Partitionner disque dur externe WD Elements

louisbaron

Membre enregistré
29 Octobre 2015
3
0
31
Bonjour à tous,

Je souhaiterais partitionner mon disque dur externe (1To) en 2 parties pour y mettre mes fichiers personnels dans l'une et une sauvegarde Time Machine de mon Mac dans l'autre.
Cependant j'ai déjà 250Go de fichiers sur ce même disque dur, j'aimerais donc savoir si il est possible de le partitionner sans perdre tous ces fichiers.

Merci pour vos réponses.

Louis
 
A mon humble avis, tu ferais mieux d'en rester là, car c'est un très mauvais plan que de vouloir le faire. Si un jour ton disque dur rend l'âme, tu perdras l'intégralité de toutes tes données. :(

Il serait beaucoup plus sage d'acheter un autre disque dur uniquement que pour Time Machine. ;)
 
  • J’aime
Réactions: louisbaron
Hello Locke,

Eh fait ce serait simplement le temps pour moi de changer le disque dur de mon mac, qui clairement est en train de me claquer entre les doigts, et ainsi ne pas perdre tout ce qu'il y a dessus. Du coups acheter un disque dur pour une opération de quelques minutes, ça m'embêterais un peu.

Du coups est-ce que tu connais une solution pour quand même faire la manip' ?
 
Bonsoir
Pourquoi partitionner ? (je ne pense pas que cela soit possible ou alors avec le terminal, peut être...)
Vous pouvez très bien faire un dossier avec la sauvegarde de vos documents, conserver les 250 Go existant et quand même dédier ce disque à TM
 
Salut Franz,

Merci pour ta réponse. J'ai bien essayé de faire ça mais lorsque je veux démarrer la sauvegarde une message apparaît en disant: "Ce disque doit être effacé avant son utilisation pour des sauvegardes de Time Machine car son système de fichiers n’est pas compatible"...

Voilà pourquoi j'ai tenté la partition
 
Avec un peu de chance, ça n'est pas un formatage "Mac"…



Note de la modération: pas trop de rapport avec les portables Mac, je déplace dans le forum adéquat.
 
Salut louisbaron.

À la différence de l'Anglais, qui multiplie les mots distincts afin que chacun n'ait qu'une acception de sens univoque ; le Français aime rassembler plusieurs directions de pensée différentes sous un même mot, dont l'acception de sens est équivoque [aussi la langue Anglaise est-elle solidaire du Pragmatisme, là où la langue Française l'est de la Spéculation]. Le terme Français : « re-partitionner » n'échappe pas à cette équivocité linguistique - quand bien même intervient-il dans le domaine de l'informatique.

En effet, si « re-partitionner » s'applique à un Disque physique, il désigne une opération logique destructrice d'une Table de Partition pré-existante dans sa totalité (ce qui implique donc les sous-partitions de cette Table qui délimitent des espaces de ce disque, avec leurs systèmes de fichiers qui constituent la mise-en-forme de ces espaces de partition, comprenant notamment les catalogues d'adresses des données incluses dans ces espaces de partitions) - destruction d'une Table de Partition suivie de la recréation d'une nouvelle Table de Partition, avec des sous-partitions découpant de nouveaux espaces et contenant formellement des systèmes de fichiers vierges, avec des catalogues entièrement vides d'adresses de données. Pratiquement parlant : re-partitionner un Disque équivaut à perdre l'accès à toutes les données qui étaient indexées par les catalogues de partitions.

Mais si « re-partitionner » s'applique à un Volume logique, il désigne alors une opération qui porte sur l'espace particulier d'une partition comprise dans une Table de Partition du disque, opération qui va conduire à la subdivision de cet espace unique pour le redistribuer en 2 ou plus de 2 espaces de nouvelles partitions. Ce redécoupage local n'implique absolument pas la suppression de la Table de Partition globale du disque, mais seulement le remaniement local de l'espace d'une seule de ses partitions. Qu'advient-il alors au système de fichiers unique qui constituait la mise-en-forme de cet espace, avec notamment un catalogue d'adresses des données incluses dans cet espace ?

Tout dépend entièrement du format du système de fichiers de la partition concernée par le re-partitionnement. Si le format de ce système de fichiers est étranger au format propriétaire Apple (donc par exemple un format MS-DOS aka FAT-32), alors un re-partitionnement est impossible directement : il ne peut y avoir que "suppression" de la partition, c'est-à-dire soustraction de son espace à la Table de Partition du disque et virement au statut d'espace_libre hors partitionnement. Ce qui implique la suppression du système de fichiers en place, et donc du catalogue d'adresses des données. Mais si le format du système de fichiers de la partition est le format propriétaire Apple HFS+ (Mac OS étendu - journalisé ou non), alors un re-partitionnement de l'espace de la partition est toujours possible (c'est une conséquence de la propriété d'« élasticité » du format de système de fichiers HFS+).

L'implication de ce repartitionnement de l'espace d'une partition incluant un système de fichiers au format Apple HFS+, est qu'il est toujours conservatif par défaut de la structure formelle du système de fichiers déjà en place, avec donc son catalogue indexant les adresses des données contenues. L'espace de la partition va être rétréci, avec en corollaire dynamique (dit mode "live") un resserrement conservatif du système de fichiers formel contenu, gardant intact le catalogue d'adresses des données, et par suite préservant intégralement l'accessibilité des données écrites à l'espace désormais rétréci. Parallèlement, l'espace dégagé par ce rétrécissement se trouve défini comme une néo-partition, pour laquelle le formateur de système de fichiers crée un système de fichiers vierge au format choisi, avec un catalogue vierge.

=> en guise de résumé pratique : si je re-partitionne un Disque, je perds toutes les données ; si je re-partitionne un Volume (un "volume" est le système de fichiers contenu dans une partition-Disque, donc l'espace-Disque d'une partition vu comme géré par une forme logique), étant donné que je ne peux le faire que si le format du système de fichiers de la partition est le format Apple HFS+, alors il y a toujours conservation des données déjà en place sur un espace-disque diminué, avec rétrécissement conservatif du système de fichiers HFS+ préalable, et création en-dessous de cet espace de celui d'une néo-partition vierge, contenant un système de fichiers vierge. Par contre, si le format du système de la partition est non-Apple (par exemple MS-DOS), alors je ne peux absolument pas re-partitionner dynamiquement le volume en question.

=> résumé de ce résumé : je perds toujours tout à re-partitionner un Disque ; je ne perds jamais rien à re-partitionner un Volume (exprimer des craintes à ce sujet est totalement infondé, étant donné la propriété logique du format de système de fichiers HFS+ qui supporte de manière entièrement conservative les re-dimensionnements dynamiques en + ou en - de l'espace-partition support).

[NB. L'«Utilitaire de disque» d'«El Capitan», non seulement est devenu une espèce de "jouet de gosses" ridicule de par la réduction de ses options ; mais il semble que le dictat de l'univocité inhérent à la langue Anglaise veuille manipuler dans ce sens la superbe équivocité de la langue Française. Ainsi, le menu "Partitionner" ne gère plus équivoquement aussi bien la possibilité de "re-partitionner un disque" que de "re-partitionner un volume" comme le faisait l'«Utilitaire de Disque» de la Vieille École ; mais univoquement la seule possibilité de "re-partitionner un volume" ; l'ancienne possibilité de "repartitionner un disque" ayant été réservée à l'intitulé séparatif : "Effacer" - lequel ne permet plus de recréer une nouvelle Table de Partition avec autant de partitions impliquées que voulu, mais avec exportation par défaut d'une seule partition majeure. Obligeant l'utilisateur à passer à la suite par le menu "Partitionner" pour subdiviser le volume unique ainsi créé au préalable.

Ou : comment l'informatique conduit à la sujétion à l'univocité verbale pragmatique de l'Anglais de l'équivocité spéculative du Français...]

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

☞ Poster le résultat de la commande : diskutil list dans le «Terminal» préconisée par Jean :coucou: permettra ipso facto de dire si le volume actuel du DDE est "re-partitionnable" conservativement (mode "live") : pour cela, il doit être au format HFS+ ; ou s'il n'est pas "re-partitionnable" (conservativement) : parce que le format de son système de fichiers serait FAT ou exFAT.
 
Dernière édition par un modérateur:
L'implication de ce repartitionnement de l'espace d'une partition incluant un système de fichiers au format Apple HFS+, est qu'il est toujours conservatif par défaut de la structure formelle du système de fichiers déjà en place, avec donc son catalogue indexant les adresses des données contenues. L'espace de la partition va être rétréci, avec en corollaire dynamique (dit mode "live") un resserrement conservatif du système de fichiers formel contenu, gardant intact le catalogue d'adresses des données, et par suite préservant intégralement l'accessibilité des données écrites à l'espace désormais rétréci. Parallèlement, l'espace dégagé par ce rétrécissement se trouve défini comme une néo-partition, pour laquelle le formateur de système de fichiers crée un système de fichiers vierge au format choisi, avec un catalogue vierge.

=> résumé de ce résumé : je perds toujours tout à re-partitionner un Disque ; je ne perds jamais rien à re-partitionner un Volume (exprimer des craintes à ce sujet est totalement infondé, étant donné la propriété logique du format de système de fichiers HFS+ qui supporte de manière entièrement conservative les re-dimensionnements dynamiques en + ou en - de l'espace-partition support).
:coucou: macomaniac,

Une question : si je repartitionne une partition avec un système de fichiers Apple HFS+, à te lire je ne devrais rien perdre.
Donc si mes données sont éparpillées dans toute la partition (fragmentation importante), puis-je en déduire que Utilitaire de disque (ou autre outil) ne me permettra pas de faire une partition de la taille supérieure à une zone sans aucune données ?

Dit autrement, Utilitaire de disque pourrait refuser que je partitionne ma partition (c'est moche écrit comme ça !!) en deux parties égales si jamais j'ai des données réparties dans toute la partition. c'est bien cela ?
 
À mon avis non. Utilitaire de disques va gérer les données et les adapter à la nouvelle taille.
 
À mon avis non. Utilitaire de disques va gérer les données et les adapter à la nouvelle taille.
Tu penses qu'Utilitaire de disque pourrait faire une défragmentation, de manière à allouer suffisamment de place continue pour pouvoir, à la fin, partitionner comme demandé ?
 
À prendre comme une "spéculation raisonnée"

:coucou: Sly

Une question : si je repartitionne une partition avec un système de fichiers Apple HFS+, à te lire je ne devrais rien perdre.
Donc si mes données sont éparpillées dans toute la partition (fragmentation importante), puis-je en déduire que Utilitaire de disque (ou autre outil) ne me permettra pas de faire une partition de la taille supérieure à une zone sans aucune données ?

Dit autrement, Utilitaire de disque pourrait refuser que je partitionne ma partition (c'est moche écrit comme ça !!) en deux parties égales si jamais j'ai des données réparties dans toute la partition. c'est bien cela ?

En termes pratiques (= ça le fait ou pas ?) --> je répondrais comme Jean (avec, comme lui, de nombreuses expérimentations comme preuves) : si le système de fichiers HFS+ contenu dans une partition est logiquement "sans erreur" (= exit code 0 à la vérification), alors une commande de re-partitionnement (graphique ou textuelle) sera toujours honorée sans échec, ce en mode conservatif du système de fichiers préalable, avec l'intégralité de sa gestion des données incluses). Qu'il y ait ou non "fragmentation".

En termes théoriques (= comment est-ce possible  dans tous les cas de figure ?) --> je veux bien (quoique non informaticien) me risquer à des spéculations, à partir du seul fait que je parle Français et ai donc à ma disposition la langue spéculative par excellence (car l'équivocité de sens des mots du Français délègue a priori à la liberté créatrice des phrases le soin de produire des significations déterminées : ce qu'on appelle bonnement "penser")...

Spinoza dit quelque part dans l'«Éthique» : « L'ordre et la connexion des choses sont les mêmes que l'ordre et la connexion des idées ». Tu es donc spinoziste lorsque tu te représentes une corrélation terme à terme des « idées » (terme ici pour "données") et des « choses » (terme ici pour "localisations"). Ce qui t'amène à la question : si mes données sont dispersées, à l'intérieur de l'étendue globale d'une partition, dans des localisations aléatoires, comment l'étendue de cette partition peut-elle être rétrécie de moitié par exemple (si la taille des données globales le permet) sans un travail préalable d'« agglutination » des localisations de données pour les regrouper dans l'espace de la partition de tête rétrécie si l'on veut qu'il y ait conservation et pas destruction (au moins de toute une partie des données) ?

Vu comme cela, il est logique de se poser cette question, et même de concevoir un paradoxe à l'opération de re-partitionnement conservatif d'un volume.

Je me contente alors de proposer (spéculativement parlant) une représentation alternative dans le respect du principe spinoziste invoqué.

Une Table de Partition met en correspondance avec l'espace physique du disque (constitué de cellules porteuses de bits : 1 vs 0) une « abstraction » : celle d'une série de blocs logiques (chacun correspondant à 8 bits physiques) numérotés séquenciellement de 1 à 1 000 000 (supposons), une partition particulière étant définie comme une suite numérique continue de blocs entre 2 limites numérales de la série totale (par exemple du 1000è bloc comme commencement au 100 000è bloc comme terminaison). J'ai donc une partition dont l'espace logique contient 100 000 blocs numérotés séquenciellement et aucun autre. Une "donnée" (selon sa taille plus ou moins grande) va correspondre à une série de blocs à la suite, le titre du fichier correspondant au bloc de départ de la série, par exemple une première donnée de 56 blocs du 1000è bloc au 1056è de ma partition 1000 --> 100 000. Si j'ajoute une donnée de 5 blocs, sans que rien n'ait varié dans les données antérieures, elle va s'écrire naturellement du 1056è au 1060è bloc. Mais les données sont évolutives : il est possible d'en supprimer, ou de les rétrécir. Si ma première donnée rétrécit de 5 blocs, les blocs 1051 à 1056 se libèrent. Si je veux écrire une 3è donnée de 10 blocs, elle va alors s'écrire pour 5 blocs du 1051 au 1056è et pour cinq autres blocs du 1061 au 1065è bloc.

Il y a donc ce que tu appelles "fragmentation logique" de l'association "données <=> blocs", mais tu noteras qu'un ordre est respecté dans la gestion de ce "désordre", puisque les blocs "libres" ou "libérés" sont utilisés sériellement et pas aléatoirement : ma 3è donnée de 10 blocs ne va pas aller s'écrire sur les blocs 90 456 à 90 465è sous prétexte qu'ils sont libres dans ma partition 1000 => 100 000, mais se répartir entre le trou de 5 blocs libéré et les 5 blocs libres au contact du dernier occupé.

Ce principe de contiguïté numérique des blocs de données logiques, quand bien même il implique des procédés de "bouche-trous" lorsque des blocs de données occupées se trouvent libérés par la destruction des données antérieures, correspond à une occupation "rationnelle" des blocs logiques par des données, au lieu d'une ventilation anarchique à toute suite de blocs libres dans la série totale des blocs de la partition. Je me figure que cet ordre séquentiel dans le choix des blocs libres pour y loger des données (du type : la série des blocs immédiatement contigus au dernier occupé, exception faite des blocs numériquement antérieurs libérés qui peuvent être remplis) proscrit une dispersion stochastique d'occupation des blocs par des données et impose un principe déterministe d'emploi d'une série de blocs 1000è => 100 000è correspondant (par exemple) à une partition.

C'est le rôle du catalogue B-tree, bâti selon le principe d'une arborescence, chaque embranchement double ou triple porteur d'une clé numérique simple ou double, que de gérer l'allocation des données à des blocs. C'est un arbre "vivant", au sens où il est en évolution et remaniements perpétuels, mais que je ne me figure pas s'en aller essaimer des branches sur des suites de blocs complètement sans contiguïté numérique, au point de comporter des feuilles (les données terminales) dispersées n'importe où dans la série complète des blocs de la partition comme des feuilles d'automne dispersées au sol par le vent. Tant que les feuilles tiennent à l'arbre B-tree, elles poussent selon un principe déterministe d'occupation continue des blocs - impliquant les "bouche-trous" - et pas stochastique.

Par voie de conséquence, le repartitionnement est immédiatement possible, dès lors qu'à un moment donné, par exemple, la série de blocs 56 000è => 100 000è est vacante. Si tel n'était pas le cas, il faudrait en préalable à tout re-partitionnement d'une partition correspondant à une série de blocs, un travail lourd de recopie des données ventilées aléatoirement sur les blocs de fin de la série aux blocs libres les plus élevés dans la série, avant effacement libérant les blocs de queue de leur occupation par une adresse de données. Travail logique lourd analogue à un clonage et qui découragerait de re-partitionner un volume. Manifestement non requis, puisqu'un repartitionnement "live" conservatif s'effectue en un temps des plus bref.
 
Dernière édition par un modérateur: