Sujet unique Si le stockage « Système » prend trop de place

Si tu n'as pas besoin de Filevault, va dans le menu /Préférences systèmes/Sécurité/Onglet Filevault/Désactiver. et là faut être patient(e).:D

Pour le reste, ton système à l'air clean maintenant.

Ça fait une différence?
Attention quand même tu as beaucoup d'onglets ouverts dans Chrome (8), ça prend de la mémoire.;)

Ça alourdit le système d'être crypté en fait ? En tout cas je vous remercie d'avoir pris le temps de m'aider et de m'avoir guider dans ces opérations !! :)
 
Tu n'es pas à jour, la dernière version est la 10.12.3.

Tu utilises une version bêta, donc pas encore officielle pour mac OS Sierra et il y a beaucoup d'utilitaires qui sont lancés au démarrage.

Tu as encore un BlackBerry ? C'est aussi lancé au démarrage.


Salut, je vais mettre à jour mon système alors, pour voir ce qu'il en est ! Et moi, je peux influer sur le nombre d'utilitaires qui se lancent seuls au démarrage ? En revanche, je n'ai plus de blackberry non. Pourtant j'avais effacé l'application proprement avec AppCleaner.. Il en reste des résidus si je comprends bien ?
 
  • J’aime
Réactions: zoelxg
Donne les retours de :
sudo du -sh /
et
sudo du -sh /.*
Bonjour,

Connaissant le même problème, j'ai lancé la séquence et voici le résultat:
du: /../Volumes/MobileBackups 1/Backups.backupdb/MacBook Pro de STEVE/2017-10-22-205824: No such file or directory

75G /..

12K /.DS_Store

5,8M /.DocumentRevisions-V100

6,9G /.MobileBackups

0B /.PKInstallSandboxManager

0B /.PKInstallSandboxManager-SystemSoftware

270M /.Spotlight-V100

0B /.Trashes

0B /.file

58M /.fseventsd

0B /.vol

pc24:~ Steve$

J'utilise CleanMyMac3, et réalise des sauvegardes sur DD externe.
Mon DD interne est de 128 Gb, lorsque je lance une analyse sous OmniDiskSweeper l'espace occupé est de 25,3 Gb dont 6,2 Gb par le system. Alors que l'on m'affiche 23Gb de disponible au lieu d'une 100 de GB normalement.
Comment récupérer le bonne espace svp?

Merci

bon espace...sorry :)
 
Dernière édition par un modérateur:
Salut Blue

Passe la commande :
Bloc de code:
df -H /
(mets le H en majuscule)

  • qui retourne la mesure des espaces : total > occupé > libre pour le volume démarré

Tu n'as poster ce tableau ici en copier-coller > mais pour bien faire --> avant de faire 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é).

----------

