Re: [PATCH] Online RAID-5 resizing
flat view
From: Neil Brown <hidden>
Date: 2005-09-20 15:01:42
On Tuesday September 20, sgunderson@bigfoot.com wrote:
(Please Cc me on any replies, I'm not subscribed)
ofcourse...
Hi, Attached is a patch (against 2.6.12) for adding online RAID-5 resize capabilities to Linux' RAID code.
Wow! Thanks for this. It's been something that I wanted to be done for some time, but it hasn't got even close to the top of my todo list.
- It's RAID-5 only; I don't really use RAID-0, and RAID-6 would probably be more complex.
I doubt raid6 would be much more difficult. However it is definitely best to get it working well in raid5 first. I'd never thought of doing raid0, but I cannot now think of a good reason not to.....
- It supports only growing, not shrinking. (Not sure if I really care about fixing this one.)
Shrinking certainly adds a lot of complications, and you would have to start at the 'top' and work backwards. Probably not worth the effort, except that people might want to be able to back-out a change...
quoted hunk
- It leaks memory; it doesn't properly free up the old stripes etc. at the end of the resize. (This also makes it impossible to do a grow and then another grow without stopping and starting the volumes.)
I'm sure that can be fixed.
quoted hunk
- There is absolutely no crash recovery -- this shouldn't be so hard to do (just update the superblock every time, with some progress meter, and restart from that spot in case of a crash), but I have no knowledge of the on-disk superblock format at all, so some help would be appreciated here. Also, I'm not really sure what happens if it encounters a bad block during the restripe.
Crash recovery is essential I think. There are some awkward cases, particularly while growing the first few stripes. I'm sure we can work it out together.
quoted hunk
- It's quite slow; on my test system with old IDE disks, it achieves about 1MB/sec. One could probably make a speed/memory tradeoff here, and move more chunks at a time instead of just one by one; I'm a bit concerned about the implications of the kernel allocating something like 64MB in one go, though :-)
I doubt speed is a top priority. I'll try to have a read through your code over the next week or so and give you more detailed feedback. Thanks again, NeilBrown