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
