Subject: [nfsv4] initial lock seqid after failure

From: eric kustarz <[email-masked]>
Date: Fri, 05 Nov 2004 12:12:04 -0800

During the last bakeoff in Ann Arbor, an edge case regarding the lock 
seqid came up.

We ran into the case where the client was trying to create a new 
lockowner using the 'struct open_to_lock_owner4' transition, but the 
server returned an error back to the client (i believe it was OPENMODE, 
but DENIED works as well).

Now the client needs to bump the open seqid, but what about the lock seqid?

At the bakeoff, i thought we didn't need to bump the lock seqid, 
thinking the lockwoner/lock seqid wasn't "established".

But the 'struct open_to_lock_owner4' avoids the necessity of confirming 
the lock seqid for a new lockowner (check out the end of section 2.2).

So the lockowner/seqid is in effect "established" as soon as the server 
sees it, regardless if it returns an error.

So this is what we should see OTW:
LOCK(open seqid=X, lock seqid=Y, lockowner=LO1) --->
	<----- BADOWNER
LOCK(open seqid=X+1, lock seqid=Y+1, lockowner=LO1) --->

And somewhat related, section 8.1.5 states:
"
The first request issued for any given lock_owner is
    issued with a sequence number of zero.
"

Though that's not a MUST.

eric

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