# Btrfs Deep Dive: Performance und Datensicherheit für Profis

TL;DR / Management Summary In SUSE ist Btrfs mehr als nur ein Dateisystem – es ist eine Datenverwaltungsplattform. Während die Grundlagen (Snapshots) bekannt sind, nutzen Senior Admins fortgeschrittene Features wie qgroups für Speicherplatz-Kontrolle, Incremental Replikation via send/receive und optimieren die Performance durch das gezielte Deaktivieren von Copy-on-Write (NoCoW) für Datenbanken und VMs.

# 1. Einführung & Architektur

B-Trees und Extents.

Btrfs basiert auf B-Bäumen. Daten werden in variablen Blöcken (Extents) gespeichert. Das Copy-on-Write (CoW) Prinzip sorgt dafür, dass bestehende Daten niemals überschrieben, sondern Kopien an neuen Orten erstellt werden.

# Der Replikations-Fluss (Mermaid)

graph LR
    A[Source Node: / (Btrfs)] -->|Snapshot| B[Read-Only Snapshot]
    B -->|btrfs send| C[Compressed Stream]
    C -->|Network / SSH| D[btrfs receive]
    D -->|Target Node| E[Backup Dataset]
    subgraph "Incremental Sync"
        B -->|Diff to last Snap| C
    end

# 2. qgroups: Quotas auf Btrfs-Ebene

Speicherverbrauch begrenzen.

Klassische Quotas (Artikel 090) funktionieren auf Btrfs oft unzuverlässig. Btrfs nutzt eigene Quota Groups (qgroups).

# Aktivierung und Nutzung

# Quota-Support für das FS einschalten
sudo btrfs quota enable /data

# Ein Subvolume auf 50GB limitieren
sudo btrfs qgroup limit 50G /data/projects

# 3. Performance Tuning: NoCoW für Datenbanken

Fragmentierung vermeiden.

Das größte Problem von Btrfs bei Datenbanken (MySQL, Postgres) ist die Fragmentierung durch ständige kleine Schreibzugriffe auf bestehende Dateien.

# Die Lösung: Das +C Attribut

Verzeichnisse für Datenbanken sollten NoCoW sein.

mkdir /var/lib/mysql_nocow
# Attribut setzen BEVOR Dateien darin erstellt werden
chattr +C /var/lib/mysql_nocow

# 4. Day-2 Operations: Btrfs Maintenance

Das Dateisystem gesund halten.

# 1. Scrub (Integritätsprüfung)

Liest alle Daten und vergleicht sie mit den Checksummen. Findet und repariert “Silent Data Corruption”.

sudo btrfs scrub start /
sudo btrfs scrub status /

# 2. Balance (Speicher-Reorganisation)

Gibt ungenutzte Chunks an den Pool zurück.

# Balance nur für wenig genutzte Chunks (spart Zeit)
sudo btrfs balance start -dusage=50 /

# 5. Troubleshooting & “War Stories”

Wenn der Platz ‘gefangen’ ist.

# Story 1: “Der 0-Byte Albtraum”

Symptom: Der Server meldet “No space left on device”, obwohl df noch 10GB anzeigt. Ursache: Btrfs hat keine freien Chunks mehr für Metadaten reserviert. Lösung: Fügen Sie temporär eine kleine USB-Disk oder ein Loop-Device dem Pool hinzu, führen Sie eine Balance durch und entfernen Sie das temporäre Device wieder.

sudo btrfs device add /dev/loop0 /
sudo btrfs balance start /
sudo btrfs device remove /dev/loop0 /

# Story 2: “Snapshot-Inflation”

Symptom: Nach einem Jahr Snapper-Nutzung wird das System bei jedem Schreibvorgang quälend langsam. Ursache: Zu viele Snapshots (tausende) führen zu einem massiven B-Baum-Overhead. Lösung: Begrenzen Sie die Anzahl der Snapshots in der Snapper-Konfiguration (NUMBER_LIMIT). Löschen Sie alte Bestände.

# 6. Fazit & Empfehlung

• Backup: Nutzen Sie btrfs send/receive für Disaster Recovery zwischen Standorten. Es ist effizienter als rsync.
• Wartung: Lassen Sie die wöchentlichen Scrub-Tasks aktiv.
• Wahl: Nutzen Sie Btrfs für fast alles, außer für Hochleistungs-Datenbanken (dort XFS).

# Anhang: Cheatsheet