December 26, 2018 11:15 PM, "Duncan" <1i5t5.duncan@xxxxxxx> 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
