Bonjour,
Il n'y a
pas de problème actuel de partitionnement -->
- car la partition apfs primaire a une extension de 250,7 Go. En l'additionnant à l'extension de la partition EFI de 0,314 Go => on obtient bien sans perte les 251 Go de capacité du SSD. De plus > le Conteneur exporté depuis la partition apfs primaire de 250,7 Go --> a la même exacte capacité de 250,7 Go.
- les volumes apfs du Conteneur n'ont chacun que la taille actuelle de ses données. Les 149,8 Go du volume Macintosh HD - Données --> signifient que ce volume dédié à l'utilisateur a une occupation de blocs actuelle de 149,8 Go. De même pour les 4 autres volumes : occupation de 11 Go pour le volume-Système Macintosh HD > et environ 6 Go pour les 3 volumes auxiliaires. En additionnant ces occupations > on sait que les volumes occupent 166,8 Go de blocs d'un Conteneur de 250,7 Go de capacité. Il y a donc actuellement 250,7 Go - 166,8 Go = 83,9 Go d'espace disponible dans le Conteneur pour une extension éventuelle des volumes (surtout du volume-Données).
Ce point éclairci (
aucun espace perdu hors de la partition apfs) > il y a un autre point beaucoup plus délicat à considérer : c'est celui de l'
occupation d'un volume (comme le volume-Données :
Macintosh HD - Données - le seul vraiment susceptible de
variations de cette occupation - celle du volume-Système étant une
constante et celle des volumes auxiliaires guère susceptible de variations notables).
- car l'occupation d'un volume est une valeur équivoque (conceptuellement) --> étant donné que se superposent 2 occupations : l'occupation des blocs et l'occupation des fichiers. Le bloc est la plus petite unité logique signifiante du point de vue de l'écriture de fichiers : il a une taille de 512 octets en tant que défaut > mais souvent une taille octuple de 4096 octets en cas d'installation en format apfs. Un bloc est considéré comme occupé > dès lors que des écritures s'y trouvent inscrites. Or comme les écritures sont des écritures de fichiers --> le logicien va tout de suite conclure qu'il y a donc égalité entre la taille des blocs occupés (par des écritures de fichiers) et la taille des fichiers (forcément inscrits sur les mêmes blocs).
- cette égalité logique (occupation des blocs = taille des fichiers) --> constitue la règle (au sens de ce qui doit normalement exister). Mais elle est susceptible d'infractions > au sens où intervient une inégalité entre l'occupation des blocs et la taille des fichiers --> et c'est bien ce qui trouble l'évidence : un état de fait inégalitaire non-conforme à la règle d'égalité.
- il arrive en effet couramment que l'occupation des blocs soit supérieure à la taille des fichiers. Chacune de ces 2 grandeurs se trouvant gérée par un composant distinct du système de fichiers formateur du volume (ici apfs). L'occupation des blocs est gérée par le spaceman (le space_manager : le gestionnaire de l'allocation des blocs) en charge de la carte bitmap. La taille des fichiers est gérée par le catalogue > en charge des fichiers existant comme objets ouvrables par des applications (en lecture par exemple). La commande diskutil ou la commande df (display_free_space) => retournent toujours exclusivement la grandeur (en Go = gigabytes : base 10) de l'occupation des blocs. On peut estimer que ces commandes adressent la carte bitmap du spaceman pour obenir leur mesure. La commande du (disk_usage) => retourne toujours exclusivement la grandeur (en Gi = gibibytes : base 2) de la taille des fichiers. On peut estimer que cette commande adresse le catalogue pour obtenir sa mesure.
- la question devient : d'où vient une occupation des blocs supérieure à la taille des fichiers ? - cela peut provenir (en format apfs) du fait que des snapshots (instantanés) archivant des états passés du volume --> verrouillent comme occupés les blocs porteurs des écritures des anciens fichiers --> alors même que des masses de ces fichiers ont été ensuite supprimés du catalogue par l'action de l'utilisateur. Il y a donc ici une occupation de blocs "fantôme". Il peut se trouver aussi que le spaceman déraille dans la gestion de la carte bitmap > en ne la mettant pas à jour de la taille (toujours évolutive) des fichiers. Il y a donc alors une "sur-occupation de blocs" qui équivaut à une erreur d'un composant de l'apfs.
- un espace occupé désigné comme "Autre" (dans l'apfs) --> peut alors cibler une occupation de blocs sans correspondance à des fichiers recensés dans le catalogue = occupation "fantôme" due à des snapshots ou encore une sur-occupation due à une erreur du spaceman. Cette désignation de "Autre" n'épuisant pas le sujet --> puisqu'elle peut encore inclure un ensemble de fichiers dûment recensés dans le catalogue => mais qui n'entrent pas dans les catégories classificatrices définies (comme Documents etc.). Il s'agit alors d'un sous-ensemble de "Autre" correspondant à des fichiers d'un type "indéfini". En résumé : Autre englobe de l'espace de blocs fantôme ou sur-occupé (sans correspondance à des fichiers actuellement catalogués) + de l'espace de fichiers catalogués mais identifiés par Stockage comme d'un type indéfini.
