On Sun, Aug 03, 2008 at 07:32:00AM -0500, Jon Nelson wrote: > After digging through the code (admittedly, way too late at night), I > think I have a basic understanding of how the resync code works, and > why it appears to be suboptimal (speed-wise) for raid10. > > It would appear that, upon receipt of a 'check' (other resync methods > have different paths, sometimes), md.c basically says, "start at the > first sector or the first sector after the checkpoint and proceed > logically through the end (unless told to stop)' and md.c schedules > this check with the relevant sync_request method. For raid10, this > finds the first device with that logical sector as a copy and then > compares the data there to the data in all of the other copies on the > other disks. For raid10 in f2 format (and to a less extent with the > offset format) this is going to result in a great deal of thrashing. > I'm guessing this is the reason why a 'check' operation raid10,f2 > takes 2x as long as for raid5 (same disks). One way to improve the > efficiency here would be to perform a loop like this: > > for device in devices: > for chunk that is not a mirror: > read chunk > compare chunk to mirror chunks on other devices > > If I'm not wrong this should result in near streaming speeds from each > device with a minimum of seeking. However, to effect this change it > looks like the changes would be more invasive than just changing > raid10.c. One way, of course, might be to abstract the sync code just > a bit more so that md.c could ask each device to provide a function > which does the driving (the above 4 lines) and md.c does all of the > common error checking, interrupt checking, etc... Does this seem like > crazy talk? If I can get some help I might give it a stab. My idea is to do the checks in bigger blocks, then you would minimize the trashing, by minimizing the number of times you need to move the head. And this would not need much change in the code. I have done a patch to do this, but I have not yet tested it. Best regards keld -- 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
