Operaciones

Qué hacer si Btrfs queda en solo lectura al llenarse un disco SMR HC620: recuperación segura de espacio y diagnóstico

Explica cómo conservar los registros, distinguir ENOSPC de errores de E/S, liberar espacio de forma segura, usar balance con cautela y verificar la recuperación cuando Btrfs zoned queda en solo lectura al llenarse un HC620 Host-Managed SMR.

Si utiliza Btrfs zoned en un HC620 y el sistema de archivos queda de repente en solo lectura al acercarse al 100%, las pistas principales suelen ser ENOSPC, falta de espacio de trabajo para zone reclaim o un cambio forzado a solo lectura después de que falle el commit de una transacción.

Sin embargo, “completo” y “solo lectura” solo pueden describir los síntomas cuando ocurre la falla, pero no pueden probar directamente que el disco duro no esté dañado. El orden correcto es:

  1. Deje de escribir tareas inmediatamente;
  2. Guarde el registro del kernel cuando ocurra la falla;
  3. Confirme el dispositivo, el estado de montaje y la distribución del espacio por zonas;
  4. Diferenciar entre agotamiento puro del espacio, recopilación bloqueada, cancelación de transacciones y errores de E/S de bajo nivel;
  5. Solo cuando la evidencia respalde ENOSPC puro, intente montarlo nuevamente en modo lectura-escritura y libere espacio en lotes;
  6. Una vez recuperado el espacio, realice únicamente tareas de bajo riesgo y complete la verificación de la recuperación.

No ejecute mount -o remount,rw, un balance sin filtros ni btrfs check --repair solo porque el sistema de archivos esté en modo de solo lectura. Es una respuesta de protección; primero localice el error inicial que la activó.

Este artículo supone que el punto de montaje es /mnt/hc620. El nombre del dispositivo está representado únicamente por /dev/sdX, que debe reemplazarse por el dispositivo o partición real antes de la ejecución. No copie la letra de la unidad.

¿Por qué es más difícil liberar espacio en el HC620 que en un disco duro normal una vez lleno?

El Western Digital Ultrastar DC HC620 es un SMR administrado por host, es decir, un disco dividido donde el host administra el área de escritura.

Linux normalmente lo expone como un dispositivo de bloque zonificado:

1

lsblk -o NAME,MODEL,SIZE,TYPE,FSTYPE,ZONED,MOUNTPOINTS

Espere ver algo como:

1
2

NAME MODEL              SIZE TYPE FSTYPE ZONED        MOUNTPOINTS
sda  HSH721414ALE6M0   12.7T disk btrfs  host-managed /mnt/hc620

El modelo real, la visualización de capacidad y el nombre del dispositivo pueden ser diferentes, y prevalecerá la salida de esta máquina.

Los discos duros CMR normales pueden sobrescribir los sectores asignados. La zona de escritura secuencial del SMR administrado por host debe continuar escribiendo desde el puntero de escritura actual; Para reutilizar una zona escrita, generalmente es necesario mover primero los datos aún válidos y luego restablecer toda la zona.

Btrfs admite el modo por zonas a partir de Linux 5.12. Utiliza VACA. Después de sobrescribir un archivo, actualizar o eliminar metadatos, es posible que el sistema de archivos ya no haga referencia al bloque de datos antiguo, pero no se convertirá inmediatamente en una zona vacía reescribible.

Estos espacios aparecerán en btrfs filesystem usage como:

1

Device zone unusable

No significa “capacidad del disco duro permanentemente dañada”, sino espacio que se ha escrito en el pasado y al que ya no se hace referencia, pero que aún necesita pasar por la recuperación del grupo de bloques y el restablecimiento de zona antes de poder reutilizarse.

El proceso de reclaim necesita trasladar los datos que siguen siendo válidos a una zona nueva. Si no hay suficientes zonas de destino, puede producirse un ENOSPC transitorio.

Entonces, en el HC620:

1

文件层面删除了 1 TiB

No necesariamente inmediatamente igual a:

1

底层马上多出 1 TiB 可写空间

Esta es también la razón por la cual los Btrfs zonificados son más difíciles de procesar en el sitio que un disco normal después de que se escribe hasta el límite.

