Re: [PATCH v4 2/3] NFSD: add new NFSD_IO_DIRECT variants that may override stable_how

[Mike Snitzer <snitzer@kernel.org>]

On Thu, Nov 06, 2025 at 03:35:29PM -0500, Chuck Lever wrote:
> On 11/6/25 3:17 PM, Mike Snitzer wrote:
> >> I asked for the use of a file_sync export option because we need to test
> >> the BUFFERED cache mode as well as DIRECT. So, continue to experiment
> >> with this one, but I don't plan to merge it for now.
> > Doesn't the client have the ability to control NFS_UNSTABLE,
> > NFS_DATA_SYNC and NFS_FILE_SYNC already?  What experiment are you
> > looking to run?
> > 
> > If just looking to compare NFS_FILE_SYNC performance of
> > NFSD_IO_BUFFERED versus NFSD_IO_DIRECT then using the client control
> > is fine right?
> 
> Not necessarily. You can mount with "sync" but for large application
> write requests, that might still generate UNSTABLE + immediate COMMIT.

OK, I'll take a closer look at NFS client controls for stable_how,
because NFSD clearly handles NFS_DATA_SYNC and NFS_FILE_SYNC so I just
assumed its because the client does actually send them.

> > Anyway, maybe I'm just being overly concerned about the permanence of
> > an export option.  I thought it best to avoid export for now given we
> > do seem to have adequate controls for a NFS_FILE_SYNC performance
> > bakeoff.
> 
> I agree on not rushing another administrative API change. I was thinking
> you would be prototyping some of this stuff first and playing with it
> for a little while before it goes upstream.
> 
> It feels like it would be much more straightforward to implement an
> export option that applies to all cache modes rather than gluing it to
> DIRECT.

OK, I'll carry the patch in Hammerspace kernel for the time being so
Jon Flynn can test whenever he has availability,

> And as I said above, "no plan to merge it for now," meaning it's still
> on the table for sometime down the road. I have some other ideas I'm
> cooking up, such as using BDI congestion to control NFS WRITE
> throttling.

Hmm, I thought the BDI congestion infra got killed (by Jan Kara and
others).. which made me sad because when it was first introduced it
was amazing at solving some complex deadlocks (but we're talking 20
years ago now).  So I haven't kept my finger on the pulse of what is
still available to us relative to BDI congestion.

Another possiblity is the PSI data, that infra was put in place by
Meta to deal with exactly the sitution we're confronting: take
action(s) when pressure builds to a particular threshold.

> But let's get the base direct WRITE stuff finished.

Yes.