Date: Wed, 13 Jul 2022 23:44:48 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Kirk McKusick <mckusick@mckusick.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org>, Ed Maste <emaste@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org> Subject: Re: RFC: Should intr/soft NFSv4 mounts be disabled? Message-ID: <YQBPR0101MB97420A1EB95D1E33E43059EBDD899@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <YQBPR0101MB97420523D715599F88DF133FDDBF9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> References: <YQBPR0101MB974216B2F2B1DCFF976D2065DDBD9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM> <202207031617.263GHZpZ000763@chez.mckusick.com> <YQBPR0101MB97420523D715599F88DF133FDDBF9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
In summary, it appears that most would like "intr" and/or "soft"
mounts to be allowed.
Recent commits to main (which will be MFC'd to stable/13) improve
the situation for NFSv4.1/4.2 mounts by fixing the situation where all
session slots are potentially bad, causing the mount to hang.
A lock can still end up in a non-determinate state, but at least for "intr"
mounts, the process will likely have been terminated anyhow, minimizing
the impact.
Unfortunately, to fully benefit from the above client commits, a FreeBSD
server needs the patch committed to main to-day as 088ba4356a11.
Without this patch, an "intr" and/or "soft" mount will do a full recovery,
including acquisition of a new ClientID when all slots are potentially bad.
Acquisition of the new ClientID throws away all locks, but is still an
improvement over a hung mount and will only occur after about 60
RPCs have been interrupted.
I don't know of more that can be done w.r.t. "intr" and/or "soft
NFSv4.1/4.2 mounts, but I will update the BUGS section of
"man mount_nfs".
Thanks for your input, rick
________________________________________
From: owner-freebsd-fs@freebsd.org <owner-freebsd-fs@freebsd.org> on behalf=
of Rick Macklem <rmacklem@uoguelph.ca>
Sent: Sunday, July 3, 2022 3:46 PM
To: Kirk McKusick
Cc: FreeBSD Filesystems; Ed Maste; Gleb Smirnoff
Subject: Re: RFC: Should intr/soft NFSv4 mounts be disabled?
Kirk McKusick <mckusick@freebsd.org> wrote:
> > From: Rick Macklem <rmacklem@uoguelph.ca>
> > To: FreeBSD Filesystems <freebsd-fs@freebsd.org>
> > CC: Ed Maste <emaste@freebsd.org>, Gleb Smirnoff <glebius@freebsd.org>
> > Subject: RFC: Should intr/soft NFSv4 mounts be disabled?
> > Date: Fri, 1 Jul 2022 21:57:21 +0000
> >
> > Hi,
> >
> > NFSv4 mounts using the "soft" and/or "intr" mount options
> > have never functioned correctly. This is noted in the BUGS
> > section of "man mount_nfs" and commit c0d14b0220ae
> > added the generation of a warning message when such
> > a mount is done. The breakage can occur when the server
> > is slow/overloaded or network partitioned such that the RPC
> > reply is not received for over 1 second, resulting in the RPC
> > attempt to fail without the RPC reply being processed.
> >
> > Breakage of the protocol has become more frequent for
> > NFSv4.1/4.2 mounts since, when a syscall returns before
> > the RPC reply is processed, it leaves the session slot for the
> > RPC non-usable. When all slots are non-usable, the mount
> > is hung.
> >
> > During review of commit c0d14b0220ae, emaste@ asked if
> > NFSv4 mounts using "soft" and/or "intr" should actually
> > be disabled, so I am now asking others for their opinion
> > on this? (Doing so will cause many extant mounts in fstab(5)
> > to fail.)
> >
> > Thanks for any comments, rick
>
> I have always been of the opinion that "soft" mounts were useless
> and would be happy to see them go.
>
> I find "intr" mounts to be preferable to "hard" in almost all
> situations. Being in an editor or some other application and
> being unable to ^C out of it when the server is not responding
> is extremely annoying. I know that quite some effort went into
> making NFS able to support "intr" and I think it would be worth
> the effort to continue to make it a viable alternative.
Well, I have a patch that is the last attachment in PR#260011, which
keeps track of broken session slots and then does a Destroysession
when they are all broken.
This works ok, at least against a FreeBSD server (haven't been able
to test in against other servers yet).
--> I think this fixes the more common session case, so long as the
Destroysession does the right thing for non-FreeBSD servers.
--> If anyone can test this patch, please do so. (Unfortunately the
patch looks different for main vs stable/13, so email if you need
the one for main.)
As for "intr" allowing a process to break out of an RPC,
even with the above patch, it would break that open lock,
but since the user no longer cares about the open working
(the close might fail, but that is only a problem if the server
does not do any cleanup and accumulates them) then
I think this might be ok?
> That said, it appears that Linux has deprecated "intr":
>
> https://access.redhat.com/solutions/157873
>
> Though they do still allow NFS hung processes to be killed with
> SIGKILL so if that option is available it will (painfully) be
> possible to get out of hung processes.
Yes, I think the Linux client folk have disabled "intr" for the same
reason (it screws up sessions and they have not figured out how
to deal with that). Since Linux defaults to NFSv4.1/4.2 mounts
for any server that supports that, their users probably see the
breakage more.
rick
Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB97420A1EB95D1E33E43059EBDD899>