M
Membre supprimé 1060554
Invité
Merci de ton retour instructif, marenostrum.
Le dispositif CoreStorage Fusion Drive a bien été converti en un dispositif APFS "Fusion Style". Quand je dis : "dispositif APFS" > je désigne le fait suivant --> l'APFS n'est pas qu'un système de fichiers nouveau (remplaçant du JHFS+) > c'est aussi un système de stockage nouveau (remplaçant du CoreStorage). C'est ce 2è point que je vise ici.
Je note donc que tu n'as plus sur tes 2 disques que des partitions converties à des Physical Stores ("magasins physiques") APFS = disk0s2 et disk1s2 au lieu de partitions converties à des Physical Volumes CoreStorage.
Tu noteras que ces partitions-converties sont ainsi labellisées :
ce qui veut dire qu'elles sont du type "Apple_APFS" (et plus "Apple_CoreStorage").
Quant à l'expression "Container disk2" > elle désigne l'entité globale de stockage APFS (le « Container ») - associée à un identifiant d'appareil disk2 qui est purement virtuel (c'est un "disque de synthèse" qui n'a aucune matérialité nulle part mais qui permet d'identifier globalement l'entité de stockage APFS).
Or ce qui existe sur les 2 partitions converties disk0s2 et disk1s2 > ce sont les Physical Stores du Container APFS : ses "magasins physiques" = émulations de disques durs qui se trouvent importées dans le Container APFS comme sa "base de stockage".
Cette courte analyse conduisant à dire --> l'expression Container disk2 se développe comme : "Physical Store servant de base de stockage (magasin physique) au Container global disk2".
Tu remarques que le haut de tableau concernant ce Container APFS (disque de synthèse global - purement virtuel) confirme cette analyse :
car il est bien mentionné que les partitions disk1s2 et disk0s2 constituent les Physical Stores (les magasins physiques ou supports de stockage) du Container disk2.
----------
Tu remarques que la suite du tableau du Container disk2 est celle-ci :
Il s'agit là de volumes purement virtuels recelés dans le Container disk2 global > et qui sont exportés à partir des magasins de stockage des Physical Stores des 2 partitions.
Ces APFS Volumes n'ont pas de taille préfixées > mais pour limite absolue d'expansion la taille globale du Container disk2 = 3,1 To - taille fixée par la somme exacte des Physical Stores (ou magasins physiques) des partitions ; et pour limite relative l'expansion que la taille actuelle des autres Volumes du Container permet. Bref : ces APFS Volumes augmentent en taille exactement comme le volume d'une image-disque de faible densité (SPARSEBUNDLE) au fur et à mesure de la seule écriture de données.
C'est pourquoi tu remarques que la taille actuelle de l'APFS Volume Macintosh HD est "seulement" de 1,4 To (alors que le Container disk2 a une limite absolue de 3,1 To) --> c'est que tu n'as "que" 1,4 To de données écrites dans ledit APFS Volume (ce qui est énorme). Si tu rajoutes 300 Go > l'APFS Volume Macintosh HD aura une taille de 1,7 To.
Tu noteras que l'APFS Volume n°4 s'intitule VM et a une taille de 2,6 Go. Ce volume VM recèle une sleepimage (fichier clone des contenus de la RAM) - sleepimage qui classiquement résidait dans l'OS et avait une taille fréquemment équivalente à celle de la RAM - par exemple 8 Go pour 8 Go de RAM. Je ne m'explique clairement ni cette nouvelle localisation > ni la faible taille de ce fichier de 2,6 Go. Peut-être s'agit-il d'une sleepimage de la session Recovery > qui permettrait un reboot en mode Recovery d'après ces contenus sauvegardés > ce qui expliquerait la taille de l'image (un volume Recovery décompressé pouvant faire dans les 2 Go).
L'APFS Preboot est une innovation par rapport au CoreStorage > en étant la transformation de la partition auxiliaire de démarrage (« boot helper partition ») qui était le « booter » du CoreStorage. Le « booter » permettait l'exportation au démarrage du Volume Logique du CoreStorage à partir du Voiume Physique émulé sur une partition de disque. Je présume que le Preboot reprend ici la même fonction d'« aide à l'exportation de l'APFS Volume à partir des Physical Stores des partitions » - mais je n'ai pas scruté ses ressources. La différence étant que le Preboot n'est plus le résident d'une partition de disque (comme le « booter» qui était localisé sur une partition en-dessous de chaque partition CoreStorage où résidait un Physical Volume) ; mais c'est à son tour un APFS Volume inclus dans le Container disk2 global.
Autre innovation encore : la Recovery devient à son tour un APFS Volume (le n°3 du tableau) et n'est plus la résidente d'une partition du disque > en cas de CoreStorage Fusion Drive en-dessous de la 2è partition CoreStorage sur le HDD. C'est donc aussi un disque virtuel > sa taille de 520 Mo seulement (au lieu des 650 Mo de l'ancienne Recovery HD) s'expliquant par l'élasticité de cet APFS Volume Recovery > qui peut se dilater à volonté à l'usage.
----------
Je te vois venir car tu penses avoir détecté la faille de toute ma reconstruction théorique : c'est que sur le HDD de 3 To > tu as aussi ceci :
Tu as donc bien une Recovery HD classique > à savoir un volume qui monte sur une partition séparée du HDD (place classique en cas de Fusion Drive CoreStorage) - hors donc du périmètre du Container disk2 ; alors même que tu as un APFS Volume Recovery inclus dans le périmètre du Container disk2.
Je conjecture que la nouvelle et "vraie" Recovery relative à un APFS OS installé dans un APFS Volume d'un Container est celle de l'APFS Volume Recovery recelé dans le Container APFS. J'ai expérimentalement créé sur une partition de SDD un Container APFS (via le «Terminal» - comme condition logique a priori) > puis j'ai installé «High Sierra» dans l'APFS Volume exporté dans ce Container --> si un APFS Volume Recovery est bien créé dans le Container > aucune Recovery HD n'est créée hors Container comme partition séparée du disque.
J'aurais alors tendance à penser (à titre de simple hypothèse de travail ici alors que je ne connais rien de l'APFS) --> que la Recovery HD disk0s3 du HDD à un statut de « fossile logique vivant » : reliquat de ton ancien CoreStorage Fusion Drive qui n'a pas été supprimé à la conversion à l'APFS. Je ne peux pas dire si cette préservation redondante de l'APFS Volume Recovery du Container est un accident logique > ou bien si elle remplit une fonction (par exemple en cas d'APFS Fusion Style).
----------
Un dernier mot sur le procédé "Fusion" > l'ancien procédé Fusion Drive qui dépendait entièrement d'un système de stockage CoreStorage > a été entièrement "récupéré" dans un procédé "Fusion Style" du système de stockage APFS. Il est possible en effet de créer un Container APFS important 2 Physical Stores (1 sur une partition de SSD et 1 sur une partition de HDD) > de telle manière que le Physical Store du SSD soit affecté du rôle "principal" et le Physical Store du HDD du rôle "secondaire".
Ce dispositif induit automatiquement un déclenchement d'algorithmes qui assurent l'optimisation entre les 2 magasins physiques comme dans un Fusion Drive.
Je conjecture que quand on fait une mise-à-niveau comme tu l'as fait > d'un Fusion Drive CoreStorage a à un Fusion Style APFS --> les rôles respectifs des Physical Stores sont bien "compris" > de sorte que le principal se trouve fixé à celui du SSD et le secondaire à celui du HDD ("compris", càd. interprété dans une programmation).
Le dispositif CoreStorage Fusion Drive a bien été converti en un dispositif APFS "Fusion Style". Quand je dis : "dispositif APFS" > je désigne le fait suivant --> l'APFS n'est pas qu'un système de fichiers nouveau (remplaçant du JHFS+) > c'est aussi un système de stockage nouveau (remplaçant du CoreStorage). C'est ce 2è point que je vise ici.
Je note donc que tu n'as plus sur tes 2 disques que des partitions converties à des Physical Stores ("magasins physiques") APFS = disk0s2 et disk1s2 au lieu de partitions converties à des Physical Volumes CoreStorage.
Tu noteras que ces partitions-converties sont ainsi labellisées :
Bloc de code:
2: Apple_APFS Container disk2 3.0 TB disk0s2
2: Apple_APFS Container disk2 121.0 GB disk1s2ce qui veut dire qu'elles sont du type "Apple_APFS" (et plus "Apple_CoreStorage").
Quant à l'expression "Container disk2" > elle désigne l'entité globale de stockage APFS (le « Container ») - associée à un identifiant d'appareil disk2 qui est purement virtuel (c'est un "disque de synthèse" qui n'a aucune matérialité nulle part mais qui permet d'identifier globalement l'entité de stockage APFS).
Or ce qui existe sur les 2 partitions converties disk0s2 et disk1s2 > ce sont les Physical Stores du Container APFS : ses "magasins physiques" = émulations de disques durs qui se trouvent importées dans le Container APFS comme sa "base de stockage".
Cette courte analyse conduisant à dire --> l'expression Container disk2 se développe comme : "Physical Store servant de base de stockage (magasin physique) au Container global disk2".
Tu remarques que le haut de tableau concernant ce Container APFS (disque de synthèse global - purement virtuel) confirme cette analyse :
Bloc de code:
/dev/disk2 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +3.1 TB disk2
Physical Stores disk1s2, disk0s2----------
Tu remarques que la suite du tableau du Container disk2 est celle-ci :
Bloc de code:
1: APFS Volume Macintosh HD 1.4 TB disk2s1
2: APFS Volume Preboot 23.4 MB disk2s2
3: APFS Volume Recovery 521.1 MB disk2s3
4: APFS Volume VM 2.6 GB disk2s4Il s'agit là de volumes purement virtuels recelés dans le Container disk2 global > et qui sont exportés à partir des magasins de stockage des Physical Stores des 2 partitions.
Ces APFS Volumes n'ont pas de taille préfixées > mais pour limite absolue d'expansion la taille globale du Container disk2 = 3,1 To - taille fixée par la somme exacte des Physical Stores (ou magasins physiques) des partitions ; et pour limite relative l'expansion que la taille actuelle des autres Volumes du Container permet. Bref : ces APFS Volumes augmentent en taille exactement comme le volume d'une image-disque de faible densité (SPARSEBUNDLE) au fur et à mesure de la seule écriture de données.
C'est pourquoi tu remarques que la taille actuelle de l'APFS Volume Macintosh HD est "seulement" de 1,4 To (alors que le Container disk2 a une limite absolue de 3,1 To) --> c'est que tu n'as "que" 1,4 To de données écrites dans ledit APFS Volume (ce qui est énorme). Si tu rajoutes 300 Go > l'APFS Volume Macintosh HD aura une taille de 1,7 To.
Tu noteras que l'APFS Volume n°4 s'intitule VM et a une taille de 2,6 Go. Ce volume VM recèle une sleepimage (fichier clone des contenus de la RAM) - sleepimage qui classiquement résidait dans l'OS et avait une taille fréquemment équivalente à celle de la RAM - par exemple 8 Go pour 8 Go de RAM. Je ne m'explique clairement ni cette nouvelle localisation > ni la faible taille de ce fichier de 2,6 Go. Peut-être s'agit-il d'une sleepimage de la session Recovery > qui permettrait un reboot en mode Recovery d'après ces contenus sauvegardés > ce qui expliquerait la taille de l'image (un volume Recovery décompressé pouvant faire dans les 2 Go).
L'APFS Preboot est une innovation par rapport au CoreStorage > en étant la transformation de la partition auxiliaire de démarrage (« boot helper partition ») qui était le « booter » du CoreStorage. Le « booter » permettait l'exportation au démarrage du Volume Logique du CoreStorage à partir du Voiume Physique émulé sur une partition de disque. Je présume que le Preboot reprend ici la même fonction d'« aide à l'exportation de l'APFS Volume à partir des Physical Stores des partitions » - mais je n'ai pas scruté ses ressources. La différence étant que le Preboot n'est plus le résident d'une partition de disque (comme le « booter» qui était localisé sur une partition en-dessous de chaque partition CoreStorage où résidait un Physical Volume) ; mais c'est à son tour un APFS Volume inclus dans le Container disk2 global.
Autre innovation encore : la Recovery devient à son tour un APFS Volume (le n°3 du tableau) et n'est plus la résidente d'une partition du disque > en cas de CoreStorage Fusion Drive en-dessous de la 2è partition CoreStorage sur le HDD. C'est donc aussi un disque virtuel > sa taille de 520 Mo seulement (au lieu des 650 Mo de l'ancienne Recovery HD) s'expliquant par l'élasticité de cet APFS Volume Recovery > qui peut se dilater à volonté à l'usage.
----------
Je te vois venir car tu penses avoir détecté la faille de toute ma reconstruction théorique : c'est que sur le HDD de 3 To > tu as aussi ceci :
Bloc de code:
3: Apple_Boot Recovery HD 650.0 MB disk0s3Tu as donc bien une Recovery HD classique > à savoir un volume qui monte sur une partition séparée du HDD (place classique en cas de Fusion Drive CoreStorage) - hors donc du périmètre du Container disk2 ; alors même que tu as un APFS Volume Recovery inclus dans le périmètre du Container disk2.
Je conjecture que la nouvelle et "vraie" Recovery relative à un APFS OS installé dans un APFS Volume d'un Container est celle de l'APFS Volume Recovery recelé dans le Container APFS. J'ai expérimentalement créé sur une partition de SDD un Container APFS (via le «Terminal» - comme condition logique a priori) > puis j'ai installé «High Sierra» dans l'APFS Volume exporté dans ce Container --> si un APFS Volume Recovery est bien créé dans le Container > aucune Recovery HD n'est créée hors Container comme partition séparée du disque.
J'aurais alors tendance à penser (à titre de simple hypothèse de travail ici alors que je ne connais rien de l'APFS) --> que la Recovery HD disk0s3 du HDD à un statut de « fossile logique vivant » : reliquat de ton ancien CoreStorage Fusion Drive qui n'a pas été supprimé à la conversion à l'APFS. Je ne peux pas dire si cette préservation redondante de l'APFS Volume Recovery du Container est un accident logique > ou bien si elle remplit une fonction (par exemple en cas d'APFS Fusion Style).
----------
Un dernier mot sur le procédé "Fusion" > l'ancien procédé Fusion Drive qui dépendait entièrement d'un système de stockage CoreStorage > a été entièrement "récupéré" dans un procédé "Fusion Style" du système de stockage APFS. Il est possible en effet de créer un Container APFS important 2 Physical Stores (1 sur une partition de SSD et 1 sur une partition de HDD) > de telle manière que le Physical Store du SSD soit affecté du rôle "principal" et le Physical Store du HDD du rôle "secondaire".
Ce dispositif induit automatiquement un déclenchement d'algorithmes qui assurent l'optimisation entre les 2 magasins physiques comme dans un Fusion Drive.
Je conjecture que quand on fait une mise-à-niveau comme tu l'as fait > d'un Fusion Drive CoreStorage a à un Fusion Style APFS --> les rôles respectifs des Physical Stores sont bien "compris" > de sorte que le principal se trouve fixé à celui du SSD et le secondaire à celui du HDD ("compris", càd. interprété dans une programmation).
Dernière édition par un modérateur:
mat
