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

[Hannes Reinecke]

On 09/23/2013 08:18 PM, Ewan Milne wrote:
> On Fri, 2013-09-20 at 18:03 -0400, Martin K. Petersen wrote:
> ...
>> Only a handful of the very latest and greatest devices support RSOC. The
>> number of devices that support WRITE SAME is orders of magnitude larger.
>>
>> Last I checked I had exactly 1 out of about 100 devices in my lab that
>> supported RSOC.
> ...
>> The major headache here of course is that WRITE SAME is inherently
>> destructive. We can't just fire off one during discovery and see if it
>> works. For WRITE you can issue a command with a transfer length of 0 to
>> see if things work. But unfortunately for WRITE SAME a transfer length
>> of zero means "wipe the entire device". Yikes!
>>
>> I guess we could read one sector and try to write it back using WRITE
>> SAME and a block count of one. But it's really icky. And I don't like
>> the notion of actually writing things during discovery.
> ...
> 
> Just out of curiosity, what do the devices that support WRITE SAME
> report for the MAXIMUM WRITE SAME LENGTH field in VPD page B0?  The
> spec says that this can be zero if there is no restriction, but is
> there any chance that most/all of them report some nonzero value?
> 
> Expanding on Doug's thinking, perhaps there is some combination of
> VPD page availability / field values that could be used to explicitly
> enable WRITE SAME?  Or, have you been through that already?
> 
Hehe. Won't do any good.

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.

Cheers,

Hannes

-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare at suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)