À propos du
Fusion Drive d'usine (installé par Apple dans un
iMac), j'ai noté le point intéressant suivant :
- dans la généralité des cas de figures, on a affaire à un format
CoreStorage, dont le
Groupe de Volumes Logiques comporte 2
Physical Volumes (
Volumes Physiques émulant des disques durs importés sur des partitions dédiées) : un sur la partition
disk0s2 du SSD et un sur la partition
disk1s2 du HDD > avec une
Logical Volume Family unique (instance de pilotage) > et un
Logical Volume unique (
Volume Logique exporté à partir des 2
Volumes Physiques et recelant le système de fichiers
jhfs+ de l'OS).
- mais il y a toujours une distribution spécifique lorsque la taille du HDD est de
3 To. En effet, Apple est obligée de rendre possible, même dans cette configuration, l'installation de
Windows dans une partition
BOOTCAMP. Or ce type d'OS ne peut s'installer ni booter que par référence à la Table de Partition secondaire
MBR, qui existe sur le
secteur 0 ou secteur de boot du disque du HDD (bloc
0). Mais une table de Partition
MBR n'est pas capable de "mapper" (cartographier) de blocs sur un disque au-delà de la limite des
2,2 premiers To. Passée cette limite, tous les blocs excédentaires sont considérés comme non-existants.
Supposons que le
Fusion Drive d'usine ait pour
Physical Volume n°2 un disque virtuel occupant une partition
disk1s2 allant du quasi début du disque (moint l'en-tête
EFI de 209 Mo) à la fin => lors de la création d'une partition par l'«
Assistant BootCamp» de (supposons) 500 Go pour
Windows, cette partition viendrait occuper la position
disk0s4 (après la «
Recovery HD» de 650 Mo qui s'installe toujours sur le HDD en
disk1s3 en cas de
Fusion Drive) à partir de la ligne de départ de blocs
2,5 To => la Table de Partition
MBR ne pourrait pas tenir compte de cette partition, qui pour elle n'existe pas, passée la limite des
2,2 premiers To.
Alors, dans ce cas de figure d'un disque de
3 To, Apple repartitionne a priori l'espace du HDD en
2 partitions : une
disk1s2 de
2,2 To et une
disk1s4 de près de
800 Go. Entre les 2 prend place à l'install la
disk1s3 de 650 Mo de la «
Recovery HD». On a donc un
CoreStorage dont le
Groupe de Volumes Logiques incorpore
3 Physical Volumes,
1 sur le SSD (
disk0s2) et
2 sur le HDD (
disk1s2 &
disk1s4). Ce dispositif donne lieu au tableau suivant :
Bloc de code:
dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *121.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage 121.0 GB disk0s2
3: Apple_Boot Boot OS X 134.2 MB disk0s3
/dev/disk1
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *3.0 TB disk1
1: EFI EFI 209.7 MB disk1s1
2: Apple_CoreStorage 2.2 TB disk1s2
3: Apple_Boot Recovery HD 650.0 MB disk1s3
4: Apple_CoreStorage 801.4 GB disk1s4
5: Apple_Boot Boot OS X 134.2 MB disk1s5
/dev/disk2
#: TYPE NAME SIZE IDENTIFIER
0: Apple_HFS Macintosh HD *3.1 TB disk2
=> L'«
Assistant BootCamp», malgré le multi-partitionnement du HDD, accepte de créer une partition pour
Windows et de l'installer, parce que l'intégration des 2 partitions
disk1s2 et
disk1s4 à un même
CoreStorage exportant un
Volume Logique unique est validée en ce qui le concerne.
Dans ce contexte, la partition
BOOTCAMP va s'installer par repartitionnement de la
disk1s2 de
2,2 To => ainsi, quelle que soit la taille demandée, la nouvelle partition restera toujours sous la limite des
2,2 premiers To du disque et sera donc cartographiée par la Table de Partition
MBR. Elle se créera donc après la
disk1s3 de la «
Recovery HD» en prenant le numéro
disk1s4 et la 2è partition du
CoreStorage du HDD sera donc repoussée en
disk1s5, avec la partition du
booter rejetée en
disk1s6.
Compliqué, non ? Un bloc
Windows s'intercalera donc entre les deux partitions du
CoreStorage du HDD,
CoreStorage qui est globalement un tripode. Je me demande si ça n'a pas des effets sur le fonctionnement global d'un
Fusion Drive...
