Re: [PATCH v7 05/14] NFSD: @stable for direct writes is always NFS_FILE_SYNC

[Christoph Hellwig <hch@infradead.org>]

On Mon, Oct 27, 2025 at 10:58:19AM -0400, Mike Snitzer wrote:
> On Mon, Oct 27, 2025 at 07:36:18AM -0700, Christoph Hellwig wrote:
> > On Mon, Oct 27, 2025 at 10:31:55AM -0400, Mike Snitzer wrote:
> > > > that.  High-end enough device won't have one, but a lot of devices that
> > > > people NFS-export do.  For pure overwrites the file system could
> > > > optimize this way by using the FUA flag, and at least the iomap direct
> > > > I/O code does implementation that optimization for that particular case.
> > > 
> > > NFSD_IO_DIRECT isn't meant to be uniformly better for all types of
> > > storage.  Any storage that has a volatile write cache is probably best
> > > served by existing NFSD default (NFSD_IO_BUFFERED).
> > 
> > That's a very odd claim.  Also what does it have to do with the rest of
> > the discussion here?
> 
> What's an odd claim?  That shitty storage shouldn't be the bad apple
> that spoils the bunch?  You seem to be advocating for requiring
> additional NFSD resources as part of the NFSD_IO_DIRECT
> implementation.

What f***ing additional resources?   What "shitty" storage?

> But we could make NFSD's behavior tuneable such that it can signal to
> NFS client NFS_FILE_SYNC or not.

Sure.  If you can come up with a good argument for returning it
for writers that don't requrst it, because in general it's going
to make things slower.

> The goal is to walk before expanding to running with other
> permutations of how to tune NFSD's IO modes.

So don't throw in random other permutations and jut concentrate on
direct I/O instead of opening up a totally new can of worms?

> > Why?
> 
> Because NFSD will then need to hold the IO until the COMMIT operation.
> That requires extra NFSD resurces right?

What I/O does it need to hold?  It just needs to implement a commit that
does a range fsync.  The client will have to still track these I/Os,
but that's fairly light weight and for most cases has huge benefits.

> 
> > > The current approach of using IOCB_DSYNC|IOCB_SYNC have performed
> > > really well on modern NVMe servers.
> > 
> > NVMe does not implement a concept called servers.
> 
> But you're aware that servers have NVMe devices in them.. that's all I
> meant.  All of these NFSD_IO_DIRECT changes have been developed and
> tested in modern servers with 8 NVMe, see:
> https://www.youtube.com/watch?v=tpPFDu9Nuuw

I'm not going to watch videos to reply to a mail thread, so if there
is anything important in that please summarize it.

> (NOTE: results covered in this session did _not_ have the benefit
> of NFSD responding to client with NFS_FILE_SYNC to avoid COMMIT, the
> ability to do so was discussed at Bakeathon and was acted on with
> these latest NFSD Direct patchsets).

Why do you think randomly returning NFS_FILE_SYNC is actually going
to improve things?  Except for one particular corner case I expect
it to make things worse, often much worse.