All of lore.kernel.org
 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 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.