障害デバイス情報：
サーバー：X3850サーバ
のハードディスクのタイプ：SAS、容量：146G 4台のドライブ構成のRAID 5
：ファイルシステムreiserfsの
2は、ReiserFSのファイルシステムの障害解析：
1.分析が見つかりました。そのことによって、以前のハードディスクのデータ組織構造以下100Mブートパーティションよりも、2Gスワップパーティションに続く、271G LVMボリュームが続きます。LVMボリュームはルートパーティションとして、直接reiserfsのファイルシステムを分割しました。
図2に示すように、使用中のユーザは、システムが衝突システムはフロント2Gとスワップパーティションのブートに全体RAID論理ボリュームの後に見つかった後に麻痺し、未知の理由が発生した、271Gは、LVMボリューム、LVMボリューム・ファイルに従っシステムは、空の位置reiserfsのスーパーブロックを有しています。
3、我々は元のデータを復元したいこの時間は、データベース、WebアプリケーションとWebページが含まれ、すべてのユーザーデータ、すべてのオフィス文書の単位OAシステムのファイルシステムでは271Gです。
三、ReiserFSのファイル・システム・ソリューション：
1は、ツリーノードがreiserfsの元の場所を分割判定全体ReiserFSの間の相関関係によって、元のデータは、データファイルを格納するための2Gシステムは、被覆される前に、ユーザはインストール時に決定されるべきで見出さインストールされたシステムは、LVMボリュームおよびDONE reiserfsckは修正しようとしてをインポートすることはできませんので、パーティション構造を初期化するシステムエラー。
図2は、B +ツリーを生成するために、ファイルキー、線形化（ディレクトリを含む）を、システム内のすべてのファイルのReiserFSのファイルシステムのため、全体的なひだ解きのツリー構造内のノードの結果を増加ツリーは、ディスク全体のデータ領域の平滑化を行います移行。最上位ノードは、ファイルシステムの前面に通常ないからです。2Gは、ルートノードのキーから最新の開始パスに格納されなければならない前に、ルートは、スペースの観点から、そう、通常は最小限であるため、KEYファイル番号。
図3に示すように、ユーザはデータそれにより深いディレクトリ階層に、ノード高い可能性があります。データ2Gカバレッジが回復することができなかった前に、私たちはそれだけでユーザデータをカバーしていないことを願っていますすることができます。インデックスにツリー全体によるファイル・システム全体の損失、プラスのReiserFSツリーのデザインコンセプトは非常に抽象的で、重いビルドツリーは非常に困難になります。
4、当社の主要輸出全体元のファイルシステム領域に独立したプログラムを介してすべてのノードとノードをスキャンします。次に、2つ、3つ、4つ、その他のリーフノードを再生成するために、すべてのリーフノード、フィルタ（ノードを廃棄する前に削除されたファイルを削除する）のために自律的手順で並べ替え。2Gは、新しいツリー構造として、フロント仕切り空間領域を選択的および対応するアドレス情報を生成します。
5は、失われたノードの元ツリーパスの場合に遭遇したような問題を持つディレクトリ・ネーミングの契約は、カスタムキーのノード番号とその名前は一時的にotherfilesダウン/アップの追加、親ディレクトリとして決定することはできません。顔に基づいて、スパニングツリーインデックス情報、特定の場所を書き込み、その後、この情報に基づいて、クリアフラグを設定、スーパーブロックを生成します。SUSE仮想マシンの下では、すでにファイルを見ることができ、修理ボリュームをマウントし、スナップショットを作成します。（注：仮想マシンの目的とスナップショット操作は補正を行わず、それがロードreiserfsckは前に行うことができない、などのメタデータビットマップの結果に影響を与えることなく、トレーサビリティデータを追加します）。
図6は、仮想マシンの使用SUSE修復に、ターゲットハードディスクをマウントし、mkfsコマンドは、ターゲット・ディスクにすべてのデータのCPデータをコピーします。ユーザーがディレクトリのファイルの場所と名前の一部を改正するために必要なデータをソートするコマンドを見つけます。ファイルヘッダフラグの大きさに応じて散乱文書の部分的な損失は、動きを見て、検索の名前を変更します。
四、ReiserFSのファイルシステムのデータ復旧結果：
分析のためのエンジニアの後、データが正常に復元されており、通常使用することができ、作業のためのデータ復旧終了。