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

Question

私の主な関心事は、とにかくNTFSでパーティション化されたディスクでは、これらの破損は決して起こらないことです。

おそらくそのようなことはありませんでした。あなたしかし、すでにそのようなことが起こりました。そのようなことが決して起こらないと主張できる唯一のファイルシステムは、そのような条件にさらされたことのないシステムです。 BTRFSとZFSの両方がこれらの問題に耐えるように設計されていても、そのような問題が存在する可能性があります。

しかし、実際の質問の場合：

ext4は一般的に安全ですか？私または他の人がetx4でフォーマットされたディスク/ディスクに関する情報の損失を経験したことがありますか？

「安全」とは何を意味するかによって異なります。私は個人的にフォーマットされたディスクのデータを失いましたext4。しかし、これが発生するたびにハードウェアエラーが原因で発生し、さらに重要なことは、最終的に他のほとんどのファイルシステムでもこれが起こることです。それにもかかわらず、私はユーザーエラーやハードウェアの問題（予期しない停電を含む）がないとうまく機能するため、まださまざまな用途に定期的に使用しています。だから、私ほとんどの人の定義によれば、「安全」だと思いますが、そうかもしれないし、そうでないかもしれません。

Linuxの世界で予想外の停電や予期しない削除に耐えることができるext4よりも安全な代替策は何ですか？

いいえ、他の制限や問題を処理したい場合以外は可能です。特に：

XFSは予期しない停電に対してより弾力性があり、ext4のように再起動時に長い確認は必要ありません。ただし、小規模使用には疑わしいほど多くの実質的な制限があります（ファイルシステムを縮小できず、パフォーマンスが悪い）。新しいボリュームのext4ほど良いですが、データロギングはありません。
NILFS2は停電のためシャットダウンすることはほとんど不可能ですが、30秒ほどの変更が失われる可能性があり、インストール時にユーザースペースコンポーネントが必要であり、通常はほとんどのLinuxファイルシステムで標準と見なされる機能がいくつかありません。
BTRFSはハードウェア障害に対する免疫を提供し、かなり安定しており、障害が発生したディスクのオンライン交換の優れたサポートを提供しますが、予期しない停電によって最新の変更の一部が失われる可能性があるため、より多くの作業を行う必要があります。他のほとんどのファイルシステムよりもボリュームを健康に保つために行われます。
ZFSは問題（管理上の問題を除く）なしでBTRFSのすべての利点を提供しますが、サードパーティのカーネルモジュールを構築する必要があり、エンタープライズクラスのハードウェアで実行しない限りアップストリームサポートを受けることはできません。。

ただし、ext4をより安全にするために実行できるいくつかの作業があります。

エラーが発生した場合の動作を変更します。デフォルトでは、ファイルシステムメタデータにエラーが発生した場合、ext4はそのボリュームを確認が必要としてマークし、何も起こらなかったかのように動作します。これはただLinuxのファイルシステムがこれを行うと、他のすべてのエントリはボリュームを読み取り専用に再マウントし、ファイルシステムへの書き込みが状況を悪化させるのを防ぎます。errors=remount-roマウントオプションを追加するか、ファイルシステムを含むブロックデバイスで実行してtune2fs -e remount-roext4でこの動作を取得できます。
あなたがいることを確認いいえログ書き込み保存モードを使用します。ボリュームのマウントオプションを再確認し、リストにないことを確認してjournal=writebackください。ログ書き込みストレージモードは、ext4ファイルシステムの特定のワークロードのパフォーマンスを大幅に向上させることができますが、予期しない停電が発生した場合にデータが失われる可能性が高くなります。
なりたいなら本物データセキュリティ編集証の場合は、ログデータモードを有効にできます。通常、ext4ファイルシステムのログは、メタデータの変更（名前の変更、ファイルの削除または作成、タイムスタンプの更新など）のみを追跡します。ログデータモードではみんな変更はログを介して行われます。これにより、作業が大幅に遅くなりますが、ファイルシステムが内部的に一貫性を保つという機能が100％保証されます。journal=dataインストールオプションを渡すことでこの機能を有効にできます。
auto_da_allocインストールオプションを追加できます。デフォルトでは、これはfsync()アプリケーションを呼び出す必要があるときに呼び出されない状況を検出し、問題を正しく処理します。速度が少し遅くなり、ほとんどのアプリケーションでは必要ないため、デフォルトではありません。
最新のカーネルでは、ログチェックサムを有効にできます。これにより、実際にデータが「保存」されませんが、問題が発生した場合に偽のデータを取得できないようにするのに役立ちます。これはjournal_checksumインストールオプションを追加することで有効にできます。
十分に新しいカーネルとe2fsprogsバージョンがある場合は、メタデータチェックサムを有効にできます。ログチェックサムと同様に、データは保存されませんが、エラーが発生した場合に偽のデータが表示されるのを防ぐのに役立ちます。ファイルシステムの作成時に-O metadata_checksum,metadata_checksum_seed渡す必要がありますmkfs.ext4。これにより、ログがメタデータチェックサムに含まれるエントリの一部であるため、ログチェックサムを同時に有効にする必要がなくなります。

Answer 1