« Spéculation provoquée autant que provocante »
Donc je dois en déduire que ce n'est pas indispensable d'avoir un cs logical volume groups ? (C'est pour ma culture lol)
Pareil que
Jean-Claude (i.e.
Invité)
☟
De manière classique, le disque physique du Mac (constitué d'un alignement de cellules matérielles porteuses chacune d'un
bit d'écriture :
0 vs
1) est géré logiquement par un dispositif qui fait correspondre chaque alignement de 8
bits à un
byte, chaque alignement de 512
bytes à un
block ou
cluster, et tel alignement de tant de
blocks à une
partition logique ou
secteur. Un
système de fichiers HFS+J (
Mac OS étendu journalisé) gère l'alignement de
blocks d'une
partition en un dispositif montable en
volume.
Un
CoreStorage introduit une complexification dans ce dispositif standard : l'alignement des
blocks d'une
partition-cible est interprété dans
2 systèmes de fichiers distincts équivalant à
2 volumes superposés : un
système de fichiers primaire (dit «
Volume Physique ») et un
système de fichiers secondaire (dit «
Volume Logique »). Le passage de l'un à l'autre est géré par une instance intercalaire de «
conversion » dite «
Famille de Volumes Logiques ».
Ce "décalage" de
systèmes de fichiers (
physique vs
logique) permet d'instaurer un processus de
cryptage intercalaire, tel que les écritures
lisibles affectées aux
blocks du
Volume Logique puissent être
converties à la volée (d'après un algorithme) en écritures
illisibles affectées au
blocks du
Volume Physique. C'est la
Famille de Volumes Logiques qui assure cette fonction de
truchement, en gérant un
logiciel de conversion et en donnant le feu vert à un
pilote de montage du
Volume Logique à partir du
Volume Physique.
Un
3è système de fichiers (eh oui ! jamais 2 sans 3...) intervient tout au sommet de cette pile d'instances du
CoreStorage, qui est le
filesystem HFS+J classique recelant les données de l'OS installé sur la
partition. Ainsi, au lieu d'être directement «
accollé » comme gestionnaire de
blocks à la
partition-support, il se trouve «
écarté » d'elle par
2 systèmes de fichiers intercalaires : le
système de fichiers primaire du
Volume Physique et le
système de fichiers secondaire du
Volume Logique - dualité qui implique un procédé de
conversion géré par l'instance de
truchement de la
Famille de Volumes Logiques.
C'est pas triste, non ? Le plus drôle dans l'histoire est que, les mêmes Anglo-Saxons dont l'empirisme logique rejette dans le domaine philosophique la
métaphysique classique en lui reprochant d'avoir «
indûment multiplié les êtres de discours» (accusation classique de
Guillaume d'Occam à l'endroit de la «
Summa Theologica» de
St Thomas d'Aquin) ; n'hésitent aucunement dans le domaine
informatique à multiplier les entités logiques - comme si ces dernières, d'être opératoires «
en pratique », s'en trouvaient justifiées dans leur prolixité, alors que les premières, d'être opératoires seulement «
en théorie », s'en trouveraient disqualifiées ! Or, je ne vois pas en quoi l'
informatique serait moins un «
artefact » que la «
métaphysique » sous ce rapport...
--------------------
Ce petit exposé, aussi abstrus que lacunaire, tente nonobstant d'avoir valeur démonstrative. C'est pour l'OS «
Lion 10.7» que les ingénieurs de la ont inventé le
CoreStorage, ce spécifiquement afin de remplacer le procédé de cryptage de «
FileVault-1» qui encapsulait le dossier de compte d'un utilisateur individuel dans une image-disque cryptée de type
.sparseimage, par le procédé de cryptage «
FileVault-2» qui chiffre désormais le
Volume Logique complet contenant le
filesystem HFS+J de l'OS. Il paraît clair que le
CoreStorage est alors un procédé dérivé de ce qui permettait le cryptage antérieur : à savoir l'existence d'un disque dur émulé (ou
Volume Physique) constitué par l'image-disque
.sparseimage, à partir duquel monte un volume virtuel (ou
Volume Logique), càd. une
dualité de systèmes de fichiers entre lesquels peut opérer une
conversion de cryptage.
Le potentiel de ce dispositif
CoreStorage s'est encore avéré par le fait qu'il est capable de solidariser 2
Volumes Physiques (un importé sur une partition de SSD et un autre sur une partition de HDD) pour exporter une
Volume Logique de synthèse unique dans le procédé du
Fusion Drive. Il s'agit en apparence de la reprise du procédé associatif déjà connu sous le nom de l'
AppleRAID, mais qui y apporte la spécificité du
CoreStorage que j'ai tenté de décrire en premier : à savoir le
parallélisme de 2
systèmes de fichiers (
Volume Physique <=>
Volume Logique) entre lesquelles opère une
conversion gérée par la
Famille de Volumes Logiques. En effet, dans un
Fusion Drive, la
conversion n'opère pas en mode
chiffrement (lequel peut lui être surajouté d'ailleurs), mais en mode
optimisation (redirection des écritures les plus fréquemment atteintes en lecture aux
blocks du SSD et rétrocession des écritures les moins fréquemment atteintes en lecture aux
blocks du HDD).
Si l'on me suit dans cette argumentation volontiers aussi byzantine que la nature de son objet informatique : on conviendra que l'instruction implémentée dans les installateurs de «
Yosemite» et d'«
El Capitan» de greffer un
CoreStorage sur la partition d'install de ces OS, alors même que l'utilisateur n'a pas requis de
chiffrement «
FileVault-2» et/ou pas instauré de
Fusion Drive, relève d'un pur fonctionnement «
à vide » du dispositif
CoreStorage. Fonctionnement «
à vide », mais néanmoins inducteur d'effets collatéraux me le figuré-je.
En effet, instaurer un
parallélisme de
systèmes de fichiers primaire (
Volume Physique) <=>
secondaire (
Volume Logique) avec intercession gérée par une
Famille de Volumes Logiques, introduit une séquence de «
traduction à vide » (ou de « conversion pour du beurre ») entre les 2
systèmes de fichiers : je conjecture que c'est là une médiation logique nuisible à l'immédiateté des opérations de lecture / écriture, et par suite introduisant une latence. Latence forcément aggravée dans le cas d'un
chiffrement, car un cryptage / décryptage à la volée entres les 2 systèmes de fichiers est forcément chronophage. J'en conjecturerais autant pour ce qui est du
Fusion Drive, dont le procédé d'
optimisation proclamé facteur d'augmentation de vitesse implique nonobstant le même procédé de conversion entre les 2 systèmes de fichiers :
primaire (des 2
Volumes Physiques) et
secondaire (du
Volume Logique unique), càd. un facteur directement en contradiction logique de l'effet proclamé.
Je conjecturerais donc qu'un OS installé dans un
système de fichiers HFS+J classique sera marginalement plus rapide que le même installé dans un
système de fichiers HFS+J séparé du disque physique par une
dualité de
systèmes de fichiers CoreStorage (
Volume Physique <=>
Volume Logique) entre lesquels opèrera une «
traduction à vide ». Notablement plus rapide qu'un OS contenu dans un
Volume Logique chiffré. Encore plus rapide qu'un OS contenu dans un
Volume Logique Fusion Drive chiffré. En supposant qu'on ait affaire à des SSD chaque fois. La vitesse d'un SSD ne peut donc qu'être ralentie par l'existence d'un
CoreStorage, de part l'intervention d'un protocole de traduction (qu'il opère «
à vide », en mode «
cryptage » ou en mode «
optimisation »).
La multiplication des «
êtres logiques » par le procédé du
CoreStorage introduit de surcroît un facteur d'
opacité dans la gestion d'un disque (car l'importation sur une partition du disque physique d'un
Volume Physique émulant un disque dur soustrait le disque physique à la manipulation directe et donne l'impression qu'il est «
verrouillé »). Et cette complication logique n'est pas sans amener un facteur de fragilité : la paire
Famille de Volumes Logiques / Volume Logique saute plus souvent qu'à son tour en ne laissant qu'un
Volume Physique dont le système de fichiers orphelin est désormais intraduisible (comme le cas de
7sume en a attesté).
--------------------