Re: [RFC] atomic create+open

[Trond Myklebust]

fr den 07.10.2005 Klokka 08:01 (+0200) skreiv Miklos Szeredi:
> > > I just think that filesystem code should _never_ need to care about
> > > mounts.  If you want to do the lookup+open, you somehow will have to
> > > deal with mounts, which is ugly.
> > 
> > You appear to think that atomic lookup+open is a question of choice. It
> > is not.
> 
> Atomic lookup+open is an optimization, and as such a question of
> choice.  Atomic create+open is not.

Really? Under NFSv4, the one and only OPEN command does an atomic lookup
+open, It _has to_ in order to deal with all the races.

Once that is the case, then separating lookup and open into two
operations means that you need to worry about namespace changes on the
server too (since OPEN takes a name argument rather than a filehandle).
If you end up opening a different file to the one you looked up, things
can get very interesting.

> I know you are thinking of the non-exclusive create case when between
> the lookup and the open the file is removed or transmuted on the
> server..

> Yes, it's tricky to sovle, but by no means impossible without atomic
> lookup+open.  E.g. consider this pseudo-code (only the atomic
> open+create case) in open_namei():

Firstly, that pseudo-code doesn't deal at all with the race you describe
above. It only deals with lookup + file creation.

Secondly, it also fails to deal with the issue of propagation of open
context.
If you open a file, then that creates open context/state on the server.
Most protocols will then have some way of tracking that state using an
identifier (the equivalent of the POSIX open file descriptor). I see
absolutely nothing in your proposal that will allow me to save the state
identifier that results from atomic open+create and then propagate it to
the struct file.

Without that stateid/descriptor, it becomes impossible to actually READ,
WRITE, lock/unlock the file or even to CLOSE it when done.

This is why I added the struct file to the intent code in the first
place.

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/