fsck lento en Debian 13: qué es normal, señales de alarma y soluciones (caso #31)

Qué es normal vs señales de alarma

Primero: entiende qué tipo de “comprobación” estás viendo

La gente dice “fsck” como si fuera una sola cosa. No lo es. En Debian 13 podrías estar viendo:

• Reproducción de journal (relativamente rápida): ext4 reproduce su journal tras un apagado no limpio. Esto no es un escaneo completo; esencialmente aplica las últimas escrituras transaccionales. Suele durar segundos a pocos minutos.
• Comprobación completa del sistema de archivos (lenta): escanea metadatos y a veces árboles de directorios e inodos. Esta es la que puede tardar horas en volúmenes de varios terabytes.
• Reconstrucción de dispositivo/RAID (no es fsck): mdadm resync o la reconstrucción del controlador que hace que cada lectura sea lenta, por lo que fsck parece “atascado”.
• Recuperación de errores en la capa de almacenamiento (la aterradora): el disco/SSD está reintentando lecturas, el kernel registra errores de E/S y fsck espera al dispositivo de bloques.

¿Cuánto tiempo es “normal”?

Lo normal depende de cuánto metadato haya, no solo del tamaño bruto del disco, y del perfil de E/S (HDD vs SATA SSD vs NVMe, local vs red, y si tu controlador está de mal humor). Aún así, heurísticas prácticas:

• Reproducción de journal: normalmente menos de un minuto en SSD/NVMe, unos minutos en HDD, más tiempo si el almacenamiento está saturado o degradado.
• Full ext4 fsck: puede ser 10–30 minutos por terabyte en discos giratorios en condiciones decentes. En SSD/NVMe puede ser mucho más rápido, pero no confíes tu noche de guardia en ello.
• Altos recuentos de inodos: millones de archivos pequeños son el impuesto clásico de fsck. Un volumen de 500 GB con 200 millones de inodos puede tardar más que un volumen de 4 TB con archivos mayoritariamente grandes.

Cómo se ve “eternidad”: señales de alarma que debes tratar como incidentes

Estos son los momentos en que dejas de esperar y empiezas a diagnosticar:

• Sin actividad de disco durante minutos mientras fsck dice que está ejecutándose, y el registro del sistema muestra errores o timeouts de E/S repetidos.
• El progreso se estanca en un paso específico (para ext4: Pass 1, 2, 3, 4, 5) durante mucho tiempo en un sistema de archivos pequeño. Un sistema grande puede legítimamente arrastrarse, pero “atascado” en un disco root de 50 GB es sospechoso.
• Mensajes del kernel sobre resets, enlace abajo/arriba o errores NCQ. Eso no es complejidad del sistema de archivos; es el dispositivo pidiendo jubilación.
• fsck imprime “UNEXPECTED INCONSISTENCY” o solicita confirmaciones durante el arranque. Estás en una reparación interactiva durante la ruta de arranque. Es una trampa para sistemas sin atención humana.
• Reinicios repiten la comprobación en cada arranque, incluso después de que “termina”. Eso puede significar que el sistema de archivos nunca se monta limpio, o que el dispositivo de bloques subyacente está mintiendo.

Un modelo mental rápido: si fsck es lento pero el disco está haciendo trabajo constante, probablemente tengas un problema de escala pero no necesariamente peligroso. Si fsck es lento y el disco no hace ningún trabajo, o el kernel está gritando, probablemente tienes un problema peligroso (hardware o corrupción).

Datos y contexto interesantes (por qué fsck se comporta así)

• Hecho 1: El clásico sistema ext2 requería comprobaciones completas regulares porque no tenía journal; el journaling de ext3/ext4 redujo la necesidad de escaneos completos frecuentes.
• Hecho 2: ext4 usa checksums de metadatos y mejoras de journaling que facilitan detectar cierta corrupción, pero detectar no significa que las reparaciones sean rápidas.
• Hecho 3: Un desmontaje “limpio” es un bit en el superblock. Si el sistema pierde energía, ese bit no se pone, y el siguiente montaje puede desencadenar una comprobación —incluso si los datos de usuario están bien.
• Hecho 4: tune2fs puede programar comprobaciones por conteo de montajes o por intervalo de tiempo; muchos sistemas pasan años sin una comprobación completa porque los valores por defecto son conservadores para servidores.
• Hecho 5: El directorio lost+found existe porque fsck puede “salvar” archivos huérfanos conectándolos a algo. Es el cajón de los trastos del sistema de archivos.
• Hecho 6: La “inicialización perezosa de la tabla de inodos” de ext4 hace que crear sistemas de archivos nuevos sea rápido, pero también significa que la inicialización en segundo plano puede competir con la I/O al inicio de la vida del sistema de archivos.
• Hecho 7: Los SSD pueden volverse lentos sin “fallar” de forma dramática; el firmware puede dedicar tiempo a garbage collection o corrección de errores interna, lo que aparece como picos de latencia y retrasos en fsck.
• Hecho 8: En arreglos RAID grandes, una reconstrucción/resincronización puede reducir a la mitad el ancho de banda de lectura efectivo. fsck entonces se convierte en el mensajero culpable.

Una cita de ingeniería que ha sobrevivido suficientes postmortems como para ganarse una silla en la mesa: “La esperanza no es una estrategia.” Esa frase está muy difundida en la cultura ops; trátala como una idea parafraseada del bagaje de ingeniería de confiabilidad, no como escritura sagrada.

Broma #1: Ver el progreso de fsck es como ver secar la pintura, excepto que la pintura de vez en cuando te pide elegir entre dos malas opciones.

Guion de diagnóstico rápido (encuentra el cuello de botella)

Tu objetivo: decidir en qué cubeta estás en 5–10 minutos.

Primero: ¿estamos realmente ejecutando una comprobación del sistema de archivos y en qué dispositivo?

• Revisa los mensajes de la consola de arranque y el estado de las unidades systemd si tienes acceso.
• Identifica el dispositivo de bloques que respalda el sistema de archivos (/dev/nvme0n1p2, /dev/md0, LVM LV, etc.).

Segundo: ¿la pila de almacenamiento está saludable ahora?

• Busca errores de E/S del kernel, resets de enlace, timeouts del controlador.
• Comprueba la salud SMART y los contadores de errores actuales.
• Si hay RAID, verifica el estado de resync/rebuild.

Tercero: ¿fsck está avanzando o bloqueado en E/S?

• Mide la utilización del dispositivo y la latencia (incluso números aproximados ayudan).
• Observa lecturas constantes; la salida “atascada” aún puede significar escaneo activo.
• Decide si dejarlo continuar, reiniciar en modo rescue o parar e imagenar el disco.

Árbol de decisiones que deberías usar realmente

• Si los logs del kernel muestran errores/timeouts de E/S: trátalo como posible fallo de disco. Prioriza la seguridad de los datos: imagen/backup, reemplaza hardware y luego repara el sistema de archivos.
• Si hay resync/rebuild de RAID activo: espera lentitud; considera pausar el resync (con cuidado) o programar fsck después de la estabilización.
• Si no hay errores y la I/O está activa: probablemente sea un escaneo largo legítimo. Déjalo terminar, pero planifica mitigaciones futuras (ajustes, dividir sistemas de archivos, almacenamiento más rápido).
• Si solicita interacción durante el arranque: deja de hacer eso. Usa modo rescue y ejecuta una reparación controlada con registros.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos pasos están escritos para Debian 13 con systemd. Ajusta los nombres de dispositivo a tu realidad. Cada tarea incluye: comando, qué significa la salida y qué decisión tomar.

Task 1: Identificar en qué espera systemd (fsck en arranque)

cr0x@server:~$ systemctl list-jobs
JOB UNIT                       TYPE  STATE  
123 systemd-fsck@dev-disk-by\x2duuid-... service running
124 dev-mapper-vg0-root.device  start waiting

2 jobs listed.

Significado: Una unidad systemd fsck está en ejecución para un dispositivo respaldado por UUID.

Decisión: Resuelve a qué dispositivo de bloques corresponde ese UUID a continuación, y comprueba errores de E/S antes de asumir que es “solo lento”.

Task 2: Mapear UUID de sistema de archivos a un dispositivo

cr0x@server:~$ ls -l /dev/disk/by-uuid | head
total 0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 1a2b3c4d-... -> ../../sda1
lrwxrwxrwx 1 root root 15 Dec 30 02:11 7f8e9d0c-... -> ../../dm-0
lrwxrwxrwx 1 root root 10 Dec 30 02:11 9abc0123-... -> ../../sda2

Significado: El UUID se resuelve a una partición (sda1) o a un nodo device-mapper (dm-0 para LVM/crypt).

Decisión: Si es dm-*, identifica también las PV subyacentes. Un fsck lento en dm-0 puede ser un disco fallando bajo LVM.

Task 3: Revisar logs recientes del kernel por dolor de E/S

cr0x@server:~$ dmesg -T | tail -n 25
[Mon Dec 30 02:12:11 2025] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Dec 30 02:12:11 2025] ata1.00: failed command: READ FPDMA QUEUED
[Mon Dec 30 02:12:11 2025] blk_update_request: I/O error, dev sda, sector 12345678 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[Mon Dec 30 02:12:12 2025] EXT4-fs (sda2): I/O error while writing superblock

