SSD Innenleben: Disk- vs. Datenmanagment

Ambrosius

Well-known member
Themenstarter
Registriert
23 Juni 2022
Beiträge
1.296
hab nun mehrfach auch von anderen Festplattenherstellern über schwache Controller in SSDs Wind gekriegt, jüngst auch die Kingston A400 wo der Controller über den Jordan gegangen ist. Oft ist auch die Firmware dran schuld, dass nicht alles richtig sitzt, und ich muss ehrlich gestehen inzwischen kann ich mir gar keine neue Platte mehr kaufen ohne nicht vorher tagelang zu recherchieren 'wo der Haken dabei ist'

Ich hab mit der 860 Pro immer gute Erfahrungen gemacht, aber die ist inzwischen fast komplett aus dem Markt verschwunden und für unsereiner der gerne alte TPs wiederaufbereitet sind 2,5 Zöller unverzichtbar.

Deswegen wollt ich mal in die Runde fragen, ob jemand gute Alternativen zu der 860 Pro kennt, die nicht überproportional mit fehlerhafte Komponenten auffällig geworden sind..


Edit vom 30.01.2023:

Da das Thema SSD Verlässlichkeit der Samsung 860 Pro hier ausgiebig und leidenschaftlich um themenverwandte Randbereiche erweitert wurde, habe ich es zum Anlass genommen, den Threadtitel zu ändern um die allgemeine Debatte rund um das Innengeschehen einer SSD in Beziehung zum gemeinen User und dem OS aka Betriebssystem weiter fortzusetzen zu können!
 
Zuletzt bearbeitet:
Wie verhält sich das Problem mit LUKS ohne Trim? :unsure:
Welches? Die Read Rate Degeneration? Darauf sollte LUKS keinen Einfluß haben. Letztendlich landen ja die Daten in den Blöcken auf der SSD.

Die Frage, wie es mit freien Blöcken der SSD bei Präsenz eines LUKS-Containers aussieht, ist eine andere. Man möchte ja aus Sicherheitsgründen, daß niemand weiß, welche Blöcke Daten enthalten und welche nicht und schreibt daher zu Beginn alles mit Zufallszahlen voll und macht dann erst sein Filesystem. Wäre also dumm, im Betrieb der SSD per TRIM die tatsächlich belegten Blöcke mitzuteilen. Also wird der ganze LUKS-Container als belegt gelten. Um der SSD dennoch einen Pool freier Blöcke zu lassen müßte man als einen Teil unpartitioniert lassen, je nach Größe 5 bis 20%.
 
Ich habe jetzt noch ein paar Änderungen gemacht und ein Python-Skript erstellt, mit dem man die Ergebnisse hinterher grafisch auswerten kann. Es gibt einen Scatter-Plot der einzenen Dateien und einen gemittelten Trend, in dem ich immer eine Woche zusammenfasse.

Aus meiner Sicht ist das Tool jetzt fertig. Jetzt werde ich es in regelmäßigen Abständen laufen lassen und schauen, ob sich was tut.

Hier ein Beispielplott der Crucial MX500 SATA-SSD meines alten T410. Die habe ich vor 5 Monten eingebaut. Hier sieht man m.E. keine "read speed degeneration".good_ssd.png
 
Das heisst wenn die blauen Punkte und die rote Linie in etwa den gleichen Raum einnehmen, sprich sich mehr oder weniger decken, dann ist alles 'im Lot'?
 
Die durchgezogene rote Linie sollte nach rechts hin nicht deutlich nach unten ausreißen. Je nach gewählter Mindestdateigröße kann man auch sagen, dass die blauen Punkte nach rechts hin nicht nach unten abhauen sollten. Frage mich jetzt aber nicht, wie groß die sein sollte. Mindestens die Sektorgröße halt, weil für jede Datei, die genau der Sektorgröße entspricht oder kleiner ist immer die gleiche Menge vom Datenträger geholt werden muss (eben der Sektor). Je größer die Datei, umso weniger fällt es ins Gewicht, wenn der (letzte) Sektor nich vollständig von der Datei belegt wird.
Dazu kommt aber auch, dass es bei SSDs nicht wirklich spürbar ins Gewicht fällt, wenn die Datei massiv fragmentiert ist und nur jeweils wenige Byte in vielen Sektoren liegen (da sind dann die IOPS interessant, AFAIK), das dürfte aber messbar nach unten ausschlagen.
Beitrag automatisch zusammengeführt:

Ich bin gerade am überlegen, ob man den Graph noch um die Dateigröße anreichern kann, aber mir fällt gerade nicht ein, wie.
 
