• Summary
• Release and Beta Schedules
• What is supposed to work, what isn't
• Milestones with planned features
• Unplanned features

なにか抜けている点に気づいた場合は、メーリングリストへ。

なお、われわれは最終的には計画通りLentoのサポートを打ち切る予定であって、 InterSyncに移行します。InterSyncはキャッシュマネージャであって、 httpベースのプロトコルを使ったサーバ（訳注：いまのところApache）と協調動作します。 こちらのほうが、使い勝手がよくインストールも容易です。 将来的には、TUXをHTTPサーバとして使い、これにInterSyncがキャッシュマネージャとして 協調動作する、といった将来計画があります。InterSync[PDF]

カーネルコードはすでにある程度の完成度を達成していますが、 やはり、よりきれいに書き換えたり、バグを取ったりすることは必要ですし、 InterSync関係でもいくつかの機能の追加は必要です。また、 徐々にですが、グローバルなネームスペースの機能を追加する計画もありますし、 今までとは異なるファイルロック機構の導入の計画もあります。

Releases

Version	Date	Key aspect	Components
1.0.6	12/15/01	2.4 カーネルにおける安定性	Kernel (2.4 & 2.2) and Lento
is0.1.0	2/28/02	Apacheをhttpをつかった InterMezzo プロトコルのサーバとして採用。また、 基本的な同期アルゴリズムも完成。	Kernel (2.4) InterSync

Betas

Releases	Name	Versions	Date	Key aspect
is0.1	beta1	is0.0.2	1/31/02	ほぼバグは出尽くした。

どのバージョンで何が動くか?

うまく動く（といいなぁ）	いまのところ動かない
1.0.0 - 1.0.6
バックアップやミラーとしてサーバをコピーする	頻繁な更新（遅いけど）
複数のクライアントをもつファイルサーバ。あまり頻繁な更新をしない。	コンフリクトの解決。手動で解決しないといけない。
Rsync による同期	NFS server の同期 (バグが多く遅い)
Samba サーバ、ウェブサーバの同期	データ、メタデータの部分的なキャッシュ
ssh / IPSec の導入、ACLの活用などでのセキュリティ向上	レプリケーションログの自動的なローテート。 その後の自動的な同期。
ext3 への 対応	ext2/3 以外のファイルシステムへの対応
Linux 2.2 & 2.4	TCP/IPパフォーマンスのチューニング
InterSync 0.1
通常のファイルシステムに、InterMezzo的な同期システムを導入する。 これらは、大規模な分散ファイルシステムに応用できるとよい。	パーミッションの管理
ノート型PCで切断状態からの復帰における同期処理を実装する。 とうぜん、衝突矛盾の解消がメイン。	データオンデマンド（訳注：コピーオンライトみたいな技術） をつかった部分的キャッシュ
mv の高速化	KML truncation (訳注：KMLという、DBでいえばREDOログのようなものが大きくなったときにデフラグのような処理をする）
あたらしいミラー先の追加に伴う同期処理の自動化	ネットワーク上のファイル転送に関するチューニング
非接続状態における変更の衝突の解決を、 矛盾点を単に削除するという単純な方法にかぎって自動的に解決する。	設定管理ツール
	バージョン管理システムの分岐管理システムの完成

Branches

InterMezzoは、ファイルのバージョン管理（分岐ふくむ）や ファイルツリー全体のスナップショットなどを簡単に実現できます。 これらは、ファイルサーバの管理やバックアップに有用でしょう。 変更は管理ツール関係が多いです。また、InterSyncでも、 こまかいKMLと変更されたファイルのセットを管理し、 ここから作られた本体に対し、差分情報を管理していく、 といったアルゴリズムの実装が必要となるでしょう。

Kernel locking model

VFSがロックした inode をInterMezzoで アンロック する計画です。 このための方法として、現在のところ、以下のような方法が適切だと 考えています。 全体として、二つの部分にわけられます。 一つ目の部分は、VFSが 処理対象の inode を決定するときに、 必要な情報をInterMezzoにも告知します。 これにより、InterMezzoは、VFSが処理を開始する前に、 ファイルロックなど必要な処理を行うことが可能です。 二つ目の部分は、inode を二つ持つことです。 ひとつめは普通の inode ですが、 もうひとつ inode をもち、こちらはキャッシュされている inode となります。このキャッシュされた inode は ロックされません。矛盾の回避はコンフリクト同期ツールで行われるでしょう。

Conflict resolution

InterSyncの論文にもあるように コンフリクト（衝突）問題に対する改良の計画があります。 コンフリクトした部分を削除して再構築する、といった形で コンフリクトを解決するようなアルゴリズムになるでしょう。

Global Namespaces

１万ものファイルセットをひとつのディレクトリツリーに統合する 方式を考えています。lustreの方法を使い、グローバルなネームスペースを つくり、そこに統合します。 lustre[HTML]

Different or no pseudo devices

カーネル空間との通信の構造ですが、 特殊なデバイスを使わないようにしたほうが よりシンプルな設計になります。 autofs のようにパイプで行うというのも一案です。 devfs/procfsのようなファイルシステムを用いるのも一案でしょう。 しかし、この方法は結局は特殊デバイスを設定することには変わりないです。 多分、InterMezzoファイルシステム上になにか特殊なファイルをうかべて、 それを用いて通信をする、といった方法に落ち着くでしょう。

Monitoring tool

ノート型PCなどでは、回線の切断、再接続、コンフリクトの発生などを モニタできるツールがあると便利です。 この手のツールの例としては、Codaはよく考えられているがまともに動かないツールを持っています。

Support for other FS's

ReiserFS, JFS, XFS and JFFS2 はサポートします。 ReiserFS に関しては作業中です。それ以外に関しても、基本的アルゴリズムとして 問題があるわけではないので、書くべきコードを書けば動くはずでしょう。

Fine grained locking

いまのところ、ロックの粒度はファイルセット単位です。 InterMezzoの現実的な応用例を考えればそれはそんなに問題ではないのですが、 しかし、AFS/Codaのようにファイル単位のロックも考えています。

Metadata caches

メタデータの変更まですべて キャッシュできるか？ 答えはイエスです。しかし、非常な困難があります。 かなりコードを書き換え、KMLにあるメタデータ関連のデータの有効性を 検査できるようなキャッシュなりデータベースなりを作る必要があります。