Re: [Evms-devel] RAID5 Expansion Question

[Kevin C. <kev...@us...>]

On Mon May 23 2005 11:26 am, David M. Strang wrote:
> On Monday, May 23, 2005 10:53 AM, Mike Tran wrote:
> >> Hello -
> >>
> >> I just recently began looking at EVMS because I'm looking to 'grow' my
> >> software raid 5. The raid consists of 14x72GB - I'm looking to double
> >> it in size to 28x72GB.
> >
> >Make sure that the raid5 array was created using MD super block format
> >1.  With MD 0.90 super block, The maximum number of disks supported is
> >27.
>
> /dev/md0:
>         Version : 00.90.01
>   Creation Time : Sat Mar 19 08:46:12 2005
>      Raid Level : raid5
>      Array Size : 931864960 (888.70 GiB 954.23 GB)
>     Device Size : 71681920 (68.36 GiB 73.40 GB)
>    Raid Devices : 14
>   Total Devices : 14
> Preferred Minor : 0
>     Persistence : Superblock is persistent
>
>
> Looks like I'm using the old superblock; is it possible to upgrade it?

I don't believe there's a way to switch the superblock version. Thus, you're 
limited to 27 disks. Of course, I'm not sure that making a 27-way raid5 is 
the best approach. First, with raid5 you can only lose one disk at a time and 
still have a useable array. Obviously the more disks you add, the higher the 
chance of multiple disks failing at the same time. Second, the more disks you 
add, the bigger a performance hit you're going to take on writes. Every write 
to a raid5 must update the parity for the stripe that is written to. The MD 
driver does do some caching to help this, but in the worst case a single 
write can cause 25 reads to get all the data to calculate the parity for that 
stripe.

It might be easier in this case to simply create a second raid5 region and 
drive-link the two together. It's even easier if you've built an LVM 
container on top of the raid5. You would simply add the new raid5 to the 
container and expand the LVM regions as desired onto the new freespace.

> >> The time estimates are like 256 hours... 10.5 days. Is this even close
> >> to accurate? Does anyone have any timings on growing a raid? It almost
> >> seems like it would be faster to back up the raid, recreate it, and
> >> restore the raid.
> >
> >lowering the evms logging level to "error" might help.
> >
> >If your file system data is much less than 14x72GB, I would do back up,
> >create a new raid5 and then restore data. It will be interesting to find
> >out the total time for this procedure.
>
> I do have a complete backup; however I'm sitting at 78% used - While I
> could do the backup / recreate / restore method;
> I'm looking for a best practice. It may not always be possible / worthwhile
> to do a full backup restore.

There's definitely a big performance issue with raid5 resizes. Unfortunately, 
I've not had the time to do an in-depth analysis of the performance to try to 
find ways to cut down on the resize time. But, it's on my EVMS to-do list. :)

-- 
Kevin Corry
kev...@us...
http://www.ibm.com/linux/
http://evms.sourceforge.net/