From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: A Big Thank You, and some Notes on Current Recovery Tools.
Date: Tue, 2 Jan 2018 02:03:01 +0000 (UTC) [thread overview]
Message-ID: <pan$e5649$323c2eeb$2471e3a9$d73fbcc8@cox.net> (raw)
In-Reply-To: CAJt7KB-sq0sxHe_3LSC5kzU0CG8ABk4baDnGP138vNaLK0KN-Q@mail.gmail.com
Stirling Westrup posted on Mon, 01 Jan 2018 14:44:43 -0500 as excerpted:
> In hind sight (which is always 20/20), I should have updated the backups
> before starting to make my changes, but as I'd just added a new 4T drive
> to the BTRFS RAID6 in my backup system a week before, and it went as
> smooth as butter, I guess I was feeling insufficiently paranoid.
Are you aware of btrfs raid56-mode history?
If you're running a current enough kernel (wiki says 4.12 for raid56
mode, but you might want 4.14 for other fixes and/or the fact that it's
LTS) the severest known raid56 issues that had it recommendation-
blacklisted are fixed, but raid56 mode still doesn't have fixes for the
infamous parity-raid write hole, and parities are not checksummed, in
hindsight an implementation mistake as it breaks btrfs' otherwise
integrity and checksumming guarantees, that's going to require an on-disk
format change and some major work to fix.
If you're running at least kernel 4.12 and are aware of and understand
the remaining raid56 caveats, raid56 mode can be a valid choice, but if
not, I strongly recommend doing more research to learn and understand
those caveats, before relying too heavily on that backup.
The most reliable and well tested btrfs multi-device mode remains raid1,
tho that's expensive in terms of space required since it duplicates
everything. For many devices, the recommendation seems to remain btrfs
raid1, either straight, or on top of a pair of mdraid0s (or alike,
dmraid0s, hardware raid0s, etc), since that performs better than btrfs
raid10, and removes a confusing tho not harmful if properly understood
layout ambiguity of btrfs raid10 as well.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2018-01-02 2:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:48 A Big Thank You, and some Notes on Current Recovery Tools Stirling Westrup
2018-01-01 5:21 ` Duncan
2018-01-01 10:13 ` Qu Wenruo
2018-01-01 12:15 ` Kai Krakow
2018-01-01 19:44 ` Stirling Westrup
2018-01-02 2:03 ` Duncan [this message]
2018-01-02 10:02 ` ein
2018-01-02 11:15 ` Paul Jones
2018-01-02 12:45 ` Marat Khalili
2018-01-02 14:45 ` ein
2018-01-01 22:50 ` waxhead
2018-01-02 0:57 ` Qu Wenruo
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='pan$e5649$323c2eeb$2471e3a9$d73fbcc8@cox.net' \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox