From: Niobos <niobos@dest-unreach.be>
To: linux-raid@vger.kernel.org
Subject: Re: List of mismatched blocks?
Date: Mon, 05 Jul 2010 12:16:01 +0200 [thread overview]
Message-ID: <i0sbd1$upv$1@dough.gmane.org> (raw)
In-Reply-To: <slrni31knc.mgo.Mario.Holbe@darkside.dyn.samba-tng.org>
On 2010-07-04 20:29, Mario 'BitKoenig' Holbe wrote:
> Niobos <niobos@dest-unreach.be> wrote:
>> I'm running cmp on an active RAID. My guess is that this cause a large
>> number of false positives: cmp reading both members at a different time,
>> and hence reading a different version. That was the main reason to ask
>> for another way to get the mismatching blocks through the raid-layer.
> On high-frequent changes this can unfortunately happen with RAID1 due to
> the handling of dirty pages (there's a thread back in 2k6 here on the
> list where Heinz Mauelshagen explained this quite nice - somewhere below
> the Subject: No syncing after crash. Is this a software raid bug?).
> I didn't notice it anymore since >2.6.26, so I thought it was fixed, but
> this could also be because the probability shrunk due to new hardware.
>
>> I'm running cmp on an active RAID. My guess is that this cause a large
>> number of false positives: cmp reading both members at a different time,
>> and hence reading a different version. That was the main reason to ask
>
> Not very likely unless your filesystem is under very high load. To be
> more specific: I did cmp -l my mirrors regularly before the "check"
> sync_action had been developed (and still do it from time to time -
> never trust... :)) and never experienced such things.
I just did 5 cmp's sequentially, with minutes in between them:
-rw-r--r-- 1 root root 15016204 2010-07-05 09:18 sd[ab]1.1.diff
-rw-r--r-- 1 root root 21404544 2010-07-05 09:49 sd[ab]1.2.diff
-rw-r--r-- 1 root root 40538120 2010-07-05 09:54 sd[ab]1.3.diff
-rw-r--r-- 1 root root 415879184 2010-07-05 10:39 sd[ab]1.4.diff
-rw-r--r-- 1 root root 24811696 2010-07-05 11:45 sd[ab]1.5.diff
From the output-size alone, one can see that something is not working as
described. There are millions of bytes that mismatched at 10:39, that
magically were "fixed" an hour later...
I'm not sure how to quantify "very heavy filesystem load", but I don't
thing it is.
thanks,
Niobos
prev parent reply other threads:[~2010-07-05 10:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-03 17:15 List of mismatched blocks? Niobos
2010-07-03 21:29 ` Mario 'BitKoenig' Holbe
2010-07-04 10:16 ` Niobos
2010-07-04 18:29 ` Mario 'BitKoenig' Holbe
2010-07-05 10:16 ` Niobos [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='i0sbd1$upv$1@dough.gmane.org' \
--to=niobos@dest-unreach.be \
--cc=linux-raid@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.