Одна из неприятных ситуаций на сервере выглядит так: удалили большой файл, а место на диске не появилось.
rm отработал, файла уже нет, но df -h показывает почти то же самое заполнение. Кажется, что что-то сломалось, но обычно проблема не в диске, а в том, как устроено удаление файлов.Важно понять простую вещь: когда вы делаете
rm, файл не исчезает с диска мгновенно. Удаляется ссылка на файл из файловой системы. Но если какой-то процесс все еще держит этот файл открытым, его данные продолжают занимать место.То есть для ядра ситуация выглядит так:
имени файла уже нет;
в каталоге он не виден;
но процесс все еще пишет или читает его через открытый file descriptor.
Пока этот дескриптор не будет закрыт, место не освободится.
▪️ Типичный сценарий:
приложение пишет большой лог;
лог удалили вручную;
процесс продолжает держать файл открытым;
du файл уже не видит;df показывает, что место все еще занято.Именно поэтому иногда возникает странная картина:
du -sh /var/log
показывает одно, а
df -h
говорит, что диск почти заполнен.
▪️ Как найти такие файлы:
lsof | grep deleted
Или точнее:
lsof +L1
Эта команда показывает открытые файлы, у которых уже удалена ссылка из файловой системы.
Там часто находятся: старые логи, временные файлы, дампы, файлы после ротации и мусор, который держит зависший процесс.
▪️ Что делать дальше:
самый правильный вариант - перезапустить процесс, который держит файл
иногда достаточно корректно перечитать логи через systemctl reload
в крайнем случае: restart сервиса
Например, если это nginx, rsyslog, java-процесс или postgres, после перезапуска место обычно сразу возвращается.
▪️ Почему это важно знать:
Админ может удалить 20 ГБ логов и не понять, почему сервер все равно задыхается. А потом начать искать битую файловую систему, хотя проблема всего лишь в открытом удаленном файле.
du считает то, что видно в дереве каталогов.
df показывает то, что реально занято на файловой системе.
Если файл удален, но открыт процессом,
du его уже не увидит, а df - да.#linux #storage
🧑💻 NetworkAdmin