On Fri, 07 Jan 2022, 'bfields@xxxxxxxxxxxx' wrote:
> On Thu, Jan 06, 2022 at 07:23:16AM +0000, inoguchi.yuki@xxxxxxxxxxx wrote:
> > > How about this? I also updated the lock/nolock description and deleted
> > > the end of this subsection since it's redundant with that. And removed
> > > the bit about using nolock to mount /var with v2/v3 as that seems like a
> > > bit of a niche case at this point. If we still want to document that, I
> > > think it belongs elsewhere.
> >
> > Thank you so much for creating the patch!
> >
> > For the most part I agree with you, but I feel unsafe to remove the part
> > "using nolock to mount /var with v2/v3" even if it seems niche case.
> > I'm also not sure if there is another suitable document to migrate it.
> >
> > Therefore, at the end of "lock/nolock" subsection ...
>
> I could live with that.
>
> Though the other reason I cut it was because I think it needs updates
> too and I wasn't sure exactly how to handle them.
>
> The v4 case is more important and should probably be dealt with first.
> I think the answer there is just "don't mount /var over NFSv4", period.
Why not? An NFSv4 client has no business accessing anything in
/var/lib/nfs, so how can it cause a problem?
>
> And maybe we should be more specific: the problem is with /var/lib/nfs,
> not all of /var.
According to "3.2. CLIENT STARTUP" section "C/" in the README that comes
with nfs-utils,
statd should be run before any NFSv2 or NFSv3 filesystem is
mounted with remote locking (i.e. without -o nolock).
so it is only fair to say "the problem is with /var/lib/nfs" if that is
a separate filesystem from /var.
Note that "-o nolock" should also be used for the root filesystem for
root-over-NFSv3, as that must be mounted before statd can be running.
Maybe that it how it should be explained in the man page:
-o nolock should be used to mount any NFSv3 filesystems that are
mounted before rpc.statd can be started, which can only be started
after /var/lib/nfs is available.
NeilBrown
