Die Kingston DC600M im Test: Für Dauerbetrieb und Stromausfall ausgelegt

Es wird sich erst in ein paar Jahren zeigen, wie sich die erhöhte Belastung auf die tatsächlich Lebensdauer auswirken wird. Aber die theoretischen Daten lesen sich nicht so gut.

QLC hält nur ein Drittel so lang wie TLC, und schon TLC hält nur ein knappes Drittel so lang wie MLC. Von den Herstellern garantiert sind folgende "bis zu"-Schreibzyklen je Speicherzelle:

SLC: 100.000
MLC 10.000
TLC 3.000
QLC 1.000

....QLC hält also nur ein Hundertstel so lang wie SLC. Und schon da hat man Zellenmanagement betrieben.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
sie hat tatsächlich 8GB DRAM, was mit dem Vorhandensein von pSLC-Cache rein gar nichts zu tun hat.
Eben, der DRAM Cache ist für die Verwaltungsdaten des Controllers, vor allem die Mappingtabelle, also die Tabelle wo die logischen Adressen mit denen die SSD angesprochen wird, auf die NAND Adressen übersetzt werden. Das unterscheidet den DRAM bei SSDs und HDDs, denn HDDs brauchen ja keine Mappingtabelle, außer für die paar Reservesektoren die ggf. schon genutzt werden.

Einen Pseudo-SLC Schreibcache dürfte sie eher nicht haben, dies wäre für eine Enterprise SSD ungewöhnlich, schon weil die Enterprise SSDs eben bei artgerechter Nutzung mehr gar nicht so lange Idle sind, dass sie den pSLC Schreibcache leeren könnten. Außerdem beschränkt hier sowieso das SATA Interface und die damit mögliche Bandbreite kann man bei so viel NAND immer auch noch im TLC Modus wegschreiben.
Das kommt natürlich auf die Zielgruppe an und folglich auf die Größe von Spare Area und wieviel Überprovisionierung (OP) ab Werk (und auch Reserveblocks usw) der Hersteller vorsieht.
Das kannst Du gerne der folgenden Tabelle entnehmen:
Wobei die auch nicht ganz korrekt ist, dann die verbaute NAND Kapazität dürfte in aller Regel kleiner sein, da die NANDs eigentlich immer den einen oder anderen ab Werk defekten NAND Block haben und dann stehen ja auch noch die Firmware und die Verwaltungsdaten im NAND. Die True Physical OP ist also ein wenig kleiner, vielleicht so um einen Ürozentpunkt als es in der Tabelle steht.

Man beachte übrigens auch die Angaben in TB, also Terrabyte und damit auf 1000er Basis, während Windows leider auch TB angibt, aber intern auf Basis 1024 rechnet und eigentlich TiB (Tebibyte) als Einheit angeben müsste.
Sie hat keinen DRAM-Cache schreibt aber in jedem Fall schneller als eine MX500 M.2 (SATA).
Der DRAM Cache hat nichts mit der Schreibgeschwindigkeit zu tun! Das ist kein Schreibcache und außer das der Controller bei SSDs ohne DRAM Cache ggf. mal einen NAND Zugriff machen muss um zu wissen wo denn freie NAND Pages sind, was aber bei sequentiellen Schreibzugriffen nicht ins Gewicht fällt, macht der DRAM Cache beim Schreiben keinen Unterschied. Der Pseudo-SLC Schreibcache ist der Cache der die Schreibgeschwindigkeit steigert, nicht der DRAM Cache!
 
Das ist kein Schreibcache
Dann weist du wohl mehr als zB https://www.thomas-krenn.com/de/wiki/SSD_Power_Loss_Protection
Die meisten SSDs verfügen so wie Festplatten über einen DRAM-Cache, der in erster Linie zur Beschleunigung von Schreibvorgängen dient. Da DRAM-Module den Speicherinhalt nur so lange speichern, wie sie mit Strom versorgt werden geht ohne weitere Schutzmaßnahmen der Inhalt dieses Caches bei einem plötzlichen Stromausfall verloren. In der Folge kann es zu einem Datenverlust kommen.......Erkennt der Controller einen Ausfall der Versorgungsspannung, nutzt er die in den Kondensatoren gespeicherte Energie noch dazu, die Daten des DRAM-Caches auf die Flash-Zellen zu schreiben. Auf diese Weise wird ein Datenverlust ausgeschlossen.

Sonst wären die Kondensatoren für PLP doch auch irgendwie sinnfrei, wenn es direkt auf die NAND Speicher geht ?
 
