Как найти файлы, которые занимают много места на конкретном разделе?

Мое название может быть не самым лучшим, поэтому я постараюсь объяснить.
Я использую старый компьютер (более 10 лет) с дистрибутивом в стиле Ubuntu. У него много независимых разделов.
Недавно появилось предупреждение о том, что “/” почти заполнен. Я запустил графический анализатор использования диска (baobab), чтобы проверить, что его раздувает, но это мало помогло. Дело в том, что baobab может показать, что находится в моей директории “home”, но не может показать, что находится, например, на /dev/sda3/ и только на /dev/sda3.
С другой стороны, такие инструменты, как gparted, могут сказать, что /dev/sda3/ — это раздел на 50 ГБ с 45 ГБ данных и 5 ГБ свободного места, но не говорят, из чего состоят эти 45 ГБ данных.
Я полагаю, решение может состоять в использовании дистрибутива livecd (например, systemrescuecd), монтировании /dev/sda3 в каталог и запуске анализатора использования диска на нем.
Тем не менее, я задумываюсь, не существует ли более простого способа сделать это. Есть подсказки?

-редактировать : По предложению @Jim L.-
Я прочитал страницу о Отслеживании исчезновения дискового пространства на Linux?, но не смог найти решение моей проблемы.
Мне нужно получить список всех файлов на конкретном разделе с указанием их размера. Это было бы похоже на запуск ncdu на /dev/sda3/ и только на /dev/sda3. Или чтобы ncdu показывал мне “этот файл находится на этом разделе”

Сначала нужно узнать, какие устройства (например, /dev/sda3) соответствуют каким частям файловой системы (например, / или /home). Это можно получить из простого вывода df -h. Просто посмотрите на первый и последний столбцы списка.

Если некоторое устройство, ответственное за части файловой системы, которые не полностью доступны вашей учетной записи обычного пользователя, заполняется и вам нужно сосредоточиться на том, что его заполняет, вы можете просто запустить baobab от имени root. Например:

sudo baobab /       # для корневой файловой системы
sudo baobab /home   # для любой подфайловой системы, например, /home

Ввиду того, что у вас несколько файловых систем, вам следует запускать baobab так на каждом смонтированном файловой системе, которая не является виртуальной файловой системой (то есть для каждой строки в выводе df -h, которая ссылается на реальное устройство /dev/<что-то..>, запустите sudo baobab <имя директории> для каталога, указанного в столбце Mounted on).

Если вам нужно сделать это в командной строке, вы можете запустить sudo du <имя директории> | sort -rn | less для каждого каталога Mounted on, так же как с baobab выше. Это выведет список каталогов в этой файловой системе, отсортированный по тому, сколько данных содержит этот каталог и его подкаталоги. Поэтому вам нужно будет обратить внимание на самые глубокие пути каталога в верхней части списка, так как именно так вы найдете фактические каталоги, содержащие необычно большие или чрезмерно большое количество файлов.

Пример: sudo du -kx /var | sort -rn | less на моей системе:

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

Верхняя строка — это целое /var, что само по себе не очень полезно. Но следующие три строки показывают, что основным источником расходования диска в /var является /var/cache, и в частности каталог /var/cache/apt/archives. Это логично, так как именно там находится каталог кэша менеджера пакетов, и недавно я получил довольно значительный набор обновлений.

После этого улаживания (с помощью apt clean all) я, возможно, захочу взглянуть на /var/log, чтобы выяснить, есть ли журналы, которые не архивируются или хранятся дольше, чем это необходимо.

Перед этим стоит /var/lib, который довольно велик, но не содержит отдельных подкаталогов, превышающих следующую запись в списке.

/var/lib/kdump, кажется, это место, где kdump создает файлы initramfs для коллекции дампов аварийного завершения, так что если я не захочу уменьшить количество установленных старых ядер, здесь нечего очищать.

/var/log/journal/<ID_машины> содержит постоянный журнал systemd-journald, который можно легко очистить с помощью sudo journalctl --vacuum-time=14d, чтобы избавиться от журналов старше 2 недель (поскольку это примерно тогда, когда я сделал довольно серьезную перенастройку системы, так что журналы до этого времени больше не будут актуальными).

Затем идет /var/tmp… и когда я это исследую, оказывается, что там есть старый файл резервной копии .tar.bz2, который я забыл удалить.

/var/lib/apt должен быть очищен вместе с /var/cache после выполнения sudo apt clean all.

Но затем есть /var/backup и в частности его подкаталог /var/backup/dualboot, который напоминает: он содержит резервные копии из инструмента, который я использовал для синхронизации пар подключения Bluetooth между Linux и Windows. Похоже, что он создал несколько резервных копий, которые не были автоматически очищены; похоже, мне нужно это исправить.

И так далее…