Ниже информация взята со справочной страницы. Я хотел бы узнать разницу между байтами на индекс и размером инода?
-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 на все. Невозможно изменить это значение после создания файловой системы.
Чрезвычайно грубая схема файловой системы:
источник
Мне очень понравился ответ sjas, он дает суть разницы.
Это только мое собственное расширение (так как я не могу комментировать или голосовать, только начиная с этого стека обмена), и я хотел, чтобы ответ для меня был сформулирован сбалансированным образом в нетехнических терминах, понятных для пользователя, который должен принять решение во время объема данных настройка, но не обязательно знать все детали реализации.
Персоны / Объекты: - том (ы) данных в устройствах хранения - файлы в томах (ах) - устройства хранения, они отформатированы и предоставляют блоки байтов и их адреса - расположения файлов в хранилище
Действия: создание / удаление / переименование файлов и папок операционной системой в хранилище, чтение / запись / перемещение файлов, изменение разрешений и т. Д.
Файл размером N байтов необходимо создать в виде «блоков» (блоков). Хотя теоретически можно думать, что файлы могут управляться как последовательности отдельных байтов (по логике, они могут), все, что нам понадобится для управления файлами в пространстве, - это назначенный индекс, сообщающий о некоторых свойствах файла (имя и т. Д.) И о том, где каждый файл начинается в хранение. Однако из-за того, как аппаратное обеспечение спроектировано с использованием «шин» и «блоков» и соображений производительности, эти «куски» имеют определенный размер и кратны размеру блока носителя (например, 512 байт, 4096 байт) и управляется слоем inodes, который сообщает следующему слою о расположении файлов и о том, как фрагменты связаны вместе, когда их нужно найти, загрузить в память и т. д.
Если у кого-то был один большой свиток бумаги (том), и ему нужно было спроектировать хранилище информации для документов, состоящих из страниц (символов или битов информации), для хранения многостраничных документов, то необходим индекс (для поиска документов), место для хранения страницы (с некоторыми простыми позициями страниц). В Unix механизм сортировки (inode) и актуальная нарезка на страницы. inode-size - размер записи индекса (более или менее), байтов на индекс - размер страницы.
Эффекты изменения двух настроек:
изменить размер inode - обычно нет необходимости менять, придерживайтесь значения по умолчанию (согласно ссылке, размещенной в предыдущем ответе на обсуждение)
bytes-per-inode - влияет на максимальное количество файлов, которое можно создать на томе (возможно, на производительность и «потерю» неиспользуемых байтов).
Возвращаясь к аналогии с бумажными рулонами: представьте себе, что вам необходимо написать и сохранить документ определенного размера (файл) в такой системе (или множество документов различного размера) - если размер страницы, который задан во время «записи и хранения» «Определение и не гибкий» - это очень тот же документ, для которого может потребоваться много страниц, если «системный» размер страницы очень большой, а размеры документа небольшие, то большое количество бумаги может быть потрачено впустую из-за наличия пустых страниц и размещения небольших файлов на одной странице. Если размер страницы большой - для документа требуется меньше страниц, но на последней использованной странице может быть много «потерянного пустого пространства». Так что все зависит ... от размера файлов, которые будут использоваться и сколько. Другое соображение - это скорость поиска и доставки документа на многих страницах.
Надеюсь, что это имеет смысл (для меня), и, пожалуйста, прокомментируйте, если я серьезно злоупотребил какой-либо частью ext design или mkfs.
источник