問題タブ [journaling]

ジャーナリング/ログ先行書き込みストレージシステムを構築しているとしましょう。（トランザクションごとに）データを追加し（write（2）を使用）、コミットマーカーを追加してから、fsyncすることで、これを簡単に実装できますか？

考慮すべきシナリオは、このログに大量の書き込みを行ってからfsyncを実行し、fsync中に障害が発生した場合です。iノードの直接/間接ブロックポインタは、すべてのデータブロックがフラッシュされた後にのみフラッシュされますか、それともブロックが順番にフラッシュされるという保証はありませんか？後者の場合、リカバリ中にファイルの最後にコミットマーカーが表示されていると、そのファイルと前のコミットマーカーの間のデータに意味があるとは信じられません。したがって、ログファイルのどの範囲が一貫しているかを判断するには、別のメカニズム（少なくとも別のfsyncを含む）に依存する必要があります（たとえば、データの書き込み/ fsync、次にコミットマーカーの書き込み/ fsync）。

それが違いを生むなら、主にコンテキストとしてext3/ext4について疑問に思います。

handle_t私はext3でジャーナリングを実装するためのソースコードを見ていましたが、タイプとtransaction_tに出くわしましたjournal_t。

handle_tプロセスによって実行されている単一のアトミック更新を表します。transaction_tアトミック更新の複合セットを表し、journal_t単一のファイルシステムのすべてのジャーナリング情報を維持します。

私は次の疑問を持っています：-

1. 一連のディスクインタラクションはどのようにさまざまなトランザクションにグループ化されますか？
2. ハンドルとトランザクションの例をお願いします。

Ruby を使用して電子メール アーカイブ システムを構築するのに役立つライブラリやメソッドに関する情報を探しています (提案があれば、他の言語も受け入れます)。

アプリケーションは、次のことを行う必要があります。

• 1) 受信メールサーバーに座って、すべての受信メールを受信して​​保存します。

  2) メールを保存した後、実際のメール サーバーにプッシュします。

  3) メール アーカイブは検索可能である必要があります。

これについての考えは大歓迎です。これを行う既存のプロジェクトが見つからないようです。

ext3 には、ジャーナリング、順序付け、書き戻しの 3 つのジャーナリング オプションがあります。ウィキペディアのエントリによると、これらはクラッシュ リカバリのリスクが最も低いものから最もリスクが高いものまでさまざまです。何らかの理由で、Linux の Android バージョンは後者の 2 つのオプションのみをサポートし、デフォルトで writeback に設定されています。（私はFroyoを実行しています）

ジャーナル モードのサポートを追加する方法はありますか? ext3 である /data パーティションでこれを実行したいと思います。また、ほとんどのファイル書き込みが行われる場所でもあります。私のデバイスにはバッテリーが搭載されていないので、誰かが電源を切断したときにクラッシュプルーフであることを確認する必要があります.

興味のある方のために、Linux オプションは kernel/fs/ext3/Kconfig で定義されています。特定のオプションは EXT3_DEFAULTS_TO_ORDERED です。

ジャーナリングファイルシステム（JFS）はメタデータのジャーナリングのみを行うことを知っています。

しかし、LinuxでのJFSは、ext3ライトバックモードまたは順序付きモードのように機能しますか？

私は、DBMS (MySQL) で「トランザクション ジャーナリング」を使用する必要があるプロジェクトに取り組んでいます。別の要件のためにトランザクションを使用するために、すでに InnoDB の使用に切り替えています。トランザクションジャーナリングとは何かを理解しようとしています。MySQLのドキュメントを読むなど、1日以上検索しています。適切なキーワードを探していないだけかもしれませんが、よくわかりません。あるいは、「トランザクション ジャーナリング」は不適切な用語かもしれません。

私の理解では、データベース トランザクションのジャーナリングは、ファイル システムにコミットされる前にジャーナルに変更が加えられるという点で、ジャーナリング ファイル システムに似ています。私が読んだところによると、InnoDB エンジンはトランザクションがディスクにコミットされる前に何らかのジャーナルに保存されているようです。これは正確に聞こえますか？もしそうなら、取引ジャーナルはどこにありますか? ib_logfile0 と ib_logfile1 ですか?

これが私の見解であり、それが正しいか間違っているかはわかりません。

ジャーナリング ログは「やり直し」ログです。データファイルの変更を記録します。

たとえば、1 つのレコードのフィールド値を 'a' から 'b' に変更したい場合、mongodb は dbfile を変更する方法 (すべての名前空間、データ、インデックスなどを含む) を見つけてから、mongodb は次のように書き込みます。ジャーナルの修正。

その後、mongodb は dbfile に対するすべての実際の変更を行います。ここで何か問題が発生した場合、mongoDB の再起動時にジャーナルが読み取られます (存在する場合)。次に、dbfile を変更して、データ セットの一貫性を保ちます。

そのため、ジャーナルには、変更するデータは記録されませんが、代わりに dbfile を変更する方法が記録されます。

私は正しいですか？ジャーナルのフォーマットに関する詳しい情報はどこで入手できますか?

ext3 および ext4 ファイル システムにはジャーナリングがあります。ファイルに関する詳細やイベントを取得するための API がある可能性はありますか?

ユーザー空間プログラムがファイルのジャーナル項目にアクセスできるようにするある種の API。または、「ファイル x が削除されました」などのジャーナル イベントも。

これはある種のドキュメントのようですが、それが正しいものかどうかはわかりません。

Exchange 2010 でジャーナリングを使用して、ハブ トランスポートを通過するすべての電子メールを 1 つのメールボックスに入れています。これらのメールでは、受信者、送信者、件名、およびメッセージ ID を取得します。どうすれば体を手に入れることができるでしょうか？