ZFS

1. Du partitionierst vier Platten mit fdisk (oder sgdisk, wenn du modern bist).
2. Du baust mit mdadm ein RAID10 (oder RAID5, wenn du Risiken magst): mdadm --create /dev/md0 ...
3. Du initialisierst das RAID-Device für LVM: pvcreate /dev/md0
4. Du erstellst eine Volume Group: vgcreate storage_vg /dev/md0
5. Du schneidest dir ein Logical Volume raus: lvcreate -n daten_lv -L 500G storage_vg
6. Du formatierst das Volume: mkfs.ext4 /dev/storage_vg/daten_lv
7. Du hoffst, dass keine Bits umkippen, denn ext4 merkt davon nichts (keine End-to-End-Checksums).
8. Snapshots? Klar, LVM-Snapshots. Die Dinger, die Performance kosten und den Platz fressen, als gäb’s kein Morgen.

Das sind sechs verschiedene Tools und Technologie-Layer (Partition, MD-RAID, PV, VG, LV, ext4), die voneinander kaum etwas wissen. Ein fragiler Turm aus Abstraktionen.

Was wir hatten: ZFS

ZFS ist kein Dateisystem. Es ist ein integrierter Storage-Stack. Es ist Filesystem und Volume-Manager in einem. Es macht nur eine Annahme: “Gib mir ganze Platten (oder Partitionen), ich kümmere mich um den Rest.”

Kern-Features:

• Pooled Storage: Alle Platten kommen in einen “Pool”. Keine Partitionen, keine Volumes. Du erstellst “Dateisysteme” (zfs create), die sich den Platz dynamisch teilen.
• Copy-on-Write (CoW): Daten werden nie überschrieben. Neue Daten werden woanders hingeschrieben, dann wird der Pointer umgehängt. Das macht Snapshots quasi kostenlos.
• Integrität: JEDER Block hat eine Checksumme. ZFS weiß immer, ob deine Daten korrupt sind (Bit Rot). Wenn du Redundanz (Mirror/RAID-Z) hast, repariert es das im Hintergrund automatisch.

Die ZFS CLI: Eleganz statt Gebastel

Vergleichen wir das 6-Schritte-Linux-Desaster von oben mit ZFS.

Szenario 1: Komplexer Pool (RAID 10 / Mirrored Stripes) Du hast vier Platten (sda bis sdd) und willst ein performantes, redundantes RAID 10.

• Linux: Siehe die mdadm + pvcreate + vgcreate + lvcreate + mkfs Orgie oben.
• ZFS (Eine Zeile):
  BASH

  Einklappen Kopieren

  1 2 3

  # Erstellt einen Pool "tank", der ein Stripe (RAID 0) # aus zwei Mirrors (RAID 1) ist. zpool create tank mirror /dev/sda /dev/sdb mirror /dev/sdc /dev/sdd

  Klicken Sie zum Erweitern und mehr anzeigen
  Fertig. Der Pool ist gemountet unter /tank. Er ist redundant. Er ist schnell.

Szenario 2: Snapshots und Rollback Du willst ein riskantes Deployment machen.

1. Dateisystem erstellen (Dataset):

   BASH

   Einklappen Kopieren

   1 2 3

   # Erstellt ein separates Dateisystem für das Projekt, # auf dem wir Quotas etc. setzen könnten. zfs create tank/mein_projekt

   Klicken Sie zum Erweitern und mehr anzeigen

2. Der Snapshot (kostenlos, sofort):

   BASH

   Einklappen Kopieren

   1	zfs snapshot tank/mein_projekt@vor-deployment

   Klicken Sie zum Erweitern und mehr anzeigen

3. …Deployment geht katastrophal schief. Alles brennt…

4. Der Rollback (sofort):

   BASH

   Einklappen Kopieren

   1 2	# Setzt ALLES im Dateisystem auf den alten Stand zurück. zfs rollback tank/mein_projekt@vor-deployment

   Klicken Sie zum Erweitern und mehr anzeigen

   Kein “Restore from Backup”. Kein Gefrickel. Nur ein Befehl.

Was Linux stattdessen tat: Ein Trauerspiel

Die Linux-Welt sah ZFS (lizenziert unter der GPL-inkompatiblen CDDL) und rief “Das wollen wir auch! Aber anders!”

1. Der unselige ReiserFS: Der erste Versuch, “etwas Besseres” als ext3 zu bauen. Es war schnell bei kleinen Dateien (Namesys-Slogan: “Your data is our data, your journal is our journal” – wie ironisch). Es war berüchtigt für seine Fähigkeit, ein Dateisystem bei Fehlern komplett zu schreddern. Es endete als technische Sackgasse, deren Name heute mehr für Kriminalgeschichte als für Kernel-Code steht.

2. Btrfs (Der “Wir-haben-ZFS-zuhause”-Kandidat): Die große Hoffnung. Von Oracle (ironischerweise) gestartet, um ZFS auf Linux zu ersetzen. Btrfs ist auf dem Papier ZFS: CoW, Snapshots, integriertes RAID, Checksums. Das Problem? Nach über 15 Jahren Entwicklung ist das Gefühl immer noch: “Es ist fast fertig.” Der RAID5/6-Modus war jahrelang als “instabil” verschrien und konnte Daten fressen (das berüchtigte “Write Hole”, das ZFS nie hatte). Es ist der ewige Beta-Test, während ZFS (via OpenZFS) auf Linux, FreeBSD und macOS einfach stabil läuft.

Fazit

Wir hatten eine fertige, brillante Enterprise-Storage-Lösung (ZFS), die auf Commodity-Hardware läuft.

Weil die Lizenz nicht passte, haben wir im Linux-Lager über ein Jahrzehnt damit verbracht: a) Einen fragilen 6-Lagen-Flickenteppich (mdadm/LVM) zu perfektionieren. b) Einen Klon (Btrfs) zu bauen, der 15 Jahre brauchte, um “vielleicht stabil” zu sein.

Das ist Technologie-Amnäsie in Reinform.

Quellen und Links

• OpenZFS

Dieser Artikel ist der Auftakt zur Serie “Technologie-Amnäsie”. Alle Türchen findest du unter /tags/techamnesia.

Alle Artikel dieser Serie