linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid5
Date: Wed, 23 Oct 2013 00:50:51 +0000 (UTC)	[thread overview]
Message-ID: <pan$8e391$f46eecbc$498ef5f9$8d48b882@cox.net> (raw)
In-Reply-To: ory55l85xm.fsf@livre.home

Alexandre Oliva posted on Tue, 22 Oct 2013 17:24:37 -0200 as excerpted:

> 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.

The thing is, btrfs /doesn't/ have any raid56 support at all, in the 
practical sense of the word.  There is a preliminary partial 
implementation, exactly as announced/warned when the feature went in, on 
a filesystem that itself is still experimental/testing status, so even 
for the features that are in general working, make and test your backups 
and keep 'em handy!

Anyone running btrfs at this point should know it's status and be keeping 
up with upstream /because/ of that status, or they shouldn't be testing/
using it at all as it's not yet considered a stable filesystem.  If 
they're already aware of upstream status and are deliberately testing, by 
definition they'll already know the preliminary/partial nature of the 
current raid56 implementation and there won't be an issue.  If they 
aren't already keeping up with developments on a declared experimental 
filesystem, that's the base problem right there, and the quick failure 
should they try raid56 in its current state simply alerts them to the 
problem they already had.

-- 
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


  reply	other threads:[~2013-10-23  0:51 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
2013-10-23  0:50         ` Duncan [this message]
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='pan$8e391$f46eecbc$498ef5f9$8d48b882@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;
as well as URLs for NNTP newsgroup(s).