All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.