Das heisst wenn die blauen Punkte und die rote Linie in etwa den gleichen Raum einnehmen, sprich sich mehr oder weniger decken, dann ist alles 'im Lot'?
Es gibt eine Forum, in dem Leute ihre Resultate mit dem Windows-Tool posten. Ein "gutes" Beispiel für so einen Fall von Read Speed Degeneration ist der hier:
https://www.overclock.net/media/no-title.3978748/full

Man sieht, daß nach 12 Wochen die Lesegeschwindigkeit von 350MB/s auf 50MB/s abfällt und auf diesem niedrigen Niveau bleibt.

Mein Graph hat Fehlerbalken (+/-ein Sigma, d.h. mit einer Wahrscheinlichkeit von 66% liegt der wahre Wert in diesem Bereich), die ich aus der Streung errechne. Manchmal sind die sehr groß, wenn in dieser Woche nur wenige Datein erneuert wurden und ein einzelne Ausreißer z.B. durch Caching-Effekte gibt.
Die Fehlerbalken zeigen, daß es keinen Trend gibt - die gestichelte Mittelline (mittlere Geschwindigkeit aller Dateien) ist innerhalb aller Fehlerbalken. Man könnte jetzt darüber philosophieren, ob es Gauß-verteilte Fehler sind oder systematische und wieviel Sinn die Fehlerbalken haben. M.E. alles müsig - es wird sich letztendlich ein Trend zeigen, wenn der Effekt da ist.
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Hast recht. Ich hab einen Abschnitt in README.md gesetzt:


Markdown (GitHub flavored):
## Example
Suppose our Linux installation has three separate file systems mounted as /, /home and /media. 
We want to scan all files greater then 1MB and write the output to readspeed.dat:

    $ ./degentest -p / -p /home -p /media -m 1M -o readspeed.dat
Now we want to plot the results:

    $ ./plotspeedtest.py readspeed.dat
If we call plotspeedtest.py without filename a file picker lets us select the file we want to plot.
 
Also, die Ergebnisse des Testers sind hier durchwachsen. Ein paar 3 Tage alte Dateien haben nur 110 bzw 300 MB/s geschafft, wohingegen 99% der Daten noch am Maximum der SATA3-Schnittstelle liegen. Ich glaube nicht, dass das Alter der Dateien ausschließlich ausschlaggebend sein kann, sondern es mag auch daran liegen dass der Controller mit dem Liefern der Daten nicht hinterherkommt - oder eben andere Gründe.

Jedenfalls die MB/s als astreinen Wert zum "Spannungs-Verfall" oder Bit-Rot herzunehmen geht wohl nicht. Das Tool mehrmals hintereinander laufen zu lassen würde hier helfen.

Die SSD hat eine SMART-Laufzeit von 3 1/2 Jahren.. ich hab sie wohl vor ca. 5 gekauft.

Habe aber auf der getesteten Partition auch hin und wieder mal MyDefrag "Monthly" laufen lassen, wobei ja der gesamte Inhalt der Partition brav bewegt wird. Bei E:\ war das nicht der Fall.
 

Anhänge

  • Clipboard-1.png
    Clipboard-1.png
    35 KB · Aufrufe: 10
  • Clipboard-2.png
    Clipboard-2.png
    33,9 KB · Aufrufe: 7
Zuletzt bearbeitet:
Jedenfalls die MB/s als astreinen Wert zum "Spannungs-Verfall" oder Bit-Rot herzunehmen geht wohl nicht. Das Tool mehrmals hintereinander laufen zu lassen würde hier helfen.
Einzelwerte sind m.E. nicht aussagekräftig, da andere Faktoren reinspielen können, z.B. Zugriffe von konkurrierenden Prozessen auf die SSD. Außerdem weiß man nie, ob sich der Controller der SSD mal kurz eine Auszeit nehmen muß.

Mehrmaliges Laufen lassen ist problematisch: einen zweiten Lauf sollte man nur nach einem Reboot machen, da nach einem Durchlauf die zuletzt gelesenen Dateien noch im Cash stecken. Sieht man sehr schön an meinem Programm degentest. Wenn man es zweimal hintereinander auf einem Verzeichnis mit nur ein paar GB Daten laufen läßt, sind beim zweiten Durchlauf alle bei ~10GB/s.
 
Hast recht. Ich hab einen Abschnitt in README.md gesetzt:


Markdown (GitHub flavored):
## Example
Suppose our Linux installation has three separate file systems mounted as /, /home and /media.
We want to scan all files greater then 1MB and write the output to readspeed.dat:

    $ ./degentest -p / -p /home -p /media -m 1M -o readspeed.dat
