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
--
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
