Zwei Dinge, die meinen SSDs fehlten: TRIM nach BitLocker und ein Schreibcache, den mein HPE-Server heimlich abgeschaltet hat

🌐 Auch auf: English · Français · Español

HP3, mein HPE MicroServer Gen10 Plus v2, läuft wieder mit Debian 13 und OpenZFS. Warum er Windows wieder verlassen hat, ist eine Geschichte für einen anderen Beitrag. In diesem geht es um die Wiederherstellung danach und um eine Einstellung, die sich zwei Betriebssysteme und zwei Blogbeiträge lang vor aller Augen versteckt hatte.

Der Plan war langweilig, so wie eine Wiederherstellung sein sollte: ein frischer RAIDZ1-Pool über dieselben drei WD-Red-SA500-SSDs, Datasets pro Benutzer, dann rund 1,7 TB per rsync von einer USB-Platte zurückkopieren. Arbeitsteilung wie immer: Ich entscheide, mein KI-Co-Admin (Claude) führt die Befehle aus und behält die Zahlen im Blick. Und genau die Zahlen sahen bald falsch aus.

🐌 Sieben Megabyte pro Sekunde. Pro SSD.

Die Kopie kroch mit 25 bis 35 MB/s dahin. Die Schätzung lag bei rund sechzehn Stunden. Selbst Kleinigkeiten wie zfs create oder zpool status hingen minutenlang, weil sie darauf warteten, dass die nächste Transaktionsgruppe fertig synchronisiert war. Dann zeigte zpool iostat -l das eigentliche Problem:

$ zpool iostat -vl storage 5 1
                                  bandwidth      total_wait    disk_wait
                                  read  write    read  write   read  write
storage                          3.42K  22.7M     1ms  233ms    1ms   65ms
  raidz1-0                       3.42K  22.7M     1ms  233ms    1ms   65ms
    ata-WD_Red_SA500_..._00458   1.14K  7.57M     1ms  262ms    1ms   68ms
    ata-WD_Red_SA500_..._01387   1.14K  7.58M     1ms  258ms    1ms   72ms
    ata-WD_Red_SA500_..._02050   1.14K  7.58M     1ms  181ms    1ms   57ms

$ cat /proc/pressure/io
some avg10=94.05 avg60=90.06 avg300=80.24
full avg10=88.82 avg60=84.62 avg300=75.87

Etwa 7,5 MB/s pro Laufwerk bei 65 ms Latenz, und die Kiste verbrachte rund 90 % ihrer Zeit mit Warten auf I/O. Das sind SATA-SSDs, die für deutlich über 500 MB/s sequenzielles Schreiben ausgelegt sind. 65 ms sind Festplatten-Niveau. Eigentlich schlimmer: Eine ordentliche HDD schafft mehr.

🕵️ Verdächtiger Nummer eins: TRIM, und ich kannte das schon

TRIM war der erste Verdächtige, und zwar nicht nur in der Theorie. Es hatte mich schon einmal erwischt. Als ich diese SSDs zum ersten Mal von Windows auf Linux umgezogen habe, habe ich Debian auf Platten installiert, die vorher mit BitLocker verschlüsselt waren. Die Zahlen waren genauso furchtbar wie jetzt, und damals war ein TRIM die Lösung. Als also dieselben Symptome zurückkamen, setzte das Déjà-vu ein.

Warum BitLocker und SSDs bei einer Neuinstallation so eine schlechte Kombination sind, liegt daran, wie eine SSD die Welt sieht. Sie hat keine Ahnung, was eine Datei ist. Sie kennt nur logische Blöcke, und ein Block gilt als „belegt“, sobald irgendetwas hineingeschrieben wurde, und zwar so lange, bis jemand ausdrücklich sagt: „Den kannst du vergessen.“ Dieser Jemand ist TRIM (unter Linux discard). Ein Dateisystem schickt es, wenn es Dateien löscht. Ein frisches mkfs oder zpool create über alten Daten tut das nicht unbedingt für die ganze Platte.

BitLocker macht das so schlimm wie nur möglich. Verschlüsselte Daten sind von Zufallsrauschen nicht zu unterscheiden, im Laufwerk gibt es also nichts zu komprimieren oder zu deduplizieren. Und wenn ein Volume eine Weile verschlüsselt war und beschrieben wurde, enthält ein großer Teil des Flash-Speichers etwas, das die SSD als wertvolle Daten behandeln muss. Dann bügele ich ein neues Betriebssystem drüber. Die Partitionstabelle ist neu, das Dateisystem ist neu, aber niemand sagt der SSD, dass all die alten Blöcke jetzt Müll sind. Aus ihrer Sicht ist das Laufwerk immer noch voll.

