Subject: Re: [nfsv4] Question on LOCK to new owner and error DENIED

From: Rick Macklem <[email-masked]>
Date: Tue, 18 Sep 2007 15:10:44 -0400 (EDT)

[Steve wrote]
> All, Version 4 (point zero) spec has the following text at section 
> 8.1.5: The client MUST monotonically increment the sequence number 
> for the CLOSE, LOCK, LOCKU, OPEN, OPEN_CONFIRM, and OPEN_DOWNGRADE 
> operations. 
> This is true even in the event that the previous operation that used the 
> sequence number received an error. The only exception to this rule is if 
> the previous operation received one of the following errors: 
> NFS4ERR_STALE_CLIENTID, NFS4ERR_STALE_STATEID, NFS4ERR_BAD_STATEID, 
> NFS4ERR_BAD_SEQID, NFS4ERR_BADXDR, NFS4ERR_RESOURCE, 
> NFS4ERR_NOFILEHANDLE. For "lock to new owner", where an open seqid 
> as well as a lock seqid is provided, some implementations increment both 
> seqids 
> on error DENIED, such that they are both +1 on the retry. Some increment 
> only 
> the open seqid, and this inconsistency leads at times to 
> NFS4ERR_BAD_SEQID if 
> the lock seqid is also bumped. I cannot tell from the spec which case is 
> the correct one. Can anyone shed some light on this for me?

Well, since the Lock Op doesn't return a lock_stateid4 for any error,
including NFS4ERR_DENIED, I'd say that the new lockowner state is not
created on the server. In other words, the state shouldn't even exist,
so incrementing the seqid# for it cannot happen.

After the error, the client will have to do the next Lock Op with
open_to_lock_owner4 and any lock_seqid in that should be ok.

At least IMHO, rick

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 18 Sep 2007 15:35:38 -0400

> open_to_lock_owner4 and any lock_seqid in that should be ok.

Agreed, but it is entirely correct for the client to increment the
open_owner seqid even if the lock_owner hasn't been created: the RFC
makes no exceptions for NFS4ERR_DENIED when it comes to bumping the
sequence id.

Cheers
  Trond

---

From: Steven Huntington <[email-masked]>
Date: Tue, 18 Sep 2007 12:43:30 -0700

Trond, yes, that was obvious to me too.  I was more concerned with the lock
owner sequence, and I think Rick's explanation holds water.  However, I
also note that some implementations ALSO accept the lock sequence bump
after lock_to_open DENIED without complaint as well.  I then am confused
about how the operation AFTER this one knows to accept both (n) and (n+1),
or if I have gone insane and am COMPLETELY missing something.

Cheers,

Steve Huntington, IBM San Jose

Phone:       (408) 463-2716 (T/L 543-216)
Fax:         (408) 463-4727
Office:      SVL 90-D215
Internet:    [email-masked]
Lotus Notes: Steven Huntington/San Jose/IBM@IBMUS

===========

Cheers
  Trond

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 18 Sep 2007 15:48:26 -0400

> makes no exceptions for NFS4ERR_DENIED when it comes to bumping the

Yeah, that the open_owner seqid should be incremented was never in
doubt.  You could argue about how to apply the statement in 8.1.5 to the
lockowner seqid in this case ("the first request issued for any given
lock_owner is issued with a sequence number of zero").  I think I'd go
with zero.  But in practice there's no reason to require a particular
value in the seqid field of open_to_lockowner, so I'd file a bug against
any server that returns NFS4ERR_BAD_SEQID if it's nonzero (as the linux
server unfortunately used to).

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 18 Sep 2007 15:50:58 -0400

> or if I have gone insane and am COMPLETELY missing something.

I don't think a server should check that field at all.  There's no
reason to, since the openowner seqid already provides the necessary
sequencing.  All it need do is record the seqid for future use in case
of success.

--b.

---

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 18 Sep 2007 16:01:12 -0400

Everyone here seems to be assuming that we have the case where the
lockowner is not created yet.  That's one case, but there's also the
case in which the lockowner exist at the time the LOCK operation is done
(no locks by this owner for this file but some, possibly in the past for
another open file).  In that case, FWIW, we bump the lock owner
sequence.

