Re: [PATCH] Online RAID-5 resizing

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

On Thu, Sep 22, 2005 at 06:16:41PM +0200, Neil Brown wrote:
> Yes, that reindenting is a problem as it makes the patch hard to read
> -- it's hard to see which bits need to be checked and which don't.  If
> you could remove them for the next version, it would help....

I'll look into it.

> 1/ in raid5_reshape, rather than allocate a separate set of
>   stripe_heads, I think it would be good to re-size all of the stripes
>   and the continue running with the new set of stripe_heads.

Hm, that's an idea. OTOH, I'm not sure how much code it really saves; you
still need to have a notion about how many disks there are in a stripe, so
you can read and write the correct amount, calculate parity correctly etc...
and thus there is a distinction after all. It's an interesting thought,
though; I'd probably try to get it all working properly first, and then go
onto that later.

> 2/ Reserve the stripe_heads needed for a chunk-resize in make_request
>    (where it is safe to block) rather than in handle_stripe.

Hm. make_request is never called from the sync code, is it? My understanding
was that make_request was called whenever userspace wanted to read/write
something, and only then.

>    Once the reads are done, shuffle the pages (rather then memcpy,
>    just fiddle with pointers), and cause write-out to commence.

Ah, flipping the pointers is a good idea. I was searching for a way of doing
optimized page-to-page memcpy operations, but of course just moving the
pointers will work fine.

I've fixed what I believe is a race condition that might lead to the subtle
corruption I've been seeing (conf->expand_progress can change between the
geometry calculation and actual writing in make_request); I'm testing it now,
but random bugs are naturally hard to verify fixed :-) OTOH, I haven't seen
the problem with uninterruptable sleep for a while, so I hope my other fix
got that.

/* Steinar */
-- 
Homepage: http://www.sesse.net/