Die Neuerungen von Linux 4.12

Trends & News | Kernel-Log

Der im Juli erwartete Linux-Kernel erhält einen I/O-Scheduler, der in Tuning-Kreisen schon lange einen guten Ruf hat. Neu in 4.12 ist auch eine Technik, um Datenverfälschungen bei Abstürzen mit RAIDs zu verhindern. Bei Btrfs und Ext4 gibt es einige Optimierungen und Fehlerkorrekturen.

Samstagnacht hat Linus Torvalds die erste Vorabversion von Linux 4.12 veröffentlicht, das am 3. oder 10. Juli erscheinen sollte. Knapp zwei Wochen nach dem Erscheinen von Linux 4.11 stehen damit alle wesentlichen Neuerungen des Nachfolgers fest. Das Kernel-Log der c't kann daher bereits jetzt einen Einblick in die wichtigsten Neuerungen der Kernel-Version 4.12 geben. Darunter sind ein ganzer Schwung von Verbesserungen zum Speichern von Daten.

Der neue Storage-I/O Scheduler "Budget Fair Queueing" (BFQ) verspricht, die Performance von Datenträgern zu steigern. Dabei hängt allerdings vom Datenträger, den eingesetzten Programmen und den Zugriffsmustern ab, ob der Scheduler letztlich die Geschwindigkeit steigert. Am ehesten dürften sich Vorteile bei klassischen Magnetfestplatten zeigen; bei schnellen SSDs dürfte er hingegen kontra-produktiv sein.

Der vornehmlich auf Desktop-Systeme ausgerichtete BFQ teilt den Prozessen ein I/O-Budget zu und nutzt eine Reihe von Tricks, um das System möglichst reaktionsschnell zu machen. So bevorzugt BFQ beispielsweise Leseoperationen, denn auf deren Ergebnis warten Nutzer oftmals. Auch I/O-Operationen von als Echtzeit markierten Prozessen erhalten eine höhere Priorität. Ferner räumt BFQ den Lese- und Schreiboperationen von Programmen, mit denen der Anwender zu interagieren scheint, eine höhere Priorität ein. Das soll die Reaktionsfreude der darunter laufenden Programme steigern; wirkt sich aber zugleich zu Ungunsten von Hintergrundprozessen aus, die beispielsweise Code kompilieren, eine Datenbank bereithalten oder den Datenträger indexieren. Ferner sammelt BFQ die einlaufenden Lese- und Schreiboperationen kurzzeitig, um sie dann nach Möglichkeit zu bündeln und in einer optimierten Reihenfolge an die Festplatte zu schicken.

Das ist lediglich eine sehr kurze und grobe Beschreibung von BFQ, das mit zahlreichen Heuristiken arbeitet. In Tuning-Kreisen hat der seit mehreren Jahren unabhängig vom offiziellen Kernel entwickelte Scheduler schon länger einen sehr guten Ruf. Gerade bei Magnetfestplatten soll er spürbare Leistungsgewinne erzielen. Auch bei SSDs soll er in bestimmten Situationen die Geschwindigkeit steigern. Aktuelle SSDs sind aber so schnell, dass BFQ allenfalls in bestimmten Situationen von Vorteil sein dürfte: Der von BFQ betriebene Optimierungsaufwand kostet halt Zeit und Prozessorressourcen, die bei schnellen Datenträgern letztlich die Performance reduzieren.

BFQ standardmäßig oft inaktiv

BFQ ist eine Weiterentwicklung des Storage I/O-Schedulers "Completely Fair Queuing" (CFQ), den viele Distributionen seit Jahren standardmäßig nutzen. Das wird vorerst bei vielen Systemen mit Festplatten auch weiterhin so sein, denn beim jetzt in den Kernel integrierten BFQ-Code handelt es sich um eine überarbeitete Variante des klassischen BFQ. Diese Variante baut auf dem in Linux 3.17 integrierten Multi-Queue Block IO Queueing Mechanism (Blk-Mq) auf. Zum Zugriff auf SATA-Festplatten verwenden Linux-Distributionen aber typischerweise Storage-Treiber wie "Ahci". Diese wiederum nutzen derzeit noch die klassische Block-Layer-Infrastruktur, bei der sich CFQ einklinkt.

Sie können BFQ aber leicht auf vielen Systemen mit Festplatten einsetzen, indem Sie Ahci anweisen, Blk-Mq zu nutzen. Dazu müssen Sie lediglich den Kernel mit dem Parameter scsi_mod.use_blk_mq=y starten oder beim Erstellen des Kernels die Konfigurations-Option SCSI_MQ_DEFAULT setzen. Das wird vermutlich schon bei einer der nächsten Kernel-Versionen nicht mehr nötig sein, denn aus Entwicklerkreisen konnte der Kernel-Log-Autor erfahren, dass Ahci bald standardmäßig auf Blk-Mq zurückgreifen soll. So oder so: Damit BFQ genutzt wird, muss man ihn explizit aktivieren. Das ist bei jedem Datenträger einzeln nötig und gelingt über Dateien wie /sys/block/sda/queue/scheduler.

Die Infrastruktur, über die sich BFQ in Blk-Mq einklinkt, wurde erst mit Linux 4.11 geschaffen. Über sie dockt auch ein weiterer Storage-I/O Scheduler an, der mit 4.12 zum Kernel stößt: Der maßgeblich von Facebook-Mitarbeitern entwickelte Kyber, der viel simpler als BFQ arbeitet. Er zielt auf ein ganz anderes Einsatzgebiet: Server mit besonders schnellen Datenträgern, die mit mehreren Warteschlangen arbeiten – beispielsweise per PCIe angebundene NVMe-SSDs. Mit Hilfe der verschiedenen Queues arbeitet Kyber darauf hin, Leseoperationen dort eher auszuführen als Schreiboperationen. Das kann Wartezeiten reduzieren und Systeme reaktionsfreudiger machen, denn Lesen passiert oftmals, weil ein lokaler oder entfernter Nutzer die Daten abruft und daher auf diese wartet. Schreiben erfolgt hingegen bei vielen Programmen asynchron; daher fällt Anwendern eine kleine Verzögerung nicht so leicht auf. Damit es lediglich eine unmerkliche Verzögerung bleibt, erledigt Kyber die Schreiboperationen nach einer Weile aber trotzdem, selbst wenn noch viele Leseoperationen anstehen. Wie bei BFQ lässt sich das Verhalten von Kyber über Dateien in Sysfs an die individuellen Ansprüche und den jeweiligen Workload anpassen.

Schrittweise aktualisierter Artikel

Dieser Text wird in den nächsten Wochen mehrfach erweitert, um nach und nach die wesentlichen Änderungen von Linux 4.12 zu beschreiben. Vor die Abschnitte mit bislang beschriebenen Neuheiten werden wir noch Absätze stellen, die Neuerungen bei Grafiktreibern, Netzwerkfunktionen, Architektur-Unterstützung, Kernel-Infrastruktur und Sicherheit beschreiben. Details zur Versionshistorie des Artikels finden Sie am Artikelende.

Details finden sich im Commit-Kommentar zu Kyber und einer Mail aus dessen Begutachtungsphase. Hintergründe zu BFQ liefern einige Commits (u. a. 1, 2, 3, 4, 5) und die Homepage von BFQ, die auch einige Benchmark-Ergebnisse enthält. Ferner findet sich bei LWN.net ein Artikel zu BFQ und Kyber, der die Ansätze grob umreißt. Die nächsten Monate müssen zeigen, wie sich die beiden in der Praxis schlagen. Wie bei neuem Kernel-Code üblich, dürften beide I/O Scheduler noch ein wenig Feintuning benötigen, bevor sie richtig rund laufen.

Mit dem "Partial Parity Log for MD RAID 5" (RAID5-PPL) bringt der Kernel jetzt eine zweite Technik, um die Integrität eines RAID-5-Verbunds auch bei Abstürzen hundertprozentig zu gewährleisten (u. a. 1, 2, 3, 4, Dokumentation). Solche können durch das sogenannte "Write Hole" zu Datenschäden führen, falls der Kernel neue Daten schreibt, diese aber durch den Absturz nicht komplett auf den am Verbund beteiligten Datenträgern landen. Die Paritätsdaten passen dann nicht zu den bereits geschriebenen Daten; falls nach dem Absturz ein Datenträger des RAID fehlen sollte, verfälscht der Rebuild in dem Bereich die Daten.

Die RAID5-PPL schützt dagegen, indem es beim Schreiben einige zusätzliche Informationen speichert, mit denen es den beschriebenen Fall abfangen kann. Das macht Arbeit; daher geht das Ganze zu Lasten der Geschwindigkeit. Laut dem federführenden Entwickler sinkt die Performance um bis zu 30 bis 40 Prozent. Diesen Nachteil nehmen einige Nutzer dennoch in Kauf, um die Daten in Sicherheit zu wiegen.

