Salut
Alexandre
En consultant le
man de
diskutil mis-à-jour pour
High Sierra > à la rubrique
APFS > dans la présentation générale inaugurale > section dédiée au :
+ Volume --> il est mentionné dans le § final -->
Bloc de code:
Although it has a device node, an APFS Volume's data
may only be accessed through its files; you cannot
open an APFS Volume device node to "directly" access
its on-disk bytes.
Quoique le volume en question soit doté d'un «
device node » (nœud d'appareil), les données d'un
Volume APFS ne peuvent être "accédées" que par l'intermédiaire des
fichiers (affichés dans ce volume) ; vous ne pouvez
pas ouvrir le «
device node » (nœud d'appareil) d'un
Volume APFS pour accéder directement les
bytes du disque qui supportent les écritures des données.
Cette stipulation correspond absolument à ce que j'ai essayé d'expliquer dans mon précédent message.
Sur un disque classique > tu as une partition qui va du bloc logique n° tant au bloc logique n° tant > et ce découpage de tranche logique (
slice) est enregistré exactement dans la table de partition
GUID de l'en-tête du disque.
Sur l'en-tête de la partition > tu as le système de fichiers
JHFS+ classique. Ce système de fichiers fait en sorte que tout l'espace de blocs de la partition se trouve défini comme un
volume : un espace logique
montable par le
kernel et exhibant les données d'écritures des blocs sous forme de
fichiers interprétables. Le
point de génération de cet espace-volume est le «
dev node » : le "nœud d'appareil" ou point de montage du volume. C'est à ce
dev node que se réfère le
kernel pour monter le volume sur la partition-disque.
Dans cette situation classique > quand tu voulais cloner les données correspondantes (par exemple dans une image-disque) > tu avais 2 possibilités : le clonage de la
partition ou clonage du
volume.
Ce sont des procédés distincts dans leurs approches :
- le clonage du volume accepte comme a priori le mécanisme logique par lequel le kernel a monté en volume exhibant des fichiers l'espace de la partition - ce en se référant au dev node (point de montage) fourni par le système de fichiers. La source étant constituée par des fichiers exhibés dans l'espace d'un volume monté > la destination est également l'espace d'un autre volume monté (géré par le système de fichiers de la partition de destination).
- le clonage de la partition transgresse ce montage du volume par le kernel > en outrepassant le dev node (le point de montage du volume) > pour adresser les blocs logiques bruts de la partition. Cet accès à l'espace primaire de la partition implique le démontage du volume par le kernel et donc la neutralisation du dev node. Suite à quoi > les blocs de la partition peuvent être clonés à partir de leur n° initial > càd. que le système de fichiers lui-même de l'en-tête de la partition va être cloné.
C'est à cet état de choses que le système de fichiers
APFS met
fin. Même si le
Volume APFS monté l'est à partir d'un
point de montage (un
dev node) > il n'est plus possible de
traverser ce
dev node pour accéder l'
espace brut des blocs d'une partition qui serait le plan primaire de sustentation du volume.
Car le
Volume APFS contenu dans le
Conteneur APFS n'est plus le corollaire logique d'une section de disque déterminée. Càd. d'un alignement de blocs de A à Z qu'il suffirait de cloner pour emporter sur la destination l'ensemble du dispositif, système de fichiers y compris. Il y a bien un
magasin de stockage physique (le
Physical Store) qui correspond à la partition du disque - mais ce
Physical Store sustente
4 Volumes APFS concomitants (celui des données et 3 auxiliaires) sans que le volume des données ait pour assignation une série continue de blocs logiques. Les blocs qui lui correspondent sont partout où ça peut dans la série des blocs du
Physical Store.
Bref : le
Volume APFS de données a bien un
point de montage logique (un
dev node) qui lui permet d'être monté par le
kernel > mais ce
dev node est
verrouillé > car il ne correspond plus à une partition-disque de blocs continus classique.
Le procédé de clonage en mode blocs est donc forclos.
----------
Quand tu dis à présent qu'après avoir cloné en
mode fichiers ton
Volume APFS dans une image-disque > tu ne peux plus prendre cette image-disque comme
source pour une
restauration --> c'est le même problème mais à l'envers.
Car la fonction de "
restauration" de l'«
Utilitaire de Disque» appelle l'exécutable
asr (
apple_software_restore - une ancienne gloire de l'ingéniérie Apple) - exécutable qui ne sait faire qu'une chose : cloner en
mode bloc.
Donc tu peux bien monter le volume de ton image-disque et la prendre en
source pour
asr = comme ton image-disque dmg est un disque physique virtuel de type
mono-partitionné > le volume monté l'est via un
dev node qui est
traversable de façon classique > donc
asr peut accéder aux blocs bruts de la partition du disque physique virtuel source.
Mais
pas sur la destination ! Car la destination est un
Volume APFS dont le
dev node, comme j'ai tenté de l'expliquer, n'est
plus traversable pour livrer accès aux blocs d'une partition de résidence fixe. Donc
asr échoue en ce qui concerne la
destination.
En résumé : le système de fichiers
APFS est
incompatible avec le clonage en mode blocs traditionnel --> aussi bien la commande
hdiutil create -srcdevice que la commande
asr restore. Il faut abandonner ce procédé. Il ne reste que le procédé de
clonage en mode fichers.
La question ouverte serait : est-ce que
dd (
data_doubler) - qui clone uniquement par
blocs - serait capable de cloner la partition de résidence totale du
Physical Store (la
disk0s2) ? Ce qui impliquerait de pouvoir adresser ses blocs ? Si c'était le cas > il faudrait envisager une commande du style :
Bloc de code:
sudo dd if=/dev/rdisk0s2 of=/[pathtovolume]/Image.dmg
(en rajoutant les options qui vont bien). L'ennui étant que ça n'en finit pas comme opération.
=> je conseille de passer à «
Carbon Copy Cloner».
Alexandre & Jean