Das tut weh, weil Flash nicht an Ort und Stelle überschrieben werden kann. Es wird in Pages geschrieben und in viel größeren Blöcken gelöscht. Ein Laufwerk, das sich für voll hält, hat keine vorab gelöschten Blöcke mehr. Für jeden neuen Schreibvorgang muss seine Garbage Collection erst einen Block finden, die noch „gültigen“ Pages (das alte verschlüsselte Rauschen) woandershin kopieren, den Block löschen und erst dann die neuen Daten schreiben. Aus einem Schreibvorgang des Hosts werden mehrere interne (Write Amplification). Der Durchsatz bricht ein, die Latenz explodiert, und obendrein verschleißt das Laufwerk schneller.

Der richtige Weg, den ich hier aufschreibe, damit mein zukünftiges Ich ihn auch wirklich geht: Bevor man gebrauchte SSDs einem neuen Dateisystem übergibt, verwirft man ihren Inhalt komplett. Das zerstört alles auf der Platte, und genau darum geht es:

# Before zpool create / mkfs — irreversibly wipes the drive!
blkdiscard /dev/disk/by-id/ata-WD_Red_SA500_2.5_2TB_...

# Check that the drive supports TRIM at all (non-zero DISC-GRAN/DISC-MAX):
lsblk --discard /dev/sdX

Auf einer SATA-SSD im Leerlauf dauert blkdiscard für das ganze Laufwerk meist Sekunden bis wenige Minuten. Nachträglich mit zpool trim auf einem laufenden Pool geht es auch. ZFS verwirft dann nur den Platz, den es nicht nutzt. Das ist aber langsamer, konkurriert mit echtem I/O und hilft erst ab dem Moment, in dem es läuft.

Es gibt noch eine dritte Möglichkeit, die mir erst später auffiel, als ich im BIOS nach etwas anderem suchte (siehe unten): Das HPE RBSU hat SATA Secure Erase und SATA Sanitize eingebaut. Das ist die Firmware-Variante derselben Idee. Das Laufwerk wirft selbst alles weg, auch seine eigenen Zuordnungstabellen, und ist danach so frisch wie am ersten Tag, mit jedem Block frei. Für SSDs, die ohnehin gelöscht werden sollen, ist das wohl der sauberste Reset überhaupt, und er braucht kein laufendes Betriebssystem. Dieselbe Warnung, in größeren Buchstaben: Es löscht das Laufwerk vollständig.

Diesmal hatte ich diesen Schritt ausgelassen, also haben wir mitten in der Wiederherstellung ein vollständiges zpool trim storage gestartet. Vierzig Minuten später stand es bei 2 %, und die Kopie war kaum schneller. TRIM war Teil des Problems, aber nicht der Teil, der SSDs in Disketten verwandelt hatte. Etwas Grundlegenderes stimmte auch nicht. Und wenn man weiß, was es war, ergibt auch ein TRIM, das bei 2 % dahinschleicht, plötzlich Sinn.

💡 Verdächtiger Nummer zwei: ein Wort in sysfs

$ for d in sda sdb sdc sdd; do echo "$d $(cat /sys/block/$d/queue/write_cache)"; done
sda write through
sdb write through
sdc write through
sdd write through

$ hdparm -W /dev/disk/by-id/ata-WD_Red_SA500_2.5_2TB_...
 write-caching =  0 (off)

Write through. Der laufwerkseigene Schreibcache war abgeschaltet. Jede SSD hat einen kleinen DRAM-Puffer: Er nimmt eingehende Schreibvorgänge an, meldet „erledigt“ und schreibt sie dann in großen, effizienten Stücken in den Flash-Speicher. Ohne ihn muss das Laufwerk jeden einzelnen Schreibvorgang selbst auf dem Flash abschließen, bevor es sich zurückmeldet. Für eine SSD ist das ungefähr die schlechteste Arbeitsweise, denn Flash wird in großen Pages geschrieben und in noch größeren Blöcken gelöscht. Viele kleine, einzelne Schreibvorgänge bedeuten langsames Schreiben und zusätzlichen Verschleiß.