I agree that in the case where the owner is new to the server the owner
is not created and thus no effective sequence update is done.

-----Original Message-----
From: J. Bruce Fields [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 3:51 PM
To: Steven Huntington
Cc: [email-masked]
Subject: Re: [nfsv4] Question on LOCK to new owner and error DENIED

--b.

---

From: Rick Macklem <[email-masked]>
Date: Wed, 19 Sep 2007 14:52:50 -0400 (EDT)

> another open file).  In that case, FWIW, we bump the lock owner
Hmm, for the case where the lockowner already exists and is associated 
with the open_owner referred to by the open_to_lock_owner4 Lock Op 
request's open_stateid, I think there can only be two responses from a 
server:
1 - Accept any lock_seqid value (assuming the open_seqid value was
     correct) and save that value + 1 in the state (assuming that it
     isn't failing. (I think this is what Dave says Netapp does?)
OR
2 - Fail the request because the lock_stateid4 for that lock_owner already
     exists and the client should have used exist_lock_owner4.

My server does #1.

I mention this because I'm not sure rfc3530 ever specifies which of
these should be accepted and it might be nice to clarify it?

rick

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Sep 2007 15:07:22 -0400

> these should be accepted and it might be nice to clarify it?

Just out of interest: what error would you return in #2?

Trond

---

From: Rick Macklem <[email-masked]>
Date: Wed, 19 Sep 2007 17:03:30 -0400 (EDT)

> Just out of interest: what error would you return in #2?
Part of the reason I chose #1 was that none of the errors listed seemed
appropriate. Btw, in case I wasn't clear (as usual:-), it is the case
where clients choose to not follow the advice of the para. you quoted
to-day and use the open_to_lock_owner4 case for other than the
"...first LOCK operation...".

A couple of old discussions that might be relevant:
http://www.nfsv4.org/nfsv4-wg-archive-feb-03-feb-05/0178.html and 
1071.html.

rick

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Sep 2007 17:10:46 -0400

> http://www.nfsv4.org/nfsv4-wg-archive-feb-03-feb-05/0178.html and 

Right. I agree with your implication that the client is really in error
when it calls open_to_lock_owner4 after it has already obtained a
stateid for that <lock_owner,open_owner,file>, so case #2 should really
be allowed by the protocol. Like you, however, I'm not sure what error
would be appropriate.

NFS4ERR_INVAL seems incorrect, since the problem isn't really that you
have an invalid or unsupported argument. NFS4ERR_BAD_SEQID would be
ambiguous: the client would normally assume that applied to the
open_seqid.

Would it perhaps be appropriate to use NFS4ERR_LOCKS_HELD if the client
actually holds an active lock, and otherwise to permit the
open_to_lock_owner?

Trond

---

From: Rick Macklem <[email-masked]>
Date: Wed, 19 Sep 2007 17:51:27 -0400 (EDT)

[stuff snipped]
> actually holds an active lock, and otherwise to permit the
Except that it isn't listed as an error for the Lock Op:-)

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Sep 2007 18:02:58 -0400

> Except that it isn't listed as an error for the Lock Op:-)

Errata? I'm just trying to start a debate on what might be useful here. 

AFAIK, the same problem exists in 4.1...

  Trond

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 19 Sep 2007 21:15:50 -0400

We're doing an error review.  Problems in v4.1 can still be addressed. 

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Wednesday, September 19, 2007 6:03 PM
To: Rick Macklem
Cc: Noveck, Dave; J. Bruce Fields; Steven Huntington; [email-masked]
Subject: RE: [nfsv4] Question on LOCK to new owner and error DENIED

On Wed, 2007-09-19 at 17:51 -0400, Rick Macklem wrote:
> > Would it perhaps be appropriate to use NFS4ERR_LOCKS_HELD if the 
> > client actually holds an active lock, and otherwise to permit the 
> > open_to_lock_owner?
> >

  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Sep 2007 21:20:58 -0400

> We're doing an error review.  Problems in v4.1 can still be addressed. 

I know. Consider this a proposal. :-)

Trond