sysfs erkunden: Kernel- und Geräteattribute unter /sys

1. Was sysfs ist und wofür es gebraucht wird

sysfs ist ein virtuelles Dateisystem, das der Linux-Kernel seit Version 2.6 unter /sys bereitstellt und in dem jedes intern verwaltete Kernel-Objekt als Verzeichnis oder Datei sichtbar wird. Statt Hardware-Informationen über proprietäre ioctl-Aufrufe oder spezialisierte Bibliotheken abzufragen, liest man einfach eine Textdatei unter /sys, oft mit cat, und bekommt den aktuellen Zustand als lesbaren String zurück. Diese Einheitlichkeit macht sysfs zu einer der wichtigsten Introspektions-Schnittstellen für Systemadministratoren, die Hardware-Zustände ohne Zusatzsoftware prüfen wollen.

Technisch basiert sysfs auf dem kobject-Subsystem des Kernels, das jedes Gerät, jeden Treiber, jedes Bus-Subsystem und jedes Kernel-Modul als strukturiertes Objekt mit Attributen verwaltet. Diese Objekte existieren im Kernel-Speicher, aber sysfs exportiert ihre Attribute als Dateien, sodass Standard-Unix-Werkzeuge wie cat, echo und find zur vollwertigen Verwaltungsoberfläche werden. Für Server-Administration bedeutet das: Wer sysfs lesen kann, versteht direkt vom Kernel, welche Hardware erkannt wurde und in welchem Zustand sie sich befindet.

2. sysfs gegen procfs: eine klare Abgrenzung

Häufig werden sysfs und das ältere procfs unter /proc verwechselt, weil beide virtuelle Dateisysteme sind, die Kernel-Zustand als Textdateien präsentieren. Der zentrale Unterschied liegt im Fokus: procfs entstand primär, um Prozessinformationen offenzulegen, PID-Verzeichnisse, Speicherzuordnungen, offene Dateideskriptoren, und wurde später um allgemeine Systemwerte wie /proc/sys für sysctl-Tuning erweitert. sysfs hingegen wurde von Grund auf für eine einheitliche, hierarchische Abbildung des Geräte- und Treibermodells entworfen.

Ein praktisches Unterscheidungsmerkmal: Wer eine Netzwerkkarte, einen USB-Stick oder einen CPU-Kern als physisches oder logisches Gerät untersuchen will, findet die relevanten Attribute in sysfs unter /sys/class oder /sys/devices. Wer dagegen einen laufenden Prozess untersucht oder einen kernelweiten Tuning-Parameter über sysctl setzt, bleibt in procfs unter /proc. Beide Schnittstellen ergänzen sich, decken aber unterschiedliche Aspekte des Kernel-Zustands ab, und sysfs ist die modernere, klarer strukturierte der beiden für alles rund um Geräte.

3. Die Struktur von /sys systematisch erkunden

Die Verzeichnisstruktur von sysfs folgt einem festen Schema mit mehreren Top-Level-Verzeichnissen, die jeweils eine andere Sicht auf dieselben Kernel-Objekte bieten. /sys/devices enthält die physische Gerätehierarchie exakt so, wie der Kernel sie über Busse wie PCI oder USB entdeckt hat. /sys/class gruppiert Geräte nach Funktion, etwa alle Netzwerkschnittstellen unter net oder alle Block-Devices unter block, unabhängig vom physischen Bus.

# Top-level layout of sysfs
ls /sys
# block  bus  class  dev  devices  firmware  fs  kernel  module  power

# Explore a network interface by function (symlink into /sys/devices)
ls -l /sys/class/net/eth0
readlink -f /sys/class/net/eth0

