Espace invisible de 161 Go sur 500 Go ?

Passe encore la commande informative :
Bloc de code: 
csrutil status

  • qui affiche le statut du SIP (protocole de sécurité). Son activation bloquerait partiellement la commande de mesure de la taille des fichiers que j'ai l'intention de te passer

Poste le retour.
 
le SIP est désactivé:

Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ csrutil status
System Integrity Protection status: disabled.
 
Passe les 2 commandes (copier-coller - l'une après l'autre) :
Bloc de code: 
df -H /Volumes/Mac*
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 revalide
  • la 1ère mesure (en Go) l'occupation des 2 volumes principaux et l'espace libre global du Conteneur apfs
  • la 2è mesure (en Gi = gibibytes : base 2) les objets de 1er rang du volume de démarrage (fichiers ou dossiers / visibles ou cachés). Elle est très lente d'exécution : attends le retour de l'invite de commande terminée par ton nomcourt$ en signal de fin.

Poste les tableaux.
 
Alors, voici pour la première commande:
Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ df -H /Volumes/Mac*
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1s5   1.0T    11G    16G    42%  483769 9767494391    0%   /

et pour la seconde:
Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
Password:
find: /System/Volumes/Data/.Spotlight-V100: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager-SystemSoftware: No such file or directory
find: /System/Volumes/Data/mnt: No such file or directory
find: /System/Volumes/Data/.DocumentRevisions-V100: No such file or directory
find: /System/Volumes/Data/.TemporaryItems: No such file or directory
find: /System/DriverKit: No such file or directory
  0B    /home
5,4G    /usr
  0B    /.DS_Store
2,4M    /bin
8,8M    /Preboot
1016K    /sbin
  0B    /.file
  0B    /etc
  0B    /var
8,5G    /Library
369G    /System
  0B    /.VolumeIcon.icns
 76K    /.fseventsd
5,0G    /private
  0B    /.vol
250G    /Users
 70G    /Applications
3,8G    /opt
4,5K    /dev
  0B    /Volumes
  0B    /tmp
  0B    /cores
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$
 
Pour une capacité de 1 To de Conteneur apfs > il y a 16 Go d'espace disponible. Ce qui fait dans les 984 Go de blocs occupés.

- en ce qui concerne la mesure de la taille des fichiers > l'OS Catalina complique terriblement la lecture. Dans la mesure où il y a dissociation de 2 volumes : Système & Données > le volume Données se trouvant monté dans le volume Système démarré at: /System/Volumes/Data.​

- malgré le recours à une option -x pour la commande find (option interdisant théoriquement de mesurer des fichiers relevant d'un autre volume que le volume démarré) => je note que le dossier System de Macintosh HD est mesuré à 369 Gi = 396 Go. Comme le volume Macintosh HD (= Système) n'a qu'une occupation intrinsèque de 11 Go > il est clair que les fichiers du volume-Données monté at: /System/Volumes/Data => se trouvent mesurés.​

- il en va de même pour le répertoire /Users de Macintosh HD. Intrinsèquement vide (à part un dossier Partagé) lorsque ce volume n'est pas démarré et donc pas associé au volume-Données > il devient l'espace d'affichage des comptes du répertoire Users du volume compagnon : Macintosh HD - Données, une fois démarré. Malgré l'emploi de l'option -x encore > les fichiers relevant d'un autre volume et d'un autre système de fichiers => s'y trouvent mesurés (250 Gi = 268 Go).​

Il s'ensuit que Catalina organise le règne de la confusion intellectuelle > puisqu'il confond au démarrage 2 volumes logiquement distincts. Afin de tenter d'y voir un peu plus clair dans ce foutoir associatif cette mantière subtile => passe encore les 2 commandes :
Bloc de code: 
df -H /System/Volumes/Data
sudo find -x /System/Volumes/Data -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +

  • qui mesurent : l'occupation des blocs du volume-Données monté at: Data > puis la taille de ses objets de 1er rang

Poste les 2 retours.
 
C'est reparti, voici les résultats de la 1e commande:

Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ df -H /System/Volumes/Data
Filesystem     Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1s1   1.0T   970G    17G    99% 2448608 9765529552    0%   /System/Volumes/Data

Et maintenant, la seconde:
Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ sudo find -x /System/Volumes/Data -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
Password:
find: /System/Volumes/Data/.Spotlight-V100: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager: No such file or directory
find: /System/Volumes/Data/.PKInstallSandboxManager-SystemSoftware: No such file or directory
find: /System/Volumes/Data/mnt: No such file or directory
find: /System/Volumes/Data/.DocumentRevisions-V100: No such file or directory
find: /System/Volumes/Data/.TemporaryItems: No such file or directory
  0B    /System/Volumes/Data/sw
  0B    /System/Volumes/Data/.HFS+ Private Directory Data
1,0K    /System/Volumes/Data/home
4,3G    /System/Volumes/Data/.OSInstallSandboxPath.trashedSandbox
4,9G    /System/Volumes/Data/usr
1,5G    /System/Volumes/Data/.Spotlight-V100
 16K    /System/Volumes/Data/.DS_Store
  0B    /System/Volumes/Data/.PKInstallSandboxManager
4,0K    /System/Volumes/Data/.installer-compatibility
  0B    /System/Volumes/Data/.PKInstallSandboxManager-SystemSoftware
1,7M    /System/Volumes/Data/.TempReceipt.bom
  0B    /System/Volumes/Data/.file
8,5G    /System/Volumes/Data/Library
3,7G    /System/Volumes/Data/System
4,0K    /System/Volumes/Data/.OSInstallerMessages
  0B    /System/Volumes/Data/mnt
 45M    /System/Volumes/Data/.fseventsd
5,1G    /System/Volumes/Data/private
2,8G    /System/Volumes/Data/.DocumentRevisions-V100
  0B    /System/Volumes/Data/.vol
251G    /System/Volumes/Data/Users
 70G    /System/Volumes/Data/Applications
3,8G    /System/Volumes/Data/opt
  0B    /System/Volumes/Data/Volumes
  0B    /System/Volumes/Data/.TemporaryItems
  0B    /System/Volumes/Data/.dbfseventsd
  0B    /System/Volumes/Data/cores
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$
 
On voit que 970 Go de blocs occupés sont alloués au volume-Données. Pour 355,6 Gi = 382 Go de fichiers catalogués -->

- soit une sur-allocation de blocs occupés (par rapport à la taille des fichiers) de 970 Go - 382 Go => 588 Go ! - ce qui revient à dire qu'il y a 588 Go d'espace occupé fantôme > auquel ne correspondent pas de fichiers recensés.​

On peut conjecturer en 1ère instance que des snapshots se trouvent associés au volume-Données = instantanés imageant des états temporels du volume > & verrouillant tous les blocs correspondant à la configuration imagée.

- passe la commande :​
Bloc de code: 
tmutil listlocalsnapshots /System/Volumes/Data

  • qui liste les snapshots du volume-Données

Poste le retour.
 
Voici, la réponse fut rapide...

Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ tmutil listlocalsnapshots /System/Volumes/Data
Snapshots for volume group containing disk /System/Volumes/Data:
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$
 
S'il n'y a pas de snapshots > alors l'espace occupé fantôme ne peut dépendre que d'une erreur massive du spaceman (le gestionnaire de l'allocation des blocs de l'apfs).

- passe la commande :​
Bloc de code: 
diskutil verifyVolume disk1

  • la commande vérifie l'apfs : du Conteneur gobal > puis de ses volumes particuliers

Poste tout l'affichage retourné.
 
Merci de ton soutien...

Voici ce que cela donne:

Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ diskutil verifyVolume disk1
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 Macintosh HD - Données was formatted by hfs_convert (748.1.46) and last modified by apfs_kext (1412.41.1)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 2 (com.apple.apfs.purgatory.32edbe)
error: object (oid 0x8ccf6bb): Bad size for physical extent record key, len: 9
Snapshot is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Finished file system verification on disk1
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$
 
Hé ! hé ! - le mystère est éclairci -->
Bloc de code: 
Checking the snapshot metadata
Checking snapshot 1 of 2 (com.apple.apfs.purgatory.32edbe)
error: object (oid 0x8ccf6bb): Bad size for physical extent record key, len: 9
Snapshot is invalid
The volume /dev/disk0s2 could not be verified completely

  • il y a bien un snapshot > mais corrompu et donc in-manipulable. Tu es donc le "bénéficiaire" d'une combinaison : existence d'un snapshot + corruption de l'apfs.

Redémarre > les 2 touches ⌘R (cmd R) pressées pour ouvrir la session de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Lance l'Utilitaire de disque -->

- dans le coin supérieur gauche > clique la pastille "Présensation". Sélectionne l'option : "Afficher tous les appareils" => le Conteneur apfs global est affiché. Sélectionne-le et fais un S.O.S. dessus.​

Redémarre ensuite (MenuRedémarrer). Ta session réouverte > repasse la commande :
Bloc de code: 
diskutil verifyVolume disk1

  • et poste le retour => qu'on voie si l'erreur persiste.
 
Opération terminée, mais cela n'a pas l'air de changer les choses.

Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ diskutil verifyVolume disk1
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 Macintosh HD - Données was formatted by hfs_convert (748.1.46) and last modified by apfs_kext (1412.41.1)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 2 (com.apple.apfs.purgatory.32edbe)
error: object (oid 0x8ccf6bb): Bad size for physical extent record key, len: 9
Snapshot is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Finished file system verification on disk1
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$
 
Alors la seule solution pour toi consiste dans le va-et-vient suivant -->

- cloner (via la démo gratuite 1 mois de Carbon Copy Cloner) > le Groupe de volumes logiques (Système & Données) => à destination d'un DDE USB.​

- démarrer sur le clone > supprimer / recréer l'apfs interne​

- cloner à rebours (toujours via la démo de Carbon Copy Cloner) > le Groupe de volumes logiques du clone => à destination du nouveau Conteneur apfs interne​

La corruption irréparable de l'apfs (générateur du Conteneur et de ses volumes) => impose ce procédé. Il te faut un DDE paramétré "Mac" avec dans les 450 Go d'espace libre (CCC ne clonant que les fichiers réels - non les blocs prétendus occupés). As-tu un tel DDE à disposition ?
 
Oui, j'ai un disque (ExFAT) avec 750 Go disponible ou un autre (MacOS étendu) où il me reste 660 Go de libre (je peux basculer l'un sur l'autre si besoin).
 
Le DDE avec le format Mac OS étendu présente de meilleurs paramètres.

- branche-le au Mac > passe les commandes (séparément) :​
Bloc de code: 
diskutil list external
df -H

  • qui affichent : la configuration du DDE & l'occupation des volumes montés

Poste les retours.
 
Première commande:
Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ diskutil list external
/dev/disk2 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *1.0 TB     disk2
   1:                  Apple_HFS Sauvegarde Yvon         1.0 TB     disk2s1

(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$

Et la 2e commande:
Bloc de code: 
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$ df -H
Filesystem      Size   Used  Avail Capacity iused      ifree %iused  Mounted on
/dev/disk1s5    1.0T    11G    17G    40%  483777 9767494383    0%   /
devfs           198k   198k     0B   100%     672          0  100%   /dev
/dev/disk1s1    1.0T   970G    17G    99% 2451696 9765526464    0%   /System/Volumes/Data
/dev/disk1s4    1.0T   1.1G    17G     6%       2 9767978158    0%   /private/var/vm
map auto_home     0B     0B     0B   100%       0          0  100%   /System/Volumes/Data/home
/dev/disk2s1    1.0T   338G   662G    34%  395130 4294572149    0%   /Volumes/Sauvegarde Yvon
(base) MacBook-Pro-de-Yvon:~ yvoncavaloc$

je ne suis pas rassuré...
 
Je te fais confiance, ce n'est pas ça, mais l'utilisation de CCC me fout la trouille (peur de perdre des trucs importants...).
Mais, quand il faut y aller, il faut y aller ;-)
 
Alors tu risques de te sentir encore plus angoissé à lire mon topo qui suit :hilarious:-->

- la table de partition du DDE est désignée comme : "FDisk_partition_scheme". C'est une MBR (encodage Windows) qui ne supporte pas les repartitionnements a posteriori de partitions déjà définies (comme la partition unique de 1 To du volume Sauvegarde Yvon).​

- le contournement de cette limitation consiste à utiliser un exécutable fdisk de manipulation de table MBR. Par son truchement > il est possible d'éditer le descripteur MBR à paramètres constants sauf la définition de l'extension de la partition qu'on pourrait ramener à 500 Go de blocs. Cette édition du descripteur MBR de partition force une réduction de la partition n°1 à 500 Go > ce qui induit une erreur de taille dans le spaceman (le gestionnaire de l'allocation des blocs) du système de fichiers jhfs+ (Mac OS étendu journalisé) qui est le formateur du volume Sauvegarde Yvon. Malgré cette erreur de taille (le spaceman continuant de prétendre gérer 1 To de blocs alors que la partition se trouve contrainte à 500 Go) => le système de fichiers jhfs+ continue de permettre la définition et le montage du volume Sauvegarde Yvon. L'erreur est donc non fatale.​

- le dégagement de 500 Go de blocs libres > permet en seconde passe une édition de la MBR avec fdisk => créant un second descripteur de partition de type "Apple_HFS" encore pour 500 Go. Cette seconde partition créée > il devient possible de la reformater en apfs > ce qui génère une destination pour le clonage. Une fois le clonage > puis le rétro-clonage effectués => une édition à rebours des descripteurs MBR avec fdisk > permet la restauration du descripteur unique à sa taille initiale --> ce qui fait disparaître l'erreur du spaceman du système de fichiers jhfs+.​

=> tu n'avais donc pas raison de t'angoisser pour un clonage bénin > ne sachant pas que pour qu'on puisse se servir de ton DDE --> il faudrait se livrer à une édition fdisk de sa table de partition MBR :hilarious:. Cette intervention sophistiquée > je l'ai déjà dirigée une demi-douzaine de fois sur les forums dans des situations analogues à la tienne. C'est à toi de voir si tu consens à cette opération.
 
Tu as raison, je ne comprends pas un traitre mot à tout ce que tu as écrit. Mais, je ne retiens qu'une chose:
je l'ai déjà dirigée une demi-douzaine de fois sur le forums dans des situations analogues à la tienne.

Alors... Let's go!
 

Sujets similaires

K
MacBook Pro Impossible de libérer de l'espace
Réponses
3
Affichages
1K
Mac
Membre supprimé 1060554
M
J
  • Fermé
10.13 High Sierra Système prend trop de place
Réponses
76
Affichages
5K
macOS
jjeremie
J
L
Stockage Autre Apple
Réponses
11
Affichages
11K
macOS
Sly54
Sly54
T
10.12 Sierra Problème de stockage suite déplacement photothèque
Réponses
16
Affichages
1K
macOS
tx3a
T
T
Comment faire tenir 400 GO dans un SSD de 128?...
Réponses
13
Affichages
2K
macOS
Deleted member 1099514
D
Haut Bas