Subject: [nfsv4] conflicting lock returns

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 8 Jun 2006 14:19:14 -0400

The LOCK operation returns information about the conflicting lock
(including the stateowner).  It's not obvious to me how this would be
useful to a client--posix interfaces, at least, don't have much use for
it (and they only know about local uid's anyway).

Is this a windows thing?  What was the original motivation for including
that information in the LOCK response?

I'm just wondering because it's one of the messier pieces of our
server's lock implementation, so it's tempting to cheat a bit.

--b.

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

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 08 Jun 2006 14:30:53 -0400

Unix thing, as far as I know.  If I want to lock a file a someone has
it locked for longer than I think it should, I want to hunt him/it/her down.

alingo 518$ lckd
Lock Daemon Test Interface

Type help to list the available commands.

LCKD> open /home/werme/foo 2
fd = 3
LCKD> lock 3 excl set 1 2
ERROR: Permission denied
errno = 13
LCKD> test 3 excl set 1 2
Locked by pid 2594427, start 1, len 2

The only catch here is that pid 2594427 is on another system.  At least
with a pid that large, I can target certain cluster nodes.

or 11% lckd
Lock Daemon Test Interface

Type help to list the available commands.

LCKD> open /home/werme/foo 2
fd = 3
LCKD> lock 3 excl set 1 2   
LCKD> 
Stopped
or 12% ps | grep lck
   2594427 pts/10   T        0:00.00 lckd
   2594529 pts/10   S  +     0:00.00 grep lck

   -Ric Werme
-- 
Eric (Ric) Werme         |  [email-masked]
Hewlett-Packard Co.      |  http://werme.8m.net/

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 08 Jun 2006 15:53:18 -0400

How did you know what pid it is? A denied lock returns the
shorthand clientid and the opaque owner blob. If it's your
clientid, you know what that means, but what if it's not?
The shorthand clientid isn't very useful either, come to think
of it.

I'm somehow inclined to say Bruce can maybe cheat, because
it's rather likely that conflicts won't originate from the same
client, and therefore are truly opaque. Counterexample?

Tom.

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Thu, 08 Jun 2006 15:59:44 -0400

> The shorthand clientid isn't very useful either, come to think

consider a local lock in conflict, or a lock held by another lock manager 
(LOCKD, samba) - in these cases there is no clientid/opaque owner blob.

-->Andy

---

From: Eric Werme USG <[email-masked]>
Date: Thu, 08 Jun 2006 16:47:35 -0400

How did you know what pid it is?

I'm sorry - I left out a rather important point.  My example was using
NFS V3 (NLM V4) which includes a field for a pid.  That was a Unix-centric
thing NFS V4 wanted to get away from.  The main point of my reply was
the Unix history behind the feature.

LCKD> test  3 excl set 1 2
Locked by pid 2610168, start 1, len 2

We still have the cretinous user level lock daemon, hence the RPC call/call
style exchange:

$ tcpdump -Nts300 port 2717 or port 3868
...
alingo.5acd756a > anw.nlm-v4: 160 call test_msg cookie 0xf excl
    lock: {"alingo..." svid 70461  l_offset 1  l_len 2}
and.179c5915 > alingo.nlm-v4: 80 call test_res cookie 0xf  stat denied
    holder: {excl svid 2610168  l_offset 1  l_len 2} (DF)

The lckd hack does the following to get the data:

    if (fcntl(fd,F_GETLK,&fls) == -1) {
        perror("ERROR");
        printf("errno = %d\n",errno);
    }
    if (fls.l_type == F_UNLCK)
	printf("Lock available on that segment\n");
    else
	printf("Locked by pid %d, start %d, len %d\n",
	       fls.l_pid, fls.l_start, fls.l_len); 

Lessee, looking at the V4 spec, I guess it could be a bit impossible
to implement this.  What do clients do now?

RFC 3530 says:
     clientid4       typedef uint64_t        clientid4;

     struct lock_owner4 {
             clientid4     clientid;
             opaque        owner<NFS4_OPAQUE_LIMIT>;
     };

     struct LOCK4denied {
             offset4         offset;
             length4         length;
             nfs_lock_type4  locktype;
             lock_owner4     owner;
     };

     union LOCKT4res switch (nfsstat4 status) {
      case NFS4ERR_DENIED:
              LOCK4denied    denied;
      case NFS4_OK:
              void;
      default:
              void;
     };

	-Ric Werme

---

From: "Talpey, Thomas" <[email-masked]>
Date: Thu, 08 Jun 2006 16:56:35 -0400

>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. :-)

Tom.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 8 Jun 2006 16:42:51 -0400

> (LOCKD, samba) - in these cases there is no clientid/opaque owner blob.

Yeah, I was forgetting that case. So the conflict lock could be:

	1. owned by a non-nfsv4 process on the server, in which case the nfs
	   server has to return something bogus;
	2. owned by the a different nfsv4 client, in which case the
	   server could return something, but the client probably can't
	   use it; or
	3. owned by another process on the same client; though in this
	   case the client may already know about the conflict anyway.

So as a server implementer I'm inclined not to worry a lot about getting
this right....

--b.