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

[Mike Snitzer <snitzer@kernel.org>]

On Thu, Oct 30, 2025 at 11:47:15AM -0400, Chuck Lever wrote:
> On 10/30/25 11:33 AM, Mike Snitzer wrote:
> >>> 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.
> 
> And the reason it hasn't been merged yet is because I couldn't find any
> such workloads. Even tmpfs was a little slower without the COMMITs,
> to my surprise.
> 
> 
> > 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.
> 
> If you want to experiment, feel free.
> 
> As always, I'm not enthusiastic about exposing a bunch of tuning knobs
> like this without a clear understanding of how it benefits users and
> what documentation might look like explaining how to use it. So for the
> moment, this patch is, as labeled in the Subject: field, an RFC, and not
> a firm/official proposal for an API change. (Note that IIRC, adding the
> new export option was an idea we had /before/ we had
> /sys/kernel/debug/nfsd available to us).
> 
> Or to put it differently, just because I proposed this patch does not
> mean it's automatically "Chuck approved". I'm interested in experimental
> results first. I'm thinking you have access to big iron on which to try
> it.
> 
> But, in the bigger picture, I think comparison between this approach
> and NFSD_IO_DIRECT might be illustrative.

Sure, I'm very interested in the data myself.  A patch to easily
enable control is all I'm after. So given what you said above, I'll
actually just run with introducing 2 new variants of NFSD_IO_DIRECT
for now, so like I mentioned in my previous reply to hch:

NFSD_IO_DIRECT_DATA_SYNC
NFSD_IO_DIRECT_FILE_SYNC

Because it sounds like it is only in the context of NFSD_IO_DIRECT
where there is any doubt about whether using NFS_FILE_SYNC helpful.
So it bounds the supportability exposure, and makes it clear these
knobs are for experimental purposes relative to NFS_IO mode controls.