When I was examining a reported performance degradation, I found out that
the reason was buggy firmware in Maxtor Atlas 15K2 SCSI disks. If the
requests are larger than 256kB, read rate drops excessively, even to one
half of the normal read rate.
Performance on these disks improves if the request size is limited with
echo 256 >/sys/block/sdc/queue/max_sectors_kb
I remember seeing similar problem (increased transfer size => decreased
performance) with IDE and SATA Maxtor disks some times ago, but I don't
have any such disk to test currently.
I'd like to ask other people with Maxtor disks to run this script (with
"sda", "sdb", etc. as an argument ... without "/dev/" prefix). The script
measures read rate as a function of request size. Report the results, so
that it can be determined which disks are buggy and which not and the
default transfer size could be reduced to 256kB for the buggy ones.
Note: fiddling with caching mode page (chaning DPTL, MAPF and MAPFC to -1)
improved performance for large requests somehow (to 70-80MB/s), but I
couldn't find a combination of settings that would restore 95MB/s rate, as
for <= 256kB request. Thus, the correct workaround for these disks is to
never send > 256kB requests.
Mikulas
#!/bin/sh
DISK="$1"
echo 1024 >/sys/block/$DISK/queue/max_sectors_kb
echo `cat /sys/block/$DISK/device/vendor /sys/block/$DISK/device/model /sys/block/$DISK/device/rev /sys/block/$DISK/device/firmware 2>/dev/null`
for i in `seq 64 64 1024`; do
blocks=`expr 200000 / $i`
echo -n "$i kB: "
dd if=/dev/$DISK of=/dev/null iflag=direct bs=$i"k" count=$blocks 2>&1 | sed -n 's/.*s, //p'
done
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Testers needed - Maxtor performance degradation
