News Western Digital: Helium-HDDs mit 12 und 14 TByte im 8-Platter-Design

@Holt
Die HDD Hersteller haben die Chance mit neuen Technologien wie H(A)MR und könnten so die Datendichte deutlich steigern, womit die Kapazitäten weit stärker als die Preise steigen dürften

Es würde ja reichen, wenn die Kapazitäten steigen, aber die Kosten nicht so stark. Dann wird es so ja auch Billiger. Also Cent pro Gig.

Nur erwartet man derzeit, dass bei 128 Layer dann ein wirtschaftliches Limit erreicht wird

Die frage ist, bei welchen Größen sind wir dann? Wenn dieses Limit dann bei willkürliche Zahl. 900 TB liegen würde. Wäre das wohl den meisten egal. Ich denke, wir reden da auch von einem Luxusproblem.

Die Datenmenge steigt keine frage aber die Steigerungen stagnieren auch irgendwann mal. Bzw die kurven flachen ab.


Bei SMR und Helium frage ich mich vor allem wie es mit der Zuverlässigkeit steht. Wenn man viel Geld ausgibt. Und die Platten halten dann auch nur 2-5 Jahre wie aktuelle für ein Bruchteil des Preises. Bei SSD erwarte ich ja auch eine höhere Ausfallsicherheit. Bei HDDs ist es ja nicht ob sondern wann es Sie erwischt.
 
Bei SMR und Helium frage ich mich vor allem wie es mit der Zuverlässigkeit steht.
Dass das Helium nicht entweicht, ist zumindest in der Luftfahrt (Cockpitinstrumente) kein Problem (von der Dichtigkeit her gesehen). Und das seit über 60 Jahren...

Und da, wo kein Helium entweichen kann, kann nichts Anderes rein (Stickstoff- und Sauerstoffatome sind größer* und Wasserstoff (Atom ist kleier) kommt eh nur als Molekül (H2) vor). Selbst wenn durch eine kleine Undichtigkeit Heliumatome nach und nach entweichen können (müsste Überdruck vorhanden sein), so ist nicht gesagt, dass Fremdgase eindringen (man stelle sich das Loch wie eine Zimmertür vor, eine Person (Heliumatom) passt durch, ein PKW (Stickstoff- oder Sauerstoffmolekül) hingegen nicht).

* Kommen aber nicht alleine vor, sondern als Molekül "zu zweit" oder manchmal sogar als "Dreierpack".
 