Qué tareas detener de inmediato

Después de descubrir que el punto de montaje es de solo lectura, no vuelva a intentar la tarea de copia original repetidamente.

Comience por detener los servicios que puedan continuar generando E/S o registrando ruido, como por ejemplo:

  • rsync, rclone o tareas de descarga;
  • contenedores y máquinas virtuales;
  • Escaneo de la biblioteca multimedia;
  • Instantáneas y copias de seguridad programadas;
  • tareas de limpieza, equilibrio o eliminación masiva.

Primero compruebe si hay un balance o scrub en curso:

1
2

sudo btrfs balance status /mnt/hc620
sudo btrfs scrub status /mnt/hc620

No cancele tareas de forma automática solo para ejecutar estas instrucciones. Registre primero el estado. Si hay un balance o scrub en curso y el sistema todavía responde, utilice los registros para determinar si forma parte del fallo.

Compruebe qué procesos siguen ocupando el punto de montaje:

1

sudo fuser -vm /mnt/hc620

Este comando es sólo para observación y no finalizará automáticamente el proceso.

Guardar los registros antes de desmontar o reiniciar

Lo más valioso en dmesg a menudo no es la última línea forced readonly, sino el primer error anterior.

Primero guarde el registro completo del kernel en otro disco normal, como el disco del sistema:

1

sudo journalctl -k -b --no-pager > "$HOME/hc620-kernel-current-boot.log"

Luego extraiga las líneas relevantes:

1
2
3

sudo dmesg -T | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error' | \
tail -200

Si la máquina se ha reiniciado, verifique el último inicio:

1
2

sudo journalctl -k -b -1 --no-pager | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error'

Si el sistema no tiene un diario persistente, es posible que el registro del último inicio no exista. Por lo tanto, el sitio del error debería intentar exportar el registro primero y luego reiniciar.

Guarde también el entorno base:

1
2
3
4

uname -a
btrfs version
lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,FSTYPE,ZONED,MOUNTPOINTS
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

Entre ellos, si OPTIONS de findmnt contiene ro, solo puede confirmar que el montaje actual es de solo lectura, pero no puede explicar por qué pasó a ser de solo lectura.

Identificar el dispositivo sin adivinar /dev/sdX

Primero verifique el dispositivo fuente desde el punto de montaje:

1

findmnt -no SOURCE /mnt/hc620

Verifique los dispositivos en el sistema de archivos nuevamente:

1

sudo btrfs filesystem show /mnt/hc620

Confirmar vínculo estable del dispositivo:

1

ls -l /dev/disk/by-id/

Si el sistema de archivos está construido en una partición, los montajes posteriores deben usar la partición en lugar de todo el disco. Por ejemplo, si el dispositivo fuente real es /dev/sda1, no se puede escribir como /dev/sda.

Al registrar resultados reales como variables, también se requiere verificación manual:

1
2
3
4
5

DEV=/dev/disk/by-id/你的实际设备或分区链接
MNT=/mnt/hc620

lsblk -f "$DEV"
findmnt "$MNT"

No ejecute los marcadores de posición chinos en el ejemplo tal como están.

Leer la distribución espacial de Btrfs

Ejecute mientras el sistema de archivos aún está montado:

1
2
3

sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs filesystem df /mnt/hc620
sudo btrfs device usage /mnt/hc620

Notas clave:

1
2
3
4
5
6
7

Device size
Device allocated
Device unallocated
Device zone unusable
Data,single
Metadata,single 或 Metadata,DUP
Global reserve

Una cartera típica de alto riesgo se ve así:

1
2
3
4
5

Device allocated:       接近 Device size
Device unallocated:     0.00 B 或非常少
Device zone unusable:   数十至数百 GiB
Data 使用率:            接近 100%
Metadata 使用率:        很高

No se limite a mirar df -h. Los datos, metadatos, grupo de bloques del sistema y espacio no asignado del dispositivo de Btrfs se encuentran en diferentes niveles; COW también necesita nuevo espacio para completar transacciones.

Device zone unusable no se puede utilizar solo como conclusión de falla:

  • Un valor distinto de cero es un fenómeno normal después de que funciona el COW zonificado;
  • Si el valor es muy grande y Device unallocated está cerca de 0, significa que el espacio recuperable y el espacio inmediatamente asignable están muy desalineados;
  • Los valores pueden cambiar durante la recopilación en segundo plano;
  • Incluso si es 0, esto no descarta el agotamiento de los metadatos o errores de E/S subyacentes.

Comprobar los contadores persistentes de errores del dispositivo

implementar:

1

sudo btrfs device stats /mnt/hc620

Ejemplo de salida normal:

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

El significado de cada elemento:

  • write_io_errs: el dispositivo del bloque inferior no pudo completar la solicitud de escritura;
  • read_io_errs: el dispositivo del bloque inferior no pudo completar la solicitud de lectura;
  • flush_io_errs: Falló la escritura con FLUSH, relacionado con el orden de colocación de la transacción;
  • corruption_errs: Se encontró una suma de comprobación que no coincide o un encabezado de metadatos dañado;
  • generation_errs: la generación del bloque no coincide con las expectativas del nodo principal.

Todos los 0 son una buena señal, pero no una prueba de que el disco esté en buen estado. También combine registros del kernel, SMART, HBA y evaluación de errores de enlace.

No lo uses todavía:

1

sudo btrfs device stats -z /mnt/hc620

-z borrará el recuento después de imprimir. Si la evidencia de falla se elimina antes de guardarla, se perderán puntos de referencia importantes.

Si realmente desea observar si los errores continúan aumentando, primero guarde el resultado actual y luego registre el tiempo:

1
2

date -Is
sudo btrfs device stats /mnt/hc620

Compare nuevamente después de completar las pruebas controladas en lugar de simplemente mirar una sola instantánea.

Clasificar el fallo en cuatro categorías mediante los registros

Categoría 1: falta de espacio o ENOSPC temporal

Otras pruebas que respaldan esta categoría incluyen:

1
2
3
4

No space left on device
ENOSPC
transaction aborted
forced readonly

Satisfacer a ambos:

  • btrfs device stats no tiene errores distintos de cero;
  • No hay ningún I/O error en el registro;
  • Sin errores de suma de comprobación, verificador de árbol, hoja corrupta o transid principal;
  • De hecho, el sistema de archivos está casi lleno;
  • Device unallocated es poco común o el reciclaje zonificado es significativamente limitado.

Esta situación es adecuada para ingresar al proceso posterior de “montaje controlado de lectura y escritura y liberación de espacio”.

Categoría 2: zone reclaim o block group reclaim bloqueado

El registro puede aparecer:

1
2
3
4
5

btrfs-cleaner
btrfs_delete_unused_bgs
btrfs_zone_finish
do_zone_finish
blocked for more than ... seconds

El problema en este punto no es necesariamente solo que el número de capacidad se ponga a cero, sino que también puede involucrar rutas de reciclaje, largas esperas de bloqueo o límites de zonas activas en zonas bajo un kernel específico.

No ejecute un balance sin filtros en este momento. Guarde primero la pila de llamadas, la versión del kernel y los registros completos; después consulte el análisis del fallo real publicado en el sitio:

[Revisión de dos fallas zonificadas de Btrfs en HC620: bloqueo, solo lectura y solución de problemas del kernel] (/es/2026/07/24/hc620-btrfs-zoned-deadlock-readonly-troubleshooting/)

Categoría 3: transacción abortada con causa aún no determinada

Las siguientes líneas sólo describen los resultados:

1
2
3

transaction aborted
BTRFS error
forced readonly

La verdadera razón suele ser evidente. Debe buscar entre docenas y cientos de líneas para encontrar el primer error, el código de retorno y la pila de llamadas.

Todo transaction aborted no se puede clasificar como completo. Los fallos de escritura de bajo nivel, los fallos de validación de metadatos y los errores del kernel también pueden abortar las transacciones.

Categoría 4: errores de E/S, checksum o estructura

Si aparece alguna de las siguientes pistas, debes detener el proceso de “eliminar algunos archivos y se solucionará”:

1
2
3
4
5
6
7
8
9

I/O error
write_io_errs
read_io_errs
flush_io_errs
checksum error
corrupt leaf
parent transid verify failed
tree-checker
zone write pointer

