SSD Innenleben: Disk- vs. Datenmanagment

[seagate]

Zum Thema 870 Evo, die hier im Thread mehrfach gepriesen wurde (ich weiss nicht ob die Evo Plus auch betroffen ist):

Nach kurzer Recherche aufgrund der Tatsache dass ich ein konkretes Kaufangebot diesbezüglich habe ist mir gleich noch ein Skandal zu der baureihe aufgepoppt. Und zwar aufgepasst, das könnte auch euch betreffen die die 870 Evo im Betrieb haben, es gab wohl mehrere Chargen aus dem Produktionsjahr 2021 wo massenweise Lesefehler auftraten, bis hin zu dem punkt dass man seine Daten nicht mehr wegkopieren konnte. Sieher auch hierzu den ausführlichen Thread im TechpowerUp Forum

Das Problem konnte wohl nachträglich nicht durch ein FW Update behoben werden, wohl aber bevor das Problem auftritt vermieden werden. Keine Ahnung was genau da schief gegangen ist (ich lese noch auf S. 4)

Aber das Problem tritt wohl häufiger auf v.a. wenn der Wert für TBW ca. 10 erreicht hat. Vorher wohl nicht.

Ich habe 5 Stück dieser Serie in Verwendung, bis jetzt noch keine Probleme.

 

[rennradler]

Ich bin jetzt in einen aktuellen c't-Artikel (02/23) auf folgendes Problem aufmerksam geworden: etliche SSDs erleiden "Read Rate Degeneration". Damit ist gemeint, daß die Leseraten von älteren Dateien dramatisch einbrechen. Gund ist wohl, daß aufgrund von Lecks in den FLASH-Zellen die Signalqualität abnimmt und dann die Fehlerkorrektur der SSD ein mehrfaches Lesen der Blöcke durchführt, bis die Datenitegrität sichergestellt ist, was natürlich die Leserate einbrechen läßt.
Eigentlich ein alter Hut - bekannt geworden bein Samsung 840-Serie und es wurde von Samung auf die brutale Art gelöst: eine geänderte Firmware schreibt alte Daten im Hintergrund regelmäßig neu.
Allerdings soll das Problem jetzt bei aktuellen SSDs vieler Hersteller wieder auftauchen. U.a. soll meine 970 PRO betroffen sein.
Es gibt ein Freeware-Tool, mit dem man dem Problem auf die Schliche kommen kann (SSD Read Speed Tester) und ein Es gibt auch ein "Refresh-Tool", das alte Dateien neu schreibt. Beides leider nur für Windows.
Da ich aber nur Linux habe, muß ich mal schauen, ob es da was vergleichbares gibt. Schlimmstenfalls muß ich selber in die Tasten greifen - zumindest ein Read Speed Tester sollte in überschaubarer Zeit zu schreiben sein, da der nicht-destruktiv arbeitet. Ein Refresh-Tool sollte man schon gut testen ...

 

[Korfox]

Read Speed Degradation ist ja grundsätzlich kein völlig neues Thema. Hier haben sich auch ein paar dazu zusammengetragen: https://www.computerbase.de/forum/t...mb-s-980pro-auch-nicht-ohne-probleme.2111994/

Grundsätzlich liegt es natürlich in der Verantwortung des Controllers, regelmäßig die beschriebenen Zellen zu refreshen. Ansonsten gibt es dazu auch - zumindest für Windows - Software wie DiskRefresh. Unter Linux sollte es ein dröges sudo dd if=/dev/sda of=/dev/sda bs=1M tun (korrigiert mich gerne, wenn ihr denkt, dass ich mit dem dd-Befehl irgendwas zerstöre, in meinen Augen wird aber einfach nur jede Zelle des Datenträgers gelesen und unmittelbar geschrieben).

Und wenn man schon dabei ist: SSDs sind keine Backup-Medien. Wenn man sie nicht regelmäßig mit Strom versorgt verlieren sie ihre Daten...

 

[T400Fan]

Ich würde noch gerne ein Wort zu den QLC SSD verlieren.
Bei mir werkelt seit einiger Zeit eine Samsung 860QVO 2.5" im T400 als Systemfestplatte und mir ist nichts negatives aufgefallen.
Sie hat inzwischen auch einige Betriebsstunden und TBW angesammelt aber funktioniert wie am ersten Tag.
Ich möchte damit eigentlich betonen, dass ich die Wahl der SSD mehr von der Marke als vom verbauten Speichertyp abhängig mache und eine Samsung SSD mit QLC würde ich persönlich einer preiswerten TLC SSD vorziehen.

 

