Arch Linux

Platte unerklärlich aus dem RAID gefallen

Ovion

Hi,
mir ist heute beim Checken meines Spiegel-RAID aufgefallen, dass eine der beiden Platten aus dem RAID-Verbund rausgeworfen wurde. Allerdings kann ich nicht ganz nachvollziehen, warum. Ich kann noch auf die Partitionstabelle zugreifen, die SMART-Werte sehen gut aus, die Partitionen selbst sind unter /dev vorhanden/sichtbar.

sudo mdadm --detail /dev/md0
sudo mdadm --detail /dev/md1

sagen jedoch beide, dass die sda-Partitionen "active sync" sind, die sdb-Partitionen hingegen sind "removed".

Struktur bei mir:
/dev/sda -> /dev/sda1, /dev/sda5
/dev/sdb -> /dev/sdb1, /dev/sdb5

Die 1er geben zusammen md0, meine /boot-Partition, die 5er md1 mit luks+lvm+Rest des Verzeichnisbaumes.

Finger drauflegen hat ergeben, dass beide Platten rotieren (sdb subjektiv weniger als sda, was aber logisch ist, da von sda gelesen wird, während sdb ja aus dem Array geflogen ist).

Ist sdb defekt oder ist meine Arrayimplementation fehlerhaft und wie komme ich der tatsächlichen Lösung am besten näher? Bin gerade etwas verwirrt. Danke schonmal!

GerBra

cat /proc/mdstat
?

Ein Ansatz wäre mal in den Logfiles zu graben:

zgrep mdadm /var/log/everything.log*

evtl. noch alles durch ein grep -i fail pipen.
So könntest du evtl. sehen wann das Problem auftrat und rund um den zeitpunkt die anderen Logeinträge mal anschauen.

Evtl. auch nochmal interessant:
mdadm -E /dev/sdb1
mdadm -E /dev/sdb5

Deine Arrays sind richtig in /etc/mdadm.conf eingetragen?
Ansonsten könntest du einfach (wenn die Logs nichts ergeben) ein --re-add (oder --add) für sdb machen, ich würde wohl erstmal an die sdb1/md0 gehen und schauen, ob der resync funktioniert.

Ovion

zgrep mdadm /var/log/everything.log* liefert nur Beschwerden über ein nicht gefundenes sendmail:

/var/log/everything.log.3:Sep 19 16:33:26 localhost mdadm[674]: sh: /usr/sbin/sendmail: Datei oder Verzeichnis nicht gefunden

Davon gibt's noch drei weitere, Sep 28, 2 x Oct 7. Heißt das, dass er das Programm, über dass er mir normalerweise die Alarmmail schicken will, nicht findet? Wäre ja nicht so cool, muss ich mich dann auf jeden Fall auch noch drum kümmern.

#cat /proc/mdstat

Personalities : [raid1] 
md0 : active raid1 sda1[0]
      96320 blocks super 1.0 [2/1] [U_]
      
md1 : active raid1 sda5[0]
      976444032 blocks super 1.2 [2/1] [U_]
      
unused devices: <none>

Nach einem "sudo mdadm --add /dev/md0 /dev/sdb1" passt sich die Ausgabe oben geringfügig an:

#[...]
md0 : active raid1 sdb1[2] sda1[0]
      96320 blocks super 1.0 [2/2] [UU]
#[...]

Ich nehme mal stark an, das sollte so sein?

mdadm.conf habe ich mir automatisch generieren lassen ("mdadm --examine --scan" war's, glaube ich, und nach /etc/mdadm.conf geleitet.

#/etc/mdadm.conf
ARRAY /dev/md/0 metadata=1.0 UUID=e591dbab:c10941b9:5f0bfb6c:7142290f name=archiso:0
ARRAY /dev/md/1 metadata=1.2 UUID=8791071e:1cfafc62:df05c7a0:1874216f name=archiso:1
MAILADDR ...

Habe mir in dem Zusammenhang mal Beispiele für die mdadm.conf angesehen, fehlt hier tatsächlich schlicht die "device="-Option? Habe ich mich wohl zu sehr darauf verlassen, dass das generieren der conf von mdadm eine brauchbare Datei liefert, wie? Aber wie findet er dann überhaupt etwas? Ich spreche in meinem System nur /dev/md1 (im Bootloader) an, wenn es tatsächlich an der fehlenden "device"-Option liegt, wie kann er dann überhaupt mdx und sdax in Zusammenhang bringen?

Die anderen Befehle:

#mdadm -E /dev/sdb1:

/dev/sdb1:
          Magic : a92b4efc
        Version : 1.0
    Feature Map : 0x0
     Array UUID : e591dbab:c10941b9:5f0bfb6c:7142290f
           Name : archiso:0
  Creation Time : Mon Aug  6 20:57:18 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 192688 (94.10 MiB 98.66 MB)
     Array Size : 96320 (94.08 MiB 98.63 MB)
  Used Dev Size : 192640 (94.08 MiB 98.63 MB)
   Super Offset : 192696 sectors
          State : clean
    Device UUID : aea34818:b15b760b:d8e4e8c8:61260ca1

    Update Time : Mon Oct  1 15:07:58 2012
       Checksum : 5b47a484 - correct
         Events : 17


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)

#sudo mdadm -E /dev/sdb5

        Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 8791071e:1cfafc62:df05c7a0:1874216f
           Name : archiso:1
  Creation Time : Mon Aug  6 20:58:12 2012
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1952888363 (931.21 GiB 999.88 GB)
     Array Size : 976444032 (931.21 GiB 999.88 GB)
  Used Dev Size : 1952888064 (931.21 GiB 999.88 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
          State : active
    Device UUID : 89d8ecd8:9ece5fb2:d407108f:492f4525

    Update Time : Wed Sep 19 16:20:30 2012
       Checksum : a59a6d81 - correct
         Events : 187


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing)

Auf jeden Fall schonmal allerbesten Dank, das sieht nach einer Spur aus!
Der Plan dürfte nun also eine Korrektur der mdadm.conf sein, wenn ich das richtig sehe?

EDIT:

#sudo mdadm --add /dev/md1 /dev/sdb5
#cat /proc/mdstat
md1 : active raid1 sdb5[2] sda5[0]
      976444032 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (2222144/976444032) finish=175.3min speed=92589K/sec

"recovery" ist hier schon in Ordnung, oder? Oder sollte da "sync stehen?

GerBra

Ovion schriebzgrep mdadm /var/log/everything.log* liefert nur Beschwerden über ein nicht gefundenes sendmail:
/var/log/everything.log.3:Sep 19 16:33:26 localhost mdadm[674]: sh: /usr/sbin/sendmail: Datei oder Verzeichnis nicht gefunden
Davon gibt's noch drei weitere, Sep 28, 2 x Oct 7. Heißt das, dass er das Programm, über dass er mir normalerweise die Alarmmail schicken will, nicht findet? Wäre ja nicht so cool, muss ich mich dann auf jeden Fall auch noch drum kümmern.

Hmm, bißchen wenig von mdadm. Läßt du den mdadm-Daemon (k.A. wie das ggf. bei systemd heißt) nicht laufen? Normalerweise gibt mdadm recht ausführlich Laut wenn was schief läuft (habe grad kein Raid hier, deshalb eine Zeile woanders her):

Sep 29 10:42:00 [mdadm] Fail event detected on md device /dev/md0, component device /dev/sdg1

Eigentlich müßte alles nach everything.log reinkommen, aber du kannst dir sicherheitshalber ja noch mal per obigem zgrep auch alle errors.log* und kernel.log* durchkämmen.
//Edit: (zgrep deshalb, da alte Logfiles ja per logrotate archiviert+gepackt werden. Es gibt etliche z-Tools wie zless, zcat die direkt auf den Archiven arbeiten)

Ovion schrieb (/proc/mdstat Ausgaben)
Nach einem "sudo mdadm --add /dev/md0 /dev/sdb1" passt sich die Ausgabe oben geringfügig an:
Ich nehme mal stark an, das sollte so sein?

Geringfügig ist gut ;-) Das vorher fehlende U (und ein Device als Unterstrich _) zeigte das deine md's ein "geringfügiges" Problem hatten. Es sollten immer soviele U's vorhanden sein wie Array-Mitglieder, ein _ deutet auf einen Ausfall/Problem.

