Re: [dm-devel] SCSI's heuristics for enabling WRITE SAME still need work [was: dm mpath: disable WRITE SAME if it fails]

[Douglas Gilbert <dgilbert@interlog.com>]

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