Salut
macdonal.
Ton message concis aborde un des aspects les plus ésotériques (et les plus passionnants) du mode de partitionnement logique des disques physiques sous
OS X [autant te prévenir d'entrée que ton interlocuteur dans ce fil a pour trait distinctif ce qu'on pourrait nommer : la prose_spéculative] 
Le mode de partitionnement logique 'standard' des disques physiques sous
OS X (version Intel) est la
Table de partition GUID : c'est une 'couche' (layer) qui définit les 'contenants logiques' (containers) des systèmes de fichiers (filesystems) pouvant être écrits sur le disque selon un 'format' particulier (comme
HFS+ par exemple : Mac OS étendu journalisé). Ces 'contenants' sont les 'volumes' servant de 'périmètres logiques' aux systèmes de fichiers. Une des caractéristiques du mode de partitionnement qu'est la
Table de partition GUID consiste dans une
carte d'amorçage intiale dénommée :
EFI qui est prise en charge par l'
EFI_Firmware (ROM intel) au démarrage et qui constitue le volume logique de départ, invisible graphiquement et inmontable, mais conditionnant le montage des volumes logiques conséquents supportant les systèmes de fichiers, dont celui de l'OS sur le disque interne d'un Mac flanqué de sa partition de récupération.
Illustration :
Bloc de code:
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme xxx MB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD xxx GB disk0s2
3: Apple_Boot Recovery HD 1.0 GB disk0s3
Mais voici qu'Apple, à partir de l'OS «
Lion 10.7», a introduit de manière complètement 'silencieuse' un mode de partitionnement additionnel capable de se 'sur-ajouter' à la
Table de partition GUID : il s'agit donc d'une 'couche logique secondaire' (d'une espèce de 'sur-couche') capable de s'intercaler entre la 'couche primaire' de la
Table de partition GUID (préservée intacte) et certains systèmes de fichiers (filesystems). Cette structure inédite porte le nom de
Groupe de Volumes Logiques (Logical Volume Group) et est gérée par un
Gestionnaire dédié, introduit à partir de «
Lion» et inconnu sous l'OS antérieur «
Snow Léopard 10.6» : le
CoreStorage Manager.
Lorsque le
CoreStorage Manager est invoqué pour générer la couche logique intermédiaire d'un
Logical Volume Group, la couche primaire d'une
Table de partition GUID est toujours requise sur le disque concerné, et la couche secondaire en question est toujours supportée exclusivement par un des
Volumes (containers) suivants la carte d'amorçage
EFI et pré-définis de la
Table de partition GUID.
Illustration sur une clé USB :
Bloc de code:
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.1 GB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage 3.8 GB disk1s2
3: Apple_Boot Boot OS X 134.2 MB disk1s3
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS CLE 3.5 GB disk2
Comme on peut le voir, la couche
GUID constituant la structure logique primaire de la clé a été 'implémentée' localement par le
CoreStorage Manager qui a 'greffé' sur le volume logique de base (
disk1s2) une définition nouvelle de
Apple_CoreStorage tout en 'interpolant' un volume annexe nouveau : le
Apple_Boot Boot OS X 134.2 MB disk1s3 qui est la
Carte d'Amorçage spécifique du
Groupe de Volumes Logiques ; mais, bien plus, un nouvel 'étage' logique se trouve créé, sous l'identification de
/dev/disk2 : le
Apple_HFS CLE 3.5 GB disk2.
Décodage de cette structure abstruse : 'sur' le volume logique primaire
disk1s2 de la couche
GUID, le
CoreStorage Manager a 'plaqué' une définition logique nouvelle : celle de '
disque dur virtuel' (sic) - lequel '
disque dur virtuel' se trouve à son tour 'partitionné' logiquement comme supportant un
Volume Logique' = le
/dev/disk2 : Apple_HFS CLE 3.5 GB disk2 qui va servir de container à un système de fichier.
De manière plus détaillé, voici ce que cela donne :
Bloc de code:
CoreStorage logical volume groups (1 found)
|
+-- Logical Volume Group 44D27A6B-B10C-474A-A664-A388B8ECCD5E
=========================================================
Name: CLE
Status: Online
Size: 3799998464 B (3.8 GB)
Free Space: 16777216 B (16.8 MB)
|
+-< Physical Volume 0E586E73-F322-4174-8E4F-19CBD2674595
| ----------------------------------------------------
| Index: 0
| Disk: disk1s2
| Status: Online
| Size: 3799998464 B (3.8 GB)
|
+-> Logical Volume Family AD61AF12-312C-4A99-90D3-736BB333D69E
----------------------------------------------------------
Encryption Status: Unlocked
Encryption Type: None
Conversion Status: NoConversion
Conversion Direction: -none-
Has Encrypted Extents: No
Fully Secure: No
Passphrase Required: No
|
+-> Logical Volume 8427D678-C0C6-42A3-BDB0-17873172B57B
---------------------------------------------------
Disk: disk2
Status: Online
Size (Total): 3464450048 B (3.5 GB)
Conversion Progress: -none-
Revertible: Yes (no decryption required)
LV Name: CLE
Volume Name: CLE
Content Hint: Apple_HFS
Le
Groupe de Volumes Logiques (Logical Volume Group) est la désignation de la structure globale générée par le
CoreStorage Manager ; le
Physical Volume est la définition additionnelle que le
CoreStorage Manager a greffée sur le volume logique
/dev/disk1s2 de la
Table de partition GUID : celle de
Disque Physique Virtuel ; le
Logical Volume Family (Famille de volume logique) est une sorte d'annexe informative décrivant comment ce
Disque Physique Virtuel se trouve logiquement défini : s'il supporte ou non un volume crypté, s'il y a un mot-de-passe, etc. ; enfin, le
Logical Volume (Volume Logique) est le
/dev/disk2 : le container du système de fichiers, qui monte à partir du disque physique virtuel conformément aux paramètres du
Logical Volume Family.
Le
CoreStorage Manager s'invoque directement, en ligne de commande dans le «
Terminal», comme fonctionnalité seconde de la commande
diskutil qui invoque le
binaire_unix du même nom : à savoir, la fonction
coreStorage. Mais il s'invoque indirectement, en mode graphique, dans la GUI de l'«
Utilitaire de Disque», lorsqu'on demande la création d'un
Volume Chiffré décryptable grâce à un mot-de-passe ; et tout aussi indirectement, lorsque dans les
Préférences Système, on active la protection
FileVault-2 qui revient à imposer au volume de l'OS (
/dev/disk0s2) un chiffrement. En dernier lieu, le procédé du
Fusion_Drive invoque lui aussi les services du même
CoreStorage Manager.
Dans tous ces cas de figure, ce sont les services du
CoreStorage Manager qui sont invoquées, avec cette différence qu'en ligne de commande, il est possible de créer un
Groupe de Volumes Logiques non chiffré greffé sur un volume partitulier de la
Table de partition GUID d'un disque physique ; alors que, en mode graphique, le
CoreStorage Manager n'est invoqué qu'en liaison avec une option de
chiffrement. La différence, enfin, entre
FileVault-2 et l'«
Utilitaire de Disque» se résumant pour l'essentiel à l'identité du disque crypté et au mode de son déchiffrement requis des services du
CoreStorage Manager : volume de l'OS + déchiffrement automatique lié au renseignement du mot-de-passe utilisateur à l'écran d'ouverture de session (
FileVault-2) vs volume indépendant + déchiffrement requis à la commande volontaire de montage (
Utilitaire de Disque).
Ces considérations abstruses (©
macomaniac ) répondent peut-ête à certaines de tes interrogations.
