stringtranslate.com

inodo

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 de propietario y permiso . [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 el motivo de la "i" en "inode". En 2002, la pregunta fue planteada al pionero de Unix Dennis Ritchie , quien respondió: [4]

La verdad yo tampoco lo sé. Fue sólo un término que empezamos a utilizar. "Índice" es mi mejor suposición, debido a la estructura del sistema de archivos ligeramente inusual que almacena la información de acceso de los archivos como una matriz plana en el disco, con toda la información jerárquica del directorio 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 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 noción de que "índice" es el origen etimológico de los inodos. Ellos escribieron: [5]

[…] una entrada de directorio contiene sólo un nombre para el archivo asociado y un puntero al archivo en sí. Este puntero es un número entero llamado i-número (para 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 encontrada (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 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, 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 mediante un número entero, a menudo denominado i-número o número de inodo .

Los inodos almacenan información sobre archivos y directorios (carpetas), como la propiedad del archivo, el modo de acceso (lectura, escritura, permisos de ejecución) y el tipo de archivo. Los datos pueden denominarse datos estadísticos, en referencia a la stat llamada al sistema que proporciona los datos a los programas.

El número de inodo indexa una tabla de inodos en el sistema de archivos. 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, permitiendo así el acceso al archivo. El número de inodo de un archivo se puede encontrar usando el ls -icomando. El ls -icomando imprime el número de inodo en la primera columna del informe.

En muchos sistemas de archivos más 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 sostener. 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]

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 directorios:

La representación en memoria del kernel del sistema operativo de estos datos se llama 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 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 UNIX tradicionales . Un inodo se indica con la frase "número de serie de archivo", definida como un identificador único del sistema por archivo para un archivo. [9] Ese número de serie del 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 ser recuperados mediante la statllamada al sistema:

Trascendencia

Los sistemas de archivos diseñados con inodos tendrán las siguientes características administrativas:

Archivos con varios nombres y enlaces duros

Los archivos pueden tener varios nombres. Si varios nombres se vinculan 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).

persistencia de inodos y archivos desvinculados

Es posible que un inodo no tenga 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 apunten a él se denomina archivo "desvinculado".

Dichos archivos se eliminan del sistema de archivos, liberando el espacio ocupado en el disco para su reutilización. Un inodo sin enlaces permanece en el sistema de archivos hasta que los recursos (espacio en disco y bloques) liberados por el archivo desvinculado se desasignan o se modifica el sistema de archivos.

Aunque un archivo desvinculado 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 mantienen abiertos los procesos que los ejecutan.

Conversión de número de inodo y recuperación de ruta de directorio de archivos.

Normalmente no es posible asignar un archivo abierto al nombre de archivo que se utilizó para abrirlo. Cuando un programa abre un archivo, el sistema operativo convierte el nombre del archivo en un número de inodo y luego descarta el nombre del archivo. 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 principal , luego hasta el directorio principal, 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. Debido a que el inodo del directorio secundario todavía existe como una entrada en su directorio principal , 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 Linux VFS, [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 al almacenar información sobre enlaces de directorios en la RAM .

Posibilidad histórica de vinculación física de directorios

Históricamente, era posible vincular directorios. Esto hizo que la estructura del directorio fuera un gráfico dirigido arbitrario , al contrario de 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 está definido 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. [13]

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

Cuando un archivo se reubica en 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 cambiar el nombre del archivo incluso durante operaciones de lectura o escritura, garantizando así un acceso continuo sin interrupciones.

Esta característica (hacer que las ubicaciones de los bloques de datos y metadatos de un archivo persistan en una estructura de datos central , independientemente del cambio de nombre o movimiento del archivo) 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 esto. Propiedad invariante cuando tanto la entrada del directorio del archivo como sus datos se reubican simultáneamente. En estos sistemas de archivos, mover o cambiar el nombre de un archivo puede generar 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 sistemas tipo Unix. sistemas.

Instalación de biblioteca simplificada con sistemas de archivos inodo

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 operación única que se completa por completo 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 , estableciendo una asignación completamente nueva. Posteriormente, 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 candado [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 ahora apuntará a la nueva versión de la biblioteca. Por lo tanto, 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 actualmente en uso. En consecuencia, los sistemas pueden actualizar o actualizar las bibliotecas de software sin problemas sin interrumpir los procesos u operaciones en ejecución.

Potencial de agotamiento de inodos y soluciones.

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 donde hay muchos archivos pequeños, como en un servidor que almacena mensajes de correo electrónico, porque cada archivo, sin importar cuán pequeño sea, requiere su propio inodo.

Otros sistemas de archivos evitan esta limitación mediante el uso de 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 el número de inodos disponibles para nuevos archivos y directorios, evitando así el problema de quedarse sin inodos. [22]

en línea

Puede tener sentido almacenar archivos muy pequeños en el propio inodo para ahorrar espacio (no se necesita bloque 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 asumir la separación estricta entre datos de inodo y de archivo 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 convenientemente. Por ejemplo, ext2 y sus sucesores almacenan los datos de los enlaces simbólicos (normalmente nombres de archivos) 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 llamada inline_dataque permite a ext4 realizar inserción si está habilitada durante la creación del sistema de archivos. Debido a que el tamaño de un inodo es limitado, esto sólo funciona para archivos muy pequeños. [24]

En sistemas que no son Unix

Ver también

Referencias

  1. ^ Tanenbaum, Andrew S. Sistemas operativos modernos (3ª ed.). pag. 279.
  2. ^ JVSANTEN. "Diferencia entre mtime, ctime y atime: preguntas frecuentes y procedimientos de Linux". Instrucciones y preguntas frecuentes sobre Linux . Archivado desde el original el 20 de noviembre de 2016.{{cite web}}: Mantenimiento CS1: URL no apta ( enlace )
  3. ^ "Anatomía del conmutador del sistema de archivos virtual de Linux". ibm.com .
  4. ^ Landley, Rob (20 de julio de 2002). "Fwd: Re: ¿Qué significa la" i "en inodo? Dennis Ritchie tampoco lo sabe". kernel-linux (lista de correo) . Consultado el 12 de enero de 2011 .
  5. ^ Ritchie, Dennis M.; Thompson, Ken (1978). "El sistema de tiempo compartido UNIX". La revista técnica de Bell System . 57 (6): 1913-1914 . Consultado 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. pag. 94. Bibcode : 1986duos.book......B.
  8. ^ "información". El proyecto de información de Linux . Consultado el 11 de marzo de 2020 .
  9. ^ "Definiciones: número de serie del archivo 3.176". El grupo abierto . Consultado el 10 de enero de 2018 .
  10. ^ ab "<sistema/stat.h>". El grupo abierto . Consultado el 15 de enero de 2018 .
  11. ^ Gooch, Richard. Enberg, Pekka (ed.). "Descripción general del sistema de archivos virtual de Linux". kernel.org . Consultado el 20 de mayo de 2023 .
  12. ^ Richard Gooch. Enberg, Pekka (ed.). "Caché de entrada de directorio (dcache)". kernel.org . Consultado el 20 de mayo de 2023 .
  13. ^ "¿Cuál es el comando de Unix para crear un enlace 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 .
  14. ^ La comunidad de desarrollo del kernel. "Cierre". kernel.org . Consultado el 21 de mayo de 2023 .
  15. ^ Gooch, Richard. Enberg, Pekka (ed.). "estructura inodo_operaciones". kernel.org . Consultado el 21 de mayo de 2023 .
  16. ^ La comunidad de desarrollo del kernel. "Bloqueo de directorio". kernel.org . Consultado el 21 de mayo de 2023 .
  17. ^ La comunidad de desarrollo del kernel. "Tipos de cerraduras 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}}: Mantenimiento CS1: 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 de autodescripción XFS". kernel.org . Consultado 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 kernel de Linux: sistemas de archivos". mar.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?". Desbordamiento de pila .
  26. ^ abc "Función GetFileInformationByHandle (fileapi.h) - Aplicaciones Win32". docs.microsoft.com .
  27. ^ "[MS-FSCC]: tipos de atributos NTFS". docs.microsoft.com .
  28. ^ "Windows: tamaño máximo de archivo que se puede almacenar por completo en la tabla maestra de archivos NTFS (MFT)".

enlaces externos