>>>>> "Al" == Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes: Al> On Thu, Mar 05, 2015 at 04:21:21PM +1100, NeilBrown wrote: >> Hi Al (and others), >> >> I wonder if you could look over this patchset. >> It allows RCU-walk to follow symlinks in many common cases, >> thus removing a surprising performance hit caused by using symlinks. >> >> The last could of patches make changes to XFS and NFS to support >> this but I haven't forwarded to the relevant lists yet. >> If/when the early code meets with approval I'll do that. >> >> The first patch almost certainly needs to be changed. I originally >> wrote this code when filesystems could see inside nameidata. >> It is now opaque so the simplest solution was to provide an >> accessor function. >> Maybe I should as a 'flags' arg to ->follow_link?? Or have -> follow_link and ->follow_link_rcu ?? >> What do you suggest? Al> Umm... Some observations: Al> * now ->follow_link() can be called in RCU mode, which means Al> that it can race with fs shutdown; not a problem, except that now it Al> joins ->lookup() et.al. in "if some data structure is needed in RCU Al> case of that, make sure it's not destroyed without an RCU delay somewhere Al> between the entry into ->kill_sb() and destruction. Al> * highmem pages in symlinks: that BS shouldn't be allowed at Al> all. Just make sure that at least for those filesystems symlink inodes Al> get mapping_set_gfp_mask(&inode->i_data, GFP_KERNEL) and be done with that. So what happens if your filesystem is 10Tb in size, and you have 50 million files and lots of them are symlinks? I've got developers who do shit like this and wonder why performance sucks.... and I just worry that GPF_KERNEL is a limited resource. But maybe 64bit systems won't really have any problems? Rest of this is way outside my pay grade to commment on. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
