btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[joshua]

I generally use this command to check my drive usage: `btrfs fi usage -T /mnt/data` But this time
it didn't give me useful information:

I decided to begin replacing a few of my drives with larger drives, so I could remove a lot of my
smaller drives. I ran this command:
Overall:
Device size: 67.31TiB
Device allocated: 41.73TiB
Device unallocated: 25.58TiB
Device missing: 0.00B
Used: 41.69TiB
Free (estimated): 12.81TiB (min: 12.81TiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)

Data Metadata System
Id Path RAID1 RAID1 RAID1 Unallocated
-- -------- -------- -------- -------- -----------
4 /dev/sda 2.57TiB 3.00GiB - 164.52GiB
{-snip-}

I then started the replace with this command: `btrfs replace start 4 /dev/sdu /mnt/data`
Everything went well, so I checked again:
root@CENTAUR:~# btrfs fi usage -T /mnt/data
Overall:
Device size: 67.31TiB
Device allocated: 41.73TiB
Device unallocated: 25.58TiB
Device missing: 0.00B
Used: 41.69TiB
Free (estimated): 12.81TiB (min: 12.81TiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)

Data Metadata System
Id Path RAID1 RAID1 RAID1 Unallocated
-- -------- -------- -------- -------- -----------
4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
{-snip-}

For a brief moment I was confused, and ran this command to double-check:
root@CENTAUR:~# btrfs fi sh
Label: 'DATA' uuid: ddafe51b-e1e8-4f4b-bcca-057f53b59a8d
Total devices 17 FS bytes used 20.84TiB
{-snip-}
devid 4 size 2.73TiB used 2.57TiB path /dev/sdu
{-snip-}

Oh right, I have to run resize! So I run resize, and everything works exactly as expected.

However, shouldn't `btrfs fi usage -T` only report the usable space in the unallocated column?
`btrfs fi sh` only reports the available space correctly.
Perhaps there is a reason for this behavior? If not, it's a little confusing, and should really be
brought into line with `btrfs fi sh` IMO.

For reference, here is what I ran afterwards:

root@CENTAUR:~# btrfs fi resize 4:max /mnt/data
Resize '/mnt/data' of '4:max'
root@CENTAUR:~# btrfs fi sh
Label: 'DATA' uuid: ddafe51b-e1e8-4f4b-bcca-057f53b59a8d
Total devices 17 FS bytes used 20.84TiB
{-snip-}
devid 4 size 9.10TiB used 2.57TiB path /dev/sdu
{-snip-}

root@CENTAUR:~# btrfs fi usage -T /mnt/data
Overall:
Device size: 73.68TiB
Device allocated: 41.73TiB
Device unallocated: 31.95TiB
Device missing: 0.00B
Used: 41.69TiB
Free (estimated): 15.99TiB (min: 15.99TiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)

Data Metadata System
Id Path RAID1 RAID1 RAID1 Unallocated
-- -------- -------- -------- -------- -----------
4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
{-snip-}

So everything is as I expect it to be afterwards- All ready to begin removing multiple drives.

Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Chris Murphy]

On Mon, Dec 24, 2018 at 10:21 AM <joshua@mailmag.net> wrote:
>
> I generally use this command to check my drive usage: `btrfs fi usage -T /mnt/data` But this time
> it didn't give me useful information:
>
> I decided to begin replacing a few of my drives with larger drives, so I could remove a lot of my
> smaller drives. I ran this command:
> Overall:
> Device size: 67.31TiB
> Device allocated: 41.73TiB
> Device unallocated: 25.58TiB
> Device missing: 0.00B
> Used: 41.69TiB
> Free (estimated): 12.81TiB (min: 12.81TiB)
> Data ratio: 2.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data Metadata System
> Id Path RAID1 RAID1 RAID1 Unallocated
> -- -------- -------- -------- -------- -----------
> 4 /dev/sda 2.57TiB 3.00GiB - 164.52GiB
> {-snip-}
>
> I then started the replace with this command: `btrfs replace start 4 /dev/sdu /mnt/data`
> Everything went well, so I checked again:
> root@CENTAUR:~# btrfs fi usage -T /mnt/data
> Overall:
> Device size: 67.31TiB
> Device allocated: 41.73TiB
> Device unallocated: 25.58TiB
> Device missing: 0.00B
> Used: 41.69TiB
> Free (estimated): 12.81TiB (min: 12.81TiB)
> Data ratio: 2.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data Metadata System
> Id Path RAID1 RAID1 RAID1 Unallocated
> -- -------- -------- -------- -------- -----------
> 4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
> {-snip-}
>
> For a brief moment I was confused, and ran this command to double-check:
> root@CENTAUR:~# btrfs fi sh
> Label: 'DATA' uuid: ddafe51b-e1e8-4f4b-bcca-057f53b59a8d
> Total devices 17 FS bytes used 20.84TiB
> {-snip-}
> devid 4 size 2.73TiB used 2.57TiB path /dev/sdu
> {-snip-}
>
> Oh right, I have to run resize! So I run resize, and everything works exactly as expected.
>
> However, shouldn't `btrfs fi usage -T` only report the usable space in the unallocated column?
> `btrfs fi sh` only reports the available space correctly.
> Perhaps there is a reason for this behavior? If not, it's a little confusing, and should really be
> brought into line with `btrfs fi sh` IMO.
>
> For reference, here is what I ran afterwards:
>
> root@CENTAUR:~# btrfs fi resize 4:max /mnt/data
> Resize '/mnt/data' of '4:max'
> root@CENTAUR:~# btrfs fi sh
> Label: 'DATA' uuid: ddafe51b-e1e8-4f4b-bcca-057f53b59a8d
> Total devices 17 FS bytes used 20.84TiB
> {-snip-}
> devid 4 size 9.10TiB used 2.57TiB path /dev/sdu
> {-snip-}
>
> root@CENTAUR:~# btrfs fi usage -T /mnt/data
> Overall:
> Device size: 73.68TiB
> Device allocated: 41.73TiB
> Device unallocated: 31.95TiB
> Device missing: 0.00B
> Used: 41.69TiB
> Free (estimated): 15.99TiB (min: 15.99TiB)
> Data ratio: 2.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data Metadata System
> Id Path RAID1 RAID1 RAID1 Unallocated
> -- -------- -------- -------- -------- -----------
> 4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
> {-snip-}
>
> So everything is as I expect it to be afterwards- All ready to begin removing multiple drives.


I'm not really following this. An fs resize is implied by any device
add, remove or replace command. In the case of replace, it will
efficiently copy the device being replaced to the designated drive,
and then once that succeeds resize the file system to reflect the size
of the replacement device. I'm also confused why devid 4 seems to be
present before and after your device replace, so I have to wonder if
your copy paste really worked out as intended? And also, what version
of kernel and btrfs-progs are you using?

What do you mean by "usable space" and "available space"? It is
possibly confusing, the new and old tools intentional do things
differently, but it really depends on what you're referring to. I
suggest going to the faq and check out these two sections:
https://btrfs.wiki.kernel.org/index.php/FAQ
4.7.1 Understanding free space, using the original tools
4.7.2 Understanding free space, using the new tools

"unallocated" and "allocated" are specific terms that refer to block
groups (chunks). Space that's unallocated has no block groups, space
that's allocated is reserved for block groups; and inside each block
group there can be unused space. "Free space" is considered to be the
unused space in block groups  plus unallocated space.

btrfs filesystem show is confusing because "used" seems to be a term
used twice. The decoder ring is:
'fi show' "FS bytes used" as equal to 'fi usage' "Used"; and
'fi show' "devid ... used" as equal to 'fi usage' "Device allocated".

-- 
Chris Murphy

Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Duncan]

Chris Murphy posted on Wed, 26 Dec 2018 17:36:19 -0700 as excerpted:


> I'm not really following this. An fs resize is implied by any device
> add, remove or replace command. In the case of replace, it will
> efficiently copy the device being replaced to the designated drive, and
> then once that succeeds resize the file system to reflect the size of
> the replacement device. I'm also confused why devid 4 seems to be
> present before and after your device replace, so I have to wonder if
> your copy paste really worked out as intended? And also, what version of
> kernel and btrfs-progs are you using?

I thought... yes...

Just checked the btrfs-replace manpage (v4.19.1) and it says:

Note
the filesystem has to be resized to fully take advantage of a larger 
target device; this can be achieved with btrfs filesystem
resize <devid>:max /path

So it does *not* auto-resize after the replace.


Also, I'm not positive on this, and I don't see it mentioned in the 
manpage, but I /think/ replace (unlike add/remove) keeps the same devid 
for the new device.

(And IIRC one of the devs commented that there's a devid 0 during the 
replace itself, but I'm unsure whether that's the source or the 
destination, that is, whether the old ID is switched to the new device at 
the beginning of the replace so the old one temporarily gets the 0 during 
the replace until it's deleted at the end, or end so the new one 
temporarily gets it until the id is transferred at the end.  That was in 
the context of a draft patch that didn't yet account for the possibility 
of devid 0 during replace, and the comment was pointing out the 
possibility.)

If that's correct then the devid 4 could indeed be the old device at 
first (when it refers to sda and has 164.5 GiB unallocated), but the new 
device later (when it refers to sdu and has 6.53 TiB unallocated), even 
before the resize, that being the point of confusion (6.53 TB unallocated 
even tho it can't actually use it as it hasn't been resized yet) that 
triggered the original post in the first place.

To address that point, I suppose ideally there'd be another line when the 
filesystem's smaller than the available device size, device-space outside 
filesystem, or some such.


Tho you are correct that fi show and fi df's output don't correspond 
exactly to fi usage, without some sort of decoder ring to translate 
between them, and even with the decoder ring, the numbers come out but 
slightly different things are reported.


Meanwhile, while I normally want the filesystem usage info and thus use 
that command, for something like this I'd be specifically interested in 
the specific device's usage, and thus would use btrfs device usage, in 
place of or in addition to btrfs filesystem usage.

It'd be interesting to see what device usage (as opposed to filesystem 
usage) did with the unreachable space in terms of reporting -- maybe it 
has that separate line tho I doubt it, but if not does it count it or 
not?.  But that wasn't posted and presumably the query wasn't run while 
in the still-unresized state, and I guess it's a bit late now to get it...

-- 
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: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Chris Murphy]

On Thu, Dec 27, 2018 at 12:14 AM Duncan <1i5t5.duncan@cox.net> wrote:
>
> Chris Murphy posted on Wed, 26 Dec 2018 17:36:19 -0700 as excerpted:
>
>
> > I'm not really following this. An fs resize is implied by any device
> > add, remove or replace command. In the case of replace, it will
> > efficiently copy the device being replaced to the designated drive, and
> > then once that succeeds resize the file system to reflect the size of
> > the replacement device. I'm also confused why devid 4 seems to be
> > present before and after your device replace, so I have to wonder if
> > your copy paste really worked out as intended? And also, what version of
> > kernel and btrfs-progs are you using?
>
> I thought... yes...
>
> Just checked the btrfs-replace manpage (v4.19.1) and it says:
>
> Note
> the filesystem has to be resized to fully take advantage of a larger
> target device; this can be achieved with btrfs filesystem
> resize <devid>:max /path
>
> So it does *not* auto-resize after the replace.

Oops. That's unexpected.


>
>
> Also, I'm not positive on this, and I don't see it mentioned in the
> manpage, but I /think/ replace (unlike add/remove) keeps the same devid
> for the new device.

Also unexpected.


> It'd be interesting to see what device usage (as opposed to filesystem
> usage) did with the unreachable space in terms of reporting -- maybe it
> has that separate line tho I doubt it, but if not does it count it or
> not?.  But that wasn't posted and presumably the query wasn't run while
> in the still-unresized state, and I guess it's a bit late now to get it...

I'm not sure, it's one of the commands I almost never use. What is device slack?

From my single device that's handy at this moment, the only item I see
in 'device usage' that I don't see in 'filesystem usage' is "device
slack".

Both 'device usage' and 'filesystem usage' show allocated and
unallocated per device. While 'filesystem usage' shows the used
portion of allocated, it's per profile, not per chunk.


-- 
Chris Murphy

Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Chris Murphy]

On Thu, Dec 27, 2018 at 1:06 PM Chris Murphy <lists@colorremedies.com> wrote:
>
> On Thu, Dec 27, 2018 at 12:14 AM Duncan <1i5t5.duncan@cox.net> wrote:
> >
> > Chris Murphy posted on Wed, 26 Dec 2018 17:36:19 -0700 as excerpted:
> >
> >
> > > I'm not really following this. An fs resize is implied by any device
> > > add, remove or replace command. In the case of replace, it will
> > > efficiently copy the device being replaced to the designated drive, and
> > > then once that succeeds resize the file system to reflect the size of
> > > the replacement device. I'm also confused why devid 4 seems to be
> > > present before and after your device replace, so I have to wonder if
> > > your copy paste really worked out as intended? And also, what version of
> > > kernel and btrfs-progs are you using?
> >
> > I thought... yes...
> >
> > Just checked the btrfs-replace manpage (v4.19.1) and it says:
> >
> > Note
> > the filesystem has to be resized to fully take advantage of a larger
> > target device; this can be achieved with btrfs filesystem
> > resize <devid>:max /path
> >
> > So it does *not* auto-resize after the replace.
>
> Oops. That's unexpected.
>
>
> >
> >
> > Also, I'm not positive on this, and I don't see it mentioned in the
> > manpage, but I /think/ replace (unlike add/remove) keeps the same devid
> > for the new device.
>
> Also unexpected.
>
>
> > It'd be interesting to see what device usage (as opposed to filesystem
> > usage) did with the unreachable space in terms of reporting -- maybe it
> > has that separate line tho I doubt it, but if not does it count it or
> > not?.  But that wasn't posted and presumably the query wasn't run while
> > in the still-unresized state, and I guess it's a bit late now to get it...
>
> I'm not sure, it's one of the commands I almost never use. What is device slack?
>
> From my single device that's handy at this moment, the only item I see
> in 'device usage' that I don't see in 'filesystem usage' is "device
> slack".
>
> Both 'device usage' and 'filesystem usage' show allocated and
> unallocated per device. While 'filesystem usage' shows the used
> portion of allocated, it's per profile, not per chunk.
                                         ^^^^

s/chunk/device


-- 
Chris Murphy

Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[joshua]

December 26, 2018 11:15 PM, "Duncan" <1i5t5.duncan@cox.net> wrote:

> Chris Murphy posted on Wed, 26 Dec 2018 17:36:19 -0700 as excerpted:
> 
>> I'm not really following this. An fs resize is implied by any device
>> add, remove or replace command. In the case of replace, it will
>> efficiently copy the device being replaced to the designated drive, and
>> then once that succeeds resize the file system to reflect the size of
>> the replacement device. I'm also confused why devid 4 seems to be
>> present before and after your device replace, so I have to wonder if
>> your copy paste really worked out as intended? And also, what version of
>> kernel and btrfs-progs are you using?
> 
> I thought... yes...
> 
> Just checked the btrfs-replace manpage (v4.19.1) and it says:
> 
> Note
> the filesystem has to be resized to fully take advantage of a larger
> target device; this can be achieved with btrfs filesystem
> resize <devid>:max /path
> 
> So it does *not* auto-resize after the replace.
> 
> Also, I'm not positive on this, and I don't see it mentioned in the
> manpage, but I /think/ replace (unlike add/remove) keeps the same devid
> for the new device.
> 
> (And IIRC one of the devs commented that there's a devid 0 during the
> replace itself, but I'm unsure whether that's the source or the
> destination, that is, whether the old ID is switched to the new device at
> the beginning of the replace so the old one temporarily gets the 0 during
> the replace until it's deleted at the end, or end so the new one
> temporarily gets it until the id is transferred at the end. That was in
> the context of a draft patch that didn't yet account for the possibility
> of devid 0 during replace, and the comment was pointing out the
> possibility.)
> 
> If that's correct then the devid 4 could indeed be the old device at
> first (when it refers to sda and has 164.5 GiB unallocated), but the new
> device later (when it refers to sdu and has 6.53 TiB unallocated), even
> before the resize, that being the point of confusion (6.53 TB unallocated
> even tho it can't actually use it as it hasn't been resized yet) that
> triggered the original post in the first place.

Thanks, I wasn't sure how devid's were supposed to work, but that's definitely the behavior I saw:
the old device is removed (from the
'pool'), but the new device now has the old device's devid:
4 /dev/sda 2.57TiB 3.00GiB - 164.52GiB (Before)
4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB (After)
After the device replace, I have the new device as the same devid as the old device, and pretty
much exactly the same amount of space currently used. I can tell the device has changed, because it
now shows /dev/sdu as the device, which is the drive I replaced it with.

> To address that point, I suppose ideally there'd be another line when the
> filesystem's smaller than the available device size, device-space outside
> filesystem, or some such.
> 
> Tho you are correct that fi show and fi df's output don't correspond
> exactly to fi usage, without some sort of decoder ring to translate
> between them, and even with the decoder ring, the numbers come out but
> slightly different things are reported.
> 
> Meanwhile, while I normally want the filesystem usage info and thus use
> that command, for something like this I'd be specifically interested in
> the specific device's usage, and thus would use btrfs device usage, in
> place of or in addition to btrfs filesystem usage.

Perhaps my original assumptions were incorrect, but I had originally assumed that since both the
commands I ran were 'btrfs fi' commands, that they would be reporting on the same things, just in
different formats. (btrfs fi show & btrfs fi usage)
I also assumed, (perhaps incorrectly) that since they were "filesystem" commands, (btrfs fi) they
would be reporting on the amounts directly available to btrfs.

Regardless, after running replace, but before running resize, 'btrfs fi show' reported the
following:
devid 4 size 2.73TiB used 2.57TiB path /dev/sdu
However, 'btrfs fi usage -T /mnt/data' reported the following:
Overall:
Device size: 67.31TiB
Device allocated: 41.73TiB
Device unallocated: 25.58TiB
Device missing: 0.00B
Used: 41.69TiB
Free (estimated): 12.81TiB (min: 12.81TiB)
Data ratio: 2.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)

Data Metadata System
Id Path RAID1 RAID1 RAID1 Unallocated
-- -------- -------- -------- -------- -----------
4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
{-snip-}
-- -------- -------- -------- -------- -----------
Total 20.84TiB 31.00GiB 32.00MiB 31.95TiB
Used 20.82TiB 29.60GiB 2.98MiB

Of particular interest here is that the data in the header (Overall) is no different than before
the replace, so it is fully aware the space is not (yet) usable, and thus reporting it correctly.
Just the Unallocated column is potentially misleading (and the totals at the bottom)

I should note that every device in this particular Array/Pool is not using partitions; I'm using
btrfs directly on the device. Perhaps this is why btrfs is handling it this way?  I wonder how it
behaves on a partitioned FileSystem.

> It'd be interesting to see what device usage (as opposed to filesystem
> usage) did with the unreachable space in terms of reporting -- maybe it
> has that separate line tho I doubt it, but if not does it count it or
> not?. But that wasn't posted and presumably the query wasn't run while
> in the still-unresized state, and I guess it's a bit late now to get it...

Yeah, I've done the 2 replaces I have intention of doing reasonably soon, so not really any chance
to do that on a live filesystem at this point.

> --
> 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: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Chris Murphy]

On Thu, Dec 27, 2018 at 1:33 PM <joshua@mailmag.net> wrote:
>


> Perhaps my original assumptions were incorrect, but I had originally assumed that since both the
> commands I ran were 'btrfs fi' commands, that they would be reporting on the same things, just in
> different formats. (btrfs fi show & btrfs fi usage)
> I also assumed, (perhaps incorrectly) that since they were "filesystem" commands, (btrfs fi) they
> would be reporting on the amounts directly available to btrfs.



>
> Regardless, after running replace, but before running resize, 'btrfs fi show' reported the
> following:
> devid 4 size 2.73TiB used 2.57TiB path /dev/sdu

devid size should match super block dev_item.total_bytes, and devid
used should match super block dev_item.bytes_used

dev_item.total_bytes normally matches the bytes for the block device
in question; but due to resize it might not match.


