Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "'bfields@fieldses.org'" <bfields@fieldses.org>
Cc:     "inoguchi.yuki@fujitsu.com" <inoguchi.yuki@fujitsu.com>,
        "'Trond Myklebust'" <trondmy@hammerspace.com>,
        "'linux-nfs@vger.kernel.org'" <linux-nfs@vger.kernel.org>,
        "'mbenjami@redhat.com'" <mbenjami@redhat.com>
Subject: Re: client caching and locks
In-reply-to: <20220106141628.GA7105@fieldses.org>
References: <20201006172607.GA32640@fieldses.org>,
 <164066831190.25899.16641224253864656420@noble.neil.brown.name>,
 <20220103162041.GC21514@fieldses.org>, =?utf-8?q?=3COSZPR01MB7050F9737016E8?=
 =?utf-8?q?E3F0FD5255EF4A9=40OSZPR01MB7050=2Ejpnprd01=2Eprod=2Eoutlook=2Ecom?=
 =?utf-8?q?=3E=2C?=
 <03e4cc01e9e66e523474c10846ee22147b78addf.camel@hammerspace.com>,
 <20220104153205.GA7815@fieldses.org>,
 <1257915fc5fd768e6c1c70fd3e8e3ed3fa1dc33e.camel@hammerspace.com>, 
 =?utf-8?q?=3COSZPR01MB7050C5098D47514FFEC2DA82EF4B9=40OSZPR01MB7050=2Ejpnpr?=
 =?utf-8?q?d01=2Eprod=2Eoutlook=2Ecom=3E=2C?=
 <20220105220353.GF25384@fieldses.org>, =?utf-8?q?=3COSZPR01MB7050BC53F1F38F?=
 =?utf-8?q?AA579E03B3EF4C9=40OSZPR01MB7050=2Ejpnprd01=2Eprod=2Eoutlook=2Ecom?=
 =?utf-8?q?=3E=2C?= <20220106141628.GA7105@fieldses.org>
Date:   Mon, 10 Jan 2022 09:16:21 +1100
Message-id: <164176658189.25899.1767614988647740830@noble.neil.brown.name>
Precedence: bulk

On Fri, 07 Jan 2022, 'bfields@fieldses.org' wrote:
> On Thu, Jan 06, 2022 at 07:23:16AM +0000, inoguchi.yuki@fujitsu.com 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