完全なデータログがあると、データがディレクトリにすぐに表示されるのはなぜですか?

完全なデータログがあると、データがディレクトリにすぐに表示されるのはなぜですか?

ext3ファイルシステムのデータログ全体について質問があります。マニュアルページでは、以下について説明します。

data=journal
All data is committed into the journal prior to being written into
the main filesystem.

私にとって、これはファイルが最初にログに保存され、次にファイルシステムにコピーされることを意味します。

何かをダウンロードしたら、まずログに保存してから、完了したらFSに転送する必要があると思います。ただし、起動後にダウンロードしたファイルがディレクトリ(FS)に表示されます。これは何の問題ですか?

編集する:「すべてのデータ」=ファイルのフルサイズだと思うのは間違っていますか?もしそうなら、すべてのデータがただ1つのブロックであるか、何かである可能性があり、もともとログに記録されているものを見ることができない場合は何ですか? !

ベストアンサー1

まず、「すべてのデータ」は、ファイル全体が正確であるという意味ではないと思います。実際、このファイルシステム階層は、フルファイルではなく固定サイズのファイルブロックで機能します。このレベルでは、限られた量のデータを保持することが重要であるため、ファイル全体(任意に大きくなる可能性がある)を処理することは不可能です。

第二に、あなたの質問に誤解があります。ディレクトリの内容を見ると、ジャーナリングの動作を観察できず、lsはるかに低いレベルで動作します。通常のツールを使用すると、常にファイルが表示されます。 (ファイルを作成しても生成されないと思われる場合は災害になるでしょう。)後で起こるのは、ファイルが別の方法で保存されることです。まず、最初の数ブロックがログに保存されます。その後、できるだけ効率的にデータを最終位置に移動します。それはまだ同じディレクトリにある同じファイルであり、別の方法で保存されています。

ログの動作を観察する唯一の方法は、カーネルがディスクに何を書き込んでいるかを確認するか、またはクラッシュ後にディスクの内容を分析することです。通常の操作では、ログは実装の詳細です。実行していることがわかると(パフォーマンスの側面に加えて)、深刻な損傷を受ける可能性があります。

ファイルシステムログの詳細については、次から始めることをお勧めします。ウィキペディア記事。 ext3という用語では、data=journalシステムがクラッシュした場合、すべてのファイルはクラッシュ前の特定の時点のままになります(バッファリングのため常に最新ではありません)。これが自動的に発生しない理由は、カーネルが効率を高めるためにディスクの書き込み順序を変更するためです(これは大きな影響を与える可能性があります)。これは…「物理学ジャーナル」Wikipediaの記事で。他の2つのパターン(data=orderedおよびdata=writeback)は次の形式です。「論理日記」:速度は速いですが、ファイルが破損する可能性があります。このログは、ガベージを含む少数のファイルに破損のリスクを制限します。 ext3は常にメタデータログ全体を使用します。メタデータログがないと、メタデータが失われ、重大なファイルシステムが破損する可能性があります。また、ログがない場合、クラッシュ後の回復にはファイルシステム全体の整合性チェックが必要ですが、ログを使用した回復は一部のログエントリを再生することを意味します。

ジャーナリングを使用しても、一般的なUNIXファイルシステムはグローバルファイルシステムの一貫性を保証せず、せいぜいファイル固有の一貫性を保証します。つまり、 file に書き込んfooで file に書き込んでbarシステムがクラッシュすると仮定します。bar新しいコンテンツがあっても、fooまだ古いコンテンツがある可能性があります。完全な一貫性のために取引上ファイルシステム

おすすめ記事