В начале моей карьеры в DevOps я удалил 5-гигабайтный лог-файл на продакшн-сервере, где заканчивалось место

Я запустил df -h, ожидая увидеть, что использование диска уменьшилось. Не снизилось. Всё ещё показывало 100% заполнения.

Ни ошибок, ни варнингов. Просто та же картинка, как будто я ничего не удалял.

Тогда я и понял, что удаление файла не всегда сразу освобождает место.

В Linux то, что мы считаем «файлом», на самом деле состоит из двух сущностей: имени файла (это всего лишь указатель) и inode (в нём хранятся данные и метаданные). Когда вы удаляете имя файла, вы всего лишь убираете указатель. Inode и его данные остаются на диске до тех пор, пока какой-то процесс держит файл открытым.

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

Диск освободился только после того, как я перезапустил веб-сервер, и он закрыл все свои файловые дескрипторы.

Вот почему нужны разные команды, чтобы видеть реальную картину:

# Проверить использование ФС
df -h  

# Проверить реальные размеры директорий
du -sh /var/log/*  

# Найти удалённые файлы, которые всё ещё держат процессы
lsof +L1

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

Если цифры не сходятся, скорее всего, у тебя есть удалённые файлы, которые всё ещё держат процессы.

По этой же причине корректная ротация логов не просто удаляет файлы. Инструменты вроде logrotate переименовывают файлы и шлют сигнал процессам, чтобы те закрыли и заново открыли дескрипторы.

Три ключевых вывода:
1. Имена файлов — это всего лишь указатели на inode
2. Удаление действительно происходит, только когда ни один процесс не ссылается на inode
3. При разборе проблем с местом на диске всегда смотрите и df, и du

Мелочь, но понимание этого может спасти от очень запутанных инцидентов в продакшене.

👉 DevOps Portal