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.

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.

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.

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.

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.

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.