On Thu, 25 Jun 2015 10:19:59 +0500 Roman Mamedov <rm@xxxxxxxxxxx> wrote: > On Thu, 25 Jun 2015 11:33:35 +1000 > NeilBrown <neilb@xxxxxxxx> wrote: > > > On Sun, 14 Jun 2015 20:13:16 +0300 tlknv <tlknv@xxxxxxxxx> wrote: > > > > > Hello, > > > > > I have raid 1 which mirrors a root/boot partition on 1SSD and 2HDD > > > (write-mostly). mismatch_cnt goes up even when there are very few > > > writes to the partition as /var is mounted separatly. After I update > > > several packages I typically see mismatch_cnt somewhere between > > > 500,000 and 2,000,000. I have read a number of threads in this DL > > > but could not find an explanation of what could cause mismatch_cnt > > > to grow that much. I checked md5 sums using > > > /var/lib/dpkg/info/*.md5sums, and didn't see many errors, even > > > though there are few, mostly in text files which look ok to me. I > > > guess when I check, all reads go to SSD (as both HDDs in this raid > > > are write-mostly), and thus md5sum only shows no problem on > > > SSD. Note, this partition is used as both boot and root and just in > > > case here is some more info about my system: > > > > This does surprise me. > > > > I had another look at the code and there could be a bug that would let > > 'check' see the difference between when the first write completes and > > when the write-behind writes complete, but you would need to run the > > check while the install was happening for that to be noticed, and even > > then you would need to be unlucky. > > Couldn't this be simply the normal observed effect of using TRIM on SSD? Yes, of course it could. I try not to think about TRIM to much - makes me ill :-) Thanks, NeilBrown > After deleting some files, the filesystem issues a discard request, it > does nothing to the HDDs, but the content of the discared areas on SSD is no > longer deterministic (or mostly zeroed, as mentioned in the original report). > So there is now a mismatch between the content of HDDs and SSD, but since it > is in the area of deleted files, it doesn't affect the system in any way. > -- 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
