我知道，到处都有几十个类似的问题。我查看了他们中的许多人，并检查了他们的答案建议，但无济于事。
根据以下信息，我的根分区 (btrfs) 几乎已满df：
> df -m / /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 56939 47349 8580 85% /
并且btrfs fi df，它有时与 df 略有不同：
Data, single: total=45.59GiB, used=45.19GiB
System, single: total=32.00MiB, used=16.00KiB
Metadata, single: total=2.00GiB, used=976.22MiB
GlobalReserve, single: total=93.81MiB, used=0.00B
因此，对此感到非常惊讶，跑步du讲述了一个完全不同的故事：
> [script checking for other fs than /; equivalent to du -smc]
other fs: dev home proc run srv sys tmp
19 bin
145 boot
29 etc
1 initrd.img
1 initrd.img.old
1135 lib
7 lib32
1 lib64
0 media
3178 opt
38 root
15 sbin
8860 usr
7866 var
1 vmlinuz
1 vmlinuz.old
21287 total
（该脚本使用*-expansion 来获取要扫描的目录条目，根目录中没有点文件）
21G和47G的区别是相当大的。比任何“舍入误差”或可能的碎片都要大得多。
我检查/尝试过的事情：
- 重新启动/恢复模式 -> 没有什么不同
- 覆盖安装（使用
mount -o bind / /a_directory）-> 没有任何隐藏 btrfs check-> 没问题btrfs scrub-> 没有变化btrfs fi defragment-> 没有变化
我没什么主意了，有人有其他想法可以检查吗？这可能是 btrfs 的一些奇怪行为吗？
类似问题：
编辑：@Martin Konrad，我认为你击中了要害！甚至不知道 apt 这样做了。我确实曾经想过检查子卷，但我想我在故障排除过程中失去了这个思路......
这是子卷列表：
ID 257 gen 5982556 top level 5 path @
ID 289 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-disco-2019-07-21_12:51:20
ID 290 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-disco-2019-07-21_12:51:23
ID 291 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-disco-2019-07-21_12:52:07
ID 310 gen 848394 top level 257 path srv
ID 312 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-eoan-2019-12-06_20:04:05
ID 313 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-eoan-2019-12-06_20:04:08
ID 314 gen 5981914 top level 5 path @apt-snapshot-release-upgrade-eoan-2019-12-06_20:04:48
那么，只删除除@该一个之外的所有内容是否安全？
编辑2：找到这个删除 apt-snapshot-* 是否安全？然后继续删除所有快照，事实上，（大部分）空间又回来了！那么......谁“应该”让他们的答案被接受？哪个更有价值、更快或更准确？ :)