Dos fallos de Btrfs zoned en un HC620: bloqueo, modo de solo lectura y diagnóstico del kernel

Esta es una revisión de fallas real. El entorno es un disco duro SMR administrado por host Western Digital HC620, que utiliza zonas Btrfs, montado en /mnt/disk1, el sistema es Ubuntu 26.04 LTS y el kernel es:

1

Linux data-server 7.0.0-28-generic

La falla no fue una disminución normal de la velocidad del disco duro, sino que ocurrieron dos anomalías graves, una tras otra:

1. btrfs-cleaner y btrfs-transaction ingresan al estado ininterrumpible D y el sistema de archivos no se puede desmontar;
2. La transacción Btrfs se cancela con -11 y el kernel cambia activamente el sistema de archivos a solo lectura.

Ambas fallas ocurrieron cerca de eliminaciones de varios terabytes, replicaciones y recuperaciones de espacio zonificado. Al final, el sistema no se reinstaló y no se ejecutó btrfs check --repair. Este artículo conserva registros en el sitio, procesos de evaluación, comandos reales y partes no confirmadas tanto como sea posible para referencia de personas que encuentren problemas similares.

Nota: esto no demuestra que todas las instalaciones de Btrfs en un HC620 vayan a fallar, y una sola pila de llamadas no permite identificar un parche concreto del kernel. Las versiones del kernel y de los paquetes de Ubuntu reflejan el estado del sistema el 24 de julio de 2026. Consulte los repositorios actuales antes de seguir los pasos específicos de versión.

Entorno y proceso desencadenante

Este disco almacena principalmente copias de seguridad y datos fríos. Las operaciones antes del primer fallo son aproximadamente las siguientes:

1
2
3
4

删除约 3TB 旧数据
→ 从另一块盘复制约 3TB 新数据
→ Btrfs 后台清理与新写入重叠
→ btrfs-cleaner 锁死

El HC620 es un SMR administrado por host. Los discos se gestionan según zonas. Cada zona se muestra en el sitio como:

1

Device zone size: 256.00MiB

En estos dispositivos, las zonas escritas no se pueden sobrescribir arbitrariamente como en los discos duros CMR normales. Eliminar un archivo solo elimina la referencia al bloque de datos, y el espacio no válido que contiene debe esperar a que se recicle el grupo de bloques, se migren datos válidos y se restablezca la zona antes de poder reutilizarse. Btrfs mostrará esta parte del espacio como:

1

Device zone unusable

Entonces, “eliminar 3 TB y escribir 3 TB inmediatamente” no es solo una eliminación más una copia. Posiblemente sucediendo simultáneamente en segundo plano:

1
2
3
4
5
6
7

提交删除事务
删除空 block group
回收旧 chunk
finish/reset zone
分配新 chunk
激活新 zone
持续写入新数据

Esto se convierte en un trasfondo importante para el análisis posterior de la pila de llamadas.

Primer fallo: btrfs-cleaner bloqueado durante mucho tiempo

El registro inicial contiene:

1
2
3

INFO: task btrfs-cleaner:1488 blocked for more than 368 seconds.
Not tainted 7.0.0-28-generic #28-Ubuntu
task:btrfs-cleaner state:D pid:1488

La cadena de llamadas clave es:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

__mutex_lock_slowpath
mutex_lock
btrfs_chunk_alloc
btrfs_inc_block_group_ro
do_zone_finish
btrfs_zone_finish_one_bg
btrfs_zoned_activate_one_bg
reserve_chunk_space
check_system_chunk
btrfs_remove_chunk
btrfs_delete_unused_bgs
cleaner_kthread

Léelo de abajo hacia arriba, el proceso es:

1
2
3
4
5
6
7

btrfs-cleaner 清理未使用的 block group
→ 删除旧 chunk
→ 检查并预留 system chunk 空间
→ 激活 zoned block group
→ finish 一个 zone
→ 再次进入 chunk 分配
→ 等待 mutex

El registro también indica que es probable que el mutex esté retenido por el mismo subproceso btrfs-cleaner. Combinado con la cadena de llamadas, el juicio en el sitio es que el hilo de limpieza ingresa a la espera de bloqueo cuando se superponen la eliminación del grupo de bloques, el final de la zona y la asignación de nuevos fragmentos. Posteriormente, también se bloquearon btrfs-transaction y kworker que esperaban el vaciado de Btrfs.

Esta es una explicación de la pila de llamadas en el sitio, lo que no significa que se haya encontrado el único error ascendente correspondiente. Lo que es seguro es:

• El bloqueo ocurre en la ruta de limpieza de fragmentos/grupos de bloques de la zona Btrfs;
• El hilo ha entrado en el estado D en el estado del kernel;
• El kill -9 ordinario no puede terminar el hilo del kernel;
• Las operaciones continuas que dependen del compromiso de la transacción pueden quedar estancadas.

¿Qué comprobaciones se realizaron en primer lugar?

Primero detenga rsnapshot, rsync, contenedor Docker u otras tareas de escritura en disco, y luego verifique el proceso ininterrumpible:

1
2

ps -eo state,pid,ppid,comm,wchan:35,args | \
awk 'NR==1 || $1 ~ /^D/'

Guarde el registro del kernel de este inicio:

1
2
3
4
5

sudo journalctl -k -b \
  > /root/btrfs-hang-$(date +%F-%H%M).log

sudo dmesg -T | \
grep -iE 'btrfs|hung task|I/O error|ata|blk_update'

Guarde la pila de subprocesos correspondiente:

1
2

sudo cat /proc/1488/stack
sudo cat /proc/1489/stack

Agregue un tiempo de espera al consultar el sistema de archivos para evitar que el comando de diagnóstico se bloquee permanentemente:

1
2

sudo timeout 15s btrfs device stats /mnt/disk1
sudo timeout 15s btrfs filesystem usage /mnt/disk1

Luego intente una desinstalación normal:

1
2

cd /
sudo timeout 60s umount /mnt/disk1

apagar:

1

umount: /mnt/disk1: target is busy.

target is busy no es lo mismo que el bloqueo del kernel

target is busy normalmente significa que la siguiente referencia todavía está disponible:

• El directorio de trabajo actual del proceso se encuentra en /mnt/disk1;
• El archivo aún está abierto;
• El programa de copia de seguridad o copia todavía está en ejecución;
• Hay puntos de submontaje debajo de /mnt/disk1;
• El proceso de usuario ha entrado en el estado D debido al bloqueo del sistema de archivos.

Primero asegúrese de que todos los terminales salgan del directorio de montaje:

1
2

cd /
pwd

Verifique los submontajes y los ocupantes:

1
2
3
4

sudo findmnt -R /mnt/disk1
sudo timeout 15s fuser -vmM /mnt/disk1

pgrep -af 'rsnapshot|rsync|borg|restic|tar|cp|mv|docker'

Los procesos de usuario ordinarios se pueden finalizar normalmente antes de considerar la terminación forzada:

1
2
3

sudo kill -TERM 1234 5678
sleep 5
sudo kill -KILL 1234 5678

Si es rsnapshot o rsync:

1
2
3
4
5

sudo pkill -TERM -x rsnapshot
sudo pkill -TERM -x rsync
sleep 5
sudo pkill -KILL -x rsnapshot
sudo pkill -KILL -x rsync

Pero no intentes matar:

1
2

btrfs-cleaner
btrfs-transaction

Son hilos del núcleo. La inspección in situ muestra que el bloqueador principal es el subproceso del kernel Btrfs, y continuar con kill, umount o sync global no puede resolver la causa raíz.

¿Por qué no se utiliza el desmontaje diferido o el desmontaje forzado?

No se implementó en ese momento:

1
2

sudo umount -l /mnt/disk1
sudo umount -f /mnt/disk1

umount -l simplemente elimina primero el punto de montaje del árbol de directorios, y la referencia real del sistema de archivos aún tiene que esperar hasta que ya no esté ocupada antes de poder limpiarse. Cuando una transacción Btrfs está bloqueada, es posible que solo oculte el punto de montaje y no significa que los datos se hayan confirmado o que el sistema de archivos se haya desmontado.

umount -f tampoco es un medio confiable para aliviar los bloqueos locales del kernel Btrfs. Se usa más comúnmente en partes de la red o en sistemas de archivos en modo de usuario.

Tampoco se ejecuta:

1
2
3
4
5
6

sync
btrfs balance start /mnt/disk1
btrfs scrub start /mnt/disk1
btrfs filesystem defragment -r /mnt/disk1
mount -o remount,ro /mnt/disk1
btrfs check --repair /dev/sda

Estas operaciones pueden quedar esperando la transacción bloqueada o volver a entrar en la ruta problemática de recuperación de grupos de bloques.

Agregue noauto antes de reiniciar

Para evitar usar el mismo kernel para leer y escribir automáticamente este disco inmediatamente después de que se reinicie la máquina, primero verifique /etc/fstab:

1

grep -n '/mnt/disk1' /etc/fstab

Configuración de copia de seguridad:

1
2
3
4

sudo cp -a /etc/fstab \
  /etc/fstab.bak-$(date +%F-%H%M%S)

sudoedit /etc/fstab

Por ejemplo resultó ser:

1

UUID=xxxx /mnt/disk1 btrfs defaults 0 0

Cambiado temporalmente a:

1

UUID=xxxx /mnt/disk1 btrfs defaults,noauto 0 0

noauto significa sólo que no se montará automáticamente al arrancar, no que deshabilitará el sistema de archivos. Una vez iniciado el sistema, aún se puede montar manualmente como solo lectura o lectura-escritura.

Del reinicio normal al último recurso

Se realizó un reinicio normal en el sitio:

1

sudo systemctl reboot

Esta vez se completó normalmente y el sistema de archivos se pudo volver a montar después de reiniciar. Si el reinicio normal se atasca debido a Btrfs, el nivel de aplicación se incrementará paso a paso según el riesgo:

1

sudo systemctl reboot --force

El último recurso es:

1

sudo systemctl reboot --force --force

Dos --force ya no detienen el servicio y desmontan el sistema de archivos normalmente, el efecto es cercano a un restablecimiento completo y es posible que se pierdan datos no confirmados. Solo se puede usar cuando el sistema no se puede finalizar normalmente y no se puede usar como un comando de reinicio normal.

Verificar después de reiniciar

Primero confirme el kernel y el disco arrancados reales:

1
2
3

uname -a
lsblk -o NAME,SIZE,MODEL,FSTYPE,MOUNTPOINTS
sudo smartctl -x /dev/sda

Confirme que no hay montaje automático:

1

findmnt /mnt/disk1

Montar solo lectura por primera vez:

1

sudo mount -o ro /dev/sda /mnt/disk1

En el entorno real, primero se debe usar UUID o /dev/disk/by-id/, y el dispositivo predeterminado no siempre debe ser /dev/sda.

Verifique el registro del kernel, el recuento de dispositivos Btrfs y el estado del espacio:

1
2
3
4
5

sudo dmesg -T | \
grep -iE 'btrfs|ata|I/O error|medium error|uncorrect|reset'

sudo btrfs device stats /mnt/disk1
sudo btrfs filesystem usage /mnt/disk1

En vivo btrfs device stats todos 0:

1
2
3
4
5

[/dev/sda].write_io_errs    0
[/dev/sda].read_io_errs     0
[/dev/sda].flush_io_errs    0
[/dev/sda].corruption_errs  0
[/dev/sda].generation_errs  0

Esto muestra que Btrfs no registra errores de lectura y escritura, descarga, verificación o generación del dispositivo, lo cual es una buena señal. Pero esto no prueba que se haya solucionado el bloqueo del kernel ni descarta el problema de los datos no leídos.

Qué hace scrub y qué no hace

Se programa una limpieza después de que el sistema esté estable:

1
2

sudo btrfs scrub start /mnt/disk1
sudo btrfs scrub status /mnt/disk1

Si desea que la recepción espere los resultados:

1

sudo btrfs scrub start -B /mnt/disk1

Cancelar tarea:

1

sudo btrfs scrub cancel /mnt/disk1

Scrub lee los datos y metadatos almacenados y verifica la suma de verificación guardada por Btrfs. Se utiliza para encontrar errores de lectura, errores de validación de datos o metadatos, no:

1
2
3
4
5
6

碎片整理
空间回收
balance
坏道修复
完整 fsck
内核死锁修复

Si el resultado es:

1

Error summary: no errors found

Solo puede mostrar que no se encontró ninguna excepción en esta lectura y verificación, pero no puede probar que la ruta de limpieza por zonas de btrfs-cleaner no se bloqueará nuevamente en el futuro.

