Почему размер таблицы inode обычно нельзя изменить?
Благодаря ответу Стефана Шазела на «Почему существует такая разница во времени выполнения echo и cat?» , ответ муру можно немного улучшить, вызвав cat только один раз (однако эта «небольшая» сумма может стать большой для больших данных и многочисленных итераций цикла; в моей системе этот сценарий занимает ~ 75% времени цикла -сценарий принимает):
#!/bin/sh
yes INPUT.file | head -100 | xargs cat >> OUTPUT.file
Скажем, вы сделали таблицу inode файлом; тогда следующий вопрос... где вы храните информацию об этом файле? Таким образом, вам понадобятся «настоящие» иноды и «расширенные» иноды, такие как таблица разделов MS -DOS. Учитывая, что вам понадобится только один (или, может быть, несколько — например, чтобы ваш журнал также был файлом ). Но на самом деле у вас были бы особые случаи, другой код. Любое повреждение этого файла также будет иметь катастрофические последствия. И учтите, что до ведения журнала это было обычным делом для файлов, которые записывались, например, когда отключалось питание, и они были сильно повреждены. Ваши операции с файлами должны быть намного более надежными, чем сбой питания/сбой/и т.д. чем они были, например, ext2.
Традиционные файловые системы Unix нашли более простое (и более надежное )решение :поместить блок inode (или группу блоков )через каждые X блоков. Затем вы находите их с помощью простой арифметики. Конечно, тогда невозможно добавить больше (без реструктуризации всей файловой системы ). И даже если вы потеряете/испортите блок инодов, в который вы записывали, когда отключилось питание, это потеря всего нескольких инодов — гораздо лучше, чем значительная часть файловой системы.
В более современных проектах используются такие вещи, как B -варианты дерева . Современные файловые системы, такие как btrfs, XFS и ZFS, не страдают от ограничений по индексам.
Многие файловые системы имеют динамически размещаемую таблицу inode (или ее моральный эквивалент)(XFS, BTRFS, ZFS, VxFS...)
Исходная Unix UFS, хотя и имела индексы, которые были зафиксированы во время создания файловой системы, и файловые системы, производные от нее (Linux EXT, Solaris UFS )часто продолжали схему. Он надежный и простой в реализации. Так много вариантов использования хорошо подходят, что разработка новой файловой системы только для того, чтобы избежать этой одной проблемы, нелегко оправдать.
Существуют файловые системы, которые динамически распределяют индексные дескрипторы :с моей головы, по крайней мере, Veritas VxFS (= файловая система по умолчанию для HP -UX, и один из вариантов, доступных на Solaris )и XFS (стандартный тип файловой системы на RHEL 7 )работает таким образом. Btrfs и IBM JFS тоже.