Subject: [nfsv4] [Technical Errata Reported] RFC5661 (3208)

From: RFC Errata System <[email-masked]>
Date: Wed, 2 May 2012 10:58:54 -0700 (PDT)

The following errata report has been submitted for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5661&eid=3208

--------------------------------------
Type: Technical
Reported by: Benny Halevy <[email-masked]>

Section: GLOBAL

Original Text
-------------

Corrected Text
--------------

Notes
-----
Section 12.5.2. says:
   The first successful LAYOUTGET
   processed by the server using a non-layout stateid as an argument
   MUST have the "seqid" field of the layout stateid in the response set
   to one.  Thereafter, the client MUST use a layout stateid (see
   Section 12.5.3) on future invocations of LAYOUTGET on the file, and
   the "seqid" MUST NOT be set to zero.

It should say:
   The first successful LAYOUTGET
   processed by the server using a non-layout stateid as an argument
   MUST have the "seqid" field of the layout stateid in the response set
   to one.  Thereafter, the client MUST use a layout stateid (see
   Section 12.5.3) on future invocations of LAYOUTGET on the file, and
   the "seqid" MUST NOT be set to zero.
|  The client MUST serialize LAYOUTGET operations using a non-layout
|  stateid with any other operation affecting the layout state on the file,
|  including CB_LAYOUTRECALL, to allow consistent initialization of the
|  layout state.

Add the following paragraph to section 12.5.3.:
|  A client MAY always forget its layout state and associated
|  layout stateid at any time (See also section 12.5.5.1).
|  In such case, the client MUST use a non-layout stateid for the next
|  LAYOUTGET operation.  This will signal the server that the client has
|  no more layouts on the file and its respective layout state can be
|  released before issuing a new layout in response to LAYOUTGET.

Section 12.5.5.2.1. says:
   One critical issue with regard to layout operations sequencing
   concerns callbacks.  The protocol must defend against races between
   the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
   CB_LAYOUTRECALL.  A client MUST NOT process a CB_LAYOUTRECALL that
   implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
   to which the client has not yet received a reply.  The client detects
   such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
   layout stateid.  If the "seqid" is not exactly one higher than what
   the client currently has recorded, and the client has at least one
   LAYOUTGET and/or LAYOUTRETURN operation outstanding, the client knows
   the server sent the CB_LAYOUTRECALL after sending a response to an
   outstanding LAYOUTGET or LAYOUTRETURN.

It should say:
   One critical issue with regard to layout operations sequencing
   concerns callbacks.  The protocol must defend against races between
   the reply to a LAYOUTGET or LAYOUTRETURN operation and a subsequent
   CB_LAYOUTRECALL.  A client MUST NOT process a CB_LAYOUTRECALL that
   implies one or more outstanding LAYOUTGET or LAYOUTRETURN operations
   to which the client has not yet received a reply.  The client detects
   such a CB_LAYOUTRECALL by examining the "seqid" field of the recall's
   layout stateid.  If the "seqid" is not exactly one higher than what
   the client currently has recorded, and the client has at least one
   LAYOUTGET and/or LAYOUTRETURN operation outstanding,
|  or if the client has a outstanding LAYOUTGET with a non-layout stateid,
   the client knows
   the server sent the CB_LAYOUTRECALL after sending a response to an
   outstanding LAYOUTGET or LAYOUTRETURN.

Section 12.5.5.2.1.1. says:
   It is permissible for the client to send multiple parallel LAYOUTGET
   operations for the same file or multiple parallel LAYOUTRETURN
   operations for the same file or a mix of both.

It should say:
    It is permissible for the client to send multiple parallel LAYOUTGET
    operations for the same file
|   using the layout stateid
    or multiple parallel LAYOUTRETURN
    operations for the same file or a mix of both.

Section 12.5.5.2.1.2. says:
   Note
   that in the first case, the "seqid" in the layout stateid of the
   recall is two greater than what the client has recorded;

It should say:
   Note
   that in the first case, the "seqid" in the layout stateid of the
   recall is two greater than what the client has recorded,
|  or the client has an outstanding LAYOUTGET using a non-layout stateid;

After the following paragraph in Section 18.43.3:
   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, byte-range lock,
   or delegation stateid.  Once a layout is held on the file by the
   client, the loga_stateid field MUST be a stateid as returned from a
   previous LAYOUTGET or LAYOUTRETURN operation or provided by a
   CB_LAYOUTRECALL operation (see Section 12.5.3).

Add the following paragraph:
|  When loga_stateid represents a non-layout stateid the server MUST
|  release any layout state previously held by the client as if the client
|  explicitly returned the layout using a corresponding LAYOUTRETURN
|  with lora_iomode of LAYOUTIOMODE4_ANY, lr_returntype of LAYOUTRETURN4_FILE,
|  lrf_offset value 0, and lrf_length value NFS4_UINT64_MAX. This is
|  particularly useful to clients implementing the forgetful model (Section
|  12.5.5.1) when acquiring a layout after unilaterally forgetting the layout
|  state.  This requirement mandates that the client serializes sending
|  a LAYOUTGET with non-layout statid with any other layout operation on
|  the file (See section 12.5.2).

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Marc Eshel <[email-masked]>
Date: Wed, 2 May 2012 13:45:31 -0700

Maybe we can finish the discussion one the following point I was not able 
to get agreement on the list.
Marc.

section 18.43.3 say:

The logr_return_on_close result field is a directive to return the layout 
before closing the file.  When the metadata server sets this  return value
to TRUE, it MUST be prepared to recall the layout in the case in which the
client fails to return the layout before close.  For the metadata server 
that knows a layout must be returned before a close of the file, this 
return value can be used to communicate the desired behavior to the client
and thus remove one extra step from the client's and metadata server's 
interaction.

it should say:

The logr_return_on_close result field is a directive to return or forget 
the layout before closing the file . When the metadata server sets this 
return value to TRUE, the client MUST NOT use the layout after sending 
the last CLOSE of that file. Any outstanding COMMIT to the data servers
or LAYOUTCOMMIT to the metadata server MUST be sent prior to closing the
file. This return value is used to communicate to the client that any 
layout or segment of a layout that were given with logr_return_on_close 
set to TRUE will result in the server invalidating all layouts of 
layouttype4 of loga_layout_type for the file after it was closed. Once 
the server returns logr_return_on_close set to TRUE to a client for a
given file it MUST set logr_return_on_close to TRUE for all subsequent 
layouts or segments of layoutype4 of the respective loga_layout_type for
that file and client until that file is closed.

Notes:

This directive will remove one or more extra steps from the client's and 
metadata server's interaction.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 08 May 2012 12:26:07 +0300

[fixing the list alias address on the Cc]

> to get agreement on the list.

Absolutely.

> and thus remove one extra step from the client's and metadata server's 

I'm good with the following direction, modulo the minor comment below.

> return value to TRUE, the client MUST NOT use the layout

and the respective layout stateid

Benny

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

---

From: Marc Eshel <[email-masked]>
Date: Wed, 9 May 2012 10:43:52 -0700

Can we update the Errata with the following?
Thanks, Marc.

18.43.3 that should go into v4.1 errata.
Marc.

section 18.43.3 say:

it should say:

The logr_return_on_close result field is a directive to return or forget 
the layout before closing the file . When the metadata server sets this 
return value to TRUE, the client MUST NOT use the layout and the 
respective 
layout stateid after sending the last CLOSE of that file. Any outstanding 
COMMIT to the data servers or LAYOUTCOMMIT to the metadata server MUST be 
sent prior to closing the file. This return value is used to communicate 
to
the client that any layout or segment of a layout that were given with 
logr_return_on_close set to TRUE will result in the server invalidating 
all
layouts of layouttype4 of loga_layout_type for the file after it was 
closed.
Once the server returns logr_return_on_close set to TRUE to a client for a
given file it MUST set logr_return_on_close to TRUE for all subsequent 
layouts or segments of layoutype4 of the respective loga_layout_type for
that file and client until that file is closed.

Notes: