All of lore.kernel.org
 help / color / mirror / Atom feed
From: kjansen387 <kjansen387@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: btrfs raid1 balance slow
Date: Wed, 22 Jan 2020 09:18:16 +0100	[thread overview]
Message-ID: <79b677e2-8aee-ecd5-bb7e-c5fabeb0b2c8@gmail.com> (raw)
In-Reply-To: <176ec92f-56ba-4c8a-bcce-115c69fb7eeb@gmail.com>

Hmm, for some reason, I did not get the mail from Hugo and Qu (had too 
look it up in the archive). I think there is a delay when subscribing to 
the email list.

 > Do you have lots of snapshots? It can take a lot of time on some of
the metadata chunks if there's lots of shared extents.

No, I do not have any snapshots. Never made one - just got started with 
btrfs.
# btrfs subvolume show /export | grep Snap
         Snapshot(s):


 > Are you using qgroup?

No, quotas are disabled:
# btrfs qgroup show /export
ERROR: can't list qgroups: quotas not enabled


 >Please use kernel newer than v5.2, which contains the optimization.

I'm running 5.4.10-200.fc31.x86_64, that should be good


 > Just as Hugo said, cancel the current one, add all device, then 
rebalance.

Yes, that would be the best. I'm moving data however.. Expand btrfs > 
move the content of a 2TB disk > use that disk to expand btrfs > move 
the content of a 2TB disk etc. When this balance is done I'll move 2TB, 
find a temp drive to store the other 2TB and add the remaining 2 drives 
in 1 go.

I'm not in a hurry.. just wondering if this is normal. As I had 2x4TB 
with 150GB free and am adding 1x2TB (~1800GB, ~900 after raid1) I would 
expect that I will end up with 150+900=1050 GB free (usable), spread 
like (approx.):
4TB disk 1: 420GB (previously: 75GB)
4TB disk 2: 420GB (previously: 75GB)
2TB disk: 210GB

Thinking very simplisticly -and that's probably where I'm wrong, just 
wondering if it's a factor 8 wrong- this would mean 420-75 = 345GB read 
from each 4TB disks and written to the new 2TB disk. At a rate of 20MB/s 
(pretty conservative, but I do have a little bit of load) this should 
take like 10 hours. It will, however, at this rate, take approx. 82 
hours. Even if all data needs to be read (does it? ~3500GB net) it 
should only take ~50 hours..

Klaas

      reply	other threads:[~2020-01-22  8:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-20 22:08 btrfs raid1 balance slow kjansen387
2020-01-20 22:13 ` Hugo Mills
2020-01-20 23:59 ` Qu Wenruo
2020-01-21  9:51 ` kjansen387
2020-01-22  8:18   ` kjansen387 [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=79b677e2-8aee-ecd5-bb7e-c5fabeb0b2c8@gmail.com \
    --to=kjansen387@gmail.com \
    --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 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.