mismatch_cnt != 0

mismatch_cnt != 0

[Justin Piszcz]

Should I be worried?

Fri Feb 22 20:00:02 EST 2008: Executing RAID health check for /dev/md0...
Fri Feb 22 20:00:03 EST 2008: Executing RAID health check for /dev/md1...
Fri Feb 22 20:00:04 EST 2008: Executing RAID health check for /dev/md2...
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/md0/md/mismatch_cnt
Fri Feb 22 21:00:06 EST 2008: 0
Fri Feb 22 21:00:06 EST 2008: cat /sys/block/md1/md/mismatch_cnt
Fri Feb 22 21:00:06 EST 2008: 0
Fri Feb 22 21:00:06 EST 2008: cat /sys/block/md2/md/mismatch_cnt
Fri Feb 22 21:00:06 EST 2008: 0
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:06 EST 2008: The meta-device /dev/md0 has no mismatched
sectors.
Fri Feb 22 21:00:07 EST 2008: The meta-device /dev/md1 has no mismatched
sectors.
Fri Feb 22 21:00:08 EST 2008: The meta-device /dev/md2 has no mismatched
sectors.
Fri Feb 22 21:00:09 EST 2008: The meta-device /dev/md3 has 936 mismatched
sectors.
Fri Feb 22 21:00:09 EST 2008: Executing repair on /dev/md3
Fri Feb 22 22:00:10 EST 2008: cat /sys/block/md0/md/mismatch_cnt
Fri Feb 22 22:00:10 EST 2008: 0
Fri Feb 22 22:00:10 EST 2008: cat /sys/block/md1/md/mismatch_cnt
Fri Feb 22 22:00:10 EST 2008: 0
Fri Feb 22 22:00:10 EST 2008: cat /sys/block/md2/md/mismatch_cnt
Fri Feb 22 22:00:10 EST 2008: 0
Fri Feb 22 22:00:10 EST 2008: cat /sys/block/md3/md/mismatch_cnt
Fri Feb 22 22:00:10 EST 2008: 936

Re: mismatch_cnt != 0

[Michael Tokarev]

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

Re: mismatch_cnt != 0

[Justin Piszcz]

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.

Justin.

Re: mismatch_cnt != 0

[Justin Piszcz]

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.
>
> Justin.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

After a reboot & check, it is back to 0-- interesting..

Justin.

Re: mismatch_cnt != 0

[Carlos Carvalho]

Justin Piszcz (jpiszcz@lucidpixels.com) 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?

Re: mismatch_cnt != 0

[Justin Piszcz]

On Sat, 23 Feb 2008, Carlos Carvalho wrote:

> Justin Piszcz (jpiszcz@lucidpixels.com) 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?

Kernel 2.6.24.2 I've seen it on different occasions, for this last time 
though it may have been due to a power outage that lasted > 2hours and 
obviously the UPS did not hold up that long.

Will keep an eye on this to see if any additional mismatches show up.

Justin.

Re: mismatch_cnt != 0

[Janek Kozicki]

Justin Piszcz said:     (by the date of Sun, 24 Feb 2008 04:26:39 -0500 (EST))

> Kernel 2.6.24.2 I've seen it on different occasions, for this last time 
> though it may have been due to a power outage that lasted > 2hours and 
> obviously the UPS did not hold up that long.

you should connect UPS through RS-232 or USB, and if a power-down
event is detected - issue hibernate or shutdown. Currently I am
issuing hibernate in this case, works pretty well for 2.6.22 and up.

-- 
Janek Kozicki                                                         |

Re: mismatch_cnt != 0

[Justin Piszcz]

On Sun, 24 Feb 2008, Janek Kozicki wrote:

> Justin Piszcz said:     (by the date of Sun, 24 Feb 2008 04:26:39 -0500 (EST))
>
>> Kernel 2.6.24.2 I've seen it on different occasions, for this last time
>> though it may have been due to a power outage that lasted > 2hours and
>> obviously the UPS did not hold up that long.
>
> you should connect UPS through RS-232 or USB, and if a power-down
> event is detected - issue hibernate or shutdown. Currently I am
> issuing hibernate in this case, works pretty well for 2.6.22 and up.
>
> --
> Janek Kozicki                                                         |
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I have it hooked up but it was a weird day for the power going on and off 
many times for upwards of 2-3 hours and then it died for 2+ hours.

Justin.