Re: READ CAPACITY 16

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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