On 06/05/2013 12:02 PM, Bernd Schubert wrote:
On 06/04/2013 05:39 PM, Joe Lawrence wrote:
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.
(squeeze)fslab1:~# cat /sys/block/md126/queue/write_same_max_bytes
16384
(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:
(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?
--
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
