Subject: [nfsv4] LAYOUTGET and current stateid.

From: Robert Gordon <[email-masked]>
Date: Sat, 01 Mar 2008 15:45:46 -0600

I've been assuming that it is perfectly valid for a client to
compound the OP_OPEN and OP_LAYOUTGET, such that loga_stateid
'other' would be zero and 'seqid' would be one. (8.2.3)

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 1 Mar 2008 19:16:28 -0500

I haven't heard anyone claim that that would not be valid.

One thing that should be clarified is whether, when there are
restrictions on the stateid seqid value, they apply to the stateid
before or after substitution of the current stateid in the case you
cite.  I would argue that it makes more sense to apply such restrictions
after the substitution and that in this case, the effective stateid
seqid would be zero.  

I don't think that conflicts with the restriction specified in 12.5.2
since that is only applied to LAYOUGETs after the initial one. 

-----Original Message-----
From: Robert Gordon [mailto:[email-masked]] 
Sent: Saturday, March 01, 2008 4:46 PM
To: NFSv4
Subject: [nfsv4] LAYOUTGET and current stateid.

I've been assuming that it is perfectly valid for a client to compound
the OP_OPEN and OP_LAYOUTGET, such that loga_stateid 'other' would be
zero and 'seqid' would be one. (8.2.3)

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Sun, 02 Mar 2008 21:49:37 +0200

> after the substitution and that in this case, the effective stateid

I agree with this interpretation.

> since that is only applied to LAYOUGETs after the initial one. 

If LAYOUTGET sets the current stateid I think it makes sense to allow
a series of LAYOUTGETs and/or LAYOUTRETURNs in the same compound,
all, (or all but the first after OPEN) using the current stateid.

Benny