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

 

[Christina]

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.

Du übersiehst, dass der SSD-Controller überhaupt keine Ahnung von einem Dateisystem hat und daher gar nicht zwischen z.B. btrfs, seinen snapshots und irgendwelchen Nutzerdaten unterscheiden kann.

Ich glaub das (TRIM, Anm. Christina) 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.

Nein.
Das Rolling Release openSUSE Tumbleweed, das von Haus aus komplett auf btrfs setzt, trimmt einmal pro Monat:

$ cat /usr/lib/systemd/system/btrfs-trim.timer

[Unit]
Description=Discard unused blocks on a mounted filesystem
Documentation=man:fstrim

[Timer]
OnCalendar=monthly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target

Das hier sind auch keine CronJobs, wie du gestern falsch geschrieben hast, sondern Units von systemd.

 

[Ambrosius]

Die Defaults von Suse, die du ansprichst, sind ja an und für sich auch ok. Ich hab darüber gesprochen welche Einstellung man vornimmt, wenn man sich sein System selbst zusammenbaut und feinjustiert.
Bei ner 1/2TB großen Systemfestplatte die auch noch <50% der verfügbaren Kapazität betrieben wird, sind die meisten Distro Trim Standards absolut ok und vernünftig. Bei ner 256GB großen Festplatte für / und /home würd ich das aber anders handhaben (just my 2 cents)

SSD-Controller überhaupt keine Ahnung von einem Dateisystem hat

Das ist mir schon bekannt. Das FS gibt Anweisungen an den Controller, und wie zwieblum richtig erkennt:

Aus Filesystemsicht sind Snapshots sehr wohl in Verwendung und die zugehörigen Blöcke werden verwendet und somit nicht freigegben

wäre die logische Schlussfolgerung in Form ein kleinen Gedankenexperiments:

Wenn ich eine Datei xyz.txt lösche, sie aber in meinem gestrigen Snapshot noch existiert, dann markiert sie btrfs zwar als gelöscht, aber 'reserviert' sie (metadatentechnisch gesprochen). Erst wenn ich das snapshot lösche, weist das FS den Controller an, den Block schlussendlich freizugeben. Wie wir wissen löscht der Controller xyz.txt aber auch nicht wirklich, sprich nullt die Betreffenden Flash Zellen nicht, sondern markiert sie auch wiederum nur als 'frei'. btrfs könnte sie also nicht wiederherstellen, aber intilligente Recovery Progs - wenn man weiss wie - schon.
Jetzt kommt eine dritte Abstraktionsebene hinzu. Erst der Trim Befehl sorgt dafür dass die Flashzellen wo sich xyz.txt befand auch tatsächlich platt gemacht werden? Geschieht das nu virtuell oder auch physisch?

ich hab das jetzt stark simplifiziert, natürlich gibt es physisch Blöcke, Sektoren und Pages die anders verwaltet werden. Ich hab das alles salopp unter Flashzellen subsummiert

Wenn man sich vorstellt, das xyz keine Textdatei ist sondern >100MB große *.db Daten, dann kommt schon schnell was zusammen.

Da die Performance der SSD mit alledem zusanmenhängt, ist das Gedankenexperiment die eine oder andere Überlegung wert, auch wenn letztlich nur fürs Gehirnjogging

 

[Corvus]

Im MS-DOS Filesystem(unter Windows dürfte das noch genauso sein) wurde beim Löschen bloß das erste Zeichen des Filenamens durch das kleine Zeichen für Beta, Delta oder Gamma ersetzt.
Alle dem Filenamen zugehörigen Blöcke können dann überschrieben werden und bei nem Undelete werden alle wieder reserviert. Können dann aber schon mehrfach in Benutzung gewesen sein und wenn ein Teil davon jetzt zu nem anderen File gehört ist das Wiederhergestellte auf jeden Fall defekt und sonst vielleicht.
Und beim TRIM muss das Filesystem jede Blockadresse dem Controller mitteilen und der löscht dann wohl oder zeitnah, weil er sonst ne eigene Datenbank in ner HPA (Host Protected Area) braucht, die nutzen Controller schon auf HDDs zum Speichern der Firmware etc.

In der c't war vor 5 bis 10 Jahren mal ein Artikel über Daten-Recovery. Da ließen sich von damals älteren SSDs Daten noch nach Wochen und bei damals Neuen bloß noch für Tage oder Stunden wiederherstellen. Wenn das durch TRIM verursacht wurde , dann galt das für alle gelöschten Files auf einmal.

Meine erste SSD war ne 256er von 2012. Systemdrive bis 2018 mit TRIM unter Windows.
Dann bis 2024 ohne TRIM in nem Linux DVB Receiver. Hat funktioniert bis zum Schluss, ich hab aber nie mehr die SMART Werte gecheckt und gerade solche wie Schreibvolumen und Health Level kannte die noch nicht. Wurde auch nicht mehr intensiv genutzt weil ich selten was aufnahm oder Timeshift nutzte beim Glotzen.

Das ist eigtl alles was ich zu TRIM weiß. Und das Windows es standardmäßig nutzt seit einem Update für Win7 schon bevor ich ne SSD hatte.

 

[Christina]

In der c't war vor 5 bis 10 Jahren mal ein Artikel über Daten-Recovery. Da ließen sich von damals älteren SSDs Daten noch nach Wochen und bei damals Neuen bloß noch für Tage oder Stunden wiederherstellen.

Wenn das für die sehr alten bzw. frühen SSDs galt, dann waren die Controller damals noch nicht so gut im Aufräumen, was ja auch eine hohe Rechenleistung und Programmierwissen durch die Entwickler erfordert. Aber Blöcke, die durch das Dateisystems als frei markiert wurden, können jederzeit und unabhängig vom SSD-Controller vom Dateisystem neu verwendet werden. Moderne Dateisysteme fassen eigenständig zusammenhängende Blöcke zusammen, um einer Fragmentierung vorzubeugen. Es ist alles bloß eine Frage der Schreib-Nutzung der SSD und eine Frage, wie viel freier Platz noch auf der SSD zur Verfügung steht.
Deswegen ist TRIM schon seit 10 Jahren unter Linux maximal noch ein wöchentlicher Vorgang auf den man aber fast genauso gut verzichten kann.

Du übersiehst, dass der SSD-Controller überhaupt keine Ahnung von einem Dateisystem hat

Das ist mir schon bekannt. Das FS gibt Anweisungen an den Controller

Ja natürlich! – Der SSD-Controller hat keine Ahnung von einem Dateisystem, aber das Dateisystem gibt dem SSD-Controller Anweisungen.
Du weißt offenbar noch gar nicht, was ein Dateisystem eigentlich ist, was es genau darstellt.