Je reviens dans ce fil pour une petite étude rétrospective, car le cas évoqué ici présentait une singularité remarquable.
Lorsque l'«
Assistant BootCamp» a créé une partition dédiée à
Windows et que, pour une raison quelconque, l'utilisateur souhaite la supprimer et réallouer son espace-disque à la partition de l'OS, alors l'«
Assistant BootCamp» permet classiquement cette opération avec succès. Mais, depuis que les installateurs d'
OS X («
Yosemite» d'abord, puis «
El Capitan») s'attachent à greffer un format
CoreStorage sur la partition de l'OS ; voire lorsque c'est l'utilisateur lui-même qui a suscité la présence d'un tel format en activant le chiffrement «
FileVault» qui le requiert - alors il arrive plus souvent que souhaité que l'opération classique de réallocation de l'espace-disque de la partition
Windows à celle de l'OS échoue.
En quoi consiste logiquement parlant cette opération de ré-allocation de l'espace de la partition
Windows à celle de l'OS ? Tel que je me le figure, en l'enchaînement des 2 commandes suivantes (nous supposerons ici que la partition de l'OS est
/dev/disk0s2 et celle créée pour
Windows /dev/disk0s4, la partition de récupération «
Recovery HD» occupant régulièrement la position intercalaire
/dev/disk0s3) =>
1ère commande :
Bloc de code:
diskutil eraseVolume free NULL /dev/disk0s4
qui supprime le système de fichiers gestionnaire de la partition
disk0s4 au format
ntfs et par là même supprime l'enregistrement de l'espace des blocs correspondant dans une partition logique de la table
GPT.
2è commande :
Bloc de code:
diskutil cs resizeStack lvUUID 0b
qui ordonne le re-dimensionnement de l'enveloppe globale du
Groupe de Volumes Logiques du
CoreStorage (
Stack = "empilement de couches logiques") en mentionnant comme cible l'
UUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx du
Volume Logique du
CoreStorage et l'option
0b = "
zero byte" équivalant en abrégé à dire : "
récupérer l'espace libre situé en-dessous de la limite du CoreStorage jusqu'à épuisement du dernier byte, ce sans obstacle d'une Apple_Boot_Recovery_HD éventuellement intercalée dont l'emplacement sera mis à jour sur les blocs".
--------------------
Faisons un effort analytique de plus : en quoi consiste exactement l'opération ordonnée par le verbe "
resizeStack" (redimensionner l'empilement des couches logiques du
CoreStorage) ? Le détail de cette opération est documentée dans un véritable « morceau de bravoure » dans le
man de
diskutil, au
§ suivant relatif au verbe
resizeStack :
Bloc de code:
This is done by making a change to the size of a logical volume (LV), after or before which
(one of its) physical volume(s) (PV) also changes its size accordingly. The (HFS) file system
"on top of" the LV and the disk partition "below" the PV, as well as the location of the PV's
associated booter partition, are automatically adjusted.
Et après on prétend que la « rhétorique » manque de rigueur, tandis que la « logique » en aurait le monopole ! Voici la traduction en bon Français de ce chef_d'œuvre :
«
Le re-dimensionnement est opéré par la réalisation d'un changement de taille du Volume Logique (LV), opération après ou avant laquelle le (ou les) Volume(s) Physique(s) (PV) change(nt) également de taille en corrélation. Le système de fichiers (HFS) ancré "tout en haut" du Volume Logique et la partition GPT du disque "en-dessous" du Volume Physique, aussi bien que l'emplacement de la partition du booter (driver Boot OS X conditionnant le montage du Volume Logique à partir du Volume Physique), se trouvent automatiquement ajustés ».
Ad-mi-ra-ble !
Donc : le
Volume Physique du
CoreStorage est dilaté pour récupérer l'espace libre ; le
Volume Logique du
CoreStorage est lui aussi dilaté pour récupérer cet espace libre ; le système de fichiers
JHFS+ d'
OS X, ancré sur le
Volume Logique à un
dev node se trouve à son tour étiré pour couvrir l'espace de blocs élargi ; la partition
GUID enfin qui sert de "sol" de sustentation au
Volume Physique se trouve redimensionnée à la mesure de l'espace libre ajouté dans le fichier
GPT qui gère le partitionnement
GUID.
--------------------
Ce qui m'intéresse plus particulièrement en rapport avec le cas de ce fil est le point suivant : l'étonnante incertitude en ce qui concerne la « temporalisation » des opérations : dilatation du
Volume Physique / dilatatation du
Volume Logique. L'opération sur le
Volume Logique intervient-elle
après ou
avant celle affectant le
Volume Physique ?
Je ne possède pas de privilège d'observateur (non plus que d'ingénieur) qui me permettrait de percevoir (ou de concevoir) la succession de ces événements. Mais je suis du moins sûr grâce au raisonnement de ce qui suit : manifestement, en ce qui concerne le
CoreStorage de
Nagarian, il y a eu dilatation du
Volume Physique avant toutes choses. Il avait une taille de
204 Go => il a été dilaté à
250 Go. Mais, lorsque l'opération de dilatation du
Volume Logique aurait dû intervenir
après afin de le faire correspondre en taille au
Volume Physique, il y a eu blocage des opérations et le
Volume Logique est resté fixé sa taille antérieure de
204 Go. Par suite, la partition
GPT servant de base de sustentation au
Volume Physique aggrandi a bien été dilatée corrélativement à
250 Go ; par contre, le système de fichiers
JHFS+ d'
OS X est resté gestionnaire de
204 Go de blocs en correspondance avec la taille du
Volume Logique lui servant d'espace d'ancrage.
L'espace de blocs libres qui existait préalablement tout en queue de disque (localisation de l'ancienne partition
/dev/disk0s4) a bien été alloué, dans le
CoreStorage, au disque dur émulé du
Volume Physique, tandis que la «
Recovery HD» se trouvait déplacée sur les 650 derniers Mo de blocs du disque. Mais le
Volume Logique n'a pas bénéficié d'un ajustement corrélatif à la dilatation du
Volume Physique. Et aucune commande ultérieure de réajustement n'a pu débloquer cette situation.
--------------------
J'oserais conjecturer qu'un
CoreStorage Chiffré n'est pas le meilleur dispositif d'accueil pour un pareil redimensionnement logique. Je me figure, en effet, que c'est le disque virtuel du
Volume Physique qui est chiffré bloc à bloc, le
Volume Logique montant à partir de lui en tant qu'espace-disque déchiffré grâce à un mécanisme de conversion à la volée (de la
Famille de Volumes Logiques). Lorsque de l'espace libre a été aggloméré au disque du
Volume Physique Chiffré, encore eût-il fallu que ces blocs exécendaires soient intégrés au chiffrement (quand bien même porteurs de zéro écritures), afin qu'une dilatation corrélative du
Volume Logique déploie un espace correspondant de blocs déchiffrables. Intégration au chiffrement de l'espace-blocs additionnel du
Volume Physique qui n'est pas intervenu. Impliquant (conjecturé-je) une impossibilité de générer une dilatation corrélative du
Volume Logique à un espace de blocs qui aurait été déconnecté d'une correspondance à des homologues chiffrés.
Ce qui apporte de l'eau au moulin de cette conjecture, c'est l'expérience que j'ai faite sur une clé USB, où j'ai construit artificiellement un analogue du dispositif logique de
Nagarian -
moins le Chiffrement du
CoreStorage. Je me suis ainsi donné un
CoreStorage dans lequel le
Volume Physique occupait la totalité de l'espace disposible (15 Go) tandis que le
Volume Logique se trouvait réduit à 12 Go. En l'absence d'un chiffrement de ce
CoreStorage, l'opération commandée par :
Bloc de code:
diskutil cs resizeLV lvUUID 0b
a été honorée sans difficultés et le
Volume Logique dilaté à 15 Go en correspondance à la taille du
Volume Physique. Pour me résumer de manière imagée : «
FileVault» et l'«
Assistant BootCamp» paraissent devoir faire aussi mauvais ménage que chiens et chats...
--------------------
)
