Re: [PATCH] Online RAID-5 resizing

["Steinar H. Gunderson" <sgunderson@bigfoot.com>]

On Wed, Sep 21, 2005 at 01:01:42AM +1000, Neil Brown wrote:
> 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...

I worked on EVMS' resizing code prior to doing this, and it seems like a
resize was simply doing it the other way without any further complications...
I don't know how the underlying block layer in Linux would like it, though.

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

Yes, of course; it's mostly about not having gotten around to doing it yet. A
good start would be doing shrink_stripes(), but the “finish up the expanding”
code is currently called from __release_stripe() when the last stripe from
the old array is freed, and thus is done under the device_lock, and I had
problems doing memory management under the spinlock. The correct solution
would probably be moving it into raid5d, outside the spinlock.

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

Mm, or at least the very first stripe. I'm not really sure if it's worth it,
though; perfect crash recovery is pretty hard (for one, you'd have to disable
all write caching on the destination disks), and I'm not sure how probable
a power loss 20ms into the resizing is.

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

Well, with multi-terabyte arrays, restriping at those speeds will take
_weeks_, so more speed is always good. I agree that we don't need to be
pushing it very hard, though.

> I'll try to have a read through your code over the next week or so and
> give you more detailed feedback.

OK, thanks. :-) There's a lot of unneeded junk in the patch, BTW (some
reindenting here and there that I don't know where is coming from, plus lots
of temporary added printks), but I guess we can sort out the cleanness after
a while. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html