Смонтированное устройство занимает место в Ubuntu [дубликат]

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

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

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

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

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

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

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

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

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

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

Kelli l-istess problema li tissemma f'dan is-suġġett, iżda f'VPS wieħed. Allura ttestjajt dak kollu li huwa deskritt f'dan is-suġġett imma mingħajr suċċess. Is-soluzzjoni kienet kuntatt għal appoġġ mal-fornitur tal-VPS tagħna li wettaq kalkolu mill-ġdid tal-kwota u kkoreġa d-differenza fl-ispazju ta ' df -h u du-sh /.

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

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

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

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

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

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

Это означало, что процесс (PID) 12345 потреблял 1,46 G (восьмой столбец, деленный на 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 -vn = 2000 'NR == FNR {L = $ 1; следующий} FNR% int (L / n) == 1 '- big.log | vim -R -

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

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

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

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

compruebe si su servidor tiene instalado el agente ossec. O algún proceso está utilizando los archivos de registro eliminados. En mi hace un tiempo era el agente ossec.

В моем случае lsof не помогло. Я смог это отследить, так как монтировал образы дисков, используя losingetup как закольцованные устройства. Даже после размонтирования этих устройств и удаления соответствующих образов существовали процессы, которые поддерживали своего рода косвенную ссылку на образы дисков.

Короче говоря, sudo ps -ef|grep loop then sudo losetup -d /dev/loopX. Это не прямой ответ на вопрос, почему du и df не согласны, но достаточно часто мне приходило в голову, что я смог наконец-то выяснить причину, которая отличалась от любого ответа, который я мог найти.