Alternativ kann man das mit dem Log-Device erreichen, mit dem man sich seit Linux 4.4 vor dem Write Hole schützen kann. Dessen Nachteil: Man muss das RAID mit einem weiteren Datenträger koppeln, auf dem der RAID-Code ein Journal führt. Seit Linux 4.10 kann dieses Log-Device aber zugleich auch als Write-Back-Cache nutzen und so die Performance des Verbunds sogar steigern.

RAID5-PPL stammt von Intel-Entwicklern und ging aus einer Funktion hervor, die die Windows-Treiber für Intels Rapid Storage Technology (RST) bei der neuen Xeon-Platform bieten soll. Bei RST funktioniert sie nur dort; die in Linux eingeflossene Implementierung ist kompatibel zu jener von Intel, arbeitet aber auf beliebiger Hardware.

Linux kann jetzt erkennen, wenn verschlüsselte Volumes manipuliert wurden.

Das neue Device-Mapper-Target "dm-integrity" stellt ein Block Device bereit, das zu jedem gespeicherten Sektor einige Metadaten für spätere Integritätsprüfungen speichert. Das Device-Mapper-Target sorgt dabei für Atomic Updates, damit Nutz- und Metadaten garantiert zusammenpassen, selbst wenn eine Schreiboperation durch einen Absturz unterbrochen wird (1, 2). Zusammen mit der ebenfalls neuen Cryptographic Data Integrity Protection gelingt so Authenticated Encryption (AE). Durch diese kann der Kernel warnen, wenn Blöcke eines verschlüsselten Volumes ohne den passenden Schlüssel modifiziert wurden (u. a. 1, 2, 3).

Ferner gab es einige Optimierungen am Device Mapper, auf den Cryptsetup oder der Logical Volume Manager (LVM) zurückgreifen (1, 2). Eine der Umbauten verspricht Latenzen beim Dm-Cache-Target zu reduzieren, mit dem sich ein SSD-Cache vor Festplatten oder Netzwerklaufwerke schalten lässt. Über die auf den MD-Code zurückgreifende RAID-Implementation des Device Mappers lässt sich nun auch die Cache-Funktion eines Log-Device aktivieren.

Mit den Änderungen am MD-Subsystem stießen einige Patches zum Kernel, die die Performance von Festplatten-Verbünden der RAID-Level 5 oder 6 steigern sollen (u. a. 1, 2). Einige andere Anpassungen versprechen zudem, ein RAID-5-Recovery zu beschleunigen (u. a. 1).

Über das "Pblk" Target kann man nun über ein normales Blockdevice auf Open-Channel SSD zugreifen. Anders als normale SSDs haben diese eher exotischen SSDs kein Flash Translation Layer (FTL), daher muss der Kernel die davon erledigten Aufgaben wie das Wear Leveling selbst behandeln. Diese Aufgabe hat das LightNVM-Framework, das bei Linux 4.4 zum Kernel stieß.

Unter den Änderungen am Block Layer (1, 2, 3) waren noch eine Reihe weitere Features, darunter einige am Blk-Throttle. Mit diesem Control Groups (Cgroup) Controller lässt sich regeln, wie viele I/O-Ressourcen die Prozesse eines Systems nutzen dürfen. Durch die Änderungen gibt es eine Reihe neuer Einstellmöglichkeiten, die eine skalierbare Priorisierung ermöglichen (u. a. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10).

Unter anderem für Datenintegritätstests ist der neue I/O-Control (Ioctl) "GETFSMAP" gedacht, den Ext4 und XFS jetzt beherrschen (1, 2, XFS, Ext, Man-Page). Programme können darüber beim Dateisystem erfragen, wie es seine Blöcke nutzt. Darüber lassen sich leere Bereiche erkennen, aber auch abklären, ob dort Meta- oder Nutzdaten liegen. Ferner lässt sich feststellen, welche Nutzdaten zu welchen Dateien gehören.