Zur mdadm.conf:
Die ist eigentlich ausreichend. Die Devices werden (wenn sie nicht extra aufgeführt sind, entweder in der DEVICES-Sektio oder bei den ARRAYs) aus /proc/partitions und den jeweiligen Metadaten zusammengstellt. I.d.R. ist das ausreichend.
Du kannst dir die "originale" mdadmconf aus dem Arch-Paket ja nochmal anschauen, ich mache es eigentlich immer so daß mein mdadm --examine --scan an diese Datei angehängt wird anstatt eine neue zu erstellen.

Evtl. wichtig wäre halt das ein mdadm im Monitor-Modus läuft (was der mdadm-Daemon macht), das System eine Warnmail versenden kann (ins eigene LAN oder ach extern). Auch PROGRAM ist nett, mit so einem Skript kann man von Jabber-Benachrichtigung bis SMS-Versand eigentlich alles machen.

Ovion schrieb

#sudo mdadm --add /dev/md1 /dev/sdb5
#cat /proc/mdstat
md1 : active raid1 sdb5[2] sda5[0]
      976444032 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (2222144/976444032) finish=175.3min speed=92589K/sec

"recovery" ist hier schon in Ordnung, oder? Oder sollte da "sync stehen?

Nein, ist ok so.
Nett um das immer im Auge zu haben (und nicht immer neu absetze zu müssen) ist hier watch:
watch cat /proc/mdstat

Den Sync kann man auch beschleunigen, normalerweise bricht dieser stark ein wenn auf dem System weitergearbeitet wird.

cat /proc/sys/dev/raid/speed_limit_max
cat /proc/sys/dev/raid/speed_limit_min
(speed_limit_min nun gut auf die Hälfte oder höher als die Ausgabe von max setzen)
echo 100000 > /proc/sys/dev/raid/speed_limit_min

Wobei deine speed-Rate ja ganz ordentlich ist.

//Edit2: beim Wiederhinzufügen von sdbX zu mdX wäre --re-add IMHO zu bevorzugen gewesen. Lies dir die manpage zu mdadm nochmal bei den beiden Parametern durch. Bei nur 2 Array-Mitgliedern ist es jetzt nicht so wichtig, aber bei mehreren will man eiegntlich ein vorher removdes Device möglichst wieder im gleichen Slot haben. Bei dir für md0 ist sdb1 nun im Slot 2 (sda1 ist Slot 0), es war aber nach dem Assemblen sicher mal in Slot 1. Außerdem verhindert --re-add daß meist nicht gewollte Hinzufügen als Spare-Device wenn sdb1 die Metadaten kaputt gewesen wären oder noch nie vorher im Array war. Ich bevorzuge eigentlich bei so einem Fall --re-add, schrieb ich ja auch im vorigen Beitrag (zumindest wollte ich es so ausdrücken, ich meinte es, ach was weiß ich denn schon… <g>)

Ovion

mdadm.service loaded, active, running, "zgrep mdadm" auf error-logs und kernel-logs ergibt nix, "mdadm --examine --scan" gibt mir dieselbe Ausgabe, die ich schon als mdadm.conf ausgewiesen habe.

Nachdem der sync fertig ist, system neustarten, gucken, ob beide Platten drinhängen und falls nicht, läuft offenbar was beim Start schief. Dann würde ich nochmal ein "manuelle" Konfiguration der mdadm.conf ausprobieren, ist aktuell mein Plan. Haben die UUIDs irgendwelche Vorteile gegenüber den angaben via /dev/blub?

GerBra

Ovion schriebmdadm.service loaded, active, running, "zgrep mdadm" auf error-logs und kernel-logs ergibt nix,

Gut, ich weiß ja nun nicht wie weit deine Logfiles (auch die archivierten) zurückreichen, deine Arrays hast du ja im August zusammengestellt. Evtl. ist das Problem ja schon länger existent.
Oder anders herum: Wann hast du deine Arrays zuletzt bewußt mit beiden Platten aktiv gesehen? Oder: Kannst du sicher sein, daß nach dem Assemblen überhaupt jemals ein "richtiges" RAID1 bestand ;-)

Ovion schrieb "mdadm --examine --scan" gibt mir dieselbe Ausgabe, die ich schon als mdadm.conf ausgewiesen habe.

Natürlich. Aber die originale mdadmconf aus dem Archlinux-mdadm-Paket hat ja schon einiges aktiv (also ohne # vor den Zeilen), z.B.:

DEVICE partitions
MAILADDR root@exaple.com

nebst etlicher Kommentare und Beispiele. Zumindest das DEVICE partitions scheint ja bei dir zu fehlen (Gut, das ist nicht weiter schlimm AFAIK da es sowieso das normalverhalten von mdadm ist). Das passiert aber dann wenn man:
mdadm --examine --scan > /etc/madm.conf
macht (also die orginale samt Inhalt *überschreibt*) statt:
mdadm --examine --scan >> /etc/madm.conf
(wo dann nur die loaklen Arrays hinzukämen).

Ovion schrieb Nachdem der sync fertig ist, system neustarten, gucken, ob beide Platten drinhängen und falls nicht, läuft offenbar was beim Start schief. Dann würde ich nochmal ein "manuelle" Konfiguration der mdadm.conf ausprobieren, ist aktuell mein Plan. Haben die UUIDs irgendwelche Vorteile gegenüber den angaben via /dev/blub?

Die UUIDs i der mdadm.conf sind AFAIK mdadm-interne Bezeichner, diese müssen/werden nicht mit den UUIDs übereinstimmen wie sie nach dem Formatieren mit einem Dateisystem entstehen. blkid kann dir das zeigen.
Wenn es um UUIDs i fstab/Bootloader statt Devicebezeichner geht: Bei mdadm ist es eigentlich immer gesichert, daß md0 auch md0 ist. Ich habe noch nie ein problem wie mit vertauschten Einzel-Platten bemerkt.
Allerdings packe ich immer die /etc/madadm.conf mit ins initrd-Image (mkinitcpio.conf->FILES), k.a. ob das aktuell noch angebracht ist. Allerdings ahbe ich im .org-Forum letzt ein paar beiträge gesehen, bei denen udev statt md0 plötzlich meinte sowas wie md012 o.ä. draus machen zu müssen. Verkehrt ist das reinpacken ins initrd wohl eher nicht.

Du solletst halt (/proc/mdstat, Logs) die nächste Zeit deine Arrays etwas beobachten.

Ovion

GerBra schrieb Oder: Kannst du sicher sein, daß nach dem Assemblen überhaupt jemals ein "richtiges" RAID1 bestand ;-)

Beim Einrichtungsboot, ansonsten denke ich nicht (stört mich gerade aber gar nicht so sehr, denn das heißt, wenn ich ein wenig Glück habe, bemerkter Konfigurationsfehler statt Hardwaredefekt).

Ich glaube mich zu erinnern, wohl versehentlich tatsächlich ">" statt ">>" beim Umleiten der Ausgabe von "mdadm --examine --scan" in die mdadm.conf benutzt zu haben. Infolge dessen habe ich auch die Originaldatei überschrieben.

Immerhin dürfte ich mittlerweile insgesamt einen Großteil der Fehler bei Linux-Raid1 durchhaben, ist auch was wert.

mdadm reinstalliert, um die originale mdadm.conf zu bekommen, allerdings behauptet er bei

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

"zsh: keine Berechtigung: /etc/mdadm.conf"

Werde die Ausgabe von mdadm mal manuell unter die neue alte mdadm.conf packen und mal sehen, was draus wird. Die Beschwerde der zsh kommt mir aber ein wenig seltsam vor, weswegen will er mir das denn verweigern? cat lässt er sogar ohne Rootrechte zu.

GerBra schrieb Du solletst halt (/proc/mdstat, Logs) die nächste Zeit deine Arrays etwas beobachten.

Werde ich definitiv tun. mdadm.conf wird bei jedem mkinitcpio-Durchlauf automatisch mit in den Kernel eingebunden (mdadm-hook, glaube ich), zumindest bei mir.

GerBra

Muß mich doch nochmal anmelden (bin schon im Nachthemd ! ;-)

