It is a very bad idea to prevent resyncs after a volume has possibly becoming out of
sync.
It is important to have the disks in sync--even if the data is the wrong data. The way
raid-1's balancing works, you don't know what disk will be read. For the same block,
the
system may read different disks at a different times. This type of inconsistency is
worse
than starting with bad data. Fsck can correct most inconsistencies in the data, but if
different data is possibly hidden, fsck cannot do anything about it and the data will
eventually come out.
Also, with raid-5, if the array is not in sync and has a disk failure (thus goes into
degraded mode,) the data generated using bad parity will be bad data.
<>< Lance.
Sam wrote:
> OK, regardless of how the failure occurs, my point is that a
> resync is a potentially dangerous operation if you don't
> know beforehand whether the source disk has bad sectors or not.
> So I don't think a resync should be performed except when
> absolutely necessary, or unless the source disk is known to
> be absolutely free from errors.
>
> Can someone answer my original question which was:
>
> Could the SB_CLEAN flag be eliminated to reduce the
> risk of a resync damaging good data?
