I was asked by the IESG to review the "pNFS Block/Volume Layout"
specification [draft-ietf-nfsv4-pnfs-block-10], and I am sharing my
review on this list. The specification is overall in good shape and
should proceed for publication soon. I do suggest addressing the
following comments, though, before forwarding the document to the RFC
Editor.
Technical:
- Section 2.2.1 ("Volume Identification") specifies two methods for
identifying a position on a disk: by positive offset starting at the
beginning of the disk, and by negative offset starting at the end of
the disk. The second method is limited to implementations where
server and client have the same understanding of the disk size. This
method could be generalized: If you defined an offset, positive or
negative, to be in the context of the disk size as seen by the
client, then you may potentially also support implementations where
server and clients have a different understanding of the disk size.
The authors may consider this.
- Section 2.4 ("Crash Recovery Issues") specifies recovery procedures
that a client could initiate following a server crash. These
procedures apply in one specific condition, which is defined at the
beginning of the section ("When the server crashes while the client
holds a writable layout, and the client has written data to blocks
covered by the layout, and the blocks are still in the
PNFS_BLOCK_INVALID_DATA state, [then]..."). The section should also
consider other conditions. It may be sufficient to explain why only
the described condition requires recovery.
- Section 2.4 ("Crash Recovery Issues") does not explain how a client
detects a server crash. The section should briefly explain this. It
may be sufficient to mention that crash detection is specified in a
related document, or that it is implementation-specific.
Editorial:
- The specification uses undefined acronyms in a couple of places,
including in the title. Those should be spelled out when mentioned
the first time. Search for "pNFS", "SAN", "XDR", "LUN" to find the
relevant places in the specification.
Best regards,
- Christian
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf