On Jan 31, 2013, at 1:05 PM, Wolfgang Denk <wd@xxxxxxx> wrote: > > Ah! Do you have any pointer for me how to access stuff there? http://koji.fedoraproject.org/koji/ Type in kernel for search. Click on a result that has a green check for state. Find the rpm you want, right click download. You can use rpm -ivh --force to install an older kernel. > >>> With the current Fedora kernel, the first check will report errors >>> which do not go away permanently, not even with a "repair". >> >> This is 3.7.4-204? > > Correct. > >> Hypothetically this should be reproducible by anyone using that kernel, by creating a new raid6, running repair, and then running check and confirming thee mismatch count is non-zero. > > Actually just running check should be sufficient - that was how I > discovered the issue: I received warning mails from the "raid-check" > cron job. But check alone doesn't reproduce the problem because the check *might* be finding valid mismatches, however unlikely on a new raid array. The problem is doing a repair which should fix any mismatches, running check still finding mismatches then is a huge bug for the scrub process for sure; and if some parity is actually being computed wrong, or written on disk wrong, then it's a possible data loss bug in addition. Not just (maybe bogus) errors. > This is what surprises me most. I would have expected at least some > "me too!" by now… If there were a study that said 95% of users using md raid never do scrubs, either check or repair, I would not be surprised at all. > For me it is sufficient to: > > - boot the 3.7.4-204 > - bring up the array > - run "check" > > It comes up with mismatch_cnt=0 after boot, and some huge number while > / after the check. If check is non-zero following a repair, with one kernel version but not another, it's a software bug. Chris Murphy -- 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
