Subject: Re: [nfsv4] conflicting lock returns

From: [email-masked]
Date: Tue, 13 Jun 2006 12:25:34 -0400 (EDT)

> 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?)

Ok, yep, agreed. So long as this is only referring to Lock and not LockT
as well. (Although the original question referred to Lock, I had a hunch
that LockT might be considered in the "same boat".)

For LockT, the client can recognize the clientid is one issued to it and
can translate the owner name back to pid for the F_GETLK return.

rick

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

---

From: "Talpey, Thomas" <[email-masked]>
Date: Tue, 13 Jun 2006 14:21:32 -0400

>can translate the owner name back to pid for the F_GETLK return.

Ahhhhh - hmm this could be a money wrench in Bruce's plans
after all then.

For a (shall we say) simple locking client didn't retain lock owner
information at all and relied on the server to remember it, it's
important to parrot back at least the client's own clientid, with
its associated opaque owner.

I don't think this is necessary for conflicting locks from *other*
clients, nor for ordinary LOCK requests, but once it's implemented
for LOCKT, it's pretty much a done deal?

(It would probably be worth sticking a sentence in the spec
somewhere that justified this extra payload on failed returns)

Tom.