On 13-09-24 03:12 PM, Jeremy Linton wrote:
On 9/24/2013 12:39 AM, Hannes Reinecke wrote:
My drives support 'report opcodes', and report that write same is
supported: ... 93 16 Write same(16) ...
but no support for page 'b0'. And yes, these are real SAS drives.
So the question is, how many devices get the protect bit in the std
inquiry
incorrect?
To that specific question: all of them get it right because
if they don't the disk (LU) does not support PI (or at least
that is the conclusion the application client should reach).
What the sales blurb for the device may say is another thing.
More generally why are we using WRITE SAME:
a) associated with LB provisioning?
b) associated with PI (DIF)?
c) as an optimized multi-block write of the same contents?
I'm not aware there is any special relationship between WS
and PI. That leaves a) and c) . I'm guessing it is more
important for a) .
If that is mostly correct, how about std inquiry (SPC>2), protect bit,
and then
VPD page 0x86 (or alternatively then do the READ CAPACITY, P_TYPE instead of
page 0x86)?
After all, the set of valid read/write opcodes is limited by the
protection
mode format, yes?
Yes: READ(32), WRITE(32), WRITE SAME(32), VERIFY(32)
and WRITE AND VERIFY(32) are only valid for protection
type 2 (sbc3r35h 4.22.2.2). I'm sure T10 have a good
reason for that but they are keeping that reason to
themselves.
Doug Gilbert
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
