Subject: [nfsv4] layout stateid issue

From: Mike Eisler <[email-masked]>
Date: Thu, 21 Feb 2008 08:56:39 -0800 (PST)

A question came up at the Austin bake-a-thon yesterday.

Let's say a client uses an OPEN stateid in LAYOUTGET, and gets back
a layout stateid. Later, it issues a LAYOUTRETURN which returns
another layout stateid. Let us call this stateid L.

Sometime later (e.g. days later), the client uses L in LAYOUTGET.

Question:

- Between the time L was returned and used, is the server allowed to
  delete L (and thus return NFS4ERR_BAD_STATEID)?

Or is the server required to keep the stateid around until the client
issues FREE_STATEID?

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

---

From: Robert Gordon <[email-masked]>
Date: Thu, 21 Feb 2008 12:36:11 -0600

> Or is the server required to keep the stateid around until the client

I'd return NFS4ERR_BAD_STATEID, iff the client had no outstanding
layout segments,  since in 18.43.3 we say

"The loga_stateid field specifies a valid stateid. If a layout is not  
currently
held by the client, the loga_stateid field represents a stateid  
reflecting the
correspondingly valid open, record lock, or delegation stateid."

presumably the client does not hold a layout since it returned it,  
however
if it still does have a portion of the file the layout stateid should  
remain valid...

--
Robert
"Don't Take Anything Personally"

---

From: Mike Eisler <[email-masked]>
Date: Thu, 21 Feb 2008 16:33:02 -0800 (PST)

I am going assume we have consensus on this. 

I also noticed that we do not appear to have any text that explicitly
says that in order for LAYOUTCOMMIT to be sent, the client MUST
have a layout. Consensus around the room at the bake-a-thon is that it
is a MUST.

So when I write the text reflecting the below, I will write text that
reflects the above.