From: Alexandre Oliva <oliva@gnu.org>
To: Brendan Hide <brendan@swiftspirit.co.za>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid5
Date: Tue, 22 Oct 2013 17:24:37 -0200 [thread overview]
Message-ID: <ory55l85xm.fsf@livre.home> (raw)
In-Reply-To: <5266B87D.9080202@swiftspirit.co.za> (Brendan Hide's message of "Tue, 22 Oct 2013 19:40:13 +0200")
On Oct 22, 2013, Brendan Hide <brendan@swiftspirit.co.za> wrote:
> On 2013/10/22 07:18 PM, Alexandre Oliva wrote:
>> ... and
>> it is surely an improvement over the current state of raid56 in btrfs,
>> so it might be a good idea to put it in.
> I suspect the issue is that, while it sortof works, we don't really
> want to push people to use it half-baked.
I don't think the current state of the implementation upstream is
compatible with that statement ;-)
One can create and run a glorified raid0 that computes and updates
parity blocks it won't use for anything, while the name gives the
illusion of a more reliable filesystem than it actually is, and it will
freeze when encountering any of the failures the name suggests it would
protect from.
If we didn't have any raid56 support at all, or if it was configured
separately and disabled by default, I'd concur with your statement. But
as things stand, any improvement to the raid56 implementation that
brings at least some of the safety net raid56 are meant to provide makes
things better, without giving users an idea that the implementation is
any more full-featured than it currently is.
> Maybe it would be nice to have some half-baked code *anyway*,
> even if Chris doesn't put it in his pull requests juuust yet. ;)
Why, sure, that's why I posted the patch; even if it didn't make it to
the repository, others might find it useful ;-)
>> So far, I've put more than
>> 1TB of data on that failing disk with 16 partitions on raid6, and
>> somehow I got all the data back successfully: every file passed an
>> md5sum check, in spite of tons of I/O errors in the process.
> Is this all on a single disk? If so it must be seeking like mad! haha
Yeah. It probably is, but the access pattern for most of the time is
mostly random access to smallish files, so that won't be a problem. I
considered doing raid1 on the data, to get some more reliability out of
the broken disk, but then I recalled there was this raid56
implementation that, in raid6, would theoretically bring about
additional reliability and be far more space efficient, so I decided to
give it a try. Only after I'd put in most of the data did the errors
start popping out. Then I decided to try and fix them instead of
moving data out. it was some happy hacking ;-)
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
next prev parent reply other threads:[~2013-10-22 19:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-21 15:45 btrfs raid5 lilofile
2013-10-22 13:27 ` Duncan
2013-10-22 16:00 ` David Sterba
2013-10-22 17:18 ` Alexandre Oliva
2013-10-22 17:40 ` Brendan Hide
2013-10-22 19:24 ` Alexandre Oliva [this message]
2013-10-23 0:50 ` Duncan
2013-10-26 7:21 ` Alexandre Oliva
-- strict thread matches above, loose matches on Subject: below --
2013-10-22 2:30 shuo lv
2013-10-22 13:30 ` 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=ory55l85xm.fsf@livre.home \
--to=oliva@gnu.org \
--cc=brendan@swiftspirit.co.za \
--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).