Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsWestern Digital OptiNAND: Integrierter Flash-Speicher soll 50-TB-HDDs ermöglichen
Sehr interessant. Aber bitte dann mit Schreibcache. Gerne so ab 64GB aufwärts. Sollte nicht so teuer sein. 256GB gibt es als Endkunde für rund 30 Euro. Da sollten 64GB den Hersteller um die 3-4 euro Kosten. Dann könnte ich auf SSDs die nächsten 10 Jahre als Datengrab verzichten. Aber nur 50TB bis 2030, das ist dann wirklich wenig. Vor 8 Jahren gab es doch schon Platten mit 4TB oder? Also Faktor fünf in 8 Jahren. Und jetzt Faktor 2,5 nicht gerade toll.
Spannend zu lesen das es doch noch bei HDDs eine Weiterentwicklung gibt. Für Anwendungsbereiche mit großen Datenmengen wohl noch eine Chance. Für mich als Heimanwender aber kommt nie mehr eine HDD in ein Computer.
Das machten doch die SSHDs auch (und sind ausgestorben).
Und außerdem, wer sowas will, kann auch schon lange HDD und SSD per Software kombinieren (bei Apple Fusion Drive, unter Linux bcache und Konsorten).
Im Normalbetrieb wäre es auch schade, 64GB ausgerechnet nur als Schreibcache zu vergeuden.
Leute hab ich es jetzt überlesen oder haben sie nicht mal schreib und lese Geschwindigkeiten angegeben? Oder ist hier das Ziel mehr Speicher? Dann versteh ich allerdings nicht so ganz warum man Nand braucht
Das machten doch die SSHDs auch (und sind ausgestorben).
Und außerdem, wer sowas will, kann auch schon lange HDD und SSD per Software kombinieren (bei Apple Fusion Drive, unter Linux bcache und Konsorten).
Im Normalbetrieb wäre es auch schade, 64GB ausgerechnet nur als Schreibcache zu vergeuden.
SSHDs waren damals auch sehr teuer gewesen da der NAND noch sehr teuer war. Aber wenn ich heute ein HDD für 300 Euro kaufe und mich der NAND in der Platte 10 Euro Aufpreis kostet ist das fast ein Witz. Was haben damals SSHDs als Aufpreis gehabt? Waren das nicht bei gleicher Kapazität gerne Mal 20% oder mehr.
Ich habe unter Windows Primocache ausprobiert war schon nicht schlecht. Aber so 100% überzeugt hat es mich auch nicht.
Für mich wäre ein Schreibcache von 64GB gerne auch 128GB super. Ich habe öfter Workloads wo ich zwischen 15 und 60GB speichern muss. Und in Zukunft werden es auch sicherlich mehr. Da wäre so ein Cache auf der Platte Perfekt.
Liest sich für mich ehrlich gesagt eher wie ‘ne Nebelkerze.
“Wir bauen das Raumschiff Enterprise. Ernsthaft. In 10 Jahren isses fertig. …. und hier ist schon mal der Overall des Captains!”
Liest man die Blog-Eintrag wird auch klar, dass das ganze nur eine von weiteren Komponenten ist, die diese 50TB ermöglichen sollen, während wir immer noch nicht wissen, was bei WD nun mit den dafür viel essentielleren Technologien HAMR und MAMR los ist.
Btw… hat Seagate uns nicht schon im März dank HAMR für 2030 100TB in Aussicht gestellt?
Nene, WD… also da sind Eure 50TB aber ganz schon fantasielos. Tststs.
Future roadmap
This certainly isn’t the endpoint, but the first waypoint on a roadmap of features and product updates Western Digital plans to implement. As it is, Hall and other leaders at Western Digital are expecting the capacity for an individual drive to reach 50TB before the end of the decade.
Alle noch eingesetzten Nicht-COW-Dateisysteme haben Journaling für Metadaten, um das Dateisystem bei einem Stromausfall in einem konsistenten Zusatand zu halten - also damit das Dateisystem weiß, welche Datei beim Stromausfall nicht zuende geschrieben wurde. Journaling für die eigentlichen Nutzdaten bietet aber nur ext4 optional und auch auf den meisten Systemen, die ext4 benutzen, werden sie "ordered" und nicht "data" eingehängt. (Journaling FileSystem & Its 3 types) Bei ordered werden zwar erst die Dateinhalte und danach der Journal-Eintrag geschrieben, wenn aber die Datei gerade nicht neu erstellt sondern geändert wird, kann es passieren, dass diese Datei und zwar sowohl die alte als auch die neue Version flöten ist.
Dieses Problem löst ausschließlich Copy on Write, was du entweder auf Software-Ebene implementieren kannst oder, wie eben bei ZFS, btrfs und ReFS der Fall, im Dateisystem selbst und genau deswegen werden COW-Dateisysteme eingeführt - die Integration des Volume-Managers ist nur ein zweites Thema, das man gleichzeitig angeht. Deswegen wird auf OpenSuse seit einigen Jahren schon die Systempartition standardmäßig in btrfs formatiert, obwohl man dort die Userdaten nachwievor lieber XFS anvertraut - in der Konfiguration kann man den Volumemanager von btrfs gar nicht nutzen, da gehts um Copy on Write.
Bei ordered werden zwar erst die Dateinhalte und danach der Journal-Eintrag geschrieben, wenn aber die Datei gerade nicht neu erstellt sondern geändert wird, kann es passieren, dass diese Datei und zwar sowohl die alte als auch die neue Version flöten ist.
Ich kenne in der Hinsicht nur das alte "Neu geschriebene (intern durch mv atomar ersetzte) Datei hat nach Crash 0 Bytes Länge"-Problem, das aber alle Dateisysteme seit über 10 Jahren gefixt haben.
Deine Aussage ist auch nicht so recht nachvollziehbar. Ohne CoW wird einfach ggf. mitten in das Extent der Datei (bei Ext4) reingeschrieben. Das klappt oder eben nicht, aber "weg" ist die Datei sicher nicht.
... Ohne CoW wird einfach ggf. mitten in das Extent der Datei (bei Ext4) reingeschrieben. Das klappt oder eben nicht, aber "weg" ist die Datei sicher nicht.
Ich hab nicht gesagt, dass sie "weg" ist, ich hab gesagt, dass sie flöten ist, was sie imho auch dann ist, wenn sie irgendwie da aber mit kaputtem Inhalt ist. Und was bedeutet in deinem Zitat "(intern durch mv atomar ersetzte)" Hast du etwa auf Software-Ebene Copy on Write implementiert und ich hatte gesagt, dass man das kann?
Ich hab nicht gesagt, dass sie "weg" ist, ich hab gesagt, dass sie flöten ist, was sie imho auch dann ist, wenn sie irgendwie da aber mit kaputtem Inhalt ist.
Welchen Mechanismus gibt es denn auf OS-syscall-Ebene, der dem Dateisystem sagen könnte, was genau eine "konsistente Version" einer Datei ist? Und wie sollte das bei Dateisystemen, die Zugriffe auf eine Datei von mehreren Threads aus unterstützen, funktionieren? Und selbst wenn es diesen Mechanismus gäbe, was sollte denn selbst ein CoW-Dateisystem machen, wenn die Anwendung sagt "1. Datei A belegt 100GB von einer 110GB-Partition und ist JETZT konsistent. 2. Bitte 50GB dieser Datei überschreiben. Erst wenn das komplett durch ist, ist die Datei wieder konsistent."? Das geht schlicht nicht. Letztendlich muss die Anwendung (mit Write Barriers und fsync) dafür sorgen, dass das schon passt.
MountWalker schrieb:
Und was bedeutet in deinem Zitat "(intern durch mv atomar ersetzte)"
Das ist Punkt 2 unter https://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data_loss , inzwischen historisch. Insbesondere hatte z.B. XFS genau das Problem auch, viel länger als Ext3/4. (ich hab mich damals auf einem Server damit länger rumschlagen dürfen, bei dem die Stromversorgung nicht topp war)
... Und selbst wenn es diesen Mechanismus gäbe, was sollte denn selbst ein CoW-Dateisystem machen, wenn die Anwendung sagt "1. Datei A belegt 100GB von einer 110GB-Partition und ist JETZT konsistent. 2. Bitte 50GB dieser Datei überschreiben. Erst wenn das komplett durch ist, ist die Datei wieder konsistent."? ...
Was heißt denn Copy on Write? Das Dateisystem verliert seine Konsistenz nie, weil eben niemals 50 GB (oder auch nur 1 b) von einer Datei überschrieben werden und solange der Schreibvorgang nicht absolut abgeschlossen ist, die alte Dateiversion vollständig als "richtige" Dateiversion verfügbar ist. Kommt jetzt wieder "das geht schlicht nicht"?
P.S.
Also in deinem provokativ konstruiertenm Beispiel, ganz klar auf den Punkt gebracht: Die Dateioperation kann nicht ausgeführt werden, weil nicht genug Speicherplatz vorhanden ist - Punkt. Einen zPool mit 110 GiB und einer 100 GiB Datei must du mir aber auch mal im echten Leben zeigen.
Western Digital ist auch im SSD-Markt und im Flash-Markt insgesamt aktiv, insbesondere in Kooperation mit Kioxia. Und aktuell gibt es dort einige Übernahmegerüchte...
→ dass das wie bei Nokia endet, kann nicht mehr passieren. Denn sie haben sich bereits deutlich stärker und vor allen Dingen auch erfolgreich an neue Marktumstände angepasst.
Ich habe doch bereits versucht zu erklären, dass Anwendungen keine Möglichkeit haben, dem Dateisystem mitzuteilen, was eine "Version" einer Datei ist. Ansonsten sag mir bitte den konkreten syscall, den ich wohl nicht kenne.
Klar hat btrfs intern ein eigenes Konzept von Schreibaktionen auf eine Datei, deren Verkettung man irgendwie als "Versionen" verstehen kann, aber mit echter Konsistenz oder Versionierung im Sinne einer Anwendung hat das wenig zu tun. Ist einfach eine ganz andere Ebene. Um bei dem 50GB-überschreiben-Beispiel zu bleiben, btrfs wird diesen großen Write einfach in viele kleine unterteilen und die - völlig unabhängig von irgendeiner Logik der Applikation - jeweils "atomar" rausschreiben. Fällt währenddessen der Strom aus, ist die Datei genau wie ohne CoW teilweise überschrieben. Der einzige Vorteil von CoW in dem Fall ist, dass das Dateisystem beim Neustart kein Journal Replay machen muss, sondern "einfach so" intern konsistent ist, aber das ist eben was anderes als auf Anwendungsebene konsistent.
So kannst Du ja nicht rechnen, kleine HDDs sind einfach verhältnismäßig teuer.
Der "Sweet Spot" liegt gerade bei rund 18€/TB (bei den 4/6TB-HDDs), also nur rund ein Viertel der günstigsten SSDs.
Für den Heimgebrauch ist aber natürlich schon ein Punkt, dass schon 1TB meist völlig ausreicht. Wenn es rein um Platz geht, sind HDDs aber nach wie vor wesentlich günstiger.
Ich ab auch nichts von Backup-Erstellung gemeint, weiß nicht, warum du das so verstanden haben willst.
GrumpyCat schrieb:
Um bei dem 50GB-überschreiben-Beispiel zu bleiben, btrfs wird diesen großen Write einfach in viele kleine unterteilen und die - völlig unabhängig von irgendeiner Logik der Applikation - jeweils "atomar" rausschreiben. Fällt währenddessen der Strom aus, ist die Datei genau wie ohne CoW teilweise überschrieben...
Mag sein, trotzdem sieht man eine klare Entwicklung am Markt und diese ist, dass HDDs aussterben. Klar es gibt immer noch gewisse Kunden für HDDs aber das ist eher die Ausnahme und nicht mehr die Regel. Man sieht es ja an den fertig PCs, dass SSDs dominieren.
