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

Reply via email to