Die Neuerungen von Linux 4.13

Trends & News | Kernel-Log

Der Anfang September erwarte Linux-Kernel 4.13 bringt gleich mehreren Verbesserungen für das Ext4-Dateisystem. Wie bei Microsoft ist SMB3 jetzt Standard. Außerdem kann Linux jetzt kurz- und langlebige Daten unterschiedlich handhaben.

Samstagnacht hat Linus Torvalds die erste Vorabversion von Linux 4.13 veröffentlicht, das in der ersten Septemberhälfte erscheinen dürfte. Knapp zwei Wochen nach dem Erscheinen von Linux 4.12 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.13 geben. Darunter sind ein ganzer Schwung von Verbesserungen rund um die Datenspeicherung.

Verzeichnisse auf Ext4-Dateisystemen sollen statt zirka 10 Millionen Einträgen in Zukunft rund 2 Milliarden Einträge aufnehmen kann. Das ist dem "Largedir Feature" zu verdanken, dass mit den Änderungen am Ext4-Dateisystem zum Kernel stieß; im Begleittext betont der Betreuer der Ext4-Codes allerdings, in der Praxis würden Performance-Problemen auftreten, wenn man so viele Dateien in einem Verzeichnis zu speichern versuche.

Die Largedir-Erweiterung wurde ursprünglich von den Machern des Distributed File Systems (DFS) Lustre programmiert und lässt sich bislang nur mit Entwicklerversionen der Ext-Dateisystemwerkzeuge E2fsprogs aktivieren. Beides gilt auch für ein ebenfalls neues Feature, durch das Ext4 ein erweitertes Attribut (Extended Attribute/EA) in einer eigenen Inode speichern kann. Darauf baut eine weitere Änderung auf, durch die Ext4 solche auch Xattr genannten Attribute zusammenlegen (deduplizieren) kann. Das spart nicht nur Speicherplatz, sondern verbessert Cache-Effekte und damit letztlich auch die Performance.

Für einen Geschwindigkeitszuwachs kann auch eine weitere Änderung sorgen: Ext4 verarbeitet Discard-Operationen jetzt parallel. Solche setzt der Ext4-Code ab, wenn man Dateisysteme mit der Option discard einbindet, um Datenträger gleich beim Löschen von Dateien auf freigewordenen Bereiche hinzuweisen. Bei Tests des Entwicklers reduzierte das neue Vorgehen eine im ungünstigsten Fall auftretenden Wartezeit von 17 Sekunden auf knapp 5 Sekunden. Dieser Werte zeigen ganz nebenbei, zu welchen Latenzen diese Mount-Option führen kann. Wer solche Geschwindigkeitseinbußen vermeiden will, lässt die Mount-Option besser links liegen; stattdessen ruft man besser zu einem günstigen Zeitpunkt fstrim auf, denn auch darüber erfahren SSDs oder mit Thin Provisioning arbeitende Netzwerkspeicher von freigewordenen Bereichen.

Schrittweise aktualisierter Artikel

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

Beim Einbinden von Dateifreigaben von Samba- oder Windows-Servern mit Hilfe des CIFS-Dateisystem nutzt dieses nun standardmäßig Version 3 des Protokolls Server Message Block (SMB) (u. a. 1, 2). Damit folgenden die Entwickler einer Empfehlung von Microsoft und CERT, die vom Einsatz des bislang verwendeten SMBv1 abraten: Dieses auch Common Internet File System/CIFS bekannte Protokoll hat bekannte und nicht so einfach behebbare Schwächen, die jüngst mehrerer Erpressungstrojaner als Verbreitungsvektor genutzt haben. Sollte das modernere Protokoll Probleme bereiten, kann man das CIFS-Code über die Mount-Option vers=1.0 zur Verwendung von SMB1 auffordern. Server-Seitig gibt es schon länger Support für das mächtigere und auch effizientere SMB3: Samba unterstützt es seit Version 4.0 und Microsoft seit Windows 8 und Windows Server 2012.

Die "Lifetime Hints" können den Speicherort beeinflussen. Bild: git.kernel.org

Über eine "Lifetime Hints" genannte Infrastruktur können Programme den Kernel nun wissen lassen, ob die zu speichernden Daten eher von kurz- oder langlebiger Natur sind (1, 2, 3, 4, 5, 6). Die Treiber des Block Layer können mit solchen Tipps besser entscheiden, wo auf dem Datenträger sie die jeweiligen Daten speichern. Das kann Lebensdauer oder die Performance steigern – etwa indem der Treiber kurzlebige Daten in andere Bereiche schreibt als langlebige, denn bei SSDs kann das unnützes Schreiben in Form der "Write amplification" vermeiden. Bislang hört allerdings nur der NVMe-Treiber auf Lifetime Hints. Bei deren Handling interagiert der Treiber über die "Streams Directive" mit der SSD, die zu einer der jetzt unterstützen Directives zählt, die NVMe 1.3 jüngst definiert hat.

Über ein neues Device-Mapper-Target lassen sich jetzt beliebige Dateisystemen auf Festplatten einsetzen, bei denen sich das Betriebssystem um das korrekte Befüllen kümmern kann oder muss. Das ist bei Festplatten der Fall, die mit Shingled Magnetic Recording (SMR) in den Spielarten "Host Aware" oder "Host Managed" arbeiten. Solche produzieren die Plattenhersteller derzeit vornehmlich für Betreiber riesiger Rechenzentren. Die im Einzelhandel verkauften SMR-Festplatten gehören in eine dritte Klasse: Sie sind "Drive Managed", damit Betriebssysteme sie wie klassische Festplatten ansprechen können.

SMR-Festplatten gibt es in drei Spielarten. Bild: Vortragsfolie von Damien Le Moal/Western Digital

Besonders wichtig ist das neue Target für Host-Managed-Platten. Genau wie andere SMR-Festplatten haben diese meist zwei unterschiedliche Bereiche. In dem einen gibt es oft 256 MByte große "Speicherbänder", die das Betriebssystem sequenziell füllen muss, denn dort packt die Festplatte die Bits enger nebeneinander. Dadurch steigt die Kapazität, weil mehr Daten auf die gleiche Fläche passen. Allerdings muss der komplette Bereich neu geschrieben werden, wenn auch nur ein bereits geschriebenes Bits geändert werden soll. Genau das stellt das neue Device-Mapper-Target sicher. Dabei versucht es allerdings ein Neuschreiben von Speicherbändern zu vermeiden, weil das zu Performance-Einbrüchen führt. Sich häufiger ändernde Daten versucht es daher von vornherein in den zweiten Bereich von SMR-Festplatten anzulegen. Dieser funktioniert wie bei klassischen Festplatten, daher muss dort nur ein meist 4 KByte großer Block neu geschrieben werden, wenn bereits geschriebene Daten verändert werden.

Bei Drive-Managed-Platten kümmert sich deren Firmware um die nötigen Aufgaben. Bei Host-Aware-Platten kann sie das auch. Dort kann es aber auch das Betriebssystem erledigen – im Fall von Linux eben mit dem neuen Device-Mapper-Targets. Das dürfte vielfach eine bessere Performance erzielen, weil es mehr über die zu speichernden Daten weiß.

Gängige Dateisysteme sollen mittelfristig Anpassungen für SMR-Platten erhalten. Bild: Vortragsfolie von Damien Le Moal/Western Digital

Die Dokumentation zu Dm-Zoned erläutert die Arbeitsweise und Einsatz des neuen Device-Mapper-Targets (1, 2, 3, 4). Dessen federführender Entwickler liefert einige weitere Details zum Einsatz von SMR-Festplatten unter Linux in den Folien zweier Vorträge, die er im letzten Jahr gehalten hat (1, 2). Dort führt er etwa an, dass sich die beste Performance mit Dateisystemen erzielen lässt, die von vornherein auf die Eigenarten von Host-Managed- oder Host-Aware-Festplatten achten. Bislang kann das nur F2FS (Flash-Friendly File System). Die Arbeitsweise dieses "Log-structured File System" birgt aber Tücken, die sich negativ auf die Performance auswirken, sobald die Platte einmal gefüllt war. Mit einigen angedachten oder bereits in Arbeit befindlichen Änderungen für Btrfs, Ext4 und XFS dürften sich diese Dateisysteme vermutlich langfristig zur besten Lösung entwickeln.

Das neue "Nowait AIO" senkt das Risiko, dass Programme auf einen Rücksprung vom Kernel warten, wenn sie asynchrone I/O-Operationen (Asynchronous I/O bzw. AIO) mit Hilfe von Direct I/O ausführen (1, 2, 3, 4, 5, 6, 7). Bei einer ordentlichen AIO-Implementierung sollte genau das eigentlich gar nicht passieren – es gibt aber Umgebungsbedingungen, wo der Kernel eben doch blockt. Die Änderungen beseitigen einige der häufiger mal auftretenden Situationen, bei denen das der Fall ist. Es gibt aber noch einige andere in der AIO-Unterstützung von Linux, die seit Jahren bekannte Schwächen aufweist. Details hierzu und den vorgenommenen Änderungen erläutert ein jüngst bei LWN.net veröffentlichter Artikel.

Die neuen Error-Codes im Block Layer. Bild: git.kernel.org

