10.14 Mojave Espace disque bloqué

Fab'Fab

Voight-Kampf Tester
Club iGen
5 Décembre 2000
16 055
3 183
Salut tout le monde
J'avais 90go de libre sur le SSD de mon MacBook Pro (2012) sous Mojave.
J'ai bossé sur des gros fichiers de 85Go et quand j'ai fini, j'ai tout effacé.
Mystère de l'informatique, il ne m'a libéré que 2Go...
Une idée du pourquoi et du comment faire pour récupérer ce qui manque ?
Merci !
 
T'as regardé tes Snapshot ?
 
:coucou: Fab'Fab

Invité
doit avoir raison. Lance le Terminal et passe les 2 commandes (une à la fois) :
Bloc de code:
diskutil list
tmutil listlocalsnapshots /

  • la 1ère affiche le tableau des disques. Elle montrera ta configuration (sans doute apfs) et l'occupation du volume de démarrage
  • la 2è liste les éventuels snapshots (instantanés temporels du volume de démarrage) : une nouveauté du système de fichiers apfs --> qui a des effets collatéraux sur l'occupation de l'espace du volume

Poste les tableaux en copier-coller > le coller dans une fenêtre de code ainsi -->
  • dans cette page de MacGé > presse le bouton
    524315_original.png
    ici :
    521520_original.png

    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é)
 
Bloc de code:
 #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *500.1 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         499.9 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +499.9 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume Fab                     489.9 GB   disk1s1
   2:                APFS Volume Preboot                 45.4 MB    disk1s2
   3:                APFS Volume Recovery                1.0 GB     disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *63.9 GB    disk2
   1:               Windows_NTFS MUSIC                   63.8 GB    disk2s1

MBP-Fabien:~ fabienr$ tmutil listlocalsnapshots /

T'as regardé tes Snapshot ?
Oui, j'avais regardé. il n'y en a pas
 
Dernière édition par un modérateur:
Il y a bien un format apfs. Le volume de démarrage -->
Bloc de code:
   1:                APFS Volume Fab                     489.9 GB   disk1s1

  • manque sérieusement d'espace libre : 490 Go d'occupation + 3 Go des volumes auxiliaires = 493 Go. Conteneur d'une capacité de 500 Go : reste à peine 7 Go.

L'existence de snapshots est la 1ère raison à laquelle on pense pour expliquer une telle occupation du volume. Car ils retiennent à l'état "occupé" l'espace des blocs qui portaient les fichiers au moment T de l'instantané. Même si tu supprimes des masses de ces fichiers ensuite : l'espace occupé ne diminue pas > car les blocs rentent "occupés".

Donc tu confirmes bien qu'aucune ligne de ce type :
Bloc de code:
com.apple.TimeMachine.2019-03-12-224335

  • n'est retournée par la commande ?
 
Ben oui, effectivement il ne reste rien alors que j'ai libéré pratiquement 85Go...
Oui, je confirme parce que j'avais fait la démarche et déjà effacé le seul snapshot qu'il y avait.
 
Alors il faut changer d'hypothèse (dommage : on tenait un coupable tout trouvé :hilarious: ). On va tenter d'incriminer l'apfs.

Passe la commande :
Bloc de code:
diskutil verifyVolume disk1

  • la commande vérifie l'apfs > en passant en revue ses composants. Il y a normalement un gel en session lors de la vérification du fsroot tree (le composant formateur du volume Fab)

Poste l'affichage retourné --> histoire de voir s'il n'y aurait pas des erreurs dans ce système de fichiers.
 
Bloc de code:
Started file system verification on disk1
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
The volume Fab was formatted by newfs_apfs (748.67.14) and last modified by apfs_kext (945.241.4)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
warning: apfs_num_other_fsobjects (60) is not valid (61)
Checking volume
Checking the APFS volume superblock
The volume Preboot was formatted by newfs_apfs (748.57.19) and last modified by apfs_kext (945.241.4)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume Recovery was formatted by newfs_apfs (748.57.19) and last modified by apfs_kext (945.241.4)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Checking volume
Checking the APFS volume superblock
The volume VM was formatted by newfs_apfs (748.57.19) and last modified by apfs_kext (945.241.4)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking the extent ref tree
Checking the fsroot tree
Verifying allocated space
Performing deferred repairs
The volume /dev/disk0s2 appears to be OK
Storage system check exit code is 0
Finished file system verification on disk1
 
