Re: [RFC PATCH] NFSD: Add a "file_sync" export option

[Mike Snitzer <snitzer@kernel.org>]

On Thu, Oct 30, 2025 at 08:45:42AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 30, 2025 at 11:33:00AM -0400, Mike Snitzer wrote:
> > Sure, but not all modern networks have the same level of performance
> > either.  When the NVMe is faster than the network we don't see nearly
> > as much MM pressure.  But that implies the network is the bottleneck, so
> > reducing network operations (like COMMIT) should reduce network
> > traffic (even if marginally).
> 
> There is a lot of code between the network and the storage, and they
> tend to be slower than either for many common workloads :)

I've been pretty impressed with how NFS, and surrounding Linux IO
stacks (network and storage), is able to keep up with really fast
hardware.

> > Once the network is as fast or faster than the NVMe devices, that's
> > when we've seen VM writeback/reclaim with buffered IO become
> > detrimental (when the working set exceeds system memory by a factor of
> > 3:1).  And that's where NFSD_IO_DIRECT mode has proven best.
> 
> I bet that getting VM writeback out of the stack helps at lot.  But as
> mentioned I doubt forcing stable writes helps, and in fact for most
> workloads will actually make it slower.  But that's just my experience
> from similar but not the same things, so I'd love to see numbers if
> you suspect something else.  Either way we're much better off changing
> one variable at a time instead of forcing two totally unrelated changes
> to go together.

Yeah.  I'd have split them out to new variants of NFSD_IO_DIRECT,
e.g.:
NFSD_IO_DIRECT_DATA_SYNC
NFSD_IO_DIRECT_FILE_SYNC

But using a proper export option to control stable_how entirely
independent of the chosen NFSD_IO mode is more useful.

> > Christoph, if you have canned benchmarks that do a solid job of
> > showcasing overwrites (which you expect to really benefit from _not_
> > having DSYNC or DSYNC|SYNC set) please let me know.
> 
> None with nfs in the loop.  For an older benchmark with purely
> local I/O, 3460cac1ca76215a60acb086ebe97b3e50731628 has an example,
> which should be pretty representative for modern workloads, even if
> the overall numbers for each case would improve a lot.

Even if not for NFS, we can run NFS client using O_DIRECT which
should drive the IO so NFSD receives it much like the application
issued it (albeit wrapped in XDR and NFS protocol).  And if using
NFSD_IO_DIRECT we should then be able to assess how/if changing
stable_how impacts performance.