On Jan 31, 2013, at 1:05 PM, Wolfgang Denk [off-list ref] 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.

quoted

quoted

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.

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html