# Block Device Mastery: Den Weg zum Sektor verstehen

TL;DR / Management Summary In Linux ist eine Festplatte nicht einfach ein Speicherort, sondern ein Block Device. Der Kernel abstrahiert die physische Hardware über Treiber in ein einheitliches Interface unter /dev/. Ein Senior Admin muss den Weg des Datenpakets vom Dateisystem über den Block-Layer bis zum Treiber verstehen und wissen, wie er mittels udev-Regeln Hardware-Events (z.B. Einstecken einer neuen Disk) automatisiert verarbeitet.

# 1. Einführung & Architektur

Vom Device-File zum NAND.

Linux unterscheidet zwischen Character Devices (Stream-basiert, z.B. /dev/tty) und Block Devices (Sektor-basiert, z.B. /dev/sda).

# Der Block-Stack (Mermaid)

graph TD
    A[App: open/write] --> B[VFS: Virtual File System]
    B --> C[Filesystem: Ext4 / XFS]
    C --> D[Block Layer: Bio / Request]
    D --> E[IO Scheduler: mq-deadline]
    E --> F[Driver: nvme / sd]
    F --> G[Hardware Controller]
    subgraph "Device Management"
        H[Kernel Event] --> I[udevd: Create /dev/ entry]
        I --> J[Apply Rules & Permissions]
    end
    G --> H

# 2. udev: Die Event-Zentrale

Hardware-Dynamik bändigen.

Der udevd Dienst sorgt dafür, dass Geräte beim Einstecken den korrekten Namen und die richtigen Berechtigungen erhalten.

# Beispiel: Eigene udev-Regel für eine SSD

Wir wollen, dass eine bestimmte Disk immer den Namen /dev/backup_disk erhält. Datei: /etc/udev/rules.d/10-local-storage.rules

SUBSYSTEM=="block", ATTR{ID_SERIAL}=="SAMSUNG_12345", SYMLINK+="backup_disk"

Aktivieren mit: sudo udevadm control --reload-rules && sudo udevadm trigger.

# 3. Treiber-Diagnose

Wer spricht mit der Hardware?

Nutzen Sie modinfo, um Informationen über den aktiven Treiber zu erhalten.

# Welcher Treiber verwaltet meine NVMe?
sudo readlink /sys/class/block/nvme0n1/device/driver
# Output: ../../../bus/pci/drivers/nvme

# 4. Day-2 Operations: Low-Level Tuning

Hardware-Limits prüfen.

# ethtool (für NICs) und blockdev (für Disks)

# Read-Ahead optimieren (Puffer für sequenzielles Lesen)
sudo blockdev --setra 4096 /dev/sda

# Device-Capabilities prüfen
sudo blockdev --getsz /dev/sda # Anzahl Sektoren

# 5. Troubleshooting & “War Stories”

Wenn das Device verschwindet.

# Story 1: “Das Phantom-Interface”

Symptom: Eine Netzwerkkarte heißt nach einem Austausch plötzlich eth1 statt eth0, obwohl nur eine Karte im System ist. Ursache: Alte udev-Regeln (oft in /etc/udev/rules.d/70-persistent-net.rules) haben die MAC-Adresse der alten Karte fest an den Namen eth0 gebunden. Lösung: Löschen Sie die veraltete Regel-Datei und starten Sie neu. Der Kernel vergibt dann wieder den ersten freien Namen (oder nutzt moderne ‘Predictable Names’).

# Story 2: “Der Read-Only Mount durch Disk-Fehler”

Symptom: Das Dateisystem schaltet sich plötzlich auf Read-Only um. Applikationen crashen. Ursache: Der Block-Layer hat einen Hardware-Fehler gemeldet. Das Dateisystem (z.B. Ext4) reagiert darauf mit einem Schutz-Remount. Lösung: Prüfen Sie die Hardware-Fehler via SMART: sudo smartctl -a /dev/sda. Suchen Sie nach “Reallocated Sectors”. Falls vorhanden: Disk sofort tauschen.

# 6. Fazit & Empfehlung

• Wartung: Nutzen Sie immer WWIDs oder UUIDs in der /etc/fstab, niemals die Namen /dev/sdX, da sich diese bei jedem Boot ändern können.
• Wahl: Nutzen Sie udev-Regeln zur Automatisierung (z.B. für das Setzen von I/O-Schedulern, siehe Artikel 369).
• Sicherheit: Überwachen Sie udev-Events mit udevadm monitor, um unautorisierte Hardware-Eingriffe zu erkennen.

# Anhang: Cheatsheet