[an error occurred while processing this directive]

(Illustration by Gaich Muramatsu)

Coda File System

Home Downloads
(インフォサイエンス)
Bugs Documentation
News Mailing lists FAQ Research
 
---------

次へ 戻る コンテンツ


1. Coda の要素

1.1 Coda とは?

Coda は分散ファイルシステムです。すなわち、ディレクトリ・ツリーの一部のように、クライアント・コンピュータをファイルとして利用することができますが、 最後にサーバにあるファイルデータのコピーを保存します。Coda は際立ったいくつかの機能を持っています: 切断操作をサポートします。言い換えれば、 本意、または不本意にネットワーク・サーバが停止している間、キャシュされたファイルスペースにフルアクセスができます。Coda は再接続したときに、自動的に切断されたクライアントのふりをしていたのを、再び完全なものにします。更に Coda は読み書きを行い、failover サーバの複製、データが蓄積されてサーバの何らかのグループから取ってくることを意味します。そして、全てのサーバのサブセットだけが利用できるとき、Coda は操作を続行します。もしネットワークパーティションのせいでサーバの違いが生じると、Coda は自動的に可能な最大のエクステントにして、違いを解消し、自動的には行われない部分については、ユーザに助けを求めます。Coda は NFS や Windows/Samba の共有とは大きく異なっています。Coda は AFS、DCE/DFS との類似点が多いです。

1.2 Coda 特有の用語

単一ネームスペース

全ての Coda はクライアントの(あるいは Windows 下の単一ドライブ)単一ディレクトリ /coda に現れます。 Coda は個別にマウントされた NFS と Samba がするような、エクスポートや共有はしません。/coda 下にある、全てのサーバ(あなたの Coda セルにある)によってエクスポートされるファイル(及びファイルセット)のボリュームは目に見えるものです。Coda は自動的にサーバを探して、クライアントが知る必要のあるものは、Coda の root ボリュームをどのように検索するかの情報となる、ブートストラップ・サーバの名前だけです。

Coda セル

はサーバのグループが共有する設定データベースのセットです。セルは単一のサーバか、数百のサーバから構成されています。 一つのサーバは SCM として指定され、システムをコントロールするマシンです。全てのサーバに共有される共有設定データベースを、そのサーバだけが識別して、他のサーバにその変更を伝えます。現在 Coda クライアントは単一のセルに属します。セル機構を入手しようとすることによって、クライアントは様々なセルにあるファイルを見ることができます。

Coda ボリューム:

ファイルサーバはボリュームにあるファイルをグループ化します。ボリュームは普通、パーティションよりも非常に小さく、ディレクトリより全然大きいものです。 ボリュームは root を持っていて、ファイルのディレクトリ・ツリーを含んでいます。それぞれのボリュームは /coda 下のどこかに "Coda mounted" され、/coda の サブツリーになっています。ボリュームは他のボリュームのマウントポイントを含むことができます。ボリュームのマウントポイントは Unix のマウントポイントや Windows のドライブではありません - Coda のための単一ドライブか、Unix のマウントポイントがあるだけです。Coda のマウントポイントは、ボリュームにファイルを貯めるサーバを探すクライアントのために、必要な情報を持っています。ボリュームを提供するサーバのグループはボリュームのボリューム・ストレージ・グループと呼ばれます。

ボリューム・マウントポイント

あるボリュームは特別なもので、Coda が /coda をマウントする root ボリュームです。他のボリュームは cfs makemount を使った /coda ツリーになります。このコマンドは Coda のディレクトリ・ツリーにボリューム・マウントポイントをインストールします。実際には Unix でマウントポイントを作って、デバイスをマウントポイントにマウントするのと似た結果になります。 cfs makemount をすると、与えらる二つの引数は、マウントポイントの名前と、マウントされるボリュームの名前です。Coda のマウントポイントは持続的なもので、リブート後に回復させる必要のある Unix のマウントポイントとは異なります。

データ・ストレージ

サーバは NFS と Samba のようにローカルディスクのファイルシステムとしてボリュームを貯めたり、エクスポートしたりはしません。 Coda はサーバの複製と切断操作をサポートするために、より多くのメタ・データが必要で、ローカルディスクのファイルシステムでは行いにくい複雑な復旧ができます。Coda サーバは普通 /vicepa ディレクトリ下に、数字で識別されるファイルを蓄積します。メタ・データ(所有者、アクセス権、バージョン・ベクトル) とディレクトリ・コンテンツは、しばしば生のディスクパーティションになる RVM データファイルに貯められます。

RVM

回復可能なバーチャル・メモリー(Recoverable Virtual Memory)を意味します。RVM はディスクにあるプロセスを続ける仮想アドレス空間の部分を作るためのライブラリを基にしたトランザクションです。Coda はそのメタ・データを管理するために RVM を使います。このデータはスタートアップ時にメモリーにマップされる RVM データファイルに貯められます。修正は VM で行なわれ、トランザクションを引き渡した上で RVM LOG ファイルにも書かれます。 LOG ファイルは、まだディスクのデータファイルに組み込まれていない、引き渡されたデータを持っています。

クライアント・データ

はいくらか似たように貯められます: RVM (普通は /usr/coda/DATA) にあるメタ・データとキャッシュ・ファイルは /usr/coda/venus.cache に数字で貯められます。クライアントのキャッシュは持続します。このキャッシュはサーバにあるファイルのコピーを持っています。キャッシュはクライアントがデータに素早くアクセスできるようにして、クライアントがサーバに接続できなかった時にはファイルへのアクセスを許可します。

有効データのチェック(Validation)

サーバが再び接続可能になったことを Coda が検知すると、キャッシュされているデータがファイルの最新版であることを確認するためにそれを使う前に、キャッシュデータを有効にします。Coda は、サーバにあるもののスタンプと、キャッシュされたもののスタンプを比較します。

認証

Coda はトークンを通じて認証を管理します。Windows の共有と似ていて(細かい所は全く違う)、Coda はユーザにログインを要求します。 プロセスをログしている間、クライアントは正確なパスワードによって交換されたセッション・キーかトークンを手に入れます。 トークンはユーザ id と関連づけられていて、現在この Coda の id はユーザがログインを実行する uid です。

プロテクト

パーミッションを許可するために、キャッシュ・マネージャとサーバは id と結びついたトークンを使います。そして、アクセス・コントロール・リスト(ACL) にあるこの id に対して与えられた権利とマッチします。もしトークンがなければ、anonymous アクセスが想定されてアクセス・コントロール・リストを通してパーミッションが再び与えられます。

1.3 クライアントの構成

カーネル・モジュールとキャッシュ・マネージャー

あらゆるファイルシステムのように Coda を使えるコンピュータは Coda ファイルにアクセスするためにカーネルのサポートが必要になります。 Coda のカーネル・サポートは最小限で、キャッシュ・マネージャ Venus と共に動きます。ユーザのリクエストは、直接リプライするか、サービスを補助するために キャッシュ・マネージャ venus に頼むカーネルを入力します。

普通、カーネルのコードはカーネル・モジュールにあって、ブート時にロードされるか、Venus の起動時に動的にロードされます。 Venus は /coda に Coda ファイルシステムをマウントします。

ユーティリティ

acl、キャッシュ、ボリューム・マウントポイント、あるいは Coda クライアントのネットワーク挙動を操るためのユーティリティがいろいろあります。 cfs コマンドは非常に重要です。

Coda 認証サーバに対して認証をする clog プログラムというのがあります。 codacon プログラムはキャッシュ・マネージャの操作の監視を許可して、cmon プログラムはリストサーバについての概略を与えます。

1.4 サーバ構成

メインプログラムは Coda ファイルサーバとなる codasrv です。 ボリューム・ロケーション・サービスだけでなく、全てのファイル操作を行うものです。

Coda 認証サーバ auth2 はトークンのために clog からのリクエストをハンドルし、aucpasswd からのパスワードの変更をハンドルします。SCM の auth2 プロセスだけが、パスワード・データベースを修正します。

Coda セルにある全てのサーバは /vice/db にある設定データベースを共有し、変更が生じたときに SCM からそれを読み出します。 updateclnt プログラムはそのような変更を読み出し、なにか変更があれば確認のために SCM で updatesrv をポールします。 しばしば SCM は他のサーバから共有データベースを更新するために(非共有)データベースを必要とします。 updatefetch を使って、サーバにある updatesrv プロセスを通じてこれをフェッチします。

ユーティリティ

サーバにはボリューム作成と管理のためのユーティリティがあります。 これらのユーティリティはシェル・スクリプトと volutil コマンドから構成されています。 データベースを保護するためのツールもあります。


次へ 戻る コンテンツ

---------
詳しくはメールで

このページの情報に関わる、ご質問、お問い合わせは、 japache@infoscience.co.jpまで。
Coda ホームページ