Fermer le menu
 

APFS : le futur système de fichiers d’Apple qui va changer votre vie

Mickaël Bazoge | | 20:49 |  187

Edit : cet article a été rédigé peu après la WWDC de juin 2016. Nous le remontons dans le flux car Apple a posé les premiers jalons d'APFS dans la première bêta d'iOS 10.3.

C’est un peu malheureux, mais lors du keynote de la WWDC, Apple a passé plus de temps à annoncer que les émojis de Messages seront trois fois plus gros dans iOS 10 qu’à faire l’article d’APFS. D’ailleurs, le nouveau système de fichiers qui sera au cœur de macOS, iOS, watchOS et tvOS n’a tout simplement bénéficié d’aucune annonce durant la conférence !

Eric Tamura et Dominic Giampaolo ont eu l’honneur de présenter APFS aux développeurs présents à la WWDC.

On peut le regretter, même si un système de fichiers est évidemment moins sexy que des émojis et d’autres fonctions flashy (lire : Keynote : des emojis, mais pas de système de fichiers). Mais APFS a ensuite fait l’objet d’une présentation en profondeur lors d'une session dédiée, et on peut retrouver sur le Dev Center une documentation qui dresse les grandes lignes de cette nouveauté majeure.

Durant la WWDC, Apple a également invité les développeurs présents à participer à des séances de questions/réponses avec les ingénieurs qui ont mis au point APFS. Adam Leventhal a participé à cette session et il en a livré un récit aussi complet que possible sur son blog. Nous avons puisé dans ces observations ainsi que dans les docs d’Apple pour faire le point sur ce système de fichiers qui devrait assurément bousculer les habitudes.

Qu’est-ce qu’un système de fichiers ?

Un système de fichiers est une des briques de base d’un système d’exploitation. C’est ce qui permet à l’OS de stocker et d’organiser les données dans des supports de stockage internes et externes. Conservées dans des suites de blocs dont le contenu est lié au format des fichiers (caractères, adresses mémoires, etc.), les informations peuvent ensuite être exploitées par les applications.

À l’intérieur du MacBook 12’’ Retina (image iFixit).

Sans système de fichiers, l’information serait placée en vrac dans un espace de stockage dans lequel il serait impossible de dire où commence et où s’arrête telle ou telle donnée. Avec des capacités de stockage toujours plus importantes, il a fallu adapter les systèmes de fichiers pour qu’ils se montrent plus efficaces.

Toute cette machinerie est invisible pour l’utilisateur, qui s’attend à retrouver ses dossiers et ses documents aux endroits où il les a laissés, le tout présenté d’une manière cohérente et hiérarchique.

Quels sont les systèmes de fichiers utilisés par Apple ?

Sans remonter aux temps immémoriaux de DOS 3.x (également connu sous le sobriquet Apple DOS) de l’Apple II, le constructeur place MFS (Macintosh File System) au cœur du premier Macintosh. Il a rapidement été remplacé par HFS (Hierarchical File System) en septembre 1985. Il s’agit alors de prendre en charge le premier disque dur (20 Mo) que le constructeur a conçu pour son Mac, alors que MFS n’était optimisé que pour les lentes disquettes de petites capacités de l’époque.

En 1998, Apple lance le successeur de HFS avec Mac OS 8.1, HFS Plus. Cette version améliorée de HFS supporte des adresses 32 bits au lieu des 16 bits de son prédécesseur, et elle utilise Unicode en replacement de Mac OS Roman pour nommer les fichiers et documents.

Avec Mac OS X 10.3, Apple met à jour HFS Plus en y apportant la sensibilité à la casse, mais de nombreux logiciels ne sont pas compatibles et sont susceptibles de planter. Durant ses 18 ans d’existence, HFS+ a évidemment été adapté aux besoins d’Apple, et s’il continue de rendre bien des services, le système de fichiers accuse depuis trop longtemps le poids des années. « HFS+ est certainement le pire système de fichiers jamais créé. Dieu que c'est de la merde ». Ainsi Linus Torvalds, créateur de Linux, qualifie-t-il le système de fichiers d'OS X dans sa langue fleurie.

On a un temps imaginé qu’Apple allait le remplacer par ZFS (Zettabyte File System). Les capacités de ce système de fichiers 128 bits développé par Sun Microsystems pour Solaris 10 sont tellement importantes qu’il faudrait faire « bouillir les océans » pour remplir un espace de données 128 bits, d’après son créateur Jeff Bonwick !

La prise en charge de ZFS annoncée sur le site d'Apple.

En décembre 2006, une bêta de Mac OS X 10.5 affiche une prise en charge très préliminaire de ZFS, une présence suivie par une annonce fracassante de Sun Microsystems : ZFS deviendra bien le système de fichiers par défaut du Leopard ! Las, après avoir joué au chat et à la souris dans les bêtas suivantes, ZFS n’est plus proposé que dans Snow Leopard Server et encore, en lecture seule (lire : La saga ZFS n'en finit plus).

Pourquoi Apple a-t-elle ainsi joué avec les nerfs de ceux qui attendaient fébrilement un système de fichiers moderne ? Des problèmes de licence ont grippé la machine, et on a appris tout récemment via Ars Technica que des problèmes d’égo sont aussi rentrés en ligne de compte. Apple n’aime rien tant que les choses développées en interne, et plusieurs cadres de l’entreprise préféraient bâtir leur propre solution plutôt que d’en adopter une conçue à l’extérieur — même si cette technologie était la meilleure à l’époque.

De plus, ZFS a été imaginé d’abord et avant tout pour les serveurs, pas pour les ordinateurs de monsieur tout le monde, et encore moins pour des appareils mobiles. Or, à cette époque, Apple était en plein développement de l’iPhone premier du nom. Les équipes en charge de la conception d’iOS ont créé une déclinaison d’HFS si secrètement que leurs homologues d’OS X n’en ont d’ailleurs rien su…

Catégories: 
Tags : 

Les derniers dossiers

Ailleurs sur le Web


187 Commentaires Signaler un abus dans les commentaires

avatar béber1 25/01/2017 - 09:37

reborn
"De cette manière un volume icloud pourrait apparaître dans le finder au même titre d'un disque local."

tiens, cela me rappelle l'iDisk de feux iTools, .Mac, Mobile.Me…
Vieille idée (~2000) qui aura mis pas mal de temps à se stabiliser

avatar bbtom007 28/06/2016 - 20:13 via iGeneration pour iOS

J'espère qu'il sera dispo en or rose

avatar Alexharez 28/06/2016 - 21:18 via iGeneration pour iOS

@bbtom007 :



avatar Alexharez 28/06/2016 - 21:21 via iGeneration pour iOS

@alexharez :
1

avatar MacGyver 28/06/2016 - 23:46

+1
et si ils y avaient pensé plutot, ils auraient pu passer plus de temps dessus lors de la keynote

avatar byte_order 29/06/2016 - 08:54 (edité)

si c'est pas dispo en bleu profond, j'installe pas !

avatar adixya 30/06/2016 - 02:00 (edité)

Oui et j'espère que les emojis seront 5 fois plus gros !!

avatar guillrun 28/06/2016 - 20:14 via iGeneration pour iOS

Ou est ios 10 beta 2 ????

avatar cloudy 28/06/2016 - 20:19

Et on doit légitimement pouvoir espérer que des applications comme Docker pourront profiter de ces évolutions.

La dernière mouture native pour Mac (en beta) a encore pas mal de soucis de perf liés aux Filesystem.
C'est environ 100 fois plus lents que les autres plateformes.

Je suis pas un expert mais je pense qu'un nouveau FS peut apporter beaucoup. Et les gars de Docker utilisent en général bien ce genre de chose (ex: voir ce qu'ils font avec Btrfs sur Linux).

avatar PierreBondurant 28/06/2016 - 20:27 via iGeneration pour iOS

Est ce que qqun sait si avec ce nouveau système de fichier l'OS peut détecter des erreurs d'écriture quand il effectue la copie d'un fichier et prévenir l'utilisateur ?

