Subject: [nfsv4] NFSv4.1 LOCK when new_lock_owner=true and lock_owner exists

From: Saul Tamari <[email-masked]>
Date: Thu, 18 Jul 2013 18:37:06 -0400

Hi,

Is there an expected response from an NFSv4.1 server when a client
sends a LOCK request with new_lock_owner=true and the lock_owner
passed has been previously used for the given open file without
calling of FREE_STATEID for the previously associated byte-range lock?

Thanks,
Saul

---

From: "Myklebust, Trond" <[email-masked]>
Date: Thu, 18 Jul 2013 22:49:15 +0000

> calling of FREE_STATEID for the previously associated byte-range lock?

Is there any good reason why the server should disallow this?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Rick Macklem <[email-masked]>
Date: Thu, 18 Jul 2013 18:56:40 -0400 (EDT)

> calling of FREE_STATEID for the previously associated byte-range
Same open_stateid or different open_stateid? You can have multiple
open_stateids for a given file (different open_owner4s). For that
case I believe doing a lock with new_lock_owner==true is ok, since
it associates the locks with a different open_stateid (the Close Op
must check for extant locks based on the open to lock_owner4 association).

For the case of same open_stateid and same lock_owner, I'm not so sure.
Maybe others can chime in on this case. (I'd have to look at the sources
to see what the FreeBSD server does for this case.)

rick

> Thanks,
> Saul
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Saul Tamari <[email-masked]>
Date: Thu, 18 Jul 2013 19:56:06 -0400

My understanding of the following paragraph (18.10.3) implies such a
request is incorrect:
"The open_to_lock_owner case covers the very
first lock done by a lock-owner for a given open file and offers a
method to use the established state of the open_stateid to transition
to the use of a lock stateid."
Do you think I'm reading too much into this?

When handling this for NFSv4.0 what do you suggest a server should do
with the lock_seqid argument? Overwrite the existing one? Ignore it?

Thanks,
Saul

---

From: Saul Tamari <[email-masked]>
Date: Thu, 18 Jul 2013 19:58:25 -0400

Yes. lock-owners seem are local to an open-owner.
I was referring to the same open_stateid and same lock_owner case
which I'm not sure is well defined.

Thanks,
Saul

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 19 Jul 2013 00:18:39 +0000

> Do you think I'm reading too much into this?

Yes. NFSv4.1 dumps all the sequence ids that enforced serialisation in
NFSv4.0, and enforces the sequence id in the lock stateid.

IOW: the session enforces the only-once semantics, and the remaining
ambiguity (due to slot parallelism) can always be solved on the client
by inspecting the lock stateid's seqid,

> with the lock_seqid argument? Overwrite the existing one? Ignore it?

Check it, and if the sequence id is wrong, then return
NFS4ERR_BAD_SEQID. Otherwise, accept it and apply the lock, merging it
with any existing locks just as you would for an ordinary lock request.

IOW: in the absence of any concrete guidance from the NFSv4 spec, just
apply Jon Postel's "be liberal in what you accept, and conservative in
what you send" principle.

Cheers
  Trond

NetApp

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 19 Jul 2013 00:27:49 +0000

> which I'm not sure is well defined.

If you look at the IETF mailing list archives, you're likely to find
that Rick disagrees with you on that count. :-)
He would argue that lock-owners are global, but I think we did manage to
convince him that lock _stateids_ are mapped bijectively to a triplet
consisting of <filehandle, open-owner, lock-owner> on the server...

Indeed, I now agree with him on the issue of lock-owners:
RELEASE_LOCKOWNER is an operation which doesn't take a filehandle, so
logically is _must_ apply to a global quantity.

Cheers,
  Trond

NetApp

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 19 Jul 2013 00:45:19 +0000

> logically is _must_ apply to a global quantity.

BTW: if you compare this to NFSv4.1, then you'll note that in the
latter, lock-owners are not associated to any sequence ids, and so the
lock-owner is literally just a string. The server can treat that as
local to the file or a global quantity without any consequences for the
client...

NetApp

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 19 Jul 2013 11:19:31 -0400

> logically is _must_ apply to a global quantity.

I believe this thread covers the same ground (do lock stateid's merge,
and are lockowners global?):

	http://www.ietf.org/mail-archive/web/nfsv4/current/msg09734.html

--b.

---

From: Saul Tamari <[email-masked]>
Date: Sat, 20 Jul 2013 10:17:27 -0400

So the open_to_lock_owner mode can be used to add a lock and get the
latest lock_stateid that's associated with the open_stateid? No matter
if there was or wasn't an existing lock_stateid for this lock_owner
for this open_stateid?
Seems like clients can always use this mode instead of the
'exist_lock_owner4' mode. Especially in NFSv4.1 where lock_seqid is
ignored.

Thanks,
Saul

---

From: "Myklebust, Trond" <[email-masked]>
Date: Sat, 20 Jul 2013 15:00:28 +0000

> if there was or wasn't an existing lock_stateid for this lock_owner

Yes. See RFC5661, section 8.2.1:

   o  Stateids may represent sets of byte-range locks.

      All locks held on a particular file by a particular owner and
      gotten under the aegis of a particular open file are associated
      with a single stateid with the seqid being incremented whenever
      LOCK and LOCKU operations affect that set of locks.

Also section 8.2.2:

   When such a set of locks is first created, the server returns a
   stateid with seqid value of one.  On subsequent operations that
   modify the set of locks, the server is required to increment the
   "seqid" field by one whenever it returns a stateid for the same
   state-owner/file/type combination and there is some change in the set
   of locks actually designated.  In this case, the server will return a
   stateid with an "other" field the same as previously used for that
   state-owner/file/type combination, with an incremented "seqid" field.
   This pattern continues until the seqid is incremented past
   NFS4_UINT32_MAX, and one (not zero) is the next seqid value.

There are no exceptions in either description above for the case of
open_to_lock_owner.

Also see section 8.2.4.

   Stateids must remain valid until either a client restart or a server
   restart or until the client returns all of the locks associated with
   the stateid by means of an operation such as CLOSE or DELEGRETURN.
   If the locks are lost due to revocation, as long as the client ID is
   valid, the stateid remains a valid designation of that revoked state
   until the client frees it by using FREE_STATEID.  Stateids associated
   with byte-range locks are an exception.  They remain valid even if a
   LOCKU frees all remaining locks, so long as the open file with which
   they are associated remains open, unless the client frees the
   stateids via the FREE_STATEID operation.

Again, no exceptions for open_to_lock_owner.

> 'exist_lock_owner4' mode. Especially in NFSv4.1 where lock_seqid is

The reason they might not want to do so is because the
open_to_lock_owner mode is likely to involve more work on the server,
and so performance will suck worse that usual.

Cheers
  Trond

NetApp