Now we want to plot the results:

    $ ./plotspeedtest.py readspeed.dat
If we call plotspeedtest.py without filename a file picker lets us select the file we want to plot.
Danke! Unter Debian 11 bekomme ich es trotzdem nicht hin .... :confused:

Code:
marc@t490:~$ Downloads/Software/SSD-Read-Speed-Degen-Test/plotspeedtest.py res.dat
bash: Downloads/Software/SSD-Read-Speed-Degen-Test/plotspeedtest.py: /usr/bin/python: bad interpreter: No such file or directory

Code:
python3 Downloads/Software/SSD-Read-Speed-Degen-Test/plotspeedtest.py
Traceback (most recent call last):
  File "/home/marc/Downloads/Software/SSD-Read-Speed-Degen-Test/plotspeedtest.py", line 8, in <module>
    from matplotlib import pylab
ModuleNotFoundError: No module named 'matplotlib'

OK für Debian 11:

Code:
apt install python3-matplotlib

und Aufruf mit:

Code:
python3 Downloads/Software/SSD-Read-Speed-Degen-Test/plotspeedtest.py ~/res.dat

Works!
 
Zuletzt bearbeitet:
Das ist halt leider das Problem mit den vielen verschiedenen Linux-Distributionen. Da heißen die Pakete alle leicht anders. Schau mal nach, ob es /usr/bin/python3 bei Dir gibt. Bei Arch ist /usr/bin/python ein Link auf /usr/bin/python3 - der Link fehlt anscheinend bei Debian. Dann müßte es genügen, die erste Zeile des Python-Skripts auf /usr/bin/python3 abzuändern. Ich das Skript entsprechend ändern, wenn es damit auf mehr Distributionen läuft
 
Danke - ich werde es ausprobieren und ggf. in das Programm einbauen.
Beitrag automatisch zusammengeführt:

So, hab das mal ausprobiert. Funktioniert. Man sieht jetzt, daß die Ausreißer nach oben (also, die richtig nach oben abhauen) Programme sind, die offensichtlich gerade laufen (z.B. networkmanager).

Ich habe es ins Programm aufgenommen. Dazu muß es allerdings mit root-Rechten laufen. Hat es die nicht, gibt es eine Warnung aus und macht so weiter.
 
Zuletzt bearbeitet:
Ich weiss nicht, ob das Subthema "SSD - Controllerschaden" ein totes Pferd ist oder nicht, aber ich bin hier bei Kuert über einen sehr interessanten Artikel gestoßen, den ich euch selbstverständlich nicht vorenthalten mag. Insbesondere mit Blick auf künftige SSD Käufe ist es ratsam sich den Artikel v.a. die zweite Artikelhälfte mal zu Gemüte zu ziehen und selbst mal Bilanz ziehen, ob sich ein Kauf lohnt. Ich wünschte ich hätte ihn vorher gelesen. Weiss allerdings nicht ob das noch den aktuellen Stand der Technik widerspiegelt. Die Ingenieure unter den Foristen wissen sicherlich mehr dazu zu berichten.
 
Ist Sandforce nicht mittlerweile ein alter Hut? Kenne das noch von vor X Jahren, wo der Controller auch für Probleme bekannt war. Generell ja, auf Rettung würde ich bei SSDs nie hoffen. Wenn der Controller wech ist, ist der NAND quasi ein Jackson Pollock an Daten. Das ist aber kein Argument gegen einen Kauf für mich. Gerade bei Samsungs gehen die Controller so selten kaputt dass das eben eine positive Kosten/Nutzen Rechnung bleibt. Man macht Backups und darf den NAND ruhig strapazieren.

Hardwareverschlüsselung sollte man sowieso tunlichst ausschalten... die taugt nicht so viel wie eine gescheite Softwarelösung. LUKS, BitLocker, VeraCrypt.. mit AES ist das alles ziemlich schnell heutzutage.

Das einizige wo ich einen Bogen drum machen würde sind die billigen Phison-Controller sowie alles was keinen RAM mit drin hat. Das senkt die Lebenserwartung drastisch.
 
Kein Backup, kein Mitleid.
Controller können immer sterben, das war such bei HDDs nicht anders. HDDs sind halt seltener HW-verschlüsselt und daher 'leicht' zu retten. SSD-Controller ohne HW-Verschlüsselung gibt es meines Wissens nicht mehr.
 
Moment, die wird doch nur aktiviert wenn man das im UEFI so eingestellt hat?

Hmm... weder, noch.

