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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
