Диск полный, 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.

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

83 голоса | спросил initall 30 Maypm11 2011, 16:29:48

15 ответов


83

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

ответил OldTroll 30 Maypm11 2011, 16:35:23
67

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

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

ответил KHobbits 12 MarpmWed, 12 Mar 2014 15:10:25 +04002014-03-12T15:10:25+04:0003 2014, 15:10:25
37

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

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

mount -o bind / /mnt

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

du -h /mnt

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

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

ответил Marcel G 30 Maypm11 2011, 17:54:32
23

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

ответил eirescot 30 Maypm11 2011, 18:10:58
15

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

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

ответил Adrian 14 52014vEurope/Moscow11bEurope/MoscowFri, 14 Nov 2014 21:15:03 +0300 2014, 21:15:03
3

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

ответил Paul Tomblin 30 Maypm11 2011, 16:51:09
3

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

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

ответил Phirsk 26 J0000006Europe/Moscow 2011, 14:38:00
3

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

Вот пример, если ваше корневое монтирование полно /(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

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

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

ls | xargs du -hs

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

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

ответил Riaan 26 J0000006Europe/Moscow 2011, 17:05:41
1

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

ответил Justin Chadwick 4 Maypm17 2017, 21:01:06
0

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

ответил Sverre 21 J0000006Europe/Moscow 2012, 14:33:29
0

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

ответил Troy Folger 6 TueEurope/Moscow2016-12-06T02:02:34+03:00Europe/Moscow12bEurope/MoscowTue, 06 Dec 2016 02:02:34 +0300 2016, 02:02:34
0

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

ответил jobevers 9 FebruaryEurope/MoscowbFri, 09 Feb 2018 14:51:50 +0300000000pmFri, 09 Feb 2018 14:51:50 +030018 2018, 14:51:50
0

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

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

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

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

ответил darxtrix 20 PMpFri, 20 Apr 2018 22:23:57 +030023Friday 2018, 22:23:57
0

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

ответил ldxd 18 J000000Wednesday18 2018, 16:33:12
-3

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

ответил Jude Zhu 24 42016vEurope/Moscow11bEurope/MoscowThu, 24 Nov 2016 01:24:17 +0300 2016, 01:24:17

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132