Subject: Re: [nfsv4] Clarification on Releasing Lock Owner for NFsv4.1

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 17 Jun 2013 17:27:57 -0400

On Fri, May 03, 2013 at 05:33:28PM -0400, J. Bruce Fields wrote:
> On Fri, May 03, 2013 at 08:51:08PM +0000, Myklebust, Trond wrote:
> > On Fri, 2013-05-03 at 16:40 -0400, J. Bruce Fields wrote:
> > > On Fri, May 03, 2013 at 06:31:12PM +0000, Myklebust, Trond wrote:
> > > > On Thu, 2013-05-02 at 15:23 +0800, Srinivas wrote:
> > > > > Hello all,
> > > > > 
> > > > > 
> > > > > RFC 5661 quotes the below regarding the non-usefulness of
> > > > > Release_LockOwner for NFSv4.1
> > > > > 
> > > > > 
> > > > > 
> > > > > o     RELEASE_LOCKOWNER because lock-owners with no associated locks do
> > > > >       not have any sequence-related state and so can be deleted by the
> > > > >       server at will.
> > > > > 
> > > > > A few questions based on the above:
> > > > > 
> > > > > 
> > > > > a) Does it mean that the server can delete the state object and the
> > > > > lock owner as soon as it gets a LOCKU that releases the last lock
> > > > > under that particular owner? Or Is it better to wait for some time and
> > > > > see a freestateid on the last state before going ahead and deleting
> > > > > the state and hence the owner?
> > > > > 
> > > > > 
> > > > > b) What happens if the server is aggressive and deletes the owner
> > > > > immediately after the  LOCKU on the last lock and the client uses the
> > > > > aforementioned deleted state for a further LOCK request? would
> > > > > BAD_STATE_ID be the right error to return in this case and is it fair
> > > > > to assume  that the clients would recover again  by establishing
> > > > > state?
> > > > 
> > > > In drafts 2,3 and 4 of RFC5661, we certainly did have language that
> > > > stated that the server could drop lock state after the last LOCKU. That
> > > > text seems to have been dropped when we added FREE_STATEID in draft 5.
> > > > 
> > > > The final version of RFC5661 states:
> > > > 
> > > > 8.2.4.  Stateid Lifetime and Validation
> > > > 
> > > >    Stateids must remain valid until either a client restart or a server
> > > >    restart or until the client returns all of the locks associated with
> > > >    the stateid by means of an operation such as CLOSE or DELEGRETURN.
> > > >    If the locks are lost due to revocation, as long as the client ID is
> > > >    valid, the stateid remains a valid designation of that revoked state
> > > >    until the client frees it by using FREE_STATEID.  Stateids associated
> > > >    with byte-range locks are an exception.  They remain valid even if a
> > > >    LOCKU frees all remaining locks, so long as the open file with which
> > > >    they are associated remains open, unless the client frees the
> > > >    stateids via the FREE_STATEID operation.
> > > > 
> > > > IOW: basically, it replaces RELEASE_LOCKOWNER with FREE_STATEID...
> > > > 
> > > > I know our client does not yet do this; I'm working on that. I'm not
> > > > sure what the server implementations out there are currently doing in
> > > > that case.
> > > 
> > > Arrrgh.  I just "fixed" the Linux server to do the
> > > destroy-on-last-LOCKU.  Looks like my understanding was out of date.
> > > Time to go revert that....
> > 
> > I'm still confused as to why we need this special case for byte range
> > locks, and why we removed that text in draft 5. We are still applying
> > those removed rules to layout stateids, and so they will currently
> > expire when the last layout segment has been released.
> 
> I'm confused too.
> 
> But it sounds like a client implementing to the above would be within
> its rights to give up when it gets the BAD_STATEID, so I think a careful
> server's stuck hanging on to them?

BTW, bakeathon testing makes it look like the Free BSD client does in
fact trip up on exactly this behavior, and given the above 8.2.4
language I think the client's in the right, so I'm fixing the server not
to toss the lock state on last close.

