linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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


      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).