Significado: Esto no es “fsck lento”. Son errores de lectura y bloqueos de enlace. ext4 tampoco pudo escribir el superblock limpiamente.

Decisión: Deja de tratar esto como un problema únicamente del sistema de archivos. Prepárate para reemplazar el disco; prioriza una copia a nivel de bloque o una copia de seguridad antes de múltiples escrituras de reparación.

Task 4: Comprobar qué sistemas de archivos están configurados para comprobaciones automáticas

cr0x@server:~$ cat /etc/fstab
UUID=7f8e9d0c-... /     ext4  defaults,errors=remount-ro  0  1
UUID=1a2b3c4d-... /boot ext4  defaults                  0  2
UUID=9abc0123-... /data ext4  defaults                  0  2

Significado: La última columna es el orden de “pass” de fsck. Root es 1 (primero), otros son 2 (después de root), 0 desactiva fsck.

Decisión: Si ves un volumen de datos enorme con pass 2 y está causando largas demoras en el arranque, considera ponerlo a 0 y ejecutar fsck en una ventana de mantenimiento. No lo hagas para ocultar corrupción; hazlo para controlar el radio de impacto.

Task 5: Ver la programación de chequeos de ext4 y la última comprobación

cr0x@server:~$ sudo tune2fs -l /dev/sda2 | egrep -i 'Filesystem state|Mount count|Maximum mount count|Last checked|Check interval'
Filesystem state:         not clean
Mount count:              41
Maximum mount count:      42
Last checked:             Sun Dec  1 03:10:22 2025
Check interval:           15552000 (6 months)

