• Bonjour Visiteur. Bienvenue sur les nouveaux forums de MacGeneration. La peinture est encore fraiche, quelques boulons doivent être resserrés, plus d’informations demain !

10.13 High Sierra Fichiers Système à 400GO stockage

Math1306

Nouveau membre
1 Mars 2018
7
0
33
Bonsoir à tous, je me tourne vers vous ce soir car ça fait maintenant depuis 2 jours que je cherche pour quoi mais il semble que les fichiers systèmes de mon Imac 27" (fin 2013) prennent presque la moitié de mon Disque dur : 414Go sur 1To.

J'avoue là je ne comprends pas bien. J'espère que l'un/une d'entre vous pourra m'éclairer.
Voilà ce que je vois:

Capture d’écran 2018-03-01 à 19.37.53.png Capture d’écran 2018-03-01 à 19.49.29.png

Merci pour votre aide.
 
Dernière édition par un modérateur:

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Salut Math

Va à : Applications > Utilitaires > lance le Terminal. Dans la fenêtre ouverte > saisis la commande informative :
Bloc de code:
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour exécuter la commande)

  • tu vas voir s'afficher le tableau des disques attachés au Mac (en interne / externe) > avec leurs paramètres de tables de partition > partitions > Conteneur CoreStorage si présent > Conteneur apfs si présent

Poste ce tableau ici en copier-coller (pas de capture) > mais attention ! > avant de faire ton coller -->

  • dans la page de ce fil de MacGé > presse le bouton (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) 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é)

=> ces informations donneront une idée de la configuration du disque. Je pourrai enchaîner en te passant des commandes destinées à mesurer l'espace occupé du volume.
 

Math1306

Nouveau membre
1 Mars 2018
7
0
33
Bonsoir,

Voilà ce que j'ai:

Bloc de code:
Last login: Thu Mar  1 16:53:19 on ttys000
iMac-de-Mathieu:~ mathieuzerah$
iMac-de-Mathieu:~ mathieuzerah$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            999.3 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS MACOS                   900.2 GB   disk1s2
   3:       Microsoft Basic Data FAT                     99.7 GB    disk1s3

/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.5 TB     disk2
   1:                  Apple_HFS Matou                   1.5 TB     disk2s1

/dev/disk3 (disk image):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     Apple_partition_scheme                        +172.7 MB   disk3
   1:        Apple_partition_map                         30.7 KB    disk3s1
   2:         Apple_Driver_ATAPI                         2.0 KB     disk3s2
   3:                  Apple_HFS Java for macOS 2017-001 172.7 MB   disk3s3

iMac-de-Mathieu:~ mathieuzerah$
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Je vois que ton volume est en format jhfs+ > car le disque est un HDD.

Alors voici des commandes (à passer l'une après l'autre ; en copier-coller) pour affiner l'analyse -->
Bloc de code:
df -H /
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
  • à validation de la 2è --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et valide de nouveau
  • la 1ère commande affiche (en Go) l'allocation des blocs au volume (total > occupé > libre)
  • la 2è commande liste et mesure (en Gi) les éléments de 1er ordre (fichiers ou dossiers ; visibles ou cachés) du volume. Elle est particulièrement lente d'exécution --> attends le temps qu'll faut le réaffichage de l'invite de commande iMac-de-Mathieu:~ mathieuzerah$ en signal de complétion.

=> poste ces 2 tableaux ici.
 

Math1306

Nouveau membre
1 Mars 2018
7
0
33
J'espère que je me suis pas tromper.
Bloc de code:
iMac-de-Mathieu:~ mathieuzerah$ sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
Password:
find: /private/var/db/ConfigurationProfiles/Store: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.LaunchServices.dv: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.nsurlsessiond: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.routined: Operation not permitted
find: /private/var/folders/jl/xcr283m51sdccytgdj_565lw0000gp/0/com.apple.LaunchServices.dv: Operation not permitted
find: /private/var/folders/zz/zyxvpxvq6csfxvn_n00000y800007k/0/com.apple.nsurlsessiond: Operation not permitted
4,0K    /.com.sony.contentbrowser.advancedpack.plist
4,0K    /.com.sony.contentbrowser.nxcampack.plist
  0B    /.dbfseventsd
