私も知っている、似たような質問がどこにも何十ものあるということです。私はそれらの多くを見て、彼らの答えの提案を確認しましたが、役に立ちませんでした。
次の情報によると、ルートパーティション（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の奇妙な動作ですか？
エマルジョン：
ディスクがいっぱいです。 duは別の方法で言います。さらなる調査方法は何ですか？
編集：@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-*を削除しても安全ですか？その後、すべてのスナップショットを削除すると、実際に（ほとんどの）スペースが再び回復されます！それでは…誰が彼らの答えを受け入れるべきですか？どちらがより価値があり、より速く、より正確ですか？ :)