問題タブ [raid]

この記事を読んで、 RAID アレイ内のハードディスクで単一ビットが (検出されずに) 複数バイトに変更されるビット腐敗の問題に気づきました。

今のところ、私たちのサーバーはそれぞれ 12 個の 3GB ハードディスクのハードウェア RAID6 を実行しており、少なくとも検出されずに、ビットの腐敗が起こらない可能性を改善しようとしています。

12 台の JBOD ハードディスクで使用btrfsしたほうがよいでしょうか (これは Debian 上にあるため、ZFS の BSD への変更はここでは少し問題外です。ただし、多くの機能が両方のファイルシステムで共有されていることは理解しています)。「btrfsのベストプラクティス」の指針はありますか?

---編集1

RAID をテストするために (例: 「まったく問題なく動作するか、それとも何か大きな失敗はありますか?」) サーバーで処理するサイズとほぼ同じサイズのファイルを多数作成します (約 100 GiB/ file) の /dev/zero コンテンツの場合は、時々md5sumそれらが表示されます。しかし、これには時間がかかります。

アレイraid5をインストールするスクリプトに取り組んでいます。スクリプトが尋ねたときに auto=yes を挿入するのに問題があります: 配列の作成を続行したい場合。--auto=yes ( http://www.linuxmanpages.com/man8/mdadm.8.php ) を試しましたが、どこに配置すればよいかわかりません。

I'm using Ubuntu 13.10 and trying to create a RAID 5 array across 3 identical disks connected to SATA ports on the motherboard. I've followed every guide and and used both the built-in Disks GUI app and mdadm at the command line, and despite everything I cannot get the array to persist after reboot.

I create the array with the following command:

Then I watch /proc/mdstat for awhile while it syncs, until I get this:

To update the mdadm config file, I run the following:

This adds the essential line to my config file:

Everything seems correct, but when I reboot, the array is gone!

自宅でシンプルな ZFS ベースのファイル サーバーを作成するために使用することを考えているため、VirtualBox で Solaris 11 をテストしていました。チェックサムの修復が実際に行われているのを見たかったのです。

私のセットアップは 3 つの仮想ディスクでした。それがインストールされている Solaris OS ディスクと 2 つのデータ ディスクです。2 つの仮想ディスクを使用して zpool を正常に構築し、それにテキスト ファイルを書き込みました。

ここで、ファイルを「破損」できるかどうかを確認しようとしましたが、ZFS はそれを「修正」します。ということで、変更前のデータディスク1と変更前のデータディスク2、変更後のデータディスク2を結合してファイルを保存し、VirtualBoxを起動しました。しかし、Solaris は問題を検出せず、最新バージョンのファイルを取得しただけです。

2 つの仮想ディスクに 2 つの異なるバージョンのファイルがあったのに、なぜ ZFS はこれを問題として認識しなかったのでしょうか?

不良スーパーブロックを含む RAID 5 からデータを復元しようとしています。3 つのドライブすべてから同時にデータをダンプできるツールを g++ で作成し、不足しているドライブがある場合はそこからデータを作成します。ありません。1 つのドライブが 100% 同期されていないことはわかっているので、後でその機能が役立つ可能性があります。また、ディレクトリの検索に役立つASCII検索機能もありますが、3TBのデータの検索を完了するのに2日かかる可能性があります.

とにかく問題は、inode番号からダンプしたいブロックをどのように計算するのですか? inode * 16 + 36984の方程式を実行したときのinode番号0x02E00001は、inode 0x02E0A007と0x02E0A007を指し、データはraidの2つのドライブに保存され、常に2つのディレクトリを見つける可能性があります. ただし、私の計算では 0xA000 の inode が高く計算されます。過去 2 日間に私が思いついたすべての計算の中で、これは私が得ることができると思われる最も近いものです。

36984 は、データが RAID 用に 2 つのドライブにストライプ化されているため、1 を 2 で割った場合、inode ゼロの場所である可能性があります。この数は、ダンプの場所 37000 または ext4 の場所 74000 にある inode 2 であるルート ディレクトリを見つけることに基づいて計算しました。

FreeBSD を実行しているサーバーに 3DM2 (3ware RAID Manager) をインストールしています。3DM2 では、ハードディスクのスマート データの 16 進ダンプを取得できます

(おそらくこの質問では必要ありませんが、次のようになります。

0A 00 01 0F 00 75 63 53 FD 63 08 00 00 00 03 03 00 61 61 00 00 00 00 00 00 00 04 32 00 64 64 70 00 00 00 00 00 00 0 05 33 400 0 0 64

等。）

ユーザーが読める/理解できるものに変換するために使用できるツールはありますか?