iMac J'ai "perdu" les 3 To de mon stockage

[Deleted member 1099514]

Je m'immisce après les opérations, pour apporter un complément d'information.

Lorsqu'on achète à Apple un iMac à 2 disques, un SSD de 120 Go et un HDD de 3 To, solidarisés en mode Fusion Drive, alors Apple construit ce Fusion Drive selon une architecture spéciale, prenant en compte la taille de 3 To du HDD.

Pourquoi ? Parce que l'utilisateur doit avoir la possibilité d'installer Windows via l'«Assistant BootCamp». Dans le cas d'un Fusion Drive, la partition BOOTCAMP résidera forcément en queue de blocs du HDD de 3 To. Or il faut savoir qu'un disque Mac possède 2 tables de partition : la table principale GPT, mais aussi une table secondaire MBR (résidant sur le bloc 0) - et que c'est le mappage de l'espace du disque par la Table de partition secondaire MBR qui servira de référence aux logiciels Windows. Mais une table de partition MBR a une limitation intrinsèque en ce qui concerne l'espace de blocs qu'elle peut mapper : à savoir la limite de 2,2 To, passés lesquels aucun bloc excédentaire ne sera considéré comme existant en mode MBR.

Par suite, installer Windows sur une partition BOOTCAMP d'un HDD de 3 To située en queue de ce disque conduit forcément à ce que tout son espace (si elle fait moins de 800 Go, ce qui est énorme) ou la plus grande partie (si elle excède 800 Go) soit non-reconnu en mode MBR. Par suite, Windows ne pourra pas être installé sur un tel espace de partition inconnu de la MBR.

Comment alors proposer à la vente un iMac possédant un HDD de 3 To associé en Fusion Drive à un SSD, pour que le repartitionnement par l'«Assistant BootCamp» de l'espace global du Fusion Drive génère une partition BOOTCAMP située nécessairement en-deçà de la limite critique des 2,2 premiers To de blocs du HDD ?

Joli problème, non ?

--------------------​

En voici la solution : avant même de créer le Fusion Drive, il faut bi-partitionner le HDD en 2 partitions, la première de 2,2 To, et la 2è de 800 Go. Admettons que la partition principale du SSD soit disk1s2 comme dans le cas de Maubuis > il faut nécessairement créer 2 partitions sur le HDD, une disk0s2 (après la petite partition EFI de 209 Mo) de 2,2 To, et une disk0s3 de 800 Go.

Cela fait, d'un démarrage sur un Système autonome comme le clone de Maubuis, il faut passer une commande de création d'un CoreStorage Fusion Drive qui soit :

diskutil coreStorage createLVG FUSION disk1s2 disk0s2 disk0s3

ce qui va créer un CoreStorage important 3 Physical Volumes (et pas 2), à partir de quoi, en récupérant l'UUID du Logical Volume Group, il sera possible de passer la commande d'exportation d'une paire Logical Volume Family > Logical Volume du style :

diskutil coreStorage createLV [LVGUUID] jhfs+ "Macintosh HD" 100%

Cela fait, que va-t-il se passer à l'installation d'«El Capitan» en clean install, ou en cas de clonage de type «CCC» ? Une partition de récupération «Recovery HD» de 650 Mo va être créée sur le HDD, exactement entre les 2 partitions supportant le Fusion Drive sur ce disque, soit en disk0s3 (après la disk0s2 de 2,2 To légèrement réduite) et avant la partition de 800 Go, ci-devant disk0s3 et à présent disk0s4.


Que va-t-il alors se passer si l'utilisateur demande à l'«Assistant Bootcamp» de lui créer une partition pour installer Windows ? Alors, par implémentation spéciale du programme de ce logiciel, c'est exclusivement la partition de tête du HDD qui va être repartitionnée, càd. la disk0s2 de 2,2 To, ce qui fait que, quelle que soit la taille demandée pour une partition Windows, serait-elle de 1 To, alors elle sera toujours comprise avant la limite des 2,2 premiers To de blocs (puisque créée par repartitionnement d'un zone de blocs courant jusqu'à la butée de 2,2 To) => la partition BOOTCAMP fera donc partie du mappage de la table de partition secondaire MBR du disque. Donc Windows pourra être installé.

On aura donc sur le HDD le schéma suivant (en supposant une partition BOOTCAMP avec Windows installé de 400 Go):

/dev/disk0
#:                  TYPE NAME            SIZE        IDENTIFIER
0: GUID_partition_scheme                *3.0 TB      disk0
1:                   EFI EFI             209.7 MB    disk0s1
2:     Apple_CoreStorage                 1.79 TB     disk0s2
3:            Apple_Boot Recovery HD     650.0 MB    disk1s3
4:    Microsoft Reserved BOOTCAMP        400.0 GB    disk1s4
5:     Apple_CoreStorage                 800.0 GB    disk1s5
6:            Apple_Boot Boot OS X       134.2 MB    disk1s6

