Partition HDD externe (NTFS) faite depuis windows introuvable sur mac
- Créateur du sujet JustD
- Date de début
D
Deleted member 1099514
Invité
Ok je ne vois pas d'autres solutions que :
soit acheter un DDE et faire un clone de ton Fusion Drive avec CarbonCopyCloner par exemple (version d'essai gratuite pendant 1 mois)
soit de reformater le DDE actuel en perdant son contenu et utiliser aussi CCC.
soit acheter un DDE et faire un clone de ton Fusion Drive avec CarbonCopyCloner par exemple (version d'essai gratuite pendant 1 mois)
soit de reformater le DDE actuel en perdant son contenu et utiliser aussi CCC.
M
Membre supprimé 1060554
Invité
Salut JustD
Il y a 2 anomalies remarquables à ton Fusion Drive (sans doute liées). La première est que c'est la partition de 420 Go de ton HDD qui a le premier rang = disk0s2, tandis que la partition de 119 Go de ton SSD n'a que le second rand = disk1s2. Il s'ensuit que c'est sur une partition secondaire = disk1s3 du SSD que se trouve installée la «Recovery HD», ce qui montre que ce disque est traité à l'instar d'un HDD, tandis que le HDD est traité à l'instar d'un SSD (c'est toujours sur le disque d'appoint = HDD normalement, que la «Recovery HD» s'installe en cas de Fusion Drive).
Tout est donc monté à l'envers. J'en viens donc à me demander si le Système de ton OS n'a pas été installé sur le secteur du HDD au lieu du secteur du SDD : est-ce qu'au fonctionnement tu as l'impression que ça traîne comme avec les HDD à plateaux classiques, ou est-ce que tu as bien la vitesse d'un SSD ?
La double anomalie que je viens de relever fait que l'espace libre (qui correspondait aux 80 Go de ton ancienne partition Windows) n'est pas situé en queue de secteur physique du disque n°2, mais en queue de secteur physique du disque n°1 (ton HDD qui a le rang n°1). Donc la commande de re-dimensionnement global de Jean
ne pouvait pas marcher, car elle a été comprise en pratique comme : "récupérer tout ce qui traîne en queue de secteur physique du dernier disque" => or dans ton Fusion Drive, c'est le SSD, et en-dessous de son secteur physique consacré au Fusion Drive, il n'y a que la «Recovery HD» et zéro espace libre récupérable. D'où le message : « The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change ».
Je te propose d'essayer de contourner la difficulté en mode analytique (par 2 commandes distinctes, et pas en mode tout en un) =>
Fais d'abord un copier-coller de :
et ↩︎ (presse la touche "Entrée") --> une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> le Physical Volume sur ton HDD devrait récupérer l'espace libre de 80 Go, avec re-dimensionnement corrélatif de la taille de la partition GUID dont il est solidaire.
Enchaîne alors par un :
et ↩︎ (pas besoin de nouvelle authentification par mot-de-passe dans les 5' après un premier sudo) --> si tout va bien, le Volume Logique devrait être dilaté en correspondance à la dilatation du Volume Physique sur le HDD (et donc récupérer 80 Go)
☞ quoi qu'il en soit de ces bidouillages logiques, je le redis : ton Fusion Drive est monté à l'envers. La seule solution drastique est que tu t'achètes un DDE USB basique de 500 Go, que tu clones (démo gratuite de ☞Carbon Copy Cloner☜ pour ce faire) le volume de ton OS dans le volume au format JHFS+ du DDE dont le disque doit avoir une table GUID). Tu démarres alors sur le clone, dans le «Terminal» tu supprimes le Fusion Drive, et tu en re-crées un neuf "à l'endroit" ce coup-ci. Pour finir, tu rétro-clones ton clone dans le Volume Logique du Fusion Drive (et «CCC» te clonera pour finir une «Recovery HD» là où il faut = secteur final du HDD identifié comme le support n°2 du Fusion Drive).
Il y a 2 anomalies remarquables à ton Fusion Drive (sans doute liées). La première est que c'est la partition de 420 Go de ton HDD qui a le premier rang = disk0s2, tandis que la partition de 119 Go de ton SSD n'a que le second rand = disk1s2. Il s'ensuit que c'est sur une partition secondaire = disk1s3 du SSD que se trouve installée la «Recovery HD», ce qui montre que ce disque est traité à l'instar d'un HDD, tandis que le HDD est traité à l'instar d'un SSD (c'est toujours sur le disque d'appoint = HDD normalement, que la «Recovery HD» s'installe en cas de Fusion Drive).
Tout est donc monté à l'envers. J'en viens donc à me demander si le Système de ton OS n'a pas été installé sur le secteur du HDD au lieu du secteur du SDD : est-ce qu'au fonctionnement tu as l'impression que ça traîne comme avec les HDD à plateaux classiques, ou est-ce que tu as bien la vitesse d'un SSD ?
La double anomalie que je viens de relever fait que l'espace libre (qui correspondait aux 80 Go de ton ancienne partition Windows) n'est pas situé en queue de secteur physique du disque n°2, mais en queue de secteur physique du disque n°1 (ton HDD qui a le rang n°1). Donc la commande de re-dimensionnement global de Jean
ne pouvait pas marcher, car elle a été comprise en pratique comme : "récupérer tout ce qui traîne en queue de secteur physique du dernier disque" => or dans ton Fusion Drive, c'est le SSD, et en-dessous de son secteur physique consacré au Fusion Drive, il n'y a que la «Recovery HD» et zéro espace libre récupérable. D'où le message : « The requested size change for the target disk or a related disk is too small; please try a different disk or partition, or make a larger change ».Je te propose d'essayer de contourner la difficulté en mode analytique (par 2 commandes distinctes, et pas en mode tout en un) =>
Fais d'abord un copier-coller de :
Bloc de code:
sudo diskutil cs resizePV 3E7E2E55-3F00-490F-85A4-36564FB2DE96 0bEnchaîne alors par un :
Bloc de code:
sudo diskutil cs resizeLV 1EC90086-F352-43E9-BC72-1A635B47DA42 0b☞ quoi qu'il en soit de ces bidouillages logiques, je le redis : ton Fusion Drive est monté à l'envers. La seule solution drastique est que tu t'achètes un DDE USB basique de 500 Go, que tu clones (démo gratuite de ☞Carbon Copy Cloner☜ pour ce faire) le volume de ton OS dans le volume au format JHFS+ du DDE dont le disque doit avoir une table GUID). Tu démarres alors sur le clone, dans le «Terminal» tu supprimes le Fusion Drive, et tu en re-crées un neuf "à l'endroit" ce coup-ci. Pour finir, tu rétro-clones ton clone dans le Volume Logique du Fusion Drive (et «CCC» te clonera pour finir une «Recovery HD» là où il faut = secteur final du HDD identifié comme le support n°2 du Fusion Drive).
D
Deleted member 1099514
Invité
Salut @macomaniac
Si tu regardes le post #3 dans le cs list, c'est bien le SSD qui a l'index 0 donc de ce coté pas de soucis pour moi.
Par contre je pense qu'il est impossible de redimensionner un Fusion Drive sans tout casser et recréer. Ce qui serait une bonne chose dans le cas présent.
@+
Si tu regardes le post #3 dans le cs list, c'est bien le SSD qui a l'index 0 donc de ce coté pas de soucis pour moi.
Par contre je pense qu'il est impossible de redimensionner un Fusion Drive sans tout casser et recréer. Ce qui serait une bonne chose dans le cas présent.
@+
M
Membre supprimé 1060554
Invité
Jean (petit intermède dominical bien abstrus)C'est sûr que les index sont théoriquement dans le bon ordre (secteur SSD = 0 et secteur HDD = 1) - mais je n'arrive pas à concevoir comment il se fait que la «Recovery HD» soit sur le disque qui a l'index 0 (le SSD) => ça ne doit jamais arriver, en principe : c'est toujours sur le HDD qu'elle doit résider. Si réellement elle a été créée à cet emplacement à l'installation de l'OS (sans y être un résidu non supprimé d'une installation antérieure isolée sur le SDD, ce qui n'est guère vraisemblable, car dans ce cas il devrait y avoir une 2è «Recovery HD» créée à l'installation en queue de HDD) - alors c'est quand même le signe que le Fusion Drive est de travers, puisque son SSD a été considéré à l'install comme 2è disque.
C'est cette existence de la «Recovery HD» sur le SSD qui m'a fait insister sur un mauvais montage. L'échec de ta commande (exacte) de re-dimensionnement de la pile du CoreStorage me semble inexplicable encore, à moins de supposer que le HDD (qui recèle l'espace libre en fin de disque) est assimilé à un disque de tête et non de queue. C'est ce qui m'a donné l'idée d'une commande de re-dimensionnement spécifique du Physical Volume du HDD (toujours honorée en principe, s'il y a de l'espace libre disponible sur le disque concerné).
Pour tester, j'ai créé un Fusion Drive expérimental associant les secteurs principaux de 2 clés USB intitulés respectivement HDD et SDD. Je me suis arrangé pour créer une «Recovery HD» (par dmtest) en-dessous de SDD. Et pour avoir un zone d'espace libre en-dessous de HDD. Donc une structure analogue au cas de ce fil. Dans mon Fusion Drive, j'ai mis HDD en index 0 et SSD en index 1. J'ai copié des données dans le Volume Logique exporté. J'ai passé les 2 mêmes sortes de commandes que j'ai proposées ici : un resizePV sur HDD (index 0) pour récupérer au Physical Volume l'espace libre de la clé correspondante ; puis un resizeLV sur le Volume Logique global (dont le secteur physique n°2 de support est bien SDD = index 1) => les 2 commandes ont passé sans problème et sans perte de données, alors que l'espace libre était bien "intercalé" entre les 2 secteurs HDD et SSD et pas en-dessous du dernier secteur SDD ; et alors que la dilatation du Volume Logique devait se faire par adaptation à la dilatation préalable du Physical Volume n°1 (et pas du n°2, ce qui est le cas de figure classique commandé par le verbe resizeStack). Ce succès m'a incité à proposer le même type d'opération ici.
Quoi qu'il en soit, je pense comme toi au final que le mieux à faire serait de détruire ce Fusion Drive et d'en re-créer un propre, en utilisant un clone comme base de démarrage externe.
