10.12 Sierra Taille du dossier "système"

alessmuse

Membre actif
9 Novembre 2009
140
4
Bonjour,

je viens de passer à Sierra, pas de gros soucis pour le moment (si ce n'est quelques applis à mettre à jour et une bibliothèque photo du second utilisateur à aller récupérer avec Time Machine... mais bon, rien de méchant, juste un peu de temps à prendre...), mais je voulais juste savoir s'il était normal que mon stockage "Système" soit de 209 Go.... (cela semble, si je ne me trompe, être la nouvelle version du dossier "autres" aux multiples sujets...).
pour info : j'ai un MacBook Pro, mi 2012 processeur 2,9 Ghz, intel core i7, 8Go ram, 750 Go stockage.

Merci! (en espérant que le sujet ne soit pas déjà traité quelque part, et que cela m'aurait échappé dans ma recherche...)
 
C'est tout simplement "autre" qui a été renommé pour moins affoler les utilisateurs. Cette catégorie est composé de tous les fichiers qui ne sont pas considéré comme images, vidéos ou documents par le système. Via le bouton "gérer..." tu pourras voir ce qui prend le plus de place et supprimer si nécessaire.
 
Oui, je suis effectivement allée dans "gérer", et j'ai fait de la place. Mais le fameux dossier "système" n'est pas accessible (gris clair)... il ne semble donc pas compressible... et la place que j'ai faite pour les autres dossiers (images, photos, documents...) n'a pas interféré sur sa taille... que je trouve assez conséquente...
 
Oui, je suis effectivement allée dans "gérer", et j'ai fait de la place. Mais le fameux dossier "système" n'est pas accessible (gris clair)... il ne semble donc pas compressible... et la place que j'ai faite pour les autres dossiers (images, photos, documents...) n'a pas interféré sur sa taille... que je trouve assez conséquente...


Bonjour,
J'ai le même problème. Comment avez-vous pu accéder au répertoire "System" pour le nettoyer ?
Merci par avance de votre réponse.
Cordialement
Bobby68
 
Salut Bobby

Ne confonds pas le terme "Système" utilisé dans le panneau Stockage et le répertoire /System de l'OS.

  • Le répertoire /System contient les composants fondamentaux du "Système" de l'OS. Il est verrouillé par le protocole de sécurité SIP dans «Sierra» contre toute modification > à cause de cette fonction essentielle. Ce n'est certainement pas ce répertoire /System (qui fait dans les 7 Go en règle générale) qui consomme exagérément d'espace dans ton volume.

  • Le terme "Système" dans le panneau Stockage est un fourre-tout emballant dans un même ensemble le contenu du répertoire /System > mais aussi tous les autres éléments de répertoires de l'OS permettant son fonctionnement (/Library > /private > /usr etc. - il y en a pas mal d'invisibles graphiquement) > et encore tout ce que le logiciel qui gère l'affichage de Stockage ne sait pas cataloguer dans des dossiers de fichiers d'un type précis (comme Vidéos ou Photos) > bref tout ce qui traîne et qui n'a pas d'identité précise.

=> je te suggère de prendre une capture de ton panneau Stockage et de l'afficher ici (tu as un bouton : Transférer un fichier en-dessous du champ de saisie d'un message dans ce fil).
 
Je vois : 28,85 Go d'espace annoncé libre sur les 498,88 du volume Macintosh HD --> il y a de quoi commencer à se préoccuper. 351,64 annoncés pour le "Système" --> autant dire que c'est du n'importe quoi (c'est impossible). "Système" ici, tu l'auras compris, qui n'est pas un dossier > mais une catégorie de regroupement de tout ce que le logiciel ne sait pas ranger ailleurs.

Je te propose de fournir des informations plus détaillées afin d'affiner le diagnostic (il est possible que tu sois victime d'un bogue notoire de «Sierra» équivalant à un sur-occupation de l'espace du volume de l'OS).

D'abord --> fais une capture du panneau Stockage sans avoir pressé le bouton "Gérer" --> de manière à ce que soit montrée la jauge horizontale colorée d'occupation du volume.

Ensuite > va à : Applications > Utilitaires > lance le «Terminal». Tu vas pouvoir passer dans sa fenêtre des commandes en mode texte retournant des informations explicites. Saisis (l'une après l'autre - en copier-coller direct chaque fois) les 2 commandes informatives :
Bloc de code:
df -H /
sudo find -x / -d 1 -regex '.*[^\.]' -exec sudo du -shx {} +
et ↩︎ (presse la touche "Entrée" du clavier après chaque commande pour l'exécuter). Après la 2è > une demande de password va s'afficher (commande sudo) --> tape ton mot-de-passe de session admin à l'aveugle - aucun caractère ne se montrant à la frappe - et ↩︎ à nouveau. La 2è commande va prendre quelque temps à opérer : patiente !

  • la 1ère affiche le tableau des espaces : total > occupé > libre du volume Macintosh HD démarré - mesures effectuées en mode "occupation des blocs"

  • la 2è retourne la liste des éléments (fichiers ou dossiers) de 1er ordre > visibles ou invisibles car leur intitulé précédé par un . > du volume Macintosh HD démarré > en affichant pour chaque item sa taille en multiple du byte - mesures effectuées en mode "taille des fichiers" différent du mode "occupation des blocs" précédent

Poste encore ces 2 tableaux ici, pas via une capture, mais en copier-coller > en procédant ainsi pour les poster proprement -->

  • avant ton coller > presse le bouton (4è avant la fin à droite) dans la barre de menus au-dessus du champ de saisie d'un message > menu  : </> Code > par ⌘V colle dans la fenêtre Code > presse le bouton Insérer (ce procédé permet un affichage fenêtré qui économise l'espace de page en respectant la mise en forme des tableaux du «Terminal» --> d'où une plus grande lisibilité)

=> en croisant ces informations --> la lumière se fera.
 
Bloc de code:
  0B    /.dbfseventsd
951M    /.DocumentRevisions-V100
12K    /.DS_Store
  0B    /.file
3,6M    /.fseventsd
256K    /.hotfiles.btree
4,0K    /.MobileBackups
4,0K    /.mtm.private.plist
  0B    /.PKInstallSandboxManager-SystemSoftware
1,0G    /.Spotlight-V100
  0B    /.Trashes
  0B    /.vol
4,0K    /10.5
9,4G    /Applications
2,5M    /bin
  0B    /cores
4,5K    /dev
4,0K    /etc
4,0K    /Guides de l’utilisateur et informations
1,0K    /home
27M    /Incompatible Software
4,0K    /installer.failurerequests
4,7G    /Library
1,0K    /net
  0B    /Network
13G    /private
1,0M    /sbin
274G    /System
4,0K    /tmp
131G    /Users
732M    /usr
4,0K    /var
4,0K    /Volumes
find: fts_read: Invalid argument
 
J'ai sorti la calculette --> la somme des tailles de fichiers dans le volume Macintosh HD est de 435 Go.

Le tableau imagé par la capture du message #6 affichait la déclaration suivante : 28,85 Go de libre sur 498,88 Go > d'où il s'ensuit que l'espace occupé était évalué à : 470 Go.

Par rapport à la taille réelle des fichiers (435 Go) --> il y a donc une sur-évalution de 63,88 Go. Une erreur quantitative notable, mais qui ne suffit à rendre compte du problème.

Car problème il y a au niveau exclusif des fichiers, dans la mesure où les dossiers de compte d'utilisateurs (Users) ne font que 131 Go --> quels fichiers peuvent donc consommer le restant d'espace amenant à 435 Go recensés, soit 304 Go ? - le répertoire des Applications (9,4 Go) > de la Bibliothèque générale (4,7 Go) > le dossier graphiquement invisible private (13 Go) > et des broutilles à droite et à gauche --> tout cela plafonne à environ 30 Go d'espace de fichiers. Quels fichiers occupent donc le restant pour atteindre 304 Go, soit 274 Go d'espace ?

La réponse est données par une anomalie absolue : le répertoire System (= la Bibliothèque du Système) est évalué à une taille de 274 Go ! - une anomalie doublement étonnante -->

  • d'abord, en raison d'un argument d'ordre empirique : l'expérience montre qu'habituellement le répertoire System fait dans les 7,5 Go --> il ne fait jamais des centaines de Go

  • ensuite, en raison d'un argument d'ordre logique : par défaut, des répertoires critiques de l'OS sont protégés contre toute modification par rapport au paradigme de l'installation par le protocole du SIP (System Integrity Protection) qui s'instaure au démarrage pour un OS comme «Sierra». Il s'ensuit logiquement que le répertoire System, qui fait partie des dossiers verrouillés par le SIP, est in-modifiable dans la nature de ses fichiers. Il doit donc avoir une taille constante et non pas variable par rapport au paradigme de l'installation de l'OS

On a donc affaire à un problème passionnant (si Bobby me passe cet intérêt « théorique ») --> non seulement il y a une erreur de sur-allocation des blocs du volume de l'ordre de 63,88 Go excédant la somme des tailles des fichiers reconnus ; mais encore il y a une aberration de "taille" dans la dimension du répertoire System (un surcroît de fichiers de l'ordre de 266,5 Go par rapport au paradigme d'environ 7,5 Go) - aberration en contradiction avec le verrouillage de ce dossier du "Système" par le SIP.

----------

Est-que tu pourrais, Bobby, apporter des compléments d'information ?

- a) d'abord poster ici une capture de la jauge d'occupation du volume du panneau Stockage.

- b) ensuite poster ici le petit tableau retourné par une commande :
Bloc de code:
df -H /

  • qui mesure l'occupation des blocs du volume.

- c) et encore poster ici le résultat de la commande (copier-coller) :
Bloc de code:
sudo find /System/Library -d 1 -regex '.*[^\.]' -exec sudo du -sh {} +

  • qui mesure en taille de fichiers les objets contenus dans la Bibliothèque du Système --> car il faut bien que les 266,5 Go de fichiers en trop soient écrits quelque part.

- d) enfin > poster le retour de la commande :
Bloc de code:
csrutil status

  • qui montrera si le protocole du SIP se trouve désactivé (ce qui expliquerait la possibilité logique de l'inflation aberrante de fichiers dans System) ; ou, s'il était activé, révèlerait un paradoxe : l'outrepassement d'une interdiction.
 
J'ai sorti la calculette --> la somme des tailles de fichiers dans le volume Macintosh HD est de 435 Go.

Le tableau imagé par la capture du message #6 affichait la déclaration suivante : 28,85 Go de libre sur 498,88 Go > d'où il s'ensuit que l'espace occupé était évalué à : 470 Go.

Le tableau du message #6 donne des tailles en Go "décimaux" alors que la commande df -H renvoie des Go "binaires".

435 Go binaires représentent 435 x 1024 x 1024 x 1024 octets soit environ 470 milliards d'octets que le Finder de MacOS dans le tableau du message #6 affichent comme 470 Go.

L'un des 2 problèmes évoqués n'est donc qu'apparent.
L'autre par contre...

(Hypothèse de ma part... un dossier /System dont l'embonpoint a été hérité d'une version de MacOS pré-SIPienne avec des sous-dossiers volumineux placés là par erreur)
 
Dernière édition:
Le tableau du message #6 donne des tailles en Go "décimaux" alors que la commande df -H renvoie des Go "binaires".

435 Go binaires représentent 435 x 1024 x 1024 x 1024 octets soit environ 470 milliards d'octets que le Finder de MacOS dans le tableau du message #6 affichent comme 470 Go.

L'un des 2 problèmes évoqués n'est donc qu'apparent.
L'autre par contre...

(Hypothèse de ma part... un dossier /System dont l'embonpoint a été hérité d'une version de MacOS pré-SIPienne avec des sous-dossiers volumineux placés là par erreur)
En fait, non : la commande
Bloc de code:
df -h
donne effectivement les données en unités binaires mais il s'agit ici de
Bloc de code:
df -H
qui donne les résultats en unités décimales standardisées (beurk!).
 
  • J’aime
Réactions: r e m y
Ah ben mince.... j'en apprends tous les jours!
Merci.
[emoji4]

Le mystère reste donc complet.
(Sauf à imaginer que df -H est buggué et renvoie en fait les mêmes résultats que df -h ou, plus simple, que ce soit la commande df -h que bobby68 ait été saisie, ignorant l'importance de la majuscule)
 
:coucou: r e m y

J'évite soigneusement de proposer l'option -h (qui retourne des Gibibytes) > mais toujours l'option -H (qui retourne des Gigabytes) - tout simplement parce que je ne sais pas compter dans le premier type d'unités.

La commande df est toujours juste et jamais prise en défaut > relativement aux blocs occupés. Sauf que... ces blocs peuvent ne pas être occupés par des fichiers recensés dans le système de fichiers > mais par des flags qui marquent des blocs comme occupés alors que les fichiers correspondants n'existent plus.

Il s'agit d'un bogue sévère de «Sierra» qui a partie liée avec la notion d'espace "occupé-purgeable". Cela revient à une erreur dans l'allocation des blocs.

Cette erreur se combine dans le cas de Bobby avec une fantastique extension du dossier System en taille de fichiers. En contradiction avec le verrouillage imposé par le SIP. Cet embompoint ne peut pas être "hérité", parce que le programme d'installation de «Sierra» (en mode mise-à-niveau) impose une quarantaine hors dossier Système à tout ce qui ne correspond pas aux normes de l'OS (par exemple --> éjection de toutes les extensions de tierce partie qui peuvent être présentes dans le sous-dossier Extensions). L'énigme d'un dossier Système de 274 Go est donc entière.

=> en résumé : ce cas est passionnant > parce qu'il combine des erreurs d'occupation de l'espace.
 
Je reste convaincu que le premier probleme constaté n'est qu'apparent et qu’il résulte d'une confusion entre Gibibytes (décimaux) et Gigabytes (binaires)

Mon calcul en divisant 3 fois les 470 Go du Finder par 1,024 pour retomber exactement sur les 453 Go du Terminal me semble suffisamment convaincant.

Au passage, pour ce qui est de la différence entre le paramètre -H et le paramètre -h, Bompi écrit plus haut exactement l'inverse:
-H retournerait les tailles en Go décimaux (Gibibytes) et -h en Go binaires (GigaBytes)

Je n'ai pas de Mac sous la main pour vérifier d'un
man df
 
Dernière édition:
Je reste convaincu que le premier probleme constaté n'est qu'apparent et qu’il résulte d'une confusion entre Gibibytes (décimaux) et Gigabytes (binaires)

Mon calcul en divisant 3 fois les 470 Go du Finder par 1,024 pour retomber exactement sur les 453 Go du Terminal me semble suffisamment convaincant.

Au passage, pour ce qui est de la différence entre le paramètre -H et le paramètre -h, Bombi écrit plus haut exactement l'inverse:
-H retournerait les tailles en Go décimaux (Gibibytes) et -h en Go binaires (GigaBytes)

Je n'ai pas de Mac sous la main pour vérifier d'un
man df
Les pages de manuel sont fort heureusement accessibles en ligne.
Pour df, c'est ici.

Et cela dit :
Bloc de code:
-H  "Human-readable" output.  Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and
    Petabyte in order to reduce the number of digits to three or less using base 10 for sizes.

-h  "Human-readable" output.  Use unit suffixes: Byte, Kilobyte, Megabyte, Gigabyte, Terabyte and
    Petabyte in order to reduce the number of digits to three or less using base 2 for sizes.

PS : accessoirement, c'est @bompi
 
Une chance... je n'ai pas écrit Bambi [emoji23]
 
J'espère que cette occupation illégale des territoires se résoudra plus vite qu'au proche orient... [emoji848]
 
<...>
Au passage, pour ce qui est de la différence entre le paramètre -H et le paramètre -h, Bompi écrit plus haut exactement l'inverse:
-H retournerait les tailles en Go décimaux (Gibibytes) et -h en Go binaires (GigaBytes)

Je n'ai pas de Mac sous la main pour vérifier d'un
man df
Note que c'est l'inverse : les Gibi, ce sont les unités "historiques", c'est-à-dire binaires (base 2).
Les Giga, ce sont les unités Shadock, c'est-à-dire les unités décimales (base 10).
Cf. Ouikipedia.
 
J'étais convaincu que c'était l'inverse...
maintenant reste à vérifier si Bobby n'aurait pas utilisé df -h plutot que le df -H demandé par Maco.