Subject: [nfsv4] Minor issues with draft-18

From: [email-masked]
Date: Mon, 31 Dec 2007 15:49:47 -0500

12.5.3.  Layout Stateid
 
   The client MUST always use a seqid that was returned by the server in
   a LAYOUTGET or LAYOUTRETURN operation,

should read either "response" or "reply" not  "operation".

   For LAYOUTGET
   results, if the client is not using the forgetful model
   (Section 12.5.5.1), it MUST first update its record of what ranges of
   the file's layout it has before using the seqid.  For LAYOUTRETURN
   results, the client MUST cease any I/O on the affected range and
   delete the range from its record of what ranges of the file's layout
   it has before using the seqid. 

I do not understand why "cease any I/O on the affected range" was added.
As far as I can tell, the client must cease any conflicting I/O before
sending the LAYOUTRETURN.   And, in fact, if a write layout is returned,
and a readonly layout is still held by the client, then the client can
still issue READ I/O on the affected range.

    Section 12.5.5.2.1 Recall/Return Sequencing

   If the
   "seqid" is not what the client currently has recorded, and the client
   has at least one LAYOUTGET and/or LAYOUTRETURN operation outstanding,
   the client knows the recall is for a response to an outstanding
   LAYOUTGET or LAYOUTRETURN.

I disagree.  The client knows that the recall must be processed after
the LAYOUTGET response, or alternatively, that the results of the
LAYOUTGET operation should be discarded (i.e not added to the client
cached layout state).  It is certainly possible that there is no
conflict between the results of the LAYOUTGET and the CB_LAYOUTRECALL.

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

---

From: Mike Eisler <[email-masked]>
Date: Mon, 31 Dec 2007 13:44:44 -0800 (PST)

Jason,

I agree with all of your comments (both this batch, and previous
batch).
I've committed the changes motivate by your comments.

Thanks.

   -mre