Gegen QLC gibt es eigentlich nicht viel auszusetzen, solang man diese SSDs nur vorrangig als Datengrab bzw. Randomseek einsetzt und damit halt nicht für hohe seq. Datentransferzugriffe über mehrere xx GB on stock.
Da machen die dann wirklich, je nach Modell und deren Rohkapazität, schneller zu als TLC. Den Unterschied DRAM_Cache Mode vs. non_DRAM, also HMB finde ich persönlich nicht dramatisch.
In der Praxis merkst du da nicht viel, eigentlich rein gar nichts. Weder als OS Medium noch Gaming Medium eingesetzt. Da wird immer mehr "Schow" drum gemacht als dann im Endeffekt real vorhanden.
Wer unbedingt nur DRAM_Cached kaufen möchte kann das ja gerne tun, meine Erfahrung aber ist, pSLC bzw. sog. dynamisches Caching, ergo HMB, ist in der Praxis nicht wirklich nachteiliger.
Es ist letztendlich eine Frage der Nutzung. Bei "Datengräbern" bzw. leseintensiven Anwendungen ist QLC sehr attraktiv. Ansonsten würde ich auf MLC oder TLC setzen. SLC ist toll, aber teuer. Sonst würde ja jeder nur SLC verbauen. Das macht bei Servern sicher Sinn, aber nicht bei Leuten wie mir die am Ende nur Filme oder Spiele speichern und sie dann von den Datenträgern lesen.

Lohnt der Cache dann? Ich hätte hier noch eine 120er Samsung Basic. Würde die meinen vorhanden Pool beschleunigen? Laut Reddit soll das ja nicht der Fall sein. Aber die SSD ist da und liegt hier rum, ich sehe sonst auch kaum Nutzen für sie.

Beim Netzwerk kommt noch dazu dass das LAN-Interface drosselt. Bei mir 1 Gbit und im Falle von 2.5 Gbe dann eben 300. Real kommen 111 MB/s sequenziell. Das schafft selbst QLC. SSDs bieten primär den Vorteil von guten random-Zugriffen, was auch bei Netzwerkzugriff so bleibt. Eine HDD, die mehrere Geräte mit Abfragen versorgen muss bricht extrem ein. Eine SSD nicht.
 
Ja, denn das ist einfach falsch, der DRAM Cache ist kein Schreibcache! Gerade wenn es um SSDs geht, haben leider auch viele Leute die sonst recht kompetent sind leider wenig Ahnung. Dabei ist seit der Intel X25-M, der ersten SATA SSD mit einem modernen Controller mit DRAM Cache so, das da die Verwaltungsdaten und keine Userdaten drin stehen und was Anandtech vor 15 Jahren geschrieben hat, hat sich bis heute nicht geändert:
Die SRAM Caches der Controller sind heute natürlich größer, selbst so ein billiger Phison S11 hat 32MB Cache intern, auch wenn der oft als DRAM Cache bezeichnet wird um den Eindruck zu erwecken die SSD hätte einen DRAM Cache, obwohl sie eben keinen hat. Deshalb ist die Größe des DRAM Caches ja auch proportional zur Kapazität der SSD und für eine ideale Datenstruktur der Mappingtabelle eben 1GB RAM pro 1TB Kapazität.

Aber wer mir nicht glaubt, der schau doch mal wo denn je der DRAM Cache das Verhalten eines Schreibcache gezeigt hat. Dies wäre ja dann beim Schreiben zu sehen, wo die ersten Daten dann auf jeden Fall mit einer Geschwindigkeit am Limit der Schnittstelle geschrieben werden können. Dies wäre bei heutigen Consumer SSDs wegen des Pseudo-SLC Schreibcaches schwer zu sehen, die können ja meist auch schon so schnell in den Pseudo-SLC Schreibcache schreiben (was den Sinn eines DRAM Cache als Schreibcache dann sowieso eliminieren würde), aber bei älteren SSDs mit MLC, wo ein Pseudo-SLC Schreibcache die seltene Ausnahme war und die Schreibraten meist weit unter dem Limit der Schnittstelle lagen, müsste man dies ja sehen können. Aber nimmt man z.B. eine Intel 750, wo selbst die 1,2TB Version nur mit 1200MB/s angegeben ist, schafft in keinem Test in irgendeinem Review nennenswert mehr als dies, obwohl die ein PCIe 3.0 x4 Interface hat und damit fast dreimal so schnell in ihren DRAM Cache schreiben können müsste, wenn er denn ein Schreibache wäre.

Bei solchen recht frühen NVMe oder auch SATA SSDs sollte man es ja sehen können, wer noch so Schätzchen hat, kann ja mal CrystalDiskMark anwerfen, die Einstellung von 1GiB auf 64MiB ändern, die sollten ja selbst in dem DRAM Cache der meist damaligen SSD mit üblicherweise recht kleinen Kapazitäten passen und sie benchen. Da müsste das Ergebnis ja massiv besser sein als mit einem Wert der größer als der DRAM Cache ist und eben nahe am Limit der Schnittstelle. Aber meine alten Samsung 830 256GB die in meinem vorherigen Rechner über 6 Jahre als Systemlaufwerk gedient hat und jetzt im neuen Rechner hängt, falls ich davon noch mal was brauche, kommt damit bei SEQ1M Q1T1 auf 280MB/s schreibend und über 1GiB sogar auf 294MB/s.