Alors il n'y a pas d'erreur critique dans l'apfs qui expliquerait une occupation indue de l'espace. Par exemple une erreur du spaceman (space_manager : gestionnaire de l'allocation des blocs). Il faut également abandonner cette hypothèse.

----------

On va donc former une 3è hypothèse : il doit y avoir une accumulation indue de fichiers dans une localisation graphiquement invisible (non affichée par le Finder) : soit de dossiers-Système > soit de dossiers de ta Bibliothèque personnelle du compte d'utilisateur fabien.

La meilleure façon de traquer des anomalies est de lancer une commande du (disk_usage) : utiltaire dédié à la mesure (toujours en Gi = Gibibytes : base 2) des fichiers / dossiers. Mais ! --> l'activation du SIP (protocole de sécurisation) dans les OS récents --> dénie l'accès en lecture à la commande du à des dossiers protégés - comme justement certains de la Bibliothèque personnelle de l'utilisateur.

Passe donc en préalable la commande informative :
Bloc de code:
csrutil status

  • qui retourne le statut actuel du SIP

Poste le retour --> qu'on sache à quoi s'en tenir...
 
Alors je te conseille de le désactiver (ne serait-ce que provisoirement) --> afin d'éviter des perturbations pour la commande du. Avec le SIP activé > il y aurait des kyrielles d'« Operation not permitted » affichées.

----------

Pour désactiver le SIP > redémarre > les 2 touches ⌘R (cmd R) tenues pressées de l'écran noir => à la  = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Va à la barre de menus supérieure de l'écran > Menu Utilitaires > sous-menu : Terminal.

Lance-le et passe la commande :
Bloc de code:
csrutil disable

  • qui désactive le SIP
  • note : pour réactiver le SIP > ce sera la commande :
Bloc de code:
csrutil enable

  • dans le même terminal de la session de secours.

Cela fait > quitte le Terminal > va à : Menu  > Disque de démarrage > sélectionne Fab > redémarre dessus.

----------

De retour dans ta session > passe la commande (copier-coller direct) :
Bloc de code:
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +

  • commande super-lente d'exécution. Attends le retour de l'invite-de-commande : MBP-Fabien:~ fabienr$ en signal de complétion
  • la commande liste & mesure (en Gi) les fichiers / dossiers de 1er ordre (visibles ou cachés) du volume de démarrage

Poste le tableau --> aucune localisation de fichiers n'aura pu échapper à cette commande.
 
quand même un truc bizarre. on dirait que la place se libère tout doucement. Hier j'étais à 4Go de libre, là je suis presque à 7...Ca m'avait déjà fait ça. j'avais libéré pas mal de place et quelques jours après, j'ai allumé l'ordi et j'avais 80Go libres que je n'avais pas la veille...
 
et là je suis presque à 8.

Bloc de code:
1,0K    /home
  0B    /Informations sur l’utilisateur
441M    /usr
4,0K    /.abackblaze
8,0K    /.bzvol
720M    /.Spotlight-V100
1,0K    /net
8,0K    /.DS_Store
  0B    /.PKInstallSandboxManager-SystemSoftware
2,5M    /bin
  0B    /installer.failurerequests
  0B    /Network
1,0M    /sbin
  0B    /.file
  0B    /etc
  0B    /var
27G    /Library
84G    /.cleverfiles
6,4G    /System
1,0G    /vm
4,0K    /.OSInstallerMessages (depuis l’ancien Mac)
45M    /.fseventsd
3,0G    /private
255M    /.DocumentRevisions-V100
  0B    /.vol
290G    /Users
41G    /Applications
4,5K    /dev
128K    /Volumes
  0B    /tmp
  0B    /.dbfseventsd
  0B    /cores
MBP-Fabien:~ fabienr$

bon on dirait que mes 84Go manquants sont dans .cleverfiles
 
Dernière édition par un modérateur:
Avant toute scrutation plus fine --> je te signale ceci (comme tu l'avais déjà vu)-->
Bloc de code:
84G    /.cleverfiles

  • 84 Gi = 90 Go => rien que dans un dossier invisible /.cleverfiles de l'espace-racine du volume. Dossier invisible graphiquement bien entendu.

Donc tu bennes ce dossier parasite par la commande :
Bloc de code:
sudo rm -rf /.cleverfiles

  • et tu vas déjà récupérer de l'espace libre. Je ne saurais pas t'expliquer exactement le rôle de ce dossier et de ce stockage indû. Dossier absent régulièrement de l'espace-racine. La commande passe sans commentaire.

Une commande :
Bloc de code:
df -H /

  • passée ensuite --> te retourne le nouvel état de l'occupation des blocs du volume de démarrage

Tu n'as qu'à le poster.
 
C'est bon, je suis remonté à 97Go disponibles !
Donc ce truc clever files vient de l'utilitaire DiskDrill. j'ai viré tout ce qui y avait trait des dossier Bibliothèques.
Merci pour le coup de main et pour le temps passé !
 
Content pour toi !

Tu peux réactiver le SIP (dans le terminal de l'OS de secours) si tu veux.

Si jamais tu avais de nouveau un problème d'occupation d'espace --> tu n'aurais qu'à récidiver les procédés d'exploration de ce fil et tu tomberais forcément sur le facteur perturbateur.
 
Oui, je l'avais fait !
tant que j'y suis, j'abuse un peu : mon Mac met plus d'une minute à démarrer sur le SSD. J'ai l'impression d'avoir un vieux DD. Tu as une idée de ce qui peut ralentir comme ça ?
 
Si tu as installé Mojave > alors comme tous les derniers OS pas encore achevés de finaliser --> le démarrage est super-lent. Ça me le fait même avec un Mac dernier cri et un SSD PCIe.

Regarde quand même à : Menu  > Préférences Système > Disque de démarrage --> si le volume Fab est bien sélectionné comme volume de démarrage automatique pour l'EFI. Si ce n'était pas le cas > il y aurait un temps de vasouillage au départ.