Re: RFC: Transport identifier

["Martin K. Petersen" <martin.petersen@oracle.com>]

>>>>> "Stefan" == Stefan Richter <stefanr@s5r6.in-berlin.de> writes:

Stefan> So, while it may be prudent to deduct "it's USB" -> "don't try
Stefan> READ CAPACITY 16", why not keep implementing this in way #2?

I predict our scanning will involve much more heuristics than it does
now.  In relatively near future we will have to start using a less
conservative approach to sending commands because 4KB drives and drives
with odd alignment require us to use READ CAPACITY(16).

The triggers at the device level which would help (protocol mode pages,
version descriptors) are generally not filled out.  Not even in brand
new enterprise drives.

For DIF I had the luxury of being able to trigger off the PROTECT bit in
INQUIRY.  And even that broke because some USB devices returned random
garbage causing DIF to be enabled by accident.

The other problem we are facing is that right now the reported version
kinda-sorta works but that may not continue to be the case.  There are
several drive vendors that deliberately return a much older version than
the command set actually supported by the drive.  This is to work around
problems in legacy proprietary operating systems.

Originally my plan was to key off of the presence of the block limits
VPD page and submit RC16 if that was present.  But the VPD is mostly
aimed at RAID vendors and I'm told that drive vendors are not going to
bother filling it out.

-- 
Martin K. Petersen	Oracle Linux Engineering