avatar fousfous 28/06/2016 - 20:31 via iGeneration pour iOS

Ça peut signifier quelque chose le fait que sous le capot tout les OS d'Apple fonctionneront pareil, ça va peut-être ouvrir la voie aux apps iOS sur macOS et même ARM sur Mac.
Surtout que l'année prochaine c'est la grosse mise à jour pour les Mac!

avatar iGeek07 28/06/2016 - 21:06 via iGeneration pour iOS

@fousfous :
Je peux vous assurer que ce n'est pas le système de fichier qui est un quelconque frein pour faire tourner les applications iOS sur Mac…

avatar C1rc3@0rc 29/06/2016 - 01:32 (edité)

@fousfous

Ben jusqu'a preuve du contraire, iOS fonctionne déjà avec le meme FS que MacOS, vu qu'iOS c'est deja MacOS a 95%.

La raison pour laquelle MacOS ne tourne pas encore sous ARM est marketing, pas technique. Au niveau puissance l'A9x est deja plus puissant que les x86 de nombreux modeles de Mac, a commencer par le Macbook.

avatar fte 29/06/2016 - 07:45 via iGeneration pour iOS

@C1rc3@0rc :
La preuve du contraire a été donnée pendant la WWDC. Des ingénieurs ont clairement dit que les devices iOS utilisent une version modifiée d'HFS et qu'APFS unifiera ces différences.

Quant aux ARM, aucun n'est plus puissant que les processeurs Core d'Intel. Ni en multithread, ni en monothread.

avatar byte_order 29/06/2016 - 08:39

Sans oublier qu'entre proposer une version ARM d'un seul code, macOS, et pouvoir disposer de l'ensemble des logiciels que vous avez besoin en version ARM également, il y a une grosse différence.

avatar fte 29/06/2016 - 10:09

Ah ça, c'est clair.

Une des forces de l'architecture ARM est d'incorporer des cores asymétriques. Par exemple deux cores puissants et un core beaucoup moins puissant, mais très économe en énergie. C'est une possibilité fantastique lorsque l'énergie est une ressource limitée et précieuse, mais au prix de performances de pointe très affectées.

Intel privilégie des cores symétriques, tous identiques, et de varier considérablement leur fréquence de fonctionnement. C'est un peu moins efficace pour économiser l'énergie.

avatar C1rc3@0rc 29/06/2016 - 10:47

Ben non c'est pas clair du tout

Deja il ne s'agit pas d'une architecture asymétrique chez ARM comme dans le cas du Cell mais de deux set de core juxtaposés (heterogenes), un set étant optimisé pour la puissance l'autre pour l'économie.
L'approche n'est pas stupide, et est bien plus efficace qu'un contrôle de l'alimentation mais elle ne vaut que pour des situations ou l'on a une exploitation mixtes bien délimité et durables: ce qui est pertinent sur du smartphone qui passe l'écrasante majorité de son temps a ne rien faire. Sur une tablette ça a déjà moins de sens et sur un PC c'est contreproductif.

Le big.LITTLE est une option de montage mais n'est pas la norme.
Apple ne l'utilise pas et pourtant ses processeurs sont au sommet en terme de puissance et d'efficacité énergétique.

De son coté Intel a développé une approche batarde qui fait qu'avec le TDP dynamique et la capacité de throttling des core controlés par l'unité de gestion électrique du processeur on arrive a un systeme virtuellement asymétrique impossible a contrôler de l'extérieur.
De plus Intel a ajouté tellement de coprocesseurs spécialisés pour compenser la déficience des Core x86 que l'on est face a une architecture hétérogène qui ressemble a la cuisine du diable.

Ce qui plombe le x86 c'est pas le montage du processeur, c'est la complication du core causé par l'architecture x86. Si on supprime la couche nécessaire aux traitements du code x86, on fait un bon d'efficacité énergétique considérable!

Ensuite, passer d'applications x86 a ARM c'est une question de respect des API et de recompilation. Dans le meilleur des cas c'est une case a cocher, dans le pire faut reecrire les parties d'optimisation x86, ce qui pour la majorité des soft n'existe pas...
Et avec des applications écrites en Swift, ce devrait être aussi transparent que compiler pour iPhone et iPad...

avatar fte 29/06/2016 - 13:08 via iGeneration pour iOS

@C1rc3@0rc :
OK alors là la concentration d'inepties bat des records. Je ne vais même pas essayer. Wow.

avatar C1rc3@0rc 29/06/2016 - 11:03

@fte
«Des ingénieurs ont clairement dit que les devices iOS utilisent une version modifiée d'HFS et qu'APFS unifiera ces différences. »

Ce qui est important c'est de savoir a quel niveau se situent ces différences précisément: tres bas niveau pour prendre en charge le SSD et codé en assembleur ARM?
Après on peut aussi dire que l'OS dans les très bas niveau est très different sur MacOS et sur iOS: autant que les sont les architecture x86 et ARM, car c'est évident, au bas niveau on va pas gérer du code ARM avec du code x86...

«Quant aux ARM, aucun n'est plus puissant que les processeurs Core d'Intel. Ni en multithread, ni en monothread.»

Si, plus puissants que le Core M a consommation équivalente. Et similaire au Core i3 et i5 en consommant moins. Et pitié ramènes pas les bench en mode surperturbo.

La supériorité de l'architecture ARM est de toute façon mathématique, la complication de l'architecture x86 nécessite pour son seul traitement une population entière de transistors et des aller-retours en mémoire qui sont évités avec l'architecture ARM.
Et cela n'est pas récent: le x86 a été conçu pour monter en puissance sans se soucier de l'efficacité énergétique, qui elle, repose sur la finesse de gravure 9et donc depuis le passage sous les 90nm ça stagne grave. Et en plus le x86 s'est écrasé contre le mur des 4Ghz...

avatar BeePotato 29/06/2016 - 10:02

@ C1rc3@0rc : « Ben jusqu'a preuve du contraire, iOS fonctionne déjà avec le meme FS que MacOS »

Pas tout à fait. Ça a bien été précisé lors de la session de la WWDC consacrée à APFS (oui, il y en a bien eu une, ce qu’on peut compter comme une « annonce principale » pour les développeurs :-P).

Reste qu’effectivement, ça n’a aucune influence sur ce dont parle foufous.

avatar C1rc3@0rc 29/06/2016 - 02:08

@PierreBondurant

Ben heu le contrôle d'intégrité c'est une base du FS, voir meme simplement au niveau du driver, donc sur ça échoue la copie échoue. Apres a charge de l'OS de recommencer ou d'avertir l'utilisateur. Mais HFS le fait bien évidemment...

Avec APFS il semble qu'Apple compte beaucoup (trop) sur la fiabilité des composants. Le CRC du FS ne peut pas etre remplacé par le ECC!

avatar fte 29/06/2016 - 09:45

Non, le contrôle d'intégrité n'est pas une base des FS. Certains le font, la majorité non. Et quelle intégrité ? Des structures du FS ? Des métadonnées ? Des extended attributes ? Des datas ?

Le CRC du FS ne veut rien dire. De plus un ECC, error correcting code, est beaucoup plus sophistiqué et permet des récupérations d'erreurs, là ou un CRC, cyclic redundancy check, ne permet que de détecter qu'une erreur s'est produite sans pouvoir rattraper le coup. Un CRC peut tout à fait être remplacé par un ECC.

avatar PierreBondurant 29/06/2016 - 10:40 via iGeneration pour iOS

@C1rc3@0rc :
Merci.

avatar dumas75 28/06/2016 - 20:29

P => Protocole

avatar byte_order 29/06/2016 - 11:56

Un protocole est une convention de communication d'information.
Un système de fichier est une convention d'organisation du stockage de l'information. Sémantiquement, on ne parle pas de protocole dans ce cas là.

De toute façon le P est là pour distinguer APFS de AFS, un système de fichier qui existe déjà.
Je pense que APFS étant destiner à être déployer sur toutes les plateformes d'Apple que le P vaut pour "Platforms", plutôt.

Pages