Subject: [nfsv4] lockowner expiry

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 6 Jul 2006 13:22:03 -0400

>From the IMPLEMENTATION section of RELEASE_LOCKOWNER:

   The client may choose to use this operation to ease the amount of
   server state that is held.  Depending on behavior of applications at
   the client, it may be important for the client to use this operation
   since the server has certain obligations with respect to holding a
   reference to a lock_owner as long as the associated file is open.

Anyone know what those "certain obligations" are?

--b.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 06 Jul 2006 14:10:42 -0400

> Anyone know what those "certain obligations" are?

You have to keep references to all lock_owners that have been used by a
given open_owner and track their sequence numbers. Only when the
open_owner closes the file can you also release the lock_owners.

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 06 Jul 2006 14:49:48 -0400

On Thu, 2006-07-06 at 14:32 -0400, J. Bruce Fields wrote:
> On Thu, Jul 06, 2006 at 02:10:42PM -0400, Trond Myklebust wrote:
> Do you remember where that's spelled out?

No, but IIRC that was the reasoning behind the introduction of the
RELEASE_LOCKOWNER op in the first place, so I guess it would at least
have to be spelled out somewhere in the mailing list archives.

> Actually the case I was thinking about was the case of multiple
> succesful open_to_lockowner locks with the same "open" (same openstateid
> stream, no closes in between), and the same lockowner string.
> 
> Our current server code allows you to do that, creating a new sequence
> id stream for each succesful new lock.
> 
> E.g. it allows this sequence of operations, all on the same file:
> 
> 	open("openowner1") -> openstate1
> 	lock(openstate1, "lockowner1", seqid = 0) -> (openstate2, lockstate1)
> 	lock(openstate2, "lockowner1", seqid = 0) -> (openstate3, lockstate2)
> 
> and then you can do further locks with lockstate1 and lockstate2, and
> the two will have independent stateid streams.
> 
> That seems like odd client behavior, though, so was wondering whether
> it'd be safe to stop supporting it and return an error on that second
> lock instead.

AFAICS the spec doesn't really say what error you should return in the
case where the user does an open_to_lockowner more than once for the
same lockowner, but I assume that returning a BAD_SEQID would be in
order in the above case.

Cheers,
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 6 Jul 2006 14:32:14 -0400

No doubt we've been through this all before someplace....

--b.