Il y a donc
845 Go (
gigabytes :
base 10) de
blocs alloués "occupés" au volume. En regard --> la
taille des fichiers contenus dans le volume est de
785 Gi (
gibibytes :
base 2) > soit
843 Go de fichiers.
On peut donc considérer > à
2 Go près > qu'il y a
congruence entre les 2 mesures > d'autant plus si l'on considère que le système de fichiers
jhfs+ fait régulièrement près de
1 Go de blocs et que cette occupation sur l'en-tête de la partition est toujours créditée du volume. Cette congruence veut dire que le
système de fichiers dans sa fonction d'
allocation des blocs (gestionnaire
bitmap) n'attribue pas plus de blocs comme "occupés" au volume qu'il ne
recense de taille de fichiers dans le même volume. Ce qui équivaut encore à dire que le système de fichiers
jhfs+ est "
cohérent" (logiquement parlant), ou encore
sans erreur interne.
----------
Cette lénifiante constatation opérée --> il est possible de concentrer l'examen uniquement sur le tableau résultant de la 2è commande > qui affiche la
distribution des fichiers dans le volume.
Je décide ici de considérer comme "
données d'utilisateur humain" --> non seulement les fichiers relevant du dossier de compte contenu dans le répertoire
/Users (=
Utilisateurs) > mais également les
logiciels contenus dans le répertoire
/Applications - parce qu'au fond aucune application de ce répertoire - quand bien même s'agit-il des applications Apple natives comme
Safari, par exemple - n'est partie prenante du Système au sens fort de l'OS. On pourrait très bien envisager un Système avec un répertoire
Applications vide. Compte tenu du fait que les applications solidaires du Système ne font pas partie des
Applications du point de vue de la localisation > mais du répertoire
/System. Par exemple, le
boot_loader :
boot.efi (programme de démarrage du Système) se trouve localisé at:
/System/Library/CoreServices -
boot.efi qu'il est possible de considérer comme l'«
application-Système » de l'
EFI (
EFI = programme de boot du Mac recelé dans une puce de la Carte-Mère).
Ces considérations épistémologiques m'amènent à évaluer en taille les "
données d'utilisateur humain" à :
359 Gi (pour le répertoire
Users) +
33 Gi (pour le répertoire
Applications) =
392 Gi soit par conversion
421 Go.
421 Go de fichier "
données d'utilisateur humain" sur
843 Go de
fichiers contenus dans le volume --> on est donc à
50% quasiment pile.
Comme ce qui ne relève pas de la catégorie "
données d'utilisateur humain" > tombe dans le catégorie "
données du Système" (et que cette division catégorielle binaire épuise le sujet, càd. le contenu du volume) --> on déduit simplement que
422 Go de fichiers correspondent aux "
données du Système".
Ce qui est choquant, intrinsèquement, parce qu'aucun Système de type
macOS n'implique une telle taille de fichiers - sauf aberration. On recheche donc une
aberration.
La somme des tailles des
répertoires du Système :
Library =
31 Go +
System =
5,8 Go +
private =
5 Go > +
usr =
0,5 Go (les répertoires d'exécutables comme
bin ou
sbin n'ayant pas de poids) donne :
42 Gi =
45 Go de
fichiers "Système".
422 Go -
42 Go =
380 Go de fichiers recensés comme relevant du Système > qui ne sont
pas contenus dans les répertoires clés du Système.
J'avise alors une anomalie absolue --> un répertoire
/cores (non nécessairemnt existant sur un mode régulier) qui fait
350 Gi =
376 Go. À
4 Go près j'ai la correspondance avec les
380 Go de fichiers en excès crédités du Système (et je ne vais pas chercher la petite bête plus finement ici).
----------
Le répertoire
/cores n'est pas créé par défaut à l'installation du Système > mais il est créé par destination s'il existe des fichiers de type "
core dumps" à archiver. Les "
core dumps" sont des "
déchets de poubelle du fonctionnement foncier" : des archives de plantage logiciel du Système. Ces "archives de plantage" n'ayant qu'un intérêt "entomologique" (pour scrutateurs de petites bêtes) --> il est donc possible a priori de les supprimer sans aucun inconvénient.
Tu peux passer la commande :
Bloc de code:
sudo launchctl limit core
- qui s'enquiert des limites fixées à la génération de "core dumps"
Le retour par défaut est :
- qui signifie qu'en matière de "core dumps" --> le kernel a pour règle de créer 0 "core dumps" > mais qu'il n'y a par contre aucune limite en taille a priori pour les "core dumps" susceptible d'être générés par des processus "extra_kernel" s'il le décident.
Tu n'as qu'à poster le retour de la commande chez toi > qui est possiblement le même.
On en tire alors l'interprétation qu'un ou plusieurs processus
extra_kernel (postérieurs au chargement par le
kernel du
Système_BSD à proprement parler) > donc processus dépendant de
launchd (le serveur de l'OS dont relèvent tous les processus
extra_kernel) --> ont connu des plantages sévères les amenant à générer des "
core dumps" en quantité massive.
Je ne peux pas dire de quoi il s'agit > ni s'il s'est agi d'incidents pontuels > ou s'il y a quelque part une réitération de plantage qui alimenterait indéfiniment le dossier
/cores en "
cores dumps".
Quoi qu'il en soit --> tente la commande :
- qui supprime tous les "core dumps" contenus dans le dossier /cores.
Si tu obtiens en retour (malgré une authentification par ton mot-de-passe admin pour passer en droits
root) --> un :
- on saura que le SIP (System Integrity Protection) verrouille aussi le répertoire /cores (ce qui m'étonnerait un peu, quand même, car ce répertoire n'existe pas par défaut dans la distribution régulière des dossiers du Système > et ne fait donc pas partie du "logiquement prévisible" par défaut pour le SIP).
Si tu n'as pas obtenu de
- alors repasse une commande :
- et poste le tableau de l'allocation des blocs.
