All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
To: Phil Karn <karn@ka9q.net>
Cc: Paul Jones <paul@pauljones.id.au>,
	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 03:20:53 -0400	[thread overview]
Message-ID: <20200502072053.GL10769@hungrycats.org> (raw)
In-Reply-To: <CAMwB8mi62y+9BfXYSmS0-VStGFnqDi8_UkskrdfPg5LsexaRNQ@mail.gmail.com>

On Fri, May 01, 2020 at 10:25:44PM -0700, Phil Karn wrote:
> I'm still not sure I understand what "balance" really does. I've run
> it quite a few times, with increasing percentage limits as
> recommended, but my drives never end up with equal amounts of data.
> Maybe that's because I've got an oddball configuration involving
> drives of two different sizes and (temporarily at least) an odd number
> of drives. It *sounds* like it ought to do what you describe, but what
> I read sounds more like an internal defragmentation operation on data
> and metadata storage areas. Is it both?

btrfs balance is mostly used to _free_ space (its other major use case
is to convert raid profiles).  Some raid levels (the mirroring and single
profiles) allocate with the goal of equalizing free space on all drives,
others (the striping profiles) equalize occupied space on all drives.
raid10 does a bit of both. 

If you have a mixed striping and mirroring profile (e.g. raid5 data with
raid1 metadata) then two opposing allocation policies happen at once, and
the space used and free on each disk is determined by the two algorithms
fighting it out.

balance coalesces free space areas into larger contiguous chunks by
reallocating all the existing data as if you had copied the files and
deleted the originals in logical extent order.  Sometimes people call this
"defrag free space" but the use of the word "defrag" can be confusing.

balance is not btrfs defrag.  defrag is concerned with making data extents
contiguous, while balance is concerned with making free space contiguous.

> On Fri, May 1, 2020 at 9:48 PM Paul Jones <paul@pauljones.id.au> wrote:
> 
> > 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.
> > 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.

  parent reply	other threads:[~2020-05-02  7:20 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 [this message]
2020-05-02  7:27               ` Phil Karn
2020-05-02  7:52                 ` Zygo Blaxell
2020-05-02  6:00           ` Zygo Blaxell
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=20200502072053.GL10769@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.