From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Gert Menke <gert@menke.ac>, Justin Kilpatrick <jkilpatr@redhat.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Switch raid mode without rebalance?
Date: Fri, 26 Aug 2016 07:52:57 -0400 [thread overview]
Message-ID: <456dc4ab-f6ae-48d6-94d6-782e56e284e0@gmail.com> (raw)
In-Reply-To: <0981faee57e9de5b29a7150dc89c4092@durkon.lan>
On 2016-08-25 18:32, Gert Menke wrote:
> Hi,
>
> On 2016-08-25 20:26, Justin Kilpatrick wrote:
>
>> I'm not sure why you want to avoid a balance,
> I didn't check, but I imagined it would slow down my rsync significantly.
It will slow it down, but I can't tell you exactly how much (there are
too many variables to give a good answer in this case).
>
>> Once you start this command all the new data should follow the new rules.
> Ah, now that's interesting.
> When the balance is running, df shows 4TB free space; when I cancel the
> balance, the free space goes back to a few 100GB.
Regular 'df' isn't to be trusted when dealing with BTRFS, the only
reason we report anything there is because many things break horribly if
we don't.
>
> But if the balancing only happens when the disk would otherwise be idle,
> and the mere fact that there is a balance process running will cause the
> new data to be written in single mode, I'm all set. I would not even
> have to wait for the balance to finish after the rsync is done; I could
> just cancel it and unmount the disks. A bit hacky, but in this case
> totally acceptable.
The balancing operation runs in the foreground (unless you daemonize it
in a new enough btrfs-progs), it isn't restricted to just using idle
time, and as explained by Chris Murphy in the other branch of this
thread, it's not flipping some binary switch telling the FS to write all
new data in the new profile.
Additionally, while running with multiple profiles while not balancing
should work, it's pretty much untested, and any number of things may
break. Assuming your two disks have similar latency and transfer speed,
you're almost certainly better off just converting completely to single
mode (which works like raid0, just at the chunk level instead of the
block level). Doing so will likely have near zero impact on
performance, will also be easier to recover data from if one disk dies,
and will avoid the mostly untested situation of running with multiple
chunk profiles.
On a slightly separate note, if your doing backups more frequently than
once a week, your probably better off just leaving the disks connected
and running. Regular load/unload cycles are generally harder on the
mechanical components in modern disks than just leaving them running 24/7.
next prev parent reply other threads:[~2016-08-26 11:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 18:16 Switch raid mode without rebalance? Gert Menke
2016-08-25 18:26 ` Justin Kilpatrick
2016-08-25 22:32 ` Gert Menke
2016-08-26 11:52 ` Austin S. Hemmelgarn [this message]
2016-08-26 19:53 ` Gert Menke
2016-08-25 19:50 ` Chris Murphy
2016-08-25 22:33 ` Gert Menke
2016-08-25 23:04 ` Chris Murphy
2016-08-26 19:18 ` Gert Menke
2016-08-26 20:31 ` Chris Murphy
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=456dc4ab-f6ae-48d6-94d6-782e56e284e0@gmail.com \
--to=ahferroin7@gmail.com \
--cc=gert@menke.ac \
--cc=jkilpatr@redhat.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.