MAATRIX / Блог / Не хватает inode при свободном месте

Не хватает inode при свободном месте

Не хватает inode при свободном месте

MAATRIX

Система отказывается создавать файлы с ошибкой No space left on device, а df -h показывает, что диск занят наполовину. Парадокс объясняется просто: закончилось место не на диске, а в таблице inode. Каждый файл, каким бы маленьким он ни был, занимает один inode, и когда их число исчерпано, писать нельзя, даже если гигабайты свободны. Ниже пошаговое решение проблемы — как проверить нехватку inode, найти каталоги с миллионами мелких файлов и освободить ресурс.

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Быстрая проверка: подтверждаем, что дело в inode

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

# свободное место в гигабайтах
df -h
# использование inode — вот здесь ключ
df -i

Если в выводе df -i какой-то раздел показывает IUse% 100%, а df -h при этом далёк от заполнения — диагноз подтверждён: место есть, а inode кончились. Именно поэтому система выдаёт No space left on device, хотя визуально диск полупустой: с точки зрения ядра «места» нет, потому что негде зарегистрировать новый файл. Теперь задача — найти, кто израсходовал все inode, и это почти всегда каталог с гигантским числом мелких файлов.

Что такое inode и почему они кончаются

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

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

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Заказать VPS с большим диском

Находим каталог-виновник

Ключевой навык здесь — считать не размер, а количество файлов в каталогах. Обычные инструменты вроде du меряют объём и виновника не покажут. Нужно посчитать файлы по каталогам и найти лидера:

# сколько файлов в каждом подкаталоге текущей директории
for d in */; do echo "$(find "$d" -xdev | wc -l) $d"; done | sort -rn | head
# то же от корня по крупным зонам
for d in /var /home /tmp; do echo "$d: $(find $d -xdev | wc -l)"; done

Начинайте с типичных мест: /var (логи, кэши, почта, спул), /tmp, домашние каталоги, папки приложений. Команда с find ... | wc -l покажет, где скопились миллионы объектов. Часто виновник обнаруживается мгновенно — какой-нибудь каталог кэша или сессий с сотнями тысяч файлов. Двигайтесь вглубь: нашли подозрительный каталог верхнего уровня — повторите подсчёт внутри него, пока не упрётесь в конкретную папку, забитую мелочью.

Обратите внимание на флаг -xdev в командах: он не даёт find уходить на другие смонтированные файловые системы. Это важно, потому что inode считаются отдельно для каждого раздела, и смешивать их подсчёт нельзя — иначе вы будете искать виновника не на том разделе, что переполнен. Сначала по выводу df -i определите, какой именно раздел показывает сто процентов использования, и обследуйте только его. На типовом VPS обычно всё лежит на одном корневом разделе, и разница незаметна, но на серверах с отдельными разделами под данные или логи эта деталь экономит время и уберегает от ложного следа.

Освобождаем inode

Нашли каталог — удаляем лишнее. Здесь есть техническая тонкость: если файлов реально миллионы, обычный rm * упадёт с ошибкой «слишком длинный список аргументов», а rm -rf может работать очень долго. Надёжнее удалять через find с батчами:

# безопасно удалить старые файлы из каталога кэша/сессий
find /var/lib/php/sessions -type f -mtime +2 -delete
# для гигантских каталогов — удаление пачками, чтобы не упереться в лимит аргументов
find /path/to/huge -type f -print0 | xargs -0 -n 1000 rm -f

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

Устраняем причину, а не симптом

Разовая чистка вернёт работоспособность, но если ничего не менять, inode кончатся снова. Найдите, что плодит файлы. Частые причины: PHP-сессии без сборки мусора (растут бесконечно), приложение, кэширующее каждый запрос отдельным файлом без ротации, почтовый спул при проблемах с доставкой, отладочное логирование, создающее файл на событие.

По каждому источнику есть решение. Для сессий — включить и настроить сборщик мусора, чтобы старые удалялись автоматически, или перенести сессии в Redis, где они не занимают inode на диске. Для кэшей — настроить лимит и ротацию либо перевести кэш в память. Для логов — ротацию через logrotate. Для почты — разобраться, почему письма застревают в очереди. Устранив источник, вы превращаете периодическую аварию в разовое воспоминание.

Когда inode мало из-за разметки

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

Радикальное решение — пересоздать файловую систему с большим числом inode (параметр задаётся при форматировании), но это требует переноса данных и потому применяется при плановой перестройке. Практичнее для проектов с миллионами мелких файлов — сразу закладывать подходящую конфигурацию диска и достаточный запас. У MAATRIX VPS и выделенные серверы в локациях RU, US и UK дают полный контроль над разметкой и щедрый диск, с оплатой из России картой или криптой. Когда объём и структура диска подобраны под задачу, ни место, ни inode не становятся неожиданным потолком.

Нужен сервер под эту задачу?

Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK, США и РФ. Оплата картой РФ и по СБП.

Заказать VPS с большим диском

Обсудить статью, задать вопрос или начать новую тему

Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.

Перейти в сообщество →

Частые вопросы

Почему No space left, если df -h показывает свободное место?

Кончились не гигабайты, а inode — записи в таблице файловой системы, по одной на каждый файл. Проверьте df -i: если IUse% равен 100%, дело в числе файлов, а не в объёме данных.

Как найти, что израсходовало inode?

Считайте не размер, а количество файлов по каталогам: find каталог -xdev | wc -l для подозрительных папок. Ищите в /var, /tmp, кэшах и сессиях. Виновник — каталог с сотнями тысяч или миллионами мелких файлов.

Как удалить миллионы файлов, если rm не справляется?

Через find с удалением пачками: find /path -type f -print0 | xargs -0 -n 1000 rm -f. Обычный rm * падает на слишком длинном списке аргументов, а find -delete работает надёжно.

Как предотвратить повторную нехватку inode?

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

Нужны сами нейросети для контента?

Генерируйте изображения, видео и озвучку нейросетями на falapi.io — десятки моделей в одном окне. Оплата картой РФ и по СБП.