Seagate IronWolf Pro mit 22 TB im Test: Neues Modell mit 2,2 TB je Platter

Thread Starter
Mitglied seit
06.03.2017
Beiträge
114.157
Mit der Seagate IronWolf Pro, 22 TB, aus der neuen NT001-Serie haben wir Seagates NAS-Top-Modell im Test. Mit CMR und einer Füllung mit Helium kann Seagate die Speicherkapazität weiterhin ohne den Einsatz von HAMR oder anderen EAMR-Technologien umsetzen. Wie sich die ST20000NT001 gegen die Konkurrenz mit Mikrowellen oder Magnetfeldern schlagen kann, klären wir in unserem Test.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das ist mittlerweile auch echt hart: :poop:

Nicht korrigierbare Lesefehler pro gelesenem Bit, max.1 Sektor pro 10E15
 
Danke euch für den Test.
"Leider gibt es keine Möglichkeit zu sehen, in welchem Zustand sich die Festplatte befindet."
Kann man leider nicht so stehen lassen. Man kann das z.b. Mit OpenSeachest (https://github.com/Seagate/openSeaChest) herausfinden.
./openSeaChest_PowerControl -d /dev/sgX --checkPowerMode
Dies funktioniert nach meinen Tests auch mit meinen Platten von Western Digital. Über Toshiba kann ich nichts sagen, da ich davon keine besitze.
 
Das ist korrekt, ich nehme den Satz heraus.
 
"Seagate IronWolf Pro mit 22 TB so leise, dass wir sie mit unseren technischen Mitteln nicht messen können."

Not bad not bad, für so einen Brecher.
 
Lesefehler lassen sich nur über Redundanz das Dateisystems verhindern. Da sollte man mal die Realität akzeptieren. Vor der Festplatte wäre da auch mal über den breiten Einsatz von ECC RAM zu diskutieren.
 
Lesefehler lassen sich nur über Redundanz das Dateisystems verhindern.
Unsinn! Wieso muss die Redundanz vom Dateisystem sein? Die Redundanz von einem echten (also keinem RAID 0) klassischem RAID funktioniert genauso, denn jede vernünftige RAID Lösung wird bei einem Lesefehler von einer der Platten in der Form reagieren, dass es die Daten mit Hilfe der Redundanz rekonstruiert und den betroffenen Bereich der Platte die den Lesefehler gemeldet hat, dann auch direkt überschreibt.
Da sollte man mal die Realität akzeptieren.
Eben, nur entspricht was von der ganzen ZFS Fanbase verbrietet wird, leider oft nicht der Realität, s.o.!
Vor der Festplatte wäre da auch mal über den breiten Einsatz von ECC RAM zu diskutieren.
Wenn es um Datenintegrität geht, ist ECC RAM unverzichtbar, da die Daten ja immer über das RAM gehen und kein System, auch kein Filesystem erkennen kann, wenn sie dort verfälscht werden nachdem sie gelesen wurden oder bevor sie geschrieben werden. Aber dies fällt unter Silent Data Corruption und ist ein anderes Thema als die UBER, denn jede HDD hat hinter jedem physikalischen Sektor eine ECC um gekippte Bits erkennen und innerhalb bestimmter Grenzen auch korrigieren zu können. Das ein Fehler unerkannt bleibt, ist extrems unwahrscheinlich, selbst bei SATA gibt es eine CRC32 pro FIS, wobei ein Datenpaket bis zu 8192 Byte Nutzdaten enthalten kann, die Wahrscheinlichkeit das eine CRC32 über 8192 Byte, auch hier ist die Wahrscheinlichkeit das ein Fehler unerkannt wird, extremst gering, es müsste ein Vielfaches der insgesamt je produzierten HDD Kapazität zigfach gelesen werden bis sowas mal vorkommen könnte.

HDDs liefern also nicht einfach heimlich falsche Daten, sondern einen Lesefehler statt der Daten zurück, es gibt zwar Ausnahmen, aber die sind hier nicht relevant, da man diese normalerweise nicht für Datenspeicherung verwendet, sondern eben für Echtzeitvideoaufzeichnungen oder eben SAS RAID Controller mit SAS Platten, wo dann der Controller die Platte so konfiguriert das er Rohdaten bekommt und selbst die Verantwortung für die Fehlerkennung und -korrektur übernimmt. FW Bugs, sowas gab es auch schon bei SAS RAID Controller und auch bei SATA HDDs, sind da eher ein Problem, aber auch ein seltenes.

Sehr viel wahrscheinlicher dürfte es sein, dass die Software die den Lesevorgang angefordert und dann den Lesefehler bekommen hat, diese nicht richtig verarbeitet. Bei einem Videoplayer ist es normal und richtig, wenn er den Fehler übergeht und versucht die nächsten Daten zu lesen, dann steht vielleicht das Bild kurz oder der Tone knackt mal eben, aber dies ist immer noch besser als wenn die Wiedergabe mit einer Fehlermeldung abbrechen würde. Aber es gibt auch Kopierprogramme die so reagieren (unstoppable copy oder sowas) und wenn man damit so eine Videodatei kopiert, ist das ja auch gut, aber bei anderen Dateien wie z.B. zip Archiven führt sowas dann natürlich zu korrupten Zieldateien und die Datenkorruption bleibt unbemerkt, aber dies liegt dann eben an der Software und nicht der Hardware!
 
Lesefehler lassen sich nur über Redundanz das Dateisystems verhindern. Da sollte man mal die Realität akzeptieren. Vor der Festplatte wäre da auch mal über den breiten Einsatz von ECC RAM zu diskutieren.
Leider sparen alle NAS Hersteller beim Einsteiger Segment nach wie vor bei ECC, teilweise so abenteuerliche 1 - 2 GB RAM und dann nicht mal ECC... Ist ja nicht so das ECC teuer ist... aber mit irgend einem abgewrackten Celeron halt wohl nicht immer drin.
 
Unsinn! Wieso muss die Redundanz vom Dateisystem sein? Die Redundanz von einem echten (also keinem RAID 0) klassischem RAID funktioniert genauso, denn jede vernünftige RAID Lösung wird bei einem Lesefehler von einer der Platten in der Form reagieren, dass es die Daten mit Hilfe der Redundanz rekonstruiert und den betroffenen Bereich der Platte die den Lesefehler gemeldet hat, dann auch direkt überschreibt.
Soweit ich das verstanden habe: Wenn Fehler von den Platten nicht gemeldet werden (was durchaus häufig vorkommt), kann normales RAID eben nicht für Datenintegrität sorgen. Die Datenkorruption kann nicht wiederhergestellt werden, weil das RAID eben nicht weiß, welches jetzt die korrekten Daten sind (gibt ja kein Checksumming)

Gute Erklärung warum Hardware RAID praktisch tot ist

Kläre mich gern auf, wenn ich was falsch verstanden habe.
 
Soweit ich das verstanden habe: Wenn Fehler von den Platten nicht gemeldet werden (was durchaus häufig vorkommt), kann normales RAID eben nicht für Datenintegrität sorgen. Die Datenkorruption kann nicht wiederhergestellt werden, weil das RAID eben nicht weiß, welches jetzt die korrekten Daten sind (gibt ja kein Checksumming)

Gute Erklärung warum Hardware RAID praktisch tot ist

Kläre mich gern auf, wenn ich was falsch verstanden habe.
Es ist nicht tot, es muss nur richtig gemacht werden und RAID ist auch kein Ersatz für Backups. Es ist nur Redundanz und das diese kaputt geht/gehen kann ist normal. Das kann dir auch mit einem Computer passieren und einem Software RAID. Die Modernen Hardware RAIDs verwenden SmartRAID, dabei wird auf den Datenträgern selbst die Konfiguration für die Rekonstruktion hinterlegt.

Im Server Bereich z. B ist es preiswerter eine Pufferbatterie für RAID+Datenträger zu Verfügung zu stellen um beim abrupten Stromausfall noch die letzten Daten fertig zu schreiben.
Auch eine USV oder Pufferbatterie ist nicht unfehlbar, aber halt zusätzliche Redundanz/Schutz. Wer erzählt Hardware RAID ist aus, arbeitet nicht oder noch nie mit kritischer Infrastruktur oder sowas zu tun gehabt, wo es wichtig ist das die Systeme laufen und wenig Fehler passieren.

Die Meisten RAIDs sterben weil die Temperatur im Betrieb zu heiß ist und an dem Punkt können auch konventionelle Platten Probleme bekommen.
Was soll man sagen gegen Bananendatenträger kann man nichts machen, da hilft das Beste System nicht. Sensoren müssen "verlässlich'" sein.
Schaut man sich Fukushima an und deren Reaktorunfall... ist es passiert mit all ihrer Redundanz und wissenschaftlicher Messinstrumente.

Wichtig ist das man zumindest technisch alles versucht um Fehler einzudämmen.
Ich meine was macht den ein RAID-Controller effektiv?
Der ist Man in the Middle und verarbeitet eingehende Daten...
Genau diesen Man in the Middle hast häufiger in der gesamten Speicherkette. Du musst sicherstellen das alle Vermittler integer sind.
 
Zuletzt bearbeitet:
wie hättest du sie gerne gemessen? Indirekt lassen sich Schlüsse darauf auch über die CDM8 IOPS erzielen. Auf den HDTune-Screenshots befinden sich auch Angaben zur Zugriffszeit.
 
wie hättest du sie gerne gemessen? Indirekt lassen sich Schlüsse darauf auch über die CDM8 IOPS erzielen. Auf den HDTune-Screenshots befinden sich auch Angaben zur Zugriffszeit.
 
Wäre schön, wenn die vergleichbar großen Platten (18-20TB) der anderen Hersteller auch in den Benchmarks vertreten wären.
 
Zuletzt bearbeitet:
Leider sparen alle NAS Hersteller beim Einsteiger Segment nach wie vor bei ECC
Ja, die wollen die teuren Modelle verkaufen und generell ist die Hardware von Fertig-NAS immer überteuert, man zahlt halt für den Support mit.
teilweise so abenteuerliche 1 - 2 GB RAM und dann nicht mal ECC...
1 oder 2GB RAM sind zwar sehr wenig, aber im Zusammenhang mit none-ECC RAM sogar besser als viel RAM, denn je mehr RAM man hat, umso wahrscheinlicher sind RAM Fehler.

aber mit irgend einem abgewrackten Celeron halt wohl nicht immer drin.
Das zum einen, aber leider gibt es auch Modelle bei denen die CPU durchaus ECC RAM unterstützen würde, dann um diese Fähigkeit beschnitten. Das gab es früher bei einigen Hersteller die Xeon-D oder Atom C2000 CPUs verbaut haben, aber trotzdem keine ECC RAM Unterstützung anboten.

Soweit ich das verstanden habe: Wenn Fehler von den Platten nicht gemeldet werden (was durchaus häufig vorkommt)
Wo kommt die Unterstellung her, es würde häufig vorkommen das Platten Lesefehler nicht melden? Dies ist Quatsch, wie schon beschrieben, haben alle HDDs extra eine ECC hinter jedem physikalischen Sektor und dies ist schon sehr, sehr lange so. Es ist ein Mythos den die ZFS Fans gerne verbreiten, dass HDDs keine Lesefehler melden sondern korrupte Daten liefern würden, der einfach nicht stimmt. Ausnahmen gibt es, z.B. Firmware Bugs wie er zuletzt bei der Samsung HD204UI vor fast 10 Jahren vorgekommen ist, wo es Datensalat geben konnte, wenn NCQ aktiv war und ein Device Ident Befehl geschickt wurde, während zugleich auf die Platte geschrieben wurde. Da wurden also Userdaten im Schreibcache überschrieben und dann lieferte die Platte natürlich nicht die Daten wieder, die mal auf sie geschrieben wurden. Aber so ein FW Bug ist nun wirklich eine seltene Ausnahmen!

Die beiden anderen Möglichkeiten wo Platten inkorrekte Daten liefern sind einmal die Surveillance Platten für Echtzeitvideoaufzeichnung, die dann aber für diesen Zweck mit ganz bestimmten Befehlen, den ATA Streaming Befehlen, angesprochen werden und da hat jeder Befehl einen eigenen Timeout und der Gedanke daher ist, dass ein paar falsche Bytes beim Abspielen eines Videos weniger stören als eine Unterbrechung. Dies Befehle werden aber von einem normalen Windows, Linux etc. niemals zum speichern normaler Dateien verwendet, sondern da werden die normalen ATA Befehle genommen die dies Platten auch unterstützen und dann verhalten sie sich wie jede andere HDD und liefern Lesefehler und keine korrupten Daten.

Der zweite Fall sind die SCSI/SAS Platten die man ja auch auf 520/528 Byte pro Sektor (oder bei 4k entsprechend mehr) Bytes pro Sektor formatieren kann und dies machen die HD RAID Controller um in den zusätzlichen Bytes eine eigene ECC Prüfsumme unterzubringen. Die Platten werden dann so betrieben, dass sie keine eigene ECC Prüfung machen und Daten wie gelesen rausgeben, was den Sinn hat, dass die Platten eben nicht durch wiederholtes Lesen versuchen die Daten doch noch korrekt zu Lesen und damit für Verzögerungen sorgen. Dies Verzögerungen zu vermeiden ist der Sinn der Sache, der Controller prüft seine eigene ECC und wenn er die Daten damit nicht korrigieren kann, dann greift er auf die Redundanz zurück und überschreibt anschließend die fehlerhaft gelesenen Daten auf der betroffenen Platte. Da liefern die Platten selbst dann zwar fehlerhafte Daten, aber die Verantwortung das diese erkannt, korrigiert und eben nicht weitergereicht werden, liegt beim RAID Controller. Dies wurde für Storages mit hohen Performance gemacht um Verzögerungen zu vermeiden. aber die dürften ausgestorben sein, weil heute SSDs dieses Segment beherrschen.

Das HW RAID Controller am Aussterben sind, ist auch richtig, die sind mit ihren kleinen CPUs einfach zu lahm für schnelle SSD, die CPU des Rechners ist um Längen schneller, was kein Kunststück ist wenn man bedenkt wie viel mehr Kerne und Budget bei der Leistungsaufnahme sie hat. Die Linux md SW RAIDs sind daher heutzutage meist schneller als HW RAID Controller, die Windows SW RAIDs waren immer dafür bekannt lahm zu sein, keine Ahnung ob dies noch stimmt, aber die Windows Systeme sind wohl noch die die am meisten HW RAID Controller verwenden.

Der Typ in dem Video verbreitet auch den Unsinn das HDDs einfach so mal unerkannt andere Daten zurückliefern würden als geschrieben wurden, ohne dafür Beweise zu liefern und dies ist einfach nicht wahr. Keine Ahnung woher diese Mythos kommt, aber wenn man kein ECC RAM hat, dann kann es natürlich passieren und man weiß nicht sowieso, denn man erfährt ja nicht das es ein RAM Fehler war und die meisten geben dann der HDD die Schuld, was aber eben nicht stimmt. Die guten HDDs und SSDs wie diese Enterprise HDDs haben alle internal data path protection auch end-to-end data path protection genannt, so dass auch auf deren internen Datenpfade und in deren Cache keine Bitfehler auftreten können, andere haben oft wenigstens eine Erkennung solcher Fehler und melden dann in den S.M.A.R.T. Werten das der Zustand schlecht ist, sobald auch nur ein solcher Fehler erkannt wurde und sowas ist wirklich extrem selten.

Der erste Schritt für alle die sich Sorgen um unerkannte Datenkorruption machen, muss immer ECC RAM (mit der passenden Plattform die dies auch unterstützt) sein und damit wird man das Problem dann schon zu bestimmt 99,9% vermeiden! Obendrauf noch ein Filesystem wie ZFS zu nutzen um das Risiko weiter zu senken, wenn auch auf Kosten der Performance, steht ja dann jedem frei, aber bitte kein ZFS als Ersatz für ECC RAM ansehen!. Es sollte auch klar sein, dass man keine absolute Sicherheit bekommt, sondern nur mehr oder weniger große Wahrscheinlichkeiten. Auch Matt Ahren, Mitentwickler des ZFS-Dateisystems, schreibt:
Man beachte die Reihenfolge, auch er empfiehlt zuerst ECC RAM und dann erst oben drauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!
 
Schön das auf die technische Messung eingegangen wird. Welche Messmittel und wie es durchgeführt wurde.

Enttäuschend das die Verbrauchswerte über circa 10 Jahre gleich geblieben sind.

Ich hoffe doch nicht, das diese Review Samples von Redaktion zu Redaktion gehen und dann verlost werden an die Gewinner
 
Festplatten für Gewinnspiele sind immer frisch und keine gebrauchten Sample :)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh