Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Robert White <rwhite@pobox.com>
To: Shriramana Sharma <samjnaa@gmail.com>,
	Austin S Hemmelgarn <ahferroin7@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: System/single + Metadata/single as leftover cruft of mkfs?
Date: Thu, 04 Dec 2014 10:17:48 -0800	[thread overview]
Message-ID: <5480A54C.6050900@pobox.com> (raw)
In-Reply-To: <CAH-HCWXXerTeeXGoQhpj-eXO78H45f6rDje4Oh2CDuZDS8-cww@mail.gmail.com>

I _think_ the "extra" single entries are the entries that deal with the 
disk/partition itself and therefore can not ever be distributed.

So like the BTRFS signatures that say "this is the third disk of this 
array" (as opposed to the first, second, or fourth etc) and "this is 
where my superblocks are" or whatever. Well that data is in its own 
small space that needs to be accounted for.

So the per-disk copy of the filesystem layout information (all the UUIDS 
of all the disks) and the per-disk copy of the disk specific information 
need to be somewhere, and they are naturally "single" since they are 
per-disk.

Compare to the LVM or MDADM signatures written to/about each element 
those systems control.

If those disappeared, or got stripped off onto other drives then 
not-amusing things would happen.

On 12/04/2014 06:25 AM, Shriramana Sharma wrote:
> On Thu, Dec 4, 2014 at 7:43 PM, Austin S Hemmelgarn
> <ahferroin7@gmail.com> wrote:
>> SuSE may have an old version of btrfs-progs then (which wouldn't surprise
>> me, it is an 'enterprise' distribution after all), because I haven't seen
>> this on anything since 3.16.
>
> Well OK I kinda like the "old" name SuSE since that was the name I was
> using back when I was on 9.3, but actually I'm running openSUSE
> Tumbleweed. See:
>
> $ btrfs --version
> Btrfs v3.17+20141103
>
> I suppose Tumbleweed should be short and clear enough for my future usage.
>
>> Also, for future reference, you can use the switch -mprofiles=single to just
>> balance out those chunks.
>
> Wow, thanks, that returned quickly. (Thankfully I did btrfs bal from a
> separate terminal can rather than ^C.)
>
> BTW I thought you had unintentionally (for brevity) omitted the
> -sprofiles=single and I gave it but it complained saying:
>
> Refusing to explicitly operate on system chunks.
> Pass --force if you really want to do that.
>
> So I did give --force. (Is it the same as -f?)
>
> I hope that was OK?
>


  parent reply	other threads:[~2014-12-04 18:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-04 13:53 System/single + Metadata/single as leftover cruft of mkfs? Shriramana Sharma
2014-12-04 14:13 ` Austin S Hemmelgarn
2014-12-04 14:22   ` Austin S Hemmelgarn
2014-12-04 14:25   ` Shriramana Sharma
2014-12-04 14:36     ` Austin S Hemmelgarn
2014-12-04 18:17     ` Robert White [this message]
2014-12-04 23:55       ` Shriramana Sharma
2014-12-05  6:57   ` Duncan
2014-12-04 18:32 ` Goffredo Baroncelli
2014-12-08  1:22   ` Qu Wenruo

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=5480A54C.6050900@pobox.com \
    --to=rwhite@pobox.com \
    --cc=ahferroin7@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=samjnaa@gmail.com \
    /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