Justin Piszcz ([EMAIL PROTECTED]) wrote on 23 February 2008 10:44:
On Sat, 23 Feb 2008, Justin Piszcz wrote:
On Sat, 23 Feb 2008, Michael Tokarev wrote:
Justin Piszcz wrote:
Should I be worried?
Fri Feb 22 20:00:05 EST 2008: Executing RAID health check for /dev/md3...
Fri Feb 22 21:00:06 EST 2008: cat /sys/block/md3/md/mismatch_cnt
Fri Feb 22 21:00:06 EST 2008: 936
Fri Feb 22 21:00:09 EST 2008: Executing repair on /dev/md3
Fri Feb 22 22:00:10 EST 2008: cat /sys/block/md3/md/mismatch_cnt
Fri Feb 22 22:00:10 EST 2008: 936
Your /dev/md3 is a swap, right?
If it's swap, it's quite common to see mismatches here. I don't know
why, and I don't think it's correct (there should be a bug somewhere).
If it's not swap, there should be no mismatches, UNLESS you initially
built your array with --assume-clean.
In any case it's good to understand where those mismatches comes from
in the first place.
As of the difference (or, rather, lack thereof) of the mismatched
blocks after check and repair - that's exactly what expected. Check
found 936 mismatches, and repair corrected exactly the same amount
of them. I.e., if you run check again after repair, you should see
0 mismatches.
/mjt
My /dev/md3 is my main RAID 5 partition. Even after repair, it showed 936,
I
will re-run repair. Also, I did not build my array with --assume-clean and
I
run my check array once a week.
The only situation where there could be mismatches on a clean array is
if you created it with --assume-clean. After a repair, a check should
give zero mismatches, without reboot.
Of course I'm supposing your hardware is working without glitches...
After a reboot check, it is back to 0-- interesting..
Looks like a bug... Which kernel version?
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