Aber es fehlen nicht nur jegliche Beweise dafür das SSDs ihren DRAM Cache als Schreibcache für Userdaten nutzen würden, wie manche es trotzdem behaupten, sondern es gibt eben auch Beweise dafür das die Controller den DRAM Cache für ihre Verwaltungsdaten verwenden. Denn wenn SSDs keinen DRAM Cache haben, dann können sie eben nur einen kleinen Teil, meist nur genug für einen Adressraum von 1GB, im internen SRAM Cache halten und müssen bei Zugriffen auf andere Adressen dann erst den passenden Teil der Mappingtabelle aus dem NAND nachladen, was aber viel länger als ein RAM Zugriff dauert und damit zu einer Verzögerung führt. Liest man dann nur 4k pro Zugriff macht sich dies als ein massiver Einbruch der IOPS bemerkbar. NVMe SSDs mit HMB können noch einen des DRAMs des Rechners als zusätzlichen Cache nutzen, was aber das Fehler des DRAM Caches nur teilweise kompensiert, wie man im Review der Kioxia BG4 1TB mit und ohne HMB sehen kann:

BG4_HMB.png


Wie man sieht fallen die IOPS ohne den HMB schon ab einem Adressraum von mehr als 1GB massiv ab, mit dem HMB dann ab einem Adressraum von mehr als 32GiB, eben weil die dann immer wieder Teile der Mappingtabelle erst aus dem NAND nachladen muss, bevor sie die eigentlichen Daten aus dem NAND lesen kann. Hier zum Vergleich mit einer 970 EVO Plus:

BG4_HMB_vs_970EVO.png


Die 970 EVO Plus hat einen vollem DRAM Cache und wie man sieht ändert sich da nichts an den IOPS, egal über welchen Adressraum zugegriffen wird, da sie eben in ihrem DRAM Cache eine flache Tabelle stehen hat in der der Controller für jede Adresse gleich schnellen Zugriff hat und damit immer gleich schnell die NAND Adresse findet wo die Daten stehen. So eine Tabelle braucht eben 1GB RM pro 1TB Kapazität, egal wie voll die SSD ist.

Wer immer noch der Meinung ist eine SSD würde ihren DRAM Cache als Schreibcache nutzen, der mögen dazu auch den Beweis bringen. Also den Benchmark verlinken aus dem er meint dies rauslesen zu können und nicht einfach noch jemanden verlinkten der den Müll auch behauptet. Hier geht es nicht um eine Abstimmung wo derjenige gewinnt der die meisten Stimmen bekommt, sondern um Fakten und Fakten ändern sich nicht, egal ob man ihnen zustimmt oder widerspricht und ob sie einem gefallen oder nicht, ändert auch nichts an den Fakten.
 
Dann bedank dich beim dicken Mann in rot/weiß, der jedes Jahr auf's neue mit den Händlern einen Deal hat, dass DU dem sein Rentierfutter bezahlen darfst. (y)
Der Coke-Außendienst-Vertriebsleiter? :d

Meinst es liegt daran? Nun, man wird sehen... bei der 870 Evo ja, bei der Kingston mit U.2 eher nein, hätte ich gesagt? Die (heiße) Micron 7400 M.2 gabs auch mal "richtig billig" in 4 TB, siehe Internet bzw. Geizhals-Statistik.
Es ist letztendlich eine Frage der Nutzung. Bei "Datengräbern" bzw. leseintensiven Anwendungen ist QLC sehr attraktiv. Ansonsten würde ich auf MLC oder TLC setzen. SLC ist toll, aber teuer. Sonst würde ja jeder nur SLC verbauen. Das macht bei Servern sicher Sinn, aber nicht bei Leuten wie mir die am Ende nur Filme oder Spiele speichern und sie dann von den Datenträgern lesen.
"Datengrab" ist halt ein weit dehnbarer Begriff, mir is immer noch nicht so ganz klar, wie das mit den NAND Flash Zellen bei langer Nichtbenutzung ist. Hab da so Hörensagen (aus nicht-DAU-Kreisen) vernommen, dass die Zellen wohl sehr langsam werden können sollen, bis zur nächsten Neubeschreibung. Hab mir sagen lassen, je mehr Zustände möglich sind, desto eher tritt das Problem auf (also QLC schlechter als SLC...).
Inwiefern das Unsinn ist, und ob das nur total stromlosen Zustand betrifft, oder auch einfach fehlende Zugriffe obwohl im "online", keine Ahnung.
=> Ich lass mich gern aufklären von euch.
Lohnt der Cache dann? Ich hätte hier noch eine 120er Samsung Basic. Würde die meinen vorhanden Pool beschleunigen? Laut Reddit soll das ja nicht der Fall sein. Aber die SSD ist da und liegt hier rum, ich sehe sonst auch kaum Nutzen für sie.
Hängt wohl davon ab, welches NAS du hast. Syno? Andere "Kompakt-NAS"? TrueNAS? Unraid, OMV, irgendwas mit (open)ZFS?
Ich meine nein, ich kenn keine "Basic", hab aber letztens erst eine 840 Pro 256gb und eine 840 Evo 1TB in der Hand gehabt, die 840 Evo musste ich erst von nem Firmwarebug freipatchen, läuft jetzt wieder brauchbar (im Office-Laptop bei Mutter... hab sie aber aub so 200 mb/s gebencht), die 840 Pro war nimmer so berauschend schnell, auch die Kleinzeug-Zugriffe nicht (auch recht voll), hab da noch diverse Daten vom alten PC runterkopiert (Ziellaufwerk war bestimmt schneller). Hab dann um 50€ die kleinste SATA "Datacenter" (mit PLP) von Samsung gekauft, so viel billiger sind die guten USB-Sticks auch nicht, war mir dann irgendwie lieber/"sicherer" die Lösung.
Wenn die 840 Basic was ähnliches ist (und kleiner ist ja auch oft langsamer in der Größenordnung), würd ich die Finger davon lassen. Nur ne Fehlerquelle mehr, CPU-Leistung brauchts wohl auch... und wahrscheinlich noch nicht mal wirklich schneller.

