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

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

The problem here is we have something that was not tightly specified.
Our hope is that the formal review process will catch things like this,
although this one just doesn't have relevance to v4.1.
 
I agree with Rick about the new lockowner case, and the text would
certainly be better if it said "number or numbers" or explicitly
excluded the lockowner seqid on the lock-to-new-owner case.  But given
the choice of how to interpret this in the absence of that clatiry, I'd
say it is much easier to believe that the former was the intention (with
or "or numbers" unintentionally dropped), then that the latter was
intended and somehow not mentioned.

	-----Original Message-----
	From: Steven Huntington [mailto:[email-masked]] 
	Sent: Tuesday, September 18, 2007 4:11 PM
	To: Noveck, Dave
	Subject: RE: [nfsv4] Question on LOCK to new owner and error
DENIED

	Dave,
	
	This scenario is exactly what happened. I had an existing lock
owner for fileA, who attempted a lock of fileB for the first time. The
lockowner seqid was already established, and I *ASSUMED* that on the
new-locker-DENIED that both the open and lock seqids should be
incremented. So maybe I was premature in agreeing with Rick and need to
rethink this some more. I apologize to all for not COMPLETELY defining
the scenario.
	
	In this case it seems that whatever the behavior for the
lockowner seqid, it needs to be CLEAR. Rick's point is a good one, in
that the lockowner has not been AFFECTED by the deny case, but it did
previously exist and the RFC does not make this clear as it refers to
"the sequence number" when there are two here.
	
	And again, I've seen some released server implementations accept
either case, even in the presence of this new-locker DENIED scenario.
That's the part that bugs me.
	
	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
	
	Dave wrote:
	=============
	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.

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 18 Sep 2007 16:47:07 -0400

The Linux client assumes that if the open_to_lockowner case fails with
an error, then the lockowner is not established.

When we retry the lock request, we therefore re-issue an
open_to_lockowner, with a lockowner seqid of 0. As I stated previously,
the open seqid will have been bumped according to the rules specified in
RFC3530.
I seem to recall from previous conversations with Spencer that Solaris
does the same.

Cheers
  Trond

On Tue, 2007-09-18 at 16:30 -0400, Noveck, Dave wrote:
> Our hope is that the formal review process will catch things like
> this, although this one just doesn't have relevance to v4.1.
>  
> the choice of how to interpret this in the absence of that clatiry,
> I'd say it is much easier to believe that the former was the intention
> (with or "or numbers" unintentionally dropped), then that the latter
> was intended and somehow not mentioned.
>         
>         owner for fileA, who attempted a lock of fileB for the first
>         time. The lockowner seqid was already established, and I
>         *ASSUMED* that on the new-locker-DENIED that both the open and
>         lock seqids should be incremented. So maybe I was premature in
>         agreeing with Rick and need to rethink this some more. I
>         apologize to all for not COMPLETELY defining the scenario.
>         
>         lockowner seqid, it needs to be CLEAR. Rick's point is a good
>         one, in that the lockowner has not been AFFECTED by the deny
>         case, but it did previously exist and the RFC does not make
>         this clear as it refers to "the sequence number" when there
>         are two here.
>         
>         And again, I've seen some released server implementations
>         accept either case, even in the presence of this new-locker
>         DENIED scenario. That's the part that bugs me.
>         
>         Cheers,
>         
>         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

---

From: Steven Huntington <[email-masked]>
Date: Tue, 18 Sep 2007 13:56:04 -0700

Trond, in this case the lockowner *IS* established, but has no lock state
for *THIS* particular file open state.  The rules are not PRECISE regarding
the lock state for an established locker that is new to the particular
file.

Cheers,

Steve Huntington

===============

Cheers
  Trond

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 18 Sep 2007 17:07:45 -0500

> I seem to recall from previous conversations with Spencer that Solaris

Correct.

Spencer

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 18 Sep 2007 19:20:16 -0400

Yes they are, and this has been discussed on this list before:

open_to_lockowner is there in order to establish a locking stateid.
That stateid is per lockowner, per open_owner, per file (i.e. it is a
triplet).
It doesn't matter if the lockowner is established on some other file or
open owner, you still need to go through the open_to_lockowner jig in
order to get a stateid that is valid.

Cheers
  Trond

On Tue, 2007-09-18 at 13:56 -0700, Steven Huntington wrote:
> Trond, in this case the lockowner *IS* established, but has no lock
> state for *THIS* particular file open state. The rules are not PRECISE
> regarding the lock state for an established locker that is new to the
> particular file.
> 
> Cheers,
> 
> Steve Huntington
> 
> ===============

---

From: Steven Huntington <[email-masked]>
Date: Tue, 18 Sep 2007 16:27:29 -0700

So, just to be clear, *YOUR* position is that therefore: for
open_to_lock_owner, if it is DENIED, that the lock owner seqID is *NOT*
incremented REGARDLESS of whether it has been previously established or
not?

