Subject: Re: [nfsv4] conflicting lock returns

From: [email-masked]
Date: Mon, 12 Jun 2006 17:58:21 -0400 (EDT)

>>Lessee, looking at the V4 spec, I guess it could be a bit impossible
>>to implement this.  What do clients do now?
>
>Toss it. What else would they do? Can't return it to the app.
>They can printk, I suppose. That sounds productive. :-)

I can see the printk (ie logging it) being useful. A sysadmin can figure
out what machine is using the clientid. (My server has an option on
the nfsstat command that would provide that info, or a sysadmin could
sniff with Ethereal to figure it out.) The lockowner name is less
useful, unless the sysadmin knows how a client formats it. (For example,
on my OpenBSD3.8 client, the first 4 bytes of the lockowner name is the
pid in machine byte order.)

Having said that, my current client doesn't log it and just throws it away.

For the LockT Op, a client can compare clientid with one that it has and,
if there is a match, map lockowner name back to pid, so I see the LockT
Op as having more use for the info.

So, I'd say it's worth getting right, rick

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

---

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

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.

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

Tom.