10TB ext3 RAID 6のfsckに関する主な問題（メモリ割り当ての失敗など）
最近、LinuxmdソフトウェアのRAID6セットアップに7番目の2TBドライブを追加しました。 mdがアレイを6から7ドライブ（8から10TB）に再形成し終えた後も、問題なくファイルシステムをマウントすることができました。次に、resize2fsの準備として、パーティションをアンマウントしてfsck -Cfyvを実行すると、何百万ものランダムエラーの無限のストリームが表示されました。ここに短い抜粋があります：
Pass 1: Checking inodes, blocks, and sizes
Inode 4193823 is too big. Truncate? yes
Block #1 (748971705) causes symlink to be too big. CLEARED.
Block #2 (1076864997) causes symlink to be too big. CLEARED.
Block #3 (172764063) causes symlink to be too big. CLEARED.
...
Inode 4271831 has a extra size (39949) which is invalid Fix? yes
Inode 4271831 is in use, but has dtime set. Fix? yes
Inode 4271831 has imagic flag set. Clear? yes
Inode 4271831 has a extra size (8723) which is invalid Fix? yes
Inode 4271831 has EXTENTS_FL flag set on filesystem without extents support. Clear? yes
...
Inode 4427371 has compression flag set on filesystem without compression support. Clear? yes
Inode 4427371 has a bad extended attribute block 1242363527. Clear? yes
Inode 4427371 has INDEX_FL flag set but is not a directory. Clear HTree index? yes
Inode 4427371, i_size is 7582975773853056983, should be 0. Fix? yes
...
Inode 4556567, i_blocks is 5120, should be 5184. Fix? yes
Inode 4566900, i_blocks is 5160, should be 5200. Fix? yes
...
Inode 5628285 has illegal block(s). Clear? yes
Illegal block #0 (4216391480) in inode 5628285. CLEARED.
Illegal block #1 (2738385218) in inode 5628285. CLEARED.
Illegal block #2 (2576491528) in inode 5628285. CLEARED.
...
Illegal indirect block (2281966716) in inode 5628285. CLEARED.
Illegal double indirect block (2578476333) in inode 5628285. CLEARED.
Illegal block #477119515 (3531691799) in inode 5628285. CLEARED.
圧縮？エクステント？私はこのマシンの近くにext4を持ったことがありません！
現在、問題はfsckが次のエラーメッセージで死に続けていることです：
Error storing directory block information (inode=5628285, block=0, num=316775570): Memory allocation failed
最初はfsckを再実行するだけで、別のiノードで停止しましたが、現在は5628285に落ち着き、それを超えることはできません。
私はこれに対する修正を検索しようとして最後の日を過ごし、次の3つの「解決策」を見つけました。
- 64ビットLinuxを使用します。
/proc/cpuinfoはプロセッサの1つとしてlmを含みますflags、getconf LONG_BITは64を返し、uname -aは次のように言います：Linux <servername> 3.2.0-4-AMD64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux。すべて良いはずですよね？ [scratch_files]/directory = /var/cache/e2fsckを/etc/e2fsck.confに追加します。そうすると、fsckを再実行するたびに、別の500K*-dirinfo-*ファイルと8M*-icount-*ファイルが/var/cache/e2fsckディレクトリに追加されます。ですから、それも望ましい効果があるようです。- マシンにメモリまたはスワップスペースを追加します。 12GBのRAMと32GBのスワップパーティションで十分ですよね？
言うまでもなく、何も役に立たなかった。さもなければ、私はここに書いていなかっただろう。
当然のことながら、ドライブに不良のマークが付けられ、マウントできなくなりました。だから、今のところ、ディスクチェックのために8TBのデータを失いましたか？！？！？
これは私に3つの質問を残します：
- このドライブを修正するためにできることはありますか（fsckを実行する前はすべて問題ありませんでした！）、1か月かけてext3ディスクのフォーマットを学習し、16進エディターで手動で修正しようとする以外にありますか？
- Ext3のように人気のあるファイルシステムのfsckのようにミッションクリティカルなものがまだこのような問題を抱えている可能性はありますか？特にext3は10年以上前のものなので。
- このような基本的な信頼性の問題がないext3の代替手段はありますか？多分jfs？
（現在、64ビットのDebian Wheezy7.1でe2fsck1.42.5を使用していますが、32ビットのDebian Squeezeの以前のバージョンでも同じ問題が発生しました）
fsckをもう少し遊んだ後、いくつかの解決策を見つけました。
「メモリ割り当てに失敗しました」エラーの防止
fsckには、メモリリークに関する大きな問題があるようです。いくつかの問題（実数または虚数）のあるファイルシステムで実行された場合、それらを1つずつ「修正」します（元の質問のスクリーンダンプを参照）。そうするにつれて、それはますます多くのメモリを消費します（おそらく変更ログを保持しますか？）。ほぼ無制限。ただし、fsckはいつでもキャンセル（Ctrl-C）して再起動できます。この場合、中断したところから続行されますが、メモリ使用量はほぼゼロにリセットされます（しばらくの間）。
これを念頭に置いて、実行する必要がある3つのことは次のとおりです。
- 64ビットLinuxを使用します（
fsckが使用可能なメモリを使用する方法に違いがあるようです） - 途方もなく巨大なスワップパーティションを追加します（私は256GBを使用し、
fsckはそれで約12時間実行されます） - Fsckを頻繁に中止して再起動します（スワップパーティションのサイズによって異なります）
注：fsckをキャンセルして再起動すると、他の危険が伴うかどうかはわかりませんが（おそらくそうなります）、うまくいくようです。
「メモリ割り当てに失敗しました」エラーが発生した場合の結果の損傷への対処（重要！）
fsckは、可能な限り最悪の方法でMemory allocation failedエラーを処理します。完全に適切なデータを破棄します。理由はわかりませんが、メモリに保持されていたもののディスクへの最終的なデータ書き込みを実行し、その間に（エラーのために）破損したと推測されます。
私の場合、最も目に見える問題は、エラーの後にfsckを再起動すると、破損したスーパーブロックが報告されることがあるということでした。問題は次のとおりです。特に、スーパーブロックが破損していると報告されなかった場合、スーパーブロックがどのように破損したかがわかりません。おそらく、エラー後に再起動すると、破損したスーパーブロックで見つかった誤ったドライブメタデータを使用してさらにすべてのチェックを行い、実際には存在しない「問題」を修正して、プロセス内の適切なデータを破壊することになります。
したがって、fsckeverがMemory allocation failedエラーで停止した場合、（うまくいけば）エラーによって破損しなかったバックアップスーパーブロックを使用するには、-bパラメーターを使用して再起動する必要があります。バックアップスーパーブロックの場所は、mke2fs -n /dev/...を使用して見つけることができます。
バックアップスーパーブロックを選択した状態でfsckが停止した場合はどうなるかわからないため、通常はPass 1: Checking inodes, blocks, and sizesに到達したらすぐにfsdkを中止し、-bなしで再起動します。それは悪いスーパーブロックについて文句を言うことなく始まります。つまりfsck -bが最初に行うことは、メインのスーパーブロックを復元することのようです。
今、私たち全員が待ち望んでいたもの：
fsckを最後まで実行させずにファイルシステムをマウントする方法
これは、偶然に見つかりました。fsck -bを実行し、Pass 1: Checking inodes, blocks, and sizesを出力するとすぐに（エラーが見つかる前に）中止した後、ファイルシステムはマウント可能な状態のままになっていることがわかりました（そうです！私はほとんどすべてを取得しました）私のデータが戻ってきました！）。
（注：mount -o forceを使用する別の方法があるかもしれませんが、私の場合は必要ありませんでした。）
そもそもこれらすべての問題を回避する方法
2つの方法があるようです：
- Ext3を使用しますが、完全に最新のバックアップを維持します。次に、パラメータ
-Nを指定してfsckを頻繁に実行します。 anyの問題が表示された場合は、fs全体を削除し、バックアップからすべてを復元します。このシナリオでは、バックアップに大きく依存するため、バックアップのバックアップを保持することをお勧めします。また、復元によってプロセスでランダムエラーが発生しないようにするコピーツールを使用します（TBのデータを処理する場合、1兆r/w-opsのMTBFは小さい）） 。マルチTBの復元にはおそらく時間がかかるため、結果として生じるダウンタイムも計画してください。 - 私の推奨事項：ext3を使用しないでください！ fs-designおよび関連ツール（ここでは
fsck）は、実際の本番環境での使用には十分な堅牢性がありません（まだ？）。fsckがメモリエラーを処理する方法と、エラーが最初に発生するという事実は、私の考えでは受け入れられません。これからxfsを試してみますが、それがもっと良いかどうかを判断するのに十分な経験がまだありません。
アレイを再構築し、バックアップからデータを復元するだけです。 RAIDの要点は、ダウンタイムを最小限に抑えることです。このような問題をいじって修正しようとすると、ダウンタイムが増加し、RAIDの目的全体が無効になります。 RAIDはデータ損失から保護するのではなく、ダウンタイムから保護します。
残念ながら、「コメントを追加」することはできませんが、ここでチャイムを鳴らして、Opに感謝する必要がありました。 RAID6に障害が発生し、イベント数が厳密に一致する8台のドライブのうち6台を手動で組み立てました。しかし、アセンブルされた配列をmountすることができませんでした。
バックアップスーパーブロックを使用する必要があるようです。 fsck -b <location> ...の実行は最終的にメモリ不足で終了し、このスレッド/質問につながりました。
つまり、fsck -b <location>...を使用してからctrl+cを実行すると、アレイをマウントしてファイルを回復することができました。
ありがとう！