Par ailleurs > va à : Menu  > À propos de ce Mac > Stockage --> fais une capture d'écran de la jauge horizontale qui affiche l'occupation du disque > et poste ce fichier ici (tu as un bouton : Transférer un fichier en-dessous du champ de saisie d'un message).

----------

Enfin > quel OS utilises-tu actuellement ? - est-ce que c'est «Sierra 10.12» ?
 
Bloc de code:
pc24:~ Steve$ df -H /
Filesystem   Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1   120G   107G    13G    90%  659155 4294308124    0%   /
pc24:~ Steve$

merci pour ton retour,
Oui je suis sous Mac Sierra 10.12.6
Et voici la copie d'écran souhaitée:

Je me demande si cela ne vient pas de TimeMachine, non?
 

Fichiers joints

  • Capture d’écran 2017-10-23 à 11.02.12.webp
    Capture d’écran 2017-10-23 à 11.02.12.webp
    19 KB · Affichages: 191
Dernière édition par un modérateur:
Tu as 22 Go déclarés "libres" > mais sur ces 22 Go il n'y a que 13 Go de réellement "vacants" > les 9 Go restants étant constitués par de l'espace "purgeable" (occupé > mais libérable).

Mais surtout tu as 107 Go d'espace "occupé" (par des écritures de fichiers). Passe la commande :
Bloc de code:
sudo du -shx /*
(qui va prendre un peu de temps à s'effectuer)

  • tu vas obtenir le tableau des dossiers de l'espace-racine de ton volume démarré > avec mesure de la taille de chacun

=> tu n'as qu'à poster ce tableau ici en copier-coller dans une fenêtre de Code.
 
  • J’aime
Réactions: Blue@512
Tu as 22 Go déclarés "libres" > mais sur ces 22 Go il n'y a que 13 Go de réellement "vacants" > les 9 Go restants étant constitués par de l'espace "purgeable" (occupé > mais libérable).

Mais surtout tu as 107 Go d'espace "occupé" (par des écritures de fichiers). Passe la commande :
Bloc de code:
sudo du -shx /*
(qui va prendre un peu de temps à s'effectuer)

  • tu vas obtenir le tableau des dossiers de l'espace-racine de ton volume démarré > avec mesure de la taille de chacun

=> tu n'as qu'à poster ce tableau ici en copier-coller dans une fenêtre de Code.
Ok merci, la commande est lancée

Voici le retour:

Bloc de code:
pc24:~ Steve$ sudo du -shx /*
6,1G    /Applications
1,4G    /Library
  0B    /Network
7,8G    /System
5,9G    /Users
4,0K    /Volumes
2,5M    /bin
  0B    /cores
4,5K    /dev
4,0K    /etc
1,0K    /home
4,0K    /installer.failurerequests
1,0K    /net
5,5G    /private
1,0M    /sbin
4,0K    /tmp
486M    /usr
4,0K    /var
pc24:~ Steve$
 
En faisant la somme de ce calcul de la taille des fichiers --> tu as 27 Go de fichiers écrits dans le volume démarré. Alors que 107 Go de blocs logiques sont considérés comme "occupés" sur la partition. Soit un excédent de 80 Go.

80 Go de blocs occupés > sans qu'il s'agisse d'une occupation par des fichiers répertoriés.

La conjecture qui me vient à l'esprit --> est qu'il y a peut-être une corruption dans le système de fichiers qui conditionnne le volume. Au sens où il y a aurait une erreur de computation dans l'allocation des blocs libres.

Passe la commande :
Bloc de code:
diskutil verifyVolume /

  • qui va vérifier en mode "live" (le volume démarré maintenu monté) > le système de fichiers JHFS+ de la partition. Un gel momentané des processus dans la session est susceptible de se produire de par le mode "live" de l'opération.

=> tu n'as qu'à poster ici encore l'ensemble de l'affichage retourné par cette vérification.
 
Il y a aussi qu'en faisant
Bloc de code:
sudo du -shx /*
on évite de regarder dans les dossiers commençant par un point. Du coup, ce que je fais est
Bloc de code:
sudo du -shx /.??*
qui me permet de les évaluer aussi (les points d'interrogation permettent d'éviter les deux dossiers particuliers que sont '.' (là où l'on se trouve) et '..' (le dossier parent).
 
En faisant la somme de ce calcul de la taille des fichiers --> tu as 27 Go de fichiers écrits dans le volume démarré. Alors que 107 Go de blocs logiques sont considérés comme "occupés" sur la partition. Soit un excédent de 80 Go.

80 Go de blocs occupés > sans qu'il s'agisse d'une occupation par des fichiers répertoriés.

La conjecture qui me vient à l'esprit --> est qu'il y a peut-être une corruption dans le système de fichiers qui conditionnne le volume. Au sens où il y a aurait une erreur de computation dans l'allocation des blocs libres.

Passe la commande :
Bloc de code:
diskutil verifyVolume /

  • qui va vérifier en mode "live" (le volume démarré maintenu monté) > le système de fichiers JHFS+ de la partition. Un gel momentané des processus dans la session est susceptible de se produire de par le mode "live" de l'opération.

=> tu n'as qu'à poster ici encore l'ensemble de l'affichage retourné par cette vérification.
Voilà le résultat:

Bloc de code:
pc24:~ Steve$ diskutil verifyVolume /
Started file system verification on disk1 Macintosh HD
Verifying storage system
Checking volume
disk0s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
Logical Volume Group 4DB24A3D-6B50-447D-AE23-3A20015EDCA2 on 1 device
disk0s2: Scan for Metadata Volume
Logical Volume Group has a 24 MB Metadata Volume with double redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Incorporate 0 newer non-checkpoint transactions
Load and verify Virtual Address Table
Load and verify Segment Usage Table
Load and verify Metadata Superblock
Load and verify Logical Volumes B-Trees
Logical Volume Group contains 1 Logical Volume
Load and verify BD240F16-D3B4-4A25-91C9-FE1512DDF984
Load and verify CB9FA301-20B1-4487-945B-DA5BEAE1E145
Load and verify Freespace Summary
Load and verify Block Accounting
Load and verify Live Virtual Addresses
Newest transaction commit checkpoint is valid
Load and verify Segment Cleaning
The volume 4DB24A3D-6B50-447D-AE23-3A20015EDCA2 appears to be OK
Storage system check exit code is 0
Verifying file system
Using live mode
Performing live verification
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking volume bitmap
Volume bitmap needs minor repair for orphaned blocks
Checking volume information
Invalid volume free block count
(It should be 21571106 instead of 5195815)
The volume Macintosh HD was found corrupt and needs to be repaired
File system check exit code is 8
Error: -69845: File system verify or repair failed
Underlying error: 8: Exec format error
pc24:~ Steve$
 
Salut Blue

La vérification du système de fichiers me paraît corroborer ma conjecture ici -->
Bloc de code:
Checking volume bitmap
Volume bitmap needs minor repair for orphaned blocks
Checking volume information
Invalid volume free block count
(It should be 21571106 instead of 5195815)
The volume Macintosh HD was found corrupt and needs to be repaired
File system check exit code is 8

En bref : il y a une erreur massive de décompte des blocs libres de la partition disk0s2 > qui (dans mes propres mots ici) interprète comme blocs "non-libres" une quantité considérable de blocs "libres" sans que que ces blocs ne correspondent pour autant à des écritures de fichiers. Cette erreur dans le système de fichiers (une incohérence en fait entre 2 de ses fichiers) > a pour conséquence une corruption relative du volume Macintosh HD qui monte sur la partition : il ne lui est reconnu que 22 Go d'espace libre alors qu'il ne recèle que 27 Go de fichiers écrits - 80 Go lui étant sucrés par l'erreur de l'allocation des blocs.

Pour réparer une erreur dans le système de fichiers > il faut que le volume qu'il conditionne soit démonté > afin que le système de fichiers soit "oisif".

Donc re-démarre ton Mac les 2 touches ⌘R pressées ensemble de l'écran noir jusqu'à l'affichage de la  (démarrage sur le RecoveryOS de secours > qui permet le démontage du volume de l'OS et donc la réparation de son système de fichiers) > lance l'«Utilitaire de Disque» > sélectionne le volume de l'OS (Macintosh HD) > et fais un S.O.S. dessus. Si tu obtiens à la fin la mention : "Le volume Macintosh HD paraît en bon état" --> c'est que l'erreur du système de fichiers aura été réparée.

Re-démarre alors normalement sur l'OS > et ta session ouverte > refais des vérifications > par exemple en repassant la commande :
Bloc de code:
df -H /

  • cette commande retourne la mesure de l'occupation ou de la disponibilité des blocs en ce qui concerne le volume démarré

=> tu n'as qu'à poster ce tableau ici. Les 80 Go d'occupation fantôme devraient avoir disparu.
 
  • J’aime
Réactions: Blue@512
Merci pour cette investigation, je vais réaliser l'opération et transmettrai le résultat.
Au cas où, j'ai remarqué que 67,9 Gb sont alloués aux sauvegardes de Time Machine sur mon DD local (voir copie d'écran).
J'ai déjà une sauvegarde sur DD Externe, comment faire pour les supprimer svp?
 

Fichiers joints

  • Capture d’écran 2017-10-23 à 18.56.21.webp
    Capture d’écran 2017-10-23 à 18.56.21.webp
    22,9 KB · Affichages: 176
La commande :
Bloc de code:
sudo tmutil disablelocal
  • effectue ce que tu souhaites : désactivation des snapshots locaux et purge des existants.
 

Sujets similaires

Réponses
30
Affichages
5K
macOS
Membre supprimé 1060554
M
Réponses
15
Affichages
3K
macOS
Membre supprimé 1060554
M
Réponses
3
Affichages
1K
Mac
Membre supprimé 1060554
M