RE: SAS and iSCSI

[Black_David@emc.com]

Andre,

> Will the additional opcodes and command descriptor blocks that
> are definied in SAS be transferred using additional header 
> segements by the iSCSI transport?

At the moment, the SAS specification
(ftp://ftp.t10.org/t10/drafts/sas/sas-r01.pdf) says:

	10.3 SCSI commands

	No SAS-specific SCSI commands are defined.

So, no iSCSI modifications are currently needed.

> This assumes there will be new opcodes as SAS is very much 
> ontrack to be an API for array management.

As long as those opcodes are SCSI opcodes that use SCSI CDBs
in a fashion specified by T10, no iSCSI modifications will
be needed.

> Specifically where many of the current
> management applications of heavily mated to SCSI and SAS is a means to
> grant them extended life, whereas the hardware is dying.  So 
> in order to acommidate such dependencies, the concern is to insure that 
> iSCSI will be adaptable to address their over short comings to be so 
> tightly tied to a transport layer and semi dependent of physical layers.

Yes and no.  To the extent that they depend on issuing SCSI commands,
receiving SCSI responses, etc., iSCSI handles that.  To the extent
that they depend on physical layer specifics (e.g., parallel SCSI
mode pages), they're broken and should be fixed, although I don't
think there are any fundamental obstacles to emulating parallel SCSI
mode pages in an iSCSI target to accommodate such brain-damaged
software if one really wanted to do so.

As for the original question about whether iSCSI AHSs (additional header
segments) would be used for SAS, the answer appears to be "only for
extended CDB formats defined by T10", something that iSCSI already
supports (AHS code 1).

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------