From: Chris Murphy <lists@colorremedies.com>
To: Adam Borowski <kilobyte@angband.pl>
Cc: Klaus Agnoletti <klaus@agnoletti.dk>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: A partially failing disk in raid0 needs replacement
Date: Tue, 14 Nov 2017 19:54:14 -0700 [thread overview]
Message-ID: <CAJCQCtSWU81jZSiY0KRgPC2ufgihnvxfWtZbQNB5SJMZP+e0BA@mail.gmail.com> (raw)
In-Reply-To: <20171114123829.r4kmvsp6aeuylo67@angband.pl>
On Tue, Nov 14, 2017 at 5:38 AM, Adam Borowski <kilobyte@angband.pl> wrote:
> On Tue, Nov 14, 2017 at 10:36:22AM +0200, Klaus Agnoletti wrote:
>> I used to have 3x2TB in a btrfs in raid0. A few weeks ago, one of the
> ^^^^^
>> 2TB disks started giving me I/O errors in dmesg like this:
>>
>> [388659.188988] Add. Sense: Unrecovered read error - auto reallocate failed
>
> Alas, chances to recover anything are pretty slim. That's RAID0 metadata
> for you.
>
> On the other hand, losing any non-trivial file while being able to gape at
> intact metadata isn't that much better, thus -mraid0 isn't completely
> unreasonable.
I don't know the statistics on UNC read error vs total drive failure.
If I thought that total drive failure was 2x or more likely than a
single UNC then maybe raid0 is reasonable. But it's a 64KB block size
for raid0. I think metadata raid0 probably doesn't offer that much
performance improvement over raid1, and if it did, that's a case for
raid10 metadata.
In the UNC case, chances are it hits a data extent of a single file,
in which case Btrfs can handle this fine, you just lose that one file.
And if it hits the smaller target of metadata, it's fine if metadata
is raid1 or raid10.
In a previous email in the archives, I did a test where I
intentionally formatted one member drive of a Btrfs data raid0,
metadata raid1, and it was totally recoverable with a bunch of scary
messages and sometimes a file was corrupted. So it actually is pretty
darn resilient when there is a copy of metadata. (I did not try DUP.)
--
Chris Murphy
next prev parent reply other threads:[~2017-11-15 2:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-14 8:36 A partially failing disk in raid0 needs replacement Klaus Agnoletti
2017-11-14 12:38 ` Adam Borowski
2017-11-15 2:54 ` Chris Murphy [this message]
2017-11-14 12:48 ` Roman Mamedov
2017-11-14 12:58 ` Austin S. Hemmelgarn
2017-11-14 14:09 ` Klaus Agnoletti
2017-11-14 14:44 ` Roman Mamedov
2017-11-14 15:43 ` Klaus Agnoletti
2017-11-26 9:04 ` Klaus Agnoletti
2017-11-14 14:43 ` Kai Krakow
2017-11-15 2:56 ` Chris Murphy
2017-11-14 12:54 ` Patrik Lundquist
2017-11-14 13:14 ` Austin S. Hemmelgarn
2017-11-14 14:10 ` Klaus Agnoletti
2017-11-15 2:47 ` Chris Murphy
2017-11-29 13:33 ` Klaus Agnoletti
2017-11-29 21:58 ` Chris Murphy
2017-11-30 5:28 ` Klaus Agnoletti
2017-11-30 6:03 ` Chris Murphy
2017-11-30 6:41 ` Klaus Agnoletti
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=CAJCQCtSWU81jZSiY0KRgPC2ufgihnvxfWtZbQNB5SJMZP+e0BA@mail.gmail.com \
--to=lists@colorremedies.com \
--cc=kilobyte@angband.pl \
--cc=klaus@agnoletti.dk \
--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;
as well as URLs for NNTP newsgroup(s).