stesz
Si tu provoques mon esprit d'impertinence - un dimanche matin, on peut s'attendre à tout
La version apocryphe d'une phrase de Hamlet déclare : « Il y a plus de choses dans le Core Storage, stesz, que n'en rêve ta philosophie ». Autant dire : le CoreStorage défie la raison et il faut appeler l'imagination à la rescousse pour s'en figurer quelque chose.
Alors figure-toi
une Caverne le cas le plus simple : un Mac à un seul disque. Une table de partition
GUID, résidant sur l'en-tête de ce disque, décrit logiquement l'espace du disque, en assignant les 209 premiers Mo de blocs du disque à une partition n°1 (
EFI_System_Partition) et tout le reste à une partition n°2 intitulée
Macintosh HD. Une partition est ainsi un secteur du disque, commençant au bloc tant et finissant au bloc tant, possédant la caractéristique suivante : un système de fichiers, ancré sur les blocs de départ de la partition, joue la fonction d'interprète du reste de la partition, en traduisant les blocs bruts sous la forme d'un répertoire de fichiers : ce qu'on appelle un volume. Au démarrage du Mac, le Programme Interne (
EFI) de la Carte-Mère accède au disque par le secteur d'amorçage constitué par la table de partition > active le système de fichiers d'en-tête de la partition
Macintosh HD > ce qui a pour effet le montage sous forme de volume de l'espace de la partition > suite à quoi le démarreur de l'OS inscrit dans cet espace peut être exécuté > et le Système Logique démarré.
Que se passe-t-il quand un
CoreStorage vient s'inscrire sur une telle partition
Macintosh HD ? Les fichiers du
CoreStorage viennent remplacer sur l'en-tête de la partition ceux du système de fichiers
JHFS+ déjà en place, lesquels sont "repoussés latéralement" pour laisser de la place (si je puis dire). Sur cet en-tête libéré de la partition, le
CoreStorage va imposer une re-description de l'espace de blocs de la partition qui n'a plus rien à voir avec la description basique du système de fichiers
JHFS+.
L'espace de blocs de la partition va se trouver décrit comme équivalent d'un
disque dur virtuel : un
Physical Volume. Avec la propriété de pouvoir exporter un
double logique (une redondance) de lui-même : un
Logical Volume, les échanges entre les 2 disques virtuels étant assurés par une instance de traduction dite :
Logical Volume Family. Et c'est sur l'en-tête de ce double logique : le
Logical Volume, que le système de fichiers
JHFS+ qui était en place sur l'en-tête de la partition > se trouve désormais amarré. Il se trouve donc accroché à un point d'ancrage qui n'est plus l'en-tête immédiat de la partition, puisque ce sont les
headers (en-têtes descriptifs) du
CoreStorage qui ont pris la place > mais sur l'en-tête d'une « image-disque virtuelle » de second ordre : le double logique du
Physical Volume, qu'est le
Logical Volume.
Ce dispositif logique sans équivalent en informatique et qui me semble un éclatant témoignage de la capacité de «
think different » des ingénieurs de la (en quoi je m'inscris en faux face aux dénigrements des esprits rechignés) comporte une conséquence : l'impossibilité pour le Programme Interne (
EFI) du Mac d'activer en mode classique le système de fichiers
JHFS+ de la partition pour déterminer le montage du volume > puisque là où classiquement réside le système de fichiers activable (l'en-tête de la partition) s'inscrivent les
headers du
CoreStorage qui décrivent au premier degré un disque dur virtuel sans système de fichiers : le
Physical Volume.
Il faut donc aménager une
instance déclencheuse capable de déployer le double logique du
Physical Volume : le
Logical Volume > à partir de quoi le système de fichiers ancré sur l'en-tête de cette « image-disque» virtuelle sera activable comme dans le dispositif classique où il réside d'entrée sur l'en-tête de la partition. Cette instance déclencheuse est une micro-partition créée au «
pied » de la partition
CoreStorage et assignée au rôle de «
booter » : déployeur du dispositif logique du
CoreStorage. Cette partition «
booter » comporte un système de fichiers (de type
Apple_Boot) permettant à l'
EFI d'accéder aux fichiers-démarreurs du
CoreStorage et de les exécuter, afin de déclencher la (ré)génération du
Volume Logique à partir du
Volume Physique > et l'accès au système de fichiers
JHFS+ ancré sur son
dev node d'en-tête.
Ainsi, l'accès à une partition
CoreStorage s'opère par le «
pied » (la partition «
booter » secondaire) > pas par l'
en-tête (puisque le système de fichiers
JHFS+ a été remplacé par les
headers du
CoreStorage).
Mais que se passe-t-il lorsqu'on installe dans le volume terminal géré par le système de fichiers
JHFS+ un
OS X de type «
Lion » (pour désigner - à tout seigneur tout honneur - le paradigme inventeur - c'est-à-dire : l'« essence logique ») ? => une partition de secours dite
Recovery HD doit nécessairement s'installer dans une partition immédiatement au «
pied » de la partition de l'OS. Il y a donc a priori
conflit d'emplacement (le «
pied » de la partition-Système) - dès lors qu'un format
CoreStorage se trouve inscrit sur la partition-Système : car là où doit nécessairement se situer le «
booter » du
CoreStorage (la partition déployeuse :
Boot OS X) > doit nécessairement se situer la partition de secours
Recovery HD.
Les ingénieurs de la ont manifestement résolu ce conflit en recourant à un analogue de la fonction «
vicariante » dans les phénomènes de la vie : la capacité d'un autre organe à exercer les fonctions d'un organe neutralisé. Ainsi, je peux respirer par la bouche si j'ai le nez bouché. Eh bien ! La partition de secours
Recovery HD se trouve, en
mode vicariant, affectée à jouer le rôle de «
booter » du
CoreStorage dès qu'un Système
OS X de type «
Lion » est installé dans le volume de la partition du dessus. Le système de fichiers de cette partition
Recovery HD est du même type (=
Apple_Boot) > le dossier de fichiers exécutables (=
com.apple.Boot.P) du «
booter »
Boot OS X se trouve déplacé dans le volume de la
Recovery HD > et ainsi la
Recovery HD devient, en
première instance exécutable, le nouveau «
booter » du dispositif
CoreStorage. C'est donc par le «
pied » encore (ici la
Recovery HD) que le
CoreStorage de la partition supérieure va se trouver déployé > son système de fichiers activé > et le volume terminal monté.
Je mets un terme ici à ces explorations (du «
Ciel » et de la «
Terre » du
CoreStorage - pour m'en rapporter à l'original de la phrase de
Hamlet) et j'en reviens à ton cas de figure plus complexe : dans un
Fusion Drive, en résumé, il y a 2 disques > 2 partitions de base > 2
Physical Volumes > il faut donc nécessairement 2 «
booters » pour déployer les 2
Physical Volumes et déterminer l'
exportation du
Volume Logique en facteur commun. La partition
CoreStorage du SDD a toujours un «
pied »
régulier : un «
booter »
Boot OS X > la partition
CoreStorage du HDD a toujours un «
pied »
vicariant : un «
booter »
Recovery HD.
Dans ton cas de figure encore, lorsqu'après recréation de la paire logique :
Famille de Volumes Logiques >
Volume Logique qui avait "sauté" => je t'ai passé une commande de
suppression de la
Recovery HD disk1s3 du HDD > cette initiative irréfléchie constituait un
impair majeur - pour l'exacte raison que j'ai tenté d'argumenter ci-dessus : cette
Recovery HD n'était pas qu'une simple partition de secours > située en «
pied » de
CoreStorage > elle assurait la fonction «
vicariante » de
première instance exécutable de «
booter » du
CoreStorage : càd. de
déployeur du disque dur virtuel de la partition
disk1s2 du HDD. La supprimer > c'était invalider la moitié du dispositif du
CoreStorage du
Fusion Drive. Comme tu as pu le constater > le dispositif s'est mis aussitôt à "boîter" : il était impossible de re-dimensionner le volume de synthèse > il était impossible aussi d'y installer un OS car... l'espace du volume terminal n'était plus reconnu comme démarrable par l'
EFI.
C'était donc le « booter » ! - en l'occurence : la Recovery HD disk1s3 du HDD exerçant la fonction vicariante de « 2è booter »...
