Re: parallel file create rates (+high latency)

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

 



On Thu, 28 Apr 2022 at 06:46, NeilBrown <neilb@xxxxxxx> wrote:
>
> 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 :-)

Thanks for looking Neil. I don't feel quite so dumb admitting that it
was way above my level! :)

Like I said, this isn't a blocker for us but definitely a nice to have
feature. Slow progress is still good progress.

Cheers,

Daire



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux