SSD Innenleben: Disk- vs. Datenmanagment

[Ambrosius]

Secure Erase setzt die interne Liste Belegungsliste der SSD wieder auf Null und löscht alle Blöcke.

dann wäre das so in etwa wie eine neue Partitionstabelle anzulegen, verstehe ich das richtig?

Beitrag automatisch zusammengeführt: 30 Jan. 2023

Ich habe mich (wie man ja offensichtlich sieht) entschieden, dass ich auch die Speichermodule mit kühle, da mir auch hier die Werte so besser gefallen (abgesehen davon, dass man dadurch ja auch wieder mehr Fläche hat, auf die der Controller ableiten kann vs. der Controller heizt die NANDs auf).

Ja das sehe ich, HWinfo liest mehrere Temperaturen, könntest du die freundlicherweise ganz sichtbar machen, also die Beschreibung?
Leider haben nur die wenigsten SSDs Temperatursensoren für Controller UND Flash Speicher, ein Pluspunkt für die 980 Pros

 

[Korfox]

Secure Erase setzt die interne Liste Belegungsliste der SSD wieder auf Null und löscht alle Blöcke. Mit Read Speed Degeneration hat das nichts zu tun.

Secure Erase schmeißt vor allem den Schlüssel weg, mit dem die Daten verschlüsselt wurden - deswegen heißt es Secure Erase \o/. Dass die Belegungsliste gelöscht wird ist ein Nebeneffekt.
Und natürlich hat das mit Read Speed Degradation zu tun. Neu geschriebene Daten unterliegen ihr nicht - und wenn ich die SSD komplett lösche und neu installiere, dann sind alle Daten neu installiert. Um den entsprechenden Aufwand.

Keine Ahnung, was Clonezilla macht - habe ich noch nie genutzt. Ich nutze tar zum OS-Umziehen Schreibt Clonezilla nur die tatsächlich belegten Blöcke oder macht das ein Diskimage?

Es kopiert nur vorhandene Daten, ja.

Overprovisioning meint eigentlich, daß die SSD intern größer ist als sie nach außen bekannt gibt - das ist eine Firmware-Geschichte, um einen SLC-Cache und Reserveblöcke (Spares) für totgeschriebene Blöcke zu haben. Das mit dem unpartitionierten Teil hat eine andere Funktion. Diese Blöcke werden vom OS nicht beschrieben. Selbst wenn die SSD ohne TRIM betrieben wird, stehen diese immer zur Verfügung. Wenn die SSD denkt, daß aufgrund eines fehlenden Trims alle Blöcke des partitionierten Teils belegt sind hat sie noch diesen Pool.
Sofern man kein TRIM nutzt, sollte man auf jeden Fall so einen 10 bis 20% Puffer beim Partitionieren vorsehen (bei eine 4TB-SSD werden wohl auch 5% reichen, da man m.E. selten mehr als 100GB am Stück schreibt), bei Verwendung von TRIM ist es nicht nötig, außer man will verhindern, daß die SSD randvoll geschrieben werden kann.

Overprovisioning heißt auf deutsch Überversorgung. Ob das jetzt von Werk da ist, oder manuell eingestellt wird - beides nennt sich Overprovisioning. Und gute Controller können auch in letzterem Fall damit umgehen, dass der freie Bereich genutzt wird, um fehlerhafte Speicherzellen zu ersetzen und wear-levelling zu betreiben. Das war nebenher auch schon bei HDDs durchaus gängige Praxis und empfehlenswert - und dass ohne dass man durch den SLC-Cache einen Geschwindigkeitsvorteil gehabt hätte.

Doch, siehe Erklärung oben für den unpartitionierten Puffer. Es ist halt eine Lösung, die nominellen Speicherplatz kostet.

Es ist etwas anderes. TRIM markiert leere Zellen als leer, Overprovisioning stellt "zusätzliche Zellen" als Cache zur Verfügung.

Beitrag automatisch zusammengeführt: 30 Jan. 2023

Ja das sehe ich, HWinfo liest mehrere Temperaturen, könntest du die freundlicherweise ganz sichtbar machen, also die Beschreibung?
Leider haben nur die wenigsten SSDs Temperatursensoren für Controller UND Flash Speicher, ein Pluspunkt für die 980 Pros

Das bringt nichts. Die Temperaturen heißen einfach "Festplatten-Temperatur" - "Festplatten-Temperatur 3" ist der Controller, "Festplatten-Temperatur" und "Festplatten-Temperatur 2" sind die beiden NAND-Chips.

 

[ebastler]

dann wäre das so in etwa wie eine neue Partitionstabelle anzulegen, verstehe ich das richtig?

Normales formatieren: Du löschst alles das drauf ist, aber das weiß der SSD controller ja nicht. Die "Daten" liegen noch im Flash, und der Controller muss sie auch so behandeln. Dass du als User sie aus der Partitionstabelle geworfen hast, kann der Controller der nur 1n und 0en in seinen Blöcken sieht nicht wissen. Da kommt dann wieder das ins Spiel:

Wenn in dem Block bereits etwas steht, dann liest er die Daten aus und verodert sie(?) mit den zu schreibenden Daten, um das Ergebnis zurückzuschreiben. Dadurch sinkt die Performance

Secure erase lässt die Daten zwar auch im Flash, sagt dem Controller aber "ganzer Flash ist leer". Ob da dann noch eine 1 oder 0 drin steht interessiert den an der Stelle nicht mehr, er schreibt einfach, weil er weiß, dass nichts davon relevante Daten sind. Was dazu kommt - aktuelle (bessere) Laufwerke arbeiten eigentlich immer verschlüsselt. Secure erase löscht den Schlüssel aus dem Controller und generiert einen neuen. Damit sind die Daten (sofern der Hersteller nicht bei Key generation gepfuscht hat) unmöglich wiederherzustellen. Kann manchmal interessant sein.

 

[rennradler]

Die Sache ist doch SOOO einfach:

Der Controller präsentiert dem OS die SSD als einen Haufen durchnummerierter LBAs (Blockgröße ist traditionell 512Byte, 2048 gibt es aber auch). Der Controller registiert nur, welche Blöcke beschrieben wurden. Mehr weiß der nicht, der kennt keine Partitionen, keine Partitionstabelle, kein Filesystem, nichts der gleichen.

Alles darüber ist OS-Sache. Einen neue Partitionstabelle anlegen heißt, da werden aus Sicht des Controllers ein paar LBAs mit Daten belegt.

Secure Erase hat den Haupteffekt, daß alle Blöcke gelöscht werden in die Belegungstabelle auf Null gesetzt wird, kann auch noch weiter Nebeneffekte haben. Letztendlich präsentiert sich die SSD dann wie fabrikneu, außer daß sie halt schon Verschleiß hat.

 

[Korfox]

Secure erase lässt die Daten zwar auch im Flash, sagt dem Controller aber "ganzer Flash ist leer". Ob da dann noch eine 1 oder 0 drin steht interessiert den an der Stelle nicht mehr, er schreibt einfach, weil er weiß, dass nichts davon relevante Daten sind. Was dazu kommt - aktuelle (bessere) Laufwerke arbeiten eigentlich immer verschlüsselt. Secure erase löscht den Schlüssel aus dem Controller und generiert einen neuen. Damit sind die Daten (sofern der Hersteller nicht bei Key generation gepfuscht hat) unmöglich wiederherzustellen. Kann manchmal interessant sein.

Secure Erase schmeißt vor allem den Schlüssel weg, mit dem die Daten verschlüsselt wurden - deswegen heißt es Secure Erase \o/. Dass die Belegungsliste gelöscht wird ist ein Nebeneffekt.
Und natürlich hat das mit Read Speed Degradation zu tun. Neu geschriebene Daten unterliegen ihr nicht - und wenn ich die SSD komplett lösche und neu installiere, dann sind alle Daten neu installiert. Um den entsprechenden Aufwand.

... jo.

 

[ebastler]

Du warst schneller, als ich angefangen hab zu tippen stand das noch nicht da - daher etwas Redundanz

 

[rennradler]

Secure erase lässt die Daten zwar auch im Flash, sagt dem Controller aber "ganzer Flash ist leer". Ob da dann noch eine 1 oder 0 drin steht interessiert den an der Stelle nicht mehr, er schreibt einfach, weil er weiß, dass nichts davon relevante Daten sind. Wa

Nein, das stimmt nicht, die ATA-Spezifikation sieht vor, daß die Daten PHYSIKALISCH gelöscht werden.

 

[Korfox]

Nein, das stimmt nicht, die ATA-Spezifikation sieht vor, daß die Daten PHYSIKALISCH gelöscht werden.

Nein, Secure Erase bei (modernen) SSDs verwirft den Verschlüsselungsschlüssel. Die Speicherzellen bleiben in ihrem Zustand. Bei HDDs werden alle magentischen Zellen mit einem festgelegten Muster überschrieben, aber wir reden von SSDs.

In der Hinsicht mag die Spec etwas vorschreiben, die Implementierung ist aber anders.

Beitrag automatisch zusammengeführt: 30 Jan. 2023

Noch etwas interessantes zu TRIM und der Formatierung eines Datenträgers:

SSD Secure Erase – Thomas-Krenn-Wiki

In diesem Artikel zeigen wir wie Sie unter Linux ein Secure Erase einer SSD durchführen. Sie können damit die Performance vieler gebrauchten SSDs für die künftige Anwendung steigern. Es gehen dabei aber alle Daten der SSD verloren.

www.thomas-krenn.com

Bei NTFS ab Win 7, Ext4 ab mke2fs 1.41.10 oder XFS ab xfsprogs 3.1.0 wird automatisch ein fstrim nachgeschickt, womit auch hier die Speicherzellen im Controller als leer markiert werden (insofern dieser TRIM unterstützt).

 

[rennradler]

Nein, Secure Erase bei (modernen) SSDs verwirft den Verschlüsselungsschlüssel. Die Speicherzellen bleiben in ihrem Zustand. Bei HDDs werden alle magentischen Zellen mit einem festgelegten Muster überschrieben, aber wir reden von SSDs.

Mag sein, daß das jetzt bei neueren SSDs so gemacht wird. Wichtig ist aber, daß bei Secure Erase der Controller garantiert alle Blöcke als frei ansieht. Bei mkfs wird ja nur die betreffende Partition dem Controller gemeldet.

Daher mag ich die Clone-Tools eben nicht. Wenn die Diskimages schreiben, fällt das alles weg. Dann ist man hinterher darauf angewiesen, daß das OS das mit TRIM wieder ins Lot bringt.

Jetzt sind wir aber weit abgekommen von der Read Speed Degeneration. Eigentlich sollte sich die SSD darum kümmern, anständig zu funktionieren.

 

[Ambrosius]

Ich hab den Threadtitel jetzt doch geändert, da ich es für angebracht hielt. Es wurde auf viele Aspekte hingewiesen, die der Datenintegrität zuträglich sind und ich glaube je tiefer man das Thema betrachtet, desto näher gelangt man auch an die physikalischen Grenzen dieser spezifischen Datenspeichertechnik. Und es ist sicher ein Wunder der Moderne, dass man fast keinerlei spürbare Latenzen mehr im laufenden PC Betrieb hat, die andere Seite der Medaille sind aber eben die wie hier bereits immer häufiger zutage auftretenden Begleiterscheinungen moderner SSDs. Und bei NVMes sind sie tatsächlich noch besser zu beobachten, als bei SATA oder eigentlich müsste ich sagen bei AHCI, wenn wir hier bei einer Einheit bleiben wollen, nämlich dem Übertragungsprotokoll.

Scheinbar verhält es sich so: je schneller die heutigen Datenträger lesen und schreiben, desto mehr kristallisieren sich die damit verbundenen Nebenwirkungen wie erhöhte Temperaturen auf der Hardwareebene einerseits und komplexere Firmwareanforderungen auf der Softwareebene andererseits. Diesen Spagat zu meistern wird zunehmend schwieriger, deswegen gerät ja auch Samsung, der bislang unangefochtene Platzhirsch unter den SSD-Herstellern, immer wieder in den letzten Jahren ins Wanken. Was hat das zu bedeuten ist letztlich die Frage? Was sind die Implikationen davon und was machen wir mit unseren Daten, dann außer sie natürlich regelmäßig zu sichern?

Erkennt ihr einen Trend? oder ist das alles nur eine vorübergehende Phase..

 

[ebastler]

Meine 980 Pro im T14s G3 bleibt selbst im Stresstest schön kühl, kann mich da nicht beklagen.

 

[rennradler]

Ich denke, das größte Problem sind die Kosten. Samsung kann nicht beliebig mehr verlangen und im typischen Sch***längenvergleich der ganzen Gamer-Magazine (wie viele GB pro Sekunde schafft das Ding) fallen halt so versteckte Problem nicht auf.
Daten sichern muß man sowieso, aber so ein SSD-Ausfall ist selbst bei aktuellem Backup mit viel Unannehmlichkeiten verbunden.

 

[Korfox]

Ich denke, das hat verschiedene Gründe.
Der Weg von SLC über MLC, TLC zu QLC ist sicher dem Geld und dem Bedarf von immer mehr Speicherplatz auf immer weniger Raum geschuldet. Dabei soll die Performance möglichst nicht schlechter werden, wenn nicht sogar steigen. Wie man das auf logischer Ebene hinbekommt haben wir hier ja ausführlich diskutiert. Die physikalische Ebene sind Taktraten und Strukturbreiten. Im Gegensatz zu CPUs und GPUs ist es ja nicht so, dass eine neue NAND-Architektur erfunden werden könnte und auch sonst bietet Speicher deutlich weniger architekturellen Entwicklungsspielraum. Also werden Strukturbreiten reduziert, um mehr Speicher auf weniger Fläche zu bekommen. Dadurch steigen die Widerstände, was wieder erhöhte Abwärme zur Folge hat. Die Performance steigert man indem man den Speicher schneller anspricht, was wieder höhere Spannungen erfordert, was höhere Abwärme zur Folge hat.
Und dass Halbleiterhaltbarkeit stark an der Temperatur skalieren, mit der sie beaufschlagt werden, ist ja nicht neu.
Das meine Gedanken zu zumindest einem Teil der Phänomene.

 

[Ambrosius]

Es gibt brancheninterne Tendenzen wir PLC (also Penta Level Cell) wo 5 Bits pro Zelle geschrieben werden können, aber selbst das ist noch Zukunftsmusik. Der Ertrag bei QLC war schon niedriger als erwartet, dass es die Entwicklungskosten nur marginal reingeholt hat. PLC wird da wohl auch noch länger auf sich warten lassen, nicht das wir danach rufen würden, aber nur mal als Fußnote.

Wohin sich NAND insgesamt weiterentwickeln wird, kann ich auch nicht genau sagen, aber mir ist es lieber dass man Vorhandenes weiter optimiert anstatt ständig neue, aber unausgegorene Modelle oder Firmwareupdates mit Bugs releast. Muss nicht sein und die meisten wissen ja dass man von ausgereifter Technik noch Jahre danach zehren kann, weil sie sich A. bewährt haben und B. als mehr oder minder verlässlich gelten. Weil sind wir mal ehrlich: Nicht jede Komponente im PC muss auf dem gleichen Niveau Verlässlichkeit bieten, wie es ein Datenträger tun muss.

Schließlich wird man künfitg zumindest im Desktopbau nicht umhin kommen, Heatsinks mit Mini-Lüftern zu versehen, was es zum Teil schon gibt. Was sich Laptophersteller einfallen lassen werden, damit wir nicht mit Kupferplättchen und Heissluftpistolen und dergleichen Hand anlegen müssen, bleibt abzuwarten. Vielleicht wird es wie bei CPUs und den TDP-Begrenzungen im mobilen Bereich zu einer ähnlich gearteten suboptimalen Lösung kommen was dann nämlich so aussieht wie wir es bereits jetzt schon kennen: die künstliche Limitierung der Leistung. zb durch x2 statt x4 PCIe Lanes... Das kann auch durch andere Dinge so konstruiert sein, aber nichts desto trotz, wer würde nicht gern seinen Porsche ausfahren, anstatt dauernd bei 110 kmH gekappt zu werden.

 

[Korfox]

Stillstand lässt sich halt nicht verkaufen.
Schon der Sprung von SATA (600MB/s auf die ersten NVMe (~1000MB/s) war kaum noch wahrnehmbar, spätestens der Sprung von PCIe 3.0 (3500MB/s) auf 4.0 (7000MB/s) dürfte selbst für den Drummer von AC/DC nicht mehr wahrnehmbar sein. Trotzdem (und da zähle auch ich mich dazu) bauen die Leute Samsung 980 pro in ihre Rechner ein, obwohl sie aktuell nur in der PS5 wirklich eine Daseinsberechtigung hat.

Ob man Heatsinks mit Mini-Lüftern versehen muss? Sehe ich nicht kommen. Bzw. es gab immer unterschiedliche Philosophien. Ich gehöre immer zu der Gruppe, die sagen: Auf Hitzequellen gehören Kühlkörper und moderate Lüfter, derweil ein guter Airflow für die eigentliche Kühlung sorgt. Andersrum kann man natürlich auch jede Hitzequelle möglichst dezentral mit massiv warmer Luft aus dem Gehäuse versorgen und den Airflow vernachlässigen oder man pappt überall die Wasserkühlung dran und hat die Lüfter dann nur noch am Radiator.

 

[rennradler]

Es scheint tatsächlich unter Linux kein Tool zu geben, das auf die "SSD Read Spead Degeneration" testet.
Ich hab mir jetzt selber eines geschrieben. Ich habe dazu Low-Level-I/O benutzt, um Artefakte von C++ Bibliotheken auszuschließen.

Momentan hat es noch keine grafische Darstellung der Ergebnisse, sondern schreibt sie in eine Textdatei (Datei, Alter, Größe, mb_per_second). Diese diese kann man z.B. mit mit einer Tabellenkalkulation visualisieren. Eventuell schreibe ich noch einen Wrapper für gnuplot, damit die Daten bequem visualisiert werden.

Ich hab es mal auf meine Samsung 970 Pro losgelassen (muß man als logischerweise mit root-Rechten ausführen) und bis jetzt sehe ich noch keine Auffälligkeiten. Das ist auch nicht verwunderlich, da ich die SSD erst Ende Dezember eingebaut habe, die älteste Datei erst gut 1 Monat alt ist.

Ich weiß nicht, ob so ein Programm für die Allgemeinheit von Interesse wäre. Dann könnte ich es auf github öffentlich machen.

 

[Korfox]

Lass mich kurz für die Allgemeinheit sprechen...

Ja, wäre es.

 

[rennradler]

Dann muß ich noch ein bisschen Testen und ein Readme schreiben.

 

[Ambrosius]

Yes please, Github wäre def ein Segen für alle Non-Script Linuxer ️

 

[rennradler]

Initiale Version ist fertig. Könnt Ihr Euch auf GitHub anschauen.

GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration Problems

Simple test program for Linux to detect SSD Read Speed Degeneration Problems - GitHub - bernhardg67/SSD-Read-Speed-Degen-Test: Simple test program for Linux to detect SSD Read Speed Degeneration P...

github.com

Ich habe kein Binary eingestellt, da ich auf Arch bin und daher immer die neuesten Libraries habe. Zudem könnt ihr euch den Source Code ansehen und euch überzeugen, daß das Programm sauber ist. Für Bug-Freiheit kann ich nicht garantieren, nur für Gutwilligkeit.

Sollte sich auf jedem anständigen Linux-System kompilieren lassen. Braucht hat gcc/g++ (mit C++17 features), cmake und GNU find.