Re: [PATCH] Online RAID-5 resizing

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

On Fri, Oct 07, 2005 at 01:09:21PM +1000, Neil Brown wrote:
> However it is usually easier to read a whole patch - reading a patch
> that removes bits of a previous patch, and depends on other bits of
> it, requires holding too much in one's brain at once.  If you could
> possibly send a complete patch against a recent release kernel, it
> would make review a lot easier.

Mm, OK.

>> I'm unsure how much this actually buys us (there's a slight reduction in
>> complexity, but I fear that will go up again once I implement it for read
>> stripes as well),
> I think it buys us a lot.  It means we can wait for stripes to become
> free instead of spinning around hoping they will come free soon.

Well, I've been doing printk-debugging on this, and it's actually a quite
rare case (even with heavy I/O) that it's starved for stripes.

> Currently the patch looks mostly good, but there are a couple of
> structural changes that I think it needs as I mentioned previously.
> Once these are in place, I can review the code more closely and look
> for races and other subtle semantic issues.

Mm. I'm still a bit ambivalent about a rewrite; I need something working in
about exactly a month (when we're going to restripe our backup server) and a
rewrite would no doubt destabilize it all for quite a while. My test server
is currently broken after I tried to get in a kdb-enabled kernel; grub
conveniently broke at about the same time :-) I'm not sure how much time I
can dedicate to this ATM either.

I definitely agree moving code into sync_request would result in a better
overall model, though, with less overhead in the usual (non-restripe) paths.

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