Cuando empezamos a trastear con GNU/Linux, tarde o temprano aparece un concepto un poco misterioso: los inodes o inodos. Sabemos que tienen que ver con cómo se guardan los archivos en disco, que los hostings los limitan, que si se agotan el sistema se vuelve loco… En este artículo arrojamos luz sobre el asunto, explicando qué son los inodos en Linux y cuál es su verdadera importancia.
Explicamos qué es exactamente un inodo, qué guarda, cómo se organiza en el disco, por qué podemos quedarnos sin ellos aun teniendo espacio libre y qué comandos tenemos para controlarlos.
Qué es un inodo en Linux
Un inodo (inode, de index node) es una estructura de datos del sistema de archivos que almacena todos los metadatos de un archivo o directorio en sistemas tipo Unix (Linux, BSD, etc.). Cada archivo ordinario, cada carpeta e incluso algunos tipos de objetos especiales (sockets, FIFOs, dispositivos) tienen asociado un inodo.
Ese inodo se identifica mediante un número entero único dentro de cada sistema de archivos, conocido como «número de inodo». Ese número es lo que, internamente, usa el kernel para referirse al archivo; el nombre que tú ves en el directorio es en realidad una “etiqueta” que apunta al inodo correspondiente.
Es importante entender que el inodo no contiene ni el nombre ni el contenido del archivo. El nombre se guarda en la entrada del directorio (en las llamadas dentries) y el contenido vive en bloques de datos aparte. El inodo guarda todo lo demás que el sistema necesita para localizar y gestionar ese contenido.
Dentro de un mismo sistema de archivos (una partición, por simplificar) no puede haber dos inodos con el mismo número. Sin embargo, sí puede repetirse el número de inodo en diferentes sistemas de archivos, porque se identifica de forma global combinando «dispositivo» + «número de inodo».
Qué información almacena un inodo
Un inodo contiene la práctica totalidad de los metadatos de un archivo o directorio. Dicho de otra forma, todo lo que describe al archivo salvo su nombre y su contenido real. Entre otros, encontramos:
- Número de inodo: identificador entero único del inodo dentro del sistema de archivos.
- Tamaño del archivo en bytes.
- Número de bloques de datos que ocupa el archivo en el disco.
- Identificador de dispositivo (Device ID): en qué dispositivo / sistema de archivos se guarda.
- UID (User ID): identificador del usuario propietario.
- GID (Group ID): identificador del grupo propietario.
- Permisos y tipo (modo): archivo regular, directorio, enlace, dispositivo, y los bits de lectura/escritura/ejecución para propietario, grupo y otros.
- Número de enlaces duros (hard links) asociados a ese inodo.
- Marcas de tiempo: atime (último acceso), mtime (última modificación de datos) y ctime (último cambio del propio inodo, por ejemplo permisos o propietario).
- Información de versión o atributos extendidos, según el sistema de archivos.
- Tabla de punteros a bloques de datos, que indica dónde están físicamente los bloques que contienen el contenido del archivo.
En sistemas Linux podemos inspeccionar esta información con el comando stat. Por ejemplo, si ejecutamos:
stat archivo.txt
veremos una salida donde aparecen el número de inodo, los permisos, el UID/GID, el tamaño, las tres fechas y el recuento de enlaces, entre otros campos. Todo eso es, básicamente, el contenido del inodo asociado a ese archivo.
Cómo funcionan los inodos y los bloques de datos
Los sistemas de archivos tipo Unix, como ext2/ext3/ext4, XFS, Btrfs o UFS, organizan el disco en bloques de datos de tamaño fijo (4 KB es lo típico hoy en día). El contenido de los archivos se reparte en esos bloques; si un archivo es grande, ocupará muchos bloques, posiblemente no contiguos.
Para que el sistema pueda encontrar ese contenido, el inodo incluye punteros a los bloques donde está almacenado el archivo. Es como la ficha de un libro en una biblioteca: la ficha (el inodo) no contiene el libro, pero te dice exactamente dónde encontrarlo en las estanterías (los bloques de datos).
En ext4, por ejemplo, la estructura clásica de un inodo reserva 15 entradas para direccionamiento:
- 12 punteros directos a bloques de datos.
- 1 puntero de indirección simple.
- 1 puntero de indirección doble.
- 1 puntero de indirección triple.
Los punteros directos apuntan directamente a bloques que contienen datos del archivo. Mientras el archivo quepa en esos 12 bloques (más o menos 48 KB si el bloque es de 4 KB), el acceso es muy rápido, porque el inodo llega directamente a los datos.
Cuando el archivo supera esa capacidad, entra en juego la indirección simple: el puntero 13 del inodo apunta a un bloque que no contiene datos de archivo, sino una tabla con más punteros a bloques de datos. Si el archivo sigue creciendo, se usan la indirección doble y triple, encadenando niveles de tablas de punteros, lo que permite archivos enormes, de hasta decenas de terabytes en ext4, a costa de más saltos y un acceso algo más lento a los últimos bloques.
De aquí podemos sacar dos ideas clave: por un lado, los archivos pequeños se gestionan de forma muy eficiente (solo punteros directos); por otro, los archivos gigantes requieren más nivel de indirección y, por tanto, más trabajo para resolver dónde está cada bloque.
Dónde se almacenan los inodos en el disco
Los inodos también ocupan espacio en el disco. No son “mágicos”: forman parte de la propia estructura del sistema de archivos. La forma concreta en que se colocan depende del tipo de sistema de ficheros.
En la familia ext (ext2, ext3, ext4), al crear el sistema de archivos se divide la partición en grupos de bloques. Cada grupo contiene su propia tabla de inodos y sus bloques de datos, de forma que los inodos de una zona del disco apuntan a bloques de datos cercanos. Esto minimiza los desplazamientos del cabezal en discos mecánicos y mejora el rendimiento.
Podemos consultar características como el tamaño de los inodos, su número total o cuántos hay por grupo usando tune2fs. Por ejemplo:
tune2fs -l /dev/sda1 | grep Inode
nos mostrará campos como Inode count, Inodes per group, Inode size, etc. Es bastante habitual ver tamaños de inodo de 128 o 256 bytes en ext2/ext3/ext4, aunque otros sistemas usan estructuras distintas.
En otros sistemas de archivos como ReiserFS, XFS o Btrfs, el enfoque es diferente: no siempre hay una tabla de inodos “tradicional” preasignada, sino estructuras más dinámicas que crean inodos cuando hacen falta. Aun así, siempre existe algún mecanismo equivalente que cumple la misma función: describir archivos mediante metadatos y punteros a datos.
Dentries: cómo se relacionan nombres e inodos
Hasta ahora hemos hablado de inodos, pero falta una pieza clave: ¿dónde se guarda el nombre del archivo? Eso corre a cargo de las dentries (directory entries).
Cada directorio mantiene una tabla con pares «nombre de entrada → número de inodo». Es decir, la dentry dice “el archivo Carta.odt corresponde al inodo 10043”. Cuando haces ls o abres un archivo por su ruta, el kernel recorre la jerarquía de directorios siguiendo estas asociaciones de nombres a inodos.
Un directorio típico incluirá entradas especiales: . (un punto) que apunta al propio directorio, y .. (dos puntos) que apunta al directorio padre. Estas entradas también se gestionan mediante inodos, y ayudan a moverse por la estructura jerárquica.
La clave aquí es que un mismo inodo puede tener varios nombres asociados en distintas dentries, lo que da lugar a los enlaces duros. Y, al revés, es perfectamente posible que un inodo exista sin nombres asociados (por ejemplo, un archivo abierto que se ha borrado), y el sistema seguirá pudiendo acceder a él mientras algún proceso lo tenga aún abierto.
Enlaces duros y el papel de los inodos
En Linux, los archivos no se referencian internamente por su ruta o su nombre, sino por su número de inodo. Esto permite una característica muy potente: los enlaces duros.
Un enlace duro no es más que una entrada de directorio adicional que apunta al mismo inodo. Si haces:
ln archivo.txt copia.txt
ambos nombres, archivo.txt y copia.txt, quedan asociados al mismo inodo. Comparten exactamente el mismo contenido y metadatos (salvo, claro, el nombre en el directorio). Si borras uno de ellos, el inodo no se elimina mientras el contador de enlaces no llegue a cero, porque todavía queda otro nombre que lo referencia.
Esto contrasta radicalmente con los enlaces simbólicos (o los accesos directos de Windows): un enlace simbólico contiene la ruta del archivo objetivo como texto y tiene su propio inodo y metadatos. Si renombramos o eliminamos el archivo real, el enlace simbólico se queda “colgando”. En cambio, con enlaces duros todos los nombres son equivalentes, ninguno es “más importante” que los demás.
Gran parte de la flexibilidad y robustez del sistema de archivos Unix viene precisamente de esta separación entre nombres (dentries) e inodos. Hace posible, por ejemplo, reemplazar un ejecutable en producción borrando el archivo antiguo y creando otro nuevo con el mismo nombre, sin interrumpir a los procesos que ya estaban ejecutando la versión anterior.
Límite de inodos y por qué se pueden agotar
Al crear un sistema de archivos, se define cuántos inodos habrá disponibles en total. En sistemas ext clásicos, ese número queda fijado en el momento de formatear y no se puede cambiar sin recrear por completo el sistema de archivos (lo que implica formatear y, por tanto, perder los datos si no se hace copia previa).
Una regla de heurística habitual en ext2/ext3/ext4 es reservar aproximadamente un inodo por cada 16 KB de capacidad. Teóricamente, con números de 32 bits, el máximo serían en torno a 232 inodos (unos 4,3 mil millones), pero en la práctica se elige un valor razonable para el tamaño de la partición.
Esto tiene una consecuencia importante: el número de inodos es finito y puede agotarse, igual que se agota el espacio del disco. Y, además, es relativamente fácil quedarse sin inodos cuando tenemos millones de archivos muy pequeños, aunque sobre espacio de sobra en la partición.
Imagina un disco con varios millones de inodos libres y cientos de megas de espacio libre. Si una aplicación genera millones de archivos diminutos (por ejemplo, correos electrónicos guardados uno por archivo, sesiones temporales, logs rotados, ficheros de caché, etc.), es posible que se ocupen todos los inodos habiendo usado solo unos pocos megas de almacenamiento. En cuanto no quede ningún inodo disponible, no se podrán crear archivos nuevos, aunque haya bloques libres.
En esa situación, al intentar crear archivos o directorios nuevos te puedes encontrar con mensajes del tipo No space left on device o ver que las aplicaciones fallan sin motivo aparente, a pesar de que el comando df muestre todavía espacio libre en GB.
Consecuencias prácticas de quedarse sin inodos
Cuando el contador de inodos llega al 100 % de uso, el sistema empieza a mostrar comportamientos bastante desagradables. Entre los problemas típicos derivados de un uso excesivo de inodos están:
- Imposibilidad de crear nuevos archivos o directorios, aunque haya mucho espacio libre en la partición.
- Bloqueos o caídas de aplicaciones que intentan escribir ficheros temporales y no pueden.
- Reinicios no previstos o crashes del sistema si los servicios críticos no pueden registrar logs o crear archivos de estado.
- Fallo de tareas programadas (cronjobs) que necesitan crear ficheros de trabajo.
- Pérdida de datos en servicios como servidores de correo si no pueden almacenar mensajes nuevos.
Es un escenario que se ve con frecuencia en servidores de hosting compartido, servidores web y servidores de correo, donde se acumulan millones de pequeños ficheros (cachés, sesiones PHP, emails antiguos, ficheros temporales del CMS, etc.). Por eso muchos proveedores de hosting limitan explícitamente el número de inodos además del espacio en disco: les evita que un solo cliente sature el sistema con millones de archivos ínfimos.
Cómo consultar el uso de inodos
Linux proporciona varios comandos para consultar tanto el número de inodos totales como su uso, así como el número de inodo concreto de un archivo o directorio. Son herramientas básicas para cualquier administración del sistema.
Ver inodos libres y usados con df -i
El comando df muestra espacio en disco, y con la opción -i muestra en su lugar información de inodos:
df -i
La salida típica incluye columnas como Inodes, IUsed, IFree e IUse%, además del punto de montaje. Sumando los campos de inodos usados y libres podemos ver el número total de inodos disponible en cada sistema de archivos.
Si queremos centrarnos en una partición concreta, podemos pasarle el dispositivo o el punto de montaje, por ejemplo:
df -i /dev/sda1
Esto es especialmente útil cuando sospechamos que un problema de “No space left on device” se debe a falta de inodos y no de bloques. Si IUse% está cerca del 100 %, ya sabemos por dónde van los tiros.
Ver el número de inodo de archivos y directorios
Para saber qué inodo usa un archivo, podemos recurrir a ls con la opción -i:
ls -i archivo.txt
o bien, para listar todo un directorio con sus números de inodo:
ls -i
En la primera columna veremos el número de inodo asociado a cada nombre. Esto es muy práctico cuando investigamos cuántos nombres apuntan al mismo inodo (enlaces duros) o cuando cruzamos información con utilidades de bajo nivel que solo muestran números de inodo.
Si nos interesa la información completa del inodo (fechas, permisos, tamaño, etc.), el comando stat es aún más detallado:
stat /var/log/lastlog
En la línea donde pone «Inode» veremos el identificador, y alrededor aparecerán los metadatos clásicos que el inodo almacena: tamaño, número de bloques, enlaces, UID, GID, modos de acceso y marcas de tiempo.
Contar cuántos inodos se usan en un árbol de directorios
Si queremos hacernos una idea de cuántos inodos consume un directorio y todo lo que cuelga de él, podemos combinar find con wc -l:
find /var/log | wc -l
El número resultante será el recuento de entradas (archivos y subdirectorios) que hay bajo esa ruta, es decir, una aproximación del número de inodos que se utilizan en ese árbol concreto. Es muy útil para localizar zonas del sistema donde se acumulan miles o millones de ficheros pequeños.
Modificar número y tamaño de los inodos (ext4)
En sistemas de archivos ext4, los inodos se crean en el momento de formatear la partición. Una vez creado el sistema de archivos, el número total de inodos y su tamaño quedan fijados y no se pueden ampliar de forma dinámica, salvo casos muy concretos (ciertas ampliaciones con LVM o cambiando de sistema de archivos).
Al formatear con mkfs.ext4, podemos indicar explícitamente cuántos inodos queremos y de qué tamaño. Por ejemplo:
sudo mkfs.ext4 -N 2000000 -I 256 /dev/sdX
Este comando creará un sistema de archivos ext4 en /dev/sdX con 2.000.000 de inodos, cada uno de 256 bytes. Eso sí, conviene tener en cuenta varios detalles:
- El tamaño de inodo debe ser una potencia de 2 igual o superior a 128 bytes (lo normal es 128 o 256).
- Cuantos más inodos y más grandes, más espacio de disco consumirá la propia estructura del sistema de archivos.
- No es buena idea “jugar” con estos parámetros sin saber muy bien lo que se hace, porque podemos desperdiciar espacio o quedarnos cortos de inodos.
En la mayoría de los casos, para usuarios sin necesidades muy especiales, es suficiente con dejar que mkfs.ext4 decida los parámetros por defecto:
sudo mkfs.ext4 /dev/sdX
Si más adelante vemos que a una partición de ext4 le faltan inodos de forma crónica, la solución real suele pasar por redimensionar o reformatear (previa copia de seguridad), o bien migrar a un sistema de archivos más flexible como XFS o Btrfs que no preasignan todos los inodos de antemano.
Cómo detectar y solucionar problemas de inodos
Cuando un sistema empieza a dar síntomas extraños (aplicaciones que se bloquean, cronjobs que no arrancan, errores aparentemente aleatorios), una de las primeras comprobaciones debería ser el uso de inodos. El flujo típico de diagnóstico es algo así:
Primero comprobamos el estado de la partición sospechosa con:
df -i /punto/de/montaje
Si el porcentaje de inodos usados está muy alto (por encima del 90 %, y desde luego si está al 100 %), tenemos confirmado que el cuello de botella está en el número de inodos, no en el espacio. A partir de ahí, la solución pasa por liberar inodos eliminando archivos.
Una estrategia típica es localizar directorios con muchos archivos pequeños. Podemos listar los ficheros de un directorio ordenados por tamaño con:
ls -laShr /ruta
y así ver de un vistazo dónde se acumulan miles de ficheros diminutos que probablemente ya no tienen sentido (por ejemplo, viejas sesiones, cachés, temporales, logs rotados, backups obsoletos…).
En servidores donde se generan constantemente ficheros temporales o de caché, una buena práctica es automatizar el borrado de archivos antiguos mediante cron. Por ejemplo, podemos borrar archivos de más de 14 días en un directorio concreto con un comando find apropiado en un cronjob periódico.
Si tras una buena limpieza seguimos muy ajustados de inodos o no tenemos margen para borrar nada, la única salida real pasa por reparticionar o recrear el sistema de archivos con más inodos. Esto es delicado, porque implica copias de seguridad completas y, normalmente, parada de servicio. Pero cuando el diseño inicial del sistema de archivos se quedó corto, no hay una solución mágica que “añada” inodos sobre la marcha.
En resumen, mantener un ojo en los inodos con herramientas como df -i, du, find y ls forma parte de las tareas de mantenimiento rutinario, al mismo nivel que vigilar el espacio libre o la carga de CPU.
Entender cómo funcionan los inodos en Linux, qué datos guardan y por qué son finitos ayuda a evitar más de un susto en producción y a dimensionar mejor nuestros sistemas de archivos. Sabiendo que cada archivo y directorio consume un inodo, que su número se define (en muchos sistemas) al crear la partición y que quedarse sin ellos bloquea la creación de nuevos archivos aunque el disco no esté lleno, podemos planificar con cabeza: elegir el sistema de archivos adecuado, controlar el crecimiento de ficheros pequeños y usar los comandos de inspección para mantener siempre bajo control este recurso tan básico como invisible en el día a día.