[CentOS] Re: LVM Resizing Problem

[Scott Lamb]

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/>