La matriz md Raid6 desapareció al reiniciar

La matriz md Raid6 desapareció al reiniciar

mi matriz raid6 desapareció al reiniciar después de que la hice crecer. Creo que el problema se estaba duplicando con el disco lleno, no con la partición. Se ha sugerido que otra posible razón por la que las unidades no se reconocieron correctamente es que no puse a cero los superbloques antes de leerlos en una nueva matriz. ¿Podría ser una combinación de ambos? Estos son los comandos emitidos (extraídos del historial, formateados para tener letras de unidad consistentes):

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=2 /dev/sd[b-c]1

#Copia de seguridad completa de ROC raid 10 en estas unidades, después de haber copiado la mayoría de los archivos a otras unidades, verifique que haya funcionado durante el reinicio.

mdadm --create /dev/md1 --level=6 --raid-devices=4 /dev/sd[d-g]1

# Pasó el tiempo para sincronizar las unidades y luego sincronizar los datos desde md0, se reinicia bien.

mdadm -S /dev/md0
mdadm /dev/md0 -r /dev/sd[b-c]

#TENGA EN CUENTA EL NÚMERO DE PARTICIÓN QUE FALTA A CONTINUACIÓN.

mdadm /dev/md1 --add /dev/sdb
mdadm /dev/md1 --add /dev/sdc
mdadm -list
mdadm --detail /dev/md1
mdadm --grow --raid-devices=6 --backup-file=/media/FastRaid/md1_grow.bak /dev/md1

Después de reiniciar, el raid6 desapareció y es reemplazado por 2 arreglos raid0, uno activo (sdb/sdc) y otro inactivo (sdd-sdg). Lo siguiente es lo que obtengo al examinar los superbloques:

/dev/sdb1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
    Array UUID : 501c08da:5069a3d8:b2982a5d:ab56c37c
        Name : tim-server:0  (local to host tim-server)
Creation Time : Tue Dec 13 22:01:10 2022
    Raid Level : raid0
Raid Devices : 2

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
        State : clean
    Device UUID : e8db27d6:0dbd1ac5:4456c304:0b43f09c

    Update Time : Tue Dec 13 22:01:10 2022
Bad Block Log : 512 entries available at offset 8 sectors
    Checksum : dfd187c0 - correct
        Events : 0

    Chunk Size : 512K

Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdc1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
    Array UUID : 501c08da:5069a3d8:b2982a5d:ab56c37c
        Name : tim-server:0  (local to host tim-server)
Creation Time : Tue Dec 13 22:01:10 2022
    Raid Level : raid0
Raid Devices : 2

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=0 sectors
        State : clean
    Device UUID : 3ce84b05:607f8565:456e7f83:88b83052

    Update Time : Tue Dec 13 22:01:10 2022
Bad Block Log : 512 entries available at offset 8 sectors
    Checksum : e35ce3e5 - correct
        Events : 0

    Chunk Size : 512K

Device Role : Active device 1
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdd1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : eaf10189:940aeaf8:947efe82:5d0e4aea

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : e38a1bd9 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 1
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sde1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 5c34a9c7:bcc3f190:d1719a9c:8aa2b722

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : c429edf - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 3
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 12d1e3a8:b8749f59:654bcca4:4f4750df

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : 7af56ae7 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdg1:
        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
    Array UUID : 929a14c9:adaf502a:53658e03:90a19fce
        Name : tim-server:0  (local to host tim-server)
Creation Time : Wed Dec 14 11:18:57 2022
    Raid Level : raid6
Raid Devices : 6

Avail Dev Size : 7813770895 (3725.90 GiB 4000.65 GB)
    Array Size : 15627540480 (14903.58 GiB 16002.60 GB)
Used Dev Size : 7813770240 (3725.90 GiB 4000.65 GB)
    Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=655 sectors
        State : clean
    Device UUID : 72085967:835efe92:cb268a64:4d192b52

Internal Bitmap : 8 sectors from superblock
    Update Time : Sun Dec 18 06:31:11 2022
Bad Block Log : 512 entries available at offset 24 sectors
    Checksum : a5623977 - correct
        Events : 26630

        Layout : left-symmetric
    Chunk Size : 512K

Device Role : Active device 2
Array State : AAAAAA ('A' == active, '.' == missing, 'R' == replacing)

