El inodo (nodo de índice) es una estructura de datos en un sistema de archivos 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.
Etimología
Ha habido incertidumbre en la lista de correo del kernel de Linux sobre el motivo de la "i" en "inodo". En 2002, se planteó la pregunta al pionero de Unix Dennis Ritchie , quien respondió: [4]
En verdad, yo tampoco lo sé. Fue solo un término que comenzamos a usar. "Index" es mi mejor conjetura, debido a la estructura del sistema de archivos ligeramente inusual que almacenaba la información de acceso de los archivos como una matriz plana en el disco, con toda la información del directorio jerárquico viviendo aparte de esto. Por lo tanto, el número i es un índice en esta matriz, el nodo i es el elemento seleccionado de la matriz. (La notación "i-" se utilizó en la primera edición del manual; su guión se eliminó gradualmente).
Un artículo de 1978 de Ritchie y Ken Thompson refuerza la noción de que "índice" es el origen etimológico de los inodos. Escribieron: [5]
[…] Una entrada de directorio contiene solo un nombre para el archivo asociado y un puntero al archivo en sí. Este puntero es un número entero llamado i-number (para el número de índice) del archivo. Cuando se accede al archivo, su número i se utiliza como índice en una tabla del sistema (la lista i ) almacenada en una parte conocida del dispositivo en el que reside el directorio. La entrada que se encuentra de este modo (el i-nodo del archivo ) contiene la descripción del archivo.
Además, Maurice J. Bach escribió que un inodo "es una contracción del término nodo índice y se usa comúnmente en la literatura sobre el sistema UNIX". [6]
Detalles
Un sistema de archivos se basa en estructuras de datos sobre los archivos, a diferencia del contenido de ese archivo. Los primeros se denominan metadatos: datos que describen datos. Cada archivo está asociado con un inodo , que se identifica con un número entero, a menudo denominado número i o número de inodo .
Los inodos almacenan información sobre archivos y directorios (carpetas), como la propiedad del archivo, el modo de acceso (leer, escribir, ejecutar permisos) y el tipo de archivo. En muchas implementaciones de sistemas de archivos más antiguas, el número máximo de inodos se fija en la creación del sistema de archivos, lo que limita el número máximo de archivos que el sistema de archivos puede contener. Una heurística de asignación típica para inodos en un sistema de archivos es un inodo por cada 2K bytes contenidos en el sistema de archivos. [8]
El número de inodo indexa una tabla de inodos en una ubicación conocida en el dispositivo. Desde el número de inodo, el controlador del sistema de archivos del kernel 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 usando el ls -i
comando. El ls -i
comando imprime el número de i-nodo en la primera columna del informe.
Algunos sistemas de archivos de estilo Unix como ReiserFS , btrfs y APFS omiten una tabla de inodo de tamaño fijo, pero deben almacenar datos equivalentes para proporcionar capacidades equivalentes. Los datos pueden denominarse datos estadísticos, en referencia a la stat
llamada al sistema que proporciona los datos a los programas. Las alternativas comunes a la tabla de tamaño fijo incluyen árboles B y los árboles B + derivados .
Nombres de archivo e implicaciones de directorio:
- Los inodos no contienen sus nombres de enlaces físicos, solo otros metadatos de archivos.
- Los directorios Unix son listas de estructuras de asociación, cada una de las cuales contiene un nombre de archivo y un número de inodo.
- El controlador del sistema de archivos debe buscar un directorio buscando un nombre de archivo en particular y luego convertir el nombre de archivo al número de inodo correspondiente correcto.
La representación en memoria del kernel del sistema operativo de estos datos se llama struct inode
en Linux . Los sistemas derivados de BSD utilizan el término vnode
(la "v" se refiere a la capa del sistema de archivos virtual del kernel ).
Descripción del inodo POSIX
El estándar POSIX exige un comportamiento del sistema de archivos que está fuertemente influenciado por los sistemas de archivos tradicionales de UNIX . Un inodo se denota con la frase "número de serie del archivo", definido como un identificador único del sistema por archivo para un archivo. [9] Ese número de serie del archivo, junto con el ID de dispositivo del dispositivo que contiene el archivo, identifica 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 ser recuperados por la stat
llamada al sistema:
- ID de dispositivo (esto identifica el dispositivo que contiene el archivo; es decir, el alcance de la unicidad del número de serie).
- Números de serie de archivos.
- El modo de archivo que determina el tipo de archivo y cómo el propietario del archivo, su grupo y otros pueden acceder al archivo.
- Un recuento de enlaces que indica cuántos enlaces duros apuntan al inodo.
- El ID de usuario del propietario del archivo.
- El ID de grupo del archivo.
- El ID de dispositivo del archivo si es un archivo de dispositivo .
- El tamaño del archivo en bytes .
- Marcas de tiempo que indican cuándo se modificó por última vez el inodo ( ctime , hora de cambio de inodo ), el contenido del archivo se modificó por última vez ( mtime , hora de modificación ) y la última vez que se accedió ( atime , tiempo de acceso ).
- El tamaño de bloque de E / S preferido.
- El número de bloques asignados a este archivo.
Trascendencia
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 firmemente al mismo inodo, entonces los nombres son equivalentes; es decir, el primero en ser creado 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 archivo desvinculado se elimina del disco y sus recursos se liberan para la reasignación, pero la eliminación debe esperar hasta que todos los procesos que lo han abierto terminen de acceder a él. Esto incluye archivos ejecutables que implícitamente se mantienen abiertos por los procesos que los ejecutan.
- Por lo general, no es posible asignar un archivo abierto al nombre de archivo que se utilizó para abrirlo. El sistema operativo convierte inmediatamente el nombre del archivo en un número de inodo y luego descarta el nombre del archivo. Esto significa que el getcwd () y Las funciones de la biblioteca getwd () buscan en el directorio principal para encontrar un archivo con un inodo que coincida con el directorio de trabajo , luego buscan en el directorio principal de ese directorio, y así sucesivamente hasta llegar al directorio raíz . Los sistemas SVR4 y Linux mantienen información adicional para que esto sea posible.
- Históricamente, era posible vincular directorios. Esto convirtió la estructura del directorio en un gráfico dirigido arbitrario contrario a un gráfico 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 root todavía se define como root. 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 físicos de directorios. [11]
- El número de inodo de un archivo permanece igual cuando se mueve a otro directorio en el mismo dispositivo, o cuando el disco se desfragmenta, lo que puede cambiar su ubicación física, lo que permite moverlo y cambiarle el nombre incluso mientras se lee y escribe sin causar interrupciones. . Esto también implica que el comportamiento de inodo completamente conforme es imposible de implementar con muchos sistemas de archivos que no son Unix, como FAT y sus descendientes, que no tienen una forma de almacenar esta invariancia cuando se mueven tanto la entrada del directorio de un archivo como sus datos. .
- La instalación de nuevas bibliotecas es sencilla con sistemas de archivos inode. Un proceso en ejecución puede acceder a un archivo de biblioteca mientras otro proceso reemplaza ese archivo, creando un nuevo inodo, y existirá una asignación completamente nueva para el nuevo archivo para que los intentos posteriores de acceder a la biblioteca obtengan la nueva versión. Esta función elimina la necesidad de reiniciar para reemplazar las bibliotecas asignadas actualmente.
- Es posible que un dispositivo se quede sin inodos. Cuando esto sucede, no se pueden crear nuevos archivos en el dispositivo, aunque puede haber espacio libre disponible. Esto es más común para casos de uso como servidores de correo que contienen muchos archivos pequeños. Los sistemas de archivos (como JFS o XFS ) escapan a esta limitación con extensiones o asignación dinámica de inodos, que pueden "hacer crecer" el sistema de archivos o aumentar el número de inodos.
Inlining
Puede tener sentido almacenar archivos muy pequeños en el propio inodo para ahorrar espacio (no se necesitan bloques de datos) y tiempo de búsqueda (no se necesita más acceso al disco). Esta característica del sistema de archivos se llama inserción. Por lo tanto, ya no se puede suponer la estricta separación de los datos de inodo y de archivo cuando se utilizan sistemas de archivos modernos.
Si los datos de un archivo encajan en el espacio asignado para punteros a los datos, este espacio se puede utilizar convenientemente. 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"). [12]
Ext4 tiene una opción de sistema de archivos llamada inline_data
que permite a ext4 realizar una alineación si está habilitada 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. [13]
En sistemas que no son Unix
- NTFS tiene una tabla maestra de archivos (MFT) que almacena archivos en un árbol B. Cada entrada tiene un "fileID", análogo al número de inodo, que se refiere exclusivamente a esta entrada. [14] Las tres marcas de tiempo, una ID de dispositivo, atributos, recuento de referencias y tamaños de archivo se encuentran en la entrada, pero a diferencia de POSIX, los permisos se expresan a través de una API diferente. [15] El diseño en disco es más complejo. [16] Los sistemas de archivos FAT anteriores no tenían una tabla de este tipo y eran incapaces de establecer vínculos físicos .
- NTFS también tiene un concepto de incluir archivos pequeños en la entrada MFT. [17]
- El ReFS derivado tiene un MFT homólogo. ReFS tiene un ID de archivo de 128 bits; esta extensión también se exportó a NTFS, que originalmente tenía un ID de archivo de 64 bits. [15]
- La misma estadística La API GetFileInformationByHandle se puede utilizar en Cluster Shared Volumes y SMB 3.0 , por lo que estos sistemas presumiblemente tienen un concepto similar de ID de archivo. [15]
Ver también
- estructura de puntero de inodo
- inotificar
Referencias
- ^ Tanenbaum, Andrew S. Modern Operating Systems (3ª ed.). pag. 279.
- ^ JVSANTEN. "Diferencia entre mtime, ctime y atime - Howtos de Linux y preguntas frecuentes" . Preguntas frecuentes y Howtos de Linux .
- ^ "Anatomía del conmutador del sistema de archivos virtual de Linux" . ibm.com .
- ^ Archivo de lista de kernel de Linux . Consultado el 12 de enero de 2011.
- ^ Ritchie, Dennis M .; Thompson, Ken (1978). "El sistema de tiempo compartido UNIX" . Revista técnica de Bell System . 57 (6): 1913-1914 . Consultado el 19 de diciembre de 2015 .
- ^ Maurice J. Bach (1986). El diseño del sistema operativo UNIX . Prentice Hall. ISBN 978-0132017992.
- ^ Bach, Maurice J. (1986). El diseño del sistema operativo UNIX . Prentice Hall. pag. 94. bibcode : 1986duos.book ..... B .
- ^ "linfo" . El proyecto de información de Linux . Consultado el 11 de marzo de 2020 .
- ^ "Definiciones - Número de serie de archivo 3.176" . El grupo abierto . Consultado el 10 de enero de 2018 .
- ^ a b "" . El grupo abierto . Consultado el 15 de enero de 2018 .
- ^ "¿Cuál es el comando de Unix para crear un vínculo físico a un directorio en OS X?" . Desbordamiento de pila . 16 de enero de 2011. Archivado desde el original el 5 de enero de 2020 . Consultado el 5 de enero de 2020 .
- ^ "El kernel de Linux: sistemas de archivos" . tue.nl .
- ^ "Diseño de disco Ext4" . kernel.org . Consultado el 18 de agosto de 2013 .
- ^ "¿Tiene Windows Inode Numbers como Linux?" . Desbordamiento de pila .
- ^ a b c "Función GetFileInformationByHandle (fileapi.h) - Aplicaciones Win32" . docs.microsoft.com .
- ^ "[MS-FSCC]: tipos de atributos NTFS" . docs.microsoft.com .
- ^ https://superuser.com/a/1185466
enlaces externos
- Anatomía del sistema de archivos de Linux
- Definición de inodo
- Explicación de inodos, enlaces simbólicos y enlaces duros