Christian,
Thank you for doing this review.
On the volume identification offset:
> - 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.
I would prefer not to do this. It's fairly easy to make a mistake in
this environment that has the client looking in the wrong place for
the volume identification, risking a false positive, and unpleasant
results. Beyond this, removing the requirement that server and client
have the same understanding of the disk size may create situations
in which different clients have different ideas of the disk size; that
seems like needless complexity, so all clients need to have the same
understanding of disk size, and adding the server to that understanding
is a small and reasonable step in pursuit of robustness.
As Hannes has already pointed out, there's quite a bit of crash
detection and recovery material in the main NFSv4.1 draft, including
descriptions of how to recover layouts in general (layouts are among
the resources that a client can reclaim during a grace period after
server restart). Hence this draft only adds material specific to
the block/volume layout. We'll add a sentence or two in order to
explain this and point to the material in the main NFSv4.1 draft.
We'll expand the first uses of the four acronyms.
Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
black_david@xxxxxxx Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Christian Vogt [mailto:christian.vogt@xxxxxxxxxxxx]
> Sent: Thursday, December 04, 2008 7:42 AM
> To: IETF Discussion Mailing List
> Cc: Black, David; fridella, stephen; jglasgow@xxxxxxxxxxxx;
> nfsv4-chairs@xxxxxxxxxxxxxx; nfsv4-ads@xxxxxxxxxxxxxx
> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf