Linux 5.2: Ext4-Dateisystem kann jetzt Groß- und Kleinschreibung ignorieren Update

Linux Kernel 5.2

Trends & News | Kernel-Log

Der nächste Linux-Kernel verspricht den Datenträgerzugriff zu beschleunigen. Die Wine-Entwickler haben sich auf eine neue, aber umstrittene Funktion des Ext4-Dateisystems gestürzt.

Nach mehreren Anläufen haben es einige Entwickler geschafft: Beim am 8. oder 15. Juli erwarteten Linux 5.2 kann das populäre Ext4-Dateisystem auf Wunsch die Groß- und Kleinschreibung ignorieren, wie es XFS schon länger kann. Die Kernel-Entwickler haben zudem die Performance einer Technik verbessert, die beim Datenträgerzugriff die Operationen umsortieren kann, um etwa interaktive Programme zu bevorzugen. Das sind aber nur zwei der Highlights bei Dateisystemen und Storage-Support, die den neuen Kernel auszeichnen.

Was in der Windows-Welt ganz normal ist, kann Ext4 jetzt auch: Die Groß- und Kleinschreibung von Datei- und Verzeichnisnamen ignorieren. Durch diese "Case Insensitivity" wechselt etwa das Bash-Kommando cd Test in ein Verzeichnis, egal, ob es jetzt TEST, test oder tatsächlich Test heißt.

Dieses Verhalten ist standardmäßig inaktiv. Wer es nutzen will, muss es zuerst beim jeweiligen Dateisystem im Superblock freischalten, indem man das Feature-Flag casefold gleich beim Formatieren oder nachträglich mit tune2fs setzt; dazu braucht man aktuelle Fassungen der Ext-Dateisystemwerkzeuge e2fsprogs. Ältere Kernel oder Image-Werkzeuge, die mit dem Flag nichts anzufangen wissen, sollten so ein Dateisystem dann nicht mehr anfassen und somit auch nicht mounten. Ungewiss ist, ob Debian, Fedora, Ubuntu & Co. die Kennzeichnung in Zukunft automatisch setzen.

Das Verhalten muss man ferner beim Hauptverzeichnis oder einem Unterverzeichnis aktivieren, indem man dort mit aktuellen Versionen von chattr das Flag F setzt. Das Verzeichnis muss dazu noch leer sein, damit das Dateisystem dort fortan das Anlegen mehrdeutiger Dateisystemeinträge wie TEST und test unterbinden kann. Die Einstellung vererbt sich, sodass Unterverzeichnisse das Verhalten übernehmen.

Entwickler haben dieses "Casefold Feature"-Feature entwickelt, um es bei Android einzusetzen – bislang nutzt das Mobilbetriebssystem einen eher uneleganten Hack in Form einer "Wrapfs" genannten Zwischenschicht, um Case Insensitivity mit Ext4 zu erzielen. Das neue Ext4-Feature ist aber auch bei den Entwicklern von Wine auf Anklang gestoßen – kein Wunder, schließlich kann das eine Reihe von Windows-Programmen unter Linux ausführen, die eben Case Insensitivity erwarten. Die Wine-Macher haben daher in den Test-Entwicklungszweig Wine Staging bei Version 4.10 eine neue Funktion eingebaut, um mit dem Casefold Feature einige Tücken rund um die Groß- und Kleinschreibung von Verzeichnis- und Dateinamen zu vermeiden.

Case Insensitivity ist in der Linux-Welt übrigens nichts Neues: Auch beim angesehenen und unter anderem von Red Hat (Root- und Datenpartitionen) und Suse (bei Datenpartitionen) verwendete Dateisystem XFS lässt sich Case Insensitivity seit vielen Jahren beim Formatieren mit dem Parameter -l version=ci aktivieren. XFS ignoriert Groß- und Kleinschreibung aber nur im Bereich der ASCII-Zeichenkodierung – letztlich also nur von A bis Z, was recht simpel und nebenwirkungsfrei zu implementieren ist.

Das Casefold Feature von Ext4 greift hingegen für Normalisierung und Casefolding auf eine UTF-8-Zeichentabelle der Unicode Version 12.1.0 zurück. Sie wurde eigens für die neue Dateisystemfunktion in Linux integriert und ist über 1 MByte schwer (u. a. 1, 2, 3).

Linus Torvalds hatte sich anfangs deutlich gegen Case-Insensitivity bei Ext4 ausgesprochen. (Bild: lore.kernel.org )

