Диск полон, дю рассказывает другое. Как продолжить расследование?

У меня есть SCSI диск на сервере (аппаратный Raid 1), 32G, ext3 файловый элемент. dfговорит мне, что диск заполнен на 100%. Если я удаляю 1G, это правильно показано.

Однако, если я запускаю a, du -h -x /то duговорит мне, что используются только 12G (я использую -xиз-за некоторых монтировок Samba).

Так что мой вопрос не о тонких различиях между командами du и df, а о том, как я могу выяснить, что вызывает эту огромную разницу?

Я перезагрузил машину для fsck, который прошел без ошибок. Должен ли я бежать badblocks? lsofпоказывает, что нет открытых удаленных файлов, lost+foundпусто, и в файле сообщений нет явного оператора warn / err / fail.

Не стесняйтесь спрашивать более подробную информацию о настройке.

Проверьте наличие файлов в точках монтирования. Часто, если вы монтируете каталог (скажем, sambafs) в файловую систему, в которой уже есть файл или каталоги, вы теряете возможность видеть эти файлы, но они все еще занимают место на базовом диске. У меня были копии файлов в однопользовательском режиме, дамп файлов в каталоги, которые я не мог видеть, кроме как в одном пользовательском режиме (из-за того, что поверх них были смонтированы другие системы каталогов).

Просто наткнулся на эту страницу при попытке отследить проблему на локальном сервере.

В моем случае df -hи не du -shсоответствует примерно 50% размера жесткого диска.

Это было вызвано тем, что apache (httpd) хранил в памяти большие файлы журналов, которые были удалены с диска.

Это выследили, запустив lsof | grep "/var" | grep deletedгде /varбыл раздел мне нужно очистить.

Выходные данные показывали такие строки:
httpd 32617 nobody 106w REG 9,4 1835222944 688166 /var/log/apache/awstats_log (deleted)

Ситуация была разрешена путем перезапуска apache ( service httpd restart) и очистки 2 ГБ дискового пространства, позволяя очистить блокировки удаленных файлов.

Я согласен с ответом OldTroll как наиболее вероятной причиной вашего "пропущенного" места.

В Linux вы можете легко перемонтировать весь корневой раздел (или любой другой раздел) в другое место в вашей файловой системе, например, / mnt, просто выполните команду

mount -o bind / /mnt

тогда вы можете сделать

du -h /mnt

и посмотрите, что занимает ваше пространство.

Ps: извините за добавление нового ответа, а не комментария, но мне нужно было некоторое форматирование, чтобы этот пост был читабельным.

Посмотри что df -iговорит. Может случиться так, что у вас нет inode, что может произойти, если в этой файловой системе есть большое количество маленьких файлов, которые используют все доступные inode, не занимая все доступное пространство.

В моем случае это было связано с большими удаленными файлами. Было довольно трудно решить, прежде чем я нашел эту страницу, которая поставила меня на правильный путь.

Наконец, я решил проблему с помощью программы lsof | grep deleted, которая показала мне, в какой программе хранятся два очень больших файла журнала (всего 5 ГБ моего доступного корневого раздела 8 ГБ).

Файлы, которые открываются программой, на самом деле не удаляются (перестают использовать дисковое пространство) при их удалении, а исчезают, когда программа их закрывает. Программа может иметь огромный временный файл, который вы (и du) не можете увидеть. Если это зомби-программа, вам может потребоваться перезагрузка, чтобы очистить эти файлы.

Попробуйте это, чтобы увидеть, заблокирован ли мертвый / зависший процесс во время записи на диск: lsof | grep "/ mnt"

Затем попробуйте убить все застрявшие PID (особенно ищите строки, оканчивающиеся на "(удалено"))

Это самый простой метод, который я нашел на сегодняшний день, чтобы найти большие файлы!

Вот пример, если ваше корневое монтирование заполнено / (mount / root) Пример:

CD / (так что вы в корне)

ls | xargs du -hs

