From: Robert White <rwhite@pobox.com>
To: Gour <gour@atmarama.net>, linux-btrfs@vger.kernel.org
Subject: Re: pro/cons of raid1 with mdadm/lvm2
Date: Mon, 01 Dec 2014 10:19:13 -0800 [thread overview]
Message-ID: <547CB121.9030807@pobox.com> (raw)
In-Reply-To: <20141201102624.1224bc54@atmarama>
On 12/01/2014 01:26 AM, Gour wrote:
> On Mon, 01 Dec 2014 09:06:19 +1100
> Russell Coker <russell@coker.com.au> wrote:
>
>> When the 2 disks have different data mdadm has no way of knowing
>> which one is correct and has a 50% chance of overwriting good data.
>> But BTRFS does checksums on all reads and solves the problem of
>> corrupt data - as long as you don't have 2 corrupt sectors in
>> matching blocks.
>
> Hmm, this is very interesting and valuable info. Thank you.
>
Don't get too excited. If the data disagrees in either system because of
partial starts (e.g. one mount /dev/sda1 is hot, the next mount
/dev/sdb1 is hot) leaving both disks with equally valid but disagreeing
data, "magical guessing" _will_ ensue.
In the BTRFS case the system will guess based on generation numbers.
In the MDADM case the system will guess based on the write intent bitmaps.
In both cases, you are _way_ better off invalidating any missing array
elements if you find yourself reaching a write-available event with said
missing elements.
BTRFS checksums really help when a write goes to both devices (e.g.
/dev/sda1 and /dev/sdb1) and the disk subsystem silently fails one of
the necessary writes, creating a disagreement between the checksum and
the data block on the drive in question.
It's an outstanding feature, but it doesn't protect you from weak
maintenance after a partial start.
next prev parent reply other threads:[~2014-12-01 18:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 11:11 pro/cons of raid1 with mdadm/lvm2 Gour
2014-11-30 22:06 ` Russell Coker
2014-12-01 1:00 ` Chris Murphy
2014-12-01 8:18 ` Russell Coker
2014-12-01 9:30 ` Gour
2014-12-01 9:26 ` Gour
2014-12-01 18:19 ` Robert White [this message]
2014-12-01 5:42 ` Roman Mamedov
2014-12-01 9:33 ` Gour
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=547CB121.9030807@pobox.com \
--to=rwhite@pobox.com \
--cc=gour@atmarama.net \
--cc=linux-btrfs@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox