Received-SPF: pass (google.com: domain of linux-nfs+bounces-3257-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Olga Kornievskaia'" <aglo@umich.edu>
Cc: "'Chuck Lever III'" <chuck.lever@oracle.com>,
	"'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>
References: <CAN-5tyFBn3C_CTrsftuYeWJHe7KWxd82YFCyrN9t=az8J4RU0w@mail.gmail.com> <2C80B5BC-AAEC-41F8-BEB6-C920F88C89BB@oracle.com> <0b1101daa646$d26a6300$773f2900$@mindspring.com> <CAN-5tyGECFmtzFsYNSZicPcH4SMKF0yovk6V20sWJ1LrZKzzyA@mail.gmail.com>
In-Reply-To: <CAN-5tyGECFmtzFsYNSZicPcH4SMKF0yovk6V20sWJ1LrZKzzyA@mail.gmail.com>
Subject: RE: sm notify (nlm) question
Date: Tue, 14 May 2024 15:13:32 -0700
Message-ID: <0b1401daa64b$f5831ee0$e0895ca0$@mindspring.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQHEASMWtXHACiXspnILht8YFbc9TwH0RebzAOjRexECfegJKbGZvMmA


> -----Original Message-----
> From: Olga Kornievskaia [mailto:aglo@umich.edu]
> Sent: Tuesday, May 14, 2024 2:50 PM
> To: Frank Filz <ffilzlnx@mindspring.com>
> Cc: Chuck Lever III <chuck.lever@oracle.com>; Linux NFS Mailing List =
<linux-
> nfs@vger.kernel.org>
> Subject: Re: sm notify (nlm) question
>=20
> On Tue, May 14, 2024 at 5:36=E2=80=AFPM Frank Filz =
<ffilzlnx@mindspring.com> wrote:
> >
> > > > On May 14, 2024, at 2:56=E2=80=AFPM, Olga Kornievskaia =
<aglo@umich.edu>
> wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > Given that not everything for NFSv3 has a specification, I post =
a
> > > > question here (as it concerns linux v3 (client) implementation)
> > > > but I ask a generic question with respect to NOTIFY sent by an =
NFS server.
> > >
> > > There is a standard:
> > >
> > > https://pubs.opengroup.org/onlinepubs/9629799/chap11.htm
> > >
> > >
> > > > A NOTIFY message that is sent by an NFS server upon reboot has a
> > > > monitor name and a state. This "state" is an integer and is
> > > > modified on each server reboot. My question is: what about state
> > > > value uniqueness? Is there somewhere some notion that this value
> > > > has to be unique (as in say a random value).
> > > >
> > > > Here's a problem. Say a client has 2 mounts to ip1 and ip2 (both
> > > > representing the same DNS name) and acquires a lock per mount. =
Now
> > > > say each of those servers reboot. Once up they each send a =
NOTIFY
> > > > call and each use a timestamp as basis for their "state" value =
--
> > > > which very likely is to produce the same value for 2 servers
> > > > rebooted at the same time (or for the linux server that looks =
like
> > > > a counter). On the client side, once the client processes the =
1st
> > > > NOTIFY call, it updates the "state" for the monitor name (ie a
> > > > client monitors based on a DNS name which is the same for ip1 =
and
> > > > ip2) and then in the current code, because the 2nd NOTIFY has =
the
> > > > same "state" value this NOTIFY call would be ignored. The linux
> > > > client would never reclaim the 2nd lock (but the application
> > > > obviously would never know it's missing a lock)
> > > > --- data corruption.
> > > >
> > > > Who is to blame: is the server not allowed to send "non-unique"
> > > > state value? Or is the client at fault here for some reason?
> > >
> > > The state value is supposed to be specific to the monitored host. =
If
> > > the client is indeed ignoring the second reboot notification, =
that's incorrect
> behavior, IMO.
> >
> > If you are using multiple server IP addresses with the same DNS =
name, you
> may want to set:
> >
> > sysctl fs.nfs.nsm_use_hostnames=3D0
> >
> > The NLM will register with statd using the IP address as name =
instead of host
> name. Then your two IP addresses will each have a separate monitor =
entry and
> state value monitored.
>=20
> In my setup I already have this set to 0. But I'll look around the =
code to see what
> it is supposed to do.

Hmm, maybe it doesn't work on the client side. I don't often test NLM =
clients with my Ganesha work because I only run one VM and NLM clients =
can=E2=80=99t function on the same host as any server other than =
knfsd...

Frank