From: Chuck Lever III <chuck.lever@oracle.com>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Jeff Layton <jlayton@kernel.org>,
Paul Menzel <pmenzel@molgen.mpg.de>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
"it+linux-nfs@molgen.mpg.de" <it+linux-nfs@molgen.mpg.de>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: NFSD: Unable to initialize client recovery tracking! (-110)
Date: Fri, 24 May 2024 16:09:18 +0000 [thread overview]
Message-ID: <5360A648-8236-466C-A9D8-82F2BBE6F059@oracle.com> (raw)
In-Reply-To: <90700421-4567-4e28-ae71-8541086b46e2@leemhuis.info>
> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
>
> On 21.05.24 12:01, Jeff Layton wrote:
>> On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
>>> Am 19.04.24 um 18:50 schrieb Paul Menzel:
>>>
>>>> Since at least Linux 6.8-rc6, Linux logs the warning below:
>>>>
>>>> NFSD: Unable to initialize client recovery tracking! (-110)
>>>>
>>>> I haven’t had time to bisect yet, so if you have an idea, that’d be great.
>>>
>>> 74fd48739d0488e39ae18b0168720f449a06690c is the first bad commit
>>> commit 74fd48739d0488e39ae18b0168720f449a06690c
>>> Author: Jeff Layton <jlayton@kernel.org>
>>> Date: Fri Oct 13 09:03:53 2023 -0400
>>>
>>> nfsd: new Kconfig option for legacy client tracking
>>>
>>> We've had a number of attempts at different NFSv4 client tracking
>>> methods over the years, but now nfsdcld has emerged as the clear winner
>>> since the others (recoverydir and the usermodehelper upcall) are
>>> problematic.
>> [...]
>> It sounds like you need to enable nfsdcld in your environment. The old
>> recovery tracking methods are deprecated. The only surviving one
>> requires the nfsdcld daemon to be running when recovery tracking is
>> started. Alternately, you can enable this option in your kernels if you
>> want to keep using the deprecated methods in the interim.
>
> Hmm. Then why didn't this new config option default to "Y" for a while
> (say a year or two) before changing the default to off? That would have
> prevented people like Paul from running into the problem when running
> "olddefconfig". I think that is what Linus would have wanted in a case
> like this, but might be totally wrong there (I CCed him, in case he
> wants to share his opinion, but maybe he does not care much).
That's fair. I recall we believed at the time that very few people
if anyone currently use a legacy recovery tracking mechanism, and
the workaround, if they do, is easy.
> But I guess that's too late now, unless we want to meddle with config
> option names. But I guess that might not be worth it after half a year
> for something that only causes a warning (aiui).
In Paul's case, the default behavior might prevent proper NFSv4
state recovery, which is a little more hazardous than a mere
warning, IIUC.
To my surprise, it often takes quite some time for changes like
this to matriculate into mainstream usage, so half a year isn't
that long. We might want to change to a more traditional
deprecation path (default Y with warning, wait, default N, wait,
redact the old code).
--
Chuck Lever
next prev parent reply other threads:[~2024-05-24 16:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 16:50 NFSD: Unable to initialize client recovery tracking! (-110) Paul Menzel
2024-05-21 9:55 ` Paul Menzel
2024-05-21 10:01 ` Jeff Layton
2024-05-24 11:16 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-24 12:46 ` Jeff Layton
2024-05-24 16:09 ` Chuck Lever III [this message]
2024-05-29 12:51 ` Linux regression tracking (Thorsten Leemhuis)
2024-05-29 13:13 ` Jeff Layton
2024-05-29 13:16 ` Chuck Lever III
2024-05-29 13:27 ` Paul Menzel
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=5360A648-8236-466C-A9D8-82F2BBE6F059@oracle.com \
--to=chuck.lever@oracle.com \
--cc=it+linux-nfs@molgen.mpg.de \
--cc=jlayton@kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=regressions@lists.linux.dev \
--cc=torvalds@linux-foundation.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).