[pnfs] Review of the draft-ietf-nfsv4-pnfs-block-04.txt specification

[Glasgow_Jason at emc.com]

Below are my notes of the block spec review conducted at the CITI
bakeathon.  I will update the spec accordingly.   Thanks to all the
participants for their input.

 

-Jason

 

 

Attendees:

David Black (phone)

Jason Glasgow

Benny Halevy

Richard Chandler

Mario Wurzl

Daniel Gardere

Jean-Louis Rochette

Andy Adamson

Fred Isaman

 

 

Notes:

Section 1 - Introduction

*	Benny notes that the diagram says "NFSv4 + pNFS".  It should say
"NFSv41"

 

Section 2.2.1 - Volume Identification

*	David Black - Signature can span 512 octect sectors.   Some
volume managers might use 4K or 8K labels.
*	Okay to limit a single signature component to a 512 octet
sector.  Not clear why.
*	Discussion of sig_offset.  Disks may move to 4K sectors at some
point.  Why are we using 512 sectors as the units.  Simpler to revert to
octet offsets.  Let the client do the math.  Since we are no longer
limiting all components of the signature to a single sector, or block,
then we might as well revert to the draft-3 spec.  Each component will
have an offset from the beginning or end of volume.

 

Section 2.2.2 - Volume Topology

*	All offsets should be octet offsets.  Eliminate the "sector"
terminology.
*	Perhaps reference the alignment attribute if it makes sense.
*	MAX_SIG_COMP is NOT specified anywhere.  It should be.  Also
belongs in the .x file.
*	Make sure all offsets are 64 bits.
*	Discussion on whether or not the client should be able to get
part of the device hierarchy.  Implementer concerned about the size of
the data structure.  Could we save space by communicating only a piece
of the hierarchy from server to client?  Generally agreed that will
cause additional complexity.    Client will have to pay the cost of
allocating memory for the potentially large reply.  What if the reply is
too large for allocated space?  Is there a mechanism to prevent endless
roundtrips just to figure out the proper sizes?  Can the error response
communicate the proper size?
*	More explanation required on GETDEVICELIST vs. GETDEVICEINFO.
How do they differ?  COPY-on-write semantics needs better explanation.
What about NMFS style file systems?
*	Get rid of reference to 512 octect blocks.

 

Section 2.2.3

*	Last sentence should be "MAY" not "SHOULD"

 

Section 2.3

*	pnfs_block_layout4 - make an array because we might have two
vol_ids.  Or should we embed the vol_id inside the extents?  We thought
we could get by with a size two array.  Readable extents and writable
extents.

 

Section 2.3.1 - Layout Requests and Extent Lists

*	/and no more than desired size//  (delete this).
*	"Extents in the extent list MUST be logicall contiguous...."
Reword to include the notion of two arrays (if this is the approach).  A
writable extent *MUST* cover readable extents.  

 

Section 2.3.2 - Layout Commits

*	Should this be a pnfs_block_extent4 data structure, or just
offset/length pairs?
*	Get rid of the "make version" field as nobody can argue why it
is used.
*	Last Paragraph "Oligation of a client does not relieve server
from issuing CB_LAYOUTRECALL".  Client should issue LAYOUTRETURN in the
same COMPOUND.  But all moot if we delete.

 

Section 2.3.3 - Layout Returns

*	No need for data structure
*	Mention that you can use multiple LAYOUT_RETURN within a
compound to return disjoint rejoins.  (Isn't there are requirement to
return only the sizes that were given in LAYOUTGET?)

 

Section 2.3.4 - Client Copy-on-Write Processing

*	Paragraph #2, Add language specifying "for unwritten portions of
extents" (if not yet clear).
*	Paragraph #2, Mention that can split extents
*	Mario wants to discuss the last paragraph of this section

 

Section 2.3.5 - Extents are Permissions

*	Get rid of "layout delegations" language through out.  This is
old terminology.  We now just say "layouts":

 

Section 2.3.7 - Client Fencing

*	Note that STOMITH and/or LUN Masking can be done by an admin.
Not necessary to automate.
*	Specify that the attribute is "per client" not per server or per
file system.
*	Open issue is how the client will know the maximum I/.O time.
Benny claims that for iSCSI it is unbounded.  Implementers want to know
how they will know how to set it?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/pnfs/attachments/20071011/0c700200/attachment.html