Cheers,

=====================

Cheers
  Trond

---

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

That is the position that was *AGREED UPON* the last time this issue was
discussed on this list. Please consult the archives.

If you read page 22 of RFC3530, then it states quite plainly that the
lock_stateid is tied to the lock_owner+lock_seqid, and that pair is in
turn tied to the open_stateid/open_seqid that was used in the
open_to_lock_owner4 structure.

IOW: the lock_seqid and lock_stateid are established as part of the
open_to_lock_owner4, and are both tied to the state that is already
established by the open_stateid/open_seqid. No lock_stateid == no
lock_seqid.

Trond

On Tue, 2007-09-18 at 16:27 -0700, Steven Huntington wrote:
> open_to_lock_owner, if it is DENIED, that the lock owner seqID is
> *NOT* incremented REGARDLESS of whether it has been previously
> established or not? 
> 
> Cheers,
>

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 19 Sep 2007 08:07:19 -0400

> That is the position that was *AGREED UPON* the last time 
> this issue was discussed on this list. Please consult the 
> archives.

I have checked the archives, perhaps not exhaustively but as well as I
could, and have found no discussion of the question Steven raised.

There seem to be three questions here:

1) What is supposed to happen when LOCK-otl4 is used in a situation in
which the specified lockowner is not known to the server and the request
is DENIED.

The answer which I do think was agreed upon and has been discussed as
you have stated, is that that lockowner is still (after the request) not
known to the server and since the lockowner is not known there can be no
seqid associated with.  Therefore, in this case, there has been no
increment of the seqid associated with the lockowner and the client when
next introducing that lockowner to the server does not have to take
account of the failed LOCK.

2) Whether, when a lockowner already exists on the server the client
when getting the first LOCK for a particular lockowner given open file
(BTW, pg 22 of RFC3530 just says the first LOCK after the open --
another case of lack of formal review), it must do a LOCK-otl4 to get a
lock stateid.

This is clearly addressed in the spec as you say and is not in dispute.

3) When the client issues a LOCK-otl4 as in (2) above, and the request
is denied, what happens to the lockowner seqid?  Specifically, since it
existed previously, it continues to exist and since it had a seqid
previously, it might be incremented or not.  As Steven has said, the
spec is not really definitive on this issue and people can read it in
various ways.

Although you address (1) and (2) in your mail, I don't see where (3) is
addressed.  I've sated my opinion (it is the behavior of our server) and
would like to know your view on this.  Do you expect the lockowner seqid
to be incremented, and if not, what is your reason for adopting that
position?   

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]] 
Sent: Tuesday, September 18, 2007 7:58 PM
To: Steven Huntington
Cc: [email-masked]
Subject: RE: [nfsv4] Question on LOCK to new owner and error DENIED

Trond

On Tue, 2007-09-18 at 16:27 -0700, Steven Huntington wrote:
> It doesn't matter if the lockowner is established on some other file 
> or open owner, you still need to go through the open_to_lockowner jig 
> in order to get a stateid that is valid.
> 
> Cheers
>  Trond
>

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 19 Sep 2007 09:12:55 -0400

> could, and have found no discussion of the question Steven raised.

There is at least

   http://www1.ietf.org/mail-archive/web/nfsv4/current/msg01250.html

and I remember an online discussion a couple of years back among
yourself, Mike Eisler, Rick(?) and myself about the whole nature of the
lock stateid. I'm still trying to find that in the archives (I was
hoping I could search on the keyword "triplet", but the IETF archives
apparently don't allow you to search for keywords in the mail text).

> to be incremented, and if not, what is your reason for adopting that

        "This structure is used for the first LOCK operation done for an
        open_owner4.  It provides both the open_stateid and lock_owner
        such that the transition is made from a valid open_stateid
        sequence to that of the new lock_stateid sequence.Using this
        mechanism avoids the confirmation of the lock_owner/lock_seqid
        pair since it is tied to established state in the form of the
        open_stateid/open_seqid."

Conversely, until the open_to_lockowner4 has been successful, we are
clearly in an unconfirmed state w.r.t. the lock_owner/lock_seqid pair:
there are no descriptions anywhere in RFC3530 of any errors that state
that they confirm a lock_owner/lock_seqid pair apart from NFS4ERR_OK.

It doesn't matter if the lock_owner has been confirmed on another file
or another open_owner, you are still in an unconfirmed state for this
<lock_owner,open_owner,file> triplet. The fact that you have no stateid
enforces this, by ensuring that you _must_ re-issue the
open_to_lockowner4 request.

Trond

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 19 Sep 2007 12:54:50 -0500

> open_to_lockowner4 request.

Agreed.  As you have stated before, it is the combination of
file/open_owner/lock_owner that is being bound/associated as part
of the initial open_to_lockowner4.

Spencer