SPC-3: TransportID Cleanup

pat_thaler at agilent.com pat_thaler at agilent.com
Mon Jun 2 10:36:39 PDT 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* pat_thaler at agilent.com
*
Rob,

I agree. This means that there are several ways to allow parsing of the list:

1) Adding a length field before each transport ID as proposed. This would be necessary if one wanted to allow processing a list where one skipped transportIDs one didn't understand and handled all the IDs one did understand. Given that one aborts when one doesn't understand a TransportID, the other options which rely on understanding of the iSCSI transport ID format are also possible.
2) Change the iSCSI transport ID to add a length field in one or two of the reserved bytes.
3) Don't change anything. One can parse an iSCSI TransportID by looking for the NULL character at the end of the name. The transport ID ends on the next 4 byte boundary. Therefore, one doesn't need a length field.  

Option 3 is no change to the existing formats. One could add an informative statement that says that the NULL is used to find the start of the next TransportID as the name only has a Null at the end. (It might have been nice if the padding was done with Nulls as that way one could find the end by only examining the last byte of each word.)

Pat

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com]
Sent: Monday, June 02, 2003 7:17 AM
To: t10 at t10.org
Subject: RE: SPC-3: TransportID Cleanup


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*

> Change 5: While preparing this proposal it was discovered
> that the PERSISTENT RESERVE OUT SPEC_I_PT additional 
> parameter data assumes that TransportIDs have a fixed 
> length. While this true for all TransportID formats except 
> iSCSI, the variable length nature of iSCSI TransportIDs 
> makes it impossible to parse the current PERSISTENT RESERVE 
> OUT SPEC_I_PT additional parameter data for iSCSI TransportIDs.

If the logical unit receives a PR OUT command specifying
any TransportID it does not understand, it will abort
the command and not make any of the registrations.  It's
not important that it be able to parse over TransportIDs
of unknown types (and thus unknown lengths), since it gives 
up if it sees any problem.

--
Rob Elliott, elliott at hp.com
Hewlett-Packard Industry Standard Server Storage Advanced Technology
https://ecardfile.com/id/RobElliott




> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at compuserve.com] 
> Sent: Wednesday, May 28, 2003 12:15 PM
> To: T10, Reflector
> Subject: SPC-3: TransportID Cleanup
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <ralphoweber at compuserve.com>
> *
> The SPC-3 editing review in Nashua uncovered some problems with the
> definition of TransportID values, particularly TransportID values
> for iSCSI devices.
> 
> TransportIDs are used by Access Controls and Persistent Reservations
> as a way for one initiator port to specify an action affecting
>  another initiator port.
> 
> Upon further review, problems have been found in previously approved
> proposal to use TransportIDs to identify initiators in the PERSISTENT
> RESERVE OUT when the SPEC_I_PT (Specify Initiator Ports) bit is set to
> one.
> 
> In all cases, the changes required to resolve the problems 
> are technical
> in nature and a proposal to effect them has been uploaded:
> 
   ftp://ftp.t10.org/t10/document.03/03-203r0.pdf

WARNING: The proposal as written includes changes to the PERSISTENT
RESERVE OUT SPEC_I_PT function that are not backward compatible.
Anyone implementing that function should comment on this reflector
if the proposed changes represent a hardship.

Regards,

.Ralph

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




More information about the T10 mailing list