I agree, if the two disks are truly out of sync
then the only thing you can do is copy the most recent
data to the out of date disk.
But what I'm seeing is that the two disks are in
sync (at least according to the serial numbers in the
superblock), but due to the SB_CLEAN flag not having
been set to true, the code decides to do a resync anyways,
regardless of the fact that both discs are apparently
in-sync.
And this resync is dangerous - it copies over good data.
On Thu, 30 Mar 2000, D. Lance Robinson wrote:
> 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?
>
>
