[an error occurred while processing this directive]

(Illustration by Gaich Muramatsu)

Coda File System

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

Next Previous Contents


2. 導入

Coda ファイル・システムは Sun Network File SystemAndrew File System のようなファイル共有のローカルファイル・システムを拡張したものです。図 XXX は以下にファイルシステムの3タイプのファイル・システムの階層構造を示しています。

ワークステーションでの Coda ファイルシステム

Andrew にあるような Coda でのデータの共有は、分散ファイルシステムによってサポートされます。 それぞれのワークステーションでローカル・ファイルシステムの単一の大きなサブツリーとして現われるのが、分散ファイルシステムです。。 このサブツリーは全てのワークステーション上で同じになります。このように2つの異なるワークステーション上のプロセスはこのサブツリー でファイルを読み書きすることができます。ファイルを開いたり閉じたりした時にだけ、異なったワークステーションが変更を見る処理をすることで、 単一のタイム・シェアリング・システムで走っているように見えます。AFS に精通していれば、Coda を理解するのは楽です。

この章では Coda の基本的なコマンドを紹介します。これらのコマンドについて、詳しくは man ページを参照してください。

2.1 認証

ワークステーションにログインするとすぐに、clog プログラムが走って Coda の認証トークンの入手が必要となります。 clog は 入力されたパスワードにプロンプトを返して認証サーバからトークンを入手するためにそれを使います。 このトークンの期限は約 25 時間です。トークンの期限が切れると、また 25 時間分の認証のために clog を使う必要が あります。以下の例では、初めに間違ったパスワードを入力した場合です:


% clog
Password:
Invalid login (RPC2_NOTAUTHENTICATED (F))
% clog
Password:
% 

新しく得られたトークンを見るには、ctokens を使ってください。これはトークンと UID の有効時間を表示します。


% ctokens

Tokens held by the Cache Manager:

UID=2534 : [Expires Mar 19 10:50]

Coda のパスワードを変更する場合には cpasswd を使ってください。 passwd と同様に、cpasswd は現在のパスワードに対してプロンプトを返して、 新しいパスワードを2回入力することを要求します。


% cpasswd
Changing password for raiff
Old password:
New password for raiff:
Retype new password:
Password changed, it will be in effect in about 1 hour

Coda をログアウトするには cunlog コマンドを使います。cunlog コマンドは venus にトークンを消去させます。 unlog を走らせると、新しい認証トークンを入手するまでは anonymous の Coda ユーザと同じ権限になります。

2.2 Coda ファイルの保護

Coda は UNIX のプロテクション・セマンティクスの近似値を用意します。 アクセス・コントロール・リスト(access control list) (ACL) はユーザやユーザのグループに権限を与えたり制限したりすることによって、ディレクトリへのアクセスを制御します。アクセス・リストにあるエントリは、保護するドメインのメンバーの権限をマップします。 ユーザの権限は、彼または彼女が、直接あるいは非直接のメンバーである全てのグループの権限によって決定されます。 Coda のアクセス・リストとは別に、ファイルモードには 3 つのオーナー・ビットがあり、読み、書き込み、実行が可能かどうかを示すために使われます。 個々のファイルのパーミッションを設定するには chmod(1) を使います。Coda の権限は以下のように、rlidwka の組み合わせによって与えられます:

Coda はアクセスを拒否するネガティブ権限も持っています。上に表示されている権限のいくつかは、ネガティブにもなります。

アクセス・コントロール・リストは listaclsetacl オプションで cfs コマンドを使うことにより管理されます。 これらのコマンドはそれぞれ lasa のように省略することができます。 Coda のシステムファイルにあるディレクトリのアクセス・コントロール・リストを見るためには、cfs la を使います。 以下に例はカレント・ディレクトリの ACL を表示しています:


% cfs la .
      System:AnyUser  rl
               raiff  rlidwka

これを見ると、ユーザ"raiff"がディレイクトリに対するアクセス権を全て持っていて、"System:AnyUser" というグループが読みとルックアップの権限を持っているのがわかります。System:AnyUser は全てのユーザが含まれる、特別な Coda のグループです。

二番目の例は他のグループ、System:coda を示しています。グループのメンバーなら誰でも、そのグループのアクセス権を持ちます:


% cfs la /coda
         System:coda  rlidwka
      System:AnyUser  rl

ディレクトリのアクセス・コントロール・リストを変更したり、設定したりするには cfs sa を使って下さい。 ユーザにネガティブ権を割り当てるには cfs sa-negative というオプションを付けます。 新しいアクセス権を設定する前に完全にアクセス・リストを消去するには -clear というオプションを付けます。 全ての権利を与える、または与えない場合には allnone を使います。 カレント・ディレクトリで System:AnyUsers のアクセスを外すには、以下のコマンドを打って下さい:


