df говорит, что диск заполнен, но это не так.

На виртуальном сервере с Ubuntu 10.04, df сообщает следующее:

# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             7.4G  7.0G     0 100% /
none                  498M  160K  498M   1% /dev
none                  500M     0  500M   0% /dev/shm
none                  500M   92K  500M   1% /var/run
none                  500M     0  500M   0% /var/lock
none                  500M     0  500M   0% /lib/init/rw
/dev/sda3             917G  305G  566G  36% /home

Это вызывает у меня недоумение по двум причинам: 1.) df говорит, что /dev/sda1, смонтированный на /, имеет емкость 7.4 гигабайта, из которых занято только 7.0 гигабайта, но все же сообщает, что / заполнен на 100 процентов; и 2.) я могу создавать файлы на /, так что очевидно, что место еще есть.

Возможно, это связано с тем, что каталог /www является символической ссылкой на /home/www, который находится на другом разделе (/dev/sda3, смонтированном на /home).

Кто-нибудь может предложить, что здесь происходит? Сервер, кажется, работает без проблем, но я хочу удостовериться, что нет проблем с таблицей разделов, файловыми системами или чем-то еще, что может привести к коллапсу (или взрыву) позже.

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

Вы можете проверить это с помощью команды sudo lsof +L1

5% (по умолчанию) файловой системы зарезервировано на случай, когда файловая система заполнена, чтобы предотвратить серьезные проблемы. Ваша файловая система заполнена. Ничего катастрофического не происходит из-за этого 5%-ого буфера — root имеет разрешение использовать этот запасной буфер, и в вашей настройке у пользователей, не обладающих правами root, нет причин писать в эту файловую систему.

Если у вас есть демоны, которые запускаются под пользователем, не обладающим правами root, но которым нужно управлять файлами в этой файловой системе, то это приведет к сбоям. Один из таких демонов — named. Другой — ntpd.

Возможно, у вас закончились индексы. Проверьте использование индексов с помощью этой команды:

df -i

Большинство файловых систем Linux (ext3, ext4) резервируют 5% пространства для использования только пользователем root.

Вы можете увидеть это, например, с помощью

dumpe2fs /dev/sda1 | grep -i reserved

Вы можете изменить количество зарезервированного пространства, используя:

tune2fs -m 0 /dev/sda1

0 в этой команде означает процент от размера диска, так что, возможно, вы захотите оставить хотя бы 1%.

В большинстве случаев сервер будет выглядеть как работающий нормально, при условии, что все процессы выполняются с правами root.

В дополнение к уже предложенным причинам, в некоторых случаях это может быть также следующее:

• диск монтируется “поверх” существующей папки, которая полна данных
• du вычисляет размер занятого места на смонтированном диске, а df показывает реально занятое
• решение: (когда возможно) размонтируйте все не-root диски и снова проверьте размер с помощью du -md 1. Исправьте ситуацию путем перемещения скрытой папки в другое место или монтирования в другом месте.

У меня была эта проблема, и я был озадачен тем, что удаление различных больших файлов не улучшало ситуацию (я не знал о 5%-ом буфере) в любом случае, следуя некоторым указаниям здесь

С уровня root я прошел по крупнейшим каталогам, выявленным путем периодического выполнения:-

du -sh */ 

пока не наткнулся на каталог с лог-файлами вебсервера, содержащий некоторые абсолютно огромные логи

которые я укоротил с помощью

:>lighttpd.error.log

внезапно df -h показал 48% использованного!

df -h округляет значения. Даже проценты округляются. Уберите -h, и вы увидите более тонкие различия.

О. И в ext3 и производных резервируется процент (по умолчанию 5%) для файловой системы именно для этой проблемной ситуации. Если ваша корневая файловая система действительно будет заполнена (0 байт остается), вы не сможете загрузить систему. Таким образом, зарезервированная часть предотвращает это.

