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

Роль Inode в файловых системах Linux

Оригинал: Inodes and the Linux filesystem
Автор: Tyler Carrigan (Red Hat)
Дата публикации: 9 июня 2020 г.
Перевод: В.Костромин
Дата перевода: 15 июня 2020 г.

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

Что такое inode?

Inode – это сокращение от «index node», по-русски – индексный узел. По сути он представляет собой уникальную порцию метаданных в заданной файловой системе. Эта порция метаданных описывает то, что мы называем файлом. Иноды относятся только к определенной файловой системе, не касаясь других. Как ни странно это может показаться, но все иноды хранятся в общей таблице и это иногда вызывает недоумение. Однако каждая файловая система, смонтированная на вашем компьютере, имеет свои собственные inode. Номер inode может использоваться более одного раза, но никогда не может дважды использоваться одной и той же файловой системой. Идентификатор файловой системы в сочетании с номером инода создает уникальную идентификационную метку.

Сколько существует инодов?

Если вы не хотите связываться с математикой, вы можете пропустить этот раздел. В каждой системе имеется множество inode и есть несколько относящихся к ним числовых значений, которые нужно знать. Прежде всего, хотя это и менее важно, теоретическое максимальное число inode равно 2 ^ 32 (приблизительно 4,3 миллиарда inode). Во-вторых, что гораздо важнее, это число inode в вашей системе. Как правило, количество inode составляет 1:16 от объема файловой системы в КБ. Очевидно, что каждая система отличается, поэтому вам нужно рассчитать это значение самостоятельно.

Команды для работы с inode

Есть хорошая новость для тех, кто не любит математику: для этого есть специальная команда. Чтобы узнать количество inode в вашей системе, вы можете использовать команду df с опцией -i , как показано здесь:

Вы можете видеть, что в этом примере мы запустили команду df -i на файловой системе /dev/sda1 . В этой системе всего имеется 524 288 инодов, но только 312 из них используется (примерно 1%).

Номер inode файла

Мы также можем узнать номер inode конкретного файла. Для этого можно использовать команду ls -i с указанием нужного файла. Например:

Номер inode этого файла — 1459027.

Номер inode каталога

Подобно тому, как мы узнали номер inode файла, мы можем посмотреть и номер inode каталога. Для этого снова используем команду ls -i с некоторыми дополнительными опциями. Например:

Как вы можете видеть, мы использовали опцию -i (inodes), а также -l (long format) и -d (directory). Применение этих флажков позволяет нам получить множество информации о каталоге my_articles, включая номер inode, разрешения, владельцы и т.д.

Подведем итог

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

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

Tyler Carrigan

Tyler работает менеджером в Enable Sysadmin, является ветераном подводного флота и энтузиастом новых технологий! Он впервые познакомился с Red Hat в 2012 году при использовании основанной на Red Hat Enterprise Linux боевой системы в Центре управления ракетами на подводной лодке USS Georgia.

Источник

Все, что вы когда-либо хотели знать об индексных дескрипторах в Linux

Файловая система Linux использует inodes. Эти жизненно важные части внутренней работы файловой системы часто неправильно понимаются. Давайте посмотрим, что они из себя представляют и чем занимаются.

Элементы файловой системы

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

В файловой системе Linux ext4 структуры inode и каталогов работают вместе, обеспечивая основу, в которой хранятся все метаданные для каждого файла и каталога. Они делают метаданные доступными для всех, кому они нужны, будь то ядро, пользовательские приложения или утилиты Linux, такие как ls , stat и df код>.

Inodes и размер файловой системы

Хотя это правда, что существует пара структур, файловая система требует гораздо большего. Есть тысячи и тысячи каждой структуры. Для каждого файла и каталога требуется индексный дескриптор, и поскольку каждый файл находится в каталоге, для каждого файла также требуется структура каталогов. Структуры каталогов также называются записями каталогов или «дентри».

Каждый индексный дескриптор имеет номер индексного дескриптора, который уникален в пределах файловой системы. Один и тот же номер inode может появляться в нескольких файловых системах. Однако идентификатор файловой системы и номер inode вместе составляют уникальный идентификатор, независимо от того, сколько файловых систем смонтировано в вашей системе Linux.

Помните, что в Linux вы не монтируете жесткий диск или раздел. Вы монтируете файловую систему, которая находится в разделе, поэтому легко иметь несколько файловых систем, даже не осознавая этого. Если у вас несколько жестких дисков или разделов на одном диске, у вас более одной файловой системы. Они могут быть одного типа — например, все ext4 — но все равно будут разными файловыми системами.

Все иноды хранятся в одной таблице. Используя номер inode, файловая система легко вычисляет смещение в таблице inode, в которой находится этот индекс. Вы можете понять, почему «i» в индексном дескрипторе означает индекс.

Переменная, содержащая номер inode, объявлена ​​в исходном коде как 32-битное длинное целое число без знака. Это означает, что номер inode — это целое число с максимальным размером 2 ^ 32, что дает 4 294 967 295 — более 4 миллиардов inode.

Это теоретический максимум. На практике количество индексных дескрипторов в файловой системе ext4 определяется, когда файловая система создается с соотношением по умолчанию один индексный дескриптор на 16 КБ емкости файловой системы. Структуры каталогов создаются на лету, когда файловая система используется, поскольку файлы и каталоги создаются в файловой системе.

Вы можете использовать команду, чтобы узнать, сколько индексных дескрипторов находится в файловой системе на вашем компьютере. Параметр -i (inodes) команды df указывает ей отображать вывод в количестве inodes.

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

Результат дает нам:

• Файловая система: файловая система, по которой создается отчет.
• Inodes: общее количество индексных дескрипторов в этой файловой системе.
• Я использовал: количество используемых индексных дескрипторов.
• Я свободен: количество оставшихся inodes, доступных для использования.
• Я использую%: процент использованных индексных дескрипторов.
• Установлен на: точка монтирования этой файловой системы.

Мы использовали 10 процентов индексных дескрипторов в этой файловой системе. Файлы хранятся на жестком диске в дисковых блоках. Каждый индексный дескриптор указывает на блоки диска, в которых хранится содержимое файла, который они представляют. Если у вас есть миллионы крошечных файлов, у вас могут закончиться inodes до того, как закончится место на жестком диске. Однако это очень сложная проблема.

В прошлом эта проблема возникала на некоторых почтовых серверах, на которых сообщения электронной почты хранились в виде отдельных файлов (что быстро приводило к большим коллекциям небольших файлов). Однако, когда эти приложения изменили свои серверные части на базы данных, это решило проблему. В средней домашней системе не закончатся inodes, и это тоже хорошо, потому что с файловой системой ext4 вы не можете добавить больше inodes без переустановки файловой системы.

Чтобы увидеть размер дисковых блоков в вашей файловой системе, вы можете использовать команду blockdev с параметром —getbsz (получить размер блока):

Размер блока 4096 байт.

Давайте воспользуемся опцией -B (размер блока), чтобы указать размер блока 4096 байт и проверить регулярное использование диска:

Этот вывод показывает нам:

• Файловая система: файловая система, по которой мы составляем отчет.
• 4K-блоки: общее количество блоков размером 4 КБ в этой файловой системе.
• Использовал: сколько блоков 4K используется.
• Имеется в наличии: количество оставшихся блоков по 4 КБ, доступных для использования.
• Использовать%: процент использованных блоков по 4 КБ.
• Установлен на: точка монтирования этой файловой системы.

В нашем примере файловое хранилище (и хранилище индексных дескрипторов и структур каталогов) заняло 28 процентов пространства в этой файловой системе за счет 10 процентов индексов, так что мы в хорошей форме.

Метаданные Inode

Чтобы увидеть номер inode файла, мы можем использовать ls с параметром -i (inode):

Номер inode для этого файла — 1441801, поэтому этот inode содержит метаданные для этого файла и, традиционно, указатели на блоки диска, в которых файл находится на жестком диске. Если файл фрагментирован, очень большой или и то, и другое, некоторые из блоков, на которые указывает индексный дескриптор, могут содержать дополнительные указатели на другие блоки диска. И некоторые из этих других дисковых блоков могут также содержать указатели на другой набор дисковых блоков. Это решает проблему того, что индексный дескриптор имеет фиксированный размер и может содержать конечное число указателей на блоки диска.

Этот метод был заменен новой схемой, в которой используются «экстенты». Они записывают начальный и конечный блоки каждого набора смежных блоков, используемых для хранения файла. Если файл нефрагментирован, вам нужно сохранить только первый блок и длину файла. Если файл фрагментирован, вы должны сохранить первый и последний блок каждой части файла. Этот метод (очевидно) более эффективен.

Если вы хотите узнать, использует ли ваша файловая система указатели или экстенты дисковых блоков, вы можете заглянуть внутрь inode. Для этого воспользуемся командой debugfs с параметром -R (запрос) и передадим ей индексный дескриптор интересующего файла. Это просит debugfs использовать его внутреннюю команду «stat» для отображения содержимого inode. Поскольку номера inode уникальны только в пределах файловой системы, мы также должны указать debugfs файловую систему, в которой находится inode.

Вот как будет выглядеть этот пример команды:

Как показано ниже, команда debugfs извлекает информацию из inode и представляет ее нам в less :

Нам показана следующая информация:

• Inode: номер рассматриваемого inode.
• Тип: это обычный файл, а не каталог или символическая ссылка.
• Режим: права доступа к файлу в восьмеричном формате.
• Флаги: индикаторы, представляющие различные функции или возможности. 0x80000 — это флаг «экстентов» (подробнее об этом ниже).
• Поколение: сетевая файловая система (NFS) использует это, когда кто-то обращается к удаленным файловым системам через сетевое соединение, как если бы они были смонтированы на локальном компьютере. Номера inode и генерации используются как форма дескриптора файла.
• Версия: версия inode.
• Пользователь: владелец файла.
• Группа: групповой владелец файла.
• Проект: всегда должно быть равно нулю.
• Размер: размер файла.
• Файл ACL: список управления доступом к файлам. Они были разработаны, чтобы позволить вам предоставлять контролируемый доступ людям, не входящим в группу владельцев.
• Ссылки: количество жестких ссылок на файл.
• Blockcount: объем места на жестком диске, выделенный для этого файла, выраженный фрагментами по 512 байт. Нашему файлу было выделено восемь из них, что составляет 4096 байт. Итак, наш 98-байтовый файл находится в одном блоке диска размером 4096 байт.
• Фрагмент: этот файл не фрагментирован. (Это устаревший флаг.)
• Ctime: время создания файла.
• Время: время последнего доступа к этому файлу.
• Mtime: время последнего изменения этого файла.
• Crtime: время создания файла.
• Размер дополнительных полей inode: в файловой системе ext4 появилась возможность выделять на диске inode большего размера во время форматирования. Это значение представляет собой количество дополнительных байтов, которые использует индексный дескриптор. Это дополнительное пространство также можно использовать для удовлетворения будущих требований к новым ядрам или для хранения расширенных атрибутов.
• Контрольная сумма inode: контрольная сумма для этого индексного дескриптора, позволяющая определить, поврежден ли индексный дескриптор.
• Экстенты: If extents are being used (on ext4, they are, by default), the metadata regarding the disk block usage of files has two numbers that indicate the start and end blocks of each portion of a fragmented file. This is more efficient than storing every disk block taken up by each portion of a file. We have one extent because our small file sits in one disk block at this block offset.

Где имя файла?

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

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

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

Каталог Inodes

Вы можете увидеть номер inode каталога так же легко, как и для файлов.

В следующем примере мы будем использовать ls с -l (длинный формат), -i (inode) и -d (каталог) и просмотрите каталог work :

Поскольку мы использовали параметр -d (каталог), ls сообщает о самом каталоге, а не о его содержимом. Inode для этого каталога — 1443016.

Чтобы повторить это для каталога home , мы вводим следующее:

Inode для каталога home — 1447510, а каталог work находится в домашнем каталоге. Теперь давайте посмотрим на содержимое каталога work . Вместо параметра -d (каталог) мы будем использовать параметр -a (все). Это покажет нам записи каталога, которые обычно скрыты.

Поскольку мы использовали параметр -a (все), отображаются записи с одинарной (.) И двойной точкой (..). Эти записи представляют сам каталог (одинарная точка) и его родительский каталог (двойная точка).

Если вы посмотрите на номер inode для записи с одной точкой, вы увидите, что это 1443016 — тот же номер inode, который мы получили, когда обнаружили номер inode для каталога work . Кроме того, номер inode для записи с двумя точками совпадает с номером inode для home каталога.

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

Inodes и ссылки

Как мы уже говорили, три компонента должны иметь правильно сформированный и доступный файл в файловой системе: файл, структура каталогов и индексный дескриптор. Файл — это данные, хранящиеся на жестком диске, структура каталогов содержит имя файла и его номер inode, а inode содержит все метаданные для файла.

Символические ссылки — это записи файловой системы, которые выглядят как файлы, но на самом деле это ярлыки, указывающие на существующий файл или каталог. Давайте посмотрим, как им это удается и как для этого используются три элемента.

Допустим, у нас есть каталог с двумя файлами: один — это сценарий, а другой — приложение, как показано ниже.

Мы можем использовать команду ln и параметр -s (символический), чтобы создать мягкую ссылку на файл сценария, например:

Мы создали ссылку на my_script.sh под названием geek.sh . Мы можем ввести следующее и использовать ls для просмотра двух файлов сценариев:

Запись для geek.sh отображается синим цветом. Первым символом флагов разрешений является «l» для ссылки, а -> указывает на my_script.sh . Все это указывает на то, что geek.sh является ссылкой.

Как и следовало ожидать, два файла сценария имеют разные номера inode. Что может быть более удивительным, так это то, что программная ссылка geek.sh не имеет тех же прав пользователя, что и исходный файл сценария. Фактически, разрешения для geek.sh гораздо более либеральны — все пользователи имеют полные разрешения.

Структура каталогов для geek.sh содержит имя ссылки и ее индексный дескриптор. Когда вы пытаетесь использовать ссылку, на ее индексный дескриптор ссылается, как на обычный файл. Inode ссылки будет указывать на блок диска, но вместо данных содержимого файла блок диска содержит имя исходного файла. Файловая система перенаправляет на исходный файл.

Мы удалим исходный файл и посмотрим, что произойдет, если мы введем следующую команду для просмотра содержимого geek.sh :

Символьная ссылка не работает, и перенаправление не выполняется.

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

Чтобы посмотреть inodes для этих двух файлов, мы набираем следующее:

Оба выглядят как обычные файлы. Ничто в geek-app не указывает на то, что это ссылка, как в листинге ls для geek.sh . Кроме того, geek-app имеет те же права пользователя, что и исходный файл. Однако может показаться удивительным то, что оба приложения имеют одинаковый номер inode: 1441797.

Запись в каталоге для geek-app содержит имя «geek-app» и номер inode, но он совпадает с номером inode исходного файла. Итак, у нас есть две записи файловой системы с разными именами, каждая из которых указывает на один и тот же индексный дескриптор. Фактически, любое количество элементов может указывать на один и тот же индексный дескриптор.

Мы введем следующее и воспользуемся программой stat для просмотра целевого файла:

Мы видим, что на этот файл указывают две жесткие ссылки. Это хранится в индексном дескрипторе.

В следующем примере мы удаляем исходный файл и пытаемся использовать ссылку с секретным безопасным паролем:

Удивительно, но приложение работает как положено, но как? Это работает, потому что при удалении файла индексный дескриптор можно использовать повторно. Структура каталогов помечается как имеющая нулевой номер inode, и затем блоки диска становятся доступными для другого файла, который будет сохранен в этом пространстве.

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

Мы введем следующее и снова воспользуемся статистикой — на этот раз в geek-app :

Эти данные извлекаются из того же индексного дескриптора (1441797), что и предыдущая команда stat . Количество ссылок уменьшилось на одну.

Поскольку у нас есть одна жесткая ссылка на этот индекс, если мы удалим geek-app , он действительно удалит файл. Файловая система освободит индексный дескриптор и пометит структуру каталогов нулевым индексом. Затем новый файл может перезаписать хранилище данных на жестком диске.

Накладные расходы Inode

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

• Найдите правильную структуру каталогов
• Прочтите номер inode
• Найдите правильный индексный дескриптор
• Прочтите информацию об индексном дескрипторе
• Следуйте либо по ссылкам inode, либо по экстентам к соответствующим дисковым блокам.
• Прочитать данные файла

Если данные не являются смежными, необходимо еще немного прыгнуть.

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

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

Источник