Guardar resultados:

1
2

sudo btrfs scrub status /mnt/disk1 | \
sudo tee /root/btrfs-scrub-$(date +%F).log

No ejecute rsync, rsnapshot, balance ni realice eliminaciones masivas al mismo tiempo durante Scrub. Para este tipo de disco de respaldo, se puede realizar cada uno a tres meses según la intensidad de uso real.

Por qué no se ejecutó balance para «recuperar espacio»

Apareció en el lugar:

1

Data,single: 98.67%

Este número solo representa el uso del grupo de bloques de datos asignado y no significa que solo quede el 1,33% de todo el disco. En ese momento, todavía quedaban varios TiB Device unallocated y no faltaba espacio para seguir asignando.

Entonces no hay ejecución:

1
2

sudo btrfs balance start /mnt/disk1
sudo btrfs balance start -dusage=0 /mnt/disk1

Balance reubicará el grupo de bloques donde se encuentra la primera falla:

1
2
3
4

btrfs_delete_unused_bgs
btrfs_remove_chunk
btrfs_zoned_activate_one_bg
do_zone_finish

Ejecutar balance con el kernel afectado puede volver a entrar en rutas similares de eliminación de grupos de bloques y recuperación de zonas.

Cómo manejar eliminaciones y escrituras de varios terabytes

El ajuste del flujo de trabajo más eficaz es copiar y verificar datos nuevos antes de eliminar los datos antiguos cuando haya suficiente espacio.

1
2
3
4

先复制新数据
→ 校验复制结果
→ 暂停新写入并观察
→ 分批删除旧数据

Copiar:

1
2
3

rsync -aHAX --info=progress2 \
  /来源目录/ \
  /mnt/disk1/目标目录/

Comparar capacidad:

1

du -sh /来源目录 /mnt/disk1/目标目录

Practica usar el método de verificación de contenido sin modificar el objetivo:

1
2
3

rsync -aHAXnc \
  /来源目录/ \
  /mnt/disk1/目标目录/

Cuando sea necesario eliminar primero, no elimine varios TB a la vez y luego escriba inmediatamente. Se puede dividir en lotes de 200~500GiB por fecha, subdirectorio o capacidad:

1
2

rm -rf /mnt/disk1/旧数据/第一批
sudo btrfs filesystem sync /mnt/disk1

btrfs filesystem sync confirmará la transacción del sistema de archivos y activará el trabajo de limpieza relacionado, pero el retorno del comando no significa que se hayan completado todos los grupos de bloques y la recuperación de zonas.

Si está eliminando un subvolumen o una instantánea de Btrfs, también puede ejecutar:

1

sudo btrfs subvolume sync /mnt/disk1

Espera a que el subvolumen para el cual se envió la solicitud de eliminación complete la limpieza y no se aplica a las eliminaciones normales de rm -rf.

Verifique después de cada lote:

1
2
3
4
5
6
7
8

sudo btrfs filesystem usage /mnt/disk1
sudo btrfs device stats /mnt/disk1

ps -eo state,pid,comm,wchan:35,args | \
awk 'NR==1 || $1 ~ /^D/'

sudo journalctl -k --since "30 minutes ago" | \
grep -iE 'btrfs.*(blocked|hung|error|warning)|I/O error'

Cumple las siguientes condiciones antes de continuar:

• btrfs filesystem sync regresa normalmente;
• No hay subprocesos Btrfs en estado D;
• No hay nuevos errores bloqueados, colgados, abortados o Btrfs en el registro del kernel;
• La actividad del disco ha disminuido significativamente;
• Device zone unusable no está creciendo rápidamente.

No es necesario reducir Device zone unusable a cero. Puede permanecer en unas decenas de GiB hasta alcanzar el siguiente umbral de recuperación; eso por sí solo no significa que el sistema de archivos siga ocupado o bloqueado.

Las escrituras también se pueden realizar por lotes, con prioridad y ancho de banda limitados:

1
2
3
4

sudo ionice -c2 -n7 nice -n 15 \
rsync -aHAX --info=progress2 --bwlimit=100M \
  /来源目录/ \
  /mnt/disk1/目标目录/

--bwlimit=100M es sólo un punto de partida conservador. La limitación de velocidad no puede solucionar los errores del kernel, pero puede reducir la probabilidad de que el limpiador, la confirmación de transacciones, la reescritura y la activación de zonas estén bajo una carga alta al mismo tiempo. No ejecute varios rsyncs grandes al mismo tiempo.

Supervisar las métricas de recuperación zoned

Primero obtenga el UUID del sistema de archivos:

1
2
3
4

FSID=$(sudo btrfs filesystem show /mnt/disk1 | \
       awk '/uuid:/ {print $NF; exit}')

echo "$FSID"

Consulta los indicadores de espacio y recuperación de datos, metadatos y sistema:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

for type in data metadata system; do
    echo "===== $type ====="
    base="/sys/fs/btrfs/$FSID/allocations/$type"

    grep -H . \
      "$base/bytes_pinned" \
      "$base/bytes_reserved" \
      "$base/bytes_may_use" \
      "$base/bytes_zone_unusable" \
      "$base/reclaim_count" \
      "$base/reclaim_bytes" \
      "$base/reclaim_errors" \
      "$base/periodic_reclaim" \
      "$base/dynamic_reclaim" \
      "$base/bg_reclaim_threshold" 2>/dev/null
done

en:

• bytes_pinned: espacio que normalmente no se puede liberar hasta que se confirme la transacción actual;
• bytes_zone_unusable: espacio zonificado que ha caducado pero que no se puede reutilizar directamente;
• reclaim_count: número acumulado de intentos de recuperación;
• reclaim_bytes: el número acumulado de bytes reciclados;
• reclaim_errors: número acumulado de errores de recuperación.

También puede ver las estadísticas de confirmación de transacciones:

1

cat "/sys/fs/btrfs/$FSID/commit_stats"

Si max_commit_ms dura decenas o cientos de segundos, o el registro aparece nuevamente:

1
2

btrfs-cleaner blocked
btrfs-transaction blocked

Debe detener la tarea de copia de seguridad y guardar el registro, no continuar ingresando datos y esperar a que se recupere por sí solo.

Deshabilitar la superposición de tareas de respaldo

Todos los ciclos de rsnapshot utilizan el mismo bloqueo:

1
2
3
4

/usr/bin/flock -n /run/lock/rsnapshot.lock \
  /usr/bin/ionice -c2 -n7 \
  /usr/bin/nice -n 15 \
  /usr/bin/rsnapshot daily

weekly y monthly también utilizan:

1

/run/lock/rsnapshot.lock

Esto puede evitar que se realicen rsync diarios, semanales, mensuales y una gran cantidad al mismo tiempo. Las depuraciones, eliminaciones masivas y copias grandes también deben programarse para diferentes períodos de tiempo.

Segundo error: transacción abortada y forzada a solo lectura

Después del primer fallo y reinicio, el sistema de archivos se puede montar normalmente y no hay errores en las estadísticas del dispositivo. Pero al volver a escribir una gran cantidad de datos más tarde, se produjo un error de transacción más explícito:

1
2
3
4
5
6

BTRFS error (device sda): error while writing out transaction: -11
BTRFS warning (device sda): Skipping commit of aborted transaction.
BTRFS: Transaction aborted (error -11)
BTRFS: error (device sda state A) in cleanup_transaction:2060:
errno=-11 unknown
BTRFS info (device sda state EA): forced readonly

El entorno operativo sigue siendo:

1
2

CPU: 0 PID: 1678 Comm: btrfs-transacti
Not tainted 7.0.0-28-generic #28-Ubuntu

Esta vez no está “bloqueado temporalmente”, pero la transacción se canceló y el kernel cambia activamente a solo lectura para proteger el sistema de archivos. -11 corresponde a EAGAIN, pero el código específico que lo activa no se puede determinar basándose únicamente en errno.

Las estadísticas del dispositivo en ese momento todavía eran 0:

1
2
3
4
5

write_io_errs    0
read_io_errs     0
flush_io_errs    0
corruption_errs  0
generation_errs  0

El estado del espacio no está lleno:

1
2
3
4
5

Device size:            12.73TiB
Device allocated:        4.95TiB
Device unallocated:      7.78TiB
Device zone unusable:   53.58GiB
Used:                    4.88TiB