% cfs sa . System:AnyUser none

System:AnyUser に読みとルックアップの権限を与えるために使います:


% cfs sa . System:AnyUser rl

ユーザの権限を拒否にするには -negative を使います:


% cfs sa -negative . baduser rl

これは "baduser" の読みとルックアップの権限を拒否して、他のユーザにはこの権限を許可します。 ネガティブな権限は通常の権限とは別々になっているので、badusers に対して読みとルックアップのアクセスを指定するために 使わなければならないことに注意:
% cfs sa -negative . baduser none

もし -negative を省略しても、"baduser" は読みとルックアップのアクセスは拒否されたままです。

2.3 切断操作

オブジェクトがあるサーバの全てがアクセスできなければ、クライアントは正当なレプリカとして、(もし存在すれば)キャッシュされたオブジェクトのコピーを使います。クライアントがこれを行う時には切断モードで操作します。

切断モードはネットワークの障害、あるいはネットワークからラップトップをは外したときに生じます。 使いたい全てのファイルがラップトップにキャッシュされていれば、ラップトップを持って外出し、あたかもネットワークに繋がっているかのようにファイルにアクセスすることができます。

不幸にも切断モードでのキャッシュミスがマスク可能でないと、connection timed out のエラーメッセージが出ます。 Coda は、キャッシュの中であなたが望むようなキャッシュのプライオリティでファイルをマークしたり貯蔵したりすることができます。

切断モードで、変更されたディレクトリを Coda が維持する修正ログをチェックポイントにすることができます。 これには cfs checkpointml を使います。修正ログのチェックポイントにすることで、もしシステムがクラッシュしてもあなたが行った変更が失われないようにします。サーバと一緒になると、Coda はこの修正ログを使います。

Coda はまた、低いバンド幅のアクセス・オーバー SLIP をサポートします。 定期的にサーバと一緒になるためにこれを使って、旅行中に新しいファイルをキャッシュできます。

切断モードにした後で再統合したら、codacon を見るか、コマンドを走らせます:


% tail -f /usr/coda/etc/console

このファイルは再統合が成功したことを知らせます。そうでなければ、修正されたファイルが /usr/coda/spool/<uid> の tar ファイルに置かれます。再統合に失敗するのは、例えば、切断モードでファイルを修正したとき、そして誰かがサーバにあるファイルを修正したときです。 再統合に関しては XXX が詳しいです

2.4 ホーディング

Coda はキャッシュに保存するべきクリティカルなファイルのキャッシュサーバ venus に通知できるようにします。 それらにプロパティを割り当てることによって、ファイルの相対的な重要度を設定します。これがホーディングと呼ばれるものです。 Venus はこれらのファイルの内部的なホード・データベースを管理します。ファイルのホードは切断モードの操作で確実に 利用できるようになります。 ホードファイルについてはhoard(1) の man ページを、ホード・データベースのセットアップについての例は、このドキュメントの XXXXXX を見て下さい。 ホード・データベースをセットアップする簡単な方法は、ホードプログラムのコマンドを使ってファイルを作ることです。 このファイルをホードファイルといいます。

2.5 リペア・コンフリクト

Coda の楽観的なレプリカ管理の結果、オブジェクト・レプリカが異なるサーバ間でコンフリクトを起こします。 同じオブジェクトが異なるネットワークの区画で更新されると、コンフリクトが生じます。 例えば、ファイルが二つのサイトでレプリカになっているとします(サーバ A とサーバ B)。 この二つのサイトが分離していて、それぞれの区画のユーザがファイルを更新すると(ユーザ A がサーバ A にあるファイルを更新して、ユーザ B がサーバ B にある ファイルを更新)、分離が終わったときにファイルはコンフリクトになります。コンフリクトは切断操作の終了時にも生じます。

Coda は両方のサーバがアクセス可能なときに、オブジェクトに対する最初のリクエストでコンフリクトの検出を保証します。 コンフリクトが見つかると Coda は自動的にコンフリクトを解析しようとします。単純な場合には、コンフリクトは自動的に解析されます。 オブジェクトへのアクセスのタイム・ディレイを除いて、プロセスはユーザに対してトランスペアレントです。 しかし、困難な場合には自動コンフリクト解析は失敗して、オブジェクトはコンフリクトにマークされます。 ファイル・システムは、コンフリクトで失敗しているオブジェクトを、オブジェクトがダングリングで、 読み専用のシンボリック・リンク(普通は ENOENT)であるかようなエラーで呼び出します。 コンフリクトはオブジェクトにアクセスしたユーザによって解析されなければなりません。 ユーザがコンフリクトを解消するには、XXX に書かれている Coda のリペアツールを使います。


Next Previous Contents

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

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