Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: anything wrong with `balance -dusage -musage` together?
Date: Fri, 20 Nov 2015 03:41:17 +0000 (UTC)	[thread overview]
Message-ID: <pan$34689$f9a98441$5a26e794$85a7efc3@cox.net> (raw)
In-Reply-To: 564E60FD.1010801@lukas-pirl.de

Lukas Pirl posted on Fri, 20 Nov 2015 12:53:33 +1300 as excerpted:

> I rarely see balance used with -dusage -musage together, esp. with
> values other than zero.
> 
> The question is, is there anything wrong with running (say) `balance
> -dusage=50 -musage=30` regularly?

I see the question in general has already been answered, nothing at all 
wrong with invoking balance with both an -musage and a -dusage filter, 
it's only rare to see in examples because the examples are generally 
dealing with specific cases where one or the other, generally metadata, 
has run out, due to the other one, generally data, taking all the 
otherwise unallocated space with mostly empty allocations.  So a quick
-dusage filter to clear out the mostly empty data allocations is the most 
common example seen.

But I'd like to point out, not only is combining -dusage and -musage OK, 
but in some cases, specifically btrfs' mixed-bg mode where data and 
metadata are combined into the same blocks, it's actually _mandatory_.

Note that mkfs.btrfs defaulted to --mixed mode for small filesystems, 
under a GiB, for some time, and that while btrfs-progs 4.3 
controversially does away with that default, it's still very strongly 
recommended for filesystems under a GiB, and recommended in general by 
many list regulars to between 8 and 32 GiB (I've even seen an argument 
for making it 64 GiB), as while slightly less efficient (and doubling 
data usage in dup mode), it does eliminate the data vs metadata hassles, 
which can be far worse at smaller filesystem sizes.

And some people use --mixed at even larger sizes, hundreds of gigs to TiB 
scale, often to enable them to do single-device dup mode data for better 
reliability and to better take advantage of btrfs' data integrity 
features, since until now dup mode has been allowed for metadata only, 
and thus has been disallowed for data except with mixed-mode.  (Tho 
that's set to change as recently patches have been posted that would 
allow dup mode data as well, which when integrated, would do away with 
the biggest reason to use mixed mode at 100 gig and larger sizes.)

Anyway, with mixed mode, data and metadata are mixed in the same chunks, 
and balance will refuse to run with balance filters unless the -d and -m 
filters exactly duplicate each other.  So on such a btrfs, to do a -dusage 
balance of any percentage, -musage must be added as well, with the exact 
same percentage.

So as I said, not only is there nothing wrong with combining -dusage and -
musage, in some cases it's actually mandatory.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


      parent reply	other threads:[~2015-11-20  3:41 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-19 23:53 anything wrong with `balance -dusage -musage` together? Lukas Pirl
2015-11-19 23:59 ` Hugo Mills
2015-11-20  0:06   ` Lukas Pirl
2015-11-20  3:41 ` Duncan [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='pan$34689$f9a98441$5a26e794$85a7efc3@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --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