10.12 Sierra Disque TM USB qui ne monte plus (sauf sur Linux)

[kmsh]

Bonjour à tous,

J'ai un problème que je pense exotique et que je n'arrive pas à résoudre (pas faute d'avoir cherché pourtant).

Je fais mes sauvegardes TM sur deux disques, 1 qui reste chez moi et l'autre qui voyage avec moi.
Actuellement, l'un des deux est aux abonnés absents.
Il ne monte plus sous OSX, mais est visible dans l'utilitaire de disque, ce dernier ne détecte aucun problème et à l'écoute le disque ne fait pas de bruit bizarre.
La seule chose perturbante, est que l'utilitaire de disque me dit que ce dernier est plein (rempli à 100 %)

voici le diskutil de mon système :
diskutil list

/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *500.3 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_CoreStorage Macintosh HD 499.4 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3

/dev/disk1 (internal, virtual):
#: TYPE NAME SIZE IDENTIFIER
0: Macintosh HD +499.1 GB disk1
Logical Volume on disk0s2
0D061C0E-7072-42C7-826B-85C3D81A3E7E
Unlocked Encrypted


/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *2.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_HFS TimeMachine 2To 2.0 TB disk2s2


/dev/disk3 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme +19.7 MB disk3
1: Apple_partition_map 32.3 KB disk3s1
2: Apple_HFS Flash Player 19.7 MB disk3s2


/dev/disk4 (external, physical):

#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *1.0 TB disk4
1: EFI EFI 209.7 MB disk4s1
2: Apple_HFS G-DRIVE mobile USB 999.9 GB disk4s2

en gras, mes deux disques TM, celui qui pose problème est le disk4.

Etrangement, je peut le monter sur Linux (en read only) et je vois correctement toute la structure du disque, le backups.backupdb, etc.

Voilà, ça m'ennuie de l'effacer sans comprendre pourquoi il ne monte plus, les SOS disques et autres n'ayant rien donné, ni sur ce mac ni sur un autre.

Merci d'avance à tous.

K.


MBPro 2015 Retina : 512/16. OSx 10.11

 

[Membre supprimé 1060554]

Salut kmsh

Ton DDE G-DRIVE mobile USB attaché au Mac > passe dans le «Terminal» la commande :

df -H

qui appelle l'utilitaire df (display_free-space) avec l'option -H (Human_readable : retourner des valeurs humainement lisibles : MB, GB) > en retour, tu vas voir s'afficher le tableau des volumes montés > avec pour chaque volume une ligne affichant : sa capacité totale > la taille de l'espace occupé > la taille de l'espace libre > le pourcentage de ce dernier.

=> tu n'as qu'à poster ce tableau en copier-coller ici (comme tu l'as fait précédemment) > les informations concernant le volume G-DRIVE mobile USB devraient trancher la question de la quantité de données recelées.

 

[Deleted member 1099514]

Salut.
Que te renvoie dans le terminal un :
sudo tmutil destinationinfo

 

[kmsh]

Salut.
Que te renvoie dans le terminal un :
sudo tmutil destinationinfo

==================================================

Name : TimeMachine 2To

Kind : Local

Mount Point : /Volumes/TimeMachine 2To

ID : D9B99175-956B-4496-A969-70A70DA85083

====================================================

Name : G-DRIVE mobile USB

Kind : Local

ID : 4B28D865-E7B5-4328-8CF5-FE447CDF394B

 

[kmsh]

Salut kmsh

Ton DDE G-DRIVE mobile USB attaché au Mac > passe dans le «Terminal» la commande :

df -H

qui appelle l'utilitaire df (display_free-space) avec l'option -H (Human_readable : retourner des valeurs humainement lisibles : MB, GB) > en retour, tu vas voir s'afficher le tableau des volumes montés > avec pour chaque volume une ligne affichant : sa capacité totale > la taille de l'espace occupé > la taille de l'espace libre > le pourcentage de ce dernier.

=> tu n'as qu'à poster ce tableau en copier-coller ici (comme tu l'as fait précédemment) > les informations concernant le volume G-DRIVE mobile USB devraient trancher la question de la quantité de données recelées.

justement, on ne le voit pas puisqu'il ne se monte pas ...
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on

/dev/disk1 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /

devfs 388Ki 388Ki 0Bi 100% 1342 0 100% /dev

map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net

map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home

/dev/disk2s2 1.8Ti 1.7Ti 124Gi 94% 10763844 4284203435 0% /Volumes/TimeMachine 2To

Sookasa@osxfuse0 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /Users/xxxx/Dropbox/Sookasa

Boxcryptor@bcfs0 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /Volumes/Secomba/xxxxx/Boxcryptor

 

[Deleted member 1099514]

Je tenterai de forcer un backup :
sudo tmutil startbackup -auto -destination 4B28D865-E7B5-4328-8CF5-FE447CDF394B

Si ça ne fonctionne pas tente ce qui suit :

sudo tmutil removedestination 4B28D865-E7B5-4328-8CF5-FE447CDF394B

Puis :
sudo tmutil setdestination /Volumes/"G-DRIVE mobile USB"
Normalement les données devraient être préservées sur le 1 TO, mais je n'assure rien.

 

[Deleted member 1099514]

justement, on ne le voit pas puisqu'il ne se monte pas ...
Filesystem Size Used Avail Capacity iused ifree %iused Mounted on

/dev/disk1 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /

devfs 388Ki 388Ki 0Bi 100% 1342 0 100% /dev

map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net

map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home

/dev/disk2s2 1.8Ti 1.7Ti 124Gi 94% 10763844 4284203435 0% /Volumes/TimeMachine 2To

Sookasa@osxfuse0 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /Users/xxxx/Dropbox/Sookasa

Boxcryptor@bcfs0 465Gi 360Gi 104Gi 78% 2075301 4292891978 0% /Volumes/Secomba/xxxxx/Boxcryptor

Que te renvoie un
diskutil mount disk4s2

 

[kmsh]

Que te renvoie un
diskutil mount disk4s2

Diskutil mount disk4s2
Volume on disk4s2 failed to mount
If the volume is damaged, try the "readOnly" option

(idem avec le readOnly)

 

[kmsh]

Je tenterai de forcer un backup :
sudo tmutil startbackup -auto -destination 4B28D865-E7B5-4328-8CF5-FE447CDF394B

Si ça ne fonctionne pas tente ce qui suit :

sudo tmutil removedestination 4B28D865-E7B5-4328-8CF5-FE447CDF394B

Puis :
sudo tmutil setdestination /Volumes/"G-DRIVE mobile USB"
Normalement les données devraient être préservées sur le 1 TO, mais je n'assure rien.

sudo tmutil startbackup -auto -destination 4B28D865-E7B5-4328-8CF5-FE447CDF394B
tmutil: Invalid destination ID.

sudo tmutil removedestination 4B28D865-E7B5-4328-8CF5-FE447CDF394B (ca passe)
sudo tmutil setdestination /Volumes/"G-DRIVE mobile USB"
/Volumes/G-DRIVE mobile USB: Invalid destination path. (error 22)
The backup destination could not be set.

 

[Deleted member 1099514]

Tente :
diskutil repairdisk disk4
diskutil repairvolume disk4s2

 

[kmsh]

Tente :
diskutil repairdisk disk4
diskutil repairvolume disk4s2

diskutil repairdisk disk4

Repairing the partition map might erase disk4s1, proceed? (y/N) Y
Started partition map repair on disk4
Checking prerequisites
Checking the partition list
Adjusting partition map to fit whole disk as required
Checking for an EFI system partition
Checking the EFI system partition's size
Checking the EFI system partition's file system
Checking the EFI system partition's folder content
Checking all HFS data partition loader spaces
Checking booter partitions
Reviewing boot support loaders
Checking Core Storage Physical Volume partitions
Updating Windows boot.ini files as required
The partition map appears to be OK
Finished partition map repair on disk4

et

diskutil repairvolume disk4s2
Started file system repair on disk4s2 G-DRIVE mobile USB
Repairing file system
Checking Journaled HFS Plus volume
Checking extents overflow file
Checking catalog file
Checking multi-linked files
Checking catalog hierarchy
Checking extended attributes file
Checking multi-linked directories
Checking volume bitmap
Checking volume information
The volume G-DRIVE mobile USB appears to be OK
File system check exit code is 0
Updating boot support partitions for the volume as required
Finished file system repair on disk4s2 G-DRIVE mobile USB

mais ça change rien. bon tant pis... j'aurais aimé savoir pourquoi ça foire

 

[Deleted member 1099514]

Aurais tu un autre boîtier pour y mettre le disque ?
As-tu tenté de changer le câble USB ?

 

[Membre supprimé 1060554]

Salut encore kmsh

j'aurais aimé savoir pourquoi ça foire

« Felix, qui potuit rerum cognoscere causas » (Géorgiques - heureux celui qui a pu pénétrer la raison des choses)

Tout ce que je peux tenter de faire ici, en ce qui me concerne, c'est exercer l'art de l'herméneutique : discipline non exacte consistant à pallier l'ignorance par le discours.​

L'espace d'une partition est défini logiquement comme un alignement de blocs (de 512 octets) entre 2 limites (le bloc de départ et le bloc de fin). L'en-tête des blocs d'une partition porte un système de fichiers : une suite de fichiers gestionnaires de l'espace restant des blocs de la partition (dont un fichier du catalogue, dit catalogue B-tree). Les blocs bruts de la partition équivalent à des paquets de 4096 bits considérés soit comme écrits, soit comme disponibles. Les blocs considérés comme écrits sont intrinsèquement illisibles, d'un point de vue humain. Un des rôles du système de fichiers gestionnaire est d'opérer une conversion de cet espace brut de blocs illisibles en un espace formellement lisible : un espace de répertoire dans lequel les écritures de blocs bruts se présentent comme des fichiers lisibles par des applications dédiées. Cet espace de répertoire, présentant les écritures des blocs bruts sous la forme de fichiers lisibles, est un volume monté.

On dira donc qu'un système de fichiers monte en volume l'espace brut des blocs de la partition. Lorsqu'un système de fichiers ne peut pas monter en volume (càd. donc présenter sous la forme d'un répertoire de fichiers lisibles) les blocs de la partition gérée > les écritures des blocs restent inaccessibles. C'est manifestement le cas en ce qui concerne la partition disk4s2 de ton DDE (section 2 du disque 4).

Quelles sont les raisons qui font que le système de fichiers d'une partition ne parvient pas à monter en volume l'espace des blocs d'une partition ? - il peut y en avoir (comme toujours) de plusieurs sortes =>

- Des erreurs majeures peuvent affecter le système de fichiers (par exemple des erreurs de catalogue), càd. un dysfonctionnement interne à l'outil gestionnaire --> ce n'est pas le cas chez toi, puisqu'une commande diskutil repairVolume (spécialisée dans la vérification / réparation des systèmes de fichiers) a retournée un :

The volume G-DRIVE mobile USB appears to be OK
File system check exit code is 0

où exit code = 0 signifie qu'aucune erreur n'a été trouvée > donc le système de fichiers de la partition disk4s2 est fonctionnel.


- Des erreurs peuvent affecter la table de partition du disque : il s'agit là de fichiers inscrits sur les tous premiers blocs du disque, qui décrivent les partitions du disque et leurs systèmes de fichiers (une espèce de catalogue des catalogues) en permettant l'attachement logique du disque et le chargement des systèmes de fichiers. La commande diskutil repairDisk en charge de la vérification / réparation des cartes de partition de disques a retourné un :

The partition map appears to be OK
Finished partition map repair on disk4

càd. n'a décelé aucune erreur dans la table de partition GPT (GUID Partition Table) gestionnaire du disque complet.


- Des dysfonctionnements matériels peuvent empêcher le traitement brut des données par le processeur (nappe défaillante ou bras de lecture du disque défaillant). Je ne pense pas que ce soit le cas, car des messages d'« input / ouput error » interviennent alors.


- Reste un dernier cas, que je conjecture caractériser ta partition : si jamais la part des blocs considérés comme « écrits » atteint la limite des 100% de l'espace disponible de la partition > alors le système de fichiers se trouve bloqué dans sa fonction de montage en volume des écritures, càd. de leur affichage comme fichiers relevant d'un espace de répertoire. En gros : saturation de l'espace à traiter. Une marge d''espace "vide" (d'écritures identifiées), ou encore "libre", est nécessaire dans une partition pour que le système de fichiers gestionnaire puisse opérer le montage du volume. Je me figure que dans ton cas ce « passage à la limite » est intervenu et que le système de fichiers est figé.​

Pourquoi le volume monte-t-il si le disque se trouve attaché à un Système Linux > et pas s'il est attaché à un Système OS X (encore qu'il ne monte qu'en lecture seule avec Linux) ? - ce genre de détail dans les raisons m'échappe, car je ne suis pas informaticien. Pourquoi l'application Time Machine n'a-t-elle pas rempli son office automatique de suppression des sauvegardes les plus anciennes afin de laisser de la marge d'espace disponible dans le volume ? - pareil.

=> en résumé : il n'y a plus rien à faire.

 

[kmsh]

Salut encore kmsh

« Felix, qui potuit rerum cognoscere causas » (Géorgiques - heureux celui qui a pu pénétrer la raison des choses)

Tout ce que je peux tenter de faire ici, en ce qui me concerne, c'est exercer l'art de l'herméneutique : discipline non exacte consistant à pallier l'ignorance par le discours.​

L'espace d'une partition est défini logiquement comme un alignement de blocs (de 512 octets) entre 2 limites (le bloc de départ et le bloc de fin). L'en-tête des blocs d'une partition porte un système de fichiers : une suite de fichiers gestionnaires de l'espace restant des blocs de la partition (dont un fichier du catalogue, dit catalogue B-tree). Les blocs bruts de la partition équivalent à des paquets de 4096 bits considérés soit comme écrits, soit comme disponibles. Les blocs considérés comme écrits sont intrinsèquement illisibles, d'un point de vue humain. Un des rôles du système de fichiers gestionnaire est d'opérer une conversion de cet espace brut de blocs illisibles en un espace formellement lisible : un espace de répertoire dans lequel les écritures de blocs bruts se présentent comme des fichiers lisibles par des applications dédiées. Cet espace de répertoire, présentant les écritures des blocs bruts sous la forme de fichiers lisibles, est un volume monté.

On dira donc qu'un système de fichiers monte en volume l'espace brut des blocs de la partition. Lorsqu'un système de fichiers ne peut pas monter en volume (càd. donc présenter sous la forme d'un répertoire de fichiers lisibles) les blocs de la partition gérée > les écritures des blocs restent inaccessibles. C'est manifestement le cas en ce qui concerne la partition disk4s2 de ton DDE (section 2 du disque 4).

