У меня есть 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.
Не стесняйтесь спрашивать более подробную информацию о настройке.
linux
ext3
disk-space-utilization
scsi
initall
источник
источник
Ответы:
Проверьте наличие файлов в точках монтирования. Часто, если вы монтируете каталог (скажем, 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 ГБ дискового пространства, позволяя очистить блокировки удаленных файлов.источник
kill -9 'pid'
освободить замки. Например: для вашего httpd это было быkill -9 32617
.lsof
какsudo
или не все открытые дескрипторы файлов будут отображатьсяsudo truncate -s0 /proc/(h2 PID)/(descriptor number obtained from ls /proc/h2pid/fd)
.httpd
пространство не освобождается. Когда я побежал,/etc/init.d/rsyslog restart
это сработало: Dlsof -a +L1 /var
, где-a
означает И все условия (по умолчанию ИЛИ),+L1
означает, что список только файлы с количеством ссылок меньше 1 (то есть, удаленные файлы с открытыми файловыми дескрипторами), и/var
ограничивает файлы в этой точке монтированияЯ согласен с ответом OldTroll как наиболее вероятной причиной вашего "пропущенного" места.
В Linux вы можете легко перемонтировать весь корневой раздел (или любой другой раздел) в другое место в вашей файловой системе, например, / mnt, просто выполните команду
тогда вы можете сделать
и посмотрите, что занимает ваше пространство.
Ps: извините за добавление нового ответа, а не комментария, но мне нужно было некоторое форматирование, чтобы этот пост был читабельным.
источник
/var/lib/docker/aufs/diff/
Посмотри что
df -i
говорит. Может случиться так, что у вас нет inode, что может произойти, если в этой файловой системе есть большое количество маленьких файлов, которые используют все доступные inode, не занимая все доступное пространство.источник
du -s
одним и тем же поддеревом, вы получите хорошую идею, если это так.В моем случае это было связано с большими удаленными файлами. Было довольно трудно решить, прежде чем я нашел эту страницу, которая поставила меня на правильный путь.
Наконец, я решил проблему с помощью программы
lsof | grep deleted
, которая показала мне, в какой программе хранятся два очень больших файла журнала (всего 5 ГБ моего доступного корневого раздела 8 ГБ).источник
Файлы, которые открываются программой, на самом деле не удаляются (перестают использовать дисковое пространство) при их удалении, а исчезают, когда программа их закрывает. Программа может иметь огромный временный файл, который вы (и du) не можете увидеть. Если это зомби-программа, вам может потребоваться перезагрузка, чтобы очистить эти файлы.
источник
kill -9 'pid'
их снимала блокировки и возвращала место на диске.Попробуйте это, чтобы увидеть, заблокирован ли мертвый / зависший процесс во время записи на диск: lsof | grep "/ mnt"
Затем попробуйте убить все застрявшие PID (особенно ищите строки, оканчивающиеся на "(удалено"))
источник
Это самый простой метод, который я нашел на сегодняшний день, чтобы найти большие файлы!
Вот пример, если ваше корневое монтирование заполнено / (mount / root) Пример:
CD / (так что вы в корне)
ls | xargs du -hs
Пример вывода:
тогда вы заметите, что магазин большой, сделайте CD / магазин
и беги снова
ls | xargs du -hs
в этом случае директория vms является пробелом.
источник
baobab
? (см. marzocca.net/linux/baobab/baobab-getting-started.html )ls
+xargs
кажется излишним,du -sh /*
само по себе прекрасно работаетДля меня мне нужно было запустить, так
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. Удалил большой файл, теперь у него есть место, и использование моих дисков соответствует размеру моего корневого раздела. Я все еще хотел бы знать, как заставить паровой журнал не расти снова таким большим.
источник
xfs_fsr
исправил эту проблему для насесли подключенный диск является общей папкой на компьютере с 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
что создаст эту проблему). Файл занимал место, но не был полностью записан на диск.Вы можете проверить это с помощью:
Он просматривает все открытые файлы и сортирует (численно через
-n
) по 8-му столбцу (ключ,-k8
), показывая последние десять элементов.В моем случае последняя (самая большая) запись выглядела так:
Это означало, что процесс (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 исчерпала все пространство.
источник