-=Kernel-Error=-

IT-Blog von Sebastian van de Meer

Schlagwort: Trim

TRIM für SSDs im ZFS-Pool unter Linux aktivieren

24. Februar 2021 / / 3 Kommentare

Speicherzellen einer SSD sind nicht unendlich beschreibbar. Damit sie möglichst lange halten, verteilt die interne Logik der SSD Schreibzugriffe gleichmäßig über alle Bereiche — Wear Leveling. Dafür muss die SSD aber wissen, welche Blöcke wirklich frei sind. Diese Information kann sie nur vom Dateisystem bekommen. Genau dafür gibt es TRIM.

Wer sich für TRIM allgemein interessiert — im älteren Beitrag zu TRIM für SSDs und Flash-Speicher steht mehr zu den Grundlagen. Hier geht es nur um ZFS.

autotrim — kontinuierliches TRIM

ZFS kennt die Pool-Eigenschaft autotrim. Wenn aktiviert, schickt ZFS nach jedem Freigeben von Blöcken automatisch TRIM-Befehle an die darunterliegenden Geräte. Prüfen, ob es aktiv ist:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE  SOURCE
bpool  autotrim  off    local
rpool  autotrim  off    local

Aktivieren:

$ zpool set autotrim=on bpool
$ zpool set autotrim=on rpool

Kontrolle — jetzt sollte on stehen:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE  SOURCE
bpool  autotrim  on     local
rpool  autotrim  on     local

zpool trim — manuelles TRIM

Neben dem kontinuierlichen autotrim gibt es auch manuelles TRIM. Das ist sinnvoll, wenn man autotrim bisher nicht aktiviert hatte und den Pool einmalig aufräumen will:

$ zpool trim rpool

Der Fortschritt lässt sich mit zpool status -t rpool beobachten. Bei großen Pools kann das eine Weile dauern.

Tipp: SSD-Wartungsmodus

Wenn eine SSD nur am Strom hängt, ohne dass ein Rechner darauf zugreift, fallen viele SSDs in einen internen Wartungs- und Reparaturmodus. Die Firmware sortiert dann selbstständig Speicherzellen um, führt Diagnosen durch und versucht schwache Zellen zu retten. Einfach 2–3 Stunden laufen lassen. Über diesen Weg lassen sich manchmal sogar „tote“ SSDs wiederbeleben. Mit aktivem TRIM funktioniert das alles natürlich deutlich besser.

Hinweis für FreeBSD: autotrim und zpool trim funktionieren dort genauso — FreeBSD nutzt seit langem OpenZFS.

Fragen? Einfach melden.

FreeBSD 11 kommt…

26. September 2016 / / Keine Kommentare

Ich ertappe mich aktuell immer mal wieder dabei auf die Release Process Seite von FreeBSD 11 zu schauen. Mit immer mal wieder meine ich 1 / 2 mal am Tag.

https://www.freebsd.org/releases/11.0R/schedule.html

Oh ich bin gerade total gespannt auf die neue Version. Auf den Testkisten habe ich die RCs ja schon angetestet und ich lese ganz brav die current-liste (was es nicht besser macht). Jetzt wurde der RC3 Build ja vom 26.08 auf den 14.09 verschoben, das hat natürlich den Rest ebenfalls geschoben *schnief* 28.09 ist nun also erst einmal der press release Termin. uhhh das ist schon übermorgen *freu*.

Ich habe auch ganz brav wieder Geld gegeben: https://www.freebsdfoundation.org/donate/

Auf was ich besonders warte? Ohh auf 1000 Dinge der neuen Version aber besonders auf ein, vielleicht etwas dummes, Detail. trim auf zfs mit geli.

Wann habt ihr eigentlich das letzte mal etwas gespendet und sei es nur 5€??

Dear Sebastian van de Meer,

The FreeBSD Foundation would like to thank you for your generous donation of $200.00 on September 26, 2016.
 
It's people like you that make it possible for us to continue supporting the FreeBSD Project and community worldwide. We are incredibly grateful for all the support we receive from you and so many individuals and organizations that value FreeBSD.
 
