10.15 Catalina B-tree node sur disque dur externe

[Venkman]

Bonjour à tous,

Ceci est mon premier message sur le forum, et je m'excuse d'avance s'il n'est pas au bon endroit.

L'autre jour mon disque dur externe s'est déconnecté tout seul de mon iMac, et depuis il ne monte plus. Le SOS dans l'utilitaire de disque me renvoie ceci :

Réparation du système de fichiers.
Le volume est déjà démonté.
Exécution de fsck_hfs -fy -x /dev/rdisk2s2
Vérification du volume HFS Plus journalisé.
Taille de nœud B-tree non valide
Le volume n’a pas pu être vérifié entièrement.
Le code de sortie de la vérification du système de fichiers est 8.
Rétablissement de l’état original : démonté.
La vérification ou la réparation du système de fichiers a échoué. : (-69845)

En le passant sous M3 data recovery, tous mes fichiers sont bien présents et il peut les restaurer... pour 80$ de licence.
Avant d'investir, je voulais m'assurer qu'il n'y ait pas un moyen plus simple.

En cherchant sur le net, j'ai appris qu'il fallait faire une commande fsck après avoir rédémarré en single user only .... mais là j'ai un pb : lorsque que je lance ce mode avec CMD+S, j'ai bien un texte blanc qui défile, j'arrive sur la page pour le loguer, une fois que c'est fait j'ai de nouveau un txt blanc sur fond noir, puis une barre de progression se lance et me voilà sur mon bureau... je n'ai pas accès à ce que tout le monde semble avoir.

Je m'en remet à vous pour m'aider, où même me dire où chercher, pour pouvoir débloquer mon disque dur et récupérer mes fichiers.

Merci d'avance et bonne journée à vous tous

Romain

 

[Moonwalker]

Le fsck -fy via le mode Single User (cmd S) c'est pour le disque interne.

Si tu as un DD externe il faut utiliser l'utilitaire de disque ou le fsck -fy depuis le Terminal de ta session.

Sinon, en outil gratuit tu as TestDisk. Je ne sais pas s'il fonctionne avec Catalina (because 64 bits).

 

[Venkman]

Si tu as un DD externe il faut utiliser l'utilitaire de disque ou le fsck -fy depuis le Terminal de ta session.

J'obtiens ça :

fsck usage: fsck [-fdnypqL] [-l number]

J'essai

sudo fsck_hfs -fy /dev/disk3s2

J'obtiens :

** /dev/rdisk3s2
   Executing fsck_hfs (version hfs-522.100.5).
** Checking Journaled HFS Plus volume.
   Invalid B-tree node size
(3, 0)
** The volume   could not be verified completely.

Et j'ai essayer de lancer testdisk, mais ça ne donne rien :

~ % /Users/romaindrouet/Downloads/testdisk-7.2-WIP/testdisk ; exit;
zsh: bad CPU type in executable: /Users/romaindrouet/Downloads/testdisk-7.2-WIP/testdisk

--------------------------------
Note du modérateur de service (ici Aliboron) :
Merci de mettre les copies de compte-rendus de Terminal entre des balises de "Bloc de code". On les trouve dans la barre d'outils, en dessous des trois petits points :

​

 

[baron]

Data Rescue te permettra de récupérer le contenu de tes fichiers mais pas leur organisation (dossiers, dates et noms de fichiers).

Quitte à dépenser, DiskWarrior devrait, lui, te permettre de rétablir la structure logique de ton disque et ainsi tout retrouver bien rangé. Lis bien la documentation pour t'en assurer (notamment la compatibilité Catalina).

 

[Membre supprimé 1060554]

Bonsoir Venkman

Je me borne à une glose explicative -->

- le système de fichiers jhfs+ (Mac OS étendu journalisé) est un dispositif inscrit sur les blocs de tête de la partition => qui est le formateur du volume sur la partition et le gestionnaire de ses fichiers. Ce système de fichiers se décompose en une série de sous-fichiers dédiés chacun à une tâche spécialisée. Il y a ainsi le fichier des blocs en excès > des attributs étendus > le fichier bitmap etc.​

