On 06/05/2013 12:02 PM, Bernd Schubert wrote:

On 06/04/2013 05:39 PM, Joe Lawrence wrote:

quoted

Just curious, what type drives were in your RAID and what does
/sys/class/scsi_disk/*/max_write_same_blocks report?  If you have a spare
drive to test, maybe you could try a quick sg_write_same command to see
how the drive reacts?

I just run into the same issue with an ancient system from 2006. Except
that I'm in hurry an need it to stress-test my own work, I can do
anything with it - it is booted via NFS and disks are only used for
development/testing.

quoted

(squeeze)fslab1:~# cat /sys/block/md126/queue/write_same_max_bytes
16384

quoted

(squeeze)fslab1:~# cat /sys/block/sd[o,n,m,l]/queue/write_same_max_bytes
0
0
0
0

Ah, now I found the reason why it fails, scsi-layer had set
write_same_max_bytes to zero when it detected that it does not support
it, but after reloading the arecal module (arcmsr) I now get:

quoted

(squeeze)fslab1:~# cat /sys/block/sd[o,n,m,l]/queue/write_same_max_bytes
33553920
33553920
33553920
33553920

In sd_config_write_same() it sets

	if (sdkp->max_ws_blocks == 0)
		sdkp->max_ws_blocks = SD_MAX_WS10_BLOCKS;

except when sdkp->device->no_write_same is set.
But only ata_scsi_sdev_config() sets that. And I also don't see any 
driver setting max_ws_blocks, so everything except of libata gets the 
default of SD_MAX_WS10_BLOCKS. This also seems to be consistent with the 
33553920 I see, except that there is somewhere a bit shift.
So no surprise that mptsas and arcmsr (and anything else) devices have 
write_same_max_bytes set.
As the correct handling in the md layer seems to be difficult, can we 
send a fake request at device configuration time to figure out if the 
device really support write-same?