У меня есть SCSI-диск на сервере (аппаратный Raid 1), 32G, файловая система ext3. df сообщает мне, что диск заполнен на 100%. Если я удалю 1G, это будет отображаться правильно.
Однако если я запустил du -h -x / затем du говорит мне, что используется только 12G (я использую -x из-за некоторых монтировок Samba).
Итак, мой вопрос не о тонких различиях между командами du и df, а о том, как я могу выяснить, что вызывает эту огромную разницу?
Я перезагрузил компьютер, чтобы получить команду fsck без ошибок. Я должен бежать badblocks? lsof не показывает мне открытых удаленных файлов, lost+found пусто, и в файле сообщений нет очевидной инструкции warn / err / fail.
Не стесняйтесь спрашивать более подробную информацию о настройке.
Просто наткнулся на эту страницу, когда пытался отследить проблему на локальном сервере.
В моем случае 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 говорит. Возможно, у вас закончились inodes, что может произойти, если в этой файловой системе есть большое количество небольших файлов, которые используют все доступные inodes, не занимая все доступное пространство.
В моем случае это было связано с большими удаленными файлами. Это было довольно болезненно, прежде чем я нашел эту страницу, которая указала мне правильный путь.
Я наконец решил проблему, используя lsof | grep deleted, который показал мне, какая программа хранит два очень больших файла журнала (всего 5 ГБ из моего доступного корневого раздела 8 ГБ).
Файлы, открытые программой, на самом деле не исчезают (перестают занимать место на диске), когда вы их удаляете, они исчезают, когда программа закрывает их. В программе может быть огромный временный файл, который вы (и вы) не можете увидеть. Если это программа-зомби, вам может потребоваться перезагрузка, чтобы очистить эти файлы.
Для меня мне нужно было бежать sudo du поскольку под /var/lib/docker что пользователь, не являющийся пользователем sudo, не имеет разрешения на чтение.
Попробуйте это, чтобы увидеть, заблокирован ли мертвый / зависший процесс при записи на диск: lsof | grep "/ mnt"
Затем попробуйте отключить любые застрявшие PID (особенно обратите внимание на строки, заканчивающиеся на "(удалено)")
Это самый простой метод, который я нашел на сегодняшний день для поиска больших файлов!
Вот пример, если ваше корневое монтирование заполнено / (mount / root) Пример:
CD / (так что вы в корне)
ls | xargs du -hs
Пример вывода:
9.4M bin 63M boot 4.0K cgroup 680K dev 31M etc 6.3G home 313M lib 32M lib64 16K lost+found 61G media 4.0K mnt 113M opt du: cannot access `proc/6102/task/6102/fd/4': No such file or directory 0 proc 19M root 840K run 19M sbin 4.0K selinux 4.0K srv 25G store 26M tmp
тогда вы заметите, что хранить большой сделать cd / store
и беги снова
ls | xargs du -hs
Example output: 109M backup 358M fnb 4.0G iso 8.0K ks 16K lost+found 47M root 11M scripts 79M tmp 21G vms
в этом случае каталог vms - это пробел.
Так что у меня была эта проблема и в Centos 7, и я нашел решение, попробовав кучу вещей, таких как bleachbit и очистка / usr и / var, хотя каждый из них показал только около 7G. По-прежнему показывал, что 50 ГБ из 50 ГБ используется в корневом разделе, но показало использование файлов только 9 ГБ. Запустил live cd ubuntu и отключил проблемный раздел 50G, открыл терминал и запустил xfs_check и xfs_repair на этом разделе. Затем я перемонтировал раздел, и мой каталог lost + found расширился до 40 ГБ. Отсортировал потерянное + найденное по размеру и нашел текстовый файл журнала размером 38 ГБ для Steam, который в конечном итоге просто повторил ошибку mp3. Удален большой файл, и теперь у меня есть место, а использование моих дисков соответствует размеру моего корневого раздела. Я все еще хотел бы знать, как сделать так, чтобы журнал Steam не стал снова таким большим.
Еще одна возможность для рассмотрения - вы почти гарантированно увидите большое несоответствие, если вы используете докер и запускаете df / du внутри контейнера, который использует монтирование томов. В случае, если каталог подключен к тому на хосте докеров, df сообщит итоговые значения df HOST. Это очевидно, если подумать, но когда вы получите отчет о «сбежавшем контейнере, заполняющем диск!», Убедитесь, что вы проверяете потребление файлового пространства контейнером с помощью чего-то вроде du -hs <dir>.
проверьте, установлен ли на вашем сервере агент ossec. Или какой-то процесс использует удаленные файлы журнала. По моему некоторое время назад был агентом ossec.
Сегодня я столкнулся с этой проблемой на машине 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 или какой-то другой программный подход.
У меня была та же проблема, что упоминается в этой теме, но на одном VPS. Итак, я протестировал все, что описано в этой теме, но безуспешно. Решением стало обращение в службу поддержки к нашему провайдеру VPS, который выполнил пересчет квоты и исправил разницу в пространстве df -h и du-sh /.
То же самое произошло и с нами в продакшене, использование диска упало до 98%. Провел следующее расследование:
а) df -i для проверки использования inode, использование inode составляло 6%, поэтому файлы не намного меньше
б) Монтаж root и проверка скрытых файлов. Не удалось подать ни одного дополнительный файлы. du результаты были такими же, как и до монтирования.
в) Наконец, проверил nginxжурналы. Он был настроен для записи на диск, но разработчик удалил файл журнала, напрямую вызвав nginx чтобы хранить все журналы в памяти. Как файл /var/log/nginx/access.log был удален с диска с помощью rm это не было видно с помощью du но доступ к файлу получил nginx и, следовательно, он все еще удерживался открыто
если смонтированный диск является общей папкой на компьютере с Windows, то кажется, что df покажет размер и использование всего диска Windows, но du покажет только ту часть диска, к которой у вас есть доступ. (и установлен). поэтому в этом случае проблема должна быть устранена на машине Windows.
В моем случае lsof не помог. Я смог отследить это, потому что я смонтировал образы дисков, используя losetup в качестве устройств петли. Даже после размонтирования этих устройств и удаления соответствующих образов оставались процессы, которые поддерживали своего рода косвенную ссылку на образы дисков.
Короче говоря, sudo ps -ef|grep loop затем sudo losetup -d /dev/loopX. Это не прямой ответ на вопрос, почему du и df не согласны, но он всплывал для меня достаточно часто, чтобы я смог, наконец, выяснить причину, отличавшуюся от любого ответа, который я мог найти.
проверьте / lost + found, у меня была система (centos 7), и некоторые файлы в / lost + found занимали все место.