From: Christian Rohmann <crohmann@netcologne.de>
To: Hugo Mills <hugo@carfax.org.uk>, linux-btrfs@vger.kernel.org
Subject: Re: How to properly and efficiently balance RAID6 after more drives are added?
Date: Wed, 2 Sep 2015 15:09:47 +0200 [thread overview]
Message-ID: <55E6F51B.3000007@netcologne.de> (raw)
In-Reply-To: <20150902113021.GD11358@carfax.org.uk>
Hey Hugo,
thanks for the quick response.
On 09/02/2015 01:30 PM, Hugo Mills wrote:
> You had some data on the first 8 drives with 6 data+2 parity, then
> added four more. From that point on, you were adding block groups
> with 10 data+2 parity. At some point, the first 8 drives became
> full, and then new block groups have been added only to the new
> drives, using 2 data+2 parity.
Even though the old 8 drive RAID6 was not full yet? Read: There was
still some terabytes of free space.
>> Should I run btrfs balance on the filesystem? If so, what FILTERS
>> would I then use in order for the data and therefore requests to
>> be better distributed?
>
> Yes, you should run a balance. You probably need to free up some
> space on the first 8 drives first, to give the allocator a chance
> to use all 12 devices in a single stripe. This can also be done
> with a balance. Sadly, with the striped RAID levels (0, 10, 5, 6),
> it's generally harder to ensure that all of the data is striped as
> evenly as is possible(*). I don't think there are any filters that
> you should to use -- just balance everything. The first time
> probably won't do the job fully. A second balance probably will.
> These are going to take a very long time to run (in your case, I'd
> guess at least a week for each balance). I would recommend starting
> the balance in a tmux or screen session, and also creating a second
> shell in the same session to run monitoring processes. I typically
> use something like:
>
> watch -n60 sudo btrfs fi show\; echo\; btrfs fi df /mountpoint\;
> echo\; btrfs bal stat /mountpoint
Yeah, that's what I usually do. The thing is that one does not get any
progress indication and estimate about how long a task will take.
> (*) Hmmm... idea for a new filter: min/max stripe width? Then you
> could balance only the block groups that aren't at full width,
> which is probably what's needed here.
Consider my question and motivation a rather obvious use case of
running out of disk space (or iops) and simply adding some more
drives. A balance needs to be straightforward for people to understand
and perform such tasks.
Regards
Christian
next prev parent reply other threads:[~2015-09-02 13:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 10:29 How to properly and efficiently balance RAID6 after more drives are added? Christian Rohmann
2015-09-02 11:30 ` Hugo Mills
2015-09-02 13:09 ` Christian Rohmann [this message]
2015-09-03 2:22 ` Duncan
2015-09-04 8:28 ` Christian Rohmann
2015-09-04 11:04 ` Duncan
2015-11-11 14:17 ` Christian Rohmann
2015-11-12 4:31 ` Duncan
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=55E6F51B.3000007@netcologne.de \
--to=crohmann@netcologne.de \
--cc=hugo@carfax.org.uk \
--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.