完全なデータジャーナリングでは、なぜデータがディレクトリにすぐに表示されるのですか？
Ext3ファイルシステムでの完全なデータジャーナリングに関する質問があります。マニュアルページには次のように記載されています。
data=journal
All data is committed into the journal prior to being written into
the main filesystem.
これは、ファイルが最初にジャーナルに保存され、次にファイルシステムにコピーされることを意味しているように思われます。
何かをダウンロードする場合は、最初にジャーナルに保存し、完了したらFSに移動する必要があると思いました。ただし、ダウンロードを開始すると、ディレクトリ（FS）にファイルが表示されます。何が問題なのですか？
編集：「すべてのデータ」=ファイルの全体のサイズを考えるのは間違っているのではないでしょうか。それで、すべてのデータがおそらくブロックかそれ以外のものであり、それが意味をなさないものであり、物事が最初にジャーナルに書き込まれるのを見ることができなかった場合はどうでしょうか？
まず、「すべてのデータ」がファイル全体を意味するのではないことを疑うのは正しいことです。実際、ファイルシステムのその層は、ファイル全体ではなく、固定サイズのファイルブロックで動作します。そのレベルでは、限られた量のデータを保持することが重要であるため、ファイル全体（任意の大きさになる可能性があります）での作業は機能しません。
第二に、あなたの質問には誤解があります。ジャーナリングの動作は、ディレクトリの内容をlsで確認することで確認できるものではなく、はるかに低いレベルで機能します。通常のツールでは、ファイルがそこにあることが常にわかります。 （ファイルの作成が、ファイルを作成するように見えなかった場合、壊滅的です。）内部で発生するのは、ファイルをさまざまな方法で保存できることです。最初に、最初の数ブロックがジャーナルに保存されます。次に、効率的に可能な限り早く、データは最終的な場所に移動されます。同じディレクトリにある同じファイルであり、保存方法が異なります。
ジャーナリングの動作を観察できる唯一の方法は、カーネルがディスクに書き込んでいる内容を正確に確認するか、クラッシュ後にディスクの内容を分析することです。通常の操作では、ジャーナルは実装の詳細です。（パフォーマンス面以外で）実際に動作しているのを見ることができれば、ジャーナルはひどく壊れています。
ファイルシステムジャーナルの詳細については、 ウィキペディアの記事 から始めることをお勧めします。 ext3の用語では、data=journalは、システムがクラッシュした場合に、各ファイルがクラッシュ前のある時点での状態になるようにします（バッファリングのため、常に最新の状態であるとは限りません）。これが自動的に行われない理由は、カーネルが効率を上げるためにディスク書き込みを並べ替えるためです（大きな違いが生じる可能性があります）。これは、ウィキペディアの記事では 「物理ジャーナル」 と呼ばれています。他の2つのモード（data=orderedおよびdata=writeback）は "論理ジャーナル" の形式です：高速ですが、ファイルが破損する可能性があります。ジャーナルは、破損のリスクをゴミを含むいくつかのファイルに制限しています。 ext3は常にメタデータに完全なジャーナルを使用します。メタデータのジャーナルがないと、メタデータが失われ、ファイルシステムが大幅に破損する可能性があります。さらに、ジャーナルがない場合、クラッシュ後のリカバリには完全なファイルシステムの整合性チェックが必要ですが、ジャーナルリカバリがある場合は、いくつかのジャーナルエントリを再生することを意味します。
ジャーナルがあっても、一般的なUNIXファイルシステムはグローバルファイルシステムの一貫性を保証せず、せいぜいファイルごとの一貫性のみを保証することに注意してください。つまり、ファイルfooに書き込んだ後、ファイルbarに書き込んだ後、システムがクラッシュしたとします。 barが新しいコンテンツを保持していても、fooが古いコンテンツを保持している可能性があります。完全な整合性を保つには、 transactional ファイルシステムが必要です。
何かをダウンロードする場合は、最初にジャーナルに保存し、完了したらFSに移動する必要があると思いました。
つまり、ファイルは閉じられた後にのみ表示されます。これは、Ext4のオプションの動作に似ています。 マウントオプションauto_da_allocと呼ばれるを参照してください。
auto_da_alloc | noauto_da_alloc
Noauto_da_allocが次のようなパターンを介して既存のファイルを置き換える場合、多くの壊れたアプリケーションはfsync（）を使用しません
fd = open（ "foo.new"）/ write（fd、..）/ close（fd）/ rename（ "foo.new"、 "foo"）
またはさらに悪い
fd = open（ "foo"、O_TRUNC）/ write（fd、..）/ close（fd）。
Auto_da_allocが有効になっている場合、ext4はreplace-via-renameおよびreplace-via-truncateパターンを検出し、次のジャーナルコミット時に、デフォルトのdata = orderedモードで、のデータブロックが割り当てられるように遅延割り当てブロックを強制的に割り当てます。新しいファイルは、rename（）操作がコミットされる前にディスクに強制されます。これにより、ext3とほぼ同じレベルの保証が提供され、遅延割り当てブロックがディスクに強制される前にシステムがクラッシュしたときに発生する可能性がある「長さがゼロ」の問題が回避されます。