¿Por qué la tabla de inodo no suele ser redimensionable?

Los sistemas de archivos Unix generalmente tienen una tabla de inodo, y el número de entradas en esta tabla generalmente se fija en el momento en que se crea el sistema de archivos. Esto a veces lleva a las personas con mucho espacio en el disco a recibir mensajes de error confusos sobre la falta de espacio libre, e incluso después de descubrir cuál es el problema, no hay una solución fácil para qué hacer al respecto.

Pero parece (para mí) que sería muy deseable evitar todo este desorden asignando inodos bajo demanda, de forma totalmente transparente a los usuarios y administradores de sistemas. Si te gustan los hacks lindos, incluso podrías hacer que la tabla de inodo sea un archivo, y así reutilizar el código que ya tienes que encuentra espacio libre en el disco. Si tiene suerte, incluso podría terminar con los inodos cerca de los archivos mismos, sin tratar explícitamente de lograr este resultado.

Pero nadie (que yo sepa) realmente hace esto, por lo que probablemente haya una trampa que me estoy perdiendo. ¿Alguna idea de lo que pueda ser?

Digamos que hizo que la tabla de inodo sea un archivo; entonces la siguiente pregunta es ... ¿dónde almacena información sobre ese archivo? Por lo tanto, necesitaría inodes "reales" e inodes "extendidos", como una tabla de particiones de MS-DOS. Dado, solo necesitaría uno (o tal vez algunos, por ejemplo, para que su diario sea un archivo). Pero en realidad tendrías casos especiales, código diferente. Cualquier corrupción en ese archivo también sería desastrosa. Y tenga en cuenta que, antes de escribir en el diario, era común que los archivos se escribieran, por ejemplo, cuando se cortó la electricidad y sufrieron daños graves. Sus operaciones de archivo tendrían que ser mucho más robustas frente a fallas de energía / bloqueo / etc. de lo que estaban, por ejemplo, ext2.

Los sistemas de archivos tradicionales de Unix encontraron una solución más simple (y más robusta): coloque un bloque de inodo (o grupo de bloques) cada bloque X. Luego los encuentras por simple aritmética. Por supuesto, entonces no es posible agregar más (sin reestructurar todo el sistema de archivos). E incluso si pierde / corrompe el bloque de inodo en el que estaba escribiendo cuando falló la alimentación, eso solo está perdiendo unos pocos inodes, mucho mejor que una parte sustancial del sistema de archivos.

Los diseños más modernos usan cosas como las variantes del árbol B. Los sistemas de archivos modernos como btrfs, XFS y ZFS no sufren límites de inodo.

Muchos sistemas de archivos tienen una tabla de inodo asignable dinámicamente (o su equivalente moral) (XFS, BTRFS, ZFS, VxFS ...)

Sin embargo, el Unix UFS original tenía inodos que se arreglaron en el momento de la creación del sistema de archivos y los sistemas de archivos derivados de él (Linux EXT, Solaris UFS) a menudo continuaron el esquema. Es robusto y más sencillo de implementar. Tantos casos de uso encajan bien, que diseñar un nuevo sistema de archivos solo para evitar ese problema no es fácil de justificar.

Hay sistemas de archivos que asignan inodos dinámicamente: fuera de mi cabeza, al menos Veritas VxFS (= el sistema de archivos predeterminado de HP-UX, y una de las opciones disponibles en Solaris) y XFS (el tipo de sistema de archivos estándar en RHEL 7) funcionan de esa manera. Btrfs y JFS de IBM también.