[[Vorlage(Getestet, noble)]] [[Vorlage(Fortgeschritten ) ]] {{{#!vorlage Wissen [:Terminal: Terminal öffnen] [:mit Root-Rechten arbeiten:mit Rootrechten arbeiten] [:Editor: Editor öffnen] [:fstab: Bearbeiten von /etc/fstab] }}} Dieser Artikel ist Teil der Artikelserie [:SSD:], welche das Thema [wikipedia:Solid_State_Drive:Solid State Drives] behandelt. [[Inhaltsverzeichnis() ]] [[Anker(sda) ]] {{{#!vorlage hinweis Vorliegender Artikel benennt * die SSD stets mit der Gerätedatei '''/dev/sda''', * eine Partition auf diesem Gerät als '''/dev/sda99''' und * ein aus dieser Partition abgeleitetes virtuelles Blockgerät als '''SDA99'''. Alle Befehle müssen vor ihrer Anwendung auf die beim eigenen System konkret zutreffende(n) Gerätedatei(en) angepasst werden. }}} [[Bild(Wiki/Icons/SSD.png, 64, align=left)]] [wikipedia:TRIM:] ist ein sehr wichtiger Befehl zur Funktionserhaltung von Flash-Speicher wie beispielsweise SSD. Abhängig von Art des Speichermediums und der verwendeten Schnittstelle werden auch die Namen Discard, UNMAP, ERASE und Deallocate verwendet; zu den Unterschieden lese den Artikel bei Wikipedia. Abseits von SSD ist TRIM auch ein wichtiges Thema in Kontext [wikipedia:Thin_Provisioning:] zur Bereitstellung von Speicherkapazität – diese Aspekte werden aber im vorliegenden Artikel ignoriert, der TRIM im folgenden Text immer als Synonym zu „Discard bei SSDs“ versteht. Im produktiv laufenden System ist TRIM nicht zwingend erforderlich und oft kann man es auch benutzen, ohne sich selbst darum zu kümmern. * ->[#Ist-TRIM-erforderlich Ist TRIM erforderlich?] * ->[#TRIM-durch-das-Betriebssystem Standardeinstellung] = Einleitung = == Was macht TRIM? == Ein Dateisystem wie z.B. [:ext:ext4] oder [:btrfs:] kennt die beiden Klassen * belegte Speicherblöcke (''cluster''), in denen aktuelle Dateien gespeichert sind und * freie Speicherblöcke, die entweder noch nie benutzt wurden oder in denen Teile von gelöschten Dateien gespeichert sind. Wenn eine neue Datei gespeichert werden soll, wird der benötigte Speicherplatz diesem Pool entnommen, wobei zwischen „nie benutzt“ und „gelöscht“ nicht differenziert wird. Eine SSD kennt dagegen * benutzte Speicherblöcke (''pages''), in denen aktuelle oder gelöschte Daten gespeichert sind und * unbenutzte Speicherblöcke, die für die Speicherung neuer oder aktualisierter Daten verwendet werden können. Das bedeutet: Die Änderung auch nur eines Bits in einer existierenden Datei belegt mindestens einen weiteren Speicherblock auf der SSD. Der Befehl TRIM (und seine Verwandten) dient dazu, dem Gerät die Sicht des Dateisystems zu vermitteln, damit auf dem Gerät Bereiche mit gelöschten Daten wieder für neue Zwecke benutzbar werden. Zur Überführung eines benutzten Speicherblocks in den Zustand „unbenutzt“ muss dieser tatsächlich gelöscht werden, was die SSD altern lässt. -> [:SSD/Begriffsdefinitionen#TRIM:] Zur Minimierung von Schreibzugriffen auf eine SSD und damit später notwendigen TRIM-Aktionen kann man flankierende Maßnahmen (die natürlich auch Nachteile haben) ergreifen: * Einbinden von Dateisystemen stets mit der Option `relatime` (ist inzwischen Standard) oder sogar mit `noatime`. * Abschalten oder Reduzierung der Journal-Einträge z.B. bei einem Dateisystem `ext4`. == Voraussetzungen == Die Nutzung von TRIM bedarf einiger Voraussetzungen: * Das Gerät – die SSD – muss es unterstützen. Dies darf inzwischen (Stand 2024) für jede neu produzierte SSD als gegeben vorausgesetzt werden. Lediglich bei uralten Exemplaren aus den ersten Baureihen kann es noch fraglich sein. -> [#TRIM-testen Unterstützt mein Gerät TRIM?] * [[Anker(Kernel-TRIM) ]]Der [:Kernel:] unterstützt es seit Ende 2008 ab Version 2.6.28 mit der Funktion Discard (englisch: discard – (etwas) verwerfen); diese ist für den Anwender über verschiedene Wege zugänglich: * Das Programm [:hdparm:] kennt Optionen `--trim…` für Experten. [[Vorlage(Warnung, "Das Paket '''hdparm''' enthält auch das Skript '''wiper.sh''', welches man auf keinen Fall ohne vorheriges Lesen seiner Dokumentation starten sollte! Auch nach dem Lesen der Dokumentation startet man es besser nicht, es droht Datenverlust." ) ]] * Manche [:Dateisystem:Dateisysteme], insbesondere [:ext:ext2] und [:btrfs:] kennen Optionen wie z.B. `discard`, mit denen man beim [:mount:Einbinden] des Dateisystems die automatische Verwendung von TRIM konfigurieren kann. * Es gibt die Dienstprogramme `blkdiscard` und `fstrim`, mit derer Hilfe man mit Rootrechten[2] für das gesamte Gerät oder selektiv für ein Dateisystem oder auch für einzelne Speicherbereiche TRIM ausführen lassen kann. In diesem Artikel wird im folgenden Text nur der Befehl `fstrim` aus dem Paket '''util-linux''' verwendet. * Man muss als Anwender bereit sein, TRIM auch anzuwenden bzw. zuzulassen. Aus der Einführungsphase von SSDs gibt es noch Relikte damaliger heftiger Diskussionen mit ernsthaften Bedenken zu TRIM – die aber aus heutiger (2024) Sicht nicht mehr relevant sind. ## -> [:Baustelle/SSD/TRIM/Diskussion:] == Vorteile und Nachteile == TRIM ist kein Werkzeug zur Steigerung der Geschwindigkeit einer SSD, sondern dient zur Bereinigung von Speicherbereichen. Unnötig (d.h. mit veralteter Information) belegte Bereiche werden einer möglichen Wiederverwendung zugeführt. Diesem einzigen Vorteil stehen als Nachteile gegenüber: * Bei der Durchführung einer TRIM-Aktion kommt es unvermeidlich zur Unterbrechung der Arbeitsfähigkeit des betroffenen Datenträgers. Dies kann auch, insbesondere wenn das auf '''/''' eingebundene Root-Dateisystem getrimmt wird, zum zeitweisen Einfrieren des Systems führen, dessen Dauer abhängig vom Umfang vorheriger Änderungen auf dem Datenträger unmerklich kurz, wenige Sekunden oder auch störend lang sein kann. Zur Abhilfe kann man die TRIM-Aktionen auf Zeiten schwacher Systemnutzung legen. * Jede durchgeführte TRIM-Aktion lässt die SSD altern. Zur Abhilfe sollte man TRIM-Aktionen nicht zu häufig ausführen, regelmäßig Backups anfertigen und ein Ersatzgerät bereit halten. * -> [wikipedia_en:Trim_(computing)#Disadvantages:] Für Tests der Performance, auch bei SSDs, lese den Artikel [:Festplatten-Geschwindigkeitstest:]. {{{#!vorlage Warnung * TRIM erzeugt immer Datenverlust und sollte auf jeden Fall nur mit äußerster Vorsicht angewendet werden, damit der Datenverlust sich auf gelöschte Daten beschränkt. * Mit TRIM gelöschte Daten lassen sich auch mit forensischen Methoden nicht wieder rekonstruieren (ausgenommen vielleicht bei uralten Datenträgern der ersten Generation). * TRIM sollte auch nicht zu oft angewendet werden, da dieser Befehl den Datenträger altern lässt. }}} = TRIM durch das Betriebssystem = Seit [:Trusty:Ubuntu 14.04] wird automatisch wöchentlich für alle über die Datei '''/etc/fstab'''[4] eingebundenen Dateisysteme ein TRIM angestoßen. Der dafür ursprünglich vorgesehene [:Cron:Cronjob] wurde wieder entfernt, da heutzutage die Aufgabe von [:systemd:] über die [#fstrim-unit Units] '''fstrim.timer''' und '''fstrim.service''' erledigt wird. Der Zeitpunkt der letzten Ausführung von '''fstrim.service''' wird als letzte Änderung der Datei '''/var/lib/systemd/timers/stamp-fstrim.timer''' gespeichert. Der Anwender eines normalen Ubuntu-Desktop-Systems muss sich daher mit der Thematik TRIM meistens nicht beschäftigen. Sonderfälle wie [#Verschluesselung Verschlüsselung], [#Swap Swap] und Verwendung eines Dateisystems vom Typ [#Btrfs Btrfs] werden [#Sonderfaelle unten] angesprochen. Wer transportable bzw. über USB angeschlossene SSDs verwendet, findet Hinweise dazu im Abschnitt [#Externe-SSD Externe SSD]. = TRIM selbst verwalten = Wer mit der in Ubuntu eingebauten Lösung nicht auskommt, kann die [#Kernel-TRIM oben] beschriebenen Möglichkeiten per Kommandozeile, Skript, Cronjob oder Systemd-Unit einsetzen. Wer TRIM selbst verwalten möchte, sollte zunächst die mit dem Betriebssystem gelieferten Units '''fstrim.timer''' und '''fstrim.service''' stoppen und deren automatischen Start deaktivieren. == TRIM Strategien == Linux unterstützt TRIM durch den Aufruf einer internen Funktion Discard. Dies kann praktisch auf zwei unterschiedlichen Wegen erfolgen: * [#Batched-Discard "Batched Discard"], auch "periodic TRIM" – Der Befehl [#fstrim `fstrim`] 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 oder als periodisch ausführbare Aktion im System definiert werden. * [#Online-Discard "Online Discard"], auch "continuous TRIM" – Der Kernel informiert das Laufwerk sofort, wenn Speicherbereiche durch Löschen von Dateien frei werden. * Diese Funktion ist bei [:ext:ext4] von Haus aus deaktiviert und muss vom Anwender mit der Option `discard` eingeschaltet werden. * Bei [:Btrfs:] kann sie unter bestimmten Umständen automatisch aktiviert werden und sollte ggf. mit der Option `nodiscard` ausgeschaltet werden. -> [#Btrfs Btrfs unter Sonderfälle] {{{#!vorlage Tabelle <-3: rowclass="titel">Tabelle 1: Fähigkeit der Dateisysteme für Discard +++ Dateisystem Batched Discard Online Discard +++ [:ext#ext4:ext4][[BR]][:ext#ext2:ext2], [:ext#ext3:ext3] über Treiber ext4 ab Kernel 2.6.37 ab Kernel 2.6.33 +++ [:ext#ext2:ext2], [:ext#ext3:ext3] über Treiber ext3 ab Kernel 2.6.38 +++ [wikipedia:XFS_(Dateisystem):XFS] ab Kernel 2.6.38 ab Kernel 3.0 +++ [:Btrfs:] ab Kernel 2.6.39 ab Kernel 2.6.32 +++ [wikipedia:File_Allocation_Table:FAT] mit Modul `vfat` ab Kernel 4.19 ja +++ [:exFAT:] mit Modul `exfat` ab Kernel 5.13 ja +++ NTFS mit [:NTFS-3G:] ja nein +++ NTFS mit [:NTFS3:] nein ja +++ [:Swap:] ab Kernel 2.6.29 ab Kernel 2.6.29 }}} == fstrim == Das Programm `fstrim` für die Kommandozeile[1] stammt aus dem Paket '''util-linux''', welches bei jeder Installation von Ubuntu bereits mit installiert wird. Es kann mit Rootrechten[2] mit folgender allgemeiner Syntax aufgerufen werden: [[Vorlage(Befehl, "fstrim OPTIONen EINBINDEPUNKT" ) ]] Das Programm bearbeitet eingebundene Dateisysteme; diese können entweder über Optionen `-a, -A, -I` oder `-t` bzw. deren Langform identifiziert werden, oder es wird über den Parameter EINBINDEPUNKT eines explizit angegeben. Man kann in einer anderen (hier nicht besprochen) Betriebsart auch einen über die Optionen `-o`, `-l` und `-m` bzw. deren Langform beschrieben Bereich auf einem Datenträger bearbeiten lassen. Diese und die vorgenannte Betriebsart kann man vermischen. Lese hierzu Details in der [:Manpage:] von `fstrim`. {{{#!vorlage Tabelle <-3: rowclass="titel">Tabelle 2: Optionen für fstrim für die Anwendung auf Dateisystemen +++ Kurzform Langform Bedeutung +++ `-h` `--help` Hilfe mit Liste der Optionen und deren Kurzbeschreibung ausgeben. +++ `-V` `--version` Version des Programms anzeigen. +++ `-n` `--dry-run` Nichts wirklich ausführen, nur andeuten was passieren könnte. +++ `-a`[[BR]]`-I /proc/self/mountinfo` `--all` Alle zum Zeitpunkt des Aufrufs tatsächlich eingebundenen Dateisysteme bearbeiten. +++ `-A`[[BR]]`-I /etc/fstab` `--fstab` Alle in der Datei fstab[4] aufgeführten, tatsächlich eingebundenen Dateisysteme bearbeiten. +++ `-I LISTE` `--listet-in LISTE` LISTE ist eine Folge von durch `:` getrennten Dateinamen. Aus der Liste wird nur die erste nicht leere Datei berücksichtigt und alle in dieser Datei aufgeführten und tatsächlich eingebundenen Dateisysteme werden bearbeitet. +++ `-t TYPen` `--types TYPen` Ergänzt eine angegebene Option `-a` oder `-A`. TYPen ist eine mit Kommata getrennte Liste von Dateisystemtypen, wie sie auch [:mount:] verwendet. In der Liste ungenannte oder mit der Vorsilbe `no` ausgeschlossene Typen werden nicht bearbeitet. Wenn man diese Option nicht verwendet, wird nur der Typ `autofs` ausgeschlossen. +++ `-v` `--verbose` Erzeugt ausführlichere Ausgabe, insbesondere die Anzahl der getrimmten Bytes. +++ `--quiet-unsupported` Wenn das Dateisystem oder das Gerät TRIM nicht unterstützt, keine Meldung erzeugen. }}} == Batched Discard == Trimmen per "Batched Discard" ist sehr einfach. Es läuft hinaus auf einen Aufruf des Befehls [#fstrim `fstrim`]: * manuell in einem Terminal[1] mit RootRechten[2] * oder per Skript * oder periodisch per [:Cron:Cronjob] (nicht empfohlen) * oder periodisch per Systemd-Unit === Beispiel === Das folgende Beispiel setzt voraus, dass auf '''/home/''' tatsächlich ein eigenes Dateisystem eingebunden ist bzw. dass das ein Einbindepunkt und nicht nur ein Ordner ist: [[Vorlage(Befehl,"sudo fstrim -v /home" ) ]] Als Ausgabe erhält man mit der Option `-v` eine Ausgabe, wie viele Bytes getrimmt wurden: \\ {{{ /home: 1825476608 bytes were trimmed }}} In diesem Beispiel wurden ungefähr 1,825 GB getrimmt. Es ist nicht ganz klar, was das bedeuten soll. Schön wäre es, wenn hier gemeldet würde, wie viele Bytes wieder beschreibbar gemacht wurden. Das ist vermutlich eine zu optimistische Interpretation: Tatsächlich ist es wohl nur die Maximalzahl der möglicherweise befreiten Bytes und die Anzahl der wirklich wieder befreiten Bytes kann sehr viel kleiner sein, möglicherweise auch gar keines. === Beispiel Skript === Das Skript unter geeignetem Namen an geeigneter Stelle ablegen, als Eigentümer und Gruppe `root` setzen und ausführbar machen: {{{#!code bash # !/bin/bash { echo "*** $(date -R) ***" for MP in / /home # <-- Anpassen auf die eigenen Bedürfnisse do /sbin/fstrim -v "$MP" || echo Fehler beim trimmen von $MP done } | tee >>/var/log/batched_discard.log }}} Eine Ausgabe sieht dann z.B. so aus: {{{ *** Sun, 12 Oct 2014 12:51:07 +0200 *** /: 290,9 MiB (305029120 bytes) trimmed /home: 116,4 MiB (122036224 bytes) trimmed }}} Man kann es z.B. als Job für [:Cron:Anacron] ablegen. === Beispiel Systemd-Unit === [[Anker(fstrim-unit) ]]Beispiel für eine Systemd-Unit für `fstrim` (basierend auf der des Betriebssystems): {{{ # /etc/systemd/system/UU-fstrim.service [Unit] Description=Discard unused blocks on filesystems from /etc/fstab Documentation=man:fstrim(8) ConditionVirtualization=!container [Service] Type=oneshot ExecStart=/sbin/fstrim [mark]--listed-in /etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported[/mark] PrivateDevices=no PrivateNetwork=yes PrivateUsers=no ProtectKernelTunables=yes ProtectKernelModules=yes ProtectControlGroups=yes MemoryDenyWriteExecute=yes SystemCallFilter=@default @file-system @basic-io @system-service }}} Die markierten Optionen für den Aufruf von `fstrim` sind an die eigenen Bedürfnisse anzupassen. Da bei Ubuntu die Datei '''/etc/fstab'''[4] nicht leer ist, bleibt die Angabe weiterer Dateien wirkungslos. == Online Discard == Diese Methode ist zwar einfach zu konfigurieren, aber ihre richtige Anwendung ist dennoch sehr anspruchsvoll. Man benötigt umfangreiches Fachwissen, detaillierte Kenntnisse über die Implementierung im Linux Kernel und genaue Kenntnis der technischen Spezifikationen der verbauten SSD (Hardware) sowie deren Verhalten (Fehler in der Firmware). Dieser Abschnitt richtet sich an Experten und enthält keine vollständige Übersicht und erst recht keine für Laien taugliche Anleitung. {{{#!vorlage Experten Es gibt inzwischen mehrere Varianten für kontinuierliches Trimmen: 1. Die ursprüngliche Implementierung (später als "non-queued continuous trim" betzeichnet) war optimiert auf frühere Bauarten von SSDs ohne "wear leveling". SATA-Geräte vor Revision 3.1 unterstützen nur diese Variante, die im Betrieb einige unerwünschte Effekte produzieren kann. Die Spezifikation SATA Rev. 3.1 wurde im Juli 2011 veröffentlicht. Bis heute (2024) sind Controller nach dieser bzw. folgenden Revisionen selten. Externe Gehäuse mit USB/SATA-Wandler beherrschen in der Regel nur SATA Rev 3.0. 1. Bei der neueren Variante "queued continuous trim" werden TRIM-Anforderungen von der SSD gesammelt und als Batch ausgeführt. Dies reduziert die Häufigkeit des während der Ausführung von TRIM erfolgenden Einfrieren des Systems. Die Variante „Ausführung von "queued continuous trim" durch die SSD“ erfordert eine SSD nach hinreichend neuer SATA Revision (zunehmend erfüllt) und ebenso beim SATA-Controller (bei externen Geräten immer noch selten). * Für manche SSDs ist dieser Modus im Linux Kernel gesperrt wegen ernsthafter Korruption von Daten. \\ -> Folgende Tabelle 3 und [wikipedia_en:Trim_(computing)#Disadvantages:] * Manche [:Administrator:Administratoren] misstrauen nach schlechten Erfahrungen aus der Anfangszeit der Methode „Ausführung von "queued continuous trim" durch die SSD“ grundsätzlich dieser Methode und sperren deshalb im Kernel deren technische Grundlage [wikipedia:Native_Command_Queuing:] (NCQ) beim Start des Kernels über eine [:Bootoption:]: * `libata.force=noncq` (NCQ komplett abschalten) oder * `libata.force=noncqtrim` (NCQ für TRIM abschalten) 1. Bei der Variante „Ausführung von "queued continuous trim" durch den Dateisystemtreiber“ simuliert der Dateisystemtreiber die vorstehende Arbeitsweise. Er sammelt selbst die TRIM-Anforderungen und sendet diese als "non-queued"-TRIM-Anforderungen. }}} Manche SSDs sind bekannt für ihre fehlerhafte Implementierung mancher ATA-Befehle im Kontext TRIM und deshalb im Linux Kernel (genauer in der libata) für bestimmte Betriebsweisen gesperrt. Eine fehlende Mitgliedschaft in dieser schwarzen Liste ist natürlich keine Garantie für fehlerfreie Funktion, sondern bedeutet nur fehlende Erkenntnisse über das betreffende Gerät. {{{#!vorlage Tabelle <-4: rowclass="titel">Tabelle 3: SSDs mit Beschränkungen bei Online Discard +++ Hersteller Modell Firmware +++ <|2>Micron/Crucial M500 alle <|5>"queued continuous trim" gesperrt. +++ M550 MU01 +++ Micron M510 MU01 +++ Crucial MX100 MU01 +++ Samsung 840[[BR]]850 alle +++ SuperSSpeed S238 alle TRIM generell gesperrt: Löscht falsche Blöcke, somit Datenverlust. }}} {{{#!vorlage hinweis Für SSDs der ersten Baureihen fanden sich Berichte, wodurch die per „Online Discard“ entstehenden TRIM-Befehle die Performance der SSD reduzieren oder diese unbenutzbar machen ''könnten''. Bei aktuellen SSDs ist dieses Problem nicht bekannt. Dennoch ist "Online Discard" aggressiver als "Batchd Discard", lässt somit die SSD schneller altern und sollte daher nur in den Fällen eingesetzt werde, wenn "Batched Discard" keine befriedigenden Ergebnisse liefert. }}} Zur Nutzung von "Online Discard" muss man beim Einbinden die (bzw. abhängig von Dateisystemtyp eine verwandte) Option `discard` verwenden. Mit einer solchen Option fordert der Dateisystemtreiber fortlaufend TRIM von der SSD an, sobald im Dateisystem Speicherbereiche frei werden. Die Details kann man in der Dokumentation des jeweiligen Dateisystems nachlesen. Siehe auch die folgenden Abschnitte für [#ext4 ext4], [#Btrfs Btrfs] und [#Swap Swap]. = Sonderfälle = == Swap == Auslagerungsspeicher ([:Swap:]) für die virtuelle Speicherverwaltung kann dem System per Datei oder Partition bereit gestellt werden. TRIM auf Swap-Partitionen ist optional und muss vom Anwender beim Programm [:Swap#Swap-leeren:Swapon] mit der Option `-d` oder über '''/etc/fstab'''[4] mit einer Option `discard` aktiviert werden. * Eine Auslagerungsdatei ist Teil des unter '''/''' eingebundenen Root-Dateisystems und wird daher vom [#Batches-Discard "Batched Discard] oder [#Online-Discard "Online Discard"] von '''/''' mit berücksichtigt. * Ein Swap-Partition hat aber auch im Gebrauch keinen Einbindepunkt und wird daher standardmäßig von der Unit '''fstrim.service''' per "Batched Discard" __nicht__ bearbeitet. * Man kann Swap per "Batched Discard" mit einem solchen Aufruf trimmen: [[Vorlage(Befehl, "fstrim -v -I /proc/swaps" ) ]] * Es ist optional möglich, "Online Discard" zu verwenden; hierzu muss man in der Datei fstab[4] eine Option `discard` nach Tabelle 4 angeben. {{{#!vorlage Tabelle <-2: rowclass="titel">Tabelle 4: Optionen für Online Discard bei Swap +++ Option Bedeutung +++ `discard=once` Bei der Ausführung von `swapon` erfolgt einmalig ein TRIM/Discard für die gesamte Partition. Empfohlen. +++ `discard=pages` Im laufenden Betrieb frei werdende Speicherbereiche werden sofort an das Gerät gemeldet, damit dieses TRIM ausführen kann. +++ `discard` Beide vorstehend genannten Methoden werden aktiviert. +++ Vorgabe: Ohne Angabe einer Option `discard` wird "Online Discard" nicht aktiviert. }}} Ob ein Trimmen der Swap-Bereiche überhaupt sinnvoll ist, hängt von der konkreten Hardware der SSD ab. Die Manpage von `swapon` führt dazu aus: > This (discard or trim) may improve performance on some Solid State Devices, but often it does not. == Ext4 == Bei einem Dateisystem [:ext:ext4] kann man [#Online-Discard "Online Discard"] über 2 unterschiedliche Methoden aktivieren: 1. Man gibt die Option `discard` beim Einbinden [#sda der Quelle] an, z.B. in der Datei [:fstab:]: \\ {{{/dev/sda99 / ext4 errors=remount-ro,noatime,discard 0 1 }}} Die Option `noatime` ist hier nicht erforderlich für `discard`, minimiert aber generell Schreibvorgänge und damit die Erfordernis für TRIM. In der Praxis sollte man statt einem unzuverlässigen temporären Bezeichner wie `sda99` besser einen permanenten wie z.B. eine [:UUID:] verwenden. 1. Man konfiguriert die Option `discard` als Standardoption im Superblock des Dateisystems auf [#sda der Quelle]: [[Vorlage(Befehl, "sudo tune2fs -o discard /dev/sda99" ) ]] Beachte: [#Sollte-ich-Online-Discard-verwenden Sollte ich Online Discard verwenden?] == Btrfs == Das Dateisystem [:Btrfs:] benutzt im Gegensatz zu [:ext:ext4] [wikipedia:Copy-On-Write:] und verschärft damit die TRIM-Problematik, denn das unterlagerte Gerät kann nun __nicht__ mehr erkennen, dass von Anwenderseite ein Überschreiben vorhandener Daten beabsichtigt ist und dies ggf. durch selbst ausgelöste TRIM-Aktionen nachvollziehen. (Der Umstand, dass die SSD ein beabsichtigtes Überschreiben erkennen könnte, bedeutet aber nicht, dass jede SSD das auch macht und schon gar nicht, dass sie selbst TRIM auslösen würde!) ##Setzt man '''btrfs''' als [:Dateisystem:] ein, so ist das Journaling nicht so umfangreich wie beim Dateisystem [:ext:], da '''btrfs''' nur [wikipedia:Metadaten:] speichert. Metadaten-Journaling garantiert lediglich die Konsistenz des Dateisystems, wohingegen beim Full-Journaling ('''ext3'''/'''ext4''') auch die Konsistenz der Dateiinhalte gewährleistet wird. (siehe [wikipedia:Journaling-Dateisystem:]). Die beim Dateisystemtyp `btrfs` für TRIM relevanten Optionen listet folgende Tabelle 5. Details zu den Optionen lese im Artikel „Mountoptionen BTRFS“. ## [:Mountoptionen BTRFS:] {{{#!vorlage Tabelle <-3: rowclass="titel">Tabelle 5: Wichtige Optionen für Online Discard bei Btrfs +++ Option Bedeutung Kernel +++ `ssd`[[BR]]`nossd` Der Modul `btrfs` des Linux Kernels setzt automatisch die Option `ssd` für nicht rotierende bzw. die Option `nossd` für rotierende Datenträger. Die Automatik wird durch explizites Setzen einer dieser Optionen abgeschaltet. Keine Auswirkungen bzgl. "Online Discard". +++ <|2>`ssd` Aktiviert für SSDs nützliche Heuristiken und Optimierungen. vor 6.2 +++ Aktiviert für SSDs nützliche Heuristiken, aber nicht mehr die früher benutzten Optimierungen. ab 6.2 +++ `nossd` Impliziert `no_ssd_spread`. Schaltet Heuristiken und alle Optimierungen für SSD ab. +++ `ssd_spread` Impliziert die Option `ssd`, aktiviert die früher per `ssd` benutzten und weitere Optimierungen. +++ `nossd_spread` Schaltet die neuen Optimierungen für SSD aus. +++ `discard=sync` "Online Discard" verwenden, aber die Variante "queued continuous trim" sperren. +++ `discard`[[BR]]`discard=async` "Online Discard" grundsätzlich und bevorzugt in der Variante "queued continuous trim" verwenden. TRIM-Anforderungen werden nicht sofort übermittelt, sondern gesammelt. Diese Betriebsart ist nur bei neueren SSDs möglich und erfordert einen SATA-Controler mit Revision 3.1. Vorgabe ab Kernel Version 6.2. [[BR]] Die frühere Option `discard` hat ihre Bedeutung verändert: Während sie früher ein Synonym für `discard=sync` war, bedeutet sie ab Kernel 6.2 nun `discard=async`. ab 5.6[[BR]]'''ab 6.2''' +++ `nodiscard` "Online Discard" nicht verwenden. Empfohlen. }}} Dank mit der Version des Kernels wechselnder Vorgaben und Automatiken ist die Situation unübersichtlich. Es ist schwer herauszufinden, welche Optionen im eigenen System konkret gelten und diese müssen auch nicht für die konkret verbaute SSD optimal sein. Man sollte daher bei Btrfs grundsätzlich immer die relevanten Optionen selbst explizit vorgeben. Ein vernünftiger Ausgangspunkt für individuelle Optimierungen ist eine solche Zeile für [#sda die Quelle] in [:fstab:]: {{{/dev/sda99 / btrfs noatime,ssd,nodiscard 0 1 }}} In der Praxis sollte man statt einem unzuverlässigen temporären Bezeichner wie `sda99` besser einen permanenten wie z.B. eine [:UUID:] verwenden. == Verschlüsselung == {{{#!vorlage Hinweis Wird TRIM auf einer verschlüsselten SSD benutzt, können für einen Angreifer nützliche Informationen "geleakt" werden. Dabei werden zunächst keine verschlüsselten Inhalte sichtbar, aber der Angreifer kann bei manchen SSDs erkennen, welche Speicherblöcke leer sind und welche Daten enthalten. Das Problem tritt bei allen SSDs auf, die beim Lesen eines leeren Speicherblocks etwas anderes als deterministische Zufallsdaten liefern. Damit sind die im Artikel [:SSD/TRIM/Testen/#Testen-des-TRIM-der-SSD:] genannten Typen 2 und 3 angreifbar. * -> [:SSD/Verschlüsselung/#Komplettverschluesselung-mit-TRIM:] * Siehe [https://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html diesen englischen Artikel] {en} für Details. Viele Anwender bewerten diese abstrakte Gefahr als tolerabel, dennoch haben die Entwickler von dm-crypt und LUKS genau deshalb discard/TRIM nicht per Vorgabe aktiviert. }}} Damit ein „Batched Discard“ oder „Online Discard“ auf einer mit dm_crypt ([:LUKS:]) verschlüsselten SSD funktioniert, muss man den Device Mapper anweisen, empfangene TRIM-Anforderungen an die Hardware weiterzugeben. Die Umsetzung dieser Anforderung unterscheidet sich etwas, je nachdem ob es sich bei dem betroffenen Dateisystem * um das Root-Dateisystem, * oder ein Dateisystem für Anwenderdaten auf einer internen SSD, * oder um eine [#Externe-SSD externe SSD] handelt. === Verschlüsselte Anwenderdaten === Man wähle eine aus den folgenden Methoden: 1. Wenn man LUKS Version 2 verwendet, kann man die Option `discard` im LUKS-Header des virtuellen Gerätes [#sda `SDA99`] speichern. Dazu muss man einmalig diesen Befehl benutzen: [[Vorlage(Befehl, "sudo cryptsetup --allow-discards --persistent refresh SDA99" ) ]] 1. Bei LUKS Version 1 funktioniert vorstehender Befehl so nicht, weil man im Header keinen Platz zur Speicherung der Option hat und das Programm dann auch die Option `--permanent` gar nicht kennt. Man kann aber den abgewandelten Befehl [[Vorlage(Befehl, "sudo cryptsetup --allow-discards refresh SDA99" ) ]] jedesmal beim Begin der Nutzung verwenden. 1. Immer funktioniert ein Eintrag in der Datei '''/etc/crypttab'''. Man bearbeitet einmalig die Datei[2] mit Rootrechten[3] und fügt in der Zeile des virtuellen Gerätes [#sda `SDA99`] die Option `discard` (im folgenden Beispiel gelb markiert) mit ein. {{{SDA99 /dev/sda99 none luks[mark],discard[/mark] }}} === Verschlüsselte Systemdaten === ## [:System_verschlüsseln/Schlüsselableitung:Schlüsselableitung voll verschlüsselt] Bei einem verschlüsselten Root-Dateisystem muss man vorstehende Aufgabe ebenfalls erledigen; dafür gibt es aber noch als Alternative eine Anpassung in der Datei '''/etc/initramfs-tools/conf.d/cryptroot''': {{{ target=SDA99,source=/dev/sda99[mark],discard[/mark],[...] }}} Danach ist noch das [wikipedia:initramfs:] zu aktualisieren: [[Vorlage(Befehl,"sudo update-initramfs -u -k all" ) ]] === Test === Nach dem Neustart kann mit [[Vorlage(Befehl, "sudo dmsetup table /dev/mapper/SDA99" ) ]] überprüft werden ob die Option `discard` aktiv ist. Beispielausgabe: {{{ 0 975718448 crypt aes-xts-plain64 00000000 0 8:99 4096 1 [mark]allow_discards[/mark] }}} Falls am Ende `allow_discards` steht, ist alles ok. = Problemlösungen = == Ist TRIM erforderlich? == Antwort: Nein und ja. * Nein: Im produktiv laufenden System ist TRIM nicht erforderlich, aber sinnvoll. Wenn man es abschaltet, werden sich auf der SSD Leichenteile von gelöschten oder geänderten Dateien ansammeln und den freien Speicherplatz reduzieren. Solange es auf der SSD noch hinreichend viele unbenutzte Speicherblöcke gibt, wird man davon gar nichts bemerken und auch die Schreibgeschwindigkeit wird nicht beeinträchtigt. Man hat sogar den Vorteil, dass man kein Einfrieren des Systems während der Ausführung von TRIM ertragen muss. * Ja: Irgendwann wird man in einem System mit deaktiviertem TRIM den Zustand erreichen, dass die unbenutzen Speicherbereiche auf der SSD knapp werden. Dann erst wird sich die Schreibgeschwindigkeit verringern und schließlich wird es unmöglich, neue Dateien zu speichern, obwohl aus Sicht des Dateisystems genügend Speicherplatz frei ist. Jetzt spätestens muss man das System aus dem produktiven Betrieb nehmen, ein Wartungssystem booten und die aufgesparten TRIM nachholen – das kann fallweise durchaus eine sinnvolle Strategie sein. Wenn man im laufenden System auf TRIM verzichtet, sollte man den möglichen Speicherplatz auf der SSD nicht vollständig ausnutzen, sondern bewusst ca. 10% frei lassen. Dies kann man auf mehreren Wegen erreichen: * Man vergrößert die "spare area", einen Speicherbereich, der im normalen Betrieb nicht sichtbar ist und exklusiv der Firmware der SSD zu Verfügung steht. Dies ist nur bei manchen SSDs möglich. * Man partitioniert den Datenträger und lässt dabei einen Bereich einfach frei. * Man partitioniert den Datenträger und legt dabei eine Partition an, die man nicht formatiert. Man kann optional zur Dokumentation der Partition ein Label wie z.B. "`Overprovision: DO NOT USE THIS!`" geben. Overprovision kann helfen, den produktiven Betrieb aufrecht zu erhalten, aber nicht endlos. Irgendwann benötigt man den Wartungslauf. [[Anker(TRIM-testen) ]] == Unterstützt mein Gerät TRIM? == Die definitive Antwort findet man in den technischen Spezifikationen zur betreffenden Hardware. Oft reicht aber auch eine Abfrage aus dem laufenden System mit [:lsblk:]: [[Vorlage(Befehl, "lsblk -dD -le7 -o+MODEL,REV" ) ]] Beispielausgabe: {{{ NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO MODEL REV sda 0 4K 0B 0 HGST HTS725032A7E635 OPAL GHB6B8Y0 sdb 0 512B 2G 0 TS512GMTS430S 2202U17A sdc 0 512B 0B 0 Samsung SSD 850 EVO 250GB EMT02B6Q }}} Relevant sind die Zahlen für `DISC-MAX`, welche die maximale Größe eines mit TRIM zu verwerfenden Bereiches angeben. Im Beispiel bedeuten bei `sda` und `sdc` die Maximalgrößen 0, dass TRIM nicht unterstützt wird. Das mag im Falle der Samsung 850 EVO überraschen, denn diese Hardware unterstützt lt. Spezifikation des Herstellers ausdrücklich TRIM, allerdings ist – was in der Ausgabe nicht erkennbar ist – die SSD in ein Gehäuse mit USB/SATA-Wandler eingebaut, der offenbar TRIM-Befehle blockiert, und das ist leider bei diesen Gehäusen oft so. Wenn wie im Beispiel bei `sdb` unter `DISC-MAX` keine 0 steht, dann ist noch die Angabe für `DISC-GRAN` auch im Kontext TRIM relevant. Diese Zahl entspricht der kleinsten Speichermenge, welche das Gerät löschen kann. Die auf Ebene des Dateisystems verwendete Blockgröße sollte ein ganzzahliges Vielfaches von `DISC-GRAN` sein. Ein weiterer schneller Test benutzt [:hdparm:]: [[Vorlage(Befehl, "sudo hdparm -I /dev/sd? | grep -e TRIM -e Model" ) ]] Beispielausgabe: {{{ Model Number: HGST HTS725032A7E635 OPAL Model Number: TS512GMTS430S * Data Set Management TRIM supported (limit 8 blocks) * Deterministic read ZEROs after TRIM Model Number: Samsung SSD 850 EVO 250GB * Data Set Management TRIM supported (limit 8 blocks) }}} Hier wird jetzt die Samsung 850 EVO richtig beurteilt, aber das hilft leider nicht, wenn der zwischengeschaltete USB/SATA-Konverter nicht mitspielt. Siehe auch Artikel [:SSD/TRIM/Testen:]. == Wird Batched Discard gestartet? == Dazu fragt man ab, ob der zuständige Timer läuft: [[Vorlage(Befehl, "systemctl list-timers '*trim*'" ) ]] Beispielausgabe: {{{ NEXT LEFT LAST PASSED UNIT ACTIVATES Mon 2024-10-28 00:17:36 CET 6 days Mon 2024-10-21 07:36:43 CEST 47min ago fstrim.timer fstrim.service }}} == Arbeitet Batched Discard auch richtig? == Hierzu fragt man aus dem Systemlog die Meldungen ab: [[Vorlage(Befehl, "journalctl -u fstrim.service" ) ]] Beispielausgabe 1: {{{ Okt 07 09:53:26 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab... Okt 07 09:53:26 Maria systemd[1]: fstrim.service: Deactivated successfully. Okt 07 09:53:26 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab. -- Boot 70c2d21dffad4e9a969b0105b386d780 -- Okt 14 07:12:42 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab... Okt 14 07:12:43 Maria systemd[1]: fstrim.service: Deactivated successfully. Okt 14 07:12:43 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab. -- Boot e2303c96212f49dcbdf799d0a5e9de4f -- Okt 21 07:36:43 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab... Okt 21 07:36:43 Maria systemd[1]: fstrim.service: Deactivated successfully. Okt 21 07:36:43 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab. }}} Im Beispiel wird die Unit '''fstrim.service''' wie erwartet wöchentlich gestartet und läuft auch fehlerfrei, macht aber gar nichts – was [#TRIM-testen daran] liegt, dass die in diesem System verbauten Geräte TRIM nicht beherrschen. Beispielausgabe 2: {{{ Okt 28 06:44:16 Maria systemd[1]: Starting fstrim.service - Discard unused blocks on filesystems from /etc/fstab... Okt 28 06:44:20 Maria fstrim[37403]: /mnt/Daten-A: 27,1 GiB (29050531840 Bytes) auf /dev/sdb10 getrimmt Okt 28 06:44:20 Maria fstrim[37403]: /: 6,7 GiB (7185223680 Bytes) auf /dev/sdb3 getrimmt Okt 28 06:44:20 Maria systemd[1]: fstrim.service: Deactivated successfully. Okt 28 06:44:20 Maria systemd[1]: Finished fstrim.service - Discard unused blocks on filesystems from /etc/fstab. }}} Hier wurden nun Bereiche mit veralteten Daten in Summe von 33,8 GiB bereinigt und können wieder belegt werden. == Sollte ich Batched Discard verwenden? == In den meisten Fällen: Ja. Allerdings bearbeitet die bereits im Betriebssystem eingebaute Unit in der Regel nur Dateisysteme auf internen Datenträgern mit Einträgen in der Datei fstab[4]. In der Praxis muss man ggf. selbst optimieren: * Ausführungszeit genauer festlegen auf Zeiträume, in denen mit hoher Wahrscheinlichkeit der Rechner läuft, aber nur wenig genutzt wird. * Die nur temporär angeschlossenen Geräte wie beispielsweise USB-SSDs einbeziehen. -> [#Externe-SSD Externe SSD] == Sollte ich Online Discard verwenden? == In den meisten Fällen: Nein, außer man ist Experte und "Batched Discard" liefert unbefriedigende Resultate. Bei Dateisystemen vom Typ [#Btrfs Btrfs] sollte man überlegen, ob man das standardmäßig eingeschaltete `discard` nicht lieber ausschalten möchte, bei [#ext4 ext4] ist es nicht aktiviert. == Externe SSD == Externe Geräte wie beispielsweise USB-SSDs, die wechselweise an mehrere Rechner oder nur temporär angeschlossen werden, werden nicht automatisch getrimmt, da ihnen in der Regel kein Einbindepunkt über die Datei '''fstab''' zugewiesen wird. Man kann sie natürlich in diese Datei aufnehmen, muss aber berücksichtigen, dass automatisches TRIM über die Systemd-Unit nur dann erfolgt, wenn sie zum Zeitpumkt des Laufs tatsächlich angeschlossen und eingebunden sind. Auf jeden Fall sollte man sich ein Konzept überlegen, wie man derartige Geräte behandeln möchte. Grundsätzlich funktionieren natürlich auch bei externen Geräten alle vorgestellten Methoden, aber man muss selber über deren für die eigenen Bedürfnisse zweckmäßige Aktivierung nachdenken und das eigene Konzept umsetzen. Beispiel für ein solches Konzept: * Man kauft eine SSD und ein Gehäuse; beide Komponenten dürfen kein Problem mit [#Online-Discard "Online Discard"] machen. * Man verwendet LUKS Version 2 für die Verschlüsselung. * Man formatiert [#sda das virtuelle Blockgerät `SDA99`] mit dem Dateisystem [:ext:ext4]. * Man definiert die Option `discard` als Standardversion für dieses Dateisystem, wie [#Ext4 oben] als zweite Methode beschrieben. Damit erspart man sich Eingriffe die Datei '''/etc/fstab'''[4] auf allen Systemen, an die man diese tranportable SSD anschließen will. * Man speichert die Option `allow_discards` permanent im LUKS2-Header. Dazu mun man die SSD nur ein einziges Mal nach manuellem Aufschließen und Einbinden neu konfigurieren: [[Vorlage(Befehl, "sudo cryptsetup --allow-discards --persistent refresh SDA99" ) ]] Nach dieser einmaligen Vorbereitung muss man zukünftig nur noch die Passphrase eingeben und kann für dieses Gerät das Thema TRIM vergessen. (Siehe: [https://www.guyrutenberg.com/2021/11/23/enable-trim-on-external-luks-encrypted-drive/ Enable TRIM on external LUKS encrypted drive] {en}) = Links = * [wikipedia_en:Trim_(computing):] – Grundlagenartikel in der englischen Wikipedia * [http://www.thomas-krenn.com/de/wiki/SSD_Performance_optimieren#Standardkonfiguration_ohne_ATA_TRIM SSD Performance optimieren] {de} im Wiki von Thomas Krenn ## - [wikipedia:Serial_ATA:] ## * [http://www.anandtech.com/show/2738/10 AnandTech.com: The Trim Command: Coming Soon to a Drive Near You] {en} ## * [http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#Kernel_realtime_discard_support opensuse.org: Kernel realtime discard support] {en} ## Projekt hdparm/wiper.sh: ## * [sourceforge:hdparm:] ## * [http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support#How_Often_should_I_run_wiper.sh opensuse.org: How Often should I run wiper.sh ] {en} ## * [https://btrfs.wiki.kernel.org/index.php/FAQ#Is_Btrfs_optimized_for_SSD.3F btrfs und SSD] {en} #tag: Hardware, System