Yes, I meant repair, sorry. I checked my bash history and I did indeed order a repair (echo repair >/sys/block/md0/md/sync_action). I think I called it a resync because that's what /proc/mdstat told me it was doing. On Sat, 2007-02-24 at 04:50 -0500, Justin Piszcz wrote: > A resync? You're supposed to run a 'repair' are you not? > > Justin. > > On Sat, 24 Feb 2007, Jason Rainforest wrote: > > > I tried doing a check, found a mismatch_cnt of 8 (7*250Gb SW RAID5, > > multiple controllers on Linux 2.6.19.2, SMP x86-64 on Athlon64 X2 4200 > > +). > > > > I then ordered a resync. The mismatch_cnt returned to 0 at the start of > > the resync, but around the same time that it went up to 8 with the > > check, it went up to 8 in the resync. After the resync, it still is 8. I > > haven't ordered a check since the resync completed. > > > > > > On Sat, 2007-02-24 at 04:37 -0500, Justin Piszcz wrote: > >> Of course you could just run repair but then you would never know that > >> mismatch_cnt was > 0. > >> > >> Justin. > >> > >> On Sat, 24 Feb 2007, Justin Piszcz wrote: > >> > >>> Perhaps, > >>> > >>> The way it works (I believe is as follows) > >>> > >>> 1. echo check > sync_action > >>> 2. If mismatch_cnt > 0 then run: > >>> 3. echo repair > sync_action > >>> 4. Re-run #1 > >>> 5. Check to make sure it is back to 0. > >>> > >>> Justin. > >>> > >>> On Sat, 24 Feb 2007, Eyal Lebedinsky wrote: > >>> > >>>> I did a resync since, which ended up with the same mismatch_cnt of 184. > >>>> I noticed that the count *was* reset to zero when the resync started, > >>>> but ended up with 184 (same as after the check). > >>>> > >>>> I thought that the resync just calculates fresh parity and does not > >>>> bother checking if it is different. So what does this final count mean? > >>>> > >>>> This leads me to ask: why bother doing a check if I will always run > >>>> a resync after an error - better run a resync in the first place? > >>>> > >>>> -- > >>>> Eyal Lebedinsky (eyal@xxxxxxxxxxxxxx) <http://samba.org/eyal/> > >>>> attach .zip as .dat > >>>> - > >>>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in > >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx > >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html > >>>> > >>> > >> - > >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in > >> the body of a message to majordomo@xxxxxxxxxxxxxxx > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > - > > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
