Sie hat ja eine URE von 1 zu 10^14 was rechnerisch alle 11,37TiB gelesene Daten garantiert einen unkorrigierbarer Lese-Fehler bedeutet.
Garantiert werden die Fehler zwar nicht, aber es wird eben auch nicht garantiert, dass sie dann nicht auftreten.
Demnach dürfte man bei einem Array von 12TiB garkein Array erstellen können, weil (rechnerisch) immer irgendeine Platte rausfliegt, bevor 12TiB gelesen wurden. Ist das so richtig?
Das Erstellen des RAIDs ist weniger das Problem, dabei wird ja praktisch nichts gelesen sondern nur geschrieben, die UBER ist aber immer als unkorrigierbare Sektoren pro gelesener Bit angegeben. Das sind bei Platten die einzeln betrieben werden die Sektoren, die dann als schwebende oder unkorrigierbare Sektoren in den S.M.A.R.T. Werten erscheinen.
falls das Array doch zustande kommt ist nicht gesagt, dass man jemals mehr ein Rebuild fertigstellen kann, da rechnerisch alle 11,37TiB ein unkorrigierbarer Lese-Fehler auftritt bis schliesslich das ganze Array zerstört ist.
Das Rebuild funktioniert halt nicht, damit kann das RAID dann unbrauchbar oder weiter nur degradiert sein. Auch muss man die Wahrscheinlichkeit auf die Fehlerwahrscheinlichkeit der einzelene Platten umrechnen, womit die Wahrscheinlichkeit etwas besser aussieht als wenn man einfach nur die Kapazitäten der Platten zusammenrechnet. Für eine 3TB HDD mit einer UBER von 1:10^14 liegt die Wahrscheinlichkeit sie einmal komplett fehlerfrei lesen zu können bei etwa 0,75, für 2 Platten (also bei Rebuild eines RAID 5 welches aus 3 solcher HDDs besteht) dann bei 0,75² = 0,5625. Für mein RAID5 mit meinen 5 3TB WD Red wäre also bei Ausfall einer Platte die Chance die anderen 4 fehlerfrei zu lesen noch 0,75^4 = 0,316, also bei fast einem Drittel und nicht praktisch 0. Mit 8 solcher Platten ist man dann aber schon bei 0,1 also 10% Chance angekommen und wenn man die großen 6TB Red oder Red Pro mit ihren ebenfalls nur 1:10^14 (bei Red Pro steht im Datenblatt zwar 10:10^15 aber soll nur besser aussehen, denn es ist auch nur 1.10^14, also ein klarer Fall von Kundenverarschung) nimmt, bei denen die Chance für eine Platte nur bei 0,5 liegt und davon 8 im RAID 5 betreibt, also im zweifel 7 beim Rebuild fehlerfrei lesen muss, dann sind es 0,5^7 = 0,0078, also keine 0,8% Wahrscheinlichkeit für ein Gelingen des Unterfangens. Dann muss man wirklich hoffen, dass die eigene Platten die Werksangabw deutlich schlagen, denn die ist ja immer <=.
Zum Vergleich ist bei einer UBER von 1:10^15 die Wahrscheinlichkeit eines Fehler pro etwa 120TB gegeben und damit kann man eine 6TB HDD also 19 von 20 mal fehlerfrei komplett lesen, also mit einer Wahrscheinlichkeit von 0,95, 7 davon also mit 0,95^7 = 0,698, hat also rund 70% Chance auf ein erfolgreiches Rebuild eines RAID 5 mit 8 solcher HDDs, im Vergleich zu weniger als einem Prozent wenn man HDDs mit einer UBER von 1:10^14 genommen hätte.
Nimmt man übrigens die Mission Critical Enterprise HDDs mit 15.000 rpm die eine UBER von 1:10^16 und maximal 600GB haben, so ist dort statistisch erst bei 2000 mal Lesen der Kapazität ein Fehler wahrscheinlich, es gibt also eine Wahrscheinlichkeit von 0,9995. Ein RAID 5 aus 8 davon hat bei Ausfall einer HDD immer noch eine Wahrscheinlichkeit von 0,9965 für ein erfolgreiches Rebuild und selbst bei 25 Stück davon in einem RAiD 5 ist die Chance das die verbleibenden 24 das Rebuild packen bei 0,988, also 98,8%, daher sind RAID 5 in Unternehemn durchaus nicht unüblich und bei 98,8% braucht man auch nicht viel Glück damit es klappt, da hat man viel Pech gehabt wenn es nicht funktioniert hat.
Ich dachte die ganze Zeit, dass ich mich mit meinen 10x Samsung F1 1TB @ Raid5 auf dünnem Eis bewege.
Das tust Du auch! Einmal haben die auch nur eine UBER von 1:10^14, also bei 1TB hast Du dann bei 9 Platten immer noch eine Chance von 45,7% auf ein erfolgreiches Rebuild, aber das sind RAID Platten, da gehst Du das Risiko ein wegen der Schwingungen der anderen HDDs, beim Rebuild sind ja immer alle gleichzeitig aktiv, dann mehr Probleme und danit eine erhöhte Fehlerwahrscheinlichkeit zu bekommen und dann könnte es bei einem HW-RAID auch noch Probleme mit der TLER (bzw. ERC bzw. CCTL) zu bekommen. Das sind alles verschiedene Begriffe für das Gleiche, TLER steht für Time-Limited Error Recovery, ERC für Error Recovery Control und CCTL für Command Completion Time Limit und meint die Zeit die eine Platte versucht selbst mit einem Fehler klar zu kommen. Das ist vor allem beim Versuch einen problematischen Sektor doch noch zu lesen relevant und das versuchen die SATA Platten alle bis sie es schaffen oder eben der Timeout erreicht ist und dann geben sie einen Lesefehler aus, wenn sie es nicht geschafft haben und haben einen schwebenden Sektor in den S.M.A.R.T. Werten.
Bei HDDs von denen man sagt sie hätten TLER (oder ERC..) ist das nicht anderes als bei denen die dies nicht haben, der Unterschied ist aber, dass bei denen mit TLER der Timeout einstellbar ist und ab Werk kürzer voreingestellt wurden. Bei SAS und FC Platten in Profi-RAIDs ist das übrigens i.d.R. kein Thema, die kann man auch mit 520 oder 528 Bytes pro Sektor formatieren und dann legt der Controller auf den zusätzlichen 8/16 Bytes eine eigene ECC ab und gibt den HDDs auch Befehle die Daten immer nur einmal zu lesen. Anhand der ECC erkennt er sofort selbst wenn eine Platte ein Problem mit einem Sektor hat, dann liest Daten aller anderen Platten an der Stelle, rekonstruiert anhand der Daten und der Parity die Daten des fehlerhaften Sektors und schreibt sie neu, wobei die Platten dann solche Daten prüfen und den Sektor wenn er defekt ist durch einen Reservesektor ersetzen, was auch bei den SATA Platten passiert und deshalb haben Platten in echten RAIDs (also nicht RAID 0, da gibt es ja keine Redundanz für die das R in RAID steht) auch nie schwebende Sektoren in den S.M.A.R.T. Werten.
SATA Platten erlauben es aber eben nicht andere Sektorgrößen zu verwenden und daher sind das sowieso eigentlich irgendwo Krüppellösungen die eben mit solche Problemen wie der TLER versuchen die Probleme zu umschiffen die echte Profisysteme gar nicht erst haben.
Umso mehr war ich verwundert, dass diese eine URE von 1 zu 10^15 haben. Das findet man eigentlich nur bei WD Pro bzw. Enterprise-HDDs, oder?
Bei der Red Pro steht 10:10^15 im Datenblatt, was nur eine Form ist 1:10^14 auszudrücken, man könnte auch 0,1:10^13 oder 100:10^16 dafür schreiben, ist alles das Gleiche, nur fallen eben viele Leser wenn sie nur 10^15 sehen drauf rein und achten gar nicht auf die 10 statt der 1 vor dem :, wobei das bei Toshiba
sogar im Datenblatt der MG Enterprise Nearline steht: "Non-recoverable Error Rate: 10 errors per 10^16 bits read"! Für mich sind solche Verarschungen ein klarer Grund mich bei anderen Anbietern umzusehen! Die HGST Deskstar NAS hat leider auch nur eine UBER von 1:10^14, die
Seagate Enterprise NAShaben dagegen eine
"Nonrecoverable Read Errors per Bits Rate: 1 sector per 10E15" und 300TB Workload Rating im Datenblatt stehen und das ganz ehrlich ohne eine 10:10^x Verarschung und ebenso die
8 TB Surveillance, aber dort nur die 8TB und nicht die kleineren Versionen der
Surveillance Reihe.
Das bedeutet, ich muss in Zukunft viel tiefer in die Tasche greifen, um in Zukunft meine 20TiB zu verwalten.
Das würde ich empfehlen, wenn Du eine gute Chance auf ein Rebuild haben willst, aber Augen auf beim Blick auf die Angaben in den Datenblättern, da versuchen leider einige Hersteller den Kunden Sand in die Augen zu streuen.
Wäre es da nicht besser statt das Raid zu erweitern einfach gute und günstige Desktop-HDDs zu kaufen und diese zu spiegeln (nicht Raid1, nur einzeln gespiegelt)
Desktoplaufwerke in RAIDs, vor allem HW-RAIDs sind keine gute Idee und ein Backup, falls Du das mit spiegeln meist, ist sowieso Pflicht, da
RAIDs keine Backups ersetzen können!
Braucht man für SAS T10 PI detection spezielle SAS-HDDs oder spezielle Controller?
Ja, das müssenPlatten sein die auf eine anderen Sektorgröße als 512 Byte formatiert werden können, was die SATA Norm gar nicht erlaubt. Aber das geht nun wirklich etwas weit, vorher sollte man schon bei anderen Dingen ansetzen, wie dem Backup des RAIDs und einem Rechner der auch ECC RAM unterstützt, liegen RAM Fehlerraten doch noch einmal deutlich höher, bei 778 bis 25.000 FIT/Mbit (FIT = failure rate in 10^9 device hours) als Harddiskfehler mit T10 PI.
Die billigen Platten brauchen bei einem Rebuild länger, weil ständig etwas korrigiert werden muss. Je länger der Rebuild dauert, desto länger besteht auch das Risiko für völligen Datenverlust bevor das Rebuild abgeschlossen ist.
Da ich jetzt die Quelle nicht gelesen habe, kann ich das nun nicht so einsortieren, aber im Prinzip ist die UBER natürlich für die Platte wie sie ist, also auch mit der TLER Einstellung ab Wert und da ist bei den Desktopplatten eben der Timeout höher voreingestellt. Bei den WD Green müsste es 14s sein, bei den Red ist es 7s, weil HW RAID Controller i.d.R. einen Timeout von 8s für die Anwortzeit der Platten haben, eine Platte die in der Zeit nicht antwortet dann also als defekt aus dem RAID fliegt. Passiert einem das beim Rebuild, dann ist das RAID danach nicht mehr nur degraded sondern FAILED und damit flöten. Daher ist der Eindatz von Desktopplatten für ein RAiD und vor allem für ein HW-RAID nicht zu empfehlen!
