У меня есть небольшой 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
чтобы узнать, откуда/
взялась их файловая система...)
- команда для монтирования (во второй раз)