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
<ahferro...@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?


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to