btrfs encima de mdadm raid: cálculo de franjas para sectores corruptos para usar con raid6check

btrfs encima de mdadm raid: cálculo de franjas para sectores corruptos para usar con raid6check

Tengo una configuración con btrfs ejecutándose sobre mdadm raid6 ya que el código RAID5/6 de btrfs aún no es estable. Pensé que de esta manera obtendría los beneficios de tomar instantáneas y realizar sumas de verificación con algunos obstáculos adicionales que superar, ahora que tengo que superar esos obstáculos me estoy encontrando con algunos problemas.

Esta mañana mi dmesg produjo este problema:

BTRFS error (device md2): bad tree block start, want 28789209759744 have 7611175298055105740
BTRFS info (device md2): read error corrected: ino 0 off 28789209759744 (dev /dev/md2 sector 55198191488)
BTRFS info (device md2): read error corrected: ino 0 off 28789209763840 (dev /dev/md2 sector 55198191496)
BTRFS info (device md2): read error corrected: ino 0 off 28789209767936 (dev /dev/md2 sector 55198191504)
BTRFS info (device md2): read error corrected: ino 0 off 28789209772032 (dev /dev/md2 sector 55198191512)

Este es el tipo de cosas que podrían haber pasado silenciosamente si no hubiera usado btrfs, así que al menos me sirvió de algo... así que ahora debería poder descubrir qué disco tiene el problema y reemplazarlo, ¿verdad?

Bueno, parece que mdadm solo admite la determinación del disco defectuoso usando la herramienta raid6check. Tuve que compilarlo desde el código fuente para que funcionara en Debian, pero después de hacerlo, parece que estoy en el negocio.

El único inconveniente aquí es que esta herramienta parece ser extremadamente lenta, para escanear 1000 franjas se necesitan unos buenos 3 minutos. Esto significa que escanear las 15261512 franjas que componen mi matriz llevará más de 31 días. Me gustaría evitar eso si es posible. La verificación/reparación de mdadm es mucho más rápida, solo alrededor de 3 días, pero no produce ninguna información útil sobre qué disco podría ser responsable de esto, por lo que no quiero usarlo exactamente.

La herramienta raid6check parece admitir la aceptación de un número de banda. Me pregunto si es posible calcular qué número de banda pasar para poder verificar directamente la parte relevante del disco.

Aquí está la información de raid6check como referencia si ayuda:

layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288

Gracias, cualquier idea se agradece.

Respuesta1

Muy bien, encontré una forma un tanto funcional de hacer esto después de hablar con JyZyXEL en #linux-raid en Freenode.

raid6check informa el total de franjas, así que ejecútelo así para ver la información básica sin ejecutar una prueba completa:

./raid6check /dev/md0 0 1

Obtendrás algo como esto:

layout: 2
disks: 8
component size: 8001427603456
total stripes: 15261512
chunk size: 524288

Verifique el total de sectores en su RAID usando fdisk -l /dev/md0:

Disk /dev/md2: 43.7 TiB, 48008565620736 bytes, 93766729728 sectors

Ahora calcule sectores por franja:

total sectors / total stripes = 93766729728 / 15261512 = 6144

Ahora simplemente divide el sector con el error por los sectores por franja:

error sector = 55198191488/6144 = 8984080

Ahora ejecuta un raid6check, intenta incluir el área alrededor ya que esto no parece ser exacto:

raid6check /dev/md0 8984000 1000

Para mí, esto rápidamente produjo muchos errores relevantes, todos apuntando al mismo disco que podría estar fallando:

 Error detected at stripe 8984078, page 100: possible failed disk slot 1: 4 --> /dev/sdj1
 Error detected at stripe 8984081, page 76: possible failed disk slot 4: 4 --> /dev/sdj1

A partir de este punto, puedes actuar en consecuencia, reemplazar el disco, ejecutar pruebas SMART, usar la reparación automática de raid6check, etc.

Puede que este no sea el método más preciso, pero lo publico en caso de que a nadie se le ocurra una idea mejor y alguien esté buscando una forma que funcione en el futuro.

información relacionada