APFS : de la défragmentation au programme d'iOS 11.4
À une époque pas si éloignée, la défragmentation était dans le vocabulaire courant des utilisateurs d’ordinateurs. Cette opération lente (si lente…) devait être effectuée régulièrement si l’on voulait conserver des performances correctes. Les informations étaient écrites sur les disques durs dans des blocs non contigus, ce qui fait que la lecture était de plus en plus lente. Pour accélérer les choses, la défragmentation consistait à organiser les blocs de manière plus logique, en les regroupant au plus près pour accélérer la lecture.
Les SSD ont contribué à rendre la défragmentation largement obsolète. Même si les blocs d’informations ne sont pas stockés les uns à côté des autres, les débits en lecture sont tels que l’impact sur les performances sont moins visibles. Et puis les contrôleurs des puces de stockage intégraient des mécanismes pour éviter les ralentissements.
C’est pourquoi la découverte de Guilherme Rambo est surprenante : en fouinant dans le code d’iOS 11.4 disponible en bêta depuis hier soir, il a déniché un nouveau processus nommé apfs_defragd. Son nom semble assez explicite, il s’agit a priori d’un outil de défragmentation pour APFS, le système de fichiers maison d’Apple qui est en place depuis un an. Apple avait prévenu l’an dernier qu’un mécanisme de défragmentation était prévu, mais uniquement pour les disques durs des Mac, pas pour les stockages flash des appareils iOS.
Alors pourquoi défragmenter iPhone et iPad ? Peut-être parce qu’Apple ne compte plus exploiter les fonctions fournies par les contrôleurs associés aux puces NAND des appareils iOS. Le constructeur pourrait au contraire tout faire du côté du logiciel, peut-être pour mieux optimiser le stockage. On ne sait pas exactement quelle est son idée, on sait en revanche que la fragmentation existe aussi pour les NAND et qu’elle peut avoir un impact sur les performances.
Est-ce qu’iOS 11.4 va améliorer les performances des appareils iOS ? Il est trop tôt pour le dire, d’autant qu’Apple utilisait jusque-là d’autres mécanismes pour éviter les baisses de performance au fil du temps. On ne sait pas non plus si macOS 10.13.4 hérite du même processus. Faute de documentation concernant la gestion de la défragmentation par APFS, les utilitaires Mac spécialisés iDefrag et iPartition ont été récemment abandonnés.
Et pour un Fusion Drive en HFS+ cela se passe comment ?
Y’a besoin de défragmenter ?
@Yoskiz
«
Et pour un Fusion Drive en HFS+ cela se passe comment ?
Y’a besoin de défragmenter ?
»
Oui, il y a toujours un bénéfice a défragmenter et l’opération est d'une complexité technique énorme ;) => backup intégral du disque, effacement du disque, restauration du disque...
A faire 1 a 2 fois par an...
La fragmentation nait du probleme de la segmentation des donnees pour tenir dans un espace disque fini.
Le principe est simple. Un disque c'est un ensemble de cases dont la taille est fixe et standard. Si un fichier est plus grand qu'une case, le gestionnaire de fichier (FS) va fragmenter le fichier en morceaux de la taille de la case et remplir autant de cases qu'il y a de morceaux de fichiers.
Ça c'est ce qui se passe lors de la première utilisation du disque, les fichiers sont alors stocké dans des cases contiguës
Lorsqu'on efface des fichiers, on libère donc des suites de cases. Et plus on a des fichiers de tailles variées, plus on a des suites de cases libre dispersées.
A ce moment l'ecriture d'un fichier va se faire en remplissant des suites de cases non contiguës... c'est ça le probleme de la fragmentation: le fichier est dispersé a plusieurs endroits sur le disque...
Et donc pour le lire en integralité, il faut aller lire a droite et a gauche: ça prend du temps, ça dégrade les performances... et ça rend la recuperation des données en cas d'accident beaucoup plus difficile.
Tous les supports fichiers sont sujets a la fragmentation. Mais il y a des systemes pour limiter cet effet negatif. On voit par exemple que les FS de Microsoft sont tres inefficaces pour limiter le fragmentation alors que HFS+ est dans les bons eleves.
Le SSD pose un problème différent, car s'il est tout autant sujet a la fragmentation sa nature est differente et les conséquences ne sont pas les mêmes.
Le fusion drive lui cumule les problèmes des 2 technologies.
Si HFS+ gere tres bien la fragmentation, APFS reste une interrogation et une inquietude.
@C1rc3@0rc
Merci c’est très intéressant ??
"Le SSD pose un problème différent, car s'il est tout autant sujet a la fragmentation sa nature est differente et les conséquences ne sont pas les mêmes."
Il le semble que de plus, en défragmentant un SSD on use prématurément les cellules qui ont une durée de vie déterminée.
Comme la défragmentation déplace les données en les écrivant ailleurs puis en les effaçant, on tape directement dans son capital vie (P/E cycles).
@EBLIS
Pas forcement.
Si Apple veut faire un defragmenteur au niveau de l'OS (je suis dubitatif, mais bon) la défragmentation pourrait s'operer en fonction du type et d'usage du fichier.
Certains fichiers sont par nature jamais modifiés, d'autres ont des cycles et des ampleurs de modifications calculables...
On pourrait imaginer que le systeme d'Apple utilise ces proprietes pour optimiser le stockage en fonction de la nature du support. Ca irait plus loin qu'un defragmenteur cela impliquerait que ce soit l'OS qui controle le SSD, ce qui voudrait aussi dire qu'Apple ne gerera plus de SSD standard...
Y'a besoin de passer au SSD. Je sais, c'est dur...
Autant sur un disque à plateaux avec une tête de lecture qui doit passer d'un secteur à l'autre pour lire ou écrire un fichier, je comprends l'intérêt d'écrire dans des secteurs contigus, mais sur des puces de mémoire flash, ça n'a aucun sens!
On peut lire n'importe quelle zone de mémoire à la même vitesse quel que soit l'emplacement physique de cette zone sur la puce, non? Il n'y a aucun élément devant se déplacer d'une zone à l'autre...
Si ce n'était pas le cas, alors le choix d'Apple de morceler le SSD des MacBookPro touchbar en plusieurs puces réparties en divers endroits de la carte mère serait un très mauvais choix !
Y'a quand mêmes 2 facteurs importants :
- les blocks SSD sont de taille nettement plus grosse que les secteurs de 512 octets (ou de 4096) des disques à plateau. Chaque écriture ramène en cache plus de données, et la contiguïté des données dans un ou plusieurs blocks peut largement améliorer l'efficacité des caches, éviter de la dégrader en particulier.
- l'usure de chaque block. Si l'on écrit plus souvent sur les mêmes blocks, la durée de vie du SSD va être finalement celle de l'usure du block le plus souvent écrit. Redistribuer les blocks de manière à distribuer l'usure sur l'ensemble des blocks du SSD permet d'éviter cela. En règle générale c'est le contrôleur qui s'occupe de ça de manière transparente, mais Apple visiblement est dans une démarche massive de remplacement des composants tiers par les leurs, soit matériel soit logiciel.
Ici la défragmentation logicielle pourrait réduire le coût du controleur pour Apple, à base d'une puce maison plus simple et en la liant au système de fichiers maison en plus (tout bonus pour Apple, qui déteste de plus en plus l'interopérabilité, la réparabilité et même la compatibilité avec des solutions tierces).
@byte_order
Merci de ces éléments qui permettent d'entrevoir l'intérêt de la chose.
Par contre, bouger les données et les repartir sur les différents blocs pour une usure uniforme de ceux-ci, c'est aussi générer des écritures supplémentaires et donc une usure prématurée...
C'est ce que je ne comprends pas, normalement le contrôleur SSD fait ça, il gère la répartition uniforme des données et repère les cellules mortes pour ne pas y écrire. Du coup quel est l'intérêt de défragmenter un SSD et réduire en même temps la durée de vie des cellules. Comment le logiciel va gérer ça sans contrôleur physique ? Comment le logiciel va-t-il marquer les cellules mortes? Si on réinstalle le système, c'est le contrôleur qui gère ce genre de chose, mais si c'est logiciel ? Est-ce qu'il y aura une puce dédiée à cette tâche ?
Apple a acheté Anobit il y a 6 ans, et Anobit faisait des contrôleurs matériels.
https://www.theguardian.com/technology/2011/dec/20/apple-buys-flash-storage
Le contrôleur SSD fait ça, mais Apple pense sans doute pouvoir faire mieux.
Sinon, intuitivement, il me semble que la pire chose pour la durée de vie d'un SSD serait d'éviter à tout prix de réécrire son contenu.
Imagine un disque SSD dont, le premier jour, tu remplis la moitié avec des films, photos, archives. Une seule écriture, zéro fragmentation. Toute ton utilisation quotidienne va se faire avec le reste du disque : les caches Internet, les trucs que tu télécharges, utilises, effaces, etc.
Au bout d'un moment, il me semble qu'il serait bon de déplacer les données que tu as installées le premier jour et qui campent dans des cellules quasi neuves, dans des cellules qui ont connu pas mal de cycles d'écriture. Donc tu déplaces les données, et au passage tu en profites pour "défragmenter", ou du moins optimiser la disposition des données pour qu'elles se chargement plus rapidement.
En résumé : si tu veux augmenter la durée des cellules, ça vaut probablement le coup de répartir l'usure même si ça coûte un cycle. Et dans le même temps tu peux améliorer les perfs.
Ça n'est qu'une théorie, je ne connais que très superficiellement le principe de fonctionnement des SSD.
C'est l'idée générale, oui, sacrifier une écriture pour mieux distribuer l'usure générale et maintenir / rebooster les performances.
@byte_order
Moi justement j'aime l'interoperabilité donc je n'achète plus Apple. Et je ne m'en porte pas plus mal.
@r e m y
Les ssd sata classique sont aussi composé de plusieurs puces
@r e m y
Je plusois
@r e m y
«le choix d'Apple de morceler le SSD des MacBookPro touchbar en plusieurs puces réparties en divers endroits de la carte mère serait un très mauvais choix !»
C'est un tres mauvais choix en effet mais la fragmentation est peu impliquée.
«On peut lire n'importe quelle zone de mémoire à la même vitesse quel que soit l'emplacement physique de cette zone sur la puce, non? Il n'y a aucun élément devant se déplacer d'une zone à l'autre...»
En effet, mais un SSD et un DD sont differents.
Il y a plusieurs elements a considerer dans le SSD:
- c'est un ordinateur a lui tout seul: il gere en interne l’organisation de l'information
- son organisation de l'information est indépendante de la structure que gere l'OS
- il repose sur le meme principe que le RAID: le maximum de performance est atteint avec les accès parallèles aux puces NAND.
- l'ecriture de donnees est asynchrone reposant sur un systeme de cache
- le SSD evite de reutiliser le plus possible une meme cellule
Element important: la vitesse du SSD a causé l'abandon de l'optimisation disque/RAM au profit de la simplification. Les I/O se sont multipliés expliquant les dégradations importantes de vitesse qu'on observe depuis quelques années sur les Mac a disque dur...
De fait la nature de la fragmentation sur SSD est logique alors que sur DD elle est physique. C'est complexe, mais si tu prends la comparaison avec le RAID tu comprends que le maximum de vitesse est atteint lorsque la donnée est repartie sur plusieurs disque et que l’accès beneficie donc du parallélisme des I/O. Le pire est une grosse donnée repartie sur une seule NAND... On rajoute a cela les mecanismes d'acces avec les tables d'index, les notions de block logiques des FS face au l'organisation cellulaire opaque du SSD,...
La question c'est que si un système de défragmentation peut être intégré dans le SSD, je vois pas comment ce serait possible au niveau de l'OS.
@C1rc3@0rc
Au niveau de l'os, c'est l'iOS :
recopie des données dans chaque applications,
pour tous les traitements successifs !
sans compter les effacements de données non réalisées correctement,
dés qu'il est question de photos par exemple même si on n'utilise pas iCloud et qu'on a bien pensé à vider le dossier des photos effacées,
dés qu'on subit un téléchargement forcé d'une mise à jour système, qu'on doit supprimer … et qui pourtant ne redonne pas tout le temps toute la mémoire,
dés qu'on utilise les bibliothèques applicatives systèmes d'iOS 11 avec des applications compatibles iOS 10 ou iOS 9 … où là, c'est à peu près n'importe quoi en gestion de mémoire, pour de simples listes !!!
Bref, peut-être un (très faible) indice de tous ces bugs qu'Apple garde sous le coude pour «forcer la main» d'un utilisateur qui, partant du même constat, arrive à déplorer une dégradation des performances qu'Apple s'impose à elle-même, à l'utilisateur du kit de développement, et à l'acheteur d'application, du fait de son inexpérience (volontaire !?!?) dans le déploiement applicatif.
Donc une dégradation par «fragmentation» au niveau système, ressemblerait plus à la transposition des données mémoires d'exécution dans les données temporaires sauvegardées sur «disque», en attendant leurs rappels pour une reprise d'exécution, à l'endroit précis de l'arrêt … comme ces LA règle sur iOS ;)
Et c'est sans compter sur le gestionnaire de dépôts sensé exister dans APFS, qui permettrait, en théorie du moins, des snapshots d'exécution, des états de sauvegarde différentielle … sans retour arrière, Apple oblige ;)
Ça serait bien que ça se fasse automatiquement pendant la nuit
tu peux les rappeler, s'ils n'ont pas jeté leur cd's, ils devraient pouvoir se refaire un peu de maille..."allo, allo, désolé, maintenant on est au board d'Apple..."
Je croyais que pour le cas des SSD il y avait la fonction TRIM qui répartissait le nombre de « secteurs » utilisés pour ne pas user prématurément les disques
Mais parler de défragmentation me laisse perplexe ?
@deltiox
La fonction TRIM est une purge effective et explicite des cellules qui ne doivent plus contenir une donnee. Ça evite le cycle lecture/effacement avant l'ecriture et ça permet de rendre les données irrécupérables par des outils dediés. Le wear levelling est lui un autre mecanisme qui evite le plus possible qu'une cellule soit réécrite.
Sur SSD la fragmentation est de nature différente et plus complexe que celle d'un disque dur et il s'agit d'une fragmentation logique.
@C1rc3@0rc
J’en étais resté là en fait
https://www.macg.co/matériel/2013/08/commande-trim-le-meilleur-ami-du-ssd-77052
Souvenirs, souvenirs ?
Je suppose que le code d’APFS est identique entre iOS et macOS. Ça pourrait donc être lié au support par APFS des disques durs et des volumes Fusion Drive sur l’imminente beta de macOS 10.13.5.
@Dwigt
Vu l'amoncellement de bugs, failles et dysfonctions majeures d'APFS dans High Sierra de toutes evidence les versions iOS et MacOS sont différentes... ce qui est logique car MacOS doit gerer un ensemble ouvert de support la ou iOS ne doit gerer que les puces NAND des iDevice.
putain ça part en live grave chez Tim couille
???
Il a raison : au lieu de travailler sur les performances du stockage, ils feraient mieux d'investir dans l'obsolescence programmée. La fameuse.