On Fri, Jan 14, 2011 at 3:18 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:> On Thu, 13 Jan 2011, Miklos Szeredi wrote:>> On Sat, 8 Jan 2011, Nick Piggin wrote:>> > The vfs-scale branch is now upstream. If you haven't>> > looked yet, your filesystem is likely to have been>> > touched, so check it out.>> >>> > Also look at Documentation/filesystems/porting and>> > path-lookup.txt.>> >>> > The dcache_lock stuff should have been all done for you>> > (for in-tree filesystems, I can help out of tree fses with>> > conversions there if you ping me offline).>> >>> > The rcu-walk stuff can be more tricky for your filesystem>> > to take advantage of.>> >>> > If you supply a .d_revalidate, .permission, or .check_acl,>> > then path walking is going to be slow and unscalable for>> > you.>> >>> > Out of tree filesystems: you _have_ to at least add a line>> > of code to the above functions in order to specify that>> > you don't want to participate in rcu-walk.>> >>> > Otherwise, you don't have to care about rcu-walk if you>> > have a legacy or special filesystem like configfs then I'd>> > advise against anything fancy. But if you have a>> > userbase and you expect them to actually do any path>> > lookups into your filesystem, please take a look.>>>> One other thing: I know ECHILD is safe since no sane filesystem will>> return it in its permission or revalidate callbacks, and even if it>> does that's just a loss of optimization.>> And it's not entirely safe either. A fuse filesystem returning ECHILD> would make nameidata_dentry_drop_rcu() to BUG. So some sort of errno> filter is necessary in the fuse kernel module.