Quelles sont les raisons qui font que le système de fichiers d'une partition ne parvient pas à monter en volume l'espace des blocs d'une partition ? - il peut y en avoir (comme toujours) de plusieurs sortes =>

- Des erreurs majeures peuvent affecter le système de fichiers (par exemple des erreurs de catalogue), càd. un dysfonctionnement interne à l'outil gestionnaire --> ce n'est pas le cas chez toi, puisqu'une commande diskutil repairVolume (spécialisée dans la vérification / réparation des systèmes de fichiers) a retournée un :

The volume G-DRIVE mobile USB appears to be OK
File system check exit code is 0

où exit code = 0 signifie qu'aucune erreur n'a été trouvée > donc le système de fichiers de la partition disk4s2 est fonctionnel.


- Des erreurs peuvent affecter la table de partition du disque : il s'agit là de fichiers inscrits sur les tous premiers blocs du disque, qui décrivent les partitions du disque et leurs systèmes de fichiers (une espèce de catalogue des catalogues) en permettant l'attachement logique du disque et le chargement des systèmes de fichiers. La commande diskutil repairDisk en charge de la vérification / réparation des cartes de partition de disques a retourné un :

The partition map appears to be OK
Finished partition map repair on disk4

càd. n'a décelé aucune erreur dans la table de partition GPT (GUID Partition Table) gestionnaire du disque complet.


