The event counter (and serial number) only indicates that the superblock is the most
current.
The SB_CLEAN bit is cleared when an array gets started, and is set when it is stopped
(this
automatically happens during a normal shutdown.) But, if the system crashes or the
power gets
yanked, the SB_CLEAN bit will be zero, so the next reboot will trigger a resync to
guarantee the
array is in sync. As far as the md driver knows, you could have been doing heavy i/o
when the
system went down--leaving the array out of sync. There is possibly a way to set
SB_CLEAN during
long idle periods, but then it would have to be cleared before doing any more i/o (i/o
which
might get interrupted.)
<>< Lance.
Sam Horrocks wrote:
> 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.
