Je vois que pour
Yoskiz > comme pour
St Thomas (pas
d'Aquin - qui était d'une autre envergure que le douteur de l'Antiquité) > la
théorie ne suffit jamais > il faut toujours pouvoir toucher du doigt en
pratique la "chose même" («
the proof of the pudding is in the eating » : tant que je ne mastique pas le pudding > je ne peux pas croire que ce soit aussi naze - et pourtant j'étais théoriquement prévenu. Et le Cheddar, c'est encore pire à l'usage - et pourtant j'étais prévenu).
Je me suis donc livré à une expérience : j'ai connecté avec un câble USB un Hitachi rotatif à 5400 tr/mn de 500 Go et un SSD Crucial de 500 Go en Thunderbolt. Dans mes nombreux disques attachés au Système > ils étaient respectivement
disk14 (SSD) et
disk16 (HDD).
Par une paire de commandes :
Bloc de code:
diskutil coreStorage createLVG Fusion disk14s2 disk16s2
diskutil coreStorage createLV xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx jhfs+ FusionDrive 100%
je crée un
CoreStorage Fusion Drive associant les 2 partitions principales et exportant un
Volume Logique intitulé
FusionDrive (vide).
Je déclenche le dmg d'une
Install macOS 10.13 Beta.app > choisis le volume
FusionDrive comme destination > trouve une case cochable : "
Convertir à l'APFS" > tout est accepté et à la fin j'ouvre une session dans mon volume
FusionDrive recelant un Système
High Sierra APFS.
Qu'en est-il de la distribution logique ? --> celle-ci d'après la commande diskutil list :
Bloc de code:
/dev/disk14 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *525.1 GB disk14
1: EFI EFI 209.7 MB disk14s1
2: Apple_APFS Container disk17 524.8 GB disk14s2
/dev/disk16 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.1 GB disk16
1: EFI EFI 209.7 MB disk16s1
2: Apple_APFS Container disk17 499.2 GB disk16s2
3: Apple_Boot Recovery HD 650.0 MB disk16s3
/dev/disk17 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +1.0 TB disk17
Physical Stores disk14s2, disk16s2
1: APFS Volume FusionDrive 8.7 GB disk17s1
2: APFS Volume Preboot 18.6 MB disk17s2
3: APFS Volume Recovery 518.9 MB disk17s3
4: APFS Volume VM 8.6 GB disk17s4
où l'on voit parfaitement que la partition
CoreStorage disk14s2 du SSD est devenu un
Physical Store APFS > la partition
CoreStorage disk16s2 du HDD un autre
Physical Store APFS > et qu'un
Container APFS disk17 se trouve créé qui
importe ces
2 Physical Stores et
exporte 4
Volumes APFS : le
FusionDrive de
macOS > le
Preboot du «
booter » de ce volume > le
Recovery de l'OS de secours > le
VM (
Virtual Memory de la
sleepimage).
L'architecture
CoreStorage Fusion Drive a donc bien été
convertie in extenso à l'architecture
APFS Fusion Style.
Ce qu'il fallait prouver.
C'est donc prouvé.
Oui mais (argue
St Thomas - pas
d'Aquin) que se passe-t-il si j'ai un
iMac avec 2 disques (SSD & HDD) dont j'ai cassé le
CoreStorage Fusion Drive et si je voulais créer de toutes pièces un
APFS Fusion Style ? -
aucune difficulté : tout passe par le «
Terminal» - comme c'était déjà le cas pour un
CoreStorage Fusion Drive "maison" (et pas "usine").
Donc je démarre sur un volume
APFS indépendant de mon
Fusion Style et par la commande :
Bloc de code:
diskutil ap deleteContainer disk17
je détruis d'abord l'
APFS Fusion Style qui associait les 2 disques (SSD et HDD). Les 2 disques se trouvent désolidarisés > avec un volume
Untitled au format
JHFS+ classique sur chaque partition principale.
Je passe alors la commande :
Bloc de code:
diskutil ap createContainer -main /dev/disk14s2 -secondary /dev/disk16s2
et j'obtiens le retour :
Bloc de code:
Creating container with disk14s2 disk16s2
Started APFS operation on disk14s2 Untitled
Creating a new empty APFS Container
Unmounting Volumes
Switching disk14s2 to APFS
Switching disk16s2 to APFS
Creating APFS Container
FusionLC autodetect: regular Fusion
Created new APFS Container disk17
Disk from APFS operation: disk17
Finished APFS operation on disk14s2 Untitled
montrant qu'un
Container APFS qui
importe 2 Physical Stores a été créé avec l'identifiant de (pseudo)-device :
disk17.
Je passe la commande :
Bloc de code:
diskutil ap addVolume disk17 apfs FusionDrive
et j'obtiens le retour :
Bloc de code:
Exporting new unencrypted APFS Volume "FUSIONDRIVE" from APFS Container Reference disk17
Started APFS operation on disk17
Preparing to add APFS Volume to APFS Container disk17
Creating APFS Volume
Created new APFS Volume disk17s1
Mounting APFS Volume
Setting volume permissions
Disk from APFS operation: disk17s1
Finished APFS operation on disk17
montrant qu'un
Volume APFS intitulé
FusionDrive a bien été
exporté du
Container.
Je n'ai plus si je le souhaite qu'à installer «
High Sierra» dans ce volume.
J'en profite pour donner un autre extrait significatif du
man de
diskutil "
High Sierra" :
Bloc de code:
createContainer [-main] device [-secondary] [device]
Create an empty APFS Container. The device(s)
specified become APFS Physical Stores.
If you specify more than one device, a Fusion Con-
tainer is created, with the performance roles
assigned automatically (preferred) unless you use
the -main and -secondary options, in which case,
the secondary disk is assumed by APFS's performance
algorithms to be on "slower" hardware. The sec-
ondary disk is usually not solid solid state, is
usually larger, and is used to store associated
"auxiliary" data such as any Windows partition(s)
for Boot Camp Assistant.
You may then add APFS Volumes with the diskutil
apfs addVolume verb.
Ownership of the affected disks is required.
Les 2 options
[-main] device [-secondary] [device] prouvent indubitablement que l'option
Fusion Style est
théoriquement supportée, car
-main désigne l'appareil de stockage
prioritaire ou
principal = SSD et
-secondary l'appareil de stockage
secondaire ou
d'appoint = HDD.
Traduction du second § :
[Si vous spécifiez
plus d'un appareil de stockage, un «
Container Fusion » est créé, avec les
rôles efficaces assignés automatiquement (préférés) à moins que vous n'utilisiez les options
-main et
-secondary, auquel cas, le "
disque secondaire" est assumé par les
algorithmes de performance APFS comme étant
l'appareil physique le plus lent. Ce
disque secondaire est habituellement un
disque non SSD > est habituellement
de plus vaste capacité > et est utilisé pour
stocker des données associées de type "auxiliaire" comme n'importe quelle partition Windows pour l'«
Assistant BootCamp».
Vous pouvez alors ajouter des
Volumes APFS avec le verbe
addVolume de la commande
diskutil apfs.]
=> je pourrais indéfiniment gloser sur ces stipulations, mais il me paraît non seulement «
prouvé pratiquement » par mes expérimentations > mais aussi «
démontré théoriquement » par les principes du
man de
diskutil => que l'
APFS supporte entièrement un
équivalent exact du
Fusion Drive CoreStorage = un
Fusion Style APFS. Ce
Fusion Style est généré soit par
conversion automatique d'un
Fusion Drive CoreStorage pré-existant en cas de passage à l'
APFS ; soit par
création ex nihilo de l'utilisateur dans le «
Terminal» (création ex nihilo qui sera le mode d'installation logicielle d'usine des nouveaux
iMac).
- tout le reste est légende urbaine.
La situation n'était déjà pas très claire, et leur documentation est incroyablement légère pour un truc si important, et ils ont ajouté une nouvelle couche de confusion.