- Des dysfonctionnements matériels peuvent empêcher le traitement brut des données par le processeur (nappe défaillante ou bras de lecture du disque défaillant). Je ne pense pas que ce soit le cas, car des messages d'« input / ouput error » interviennent alors.


- Reste un dernier cas, que je conjecture caractériser ta partition : si jamais la part des blocs considérés comme « écrits » atteint la limite des 100% de l'espace disponible de la partition > alors le système de fichiers se trouve bloqué dans sa fonction de montage en volume des écritures, càd. de leur affichage comme fichiers relevant d'un espace de répertoire. En gros : saturation de l'espace à traiter. Une marge d''espace "vide" (d'écritures identifiées), ou encore "libre", est nécessaire dans une partition pour que le système de fichiers gestionnaire puisse opérer le montage du volume. Je me figure que dans ton cas ce « passage à la limite » est intervenu et que le système de fichiers est figé.​

Pourquoi le volume monte-t-il si le disque se trouve attaché à un Système Linux > et pas s'il est attaché à un Système OS X (encore qu'il ne monte qu'en lecture seule avec Linux) ? - ce genre de détail dans les raisons m'échappe, car je ne suis pas informaticien. Pourquoi l'application Time Machine n'a-t-elle pas rempli son office automatique de suppression des sauvegardes les plus anciennes afin de laisser de la marge d'espace disponible dans le volume ? - pareil.

=> en résumé : il n'y a plus rien à faire.

C'est bel et bien ce que je pensais, je vous remercie de cet herméneutique artisanal et je vous passe le bonsoir

 

[bompi]

C'est l'ennui avec les logiciels un peu trop sophistiqués (TM) et pratiquement pas documentés...

Avec Linux, as-tu essayé de monter le volume en RW, éventuellement en le forçant (avec la commande mount) ? Il y a peut-être quelques fichiers à purger sur le volume, suffisamment pour débloquer la situation (genre fichiers cachés de Spotlight à la racine : quelques dizaines de MB pourraient suffire).
Il y a quelques années, Linux montait les partitions HFS+ journalisées en lecture seule. Aujourd'hui les pilotes savent aussi écrire sur HFS+ journalisé (un peu de lecture).

Quoi qu'il en soit, tu pourrais cloner le disque avec Linux en montant un volume HFS+ plus grand et en y recopiant le contenu de Backups.backupdb (comme indiqué ici). Ensuite, sous macOS, tu passes ce nouveau disque en HFS+ journalisé avec l'Utilitaire de Disque (sélectionner la partition, ouvrir le menu Fichier et choisir l'item ad hoc) puis tu dis à TM de prendre ce disque comme nouveau disque. D'après Apple, ça marche... (personnellement, ma confiance est limitée, façon Saint Thomas).

En restant sous OS X, tu peux aussi cloner le disque récalcitrant sur un disque plus grand en utilisant la commande dd qui effectue une copie par bloc (façon Unix) ou une commande un peu plus souple et pratique, plus macOS, asr, avec l'option (le "verb") restore :

asr restore --source /dev/diskXsY --target /dev/diskWsZ

Dans ton cas (cf. ton post #1) X vaut 4 et Y vaut 2 ; W et Z seront définis lors du branchement du nouveau disque.

Normalement, c'est aussi possible avec l'Utilitaire de Disque mais ses dernières versions me sont inconnues.

 

[Membre supprimé 1060554]

Lorsqu'un trop-plein de données ayant bloqué le système de fichiers de la partition d'un disque > il n'est plus possible de monter un volume qui permette la lecture des fichiers - la question se pose : y a-t-il moyen de récupérer ce volume ?

J'exclus le procédé des logiciels de récupération de données, qui marche bien pour retrouver des lots de fichiers graphiques, mais qui est totalement inapte à restaurer l'arborescence d'un volume-Système ou d'une sauvegarde (comme ici).

Comme le blocage d'un tel volume provient du manque d'espace libre dans les blocs gérés par le système de fichiers > parvenir à cloner le "contenu" du container de la source dans un container de destination de plus grande taille semble la solution. Dans le sens où le système de fichiers cloné dans la destination bénéficierait alors de la marge de blocs libres (due à la plus grande taille du container d'accueil) qui lui faisait défaut dans le container de la source.

C'est ainsi que je comprends, bompi, ton paragraphe :

sous OS X, tu peux aussi cloner le disque récalcitrant sur un disque plus grand en utilisant la commande dd qui effectue une copie par bloc (façon Unix) ou une commande un peu plus souple et pratique, plus macOS, asr, avec l'option (le "verb") restore

J'ai plus d'une fois essayé, dans les obscures coulisses de l'expérimentation, de réaliser ce plan avec les deux utilitaires que tu cites (dd & asr), mais aussi avec hdiutil : j'ai échoué dans les 3 cas.

En voici les raisons :

- en ce qui concerne dd : on a affaire à un utilitaire spécialisé dans le clonage bloc à bloc d'une partition source à destination : soit d'une partition pré-existante sur un disque > soit d'une partition d'image-disque créée par la commande. Le problème avec dd, c'est qu'il va cloner exactement les blocs du container-source (blocs du système de fichiers + blocs des données) sur les blocs du container-destination à partir du début constitué par le système de fichiers > de telle façon que, s'il existe dans le container-destination des blocs excédentaires (container plus grand) > ces blocs vont être radicalement neutralisés par virage au statut de NULL_BLOCS (chacun constitué de 4096 null_bits marqués par des *). Il s'ensuit que la taille du container-destination sera exactement celle du container-source, les NULL_BLOCS excédentaires ne constituant aucun espace libre, mais un non espace disque (hors système de fichiers).

=> en conséquence : le système de fichiers cloné dans le container-destination se trouve tout aussi à court d'espace libre que son paradigme du container-source > tout aussi bloqué que lui, il ne monte donc pas de volume.

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

- en ce qui concerne asr : encore un utilitaire spécialisé dans le clonage bloc à bloc, un ©Apple celui-là (apple_software_restore). Son énorme avantage sur dd : il est capable de cloner les blocs d'une source dans un container-destination de plus vaste capacité, sans neutraliser au statut de NULL_BLOCS l'espace excédentaire > mais au contraire en en faisant une extension d'espace libre du système de fichiers cloné. On tiendrait donc ici la solution au problème. Sauf que... pour opérer ce chef-d'œuvre, asr requiert une condition sine qua non : les 2 partitions de la source et de la destination doivent, au préalable, être montées en volumes > et c'est l'utilitaire qui se charge de démonter ces 2 volumes à sa façon avant de démarrer son procédé de clonage bloc à bloc.

=> asr me paraît donc procéder de manière "hybride", en requérant un mode "volume" préalable avant le mode "blocs bruts" - ce qui, je me le figure, lui permet justement de pouvoir étendre le système de fichiers cloné à tout l'espace du container-disque de destination (à la différence de dd). La difficulté étant que, lorsque justement le problème provient d'une partition qui ne monte plus de volume, asr est inemployable.

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

- en ce qui concerne hdiutil : on a affaire à un utilitaire d'une grande versatilité, dont les compétences s'étendent jusqu'au clonage en mode bloc, si on l'appelle avec le verbe create et l'option -srcdevice (source=device). Alors, la partition peut très bien ne monter aucun volume > elle est aussi clonable en mode bloc qu'avec dd. La destination avec hdiutil étant évidemment une image-disque créée par la commande à l'endroit voulu > le problème qui se reproduit est exactement celui de dd : on obtient une image-disque en taille fixe de type DMG exclusif, dont le container comprend exactement autant de blocs que celui de la source et aucun de plus. Si le système de fichiers du container-source est bloqué par saturation de données > celui de l'image-disque créée par hdiutil le sera aussi et ne montera donc pas de volume.

=> le mode -srcdevice de hdiutil rejette absolument toute option sur l'image-disque de destination créée : aussi bien une option de -type (comme SPARSEIMAGE ou SPARSEBUNDLE) qui créerait un container extensible, qu'une option de -size qui créerait un container plus vaste que celui de la source. En conséquence : l'image-disque créée en destination est un DMG fixe, qui ne supporte pas non plus après coup une opération de type resize qui étirerait son système de fichiers à une dimension d'espace libre..

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

​

En résumé de ces obscures expérimentations (où je ne vis poindre aucun point du jour) : il me paraît manquer un utilitaire qui serait capable d'étirer le système de fichiers d'une source à une dimension d'espace libre ne pré-existant pas dans ce container-paradigme > ce qui permettrait ipso facto de créer un clone débloqué d'un système de fichiers verrouillé par un trop-plein de données...

 

[bompi]

Je n'ai rien sous la main mais je dirais que dd devrait être capable de faire le boulot : j'ai le souvenir d'avoir fait ce genre de choses dans le passé sur des partitions autres que HFS+ (en l'espèce, je sais que je faisais de nombreuses copies d'un master vers des partitions cibles plus grandes sur des stations de travail Sun, avec diverses versions de SunOS/Solaris : la version de dd était peut-être accommodante, le système de fichiers plus souple, allez savoir).
Néanmoins, imaginons que ça ne fonctionne pas directement, on peut quand même essayer ceci : sur un disque destination plus grand, on crée une partition de la taille de celle de la source. On clone en douceur avec dd. On devrait (soyons optimistes) pouvoir ensuite augmenter la taille de la partition destination afin de l'étendre au reste du disque physique. C'est à tester, en tout cas.

Quant à asr, la documentation précise que le volume source comme le volume cible doivent être démontables ou montés en lecture seule. Dans ce cas, essayons de monter la partition pleine en lecture seule, comme sous Linux. Et le reste suivra, si la documentation est correcte.

 

[bompi]

Je n'ai pas de partition dans le triste état de remplissage complet, je fais donc un test avec une partition normale de type HFS+ que je copie vers une autre à l'aide de asr.

C'est en cours mais je peux déjà souligner qu'il ne m'a pas été demandé de monter de partition, ni la source ni la destination : le tout est que les partitions soient accessibles et inoccupées, ce qui est évidemment le cas puisque non montées.

Donc utiliser la méthode indiquée par Apple en prenant un disque cible plus grand doit permettre de se sortir du mauvais pas.

 

[Membre supprimé 1060554]

Je me suis toujours servi d'asr en prenant des volumes montés en source et en destination - si bien que cette routine personnelle a fini par m'apparaître comme une condition exclusive. Or tu as raison : il existe bien une alternative, consistant à prendre en source et en destination les devices des partitions - à condition que leurs volumes soient démontés au préalable.

Un clonage bloc à bloc s'opère vite et bien de la partition source à la partition destination, sans que les blocs excédentaires de la partition destination (si on l'a choisie de plus vaste capacité) ne soient neutralisés, comme avec dd. En utilisant asr d'une partition source démontée vers une partition destination démontée plus vaste, il y a donc un espoir raisonnable de pouvoir remonter en volume à la fin la partition de destination clonée, son système de fichiers ayant récupéré l'espace libre qui lui manquait.

J'ai bien essayé de bloquer expérimentalement le système de fichiers d'une partition de clé USB par saturation de données, mais je n'y suis pas parvenu. Même à 0 ko d'espace libre résiduel, le volume continue de monter. Je ne sais pas comment s'y prennent les plaignants des forums (sur ce point : je les « envie »). Je n'ai pas pu par conséquent vérifier si le procédé asr produit bien dans ce cas de figure un clone débloqué par la capacité plus vaste de la partition d'accueil.

Je note qu'une limitation d'asr par rapport à dd est de n'accepter que des formats de partition jhfs(+) en source et en destination. Si le système de fichiers bloqué d'une partition source était un fat32, par exemple, impossible d'envisager ce procédé. Sinon : à la prochaine occasion sur les forums hop ! test asr...

En ce qui concerne l'autre hypothèse que tu avais envisagée : cloner avec dd d'une partition source à une partition destination d'une taille exactement identique - partition de destination telle qu'un espace libre conséquent existerait en-dessous d'elle sur le disque d'accueil, ce qui permettrait d'envisager après clonage d'étirer le système de fichiers de la destination à l'espace libre subalterne => voici les objections que j'envisage :

- seul un format jhfs+ de système de fichiers est susceptible de re-dimensionnement : le procédé ne pourrait donc marcher que dans ce cas de figure exclusif.

- pour re-dimensionner le système de fichiers d'une partition afin de l'étirer à la gestion d'un espace libre existant en-dessous de cette partition, il est nécessaire de remonter le volume correspondant en préalable de manière à employer la commande diskutil resizeVolume (un verbe resizePartition n'étant pas disponible pour diskutil) => en cas de système de fichiers bloqué par un trop plein de données et incapable de monter un volume, le même blocage se répétant de la source sur la destination de taille identique, on ne pourrait donc pas monter le volume permettant le redimensionnement par ajout de l'espace libre.​

=> il semble bien alors qu'asr concentre tous les espoirs en cas de système de fichiers jhfs+ bloqué par le trop-plein de données...

 

[bompi]

Seconde tentative effectuée durant la nuit : un dd de la même partition source vers la même partition destination.
Pas de problème non plus. J'ai simplement eu à faire une petite réparation de la partition destination : elle monte sans cela mais il est quand même préférable de faire cette réparation qui permet d'indiquer que le nombre de blocs occupés a changé et de s'assurer que le tableau des allocations est à jour.
Dans mon petit exemple la source était de 150 GB (109 GB occupés) et la destination de 319 GB (réinitialisée à zéro).

Je vais refaire cette seconde tentative avec des volumes journalisés (je n'avais pas vérifié ce point) : cela ne devrait pas changer grand-chose mais soyons pragmatiques.