03-002r0: Remove SPI from SAM-3 and SPC-3 [a little bit more]

Elliott, Robert (Server Storage) Elliott at hp.com
Sat Feb 8 07:54:12 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
The proposal is removing CA, not ACA.

CA = state between CHECK CONDITION and return of sense data; effectively
nonexistent with autosense.

ACA = optional state that can be entered after CHECK CONDITION which
remains until a CLEAR ACA task management function is run.  During this
state commands submitted with the "ACA" task attribute can be processed.

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




> -----Original Message-----
> From: Sheffield, Robert L [mailto:robert.l.sheffield at intel.com] 
> Sent: Friday, February 07, 2003 7:13 PM
> To: roweber at acm.org; T10, Reflector
> Cc: Elliott, Robert (Server Storage)
> Subject: RE: 03-002r0: Remove SPI from SAM-3 and SPC-3 [a 
> little bit more]
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Sheffield, Robert L" <robert.l.sheffield at intel.com>
> *
> Is the proposal really to remove ACA completely from SAM-3?
> 
> I can understand that with auto-sense there isn't a need to 
> preserve the sense information for a subsequent REQUEST SENSE 
> command, but I thought the intent of ACA went beyond just 
> preserving sense data. In many cases an initiator may want to 
> issue additional retry commands (rezero unit, retry the same 
> command, read long, twiddle recovery mode pages to transfer 
> the bad block,....), and needs to be able to execute these 
> recovery procedures without worrying about interfering 
> commands from other initiators. I can't say for certain that 
> any existing drivers or storage controllers today use ACA to 
> implement this type of recovery, but it's clear the intent of 
> ACA originally was, in part, to address this sort of error 
> recovery. These sorts of retry mechanisms would apply as well 
> to SAS or fibre-channel FCP as they do for SPI, so I don't 
> see the end of SPI itself as adequate justification for 
> eliminating ACA.
> 
> Regards,
> Bob Sheffield
> Intel Corporation - CH6-333
> Storage Components Division (SCD)
> 5000 W. Chandler Blvd
> Chandler, AZ 85226-3699
> Phone: 480-554-8597
> Fax: 480-554-6617
> 
> 
> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber at compuserve.com]
> Sent: Tuesday, January 07, 2003 8:31 PM
> To: T10, Reflector
> Cc: Elliott, Robert (Server Storage)
> Subject: Re: 03-002r0: Remove SPI from SAM-3 and SPC-3 [a 
> little bit more]
> 
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <ralphoweber at compuserve.com>
> *
> Rob,
> 
> I never suggested that REQUEST SENSE be made obsolete.
> I am, however, questioning whether it needs to remain
> mandatory for all device types.
> 
> I seriously doubt that any real world device will decline
> to implement REQUEST SENSE anytime soon.
> 
> I do not have any serious problems with leaving REQUEST
> SENSE mandatory for all device types, but I believe that
> the result will be a profoundly lame explanation of why
> in SPC-3 subclause 5.2.3 along the lines of the polling 
> function that you note.
> 
> This could be a case where we decide to make no changes
> now and let time give us some perspective on the matter.
> That is a fine way to go.
> 
> Regards,
> 
> .Ralph
> 
> Elliott, Robert (Server Storage) wrote:
> 
> > 
> >* From the T10 Reflector (t10 at t10.org), posted by:
> >* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> >*
> >There is one other SCSI transport that still uses contingent 
> allegiance
> >(CA): ATAPI (ATA Packet Interface, defined in T13's ATA/ATAPI 
> >standard). ATAPI devices will still require REQUEST SENSE, 
> regardless 
> >of their command set (most likely but not exclusively MMC).  Perhaps 
> >that requirement could be documented in ATA/ATAPI-7 itself.
> >
> >Many devices let applications poll with REQUEST SENSE to 
> retrieve sense 
> >data containing progress indication - the status of long operations 
> >like FORMAT MEDIUM or self-test.  I don't think autosense 
> can replace 
> >this usage.  REQUEST SENSE might only need to be required 
> for devices 
> >implementing those commands, though.
> >
> >A quick web search shows at least one Fibre Channel driver might get 
> >upset if a target chose not to support autosense (but only 
> after it had 
> >trouble delivering the autosense data in the first place): 
> "The driver 
> >now issues a request sense when an FCP_RSP is received with check 
> >condition status, but no sense data (CR#3872)"
> >
> >--
> >Rob Elliott, elliott at hp.com
> >Hewlett-Packard Industry Standard Server Storage Advanced Technology 
> >https://ecardfile.com/id/RobElliott
> >  
> >
> 
> 
> *
> * 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