linux4noobs

1387 readers

1 users here now

linux4noobs

Noob Friendly, Expert Enabling

Whether you're a seasoned pro or the noobiest of noobs, you've found the right place for Linux support and information. With a dedication to supporting free and open source software, this community aims to ensure Linux fits your needs and works for you. From troubleshooting to tutorials, practical tips, news and more, all aspects of Linux are warmly welcomed. Join a community of like-minded enthusiasts and professionals driving Linux's ongoing evolution.

Seeking Support?

Mention your Linux distro and relevant system details.
Describe what you've tried so far.
Share your solution even if you found it yourself.
Do not delete your post. This allows other people to see possible solutions if they have a similar problem.
Properly format any scripts, code, logs, or error messages.
Be mindful to omit any sensitive information such as usernames, passwords, IP addresses, etc.

Community Rules

Keep discussions respectful and amiable. This community is a space where individuals may freely inquire, exchange thoughts, express viewpoints, and extend help without encountering belittlement. We were all a noob at one point. Differing opinions and ideas is a normal part of discourse, but it must remain civil. Offenders will be warned and/or removed.
Posts must be Linux oriented
Spam or affiliate links will not be tolerated.

founded 1 year ago

MODERATORS

PlutoParty

[SOLVED] Ubuntu disk space usage after upgrade from 20.04 to 22.04 (self.linux4noobs)

submitted 9 months ago* (last edited 9 months ago) by andnekon to c/linux4noobs

9 comments fedilink hide all child comments

Hello, everyone. Recently I finally decided to update my system, and right after the update ran into a problem: before update baobab showed ~22 GB avaliable space, and after the update it went down to around 8.

Here's some info, that might be relevant:

df output:

Filesystem     1K-blocks     Used Available Use% Mounted on
tmpfs             788700     1976    786724   1% /run
/dev/nvme0n1p8  53050368 48246568   4054792  93% /
tmpfs            3943496        0   3943496   0% /dev/shm
tmpfs               5120        4      5116   1% /run/lock
/dev/nvme0n1p8  53050368 48246568   4054792  93% /home
/dev/nvme0n1p7    998060   133944    795304  15% /boot
/dev/nvme0n1p1    364544    89768    274776  25% /boot/efi
tmpfs             788696      104    788592   1% /run/user/1000

du -h / shows 23G, du -h /home — 13G. Overall I have 54.3G disk space, so (23+13)/54 doesn't add up to 93%

sudo lsof | grep deleted | wc -l shows 8433 deleted files that are still in use.

I also tried booting with liveUSB and running 'check' on partition via GParted.

I did some research online:

https://forum.manjaro.org/t/baobab-shows-14gb-less-usage-where-is-the-rest/109527 - seems like a similar problem, but does not address huge du/df difference, also doesn't provide solution for me
https://unix.stackexchange.com/questions/414417/du-not-accounting-for-space-shown-by-df helped me understend difference between du/dh, so I provided output of lsof as suggested.
a lot of other stackoverflow posts, all having similar answers, that didn't help me

I tried some methods to locate what consumes all the space, but couldn't figure it out. Also, the problem seems to be getting worse (right now baobab shows only ~5GB avaliable space). Can you help me find the source of the problem (and ideally also help me solve it :) )?

all 13 comments

sorted by: hot top controversial new old

[–] Still 4 points 9 months ago (1 children)

because you've updated be tween releases you may have a large cache of file for apt

you may want to run sudo apt-get autoclean to remove old files that aren't in the repo (replaced with new versions)

apt-cache stats will tell you info about the cache

[–] andnekon 1 points 9 months ago

Running sudo apt-get autoclean && sudo apt-get autoremove was the first thing I tried.

I am not sure, how do I interpret output of apt-cache stats?

spoiler

Total package names: 126893 (3,553 k)
Total package structures: 122145 (5,374 k)
  Normal packages: 81989
  Pure virtual packages: 2797
  Single virtual packages: 22954
  Mixed virtual packages: 2708
  Missing: 11697
Total distinct versions: 101553 (8,937 k)
Total distinct descriptions: 180829 (4,340 k)
Total dependencies: 609988/159599 (14.8 M)
Total ver/file relations: 32564 (782 k)
Total Desc/File relations: 49757 (1,194 k)
Total Provides mappings: 50727 (1,217 k)
Total globbed strings: 239740 (5,895 k)
Total slack space: 65.4 k
Total space accounted for: 47.7 M
Total buckets in PkgHashTable: 196613
  Unused: 109956
  Used: 86657
  Utilization: 44.0749%
  Average entries: 1.40952
  Longest: 17
  Shortest: 1
Total buckets in GrpHashTable: 196613
  Unused: 103120
  Used: 93493
  Utilization: 47.5518%
  Average entries: 1.35725
  Longest: 8
  Shortest: 1

[–] JaxNakamura 2 points 9 months ago (1 children)

A reboot will make whatever processes that are still using those deleted files let go of them. Maybe that solves your problem. If not, ncdu will help you find large files and directories.

[–] andnekon 1 points 9 months ago

I've already tried rebooting (as mentioned in the post, I've run GParted 'check' from liveUSB, reboot after. Also, I've done it seperately). And ncdu shows basically the same result as baobab — it doesn't add up to 93% disk usage from df

[–] andnekon 1 points 9 months ago* (last edited 9 months ago)

I want to thank everyone for the help!

I was finally able to find the issue. Thanks to @[email protected] 's question regarding my filesystem type, I decided to look into it.

I use btrfs, and this command showed me, that I have a lot of snapshots made by apt.

$ sudo btrfs subvolume list -s /         
...
ID 318 gen 2617038 cgen 2566262 top level 5 otime 2024-02-13 06:59:10 path @apt-snapshot-release-upgrade-jammy-2024-02-13_06:59:10

It was probably possible to determine how much space each of them was occupying, but I decided to simply delete them all and be done with the issue. So I installed apt-btrfs-snapshot and run delete-older-than 0d.

As a result, I now have 29 Gb and no backups, which is fine with me.

This answer on askubuntu was useful