Индексный дескриптор

В информатике инодом (или индексным дескриптором) (произносится айнод или инод) называют структуру данных в традиционных файловых системах Unix, таких как UFS. Инод хранит основную информацию о постоянных файлах, каталогах или других объектах файловой системы.

Подробности

При создании файловой системы создаются также и структуры данных, содержащие информацию о файлах. Каждый файл имеет свой инод, идентифицируемый по номеру инода (часто называемый 'i-номером' или 'инодом'), в файловой системе, в которой располагается сам файл.

Иноды хранят информацию о файлах, такую как принадлежность владельцу (пользователю и группе), режим доступа (чтение, запись, запуск на выполнение) и тип файла. Существует определенное число инодов, которое указывает максимальное количество файлов, допускаемое определенной файловой системой. Обычно, при создании файловой системы примерно 1% ее выделяется под иноды.

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

• Номер инода заносится в таблицу инодов в определенном месте устройства; по номеру инода ядро системы может считать содержимое инода, включая указатели данных и прочий контент файла.
• Номер инода файла можно посмотреть используя команду ls -i, а команда ls -l покажет информацию, хранящуюся в иноде.
• Файловые системы, не относящиеся к традиционным ФС UNIX, такие как stat - системным вызовом, поставляющим информацию программам.

Имена файлов и содержимое каталогов

• Иноды не хранят имена файлов, только информацию об их содержимом.
• Каталоги в Unix являются списками 'ссылочных' структур, каждая из которых содержит одно имя файла и один номер инода.
• Ядро должно просматривать каталог в поисках имени файла, затем конвертировать это имя в соответствующий номер инода, в случае успеха.

Представление ядром этих данных в памяти называется struct inode (структурным инодом) (в ОС BSD система использует терм vnode, буква v в котором указывает на виртуальную файловую систему уровня ядра.

Описание инода в POSIX

Стандарты Unix. Постоянные файлы должны иметь следующие атрибуты:

• Длина файла в байтах.
• ID устройства (это идентифицирует устройство, содержащее файл).
• ID пользователя, являющегося владельцем файла.
• ID группы файла.
• Режим файла, определяющий какие пользователи могут считывать, записывать и запускать файл.
• ctime, change time), последней модификации содержимого файла (mtime, modification time), и последнего доступа (atime, access time).
• Счетчик ссылок указывают количество жестких ссылок, указывающих на инод.
• Указатели на блоки диска, хранящие содержимое файла (смотри структура указателя в иноде).

Системный вызов stat считывает номер инода файла и некоторую информацию из инода.

Происхождение слова

Точная причина использования "и" в узлах (нодах) неизвестна. В ответ на вопрос об этом один из пионеров Unix-систем Деннис Ритчи ответил:

Честно говоря, я мало об этом знаю. Это был всего лишь термин, который мы начали использовать. 'Индекс', как я полагаю, использовался из-за несколько необычной структуры файловой системы, хранившая информацию о доступе к файлам в плоском (двумерном) массиве на диске, а вся информация об иерархии каталогов хранилась отдельно. Таким образом, и-номер являлся индексом в этом массиве, и-нод - выбранным элементом массива. (Приставка 'и-' использовалась в первой версии руководства; со временем дефис перестали употреблять).

Т.е. index node (индексный узел, элемент) → index-node → i-node → inode — постепенное укорочение и слияние словосочетания index node. По другой версии, начальная буква i в i-node происходит от слова information (информация).

Значение

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

• Если несколько имен указывают на один и тот же инод (жесткие ссылки), то все имена считаются эквивалентными. Первое созданное имя никаким особым положением не обладает. Это отличается от поведения похожих символьных ссылок, которые зависят от первоначального имени.
• Инод может совсем не иметь ссылок. Обычно такой файл должен быть удален с диска (именно поэтому программы типа undelete в Unix не позволяют установить точное имя удалённого файла), а его ресурсы должны освободиться (это нормальный процесс удаления файла), но если какие-либо процессы держат файл открытым, то они могут удерживать доступ к нему, а файл будет окончательно удален только когда будет закрыто последнее обращение к нему. Это относится и к исполнимым копиям, которые удерживаются открытыми процессами, их выполняющими. По этой причине, при обновлении программы рекомендуется удалять старую копию и создавать новый инод для обновленной версии, чтобы никакие экземпляры старой версии не продолжали выполняться.
• Обычно нет возможности сопоставить открытый файл и имя, по которому он был открыт. Операционная система преобразует имя файла в номер инода при первом же удобном случае, а затем "забывает" про имя файла. Таким образом, функции библиотек getwd() начинают искать в родительском каталоге файл с инодом, совпадающим с файлом "." каталога, затем ищут родительский каталог для текущего, и так далее пока не достигнут "/" каталога. SVR4 и
• Ранее было возможно применять жесткие ссылки на каталоги. Это делало структуру каталогов ориентированным графом вместо дерева, т.е. связного графа с N-1 ребрами и N узлами. Например, каталог имел возможность быть собственным родителем. Современные системы не допускают подобных двусмысленностей, за исключением корневого каталога, который считается собственным родителем.
• Номер инода файла остается неизменным при перемещении файла в другой каталог на том же устройстве или при дефрагментации диска. Поэтому, перемещение или каталога, содержащего файл, или его содержимого (или и того и другого вместе) недостаточно для предотвращения доступа к нему запущенного процесса, если у процесса есть возможность вычислить номер инода. Это также обусловливает то, что полностью управляемое поведение инодов невозможно реализовать на множестве не-Юниксовых файловых систем, таких как FAT и его преемники, которые не имеют возможности хранить подобную постоянную 'неизменность', когда каталог файла и его содержимое перемещается.

Практическое применение

Множество программ, используемых системными администраторами в операционной системе жестких дисков pfiles могут послужить в данном случае примерами, так как у них есть необходимость естественным образом конвертировать номера инодов в пути файлов и обратно. Это может быть дополнено использованием программы поиска файлов -inum или командой -i).

Иноды могут 'закончиться'. В этом случае нельзя записать информацию на устройство, даже если там достаточно свободного места.

Проблема Y2038

Некоторые файловые системы, основаные на инодах, защищены от проблемы Y2038 (известной как Unix time) с учетом предотвращения 'переполнения' даты, но, к сожалению, далеко не все такие файловые системы защищены от подобных проблем. При настройке сервера отказ от использования подобных

См. также

• Идентификатор

Ссылки

• Уровень виртуальной файловой системы Linux: Иноды и Действия — Иноды в Linux