[rennradler]

Unter Linux sollte es ein dröges sudo dd if=/dev/sda of=/dev/sda bs=1M tun (korrigiert mich gerne, wenn ihr denkt, dass ich mit dem dd-Befehl irgendwas zerstöre, in meinen Augen wird aber einfach nur jede Zelle des Datenträgers gelesen und unmittelbar geschrieben).

Ist Linux ein Multi-Tasking-Betriebssystem? Hat Linux ein Filesystem?

 

[Korfox]

Ist Linux ein Multi-Tasking-Betriebssystem? Hat Linux ein Filesystem?

Ja, ja.
Wie kommt die Frage zustande und wo ist der Kontext?

Also... zur Erklärung:
Ich kenne kein Linux, das kein Multitasking und auch Multiuser ist - im Gegensatz zu Windows ist das sogar per Design von Anfang an so implementiert. https://debiananwenderhandbuch.de/multiuser.html

Und zur zweiten Frage: Ein Betriebssystem "hat" kein Dateisystem. Sowohl Linux nicht, als auch Windows nicht, als auch MacOS nicht. Ein Betriebssystem unterstützt nur Dateisysteme. Linux vernehmlich ext2, ext3, ext4, dazu kommen ReiserFS, btrfs und XFS. Weiterhin FAT12/16/32, exFAT und NTFS (letzteres mehr oder minder gut - die Rechteverwaltung ist nur rudimentär und es gibt wohl unter bestimmten Workloads immer Mal wieder Probleme... ich arbeite seit über 10 Jahren mit einer NTFS-Partition um meine Cloud-Daten nicht doppelt abzulegen und zwischen Windows und Linux Daten auszutauschen und bin noch nie über diese Probleme gestolpert...).
Windows unterstützt ohne weiteres nur FAT12, FAT16, FAT32, exFat, NTFS, ReFS und VFAT (IIRC kann man aktuell nicht mehr so einfach FAT12 und FAT16 erzeugen, aber lesen).

Das Dateisystem benötigt der Datenträger um die Daten zu organisieren. Das Betriebssystem muss das Dateisystem "verstehen" um mit den Informationen daraus umgehen zu können.

 

[rennradler]

Ja, ja.
Wie kommt die Frage zustande und wo ist der Kontext?

Zur Erklärung: in einem Multitaskingbetriebssystem kann eine Operation zu jedem Zeitpunkt unterbrochen werden. Bevor dd die Daten zurückschreibt, kann ein anderer Prozeß oder der Kernel die Datenblöcke bereits geändert haben. Die Sache wird dadurch noch schlimmer, daß du unterhalb des File-System-Treibers auf die SSD zugreifst. Der Kernal cashed zunächst Daten, bevor es sie auf die Platte schreibt. Was du da liest kann sich schon längst geändert haben, wurde aber noch nicht zurückgeschrieben. Stell dir vor, nach dem Lesen wird dd unterbrochen, der Kernel schreibt den Cashinhalt und anschließend schreibt dd die veralteten Daten. -Vorallem bei wichtigen Verwaltungsdaten des Filesystems ist das wahrscheinlich. Zudem unterläufst du damit das Journaling des Filesystems - diese kann nur gegen eine unerwartete Unterbrechung einer Operation absichern. Im schlimmsten Fall kann das ganze Filesystem so inkonsistent werden, daß der totale Datenverlust eintritt.

 

[Korfox]

Eine Platte bzw. Partition auf die man mit dd schreibt hängt man vorher aus, danke für den Hinweis, dass ich das hätte erwähnen sollen.
Ist es die Systempartition, dann würde ich persönlich von einem Live-Datenträger booten, weil root nicht ohne weiteres im laufenden Betrieb ausgehängt werden kann.

Ansonsten macht DiskRefresh aber wahrscheinlich auch nichts anderes, das heißt: auch unter Windows sollte man die Partitionen soweit möglich aushängen.

 

[rennradler]

Ich glaube schon, daß das Tool schlauer vorgeht. Mit dd die ganze Platte zu überschreiben, ist ziemlich doof. Damit wird alles gnadenlos refresht, auch leere und frische Blöcke. Zudem denkt die ssd hinterher, daß sie zu 100% voll ist.

 