65M    /.DocumentRevisions-V100
8,0K    /.DS_Store
  0B    /.file
8,3M    /.fseventsd
896K    /.hotfiles.btree
  0B    /.PKInstallSandboxManager
  0B    /.PKInstallSandboxManager-SystemSoftware
614M    /.Spotlight-V100
  0B    /.Trashes
  0B    /.vol
33G    /Applications
2,5M    /bin
350G    /cores
4,5K    /dev
4,0K    /etc
142M    /Firefox.app
1,0K    /home
18M    /Incompatible Software
4,0K    /Informations sur l’utilisateur
4,0K    /installer.failurerequests
31G    /Library
1,0K    /net
  0B    /Network
du: /private/var/db/ConfigurationProfiles/Store: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.LaunchServices.dv: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.nsurlsessiond: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.routined: Operation not permitted
du: /private/var/folders/jl/xcr283m51sdccytgdj_565lw0000gp/0/com.apple.LaunchServices.dv: Operation not permitted
du: /private/var/folders/zz/zyxvpxvq6csfxvn_n00000y800007k/0/com.apple.nsurlsessiond: Operation not permitted
5,0G    /private
1,1M    /sbin
5,8G    /System
4,0K    /tmp
359G    /Users
508M    /usr
4,0K    /var
36K    /Volumes
iMac-de-Mathieu:~ mathieuzerah$
Voilà ce que j'obtiens:

Bloc de code:
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s2   999G   845G   154G    85% 1138862 4293828417    0%   /
iMac-de-Mathieu:~ mathieuzerah$
 

Math1306

Nouveau membre
1 Mars 2018
7
0
33
Je vois que ton volume est en format jhfs+ > car le disque est un HDD.

Alors voici des commandes (à passer l'une après l'autre ; en copier-coller) pour affiner l'analyse -->
Bloc de code:
df -H /
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
  • à validation de la 2è --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et valide de nouveau
  • la 1ère commande affiche (en Go) l'allocation des blocs au volume (total > occupé > libre)
  • la 2è commande liste et mesure (en Gi) les éléments de 1er ordre (fichiers ou dossiers ; visibles ou cachés) du volume. Elle est particulièrement lente d'exécution --> attends le temps qu'll faut le réaffichage de l'invite de commande iMac-de-Mathieu:~ mathieuzerah$ en signal de complétion.
=> poste ces 2 tableaux ici.
Bloc de code:
iMac-de-Mathieu:~ mathieuzerah$ df -H /
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s2   999G   845G   154G    85% 1138862 4293828417    0%   /
iMac-de-Mathieu:~ mathieuzerah$ sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
Password:
find: /private/var/db/ConfigurationProfiles/Store: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.LaunchServices.dv: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.nsurlsessiond: Operation not permitted
find: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.routined: Operation not permitted
find: /private/var/folders/jl/xcr283m51sdccytgdj_565lw0000gp/0/com.apple.LaunchServices.dv: Operation not permitted
find: /private/var/folders/zz/zyxvpxvq6csfxvn_n00000y800007k/0/com.apple.nsurlsessiond: Operation not permitted
4,0K    /.com.sony.contentbrowser.advancedpack.plist
4,0K    /.com.sony.contentbrowser.nxcampack.plist
  0B    /.dbfseventsd
65M    /.DocumentRevisions-V100
8,0K    /.DS_Store
  0B    /.file
8,3M    /.fseventsd
896K    /.hotfiles.btree
  0B    /.PKInstallSandboxManager
  0B    /.PKInstallSandboxManager-SystemSoftware
614M    /.Spotlight-V100
  0B    /.Trashes
  0B    /.vol
33G    /Applications
2,5M    /bin
350G    /cores
4,5K    /dev
4,0K    /etc
142M    /Firefox.app
1,0K    /home
18M    /Incompatible Software
4,0K    /Informations sur l’utilisateur
4,0K    /installer.failurerequests
31G    /Library
1,0K    /net
  0B    /Network
du: /private/var/db/ConfigurationProfiles/Store: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.LaunchServices.dv: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.nsurlsessiond: Operation not permitted
du: /private/var/folders/d2/k7kpbs751yn4zpcqk324dvy00000gn/0/com.apple.routined: Operation not permitted
du: /private/var/folders/jl/xcr283m51sdccytgdj_565lw0000gp/0/com.apple.LaunchServices.dv: Operation not permitted
du: /private/var/folders/zz/zyxvpxvq6csfxvn_n00000y800007k/0/com.apple.nsurlsessiond: Operation not permitted
5,0G    /private
1,1M    /sbin
5,8G    /System
4,0K    /tmp
359G    /Users
508M    /usr
4,0K    /var
36K    /Volumes
iMac-de-Mathieu:~ mathieuzerah$
 

Math1306

Nouveau membre
1 Mars 2018
7
0
33
Salut Math

Va à : Applications > Utilitaires > lance le Terminal. Dans la fenêtre ouverte > saisis la commande informative :
Bloc de code:
diskutil list
et ↩︎ (presse la touche "Entrée" du clavier pour exécuter la commande)

  • tu vas voir s'afficher le tableau des disques attachés au Mac (en interne / externe) > avec leurs paramètres de tables de partition > partitions > Conteneur CoreStorage si présent > Conteneur apfs si présent

Poste ce tableau ici en copier-coller (pas de capture) > mais attention ! > avant de faire ton coller -->

  • dans la page de ce fil de MacGé > presse le bouton (carré avec un + inscrit - juste au milieu de la largeur de la fenêtre totale) 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é)

=> ces informations donneront une idée de la configuration du disque. Je pourrai enchaîner en te passant des commandes destinées à mesurer l'espace occupé du volume.
j'essaye de te poster le tableau mais mon message est en attente de modération.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
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 :
Bloc de code:
    core        0              unlimited
  • 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 :
Bloc de code:
sudo rm -rf /cores/*
  • 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 :
Bloc de code:
permission denied
  • 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
Bloc de code:
permission denied
  • alors repasse une commande :
Bloc de code:
df -H /
  • et poste le tableau de l'allocation des blocs.
 
Dernière édition:

Math1306

Nouveau membre
1 Mars 2018
7
0
33
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 :
Bloc de code:
    core        0              unlimited
  • 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 :
Bloc de code:
sudo rm -rf /cores/*
  • 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 :
Bloc de code:
permission denied
  • 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
Bloc de code:
permission denied
  • alors repasse une commande :
Bloc de code:
df -H /
  • et poste le tableau de l'allocation des blocs.
Incroyable!! Après le passage de la commande, je retombe à 38Gb de fichiers Systèmes:
Bloc de code:
iMac-de-Mathieu:~ mathieuzerah$ df -H /
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk0s2   999G   470G   529G    48% 1138254 4293829025    0%   /
iMac-de-Mathieu:~ mathieuzerah$
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Disons que ton problème est actuellement résolu.

Il te suffira simplement de surveiller du coin de l'œil la taille des fichiers-Système dans le panneau Stockage > ou même de repasser la commande :
Bloc de code:
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
  • et de vérifier si le dossier cores s'est regonflé ou pas du tout.

S'il reste vide --> alors aucun processus ne plante de manière récurrente en produisant des "core dumps".
 

Math1306

Nouveau membre
1 Mars 2018
7
0
33
Disons que ton problème est actuellement résolu.

Il te suffira simplement de surveiller du coin de l'œil la taille des fichiers-Système dans le panneau Stockage > ou même de repasser la commande :
Bloc de code:
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
  • et de vérifier si le dossier cores s'est regonflé ou pas du tout.

S'il reste vide --> alors aucun processus ne plante de manière récurrente en produisant des "core dumps".
Je garderais effectivement un œil attentif à ça. Merci beaucoup pour ton aide précieuse. Je n'y serais jamais arrivé seul.
 

Sash18

Nouveau membre
2 Octobre 2018
9
0
23
Bonjour Macromaniac !
Je m'adresse à toi vu que tu as l'air d'avoir bien géré la situation pour Math1306 :)
J'ai également le même soucis, un fichier Système qui occupe plus d'1/3 de mon disque dur … J'ai donc suivi les mêmes commandes dans le terminal pour pouvoir t'envoyer ce que j'obtenais avant de supprimer quoi que ce soit.

- Tableau des disques attachés au Mac :
Bloc de code:
Last login: Tue Oct  2 14:45:44 on ttys000
sashas-mbp:~ sashacollome$ diskutil list
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *121.3 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:          Apple_CoreStorage Macintosh HD            120.5 GB   disk0s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk0s3

/dev/disk1 (internal, virtual):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:                  Apple_HFS Macintosh HD           +120.1 GB   disk1
                                 Logical Volume on disk0s2
                                 8C474181-8CF3-46A1-A83E-205EF1C80F1C
                                 Unlocked Encrypted
- Allocation des blocs :
Bloc de code:
sashas-mbp:~ sashacollome$ df -H /
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1   120G   110G    10G    92% 1188394 4293778885    0%   /
- Éléments du 1er ordre :
Bloc de code:
sashas-mbp:~ sashacollome$ sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
Password:
82M    /.DocumentRevisions-V100
12K    /.DS_Store
  0B    /.file
7,8M    /.fseventsd
4,0K    /.MobileBackups
  0B    /.PKInstallSandboxManager-SystemSoftware
617M    /.Spotlight-V100
  0B    /.Trashes
  0B    /.vol
17G    /Applications
2,5M    /bin
  0B    /cores
4,5K    /dev
28K    /Developer
4,0K    /etc
1,0K    /home
4,0K    /installer.failurerequests
8,9G    /Library
1,0K    /net
  0B    /Network
4,2G    /private
1,0M    /sbin
5,8G    /System
4,0K    /tmp
57G    /Users
2,0G    /usr
4,0K    /var
4,0K    /Volumes
Voilà tous les résultats que j'obtiens. Est-ce que tu as une idée du problème ? J'ai vu que, contrairement à Math1306, le fichier /cores est vide …
Je te remercie beaucoup par avance ! :)
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Il y a 110 Go de blocs alloués "occupés" au volume Macintosh HD d'une capacité de 120 Go. Ce qui laisse 10 Go d'espace disponible.

En regard --> il y a 95,6 Gi = 102,6 Go de fichiers catalogués. Ce qui fait une sur-allocation de blocs occupés de 7,4 Go : blocs occupés sans fichiers répertoriés sur ces blocs -->

  • ton OS est-il High Sierra ?
----------

Les fichiers "orientés utilisateur" sont : Users 57 Gi + Applications 17 Gi => 74 Gi = 79,5 Go. Ce qui laisse 102,6 Go de fichiers totaux - 79,5 Go = 23,1 Go de "fichiers-Système" --> ce qui est une valeur tout a fait normale sans aucune hypertrophie -->

  • le panneau Stockage raconte n'importe quoi comme à son habitude.
 

Sash18

Nouveau membre
2 Octobre 2018
9
0
23
Il y a 110 Go de blocs alloués "occupés" au volume Macintosh HD d'une capacité de 120 Go. Ce qui laisse 10 Go d'espace disponible.

En regard --> il y a 95,6 Gi = 102,6 Go de fichiers catalogués. Ce qui fait une sur-allocation de blocs occupés de 7,4 Go : blocs occupés sans fichiers répertoriés sur ces blocs -->

  • ton OS est-il High Sierra ?
----------

Les fichiers "orientés utilisateur" sont : Users 57 Gi + Applications 17 Gi => 74 Gi = 79,5 Go. Ce qui laisse 102,6 Go de fichiers totaux - 79,5 Go = 23,1 Go de "fichiers-Système" --> ce qui est une valeur tout a fait normale sans aucune hypertrophie -->

  • le panneau Stockage raconte n'importe quoi comme à son habitude.
- ton OS est-il High Sierra ?
Non je suis sous Sierra (version 10.12.6)

- le panneau Stockage raconte n'importe quoi comme à son habitude.
23.1 Go de fichiers Système c'est déjà plus cohérent en effet. Comment faire en sorte que le panneau Stockage soit correct ? Car actuellement c'est plus du double et 25 Go d'espace libéré me ferait du bien sur un DD de 120 Go …
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Pour remettre à jour le panneau Stockage --> il faut réindexer les bases de données de Spotlight qui lui servent de rélérentiel. Ce sera la commande :
Bloc de code:
sudo mdutil -E /
  • qui efface ces bases de données --> ce qui induit une reprise directe de la réindexation. Ça prend un moment. Lance le Moniteur d'activité (même sous-dossier des Utilitaires que le Terminal) > et regarde à l'onglet Processeur la lettre m : tous les agents de la réindexation ont un intitulé commençant par md (metadata) : mds etc. Tant que tu vois un % positif associé > attends. Quand tout est retombé à zéro > redémarre une fois et teste le panneau Stockage.

Je te conseille d'effectuer cette opération après celle que je te décris à présent.

----------

Utilisant l'OS Sierra > tu es victime de son bogue d'espace occupé fantôme > qui est spécifique > et qui requiert un procédé spécifique pour sa purge.

Il s'agit de créer une image-disque bidon d'une taille égale à l'espace disponible (10 Go ici) chez toi > moins disons 5 Go de marge pour ne pas saturer le volume. Cette image-disque bidon est créée dans les Téléchargements de ton dossier de comtpe.

Passe la commande :
Bloc de code:
hdiutil create -size 5g ~/Downloads/IMG.dmg
  • la commande crée une image-disque IMG.dmg dans les Téléchargements. Attends que l'image ait pris toute sa taille (réaffichage de l'invite de commande du Terminal)
  • cela fait > tu peux aller à  : Menu  > À propos de ce Mac > Stockage > presse le bouton Gérer > bouton : Réduire l'encombrement (en bas) > Passer en revue les fichiers > Téléchargements => en survolant au pointeur la ligne où tu vois affichée l'image-disque IMG.dmg > un bouton s'affiche qui permet de supprimer l'élément > presse-le et valide dans le panneau démasqué en pressant le bouton Supprimer.

=> cela fait > re-démarre ton Mac une fois > ta session ré-ouverte > passe la commande :
Bloc de code:
df -H /
  • et poste le tableau de l'occupation du volume de démarrage.
----------

Je te conseille de commencer par l'image-disque > et en second la réindexation de Spotlight.
 

Sash18

Nouveau membre
2 Octobre 2018
9
0
23
- Tableau d'occupation du volume de démarrage :
Bloc de code:
sashas-mbp:~ sashacollome$ df -H /
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1   120G   108G    11G    91% 1192777 4293774502    0%   /
Je suis en train de réindexer les BDD de Spotlight actuellement
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
59 274
19 683
Forêt de Fontainebleau
Tu as gagné 1 Go d'espace disponible.

Quand Spotlight sera réindexé > après redémarrage > poste ici une capture de la jauge colorée de distribution de l'espace par le panneau Stockage.
 

Sash18

Nouveau membre
2 Octobre 2018
9
0
23
Tu as gagné 1 Go d'espace disponible.

Quand Spotlight sera réindexé > après redémarrage > poste ici une capture de la jauge colorée de distribution de l'espace par le panneau Stockage.
Certains "mdworker" sur le moniteur d'activité restent à 0% et d'autres varient : ils augmentent à 3-4% puis repassent à 0%. Je dois attendre encore un peu ou c'est bon pour redémarrer ?