=> par voie de conséquence, 2 partitions intercalaires (la 3: Apple_Boot Recovery HD 650.0 MB disk1s3 et la 4: Microsoft Reserved BOOTCAMP 400.0 GB disk1s4) s'inscrivent entre les 2 partitions support du CoreStorage Fusion Drive du HDD (la 2: Apple_CoreStorage 1.79 TB disk0s2 et la 5: Apple_CoreStorage 800.0 GB disk1s5, où se trouvent importés 2 des 3 Physical Volumes).

Salut @macomaniac

Tu as testé?

 

[Membre supprimé 1060554]

Jean

Tu as testé?

Pas au sens de « vérifié par moi-même » : car je n'ai pas d'iMac avec un disque interne de 3 To.

Mais au sens de « vérifié par un autre » : naguère, en effet, dans un message privé (ça arrive plus souvent que souhaité), un membre des forums m'a sollicité pour un de ces inénarrables problèmes de partitionnement occasionnés par un plantage de l'«Assistant BootCamp» lorsqu'on lui demande de supprimer une partition BOOTCAMP dédiée à Windows qu'il a créée et de réallouer l'espace de blocs libéré à la partition de l'OS. Tu en connais un rayon sur la question : CoreStorage (parfois Chiffré) faisant butoir > free_space en train de se ballader en queue du disque > «Utilitaire de Disque» d' «El Capitan» incapable ne serait-ce que de représenter sa localisation > utilisateur désespéré de cette « disparition d'espace disponible »

Bref : je lui passe les commandes classiques diskutil list & diskutil cs list > il me ressort une table de partition où un Fusion Drive associait les 2 disques (SSD & HDD) de son iMac, SSD = 121 Go et HDD = 3 To > j'éprouve sur le coup une impression de « bizarreté » (si je puis dire pour rendre cet effet de bizarrerie) > son HDD avait 2 partitions principales : s2 = 1,8 To & s4 = 800 Go, avec une s3 Recovery HD 650 Mo intercalée + du free_space pour environ 400 Go entre la s3 et la s4 (d'après un rapport gpt show).

J'ai mis un moment à me remettre du choc logique et j'ai fini par piger que j'avais sous les yeux (un peu secoué, suite au plantage de BOOTCAMP) le dispositif archétype d'un Fusion Drive ©Apple dans le cas de figure : iMac > SSD 121 Go > HDD 3 To.

Dans ce cas, ils créent d'usine un CoreStorage à triple Physical Volume en bi-partitionnant a priori le HDD en 2,2 To & 800 Go => Physical Volume n°1 = s2 (121 Go) du SSD > Physical Volume n°2 = s2 (2,2 To) du HDD > Physical Volume n°3 = s4 (800 Go) du HDD (s3 avant install d'OS X).

À l'install d'OS X sur le Volume Logique unique, le Programme d'Install repartitionne exclusivement la partition s2 (2,2 To) du HDD pour créer la «Recovery HD» pile en s3 intercalaire entre les 2 partitions du CoreStorage du HDD.

Au lancement de l'«Assistant BootCamp» pour lui faire créer une partition BOOTCAMP pour Windows, c'est exclusivement encore la s2 (2,2 To - 650 Mo de la «Recovery HD») du HDD qui est repartitionnée, pour générer une s4 entre la s3 de la «Recovery HD» et la s5 du 2è secteur du CoreStorage, lequel garde une taille constante de 800 Go (il y a toujours une petite partition de 134 Mo en queue pour le booter Boot OS X du dispositif CoreStorage) => ainsi, la partition BOOTCAMP n'excède jamais la limite des 2,2 To et est donc reconnue a priori par la MBR du secteur 0 du disque.

Donc il y a bien 2 partitions démarrables intercalées (s3 = Recovery HD > s4 = BOOTCAMP) entre les 2 partitions Fusion Drive (s2 > s5) du HDD dans le paradigme Apple, lorsque le HDD fait 3 To.

[C'est marrant, parce que c'est « compliqué » sans être « complexe ». « Compliqué » au sens de ces ruses de l'enfance pour arriver à piquer dans le placard aux confitures de la grand-mère sans donner l'impression visuelle qu'il manque quelque chose...]

Tu imagines sans mal l'indescriptible foutoir que ça donne, quand l'utilisateur (qui a eu toujours l'impression graphique depuis le début que le Volume de ton OS était constitué d'un seul bloc) > demande à l'«Assistant BootCamp» de supprimer la partition BOOTCAMP > et se retrouve avec autant de Go disparus suite au plantage du logiciel incapable de récupérer cet espace intercalaire s4 au CoreStorage d'ensemble

 

[Deleted member 1099514]

En effet.