From: Hugo Mills <hugo-lkml@carfax.org.uk>
To: helmut@hullen.de
Cc: linux-btrfs@vger.kernel.org
Subject: Re: btrfs balancing start - and stop?
Date: Fri, 1 Apr 2011 14:52:48 +0100 [thread overview]
Message-ID: <20110401135248.GC2984@carfax.org.uk> (raw)
In-Reply-To: <Bj0iubBi1uB@helmut.hullen.de>
[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]
On Fri, Apr 01, 2011 at 03:36:00PM +0200, Helmut Hullen wrote:
> Hallo, Konstantinos,
>
> Du meintest am 01.04.11:
>
> >> "dmesg" counts down the number of remaining "jobs".
>
> > are you sure? here is a snippet of dmesg from a balance i did
> > yesterday (2.6.38.1)
>
> > btrfs: relocating block group 15338569728 flags 9
> > btrfs: found 17296 extents
> > btrfs: found 17296 extents
> > btrfs: relocating block group 13191086080 flags 9
> > btrfs: found 21029 extents
> > btrfs: found 21029 extents
> > btrfs: relocating block group 11043602432 flags 9
> > btrfs: found 4728 extents
> > btrfs: found 4728 extents
>
> Yes - there I look how long the balancing job may still work. You see
> that the "relocating" line counts down: 15 13 11 ...
It's not a good measure of time remaining, as the numbers there are
pretty arbitrary: they're the start of the block group in btrfs's own
internal address space. The balance algorithm will indeed go through
the block groups in reverse order, but they're not guaranteed to
terminate at zero. In fact, if you've balanced before, they're pretty
much guaranteed to terminate a long way before zero.
New block groups (for example, ones created during a balance) are
always created with virtual addresses larger than any previous block
group. So, if you started with block groups at addresses 1G, 2G, 3G,
4G and balanced, you'd end up with ones at 5G, 6G, 7G, 8G. The next
time you balanced, you'd see the numbers count down: 8G, 7G, 6G, 5G,
complete.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Happiness is mandatory. Are you happy? ---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
next prev parent reply other threads:[~2011-04-01 13:52 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-01 11:14 btrfs balancing start - and stop? Struan Bartlett
2011-04-01 11:59 ` Hugo Mills
2011-04-05 16:06 ` Struan Bartlett
2011-04-01 12:12 ` Helmut Hullen
2011-04-01 13:22 ` Konstantinos Skarlatos
2011-04-01 13:36 ` Helmut Hullen
2011-04-01 13:52 ` Hugo Mills [this message]
[not found] ` <20110401133736.GB2984@carfax.org.uk>
2011-04-01 14:24 ` Konstantinos Skarlatos
2011-04-01 18:33 ` Stephane Chazelas
2011-04-01 19:26 ` Helmut Hullen
2011-04-03 18:53 ` Stephane Chazelas
2011-04-03 19:35 ` Helmut Hullen
2011-04-04 19:07 ` Stephane Chazelas
2011-04-06 11:43 ` Stephane Chazelas
2011-04-11 8:42 ` Stephane Chazelas
2011-04-11 9:14 ` Helmut Hullen
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=20110401135248.GC2984@carfax.org.uk \
--to=hugo-lkml@carfax.org.uk \
--cc=helmut@hullen.de \
--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).