Inodes en Linux: conceptos clave y cómo dominarlos

Si trabajas con servidores Linux, tarde o temprano te toparás con los inodos, y más vale que sea antes de que el sistema empiece a lanzar el temido mensaje “No space left on device” pese a tener disco libre. Los inodos son una pieza clave del sistema de archivos y, aunque al principio suenen a teoría pura, entenderlos te puede ahorrar caídas de servicios, pérdidas de datos y buenos sustos en producción.

En este artículo vamos a ver con calma qué es un inodo, qué guarda, cómo se organiza en disco, qué pasa cuando te quedas sin ellos y, lo más importante, cómo controlar y optimizar el uso de inodos en Linux con comandos prácticos. La idea es ir de la parte teórica a la parte práctica, pero con un lenguaje cercano y sin florituras innecesarias.

¿Qué es un inodo y qué papel juega en Linux?

Un inodo (del inglés index node) es una estructura de datos interna del sistema de archivos que almacena todos los metadatos de un archivo o directorio, excepto su nombre y su contenido. Cada archivo y cada directorio de un sistema de archivos tipo Unix (Linux, macOS, etc.), e incluso en entornos Windows con WSL2, tiene asociado exactamente un inodo, identificado por un número entero conocido como número de inodo.

Dentro de un mismo sistema de archivos, cada número de inodo es único. Sin embargo, el mismo número se puede repetir en otros sistemas de archivos montados en la misma máquina. La identidad real de un archivo se define combinando el identificador del sistema de archivos y su número de inodo; esa pareja es la que hace que cada elemento sea inequívoco a nivel global dentro del sistema.

Es importante recalcar que el nombre del archivo no forma parte del inodo. Los nombres se guardan en las entradas de los directorios, que no son más que listas que relacionan un nombre de archivo con un número de inodo. Por eso, en Linux los archivos se referencian realmente por su inodo, y el nombre es solo una etiqueta que apunta a él.

¿Qué información almacena un inodo: metadatos al detalle?

El inodo guarda toda la información necesaria para que el sistema de archivos sepa cómo manejar ese archivo o directorio, sin necesidad de conocer su nombre. Entre los metadatos más habituales que almacena un inodo en sistemas Linux están:

• Tipo de archivo (regular, directorio, enlace simbólico, dispositivo, etc.).
• Permisos de acceso (lectura, escritura, ejecución para usuario, grupo y otros).
• UID del propietario (número de usuario dueño del archivo).
• GID del grupo (número de grupo al que pertenece).
• Tamaño del archivo en bytes.
• Número de enlaces duros que apuntan a ese inodo.
• Número de bloques de datos que ocupa el archivo en el disco.
• Dispositivo de almacenamiento donde reside (Device ID) cuando aplica.
• Marcas de tiempo: última lectura (atime), última modificación de contenido (mtime) y último cambio de metadatos (ctime); en algunos sistemas también la fecha de creación.
• Direcciones de los bloques de datos donde está almacenado el contenido del archivo.
• Direcciones de bloques indirectos (bloques de redirección) cuando el archivo es demasiado grande para referenciarlo solo con punteros directos.
• Número de versión u otros campos internos dependiendo del sistema de archivos.

En definitiva, el inodo concentra todo lo que el sistema necesita saber sobre un archivo, menos su nombre y su contenido. El contenido real vive en los bloques de datos del disco; el nombre, en las entradas de directorio.

Código de bloques, cómo trabajan los inodos internamente

Los sistemas Unix y Linux gestionan los discos duros dividiéndolos en bloques de datos de tamaño fijo, no en clusters al estilo de FAT. Cuando guardas un archivo, su contenido se reparte en uno o varios bloques libres del sistema de archivos. Si el archivo es más grande que un solo bloque, se va fragmentando en tantos bloques como haga falta.

El inodo actúa como una especie de “tabla de contenidos”: contiene punteros a los bloques físicos del disco donde reside el archivo. Si el archivo cabe en unos cuantos bloques, el inodo apunta directamente a ellos mediante las entradas de direccionamiento directo. Cuando el archivo crece demasiado, entran en juego las tablas de direccionamiento indirecto.

Tablas de direccionamiento directas e indirectas

En sistemas de archivos como ext4, cada inodo suele reservar 15 entradas de direccionamiento para sus bloques de datos. Las primeras 12 entradas son punteros directos: cada una apunta directamente a un bloque de datos. Esto permite que archivos relativamente pequeños se gestionen de forma muy eficiente.

Cuando las 12 entradas directas ya no son suficientes, el sistema recurre al direccionamiento indirecto:

• La entrada 13 suele ser un puntero indirecto simple: apunta a un bloque que no contiene datos del archivo, sino una tabla con direcciones de más bloques de datos.
• La entrada 14 se usa como puntero doblemente indirecto: apunta a un bloque que a su vez contiene direcciones de bloques que contienen listas de bloques de datos.
• La entrada 15 sirve como puntero triplemente indirecto: una cadena de tres niveles de tablas antes de llegar a los bloques finales con los datos.

Este mecanismo escalonado permite que un solo inodo pueda referenciar archivos de tamaño muy elevado sin que la estructura interna se dispare de tamaño, a costa de añadir algo de complejidad en el acceso cuando el archivo es muy grande.

Dónde se guardan los inodos en el disco

Los inodos no son archivos que puedas “ver” normalmente; son estructuras de datos que el sistema de archivos reserva en zonas específicas del disco. En sistemas ext2/ext3/ext4, por ejemplo, cuando se crea el sistema de archivos se generan de antemano unas tablas de inodos organizadas en grupos.

En ext4, la partición se divide internamente en varios grupos de bloques. Al inicio de cada grupo se reserva una tabla de inodos y otros metadatos. Los inodos de ese grupo suelen referenciar bloques de datos que están físicamente cercanos, lo que reduce el movimiento de cabezal en discos mecánicos y mejora el rendimiento.

Como cada inodo tiene un tamaño fijo (por ejemplo, 256 bytes por defecto en ext4), y los bloques de disco suelen ser de 4096 bytes, en cada bloque caben 16 inodos. El número total de inodos se define al formatear el sistema de archivos y, en general, no se puede cambiar sin recrearlo.

Cómo se crean, copian y mueven los inodos

Cuando creas un archivo nuevo, el sistema de archivos le asigna un inodo libre y un número de inodo único dentro de esa partición. Si copias un archivo dentro del mismo sistema de archivos, la copia recibe un inodo diferente, con su propio número, aunque el contenido de los datos sea idéntico.

Al mover un archivo dentro de la misma partición (por ejemplo con mv), el inodo no cambia: solo se actualizan las entradas de los directorios que enlazan el nombre del archivo con ese número de inodo. Por eso, mover un archivo grande dentro del mismo sistema de archivos es tan rápido: no se copian los datos, solo se actualizan nombres.

Si mueves un archivo entre sistemas de archivos distintos (por ejemplo, de / a otra partición montada en /mnt), el proceso por debajo es realmente una copia seguida de un borrado. En ese caso, el número de inodo sí cambia porque el archivo “nuevo” pertenece a otro sistema de archivos con su propio conjunto de inodos.

Inodos y enlaces duros: por qué son tan potentes

Como hemos comentado, en Linux los archivos se identifican internamente por su número de inodo, no por su nombre. Esto permite que varios nombres distintos apunten al mismo inodo y, por tanto, al mismo contenido del archivo. A eso se le llama enlace duro (hard link).

Cuando creas un enlace duro con el comando ln, estás añadiendo una nueva entrada de directorio que apunta al mismo número de inodo que el archivo original. No se duplican datos ni se ocupa espacio extra para el contenido. Mientras exista al menos un nombre apuntando a ese inodo, los datos se mantienen en disco.