Este conjunto de evidencia favorece anomalías en la escritura interna, la asignación de fragmentos o la lógica de transacciones de Btrfs zonificados en lugar de errores de E/S de medios comunes o ENOSPC en todo el disco. Sin embargo, sin un análisis completo del primer error y el código fuente correspondiente, no se debe afirmar que la causa sea un parche determinado.

Manejo correcto después de solo lectura forzada

No lo intentes:

1
2
3
4

sudo mount -o remount,rw /mnt/disk1
sudo btrfs balance start /mnt/disk1
sudo btrfs filesystem sync /mnt/disk1
sudo btrfs check --repair /dev/sda

Primero detenga la tarea de escritura:

1
2
3
4

sudo pkill -TERM -x rsync
sudo pkill -TERM -x rsnapshot

pgrep -af 'rsync|rsnapshot|btrfs balance|btrfs scrub'

Guarde los registros completos antes y después de la falla. El primer error que realmente hace que la transacción se cancele puede aparecer docenas de líneas antes de forced readonly:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

sudo journalctl -k -b \
  --since "2026-07-24 17:20:00" \
  --until "2026-07-24 17:35:00" \
  > /root/btrfs-abort-2026-07-24.log

sudo dmesg -T \
  > /root/dmesg-btrfs-abort-2026-07-24.log

sudo smartctl -x /dev/sda \
  > /root/smart-sda-2026-07-24.log

Confirmar opciones de montaje:

1

findmnt -no TARGET,SOURCE,FSTYPE,OPTIONS /mnt/disk1

ro debería aparecer allí. Luego desinstale y reinicie normalmente:

1
2
3

cd /
sudo umount /mnt/disk1
sudo reboot

Si indica ocupado:

1

sudo fuser -vmM /mnt/disk1

Detenga los procesos de usuario normales enumerados antes de desinstalar.

Comprobar si la copia quedó incompleta

Parte de los datos que se escribieron antes de que se cancelara la transacción no pueden considerarse directamente como una copia de seguridad completa. Puede aparecer:

• El archivo aún no ha sido creado;
• La longitud del archivo está incompleta;
• Los datos se escriben, pero la entrada del directorio o la marca de tiempo no se confirman;
• Se revierten los cambios en la última transacción.

Por lo tanto, se debe conservar el disco de origen. Después de cambiar a un entorno estable y volver a leer y escribir el montaje, use el rsync original para completar:

1
2
3
4

sudo ionice -c2 -n7 nice -n 15 \
rsync -aHAX --info=progress2 \
  /来源目录/ \
  /mnt/disk1/目标目录/

Luego use el modo de verificación para verificar:

1
2
3

rsync -aHAXnc \
  /来源目录/ \
  /mnt/disk1/目标目录/

Sin resultados significa que rsync no ha encontrado nada que deba actualizarse.

Solución kernel: primero distinga entre pruebas y uso a largo plazo

Continuamente han aparecido la misma máquina, la misma 7.0.0-28-generic y la misma HC620:

1. btrfs-cleaner está bloqueado con el hilo de transacción;
2. error -11, transacción cancelada, solo lectura forzada.

Por lo tanto, ya no seguiremos usando este kernel para leer y escribir terabytes de datos en este disco. Se discutieron tres rutas:

Lo más importante aquí no es buscar el número de versión más grande, sino:

• Mantener un kernel antiguo que pueda iniciarse;
• Realice únicamente un arranque de GRUB por primera vez;
• Montar primero el modo de solo lectura;
• Prueba paso a paso de 100 a 200GiB;
• “Escribir 3 TB inmediatamente después de eliminar 3 TB” ya no se reproduce directamente.

Confirmado en Ubuntu 24.04 6.8 GA

No mezcle paquetes de Ubuntu 24.04 con Ubuntu 26.04 existente. Una forma más segura es instalar Ubuntu Server 24.04 en otro SSD y luego montar el disco de datos HC620 para realizar pruebas.

Instale y conserve el metapaquete 6.8 GA:

1
2
3

sudo apt update
sudo apt install --install-recommends linux-generic-6.8
sudo reboot

Confirmar sistema y kernel:

1
2
3
4
5

cat /etc/os-release
uname -r

dpkg -l | \
grep -E '^ii +linux-(generic|image-generic|headers-generic)(-6\.8)? '

La clave es que uname -r comienza con 6.8. y no codifica una determinada versión del parche de forma permanente.