Significado: Has alcanzado el umbral de conteo de montajes, o el sistema de archivos está marcado como “not clean”, así que se está desencadenando una comprobación completa.

Decisión: Si esto es un disparador previsto de mantenimiento, déjalo correr. Si es inesperado, pregunta por qué el sistema de archivos sigue quedando “not clean” (pérdida de energía, kernel panic, timeouts de almacenamiento).

Task 6: Obtener visión en tiempo real de lo que fsck está haciendo (vista de procesos)

cr0x@server:~$ ps -eo pid,etime,stat,cmd | grep -E 'fsck|e2fsck' | grep -v grep
  622 01:17:43 D    /sbin/e2fsck -p -C 0 /dev/sda2

Significado: El estado D a menudo indica sueño no interrumpible, usualmente esperando E/S. Eso es un indicador contundente cuando se combina con errores de disco o alta latencia.

Decisión: Si está atascado en D y tienes errores de E/S, detén y triajea el disco. Si está en R o S con I/O constante, puede estar bien.

Task 7: Medir latencia y utilización del dispositivo (rápido y sucio)

cr0x@server:~$ iostat -x 1 5
Linux 6.12.0 (server)  12/30/2025  _x86_64_ (8 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          1.20  0.00    2.40   72.00    0.00   24.40

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
sda             90.0  14400.0     0.0   0.00  850.00   160.00      2.0     64.0  120.00  40.00  99.00

Significado: r_await a 850ms y %util ~99% significa que el disco está saturado y lento. El iowait es enorme. Por eso fsck se siente como melaza.

Decisión: Si se trata de un HDD individual en un sistema de archivos grande, aún puede ser “más o menos normal” pero doloroso. Si es un SSD/NVMe, es una señal de alarma: problemas de firmware, medio fallando o RAID degradado.

Task 8: Revisar SMART y contadores de error

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i 'SMART overall|Reallocated|Pending|Offline|Error|Power_On_Hours'
SMART overall-health self-assessment test result: FAILED!
Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always       -       8123
Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       97
Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       97
ATA Error Count: 203

Significado: Sectores pendientes/offline-uncorrectable significan que la unidad no puede leer algunos datos de forma fiable. fsck golpeará esas áreas y se detendrá.

Decisión: Reemplaza el disco. Antes de ejecutar opciones de reparación agresivas, imagen o respalda lo que puedas. Cada reparación son escrituras adicionales en un disco fallando.

Task 9: Revisar el estado de mdadm RAID (si aplica)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [========>............]  recovery = 41.2% (402123456/976630336) finish=210.3min speed=45512K/sec

Significado: El arreglo está degradado ([U_]) y recuperándose. Las lecturas pueden ser más lentas; la contención de I/O puede hacer que fsck se arrastre.

Decisión: Si los datos son críticos y el rendimiento colapsa, quizá prefieras completar la recuperación primero y luego ejecutar una comprobación del sistema de archivos, en lugar de mezclar ambas operaciones intensivas.

Task 10: Si usas LVM, confirma qué PV es lento

cr0x@server:~$ sudo lvs -a -o +devices
  LV   VG  Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  root vg0 -wi-ao---- 120.00g                                                     /dev/sda2(0)
  data vg0 -wi-ao----   3.50t                                                     /dev/sdb1(0)

Significado: Puedes mapear un sistema de archivos lento a un disco físico. Si / está en sda2, sabes dónde enfocar SMART y las comprobaciones de cableado.

Decisión: No adivines. Si el volumen abarca múltiples PV, necesitas encontrar el eslabón más débil, no ejecutar fsck dos veces y confiar en la suerte.

Task 11: Ejecutar un fsck controlado desde rescue (solo lectura primero)

cr0x@server:~$ sudo e2fsck -f -n -v /dev/sda2
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? no
Pass 2: Checking directory structure
Entry 'tmp123' in /var/tmp (12345) has deleted/unused inode 778899.  Clear? no
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200322/31457280 blocks

Significado: -n significa “sin cambios”, por lo que es seguro para evaluación. Aun así reporta lo que arreglaría y si se requieren modificaciones.

Decisión: Si reporta “WAS MODIFIED” incluso con -n, significa que se necesitan cambios. Planifica tiempo de inactividad y ejecuta sin -n (o usa -p para preen) solo después de confirmar que el disco está lo bastante sano para soportar escrituras.

Task 12: Ejecutar reparación con registro (y acepta que eres responsable del resultado)

cr0x@server:~$ sudo e2fsck -f -y -v /dev/sda2 | tee /root/e2fsck-root.log
Pass 1: Checking inodes, blocks, and sizes
Inode 774533 has illegal block(s).  Clear? yes
Pass 2: Checking directory structure
...
/dev/sda2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda2: 164233/7864320 files, 19200320/31457280 blocks

Significado: -y responde “sí” a los avisos. Es una reparación contundente. Útil para recuperación no atendida, peligrosa si el problema subyacente es hardware en fallo.

Decisión: Usa -y cuando hayas decidido que restaurar la montabilidad es más importante que conservar cada nombre de archivo. Para sistemas críticos, considera una ruta de backup/restauración en lugar de reparaciones agresivas.

Task 13: Revisar características de ext4 que pueden afectar el comportamiento de la comprobación

cr0x@server:~$ sudo dumpe2fs -h /dev/sda2 | egrep -i 'Filesystem features|Checksum|metadata_csum|64bit'
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit metadata_csum

Significado: Características modernas de ext4 como metadata_csum y 64bit son normales en sistemas de archivos grandes. Pueden cambiar cómo se realizan las comprobaciones y cómo lucen los errores.

Decisión: Si migras discos entre toolchains antiguas, asegúrate de que tu entorno de rescue tenga un e2fsck reciente. Herramientas muy antiguas más características modernas equivalen a un mal día.

Task 14: Confirmar montajes y evitar ejecutar fsck sobre un sistema montado

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE / /data
/dev/sda2 / ext4
/dev/sdb1 /data ext4

Significado: Muestra qué dispositivos están montados dónde.

Decisión: No ejecutes un fsck de escritura en un sistema montado. Si debes comprobar un ext4 montado, usa fsck -n solo para inspección y programa una ventana de mantenimiento para reparaciones reales.

Task 15: Forzar una comprobación en el próximo reinicio (controlado, no accidental)

cr0x@server:~$ sudo touch /forcefsck
cr0x@server:~$ ls -l /forcefsck
-rw-r--r-- 1 root root 0 Dec 30 02:45 /forcefsck

Significado: Muchas configuraciones Debian respetan /forcefsck en el arranque para forzar comprobaciones.

Decisión: Úsalo cuando quieras una comprobación planificada, no cuando quieras apostar a que no aparecerá una demora de 2 horas durante una ventana de despliegue.

Task 16: Encontrar por qué el apagado anterior fue no limpio

cr0x@server:~$ journalctl -b -1 -p warning..alert | tail -n 30
Dec 30 01:58:09 server kernel: EXT4-fs warning (device sda2): ext4_end_bio:345: I/O error 10 writing to inode 2625315 starting block 1234567)
Dec 30 01:58:12 server systemd[1]: Failed to start Flush Journal to Persistent Storage.
Dec 30 01:58:16 server kernel: Kernel panic - not syncing: Fatal exception

Significado: El arranque anterior terminó mal. fsck no es la causa; es una consecuencia.

Decisión: Arregla el desencadenante (errores de disco, panic, problemas de energía) o volverás a estar aquí, disfrutando la misma “comprobación del sistema de archivos que tarda una eternidad”.

Tres micro-historias del mundo corporativo (qué sucede en la práctica)

1) Incidente causado por una suposición errónea: “Es solo un disco grande”

Una empresa mediana ejecutaba una flota Debian que alojaba artefactos de compilación internos. Una mañana, un runner crítico dejó de arrancar. La consola mostró una comprobación ext4. El on-call se encogió de hombros: disco grande, muchos archivos, terminará.

Dos horas después, aún en ejecución. Los mensajes de progreso avanzaban lentamente, pero no al ritmo que esperarías de un host con NVMe. El primer error del equipo fue asumir que “lento” equivale a “normal” y no revisar los logs del kernel. Estaban tratando fsck como una tarea de mantenimiento, no como un síntoma.

Finalmente alguien miró dmesg y encontró resets de enlace en la ruta SATA que alimentaba un SSD SATA barato usado como capa de cache “temporal” que se había vuelto permanente. Las lecturas se reintentaban. El disco no estaba muerto; estaba muriendo de forma educada mientras arrastraba a todos con él.

La reparación terminó, pero el sistema de archivos necesitó otra comprobación en el siguiente arranque porque el disco lanzó más errores al escribir el superblock final. Solo entonces reemplazaron el dispositivo. La lección fue dolorosamente aburrida: los errores de almacenamiento se hacen pasar por “comprobaciones largas” antes de convertirse en caídas obvias.

Después añadieron un runbook: si fsck supera un umbral, comprueba SMART y dmesg en diez minutos. No porque amen el proceso, sino porque aman dormir.

2) Optimización que salió mal: “Aceleremos la reconstrucción RAID”

Otra organización tenía un par de grandes arreglos RAID1 en servidores commodity. Un disco falló, empezó la reconstrucción y alguien decidió “optimizar” aumentando la velocidad de rebuild para acortar la ventana degradada. En papel, era racional: rebuild más rápido, menos riesgo.

En realidad, la máquina alojaba una base de datos crítica y un montón de trabajos de procesamiento de logs. Aumentar la agresividad del rebuild asfixió las lecturas sensibles a latencia. La base de datos empezó a hacer timeouts, crecieron las colas del kernel y luego vino el reboot—porque alguien pensó que la base de datos estaba “colgada”. No lo estaba. Estaba asfixiada.

Al reiniciar, la comprobación del sistema de archivos empezó. Ahora fsck competía con la recuperación RAID aún en curso. La “optimización” convirtió un día con un problema en un día con dos problemas: RAID degradado más fsck dolorosamente lento, más tiempo de recuperación de aplicaciones.

