Re: READ CAPACITY 16

[Douglas Gilbert <dgilbert@interlog.com>]

Matthew Wilcox wrote:
> I'm looking at the UNMAP support again, and we now have a bit that tells
> us whether the device supports UNMAP or not, it's called TPE (Thin
> Provisioning Enabled) and is found in byte 14 of the result from READ
> CAPACITY 16.  The problem is that we do our best to avoid calling READ
> CAPACITY 16.
> 
> Presumably, there are many devices which do not support RC16.  That
> isn't a problem, we can try RC16 and fall back to RC10 if the device
> returns an error.  The question is what to do about devices that either
> hang or take a long time to respond to an RC16 command.
> 
> This kind of problem isn't going to be limited to UNMAP.  DIF/DIX
> already has to use RC16 to get the protection type.  Once 4k sector size
> drives become common, we're going to want the "LOGICAL BLOCKS PER
> PHYSICAL BLOCK EXPONENT" and the "LOWEST ALIGNED LOGICAL BLOCK ADDRESS"
> information that RC16 returns and RC10 doesn't.  There's another 16
> bytes and a couple of reserved 4-bit fields to be assigned too, and I
> can imagine them getting used for new features in the future.
> 
> So what strategy should we adopt for trying harder to issue RC16?
> 
> Algorithm A (a perfect world):
> 
> Issue RC16
>  -> If it fails, issue RC10
>  -> If it times out, reset the device, issue RC10
> 
> Algorithm B:
> 
> Issue RC10
> Issue RC16
>  -> If it succeeds, use its results in preference to those from RC10
>  -> If it fails, carry on with the results from RC10
>  -> If it times out, reset the device, carry on with the results from RC10
> 
> Algorithm C:
> 
> As algorithm B, except:
>  -> If it succeeds, use the RC10 results for LBA unless the LBA is 0xffffffff
>     but use the RC16 results for TPE, PROT, etc.
> 
> Algorithm D:
> 
> Go back to T10 and say "Excuse me, kind sirs, would you mind adding an
> INQUIRY bit to indicate that the device supports UNMAP?  I know you've
> added a bit to RC16, but there's this nasty real world out there where
> devices are apt to blow up if you send them an RC16 when they're not
> expecting it."

T10 proposal 08-149r7 on thin provisioning does add two
extra fields to the Block Limits VPD page. A value greater
than zero in the first extra field ("Maximum UNMAP LBA
count") indicates that thin provisioning is supported.

In my experience it is reasonably safe to fire a "36 byte"
INQUIRY command with the EVPD bit set (with a page code of
B0h in this case) and examine the response. Crappy devices
just ignore the EVPD bit and respond as if it was a standard
INQUIRY, and this is easy to detect. The chances of such
devices supporting thin provisioning are extremely remote.

So if a properly formatted Block Limits VPD page is returned
with "Maximum UNMAP LBA count" > 0 then do a READ CAPACITY 16.

It wouldn't be a bad idea if the block subsystem used some
of the other fields in the Block Limits VPD page.

Doug Gilbert