Salut
David
Toi au moins tu apportes les informations sur un plat
.
Tu as donc
244 Go d'espace-blocs occupés par le volume
Macintosh HD alors qu'il n'y a - j'ai sorti la calculette - que
87,5 Gi (
Gibibytes =
base 2) =
94 Go (
Gigabytes =
base 10) de fichiers recensés (visibles ou cachés).
Ce qui fait donc un excédent de
150 Go. Les
3,2 Go de fichiers du volume
disk1s4 VM (
Virtual Memory) sont à ajouter à la taille des fichiers dans le volume
Macintosh HD > car le volume
VM est
monté dans Macintosh HD démarré at:
/private/var/vm et l'option
-x (
exclude) dans la commande
find a fait échapper la traversée de ce point de montage. Donc
94 Go de fichiers +
3,2 Go =
97,2 Go. L'excédent d'occupation d'espace-disque tombe alors à
146,8 Go.
Le fait de supprimer une image-disque (ou un gros fichier) bidon était un procédé permettant d'effacer l'effet d'un bogue de l'OS «
Sierra» (exclusivement) : des
flags (marqueurs) "occupés" affectés à des blocs libérés de leurs fichiers.
Tu es en train de te demander alors comment un ensemble (le volume) qui ne contient que
97,2 Go d'éléments peut malgré tout occuper
146,8 Go d'espace-blocs sur le disque ?
Voici la conjecture que je te soumets : une structure logique inscrite sur l'en-tête de la partition et appelée
système de fichiers est la
génératrice du volume = répertoire montrant des fichiers. Le paradoxe logique courant est que : bien que cette structure du système de fichiers soit
extérieure (en tant que génératrice) au volume qu'elle produit > la taille des fichiers du
système de fichiers est toujours
annexée à la taille du volume.
Pour un système de fichiers classique (
jhfs+) --> on dira que la taille de ses fichiers est d'environ
300 Mo de blocs. Taille minime et donc négligeable. Pour ce qui est des fichiers générateurs d'un système de stockage comme le
CoreStorage > la taille peut aller (disons) jusqu'à
1 Go. Je n'ai pas trop d'idée de la taille standard des fichiers du système de fichiers
apfs sur une partition.
Quoi qu'il en soit > si tu supposes cette conjecture --> il conviendrait de conclure ce qui suit : l'excédent de
146,8 Go d'espace-blocs occupé par rapport à la taille des fichiers contenus dans le volume
Macintosh HD > doit nécessairement correspondre à la
taille actuelle des fichiers du
système de fichiers apfs. Ce qui est une monstrueuse anomalie --> le
système de fichiers apfs ferait actuellement chez toi
146,8 Go > et cet espace-blocs occupé serait donc
crédité en surcroît de taille au volume monté
Macintosh HD.
Voici dans la rapport de la vérification de l'
apfs > ce qui me paraît confirmer ma conjecture :
Bloc de code:
Checking the snapshot metadata tree
error: btn:1: invalid key order (2) oid 659330 / oxid 47651
Snapshot metadata tree is invalid
L'
arbre des métadonnées de snapshots est
invalide. Cet embranchement de l'arbre global du
système de fichiers apfs sert de magasin de stockage aux instantanés locaux du volume
Macintosh HD. Je veux imaginer ici que ce stockage fait actuellement
146,8 Go.
Je te propose dans un premier temps de passer la commande informative :
Bloc de code:
tmutil listlocalsnapshots /
- cette commande appelle l'utilitaire tmutil (time_machine_utility) > avec le verbe listlocalsnapshots (lister les instantanés locaux) > et le domaine / (le point de montage du volume Macintosh HD démarré)
=> tu qu'à poster ce qui est retourné. S'il y a une kyrielle de
snapshots > tu devrais avoir une liste. Mais j'y crois moyennement : s'il y a une erreur dans l'
arbre de métadonnées de snapshots > je doute qu'on obtienne une liste bien sage d'instantanés.
