Je suis en mission pour récupérer des fichiers à partir de l'un de mes 2 disques NAS parfaitement fonctionnels, non corrompus et non chiffrés qui étaient auparavant en RAID 1. Le NAS était Patriot Javelin S4, qui (comme je l'ai trouvé à partir de mes recherches ) utilise le faux contrôleur de raid Promise Fasttrack.
Les informations sont très rares à ce sujet, donc pour les googleurs dans la même situation, voici quelques faits sur ce NAS:
- Contrôleur RAID: Promise FastTrack (FakeRaid)
- Système de volume: LVM2
- Système de fichiers: XFS avec une taille de bloc de 64 Ko (65536 octets)
- Arch: processeur AMPC PowerPC 800 MHz, 256 Mo de RAM (grâce aux recherches de Matthew)
Je n'avais qu'un ordinateur Windows 10 et MacOS lors de cette opération, et je n'ai trouvé aucun logiciel capable de monter XFS dans le volume LVM2 (à une exception près, plus d'informations ci-dessous). J'ai dû sortir mon ancien netbook Acer Aspire One et y installer chiot linux (en particulier la saveur lxpup).
Sur chiot linux, j'ai réussi à monter ce système de fichiers à l'aide d'un outil appelé dmraid
. Cet outil a un moyen de monter un volume pdc, qui est son id pour Promise FastTrack. Une fois que j'ai réussi à sauter à travers quelques cerceaux de montage, j'ai eu accès au système de fichiers XFS réel, et à mon grand désarroi, il s'est avéré être une taille de bloc de 64 Ko.
C'est là que j'ai commencé à googler des choses comme "lire la taille du bloc xfs 64kb" et ne parvenir nulle part. Seules quelques réponses disent: "Linux ne peut pas lire les tailles de bloc supérieures à 4 Ko, à moins que vous corrigiez le noyau". Je ne sais pas comment patcher le noyau, et je suis déconcerté qu'il n'y ait aucune sorte d'émulation pour permettre cela.
J'ai mentionné 1 exception parmi les applications qui ne peuvent pas lire cette partition sur Win / Mac. Cette exception était ufsexplorer. C'est une application à 100 $, elle a pu me montrer les fichiers en toute transparence. J'ai copié quelques fichiers prouvant que cela fonctionne, mais la version d'essai ne permet que de copier de petits fichiers.
Je refuse de croire qu'il n'y a pas d'outil open source gratuit de n'importe quel niveau de complexité qui ne puisse pas m'aider à lire des fichiers xfs de 64 Ko.
Ma question est: quelqu'un connaît-il un tel outil? Toutes les instructions spécifiques sur la façon d'obtenir les données en utilisant un ou plusieurs outils, ou la correction du noyau, ou quelque chose d'autre (gratuit) sont grandement appréciées.
Un autre point: je préférerais fortement ne pas avoir à créer des images locales de ces disques (sauf si c'est la seule façon). Après tout, c'est 2 To de données, je n'ai peut-être pas autant d'espace.
PS S'il y a un linux connu que je peux installer sur mon Acer qui peut lire xfs 64kb, c'est une solution viable aussi.
Mise à jour 1 : je viens d'apprendre sur https://www.cgsecurity.org/wiki/TestDisk . Ça vaut peut-être la peine. Je reviendrai une fois que j'aurai eu le temps de l'essayer.
Mise à jour 2 : TestDisk semble reconnaître la présence d'une partition XFS, mais je ne sais pas comment procéder à partir de là. Je ne vois pas de moyen d'extraire un fichier, alors je l'ai juste abandonné pour l'instant et j'ai essayé l'approche qemu dans la réponse de Matthew.
Réponses:
J'ai fait un peu de recherche sur votre problème. Pas facile mais semble faisable.
Le domaine du code qui vous brise est le suivant (enfin, dans les noyaux plus récents):
fs/xfs/libxfs/xfs_sb.c
Cela nécessite essentiellement que la taille du bloc XFS soit au moins égale à la taille de la page du système.
Cela signifie deux choses.
Je suis allé vérifier un très vieux noyau (EL4) et cette restriction ci-dessus était toujours là. Cela signifie qu'il est fondamentalement impossible de faire ce que vous voulez faire sur votre architecture (x86).
Étant donné que vous avez fourni le nom du NAS, j'ai fait une recherche sur Google et j'ai découvert ceci: http://www.techwarelabs.com/patriot-javelin-s4-network-attached-storage/2/
Ce qui implique qu'il utilise un processeur PPC.
En effet, sur PowerPC, les noyaux peuvent être construits pour utiliser soit des pages 64k soit des pages 4k. Cela expliquerait pourquoi le bloc est de 64k et pourquoi vous ne pouvez pas exécuter le système de fichiers sur votre machine, où il fonctionnait auparavant sur son propre NAS.
Si vous voulez essayer d'ouvrir le système de fichiers - je pense que votre meilleure option est d'exécuter une instance de machine virtuelle dans un hyperviseur en utilisant PPC64LE (je pense que c'est l'architecture réelle de ce CPU), Fedora construit son PPC64LE avec 64k pages.
https://alt.fedoraproject.org/alt/
Vous pouvez utiliser qemu pour ce faire. Ce mec semble donner des instructions (non testées) sur la façon de procéder.
https://rwmj.wordpress.com/tag/ppc64le/
À partir de là, exposez directement le (s) disque (s) dans la machine virtuelle et faites votre dmraid / lvm / mount normal pour accéder au lecteur.
la source
virt-builder fedora-25 --arch ppc64le -o fedora-25-ppc64le.img
. Je suis sur chiot linux et je reçois "supermin: impossible de détecter le gestionnaire de paquets utilisé par ce système ou distribution".