linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Andrei Borzenkov <arvidjaar@gmail.com>
Cc: Eric Wong <e@80x24.org>, kreijack@inwind.it, linux-btrfs@vger.kernel.org
Subject: Re: adding new devices to degraded raid1
Date: Fri, 28 Aug 2020 16:56:36 -0400	[thread overview]
Message-ID: <20200828205636.GF8346@hungrycats.org> (raw)
In-Reply-To: <0efae4eb-30dd-4d5a-d5fa-eac7ffc1fad8@gmail.com>

On Fri, Aug 28, 2020 at 08:09:26AM +0300, Andrei Borzenkov wrote:
> 28.08.2020 07:36, Zygo Blaxell пишет:
> > 
> > Replace just computes the contents of the filesystem the same way scrub
> > does:  except for the occasional metadata seek, it runs at wire speeds
> > because it reads blocks in order from one disk and writes in order on
> > the other disk, 99.999% of the time.
> > 
> 
> Does it write them to the same absolute disk locations? IOW - is it
> possible to use smaller disk for replace or it must be at least as large
> as original disk?

Replace writes data to the locations recorded in the chunk tree, i.e. the
original disk locations on the missing disk.

In theory, you can resize the offline disk to be smaller than the
replacement disk, then run btrfs replace.  In practice, only some of
the methods work (e.g. you must specify device ID and not device name
when replacing) and only on recent kernel versions.

btrfs dev remove is equivalent to 'btrfs fi resize <devid>:0' followed by
"remove empty device <devid>" so the performance will be very similar
for the portion of the data that is resized; however, a combination of
resize and replace is still much faster than device remove, which does
it the slow way for all of the data.

  reply	other threads:[~2020-08-28 20:56 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
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 [this message]
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=20200828205636.GF8346@hungrycats.org \
    --to=ce3g8jdj@umail.furryterror.org \
    --cc=arvidjaar@gmail.com \
    --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).