Файловая система Linux; разница в расчете размера с использованием df & du

Question

Когда я запускаю df он показывает, что корневое устройство заполнено.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             9.9G  9.4G     0 100% /

Я посмотрел на использование inode и есть достаточно места для корневого устройства

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda1               640K    103K    538K   16% /

Но когда я запускаю команду du , это показывает, что я использовал только 2G из 9.9G .

ip-XXX-XXX-XXX-XXX:/$ du -xh --max-depth=1
14M ./etc
4.0K ./mnt
96K ./tmp
3.5M ./bin
0   ./sys
964K ./boot
4.0K ./srv
0   ./dev
55M ./lib
25M ./root
1.1G ./usr
4.0K ./opt
846M ./var
4.3M ./sbin
23M ./home
16K ./lost+found
0   ./proc
2.0G .

Это просто сводит меня с ума и интересно тоже. Это большая проблема для нас, поскольку корневой диск / заполнен и некоторые функции нашего сайта не работают.

Пожалуйста, помогите мне решить (также понять) эту проблему.

Благодарю.

Answer 1

Когда файлы удаляются в * nix, они продолжают жить на диске (и занимают место на диске) до тех пор, пока процесс открывает их. Довольно часто это можно использовать для "защиты" временных файлов, создавая их с небольшим размером, удаляя их, а затем используя удаленный файл для хранения данных, не беспокоясь о том, что другие процессы (легко) могут получить к нему доступ, поэтому объем пространства в удаленных файлах может вырасти довольно большим, если, скажем, таким образом обрабатывается временная база данных или сеанс редактирования мультимедиа. Другая возможность того, как вы могли бы получить так много "потерянного" пространства, была бы, если бы система была обновлена (многократно) без перезагрузки или перезапуска программ, в результате чего все ваши старые библиотеки .so были открыты программами, которые были запущены до обновить и все еще работает.

df видит пространство, используемое этими файлами, потому что просто смотрит, сколько места выделено на устройстве, но du не видит их, потому что нет соответствующих записей каталога.

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

Answer 2

Были случаи, когда, если диск был заполнен, его можно перепутать до перезагрузки / переустановки, что диск все еще заполнен, даже если вы удалили загрузку файлов.

Answer 3

Со своей стороны, я просто перезапустил syslogd, чтобы вернуть дисковое пространство. Мне не хватило 3ГБ! Мой сервер был запущен в течение 250 дней.

Answer 4

Существует способ очистки пространства без перезапуска приложения. Вот подробности:

1. Допустим, у вас запущен процесс foo и вы создали файл размером 2 ГБ с именем abc.log. Теперь скажите, что этот abc.log удален кем-то другим.

2. Получить foo (скажем, 123). Поэтому /proc/123/fd покажет список файловых дескрипторов, открытых foo . Один с abc.log покажет как удаленный. Допустим, fd of abs.log составляет 111. Если вы запустите less /proc/123/fd/111 , он все равно покажет вам все эти 2 ГБ данных.

3. Запустите echo " " > /proc/123/fd/111 . Это перезапишет содержимое пустой строкой. После этой команды, если вы попробуете df она покажет дополнительные 2 ГБ, восстановленные очисткой abc.log.

Вот и все. Я попробовал это на CentOS, и это работает.