Ovion schrieb mdadm reinstalliert, um die originale mdadm.conf zu bekommen, allerdings behauptet er bei
sudo mdadm --examine --scan >> /etc/mdadm.conf
"zsh: keine Berechtigung: /etc/mdadm.conf"
Werde die Ausgabe von mdadm mal manuell unter die neue alte mdadm.conf packen und mal sehen, was draus wird. Die Beschwerde der zsh kommt mir aber ein wenig seltsam vor, weswegen will er mir das denn verweigern? cat lässt er sogar ohne Rootrechte zu.

Typisches sudo Problem, was habt ihr alle gegen eine Root-Shell? ;-)
Das sudo gilt nur für mdadm --examine --scan, nicht mehr für die anschließende Dateiumleitung. Packe Anführungszeichen rund um die *beiden* Befehle, dann sollte es gehen.

Ovion

Eieiei, ich hoffe, ich habe dich nicht über Gebühr vom schlafen gehen abgehalten.

GerBra schrieb Typisches sudo Problem, was habt ihr alle gegen eine Root-Shell? ;-)

Das wäre ja ein "su-enter" mehr und man redet sich dann ein, es ist ja nur dieser eine Befehl, dafür muss ich nicht extra eine rootshell aufmachen - und beim nächsten Befehl ist der ja auch der letzte... Wie die Faulheit doch für mehr Arbeit sorgen kann. Aber die Begründung, dass "sudo mdadm --cmds" in mdadm.conf geschrieben wird, klingt ziemlich logisch. Wieder was gelernt.

Habe jetzt mal rebootet, er assembelt mir das Array sauber, sind beide Platten drin. Auch als ich "DEVICE partitions" nochmal auskommentiert (=komplette Ursprungsconfig auskommentiert) und dann rebootet habe, hat er alles sauber zusammengesetzt. Hab's jetzt nochmal deauskommentiert und werde das ganze mal im Auge behalten.
Vielleicht hängt dieser Ausfall doch damit zusammen, dass mein System gestern morgen total rumgespackt hat, vielleicht ist es aber auch nur eine Folge dessen, da bin ich noch am logs lesen. Oder tatsächlich völlig unabhängig.

Gibt's eigentlich einen Befehl, mit dem ich mdadm sagen kann, schick mir 'ne Testwarnmeldung, um zu testen, ob der Kanal funktioniert?

Auf jeden Fall nochmal allerbesten Dank für deine Hilfe!

GerBra

Ovion schrieb
GerBra schrieb Typisches sudo Problem, was habt ihr alle gegen eine Root-Shell? ;-)
Das wäre ja ein "su-enter" mehr und man redet sich dann ein, es ist ja nur dieser eine Befehl, dafür muss ich nicht extra eine rootshell aufmachen - und beim nächsten Befehl ist der ja auch der letzte... Wie die Faulheit doch für mehr Arbeit sorgen kann.

Ich nutze auch sudo - für kleine Tasks.
Für administrative Sachen (hier: das Raid re-assemblen oder ystemupdates) aber eine Rootshell (su -).
Bei eigenen Bedenken kann man sich ja einen auffälligen Rootprompt oder einen knallroten Hintergrund dafür machen, ich habe auch schon (fast) mal eine normale und root-shell verwechselt ;-)
Aber ich hätte (dieses Ubuntu-gehabe) langfristig eher "Angst" vor sudo-Nutzung als einer root-Shell <g>.
//Edit: Als root kann ich auch bedenkenlos Dateimanager wie den mc nutzen, was mir als Swiss-Knife eigentlich alles für die Arbeit als root/Admin mitbringt. Um an die originale mdadm.conf zu kommen hätte ich auch wirklich nicht mdadm neu installiert, mit einem Archivmanager deiner Wahl (oder dem mc, erwähnte ich die Genialität von mc schon?) hättest du dir die Datei auch direkt aus dem Archiv mdadm*.pkg.xz holen/anschauen können.

Ovion schrieb Gibt's eigentlich einen Befehl, mit dem ich mdadm sagen kann, schick mir 'ne Testwarnmeldung, um zu testen, ob der Kanal funktioniert?

