Received-SPF: softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220126025722.GD17638@fieldses.org> <CAPt2mGP2guMMf1C9VoQ0AvZ819jPuz0vDoEzJJhtL8q5DJ300A@mail.gmail.com>
 <CAPt2mGNXq==1KUskF3U6-CDeoX57=d7NW4Qn_esDqarf9bTBaw@mail.gmail.com>
 <20220211155949.GA4941@fieldses.org> <CAPt2mGOx0qNTWoY9vmyVBtZ3gxdbv5qQ-2qVbtqWW9FiZFRhEg@mail.gmail.com>
 <164517040900.10228.8956772146017892417@noble.neil.brown.name>
 <CAPt2mGMLQCEPqsYGeaMd3BPGRne4F4h-2-pzqm1a8nwfKqv1ug@mail.gmail.com>
 <CAPt2mGMt3Sq66qmPBeGYE0CASTTy7nY2K_LjQK6VZx-uz2P-wg@mail.gmail.com>
 <20220425132232.GA24825@fieldses.org> <CAPt2mGMtBH=jzK0cTT7+PTbX-iR-iSx1RmF2beCDxBjXY5sj8A@mail.gmail.com>
 <20220425160236.GB24825@fieldses.org> <CAPt2mGPR9c9=rh4p_D7RPo+4S=DgH7VNpqvOKryKsYwaCAtnJA@mail.gmail.com>
 <165093700757.1648.16863178337904278508@noble.neil.brown.name>
 <CAPt2mGPVWuut=ESWicSw0Ser2PGTeuyb+ACL41N6p_FAAuOUwg@mail.gmail.com> <165112480439.1648.3067400915036759878@noble.neil.brown.name>
In-Reply-To: <165112480439.1648.3067400915036759878@noble.neil.brown.name>
From:   Daire Byrne <daire@dneg.com>
Date:   Fri, 29 Apr 2022 08:55:24 +0100
Message-ID: <CAPt2mGP35TPH6KBk+NWL3HcAUAECdC7pnoWfYxYNY9bTeGyhdQ@mail.gmail.com>
Subject: Re: parallel file create rates (+high latency)
To:     NeilBrown <neilb@suse.de>
Cc:     "J. Bruce Fields" <bfields@fieldses.org>,
        Patrick Goetz <pgoetz@math.utexas.edu>,
        linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 28 Apr 2022 at 06:46, NeilBrown <neilb@suse.de> wrote:
>
> On Tue, 26 Apr 2022, Daire Byrne wrote:
> > On Tue, 26 Apr 2022 at 02:36, NeilBrown <neilb@suse.de> 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