2014-04-07 13:42:39 +0000 2014-04-07 13:42:39 +0000
26
26

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

Имея дело со старым CentOS 5.6 box, без установки 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)

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

Ответы (9)

38
38
38
2014-04-07 14:02:13 +0000

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

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

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

# tune2fs -m 1 /dev/sda3

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

18
18
18
2015-09-24 09:32:08 +0000

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

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

10
10
10
2014-04-07 21:03:43 +0000

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

2) ** повреждённые файлы:** Иногда я вижу это при передаче файлов из windows в linux через SMB. Один файл не закрывает дескриптор файла, и вы получаете 4 Гб мусорный файл.

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

cd /
du -sh ./*

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

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

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

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

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

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

4
4
4
2014-04-07 14:27:52 +0000

Вы можете узнать, какие файлы открыты с помощью 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
...
1
1
1
2017-06-08 10:02:04 +0000

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

#lsof +L1

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

#echo "" > /proc/$pid/fd/$fd
```.
1
1
1
2020-02-27 01:18:39 +0000

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

1
1
1
2017-10-31 13:45:06 +0000

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

#lsof +L1

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

Обратите внимание на pid ( Process id ) файла

Убейте процесс

#kill <pid>

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

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

#df -h
0
0
0
2016-06-02 09:58:41 +0000

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

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

0
0
0
2016-01-23 08:00:36 +0000

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

Похожие вопросы

6
10
5
37
10