次のページ 前のページ 目次へ

9. InterMezzo はどのように動作しますか?

InterMezzo はかなり Coda から着想を得ており、現在のキャッシュ同期プ ロトコルは Coda がサポートする多くのプロトコルの一つです。すべての状況で 最良であるとは言えませんが、それを簡単に行うことができるものです。

InterMezzo ファイルシステムは同期させられた複数のホスト上のファイルの集 合を保持します。各ホストのネイティブファイルシステムの上に位置し、複数の ホスト間の変更を同期させることができるような方法で、更新を把握します。こ の文書で、同期されたファイルを保持するために InterMezzo が用いるアーキテ クチャおよびプロトコルを記述します。

9.1 一貫性と粒度

InterMezzo はファイルシステム間の非常に緩い一貫性だけを保証します。 ファイルは完全なユニットとしてのみ扱われ、ファイルが書込みでクロー ズされるまで変更は広められず、あるシステム上の変更は別のシステムに 直ちに反映する必要もありません。InterMezzo 1.0 ではファイルシステ ム全体が複製され、どの時点においてもあるホストだけがそのファイルシ ステム向けの書込みロックを持つことが可能です。

9.2 intermezzo.o、カーネルモジュール

Presto は InterMezzo 用のカーネルモジュールです。VFS 下の InterMezzo ファイルシステムに関連した様々な動作を実行し、Lento と のやり取りのための仮想デバイスを作成します。

9.3 Lento

Lento はユーザ空間のデーモンで、ファイル転送および presto に代わっ て他のキャッシュ関連を扱います。マウントされた InterMezzo ファイル システムにつき Lento が一つあります。

9.4 KML ファイル

マウントされた InterMezzo ファイルシステムにつき一つの KML ファイ ルがあります。KML ファイルはファイルシステムの変更のレコードを含み、 KML ファイルを全体的に見ると、ファイルシステム全体の複製を構築する ためのスクリプトと規定できます。

KML ファイルは一連のバイナリレコードで、その各々はファイルシステム に対する一つの修正を表わします。各レコードは他のレコードと関係がな い点で自給自足で、レコードを容易に動かせるのが特徴です。レコードは 可変長で、ファイルの中で前後に動かし安くするために、レコードの長さ は各レコードの最初と最後に格納されます。許される KML レコードフォー マットの完全な記述はまだ存在しません。

9.5 Last_rcvd ファイル

マウントされた InterMezzo ファイルシステムにつき一つの Expect ファ イルがあります。Expect ファイルは、このホストおよび他のホストの KML ファイルへのポインタを保持することにより、このホストが他のホス トと同期する方法についての情報を含みます。この情報はファイルシステ ム内に格納されるので、リブートされてもこれは永続性があります。

Expect ファイルはリモートホスト用にそれぞれ四つの情報を持ちます。

  1. next_to_expect 私たちに送られることを期待するリモートホ ストの KML ファイル内の次のレコードへのポインタ。この値で始まら ないレコードの組みを得た場合、メッセージがどこかで落とされ、その ホストとの再交渉が必要です。これはヒントではありません。
  2. next_to_send リモートホストへ送る予定の私たちの KML ファ イル内の次のレコードへのポインタ。データが受信され処理されたこと の確認が得られた時ではなく、別のホストへデータを送ったらすぐに next_to_send を進めるので、これは単にヒントです。KML レコードを リモートホストに送る場合、レコードが私たちの KML のどこにあるか リモートホストに伝えるために、next_to_send の値を送ります (以下 の gap を加算します)。
  3. confirmed リモートホストが受信および処理したことをまだ 確認 (confirmed) していない私たちの KML ファイル内の次のレコード の始まりへのポインタ。これはヒントではありません。
  4. gap リモートホストへレコードを送る前に next_to_send に 加える調整。これは、外部的に見えるファイル位置を保持しながら、私 たちのローカル KML ファイル内でレコードを前後させます。これはヒ ントではありません。

9.6 KML および Expect ファイルの正当な変換

一貫性を維持するために、KML および Expect ファイルに対するある特定 の変換だけが許可され、一般にシステムを一貫した状態に確実にしておく ため、一緒にトランザクションを利用して行わなければなりません。

  1. KML ファイルにレコードを追加する。これは通常の VFS ファ イル操作の最後に利用される操作です。レコードは KML ファイルに追 加され、Expect ファイルに対する修正は行われません。
  2. リモートの KML レコードを組込む。ローカル KML ファイル に対する操作の実行およびレコードの追加に加え、そのホスト向けの next_to_expect を増加します。KML および Expect ファイルを修正し ます。
  3. リモートホストへ KML レコードを送る。KML レコードのブロッ クは next_to_send から始まる KML ファイルから読まれ、リモートマ シンへ送信されます。next_to_send は読まれたバイト数の分増加され ます。KML ファイルのこのセクションの読出しロックを効果的に得ます。 KML は読まれますが修正されず、Expect ファイルは修正されます。
  4. KML 処理の確認を受取る。受信および処理されたレコードの ポインタと特定のバイト数の組みからなる確認をリモートホストから受 取ります。これらのオフセットはリモートホストからなので、そのホス ト向けの gap を引き、次に confirmed ポインタと考えているものと比 較し、その後 confirmed ポインタを動かさなければなりません。KML の修正はありません。
  5. KML ファイルのセクションを最適化する。最適化するために セクションの書込みロックを取得し、セクションの中を読出し、私たち が望む最適化を実行し、それを再び書込みます。新しく書かれたセクショ ンは前と比べ大きくなってはならず、より小さい場合、NOP ブロックが 新しいセクションの前後の領域を満たすため挿入されます。このセクショ ンが KML ファイルの終わりにある場合、KML ファイルは終わりにある NOP ブロックを削除することで切り詰めることができます。その後書込 みロックは解放されます。KML ファイルは修正され、Expect ファイル は修正されません。
  6. KML ファイルのセクションを打抜く。削除されるセクションは 顕著な読出しもしくは書込みロックを持ってはならず、その中に NOP レコードを持つことだけができます。その後、ファイルシステムのマジッ クは希薄なファイルを形成する適切なファイルブロックを解放します。 Expect ファイルは変更されません。
  7. KML ファイルの前面を切り詰める。希薄なファイルを形成す る代わりに、KML ファイルの始めを削除できます。前記の打抜く操作と 同様に、削除されるセクションは顕著な読出しもしくは書込みロックを 持ってはならず、NOP 操作だけ持つことができます。その後、ファイル は切詰められ、すべてのリモートホスト用の gap の値は一つのトラン ザクション内で調節されます。
  8. KML ファイル内の NOP ブロックをスキップする。 next_to_send と confirm の両ポインタは NOP ブロックの開始を指し ているはずです。その後 next_to_send, confirm, gap のすべてを NOP ブロックの大きさ分増加できます。変更は KML ファイル内で行なわれ ません。


次のページ 前のページ 目次へ