Wie wird ein inaktives RAID-Gerät wieder funktionsfähig?

Nach dem Booten geht mein RAID1-Gerät ( /dev/md_d0*) manchmal in einen komischen Zustand über und ich kann es nicht mounten.

^{* Ursprünglich habe ich erstellt, /dev/md0aber es hat sich irgendwie in geändert /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

Das RAID-Gerät scheint irgendwie inaktiv zu sein :

# 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.

Die Frage ist, wie man das Gerät wiedermdmadm aktiviert (mit , nehme ich an)?

(Andere Male ist es in Ordnung (aktiv) nach dem Booten und ich kann es ohne Probleme manuell einhängen. Aber es wird immer noch nicht automatisch eingehängt, obwohl ich es in habe /etc/fstab:

/dev/md_d0        /opt           ext4    defaults        0       0

Also eine Bonusfrage: Was soll ich tun, damit das RAID-Gerät /optbeim Booten automatisch bereitgestellt wird? )

Dies ist eine Ubuntu 9.10 Workstation. Hintergrundinformationen zu meinem RAID-Setup in dieser Frage .

Edit : Mein /etc/mdadm/mdadm.confsieht so aus. Ich habe diese Datei noch nie berührt, zumindest nicht von Hand.

# 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

Im /proc/partitionsletzten Eintrag ist md_d0spätestens jetzt, nach dem Neustart, wenn das Gerät zufällig wieder aktiv ist. (Ich bin nicht sicher, ob es dasselbe wäre, wenn es inaktiv ist.)

Vorsatz : Wie Jimmy Hedman vorschlug , nahm ich die Ausgabe von mdadm --examine --scan:

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

und fügte es hinzu /etc/mdadm/mdadm.conf, was das Hauptproblem behoben zu haben scheint. Nach dem Wechsel /etc/fstabzur /dev/md0erneuten Verwendung (anstelle von /dev/md_d0) wird das RAID-Gerät auch automatisch bereitgestellt!

Für Ihre Bonusfrage:

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

Ich habe festgestellt, dass ich das Array manuell hinzufügen /etc/mdadm/mdadm.confmuss, damit Linux es beim Neustart mounten kann. Ansonsten bekomme ich genau das was du hier hast - md_d1-Geräte die inaktiv sind etc.

Die Conf-Datei sollte wie folgt aussehen - dh eine ARRAYZeile für jedes MD-Gerät. In meinem Fall fehlten die neuen Arrays in dieser Datei, aber wenn Sie sie aufgelistet haben, ist dies wahrscheinlich keine Lösung für Ihr Problem.

# 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

Fügen Sie ein Array pro MD-Gerät hinzu und fügen Sie diese nach dem oben angegebenen Kommentar oder, falls kein solcher Kommentar vorhanden ist, am Ende der Datei hinzu. Sie erhalten die UUIDs, indem Sie Folgendes tun 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

Wie Sie sehen, können Sie die Ausgabe des Scan-Ergebnisses so ziemlich einfach in die Datei kopieren.

Ich verwende ubuntu desktop 10.04 LTS und soweit ich mich erinnere, unterscheidet sich dieses Verhalten von der Serverversion von Ubuntu. Es ist jedoch so lange her, dass ich meine md-Geräte auf dem Server erstellt habe, dass ich möglicherweise falsch liege. Es kann auch sein, dass ich gerade eine Option verpasst habe.

Wie auch immer, das Hinzufügen des Arrays in der conf-Datei scheint den Trick zu tun. Ich habe die obigen Raids 1 und 5 jahrelang ohne Probleme ausgeführt.

Warnung: Lassen Sie mich zunächst sagen, dass das Folgende (aufgrund der Verwendung von "--force") für mich ein Risiko darstellt. Wenn Sie nicht wiederherstellbare Daten haben, empfehle ich Ihnen, Kopien der betroffenen Partitionen zu erstellen, bevor Sie eine von ihnen ausprobieren die Dinge unten. Dies hat jedoch bei mir funktioniert.

Ich hatte das gleiche Problem mit einem Array, das als inaktiv angezeigt wurde, und nichts, was ich getan habe, einschließlich "mdadm --examine --scan> /etc/mdadm.conf", wie von anderen hier vorgeschlagen, half überhaupt.

In meinem Fall wurde beim Versuch, das RAID-5-Array nach einem Austausch des Laufwerks zu starten, festgestellt, dass es verschmutzt war (über 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.

Dies führt dazu, dass es in folgenden Fällen als inaktiv angezeigt wird /proc/mdstat:

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

Ich habe festgestellt, dass auf allen Geräten die gleichen Ereignisse aufgetreten sind, mit Ausnahme des Laufwerks, das ich ausgetauscht hatte ( /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

Die Array-Details zeigten jedoch, dass 4 von 5 Geräten verfügbar waren:

[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

(Das oben Gesagte stammt aus dem Speicher in der Spalte "Status". Ich kann es nicht in meinem Scroll-Back-Puffer finden.)

Ich konnte das Problem beheben, indem ich das Array anhielt und es dann wieder zusammenbaute:

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

Zu diesem Zeitpunkt lief das Array mit 4 der 5 Geräte, und ich konnte das Ersatzgerät hinzufügen und es wird neu erstellt. Ich kann problemlos auf das Dateisystem zugreifen.

Ich hatte Probleme mit Ubuntu 10.04, bei denen ein Fehler in FStab das Booten des Servers verhinderte.

Ich habe diesen Befehl ausgeführt, wie in den obigen Lösungen erwähnt:

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

Hiermit werden die Ergebnisse von "mdadm --examine --scan" an "/etc/mdadm/mdadm.conf" angehängt.

In meinem Fall war dies:

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

Dies ist eine fakeraid 0. Mein Befehl in / etc / fstab zum automatischen Mounten lautet:

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

Wichtig ist hier, dass Sie "nobootwait" und "nofail" haben. Nobootwait überspringt alle Systemmeldungen, die Sie am Booten hindern. In meinem Fall befand sich dies auf einem Remoteserver, daher war dies unerlässlich.

Hoffe das wird einigen Leuten helfen.

Sie können Ihr md-Gerät mit aktivieren

mdadm -A /dev/md_d0

Ich nehme an, ein Startskript startet zu früh, bevor eines der RAID-Mitglieder entdeckt wurde, oder ein ähnliches Problem. Als schnelle und fehlerhafte Umgehung sollten Sie in der Lage sein, diese Zeile zu /etc/rc.local hinzuzufügen:

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

Edit: anscheinend enthält deine /etc/mdadm/mdadm.conf noch den alten Konfigurationsnamen. Bearbeiten Sie diese Datei und ersetzen Sie die Vorkommen von md0 durch md_d0.

Ich hatte ein ähnliches Problem ... mein Server konnte md2 nicht mounten, nachdem ich die zugehörigen Gerätepartitionen vergrößert hatte. Beim Lesen dieses Threads stellte ich fest, dass das md2-RAID-Gerät eine neue UUID hatte und der Computer versuchte, die alte zu verwenden.

Wie vorgeschlagen ... mit 'md2' Ausgabe von

mdadm --examine --scan

Ich habe /etc/mdadm/mdadm.confdie alte UUID-Zeile bearbeitet und durch die Ausgabe des obigen Befehls ersetzt, und mein Problem ist behoben.

Wenn Sie so tun, als ob Sie etwas /dev/md[012346789}damit machen, geht das zu /dev/md{126,127...}. /dev/md0weiter gemountet bei /dev/md126oder /dev/md127du musst:

umount /dev/md127 oder umount /dev/md126.

Dies ist vorübergehend, damit Sie Befehle und einige Anwendungen ausführen können, ohne Ihr System anzuhalten.

md_d0 : inactive sda4[0](S)sieht für ein RAID1-Array falsch aus. Es scheint darauf ^_hinzudeuten , dass das Array keine aktiven Geräte und ein Ersatzgerät hat ^{_{(angezeigt durch (S), würden Sie dort (F) für ein ausgefallenes Gerät und nichts für ein OK / aktives Gerät sehen)}} - für ein RAID1-Array, das nicht ist Läuft nicht beeinträchtigt, sollte es mindestens zwei einwandfreie / aktive Geräte geben ^{_{(und für}} ein beeinträchtigtes Array ^_mindestens ein einwandfreies ^{_{/ aktives Gerät),}} und Sie können ein RAID1-Array nicht aktivieren, wenn keine nicht ausgefallenen Ersatzgeräte vorhanden sind (als Ersatzgeräte) Enthalten Sie keine Kopie der Daten, bis sie aktiviert werden, wenn ein anderes Laufwerk ausfällt. Wenn ich diese /proc/mdstatAusgabe richtig lese, können Sie das Array im aktuellen Status nicht aktivieren.

Haben Sie physische Laufwerke in der Maschine, die nicht hochgefahren werden konnten? Werden ls /dev/sd*alle Laufwerke und Partitionen aufgelistet, die Sie normalerweise auf diesem Computer erwarten würden?

Eine einfache Möglichkeit, das Array zum Laufen zu bringen, vorausgesetzt, es liegt kein Hardwareproblem vor und Sie haben genügend Laufwerke / Partitionen, um das Array zu starten:

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

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

Es könnte sein, dass das Array aus irgendeinem Grund in Ordnung ist, aber etwas daran gehindert hat, es zu starten oder zu bauen. In meinem Fall lag dies daran, dass mdadm nicht wusste, dass der ursprüngliche Array-Name md127 war und alle Laufwerke für dieses Array vom Netz getrennt wurden. Beim Repluggen musste ich manuell zusammenbauen (wahrscheinlich ein Fehler, bei dem mdadm dachte, das Array sei wegen des alten Offline-Arraynamens bereits aktiv).