linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Murphy <lists@colorremedies.com>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Nathan Dehnel <ncdehnel@gmail.com>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: How to replace a missing device with a smaller one
Date: Wed, 20 Nov 2019 10:07:34 -0700	[thread overview]
Message-ID: <CAJCQCtRPK02xna7yJGQiuHOpjWcdquWingSBL6mXys=XDKkG6A@mail.gmail.com> (raw)
In-Reply-To: <58154d62-7f6e-76ee-94d5-00bfcd255e59@gmx.com>

On Sun, Nov 17, 2019 at 10:32 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> On 2019/11/18 上午10:09, Nathan Dehnel wrote:
> > I have a 10-disk raid10 with a missing device I'm trying to replace. I
> > get this error when doing it though:
> >
> > btrfs replace start 1 /dev/bcache0 /mnt
> > ERROR: target device smaller than source device (required 1000203091968 bytes)
> >
> > I see that people recommend resizing a disk before replacing it, which
> > isn't an option for me because it's gone.
>
> Oh, that's indeed a problem.
>
> We should allow to change missing device's size.
>
> > I'm replacing the drive by
> > copying from its mirror, so can I resize the mirror and then replace?
> > How do I do that? Do I need to run "btrfs fi res" on each of the
> > remaining drives in the array?
> >
> As a workaround, you could remove that missing device (which would
> relocate all chunks using it, so it can be slow).
>
> Then add the new device to the fs.
>
> With that done, it's recommended to do a convert to take full use the
> two added devices.

I think I'd advise adding the new device, and then removing the
missing device, rather than the other way around.

remove before add means the redundancy has to be re-established on the
remaining drives, device add then only increases fs capacity, and then
a balance is necessary to actually use the new device. Basically it
will cause two restripe tasks to happen.

add before remove, means the new device is available and will be used
during the redundancy being re-established (chunk replication); a full
balance won't be necessary, just check 'btrfs fi us' to see if there
are any single chunks for some reason, and if so a filtered
convert,soft balance can be done to convert them to raid10. This means
no restripe, just re-establishing the replication, and maybe a
"cleanup" filtered balance at the end to make sure all chunks are in
fact raid10.



-- 
Chris Murphy

      parent reply	other threads:[~2019-11-20 17:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-18  2:09 How to replace a missing device with a smaller one Nathan Dehnel
2019-11-18  5:32 ` Qu Wenruo
2019-11-18  7:08   ` Qu Wenruo
2019-11-19 14:38     ` David Sterba
2019-11-20  0:02       ` Qu Wenruo
2019-11-20  0:05         ` Zygo Blaxell
2019-11-21 10:21           ` Anand Jain
2019-11-24 23:02     ` Nathan Dehnel
2019-11-20 17:07   ` Chris Murphy [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='CAJCQCtRPK02xna7yJGQiuHOpjWcdquWingSBL6mXys=XDKkG6A@mail.gmail.com' \
    --to=lists@colorremedies.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=ncdehnel@gmail.com \
    --cc=quwenruo.btrfs@gmx.com \
    /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).