Zuletzt bearbeitet:
Zunächst wer heute noch RAW dem DNG Format vorzieht hat kein Problem mit Geld und Speicher. ;P und ja mich nervt es auch das die neuen Festplatten kaum eine Wirkung auf den Preis der keinen haben. Das lieg wohl daran das der Markt für Enterprise Platten unabhängig von dem für Konsumenten ist. Daher finde ich auch immer so Aussagen lustig wo irgendein Institut darüber berichtet das alle in dir Cloud gehen, die Nachfrage nach Speicher stinkt... Ja wen wundert es wenn die Preise nicht runter gehen. Nicht jeder kann und will sich Festplatten zu Ferrari-Preise zulegen. :(
 
NobodysFool schrieb:
Denn in einem RAID-6 hat man immer noch 1 x Daten + 2 x Parity. Ist ein Datensatz korrupt, egal welcher, dann lässt sich immer noch feststellen, wenn die anderen beiden zusammenpassen
Du hast da genau wie tek9 ein grundsätzliches Verständnisproblem. Denn was Du da von ihm zitiert hast, ist sowieso Quatsch:
Ab 12tb besteht ein nicht unwahrscheinliches Risiko das sich Bitfäule (Silent-Data-Corruption)in ein RAID 6 einschleicht und ein Restore auf ein Hot Spare oder Ersatzplatten fehlschlägt
Erstens hat die UBER nichts mit Bitfäule, also Silent-Data-Corruption zu tun. Denn wenn ein Lesefehler passiert, ist dies nicht Silent, sondern es gibt eine Fehlermeldung von der Platte und daher hat UBER mit Silent-Data-Corruption schon mal nichts zu tun und man muss auch nicht feststellen welche Daten betroffen sind, dies erfährt der Host Controller sofort. Bei einem RAID 6 wo nur eine HDD ausgefallen ist, kann er dann wie bei einem normal laufenden RAID 5 diese Daten aus den Daten der anderen Platten, also auch der verbliebenen Parity, wieder rekonstruieren und wird den Sektor auf der Platte überschreiben, die den Lesefehler gemeldet hat.

Obendrein ist dfie Aussage von tek9 natürlich Quatsch, dass diese ab 12TB wahrscheinlich passiert, denn dies trifft nur bei HDDs mit einer UBER von 1:10^14 zu, bei einen HDD mit einer UBER von 1:10^15 ist es eben erst alle etwa 120TB gelesener Daten wahrscheinlich, sofern die Platten innerhalb der Spezifikationen betrieben werden.

NobodysFool schrieb:
läuft einen Restore und hat somit wie erwähnt nur zwei Datensätze zum Abgleich. Stimmen die nicht überein lässt sich nicht sagen was stimmt.
Ein echtes RAID vergleich gewöhnlich die Parity nicht, nur diese Geschichten wie die RAID Z bei ZFS machen das laufend weil die für Hysteriker sind. Normale RAIDs wie auch das Linux md SW_RAID lesen die Parity nur wenn sie diese wirklich brauchen, es also einen Lesefehler gab, ein Rebuild oder Scrubbing erfolgt. Das ist performanter und da HDDs eben gewöhnlich die falsche Werte liefern außer bei Fehlern auf den internen Datenpfaden, sondern Lesefehler statt korrupter Daten zurückliefern, ist es auch nicht nötig.

Richtige SAS/FC HW RAID Controller arbeiten noch anderes, die formatieren die Platten auf 520 oder 528 Byte pro Sektor und schreiben in diese zusätzlichen 8 oder 16 Byte ihre eigene Prüfsumme für den Sektor und können so jeden Lesefehler sofort selbst erkennen und entsprechend reagieren, die korrekten Daten also aus denen der anderen Platten rekonstruieren und den Sektor wieder überschreiben, womit die Zeit die SATA HDDs dann versuchen die Daten doch noch korrekt zu lesen und damit die TLER Problematik dann entfällt.

Koto schrieb:
Es würde ja reichen, wenn die Kapazitäten steigen, aber die Kosten nicht so stark. Dann wird es so ja auch Billiger. Also Cent pro Gig.
Das hat bei den HDDs bisher immer so funktioniert und ist auch das Ziel von neuen Technologien die HAMR.

Koto schrieb:
Die frage ist, bei welchen Größen sind wir dann? Wenn dieses Limit dann bei willkürliche Zahl. 900 TB liegen würde.
Die Zahl der Layer hat nichts mit TB zu tun und derzeit fertigt Samsung 3D NANDs mit 48 Layern in Großserien, die Fertigung der 3D NANDs mit 64 Layer sollte noch in diesem Quartal anlaufen oder ist es vielleicht sogar schon. Das ist auch kein Luxusproblem, sondern ganz konkret ein Problem wenn es darum geht wie billig die NANDs überhaupt letztendlich werden können, also auch ob die jemals pro GB günstiger als HDDs werden oder nicht.

Koto schrieb:
Die Datenmenge steigt keine frage aber die Steigerungen stagnieren auch irgendwann mal. Bzw die kurven flachen ab.
Derzeit ist die Kurve der Steigerung des weltweiten Datenvolumens noch keineswegs am Abflachen, sondern im Gegenteil ansteigend und gar nicht so knapp. Abflachend ist die Kurve der Steigerung der GB pro $, die Kosten zu senken wird immer schwerer und irgendwann an ein Limit stoßen.

Koto schrieb:
Bei SMR und Helium frage ich mich vor allem wie es mit der Zuverlässigkeit steht.
SMR sollte in der Hinsicht kein Problem sein, außer das eben die Daten auf den Platten noch dichter zusammen stehen, aber wenn die Datendichten weiter steigen, passiert dies ja sowieso. Wie gut die Dichtigkeit der mit Helium gefüllten HDDs ist, wird man sehen müssen, aber es düfte auch von der Behandlung der Platten abhängen, die werden wohl noch empfindlicher z.B. auf Kratzer sein.
Koto schrieb:
Wenn man viel Geld ausgibt. Und die Platten halten dann auch nur 2-5 Jahre wie aktuelle für ein Bruchteil des Preises.
Platten für einen Bruchteil sind aber dann meist einfache Desktopplatten und die sind nur für einfach Desktopanwendungen, worunter die HDD Hersteller maximal 2400 Betriebsstunden (Power On Hours) pro Jahr, maximal 55TB Workload (gelesenes plusgeschriebenes Datenvolumen) pro Jahr und nur eine HDD im Gehäuse verstehen Wenn die dann auch im Dauerbetrieb z.B. in einem NAS laufen, dann haben die nach 2 Jahren mehr Stunden runter als in über 7 Jahren bei der vorgesehenen Nutzung und fallen dann eben öfter aus.
Koto schrieb:
Bei SSD erwarte ich ja auch eine höhere Ausfallsicherheit. Bei HDDs ist es ja nicht ob sondern wann es Sie erwischt.
HDDs sind auf ein Service Life (Nutzungsdauer) von 5 Jahren ausgelegt, sie sind unter optimalen Umständen maximal ein Jahr lagerbar und somit ab 6 Jahre nach dem Produktionsdatum als Schrott zu betrachten und laufen wenn sie noch laufen praktisch auf Abruf. Vor 20 oder 30 Jahren war das noch anderes, da waren aber nicht die Kapazitäten sondern auch die Technik noch ganz anderes, nur seht man ihnen die Unterschiede eben nicht an. Das z.B. die Köpfe von HDDs schon lange im Teilkontaktbereich betrieben werden, erzählen die HDD Hersteller ja auch gar nicht öffentlich.
 
Dein überlanger Beitrag stinkt schwer nach Besserwisserei.

Ich habe einen Artikel gepostet der genau das besagt was ich geschrieben habe.

Die CT hat auch mal einen Artikel gedruckt der das Problem von RAID 6 und Arrays ab 12tb behandelt hat.

Du hingegen hast bisher keine Quellen für deine Behauptungen parat.
 
Derzeit ist die Kurve der Steigerung des weltweiten Datenvolumens noch keineswegs am Abflachen, sondern im Gegenteil ansteigend und gar nicht so knapp.

Ich bezog mich da auch eher auf den Privatbereich. Und eben nicht Datenvolumen insgesamt sondern eben Offline Speicher im Privatbereich.

Beispiel:
Wenn ich Filme & Serie Sammle. Hat man anfangs eine enorme Steigerung. Irgendwann hat man die meisten Sachen und die Steigerung geht klar zurück. Seit den man hebt wirklich jeden mist auf. :-)