​

- le fichier cardinal est le fichier du catalogue dit : B-tree catalog file. Ce fichier gère les accès aux données du volume en lecture > édition > ajout > suppression. Il est dit de type B-tree car les accès aux données terminales sont gérées par un dispositif en forme d'arborescence (arbre de dérivation) > qui part d'une entrée unique et se déploie via une série de bifurcations (parfois trifurcations). Une bifurcation est appelée nœud (node) et porte une clé numérique (toutes les données terminales ayant aussi un indicateur numérique). À supposer qu'il faille accéder à un fichier terminal indexé 66850 > le processus d'accès parvenu à un nœud portant la clé numérique 5210 va automatiquement empunter la branche dite "haute" = conduisant à des valeurs d'indexation de fichiers supérieures à 5210. S'il fallait chercher un fichier indexé 3471 > le processus d'accès emprunterait automatiquement la branche dite "basse" = conduisant à des valeurs d'indexation inférieures à 5210. La validité des nœuds de l'arbre B-tree du catalogue est donc décisive. Une erreur de nœud dans le catalogue est la plus grave des erreurs pour le système de fichiers jhfs+. Elle invalide de parcours toutes les branches de l'arbre de dérivation qui descendent à partir du nœud et par là met hors jeu des pans entiers de données terminales. Ton erreur :​

Invalid B-tree node size

• est une pareille erreur de nœud dans la structure B-tree du catalogue. Elle est irrécupérable. Le volume est perdu > au sens où il ne peut pas être monté pour accès à ses fichiers. Je te renvoie aux contributions précédentes de Monnwalker & de baron en ce qui concerne des utilitaires de récupération de données (ils scannent les blocs de la partition concernée à la recherche de fichiers identifiables > sans passer par le système de fichiers invalide).

 

[baron]

Quitte à dépenser, DiskWarrior devrait, lui, te permettre de rétablir la structure logique de ton disque et ainsi tout retrouver bien rangé. Lis bien la documentation pour t'en assurer (notamment la compatibilité Catalina).

J'ai pris le temps d'aller voir :
DiskWarrior est bien approprié à ton cas ; il peut reconstruire le système de fichiers d'un disque externe HFS+ sous Catalina.
• https://www.alsoft.com/

C'est un peu cher mais c'est le meilleur logiciel pour ce cas de figure.

 

[The Jibest]

La validité des nœuds de l'arbre B-tree du catalogue est donc décisive. Une erreur de nœud dans le catalogue est la plus grave des erreurs pour le système de fichiers jhfs+. Elle invalide de parcours toutes les branches de l'arbre de dérivation qui descendent à partir du nœud et par là met hors jeu des pans entiers de données terminales.

@macomaniac

Je ne me lasse pas de tes explications, celle-là m'interpelle d'autant plus suite à ma récente aventure pour verrouiller le jhfs+ sur mes volumes interne et externes, justement pour avoir la capacité de lancer DiskWarrior.

https://www.alsoft.com/diskwarrior5apfs?rq=apfs?from=gyagbbb3 lien rappelé par @Sly54 dans un autre post confirme qu'il vaut mieux oublier DiskWarrior en APFS.

J'ai donc une question, quid d'APFS concernant cette erreur fatale à jhfs+ ?

J'imagine que dans la (r)évolution qu'il représente, APFS a anticipé ce type d'erreur avec une autre hiérarchie ? ou pas ?

 

[Membre supprimé 1060554]

Bonjour TJ

