4

I know, there are dozens of similar questions everywhere. I have looked at many of them, and checked what their answers suggested, to no avail.

My root partition (btrfs) is almost full according to df:

> df -m /                                                                                                /
Filesystem     1M-blocks  Used Available Use% Mounted on
/dev/nvme0n1p2     56939 47349      8580  85% /

And btrfs fi df, it sometimes disagrees with df slightly:

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

So, being quite surprised by this, running du tells a completely different story:

> [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

(the script uses *-expansion to get the dir entries to scan, there are no dotfiles in the root)

The difference from 21G to 47G is quite large. Much bigger than any "rounding error" or probably fragmentation.

Things I checked/tried:

  • Rebooting/recovery mode -> nothing different
  • Overlayed mounts (using mount -o bind / /a_directory) -> nothing hidden
  • btrfs check -> no problems
  • btrfs scrub -> no change
  • btrfs fi defragment -> no change

I'm running out of ideas, does anyone have any other ideas of things to check? Could this be some strange behaviour of btrfs?

Similar questions:

btrfs - missing space, what is taking it up?

Disk full, du tells different. How to further investigate?

edit: @Martin Konrad, I think you hit the nail on the head! Didn't even know that apt did that. I did actually have a thought to check subvolumes at one point, but I think I lost that train of thought during the troubleshooting...

Here's the subvolumes list:

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

So, is it safe to just delete all but the @ one?

edit2: Found this Is it safe to delete apt-snapshot-*? and went ahead and removed all the snapshots, and indeed, (most of) the space came back! Well then... who "should" get their answer accepted? Which is more valued, faster or more accurate? :)

2
  • 2
    Can you edit your question and add the output of btrfs subvolume list? Jul 11, 2020 at 14:51
  • 1
    Is it possible you have old snapshots lingering around? Maybe apt-btrfs-snapshot is creating them automatically? Jul 11, 2020 at 15:03

0

You must log in to answer this question.

Browse other questions tagged .