Lesefehler auf Western Digital WD20EARS
Zur Abwechslung mal wieder was aus dem Reich der Informatik.
Im Mai 2010 hatte ich beschrieben, wie ich meine ersten 2TB-Festplatten unter Linux verwendet habe. Damals hatte ich 2 Platten WD20EARS gekauft.
Manche Leute hatten mich vor diesen Platten gewarnt. Ein Problem bei diesen (und andere Western Digital-Platten) ist, dass sie ab Werk eine sehr kurze Einstellung der Idle-Zeit haben. Ich bin mir jetzt nicht ganz sicher, aber ich glaube, die steht nur auf 5 Sekunden oder etwas in dieser Größenordnung. Damit laufen die prima unter Windows, aber unter Linux gibt es ein Problem. Denn weil sich Linux anders gegenüber Festplatten verhält und anders puffert, kommt es häufig dazu, dass die Platte für gewisse Zeit gar nicht mehr angesprochen wird, oft länger als diese 5 Sekunden, und dann fahren die WD-Platten in einen Ruhezustand (bin mir nicht ganz sicher, was genau, anscheinend fährt zumindest der Kopf in eine Ruheposition, ich weiß aber nicht, ob sie auch langsamer drehen) und fahren dann wieder an. Das kann man dann daran sehen, dass der Load Cycle Counter (unter Linux anzuzeigen mit smartctl) schon nach wenigen Tagen auf mehreren Tausend steht. Da der Hersteller aber nur irgendwas in der Größenordnung von 200.000 oder 300.000 Cycles garantiert, ist man ruckzuck außerhalb des spezifizierten Bereichs und hat seine Garantie schon nach ein paar Wochen verloren, weil der Cycle-Counter das Limit überschritten hat. Ein Schelm, wer sich was dabei denkt.
Man muss also mühsam und anachronistisch noch ein uraltes DOS anbooten (DRDOS, Freedos oder eben noch ein MSDOS), um dann mit einem auch schon vier Jahre alten Tool namens wdidle.exe den Idle-Counter zu verstellen, entweder auf 300 Sekunden oder ganz abschalten. Dann zählt der Zähler nur noch beim Einschalten bzw. Booten des Linux einen hoch und dann ist Ruhe. Wie man das bewerkstelligt, wenn die Platte nicht an einem x86-Prozessor, sondern etwa an einem ARM-Prozessor oder irgendeinem Embedded Device mit Linux hängt, dazu sagt WD erst gar nichts. Inzwischen gibt es ein Open-Source-Projekt dazu, weil Western Digital selbst nicht willens oder in der Lage ist, das Problem ordentlich zu lösen.
Es wird den Leser erstaunen, aber inzwischen hatte ich 6 von diesen Festplatten. Zwei habe ich noch freiwillig für meinen Server gekauft, weil ich bis dahin keine Probleme mit den Platten hatte, und zwei habe ich mit einem NAS gekauft. Ich brauchte mal kurzfristig dringend ein NAS, um was auszulagern, und habe mir damals im Sonderangebot schnell das billigste gekauft, ein Buffalo. Die werden mit Festplatten verkauft, man weiß aber nicht, von welchem Hersteller. Da waren auch zwei WD20EARS drin.
Problematisch bei der Auswahl ist eben, dass es kaum noch Hersteller gibt. Effektiv sind da nur noch zwei oder drei unterwegs. Viel mehr als WD, Seagate oder Fujitsu ist da nicht mehr. Und von Fujitsu habe ich in letzter Zeit auch nur noch 2,5-Zoll-Platten gesehen. Und dann kam noch die Festplattenkrise wegen des Hochwassers (angeblich), wo man sowieso nehmen musste, was zu kriegen war. Das NAS hatte ich gerade ein paar Tage vor dem Hochwasser billig gekauft. Eine Woche später sind die Preise schon explodiert. Dabei ist mir damals übrigens auch aufgefallen, dass bei den Platten, die Buffalo einsetzt, dieser Timer auch nicht hochgesetzt worden war. Weil aber auch in Buffalo-NAS-Geräten ein Linux läuft, tritt genau derselbe Fehler auf, die Cycle-Counter gehen hoch wie Hölle. Ich habe versucht, Buffalo darauf hinzuweisen, aber die (bzw. deren Kundenservice) hat nicht mal ansatzweise begriffen, was ich von ihnen will, und mich nur mit Lehrbuch-Antworten abgespeist. Wenn sie’s nicht kapieren, muss man halt Festplatten auf Garantie austauschen lassen.
Schon kurze Zeit nach dem Kauf hat sich das NAS nachdrücklich per E-Mail bei mir beschwert, dass eine Festplatte massig Lesefehler hätte. Nach viel hin- und her hat mir Buffalo dann die Platte ausgetauscht und stattdessen eine Seagate geschickt. Das war gerade in der Krisenzeit, da hat die die Platte wahrscheinlich mehr gekostet als ich für das ganze NAS mit zwei Platten gezahlt hatte. Sowas ist aber notwendig, weil es nur so das nötige Feedback auf die Qualität gibt.
Nun hatte ich gerade das Problem, dass bei meinem Rechner (der, zu dem ich 2010 den Blog-Artikel geschrieben habe) der Plattenplatz nicht mehr reichte. Zwei Platten als RAID geschaltet, macht 2 TB Plattenplatz. Aber mein Bestand an Videos und Fotos wächst eben zusehends, und bei Videos und RAW-Fotos bis zu 40 MByte pro Foto läppert sich das eben.
Eigentlich hatte ich nur vor, im PC eine der beiden WD20EARS durch eine 4TB-Platte zu ersetzen, um dann 2TB weiter als RAID und die überschießenden 2TB nur auf einer Platte zu halten, für temporäre Dateien oder solche, die ich ohnehin mehrfach gespiegelt habe, wo es kein Problem ist, wenn mal eine Platte abnudelt. Die dabei freiwerdende Platte wollte ich in den Server stecken, um aus dem alten RAID1 mit 2 WD20EARS ein RAID5 mit 3 WDEARS zu machen, damit also auch dort den Plattenplatz von 2 auf 4 TB zu heben.
Jo, Mist war’s. Beide der 2010 gekauften Platten haben inzwischen reproduzierbar matschige Sektoren, die nicht mehr lesbar sind. Ein mit smartctl angeworfener langer Selbsttest listet die Fehler, und smartctl zeigt an, dass der Zähler für Current Pending Sector bei einer auf 9 und bei der anderen Platte auf 1456 steht. Current Pending Sectors sind die Sektoren, die die Platte gerade nicht mehr lesen kann, und die sie beim nächsten Schreibzugriff durch Reserve-Sektoren ersetzen würde. Man kommt dadurch in einen Effekt, den ich schon vor über 20 Jahren als Unix-Admin an der Uni beobachtet habe: Die Platte meldet Fehler und geht nicht mehr, aber wenn man sie neu formatiert und frisch beschreibt, geht sie plötzlich wieder anscheinend fehlerfrei. Weil die kaputten Sektoren aus den Reservespuren ersetzt werden. Erfahrungsgemäß halten diese Platten dann aber auch nicht mehr lange. Man kann sie schon noch verwenden, aber nicht mehr für wichtige Sachen oder eben als RAID.
Ärgerlicherweise hat mir der smart-Dämon bisher auch nichts von den Fehlern berichtet, anscheinend haben die zwischendurch mal was an der Konfigurationsdatei geändert. Die Lesefehler sind nie aufgefallen, weil ich vielleicht entweder gar nicht auf diese Sektoren zugegriffen habe (Ein paar Gig waren ja noch frei, die Platte nicht komplett voll), da alte Dateien lagen, die ich nicht mehr angefasst habe, oder es einfach zufällig über das RAID immer so lief, dass die jeweils andere Platte abgefragt wurde. Jedenfalls haben beide Platten jetzt matschige Sektoren. Aufgefallen ist es erst, als ich zum Zweck des Umkopierens eine Platte hart rausgezogen habe, um noch eine Kopie zu haben, falls ich einen Fehler mache, und die andere Platte verwendet habe, um auf die neue Platte umzukopieren. Die anderen beiden Platten im Server funktionieren dagegen einwandfrei, sie bestehen den Selbsttest und die Fehler- und Pending-Zähler sind auf Null.
Das heißt, dass von 6 Platten mindestens 3 inzwischen Fehler produziert haben. Davon eine kurz nach dem Kauf, die anderen jetzt nach fast 4 Jahren. Zwei Platten sind in Ordnung, von der sechsten, die noch im NAS steckt, weiß ich es nicht, weil ich da nicht so leicht drankomme und das NAS auch kein smartctl hat.
Ob das in Ordnung ist, wenn eine Platte 4 Jahre hält, oder dann einfach die Lebenszeit abgelaufen ist, kann man nun diskutieren.
Man kann sogar diskutieren, ob die beiden Platten überhaupt kaputt sind. Denn gerade für die preisgünstigeren Home-Bereiche haben die Festplatten spezifizierte Fehler-Quoten, die nicht mehr im Verhältnis zur Größe stehen. Zwar erreicht man häufig nicht die MTBF, also die Zeit bis zum Verschleiß-Ausfall der Platte, aber in Bezug auf die Zahl der Daten und die Zahl der Schreib-Lese-Zugriffe und die angegebenen Fehlerquoten ist das nun gar nicht mehr so unwahrscheinlich, dass man einfach statistisch in Schreib-Lese-Fehler läuft. Denn diese großen Datenmengen werden auch darüber erreicht, dass sie an der Redundanz zur Fehlerkorrektur und so weiter sparen müssen, um mehr Sektoren auf eine Spur zu quetschen. Irgendwann sind die Lesefehler dann eben nicht mehr korrigierbar und die Platte meldet den Sektor als nicht lesbar.
Welche Konsequenzen zieht man nun daraus?
- Weiterhin fleißig Backups machen
- Platten in der Größe mit wichtigen Daten muss man als RAID fahren.
- Ich muss mir mal meine smartctl-Konfiguration ansehen, damit die künftig auch die Pending Sectors zählt.
- Ich werde mir wieder (ich hatte es früher mal, aber irgendwie dann vergessen einzurichten) einen Cron-Job einrichten, der etwa einmal im Monat einen vollen Plattentest fährt. Kann man mit anacron gut machen. Bei meinem anderen NAS, einem Synology, kann man das übrigens über die GUI konfigurieren, die leiert jeden Sonntag morgen die Platten einmal durch.
- Prüfsummen sind notwendig. Ich habe angefangen, auf Dateiebene Prüfsummen über alle Dateien zu erzeugen und in eine Datei zu schreiben. Damit kann man auch bei umkopierten Dateien per checksum prüfen, ob die noch stimmen, und auf diesem Weg alle Daten einmal lesen.
- Man muss mordernere Dateisysteme auswählen. Ext2/3/4 bemerken Fehler nicht mehr, wenn die Festplatte sie nicht selbst erkennt. Auch ein RAID erkennt Fehler nur, wenn die Platte Lesefehler meldet. Ob die Daten stimmen, wenn die Platte welche liefert, merken sie nicht. Für solche Datenbestände braucht man dann Dateisysteme wie ZFS oder BTRFS, die zwar langsam sind, aber für die Inhalte Prüfsummen erzeugen und das melden, wenn Daten fehlerhaft sind.
- Was bin ich froh, dass ich meine Daten nie auf nur ein oder zwei Platten und nie auf nur einem Rechner habe. Dabei bleibe ich.
- Die Konsequenz ist auch: Billig geht’s nicht. Zwar werden die Platten immer größer und billiger, man bekommt inzwischen 2TB-Platten schon ab etwa 75 Euro. Neulich habe ich eine 2TB-2,50-Zoll-Platte für etwas über 100 Euro gekauft, im Blödmarkt haben sie jetzt eine ähnliche für 99 Euro. Gleichzeitig steigt mit den enormen Datenmengen aber auch die Wahrscheinlichkeit, statistisch in die Lesefehler zu laufen, die die inzwischen dünnere Fehlerkorrektur nicht mehr korrigieren kann. Das muss man dann ausgleichen, indem man einfach mehr Platten verwendet und auf der Ebene mehr Redundanz erzeugt. Redundanz kostet Geld.
- Ich werde alle matschigen Platten ersetzen. Sie aber dann nicht wegwerfen, sondern erstmal testen, ob sie durch Überschreiben die Lesefehler noch durch Ersatzsektoren ausgleichen können. Wenn ja, kommen die alle in einen unbenutzten PC und bilden dort ein Riesen-Schrott-NAS, was dann als zusätzliche Sicherheitskopie eingesetzt werden kann. Jede zusätzliche Redundanz hilft.
65 Kommentare (RSS-Feed)
> Worauf bezieht sich denn deine Aussage, dass ZFS bzw. BTRFS langsam sind?
Darauf, dass das Erstellen und Prüfen von Prüfsummen zwar angenehm und vorteilhaft ist, aber eben Rechenzeit kostet.
Jetzt mal im Ernst. Sie sind doch Informatiker oder?
Ich lese hier nur Western Digital Green ober billigst schrott, gepaart mit einen NAS womöglich auch noch im RAID (lol? TLER?!) und dann als Sahnehäupchen auch noch der drittklassigste aller NAS Hersteller “Buffallo” – Ein Name der eigentlich jedem ITler eiskalt den Rücken runter laufen sollte!
….und ganz viel Jammer Jammer Jammer!
Schon villeicht mal dran gedacht das Sie sich viel, vorallem viel Jammertext hier erspart hätten, wenn sie nicht nach dem gängigen Mediamarkt (Sie haben nicht auch noch dort gekauft?!) Motto gehandelt hätten und “billig-billigst-Schrott ist gerade gut genug + Mein Leben, Meine Daten, Ich bin so unwichtig, Datensicherheit ist alles egal! Scheiß auf meine Hardware! Hauptsache mal wieder was konsumiert und mit billig konsumiert sichs einfach öfters!”
Darf ich Ihnen und jedem anderen mal einen Tipp geben:
Western Digital – Red (für NAS)
http://geizhals.de/?cat=hde7s&asuch=red&bpmax=&v=e&plz=&dist=&filter=aktualisieren&bl1_id=30&sort=t&xf=3772_3.5
Hitachi Deskstar (für Performance – im NAS)
http://geizhals.de/hgst-deskstar-7k4000-4tb-hds724040ale640-h3ik40003272sw-a682487.html
Synologie NAS (unter Hilfe findet jeder Noob seinen Liebling)
http://www.synology.com/de-de/
Mein persönlicher Favorit momentan (solange Synologie noch keine CPUs mit AES-NI rausbringt) ist das NAS hier:
http://geizhals.at/qnap-turbo-station-ts-470-pro-a1040198.html
o 2x RAID1 möglich
o Verschlüsselungsperformance/Beschleunigung (AES-NI)
o Endlich 10 Gbit LAN!!! (bitte Keine comments von Mediamarktkunden. Danke.)
o Mit 20W Idle extrem stromsparend
o Extrem preiswert hierfür*
* Zumal es sowieso egal ist weil es druch den Strompreis sich komplett armortisiert binnen kürzester Zeit. Könnte auch 2000 Euro kosten. 😉
@Emila: Dummschwätzer!
2010 gab es nicht viel Auswahl bei 2TB-Platten. Die WD Red gab es damals noch gar nicht. Inzwischen habe ich auch WD Red, aber noch keine längeren Erfahrungen damit.
Ein Buffalo NAS ist das einzige, was man kurzfristig an einem Mittwoch Abend nach 21 Uhr vor Ort noch kaufen kann, und das bei Metro. Alles andere muss man bestellen. Dass ich ein Synology habe, steht im Artikel.
Außerdem hat das Buffalo seinen Zweck erfüllt und war drastisch billiger als ein mindestens gleich ausgestattetes Synology. Informatiker schmeißen Geld nicht raus, sondern kaufen das, was das Problem löst.
Mir geht solche Pseudo-Schlaumeierei auf die Nerven. Vor allem, wenn es so billig und dahergeschwätzt ist.
@ Hadmut
Der Rechenzeitaufwand ist in der Praxis völlig irrelevant. SMBd und NFSd fressen ein Vielfaches der Rechenzeit, die für die Prüfsummenberechnung draufgeht. Selbst ein ~1Ghz Celeron der letzten Generation braucht gerade mal ein paar einzelne Prozent eines Kerns für den Kram – wenn die Platten glühen. (Natürlich hängt es auch vom gewählten Algorithmus für die Checksummen ab.)
> SMBd und NFSd fressen ein Vielfaches der Rechenzeit,
Deshalb verwende ich sowas ja nicht, sondern lokale Platten. BTW: Manche Software, wie etwa Adobe Lightroom, verweigert die Arbeit an Daten, die übers Netz geholt werden, und will lokale Daten.
Ich muss da jetzt mal blöd fragen (komme zwar auch aus der IT-Welt und hab auch Hardware-Knowhow, aber steck da jetzt nicht so tief drin):
Ich mach gewohnheitsmässig in den Energiespareinstellungen des Betriebssystems die Idle-Time ganz aus, weil ich nicht will dass da ständig angehalten und neu-angefahren wird (verschleisst ja nur die Mechanik und das bisschen Strom-Mehrverbrauch ist mir egal).
Und dann geht meine WD trotzdem in den Idle-Modus, oder wie?
Mich nervt ja schon dass ich jedesmal wenn ich auf’s Klo gehe (Rechner steht im Flur) sehen muss wie die HDD-LED alle paar Sekunden aufblitzt obwohl der PC nix macht. Ich denk dann immer dass das irgendwelcher Index-Caching-Blödsinn seit Win7 ist, den man nicht wirklich abstellen kann und den es unter XP noch nicht gab.
Und dann muss ich dafür womöglich sogar noch dankbar sein weil dadurch diese 5 Sekunden HD-Idle-Time nicht erreicht werden?
@Fred: Welches Betriebssystem meinst Du?
Aber soweit ich weiß, steuert kein Betriebssystem die Idle-Werte der WD-Platten. Das hat miteinander wenig zu tun. Vermutlich ist es so, wie Du schreibst, dass durch ständige Windows-Zugriffe die 5 Sekunden im Normalbetrieb nicht erreicht werden und die Platte sich erst schlafen legt, wenn das Betriebssystem gerade nichts mehr will. Bei Linux stimmt das dann so dann nicht.
Hadmut, schau dir mal ein HDD-Datenblatt an (z.B. das von deiner), Punkt “Non-recoverable read errors per bits read” o.ä.. Inzwischen sind da meist weniger als einer pro 10^14 spezifiziert, auch bei den Extra-€ WD Red. Enterpriseplatten ein oder zwei Größenordnungen mehr. Nehmen wir gütigerweise an, dass das Userdaten und nicht Rohbits inkl. Codierung sind, und dass der Hersteller das nicht nur heuchelt, sondern tatsächlich so umsetzt. Ab wann würdest du Abstand von einem RAID1 (ganz normal mit zwei Platten) oder RAID5 nehmen, weil du erwarten müsstest, dass der Rebuild nach einem Plattenfehler durch einen weiteren Plattenfehler des verbliebenen Laufwerks unsanft und vorzeitig endet?
Stichwort Prüfsummen pro Datei: Macht mein ZFS für mich, auch für alle relevanten Teile des Dateisystems. Wenn doch bloß der Laden von Larry nicht so eine lizenzrechtliche Pest wäre…
@Bzzz: Genau das meine ich ja. Ich hatte das Datenblatt nur jetzt nicht zur Hand. 1014 ist nicht so wahnsinnig viel, seit wir TB-Platten haben. 1014 entspricht etwa 246. Eine Platte mit 4TB hat aber schon 245 Bit.
Das heißt, dass es faktisch gar nicht mehr möglich ist, Daten auf so einer Festplatte korrekt zu speichern. Es ist sogar so gut wie ausgeschlossen. Denn was würde nicht etwa heißen, dass bei jeder vierten 2TB-Platte ein Fehler auftreten würde, sondern man muss für jedes einzelne Bit diese Wahrscheinlichkeit berechnen und multiplizieren. Und damit kommt man aus den Fehlern praktisch gar nicht mehr raus.
@ Hadmut
Mir ging es um die Aussage, dass die Dateisysteme langsam seien, nicht um irgendwelche Anwendungen, die damit nichts zu tun haben. SMB und NFS sind als Größenvergleich gedacht, weil das selbst schwachbrüstige NAS-Systeme noch hinbekommen – obwohl es zigfach mehr Rechenzeit frisst.
Und wenn Du “lokalen” Speicher willst, nimm iSCSI. Für Lightroom sind aber wahrscheinlich die rund 110MB\s zu wenig, die Gigabit in der Praxis bietet.
Für normale Computer mit lokalen Platten, an denen man mit Photoshop arbeiten wollen würde, ist Rechenzeit gleich zwei Mal kein Argument.
Ja, die Backup-Problematik ist selbst im privaten Bereich ein riesiger Klumpen aus mehreren Bereichen.
Das Technische (zuverlässige Hardware und Verfahren) ist dabei ja nur ein Bereich, die ganze Organisation und auch der gescheite Umgang mit Redundanz und Katalogisierung (welche Daten man wie oft und nach welchen Prinzipien man sichert, wie inkrementelles o. differentielles Backup, ein anderer, aber genauso wichtiger Bereich.
Der Aufwand ist und bleibt enorm. Und wenn man nicht allzu viel Zeit damit verbringen will, muss man halt auch bereit sein, manche Daten auch verlieren zu können.
Platten Images der Systeme alle paar sechs Monate und nur das notwendigste (Passwörter, Arbeitsstände, Mails, Rechnungen, Verträge etc.) regelmäßig, so mache ich das. Ansonsten wäre es ganz einfach zu teuer. Im Katastrophenfall hat man dann den Systemzustand von vor 6 Monaten, inklusive der “unwichtigen” Daten, wie Musik und Konsumdaten. Alles wichtige aktuellere muss dann eben wieder halbmanuell rückgespielt werden.
Aber das ist, wie gesagt, nur im privaten Umfeld.
Eine Backup-Architektur in einem kompletten Firmenumfeld bereitzustellen, allein die Policies auszuarbeiten und die passende Technologie zu finden und zu etablieren ist richtig Arbeit für sich.
Interessanter Bericht. Ich habe seit Jahren meine Systeme so konfiguriert, daß täglich ein Schnelltest und wöchentlich ein Extended-Selbsttest durchgeführt wird, Also einfach den auskommentierten Vorschlag aus der smartd.conf übernommen. So habe ich bisher alle ausfallenden Platten rechtzeitig erkannt.
Zu den Lesefehlern könnte auch das Idle-Abschalten geführt haben. Denn so befinden sich die Köpfe schließlich ständig im Luftstrom, während WD sich das so vorgestellt hat, daß die Spindel die meiste Zeit frei dreht und hin und wieder ein paar Zugriffe kommen. In der c’t habe ich mal gelesen, daß Köpfe auch nicht mehr als 45 °C Temperatur vertragen. Da WD auch noch bei der Aufhängung der Plattenspindel spart (nur einseitig fixiert, die andere Seite der Achse hängt frei), rate ich inzwischen von WDs Consumer-Modellen ab.
Persönlich bin ich mittlerweile zum HGST-Fan geworden (gehört inzwischen ja auch zu WD). Die Platten haben mir noch nie Ärger gemacht. Kein Park- und anderer Firmwareblödsinn, sie kommen problemlos mit 24/7-Betrieb und hohen Temperaturen klar (bis 60 °C) und vertragen meiner Erfahrung nach auch Fremdvibration deutlich besser.
Weil es wegen des Kartellamts fast nur noch 2,5″-Festplatten von diesem Hersteller gibt (der Rest ging an Toshiba), kauf ich eben die, sind sowieso wesentlich robuster. Langfristig wird wohl eh alles früher oder später auf SSD umgestellt und das Kapitel drehende Scheiben abgehakt.
@gedankenwerk
Die “Backup-Problematik im privaten Bereich” ist wirklich ein Riesen-Problem, da nutzbare Backups für Normal-User (also die Meisten) undurchführbar sind. Der hat nur zwei unbrauchbare Möglichkeiten:
1) Alles sichern 2) Nur User-Dateien sichern
Bei 1) macht nur eine zweite Platte Sinn um die Datenmenge zu bewältigen. Dutzende DVDs brennen oder teure DAT-Streamer zu kaufen ist dem Normalo nicht vermittelbar. Ein Voll-Backup kriegt der zwar noch hin, aber das Restore geht nur mit Boot-Sticks o.ä., da muss dann einer von “uns” ran.
2) kann man auch vergessen weil die es höchstens schaffen den Ordner “Eigene Dateien” auf ‘nen Stick zu ziehen. Da fehlt dann aber immer was weil halt nicht alle Programme wirklich alle User-Dateien da rein schreiben und die sowieso es immer irgendwie schaffen, ihre Dateien an den irrsten Orten abzuspeichern.
Die brauchen also immer einen von “uns”, aber seit meinem letzten Erlebnis verweigere ich strikt jegliche Hilfe in diesem Bereich. Das war ein Laptop mit 20 GB Bildern und Filmen vom Baby, bei dem die ruinierte Platte mit Müh und Not noch per DOS-Stick gebootet werden konnte. 20 GB auf einem 16-Bit-System mühsam mittels eines 8 GB Sticks zu sichern hat dann 3 Tage gedauert. Hier jetzt 300 € der Mama abzuknöpfen war mir zu brutal, also ein fettes Minus-Geschäft für mich.
Da muss die Menschheit also damit leben, dass man immer wieder mal ein paar oder alle Daten verliert, brauchbare Lösungen gibt es nicht bzw. nur für “uns”.
Guck an, eine der 2 WD20EARS im RAID1 ist bei uns auch vor einigen Wochen abgeraucht – nach gut 37k Stunden Quasi-Dauerbetrieb (sie hatte um die 50 Load Cycles in dieser Zeit). Das ist schon ordentlich für so eine Consumerplatte.
Allerdings gelten natürlich wieder die 3 Regeln des Festplattenkaufs:
* IDLE3 sofort ausschalten (also wirklich sofort, innerhalb der ersten Betriebsstunde)
* mehrere kaufen und ~10h testen um schlechte Lagerungen zu erkennen, Rest retournieren (sollte jeder gute Händler ohne Murren annehmen, denn die *sind* minderwertige Qualität)
* wenn RAID dann unterschiedliche Herstelldaten mischen, am gleichen Tag gebaute fallen auch oft gleichzeitig aus
Und natürlich monitoren, monitoren, monitoren. Mindestens ein Munin, dass man sich dann auch mal anguckt. SMART-Health ist kompletter unsinn, die Platte selbst hat erst Tage nach dem Komplettausfall gemerkt dass sie womöglich nicht mehr gut drauf ist. In unserem Fall hatte das md-RAID den Fehler bemerkt und sich gemeldet.
Die Platten jedenfalls sind jetzt ersetzt durch zwei neue WD40EFRX (das sind 4TB Red), der Platz wurde sowieso knapp. Auf die nächsten 4 Jahre 😉
(Oh und: ja, das ist keine Plug&Play-Box, sondern ein HP Microserver. Und nix im Laden gekauft, sondern im Fachhandel [was in .de quasi-identisch mit Versand ist])
Wie sich’s doch gleicht. Ich habe auch WD40EFRX nachgekauft und habe auch zwei HP Microserver. 🙂
Unter Linux kann man zumindest mit
hdparm
einige Hardwareseitige Einstellungen der Platte ändern und diese auch auf die Platte schreiben. Der Idle-Timeout wäre so ein Fall. Für andere Einstellungen muß man hdparm beim booten halt automatisiert wieder ausführen. Funktioniert aber gut so.
@no:
Nein. Es gibt ja nicht nur einen Idle-Timeout. hdparm kann nur Werte ändern, die im Treiber oder ATA-Standard festgelegt sind. Hier geht’s um einen WD-proprietären Wert in der Plattenelektronik.
Hadmut, hdparm kann in der aktuellen Version den IDLE3-Timer ändern. Dabei wird übrigens genau wie beim DOS-Tool mittels proprietärem Kommando die Firmware selbst gepatcht, denn WD hatte die Möglichkeit ja ursprünglich nie vorgesehen. Deswegen wird die Änderung auch erst nach dem Power-Cycle aktiv.
Bei neueren Green-Modellen funktioniert das natürlich eh nicht mehr.
> hdparm kann in der aktuellen Version den IDLE3-Timer ändern.
Is ja scharf… Danke!
Ich hatte massive Performanceprobleme mit HDDs, insbesondere als ich es als Root-FS auf meinem Laptop genommen habe (5k4 RPM HDD). Daher kann ich Hadmuts postulierte Performance-Probleme nur bestätigen (es liegt vermutlich an der starken Fragmentierung durch CoW). Ich vermute, dass das mit ZFS ähnlich ist, dennoch muss ich Hadmut vollkommen zustimmen dass das die einzig sinnvolle Lösung für ein Backupsystem ist. Aufgrund von vergangenen Problemen mit BTRFS (steht auch irgendwo in einem von Hadmuts Posts, ist schon ein paar Monate her) würde ich eher zu ZFS tendieren.
Der Grund dafür ist IMO vor allem, dass in einem RAID der RAID-Controller nicht mehr weiß auf welcher Platte die richtige Version gespeichert ist, insbesondere ohne Checksumme. Dann muss er raten. Selbst wenn man manuell eine sha512sum etc. angelegt hat, hilft einem das dann nur sehr begrenzt weiter, weil man in 50% der Fälle die falsche Version (pro Block) bekommt, wenn eine Platte einen Schreibfehler hat. Mit einem FS-Level-RAID mit ZFS/BTRFS löst sich dieses Problem selbst.
@Hadmut:
Use of -J is EXTREMELY DANGEROUS.
(Rückfrage: welches hdparm-flag ist nicht EXTREMELY DANGEROUS?)
@ Hans
ZFS mit nur normalen Festplatten ist, wenn es ans Schreiben geht, tatsächlich ziemlich langsam, selbst wenn man sync=disabled setzt. Das liegt aber quasi im Kern begründet, weil ZFS selbst transaktional aufgebaut ist und (eigentlich, wenn die Platten nicht lügen) keine transienten Zustände auf dem Backing Store erzeugt. Das macht einige Dinge aufwändiger. Man kann zwar einige Parameter zurechtbiegen, aber die imo einzig sinnvolle Lösung ist ein Log-Device. So ziemlich alles, was auf die Platte schreibt, ist danach massiv schneller.
Das Problem mit der Fragmentierung ist nochmal ein anderes. Je nach dem was man tut ist es auch ziemlich relevant. Hier zeigt sich halt, dass ZFS eigentlich für größere Anwendungen gedacht ist, bei denen Zugriffe fast immer näherungsweise wahlfrei sind.
Noch ein anderer Aspekt, der es als lokales Dateisystem problematisch macht, ist die Cachingarchitektur. Die ist auf gute Performance unter hoher Last im Dauerbetrieb getrimmt, nicht auf kleine Spitzen und Neustarts. (Ich glaube mittlerweile gibt es irgendwo eine Variante, die einen persistenten L2ARC besitzt, was sehr viel ausmachen kann.) Sind die Caches kalt, sind Zugriffe ziemlich teuer, weil oftmals erst noch Metadatenstrukturen geladen und traversiert werden müssen. Starte ich mein NAS neu und boote einen Rechner via iSCSI, dann ist das ziemlich lahmarschig, aber die Platten sind ziemlich gut ausgelastet. Ein “dummes” Dateisystem ohne den Overhead ist da anfangs schneller. Sind die Caches warm, dann spielen die paar Zugriffe, für die noch richtig Leseaufwand auf der Platte selbst notwendig ist, praktisch keine Rolle mehr, weil extrem viel aus dem Cache bedient wird.
Allerdings sind beim Booten und danach erstmal alle Caches leer.
Mit Rechenzeit, was Hadmut meinte, hat das aber nichts zu tun.
Und ja, für Backups ist ZFS wirklich genial. Snapshot machen, zfs send, fertig. Ein Restore ist genau so trivial und man muss sich keinerlei Gedanken mehr um solchen Käse wie Berechtigungen machen. Das Prüfen und ggf. reparieren von Backups ist qua scrub auch direkt eingebunden.
Zu hdparm:
Das Anzeigen der Hilfe ist relativ sicher 😀
Bei den privaten Backups halte ich das eh mittlerweile mit dem 3-Kopien-System: eine Kopie mit der man arbeitet, eine lokal im NAS, eine “außerhalb des Schüttkegels”. RAID5 mit Consumerplatten ist der letzte Mist, wenn eine abraucht geht die Wahrscheinlichkeit, dass eine oder beide andere Platten irgendwo Sektorfehler hat gegen 1, also unbrauchbar. Hab ich ziemlich oft schon gesehen.
Ich hab mir jetzt ein marsboard zugelegt, das ist ein 50$ China-ARM-Teil mit SATA, da läuft ein Debian drauf und BitTorrent Sync-t meine Sachen vom Rechner und zu einem anderen NAS was bei einem Bekannten steht (wo man in der größten Not, z.B. Wohnungsbrand/-einbruch auch mal hinfahren könnte).
Viel anderes macht finde ich im privaten Bereich, wo die Zuverlässigkeit der großen Platten nach TLER ja eh gegen 0 geht (Bitfehler vs. Plattengröße) wenig Sinn.
Das einzige wäre noch, “plötzliche” Änderungen bei alten Dateien z.B. per Prüfsumme abzufangen und Alarm zu schlagen, also damit fehlerhafte Sektoren frühzeitig zu erkennen. Aber automatisch kann man das m.E. eh nicht machen, denn wie soll man zwischen einer echten Änderung und einer “falschen” unterscheiden?
Zu den 10^14: Das ist der Garantiewert, nicht unbedingt der Realwert. Wärs real auch so, dann würden längst die Fetzen fliegen.
Genau diese mögliche Fehlerbilanz führt aber dazu, das ernsthafte RAID-Systeme auf SATA Basis sinnvollerweise gerne mit Dual-Parity betrieben werden, also RAID-6 oder RAID-DP statt RAID-5. Damit der Ausfall einer Disk nicht zum Datenverlust bei der Wiederherstellung führt. Wobei solche RAID-Gruppen dann schon mal 12 Disks umfassen dürfen.
Zum Problem, auf welcher Disks die richtige Version sitzt: Wenn eine Disk einen Sektor nicht mehr lesen kann, dann heisst das trotzdem i.d.R. nicht, dass sie Schrott liefert, sondern dass sie an Stelle der Daten einen Fehler liefert. Weshalb ein RAID dann durchaus weiss, wie an die korrekten Daten ranzukommen ist.
ZFS braucht viel RAM und ein System, das mit sysctl angepasst wurde.
zum anderen Mist: Ich kenne niemanden, der Dauerrotationsplatten ärgerfrei einsetzen kann. Immer ist was. Schlecht.
@Hanz Moser
Danke für die Hinweise! Du hast natürlich vollkommen recht. ZFS (und BTRFS) sind halt, genauso wie EXT[234] nicht “das eine perfekte” Dateisystem” (wird es wohl kaum jemals geben). Es kommt sehr auf die Anwendung an, und CoW ist trotz aller möglichen Nachteile natürlich ein super Feature!
Mit dem Cache hast du vollkommen recht, davon ausgehend dass der iSCSI-Target-Host genügend RAM bzw. schnellen SSD-Cache hat. Je nach Usecase ist es dann natürlich ziemlich schnell, wobei das meiner Auffassung nach zusätzlich noch von Geschwindigkeit und Auslastung des Netzwerks abhängig ist.
Wenn ich zum Beispiel wenige sehr große Dateien habe, die sich häufig in ihrem Inhalt ändern (nicht aber in der Größe), und ich muss periodisch die Dateien streamen, dann werde ich zumindest auf langsameren Platten mit CoW das Frag-Problem haben, dass die Dateien dann diskontinuierlich gespeichert werden, also i.d.R. relativ viele Seeks brauchen, während bei dummen FSs die alten Daten einfach überschrieben werden können, und daher die Anzahl der Seeks ziemlich reduziert werden dürfte. Für Backups dürfte das allerdings keine große Relevanz haben.
Hdparm: Bist du dir da sicher ;-? Man kommt durch die Hilfe auf dumme Gedanken!
zum anderen Mist: Ich kenne niemanden, der Dauerrotationsplatten ärgerfrei einsetzen kann. Immer ist was. Schlecht.
Ich fahre hier eine KISS-Strategie: kein RAID, kein DrölfFS, kein Foobar-Nerd-Zauber. Sondern Consumer-Platten (extern/intern) mit Simpel-Filesystemen, Kopieren mit rsync. Betriebssystem-Images mit dump. Das war’s. Katalog (was ist wo) führe ich mit Stift und Papier.
Ein NAS würde ich auch einfach als JBOD betreiben.
Ich achte außerdem penibel darauf, daß Lese-Software für die gespeicherten Datenformate immer auf den jeweiligen Datenträgern mit enthalten ist.
@prx Das kommt auf die Art des Fehler und auf die Firmware (insbesondere Fehlererkennung) der Platte an. Ich hatte beide Varianten schon.
@Michel Ja, ZFS ist vielleicht nicht das “normale” Desktop-FS, sondern eher ein spezialisiertes Storagesystem.
Klar, HDDs machen Ärger. Warum nimmt man sie trotzdem:
> Informatiker schmeißen Geld nicht raus, sondern kaufen das, was das Problem löst.
SSDs mit ein paar Terabyte, und noch mehrere davon, sind … teuer … . Das ist nicht toll, aber im Moment müssen wir damit leben.
Davon abgesehen, machen SSDs schon auch Ärger, oft halt nicht ganz so viel und wenn, dann häufig weniger (wenn nicht gleich die Elektronik ausfällt), zumindest nach meiner Erfahrung. Hängt aber auch vom Workload ab.
Longterm-Backups speichere ich auch gerne mal auf den guten alten LTO-1-Bändern. Die SCSI-Geräte dafür sind inzwischen relativ billig zu haben, LTO2-5 ist mir aktuell zu teuer.
Mindestens ein Munin, dass man sich dann auch mal anguckt. SMART-Health ist kompletter unsinn,…
Bin kein Linux Profi… Wo kann man Lesefehler, wenn nicht mit smartmintools so auslesen das man sie per rrdtool o.ä. Erfassen kann?
Hallo zusammen
Habe vor ca 2 Monaten meine einzige WD green verabschiedet. War die erste WD green 1 TB die es gab. Damals ganz neu mit variabler Drehzahl. Die Bezeichnung habe ich leider grad nicht zur Hand. Aber die platte machte nie Probleme und hatte zum Schluss knapp 15000 Stunden Laufzeit. Genaugenommen lief die platte noch. Wurde mir aber zu gefährlich.
Lg
Übrigens hier noch der Beweis, dass der hohe Load-Cycle-Count nicht wirklich “das” Problem ist, wahrscheinlich hat bei dir eher die Wahrscheinlichkeit + Datendichte zugeschlagen. smartctl von einer WD20EARS-07MVWB0, Power-On-Hours 2 1/3 Jahre, Load_Cycle_Count bei 87/200 (200 vermute ich, weil der Wert vor einem Jahr bei 140 war). Ich habe auch schon von solchen Platten gelesen, die >1Mio Load Cycles überstanden haben. Allerdings sind es auch “nur” 16,5 Load Cycles pro Stunde.
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always – 69
3 Spin_Up_Time 0x0027 253 253 021 Pre-fail Always – 1008
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always – 77
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always – 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always – 0
9 Power_On_Hours 0x0032 072 072 000 Old_age Always – 20579
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always – 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always – 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always – 75
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always – 47
193 Load_Cycle_Count 0x0032 087 087 000 Old_age Always – 339839
194 Temperature_Celsius 0x0022 118 100 000 Old_age Always – 32
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always – 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always – 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline – 0
199 UDMA_CRC_Error_Count 0x0032 200 150 000 Old_age Always – 1570
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline – 0
ZFS bietet eine Property namens “copies”, die angibt, wieviele Kopien eines Blocks gespeichert werden sollen. Damit kann man innerhalb eines Plattenverbunds auf Dataset Ebene nochmal gewichten. Persönliche Daten wie Digitalkopien wichtiger Dokumente und Photos in einem Dataset mit copies=3 sichern, die Onlinesicherung der BluRay Sammlung in einem mit copies=1.
Spätestens seit ZFS v28 wächst der Cache nicht mehr exorbitant, d.h. zumindest auf 64 Bit-Systemen mit >=2GB RAM braucht man keine sysctls mehr. Gilt für FreeBSD wie auch Solaris.
@ Hans
ZFS ist kein Allheilmittel, das ist richtig. Auch als root-FS ist es imo total geil, aber nur wenn man eine SSD hat. Da die IO-Performance einer typischen SSD mittlerweile für die meisten Zwecke ordentliche Reserven hat, merkt man von den Nachteilen und Schwächen während des Warmwerdens der Caches praktisch nichts. Auch die COW-Problematik ist weg. Dafür hat man aber alle Features, allen voran snapshots und send\receive. Was Michel hinsichtlich RAM sagt ist dann auch eher unwichtig, weil man einen riesigen Cache für ein Einzelsystem nicht braucht, ein paar hundert MB als Grundstock reichen und das heute eher Peanuts sind, wenn selbst Laptops bei real mit 8GB verkauft werden.
Als iSCSI-Host kommt es, wie du gesagt hast, immer drauf an, was mit dem Speicher gemacht wird, und natürlich auch auf die Netzwerkanbindung. Ich boote meine Kisten schon seit geraumer Zeit (fast) alle via iSCSI, weil man so bequem Backups machen kann, Offline Virenscans und sich nicht für jede kleine Büchse um die Hardware kümmern muss. Hinter dem Fernseher hängt ein altes Core2Duo Laptop. Wenn irgendeine Software Mucken macht, setze ich es auf einen alten Snapshot zurück – wie bei einer VM. Ich muss mich auch nicht damit herumschlagen, noch irgendwo eine alte 2.5″ Platte zu finden oder 50 Euro für eine auszugeben, obwohl ich eigentlich bloß ~20GB brauche. Und schneller als eine lokale 5400er ist eine via iSCSI angebundene 7200er Desktopplatte auch ohne ZFS dazwischen.
Mit ZFS und einer SSD als Cache hat man für die meisten Dinge nahezu die Geschwidigkeit einer lokalen SSD.
Richtig pervers wird es, wenn man ein Master-Image für so etwas wie eine Schulungsumgebung hat und dann eine Hand voll Klone, die man problemlos abreißen und neu machen kann. Zwei Festplatten, eine kleine SSD und ein paar GB RAM reichen dann, um 40 Rechner (wahrscheinlich auch noch mehr) zu versorgen – mit genug GBit NICs.
@ Joe
Und wie beugst du mit der Strategie genau dem Problem vor, das Hadmut hier getroffen hat? Also schleichende Korrumpierung der gespeicherten Daten? Verlässt du dich darauf, dass beim Umkopieren im Zweifel ein Fehler hochkommt?
Buffalo und WD billig HDDs – lustig. Selbst schuld. Ich Nicht-Akademiker habe eine NAS von QNAP und Platten von Hitachi hua722010cla330 mit, ich meine es waren, 5 Jahren Gewährleistung. Nach 18000 Betriebsstunden – no problemo – weil nix billig gekauft. Kindergartenthemen. Wenn ihr was gescheites wollt, müßt ihr halt zahlen. Sprich: IBM Hardware und SAS Platten rein und kein SATA Schrott. Ist wie im Leben: Ein Porsche ist ein Porsche und kein Fiat – sollte nun auch ein Akademiker verstanden haben.
@Michael: Schwätzer!
Halten wir fest: Herr Danisch ist Inkompetent in Fragen IT. Selbst schon für Privat. Aber hauptsache sich hier eine Plattform schaffen um sich selbst zu diskreditieren.
So und jetzt Zensur! Herr Pseuedofreiheitskämpfer! Ihre vorgehäuchelte Ethik können Sie sich in ihren Arsch stecken, wo ihre Moral und Rückrad sich schon befindet.
So solche kleinbürgerlichen aus Opportunismus verkappt-faschistoide “Freiheitskämpfer” haben wir hier doch wahrlich genug in unserem Land! Finden Sie nicht?
@James: Oh, wie herzerwärmend. Die Feministinnen versuchen jetzt mit einer Charme-Offensive, mich gnädig zu stimmen.
Sorry, James, das reicht noch nicht. Das musst Du noch üben.
An die ZFS/BTRFS Profis: wie baut man denn dort die Verschlüsslung rein?
Biss jetzt habe ich immer PV -> LUKS -> LVs -> Ext3/4 gemacht.
Würde man trotzdem PV -> LUKS -> Btrfs machen, auch wenn man mehr als eine Platte hat? Eigentlich soll ja BTRFS auch gleich die Raid Funktionen übernehmen. Oder habe ich da etwas falsch verstanden?
@Phil: Du hast das Problem richtig verstanden. Ist aber nicht so einfach.
Am besten ist es, wenn die Verschlüsselung im ZFS selbst verwendet wird. Dummerweise gibt’s die aber nur bei Solaris, nicht in der Linux-Version. Man kann natürlich auch die einzelnen Platten für ZFS mit LUKS verschlüsseln, das gibt aber kuddelmuddel bei zfs und man muss die Passworte immer für jede Platte eingeben, auch wenn’s die gleichen sind.
Man könnte sich also selbst was in die initramfs bauen, was das Passwort einmal abfragt und dann alle Platten luks-öffnet, bevor ZFS zupacken kann. Das wäre das Beste. Ansonsten Verschlüsselung auf Dateiebene (cryptfs oder sowas). Was natürlich auch wieder nicht wirklich toll ist, deduplizierung und sowas.
@Michael: Auch Big Names wie IBM oder NetApp verbauen SATA Disks in Storage-Systemen. Kommt immer drauf an wofür der Kram verwendet wird, d.h. ob eher Performance oder eher Kapazität gefragt ist.
@Phil: Zur Verschlüsselung mit ZFS (Annahme, dass zfsonlinux verwendet wird) kannst du LUKS einsetzen und wie Hadmut schreibt, gibst du dann für jede Festplatte einzeln das Passwort ein. Sind die Platten entsperrt, erstellst du den ZFS-Pool mit allen Festplatten – folgende Einstellung musst du danach noch machen, damit ZFS es zulässt, dass du auf den ZFS-Pool mount/umount anwenden kannst: ‘zfs set mountpoint=legacy Name_des_Pools’ Nun ist der ZFS-Pool auf den verschlüsselten, aber natürlich gerade entsperrten Festplatten erstellt. Willst du nun wieder sperren, zuerst umount und danach unbedingt ZFS mittels ‘zpool export Name_des_Pools’ mitteilen, dass der Pool “ausgeworfen” werden soll. Ansonsten kannst du die einzelnen Festplatten nicht sperren. Beim nächsten Mal zuerst für jede Festplatte wieder das Passwort eingeben, danach ‘zpool import Name_des_Pools’ und dann kann der Pool wieder gemountet werden.
Das hat halt gegenüber anderen Verschlüsselungsmethoden (auch gegenüber der ZFS-Verschlüsselung in Solaris) den Vorteil, dass LUKS verwendet wird.
Ich verwende jetzt selbst nur noch die WD-Red-Festplatten, das ist ein Kompromiss aus Garantiezeit+Zuverlässigkeit und Preis. Außerdem muss hier nichts mit einem IDLE3-Timer umgestellt werden, die Festplatten sind sofort einsatzbereit. Eine einzige Sache gibt es zu bedenken: Die Festplatte hat 4k-Sektoren, gibt aber die “alten” 512B an. Bedenkt man das nicht, arbeitet das System mit 512B und es gibt Performanceeinbußen. Unter ZFS lässt sich das manuell bei der Poolerstellung auf 4k umstellen, indem dem Befehl ‘zpool create’ mitgegeben wird: ‘-o ashift=12’
Wobei ich mich da noch frage, ob das auch sinnvoll ist, wenn darunter mit LUKS verschlüsselt wurde – spielt dann 4k vs 512B unter ZFS noch eine Rolle?
Um separate LUKS-Container auf mehreren Platten beim Booten mit nur einer Passphrase auf einmal zu öffnen, kann man unter Debian/Ubuntu statt initramfs-Anpassungen Marke Eigenbau auch das Script /lib/cryptsetup/scripts/decrypt_derived für abgeleitete Schlüssel verwenden: http://wiki.ubuntuusers.de/LUKS/Schl%C3%BCsselableitung
Damit man auch bei abgerauchter Primär-Platte noch die weiteren Container öffnen kann, sollte man sie unbedingt mit einer zusätzlichen manuellen Passphrase versehen. Diese manuelle Passphrase darf dabei auch für jede Platte unterschiedlich sein, wobei das je nach Anzahl verwirrend werden könnte, zumal man diese Passphrase(n) im Normalbetrieb ja nicht benötigt.
Beim Booten muss dann nur noch die Passphrase für den primären Container eingegeben werden. Sobald der erfolgreich entsperrt wurde, kann daraus automatisch der passende Schlüssel für die weiteren Container erzeugt und die damit geöffnet werden.
@prx Kurzum: “SATA drives have a BER of 1 read error in 10^15 bits read. SAS drives have a BER of 1 read error in 10^16 bits read. SAS drives are 10x more reliable for read errors.” http://blog.zmicro.com/blogzmicrocom/bid/270575/SAS-vs-SATA-Facts-and-Mythbusters
Klar – IBM verkauft auch SATA Storrage im Enterprise Segment – da muß man, wie Du erwähnst, halt abwägen ob billiger und dann eben 10x Fehleranfälliger. Wobei ich denke, daß die IBM Enterprise SATAs wohl besser sind, als die Enduser SATA Büchsen. Ein ganz anderes Universum sind da noch die WD/Seagate/… Billig-Blechbüchsen.
@Michael: Typischer Trugschluss.
Moderne SAS-Platten sind meist dieselben wie die SATA-platten, nur mit anderem Interface. Die geringere Fehlerquote kommt da dann alleine vom Übertragungsprotokoll, weil SAS weniger Übetragungsfehler macht als SATA. Wenn der Sektor aber nicht mehr lesbar ist, hilft Dir das einfach gar nichts.
@Michael: Nein. Ob SATA oder SAS, oder FC etc sinnvoller ist hängt von deiner Anwendung ab, nicht von deiner Glaubensrichtung.
SATA ist relativ günstig, aber für Multiuserbetrieb nur eingeschränkt geeignet, FC ist richtig teuer, dafür aber i.d.R. auch entsprechend schnell.
Ich kann deiner Philosophie “wer teuer kauft, kauft immer richtig” keineswegs zustimmen.
@Hadmut: Es gibt zwar 3,5er Platten mit SAS statt SATA als Nearline Storage. Die gängigsten SAS Platten für Server und besseren Storage sind heuzutage aber durchweg 2,5er mit 10K/15K U/min, während die 2,5er SATA maximal mit 7200 drehen. Das sind also getrennte Baureihen.
@prx: Die gängigsten SAS Platten für Server und besseren Storage sind heuzutage aber durchweg 2,5er mit 10K/15K U/min, während die 2,5er SATA maximal mit 7200 drehen.
Aber erstens brauch ich hier große 3,5-Zoll-Platten, zweitens habe ich keine Lust, mir schnelldrehende Platten (selbst wenn’s die kleinen sind) ins Büro zu stellen. Im Server-Raum gerne, aber nicht im Büro.
Zu den Fehlerraten: Die WD RE Reihe von 3,5er Enterprise SATA Disks (7200) gibts mit 6Gb/s SATA (WD4000FYYZ) und 6Gbs/s SAS (WD4001FYYG). Beide mit einer Fehlerrate von 10^16.
Demgenenüber liegen die WG Grenn (WD4ßEZRX) bei 10^-14.
Das Interface ist nicht der Grund.
@ Hadmut
Hast du für die Aussage, dass die geringere Bitfehlerrate alleine durch das Interface zustande kommt, eine Quelle zur Hand?
@Hanz:
> Hast du für die Aussage, dass die geringere Bitfehlerrate alleine durch das Interface zustande kommt, eine Quelle zur Hand?
Jetzt nicht zur Hand. Ich glaube mich erinnern zu können, das vor ein paar Monaten mal in einem Artikel der c’t über Festplatten gelesen zu haben.
Aber für 3,5er zu Hause brauchst du dann auch kein SAS. Die 10^16 Fehlerrate kriegst du auch mit SATA. Ich schrieb ja oben, dass die erwähnte WD Reihe für beide Interfaces diese Fehlerrate angibt.
Falls relevant die Google HDD Studie – allerdings nur über Heim-Blechbüchsen: http://static.googleusercontent.com/media/research.google.com/de//archive/disk_failures.pdf
Und wie beugst du mit der Strategie genau dem Problem vor, das Hadmut hier getroffen hat? Also schleichende Korrumpierung der gespeicherten Daten? Verlässt du dich darauf, dass beim Umkopieren im Zweifel ein Fehler hochkommt?
Siehe oben, regelmäßige Oberflächenscans, die SMART im Hintergrund ausführt. Wenn man die richtige Option (selective) wählt, können die sogar doch einen Powercycle unterbrochen werden und werden automatisch fortgesetzt. Die erforderliche Funktionalität ist komplett in jede Festplatte eingebaut. (Und ich wundere mich, daß die Festplattenhersteller sie noch nicht weggespart haben.)
Wichtige Daten sind zusätzlich noch prüfsummengesichert (auch wieder simpel per danebenliegenden .sfv- und .md5-Dateien oder sie sind eh in .zip-Archive gepackt) und können vollautomatisch geprüft werden. Außerdem setze aber primär darauf, immer genug Kopien verfügbar zu haben, so daß mich überraschende Lesefehler nicht treffen.
Einfach so korrumpierte Daten hatte ich übrigens noch nicht. Allerdings habe ich in meinem Bestand auch hauptsächlich Platten mit 333-500 GB pro Platter. Hadmuts WD20EARS kommt schon mit 667 GB/Platter daher und die aktuellen Festplattenmodelle haben TB-Platter, wo die gegenwärtige Grenze, des technisch möglichen erreicht ist. Auch vermeide ich wegen des Klumpenrisikos derzeit noch Plattengrößen über 2 TB.
Meine Strategie beruht einfach auf der Erfahrung, daß im privaten Rahmen auf der logischen Ebene viel häufiger Fehler passieren, als daß es zu echten Hardware-Ausfällen kommt. Von mir wird man also keine Hilferufe zu defekten Spielzeug-RAIDs oder unlesbaren ZFS-Pools lesen. Für Ext2, NTFS und FAT gibt es reichlichst Lese – und Salvagewerkzeuge für alle Plattformen.
@ Joe
Also eine halbgare (Prüfsumme pro Datei, statt pro Block), semi-manuelle Variante dessen, was ZFS macht, die aber deshalb besser sein soll. Plus regelmäßig SMART Scans anstoßen, statt Scrubs…
Jeder wie er es mag, aber mir scheint da ZFS weniger Potential für ein Versehen zu bieten.
Plus regelmäßig SMART Scans anstoßen, statt Scrubs
Das geht nicht nur wesentlich schneller, es stört nicht bei der Arbeit (da es kein I/O gibt). Die Firmware sieht bei einem Selbsttest direkt den PRML-Output und kann die Qualität der gespeicherten Daten beurteilen, bevor sie unlesbar werden.
Jeder wie er es mag, aber mir scheint da ZFS weniger Potential für ein Versehen zu bieten.
Ich habe keinen Vertrag mit Oracle (und damit kein ZFS) und dem Gebastel aus der Open-Source-Ecke werde ich meine Daten nicht anvertrauen. Sorry.
Hallo,
ich habe mal eine Nachfrage zum erstellen von MD5-Summen und feststellen was sich geändert haben könnte.
Gibt es da schon ein fertiges Konstrukt, so dass ich mir da nicht selber was im Zweifel nicht korrekt funktionierendes zusammen bauen muss?
Cu!
Hallo Herr Danisch,
als Stammleser beim werten LePenseur schnuppere ich schon seit einiger Zeit bei Ihnen rum und das meiste, was ich lese, gefällt mir ausnehmend.
Doch für diesen Warnhinweis muß ich mich explizit bedanken, da ich auch solch ein WD-Teil im Einsatz habe, sofort der idle3-Zähler überprüfte und einen Schock bekam. Nun habe ich das Parken deaktiviert und da die anderen SMART-Werte noch gut aussehen, mich wieder etwas beruhigt.
Als Dank und zur möglichen Gewissensentlastung einiger Männer sende ich Ihnen einen Link über das wichtige Thema, ob Frauen nun kommen oder nicht:
http://www.achgut.com/dadgdx/index.php/dadgd/article/hurra_wir_kommen_nicht
Doch für diesen Warnhinweis muß ich mich explizit bedanken, da ich auch solch ein WD-Teil im Einsatz habe, sofort der idle3-Zähler überprüfte und einen Schock bekam. Nun habe ich das Parken deaktiviert und da die anderen SMART-Werte noch gut aussehen, mich wieder etwas beruhigt.
Ich denke übrigens, daß der Verschleiß durch das Parken überbewertet wird und man sich durch diese Firmware-Modifikation u. U. mehr Ärger einhandelt. Die “grünen” WD-Platten haben je nach Serie zudem noch andere Probleme.
@Joe: Quark! Das ist keine Firmware-Modifikation, sondern das Ändern eines Parameters mit einer von WD offiziell dafür publizierten Software. Davon abgesehen habe ich bei den WD Green den Wert auf 300 Sekunden gestellt. Bei der WD Red steht er schon ab Werk auf 300 Sekunden. Wenn’s schlecht wäre, würde WD das Tool dafür ja nicht anbieten.
@Joe: Quark! Das ist keine Firmware-Modifikation, sondern das Ändern eines Parameters mit einer von WD offiziell dafür publizierten Software.
Es gibt keinen konfigurierbaren Parameter. Die Software, die WD nur auf Anfrage an Kunden rausgab, patcht einfach die Firmware, deswegen mußt Du danach powercyclen.
Und je nach dem, welche Version Software und Platte Du hast, funktioniert nicht mal das. Ich habe bspw. diverse Revisionen der WD Green und nur eine davon (die WD20EARS) kann überhaupt auf 300 Sekunden gebracht werden, die anderen sind auf 30 Sekunden (reicht auch), bei neueren Grünplatten funktioniert das Ding gar nicht mehr.
@Joe: Die Software gibts frei zum Download auf der Webseite, man braucht keinen Powercycle, und es wird auch nichts gepatcht.
MD5-Summen und feststellen was sich geändert haben könnte. Gibt es da schon ein fertiges Konstrukt,
Möglicherweise relevant (auf alle Fälle interessant) in dem Zusammenhang:
Backblaze Blog: What Harddrive Should I Buy?
und der zugehörige HackerNews-Diskussions-Thread.
Worauf bezieht sich denn deine Aussage, dass ZFS bzw. BTRFS langsam sind?