fstrim für Transcend TS256GMSA340 unter Linux aktiveren oder nicht?

[le0m]

Weiß jemand ob die Transcend TS256GMSA340 den fstrim Befehl unter Linux verkraftet?
Angeblich kann der Befehl bei SSDs von anderen Herstellern als den auf der Whiteliste (Intel, Samsung, OCZ, SanDisk und Patriot) zu Datenverlust führen. Per default ist der Befehl unter Linux Mint und Ubuntu für all SSDs die nicht auf der Whitelist stehen deaktiviert...

Hier gibt es mehr zu dem Thema:
https://wiki.ubuntuusers.de/SSD/TRIM/#Automatisches-TRIM-ab-Ubuntu-14-10

Ich frage mich ob ich Trim aktivieren soll oder nicht. Angeblich sei das ja auf Dauer gut für die Performance der SSD. Aber auf Datenverlust hätte ich auch keine Lust. Hat vielleicht jemand Ahnung von dem Thema oder kann aus Erfahrung sprechen?

Vielen Dank!

 

[Piktogramm]

Für mich liest sich der Artikel wie: Das Problem bestand in der Vergangenheit, ab 14.04 ist es aber wohl kein Problem mehr und Trim wird wöchentlich durchgeführt.

 

[Holt]

Ehrlich habe ich da den Verdacht, dass der Bug nicht bei der Hälfte der SSD zu suchen ist, sondern eher im Linux, genau wie damals der Bug mit TRIM und mdraid. Es ist einfach extrem unwahrscheinlich, dass so viele SSD Controller / FW Entwickler / Hersteller bei so vielen Modellen den gleichen Bug haben.

 

[Hallo32]

Falls du eine aktuelle Distribution hast, würde ich es aktivieren.
Viele der Gründe für die Blacklist bezogen sich auf sehr alte SSD Generation.

Persönlich nutze ich seit längerer Zeit sowohl die Online Discard als auch die Batched Discard Funktion ohne Probleme.

 

[le0m]

Für mich liest sich der Artikel wie: Das Problem bestand in der Vergangenheit, ab 14.04 ist es aber wohl kein Problem mehr und Trim wird wöchentlich durchgeführt.

Ich wäre mir nicht so sicher. Ich benutze das aktuellste Mint. Wenn ich unter /etc/cron.weekly/ gucke, finde ich den fstrim Cronjob. Wenn ich ihn öffne steht folgendes im Comment:

# This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty
# firmware may encounter data loss problems when running fstrim under high I/O
# load (e. g.  https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run fstrim on
# all SSD drives.

Das spricht aus meiner Sicht eher dafür, dass die Whitelist noch existerit. Kann natürlich sein, dass die Whitelist entfernt und der Comment vergessen wurde. Wie soll man das herausfinden?

Ehrlich habe ich da den Verdacht, dass der Bug nicht bei der Hälfte der SSD zu suchen ist, sondern eher im Linux, genau wie damals der Bug mit TRIM und mdraid. Es ist einfach extrem unwahrscheinlich, dass so viele SSD Controller / FW Entwickler / Hersteller bei so vielen Modellen den gleichen Bug haben.

Egal wie rum. Ich fände es gute zu wissen, ob es meine SSD betrifft oder nicht.

Falls du eine aktuelle Distribution hast, würde ich es aktivieren.
Viele der Gründe für die Blacklist bezogen sich auf sehr alte SSD Generation.

Ich tendiere auch eher dazu es zu aktiveren. Wobei es nichts schlimmeres gibt als Datenverlust. Am schlimmsten ist es wenn dieser unbemerkt und schleichend von statten geht. Habe das mal gehabt. Als ich es bemerkte, hatten die fehlerhaften Dateien ihren Weg ins Backup schon gefunden und waren damit verloren. Das ist auch der Grund weshalb ich mehrere Backups in unterschiedlichen Zeitintervallen mache.

Persönlich nutze ich seit längerer Zeit sowohl die Online Discard als auch die Batched Discard Funktion ohne Probleme.

Dürfte ich fragen, was "Online Discard" und "Batched Discard" sind?

 

[Holt]

Wenn Du so eine Sorgen wegen Datenverlust hast, machst Du ja auch sicher regelmäßig Backups und wenn Du Dich vor schlechender Datenkorruption schützen willst, musst Du zuerst einmal ein System mit ECC RAM Funktionalität, also ECC-RAM, eine CPU und ein Board mit entsprechender Unterstützung dafür nehmen. RAM Fehler sind die bei weitem häufigste Ursache für Datenkorruption!

 

[Piktogramm]

@le0m

Solang du nicht an der Config herumfingerst, fängt das Whitelisting die bekannten Fehler ab. Wobei es mittlerweile so sein sollte, dass fstrim sich daran orientiert. Also es wird getrimmt, jedoch mit unterschiedlicher Strategie. Geräte in der Whitelist mittels Queued Trim und ansonsten eben ohne Queue. Im zweiten Fall schlägt Trim aber voll auf die Performance. Je nach SSD ist für Sekunden bis Minuten dann I/O r/w wirklich richtig langsam.

Den genauen Effekt wollte ich mal mit Holt klären, indem ich meiner M550 ein Firmwareupdate verpassen. Wobei die neue FW dann in der Whitelist stünde. Dummerweise bin ich Konservativ was FW-Updates angeht und mach sowas nicht. solang ich das betreffende Gerät tagtäglich brauche. Ich habe es noch auf dem Radar, vor Ende Februar / März sehe ich aber Schwarz.

Ansonsten Erfahrungswerte: Es ist unwahrscheinlich, dass ohne Gefrickel an der Config bei aktuellen Distributionen die bekannten Fehler auftreten. Trimmen kann durchaus sinnvoll sein, durch den Cronjob braucht es aber kein händisches Eingreifen, solang du nicht wirklich intensiv Schreiblasten erzwingst.

 

[Hallo32]

Dürfte ich fragen, was "Online Discard" und "Batched Discard" sind?

Online Discard:
Es wird direkt nach dem Löschen einer Datei der Trim Befehl an die SSD gesendet. (So wie Windows es in der Regel macht.)

Batched Discard:
Das ist das, was du gerade verwenden möchtest.
In regelmäßigen Abständen wird ein Programm aufgerufen (fstrim), welches anhand des Dateisystems die zu trimmenden Sektoren ermittelt und die Trim Befehle in einen Durchgang an die SSD sendet. (Unter Windows 10 kann man es mit der "Optimieren" Funktion von Defrag vergleichen.)

Persönlich ziehe ich die Online Discard Funktion vor. Ein Einbruch der I/O Leistung ist mir bei normaler Nutzung des Systems nicht aufgefallen.


Es gibt hier auch einen User (Transcend_de?) der vom Transcend Support ist. Evtl. kann er noch weitere Information liefern.

 

[Piktogramm]

Seit wann nutzt Windows online discard?

In der ThomasKren Wiki steht das zwar und es sind auch Quellen angegeben, aber die Quellen selbst erwähnen dieses Verhalten nicht. Hingegen finden sich viele (nicht zitierfähige Quellen...), die von einem Batchjob sprechen. Wenn es um Trim unter Win7 geht.

 

[Hallo32]

@Piktogramm

Wie trimmt Windows den sonst?

Schaue dir mal die Funktionsweise von Trimcheck an.

https://github.com/CyberShadow/trimcheck

 

[Piktogramm]

Ich versuch es mir anzuschauen. Bisherige Feststellungen:

Der Entwickler könnte ruhig mal Kommentare schreiben.
Der Quelltext lässt sich nicht gut lesen.

 

[Hallo32]

Im Prinzip ist es die Methode B im verlinkten Thread.
http://www.win-raid.com/t24f34-Easy-TRIM-test-methods.html

 

[Piktogramm]

Wenn ich trimcheck richtig verstehe, dann lässt sich darauf nicht ableiten, ob da ein online discard stattfindet, der jedem Löschbefehl gleich ein Trimbefehl hinterher schickt, oder aber ob Windows sehr zeitnah, jedoch mit Verzögerung gelöschte Bereiche per Batch trimmt. Die Fehlerbehandlung bei Trimcheck schaut für mich eher so aus, als ob die zweite Option zum Einsatz kommt. Denn es gibt extra eine Fehlerbehandlung, die direkt auf das Löschen folgt. Wobei da getestet wird, ob die soeben gelöschte Datei noch auffindbar ist. Als normales Verhalten wird erwartet, dass die Daten noch auffindbar sind und das Trim erst mit Sekunden Verzögerung eintritt. Was sehr nach Trim über Batch bzw. Deamon klingt.

Da müsste wirklich mal jemand eine Primärquelle auftun. Denn so ist es nur Spekulation, wieso das Programm geschrieben wurde wie es ist.

trimcheck.d ab Zeile 390 bis etwa 430 als Referenz

 

[le0m]

Solang du nicht an der Config herumfingerst, fängt das Whitelisting die bekannten Fehler ab. Wobei es mittlerweile so sein sollte, dass fstrim sich daran orientiert. Also es wird getrimmt, jedoch mit unterschiedlicher Strategie.

Du meinst also, wenn die SSD nicht auf der Whitlist ist, wird trotzdem getrimmt, nur nicht per "Batched Discard", sondern per "Online Discard". Soll heißen, wenn ich den --no-model-check Command hinzufüge, um den Cron-Trim zu aktivieren wird meine SSD (die ja nicht auf der Whitlist steht) mit beiden Methoden ("Online Discard" und "Batched Discard") getrimmt?

Also es wird getrimmt, jedoch mit unterschiedlicher Strategie. Geräte in der Whitelist mittels Queued Trim und ansonsten eben ohne Queue. Im zweiten Fall schlägt Trim aber voll auf die Performance. Je nach SSD ist für Sekunden bis Minuten dann I/O r/w wirklich richtig langsam.

Wenn die "Online Discard" bzw. "ohne Queue" Trim-Variante verwendet wird (was ja bei mir dann der Fall sein sollte), muss man mit krassen Performance Einbußen rechnen? Wenn das stimmt, wäre es mir um so wichtiger herauszufinden, ob die Transcend SSD den Trim per Cron verkraftet.

Wenn ich das höre wünschte ich meine SSD stünde auf der Whitelist :'(
Auf der Herstellerseite steht glaube ich, dass die SSD Trim unterstützt, aber das besagt wohl noch nicht, ob sie einen Komplett-Trim per cron/batch vertragen kann.

Wenn es so wäre, dass die Transcend den Trim per cron problemlos mitmacht und ich den --no-model-check verwende, wüsste ich immer noch nicht, ob damit der "Online Discard"-Trim deaktiviert wäre. Den müsste ich dann wohl auch noch manuell deaktiveren.

Wenn es so wäre, dass die Transcend den Trim NICHT verkraftet, müsste ich mir überlegen, ob ich Trim komplett (also auch den "Online Discard") deaktivere.

Es gibt hier auch einen User (Transcend_de?) der vom Transcend Support ist. Evtl. kann er noch weitere Information liefern.

Wenn keine sichere Quelle zufinden ist, müsste ich ihn wohl mal kontaktieren.

 

[Piktogramm]

Trim per Cron ist kein Problem, im Zweifelsfall bricht während des Trims die I/O Leistung schlicht massiv ein. Das sollte aber nur wenige Sekunden bis wenige Minuten dauern (je mehr geschrieben und wieder gelöscht wurde, desto mehr gibt es zu trimmen, desto länger dauert es). Fehler treten dabei nicht aus, solang dein System halbwegs aktuell ist. Beispiel Ubuntu 15.10, da wird der Conjob schlicht immer ausgeführt und Fehler fängt die Software bzw. die Whitelist ab.

Um die Auswirkung des Ganzen abzuschätzen: Ich habe fstrim noch nie bemerkt, außer ich habe es per Hand erzwungen. Wobei ein händisches Ausführen bisher nur erfolge, weil ich durchaus am Tag aus Schreiblasten von +100GB komme und diese recht zeitnah wieder lösche und die VMs und Datenbanken empfindlich sind, wenn die I/O Leistung ohne Trim etwas nachlässt.


OnlineDiscard und Batched discard würde ich bei Modellen die nicht whitelisted sind weglassen.

 

[Holt]

Online getrimmt wird bei Linux nur, wenn die entsprechende Mountoption "discard" eingetragen ist.

Piktogramm, ich glaube nicht das die Dauer des Offline TRIM davon abhängt wie viel geschrieben und gelöscht wurde, sondern eher wie groß und wie voll die SSD ist, wobei vor allem die Anzahl der Dateien und Fragmente zählen dürfte. Außer wenn Linux da ein Protokoll über alle Änderungen führt, wird nämlich beim Offline TRIM geschaut welche Adressen auf das SSD vom Filesystem belegt sind und für alle andere ein TRIM Befehl ausgelöst. Das dabei ein Risiko besteht wenn nebenbei auch geschrieben wird, nämlich das eine LBA erst als leer erkannt wird, dafür ein TRIM Befehl geniert wird bzw. um genauer zu sein der LBA Bereich in der Liste eines LBA Befehls landet (die übermitteln ja ganze Listen von LBA Bereichen), dann aber vor der Ausführung des Befehls ein Schreibzugriffe auf diese LBA erfolgt weil eine Datei geschrieben wurde.

Linux hat viel im I/O parallelisiert und dabei kann es leicht zu solchen Laufzeitproblemen kommen, wenn man nicht extrem gut aufpasst und genau so ein Problem, nämlich das der Puffer in dem der Bereich der zu trimmenden LBAs stand von einem anderen Thread überschrieben wurde, gab es ja schon bei dem Kernel Bug mit TRIM und mdraid. Eigentlich hatte ich gehofft, dass man dies zum Anlass nimmt sich das ganze mit der White- und Blacklist auch mal anzusehen, denn es riecht mir sehr nach einem weiteren Bug im Kernel, da es kaum wahrscheinlich ist, dass so viele Entwickler von so vielen unterschiedlichen SSDs den gleichen Fehler begehen.

 

[highks]

Ging es bei dieser Whitelist nicht ausschließlich darum, kein queued Trim auszuführen, weil das manche SSDs falsch handhaben?

Beim "altmodischen" TRIM gab es doch nie Probleme, oder habe ich da was verpasst?

 

[le0m]

Trim per Cron ist kein Problem, im Zweifelsfall bricht während des Trims die I/O Leistung schlicht massiv ein.

Angeblich ist es für einige SSDs leider schon ein Problem, sogar mit fatalen Auswirkungen (Datenverlust).. sonst wäre die Sache mit der Whitelist überflüssig. Einige SSDs vertragen angeblich kein Batched Discard..

Fehler treten dabei (beim Batched Discard) nicht aus, solang dein System halbwegs aktuell ist. Beispiel Ubuntu 15.10, da wird der Conjob schlicht immer ausgeführt und Fehler fängt die Software bzw. die Whitelist ab.

Was meinst du mit: "Fehler fängt die Software bzw. die Whitelist ab." ?. Für mich bedeutet das, wenn eine SSD NICHT auf der Whitelist steht wird entweder gar nicht getrimmt oder es wird per Online Discard getrimmt. Aber per Online Discard wird leider auch nicht getrimmt. Siehe Folgendes:

Linux unterstützt zwei Arten des Discard (nähere Details in der nachfolgenden Tabelle):

* Batched Discard – Der Befehl fstrim /mnt/point/ weist das Dateisystem an, ungenutzte Bereiche zu suchen und diese dem Controller der SSD zu melden. Dieser Befehl muss sporadisch und manuell vom Anwender ausgeführt werden.

* Online Discard – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden. Diese Funktion ist von Haus aus deaktiviert und muss vom Anwender in /etc/fstab mit der Option discard eingeschaltet werden.

Hier wird auch noch mal darauf hingewiesen, dass kein "Online Discard" per default aktiviert ist. Auch in meiner /etc/fstab ist keine Funktion per "discard" Command aktiviert.

Mein Vermutung ist, dass kein Batched (wegen Whitelist) und kein Online Discard (per default deaktiviert) stattfindet und deshalb gar nicht gertimmt wird..

Ich verstehe nicht wieso du meinst, dass die SSD getrimmt wird? Wo findet das statt, bzw. woher weißt du das?

OnlineDiscard und Batched discard würde ich bei Modellen die nicht whitelisted sind weglassen.

Was gibt es denn noch?

Update

