Linux NFS development
 help / color / mirror / Atom feed
From: "Frank Filz" <ffilzlnx@mindspring.com>
To: "'Chuck Lever III'" <chuck.lever@oracle.com>,
	"'Olga Kornievskaia'" <aglo@umich.edu>
Cc: "'Linux NFS Mailing List'" <linux-nfs@vger.kernel.org>
Subject: RE: sm notify (nlm) question
Date: Tue, 14 May 2024 14:36:46 -0700	[thread overview]
Message-ID: <0b1101daa646$d26a6300$773f2900$@mindspring.com> (raw)
In-Reply-To: <2C80B5BC-AAEC-41F8-BEB6-C920F88C89BB@oracle.com>

> > On May 14, 2024, at 2:56 PM, 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=0

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.

Frank


  parent reply	other threads:[~2024-05-14 21:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-14 20:56 sm notify (nlm) question Olga Kornievskaia
2024-05-14 21:08 ` Chuck Lever III
2024-05-14 21:21   ` Olga Kornievskaia
2024-05-14 21:36   ` Frank Filz [this message]
2024-05-14 21:49     ` Olga Kornievskaia
2024-05-14 22:13       ` Frank Filz
2024-05-22 13:57         ` Olga Kornievskaia
2024-05-22 16:20           ` Trond Myklebust
2024-05-22 17:18             ` Tom Talpey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='0b1101daa646$d26a6300$773f2900$@mindspring.com' \
    --to=ffilzlnx@mindspring.com \
    --cc=aglo@umich.edu \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox