Seite 3: Storage: Datenbank-Beschleuniger und Schrumpfkur

Inhaltsverzeichnis

Datenbank-Beschleuniger

Das neue Writecache Target im Device Mapper (DM) ist für Systeme gedacht, bei denen möglichst geringe Latenzen gefragt sind, wenn Datenbanken und ähnlich gelagerte Anwendungen verarbeitete Daten speichern. Um das zu erreichen, bindet das neue DM-Target persistente Speichermodule als Schreib-Cache ein, um die Daten später in weniger zeitkritischen Situationen auf die regulären Datenträger zu überführen; alternativ funktioniert das auch mit SSDs und somit ähnlich wie beim Schreiben mit SSD-Caching-Lösungen wie Bcache und DM-Cache. Die beschleunigen auch das Lesen von häufiger genutzten Daten. Das neue DM-Target implementiert indes bewusst keinen Lese-Cache, schließlich nutzt der Kernel den Arbeitsspeichers ja ohnehin automatisch als solchen.

Feintuning bei Btrfs

Leere Snapshots lassen sich bei Btrfs-Dateisystem jetzt mit einem simplen rmdir selbst ohne Root-Rechte entfernen. Über neue Schnittstellen können unprivilegierte Anwender jetzt Informationen zu Subvolumes abrufen (u. a. 1, 2, 3). Über die neuen Ioctl-Kommandos FS_IOC_FSGETXATTR und FS_IOC_FSSETXATTR lassen sich zudem verschiedene Dateiattribute anpassen. Eine Optimierung an Btrfs Send/Receive hat bei gezielten Tests zu einem dramatischen Performance-Zuwachs geführt: Das Entfernen eines großen Verzeichnisses dauerte statt rund 33 Stunden nur noch 2 Minuten. Das sind nur einige von vielen kleinen Änderungen, die es diesmal beim Btrfs gab.

Verschlüsselung mit umstrittenem Speck-Algorithmus

Die von Ext4 und F2FS zur Verschlüsslung genutzte Fscrypt-Infrastruktur kann Daten nun mit den Algorithmen Speck 128 und 256 verschlüsseln, die Linux seit 4.17 unterstützt und wenig Overhead aufweisenden sollen (u. a. 1, 2). Im begleitenden Kommentar weist der langjährige Kernel-Entwickler Theodore 'tytso' Ts'o darauf hin, dass der von der NSA entwickelte Cipher als umstritten gilt (siehe u. a. Linux-Crypto-Post von Tomer Ashur und Wikipedia).

Laut Tytso sei der Speck-Support aber nur für die schwächsten Android-Geräte gedacht, bei denen die Alternative sonst wäre, Daten gar nicht zu verschlüsseln. In einer anderen Mail hat der bei Google arbeitende Tytso das noch konkretisiert: Der Algorithmus ziele auf "Die nächste Milliarde" von Android-Nutzern, die Google mit Geräten erreichen will, die weit unter 100 US-Dollar kosten.

Die Google-Mitarbeiter, die den Speck-Support bei 4.17 eingebracht hatten, erwähnten indes wenige Tage vor Fertigstellung von 4.18, Google wolle den Algorithmus jetzt doch nicht bei Android einsetzen. Das erwähnten Sie bei der Vorstellung des von ihnen entwickelten HPolyC, das Google stattdessen einsetzen will. Kurz darauf wurde noch vorgeschlagen, Speck samt des Fscrypt-Support wieder zu entfernen. Dazu ist es aber nicht gekommen.

Lustre-Rauswurf sorgt für weitere Schrumpfkur

Mit Version 4.18 schrumpft der Quellcode von Linux 4.18. Das allein ist ungewöhnlich, denn es passiert erst das vierte Mal in der Geschichte der modernen Linux-Entwicklung; noch ungewöhnlicher ist allerdings, dass auch 4.17 schon kleiner als sein direkter Vorgänger war.

Dass es zweimal hintereinander passiert, liegt keineswegs an neuen Arbeitsweisen, sondern schlicht und einfach am Zufall: Bei beiden Kernel-Versionen gab es Aufräumarbeiten, bei denen ein Entwickler einen Batzen Quellcode entfernt hat. Bei 4.17 traf es den Support für alte, offenbar von niemand mehr genutzte Prozessorarchitekturen. Bei 4.18 ist es vornehmlich dem Rauswurf des Cluster-Dateisystems Lustre zu verdanken, der die Kernel-Quellen um fast zweihunderttausend Codezeilen erleichtert hat.

Das vor allem beim High Performance Computing (HPC) eingesetzte Lustre hat durchaus noch Nutzer, daher dürfte es nach den Regeln der Linux-Entwicklung eigentlich gar nicht entfernt werden. In diesem Fall geht es aber doch, denn der Code steckte nur im Staging-Zweig, weil er nie die Qualitätsstandards der zuständigen Kernel-Entwickler erfüllt bat.

Sonderregeln im Staging-Zweig

Staging ist ein vor allem für Treiber gedachter Sonderbereich des Kernels, der Entwickler helfen soll, mangelhaften Code im Rahmen der normalen Linux-Entwicklung auf Vordermann zu bringen. Beim Lustre hat aber aus verschiedenen, bei LWN.net näher erläuterten Gründen in den letzten Jahren nicht geklappt – unter anderem, weil die Lustre-Entwickler ihr Dateisystem auch nach der Aufnahme in den Kernel weitgehend losgelöst davon an anderen Stelle vorantreiben. Kurzfristig ist keine Besserung der Lage in Sicht, daher flog der Code jetzt raus, denn die Staging-Regeln erlauben das als Druckmittel. Der Schritt bringt so in Erinnerung: Im Staging-Zweig enthaltenen Funktionen oder Treiber können jederzeit verschwinden, daher sollte man genau abwägen, ob oder wie weit man sich auf diese verlassen will.

Lustre war nicht der einzige Rauswurf: Auch die Unterstützung für das Netzwerkprotokoll Novell IPX und das darauf aufbauende Netware Core Protocol File System (Ncpfs) mussten weichen. Diese zum Zugriff auf NetWare-Server von Novell genutzten Techniken waren bei Linux 4.16 in den Staging-Zweig verlagert worden, damit potenziell noch vorhandene Anwender den drohenden Rauswurf bemerken und Einspruch erheben konnten. Das hat in den zwei zwischenzeitlich verstrichenen Monaten aber niemand getan. Das zeigt: Wer sicher gehen will, dass von ihm benötigte Alttechniken nicht aus dem Kernel verschwinden, muss ein Auge auf die Linux-Entwicklung halten und regelmäßig testen, um gegebenenfalls rechtzeitig Laut geben zu können.

Android beschleunigen, ATA-Finetuning, XFS-Fortschritte, …

Unter den Änderungen am F2FS (Flash-Friendly File System) sind einige, die Performance-Probleme rund um das Melden freigewordener Speicherbereiche (Discard/Trim) beheben. Das soll vom Benutzer spürbare Wartezeiten vermeiden, wie sie einige F2FS einsetzende Andorid-Geräte gelegentlich zeigen.

Zwischen den Patches am ATA-Subsystem ist eine kleine Anpassung, durch die der AHCI-Treiber statt 31 nun die maximal möglichen 32 Queues nutzt, wenn es NCQ-taugliche Datenträger anspricht. Bei Tests, wo die Zahl der Zugriffe (IOPS) den Flaschenhals bildete, konnte das die Performance um zirka drei Prozent verbessern.

Beim XFS gab es weitere Änderungen, um Dateisysteme in Zukunft im Betrieb prüfen und gegebenenfalls sogar reparieren zu können. Umbauten am Code zur Dateisystemvergrößerung legen zudem Grundlagen, durch die XFS letztlich Subvolumens unterstützen soll. Der Weg zu beiden Features ist aber noch weit, wie der XFS-Maintainer in einem der Merge-Commits mit den Erweiterungen betont (1, 2). Beide Features bauen auf den tiefgreifenden Umbauten an XFS auf, die seit Linux 4.8 im Rahmen der normalen Kernel-Entwicklung erfolgen.

Mit zahlreichen Änderungen am Block Layer stießen einige Grundlagen für Bcachefs zum Kernel. Dabei handelt es sich um ein noch junges Dateisystem, das aus der SSD-Caching-Lösung Bcache hervorgegangen ist. Dessen Entwickler arbeitet jetzt auf eine Integration in den offiziellen Kernel hin, nachdem er darüber jüngst auf einer Konferenz mit anderen Dateisystementwicklern gesprochen hat. Diese zeigten sich einer Aufnahme gegenüber nicht abgeneigt, wie LWN.net berichet – wie gewohnt wollen sie den Code aber vorher begutachten.

Einige weitere Änderungen rund um den Support für Storage-Hardware finden sich in den Pull-Requests für die Subsysteme Libnvdimm, MDT und SCSI. Weitere Änderungen an Dateisystemen und Speicherlösungen nennen die Kommentare der wichtigsten Merge-Commits von Ceph, CIFS, Device Mapper, DLM, Ext4, FUSE, GFS2, MD, NFS, NFSd, UDF, UBI & UBIFS und VFS (work.aio).