La solución no fue heroica. Volvieron la velocidad de rebuild a un valor conservador durante horas laborables, programaron reconstrucciones y comprobaciones pesadas fuera de pico, e introdujeron monitorización en latencia, no solo en throughput. También dejaron de reiniciar máquinas porque las aplicaciones estaban lentas. Si reinicias una máquina en apuros, en verdad estás reiniciando tus propias suposiciones.

3) Práctica aburrida pero correcta que salvó el día: “Ventanas de mantenimiento y recuperación ensayada”

Un tercer equipo corrió servidores Debian para un entorno con cumplimiento estricto. Tenían la cultura de ingeniería menos emocionante que puedas imaginar, y fue gloriosa. Programaban ventanas de mantenimiento de almacenamiento trimestrales, incluidos reinicios controlados, verificación de atributos SMART y fsck planificados en un subconjunto rotativo de máquinas.

Cuando un host sufrió un apagado no limpio por un problema de distribución eléctrica, el on-call vio un fsck largo y no entró en pánico. Ya tenían baselines: cuánto tarda una comprobación completa en ese volumen y hardware específico, y qué apariencia tienen los pases normales. También tenían una imagen de rescue conocida buena con versiones compatibles de e2fsck.

Durante el diagnóstico no encontraron errores de E/S, solo un sistema de archivos marcado como no limpio. Lo dejaron correr, terminó dentro de la ventana esperada y los servicios regresaron. Sin drama, sin heroísmos improvisados.

Al día siguiente auditaron el evento de energía, confirmaron que no se repetía y siguieron con su trabajo. Su “salsa secreta” no era inteligencia. Era ensayo y bases aburridas. Ese tipo de cosas que nadie quiere financiar hasta que llega la factura del outage.

Broma #2: Los sistemas de archivos son como los organigramas corporativos: todo parece consistente hasta que intentas conciliar quién reporta a quién.

Errores comunes: síntoma → causa raíz → solución

1) “fsck se queda atascado en 0–5% para siempre”

Síntoma: El pase inicial tarda una eternidad, la consola muestra poco movimiento.

Causa raíz: El dispositivo devuelve lecturas con enorme latencia por reintentos, o estás en un RAID degradado/resync.

Solución: Revisa dmesg por errores de E/S, ejecuta iostat -x para await/%util e inspecciona contadores SMART. Si RAID se está reconstruyendo, decide si finalizar la reconstrucción primero.

2) “fsck se ejecuta en cada reinicio”

Síntoma: El sistema siempre comprueba root al arrancar incluso después de un apagado limpio.

Causa raíz: El sistema de archivos nunca se marca limpio: errores de almacenamiento, comprobaciones forzadas por política de conteo de montajes o apagados que no alcanzan el desmontaje limpio.

Solución: Confirma el estado/conteo de montaje con tune2fs -l, revisa logs por crashes previos, arregla el problema de reinicio/energía y asegúrate de que el apagado se complete.

3) “Solicita intervención manual durante el arranque”

Síntoma: El arranque cae a un prompt pidiendo corregir errores.

Causa raíz: Errores no prehabilitados o desajuste de política (el sistema espera -p pero los errores requieren decisiones manuales).

Solución: Arranca en rescue/emergency, ejecuta e2fsck -f -n primero para evaluar y luego repara con registro. Considera ajustar cómo el sistema maneja las comprobaciones para que los arranques en producción no sean juegos interactivos.

