Ok, ça a l'air fâcheux... Dis moi, dans cette procédure, je risque pas de perdre des applications en licence, des paramètres, préférences, réglages où autres types de données, c'est certain ?
10.12 Sierra Problème de stockage...
- Créateur du sujet Bettyblue18
- Date de début
M
Membre supprimé 1060554
Invité
Le clone contient ton dossier de compte intégral > avec tes réglages et tes identifiants de licence ou de sites internet dans le «Trousseau». Donc pas de problème.
Ok !
J'ai reformaté mon DDE, je refais un clone, puis je démarre dessus et je te donne la ligne de code dont tu as besoin.
J'ai reformaté mon DDE, je refais un clone, puis je démarre dessus et je te donne la ligne de code dont tu as besoin.
Alors, la commande diskutil list donne :
Bloc de code:
#: 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
F8761934-10DC-458B-9ECB-63D686D4E152
Unencrypted
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS DDEXT LEO 499.2 GB disk2s2
3: Apple_Boot Recovery HD 650.0 MB disk2s3
M
Membre supprimé 1060554
Invité
Je me doutais que tu avais un format CoreStorage sur la partition de ton OS.
Si tu es satisfait de ton clone (fait par «CCC» il n'y a pas de problème) > voici la commande :
=> si tu n'as pas de message d'erreur au reformatage > tu peux cloner à rebours ton clone dans le nouveau volume Macintosh HD.
Si tu es satisfait de ton clone (fait par «CCC» il n'y a pas de problème) > voici la commande :
Bloc de code:
diskutil reformat disk1- cette commande va effacer le système de fichiers JHFS+ corrompu qui réside sur le Volume Logique du CoreStorage (sans affecter le système de stockage CoreStorage) > et en recréer un neuf au même point d'ancrage > qui va remonter un volume vide du même nom que le précédent > soit Macintosh HD.
=> si tu n'as pas de message d'erreur au reformatage > tu peux cloner à rebours ton clone dans le nouveau volume Macintosh HD.
Je ne sait pas ce que c'est CoreStorage, c'est étonnant d'avoir ça ?
Aller, je vais lancer cette commande, même si ça fait un peu peur j'avoue !
Aller, je vais lancer cette commande, même si ça fait un peu peur j'avoue !
M
Membre supprimé 1060554
Invité
C'est l'installateur de «Sierra» qui crée d'office un CoreStorage sur la partition de l'OS - la disk0s2 ici.
Il s'agit de 2 disques virtuels en miroir (Volume Physique > Volume Logique) > le second servant de support au système de fichiers JHFS+ qui monte le volume standard. Ce dispositif est requis en cas de chiffrement (activation de «FileVault») ; superflu dans ton cas (pas de chiffrement).
Il s'agit de 2 disques virtuels en miroir (Volume Physique > Volume Logique) > le second servant de support au système de fichiers JHFS+ qui monte le volume standard. Ce dispositif est requis en cas de chiffrement (activation de «FileVault») ; superflu dans ton cas (pas de chiffrement).
C'est bon, Macintosh HD reformaté ! On passe à 36 Go d'espace libre, ce que l'on doit au fait qu'il n'y a plus le dossier lost+found à la racine... Le système fait toujours 44 Go cependant...
Ceci-dit avec cet espace récupéré, je suis déjà plus à l'aise !
Il y a toujours la même contradiction entre la commande du qui me dit 77 Go utilisés, et la commande dh qui me dit 84 Go, avec moins d'écart cette fois.
Ceci-dit avec cet espace récupéré, je suis déjà plus à l'aise !
Il y a toujours la même contradiction entre la commande du qui me dit 77 Go utilisés, et la commande dh qui me dit 84 Go, avec moins d'écart cette fois.
Dernière édition:
M
Membre supprimé 1060554
Invité
Il faut peut-être que tu ré-indexes les bases de données de Spotlight.
Pour ce faire > tu passes la commande :
=> lorsque l'opération est complétée > re-démarre une fois > et vérifie s'il y a eu une évolution dans le panneau Stockage (le mystérieux "Système").
Pour ce faire > tu passes la commande :
Bloc de code:
sudo mdutil -E /- où l'utilitaire mdutil (metadata_utility) est appelé en droits root > avec l'option -E (Erase : effacer) > sur le point de montage / du volume démarré.
- les bases de données de Spotlight vont être effacées > et les agents de la ré-indexation lancés dans la foulée.
=> lorsque l'opération est complétée > re-démarre une fois > et vérifie s'il y a eu une évolution dans le panneau Stockage (le mystérieux "Système").
Le suspense est haletant !
Mais MacO n'est pas du soir. Peut être une nouvelle idée demain matin ?
J'en profite d'ailleurs lâchement pour ré-indexer Spotlight qui ne trouve pas tout chez moi.
Merci pour la commande
Mais MacO n'est pas du soir. Peut être une nouvelle idée demain matin ?
J'en profite d'ailleurs lâchement pour ré-indexer Spotlight qui ne trouve pas tout chez moi.
Merci pour la commande
M
Membre supprimé 1060554
Invité
À ce sujet > je pense qu'il faut savoir opérer une "mise en parenthèse" critique (« réduction épistémologique »). Le panneau Stockage présente une distribution "typologique" et pas "topologique" des fichiers.
- Par "topologique" > j'entends : un recensement des fichiers par lieux de résidence : les répertoires de premier degré de l'arborescence de l'OS. Ce que fait «OmniDiskSweeper». Ce que fait la commande du.
- Par "typologique" > j'entends : un recensement des fichiers par types d'utilisation (employés comme éléments du Système > comme applications > ou véhicules de contenus graphiques : iconique > musical > vidéo...).
Le problème des classifications par "genres" > c'est qu'il y a toujours des ambiguïtés : si je veux répartir mes livres en "genre comique" et genre "tragique" > où vais-je mettre les bouquins "tragi-comiques" ? - et les traités de philosophie - où vais-je les mettre ? Dans le "genre comique" : Épicure ? Le "genre tragique" : Pascal ? - Oui, mais les autres ? On se retrouve immanquablement obligé de créer un contenant tiers d'un "genre indéfini" qui va servir de fourre-tout pour les Kant et autres du même acabit...
----------
Si donc on "met entre parenthèses" la répartition "typologique" du panneau Stockage --> la seule chose qui importe vraiment est la mesure différentielle de l'espace total d'un volume en : espace occupé par des fichiers vs espace libre.
Voici l'évolution de ce différentiel (coloré = occupé vs blanc = libre) au cours des opérations effectuées :
répartition initiale des espaces :
total = 120,1 Go --> occupé = 104,76 Go vs libre = 15,34 Go
après semi-réparation du système de fichiers JHFS+ :
total = 120,1 Go --> occupé = 92,46 Go vs libre = 27,64 Go
après reformatage / rétro-clonage :
total = 120,1 Go --> occupé = 84,35 Go vs libre = 35,75 Go
Le système de fichiers JHFS+ qui définit le volume Macintosh HD a été recréé de neuf > les données ré-injectées depuis un clone > l'espace "purgeable" provisoirement éliminé. On a donc théoriquement une répartition binaire de l'espace des blocs : occupé par des fichiers vs libre au sens strict (ré-inscriptible).total = 120,1 Go --> occupé = 104,76 Go vs libre = 15,34 Go
après semi-réparation du système de fichiers JHFS+ :
total = 120,1 Go --> occupé = 92,46 Go vs libre = 27,64 Go
après reformatage / rétro-clonage :
total = 120,1 Go --> occupé = 84,35 Go vs libre = 35,75 Go
Cette évolution "flatteuse" de l'espace libre (de 15 à 35 Go en gros) > avec réduction concomitante de l'espace occupé (de 104 à 84 Go) > soit une variation de 20 Go en + et en - => nous conduit à la seule question qui importe -->
non pas "qualitative" --> de quel "type" sont les fichiers qui occupent l'espace du volume ?) > mais "quantitative" --> la proportion d'espace occupé vs libre dans le volume est-elle exactement mesurée par le rapport 84 Go / 36 Go (en arrondissant) ?
--> je propose donc de repasser dans le «Terminal» les 2 commandes :
Bloc de code:
sudo du -d 0 -hx /
df -H /[NB. Il est bien entendu que l'option -h pour la commande du détermine une mesure en multiples du Byte = MB / GB > et que l'option -H pour la commande df détermine identiquement une mesure en multiples du Byte = MB / GB.]
----------
Et puisque précédemment l'épineuse question du « CoreStorage » s'est immiscée dans la conversation > je propose de passer encore la commande (purement informative) :
Bloc de code:
diskutil cs list- l'utilitaire diskutil (disk_utility : utilitaire de disque) est appelé > avec le verbe list (lister) > et l'adjonction en intercalaire de cs (corestorage)
- la composition logique du Groupe de Volumes Logiques constituant le système de stockage CoreStorage va être retournée
[La contemplation de cet imposant dispositif montre instantanément qu'on accède à une autre dimension de complexité logicielle.]
Dernière édition par un modérateur:
Et bonjour !
Alors, si je comprends bien, la taille de la rubrique système n'est pas un soucis en soit car c'est un peu un fourre-tout... C'est d'ailleurs ce qui semblait apparaitre quand à un moment mes documents ont réduits pour sans doute être comptabilisés en système, alors qu'ils sont toujours là...
Alors les commandes du jour, nous donnent :
Je les avait déjà réessayées, comme dit dans mon message #28...
Alors, si je comprends bien, la taille de la rubrique système n'est pas un soucis en soit car c'est un peu un fourre-tout... C'est d'ailleurs ce qui semblait apparaitre quand à un moment mes documents ont réduits pour sans doute être comptabilisés en système, alors qu'ils sont toujours là...
Alors les commandes du jour, nous donnent :
Bloc de code:
sudo du -d 0 -hx /
78G /
Bloc de code:
df -H /
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on
/dev/disk1 120G 85G 35G 72% 1116469 4293850810 0% /
Bloc de code:
diskutil cs list
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 9D6DB5B2-188D-4A43-AA5D-734BEEA89B4B
=========================================================
Name: Macintosh HD
Status: Online
Size: 120473067520 B (120.5 GB)
Free Space: 18948096 B (18.9 MB)
|
+-< Physical Volume A607363F-5C73-4CDB-9C1E-96CAFD2B3C81
| ----------------------------------------------------
| Index: 0
| Disk: disk0s2
| Status: Online
| Size: 120473067520 B (120.5 GB)
|
+-> Logical Volume Family B4AAABA2-E0D5-4C72-B7BF-E5E0B320E89F
----------------------------------------------------------
Encryption Type: None
|
+-> Logical Volume F8761934-10DC-458B-9ECB-63D686D4E152
---------------------------------------------------
Disk: disk1
Status: Online
Size (Total): 120101797888 B (120.1 GB)
Revertible: Yes (no decryption required)
LV Name: Macintosh HD
Volume Name: Macintosh HD
Content Hint: Apple_HFS
M
Membre supprimé 1060554
Invité
Déjà > tu peux te simplifier la vie en déconstruisant (conservativement pour le volume Macintosh HD) le système de stockage CoreStorage qui n'est d'aucun usage pour toi > et qui est noté :
Pour ce faire tu fais un copier-coller de la commande :
(c'est l'UUID du Logical Volume qui est la cible). L'opération effectuée > tu re-démarres une fois (pour que le kernel cesse de garder chargé le disk1 du Volume Logique) > et tu te retrouves avec un système de fichiers JHFS+ directement ancré sur l'en-tête de la partition disk0s2.
Cela fait > tu peux passer la commande informative :
et poster le tableau retourné.
Bloc de code:
Revertible: Yes (no decryption required)
Bloc de code:
diskutil coreStorage revert F8761934-10DC-458B-9ECB-63D686D4E152Cela fait > tu peux passer la commande informative :
Bloc de code:
diskutil info disk0s2Après la commande et le redémarrage, le tableau d'infos :
Bloc de code:
Device Identifier: disk0s2
Device Node: /dev/disk0s2
Whole: No
Part of Whole: disk0
Volume Name: Macintosh HD
Mounted: Yes
Mount Point: /
Partition Type: Apple_HFS
File System Personality: Journaled HFS+
Type (Bundle): hfs
Name (User Visible): Mac OS Extended (Journaled)
Journal: Journal size 16384 KB at offset 0x381000
Owners: Enabled
OS Can Be Installed: Yes
Recovery Disk: disk0s3
Media Type: Generic
Protocol: SATA
SMART Status: Verified
Volume UUID: 56687837-289B-327C-80AB-AE3C5E644AFD
Disk / Partition UUID: 1D4D5346-2F9A-4A4C-B90C-07B63C09A29B
Disk Size: 120.5 GB (120473067520 Bytes) (exactly 235298960 512-Byte-Units)
Device Block Size: 512 Bytes
Volume Total Space: 120.5 GB (120473067520 Bytes) (exactly 235298960 512-Byte-Units)
Volume Used Space: 86.1 GB (86140743680 Bytes) (exactly 168243640 512-Byte-Units) (71.5%)
Volume Available Space: 34.3 GB (34332323840 Bytes) (exactly 67055320 512-Byte-Units) (28.5%)
Allocation Block Size: 4096 Bytes
Read-Only Media: No
Read-Only Volume: No
Device Location: Internal
Removable Media: Fixed
Solid State: Yes
M
Membre supprimé 1060554
Invité
En guise de petite synthèse > voici les espaces mesurés en fonction des utilitaires employés :
Il apparaît qu'aucune mesure d'utilitaire ne concorde exactement avec celles des autres (à part pour la mesure de l'espace total du volume-cible) ;
3 utilitaires donnent des mesures grosso modo concordantes (Stockage > diskutil > df) --> occupé = 85 Go vs libre = 35 Go (à la moyenne)
1 utilitaire donne des mesures apparemment aberrantes en comparaison des 3 autres (du) --> occupé = 78 Go vs libre = 42 Go.
----------
Mais si l'on admet que les 3 utilitaires Stockage > diskutil > df mesurent tous en Gigabytes (GB = Go) > le seul moyen de réduire l'aberration apparente est d'admettre que l'utilitaire du mesure lui en Gibibyte (= Gi). 1 Gi étant égale à 1,07374 GB --> 78 Gi = 83,75 GB.
On obtient donc le tableau homogénéisé en unité de mesure Gigabyte :
Moyennes (en valeurs arrondies) --> espace occupé = 85 GB vs espace libre = 35 GB. On peut en tirer l'idée que le juge de paix en cas d'aberrations de mesures est l'utilitaire df (display_free_space) > à la stricte condition de l'assortir de l'option -H (mesure en Gigabytes) et surtout pas de l'option -h (mesures en Gibibytes).
----------
Si l'on revient sur le début du fil > «OmniDiskSweeper» qui trouvait 84 Gb d'espace occupé vs 36 GB d'espace libre était donc dans le vrai > il devait donc être suivi dans ses mesures. Tandis que le panneau Stockage qui affichait 110 GB d'espace occupé vs 10 GB d'espace libre manifestait une pure aberration dans les mesures.
Mes efforts holmésiens pour envisager l'improbable (une discordance entre blocs indexés porteurs de fichiers et blocs flaggés purgeables sans plus d'indexation de fichiers) > n'étaient finalement pas si farfelus que cela > dans la mesure où ils présupposaient un conflit à l'intérieur du système de fichiers - entre le fichier du catalogue_B-tree et le fichier des attributs étendus.
Or > manifestement > le système de fichiers était corrompu et recelait des erreurs irréparables (une chance que le volume se montait encore !) > et c'était là la source directe des mesures aberrantes retournées par le panneau Stockage. On en tire l'argument récursif : si le panneau Stockage affiche une mesure aberrante des espaces occupé (global) vs libre > alors on peut en inférer que le système de fichiers JHFS+ définissant le volume est corrompu.
Quant à la répartition "typologique" de l'espace occupé par ce même panneau Stockage --> c'est [IMHO] une vision absurde ab origine --> aucun intérêt de se prendre la tête (d'écrou) à ce sujet > puisque on nage dans le non-sens avec un tel point de vue "typologique" (donc inutile de chercher à aménager le non-sens pour qu'il devienne producteur de sens).
=> je considère le sujet comme résolu.
Bloc de code:
Utilitaires espace total espace occupé espace libre
Stockage 120,1 GB 84,35 GB 35,75 GB
diskutil 120,5 GB 86,1 GB 34,3 GB
df 120 GB 85 GB 35 GB
du 120 GB 78 GB 42 GBIl apparaît qu'aucune mesure d'utilitaire ne concorde exactement avec celles des autres (à part pour la mesure de l'espace total du volume-cible) ;
3 utilitaires donnent des mesures grosso modo concordantes (Stockage > diskutil > df) --> occupé = 85 Go vs libre = 35 Go (à la moyenne)
1 utilitaire donne des mesures apparemment aberrantes en comparaison des 3 autres (du) --> occupé = 78 Go vs libre = 42 Go.
----------
Mais si l'on admet que les 3 utilitaires Stockage > diskutil > df mesurent tous en Gigabytes (GB = Go) > le seul moyen de réduire l'aberration apparente est d'admettre que l'utilitaire du mesure lui en Gibibyte (= Gi). 1 Gi étant égale à 1,07374 GB --> 78 Gi = 83,75 GB.
On obtient donc le tableau homogénéisé en unité de mesure Gigabyte :
Bloc de code:
Utilitaires espace total espace occupé espace libre
Stockage 120,1 GB 84,35 GB 35,75 GB
diskutil 120,5 GB 86,1 GB 34,3 GB
df 120 GB 85 GB 35 GB
du 120 GB 83,75 GB 36,25 GBMoyennes (en valeurs arrondies) --> espace occupé = 85 GB vs espace libre = 35 GB. On peut en tirer l'idée que le juge de paix en cas d'aberrations de mesures est l'utilitaire df (display_free_space) > à la stricte condition de l'assortir de l'option -H (mesure en Gigabytes) et surtout pas de l'option -h (mesures en Gibibytes).
----------
Si l'on revient sur le début du fil > «OmniDiskSweeper» qui trouvait 84 Gb d'espace occupé vs 36 GB d'espace libre était donc dans le vrai > il devait donc être suivi dans ses mesures. Tandis que le panneau Stockage qui affichait 110 GB d'espace occupé vs 10 GB d'espace libre manifestait une pure aberration dans les mesures.
Mes efforts holmésiens pour envisager l'improbable (une discordance entre blocs indexés porteurs de fichiers et blocs flaggés purgeables sans plus d'indexation de fichiers) > n'étaient finalement pas si farfelus que cela > dans la mesure où ils présupposaient un conflit à l'intérieur du système de fichiers - entre le fichier du catalogue_B-tree et le fichier des attributs étendus.
Or > manifestement > le système de fichiers était corrompu et recelait des erreurs irréparables (une chance que le volume se montait encore !) > et c'était là la source directe des mesures aberrantes retournées par le panneau Stockage. On en tire l'argument récursif : si le panneau Stockage affiche une mesure aberrante des espaces occupé (global) vs libre > alors on peut en inférer que le système de fichiers JHFS+ définissant le volume est corrompu.
Quant à la répartition "typologique" de l'espace occupé par ce même panneau Stockage --> c'est [IMHO] une vision absurde ab origine --> aucun intérêt de se prendre la tête (d'écrou) à ce sujet > puisque on nage dans le non-sens avec un tel point de vue "typologique" (donc inutile de chercher à aménager le non-sens pour qu'il devienne producteur de sens).
=> je considère le sujet comme résolu.
Ok, donc en gros à partir de maintenant, je peux considérer que mon disque a 35 Go de libre, et que toute autre estimation est a priori farfelue. Et je retiens de ne pas se fier au panneau stockage.
Merci cher ami pour ces pérégrinations, et je te souhaite bonne continuation !
Merci cher ami pour ces pérégrinations, et je te souhaite bonne continuation !
M
Membre supprimé 1060554
Invité
Oui : tu peux tabler actuellement sur 35 Go d'espace libre. Ce qui est plus confortable rapporté à la taille totale de 120 Go (29 %).
Ton fil offrait un intéressant "casse-tête" à résoudre. Merci de tes souhaits et bonne route pour toi aussi.
Ton fil offrait un intéressant "casse-tête" à résoudre. Merci de tes souhaits et bonne route pour toi aussi.
Sujets similaires
macOS Monterey
stockage disque
