On Tue, 26 Apr 2022, Daire Byrne wrote: > On Tue, 26 Apr 2022 at 02:36, NeilBrown <neilb@xxxxxxx> wrote: > > > > On Tue, 26 Apr 2022, Daire Byrne wrote: > > > > > > I'll stare at fs/nfsd/vfs.c for a bit but I probably lack the > > > expertise to make it work. > > > > Staring at code is good for the soul .... but I'll try to schedule time > > to work on this patch again - make it work from nfsd and also make it > > handle rename. > > Yea, I stared at it for quite a while this morning and no amount of > coffee was going to help me figure out how best to proceed. yes, it isn't at all straight forward - is it? We probably need quite a bit of surgery in nfsd/vfs.c to make it more similar to fs/namei.c. In particularly we will need to use filename_create() instead of lookup_one_len(). There is a potential cost to doing this though. The NFS protocol allows the server to report the change-id of the directory before and after a create/unlink operation so that the client can determine if it is the only one making changes to the directory, and so can keep its cache. This requires the pre/post to be atomic - which requires an exclusive lock. If we change nfsd to use a shared lock on the directory, then it cannot report atomic pre/post attributes, so the client will have to flush its cache more often. Support parallel creates and atomic attributes we would need to enhance the filesystem interface so the fs can report the attributes for each create. Could get messy. This doesn't actually matter for NFS re-export because it doesn't support atomic attributes anyway. It also doesn't matter if multiple clients are changing tghe one directory. But I think we do want to keep atomic attributes for exporting other filesystems in other use-cases. It's starting to get messy. Not impossible, just messy. Messy takes longer :-) NeilBrown