Consulta el repositorio actual en lugar de copiar la versión histórica de este artículo:

1
2
3
4

apt-cache policy \
  linux-generic-6.8 \
  linux-generic \
  linux-generic-hwe-24.04

Si las pruebas apuntan a GA 6.8, no permita que linux-generic-hwe-24.04 lleve el sistema a otra línea principal de HWE.

Prueba a corto plazo en Ubuntu 24.04 6.17

Primero compruebe si los repositorios actuales todavía ofrecen y mantienen el paquete:

1
2
3
4
5

sudo apt update

apt-cache policy \
  linux-generic-6.17 \
  linux-image-generic-6.17

Después de confirmar que el paquete aún está disponible, instálelo explícitamente:

1
2

sudo apt install --install-recommends linux-generic-6.17
sudo update-grub

Documento de confirmación:

1

ls -lh /boot/vmlinuz-6.17.0-*-generic

Comience solo una vez por primera vez. La versión completa a continuación debe reemplazarse con la versión realmente instalada en su máquina:

1
2
3
4
5

sudo grub-reboot \
  'Advanced options for Ubuntu>Ubuntu, with Linux 6.17.0-xx-generic'

sudo grub-editenv - list
sudo reboot

Verifique después de reiniciar:

1

uname -r

El repositorio Noble 24.04 no debe agregarse a Ubuntu 26.04 para forzar la instalación de este kernel; de lo contrario, puede introducir firmware, DKMS, initramfs y problemas posteriores de mantenimiento de apt.

Límites al probar 7.1 Mainline

El paquete Mainline es adecuado para verificar “si el nuevo kernel ascendente cambia el comportamiento de falla” y no es equivalente al kernel de producción oficial de Ubuntu. Debe comprobar antes de la instalación:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

. /etc/os-release
echo "$PRETTY_NAME  codename=$VERSION_CODENAME"

dpkg --print-architecture
df -h /boot /

sudo apt update
sudo apt install -y mokutil
mokutil --sb-state
dkms status