> However, 'btrfs fi usage -T /mnt/data' reported the following:
> Overall:
> Device size: 67.31TiB
> Device allocated: 41.73TiB
> Device unallocated: 25.58TiB
> Device missing: 0.00B
> Used: 41.69TiB
> Free (estimated): 12.81TiB (min: 12.81TiB)
> Data ratio: 2.00
> Metadata ratio: 2.00
> Global reserve: 512.00MiB (used: 0.00B)
>
> Data Metadata System
> Id Path RAID1 RAID1 RAID1 Unallocated
> -- -------- -------- -------- -------- -----------
> 4 /dev/sdu 2.57TiB 3.00GiB - 6.53TiB
> {-snip-}
> -- -------- -------- -------- -------- -----------
> Total 20.84TiB 31.00GiB 32.00MiB 31.95TiB
> Used 20.82TiB 29.60GiB 2.98MiB
>
> Of particular interest here is that the data in the header (Overall) is no different than before
> the replace, so it is fully aware the space is not (yet) usable, and thus reporting it correctly.
> Just the Unallocated column is potentially misleading (and the totals at the bottom)

OK let me see if I get this right. You're saying it's confusing that
'btrfs fi sh' "devid size" does not change when doing a device
replace; whereas 'btrfs fi us' device specific "unallocated" does
change, even though you haven't yet done a resize.

I kinda sorta agree. While "unallocated" becomes 6.53TiB for this
device, the idea it's unallocated suggests it could be allocated,
which before a resize it cannot be allocated.

Someone would have to dig into the btrfs-progs code and see how
"unallocated" is computed per device, maybe there's a rationalization
in the comments. I'd say it's confusing if unallocated for a device is
greater than either 'btrfs fi sh' "devid size" or dev_item.total_bytes
found in the super for that device.


> I should note that every device in this particular Array/Pool is not using partitions; I'm using
> btrfs directly on the device. Perhaps this is why btrfs is handling it this way?  I wonder how it
> behaves on a partitioned FileSystem.

It behaves the same. Whether partitioned or not, Btrfs sees it as a
block device.


-- 
Chris Murphy

Re: btrfs fi usage -T shows unallocated column as total in drive, not total available to btrfs

[Duncan]

Chris Murphy posted on Thu, 27 Dec 2018 16:37:55 -0700 as excerpted:

[Context is btrfs reports when btrfs is smaller on a device than the 
device it is on.  In this specific case it's due to btrfs replace to a 
larger device, before using btrfs filesystem resize to increase the size 
to that of the newer/larger device.]

> OK let me see if I get this right. You're saying it's confusing that
> 'btrfs fi sh' "devid size" does not change when doing a device replace;
> whereas 'btrfs fi us' device specific "unallocated" does change, even
> though you haven't yet done a resize.
> 
> I kinda sorta agree. While "unallocated" becomes 6.53TiB for this
> device, the idea it's unallocated suggests it could be allocated, which
> before a resize it cannot be allocated.

"It depends what the definition of "unallocated" is."[1]

Arguably, just as "unallocated" includes space not yet allocated to data/
metadata/system chunks, it could be argued it should include space on the 
device not yet allocated to the filesystem as well.  Clearly, that's what 
the coder of the btrfs filesystem usage functionality thought.

By that view, "unallocated" includes "not yet allocated to the filesystem 
itself also, but available on the block device the filesystem is on, to 
be allocated to the filesystem should the admin decide to do so."

OTOH, as the OP says it's still confusing, and as pointed out in a reply, 
it's btrfs _filesystem_ usage we're talking about here, not btrfs 
_device_ usage, and at minimum, _filesystem_ usage including space on the 
device that's not yet allocated to that filesystem is indeed confusing/
unintuitive, and arguably actually incorrect, particularly if the btrfs 
device usage report reports that space under its "device slack" line, 
which as admins we don't actually know at this point (it doesn't appear 
to be documented except presumably in the code itself).  And arguably, if 
btrfs filesystem usage is to report it at all, it should be under a 
separate (additional) line, presumably device slack, if that's what the 
device usage version does with that line.

---
[1] Quote paraphrases a famous US political/legal quote from some years 
ago...  OT as to the merits, but if you wish the background, 
s/unallocated/is/ and google it using the search engine of your choice.

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