CentOS 7 creado matriz mdadm desaparece después de reiniciar

Creé un raid1 utilizando los siguientes discos y commands:

$ ls -l /dev/disk/by-id/ata-ST3000* lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 -> ../../sdc lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 -> ../../sda $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 

Agregué la información pertinente a mdadm.conf. Usé 'mdadm –detail –scan >> /etc/mdadm.conf' para la línea ARRAY:

 $ cat /etc/mdadm.conf DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 ARRAY /dev/md0 metadata=1.2 name=jaime.WORKGROUP:0 UUID=93f2cb73:2d124630:562f1dd9:bf189029 MAILADDR your@address 

Creé y monté el sistema de files:

 $ mkfs -t xfs /dev/md0 $ mount -t xfs /dev/md0 /data 

Después de reiniciar, / dev / md0 ya no existe y no puedo ensamblar la matriz:

 $ mdadm --assemble /dev/md0 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 mdadm: Cannot assemble mbr metadata on /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 mdadm: /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 has no superblock - assembly aborted 

Soy un principiante completo de software RAID y probablemente estoy jugando algo simple aquí. ¿Alguien puede ayudar?

 $ blkid /dev/sda: PTTYPE="gpt" /dev/sdb1: UUID="5c7d3f2b-c975-46a3-a116-e9fc156c1de5" TYPE="xfs" /dev/sdb2: UUID="JhoqjI-N6R6-O9zt-Xumq-TnFX-OUCd-Lg9YHy" TYPE="LVM2_member" /dev/sdc: PTTYPE="gpt" /dev/mapper/centos-swap: UUID="3b882d4d-b900-4c59-9912-60a413699db4" TYPE="swap" /dev/mapper/centos-root: UUID="08df953d-d4f4-4e83-bf4b-41f14a98a12e" TYPE="xfs" /dev/mapper/centos-home: UUID="2358f723-5e7f-49ed-b207-f32fe34b1bbc" TYPE="xfs" 

Related of "CentOS 7 creado matriz mdadm desaparece después de reiniciar"

En teoría, se pueden realizar incursiones desde "unidades desnudas" (no particionadas), pero noté que los discos se muestran como unidades gpt-particionadas, no md. En general, he encontrado un mayor éxito / estabilidad al particionar mi disco y luego usar particiones en mis matrices md.

Intentaría crear una tabla de particiones, configurando el tipo de partición como linux raid autodetect (fd en fdisk si recuerdo correctamente). Luego, recrea tu matriz.

Además, descubrí que si NO usaba mdadm.conf, encontraba un mejor éxito. Las versiones modernas de las herramientas de md obtendrán toda la información que necesitan de las supermanzanas de las particiones involucradas.

Se aplican advertencias habituales. Asegúrese de que sus datos fueron respaldados. No soy responsable de ninguna pérdida de datos. Esto funcionó para mí. Asegúrese de probar su matriz antes de poner datos significativos sobre ella. Asegúrate de que pueda sobrevivir a un reinicio y cambios en el nombre del dispositivo, etc. etc.

Ahora a lo que hice.

Me encontré con el mismo problema hoy. Después de hacer algunas búsquedas, pude arreglar esto y get un dispositivo de ataque estable.

En dos discos que estaba usando para mi matriz creé una partición usando gdisk antes de crear el dispositivo RAID. Eliminé las particiones usando gdisk, pero cuando creé la matriz, recibí el siguiente post informativo:

 mdadm: partition table exists on /dev/disk/by-id/ata-ST4000VN000-1H4168_Z30254QX but will be lost or meaningless after creating array 

Cada vez que veía este post cuando reiniciaba, la matriz se perdía.

Pensé que usaría la sugerencia anterior de Jim K y crearía una partición de ataque de Linux en cada disco. Esto funcionó, pero la tasa de synchronization pasó de 145 MB / s en las unidades en bruto a 35 MB / s en las particiones. Probablemente podría haber jugado con los parameters de ajuste, pero ¿por qué debería hacer eso?

Fui en una búsqueda para descubrir cómo nukear la tabla de particiones del disco.

La solución…

Primero asegúrate de que tu dispositivo incursor esté detenido y luego envía una señal nuclear a la unidad.

 mdadm --stop /dev/md<number> mdadm --zero-superblock /dev/sd<x> (do this for all your raid disks) 

Corre blkid y mira si aparece alguno de los dispositivos de ataque. Si lo hacen.

correr:

 dd if=/dev/zero of=/dev/sd<x> bs=512 count=1 

Esto con suerte nukeará las tablas de particiones. Ejecute blkid de nuevo para asegurarse de que no se enumeren los discos utilizados para el dispositivo incursor.

En mi caso, gpt tenía una label LVM respaldada en un disco. Limpié esto usando lvremove, vgremove, y finalmente pvremove.

blkid corrió limpio esta vez.

Sin embargo, cuando intenté crear la matriz de nuevo, recibí un error sobre un dispositivo RAID existente, así que lo hice una vez más. Después de esto, la matriz creada sin avisos como he enumerado anteriormente.

Recreé la matriz como era originalmente. Utilicé disk / by-id en lugar de sd. Una vez que se volvió a crear la matriz, la partición de testing que había creado en la matriz volvió intacta.

La matriz ahora sobrevive al reinicio y cambia a / dev / sd desde que la matriz se creó originalmente. Espero que esto ayude a otros …

La salida de blkid muestra su problema: las unidades no estaban limpias cuando las creó, y la información anterior es confusa.

Dado que usted creó estos sin una tabla de partición, el hecho de que blkid informe PTTYPE = "gpt" para sda y sdc es el problema.

Si todavía no tiene datos en las unidades que necesita save, puede eliminar la tabla de particiones GPT con 'dd':

$ sudo dd if = / dev / zero of = / dev / sda bs = 1M count = 10

Esto pondrá a cero los primeros 10 megabytes de /dev/sda . Repita para /dev/sdc . Vuelva a crear la matriz después de eso, y luego /dev/md0 debería aparecer al inicio.

Para todos ustedes amigos, he encontrado una solución alternativa que funciona para mí. Puede ser que esto les ayude chicos. Aquí está:

El assembly de RAID desaparece porque el sistema no está leyendo el file mdadm.conf durante el arranque o el inicio. Entonces, lo que hice fue editar el file /etc/rc.d/rc.local para include los siguientes commands:

 sleep 10 mdadm --assemble --scan sleep 10 mount -a 

Ahora, cada vez que reinicio el sistema, lee este file, ejecuta los commands mencionados en él y monta el assembly RAID.

Parece ser una forma mejor de formatear las particiones de disco con el tipo fd (Linux raid autodetect), ¡pero fíjese si hay posts de alignment en fdisk! Recibí esas advertencias y las resolví con la herramienta luego partida para crear las particiones y luego usé fdisk para configurarlas para que escriban 'fd'. Luego haga exactamente lo que hizo y el dispositivo RAID se formará automáticamente en el momento del inicio. Con una input en / etc / fstab, incluso se montará …

Una advertencia: Usar /etc/mdadm.conf destruyó mi sistema RHEL7 3.10.0-514.6.1.el7.x86_6.

Me encontré con esta pregunta que me ayudó mucho durante la solución de problemas. Pero ninguna de las respuestas podría resolver mi problema.

Entonces quizás esto ayude a alguien a tener el mismo problema. En mi caso, tengo dos unidades NVME en un RedHat Linux 7.2.

SELinux tiene un problema con nvme y evita que mdadm trabaje con ellos.

Síntomas:

Crear software RAID como se describe en la pregunta de este hilo. Después de reiniciar el RAID se ha ido:

  • /proc/mdstat está vacío y /dev/md0 no existe
  • mdadm --assemble --scan trae el RAID hacia arriba.

Solución:

Inhabilité Selinux en mi caso. Sé que esto no es posible en todos los sistemas. Pero tal vez estés en la dirección correcta de mi publicación.