M
Membre supprimé 1060554
Invité
Je profite de l'accalmie des opérations dans ce fil pour revenir sur le sens des mesures :
De cette courte herméneutique > on conclut que les 683 G retournés par du -h pour le volume entier = 683 Gi (Gibibytes) qui se convertissent en 733 GB (Gigabytes). Tandis que les 736 G retournés par df -H pour le volume entier = 736 GB (Gigabytes).
La différence entre les 2 utilitaires, indépendamment du type de mesure utilisée, est que df mesure l'occupation des blocs logiques de la partition > tandis que du mesure la taille des fichiers présentés dans le volume monté.
On considérera qu'il y a corroboration ici > pour estimer aux alentours de 735 Go (Gigabytes - base 10) aussi bien la taille de l'occupation des blocs de la partition que la taille des fichiers présentés dans le volume monté.
Cette absence de décalage semble alors confirmer que le volume est sur-rempli et l'espace libre faible. Il n'y a donc pas d'erreur de flags "purgeables" indûment fixés sur les blocs comme je me l'étais figuré a priori en hypothèse de travail.
Comme se fait-il alors que l'onglet Stockage retourne pour le Système une taille équivalant à la moitié de l'occupation, soit environ 375 Go > alors que le décompte des dossiers recelés dans le dossier /System par du --> n'avère que quelques maigres Go (pas de dossiers Caches hypertrophié en particulier) ?
À ce stade du raisonnement --> j'entrevois 2 hypothèses de travail :
=> lorsque yahel (qui n'est pas encore retourné nous narrer les résultats de l'opération : "image-disque bidon") reviendra dans ce fil --> je suis prêt à explorer avec lui ces 2 hypothèses de travail si rien n'est changé concernant l'occupation du volume. À mon avis > une seule commande du Terminal devrait vite régler la question de la localisation de la masse des Go de fichiers dans le volume (1ère hypothèse). Mais j'avoue qu'une erreur de sur-allocation du gestionnaire bitmap me plaît bien --> auquel cas il faudrait voir à réparer le système de fichiers.
- l'utilitaire df dispose de 2 sortes de mesures : avec l'option -H (Human_readable en majuscule) il utilise une base 10 et donc retourne des Gigabytes (Go) ; avec l'option -h (human_readable en minuscule) il utilise une base 2 et retourne des Gibibytes (Gi)
- l'utilitaire du pour sa part ne dispose que d'une seule option : -h (human_readable) > qui utilise une base 2 et retourne des Gibibytes (Gi). L'option -H vaut pour Hard_link en ce qui concerne cet utilitaire et n'a rien à voir avec une mesure en base 10 (GB)
De cette courte herméneutique > on conclut que les 683 G retournés par du -h pour le volume entier = 683 Gi (Gibibytes) qui se convertissent en 733 GB (Gigabytes). Tandis que les 736 G retournés par df -H pour le volume entier = 736 GB (Gigabytes).
La différence entre les 2 utilitaires, indépendamment du type de mesure utilisée, est que df mesure l'occupation des blocs logiques de la partition > tandis que du mesure la taille des fichiers présentés dans le volume monté.
On considérera qu'il y a corroboration ici > pour estimer aux alentours de 735 Go (Gigabytes - base 10) aussi bien la taille de l'occupation des blocs de la partition que la taille des fichiers présentés dans le volume monté.
Cette absence de décalage semble alors confirmer que le volume est sur-rempli et l'espace libre faible. Il n'y a donc pas d'erreur de flags "purgeables" indûment fixés sur les blocs comme je me l'étais figuré a priori en hypothèse de travail.
Comme se fait-il alors que l'onglet Stockage retourne pour le Système une taille équivalant à la moitié de l'occupation, soit environ 375 Go > alors que le décompte des dossiers recelés dans le dossier /System par du --> n'avère que quelques maigres Go (pas de dossiers Caches hypertrophié en particulier) ?
À ce stade du raisonnement --> j'entrevois 2 hypothèses de travail :
- soit il y a bien réellement 735 Go de fichiers dans le volume > mais le logiciel Stockage se référant à des bases de données de Spotlight désuètes retourne une distribution fantaisiste --> il faut donc chercher ailleurs que dans le dossier Système où réside le gros des Go en ce qui concerne les fichiers
- soit il n'y a pas réellement 735 Go de fichiers dans le volume non plus que 735 Go de blocs réellement occupés > et c'est alors une erreur interne au système de fichiers jhfs+ qu'il faut incriminer : le gestionnaire bitmap serait responsable d'une surallocation de blocs ne correspondant pas à des écritures de fichiers recensés dans le catalogue B-tree. Ce qu'on appelle un conflit interne au système de fichiers gestionnaire de la partition
=> lorsque yahel (qui n'est pas encore retourné nous narrer les résultats de l'opération : "image-disque bidon") reviendra dans ce fil --> je suis prêt à explorer avec lui ces 2 hypothèses de travail si rien n'est changé concernant l'occupation du volume. À mon avis > une seule commande du Terminal devrait vite régler la question de la localisation de la masse des Go de fichiers dans le volume (1ère hypothèse). Mais j'avoue qu'une erreur de sur-allocation du gestionnaire bitmap me plaît bien --> auquel cas il faudrait voir à réparer le système de fichiers.