On Sun, 17 May 2015 11:55:35 +0100 Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > As for Neil's point re do_last() and friends being much too convoluted - yes, > they are. And it's not a result of trying to shoehorn everything in one > model. "Just let NFS have at it" as soon as we reach do_last() won't make > things any simpler, unfortunately - we'll end up with the same convoluted > mess copied in a bunch of filesystems, each with bugs of its own. There is no reason to be so gloomy. The VFS would provide a generic_do_last() (or whatever) which handles everything correctly for local filesystems which keep the dcache precisely consistent and use it for all the valuable locking it can provide. generic_to_last() would call into other filesystem entry points just like the current do_last() does. It wouldn't bother with 'revalidation' though. Then there might be a "generic_network_do_last()" which does minimal if any checking because the server will do all that, and just calls back to the filesystem depending on which particular operation is happening - mkdir, or unlink or whatever. Filesystem developers are both very clever and (I assume) very lazy. If you provide them with tools that work and are easy to understand, they will much rather use them than try to implement their own. This is why the page cache is such a success. The more I think about this, the more it seems to me that having a dentry that can be "unknown", or as you put it "in-lookup" is potentially transformational. Pathname lookup just always returns the dentry of the final component (plus vfsmount), but that final component might be "unknown". Then the various "last" steps are quite separate and each work with this dentry. They unlink or mkdir or mknod or lookup or create or whatever. There are probably races that make this a little more complicated than I am hoping, and rename will doubtlessly be the most interesting. But it feels like a good direction. That is all a long way off of course. Even just getting a "in-lookup" dentry and starting to explore what can be done with that would be a very positive step I think. Thanks, NeilBrown
Attachment:
pgpYZcBlTyYzO.pgp
Description: OpenPGP digital signature