Mit diesen Informationen können Programme beispielsweise eine Liste aller für Nutzdaten verwendeten Blöcke erhalten, um diese dann sequenziell auszulesen und dabei auf Lesefehler zu prüfen. Sollten welche auftreten, kann das Check-Programm ausgeben, welche Dateien davon betroffen sind. Das ist eine der Funktionen, auf die das noch in Entwicklung befindliche Online-Scrubbing-Tool zurückgreifen soll, das XFS-Dateisystem im Betrieb auf Fehler untersucht. Das gelingt aber nur mit den seit Linux 4.8 unterstützten Dateisystemstrukturen, die seit Linux 4.9 Funktionen wie COW (Copy-on-Write) ermöglichen.

Vergrößern Der RAID-5/6-Code von Btrfs gilt nach wie vor als unausgereift.Bild: Btrfs-Wiki

Einige der Änderungen an Btrfs beseitigen bekannte Probleme und Funktionslücken bei der Dateisystem-eigenen Implementation von RAID 5 und 6. Das ist eine der Funktionen von Btrfs, die nach wie vor als instabil gilt.

Zwischen den Umbauten am Ext4-Dateisystem verstecken sich einige, die die Performance großer Dateisystemen verbessern sollen. Auch Workloads mit verteilten Schreiboperationen (random write) sollen zulegen.

Einige Umbauten gab es auch beim CIFS-Dateisystem, mit dem sich Dateifreigaben von macOS, Samba oder Windows einbinden lassen. Darunter finden sich einige, die asynchrones I/O beschleunigen (u. a. 1, 2, 3). Die Kernel-Entwickler haben ferner eine Inkompatibilität beseitigt, durch die sich SMB-Freigaben von macOS manchmal nicht mounten ließen.

Details zu weiteren Neuerungen rund um Datenspeicherung und Dateisystemen finden sich in den Kommentaren zu den Commits, die die wesentlichsten Neuerungen bei Ceph, Fuse, F2FS, Fsnotify, GFS2, Libnvdimm (1, 2, MMC, MTD, NFS, NFSd, Orangefs, Overlayfs, Pstore, SCSI, SCSI Target, UBIFS und XFS beschreiben.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
Linux 4.5 52.916 21.154.659
(19.489.725)
63 Tage 13.173
(12.080)
11.590 files changed,
1.146.355 insertions(+),
854.286 deletions(-)
Linux 4.6 53.660 21.422.808
(19.724.413)
63 Tage 14.618
(13.517)
10.250 files changed,
606.023 insertions(+),
337.875 deletions(-)
Linux 4.7 54.400 21.720.955
(19.971.725)
70 Tage 13.433
(12.283)
9909 files changed,
575.816 insertions(+),
277.305 deletions(-)
Linux 4.8 55.503 22.071.048
(20.266.168)
70 Tage 14.552
(13.382)
11.483 files changed,
662.558 insertions(+),
314.177 deletions(-)
Linux 4.9 56.223 22.348.356
(20.520.460)
70 Tage 17.392
(16.214)
11.416 files changed,
713.497 insertions(+),
436.209 deletions(-)
Linux 4.10 57.202 22.839.659
(20.864.595)
70 Tage 14.249
(13.029)
11.913 files changed,
806.420 insertions(+),
312.218 deletions(-)
Linux 4.11 57.994 23.137.402
(21.132.076)
70 Tage 13.891
(12.724)
12.528 files changed,
550.108 insertions(+),
252.364 deletions(-)
Linux 4.12-rc1 59.835 24.162.964
(22.118.093)
n. n. 13.729
(12.920)
11.921 files changed,
1.326.540 insertions(+),
300.967 deletions(-)
¹ git ls-tree -r --name-only HEAD | wc -l
² find . -type f -not -regex '\./\.git/.*' | xargs cat | wc -l; echo "($(find . -name *.[hcS] -not -regex '\./\.git/.*' | xargs cat | wc -l))"
³ git-log --pretty=oneline vx.(y-1)..vx.(y) | wc -l; echo "($(git-log --pretty=oneline --no-merges vx.(y-1)..vx.(y) | wc -l))"
⁴ git diff --shortstat vx.(y-1)..vx.(y)

(thl)

Versionshistorie dieses Artikels

Der nebenstehende Text Artikel wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.12 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze werden nur verändert, wenn triftige Gründe es erfordern; zur Freigabe des neuen Kernels werden wir den Text aber umstellen, damit die wichtigsten Informationen vorne stehen.

  • 2017-05-15, 07:00 – v1.0: Erste Version, die sich auf die Neuerungen bei Storage-Support und Dateisystemen konzentriert.

Kommentare

Anzeige