ext4ファイルシステムは安全ですか？

Question

最近、ディスクをetx4にフォーマットして事故が発生しました。正直なところ、失敗は私の側にあると思います。1つはフラッシュカードの誤った[手動]アンマウントによるもので、もう1つは電源のオフに関連していたためです。正味の影響は、128 GBのフラッシュカード[お金に関連する]と2TbHDDの情報[時間に関連する]を物理的に失ったことです。私の主な懸念は、そのような損傷がNTFSにパーティション化されたディスクに決して起こらなかったことです。

私の質問は次のとおりです。

Ext4は一般的に安全ですか？つまり、私なのか、それともetx4にフォーマットされたディスク上のディスク/情報の損失を経験した他の人々がいますか？
Linuxの世界では、予期しない電気のスイッチオフや予期しないアンマウントよりも長持ちする、ext4のより安全な代替手段は何でしょうか。

Austin Hemmelgarn · Accepted Answer

私の主な懸念は、NTFSにパーティション分割されたディスクにそのような損傷が発生したことはまったくないということです。

yoに起こったことはないかもしれませんが、起こったことはあります。このようなことが決して起こらないと主張できる唯一のファイルシステムは、そのような条件にさらされたことがないファイルシステムです。どちらもこのようなものに対して回復力があるように設計されているBTRFSとZFSでさえ、このような問題を抱えている可能性があります。

しかしあなたの実際の質問に：

Ext4は一般的に安全ですか？つまり、私ですか、それともetx4にフォーマットされたディスク上のディスク/情報の損失を経験した他の人がいますか？

それはあなたが「安全」とはどういう意味かによります。 _ext4_でフォーマットされたディスク上のデータを個人的に失いましたが、それが発生するたびに、ハードウェアの不良が原因であり、さらに重要なことに、他のほとんどのファイルシステムで最終的に発生していました。それにもかかわらず、ユーザーエラーやハードウェアの問題（予期しない電力損失を含む）を除いて、それは正常に機能するため、私はまだ定期的に多くのことに使用しています。したがって、[〜＃〜] i [〜＃〜]ほとんどの人の定義では「安全」であると考えていますが、そうでない場合もあります。

Linuxの世界では、予期しない電気のスイッチオフや予期しないアンマウントよりも長持ちする可能性のあるext4のより安全な代替手段は何でしょうか？

いいえ、他の制限や問題に対処したい場合を除いて、そうではありません。特に：

XFSは、予期しない電力損失に対して少し回復力があり、ext4のように再起動時に長いチェックを行う必要はありませんが、小規模な使用には問題となる実用的な制限がいくつかあります（ファイルシステムを縮小できず、パフォーマンスは低下しません）新しいボリュームのext4と同じくらい優れており、データジャーナリングを実行できません）。
NILFS2は、停電で強制終了することはほぼ不可能ですが、30秒ほどの変更が失われる可能性があり、マウント時にユーザースペースコンポーネントが必要であり、ほとんどのLinuxファイルシステムで一般的に標準と見なされている機能がいくつか欠けています。
BTRFSは、ハードウェアの障害から合理的に確実に節約し、さらに障害のあるディスクのオンライン交換を適切にサポートしますが、予期しない電力損失で最新の変更の一部が失われる可能性があり、維持するためにさらに多くのことを行う必要がありますボリュームは他のほとんどのファイルシステムよりも健全です。
ZFSには、BTRFSが提供するすべての利点があり、問題はありません（管理のものを除く）が、サードパーティのカーネルモジュールを構築する必要があり、問題が発生した場合のアップストリームサポートは受けられません。エンタープライズグレードのハードウェアでは実行されていません。

ただし、ext4をより安全にするためにいくつかのことを行うことができます。

エラーが発生したときの動作を変更します。デフォルトでは、ファイルシステムメタデータでエラーが発生した場合、ext4はボリュームをチェックする必要があるとマークするだけで、何も起こらなかったように動作します。これを行うのはLinux上のonlyファイルシステムであり、他のすべてはボリュームを読み取り専用で再マウントするため、ファイルシステムへの書き込みが事態を悪化させるのを防ぎます。 ext4でこの動作を得るには、マウントオプションに_errors=remount-ro_を追加するか、ファイルシステムを含むブロックデバイスで_tune2fs -e remount-ro_を実行します。
ジャーナルにライトバックモードを使用していることを確認してくださいnot。ボリュームのマウントオプションを再確認し、_journal=writeback_がリストにないことを確認することで、これを確認できます。ジャーナルライトバックモードは、ext4ファイルシステム上の特定のワークロードのパフォーマンスを大幅に向上させることができますが、予期せず電力が失われた場合にデータが失われる可能性がはるかに高くなります。
本当にデータの安全性について偏執的になりたい場合は、ジャーナルデータモードを有効にすることができます。通常、ext4ファイルシステムのジャーナルは、メタデータへの変更（名前の変更、ファイルの削除または作成、タイムスタンプの更新など）のみを追跡します。ジャーナルデータモードでは、all変更はジャーナルを通過します。これにより処理速度が大幅に低下しますが、ファイルシステムの内部整合性が機能的に100％保証されます。これを有効にするには、マウントオプションで_journal=data_を渡します。
_auto_da_alloc_マウントオプションを追加できます。基本的に、これは必要なときにfsync()を呼び出さないアプリケーションを検出し、適切に処理します。速度が少し遅くなるため、デフォルトではありません。ほとんどのアプリケーションでは必要ありません。
新しいカーネルでは、ジャーナルのチェックサムを有効にできます。これは実際にはデータを「保存」しませんが、エラーが発生したときに偽のデータが返されないようにするのに役立ちます。これは、マウントオプションに_journal_checksum_を追加することで有効にできます。
十分に新しいカーネルとe2fsprogsのバージョンがある場合は、メタデータのチェックサムを有効にできます。ジャーナルのチェックサムと同様に、これはデータを保存しませんが、エラーが発生した場合に偽のデータが表示されるのを防ぐのに役立ちます。これは、ファイルシステムの作成時に_-O metadata_checksum,metadata_checksum_seed_を_mkfs.ext4_に渡すことによって有効にする必要があります。これを行う場合、ジャーナルはメタデータチェックサムの対象となるものの一部であるため、（おそらく）ジャーナルチェックサムも有効にする必要はありません。