4) “fsck es lento en NVMe, que debería ser rápido”

Síntoma: Minutos parecen horas en almacenamiento moderno.

Causa raíz: Throttling térmico NVMe, corrección de errores a nivel de firmware, problemas de enlace PCIe o contención en almacenamiento virtualizado.

Solución: Revisa dmesg por resets NVMe, usa iostat para ver awaits e inspecciona la salud SMART/NVMe. Si está virtualizado, confirma la salud del host de almacenamiento y vecinos ruidosos.

5) “Desactivamos fsck en fstab y ahora la corrupción empeoró”

Síntoma: Tras una serie de crashes, el sistema de archivos monta pero se comporta de forma extraña, y más tarde queda inmontable.

Causa raíz: Desactivar comprobaciones para acelerar arranques ocultó problemas de metadatos en escalada.

Solución: Vuelve a habilitar comprobaciones para root, programa comprobaciones para volúmenes de datos grandes y construye un flujo de trabajo de mantenimiento en lugar de confiar en que el journaling lo arregle todo.

6) “Ejecutamos fsck en un sistema montado y se puso raro”

Síntoma: Archivos desaparecen, directorios se comportan mal, los errores aumentan después.

Causa raíz: Ejecutar reparación mientras el sistema de archivos está montado y cambiando.

Solución: Para. Remonta en solo lectura si es posible y luego repara offline desde rescue o con un reinicio de mantenimiento. Si los datos son críticos, crea snapshot/backup primero.

Listas de verificación / plan paso a paso

Lista A: Cuando fsck se ejecuta en arranque y estás de guardia

1. Confirma qué está corriendo: identifica la unidad fsck y el dispositivo (Tasks 1–2).
2. Busca errores de almacenamiento en el kernel: dmesg y el journal del arranque previo (Tasks 3 y 16).
3. Mide salud de I/O: iostat -x para latencia/utilización (Task 7).
4. Comprueba SMART / NVMe: confirma que no estás martillando un dispositivo en fallo (Task 8).
5. Revisa capas RAID/LVM: verifica que no compitas con reconstrucción o una ruta degradada (Tasks 9–10).
6. Decide:
   • Si hay errores de dispositivo: detén reparaciones repetidas, planifica reemplazo y recuperación de datos.
   • Si no hay errores pero el volumen es grande: déjalo correr; comunica un rango de ETA, no una promesa.
   • Si hay prompts interactivos: arranca en rescue y haz una reparación controlada con registros.

Lista B: Flujo de trabajo de reparación controlada (el plan “quiero recuperar mi vida”)

1. Arranca en modo rescue/emergency o desde una imagen instaladora/live.
2. Asegura que el sistema de archivos esté desmontado: verifica con findmnt (Task 14).
3. Ejecuta evaluación en solo lectura: e2fsck -f -n -v (Task 11).
4. Si el disco está lo bastante sano, realiza la reparación con registros: e2fsck -f -y -v | tee (Task 12).
5. Repite fsck hasta que reporte limpio. Una pasada no siempre basta después de reparaciones intensas.
6. Monta y comprueba saneamiento: confirma directorios clave, servicios y sumas de verificación a nivel de aplicación si las tienes.
7. Tras el arranque, recopila evidencia: SMART, logs del kernel y el archivo de log de fsck para el registro del incidente.

Lista C: Prevenir la próxima maratón fsck a las 3am

1. Establece tiempos base de comprobación por clase de host (HDD vs SSD vs NVMe, RAID vs no-RAID).
2. Asegura alertas de monitorización sobre latencia de disco y degradación SMART, no solo “disco lleno”.
3. Revisa los valores pass en /etc/fstab. No permitas que volúmenes de varios terabytes bloqueen arranques a menos que lo quieras.
4. Programa comprobaciones controladas periódicas para volúmenes grandes si tu modelo de riesgo lo requiere.
5. Arregla causas de apagados no limpios: energía inestable, kernels/controladores inestables, controladores sobrecalentados, cables defectuosos.

Preguntas frecuentes

1) ¿Cuánto debería tardar ext4 fsck en Debian 13?