El riesgo de las pruebas aumenta significativamente si el arranque seguro está habilitado, hay módulos DKMS críticos presentes o el servidor no tiene una consola fuera de banda. La versión específica, el nombre del archivo y el valor de verificación deben volver a obtenerse del [Ubuntu Mainline Kernel Archive] actual (https://kernel.ubuntu.com/mainline/), y las direcciones de descarga caducadas no deben copiarse.

Mantenga el kernel de arranque actual e inicie el nuevo kernel de una vez a través de GRUB. Verificar después del inicio:

1
2
3
4
5
6
7
8

uname -r
systemctl --failed
ip addr
ip route
dkms status

sudo dmesg -T | \
grep -iE 'btrfs|hung task|blocked for more|I/O error|ata|medium error|uncorrect'

Primer montaje y prueba del nuevo kernel

Ya sea que pruebe 6.8, 6.17 o actualice el kernel, primero mantenga noauto en /etc/fstab y móntelo como solo lectura después del inicio:

1
2
3
4
5
6
7

sudo mount -o ro /dev/sda /mnt/disk1

sudo journalctl -k -b | \
grep -iE 'btrfs|error|warning|abort|readonly|hung|blocked|I/O error'

sudo btrfs device stats /mnt/disk1
sudo btrfs filesystem usage /mnt/disk1

Después de que no haya nuevos errores:

1
2
3
4

sudo umount /mnt/disk1
sudo mount /dev/sda /mnt/disk1

findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /mnt/disk1

Prueba paso a paso:

1
2
3
4
5
6

写入 100～200GiB
→ btrfs filesystem sync
→ 检查日志和 D 状态
→ 删除 100～200GiB
→ 等待并再次检查
→ 再写入下一批

El hecho de que pase un lote pequeño no significa inmediatamente que esté “arreglado” con terabytes de presión. Como mínimo, se requieren múltiples rondas, grandes cantidades de datos y tiempos de ejecución prolongados para mejorar la confianza.

Si se debe reformatear Btrfs

Reformatear puede dar como resultado un sistema de archivos limpio, pero no puede solucionar por sí solo los problemas de rutas de zonas del kernel. Ambas excepciones ocurrieron en el grupo de bloques, la zona y la ruta de transacción en tiempo de ejecución, y las estadísticas del dispositivo no tuvieron errores de medios.

Reconstruir el sistema de archivos sólo tiene sentido cuando:

• btrfs check --readonly Se encontró un error estructural explícito;
• Scrub sigue presentando errores de verificación irreparables;
• No se puede montar normalmente o se siguen produciendo errores de generación;
• Se ha decidido ajustar el perfil de datos/metadatos;
• Prepárese para reemplazar el sistema de archivos.

Incluso si desea reconstruir, primero complete otra copia de seguridad verificable en lugar de tratar el formateo como un comando de prueba y error.

Cómo elegir entre Btrfs y F2FS

F2FS puede omitir la ruta de llamada específica de Btrfs que aparece esta vez:

1
2
3
4
5

btrfs_delete_unused_bgs
btrfs_remove_chunk
btrfs_zone_finish_one_bg
Btrfs chunk allocation
Btrfs transaction commit

Pero no es una solución “libre de problemas”. F2FS también tiene riesgos en GC, migración de segmentos, restablecimiento de zonas, recuperación de fallas de energía y reparación del sistema de archivos. Aún pueden producirse retrasos prolongados en la GC en primer plano con escrituras grandes inmediatamente después de eliminaciones grandes.

Las principales compensaciones entre los dos son:

Si el HC620 es solo uno de varios respaldos, F2FS más paridad externa es aceptable. Ni el uso de Btrfs ni F2FS de disco único es lo suficientemente seguro si es la única copia.

Puede guardar la lista SHA256 en otro disco cuando utilice F2FS:

1
2
3
4
5
6

cd /mnt/disk1

find backup_data -type f -print0 | \
sort -z | \
xargs -0 sha256sum \
  > /其他磁盘/backup_data.sha256

Verificar más tarde:

1
2

cd /mnt/disk1
sha256sum -c /其他磁盘/backup_data.sha256

El propio ECC de la unidad, la reasignación de sectores defectuosos y el SATA CRC seguirán funcionando, pero no cubren el vínculo completo de extremo a extremo entre aplicaciones, memoria, sistemas de archivos, controladores y discos. La suma de comprobación de Btrfs y el ECC del disco duro son funciones complementarias, no duplicadas.

Principio de procesamiento final

Esta solución de problemas dio como resultado las siguientes reglas prácticas:

1. Ya no utilice 7.0.0-28-generic para realizar lecturas y escrituras a gran escala de este HC620;
2. Conservar los datos fuente y al menos una copia independiente;
3. Copie y verifique primero, luego elimine en lotes;
4. Divida varias operaciones de TB en lotes de 200 ~ 500 GiB;
5. rsync, rsnapshot, Scrub, eliminación masiva y equilibrio no se superponen;
6. Deje de escribir inmediatamente después de que aparezca el estado D o el registro de tareas colgadas;
7. No fuerce el reinicio, rw después de forzar solo lectura;
8. No utilice btrfs check --repair para realizar intentos a ciegas;
9. El núcleo de prueba debe conservar los elementos de reversión y comenzar con un montaje de solo lectura;
10. La confiabilidad a largo plazo proviene primero de las copias múltiples y, en segundo lugar, de la selección del sistema de archivos.

Toda la cadena de fallas se puede resumir como:

1
2
3
4
5
6
7

数 TB 删除
→ zoned 无效空间和后台回收增加
→ 数 TB 新写入与 chunk/zone 管理交叠
→ 第一次：btrfs-cleaner 锁等待，事务线程阻塞
→ 重启后暂时恢复，scrub 与设备计数未见错误
→ 再次大量写入
→ 第二次：transaction -11，中止并 forced readonly

Este conjunto de resultados es suficiente para mostrar que la combinación actual “HC620 + Btrfs zonificado + 7.0.0-28 + CLOS” no es adecuada para continuar con tareas desatendidas a gran escala, pero no es suficiente para demostrar que todos los HC620, todos los Btrfs zonificados o todos los núcleos 7.0 tienen el mismo problema.

Referencias

• Modo de zona Btrfs
• Btrfs fregado
• Btrfs balance
• Interfaz sysfs Btrfs
• Documentación Btrfs del kernel de Linux
• Archivo del núcleo principal de Ubuntu
• Sitio: Malentendidos y uso correcto del disco con tejas Western Digital HC620