удаление файлов, но дисковое пространство все еще заполнено

Имея дело со старой коробкой CentOS 5.6, без установки lvm, моя корневая файловая система / переполнена, я очистил много старых файлов журналов и файлов приложений, которые мне не нужны, которые были больше чем 2 -5 ГБ, однако моя система по-прежнему сообщает, что диск заполнен.

[root@tornms1 ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             130G  124G     0 100% /
/dev/sdb1             264G  188M  250G   1% /data
/dev/sda1              99M   24M   71M  26% /boot
tmpfs                 2.0G     0  2.0G   0% /dev/shm



[root@tornms1 ~]# mount
/dev/sda3 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sdb1 on /data type ext3 (rw)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Любая идея о том, что я должен попытаться сделать дальше? к сожалению, перезагрузка коробки не вариант в настоящее время.

Здесь могут происходить две вещи.

Во-первых , ваша файловая система зарезервировала некоторое пространство, в которое rootможет выполнять запись только так, чтобы критический системный процесс не падал, когда обычным пользователям не хватает места на диске. Вот почему вы видите 124G 130G, но ноль доступно. Возможно, файлы, которые вы удалили, снизили уровень использования до этого уровня, но не ниже порогового значения для обычных пользователей.

Если это ваша ситуация, и вы в отчаянии, вы можете изменить количество места, отведенного для root. Чтобы уменьшить его до 1% (по умолчанию 5%), ваша команда будет

# tune2fs -m 1 /dev/sda3

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

Если вы удалите файл, который используется процессом, вы больше не сможете просматривать файл с помощью ls. Процесс все еще записывает в этот файл, пока вы не остановите процесс.

Чтобы просмотреть эти удаленные файлы, просто запустите lsof|grep delete

2 других способа получить диск это полная проблема:

1) скрытый под точкой монтирования: linux покажет полный диск с файлами, «скрытыми» под точкой монтирования. Если у вас есть данные, записанные на диск и монтирующие поверх него другую файловую систему, linux правильно отмечает использование диска, даже если вы не видите файлы под точкой монтирования. Если у вас есть монтирования nfs, попробуйте их монтировать и посмотреть, не было ли что-нибудь случайно записано в этих каталогах перед монтированием.

2) поврежденные файлы: иногда я вижу это при передаче файлов через Linux в SMB. Один файл не может закрыть дескриптор файла, и вы получите 4ГБ файл мусора.

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

cd /
du -sh ./* 

Количество каталогов верхнего уровня обычно ограничено, поэтому я установил удобочитаемый флаг, -hчтобы увидеть, какой подкаталог является пробелом.

Затем вы перейдете к проблемному дочернему элементу и повторите процедуру для всех элементов в нем. Чтобы упростить обнаружение крупных предметов, мы немного изменим du и свяжем его с сортировкой.

cd /<suspiciously large dir>
du -s ./* | sort -n

который производит наименьший к наибольшему выводу по байтовому размеру для всех файлов и каталогов

4          ./bin 
462220     ./Documents
578899     ./Downloads
5788998769 ./Grocery List

Как только вы обнаружите слишком большой файл, вы можете просто удалить его.

Вы можете узнать, какие файлы открыты с помощью lsof. Он может выводить много информации, поэтому в приведенном ниже примере я ограничился строками, заканчивающимися на log:

# lsof | grep log$
rsyslogd   2109     syslog    0u     unix 0xffff88022fa230c0      0t0       8894      /dev/log
rsyslogd   2109     syslog    1w      REG              252,6    62393         26 /var/log/syslog
rsyslogd   2109     syslog    2w      REG              252,6   113725        122 /var/log/auth.log
rsyslogd   2109     syslog    3u     unix 0xffff88022fa23740      0t0       8921 /var/spool/postfix/dev/log
rsyslogd   2109     syslog    5w      REG              252,6    65624        106 /var/log/mail.log
/usr/sbin  2129       root    2w      REG              252,6    93602         38 /var/log/munin/munin-node.log
/usr/sbin  2129       root    4w      REG              252,6    93602         38 /var/log/munin/munin-node.log
...

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

#lsof +L1

он даст идентификатор процесса и дескриптор файла. Обнулить удаленный файл дескриптором файла

#echo "" > /proc/$pid/fd/$fd 

Введите команду

#lsof +L1

Который покажет список файлов, в которых хранится память с удаленной цитатой.

Обратите внимание на pid (идентификатор процесса) файла

Убить процесс

#kill <pid>

Память будет освобождена процессом

Проверьте это командой

#df -h

В дополнение к тому, что было объяснено, проблема может заключаться в том, что существует другая точка монтирования удаленного файлового каталога на другом подключенном дисковом устройстве на том же сервере. Проверьте текущие монтирования и записи fstab.

Актуальная проблема наблюдается в дикой природе:

Убедитесь, что вы удаляете фактические файлы, а не символические ссылки на файлы. Это может быть особенно важно для файлов журналов.