En este momento, se da prioridad a proteger las copias de datos y verificar los discos, los HBA SAS/SATA, los cables, las fuentes de alimentación y los errores de zona del kernel. No interprete simplemente un recuento de dispositivos distinto de cero como “sólo un disco lleno”.

Montar primero en solo lectura y rescatar los datos

Si aún se puede leer el montaje actual, copie primero los datos más importantes que no tengan otras copias.

Si necesita desmontar y volver a montar, salga primero de cualquier shell que esté usando el directorio y después ejecute:

1
2

cd /
sudo umount /mnt/hc620

Confirme que se ha desmontado:

1

findmnt /mnt/hc620

Sin salida significa que el punto de montaje no está en la tabla de montaje actual.

Primer montaje en modo de solo lectura:

1
2

sudo mount -o ro "$DEV" /mnt/hc620
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

Luego copie los archivos importantes a otro disco en buen estado. No vuelva a colocar el directorio de destino en el HC620 durante un rescate de solo lectura.

Si falla el montaje normal de solo lectura, no superponga aleatoriamente el parámetro rescue=. Diferentes errores requieren diferentes opciones de rescate. Los parámetros de error pueden cubrir el registro o cambiar los resultados de la lectura. La decisión debe tomarse basándose en el informe de error específico.

Cuándo intentar un nuevo montaje de lectura y escritura

Se podrá considerar un intento controlado cuando se cumplan simultáneamente las siguientes condiciones:

  • Registro de fallos guardado;
  • Los datos importantes tienen otras copias o se ha completado primero el rescate de solo lectura;
  • La primera razón en el registro apunta claramente a ENOSPC;
  • Sin errores de E/S, suma de comprobación, comprobador de árbol o puntero de escritura de zona;
  • btrfs device stats no tiene ningún recuento de excepciones;
  • No hay tareas del kernel antiguas atascadas;
  • El sistema de archivos se puede desmontar limpiamente.

Primero desmonte el sistema de archivos de solo lectura:

1

sudo umount /mnt/hc620

Realice un montaje nuevo en lugar de usar remount,rw para forzar el montaje actual de nuevo a lectura y escritura:

1

sudo mount "$DEV" /mnt/hc620

Verificar ahora:

1
2

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620
sudo dmesg -T | tail -100

Si la opción de montaje todavía contiene ro, o la cancelación de la transacción aparece nuevamente en el registro, deje de intentarlo y no realice un ciclo de montaje y desmontaje.

Si rw se muestra correctamente, no restaure el servicio de replicación inmediatamente. La primera tarea de la ventana de lectura y escritura es liberar datos borrables conocidos en lotes.

Cómo liberar espacio de forma segura tras recuperar la escritura

Dé prioridad a los directorios que se haya confirmado que tienen otras copias, que se pueden reconstruir y que son de gran tamaño.

Primero verifique el tamaño del directorio de primer nivel:

1

sudo du -xhd1 /mnt/hc620 | sort -h

No copiar directamente:

1

rm -rf /mnt/hc620/某个大目录

El objetivo real debe imprimirse primero para confirmar que no hay errores de expansión variable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

DELETE_TARGET=/mnt/hc620/已确认可删除的实际目录
DELETE_TARGET=$(realpath -e -- "$DELETE_TARGET") || exit 1

