El superbloque en Linux: qué es, qué guarda y cómo se repara

Si alguna vez te has encontrado con un mensaje de bad superblock, BusyBox o initramfs al arrancar Linux, sabrás que es uno de esos momentos en los que se te queda cara de «¿y ahora qué he roto?». Detrás de ese tipo de errores hay un componente clave de los sistemas de ficheros: el superbloque. Entender qué es, qué guarda y cómo se repara puede ahorrarte muchos sustos, sobre todo cuando el portátil de un amigo decide morirse justo después de ver una serie.

En este artículo vamos a desgranar de forma práctica y en castellano claro qué es el superblock en Linux, qué contiene, por qué es tan importante, qué significa que esté dañado (bad superblock) y cómo se puede comprobar y reparar usando herramientas como fsck, e2fsck, mke2fs, debugfs y compañía. También veremos cómo encaja en el resto de la estructura del sistema de ficheros (inodos, bloques de datos, RAID, etc.) y qué tipo de comandos sirven para diagnosticar problemas reales.

¿Qué es el superblock en Linux y dónde encaja en el sistema de ficheros?

En los sistemas de ficheros tipo ext2, ext3 y ext4, el superbloque es el “cerebro” del sistema de archivos. Es una estructura de metadatos que describe cómo está organizado todo: tamaño del sistema de ficheros, tamaño de bloque, número de inodos, estado, marcas de tiempo y bastante más información crítica. Sin ese bloque de información, el kernel no sabe cómo interpretar lo que hay en la partición.

El sistema de ficheros de Linux se compone de varias piezas bien diferenciadas, y el superbloque es sólo una de ellas, aunque crucial. A grandes rasgos, en un sistema ext2/ext3/ext4 típico encontramos tres componentes principales: el propio superbloque, la tabla de inodos y los bloques de datos donde se guardan los contenidos de los archivos y directorios.

Para situarlo mentalmente, conviene recordar que en Linux no se trabaja con “unidades C:, D:” al estilo Windows, sino con una única jerarquía de directorios en la que los dispositivos físicos se representan como ficheros especiales (por ejemplo, /dev/sda1, /dev/nvme0n1p3, /dev/md0). Sobre esos dispositivos se crean sistemas de archivos, y cada sistema de archivos tiene su propio superbloque.

Estructura básica de un sistema de ficheros Linux (ext2/ext3/ext4)

En los sistemas de ficheros derivados de ext2, Linux organiza el disco en bloques de tamaño fijo (normalmente múltiplos de 512 bytes, a menudo 1K, 2K o 4K). Si en FAT el protagonista era el “cluster”, aquí la unidad estrella es el bloque. El sistema se estructura de la siguiente forma simplificada:

Bloque de arranque (bloque 0): reservado para código de arranque o metadatos especiales.
Superbloque (bloque 1 y copias de respaldo): datos globales del sistema de archivos.
Tabla de inodos: estructuras que describen cada archivo y directorio.
Área de datos: bloques donde realmente se guardan los contenidos.

El llamado bloque de carga, o bloque cero, suele reservarse para un pequeño programa o información que ayuda al sistema a gestionar el resto de la estructura. Justo a continuación aparece el superbloque principal, que indica al sistema cómo interpretar todo lo que viene después. A partir de ahí se sitúa la tabla de inodos y, finalmente, los bloques de datos donde residen ficheros y directorios.

Cada directorio no es más que un archivo especial cuya “lista de contenido” asocia nombres (de ficheros o subdirectorios) con números de inodo. Gracias a esa correspondencia, el kernel puede localizar el inodo y, desde él, encontrar los bloques de datos en los que se almacena la información real.

Inodos: la “ficha técnica” de cada archivo

Dentro de esta arquitectura, los inodos son las estructuras que describen cada fichero o directorio. No guardan el nombre (que va en la entrada de directorio), sino todos los metadatos importantes: permisos, propietario, tamaños, timestamps y punteros a los bloques de datos. Cada inodo contiene aproximadamente la siguiente información:

Identificador de dispositivo donde se aloja el sistema de ficheros.
Número de inodo único dentro del sistema de archivos.
Tamaño del archivo en bytes.
UID del propietario y GID del grupo.
Modo de acceso: permisos de lectura, escritura y ejecución para propietario, grupo y otros.
Marcas de tiempo: última modificación (mtime), último acceso (atime) y cambio del propio inodo (ctime).
Número de enlaces duros (hard links) que apuntan a ese inodo.

Ese contador de enlaces duros es clave: el sistema de ficheros sólo libera realmente el inodo y sus bloques cuando el número de enlaces llega a cero. Si un archivo tiene varios nombres distintos apuntando al mismo inodo (hard links), todos son equivalentes, sin un “original” privilegiado, al contrario que los accesos directos de Windows o los enlaces simbólicos, que dependen de un archivo real subyacente.

Mientras que el inodo concentra la “ficha técnica”, el superbloque concentra la “ficha técnica global” del sistema de ficheros, desde el número total de inodos hasta el estado de montaje o el intervalo entre comprobaciones forzadas con fsck. Si se estropea esa ficha técnica global, empezamos a ver mensajes de error bastante feos al arrancar.

¿Qué contiene exactamente el superbloque y por qué es tan crítico?

El superbloque de un sistema de archivos ext2/ext3/ext4 almacena un conjunto amplio de metadatos esenciales. Sin pretender listar todos los campos de bajo nivel, incluye información del estilo:

Tamaño total del sistema de archivos (en bloques).
Tamaño de bloque que se está usando.
Número total de inodos y de bloques y cuántos están libres.
Estado del sistema de archivos (limpio, con errores, montado, etc.).
UUID del sistema de ficheros y etiqueta (label) si existe.
Frecuencia con la que se debe pasar fsck (montajes máximos, intervalos de tiempo).
Información sobre el journal en ext3/ext4 (si existe, tamaño, etc.).

Con esos datos, el kernel o la herramienta de comprobación sabe cómo recorrer la tabla de inodos, cómo interpretar los grupos de bloques, dónde buscar las copias de respaldo del propio superbloque y otros detalles. Cuando el superbloque principal se corrompe (por un corte de corriente, un bug, un fallo físico o un apagado brusco), el sistema queda “desorientado” respecto a la estructura interna de la partición.

Por eso, si el superbloque no es legible o contiene datos inconsistentes, lo típico es que al arrancar el sistema no pueda montar / correctamente y termine dejándote en una shell de BusyBox/initramfs con mensajes del estilo “no se puede montar /root” o errores sobre /sys, /proc, /root/dev/console. En el fondo, lo que ocurre es que el initramfs intenta montar el sistema de ficheros raíz y se estrella porque los metadatos de base (superbloque) están mal.

¿Qué es un “bad superblock” y por qué aparece?

Cuando las herramientas de bajo nivel hablan de un bad superblock, lo que están diciendo es que el superbloque que intentan leer se considera inválido: o bien no se puede leer físicamente (lectura corta, errores de E/S), o bien los datos que ve no cumplen las expectativas de un sistema de ficheros ext válido.

Un caso típico es al ejecutar fsck.ext4 o e2fsck directamente sobre una partición averiada y recibir un error como: “El intento de leer el bloque del sistema de archivos resultó en una lectura breve… ¿Podría ser esta una partición de longitud cero?”. Ese mensaje suele indicar que el comprobador no ve un superbloque coherente en la posición estándar y sospecha que la partición está vacía, recortada o muy dañada.

Los motivos habituales por los que un superbloque se degrada o da errores son bastante variados, pero los más comunes incluyen apagados bruscos con mucha actividad de escritura, baterías agotadas de golpe en portátiles, sectores defectuosos en el disco, errores de cableado, bugs del driver o del sistema de archivos y, en menor medida, manipulación incorrecta de particiones.

Lo bueno es que los diseñadores de ext2/ext3/ext4 fueron previsores: además del superbloque principal, el sistema guarda copias de respaldo del superbloque en diferentes bloques del disco. Estas copias permiten “resucitar” un sistema de archivos que, en apariencia, está completamente roto, apoyándose en uno de esos superblocks alternativos que aún se conservan sanos.

Copias de respaldo del superbloque: cómo localizarlas

Al crear un sistema de archivos con herramientas como mkfs.ext4, se generan automáticamente varias copias de seguridad del superbloque. En el propio mensaje de creación suele aparecer una línea tipo “Superblock backups stored on blocks: 32768, 98304, 163840, …”, que indica los bloques donde se han guardado esas réplicas.

Si ya no tienes a mano el mensaje inicial de mkfs, puedes usar el truco de mke2fs -n /dev/XXX (con -n, “dry run”) sobre el dispositivo: de este modo, la herramienta no reescribe el sistema de ficheros, sólo simula la creación y te muestra en qué bloques habría superbloques, que suelen coincidir con los que ya están allí. Esa lista de posiciones es oro puro cuando el superbloque principal ha quedado inutilizable.

Una vez conoces las ubicaciones de respaldo (por ejemplo, el bloque 32768), puedes indicarle a fsck que las use, mediante la opción -b para especificar un superbloque alternativo. Un comando típico sería algo del estilo: fsck -y -b 32768 /dev/nvme0n1p3, que le ordena intentar reparar el sistema basándose en la copia de superbloque situada en ese bloque concreto.

Cómo actúa fsck/e2fsck al reparar un sistema con un superblock dañado

Cuando ejecutas fsck sobre un sistema de ficheros ext y se encuentra con inconsistencias, internamente delega en e2fsck (para ext2/ext3/ext4). Esta herramienta recorre distintas “pasadas” de comprobación: revisa la estructura de inodos, examina directorios, contrasta el recuento de bloques libres, valida referencias cruzadas, etc. Si le has pasado la opción -y o -p, intentará corregir automáticamente todo lo que no requiera una decisión destructiva complicada.

En el caso concreto de un bad superblock, si le proporcionas un superbloque alternativo con -b, e2fsck utilizará esa copia como referencia de cómo debería estar organizado el sistema. A partir de ahí, revisa y repara estructuras corruptas, marca bloques realmente defectuosos para que no vuelvan a usarse y reconstituye el sistema de ficheros hasta dejarlo coherente, dentro de lo posible.

Según el grado de daño, la reparación puede ser casi transparente (el sistema de ficheros vuelve a montar y los datos están intactos) o, en casos graves, implicará pérdida de algunos archivos o directorios. Aun así, cuando el problema está limitado a un superbloque roto y las copias de respaldo están bien, las probabilidades de recuperar la partición ampliamente son bastante altas.

Herramientas avanzadas para diagnosticar superbloques e inodos

Además de fsck y e2fsck, el ecosistema Linux proporciona varias herramientas especializadas para examinar sistemas de ficheros ext en profundidad, incluyendo la información de superbloques, bloques defectuosos y parámetros de montaje.

La utilidad dumpe2fs muestra de forma muy detallada la configuración y el estado de un sistema de archivos ext2/ext3/ext4. Aunque se puede ejecutar con el sistema montado, lo recomendable es hacerlo con la partición desmontada. Permite, entre otras cosas, listar los bloques marcados como defectuosos (-b), consultar sólo la información de superbloque con -h o indicar explícitamente qué copia de superbloque usar con -o superblock= y forzar un tamaño de bloque concreto con -o blocksize= cuando hay corrupción seria.

Por su parte, tune2fs sirve para modificar múltiples parámetros del sistema de ficheros, muchos de los cuales están relacionados con datos que aparecen en el superbloque. Puedes ajustar cada cuántos montajes debe forzarse un fsck (-c y -C), o cada cuánto tiempo máximo (-i), cambiar el porcentaje de bloques reservados para root (-m o -r), añadir un journal a un ext2 (-j) o reservar bloques para un grupo concreto (-g), entre otras cosas.

qué es el superbloque de linux y cómo funciona

Bloques defectuosos y su relación con el superbloque

Una causa frecuente de corrupción de superbloques y demás metadatos son los bloques físicos defectuosos en el disco. Si un sector malo coincide con alguna de las posiciones del superbloque o sus copias, la partición se vuelve muy frágil. Por eso, herramientas como badblocks son importantes a la hora de diagnosticar el estado real del dispositivo.

