Seite 5: Dateisysteme & Storage

Inhaltsverzeichnis

Daten unterschiedlich handhaben

Ü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 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" reduzieren. 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ützten Directives zählt, die NVMe 1.3 jüngst definiert hat.

Support für neue Festplatten-Typen

Über ein neues Device-Mapper-Target lassen sich jetzt beliebige Dateisysteme 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.

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 Bit 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 dem 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-Target. Das dürfte vielfach eine bessere Performance erzielen, weil es mehr über die zu speichernden Daten weiß.

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.

Asynchrones I/O besser

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.

Fehler beim Datenträgerzugriff besser handhaben

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önnen 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, als unwissend aufzugeben oder es einfach nochmal zu probieren. Der neue 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önnen durch diese Änderungen zuverlässiger erfahren, ob beim Wegschreiben von im Writeback-Cache zwischengespeicherter Daten ein Problem auftritt (u. a. 1, 2, 3).

OPAL-Support für ATA-Datenträger

Das SCSI-Subsystem unterstützt nun selbstverschlüsselnde SSDs, 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. Damit Linux-Distributionen die Technik unterstützen können, müssen diese allerdings die Userspace-Software anpassen, die für verschlüsselte Datenträger das Passwort abfragt und diese entriegelt.

Neues bei Btrfs, Ceph, Overlayfs, XFS, …

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.

Unter den Änderungen an XFS waren Grundlagen, durch die sich die Datenträger mit dem neuesten On-Disk-Format 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 einigen besonders stromsparenden Embedded-Prozessoren entgegenkommen, denn sie verarbeiten die 128-Bit-Variante 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.