Das neue Dateisystem von Apple

Wie APFS das Apple-Ökosystem verändert

05.04.2017
Von  und Klaus  Rodewig  
Mark Zimmermann weist mehrere Jahre Erfahrung in den Bereichen Mobile Sicherheit, Mobile Lösungserstellung, Digitalisierung und Wearables auf. Er versteht es diese Themen aus unterschiedlichsten Blickwinkeln für unternehmensspezifische Herausforderungen darzustellen. Hierzu ist er auf nationale Vorträgen und als freier Autor für Fachpublikationen tätig.
Das auf iPhone, iPad, Mac & Co. laufende Dateisystem HFS+ ist mittlerweile stark in die Jahre gekommen. Deshalb rollt Apple gerade dessen Nachfolger, das Apple Platform File System APFS, sukzessive aus. Grund genug, einen Blick darauf zu werfen.

Als Mac-Anwender kommt man in der Regel nur bei zwei Gelegenheiten mit dem Dateisystem in Berührung: wenn es Probleme gibt (z.B. nach einem System-Crash) oder wenn man eine neue Festplatte einrichten möchte. Bei iPhone, iPad, Watch und AppleTV hingegen ist das Dateisystem komplett wegabstrahiert; dort bekommen Anwender und App-Programmierer keinen direkten Kontakt mehr mit dem Dateisystem und dementsprechend uninteressant ist so ein Dateisystem auf diesen Geräten für den Anwender. Zumindest vordergründig.

Mit iOS 10.3 erhalten die Apple Devices iPhone und iPad ein neues Dateisystem.
Mit iOS 10.3 erhalten die Apple Devices iPhone und iPad ein neues Dateisystem.
Foto: blackzheep - shutterstock.com

Seit 1998 bis heute verwendet Apple auf seinen Rechnern das Hierarchical File System Plus (HFS+) als Dateisystem. HFS+ stammt noch aus der Zeit von Mac OS 8, wurde also auf einem ganz anderen Betriebssystem als dem heutigen macOS entwickelt. 1998 war die Zeit, in der die Konkurrenz von Microsoft noch mit FAT32 arbeitete, was seinerseits eine Weiterentwicklung aus MS-DOS-Zeiten war. HFS+ wiederum ist eine Weiterentwicklung von HFS, einem Dateisystem, das Apple 1985 für Disketten und Festplatten entworfen hat.

Ihre Meinung ist gefragt!

Consumer-Dateisystemen war in den späten 90ern gemein, dass sie ausschließlich dafür konzipiert waren, Dateien und Verzeichnisse auf einem Datenträger zu organisieren und aus einer Zeit stammten, in der es weder Multitasking noch große Datenträger gab. Funktionen wie z.B. das Führen eines Journals, um die Integrität des Dateisystems nach einem Crash zu gewährleisten, gab es in der Zeit nur in Server-Dateisystemen wie dem NTFS von Windows NT. So kam auch HFS+ lange ohne Journal daher, was nach einem Crash gerne zu einem nicht definierbaren Zustand des Dateisystems geführt hat. Erst 2002 hat Apple HFS+J (oder auch jHFS+) eingeführt; eine Version von HFS+ mit Journal. Die Konkurrenz von Microsoft war da mit ihrem NTFS satte neun Jahre schneller.

Auch war der gleichzeitige Zugriff verschiedener Prozesse auf das Dateisystem nicht vorgesehen; HFS+ unterstützt diese Funktion bis heute nicht; die Informationen über alle Dateien und Verzeichnisse liegen in einer einzigen, zentralen Katalogdatei. Der schreibende Zugriff eines Prozesses auf das Dateisystem kann also immer nur dann ausgeführt werden, denn die Katalogdatei nicht von einem anderen Prozess blockiert ist. 2017 kein sehr praxisnahes Verhalten mehr.

Zeitliche Entwicklung von Dateisystemen
Zeitliche Entwicklung von Dateisystemen
Foto: Klaus Rodewig und Mark Zimmermann

HFS+ unterstützt in seiner ursprünglichen Form Groß- und Kleinschreibung, ist aber nicht case sensitive. Was sich auf den ersten Blick wie ein Widerspruch anhört, ist leicht erklärt. Es ist mit HFS+ möglich, eine Datei mit dem Namen Test.txt zu erstellen. HFS+ erkennt den Großbuchstaben am Anfang und behält ihn bei. Es ist auch möglich eine Datei text.txt zu nennen; hier verwendet HFS+ den kleinen Anfangsbuchstaben. Intern bildet HFS+ die beiden Namen aber auf eine Darstellung ab, die case insensitive ist. Es ist also unmöglich, im selben Verzeichnis eine Datei Test.txt und eine Datei test.txt zu speichern. Bei modernen Dateisystemen ist das kein Problem und gehört zu den grundlegendsten Funktionalitäten.

Für den Anwender ist dieses Verhalten kein großes Problem; im Zweifelsfall hat er es über die Jahre gelernt. Komplizierter wird es, wenn ein Mac als Server für andere Betriebssystem fungiert. Auf Linux und anderen Unix-Derivaten ist Groß- und Kleinschreibung Standard, und dementsprechend kommt es zu großen Problemen, wenn ein Mac solchen Clients ein Netzwerklaufwerk anbietet, das nicht zwischen Groß- und Kleinschreibung unterscheidet. Um dieses Manko zu umgehen, hat Apple 2003 HFS+ um Groß- und Kleinschreibung erweitert. Als Anwender sollte man von dieser Erweiterung aber tunlichst die Finger lassen und die Systempartition nicht damit ausstatten. Unzählige Programme funktionieren dann nämlich nicht mehr, weil sie davon ausgehen, auf einem System zu laufen, dass eben keine Groß- und Kleinschreibung unterscheidet; diese Programme finden dann schlichtweg benötigte Dateien und Ordner nicht mehr.

Für iOS, tvOS und watchOS verwendet Apple intern hingegen die HFS+-Version mit Groß- und Kleinschreibung. Das führt beim Entwickeln von Apps mitunter zu ärgerlichen Problemen, denn Dateien, die eine App im Xcode-Simulator auf dem Mac problemlos findet, findet sie dann plötzlich auf dem echten Gerät nicht mehr; Groß- und Kleinschreibung sei Dank. Das führt dann zu mitunter kruden Workarounds, damit es zur Laufzeit auf dem Gerät nicht zu Problemen kommt.

Besonders ärgerlich wird die Arbeit mit HFS+, wenn der Mac stehen bleibt und ein harter Neustart notwendig ist. Aber auch Stromausfälle oder schlechte Software führen zu derartig notwendigen Neustarts. Allzu oft, befindet sich das Dateisystem dann in einem inkonsistenten Zustand. Trotz Journal stimmen in diesen Situationen die im Katalog gespeicherten Informationen nicht mit dem tatsächlichen Zustand des Dateisystems überein. Das Ergebnis sind dann verwaiste Daten, kaputte Verzeichnisstrukturen oder gar ein komplett irreparables Dateisystem. In solchen Momenten hilft dann nur noch ein (hoffentlich vorhandenes) Time Machine-Backup.

Der harte Absturz eines macOS-Rechners hinterlässt oft ein irreparabeles HFS+ Dateisystem.
Der harte Absturz eines macOS-Rechners hinterlässt oft ein irreparabeles HFS+ Dateisystem.
Foto: Klaus Rodewig und Mark Zimmermann

Nicht ganz ohne Grund hat Linus Torvalds, der Vater von Linux, HFS+ als das schlechteste Dateisystem aller Zeiten bezeichnet. Abgesehen von diesen sehr handfesten Nachteilen, die vermutlich jeder Entwickler oder Anwender schon zu spüren bekommen hat, fehlen HFS+ noch viel weitergehende Funktionen, die moderne Dateisysteme schon seit Jahren bieten.

In einer frühen Beta von OS X Leopard hatte Apple 2007 das Dateisystem ZFS für OS X eingeführt und damit Hoffnung auf eine Ablösung von HFS+ geschürt. Leider ist es dann vor dem Release von Leopard wieder entfernt worden. Und so hat es weitere 10 Jahre gedauert, bis tatsächlich ein Nachfolger von HFS+ vor der Tür steht.

Was verspricht APFS?

Das neue Dateisystem APFS adressiert alle Plattformen aus dem Hause Apple - macOS, iOS, watchOS und tvOS. Es ist ein 64-Bit-Dateisystem, das auf dem Konzept der Inodes basiert. Ein Inode bezeichnet die grundlegende Datenstruktur zur Verwaltung von Dateisystemen mit unixoiden Betriebssystemen.

Datenstrukturen (Attribute) können nun flexibel und erweiterbar einer Datei hinzugefügt werden. Im alten Dateisystem HFS waren diese Dateiattribute feststehend. APFS unterscheidet zwischen Groß- und Kleinschreibung - für das Apple-Universum ein großer Schritt nach vorn.

Ein Datenträger beherbergt den so genannte APFS Container. Dies entspricht 1:1 den bisher bekannte GUID Partition Table (GPT). Diese Container erlauben es mehrere APFS Volumen (ehemals Partitionen) vorzuhalten. Jedes Volumen stellt danach das APFS Dateisystem (APFS Namespace) zur Verfügung.

Wichtigste interne Neuerung ist die zeitgemäße Ablage von Metainformationen, also Informationen über Aufbau und Zustand des Dateisystems an verteilten Stellen und nicht mehr in einer zentralen Katalogdatei wie bei HFS+. Das erlaubt es erst, alle Anforderungen an ein modernes Dateisystem zu erfüllen.

HFS+

APFS

Anzahl Blöcke

2^32

2^63

Datei-ID