Dass ein SSD Cache privat sinnvoll ist, mh. RAM ist bestimmt "besser", weil sja in der Größenordnung 64-128gb am AM4 recht easy ist (mit ECC), da ist die Optane nicht viel billiger. Ist halt die Frage, wie sich der SSD-Cache bei Stromausfall verhält während dem Schreiben, ob das soweit bulletproof ist.

Ist wsl. beides übertrieben privat.
Beim Netzwerk kommt noch dazu dass das LAN-Interface drosselt. Bei mir 1 Gbit und im Falle von 2.5 Gbe dann eben 300. Real kommen 111 MB/s sequenziell. Das schafft selbst QLC. SSDs bieten primär den Vorteil von guten random-Zugriffen, was auch bei Netzwerkzugriff so bleibt. Eine HDD, die mehrere Geräte mit Abfragen versorgen muss bricht extrem ein. Eine SSD nicht.
Ja, 260-280 MB/s schaff ich recht konstant über 2,5G (Intel-Onboard-NIC, Win10 Desktop vs. TrueNAS [5750G/64gb ECC] und ein unmanaged QNAP Switch).

Die QLC sollten eigentlich reichen für sowas, wichtig wäre mir dafür meine Frage weiter oben. Hängt auch davon ab, wie man das NAS backupt, probieren könnte mans.
Hab schon einiges zum Thema QLC und TrueNAS rumgelesen, find aber auch auf englisch nix handfestes. Die meisten raten eher aufgrund ihres Vorwissens davon ab, nicht aus eigener (gescheiterter) Erfahrung.

Ich könnt mir schon vorstellen, dass so eine QLC SSD (eine TLC ohnehin) in einem schlanken Kompaktnas (ob Syno oder sonst was) sinnvoll ist, vor allem in der Wohnung, wenns leise sein soll.
SSD hat ja viele Vorteile, selbst QLC, gerade wenn man so Kleinzeug-Zugriffe hat, also Fotos, Backup vom Handy mit den Whatsapp Image Ordnern usw...

Zum Test:
Die DC600M kostet in der 8 TB Version momentan ca. 630€, war aber monatelang bei 550€ (ein Händler hat sie auch jetzt drum gelistet), dafür, wie RAR und Teuer die SATA-Steckplätzte im Kompaktnas sind, find ich das gar nicht sooo schlimm.
In jedem Fall schneller als 2.5G und lautlos.
Geplantes regemäßiges Backup auf eine USB-HDD (dreht die dann ab, wenn der Zugriff weg ist?), und die Sache dürfte recht rund sein, wenn die Daten nicht tagesaktuell sein können kann man sich die Spiegelung der SSD wohl sparen, hatte bisher ganz gute Erfahrungen mit den SSDs.

=> Ich bin Team SSD-NAS (wäre ich nicht so Data-Horder)
Wer immer noch der Meinung ist eine SSD würde ihren DRAM Cache als Schreibcache nutzen, der mögen dazu auch den Beweis bringen. Also den Benchmark verlinken aus dem er meint dies rauslesen zu können und nicht einfach noch jemanden verlinkten der den Müll auch behauptet. Hier geht es nicht um eine Abstimmung wo derjenige gewinnt der die meisten Stimmen bekommt, sondern um Fakten und Fakten ändern sich nicht, egal ob man ihnen zustimmt oder widerspricht und ob sie einem gefallen oder nicht, ändert auch nichts an den Fakten.
Mein lieber Holt, erklär mir, wofür die SSD ihn sonst verwendet. Wie gut die Sache implementiert ist, ist wieder eine andere Frage. Ein Lese-Cache kanns ja nicht sein (wie soll der Controller wissen, was gern gelesen wird, das ist doch die ZFS-Magic?).
Die 970 EVO Plus hat einen vollem DRAM Cache und wie man sieht ändert sich da nichts an den IOPS, egal über welchen Adressraum zugegriffen wird, da sie eben in ihrem DRAM Cache eine flache Tabelle stehen hat in der der Controller für jede Adresse gleich schnellen Zugriff hat und damit immer gleich schnell die NAND Adresse findet wo die Daten stehen. So eine Tabelle braucht eben 1GB RM pro 1TB Kapazität, egal wie voll die SSD ist.
Okay. Klingt logisch. Also ein Cache für diese Tabelle, nicht für die Schreibdaten? Und wenn sie keinen DRAM "Cache" hat, wohin dann mit dem Kram? Hält das OS dann die Tabelle im RAM, sonst wo, gibts dann keine...? Wie ist das mit dem Cache bei HDDs?

