Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Индексный дескриптор (индекс узел) представляет собой структуру данных в файловой системе UNIX-стиле , который описывает файловую систему объект , такие как файл или каталог . Каждый индексный дескриптор хранит атрибуты и расположение дисковых блоков данных объекта. [1] Атрибуты объекта файловой системы могут включать в себя метаданные (время последнего изменения, [2] доступ, модификацию), а также данные о владельце и разрешениях . [3]

Каталоги - это списки имен, присвоенных индексным дескрипторам. Каталог содержит запись для себя, своего родителя и каждого из его дочерних элементов.

Этимология [ править ]

В списке рассылки ядра Linux была неопределенность относительно причины появления «i» в «inode». В 2002 году этот вопрос был задан первопроходцу Unix Деннису Ричи , который ответил: [4]

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

В статье 1978 года Ричи и Кена Томпсона подтверждается идея о том, что «индекс» является этимологическим происхождением индексов. Они написали: [5]

[…] Запись каталога содержит только имя связанного файла и указатель на сам файл. Этот указатель представляет собой целое число, называемое i-номером (порядковым номером) файла. При доступе к файлу его i-номер используется в качестве индекса в системной таблице ( i-list ), хранящейся в известной части устройства, на котором находится каталог. Найденная таким образом запись ( i-узел файла ) содержит описание файла.

Кроме того, Морис Дж. Бах писал, что индексный дескриптор «является сокращением термина индексный узел и обычно используется в литературе по системе UNIX». [6]

Подробности [ править ]

Дескрипторы файлов, таблица файлов и таблица inode в Unix [7]

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

Inodes хранит информацию о файлах и каталогах (папках), такую ​​как право собственности на файл, режим доступа (права на чтение, запись, выполнение) и тип файла. Во многих более старых реализациях файловых систем максимальное количество inodes фиксируется при создании файловой системы, ограничивая максимальное количество файлов, которое может содержать файловая система. Типичная эвристика распределения для индексных дескрипторов в файловой системе - один индексный дескриптор на каждые 2 Кбайт, содержащихся в файловой системе. [8]

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

Некоторые файловые системы в стиле Unix, такие как ReiserFS , btrfs и APFS, опускают таблицу inode фиксированного размера, но должны хранить эквивалентные данные для обеспечения эквивалентных возможностей. Данные могут называться статистическими данными по отношению к stat системному вызову, который предоставляет данные программам. Общие альтернативы таблице фиксированного размера включают B-деревья и производные B + деревья .

Имена файлов и значения каталогов:

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

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

Описание inode POSIX [ править ]

Стандарт POSIX предписывает поведение файловой системы, на которое сильно влияют традиционные файловые системы UNIX . Inode обозначается фразой «серийный номер файла», определяемой как уникальный идентификатор файла для каждой файловой системы . [9] Этот серийный номер файла вместе с идентификатором устройства, содержащего файл, однозначно идентифицирует файл во всей системе. [10]

В системе POSIX файл имеет следующие атрибуты [10], которые могут быть получены statсистемным вызовом:

  • Идентификатор устройства (идентифицирует устройство, содержащее файл; то есть область уникальности серийного номера).
  • Серийные номера файлов.
  • Файл режим , который определяет тип файла и как владелец файла, его группа, и другие могут получить доступ к файлу.
  • Ссылка подсчета красноречивым , сколько жестких ссылок указывают на индексный дескриптор.
  • Идентификатор пользователя владельца файла.
  • Идентификатор группы файла.
  • Идентификатор устройства для файла, если это файл устройства .
  • Размер файла в байтах .
  • Метки времени, указывающие , когда сам индексный дескриптор был в последний раз изменен ( ctime , время изменения inode ), содержимое файла в последний раз изменено ( mtime , время модификации ) и последний доступ ( atime , время доступа ).
  • Предпочтительный размер блока ввода-вывода.
  • Количество блоков, выделенных для этого файла.

Последствия [ править ]

  • Файлы могут иметь несколько имен. Если несколько имен жестко ссылаются на один и тот же индексный дескриптор, тогда имена эквивалентны; т.е. создаваемый первым не имеет особого статуса. Это не похоже на символические ссылки , которые зависят от исходного имени, а не от индекса (номера).
  • Inode может не иметь ссылок. Несвязанный файл удаляется с диска, а его ресурсы освобождаются для перераспределения, но удаление должно ждать, пока все процессы, открывшие его, закончат доступ к нему. Сюда входят исполняемые файлы, которые неявно открываются исполняющими их процессами.
  • Обычно невозможно сопоставить открытый файл с именем файла, которое использовалось для его открытия. Операционная система немедленно преобразует имя файла в номер inode, а затем отбрасывает имя файла. Это означает, что библиотечные функции getcwd () и getwd () выполняют поиск в родительском каталоге, чтобы найти файл с индексным индексом, соответствующим рабочему каталогу , затем выполняют поиск в родительском каталоге этого каталога и так далее до достижения корневого каталога . Системы SVR4 и Linux содержат дополнительную информацию, чтобы это стало возможным.
  • Исторически существовала возможность жестко связать каталоги. Это превратило структуру каталогов в произвольный ориентированный граф в отличие от ориентированного ациклического графа . Каталог даже мог быть собственным родительским. Современные системы обычно запрещают это сбивающее с толку состояние, за исключением того, что родительский элемент root по-прежнему определяется как root. Наиболее заметным исключением из этого запрета является Mac OS X (версии 10.5 и выше), которая позволяет суперпользователю создавать жесткие ссылки на каталоги. [11]
  • Номер inode файла остается неизменным, когда он перемещается в другой каталог на том же устройстве или когда диск дефрагментирован, что может изменить его физическое расположение, что позволяет перемещать и переименовывать его даже во время чтения и записи без прерывания работы . Это также означает, что полностью соответствующее поведение inode невозможно реализовать со многими файловыми системами, отличными от Unix, такими как FAT и ее потомки, у которых нет способа сохранить эту инвариантность, когда и запись каталога файла, и его данные перемещаются. .
  • Установка новых библиотек проста с файловыми системами inode. Запущенный процесс может получить доступ к файлу библиотеки, в то время как другой процесс заменяет этот файл, создавая новый индексный дескриптор, и для нового файла будет существовать совершенно новое сопоставление, чтобы при последующих попытках доступа к библиотеке была получена новая версия. Эта возможность устраняет необходимость перезагрузки для замены библиотек, отображаемых в настоящее время.
  • На устройстве могут закончиться inodes. В этом случае на устройстве невозможно создать новые файлы, даже если на нем может быть свободное место. Это наиболее распространено для таких случаев, как почтовые серверы, содержащие много небольших файлов. Файловые системы (такие как JFS или XFS ) избегают этого ограничения с помощью экстентов или динамического выделения inode, что может «разрастать» файловую систему или увеличивать количество inode.