Weitere Details zum neuen Feature und der Verwendung von Unicode-Tabellen im Kernel liefert ein Commit-Kommentar, die Dokumentation sowie die LWN.net-Artikel "Filesystems and case-insensitivity" und "Case-insensitive ext4". Letzterer zeigt auch, dass die Entwickler über die Funktion anfangs gezankt haben. Selbst Linus Torvalds hatte sich zuerst dagegen ausgesprochen und den ganzen Ansatz zuerst mit deutlichen Worten in Frage gestellt: "Himmel! Warum wollen Leute das machen? Wir wissen doch, dass es eine verrückte und beknackte Sache ist. […] Sowas löst echte und subtile Sicherheitslücken aus". Letztlich hat er die Änderung aber ohne Widerworte für 5.2 integriert (1, 2).

Ein ganzer Schwung von Änderung verspricht die Performance von Budget Fair Queueing (BFQ) zu verbessern – dem von manchen Distributionen standardmäßig eingesetzten Storage-I/O Scheduler, der bei Datenträgerzugriffen die gerade anstehenden Lese- und Schreiboperationen umsortieren kann, um die Performance zu verbessern.

Eine der Anpassungen an BFQ hat bei einem Test der Entwickler größere Auswirkungen gezeigt: Der Test Dbench legte bei sechs Clients bei einem System mit Plextor-SSD von 80 MByte/s auf 100 zu. Bei einer weiteren Änderung am Nachfolger des früher verbreiteten I/O-Scheduler CFQ (Completely Fair Queuing) ist von einem Zugewinn von 100 auf 150 MByte/s die Rede – anscheinend geht es hier um dasselbe Testsystem. Damit nicht genug: Durch einen dritten Patch stieg das Testergebnis von 150 auf 200 MByte/s. Wie bei solchen Messungen üblich, hängt stark von Umgebungsbedingungen, Benchmark und Testparametern ab, ob es in anderen Situationen überhaupt einen Performance-Gewinn gibt und wie groß dieser ausfällt.

Der BFQ-Entwickler hat viele Messwerte mit der modernen BFQ-Ausführung veröffentlicht. (Bild: algo.ing.unimo.it/people/paolo/ )

Durch andere Änderungen an BFQ sollen Programme um einiges schneller starten, wenn parallel viele Schreiboperationen anliegen. Einige weitere Verbesserungen versprechen die CPU-Belastung zu reduzieren. Details zum Ganzen liefert der LWN.net-Artikel "Improving the performance of the BFQ I/O scheduler", der noch andere Testergebnisse enthält; weitere hat der Hauptentwickler von BFQ auf seiner Homepage veröffentlicht.

Beim XFS-Dateisystem gab es einen größeren Batzen von Neuerungen, die ein Commit-Kommentar nennt. Darunter etwa eine Schnittstelle, über die das Dateisystem jetzt Informationen zum Gesundheitszustand des Dateisystems abliefern kann. Der Code zum Prüfen der Metadaten im Betrieb bleibt experimentell, bietet nach einer Erweiterung aber jetzt alle wesentlichen Funktionen, auf die Oracle-Entwickler Darrick Wong seit einiger Zeit im Rahmen eines größeren Umbaus hinarbeitet.

Auch beim Device Mapper (DM), auf den unter anderem der Logical Volume Manager oder die Datenträgerverschlüsselung mit Cryptsetup/LUKS zurückgreifen, gab es allerlei Änderungen. Eine davon ist ein Bitmap-Mode für Dm-Integrity (1, Dokumentation); diese Device-Mapper-Funktion zur Sicherstellung von Datei-Integrität soll damit eine bessere Performance erzielen als mit dem älteren Ansatz, der ein Journal verwendet. Neu ist das DM-Dust-Target, mit dem man zu Testzwecken das Verhalten eines gealterten Datenträgers simulieren kann, der defekte Sektoren aufweist.

Das beim Zugriff auf SMB-Freigaben von Samba- oder Windows-Servern verwendete CIFS beherrscht jetzt die lseek()-Flags SEEK_DATA und SEEK_HOLE. Auch das Overlay-Dateisystem (OVL) unterstützt sie jetzt. Diese Funktionen sind unter anderem zur effizienteren Handhabung von Images virtueller Maschinen interessant, denn Anwendungen können darüber Speicherbereiche in Dateien effizienter handhaben, die lediglich Nullen enthalten.

Unter den Änderungen an CEPH ist Unterstützung für den bei Linux 4.11 eingeführten Systemfunktionsaufruf statx(), der eine umfassendere und effizientere Abfrage von Datei- oder Verzeichniseigenschaften ermöglicht. Außerdem kann es jetzt NFS-Snapshots re-exportieren.

Beim ursprünglich für simple Flash-Datenträger gedachten F2FS-Dateisystem haben die Entwickler unter anderem den Support für Festplatten verbessert, die mit Shingled Magnetic Recording (SMR) arbeiten; bei solchen gibt es größere, Zonen genannte Bereiche, die immer sequenziell gefüllt werden müssen.

Das bei Linux 5.1 eingeführte, dort aber allenfalls intern verwendete Programmier-Interface zum Einhängen von Dateisystemen lässt sich bei 5.2 jetzt auch von Userspace-Programmen verwenden (u. a. 1, 2, 3, 4, 5). Der zuständige Entwickler will mit diesen neuen Mount-APIs eine Reihe von Problemen der bisherigen Schnittstelle aus der Welt schaffen.

Weitere Neuerungen nennen die wichtigsten Git-Commits der Bereiche AFS, Btrfs, Block-Layer (1, 2), CIFS (1, 2), Fuse, GFS, IO-Uring, MTD, NFS, NFSd, Orangefs, SCSI und Ubifs.

Eigentlich nur für Nostalgiker interessant ist eine Detailänderung, die im Internet aber viel Aufsehen erregte: Zwei Linux-Entwickler haben angekündigt, 2021 die Infrastruktur und die Treiber entfernen zu wollen, die via Parallel-ATA (auch PATA beziehungsweise IDE/Integrated Drive Electronics genannt) angesprochene Datenträger über Gerätenamen wie /dev/hda oder /dev/hdc bereitstellen.

PATA-Datenträger über diesen Code und solche Gerätenamen anzusprechen war in der Anfangszeit von Linux Usus. Mit dem Aufkommen von Serial ATA erhielt der Kernel aber eine modernere Infrastruktur samt neuer Treiber zum Austausch mit ATA-Datenträgern, die Linux dann unter Block-Devices wie /dev/sda, /dev/sdb, usw. bereitstellt. Dieses Libata genannte Subsystem erhielt wenig später auch alles Nötige, um gängige PATA-Chips anzusprechen. Damit hat Libata die ältere, oft schlicht "IDE-Treiber" genannte Infrastruktur schnell zurückgedrängt, sodass moderne Systeme auch PATA-Datenträger über /dev/sd? ansprechen.

Die Entwickler vermuten daher, dass kaum noch jemand die ältere Infrastruktur bei aktuellen Kernel-Versionen nutzt. Sofern niemand Einspruch erhebt, wollen sie den zuständigen Code entfernen, um die Wartung zu vereinfachen. Da die Parallel-ATA-Treiber auf Libata-Basis im Kernel bleiben, hat dieser Schritt für die meisten Anwender keinerlei Bedeutung.

Schrittweise aktualisierter Text zu Linux 5.2

Die Neuerungen des am 8. oder 15 Juli erwarteten Linux 5.2 sind seit dem 20. Mai absehbar, als Linus Torvalds die erste Vorabversion dieser Kernel-Version freigegeben hat. Damit hat er die "Merge Window" genannte Phase des Entwicklungszyklus abgeschlossen, in der er alle wesentlichen Umbauten für eine neue Kernel-Version vornimmt. Größere, erwähnenswerte Änderungen erfolgen danach nur in Ausnahmefällen; es passiert auch nur äußerst selten, dass die Entwickler eine umfangreichere, im Merge Window integrierte Änderung vor der Fertigstellung deaktivieren oder gar entfernen.

Das Kernel-Log der c't kann daher bereits jetzt die Neuerungen der nächsten Linux-Version in einem detaillierten Text beschreiben. Er wird zwischen Erstpublikation und der Fertigstellung des neuen Kernels mehrfach erweitert, um die wesentlichen Änderungen der verschiedenen Kernel-Bereiche schrittweise in leichter handhabbaren Mengen zu beschreiben. Der Text reißt daher die Highlights bislang nur an und beschreibt nur die Neuerungen bei Grafiktreibern, Infrastruktur und Dateisystemen & Storage näher; es folgen noch Textupdates, die sich Netzwerk-Unterstützung, Treibern, und Architektur-Support noch näher widmen und dabei Details zu den Highlights liefern.

Der Newsticker von heise online und der Twitter-Account @kernellog erwähnen größere Erweiterungen des Textes zum neuen Linux-Kernel. Diese finden Sie immer auf der ersten Artikelseite; ältere Textpassagen finden Sie auf den folgenden Seiten. Details zur Versionshistorie des Artikels liefert das Changelog am Artikelende.

Kommentare

Kommentare lesen (847 Beiträge)

Anzeige
Anzeige