Mailinglist Archive: opensuse-factory (586 mails)

< Previous Next >
Re: [opensuse-factory] Problem with BTRFS in openSUSE Tumbleweed: No space left on device
  • From: Chris Murphy <lists@xxxxxxxxxxxxxxxxx>
  • Date: Tue, 30 Aug 2016 09:58:35 -0600
  • Message-id: <CAJCQCtRTvFBYPz9Ctnctryf38bHJyyXWz6dHTDnPNi4EpBxd=Q@mail.gmail.com>
On Tue, Aug 30, 2016 at 4:08 AM, Lindsay Mathieson
<lindsay.mathieson@xxxxxxxxx> wrote:
On 30/08/2016 7:57 PM, Carlos E. R. wrote:

But nothing new in this area. Nothing like "debacle over RAID 5/6" that
Lindsay mentioned.

Or is he referring to a new implementation of raid? :-? I thought I
heard of a raid implementation peculiar to btrfs.


"Btrfs RAID 5/6 Code Found To Be Very Unsafe & Will Likely Require A
Rewrite"

http://www.phoronix.com/scan.php?page=news_item&px=Btrfs-RAID-56-Is-Bad


The btrfs scrub recalculates the wrong parity for raid 5/6 volumes, the bug
has existed for years - probably the cause for a recovery failure bug the
btrfs team have been trying to track down.

This is overstated.

Parity is not always recalculated incorrectly. It first requires a bad
data strip, and second it requires a scrub, during which data csum
mismatch happens, then the data is correctly reconstructed and
repaired from good parity, and then *sometimes* bad parity is
recomputed and written to disk. It's not clear that this happens
passively (during normal reads), or with balance code, as it's only
been reproduced with existing corruption of a data strip and during
scrubs. And it doesn't cleanly reproduce, the original reproducer and
I only found it happening about 1 in 3 attempts. So it's actually
rather obscure, which in no way discounts how bad a bug it is.

Next, Photonix doesn't bother to point out that Duncan isn't a
developer, or kernel developer, or Btrfs developer (and neither am I).
Duncan states this fact in fully half, or more, of his posts. So while
I agree with his opinion that Btrfs raid56 is only suitable for
testing, I can't agree with the broad statement that Btrfs raid56 is
so problematic that it has to be totally scraped and rewritten. That
isn't knowable to those unfamiliar with Btrfs code. It might very well
be there are a handful of obscure yet treacherous bugs that can
eventually be found and fixed.

A much bigger problem, affecting more users, for all consumer drive
configurations whether single drive or in some kind of raid (LVM,
mdadm, Btrfs, and maybe even ZFS on Linux):
http://www.spinics.net/lists/raid/msg52800.html
http://www.spinics.net/lists/raid/msg53389.html

It comes up probably once a week or two, and people lose data because
of this (now) very common misconfiguration.

Another big problem for Btrfs multiple device support is the lack of
faulty device handling. Btrfs will continue to read and write to bad
devices, indefinitely, spewing errors the entire time which itself
sometimes causes problems (not least of which is the log spamming that
ensues). There are patches available for testing upstream that aren't
yet merged because they haven't had enough testing. So if people want
this to get better, more will have to step up and do some testing with
sane hardware setups, in simple configurations, without any other out
of tree patches or kernel modules, and be completely OK with actually
having to used their backups.

In something like 7 years now, I've had no data loss with Btrfs. I
have had a couple arrays implode such that they became read only, so
they had to be recreated; and in both cases there was a user induced
event that caused the degraded state to happen, during which a bug was
triggered that results in the read only state.

--
Chris Murphy
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >