Введение

Структура данных, описывающая объект файловой системы и расположение блоков диска, содержащих данные объекта.

Инод (индексный узел) – это структура данных в файловой системе типа Unix, которая описывает объект файловой системы, такой как файл или каталог. Каждый инод хранит атрибуты и расположение блоков диска, содержащих данные объекта. Атрибуты объектов файловой системы могут включать метаданные (время последнего изменения, доступа и модификации), а также данные о владельце и правах доступа. Каталог представляет собой список инодов с присвоенными им именами. Этот список включает в себя запись для самого каталога, для его родительского каталога и для каждого из его дочерних каталогов.

Этимология

В списке рассылки ядра Linux существовала неопределенность относительно причины буквы "i" в "inode". В 2002 году этот вопрос был задан пионеру Unix Деннису Ричи, который ответил:

Статья 1978 года, написанная Ричи и Кеном Томпсоном, подтверждает предположение о том, что "index" (индекс) является этимологическим происхождением inodes. Они писали: Кроме того, Морис Дж. Бах отмечал, что слово inode "является сокращением от термина 'index node' (индексный узел) и широко используется в литературе, посвященной системе UNIX".

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

Стандарт POSIX определяет поведение файловой системы, которое во многом обусловлено традиционными файловыми системами UNIX. Инод обозначается как "серийный номер файла" и определяется как уникальный идентификатор файла в пределах файловой системы. Этот серийный номер файла, вместе с идентификатором устройства, содержащего файл, однозначно идентифицирует файл во всей системе и может быть получен с помощью системного вызова stat: идентификатор устройства (определяет устройство, содержащее файл, то есть область уникальности серийного номера), серийные номера файлов, режим файла, определяющий тип файла и права доступа для владельца, группы и остальных пользователей, количество жестких ссылок, указывающих на данный инод, идентификатор пользователя-владельца файла, идентификатор группы файла, идентификатор устройства файла, если это файловое устройство, размер файла в байтах, временные метки, указывающие время последнего изменения самого инода (время изменения инода), время последнего изменения содержимого файла (время модификации) и время последнего доступа (время доступа), предпочтительный размер блока ввода-вывода и количество блоков, выделенных этому файлу.

Файлы с несколькими именами и жесткие ссылки

Файлы могут иметь несколько имен. Если несколько имен жёстко связаны с одним и тем же inode, то эти имена эквивалентны; то есть, первому созданному имени не придаётся никакого особого статуса. Это отличается от символических ссылок, которые зависят от исходного имени, а не от номера inode.

постоянство инодов и несвязанные файлы

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

конверсия инода и поиск пути каталога файлов

Обычно невозможно сопоставить открытый файл с именем файла, которое использовалось при его открытии. Когда программа открывает файл, операционная система преобразует имя файла в номер inode и затем отбрасывает имя файла. В результате, функции, подобные и , которые получают текущий рабочий каталог процесса, не могут напрямую получить доступ к имени файла. Начиная с текущего каталога, эти функции ищут до родительского каталога, затем до родительского каталога родительского каталога и так далее, пока не достигнут корневого каталога. На каждом уровне функция ищет запись в каталоге, inode которой соответствует каталогу, из которого она только что перешла. Поскольку inode дочернего каталога всё ещё существует как запись в его родительском каталоге, это позволяет функции восстановить абсолютный путь текущего рабочего каталога. Некоторые операционные системы поддерживают дополнительную информацию для ускорения этой операции. Например, в Linux VFS кэш записей каталогов, также известный как dentry или dcache, представляет собой кэш, используемый ядром для ускорения операций файловой системы путём хранения информации о связях каталогов в оперативной памяти.

Историческая возможность жесткой ссылки на каталог

Исторически существовала возможность создавать жесткие ссылки на каталоги. Это приводило к тому, что структура каталогов становилась произвольным ориентированным графом, а не ориентированным ациклическим графом. Даже было возможно, чтобы каталог являлся родителем самого себя. Современные системы, как правило, запрещают это запутанное состояние, за исключением того, что родитель корневого каталога по-прежнему определяется как корневой каталог. Наиболее заметным исключением из этого запрета является Mac OS X (версии 10.5 и выше), которая позволяет суперпользователю создавать жесткие ссылки на каталоги.