Oder wer die Welt bereist. Filme & Bilder erzeugt. War irgendwann schon fast überall.

@all
Also so große Raids würde ich auch nicht machen. Die Gefahr das bei den ewig langen Rebuilds das dann Platten ausfallen. Wäre mir zu hoch. Ich mein beim Normalen Backup kopiert man eben nur eine Platte im Raid werden alle Platten belastet.

Gerade im Privat Bereich sehe ich auch den Sinn von Raid nicht wirklich. Ich mein 5 Minuten eine Platte zu tauschen die platt ist. Die Zeit hat wohl Privat jeder. Und ein Raid ist in der Tat kein Backup.

Natürlich rede ich nur von Privat. In der Industrie usw sieht das natürlich anders auch.
 
tek9, wenn Du einem Doc Storage mehr glaubst, der sich auch noch als Fan von ZFS outet und von RAM Fehlern und ECC RAM überhaupt nicht redet, dann ist das Deine Sache. Wenn ein Bit einer Datei gekippt ist, dann lag es jedenfalls nicht an der UBER, denn HDDs haben wie die SSDs alle eine ECC hinter jedem Sektor, erkennen Fehler bei den Daten also und wenn sie die nicht korrigieren können, geben sie keine korrupten Daten sondern einen Lesefehler aus, andernfalls wüssten ja RAID Controller bei einem Rebuild auch nichts von dem Problem und das Rebuild würde dann auch nicht abgebrochen werden, wenn so ein Fehler auftritt. Statt nach irgendwelche Quellen in Netz zu suchen, man findet dort so ungefähr zu jeder Behauptung etwas, sollte man manchmal auch einfach den Verstand einschalten und selbst überlegen was angehen kann und was nicht.
 
Nochmal, auch wenn Du es kaum begreifen willst: Dies hängt von der UBER ab und die 12TB gelten nur für HDDs mit einer UBER von 1:10^14, wie auch in dem Beitrag bei zdnet steht:
Was schon nicht mehr stimmt, ist der nächste Satz:
Es gibt nämlich keine Garantie auf das Eintreten so eines Fehlers, die UBER ist ja auch meist als < oder <= angegeben und damit bedeutet es nur, dass die HDD noch innerhalb der Spezifikationen ist, wenn das mit der Häufigkeit passiert. Und bei einer UBER von 1:10^15 sollte es nur maximal alle 120TB passieren. Aber wer dazwischen nur unterscheiden, findet eben auch keine Links zu Informationen was passiert, wenn eine HDD einen Sektor nicht mehr korrekt lesen kann und versteht daher auch wohl auch nie, wieso die Einheit der UBER Sektoren/Bits ist, wenn Du der Meinung bist diese würden zu Silent-Data-Corruption führen.

Das Thema ist aber für mich hier durch, da ich klar erwarte, dass WD / HGST Platten mit derartigen Kapazitäten dann mit einer UBER von <= 1:10^15 bringen wird, wie es bei den Enterprise Nearline HDDs üblich ist.
 
MidwayCV41 schrieb:
BTT.: Die Entwicklung gefällt mir. Aber die Preise bei den HDDs pro TB sind generell arg hoch. :( Aber ich muss bald umrüsten und dann eben in den teuren saueren Apfel beissen.
Da fehlt seit 5 Jahren eindeutig der Preisbrecher im Markt, und der war Samsung. Dessen Festplattensparte wurde ja bekanntlich im April 2011 von Seagate übernommen. Mittlerweile sind eindeutig zu wenige Player im Markt (Stichwort "Oligopol"), und die nehmen sich gegenseitig nicht mehr die Butter vom Brot.
 
Holt schrieb:
s gibt nämlich keine Garantie auf das Eintreten so eines Fehlers, die UBER ist ja auch meist als < oder <= angegeben und damit bedeutet es nur, dass die HDD noch innerhalb der Spezifikationen ist, wenn das mit der Häufigkeit passiert.

Das Thema ist aber für mich hier durch, da ich klar erwarte, dass WD / HGST Platten mit derartigen Kapazitäten dann mit einer UBER von <= 1:10^15 bringen wird, wie es bei den Enterprise Nearline HDDs üblich ist.

Es garantiert dir auch keiner das der Fehler nicht eintreten wird ;)

Das du etwas erwartest ist schön. Mal schauen ob deine Erwartungen erfüllt werden.
 
Also auf WD gold warten für den neuen server... (Haben 10^15 uber, afaik)

Ps: wenn das raid 5 keinen Sinn ergeben soll, was ist dann mit einem single disk setup? Da sind ja die Daten einfach futsch.. ???
 
winni71 schrieb:
Bei Synology funktioniert bislang nur die automatische Korrektur nicht, manuell geht das schon (stellt sich dann natürlich die Sinnfrage, wenn man immer erst prüfen und dann ggf. korrigieren muß, ein NAS sollte sowas ohne Zutun des Anwenders können)
Mit der Beta von DSM6.1 geht nun auch automatische Korrektur, allerdings nicht in jedem Setup:
---
File Self-Healing

DSM is now capable of detecting and repairing silent data corruption if your Synology NAS meets the following criteria:
Running Btrfs file system
Built on RAID 1, RAID 5, RAID 6, RAID 10, or non-1 disk SHR
Without any SSD read-write cache mounted (This limitation will be removed in the coming release.)
---

Danke für den Hinweis! Ich hatte darauf gehofft, dass diese Funktionalitäten nachgereicht werden. Daher stand für mich schon fest, dass derzeit ein NAS nur von Synology in Frage kommt, da dieses bereits Btrfs unterstützt. QNAP hat hier definitiv Nachholbedarf.
 
Sharangir schrieb:
wenn das raid 5 keinen Sinn ergeben soll, was ist dann mit einem single disk setup? Da sind ja die Daten einfach futsch.. ???
ja, dann sind die Daten futsch die auf dem betroffenen Sektor gestanden haben und dies kann im schlimmsten Fall wichtige Metadaten des Filesystems treffen und dann ist mehr als eine Datei betroffen, ob ZFS/btrfs dagegen helfen? Ich früchte eher nicht, da diese Filesysteme ja auch gleich eine RAID Funktion integriert haben und ein RAID 5 ist eben auch dann nicht sinnlos, wenn die Chancen auf ein Rebuild gering sind. Dann wenn ein Lesefehler auftritt, denn gehen bei einem echten RAID (also keinen RAID 0, dem ja die Redundanz fehlt für die das R in RAID steht) keine Daten verloren, sondern die werden über die Redundanz rekonstruiert und der betroffene Sektor wird auch sofort wieder überschrieben. Bei einer einzelnen Platte geht das nicht, außer man verwendet einen deutlichen Teil ihrer Kapazität für eine interne Redundanz.

Im übrigen ist die Wahrscheinlichkeit ein RAID 5 mit 12TB Platten zu rebuilden bei HDDs mit einer UBER von 1:10^15 durchaus sehr gut, sogar besser als bei 2TB HDDs die nur eine UBER von 1:10^14 haben.
 
Ich verstehe die ZFS Hater nicht wirklich.

Was gefällt euch nicht an diesem Filesystem?

Es kann quasi unbegrenzte Kapazitäten verwalten und entdeckt Fehler durch parity checks.

Das ist doch genau das was alle immer wollten?
 
Es sollte aber unbedingt auf einer Plattform mit ECC RAM laufen und man kann die Pools nicht um weitere Platten erweitern, die werden nur wie ein JBOD angeklebt, aber nicht wirklich integriert. Außerdem frisst es mächtig Resourcen und löst Probleme die man nicht hat, wenn man ein ordentliches System mit ECC RAM verwendet, denn Bit faulen nicht einfach auf den HDDs, wie es die Verfechter von solche Filesystemen den Leuten immer wieder einreden wollen, in Wahrheit ist das Fehlen von ECC RAM der Hauptgrund für korrupte Daten und nicht die Platten. Bzgl. der Kapazität die auch ein normales Linux md SW RAID mit ext4 drauf verwalten kann, komme ich auch noch längst nicht an die Grenzen dessen, was ich brauche. Filesysteme wie ZFS brauchen Heimanwender nicht und wenn sie dann fatalerweise auch noch meine dies als Ersatz für eine ordentliche HW mit ECC RAM und dessen Unterstützung und womöglich gar eines Backups nehmen zu können, haben sie den ersten Schritt zum Totalverlust der Daten schon unternommen.
 
1.Heimanwender haben kein ECC RAM

2. ZFS benötigt kein ECC RAM

3. Steht die Backup Strategie hier nicht zur Diskussion
 
1.) Richtig, deshalb ist dann ZFS (und btrfs) nichts für sie, zumindest wenn sie Datensicherheit wollen.

2.) ZFS läuft auch auf Systemen ohne ECC RAM, leider, denn es wurde für Systeme mit entwickelt und verlässt sich darauf das die HW für die Korrektheit der Informationen im RAM sorgt. Ist dies nicht der Fall, kann es eine die Daten noch wahrscheinlicher korrumpieren als andere FS, denn bei normales md SW RAID mit z.B. ext4 drüber. Denn dies prüft beim Lesen die Paritätsdaten gar nichts, anders als es ZFS macht. Kippt dabei als ein Bit im RAM bekommt der User die Datei korrupt wieder, ein Risiko wovor ihn nur ECC RAM und kein FS schützen kann. Kippt aber bei ZFS mit Fehlerkorrektur ein Bit in den zusätzlich gelesenen Paritydaten, dann hält es die eigentlichen Daten für korrupt und korrigiert sie, was dann eine Kaputtkorrektur ist, Daten die vorher korrekt waren, sind es danach nicht mehr. Bei einem md-SW RAID würde sowas nur passieren, wenn die Partity wegen seines Lesefehlers an der Stelle oder eines Rebuilds gelesen werden muss. Betrifft die Datenkorruption die Metadaten des Filesystems, welche bei ZFS noch viel umfangreicher als bei anderen OS sind, denn kostet es einen den Pool und es gibt kein Tool dies zu reparieren, denn die Profis für die ZFS gemacht wurde, spielen dann ihr Backup ein, weil sie die Zeit kennen die das dauern wird, aber nicht abschätzen können wie lange ein Repair dauern könnte und vor allem ob es gelingen würde. Profis machen aber viel frequenter und konsequenter Backups als die allermeisten Heimanwender.

Es wird von Leute die meinen man könnte ZFS ruhig auch ohne ECC RAM einsetzen ja immer gerne ein anderer Teil von Matt Ahren zitiert:
Will man es wirklich als qualitative Bewertung verstehen, kann es nur auf ZFS ohne automatische Fehlerkorrektur oder als Verteidigung seiner Mitschöpfung gesehen werden. Viel eher muss man es einfach so auslegen, dass es ohne ECC RAM egal ist, weil kein Filesystem dann vor Datenkorruption schützen kann. Diese auch schon beim Kopieren der Daten z.B. vom Netzwerktreiber ins RAM auftreten kann, also noch bevor das Filesystem Zugriff darauf bekommt.

Die Antwort darauf verweist auf diesen Beitrag im Freenas Forum:
Check out this thread - http://forums.freenas.org/index.php?thr ... zfs.15449/

Note specifically the behavior of ZFS scrubs, rsyncs, and ZFS replication with respect to memory errors. The potential for loss of data with ZFS is quite a bit greater than with UFS, EXT, NTFS (perhaps not with btrfs) without ECC RAM.
Da kannst und solltest Du mal nachlesen wie genau RAM Fehler was bei ZFS anrichten was bei andere Filesystemen wie NTFS oder ext so nicht passiert und fürchte bei btrfs dürfte es sehr ähnlich laufen. Ich will nicht alles zitieren, nur die Schlussfolgerung:

3.) Eigentlich nicht, aber s.o. und leider verwechseln viele auch die Snapshots mit Backups.

Also nichts gegen ZFS oder btrfs, wenn man die passende HW dazu hat, also welche mit ECC RAM und natürlich auch eine Unterstützung dafür, denn ECC RAM Riegel in ein Board zu packen welches kein ECC RAM unterstützt geht bei Unbuffered ECC RAM zwar meisten, bringt aber gar nichts da die zusätzlichen Bits dann nur sinnlos in der Luft hängen. ECC RAM sollte man sowieso haben, wenn man eine besseren Schutz vor Datenkorruption haben möchte als Consumer HW sie bietet, da kann man dem Matt Ahren nur zustimmen:
Additionally bedeutet oben darauf und an anstelle! Solche HW die ECC RAM unterstützt hat auch an anderen Stellen mehr Schutz vor Bitfehlern, man schau sich z.B. mal die Übersicht der Intel NICs an:
intel-ethernet-controller-ecc-png.531765


Oder schau Dir die Übersicht der RAS Features verschiedener Intel Plattformen die ECC RAM unterstützen an, dann sieht man das es da noch viel weiter geht und je mehr Sicherheit man möchte, umso aufwendiger wird es:


Das gleich gilt auch für HDDs, die Enterprise HDDs (wie die um die es hier geht) haben in aller Regel einen Schutz der internen Datenpfade, die HW RAID Controller für Profis haben ECC RAM als Cache und genau da liegen die Risiken das von einer Platte wirklich mal unbemerkt Daten mit einem falschen Bit kommen, nicht bei der UBER.
 
Was würdet ihr auf einem Xeon D mit 16X SAS + 10 10GBe + 64 GB ECC Ram einsetzen? Aktuell rennt Server 2016 Datacenter, die Frage is ob ich vllt nen Hypervisor drunter bau oder Hyper V / VMware ESX nehme und den LSI durchreiche + da nen ZFS aufsetze.

Muss mich ma schlau machen ob das der HyperV zwischenzeitlich gut beherrscht, das Durchreichen eines Speichercontrollers.

Edit:

Interessant
https://www.hardwareluxx.de/community/f101/microsoft-hyper-v-stammtisch-1114189-6.html#post25006936

-> hab ja den onboard 16x LSI und nen LS 9260 8i der grad die Hauptarbeit hat. Glaub ich reich mal den OnBoard testweise an ne ZFS Nas durch. Vllt nas4free?
 
Zuletzt bearbeitet:
Zurück
Oben