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 steering group member) No Objection

No Objection ()

                            

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Ward; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2008-12-04)
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 steering group member) No Objection

No Objection ()

                            

(Lisa Dusseault; former steering group member) No Objection

No Objection ()

                            

(Magnus Westerlund; former steering group member) No Objection

No Objection ()

                            

(Pasi Eronen; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Ross Callon; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Tim Polk; former steering group member) (was No Record, Discuss) No Objection

No Objection ()