initramfsをルートファイルシステムとして使用し、コンパクトフラッシュIDEドライブにカスタムext3パーティションをマウントした組み込み設定があります。停電時にデータの整合性が設定全体の最も重要な要素であるため、次のオプションを使用してインストールしました（以下は/etc/fstab私のファイルの項目です）。
<file system> <mount pt> <type> <options> <dump><pass>
/dev/sda2 /data ext3 auto,exec,relatime,sync,barrier=1 0 2
オンラインで読んでこれらのオプションを見つけました。私の興味は/proc/mounts次のようなものです。
/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0
あちこちで読んだ結果、data=journalデータ破損に対する最良の保護を提供するインストールオプションを使用したいと思います。ただし、特定のext3オプションのマニュアルページでは、書き込みmount保存オプションは次のように説明されています。
データの順序は維持されません。 - メタデータがログにコミットされた後、データがデフォルトのファイルシステムに書き込まれることがあります。
これはスループットが最も高いオプションであるという噂があります。内部ファイルシステムの整合性を保証します。ただし、競合やログの回復後にファイルに古いデータが表示されることがあります。
私はこれについて非常に混乱しています。マニュアルページは、ファイルシステムの整合性のためにdata=writebackオプションを指定したいと提案しているようですが、mount私が見つけた他のほとんどの参照（組み込みLinuxに公開されているいくつかの本を含む）は、What's theを使用する必要があることを示唆していますdata=journal。最良の方法は？書き込み速度はまったく問題になりません。データの整合性が問題です。
ベストアンサー1
writeback単に事実に言及することによって誤解しないでくださいinternal filesystem integrity。または使用するかどうかに
関係なく、ファイルシステムメタデータは常にext3journalorderedwriteback日記これは内部ファイルシステムの整合性を意味します。
これデータスキーマ制御できる方法を提供ノーマルデータはファイルシステムに書き込まれます。モード
ではwritebackメタデータの変更は最初にログに書き込まれ、コミットブロックに書き込まれます。ログが更新された後でも、メタデータとデータの書き込みを続行できます。 data=writeback 重大なセキュリティリスクを引き起こす可能性があります。ファイルに追加中にシステムがクラッシュした場合、メタデータがコミットされた後（および追加のデータブロックが割り当てられている）データが書き込まれる前（新しいデータでデータブロックを上書き）、すべてのユーザーがログファイルを回復するに削除したファイルのデータで埋められたブロックを含めることができます。1。
したがって、データの整合性が主な関心事であり、速度が重要でない場合、data=journalこれは正しい選択です。