Come far funzionare nuovamente un dispositivo RAID inattivo?

Dopo l'avvio, il mio dispositivo RAID1 ( /dev/md_d0*) a volte passa in uno stato divertente e non riesco a montarlo.

^{* Inizialmente ho creato /dev/md0ma in qualche modo si è cambiato /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

Il dispositivo RAID sembra essere inattivo in qualche modo:

# 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 domanda è: come rendere nuovamente attivo il dispositivo (utilizzo mdmadm, presumo)?

(Altre volte va bene (attivo) dopo l'avvio e posso montarlo manualmente senza problemi. Ma non si monterà automaticamente anche se ce l'ho /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Quindi una domanda bonus: cosa devo fare per far montare automaticamente il dispositivo RAID /optall'avvio? )

Questa è una workstation Ubuntu 9.10. Informazioni di base sulla mia configurazione RAID in questa domanda .

Modifica : il mio /etc/mdadm/mdadm.confassomiglia a questo. Non ho mai toccato questo file, almeno 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 <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

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

In /proc/partitionsultimo ingresso è md_d0almeno ora, dopo il riavvio, quando il dispositivo sembra essere di nuovo attivo. (Non sono sicuro che sarebbe lo stesso quando è inattivo.)

Risoluzione : come ha suggerito Jimmy Hedman , ho preso l'output di mdadm --examine --scan:

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

e aggiunto in /etc/mdadm/mdadm.conf, che sembra aver risolto il problema principale. Dopo aver cambiato /etc/fstabper /dev/md0riutilizzarlo (anziché /dev/md_d0), anche il dispositivo RAID viene montato automaticamente!

Per la tua domanda bonus:

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

Ho scoperto che devo aggiungere manualmente l'array /etc/mdadm/mdadm.confper fare in modo che Linux lo monti al riavvio. Altrimenti ottengo esattamente quello che hai qui - dispositivi md_d1che sono inattivi ecc.

Il file conf dovrebbe apparire come sotto - cioè una ARRAYriga per ogni dispositivo md. Nel mio caso i nuovi array mancavano in questo file, ma se li hai elencati questo probabilmente non è una soluzione al tuo 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

Aggiungi un array per dispositivo md e aggiungili dopo il commento incluso sopra, o se non esiste tale commento, alla fine del file. Ottieni gli UUID facendo 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

Come puoi vedere, puoi semplicemente copiare l'output dal risultato della scansione nel file.

Eseguo Ubuntu desktop 10.04 LTS, e per quanto ricordo questo comportamento differisce dalla versione server di Ubuntu, tuttavia è stato tanto tempo fa che ho creato i miei dispositivi md sul server che potrei sbagliare. Potrebbe anche essere che ho perso qualche opzione.

Ad ogni modo, l'aggiunta dell'array nel file conf sembra fare il trucco. Ho eseguito il raid 1 sopra e il raid 5 per anni senza problemi.

Avvertenza: prima di tutto lasciatemi dire che quanto segue (a causa dell'uso di "--force") mi sembra rischioso e, se avete dati irrecuperabili, vi consiglio di fare copie delle partizioni coinvolte prima di iniziare a provare qualsiasi le cose qui sotto. Tuttavia, questo ha funzionato per me.

Ho avuto lo stesso problema, con un array apparentemente inattivo, e nulla di ciò che ho fatto, incluso "mdadm --examine --scan> /etc/mdadm.conf", come suggerito da altri qui, mi ha aiutato.

Nel mio caso, quando ha tentato di avviare l'array RAID-5 dopo una sostituzione dell'unità, diceva che era sporco (tramite 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.

Causandolo per apparire inattivo in /proc/mdstat:

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

Ho scoperto che tutti i dispositivi avevano gli stessi eventi, ad eccezione dell'unità che avevo sostituito ( /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

Tuttavia, i dettagli dell'array hanno mostrato che erano disponibili 4 dispositivi su 5:

[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

(Quanto sopra è dalla memoria nella colonna "Stato", non riesco a trovarlo nel mio buffer di scorrimento).

Sono stato in grado di risolvere questo problema arrestando l'array e quindi riassemblandolo:

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

A quel punto l'array era attivo, funzionante con 4 dei 5 dispositivi e sono stato in grado di aggiungere il dispositivo sostitutivo e la ricostruzione. Sono in grado di accedere al file system senza alcun problema.

Ho avuto problemi con Ubuntu 10.04 in cui un errore in FStab ha impedito l'avvio del server.

Ho eseguito questo comando come indicato nelle soluzioni sopra:

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

Questo aggiungerà i risultati da "mdadm --examine --scan" a "/etc/mdadm/mdadm.conf"

Nel mio caso, questo era:

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

Questo è un falso 0. Il mio comando in / etc / fstab per il montaggio automatico è:

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

La cosa importante qui è che hai "nobootwait" e "nofail". Nobootwait salterà tutti i messaggi di sistema che impediscono l'avvio. Nel mio caso, questo era su un server remoto, quindi era essenziale.

Spero che questo possa aiutare alcune persone.

Puoi attivare il tuo dispositivo md con

mdadm -A /dev/md_d0

Suppongo che alcuni script di avvio vengano avviati troppo presto, prima che uno dei membri RAID venisse scoperto o un problema simile. Come soluzione rapida e sporca, dovresti essere in grado di aggiungere questa riga a /etc/rc.local:

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

Modifica: apparentemente il tuo /etc/mdadm/mdadm.conf contiene ancora il vecchio nome di configurazione. Modifica questo file e sostituisci le occorrenze di md0 con md_d0.

md_d0 : inactive sda4[0](S)sembra sbagliato per un array RAID1. Sembra suggerire che l'array non ha dispositivi attivi e un dispositivo di riserva ^{_{(indicato da (S), vedresti (F) lì per un dispositivo guasto e niente per un dispositivo OK / attivo)}} - per un array RAID1 che non è in esecuzione degradata dovrebbero esserci almeno due dispositivi OK / attivi ^{_{(e per un array degradato, almeno un dispositivo OK / attivo)}} e non è possibile attivare un array RAID1 senza dispositivi non di riserva non guasti (come ricambi non contengono una copia dei dati fino a quando non vengono resi attivi in ​​caso di guasto di un'altra unità). Se sto leggendo /proc/mdstatcorrettamente quell'output, non sarai in grado di attivare l'array nel suo stato attuale.

Hai delle unità fisiche nella macchina che non sono riuscite a girare? Does ls /dev/sd*lista tutte le unità e le partizioni che normalmente si aspetterebbe di vedere su quella macchina?

Ho avuto un problema simile ... il mio server non montava md2 dopo che avevo sviluppato le partizioni di dispositivi associati. Leggendo questo thread ho scoperto che il dispositivo RAID md2 aveva un nuovo UUID e la macchina stava cercando di usare quello vecchio.

Come suggerito ... usando 'md2' output da

mdadm --examine --scan

Ho modificato /etc/mdadm/mdadm.confe sostituito la vecchia linea UUID con l'output del comando precedente e il mio problema è andato via.

Quando fai finta di fare qualcosa con /dev/md[012346789}esso va /dev/md{126,127...}. /dev/md0continua montato /dev/md126o /dev/md127devi:

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

Questo è temporaneo per consentire l'esecuzione di comandi e alcune applicazioni senza arrestare il sistema.

Un modo semplice per far funzionare l'array presupponendo che non ci siano problemi hardware e che hai abbastanza unità / partizioni per avviare l'array è il seguente:

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

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

Potrebbe essere che per qualsiasi motivo l'array vada bene, ma qualcosa gli ha impedito l'avvio o la costruzione. Nel mio caso, questo perché mdadm non sapeva che il nome originale dell'array era md127 e tutte le unità erano scollegate per quell'array. Durante la sostituzione ho dovuto assemblare manualmente (probabilmente un bug in cui mdadm pensava che l'array fosse già attivo a causa del vecchio nome dell'array offline).