On Sat, 26 Sep 2015 06:47:26 AM Chris Murphy wrote: > And then > > Aug 28 17:06:49 host mdadm[2751]: RebuildFinished event detected on md > device /dev/md/0, component device mismatches found: 2048 (on raid > level 10) > Aug 28 17:06:49 host mdadm[2751]: SpareActive event detected on md > device /dev/md/0, component device /dev/sdd1 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405919#41 For Linux Software RAID-1 it's expected that you get a multiple of 128 mismatches found every time you do a scan. I don't know why that is, but systems running like that don't appear to have any problems. This even appears to happen on arrays that aren't in any noticable use (EG swap on a server that has heaps of RAM so swap doesn't get used). The above URL describes part of the problem but if that was the entire explanation then I'd expect multiples of 8 not 128. Also the explanation that Neil offers doesn't seem to cover the case of 10,000+ mismatches occurring in the weekly scrubs. Linux Software RAID-10 works the same way in this regard. So I'm not sure that the log entries in question mean anything other than a known bug in Linux Software RAID. I have servers that have been running well for years while repeatedly reporting such errors on Linux Software RAID-1 and not getting any FSCK problems. Note that the servers in question don't run BTRFS because years ago it really wasn't suitable for server use. It is possible that there are errors that aren't detected by e2fsck, don't result in corruption of gzip compressed data, don't give MySQL data consistency errors, and don't corrupt any user data in a noticable way. But it seems to be evidence in support of the theory that such mismatches don't matter. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
