Subject: Re: [nfsv4] conflicting lock returns

From: [email-masked]
Date: Tue, 13 Jun 2006 11:56:53 -0400 (EDT)

> Agreed on getting it right, but going to great lengths in the server
> to provide it? Does it need to be *that* right? I don't think so.

I don't believe Bruce specified how they wanted to cheat. A clientid +
NULL name or a bogus clientid or ??? I agree that it is information that
does not seem critical, but maybe useful.

> Also, I'll point out again that a client who gets a lock contention
> on itself deserves to be confused.

I don't see anything in the RFC that requires a client to check for conflicts
locally and not depend on the server to handle it. My client for OpenBSD
doesn't check and depends on the server to spot conflicts. (I can see the
argument for the client doing it locally for performance reasons, but I'm
assuming that I will get there once I start using delegations effectively.)

rick

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 13 Jun 2006 12:09:07 -0400

>assuming that I will get there once I start using delegations effectively.)

I guess my point is, if the client doesn't check whether it holds a
conflicting lock, then it won't be able to use the response "you already
have it" any more effectively than a response that another client holds
it. The result will be the same in any case! (right?)

Tom.

---

From: Eric Werme USG <[email-masked]>
Date: Tue, 13 Jun 2006 12:56:01 -0400

Tom & Rick-with-a-k wrote:
>> Tom:

If you're doing a blocking lock request (lock type READW_LT or WRITEW_LT),
It's reasonable to contact the server first to get one's request on the
queue.  If the lock is blocked, you'll get a lockowner back.  I'd be inclined
to look at that before checking the local lock database.  In either case,
a Posix client which can then be massaged, found to refer to a local
lock, etc, and then be discarded because Posix doesn't return owner
information.

On a Posix client, it may make sense to check the local lock database
before sending LOCKT both for avoiding network delays and to be
able to return useful information.

Hmm.  RFC 3530 says:

   The LOCKT operation tests the lock as specified in the arguments.  If
   a conflicting lock exists, the owner, offset, length, and type of the
   conflicting lock are returned;

Note that there may be multiple locks blocking the request.

Note that Posix (well, X/Open XSI) says for F_GETLK:

   Get the first lock which blocks the lock description...

So even if there is a local blocker, it may make sense to talk
to the server first even if the reponse doesn't let you return
senisble results.  I guess I'd be inclined to check the local
data base first and return the first match there (in whatever order
they might be in!).  If the goal is "accelerate" getting a lock,
the quality of the information is more useful than returning the
"first" blocker.

	-Ric