Seite 2: Storage-Performance; Groß- und Kleinschreibung; Änderungsrekord

Inhaltsverzeichnis

Performance-Verbesserungen beim Storage-IO Scheduler BFQ

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.

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.

Case Insensitivity beim Ext4-Dateisystem

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.

Für Android gemacht, von Wine-Entwicklern begrüßt – und nichts wirklich Neues

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.

Unicode-Tabelle für Casefold-Funktion von Ext4

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).

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).

Zweieinhalb mal so viele Dateien verändert wie üblich

Die Linux-Entwickler haben für Linux 5.2 nicht wie sonst elf- bis dreizehntausend Dateien verändert, sondern über dreißigtausend. Für diesen Rekord sind Thomas Gleixner und einige Mitstreiter verantwortlich, die tausende Lizenzhinweise in Quelltextdateien durch einzeilige Lizenzauszeichner ersetzt haben, die der Spezifikation des SPDX (Software Package Data Exchange) entsprechen. Diese am Dateianfang stehenden "SPDX License Identifier" lauten etwa "GPL-2.0-or-later" oder "GPL-2.0-only". Compliance-Werkzeuge können diese leicht und unmissverständlich abfragen. Vor allem Unternehmen setzen solche Werkzeuge ein, um sich einen Überblick über die in Produkten verwendeten Software-Lizenzen zu verschaffen, damit sie besser sicherstellen können, die Lizenzen auch einzuhalten.

Die Bestrebungen zur SPDX-Auszeichnung der Quelldateien von Linux begannen bei Linux 4.14 und bekamen bei Linux 4.16 einen ersten Schub. Die jetzt vorgenommenen Änderungen (u. a. 1, 2, 3, 4, 5, 6) sind ein enormer Schritt vorwärts, durch den jetzt statt zirka 25 rund 70 Prozent der Dateien einen SPDX License Identifier tragen.Die Änderungen nahmen die Entwickler im Wesentlichen mit Skripten vor. Bei den verbliebenen Dateien ist mehr Handarbeit nötig, weil die Skripte die Lizenzen dort nicht zweifelsfrei erkennen können.