Subject: [nfsv4] courtesy locks

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 11 Mar 2011 15:05:55 -0500

I promised yesterday that I'd dig up the previous discussion on courtesy
locks and report whether there was any issue that we could resolve in
3530bis.

The previous discussion I recall was started by Dave Noveck's survey of
courtesy-lock behavior; see

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

and followups.  I don't see any suggestions for spec changes.

As far as we know, the only existing server-side courtesy-lock
implementations do the simplest possible thing: they hang on to all the
client's state until the first conflict, and then ditch it all (and
start returning NFS4ERR_EXPIRED to that client).

The spec also permits servers to throw away only part of that state.
The thread above suggests two different approaches for handling that:

	- Continue to honor the client's remaining stateid's normally,
	  returning errors only on attempts to use the "bad" stateid's.

	- Throw away all the stateid's, but keep some record of the fact
	  that the client held certain locks.  Return EXPIRED, and allow
	  the client to reclaim the unconflicted locks using lock
	  requests that have the reclaim bit set.

	  (At least one client apparently does attempt such lock
	  requests after an EXPIRED error.)

I suppose the second has the advantage that it communicates the lock
loss to the client at the earliest possible point, and allows the client
to find out exactly which locks were lost quickly.

My impression is that the spec was written assuming the former, not the
latter, approach, though I don't see why the latter couldn't work.

In any case, since as long as we don't know of any server that actually
tries to keep courtesy locks on only a subset of a client's locks, I'm
inclined to suggest we leave well enough alone.  Perhaps some day an
industrious implementor can attempt something more complicated and
report any issues that s/he finds.

A couple other issues of possible interest raised in that thread:

	- POSIX-y clients don't necessarily have a way to tell
	  applications they've lost locks.  Giving the choice between
	  killing process completely, and letting them just soldier on,
	  the latter may be the lesser evil.  Hence the Linux client
	  behavior of recovering from EXPIRED using ordinary locks, and
	  taking some risk of silent locking violations.
	- Note that returning errors on subsequent IO doesn't always
	  help, as applications sometimes use dedicated lock files that
	  they don't do IO to.

But, again, I'm not sure we need to document any of that (any more than
we already do) in 3503bis.

--b.

---

From: Thomas Haynes <[email-masked]>
Date: Fri, 11 Mar 2011 14:24:18 -0600

Thanks for the update Bruce!

On Mar 11, 2011, at 2:05 PM, J. Bruce Fields wrote:

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