стабильность инодных номеров и файловые системы, не использующие Unix

Когда файл перемещается в другой каталог в той же файловой системе, или когда дефрагментация диска изменяет его физическое расположение, номер inode файла остаётся неизменным. Эта уникальная особенность позволяет перемещать или переименовывать файл даже во время операций чтения или записи, обеспечивая тем самым непрерывный доступ без прерываний. Эта возможность – сохранение метаданных файла и расположения блоков данных в центральной структуре данных, независимо от переименования или перемещения файла – не может быть полностью воспроизведена во многих файловых системах, отличных от Unix, таких как FAT и её производные, поскольку в них отсутствует механизм для поддержания этого инвариантного свойства при одновременном перемещении записи файла в каталоге и его данных. В этих файловых системах перемещение или переименование файла может привести к более существенным изменениям в структуре данных, представляющей файл, и система не хранит отдельную, централизованную запись расположения блоков данных файла и метаданных, как это делают inode в Unix-подобных системах.

Упрощенная установка библиотеки с файловыми системами inode

Файловые системы, использующие inodes, позволяют работающему процессу продолжать доступ к файлу библиотеки, даже если другой процесс заменяет этот же файл. Эта операция должна выполняться атомарно, то есть выглядеть как единое действие, которое либо полностью завершается, либо не выполняется вовсе, без какого-либо видимого промежуточного состояния для других процессов. В процессе замены для нового файла библиотеки создается новый inode, устанавливая совершенно новую связь. После этого последующие запросы на доступ к библиотеке будут получать новую установленную версию. Когда операционная система заменяет файл (и создает новый inode), она устанавливает блокировку на inode и, возможно, на содержащий его каталог. Это предотвращает чтение или запись файла (inode) другими процессами во время операции обновления, тем самым избегая несогласованности или повреждения данных. После завершения операции обновления блокировка снимается. Любой последующий доступ к файлу (через inode) любыми процессами теперь будет указывать на новую версию библиотеки. Таким образом, становится возможным выполнять обновления даже при использовании библиотеки другим процессом. Важным преимуществом этого механизма является то, что он устраняет необходимость перезагрузки системы для замены библиотек, которые в данный момент используются. Следовательно, системы могут беспрепятственно обновлять или модернизировать программные библиотеки, не прерывая работу запущенных процессов или операций.

Потенциал исчерпания и решения

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

Внутренний подклад

Может быть целесообразно хранить очень маленькие файлы непосредственно в иноде, чтобы сэкономить место (не требуется блок данных) и время поиска (не требуется дополнительный доступ к диску). Эта функция файловой системы называется inlining (встраиванием). Таким образом, строгое разделение данных инода и данных файла нельзя гарантировать при использовании современных файловых систем. Если данные файла помещаются в пространство, выделенное для указателей на данные, это пространство можно эффективно использовать. Например, ext2 и её последователи хранят данные символических ссылок (обычно имена файлов) таким образом, если размер данных не превышает 60 байт ("быстрые символические ссылки"). Ext4 имеет опцию файловой системы под названием inline data, которая позволяет Ext4 выполнять inlining, если она включена при создании файловой системы. Поскольку размер инода ограничен, это работает только для очень маленьких файлов.

В не-Unix системах

NTFS имеет мастер-таблицу файлов (MFT), хранящую файлы в B-дереве. Каждая запись имеет "fileID", аналогичный номеру inode, который однозначно идентифицирует эту запись. В записи содержатся три временные метки, идентификатор устройства, атрибуты, счетчик ссылок и размеры файлов, но, в отличие от POSIX, права доступа выражаются через другой API. Структура на диске более сложная. Более ранние файловые системы FAT не имели такой таблицы и не поддерживали создание жестких ссылок. NTFS также поддерживает встраивание небольших файлов непосредственно в запись MFT. Производная файловая система ReFS имеет аналогичную MFT. ReFS использует 128-битный идентификатор файла; это расширение было также перенесено в NTFS, который изначально использовал 64-битный идентификатор файла. Аналогичный API может использоваться для томов Cluster Shared Volumes и SMB 3.0, следовательно, эти системы, вероятно, используют схожую концепцию идентификатора файла.