Jibest
la commande dd du Terminal copie intégralement une source vers une destination
Oui : c'est ça.
Disons qu'il y a 2 grands procédés de recopie :
a) le procédé en mode "fichiers" (utilisé par des commandes comme
cp >
ditto >
rsync et des logiciels comme comme «
Carbon Copy Cloner» ou «
Super Duper!»). La
source pour ces opérateurs est toujours exclusivement ce que montre un
volume monté. Volume
défini par la structure logicielle sous-jacente et externe du
système de fichiers inscrit sur l'
en-tête de la partition. Définition d'un Volume càd. d'un
espace de répertoire affichant des fichiers lisibles et scriptibles. Ce qui est une conversion opérée par le système de fichiers à partir des blocs d'écriture bruts de la partition. La définition d'un volume est donc la
génération de cet espace de répertoire affichant des fichiers > qui en somme est la version «
user_friendly » ou encore «
human_readable » de l'alignement des blocs bruts de la partition.
Le volume étant
défini par le
système de fichiers comme espace "
user_friendly" --> il est
monté par le
kernel (noyau opérateur) > càd. pris en charge comme espace-disque.
Bref ! cette mise-en-scène "tournée vers l'utilisateur" effectuée par les 2 compères invisibles : le
système de fichiers et le
kernel --> des "
pseudo-objets" ont l'air d'«
exister en soi », comme des entités quasi chosistes : des
fichiers (et des
fichiers de fichiers =
dossiers). C'est ces "pseudo-objets" que les opérateurs de copie en mode "fichiers" prennent pour
source. Ils ne vont
pas au-delà de cette présence "chosiste" dans l'espace "
human_readable" du
volume monté. Et idem pour la
destination : c'est aussi un
volume monté > càd. un espace de présentation de fichiers > dépendant d'un
autre système de fichiers inscrit sur une autre partition de disque > mais
monté par le même unique
kernel qui est seul à opérer en tant que noyau d'un Système.
----------
- b) le procédé en mode 'blocs" (utilisé par des commandes comme
asr ou
dd). Ces opérateurs se contrefichent des
fichiers présentés dans l'espace de répertoire du volume. Il se contrefichent même, dans l'absolu, du
volume. Du volume
monté (par le
kernel). Mais aussi bien du volume en tant que
définition logique d'un espace de répertoire par le
système de fichiers. Ils
traversent le
point de montage du
volume sur la partition > qui est le
point de départ de la génération du volume par le
système de fichiers : le point de départ de cet espace de répertoire. Ils le traversent pour accéder au «
raw disk ».
Le «
raw disk » (disque brut) est le
conteneur de la partition. Càd. l'
espace brut de blocs allant d'un n° tant à un n° tant qui est enregistré dans la table de partition. Le point de départ du «
raw disk » est le
1er bloc absolu de la partition : le
bloc limite. Sur ce bloc est inscrit le
header du
système de fichiers. L'opérateur qui copie en mode "
blocs" va donc copier
à partir du 1er bloc de la source --> il va donc copier en 1er lieu l'
en-tête des blocs de la partition "
source" où réside le
système de fichiers du volume source. Et il va
copier ces blocs supportant le système de fichiers de la source --> sur l'
en-tête des blocs de la partition de destination. Il va donc
remplacer le
système de fichiers de la
destination > par un
clone du
système de fichiers de la
source.
À partir de là > le destin de l'opérateur en mode "
blocs" est scellé --> pour que le
clone sur la destination du
système de fichiers de la source retrouve ses "petits" --> càd. puisse définir un alignement de blocs bruts comme espace de répertoire de fichiers lisibles --> il faut absolument que l'
alignement des blocs de la partition-source qui suivent le "
point de montage" [càd. le bloc limite qui distingue la fin du système de fichiers du départ du volume montable] --> soit
copié strictement à l'identique de la source sur la destination.
Ainsi --> le
système de fichiers cloné sur l'en-tête des blocs de la partition de destination --> passé le bloc "limite" du
point de montage --> trouvera un
alignement de blocs clones de ceux de la source --> correspondant exactement dans leurs écritures aux
gestionnaires du
système de fichiers exporté : le fichier du
catalogue B-tree > le fichier de l'
allocation des blocs (
bitmap) > le fichier des
segments de blocs en excès (
extents) etc.
Des 2 utilitaires >
asr (
apple_sofware_restore) est le plus "
souple" --> au sens où s'il y a dans le conteneur de la partition de
destination un espace de
blocs excédentaires par rapport à la partition source (par exemple : source =
500 Go > destination =
999 Go) --> il ne va
pas neutraliser les
499 Go de blocs excédentaires parce qu'ils ne correspondent pas a priori au système de fichiers de la source cloné sur la destination. Mais le
système de fichiers cloné sur la
destination > va être "
étiré" en finalisation de la copie pour intégrer comme "
espace disponible" les blocs excédentaires.
asr est un magnifique exemple de l'ingéniérie Apple.
L'utilitaire
dd est un binaire à programmation aussi puissante que
rigide :
tous les blocs excédentaires dans le
conteneur de la partition de destination par rapport à la
capacité de la partition source seront
neutralisés en finalisation de la copie. Càd. que les
bytes correspondant à ces blocs seront
flaggués comme «
null_bytes » (marqués par un astérique
*) --> de telle sorte que les blocs constitués de «
null_bytes » seront des «
null_blocks ». Espace-disque "
absent" (introuvable) qui fait que le conteneur de la partition incluant cet espace-disque "
zéroïsé" n'aura pour capacité que les blocs (écrits ou libres) correspondant à la source. Dans mon exemple :
500 Go (
499 Go de «
null_blocks » se trouvant "disparus").
Je présume que
dd puisse cloner un
disque entier en mode "
blocs" en commençant "à partir du commencement" --> càd. le bloc
0 ou premier bloc du disque source. Bloc
0 supportant la table alternative
Protective_MBR > puis clonant les
32 blocs suivant portant la
Pri[mary] GPT > puis etc. tous les blocs à la suite jusqu'au dernier bloc du disque de la source.
Je n'ai jamais testé cette capacité > harrassé d'avance (mentalement) par le procédé
dd (
data_doubler ou
disk_doubler). Procédé opérant en
aveugle (pas de fonction
verbose ; on peut simplement mettre
dd en
pause --> ce qui affiche une sommation provisoire du rapport : nombre de bytes copiés par tant de secondes) > d'une
lenteur phénoménale (malgré un choix possible de
clusters 4096 bytes) car copiant
byte à
byte comme un véritable bourrin. Ça peut prendre des jours et des jours cette affaire !
En résumé : je n'arrive jamais à me motiver pour m'intéresser à
dd --> c'est plus fort que moi. L'intérêt de retrouver sur un disque de destination la distribution complète d'un disque source n'arrive pas à m'impulser (je m'en f...).
