[erledigt] (asynchroner) TRIM-Befehl fuehrt zu Datenverlust
-
- Beiträge: 119
- Registriert: 29.11.2013 23:59:24
[erledigt] (asynchroner) TRIM-Befehl fuehrt zu Datenverlust
Hallo,
ich spiele mit dem Gedanken meinen verstaubten Rechner mit einer chicen Samsung SSD 840 oder 850 EVO etwas auf Vordermann zu bringen.
Nun lese ich hier [1] diverse Horror-Posts ueber Datenverlust bei der Verwendung von asynchronem TRIM:
If you are running a firmware updated Evo on a TRIM enabled linux that isn’t the latest linux kernel or a Pro on any TRIM enabled linux you may be screwed.
Zum einen scheint das Problem bei einem Firmware-update der SSD zu entstehen oder bei einer Samsung Pro in Verbindung mit dem TRIM-Befehl.
Liest man durch die Posts, dann scheint es wahrlich das Personen die nie einen Firmwareupdate der SSD vorgenommen haben ohne Probleme sind.
Basically asynchronous TRIM on Samsung SSDs are broken and will cause the drive to erase current data (as opposed to deleted data), causing data loss without any warning. Right now only linux supports async TRIM and it includes a blacklist of drives to disable async TRIM on. Samsung (among others) has many SSDs in this list, but it seems that some of their SSDs, including some 8-series Evo/Pro SSDs are not triggering the blacklist which will cause data loss.
Hier, vorallem im letzten Satz, steht das die 8-series Evo/Pro SSDs nicht (!) die Blacklist "triggern" und es dadurch zu Datenverlust kommt.
Meine Frage ist daher, muss ich mir wegen dem asynchronen TRIM und einer Samsung SSD Gedanken machen oder ist der Fehler mittlerweile behoben (immerhin ist der Post auch schon 11 Monate alt)?
Gibt es Erfahrungen?
Ich nutze ein ganz normales aktuelles Stable.
Danke im Voraus!
[1] https://www.reddit.com/r/buildapc/comme ... sung_ssds/
ich spiele mit dem Gedanken meinen verstaubten Rechner mit einer chicen Samsung SSD 840 oder 850 EVO etwas auf Vordermann zu bringen.
Nun lese ich hier [1] diverse Horror-Posts ueber Datenverlust bei der Verwendung von asynchronem TRIM:
If you are running a firmware updated Evo on a TRIM enabled linux that isn’t the latest linux kernel or a Pro on any TRIM enabled linux you may be screwed.
Zum einen scheint das Problem bei einem Firmware-update der SSD zu entstehen oder bei einer Samsung Pro in Verbindung mit dem TRIM-Befehl.
Liest man durch die Posts, dann scheint es wahrlich das Personen die nie einen Firmwareupdate der SSD vorgenommen haben ohne Probleme sind.
Basically asynchronous TRIM on Samsung SSDs are broken and will cause the drive to erase current data (as opposed to deleted data), causing data loss without any warning. Right now only linux supports async TRIM and it includes a blacklist of drives to disable async TRIM on. Samsung (among others) has many SSDs in this list, but it seems that some of their SSDs, including some 8-series Evo/Pro SSDs are not triggering the blacklist which will cause data loss.
Hier, vorallem im letzten Satz, steht das die 8-series Evo/Pro SSDs nicht (!) die Blacklist "triggern" und es dadurch zu Datenverlust kommt.
Meine Frage ist daher, muss ich mir wegen dem asynchronen TRIM und einer Samsung SSD Gedanken machen oder ist der Fehler mittlerweile behoben (immerhin ist der Post auch schon 11 Monate alt)?
Gibt es Erfahrungen?
Ich nutze ein ganz normales aktuelles Stable.
Danke im Voraus!
[1] https://www.reddit.com/r/buildapc/comme ... sung_ssds/
Zuletzt geändert von prankenandi am 12.06.2016 11:11:55, insgesamt 1-mal geändert.
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Hat die 850er auch dieses tolle Feature von der 840EVO, dass sie sich nach ein paar Monaten auf HDD-Geschwindigkeit abbremst? Dann könntest du dir das Upgrade ganz sparen ...
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Wurde dieses Geschwindigkeitseinbruchsantifeature nicht durch ein Firmwareupdate behoben?
Ich verwende schon eine ganze Zeit lang zwei 840 Pro in meinem Desktop, habe discard aktiviert und immer brav die Firmware aktualisiert, wenn ein Update erschienen ist (das letzte ist aber schon lange her). Probleme hatte ich aber nie und dank der Prüfsummen von btrfs bin ich auch sehr zuversichtlich, dass keine Daten verfälscht worden sind.
Ich bin mir aber ziemlich sicher, dass bei meiner SSD dieses NCQ-Trimming wegen dem Eintrag in der Blacklist des Kernels schon seit vielen Kernelversionen nicht verwendet wird.
Was mir dagegen immer schon suspekt war, ist dieses Verwenden von TLC- oder MLC-Speicher als schneller SLC-Cache, wie es die Evo-Modelle und viele andere SSDs machen - ich denke die Verwaltung der Speicherzellen ist schon ohne solche Späßchen komplex genug.
Momentan ist unter anderem deshalb die Crucial MX200 ab 500 GB mein Favorit (darunter hat sie auch dieses SLC-Caching-Feature).
Alles in allem würde ich mir keine Gedanken machen, aber unabhängig davon natürlich nicht auf Backups verzichten.
Ich verwende schon eine ganze Zeit lang zwei 840 Pro in meinem Desktop, habe discard aktiviert und immer brav die Firmware aktualisiert, wenn ein Update erschienen ist (das letzte ist aber schon lange her). Probleme hatte ich aber nie und dank der Prüfsummen von btrfs bin ich auch sehr zuversichtlich, dass keine Daten verfälscht worden sind.
Ich bin mir aber ziemlich sicher, dass bei meiner SSD dieses NCQ-Trimming wegen dem Eintrag in der Blacklist des Kernels schon seit vielen Kernelversionen nicht verwendet wird.
Was mir dagegen immer schon suspekt war, ist dieses Verwenden von TLC- oder MLC-Speicher als schneller SLC-Cache, wie es die Evo-Modelle und viele andere SSDs machen - ich denke die Verwaltung der Speicherzellen ist schon ohne solche Späßchen komplex genug.
Momentan ist unter anderem deshalb die Crucial MX200 ab 500 GB mein Favorit (darunter hat sie auch dieses SLC-Caching-Feature).
Alles in allem würde ich mir keine Gedanken machen, aber unabhängig davon natürlich nicht auf Backups verzichten.
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Wie definierst du "behoben"? AFAIK kopiert die neue Firmware einfach hier-und-da ein paar Sektoren um, um den Geschwindigkeitseinbruch zu vermeiden und um die Lebensdauer zu verkürzen.smutbert hat geschrieben:Wurde dieses Geschwindigkeitseinbruchsantifeature nicht durch ein Firmwareupdate behoben?
Mein Tipp: Kaufe eine Intel. Oder SanDisk.
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Von samsung.com -- "SSD" -- blablabla ---> 840pro (Bsp) ->
DXM05B0Q (2013)
scheinbar "offiziell"
In den ganzen Foren wird sich auf die "neue" Firmware bezogen
DXM06B0Q (2014)
http://www.samsung.com/semiconductor/mi ... tools.html
Das zweite ist dann eine Art Entwickler-Branch / Beta?
DXM05B0Q (2013)
scheinbar "offiziell"
In den ganzen Foren wird sich auf die "neue" Firmware bezogen
DXM06B0Q (2014)
http://www.samsung.com/semiconductor/mi ... tools.html
Das zweite ist dann eine Art Entwickler-Branch / Beta?
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Ehrlich gesagt ... ich weiß es nicht ... ich hab irgendwann nach dem dritten oder vierten Versuch von Samsung aufgehört zu zählen ...smutbert hat geschrieben:Wurde dieses Geschwindigkeitseinbruchsantifeature nicht durch ein Firmwareupdate behoben?
10.2014:
http://www.heise.de/newsticker/meldung/ ... 57228.html
02:2015:
http://www.heise.de/newsticker/meldung/ ... 57228.html
04:2015:
http://www.gamestar.de/hardware/ssds/sa ... 84546.html
Da ist die richtige Lösung dann für Ende April angekündigt ... wobei sie nicht sagen, in welchem Jahr dieser April liegen soll.
Bei der 840 Basic sieht's deutlich übersichtlicher aus:
Das war's schon.
Viel besser war aber das Datenschutz-Feature für die 850 Pro:
http://www.pcwelt.de/news/SSD-850-Pro-S ... 83408.html
Never change a broken system. It could be worse afterwards.
"No computer system can be absolutely secure." Intel Document Number: 336983-001
"No computer system can be absolutely secure." Intel Document Number: 336983-001
- Lord_Carlos
- Beiträge: 5578
- Registriert: 30.04.2006 17:58:52
- Lizenz eigener Beiträge: GNU Free Documentation License
- Wohnort: Dänemark
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Dies. In den von OP genannten Thread geht es um NCQ-Trimming was via Kernel blacklist deaktiviert wird.smutbert hat geschrieben:Ich bin mir aber ziemlich sicher, dass bei meiner SSD dieses NCQ-Trimming wegen dem Eintrag in der Blacklist des Kernels schon seit vielen Kernelversionen nicht verwendet wird.
_________
The title is a bit extreme, the blacklist patch was included in the 4.0.5 kernel released 11 days ago, so anything with the latest kernel is safe from this firmware issue.
For those without this patch in their kernel, queued TRIM can be disabled by adding libata.force=noncq to your kernel command line
Code: Alles auswählen
╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!
-
- Beiträge: 119
- Registriert: 29.11.2013 23:59:24
Re: (asynchroner) TRIM-Befehl fuehrt zu Datenverlust bei SSD
Danke fuer die Antworten.
Wenn dieses NCQ-Trimming via Kernel blacklist deaktiviert ist klingt das ja doch schon beruhigend. Und, wie von smutbert geschrieben, gibt es ja auch positive Erfahrungen mit der 840 Pro.
Nichtsdestotrotz schaue ich auch einfach mal bei Intel oder SanDisk (und nutze ab und an ein Backup).
MfG Andre
Wenn dieses NCQ-Trimming via Kernel blacklist deaktiviert ist klingt das ja doch schon beruhigend. Und, wie von smutbert geschrieben, gibt es ja auch positive Erfahrungen mit der 840 Pro.
Nichtsdestotrotz schaue ich auch einfach mal bei Intel oder SanDisk (und nutze ab und an ein Backup).
MfG Andre