On Friday October 14, sgunderson@xxxxxxxxxxx wrote: > 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. > > Here's the latest version of the patch. What's been done since last > time: Thanks a lot for this, I really appreciate it! > > - There's no longer a set of $,1r|(Blarger$,1r}(B stripes; instead, they're all shrunk > and then expanded, like you requested the last time. > - The expand stripes are preallocated in sync_request(), again like you > requested. > - Likewise, the raid5_conf struct is never reallocated; instead, I just make > sure it supports MAX_MD_DEVS devices in the first place. This wasted a > kilobyte or so per active device, but it removed a _lot_ of fiddly code, > so I believe it's a good thing. I really don't like having hard-coded maximums like this. However it makes perfect sense to keep that piece of code really simple while we make sure the rest of the code work. So I'm happy for it to stay with a hard-coded maximum for now, but I will probably want to change it back to re-allocating raid5_conf once the rest of the code is stable. > - The patch in general is a lot slimmer (about half the size of the original > patch). Lots of special-case code has been thrown out and replaced by using > the generic functions instead (for, say, all the parity disk layout stuff). Half the size sounds like a great step forward!! :-) I'll have a close look at all the code sometime today and get back to you with any comments. Thanks again, NeilBrown - 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
