Bug#518834: the issue with mismatch_cnt

Cristian Ionescu-Idbohrn cristian.ionescu-idbohrn at axis.com
Sun May 3 08:46:36 UTC 2009


On Wed, 29 Apr 2009, martin f krafft wrote:

> The following explanation from upstream might help you get better
> sleep at night. I am also forwarding it so that I can present people
> asking on IRC with a link. We'll work on folding this into
> documentation for an upcoming release.
>
> I'll start with the last point from Neil's reply before getting to
> the details:
>
> > Can anyone explain what these mismatches are...is my data at risk?
>
> Data is not at risk.

Alright.  I guess what you're saying is that mismatch reports may be
safely ignored, isn't it?

Still, there are a few spots in Neil's reply that are still confusing me a
bit, like this:

> For RAID5, unexpected mismatches would be a problem, yes.
> But that is not what is being reported.  All the reports related to
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^
> raid1, though raid10 could be affected as well.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Affected?  In the direction of "unexpected mismatches would be a problem"
like for raid5?

> These mismatches can happen for a number of different reasons,
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


> but are most likely when swap is on the array.

Got this whit the swap on the md-array.

> This can conceivably happen with out swap being part of the picture,
> if memory mapped files are used.

Yes.  I see such an example right now.  128 mismatches are reported on
md0 (raid1), on a box partitioned like this:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/vg0-root   4128448    239588   3679148   7% /
tmpfs                  2041940         0   2041940   0% /lib/init/rw
udev                     10240        68     10172   1% /dev
tmpfs                  2041940         4   2041936   1% /dev/shm
/dev/md0                505508     26613    452796   6% /boot
/dev/mapper/vg0-home 103212320  32262236  65707204  33% /home
/dev/mapper/vg0-tmp    2064208     78352   1881000   4% /tmp
/dev/mapper/vg0-usr   10321208   2560548   7236372  27% /usr
/dev/mapper/vg0-local
                      10321208    666104   9130816   7% /usr/local
/dev/mapper/vg0-src   10321208    235028   9561892   3% /usr/src
/dev/mapper/vg0-var   10321208    434184   9362736   5% /var

Filename                                Type            Size    Used    Priority
/dev/mapper/vg0-swap                    partition       4194296 72      -1

Please note, md0 here is a partition where there are no other files than
these:

/boot/System.map-2.6.26-1-686-bigmem
/boot/config-2.6.26-1-686-bigmem
/boot/grub/default
/boot/grub/device.map
/boot/grub/e2fs_stage1_5
/boot/grub/fat_stage1_5
/boot/grub/jfs_stage1_5
/boot/grub/menu.lst
/boot/grub/menu.lst.pre_fcopy
/boot/grub/menu.lst~
/boot/grub/minix_stage1_5
/boot/grub/reiserfs_stage1_5
/boot/grub/stage1
/boot/grub/stage2
/boot/grub/xfs_stage1_5
/boot/initrd.img-2.6.26-1-686-bigmem
/boot/initrd.img-2.6.26-1-686-bigmem.bak
/boot/memtest86+.bin
/boot/vmlinuz-2.6.26-1-686-bigmem

AFAICU, none of these files should need to be mmapped at this particular
point in time:

# uptime
 10:00:07 up 24 days, 23:07,  8 users,  load average: 0.15, 0.03, 0.01

I'm missing something, I can see that :(  But what?
Is it just because I'm not a "believer"?  Sorry.
The problem is still nagginng me.  Ok.  I'll repair that, than wait to see
if it comes back.  My picture is that mismatches should be even less
probable in the above context.  What do you think?

> NeilBrown


Cheers,

-- 
Cristian





More information about the pkg-mdadm-devel mailing list