Если вы давно работаете с Linux, то наверняка хотя бы раз видели странное сообщение: “No space left on device”, хотя команда df -h честно показывает свободное место на диске. Чаще всего в таких ситуациях виноват именно inode. Разбираемся, почему такое происходит.
По промокоду DZEN вы получите скидку на заказ VPS или dedicated от UFO.Hosting. С этим кодом вы сможете запустить свои проекты на надежной и производительной платформе, готовой к любым нагрузкам.
Что такое Inode простыми словами
Проще всего представить inode как паспорт файла. У каждого файла и каталога в файловой системе есть свой уникальный идентификатор — номер inode. Этот номер ведёт к записи со служебной информацией:
- кто владелец файла;
- какие у него права доступа;
- где на диске лежат его данные;
- какой у файла размер;
- когда он был создан, изменен, к нему обращались.
Важно понять одну вещь: имя файла не хранится в inode. Имя хранится в каталоге, который содержит файл, и лишь ссылается на номер inode.
Один и тот же inode может иметь несколько имен (это и есть жёсткие ссылки). А вот один и тот же файл без inode существовать не может.
Как устроена связка «каталог → inode → данные»
Представим, что у вас есть файл /home/user/report.txt. Внутри файловой системы это выглядит так:
1. Каталог /home/user содержит запись:
report.txt → номер inode, допустим 254619.
2. В таблице inode по номеру 254619 находится структура с информацией о файле:
→ тип: обычный файл;
→ владелец: user;
→ права: rw-r--r--;
→ размер: например, 32 КБ;
→ ссылки на блоки данных, где физически лежит содержимое файла;
→ количество ссылок (link count), допустим 1.
Когда программа открывает report.txt, ядро сначала находит inode по имени файла, а уже по inode — реальные данные на диске.
Эта двухступенчатая схема («каталог с именами» → «таблица inode» → «блоки данных») дает файловой системе гибкость: можно менять имя файла, не трогая его содержимое; можно создавать несколько имён, указывающих на один и тот же inode; можно переезжать с одним и тем же файлом между каталогами в пределах одной файловой системы.
Конкретный набор полей в inode зависит от типа файловой системы (ext4, XFS, btrfs и т.д.), но в общих чертах inode содержит:
- тип объекта: обычный файл, каталог, символическая ссылка, устройство, сокет;
- права доступа (rwx для владельца, группы и остальных);
- владельца и группу (UID и GID);
- размер файла;
- набор временных меток (mtime, atime, ctime, иногда и дополнительные);
- количество жёстких ссылок (link count);
- флаги и расширенные атрибуты;
- ссылки на блоки данных (или на другие структуры, через которые эти блоки находятся).
И снова напомним: в inode нет имени. Имя — это отдельная запись в каталоге.
Почему inode могут закончиться раньше, чем место на диске
А теперь вернемся к кейсу из вступления к статье. При создании файловой системы ей заранее выделяется фиксированное количество inode. Каждый файл и каталог получает один inode, независимо от того, сколько данных он занимает.
Если вы создаете очень много мелких файлов (например, логов, временных данных, миниатюр, кэшей), то рано или поздно можете оказаться в ситуации, когда свободное место по объёму ещё есть, а inode уже закончились.
В этот момент любая попытка создать новый файл завершится ошибкой No space left on device, хотя df -h показывает свободные гигабайты. Посмотреть статистику по inodes можно так:
df -i
Вы увидите для каждого раздела:
- общее количество inode;
- сколько уже занято;
- сколько свободно;
- процент использования.
Если число занятых inode близко к 100%, пора разбираться с множеством мелких файлов: чистить временные директории, архивировать или удалять старые данные.
Увеличить количество inode «на живой» файловой системе нельзя. Обычно для этого раздел создают заново, указывая другие параметры при форматировании.
Как inode связаны с производительностью
Хотя inode — это небольшие структуры, они заметно влияют на работу файловой системы. Несколько примеров из практики:
- Миллионы мелких файлов в одном каталоге.
Список inode становится огромным, операции чтения каталога и поиска нужного имени замедляются. Современные файловые системы справляются лучше, чем старые, но проблему это до конца не снимает. - Резервное копирование и сканирование.
Бэкап-системы, антивирусы, индексация — всё это требует обхода дерева файлов и чтения inode. Если их очень много, бэкапы могут работать часами. - Поиск по файловой системе.
Обычная команда find тратит время в основном на то, чтобы обойти все каталоги и прочитать их inode и записи. Поэтому структура каталогов и количество файлов — не менее важный фактор, чем скорость диска.
Понимание того, что inode — это «единица учёта» для файлов, помогает лучше планировать структуру данных: разбивать хранилище на подкаталоги, не складывать всё «в одну корзину», использовать архивы там, где это уместно.
В повседневной работе с Linux можно не думать о inode годами: команды cp, mv, rm и файловые менеджеры отлично справляются сами. Но как только на продакшене появляется что-то необычное — миллион мелких файлов, странные ошибки при записи или непонятное поведение ссылок — именно знание того, что происходит на уровне inode, помогает спокойно и без паники найти причину.
Относиться к inode стоит как к фундаменту. Его не видно, но на нём держится вся файловая система. И чем лучше вы представляете себе этот фундамент, тем увереннее чувствуете себя, когда что-то идёт не по плану.