Как определить, насколько заполнен мой раздел, даже если он не заполнен?

Question

Я запустил "df -kh" на моей коробке FreeBSD и вижу, что /var заполнен почти на 100%. Все было кончено, но я обрезал все, что смогу, но на разделе осталось менее 500 МБ в соответствии с командой "du -ksh *" в /var. Сам раздел /var имеет размер 6,8 ГБ, и теперь в нем говорится, что у него всего 18 МБ. Это просто не складывается.

Я запускаю следующую команду, я не нахожу никаких преступников.

 find . -type f -size +2000 -exec ls -lh {} \; | awk '{ print $9 ": " $5 }'

Я даже просматривал папку за папкой, используя «du -ksh *», чтобы определить папки с большим количеством использования диска, но я не могу найти, как все это складывается. Я хотел бы сжать, удалить или переместить файлы, чтобы освободить больше места, так как в других разделах есть место, но между df и du я не могу найти то, что использует все дисковое пространство.

Что еще я должен сделать, чтобы найти файлы и папки, занимающие все пространство?

Answer 1

Считаете ли вы, что у вас может быть несвязанный файл, который все еще открыт? Попробуйте просмотреть вывод команды lsof /var чтобы увидеть, есть ли в списке необычно большие файлы.

Answer 2

Я бы запустил следующее, чтобы у вас был хороший снимок всех файлов для работы:

du -kx /var | sort -n | tee /var/tmp/du_results.out

... а затем посмотрите на последние несколько сотен строк.

Это отлавливает размер всех каталогов (для отлова большого количества маленьких файлов), а также отлавливает обычные большие файлы. Обратите внимание, что я не использую -h (удобочитаемый для человека), поэтому результаты легко сортируются по номерам. Также обратите внимание, что я не использую /var/* , который также подцепил бы что-нибудь, смонтированное в /var .

Возможные виновники включают, в грубом порядке вероятности:

• Устаревшие несвязанные файлы. Попробуйте то, что не предложил @not simon (lsof /var). /var/tmp иногда является очевидным местом для их поиска. Если у вас не установлен lsof , вы можете использовать fstat -f /var | sort -k 8 -n , который не показывает имена файлов, но по крайней мере покажет размеры (от наименьшего к наибольшему), inode и какой процесс имеет открытый файл.

• Повреждение файловой системы. Запустите fsck из однопользовательского режима, чтобы проверить /var .

• Старые файлы скрыты под точками монтирования. Если в /var есть какие-либо монтирования, размонтируйте их, а затем снова запустите поиск / диагностику. Возможно, самый безопасный способ сделать это - загрузить в однопользовательском режиме и просто смонтировать /var не монтируя ничего под ним.

Различия в сообщениях о размере файлов могут быть связаны с наличием разреженных или сжатых файлов. Вы можете использовать опцию -A du работать с видимым размером файла вместо использования диска, который мог бы объяснить некоторые расхождения. Вставьте, а затем опустите и сравните результаты. В моем примерно 3,6 ГБ /var разделе результаты с -A были примерно на 100 МБ меньше.

Answer 3

У меня была похожая проблема, когда диск исчез. Точка монтирования еще существовала, но по какой-то причине файлы записывались в каталог раздела, содержащего точку монтирования. Это может не относиться к вашей операционной системе, но загрузка спасательной системы и просмотр разделов могут открыть больше.