2264851

Wie APFS (Apple File System) das Apple-Ökosystem verändert

06.04.2017 | 15:10 Uhr |

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 für alle Plattformen 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 (etwa nach einem System-Crash) oder wenn man eine neue Festplatte einrichten möchte.

Bei iPhone, iPad, Watch und Apple TV 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 Nutzer. 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 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 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 gern 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, wenn die Katalogdatei nicht von einem anderen Prozess blockiert ist. 2017 ist das kein sehr praxisnahes Verhalten mehr.

Zeitliche Entwicklung von Dateisystemen
Vergrößern Zeitliche Entwicklung von Dateisystemen
© 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 test.txt zu nennen; hier verwendet HFS+ den kleinen Anfangsbuchstaben. Intern bildet HFS+ die beiden Namen aber auf eine Darstellung ab, die nicht case sensitive 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 dort zu den grundlegenden Funktionen.

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 Betriebssysteme fungiert. Auf Linux und anderen Unix-Derivaten ist Groß- und Kleinschreibung Standard. 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 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 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 stehenbleibt 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 verwaiste Daten, kaputte Verzeichnisstrukturen oder gar ein komplett irreparables Dateisystem. In solchen Momenten hilft nur noch ein (hoffentlich vorhandenes) Time-Machine-Backup.

Der harte Absturz eines macOS-Rechners hinterlässt oft ein irreparables HFS+ -Dateisystem.
Vergrößern Der harte Absturz eines macOS-Rechners hinterlässt oft ein irreparables HFS+ -Dateisystem.
© 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 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 sogenannten APFS-Container . Dies entspricht 1:1 der bisher bekannten 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 Meta-Informationen, 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

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 vorzubeugen, 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. Mit der 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, wenn der Vorgang unerwartet abbricht, etwa weil der Mac stehenbleibt oder der Strom ausfällt. Die Erfahrung mit HFS+ zeigt ja: Ein Journal allein reicht nicht. Dieser Seitenhieb sei erlaubt, weil 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, so dass 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 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 Nutzer sich fragen, warum die Datensicherheit hier nicht gewahrt ist. Vielleicht liefert Apple diese Funktion mit einer künftigen Version 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 dasselbe: Gehe zurück auf Los.

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

APFS-Volumen passen sich dynamisch an, basierend auf dem Verhältnis von belegtem und freiem Speicherplatz eines Datenträgers.
Vergrößern APFS-Volumen passen sich dynamisch an, basierend auf dem Verhältnis von belegtem und freiem Speicherplatz eines Datenträgers.
© Klaus Rodewig und Mark Zimmermann

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.

0 Kommentare zu diesem Artikel

Macwelt Marktplatz

2264851