On Fri, 17 Sep 2010 22:40:54 -0500 Jon Nelson <jnelson-linux-raid@xxxxxxxxxxx> wrote: > I have a raid10f2 across 2 drives. > I happened to note (only by chance!) that mismatch_cnt was 128, after > a periodic 'check' (/sys/block/md0/md/sync_action). > A quick google seemed to suggest that a 'repair' was in order. > mismatch_cnt reset to 0, and I waited 2 hours. > mismatch_cnt is now 128 again, but *no* kernel messages about the > repair were output, except: > > [463639.341245] md: requested-resync of RAID array md0 > [463639.341252] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. > [463639.341257] md: using maximum available idle IO bandwidth (but not > more than 200000 KB/sec) for requested-resync. > [463639.341266] md: using 128k window, over a total of 483401728 blocks. > [470612.805202] md: md0: requested-resync done. > > This does not seem to be right. > > Kernel: 2.6.34.4-0 from openSUSE 11.3 x86_64. > Depends on what you mean by "right". mismatch count is increased by both 'check' and 'repair'. So 'repair' confirms that it found the same things that 'check' found (or the same number of them). raid10 does not report any mismatches found or corrected in the kernel logs, though it would report if it failed to correct something. So the conclusion we can draw is that raid10 attempted to correct all the inconsistencies it found, and no error was reported during that correction. So it is fairly likely that the inconsistency is actually corrected. The best way to be sure is to run another 'check'. Maybe raid10 (and other levels) should report inconsistencies when they are found - I'm not sure. Certainly they shouldn't during an initial sync, but that is fairly easy to detect. Equally any reports should be carefully rate-limited so as not to produce too much noise, but that is fairly easy too. All that is required (assuming this is actually a good idea) is for someone to do the work. :-) NeilBrown -- 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
