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.
--
Jon
--
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
