[erledigt] queued TRIM Bug Samsung SSDs

Hi,
bei mir läuft ja schon lange die Samsung 840 Evo und auch super problemlos mit Kernel 3.11 (openSUSE 13.1).
Samsung hat die Preise gesenkt. Meine Kommilitonin & Lernpartnerin hat noch keine SSD und würde die Samsung 850 Evo 250GB kaufen.

Gibt es da Gegenargumente wegen der Blacklist aller Samsung 800er SSDs im Kernel?
In allen Testberichten ist die 850 Evo etwas besser als die Crucial MX200. Dafür funktioniert aber bei Crucial queued TRIM.

Verschlechtert das Blacklisting die Performance der Samsung 850 Evo? Was meint ihr?

Hab mit der 840 Evo; Mit der aktuellsten Firmware und seit der Patch im Kernel ist keine Probleme.
Also diese werkelt derzeit bei mir:

ATA-9: Samsung SSD 840 EVO 120GB, EXT0DB6Q, max UDMA/133

Zum Vergrößern anklicken....

Zu der neueren 850 Serie kann ich dir überhaupt nichts sagen. Aber warum denn nicht? Eigentlich sind die neueren Geräte dann in der Regel besser und profitieren von der Kenntnis über Kinderkrankheiten vorangehender Serien, oder?

Du meinst das hier, oder?::

/* devices that don't properly handle queued TRIM commands */

Zum Vergrößern anklicken....

https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c

Gruß,

R

revealed schrieb:

Du meinst das hier, oder?::

/* devices that don't properly handle queued TRIM commands */

Zum Vergrößern anklicken....

https://github.com/torvalds/linux/blob/master/drivers/ata/libata-core.c

Zum Vergrößern anklicken....

Ja.
Was hat dieser Blacklisteintrag für Konsequenzen auf die Performance?
Die Samsung 850 Evo ist jetzt nämlich billiger als die Crucial MX200.
www.heise.de/preisvergleich

Die Samsung 840 Evo wird gebraucht so hoch gehandelt dass ich meine 250 GB fast gleich auch noch gegen eine neue 850 Evo 1:1 eintauschen könnte.

Hast Du durch den Umstand, daß bei Deinem 3.11er-Kernel queued TRIM gar nicht möglich ist, irgendwelche Leistungs-Probleme? Ich behaupte, daß allfällige Probleme beim "normalen" TRIM durch eine schlecht kodierte firmware verursacht werden, aber selbst in diesem Fall wirst Du im Normalbetrieb nichts davon merken (andere Ansichten zu diesem Thema sind durchaus willkommen). Jede SSD(-firmware) muß individuell für sich betrachtet werden, und ohne einen mit entsprechender Funktionalität selbst erstellen Kernel kannst Du es bei der Ziel-SSD auch nicht herausfinden.

Bei meinen Crucial M550 konnte ich bei ext4 mit der Einhängeoption discard subjektiv keinen Unterschied zwischen der Zeit, in der queued TRIM nicht möglich war, und der Zeit danach feststellen.

josef-wien schrieb:

Hast Du durch den Umstand, daß bei Deinem 3.11er-Kernel queued TRIM gar nicht möglich ist, irgendwelche Leistungs-Probleme?

Zum Vergrößern anklicken....

Dafür fehlt mir der Vergleich.

Ich bin halt etwas verunsichert, ob die Samsung 850 Evo trotzdem ein guter Kauf ist, zumal die 250 GB jetzt bei 80 Euro liegt.
Für meine 250 GB Samsung 840 Evo habe ich noch 126,80€ bezahlt. Das war ein super Preis damals.

Riesig sind die Unterschiede zwischen Samsung 840 Evo, Crucial MX200 und Samsung 850 Evo nicht. Aber die MX200 ist jetzt teurer als die 850Evo.
Und in der Preisklasse gibt es nichts besseres.

Also zugegeben wenn ich den Batched Trim starte, habe ich nen ganz kurzen micro lag. Kann aber auch mein schlechtes Script sein weil ich ins Journal schreibe und eine Wall message an alle angemeldeten Benutzer schicke.

Gruß,

R

Hi!
Es gibt Neuigkeiten:

Samsung hat einen Linux Kernel-Patch beigesteuert der das queued TRIM Problem lösen sollte.
http://www.spinics.net/lists/raid/msg49440.html und https://github.com/algolia/trimtester
Original von hier:
https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/

Was meinen die Spezialisten hier dazu?

LUH 3417 schrieb:

Was meinen die Spezialisten hier dazu?

Zum Vergrößern anklicken....

Die wirst Du hier nicht finden. Der in der Antwort zu Deinem ersten link erwähnte patch ist zwar z. B. im Kernel 4.1.13 enthalten, an den Eintragungen in libata-core.c hat sich allerdings auch in den aktuellen Kernel-Quellen nichts geändert, und das wird wohl seinen Grund haben. Falls Du Versuchskaninchen spielen willst, mußt Du Dir einen Kernel mit geänderter libata-core.c erzeugen.

Danke für die Info. Diese threads hatte ich tatsächlich schon gesehen. Und die SSD läuft hier unproblematisch mit Tumbleweed. Und vorher hat es auch mit 13.2 gepasst, seit dieser weiter vorne genannte libata core c Patch in den 3 er kernel vom 13.2 geportet wurde. Im Kernel 4 (Tumbleweed) ist der freilig auch drin.

Ich weiss aber selber nicht ob das das selbe ist, wie diese Info von dir anpreist. Ich habe aktuell keine Bedenken mehr beim Einsatz der 840 Evo mit der derzeit aktuellsten Firmware. (vom April). Und dem libata core c enthaltenen workaround.

Ein wöchentlicher Batched trim geht so unmerklich schnell. Ich verwende sowieso keine (discard) moutoption.

Gruß,

R

PS.: Da wir gleichzeitig gepostet haben -- lol --- Ich hab auch keine Lust Versuchskaninchen zu spielen. Hab schon genug zu tun mit Tumbleweed.

Und gut ist es mit:
- Aktueller Firmware
- Aktuellem Kernel

josef-wien schrieb:

Falls Du Versuchskaninchen spielen willst, mußt Du Dir einen Kernel mit geänderter libata-core.c erzeugen.

Zum Vergrößern anklicken....

Nein auf keinen Fall.
Die Samsung SSD ist ja nur ein Muggesäckele schneller als die Crucial.
Aber mit dem Pferdefuß einer seltsamen Firmware verzichten wir gerne darauf.
Wenn jemand viele große Dateien schreiben muss kauft er für volles Tempo besser eine SSD mit 500 oder 1000 GB.

Danke für die Antworten!