* mismatch_cnt != 0 @ 2008-02-23 9:34 Justin Piszcz 2008-02-23 13:19 ` Michael Tokarev 0 siblings, 1 reply; 8+ messages in thread From: Justin Piszcz @ 2008-02-23 9:34 UTC (permalink / raw) To: linux-raid 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-23 9:34 mismatch_cnt != 0 Justin Piszcz @ 2008-02-23 13:19 ` Michael Tokarev 2008-02-23 14:05 ` Justin Piszcz 0 siblings, 1 reply; 8+ messages in thread From: Michael Tokarev @ 2008-02-23 13:19 UTC (permalink / raw) To: Justin Piszcz; +Cc: linux-raid 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-23 13:19 ` Michael Tokarev @ 2008-02-23 14:05 ` Justin Piszcz 2008-02-23 15:44 ` Justin Piszcz 0 siblings, 1 reply; 8+ messages in thread From: Justin Piszcz @ 2008-02-23 14:05 UTC (permalink / raw) To: Michael Tokarev; +Cc: linux-raid 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-23 14:05 ` Justin Piszcz @ 2008-02-23 15:44 ` Justin Piszcz 2008-02-24 1:33 ` Carlos Carvalho 0 siblings, 1 reply; 8+ messages in thread From: Justin Piszcz @ 2008-02-23 15:44 UTC (permalink / raw) To: Michael Tokarev; +Cc: linux-raid 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-23 15:44 ` Justin Piszcz @ 2008-02-24 1:33 ` Carlos Carvalho 2008-02-24 9:26 ` Justin Piszcz 0 siblings, 1 reply; 8+ messages in thread From: Carlos Carvalho @ 2008-02-24 1:33 UTC (permalink / raw) To: linux-raid 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-24 1:33 ` Carlos Carvalho @ 2008-02-24 9:26 ` Justin Piszcz 2008-02-24 16:38 ` Janek Kozicki 0 siblings, 1 reply; 8+ messages in thread From: Justin Piszcz @ 2008-02-24 9:26 UTC (permalink / raw) To: Carlos Carvalho; +Cc: linux-raid 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-24 9:26 ` Justin Piszcz @ 2008-02-24 16:38 ` Janek Kozicki 2008-02-25 12:05 ` Justin Piszcz 0 siblings, 1 reply; 8+ messages in thread From: Janek Kozicki @ 2008-02-24 16:38 UTC (permalink / raw) To: linux-raid 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 | ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: mismatch_cnt != 0 2008-02-24 16:38 ` Janek Kozicki @ 2008-02-25 12:05 ` Justin Piszcz 0 siblings, 0 replies; 8+ messages in thread From: Justin Piszcz @ 2008-02-25 12:05 UTC (permalink / raw) To: Janek Kozicki; +Cc: linux-raid 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. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-02-25 12:05 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-02-23 9:34 mismatch_cnt != 0 Justin Piszcz 2008-02-23 13:19 ` Michael Tokarev 2008-02-23 14:05 ` Justin Piszcz 2008-02-23 15:44 ` Justin Piszcz 2008-02-24 1:33 ` Carlos Carvalho 2008-02-24 9:26 ` Justin Piszcz 2008-02-24 16:38 ` Janek Kozicki 2008-02-25 12:05 ` Justin Piszcz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).