APFS : plongée dans le nouveau système de fichiers d’Apple
Un quoi ?
Le 07 septembre 2017 à 06h45
19 min
Logiciel
Logiciel
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.
Le 07 septembre 2017 à 06h45
APFS : plongée dans le nouveau système de fichiers d’Apple
-
Un peu d’histoire
-
Le cas Apple
-
Pourquoi un nouveau système de fichiers ?
-
Des appareils mobiles aux ordinateurs
-
APFS : caractéristiques principales
-
L’armée des clones
-
Compatibilité : de nombreux points à connaître
-
Les snapshots à la rescousse
-
Et l’intégrité des données alors ?
-
Chiffrement : peu d'informations en pratique
-
Fichiers creux et Space sharing
-
Des détails manquent encore à l'appel
Commentaires (66)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 07/09/2017 à 07h39
#1
Qu’en est il de la compatibilité avec des systèmes tiers ? Existera t’il un driver APFS pour Windows ? Pour Linux ?
Le 07/09/2017 à 08h00
#2
Il n’en existe pas pour NTFS de façon “officielle” en écriture alors " />
Le 07/09/2017 à 08h00
#3
La réponse est à lire entre les lignes dans l’article.
Le système est fermé et la doc encore très maigre. Apple ne fera sûrement pas de driver pour Linux, et probablement pas pour Windows non plus (actuellement, les drivers HFS+ pour bootcamp sont fait par des tiers il me semble).
La seule possibilité de voir ça arriver sous Linux est donc que la doc soit assez fine ou que des devs motivés passent assez de temps pour comprendre le fonctionnement et pour faire du reverse engineering.
Le 07/09/2017 à 08h40
#4
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.
Tu t’avances un peu sur ce point…
On en sait rien si Apple compte l’ouvrir ou pas. Comme le reste de leur comm’, c’est “on dit rien”.
Apple gère directement un certain nombre de projets opensource fondamentaux pour le fonctionnement de leurs OS (dont notamment CUPS, LLVM, Webkit et d’autres), il intègre aussi beaucoup d’opensource (Apache, java, Python, Tcl/Tk, shells, openssh, etc) et libère (parfois) des technos maison (comme Dispatch ou Swift).
Donc ça me parait assez rapide d’arriver à la conclusion “Apple n’ayant aucune intention de l’ouvrir”…
Le 07/09/2017 à 08h56
#5
Boot Camp propose un pilote HFS+ en lecture par Apple (très utile pour lire un disque externe sur un PC, d’ailleurs). Par contre, en écriture, c’est uniquement des pilotes tiers.
Le 07/09/2017 à 08h57
#6
En réalité… si. Il a juste jamais été rendu publique. Snow Leopard pouvait écrire sur du NTFS avec le pilote Apple (mais fallait l’activer manuellement). Visiblement une histoire de licence.
Le 07/09/2017 à 08h58
#7
Tout à fait, mais ce sont soit des produits existants auxquels ils participent, soit des technos de dev pour suivre le mouvement général dans ce domaine (Facebook, Google et Microsoft font pareil). Dans le cas d’une techno à eux par contre, j’attends vraiment de voir. Cela dit, je serais très heureux de me planter ;)
Le 07/09/2017 à 09h08
#8
> Les poids des données n’est pas toujours représentatif et on entre davantage dans les informations symboliques.
Ne le prenez pas mal mais je vous jure, des fois, je ne comprends rien à vos phrases. C’est tellement flou et abstrait. On entre davantage dans les informations symboliques? Qu’est ce que ça peut bien vouloir dire concrètement? J’ai du aller voir ce qu’est un sparse file sur wikipedia pour comprendre tout le paragraphe en fait. Aussi le fait que vous traduisiez logical par symbolique est pas inintéressant en soit (et probablement plus juste que logique), mais vu que c’est pas la pratique (autant que je sache) je trouve que ça ajoute à la confusion plus qu’autre chose. Enfin, c’est titré Fichiers creux et space sharing, mais ça ne parle pas du tout du space sharing, si j’ai tout compris.
> Signalons quand même quelques points pour tempérer les éventuels effets
d’annonce de l’entreprise. Par contre, la déduplication et la
compression des données ne sont pas présentes.
Bon là j’ai compris, mais y a un problème de construction de(s) la phrase je pense.
Le 07/09/2017 à 09h09
#9
Le 07/09/2017 à 09h10
#10
Le snapshot/cow est un confort inégalable quand on commence à administrer des gros volumes de données (backup, versioning…).
La contrainte c’est de gérer correctement les snapshots pour éviter d’engorger les disques avec des versions obsolètes des fichiers. C’est si facile de faire un snapshot et d’oublier de le supprimer. " />
Le 07/09/2017 à 09h17
#11
Salut .o/
Je ne comprends pas bien cette partie :
« 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. »
Du fait de la formulation de ce passage en particulier, j’aurais tendance à croire que c’est supposé remplacer MBR et GPT… ou que c’est un genre de couche intermédiaire ?_?
Le 07/09/2017 à 09h19
#12
Si je lis bien, c’est un système qui gère le disque entier, et non pas une des partitions tells que définies par un MBR ou un GPT ?
Du coup, le système d’amorce de la machine, bios ou autre doit pouvoir lire ça ?
edit: je me suis fait cramer…" />
Le 07/09/2017 à 09h22
#13
Ils ont parlé de specs, mais bon il reste quand même une différence nette entre une techno open source avec la licence qui l’accompagne, et des specs suffisamment détaillées pour permettre des implémentations. Bon après comme tu dis, tant que c’est assez détaillé, ça devrait suffire. Et puis ça concerne les devs de produits plus spécifiques, la plupart des applications n’ont pas besoin d’aller trafiquer de manière aussi profonde dans le FS, elles appellent simplement les API système pour faire leur tambouille.
Le 07/09/2017 à 09h34
#14
Question benoîte d’un néophyte en la matière: j’ai un compte dropbox, synchronisé entre un PC sous W10, et un MBA. Je n’ai jamais eu de problème jusqu’à maintenant avec la synchro ou avec l’ouverture des fichiers sur l’un ou l’autre. Cela veut-il dire que Dropbox assure le lien entre les deux? Que les fichiers sont convertis pour être compatibles avec chacun des file systems? Comment ça marche, concrètement, pour éviter les problèmes? Parce que j’ai déjà essayé de brancher mon hdd externe avec des fichiers venus de mon PC sur mon Mac, et là j’ai eu des soucis…
merci d’avance de vos réponses! " />
Le 07/09/2017 à 09h38
#15
en théorie, si on veut garder HFS+ sur un ssd :
-clone du SSD vers DD externe
-boot sur celui ci, màj du système
-choix de rester en HFS+
-reclone dans l’autre sens
" />" />
Non ? " />
Le 07/09/2017 à 09h40
#16
chaque version de Dropbox (Win ou OSX) s’appuie sur le FS local pour lire et écrire les fichiers, ça ne devrait pas poser de soucis.
Mais si c’est sensible pour toi, attends quelques semaines avant de migrer ;)
Le 07/09/2017 à 09h43
#17
Dropbox utilise une application/logiciel sur ton windows ou ton osx. Cette application, download/upload le fichier, dans un format qui lui est propre. Et pour le stocker sur le disque, il demande au système (win/osx) : range moi ces données (le fichier) sous le nom /User/dropbox/monfichier.toto. Le système délègue cette opération au filesystem.
Le système permet ensuite de retrouver le fichier quand tu lui donne le nom. C’est ça le filesystem
Pour ton HDD externe, t’as branché, OSX a vu ton disque, s’est demandé quoi en faire. Il a du se dire, tiens c’est du NTFS, connais pas.
Le 07/09/2017 à 09h46
#18
Et on sait où ça en est la relève de NTFS chez Microsoft? Je crois que ça s’appelle WinFS…
Sinon, ReiserFS, ça c’est du filesystem qui tue.
Le 07/09/2017 à 10h00
#19
Le 07/09/2017 à 10h05
#20
Le 07/09/2017 à 10h08
#21
Le 07/09/2017 à 10h14
#22
@jb&_V ET @uzak –> OK, merci, c’est très clair comme cela :-)
Le 07/09/2017 à 11h17
#23
Bel article :)
Le 07/09/2017 à 11h48
#24
Wow super article ! Ce APFS semble assez prometteur " />
Le 07/09/2017 à 13h01
#25
Le 07/09/2017 à 13h18
#26
Bon, je ne sais pas encore ça marche avec APFS, mais de ce que je comprends c’est le même principe que pour ZFS. Donc en pratique et dans l’idéal, APFS utilisera tout l’espace du disque (comprendre une seule partition physique).
Si on veut utiliser plusieurs systèmes de fichiers APFS (genre 1 pour /, et un autre pour /home), il ne sera pas nécessaire de créer d’autre partition : APFS les fait cohabiter dans le même espace, ce qui fait que pour un DD de 100Go, les 2 systèmes de fichiers peuvent utiliser la totalité des 100Go sans avoir à se préoccuper de combien donner à l’un ou à l’autre au préalable, et aura pour espace disponible l’espace total restant sur la partition : le premier qui remplit le disque a gagné !
Si on souhaite faire cohabiter une autre type de système de fichiers, comme du NTFS pour faire un Boot Camp, alors on crée 2 partitions sur le disque, une pour NTFS et une autre pour APFS, et les systèmes de fichiers APFS se partageront cette partition.
En fait, je crois que la confusion vient du fait qu’on a tendence à confondre partition et système de fichier, puisque historiquement on trouve en général un seul système de fichiers sur une partition.
Après, ZFS permet d’étendre l’espace (le pool) sur plusieurs disques en fonctionnant un peu comme un RAID logiciel, mais je ne sais pas si APFS a vocation à en faire autant.
Le 07/09/2017 à 13h23
#27
Le 07/09/2017 à 13h32
#28
A quand un dossier similaire sur ReFS de Microsoft ? Merci.
Le 07/09/2017 à 14h42
#29
Bel article, merci
Le 07/09/2017 à 14h44
#30
Le 07/09/2017 à 15h44
#31
Vu les décisions récentes de MS en la matière, pas sûr que ce soit très utile…
Le 07/09/2017 à 15h47
#32
De quelles décisions récentes parlez-vous?
Le 07/09/2017 à 15h51
#33
Voir les détails ici : https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-de…
Le 07/09/2017 à 16h09
#34
Le 07/09/2017 à 17h04
#35
Le 07/09/2017 à 18h19
#36
Le 08/09/2017 à 05h20
#37
Un peu de lecture, en français en plus (sur linuxfr) : BTRFS ne serait plus le futur
Ce que j’en avais retenu c’est que RHEL (distrib orientée professionnels) a retiré le support car elle propose un support sur une très longue période de temps (5 à 10 ans) sur la même version du noyau, ce qui l’oblige à rétroporter toutes les modifications. Elle n’a pas les moyens/l’expertise de le faire pour Btrfs.
C’est en revanche le FS par défaut sous OpenSUSE. Tu peux consulter une série d’article sur ses fonctionnalités en consultant les journaux écrits par AR7 sur linuxfr.
Le 08/09/2017 à 05h55
#38
Le 08/09/2017 à 07h45
#39
Bon, après, je m’aperçois que peu de gens semblent connaître VSS sous Windows.
Ce VSS sert surtout à figer le système de fichier pendant des copies pour éviter de faire des copies “partiellement correctes” de fichiers en cours d’écriture. C’est notamment utilisé pour les sauvegarde sur d’autres supports.
Mais c’est aussi utilisable en interne (clichés instantanés)
Vous pouvez prendre des snapshots “volume” (si vous avez un disque dur pour les données et un SSD pour le système, c’est parfait). On peut le déclencher tout les X temps. Vous avez alors un historique qui coûte peu de place (copy on write).
Le 08/09/2017 à 12h42
#40
Moi je fais un snapshot VSS tous les soirs.
vshadow -p -scsf e:
Comme ça je peux revenir jusqu’à max 64 jours en arrière (nombre max de snasphots, et ça dépend de l’espace max qu’on a alloué pour les snaphots sur le disque) sur n’importe que répertoire ou n’importe quel fichier.
Et depuis W10 on y accède facilement via l’item de menu “Restaurer les versions précédentes”. Avant MS avait plus ou moins planqué le truc..
Le 08/09/2017 à 16h29
#41
Le 08/09/2017 à 17h59
#42
Je coince lors de la copie par clonage. Je vois l’intéret mais ça me fait franchement peur. Admettons que je fasse un clone B et qu’après je change le fichier A, est-ce que B qui est donc un clone partiel en souffre ? Par exemple sous Windows et Office, je fais des doubles de mes documents importants car il arrive (très rarement, mais ça choque) qu’Office demande une réparation d’un fichier alors qu’aucune erreur n’avait pourtant eu lieu… Et bien sûr, ça échoue parfois. Je n’ose pas imaginer ce que ça donnerait pour B si A est réparé de je ne sais quelle maladie imaginaire.
Après, ça a l’air pas mal pour des SSDs mais pas pour des disques traditionnels, car partitionner à l’ancienne permet (indirectement) aussi de lutter contre la fragmentation.
Le 09/09/2017 à 08h58
#43
Espérons que ce FS ne consomme pas trop de ressources. Pour la comparaison, BTRFS est hélas connu pour sa forte utilisation CPU. C’est peut être pour cela qu’on ne le trouve pas activé par défaut sur les distros grand public (ex : Ubuntu, OpenSuse), souvent installées sur des laptops. Sur des distros pro et à destination de serveurs (ex : Suse Enterprise), ça peut s’envisager plus sereinement.
Bref, APFS va t-il faire des trous dans nos batteries ou affoler nos ventilos ? " /> (à priori non, je vois mal Apple faire cette bêtise)
Le 09/09/2017 à 09h35
#44
Le 09/09/2017 à 09h37
#45
Le 09/09/2017 à 09h49
#46
Complètement d’accord, d’autant que l’on va retrouver ce FS sur des systèmes critiques.
Mais ça ne serait pas la première gaffe des ingénieurs fous d’Apple hein " />
Le 09/09/2017 à 09h56
#47
Le 09/09/2017 à 14h11
#48
Ou sinon tu utilises snapper.
Le 09/09/2017 à 14h33
#49
Je pense qu’il faut voir ça comme un lvm
Le 09/09/2017 à 14h34
#50
Le client dropbox de chaque machine interagit avec le fichier en utilisant l’abstraction fournie et n’a même pas à connaître le système de fichier en dessous.
Le 11/09/2017 à 09h19
#51
Le 11/09/2017 à 09h26
#52
Le 11/09/2017 à 10h26
#53
Le 11/09/2017 à 10h34
#54
Le 11/09/2017 à 12h27
#55
Le 11/09/2017 à 12h43
#56
Le 12/09/2017 à 08h16
#57
Le 12/09/2017 à 09h21
#58
Le 12/09/2017 à 09h33
#59
Le 12/09/2017 à 09h35
#60
Le 12/09/2017 à 10h14
#61
Le 12/09/2017 à 11h26
#62
Le 12/09/2017 à 11h30
#63
Le 12/09/2017 à 12h55
#64
Le 12/09/2017 à 14h14
#65
Le 12/09/2017 à 17h32
#66