From: Jeff Layton <jlayton@kernel.org>
To: NeilBrown <neil@brown.name>
Cc: Chuck Lever <cel@kernel.org>, Mike Snitzer <snitzer@kernel.org>,
Olga Kornievskaia <okorniev@redhat.com>,
Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
linux-nfs@vger.kernel.org, Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [PATCH v1] NFSD: Enable return of an updated stable_how to NFS clients
Date: Fri, 17 Oct 2025 07:09:17 -0400 [thread overview]
Message-ID: <9cb044ec5e03730c445f424d53afb3dbe51733d6.camel@kernel.org> (raw)
In-Reply-To: <176068215301.1793333.15890172978403788855@noble.neil.brown.name>
On Fri, 2025-10-17 at 17:22 +1100, 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.
>
> 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.
>
> 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.
>
> I'm not in favour of deprecating things that work.
>
> NeilBrown
I think we should. We deprecate obsolete drivers and (even CPU
architectures!) all the time. Arnd has even started discussing
deprecating 32-bit CPU support in the kernel altogether. Why would we
not deprecate obsolete protocols too? The handful of people that still
need v2 support can boot to an old kernel.
Supporting NFSv2 is a maintenance burden (albeit a mostly minor one at
this point). If we want to properly support it, it has to be tested,
which I don't think anyone is doing currently. I only have so much time
to spend on upstream maintenance, and I don't care to spend it
supporting v2.
SuSE's customer using ancient equipment is an exception here, but I
don't think that's enough to justify all of us spending time keeping v2
limping along.
Do you have the same attachment to NFSv4.0? We had a discussion around
starting to deprecate it as well. Having to support v4.0 _is_ a
significant maintenance burden, IMO.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2025-10-17 11:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-13 19:01 [PATCH v1] NFSD: Enable return of an updated stable_how to NFS clients Chuck Lever
2025-10-13 19:34 ` Jeff Layton
2025-10-14 5:24 ` NeilBrown
2025-10-15 16:53 ` Mike Snitzer
2025-10-15 18:00 ` Chuck Lever
2025-10-15 18:11 ` Jeff Layton
2025-10-15 18:16 ` Chuck Lever
2025-10-17 6:22 ` NeilBrown
2025-10-17 11:09 ` Jeff Layton [this message]
2025-10-17 23:15 ` NeilBrown
2025-10-17 13:43 ` Chuck Lever
2025-10-17 23:19 ` NeilBrown
2025-10-15 18:40 ` Mike Snitzer
2025-10-15 22:13 ` [PATCH v3] NFSD: Implement NFSD_IO_DIRECT for NFS WRITE Mike Snitzer
2025-10-16 16:10 ` Jeff Layton
2025-10-17 14:13 ` Chuck Lever
2025-10-17 21:03 ` Mike Snitzer
2025-10-17 21:54 ` Chuck Lever
2025-10-17 22:49 ` Mike Snitzer
2025-10-17 23:23 ` NeilBrown
2025-10-17 4:08 ` [PATCH v1] NFSD: Enable return of an updated stable_how to NFS clients Christoph Hellwig
2025-10-17 13:27 ` Chuck Lever
2025-10-20 6:59 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9cb044ec5e03730c445f424d53afb3dbe51733d6.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=dai.ngo@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neil@brown.name \
--cc=okorniev@redhat.com \
--cc=snitzer@kernel.org \
--cc=tom@talpey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).