Встраивание [ править ]

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

Если данные файла умещаются в пространстве, выделенном для указателей на данные, это пространство можно удобно использовать. Например, ext2 и его последователи хранят данные символических ссылок (обычно имена файлов) таким образом, если размер данных не превышает 60 байтов («быстрые символические ссылки»). [12]

В Ext4 есть опция файловой системы, inline_dataкоторая позволяет ext4 выполнять встраивание, если она включена во время создания файловой системы. Поскольку размер inode ограничен, это работает только для очень маленьких файлов. [13]

В системах, отличных от Unix [ править ]

  • NTFS имеет основную файловую таблицу (MFT), в которой файлы хранятся в виде B-дерева. У каждой записи есть «fileID», аналогичный номеру inode, который однозначно ссылается на эту запись. [14] Три метки времени, идентификатор устройства, атрибуты, количество ссылок и размеры файлов находятся в записи, но, в отличие от POSIX, разрешения выражаются через другой API. [15] Схема на диске более сложная. [16] Ранние файловые системы FAT не имели такой таблицы и не могли создавать жесткие ссылки .
    • NTFS также имеет концепцию встраивания небольших файлов в запись MFT. [17]
    • Производное ReFS имеет гомологичный MFT. ReFS имеет 128-битный идентификатор файла; это расширение также было перенесено в NTFS, которая изначально имела 64-битный идентификатор файла. [15]
  • Тот же статистический API GetFileInformationByHandle может использоваться в общих томах кластера и SMB 3.0 , поэтому эти системы, по-видимому, имеют аналогичную концепцию идентификатора файла. [15]

См. Также [ править ]

  • структура указателя inode
  • inotify

Ссылки [ править ]

  1. ^ Таненбаум, Эндрю С. Современные операционные системы (3-е изд.). п. 279.
  2. ^ JVSANTEN. «Разница между mtime, ctime и atime - Linux Howtos и часто задаваемые вопросы» . Linux Howtos и часто задаваемые вопросы .
  3. ^ «Анатомия переключателя виртуальной файловой системы Linux» . ibm.com .
  4. ^ Архив списка ядер Linux . Проверено 12 января 2011.
  5. ^ Ричи, Деннис М .; Томпсон, Кен (1978). «Система разделения времени UNIX» . Технический журнал Bell System . 57 (6): 1913–1914 . Дата обращения 19 декабря 2015 .
  6. ^ Морис Дж. Бах (1986). Дизайн операционной системы UNIX . Прентис Холл. ISBN 978-0132017992.
  7. ^ Бах, Морис Дж. (1986). Дизайн операционной системы UNIX . Прентис Холл. п. 94. Bibcode : 1986duos.book ..... B .
  8. ^ "линфо" . Информационный проект Linux . Дата обращения 11 марта 2020 .
  9. ^ «Определения - 3.176 серийный номер файла» . Открытая группа . Проверено 10 января 2018 .
  10. ^ a b "<sys / stat.h>" . Открытая группа . Проверено 15 января 2018 .
  11. ^ "Что такое команда Unix для создания жесткой ссылки на каталог в OS X?" . Переполнение стека . 16 января 2011. Архивировано 5 января 2020 года . Дата обращения 5 января 2020 .
  12. ^ «Ядро Linux: Файловые системы» . tue.nl .
  13. ^ "Схема диска Ext4" . kernel.org . Проверено 18 августа 2013 года .
  14. ^ "Есть ли в Windows номера Inode, как в Linux?" . Переполнение стека .
  15. ^ a b c «Функция GetFileInformationByHandle (fileapi.h) - приложения Win32» . docs.microsoft.com .
  16. ^ «[MS-FSCC]: Типы атрибутов NTFS» . docs.microsoft.com .
  17. ^ https://superuser.com/a/1185466

Внешние ссылки [ править ]

  • Анатомия файловой системы Linux
  • Определение inode
  • Объяснение Inodes, Symlinks и Hardlinks