>>>>> "Stefan" == Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> 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 -- 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