Le système de fichiers jhfs+ est une structure logicielle composée d'une série de sous-fichiers gestionnaires : le fichier des attributs étendus > le fichier des blocs en excès > le fichier des liens multiples > le fichier d'allocation des blocs > le fichier du catalogue. De ces fichiers > celui du catalogue (dit : catalogue B-tree à cause de son organisation en arbre de dérivation) est le plus important et le plus sensible à l'erreur. L'erreur de nœud (= point de bifurcation de l'arbre du B-tree) est l'erreur capitale. Elle invalide le parcours des branches de l'arbre dépendant de la bifurcation => vers les feuilles (données) terminales. Des pans entier de données deviennent donc inacessibles en lecture > édition > ajout > suppression. Ça suffit couramment à invalider le montage du volume formé par le jhfs+ > ou du moins à précipiter son montage en lecture seule.

- le système de fichiers apfs est une structure logicielle beaucoup plus complexe et inscrutable > qui constitue (comme l'était précédemment le format CoreStorage) un système de stockage virtulisant des volumes à partir d'un magasin primaire. Donc dans la partition apfs de base réside un magasin primaire appelé Physical Store > et de ce magasin se trouve virtualisé un espace-disque secondaire appelé Conteneur > supportant des volumes virtuels (de démarrage et auxiliaires). Le magasin primaire (l'infrastructure) échappe à l'examen > seul ce qui est virtualisé à partir de lui (superstructure) est vérifiable car susceptible d'erreurs. Le Conteneur comporte des composants qui sont principalement : le super-bloc > le gestionnaire des blocs (spaceman) et la carte des objets. Les volumes dépendent de composants qui sont principalement : la carte des objets (encore) > les métadonnées de snapshots > le formateur du volume (fsroot tree). Le catalogue B-tree me paraît remplacé par la carte des objets (dont je ne sais si elle a gardé une structure d'arbre de dérivation B-tree ou pas).​

Bref : tu as affaire à 2 structures logiques sans commune mesure. Il n'est pas étonnant que DiskWarrior ne supporte pas de réparation de l'apfs. D'autant que l'apfs est une structure d'une complexification logicielle croissante dans le temps (ainsi le dernier OS Big Sur comporte 6 volumes interdépendants - dont un volume-Système hors norme ne servant plus à démarrer mais de patron pour la création d'un clone instantané de démarrage).

 

[baron]

Les volumes dépendent de composants qui sont principalement : la carte des objets (encore) > les métadonnées de snapshots > le formateur du volume (fsroot tree). Le catalogue B-tree me paraît remplacé par la carte des objets (dont je ne sais si elle a gardé une structure d'arbre de dérivation B-tree ou pas).

La structure sous-jacente est toujours semble-t-il du type B-tree :

Volume​

An APFS volume contains file system directory structures, file metadata and file content. Each has its own superblock, which contains the location of the root file system tree, the extent reference tree, and the snapshot metadata tree, as well as the volume object map. The trees used are, as in HFS+, B-trees. For example, a directory in the file system consists of an inode record, several directory entry records, and an extended attributes record.​

[…]​

​

​

Source : https://eclecticlight.co/2020/10/08/inside-the-file-system-3-apfs-containers-and-volumes/​

Le risque de corruption de ces structures devrait toutefois être réduit par rapport à l'HFS+ du fait qu'en cas de changement aux fichiers, au lieu d'écrire à la place de ce qu'il y avait – avec le risque d'etre interrompu en cours d'écriture, et donc de se retrouver avec un mic-mac de vieux et de neuf –, le système écrit ailleurs ce qu'il y a de neuf puis déclare qu'on peut « oublier » l'ancienne version.
(C'est beaucoup mieux détaillé dans cet article : http://dtrace.org/blogs/ahl/2016/06/19/apfs-part5/ )

 

[The Jibest]

Salut @macomaniac

J'ai loupé ton excellente réponse qui répond bien à ce que je me demandais, en particulier pourquoi DiskWarrior n'avait pas proposé de pérennité.

J'ai lu qu'en fait, cette complexité logicielle que tu évoques n'était pas suffisamment documentée par la pomme d'où l'incapacité des développeurs tiers.

Merci @baron pour ce lien que j'essaie d'assimiler tranquillement. L'introduction situe bien le souci à traiter : l'intégrité de nos données, surtout dans le cas d'un disque unique dans nos ordinateurs.