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 replace performance with missing drive
Date: Thu, 14 Jul 2016 12:01:36 +0000 (UTC)	[thread overview]
Message-ID: <pan$97fa$5418116$c2d5a5b1$dde13409@cox.net> (raw)
In-Reply-To: 1468495129.19617.127.camel@seblu.net

Sébastien Luttringer posted on Thu, 14 Jul 2016 13:18:49 +0200 as
excerpted:

> I have a performance issue with «btrfs replace» with raid5 and a 
_missing_
> device. My btrfs rely on 6x4TB HDD and the operating system is an 
Archlinux.
> 
> In a nutshell, I will need 23 to 46 days to replace on missing disk.


If you're still posting about this, it means you haven't been keeping up 
with list discussion over the last couple weeks and thus have missed the 
following.  I'll leave it to you to find the threads and get the details 
if you want, but here's the basics:

1) Btrfs raid56 mode has never really gotten to the stability level of 
the rest of btrfs, and recently a couple of fundamental defects in the 
current implementation have come to light, that unfortunately might well 
require a full rewrite to correct.

As such, btrfs raid56 mode, while never recommended except for those 
willing to be on the bleeding edge, is now negatively recommended, with 
the recommendation for those already using it being to switch to 
something more stable at their soonest convenience and to *ensure* that 
they either have backups or simply don't care about losing the data in 
the mean time.

2) Replace's often impractically slow performance in raid56 mode with a 
missing device was one of the known bugs keeping raid56 mode from being 
considered stable even before the above mentioned fundamental defects had 
come to light.  As such, for raid56 mode with a missing device, btrfs 
device add of the replacement, followed by btrfs device delete of the 
missing/failed drive (which forces a rebalance as part of the device 
delete), seems to be much faster, and is recommended, for raid56 mode 
with a missing device only, instead of btrfs replace.

So there's a workaround for your immediately reported problem, but that 
doesn't change the fact that there are fundamental issues with the 
current implementation, and that as such, getting off of raid56 mode as 
soon as convenient, and ensuring good backups of anything you don't want 
to lose in the mean time, is now recommended.

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


      parent reply	other threads:[~2016-07-14 12:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14 11:18 btrfs replace performance with missing drive Sébastien Luttringer
2016-07-14 11:54 ` Steven Haigh
2016-07-14 12:01 ` Duncan [this message]

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$97fa$5418116$c2d5a5b1$dde13409@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).