linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: kreijack@inwind.it
Cc: Eric Wong <e@80x24.org>, linux-btrfs@vger.kernel.org
Subject: Re: adding new devices to degraded raid1
Date: Thu, 27 Aug 2020 20:30:37 -0400	[thread overview]
Message-ID: <20200828003037.GU5890@hungrycats.org> (raw)
In-Reply-To: <862ab235-298a-12eb-647b-04ec01d95293@libero.it>

On Thu, Aug 27, 2020 at 07:14:18PM +0200, Goffredo Baroncelli wrote:
> On 8/27/20 2:41 PM, Eric Wong wrote:
> > I don't need to do it right away, but is it possible to add new
> > devices to a degraded raid1?
> > 
> > One thing I might do in the future is replace a broken big drive
> > with two small drives.  It may even be used to migrate to SSDs.
> > 
> > Since btrfs-replace only seems to do 1:1 replacements, and I
> > needed to physically remove an existing broken device to make
> > room for the replacements, could I do something like:
> > 
> > 	mount -o degraded /mnt/foo
> > 	btrfs device add small1 small2 /mnt/foo
> > 	btrfs device remove broken /mnt/foo

Note that add/remove is orders of magnitude slower than replace.
Replace might take hours or even a day or two on a huge spinning drive.
Add/remove might take _months_, though if you have 8-year-old disks
then it's probably a few days, weeks at most.

Add/remove does work for raid1* (i.e. raid1, raid10, raid1c3, raid1c4).
At the moment only 'replace' works reliably for raid5/raid6.

> > ?
> > 
> 
> Instead of
> 
>  	btrfs device remove broken /mnt/foo
> 
> You should do
> 
> 	btrfs device remove missing /mnt/foo
> 
> ("missing" has to be write as is, it is a special term, see man page)
> 
> and
> 
> 	btrfs balance start /mnt/foo

If the replacement disks are larger than half the size of the failed disk
then device remove may do sufficient data relocation and you won't need
balance.  Once all the disks have equal amounts of unallocated space in
'btrfs fi usage' you can cancel any balances that are running.

On the other hand, if the replacement disks are close to half the size
of the failed disk, then some careful balance filtering is required in
order to utilize all the available space.  This filtering is more than
what the stock tool offers.  You have to make sure that there are no block
groups with a mirror copy on both of the small disks, as any such block
group removes 1GB of available mirror space for data on the largest disk.

> To redistribute the data to the disks.
> 
> Please before trying it, wait for other suggestions or confirmation from more expert dveloper about that
> 
> BR
> G.Baroncelli
> 
> > Anyways, so far raid1 has been working great for me, but I have
> > some devices nearing 70K Power_On_Hours according to SMART
> > 
> > Thanks.
> > 
> 
> 
> -- 
> gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
> Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

  reply	other threads:[~2020-08-28  0:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-27 12:41 adding new devices to degraded raid1 Eric Wong
2020-08-27 17:14 ` Goffredo Baroncelli
2020-08-28  0:30   ` Zygo Blaxell [this message]
2020-08-28  2:34     ` Eric Wong
2020-08-28  4:36       ` Zygo Blaxell
2020-08-28  5:09         ` Andrei Borzenkov
2020-08-28 20:56           ` Zygo Blaxell
2020-08-29  0:42         ` Eric Wong
2020-08-29 18:46           ` Zygo Blaxell

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=20200828003037.GU5890@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=e@80x24.org \
    --cc=kreijack@inwind.it \
    --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).