Con badblocks puedes escanear una partición o disco y localizar qué bloques son físicamente inseguros, bien en modo sólo lectura (-n) o en modo destructivo de escritura (-w). Admite ajustar el tamaño de bloque (-b), leer listas de bloques malos ya conocidas (-i), escribir los resultados a un archivo (-o) y mostrar el porcentaje de progreso (-s). Esa lista de bloques se puede pasar luego a e2fsck o integrarse en la lista interna de bloques malos del sistema de ficheros para que nunca se utilicen en nuevos archivos.

Cuando combinas e2fsck con la opción -c, el comprobador se apoya en badblocks para localizar y añadir bloques defectuosos a la lista de malos. Si repites -c dos veces, se hace un test de lectura-escritura no destructivo más exhaustivo. Además, con -k puedes pedirle que conserve los bloques defectuosos ya registrados y sólo añada los nuevos hallados durante la comprobación.

fsck y e2fsck: consideraciones prácticas y opciones clave

El comando genérico fsck es, en realidad, un frontend que delega en el comprobador correspondiente según el tipo de sistema de archivos (e2fsck para ext*, otros para XFS, etc.). Puedes indicar el tipo explícitamente con -t o, al revés, excluir uno concreto con -t no. Opciones como -A permiten revisar todos los sistemas marcados para chequeo en /etc/fstab, mientras que -M evita tocar sistemas montados y -R excluye el root (/) al usar -A.

Es importante recordar que fsck debe ejecutarse sobre sistemas de ficheros desmontados o, como mucho, montados en solo lectura. Si se intenta forzar sobre una partición montada en lectura-escritura, el riesgo de generar corrupción adicional es serio. Para sistemas de producción, suele utilizarse el chequeo automático al arranque o programar mantenimientos específicos.

Al trabajar directamente con e2fsck, se dispone de opciones extra muy útiles. Por ejemplo, -p (o -a, ahora en desuso) intenta una corrección automática sin intervención, mientras que -n abre en sólo lectura y contesta “no” a todas las preguntas, ideal para diagnosticar sin tocar nada. Para el tema de superbloques, la opción -b numero_superbloque permite usar una copia alternativa, y -B tamaño fuerza un tamaño de bloque concreto en casos de corrupción sospechosa.

Superbloques más allá de ext: RAID por software y XFS

El término “superblock” no se limita únicamente a los sistemas de ficheros ext; también aparece, por ejemplo, en el contexto de RAID por software en Linux. Cuando se crea un array RAID con mdadm (ya sea RAID-0, RAID-1 o niveles superiores), el subsistema md almacena metadatos en los discos que componen ese array, y a esos metadatos se les llama también superbloques del array.

Un comando como mdadm –create /dev/md0 –level=0 –raid-devices=2 /dev/sdb /dev/sdc genera un dispositivo lógico RAID-0 a partir de dos discos, y en la salida de mdadm –detail /dev/md0 verás campos como “Superblock is persistent”, lo que indica que ese array guarda un superbloque RAID estable en disco. Algo similar ocurre con un RAID-1 creado con mdadm –create /dev/md1 –level=1 …, donde cada disco mantiene metadatos que describen al array: UUID, nombre, nivel, tamaño, estado, etc.

Estos superbloques RAID permiten que el kernel pueda reconocer y ensamblar automáticamente los arrays al arrancar, incluso si se han movido discos de un servidor a otro. No obstante, por si acaso, es habitual respaldar la configuración con /etc/mdadm/mdadm.conf, usando comandos como mdadm –misc –detail –brief /dev/md? que generan las líneas ARRAY con metadatos, UUID y nombre del array.

En el mundo de XFS, otro sistema de ficheros muy utilizado en servidores, también se trabaja con metadatos complejos y estructuras similares a superbloques. Herramientas como xfs_info muestran información técnica del sistema de archivos (requiere que esté montado), mientras que xfs_metadump permite volcar los metadatos a un archivo para análisis, y xfs_check y xfs_repair desempeñan un papel similar a fsck/e2fsck para XFS. Además, xfs_admin hace las veces de tune2fs “a lo bruto” para XFS, permitiendo cambiar etiqueta o UUID, siempre con el sistema desmontado.