[Korfox]

Wie kommst du darauf, dass die SSD denkt, dass sie zu 100% voll ist?
Ich habe es tatsächlich noch nie nötig gehabt per dd zu refreshen, aber ich habe ja schon SSDs aufeinander geklont per dd (bzw. ddrescue, das ist fixer) und da war noch nie anschließend eine SSD der Meinung voll zu sein. Und ich bin da sicher nicht der einzige Mensch, der dd nutzt.

Ich zitiere Mal eben die DiskFresh-Homepage:

DiskFresh is a simple yet powerful tool that can refresh your hard disk signal without changing its data by reading and writing each sector and hence making your disk more reliable for storage.

Hervorhebung von mir.

Empfohlen wird unter Linux wenn ich das gerade richtig sehe auch eher nicht dd, sondern badblocks - aber im Endeffekt macht das per default auch nichts anderes (zumindest beim non-destruktiven Test und um den geht es ja).

 

[rennradler]

Wie kommst du darauf, dass die SSD denkt, dass sie zu 100% voll ist?

Der Controller führt Buch, welche Blocks beschrieben wurden. Diese kennzeichnet er intern als belegt. Das ist nötig, da bereits beschriebene Blöke vor einen Beschreiben erst gelöscht werden müssen, was zeitaufwändig ist. Daher schreibt er, sofern er noch freie Blöcke hat (also solche, die noch nie beschrieben wurden oder bereits gelöscht sind), die Daten in freie Blöcke, macht eine logisches Remapping und führt im Hintergrund das Löschen der jetzt frei gewordenen Blöcke aus, die dann in den Pool seiner freien Blöcke wandern. Wenn du mit dd die komplette SSD umgräbst, meint er, alle Blöcke sind belegt und kann diesen Mechanismus nicht mehr ausführen.
Auf OS-Ebene sieht man das natürlich nicht, da das OS eine Ebene darüber arbeitet. Sowas passiert auch, wenn auf Filesystemebene eine Datei gelöscht wird und die Blöcke aus Sicht des OS jetzt frei sind. Davon weiß aber die SSD nichts, aus ihrer Sicht sind die Blöcke nachwievor belegt. Daher macht der Kernel ein Trim, d.h. er teilt der SSD die Blöcke mit, die jetzt frei sind. Dieser Mechanismus greift bei einem dd auf das raw device nicht.

Trim ist zudem so eine Sache - bei manchen SSDs doht aufgrund von Firmwarebugs ein Datenverlust, dort ist Trim via Black List deaktiviert.

 

[Korfox]

Der Controller führt Buch, welche Blocks beschrieben wurden. Diese kennzeichnet er intern als belegt. Das ist nötig, da bereits beschriebene Blöke vor einen Beschreiben erst gelöscht werden müssen, was zeitaufwändig ist. Daher schreibt er, sofern er noch freie Blöcke hat (also solche, die noch nie beschrieben wurden oder bereits gelöscht sind), die Daten in freie Blöcke, macht eine logisches Remapping und führt im Hintergrund das Löschen der jetzt frei gewordenen Blöcke aus, die dann in den Pool seiner freien Blöcke wandern. Wenn du mit dd die komplette SSD umgräbst, meint er, alle Blöcke sind belegt und kann diesen Mechanismus nicht mehr ausführen.
Auf OS-Ebene sieht man das natürlich nicht, da das OS eine Ebene darüber arbeitet. Sowas passiert auch, wenn auf Filesystemebene eine Datei gelöscht wird und die Blöcke aus Sicht des OS jetzt frei sind. Davon weiß aber die SSD nichts, aus ihrer Sicht sind die Blöcke nachwievor belegt. Daher macht der Kernel ein Trim, d.h. er teilt der SSD die Blöcke mit, die jetzt frei sind. Dieser Mechanismus greift bei einem dd auf das raw device nicht.

Trim ist zudem so eine Sache - bei manchen SSDs doht aufgrund von Firmwarebugs ein Datenverlust, dort ist Trim via Black List deaktiviert.

Ok... danke für die Aufklärung.
Es geht weiter mit meinen Fragen - den letzten Satz zuerst:
Mir sind bisher nur Sandforce-SSDs bekannt, die Probleme mit Trim haben... und das war vor 12 Jahren. Die Chance ist sehr groß, dass diese SSDs inzwischen entweder schon deutlich häufiger als ein Mal "komplett überschrieben" wurden, womit die Belegungstabelle eh auf voll steht. Was für - vor allem halbwegs aktuelle - SSDs gibt es denn noch, die TRIM nicht korrekt umsetzen?

Dass du etwas gegen TRIM hast wusste ich natürlich nicht. Ich bin der Meinung, dass man es nicht intelligenter lösen kann, als ein Mal sämtliche Zellen auszulesen und zurückzuschreiben (den obligatorischen TRIM-Befehl überlassen die Tools dem Betriebssystem).
Dann muss man wohl entscheiden zwischen Pest (potentieller Datenverlust durch mangelnden Refresh und langsame SSD durch mangelhafte Signalqualität) und Cholera (potentieller Datenverlust durch Verwendung von TRIM und [temporär] langsame SSD durch verwirrte Controller).

Für die Suche nach einem Nachfolger einer 860 Pro dürfte das Thema vergleichsweise irrelevant sein, da meines Erachtens heute keine SSD-Controller mehr existieren, die TRIM falsch durchführen, aber wie gesagt: Ich lass mich gerne belehren.

 

[rennradler]

Ich zitiere Mal eben die DiskFresh-Homepage:
Hervorhebung von mir.

DiskFresh und badblocks sind für HDDs gedacht und bei SSDs kontraproduktiv - hinterher gelten für die SSD alle Blöcke als belegt, obwohl aus SIcht des OS noch alles frei ist. badblocks stammt zudem noch aus der Urzeit des Festplatten, wo der Controller sowas nicht intern geregelt hat. Da mußte das OS über fehlerhafte Blöcke selber Buch führen.

Mir sind bisher nur Sandforce-SSDs bekannt, die Probleme mit Trim haben... und das war vor 12 Jahren. Die Chance ist sehr groß, dass diese SSDs inzwischen entweder schon deutlich häufiger als ein Mal "komplett überschrieben" wurden, womit die Belegungstabelle eh auf voll steht. Was für - vor allem halbwegs aktuelle - SSDs gibt es denn noch, die TRIM nicht korrekt umsetzen?

Da würde vor einer Neuinstallation ein Secure Erase helfen. Dann wird alles intern auf Null gesetzt.

Man kann eine SSD auch sinnvoll ohne Trim betreiben. Einfach einen Teil der Kapazität, 10 bis 20% je nach Göße, unpartioniert lassen. Dann ist sichergestellt, daß die SSD immer einen Pool von freien Blöcken hat, egal was das OS in seinen Partitionen macht.

 

[Korfox]

Du weichst meinen Fragen aus.
Mit einem Secure-Erase und einer Neuinstallation wirke ich natürlich der Read Speed Degradation insofern entgegen, dass alle Daten neu geschrieben werden, installiere aber auch das komplette OS neu. Aber das Ziel sollte es ja sein, ein fehlendes Refresh des Controllers zu kompensieren, die Zellen also unverändert zu lassen und nur die Signalstärke wieder auf das ursprüngliche Level zu heben.
Wenn man Clonezilla benutzt (ist ja ok, dd willst du nicht, weil es ohne TRIM zu Schwierigkeiten kommen kann), ein Image wegschreibt, Secure-Erase macht und das Image zurückschreibt, dann hat man den Refresh wenigstens ohne den Aufwand der Neuinstallation. Wenn man dann vorher noch dd if=/dev/zero of=asdf.txt ausführt und anschließend die asdf.txt löscht, dann ist nach dem Zurückspielen des Clonezilla-Images auch tatsächlich nur belegt, was belegt ist.

Printipiell sollte man sich vielleicht erstmal darauf einigen, wie Speicher auf SSDs organisiert ist.
Es wird nicht eine einzelne Speicherzelle geschrieben, sondern der Speicher ist in Blöcken organisiert. Wenn ein Block leer ist, dann kann der Controller da direkt hinschreiben. 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. Jetzt kommt TRIM und sagt dem Controller: In dem Block steht zwar was, aber das kannst du ignorieren, ist gelöscht.

