Die Neuerungen von Linux 4.4

Seite 4: Verbesserungen an Btrfs, NFS, eBPF und KVM

Inhaltsverzeichnis

Facebook-Entwickler haben die Prozessorlast beim Einsatz der Btrfs-Mount-Option ssd_spread reduziert (u. a. 1, 2, 3). Zuvor hatten sie festgestellt, dass die darüber aktivierte Datenverteilungsmethode die Performance bei ihren Hardware-RAIDs der Level 5 und 6 erheblich verbessert.

Der NFS-Clientcode unterstützt jetzt die NFS-4.2-Operation "CLONE", mit der sich Dateien oder Dateibereiche innerhalb eines NFS-Shares serverseitig kopieren lassen – also ohne die Dateinhalte von Server an den Client und wieder zurück übertragen zu müssen (1, 2). Die dazu verwendeten Funktionsaufruf sind jenen nachempfunden, die das Btrfs-Dateisystem bietet; auf sie greift etwa cp --reflink zurück, um Dateien innerhalb eines Btrfs-Volumes zu kopieren, ohne deren Inhalte zu duplizieren.

Der Code zum Mounten von Dateisystemen über Loop-Devices beherrscht jetzt Direct I/O (DIO) und Asynchronous I/O (AIO), was die Geschwindigkeit steigern und Overhead reduzieren soll.

Die bei Linux 4.1 integrierte Unterstützung zum Clustern eines MD-RAID 1 soll jetzt nahezu komplett sein; über diese noch experimentelle Funktion soll sich ein RAID 1 auf einem zweiten Rechner spiegeln lassen, damit die auf dem RAID enthaltenen Daten auch erreichbar bleiben, wenn einer der beiden Rechner ausfällt.

Block-Layer sowie SCSI-, NVMe- und Device-Mapper-Code beherrschen jetzt Persistent Reservations (PRs). Diese in SCSI-3 und SCSI-4 definierten Technik wird vornehmlich in High-Availability-Clustern eingesetzt, um einzelnen Clients exklusiven Zugriff auf bestimmte Datenträgerbereiche (I/O Fencing) und zugleich Ausfallsicherheit mit Failover und Retakeover zu bieten.

Der Kernel und sein eigener Hypervisor KVM unterstützen nun eine "VT-d posted interrupts" oder "Hardware-Interrupt-Bypass" genannten Funktion, bei der das System einen Interrupt direkt an eine vorher festgelegte virtuelle Maschine sendet (u. a. 1, 2, 3, 4, 5, 4). Das vermeidet Overhead und steigert die Geschwindigkeit, da seltener vom Gast in den Host und zurück gewechselt werden muss.

Auch unprivilegierte Anwendungen können nun vom eBPF (extended Berkeley Packet Filter) ausgeführte Programme in den Kernel laden, um damit Datenströme zu verarbeiten, die durch den Kernel fließen. Dadurch kann beispielsweise ein nicht von Root ausgeführtes Tcpdump in Zukunft einen eBPF-Filter beim Kernel hinterlegen, damit der nur die Netzwerkpakete an den Sniffer weitergibt, die der Nutzer untersuchen will. Von unprivilegierten Anwendern stammende eBPF-Programme unterliegen allerdings einigen Einschränkungen, damit Angreifer den eBPF-Interpreter nicht missbrauchen; Details hierzu erläutert LWN.net.

Anwendungen können eBPF-Programme und von ihnen verwendete Datenstrukturen nun persistent im Kernel hinterlegen, damit diese auch nach Beenden der Anwendungen verfügbar bleiben und von anderen Programmen wieder aufgegriffen werden können (siehe u. a. 1, 2 sowie LWN.net). Das zur IP-Werkzeugsammlung Iproute2 gehörende Programm tc (Traffic Control) will das nutzen, um eBPF-Daten zwischen mehreren Classifiern und Actions zu teilen. Dadurch könnte man mit dem Programm beispielsweise einen Load-Balancer mit eBPF Classifier bauen, eine simple Firewall programmieren oder einen einfachen Connection-Tracker realisieren, was vor allem beim Einsatz in größeren Rechenzentren interessant sein kann. Im Entwicklerzweig von Iproute2 enthaltene Code greift auf die neue Kernel-Funktion bereits zurück (1, 2, 3, 4, 5); diese Änderungen sollen Bestandteil von Iproute2 4.4 werden, das im Fahrwasser von Linux 4.4 erscheinen soll.

Unabhängig von den anderen eBPF-Änderungen haben die Entwickler das Performance-Analyse-Werkzeug Perf erweitert, damit es eBPF-Programme automatisch bauen, prüfen und in den Kernel laden kann (u. a. 1, 2, 3, 4, 5). Über solche Programme kann der Kernel irrelevante Informationen zu Vorgängen im System frühzeitig ausfiltern, was Overhead und Störeinfluss der Analyse reduziert.