Яка різниця між "розміром inode" та "Bytes per inode"

Нижче інформація взята зі сторінки man, я хотів би знати різницю між байтами на один inode та розміром Inode?

-i bytes-per-inode

Вкажіть співвідношення байтів / inode. mke2fs створює inode для кожного байта на кожен байт простору на диску. Чим більше співвідношення байтів на ввід, тим менше буде створено кількість входів. Це значення, як правило, не повинно бути меншим за розмір файлової системи, оскільки тоді буде зроблено занадто багато індексів. Попереджуйте, що не можна розширювати кількість входів у файловій системі після її створення, тому будьте уважні, вирішивши правильність значення для цього параметра.

-I inode-size

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

Ну, по-перше, що таке індеда? У світі Unix inode - це своєрідний запис файлу. Ім'я файлу в каталозі - це лише мітка (посилання!) На inode. На індед можна посилатися в декількох місцях (жорсткі посилання!).

-i bytes-per-inode (він же inode_ratio)

З незрозумілої причини цей параметр колись задокументований як байти за вхід, а колись як inode_ratio . Згідно з документацією, це співвідношення байтів / inode . Більшість людей матиме краще розуміння, коли це буде зазначено як (вибачте мою англійську):

• 1 inode на кожен X байт пам’яті (де X - байти на ввід).
• найменший середній розмір файлів, який ви можете помістити.

Формула (взята з 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 (читайте Intro to Inodes ). У Ext3 розмір за замовчуванням становив 128. У Ext4 розмір за замовчуванням - 256 (для зберігання extra_isizeта надання місця для вбудованих розширених атрибутів). читати Linux: Навіщо змінювати розмір inode?

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

bytes-per-inode визначає, скільки inode створено для цієї файлової системи; inode-size визначає, наскільки велика кожна з цих inode.

Вам потрібно багато вкладень, якщо ви збираєтесь помістити у файл файлу багато невеликих файлів (& / або безліч каталогів).

AFAIK, вам справді потрібні лише вставки, розмір яких більший за розмір за замовчуванням 256 байт, якщо ви хочете зберігати розширені атрибути для своїх файлів. psusi в коментарях каже, що це не правильно.

Надзвичайно груба схема файлової системи:

|_|__inodes__|_______________________DATA_________________________________|

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

Мені дуже сподобалась відповідь sjas, вона дає суть різниці.

Це лише моє власне розширення (оскільки я не можу коментувати чи голосувати, тільки починаючи з цієї стак-обміну), і я хотів відповіді для себе, викладеної збалансовано в нетехнічних умовах, зрозумілою для користувача, який повинен приймати рішення під час обсягу даних. налаштування, але не обов’язково знати всі деталі, що стоять за реалізацією.

Персонали / Об'єкти: - об'єм (и) даних у пристроях зберігання даних - файли в томах (іх) - пристрої зберігання даних, вони форматовані та надають блоки байтів та їх адреси - розташування файлів у сховищі

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

Файл розміром з N байтів потрібно створити в "шматках" (блоках). Хоча теоретично можна думати, що файлами можна керувати як послідовності одиничних байтів (логічно, що вони можуть), все, що нам знадобиться для управління файлами в просторі, - це позначений індекс, який повідомляє про деякі властивості файлу (ім'я тощо) і де кожен файл починається в сховище. Однак із-за способу побудови апаратного забезпечення з "шинами" та "блоками" та міркувань щодо продуктивності, ці "шматки" мають певний розмір і кратні розміру блоку медіа (наприклад, 512 байт, 4096 байт) і є керується шаром inodes, який повідомляє наступному шару про розташування файлів та про те, як шматки з'єднуються, коли їх потрібно знайти, завантажити в пам'ять тощо.

Якщо у вас було одне велике прокручування паперу (об'єм) і довелося спроектувати сховище інформації для документів зі сторінок (символів або біт інформації) для зберігання багатосторінкових документів, необхідним є індекс (для пошуку документів), місце для зберігання сторінки (з простими положеннями сторінок). У механізмі зіставлення Unix (inodes) та фактичному розкроюванні сторінок. inode-size - це розмір вводу індексу (більше або менше) байтів на індез - це розмір сторінки

Ефекти зміни двох розглянутих налаштувань:

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

bytes-per-inode - впливає на максимальну кількість файлів, які можна створити в томі (можливо, продуктивність та "витрата" невикористаних байтів)

Повернення до аналогії рулону паперу: Уявіть, що потрібно писати та зберігати документ певного розміру (файл) у такій системі (або багато документів різного розміру) - якщо розмір сторінки, який передбачено під час "системи запису та зберігання" "визначення і не є гнучким, дуже один і той же документ може зажадати багатьох сторінок, якщо" системний "розмір сторінки дуже великий, а розмір документа невеликий, тоді багато паперу потенційно може бути витрачено за рахунок заготовок і розміщення невеликих файлів на одній сторінці. Якщо розмір сторінки великий - є менше сторінок, які потрібно використовувати для документа, але на останній використаній сторінці може бути багато "витраченого порожнього місця". Отже, все залежить ... від розміру файлів, які будуть використовуватися, і скільки. Інша думка - швидкість пошуку та отримання документа на багатьох сторінках.

Сподіваюся, це має сенс (це для мене), і, будь ласка, прокоментуйте, якщо я серйозно зловживав будь-якою частиною варіантів дизайну ext або mkfs.