Alors que macOS High Sierra se rapproche, certains s’interrogent sur l’arrivée d’un nouveau système de fichiers sur les Mac : APFS, pour Apple File System. Il remplace le bien ancien HFS+ après près de 20 ans de service. Nous faisons le tour de ses fonctionnalités et apports, afin de mieux cerner ce nouveau venu.
Avant d’évoquer les éventuels bénéfices d’APFS, il faut revenir à ce qu’est un système de fichiers (ou FS, pour File System). Il décrit, dans les grandes lignes, comment les données sont stockées et organisées. Chaque système d’exploitation sait en utiliser un ou plusieurs, et les fonctionnalités liées aux fichiers dépendent directement du FS.
Il définit un très grand nombre d’informations comme le découpage de la partition (ou volume), la taille allouée aux blocs, les métadonnées qui les accompagnent, comment sont codés les caractères, la manière de retrouver les informations, les éventuelles protections contre la corruption des données, les mécanismes de réparation, la taille maximale d’un volume, d’un fichier, la gestion des copies, la possibilité de préserver plusieurs versions d’un même fichier, les droits d’accès, etc.
Pour l’immense majorité des utilisateurs, il s'agit d'un concept flou… quand il est connu. Tout ce que l’on voit en effet, c’est un choix au moment du formatage. Pour le reste, cela se résume le plus souvent dans une interface graphique à une fenêtre affichant des dossiers et des fichiers : des documents, des photos, des archives, des images disques… C’est pourtant le FS qui s’occupe du stockage de ces informations et qui indique à l’OS où les récupérer en cas de besoin.
C'est une méthode de classement, et de ses capacités dépendent bien des comportements. C’est d’ailleurs pour ça qu’il en existe un très grand nombre, car leur usage se fait avant tout en fonction du type de produit auxquels ils se destinent.
Un peu d’histoire
Pour les aficionados de l’informatique, la plupart de ces systèmes de fichiers sont très connus. Sous Windows par exemple, la FAT32 avait ainsi pris le relai de la FAT (File Allocation Table), augmentant drastiquement le nombre possible de clusters (unités d’allocation) et permettant généralement d’en réduire la taille. Une évolution qui illustrait l’importance d’un FS.
Bien sûr, les utilisateurs connaissent surtout NTFS (New Technology File System), largement poussé par Microsoft depuis Windows XP. Il est pour l’instant le système de fichiers par défaut, même si la FAT32 est souvent utilisée pour des périphériques amovibles, puisqu'il est aisé d'y lire et écrire depuis tous les systèmes.
Ces périphériques ont eu plus récemment droit à leur propre FS : exFAT. Mais, comme son prédécesseur, son utilisation passe parfois par une licence spécifique hors des produits de Microsoft. C'est notamment pour cela que Synology fait payer son utilisation via un paquet spécifique disponible pour son DSM. Il existe néanmoins des implémentations libres permettant leur utilisation sous Linux par exemple.
La plupart des distributions utilisent toutefois d'autres systèmes de fichiers. On retrouve les plus connus, tels qu'Ext 2/3/4 dérivés de l'Extended file system. Mais il en existe bien d'autres comme JFS, XFS ou encore ReiserFS. Mais là aussi le paysage évolue avec la montée en puissance de Btrfs, qui offre de nombreux avantages, notamment pour la gestion des instantanés (snapshots). Il est par exemple mis en avant par Synology au sein de ses NAS.
Un petit tour sur la page du Wiki de Debian destinée aux systèmes de fichiers supportés montre que la liste est bien plus longue, mais seuls certains sont destinés au système (R). Il y a une explication simple à cela : un système de fichiers peut aussi prendre la forme d'une implémentation par une application qui vient se rajouter au-dessus d'un FS existant.
Des outils tels que FUSE (Filesystem in Userspace) ou Dokany ont cet objectif. Ils peuvent être utilisés pour de multiples raisons, mais on les retrouve souvent dans des solutions permettant de « monter » un service de stockage dans le « cloud » (rclone par exemple) et proposant parfois l'ajout d'une couche de chiffrement.
Le cas Apple
Du côté d'Apple, le système de fichiers le plus connu est HFS+. Pour une raison simple : il fêtera l’année prochaine son vingtième anniversaire. Bien entendu, comme pour NTFS et autres, ses capacités se sont étendues avec le temps.
Il est lui-même l’évolution de HFS (Hierarchical File System), lancé par Apple en 1985, qui remplaçait alors MFS (Macintosh File System). Les bénéfices étaient alors importants, avec la prise en charge des disques durs qui posaient de nouvelles contraintes de performances. Les quantités de données à gérer devenaient en effet beaucoup plus importantes que les simples disquettes. Il est aussi connu pour avoir été vertement critiqué par Linus Torvalds il y a quelques années.
HFS+, lorsqu’il apparaît avec Mac OS 8.1, a pour mission principale de faire voler en éclats le nombre maximal de clusters sur un volume, alors limité à 65 535. Les adresses passent ainsi du 16 au 32 bits, et Apple en profite pour basculer sur Unicode. En presque 20 ans, HFS+ a évolué à plusieurs reprises, mais son ajout le plus notable reste la prise en charge de la casse (distinction entre minuscules et majuscules) avec Panther (Mac OS 10.3).
La question de son remplacement a commencé à réellement se poser dès la fin 2006 quand – surprise ! – une bêta du futur Leopard (Mac OS X 10.5) présentait tout à coup un support expérimental de ZFS, système de fichiers créé par Sun. Un feuilleton commence alors, Apple n’expliquant guère ce choix.
En juin 2007, le PDG de Sun (alors Jonathan Schwartz) annonce que Leopard utilisera par défaut ZFS. Il n’en sera finalement rien. Nous nous interrogions alors à l’époque sur un éventuel système de fichiers maison.
C’est ainsi qu’entre en scène APFS.
Pourquoi un nouveau système de fichiers ?
20 ans en informatique représentent évidemment une succession de plusieurs âges géologiques. Les évolutions et les attentes ont largement changé. Tout comme HFS avait remplacé MFS pour des questions de performances, APFS veut accomplir la même opération, notamment parce que les disques durs sont progressivement remplacés par les SSD.
Cette transition n’est pour beaucoup qu’une affaire de performances. Oui, un SSD est beaucoup plus rapide qu’un disque dur et on se surprend encore souvent à regarder un ordinateur démarrer en quelques secondes. Mais les SSD demandent des adaptations. Sur Windows par exemple, depuis la version 8, l’indexation et la défragmentation automatique n’y sont même plus activées quand un tel disque est détecté.
Il fallait donc qu’APFS soit aligné sur des besoins modernes. Tirer ce qu’il y a de mieux dans les SSD sans pour autant rejeter les disques durs (et ne surtout pas les rendre plus lents), faciliter le chiffrement ou encore, si possible, la gestion des versions d’un même fichier, le tout avec une grande précision des dates et heures. Et pourquoi pas utiliser le même système de fichiers pour l’ensemble des produits de l’entreprise ?
Des appareils mobiles aux ordinateurs
APFS est en fait déjà déployé sur une partie des gammes d’Apple. Les premiers à en avoir profité sont les appareils sous iOS, avec l’arrivée de la mise à jour 10.3 (à condition que le SoC soit lui-même 64 bits). Dans la foulée, tvOS 10.2 a également installé APFS dans les dernières générations d’Apple TV.
Il s’agissait pour Apple de déployer son système de fichiers sur des produits grand public, mais avec un impact plus limité. Les utilisateurs n’y ont en effet pas accès puisque la gestion des données passe presque exclusivement par les applications. La situation évoluera prochainement avec iOS 11 puisque l’application Fichiers offrira un semblant d'explorateur de fichiers à la plateforme mobile.
Les avantages liés à APFS ne sont guère visibles sur ces systèmes. Le démarrage est un peu plus rapide et beaucoup ont constaté une petite libération d’espace de stockage, davantage liée en fait à la manière dont APFS calcule l'espace disponible. Sur Mac, avec l’arrivée de High Sierra, les bénéfices devraient cependant être nettement plus importants.
Comme indiqué récemment dans un article, le passage à APFS sera obligatoire sur les Mac disposant d’un SSD, alors que le choix était laissé durant la phase de bêta. Les possesseurs de modèles à disques durs pourront refuser la migration.
APFS : caractéristiques principales
Commençons par un petit tour rapide de ses caractéristiques principales. APFS est un système de fichiers 64 bits, ce qui lui permet de stocker un maximum de 9 milliards de milliards de fichiers au sein d’un même volume.
Il a en outre une manière spécifique de diviser l'espace disque. On ne parle en fait plus de partitions mais de volumes, rassemblés dans un ou plusieurs conteneurs. L'allocation des espaces n'est ainsi plus fixe et ces volumes peuvent changer de taille sans opération lourde sur le disque.
L'espace libre rapporté pour chaque volume devient également celui du conteneur. Si ce dernier dispose de 100 Go et contient deux volumes embarquant respectivement 10 et 20 Go de données, l'espace libre signalé pour chacun sera de 70 Go. On peut en fait considérer les volumes comme de simples signalements symboliques d'organisation des données.
Il se base sur Unicode 9.0 et est donc sensible à la casse. Les noms de fichiers doivent impérativement être en UTF-8. APFS permet également de vérifier l’intégrité des métadonnées, de gérer les clones, facilite la création des snapshots (instantanés), et le chiffrement, calcule rapidement les tailles et donc les espaces disponibles, gère les fichiers creux, autorise le partage des espaces.
La plupart de ces fonctionnalités sont destinées à des usages plus professionnels, mais les bénéfices pour l'ensemble des utilisateurs seront également visibles. APFS est en effet et avant tout mis en avant pour son exploitation des SSD, ce qui inclut évidemment le support de la commande TRIM.
L’armée des clones
Lors de tests effectués à la WWDC de 2016, Apple montrait les performances en copie sur un lot de fichiers. Sur le disque utilisant APFS, l’opération était presque instantanée, tandis que la même via HFS+ réclamait une vingtaine de secondes. On s’en doute toutefois, il ne s’agit pas d’un miracle, mais d’une manière très différente de gérer ces opérations.
Dans HFS+, comme dans bien d’autres systèmes de fichiers, la copie de données entraine celles des blocs associés. Dans APFS, ce n’est pas le cas : le Finder peut afficher plusieurs fois le fichier, mais les copies réalisées n'en sont pas vraiment. Ces fichiers ne contiennent en fait que quelques éléments – surtout les métadonnées – qui permettent leur identification, mais pas le contenu. Mais que se passe-t-il si on modifie l’une des copies ?
On entre ici dans l’une des caractéristiques principales d’APFS, qui explique des gains possibles de place sur un disque. Modifier une copie n’entrainera une allocation de blocs que pour les données réellement modifiées. Il s'agit du processus COW, ou copy-on-write, déjà exploité par Btrfs.
Attention, on ne parle ici que des copies au sein d’un même volume APFS. Si vous utilisez un disque dur externe par exemple, et quel que soit son système de fichiers, la copie fonctionnera à nouveau de manière classique. Un emplacement distant, donc y compris réseau, aurait sinon à se référer au contenu local du disque de départ.
Ce fonctionnement a ses avantages et ses inconvénients. Si vous avez besoin de dupliquer un dossier de 10 Go, l’opération sera presque instantanée, et pour cause : seules des métadonnées sont copiées.
Par contre, les opérations de ménage sur le disque demanderont une autre gymnastique. Car beaucoup de fichiers risquent d’apparaître pour ce qu’ils ne sont pas. La notion de fichier source a ici toute son importance car supprimer les copies n’aura que très peu d’effet concret sur l'espace disponible. On compte ici sur les nouveaux outils de nettoyage présents dans macOS High Sierra pour épauler l’utilisateur.
Par ailleurs, le fonctionnement des clones sur la sauvegarde est théorique. En clair, APFS offre ces capacités, mais les applications doivent en tirer parti (via des API spécifiques) pour que l’utilisateur en profite. Ce n’est pas le cas pour le moment et des logiciels comme Word et Photoshop enregistrent des documents entiers quand une modification est apportée sur une copie, aussi légère soit-elle.
Compatibilité : de nombreux points à connaître
Puisque la migration vers APFS est obligatoire pour les SSD, beaucoup auront le nouveau système de fichiers sans qu’on leur demande leur avis. Il est important de connaitre dans ce cas certains points de compatibilité, car il ne s’agit pas d’un changement léger.
Un Mac utilisant APFS pourra donc lire et écrire sur l’ensemble des partitions et volumes en APFS ou HFS+. Un Mac utilisant HFS+ pourra également écrire sur un volume APFS si la mise à jour 10.12.6 de Sierra est installée. Pour démarrer sur un tel volume, il faudra cependant que High Sierra soit présent.
La migration vers APFS pose également certaines questions sur les fonctions de macOS. FileVault ? Aucun problème. Partages réseau ? Idem, à condition qu’ils utilisent NFS ou SMB, AFP n’étant plus pris en charge. Time Machine et ses Time Capsules ? Pas de soucis non plus, si les disques utilisés ne sont pas retouchés. Un point détaillé un peu plus loin.
Les deux seuls vrais cas d’incompatibilité concernent les volumes Boot Camp. Ainsi, s’ils dépassent les 3 To et se trouvent sur un Fusion Drive, la migration vers APFS ne se fera pas. Un cas assez spécifique.
Par contre, et c’est beaucoup plus ennuyeux, un Windows installé via Boot Camp ne pourra ni lire ni écrire dans un volume APFS... en tout cas pour l'instant. Un point qui risque d’avoir de fortes conséquences pour ceux qui récupéraient des données sous Windows depuis leur partition macOS.
Les snapshots à la rescousse
Les instantanés sont une autre fonctionnalité phare d’APFS, que les utilisateurs ne verront pas forcément. Le principe est connu de longue date, particulièrement de ceux qui manipulent régulièrement des machines virtuelles. Le système crée ainsi une capture de son état à un instant « t ». En cas de problème, on peut alors y revenir.
Comme expliqué dans la documentation d’Apple, les snapshots sont des instances en lecture seule correspondant à l’état du système de fichiers à un moment précis. APFS peut alors traquer les modifications depuis le dernier snapshot pour que le suivant ne prenne en compte que celles intervenues entre temps.
Le fonctionnement de ce dispositif pose immédiatement la question : cette fonctionnalité d’APFS est-elle compatible avec Time Machine, dédiée justement à la sauvegarde régulière des données utilisateurs et gérant les versions ? On entre ici – et pour l’instant – dans une zone grise.
Nous avons procédé à quelques tests sur la dernière bêta (9) de High Sierra. Une fois branché un disque dur disposant d’une partition formatée en HFS+, le système n’a aucune difficulté pour s’en servir comme destination Time Machine. Puisque l’Utilitaire de disque propose une conversion, nous avons voulu savoir si High Sierra pouvait également utiliser un volume externe en APFS. La conversion a fonctionné, mais Time Machine n’en voulait plus.
En clair, actuellement, la fonction de sauvegarde automatisée n’accepte que des disques externes en HFS+, que l’Utilitaire de disque appelle Mac OS Étendu journalisé. Si la conversion d’un tel disque vers APFS ne pose aucun problème (tant qu’il ne possède pas une autre partition FAT32 ou NTFS, ce qui provoque une erreur), Time Machine ne peut ensuite plus l’utiliser. Formater intégralement le disque externe n’y changera rien.
Un point sur lequel on espère qu’Apple communiquera pour prévenir des risques. Actuellement, si on se fie à la note publiée récemment sur les questions pratiques d’APFS, la société se contente de dire que les sauvegardes existantes continueront d’être exploitables et que Time Machine continuera de fonctionner. Rien n’est indiqué sur l’utilisation d’un volume APFS, sauf de manière détournée : APFS change les liens « en dur » par des liens symboliques et alias.
Et l’intégrité des données alors ?
Chaque système de fichiers un tant soit peu moderne dispose d’un ou plusieurs mécanismes dédiés à l’intégrité des données. Après tout, c’est une priorité réclamée sans mot dire par l’utilisateur : il compte avant tout sur une récupération de ses documents. APFS n’y fait pas exception.
Il y a encore ici des hauts et des bas. Par exemple, les clones de fichiers évoqués plus haut peuvent se retourner contre l’utilisateur en cas de corruption matérielle du disque. Si un incident touche le fichier source, tous ses clones en seront affectés. Apple compte en fait sur les fameux snapshots pour restaurer les éventuelles données corrompues. On rappellera au passage l'intérêt des sauvegarde et de l'utilisation de volumes RAID avec protection des données.
La société indique également que la mécanique Error Correcting Code (ECC) sera toujours utilisée. Elle permet de vérifier l’intégrité des données pendant leur transfert, avec correction à la volée si nécessaire. Rien de bien nouveau ici. Par contre, la société ajoute l’algorithme Fletcher pour créer des sommes de contrôle (checksum) sur les métadonnées.
La journalisation est pour sa part toujours présente, même si elle change de mécanique puisque c’est le copy-on-write qui est utilisé pour la traçabilité des opérations. Apple promet que l’installation des mises à jour du système est totalement protégée. En fait, c’était – théoriquement bien sûr – déjà le cas avant, mais la journalisation impliquait une copie complète des données. Encore une fois, avec le copy-on-write, seules les modifications réelles sont enregistrées.
Chiffrement : peu d'informations en pratique
Même s’il ne s’agit pas du chapitre le plus étoffé, le chiffrement reste un point crucial d’APFS. L’un de ses objectifs est en effet de le simplifier en supportant de manière « native » deux scénarios, à savoir avec clé unique (par volume) ou clés multiples. Dans ce deuxième cas, il est possible d’affecter une clé différente pour chaque fichier concerné, et encore une autre pour les métadonnées jugées sensibles.
Dans tous les cas, c’est AES-256 qui sera utilisé pour le chiffrement. Dans sa documentation destinée aux développeurs, Apple précise que la variante utilisée (AES-XTS ou AES-CBC) dépendra du matériel.
Fichiers creux et Space sharing
Les fichiers creux, ou « sparse files » sont intimement liés à la manière dont APFS gère globalement les fichiers et l’espace de stockage. Les poids des données n’est pas toujours représentatif et on entre davantage dans les informations symboliques.
Les fichiers creux (ou troués) sont une manière de déclarer qu’un espace quelconque est réservé. Ils ont plusieurs utilités. Par exemple, réserver une place en prévision du « remplissage » futur du fichier. Ils peuvent également servir à marquer « plus efficacement » – selon Apple – les blocs vides sur un disque.
Il s’agit donc de structures logiques et non physiques. L’espace n’est réellement alloué qu’en cas de besoin. Puisque l’on se trouve encore une fois devant une information devenue symbolique, les API associées permettront aux développeurs de récupérer à la fois les poids physique et logique des fichiers, tout en autorisant des manipulations fines de leurs contenus.
Des détails manquent encore à l'appel
Le potentiel d'APFS est conséquent, ses caractéristiques en faisant très clairement un système de fichiers tourné vers le futur. Signalons quand même quelques points pour tempérer les éventuels effets d'annonce de l'entreprise. Par exemple, la déduplication et la compression des données ne sont pas présentes, même si au vu du fonctionnement global, il n'est pas certain qu'elles soient très utiles.
Ensuite, une bonne partie des fonctionnalités présentées ne sont pas nouvelles. Il suffit d'examiner de plus près Btrfs dans les distributions Linux pour se rendre compte qu'il propose déjà depuis plusieurs années le copy-on-write, les sommes de contrôle ou encore les snapshots. Par ailleurs, ces mêmes fonctionnalités demandent à être exploitées par les développeurs pour en tirer un véritable avantage. Et c'est d'ailleurs ici que l'on entre un peu dans le flou.
APFS n'étant pas open source – et Apple n'ayant aucune intention de l'ouvrir – il faudra se contenter de la documentation mise à disposition des développeurs. Or, celle-ci est pour l'instant assez succincte. Dans sa FAQ, Apple précise que des spécifications complètes seront publiées. Quand ? L'éditeur ne donne aucune indication précise. En attendant, aux concepteurs d'applications de s'adapter avec les informations à leur disposition.