Пример вывода:

 9,4 М бен
 63M boot
 4.0K cgroup
 680 тыс. Устройств
 31 м и т. Д.
 6.3G домой
 313M lib
 32M lib64
 16K потеряно + найдено
 61G медиа
 4,0 тыс. Т
 113M опт
 du: не может получить доступ к `proc / 6102 / task / 6102 / fd / 4 ': такого файла или каталога нет
 0 проц
 19M корень
 Пробег 840К
 19М сбин
 4.0K selinux
 4.0K срв
 25G магазин
 26 миллионов тонн

тогда вы заметите, что магазин большой, сделайте CD / магазин

и беги снова

ls | xargs du -hs

Пример вывода: 
 Резервное копирование 109M
 358 млн фнб
 4.0G iso
 8.0 Кс
 16K потеряно + найдено
 47M корень
 11M скриптов
 79 млн тонн
 21G VMS

в этом случае директория vms является пробелом.

Для меня мне нужно было запустить, так sudo duкак было много файлов докеров, под /var/lib/dockerкоторыми пользователь не-sudo не имеет разрешения на чтение.

Еще одна возможность для рассмотрения - вы почти гарантированно увидите большое расхождение, если вы используете docker, и вы запускаете df / du внутри контейнера, который использует том-монтирования. В случае каталога, подключенного к тому на хосте докера, df сообщит итоги df HOST. Это очевидно, если вы подумаете об этом, но когда вы получите отчет о «убегающем контейнере, заполняющем диск!», Убедитесь, что вы проверили потребление файлового пространства контейнера чем-то вроде du -hs <dir>.

Так что у меня была эта проблема и в Centos 7, и я нашел решение после того, как попробовал кучу таких вещей, как bleachbit и cleaning / usr и / var, хотя они показывали только около 7G каждый. По-прежнему показывал 50G из 50G, используемых в корневом разделе, но показывал только 9G использования файла. Запустил работающий Ubuntu CD и размонтировал поврежденный раздел 50G, открыл терминал и запустил xfs_check и xfs_repair на этом разделе. Затем я перемонтировал раздел, и мой каталог lost + found расширился до 40G. Сортировал потерянный + найденный по размеру и нашел 38G текстовый лог-файл для steam, который в итоге просто повторил ошибку mp3. Удалил большой файл, теперь у него есть место, и использование моих дисков соответствует размеру моего корневого раздела. Я все еще хотел бы знать, как заставить паровой журнал не расти снова таким большим.

если подключенный диск является общей папкой на компьютере с Windows, то кажется, что df покажет размер и использование диска всего диска Windows, но du покажет только ту часть диска, к которой у вас есть доступ. (и смонтирован). поэтому в этом случае проблема должна быть исправлена ​​на машине с Windows.

Аналогичная вещь произошла с нами на производстве, использование диска возросло до 98%. Провел следующее расследование:

а) df -iдля проверки использования инода, использование инода составило 6%, поэтому файлы не намного меньше

б) Монтирование rootи проверка скрытых файлов. Не удалось подать дополнительные файлы. duрезультаты были такими же, как и до монтирования.

в) Наконец, проверил nginxлоги. Он был настроен на запись на диск, но разработчик удалил файл журнала напрямую, в результате чего nginxвсе журналы были сохранены в памяти. Поскольку файл /var/log/nginx/access.logбыл удален с диска с помощью, rmон не был виден с помощью, duно доступ к файлу осуществлялся nginxи, следовательно, он все еще оставался открытым

У меня была та же проблема, которая упоминается в этой теме, но в одном VPS. Поэтому я проверил все, что описано в этой теме, но безуспешно. Решением стало обращение в службу поддержки нашего провайдера VPS, который выполнил пересчет квот и исправил разницу в размерах df -hи du-sh /.

Я столкнулся с этой проблемой сегодня на коробке FreeBSD. Проблема заключалась в том, что это был артефакт vi(нет vim, не уверен, vimчто создаст эту проблему). Файл занимал место, но не был полностью записан на диск.

Вы можете проверить это с помощью:

$ fstat -f /path/to/mount/point |sort -nk8 |tail

Он просматривает все открытые файлы и сортирует (численно через -n) по 8-му столбцу (ключ, -k8), показывая последние десять элементов.

В моем случае последняя (самая большая) запись выглядела так:

bob      vi         12345    4 /var      97267 -rwx------  1569454080 rw

Это означало, что процесс (PID) 12345 потреблял 1,46 ГБ (восьмой столбец, разделенный на 1024 ³) диска, несмотря на его отсутствие du. viужасно при просмотре очень больших файлов; даже 100 МБ это большое для него. 1,5 ГБ (или как бы велик этот файл на самом деле) нелепо.

Решение было в sudo kill -HUP 12345том, что (если это не сработает, я буду, sudo kill 12345и если это тоже не kill -9получится , то страшные войдут в игру).

Избегайте текстовых редакторов на больших файлах. Примеры обходных путей для быстрого скимминга:

Предполагая разумную длину строки:

• { head -n1000 big.log; tail -n1000 big.log } |vim -R -
• wc -l big.log |awk -v n=2000 'NR==FNR{L=$1;next}FNR%int(L/n)==1' - big.log |vim -R -

Предполагая неоправданно большие строки:

• { head -c8000 big.log; tail -c8000 big.log } |vim -R -

Они используют vim -Rвместо, viewпотому что vimпочти всегда лучше ... когда он установлен. Не стесняйтесь трубить их viewили vi -Rвместо.

Если вы открываете такой большой файл на самом деле изменить его, рассмотреть sedили awkили какой -либо другой программный подход.

проверьте, установлен ли на вашем сервере агент ossec. Или какой-то процесс использует удаленные файлы журнала. По моему некоторое время назад был агентом осек.

проверьте / lost + found, у меня была система (centos 7) и часть файла в / lost + found исчерпала все пространство.