If I've got the numbering right;
0 - concatenated stripes => no sync required
1 - mirrored => resync required
a: which drive has the correct info?
b: having determined that, read the correct block,
it must now be written to the mirror.
all others => resync required (rebuild possible bad block)
>Is this a pathological case because of the way fsck does business, or does
>the RAID re-sync affect any disk-bound process that severely?
My experience has been with hardware raid, and even then there has been
a 1-5% decrease in I/O during resync (not accurately measured - fsck took
longer, and then only when the channel is maxed out -- otherwise the 1-5% is
not visible; filesystem was 3 IRIX efs, spread across two raid luns).
fsck is particularly bad, since nearly every read instigates a write to
the mirror drive. Fsck can then modify the block and write it back, causing
two more writes; for a total of 3 writes for a read (worst case).
It does mean that when fsck finishes, MOST of the re-sync will be finished.
All of the metadata will be synced, and only file data blocks will remain.
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: jesse@cats-chateau.netAny opinions expressed are solely my own. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/