System/single + Metadata/single as leftover cruft of mkfs?

System/single + Metadata/single as leftover cruft of mkfs?

[Shriramana Sharma]

I observe that whenever I create a BtrFS instance using mkfs.btrfs,
there is always the leftover cruft of two System/Metadata-Single
allocation profiles:

btrfs fi df /run/media/samjnaa/BRIHATII/
Data, single: total=460.01GiB, used=458.47GiB
System, DUP: total=8.00MiB, used=80.00KiB
System, single: total=4.00MiB, used=0.00B
Metadata, DUP: total=1.50GiB, used=736.86MiB
Metadata, single: total=8.00MiB, used=0.00B
GlobalReserve, single: total=256.00MiB, used=0.00B

Doing btrfs balance eventually removes these (but since I forgot to do
it *before* copying 400+ G of data to the drive it's still running)
but I don't understand why these have to be created in the first
place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
-m or -d options.)

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On 2014-12-04 08:53, Shriramana Sharma wrote:
> I observe that whenever I create a BtrFS instance using mkfs.btrfs,
> there is always the leftover cruft of two System/Metadata-Single
> allocation profiles:
>
> btrfs fi df /run/media/samjnaa/BRIHATII/
> Data, single: total=460.01GiB, used=458.47GiB
> System, DUP: total=8.00MiB, used=80.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, DUP: total=1.50GiB, used=736.86MiB
> Metadata, single: total=8.00MiB, used=0.00B
> GlobalReserve, single: total=256.00MiB, used=0.00B
>
> Doing btrfs balance eventually removes these (but since I forgot to do
> it *before* copying 400+ G of data to the drive it's still running)
> but I don't understand why these have to be created in the first
> place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
> -m or -d options.)
>
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.

The really interesting thing in this case is that the metadata chunk is 
8M, when they are usually 256M.

Also, for future reference, you can use the switch -mprofiles=single to 
just balance out those chunks.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

On 2014-12-04 09:13, Austin S Hemmelgarn wrote:
> On 2014-12-04 08:53, Shriramana Sharma wrote:
>> I observe that whenever I create a BtrFS instance using mkfs.btrfs,
>> there is always the leftover cruft of two System/Metadata-Single
>> allocation profiles:
>>
>> btrfs fi df /run/media/samjnaa/BRIHATII/
>> Data, single: total=460.01GiB, used=458.47GiB
>> System, DUP: total=8.00MiB, used=80.00KiB
>> System, single: total=4.00MiB, used=0.00B
>> Metadata, DUP: total=1.50GiB, used=736.86MiB
>> Metadata, single: total=8.00MiB, used=0.00B
>> GlobalReserve, single: total=256.00MiB, used=0.00B
>>
>> Doing btrfs balance eventually removes these (but since I forgot to do
>> it *before* copying 400+ G of data to the drive it's still running)
>> but I don't understand why these have to be created in the first
>> place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
>> -m or -d options.)
>>
> 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.
Correction, this happens even on current versions, I just hadn't noticed 
it.  It also seems to create a data chunk in single mode when data is 
set to some other profile.
>
> The really interesting thing in this case is that the metadata chunk is
> 8M, when they are usually 256M.
>
> Also, for future reference, you can use the switch -mprofiles=single to
> just balance out those chunks.
>



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Shriramana Sharma]

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?

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Austin S Hemmelgarn]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On 2014-12-04 09:25, 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?
>
Shouldn't be a problem, but unless they have changed the behavior 
recently specifying a filter for metadata also runs with that filter for 
system chunks unless you explicitly specify a different filter set for 
those.  The reason for the warning regarding system chunks is that if 
they get messed up, you pretty much lose everything on the disk.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Robert White]

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?
>

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Shriramana Sharma]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 487 bytes --]

On Thu, Dec 4, 2014 at 11:47 PM, Robert White <rwhite@pobox.com> wrote:
>
> If those disappeared, or got stripped off onto other drives then not-amusing
> things would happen.

Well after doing btrfs bal start <path> -mprofiles=single, the FS is
still working...

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±ý»k~ÏâžØ^n‡r¡ö¦zË\x1aëh™¨è­Ú&£ûàz¿äz¹Þ—ú+€Ê+zf£¢·hšˆ§~†­†Ûiÿÿïêÿ‘êçz_è®\x0fæj:+v‰¨þ)ߣøm

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Duncan]

Austin S Hemmelgarn posted on Thu, 04 Dec 2014 09:13:45 -0500 as
excerpted:

> Also, for future reference, you can use the switch -mprofiles=single to
> just balance out those chunks.

FWIW, the way I do it has the same effect on those left-over chunks, but 
uses a slightly different method and may be a bit more useful:

-musage=0

And to get rid of the single data chunk as well since I normally use 
raid1 for both data and metadata:

-dusage=0

Of course they can be combined in the same balance command.


This approach rebalances only those chunks with zero usage.  Since they 
have no usage, they aren't rewritten, simply deleted.

Of course that removes the empty single-profile chunks, but on systems 
with usage over a longer period, either where the filesystem was filled 
before the command was run or when the command was run for this reason 
instead of the single-profile chunks reason, there may be additional 
empty chunks of the desired profile (raid1 in my case).  Removing these 
empty chunks by rebalancing only them is a very quick way to return their 
allocation to unallocated space, thus freeing them for allocation on 
demand as either data or metadata, instead of keeping them pinned as one 
or the other which is what an empty chunk is effectively doing.

Of course on the most recent kernels (I think only 3.18 has it and of 
course it's not yet released tho the release is getting close) that's 
less of an issue since the kernel will now rebalance when data/metadata 
chunk usage gets too unbalanced, but previous to that, a bunch of empty 
data chunks hogging all the space so no more chunks could be allocated, 
while metadata was full and a new metadata chunk was needed, was a 
relatively common ENOSPC trigger, and the reverse (empty or nearly empty 
metadata chunks hogging all the otherwise free space, a new data chunk 
needed), while rarer, was known to happen on occasion as well.

But at least until that new auto-rebalancer has a bit more testing, 
knowing how to rebalance empty chunks and thus eliminate them, especially 
when a balance to free up space is otherwise unable to run due to no free 
space to allocate a new chunk to write the partial chunks into, can come 
in handy. =:^)

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

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Goffredo Baroncelli]

On 12/04/2014 02:53 PM, Shriramana Sharma wrote:
> I observe that whenever I create a BtrFS instance using mkfs.btrfs,
> there is always the leftover cruft of two System/Metadata-Single
> allocation profiles:
> 
> btrfs fi df /run/media/samjnaa/BRIHATII/
> Data, single: total=460.01GiB, used=458.47GiB
> System, DUP: total=8.00MiB, used=80.00KiB
> System, single: total=4.00MiB, used=0.00B
> Metadata, DUP: total=1.50GiB, used=736.86MiB
> Metadata, single: total=8.00MiB, used=0.00B
> GlobalReserve, single: total=256.00MiB, used=0.00B

Time, to time this question returns:
this was a explanation from Hugo Mills
	http://permalink.gmane.org/gmane.comp.file-systems.btrfs/38205


: I believe it comes from mkfs creating a trivial basic filesystem
: (with the single profiles), and then setting enough flags on it that the
: kernel can bootstrap it with the desired chunks in it -- but I may be
: wrong about that.


> 
> Doing btrfs balance eventually removes these (but since I forgot to do
> it *before* copying 400+ G of data to the drive it's still running)
> but I don't understand why these have to be created in the first
> place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
> -m or -d options.)
> 




-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Re: System/single + Metadata/single as leftover cruft of mkfs?

[Qu Wenruo]

-------- Original Message --------
Subject: Re: System/single + Metadata/single as leftover cruft of mkfs?
From: Goffredo Baroncelli <kreijack@inwind.it>
To: Shriramana Sharma <samjnaa@gmail.com>, linux-btrfs 
<linux-btrfs@vger.kernel.org>
Date: 2014年12月05日 02:32
> On 12/04/2014 02:53 PM, Shriramana Sharma wrote:
>> I observe that whenever I create a BtrFS instance using mkfs.btrfs,
>> there is always the leftover cruft of two System/Metadata-Single
>> allocation profiles:
>>
>> btrfs fi df /run/media/samjnaa/BRIHATII/
>> Data, single: total=460.01GiB, used=458.47GiB
>> System, DUP: total=8.00MiB, used=80.00KiB
>> System, single: total=4.00MiB, used=0.00B
>> Metadata, DUP: total=1.50GiB, used=736.86MiB
>> Metadata, single: total=8.00MiB, used=0.00B
>> GlobalReserve, single: total=256.00MiB, used=0.00B
> Time, to time this question returns:
> this was a explanation from Hugo Mills
> 	http://permalink.gmane.org/gmane.comp.file-systems.btrfs/38205
>
>
> : I believe it comes from mkfs creating a trivial basic filesystem
> : (with the single profiles), and then setting enough flags on it that the
> : kernel can bootstrap it with the desired chunks in it -- but I may be
> : wrong about that.
>
Yes, Hugo's explain is right.
mkfs.btrfs will make a basic file system(empty one) with SINGLE as 8M 
metadata and 4M system.(numbers may differ)
And then *add* new chunks with the raid level passed by  -m/-d options,
which makes mkfs.btrfs codes short and clean.

So, you can see the single system and metadata.

Also, if you have any raid level that has duplication(raid1 or dup), 
then kernel will not use such unsafe(single/raid0)
so in fact, they will never be used if using default DUP metadata like 
output

BTW, the latest kernel should have the patch  Josef committed, which 
will automatically remove the empty
chunks, so after rw mount with latest kernel, they should disappear.

Thasnk,
Qu
>> Doing btrfs balance eventually removes these (but since I forgot to do
>> it *before* copying 400+ G of data to the drive it's still running)
>> but I don't understand why these have to be created in the first
>> place? (I just used SuSE Tumbleweed's default mkfs.btrfs without any
>> -m or -d options.)
>>
>
>
>