les-z-amis
ninkasi devrait être « plus » prudent : ce n'est pas en vain qu'on en appelle aux services de
Jean ou de
mézigue
En ce qui concerne ma pomme : on se voit infliger une «
épistémologie » en sus (sous forme de
laïus en bonne et due forme).
Allez hop ! Quand un format
CoreStorage se trouve inscrit sur une partition de disque (comme ici la
disk0s2) > partition qui était déjà gérée par un
système de fichiers assurant la montée d'un volume sur ses blocs > système de fichiers résidant sur l'en-tête de la partition en question > alors il s'effectue un processus sournois dans les « bas-fonds » de la partition.
Comme l'
en-tête de la partition est déjà occupé par les fichiers du
système de fichiers JHFS+ > lesquels y sont ancrés à demeure > la seule localisation disponible pour les fichiers du
CoreStorage est alors la
queue de partition, toujours retaillable. C'est sur les blocs de fin de partition, donc, que les «
headers » (les en-têtes logiques) du dispositif
CoreStorage vont se trouver inscrits, en cas de partition déjà formatée.
Pour décrire les choses de manière imagée > ces «
headers » du
CoreStorage vont faire glisser des « couches logiques » entre le
système de fichiers JHFS+ en place (et le volume qu'il monte) > et le
container de blocs bruts de la partition. Pour résumer à l'essentiel :
2 couches logiques principales distribuées en superposition -->
- importé directement sur les blocs du container de la partition : un Physical Volume > qui re-configure les blocs de la partition comme constituant un Disque Dur Virtuel ;
- exporté secondairement à partir du Physical Volume : un Logical Volume > qui constitue une redondance logique du Physical Volume : un Disque Miroir Virtuel.
=> par suite de cet intercalement logique > le
système de fichiers JHFS+ n'est plus représenté comme
ancré sur l'en-tête brut de la partition > mais comme amarré à un «
dev node » (un nœud d'appareil) du
Logical Volume --> il est donc re-configuré comme une «
tierce instance » : il gère la montée en volume de l'espace logique du
Logical Volume > lequel est intrinsèquement un
espace-miroir du
Physical Volume ou disque dur émulé sur le container de la partition.
C'est ce dispositif inouï (créé à l'époque de l'OS «
Lion 10.7») qui permet seul le
mécanisme logique du chiffrement. Car il devient possible d'avoir un espace logique du
Physical Volume entièrement
chiffré en permanence > par rapport auquel le
Logical Volume constitue un
espace-miroir entièrement déchiffré (un
traducteur assurant en permanence la conversion d'un espace logique à l'autre). Aussi > le
système de fichiers résidant sur le
Logical Volume > gère en permanence des
fichiers lisibles > tandis que le mécanisme de traduction
Logical Volume <=> Physical Volume assure la conversion en
écritures chiffrées.
----------
Ce
laïus exposé > on comprend un peu mieux pourquoi, systématiquement, le
Logical Volume d'un
CoreStorage se trouve identifié comme un
device (appareil) de
second ordre : un
disk1 par rapport au
device disk0 du disque physique. Car si le
Physical Volume équivaut à la partition
disk0s2 redéfinie logiquement comme
Disque Dur Virtuel > le
Logical Volume, en tant que
Disque-Miroir exporté (redondance logique), constitue l'équivalent d'un «
second disque » logique : d'un disque « jumeau » > qui est donc naturellement identifié comme un
disk1 (ou un
disk17 dans la numérotation assez spéciale des
devices en cas de démarrage en mode
Recovery).
Si l'on veut alors lancer une opération de
réparation (à supposer bien sûr le
Logical Volume déverrouillé au préalable s'il y a
chiffrement «
FileVault» > et à supposer encore un démarrage sur un Système
indépendant de l'OS comme le
Recovey OS) --> alors il y a 2 niveaux d'opérations possibles :
-
a) une commande de la forme :
Bloc de code:
diskutil repairDisk /dev/disk17
va adresser spécifiquement le
Logical Volume du
CoreStorage en tant que
Disque-Miroir Redondant de second ordre --> c'est donc une vérification / réparation des
structures logiques intrinsèques du
CoreStorage qui va avoir lieu (à savoir : s'il y bien adéquation logique
Logical Volume exporté /
Physical Volume importé...) ;
- b) une commande de la forme :
Bloc de code:
diskutil repairVolume /dev/disk17
va non seulement adresser le
Logical Volume du
CoreStorage (pour vérifier / réparer le dispositif de
redondance Logical Volume / Physical Volume) > mais va adresser le
système de fichiers JHFS+ qui est l'hôte-résident du
Logical Volume --> il va donc y avoir en seconde instance une vérification d'intégrité classique du
système de fichiers (catalogue etc.) > càd. de sa capacité à gérer sans erreurs l'espace logique du
Logical Volume pour le monter en volume classique.
Dans le cas spécifique de
Quent27 > tel que montré par ses captures initiales d'affichages dans l'interface de l'«
Utilitaire de Disque» -->
- le code de sortie de la vérification du « système de stockage CoreStorage » est 0 = sans erreur ;
- le code de sortie de la vérification du « système de fichiers JHFS+ » est 8 = erreurs irréparables.
=>
en résumé : le «
magasinage du noyau » (dispositif logique du
CoreStorage) est
sans erreurs > c'est le
système de fichiers JHFS+ terminal qui est
corrompu. L'erreur paraît survenir sur la vérification du
fichier du catalogue (
catalogue B-tree) > qui permet l'adressage des fichiers de données.