Re: [PATCH v1] NFSD: Enable return of an updated stable_how to NFS clients

[Chuck Lever <cel@kernel.org>]

On 10/17/25 2:22 AM, NeilBrown wrote:
> On Thu, 16 Oct 2025, Jeff Layton wrote:
>>
>> Somewhat related question:
>>
>> Since we're on track to deprecate NFSv2 support soon, should we be
>> looking at deprecating the "async" export option too? v2 was the main
>> reason for it in the first place, after all.
> 
> Are we?  Is that justified?
> 
> We at SUSE had a customer who had some old but still perfectly
> functional industrial equipment which wrote logs using NFSv2.
> So we had to revert the nfs-utils changes which disabled NFSv2.
> It would be nice if we/they didn't have to do that to the kernel was
> well.

It's difficult to make deprecation decisions like this because such
customers are rare and are unrepresented to upstream developers. But
it's clear that there are at least two interesting alternatives
for such customers:

- Stick with older releases of Linux
- Switch to a user space client implementation


> What is the down-side of continuing v2 support?  The test matrix isn't
> that big.  Of course we need to revert the nfs-utils changes to continue
> testing.  I'd be in favour of that anyway.

IMO changes to remove NFSv2 support from nfs-utils were premature. NFSv2
can still be enabled in the kernel, so nfs-utils should continue to have
full support for it.


> And async can still have a place for the hobbyist.  If a human is
> overseeing a process and is prepared to deal with a server crash if it
> happens, but doesn't want to be slowed down by the cost of being careful
> just-in-case, then async is a perfectly rational choice.

async is not a hobbyist-only setting. I am aware of production
deployments that use the setting.

As much as I hate async, it's not something the user community will
permit us to remove, so it's going to remain for a while. But as I
mentioned before, it seems to have less and less purpose as persistent
storage speeds continue to improve.


-- 
Chuck Lever