From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Why we always balance system chunk alone with metadata?
Date: Thu, 17 Mar 2016 08:09:17 +0000 (UTC) [thread overview]
Message-ID: <pan$87d80$ac7678a4$4439cb5$60c45f2a@cox.net> (raw)
In-Reply-To: 56E8C990.1010508@cn.fujitsu.com
Qu Wenruo posted on Wed, 16 Mar 2016 10:48:48 +0800 as excerpted:
> Hi,
>
> During debugging a bug related to balancing metadata chunk, we found
> that if we specify -m option for "btrfs balance", it will always balance
> system chunk too.
>
> cmds-balance.c:
> ---
> /*
> * allow -s only under --force, otherwise do with system chunks
> * the same thing we were ordered to do with meta chunks */
> if (args.flags & BTRFS_BALANCE_SYSTEM) {
> if (!force) {
> error(
> "Refusing to explicitly operate on system
> chunks.\n"
> "Pass --force if you really want to do
> that.");
> return 1;
> }
> } else if (args.flags & BTRFS_BALANCE_METADATA) {
> args.flags |= BTRFS_BALANCE_SYSTEM; <<< Here
> memcpy(&args.sys, &args.meta,
> sizeof(struct btrfs_balance_args));
> }
> ---
>
> I'm curious why we always bind system chunk to metadata balance?
>
> Is there any special reason?
> The patch introducing such behavior is dated back to 2012, and this
> makes us unable to do metadata *only* balance.
I always understood it as a convenient simplification for the sake of the
user, for whom tracking data and metadata separately is already a major
complication over what they're dealing with on most filesystems.
But I also wondered why there was no parallel to the -s system option for
metadata ONLY, perhaps requiring --force just as the -s option does.
The --force requirement for -s /does/ encourage people not to touch it at
all, separately, and there could be very good reasons to normally treat
system as metadata and process them as a combined unit, but even then, it
seems very odd to me to expose -s on its own, even if --force is
required, and not a parallel, say -M, for metadata-only, again, possibly
only if --force is used as well.
--
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
prev parent reply other threads:[~2016-03-17 8:09 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-16 2:48 Why we always balance system chunk alone with metadata? Qu Wenruo
2016-03-17 8:09 ` 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$87d80$ac7678a4$4439cb5$60c45f2a@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;
as well as URLs for NNTP newsgroup(s).