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

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

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

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

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

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

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

dumpe2fs /dev/sda1 | grep -i reserved

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

tune2fs -m 0 /dev/sda1

В большинстве случаев сервер будет продолжать работать нормально - при условии, что все процессы выполняются как «root».

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

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

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

df -i

I had this problem and was baffled by the fact deleting various large files did not improve the situation (didn't know about the 5% buffer) anyway following some clues here

From root walked down the largest directories revealed by repetitively doing:-

du -sh */ 

until I came a directory for webserver log files which had some absolutely massive logs

which I truncated with

:>lighttpd.error.log

suddenly df -h was down to 48% used!

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

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

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

Если ваш раздел - btrfs, возможно, есть подтом, занимающий место. Файловая система btrfs может иметь много подтомов, только один из которых смонтирован. Вы можете использовать btrfs subvolume list

Я сделал большое обновление нескольких библиотек, и там было много ненужных библиотек и временных файлов, поэтому я освобождаю место в папке «/», используя:

apt-get install -f
sudo apt-get clean

И очищаю вашу корзину

Если вам не хватает места в /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

Вы можете увидеть смещение 90G <> 46G. Это в файлах выше.

Затем просто уничтожьте 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 '(удален)' | grep 'dev/shm' | awk '{напечатать $2}' | sudo xargs kill -9 заключается в том, что лежащие в основе процессы могут все еще работать. Если вы уверены, что это/они есть/нет, эта команда является потенциальной альтернативой в зависимости от вашего сценария. Это убьет все процессы, которые открыли «удаленные» файлы.

Поскольку это была первая страница моего поиска в 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

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