Subject: [nfsv4] client re-use of lock_owner name

From: [email-masked]
Date: Thu, 19 May 2005 16:25:29 -0400 (EDT)

I just ran into this case when testing a very green client I've started
to work on:
"P1" on client:
- Opened "xx" with lock_owner4 name "P1" with seqid# 0
  - got a sequence of seqid#s started with OpenConfirm
  - did assorted Ops on "xx"
  - Closed OpenStateid for the above Open
a little later
- Opened "yy" with lock_owner4 name "P1", but with a fresh seqid# of 0

At this point my server replied NFS4ERR_BADSEQID.

Now, looking at the RFC (Sec. 8.1.7 and 8.1.8), it indicates the server
can choose to release the lock_owner when there is no outstanding state
associated with it, but doesn't seem to clarify if/when the client can
do something similar (aka forget the seqid#).

I've already changed my client to hold onto the lock_owner seqid# until
the associated process terminates (at the least it will reduce the number
of OpenConfirms required), but I am wondering what the correct server
response is for the above case?
Door #1 - NFS4ERR_BADSEQID as I currently do
OR
Door #2 - re-initialize the seqid# and require an OpenConfirm, since no state
    is currently associated with the open lock_owner

I am now leaning towards Door #2, since it seems harmless and would accomodate
clients that might choose to re-use lock_owner names.

So, should I take Door #1 or Door #2? rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 19 May 2005 16:47:32 -0400

> So, should I take Door #1 or Door #2? rick

You might be able to do Door #2 when NFSv4.1 sessions are implemented,
but in minor version 0, the seqid is there in order to allow the server
to detect replayed requests so that it can offer correct only-once
semantics.
If the client were to be allowed to forget the seqid as you suggest,
then some new mechanism would be needed in order to tell the server that
this is not a replay of the initial OPEN request.

So Door #1 looks correct for minor version 0.

Cheers,
  Trond