Индексный дескриптор (индексный узел) — это структура данных в файловой системе в стиле Unix , которая описывает объект файловой системы, такой как файл или каталог . Каждый индексный дескриптор хранит атрибуты и расположение дисковых блоков данных объекта. [1] Атрибуты объекта файловой системы могут включать метаданные (время последнего изменения, [2] доступ, модификацию), а также данные владельца и разрешения . [3]
Каталог — это список инодов с присвоенными им именами. Список включает запись для себя, своего родителя и каждого из своих потомков.
В списке рассылки ядра Linux была неопределенность относительно причины "i" в "inode". В 2002 году вопрос был задан пионеру Unix Деннису Ритчи , который ответил: [4]
По правде говоря, я тоже не знаю. Это был просто термин, который мы начали использовать. «Индекс» — моя лучшая догадка, из-за немного необычной структуры файловой системы, которая хранила информацию о доступе к файлам в виде плоского массива на диске, а вся иерархическая информация о каталогах находилась отдельно от него. Таким образом, i-номер — это индекс в этом массиве, i-узел — это выбранный элемент массива. (Обозначение «i-» использовалось в руководстве 1-го издания; его дефис постепенно исчез.)
Статья Ритчи и Кена Томпсона 1978 года поддерживает идею о том, что «индекс» является этимологическим источником инодов. Они писали: [5]
[…] запись каталога содержит только имя связанного файла и указатель на сам файл. Этот указатель представляет собой целое число, называемое i-номером (индексный номер) файла. При доступе к файлу его i-номер используется как индекс в системной таблице ( i-список ), хранящейся в известной части устройства, на котором находится каталог. Найденная таким образом запись ( i-узел файла ) содержит описание файла.
Кроме того, Морис Дж. Бах писал, что слово inode «является сокращением термина index node и широко используется в литературе по системе UNIX» [6] .
Файловая система опирается на структуры данных о файлах, а не на содержимое этого файла. Первые называются метаданными — данными, описывающими данные. Каждый файл связан с inode , который идентифицируется целым числом, часто называемым i-number или inode number .
Inodes хранят информацию о файлах и каталогах (папках), такую как владелец файла, режим доступа (разрешения на чтение, запись, выполнение) и тип файла. Данные могут называться stat data, в соответствии с stat системным вызовом , который предоставляет данные программам.
Номер инода индексирует таблицу инодов в файловой системе. Из номера инода драйвер файловой системы ядра может получить доступ к содержимому инода, включая местоположение файла, тем самым разрешая доступ к файлу. Номер инода файла можно найти с помощью команды ls -i. ls -iКоманда выводит номер инода в первом столбце отчета.
Во многих старых файловых системах inodes хранятся в одной или нескольких областях фиксированного размера, которые настраиваются во время создания файловой системы, поэтому максимальное количество inodes фиксируется при создании файловой системы, ограничивая максимальное количество файлов, которые может содержать файловая система. Типичная эвристика распределения для inodes в файловой системе — один inode на каждые 2 Кбайт, содержащиеся в файловой системе. [8]
Некоторые файловые системы в стиле Unix, такие как JFS , XFS , ZFS , OpenZFS , ReiserFS , btrfs и APFS , не содержат таблицу инодов фиксированного размера, но должны хранить эквивалентные данные для предоставления эквивалентных возможностей. Распространенными альтернативами таблице фиксированного размера являются B-деревья и производные B+деревья .
Имена файлов и каталоги:
Представление этих данных в памяти ядра операционной системы называется struct inodeв Linux . Системы, полученные от BSD, используют этот термин («v» относится к слою виртуальной файловой системыvnode ядра ).
Стандарт POSIX предписывает поведение файловой системы, на которое сильное влияние оказывают традиционные файловые системы UNIX . Инод обозначается фразой «серийный номер файла», определяемой как уникальный идентификатор файла для каждой файловой системы . [9] Этот серийный номер файла вместе с идентификатором устройства, содержащего файл, уникально идентифицирует файл в пределах всей системы. [10]
В системе POSIX файл имеет следующие атрибуты [10] , которые могут быть получены системным statвызовом:
Файловые системы, разработанные с использованием inode, будут иметь следующие административные характеристики:
Файлы могут иметь несколько имен. Если несколько имен жестко ссылаются на один и тот же inode, то имена эквивалентны; т. е. первое созданное имя не имеет особого статуса. Это отличается от символических ссылок , которые зависят от исходного имени, а не от inode (номера).
У inode может не быть ссылок. Inode без ссылок представляет собой файл, в котором не осталось записей каталогов или путей, ведущих к нему в файловой системе. Файл, который был удален или не имеет записей каталогов, указывающих на него, называется «несвязанным» файлом.
Такие файлы удаляются из файловой системы, освобождая занятое дисковое пространство для повторного использования. Инод без ссылок остается в файловой системе до тех пор, пока ресурсы (дисковое пространство и блоки), освобожденные несвязанным файлом, не будут освобождены или файловая система не будет изменена.
Хотя несвязанный файл становится невидимым в файловой системе, его удаление откладывается до тех пор, пока все процессы, имеющие доступ к файлу, не закончат его использовать, включая исполняемые файлы, которые неявно удерживаются открытыми процессами, выполняющими их.
Обычно невозможно сопоставить открытый файл с именем файла, которое использовалось для его открытия. Когда программа открывает файл, операционная система преобразует имя файла в номер inode, а затем отбрасывает имя файла. В результате функции вроде getcwd() и getwd() , которые извлекают текущий рабочий каталог процесса, не могут напрямую получить доступ к имени файла.
Начиная с текущего каталога, эти функции выполняют поиск вплоть до его родительского каталога , затем до родителя родителя и так далее, пока не достигнет корневого каталога . На каждом уровне функция ищет запись каталога, чей inode совпадает с таковым каталога, из которого она только что переместилась. Поскольку inode дочернего каталога все еще существует как запись в его родительском каталоге , это позволяет функции восстановить абсолютный путь текущего рабочего каталога .
Некоторые операционные системы поддерживают дополнительную информацию, чтобы ускорить выполнение этой операции. Например, в Linux VFS [11] кэш записей каталогов [12] , также известный как dentry или dcache, — это записи кэша, используемые ядром для ускорения операций файловой системы путем хранения информации о ссылках каталогов в оперативной памяти .
Исторически существовала возможность жесткого связывания каталогов. Это делало структуру каталогов произвольным направленным графом, в отличие от направленного ациклического графа . Было даже возможно, чтобы каталог был своим собственным родителем. Современные системы, как правило, запрещают это запутанное состояние, за исключением того, что родитель корня по-прежнему определяется как root. Наиболее заметное исключение из этого запрета можно найти в Mac OS X (версии 10.5 и выше), которая позволяет суперпользователю создавать жесткие ссылки каталогов. [13]
Когда файл перемещается в другой каталог в той же файловой системе или когда дефрагментация диска изменяет его физическое местоположение, номер inode файла остается неизменным.
Эта уникальная характеристика позволяет перемещать или переименовывать файл даже во время операций чтения или записи, тем самым обеспечивая непрерывный доступ без перебоев.
Эта функция — сохранение метаданных файла и расположения блоков данных в центральной структуре данных , независимо от переименования или перемещения файла — не может быть полностью воспроизведена во многих не-Unix файловых системах, таких как FAT и ее производные, поскольку у них отсутствует механизм для поддержания этого инвариантного свойства, когда и запись каталога файла, и его данные одновременно перемещаются. В этих файловых системах перемещение или переименование файла может привести к более значительным изменениям в структуре данных, представляющей файл, и система не хранит отдельную, центральную запись расположения блоков данных файла и метаданных , как это делают inodes в Unix-подобных системах.
Файловые системы inode позволяют запущенному процессу продолжать доступ к библиотечному файлу, даже если другой процесс заменяет этот же файл.
Эта операция должна выполняться атомарно , то есть она должна выглядеть как одна операция, которая либо полностью завершена, либо не выполнена вообще, без промежуточного состояния, видимого другим процессам.
Во время замены создается новый inode для нового файла библиотеки , устанавливая совершенно новое отображение. Впоследствии будущие запросы на доступ к этой библиотеке будут извлекать новую установленную версию.
Когда операционная система заменяет файл (и создает новый inode), она устанавливает блокировку [14] на inode [15] и, возможно, на содержащий его каталог. [16] Это предотвращает чтение или запись в файл (inode) другими процессами [17] во время операции обновления, тем самым избегая несогласованности или повреждения данных. [18]
После завершения операции обновления блокировка снимается. Любой последующий доступ к файлу (через inode) любыми процессами теперь будет указывать на новую версию библиотеки. Таким образом, становится возможным выполнять обновления, даже если библиотека используется другим процессом.
Одним из существенных преимуществ этого механизма является то, что он устраняет необходимость перезагрузки системы для замены используемых в данный момент библиотек. Следовательно, системы могут обновлять или модернизировать библиотеки программного обеспечения беспрепятственно, не прерывая запущенные процессы или операции.
При создании файловой системы некоторые файловые системы выделяют фиксированное количество инодов. [19] Это означает, что в файловой системе может закончиться количество инодов, даже если в файловой системе осталось свободное место. Такая ситуация часто возникает в случаях использования, когда есть много небольших файлов, например, на сервере, хранящем сообщения электронной почты, поскольку каждый файл, независимо от его размера, требует своего собственного инода.
Другие файловые системы обходят это ограничение, используя динамическое распределение инодов. [20] Динамическое распределение инодов позволяет файловой системе создавать больше инодов по мере необходимости, а не полагаться на фиксированное число, созданное во время создания файловой системы. [21] Это может «вырастить» файловую систему, увеличив количество инодов, доступных для новых файлов и каталогов, тем самым избежав проблемы исчерпания инодов. [22]
Может иметь смысл хранить очень маленькие файлы в самом inode, чтобы сэкономить как место (не требуется блок данных), так и время поиска (не требуется дополнительный доступ к диску). Эта функция файловой системы называется встраиванием. Таким образом, строгое разделение inode и данных файла больше не может предполагаться при использовании современных файловых систем.
Если данные файла помещаются в пространство, выделенное для указателей на данные, это пространство можно удобно использовать. Например, ext2 и ее последователи хранят данные символических ссылок (обычно имена файлов) таким образом, если данные не превышают 60 байт («быстрые символические ссылки»). [23]
Ext4 имеет опцию файловой системы inline_data, которая позволяет ext4 выполнять встраивание, если она включена во время создания файловой системы. Поскольку размер inode ограничен, это работает только для очень маленьких файлов. [24]
{{cite web}}: CS1 maint: неподходящий URL ( ссылка ){{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка )