# I/O Elevators: Die Geschichte und Mechanik der Daten-Sortierung

TL;DR / Management Summary In der Frühzeit von Linux war die Festplatte der langsamste Teil des Systems. Der Kernel musste Anfragen wie ein Aufzug (Elevator) sortieren, um die Kopfbewegungen der HDD zu minimieren. Mit dem Einzug von SSDs und NVMe wurde diese Sortierung zum Flaschenhals. Ein Senior Admin muss die Evolution vom komplexen CFQ hin zum modernen, parallelen blk-mq (Multi-Queue) verstehen, um alte Optimierungstipps von modernen Best-Practices zu unterscheiden.

# 1. Einführung: Die Elevator-Analogie

Warum wir sortieren mussten.

Eine rotierende HDD ist bei sequenziellen Zugriffen schnell, bei zufälligen Zugriffen (Random I/O) jedoch extrem langsam. Der Scheduler sortierte Anfragen so, dass der Schreib-Lese-Kopf in einer flüssigen Bewegung über die Scheibe gleiten konnte – genau wie ein Aufzug, der Stockwerke der Reihe nach abfährt.

# 2. Die Ära der Single-Queue (Legacy)

NOOP, Deadline, CFQ.

Bis Kernel 3.13 gab es nur eine einzige Warteschlange für alle CPU-Kerne zu einer Disk.

1. NOOP (No-Operation): Keine Sortierung. Ideal für VMs und SSDs (wenig CPU-Last).
2. Deadline: Garantiert eine maximale Wartezeit pro Request. Verhindert das “Verhungern” von Lesezugriffen.
3. CFQ (Completely Fair Queuing): Teilt die Bandbreite gerecht zwischen Prozessen auf. Standard für Desktops über Jahre hinweg.

# Der Flaschenhals (Mermaid)

graph TD
    A[CPU Core 0] --> E{Single Queue Lock}
    B[CPU Core 1] --> E
    C[CPU Core 2] --> E
    D[CPU Core 3] --> E
    E --> F[IO Scheduler: CFQ/Deadline]
    F --> G[Disk Controller]
    style E fill:#f66,stroke:#333

# 3. Die Revolution: Multi-Queue (blk-mq)

Parallelität statt Sperren.

Mit 100-Kern-CPUs und NVMe-Speicher wurde das “Lock” der Single-Queue zum massiven Performance-Killer. Seit Kernel 5.0 ist blk-mq der einzige Standard.

• Architektur: Jeder CPU-Kern (oder Gruppe) hat seine eigene Warteschlange. Daten fließen parallel zum Controller.

# 4. Day-2 Operations: Moderne Schedulers (Scion)

Was heute noch übrig ist.

In der blk-mq Welt gibt es neue Namen für alte Konzepte (siehe Artikel 369):

• mq-deadline: Der Nachfolger von Deadline.
• kyber: Der moderne, skalierbare Scheduler für NVMe/SSD.
• bfq: Der geistige Nachfolger von CFQ, hochkomplex und fair.

# Auswahl-Logik

• HDD: BFQ
• SATA SSD: mq-deadline / kyber
• NVMe: none (Direktzugriff)

# 5. Troubleshooting & “War Stories”

Wenn die alten Tipps das neue System bremsen.

# Story 1: “Der NOOP-Geist”

Symptom: Ein Admin sucht in einem modernen SLES 15 den noop Scheduler für seine SSD, findet ihn aber nicht. Er denkt, das Kernel-Modul fehlt. Ursache: In blk-mq existiert noop nicht mehr. Die Entsprechung ist none. Lösung: Nutzen Sie none für SSDs in virtuellen Umgebungen. Es hat den geringsten Overhead.

# Story 2: “BFQ CPU-Hunger”

Symptom: Ein Fileserver zeigt hohe CPU-Last in den Kernel-Threads, obwohl der I/O-Durchsatz niedrig ist. Ursache: Der Admin hat bfq auf einer sehr schnellen NVMe aktiviert. Die Berechnung der “Fairness” für tausende parallele IOPS kostet mehr CPU-Zeit, als der Scheduler an I/O einspart. Lösung: Deaktivieren Sie komplexe Scheduler bei High-Speed Medien.

# 6. Fazit & Empfehlung

• Wissen: Verstehen Sie, dass moderne Scheduler (blk-mq) für Parallelität gebaut sind.
• Pflicht: Entfernen Sie alte elevator=... Parameter aus Ihren GRUB-Konfigurationen bei Upgrades von Kernel 4.x auf 5.x+.
• Monitoring: Beobachten Sie die Queue Depth Ihrer Hardware via iostat -x.

# Anhang: Cheatsheet