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

[Duncan <1i5t5.duncan@cox.net>]

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