From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Paul Jones <paul@pauljones.id.au>
Cc: Phil Karn <karn@ka9q.net>,
Jean-Denis Girard <jd.girard@sysnux.pf>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Extremely slow device removals
Date: Sat, 2 May 2020 02:00:38 -0400 [thread overview]
Message-ID: <20200502060038.GK10769@hungrycats.org> (raw)
In-Reply-To: <SYBPR01MB3897D20A8185249BF2A26B139EA80@SYBPR01MB3897.ausprd01.prod.outlook.com>
On Sat, May 02, 2020 at 04:48:42AM +0000, Paul Jones wrote:
> > -----Original Message-----
> > From: linux-btrfs-owner@vger.kernel.org <linux-btrfs-
> > owner@vger.kernel.org> On Behalf Of Zygo Blaxell
> > Sent: Saturday, 2 May 2020 1:35 PM
> > To: Phil Karn <karn@ka9q.net>
> > Cc: Jean-Denis Girard <jd.girard@sysnux.pf>; linux-btrfs@vger.kernel.org
> > Subject: Re: Extremely slow device removals
> >
> > On Fri, May 01, 2020 at 01:05:20AM -0700, Phil Karn wrote:
> > > On 4/30/20 11:13, Jean-Denis Girard wrote:
> > > >
> > > > Hi Phil,
> > > >
> > > > I did something similar one month ago. It took less than 4 hours for
> > > > 1.71 TiB of data:
> > > >
> > > > [xxx@taina ~]$ sudo btrfs replace status /home/SysNux Started on
> > > > 21.Mar 11:13:20, finished on 21.Mar 15:06:33, 0 write errs, 0
> > > > uncorr. read errs
> > >
> > > I just realized you did a *replace* rather than a *remove*. When I did
> > > a replace on another drive, it also went much faster. It must copy the
> > > data from the old drive to the new one in larger and/or more
> > > contiguous chunks. It's only the remove operation that's painfully slow.
> >
> > "Replace" is a modified form of scrub which assumes that you want to
> > reconstruct an entire drive instead of verifying an existing one.
> > It reads and writes all the blocks roughly in physical disk order, and doesn't
> > need to update any metadata since it's not changing any of the data as it
> > passes through.
> >
> > "Delete" is resize to 0 followed by remove the empty device. Resize requires
> > relocating all data onto other disks--or other locations on the same disk--one
> > extent at a time, and updating all of the reference pointers in the filesystem.
> >
> > The difference in speed can be several orders of magnitude.
>
> Delete seems to work like a balance. I've had a totally unbalanced
> raid 1 array and after removing a single almost full drive all the
> remaining drives are magically 50% full, down from 90% and up from
> 10%. It's a bit stressful when there is a missing disk as you can only
> delete a missing disk, not replace it.
Huh? Replacing missing disks is what btrfs replace is _for_.
> It would be nice if BTRFS had some more smarts so it knows when to "balance" data, and when to simply "move/copy" a single copy of data.
>
>
> Paul.
next prev parent reply other threads:[~2020-05-02 6:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 7:22 Extremely slow device removals Phil Karn
2020-04-30 17:31 ` Phil Karn
2020-04-30 18:13 ` Jean-Denis Girard
2020-05-01 8:05 ` Phil Karn
2020-05-02 3:35 ` Zygo Blaxell
[not found] ` <CAMwB8mjUw+KV8mxg8ynPsv0sj5vSpwG7_khw=oP5n+SnPYzumQ@mail.gmail.com>
2020-05-02 4:31 ` Zygo Blaxell
2020-05-02 4:48 ` Paul Jones
2020-05-02 5:25 ` Phil Karn
2020-05-02 6:04 ` Remi Gauvin
2020-05-02 7:20 ` Zygo Blaxell
2020-05-02 7:27 ` Phil Karn
2020-05-02 7:52 ` Zygo Blaxell
2020-05-02 6:00 ` Zygo Blaxell [this message]
2020-05-02 6:23 ` Paul Jones
2020-05-02 7:20 ` Phil Karn
2020-05-02 7:42 ` Zygo Blaxell
2020-05-02 8:22 ` Phil Karn
2020-05-02 8:24 ` Phil Karn
2020-05-02 9:09 ` Zygo Blaxell
2020-05-02 17:48 ` Chris Murphy
2020-05-03 5:26 ` Zygo Blaxell
2020-05-03 5:39 ` Chris Murphy
2020-05-03 6:05 ` Chris Murphy
2020-05-04 2:09 ` Phil Karn
2020-05-02 7:43 ` Jukka Larja
2020-05-02 4:49 ` Phil Karn
2020-04-30 18:40 ` Chris Murphy
2020-04-30 19:59 ` Phil Karn
2020-04-30 20:27 ` Alexandru Dordea
2020-04-30 20:58 ` Phil Karn
2020-05-01 2:47 ` Zygo Blaxell
2020-05-01 4:48 ` Phil Karn
2020-05-01 6:05 ` Alexandru Dordea
2020-05-01 7:29 ` Phil Karn
2020-05-02 4:18 ` Zygo Blaxell
2020-05-02 4:48 ` Phil Karn
2020-05-02 5:00 ` Phil Karn
2020-05-03 2:28 ` Phil Karn
2020-05-04 7:39 ` Phil Karn
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=20200502060038.GK10769@hungrycats.org \
--to=ce3g8jdj@umail.furryterror.org \
--cc=jd.girard@sysnux.pf \
--cc=karn@ka9q.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=paul@pauljones.id.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.