# The Linux Storage Stack: Die Architektur der Datenpfade

TL;DR / Management Summary Linux ist in der Lage, hunderte verschiedene Dateisysteme (Ext4, XFS, ZFS, NFS, GlusterFS) einheitlich anzusprechen. Das Geheimnis ist das VFS (Virtual File System). Es ist die Abstraktionsschicht, die Applikationen erlaubt, Dateien zu lesen und zu schreiben, ohne die Details der Hardware zu kennen. In diesem Modul analysieren wir die Schichten vom User-Space-Aufruf bis zum physischen Block und lernen, wo wir Performance-Metriken auf jeder Ebene abgreifen können.

# 1. Einführung & Architektur

Die Schichten der Abstraktion.

Wenn eine Applikation write() ruft, durchläuft dieser Befehl eine lange Kette von Software-Komponenten.

# Der Full-Stack (Mermaid)

graph TD
    A[Application: SQL / Web] -->|1. POSIX API| B[VFS: Virtual File System]
    B -->|2. Specific FS Driver| C[Filesystem: e.g. Ext4]
    C -->|3. Buffer Management| D[Page Cache: RAM]
    D -->|4. BIO Struct| E[Block Layer: Generic Block]
    E -->|5. Scheduling| F[IO Scheduler: kyber]
    F -->|6. Driver| G[Driver Layer: nvme / sd]
    G -->|7. Command| H[Physical Device]

# 2. VFS: Der große Übersetzer

Ein Interface für alle.

Das VFS definiert eine Reihe von Standard-Operationen (open, read, write, seek), die jedes Dateisystem implementieren muss.

• Vorteil: Sie können grep auf einer lokalen Datei genauso ausführen wie auf einem Cloud-Speicher (S3 via FUSE).
• Inodes & Dentries: VFS verwaltet Metadaten im RAM (Dentry Cache), um Verzeichnis-Suchen zu beschleunigen.

# 3. Der Block-Layer (Bio)

Daten in Bewegung.

Sobald Daten aus dem Page-Cache auf die Disk müssen, werden sie in bio-Strukturen (Block I/O) gekapselt.

• Merging: Der Block-Layer bündelt viele kleine Schreibzugriffe zu einem großen, um die I/O-Performance zu steigern.
• Splitting: Zu große Anfragen werden auf die maximale Größe des Hardware-Controllers aufgeteilt.

# 4. Day-2 Operations: Stack-Analyse

Wo liegt die Bremse?

Nutzen Sie Werkzeuge, die auf verschiedenen Ebenen des Stacks ansetzen:

1. User-Space: strace -e write (Misst Latenz der App-Aufrufe).
2. VFS-Ebene: vfsstat (aus bcc-tools).
3. Block-Ebene: iostat (Artikel 266).
4. Treiber-Ebene: dmesg (Fehler des Hardware-Treibers).

# 5. Troubleshooting & “War Stories”

Wenn die Abstraktion bricht.

# Story 1: “Die hängende App durch VFS-Lock”

Symptom: Alle Prozesse, die auf /data zugreifen wollen, hängen im Status D (Uninterruptible Sleep). Die Disk-Last ist aber bei 0%. Ursache: Ein Netzwerk-Dateisystem (NFS) hat die Verbindung verloren. Das VFS wartet auf ein Lock des Remote-Systems und blockiert den gesamten Aufrufpfad. Lösung: Nutzen Sie mount -o soft,intr oder forcieren Sie den Unmount: umount -l /data.

# Story 2: “Das Inode-Limit des VFS”

Symptom: Sie können keine Dateien mehr erstellen (“No space left on device”), obwohl noch TB-weise Platz frei ist. Ursache: Das Dateisystem (z.B. Ext4) hat keine freien Inodes (Metadaten-Zeiger) mehr. Das VFS kann keinen neuen Eintrag im Inode-Table erstellen. Lösung: Finden Sie Verzeichnisse mit Millionen kleiner Dateien: find / -xdev -type d -size +100k. Löschen Sie unnötige Dateien (z.B. Session-Files oder Temp-Mails).

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie für High-Performance Datenbanken das Flag O_DIRECT, um den Page-Cache zu umgehen und direkt in den Block-Layer zu schreiben.
• Wartung: Überwachen Sie die Dentry-Cache Größe via /proc/sys/fs/dentry-state.
• Wissen: Der Storage-Stack ist heute hochgradig parallel (blk-mq). Stellen Sie sicher, dass Ihre Applikation ebenfalls Multi-Threaded I/O nutzt.

# Anhang: Cheatsheet