News FuzeDrive SSD: Enmotus gießt SLC-Caching-Software in Hardware

[mibbio]

Wofür auch? Der "Clou" ist die Betriebssystemunabhängigkeit.

Weil bisher die Rede davon ist, dass man dafür anscheinend einen speziellen NVMe Treiber braucht, damit das Konzept funktioniert. Und bei der Verfügbarkeit von proprietären Treibern ist es oft sehr dünn abseits von Windows.

 

[Oma Erna]

Was wollen sie immer mit maschinellen Lernen? Nutzhäufigkeit lässt sich doch prima mit klassichen statistichen Algorithmen bestimmen. Overengineered?

Es wird letztlich auch eine klassische Berechnung sein, alles andere wäre ,glaube ich, zu teuer. Aber maschinelles lernen klingt natürlich besser.

 

[Holt]

Das Prinzip eines solchen Pseudo-SLC-Cache als temporärer Schreibpuffer ist längst nicht neu und kam schon vor Jahren bei TLC-SSDs zum Einsatz.

Es kam sogar vorher schon bei SSDs mit MLC NAND zum Einsatz, z.B. auch bei der Crucial MX200.

Um beim 250-GB-Modell dennoch einen hohen Schreibdurchsatz zu erzielen, kommt erstmals die mit Microns M600-Serie eingeführte Dynamic Write Acceleration zum Einsatz, auf die in einem nachfolgenden Abschnitt näher eingegangen wird.

Schön und gut, aber ich verstehe nicht so ganz, was das jetzt groß bringen soll, besonders in Bezug auf die dadurch angeblich Faktor 25 bessere Haltbarkeit.

Das TLC oder QLC im Pseudo-SLC Modus deutlich mehr Haltbarkeit hat als wenn alle 3 / 4 Bits pro Zelle beschrieben werden, ist ja lange bekannt. Dieser Faktor 25 bei den TBW wird darauf basieren, dass vor allem in den Pseudo-SLC Bereich geschrieben wird, aber wer ständig große Adressbereich überschreibt, dürfte diese Haltbarkeit bei weitem nicht erreichen.

Ich finde diesen Ansatz (in Hardware) nicht schlecht

Der "Clou" ist die Betriebssystemunabhängigkeit.

Da man ja auch einen speziellen NVMe Treiber braucht, ist es ja nicht wirklich nur in Hardware umgesetzt und damit auch nicht vom Betriebssystem unabhängig:

zudem ist Stand Januar ein spezieller NVMe-Treiber nötig.

Wie bei allen Cachlösungen hängt es von der Nutzung ab, was sie bringt! Ähnliche Lösungen gibt es, z.B. bei Intel mit dem RST Treiber und dem Caching auf den Optane und in Form der H10 auch mit beiden SSDs auf der gleichen Platine. Wenn man bei dieser SSD frei wählen könnte wie viel der Kapazität als QLC und wie viel als Pseudo-SLC genutzt wird, wäre es interessant, aber so? Dazu noch der Preis, aber "29 Prozent Rabatt" zeigen ja das da noch viel Luft drin ist. Eine 2TB QLC SSD wie die Intel 660p 2TB ist deutlich günstiger zu haben.

 

[Beitrag]

Dieser Faktor 25 bei den TBW wird darauf basieren, dass vor allem in den Pseudo-SLC Bereich geschrieben wird, aber wer ständig große Adressbereich überschreibt, dürfte diese Haltbarkeit bei weitem nicht erreichen.

Wenn diese ach so smarte Tief-Lern-Software die Daten nach Frequenz zwischen pSLC- und QLC-Speicher sortiert, dann muss sie zwangsweise auch den QLC gut nutzen. Die schlaue Software macht eigentlich ja sogar unnötige Schreibvorgänge, die ich bei 'ner normalen SSD gar nicht hätte, indem sie Daten zwischen pSLC und QLC hin- und herschiebt, wenn sich deren Lesezugriffe ändern. Gerade weil QLC lesend ja gar keine großen Nachteile hat, erscheint mir das einfach unsinnig.
Beispiel: Ich habe so eine SSD und hab alle meine Spiele raufgepackt. 'ne normale SSD würde dann nur noch lesen und nur bei Updates oder Spielständen mal was schreiben. Bei dieser SSD würden sich jedes Mal die Daten im SLC ändern, wenn sich die Spiele ändern, die ich zurzeit spiele. Das ist doch dumm.
Sinn machen würde das, wenn die Software nur nach Schreibvorgängen schaut, also bspw. Dateien erkennt, die häufig bearbeitet werden oder Ordner, in denen häufig neue Dateien erstellt und gelöscht/geändert werden. Wenn die Software das kann, würde es die Haltbarkeit sicher deutlich verbessern. Da es sich hier vmtl. aber um eine mehr oder weniger 1:1-Umsetzung von StoreMI/FuzeDrive handelt, gehe ich davon aus, dass stumpf die Lesezugriffe berücksichtigt werden und das halte ich in so einem SSD-SSD-Gespann einfach für unsinnig.

 

[Holt]

Die schlaue Software macht eigentlich ja sogar unnötige Schreibvorgänge, die ich bei 'ner normalen SSD gar nicht hätte, indem sie Daten zwischen pSLC und QLC hin- und herschiebt

Im Prinzip sorgt jeder Pseudo-SLC Schreibcache dafür, dass Daten doppelt geschrieben werden, außer wenn die Adresse unter der sie geschrieben wurde schon vorher überschrieben oder getrimmt wurde oder der Pseudo-SLC Cache voll war und direkt in den normalen NAND Bereich geschrieben wurde (wobei es auch SSDs gibt bei denen jeder Schreibvorgang immer durch den Pseudo-SLC Cache gehen). Wie schau der Algorithmus ist, wird man auch erst sehen müssen, in der Werbung ist er meist viel schlauer als in der Realität, wie man auch bei den SSHDs gesehen hat, wo einfach die zuletzt gelesenen Daten in den NAND Cache gehen, sofern der Zugriff nicht zu lang war mit dem sie gelesen wurden.

Da begrenzen einfach auch die Resourcen die zu Verwaltung des Caches vorhanden sind, wobei ein SSD Controller da mehr Resourcen hat, vor allem auch mehr DRAM zur Datenhaltung, als ein HDD Controller. Trotzdem würde ich nicht zu viel an Intelligenz in den Algorithmen erwarten, egal wie vollblumig die Herstellerversprechen auch sein mögen. Nimm z.B. Marvells Hyper Duo SSD Cache für HDDs:

Storing all consumer data on SSDs is costly and using the hybrid approach of manually combining an HDD and SSD doesn’t offer a true solution for achieving consistent performance acceleration in applications like gaming, video and rich media or I/O intensive programs.

Marvell HyperDuo solves this dilemma.
...
HyperDuo achieves immediate performance value from day one. The technology uses intelligent algorithms to automatically migrate hot data to SSDs, while enabling all data to be safely stored on larger capacity SATA HDDs. Thus HyperDuo enables near-SSD performance at HDD capacities.

Aber was passiert wirklich? Es gibt zwei mögliche Konfigurationen, den "Safe Mode: Automated mirroring from SSD to HDD for maximum protection" und den "Capacity Mode: SSD capacity augments the hard drive to optimize cost efficiency". Im Capacity Mode ist es einfach ein JBOD (BIG) bei dem die SSDs am Anfang des Adressraums steht und danach die HDD und beim Safe Mode laufen beide in einer Art RAID 1, aber da eben Kapazität der SSD in aller Regel geringer als die der HDD ist, reicht das RAID 1 eben nur über den Adressraum der SSD und nur in dem Bereich wird dann von der SSD gelesen, alle Daten die auf höheren Adressen geschrieben werden, landen nur auf der HDD und werden niemals auf die SSD geschrieben und damit auch nicht von dort gelesen. In beiden Fällen profitieren also nur Daten die am Anfang stehen vom SSD Cache, auch wenn vollmundig von "intelligent algorithms to automatically migrate hot data to SSDs" die Rede ist, so ist die Lösung die die kleinen Controller mit gerade 1 W TDP in Wahrheit umsetzen, halt doch nur extrem simpel und könnte bei den knappen Resourcen auch kaum nennenswert komplexer ausfallen. Daher bin ich bei den Werbeversprechen immer extrem vorsichtig!

 

[Beitrag]

Das wäre schlecht, da der Unterschied zwischen QLC- und TLC-Flash was ganz anderes ist als der zwischen SSD und HDD. Ohne schlauen Algorithmus wird das Ding genau gar nichts bringen und trotzdem viel teurer als 'ne 2 TB QLC-SSD sein - wo man auch noch mehr Nutzspeicher hat.

 

[Holt]

Diese SSD ist total uninteressant, zumal sie am Ende wohl ungefähr so viel kosten dürfte wie die Samsung 970 Evo Plus 2TB und zwischen den beiden müsste man doch nun wirklich nicht zweimal überlegen, oder?

 

[Giga-Gaga]

Intel Optane? Nur in einer Platine und ohne den Vorteil der schnelleren Zugriffszeit?
Ich gehe mal davon aus das in dem 128gb Bereich, wie bei Optane, keine ganzen Dateien vorhanden sind sondern nur die die Teile die eben oft benötigt werden. Die kompletten Daten liegen dann im dem andern Bereich. Für das Betriebssystem wird der kleine Bereich wohl nicht sichtbar sein.

 

[CTmanGer]

Massenspeicher...
Für mehr, wird das hoffentlich bald obsolet sein.
Es ist bedenklich, dass es im normalen Betrieb keinen Unterschied macht, ob 5 jahre alte SATA oder neuste PCIe 4 SSD verbaut ist.

Weder bei Updates, Installationen, Virusscan, öffnen von Dokumenten... elendig langsam alles obwohl man hunderttausende iops und 4GB/s theoretische Schreib/Leserate hat...
Bei solchen Operationen, oder ein Spiel/Level laden: 1-10% der Leistung kann abgerufen werden.

Ich sehe optimistisch auf die kommenden Konsolen... die erfinden sozusagen die Zugriffe und Integration der SSD neu...

 

[Hatsune_Miku]

So gut die Idee auch ist, ich glaube aber das wird genauso floppen wie SSHDs, ist ja im prinzip ähnlich.

 

[Holt]

Ich sehe optimistisch auf die kommenden Konsolen... die erfinden sozusagen die Zugriffe und Integration der SSD neu...

Lies diesen Artikel, die SSDs die da drin stecken, wird man nicht als Systemlaufwerk in seinem PC haben wollen!

Mainstream SSDs have a ratio of 1 GB of DRAM for each 1 TB of flash memory. That ratio is a direct consequence of the FTL managing flash in 4kB chunks. Having the FTL manage flash in larger chunks directly reduces the memory requirements for the mapping table. The downside is that small writes will cause much more write amplification and be much slower. Western Digital sells a specialized enterprise SSD that uses 32kB chunks for its FTL rather than 4kB, and as a result it only needs an eighth the amount of DRAM. That drive's random write performance is poor, but the read performance is still competitive. Sony's patent proposes going way beyond 32kB chunks to using 128MB chunks for the FTL, shrinking the mapping table to mere kilobytes. That requires the host system to be very careful about when and where it writes data, but the read performance that gaming relies upon is not compromised.

In short, while the Sony SSD should be very fast for its intended purpose, I'm going to wager that you really wouldn't want it in your Windows PC. The same is probably true to some extent of Microsoft's SSD

 

[bensen]

Irgendwie nur für Nischen interessant. Bei QLC ist ja vor allem die Schreibgeschwindigkeit sehr lahm. Dort leistet ein SLC-Cache gute Abhilfe.
Die Lesegeschwindigkeit ist weniger beeinträchtigt. Und wenn ich ein Anwendungsszenario habe, wo es auf jedes bisschen Performance ankommt, dann kaufe ich von vorneherein keine QLC SSD.

Für die Allgemeinheit ist ein großer SLC-Cache die bessere Lösung.

 

[sdffffds.sadofi]

kann man den slc-bereich selbst festlegen? zb auf 100%?

das ganze könnte man ja auch noch weiterspinnen:
die komplette ssd ist erst mal 500gb slc, quasi extremes wear-leveling.
sobald sie voll ist, wird sie automatisch zu 1tb mlc, dann 1,5tb tlc und am ende 2tb qlc (optional bleibt ein gewisser teil immer als slc-cache).

 

[C4rp3di3m]

Ist schon eine Weile her, aber diese SSHD´s sind schon daran erkrankt gewesen dass die oft nur 8Gig SSD Teil hatten, was bringt das schon. Zumindest erinnere ich mich daran und habe es gleich gelassen eine zu Testen.
Mal vom unterdimensionierten NAND abgesehen, fand ich den Ansatz schon befremdlich etwas ohne bewegliche Teile damit zu kombinieren.

Oft wird von den Herstellern an der flaschen Seite gespart, daher konnten diese Dinger nicht erfoglreich werden.

Finde diese SLC Sache, schrieb ich schon letztes mal, natürlich interessant. SLC SSD´s sind sehr Teuer und selten. In meinen Augen wäre es nur Sinnvoll, wenn der Treiber es dem Kunden freistellt selber zu entscheiden wie viel RAM er als SLC laufen lassen möchte. Bei 1/4 einer TB Version hätte man z.B. 256GB SLC. Wenn der Preis dann günstiger liegt als bei einer nativen SLC wäre das Sinnvoll.

So ließt sich das jetzt halt wie firscher Wein in alten Schläuchen.

mfg

 

[andi_sco]

Was wollen sie immer mit maschinellen Lernen? Nutzhäufigkeit lässt sich doch prima mit klassischen statistischen Algorithmen bestimmen. Overengineered?

Hört sich einfach besser an

 

[Holt]

sobald sie voll ist, wird sie automatisch zu 1tb mlc, dann 1,5tb tlc und am ende 2tb qlc

Nur muss dann auch das Filesystem erweitert werden und es müssten alle Daten intern umkopiert werden, da sie sonst beim Schreiben sehr lahm wäre, weil dann bei MLC das zweite, später immer das dritte und am Ende im QLC Modus immer jeweils das vierte Bit einer Zelle beschrieben werden müsste, immer länger dauert. Vom Risiko das Low-page-corruption gar nicht zu reden. Sowas wird also wohl kaum möglich sein und wenn man sie leert, müsste man das Filesystem auch wieder verkleinern um zurück in den Pseudo-SLC, MLC oder TLC Modus kommen zu können und müsste man der SSD dann auch noch irgendwie mitteilen das man die Größe des Filesystems angepasst hat.

Ist schon eine Weile her, aber diese SSHD´s sind schon daran erkrankt gewesen dass die oft nur 8Gig SSD Teil hatten, was bringt das schon.

Also ganz schlecht waren die nicht, ich hatte mal eine als Datengrab und wenn man viel und wiederholt mit kleinen Dateien gearbeitet hat, dann war die schon flotter als eine normale HDD, wenn auch noch immer weit von einer SSD entfernt.

Je nachdem welche Anwendung man hat, kann Caching schon interessant sein, aber dann würde ich immer eine Lösung bevorzugen wo man ein getrenntes Cachlaufwerk hat und nur wenn der Platz dies nicht erlaubt, dann könnte so eine integrierte Lösung als Notbehelf dienen.

 

[C4rp3di3m]

Ja ok gerade bei Bildbearbeitung, MP3 etc. wo viele kleinere Dateien anfallen, sind die bestimmt ok gewesen. Bei mir haben Festplatten eigentlich nur die Aufgabe massenhaft mkv dateien der x266-4K Klasse zu archivieren. Bei 15 bis 40Gig pro File nutzen die mir nichts, ich komm sogar mit SMR gut zurecht. Da habe ich halt nur bedenken dass die nicht so Langlebig sind.

SLC SSD für zum RAR´en finde ich halt interessant, da dort sehr viel Traffic durchgeht. Ca. 10TBx2 oder 3, pro Jahr.

mfg

 

[Holt]

ich komm sogar mit SMR gut zurecht. Da habe ich halt nur bedenken dass die nicht so Langlebig sind.

Wieso sollten HDDs mit SMR weniger langlebig sein als solche ohne? Wichtig ist bei allen HDDs, dass man sie nicht allzulange unbenutzt rumliegen lassen sollte, dies kann gutgehen, oder auch nicht. Die Hersteller spezifizieren maximal 1 Jahr Lagerdauer und dies oft nur in der originalen Verpackung vom Hersteller, nach dem Öffnen, also auch dem ersten Benutzen, sind es oft nur 3 Monate.

SLC SSD für zum RAR´en finde ich halt interessant, da dort sehr viel Traffic durchgeht.

Wenn man keine Kompression nutzt, aber bei solchen Videos dürfte die sowieso nichts mehr bringen. Sonst bremst wohl eher die CPU.

Im übrigen zeigt dies mal wieder schön, wie sehr die Effizienz einer Cachinglösung von der Anwendung abhängt. Deshalb ist der eine dann begeistert und der andere eben völlig enttäuscht.

 

[C4rp3di3m]

Hmm ja die Frage ist dann ob ein extrem großer DRAM cache nicht in Verbindung mit eine SLC gut kommt. Weiß nicht ob es so was gibt aber ein Cache von 4 bis 8GB wäre schon eine Ansage. Mit sehr großen SSD über 1TB habe ich mich nie beschäftigt, ist deren Zwischenspeicher signifikant höher als bei kleinen? Nunu eine 1TB SSD umgestellt auf 256GB voll SLC mit großem Cache wäre schon sehr schön. Zumindest würde man dem Kunden die freie Wahl lassen, viel Space oder halt viel TBW, ok und der speed im SLC mode müsste natürlich egal ob SATA oder PCie brutal sein.

Nein gelagert wird nichts, also min 3-4 mal die Woche sind alle Platten unter Strom und am Laufen.
Aber ich hatte das bei einer mit viel Laufzeit, die ich getauscht hatte Vorsichtshalber. Habe die Daten drauf gelassen als extra Backup. Nach ca. 1 Jahr mal wieder angeschlossen und die Platte war einfach tod, tat sich nichts mehr.

mfg

 

[Holt]

ja die Frage ist dann ob ein extrem großer DRAM cache nicht in Verbindung mit eine SLC gut kommt.

Der DRAM Cache auf einer SSD dient, anders als bei HDDs, in aller Regel nicht als Cache für die Userdaten, sondern da cacht der Controller seine Verwaltungsdaten, vor allem die Mappingtabelle. Deshalb ist dessen Größe in aller Regel auch proportional zur Kapazität der SSD! Der DRAM Cache von dem Du sprichst, müsste also ein externen im RAM des Rechners sein.