Meine neue Festplatte wollte ich vor der Inbetriebnahme durch einen HDD Burn-In-Test absichern. Ob man das überhaupt braucht ist in diversen Foren im Internet reichlich umstritten. Für mich selbst habe ich entschieden dass ich das machen will.
Das Argument für mich war, dass in vielen Produktbewertungen von Festplatten darüber gescholten wird, dass die Festplatte entweder schon bei der Lieferung defekt war oder innerhalb der ersten Woche ausgefallen ist. Das deckt sich auch mit dem was ich vor Jahren im Studium gehört habe. Die Ausfallkurve sieht aus wie eine Badewanne. Viel am Anfang und am Ende.
Bei Google gab es vor einigen Jahren eine Studie zu Festplattenausfällen: Failure Trends in a Large Disk Drive Population
Auch dort wurde erwähnt, dass die Festplatten in den ersten drei Monaten häufiger ausfallen. Als interessanter Nebensatz wurde auch erwähnt dass Google einen Burn-In mit neuen Platten macht. Auch der Hersteller von meinem Raid-Controller empfiehlt einen Burn-In von neuen Platten.
Damit war für mich die Sache klar. Außer ein wenig Zeit kann ich dadurch nichts verlieren. Lieber einen Burn-In als später den Ausfall zu haben während ich die Platte mit den initialen Daten befülle.
Im Netz hatte ich keine Software gefunden die einen HDD Burn-In-Test anbietet. Eventuell bringt das ja irgend ein Benchmark Tool mit, lässt sich aber auch relativ einfach selbst stricken.
Die Testspezifikation
Zuerst habe ich mir überlegt was ich eigentlich genau testen will. Das Hauptaugenmerk lege ich auf die Mechanik der Platte. Ausfälle am Controller dürften sich nur schwer provozieren lassen. Eventuell müsste ich dazu die Umgebungstemperatur anheben aber ich will die Platte nicht außerhalb der Spezifikation betreiben.
Ein erster Punkt sind sicher die Betriebsstunden an und für sich. Das lasse ich quasi „nebenbei“ erledigen indem ich die Platte beschäftigt halte. Kritisch könnten auch Kopfbewegungen sein. Daher werde ich viele Seeks verursachen.
Eventuell belastet ist auch das Anlaufen der Platte belastend. Daher will ich einige Load Cycles verursachen.
Die Tools
Ich verwende die folgenden Open Source Tools um den Test zu machen, bzw. auszuwerten:
- smartmontools
- Die smartmontools lesen S.M.A.R.T. Daten von Festplatten aus. Auch können damit Selbsttests der Festplatte gestartet werden. Das Tool funktioniert auch mit RAID Controllern beispielsweise von 3ware.
- hdparm
- hdparm erlaubt Einstellungen an den Festplatten zu machen wie den accoustic mode oder den power mode zu beeinflussen.
- Iometer
- Iometer ist ein Benchmark Werkzeug. Die Testbedingungen lassen sich relativ frei einstellen.
Load-Unloads
Um die Belastung der Festplatte die beim Anlaufen der Spindel entsteht auf eine kürzere Zeitspanne zusammenzudrücken habe ich ein Script geschrieben das über hdparm die Festplatte in den standby Modus schickt. Dabei wird auch der Spindelmotor abgeschalten, der Schreib-/Lesekopf geparkt.
Als Ziel habe ich 200 Zyklen vorgesehen die die Platte überleben muss damit ich an ein mängelfreies Produkt glaube.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@echo off SET device=sda SET runs=100 SET waittime=45 SET count=0 :loop SET /A count=%count%+1 echo TEST RUN %count% hdparm -y %device% timeout /T %waittime% hdparm -t %device% hdparm -t %device% hdparm -t %device% if %count% LSS %runs% goto loop |
Das Script verwendet die Shell von Windows, ab Vista gibt es auch einen Befehl um zu warten. Nach dem standby warte ich für 45 Sekunden damit die Platte wirklich runtergedreht hat. Durch einen Lesebefehl wecke ich die Platte wieder aus dem Standby. Das braucht typisch 15 Sekunden. Ich verwende dazu den read test von hdparm. Das mache ich insgesamt drei mal so dass etwa ein Gigabyte gelesen wurde. Dann fängt die Schleife von vorne an.
Der Lasttest
Mit Iometer habe ich ein Zugriffsprofil eingestellt das die Platte stressen sollte. Ich verwende vier Threads die gleichzeitig arbeiten. Jeweils einmal wird sequenziell 10MB gelesen oder geschrieben. Zwei weitere Threads schreiben/lesen zufällige 64k Blöcke von der Platte.
Das führt dazu dass der Kopf die ganze Zeit in Bewegung ist und auch die Elektronik unter Strom steht.
Den Test lasse ich 100 Stunden laufen. Da die Platte für den Dauerbetrieb spezifiziert ist sollte sie das anstandslos verkraften.
Das Fazit
Ich verwende die Hitachi Ultrastar 7K3000 und habe vor dadurch meine alten Consumer Seagate-Platten zu ersetzten da ich denen nicht wirklich vertraue.
Mit einer Consumer-Platte sollte man bei den Tests vielleicht etwas vorsichtiger sein. Von der Ultrastar erwarte ich aber keine Probleme. Neben einer Freigabe für den Dauereinsatz hat die Platte noch als interessantes Merkmal eine Bitfehlerrate von 10-15. Das ist zehn Mal besser als typische Consumerplatten.
Die Festplatte hat den Burn-In überstanden und funktioniert noch. Bleibt zu hoffen dass die Platte weiterhin zuverlässig läuft.
Dein Artikel hat mich dazu inspiriert, die Funktionalität des Skripts mal nach Linux zu portieren.
http://forum.ubuntuusers.de/topic/stresstest-burn-in-test-fuer-festplatten/
Viel Spaß damit.
Hey, guter Artikel. Bin hier gelandet weil ich exakt die gleiche Idee habe bzw. jetzt ja er wohl hatte. Bei normalen Festplatten sollte man diese Tests auf keinen Fall machen, auch nicht bei Platten die nur für den Dauerbetrieb zertifiziert sind, Dauerlast können nur spezielle Platten wie z.B. SAS-Laufwerke aushalten. Ich habe jetzt einen 300 Stunden-Test bei meinen neuen WD Velis gemacht, die halten das ohne Probleme aus.