В чем разница между «размером инода» и «байтами на инод»

Ниже информация взята со справочной страницы. Я хотел бы узнать разницу между байтами на индекс и размером инода?

-i bytes-per-inode

Укажите соотношение байт / индекс. mke2fs создает индекс для каждого байта на индекс байтов пространства на диске. Чем больше отношение байтов к индексу, тем меньше будет создано инодов. Как правило, это значение не должно быть меньше размера блока файловой системы, так как в этом случае будет создано слишком много inode. Будьте предупреждены, что невозможно увеличить число inode в файловой системе после ее создания, поэтому будьте осторожны при выборе правильного значение для этого параметра.

-I inode-size

Укажите размер каждого inode в bytes.mke2fs создает 256-байтовые inode по умолчанию. В ядрах после 2.6.10 и некоторых ядрах более ранних производителей можно использовать иноды размером более 128 байт для хранения расширенных атрибутов для повышения производительности. Значение размера инода должно быть степенью 2, большей или равной 128. Чем больше индекс -size, чем больше места будет занимать таблица inode, и это уменьшает используемое пространство в файловой системе и может также негативно повлиять на производительность. Расширенные атрибуты, хранящиеся в больших inode, не видны в старых ядрах, и такие файловые системы не будут монтироваться с ядрами 2.4 на все. Невозможно изменить это значение после создания файловой системы.

Ну, во-первых, что такое инод? В мире Unix, inode - это вид записи файла. Имя файла в каталоге - это просто метка (ссылка!) На индекс. На индекс можно ссылаться в нескольких местах (жесткие ссылки!).

-i байт-на-индекс (он же inode_ratio)

По какой-то неизвестной причине этот параметр иногда документируется как bytes-per-inode, а иногда как inode_ratio . Согласно документации это соотношение байтов к индоду . У большинства людей будет лучшее понимание, если они указаны как (извините за мой английский):

• 1 индекс на каждые байты Х (где Х - байты на индекс).
• самый низкий средний размер файла, который вы можете подогнать.

Формула (взята из mke2fs исходного кода ):

inode_count = (blocks_count * blocksize) / inode_ratio

Или даже упрощенный (предполагая, что «размер раздела» примерно эквивалентен blocks_count * blocksize, я не проверял распределение):

inode_count = (partition_size_in_bytes) / inode_ratio

Примечание 1: Даже если вы указали фиксированное количество inode во время создания FS ( mkfs -N ...), значение преобразуется в соотношение, так что вы можете разместить больше inode по мере увеличения размера файловой системы.

Примечание 2: если вы настроите это соотношение, убедитесь, что выделите значительно больше inode, чем вы планируете использовать ... вы действительно не хотите переформатировать свою файловую систему.

-Я размер inode

Это число байтов, которое файловая система будет выделять / резервировать для каждого inode, который может иметь файловая система. Пространство используется для хранения атрибутов inode (прочитайте Intro to Inodes ). В Ext3 размер по умолчанию был 128. В Ext4 размер по умолчанию равен 256 (для хранения extra_isizeи предоставления пространства для встроенных расширенных атрибутов). читать Linux: зачем менять размер inode?

Примечание: X байтов дискового пространства выделяется для каждого выделенного inode, независимо от того, свободен он или используется, где X = размер inode.

bytes-per-inode определяет, сколько inode создается для этой файловой системы; Размер inode определяет размер каждого из этих inode.

Вам нужно много inode, если вы хотите поместить множество маленьких файлов (и / или много каталогов) в файловую систему.

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

Чрезвычайно грубая схема файловой системы:

|_|__inodes__|_______________________DATA_________________________________|

• инф.узлы-соотношение / байты-за индексный дескриптор = количество дескрипторов для DATA области
• инф.узлов размер = размер каждого индексного дескриптора в Inodes области

Мне очень понравился ответ sjas, он дает суть разницы.

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

Персоны / Объекты: - том (ы) данных в устройствах хранения - файлы в томах (ах) - устройства хранения, они отформатированы и предоставляют блоки байтов и их адреса - расположения файлов в хранилище

Действия: создание / удаление / переименование файлов и папок операционной системой в хранилище, чтение / запись / перемещение файлов, изменение разрешений и т. Д.

Файл размером N байтов необходимо создать в виде «блоков» (блоков). Хотя теоретически можно думать, что файлы могут управляться как последовательности отдельных байтов (по логике, они могут), все, что нам понадобится для управления файлами в пространстве, - это назначенный индекс, сообщающий о некоторых свойствах файла (имя и т. Д.) И о том, где каждый файл начинается в хранение. Однако из-за того, как аппаратное обеспечение спроектировано с использованием «шин» и «блоков» и соображений производительности, эти «куски» имеют определенный размер и кратны размеру блока носителя (например, 512 байт, 4096 байт) и управляется слоем inodes, который сообщает следующему слою о расположении файлов и о том, как фрагменты связаны вместе, когда их нужно найти, загрузить в память и т. д.

Если у кого-то был один большой свиток бумаги (том), и ему нужно было спроектировать хранилище информации для документов, состоящих из страниц (символов или битов информации), для хранения многостраничных документов, то необходим индекс (для поиска документов), место для хранения страницы (с некоторыми простыми позициями страниц). В Unix механизм сортировки (inode) и актуальная нарезка на страницы. inode-size - размер записи индекса (более или менее), байтов на индекс - размер страницы.

Эффекты изменения двух настроек:

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

bytes-per-inode - влияет на максимальное количество файлов, которое можно создать на томе (возможно, на производительность и «потерю» неиспользуемых байтов).

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

Надеюсь, что это имеет смысл (для меня), и, пожалуйста, прокомментируйте, если я серьезно злоупотребил какой-либо частью ext design или mkfs.