Ich frag das jetzt nicht, um dich irgendwie aufs Eis zu führen, ich bin tatsächlich dran interessiert das genauer zu lernen.
 
erklär mir, wofür die SSD ihn sonst verwendet.
Für das FTL (Flash Translation Layer).
Und wenn sie keinen DRAM "Cache" hat, wohin dann mit dem Kram?
Der "Kram" ist IMMER im Flash vorhanden und zwar in der pSLC-Form und wird bei Inbetriebnahme in den viel schnelleren DRAM eingelesen, das FTL ist meist sogar doppelt vorhanden und einige Modelle legen pro NAND-Chip extra ein Backup an - es gibt also mehrere Backups. Sobald die Daten und somit das FTL im DRAM geändert wird, geschieht auch das schnellstmögliche Ändern der Kopie im NAND-Flash, schnellstmöglich - ja, unverzüglich - ja aber nicht instant -> daher hat eine PLP schon ihren Sinn.
 
..und im Gegensatz zum HMB Mode der DRam_less SSD die sich sharing des Host Ram bedient, ist der DRam @ SSD halt nicht flüchtig. Heißt, darin gespeicherte Daten (Mapping) sind auch nach dem herunterfahren noch vorhanden. Der HMB Mode von DRam_less SSDs ist jetzt zwar nicht so schnell wie bei SSDs mit internen DRam aber das Ram_caching ist immer einiges schneller, als würde die SSD fürs Mapping direkt hierfür einen Bereich des NanD reservieren.

Hat aber dennoch alles keinen wesentlichen Einfluss auf die seq. Datentransfergeschwindigkeit einer SSD, diese richtet sich weit mehr nach u.a. auch dem Füllstand.

Ich hatte das ja mal ausführlich gebencht, WD SN850X mit DRam_cache vs. Fanxiang S880 DRam_less (HMB Mode). Hier auszugsweise, beide komplett leer, Rohmaterial 800GB Datenpaket:

Copybench1-2.png

..selbst nach 400GB kopieren beide noch auf sehr hohen Niveau.

edit: Geschrieben werden also rein die Daten immer direkt in den NanD, egal ob nun SLC, pSLC, MLC, TLC oder QLC. Alles andere würde auch keinen Sinn ergeben, denn wenn die Daten erst gecached (zwischen gespeichert) werden würden, wäre a.) der DRam dafür viel zu knapp bemessen und b.) dies die SSD unerträglich ausbremsen. Der andere "Boost" der über eine gewisse Schreiblast, abhängig vom jeweiligen Füllstand, eine SSD schreibseitig puscht ist dann halt pSLC, TurboWrite, Gaming Mode und wie man das auch immer nennen mag (Kreativität der Hersteller). Das findet aber auch unabhängig davon statt, ob die SSD nun mit oder ohne eigenen DRam Cache daher kommt.

Es bleibt aber wie es halt ist, im normalen Nutzungsbereich einer SSD, egal ob als OS Datenträger oder Datengrab, wird man nicht bemerken ob die SSD nun den internen DRam Cache nutzt oder HMB Mode anwendet.
Da wird oftmals viel Wind um im Grunde genommen sehr wenig Ausbeute betrieben und wenn jetzt zwischen zwei SSDs identischer Größe und Gen. der einzige Unterschied halt nur im Caching begründet ist, dafür aber die mit DRam meinetwegen 50€ teurer ist, dann wäre mir nur das den Aufpreis nicht wert. Außer die ist halt im Angebot, dann ja. Selbst bei den Herstellergarantiezeiten tut sich da oft kein Unterschied mehr auf.

edit2: Und da ich den hier schon bestimmt 1000x in Teilen zitierten at Artikel selbst kenne, dieser von 2018 ist und damit schon arg in die Jahre gekommen, kann man mit Gewissheit davon ausgehen, dass heutige aktuelle SSDs die Controller_seitig den HMB Mode nutzen, wesentlich leistungsfähiger sind als hier immer wieder anders dargestellt. Das sind auch meine Erfahrungen mit diesen SSDs, wovon ich selbst einige teilweise konstant nutze.
Bis auf eine Crucial P3 Plus, bei der aber einige Faktoren zusammen kamen und dafür sorgten, dass die schon nach sehr kurzer Schreiblast auf HDD Niveau absackte (QLC, DRam_less, verbugte Firmware) und auch dabei blieb, ist mir noch keine DRam_less SSD untergekommen die nicht sehr flott, selbst bei höherer Schreiblast, agierte.

