On 13.02.2022 20:13, Kévin Le Gouguec wrote:
Hello folks,
(I hope this is the right list; if not: apologies, and where would this belong more? users@? support@? Somewhere else?)
I have Tumbleweed installed on a pair of desktops: the first since February 2018, and the second since April 2021. I let the former gather dust since setting up the latter until a couple of weeks ago; I figured that dist-upgrading this "old" setup was the responsible thing to do after waking it up (openSUSE-release 20210621 → 20220122).
The upgrade itself went smoothly, but now I'm facing a problem that I have experienced quite often with this first desktop (though not with the second desktop yet): 'btrfs filesystem usage /' says that… *something* is close to bursting, and I suspect that the next 1GB+ dist-upgrade will have me scrambling again for disk space, and confused about snapshot management.
First, what I think I understand (see footnotes for the commands I use to come to these conclusions):
* I have about 20GB's worth of actual data in the /… subvolume? partition?, estimated by weighing /usr.[1]
Yes, it looks like it.
* The / subvolume is 40GB, and has almost no free space left.[2]
* My recent upgrade left me with a 15GB snapshot that *I think* is responsible for / being so full?[3]
Yes. This snapshot consumes 15GB of unique (non-shared) data. Showing btrfs qgroup show / may give some more information.
(2) Is this 2018 setup still salvageable, or should I reinstall? I try to follow factory@lists.opensuse.org and project@lists.opensuse.org, so I know that Tumbleweed underwent some Big Changes between February 2018 and April 2021; I assume that reinstalling should nonetheless not be necessary, and I just messed something up?
Delete offending snapshot (as long as you are sure you will not need it to rollback). snapper delete 2 Note that this may move accounting of this data to different snapshot, in the worst case you may need to delete all of them.
(3) What does this huge snapshot represent? The dates in snapper list make me think that it's a diff between the first installation (2018-02-20) and the last upgrade (2022-01-24), in which case, yup, of course the diff would be huge.
So look inside this snapshot? Snapshot is filesystem content at some point in time. Snapshot "grows" when content of actual (root) filesystem changes and starts to differ from what is in snapshot. If you have 15G of packaged files and did huge update that touches *all* packages (there were several not long ago), then snapshot will have old files and you root will have new files.
Empirically though deleting this huge snapshot just moves all the gigabytes into snapshot 1 (that's what I remember happening the last time I tried to reclaim disk space), which I cannot delete. Is there a way to tell snapper to just forget about 2018 and use the last upgrade as the oldest point of reference?
No, that should not happen. Snapshot 1 is your actual root filesystem. You cannot delete it. So show actual results after "snapper delete 2".
(4) There are some differences between the two desktop setups I don't understand. For one, 'btrfs filesystem usage /' reports very different device sizes: on the first setup it's 40GB; on the second setup it's roughly 440GB.[4] This is surprising to me, since both disks have similar total sizes (about 500GB).[5]
There are disks and there are partitions. You "old" desktop has 40G root partition, the rest is partition with xfs filesystem. Probably /home, at some point Tumbleweed installation defaulted to this layout. 40G is a bit tight and suitable for the basic installation only.
Also, the subvolume setup seems different?[6] Not sure why the older setup has /tmp listed, since findmnt /tmp tells me it's a tmpfs; why is it still on btrfs's radar? Also, why does the newer setup have entries for /root and /home, and not the older one?
Yes, things change over time. ...
[3] On the older desktop: # snapper --iso \ list --columns number,type,date,used-space,cleanup,description # | Type | Date | Used Space | Cleanup | Description ---+--------+---------------------+------------+---------+---------------------- 0 | single | | | | current 1* | single | 2018-02-20 20:13:41 | 237.26 MiB | | first root filesystem 2 | pre | 2022-01-24 07:39:54 | 15.98 GiB | number | zypp(zypper) 3 | post | 2022-01-24 12:58:38 | 12.64 MiB | number | 4 | pre | 2022-01-24 13:46:28 | 960.00 KiB | number | zypp(zypper) 5 | post | 2022-01-24 13:49:01 | 73.57 MiB | number |
...
[6] On the older desktop: # btrfs subvolume list / | grep -v snapshots/ ID 257 gen 622718 top level 5 path @ ID 258 gen 638632 top level 257 path @/var ID 259 gen 637339 top level 257 path @/usr/local ID 260 gen 622718 top level 257 path @/tmp ID 261 gen 637339 top level 257 path @/srv ID 262 gen 637339 top level 257 path @/opt ID 263 gen 629216 top level 257 path @/boot/grub2/x86_64-efi ID 264 gen 637331 top level 257 path @/boot/grub2/i386-pc ID 265 gen 637331 top level 257 path @/.snapshots ID 269 gen 637339 top level 258 path @/var/lib/machines
That does not match. Please, NEVER filter output. Now we have no idea whether your system is seriously broken or you just decided to now show this data. In particular, omitting snapshots will make interpreting output of btrfs qgroup show / near to impossible.