Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux