Salut
slickizer
Pourquoi as-tu posté des photos d'écran de tableaux relevant d'un
Terminal de la session
Recovery > alors que tu peux ouvrir un
Terminal à partir de ta session dans l'OS (tu trouves l'application at:
Applications >
Utilitaires >
Terminal.app) ? - cela t'aurait permis de poster les tableaux en mode texte dans une fenêtre de
Code > ce qui est plus maniable pour l'interlocuteur que des photos d'écran.
Voici donc ma reconstruction de ton dispositif en mode texte > en te supposant démarré sur le volume
Macintosh HD :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage FUSIONDRIVE 121.0 GB disk0s2
6: Apple_Boot Boot OS X 134.2 MB disk0s3
/dev/disk1 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage FUSIONDRIVE 2.2 TB disk1s2
6: Apple_Boot Recovery HD 650.1 MB disk1s3
2: Apple_CoreStorage FUSIONDRIVE 801.4 GB disk1s4
6: Apple_Boot Boot OS X 134.2 MB disk1s5
/dev/disk2 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD +2.0 TB disk2
Logical Volume on disk0s2, disk1s2, ...
CDBCFC18-1BB4-4BB4-B3EB-E86DF3AE2E35
Unencrypted Fusion Drive
Cette distribution logique est typique de celle d'un
iMac déjà un peu ancien dans lequel un SSD de
121 Go et un HDD de
3 To se trouvaient associés d'usine en mode
Fusion Drive - de telle manière que l'utilisateur puisse (s'il le voulait) installer un OS «
Windows» de type «
Legacy » (
Windows-7) dans le volume d'une partition
BOOTCAMP.
En effet, un OS «
Legacy » tel que
Windows-7 boote non pas en mode
UEFI comme l'actuel «
Windows-10» > mais en mode «
BIOS_émulé » par l'
EFI (ou Programme Interne) du Mac. Ce
BIOS_émulé de l'
EFI > ne sait que lire une table de partition
MBR (alternative de la
GPT principale) inscrite sur le bloc
0 du disque - table de partition
MBR qui doit lui décrire exactement l'accès à la partition
BOOTCAMP en mode
MBR. Pour cela > une table dite «
Hybrid_MBR » (
HMBR), càd. hybridée dans son schéma
MBR de la description des partitions par la table
GPT principale (blocs n°
1 à
32), se trouve créée sur le bloc
0.
Or la limitation logique d'une table
MBR est de ne pas pouvoir gérer d'étendue de blocs logiques
au-delà de 2,2 To. Pour que la partition
BOOTCAMP soit nécessairement créée
en-deçà de cette limite sur le HDD de
3 To d'un
iMac Fusion Drive > le HDD se trouve
bi-partitionné en 2 partitions principales : une
disk1s2 de
2,2 To et une
dis1s4 de
800 Go. Entre ces 2 partitions > se trouve créée la
Recovery HD disk1s3 de
650 Mo. La logistique d'un
CoreStorage de type
Fusion Drive dans une telle distribution associant
3 partitions (
disk0s2 du SSD &
disk1s2 +
disk1s4 du HDD) --> est telle que c'est toujours exclusivement par re-partitionnement de la
première partition du HDD (celle de
2,2 To) que se trouve créée la partition
BOOTCAMP > régulièrement en-dessous de la
Recovery HD disk1s3 et juste avant la 3è bande du
CoreStorage de
800 Go. Ainsi, la partition
BOOTCAMP retaillée sur l'espace-disque de la partition qui va jusqu'à la limite de
2,2 To > ne se trouve jamais excéder la barre des
2,2 To qui devient non-gérable par une table
MRB.
En conséquence de ce dispositif où la partition
BOOTCAMP se trouve toujours imbriquée entre 2 partitions
CoreStorage sur le HDD --> elle est descriptible par la table
HMBR alternative du bloc
0 et son volume bootable par le
BIOS_émulé de l'
EFI.
----------
L'examen de la distribution des partitions montre qu'il n'existe
aucun espace libre hors partitions actuellement. La partition
BOOTCAMP de
1,1 To n'ayant pas été créée à sa place attendue sur le HDD (en
disk1s4) --> "mais_où_et_donc_or_ni_car" - càd. l'espace perdu > puisque le volume terminal
Macintosh HD du
Fusion Drive ne fait plus que
2 To au lieu de
3,1 To ?
Le tableau spécifique du
CoreStorage vend la mèche :
Bloc de code:
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 1C0AB82F-291A-4211-BF6D-5A5C10AB4790
=========================================================
Name: FUSIONDRIVE
Status: Online
Size: 3120587743232 B (3.1 7B)
Free Space: 1154447175680 B (1.2 TB)
|
+-< Physical Volume 73CF7198-DAF8-40F3-BA37-0E8B294536D7
| ----------------------------------------------------
| Index: 0
| Disk: disk0s2
| Status: Online
| Size: 120988852224 B (121.0 GB)
|
+-< Physical Volume CC3C76EF-E6DC-4D73-BB4D-8A8AF0D67498
| ----------------------------------------------------
| Index: 1
| Disk: disk1s2
| Status: Online
| Size: 2198162350080 B (2.2 TB)
|
+-< Physical Volume 38FADC61-8F11-4EEA-BFC7-0F014C089521
| ----------------------------------------------------
| Index: 2
| Disk: disk1s4
| Status: Online
| Size: 801436540928 B (801.4 GB)
|
+-> Logical Volume Family 54BF9A8F-3DEB-4ACD-82D8-BEFC299AC68A
----------------------------------------------------------
Encryption Type: None
|
+-> Logical Volume CDBCFC18-1BB4-4B84-B3EB-E86DF3AE2E35
---------------------------------------------------
Disk: disk2
Status: Online
Size (Total): 1959999963136 B (2.0 TB)
Revertible: No
LV Name: Macintosh HD
Volume Name: Macintosh HD
Content Hint: Apple_HFS
LVG Type: Fusion, Sparse
En examinant ce tableau > il apparaît que la taille du
Conteneur global "
Groupe de Volumes Logiques" est bien de
3,1 To > mais qu'un
espace libre de
1,1 To est annoncé à l'intérieur de ce
Conteneur.
Les 3 magasins de stockage physique
Physical Volumes importés dans ce
Conteneur ont bien les tailles attendues de :
121 Go +
2,2 To +
800 Go =
3,1 To. C'est le
Volume Logique exporté à partir de ces 3 magasins de stockage physique qui apparaît
rétréci à une taille de
2 To seulement.
Où existe alors l'espace libre ? - nécessairement sur le
magasin de stockage physique n°2 --> le
Physical Volume disk1s2 de
2,2 To > puisque comme expliqué précédemment > c'est cette partition exclusivement qui se trouve rétrécie pour créer un une nouvelle partition
BOOTCAMP.
La moitié de la partition
disk1s2 de
2,2 To > soit
1,1 To > se trouve donc
inemployée en tant que magasin de stockage physique par le
Logical Volume exporté.
Pourquoi cet incident ? --> c'est que, quand on demande un re-partitionnement en mode "
live" d'un dispositif
CoreStorage comme celui-ci > la réduction de taille implique :
a) le
magasin de stockage physique (
Physical Volume) identique à la
partition disk1s2 ici >
b) le
Logical Volume exporté à partir des 3 magasins de stockage >
c) le
système de fichiers JHFS+ qui monte le volume
Macintosh HD sur la couche virtuelle d'un seul tenant du
Logical Volume.
Cette triple opération logique ne s'effectue
jamais en concomitance (ou synchronisme) absolu : il y a toujours un
décalage chronologique entre le
mouvement de rétrécissement de la paire logique (
Volume Logique et
système de fichiers JHFS+ résident) et le
mouvement de rétrécissement du magasin physique (
Physical Volume de la partition).
Manifestement ici > une
stase est intervenue pile au moment où le
rétrécissement de la paire logique était accompli (réduction du
Logical Volume et du volume
Macintosh HD résident à
2 To) > et où le
rétrécissement du magasin de stockage physique Physical Volume de
2,2 To sur la partition
disk1s2 devait s'enclencher. Le résultat est une
fixation de ce décalage temporel : le
Volume Logique et son volume
Macintosh HD résident sont réduits à
2 To en tout > tandis que le
Physical Volume identique à la partition
disk1s2 est resté à sa taille initiale de
2,2 To.
----------
Ce genre d'incident logique est d'une "réparabilité" absolument pas garantie > si le décrochage des tailles volume logique / magasin physique est assimilé à une
erreur de taille interne du
CoreStorage.
Dans le «
Terminal» que tu trouves at:
Applications >
Utilitaires > tu peux passer la commande :
Bloc de code:
diskutil coreStorage resizeLV CDBCFC18-1BB4-4B84-B3EB-E86DF3AE2E35 0b
- et poster l'affichage retourné en copier-coller textuel dans une fenêtre de code et pas en photo ! -->
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é)
Cette commande ordonne un re-dimensionnement spécifique du
Logical Volume du
CoreStorage par récupération de tout l'espace libre disponible
en interne sur le magasin de stockage physique du
Physical Volume.
Si le message retourné est négatif et invite à une
réparation du disque global («
whole disk repair ») --> re-démarre en mode
Recovery comme tu l'avais fait > lance l'«
Utilitaire de Disque» et fais la totale des réparations possibles :
S.O.S. (ou "
Réparer le disque" - selon la version de l'OS) sur tout ce qui est sélectionnable : volume
Macintosh HD et disques physiques).
Cela opéré > re-démarre sur le volume
Macintosh HD > relance le «
Terminal» et repasse la commande :
Bloc de code:
diskutil coreStorage resizeLV CDBCFC18-1BB4-4B84-B3EB-E86DF3AE2E35 0b
pour voir si tu obtiens un effet différent.