El inodo (nodo índice) es una estructura de datos en un sistema de archivos de estilo Unix que describe un objeto del sistema de archivos, como un archivo o un directorio . Cada inodo almacena los atributos y las ubicaciones de los bloques de disco de los datos del objeto. [1] Los atributos de los objetos del sistema de archivos pueden incluir metadatos (horas del último cambio, [2] acceso, modificación), así como datos del propietario y de los permisos . [3]
Un directorio es una lista de inodos con sus nombres asignados. La lista incluye una entrada para sí misma, su padre y cada uno de sus hijos.
En la lista de correo del kernel de Linux ha habido incertidumbre sobre el motivo de la "i" en "inode". En 2002, se le planteó la cuestión al pionero de Unix, Dennis Ritchie , quien respondió: [4]
En realidad, yo tampoco lo sé. Era simplemente un término que empezamos a utilizar. "Índice" es mi mejor suposición, debido a la estructura ligeramente inusual del sistema de archivos que almacenaba la información de acceso a los archivos como una matriz plana en el disco, con toda la información jerárquica del directorio viviendo aparte de esto. Por lo tanto, el i-número es un índice en esta matriz, el i-nodo es el elemento seleccionado de la matriz. (La notación "i-" se utilizó en el manual de la primera edición; su guión se eliminó gradualmente).
Un artículo de 1978 de Ritchie y Ken Thompson refuerza la idea de que el "índice" es el origen etimológico de los inodos. Escribieron: [5]
[…] una entrada de directorio contiene únicamente un nombre para el archivo asociado y un puntero al archivo mismo. Este puntero es un entero llamado i-number (por número de índice) del archivo. Cuando se accede al archivo, su i-number se utiliza como índice en una tabla del sistema (la i-list ) almacenada en una parte conocida del dispositivo en el que reside el directorio. La entrada encontrada de esta manera (el i-nodo del archivo ) contiene la descripción del archivo.
Además, Maurice J. Bach escribió que la palabra inodo "es una contracción del término nodo de índice y se utiliza comúnmente en la literatura sobre el sistema UNIX". [6]
Un sistema de archivos se basa en estructuras de datos sobre los archivos, en lugar de en el contenido de esos archivos. Las primeras se denominan metadatos , es decir , datos que describen los datos. Cada archivo está asociado a un inodo , que se identifica mediante un número entero, a menudo denominado i-number o número de inodo .
Los inodos almacenan información sobre archivos y directorios (carpetas), como la propiedad del archivo, el modo de acceso (permisos de lectura, escritura y ejecución) y el tipo de archivo. Los datos pueden denominarse datos estadísticos, en referencia a la stat llamada del sistema que proporciona los datos a los programas.
El número de inodo indexa una tabla de inodos en el sistema de archivos. A partir del número de inodo, el controlador del sistema de archivos del núcleo puede acceder al contenido del inodo, incluida la ubicación del archivo, lo que permite el acceso al archivo. El número de inodo de un archivo se puede encontrar mediante el ls -icomando. El ls -icomando imprime el número de inodo en la primera columna del informe.
En muchos sistemas de archivos antiguos, los inodos se almacenan en una o más áreas de tamaño fijo que se configuran en el momento de la creación del sistema de archivos, por lo que la cantidad máxima de inodos se fija en el momento de la creación del sistema de archivos, lo que limita la cantidad máxima de archivos que el sistema de archivos puede contener. Una heurística de asignación típica para los inodos en un sistema de archivos es un inodo por cada 2K bytes contenidos en el sistema de archivos. [8]
Algunos sistemas de archivos de estilo Unix, como JFS , XFS , ZFS , OpenZFS , ReiserFS , btrfs y APFS, omiten una tabla de inodos de tamaño fijo, pero deben almacenar datos equivalentes para proporcionar capacidades equivalentes. Las alternativas comunes a la tabla de tamaño fijo incluyen árboles B y árboles B+ derivados .
Nombres de archivos e implicaciones de directorio:
La representación de estos datos en la memoria del núcleo del sistema operativo se denomina struct inodeen Linux . Los sistemas derivados de BSD utilizan el término (la "v" se refiere a la capa del sistema de archivos virtualvnode del núcleo ).
El estándar POSIX establece un comportamiento del sistema de archivos que está fuertemente influenciado por los sistemas de archivos UNIX tradicionales . Un inodo se denota con la frase "número de serie de archivo", definida como un identificador único para cada sistema de archivos. [9] Ese número de serie de archivo, junto con el ID del dispositivo que contiene el archivo, identifican de forma única el archivo dentro de todo el sistema. [10]
Dentro de un sistema POSIX, un archivo tiene los siguientes atributos [10] que pueden recuperarse mediante la statllamada al sistema:
Los sistemas de archivos diseñados con inodos tendrán las siguientes características administrativas:
Los archivos pueden tener varios nombres. Si varios nombres se vinculan directamente al mismo inodo, entonces los nombres son equivalentes; es decir, el primero que se crea no tiene un estatus especial. Esto es diferente a los enlaces simbólicos , que dependen del nombre original, no del inodo (número).
Un inodo puede no tener enlaces. Un inodo sin enlaces representa un archivo sin entradas de directorio restantes ni rutas que conduzcan a él en el sistema de archivos. Un archivo que ha sido eliminado o que carece de entradas de directorio que lo apunten se denomina archivo "sin enlaces".
Estos archivos se eliminan del sistema de archivos, liberando el espacio en disco ocupado para su reutilización. Un inodo sin vínculos permanece en el sistema de archivos hasta que se desasignen los recursos (espacio en disco y bloques) liberados por el archivo sin vínculos o se modifique el sistema de archivos.
Aunque un archivo no vinculado se vuelve invisible en el sistema de archivos, su eliminación se pospone hasta que todos los procesos con acceso al archivo hayan terminado de usarlo, incluidos los archivos ejecutables que implícitamente se mantienen abiertos por los procesos que los ejecutan.
Normalmente no es posible realizar una asignación de un archivo abierto al nombre de archivo que se utilizó para abrirlo. Cuando un programa abre un archivo, el sistema operativo convierte el nombre de archivo en un número de inodo y luego descarta el nombre de archivo. Como resultado, funciones como getcwd() y getwd() que recuperan el directorio de trabajo actual del proceso no pueden acceder directamente al nombre de archivo.
Comenzando con el directorio actual, estas funciones buscan hasta su directorio padre , luego hasta el directorio padre del padre, y así sucesivamente, hasta llegar al directorio raíz . En cada nivel, la función busca una entrada de directorio cuyo inodo coincida con el del directorio desde el que acaba de moverse hacia arriba. Debido a que el inodo del directorio hijo todavía existe como una entrada en su directorio padre , permite que la función reconstruya la ruta absoluta del directorio de trabajo actual .
Algunos sistemas operativos mantienen información adicional para que esta operación se ejecute más rápido. Por ejemplo, en el VFS de Linux , [11] la caché de entradas de directorio, [12] también conocida como dentry o dcache, son entradas de caché que utiliza el núcleo para acelerar las operaciones del sistema de archivos almacenando información sobre los enlaces de directorio en la RAM .
Históricamente, era posible crear enlaces duros entre directorios. Esto hacía que la estructura del directorio fuera un grafo dirigido arbitrario, al contrario de un grafo acíclico dirigido . Incluso era posible que un directorio fuera su propio padre. Los sistemas modernos generalmente prohíben este estado confuso, excepto que el padre de la raíz todavía se define como raíz. La excepción más notable a esta prohibición se encuentra en Mac OS X (versiones 10.5 y superiores), que permite que el superusuario cree enlaces duros entre directorios. [13]
Cuando un archivo se reubica en un directorio diferente en el mismo sistema de archivos, o cuando una desfragmentación de disco altera su ubicación física, el número de inodo del archivo permanece sin cambios.
Esta característica única permite mover o renombrar el archivo incluso durante operaciones de lectura o escritura, lo que garantiza un acceso continuo sin interrupciones.
Esta característica (que los metadatos y las ubicaciones de los bloques de datos de un archivo persistan en una estructura de datos central , independientemente de que se cambie el nombre o se mueva el archivo) no se puede replicar por completo en muchos sistemas de archivos que no son Unix, como FAT y sus derivados, ya que carecen de un mecanismo para mantener esta propiedad invariable cuando tanto la entrada de directorio del archivo como sus datos se reubican simultáneamente. En estos sistemas de archivos, mover o cambiar el nombre de un archivo puede provocar cambios más significativos en la estructura de datos que representa el archivo, y el sistema no mantiene un registro central separado de las ubicaciones de los bloques de datos y los metadatos del archivo como lo hacen los inodos en los sistemas tipo Unix .
Los sistemas de archivos inodo permiten que un proceso en ejecución continúe accediendo a un archivo de biblioteca incluso cuando otro proceso esté reemplazando ese mismo archivo.
Esta operación debe realizarse de forma atómica , lo que significa que debe aparecer como una única operación que se completa totalmente o no se realiza en absoluto, sin ningún estado intermedio visible para otros procesos.
Durante el reemplazo , se crea un nuevo inodo para el nuevo archivo de biblioteca , lo que establece una asignación completamente nueva. Posteriormente, las futuras solicitudes de acceso para esa biblioteca recuperarán la versión recién instalada.
Cuando el sistema operativo reemplaza el archivo (y crea un nuevo inodo), coloca un bloqueo [14] en el inodo [15] y posiblemente en el directorio que lo contiene. [16] Esto evita que otros procesos lean o escriban en el archivo (inodo) [17] durante la operación de actualización, evitando así la inconsistencia o corrupción de los datos. [18]
Una vez que se completa la operación de actualización, se libera el bloqueo. Cualquier acceso posterior al archivo (a través del inodo) por parte de cualquier proceso apuntará a la nueva versión de la biblioteca. De esta manera, es posible realizar actualizaciones incluso cuando la biblioteca está siendo utilizada por otro proceso.
Una ventaja importante de este mecanismo es que elimina la necesidad de reiniciar el sistema para reemplazar las bibliotecas que se encuentran en uso. En consecuencia, los sistemas pueden actualizar o mejorar las bibliotecas de software sin problemas y sin interrumpir los procesos o las operaciones en ejecución.
Cuando se crea un sistema de archivos, algunos sistemas de archivos asignan una cantidad fija de inodos. [19] Esto significa que es posible quedarse sin inodos en un sistema de archivos, incluso si queda espacio libre en el sistema de archivos. Esta situación suele surgir en casos de uso en los que hay muchos archivos pequeños, como en un servidor que almacena mensajes de correo electrónico, porque cada archivo, sin importar lo pequeño que sea, requiere su propio inodo.
Otros sistemas de archivos evitan esta limitación mediante la asignación dinámica de inodos. [20] La asignación dinámica de inodos permite que un sistema de archivos cree más inodos según sea necesario en lugar de depender de un número fijo creado en el momento de la creación del sistema de archivos. [21] Esto puede "hacer crecer" el sistema de archivos al aumentar la cantidad de inodos disponibles para nuevos archivos y directorios, evitando así el problema de quedarse sin inodos. [22]
Puede tener sentido almacenar archivos muy pequeños en el propio inodo para ahorrar espacio (no se necesita ningún bloque de datos) y tiempo de búsqueda (no se necesita ningún otro acceso al disco). Esta característica del sistema de archivos se denomina inlining. Por lo tanto, ya no se puede dar por sentado que los datos del inodo y del archivo están estrictamente separados cuando se utilizan sistemas de archivos modernos.
Si los datos de un archivo caben en el espacio asignado para los punteros a los datos, este espacio se puede utilizar de forma conveniente. Por ejemplo, ext2 y sus sucesores almacenan los datos de los enlaces simbólicos (normalmente nombres de archivos) de esta forma si los datos no superan los 60 bytes ("enlaces simbólicos rápidos"). [23]
Ext4 tiene una opción de sistema de archivos llamada inline_dataque permite que ext4 realice la inserción en línea si se habilita durante la creación del sistema de archivos. Debido a que el tamaño de un inodo es limitado, esto solo funciona para archivos muy pequeños. [24]
{{cite web}}: CS1 maint: URL no apta ( enlace ){{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )