On May 7, 2007, at 11:56 AM, Ruslan Sivak wrote:
Isn't a degraded raid5 horribly slow?
For the record, my copy is going slowly. I'm copying files from three out of four RAID-5 drives to the non-RAID drive now, and the RAID is the bottleneck, not the single drive. From eyeballing the iostat output, an md device composed of three ST3320620AS drives is reading anywhere from 30,000-65,000 blocks/sec (individual devices reading 18,000-35,000 blocks/sec), and the other drive (while mostly idle) occasionally shoots up to writes of 120,000 blocks/sec. (I think block size = sector size = 512 bytes, so md read performance of 15 MByte/sec - 33 Mbyte/sec. Not good.)
The time seems to be going into seeks. The CPU's mostly idle (this is software RAID, so that means the parity calculations aren't the problem), and my ears and the "tps" column of iostat say there's a lot of seeking going on. I assume that's due to some combination of degraded RAID-5, the extra LVM layer, fragmentation, the filesystem damage, and possibly a few other processes accessing the RAID array since I've booted off it.
In particular with the fragmentation: some of the larger files were downloaded with rtorrent. I wonder if its access pattern of ftruncate ()ing files to their full length (creating holes) then filling them in with mmap()-based writes encourages the operating system to fragment the file. It also seems to be unusual enough to trigger kernel bugs - there was one recently about data corruption. I wonder if it also triggered whatever bug caused my filesystem to be corrupted.
In any case, the copy's not so slow that it won't finish tonight, which is good enough for me.
-- Scott Lamb <http://www.slamb.org/> _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
