chmatse
Anmeldungsdatum: 22. Februar 2014
Beiträge: 4
|
Okay, ich hole mal ein wenig aus welche Gedanken ich mir gemacht habe: Wenn man im Internet stöbert kristallisieren sich folgende Facts heraus: Eine Speicherzelle kann je nach Typ 3K - 100K Schreibvorgänge absolvieren Damit eine Zelle nicht gleich nach drei Tagen durchgeröstet wird haben die Hersteller das "Wear-Leveling"-Verfahren ersonnen. Wie effizient da jeder Hersteller zu Werke geht bleibt im Verborgenen, denn der Algorithmus ist Herstellerspezifisch. Ob eine SSD defekt ist oder nicht hängt schlussendlich davon ab wieviele Löschzyklen vorgenommen wurden und wieviele Reserveblöcke noch vorhanden sind. Überschreitet eine Disk die vorgesehenen Grenzen, wird sie vorsichtshalber in einen Read-only Modus versetzt. Sie lässt also kein schreiben mehr zu und ist faktisch "Defekt".
Da ich nun nicht wissen kann, wie gut das jeweilige "Wear-Leveling"-Verfahren meiner aktuellen SSD ist, gehe ich einfach einmal davon aus, dass die einzelnen Speicherzellen eben doch nicht so gleichmässig häufig beschrieben werden wie ich mir das Vorstelle. Ich kann mir gut vorstellen, dass es da zwecks Performance-Gewinn beim lesen oder schreiben von Daten durchaus den einen oder anderen Kompromiss beim Wear-Leveling geben kann. Gehen wir nun einmal davon aus, dass meine Annahme von vorhin der Wahrheit entspricht. Dann würde das doch bedeuten, dass die Wahrscheinlichkeit dafür, das Blöcke öfters als andere überschrieben werden steigt. Und wenn diese Blöcke öfters beschrieben werden als andere, dann sind diese auch schneller "verbraucht" und es müssen somit früher Reserveblöcke herangezogen werden. Und somit steigere ich doch mit jedem Trim (ob nötig oder nicht) den Löschzyklen Counter und mit einem suboptimalen Wear-Leveling verbrauche ich früher Reserveblöcke. Und das läuft zwangsläufig auf einen "früheren Tod" einer SSD heraus, weil ich die Grenzen einfach früher erreiche. Und aus diesem Grund glaube ich, dass mein SSDcronTRIM durchaus hilfreich sein kann, wenn es um die Verlängerung der Lebensdauer der SSD geht. Denn dadurch dass ich "dosierter" Trimme steigt der Counter für die Löschzyklen weniger schnell an und aufgrund der länger liegen bleibenden Daten werden vielleicht auch eher andere Speicherzellen mit Schreibzyklen beglückt. Und was würde es bedeuten, wenn meine Annahme falsch ist und alle "Wear-Leveling"-Verfahren absolut zuverlässig wären und die Daten in jedem Fall gleichmässig verteilen würden? Nun, dann hat das Programm bis auf einen dynamischeren Trim-Zyklus keinen weitere Einfluss auf das System und insbesondere die SDD.
|
ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Warum so ablehnenend? Die Idee von Matse ist doch gut und zeigt, was man mit Linux so einfach selbst machen kann. Und das Prinzip "fire and forget" ist doch toll (speiell für Newbies, die Terminals hassen) 👍 Ich selbst trimme auch wöchentlich mit
nice ionice -c idle fstrim -vm 1M
und habe dafür ein Script mit Log-Funktion und Zeitstempeln $(date -R) erstellt. Der TRIM dauert 3 sec. für die 32GiB-Systempartition. Zusätzlich mounte ich - nur zum Trimmen - noch eine weitere Partition, weil das System darauf, bzw. der Kernel kein TRIM unterstützt. Weekly finde ich auch angemessen, meine 120GB SSD hat sogar noch 20 GB unpartitionierten Bereich als spare area und die genutzten Partitionen sind auch nur zu ca. 50% gefüllt. Das Verhältnis Read/Write ist bei meiner S3500 bisher 10:1. Die großen Datenmengen liegen natürlich auf einer rotational HD 😉 Ingo
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
chmatse schrieb: Und somit steigere ich doch mit jedem Trim (ob nötig oder nicht) den Löschzyklen Counter
Nein, TRIM != Löschen. Gelöscht wird wie gesagt nur einmal, egal wie oft du trimmst. Bei modernen SSDs ist TRIM eigentlich fast nicht mehr nötig (nur um die maximale Geschwindigkeit zu sichern) denn selbst gerade belegte Sektoren werden irgendwann ausgetauscht, wenn sie nur selten beschrieben wurden. Auch wenn die SSD voll ist, hat sie ja immer noch den Reservebereich, den sie zum durchwechseln der Sektoren verwenden kann, das sind bei einer 240GB SSD immerhin 32 (echte) GB. dass mein SSDcronTRIM durchaus hilfreich sein kann, wenn es um die Verlängerung der Lebensdauer der SSD geht.
Zumindest im Vergleich mit monatlichem Trim, da dein Script ja teilweise öfter trimmt. Wenn es dir aber um die maximale Lebensdauer geht (wir reden hier über wenige Monate oder Wochen bei viel beschriebenen SSDs), dann solltest du discard verwenden, damit ist sicher gestellt, dass immer der maximal verfügbare freie Speicher zum neu beschreiben verwendet werden kann und weniger belegte Blöcke ausgetauscht werden müssen. Und was würde es bedeuten, wenn meine Annahme falsch ist und alle "Wear-Leveling"-Verfahren absolut zuverlässig wären und die Daten in jedem Fall gleichmässig verteilen würden? Nun, dann hat das Programm bis auf einen dynamischeren Trim-Zyklus keinen weitere Einfluss auf das System und insbesondere die SDD.
Jupp, ich habe auch nix gegen dein Script, finde nur, dass es keinen relevanten Vorteil gegenüber den anderen Methoden hat. Wenn du es ins Wiki einarbeiten willst, dann nur zu ...
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7648
|
ingo2 schrieb: Warum so ablehnenend?
Wenn jemand einen Einzeiler durch einen 500-Zeilen-Apparat ersetzt, wird man ja wohl mal nachhaken dürfen. Das ganze scheint ja auf einem Mißverständnis zu beruhen. Das geänderte Verhalten könnte man nebenbei auch durch einen Einzeiler realisieren. [[ $(($(stat -f -c "%f*100/%b" /))) -ge 42 ]] && fstrim / Führt fstrim / aus wenn der freie Speicher 42% oder mehr. Das mit angepassten Werten in cron.{hourly,daily,weekly,monthly} abgelegt und der Füllstand würde sogar stündlich überprüft werden. Einen Sinn sehe ich darin aber immer noch nicht. Wöchentlich und gut. Das discard Flag mag ich aus mehreren Gründen nicht; einmal wegen der Performanzprobleme, zum anderen weil es bei einem versehentlichen Löschen jegliches undelete verhindert. Aus dem gleichen Grund habe ich bei meinem LVM auch kein issue_discards, sondern entscheide selbst ob/wann das passiert (blkdiscard vor dem lvremove oder danach auf ein temporäres -l100%FREE LV). Trim ist bei weitem nicht so wichtig daß man dafür riesengroße Scripte schreiben müsste oder es sofort durchführen müsste...
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu! Ab 14.04 hat sich das womöglich sowieso alles erledigt: Ubuntu 14.04 to Feature SSD TRIM Support By Default Siehe auch Posting. Liebe Grüße, Flo
|
chmatse
Anmeldungsdatum: 22. Februar 2014
Beiträge: 4
|
stfischr schrieb: chmatse schrieb: Und somit steigere ich doch mit jedem Trim (ob nötig oder nicht) den Löschzyklen Counter
Nein, TRIM != Löschen. Gelöscht wird wie gesagt nur einmal, egal wie oft du trimmst.
😳 Höhre ich da einen dumpfen Schlag von mehrmals hart auf Holz aufknallendem Kopf? Du hast natürlich recht! 😕
dass mein SSDcronTRIM durchaus hilfreich sein kann, wenn es um die Verlängerung der Lebensdauer der SSD geht.
Zumindest im Vergleich mit monatlichem Trim, da dein Script ja teilweise öfter trimmt.
[...]
Jupp, ich habe auch nix gegen dein Script, finde nur, dass es keinen relevanten Vorteil gegenüber den anderen Methoden hat. Wenn du es ins Wiki einarbeiten willst, dann nur zu ...
Ich danke dir für dein Angebot. Ich überlege es mir noch ob ich das ins Wiki einpflege oder nicht. Es hat zwar tatsächlich keinen relevanten Vorteil gegenüber den anderen Methoden, aber zumindest für Newbies könnte das Script von Interesse sein. Es prüft schliesslich ob Disk, Dateisystem und Kernel Trim unterstützen und macht gleich alle relevanten Einträge im jeweiligen Cron für alle angegebenen Mountpoints. Und schneller erstellt ist das ganze auch noch als wenn man alles von Hand macht 😀 Wie ingo2 schrieb, wäre das für Newbies die Terminals hassen sicherlich eine Erleichertung... (Irgendwie muss ich mir das ganze Script doch schönreden oder 😇 😀 ) frostschutz schrieb: ingo2 schrieb: Warum so ablehnenend?
Wenn jemand einen Einzeiler durch einen 500-Zeilen-Apparat ersetzt, wird man ja wohl mal nachhaken dürfen. Das ganze scheint ja auf einem Mißverständnis zu beruhen.
Also Prinzipiell finde ich das intervenieren von frostschutz und stfischr ganz okay. Sie haben ja nicht einfach geflamed sondern einfach gefragt wozu das gut sein soll. Und schlussendlich hat sich ja gezeigt, dass ich tatsächlich einem Denkfehler auferlegen bin. Lieber Gruss Matse
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu! Ich habe mal den Abschnitt zu Trusty-SSD-TRIM eingebaut: Automatischer TRIM ab Ubuntu 14.04 LTS. Sollte soweit verständlich sein, hoffe ich. Wenn das ausführlicher gewünscht wird (man kann seine SSD erst selbst lasttesten), dann sagt mir das bitte. Dann baue ich das noch ein. Liebe Grüße, Flo
|
busybit
Anmeldungsdatum: 29. Dezember 2010
Beiträge: 171
|
Hallo, im Abschnitt "Online-Discard" fehlt mir noch eine Info: wenn ich den Online-Discard über mount Option nutzen will, wie deaktiviere ich dann dauerhaft das wöchentliche cron script? Und zwar so, dass es nicht bei einem Update des entsprechenden Pakets wieder aktiviert wird? Lässt sich das überhaupt verhindern?
|
UbuntuFlo
Anmeldungsdatum: 8. Februar 2006
Beiträge: 12317
Wohnort: /home/flo
|
Huhu! Die Info wird auch nicht in den Artikel einfließen. Das Trimmen via Batched Discard ist in Trusty voreingestellt und auch der empfohlene Weg bei Versionen vor Ubuntu 14.04. Online Discard ist teilweise nicht empfehlenswert. So stand das auch mal im Artikel bis es geändert wurde. Das c't-Magazin warnte damals vor Online Discard. Wenn Du den voreingestellten Weg via fstrim umgehen willst, kannst Du den Cronjob /etc/cron.weekly/fstrim löschen. Dann wird nichts mehr (automatisch) getrimmt. Um durch die Updates nichts „untergeschoben“ zu bekommen, musst Du das Paket util-linux pinnen. Davon rate ich aber dringend ab! Das Paket util-linux enthält die beiden Skripte (siehe Liste der Dateien). Die beiden Skripte fstrim und fstrim-all selbst sind im Ordner /sbin zu finden. Liebe Grüße, Flo
|
busybit
Anmeldungsdatum: 29. Dezember 2010
Beiträge: 171
|
Und warum wurde vor Online-Discard gewarnt? Von der Theorie her müsste das sicherer sein, denn beim Batch-Discard besteht die Gefahr von Race Conditions. Wird ja auch im Artikel genannt, dass es Probleme geben kann wenn gleichzeitig heavy io stattfindet.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7648
|
busybit schrieb: Und warum wurde vor Online-Discard gewarnt?
Zum einen gibts Performanzeinbußen. Wenn du viele Dateien auf einmal löschst dauert es mit Online Discard (Instant Discard) länger, weil die SSD einfach Zeit zum Bearbeiten der TRIM-Befehle braucht. Zum anderen hast du keine Möglichkeit mehr, versehentlich gelöschte Daten wieder herzustellen. Und ansonsten ist es in der Praxis einfach egal, ob du sofort oder nur alle paar Tage/Wochen trimmst. Solange die SSD nicht rand voll ist, sind so oder so immer freie Blöcke vorhanden.
Von der Theorie her müsste das sicherer sein, denn beim Batch-Discard besteht die Gefahr von Race Conditions.
fstrim ruft den FITRIM ioctl auf. Das ist eine Dateisystem-Funktion. Das Dateisystem bestimmt also auch bei fstrim in voller Kontrolle selbst, wie es den TRIM durchführt. Wenn das Dateisystem da einen Fehler macht und Daten verliert - ist es schlichtweg ein Dateisystem-Bug, und das kann dich beim Online-Discard dann genauso erwischen. Du kannst das Dateisystem auch umgehen und die SSD direkt trimmen. Das ist dann aber nicht mehr FITRIM sondern BLKDISCARD und dafür gibts ein eigenes Tool (eben blkdiscard). Praktisch wenn du vor einer Neuinstallation tabula rasa machen willst.
|
lg51
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 454
|
Hallo Ich bin durch diesen Artikel ( https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ ) etwas alarmiert. Darin ist die Rede davon, dass der TRIM Befehl in den aktuelleren Linux-Kernelversionen wohl im Zusammenhang mit gewissen Samsung SSDs zuverlässig zu Datenverlust führt. im Artikel ist explizit auch die "Samsung SSD 840 PRO"-Serie als betroffen erwähnt, und eine solche habe ich in meinem PC verbaut. Weiss jemand mehr dazu? Gibt es Informationen, inweiweit wir als Ubuntu-Nutzer (14.04 LTS) davon potentiell auch betroffen sind? Sollten wir TRIM deaktivieren, und falls ja, wie ist dabei vorzugehen?
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7648
|
Der Blogpost scheint zur Zeit durch alle Medien zu geistern. Es fehlen ein paar Infos, etwa welcher RAID-Level benutzt wurde. Mit RAID0+TRIM+EXT4 gabs kürzlich einen fiesen Bug in Linux. NCQ schalte ich ab, da gibts auch Bugs und speziell mit meiner SSD (Crucial) sind da auch Korruptionsprobleme bekannt. Die ist aber inzwischen auch auf der Kernel-Blacklist. TRIM wirft Daten weg. Wenns in Verbindung damit dann im Kernel eine Blacklist gibt, kann man schon mal nachdenklich werden. TRIM ist auch nicht so unglaublich wichtig. Dem Durchschnittsnutzer fällt da kein Unterschied auf zwischen TRIM und nicht TRIM. Auf einem Server wo jedes bisschen Performanz zählt weil das Ding am brennen ist, sieht das vielleicht anders aus. Backups sind auf jeden Fall wichtig. Datenverlust ist ja auch so jederzeit möglich, SSD können auch einfach kaputt gehen. Mit einer guten Backuplösung hat man nur noch halb so viele Sorgen.
|
busybit
Anmeldungsdatum: 29. Dezember 2010
Beiträge: 171
|
Ich nutze seit über einem Jahr eine Samsung MZ-7TE250BW Serie 840 EVO Basic mit einem 3.2 Kernel, ext4 und Online-Discard, und hatte noch keine Probleme damit.
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 3309
|
Für den Abschnitt im Wiki: https://wiki.ubuntuusers.de/SSD/TRIM/#TRIM-mit-Festplattenverschluesselung möchte ich für nachschauen, ob die discard-Option aktiv ist, eine Optimierung zur Bequemlichkeit vorschlagen, denn das funktioniert auch mit Wildcard - und mit awk lässt sich das relevante allow_discards in der letzten Spalte auch gleich leicht finden:
sudo dmsetup table /dev/mapper/sd*_crypt | awk '{print $NF}'
Hier getestet mit Kubuntu 16.04 Xenial Xerus.
Ausgabe dann:
allow_discards
|