SSD und Trim

[cyrax]

Hi,

ich möchte mal was großes wagen und von Ubuntu Mate auf ein freies Arch Linux wechseln (Parabola oder Hyperbola). Der Grund ist folgender, alle anderen nur mit freier Software arbeitenden BS sind mir einfach zu alt von den Paketen her (Debian, Trisquel ...)

Da die Platte dank Libreboot komplett verschlüsselt werden soll bin ich auf diese beiden Artikel gestoßen: Arch Wiki, Blog, und würde gerne wissen ob sich an der Thematik etwas geändert hat oder wie vielleicht Arch Nutzer mit SSD das handhaben?
Wir die Lebenszeit einer SSD ohne Trim wirklich so sehr in Mitleidenschaft gezogen? Da die Basis ein X200 bildet sind Einbußen in der Geschwindigkeit auch nicht wirklich wichtig, da der Durchsatz ja eh schon limitiert ist.

Mein Fazit wäre, kein Trim da die SSD trotzdem fixer ist und die Lebenszeit nicht drastisch verkürzt wird. Habe gerade mal im Ubuntu nachgeschaut und hier ist Trim auch bei bis /boot verschlüsselter Platte aktiv.

Thx
cyrax

 

[ferda]

Ich hatte eine ganze Zeit lang eine verschlüsselte Festplatte mit der Option

allow-discards

im Betrieb, sodass Trim aktiv war. Theoretisch erlaubt das Rückschlüsse auf die Struktur der Daten, aber für mich war das der beste Kompromiss.

 

[owl102]

Wir die Lebenszeit einer SSD ohne Trim wirklich so sehr in Mitleidenschaft gezogen?

Naja, sobald jeder Sektor der SSD mindestens einmal benutzt wurde könnte die SSD ohne TRIM halt bei jedem Schreibvorgang auf die Idee kommen, erst einmal einen anderen Sektor umzukopieren, der gar nicht umkopiert werden müsste, da nicht in Verwendung (, was die SSD aber ohne TRIM nunmal nicht weiß).

Ob das nun unter "so sehr in Mitleidenschaft gezogen" fällt, mußt du selbst entscheiden. Ich zumindest sehe keinen Grund, TRIM nicht zu verwenden.

 

[Gummiente]

Ich habe mal vor einiger Zeit mit Samsung Magician die Firmware auf einem duzend Desktop PCs aktualisiert und mir dabei die Werte angesehen.

Keine einzige SSD hatte die 10 TB Marke beim Schreiben geknackt obwohl einige über fünf Jahre alt gewesen sein dürften. Seitdem mache ich mir zumindest auf Desktop keine Gedanken mehr über die Haltbarkeit.

 

[Volvo-Berti]

diese Frage nach TRIM hatte ich mir heute auch gestellt, u.a. weil seit Sparkylinux 5 (ein Debian-System) das X220 langsamer bootet als unter Win 10 (ca. 15s statt 5).
danach allerdings merke ich nichts von einer Einschränkung.

Gefunden habe ich, das ich das TRIM evtl. aktivieren muss http://blog.helmutkarger.de/linux-und-moderne-ssd-speicher/ Pkt 9. Allerdings weiß ich nicht, ob das auch unter Debian so funktioniert. Auch weiß ich nicht, ob es evtl. schon aktiviert ist. Das muss ich mal checken.

allerdings ist im X220 eine Samsung 830 drin, die ja auch schon etwas älter ist. Gibt es bei der evtl. eine Einschränkung?

 

[cyrax]

Also ich habe mich dazu entschieden Trim weg zu lassen und mal schauen ob sich das langfristig negativ bemerkbar macht. Da ich aber auch eher wenig Daten habe und auch nicht viel installiere sollten sich die Schreibraten auch in Grenzen halten.

@ meinst du der Performance Verlust liegt an dem Trim Befehl? Ich dachte es wirkt sich nur marginal aus und der eigentlich kritische Punkt ist die Haltbarkeit aufgrund der Schreibvorgänge wie in den Links beschrieben.

 

[mcb]

https://de.wikipedia.org/wiki/TRIM

"Durch den ATA-Befehl TRIM[SUP][2][/SUP] wird dem Laufwerk beim Löschen von Dateien mitgeteilt, dass es die davon betroffenen Blöcke als ungültig markieren kann, anstelle deren Daten weiter vorzuhalten. Die Inhalte werden nicht mehr weiter mitgeschrieben, wodurch die Schreibzugriffe auf das Laufwerk beschleunigt und zudem die Abnutzungseffekte verringert werden."

 

[Volvo-Berti]

ich habe nun TRIM aktiviert als daily job und es auch mal manuell gestartet, wie hier https://wiki.debian.org/SSDOptimization im Text beschrieben.

 

[cyrax]

https://de.wikipedia.org/wiki/TRIM

"Durch den ATA-Befehl TRIM[SUP][2][/SUP] wird dem Laufwerk beim Löschen von Dateien mitgeteilt, dass es die davon betroffenen Blöcke als ungültig markieren kann, anstelle deren Daten weiter vorzuhalten. Die Inhalte werden nicht mehr weiter mitgeschrieben, wodurch die Schreibzugriffe auf das Laufwerk beschleunigt und zudem die Abnutzungseffekte verringert werden."

Die Frage ist aber ob sich um einen "messbaren" oder "fühlbaren" Unterschied handelt. Wenn das nur in irgendwelchen Benchmarks zu sehen ist, was ich glaube, denn ansonsten würde das in den Wikis wohl expliziter erwähnt werden, wäre das ja verschmerzbar. Ich werde hier mal in einem Ubuntu System das Trim abschalten und schauen wie/ob sich das im täglichen Gebrauch bemerkbar macht.

- - - Beitrag zusammengeführt - - -

ich habe nun TRIM aktiviert als daily job und es auch mal manuell gestartet, wie hier https://wiki.debian.org/SSDOptimization im Text beschrieben.

Und hat sich die bootzeit verkürzt?

 

[Volvo-Berti]

nicht wesentlich. mir gings ja auch um das TRIM

 

[Ambrosius]

Bin hier zufällig mal über den Thread gestolpert und wollt dich @cyrax mal fragen ob du eine kleine Bilanz ziehen kannst zum dem Thema 'Trim & LUKS'?

Hast du dein Setup so einrichten können und wenn ja kann man ne Art Defragmentierung der SSD fesstellen?

 

[Christina]

Ich werde hier mal in einem Ubuntu System das Trim abschalten und schauen wie/ob sich das im täglichen Gebrauch bemerkbar macht.

kann man ne Art Defragmentierung der SSD fesstellen?

Ein fehlendes TRIM macht sich, wenn überhaupt, erst nach Jahren bemerkbar. Solange genügend freie Pages auf der SSD vorhanden sind, gibt es für den SSD-Controller noch andere Techniken zum Aufräumen. TRIM ist bloß eine davon.

Die Flash-Zellen einer SSD sind im Prinzip völlig fragmentiert, weil sie nach jedem größeren Schreibvorgang neu zusammengefasst werden.
Was der SSD-Controller nach außen, zum Betriebssystem hin als Blockgerät abbildet, ist in keiner Weise mit dem vergleichbar, was sich auf den Flash-Zellen abspielt.

 

[cyrax]

Bin hier zufällig mal über den Thread gestolpert und wollt dich @cyrax mal fragen ob du eine kleine Bilanz ziehen kannst zum dem Thema 'Trim & LUKS'?

Hast du dein Setup so einrichten können und wenn ja kann man ne Art Defragmentierung der SSD fesstellen?

Hi, ne ich habe da von der Geschwindikeit her keinen Unterschied fühlen können und daher verwende ich immer das default Setting des jeweiligen OS und da ist TRIM eigentlich immer an. Arch war nur ein kurzer Ausflug bin wieder bei Ubuntu gelandet.

 

[Ambrosius]

Solange genügend freie Pages auf der SSD vorhanden sind, gibt es für den SSD-Controller noch andere Techniken zum Aufräumen. TRIM ist bloß eine davon.

Ja, eben. Wear Leveling ist natürlich so ein Oberbegriff dafür.

Zugegeben, das ist ja ein alter Hut und der von dir verlinkte Blogartikel (<- Dennoch sehr lesenswert!!) ist anno heute fast 15 Jahre alt. Seitdem ist die Verschlüsselungstechnik sehr viel weiter. Auch die Controller der SSDs (HW-seitig) und die Software (truecrypt,luks,etc) sind sehr viel weiter. Ich hatte das als Gedankenanstoß verstanden für weitere Diskussion, da mich der technische Unterbau sehr interessiert, ich mich aber keinesfalls so gut mit der Materie auskenne, was wohl wiederum Grund für die Neugier ist, als dass ich darüber qualifizierte Aussagen treffen könnte. Aber eben auch im Sinne der Systemoptimierung ist das Thema Trim (mit oder ohne Crypto) immer interessant und ich finde immer wieder neue fstab Optionen die damit einhergehen. Andererseits lese ich manchmal dass fstab ein Relikt aus vergangen Zeiten sei und das das Einhängen von Datenträgern anders besser ginge. (Bestimmt ist damit irgend einer der vielen Köpfe der Hydra aka sysd gemeint).

Nun denn.

 

[Christina]

das default Setting des jeweiligen OS und da ist TRIM eigentlich immer an

Die Bedeutung von TRIM wird oft völlig überbewertet:
cat /usr/lib/systemd/system/fstrim.timer

[Unit]
Description=Discard unused filesystem blocks once a week
Documentation=man:fstrim
ConditionVirtualization=!container
ConditionPathExists=!/etc/initrd-release

[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
RandomizedDelaySec=100min

[Install]
WantedBy=timers.target

 

[Ambrosius]

Das ist der einmal wöchentliche CronJob, der den discard Befehl aus der fstab ersetzt. Glaub auch dass das besser isz, als wenn das unmittelbar nach ner Löschaktion geschieht. (alternativ discard=async?)

Die Bedeutung von TRIM wird oft völlig überbewertet:

Ich glaub das hängt stark vom Nutzungsverhalten ab. Wenn laufend Schreibaktionen im / geschehen, dann ist Trim sicher sinnvoll. Ich denke da v.a. an rollende Distros die gepaart mit nem hohen package count täglich mehrere MB/GB an Updates bereitstellen.

 

[Ravensberger]

Ein wöchentlicher Start ist aber wirklich viel. Ich habe den Timer jetzt einmal auf OnCalenda=monthly gesetzt. Debian Stable, so viel tut sich hier auch wiederum nicht.

 

[zwieblum]

in fstab die option "discard" tut's auch, wenn man sicher sein will.

Aber beachte was in der Manpage von fstrim steht:
"Running fstrim frequently, or even using mount -o discard, might negatively affect the lifetime of poor-quality SSD devices. For most desktop and server systems a sufficient trimming frequency is once a week. Note that not all devices support a queued trim, so each trim command incurs a performance penalty on whatever else might be trying to use the disk at the time."

 

[Ambrosius]

in fstab die option "discard" tut's auch, wenn man sicher sein will.

Ja, das ist dann so eine 'Einstellungssache'. Deswegen mein obiger Einwand.

Wenn ich btrfs nutze ist discard in der fstab dann nicht kontrapoduktiv? Ich frage v.a. in Bezug auf die snapshotting Funktion, weswegen man ja auf CoW FSe wie btrfs zurückgreift. Oder anders gefragt wie wirkt sich denn das Trimmen gelöschter Blöcke auf das Zurückspielen vergangener Snapshots aus? Sollte das nicht in den Metadaten auch irgendwie festgehalten werden?

Ja ich weiss, ich übersehe was, denn ich kann mir nicht vorstellen, dass Trim und Wear Leveling allgemein dem FS da in seiner Grundfunktionalität in die Quere kommen dürften.

 

[zwieblum]

Vo FS freigegebene Blöcke werden nicht mehr verwendet / referenziert. Aus Filesystemsicht sind Snapshots sehr wohl in Verwendung und die zugehörigen Blöcke werden verwendet und somit nicht freigegben.