..fast 6 Jahre alte Schinken zitieren, der 1 Jahr später dann halt zu Ehren der Samsung 970EVO Plus noch einmal frisch aufgebrüht wurde aber dennoch nicht mehr viel mit aktuellen HMB Mode SSDs zu schaffen haben dürfte, naja, wer's braucht.. :sneaky:

Aber sei es drum, dass alles hat dennoch sehr wenig mit den eigentlichen Thema S-Ata SSD hier zu schaffen, denn:
Dies ist möglich, sobald die SSDs auf PCI-Express (PCIe) als Übertragungskanal setzen. PCIe Gen3 ist Teil der NVMe-(Non-Volatile-Memory Express)-Spezifikation, die es dem Controller ermöglicht, einen Teil des Hostspeichers für sich zu reservieren (Host-Memory-Buffer / HMB). Dort kann dann die Mapping-Tabelle des File-Translation-Layers (FTL) in Form von L2P-Cache-Einträgen abgelegt werden. Dies macht ähnliche Zugriffsgeschwindigkeiten wie bei Architekturen mit DRAM möglich.
:fresse:
 
Zuletzt bearbeitet:
Mein lieber Holt, erklär mir, wofür die SSD ihn sonst verwendet.
Das steht doch im Text und du zitierst es danach auch noch. Wie wäre es mit erst Lesen dann Kommentieren?

Aber massaker hat es ja schon geschrieben:
Für das FTL (Flash Translation Layer).
Wobei FTL (Flash Translation Layer) nur eine andere Bezeichnung für die Mappingtabelle ist, eben die Tabelle in der steht wo die Daten die unter der jeweiligen Adresse gespeichert wurden, dann im NAND stehen. Das ändert sich ja bei SSDs immer wieder mal, z.B. nach einer Idle-GC. Denn NAND kann man zwar Pageweise lesen und beschreiben, aber nicht überschreiben und nur blockweise löschen. Eine Page ist heutzutage typischerweise so 16K groß, ein Block umfasst Hunderte, wenn nicht sogar über 1000 Pages und wenn dem Controller die freien NAND Pages ausgehen, dann schaut er eben so in einem Block viele Pages mit ungültigen Daten sind. Daten werden ungültig, wenn die Adresse überschrieben wird unter der sie gespeichert waren, die neuen Daten müssen ja dann in andere NAND Pages geschrieben werden da man die Daten halt nicht überschreiben kann oder wenn die Adresse getrimmt wurde. Vor dem Löschen des Blocks in dem diese vielen Pages mit ungültigen Daten sind, muss der Controller natürlich die Daten aller Pages die noch gültig sind, erstmal in Pages in einem anderen Block kopieren und damit ändert sich dann der Eintrag in der Mappingtabelle.

Eine weitere Bezeichnung für die Mappingtabelle ist übrigens Indirection Table, denn wie so oft wenn es um neue Technologie geht, machen am Ende zwar alle mehr oder weniger das Gleiche, aber jeder gibt seinem Kind einen eigenen Namen um es als was besonders anpreisen zu können.
Klingt logisch. Also ein Cache für diese Tabelle, nicht für die Schreibdaten? Und wenn sie keinen DRAM "Cache" hat, wohin dann mit dem Kram?
Wie schreibt:
Der "Kram" ist IMMER im Flash vorhanden und zwar in der pSLC-Form und wird bei Inbetriebnahme in den viel schnelleren DRAM eingelesen
Denn Spieluhr, der auch auf meiner IL steht und wieder mal Blödsinn schreibt, irrt wenn er meint:
..und im Gegensatz zum HMB Mode der DRam_less SSD die sich sharing des Arbeitsspeichers bedient und dort quasi einen Bereich "reserviert" ist der DRam @ SSD halt nicht flüchtig. Heißt, darin gespeicherte Daten (Mapping) sind auch nach dem herunterfahren noch vorhanden.
DRAM ist immer flüchtig und wenn man es nicht flüchtig haben will, dann muss man es ununterbrochen mit Spannung versorgen um es refreshen zu können. Eine nicht flüchtige Alternative wäre 3D XPoint, dies nennt sich aber ebne nicht DRAM und dies haben die Optane verbaut, die daher auch ohne DRAM Cache schnell sind, da 3D XPoint eben auch wahlfreie Lese- und Schreibzugriffe erlaubt und lesend fast so schnell ist wie DRAM, schreibend ist es ein wenig langsamer, aber immer noch schneller als NAND.

Wie ist das mit dem Cache bei HDDs?
Der dient vor allem als Arbeitsspeicher des Controllers, wofür bei SSD Controllern das internes SRAM dient (wo dann auch meist ein paar Userdaten gecacht werden, eben um die ECC dafür zu berechnen oder genug Daten zu sammeln bis eine ganze Page geschrieben werden kann, statt eine Page nur teilweise beschrieben zu müssen und wenn die nächsten Daten kommen, müssen sonst die alten Daten gelesen und zusammen mit den neuen Daten in eine andere Page geschrieben werden). Der Teil der als Cache für Userdaten verwendet wird, ist meist auch nur ein eher kleiner Teil dessen was immer angegeben wird, denn da wird meist die Größe des gesamten DRAMs angegeben. Samsung hat früher in den Datenblättern auch immer angegeben wie viel vom DRAM wirklich für Userdaten ist. Bei SMR Platten ist sowieso mehr DRAM nötig um die Daten zu speichern die beim Schreiben der überlappten Spuren gelöscht werden und neu geschrieben werden müssen. Das sind dann zwar Userdaten, aber vielleicht wurden sie schon vor Jahren geschrieben und damit ist es auch nicht wirklich das was man meist unter dem Cache einer HDD versteht.

Ich frag das jetzt nicht, um dich irgendwie aufs Eis zu führen, ich bin tatsächlich dran interessiert das genauer zu lernen.
Sonst hätte ich auch nicht geantwortet.

als würde die SSD fürs Mapping hierfür einen Bereich des NanD reservieren
Das macht jede SSD, denn der DRAM Cache ist eben nur ein Cache, vor allem eine Lesecache für eben genau diese Mappingtabelle und da DRAM eben immer flüchtig ist, muss der Controller die Änderungen in dieser Tabelle irgendwann ins NAND zurückschreiben. Gibt es eine Full-Power-Loss Protection die dafür genug Energie liefern kann, dann kann er dies bis zum Schluss aufschieben, also bis er den Befehl bekommt das gleich die Spannungsversorgung unterbrochen wird, da er es im Zweifel sonst immer noch könnte. Normalerweise werden die Controller aber nicht so lange damit warten.

Hat aber dennoch alles keinen wesentlichen Einfluss auf die seq. Datentransfergeschwindigkeit einer SSD
Das ist richtig, denn ein NAND Zugriff hier und da, spielt in Vergleich zu den ganzen NAND Zugriffen beim sequentiellen Lesen und Schreiben kaum eine Rolle, aber bei kurzen zufälligen Lesezugriffen fällt es halt richtig ins Gewicht, da sich dann ja schlimmstenfalls die Anzahl der NNAD Zugriffe verdoppelt, wenn für jeden Zugriff auf die eigentlichen Daten erst noch ein Zugriff auf den passenden Teil der Mappingtabelle nötig ist. Genau dies sieht man ja auch im Test den Aanandtech mit und ohne HMB mit der BG4 gemacht hat und der Vergleich mit der 970 EVO Plus zeigt halt, wie es idealweise aussieht, nämlich das die Zugriffe auf alle Adressen gleichschnell sind. Das geht aber nur mit einem vollen DRAM Cache und einer entsprechenden Organisation der Mappingtabelle, was ein Thema war, dass Intel mit der DC S3700 in den Fokus gerückt hat. Vorher waren nämlich binary trees üblich, die eben weniger Platz benötigt haben.
Wer mehr Details dazu wissen will, vor allem was die Nachteile davon sind, möge die ganze Zeit lesen aus der ich gerade zitiert habe, aber Intel ist damals aus gutem Grund zu einer neuen Tabelle übergegangen:
Und die anderen sind nachgezogen, deshalb ist eben 1GB RAM pro 1TB Kapazität die optimale Größe für den DRAM Cache einer SSD, wenn man schnellen und vor auch gleichschnellen Zugriff auf alle Daten auf der SSD haben möchte. Wird eine SSD als Datengrab genutzt und liegen da vor allem große Dateien drauf, dann ist ein DRAM Cache nicht so wichtig.

Auch hier nochmal der Hinweis:
 
Wenn die theoretische Lebensdauer der Zellen dadurch aber von 60 auf 30 Jahre reduziert wird, dürfte das den meisten Usern nichts ausmachen ;-)
Wenn mit den 60 Jahren SLC-SSDs gemeint sind, dann haben wir ein Problem! Denn dann halten QLC-SSDs nur 7 Monate... ;)
 
Die Zellen nutzen doch aber nur stark ab wenn geschrieben wird. Darum sehe ich QLC als sehr gut für Datenspeicherung an. Für schreibintensive Aufgaben braucht man eine starke Server-SSD wenn es lange halten muss. Hier ist es aber auch die Frage der Nutzung: Wer hobbymäßig Videos schneidet braucht nicht unbedingt eine teure SSD dafür. Wer dies berufsmäßig jeden Tag macht braucht eine.

Die reale Lebensdauer würde mich auch mal interessieren. Es gab vor Jahren mal einen Test, wo eine 256 GB 840 Pro nach über 2 PB irgendwann schlapp machte. 256 GB... Mehrere 1000 mal wiederbeschrieben. In Realität kann man das vermutlich nicht so leicht erreichen. Zumindest nicht als Heimanwender. Ich benutze meine SSDs, dennoch haben die maximal 30 TBW nach ein paar Jahren. Das schafft genug Zeit die Datenträger irgendwann zu ersetzen, da der Speicher nur noch günstiger wird.
 
Hi

Würdet Ihr für VMs auf ZFS eher zur DC600M oder zur Samsung PM893 Retail greifen? Für die Kingston spricht sicher der Preis, mit Samsung habe ich bislang aber gute Erfahrungen gemacht. Sonderlich viel wird da nicht geschrieben, aber halt viele Random Zugriffe. Oder geben sich die nicht viel? Liegen halt VMs mit Hostingpanel, DBs, Spieleserver (-Clients) und sowas drauf. Also Querbeet, aber keine Daten im klassischen Sinne. Mehr OS und Anwendungen.

Schiebe ich schon länger vor mir her. Musste letzthin diverse VMs sichern bzw. löschen, da permanent kein Platz vorhanden ist.
 
Samsung PM893 Retail
Was für eine Retail? Die PM sind immer OEM SSDs, also nicht für private Endkunden gedacht und damit gibt es da keine Retail Versionen und man bekommt als privater Endkunden auch keinen Support, auch keine FW Updates und kann die Herstellergarantie auch nicht direkt in Anspruch nehmen. Dies muss wenn, dann über den Händler erfolgen.

Keine Ahnung wie es bei Kingston mit der DC600M in der Hinsicht aussieht, aber persönlich würde ich immer Samsung vorziehen.
 
Keine Ahnung wie der Händler auf die Bezeichnung Retail kommt, vermutlich ist da eine Verpackung dabei, aber dies PM sind immer OEM SSDs. Die kommen auch von einer anderen Tochterfirma als die Consumer SSDs, die OEM Modelle sind von von der Samsung Semicondutor Europe und die ganzen Konsumerprodukte (auch Fernseher, Handys etc.) sind von Samsung Electronics.
 
Ich habe in der Tag nochmal zugeschlagen bei einem DS620Slim und 6x 8TB QVO (für 275€), bevor die SSDs mal wieder drastisch im Preis gestiegen sind.
Die SSDs laufen im Raid 5 bisher ohne jegliche Probleme. Ich wollte einfach viel Speicherplatz haben für Filme, Musik und Co ... als letztlich als Datengrab.
Mit den 100MBit kommen die SSDs jedenfalls nicht an ihre Grenzen ^^.
 
Leise ist ne SSD halt, also wenn man nur son kleines 2-Bay-NAS hat in einer Wohnung und keine großen Datenmengen, würde ich da heute schon SSDs reinstecken. Hat ja (fast) nur Vorteile. Langzeitspeicher auf ne HDD im Idealfall ohne Helium.

Es gibt Hauswirtschaftsräume, Keller oder im Notfall auch die Küche. Ins Wohnzimmer oder Büro kommt natürlich niemals wieder ein NAS mit HDDs.
 
Außerhalb des Luxx gibt es angeblich Menschen, die keine 105m² Wohnfläche pro Person haben...
 
Die OEM Modelle können durchaus mit Garantie kommen, wenn Dell, HP, Lenovo oder sonst eine Firma die kauft, dann kann sie bei einem Ausfall eben die Garantie von Samsung in Anspruch nehmen. Aber der private Endkunde kann dies nicht. Wenn man sie privat einzeln, also nicht als Teil eines Gerätes wie z.B. in einem Notebook, kauft, dann kann Glück haben und vielleicht kann der Händler dann die Garantieabwicklung übernehmen. Das muss dann aber eben ggf, über den Großhändler, Importeur, etc. halt die ganze Kette des Handels bis zurück zu dem gehen der Samsung dieses OEM SSDs abgekauft hat und genau so ist es auch mit den FW Updates.
 
Ich plane eine SSD wie diese für mein Homeserver als Systemplatte zu kaufen.

Hat jemand Praxiserfahrung mit dieser Platte gesammelt?

Was gibt es wohl außer einer Samsung pm893 noch für alternativen? ~500 GB Speicher sollten ausreichen
 
Ich schätze gebrauchte Samsung SM863/SM883 mit gutem alten MLC wären noch eine Erwähnung wert, besonders zu einem guten Preis. Die machen als Systemplatte, wo vor allem Stabilität und Ausfallsicherheit zählen, bestimmt eine gute Figur. Die Kingston ist allerdings wesentlich moderner, wird höhere Performance haben und sicherlich auch nicht von heute auf morgen den Geist aufgeben. Also wenn die Preisdifferenz nicht der Rede wert ist, dann wohl am Ende die Kingston.
 
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