M
Membre supprimé 1060554
Invité
Situation normale : pas de partition BOOTCAMP > pas d'espace libre en-dehors du Conteneur apfs : RAS.
10.13 High Sierra Problème de partition
- Créateur du sujet pixelable
- Date de début
M
Membre supprimé 1060554
Invité
Ah ! oui : je n'avais pas déroulé le tableau jusqu'au Logical Volume caché d'affichage -->
En vérification de ces spéculations --> passe la commande :
Poste ce tableau.
Bloc de code:
2: Apple_CoreStorage Fusion Drive 27.6 GB disk0s2
----------------------------------------------------------------------------------------------------
2: Apple_CoreStorage Fusion Drive 999.3 GB disk1s2
----------------------------------------------------------------------------------------------------
0: Apple_HFS Macintosh HD +899.6 GB disk2- chacune des partitions disk0s2 & disk1s2 recèle un magasin de stockage physique CoreStorage appelé : Physical Volume. La somme des 2 donne une capacité de 1026,9 Go de magasinage. Par contre le Logical Volume disk2 exporté à partir de ces 2 magasins comme espace-disque virtuel "miroir" --> ne fait que 899,6 Go. Il y a donc une perte de 127,3 Go du Volume Logique par rapport aux magasins Physical Volumes.
- c'est le résultat d'un accident de récupération de l'espace libre à un Conteneur CoreStorage --> qui donne lieu à une "erreur de taille interne". Le pronostic de réparation de cette erreur est toujours réservé.
En vérification de ces spéculations --> passe la commande :
Bloc de code:
diskutil cs list- qui affiche le tableau détaillé du CoreStorage du Fusion Drive
Poste ce tableau.
D'accord pas de soucis, voici ;
Bloc de code:
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
=========================================================
Name: Fusion Drive
Status: Online
Size: 1026896293888 B (1.0 TB)
Free Space: 126334160896 B (126.3 GB)
|
+-< Physical Volume DDF82B1C-264B-4977-87C6-12E70E7064BB
| ----------------------------------------------------
| Index: 0
| Disk: disk1s2
| Status: Online
| Size: 999345127424 B (999.3 GB)
|
+-< Physical Volume 18405E4A-2706-40E5-A191-ED0BAF0A315D
| ----------------------------------------------------
| Index: 1
| Disk: disk0s2
| Status: Online
| Size: 27551166464 B (27.6 GB)
|
+-> Logical Volume Family 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
----------------------------------------------------------
Encryption Type: None
|
+-> Logical Volume 65E21C3F-7471-4BB4-A4E5-509796CC3290
---------------------------------------------------
Disk: disk2
Status: Online
Size (Total): 899646488576 B (899.6 GB)
Revertible: No
LV Name: Macintosh HD
Volume Name: Macintosh HD
Content Hint: Apple_HFS
LVG Type: Fusion, Sparse
M
Membre supprimé 1060554
Invité
Le tableau montre bien qu'il s'agit d'une erreur interne au Conteneur CoreStorage : la somme des tailles des 2 Physical Volumes (magasins) est plus large que la taille du Logical Volume (disque miroir exporté). Il y a donc de l'espace libre dans le Conteneur (et pas en-dehors) -->
Passe la commande :
=> poste l'affichage "informatif" retourné par l'échec (prévisible) de la commande
Bloc de code:
Free Space: 126334160896 B (126.3 GB)- précisément sur le magasin Physical Volume disk1s2 du HDD (le seul affecté par des redimensionnements).
Passe la commande :
Bloc de code:
diskutil coreStorage resizeLV 65E21C3F-7471-4BB4-A4E5-509796CC3290 0b- la commande instruit une dilatation du Logical Volume dans le Conteneur CoreStorage --> afin que cet espace-disque virtuel récupère l'espace libre du magasin de stockage Physical Volume du HDD
- cette commande > quoique formellement documentée > échoue toujours en cas d'« erreur de taille interne » --> je la détourne donc ici de sa fonction "opératoire" > sur une fonction "informative" --> car elle déclenche un message de confirmation du type d'erreur :
Bloc de code:
You should run whole disk repair
=> poste l'affichage "informatif" retourné par l'échec (prévisible) de la commande
Voici la réponse que cela ressort :
Bloc de code:
The Core Storage Logical Volume UUID is 65E21C3F-7471-4BB4-A4E5-509796CC3290
Started CoreStorage operation
Error: -69674: The provided Core Storage logical volume has an incorrect size; you should run whole-disk repair
M
Membre supprimé 1060554
Invité
Confirmation de l'erreur de taille interne.
Il faudrait que tu re-démarres par internet (⌘⌥R). Quand tu seras dans la session de secours correspondante > passe la commande :
Il faudrait que tu re-démarres par internet (⌘⌥R). Quand tu seras dans la session de secours correspondante > passe la commande :
Bloc de code:
diskutil list- et poste le tableau --> que j'aie l'index des disques.
Voici le tableau pour les index des disques :
Bloc de code:
/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_CoreStorage Fusion Drive 999.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 28.0 GB disk1
1: EFI EFI 314.6 MB disk1s1
2: Apple_CoreStorage Fusion Drive 27.6 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +2.1 GB disk2
1: Apple_HFS OS X Base System 2.0 GB disk2s1
/dev/disk3 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +899.6 GB disk3
Logical Volume on disk0s2, disk1s2
65E21C3F-7471-4BB4-A4E5-509796CC3290
Unencrypted Fusion Drive
/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +5.2 MB disk4
/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk5
/dev/disk6 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk6
/dev/disk7 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk7
/dev/disk8 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk8
/dev/disk9 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk9
/dev/disk10 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk10
/dev/disk11 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +12.6 MB disk11
/dev/disk12 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +4.2 MB disk12
/dev/disk13 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk13
/dev/disk14 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk14
/dev/disk15 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk15
/dev/disk16 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk16
/dev/disk17 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk17
/dev/disk18 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk18
/dev/disk19 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk19
/dev/disk20 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk20
/dev/disk21 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk21
M
Membre supprimé 1060554
Invité
Alors passe les commandes (l'une après l'autre) -->
=> poste les affichages retournés par ces 3 commandes.
Bloc de code:
diskutil repairVolume disk3
diskutil repairDisk disk1
diskutil repairDisk disk0- à validation des 2 dernières > tu auras à confirmer --> tape y (comme yes) et revalide chaque fois
- la 1ère répare : a) le système de stockage CoreStorage > b) le système de fichiers jhfs+ du volume terminal
- la 2è répare la table de partition GPT du SDD
- la 3è répare la table de partition GPT du HDD
=> poste les affichages retournés par ces 3 commandes.
Je viens d'effectuer les commandes, cependant en voulant aller trop vite j'ai quitter le terminal sans copier les affichages retournés...
J'ai donc recommencer une seconde fois en espérant que cela ne change pas le résultat que voici ;
J'ai donc recommencer une seconde fois en espérant que cela ne change pas le résultat que voici ;
Bloc de code:
-bash-3.2# diskutil repairVolume disk3
Started file system repair on disk3 Macintosh HD
Verifying storage system
Performing fsck_cs -n -x --lv --uuid 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 2 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 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
Load and verify 65E21C3F-7471-4BB4-A4E5-509796CC3290
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 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 appears to be OK
Storage system check exit code is 0
Repairing file system
Volume was successfully unmounted
Performing fsck_hfs -fy -x /dev/rdisk3
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
Checking volume information
Trimming unused blocks
The volume Macintosh HD appears to be OK
File system check exit code is 0
Restoring the original state found as mounted
Checking for overcommitted space in Logical Volume Group
Finished file system repair on disk3 Macintosh HDMalheureusement il semblerait que je sois limité en nombre de caractère sur le forum, voici la suite du code retourné.
Bloc de code:
-bash-3.2# diskutil repairDisk disk1
Repairing the partition map might erase disk1s1, proceed? (y/N) y
Started partition map repair on disk1
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk1s3
Verifying file system
Volume is already unmounted
Performing fsck_hfs -fn -x /dev/rdisk1s3
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
Checking volume information
The volume Boot OS X appears to be OK
File system check exit code is 0
Restoring the original state found as unmounted
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Verifying storage system
Performing fsck_cs -n -x --lv --uuid 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 3 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 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
Load and verify 65E21C3F-7471-4BB4-A4E5-509796CC3290
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 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 appears to be OK
Storage system check exit code is 0
Repairing storage system
Performing fsck_cs -y -x --lv --uuid 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
The volume disk0s2+disk1s2 cannot be repaired when it is in use
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 3 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 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
Load and verify 65E21C3F-7471-4BB4-A4E5-509796CC3290
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 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 appears to be OK
Storage system check exit code is 0
The partition map appears to be OK
Finished partition map repair on disk1Et la troisième et dernière partie :
Bloc de code:
-bash-3.2# diskutil repairDisk disk0
Repairing the partition map might erase disk0s1, proceed? (y/N) y
Started partition map repair on disk0
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Checking booter partition disk0s3
Verifying file system
Volume is already unmounted
Performing fsck_hfs -fn -x /dev/rdisk0s3
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
Checking volume information
The volume Recovery HD appears to be OK
File system check exit code is 0
Restoring the original state found as unmounted
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Verifying storage system
Performing fsck_cs -n -x --lv --uuid 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 3 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 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
Load and verify 65E21C3F-7471-4BB4-A4E5-509796CC3290
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 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 appears to be OK
Storage system check exit code is 0
Repairing storage system
Performing fsck_cs -y -x --lv --uuid 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979
The volume disk0s2+disk1s2 cannot be repaired when it is in use
Checking volume
disk0s2: Scan for Volume Headers
disk1s2: Scan for Volume Headers
disk0s2: Scan for Disk Labels
disk1s2: Scan for Disk Labels
Logical Volume Group 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 spans 2 devices
disk0s2+disk1s2: Scan for Metadata Volume
Logical Volume Group has a 62 MB Metadata Volume with no redundancy
Start scanning metadata for a valid checkpoint
Load and verify Segment Headers
Load and verify Checkpoint Payload
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Load and verify Transaction Segment
Incorporate 3 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 7B57D61E-AD74-4E08-BD15-3EA7BE4FE70A
Load and verify 65E21C3F-7471-4BB4-A4E5-509796CC3290
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 4B9F01AE-6A5E-46F4-B9BB-BDF3FA40D979 appears to be OK
Storage system check exit code is 0
The partition map appears to be OK
Finished partition map repair on disk0
M
Membre supprimé 1060554
Invité
Le voici, je ne comprends pas tous les disques mais si je ne me trompe pas le fait d'avoir bien 1to pour le disque principal semble être positif...
Bloc de code:
/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_CoreStorage Fusion Drive 999.3 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
/dev/disk1 (internal):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme 28.0 GB disk1
1: EFI EFI 314.6 MB disk1s1
2: Apple_CoreStorage Fusion Drive 27.6 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +2.1 GB disk2
1: Apple_HFS OS X Base System 2.0 GB disk2s1
/dev/disk3 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +1.0 TB disk3
Logical Volume on disk0s2, disk1s2
65E21C3F-7471-4BB4-A4E5-509796CC3290
Unencrypted Fusion Drive
/dev/disk4 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +5.2 MB disk4
/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk5
/dev/disk6 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk6
/dev/disk7 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk7
/dev/disk8 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk8
/dev/disk9 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk9
/dev/disk10 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk10
/dev/disk11 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +12.6 MB disk11
/dev/disk12 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +4.2 MB disk12
/dev/disk13 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk13
/dev/disk14 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk14
/dev/disk15 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk15
/dev/disk16 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk16
/dev/disk17 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +1.0 MB disk17
/dev/disk18 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk18
/dev/disk19 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +6.3 MB disk19
/dev/disk20 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +524.3 KB disk20
/dev/disk21 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: untitled +2.1 MB disk21
M
Membre supprimé 1060554
Invité
L'erreur de taille interne au Conteneur CoreStorage a été réparée par les opérations massives précédentes > qui ont eu pour effet de rajuster la taille du Logical Volume à congruence de celle des 2 magasins Physical Volumes -->
- problème résolu : tu peux redémarrer normalement sur macOS.
Super, je viens de redémarré normalement et effectivement j'ai bien 1tb disponible.
C'est donc réglé, merci encore pour ton aide et ton temps !
M
Membre supprimé 1060554
Invité
- la récupération d'espace libre à un Conteneur CoreStorage > est une opération de haute complexité qui se trouve "sensible à l'accident" > car cette opération consiste dans un enchaînement temporel de 2 "paires de redimensionnements" -->
- une paire "physique" : le magasin de stockage physique des écritures Physical Volume du DDE & le conteneur de sa partition de résidence disk0s2 sur le disque
- une paire "logique" : le disque virtuel exporté Logical Volume disk3 & le volume jhfs+ Macintosh HD hôte de son espace-disque virtuel
Cet enchaînement virtuose (un des titres de gloires de l'ingéniérie Apple) est "sensible à l'accident" > exactement comme dans une course de relais le moment du "passage du bâton" du relayeur A au relayeur B à l'entrée du virage : il y a risque de "chute du bâton" et d'interruption de la séquence continue de la course.
Si tu ne te représentes métaphoriquement ainsi le problème --> tu concevras sans mal aucun que dans ton cas > il y a eu "chute du bâton" au moment du passage entre le "redimensionnement physique" & le "redimensionnement logique" -->
- le magasin de stockage physique Physical Store avait bien été dilaté de la reprise de l'espace libre à une taille de 999,3 Go > et concomitament le conteneur de la parition-disque du HDD disk0s2 dilaté à la même taille de 999,3 Go - cela dûment enregistré dans la table GPT du HDD
- mais une "interruption accidentelle d'enchaînement" (erreur au passage du relais) a fait que --> la paire "logique" (Logical Volume du CoreStorage & volume jhfs+ Macintosh HD hôte) > n'a pas "suivi le mouvement" > mais est restée à ses dimensions antérieures = 865.4 Go de Logical Volume & donc 865.4 Go d'espace pour le volume-hôte Macintosh HD
Cette "fixation" de la seconde paire ("paire logique") à sa taille primitive --> a eu un effet remarquable dans la distribution du Conteneur CoreStorage (= "Logical Volume Group") : une "erreur de taille interne" en tant que précipité logique d'un décalage temporel : le magasin physique Physical Volume dilaté existant dans une extension du "temps présent" > tandis que le disque virtuel Logical Volume restait fixé dans un retractation du "temps antérieur". Une discordance temporelle dans le Conteneur > se précipitant en "erreur de taille interne".
Les 3 réparations logiques dans la session de l'OS de secours en RAM (téléchargé par internet) --> ont (en quelque sorte) "remis les pendules à l'heure" dans le Conteneur CoreStorage. Permis la reprise du processus de dilatation de la "paire logique" à congruence de taille de la "paire physique". En somme : rattrapé l'erreur de taille interne > en permettant à la paire logique fixée dans un "temps antérieur" > de rattraper le "temps présent" de la "paire physique".
Il y a souvent en informatique un droit de "séance de rattrapage". Ici > repasser le bâton au 2è relayeur pour qu'il termine la course comme si aucun échec n'était intervenu une 1ère fois. Pour un entendement spéculatif --> l'informatique offre des objets admirables à l'examen conceptuel. Le CoreStorage fait partie de ces objets qui forcent l'admiration.
