Re: mismatch_cnt != 0
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 [EMAIL PROTECTED] 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. - 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
Re: mismatch_cnt != 0
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mismatch_cnt != 0
On Sat, 23 Feb 2008, Carlos Carvalho wrote: 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? 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. - 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
Re: mismatch_cnt != 0
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
Re: mismatch_cnt != 0
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html After a reboot & check, it is back to 0-- interesting.. Justin. - 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
Re: mismatch_cnt != 0
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mismatch_cnt != 0
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 - 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
mismatch_cnt != 0
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 - 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