The FreeBSD Foundation is a 501(c)3 non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. The Foundation gratefully accepts donations from individuals and businesses. Donations are used to fund and manage development projects, educating the public and promoting FreeBSD, sponsoring BSD conferences and summits, providing travel grants to FreeBSD developers, protecting FreeBSD IP and providing legal support to the Project, and purchasing hardware to build and improve FreeBSD Project infrastructure.
 
The FreeBSD Foundation is entirely supported by donations. For information regarding our goals, projects and use of collected funds, please visit our web site: www.FreeBSDFoundation.org.
 
No goods or services of any value were or will be transferred to you in connection with this donation. Please keep this written acknowledgment of your donation for your tax records.
 
Thanks again for your support!
 
Sincerely,
 
Deb Goodkin
Executive Director
The FreeBSD Foundation

Siehe auch: FreeBSD auf dem Desktop

Fragen? Einfach melden.

TRIM für SSDs und Flash-Speicher unter Linux aktivieren

4. August 2013 / / Keine Kommentare

Was macht TRIM?

Wenn eine Datei gelöscht wird, entfernt das Dateisystem nur den Eintrag aus seinem Inhaltsverzeichnis. Die Speicherblöcke werden als überschreibbar markiert — aber der Datenträger selbst erfährt davon nichts. Bei klassischen Festplatten ist das egal. Bei Flash-Speicher (SSDs, USB-Sticks, Speicherkarten) wird es zum Problem.

Flash-Speicher verteilt Schreibvorgänge gleichmäßig über alle Zellen — das nennt sich Wear Leveling und verlängert die Lebensdauer. Dafür muss der Controller aber wissen, welche Blöcke frei sind. Ohne diese Information kann er irgendwann nur noch den kleinen Reservebereich nutzen und wird spürbar langsam. Genau hier kommt TRIM ins Spiel: Es teilt dem Datenträger mit, welche Blöcke nicht mehr gebraucht werden.

Methode 1: fstrim (manuell oder per Cronjob)

  • Informiert den Datenträger nur zum Zeitpunkt der Ausführung
  • Funktioniert ab Kernel 2.6.33
  • Lässt sich einfach per Cronjob automatisieren

Einmalig ausführen:

fstrim -v /

Täglich per Cronjob — ein Script unter /etc/cron.daily/hdd-trim anlegen:

#!/bin/bash
echo "Gestartet am: $(date)" >> /var/log/hdd-trim.log
fstrim -v / >> /var/log/hdd-trim.log
chmod +x /etc/cron.daily/hdd-trim

Die meisten Linux-Distributionen bringen mittlerweile einen systemd-Timer fstrim.timer mit, der wöchentlich TRIM ausführt. Ob er aktiv ist: systemctl status fstrim.timer

Methode 2: discard (Echtzeit-TRIM per fstab)

  • Informiert den Datenträger in Echtzeit bei jedem Löschvorgang
  • Erzeugt minimal mehr I/O als periodisches fstrim
  • Bei modernen SSDs und Kerneln problemlos nutzbar

In der /etc/fstab die Option discard zu den Mount-Optionen hinzufügen:

/dev/sda1  /  ext4  noatime,errors=remount-ro,discard  0  1

Device, Mountpunkt und Dateisystem natürlich an das eigene Setup anpassen.

Welche Methode?

Für die meisten Setups reicht der wöchentliche fstrim.timer — das ist heute die empfohlene Methode. discard in der fstab ist sinnvoll, wenn der Datenträger permanent voll ist und sofort von freigegebenen Blöcken profitieren soll. Für ZFS gibt es eine eigene TRIM-Konfiguration — siehe TRIM im ZFS-Pool aktivieren.

Achtung: TRIM sagt dem Datenträger, dass er Blöcke überschreiben darf. Wenn hier etwas schiefgeht, sind Daten weg. Vorher prüfen, ob Kernel, Dateisystem und SSD-Firmware TRIM korrekt unterstützen — und ein Backup haben.

Siehe auch: TRIM für SSDs im ZFS-Pool

Fragen? Einfach melden.

ZFS Compression und Deduplication: Konfiguration und Praxis

22. März 2012 / / Keine Kommentare

Compression

ZFS kann Daten transparent beim Schreiben komprimieren und beim Lesen dekomprimieren. Bei heutigen CPUs merkt man davon nichts — im Gegenteil: Weil weniger Daten auf die Platte geschrieben werden müssen, sinkt die I/O-Last und es wird oft sogar schneller. Man bekommt also mehr Platz und mehr Performance gleichzeitig.

Wichtig: Beim Aktivieren werden nicht rückwirkend alle Daten komprimiert. Nur neue Schreibvorgänge werden komprimiert abgelegt. Schaltet man Compression wieder ab, bleiben die komprimierten Daten lesbar — neue Daten werden unkomprimiert geschrieben.

Aktivieren:

zfs set compression=lz4 pool/dataset

LZ4 ist heute der empfohlene Algorithmus — schnell, niedriger CPU-Verbrauch, gutes Kompressionsverhältnis. Es ist seit OpenZFS 0.7 und FreeBSD 12 der Default bei compression=on. Alternativ gibt es gzip (Level 1–9, stärkere Kompression aber mehr CPU) und zstd (seit OpenZFS 2.0, guter Kompromiss zwischen gzip und lz4).

Für Daten, die bereits komprimiert sind (Videos, Bilder, Archive), bringt Compression nichts — ZFS erkennt das und legt solche Blöcke unkomprimiert ab. Für Logfiles, Konfigurationen, VMs und Datenbanken lohnt es sich fast immer.

Compression in der Praxis

Test mit einer frischen Betriebssystem-Installation auf zwei baugleichen Rechnern — einmal mit, einmal ohne Compression:

# Kompressionsverhältnis prüfen
zfs get compressratio rpool
NAME   PROPERTY       VALUE  SOURCE
rpool  compressratio  1.52x  -

# Plattenverbrauch mit Compression
zpool list
NAME    SIZE  ALLOC   FREE    CAP  HEALTH
rpool    74G  2,59G  71,4G     3%  ONLINE

# Plattenverbrauch ohne Compression
zpool list
NAME    SIZE  ALLOC   FREE    CAP  HEALTH
rpool    74G  3,93G  70,1G     5%  ONLINE

2,59 GB statt 3,93 GB — ein Drittel weniger Plattenverbrauch bei einer Standard-Installation. Die Installation dauerte mit Compression etwa 30 Sekunden länger.

Algorithmus-Wahl

Pro Dataset lässt sich der Algorithmus und Level anpassen:

# LZ4 — schnell, empfohlen für fast alles
zfs set compression=lz4 pool/data

# gzip-9 — maximale Kompression, mehr CPU
zfs set compression=gzip-9 pool/archiv

# zstd — seit OpenZFS 2.0, guter Kompromiss
zfs set compression=zstd pool/logs

# Prüfen
zfs get compression pool/data

Deduplication

Bei aktivierter Deduplication werden identische Blöcke nur einmal gespeichert. ZFS bildet für jeden Block eine SHA-256-Checksumme — existiert ein Block mit derselben Checksumme bereits, wird nur ein Verweis angelegt statt die Daten erneut zu schreiben.

Das spart Platz bei VMs (viele identische OS-Blöcke), Fileservern (dasselbe Dokument an verschiedenen Stellen) oder Versionierungs-Kopien. Aktivieren:

zfs set dedup=on pool/vms

Für zusätzliche Sicherheit gegen Hash-Kollisionen kann man einen Byte-für-Byte-Vergleich erzwingen:

zfs set dedup=sha256,verify pool/vms

Dedup-Warnung: RAM-Verbrauch

Deduplication frisst RAM. Die Dedup-Tabelle (DDT) muss im Arbeitsspeicher gehalten werden — pro Block ein Eintrag. Faustformel: ~320 Bytes pro Block, bei 128K-Blockgröße also ~2,5 GB RAM pro TB gespeicherter Daten. Passt die DDT nicht mehr in den RAM, wird sie auf die Platte ausgelagert und die Performance bricht dramatisch ein.

Ob sich Dedup lohnt, kann man vorher mit einem Trockenlauf prüfen — zdb -S pool zeigt das erwartete Dedup-Ratio ohne tatsächlich zu deduplizieren. In den meisten Fällen ist Compression allein die bessere Wahl: weniger Komplexität, kein RAM-Overhead, und der Platzvorteil ist oft vergleichbar.

Mehr zu ZFS: TRIM im ZFS-Pool aktivieren und Linux Mint mit verschlüsseltem ZFS Root Pool. Fragen? Einfach melden.

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