# Explore the same device by its physical bus location
ls /sys/devices/pci0000:00/*/net/ 2>/dev/null

# List every loaded kernel module and its exposed parameters
ls /sys/module/ | head -10
ls /sys/module/nvme/parameters/

# Find all block devices the kernel currently knows about
ls /sys/class/block/

Der Schlüssel zum Verständnis von sysfs ist, dass fast alle Verzeichnisse unter /sys/class nur Symlinks in die eigentliche Gerätehierarchie unter /sys/devices sind. Mit readlink -f lässt sich jeder dieser Symlinks auf seinen physischen Bus-Pfad zurückführen, was besonders bei Servern mit mehreren identischen Netzwerkkarten oder Storage-Controllern hilft, ein Gerät eindeutig zu identifizieren.

4. Geräteattribute lesen: Power, Storage, Netzwerk

Jedes Gerät in sysfs exportiert eine Reihe von Attributdateien, die den aktuellen Zustand oder statische Eigenschaften beschreiben. Bei Netzwerkschnittstellen zeigen diese Attribute die Verbindungsgeschwindigkeit, den Duplex-Modus und den Betriebszustand, ohne dass ein separates Diagnosewerkzeug nötig wäre. Bei Storage-Geräten liefern sie Größe, Sektorgröße und Warteschlangentiefe direkt aus dem Kernel-Blocklayer.

# Network interface attributes exposed by sysfs
cat /sys/class/net/eth0/speed          # link speed in Mbit/s
cat /sys/class/net/eth0/duplex         # full or half duplex
cat /sys/class/net/eth0/operstate      # up, down, unknown
cat /sys/class/net/eth0/address        # MAC address

# Storage device attributes
cat /sys/class/block/sda/size          # size in 512-byte sectors
cat /sys/class/block/sda/queue/rotational   # 0 = SSD/NVMe, 1 = spinning disk
cat /sys/class/block/sda/device/model  # device model string reported by firmware

# Power management state of a PCI device
cat /sys/bus/pci/devices/0000:00:1f.6/power/control   # "on" or "auto"

# CPU frequency scaling attributes per core
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

Diese Art der Introspektion über sysfs ist besonders bei der Fehlersuche nach Performance-Problemen wertvoll. Ein plötzlich langsames Netzwerkinterface lässt sich über speed und duplex sofort auf einen Autonegotiation-Fehler eingrenzen, ohne dass ein externes Netzwerk-Diagnosewerkzeug installiert werden müsste. Ebenso zeigt rotational, ob ein vermeintliches SSD-Storage-Array tatsächlich als Solid State erkannt wurde oder fälschlich als rotierende Platte behandelt wird, was direkt die I/O-Scheduler-Wahl beeinflusst.

5. Kernel-Modul-Parameter zur Laufzeit über sysfs

Viele Kernel-Module akzeptieren Parameter, die entweder beim Laden über modprobe gesetzt oder für manche Parameter sogar zur Laufzeit über sysfs unter /sys/module/<name>/parameters/ geändert werden können. Ob ein Parameter zur Laufzeit änderbar ist, hängt davon ab, wie der Treiber-Entwickler ihn im Quellcode mit module_param und den entsprechenden Berechtigungsflags deklariert hat.

# Inspect current parameters of a loaded module
ls /sys/module/nvme_core/parameters/
cat /sys/module/nvme_core/parameters/multipath

# Check file permissions to see which parameters are writable at runtime
ls -l /sys/module/nvme_core/parameters/
# -r--r--r-- read-only, cannot change without reload
# -rw-r--r-- writable at runtime

# Change a runtime-writable parameter (example only, verify first!)
echo Y | sudo tee /sys/module/nvme_core/parameters/multipath

# Cross-reference with modinfo to see the parameter description
modinfo -p nvme_core | grep -A2 multipath

Diese Fähigkeit, Modul-Parameter über sysfs ohne Neuladen des Moduls zu prüfen und in vielen Fällen anzupassen, ist besonders bei Storage- und Netzwerktreibern relevant, wo ein Neustart des Dienstes oder gar des Servers unerwünscht wäre. Wichtig ist, die Berechtigungsbits jeder Attributdatei zu prüfen, denn nicht jeder Parameter ist tatsächlich zur Laufzeit schreibbar, manche zeigen nur den beim Laden gesetzten Wert schreibgeschützt an.

6. Block-Device-Tuning über sysfs: Scheduler und Read-Ahead

Eines der praxisrelevantesten Einsatzgebiete von sysfs ist das Tuning von Block-Devices für Datenbank- und Storage-Workloads. Der I/O-Scheduler eines Geräts, die Read-Ahead-Größe und die Warteschlangentiefe lassen sich alle direkt über Dateien unter /sys/class/block/<device>/queue/ ändern, ohne Neustart und ohne spezialisierte Tools.

# Show available and currently selected I/O scheduler
cat /sys/class/block/nvme0n1/queue/scheduler
# [none] mq-deadline kyber

# Switch to a different scheduler for a spinning disk
echo bfq | sudo tee /sys/class/block/sda/queue/scheduler

# Tune read-ahead size (in 512-byte sectors) for sequential workloads
cat /sys/class/block/sda/queue/read_ahead_kb
echo 256 | sudo tee /sys/class/block/sda/queue/read_ahead_kb

# Inspect queue depth for an NVMe device
cat /sys/class/block/nvme0n1/queue/nr_requests

# Make a sysfs tuning value persistent via a udev rule
cat <<'EOF' | sudo tee /etc/udev/rules.d/60-io-scheduler.rules
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="bfq"
ACTION=="add|change", KERNEL=="nvme[0-9]n[0-9]", ATTR{queue/scheduler}="none"
EOF

Änderungen über sysfs sind flüchtig und gehen beim nächsten Neustart verloren, sofern sie nicht wie im Beispiel über eine udev-Regel dauerhaft gemacht werden. Für Datenbankserver mit hoher, zufälliger I/O-Last liefert der Wechsel von einem für rotierende Platten optimierten Scheduler zu none oder mq-deadline auf NVMe-Geräten oft messbare Latenzverbesserungen, die sich direkt über sysfs validieren lassen.

7. udev und sysfs: wie Geräte-Events zusammenspielen

udev, der Geräte-Manager im Userspace, arbeitet eng mit sysfs zusammen. Erkennt der Kernel ein neues Gerät, etwa einen eingesteckten USB-Stick, legt er zuerst die entsprechenden Einträge in sysfs an und sendet dann ein uevent über den Netlink-Socket an udev. udev liest die Attribute aus sysfs aus, wendet passende Regeln an und erzeugt daraus zum Beispiel einen stabilen Gerätenamen unter /dev/disk/by-id/.

Diese Kette macht sysfs zur eigentlichen Datenquelle hinter jeder udev-Regel. Wer eine eigene udev-Regel schreibt, um etwa allen NVMe-Geräten automatisch einen bestimmten I/O-Scheduler zuzuweisen, greift letztlich auf dieselben Attributpfade unter sysfs zu, die auch manuell mit cat und echo les- und schreibbar sind. Das Verständnis von sysfs ist deshalb eine Voraussetzung, um udev-Regeln nicht nur zu kopieren, sondern tatsächlich selbst zu schreiben und zu debuggen.

8. Vorsicht beim Schreiben nach sysfs: Risiken und Praxis

Nicht jede Schreiboperation nach sysfs ist gefahrlos. Manche Attribute lösen beim Schreiben sofortige Hardware-Aktionen aus, etwa das Deaktivieren eines Netzwerkinterfaces oder das Auswerfen eines Storage-Geräts, ohne vorherige Bestätigung oder Undo-Möglichkeit. Auf Produktivservern sollte deshalb jede Änderung an sysfs zunächst auf einem Testsystem verifiziert werden, bevor sie im laufenden Betrieb angewendet wird.

# Always read the current value before writing a new one
cur=$(cat /sys/class/block/sda/queue/scheduler)
echo "Current scheduler setting: $cur"

# Prefer udev rules over one-off manual writes for anything permanent
# so the setting survives reboots and device re-enumeration

# Guard against writing to a non-existent or non-writable attribute
attr="/sys/class/net/eth0/mtu"
if [[ -w "$attr" ]]; then
  echo 9000 | sudo tee "$attr"
else
  echo "Attribute not writable, check permissions or driver support" >&2
fi

# Document every manual sysfs change in a runbook, including the
# exact path, old value and new value for later rollback

Ein weiteres Risiko: Attributpfade unter sysfs sind nicht über Kernel-Versionen hinweg garantiert stabil. Ein Skript, das einen bestimmten Pfad hart codiert, kann nach einem Kernel-Versionsupgrade plötzlich ins Leere laufen, weil sich die Struktur eines Treibers geändert hat. Deshalb gehört zu jeder Automatisierung rund um sysfs eine Existenzprüfung des Pfads, bevor geschrieben wird, und eine Fehlerbehandlung für den Fall, dass sich die Struktur geändert hat.

9. sysfs im Vergleich zu anderen Introspektions-Schnittstellen

sysfs steht nicht isoliert da, sondern konkurriert und ergänzt sich mit mehreren anderen Wegen, Kernel- und Hardwarezustand abzufragen. Die Wahl der richtigen Schnittstelle hängt vom konkreten Anwendungsfall ab.

Für den alltäglichen Server-Betrieb bleibt sysfs die zugänglichste und am besten standardisierte dieser Schnittstellen. Es erfordert keine Spezialwerkzeuge, funktioniert mit jedem Standard-Unix-Befehl und bildet direkt die Struktur ab, die auch udev und viele Monitoring-Tools im Hintergrund auslesen.

10. Zusammenfassung

sysfs bildet die interne Objektstruktur des Linux-Kernels als lesbare Dateihierarchie unter /sys ab und macht damit Geräteattribute, Treiber-Parameter und Kernel-Objekte ohne Spezialwerkzeuge zugänglich. Anders als procfs, das sich primär um Prozesse und generische sysctl-Werte kümmert, konzentriert sich sysfs auf die Geräte- und Treiberhierarchie und bildet damit die Grundlage, auf der auch udev seine Regeln anwendet.

Für den produktiven Einsatz zählen zwei Dinge besonders: Änderungen über sysfs sind standardmäßig flüchtig und müssen über udev-Regeln dauerhaft gemacht werden, und nicht jede Schreiboperation ist risikofrei, weshalb ein Test auf einem Staging-System vor jeder Produktivänderung Pflicht bleibt. Wer diese Regeln beachtet, gewinnt mit sysfs einen direkten, werkzeugfreien Zugang zum tatsächlichen Hardware- und Kernel-Zustand eines Servers.

11. FAQ: sysfs erkunden