READ CAPACITY 16
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."
Critiques should be expressed in the form of new algorithms.
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
Quoted 28 lines · Matthew Wilcox
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
Quoted 7 lines
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
I fail to see an effective difference between Algo A and B. The question really is one you already asked:
Quoted 2 lines
...The question is what to do about devices that either hang or take a long time to respond to an RC16 command.
A few ideas:
1) maintain a blacklist
2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality? If so, then something like B or C would make sense.
3) How long does Read Capacity16 normally take? e.g. at boot time with drive that isn't spun up yet or equivalent from RAID device.
If it's not that long (e.g < 1sec or so) then just use a shorter
timeout in general?
With parallel scanning, it should be tolerably painful.
hth,
grant
Quoted 27 lines
Algorithm C:
As algorithm B, except:
-> If it succeeds, use the RC10 results for LBA unless the LBA is0xffffffff
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."
Critiques should be expressed in the form of new algorithms.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Grant Grundler
Quoted 8 lines
Algorithm A (a perfect world):
Issue RC16
-> If it fails, issue RC10
-> If it times out, reset the device, issue RC10Algorithm B:
Quoted 7 lines
Quoted 5 lines
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 RC10I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have 0xffffffff LBAs).
Quoted 6 lines
The question really is one you already asked:
Quoted 2 lines
...The question is what to do about devices that either hang or take a long time to respond to an RC16 command.
A few ideas:
1) maintain a blacklist
Which is obviously what we're trying to avoid doing.
Quoted 2 lines
2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality? If so, then something like B or C would make sense.
RC10 only returns number of LBAs and how many bytes per LBA. I don't see anything in the INQUIRY data (other than the protection bit, which we already use to know that RC16 is supported). We could maybe key off scsi_level > SCSI_2 like scsi_device_protection() does. This would work for ATA SSDs because libata reports SCSI ANSI revision 05, but it won't work for USB devices because they get mangled down to SCSI_2, no matter what they support.
Quoted 5 lines
3) How long does Read Capacity16 normally take? e.g. at boot time with drive that isn't spun up yet or equivalent from RAID device.
If it's not that long (e.g < 1sec or so) then just use a shorter
timeout in general?
With parallel scanning, it should be tolerably painful.
I don't know how long it'll take. I was hoping people with experience in this matter would chime in.
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
Quoted 15 lines · Matthew Wilcox
Quoted 14 lines · Grant Grundler
Quoted 13 lines
Algorithm A (a perfect world):
Issue RC16
-> If it fails, issue RC10
-> If it times out, reset the device, issue RC10Algorithm 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
Quoted 5 lines
Quoted 1 line
I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have
0xffffffffLBAs).
Sorry, I was thinking the case of RC16 timing out.
We end up timing out on the RC16 for the given device in both Algo. Current behavior is shaped by device behaviors and the need to get a valid LBA count.
New behavior will be shaped by the same thing PLUS additional fields you pointed out.
Quoted 9 lines
Quoted 7 lines
The question really is one you already asked:
Quoted 2 lines
...The question is what to do about devices that either hang or take a long time to respond to an RC16 command.
A few ideas:
1) maintain a blacklistWhich is obviously what we're trying to avoid doing.
Yes. But it won't be the first blacklist linux kernel has. Similarly, adding a kernel command line flag to modify behavior also sucks.
Quoted 10 lines
Quoted 2 lines
2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality? If so, then something like B or C would make sense.
RC10 only returns number of LBAs and how many bytes per LBA. I don't see anything in the INQUIRY data (other than the protection bit, which we already use to know that RC16 is supported). We could maybe key off
scsi_level>SCSI_2likescsi_device_protection()does. This would work for ATA SSDs because libata reports SCSI ANSI revision 05, but it won't work for USB devices because they get mangled down toSCSI_2, no matter what they support.
Ugh. So fixing this for USB would require sorting out why USB devices get "down graded".
Quoted 9 lines
Quoted 6 lines
3) How long does Read Capacity16 normally take? e.g. at boot time with drive that isn't spun up yet or equivalent from RAID device.
If it's not that long (e.g < 1sec or so) then just use a shorter
timeout in general?
With parallel scanning, it should be tolerably painful.I don't know how long it'll take. I was hoping people with experience in this matter would chime in.
Since this is forward looking, I'd think someone would need to ping HD and other storage vendors. Are any subscribed to linux-scsi?
thanks,
grant
James Bottomley
maintainerQuoted 21 lines · Matthew Wilcox
Quoted 8 lines · Grant Grundler
Quoted 8 lines
Algorithm A (a perfect world):
Issue RC16
-> If it fails, issue RC10
-> If it times out, reset the device, issue RC10Algorithm B:
Quoted 7 lines
Quoted 5 lines
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 RC10I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have
0xffffffffLBAs).
Quoted 8 lines
Quoted 6 lines
The question really is one you already asked:
Quoted 2 lines
...The question is what to do about devices that either hang or take a long time to respond to an RC16 command.
A few ideas:
1) maintain a blacklistWhich is obviously what we're trying to avoid doing.
I don't really see a way of avoiding this ... for USB devices it's probably going to be a requirement.
Quoted 10 lines
Quoted 2 lines
2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality? If so, then something like B or C would make sense.
RC10 only returns number of LBAs and how many bytes per LBA. I don't see anything in the INQUIRY data (other than the protection bit, which we already use to know that RC16 is supported). We could maybe key off
scsi_level>SCSI_2likescsi_device_protection()does. This would work for ATA SSDs because libata reports SCSI ANSI revision 05, but it won't work for USB devices because they get mangled down toSCSI_2, no matter what they support.
That latter piece is fixable. We can also go with the INQUIRY version descriptor information which I don't think USB mangles.
Quoted 8 lines
Quoted 5 lines
3) How long does Read Capacity16 normally take? e.g. at boot time with drive that isn't spun up yet or equivalent from RAID device.
If it's not that long (e.g < 1sec or so) then just use a shorter
timeout in general?
With parallel scanning, it should be tolerably painful.I don't know how long it'll take. I was hoping people with experience in this matter would chime in.
Actually, we can't afford to send READ CAPACITY(16) to failing devices; some of them never come back.
James
Quoted 2 lines · James Bottomley
Actually, we can't afford to send READ CAPACITY(16) to failing devices; some of them never come back.
When you say 'never come back', do you mean:
a) The drive discards the command silently
b) The drive hangs until a reset is issued
c) The drive hangs until it's power-cycled
d) The drive turns into a paperweight
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
James Bottomley
maintainerQuoted 10 lines · Matthew Wilcox
Quoted 2 lines · James Bottomley
Actually, we can't afford to send READ CAPACITY(16) to failing devices; some of them never come back.
When you say 'never come back', do you mean:
a) The drive discards the command silently
b) The drive hangs until a reset is issued
c) The drive hangs until it's power-cycled
d) The drive turns into a paperweight
All of the above ... this is USB ... well, I don't *know* of a D case ... but I wouldn't bet one doesn't exist.
James
Quoted 7 lines · James Bottomley
Quoted 6 lines · Matthew Wilcox
Quoted 2 lines · James Bottomley
Actually, we can't afford to send READ CAPACITY(16) to failing devices; some of them never come back.
When you say 'never come back', do you mean:
Quoted 7 lines
Quoted 4 lines
a) The drive discards the command silently
b) The drive hangs until a reset is issued
c) The drive hangs until it's power-cycled
d) The drive turns into a paperweightAll of the above ... this is USB ... well, I don't *know* of a D case ... but I wouldn't bet one doesn't exist.
The unfortunate thing is that we don't have a collection of INQUIRY results from these devices, so we can't say whether checking for SCSI_2 would eliminate those in categories C and D.
Are you willing to take a patch that sends RC16 for devices claiming SCSI_2, and falls back to RC10 if that doesn't work? Or shall I try to implement algorithm D and talk to T10?
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
James Bottomley
maintainerQuoted 16 lines · Matthew Wilcox
Quoted 7 lines · James Bottomley
Quoted 6 lines · Matthew Wilcox
Quoted 2 lines · James Bottomley
Actually, we can't afford to send READ CAPACITY(16) to failing devices; some of them never come back.
When you say 'never come back', do you mean:
Quoted 7 lines
Quoted 4 lines
a) The drive discards the command silently
b) The drive hangs until a reset is issued
c) The drive hangs until it's power-cycled
d) The drive turns into a paperweightAll of the above ... this is USB ... well, I don't *know* of a D case ... but I wouldn't bet one doesn't exist.
Quoted 7 lines
The unfortunate thing is that we don't have a collection of INQUIRY results from these devices, so we can't say whether checking for
SCSI_2would eliminate those in categories C and D.Are you willing to take a patch that sends RC16 for devices claiming
SCSI_2, and falls back to RC10 if that doesn't work? Or shall I try to implement algorithm D and talk to T10?
Not really ... SCSI_2 is where the problems are. SCSI 3 would be much more acceptable. Then you can add an inquiry passthrough to USB mangling for devices you need to work.
James
Quoted 8 lines · James Bottomley
Quoted 3 lines · Matthew Wilcox
Are you willing to take a patch that sends RC16 for devices claiming
SCSI_2, and falls back to RC10 if that doesn't work? Or shall I try to implement algorithm D and talk to T10?Not really ...
SCSI_2is where the problems are. SCSI 3 would be much more acceptable. Then you can add an inquiry passthrough to USB mangling for devices you need to work.
That works for me. Best of all, I don't care about any USB devices today, so I won't even have to do the second part!
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
Quoted 11 lines · Matthew Wilcox
Quoted 10 lines · Grant Grundler
Quoted 10 lines
Algorithm A (a perfect world):
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
Quoted 6 lines
Quoted 1 line
I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have
0xffffffffLBAs).
Sorry to barge in but I think this is the most practical solution and the one to go to T10 with.
If a (new) device supports RC16 it should return LBAs==0xffffffff for RC10 even if it's capacity is smaller, to indicate an RC16 request.
If LBAs!=0xffffffff and !SCSI_3 then do not risk RC16 unless a white list or load parameter.
Since you are going to T10 with this the white list should be, as you said in other mail, zero length.
Quoted 8 lines
Quoted 5 lines
The question really is one you already asked:
Quoted 2 lines
...The question is what to do about devices that either hang or take a long time to respond to an RC16 command.
A few ideas:
1) maintain a blacklistWhich is obviously what we're trying to avoid doing.
If you are going to T10 with this a white list should be much shorter
Quoted 11 lines
Quoted 2 lines
2) anything in RC10 or IDENTIFY that would clue us about RC16 functionality? If so, then something like B or C would make sense.
RC10 only returns number of LBAs and how many bytes per LBA. I don't see anything in the INQUIRY data (other than the protection bit, which we already use to know that RC16 is supported). We could maybe key off
scsi_level>SCSI_2likescsi_device_protection()does. This would work for ATA SSDs because libata reports SCSI ANSI revision 05, but it won't work for USB devices because they get mangled down toSCSI_2, no matter what they support.
<snip>
This is certainly a bug in the standard, draft as you say. It must be fixed in a backward compatible way. Practical matters aside, the standard can not stay as it is.
Thanks
Boaz
Quoted 15 lines · Boaz Harrosh
Quoted 7 lines · Matthew Wilcox
Quoted 7 lines
Quoted 7 lines
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 RC10Quoted 6 lines
Quoted 1 line
I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have
0xffffffffLBAs).
Quoted 5 lines
Sorry to barge in but I think this is the most practical solution and the one to go to T10 with.
If a (new) device supports RC16 it should return LBAs==0xffffffff for RC10 even if it's capacity is smaller, to indicate an RC16 request.
That breaks compatibility with older software that doesn't know that RC16 exists.
Quoted 5 lines
If LBAs!=0xffffffff and !SCSI_3 then do not risk RC16 unless a white list or load parameter.
Since you are going to T10 with this the white list should be, as you said in other mail, zero length.
I don't need to go to T10 for anything except Algorithm D.
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
Quoted 23 lines · Matthew Wilcox
Quoted 13 lines · Boaz Harrosh
Quoted 7 lines · Matthew Wilcox
Quoted 7 lines
Quoted 7 lines
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 RC10Quoted 5 lines
Quoted 1 line
I fail to see an effective difference between Algo A and B.
Whether to issue an RC10 before issuing an RC16 or not. It matches what we currently do better (we currently issue an RC10 and then issue an RC16 if RC10 reports we have
0xffffffffLBAs).Quoted 5 lines
Sorry to barge in but I think this is the most practical solution and the one to go to T10 with.
If a (new) device supports RC16 it should return LBAs==0xffffffff for RC10 even if it's capacity is smaller, to indicate an RC16 request.
That breaks compatibility with older software that doesn't know that RC16 exists.
Quoted 8 lines
Quoted 5 lines
If LBAs!=0xffffffff and !SCSI_3 then do not risk RC16 unless a white list or load parameter.
Since you are going to T10 with this the white list should be, as you said in other mail, zero length.
I don't need to go to T10 for anything except Algorithm D.
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?
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.
Boaz
Quoted 2 lines · Boaz Harrosh
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?
I'm not sure I've explained myself correctly.
- There are new features from T10 (UNMAP being one of them) that are reported only through the RC16 command.
- We don't currently use RC16 unless:
- The device claims to have more than 4 billion sectors (~= 2TB with 512-byte sectors) OR
- The device claims to support protection information
We need a way to be able to use RC16, or we need to persuade T10 that using RC16 is basically impossible in the real world, so they should stop putting features in it.
James and I seem to have come to a conclusion -- that we'll try RC16 for drives which claim SCSI_3 compliance (which excludes all the current USB devices). It's then up to the USB people to implement a whitelist for not mangling USB devices down to SCSI_2.
Quoted 2 lines
Your tested devices report
SCSI_3? Do all devices that arescsi_level>SCSI_2suppose to support RC16?
My tested devices are all libata which claims SCSI_SPC_2 compliance. Obviously, this is faked.
Signature · 4 lines
Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."
James Bottomley
maintainerQuoted 5 lines · Boaz Harrosh
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 arescsi_level>SCSI_2suppose 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.
Quoted 5 lines
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
Quoted 29 lines · James Bottomley
Quoted 5 lines · Boaz Harrosh
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 arescsi_level>SCSI_2suppose 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.cOur 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_2for them and the world will just work.
Quoted 9 lines
Quoted 5 lines
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
OK Jams Mathew thanks that makes sense.
All these emulation layers being in HW, USB, or SW, libata will have to attempt an higher-then-SCSI_2 if they want RC16 stuff, full stop. That sounds safe to me, and the market will win.
Boaz
Quoted 41 lines · Matthew Wilcox
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 RC10Algorithm 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 RC10Algorithm C:
As algorithm B, except:
-> If it succeeds, use the RC10 results for LBA unless the LBA is0xffffffff
but use the RC16 results for TPE, PROT, etc.
Quoted 7 lines
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