Seite 5: Storage-Unterstützung und Dateisysteme

Inhaltsverzeichnis

XFS-Umbau schreitet voran

Die grundlegende Erweiterung von XFS, die im Spätsommer 2016 ihren Anfang nahm, zeigt erste Früchte: Die bei Linux 4.8 integrierte Funktion zum Reverse Mapping (Rmap) in XFS gilt nicht mehr als experimentell; auch das bei Linux 4.9 dazugestoßene Reflink konnte diesen Status ablegen. Um die Features nutzen zu können, braucht es allerdings auch Dateisystem-Werkzeuge, die diese Funktionen freigeben. Aktuelle Versionen der xfsprogs können beide Features beim Formatieren neuer Volumen aktivieren. Standardmäßig machen sie das aber nicht; das dürfte vermutlich erst der Fall werden, wenn noch mehr der grundlegenden XFS-Erweiterungen im Linux-Kernel angekommen sind und die Experimentell-Einstufung ablegen. Zu den noch unfertigen Features zählt das  in Linux 4.15 eingeflossene "Online Scrub and Repair", mit dem sich Dateisysteme prüfen und reparieren lassen, ohne sie aushängen zu müssen. Es gab für 4.16 aber allerlei Änderungen, die dieses Feature vorantreiben.

Diese und andere neue Funktionen greifen vielfach auf die Funktionen für Reverse Mapping und Reflink auf. Durch sie kann das Werkzeug cp beim Aufruf mit --reflink beispielsweise Kopien in Sekundenbruchteilen erzeugen, weil sich XFS ein Vervielfältigen der Dateiinhalte sparen kann; stattdessen braucht es dank Reflink-Support nur einen neuen Dateisystemeintrag mit einer Kopie der Metadaten anzulegen, der auf dieselben Nutzdatenbereiche verweist wie der Eintrag der Quelldatei. Änderungen an den Inhalten des Originals wirken sich dennoch ebensowenig auf die Inhalte der Kopie aus wie umgekehrt. Das ist der Unterschied zu einem mit ln erzeugten Hardlink, bei dem man letztlich die gleiche Datei über unterschiedliche Dateisystemeinträge ansprechen kann.

RAIDs wieder splitten und andere Storage-Neuerungen

Über das neue Device-Mapper-Target Dm-Unstripe kann man zu einem JBOD (Just a bunch of disks) oder RAID 0 verbundene Datenträger wieder auseinanderklamüsern und separat ansprechen. Wenn Sie jetzt "was soll denn der Unfug" denken, geht es ihnen genau wie dem Kernel-Log-Autor, als er diese dafür zuständige Änderung sah. Der Commit-Kommentar erklärt aber, wozu das Ganze gut ist. Es soll beispielsweise für NVMe-SSDs von Intel interessant sein, wo verschiedene Controller-Kerne unterschiedliche Speicherbereiche betreuten, die die NVMe-SSD-Firmware zu einem RAID 0 verbindet und komplett exportiert.

Das Verbinden bringt aber Overhead mit sich, der etwa zu Latenzen bei Leseanforderungen führt. Für bestimmte Einsatzzwecke kann es daher sinnvoll sein, die Speicherbereiche jeweils separat anzusprechen. Die Firmware erlaubt das aber nicht. Mit dem neuen und von einem Intel-Entwickler eingebrachten Target können Admins diese Beschränkung umgehen.

Das bei Linux 4.12 nachgerüstete "Partial Parity Log for MD RAID 5" (RAID5-PPL) soll nun auch zuverlässig mit Datenträgern arbeiten, bei denen der Write-Back Cache aktiv ist.

Effizienteren Zugriff und dadurch bessere Performance beim Zugriff auf Speicherkarten versprechen Änderungen, durch die das Subsystem für Multi Media Cards (MMCs) nun das Multiqueue Block API nutzt. Diese auch Blk-MQ genannten Infrastruktur kann Datenträger mit mehreren Warteschlangen ansprechen und so stärker von den heute allgegenwärtigen Multicore-Prozessoren profitieren; letztlich ist das nötig, um das Leistungspotenzial moderner Datenträger besser auszuschöpfen.

Gleich mehrere der Umbauten am Device Mapper versprechen, die Performance beim Einsatz auf NVMe-Datenträgern zu verbessern.

Unter einem ganzen Schwung von Änderungen am Block-Layer (1, 2) waren einige Patches, durch die die IO-Scheduler Deadline und MQ-Deadline auf SMR-Festplatten keine Schreiboperationen mehr eigenständig umordnen. Das ist bei manchen SMR-Platten nötig ("Host Managed") oder für gute Performance empfehlenswert ("Host Aware"), weil diese verschiedene Zonen haben, in denen die Daten enger beieinander liegen als bei klassischen Festplatten. Diese Zonen müssen jeweils sequenziell gefüllt werden; um in einem einmal beschriebenen Bereich neue Daten zu speichern, muss die komplette Zone gelöscht werden.

Einige weitere Änderungen rund um Support für Storage-Hardware finden sich in den Pull-Requests für die Subsysteme Libnvdimm, MMC, SCSI und SCSI Target.

SMB3-Direct-Support und Overlayfs für NFS

CIFS kommt dank einiger Korrekturen jetzt auch mit per SMB3 angesprochenen Samba- oder Windows-Freigaben klar, bei denen sich die Daten per DFS (Distributed File System) auf verschiedenen Servern verteilen. Ferner bietet CIFS nun experimentelle Unterstützung für SMB3 Direct, mit dem der Client direkt per RDMA (Remote Direct Memory Access) auf dafür vorgesehene Bereiche im Speicher des Servers schreiben oder lesen kann; das vermeidet Overhead auf Client- und Server-Seite und kann so die Geschwindigkeit steigern (u. a. 1, 2, 3, 4).

Per Overlay-Dateisystem (Overlayfs/Ovl) übereinander gelegte Dateisysteme lassen sich jetzt auch per NFS exportieren (u.a. 1, Dokumentation).

Das NFS-Dateisystem unterstützt jetzt den bei Linux 4.11 eingeführten System-Funktionsaufruf statx(), der eine umfassendere und zugleich aber auch effizientere Abfrage von Datei- oder Verzeichniseigenschaften ermöglicht.

Weitere Änderungen an Dateisystemen und Speicherlösungen nennen die Kommentare der wichtigsten Merge Commits am Code für AFS, Btrfs, Ceph, CIFS, Ext4, Fscrypt, F2FS, GFS2, MD, NFS (1, 2), NFSd, Overlayfs, UBI/UBIFS und XFS (1, 2).