Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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.

  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