Dafür muß auf dem Rechner ein (ggf. kleiner wie msmtp) smtp-Client eingerichtet werden. mdadm bringt da nichts "automatsich" mit sondern verläßt sich auf die existenz von sendmail (Sieht man ja an den Logmeldungen).
Im .org-Wiki gibt es sicher einen beitrag zu msmtp.
//Edit3: Wenn das dein Arbeits-PC ist, dann kannst du dir statt des Email-Aufwands u.U. auch mittels mdadm,conf->PROGRAM und notify-send o.ä. etwaige Meldungen lokal/sichtbar ausgeben lassen. Wichtig ist halt nur, daß die Benachrichtigungsmethode zu jedem Zeitpunkt (während/nach einem Bootvorgang) den aufmerksamen Amin erreichen kann.

//Edit2: Was ich schon die ganze Zeit anbringen wollte:
Bei der Forumsspartenwahl(HW+Technik) und dem Threadtitel wollte ich dich eigentlich noch/erst fragen: Aus welcher Höhe ist die Platte denn gefallen? Erdbeben? Torkelnder Admin (don't drink and root!) der seine weitausholenden Armbewegungen feinmotorisch nicht im Griff hat? ;-) SCNR <g>

Ovion

GerBra schrieb Ich nutze auch sudo - für kleine Tasks.
Für administrative Sachen (hier: das Raid re-assemblen oder ystemupdates) aber eine Rootshell (su -).

Sollte ich mir tatsächlich auch angewöhnen, statt mir jeden Befehl als kleinen Task schönzureden.
Optisch macht die zsh das schon recht gut, Bentutzernamen in dezentem blau, während der Benutzername root in der rootshell knallrot ist.

GerBra schrieb Um an die originale mdadm.conf zu kommen hätte ich auch wirklich nicht mdadm neu installiert, mit einem Archivmanager deiner Wahl (oder dem mc, erwähnte ich die Genialität von mc schon?) hättest du dir die Datei auch direkt aus dem Archiv mdadm*.pkg.xz holen/anschauen können.

Hatte ich auch erst gemacht und die Datei ersetzt, dann aber dieses Berechtigungsproblem mit dem sudo gehabt und in der Nichtannahme eines syntaktischen Rechteproblems es testweise so zu lösen versucht. Überflüssigerweise.

GerBra schrieb
Ovion schrieb Gibt's eigentlich einen Befehl, mit dem ich mdadm sagen kann, schick mir 'ne Testwarnmeldung, um zu testen, ob der Kanal funktioniert?
Dafür muß auf dem Rechner ein (ggf. kleiner wie msmtp) smtp-Client eingerichtet werden. mdadm bringt da nichts "automatsich" mit sondern verläßt sich auf die existenz von sendmail (Sieht man ja an den Logmeldungen).
Im .org-Wiki gibt es sicher einen beitrag zu msmtp.

Da werde ich mich dann mal als nächstes dransetzen.

Edit: Ein Systemupdate a la "pacman -Syu" machst du auch über 'ne root-shell?

GerBra

Ovion schrieb Edit: Ein Systemupdate a la "pacman -Syu" machst du auch über 'ne root-shell?

Ja, eigentlich schon. Am Arbeits-PC habe ich sowieso meist eine Rootshell offen, an Servern (auch mein privater) dürfen per sudo nur wenige spezielle Befehle ausgeführt werden, der User der sich remote einloggen darf kann sowieso nur /bin/su ausführen.
Ich bin es seit Jahren so gewöhnt, brauche allerdings auch keine "grafische Oberfläche" zum administrieren.

Ovion

GerBra schriebbrauche allerdings auch keine "grafische Oberfläche" zum administrieren.

Jaja. Ich gebe zu, als ich noch Windows und Ubuntu in Verwendung hatte, hätte ich nie gedacht, dass ich eine grafische Oberfläche tatsächlich mal als sogar eher hinderlich betrachten würde. Und dabei arbeite ich jetzt produktiv erst seit ca. zwei Monaten auf so einem System und schon ist das Tastaturkürzel zum Starten eines Terminals mit eines der am häufigsten gebrauchten. Schon interessant.