La matriz MD raid5 parece haber dejado de funcionar repentinamente. Los síntomas son algo similares aeste problemaen el sentido de que recibo errores que indican que no hay suficientes dispositivos para iniciar la matriz; sin embargo, en mi caso, el recuento de eventos en las tres unidades es igual. Es una matriz raid 5 que debería tener 2 unidades activas y una paridad; sin embargo, mdadm --examine en cada unidad muestra que dos de ellas tienen su función listada como repuesto y solo una como unidad activa.
He intentadomdadm --stop /dev/md1seguido pormdadm --ensamblar /dev/md1(incluidos los intentos con las banderas --force y --run).
Los datos SMART no indican ningún problema con las unidades (y los recuentos actuales de sectores pendientes y reasignados son todos cero), probé elguía raid.wiki.kernel.orgvinculado a continuación por frostschutz a través de los pasos que implican la configuración de dispositivos de superposición mapeados.
Entonces habría asumido que ejecutar el siguiente comando crearía una matriz raid que luego podría intentar montar en modo de solo lectura y ver si eso daba como resultado un sistema de archivos legible o simplemente un desastre confuso (es decir, para determinar si mi suposición de que sdf1 es la paridad la unidad era correcta o si debería intentarlo nuevamente con sde1), pero en su lugar muestra el error que se muestra a continuación (también lo intenté con los dispositivos de bucle asociados segúnperder-lista, con el mismo resultado).
mdadm --create /dev/md2 --assume-clean --level=5 --chunk=64K --metadata=1.2 --data-offset=261888s --raid-devices=3 desaparecidos /dev/mapper/sdh1 / dev/mapeador/sdf1
mdadm: super1.x cannot open /dev/mapper/sdh1: Device or resource busy
mdadm: /dev/mapper/sdh1 is not suitable for this array.
mdadm: super1.x cannot open /dev/mapper/sdf1: Device or resource busy
mdadm: /dev/mapper/sdf1 is not suitable for this array.
mdadm: create aborted
Además, mientrasmdadm --detalle /dev/md1Anteriormente dio el resultado (más) a continuación, ahora da:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 253 11 - /dev/dm-11
- 253 10 - /dev/dm-10
- 253 9 - /dev/dm-9
Además, he notadoestado de configuración de dmproporciona la misma información para las tres superposiciones y tiene un número que parece sospechosamente que puede referirse al tamaño de la matriz raid original (16 TB) en lugar de a una unidad individual (8 TB). ¿No estás seguro de si esto es como debería ser?
sde1: 0 15627528888 snapshot 16/16777216000 16
sdh1: 0 15627528888 snapshot 16/16777216000 16
sdf1: 0 15627528888 snapshot 16/16777216000 16
No estoy seguro de cómo avanzar desde este punto hasta intentar crear el dispositivo, montar e inspeccionar el sistema de archivos para confirmar si adiviné el dispositivo de paridad correcto o no, usando la superposición para evitar que se escriba algo en las unidades reales.
ACTUALIZAR: Según la sugerencia de Frostschutz a continuación, la matriz estaba de alguna manera en algún tipo de estado en el que era necesario emitir --stop antes de poder hacer algo con las unidades subyacentes. Había descartado esa posibilidad anteriormente porquegato /proc/mdstatestaba mostrando la matriz como inactiva, lo que supuse significaba que no podía ser lo que estaba bloqueando las unidades, pero ese no era el caso (también había ejecutado anteriormente --stop, pero parecía que algo estaba hecho después de activar su regreso a un estado no detenido). Después de obtener el orden correcto de las unidades (no en el primer intento, me alegro de haber usado superposiciones), la matriz pasó una verificación fsck sin errores reportados yahora está funcionando como si nada hubiera pasado.
El resultado de ejecutar otros comandos de diagnóstico:
gato /proc/mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : inactive sdh1[1](S) sde1[3](S) sdf1[0](S)
23440900500 blocks super 1.2
mdadm --detalle /dev/md1:
/dev/md1:
Version : 1.2
Raid Level : raid0
Total Devices : 3
Persistence : Superblock is persistent
State : inactive
Working Devices : 3
Name : bob:1 (local to host bob)
UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Events : 373364
Number Major Minor RaidDevice
- 8 113 - /dev/sdh1
- 8 81 - /dev/sdf1
- 8 65 - /dev/sde1
líneas que aparecen en dmesg al intentarmdadm --ensamblar /dev/md1:
md/raid:md1: device sdh1 operational as raid disk 1
md/raid:md1: not enough operational devices (2/3 failed)
md/raid:md1: failed to run raid set.
md: pers->run() failed ..
y elmdadm --examinars
/dev/sde1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261808 sectors, after=312 sectors
State : clean
Device UUID : e856f539:6a1b5822:b3b8bfb7:4d0f4741
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 40 sectors
Checksum : 9b5703bc - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdf1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 7919e56f:2e08430e:95a4c4a6:1e64606a
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : d54ff3e1 - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : spare
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
/dev/sdh1:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 07ff9ba9:e8100e68:94c12c1a:3d7ad811
Name : bob:1 (local to host bob)
Creation Time : Mon Mar 4 22:10:29 2019
Raid Level : raid5
Raid Devices : 3
Avail Dev Size : 15627267000 (7451.66 GiB 8001.16 GB)
Array Size : 15627266688 (14903.32 GiB 16002.32 GB)
Used Dev Size : 15627266688 (7451.66 GiB 8001.16 GB)
Data Offset : 261888 sectors
Super Offset : 8 sectors
Unused Space : before=261800 sectors, after=312 sectors
State : clean
Device UUID : 0c9a8237:7e79a439:d4e35b31:659f3c86
Internal Bitmap : 8 sectors from superblock
Update Time : Sun May 30 00:22:45 2021
Bad Block Log : 512 entries available at offset 72 sectors
Checksum : 6ec2604b - correct
Events : 373364
Layout : left-symmetric
Chunk Size : 64K
Device Role : Active device 1
Array State : .AA ('A' == active, '.' == missing, 'R' == replacing)
Respuesta1
Parece extraño. Puede que tengas quemdadm --crear con superposicionespara este (con desplazamiento de datos, tamaño de fragmento y orden de unidad correctos). Y tal vez con la falta del primer disco, ya que parece haber fallado primero...
Básicamente, no hay forma de recuperarse con medios convencionales una vez que una unidad ya ni siquiera recuerda su función de dispositivo. Ambos dicen que son "repuestos", por lo que se desconoce si alguna de las unidades tenía la función 0, la función 2 o nada en absoluto (algunas configuraciones raid5 en realidad usan repuestos por alguna razón). Por lo tanto, no está claro si hay datos útiles sobre ellos y, de ser así, en qué orden estarían. Tienes que determinarlo tú mismo.
Mientras lo hace, verifique también los datos SMART y utilícelos ddrescueprimero si alguna de estas unidades realmente tiene sectores reasignados o pendientes que podrían haber contribuido al fallo del raid.