> On May 29, 2024, at 9:13 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote: >> >> >>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten >>> Leemhuis) <regressions@xxxxxxxxxxxxx> 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@xxxxxxxxxx> >>>>> 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). >> > > I've no objection if you want to do that. > > I'm more concerned about Paul's setup though. Paul, what distro are you > running that starts nfsd (and presumably, mountd, etc.), but doesn't > bother starting nfsdcld? > > Reenabling this for now is an OK workaround, but we need to understand > where these setups are coming from, and probably do some sort of > outreach to get them working properly. Getting a root cause first seems prudent. I will hold off changes for a bit. -- Chuck Lever
