# I/O Forensics: Dem Datenstrom auf Block-Ebene folgen

TL;DR / Management Summary Während iostat (Artikel 266) nur Durchschnittswerte liefert, erlaubt uns blktrace, jedes einzelne Ereignis auf dem Block-Layer aufzuzeichnen. Wir sehen exakt, wann eine Applikation einen Block anfordert, wann der Kernel ihn in die Queue schiebt und wann der Controller den Schreibvorgang bestätigt. Ein Senior Admin nutzt blktrace und blkparse, um mikroskopisch kleine Latenz-Probleme zu finden, die in Standard-Statistiken untergehen.

# 1. Einführung & Architektur

Das Trace-Prinzip.

Blktrace klinkt sich direkt in den Block-I/O-Pfad des Kernels ein und nutzt die debugfs Schnittstelle, um Events mit minimalem Overhead auszuspielen.

# Der Event-Lifecycle (Mermaid)

graph TD
    A[App: write request] -->|Q| B[Kernel: Queued]
    B -->|G| C[Kernel: Get request]
    C -->|M| D[Kernel: Merged]
    D -->|D| E[Driver: Issued to Device]
    E -->|C| F[Device: Completed]
    subgraph "blktrace analysis"
        B --- G[Time Difference: Q to D]
        E --- H[Time Difference: D to C]
    end

# 2. Aufzeichnung mit blktrace

Die Jagd beginnt.

# Eine Spur aufzeichnen

# -d: Device, -w: Dauer in Sekunden
sudo blktrace -d /dev/sda -w 10
# Dies erstellt Dateien wie sda.blktrace.0, sda.blktrace.1 (pro CPU-Kern)

# 3. Analyse mit blkparse

Die Rohdaten lesbar machen.

blkparse führt die Dateien der CPU-Kerne zusammen und gibt eine chronologische Liste aus.

# Kombiniert Aufzeichnung und Analyse in Echtzeit
sudo blktrace -d /dev/sda -o - | blkparse -i -

# Die Event-Codes verstehen

• Q: Queued (Befehl in Warteschlange).
• D: Issüd (Befehl an Hardware gesendet).
• C: Completed (Hardware fertig).

# 4. Day-2 Operations: Post-Processing mit btt

Statistiken aus dem Trace generieren.

Nutzen Sie btt (Blktrace Tool), um aus einer massiven Trace-Datei eine lesbare Zusammenfassung der Latenzen zu erhalten.

blkparse -i sda -d sda.bin
btt -i sda.bin
# Zeigt Durchschnittswerte für Q2D, D2C und Seek-Distanzen.

# 5. Troubleshooting & “War Stories”

Wenn der Trace das System überlastet.

# Story 1: “Der hängende Trace-Server”

Symptom: Der Admin startet blktrace auf einem High-Traffic Datenbank-Server. Plötzlich wird der Server unbedienbar, SSH-Sitzungen brechen ab. Ursache: blktrace schreibt seine eigenen Trace-Daten auf die gleiche Disk, die es gerade überwacht. Es entsteht eine Feedback-Schleife (Write-Storm). Lösung: Schreiben Sie die Trace-Files immer auf eine separate physische Disk oder in ein tmpfs (RAM-Disk).

# Story 2: “Das Seek-Chaos”

Symptom: Ein Dateiserver ist langsam, obwohl die Bandbreite ausreicht. Ursache: btt zeigt eine hohe “Average Seek Distance”. Die Dateisystem-Blöcke sind über die gesamte Disk fragmentiert (vor allem bei alten HDDs). Lösung: Defragmentieren Sie das Dateisystem oder migrieren Sie die Daten auf SSDs, bei denen Seek-Distanzen irrelevant sind.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie blktrace nur für akute Problemanalysen. Es erzeugt massiv Daten (GB pro Minute).
• Sicherheit: Das Tool braucht Root-Rechte, da es direkt in den Kernel greift.
• Visualisierung: Nutzen Sie iowatcher, um aus blktrace-Daten grafische Diagramme der Disk-Auslastung zu bauen.

# Anhang: Cheatsheet