Greetings, I was posting a question on non-zero mismatch_cnt here a while ago. Now I have backed up all the data (from both replicas of the mirror, and the two data copies turned out to be identical), so I was finally free to mess with my mirror w/o risking the data. Mi first idea was that the metadata (ownership, mtime, ctime, atime) have diverged, so I ran chown -R (a couple of times) with a touch (recursively) Then I once again zeroed out the free space (with zerofree). The above didn't help, with mismatch_cnt holding at 1024. Then I deleted the data, removed and re-created disk partitions (within the raid1 device), formatted the partitions as ext4, ran tune2fs and zeroed out the free space -- yet another time. Now I have 3 empty ext4 partitions with only lost+found directories. And the value of mismatch_cnt dropped to 384. Okay, so far, so good. I don't have any data, so a repair action can't possibly harm it. > echo repair >>/sys/block/md4/md/sync_action And the value of mismatch_cnt is still 384. My first guess was that one of the hard drives was degrading, but SMART attributes of both disks are ok (and nearly identical). Can you please propose the explanation of the non-zero value? And what else can I do to finally make it drop to zero (w/o reassembling the whole array)? Regards, Andrey.
