Cendant que
maco fait la sieste > un petit scarabée dicte les commandes à sa place. C'est drôlement pratique
Mais je m'avise que cette question théorique cruciale n'a pas obtenu de réponse (et que tout le monde - dans l'ivresse du succès - fait comme si elle n'avait jamais été posée) -->
Quelqu'un pourrait m'expliquer en gros comment le Mac fait pour supprimer une partition et la réinjecter dans le HD ?
Alors voici :
La paire de commandes :
Bloc de code:
diskutil eraseVolume free space disk0s5
diskutil eraseVolume free space disk0s4
a demandé à l'utilitaire
diskutil de supprimer les
systèmes de fichiers inscrits sur l'en-tête des 2 partitions n°
4 et n°
5 du disque (lesquels définissaient un volume montable sur les blocs de chaque partition).
Cet effacement a conduit à la suppression du container de chaque partition > dont les blocs ont été virés au statut d'
espace libre > de par l'option de "
non-système de fichiers à recréer" =
free (
free_space). Par la même > ces 2 partitions se sont trouvées désinscrites de la
Table de partition GUID de l'en-tête du disque.
À partir de là > la commande :
Bloc de code:
diskutil resizeVolume disk0s2 0b
a demandé à l'utilitaire
diskutil d'opérer un redimensionnement de l'espace de la partition bénéficiaire n°
2 sur laquelle monte le volume
Macintosh HD de l'OS démarré. L'option
0b finale =
0_byte s'interprète ainsi : "
n'excepter aucun byte libre disponible de ce re-dimensionnement".
Lorsqu'on passe cette demande à
diskutil > le
système de fichiers de la partition bénéficiaire se trouve "
étiré" pour englober l'extension supplémentaire de blocs libres > ce qui fait que ces blocs deviennent des blocs annexés au volume monté par le
système de fichiers. La partition enregistrée dans la
Table de Partition GUID de l'en-têtre du disque se trouve par là-même éditée par addition de la nouvelle extension de blocs.
----------
Mais... un esprit observateur ne peut que constater un "mais". Il existe une partition en
intercalaire entre la partition bénéficiaire
disk0s2 et la bande de blocs libérés par la suppression des anciennes partitions n°
4 et n°
5 (car la numérotation de ces blocs n'a pas changé --> il commencent tous après l'actuelle partition n°
3) : la partition de secours
Recovery HD disk0s3.
Comment donc des blocs séparés de la partition n°
2 Macintosh HD par un intercalaire de
650 Mo de blocs occupés par la partition
Recovery HD > peuvent-ils venir se "coller" au dernier bloc de la partition n°
2 pour que le
système de fichiers de cette dernière puisse être étiré afin de les inclure ?
Le type
Apple_Boot de la partition
Recovery HD permet à l'utiltaire
diskutil de lui octroyer un régime de faveur exceptionnel (dont aucun autre type de partition ne bénéficie) --> à savoir un procédé de "
déplacement sur les blocs" en cas de demande d'extension de la partition de l'OS
du-dessus > à une rangée de blocs situés
en-dessous de la
Recovery.
Pour ce faire > la partition
Recovery HD se trouve dans un premier temps
clonée en queue des blocs du disque (en position n°
4) > puis ce clonage effectué > la partition originale
disk0s3 qui collait la partition
disk0s2 se trouve
supprimée et donc virée à de l'espace libre. Ainsi > tout l'espace libre disponible se trouve désormais
intercalé entre la partition bénéficiaire
disk0s2 et le
clone de la
Recovery HD situé en queue de disque > au point que le premier bloc de l'espace libre touche le dernier bloc de la partition
disk0s2 bénéficiaire.
L'opération "
étirement du système de fichiers" devient donc praticable de façon régulière > si bien qu'à la fin de cette opération > la
Recovery HD clonée en queue du disque se trouve juste
en-dessous de la partition
Macintosh HD étendue sur les blocs libres.
La
preuve absolue de ce que je viens de décrire se trouve dans la numérotation des partitions donnée dans le dernier tableau :
Bloc de code:
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *320.1 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 319.2 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s4
=> on saute directement de
Macintosh HD =
disk0s2 à
Recovery HD =
disk0s4. Alors qu'auparavant la
Recovery HD était bien
disk0s3. Qu'est-ce qui s'est donc passé ? La
Recovery HD disk0s3 a été
clonée en queue de blocs libres du disque en un doublon =
Recovery HD disk0s4 > puis l'original
Recovery HD disk0s3 supprimé --> ne reste plus que la trace significative de l'opération : l'identifiant logique d'appareil
disk0s4 de l'actuelle
Recovery HD remonté au rang n°
3 des partitions - preuve que c'est un
clone.
Pourquoi la numérotation n'a-t-elle pas été mise-à-jour ? - car c'est le
kernel (noyau opérateur) qui gère le montage des volumes sur les partitions > et l'identification d'appareil des partitions. En cas d'opération complexe de re-partitionnement comme ici > il arrive que le
kernel ne mette pas à jour les identifiants > mais continue de charger les paramètres antérieurs.
=> un simple de
re-démarrage du Mac > devrait à la relance du
kernel > restituer à la partition
Recovery HD (clone de l'antérieure) son identifiant de device
disk0s3.
doit faire la sieste. 