Había desactivado md0 en algún momento, así que lo volví a crear con mdadm -A -o /dev/md0 /dev/sdb1 /dev/sdc1. Este es un /proc/mdstatahora:

cat /proc/mdstat

Personalities : [raid0] [linear] [multipath] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active (read-only) raid0 sdb1[0] sdc1[1]
  7813770240 blocks super 1.2 512k chunks

md1 : inactive sdf1[0](S) sde1[3](S) sdd1[1](S) sdg1[2](S)
    15627541790 blocks super 1.2

unused devices: <none>

Si lo intento mount /dev/md0 /media/tmp_md_raidobtengo: mount: /media/tmp_md_raid: wrong fs type, bad option, bad superblock on /dev/md126, missing codepage or helper program, or other error.. Si lo intento: mdadm -A -o /dev/md1 /dev/sdf1 /dev/sde1 /dev/sdd1 /dev/sdg1obtengo:

mdadm: /dev/sdf1 is busy - skipping
mdadm: /dev/sde1 is busy - skipping
mdadm: /dev/sdd1 is busy - skipping
mdadm: /dev/sdg1 is busy - skipping

Todos los smartctl dicen que todas las unidades están bien. No estoy seguro de si debería probar mdadm --assemble --force primero o mdadm --create --assume-clean primero. ¿Debo probar el segundo con -o configurado para ver si puedo recrear la matriz y ver los datos sin posiblemente destruir la recuperación? Gracias por cualquier consejo.

Respuesta1

Parece que tiene una matriz de 6 dispositivos (AAAAAA), pero solo hay 4 dispositivos disponibles ( /dev/sd[defg]1). El cálculo de capacidad lo confirma: se necesitan 6 discos de 4 TB para crear una matriz RAID6 de 16 TB.

Dado que se trata de RAID6 y los 4 dispositivos disponibles parecen estar sincronizados, se puede ejecutar, pero sólo en el llamadocompletamente degradadomodo. En este modo, para leer cualquier bloque, necesita leer una banda de todas las unidades (que requiere mucha E/S) y realizar una reconstrucción (utiliza ambos síndromes de paridad, lo que implica cálculos de campo de Galois que requieren un uso intensivo de la CPU) y escribir un bloque. necesita leer toda la franja, calcular nuevos síndromes de paridad y escribir en al menos tres dispositivos (lo que en general requiere aún más E/S).

Linux no tiene otro camino a seguir que recurrir a esto si la matriz se estaba ejecutando y algún dispositivo fallaba en medio del uso, ese es el objetivo de tener una matriz RAID. Como habrás adivinado, el rendimiento en este estado es muy malo y el riesgo de perder datos es muy alto, por lo que no debes ejecutar una matriz en este estado durante períodos prolongados. Lo ideal es que proporcione un repuesto dinámico además de los dispositivos que funcionen para que pueda comenzar la reconstrucción inmediatamente si detecta la falla de cualquier componente.

Pero durante el arranque no sabe si algunos dispositivos faltan permanentemente o simplemente no están disponibles todavía debido a un giro escalonado u otros retrasos en la inicialización. La activación temprana de la matriz desincronizará los dispositivos tardíos y forzará una resincronización prolongada, durante la cual la matriz experimentará la peor característica de rendimiento como se describe anteriormente. Esto motiva a esperar a que aparezcan dispositivos tardíos. Linux no activará automáticamente la matriz parcialmente disponible de forma predeterminada, incluso si hay suficientes dispositivos para ejecutarla al menos en algún modo degradado.

Pero usted, un administrador, puedefuerzaque lo haga. Para esto,volver a ensamblar la matriz con--force:

mdadm --stop /dev/md1
mdadm --force --assemble /dev/md1 /dev/sd[defg]1

Más precisamente, no ensamblará automáticamente la matriz si hay menos dispositivos disponibles que los registrados en los superbloques de dispositivos actuales (en su caso, se registra que todos los dispositivos estuvieron disponibles la última vez); cuando retira un dispositivo correctamente con mdadm -f/ mdadm -rsecuencia, o cuando lo fuerza a ensamblarlo, lo registra y la matriz luego se ensamblará automáticamente enmismoestado degradado automáticamente.

Si esta matriz no contiene datos valiosos, será mejor volver a crearla. La inicialización se sientemás rápidoque añadir dispositivos y sufrir una reconstrucción.

información relacionada