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
Now for example
11:0:1:2] disk Hitachi HDS724040KLSA80 R001 /dev/sdl /dev/sg11
(squeeze)fslab1:~# sg_write_same --num=100 /dev/sg11
Write same(10) command not supported
(squeeze)fslab1:~# sg_write_same --16 --num=100 /dev/sg11
Write same(16) command not supported
Cheers,
Bernd
PS: This is the 2nd time this I run into this, on Sunday I had a similar
same issue at home with Ubuntus 3.8 kernel, but somehow not with vanilla
3.9. I need to recheck the logs in evening to see if it is really the
same issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
