On Tue, May 14, 2024 at 5:09 PM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote: > > > > > On May 14, 2024, at 2:56 PM, Olga Kornievskaia <aglo@xxxxxxxxx> 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 Thank you Chuck. This too does not give any limits as to the uniqueness of the state value. > > 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. State is supposed to help against replays I think. This client is in its right to update the state value upon processing a reboot notification. The fact that another sm_notiffy comes with the same state (and from the same DNS name monitor name) seems logical that can be a re-try and thus grounds for ignoring it. > > > -- > Chuck Lever > >