--b.

---

From: "Noveck, David" <[email-masked]>
Date: Tue, 18 Jun 2013 16:21:10 -0400

> > I'm still confused as to why we need this special case for byte 
> > range locks, and why we removed that text in draft 5. 

Where specifically is the removed text from draft 4 that is being referred to?

> > We are still 
> > applying those removed rules to layout stateids, and so they will 
> > currently expire when the last layout segment has been released.
> 
> I'm confused too.

> > > >    stateids via the FREE_STATEID operation.

The exception regarding stateids associated with byte range locks only applies
to the case of locks lost due to revocation and not to byte range locks  in 
general.  Still, I'm not clear why it is there.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Bruce Fields
Sent: Monday, June 17, 2013 5:28 PM
To: Myklebust, Trond
Cc: Srinivas; Rick Macklem; [email-masked]
Subject: Re: [nfsv4] Clarification on Releasing Lock Owner for NFsv4.1

On Fri, May 03, 2013 at 05:33:28PM -0400, J. Bruce Fields wrote:
> > > > > a) Does it mean that the server can delete the state object 
> > > > > and the lock owner as soon as it gets a LOCKU that releases 
> > > > > the last lock under that particular owner? Or Is it better to 
> > > > > wait for some time and see a freestateid on the last state 
> > > > > before going ahead and deleting the state and hence the owner?
> > > > > 
> > > > > 
> > > > > b) What happens if the server is aggressive and deletes the 
> > > > > owner immediately after the  LOCKU on the last lock and the 
> > > > > client uses the aforementioned deleted state for a further 
> > > > > LOCK request? would BAD_STATE_ID be the right error to return 
> > > > > in this case and is it fair to assume  that the clients would 
> > > > > recover again  by establishing state?
> > > > 
> > > > In drafts 2,3 and 4 of RFC5661, we certainly did have language 
> > > > that stated that the server could drop lock state after the last 
> > > > LOCKU. That text seems to have been dropped when we added FREE_STATEID in draft 5.
> > > > 
> > > > I know our client does not yet do this; I'm working on that. I'm 
> > > > not sure what the server implementations out there are currently 
> > > > doing in that case.
> > > 
> > I'm still confused as to why we need this special case for byte 
> > range locks, and why we removed that text in draft 5. We are still 
> > applying those removed rules to layout stateids, and so they will 
> > currently expire when the last layout segment has been released.
> 
> I'm confused too.
> 
> its rights to give up when it gets the BAD_STATEID, so I think a 
> careful server's stuck hanging on to them?

BTW, bakeathon testing makes it look like the Free BSD client does in fact trip up on exactly this behavior, and given the above 8.2.4 language I think the client's in the right, so I'm fixing the server not to toss the lock state on last close.

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

---

From: Rick Macklem <[email-masked]>
Date: Tue, 18 Jun 2013 19:37:15 -0400 (EDT)

> general. Still, I'm not clear why it is there.
Well, if the server discards a byte range lock stateid as soon as there
are no byte range locks, then for the following application:
- long running process, locks a byte range, unlocks the byte range, locks
  another byte range, unlocks that byte range and keeps doing this many
  many times (think of a database where the locks of byte ranges are records)
The server will have to allocate a new lock_owner/lockstateid every time the
client does a byte range lock, since the previous lock stateid will have been
discarded and the client will have to do something similar for each lock done
with open_to_lock_owner.

Also, since the 4.0 server doesn't discard the lock stateid until there is
a Releaselockowner Op or Close of the associated open, it behaves like the
current 4.1 spec, which doesn't allow the lock stateid to be discarded when
the lock is unlocked. (ie. The discard the lock stateid/lockowner when the
lock is unlocked would result in different semantics from 4.0.)

rick

> language I think the client's in the right, so I'm fixing the server
> not to toss the lock state on last close.
> 
> --b.