Вопрос: Диск полный, du говорит разные. Как продолжить расследование?


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

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

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

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

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


85
2018-05-30 12:29


Источник


Это очень близко к вопросу: linux-du vs. df разница (serverfault.com/questions/57098/du-vs-df-difference). Решением были файлы под точкой монтирования, на которые ответил OldTroll. - Chris Ting


Ответы:


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


83
2018-05-30 12:35



Вы можете найти эти скрытые файлы без необходимости размонтировать каталоги. Взгляните на ответ Марселя G ниже, в котором объясняется, как это сделать. - mhsekhavat


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

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


67
2018-03-12 11:10



Для меня блокировки, которые не были выпущены даже после того, как я остановил программу (зомби?). Мне пришлось kill -9 'pid' освободить замки. например: для вашего httpd это было бы kill -9 32617, - Micka
Незначительное примечание. Возможно, вам придется запустить lsof в виде sudo или не все открытые дескрипторы файлов будут отображаться - ChrisWue
Я столкнулся с этим с H2, который каждый день добавлял несколько концертов в лог-файл. Вместо перезапуска H2 (медленный) я использовал sudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd), - Desty
В моем случае даже при перезапуске httpd пространство не освобождается. Когда я побежал /etc/init.d/rsyslog restart он работал: D - Thanh Nguyen Van
Спасибо! Для меня это тоже было проблемой. У меня был огромный файл журнала, и даже после его удаления пространство не стало доступным. С lsof | grep deleted Я нашел то, что поддерживало его, и перезапуск службы снова запустил пространство. - Nemo


Я согласен с ответом OldTroll как наиболее вероятной причиной вашего «недостающего» пространства.

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

mount -o bind / /mnt

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

du -h /mnt

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

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


37
2018-05-30 13:54



Большое спасибо за этот совет. Разрешил мне находить и удалять мои большие «скрытые» файлы без простоя! - choover
Спасибо - это показало, что докер заполнял мой жесткий диск с различиями в /var/lib/docker/aufs/diff/ - naught101


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


23
2018-05-30 14:10



Размер файла и объем пространства, который он занимает в файловой системе, - две разные вещи. Чем меньше файлы, тем больше разница между ними. Если вы пишете скрипт, который суммирует размеры файлов и сравнивает его с du -s одного и того же поддерева, вы получите хорошую идею, если это так. - Marcin


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

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


15
2017-11-14 18:15



Этот ответ заставляет меня задаться вопросом, почему вы храните файлы журналов в корневом разделе, особенно тот, который маленький ... но для каждого из них, я полагаю ... - Michael Kjörling
У меня была аналогичная проблема, я перезапустил все приложения, которые использовали удаленный файл, я думаю, что существовал процесс зомби, который все еще держится за большой удаленный файл - user1965449
Это было для нас, приложение для обработки журналов, известное как файлы filebeat, которые были открыты. - Pykler


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


3
2018-05-30 12:51



ОП сказал, что он перезагрузил систему, и проблема продолжалась. - OldTroll
У меня были зомби, которые не выпустили бы блокировки на файлы, я kill -9 'pid' их освободить блокировки и вернуть дисковое пространство. - Micka


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

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


3
2018-06-26 10:38



Благодаря! Мне удалось найти, что процесс SFTP-сервера содержит удаленный файл - lyomi


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

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

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

ls | xargs du -hs

Пример:

 9.4M bin
 Загрузка 63M
 4.0K cgroup
 680K dev
 31М и т.д.
 6.3G домой
 313M lib
 32M lib64
 16K потеряно + найдено
 61G медиа
 4.0K mnt
 113M opt
 du: невозможно получить доступ к `proc / 6102 / task / 6102 / fd / 4 ': нет такого файла или каталога
 0 proc
 Корень 19M
 840K
 19 м сбин
 4.0K selinux
 4.0K srv
 Магазин 25G
 26M tmp

то вы заметили бы, что магазин большой cd / store

и снова запустите

ls | xargs du -hs

Пример вывода:
 109M резервная копия
 358M fnb
 4.0G iso
 8,0 тыс. Кс
 16K потеряно + найдено
 Корень 47M
 11M скрипты
 79M tmp
 21G vms

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


3
2018-06-26 13:05



Почему бы не использовать более простые инструменты, такие как baobab? (видеть marzocca.net/linux/baobab/baobab-getting-started.html) - Yvan
Hm ls + xargs кажется излишним, du -sh /* работает просто отлично - ChrisWue
если вы не знаете о ncdu ... вы поблагодарите меня позже: dev.yorhel.nl/ncdu - Troy Folger


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


1
2018-05-04 18:01



Это случилось с вами на работе? serverfault.com/help/on-topic - chicks
Нет, просто на моем домашнем компьютере. - Justin Chadwick
xfs_fsr исправил этот вопрос для нас - Druska