how to find files that bloats a specific partition? [duplicate]

Question

This question already has answers here:

Tracking down where disk space has gone on Linux? (40 answers)

Closed 8 months ago.

My title may not be the best so I will try to explain it.
I am using an old computer (more than 10y) with a ubuntu style distro. It has a lot of independent partitions.
I recently had an alert telling me that "/" is nearly full. I launch a graphic disk usage analyzer (baobab) to check what was bloating it but it didn't help much. The reason is that baobab can tell me what is in my "home" directory but it cannot tell me what is on -as an example- /dev/sda3/ and /dev/sda3 only. On the other hand, tools like gparted can tell me that /dev/sda3/ is a 50GB partition with 45GB data and 5GB free space but it doesn't tell me what those 45GB data are made of.
I guess a solution could be to use a livecd distro (such as systemrescuecd), mount /dev/sda3 in a directory and run a disk usage analyzer on it.
However I wonder if there is not a more simple way to do it. Any clue?

-edit : Following @Jim L. suggestion-
I read the page about Tracking down where disk space has gone on Linux? but I couldn't find a solution to my problem.
What I need is to get a list of all the files on a specific partition with their size. Would be something like running ncdu on /dev/sda3/ and /dev/sda3/ only. Or having ncdu tell me "this file is on this partition"

• Grenouille: @JimL. thank you for you suggestion. I will edit. The page you suggest doesn't helps me or maybe it is that I do not understand it well.
• Jim L.: First, read the man page for du(1). Then add the output of this command to your post: sudo du -shx /* | sort -h | tail -n 20
• Grenouille: @JimL. thank you for trying to help me but I fear "du" cannot help. The reason is if I well understand, du does not perceive the hardware under the filesystem. I used an advanced partition scheme on this computer so a file in a sub-directory may be in a different partition than a file in another sub-directory. Furthermore, in more than ten years of use, I used other tricks such as creating a 10GB file and mounting it as a partition. du doesn't seems to perceive that. In fact this 10GB file was the culprit.
• Stephen Kitt: @Grenouille when you say "this 10GB file was the culprit", does that mean you’ve solved your problem?
• Grenouille: @StephenKitt I mean I only solved the problem of my computer telling me that "/" was full. However, that was after days of searching what could be going on, until I remembered by pure luck that 8 years ago I had created this huge file. I don't want to rely on luck alone if this problem happens again, that's why I'm trying to find a tool that could do the job properly. In other words, I'm looking for a software that could tell me: "you have a problem on this partition because of this (those) big file(s) located on this partition in this directory".

Answer 1

First, you need to know which devices (like /dev/sda3) correspond to which parts of the filesystem tree (like / or /home). You can get that from a simple df -h listing. Just look at the first and the last columns of the listing.

Then, if some device that is responsible of some parts of the filesystem tree that are not fully accessible to your regular user account is getting full and you'll need to zero in on whatever's filling it up, you could simply run baobab as root. For example:

sudo baobab / # for the root filesystem
sudo baobab /home # for any sub-filesystem, like /home here

Since you have multiple filesystems, you should run baobab like that in each mounted filesystem you have that is not a virtual filesystem (i.e. for every line in df -h output that refers to a real /dev/<something..> device, run sudo baobab <directory name> for the directory listed in the Mounted on column).

If you have to do this on the command line, you can run sudo du <directory name> | sort -rn | less on each Mounted on directory, just like with baobab above. This will list the directories in that filesystem, ordered by how much data that directory and its sub-directories contain. So you'll need to pay attention at the deepest directory paths towards the top of the listing, as that's how you'll find the actual directories containing exceptionally big or exceptionally large numbers of files.

Example: sudo du -kx /var | sort -rn | less on my system:

5861812 /var
3008568 /var/cache
2598836 /var/cache/apt
2482196 /var/cache/apt/archives
1459084 /var/lib
738072 /var/log
339928 /var/lib/kdump
319296 /var/log/journal
319292 /var/log/journal/<machine-id redacted>
319240 /var/tmp
317000 /var/lib/apt
316668 /var/lib/apt/lists
300296 /var/backup
300292 /var/backup/bt-dualboot
247760 /var/tmp/kdecache-myusername
241788 /var/cache/apt-xapian-index
241784 /var/cache/apt-xapian-index/index.2
219044 /var/lib/dpkg
202324 /var/lib/dpkg/info
188216 /var/log/atop
137360 /var/lib/texmf
134796 /var/lib/texmf/web2c
99760 /var/lib/dlocate
69444 /var/log/atsar
62256 /var/lib/sddm
59792 /var/lib/texmf/web2c/pdftex
56700 /var/lib/sddm/.cache
[...]

The top line is the whole of /var, which is not very useful in itself. But the next three lines reveal that the biggest disk hog within /var is /var/cache, and specifically the /var/cache/apt/archives directory. That makes sense, as that's where the package manager's cache directory is, and I've recently received a fairly big set of updates.

Once that's sorted (with apt clean all), I might then want to take a look at /var/log to see if there are logs that aren't being rotated or are being preserved for way longer than necessary.

Before that, there is /var/lib which is pretty large, but contains no individual sub-directories larger than the next entry in the list.

/var/lib/kdump seems to be where kdump builds its crash dump collection initramfs files, so unless I want to decrease the number of old kernels I have installed, there's nothing I could clean up here.

/var/log/journal/<machine id> contains the persistent journal of systemd-journald, which can be easily cleaned up using sudo journalctl --vacuum-time=14d to get rid of journals older than 2 weeks (since that's about when I did a fairly major system reconfiguration, so logs from before that are not going to be relevant any more).

Then there is /var/tmp... and when I investigate that, it turns out there is an old backup .tar.bz2 file I've forgotten to remove.

/var/lib/apt should get cleaned together with /var/cache once I run sudo apt clean all.

But then there's /var/backup and specifically its sub-directory /var/backup/dualboot which rings a bell: it contains backups from a tool I used to synchronize Bluetooth pairings between Linux and Windows. Looks like it has made a number of backups which haven't been cleaned up automatically; it seems I'll need to fix that.

And so on...