Чому таблиця inode зазвичай не змінюється?

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

Але мені здається, що дуже хотілося б уникнути цілого безладу, розподіляючи нутри на вимогу, повністю прозоро для користувачів та системних адміністраторів. Якщо ви потрапляєте в симпатичні хаки, ви навіть можете зробити таблицю inode самим файлом і, таким чином, повторно використати вже наявний у вас код, який знайде вільний простір на диску. Якщо вам пощастить, ви, можливо, навіть укладете вкладені файли біля самих файлів, не намагаючись явно досягти цього результату.

Але ніхто (що я знаю) насправді цього не робить, тому, мабуть, є улов, якого я пропускаю. Будь-яка ідея, що це може бути?

Скажіть, ви зробили таблицю inode файлом; то наступне питання - де ви зберігаєте інформацію про цей файл? Таким чином, вам знадобляться "справжні" входи та "розширені" входи, як таблиця розділів MS-DOS. Враховуючи, вам знадобиться лише одне (а може бути декілька - наприклад, щоб ваш журнал також був файлом). Але у вас насправді є спеціальні випадки, інший код. Будь-яке пошкодження цього файлу теж було б згубним. І врахуйте, що до журналу це було звичайним для файлів, які писалися, наприклад, коли потужність сильно пошкодилася. Ваші файлові операції повинні бути набагато більш надійними, порівняно з відключенням електроенергії / збоєм / тощо. ніж вони були, наприклад, ext2.

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

Більш сучасні конструкції використовують такі речі, як варіанти B-дерева . Сучасні файлові системи, такі як btrfs, XFS та ZFS, не страждають від обмежень inode.

Багато файлових систем мають динамічно розподілену таблицю inode (або її моральний еквівалент) (XFS, BTRFS, ZFS, VxFS ...)

Оригінальний Unix UFS, хоча мав іноди, які були зафіксовані на час створення файлової системи, і файлові системи, отримані з неї (Linux EXT, Solaris UFS), часто продовжували схему. Це надійний і простіший в реалізації. Тож багато випадків використання добре підходять, що розробка нової файлової системи просто для того, щоб уникнути однієї проблеми непросто виправдати.

Є файлові системи, які динамічно виділяють вставки: працюють вгорі голови, принаймні, Veritas VxFS (= файлова система HP-UX за замовчуванням, і один із варіантів, доступних у Solaris) та XFS (стандартний тип файлової системи в RHEL 7) цей шлях. Btrfs та JFS IBM також.