Ah exact! j'avais loupé l'info et n'avais pas vu ce grand retour dans Utilitaire Disques.
Il suffit d'aller dans le menu "Fichier" et tout en bas se trouve l'Assistant RAID.
10.13 High Sierra Systeme fichier High Sierra
- Créateur du sujet phcm64100
- Date de début
Il suffit d'aller dans le menu "Fichier" et tout en bas se trouve l'Assistant RAID.
M
Membre supprimé 1060554
Invité
Comme ce fil est devenu le dernier "salon" dédié à l'APFS où les conversations s'entrecroisent > je reviens sans complexe au tableau que marenostrum avait posté au message #33 et dont je redonne ici la teneur :
C'est le tableau détaillé du Container APFS "Fusion Style" qui associe les 2 disques de son iMac (SSD & HDD) - ce suite à une conversion du dispositif CoreStorage "Fusion Drive" qui les solidarisait précédemment.
Il saute aux yeux que le système de stockage APFS est une relève (« Aufhebung » aurait dit Hegel) du système de stockage CoreStorage antérieur (le CoreStorage n'est donc pas mort > il survit sous la forme "métamorphique" de l'APFS)-
----------
Comme le système de stockage CoreStorage > on a affaire à un ensemble d'objets logiques relevant d'une "Entité Ensembliste" qui s'appelle désormais Container (et plus Groupe de Volumes Logiques).
Le point qui se note est que c'est le Container APFS qui hérite d'un identifiant d'appareil (ici : disk2) > alors que c'était le Volume Logique qui en était pourvu avec le CoreStorage. On note aussi que les tailles : totale > utilisée > libre du Container se trouvent explicitement mentionnées.
----------
Comme pour un Groupe de Volumes Logiques CoreStorage où existaient 2 types de disques virtuels : Volume Physique / Volume Logique => dans le Container APFS existent 2 types de disques virtuels également : Magasin Physique / Volumes. Le Magasin Physique (Physical Store) emmagasine tous les bytes disponibles pour l'écriture de fichiers ; les Volumes sont des espaces logiques montables par référence à des secteurs de bytes du Magasin Physique > et présentant des fichiers manipulables.
Dans le tableau de marenostrum > il y a 2 Magasins Physiques > parce qu'il a 2 partitions de disques associées dans un Fusion Style.
----------
La grande différence avec le CoreStorage > est qu'il n'y a plus un Volume Logique unique exporté à partir d'un (ou plusieurs) Volume(s) Physique(s) > mais qu'il y a une Famille de Volumes APFS exportée à partir du (ou des) Magasins Physiques.
Cette famille se compose par défaut de 4 Volumes ordonnés > numérotés comme des tranches logiques du disque virtuel du Container (il y a donc analogie avec l'identification des devices par n° de disque associé à des n° de tranches = slices) Ainsi > pour un Container disk2 comme ici > le Volume disk2s1 est celui de macOS > le Volume disk2s2 est celui du Preboot > le Volume disk2s3 est celui de la Recovery > le Volume disk2s4 est celui de la VM recelant une sleepimage.
On peut noter que chaque volume est associé à une indication de sa taille actuelle (en données) > de sa taille de réserve (minimale) si définie > de sa taille de quota (maximale) si définie.
----------
En ce concerne le mystérieux volume n°4 VM (qui porte le même nom que le dossier de l'OS /private/var/vm dans lequel sont recelés la sleepimage et les éventuels swapfiles) > je note qu'un point de montage du volume est défini qui est : /private/var/vm (le Volume Macintosh HD étant défini par /) --> j'en tire l'idée que le dossier traditionnel vm sert de point de montage au volume n°4 VM du Container > de sorte que le fichier sleepimage at: /private/var/vm/sleepimage est celui du volume VM monté à ce dossier-point de montage.
----------
=> pour ce qui est de la question de savoir quel Physical Store (Magasin Physique) en cas de Container APFS Fusion Style a le statut "main" (principal = stockage type SSD) et quel a le statut "secondary" (secondaire = stockage type HDD) --> rien n'est malheureusement mentionné à ce sujet dans le tableau APFS. Il n'est donc pas possible de savoir si le Fusion Style APFS de l'iMac de marenostrum a affecté à bon escient les statuts : main = Physical Store disk1s2 du SSD vs secondary = Physical Store disk0s2 du HDD. C'est évidemment crucial pour la bonne gestion des algorithmes qui assurent l'optimisation entre les 2 Magasins Physiques de stockage.
Bloc de code:
APFS Container (1 found)
|
+-- Container disk2 4465BB1C-9539-4C53-AF2A-6C600508A8A9
====================================================
APFS Container Reference: disk2 (Fusion)
Capacity Ceiling (Size): 3120722075648 B (3.1 TB)
Capacity In Use By Volumes: 1458212343808 B (1.5 TB) (46.7% used)
Capacity Available: 1662509731840 B (1.7 TB) (53.3% free)
|
+-< Physical Store disk1s2 6B58276D-B36C-47CE-9465-B2499BAD2A3B
| -----------------------------------------------------------
| APFS Physical Store Disk: disk1s2
| Size: 120988852224 B (121.0 GB)
|
+-< Physical Store disk0s2 C4A229D9-2226-4A0D-BB74-A81FAEA845DB
| -----------------------------------------------------------
| APFS Physical Store Disk: disk0s2
| Size: 2999733223424 B (3.0 TB)
|
+-> Volume disk2s1 17FDD9FD-824F-3053-AD32-0AB9B1A25CBB
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s1 (No specific role)
| Name: Macintosh HD
| Mount Point: /
| Capacity Consumed: 1446501453824 B (1.4 TB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: No
|
+-> Volume disk2s2 C43C8AF4-8BA4-417F-B54F-75499861425D
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s2 (Preboot)
| Name: Preboot
| Mount Point: Not Mounted
| Capacity Consumed: 23437312 B (23.4 MB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: No
|
+-> Volume disk2s3 B68DED07-BEDC-48B4-8EE8-54408995C9FE
| ---------------------------------------------------
| APFS Volume Disk (Role): disk2s3 (Recovery)
| Name: Recovery
| Mount Point: Not Mounted
| Capacity Consumed: 521072640 B (521.1 MB)
| Capacity Reserve: None
| Capacity Quota: None
| Encrypted: No
|
+-> Volume disk2s4 46452533-69E8-4DC2-845B-78BE42FB78D1
---------------------------------------------------
APFS Volume Disk (Role): disk2s4 (VM)
Name: VM
Mount Point: /private/var/vm
Capacity Consumed: 2147508224 B (2.1 GB)
Capacity Reserve: None
Capacity Quota: None
Encrypted: NoC'est le tableau détaillé du Container APFS "Fusion Style" qui associe les 2 disques de son iMac (SSD & HDD) - ce suite à une conversion du dispositif CoreStorage "Fusion Drive" qui les solidarisait précédemment.
Il saute aux yeux que le système de stockage APFS est une relève (« Aufhebung » aurait dit Hegel) du système de stockage CoreStorage antérieur (le CoreStorage n'est donc pas mort > il survit sous la forme "métamorphique" de l'APFS)-
----------
Comme le système de stockage CoreStorage > on a affaire à un ensemble d'objets logiques relevant d'une "Entité Ensembliste" qui s'appelle désormais Container (et plus Groupe de Volumes Logiques).
Le point qui se note est que c'est le Container APFS qui hérite d'un identifiant d'appareil (ici : disk2) > alors que c'était le Volume Logique qui en était pourvu avec le CoreStorage. On note aussi que les tailles : totale > utilisée > libre du Container se trouvent explicitement mentionnées.
----------
Comme pour un Groupe de Volumes Logiques CoreStorage où existaient 2 types de disques virtuels : Volume Physique / Volume Logique => dans le Container APFS existent 2 types de disques virtuels également : Magasin Physique / Volumes. Le Magasin Physique (Physical Store) emmagasine tous les bytes disponibles pour l'écriture de fichiers ; les Volumes sont des espaces logiques montables par référence à des secteurs de bytes du Magasin Physique > et présentant des fichiers manipulables.
Dans le tableau de marenostrum > il y a 2 Magasins Physiques > parce qu'il a 2 partitions de disques associées dans un Fusion Style.
----------
La grande différence avec le CoreStorage > est qu'il n'y a plus un Volume Logique unique exporté à partir d'un (ou plusieurs) Volume(s) Physique(s) > mais qu'il y a une Famille de Volumes APFS exportée à partir du (ou des) Magasins Physiques.
Cette famille se compose par défaut de 4 Volumes ordonnés > numérotés comme des tranches logiques du disque virtuel du Container (il y a donc analogie avec l'identification des devices par n° de disque associé à des n° de tranches = slices) Ainsi > pour un Container disk2 comme ici > le Volume disk2s1 est celui de macOS > le Volume disk2s2 est celui du Preboot > le Volume disk2s3 est celui de la Recovery > le Volume disk2s4 est celui de la VM recelant une sleepimage.
On peut noter que chaque volume est associé à une indication de sa taille actuelle (en données) > de sa taille de réserve (minimale) si définie > de sa taille de quota (maximale) si définie.
----------
En ce concerne le mystérieux volume n°4 VM (qui porte le même nom que le dossier de l'OS /private/var/vm dans lequel sont recelés la sleepimage et les éventuels swapfiles) > je note qu'un point de montage du volume est défini qui est : /private/var/vm (le Volume Macintosh HD étant défini par /) --> j'en tire l'idée que le dossier traditionnel vm sert de point de montage au volume n°4 VM du Container > de sorte que le fichier sleepimage at: /private/var/vm/sleepimage est celui du volume VM monté à ce dossier-point de montage.
----------
=> pour ce qui est de la question de savoir quel Physical Store (Magasin Physique) en cas de Container APFS Fusion Style a le statut "main" (principal = stockage type SSD) et quel a le statut "secondary" (secondaire = stockage type HDD) --> rien n'est malheureusement mentionné à ce sujet dans le tableau APFS. Il n'est donc pas possible de savoir si le Fusion Style APFS de l'iMac de marenostrum a affecté à bon escient les statuts : main = Physical Store disk1s2 du SSD vs secondary = Physical Store disk0s2 du HDD. C'est évidemment crucial pour la bonne gestion des algorithmes qui assurent l'optimisation entre les 2 Magasins Physiques de stockage.
Comme ce fil est devenu le dernier "salon" dédié à l'APFS où les conversations s'entrecroisent > je reviens sans complexe au tableau que marenostrum avait posté au message #33 et dont je redonne ici la teneur :
Bloc de code:APFS Container (1 found) | +-- Container disk2 4465BB1C-9539-4C53-AF2A-6C600508A8A9 ==================================================== APFS Container Reference: disk2 (Fusion) Capacity Ceiling (Size): 3120722075648 B (3.1 TB) Capacity In Use By Volumes: 1458212343808 B (1.5 TB) (46.7% used) Capacity Available: 1662509731840 B (1.7 TB) (53.3% free) | +-< Physical Store disk1s2 6B58276D-B36C-47CE-9465-B2499BAD2A3B | ----------------------------------------------------------- | APFS Physical Store Disk: disk1s2 | Size: 120988852224 B (121.0 GB) | +-< Physical Store disk0s2 C4A229D9-2226-4A0D-BB74-A81FAEA845DB | ----------------------------------------------------------- | APFS Physical Store Disk: disk0s2 | Size: 2999733223424 B (3.0 TB) | +-> Volume disk2s1 17FDD9FD-824F-3053-AD32-0AB9B1A25CBB | --------------------------------------------------- | APFS Volume Disk (Role): disk2s1 (No specific role) | Name: Macintosh HD | Mount Point: / | Capacity Consumed: 1446501453824 B (1.4 TB) | Capacity Reserve: None | Capacity Quota: None | Encrypted: No | +-> Volume disk2s2 C43C8AF4-8BA4-417F-B54F-75499861425D | --------------------------------------------------- | APFS Volume Disk (Role): disk2s2 (Preboot) | Name: Preboot | Mount Point: Not Mounted | Capacity Consumed: 23437312 B (23.4 MB) | Capacity Reserve: None | Capacity Quota: None | Encrypted: No | +-> Volume disk2s3 B68DED07-BEDC-48B4-8EE8-54408995C9FE | --------------------------------------------------- | APFS Volume Disk (Role): disk2s3 (Recovery) | Name: Recovery | Mount Point: Not Mounted | Capacity Consumed: 521072640 B (521.1 MB) | Capacity Reserve: None | Capacity Quota: None | Encrypted: No | +-> Volume disk2s4 46452533-69E8-4DC2-845B-78BE42FB78D1 --------------------------------------------------- APFS Volume Disk (Role): disk2s4 (VM) Name: VM Mount Point: /private/var/vm Capacity Consumed: 2147508224 B (2.1 GB) Capacity Reserve: None Capacity Quota: None Encrypted: No
C'est le tableau détaillé du Container APFS "Fusion Style" qui associe les 2 disques de son iMac (SSD & HDD) - ce suite à une conversion du dispositif CoreStorage "Fusion Drive" qui les solidarisait précédemment.
Il saute aux yeux que le système de stockage APFS est une relève (« Aufhebung » aurait dit Hegel) du système de stockage CoreStorage antérieur (le CoreStorage n'est donc pas mort > il survit sous la forme "métamorphique" de l'APFS)-
----------
Comme le système de stockage CoreStorage > on a affaire à un ensemble d'objets logiques relevant d'une "Entité Ensembliste" qui s'appelle désormais Container (et plus Groupe de Volumes Logiques).
Le point qui se note est que c'est le Container APFS qui hérite d'un identifiant d'appareil (ici : disk2) > alors que c'était le Volume Logique qui en était pourvu avec le CoreStorage. On note aussi que les tailles : totale > utilisée > libre du Container se trouvent explicitement mentionnées.
----------
Comme pour un Groupe de Volumes Logiques CoreStorage où existaient 2 types de disques virtuels : Volume Physique / Volume Logique => dans le Container APFS existent 2 types de disques virtuels également : Magasin Physique / Volumes. Le Magasin Physique (Physical Store) emmagasine tous les bytes disponibles pour l'écriture de fichiers ; les Volumes sont des espaces logiques montables par référence à des secteurs de bytes du Magasin Physique > et présentant des fichiers manipulables.
Dans le tableau de marenostrum > il y a 2 Magasins Physiques > parce qu'il a 2 partitions de disques associées dans un Fusion Style.
----------
La grande différence avec le CoreStorage > est qu'il n'y a plus un Volume Logique unique exporté à partir d'un (ou plusieurs) Volume(s) Physique(s) > mais qu'il y a une Famille de Volumes APFS exportée à partir du (ou des) Magasins Physiques.
Cette famille se compose par défaut de 4 Volumes ordonnés > numérotés comme des tranches logiques du disque virtuel du Container (il y a donc analogie avec l'identification des devices par n° de disque associé à des n° de tranches = slices) Ainsi > pour un Container disk2 comme ici > le Volume disk2s1 est celui de macOS > le Volume disk2s2 est celui du Preboot > le Volume disk2s3 est celui de la Recovery > le Volume disk2s4 est celui de la VM recelant une sleepimage.
On peut noter que chaque volume est associé à une indication de sa taille actuelle (en données) > de sa taille de réserve (minimale) si définie > de sa taille de quota (maximale) si définie.
----------
En ce concerne le mystérieux volume n°4 VM (qui porte le même nom que le dossier de l'OS /private/var/vm dans lequel sont recelés la sleepimage et les éventuels swapfiles) > je note qu'un point de montage du volume est défini qui est : /private/var/vm (le Volume Macintosh HD étant défini par /) --> j'en tire l'idée que le dossier traditionnel vm sert de point de montage au volume n°4 VM du Container > de sorte que le fichier sleepimage at: /private/var/vm/sleepimage est celui du volume VM monté à ce dossier-point de montage.
----------
=> pour ce qui est de la question de savoir quel Physical Store (Magasin Physique) en cas de Container APFS Fusion Style a le statut "main" (principal = stockage type SSD) et quel a le statut "secondary" (secondaire = stockage type HDD) --> rien n'est malheureusement mentionné à ce sujet dans le tableau APFS. Il n'est donc pas possible de savoir si le Fusion Style APFS de l'iMac de marenostrum a affecté à bon escient les statuts : main = Physical Store disk1s2 du SSD vs secondary = Physical Store disk0s2 du HDD. C'est évidemment crucial pour la bonne gestion des algorithmes qui assurent l'optimisation entre les 2 Magasins Physiques de stockage.
alors puisqu'il est question de commenter sans complexes, je le fais , moi aussi : n'oublions pas que la théorie des ensembles découle de la catégorie restreinte à un seul point !
Merci à tous
Merci a macomaniac pour ses explications
Je suis loin de tout comprendre
Je peux sans probleme reformater mon mac pour avoir le nouveau systeme, mais avant ai 2 questions
Ce nouveau systeme est il plus performant
et
Dois je retelecharger la version beta ou puis je reformarter avec celle que j ai deja et comment ?
merci
Merci a macomaniac pour ses explications
Je suis loin de tout comprendre
Je peux sans probleme reformater mon mac pour avoir le nouveau systeme, mais avant ai 2 questions
Ce nouveau systeme est il plus performant
et
Dois je retelecharger la version beta ou puis je reformarter avec celle que j ai deja et comment ?
merci
Plus performant ? C'est toi qui va nous le dire... Cependant on peut en douter : les premières versions bêta sont rarement des versions optimisées et certaines nouveautés sont encore inabouties.
High Sierra n'est pour l'instant qu'en test et le système à installer pour être tranquille est la dernière mouture de Sierra, sauf bug rédhibitoire bien entendu.
Si la version bêta en ligne est la même que celle que tu as téléchargée, pas besoin de la télécharger de nouveau.
High Sierra n'est pour l'instant qu'en test et le système à installer pour être tranquille est la dernière mouture de Sierra, sauf bug rédhibitoire bien entendu.
Si la version bêta en ligne est la même que celle que tu as téléchargée, pas besoin de la télécharger de nouveau.
Merci Bompi
Alors comment faire pour redemarrer et lancer formatage et installation ?
et surtout avoir la fameuse option
Alors comment faire pour redemarrer et lancer formatage et installation ?
et surtout avoir la fameuse option
Dernière édition par un modérateur:
Bonne question... 
Je dirais que tu dois avoir le moyen de créer une clef USB d'installation à partir de la version téléchargée. Je suppose que les méthodes conseillées pour Sierra continueront de fonctionner.
Je dirais que tu dois avoir le moyen de créer une clef USB d'installation à partir de la version téléchargée. Je suppose que les méthodes conseillées pour Sierra continueront de fonctionner.
Bon j ai trouvé en redemarrantr avec CMD R je peux reformater mais la il me propose plein de choix
lequel choisir
voir image
lequel choisir
voir image
GC APFS
at tout a l heure peut etre si ca explose pas (au Pays Basque, il faut s attendre à tout ....)
at tout a l heure peut etre si ca explose pas (au Pays Basque, il faut s attendre à tout ....)
M
Membre supprimé 1060554
Invité
phcmPuisque High Sierra est déjà installé dans ton volume PCM Osx (partition disk0s2 ; volume au format JHFS+) > pourquoi est-ce que tu te compliques la vie ?
Une fois démarré par ⌘R sur le Recovery OS -->
- soit tu lances le «Terminal» (menu : Utilitaires) > et tu passes une des 2 commandes au choix :
Bloc de code:
diskutil ap convert disk0s2 diskutil ap convert /Volumes/"PCM Osx"
- soit tu lances l'«Utilitaire de Disque» > tu sélectionnes le volume PCM Osx > menu : Édition > sous-menu : Convertir en APFS
--> les 2 procédés sont strictement équivalents. Après démontage du volume-cible PCM Osx > il va y avoir conversion à l'APFS > après quoi tu pourras re-démarrer > ré-ouvrir ta session dans High Sierra et... ton volume ainsi que le système de fichiers qui le gère seront en APFS.
Bien évidemment > l'OS déjà installé > ainsi que le compte d'utilisateur > sont conservés par cette conversion logique.
-----------
@ Flo
Est-ce que ce procédé de conversion a posteriori à l'APFS d'un volume JHFS+ dans lequel a été installé a priori High Sierra répond à ta question ?
Dernière édition par un modérateur:
Voili voilou
Formatage, High Sierra et reinstallation des softs
Fini
A priori je ne vois pas de difference sauf qu au bout je trouve plus long
Formatage, High Sierra et reinstallation des softs
Fini
A priori je ne vois pas de difference sauf qu au bout je trouve plus long
Une fois le volume converti en APFS, quels logiciels de sauvegarde peut-on utiliser à ce stade?
Est-ce qu'Apple a mis à jour TimeMachine dans HighSierra?
Est-ce qu'Apple a mis à jour TimeMachine dans HighSierra?
Merci pour tous les détails macomaniac, je n'avais pas eu le temps de me pencher sur ce nouveau FS, mais c'est assez clair. Par contre il va falloir s'habituer à tout avoir en dynamique, ce que je ne fais même pas en jfs2 au boulot (on ajoute nos LP/PP à la mano, jusqu'à concurrence des PP dispos, et après faut rajouter un LUN ).
).Très bonne question concernant Timemachine qui est quand même une solution clé en main.
Une refonte de TM est nécessaire pour qu'il soit compatible avec APFS. Je ne vois pas Apple laisser macOS sans solution de sauvegarde pour les utilisateurs "basiques"
Pour la sauvegarde Carbon copy cloner de bombich a annoncé une pre version assez compatible avec APFS.
Dans cette capture on voit la notion de "purgeable" : Certainement un stockage des versions un peu à la façon d'une backup est peut être inclu dans macOS pour ensuite faciliter les sauvegarde du futur TimeMachine. Tout est conservé jusqu'à que de l'espace soit nécessaire.
Un comportement qui est à étudier mais il ne serait pas étonnant qu'Apple n'est pas poussé le concept de "versions" jusqu'au tréfond du système. Celui-ci étant le fondement même d'APFS. (Snapshot, alias,...)
On note aussi la présence de 4 volumes sur la capture. Est ce de base ou une modification perso ?
M
Membre supprimé 1060554
Invité
En réponse à la question de r e m y :
j'ai réalisé le test suivant avec «Carbon Copy Cloner» -->
Ce procédé élémentaire peut permettre à des usagers de la developer beta n°1 de High Sierra d'assurer leurs arrières provisoirement.
----------
Le point qui est à noter et que j'avais tenté d'éclairer dans des messages précédents de ce fil est le suivant : un Volume APFS est le résident d'un ensemble logique de référence appelé Container APFS. Le Volume APFS recelant macOS se trouve accompagné dans le même Container de 3 autres Volumes APFS qui sont ses auxiliaires directs :
Le dispositif que je viens de décrire en abrégé présente la différence fondamentale suivante par rapport au dispositif d'un OS installé dans le Volume Logique d'un système de stockage CoreStorage : les 2 Volumes auxiliaires Preboot et Recovery ne sont plus affectés à des partitions de disque séparées de la partition portant le volume de l'OS > mais ce sont des Volumes APFS inclus dans le même Container d'ensemble que le Volume macOS.
Il est donc clair que si l'on voulait cloner un Volume APFS macOS non pas comme dans mon test dans un volume de destination JHFS+ > mais dans un Volume APFS => il faudrait à toute force que dans le Container APFS de destination puisse être cloné également (au minimum) le Volume APFS Preboot > sans lequel aucun Volume APFS macOS n'est démarrable. Et il vaudrait mieux aussi pouvoir cloner les 2 autres Volumes APFS : la Recovery du Container source > et également le Volume APFS VM recelant une sleepimage.
Bref : la problématique du clonage d'un Volume APFS macOS > devient le problème de cloner les composants d'un Container APFS complet > càd. ses 4 Volumes logiquement solidaires : macOS > Preboot > Recovery > VM. Voilà la tâche à laquelle Mike Bombich est en train de s'atteler (quel veinard ! - avec Apple > il n'a jamais le temps de s'ennuyer > il lui faut toujours remettre en chantier son logiciel <et il a commencé avec Cheetah 10.0>-
). Évidemment > la version de «CCC» capable de cette performance n'est pas encore publiée.
----------
Pour donner un indice de la difficulté de la tâche --> supposons un volume JHFS+ de simple stockage > démarré sur mon OS High Sierra recelé dans un Volume APFS > je décide d'utiliser à son sujet la fonction de "Convertir à APFS" de l'«Utilitaire de Disque» ou la commande : diskutil ap convert [device] dans le «Terminal». L'opération n'a aucun mal à s'effectuer (conservativement pour les données en place) mais... le Container qui se trouve généré sur la partition du volume-cible va être un Container APFS de Stockage et non un Container APFS de Démarrage.
Càd. que dans le Container en question > il n'y aura que 2 objets en tout et pour tout : le Physical Store (Magasin Physique) correspondant à l'espace de stockage de la partition > et le Volume APFS qui s'exporte à partir de ce Magasin Physique de stockage. Pas de Volume Preboot > pas de Volume Recovery > pas de Volume VM. Ce qui paraît logique.
L'ennui (j'ai essayé) > c'est que si je reprends le clone JHFS+ créé au départ par «CCC» > et si j'active à son sujet l'option de Conversion à APFS > je vais obtenir... un Container APFS de Stockage simple auquel manqueront les 3 volumes auxiliaires : Preboot > Recovery > VM. Ce qui n'arrive pas, par contre, si l'OS recelé dans le volume JHFS+ est un High Sierra qui y a été installé par un installateur avec l'option : "Upgrade to APFS" décochée.
Il s'en conclut que : si le clone JHFS+ réalisé par «CCC» est démarrable tel quel et a l'air une image conforme d'un High Sierra installé sans l'option "Upgrade to APFS" > il ne leurre pas une seconde la fonction de "Conversion à APFS" de l'«Utilitaire de Disque» ou du «Terminal» - qui ne créera pas dans le Container de destination les 3 volumes auxiliaires requis. Résultat : le clone JHFS+ qui était démarrable tel quel > converti à un Volume APFS > ne sera plus démarrable > car il lui manque notamment le Volume auxiliaire Preboot sans lequel un Volume-Système APFS ne peut pas démarrer. Et déjà ne peut pas être affiché par le gestionnaire de démarrage de l'EFI (touche alt).
j'ai réalisé le test suivant avec «Carbon Copy Cloner» -->
- démarré sur un Volume APFS contenant «High Sierra» > j'ai cloné en direction d'un volume JHFS+ monté sur un autre disque ;
- la copie s'effectue sans aucun problème > ce qui n'a rien d'étonnant puisque «CCC» copie en mode "fichiers" --> il est donc capable de reproduire dans un volume JHFS+ une arborescence dossiers > sous-dossiers > fichiers d'un volume APFS en préservant les propriétés (étant bien entendu que le système de fichiers "source" ne fait jamais l'objet d'une recopie en mode "fichiers") ;
- le volume JHFS+ cloné est démarrable sans difficulté > la session d'utilisateur ouvrable > et on a affaire à un clone du High Sierra source dans un volume JHFS+ ;
- il est également possible > démarré sur le clone JHFS+ > d'utiliser «CCC» pour rétro-cloner ce clone dans le volume source APFS monté => ce dernier volume reste démarrable > et on récupère une image-conforme du clone dans le volume APFS.
Ce procédé élémentaire peut permettre à des usagers de la developer beta n°1 de High Sierra d'assurer leurs arrières provisoirement.
----------
Le point qui est à noter et que j'avais tenté d'éclairer dans des messages précédents de ce fil est le suivant : un Volume APFS est le résident d'un ensemble logique de référence appelé Container APFS. Le Volume APFS recelant macOS se trouve accompagné dans le même Container de 3 autres Volumes APFS qui sont ses auxiliaires directs :
- un Volume APFS Preboot qui reprend le rôle du « booter » d'un Volume Logique CoreStorage --> c'est directement l'auxiliaire de démarrage du Volume macOS du Container. À cette fin > il contient un dossier « booter » recelant les ressources dé pré-démarrage du Volume macOS exécutables par l'EFI ;
- un Volume APFS Recovery qui reprend le rôle de la « Recovery HD » --> c'est le Volume de secours permettant de réparer ou de restaurer l'OS du Volume macOS en cas de pépin. Il recèle un dossier de démarrage du Recovery OS comme antérieurement.
- un Volume APFS VM qui recèle un fichier sleepimage (image des contenus de la RAM) > et dont le point de montage est le dossier /private/var/vm qui recèle traditionnellement la sleepimage dans l'OS.
Le dispositif que je viens de décrire en abrégé présente la différence fondamentale suivante par rapport au dispositif d'un OS installé dans le Volume Logique d'un système de stockage CoreStorage : les 2 Volumes auxiliaires Preboot et Recovery ne sont plus affectés à des partitions de disque séparées de la partition portant le volume de l'OS > mais ce sont des Volumes APFS inclus dans le même Container d'ensemble que le Volume macOS.
Il est donc clair que si l'on voulait cloner un Volume APFS macOS non pas comme dans mon test dans un volume de destination JHFS+ > mais dans un Volume APFS => il faudrait à toute force que dans le Container APFS de destination puisse être cloné également (au minimum) le Volume APFS Preboot > sans lequel aucun Volume APFS macOS n'est démarrable. Et il vaudrait mieux aussi pouvoir cloner les 2 autres Volumes APFS : la Recovery du Container source > et également le Volume APFS VM recelant une sleepimage.
Bref : la problématique du clonage d'un Volume APFS macOS > devient le problème de cloner les composants d'un Container APFS complet > càd. ses 4 Volumes logiquement solidaires : macOS > Preboot > Recovery > VM. Voilà la tâche à laquelle Mike Bombich est en train de s'atteler (quel veinard ! - avec Apple > il n'a jamais le temps de s'ennuyer > il lui faut toujours remettre en chantier son logiciel <et il a commencé avec Cheetah 10.0>-
----------
Pour donner un indice de la difficulté de la tâche --> supposons un volume JHFS+ de simple stockage > démarré sur mon OS High Sierra recelé dans un Volume APFS > je décide d'utiliser à son sujet la fonction de "Convertir à APFS" de l'«Utilitaire de Disque» ou la commande : diskutil ap convert [device] dans le «Terminal». L'opération n'a aucun mal à s'effectuer (conservativement pour les données en place) mais... le Container qui se trouve généré sur la partition du volume-cible va être un Container APFS de Stockage et non un Container APFS de Démarrage.
Càd. que dans le Container en question > il n'y aura que 2 objets en tout et pour tout : le Physical Store (Magasin Physique) correspondant à l'espace de stockage de la partition > et le Volume APFS qui s'exporte à partir de ce Magasin Physique de stockage. Pas de Volume Preboot > pas de Volume Recovery > pas de Volume VM. Ce qui paraît logique.
L'ennui (j'ai essayé) > c'est que si je reprends le clone JHFS+ créé au départ par «CCC» > et si j'active à son sujet l'option de Conversion à APFS > je vais obtenir... un Container APFS de Stockage simple auquel manqueront les 3 volumes auxiliaires : Preboot > Recovery > VM. Ce qui n'arrive pas, par contre, si l'OS recelé dans le volume JHFS+ est un High Sierra qui y a été installé par un installateur avec l'option : "Upgrade to APFS" décochée.
Il s'en conclut que : si le clone JHFS+ réalisé par «CCC» est démarrable tel quel et a l'air une image conforme d'un High Sierra installé sans l'option "Upgrade to APFS" > il ne leurre pas une seconde la fonction de "Conversion à APFS" de l'«Utilitaire de Disque» ou du «Terminal» - qui ne créera pas dans le Container de destination les 3 volumes auxiliaires requis. Résultat : le clone JHFS+ qui était démarrable tel quel > converti à un Volume APFS > ne sera plus démarrable > car il lui manque notamment le Volume auxiliaire Preboot sans lequel un Volume-Système APFS ne peut pas démarrer. Et déjà ne peut pas être affiché par le gestionnaire de démarrage de l'EFI (touche alt).
Dernière édition par un modérateur:
Hum hum, tu t'es fait pirater ton clavier, Melaure ?ce que je ne fais même pas en jfs2 au boulot (on ajoute nos LP/PP à la mano, jusqu'à concurrence des PP dispos, et après faut rajouter un LUN
