SAT-2 and DSENSE

SAT-2 and DSENSE

[Douglas Gilbert]

The SCSI to ATA Translation 2 (SAT-2) project is in the
technical review stage pending standardization at
www.t10.org. In the last month a change has been added
which will break existing user space code (e.g. smartmontools).

The area of concern is the ATA return descriptor and the
newly introduced "Fixed format sense data" (sat2r08b.pdf
section 12.2.7). SAT code has been in the kernel (libata)
since 2005 and roughly complies the original SAT standard
(ANSI INCITS 431-2007). There has been an anomaly between
the way DSENSE in the control mode page of SPC-3 is defined
and the fact that parts of SAT-1 act as if it was always
set. So no matter that libata-scsi.c actually sets the DSENSE
bit to 0 (line 101 libata-scsi.c in lk 2.6.30), the ATA
PASS-THROUGH COMMANDs will yield descriptor sense format if
requested (e.g. by the CK_COND bit).

The non backwardly compatible SAT-2 change is that when
DSENSE=0, the newly introduced "Fixed format sense data"
should be generated by the SAT layer (SATL). ***

The code in libata-scsi.c is a SATL which we control.
However there are lots of other SATLs out there that
are not controlled by the kernel (e.g. a SATA disk in an
external USB, SAS, FC or iSCSI enclosure). That leaves
a bit of a mess in the hands of applications like
smartmontools that is fixable. Existing versions of
smartmontools will break if a SATL complying with SAT-2
sets DSENSE=0 (and my guess is most do).


I was thinking of sending a patch to change libata's setting
of DSENSE to 1 but that implies that all "normal" SCSI
commands (e.g. READ, WRITE and READ CAPACITY) would also
return descriptor sense data. So the patch would need to
include generation of descriptor format sense data where
required. That might upset some applications.

As a side note, sooner or later SCSI block devices (including
SATA devices behind libata's SATL) will need to use descriptor
sense format because the Information field in the fixed sense
data format is only 32 bits. As an example: the Information
field is used for the first failed LBA of a medium error.
For 512 byte sectors 32 bits gets as far as 2 TB.


*** If libata complies with SAT-2 DSENSE=0 handling it should
     probably also handle PROTOCOL="Return response information"
     properly as well. [It ignores it currently.]


Doug Gilbert

Re: SAT-2 and DSENSE

[Mark Overby]

Sending again.


On 7/30/09 1:04 PM, "Mark Overby" <moverby@nvidia.com> wrote:

> Speaking as editor, and not author of the proposal that changed it:
> 
> It was noted during letter ballot review that the existing sense data return
> did not work with existing operating system implementation. Therefore, it was
> proposed (and accepted) that a fixed format sense data be defined for ATA
> PASS-THROUGH and that D_SENSE follow the SPC-4 definition. This allows
> selection of the mode that works for the application environment, including
> operating system.
> 
> It is noted in multiple places that SATLs compliant with previous versions of
> this standard always return descriptor format sense data.
> 
> T10 doc 08-344r2 was the proposal to address letter ballot comments on this.
> 
> You could use the version descriptor to indicate a SATL that is compliant with
> SAT-1 and branch your behavior accordingly.
> 
> 
> On 7/30/09 12:50 PM, "Douglas Gilbert" <dgilbert@interlog.com> wrote:
> 
>> The SCSI to ATA Translation 2 (SAT-2) project is in the
>> technical review stage pending standardization at
>> www.t10.org. In the last month a change has been added
>> which will break existing user space code (e.g. smartmontools).
>> 
>> The area of concern is the ATA return descriptor and the
>> newly introduced "Fixed format sense data" (sat2r08b.pdf
>> section 12.2.7). SAT code has been in the kernel (libata)
>> since 2005 and roughly complies the original SAT standard
>> (ANSI INCITS 431-2007). There has been an anomaly between
>> the way DSENSE in the control mode page of SPC-3 is defined
>> and the fact that parts of SAT-1 act as if it was always
>> set. So no matter that libata-scsi.c actually sets the DSENSE
>> bit to 0 (line 101 libata-scsi.c in lk 2.6.30), the ATA
>> PASS-THROUGH COMMANDs will yield descriptor sense format if
>> requested (e.g. by the CK_COND bit).
>> 
>> The non backwardly compatible SAT-2 change is that when
>> DSENSE=0, the newly introduced "Fixed format sense data"
>> should be generated by the SAT layer (SATL). ***
>> 
>> The code in libata-scsi.c is a SATL which we control.
>> However there are lots of other SATLs out there that
>> are not controlled by the kernel (e.g. a SATA disk in an
>> external USB, SAS, FC or iSCSI enclosure). That leaves
>> a bit of a mess in the hands of applications like
>> smartmontools that is fixable. Existing versions of
>> smartmontools will break if a SATL complying with SAT-2
>> sets DSENSE=0 (and my guess is most do).
>> 
>> 
>> I was thinking of sending a patch to change libata's setting
>> of DSENSE to 1 but that implies that all "normal" SCSI
>> commands (e.g. READ, WRITE and READ CAPACITY) would also
>> return descriptor sense data. So the patch would need to
>> include generation of descriptor format sense data where
>> required. That might upset some applications.
>> 
>> As a side note, sooner or later SCSI block devices (including
>> SATA devices behind libata's SATL) will need to use descriptor
>> sense format because the Information field in the fixed sense
>> data format is only 32 bits. As an example: the Information
>> field is used for the first failed LBA of a medium error.
>> For 512 byte sectors 32 bits gets as far as 2 TB.
>> 
>> 
>> *** If libata complies with SAT-2 DSENSE=0 handling it should
>>      probably also handle PROTOCOL="Return response information"
>>      properly as well. [It ignores it currently.]
>> 
>> 
>> Doug Gilbert
>> 

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------