Skip to main content

Parallel NFS (pNFS) Block/Volume Layout
RFC 5663

Yes

Lars Eggert

No Objection

(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Note: This ballot was opened for revision 12 and is now closed.

Lars Eggert
Yes
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2008-12-04) Unknown
Review by Christian Vogt:

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.
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was No Record, Discuss) No Objection
No Objection () Unknown