Hi Christian,
since draft-ietf-nfsv4-pnfs-block-10 is an extension for block and
volume-based layout of
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-26.tx
t
and more information about recovery can be found in that NFSv4.1
document.
Ciao
Hannes
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of ext Christian Vogt
Sent: 04 December, 2008 14:42
To: IETF Discussion Mailing List
Cc: nfsv4-chairs(_at_)tools(_dot_)ietf(_dot_)org;
fridella_stephen(_at_)emc(_dot_)com;
black_david(_at_)emc(_dot_)com; nfsv4-ads(_at_)tools(_dot_)ietf(_dot_)org;
jglasgow(_at_)aya(_dot_)yale(_dot_)edu
Subject: Review of draft-ietf-nfsv4-pnfs-block-10
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf