Что такое inode и почему хостинг их считает

Что такое inode на самом деле

Inode (index node) — это структура метаданных файловой системы, которая существует для каждого файла, директории или символической ссылки на диске. Она не хранит имя файла и не хранит его содержимое напрямую — вместо этого в ней записаны права доступа, идентификатор владельца и группы, время создания, изменения и последнего доступа, размер файла и, что самое важное, указатели на реальные блоки данных на диске, где физически лежит содержимое.

Имя файла, которое видит пользователь в файловом менеджере или в выводе команды ls, хранится отдельно — в записи директории, которая просто сопоставляет текстовое имя с номером конкретного inode. Именно поэтому в Linux у одного файла может быть несколько имён (жёстких ссылок, hard links), указывающих на один и тот же inode и одни и те же данные на диске, — это два разных вопроса: «как называется файл» и «где физически лежат его метаданные и данные».

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

ls -i /var/www/html/index.php
# 1310745 /var/www/html/index.php

Почему число inode фиксировано с момента создания файловой системы

В классических файловых системах Linux, и прежде всего в самой распространённой на серверах ext4, общее число доступных inode на разделе рассчитывается и жёстко резервируется в момент форматирования диска — то есть один раз, когда раздел только создаётся, а не по мере фактического заполнения диска файлами.

Причина такого решения — в самой архитектуре файловой системы: таблица inode физически размещается в отведённой для неё области диска отдельно от области данных, и расширить эту таблицу «на лету» после форматирования без пересоздания всей структуры файловой системы в общем случае невозможно. Это принципиально отличается от того, как многие интуитивно представляют себе диск, — как единый бесконечно делимый объём места, ограниченный только суммарным размером файлов.

mkfs.ext4 -N 5000000 /dev/sdb1

При стандартном форматировании без явного указания флага -N утилита mkfs рассчитывает число inode исходя из предполагаемого среднего размера файла на разделе (обычно порядка 16 килобайт) — это разумное допущение для типичного сервера с документами, изображениями и базами данных, но оно перестаёт работать, когда реальный профиль использования диска сильно отклоняется от этого среднего в сторону множества совсем маленьких файлов.

Симптом: «No space left on device» при видимо свободном месте

Одна из самых обманчивых для новичка ситуаций на Linux-сервере — приложение или сама система выдаёт ошибку записи «No space left on device», хотя команда df -h честно показывает десятки гигабайт свободного пространства на разделе. Разгадка почти всегда одна: закончилось не дисковое пространство, а свободные inode — то есть система физически не может создать ни одной новой учётной записи файла, даже если для его содержимого есть сколько угодно места в области данных.

Проверяется это отдельной командой df с флагом -i, которая показывает занятость именно inode, а не блоков данных, — по формату вывод очень похож на обычный df -h, но колонки означают количество занятых и свободных inode, а не занятых и свободных мегабайт.

df -i
# Filesystem      Inodes  IUsed    IFree IUse% Mounted on
# /dev/vda1      2621440 2621440       0  100% /

Именно рассинхронизация между этими двумя показателями — почти пустой df -h и почти полный df -i — является однозначным диагностическим признаком именно исчерпания inode, а не банальной нехватки места на диске, и требует принципиально другого решения: не расширения диска, а поиска и удаления избыточного количества мелких файлов или пересоздания раздела с изначально большим числом inode.

Частые реальные причины исчерпания inode

Миллионы файлов сессий PHP, которые копятся в стандартной директории /var/lib/php/sessions или аналогичной, если на сервере не настроена сборка мусора сессий (session garbage collection) или она настроена с слишком большим временем жизни, — каждая активная сессия посетителя сайта создаёт отдельный крошечный файл, а при высокой посещаемости и без своевременной очистки таких файлов накапливаются миллионы за считаные недели.

Бесконтрольно растущая директория кэша приложения или CMS — многие системы кэширования на файловой системе (в отличие от кэширования в Redis или Memcached) создают отдельный файл на каждый закэшированный фрагмент страницы, запрос к базе данных или объект, и без настроенного автоматического устаревания (TTL) и периодической очистки эта директория со временем превращается в миллионы мелких файлов.

Незакрытая или зависшая очередь почтового сервера — если исходящая почта с сервера по какой-то причине не может быть доставлена (заблокирован SMTP-порт, неверные DNS-записи, отклонение принимающим сервером), сообщения накапливаются в директории очереди Postfix или Exim, и при большом объёме рассылки эта очередь легко превращается в существенную долю всех использованных inode на разделе.

Директория node_modules в проектах на Node.js — характерная особенность экосистемы npm в том, что даже небольшой проект способен затянуть за собой десятки тысяч файлов зависимостей, многие из которых крошечного размера сами по себе, но каждый занимает отдельный inode; на серверах, где одновременно разворачивается несколько таких проектов без очистки старых сборок, это одна из самых частых практических причин исчерпания inode на разделе с приложениями.

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

Как найти, что именно расходует inode

Первый практический шаг после того, как df -i подтвердил исчерпание inode, — найти директорию, где сосредоточено аномально большое число файлов. Команда du считает объём в байтах, а не число файлов, поэтому для этой задачи не подходит напрямую — вместо неё используется связка find с подсчётом количества файлов в каждой директории верхнего уровня.

for d in /var/*/; do echo -n "$d: "; find "$d" -xdev | wc -l; done | sort -t: -k2 -n -r | head -10

Флаг -xdev важен, если поиск ведётся от корня файловой системы или от точки монтирования, объединяющей несколько разных разделов, — он не даёт команде find уходить в примонтированные отдельные файловые системы и искажать подсчёт файлами с другого физического раздела, у которого свой отдельный запас inode.

После того как найдена конкретная директория-виновник, для более детального анализа полезна утилита ncdu — интерактивный аналог du с постраничной навигацией, — хотя по умолчанию она тоже считает размер, а не число файлов; для чистого подсчёта количества файлов в конкретной уже найденной директории быстрее и нагляднее прямой find с подсчётом строк.

find /var/www/example.ru/cache -type f | wc -l

Определив источник, дальнейшие действия зависят от его природы: для директории сессий или кэша — настроить корректную сборку мусора и TTL средствами самого приложения; для почтовой очереди — разобраться, почему письма не доставляются, вместо того чтобы просто чистить очередь вручную, теряя сообщения; для node_modules старых сборок — удалить неиспользуемые версии проекта после успешного деплоя новой.

Пример практической очистки: старые файлы сессий PHP

Если диагностика показала, что именно директория сессий PHP занимает основную массу использованных inode, а встроенная сборка мусора PHP по какой-то причине не отрабатывает штатно (например, из-за нестандартного пути хранения сессий, не отслеживаемого механизмом session.gc), можно вручную удалить файлы сессий старше определённого возраста как разовую меру.

find /var/lib/php/sessions -type f -mtime +1 -delete

Разовая очистка решает симптом, но не причину — куда правильнее проверить и, если нужно, скорректировать параметры session.gc_probability, session.gc_divisor и session.gc_maxlifetime в конфигурации PHP, отвечающие за то, как часто и по каким критериям сама PHP-FPM удаляет устаревшие файлы сессий автоматически, без ручного вмешательства администратора.

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

Проверка параметров файловой системы: tune2fs и запас на будущее

Для файловых систем ext4 узнать точное общее число inode, уже использованное количество и резерв, заложенный при форматировании, можно без монтирования специальных инструментов — командой tune2fs с флагом -l, показывающей полный набор параметров суперблока конкретного раздела.

tune2fs -l /dev/vda1 | grep -i inode
# Inode count:              2621440
# Free inodes:              1842103
# Inodes per group:         8192

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

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

Как избежать проблемы заранее при проектировании сервера

Если заранее известно, что проект будет активно генерировать множество мелких файлов — например, файловый кэш высоконагруженного сайта, обработка миллионов пользовательских загрузок небольшого размера или интенсивная работа очереди задач с файловыми артефактами, — разумно заранее отформатировать раздел под данные с явно увеличенным числом inode через флаг -N команды mkfs, а не полагаться на автоматический расчёт по умолчанию.

Альтернативный архитектурный подход — вынести особенно «прожорливые» по числу файлов данные (кэш, сессии, временные файлы) в отдельное хранилище, изначально не завязанное на лимит inode обычной файловой системы, — например, в Redis для сессий и кэша вместо файловой системы, что заодно и быстрее по производительности, и полностью снимает вопрос об исчерпании inode для этого конкретного типа данных.

Для проектов, где объективно ожидается огромное число небольших файлов и файловая система обязана оставаться классической (например, для хранения пользовательских аватаров или вложений), стоит рассмотреть файловые системы, не имеющие фиксированного заранее числа inode, вроде XFS в режиме динамического выделения или Btrfs, — но переход на них требует отдельного тестирования конкретной нагрузки и не всегда оправдан ради решения одной узкой проблемы.

Регулярный мониторинг занятости inode наравне с обычным местом на диске — простая профилактическая мера, полностью аналогичная привычному контролю df -h, разобранному в статье о базовом мониторинге сервера, только с добавлением флага -i в тот же скрипт или ту же команду, выполняемую по расписанию.

Типичные ошибки при работе с inode

Попытка «почистить диск», удаляя крупные файлы, когда на самом деле закончились именно inode, — удаление одного большого видеофайла освобождает много места, но всего один inode, тогда как для реального решения проблемы нужно удалить множество мелких файлов, а не искать самые тяжёлые.

Расширение диска (увеличение размера раздела) как попытка решить проблему исчерпания inode — простое увеличение объёма существующего раздела без его пересоздания в большинстве случаев не увеличивает автоматически число inode, зарезервированное при первоначальном форматировании, и проблема воспроизведётся снова при том же характере нагрузки.

Игнорирование предупреждающих признаков в логах приложений о невозможности создать временный файл или файл сессии, списываемых на случайный сетевой сбой, — часто это ранний сигнал приближающегося исчерпания inode, который стоит проверить командой df -i сразу, а не откладывать разбирательство до полного отказа записи на диск.

Форматирование нового раздела под задачу с заведомо мелкими файлами без явного увеличения числа inode через флаг -N — если заранее известно, что будущая нагрузка нетипична (миллионы мелких файлов при небольшом суммарном объёме данных), закладывать больший запас inode стоит на этапе создания раздела, а не после того, как проблема уже проявилась на реальных данных.

Чек-лист диагностики проблем с inode

Шаг 1. При ошибке «No space left on device» сразу проверьте оба показателя — df -h для места и df -i для inode, — чтобы точно понять природу проблемы, прежде чем предпринимать какие-либо действия.

Шаг 2. Если виноваты именно inode, найдите директорию-источник через подсчёт числа файлов (find с wc -l), а не через подсчёт размера (du), поскольку это разные метрики и один не заменяет другой.

Шаг 3. Разберитесь с первопричиной накопления файлов — незавершённая сборка мусора сессий, неограниченный кэш, зависшая почтовая очередь или забытые артефакты сборки — вместо разовой ручной очистки без понимания причины.

Шаг 4. Настройте автоматическую регулярную очистку через cron или встроенные механизмы приложения там, где это применимо, чтобы проблема не повторилась через несколько недель в том же виде.

Шаг 5. Для новых разделов под нагрузку с заведомо мелкими файлами закладывайте увеличенное число inode при форматировании через флаг -N, а не полагайтесь на автоматический расчёт по умолчанию.

Шаг 6. Добавьте проверку df -i в тот же скрипт мониторинга, что уже проверяет свободное место на диске, чтобы получать предупреждение заранее, а не по факту отказа записи на сервере.

Итог: невидимый лимит, о котором вспоминают слишком поздно

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

Практическая привычка — проверять df -i так же регулярно, как df -h, особенно на серверах, обслуживающих активные сайты с сессиями, кэшем и загрузкой пользовательских файлов, где риск незаметного накопления миллионов мелких файлов заметно выше, чем на статичном сервере с редко меняющимся набором данных.

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