Что такое inodes и зачем за ними наблюдать

Что проверяют

Знаете ли вы, как файловая система хранит метаданные, и связываете ли это с эксплуатацией. Вопрос практический: сервер отказывается создавать файлы, свободное место по отчёту есть, и от ответа зависит, сколько времени займёт разбор инцидента.

Как отвечать

Inode это запись метаданных файла: тип, права, владелец, времена, счётчик жёстких ссылок, размер, карта расположения данных. Имени файла в ней нет, имя живёт в каталоге и ссылается на номер inode. Отсюда два следствия: несколько имён указывают на одну запись, а место освобождается, только когда не осталось ни ссылок, ни открытых дескрипторов.

В ext4 количество записей фиксируется при создании файловой системы и потом не растёт, в XFS они выделяются по мере надобности. Значит, миллионы мелких файлов упираются не в гигабайты, а в счётчик:

df -i
find /var -xdev -printf '%h\n' | sort | uniq -c | sort -n | tail

Симптом исчерпания это отказ записи с сообщением о нехватке места при свободных гигабайтах. Типичные источники: неротируемые логи, кэш сессий, очередь почты, слои контейнеров, каталоги зависимостей. Мониторят всегда пару: занятое место и занятые записи, отдельно по каждой точке монтирования.

Где спотыкаются

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

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

Настраивают оповещение на сервер целиком. Переполняется всегда конкретная файловая система, и порог по корню не заметит забитый раздел с данными контейнеров. Ещё путают следствие: нехватка записей не замедляет систему, она останавливает создание файлов, и сервис падает резко, а не деградирует постепенно.