Wie APFS das Apple-Ökosystem verändert

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.

Sofortige Größenberechnung von Ordnern

Um eine Übersicht des auf einem Datenträger belegten Platzes zu erhalten, und zwar pro Verzeichnis und Datei, kann mit HFS+ Minuten dauern. Der Grund ist schnell erklärt. Mangels eines zentralen Stelle, die über diese Information Buch führt, muss das System die gesamte Baumstruktur des Dateisystems durchlaufen und den Speicherplatz jeder einzelnen Datei ermitteln. Das kann dauern; auf alten Magnetfestplatten insbesondere. APFS verwendet zur Abfrage des Speicherplatzes eine Technik namens Fast Directory Sizing. Die Abfrage der Ordnergrößen ist damit kein langwieriges Unterfangen mehr.

SPARSE-Support

Eine Sparse-Datei bezeichnet eine Datei, die in einem Dateisystem kompakt gespeichert werden kann, da sie weniger Daten enthält als die angegebene Dateigröße - sie enthält also Abschnitte mit unbestimmtem Inhalt. In einer Sparse-Datei wechseln sich Bereiche, in denen sich bereits gespeicherte Daten befinden, mit Bereichen ab, die noch nicht beschrieben wurden. Für diese unbeschriebenen Bereiche musste unter HFS+ entsprechend freier Platz fest allokiert werden. APFS benötigt hier nur den Speicherplatz, der tatsächlich belegt ist. Gleichzeitig kann die Datei auf ihre eigentlich definierte Größe dynamisch wachsen bzw. zurück schrumpfen.

Dies ermöglicht es, dass große Dateien, wie z.B. die virtuelle Festplatte einer Virtualisierungsumgebung wie Parallels oder VMWare unter APFS nur den tatsächlich genutzten Speicherplatz benötigen.

Verschlüsselung

Langjährige Mac-Anwender mit Sicherheitsbewusstsein werden sich noch mit Grausen an die Anfänge der Festplattenverschlüsselung mit OS X erinnern. HFS+ bot in seiner ursprünglichen Version keine Datenverschlüsselung an. 2003 hat Apple mit OSX-Panther dann FileVault eingeführt. FileVault, in Anwenderkreisen bekannter unter dem Namen FileFault, war nichts anderes als das Speichern des Benutzerverzeichnisses in einem verschlüsselten Image.

Dieses Vorgehen kam mit einigen Pferdefüßen daher. Zum einen konnte man FileVault nicht parallel mit Time Machine nutzen. Man musste also zwischen Verschlüsselung oder Backup wählen. Zum anderen war dies um so dramatischer, als dass ein Image auf einer HFS+-Partition bisweilen dazu neigt, durch einen Crash des Systems korrupt zu werden (wir erwähnten es bereits). Einem unverschlüsselten, korrupten Image seine Daten zu entlocken, ist schon harter Tobak. Bei einem verschlüsselten, korrupten Image ist dies unmöglich. FileVault war in der Praxis daher nicht mehr als eine gewaltige Lachnummer, die in vielen Fällen zum Totalverlust der Daten geführt hat.

Mit FileVault 2, eingeführt mit OSX- Lion, wurde die Situation erheblich besser, denn FileVault 2 bietet eine transparente Verschlüsselung des gesamten Datenträgers und bringt keinerlei Einschränkungen mit sich; auch ist ein Backup über Time Machine damit problemlos möglich.

Aber auch FileVault 2 ist weit von dem entfernt, was auf iOS seit Version 4 der Standard bei der Datenträgerverschlüsselung ist. iOS-Geräte verschlüsseln jede Datei individuell. Das bedeutet, dass eine granulare Verschlüsselung des Datenträgers auch einzelner Dateien möglich ist, abhängig vom Anwendungsfall.

APFS setzt auf das umfangreiche Schlüsselkonzept (NSFile Protection-Klasse) von iOS auf und unterstützt damit die Verschlüsselung ganzer Volumen, einzelner Dateien und sensibler Metadaten. Das Schlüsselkonzept besteht darin, dass eine Datei mit einem eindeutigen Geräteschlüssel und einem Schlüssel, der aus dem Kennwort des Anwenders abgeleitet wird, verschlüsselt wird. Das schützt zum einen davor, dass ein Angreifer einer Datei außerhalb des Gerätes entschlüsselt (Geräteschlüssel). Zum anderen schützt es davor, dass jemand mit phyischem Zugriff auf das Gerät, z.B. ein Dieb, die Daten entschlüsselt, wenn er das Kennwort des Anwenders nicht kennt. Auf diese Weise ist nicht nur ein Schutz gegen physischen Zugriff gegeben, so wie mit FileVault 2, sondern auch gegen logischer Zugriffe, z.B. über Schadsoftware, die unbefugt auf verschlüsselte Dateien zugreifen möchte.

Etwas, das APFS eEbenfalls von iOS lernen wird, ist die Tatsache, dass der "geheime Schlüssel" zur Verschlüsselung das Enzige ist, was gelöscht werden muß, um die Daten "quasi" zu entfernen.

So unterstützt APFS (anscheinend) die Löschung eines Dateisystems durch Constant-Time-Kryptographie, was in der diskutil-Ausgabe "effaceable" genannt wird. Dies wird vermutlich durch einen geheimen Schlüssel realisiert, der nicht aus APFS extrahiert werden kann und der für die Verschlüsselung des Dateisystems genutzt wird. Für eine sichere Löschung braucht man dann nur den Schlüssel zu löschen, anstatt die komplette Festplatte zu scramblen und re-scramblen, um eine vollständige Löschung zu gewährleisten.

Als Verschlüsselungsverfahren kommt unter APFS entweder AES-XTS oder AES-CBC zum Einsatz, je nachdem, auf welcher Hardware das Dateisystem betrieben wird. Letzteres wird unter anderem auch von OpenBSD, Veracrypt oder DM-Crypt genutzt.

Momentaufnahmen

Mit dem neuen Dateisystem ändert sich die Art und Weise, wie Backups angefertigt werden. APFS kann aufgefordert werden, eine nicht beschreibbare Instanz des Dateisystems als Momentaufnahmen (engl. Snapshot) zu erstellen. Dieser Vorgang kann auch als Einfrieren des gesamten Dateisystems zu einem bestimmten Zeitpunkt bezeichnet werden. Snapshots gehören im Server- und Storageumfeld schon seit vielen Jahren zum täglichen Werkzeug von Administratoren.

Beim Anfertigen eines Snapshots findet erst einmal kein Kopiervorgang als solcher statt. Es wird lediglich markiert, welcher Stand von welcher Datei zu diesem Snapshot gehört. Erst wenn eine Datei nach Erstellen des Snapshots geändert wird, schreibt das Dateisystem die geänderten Blöcke der Datei an eine neue Position auf der Festplatte und APFS registriert, dass diese Änderung nicht zum Snapshot gehörte.

Das heißt: Macht der Anwender einen Snapshot seines Heimverzeichnisses und verändert dann eine Datei, bleibt die Version im Snapshot unverändert.

Was interessant ist, ist, dass dies zu einer völlig neuen Art und Weise führen kann, wie Time Machine funktionieren wird. Derzeit verwendet Apples OS X Backup-Schema ein altmodisches System von harten Links, die von Time Machine gebaut und gepflegt werden. In einer zukünftigen Version von Time Machine würden nur Snapshots stattfinden.

Ein solcher Snapshot kann auch als Rollback genutzt werden, um ein System wieder in seinen Ursprungszustand zum Zeitpunkt des eigentlichen Snapshot zurückzuversetzen. Ein solches Verfahren würde es erlauben, ein System-Upgrade oder eine Software auszuprobieren und am Ende das System bei Nichtgefallen oder technischen Problemen davon wieder zu befreien.

Während Snapshots schreibgeschützt sind, ermöglichen es Klone, gelesen, aber auch beschrieben zu werden. Dies greift beim Kopieren von Dateien oder Verzeichnissen im Dateisystem. APFS kann Datei- oder Verzeichnisklone sofort erstellen, ohne Verzögerung (engl. Copy On Write), so dass die damit verbundenen Daten tatsächlich kopiert werden.

APFS überträgt die Daten nicht Byte für Byte, sondern legt nur einen neuen Eintrag in der Verzeichnisstruktur an, der auf die originalen Daten zeigt. Ändert der Anwender nun das Original oder die kopierte Datei, vermerkt APFS diese und speichert die Abweichungen ab. Damit benötigt dann diese Änderung natürlich auch den entsprechenden Platz auf der Platte.

Die Kopie (der Klon) wird dabei nahezu ohne Zeitverzögerung erstellt. Damit verbraucht das System für eine Kopie nur noch den Platz für die Struktur, keinen für die kopierten Daten - und der Vorgang ist praktisch sofort erledigt. Für den Anwender verhält sich eine geklonte Datei oder ein Verzeichnis somit identisch zu einer Kopie im alten HFS+, nur dass kaum Platz verbraucht wird.

Das Kopieren von Dateien zwischen verschiedenen Speichermedien (z.B. auf einen USB Stick, um sie zu teilen) dauert natürlich noch immer eine gewisse Zeit - proportional zu der Menge der zu kopierenden Daten.

Performance, Performance, Performance

SSDs imitieren die Blockschnittstelle herkömmlicher Festplatten, aber die zugrunde liegende Technologie ist völlig anders. Insbesondere während magnetische Medien Sektoren beliebig lesen oder schreiben können, löscht Flashspeicher große Blöcke (Blocks) und liest und schreibt kleinere Stücke (Seiten). Das Management wird durch das so genannte Flash-Translation-Layer (FTL) gewährleistet. Ein FTL ähnelt dabei einem eigenen Dateisystem, das eine virtuelle Zuordnung zwischen Blockadressen und Orten innerhalb des Mediums erzeugt.

APFS ist ein Dateisystem mit Flash-fähigen Merkmalen, in dem die Dateien in einer Art geschrieben wird, das von einem Flashspeicher leichter behandelt werden kann.

So ist APFS in der Lage, eine Reihe von kurzen und potenziell unabhängigen Speicherbefehle zu kombinieren. Dies ermöglicht es, diese in einem kombinierten Schreibprozess abzuspeichern, um damit die (langsamere) physische Speicherung effizienter zu gestalten. APFS ermöglicht es also, in einer Art und Weise die Daten auf den Datenträger zu speichern, wie es für Flash Speicher einfacher zu handhaben ist.

Für Lösch- und (Wiederbe-)schreib-Vorgänge benötigt eine einfache SSD immer länger für die Datenspeicherung als eine HDD. Dies liegt daran, dass magnetische Festplatten dies in einem Durchgang abarbeiten, eine SSD in zwei Schritten. Wenn eine Datei auf einer SSD über das Betriebssystem gelöscht wird, dann wird auf dem SSD-Laufwerk nur der Eintrag dieser Datei im Inhaltsverzeichnis des Speichers gelöscht, die eigentlichen Daten befinden sich nach wie vor auf der SSD. Mit der Zeit sind so immer weitere Bereiche auf der SSD mit eigentlich gelöschten Daten gefüllt. Beim erneuten Schreiben muss eine SSD diese Zellen erst leeren, bevor sie jene neu beschreiben kann, was die Schreibgeschwindigkeit verlangsamt.

An dieser Stelle setzt der TRIM-Support von APFS an. TRIM ist ein Befehl im ATA-Protokoll, der es einem Dateisystem ermöglicht, einer SSD anzuzeigen, dass etwas Speicherplatz freigegeben wurde und so intern freigeräumt werden können.

Das Problem mit TRIM ist, dass es nur sinnvoll ist, wenn es freien Speicherplatz gibt. Sobald ein Datenträger meistens voll ist, hilft dieses Verfahren nichts. Daher darf davon ausgegangen werden, dass TRIM für APFS-Nutzer ein Placebo-Effekt ist, da Datenträger im täglichen Einsatz häufig sehr gut gefüllt sind und wenig freien Speicherplatz bringt.

OS X unterstützte TRIM bisher nur für Apple-eigene SSDs. Drittanbieter-SSDs hingegen benötigten oft spezielle Dienstprogramme. APFS unterstützt TRIM nun für alle SSD Hersteller.

APFS fokussiert sich auf Latenz bei den eigentlichen Zugriffen und weniger auf Datendurchsatz. Letzteres bieten moderne SSDs und Flashspeicher von Haus aus. Die Latenz hingegen geht APFS mit I/O QoS (Quality of Service) an, indem Zugriffe, die für den Anwender direkt sichtbar sind, gegenüber Hintergrundaktivitäten, die nicht die gleichen Zeitbeschränkungen haben, priorisiert werden. Dies sorgt für kurze Latenzen, um dem Anwender ein besseres Ansprechverhalten des Systems zu geben.

Was sich für Besitzer eines derartigen Speichers positiv anhört, dürfte für Anwender mit drehenden Festplatten nicht die beste Wahl sein. Praxistests müssen hier noch Erfahrungswerte liefern.

Weitere Neuerungen

Im alten HFS-Dateisystem wurden Änderungs- und Erstellungszeitpunkte noch mit einer Präzision von einer Sekunde gespeichert. Mit APFS erhöht Apple dies von einer Sekunde unter HFS+ auf 1 Milliardstel Sekunde (= 1 Nano-Sekunde). Der Sinn dahinter ist, dass das Dateisystem so erheblich genauer den Änderungsverlauf protokollieren und im Falle eines Stromausfalls wieder rekonstruieren kann.

Auch schneidet Apple alte Zöpfe ab. Das proprietäre Apple Filing Protocol, kurz AFP, eingeführt mit System 6 zum Austauschen von Dateien über Netzwerke, wird nicht mehr unterstützt. Die Netzwerkfreigabe von APFS-Volumen erfolgt nur noch das ursprünglich von Microsoft entwickelte und im Unternehmensumfeld verbreitete SMB (Server Message Block). Dieses ist schon seit OS X 10.9 Mavericks das bevorzugte Protokoll für Apple, um zwischen Macs Dateien im Netzwerk auszutauschen.

Aufgrund der breiten Bandbreite an Zielgeräten, angefangen bei der Apple Watch bis zum MacPro, ist ein weiteres Ziel die Schonung der Ressourcen (CPU, RAM).

Migration in der Praxis

Mit iOS 10.3 hat Apple APFS leise und vom Anwender unbemerkt ausgerollt. Wäre nicht die etwas längere Installationszeit für das Update gewesen, man hätte gar nicht bemerkt, dass etwas mehr passiert als nur ein Update.

Trotzdem sind die Vorteile von APFS vorhanden. So ist der Footprint, also der Speicherplatz, den z.B. eine Runtime-Umgebung belegt oder referenziert, einer jeden Swift-App um ca. 6,5 MB gesunken. Was sich auf den ersten Blick vielleicht merkwürdig anhört, ist nur die konsequente Implementierung der APFS-Funktionen. Diese bewirken, dass die Runtime-Umgebung von Swift nicht mehr pro App, sondern nur ein Mal im Dateisystem vorgehalten wird.

Kopiert ein Anwender Dateien innerhalb einer Sandbox oder in eine andere hinein, bewirkt dies keinen zusätzlichen Speicherverbrauch. Bei einem Neustart des iOS-Gerätes bringt APFS zwischen 3-7 Sekunden Performance-Steigerung. Auch das Starten einiger Apps erfolgt nun schneller.

In allen Tests der Autoren verlieft die Migration problemlos und fehlerfrei. Natürlich rät Apple ausdrücklich zum Anfertigen eines Backups vor der Installation von iOS 10.3. Aber das sollte ja auch unabhängig von der Migration des Dateisystems eine Selbstverständlichkeit sein.

Fazit

Apple ist immer wieder für Überraschungen gut. Wurde die Entwicklergemeinde 2014 von der Einführung von Swift vollkommen überrumpelt, war es 2016 die Ankündigung von APFS. Auf der WWDC selber war APFS noch nicht verfügbar und die Beschreibungen dazu noch sehr rudimentär. In etwas mehr als einem halben Jahr hat Apple es seitdem auf iOS schon zur Produktionsreife getrieben. Es bleibt abzuwarten, wie die Migration auf dem Mac passieren wird. Wenn man sich die Liste der noch offenen Punkte anschaut, werden wir darauf allerdings noch ein bisschen warten müssen.

Spannend wird die Frage, wie Apple die neuen Features von APFS so einführt, dass es kein Inkompatibilitäten gibt. Die oben erwähnten Probleme bei der Nutzung von HFS+ mit Groß- und Kleinschreibung werden bei APFS auch vorhanden sein. Apple hat auf solche Herausforderungen in der Vergangenheit entweder mit einem schlauen Kompatibilitätsmechanismus, man erinnere sich nur an Rosetta beim Umstieg vom PowerPC zur Intel-Architektur, oder dem rigorosen Abschneiden alter Zöpfe reagiert. Denkbar ist z.B., dass APFS auf dem Mac vorerst eine Kann-Option ist und der Anwender selber entscheiden muss, es zu nutzen.

Vielleicht stellt Apple die Lösung auch als Open Source zu Verfügung (analog Swift oder ResearchKit). Dieser Schritt wurde von Apple jedoch weder bestätigt noch abgelehnt.

Eins ist sicher: APFS ist ein großer und wichtiger Wurf für Apple. In einer Zeit, wo langjährige Apple-Anwender sich schon länger fragen, ob Apple seinen Fokus nur noch auf Sticker-Apps und bunte Watch-Armbänder legt, ist es sehr erfreulich, dass sich Apple ein für Normalanwender vordergründig so unglaublich uninteressantes und langweiliges Thema wie ein Dateisystem auf die Agenda schreibt. Dabei darf man aber auch nicht vergessen, dass APFS Techniken einführt, die bei konkurrierenden Linux-Systemen seit Jahrzehnten (!) erfolgreich im Einsatz sind. Im Vergleich zum NTFS-Dateisystem, im Windows-Lager, ist Apple jedoch um Meilen voraus.

Ein bisschen weniger bunt, dafür mehr Arbeit am Fundament würde allen Apple-Produkten gut zu Gesicht stehen. (mb)