00-279r0 Large SCSI Device Identifiers

[chamb at almaden.ibm.com]

* From the T10 Reflector (t10 at t10.org), posted by:
* chamb at almaden.ibm.com
*


Ed's proposal addresses a significant need, and George's comments are
important.  I add the comments below from the perspective of more detailed
work with EXTENDED COPY.

1.  EXTENDED COPY

While I agree that E4 is the elegant target descriptor for identifying a
LU, by itself it is not a scalable approach.  A copy manager should not be
required to maintain a table of the world-wide ids of all LUs on a large
SAN.  However, it must if the E4 target descriptor is to be useful by
itself.  Otherwise it is necessary to provide mechanisms to supply
addressing paths to the copy manager.

My preference is that path information could be supplied in a new segment
descriptor.  Such path hints could supplement the definitive LU unique id
contained in the E4 target descriptor.  As in Edward's suggestion, the path
information would be contained in the inline data area.  That path info
should probably be self-defining, in that it would start with a fixed
header that includes a protocol code (specifying which protocol defines the
format), a format code (if the protocol defines multiple formats), and the
size of the additional (protocol-specific) data that follows.  The same
path format could be used in other contexts to identify initiators (see
below).  The fixed header would probably also include an 8-byte LUN field
that contains a LUN, an AccessID per 99-245r9, or zeroes if no LUN is to be
supplied.

(Note:  For future capabilities (such as support for authentication
protocols) it will be useful to supply other parameters as additional
attributes of a target descriptor, and it is appropriate to do that in the
inline data area using segment descriptors similar in format to the one
described above.  I was tempted to suggest that only one descriptor type
code be used, and that an attribute code in the descriptor be used to
identify the content.  However, it is simpler to allocate a separate
descriptor type code to each attribute type, as needed, and move to a
hierarchical scheme only in the unlikely event that we deplete that
namespace.)


2.  THIRD-PARTY RESERVATIONS

Is it true that third-party reservations are considered obsolete?  Some
third-party applications need them, at least until support for persistent
reservations becomes prevalent.  It would be sensible for RESERVE(10) and
RELEASE(10) to accept a longer initiator identifier similar to the path
information described in (1).  SPC would define the header format but not
the total size; a given protocol might define the format so that the size
is fixed.

3.  XOR COMMANDS

Just a thought:  instead of enhancing XDWRITE EXTENDED to use addressing
constructs like those in EXTENDED COPY, would it be easier to add a segment
descriptor to EXTENDED COPY  that would perform the XDWRITE EXTENDED
function?
a.  An XOR-capable disk could support this capability in EXTENDED COPY
without offering any of the other capabilities (like tape operations).
b.  This would require that path-data and data-data be combined into the
parameter data for the command.  This is slightly awkward for some
initiator platforms, but should be okay for low-level code that can deal
with hardware scatter-gather.  In any event this would be an issue for an
extension of XDWRITE EXTENDED as well.



David Chambliss
Research Staff Member, Computer Science /Storage Systems
IBM Research Division
(408) 927-2243  (TL 457-2243)
FAX (408) 927-3497


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org