Original-URL des Artikels: https://www.golem.de/news/linux-fehler-im-kernel-zerstoert-raid-arrays-1206-92613.html    Veröffentlicht: 19.06.2012 11:59    Kurz-URL: https://glm.io/92613

Linux

Fehler im Kernel zerstört Raid-Arrays

Ein Fehler im Raid-Stack des Linux-Kernels kann die Metadaten so beschädigen, dass Daten nach einem Neustart nur schwer zugänglich sind. Der Fehler betrifft zahlreiche Kernelversionen, ist aber inzwischen behoben.

Durch einen Fehler können Metadaten auf Raid-Arrays des Linux-Kernels beschädigt werden. Die Daten selbst gehen dabei nicht verloren, wohl aber Informationen zum Raid-Array selbst, etwa dessen Blockgröße oder die Anzahl der dazugehörigen Geräte. Der Fehler tritt nur nach einem Neustart auf, wenn ein Raid-Array erneut zusammengestellt (Assemble), danach aber nicht erneut initialisiert wird, schreibt Entwickler Neil Brown.

Das kann etwa passieren, wenn der Befehl "mdadm --incremental" auf einigen einem Raid zugehörigen Geräten ausgeführt wird, aber nicht auf allen. Brown nennt als Fehlerquelle auch den Befehl "mdadm -A", bei dem ein Raid zusammengestellt wird, aber nicht alle Geräte per Parameter definiert wurden, die dem Array zugeordnet sind. Auch hier startet das Administrationswerkzeug Mdadm das Array nicht.

Erst einprogrammiert, dann behoben

Der Bug tritt in den Kernelversionen 3.3.1 bis 3.3.3, 3.2.14 bis 3.2.16 und in der Vorabversion 3.4-rc1 und v3.4-rc5 des aktuellen Kernels 3.4 auf. In der finalen Version 3.4 sowie in Linux 3.3.4 und 3.2.17 sei der Fehler behoben, schreibt Brown. In Suse Linux Enterprise Server 11 (SLES11) mit Service Pack 2 tritt der Bug in Kernel 3.0.26-0.7 auf und wurde in 3.0.31-0.9 repariert. In Ubuntus Linux-Kernel-3.2.0-22.35 wurde der Fehler einprogrammiert und in Ubuntu-3.2.0-24.38 wieder behoben.

Vorsorge

Mit dem Befehl mdadm -Evvvvs lassen sich zunächst die wichtigsten Informationen eines Raid-Arrays auslesen und sichern.

Bei einem Upgrade auf einen neuen Kernel und vor dem anschließend notwendigen Neustart sollte zunächst sichergestellt werden, dass alle Raid-Arrays vollständig assembliert und neu initialisiert wurden. Dabei empfiehlt Brown, zunächst mit mv /sbin/mdadm /sbin/mdadm.moved das Raid-Werkzeug umzubenennen, damit ein möglicher distributionseigener Automatismus den Fehler nicht noch auslösen kann.

Unter Ubuntu wird beispielsweise eine inkrementelle Zusammenstellung (incremental assembly) bei einem Start auf allen Raid-Arrays durchgeführt, was den Fehler auslösen kann. Die entsprechenden Befehle sind in der Konfigurationsdatei 85-mdadm.rules festgelegt.

Danach sollte der Befehl /sbin/mdadm.moved --stop -scan ausgeführt werden.

Vor einem Neustart mit repariertem Kernel muss im Rescue-Modus mit mv /sbin/mdadm.moved /sbin/mdadm das Administrationswerkzeug zurückkopiert werden. Dieser Workaround sei etwas fummelig, schreibt Brown, es sei aber der sicherste ihm bekannte.

Brown beschreibt in seinem Blogeintrag auch die technischen Hintergründe des Fehlers sowie mögliche Maßnahmen für den Fall, dass der Fehler bereits eingetreten ist.  (jt)


Verwandte Artikel:
Stratis: Red Hat arbeitet an eigener Datenträgerverwaltung für XFS   
(03.08.2017, https://glm.io/129280 )
Google: Chromebooks bekommen "Linux-VMs" und "Terminal"   
(27.02.2018, https://glm.io/133030 )
Bpfilter: Linux-Kernel könnte weitere Firewall-Technik bekommen   
(22.02.2018, https://glm.io/132933 )
Systemanalyse: Wie Dtrace auf Linux kommen könnte   
(15.02.2018, https://glm.io/132799 )
Freedreno: Google will Mainline-Linux-Support für Snapdragon 845   
(14.02.2018, https://glm.io/132774 )

© 1997–2019 Golem.de, https://www.golem.de/