Breaking

Post Top Ad

Your Ad Spot

viernes, 22 de enero de 2021

Todo lo que siempre quiso saber sobre los inodos en Linux

 

Un sistema Linux con texto de terminal verde en una computadora portƔtil.

El sistema de archivos de Linux se basa en inodos. Estas piezas vitales del funcionamiento interno del sistema de archivos a menudo se malinterpretan. Veamos exactamente quĆ© son y quĆ© hacen.

Los elementos de un sistema de archivos

Por definición, un sistema de archivos necesita almacenar archivos y tambiĆ©n contienen directorios. Los archivos se almacenan dentro de los directorios y estos directorios pueden tener subdirectorios. Algo, en algĆŗn lugar, tiene que registrar dónde se encuentran todos los archivos dentro del sistema de archivos, cómo se llaman, a quĆ© cuentas pertenecen, quĆ© permisos tienen y mucho mĆ”s. Esta información se llama metadatos porque son datos que describen otros datos.

En el sistema de archivos ext4 de Linux, las  estructuras de directorio y de inodo trabajan juntas para proporcionar un marco de apoyo que almacena todos los metadatos para cada archivo y directorio. Hacen los metadatos disponibles para cualquier persona que lo requiera, ya sea el nĆŗcleo, las aplicaciones de usuario, o utilidades de Linux, tales como , y .lsstatdf

Inodos y tamaƱo del sistema de archivos

Si bien es cierto que hay un par de estructuras, un sistema de archivos requiere muchas mĆ”s que eso. Hay miles y miles de cada estructura. Cada archivo y directorio requiere un inodo, y debido a que cada archivo estĆ” en un directorio, cada archivo tambiĆ©n requiere una estructura de directorio. Las estructuras de directorio tambiĆ©n se denominan entradas de directorio o "dentries".

Cada inodo tiene un nĆŗmero de inodo, que es Ćŗnico dentro de un sistema de archivos. El mismo nĆŗmero de inodo puede aparecer en mĆ”s de un sistema de archivos. Sin embargo, el ID del sistema de archivos y el nĆŗmero de inodo se combinan para crear un identificador Ćŗnico, independientemente de cuĆ”ntos sistemas de archivos estĆ©n montados en su sistema Linux.

Recuerde, en Linux, no monta un disco duro o una partición. Usted monta el sistema de archivos que estĆ” en la partición, por lo que es fĆ”cil tener varios sistemas de archivos sin darse cuenta. Si tiene varios discos duros o particiones en un solo disco, tiene mĆ”s de un sistema de archivos. Pueden ser del mismo tipo, todos ext4, por ejemplo, pero seguirĆ”n siendo sistemas de archivos distintos.

Todos los inodos se mantienen en una tabla. Usando un nĆŗmero de inodo, el sistema de archivos calcula fĆ”cilmente el desplazamiento en la tabla de inodo en la que se encuentra ese inodo. Puede ver por quĆ© la "i" en inodo significa Ć­ndice.

La variable que contiene el nĆŗmero de inodo se declara en el código fuente como un entero largo sin signo de 32 bits. Esto significa que el nĆŗmero de inodo es un valor entero con un tamaƱo mĆ”ximo de 2 ^ 32, que se calcula en 4.294.967.295, mĆ”s de 4 mil millones de inodos.

Ese es el mĆ”ximo teórico. En la prĆ”ctica, el nĆŗmero de inodos en un sistema de archivos ext4 se determina cuando el sistema de archivos se crea con una proporción predeterminada de un inodo por cada 16 KB de capacidad del sistema de archivos. Las estructuras de directorio se crean sobre la marcha cuando el sistema de archivos estĆ” en uso, ya que los archivos y directorios se crean dentro del sistema de archivos.

Hay un comando que puede usar para ver cuĆ”ntos inodos hay en un sistema de archivos en su computadora. La -iopción (inodos) del dfcomando le indica que muestre su salida en nĆŗmeros de inodos.

Vamos a ver el sistema de archivos en la primera partición en el primer disco duro, entonces escribimos lo siguiente:

df -i / dev / sda1

El comando "df -i / dev / sda1" en una ventana de terminal.

La salida nos da:

  • Sistema de archivos : el sistema de archivos sobre el que se informa.
  • Inodos : el nĆŗmero total de inodos en este sistema de archivos.
  • IUsed : el nĆŗmero de inodos en uso.
  • IFree : el nĆŗmero de inodos restantes disponibles para su uso.
  • IUse% : el porcentaje de inodos usados.
  • Montado en : el punto de montaje para este sistema de archivos.

Hemos utilizado el 10 por ciento de los inodos en este sistema de archivos. Los archivos se almacenan en el disco duro en bloques de disco. Cada inodo apunta a los bloques de disco que almacenan el contenido del archivo que representan. Si tiene millones de archivos diminutos, puede quedarse sin inodos antes de quedarse sin espacio en el disco duro. Sin embargo, ese es un problema muy difĆ­cil de encontrar.

En el pasado, algunos servidores de correo que almacenaban mensajes de correo electrónico como archivos discretos (que rĆ”pidamente conducĆ­an a grandes colecciones de archivos pequeƱos) tenĆ­an este problema. Sin embargo, cuando esas aplicaciones cambiaron su back-end a bases de datos, esto resolvió el problema. El sistema domĆ©stico promedio no se quedarĆ” sin inodos, lo cual es bueno porque, con el sistema de archivos ext4, no puede agregar mĆ”s inodos sin reinstalar el sistema de archivos.

Para ver el tamaƱo de los bloques de disco en su sistema de archivos, puede usar el blockdevcomando con la --getbszopción (obtener tamaƱo de bloque):

sudo blockdev --getbsz / dev / sda

El comando "sudo blockdev --getbsz / dev / sda" en una ventana de terminal.

El tamaƱo del bloque es 4096 bytes.

Usemos la -Bopción (tamaƱo de bloque) para especificar un tamaƱo de bloque de 4096 bytes y verifiquemos el uso regular del disco:

df -B 4096 / dev / sda1

El comando "df -B 4096 / dev / sda1" en una ventana de terminal.

Esta salida nos muestra:

  • Sistema de archivos : el sistema de archivos sobre el que informamos.
  • Bloques de 4K : el nĆŗmero total de bloques de 4 KB en este sistema de archivos.
  • Usado : cuĆ”ntos bloques 4K estĆ”n en uso.
  • Disponible : la cantidad de bloques de 4 KB restantes que estĆ”n disponibles para su uso.
  • % De uso : el porcentaje de bloques de 4 KB que se han utilizado.
  • Montado en : el punto de montaje para este sistema de archivos.

En nuestro ejemplo, el almacenamiento de archivos (y el almacenamiento de inodos y estructuras de directorios) ha utilizado el 28 por ciento del espacio en este sistema de archivos, al costo del 10 por ciento de los inodos, por lo que estamos en buena forma.

Metadatos de inode

Para ver el nĆŗmero de inodo de un archivo, podemos usar lscon la -iopción (inode):

ls -i geek.txt

ls -i geek.txt en una ventana de terminal

El nĆŗmero de inodo para este archivo es 1441801, por lo que este inodo contiene los metadatos para este archivo y, tradicionalmente, los punteros a los bloques de disco donde reside el archivo en el disco duro. Si el archivo estĆ” fragmentado, es muy grande o ambos, algunos de los bloques a los que apunta el inodo pueden contener mĆ”s punteros a otros bloques de disco. Y algunos de esos otros bloques de disco tambiĆ©n pueden contener punteros a otro conjunto de bloques de disco. Esto supera el problema de que el inodo tiene un tamaƱo fijo y puede contener un nĆŗmero finito de punteros a bloques de disco.

Ese mĆ©todo fue reemplazado por un nuevo esquema que hace uso de "extensiones". Estos registran el bloque inicial y final de cada conjunto de bloques contiguos que se utilizan para almacenar el archivo. Si el archivo no estĆ” fragmentado, solo tiene que almacenar el primer bloque y la longitud del archivo. Si el archivo estĆ” fragmentado, debe almacenar el primer y Ćŗltimo bloque de cada parte del archivo. Este mĆ©todo es (obviamente) mĆ”s eficiente.

Si desea ver si su sistema de archivos usa punteros o extensiones de bloque de disco, puede mirar dentro de un inodo. Para hacerlo, usaremos el debugfscomando con la -Ropción (solicitud) y le pasaremos el inodo del archivo de interĆ©sEsto solicita  debugfs usar su comando interno "stat" para mostrar el contenido del inodo. Debido a que los nĆŗmeros de inodo solo son Ćŗnicos dentro de un sistema de archivos, tambiĆ©n debemos indicarle debugfs al sistema de archivos en el que reside el inodo.

AsĆ­ es como se verĆ­a este comando de ejemplo:

sudo debugfs -R "stat <1441801>" / dev / sda1

El comando "sudo debugfs -R" stat <1441801> "/ dev / sda1" en una ventana de terminal.

Como se muestra a continuación, el debugfscomando extrae la información del inodo y nos la presenta en less:

Los metadatos del inodo se muestran en menos en una ventana de terminal.

Se nos muestra la siguiente información:

  • Inode : el nĆŗmero del inodo que estamos viendo.
  • Tipo : este es un archivo normal, no un directorio ni un enlace simbólico.
  • Modo : los permisos del archivo en octal.
  • Banderas : Indicadores que representan diferentes caracterĆ­sticas o funcionalidades. El 0x80000 es el indicador de "extensiones" (mĆ”s sobre esto a continuación).
  • Generación : un  sistema de archivos de red (NFS) lo usa cuando alguien accede a sistemas de archivos remotos a travĆ©s de una conexión de red como si estuvieran montados en la mĆ”quina local. Los nĆŗmeros de inodo y generación se utilizan como una forma de identificador de archivo.
  • Versión : la versión de inodo.
  • Usuario : el propietario del archivo.
  • Grupo : el propietario del grupo del archivo.
  • Proyecto : Siempre debe ser cero.
  • TamaƱo : el tamaƱo del archivo.
  • Archivo ACL : la lista de control de acceso a archivos. Estos fueron diseƱados para permitirle dar acceso controlado a personas que no estĆ”n en el grupo de propietarios.
  • Enlaces : el nĆŗmero de enlaces fĆ­sicos al archivo.
  • Blockcount : la cantidad de espacio en el disco duro asignado a este archivo, expresada en fragmentos de 512 bytes. A nuestro archivo se le han asignado ocho de estos, que son 4.096 bytes. Entonces, nuestro archivo de 98 bytes se encuentra dentro de un solo bloque de disco de 4.096 bytes.
  • Fragmento : este archivo no estĆ” fragmentado. (Esta es una bandera obsoleta).
  • Ctime : la hora a la que se creó el archivo.
  • Atime : la hora a la que se accedió por Ćŗltima vez a este archivo.
  • Mtime : la hora a la que se modificó por Ćŗltima vez este archivo.
  • Crtime : la hora a la que se creó el archivo.
  • TamaƱo de los campos de inodo adicionales : el sistema de archivos ext4 introdujo la capacidad de asignar un inodo en disco mĆ”s grande en el momento del formateo. Este valor es el nĆŗmero de bytes adicionales que utiliza el inodo. Este espacio adicional tambiĆ©n se puede utilizar para acomodar los requisitos futuros de nuevos nĆŗcleos o para almacenar atributos extendidos.
  • Suma de comprobación de inodo: una suma de comprobación para este inodo, que permite detectar si el inodo estĆ” daƱado.
  • Extensiones : si se utilizan extensiones (en ext4, lo son, de forma predeterminada), los metadatos relacionados con el uso de bloques de disco de los archivos tienen dos nĆŗmeros que indican los bloques de inicio y finalización de cada parte de un archivo fragmentado. Esto es mĆ”s eficaz que almacenar todos los bloques de disco ocupados por cada parte de un archivo. Tenemos una extensión porque nuestro archivo pequeƱo se encuentra en un bloque de disco en este desplazamiento de bloque.

¿Dónde estĆ” el nombre del archivo?

Ahora tenemos mucha información sobre el archivo, pero, como habrĆ”s notado, no obtuvimos el nombre del archivo. AquĆ­ es donde entra en juego la estructura de directorios. En Linux, al igual que un archivo, un directorio tiene un inodo. Sin embargo, en lugar de apuntar a bloques de disco que contienen datos de archivo, un inodo de directorio apunta a bloques de disco que contienen estructuras de directorio.

En comparación con un inodo, una estructura de directorio contiene una cantidad limitada de información sobre un archivoSolo contiene el nĆŗmero de inodo del archivo, el nombre y la longitud del nombre.

El inodo y la estructura del directorio contienen todo lo que usted (o una aplicación) necesita saber sobre un archivo o directorio. La estructura del directorio estĆ” en un bloque de disco de directorio, por lo que sabemos en quĆ© directorio se encuentra el archivo. La estructura del directorio nos da el nombre del archivo y el nĆŗmero de inodo. El inodo nos dice todo lo demĆ”s sobre el archivo, incluidas las marcas de tiempo, los permisos y dónde encontrar los datos del archivo en el sistema de archivos.

Inodos de directorio

Puede ver el número de inodo de un directorio tan fÔcilmente como puede verlos para los archivos.

En el siguiente ejemplo, usaremos ls con las opciones -l(formato largo), -i(inodo) y -d(directorio), y miraremos el workdirectorio:

ls -lid work /

El comando "ls -lid work /" en una ventana de terminal.

Debido a que usamos la -dopción (directorio),  lsinforma sobre el directorio en sĆ­, no sobre su contenido. El inodo para este directorio es 1443016.

Para repetir eso para el homedirectorio, escribimos lo siguiente:

ls -lid ~

El comando "ls -lid ~" en una ventana de terminal.

El inodo para el homedirectorio es 1447510 y el workdirectorio estĆ” en el directorio de inicio. Ahora, veamos el contenido del workdirectorio. En lugar de la  -dopción (directorio), usaremos la -aopción (todos). Esto nos mostrarĆ” las entradas del directorio que suelen estar ocultas.

Escribimos lo siguiente:

ls -lia trabajo /

El comando "ls -lia work /" en una ventana de terminal.

Debido a que usamos la -aopción (todos), se muestran las entradas de un solo punto (.) Y de doble punto (..). Estas entradas representan el directorio en sĆ­ (punto Ćŗnico) y su directorio padre (punto doble).

Si observa el nĆŗmero de inodo para la entrada de un solo punto, verĆ” que es 1443016, el mismo nĆŗmero de inodo que obtuvimos cuando descubrimos el nĆŗmero de inodo para el workdirectorio. AdemĆ”s, el nĆŗmero de inodo para la entrada de doble punto es el mismo que el nĆŗmero de inodo para el homedirectorio.

Es por eso que puede usar el cd ..comando para subir un nivel en el Ć”rbol de directorios. Del mismo modo, cuando antepone el nombre de una aplicación o script   ./, le indica al shell desde dónde iniciar la aplicación o el script.

Inodos y enlaces

Como hemos visto, se requieren tres componentes para tener un archivo bien formado y accesible en el sistema de archivos: el archivo, la estructura del directorio y el inodo. El archivo son los datos almacenados en el disco duro, la estructura del directorio contiene el nombre del archivo y su nĆŗmero de inodo, y el inodo contiene todos los metadatos del archivo.

Los enlaces simbólicos son entradas del sistema de archivos que parecen archivos, pero en realidad son atajos que apuntan a un archivo o directorio existente. Veamos cómo gestionan esto y cómo se utilizan los tres elementos para lograrlo.

Digamos que tenemos un directorio con dos archivos: uno es un script y el otro es una aplicación, como se muestra a continuación.

"my_script.sh" y "special-app" en una ventana de terminal.

Podemos usar el comando ln y la -sopción (simbólica) para  crear un enlace suave al archivo de script, asĆ­:

ls -s my_script geek.sh

El comando "ls -s my_script geek.sh" en una ventana de terminal.

Hemos creado un enlace a my_script.shllamado geek.shPodemos escribir lo siguiente y usarlo  ls para ver los dos archivos de script:

ls -li * .sh

El comando "ls -li * .sh" en una ventana de terminal.

La entrada para geek.sh aparece en azul. El primer carĆ”cter de las banderas de permisos es una "l" para el enlace y los  ->puntos a my_script.shTodo esto indica que geek.shes un enlace.

Como probablemente espera, los dos archivos de script tienen diferentes nĆŗmeros de inodo. Sin embargo, lo que podrĆ­a ser mĆ”s sorprendente es que el enlace flexible geek.sh, no tiene los mismos permisos de usuario que el archivo de script original. De hecho, los permisos para  geek.shson mucho mĆ”s liberales: todos los usuarios tienen permisos completos.

La estructura del directorio geek.shcontiene el nombre del enlace y su inodo. Cuando intenta utilizar el enlace, se hace referencia a su inodo, como un archivo normal. El inodo de enlace apuntarĆ” a un bloque de disco, pero en lugar de contener datos de contenido de archivo, el bloque de disco contiene el nombre del archivo original. El sistema de archivos redirige al archivo original.

Eliminaremos el archivo original y veremos quĆ© sucede cuando escribimos lo siguiente para ver el contenido de  geek.sh:

rm my_script.sh
gato geek.sh

Los comandos "rm my_script.sh" y "cat geek.sh" en una ventana de terminal.

El enlace simbólico estÔ roto y la redirección falla.

Ahora escribimos lo siguiente para crear un enlace duro al archivo de la aplicación:

En una aplicación especial, una aplicación geek

El comando "ln special-app geek-app" en una ventana de terminal.

Para ver los inodos de estos dos archivos, escribimos lo siguiente:

ls -li

El comando "ls -li" en una ventana de terminal.

Ambos parecen archivos normales. Nada geek-appindica que sea un enlace en la forma lsen que lo geek.shhizo la lista AdemĆ”s,  geek-app tiene los mismos permisos de usuario que el archivo original. Sin embargo, lo que podrĆ­a sorprender es que ambas aplicaciones tienen el mismo nĆŗmero de inodo: 1441797.

La entrada de directorio para geek-appcontiene el nombre “geek-app” y un nĆŗmero de inodo, pero es el mismo que el nĆŗmero de inodo del archivo original. Entonces, tenemos dos entradas del sistema de archivos con diferentes nombres que apuntan al mismo inodo. De hecho, cualquier nĆŗmero de elementos puede apuntar al mismo inodo.

Escribiremos lo siguiente y usaremos el statprograma para ver el archivo de destino:

estadística-aplicación especial

El comando "stat special-app" en una ventana de terminal.

Vemos que dos enlaces duros apuntan a este archivo. Esto se almacena en el inodo.

En el siguiente ejemplo, eliminamos el archivo original e intentamos usar el enlace con una contraseƱa secreta y segura:

rm aplicación especial
./geek-app correcthorsebatterystaple

Los comandos "rm special-app" y "./geek-app correcthorsebatterystaple" en una ventana de terminal.

Sorprendentemente, la aplicación se ejecuta como se esperaba, pero ¿cómo? Funciona porque, cuando elimina un archivo, el inodo puede reutilizarse libremente. La estructura del directorio estĆ” marcada con un nĆŗmero de inodo de cero, y los bloques de disco estĆ”n disponibles para que se almacene otro archivo en ese espacio.

Sin embargo, si el nĆŗmero de enlaces fĆ­sicos al inodo es mayor que uno, el recuento de enlaces fĆ­sicos se reduce en uno y el nĆŗmero de inodo de la estructura de directorios del archivo eliminado se establece en cero. El contenido del archivo en el disco duro y el inodo todavĆ­a estĆ” disponible para los enlaces duros existentes.

Escribiremos lo siguiente y usaremos stat una vez mĆ”s, esta vez en geek-app:

stat geek-app

El comando "stat geek-app" en una ventana de terminal.

Estos detalles se extraen del mismo inodo (1441797) que el statcomando anterior El recuento de enlaces se redujo en uno.

Debido a que solo tenemos un enlace duro a este inodo, si lo eliminamos  geek-app, realmente eliminarĆ­a el archivo. El sistema de archivos liberarĆ” el inodo y marcarĆ” la estructura del directorio con un inodo de cero. Un nuevo archivo puede sobrescribir el almacenamiento de datos en el disco duro.

Gastos generales de Inode

es un sistema ordenado, pero hay gastos generales. Para leer un archivo, el sistema de archivos debe hacer todo lo siguiente:

  • Encuentre la estructura de directorio correcta
  • Leer el nĆŗmero de inodo
  • Encuentra el inodo correcto
  • Leer la información del inodo
  • Siga los enlaces de inodo o las extensiones a los bloques de disco relevantes
  • Leer los datos del archivo

Es necesario saltar un poco mƔs si los datos no son contiguos.

Imagine el trabajo que debe realizarse para  ls realizar una lista de archivos de formato largo de muchos archivos. Hay un montón de ida y vuelta solo para lsobtener la información que necesita para generar su salida.

Por supuesto, acelerar el acceso al sistema de archivos es la razón por la que Linux intenta realizar la mayor cantidad posible de almacenamiento en cachĆ© de archivos preventivo. Esto ayuda mucho, pero a veces, como con cualquier sistema de archivos, los gastos generales pueden hacerse evidentes.

Ahora sabrƔs por quƩ.

No hay comentarios.:

Publicar un comentario

Post Top Ad

Your Ad Spot

PƔginas