Я не думаю, что в этом случае вам может помочь "инструмент визуализации дискового пространства": пространство, занимаемое и видимое для таких инструментов, одинаково видно для du , только эти инструменты делают это более подробно. Но инструмент по-прежнему будет сообщать только о тех 8-10 ГБ, которые, как вы уже знаете, используются, а не сообщать, где находятся эти двадцать гигабайт, которые "отсутствуют в действии".
Возможное объяснение "исчезающего" пространства таких пропорций состоит в том, что оно находится в одном (или более) удаленных файлах.
Если вы откроете файл в Unix и, пока он еще открыт, вы удалите (отмените связь) его, он все равно будет "существовать", но будет виден только процессу, содержащему свой файловый дескриптор, и немедленно исчезнет, как только процесс завершится, выпустив дескриптор.
Это отличный способ управления временными файлами.
К сожалению, если временный файл пропадает и данные непрерывно добавляются в него, не закрывая и не воссоздавая файл, то много места на диске может "исчезнуть".
В качестве пользователя root попробуйте:
ls -la /proc/*/fd/* | grep deleted
Имена файлов и идентификаторы процессов скажут вам, какие процессы поддерживают "несвязанное" пространство.
Если вы можете сделать это, конечно, перезагрузка будет иметь тот же эффект быстрее. И некоторые процессы настолько переплетены в системе, что на самом деле лучше их перезагрузить, чем завершать и управлять всеми другими зависимыми процессами и службами.
Например, на моей машине у меня есть около 25 таких файлов, и этот
lrwx------ 1 root root 64 May 9 07:45 /proc/732/fd/8 -> /tmp/vmware-root/vmware-usbarb-732.log (deleted)
Я знаю, что иногда растет в мегабайтном диапазоне. Бег
vmware-usbarbitrator --kill
vmware-usbarbitrator
может освободить в любом месте от нуля до 100M пространства, в зависимости от того, как долго он работает и сколько я использовал vmplayer .
Автоматизация проверки
Чтобы проверить, какие файлы занимают много места, можно проверить их размеры: большинство несвязанных файлов занимают всего несколько байтов.
Этот метод использует wc , что крайне неэффективно; возможно, открытие файла, поиск SEEK_END и возврат значения ftell() будет намного, намного быстрее (особенно для больших файлов). Но для этого нужно собрать небольшую утилиту.
for i in $( ls -la /proc/*/fd/* 2>/dev/null \
| grep deleted \
| sed -e 's/.*\(\/proc\S*\) -.*/\1/g' ); do
wc -c $i | tr "\n" "="; readlink $i
done | grep -v "^0 " | sort -rn
Это использует (надеюсь) портативный способ перечисления виртуальных файлов всех удаленных файлов и читает их с помощью wc . Затем для каждого файла читает символическую ссылку. Файлы нулевой длины игнорируются, чтобы избежать беспорядка.
На моей недавно загруженной системе это дает мне
217032 /proc/812/fd/9=/var/run/nscd/dbMn7Auu (deleted)
217032 /proc/812/fd/8=/var/run/nscd/dbMn7Auu (deleted)
3278 /proc/2357/fd/3=/tmp/vmware-root/vmware-apploader-2327.log (deleted)
2257 /proc/2422/fd/7=/tmp/vmware-root/vmware-authdlauncher-2418.log (deleted)
так что я знаю, что nscd использует 400 КБ "невидимого пространства" (это не изменится, если я перезапущу nscd ; так что, вероятно, это рабочая область, которая не увеличивается ... сильно. Ничто не мешает мне следить за процессом, хотя).
Также было бы легко сохранить приведенный выше код в небольшой утилите и запустить его через cron , отбрасывая все значения, скажем, до 500 мегабайт, но отправив электронное письмо администратору, если что-нибудь всплывет в конце концов.
