All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.