В файловых системах семейства Unix inode представляет собой структуру с метаданными файлового объекта. В ней хранится служебная информация, необходимая файловой системе: права доступа, владелец, временные метки, ссылки на данные и другие сведения.
Имя файла при этом не является самим inode. Каталог связывает имя с соответствующим объектом файловой системы.
Для обычного владельца сайта необязательно разбираться во внутреннем устройстве ext4 или другой файловой системы. В контексте тарифа хостинга полезнее запомнить практический смысл: провайдер может ограничивать не только общий объем данных, но и количество файлов и каталогов, которое разрешено хранить в аккаунте.
Причем терминология у хостеров отличается. Где-то в панели действительно показывают inode. Где-то пишут «файлы», «количество файлов» или «файловые объекты». Эти показатели не всегда технически тождественны во всех реализациях, поэтому ориентироваться нужно на правила конкретного провайдера.
Сам факт ограничения количества файлов вполне реален. Например, у бесплатного хостинга Beget на момент проверки одновременно указаны 1 ГБ дискового пространства и отдельный предел в 25 000 файлов. То есть объем и количество являются двумя самостоятельными ограничениями тарифа. citeturn0search3turn0search13
Именно поэтому фраза «у меня еще половина диска свободна» не всегда означает, что аккаунт может бесконечно создавать новые файлы.
Почему миллион маленьких файлов не равен одному большому
Допустим, у нас есть архив размером 1 ГБ.
Для очень грубого примера представим, что он хранится как один обычный файл. С точки зрения количества файлов это один объект.
Теперь возьмем тот же гигабайт данных и разобьем его на 500 000 маленьких файлов. Общий объем может остаться примерно тем же, но файловая система и инфраструктура хостинга уже работают с огромным количеством отдельных объектов.
Каждый из них нужно учитывать. Каталоги нужно обходить. Резервной системе приходится обрабатывать множество имен и метаданных. Антивирусным и служебным процессам приходится работать с большим деревом файлов. Даже обычный файловый менеджер может заметно медленнее открывать каталог, в котором лежат десятки тысяч элементов.
Поэтому провайдеру важно не только сколько байтов занял клиент.
Хороший пример можно увидеть даже в рекомендациях самих хостеров. Timeweb предупреждает, что встроенный файловый менеджер не предназначен для работы с большими объемами данных и для крупных операций рекомендует SSH или FTP. Это не про inode напрямую, но хорошо показывает, что количество и организация файлов влияют на удобство и стоимость операций с ними. citeturn0search6
Именно здесь возникает парадокс, который удивляет владельцев сайтов.
Аккаунт А: один архив на 10 ГБ.
Аккаунт Б: 300 000 файлов общим объемом всего 3 ГБ.
По диску первый аккаунт тяжелее более чем втрое. Но если тариф ограничивает количество файлов, именно второй способен первым упереться в этот предел.
Откуда на обычном WordPress берутся сотни тысяч файлов
Свежая установка WordPress не должна сама по себе пугать огромным количеством файлов. Проблема обычно накапливается со временем и почти всегда имеет конкретный источник.
Один из самых распространенных кандидатов это кэш.
Страничный кэш ускоряет сайт, сохраняя готовые результаты, чтобы WordPress не собирал страницу с нуля при каждом посещении. Это полезный механизм. Но некоторые конфигурации способны создавать очень большое количество кэш-файлов, особенно если сайт имеет множество URL, языковых версий, вариантов страниц или неправильные правила очистки.
Кэш не нужно отключать только из страха перед количеством файлов. Официальная документация WordPress, наоборот, называет кэширование одним из основных способов повышения производительности. Проблемой является не сам кэш, а его бесконтрольное накопление. citeturn0search8
Второй источник часто находится в wp-content/uploads.
Когда вы загружаете одну фотографию, WordPress и тема могут создать несколько дополнительных размеров изображения. Это нормально: браузеру не обязательно отдавать огромный оригинал там, где нужна маленькая миниатюра.
Но если медиатека содержит десятки тысяч изображений, а тема и плагины зарегистрировали множество размеров, итоговое число файлов становится значительно больше количества фотографий, которое видит владелец в библиотеке.
Третий кандидат это резервные копии.
Особенно забавно выглядит ситуация, когда плагин ежедневно создает новый бэкап сайта и складывает его внутрь того же хостинг-аккаунта. Владелец уверен, что заботится о надежности, а через несколько месяцев обнаруживает десятки или сотни старых копий.
Если каждая копия представляет собой один архив, она быстрее съедает гигабайты, чем лимит файлов. Но некоторые системы резервирования используют наборы из множества частей, временные каталоги и служебные файлы. Кроме того, старые незавершенные задания могут оставлять мусор.
Есть еще миниатюры, временные файлы, логи, сессии, каталоги обновлений, файлы безопасности, staging-копии сайта и остатки удаленных расширений.
Наконец, нельзя забывать про почту, если она хранится в том же аккаунте и учитывается в квоте провайдера. Почтовый ящик с десятками тысяч сообщений способен означать очень большое количество отдельных объектов, хотя визуально пользователь видит всего одну папку «Входящие».
Как понять, что проблема именно в количестве файлов
Сначала не удаляйте ничего.
Это звучит слишком очевидно, но именно после сообщения о превышении лимита люди иногда открывают файловый менеджер и начинают стирать каталоги с непонятными названиями. Среди них легко оказывается не мусор, а часть CMS, тема, загрузки или данные работающего плагина.
Первым делом откройте панель хостинга и посмотрите статистику ресурсов. Нас интересуют две разные вещи: занятое дисковое пространство и количество файлов или inode, если провайдер отображает такой показатель.
Если счетчик файлов достиг лимита, причина найдена хотя бы на первом уровне.
Дальше нужно определить, где находятся эти файлы.
При наличии SSH количество файлов в конкретном дереве можно оценить стандартными инструментами Linux. Например, для подсчета обычных файлов в текущем каталоге и его подкаталогах часто используют:
find . -type f | wc -lКоманду нужно запускать осознанно в нужной директории. На огромном дереве обход сам по себе может занять время и создать дополнительную дисковую нагрузку.
Для поиска крупных каталогов по занимаемому месту полезны du и интерактивная утилита ncdu. Timeweb, например, рекомендует ncdu для подробного анализа дискового пространства аккаунта через SSH. Но здесь есть важное различие: большой каталог по гигабайтам не обязательно является лидером по числу файлов. citeturn0search9
Поэтому искать нужно в двух измерениях.
Каталог с видео может занимать 15 ГБ и содержать 40 файлов. Каталог кэша может весить 900 МБ и содержать 180 000 файлов. Если проблема в лимите файлов, второй для нас намного интереснее.
Что можно удалить, а к чему лучше не прикасаться
Самый безопасный кандидат на очистку это данные, которые точно являются восстанавливаемым кэшем и которые разрешено удалять документацией конкретного плагина.
Лучше очищать такой кэш штатной кнопкой самого расширения или панели хостинга. Так меньше вероятность удалить не тот каталог.
Следом проверьте старые локальные резервные копии. Если у вас лежат копии за каждый день последних двух лет, подумайте, действительно ли все они нужны.
Но перед удалением убедитесь, что рабочие резервные копии существуют в другом месте и их можно восстановить. Бэкап, который лежит только рядом с оригинальным сайтом, плохо защищает от потери всего аккаунта.
С изображениями сложнее.
Нельзя просто открыть uploads и удалить все файлы с размерами в имени. WordPress, тема или страницы сайта могут ссылаться именно на эти миниатюры. После такой «оптимизации» часть изображений исчезнет или будет генерироваться заново.
Сначала выясните, какие размеры действительно используются. Для массовой регенерации или удаления старых размеров существуют специальные инструменты, но на рабочем сайте такие операции лучше выполнять после резервного копирования.
Не стоит вручную чистить wp-admin, wp-includes и случайные каталоги плагинов ради экономии inode. Несколько тысяч системных файлов WordPress редко являются тем местом, где внезапно выросли дополнительные 200 000 объектов.
Гораздо подозрительнее каталог, который должен быть временным, но продолжает расти каждый день.
Переход на более дорогой тариф не всегда лечит причину
Допустим, вы нашли 250 000 файлов кэша и почти достигли ограничения тарифа.
Можно перейти на план, разрешающий больше файлов.
Через несколько месяцев проблема повторится, если кэш продолжает расти без очистки.
Это тот же принцип, что и с дисковым пространством. Если лог-файл из-за ошибки прибавляет 5 ГБ каждую неделю, покупка еще 50 ГБ диска только переносит дату следующего аварийного сообщения.
Сначала найдите источник роста.
Полезно сравнить количество файлов сегодня и через несколько дней. Если оно увеличивается на десятки тысяч без публикации нового контента, значит на сайте работает процесс, который стоит исследовать.
Для большого интернет-магазина или сервиса огромное количество файлов может быть совершенно естественным. Тогда увеличение лимита, другой тариф, VPS или перенос части данных в объектное хранилище действительно становятся архитектурным решением.
Например, S3-совместимое объектное хранилище предназначено для работы с объектами и может использоваться для архивов, резервных копий, медиа и других данных. У Beget среди сценариев S3 прямо указано длительное хранение резервных копий и архивов, причем для объектов действуют собственные правила и ограничения, отличные от файловой квоты обычного хостинга. citeturn0search14
Но переносить медиатеку небольшого блога в S3 только потому, что в интернете посоветовали «бороться с inode», тоже необязательно.
На лимит файлов стоит смотреть еще до покупки хостинга
Большинство людей сравнивают тарифы примерно так: 20 ГБ против 30 ГБ, два сайта против десяти, одна база против нескольких, столько-то CPU.
Если ваш проект состоит из обычного небольшого сайта, ограничение количества файлов может никогда не стать заметным.
Но есть проекты, для которых этот параметр важен с самого начала.
Большая фотогалерея. Интернет-магазин с десятками тысяч товаров и множеством изображений. Несколько WordPress-сайтов в одном аккаунте. Огромная почта. Система, генерирующая множество мелких файлов. Хранение локальных копий и архивов.
В этих случаях имеет смысл спросить хостера о лимите файлов до оплаты тарифа, даже если на странице с ценами он не вынесен крупным шрифтом.
Заодно стоит уточнить, что именно учитывается: файлы сайтов, каталоги, почта, служебные данные, резервные копии провайдера. Правила разных платформ могут отличаться.
Не нужно автоматически выбирать тариф с максимальным числом inode. Этот показатель имеет смысл только вместе с остальными ресурсами.
Хостинг может разрешать огромное количество файлов, но быть слишком слабым по CPU для вашего магазина. Или предлагать много гигабайт, но ограничивать процессы и нагрузку на базу. Например, Timeweb в актуальных правилах виртуального хостинга отдельно перечисляет ограничения на процессы, CPU, MySQL и PHP, что хорошо показывает: реальная емкость тарифа никогда не определяется одной цифрой. citeturn0search1
Если лимит уже достигнут, действуйте в таком порядке
Не покупайте новый тариф в первые пять минут и не удаляйте случайные файлы.
Сначала подтвердите в панели или у поддержки, какое именно ограничение достигнуто. Свободные гигабайты не исключают лимит по количеству объектов.
Затем найдите каталоги с наибольшим количеством файлов. Отдельно посмотрите кэш, загрузки WordPress, резервные копии, временные каталоги и почту.
Определите источник роста. Если сегодня в каталоге 80 000 файлов, а завтра 120 000, простая очистка даст только временный эффект.
Удаляйте только то, назначение чего понятно. Кэш лучше очищать штатным способом. Перед операциями с медиатекой и резервными копиями убедитесь, что данные можно восстановить.
После очистки проверьте работу сайта, административной панели, загрузку изображений, формы и фоновые задания.
И только после этого решайте, нужен ли тариф с большим лимитом или другая архитектура хранения.
Иногда проблема решается одной неправильной настройкой кэша. Иногда сайт действительно вырос из виртуального хостинга.
Но главное здесь другое.
Дисковое пространство и количество файлов это не одно и то же. На сервере могут оставаться десятки свободных гигабайт, а аккаунт уже не сможет нормально создавать новые объекты из-за другого ограничения.
Поэтому при следующем сравнении тарифов смотрите не только на красивую цифру «50 ГБ NVMe».
Иногда значительно важнее маленькая строчка, которую до первой проблемы почти никто не замечает.
