Subject: [nfsv4] re: initial lock seqid after failure

From: [email-masked]
Date: Tue, 9 Nov 2004 12:03:15 -0500 (EST)

> 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".

That makes sense to me. I vaguely recall a previous discussion I had w.r.t.
the lockowner seqid in open_to_lockowner and I was told it was just the
initial value for the seqid. When I pointed out the sentence in 8.1.5 that
states the first request will use a value of 0, I was told "that isn't
what is being done". To me, if the lockowner is "established" the client
wouldn't use open_to_lockowner, but exist_lock_owner. And since this requires
the lock_stateid that is only returned for the non-error case, I support the
"not established" concept for all error cases.

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

True, but I don't see this as relevent to the error cases, since there isn't a
lock_stateid yet.

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

Not to me. See above.

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

For my server, it will only check the open_seqid for the open_to_lock_owner
case, so it doesn't care what the lock_seqid is. It only uses it as the
initial value for the state for the successful case, where the stateid is
created.

Requiring it to be incremented when a retry after an error is replied seems
unnecessarily restrictive to me, but my server won't mind.

> 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.
> "

If this rule was actually used, there would be no need for the lock_seqid
field in the open_to_lock_owner, as I understand it.

Hope you had fun at the bakeathon, rick

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

---

From: "William A.(Andy) Adamson" <[email-masked]>
Date: Tue, 09 Nov 2004 12:37:36 -0500

> initial value for the state for the successful case, where the stateid is

the linux server does the same. we don't remember new lockowners in the error 
case.

-->Andy