Unter den wichtigsten Änderungen am Block Layer (1, 2) waren Umbauten am Code, der Schreib- oder Leser-Fehler an höhere Schichten zurückmeldet (u. a. 1, 2). Dateisysteme und Anwendungen könne dadurch jetzt mehr über die Art aufgetretener Fehler erfahren, denn bislang erhielten sie in vielen Fällen nur einen vagen "EIO (I/O error)"; Software blieb daher manchmal nichts anderes übrig bleibt, als unwissend aufzugeben oder es einfach nochmal zu probieren. Den neuen Ansatz soll andere Teile des Kernels und letztlich auch Anwendungen ermöglichen, einige Fehlersituationen galanter abzufangen. Details hierzu erläutert ein LWN.net-Artikel.

Dieser und ein früherer Artikel erwähnen auch Änderungen am Writeback-Code, die jetzt in den Kernel eingeflossen sind. Anwendungen könne durch diese Änderungen besser erfahren, falls beim Wegschreiben von im Writeback-Cache zwischengespeicherter Daten ein Problem auftritt (u. a. 1, 2, 3).

Das SCSI-Subsystem unterstützt nun selbstverschlüsselnden SSD, die die Opal Storage Specification der Trusted Computing Group (TCG) implementieren. Damit werden jetzt auch per ATA angebundene OPAL-SSDs unterstützt, weil der Treiber für moderne ATA-Adapter nach AHCI-Standard auf dem SCSI-Code aufbaut. Die Basis-Infrastruktur zum Support solcher Self-Encrypting Drives (SED) war bereits in Linux 4.11 eingeflossen.

Die Entwickler haben die Implementation von statx() bei Btrfs, F2FS und UBIFS verbessert, damit die beiden Dateisysteme über den bei Linux 4.11 eingeführten Funktionsaufruf nun auch Informationen wie "wann wurde der Dateisystemeintrag erzeugt" liefern.

Kernel-Log zu Linux 4.13

Am 16. Juli hat Linus Torvalds die erste Vorabversion von Linux 4.13 freigegeben. Damit hat er die "Merge Window" genannte Phase des Entwicklungszyklus abgeschlossen, in der er alle wesentlichen Änderungen für eine neue Kernel-Version einpflegt. Größere, erwähnenswerte Änderungen passieren danach nur noch in Ausnahmefällen. Das Kernel-Log kann daher schon jetzt einen Überblick über die wichtigsten Neuerungen des Linux-Kernels 4.13 liefern, der am 4. oder 11. September erscheinen dürfte.

Unter den Änderungen an XFS warten Grundlagen, durch die sich die Datenträger mit der neuesten Varianten des Dateisystems bald zur Laufzeit prüfen und korrigieren lassen sollen ("online fsck").

Das vorwiegend auf Flash-Datenträger von Smartphones und Tablets ausgerichtete F2FS (Flash-Friendly File System) beherrscht jetzt User- und Gruppen-Quoten.

Btrfs erhielt einige Detailverbesserungen; darunter etwa eine Funktion, durch die mit CAP_SYS_RESOURCE gekennzeichnete Programme kurzzeitig ein Speicherplatzlimit (Quota) überschreiten dürfen (1, 2)

Der unter anderem von Ext4 und F2FS genutzte Code zur Verschlüsselung durch das Dateisystem kann statt 256-bit AES nun auch 128-bit AES nutzen. Das soll einige besonders stromsparenden Embedded-Prozessoren entgegenkommen, denn sie handhaben das 128-Bit-Variate deutlich effizienter.

Änderungen an Overlayfs verbessern die Handhabung von Hardlinks. Außerdem bringen sie eine Infrastruktur, um übereinander gelegte Dateisysteme per NFS zu exportieren.

Neben den erwähnten Änderungen gab es noch zahlreiche weitere, die die Kommentare der Merge-Window-Commits zu den Dateisystemen CIFS (1, 2), F2FS, GFS2, NFS, NFSd und UBIFS nennen. Auch bei Ceph, Device Mapper, Libata, Libnvdimm, MD, MTD, Pstore, SCSI, Target, und UUID gab es noch allerlei Neuerungen.

Kernel-
Version
Anzahl
Dateien¹
Zeilen
Quelltext
(Ohne Doku)²
Entwick-
lungs-
zeitraum
Commits
(Ohne
Merges)³
Diffstat⁴
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 59.845 24.170.860
(22.125.075)
63 Tage 15.736
(14.570)
12.531 files changed,
1.342.677 insertions(+),
309.204 deletions(-)
Linux 4.13-rc1 60.557 24.762.271
(22.684.399)
n. n. 12.051
(11.258)
10.164 files changed,
850.609 insertions(+),
259.194 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 obige Text Artikel wird zwischen Freigabe der ersten Vorabversion und Fertigstellung von Linux 4.13 mehrfach erweitert, um schrittweise alle wichtigen Änderungen der neuen Kernel-Version zu erläutern. Einmal publizierte Absätze ändern wir nur bei triftigen Gründe; zur Freigabe des neuen Linux stellen wir den Text allerdings um, damit Absätze zu den wichtigsten Neuerungen am Anfang stehen.

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

Kommentare

Anzeige