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
