Usuario del software
2010-03-09 09:55:18 +0000 2010-03-09 09:55:18 +0000
31

¿Cómo hacer que un dispositivo RAID inactivo vuelva a funcionar?

Después de arrancar, mi dispositivo RAID1 (/dev/md_d0 *) a veces se pone en un estado extraño y no puedo montarlo.

* Originalmente creé /dev/md0 pero de alguna manera se ha transformado en /dev/md_d0.

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail or so

El dispositivo RAID parece estar inactivo de alguna manera:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

La pregunta es, cómo hacer que el dispositivo vuelva a estar activo (usando mdmadm, supongo)?

(Otras veces está bien (activo) después del arranque, y puedo montarlo manualmente sin problemas. Pero sigue sin montarse automáticamente aunque lo tenga en /etc/fstab:

/dev/md_d0 /opt ext4 defaults 0 0

Así que una pregunta extra: **¿Qué debo hacer para que el dispositivo RAID se monte automáticamente en /opt al arrancar?

Esta es una estación de trabajo Ubuntu 9.10. Información de fondo sobre mi configuración RAID en esta pregunta .

Editar : Mi /etc/mdadm/mdadm.conf se ve así. Nunca he tocado este archivo, al menos a mano.

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST 

# instruct the monitoring daemon where to send mail alerts
MAILADDR 

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

En el /proc/partitions la última entrada es md_d0 al menos ahora, después de reiniciar, cuando el dispositivo vuelve a estar activo. (No estoy seguro de si sería lo mismo cuando está inactivo).

Resolución : como sugirió Jimmy Hedman , tomé la salida de mdadm --examine --scan:

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

y la añadí en /etc/mdadm/mdadm.conf, lo que parece haber solucionado el problema principal. Después de cambiar /etc/fstab para usar /dev/md0 de nuevo (en lugar de /dev/md_d0), ¡el dispositivo RAID también se monta automáticamente!

Respuestas [9]

25
2010-03-10 12:34:08 +0000

Para su pregunta de bonificación:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf
25
11
2011-08-01 02:41:23 +0000

He descubierto que tengo que añadir el array manualmente en /etc/mdadm/mdadm.conf para que Linux lo monte al reiniciar. De lo contrario, obtengo exactamente lo que tienes aquí - md_d1-dispositivos que están inactivos, etc.

El archivo conf debería ser como el de abajo - es decir, una línea ARRAY para cada dispositivo md. En mi caso, las nuevas matrices no aparecían en este archivo, pero si usted las tiene listadas, probablemente esto no solucione su problema.

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Añade un array por cada md-device, y añádelos después del comentario incluido arriba, o si no existe tal comentario, al final del archivo. Los UUIDs se obtienen haciendo sudo mdadm -E --scan:

$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Como puedes ver, puedes copiar la salida del resultado del escaneo en el archivo.

Corro ubuntu desktop 10.04 LTS, y por lo que recuerdo este comportamiento difiere de la versión del servidor de Ubuntu, sin embargo fue hace tanto tiempo que creé mis md-devices en el servidor que puedo estar equivocado. También puede ser que se me haya pasado alguna opción.

De todos modos, añadir el array en el archivo conf parece hacer el truco. He ejecutado el anterior raid 1 y raid 5 durante años sin problemas.

11
7
2012-03-21 22:21:47 +0000

Advertencia: En primer lugar permítanme decir que lo siguiente (debido al uso de "--force") me parece arriesgado, y si tienes datos irrecuperables te recomendaría hacer copias de las particiones implicadas antes de empezar a intentar cualquiera de las cosas que se indican a continuación. Sin embargo, esto me funcionó.

Tuve el mismo problema, con un array que aparecía como inactivo, y nada de lo que hice, incluyendo el "mdadm --examine --scan >/etc/mdadm.conf", como sugirieron otros aquí, ayudó en absoluto.

En mi caso, cuando intentaba arrancar el array RAID-5 después de un cambio de disco, decía que estaba sucio (a través de dmesg):

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

Causando que apareciera como inactivo en /proc/mdstat:

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

Sí comprobé que todos los dispositivos tenían los mismos eventos en ellos, excepto la unidad que había sustituido (/dev/sdb4):

[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

Sin embargo, los detalles del array mostraban que tenía 4 de los 5 dispositivos disponibles:

[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number Major Minor RaidDevice State
       0 8 4 0 inactive dirty /dev/sda4
       2 8 36 2 inactive dirty /dev/sdc4
       3 8 52 3 inactive dirty /dev/sdd4
       5 8 68 4 inactive dirty /dev/sde4

(Lo anterior es de memoria en la columna de "Estado", no lo encuentro en mi buffer de retroceso).

Pude resolverlo deteniendo el array y volviéndolo a montar:

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

En ese momento el array estaba levantado, funcionando con 4 de los 5 dispositivos, y pude añadir el dispositivo de reemplazo y se está reconstruyendo. Puedo acceder al sistema de archivos sin ningún problema.

7
5
2012-04-24 01:29:43 +0000

Estaba teniendo problemas con Ubuntu 10.04 donde un error en FStab impedía el arranque del servidor.

Ejecuté este comando como se menciona en las soluciones anteriores:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

Esto añadirá los resultados de "mdadm --examine --scan" a "/etc/mdadm/mdadm.conf"

En mi caso, esto fue:

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

Esto es un fakeraid 0. Mi comando en /etc/fstab para montar automáticamente es:

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

Lo importante aquí es que tienes "nobootwait" y "nofail". Nobootwait omitirá cualquier mensaje del sistema que le impida arrancar. En mi caso, esto fue en un servidor remoto por lo que fue esencial.

Espero que esto ayude a algunos.

5
2
2010-03-09 10:46:27 +0000

Puede activar su dispositivo md con

mdadm -A /dev/md_d0

Supongo que algún script de arranque se inicia demasiado pronto, antes de que uno de los miembros del RAID fuera descubierto o algún problema similar. Como una solución rápida y sucia, debería poder añadir esta línea a /etc/rc.local :

mdadm -A /dev/md_d0 && mount /dev/md_d0

Edite : aparentemente su /etc/mdadm/mdadm.conf todavía contiene el antiguo nombre de configuración. Edite este archivo y sustituya las apariciones de md0 por md_d0.

2
2
2011-08-15 01:56:27 +0000

Tuve un problema similar... mi servidor no montaba md2 después de haber hecho crecer las particiones de los dispositivos asociados. Al leer este hilo descubrí que el dispositivo RAID md2 tenía un nuevo UUID y la máquina intentaba utilizar el antiguo.

Como se sugirió... usando la salida de 'md2' de

mdadm --examine --scan

edité /etc/mdadm/mdadm.conf y reemplacé la vieja línea UUID con la salida del comando anterior y mi problema desapareció.

2
2
2010-03-10 13:14:14 +0000

md_d0 : inactive sda4[0](S) parece incorrecto para una matriz RAID1. Parece sugerir que el array no tiene dispositivos activos y un dispositivo de repuesto (indicado por la (S), veríais la (F) allí para un dispositivo fallado y nada para un dispositivo OK/activo) - para un array RAID1 que no esté funcionando degradado debería haber al menos dos dispositivos OK/activos (y para un array degradado, al menos un dispositivo OK/activo) y no podéis activar un array RAID1 sin dispositivos de repuesto no fallados (ya que los repuestos no contienen una copia de los datos hasta que se activan cuando otra unidad falla). Si estoy leyendo bien esa salida /proc/mdstat, no podrás activar el array en su estado actual.

¿Tiene alguna unidad física en la máquina que haya fallado al girar? ¿Lista ls /dev/sd* todas las unidades y particiones que normalmente esperarías ver en esa máquina?

2
2
2012-11-26 21:43:18 +0000

Cuando pretendes hacer algo con /dev/md[012346789} se va a /dev/md{126,127...}./dev/md0 sigue montado en /dev/md126 o /dev/md127 tienes que:

umount /dev/md127 o umount /dev/md126.

Esto es temporal para permitirte ejecutar comandos y algunas aplicaciones sin detener el sistema.

2
2
2017-02-14 23:24:17 +0000

Una forma sencilla de conseguir que el array se ejecute asumiendo que no hay ningún problema de hardware y que tienes suficientes unidades/particiones para arrancar el array es la siguiente:

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 sudo mdadm --manage /dev/md20 --run

Puede ser que por alguna razón el array esté bien pero algo impidió que se iniciara o construyera. En mi caso fue porque mdadm no sabía que el nombre original del array era md127 y todas las unidades estaban desconectadas para ese array. Al volver a conectar tuve que ensamblar manualmente (probablemente un error en el que mdadm pensó que el array ya estaba activo debido al antiguo nombre de array desconectado).

2