Articulo de referencia

inodo

Un inodo (nodo de í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 . C...

Un inodo (nodo de í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 (tiempos del último cambio, [ 2 ] acceso, modificación), así como datos de propietario y permisos . [ 3 ]

Un directorio es una lista de inodos con sus nombres asignados. La lista incluye una entrada para sí mismo, su padre y cada uno de sus hijos.

Etimología

Ha habido incertidumbre en la lista de correo del kernel de Linux sobre la razón de la "i" en "inode". En 2002, la pregunta se le planteó al pionero de Unix Dennis Ritchie , quien respondió: [ 4 ]

La verdad es que yo tampoco lo sé. Simplemente era un término que empezamos a usar. "Índice" es mi mejor suposición, debido a la estructura del sistema de archivos, algo inusual, 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 separada de esta. Así, el número i es un índice en esta matriz, y el nodo i es el elemento seleccionado de la matriz. (La notación "i-" se usó en la primera edición del manual; el guion se fue eliminando gradualmente).

Un artículo de 1978 de Ritchie y Ken Thompson refuerza la idea de que "índice" es el origen etimológico de inodos. Escribieron: [ 5 ]

[...] una entrada de directorio contiene únicamente el nombre del archivo asociado y un puntero al archivo mismo. Este puntero es un número entero denominado número i (por índice) del archivo. Al acceder 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 donde reside el directorio. La entrada encontrada (el nodo i 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 usa comúnmente en la literatura sobre el sistema UNIX". [ 6 ]

Detalles

Descriptores de archivos , tabla de archivos y tabla de inodos en Unix [ 7 ]

Un sistema de archivos se basa en estructuras de datos sobre los archivos, en lugar de en el contenido de estos. Las primeras se denominan metadatos : datos que describen los datos. Cada archivo está asociado a un inodo , que se identifica mediante 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 (permisos de lectura, escritura y ejecución) y el tipo de archivo. Estos datos pueden denominarse datos de estado, en referencia a la statllamada al sistema que los proporciona 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 kernel puede acceder al contenido del inodo, incluida la ubicación del archivo, lo que permite acceder a él. El número de inodo de un archivo se puede encontrar mediante el ls -icomando, que imprime dicho número en la primera columna de su salida.

En muchos sistemas de archivos antiguos, los inodos se almacenan en una o más áreas de tamaño fijo que se configuran al crear el sistema de archivos, por lo que el número máximo de inodos se fija al crear el sistema de archivos, lo que limita el número máximo de archivos que este puede contener. Una heurística de asignación típica para los inodos en un sistema de archivos es un inodo por cada 2 KB 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 los árboles B y los árboles B+ derivados .

Implicaciones entre nombres de archivos y directorios:

  • Los inodos no contienen los nombres de sus enlaces físicos , solo otros metadatos de archivo.
  • Los directorios de 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 nombre de archivo específico en un directorio y luego convertir ese nombre de archivo al número de inodo correspondiente.

La representación en memoria del núcleo del sistema operativo de estos datos se denomina struct inodeen Linux . Los sistemas derivados de BSD utilizan el término vnode(la "v" se refiere a la capa del sistema de archivos virtual del núcleo).

Descripción del inodo POSIX

El estándar POSIX exige un comportamiento del sistema de archivos fuertemente influenciado por los sistemas de archivos UNIX tradicionales . Un inodo se denota mediante la frase "número de serie del archivo", que se define como un identificador único del sistema de archivos para un archivo. [ 9 ] Ese número de serie del archivo, junto con el ID 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 recuperarse mediante la statllamada al sistema:

  • ID del 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 archivo.
  • El modo de archivo , que determina el tipo de archivo y cómo el propietario del archivo, los usuarios que son miembros del grupo del archivo y los usuarios que no son ni el propietario ni miembros del grupo del archivo pueden acceder al archivo.
  • Un contador de enlaces que indica cuántos enlaces físicos apuntan al inodo.
  • El ID de usuario del propietario del archivo.
  • El ID de grupo del archivo.
  • El ID del dispositivo del archivo si se trata de 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 del inodo ), cuándo se modificó por última vez el contenido del archivo ( mtime , hora de modificación ) y cuándo se accedió por última vez ( atime , hora 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 enlazan directamente al mismo inodo, entonces los nombres son equivalentes; es decir, el primero que se crea no tiene un estatus especial. Esto difiere de los enlaces simbólicos , que dependen del nombre original, no del inodo (número).

persistencia de inodos y archivos no vinculados

Un inodo puede no tener enlaces. Un inodo sin enlaces representa un archivo sin entradas de directorio 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 enlaces permanece en el sistema de archivos hasta que se liberan los recursos (espacio en disco y bloques) liberados por el archivo sin enlaces o se modifica el sistema de archivos.

Aunque un archivo sin enlazar 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 permanecen abiertos implícitamente debido a los procesos que los ejecutan.

Conversión de números de inodo y recuperación de rutas de directorios de archivos.

Por lo general, no es posible establecer una correspondencia entre un archivo abierto y el nombre del archivo con el que se abrió. Cuando un programa abre un archivo, el sistema operativo convierte el nombre del archivo en un número de inodo y luego lo descarta. Como resultado, funciones como getcwd() y getwd() , que recuperan el directorio de trabajo actual del proceso, no pueden acceder directamente al nombre del archivo.

Comenzando con el directorio actual, estas funciones buscan hasta su directorio padre , luego hasta el padre de este, 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 ascender. Dado que el inodo del directorio hijo aún existe como una entrada en su directorio padre , esto permite a la función reconstruir 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é utilizadas por el kernel para acelerar las operaciones del sistema de archivos almacenando información sobre los enlaces de directorio en la RAM .

Posibilidad histórica de enlaces duros a directorios

Históricamente, era posible crear enlaces duros entre directorios. Esto convertía la estructura de directorios en un grafo dirigido arbitrario , a diferencia de un grafo dirigido acíclico . Incluso era posible que un directorio fuera su propio padre. Los sistemas modernos generalmente prohíben este estado confuso, salvo que el padre de la raíz se sigue definiendo como raíz. La excepción más notable a esta prohibición se encuentra en Mac OS X (versiones 10.5 y posteriores), que permite al superusuario crear enlaces duros entre directorios en sistemas de archivos HFS+ . [ 13 ]

Estabilidad del número de inodos y sistemas de archivos que no son Unix

Cuando un archivo se traslada a un directorio diferente en el mismo sistema de archivos, o cuando una desfragmentación del 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 las 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 si el archivo se renombra o se mueve— no se puede replicar completamente en muchos sistemas de archivos que no son Unix , como FAT y sus derivados, ya que carecen de un mecanismo para mantener esta propiedad invariante cuando tanto la entrada del directorio del archivo como sus datos se reubican simultáneamente. En estos sistemas de archivos, mover o renombrar un archivo puede provocar cambios más significativos en la estructura de datos que lo representa, 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 .

Instalación simplificada de bibliotecas con sistemas de archivos de inodos.

Los sistemas de archivos de inodos permiten que un proceso en ejecución continúe accediendo a un archivo de biblioteca incluso mientras otro proceso reemplaza 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 por completo o que no se realiza en absoluto, sin que otros procesos puedan observar ningún estado intermedio.

Durante el proceso de reemplazo , se crea un nuevo inodo para el nuevo archivo de biblioteca , estableciendo una asignación completamente nueva. Posteriormente, las futuras solicitudes de acceso a 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 impide 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 datos. [ 18 ]

Una vez completada la 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 este modo, es posible realizar actualizaciones incluso cuando la biblioteca está siendo utilizada por otro proceso.

Una ventaja significativa de este mecanismo es que elimina la necesidad de reiniciar el sistema para reemplazar las bibliotecas en uso. En consecuencia, los sistemas pueden actualizar o mejorar las bibliotecas de software sin interrumpir los procesos u operaciones en ejecución.

Potencial de agotamiento de inodos y soluciones

Al crear un sistema de archivos, algunos asignan un número fijo de inodos. [ 19 ] Esto significa que es posible que se agoten los inodos en un sistema de archivos, incluso si aún hay espacio libre. Esta situación suele darse en casos de uso con muchos archivos pequeños, como en un servidor que almacena correos electrónicos, ya que cada archivo, por 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 al momento de la creación del sistema de archivos. [ 21 ] Esto puede "expandir" el sistema de archivos al aumentar el número de inodos disponibles para nuevos archivos y directorios, evitando así el problema de quedarse sin inodos. [ 22 ]

Inserción en línea

Puede resultar conveniente almacenar archivos muy pequeños en el propio inodo para ahorrar espacio (no se necesita un bloque de datos) y tiempo de búsqueda (no se requiere acceso adicional al disco). Esta característica del sistema de archivos se denomina inserción en línea. Por lo tanto, la estricta separación entre los datos del inodo y los del archivo ya no se puede dar por sentada al usar 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 convenientemente. Por ejemplo, ext2 y sus sucesores almacenan los datos de los enlaces simbólicos (normalmente nombres de archivo) de esta manera si los datos no superan los 60 bytes ("enlaces simbólicos rápidos"). [ 23 ]

Ext4 tiene una opción de sistema de archivos inline_dataque permite realizar la inserción de código 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 ]

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 de forma única a esta entrada. [ 25 ] Las tres marcas de tiempo, un ID de dispositivo, atributos, contador 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. [ 26 ] La disposición en disco es más compleja. [ 27 ] Los sistemas de archivos FAT anteriores no tenían dicha tabla y eran incapaces de crear enlaces duros.
    • NTFS también tiene un concepto de insertar archivos pequeños en la entrada de la MFT. [ 28 ]
    • El ReFS derivado tiene una MFT homóloga. ReFS tiene un ID de archivo de 128 bits; esta extensión también se adaptó a NTFS, que originalmente tenía un ID de archivo de 64 bits. [ 26 ]
  • La misma API GetFileInformationByHandle, similar a una estadística, se puede usar en volúmenes compartidos de clúster , por lo que presumiblemente tiene un concepto similar de ID de archivo. [ 26 ]

Véase también

Referencias

  1. Tanenbaum, Andrew S. Sistemas operativos modernos (3.ª  ed.). pág.  279.
  2. JVSANTEN. "Diferencia entre mtime, ctime y atime - Tutoriales y preguntas frecuentes de Linux" . Tutoriales y preguntas frecuentes de Linux . Archivado del original el 20 de noviembre de 2016.
  3. "Anatomía del conmutador del sistema de archivos virtual de Linux" . ibm.com .
  4. Landley, Rob (20 de julio de 2002). "Re: Re: ¿Qué significa la "i" en inodo? Dennis Ritchie tampoco lo sabe" . linux-kernel (Lista de correo) . Consultado el 12 de enero de 2011 .
  5. Ritchie, Dennis M.; Thompson, Ken (1978). " El sistema de tiempo compartido UNIX" . The Bell System Technical Journal . 57 (6): 1913–1914 . Recuperado el 19 de diciembre de 2015 .
  6. Maurice J. Bach (1986). El diseño del sistema operativo UNIX . Prentice Hall. ISBN 978-0132017992.
  7. Bach, Maurice J. (1986). El diseño del sistema operativo UNIX . Prentice Hall. pág. 94. Bibcode : 1986duos.book.....B . 
  8. "linfo" . El Proyecto de Información de Linux . Consultado el 11 de marzo de 2020 .
  9. "Definiciones - 3.176 Número de serie de archivo" . The Open Group . Consultado el 10 de enero de 2018 .
  10. 1 2 "<sys/stat.h>" . The Open Group . Consultado el 15 de enero de 2018 .
  11. Gooch, Richard. Enberg, Pekka (eds.). "Descripción general del sistema de archivos virtuales de Linux" . kernel.org . Consultado el 20 de mayo de 2023 .
  12. Richard Gooch. Enberg, Pekka (ed.). "Caché de entradas de directorio (dcache)" . kernel.org . Consultado el 20 de mayo de 2023 .
  13. "¿Cuál es el comando de Unix para crear un enlace duro a un directorio en OS X?" . Stack Overflow . 16 de enero de 2011. Archivado del original el 5 de enero de 2020. Consultado el 5 de enero de 2020 .
  14. La comunidad de desarrollo del kernel. "Bloqueo" . kernel.org . Consultado el 21 de mayo de 2023 .
  15. Gooch, Richard. Enberg, Pekka (ed.). "struct inode_operations" . kernel.org . Consultado el 21 de mayo de 2023 .
  16. La comunidad de desarrollo del kernel. "Bloqueo de directorios" . kernel.org . Consultado el 21 de mayo de 2023 .
  17. La comunidad de desarrollo del kernel. "Tipos de bloqueo y sus reglas" . kernel.org . Consultado el 21 de mayo de 2023 .
  18. van de Ven, A., Molnar, I. "Validador de corrección de bloqueo en tiempo de ejecución" . kernel.org . Consultado el 21 de mayo de 2023 .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  19. La comunidad de desarrollo del kernel. "2. Diseño de alto nivel" . kernel.org . Consultado el 21 de mayo de 2023 .
  20. La comunidad de desarrollo del kernel. "Metadatos autodescriptivos de XFS" . kernel.org . Archivado del original el 21 de mayo de 2023. Recuperado el 21 de mayo de 2023 .
  21. La comunidad de desarrollo del kernel. "2.7. Política de asignación de bloques e inodos" . kernel.org . Consultado el 21 de mayo de 2023 .
  22. Vadala, Derek (2002). "6. Sistemas de archivos". Gestión de RAID en Linux . O'Reilly Media, Inc. ISBN 9781565927308.
  23. " El núcleo de Linux: Sistemas de archivos" . tue.nl.
  24. "Diseño de disco Ext4" . kernel.org . Consultado el 18 de agosto de 2013 .
  25. "¿Windows tiene números de inodo como Linux?" . Stack Overflow .
  26. 1 2 3 "Función GetFileInformationByHandle (fileapi.h) - Aplicaciones Win32" . docs.microsoft.com . 27 de julio de 2022.
  27. " [ MS-FSCC ] : Tipos de atributos NTFS" . docs.microsoft.com . 20 de septiembre de 2023.
  28. "Windows - Tamaño máximo de archivo que se puede almacenar completamente en la tabla maestra de archivos (MFT) de NTFS" .
  • Anatomía del sistema de archivos de Linux
  • Definición de inodo
  • Explicación de inodos, enlaces simbólicos y enlaces duros