ArchWiki schrieb:
In fact, in drives featuring full-disk encryption, data is always encrypted with the data encryption key when stored to disk, even if there is no password set (e.g. a new drive). Manufacturers do this to make it easier for users who do not wish to enable the security features of the self-encrypting drive. These self-encrypting drives can be thought of as having a zero-length password by default that always transparently encrypts the data (similar to how passwordless SSH keys can provide somewhat secure access without user intervention.

If a user wishes to "enable" encryption at a later stage, they are able to configure an authentication key (such as a passphrase) which encrypts the existing data encryption key. The user will then be prompted for their passphrase when decrypting the data encryption key in the future. Crucially, because the existing data encryption key is not regenerated, setting a passphrase allows for the drive to be locked while preserving existing encrypted data on the disk, avoiding the need for the drive to be re-encrypted.
 
Zuletzt bearbeitet:
Ich kenne das so, dass der Controller eine zufällige Keyphrase erzeugt, die er dann (auf der SSD? in einem Bereich, auf den nur er Zugriff hat) ablegt. Diese Keyphrase wird verworfen und eine neue erzeugt, wenn man Secure Erase ausführt...:
OnTrack schrieb:
Hintergrund: Die Samsung SSD Festplatten der 840 EVO und PRO Serie verfügen standardmäßig über eine automatische Verschlüsselung, die ohne Wissen des Nutzers greift. Bei jedem neuen Zugriff auf die jeweilige Platte fragt der Controller den auf der Festplatte vorhandenen Schlüssel ab, um diese zu aktivieren.

Crucial schrieb:
Die Mehrheit der Crucial® SSDs sind SEDs.
[...]
Bei einer SED ist die Verschlüsselung immer eingeschaltet, d. h. wenn Daten in die SED geschrieben werden, werden sie vom Controller verschlüsselt und dann beim Lesen aus der SED entschlüsselt. Die Funktion des Passwortschutzes muss von der Verschlüsselungsverwaltungssoftware aktiviert werden. Wenn dies nicht geschieht, kann jeder beliebige Benutzer die Daten auf dem Laufwerk lesen. Mit anderen Worten: die SED wird alle Informationen für jeden, der danach fragt, großzügig entschlüsseln, es sei denn, es wird eine Sicherheitsmanagementsoftware installiert, um dies zu verhindern.

D.h.: Wie üblich bei asymmetrischer Verschlüsselung wird ein Schlüssel erzeugt, mit dem die Daten asymmetrisch verschlüsselt wird. Und das unabhängig davon, ob man die Verschlüsselung aktiviert oder nicht. Die Verschlüsselung wirkt sich dann nur auf den Schlüssel aus, welcher bei aktiver Verschlüsselung symmetrisch mit dem eingegebenen Passwort verschlüsselt wird und auch nur mit diesem wieder entschlüsselt werden kann.
 
Wieso asymmetrische Verschlüsselung? Das macht man garantiert nicht so. Auch PGP macht das nicht so. Einerseits aus Performancegründen und zweitens ist die asymetrische Verschlüsselung prizipiell nicht für die direkte Verschlüsselung vom Daten geeignet (deterministisch, Klartextangriff ist möglich).

Hier wird garantiert AES-Verschlüsselung gemacht und beim Setzen des Passwortes der AES-Schlüssel via Trap-Door-Funktion verschlüsselt. Solange kein Passwort gesetzt ist, ist der Schlüssel in der SSD unverschlüsselt gespeichert, vermutlich in einem nur durch den Controller zugänglichen Bereich, wie du schon geschrieben hast.
 
vermutlich in einem nur durch den Controller zugänglichen Bereich, wie du schon geschrieben hast.
Dazu gab es vor einer Weile einen lustigen Talk beim CCC, da hat es einer geschafft den Controller durch wear levelling dazu zu bringen, teile des Speichers wo der Key hinterlegt war in den Userspace zu exposen, wenn ich mich richtig erinnere.


Allgemein guter Talk zum Thema, einer der interessantesten die ich live gesehen hab.

Meine bottom line: für meine Anwendung (jemand klaut mein Notebook und soll nicht an meine Daten kommen) reichen moderne SEDs dicke, jedenfalls von Samsung die es halbwegs vernünftig umzusetzen scheinen.

Wenn man erwartet, dass das Gerät von einem Geheimdienst oder fortschrittlicher Industriespionage mit ~unlimitiertem Budget angegriffen wird, sollte man lieber auf sinnvolle Software Verschlüsselung setzen. Wobei da dann die Frage ist, ob Leute die das Budget und den Willen hätten, SEDs zu knacken, einem nicht auch einfach so lange mit einem Hammer auf die Kniescheibe klopfen bis man das Passwort rausgibt...
 
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben