Erschrocken musste ich feststellen, das meine Festplatte im Tablet PC so langsam den Geist aufgibt. Aufgefallen war es beim kopieren einer größeren Datei, die massiv Lesefehler verursachte. Ach ja, am Sonntag früh hatte das booten länger als das Frühstück gedauert... Das ist natürlich kein Zustand, deshalb musste eine SSD (Solid State Disc) her. Wenn mann keine allzu große Speichermengen benötigt, sind sie mittlerweile durchaus erschwinglich.
Ich habe mich für die ADATA S599 entschieden. Die Platte bekommt man mit 64GB für m die 100.- €
Allerdings gibt es bei den SSD so einiges beachten, schließlich sind SSD im Grunde genommen nur Flash Speicher, die sind nun mal nicht für unendlich viele Schreibvorgänge konzipiert.
Da wäre z.B. welches Dateisystem kann und sollte man verwenden, welche Optionen sind sinnvoll. Welche Bereiche gehören nach Möglichkeit nicht auf die SSD? Sollte man die SSD beim Partitionieren ausreizen, oder sollte man einen Bereich unpartioniert lassen? Welche Wear Leveling Technologie verwendet der Plattencontroller innerhalb der SSD?
Ich fange mal von hinten an.
Was ist überhaupt Wear Leveling?
Die geschriebenen Blöcke können in zwei Kategorien eingeteilt werden. zum Einen sind das Dateien, die sich selten oder nie ändern. Zum Beispiel Bilder, Filme oder Dateien vom Betriebssystem. Diese Blöcke, (für den Controller gibt es nur zu schreibene Blöcke, einzelne Bytes existieren in dieser Betrachtung nicht) werden geschrieben und liegen dann ewig im Speicher herum. Der interne Schreibcounter steht für diesen Block also für lange Zeit auf 1. Zum Anderen gibt es die Dateien, die sich häufig ändern, das sind zum Beispiel Textfiles, Logfiles, oder auch Status- Dateien usw. Diese Dateien, - besser die Blöcke, in denen diese Dateien residieren-, werden vom Controller anders behandelt. Wenn sich ein Block zum wiederholten Mal geändert hat, dann schreibt der Controller diesen geänderten Block an einen anderen Platz in der SSD auf einen Platz, der noch nie beschrieben worden ist. Das Ganze merkt sich der SSD-Controller in einer internen Äbersetzungstabelle. Er würde, wenn man explizit diesen Block anfordert, z.B. mit einen dd Kommonado behaupten er liefere den Block von der Stelle, an der er zum allerersten Mal geschrieben worden ist, durch seine Tabelle liefert er natürlich aber den tatsächlichen Block, der physikalisch an einem ganz anderen Ort liegen kann.
Diese Mimik nennt der Hersteller Wear Leveling. Innerhalb dieser Strategie gibt es mehrere Varianten, schließlich haben unterschiedliche Firmen unterschiedliche Strategien. Der Controller sorgt also dadurch dafür, das die Blöcke gleichmäßig beschrieben werden und somit gleichzeitig altern. Jeder Block, der vom Betriebssystem jemals beschrieben wurde, gilt als belegt und der interne Schreibcounter geht um eins hoch.
Wenn man nun aber von vorn herein einen Bereich unpartitioniert gelassen hat, dann ist dieser Blockbereich für diesen Wear Leveling Mechanismus verfügbar und es dauert entsprechend lange, bis der Controller Blöcke benutzt, die bereits mehrfach beschrieben worden. Man verzögert also durch diese Maßnahme, den Zeitpunkt, an denen jeder Block eine gewisse Schreibzyklenanzahl überschritten hat. Die Flashzellen haben nämlich die unangenehme Eigenschaft, mit dem zunehmenden Schreibzyklen immer langsamer zu werden, sie altern.
Das beschreiben eines Blockes vom Betriebssystem hält der SSD Controller zwar fest, er kann jedoch nicht wissen, ob und wann dieser Block wieder freigegeben wurde. Denn die üblichen Filesysteme markieren Dateien, die nicht mehr benötigt werden nur als gelöscht, zwar auf gänzlich verschiedene Arten, aber es wird eben nicht der Block auf der Platte gelöscht.
Nun gibt es den neuen ATA Befehl TRIM. Der wird vom Linux Kernel ab 2.6.33 unterstützt. Bei Debian Kerneln ist auch der Kernel ab 2.6.32.5 gepatchet und kennt fortan den Befehl.E
Wenn jetzt das verwendete Filesystem bei löschen einer Datei das Kommando TRIM zum SD Controller sendet, kann der Controller ggfs. den betroffenen Block als wieder freigegeben markieren und im späteren Verlauf erneut allokieren.
Die Größe des Blockes, der einem Rutsch auf die SSD geschrieben wird ist vom Controller abhängig. Äblich sind 32K, wieviel es nun tatsächlich sind, steht nicht im Datenblatt und kann nur mit Benchmarks benchmarkreviews.com ausbaldovert werden.
Womit der nächste Punkt,
die Wahl des Dateisystems
eigentlich auch schon geklärt ist. Ext4 wird seit ein paar Kernelversionen als stabil bezeichnet und bietet explizit die SSd Unterstüzung in Zusammenhang mit TRIM und Block layer discard requests.
Sollte man die SSD beim Partitionieren ausreizen, oder sollte man einen Bereich unpartioniert lassen?
Um es kurz zu machen. Lässt man einen bestimmten Bereich unpartitioniert, dann kann sich das Betriebssystem auf den Kopf stellen, es wird nie diesen Bereich der SSD beschreiben können, sieht man vom mutwilligen Beschreiben auf das Raw Device mit dd einmal ab. Der Umkehr Schluss lautet also, dieser Bereich wird vorrangig vom SSD Controller für das Wear Leveling benutzt werden. Meine SSD hat nun 64 GB, Es kursieren Empfehlungen einen Bereich von 10-20% unpartitioniert zu lassen. Nun ich werde 14GB liegen lassen. Der Grund dafür ist noch einmal etwas weiter unten erläutert.
Vollverschlüsselung der SSD
Ich weiß selber nicht, ob ich mir da selber ein Ei lege. Der C'T Artikel SSD-verschlüsseln und auch hardwareluxx a-data-s599-was-kann-der-sandforce-controller erwähnen explizit die Sandforce Controller. Die haben nämlich eine sehr hohe Schreibrate, die vornehmlich durch Datenkompression erreicht wird. Verschlüsselte Daten sind aber nicht komprimierbar. Deshalb partitioniere ich nur 50GB der 64 GB Gesamtkapazität.
Weiterhin stellt sich die Frage, ob ich das bei der Erstellung der verschlüsselten Volumegroup durchgeführte beschreiben mit Zufallswerten nicht lieber abbrechen sollte, um so eine geringere Belastung zu erreichen. Ein brauchbarer Kompromiss wäre, das ich nur die /home Partition verschlüssele und das System ansonsten unverschlüsselt lasse.
Hier fehlt einfach die Erfahrung, vielleicht mache ich im ersten Schritt nur die Minimal Lösung mit verschlüsselter Home Partition.
Welche Bereiche gehören nicht auf einen ssd?
Das Runlevel System von Debian (andere Derivate und SysV kompatible natürlich auch) bieten die Möglichkeit in /etc/default/rcS diverse Einstellungen vorzunehmen.
Zwei interessante Möglichkeiten sind
RAMRUN=no RAMLOCK=no
Die stehen per default auf no. RAMRUN betrifft die Dateien unter /var/run/ Dort sind nun nicht unbedingt viele Dateien gespeichert, allerdings sind es alles sehr kleine Dateien, die doch relativ oft upgedatet werden, damit sind sie prädestiniert für ein Filesystem im RAM.
Die selben Argumente treffen auf RAMLOCK zu. Da handelt es sich um Dateien, die unter /var/lock/ gespeichert sind.
Ändert man die Parameter auf yes, werden vom nächsten Reboot an die beiden Verzeichnisse im RAM mittels tmpfs gehalten. Beide Verzeichnisse enthalten.
das Verzeichnis /tmp ist der Namensgeber für tmpfs, so nimmt es nicht Wunder, das man /tmp auch in der /etc/fstab zum tmpfs Filesystem erklären kann und damit seinem System u.U. erhebliche Writes ersparen kann.
Der folgende Eintrag in der /etc/fstab bewerkstelligt dies:
tmpfs /tmp tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0
Ein weitere Kandidat für die Auslagerung ins RAM ist /var/log
Nur ist es hier nicht mehr ganz so eindeutig, hat man seine Daemonen auf geschätzig gestellt, dann erntet man als Dank auch eine ständig wachsende Logdatei, z.B. messages. Hat man einen Webserver installiert, erübrigt sich die weitere Betrachtung, denn die sind immer geschwätzig.
Wenn man /var/log wirklich auslagern möchte, benötigt man also entsprechend reichlich RAM. Da muss ein Jeder für sich abwägen, was einem wichtiger ist...
tmpfs /var/log tmpfs defaults,noatime,nodev,nosuid,mode=1777 0 0
wäre demnach der korrekte Eintrag in der /etc/fstab, wenn man sich dafür entscheidet.
Man sollte aber bedenken, das damit Fehlersituationen nicht mehr so leicht zu lokalisieren sind, denn nach einem reboot sind die Logs weg. Man solte dann ggfs. den Eintrag zur Fehlersuche auskommentieren.
Bleibt noch
/swap.
Auf SSD oder im Ram was u.U. durchaus Sinn macht, betrachtet man CompCache bzw. zram oder evtl. ganz darauf verzichten?
Unbedingte Voraussetzung ist swap nur, wenn man nicht genug RAM zur Verfügung hat, oder wenn man suspend to Disk nutzen möchte. Man könnte auch ein File als Swapfile anlegen, die Priorität entsprechend niedrig ansetzen, so das es so gut wie nie, oder eben nur im Notfall benutzt wird.
Oder man definiert eine kleine swap Partition, die man auch mittels "swapiness" so schlecht beurteilt, das sie praktisch nie genutzt wird. Das ist eine Entscheidung, die nicht leicht zu fällen ist, will man ab- und zu auch mal Panorama Aufnahmen erzeugen und bearbeiten, sind 2GB Arbeitspeicher nicht zu reichlich bemessen. Da sollte man schon swap Space vorsehen.
Für die derzeit üblichen Games sind 2GB ausreichend. Auf meinem Tablet PC allemal, weil da eh nur eine integrierte Graphic vorhanden ist und Blockbuster wie Enemy Territory eh nicht in Frage kommen.
Da ich auf jeden Fall wieder ein vollverschlüsseltes System mit Volumegroup aufsetzen werde, ist es nicht so entscheidend, denn ich kann es im nach hinein jederzeit wieder ohne Probleme ändern.
Wer also Swap eingerichtet hat, sollte die Verwendung minimieren. das kann man dauerhaft in der /etc/sysctl.conf einstellen.
Der Parameter vm.swappiness steht nach der default Installation auf 60.
Damit neigt der Kernel eher dazu Swap zu nutzen. Weil die ssd eigentlich schnell ist, ist das auch gar nicht so schlecht, nur wird die Hardware schneller altern.
Ich stelle einen Wert von 10 ein, damit beginnt der Kernel erst Prozesse oder Teile davon auszulagern, wenn alle Reserven bis auf einen kleinen Rest erschöpft sind.
Browser Cache.
Einer der meistgenutzten Anwendungen auf (m)einem Laptop ist der Webbrowser.
Ich benutzt nachezu ausschließlich den Iceweasel 3.5.x
Der Browser verwendet per default einen Festplatten Cache, dieser ist bei mir 50MB groß und wird seiner Natur gemäß auch laufend verändert. Der Firefox (oder Iceweasel) verwendet darüber hinaus aber auch noch einen Cache im RAM. Beim Schieb erfährt man darüber näheres.
Deshalb habe ich mich entschlossen, ganz auf Festplatten Cache zu verzichten, und ihn auf 0 gesetzt.
Natürlich könnte man den cache Ordner des Browsers auch nach /tmp verlinken, das müsste man mal in der Praxis untersuchen......
Dank eines Kommentars bin ich da inzwischen weiter: ich habe den Key in about:config eingerichtet browser.cache.disk.parent_directory; /tmp/browser/
Hier mal der Smart Status;
smartctl 5.40 2010-07-12 r3124 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ADATA SSD S599 64GB Serial Number: 00000000000000000462 Firmware Version: 3.1.0 User Capacity: 60.022.480.896 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 6 Local Time is: Wed Dec 8 16:41:57 2010 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED
Auffallend ist nicht nur die sehr kleine Seriennummer und der Firmware stand, sondern auch der niedrige nutzbare Speicher. Dabei steht in der Produktinfo doch 64MB. Sowas 
Für den Firefox habe ich ein anderes Verzeichnis über die Einstellung (about:config) browser.cache.disk.parent_directory eingetragen, um das Temporärverzeichnis von meiner SSD wegzubekommen.
Wieder mal ein Wert, der nicht eingetragen ist ... Aber gute Lösung, so etwas in der Art hatte ich eigentlich auch gesucht
Danke für den Tipp, habe ich gleich umgesetzt
Die IT-Branche braucht alle paar Jahre eine technische Innovation, die zur Mythenbildung taugt, sodass man Gegenvoodoo veranstalten kann – etwa das 42-fache Äberschreiben von Daten auf Festplatten. Natürlich kann und wird jedes technische Bauteil irgendwann seinen Geist aufgeben. Dass SSDs allerdings kurzlebiger sein sollen als Festplatten, ist wahrscheinlich von Firmen wie Seagate lanciert worden. Mit modernem Wear Leveling pro Tag einen kompletten Write Cycle zu schaffen ist extrem unwahrscheinlich – schon weil die Schreibraten nicht so hoch sind, wie angegeben. Aber auch einfach, weil es selten so viel zu schreiben gibt. Aber selbst wenn man pro Tag einen kompletten Zyklus schafft, übertrifft eine SSD selbst mit MLC-Flash die Lebensdauer einer Festplatte noch deutlich (10000 / 360 = fast 30 Jahre) – von SLC mal gar nicht zu reden, die garantieren mehr als 100000 Zyklen. Bevor also die Nubsis ausleiern, geht eher ein anderes Bauteil kaputt. Das kann allerdings passieren. Deshalb sollte man selbstverständlich Back-ups machen. Man muss das Dateisystem allerdings deshalb nicht verändern. Und man muss auch nichts unpartitioniert lassen. Den Browsercache ins tmpfs zu verlegen hilft zwar IMHO nicht, die SSD zu schonen, bringt aber enorme Geschwindigkeitsvorteile, wenn man genug Ram hat – auch mit Festplatte.
Hallo, schöner Artikel, dankeschön für die neuen Anregungen. RAMLOCK und RAMRUN z.B. waren mir noch unbekannt, werde ich mir bei Gelegenheit mal ansehen, bisher fahre ich hier ganz gut mit 64Gb SSD und diversen tmpfs-Mountpoints + einigen etc/rc.local-Einstellungen + $HOME-Verschlüsselung - aber da kann sicherlich noch ordentlich optimiert werden. Habe diesen Artikel auf IML verlinkt falls jemand noch zufällig auf meinen älteren Beitrag stösst. Danke nochmal.
Bitte. Man kann sich damit richtig austoben, mal sehen, was mir noch ein bzw. auffällt.
Schöner Artikel. Zum letzten Punkt, dem Browser-Cache: Ich habe es selbst noch nicht probiert, aber im Arch-Linux-Wiki gibt es eine Anleitung, wie man das Firefox-Profil relativ sicher im RAM betreiben kann.
Danke für die Blumen! Ich habe den Tipp von Blubberbart umgesetzt. Der Cache Folder ist jetzt unter /tmp/Browser. tmp ist eh im RAM
Vielen Dank für den informativen und ausführlichen Artikel.
Ich besitze zwar keine SSD, aber meine langsame Laptop Festplatte freut sich ziemlich sicher auch wenn ich von ihr ein paar mountpoints in den ram ziehe. (Davon hab ich zum glück genug).
Tja, wenn RAM reichlich vorhanden ist... Frisch ans Werk
Was passiert denn, wenn die Schreibzyklen „durch“ sind: Wird das Teil einfach nur unsäglich langsam, kann man nur nicht mehr schreiben oder sind die Daten gleich komplett futsch?
Ich gehe davon aus, es wird immer langsamer und die Kapazität nimmt ab. mit
finde ich derzeit 544 Sektoren (sind wahscheinlich Blöcke und werden in meinem Fall wohl schon von Anfang an da gewesen sein)
Es wird gar nichts langsamer. Wenn Flashspeicher kaputt wird, lässt er sich nicht mehr beschreiben. Das hat Mancher vielleicht schon bei einem defekten USB-Stick bemerkt: Er lässt sich nicht mehr formatieren, dafür ist der alte Inhalt auf ewig eingebrannt.
Der SSD-Controller checkt daher nach jedem Schreibvorgang, ob die Speicherzelle den gewünschten Inhalt hat. Wenn nicht -> ab in den Defektbereich, her mit einer Reservezelle! (Insoferne ist dieser eine Schreibvorgang natürlich langsamer.) SSDs enthalten üblicherweise einige Prozent Reservezellen - für alle Fälle. Diese werden für die Wearlevelling-Zyklen verwendet.
Das ist also wesentlich sicherer als bei einer magnetischen Festplatte; wenn die altert, lässt sie sich zwar beschreiben, aber die Daten sind nach Minuten bis Monaten futsch. Hat auch sicher schon jeder erlebt.
Samsung gab bereits vor mehr als einem Jahr sogar für MLC-SSDs (also die billigen) bereits die doppelte Lebensdauer an wie für seine magnetischen Platten. Und rotierende Samsung-Platten sollen ja nicht schlecht sein...
Partition freilassen: Wo ist der Unterschied zwischen einer frei gelassenen Partition und frei gelassenem Bereich im Filesystem? Es wird wohl kaum jemand ständig mit einer zu 100 % gefüllten Platte arbeiten... Wenn TRIM funktioniert, braucht es die defnitiv nicht, ohnehin sind die 10-20 % nach ein paar Tagen bis Monaten nicht mehr jungfräulich. Ich habe z.B. auf meiner Homepartition (102 GB) seit ihrer Erstellung vor etwas mehr als einem halben Jahr 1454 GB geschrieben (lt. dumpe2fs). Umgelegt auf die gesamte Festplatte bedeutet das, dass jede Speicherzelle pro Jahr etwa 20 Mal überschrieben wird.
Die beschriebenen rcS-Parameter gibt es übrigens im Kernel 2.6.35 (Ubuntu 10.10) nicht mehr. Dieser legt /var/run und /var/lock bereits von sich aus ins RAM.
Swap im RAM macht ebenfalls keinen Sinn. (Ich gebe zu, ggf. muss man im Ubuntu ein paar sysctl-Parameter manuell tunen, um eine optimale RAM-Nutzung zu erreichen.) Für Swap gilt der alte Spruch: Hat man keines, ist das System mit vollem RAM ziemlich unbrauchbar (und man kann dem Out-of-Memory-Killer bei der Arbeit zusehen), hat man es, wird es zwar langsamer, aber es bleibt benützbar. Und besser man hat es, braucht es aber nicht, als umgekehrt.
Äbrigens: Vorsicht bei verschlüsselten Partitionen (z.B. LUKS, Truecrypt): Da verschlüsselte Daten immer mehr Platz benötigen als unverschlüsselte, wird das Layout über den Haufen geworfen. Wenn das Filesystem also glaubt, es schriebe auf Blockgrenze, tut es das auf SSD-Ebene keineswegs. Die Anzahl der Schreibvorgänge kann sich im schlimmsten Fall verdoppeln, auf jeden Fall wird die SSD aber wesentlich langsamer, als man das auf Grund der Verschlüsselung alleine vermuten würde.
Verschlüsselte Partitionen sollte man möglichst nur auf herkömmlichen Festplatten verwenden, zumindest, wenn sie häufig beschrieben werden. Gegen verschlüsselte Dateien (z.B. encfs, ecryptfs) spricht hingegen nichts.
Ubuntu: Ja, wollte gerade nachsehen und habe das hier per 'mount' gesehen:
Das mit der Verschlüsselung ist interessant, an eine steigende Anzahl der Schreibvorgänge habe ich da noch nie gedacht - betreibe U10.10 hier mit verschlüsselter $HOME-Partition, möglichst viel RAM-Nutzung (geht auch bei 'nur' 2GB im Privatgebrauch noch recht gut) und ein paar Optimierungen über die rc.local - das System funktioniert für mich ausreichend schnell und trotz verschlüsseltem $HOME fühlt es sich bei Zugriff auf entsprechende Daten dieser Partition zügiger an als auf den früher ausprobierten Festplatten.
Gemessen hab ich da aber noch nichts. Muss ich mich wohl mal wg. der Schreibvorgänge belesen.
Also das mit dem extra Speicherplatz frei lassen halte ich für ein Märchen und unnötig. Wie du im letzten Absatz bemerkst "fehlen" 4GB. Die 4GB sind in Wirklichkeit aber auch auf gelötet und sind vom Hersteller für Wear Leveling vorgesehen. Dein nicht formatierter Speicherplatz ist in meinen Augen verschenkt. Ich denke, dass du damit die Lebenszeit der SSD nur marginal verlängerst. Ich hab inzwischen schon einige defekte SSDs erlebt, aber da ist bisher der Controller drauf gegangen bevor die Flash-Chips überhaupt "alt" waren. Ich würde an deiner Stelle lieber die gesamte Festplatte formatieren und mich auf den Wear Leveling Algorithmus vom Hersteller verlassen. Regelmäßig Backups, sind sowieso Pflicht. Sollte die Platte nach einem Jahr zu langsam werden, kannst du ja die SSD komplett "trimmen" und dann ein backup zurück spielen. Das vollständig trimmen macht vermutlich auch bei einer Neuinstallation Sinn.
Mit deiner Meinung stehst du aber auf Gegenkurs zum C'T Artikel. Davon abgesehen scheint bei normaler Nutzung die Lebensdauer der SSD für Privatcomputer in der Tat mehr als ausreichend zu sein, das sehe ich auch so. Aber die Erfahrung aus dem Beruflichen Leben kann ich leider nicht beisteuern, ist nicht mehr mein Gebiet
Naja, die c't schreibt auch nur "Es kann..." und das ist sehr Waage. In anderen c't Artikeln stand auch schon, dass bei neueren Controllern der reservierte Bereich ausreichen sollte.
Stimmt, also wahrscheinlich wirklich ein wenig übertrieben. Aber was mache ich jetzt mit den 10 Gig? Da ich nun keinen Volumemanager benutzt habe, doppelfail... Naja, mal sehen. Vielleicht wandert ja doch noch wieder ein anderes Debian drauf
Du kannst es ja für Swap verwenden (; Ich geh nur davon aus, das swap leider nicht getrimmt wird.
Oder verwende einfach resize2fs und nimmst die 10GB dazu. Damit kannst du sogar / im laufenden Betrieb vergrößern und hast anschließend den gesamten Platz. (Backup vorher nicht vergessen (; )
Ja, ist schon klar, habe ich selber schon gemacht und beschrieben
Aber vorerst lasse ich es mal so. Man wird sehen
Wenn man beim Tunen der SSD-Hardware ist, kann man auch mal einen Blick auf den Scheduler werfen. Mir hatte dieser Beitrag hier gut gefallen:
http://everflux.de/ubuntu-desktop-tuning-mit-elevatordeadline-1681/
Bevor man einen anderen Sheduler verwendet, sollte man ausprobieren, ob es nicht reicht, dass I/O-lastige Programm mittels nice -n 19 ionice -c 3 $PROGRAMM startet. nice -n 19 macht eine niedrige Prozesspriorität und ionice -c 3 gibt dem Programm nur übrige I/Os So laufen alle IO-lastige Programme auf meinem System und so bin ich mit CFQ besser bedient.
Mal selber einen Kommentar zum Thema. Mich wurmt, das der Hersteller seine Parameter für S.M.A.R.T. nicht offenlegt. Damit wird es mit den smartmontools nicht möglich alle Attribute auszulesen und den Zustand gewissenhaft zu beurteilen. Der Hersteller verlangt die Unterzeichnug eines NDAm wenn man die Daten anfordert. Leute, das ist Scheisse!
Schöner Artikel mit guten Hinweisen zur GPTPartitionierung: http://www.aptosid.de/index.php?module=news&func=display&sid=32
Manuelles trim fürs Dateisystem fstrim -v -v ist wichtig, sonst erfährt man nicht, was es gebracht hat. Anwendungsbeispiel: [pre]fstrim -v --all /home: 9,8 GiB (10553425920 bytes) trimmed /boot: 167,3 MiB (175466496 bytes) trimmed /: 3,9 GiB (4158386176 bytes) trimmed [/pre]