Re: SAT-2 and DSENSE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sending again.


On 7/30/09 1:04 PM, "Mark Overby" <moverby@xxxxxxxxxx> 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@xxxxxxxxxxxx> 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.
-----------------------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux