10.12 Sierra Récupération espace libre du ssd

[Membre supprimé 1060554]

Comme tu vois > les 3 partitions sont alignées sans espace libre : ce qui est convenable.

- il y a en fin de disque un tampon de 262151 blocs = 134 Mo de blocs libres. Pas très habituel (il n'y a normalement que 7 blocs libres en tampon entre la fin de la partition de secours > et la Sec(ondary) GPT = sauvegarde de la table de partition GPT d'en-tête du disque). Mais non problématique.​

Les 2 anomalies (volume Recovery HD non affiché + index d'appareil modifié à disk0s4) -->

- ont à voir avec le procédé de récupération d'espace. Demande-toi comment un espace libre qui était situé en-dessous de la partition de secours (en queue de disque donc) => a pu se trouver accollé à la partition principale n°2 (Macintosh HD) > alors que la partition de secours intercalaire faisait obstacle...​

 

[Membre supprimé 1060554]

Me revoici pour réponse à ma petite question -->

- de l'espace libre sur un disque : c'est toujours un alignement arithmétique de blocs logiques (de 512 octets ici) qui ne peut pas jouer à saute-mouton, si une partition (comme la partition de secours) s'intercale comme obstacle entre le bloc de début de l'espace libre et le bloc de fin de la partition de Macintosh HD destinée à le récupérer.​

- la seule solution concevable consiste en un clonage préalable de la partition de secours (650 Mo de blocs - partition indexée dans le kernel ou noyau du Système démarré comme disk0s3) => sur les 650 Mo de blocs de fin du disque (càd. de terminaison de l'espace libre de fin du disque). Cette partition de secours-clone va se trouver indexée en tant que nouvel appareil dans le kernel --> comme disk0s4.​

- ce clonage effectué par l'utiiltaire diskutil (convoqué par la commande) --> il y a suppression de la partition de secours originale disk0s3 > laquelle bloquait la récupération d'espace libre en faisant obstacle entre cette bande de blocs disponibles et la partition Macintosh HD. La suppression des 650 Mo de cette partition de secours originale disk0s3 compense les 650 Mo de fin d'espace libre consommés pour la création du clone de partition de secours. Ainsi => une bande continue de blocs libres existe désormais à partir du dernier bloc de la partition n°2 de Macintosh HD => jusqu'au 1er bloc du clone de partition de secours de pied de disque.​

- le système de fichiers jhfs+ (formateur du volume Macintosh HD sur la partition n°2) => peut alors se trouver étiré --> pour gérer comme extension de partition tous les blocs libres jusqu'au commencement de la partition de secours-clone. Cet "étirement" du système de fichiers équivaut à la récupération de l'espace libre. Mais pendant ce temps > le kernel conserve dans sa mémoire des appareils l'index disk0s4 de la partition de secours-clone => sans le mettre à jour de l'index disk0s3 désormais vacant (ces index assignent des rangs temporels dans la prise en charge en kernel des partitions - non des "attributs intrinsèques" des partitions).​

- quant au volume Recovery HD (formé par le système de fichiers jhfs+ cloné de l'original sur l'en-tête de la partition de secours-clone de fin du disque) => souvent il ne se trouve pas défini sur la partition > faute de prise en charge par le kernel du système de fichiers cloné - parce que le type "Apple_Boot" de la partition de secours clonée proscrit tout montage automatique en kernel d'un volume de cette partition. Cas de figure intervenant marginalement néanmoins : le binaire diskutil se loupe au clonage du système de fichiers la partition de secours --> ce qui fait que la partition existe avec un type "Apple_boot" mais aucun volume Recovery HD ne se trouve défini sur la partition : tu vas avoir l'occasion de vérifier si tout s'est bien passé ou pas à ce niveau.​

=> donc redémarre une fois (ce qui ré-génère un kernel avec prise en charge neuve des partitions de disques). De retour dans ta session > repasse la commande :

diskutil list disk0

• et reposte la configuration du disque interne (telle que prise actuellement en charge par le nouveau kernel démarré en RAM) : si tout se passe bien > la partition de secours (clone) sera indexée disk0s3 avec un volume Recovery HD défini sur la partition mais non monté ; sinon > il y aura bien un index de partition disk0s3 > mais aucun volume Recovery HD défini sur la partition.

 

[crey]

Bonjour, là c'est sûr que je n'aurais pas pu trouver la réponse tout seul ! En tout cas, merci beaucoup pour avoir résolu mon problème et aussi pour l'aspect pédagogique que j'apprécie tout particulièrement !

MacBook-Pro-de-Benjamin:~ benjaminmerlin$ diskutil list disk0
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS Macintosh HD            250.0 GB   disk0s2
   3:                 Apple_Boot                         650.0 MB   disk0s3
MacBook-Pro-de-Benjamin:~ benjaminmerlin$

 

[Membre supprimé 1060554]

Malheurement comme tu le peux le voir à ce descriptif de la partition de secours -->

   3:                 Apple_Boot                         650.0 MB   disk0s3

• si le redémarrage a bien pu restaurer l'index d'appareil de la partition à disk0s3 > aucun volume Recovery HD ne s'est trouvé redéfini sur la partition. Ce qui laisse conjecturer que diskutil s'est loupé en partie dans l'opération de clonage de la partition de secours originale => à son clone actuel.

Vérification de ce loupé. Passe la commande :

diskutil mount disk0s3

• qui instruit le montage du volume de la partition de secours

Poste le retour (à tous les coups tu vas avoir un message d'échec du montage)...