Desde segundos (reproducción de journal) hasta horas (escaneo completo). Para sistemas de archivos de varios terabytes en HDD con muchos archivos pequeños, horas pueden ser normales. En SSD/NVMe, horas es sospechoso a menos que el sistema sea enorme o el dispositivo esté enfermo.

2) ¿Por qué fsck parece atascado sin actualizaciones de porcentaje?

Algunos pases no emiten progreso frecuente y las consolas de arranque pueden almacenar salida en buffer. Más importante: fsck puede estar bloqueado en E/S y aun así “ejecutarse”. Usa ps para ver el estado y iostat -x para distinguir.

3) ¿Puedo cancelar fsck?

Puedes, pero normalmente es una mala negociación. Interrumpir una reparación puede dejar el sistema de archivos en peor estado. Si sospechas fallo de hardware, la “cancelación” correcta es detener escrituras, imagenar el disco y recuperar de forma segura.

4) ¿Es seguro ejecutar fsck en un sistema montado?

Para ext4, ejecutar un fsck reparador en un sistema montado no es seguro. Usa -n solo para inspección en solo lectura si debes, y programa una ventana de inactividad para reparar offline.

5) ¿Por qué Debian ejecuta fsck en arranque?

Porque montar un sistema de archivos corrupto en modo lectura-escritura puede propagar el daño. La comprobación en arranque es una salvaguarda. A veces es molesto. Sigue siendo mejor que la corrupción silenciosa.

6) Mi servidor está virtualizado. ¿Qué cambia?

La latencia miente. Una VM puede mostrar “disco lento” porque el host está sobrecargado, el backend de almacenamiento está degradado o compites con vecinos ruidosos. Los diagnósticos a nivel VM aún ayudan, pero puede que necesites confirmación desde el host para cerrar el ciclo.

7) ¿Debería desactivar comprobaciones automáticas para volúmenes de datos grandes?

A menudo sí—si las reemplazas por comprobaciones programadas y monitorización. Usa 0 en el campo pass de fsck para el montaje de datos en /etc/fstab, mantén root comprobado y ejecuta fsck controlado en una ventana.

8) ¿Cuál es la diferencia entre journal replay y un fsck completo?

La reproducción del journal aplica transacciones pendientes y suele ser rápida. El fsck completo escanea estructuras de metadatos y puede tardar mucho, especialmente con muchos inodos y entradas de directorio.

9) fsck termina, pero el sistema aún no arranca. ¿Ahora qué?

Comprueba si el cargador de arranque o initramfs carecen de archivos, si /etc/fstab referencia un UUID incorrecto y si el disco subyacente sigue generando errores. Un fsck “exitoso” en un disco fallando puede ser temporal.

10) ¿XFS/Btrfs/ZFS tienen el mismo problema de fsck?

Tienen modos de fallo distintos. XFS usa xfs_repair (offline, puede ser pesado). Btrfs tiene sus propias herramientas y puede ser doloroso ante ciertas corrupciones. ZFS es totalmente diferente (scrubs, sumas de verificación). El tema común: la latencia de almacenamiento y fallos de hardware hacen que toda reparación parezca lenta.

Siguientes pasos que no te harán perder la noche

Si fsck en Debian 13 “tarda una eternidad”, no lo trates como el clima. Trátalo como un momento de diagnóstico.

1. En 10 minutos: revisa dmesg, iostat -x y SMART. Decide si estás ante una corrupción en almacenamiento sano o corrupción por almacenamiento que está fallando.
2. Si el hardware parece enfermo: detén intentos repetidos de reparación, protege los datos, reemplaza el dispositivo y luego repara/restaura.
3. Si el hardware parece sano: deja que fsck termine, pero arregla la causa de los apagados no limpios y revisa la política de comprobaciones en arranque para volúmenes no-root enormes.
4. Tras la recuperación: captura el log de fsck, ajusta los pass en /etc/fstab con criterio y establece líneas base de duración de comprobaciones para que el siguiente on-call no tenga que adivinar.

No necesitas amar las comprobaciones de sistema de archivos. Solo necesitas dejar de sorprenderte por ellas.