case "$DELETE_TARGET" in
  /mnt/hc620/*) ;;
  *) printf '拒绝删除挂载点之外的路径：%s\n' "$DELETE_TARGET" >&2; exit 1 ;;
esac

printf '%s\n' "$DELETE_TARGET"
sudo du -sh -- "$DELETE_TARGET"
sudo find "$DELETE_TARGET" -xdev -maxdepth 1 -mindepth 1 -printf '%f\n' | head

Asegúrese de que el objetivo sea correcto antes de eliminar:

1
2

sudo rm -rf -- "$DELETE_TARGET"
sync

Para datos de varios terabytes, se recomienda eliminarlos en subdirectorios o lotes separados y no realizar escrituras a gran escala al mismo tiempo.

Verifique después de cada lote:

1
2
3
4

sudo btrfs filesystem sync /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620
sudo dmesg -T | tail -100

btrfs filesystem sync Puede que tarde un poco. Antes de que regrese el comando, no confunda “directorio desaparecido” porque se completó la recuperación de espacio.

Intente liberar primero cientos de GiB, en lugar de simplemente eliminar unos pocos GiB y luego llenarlos inmediatamente. El margen de seguridad específico depende de la carga de trabajo, el tamaño de la zona, los metadatos y la eficiencia del reciclaje, y no se puede dar una proporción absoluta para todo el HC620.

En uso a largo plazo, no se recomienda mantener Btrfs zonificados entre 99% y 100%. Para reservar ambos:

  • Nuevo espacio de escritura diario;
  • Espacio de transacciones COW;
  • Espacio de crecimiento de metadatos;
  • la recuperación de zona mueve un espacio de trabajo que todavía tiene datos válidos;
  • Ventanas de mantenimiento y eliminación de emergencia.

Por qué es posible que el espacio no vuelva a aparecer inmediatamente después de la eliminación

La eliminación de archivos principalmente elimina las referencias y actualiza los metadatos. Para dispositivos zonificados, puede haber extensiones válidas en las zonas relevantes y Btrfs debe alejarlas antes de restablecer la zona.

Entonces podrías ver:

  • El archivo ha sido eliminado;
  • Used ha disminuido;
  • Device zone unusable sube temporalmente;
  • Device unallocated no aumenta sincrónicamente según la cantidad de eliminación;
  • El limpiador de fondo continúa generando E/S.

Esto no significa necesariamente que la eliminación haya fallado. Observe un ciclo de reclaim completo y controlado, y evalúe la evolución de los registros y de btrfs filesystem usage -T.

Si el valor no cambia durante mucho tiempo y al mismo tiempo se producen bloqueos más limpios, errores de transacción o tareas de estado D, se debe manejar de acuerdo con la falla de la ruta de recuperación en lugar de continuar eliminando una gran cantidad de datos.

Ejecutar balance gradualmente y solo después de recuperar espacio

El equilibrio moverá el grupo de bloques. La mayoría de las operaciones de equilibrio necesitan crear primero un nuevo grupo de bloques como espacio de trabajo, por lo que ejecutar el equilibrio sin un filtro directamente cuando el disco está lleno puede activar ENOSPC nuevamente.

No lo ejecutes de inmediato:

1

sudo btrfs balance start /mnt/hc620

Primero confirme que no haya ningún balance en curso:

1

sudo btrfs balance status /mnt/hc620

Bajo la premisa de que el registro es estable, se ha liberado espacio y el recuento de errores del dispositivo no ha aumentado, primero puede procesar el grupo de bloques completamente no utilizado:

1

sudo btrfs balance start -dusage=0 -musage=0 /mnt/hc620

usage=0 no requiere espacio de trabajo adicional y es el punto de partida de bajo riesgo para ENOSPC proporcionado por la documentación oficial de Btrfs.

Verificar después de completar:

1
2
3
4

sudo btrfs balance status /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620
sudo dmesg -T | tail -100

El umbral bajo sólo se considera cuando tanto el espacio como los registros son estables:

1

sudo btrfs balance start -dusage=5 /mnt/hc620

Después de observar nuevamente, es posible mejorar para:

1

sudo btrfs balance start -dusage=20 /mnt/hc620

Estas cifras no son una receta fija que deba implementarse paso a paso. Cuanto mayor sea el umbral, más datos se podrán mover y más espacio de trabajo y E/S se necesitarán.

Si btrfs-cleaner, la eliminación de block groups o la ruta de finalización de zonas se han bloqueado antes, no trate balance como una reparación automática. Podría volver a entrar en rutas de código similares; investigue primero el problema del kernel.

Operaciones que deben evitarse en el disco afectado

No forzar un remount de lectura y escritura

evitar:

1

sudo mount -o remount,rw /mnt/hc620

Si el kernel acaba de forzar que el sistema de archivos sea de solo lectura debido a un error, el montaje directo omitirá el límite de “guardar registro, desmontar y volver a evaluar” y, por lo general, no podrá eliminar la causa raíz del sistema de archivos de solo lectura.

No ejecutar un balance completo sin filtros

evitar:

1

sudo btrfs balance start /mnt/hc620

Un equilibrio de disco completo necesita mover datos, lo que puede requerir más espacio temporal que la falla original.

No ejecute btrfs check --repair

evitar:

1

sudo btrfs check --repair /dev/sdX

La documentación oficial de Btrfs advierte claramente: No utilice --repair a menos que el desarrollador o una persona con experiencia le informe de un error específico.

Si realmente necesita comprobar la estructura sin conexión, desmonte primero el sistema de archivos y utilice el modo de solo lectura predeterminado:

1

sudo btrfs check --readonly "$DEV"

Pero en un sistema de archivos de 14 TB o 15 TB, esta verificación puede llevar mucho tiempo, consumir mucha memoria y generar lecturas continuas. Por lo general, esto no es necesario como primer paso cuando solo hay evidencia pura de ENOSPC.

No borre primero las estadísticas de errores del dispositivo

Evite ejecutar antes de guardar la evidencia:

1

sudo btrfs device stats -z /mnt/hc620

La puesta a cero no reparará la unidad, los cables o el HBA; simplemente borrará la línea base de comparación.

No continuar con borrados y escrituras masivos al mismo tiempo

La superposición de eliminaciones de varios terabytes, recuperaciones de zonas y nuevas escrituras de varios terabytes en un SMR administrado por host puede ampliar significativamente la superficie de fallas.

Un proceso más confiable es:

1
2
3
4
5
6

停止新写入
→ 分批删除
→ 等待事务提交与回收
→ 检查空间和日志
→ 保留明显余量
→ 再分批恢复写入

Verificación después de recuperar espacio

Restaurar rw es solo el comienzo y no puede usarse como criterio de éxito final.

Verificar el estado del montaje 

1

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

confirmar:

  • El dispositivo fuente es correcto;
  • El sistema de archivos es btrfs;
  • Las opciones de montaje incluyen rw;
  • No hay subvolúmenes ni particiones incorrectos montados.

Verificar la distribución espacial 

1
2

sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device usage /mnt/hc620

No opte simplemente por Device zone unusable cero. Es más:

  • Ya hay suficiente espacio disponible;
  • Device unallocated o espacio asignable restaurado;
  • Los metadatos ya no se llevan al límite;
  • No aparecen errores nuevos durante el reclaim.

Comprobar que los contadores de errores no aumenten 

1
2

date -Is
sudo btrfs device stats /mnt/hc620

Comparar con la línea de base guardada después del error. Deje de reanudar escrituras grandes si write_io_errs, flush_io_errs, corruption_errs o generation_errs crecen.

Verifique que el kernel no vuelva a forzar el modo de solo lectura 

1
2

sudo journalctl -k --since '-30 min' --no-pager | \
grep -iE 'btrfs|enospc|no space|transaction|abort|forced readonly|zone|I/O error'

Preste atención a los registros recién generados y no juzgue mal el error anterior de hace unas horas como una recurrencia.

Hacer pruebas de escritura a pequeña escala

Primero escriba en un directorio de prueba claro:

1
2
3
4
5

TEST_DIR=/mnt/hc620/.recovery-test
sudo mkdir -p "$TEST_DIR"
sudo dd if=/dev/zero of="$TEST_DIR/test.bin" bs=1M count=1024 status=progress
sync
sudo sha256sum "$TEST_DIR/test.bin"

Elimine los archivos de prueba y envíelos nuevamente:

1
2
3

sudo rm -f "$TEST_DIR/test.bin"
sudo rmdir "$TEST_DIR"
sudo btrfs filesystem sync /mnt/hc620

Luego verifique nuevamente los registros, el espacio y las estadísticas del dispositivo.

Pasar la prueba de 1GiB solo puede demostrar que las escrituras a pequeña escala son exitosas, pero no puede probar que las escrituras continuas de varios TB sean necesariamente estables. Las tareas formales deben reanudarse en pequeños lotes y monitorearse.

Programar scrub después de disponer de redundancia o copia de seguridad

Scrub lee todos los datos asignados y verifica las sumas de verificación, lo que puede llevar mucho tiempo. No ejecute equilibrar, copiar y eliminar inmediatamente en un disco lleno recién restaurado al mismo tiempo.

Después de confirmar que el sistema de archivos es estable y que hay copias de datos importantes, programe una ventana de mantenimiento independiente:

1

sudo btrfs scrub start -Bd /mnt/hc620

Compruébalo cuando termine:

1
2

sudo btrfs scrub status /mnt/hc620
sudo btrfs device stats /mnt/hc620

Los datos del disco único single no tienen otro espejo para que Btrfs los repare automáticamente. El hecho de que Scrub pueda encontrar problemas de verificación no significa necesariamente que puedan solucionarse.

Cómo evitar volver a llenar el sistema de archivos

Establecer línea de parada de capacidad para tareas de escritura

No permita que el script de respaldo solo mire el código de salida del comando. Registre tanto antes como después de escribir:

1
2

df -h /mnt/hc620
sudo btrfs filesystem usage -T /mnt/hc620

Cuando el espacio disponible caiga por debajo de su umbral de mantenimiento, dejará de recibir nuevos datos y le avisará.

El umbral no solo debe calcularse en función de “cuánto espacio cabe en el siguiente archivo”, sino que también debe incluir espacio para COW, metadatos y recuperación de zona.

Escalonar eliminaciones y escrituras grandes

recomendar:

1
2
3
4
5

复制一批
→ 校验一批
→ 等待事务稳定
→ 删除一批旧数据
→ 再检查 zone 与日志

No programe rsync, eliminación de instantáneas, limpieza y equilibrio para competir por E/S durante la misma ventana de mantenimiento.

Mantener una lista externa de checksums para los datos archivados

Puede generar una lista de verificación para directorios importantes y copiar la lista a otro disco:

1
2

cd /mnt/hc620/archive
find . -type f -print0 | sort -z | xargs -0 sha256sum > /另一块盘/archive.sha256

El formato de manifiesto de texto anterior aún puede resultar incómodo de manejar cuando los nombres de archivos contienen nuevas líneas; Si la fuente de datos produce nombres de archivos especiales, se debe utilizar un proceso de manifiesto dedicado que admita la delimitación NUL.

No trate un sistema de archivos de un solo disco como copia de seguridad

Las sumas de comprobación de Btrfs pueden detectar daños silenciosos, pero los perfiles de datos de un solo disco generalmente no tienen una segunda copia de los datos para recuperarse.

Los datos del HC620 también deben incluir al menos:

  • Otra copia del disco local;
  • Otra máquina o copia externa;
  • Almacenamiento de objetos periódicamente verificable o réplicas fuera de línea.

Preguntas frecuentes

Device zone unusable es muy grande. ¿Significa que el disco está roto?

incierto. Representa el espacio que se escribió en el pasado y al que ya no se hace referencia debido a COW, pero que aún no se ha reclamado ni se ha restablecido la zona.

También debe consultar Device unallocated, el uso de datos y metadatos, los registros del kernel, las tendencias de reciclaje y los recuentos de errores del dispositivo.

¿Se puede restaurar la misma capacidad inmediatamente después de eliminar un archivo?

No garantizado. La eliminación primero cambia la referencia del sistema de archivos. Es posible que la zona subyacente también necesite mover datos válidos y restablecerse.

Si el montaje normal funciona, ¿se puede volver a llenar el disco?

no puedo. Primero debe lograr un margen significativo, confirmar que los registros y los recuentos de errores sean estables, luego realizar pruebas a pequeña escala y, finalmente, reanudar el negocio en lotes.

write_io_errs es 0, ¿se descarta el problema del disco duro?

No se puede descartar por completo. Sólo muestra que no hay errores de escritura para este tipo de recuento de persistencia registrado por Btrfs; También verifique los registros de la capa de bloques del kernel, SMART, HBA, cables y fuente de alimentación.

¿Puedo usar mount -o recovery?

No piense en el recovery del antiguo tutorial como un interruptor de reparación universal. La opción actual de montaje de rescate de Btrfs tiene errores aplicables claros y, por lo general, requiere un montaje de solo lectura, que debe seleccionarse en función del registro real.

¿Por qué df informa ENOSPC cuando muestra que todavía hay espacio?

El COW, el grupo de bloques de datos y metadatos, la reserva de transacciones y la recuperación de zonas de Btrfs requieren espacio. Las estimaciones disponibles a nivel de archivo presentadas por df no expresan completamente estas restricciones internas.

¿Debo cambiar los metadatos de DUP a sencillos?

No realice cambios temporales en el perfil sólo para ahorrar espacio. La conversión de perfiles en sí requiere mover grupos de bloques, lo que requiere espacio de trabajo y muchas E/S; Los perfiles admitidos por el modo por zonas también están sujetos a las versiones del kernel y de la herramienta.

Por qué un balance con usage=0 es relativamente seguro

Debido a que solo escanea y recupera grupos de bloques completamente no utilizados, la documentación oficial indica que este filtro no requiere espacio de trabajo adicional.

“Relativamente seguro” no significa que sea adecuado para todos los fallos. Si los registros muestran una ruta de reclaim bloqueada o un error estructural, detenga la operación y analice primero la causa.

¿Es posible cortar la energía directamente y reiniciarla?

Si el sistema todavía responde, guarde los registros, detenga las tareas, espere las transacciones necesarias y desmonte normalmente. Un corte de energía forzado aumenta la incertidumbre sobre las escrituras sin confirmar y complica el análisis del fallo.

Si la tarea del kernel está en el estado D ininterrumpible durante mucho tiempo y la máquina no puede apagarse normalmente, debe guardar tantos registros como sea posible a través de otra máquina o consola remota antes de evaluar el riesgo de reiniciar.

Lista de actuación paso a paso

Ejecutar en orden, no saltar para equilibrar o reparar:

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

1. 停止复制、下载、容器、快照和维护任务
2. 保存当前及上一次启动的内核日志
3. 用 findmnt 和 lsblk 确认设备、分区、zoned 与 ro/rw
4. 保存 btrfs filesystem usage -T
5. 保存 btrfs device stats，不清零
6. 找到 forced readonly 前的第一条错误
7. 区分 ENOSPC、回收阻塞、事务异常和 I/O/结构错误
8. 有重要数据时先只读挂载并复制到另一块盘
9. 仅在纯 ENOSPC 证据充分时尝试一次普通读写挂载
10. 读写成功后分批删除已确认可重建的数据
11. 每批后 sync，并检查空间、日志和错误计数
12. 空间充裕且日志稳定后，才考虑 usage=0 balance
13. 做小规模写入、删除与校验测试
14. 独立维护窗口再安排 scrub
15. 给未来写入设置容量停止线和外部告警

Resultados que deben recopilarse para continuar el diagnóstico

Si aún no puede confirmar a qué categoría pertenece, oculte información confidencial, como números de serie, al recopilar el siguiente resultado, pero no elimine el contexto de error:

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

uname -a
btrfs version

lsblk -o NAME,MODEL,SIZE,TYPE,ZONED,FSTYPE,MOUNTPOINTS
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/hc620

sudo btrfs filesystem usage -T /mnt/hc620
sudo btrfs device stats /mnt/hc620

sudo journalctl -k -b --no-pager | \
grep -iE 'btrfs|zone|enospc|no space|I/O error|transaction|abort|forced readonly' | \
tail -200

Con base en estos resultados, el siguiente paso generalmente puede converger hacia:

  1. Simplemente llénalo y podrás hacer espacio bajo control;
  2. la recuperación de zona no tiene espacio de trabajo ni bloqueo de ruta de recuperación;
  3. La transacción Btrfs se cancela y es necesario rastrear el primer error;
  4. Fallo real de E/S en HC620, HBA, cable o fuente de alimentación;
  5. Hay un error de verificación o estructura en el sistema de archivos y los datos deben ser rescatados primero y luego manejados por personal experimentado.

Referencias

Cuando un HC620 lleno queda en solo lectura, la prioridad no es conseguir que vuelva a mostrar rw cuanto antes. Primero determine por qué el kernel activó el modo de protección. Solo si las pruebas apuntan claramente a un ENOSPC ordinario debe conservar los registros y las copias de datos, y después liberar espacio de forma controlada. Si aparecen errores de E/S, checksum, estructura o zone write pointer, detenga las escrituras y priorice el rescate de datos y el diagnóstico de la ruta de hardware.