Samsung 840 Evo 1TB nur noch 50MB/s Schreibrate nach SLC-Cache

[qiller]

Hallo,

tja, Problem steht ja schon im Threadtitel. Ich muss hin und wieder mal größere Datenmengen (50-300GB) hin- und herkopieren und mittlerweile nerven die niedrigen Schreibraten der Evo. Ich hatt das Problem schonmal, aber ka mehr, was ich da gemacht hatte. Evt. hatte ich die SSD mal plattgemacht aber das will ich diesmal vermeiden.

Hatte jetzt diesen Magician nochmal installiert, aber manuelles Optimieren (aka Trim) scheint das wohl nicht mehr zu unterstützen. Die SSD ist nicht komplett gefüllt. Ich hab irgendwie das Gefühl, dass Trim nicht richtig funktioniert, in der Optimierung scheint aber alles richtig eingestellt zu sein und Trim ist auch aktiv.

Die ersten paar GB gehen danke SLC-Cache noch mit Full-Speed, aber dann gehts immer weiter runter. Der Magician zeigt beim Performancetest ganz normal ~490GB/s, aber der testet halt nur max. 2GB an Schreibdaten, bisschen witzlos. Mit Crystaldiskmark sieht man ein Einbrechen am Ergebnis erst bei den Schreibtests mit größeren Daten. Im Taskmanager sieht mans aber besser.

Achso, ich hab noch ne 870 QVO, die auch ordentlich einbricht, aber bei der stört mich das nicht, weil das dank QLC-Zellen normal ist und die benutze ich auch mehr als Datenhalde. Dann habe ich noch 2x 840 Pro (256GB/512GB) die überhaupt nicht einbrechen, egal wieviel ich da drauf kopiere. Die Schreibraten sind zwar bisschen niedriger (~400-450MB/s) als bei der Evo im SLC-Cache, aber dafür keinerlei Einbruch. Und halt noch 2x NVMe SSDs die ich am häufigsten verwende.

Also kein Plan warum die EVO so stark einbricht (glaub früher war der Einbruch nur so auf ~250MB/s und nicht wie jetzt 50MB/s). Noch einer schlaue Ideen? Oder SSD in Tonne haun?

 

[Mojo1987]

Wie voll ist die SSD?
Wurde die SSD ggf. schon einmal mit einem Secure Erase gelöscht falls möglich?

 

[Cerebral_Amoebe]

72° ist ganz schön viel für eine SATA-SSD.
Handelt es sich um die Systemplatte oder warum willst Du die nicht plattmachen?

Edit:
Gerade gelesen, das man die Luftstromtemperatur von 100°C abziehen muss.
Das passt ja dann bei aktuell 28°C. Die maximale Temperatur der SSD war 48°C.

 

[oicfar]

NVMe's oder SSD's werden meist langsamer, wenn die zu voll sind. Ob das schon bei 70% Belegung anfängt ... Ich hatte es bei mir ab 80+% Belegung gemerkt.

Ergänzung (31. Oktober 2024)

tja, Problem steht ja schon im Threadtitel. Ich muss hin und wieder mal größere Datenmengen (50-300GB) hin- und herkopieren und mittlerweile nerven die niedrigen Schreibraten der Evo.

Wenn man aber oft hin und her kopieren muss, dann entweder die Strategie überdenken oder größere SSDs nehmen?

 

[qiller]

Wie voll ist die SSD?

Man siehts im Crystaldisk-Screenshot: ~650GB

mit einem Secure Erase gelöscht falls möglich?

Magician sagt, nicht möglich. Glaub Secure Erase hielt erst bisschen später Einzug. Aber eigt. will ich die SSD nicht plattmachen. Ich mein, das kann doch nicht die Lösung sein (die ich dann in 1-2 Jahren wieder machen darf?) Laufwerke immer plattzumachen.

dann entweder die Strategie überdenken

Hab ich schon, daher nehm ich für die meisten Aktionen ja die NVMe SSDs. Aber hin- und wieder lager ich mal was auf die Evo aus und das ist halt super nervig da was draufzukopieren, vor allem wenn man bei den NVMe-SSDs GB/s als Einheit gewohnt ist :x.

 

