Subject: Re: [nfsv4] LAYOUTRRETURN and current stateid

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 1 May 2008 08:00:04 -0400

How about:

      and the request's current stateid will be invalidated.
	The server MUST reject with NFS4ERR_BAD_STATEID any
	further use of the current stateid in that COMPOUND
	until the current stateid is re-established by a later
	stateid-returning operation.

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Thursday, May 01, 2008 2:21 AM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] LAYOUTRRETURN and current stateid

On May. 01, 2008, 2:34 +0300, "Mike Eisler" <[email-masked]> wrote:
>   If the operation specified lr_returntype of LAYOUTRETURN4_FILE, then
>   lrs_stateid will represent the layout stateid as updated for this
>   operation's processing; the current stateid will also be updated to
>   match the returned value.  If the last byte of any layout for the
>   current file, client ID, and layout type is being returned and there
>   are no remaining pending CB_LAYOUTRECALL operations for which a
>   LAYOUTRETURN operation must be done as a completing operation,
>   lrs_present MUST be FALSE, and thus no stateid will be returned.
> 
> Unless there are objections, I will add to the last sentence of the 
> above
> paragraph:
> 
>   and the current stateid will be cleared.
> 

I understand where this is coming from but the wording is a bit terse
IMO. By "current stateid" you mean the COMPOUND RPC's current stateid,
right?
Now, what does "clear" mean?
Set to zero, become invalid?
I think it should be invalidated such that any further use of the
current stateid in that COMPOUND will result in NFS4ERR_BAD_STATEID (as
required by section 8.2.3, third bullet point).

Therefore, I suggest this instead:

	and the RPC's current stateid will be invalidated.
	The server MUST reject any further use of the current
	stateid in that COMPOUND with NFS4ERR_BAD_STATEID
	Any further use of the current stateid in that COMPOUND
	until the current stateid is re-established by another
	stateid-returning operation.

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

---

From: Robert Gordon <[email-masked]>
Date: Thu, 01 May 2008 08:29:46 -0500

Mikes original text i thought was clear, and the following
is okay too..

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 16:38:12 +0300

> Mikes original text i thought was clear, and the following

Dave's re-wording looks good to me.
Mike's original text can be a bit confusing to a new comer.
honestly, when I read "the current stateid will be cleared"
the first time I thought it talked about the layout stateid
associated with the file, not with the COMPOUND.  Then
"be cleared", especially to engineers with hardware background,
can mean "set to zero", which is not what you want.  You want
to invalidate it....

-- 
Benny Halevy
Software Architect
Tel/Fax: +972-3-647-8340
Mobile: +972-54-802-8340
US:      +1-412-203-3187
[email-masked]
 
Panasas, Inc.
The Leader in Parallel Storage
www.panasas.com
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 01 May 2008 09:19:58 -0500

> 	stateid-returning operation.

The section describing current stateid mentions setting the
current stateid value to that of the all-zeros special
stateid in those cases that a stateid is not returned by
an operation.  It seems that this language is sufficient for the
case where LAYOUTRETURN is ending the life cycle of a stateid
and there is no valid stateid to return.  Then the use
of the current stateid in this case, when its value is all-zeros
special stateid, would generally return NFS4ERR_BAD_STATEID.

This way, there isn't a need for special language for this case.

So, I would amend Mike's proposed change to be

"and the current stateid will be set to the all-zeros special stateid.
See section 16.2.3.1.2 Current Stateid".

Spencer

---

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 17:31:29 +0300

> This way, there isn't a need for special language for this case.

Oh, I wasn't aware of that.  Thanks!