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@xxxxxxx +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) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
