Ok, algo me estaba molestando sobre tu problema, así que encendí una máquina virtual para sumergirme en el comportamiento que debería esperarse. Llegaré a lo que me estaba molestando en un minuto; primero déjame decir esto:
¡Haga una copia de seguridad de estas unidades antes de intentar algo!
Es posible que ya haya hecho daño más allá de lo que hizo la resincronización; ¿Puedes aclarar a qué te referías cuando dijiste:
Según las sugerencias, limpié los superbloques y volví a crear la matriz con la opción --assume-clean, pero sin suerte.
Si ejecutaste un mdadm --misc --zero-superblock, entonces deberías estar bien.
De todos modos, busque algunos discos nuevos y tome imágenes actuales exactas de ellos antes de hacer cualquier cosa que pueda escribir más en estos discos.
dd if=/dev/sdd of=/path/to/store/sdd.img
Dicho esto ... parece que los datos almacenados en estas cosas son sorprendentemente resistentes a las desincronizaciones rebeldes. Siga leyendo, hay esperanza, y este puede ser el día en que llegue al límite de longitud de respuesta.
El mejor escenario
Creé una máquina virtual para recrear su escenario. Las unidades tienen solo 100 MB, por lo que no esperaría para siempre en cada resincronización, pero de lo contrario, esta debería ser una representación bastante precisa.
Construyó la matriz de la manera más genérica y predeterminada posible: trozos de 512k, diseño simétrico a la izquierda, discos en orden de letras ... nada especial.
root@test:~# mdadm --create /dev/md0 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Hasta aquí todo bien; hagamos un sistema de archivos y agreguemos algunos datos.
root@test:~# mkfs.ext4 /dev/md0
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=512 blocks, Stripe width=1024 blocks
51000 inodes, 203776 blocks
10188 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2040 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@test:~# mkdir /mnt/raid5
root@test:~# mount /dev/md0 /mnt/raid5
root@test:~# echo "data" > /mnt/raid5/datafile
root@test:~# dd if=/dev/urandom of=/mnt/raid5/randomdata count=10000
10000+0 records in
10000+0 records out
5120000 bytes (5.1 MB) copied, 0.706526 s, 7.2 MB/s
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Okay. Tenemos un sistema de archivos y algunos datos ("datos" datafiley 5 MB de datos aleatorios con ese hash SHA1 randomdata); Veamos qué sucede cuando hacemos una recreación.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md0
mdadm: stopped /dev/md0
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
unused devices: <none>
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 21:07:06 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[2] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
La resincronización terminó muy rápidamente con estos pequeños discos, pero ocurrió. Así que esto es lo que me estaba molestando de antes; su fdisk -lsalida No tener una tabla de particiones en el mddispositivo no es un problema, se espera. Su sistema de archivos reside directamente en el dispositivo de bloque falso sin tabla de particiones.
root@test:~# fdisk -l
...
Disk /dev/md1: 208 MB, 208666624 bytes
2 heads, 4 sectors/track, 50944 cylinders, total 407552 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
Disk /dev/md1 doesn't contain a valid partition table
Sí, no hay mesa de partición. Pero...
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
Sistema de archivos perfectamente válido, después de una resincronización. Entonces eso es bueno; Vamos a ver nuestros archivos de datos:
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sólido: ¡no hay corrupción de datos en absoluto! Pero esto es exactamente con la misma configuración, por lo que nada se asignó de manera diferente entre los dos grupos RAID. Dejemos caer esto antes de intentar romperlo.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
Dando un paso atrás
Antes de intentar romper esto, hablemos de por qué es difícil de romper. RAID 5 funciona mediante el uso de un bloque de paridad que protege un área del mismo tamaño que el bloque en cualquier otro disco de la matriz. La paridad no solo se encuentra en un disco específico, sino que se gira alrededor de los discos de manera uniforme para distribuir mejor la carga de lectura a través de los discos en funcionamiento normal.
La operación XOR para calcular la paridad se ve así:
DISK1 DISK2 DISK3 DISK4 PARITY
1 0 1 1 = 1
0 0 1 1 = 0
1 1 1 1 = 0
Entonces, la paridad se extiende entre los discos.
DISK1 DISK2 DISK3 DISK4 DISK5
DATA DATA DATA DATA PARITY
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
Una resincronización generalmente se realiza al reemplazar un disco muerto o faltante; también se realiza mdadm createpara garantizar que los datos en los discos se alineen con la apariencia de la geometría del RAID. En ese caso, el último disco en la especificación de la matriz es el que está 'sincronizado': todos los datos existentes en los otros discos se usan para la sincronización.
Entonces, todos los datos en el 'nuevo' disco se borran y se reconstruyen; ya sea construyendo nuevos bloques de datos a partir de bloques de paridad para lo que debería haber estado allí, o bien construyendo nuevos bloques de paridad.
Lo bueno es que el procedimiento para ambas cosas es exactamente el mismo: una operación XOR a través de los datos del resto de los discos. El proceso de resincronización en este caso puede tener en su diseño que cierto bloque debería ser un bloque de paridad, y pensar que está construyendo un nuevo bloque de paridad, cuando en realidad está recreando un bloque de datos antiguo. Entonces, incluso si cree que está construyendo esto:
DISK1 DISK2 DISK3 DISK4 DISK5
PARITY DATA DATA DATA DATA
DATA PARITY DATA DATA DATA
DATA DATA PARITY DATA DATA
... puede que solo se esté reconstruyendo a DISK5partir del diseño anterior.
Por lo tanto, es posible que los datos se mantengan consistentes incluso si la matriz está mal construida.
Lanzar un mono en las obras
(no una llave inglesa; todo el mono)
Prueba 1:
¡Hagamos la matriz en el orden incorrecto! sdc, entonces sdd, entonces sdb..
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:06:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
Ok, eso está muy bien. ¿Tenemos un sistema de archivos?
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
No! ¿Porqué es eso? Porque si bien los datos están allí, están en el orden incorrecto; lo que una vez fue 512 KB de A, luego 512 KB de B, A, B, y así sucesivamente, ahora se ha barajado a B, A, B, A. El disco ahora parece incoherente para el verificador del sistema de archivos, no se ejecutará. La salida de mdadm --misc -D /dev/md1nos da más detalles; Se parece a esto:
Number Major Minor RaidDevice State
0 8 33 0 active sync /dev/sdc1
1 8 49 1 active sync /dev/sdd1
3 8 17 2 active sync /dev/sdb1
Cuando debería verse así:
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 33 1 active sync /dev/sdc1
3 8 49 2 active sync /dev/sdd1
Entonces, eso está muy bien. Sobreescribimos un montón de bloques de datos con nuevos bloques de paridad esta vez. Vuelva a crear, con el orden correcto ahora:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:11:08 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
¡Genial, todavía hay un sistema de archivos allí! ¿Aún tienes datos?
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
¡Éxito!
Prueba 2
Ok, cambiemos el tamaño del fragmento y veamos si eso nos da algo de quiebre.
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:19 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
Sí, sí, está manguera cuando se configura así. Pero, ¿podemos recuperarnos?
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:21:51 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
¡Éxito otra vez!
Prueba 3
Este es el que pensé que mataría datos con seguridad, ¡hagamos un algoritmo de diseño diferente!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --layout=right-asymmetric --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:32:34 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 1 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Miedo y mal: ¡cree que encontró algo y quiere arreglarlo! Ctrl+ C!
Clear<y>? cancelled!
fsck.ext4: Illegal inode number while checking ext3 journal for /dev/md1
Ok, crisis evitada. Veamos si los datos siguen intactos después de volver a sincronizar con el diseño incorrecto:
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Sat Jan 7 23:33:02 2012
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
¡Éxito!
Prueba 4
Probemos también que la reducción a cero del superbloque no es dañina muy rápido:
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 12/51000 files, 12085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Sí, no es gran cosa.
Prueba 5
Vamos a tirar todo lo que tenemos. Las 4 pruebas anteriores, combinadas.
- Orden de dispositivo incorrecta
- Tamaño de trozo incorrecto
- Algoritmo de diseño incorrecto
- Superbloques a cero (haremos esto entre ambas creaciones)
¡Adelante!
root@test:~# umount /mnt/raid5
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=64 --level=5 --raid-devices=3 --layout=right-symmetric /dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdb1[3] sdd1[1] sdc1[0]
204672 blocks super 1.2 level 5, 64k chunk, algorithm 3 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/md1
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
root@test:~# mdadm --stop /dev/md1
mdadm: stopped /dev/md1
¿El veredicto?
root@test:~# mdadm --misc --zero-superblock /dev/sdb1 /dev/sdc1 /dev/sdd1
root@test:~# mdadm --create /dev/md1 --chunk=512 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@test:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid5 sdd1[3] sdc1[1] sdb1[0]
203776 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
root@test:~# fsck.ext4 /dev/md1
e2fsck 1.41.14 (22-Dec-2010)
/dev/md1: clean, 13/51000 files, 17085/203776 blocks
root@test:~# mount /dev/md1 /mnt/raid5/
root@test:~# cat /mnt/raid5/datafile
data
root@test:~# sha1sum /mnt/raid5/randomdata
847685a5d42524e5b1d5484452a649e854b59064 /mnt/raid5/randomdata
Guau.
Por lo tanto, parece que ninguna de estas acciones corrompió los datos de ninguna manera. Me sorprendió bastante este resultado, francamente; Esperaba probabilidades moderadas de pérdida de datos en el cambio de tamaño del fragmento, y alguna pérdida definitiva en el cambio de diseño. Aprendí algo hoy.
Entonces ... ¿Cómo obtengo mis datos?
Toda la información que tenga sobre el antiguo sistema le sería extremadamente útil. Si conoce el tipo de sistema de archivos, si tiene copias antiguas de su /proc/mdstatinformación sobre el orden de la unidad, el algoritmo, el tamaño del fragmento y la versión de metadatos. ¿Tiene configuradas las alertas de correo electrónico de mdadm? Si es así, encuentre uno viejo; si no, verifique /var/spool/mail/root. Verifique ~/.bash_historysi su construcción original está allí.
Entonces, la lista de cosas que debes hacer:
- ¡Haga una copia de seguridad de los discos
ddantes de hacer nada!
- Intente con
fsckel md activo actual: es posible que haya compilado en el mismo orden que antes. Si conoce el tipo de sistema de archivos, eso es útil; usa esa fsckherramienta específica . Si alguna de las herramientas ofrece arreglar algo, ¡no lo deje a menos que esté seguro de que realmente ha encontrado el sistema de archivos válido! Si hay fsckofertas para arreglar algo por usted, no dude en dejar un comentario para preguntar si realmente está ayudando o si está a punto de destruir datos.
- Intente construir la matriz con diferentes parámetros. Si tienes un viejo
/proc/mdstat, puedes imitar lo que muestra; si no, entonces estás un poco a oscuras: probar todas las diferentes órdenes de manejo es razonable, pero es inútil verificar cada tamaño de fragmento posible con cada orden posible. Para cada uno, fsckpara ver si obtienes algo prometedor.
Entonces, eso es todo. Perdón por la novela, siéntase libre de dejar un comentario si tiene alguna pregunta, ¡y buena suerte!
nota al pie: menos de 22 mil caracteres; 8k + menos del límite de longitud