Wer hat ihn abgeschaltet? Debian nicht, es fasst diese Einstellung nicht an. Das Kernel-Log beantwortet die Frage, zwei Sekunden nach dem Einschalten, lange bevor irgendetwas im Userspace gelaufen ist:

$ dmesg | grep -i "write cache"
[    2.101312] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled
[    2.101316] sd 3:0:0:0: [sdc] Write cache: disabled, read cache: enabled
[    2.101332] sd 5:0:0:0: [sdd] Write cache: disabled, read cache: enabled
[    2.101407] sd 4:0:0:0: [sdb] Write cache: disabled, read cache: enabled
[    3.644946] sd 6:0:0:0: [sde] Write cache: enabled, read cache: enabled   ← USB stick
[  530.822448] sd 7:0:0:0: [sdf] Write cache: enabled, read cache: enabled   ← USB disk

Alle vier internen SATA-SSDs kommen mit disabled hoch, beide USB-Geräte mit enabled. SATA-Laufwerke werden mit eingeschaltetem Schreibcache ausgeliefert, also schaltet ihn etwas während des POST ab, und dieses Etwas ist die Firmware des Servers. HPE setzt für SATA-Laufwerke offenbar standardmäßig „Laufwerks-Schreibcache aus“, und wie sich herausstellte, lässt sich das nicht ändern (mehr dazu unten). Die Indizien weisen eindeutig auf die Plattform, nicht zu Linux.

⚡ Einen Befehl später

$ for d in /dev/disk/by-id/ata-WD_Red_SA500_2.5_2TB_*[0-9]; do hdparm -W1 "$d"; done
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
 ...

Live, mitten in der Kopie, ohne Neustart. Die SSDs waren nicht mehr das Problem, sondern warteten jetzt auf eine tragbare USB-Festplatte. Nach der Wiederherstellung habe ich zusätzlich einen sauberen Benchmark gemacht.

📊 Der saubere Benchmark: dieselben Platten, ein Schalter

Als die Wiederherstellung fertig und der Pool wieder ruhig war (rund 1,3 TB belegt, TRIM noch pausiert), habe ich dieselben dd-Tests wie im ursprünglichen NAS-Beitrag laufen lassen, zweimal: einmal mit wieder abgeschaltetem Laufwerks-Schreibcache, einmal mit eingeschaltetem. Diesmal habe ich die Lehren aus jenem Beitrag ernst genommen: ein eigenes Test-Dataset mit compression=off, eine 1-GiB-Datei mit Zufallsdaten aus dem RAM (/dev/shm), damit /dev/urandom nicht zum Engpass wird, fsync am Ende und O_DIRECT beim Lesen, damit der ARC die Lesewerte nicht schönt.

zfs create -o compression=off storage/bench
head -c 1G /dev/urandom > /dev/shm/rand.bin

dd if=/dev/shm/rand.bin of=/storage/bench/t bs=1M conv=fsync                 # buffered + fsync
dd if=/dev/shm/rand.bin of=/storage/bench/t bs=1M oflag=direct conv=fsync    # O_DIRECT
dd if=/dev/shm/rand.bin of=/storage/bench/t4k bs=4k count=5000 oflag=direct,dsync
dd if=/storage/bench/t of=/dev/null bs=1M iflag=direct                       # read

Zwei Megabyte pro Sekunde. Auf SSDs. Der erste Versuch nutzte wie der ursprüngliche Beitrag eine 4-GiB-Datei. Mit abgeschaltetem Cache schaffte er 3 MB/s und hätte deutlich über eine halbe Stunde gedauert, also habe ich auf 1 GiB verkürzt. Das ist schon ein Ergebnis für sich.

Was die Tabelle eigentlich aussagt:

• Schreiben wird um den Faktor 70 bis 120 schneller. Das ist kein Tuning-Gewinn mehr. Das ist der Unterschied zwischen „kaputt“ und „funktioniert“.
• Lesen ändert sich nicht. Natürlich nicht, es ist ja ein Schreibcache. Der kleine Unterschied ist Messrauschen zwischen den Läufen.
• Synchrone 4K-Schreibvorgänge werden überhaupt nicht besser, und das ist richtig so. Mit dsync endet jeder einzelne 4K-Schreibvorgang mit einem Cache-Flush, der Cache wird also so schnell geleert, wie er sich füllt. Für Workloads mit vielen synchronen Schreibvorgängen (Datenbanken, NFS mit sync, VMs) ist die Antwort nicht der Laufwerks-Cache, sondern ein separates Log-Gerät für ZFS (SLOG) oder SSDs mit Stromausfallschutz. Der Schreibcache ist keine Zauberei. Er verhindert nur, dass das Laufwerk jeden Schreibvorgang auf die denkbar mühsamste Art erledigt.
• Im Vergleich zum ursprünglichen Beitrag (138 MB/s gepuffert, 15,4 MB/s O_DIRECT) sind die Werte ohne Cache heute sogar noch schlechter. Ich vermute, da wirkt das zweite Problem aus diesem Beitrag mit: Damals waren die Laufwerke frisch, diesmal waren sie voller alter BitLocker-Daten, und das TRIM war noch nicht gelaufen. Zwei Dinge fehlten, und jedes macht das andere schlimmer.

🔙 Der Teil, in dem ich meinen eigenen Blog noch mal lese

Jetzt kommt der leicht peinliche Teil. Das sind dieselben drei SSDs in derselben Kiste, über die ich schon zweimal geschrieben habe. Beide Male haben mir die Zahlen genau das gesagt, und beide Male habe ich eine plausible Erklärung gefunden und bin weitergezogen.

Erster Fehlschuss: Building a RAIDZ1 NAS on Debian 13 with OpenZFS. Ich habe 138 MB/s gepuffertes Schreiben gemessen und 15,4 MB/s mit O_DIRECT, also etwa neunmal langsamer. Ich habe sogar geschrieben, dass mich das „so überrascht hat, dass ich es doppelt und dreifach geprüft habe“. Dann habe ich es mit dem Bündeln von Transaktionsgruppen in ZFS erklärt: Gepufferte Schreibvorgänge werden zu vollen Stripe-Schreibvorgängen zusammengefasst, O_DIRECT umgeht das. Das stimmt auch. Aber die Erklärung war zu bequem. Mit abgeschaltetem Laufwerks-Cache muss jeder nicht gebündelte Schreibvorgang auf den Flash selbst warten, und genau das macht aus „etwas langsamer“ ein „neunmal langsamer“. Selbst der „gute“ Wert hätte einen zweiten Blick verdient: 138 MB/s über drei SATA-SSDs sind nicht berauschend.

Zweiter Fehlschuss: Enough YAML for Now, auf der Windows-Seite. Storage-Spaces-Parität auf denselben Platten: 88 MiB/s sequenzielles Schreiben, 461 IOPS bei zufälligem Schreiben und eine Latenz im 99. Perzentil von über einer Sekunde. Ich habe die Parität verantwortlich gemacht: „Lesen ist großartig. Schreiben ist … Parität.“ Die Read-Modify-Write-Kosten der Parität sind real. Aber ich habe DiskSpd auch mit -Sh laufen lassen, was den Schreibcache des Laufwerks für den Test absichtlich abschaltet. Der Benchmark hat „kein Schreibcache“ mit Absicht gemessen, und genau so lief der Server zufällig ohnehin jeden Tag. Der schlimmste Fall und der Alltag waren dasselbe, und ich habe nie nach dem Warum gefragt.

Zwei Betriebssysteme, zwei Benchmarks, zwei vernünftig klingende Erklärungen, eine Einstellung, die niemand geprüft hat. Die Lehre ist nicht „Benchmarks lügen“. Sondern dass ich die Zahlen mit meinen Erwartungen an die Software verglichen habe und nie mit dem Datenblatt der Hardware. 15 MB/s Schreiben auf einer SSD hätten ein Warnsignal sein müssen, egal welches Dateisystem darauf lief.

🛡️ Ist es sicher, ihn einzuschalten?

Das ist die naheliegende Frage: Wenn HPE ihn abschaltet, gibt es vielleicht einen Grund.

Es gibt einen Grund, und er trifft hier größtenteils nicht zu. Der Laufwerks-Cache ist flüchtiger RAM. Fällt der Strom aus, ist verloren, was darin liegt und noch nicht auf dem Flash ist. Enterprise-SSDs haben dafür Kondensatoren („Power-Loss-Protection“), Consumer- und NAS-SSDs meist nicht. Dazu kommt: Ein klassischer HPE-Server nutzt einen Smart-Array-RAID-Controller mit eigenem, batteriegepuffertem Cache. In diesem Aufbau ist der Laufwerks-Cache bestenfalls überflüssig und schlimmstenfalls ein Risiko, also ist Abschalten die vorsichtige Wahl. Für einen Hersteller, der nicht weiß, welches Betriebssystem, Dateisystem oder welchen Controller du einsetzt, ist „aus“ die sichere Voreinstellung.

