Messages in this thread | | | Subject | Re: [RFC] atomic create+open | From | Miklos Szeredi <> | Date | Fri, 07 Oct 2005 19:27:09 +0200 |
| |
> > > > > > Which may return yet another result for the dentry and another race. > > > There is no guarantee that you will ever make progress if someone is > > > doing something like. > > > > > > while true > > > do > > > echo "1" > foo > > > echo "2" > foo > > > done > > > > > > on the server. > > > > Not good example. This won't change the file, only the contents. > > Something with rename would be better. > > Sorry, yes. This tweak should demonstrate what I meant > > while true > do > echo "1" > foo > echo "2" > bar > mv bar foo > done > > > We are still pitting two different races against each other. I can't > > see such a big difference in ugliness... > > No we're not. I telling you that your open_create is not a solution for > the problems we have with open in NFSv4.
OK, I think I see the problem better now.
> If it doesn't do atomic lookup+open, then I have an unfixable race. Any > "solution" that requires NFS to assume that the dcache will remain > consistent with the server namespace across more than one RPC operation > is prone to races. > > OTOH mount/umount races are fixable since they involve only the local > namespace. Just add locking.
You _could_ take the namespace semaphore across lookup_hash() and follow_mount(), but I'm not sure everybody would like that.
Are you planning to post a patch? Atomic open+create is something that FUSE wants as well, so it would be nice to get a proper solution into the kernel.
I'll think a bit more about solving the mount thing properly.
Miklos - 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/
| |