32 Bit

64 Bit

Maximale Dateigröße

2^63 Byte

2^63 Byte

Genauigkeit des Zeitstempels

Sekunde

Nanosekunde

Copy on write

nein

ja

Crash-Schutz

Journal (also: nein)

ja

Datei- und Verzeichnis-Klone

nein

ja

Snapshots

nein

ja

Teilen von Speicherplatz

nein

ja

Verschlüsselung

ja

ja

Sparse Files

nein

ja

Fast Directory Sizing

nein

ja

Tabellenunterschrift: HFS+ und APFS im Vergleich

Integrität

Probleme mit der Integrität des Dateisystems können naturgemäß nur durch fehlgeschlagene Schreiboperationen entstehen (von Hardware-Defekten mal abgesehen). Um solchen Problemen vorzusorgen und um den Nutzer nicht länger mit korrupten Dateisystemen im Regen stehen zu lassen, verwendet APFS einen bereits von ZFS bekannten Mechanismus namens Copy on write (COW). Bevor APFS Daten auf den Datenträger schreibt, erstellt es eine Kopie der Metadaten, die die Attribute einer Datei oder eines Ordners beschreiben. Mithilfe der beschrieben Copy-on-Write (COW) für diese Metadaten bleiben Einträge in das Dateisystem, ebenso wie Schreibvorgänge in das Journal des Dateisystems, auch dann nachvollziehbar bleiben, wenn der Vorgang unerwartet abbricht, z.B. weil der Mac stehen bleibt oder der Strom ausfällt. Die Erfahrung mit HFS+ zeigt ja: ein Journal alleine macht noch keinen Sommer. Auch, dieser Seitenhieb sei erlaubt, wenn das freie Linux-Dateisystem ext3 nur mit einem Journal vor 17 Jahren schon wesentlich crashresistenter war als es HFS+ heute ist.

Zur Sicherheit kommen bei diesen Metadaten zusätzlich Checksummen zum Einsatz, sodass zu jedem Zeitpunkt ein konsistentes Dateisystem vorliegt. Allerdings beschränkt sich APFS auf die Metadaten einer Datei. Der Dateninhalt selbst wird nicht mit Checksummen abgesichert. Daher kann APFS Fehler innerhalb der Dateien weder erkennen noch korrigieren. Das auch als Bitfäule bezeichnete Problem bleibt damit unerkannt. Apple scheint hier auf die ECC-Fehlerkorrektur der Speichermedien selbst zu vertrauen, statt sich dieses Problems selbst anzunehmen.

Im Falle der Apple Watch mag diese Einschränkung sicherlich nachvollziehbar sein, bei Produktionsmaschinen wie der MacPro dürften Anwender sich fragen, warum die Datensicherheit hier nicht gewahrt ist. Vielleicht liefert Apple diese Funktion mit einer zukünftigen Version noch nach. Dank des variablen Aufbaus von APFS wäre dies technisch denkbar.

Flexible Partitionen

Das nachträgliche Verändern der Partitionsgröße einer HFS+-Partition ist immer problematisch. Zwar erlaubt HFS das Verändern einer Partition, dies stößt in der Praxis aber immer wieder an Herausforderungen. Ob dies an der Qualität der Werkzeuge oder der Eingeschränktheit des Dateisystems liegt, ist nicht immer offensichtlich; das Ergebnis ist aber immer das selbe: gehe zurück auf Los.

Mit APFS führt Apple flexible Partitionen (engl. Space Sharing) ein. Diese Technik ist aus anderen modernen Dateisystemen, wie z.B. ZFS, bekannt. Hierbei haben die Partitionen auf einer Festplatte keine festen Größen, sondern werden durch logische APFS-Volumen definiert. Ein einzige APFS-"Container", der eine ganze Festplatte umfasst, kann mehrere derartiger APFS-Volumen beinhalten. Jedes einzelne APFS-Volumen meldet für sich, dass der gesamte Platz der Festplatte ihr zur Verfügung steht.

Dies ist äußerst praktisch, da beim Erstellen der Partitionen die tatsächlich benötigte Speichergröße nicht bekannt sein muss. Ein Beispiel: Auf einer 100 Gigabyte fassenden SSD kann ein Volume 10 Gigabyte belegen und ein weiteres 20 Gigabyte. Beide hätten dann noch 70 Gigabyte freien Speicherplatz. Statt fester Partitionen, deren zugewiesener Speicherplatz aufwendig geändert werden müsste, passt APFS den notwendigen Speicherplatz automatisch an. Wer dann zuerst schreibt, bekommt den Platz.

APFS Volumen passen sich dynamisch, basierend auf dem Verhältnis von belegtem und freien Speicherplatz eines Datenträgers an.
APFS Volumen passen sich dynamisch, basierend auf dem Verhältnis von belegtem und freien Speicherplatz eines Datenträgers an.
Foto: Klaus Rodewig und Mark Zimmermann