Umso mehr ich zum Thema lese umso mehr glaube ich, dass es tatsächlich so ist, wie ich mir die Sache vorstelle. Der einzige Trim der in Ubuntu (vermutlich auch in Mint) per Default aktiviert ist, ist der Batched-Discard-Trim im weekly Cron und zwar nur für die SSDs, die auf der Whitelist stehen. Weil die SSDs einiger Hersteller so sensibel auf Trim reagieren und in manchen Fällen davon sogar zerschrottet werden können, haben sich die Entwickler für die Whitelist entschlossen. (Ich finde den Entschluss richtig, weil man kein OS auf den Markt bringen sollte, welches per default Hardware zerstört.) Das bedeutet, wenn man NICHT auf der Whitelist steht und Trimmen möchte, muss man dies manuell aktivieren und zwar entweder mit dem --no-model-check Befehl z.B. im Cron für ein wöchentlichen Batched-Discard-Trim oder per "discard" Befehl in /etc/fstab für den Online-Discard-Trim. Vorallem wenn man den Batched-Discard-Trim verwendet, muss man sich über die Konsequenzen im Klaren sein.

Hier wird das auch noch mal bestätigt: http://askubuntu.com/questions/443761/how-is-trim-enabled

Ich entschließe mich dazu den --no-model-check Befehl im Cron zu verwenden, da ich glaube, dass meine SSD den Batched-Discard-Trim verkraftet. So wie ich das verstehe sind nur die SSDs von dem Problem betroffen, bei denen die Hersteller nicht explizit darauf hinweisen, dass sie Trim unterstützen. Meine SSD unterstützt laut Transcend Trim.
Zusätzlich habe ich diesen Test durchgeführt, welcher positiv ausgfallen ist.

 

[Holt]

Es wird keine HW zerstört! Und so sehr ich Linux mag, da Windows keine derartigen Probleme hat und ich auch sonst noch von keinem anderen OS vom diesen Problemen gehört habe, halte ich Linux an der Stelle für buggy, auch wenn die oft zu stolzen Entwickler und Fanboys das nicht einsehen. Es muss wohl erst wieder eine SSD Herstellerfirma den Kernel debuggen um das Problem zu beheben.

 

[Piktogramm]

@Holt

Wie lang fstrim braucht, ist eine reine Feststellung meinerseits. Das Wie ist mit halbwegs unbekannt. Es ist jedoch ein deutlicher Zeitunterschied zwischen dem Trimmen von wenigen hundert MB und +200GB. Sowohl bei ner SanDsik SSD (die, die wirklich nur SSD heißt), einer M500 und einer M550 ohne aktualisierter FW.


@le0m

Das aktuelle Mint setzt auf Ubuntu 14.04 auf und dort war Trim (vor allem queued Trim) problematisch. Inwieweit da mit dem Update auf Kernel 3.19 und evtl Backports etwaige Fehler ausgemerzt wurden steht auf einem anderem Blatt. Ubuntuwiki und auch andere Quellen halten mit den Entwicklungen da nicht immer mit. Einträge bei Stackoverflow, launchbug etc. sind bei solchen Dingen schon nach wenigen Wochen/Monaten oft veraltet. Eben weil dankenswerterweise der Linux Kernel Patches erhalten hat.

Das Verhalten unter Ubuntu 15.10 ist mittlerweile, dass der Cronjob nicht mehr prüft. Da wird schlicht getrimmt und die Whitelist bestimmt nur das WIE und nicht das OB. Ubuntu 14.04 bzw das darauf aufbauende Mint verhalten sich da anders und Trim wird da wohl als eher instabil betrachtet.

Setzt du dein Cronjob auf --no-model-check spielst du mit deinen Daten Versuchskaninchen, denn wie Holt schon schrieb, der Linux Kernel war buggy und ob 3.19 + Backports mittlerweile save ist kann ich dir nicht verraten. Um da Infos zu erhalten solltest du gezielt zu Dokumentation nach Mitte August 2015 suchen. Sinnvoll wäre es wohl eher auf Ubuntu 16.04 und die entsprechend Aktualisierung bei Mint zu warten. Dann ist das Ganze wirklich kein Problem mehr. Dann steht im entsprechendem Cronjob nur noch "fstrim -all [...]" weil trimmen als zuverlässig angesehen wird.


Edit: Sorry, meine Post in diesem Thread sind teils arg unsortiert und damit mitunter falsch :/