Subject: [nfsv4] [Editorial Errata Reported] RFC5663 (4140)

From: RFC Errata System <[email-masked]>
Date: Thu, 23 Oct 2014 01:09:47 -0700 (PDT)

The following errata report has been submitted for RFC5663,
"Parallel NFS (pNFS) Block/Volume Layout".

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

--------------------------------------
Type: Editorial
Reported by: Christoph Hellwig <[email-masked]>

Section: 2.3.5

Original Text
-------------
   Block/volume class storage devices are not required to perform read
   and write operations atomically.  Overlapping concurrent read and
   write operations to the same data may cause the read to return a
   mixture of before-write and after-write data.  Overlapping write
   operations can be worse, as the result could be a mixture of data
   from the two write operations; data corruption can occur if the
   underlying storage is striped and the operations complete in
   different orders on different stripes.  When there are multiple
   clients who wish to access the same data, a pNFS server can avoid
   these conflicts by implementing a concurrency control policy of
   single writer XOR multiple readers.  This policy MUST be implemented
   when storage devices do not provide atomicity for concurrent
   read/write and write/write operations to the same data.

Corrected Text
--------------
   Block/volume class storage devices do not provide byte granularity
   access and can only perform read and write operations atomically at
   block granularity, and thus require read-modify-write cycles to write
   data smaller than the block size.  Overlapping concurrent read and
   write operations to the same data thus may cause the read to return
   a mixture of before-write and after-write data.  Additionally, data
   corruption can occur if the underlying storage is striped and the
   operations complete in different orders on different stripes.  When
   there are multiple clients who wish to access the same data, a pNFS
   server MUST avoid these conflicts by implementing a concurrency
   control policy of single writer XOR multiple readers for a given data
   region.

Notes
-----
No device classified as block device can support concurrent writes at arbitrary byte granularity, so reword the section to not confuse the reader.  Also make it explicit that the reader XOR writer policy only applies to different clients, as existing client implementation require layouts not to be recalled due to their own LAYOUTGET operations.  Note that fixing this on the client also isn't feasible as the block layout unfortunately decided to introduce it's own extent concept instead of using layouts to describe individual I/O mappings.

Instructions:
-------------
This erratum 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. 

--------------------------------------
RFC5663 (draft-ietf-nfsv4-pnfs-block-12)
--------------------------------------
Title               : Parallel NFS (pNFS) Block/Volume Layout
Publication Date    : January 2010
Author(s)           : D. Black, S. Fridella, J. Glasgow
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG