Inodo

Ken Thompson y Dennis Ritchie fueron los principales creadores de la idea.^[1]​ No existe una explicación clara para la denominación "inodo". Dennis Ritchie lo explicó así:

Realmente, tampoco lo sé. Era simplemente el nombre que comenzamos a utilizar. "Índice" es lo mejor que se me ocurre, debido a la estructura algo inusual de un sistema de ficheros que almacenaba la información del acceso a los archivos como una lista plana en disco, dejando al margen toda la información jerárquica de los directorios. Así el número "i'" es un índice sobre la lista, el nodo "i" es el elemento seleccionado de la lista. (En la primera edición del manual se empleó la notación "i-nodo"; el guion fue desapareciendo poco a poco).

El estándar POSIX establece un modelo de sistema de archivos que se ajusta al empleado en los UNIX tradicionales. Un archivo ordinario tendrá las propiedades siguientes:

• El identificador de dispositivo del dispositivo que alberga al sistema de archivos.
• El número de inodo que identifica al archivo dentro del sistema de archivos
• La longitud del archivo en bytes.
• El identificador de usuario del creador o un propietario del archivo con derechos diferenciados
• El identificador de grupo de un grupo de usuarios con derechos diferenciados
• El modo de acceso: capacidad de leer, escribir, y ejecutar el archivo por parte del propietario, del grupo y de otros usuarios.
• Las marcas de tiempo con las fechas de última modificación (mtime), acceso (atime) y de alteración del propio inodo (ctime).
• El número de enlaces, esto es, el número de nombres (entradas de directorio) asociados con este inodo. El número de enlaces se emplea por el sistema operativo para eliminar el archivo del sistema de ficheros, tanto el inodo como el contenido, cuando se han borrado todos los enlaces y el contador queda a cero.
• La estructura de punteros, para direccionar hacia los bloques de datos (contenido) del archivo. Está compuesta por:
  • Doce punteros que apuntan directamente a bloques de datos del archivo (punteros directos)
  • Un puntero de indirección simple (apunta a un bloque de punteros, los cuales apuntan a bloques de datos del archivo)
  • Un puntero de indirección doble (apunta a un bloque de punteros, los cuales apuntan a otros bloques de punteros, estos últimos apuntan a bloques de datos del archivo)
  • Un puntero de indirección triple (apunta a un bloque de punteros que apuntan a otros bloques de punteros que apuntan a otros bloques de punteros que luego apuntan a bloques de datos del archivo)

 

El trabajar sobre un sistema de ficheros basado en inodos resulta al principio deslumbrante para usuarios que no están habituados a él:

• Si múltiples nombres están enlazados, o sea, asociados a un mismo inodo (lo que se denomina enlaces duros o simplemente enlaces) entonces todos los nombres son equivalentes entre sí. El que fue creado en primer lugar no tiene ningún estatus especial, al contrario de lo que ocurre con los enlaces simbólicos o con los denominados accesos directos donde todos dependen del nombre original.

• Un inodo puede incluso no tener ningún enlace. Tal archivo sería eliminado del disco y sus recursos liberados para ser reasignados (el proceso normal de suprimir un archivo); pero, si algún proceso estuviera accediendo al archivo, puede seguir haciéndolo, y el archivo sólo será finalmente suprimido cuando la última referencia a él quede completamente cerrada. Esto afecta también a los archivos ejecutables, que de forma implícita permanecen abiertos por los procesos que los ejecutan. Por esta razón, cuando se actualiza un programa, se recomienda suprimir primero el viejo ejecutable y crear a continuación un nuevo archivo y un nuevo inodo para la versión actualizada, de modo que si la versión anterior estaba en ejecución en ese instante, pueda mantenerse temporalmente el archivo y continuar funcionando sin problemas.

• Tradicionalmente, no era posible identificar un archivo abierto con el nombre de archivo que fue utilizado para abrirlo. El sistema operativo convertiría inmediatamente el nombre a un número de inodo y prescindiría del nombre. Eso implica que funciones de librería como getcwd() y del getwd() tendrían que husmear en los archivos de tipo directorio hasta localizar el número de inodo. Los sistemas SVR4 y Linux conservan información adicional para evitar esta dificultad.

• Tradicionalmente, era posible hacer enlaces (enlaces duros) a directorios. Esto hacía que la estructura de directorios fuera un grafo dirigido en vez de un árbol. Se podía dar la paradoja de que un directorio fuera su propio padre. Los sistemas modernos prohíben generalmente este estado confuso.

 

 

Para ilustrar los conceptos de inodo y enlaces, tanto normales como simbólicos, en la figura se muestra la creación de un archivo de texto de 4 bytes (3 caracteres más el carácter de finalización de fichero) con el comando echo. Luego se crea un enlace "duro" con el comando ln y además un enlace simbólico por medio del parámetro -s. Nótese que en el primer enlace creado el valor del inode no varía mientras que para el segundo enlace sí. Además, al agregar datos al archivo de texto su tamaño varía mas sin embargo en el enlace simbólico no, pues su tamaño es siempre el mismo y viene dado por la cantidad de caracteres en el nombre enlazado ("archivo1.txt" son doce caracteres, doce bytes). En el siguiente ejemplo gráfico se puede corroborar la anterior afirmación.

Sistemas de archivos actuales, como por ejemplo ReiserFS, pueden evitar tener una tabla de inodos en el sentido tradicional, pero deben implementar mecanismos que reproduzcan externamente toda la funcionalidad de los inodos.

Los datos sobre el archivo contenidos en el inodo se pueden consultar desde un programa por medio de la llamada al sistema stat. En sistemas Linux la información queda recogida en una estructura de C del tipo struct inode, definido en el archivo de cabecera linux/fs.h.

Los sistemas derivados de BSD utilizan la denominación vnode; con la "v" en referencia al sistema de ficheros "virtual" que el núcleo del sistema operativo mantiene en memoria.

En muchos programas empleados por los administradores de sistemas UNIX se trabaja con los números de inodo para identificar archivos; es el caso de fsck o pfiles. Se presenta así la necesidad de traducir números de inodo en rutas y nombres de archivo y viceversa. Esto se consigue con la utilidad find empleando la opción -inum o con el propio ls y la opción apropiada que en muchas plataformas es -i.

• Como limpiar memoria cache, inodes y dentries
• «The Linux Virtual File-system Layer: Inodes and Operations] - Inodos en [[Linux]] (en inglés)». Archivado desde el original el 19 de diciembre de 2008. Consultado el 1 de marzo de 2006.