Inode | это... Что такое Inode? (original) (raw)
inode
В информатике инодом (или индексным дескриптором) (произносится айнод или инод) называют структуру данных в традиционных файловых системах Unix, таких как UFS. Инод хранит основную информацию о постоянных файлах, каталогах или других объектах файловой системы.
Содержание
- 1 Подробности
- 2 Описание инода в POSIX
- 3 Происхождение слова
- 4 Значение
- 5 Практическое применение
- 6 См. также
- 7 Ссылки
Подробности
При создании файловой системы создаются также и структуры данных, содержащие информацию о файлах. Каждый файл имеет свой индексный дескриптор, идентифицируемый по уникальному номеру (часто называемому 'i-номером' или 'инодом'), в файловой системе, в которой располагается сам файл.
Иноды хранят информацию о файлах, такую как принадлежность владельцу (пользователю и группе), режим доступа (чтение, запись, запуск на выполнение) и тип файла. Существует определенное число инодов, которое указывает максимальное количество файлов, допускаемое определенной файловой системой. Обычно, при создании файловой системы примерно 1 % ее выделяется под иноды.
Термин инод обычно указывает на иноды блочных устройств, управляющие постоянными файлами, каталогами и, по возможности, символьными ссылками. Подобная концепция играет важную роль при восстановлении поврежденных файловых систем.
- Номер инода заносится в таблицу инодов в определенном месте устройства; по номеру инода ядро системы может считать содержимое инода, включая указатели данных и прочий контент файла.
- Номер инода файла можно посмотреть используя команду ls -i, а команда ls -l покажет информацию, хранящуюся в иноде.
- Файловые системы, не относящиеся к традиционным ФС UNIX, такие как ReiserFS, могут обходиться без таблицы инодов, но должны хранить аналогичную информацию схожим способом, обеспечивающим эквивалентную функциональность. Такие данные могут называться статистической информацией, по аналогии со
stat— системным вызовом, поставляющим информацию программам.
Имена файлов и содержимое каталогов
- Иноды не хранят имена файлов, только информацию об их содержимом.
- Каталоги в Unix являются списками 'ссылочных' структур, каждая из которых содержит одно имя файла и один номер инода.
- Ядро должно просматривать каталог в поисках имени файла, затем конвертировать это имя в соответствующий номер инода, в случае успеха.
Представление ядром этих данных в памяти называется struct inode (структурным инодом) (в ОС Linux). В BSD система использует терм vnode, буква v в котором указывает на виртуальную файловую систему уровня ядра.
Описание инода в POSIX
Стандарты POSIX описывают поведение файловой системы как потомка традиционных файловых систем Unix. Постоянные файлы должны иметь следующие атрибуты:
- Длина файла в байтах.
- ID устройства (это идентифицирует устройство, содержащее файл).
- ID пользователя, являющегося владельцем файла.
- ID группы файла.
- файла, определяющий какие пользователи могут считывать, записывать и запускать файл.
- Timestamp указывает дату последнего изменения инода (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 не позволяют установить точное имя удалённого файла), а его ресурсы должны освободиться (это нормальный процесс удаления файла), но если какие-либо процессы держат файл открытым, то они могут удерживать доступ к нему, а файл будет окончательно удален только когда будет закрыто последнее обращение к нему. Это относится и к исполнимым копиям, которые удерживаются открытыми процессами, их выполняющими. По этой причине, при обновлении программы рекомендуется удалять старую копию и создавать новый инод для обновленной версии, чтобы никакие экземпляры старой версии не продолжали выполняться.
- Обычно нет возможности сопоставить открытый файл и имя, по которому он был открыт. Операционная система преобразует имя файла в номер инода при первом же удобном случае, а затем «забывает» про имя файла. Таким образом, функции библиотек getcwd() и начинают искать в родительском каталоге файл с инодом, совпадающим с файлом «.» каталога, затем ищут родительский каталог для текущего, и так далее пока не достигнут «/» каталога. SVR4 и Linux используют дополнительную информацию для избежания подобного неудобства.
- Ранее было возможно применять жесткие ссылки на каталоги. Это делало структуру каталогов ориентированным графом вместо дерева, то есть связного графа с N-1 ребрами и N узлами. Например, каталог имел возможность быть собственным родителем. Современные системы не допускают подобных двусмысленностей, за исключением корневого каталога, который считается собственным родителем.
- Номер инода файла остается неизменным при перемещении файла в другой каталог на том же устройстве или при дефрагментации диска. Поэтому, перемещение или каталога, содержащего файл, или его содержимого (или и того и другого вместе) недостаточно для предотвращения доступа к нему запущенного процесса, если у процесса есть возможность вычислить номер инода. Это также обусловливает то, что полностью управляемое поведение инодов невозможно реализовать на множестве не-Юниксовых файловых систем, таких как FAT и его преемники, которые не имеют возможности хранить подобную постоянную 'неизменность', когда каталог файла и его содержимое перемещается.
Практическое применение
Множество программ, используемых системными администраторами в операционной системе UNIX, часто используют номера инодов для обозначения файлов. Популярная встроенная программа проверки жестких дисков [fsck](366967) или команда pfiles могут послужить в данном случае примерами, так как у них есть необходимость естественным образом конвертировать номера инодов в пути файлов и обратно. Это может быть дополнено использованием программы поиска файлов [find](310797) с ключом -inum или командой [ls](15830) с соответствующим ключом (которым на большинстве платформ является -i).
Иноды могут 'закончиться'. В этом случае нельзя записать информацию на устройство, даже если там достаточно свободного места.
Проблема Y2038
Некоторые файловые системы, основаные на инодах, защищены от проблемы Y2038 (известной как Unix time) с учетом предотвращения 'переполнения' даты, но, к сожалению, далеко не все такие файловые системы защищены от подобных проблем. При настройке сервера отказ от использования подобных POSIX-несовместимых файловых систем становится более важным. Последняя версия POSIX поддерживает системное время и вызовы даты, устойчивые к проблеме Y2038.
См. также
Ссылки
Wikimedia Foundation.2010.