SPC-3: TransportID Cleanup

Elliott, Robert (Server Storage) Elliott at hp.com
Mon Jun 2 07:16:40 PDT 2003


* 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




More information about the T10 mailing list