Диск заполнен, но не могу найти занятое место (Ubuntu)

Диск заполнен, но не могу найти занятое место (Ubuntu)

У меня есть небольшой Intel NUC с диском на 30 ГБ. Моя проблема в том, что этот диск заполнен, но я не могу найти причину этого.

dfсообщаем следующее

Filesystem     1K-blocks      Used Available Use% Mounted on
udev              899412         0    899412   0% /dev
tmpfs             189284      2676    186608   2% /run
/dev/sda2       28414508  27751116         0 100% /
tmpfs             946404         0    946404   0% /dev/shm
tmpfs               5120         4      5116   1% /run/lock
tmpfs             946404         0    946404   0% /sys/fs/cgroup
/dev/loop0           128       128         0 100% /snap/bare/5
/dev/loop1         56832     56832         0 100% /snap/core18/2128
/dev/loop2         56832     56832         0 100% /snap/core18/2246
tmpfs             946404         0    946404   0% /tmp
/dev/loop3        314880    314880         0 100% /snap/makemkv/381
/dev/loop4         66688     66688         0 100% /snap/gtk-common-themes/1515
/dev/loop5         63360     63360         0 100% /snap/core20/1169
/dev/loop6         63360     63360         0 100% /snap/core20/1081
/dev/loop7         33280     33280         0 100% /snap/snapd/13270
/dev/loop8        317184    317184         0 100% /snap/makemkv/385
/dev/loop9         33280     33280         0 100% /snap/snapd/13640
/dev/loop10        66816     66816         0 100% /snap/gtk-common-themes/1519
/dev/sda1         306584      5356    301228   2% /boot/efi
tmpfs             189280         4    189276   1% /run/user/1000

Если подсчитать, то получится где-то около ~14 ГБ занятого дискового пространства.

Бегsudo lsof | grep REG | grep -v "stat: No such file or directory" | grep -v DEL | awk '{if ($NF=="(deleted)") {x=3;y=1} else {x=2;y=0}; {print $(NF-x) " " $(NF-y) } }' | sort -n -u | numfmt --field=1 --to=iec | tail -10

дает мне список с несколькими процессами, которые имеют значение:

5,5M  /usr/lib/php/20190902/fileinfo.so
6,8M  /usr/lib/jellyfin/bin/libcoreclr.so
8,0M  /var/log/journal/6296b00d07874d0a9533eed0efb81840/user-1000.journal
8,2M  /usr/lib/jellyfin/bin/System.Private.Xml.dll
8,3M  /usr/lib/locale/locale-archive
8,9M  /usr/lib/jellyfin/bin/System.Private.CoreLib.dll
10M  /usr/lib/udev/hwdb.bin
24M  /snap/snapd/13640/usr/lib/snapd/snapd
27M  /usr/lib/x86_64-linux-gnu/libicudata.so.66.1
64M  /memfd:pulseaudio

Запуск sudo du -sh / --exclude=disks --totalдает мне в общей сложности 13 ГБ.

Итак, по сути, у меня нет идей, как выяснить, где находятся недостающие ~16 ГБ, о которых система сообщает, что они где-то заполняют мой диск.

Отчет на самом деле ведет себя как таковой, работает

cd ~/ && touch example && echo "FooBar" > example
-bash: echo: write error: No space left on device

Спасибо заранее, и любая идея хороша, в основном, у меня есть устройство, которое в данный момент непригодно для использования, и у меня мало вариантов (в основном чистая переустановка/покупка большего SSD для устройства, которое не должно использовать более 20 ГБ)

решение1

Вот несколько вариантов, как попытаться найти то, что заполняет ваш раздел "/":

  • lsof -nP +L1 # следует перечислить все файлы, которые были удалены (откреплены), но все еще открыты процессом и поэтому все еще занимают место
  • См. также этот ответ:https://unix.stackexchange.com/a/68532/27616который дает некоторую дополнительную информацию и советы, которые можно попробовать
  • Другая возможность: проверьте (с помощью df -ih /), нет ли у вас "миллионов" маленьких файлов в этой /файловой системе: каждый файл занимает по крайней мере "небольшое" количество на диске (обычно потому, что он занимает по крайней мере 1 inode, размер которого зависит от размера файла и файловой системы). Это может суммироваться... если минимальное занимаемое дисковое пространство составляет 512 байт, то наличие 1 миллиона файлов по 1 байту все равно займет 512 миллионов байт вместо 1 миллиона байт. dfпокажет занятое дисковое пространство (полное пространство inode подсчитано), тогда как duпокажет добавленные размеры файлов (т. е. только содержимое этих файлов, а не пространство, которое занимают inode(ы), содержащие это содержимое)
  • Другая возможность: может быть, есть некоторый большой файл(ы), скрытый смонтированной файловой системой. То есть, некоторые файлы могут лежать "под" смонтированной файловой системой (может быть, вы поместили много больших файлов в/tmp каталог(тот, который находится в /файловой системе и который затем используется как точка монтирования для монтирования /tmpфайловой системы) ? Это может произойти, если вы помещаете туда что-то, пока файловая /tmpсистема не была смонтирована. Чтобы проверить это, вы можете в Linux перемонтировать /(используя устройство свободного цикла) как доступное только для чтения где-нибудь (например: смонтировать его под /mnt/readonlyroot/точкой монтирования), и просмотреть его с помощью du -hs /mnt/readonlyroot, и сравнить с du -hxs /# -xпредотвращает переход du в другую файловую систему, смонтированную под /, например, /tmpв файловую систему, например).
    • команда для монтирования (во второй раз) /как readonly в некоторой точке монтирования: вы можете (насколько я помню... я не могу проверить это на Linux прямо сейчас):
      • mkdir -p /mnt/rootreadonly/для создания точки монтирования каталога (которая, по иронии судьбы, будет находиться внутри файловой системы "/"...)
      • mount -o loop -o ro /dev/sda2 /mnt/rootreadonly(чтобы эта файловая система "/" отображалась там как доступная только для чтения. Я указываю здесь sda2, поскольку вы указываете в своем вопросе, что ваша файловая система "/" находится в "/dev/sda2". Кто-нибудь другой, читающий этот ответ, должен сначала проверить вывод, mountчтобы узнать, откуда /взялась их файловая система...)

Связанный контент