![]() | |||||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-10-07 13:40 [from the cache] ©2003-2008 | |||||||||||||