Auf einem modernen Dateisystem ist ein Schreibcache sicher, weil das Dateisystem dem Laufwerk sagt, wann Daten dauerhaft gespeichert sein müssen. An jedem entscheidenden Punkt schicken ZFS, ext4 und NTFS einen Cache-Flush und betrachten nichts als festgeschrieben, bis das Laufwerk es bestätigt. ZFS arbeitet zusätzlich mit Copy-on-Write, nach einem Absturz hat man also entweder den letzten konsistenten Stand oder den neuen, nie eine Mischung. Die einzige echte Gefahr ist ein Laufwerk, das Flushes bestätigt, die es nie ausgeführt hat (billige, zweifelhafte Firmware), oder unter Windows das Häkchen bei „Leeren des Windows-Schreibcachepuffers auf dem Gerät deaktivieren“. Das ist wirklich das Häkchen für „Ich lebe gern gefährlich“.

Und in meinem Fall hängen alle drei HP-Server ohnehin an einer USV. Was noch auf der To-do-Liste steht: HP3 soll sauber herunterfahren, wenn der Akku zur Neige geht (NUT). Eine USV, die leerläuft, während der Server weiterschreibt, verschiebt den Stromausfall nur.

💾 SSDs, HDDs und der PC unter deinem Schreibtisch

• SSDs leiden am meisten. Flash wird in Pages geschrieben und in Blöcken gelöscht. Ohne Cache kann das Laufwerk kleine Schreibvorgänge nicht sammeln, jeder kostet also mehr Zeit und mehr Verschleiß. So kommt man auf 7,5 MB/s.
• HDDs verlieren auch, vor allem beim zufälligen Schreiben, weil das Laufwerk die Anfragen nicht mehr umsortieren kann, um Kopfbewegungen zu minimieren. Sequenzielles Schreiben leidet weniger.
• Normale Desktop-PCs sind fast immer in Ordnung. Consumer-BIOS fassen die Einstellung nicht an, und Windows lässt „Schreibcache auf dem Gerät aktivieren“ für interne Laufwerke eingeschaltet. Mein Jump-Host, ein gewöhnliches Desktop-Board, meldet write back für seine 8-TB-HDD und seine NVMe-SSD. Auch NVMe hat einen flüchtigen Schreibcache, und das Betriebssystem steuert ihn, standardmäßig eingeschaltet.
• USB-Laufwerke unter Windows sind die Ausnahme, die du wahrscheinlich schon gespürt hast. Sie stehen standardmäßig auf „Schnelles Entfernen“, dabei verzichtet Windows auf seiner Seite auf Write-Back-Caching, damit du den Stick ohne Auswerfen abziehen kannst. Das ist ein Grund, warum große Kopien auf USB unter Windows oft langsamer wirken als unter Linux.

Prüf es selbst:

