D
Fusionner 2 partitions d'un disque dur externe MAC
- Créateur du sujet Patshak
- Date de début
M
Membre supprimé 1060554
Invité
Salut Patshak
Intrigant, le cas de ton disque Western Digital. Je te propose (à mes risques et périls) quelques spéculations (d'une valeur de vérité douteuse) :
Il s'ensuit que ton disque, physiquement unique, n'est pas "partitionné" en 2 "secteurs logiques" relevant d'une même Table de Partition ; il est "scindé" en 2 "supports-disques" qui ne relèvent pas d'une même Table de Partition, mais qui portent chacun leur propre Table de Partition.
Lorsque tu attaches ce disque au Mac (par l'intermédiaire d'un boîtier - peu importe lequel), les utilitaires du Mac (comme diskutil) sont incapables d'appréhender le disque physique unicitaire ; ils ne peuvent qu'appréhender le plan de la dualité de "supports-disques". Tout se passe donc comme si une couche logicielle duale "recouvrait" le disque physique unique, en empêchant totalement les utilitaires du Mac de la traverser pour adresser le support physique.
Ça me fait penser (de loin) au CoreStorage, qui, en émulant un disque dur sur l'espace d'une partition majeure d'un disque, crée par là une couche logique qui "recouvre" le disque physique en le rendant inaccessible par les moyens classiques (mais, pour ce qui est du CoreStorage, l'utilitaire diskutil possède une implémentation lui permettant de gérer ce type de couche logique).
Ces réflexions me conduisent à la conjecture suivante : ce n'est pas en t'adressant à Western Digital que tu vas régler ton problème ; non plus qu'en continuant d'utiliser les utilitaires standards du Mac ; mais c'est en t'adressant à l'origine de cette scission logicielle de ton disque en 2 "supports-disques" sans communication : à savoir, la logistique Drobo qui a, présumablement, manipulé le disque WD quand il était dans le NAS.
À vue de nez, la situation ressemble à une distribution RAID en 2 "supports-disques", sauf qu'il ne s'agirait pas d'un RAID logiciel standard, que diskutil serait alors capable d'identifier ; mais d'un RAID spécial relevant de la logistique Drobo. Cette logistique ne serait-elle pas capable d'affecter le firmware du disque lui-même (le contrôleur), ce qui pourrait expliquer que les utilitaires purement logiques du Mac soit incapables de voir autre chose que l'« effet produit » : la distribution en 2 "supports-disques" ?
Mais pourquoi diantre alors cette bipartition asymétrique en 2,2 To et 0,8 To ? - une seule chose me vient à l'esprit => lorsqu'on a affaire à des disques de très grandes capacités (càd. > 2 To), un effet limitatif d'une Table de Partition MBR (pour Windows) est que ce type de gestion de l'espace d'un disque est incapable d'un mappage allant au-delà de la limite absolue des 2,2 premiers To de blocs du disque. Tous les blocs en-deça des 2,2 premiers To pourront être interprétés dans la table MBR, mais les blocs au-delà de la limite des 2,2 To échapperont totalement à l'interprétation logique de cette table, et seront considérés comme "non-alloués" (càd. de l'espace_libre). .
Conjecture "folle" : est-il envisageable que cette limitation intrinsèque à la Table MBR (de ne pas pourvoir mapper les blocs au-delà des 2,2 premiers To) conduirait la logistique Drobo instauratrice d'un RAID « maison » à transformer logiciellement en "support-disque" séparatif tout ce qui déborde de ces 2,2 To, soit dans le cas d'un disque de 3 To, à convertir les 0,8 To en excès en "support-disque" scindé du premier ? Ce qui permettrait de gérer tous les blocs, en les affectant à 2 "entités-disques" au lieu de 2 partitions d'une même table MBR ?
Cette limite est absente de la GPT (Table de Partition GUID), qui peut très bien mapper sans limitation des disques de très grande taille. Faut-il donc supposer que le disque Western Digital pour NAS (géré par une logistique Drobo) aurait a priori été "apprêté" en 2 "supports-disques" par rapport à une table MBR, avant de servir pour un Mac ?
Pour cela, dans le «Terminal», tu commences par passer la commande qui va créer un Groupe de Volumes Logiques important un Volume Physique sur chaque partition :
=> tu devrais voir se dérouler l'affichage suivant :
Ensuite, tu adaptes la commande suivante qui va exporter un Volume Logique unique à partir de ce CoreStorage associatif (en collant exactement à la place de mon XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX le réel UUID de ton Logical Volume Group affiché en fin d'opération précédente - attention aux espaces critiques dans la commande) :
=> tu devrais voir se dérouler l'affichage suivant :
=> avec montage sur ton Bureau d'un volume unique de 3 To intitulé Stock (que tu peux renommer à ta guise dans le Finder).
[NB. Il serait possible, à la place, d'opérer une assocation logique des 2 disques pour exporter un Volume Unique par le truchement d'un appleRAID concaténé, par une commande de type :
mais le CoreStorage est un procédé Apple plus moderne que le RAID. À supposer que la scission du disque WD en 2 "supports-disques" ait été d'origine (à cause de la limitation des 2,2 To dans une table MBR), mais que le disque soit apparu dans le NAS comme porteur d'un seul volume, alors il y aurait eu un RAID associatif des 2 "supports-disques" pour générer un Volume unique]
Intrigant, le cas de ton disque Western Digital. Je te propose (à mes risques et périls) quelques spéculations (d'une valeur de vérité douteuse) :
- Comme il s'agit d'un seul et unique disque dur, le réflexe est de considérer que les 2 volumes qui montent visiblement à partir de ce disque (Sans titre 1 et Sans titre 1 2) correspondent aux systèmes de fichiers de 2 partitions dépendant d'une seule et même Table de Partiton GUID mappant l'espace intégral de ce disque physique.
- Contrairement à cette idée, la commande diskutil list ne te retourne pas, concernant le disque Wester Digital, l'identifiant d'un seul disque (/dev/disk1) qui comporterait 2 partitions principales (de 2,2 To et 0,8 To) ; mais bel et bien 2 identifiants de disques (/dev/disk1 et /dev/disk2), chacun supportant une Table de Partition GUID complète.
- Contrairement à cette idée, la commande diskutil list ne te retourne pas, concernant le disque Wester Digital, l'identifiant d'un seul disque (/dev/disk1) qui comporterait 2 partitions principales (de 2,2 To et 0,8 To) ; mais bel et bien 2 identifiants de disques (/dev/disk1 et /dev/disk2), chacun supportant une Table de Partition GUID complète.
Il s'ensuit que ton disque, physiquement unique, n'est pas "partitionné" en 2 "secteurs logiques" relevant d'une même Table de Partition ; il est "scindé" en 2 "supports-disques" qui ne relèvent pas d'une même Table de Partition, mais qui portent chacun leur propre Table de Partition.
Lorsque tu attaches ce disque au Mac (par l'intermédiaire d'un boîtier - peu importe lequel), les utilitaires du Mac (comme diskutil) sont incapables d'appréhender le disque physique unicitaire ; ils ne peuvent qu'appréhender le plan de la dualité de "supports-disques". Tout se passe donc comme si une couche logicielle duale "recouvrait" le disque physique unique, en empêchant totalement les utilitaires du Mac de la traverser pour adresser le support physique.
Ça me fait penser (de loin) au CoreStorage, qui, en émulant un disque dur sur l'espace d'une partition majeure d'un disque, crée par là une couche logique qui "recouvre" le disque physique en le rendant inaccessible par les moyens classiques (mais, pour ce qui est du CoreStorage, l'utilitaire diskutil possède une implémentation lui permettant de gérer ce type de couche logique).
--------------------
Ces réflexions me conduisent à la conjecture suivante : ce n'est pas en t'adressant à Western Digital que tu vas régler ton problème ; non plus qu'en continuant d'utiliser les utilitaires standards du Mac ; mais c'est en t'adressant à l'origine de cette scission logicielle de ton disque en 2 "supports-disques" sans communication : à savoir, la logistique Drobo qui a, présumablement, manipulé le disque WD quand il était dans le NAS.
À vue de nez, la situation ressemble à une distribution RAID en 2 "supports-disques", sauf qu'il ne s'agirait pas d'un RAID logiciel standard, que diskutil serait alors capable d'identifier ; mais d'un RAID spécial relevant de la logistique Drobo. Cette logistique ne serait-elle pas capable d'affecter le firmware du disque lui-même (le contrôleur), ce qui pourrait expliquer que les utilitaires purement logiques du Mac soit incapables de voir autre chose que l'« effet produit » : la distribution en 2 "supports-disques" ?
--------------------
Mais pourquoi diantre alors cette bipartition asymétrique en 2,2 To et 0,8 To ? - une seule chose me vient à l'esprit => lorsqu'on a affaire à des disques de très grandes capacités (càd. > 2 To), un effet limitatif d'une Table de Partition MBR (pour Windows) est que ce type de gestion de l'espace d'un disque est incapable d'un mappage allant au-delà de la limite absolue des 2,2 premiers To de blocs du disque. Tous les blocs en-deça des 2,2 premiers To pourront être interprétés dans la table MBR, mais les blocs au-delà de la limite des 2,2 To échapperont totalement à l'interprétation logique de cette table, et seront considérés comme "non-alloués" (càd. de l'espace_libre). .
Conjecture "folle" : est-il envisageable que cette limitation intrinsèque à la Table MBR (de ne pas pourvoir mapper les blocs au-delà des 2,2 premiers To) conduirait la logistique Drobo instauratrice d'un RAID « maison » à transformer logiciellement en "support-disque" séparatif tout ce qui déborde de ces 2,2 To, soit dans le cas d'un disque de 3 To, à convertir les 0,8 To en excès en "support-disque" scindé du premier ? Ce qui permettrait de gérer tous les blocs, en les affectant à 2 "entités-disques" au lieu de 2 partitions d'une même table MBR ?
Cette limite est absente de la GPT (Table de Partition GUID), qui peut très bien mapper sans limitation des disques de très grande taille. Faut-il donc supposer que le disque Western Digital pour NAS (géré par une logistique Drobo) aurait a priori été "apprêté" en 2 "supports-disques" par rapport à une table MBR, avant de servir pour un Mac ?
--------------------
Au cas où tu ne parviendrais pas à supprimer la scission de ton disque en 2 "supports-disques", tu peux toujours opérer une synthèse logique "par en-dessus", en créant un CoreStorage associatif (équivalent d'un Fusion Drive) des 2 partitions majeures /dev/disk1s2 et /dev/disk2s2 (si les identifiants n'ont pas varié ente temps - repasser un diskutil list pour vérifier).
Pour cela, dans le «Terminal», tu commences par passer la commande qui va créer un Groupe de Volumes Logiques important un Volume Physique sur chaque partition :
Bloc de code:
diskutil coreStorage createLVG FUSION /dev/disk1s2 /dev/disk2s2
Bloc de code:
Started CoreStorage operation
Unmounting disk1s2
Touching partition type on disk1s2
Adding disk1s2 to Logical Volume Group
Unmounting disk2s2
Touching partition type on disk2s2
Adding disk2s2 to Logical Volume Group
Creating Core Storage Logical Volume Group
Switching disk1s2 to Core Storage
Switching disk2s2 to Core Storage
Waiting for Logical Volume Group to appear
Discovered new Logical Volume Group "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
Core Storage LVG UUID: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Finished CoreStorage operationEnsuite, tu adaptes la commande suivante qui va exporter un Volume Logique unique à partir de ce CoreStorage associatif (en collant exactement à la place de mon XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX le réel UUID de ton Logical Volume Group affiché en fin d'opération précédente - attention aux espaces critiques dans la commande) :
Bloc de code:
diskutil coreStorage createLV XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX jhfs+ Stock 100%
Bloc de code:
Started CoreStorage operation
Waiting for Logical Volume to appear
Formatting file system for Logical Volume
Initialized /dev/rdisk3 as a 3 TB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Core Storage LV UUID: XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
Core Storage disk: disk3
Finished CoreStorage operation[NB. Il serait possible, à la place, d'opérer une assocation logique des 2 disques pour exporter un Volume Unique par le truchement d'un appleRAID concaténé, par une commande de type :
Bloc de code:
diskutil appleRAID create concat Stock jhfs+ /dev/disk1 /dev/disk2--------------------
Dernière édition par un modérateur:
Cher Ami… tu es un génie… Cher Macomaniac… Je me lève ce matin… je vois ton message… Bon un peu long
et un peu au delà de mon niveau de compréhension… mais j'ai suivi très simplement tes informations de la fin
par 2 simples copier-coller et BINGOOO… un seul disque… Nikel chrome… visible dans uilitaire de disque en 1 morceau
et cerise sur le gateau j'ai même pu le renommer… LOL ! Effectivement Drobo est bien un RAID maison… un peu Bip Bip (censure) d'ailleurs c'est pour celà que je le quitte… Pour ta remarque sur le partionnage asymétrique… il provient du fait que comme tu dois le savoir le drobo sauvedarde une partie de chaque disque sur les autres et qu'il a la particularité d'accepter des disques de tailles différentes… ainsi j'avais 3 disques de 1To et le dernier de 3To ainsi donc, le système avait partitionné ce disque de tel sorte qu'il est une petite partie des autres… etc etc… bref tu m'as compris.
En tout cas 1000 MERCIS… et MERCI à tous ceux qui ont tenté de m'aider… Il reigne une ambiance très chaleureuse sur ce forum… je pense que je vais continuer à m'y ballader… Bonne journée à Tous.
et un peu au delà de mon niveau de compréhension… mais j'ai suivi très simplement tes informations de la fin
par 2 simples copier-coller et BINGOOO… un seul disque… Nikel chrome… visible dans uilitaire de disque en 1 morceau
et cerise sur le gateau j'ai même pu le renommer… LOL ! Effectivement Drobo est bien un RAID maison… un peu Bip Bip (censure) d'ailleurs c'est pour celà que je le quitte… Pour ta remarque sur le partionnage asymétrique… il provient du fait que comme tu dois le savoir le drobo sauvedarde une partie de chaque disque sur les autres et qu'il a la particularité d'accepter des disques de tailles différentes… ainsi j'avais 3 disques de 1To et le dernier de 3To ainsi donc, le système avait partitionné ce disque de tel sorte qu'il est une petite partie des autres… etc etc… bref tu m'as compris.
En tout cas 1000 MERCIS… et MERCI à tous ceux qui ont tenté de m'aider… Il reigne une ambiance très chaleureuse sur ce forum… je pense que je vais continuer à m'y ballader… Bonne journée à Tous.
D
Deleted member 1099514
Invité
Il n'empêche que tu as toujours 2 disques physiques, certes réunis dans une structure logique, mais quand même séparés pour le système.
Perso j'aurais tenté d'utiliser les outils WD ou sinon les contacter. Il doit y avoir un pb de firmware qui devrait pouvoir être résolu.
Perso j'aurais tenté d'utiliser les outils WD ou sinon les contacter. Il doit y avoir un pb de firmware qui devrait pouvoir être résolu.
Et pourtant le système voit bien 2 disques (Disk 1 et Disk2) chacun portant sa table de partition GUID et chacun scindé en 2 partitions s1 et s2
C'est quand même bizarre!
Quelle est la reference du disque WD? Ce ne serait pas un disque hybride embarquant 800 Go de SSD et 2,2 To de disque à plateaux?
REMY > non c'est un seul disque physique… un disque dur externe nu ! un WD RED acheté sur Amazon…
JEAN > il faudra que je reteste un "diskutil list" pour voir ce qu'il me met mais là je ne suis plus à côté… ce soir !
Sinon je me pose la question : Si je le reformate maintenant avec l'utilitaire de disque qui le voit bien et en un seul morceau…
ne va t'il pas me le reformater avec un bon reformatage des familles ?
JEAN > il faudra que je reteste un "diskutil list" pour voir ce qu'il me met mais là je ne suis plus à côté… ce soir !
Sinon je me pose la question : Si je le reformate maintenant avec l'utilitaire de disque qui le voit bien et en un seul morceau…
ne va t'il pas me le reformater avec un bon reformatage des familles ?
M
Membre supprimé 1060554
Invité
PatshakSi tu passes une commande :
Bloc de code:
diskutil cs listEn résumé, si tu fais un diskutil list, tu vas voir identifiés 4 disques : un /dev/disk0 qui est le disque physique interne du Mac ; un /dev/disk1 & un /dev/disk2 qui sont les 2 "support-disques" qui divisent logiquement le disque physique du DDE (lequel n'apparaît pas en tant que support d'un seul tenant) ; un /dev/disk3, enfin, qui est le Volume Logique considéré comme couche logique exportée de 2è ordre.
Donc : la division logique en 2 "supports-disques" de ton disque dur n'est en rien abolie, mais au fond est-ce un problème ? Comme c'est apparemment une implémentation qui a été injectée dans le Firmware, c'est une donne aussi stable que si tu avais 2 disques durs distincts dans un même boîtier. Dans ces conditions, le CoreStorage t'apporte une solidarisation logicielle permettant d'exporter un seul Volume Logique en terme d'utilisation. Mais si tu voulais supprimer cette division, est-ce que remettre le disque dans le NAS ne permettrait pas de le remanipuler par la logistique Drobo ?
[NB. Si tu demandes à l'«Utilitaire de Disque» un reformatage, il va simplement supprimer le système de fichiers JHFS+ terminal qui réside dans le Volume Logique du CoreStorage, pour en régénérer un neuf dans cette même localisation du Volume Logique intouché => bref : la structure logicielle du Groupe de Volumes Logiques CoreStorage : Volume Physique n°1 (sur disk1s2) + Volume Physique n°2 (sur disk2s2) > Famille Logique > Volume Logique restera intacte - tu ne manipuleras que le système de fichiers JHFS+ terminal qui repose sur la couche du Volume Logique.]
Dernière édition par un modérateur:
