Wie APFS (Apple File System) 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 (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.

©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.

©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+ 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.

©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.

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 einer 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, vor allem auf alten Magnetfestplatten. 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ückschrumpfen.

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

©Klaus Rodewig und Mark Zimmermann

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 OS -X-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 OS-X-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 eine Datei außerhalb des Gerätes entschlüsselt (Geräteschlüssel). Zum anderen schützt es davor, dass jemand mit physischem Zugriff auf das Gerät, etwa 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 wie mit Filevault 2, sondern auch gegen logische Zugriffe, etwa über Schadsoftware, die unbefugt auf verschlüsselte Dateien zugreifen möchte.

Etwas, das APFS ebenfalls von iOS lernen wird, ist die Tatsache, dass der “geheime Schlüssel” zur Verschlüsselung das einzige ist, was gelöscht werden muss, 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 Storage-Umfeld 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 Nutzer einen Snapshot seines Heimverzeichnisses und verändert dann eine Datei, bleibt die Version im Snapshot unverändert.

Interessant 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 kü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 Snapshots 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 das und speichert die Abweichungen ab. Damit benötigt diese Änderung natürlich auch den entsprechenden Platz auf der Platte.

©Klaus Rodewig und Mark Zimmermann

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 (etwa auf einen USB-Stick, um sie zu teilen) dauert natürlich noch immer eine gewisse Zeit – proportional zur Menge der zu kopierenden Daten.

Performance, Performance, Performance

SSDs imitieren die Blockschnittstelle herkömmlicher Festplatten, aber die zugrundeliegende Technologie ist völlig anders. 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 sogenannte 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.

So ist APFS in der Lage, eine Reihe von kurzen und potenziell unabhängigen Speicherbefehlen zu kombinieren. Diese lassen sich in einem kombinierten Schreibprozess abspeichern, um damit die (langsamere) physische Speicherung effizienter zu gestalten. APFS kann also Daten so auf den Datenträger speichern wie es für Flashspeicher 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 sie 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 intern freigeräumt werden kann.

TRIM ist allerdings nur sinnvoll, wenn es freien Speicherplatz gibt. Sobald ein Datenträger voll ist, hilft dieses Verfahren nichts. Man darf daher davon ausgehen, 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 TRIM wenig freien Speicherplatz bringt.

OS X unterstützte TRIM bisher nur für Apple-eigene SSDs. Drittanbieter-SSDs 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 Nutzer 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 Nutzer 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). Das Dateisystem kann so den Änderungsverlauf erheblich genauer protokollieren und im Falle eines Stromausfalls rekonstruieren.

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 über 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 großen 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 beispielsweise eine Runtime-Umgebung belegt oder referenziert, einer jeden Swift-App um ca. 6,5 MB gesunken. Was sich zunächst 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 bis 7 Sekunden Performance-Steigerung. Auch das Starten einiger Apps erfolgt nun schneller.

In allen Tests der Autoren verlief 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 bleibt, wie Apple die neuen Funktionen von APFS so einführt, dass es keine 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 beispielsweise, dass APFS auf dem Mac vorerst eine Kann-Option ist und der Anwender selber entscheiden muss, ob er es nutzen will.

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

Eines ist sicher: APFS ist ein großer und wichtiger Wurf für Apple. In einer Zeit, wo langjährige Apple-Nutzer 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 das Unternehmen ein für Normalanwender vordergründig so 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 jedenfalls allen Apple-Produkten gut zu Gesicht stehen.