ietf
[Top] [All Lists]

RE: Review of draft-ietf-nfsv4-pnfs-block-10

2008-12-04 08:13:59
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

<Prev in Thread] Current Thread [Next in Thread>