At 9:23 PM -0500 2001-04-15, Jesse Pollard wrote:
> >b) wait with fsck until rebuild is fixed
>
>Depends on your definition of "fixed". The most I can see to fix is
>reduce the amount of continued update in favor of updating those blocks
>being read (by fsck or anything else). This really ought to be a runtime
>configuration option. If it is set to 0, then no automatic repair would
>be done.
The original post was referring to RAID 1; there's no repair necessary at the RAID
level to give fsck the correct data. Seems to me the basic problem here is that the
RAID re-sync is supposed to be throttling back to allow other activity to run, but
that in the case of fsck the other activity is still slower by a large factor
(compared to no RAID re-sync).
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?
--
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