Jetzt kommt Overprovisioning dazu. Das heißt ich lasse einen Bereich (10%) der SSD unpartitioniert. Dieser Bereich kann als SLC-Cache genutzt werden (afaik unterstützt das nicht jeder Controller). D.h. bei MLC-SSDs kann ich so 20% des verfügbaren Speicherplatzes schneller ansprechen, weil die Daten zwar logisch in der Partition liegen, physikalisch aber so verteilt sind, dass eine MLC-Speicherzelle nur ein Bit bereit stellt, also einfach überschrieben werden kann (bei TLC/QLC verkleinert sich der Bereich der schnell genutzt werden kann entsprechend).
Weiterhin dient Overprovisioning dem Bereitstellen von Ersatzblöcken um defekten Blöcken entgegenzuwirken und dem wear-levelling.

Das hat meines Erachtens nichts damit zu tun, dass man TRIM durch OP ersetzen kann. Durch OP fällt das Fehlen von TRIM nicht so sehr auf, weil beide ähnliche Symptome haben.

Beitrag automatisch zusammengeführt: 30 Jan. 2023

Und um einfach Mal zu widerlegen, dass DiskFresh kpontraproduktiv ist:

Readspeed degradation 2022 kein Thema mehr ? Von wegen ! MP510 -> 14MB/s ! 980pro auch nicht ohne Probleme...

