Почему размер таблицы индексов обычно не изменяется?

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

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

Но никто (о котором я знаю) на самом деле не делает этого, так что, вероятно, есть улов, который я пропускаю. Есть идеи, что это может быть?

Скажем, вы сделали таблицу inode файлом; тогда следующий вопрос ... где вы храните информацию об этом файле? Таким образом, вам понадобятся «настоящие» inode и «расширенные» inode, такие как таблица разделов MS-DOS. Учитывая, вам нужен только один (или, может быть, несколько - например, чтобы ваш журнал был файл). Но у вас действительно были бы особые случаи, другой код. Любое повреждение этого файла также будет иметь катастрофические последствия. И учтите, что перед журналированием это было обычным делом для записываемых файлов, например, когда выходило из строя питание, которое было сильно повреждено. Ваши файловые операции должны быть много более надежными, чем сбой питания / сбой / и т.д. чем они были, например, ext2.

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

Более современные дизайны используют такие вещи, как варианты B-дерева . Современные файловые системы, такие как btrfs, XFS и ZFS, не страдают от ограничений inode.

Многие файловые системы имеют динамически размещаемую таблицу inode (или ее моральный эквивалент) (XFS, BTRFS, ZFS, VxFS ...)

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

Существуют файловые системы, которые динамически распределяют inode: по крайней мере Veritas VxFS (= файловая система по умолчанию HP-UX и один из вариантов, доступных в Solaris) и XFS (стандартный тип файловой системы в RHEL 7) работают сюда. Btrfs и IBM JFS тоже.