[oicfar]

Hab ich schon, daher nehm ich für die meisten Aktionen ja die NVMe SSDs. Aber hin- und wieder lager ich mal was auf die Evo aus und das ist halt super nervig da was draufzukopieren, vor allem wenn man bei den NVMe-SSDs GB/s als Einheit gewohnt ist :x.

Meistens kauft man zu kleine Datenträger. Bezogen auf die Zukunft. An sich würde ich an deiner Stelle die Anzahl NVMe's/SSD's reduzieren und dann größere nehmen.

 

[Mojo1987]

Magician sagt, nicht möglich. Glaub Secure Erase hielt erst bisschen später Einzug.

Die 840 EVO kann Secure Erase. Secure Erase ist Teil der ATA Spezifikation und dort seit 2001 enthalten auch wenn es auf SSDs anders funktioniert wie ursprünglich angedacht.
Der Grund warum die damit nicht gelöscht werden kann ist also definitiv ein anderer.

Und ja, SATA SSDs aus der Zeit brauchen tatsächlich hin und wieder einen Secure Erase wenn die Performance so schlecht ist und die üblichen Mittel wie TRIM und Co nichts mehr bringen.

70% Füllstand ist halt auch schon ordentlich für einen First Gen TLC SSD, kann auch sein das es einfach in der Natur der Sache liegt. Damals hat man gesagt das man die nicht über 80% bringen soll, da es die Performance permanent beeinträchtigen kann.

 

[qiller]

Wtf, eben nochmal Crystaldiskmark gemacht und nu passts wieder oO

Nach dem Einbruch:

Der Einbruch kam auch viel später eben.

Ergebnis:

Ergänzung (31. Oktober 2024)

Ach ich weiß wieder, wie ich das damals gemacht habe. Die SSD einmal mit irgendnem Kram komplett vollschreiben und den Kram dann wieder löschen, damit Trim einmal auf die Blöcke ausgelöst wird. Eben gerade nochmal nen Copy-Test gemacht und der sah auf einmal schon besser aus, weil der Einbruch viel später kam, da ist mir das wieder eingefallen.

Anfang:

Mitte:

Später:

 

[motorazrv3]

@qiller

auf die Windowsanzeige würde ich mich nicht verlassen.


Meine "alte" ADATA S510 war auch mal echt mega bockig bei der Performance und ein Secure Erase hat da geholfen. Die war danach quasi wie gerade neu gekauft.
Neuere MB bieten ein Secure Erase über das UEFI ansonsten sind hier zwei Anleitungen.

https://www.thomas-krenn.com/de/wiki/SSD_Secure_Erase
https://www.ssdblog.de/2014/12/16/ssd-secure-erase-unter-linux-mit-hdparm/

 

[xxMuahdibxx]

Ansonsten gibt es auch smart Werte die vielleicht Mal Posten...

 

[klampf]

Aktuelle firmware wirst du ja haben?
840 evo hatte mal was mit sehr langsamen lesen alter Dateien und da gab es eine Firmware, ist aber schon lange her.

Manuelles trim kann auch der Windows Optimzer, macht der bei einer SSD statt optimieren.

Manuell im CMD geht auch, falls die SSD jetzt J: ist ...:
defrag J: /L

 

[qiller]

Wie gesagt, Schreibraten passen wieder. Einmal SSD vollmüllen und dann wieder löschen, Problem gefixed. Ich glaube mit der Zeit fallen da immer wieder mal Blöcke an, die nicht zum Löschen markiert wurden und damit beim Beschreiben erst gelöscht werden müssen (weswegen die Schreibrate so einbricht). Normalerweise gibts für sowas die Garbage Collection, die sollte sowas eigentlich regeln. Aber ich glaub bei der 840 Evo läuft das so, dass die Garbage Collection primär fürs Freiräumen des SLC-Caches da ist. Kommt man über den SLC-Cache hinaus und die Nicht-SLC-Blöcke sind nicht gelöscht, knickt der Write-Speed hart ein.