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.
NewsDapuStor R6060: Erste 512-TB-SSD zur Schau gestellt
Ich war bei der Größe der SSD davon ausgegangen, dass die in Geschwindigkeit der Schnittstelle schreiben kann sofern genügend Parallelität vorhanden ist.
Falls nicht wäre das ein Limit des Controller, nicht des NAND, wenn eine 122 TB Version mit 4 GB/s schreiben kann.
AGB-Leser schrieb:
Drei Gigabyte pro Sekunde schreiben.... aber nur bis der SLC-Cache von 40GB voll ist, danach mit 100MB/s
Löst halt nicht die Probleme der nand Fertigung. Das ist einfach linear mehr Chips auf engerem Raum und kanibalisiert alles kleinere darunter die die gleichen Bausteine brauchen. linear mehr Kosten, keine Skalierung mit Größe.
Irgendwann hast dann einen ganzen wafer in so einem Teil verbaut und da die Preise für sowas hinlänglich bekannt sind werden SSDs solcher Kapazitäten niemals in andere nieschen vorstoßen wenn sie die Dichte und die ganzen Probleme damit nicht in den Griff bekommen besonders jetzt wo andere Medien im Segment ihre Dichte sehr schnell erhöhen und Gleizeitig dadurch nicht schlechter werden was die Eckdaten betrifft
Auch wäre spannend wie schnell sie kontinuierlich schreiben kann. QLC ist das eine aber man hat auch viele Chips..
…vier davon hab ich aktuell im NAS und längere Schreibaktionen sind wirklich keine Freude. Im RaidZ1 mit ZFS eher eine Katastrophe, wenn auf dem selben Storage auch noch die VMs gespeichert sind: Teilweise reagieren die dann gar nicht mehr aufgrund eines gigantischen IO-Delays, da kann eine Platte die nicht hinterher kommt das ganze Raid sekundenlang blockieren, mit Schreibraten im niedrigen zweistelligen Bereich. In den VMs geht dann gar nichts mehr.
Als großes, gemountetes Datengrab für überwiegend Lesezugriffe sind die ok, aber für mehr auch nicht…
Und wegen Sicherung sollten es auch gleich Zwei sein falls das Prunkstück mal ausfällt.
Ok die Big Firmen das ist Porto Kasse. Aber ich kann mir vorstellen das ein oder andere Mittlere Unternehmen.
die Regel gilt aber auch schon lange nicht mehr ^^
Zumindest unter FreeBSD kannste einfach den ARC begrenzen und dann ist gut
Ich habe selber im NAS +60TiB Speicherplatz auf diversen RaidZ1 und Z2 Pools und genehmige dem ARC aber auch nur 32GiB meines RAM - meine 20 Jails brauchen ja auch noch etwas Luft zum atmen 😉
Ob das ganze so easy unter ZoL (ZFS on Linux) genauso funktioniert kann ich mangels Erfahrung allerdings nicht sagen...
Irgendwo in einem Umzugskarton habe ich noch einen 1 MB Speicher. Damals so groß wie ca. DIN A5.
Inzwischen eingerahmt. Kostenpunkt damals 100.000,00 DM
Zumal die Beschaffung eines redundanten HDD arrays mit der Größe wo es mittlerweile schon Richtung 40TB platten geht und bald Richtung 50-70 wesentlich billiger geht als mit dieser monstrosität. Den HDDs dieser Größe kosten selbst jetzt in der Speicherkrise so 1400€ und man braucht keine 30 Stück um selbst dreifache Parität mit aktuellen Größen für 1PB herzustellen.
Die SSD hier wird sechsstellig kosten und bis ich mit dem System oben Strom für 60000€ mehr verheizt hab ist jedes dieser Medien tot.
Also im Massenspeicher sehe ich SSDs nicht. Weder jetzt noch in Zukunft. Aber für die Anwendungen für die sie gedacht ist wirds sicherlich sehr schön sein.
Also im Massenspeicher sehe ich SSDs nicht. Weder jetzt noch in Zukunft. Aber für die Anwendungen für die sie gedacht ist wirds sicherlich sehr schön sein.
Ja, oben genanntes Beispiel gilt natürlich nur für Massenspeicher. Einsatzbereich dieser SSD ist sicherlich KI - dort müssen Unmengen an Daten schnell zugreifbar sein und die hohe sequentielle Geschwindigkeit eines HDD-Arrays rettet nichts - KI braucht hohe random Lesespeeds und sehr viele IOPs. Dort kannst Du so eine SSD mit beliebiger HDD-Konfiguration NICHT ersetzen.
V3K1 schrieb:
Zum einmaligem schreiben, um danach nur gelesen zu werden,reichts
Sprich: für stromlos im Schrank liegen ist QLC ebenfalls nicht optimal, auf gut Denglisch:
Nicht nur die Endurance ist bei QLC schlechter, sondern Data Retention ebenfalls.
