Закончились inode: место на диске есть, а файлы не создаются — причины и решение

Владельцы сайтов иногда сталкиваются со странной ситуацией: в панели хостинга занято меньше половины диска, но сайт не может загрузить новое изображение, WordPress не обновляет плагины, а в почтовый ящик перестают приходить письма. В логах при этом видно «No space left on device» или «Disk quota exceeded». Проблема в таком случае не в объёме данных, а в количестве файлов. Каждый файл и каждая папка занимают в файловой системе один inode, и на хостинге обычно ограничен не только объём диска, но и число inode.

Что такое inode и почему он заканчивается отдельно

Inode — это служебная запись файловой системы, в которой хранится информация о файле: владелец, права доступа, размер и расположение данных на диске. Неважно, большой файл или маленький, он всегда занимает ровно один inode. Видеоролик на 2 ГБ использует один inode, а сто тысяч файлов кеша по 1 КБ — сто тысяч inode, хотя вместе они весят всего около 100 МБ. Поэтому вполне возможно упереться в лимит количества файлов, когда диск почти свободен.

Когда лимит исчерпан, система просто отказывает в создании новых файлов. Последствия видны сразу в нескольких местах: PHP не может записать файл сессии, и пользователи не могут войти в личный кабинет; плагин кеширования не сохраняет новые страницы; не работает загрузка изображений; входящие письма не сохраняются. Снаружи кажется, что сайт «сломался», хотя на деле в одной папке просто скопилась масса ненужных файлов.

Как убедиться, что дело именно в inode

Сначала посмотрите статистику в панели хостинга. В ISPmanager в разделе ресурсов пользователя рядом с объёмом диска показывается и количество файлов с лимитом. Если объём небольшой, а число файлов близко к пределу, диагноз ясен. Клиенты sayt.uz открывают панель хостинга прямо из личного кабинета, без отдельного ввода логина.

Если на хостинге доступен SSH, подсчитать всё можно в терминале. Команда ниже покажет общее число файлов и папок в домашнем каталоге:

find ~ -xdev | wc -l

На виртуальном хостинге команда df -i часто выводит данные по всему серверу, а не вашу личную квоту, так что полагаться на неё не стоит. Личный лимит точнее показывает панель или команда quota -s, если сервер её разрешает.

Ищем папку, где скопились файлы

Следующий шаг — найти виновника. Команда du из GNU coreutils умеет считать не объём, а количество inode. Так можно вывести 20 каталогов с наибольшим числом файлов:

du --inodes -x -d 3 ~ 2>/dev/null | sort -n | tail -20

Если сервер старый и параметр --inodes не поддерживается, то же самое делается через find:

for d in ~/*/ ~/www/*/*/; do
  printf '%s %s\n' "$(find "$d" -xdev | wc -l)" "$d"
done | sort -n | tail -20

Обычно одна-две папки резко выделяются в верхней части списка. На практике чаще всего виноваты: каталог wp-content/cache плагинов кеширования WordPress, папка tmp с файлами PHP-сессий, почтовые ящики, которые годами не чистились, распакованные и забытые архивы резервных копий, а также целиком залитые на сервер node_modules или vendor.

Пример: интернет-магазин в Ташкенте

Допустим, магазин одежды на misol.uz работает на WooCommerce. Однажды утром владелец замечает, что не может загрузить фотографии товаров, а покупатели жалуются, что товар не добавляется в корзину. В панели занято 40 процентов диска, но счётчик файлов на пределе. du --inodes показывает, что в wp-content/cache несколько сотен тысяч файлов: плагин кеширования сохранял отдельную страницу для каждой комбинации фильтров по цвету и размеру. Такой «взрыв кеша» в каталогах с фильтрами встречается часто.

Решение заняло два шага. Сначала в настройках плагина нажали «Очистить кеш», но из-за огромного количества файлов плагин упёрся в лимит времени выполнения и остановился. Тогда папку кеша очистили через SSH, а в настройках плагина отключили кеширование URL с параметрами фильтров. Через несколько минут сайт заработал как обычно.

Безопасные команды для очистки

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

cd ~/www/misol.uz/wp-content/cache
find . -type f -delete

Файлы PHP-сессий обычно начинаются с sess_. Удаление сессий старше двух дней не затронет активных пользователей:

find ~/tmp -type f -name 'sess_*' -mtime +2 -delete

В папке с огромным числом файлов команда rm -rf * может выдать ошибку «Argument list too long», потому что оболочка пытается развернуть все имена в одну строку. find ... -delete этой проблемы не имеет и надёжнее при массовой очистке. Если SSH нет, папку можно удалить через файловый менеджер ISPmanager, но при сотнях тысяч файлов это медленно и может прерваться по таймауту.

Почтовые ящики тоже расходуют inode

На серверах почта обычно хранится в формате Maildir, где каждое письмо — отдельный файл. Ящик, в котором годами копились рассылки, уведомления и спам, может занимать десятки тысяч inode. Здесь помогает архивирование старых писем в почтовом клиенте и очистка папок «Спам» и «Корзина».

Как не допустить повторения

Мало один раз всё почистить, нужно устранить причину. В плагине кеширования ограничьте срок жизни кеша и включите автоматическую очистку. Для регулярного удаления старых сессий в панели можно добавить ежедневное задание cron:

0 4 * * * find $HOME/tmp -type f -name 'sess_*' -mtime +2 -delete

В проектах на Composer или npm устанавливайте зависимости на сервере, но не храните лишние каталоги, оставшиеся после сборки. Не распаковывайте резервные копии внутри сайта: держите их в виде архива или выносите за пределы хостинга. Если сайт по своей природе работает с огромным количеством файлов, например большая фотогалерея или файлообменник, стоит подумать о тарифе с более высоким лимитом или о VPS. Конкретные лимиты и подбор тарифа можно уточнить в кабинете sayt.uz или через техническую поддержку.