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

[Mike Snitzer <snitzer@kernel.org>]

On Thu, Oct 30, 2025 at 07:20:02AM -0700, Christoph Hellwig wrote:
> On Thu, Oct 30, 2025 at 08:56:38AM -0400, Chuck Lever wrote:
> >    Either the underlying persistent storage is faster than most any
> >    network fabric (eg, NVMe); or the network connection to the
> >    client is very high latency (eg, a WAN link).
> 
> NVMe really is an interface and not a description of performance
> characteristics.  Nevertheless none of the NVMe implementations I
> know have lower roundtrip latency than modern local networks.

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).

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.

> > This patch is a year old, so won't apply to current kernels. But
> > the idea is similar to Mike's suggestion that NFSD_IO_DIRECT
> > should promote all NFS WRITEs to durable writes, but is much
> > simpler in execution. Any interest in revisiting this approach?
> 
> This is a much better approach than overloading direct I/O with
> these semantics.  I'd still love to see actual use cases for which
> we see benefits before merging it.

Yes.  Also thinking that a "data_sync" export option would be
appropriate too (that way to have the ability to try all stable_how
variants).  Chuck?  If something like that sounds OK in theory I can
rebase your patch (still attributed to you) and then create a separate
to add "data_sync" and then work to get the permutations tested.

Or the export option could be stable_how=[unstable,data_sync,file_sync] ?
(knowing that this export option would just set the stable_how floor,
NFSD cannot downgrade NFS client specified stable_how as per the spec
Chuck pointed to before).
(but that ushers in collision with async and stable_how=, so maybe
best to just go with discrete export options? or confine stable_how=
to being able to set data_sync or file_sync?)

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.

Thanks,
Mike