Если у вас заканчивается место на /dev/shm и вы удивлены почему (учитывая, что фактически используемое пространство (df -shc /dev/shm) намного меньше, чем выделенный размер /dev/shm)? lsof может помочь:

$ sudo lsof -s +L1 | awk '{print $7" "$2" "$3" "$10}' | grep 'dev/shm' | grep "^[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]" 
7931428864 1133806 roel /dev/shm/1600335920/subreducer/2/data/ibtmp1
12710576128 1133806 roel /dev/shm/1600335920/subreducer/2/tmp/#sql-temptable-114cee-8-e18.MAD
4173332480 1352445 roel /dev/shm/1600335920/subreducer/1/data/ibtmp1
13040484352 1352445 roel /dev/shm/1600335920/subreducer/1/tmp/#sql-temptable-14a2fd-8-eb3.MAD
9670602752 2298724 roel /dev/shm/1600338626/subreducer/2/tmp/#sql-temptable-231364-8-d2e.MAD

Первый файл занимает ~7,9ГБ, второй около 12,7ГБ и т.д. Регулярное выражение подбирает все, что превышает 1ГБ. Вы можете настроить регулярное выражение по своему усмотрению.
Причиной может быть, что иначе “мертвый” процесс удерживает файл.
df -h не покажет проблему;

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            90G   90G  508K 100% /dev/shm

508K, однако…

$ du -shc | grep total
46G total

Вы можете видеть разницу в значениях между 90ГБ и 46ГБ. Она заключена в файлах выше.

Затем просто убейте PID (kill -9 PID), указанный во второй колонке вывода выше.

$ kill -9 1133806

Результат:

Filesystem      Size  Used Avail Use% Mounted on
tmpfs            90G   72G   19G  80% /dev/shm

Отлично, место освобождено.

Причина выполнения действий таким образом, а не просто с использованием команды sudo lsof +L1 | grep '(deleted)' | grep 'dev/shm' | awk '{print $2}' | sudo xargs kill -9 заключается в том, что базовый процесс(ы) может(ут) еще работать. Если вы уверены, что он(и) не работает(ют), эта команда может быть возможной альтернативой в зависимости от вашего сценария. Она убьет все процессы, у которых открыты ‘удаленные’ файлы.

Я сделал большую обновление нескольких библиотек и было много ненужных библиотек и временных файлов, так что я освободил место в папке “https://serverfault.com/” с помощью:

apt-get install -f
sudo apt-get clean

И очистил корзину

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

Если ваш раздел является btrfs, возможно, существует подтом, занимающий пространство. Файловая система btrfs может иметь множество подтомов, и только один из них может быть смонтирован. Вы можете использовать btrfs subvolume list <dir> для перечисления всех подтомов и btrfs subvolume delete <dir>/<subvolume> для удаления одного из них. Убедитесь, что вы не удаляете тот, который монтируется по умолчанию.

Поскольку это была первая страница в моем поиске в Google, я надеюсь, что смогу помочь кому-то здесь. Я знаю, что это очень старый пост и речь идет о разделе /, а не /boot.

Во-первых, моя система использует xfs.
В выходные df -h показал /boot на 100%
однако du -h /boot использовал всего 40M

Чтобы решить мою проблему, я выполнил

1. umount /boot
2. xfs_repair /dev/sda1
3. mount -a
4. df -h /boot

Система теперь показывает правильное использование

У меня было множество веб-проектов, на довольно маленьком vps-диске, и я столкнулся с этой проблемой. Я очистил папку /backups и удалил множество старых папок node_modules/vendor из старых проектов.

node_modules печально известен тысячами крошечных файлов

затем перезагрузился – ошибка исчезла

Это решило мою проблему:
отмонтируйте все ваши смонтированные диски резервного копирования (df -h показывает их)
и проверьте, есть ли данные в каталогах монтирования.
Резервные копии записываются в каталоги монтирования, если они не смонтированы.
Удалите данные в каталогах монтирования и снова смонтируйте их.