Re: USB storage devices and SAT

[Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>]

On Mon, 4 Aug 2008, Douglas Gilbert wrote:

> USB storage devices that support SAT (the T10 SCSI to ATA
> translation standard) are beginning to appear.
> 
> SAT enables tools like smartmontools to access SMART data
> on a ATA disk in a USB enclosure. We have run into
> a problem. It seems that the usb storage subsystem is wedded
> to the idea of sense data that is no longer than 18 bytes. **
> That doesn't play well with SAT which uses descriptor format
> sense data that is made up of an 8 byte header plus zero or
> more descriptors. SAT uses a 14 byte "ATA return" (sense)
> descriptor to yield the ATA registers. That means the sense
> data length is 22 bytes when an ATA return descriptor is
> required.
> 
> Alan Stern has already noted to another smartmontools developer
> that such a change is likely to break some USB storage devices.
> Perhaps the maximum sense buffer size could be optionally
> specified per usb storage device. Alternatively the usb mass
> storage logic could make some dynamic decisions itself.
> For example if the (disk) device responds successfully to either
> SCSI ATA PASS_THROUGH (12 or 16 byte) command then it will
> be capable of (at least) 22 byte sense data. A T10 vendor
> identification field in a standard INQUIRY response of
> "ATA     " is another indication of a device that supports
> SAT.

If either of these techniques could be used for dynamically detecting
when a device can reliably support 22-byte REQUEST SENSE, they would be
okay.

I tend to agree with Matt that it would be best to have the higher
layers tell usb-storage exactly how much sense data they want to get.
The problem is that these higher layers would not know about the 
18-byte restriction on many earlier USB devices, so usb-storage would 
probably end up needing to make its own dynamic decisions anyway.

Alan Stern


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html