Esto también explica por qué borrar un archivo no elimina necesariamente sus datos de inmediato: lo que se elimina es una entrada de nombre. Solo cuando el contador de enlaces duros del inodo llega a cero, el sistema de archivos libera los bloques de datos asociados.

Número total de inodos y su límite

Cada sistema de archivos tiene un número máximo de inodos que puede gestionar. A nivel teórico, para muchos sistemas el límite anda por 2^32 inodos, es decir, unos 4,3 mil millones. En la práctica, el número disponible es mucho menor y depende de cómo se haya creado el sistema de archivos.

En sistemas ext2/ext3/ext4 se suele usar una regla heurística: aproximadamente un inodo por cada 16 KB de capacidad de disco. Esto significa que, si creas un sistema de archivos de varios cientos de gigas con la configuración por defecto, vas a disponer de millones de inodos, pero no infinitos.

El dato clave es que el número total de inodos se fija en el momento de formatear con herramientas como mkfs. Ahí puedes ajustar parámetros como los bytes por inodo (opción -i), lo que impacta en cuántos inodos se crearán. Modificarlo más tarde implica recrear el sistema de archivos o reparticionar, con el consiguiente riesgo de pérdida de datos si algo sale mal.

Por qué te puedes quedar sin inodos aunque tengas espacio en disco

Quedarse sin inodos significa que ya no quedan estructuras disponibles para representar nuevos archivos o directorios, aunque los bloques de datos del disco sigan teniendo espacio de sobra. Es una situación menos habitual que quedarse sin espacio bruto, pero perfectamente posible.

Algunos escenarios típicos que disparan el uso de inodos son:

• Generar enormes cantidades de archivos muy pequeños (por ejemplo, logs, correos individuales en disco, sesiones temporales).
• Uso intensivo de contenerización, donde proliferan ficheros y directorios para capas, imágenes y contenedores.
• Crear sistemas de archivos con bloques muy pequeños (por ejemplo, ext3 con bloques de tamaño reducido) que incentivan la generación de muchos archivos minúsculos.
• Cachés, TMP y directorios de sesiones que acumulan archivos antiguos durante años si no se limpian.

En estos casos puedes encontrarte con el error “No space left on device” al crear archivos nuevos, aunque al hacer un df -h veas todavía gigas libres de espacio. El problema no es el almacenamiento bruto, sino que se ha agotado el inventario de inodos disponibles.

Síntomas y riesgos de quedarte sin inodos

Cuando un sistema toca techo con los inodos, empiezan a aparecer fallos de lo más variado. Algunos de los problemas más habituales cuando no quedan inodos libres son:

• Imposibilidad de crear nuevos archivos o directorios, incluso teniendo espacio de disco disponible.
• Bloqueos y caídas de aplicaciones que intentan escribir logs, archivos temporales o datos persistentes.
• Reinicios inesperados del servidor o fallos del sistema operativo si procesos críticos no pueden escribir.
• Pérdida o corrupción de datos cuando fallan escrituras a mitad de operación.
• Tareas programadas (cronjobs) que no se ejecutan correctamente porque no pueden crear archivos temporales o de salida.

En entornos de producción, todo esto se traduce en un riesgo claro: si no vigilas los inodos, puedes tumbar servicios enteros por “falta” de espacio cuando el disco aún está medio vacío.

Comprobar el número de inodos y su uso en Linux

Linux ofrece varios comandos para inspeccionar inodos concretos y monitorizar el uso global de inodos en el sistema. Vamos a ver los más útiles.

Ver la información completa de un inodo con stat

El comando stat muestra todos los metadatos que el sistema conoce sobre un archivo o directorio, incluyendo su número de inodo, permisos, dueño y marcas de tiempo.

Por ejemplo:

root@equipo:~# stat /var/log/lastlog
File: /var/log/lastlog
Size: 292292 Blocks: 96 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 17381397 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 22/ utmp)
Access: 2022-01-12 11:28:19.900058928 +0100
Modify: 2022-01-12 11:28:19.900058928 +0100
Change: 2022-01-12 11:28:19.900058928 +0100
Birth: 2021-06-25 17:40:57.254208200 +0200

En esta salida puedes identificar fácilmente el número de inodo (campo Inode), el número de enlaces, el tamaño y las fechas relevantes.

Ver el número de inodo con ls -i

Si solo te interesa el número de inodo de un archivo o directorio sin tantos detalles, puedes usar ls con la opción -i. Este comando lista los archivos mostrando su inodo en la primera columna.

Ejemplo sobre un archivo:

root@equipo:~# ls -i /var/log/lastlog
17381397 /var/log/lastlog

Y para un directorio, añadiendo alguna opción más para ver la propia entrada:

root@equipo:~# ls -idl /var/log
16813380 drwxr-xr-x. 18 root root 4096 Jun 6 12:33 /var/log

Consultar uso de inodos a nivel de sistema de archivos con df -i

El comando df sirve para ver el uso de espacio en los sistemas de archivos, y con la opción -i pasa a mostrar información sobre inodos totales, usados y libres.

Por ejemplo:

root@equipo:~# df -i /dev/sda1
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda1 524288 379 523909 1% /boot

De esta forma puedes ver el número total de inodos, cuántos están en uso, cuántos quedan libres y el porcentaje utilizado. Es una forma rápida de comprobar si te estás acercando al límite.

Contar cuántos inodos (archivos) hay en un directorio

Si quieres hacerte una idea de cuántos archivos y directorios hay bajo una ruta concreta, puedes combinar find con wc -l, ya que cada archivo o directorio consume un inodo:

root@equipo:~# find /var/log | wc -l
120

Este número te indica aproximadamente cuántos inodos se están utilizando en ese árbol de directorios. Es muy útil para localizar zonas del sistema que generan miles de archivos pequeños.

Ver características de los inodos de una partición

Para inspeccionar la configuración de inodos en una partición ext2/ext3/ext4 puedes usar tune2fs. El siguiente comando muestra el número total de inodos, cuántos hay por grupo y el tamaño de cada inodo:

root@equipo:~# tune2fs -l /dev/sda1 | grep Inode
Inode count: 2031616
Inodes per group: 8192
Inode blocks per group: 512
Inode size: 256

Con esta información puedes estimar cuántos inodos tienes disponibles y cuántos caben por bloque. Por ejemplo, con inodos de 256 bytes y bloques de 4096 bytes, podemos albergar 16 inodos por bloque.

Diferencias entre sistemas de archivos: ext, XFS, Btrfs y compañía

No todos los sistemas de archivos gestionan los inodos de la misma forma. En la familia ext2/ext3/ext4, como hemos visto, las tablas de inodos se crean de forma estática al inicializar el sistema de archivos. Los inodos ocupan un espacio fijo reservado que no se puede usar para otra cosa, y su número no puede crecer dinámicamente.

En sistemas más avanzados como XFS o Btrfs, el enfoque es distinto. En lugar de reservar de antemano una gran tabla, los inodos se van creando bajo demanda cuando se necesitan para representar nuevos archivos. Eso permite mayor flexibilidad, aunque la lógica de gestión interna es más compleja.

También hay que distinguir entre Disk Inodes (los inodos almacenados en el disco físico) y los In-Core Inodes (las estructuras en memoria que usa el kernel para trabajar con ellos mientras los archivos están abiertos). El concepto es el mismo, pero cambian el soporte y algunos detalles de implementación.

Caso práctico: uso de df -i y lectura de su salida

Cuando ejecutas df -i obtienes una tabla con varias columnas. Entender bien qué significa cada una ayuda a interpretar el estado de salud de tus inodos:

• Filesystem: el dispositivo o volumen montado (por ejemplo, /dev/sda1 o /dev/disk1s2 en macOS).
• Inodes / iused / ifree: total de inodos, inodos utilizados e inodos libres.
• %iused: porcentaje de inodos en uso.
• Mounted on: punto de montaje del sistema de archivos.

Aunque los números totales puedan parecer enormes, se pueden agotar mucho antes de llenar el disco. Por ejemplo, en un portátil con 1 TB y unos 4.900.000 inodos libres, podrías crear 4.900.000 archivos de 1 byte, usar apenas unos pocos MB de almacenamiento y, sin embargo, dejar de poder crear nuevos archivos porque ya no quedan inodos.

Cómo detectar y solucionar problemas de inodos altos

Cuando empiezan a fallar aplicaciones o a no ejecutarse tareas programadas, conviene sospechar de los inodos. Lo primero que hay que hacer es comprobar el uso con df -i en los sistemas de archivos relevantes:

df -i
df -i /ruta/que/te/preocupa

Si ves que el porcentaje de inodos usados está cerca del 100 %, tienes el cuello de botella localizado. El siguiente paso es identificar dónde se concentran los archivos pequeños que están consumiendo tantos inodos.

Algunas estrategias útiles son:

• Localizar directorios con gran número de archivos usando combinaciones de find, du y wc -l.
• Ordenar archivos por tamaño con algo como ls -laShr en una ruta concreta para identificar muchos ficheros diminutos.
• Revisar directorios de caché, temporales y descargas, que suelen olvidarse: por ejemplo /tmp, cachés de aplicaciones web, almacenes de sesiones, etc.
• Si una aplicación (como un servidor de correo) guarda muchos elementos individuales como archivos, concentrar su salida en directorios específicos para poder limpiar periódicamente.

Una vez localizada la fuente del problema, la solución más directa suele ser borrar archivos que ya no se necesiten:

• Eliminar directorios y archivos obsoletos.
• Borrar archivos de caché antiguos que puedan regenerarse solos.
• Limpiar archivos de email, sesiones o temporales de más de cierto tiempo (por ejemplo, 14 días) mediante un cronjob con find -mtime y -delete.

Esto permite recuperar inodos rápidamente sin tocar la estructura del sistema de archivos. Hay que tener cuidado con las automatizaciones agresivas porque borrar ficheros imprescindibles puede romper aplicaciones. Siempre conviene revisar y probar los comandos antes de lanzarlos en producción.

Si aun así sigues corto de inodos y no puedes liberar más, solo queda la vía dura: reparticionar o recrear el sistema de archivos con un ratio de inodos más generoso (ajustando bytes por inodo en mkfs). Es un proceso delicado que implica copias de seguridad y posible pérdida de datos si algo sale mal.

Cuándo un uso alto de inodos es realmente preocupante

Ver un porcentaje alto de inodos usados no significa automáticamente desastre. A veces simplemente refleja que tienes muchos archivos, pero aún con margen suficiente. El problema real aparece cuando te acercas al 100 %, sobre todo en particiones críticas como /, /var o /home, donde constantemente se crean y eliminan archivos.

En muchos casos, el uso desmedido proviene de datos superfluos de pequeño tamaño: temporales, cachés o sesiones que nadie ha limpiado en meses. Implantar rutinas automáticas (cronjobs) que borren periódicamente ficheros por antigüedad suele ser una manera sencilla de mantener a raya el consumo de inodos sin tocar el diseño del sistema.

También merece la pena tener en cuenta las diferencias entre sistemas de archivos. Algunos, como XFS o Btrfs, gestionan los inodos de forma más flexible que ext4, lo que puede resultar interesante en entornos donde se sabe que se van a manejar millones de archivos pequeños.

Entender cómo funcionan los inodos, qué información guardan y cómo se agotan permite ver el sistema de archivos con otros ojos: ya no son “archivos y carpetas” sin más, sino estructuras internas con límites muy concretos.

Controlando estos límites y revisando de vez en cuando el uso de inodos con los comandos adecuados, es mucho más fácil evitar errores de “No space left on device” y mantener un Linux sano, incluso bajo carga intensa. Comparte la información y más personas sabrán del tema.