From: Roman Mamedov <rm@romanrm.net>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: I need to P. are we almost there yet?
Date: Sun, 4 Jan 2015 02:58:35 +0500 [thread overview]
Message-ID: <20150104025835.02f0d6b8@natsu> (raw)
In-Reply-To: <pan$872b8$2e173aaa$59613c61$c4e30dfd@cox.net>
On Sat, 3 Jan 2015 13:11:57 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> > What about using btrfs on top of MD raid?
>
> The problem with that is data integrity. mdraid doesn't have it. btrfs
> does.
Most importantly however, you aren't any worse off with Btrfs on top of MD,
than with Btrfs on a single device, or with Ext4/XFS/JFS/etc on top of MD.
Sure you don't get checksum-based recovery from partial corruption of a RAID,
but you do get other features of Btrfs, such as robust snapshot support,
ability to online-resize up and down, compression, and actually, checksum
verification: even if it won't be able to recover from a corruption, at least
it will warn you of it (and you could recover from backups), while other FSes
will pass through the corrupted data silently.
So until Btrfs multi-device support is feature-complete (and yes that includes
performance-wise), running Btrfs in single-device mode on top of MD RAID is
arguably the most optimal way to use Btrfs in a RAID setup.
(Personally I am running Btrfs on top of 7x2TB MD RAID6, 3x2TB MD RAID5 and
2x2TB MD RAID1).
--
With respect,
Roman
next prev parent reply other threads:[~2015-01-03 21:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-29 18:56 I need to P. are we almost there yet? sys.syphus
2014-12-29 19:00 ` sys.syphus
2014-12-29 19:04 ` Hugo Mills
2014-12-29 20:25 ` sys.syphus
2014-12-29 21:50 ` Hugo Mills
2014-12-29 21:16 ` Chris Murphy
2014-12-30 0:20 ` ashford
[not found] ` <CALBWd85UsSih24RhwpmDeMjuMWCKj9dGeuZes5POj6qEFkiz2w@mail.gmail.com>
2014-12-30 17:09 ` Fwd: " Jose Manuel Perez Bethencourt
2014-12-30 21:44 ` Phillip Susi
2014-12-30 23:17 ` ashford
2014-12-31 2:45 ` Phillip Susi
2014-12-31 17:27 ` ashford
2014-12-31 23:38 ` Phillip Susi
2015-01-01 1:26 ` Chris Samuel
2015-01-01 20:12 ` Roger Binns
2015-01-02 3:47 ` Duncan
2015-01-02 13:42 ` Austin S Hemmelgarn
2015-01-02 17:45 ` Brendan Hide
2015-01-02 19:41 ` Austin S Hemmelgarn
2014-12-29 21:13 ` Chris Murphy
2015-01-03 11:34 ` Bob Marley
2015-01-03 13:11 ` Duncan
2015-01-03 18:53 ` Bob Marley
2015-01-03 19:03 ` sys.syphus
2015-01-03 18:55 ` sys.syphus
2015-01-04 3:22 ` Duncan
2015-01-04 3:54 ` Hugo Mills
2015-01-03 21:58 ` Roman Mamedov [this message]
2015-01-04 3:24 ` Duncan
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=20150104025835.02f0d6b8@natsu \
--to=rm@romanrm.net \
--cc=1i5t5.duncan@cox.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 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.