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

From: Srinivas <[email-masked]>
Date: Thu, 2 May 2013 15:23:19 +0800 (SGT)

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?

thanks for your time,
Srinivas.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 3 May 2013 18:31:12 +0000

On Thu, 2013-05-02 at 15:23 +0800, Srinivas wrote:
> 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) 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.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 3 May 2013 16:40:56 -0400

> sure what the server implementations out there are currently doing in

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

--b.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 3 May 2013 20:51:08 +0000

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

NetApp

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 3 May 2013 17:33:28 -0400

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

--b.

---

From: Frank S Filz <[email-masked]>
Date: Fri, 3 May 2013 15:03:26 -0700

> server's stuck hanging on to them?

Just because a client has released the last lock on a file doesn't mean
it's necessarily done doing locking on that file.

RELEASE_LOCKOWNER would imply the client is done a lock stateid since the
stateid encompasses file and lock owner.

Frank

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 3 May 2013 22:11:23 +0000

On Fri, 2013-05-03 at 15:03 -0700, Frank S Filz wrote:
> Just because a client has released the last lock on a file doesn't
> mean it's necessarily done doing locking on that file.
> 
> RELEASE_LOCKOWNER would imply the client is done a lock stateid since
> the stateid encompasses file and lock owner.

So? What's the huge deal about doing an open_to_lockowner? It's a few
extra bytes on the wire as part of the new LOCK request.

How does the client magically know whether or not the application will
decide to lock the file again before closing the file anyway?

Trond

NetApp

---

From: Frank S Filz <[email-masked]>
Date: Fri, 3 May 2013 15:15:50 -0700

"Myklebust, Trond" <[email-masked]> wrote on 05/03/2013
> extra bytes on the wire as part of the new LOCK request.

A thought though, I know the Linux client keeps track of whether it has any
locks left. Does every client do so? If not, how does the client know it
has to do an open new lockowner? And especially if not all servers release
the stateid when LOCKU releases the last lock.

> decide to lock the file again before closing the file anyway?

Sure, the client doesn't know the application is done with locks until the
file is closed.

Frank

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 3 May 2013 22:24:08 +0000

On Fri, 2013-05-03 at 15:15 -0700, Frank S Filz wrote:
> A thought though, I know the Linux client keeps track of whether it
> has any locks left. Does every client do so? If not, how does the
> client know it has to do an open new lockowner? And especially if not
> all servers release the stateid when LOCKU releases the last lock.
> 
If a client doesn't track the locks it holds, then it won't be able to
recover them in case of a server reboot. It is therefore hard to imagine
a client not wanting to do so.

NetApp

---

From: Frank S Filz <[email-masked]>
Date: Fri, 3 May 2013 15:47:43 -0700

> a client not wanting to do so.

Duh, good point...

Ok, so the only question remains, should the client assume the server will
drop the stateid on last lock release, or assume it doesn't and interpret
NFS4ERR_BAD_STATEID as oh, this server DID drop the stateid?

Frank

---

From: "Noveck, David" <[email-masked]>
Date: Mon, 6 May 2013 16:33:43 -0400

>      server at will.

The statement is true but misleading.  Lockowners in NFSv4 never have any

sequence-associated state.  The need to maintain such sequence-associated

state is why RELEASE_LOCKOWNER was created, and the absence of such sequence-

associated state is the reason it was dumped from v4.1.

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

It doesn't mean that.

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

Typically, the state deletion is more likely to happen as a result of CLOSE.

A FREE_STATEID is only necessary when lock revocation makes CLOSE undoable.

> 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

Yes.

> and is it fair to assume  that the clients would recover again  by establishing state?

You might try this at Connectathon.  Personally,  I can't see this being such  a memory
issue that one might choose to court possible interoperability problems, despite the
fact that the recovery you mention is one that the client could do.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Srinivas
Sent: Thursday, May 02, 2013 3:23 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [nfsv4] Clarification on Releasing Lock Owner for NFsv4.1

Hello all,

      server at will.

thanks for your time,
Srinivas.

---

From: Rick Macklem <[email-masked]>
Date: Mon, 6 May 2013 18:30:19 -0400 (EDT)

David Noveck wrote:
> > > not have any sequence-related state and so can be deleted by the >
> > server at will. The statement is true but misleading. Lockowners in
> > NFSv4 never have any sequence-associated state. The need to maintain
> > such sequence-associated state is why RELEASE_LOCKOWNER was created,
> > and the absence of such sequence- associated state is the reason it
> > was dumped from v4.1.
> 
> > lock owner as soon as it gets a
> 
> It doesn’t mean that.
Btw, a client can run into this situation when the OPEN is inherited
from a parent process that is long running (system daemon) that doesn't
CLOSE the OPEN, but keeps forking different children,
where the client uses a new lockowner4 for each child's pid for byte range
locking. (The client does know when that child process has exited and the
lockowner/lock_stateid can go away safely. That is when the FreeBSD client
does a ReleaseLockOwner or FreeStateID.)

> > immediately after
Not the FreeBSD one. It will expect the lock_stateid to keep working
until it does a FreeStateID or a Close of the associated Open.

rick, who is never at connectathon

> 
> 
> You might try this at Connectathon. Personally, I can’t see this being
> such a memory
> 
> From: [email-masked] [ mailto:[email-masked] ] On
> Behalf Of Srinivas
> To: [email-masked]
> Cc: [email-masked]
> to assume that the clients would recover again by establishing state?
> 
> 
> 
> 
> 
> thanks for your time,
> Srinivas.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4