On Jan 27, 2013, at 11:36 PM, Wolfgang Denk <wd@xxxxxxx> wrote: > > No. These are all 512 byte sector drives. 362732152 comes out to a max of 173GiB of mismatching sectors for a 512 byte sector size. In any case, the mistmatch count is not trivial, even if it's not a lot of sectors relative to the size of the array. > >> What file system? > > ext4 on all of these. And what does fsck.ext4 -f -n get you? >> Have you done only a check or also a repair, either before or after the upgrade? (I'm not suggesting doing a repair now.) > > I did only a check. I rebootetd two of the systems, which made the > mismatch_cnt go back to zero. Of course I don;t know if this means > everything is fine now. No, it's fine when you write check to md/sync_action, and upon completion md/mismatch_cnt is 0. > >> A check should cause URE's to be fixed, but you don't get a count against them because chunk and parity end up being the same for the check after being fixed. >> >> Are there any messages in dmesg for the time of the check? I would like to know what was recorded in dmesg at the time the mismatches were found. > > There is absolutely nothing to be seen in the logs; I also routinely > monitor the drives for reallocated, offline uncorrectable and pending > sectors, and nothing can be seen here either. > > I would like to point out that all these systems have been up an > running essentially unchanged for many months, even years (OK, the old > Maxtor drive based one needs a disk swap every few weeks, but this is > because the disks have reached EOL). No such problem has been observed > ever before, but now it happens at the first check operation after > switching to Fedora 18, simultaneous on all systems … Switching to Fedora 18 means many things have changed so it's harder to find out, if software, what's causing it. Is it kernel itself, is it md, is it the HBA driver? Chris Murphy-- 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
