web-dev-qa-db-ja.com

64KBのブロックサイズでXFSからファイルを取得する

私は、完全に機能し、破損しておらず、暗号化されていない2つのファイルのうちの1つからファイルを回復する使命を負っていますNAS RAID 1にあったドライブ。NASはPatriot Javelin S4でした（私の研究からわかったように）Promise Fasttrackフェイクレイドコントローラを使用しています。

これに関する情報は非常に少ないため、同じ状況のグーグルにとって、このNASに関するいくつかの事実があります。

  • RAIDコントローラー：Promise FastTrack（FakeRaid）
  • ボリュームシステム：LVM2
  • ファイルシステム：64KBブロックサイズ（65536バイト）のXFS
  • Arch：800MHz AMCC PowerPCプロセッサ、256MB RAM（Matthewの研究に感謝）

これを行ったとき、私はWindows 10とMacOSコンピューターしか持っていませんでした。LVM2ボリュームにXFSをマウントできるソフトウェアは見つかりませんでした（1つを例外として、以下で詳しく説明します）。私は古いネットブックAcer Aspire Oneを取り出して、それにPuppy Linux（具体的にはlxpupフレーバー）をインストールする必要がありました。

パピーリナックスでは、dmraidというツールを使ってこのファイルシステムをマウントすることができました。このツールには、Promise FastTrackのIDであるpdcボリュームをマウントする方法があります。それをマウントしているいくつかのフープを飛び越えることができたら、実際のXFSファイルシステムにアクセスできました。

これは、「read xfs 64kb block size」のようなものをググって始めて、どこにも行かないところです。 「カーネルにパッチを適用しない限り、Linuxは4kbを超えるブロックサイズを読み取ることができません」という回答はわずかです。カーネルにパッチを当てる方法がわかりませんし、これを可能にするエミュレーションもないので困惑しています。

Win/Macでこのパーティションを読み取れないアプリの1つの例外について言及しました。その例外はufsexplorerでした。 100ドルのアプリで、シ​​ームレスにファイルを表示できました。いくつかのファイルをコピーして動作することを証明しましたが、試用版では小さなファイルしかコピーできません。

64kbのxfsを読み取るのに役立つような複雑さのレベルにある無料のオープンソースツールは存在しないと私は信じません。

私の質問は：誰かがそのようなツールを知っていますか？ 1つ以上のツール、カーネルパッチ、または何か他のもの（無料）を使用してデータを取得する方法についての具体的な指示があれば、高く評価されます。

もう1つ、これらのドライブのローカルイメージを作成する必要がないことを強く望みます（それが唯一の方法でない限り）。結局のところ、それは2TBのデータであり、私はこれほどのスペースを持っていないかもしれません。

追伸Acerに64kb xfsを読み取ることができる既知のLinuxがある場合、それも実行可能なソリューションです。

更新1： https://www.cgsecurity.org/wiki/TestDisk について学んだところです。一撃の価値があるかもしれません。試してみる時間があったらまた報告します。

アップデート2：TestDiskはXFSパーティションの存在を認識しているようですが、そこに進む方法がわかりません。ファイルを抽出する方法がわからないので、今はそれを放棄し、マシューの答えでqemuアプローチを試しました。

lvmraid1data-recoveryxfsfakeraid
9
Max Chernyak

私はあなたの問題について少し調査しました。簡単ではないが実現可能に見えます。

あなたを壊すコードの領域はこれです（まあ、新しいカーネルでは）：fs/xfs/libxfs/xfs_sb.c

271         /*
272          * Until this is fixed only page-sized or smaller data blocks work.
273          */
274         if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) {
275                 xfs_warn(mp,
276                 "File system with blocksize %d bytes. "
277                 "Only pagesize (%ld) or less will currently work.",
278                                 sbp->sb_blocksize, PAGE_SIZE);
279                 return -ENOSYS;
280         }

基本的に、XFSブロックサイズが少なくともシステムのページサイズと等しいことが必要です。

これは2つのことを意味します。

  1. これは、これまで知られていなかったバグの回避策です。
  2. システムのページサイズは元々64kでした。

私は行って本当に古いカーネル（EL4）をチェックしましたが、上記の制限はまだありました。つまり、アーキテクチャ（x86）で実行したいことを実行することは基本的に不可能です。

NASの名前を指定して、グーグルを実行してこれを発見しました： http://www.techwarelabs.com/patriot-javelin-s4-network-attached-storage/2 /

これは、PPC CPUを使用することを意味します。

Javelinのハードウェアは、追加の役割を処理するだけでは不十分です。基本的に、800 MHz AMCC PowerPCプロセッサと256 MBのRAMを備えた組み込みLinuxシステムです。

実際、PowerPCでは、カーネルは64kページまたは4kページを使用するように構築できます。これは、ブロックが64kである理由と、以前は独自のNASで機能していたマシンでファイルシステムを実行できない理由を説明します。

ファイルシステムを開こうとする場合-PPC64LE（私はそのCPUの実際のアーキテクチャだと思います）を使用してハイパーバイザーで仮想マシンインスタンスを実行するのが最良のオプションだと思います。Fedoraは64kページでPPC64LEを構築します。

https://alt.fedoraproject.org/alt/

これを行うにはqemuを使用できます。この男は、これをどのように行うかについて、いくつかの（テストされていない）指示を与えるようです。

https://rwmj.wordpress.com/tag/ppc64le/

そこから、VMでディスクを直接公開し、通常のdmraid/lvm/mountを実行してドライブにアクセスします。

8
Matthew Ife