datenritter blog

Das hier kann ich nicht zur Nachahmung empfehlen. Die Oberflächen der Festplattenscheiben (Platters), sind mit Chrom- und Kobalt-Verbindungen beschichtet, und die möchte man lieber nicht in Staub umwandeln und einatmen. Außerdem bestehen die Scheiben zwar meist aus Aluminium, manchmal aber auch aus Glas. Wenn so eine zerspringt, könnte das bei den hohen Drehzahlen üble Konsequenzen haben.

Eine 5.25" breite Quantum Bigfoot mit einer Kapazität von 4GB musste für dieses Experiment sterben:



Das Video stammt wohl von Thomas Pfeifer.

Hier haben wir mal wieder einen Fall von "hätte ich ein Backup..." Der arme Mann fragt nun per Blog und Twitter, was er tun soll:

Mindestens ein Mal im Jahr zerschießt es meinen Windows XP Rechner. Genauer gesagt ist und war es meist die Festplatte, die aus einem mir nicht nachvollziehbarem Grund ihren Geist aufgibt und mir nun jede Menge Daten, als auch nicht extern gesicherte Fotos vorenthält. Ein persönliches Drama sozusagen an dem ich natürlich selbst dran Schuld bin. Daten zu sichern war bisher nicht meine Stärke ,(

Kein Backup, und Windows macht das regelmäßig. Was soll man dazu noch sagen?

TOLD YOU SO!

Vor einiger Zeit bekam fand ich nach dem Anschließen einer USB-Festplatte den Fehler "Buffer I/O error on device" im Syslog. Eine Websuche förderte diesen bemerkenswert halbwahren Beitrag hervor:

Ein Festplattencrash unter Linux sieht im Log i.d.R. folgendermaßen aus

Unter einem Crash versteht man dann doch etwas anderes als einen Ein-/Ausgabefehler. Der Fehler ist harmlos und tritt bei bestimmten Chipsätzen, welche offenbar überwiegend in USB-Adaptern verbaut werden, auf und wird seit Kernel-Version 2.6.20 korrekt behandelt.

In oben verlinktem Beitrag geht es dann mit einem schlauen Tipp weiter:

Das bedeutet i.d.R. nichts gutes und es hilft meist nur eines: Server herunterfahren und wenn möglich, ein Festplatten Testtool durchlaufen lassen, um den Fehler genauer zu lokalisieren und die HDD ggf. nochmal fit zu kriegen. Sollte dies gelingen, schleunigst ein Backup der Daten machen und die Harddisk anschließend austauschen.

Das ist gleich auf mehrere Arten falsch. Sollte der Fehler im laufenden Betrieb plötzlich auftreten, dann ist Datenverlust zu befürchten, und man macht natürlich sofort ein Backup. Ausschalten sollte man den Rechner auf gar keinen Fall, da es Festplattendefekte gibt, die erneutes Anlaufen des Motors verhindern. Die Platte mittels irgendeines "Tools" wieder flottzukriegen hätte ich ebenfalls keine Hoffnung.

Der einzige mir bekannte Fall, in dem Software mehr tun konnte, als nur das baldige Ableben der Festplatte zu prophezeien, ist ein Firmware-Fehler, wie er vor einiger Zeit bei einigen Seagate-Modellen auftrat. Sehr lästig und gefährlich, wenn man ein RAID aus genau diesen Festplatten betreibt.

Das Dateisystem ReiserFS wird nicht mehr gepflegt, zumindest nicht in Version 3. Das ist bedauerlich, denn ReiserFS kann viele kleine Dateien platzsparend speichern und hat auch sonst ein paar Vorzüge. Allerdings scheint es einen ernsthaften Bug zu geben.

Wie hier beschrieben, habe ich versucht, die Änderungszeitstempel von einigen hunderttausend Dateien zu setzen.

Das Problem: Mit dem Kernel 2.6.26-xen-686 (Debian) gibt es nach etwa 1000 bis 7000 Änderungen auf einem ReiserFS (auf einem Raid5) einen plötzlichen Reset. Das ist nicht das, was man normalerweise von Linux erwartet. Nun muss ich wohl auch von ReiserFS abraten.

Mit dem Kernel 2.6.22-3-k7 und ext3 ging das ganze problemlos, aber die Dateisystemumstellung machte natürlich eine weitere Umkopieraktion nötig.

Die letzten zwei Stunden lief Chaosradio 144 "Datenträger, Datenverlust und Datenrettung — Vom magnetischen Flußwechsel zum Dokument".

Es ging um Festplattenfehler ebenso wie Anwenderfehler, um die Methoden zur Rettung der Daten, um RAID-Systeme und sogar um das zuverlässige Löschen alter Daten. Und der häufigste Tipp war: Habt ein Backup!

Bei Datenrettungen, dem Erstellen von Dateisystemen für virtuelle Maschinen oder forensischen Maßnahmen entstehen Festplattenimages, welche nicht direkt ein Dateisystem, sondern eine eigene Partitionstabelle enthalten. Diese lassen sich mit losetup "loopmounten":

losetup /dev/loop1 image.dd

Doch bekanntlich hat man dann zumindest unter Debian Linux ein Problem, da für die Partitionen innerhalb des Image-Files keine Device-Nodes in /dev/ angelegt werden.

Überall im Netz findet man Anleitungen, wie man aus der mit fdisk -ul /dev/loop1 ausgegebenen Partitionstabelle des Files Offsets berechnet, welche mount als Option übergeben werden können. Unter anderem hier und hier. Das ist, sagen wir mal, etwas umständlich.

Theoretisch kann man das Problem auch mit dem Device Mapper lösen. Laut Manpage muss man dmsetup dazu "nur" eine Partitionstabelle übergeben, die Devices erscheinen dann unter /dev/mapper/. Mir ist das selbst mit einer von dmsetup selbst ausgegebenen Tabelle nicht gelungen.

Deswegen überlässt man diese Aufgabe einfach einem Programm, nämlich kpartx:

kpartx -a /dev/loop1

legt Devices für die im loopback-gemounteten File enthaltenen Partitionen an. Danach funktioniert sowas dann auch unter Debian:

mount /dev/mapper/loop1p1 /mnt

Robin Harris schrieb 2007 in einem Artikel bei ZDNet, dass RAID5-Systeme seiner Ansicht nach im Laufe dieses Jahres aufhören werden zu funktionieren, bzw. dass und RAID6-Systeme keine größere Sicherheit als RAID5-Systeme geben werden.

Was ist dran an der Behauptung?

Die Zahlenspielereien, die er anstellt, basieren auf der Annahme, dass die durchschnittlichen Lesefehlerraten gleich bleiben, während die Kapazitäten der Laufwerke sich immer weiter erhöhen. Dadurch steigt die Gefahr eines zweiten — fatalen — Fehlers nach dem Ausfall einer Festplatte im RAID5-Verbund. Denn nach so einem Ausfall wird das Reservelaufwerk (Spare Drive) aktiviert, und vollständig beschrieben, um den Verbund wieder zu vervollständigen.

Während dieser Wiederherstellung (Recovery) der vollen Redundanz werden die anderen Laufwerke komplett gelesen. Bei gleichbleibenden Raten von einem unbehebbaren Fehler auf etwa zwölf Terabyte Daten hat man also bereits mit sechs 2TB Laufwerken — und solche wird es im Laufe dieses Jahres geben — ein reale Chance, dass ein solcher Fehler auftritt. Der zweite Lesefehler kann seiner Ansicht nach aber das gesamte RAID5-System ruinieren.

Kurz: Die zur Rekonstruktion des RAID-Verbundes zu lesende Datenmenge steigt gegenüber der Lesefehlerrate.

Nun ist es so, dass mittlere Fehlerraten und ähnliche Kennzahlen gerne missverstanden werden. Doch ist es ohne tief in die Materie einzusteigen und eine anständige Portion Stochastik nahezu unmöglich, die Qualität von Harris' Voraussagen zu bewerten. Deswegen sollte man einen Blick auf weitere Meinungen werfen.

Am Rande erwähnt sei ein Artikel in einem Mitarbeiter-Blog von SUN Microsystems. Hier wurden verschiedene mathematische Modelle verglichen und Berechnungen für RAID-Z2 angestellt, ein Raidsystem, welches mit dem Dateisytem ZFS verbandelt ist und höhere Sicherheit vor Inkonsistenzen bei Scheibfehlern bietet. Das ist auch bei RAID-Systemen ein nicht zu vernachlässigender Punkt, denn Schreibfehler sind möglich und das wird meist nicht berücksichtigt. Der Artikel geht etwas sehr ins Detail, bestätigt Harris' Vorhersage aber zumindest teilweise.

Ein lesenswerter Artikel im Blog von subnetmask255x4 betrachtet viele Äußerungen zum Thema eher kritisch und beruhigt in sofern, dass er die Fehlerraten schneller sinken sieht, als die Kapazitäten der Laufwerke sich erhöhen. Die Annahme, dass die Fehlerraten gleichbleiben, scheint also der Haken an Harris' Prophezeiung zu sein.

Allerdings empfiehlt der Autor, lieber RAID6 statt RAID5 zu nutzen, bzw. RAID10 für den Hausgebrauch. Zudem soll man gezielt spezielle Festplatten mit geringerer Fehlerquote kaufen und natürlich Backups anlegen.

Die sind eine gute Idee, denn im Gegensatz zu RAID-Systemen schützen sie vor Dummheiten und Rechenfehlern.

Nachtrag 2009-02-28: Grundsätzlich sollte man auch bedenken, dass auch RAID5 und RAID6-Systeme nicht vor Bedienfehlern geschützt sind. Wird statt der ausgefallenen Platte vom "Bedienpersonal" versehentlich eine andere Platte entfernt, so wird das Dateisystem möglicherweise schwer beschädigt. Der RAID-Controller bzw. der Daemon gibt dann sofort auf, und überredet man ihn, den Verbund trotz der entstandenen Inkosistenz wieder in Betrieb zu nehmen, kann sonstwas passieren. Eine möglichkeit, ein Laufwerk als "half failed" zu markieren, kenne ich jedenfalls nicht.

Ein Freak namens Ian Matthew Smith hat eine Festplatte so umgebaut, dass er sie zum Beispiel als Uhr verwenden kann. Die Scheibe der Platte wurde geschlitzt, ein Hall-Sensor registriert , wenn die Platte in einem bestimmten Winkel steht, und ein PIC-Mikrocontroller schaltet zum richtigen Zeitpunkt LEDs an, aus bzw. auf die richtige Farbe.

Das Ergebnis sieht dann so aus:


Hier die Projektseite mit Details: HD-Clock. Gefunden bei fefe.

Die Konstruktion ist zu laut für eine Uhr und verbraucht zu viel Energie. Trotzdem cool.

Van Halen: