News NAS-Festplatten: WD Red und WD Red Pro auf 10 TByte aufgestockt

[Holt]

Naja dennoch wüsste ich gern mal Holt warum ich bei dem Vielfachen von 12TB mit "ungeeigneten" Desktopplatten noch keinen Fehler feststellen konnte, wenn sie doch im Schnitt alle 12TB einen unkorrigierbaren Fehler ausgeben.

Wie kommst Du darauf das es garantiert alle 12TB einen Fehler geben muss? Ich hatte doch extra geschrieben:

Die Wahrscheinlichkeit muss man pro Platte errechnen. Bei einer UBER von 1:10^14 muss man pro etwa 12TB gelesener Daten (den genauen Wert kennt man nicht, da man ja nicht weiß wie viele Bit neben den Daten noch pro Sektor vorhanden sind, z.B. für die ECC) mit einem Lesefehler rechnen, der muss nicht kommen, kann aber und selbst dann ist die HDD noch innerhalb ihrere Spezifikationen.

Da Lesen und Verstehen nicht Deine Stärke zu sein scheint, ist jede weitere Diskussion also Zeitverschwendung.

 

[Bogeyman]

Du bist auch nen Komiker oder?
Lesen scheint auch nicht deine Stärke zu sein du hattest geschrieben dass man bei 12TB mit einem Fehler rechnen muss, sogar in deinem eigenen Zitat steht das. Das das nur ein Erwartungswert ist ist mir auch klar.
Nur etwas merkwürdig das dann nach 288TB gelesenener Daten pro Jahr und nach 2 Jahren jetzt eben das doppelte, noch immer keiner dieser merkwürdigen Fehler aufgetreten ist?
Vielleicht fragste mal nen Mathematiker wie Warscheinlich genau DAS am Ende ist bei 12TB nen Erwartungswert von 1 zu haben. Dann bei über dem 20fachen aber immer noch bei 0 zu sein dann?

Glaubst mir oder lass es bleiben, ich habe gut nen halbes Petabyte von meinem 6x4TB Array gelesen mit keinem einzigen Lesefehler... Dies ist zwar möglich, laut deinen Ausführungen aber total unwarscheinlich...
Und "billige" Desktopplatten sind es noch dazu auch.

Wie kommst Du darauf das es garantiert alle 12TB einen Fehler geben muss?

Du hast das Wort "vielfach" obwohl du es zitiert hast gekonnt ignoriert.
Ich wunder mich nicht darüber dass ich 6 mal gewürfelt habe und nie ne 6 gewürfelt habe. Ich wunder mich weil ich über 100mal gewürfelt habe und immer noch keine 6 hatte...

 

[KRambo]

Ein Fehler kann vorkommen, muss aber nicht. Die UBER beziffert die Wahrscheinlichkeit eines solchen Fehlers.

Wenn du bisher noch keine Probleme mit deinen Greens hattest kannst du auf Holz klopfen, trotzdem würde ich das keinem weiterempfehlen. Ich halte mich lieber an die Empfehlungen der Hersteller und gebe etwas mehr Geld für die richtigen Platten aus, im Fehlerfall merkt man den Unterschied. Aber jeder wie er will

 

[Bogeyman]

Ich habe keine Greens.

Die UBER beziffert die Wahrscheinlichkeit eines solchen Fehlers.

Wenn du bisher noch keine Probleme mit deinen Greens hattest kannst du auf Holz klopfen

Ach komm ich bitte dich. Wenn ich 100mal Würfel und keine 6 dabei rum kommt reicht dir als Erklärung dann auch "bist halt ein Glückspilz!"
Oder hälst es vielleicht nicht für warscheinlicher dass der angegebene UBER Wert nicht hinhaut immer und teilweise sogar besser ist?
Ich bitte dich auch zu bedenken dass ich 6 Platten habe. Dass alle 6 ein außergewöhnlicher Glücksgriff waren, ist wohl auch arg unwarscheinlich findest du nicht?

im Fehlerfall merkt man den Unterschied

Du wirst Schwierigkeiten haben beweisen zu können dass der Fehler genau deswegen auftrat weil es die falsche Platte war. Verrate mir doch bitte mal wenn mir ne Platte nach einem Jahr abschmiert, ich dir auch sämtliche Logs dazu liefern könnte, wann wieviel auf der Platte geschrieben wurde. Auch Temperaturverlauf haste über die gesamte Dauer. Wie du mir NACHWEISEN willst dass der Fehler der zum Datenverlust geführt hat mit einer anderen Platte NACHWEISLICH nicht augetreten wäre? Du kannst nur Aussagen treffen wenn du eine genügend hohe Anzahl an Festplatten lange genug beobachtest. Und dann auch nur allgemein aber niemals über eine einzelne Festplatte allein die vor dir liegt.
Wenn meine Oma an Krebs stirbt kann ich auch nicht sagen dass war wegen Tschernobyl weil sie deswegen krank wurde.
Kann im Endeffekt sein, muss aber nicht, und zu beweisen ist das nicht.

 

[Racer11]

Ich war der mit den Greens und der WD Blue.
Muss jeder selbst entscheiden, ob es ihm die 40-50€ mehr pro Platte wert ist.
Jedenfalls sind die Green, Blue und Red alle baugleich. Nur die Firmware ist anders.

 

[Koto]

@Holt

Ich verstehe nicht viel von der Materie aber ich habe noch nie einen unkorrigierbare Fehler bei bei meinen Platten gesehen in 47 Jahren. Defekte mal außen vorgelassen.

Nun kann man natürlich Argumentieren man hatte mehr Glück als der Russisch Roulette Vize Weltmeister. Oder es ist so Wahrscheinlich wie der Papst Muslime wird oder ich 6 mal im Lotto Gewinne.

@all
Da stellt sich auch die frage zumindest für mich. Deutlich Geld ausgeben für etwas, dessen Wahrscheinlichkeit quasi gegen 0 tendiert?

Also dafür bin ich dann doch zu Rational eingestellt.

 

[Holt]

Bogeyman, bist Du sicher das solche Fehler überhaupt dort geloggt würden wo Du nachsiehst? Die Lesefehler kommen bei einem RAID ja nicht nach oben, solange die Daten ja mit Hilfe der Daten von den anderen Platten und damit der Redundanz doch noch rekonstruiert werden konnten. Die RAID überschreiben dann auch sofort den betroffenen Sektor, man sieht also auch keine schwebenden Sektoren wie es sonst üblich ist, wenn ein solcher unkorrigierbarer Fehler aufgetreten ist und es keine Platte in einem echten RAID (also mit Redundanz) ist. Bei einem HW RAID Controller dürfte aber wegen der bei den aktuellen Desktopplatten meist fehlenden TLER/ERC durchaus passieren, dass die HDD dann aus dem RAID fliegt, SW RAIDs und vor allem ZFS haben aber sehr, sehr Timeouts, dort passiert dies in aller Regel nicht.

Koto, Du hast noch nie eine HDD mit einem schwebenden Sektor gesehen? Das kann ich kaum glauben! Und nein, ein schwebender Sektor bedeutet nicht das die HDD defekt ist, daher ist es in aller Regel für die Hersteller auch kein Grund für einen Garantiefall.

 

[Koto]

Koto, Du hast noch nie eine HDD mit einem schwebenden Sektor gesehen? Das kann ich kaum glauben! Und nein, ein schwebender Sektor bedeutet nicht das die HDD defekt ist, daher ist es in aller Regel für die Hersteller auch kein Grund für einen Garantiefall.

Also früher hatte ich schon Defekte Sektoren. Das ist aber echt ewig her. Das war irgendwann in den 80er.

Mag natürlich sein das die Platte so was heute selber korrigiert. Also den Sektor außer Dienst stellt.

 

[Racer11]

Man kann aber nicht generell behaupten, dass schwebende Sektoren nicht auf einen Defekt hinweisen. Das ist definitiv falsch. Meistens sogar ist es ein starkes Anzeichen für einen schon bestehenden Defekt. Ich hatte schon viele Platten während der Arbeit in der Hand. Nur wenige mit schwebenden Sektoren hatten nach dem Wipen die gleiche Anzahl an schwebenden Sektoren oder tatsächlich weniger.

 

[Bogeyman]

Bogeyman, bist Du sicher das solche Fehler überhaupt dort geloggt würden wo Du nachsiehst? Die Lesefehler kommen bei einem RAID ja nicht nach oben, solange die Daten ja mit Hilfe der Daten von den anderen Platten und damit der Redundanz doch noch rekonstruiert werden konnten. Die RAID überschreiben dann auch sofort den betroffenen Sektor, man sieht also auch keine schwebenden Sektoren wie es sonst üblich ist, wenn ein solcher unkorrigierbarer Fehler aufgetreten ist und es keine Platte in einem echten RAID (also mit Redundanz) ist. Bei einem HW RAID Controller dürfte aber wegen der bei den aktuellen Desktopplatten meist fehlenden TLER/ERC durchaus passieren, dass die HDD dann aus dem RAID fliegt, SW RAIDs und vor allem ZFS haben aber sehr, sehr Timeouts, dort passiert dies in aller Regel nicht.

Koto, Du hast noch nie eine HDD mit einem schwebenden Sektor gesehen? Das kann ich kaum glauben! Und nein, ein schwebender Sektor bedeutet nicht das die HDD defekt ist, daher ist es in aller Regel für die Hersteller auch kein Grund für einen Garantiefall.

Also ich lasse mir die Info per zpool status anzeigen.

Näheres dazu unter http://docs.oracle.com/cd/E19253-01/819-5461/6n7ht6r74/index.html

The second section of the configuration output displays error statistics. These errors are divided into three categories:

READ – I/O errors that occurred while issuing a read request

WRITE – I/O errors that occurred while issuing a write request

CKSUM – Checksum errors, meaning that the device returned corrupted data as the result of a read request

Liefert eine Platten Daten die nicht mit den Prüfsummen von ZFS übereinstimmen läuft dort der Zähler hoch und wenn eine Kopie vorhanden ist, also Redundanz wird der Fehler damit behoben.

Wenn man von diesen 12TB ausgeht und der Erwartungswert dort 1 ist, dann ist es imo sehr unwarscheinlich dass man davon überhaupt nichts sehen würde bei mehreren 100TB gelesenen Daten. Nicht unmöglich, aber doch eher unwarscheinlich sofern der UBER Wert stimmen sollte.

 

[Holt]

Mag natürlich sein das die Platte so was heute selber korrigiert. Also den Sektor außer Dienst stellt.

Das mag nicht nur sein, wenn ein schwebender Sektor überschrieben wird, dann und nur dann prüfen die Platten die neu geschriebenen Daten und wenn sie korrekt sind, dann verschwindet der schwebende Sektor einfach wieder. Andernfalls wird ein Reservesektor aktiviert und der defekte Sektor nicht mehr benutzt, dann hat die Platten einen wiederzugewiesenen Sektor (mehr).

Man kann aber nicht generell behaupten, dass schwebende Sektoren nicht auf einen Defekt hinweisen.

Man kann aber auch nicht behaupten, dass sie immer auf einen Defekt hindeuten, auch das ist definitiv falsch. Es kann neben einem Defekt eben auch andere Ursachen für schwebende Sektoren geben,
z.B. Vibrationen oder Stöße während eines Schreibvorgangs die dazu führen das Daten auf der Nachbarspur überschrieben werden oder Spannungsabfälle während Schreibvorgängen, so dass nicht mehr die kompletten Daten mit der ECC dahinter auf den Sektor geschrieben werden können. Beides ist kein Defekt der Platte. Ob ein Defekt vorliegt, sieht man erst nach dem Überschrieben und zwar daran ob ein (weiterer) Reservesektor aktiviert wurde oder nicht. Wenn nicht, lag kein Defekt vor!

Meistens sogar ist es ein starkes Anzeichen für einen schon bestehenden Defekt.

Über Häufigkeiten liegt mir keine Statistik vor, aber wenn ich sehe wie oft bei den Fällen im Forum die schwebenden Sektoren nach dem Überschrieben wieder verschwunden sind, so würde ich das meistens eher nicht unterschreiben wollen. Wenn wirklich ein Defekt vorliegt, steigt die Zahl der schwebenden und i.d.R. auch die der wiederzugewiesenen Sektoren eigentlich immer recht schnell an, was dann wirklich ein Alarmsignal ist. Aber manche tauschen eben jede HDD schon beim ersten schwebenden Sektor und das ist nun wirklich übertrieben.

Nur wenige mit schwebenden Sektoren hatten nach dem Wipen die gleiche Anzahl an schwebenden Sektoren oder tatsächlich weniger.

Nach dem Wipen sollte es keine schwebenden Sektoren mehr geben, wenn dabei wirklich alle Sektoren überschrieben wurden. Wenn doch, dann wurden entweder die S.M.A.R.T. Werte nicht wirklich neu eingelesen, von dem Controller der Platte nicht aktualisiert oder der hatte selbst einen Fehler, ggf. auch einen FW Bug.

Liefert eine Platten Daten die nicht mit den Prüfsummen von ZFS übereinstimmen läuft dort der Zähler hoch

Genau das passiert aber bei einem unkorrigierbaren Bitfehler nicht, die HDDs liefern eben keine korrupten Daten sondern einen Lesefehler an den Host zurück. Korrupte Daten gibt es nur, wenn entweder ein Fehler auf dem internen Datenpfad vorhanden ist und die Platte dagegen keinen Schutz hat oder wenn es einen FW Bug in der Platte oder dem Controller gibt, beides kommt selten vor. Bei SW-RAID wie ZFS kann noch das RAM hinzu kommen, zumindest sofern man kein ECC RAM (natürlich immer mit passendem System welches das auch unterstützt!) hat oder das OS auf unkorrigierbare RAM Fehler nicht entsprechend reagiert. Die Frage ist also, ob solche Lesefehler die auch jedes normale RAID (mit Redundanz) ausbügeln kann dort auch gezählt werden oder nur die eigentlich extrem unwahrscheinlichen Fälle in denen "HDDs" wirklich mal falsche Daten liefern. Keine Ahnung und wenn ich sowas lese habe ich auch keine Lust mehr mich da weiter durch die Doku zu wühlen:

Bit rot – Over time, random events such as magnetic influences and cosmic rays can cause bits stored on disk to flip. These events are relatively rare but common enough to cause potential data corruption in large or long-running systems.

Sowas gibt es bei SATA Platten nicht, außer bei Nutzung der ATA Streamingbefehle, aber die sind nur für Echtzeitvideoaufzeichnungen, die nutzt Windows von sich auch gar nicht und nur die Surveillance und Enterprise Nearline HDDs unterstützen diese Befehlserweiterung überhaupt. Das kann bei SAS Platten provoziert werden, denen kann man die Rohdaten abverlangen und genau das machen die SAS RAID Controller meist auch, nur sollte es nur gemacht werden, wenn die Sektorgröße auch entsprechend erhöht wird (z.B. auf 520 oder 528 Byte statt 512) damit der Controller dort eine eigene ECC ablegen und die Daten daher selbst prüfen kann. Wenn man da Fehler macht, sollte man sich über korrupte Daten nicht wundern und Fehler passieren immer wieder mal, auch den Entwicklern der FW von SAS HBAs/RAID Controllern.

Wenn man von diesen 12TB ausgeht und der Erwartungswert dort 1 ist, dann ist es imo sehr unwarscheinlich dass man davon überhaupt nichts sehen würde bei mehreren 100TB gelesenen Daten. Nicht unmöglich, aber doch eher unwarscheinlich sofern der UBER Wert stimmen sollte.

Der UBER Wert ist ein Worst Case, wie viel besser HDDs in der Regel sein werden, entzieht sich meiner Kenntnis, dazu habe ich auch keine Statistiken, aber ich möchte mich auch nicht darauf verlassen das eine Hardware um ein Vielfaches besser ist als es vom Hersteller angegeben wird.

 

[Bogeyman]

aber ich möchte mich auch nicht darauf verlassen das eine Hardware um ein Vielfaches besser ist als es vom Hersteller angegeben wird.

Das vielleicht nicht aber dennoch wäre es interesant wie sich die HDD so im Mittel verhält und nicht nur im Worst Case.
Kann es nicht sein dass die Hersteller diesen Wert absichtlich niedrig setzen um einen eventuellen Rechtsstreit aus dem Wege zu gehen wenn sich wirklich mal jemann die Mühe macht entsprechend die Fehler zu dokumentieren. Da dürfte sich der Hersteller bei einem großen Storage Provider auch schlecht rausreden können, wenn dieser hinreichend viele HDDs beobachtet hat.
Vielleicht hat man da auch so im Schnitt eine Größenordnung an Puffer eingebaut um auf der sicheren Seite zu sein?
Jemand der ne Halterung fürn TV oder Beamer verkauft/herstellt wird ja bei der maximalen Traglast diese auch eher zu niedrig als zu hoch ansetzen.

 

[fuyuhasugu]

Glaubst mir oder lass es bleiben, ich habe gut nen halbes Petabyte von meinem 6x4TB Array gelesen mit keinem einzigen Lesefehler...

Ich verstehe nicht viel von der Materie aber ich habe noch nie einen unkorrigierbare Fehler bei bei meinen Platten gesehen in 47 Jahren.

Da haben aber zwei ganz fleißig beim Schreiben alle Bits per Hand notiert und beim Lesen ebenso fleißig wieder verglichen.

Wer sagt denn, dass sich der Fehler überhaupt bemerkbar gemacht hat? Genauso ist möglich, dass Fehler auf anderen Ebenen des Transfers und der Bearbeitung von Daten korrigiert werden. Einfach so zu behaupten, dass noch nie ein Fehler aufgetreten wäre, ist ziemlich blauäugig. Wenn Fehler derartig selten wären, könnte man sich eine ganze Menge Arbeit zur Absicherung der Datenkonsistenz sparen.

 

[Holt]

Vielleicht hat man da auch so im Schnitt eine Größenordnung an Puffer eingebaut um auf der sicheren Seite zu sein?

Das auf jeden Fall, aber man sollte eben nicht vergessen, dass diese Fehlerate auch eingehalten werden sollte, wenn die Kunden die HDD hart am Limit ihrer Spezifikationen betreiben. Hat sie einen eher entspannten Arbeitsplatz, so dürfte sie eben um einiges Besser abschneiden als wenn sie irgendwo mit größeren Belastungen betrieben würde. Nur weißt Du für wie entspannt die HDD den Arbeitsplatz z.B. in Deinem NAS ansieht? Vielleicht ändert sich das wenn nebenan eine HDD eingebaut wird sie stärker vibriert als ihre Vorgängerin.

Wer sagt denn, dass sich der Fehler überhaupt bemerkbar gemacht hat?

Bei einem echten RAID fällt er in aller Regel nur beim Rebuild auf, dafür da dann auch meist richtig blöd in der Form das es fehlschlägt, weil eben die HDD keine korrupten Daten liefern, sondern einen Lesefehler. Die Wahrscheinlichkeit das die Daten zwar korrupt sind, die ECC aber trotzdem passt, kann man praktisch mit 0 ansetzen, da diese mindestens noch mal um den gleichen Faktor geringer ist wie die UBER selbst und die UBER sagt schon aus, dass ein Bitfehler zwar erkannt aber eben nicht mehr korrigiert werden kann. Diesen Lesefehler zu behandeln ist Aufgabe des OS, wobei das OS diese bestenfalls loggt und dann an das Programm weiterreicht welches die Leseanforderung gestellt hat. Ignoriert es den einfach und tut so als wäre alles gelesen, so hat man dann hinterher eine korrupte Datei im Speicher oder ggf. auch kopiert, die dann oft so aussieht das ab einer bestimmten Adresse die glatt durch 512 Byte teilbar ist, dann nur noch 00 in der Datei steht.

Genauso ist möglich, dass Fehler auf anderen Ebenen des Transfers und der Bearbeitung von Daten korrigiert werden.

Bei ZFS ja, da ist die Frage was dann wo geloggt wurde.

Einfach so zu behaupten, dass noch nie ein Fehler aufgetreten wäre, ist ziemlich blauäugig. Wenn Fehler derartig selten wären, könnte man sich eine ganze Menge Arbeit zur Absicherung der Datenkonsistenz sparen.

Das auf jeden Fall, dabei ist es gerade die größtmögliche Absicherung vor jeder Art von Fehlern die den Mainframes das Überleben in so kritischen Bereichen wie Banken und Versicherungen garantiert.

 

[Koto]

Wer sagt denn, dass sich der Fehler überhaupt bemerkbar gemacht hat? Genauso ist möglich, dass Fehler auf anderen Ebenen des Transfers und der Bearbeitung von Daten korrigiert werden. Einfach so zu behaupten, dass noch nie ein Fehler aufgetreten wäre

Na gut, aber Fehler die letztendlich korrigiert wurden und keine Auswirkungen haben sind doch Irrelevant?

Komische Diskussion. Irgendwie scheint es da nur um Recht haben des Recht haben willens zu gehen?

 

[Holt]

Klar sind Fehler die korrigiert werden konnte irgendwo irrelevant, aber wenn man ein RAID 5 hat und davon ein Rebuild machen muss, dann können Fehler eben dabei nicht mehr korrigiert werden und dann sie eben relevant und daher ist die UBER eben schon interessant.

 

[Dreamer10]

Also die WD Red Pro 10TB steht auf meinem Wunschzettel ganz oben. Nur blöd, dass ich erst Ende letzten Jahres die WD Red Pro 8TB gekauft habe; und jetzt kommt ein sparsameres, schnelleres und auch noch leiseres Nachfolgemodell:

After introducing its first hermetically sealed helium-filled NAS and video-surveillance HDDs with 8 TB capacity and six platters last year, Western Digital is refreshing its Red and Purple lineups with more advanced drives offering 10 TB capacity and using seven 1.42 TB platters. The new WD Red and WD Red Pro with 10 TB capacity are based on revamped 5400 RPM and 7200 RPM HelioSeal platforms that can support a higher number of platters. The drives also feature increased areal density and 256 MB of cache, enabling ~17% higher sequential read/write performance compared to its predecessors, as well as a lower power consumption compared to previous-gen helium WD Red hard drives. Other than that, Western Digital does not really disclose the feature set of its platform for helium-filled HDDs for NAS applications.

http://www.anandtech.com/show/11412/wd-adds-helium-filled-10-tb-nas-hdds-to-wd-red-wd-red-pro-lineups