Ich poste das hier auch mal weil ich das Thema für WICHTIG halte... Ich beschränke mich aber auf die TLDR Fassung: Worum gehts: Die Ladung der Zellen von SSDs altert, das ist normal. Eigentlich sollte die Firmware/der Controller daher regelmäßig einen Refresh der Zellen machen (sofern die...

www.computerbase.de

https://www.overclock.net/threads/read-speeds-dropping-dramatically-on-older-files-benchmarks-needed-to-confirm-affected-ssds.1512915/

 

[Ambrosius]

Allerdings soll das Problem jetzt bei aktuellen SSDs vieler Hersteller wieder auftauchen. U.a. soll meine 970 PRO betroffen sein.
Es gibt ein Freeware-Tool, mit dem man dem Problem auf die Schliche kommen kann (SSD Read Speed Tester) und ein Es gibt auch ein "Refresh-Tool", das alte Dateien neu schreibt. Beides leider nur für Windows.
Da ich aber nur Linux habe, muß ich mal schauen, ob es da was vergleichbares gibt. Schlimmstenfalls muß ich selber in die Tasten greifen - zumindest ein Read Speed Tester sollte in überschaubarer Zeit zu schreiben sein, da der nicht-destruktiv arbeitet. Ein Refresh-Tool sollte man schon gut testen ...

Das ist leider nicht so erfreulich! Da ich auch Linux nutze, kenn ich das Problem, dass auch die gängigen Tools u.a. auch die herstellereigenen Programme wie Magician & Cohorten nicht wirklich eine Hilfe sind. Hab sogar überlegt eine Windohs Platte extern anzuschließen nur um solche Diagnosen und FW Updatechecks hin und wieder anstoßen zu können. Leider nur etwas umständlich und elegant schon gar nicht. Das führt womöglich nur dazu dass man es eher aufschiebt und dann vergisst..

Für die Suche nach einem Nachfolger einer 860 Pro dürfte das Thema vergleichsweise irrelevant sein, da meines Erachtens heute keine SSD-Controller mehr existieren, die TRIM falsch durchführen, aber wie gesagt: Ich lass mich gerne belehren.

@Korfox es stimmt, dass die hier, mitunter sehr kontrovers, besprochenen Themen wie dd, TRIM, Disk Refresh nur periphär mit der Nachfolgesuche einer 860 Pro zusammenhängen, aber erhellend sind sie allemal. Und ich darf ergänzen auch nicht so ganz unwichtig. Denn schließlich geht es mir und mit Sicherheit auch vielen anderen, bei der Suche nach einer verlässlichen Platte allen voran um Verlässlichkeit, was in meinem Duden eben auch miteinschliesst, dass man sie einmal montiert, installiert und zum Laufen gebracht, auch schonmal vergessen darf. Soll heissen, keiner hat Bock langfristig seine Hardware durch Software zu micromanagen...deswegen kauft man sich auch ne Pro.

Das ändert aber nichts an dem Fakt, dass man seine Hausaufgaben machen muss. Ich bin gefühlt in jeder meiner SSDs und HDDs um ihr Wohl mehr investiert, als mir lieb ist, weswegen ich im Vorfeld eines Kaufes die Modelle raussuche, die am "wenigsten" aufgefallen sind. Aber es scheint mir als würde mit jedem Jahr mehr Wissen darüber akkumuliert, wie sich SSDs langzeittechnisch entwickeln und altes richtiggeglaubtes Wissen wieder revidiert oder ergänzt werden muss

Ein prominentes Beispiel - Obacht! Wieder was gelernt - ist wie man NVMes richtig kühlt. Einfach Pad draufklatschen und dann Kühlkörper druff; damit ists nicht getan. Eben weil der Controller heißer wird als die NAND Flash Chips, sorgt das bei einem durchgehenden Kühlkörper für eine unangenehme Nebenwirkung, und zwar wird der Stahl- oder Aluminiumkörper erst einmal warm, sagen wir durch Arbeit, so bleibt er es für eine Weile und erwärmt die NAND Flashs länger als nötig passiv mit, wenn er die Wärme nicht durch geeigneten Luftstrom schnell wieder abgeben kann. Fazit: je nach durchschnittlichen Umgebungstemperatur kann es auch durchaus sinnvoller sein, KEIN Heatsink aka Kühlkörper über der NVMe zu montieren.

Das ist etwas knapp formuliert und vielleicht nicht ganz ersichtlich, deswegen hier nochmal ein weiterführender Leselink, der Ausführlichkeit wegen. Und der hier ist auch sehr interessant besonders was die Wechselwirkung von Temperatur und Data Retention angeht...

In dem Sinne plädiere ich auch den Titel des Threads etwas allgemeiner zu fassen, da es sinnvoller ist den Thread nicht nur als Ideengeber für SSD Kaufinteressierte sondern vielmehr auch als SSD Wartung und Aufklärung bzgl. den technischen Finessen zu verstehen. Bin offen für Vorschläge

 

[Korfox]

Ein prominentes Beispiel - Obacht! Wieder was gelernt - ist wie man NVMes richtig kühlt. Einfach Pad draufklatschen und dann Kühlkörper druff; damit ists nicht getan. Eben weil der Controller heißer wird als die NAND Flash Chips, sorgt das bei einem durchgehenden Kühlkörper für eine unangenehme Nebenwirkung, und zwar wird der Stahl- oder Aluminiumkörper erst einmal warm, sagen wir durch Arbeit, so bleibt es es für eine Weile und erwärmt die NAND Flashs länger als nötig, wenn er die Wärme nicht durch geeigneten Luftstrom schnell wieder abgeben kann. Fazit: je nach durchschnittlichen Umgebungstemperatur kann es auch durchaus sinnvoller sein, KEIN Heatsink aka Kühlkörper über der NVMe zu montieren.

Das ist etwas knapp formuliert und vielleicht nicht ganz ersichtlich, deswegen hier nochmal ein weiterführender Leselink, der Ausführlichkeit wegen. Und der hier ist auch sehr interessant besonders was die Wechselwirkung von Temperatur und Data Retention angeht...

Persönliche Erfahrung hierzu: eine einfache 1mm dicke Kupferplatte mit Wärmeleitpad (genauer: https://www.amazon.de/dp/B0BL3X75JF). Nichts großartiges, musste ja im Laptop platz finden (über den Luftstrom, der eine NVMe-SSD in einem Laptop erreicht müssen wir wahrscheinlich eher wenig reden, oder):
Ohne:

Mit:

Also ich bevorzuge einen Controller, der 20 Minuten lang 75°C warm ist vor einem Controller, der 10 Sekunden lang 95°C hat.

EDIT: Sieht man die Bilder oder muss ich die gleich neu hochladen? Von dem Gerät an dem ich gerade sitze habe ich keinen Zugriff auf abload... die Screenshots sind aber von mir vor ein paar Tagen da abgelegt worden.

 

[Ambrosius]

Also ich bevorzuge einen Controller, der 20 Minuten lang 75°C warm ist vor einem Controller, der 10 Sekunden lang 95°C hat.

Absolut, und damit wären wir auch wieder an dem Punkt, den ich ansprach, konkret in meinem Fall auch Thinkpad wieder öffnen und nachbessern. Und ich überlege auch selbst die NAND Flashs nicht mit nem PAD zu überdecken sondern frei zu lassen, Im Laptop auch kein Akt. Wenn der Controller wie meistens ganz vorne positioniert ist, dann sollte das auch glaub ich auf den Teil begrenzt werden. Man muss auch seinen Workload gut kennen, wer viel schreibt, der sollte besser eine andere Kühllösung vorziehen..

 

[rennradler]

Du weichst meinen Fragen aus.
Mit einem Secure-Erase und einer Neuinstallation wirke ich natürlich der Read Speed Degradation insofern entgegen, dass alle Daten neu geschrieben werden, installiere aber auch das komplette OS neu. Aber das Ziel sollte es ja sein, ein fehlendes Refresh des Controllers zu kompensieren, die Zellen also unverändert zu lassen und nur die Signalstärke wieder auf das ursprüngliche Level zu heben.

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.

Wenn man Clonezilla benutzt (ist ja ok, dd willst du nicht, weil es ohne TRIM zu Schwierigkeiten kommen kann), ein Image wegschreibt, Secure-Erase macht und das Image zurückschreibt, dann hat man den Refresh wenigstens ohne den Aufwand der Neuinstallation. Wenn man dann vorher noch dd if=/dev/zero of=asdf.txt ausführt und anschließend die asdf.txt löscht, dann ist nach dem Zurückspielen des Clonezilla-Images auch tatsächlich nur belegt, was belegt ist.n.

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?

Printipiell sollte man sich vielleicht erstmal darauf einigen, wie Speicher auf SSDs organisiert ist.
Es wird nicht eine einzelne Speicherzelle geschrieben, sondern der Speicher ist in Blöcken organisiert. Wenn ein Block leer ist, dann kann der Controller da direkt hinschreiben. 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. Jetzt kommt TRIM und sagt dem Controller: In dem Block steht zwar was, aber das kannst du ignorieren, ist gelöscht.

So ungefähr, wobei es auch noch so ist, daß die Blöcke mehrere LBAs umfassen.

Jetzt kommt Overprovisioning dazu. Das heißt ich lasse einen Bereich (10%) der SSD unpartitioniert. Dieser Bereich kann als SLC-Cache genutzt werden (afaik unterstützt das nicht jeder Controller).

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.

Das hat meines Erachtens nichts damit zu tun, dass man TRIM durch OP ersetzen kann. Durch OP fällt das Fehlen von TRIM nicht so sehr auf, weil beide ähnliche Symptome haben.

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

 

[Ambrosius]

Wie verhält sich denn Overprovisioning mit dem Trim Befehl? Müsste sich doch eigentlich ergänzen oder? Ich mein, was übernimmt der Controller (ergo FW) und was das OS? Muss es da nicht auch so eine Art Best Practice geben, das sich so bissi durchgesetzt hat?

 

[Korfox]

Absolut, und damit wären wir auch wieder an dem Punkt, den ich ansprach, konkret in meinem Fall auch Thinkpad wieder öffnen und nachbessern. Und ich überlege auch selbst die NAND Flashs nicht mit nem PAD zu überdecken sondern frei zu lassen, Im Laptop auch kein Akt. Wenn der Controller wie meistens ganz vorne positioniert ist, dann sollte das auch glaub ich auf den Teil begrenzt werden. Man muss auch seinen Workload gut kennen, wer viel schreibt, der sollte besser eine andere Kühllösung vorziehen..

Die Werte sind ja gebenched (und das mit nicht gerade harmlosen Parametern). Trotzdem hängt die SSD (eine 980 pro) nur an PCIe 3.0, läuft also per Preset schonmal nur auf halber Kraft. Trotzdem sind die Temperaturen so hoch gegangen. 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). Ich gehe nicht davon aus, dass so eine Last häufig auftreten wird (beim Syncen aus der Cloud ist die Quelle zu langsam, wenn man ein OS installiert da kann das bei Otto-Normalo schonmal vorkommen).
Das Laptop (ist ein HP, ich bin durch einen unglücklichen Umstand da dran gekommen und verabschiede mich gerade zumindest für diese Generation von ThinkPads, weil Ryzen 5 5500U >> mein aktueller i5-5200U). Das T450s bekommt jetzt halt meine Frau, die aktuell noch ein T430s nutzt. Ursprünglich war ich dabei mich nach einem T480s umzusehen, aber auch das sticht gegen das HP nicht) lag 3 Wochen geöffnet rum, bis ich alle Teile zusammen hatte, weil ich eben keinen Bock hatte, es drei Mal zu öffnen .