On Thu, 2008-12-18 at 16:38 +0200, Boaz Harrosh wrote: > OK Then I say D, go to T10, while white list the (0) devices that currently > report !SCSI_3 but do support UNMAP. These are only USB right? > > Your tested devices report SCSI_3? Do all devices that are scsi_level > SCSI_2 > suppose to support RC16? The problem isn't whether they support it or not. A proper standards compliant SCSI device can be sent READ CAPACITY(16) and just return ILLEGAL REQUEST sense quite normally. If those were all the devices in the world, we'd send 16 first and fall back to 10. The problem is that there are devices (USB devices) that go haywire when sent a READ CAPACITY 16 command (or, indeed, any other SCSI command not in their vocabulary). It's for these devices that we do the 10->16 dance the way we do in sd.c Our problem is to identify devices that could reliably receive (and this doesn't mean process it just means return a standards compliant response without crashing or going out to lunch) READ CAPACITY 16 because the current Thin Provisioning draft requires this to indicate thin provisioning support. My take is still that TP devices have to be SCSI-3 SBC-3 or higher, so we just check this and for them do READ CAPACITY 16 with fallback to 10 on ILLEGAL REQUEST return. USB has to whitelist the TP compliant devices and not mangle the inquiry version field down to SCSI_2 for them and the world will just work. > My point is make the standard, which is still a draft, crystal clear > in a backward compatible way. All new, supporting, devices can be easily > identified, and the very few devices that do support the new fixture but > were released prior to the finalization of the draft be white-listed. > And in any event don't let the standard be broken like that. James -- 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
