Subject: Re: [nfsv4] FREE_STATEID & open files question

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 2 Jul 2013 11:24:22 -0400

On Tue, Jun 25, 2013 at 02:07:12PM +0000, Myklebust, Trond wrote:
> On Tue, 2013-06-25 at 07:28 -0400, Saul Tamari wrote:
> > Hi,
> > 
> > When I read 18.38.3 I see the following:
> > The FREE_STATEID operation is used to free a stateid that no longer
> > has any associated locks (including opens, byte-range locks ...)
> > 
> > My question is:
> > Does a client need to send a FREE_STATEID after closing a file with
> > the open file's stateid?
> > What about calling FREE_STATEID with byte-range-lock stateid after a
> > CLOSE was called?
> > 
> > My understanding is that after a CLOSE all stateid's are freed, am I
> > wrong about this?
> 
> You are correct.
> 
> FREE_STATEID is only needed in recovery situations (when the server sets
> the SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED,
> SEQ4_STATUS_EXPIRED_SOME_STATE_REVOKED, SEQ4_STATUS_ADMIN_STATE_REVOKED,
> or SEQ4_STATUS_RECALLABLE_STATE_REVOKED flags (see RFC5661 section 8.3,
> section 8.4.3, section 8.5 and section 18.46.3).
> 
> FREE_STATEID is also used in those situations where RELEASE_LOCKOWNER
> would be used in minor version 0 (see RFC5661 section 8.2.4).

Saul, in case it's useful, I wrote a simple pynfs test for 4.1 server
behavior in the presence of a client that doesn't send a timely
delegreturn--the test expects the server to set
SEQ4_STATUS_RECALLABLE_STATE_REVOKED until FREE_STATEID is sent.

	git clone git://linux-nfs.org/~bfields/pynfs.git
	cd pynfs
	./setup.py build
	./nfs4.1/testserver.py server:/export/testtree --maketree --rundeps DELEG8

It shouldn't depend on special behavior of the Linux server; let me know
if you find otherwise.

--b.

---

From: Saul Tamari <[email-masked]>
Date: Tue, 2 Jul 2013 13:16:36 -0400

Thanks Bruce,

I'll have a go with this once I get my server to work in a reasonable way.

Saul

---

From: Saul Tamari <[email-masked]>
Date: Tue, 2 Jul 2013 14:13:42 -0400

I still don't understand how this works.
The SEQUENCE description (18.46.3.) says the following about one of
the sr_status_flags:

SEQ4_STATUS_EXPIRED_ALL_STATE_REVOKED
When set, indicates that the lease has expired and as a result the
server released all of the client's locking state.  This status
bit remains set on all SEQUENCE replies until the loss of all such
locks has been acknowledged by use of FREE_STATEID (see
Section 18.38), or by establishing a new client instance by
destroying all sessions (via DESTROY_SESSION), the client ID (via
DESTROY_CLIENTID), and then invoking EXCHANGE_ID and
CREATE_SESSION to establish a new client ID.

Does that mean that after a client's lease has expired the server has
to keep all the expired stateid until they are ack'd by FREE_STATEID?
What happens if this client will never contact the server again?

Thanks (sorry for the late response),
Saul

On Tue, Jun 25, 2013 at 10:07 AM, Myklebust, Trond
<[email-masked]> wrote:
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> [email-masked]
> www.netapp.com

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 2 Jul 2013 16:59:57 -0400

> What happens if this client will never contact the server again?

The server *can* hang on to all that state, but it can also be harsh and
just throw away all the client's state on expiry, in which case the
client will get BADSESSION on its next attempt to use the session:

	http://tools.ietf.org/html/rfc5661#section-8.4.3

FREE_STATEID allows the server to be more forgiving and hang on to just
the session state while revoking locks as necessary (for example, to
allow progress by clients requesting conflicting locks).

(The Linux server currently takes the easy way out and throws away all
state the moment the a lease period passes without any renewal.)

--b.