From: David M. S. <ds...@sh...> - 2005-05-26 15:35:14
|
----- Original Message ----- From: Kevin Corry To: evm...@li... Cc: David M. Strang Sent: Thursday, May 26, 2005 11:03 AM Subject: Re: [Evms-devel] RAID5 Expansion Question > 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. This is what I started to do initially; except I screwed up creating the drive-link feature. I did an 'Add Feature' to each array and added a drivelink... I couldn't remove it; so I ended up trashing the entire array and recreating it. I'm in the middle of restore now. The writes are moderately respectable still. I'm getting 650MB/minute from the tape drive; which is only 200MB/minute slower than the backup. I didn't try a write to the single array; but I know reads are much faster than writes anyways. > > > >> 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. > :) Part of it may just be the pain of a software raid 5 itself. It took nearly 10 hours to synchronize an empty 1.9TB software raid. I'm curious to know how much faster it would be hardware based... -- David M. Strang |