# Linux
cat /sys/block/*/queue/write_cache
dmesg | grep -i "write cache"
hdparm -W /dev/sdX                      # SATA

# Windows (PowerShell)
Get-PhysicalDisk | Get-StorageAdvancedProperty   # IsDeviceCacheEnabled, IsPowerProtected

🔧 Damit es bleibt

hdparm -W1 ist flüchtig: Das Laufwerk setzt es beim nächsten Aus- und Einschalten zurück, und die Firmware schaltet es bei jedem Start wieder ab. Also muss auch die Korrektur bei jedem Start passieren. Vorerst ist das eine udev-Regel:

# /etc/udev/rules.d/69-ssd-write-cache.rules
# HPE firmware disables the SATA SSD write cache at boot (write through).
# ZFS and ext4 issue cache flushes, so enabling it is safe.
ACTION=="add|change", KERNEL=="sd[a-z]", SUBSYSTEM=="block", ENV{ID_BUS}=="ata", \
  ATTR{queue/rotational}=="0", RUN+="/usr/sbin/hdparm -W1 /dev/%k"

Sie betrifft nur interne, nicht rotierende ATA-Laufwerke, die System-SSD bekommt sie also auch, und USB-Geräte bleiben unberührt.

Wäre das BIOS nicht der bessere Ort? Theoretisch ja: Eine Firmware-Einstellung greift, bevor irgendein Betriebssystem lädt, überlebt eine Neuinstallation und gilt auch für Installer und Rettungssysteme. Also habe ich ins RBSU (F9) neu gestartet und gesucht. Unter System Configuration → BIOS/Platform Configuration → Storage Options → SATA Controller Options gibt es beim MicroServer Gen10 Plus v2 genau drei Einträge:

• Embedded SATA Configuration: SATA AHCI Support
• SATA Secure Erase
• SATA Sanitize

Das ist alles. Kein „Drive Write Cache“, auch nichts in den Performance-Optionen. Im AHCI-Modus schaltet die Firmware den Cache ab und gibt dir keine Möglichkeit, das zu ändern. (Smart-Array-Controller haben zwar eine „Physical Drive Write Cache Policy“, aber die Kiste in einen RAID-Modus zu schalten, um an diesen Regler zu kommen, würde die Platten vor Linux verstecken und den ZFS-Pool gleich mitnehmen. Keine Option.) Die udev-Regel ist also kein Sicherheitsgurt neben der eigentlichen Lösung. Sie ist die Lösung, bei jedem Start vom Betriebssystem angewendet, weil es sonst niemand tut.

Das heißt auch: Sie muss Teil des Aufbaus sein und nicht etwas, an das man sich hinterher erinnert. Wenn die nächste Neuinstallation diese eine Datei vergisst, sind wir wieder bei 7,5 MB/s und wahrscheinlich bei einem weiteren Blogbeitrag.

Die beiden anderen HP-Server haben mit ziemlicher Sicherheit dieselbe Voreinstellung. Sie sind dran, sobald ich entschieden habe, was mit ihnen passiert.

🎯 Fazit

Ich habe zwei Beiträge voller sorgfältiger Benchmarks geschrieben: komprimierbare gegen nicht komprimierbare Daten, ARC gegen Page-Cache, die mit Nullen gefüllten Testdateien von DiskSpd. Das waren gute Lektionen, und alle handelten davon, dass mich die Software anlügt. Währenddessen war die Hardware vollkommen ehrlich: ein Wort in sysfs, eine Zeile in dmesg und eine TRIM-Lektion, die ich nach der BitLocker-Installation schon einmal gelernt und prompt wieder vergessen hatte. Ich habe einfach nie hingeschaut.

Wenn mir das nächste Mal eine Zahl komisch vorkommt, lautet die erste Frage nicht „Wie erklärt mein Dateisystem das?“, sondern „Was soll diese Hardware eigentlich leisten?“. Eine SATA-SSD mit 15 MB/s ist keine interessante Eigenheit des Dateisystems. Das ist eine Einstellung oder ein fehlendes TRIM, in meinem Fall beides. 🔍💾

Meine Checkliste für wiederverwendete SSDs in einem Server ab jetzt:

1. Zuerst verwerfen. blkdiscard auf jede gebrauchte SSD, bevor der Pool angelegt wird (oder SATA Secure Erase / Sanitize im BIOS), vor allem wenn BitLocker oder eine andere Vollverschlüsselung darauf war.
2. Die udev-Regel mit der Installation ausliefern, bei HPE-Kisten im AHCI-Modus. Das BIOS erledigt das nicht für dich.
3. Den Schreibcache prüfen. dmesg | grep -i "write cache" und /sys/block/*/queue/write_cache. Erwartet wird „write back“.
4. Mit dem Datenblatt vergleichen, nicht mit den eigenen Erwartungen an das Dateisystem.
5. Erst dann benchmarken, mit nicht komprimierbaren Daten und auf einem ruhigen Pool.

📚 Mehr aus dieser Reihe: das RAIDZ1-NAS (auf Englisch)

• Building a RAIDZ1 NAS on Debian 13 with OpenZFS: Datasets, Compression, and the Lies dd Told Me
• RAIDZ1 NAS Addendum: How Scrub and Trim Actually Get Scheduled — and the Alert That Wasn’t
• Everybody Smile — We’re Taking a Snapshot! Moving From rdiff-backup to ZFS on the RAIDZ1 NAS
• Second Addendum: ZED Watches My Pool’s Health, Not Its Waistline