This draft generally looks good. Looking at this from a SCSI standards
perspective,
I found a few small things. The 512 vs. 4k block size (2.3.1) and reservation
scope
(2.4.10.3) items are important - everything else is editorial, although clarity
on
commonality with RFC 5663 would be of significant help to any implementer who
has exposure to that.
-- Introduction, last paragraph.
Add a sentence saying that there are no other significant differences from RFC
5663
(previous sentences indicate use of SCSI for fencing and LAYOUTCOMMIT
improvements),
e.g., the volume topology (Section 2.3.2) and data structures that describe
extents
(Section 2.3.3.) are common with RFC 5663. Those two examples seem important.
-- Section 2.1, 1st paragraph
" and the SCSI initiators used for the pNFS Metadata Server and clients
MUST
support SCSI persistent reservations."
Add a citation of [SPC4] to support that MUST requirement.
-- Section 2.1, 2nd paragraph:
Clients MUST be able to perform I/O to
the block extents without affecting additional areas of storage
(especially important for writes); therefore, extents MUST be aligned
to 512-byte boundaries.
That assumes a 512 byte logical block size, which is generally ok for now, but
4k is coming.
At a minimum, "extents MUST be aligned to logical block size boundaries of the
logical
units, e.g., 512 bytes." OTOH, would it be reasonable to just make 4k
alignment a MUST
now, as there will be storage systems that need 4k alignment and 4k alignment
generally
works better than 512-byte alignment with existing systems?
-- Section 2.3.1
It is similar to the "Identification
Descriptor Target Descriptor" specified in [SPC4], but limits the
allowed values to those that uniquely identify a LU.
I suggest just deleting this sentence, as that is now called an "Identification
CSCD Descriptor" -
if this sentence is retained, the use of those descriptors in EXTENDED COPY
would be
important to mention - that seems like a diversion.
2. The "DESIGNATOR TYPE" MUST be set to one of four values
T10 is now allowing UUIDs to also be used in the working draft of SPC-5, and
those would be
appropriate here. Nonetheless, I suggest no change until SPC-5 is completed at
T10, as this
draft is (properly, IMHO) based on SPC-4.
-- Section 2.4.10.3
To make sure all I_T nexuses are registered,
the client SHOULD set the "All Target Ports" (ALL_TG_PT) bit when
registering the key, or otherwise ensure the registration is
performed for each initiator port.
It looks like initiator and target registration scopes were conflated here and
need to be separated. Suggested text:
To make sure all I_T nexuses are registered,
the client SHOULD set the "All Target Ports" (ALL_TG_PT) bit when
registering the key, or otherwise ensure the registration is
performed for each target port, and MUST perform registration
for each initiator port.
-- References
Current version of SAM is SAM-5, consider updating SAM-4 reference to SAM-5.
Thanks, --David
-----Original Message-----
From: nfsv4 [mailto:nfsv4-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Tuesday, June 28, 2016 11:08 AM
To: IETF-Announce
Cc: spencerdawkins(_dot_)ietf(_at_)gmail(_dot_)com;
nfsv4-chairs(_at_)ietf(_dot_)org; nfsv4(_at_)ietf(_dot_)org;
draft-ietf-nfsv4-scsi-layout(_at_)ietf(_dot_)org
Subject: [nfsv4] Last Call: <draft-ietf-nfsv4-scsi-layout-06.txt> (Parallel
NFS
(pNFS) SCSI Layout) to Proposed Standard
The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'Parallel NFS (pNFS) SCSI Layout'
<draft-ietf-nfsv4-scsi-layout-06.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2016-07-12. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
The Parallel Network File System (pNFS) allows a separation between
the metadata (onto a metadata server) and data (onto a storage
device) for a file. The SCSI Layout Type is defined in this document
as an extension to pNFS to allow the use SCSI based block storage
devices.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-scsi-layout/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
nfsv4 mailing list
nfsv4(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/nfsv4