[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


3. よくあるシナリオ

あなたが出くわすシナリオがいくつかあるかもしれません。 この章では可能な限りたくさん示して、それにどう対応するのかを記述します。

3.1 ホードファイルの構築

Coda はキャッシュ・マネージャに影響するファイルに優先順位を付けることができます。 プライオリティが高いと、ファイルが他のファイルにスペースを作るためのキャッシュから流れる可能性が低くなります。 この優先権は Venus に対するホード・データベース内部に保存されます。このデータベースは Venus の実施を超えて 保存されますが、Venus が再初期化されると消されます。

ホード・データベースをセットアップする一番良い方法は、ホードファイルを作ることです。 一度ファイルを作ってしまえば、ファイルの設定をする必要はありません。 手動か、あるいは spy というプログラムを使ってホードファイルを作ることができます。 詳しくは HOARD(1) の man ページを見てください。

spy を実行するには:

  1. バックグラウンドで spy を走らせて、その出力をファイルにリダイレクトします。
  2. 全てのプログラムを走らせて、ホードしたいファイルにアクセスします。
  3. spy に SIGTERM を送信します。 (^C を使ってはいけません)
  4. 出力ファイルをソートして、複製を外します。
  5. 必要のないエントリを外します。
  6. それぞれの行の最初に a を追加して、行末に優先権を追加します。

以下は gnu-emacs でホードファイルを作成した例です。gnu-emacs を走らせている間、"scribe mode" を入力していることに注意してください。 これは scribe 指定ファイルがフェッチされるのを確実にします。


% spy > gemacs.out &
[1] 316
% gnu-emacs
% kill %1
%
[1]    Done                 spy > gemacs.out
sort -u gemacs.out > gemacs.hdb
% cat gemacs.hdb
/coda
/coda/i386_mach/omega/usr/local/emacs
/coda/i386_mach/omega/usr/misc/.gnu-emacs
/coda/misc/gnu-emacs/i386_mach/omega/bin/gnu-emacs
/coda/misc/gnu-emacs/i386_mach/omega/lisp/scribe.elc
/coda/misc/gnu-emacs/i386_mach/omega/lisp/term/x-win.el
/coda/misc/gnu-emacs/i386_mach/omega/lisp/x-mouse.elc
/coda/usr

次に、必要ないのでファイルの最初の行と最後の行を消します。 それから hoard 指定コマンドを追加します。 最終的に、ファイルはこのようになります:


a /coda/i386_mach/omega/usr/local/emacs 600
a /coda/i386_mach/omega/usr/misc/.gnu-emacs 600
a /coda/misc/gnu-emacs/i386_mach/omega/bin/gnu-emacs 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/scribe.elc 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/term/x-win.el 600
a /coda/misc/gnu-emacs/i386_mach/omega/lisp/x-mouse.elc 600

a で始まっている行は、ホードがファイルをデータベースに追加するようにします。 600 で終わっている行はファイルの優先権を設定します。それぞれの行に追加の属性を指定することもできます。 これらの属性は":"で優先権と区切ります。

例えば、emacs ディレクトリとその子孫、将来の子孫をホードするには、ホードファイルに以下の行を挿入します:


a /coda/i386_mach/omega/usr/local/emacs 600:d+

これで必要なファイルを全て入手することができますが、必要のないたくさんのファイルをホードするために数十メガバイトを使うことになります。 ホードするファイルに関する指定をしたくなるかもしれません。

hoard に対する他のコマンドは clear、delete、list、modify です。 これらのコマンドについて詳しくは hoard(1) の man ページを見てください。

3.2 週末のホーディング

Coda の使い方の一つとして、一晩、あるいは週末に家にラップトップを持って帰るというのがあります。 当然、週末にかけて必要としているファイルの全てをキャッシュにします; そうでなければラップトップを家に持ち帰る意味がありません。 hoard(1) プログラムはこれができます。あなたが作業を行いたいそれぞれのプロジェクトについて、 XXX の章に書かれているようにホードファイルを作ります。 ホームディレクトリのような個人のファイル、あるいは使いたいツールが Coda にあれば、ホードファイルが欲しくなるでしょう。 キャッシュに十分な空きを作るには、プロジェクトを切り替えるとホードデータベースを消去するようにするのがベストです。 個人的なホードファイルに、まず clear コマンドを使うことが考えられます。 これをやると、他のファイルの前にこのファイルでホードが走るのを確認してください。 使いたいツールやプロジェクトの全てに関して一度ホードファイルを作ると、ホードデータベースを作るためにホードを走らせるのが簡単になります。 hoard を走らせるときには、マシンのコンソールにログオンしなければなりません(X を走らせないで)。 出る準備ができる 15 分前に、以下のコマンドで hoard walk します:


% hoard walk

これで、venus はホードデータベースに全てのファイルをキャッシュするようにします。 ホードコマンドが終了するまで待って下さい。これでネットワークから切断する準備ができた訳です。 切断した後使うつもりの全てのコマンドを試すように促されます。もしファイルのいくつかを失っても、再接続してそれをホードするのが簡単になります。

3.3 切断操作後の再統合

切断セッション後にネットワークに再接続すると、Coda は自動的に Coda サーバとあなたの変更を再統合しようとします。 再統合をする前に認証されていなければなりません。codacon コマンドか、以下を実行することで /usr/coda/etc/console ファイルを見ます: tail -f /usr/coda/etc/console. 再統合ステータスはこのファイルに書かれます。

再統合が成功すると、ログはこのようになります:


Reintegrate u.raiff, (1, 244) ( 13:33:43 )
coda: Committing CML for u.raiff ( 13:33:43 )
coda: Reintegrate: u.raiff, result = SUCCESS, elapsed = 2640.0 (15.0, 2609.0, 
15.0) ( 13:33:43 )
coda:   delta_vm = 0, old stats = [0, 1, 0, 0, 0] ( 13:33:43 )
coda:   new stats = [   0,   0.0,     0.0,    1,   0.2], [   0,   0.0, 0.0,  
 0,   0.0] ( 13:33:43 )

以下の例は u.raiff というボリュームの再統合に失敗した例です。 The following example is from a failed reintegration on the volume u.raiff.


Reintegrate u.raiff, (1, 244) ( 13:27:10 )
coda: Checkpointing u.raiff ( 13:27:10 )coda: to /usr/coda/spool/2534/u.raiff@@%
coda%usr%raiff ( 13:27:10 )
coda: Aborting CML for u.raiff ( 13:27:10 )
coda: Reintegrate: u.raiff, result = 198, elapsed = 2437.0 (15.0, 2265.0, 531.0)  ( 13:27:10 )
coda:   delta_vm = 1000, old stats = [0, 0, 1, 0, 0] ( 13:27:10 )
coda:   new stats = [   0,   0.0,     0.0,    1,   0.2], [   0,   0.0, 0.0,   0,
   0.0] ( 13:27:10 )

change modify log (CML) が /usr/coda/spool/2534/u.raiff@@%coda%usr%raiff にチェックポイントされていることに 気を付けてください。このファイルは切断セッションの間に変更があった tar ファイルです。tar ファイルにあるファイルは u.raiff の root に相対するものです。cfs examineclosurecfs replayclosure はどのファイルが再統合されていないかを示して、 個々に再統合しようとします。

3.4 変則的なネットワークへの対応

ネットワークの調子がおかしくなると、ネットワークの問題から切り離して Coda を使うことができます。 ホードデータベースをセットアップすると、Venus はあなたが作業しているファイルをホードします。 それから、cfs disconnect コマンドで Coda サーバから切断します。 Coda にとっては、ネットワークからの物理的な切断と同じです。

一旦ネットワークが安定したら、cfs reconnect を使って Coda サーバに再接続して、作業分を再統合します。 一度ホードしたファイルのセットで作業したら、hoard clear でホードデータベースを消去するのを忘れないでください。

注: AFS は cfs の影響を受けません。AFS ファイルへのアクセスはネットワークの問題に左右されます。

3.5 電話線からの再統合

出張などで Coda のラップトップを使うなら、SLIP を使って Coda サーバと定期的に再統合するのが良いでしょう。 SLIP を使うことで、他の Coda ユーザに見えるように更新して、ハードディスクの故障や盗難のようなクライアントのクラッシュから保護して、 様々なプロジェクトで作業できるようになります。キャッシュスペースが全てのプロジェクトに対して十分でなくてもです。 以下の手順で、電話越しの再統合とホードデータベースにあるファイルの変更が可能になります。

1. dialup man ページと以下を読んでください。 /afs/cs/help/03-Communication/03-Tcons_and_Dialups/slip.doc /afs/cs/help/03-Communication/03-Tcons_and_Dialups/cisco_tcon.doc

2. ターミナル・サーバでアカウントを入手するのが楽な方法です。 このサーバは slip を起動した時に使う名前です。

3. ターミナルサーバに接続して、slip を起動します。

4. /etc/slattach /dev/com{0,1} の速さで走らせます。 もし内蔵モデムを使っているのなら、/dev/com0 と 2400 を指定してください。 外部モデムなら /dev/com1 と適用な速さ (9600) を指定してください。

5. コミュニケーション・プログラム(kermit など)を終了してください。 slattach は行をオープンにしたままにします。

6. ルーティング・テーブルでルーティングを設定し直します。 まず、古いルーティングを消します:


% set slipaddr = 128.2.254.129 # address of ts2.srv.cs.cmu.edu
% set gwaddr = 128.2.254.36    # address of gw.cs.cmu.edu

% /etc/route delete 0 $gwaddr
% /etc/route delete net 128.2 $hostaddr
% /etc/route -f delete $hostaddr $hostaddr

そして、新しいルーティングで slip のインターフェースを設定します:
% /etc/ifconfig sl0 $hostaddr $slipaddr -trailers up
% /etc/route add net 128.2 $slipaddr 0
% /etc/route add 0 $slipaddr 1

切断を開始したら、コマンドを走らせます:
% ifconfig par0 down

最後に、通信できるのがどのサーバなのかを Coda に教えます:


% cfs checkservers

ラップトップはまるでネットワークに繋がっているかのように振る舞います。 コマンドに対するレスポンス・タイムは遅いです。

コンピュータをシャットダウンする前に SLIP を走らせるのをやめたいなら、単にモデムを切るか、 slattach を kill すれば SLIP の接続は終了します。

3.6 矛盾するディレクトリの修復

時々ディレクトリのエントリが矛盾する場合があります。 これは、ファイルサーバのレプリカとの間でコンフリクトが生じた時に起こります。Coda はグローバル・ステートでコンフリクトをローカルがアップデートしたせいで、自動解析ができなかったり、再統合に失敗したりします。よくあるコンフリクトの原因は、ファイルサーバが分割していて、ファイルが一つ以上の分割部分で 更新された時か、サーバでもアップデートされているファイルを、切断状態のクライアントがアップデートをした時です。 こうなった時に、コンフリクトのあるディレクトリはシンボリック・リンクのように見て、その fid にポイントします。 例えば、conflict というディレクトリが矛盾していれば、このように表します:


% ls -l conflict
lr--r--r--  1 root      27 Mar 23 14:52 conflict -> @@7f0000b3.00000005.0000011a

殆どのアプリケーションは、矛盾しているファイルを開こうとして File not found のエラーを返します。 このコンフリクトを解消するには repair(1) ツールを使います。

サーバ/サーバ のコンフリクト

一度 repair を走らせると、矛盾しているオブジェクトで"beginRepair"をする必要があります。 "beginRepair" が実行されると、矛盾しているディレクトリはそれぞれのレプリカのボリュームにエントリを持ちます。 欲しいのがどのコピーなのかを決定するために、これらの全てを見ることができます。 正しいバージョンをコピーするには repair を使って、矛盾を消去します。 以下の例では、conflict/example というファイルが3つのサーバでレプリカになっています。 それが矛盾してしまいました。


% ls -lL conflict
lr--r--r--  1 root           27 Dec 20 13:12 conflict -> @@7f0002ec.000000e3.000005d1
% repair
The repair tool can be used to manually repair files and directories that have 
diverging replicas.  You will first need to do a "beginRepair" which will expose 
the replicas of the inconsistent object as its children.  If you are repairing a 
directory, you will probably use the "compareDir" and "doRepair" commands.  
For inconsistent files you will only need to use the "doRepair" command.  If you 
want to REMOVE an inconsistent object, use the "removeInc" command.  Help on 
individual commands can also be obtained using the "help" facility.
* begin conflict
a server-server-conflict repair session started
use the following commands to repair the conflict:
        comparedirs
        removeinc
        dorepair
* ^Z
Stopped
% ls conflict
gershwin.coda.cs.cmu.edu        schumann.coda.cs.cmu.edu
% ls conflict/*
conflict/gershwin.coda.cs.cmu.edu:
example

conflict/schumann.coda.cs.cmu.edu:
example
% fg
repair
compare
Pathname of Object in conflict?  [conflict]  
Pathname of repair file produced?  []  /tmp/fix

 
NAME/NAME CONFLICT EXISTS FOR example

-rw-r--r--  1 raiff           0 Dec 20 13:10 gershwin.coda.cs.cmu.edu/example
-rw-r--r--  1 -101            0 Dec 20 13:11 schumann.coda.cs.cmu.edu/example


/coda/project/coda/demo/basic/rep/conflict/gershwin.coda.cs.cmu.edu/example
        Fid: (0xb0.612) VV:(0 2 0 0 0 0 0 0)(0x8002f23e.30c6e9aa)
/coda/project/coda/demo/basic/rep/conflict/schumann.coda.cs.cmu.edu/example
        Fid: (0x9e.5ea) VV:(2 0 0 0 0 0 0 0)(0x8002ce17.30d56fb9)
Should /coda/project/coda/demo/basic/rep/conflict/gershwin.coda.cs.cmu.edu/example be removed?   [no]  yes
Should /coda/project/coda/demo/basic/rep/conflict/schumann.coda.cs.cmu.edu/example be removed?   [no]  
Do you want to repair the name/name conflicts  [yes]  
Operations to resolve conflicts are in /tmp/fix
* do
Pathname of object in conflict?  [conflict]  
Pathname of fix file?  [/tmp/fix]  
OK to repair "conflict" by fixfile "/tmp/fix"?  [no]  yes
SCHUMANN.CODA.CS.CMU.EDU  succeeded
GERSHWIN.CODA.CS.CMU.EDU  succeeded
* quit
% ls conflict
example
% exit

ローカル/グローバルのコンフリクト

ローカル/グローバルのコンフリクトは、クライアントが切断している間に行われた変更が、 他のクライアントがサーバで行った変更とコンフリクトになって、再統合に失敗します。 ローカル/グローバルのコンフリクトになったオブジェクトは、サーバ/サーバのコンフリクトと同じように表されます。 すなわち、シンボリック・リンクです。

OBJ というオブジェクトに対してローカル/グローバルのリペア・セッションを行うには、repair ツールを呼び出して、引数として OBJ のパス名を 使った"beginrepair"コマンドを実行する必要があります。一旦リペア・セッションが始まると OBJ のローカルとグローバルの レプリカが OBJ/local (読み込み専用)と OBJ/global (変わりやすく、OBJ とその子孫に対するリペアの結果を保存する作業スペースとして使用) で見えるようになります。OBJ でのローカル/グローバルのコンフリクトをリペアする主なプロセスは local-mutations-list を繰り返すことです。 local-mutations-list には、"listlocal" コマンドによって表示される OBJ やその子孫で行われる全てのローカル・アップデートが含まれます。 リストでのそれぞれの操作が、繰り返された current-mutation の原因となって、リペア・ツールは、 繰り返された current-mutation を保存するために Venus と協力します。"checklocal"コマンドは current-mutation とグローバル・サーバステート との間でのコンフリクト情報を表示するために使われます。関連したグローバルなレプリカで、前者が current-mutation の操作を リプレーする"preservelocal"あるいは"discardlocal"コマンドのどちらかを使って、次の操作に繰り返しを進めます。 繰り返しをスピード・アップするには "preservealllocal" と "discardalllocal" コマンドを使うこともできます。 グローバルのレプリカ OBJ は変わりやすく、emacs 等のツールは直接、必要なアップデートを行うために使われます。 "quit" コマンドはリペア・セッションを任せるか、停止するために使われます。リペア・コマンドの詳しい情報は man ページにあります。 以下の簡単な例は、ローカル/グローバルのコンフリクトをリペアする主なプロセスを示しています。

切断状態という前提で、ユーザは新しいディレクトリ /coda/usr/luqi/papers/cscw/figs を作り、新しいバージョンのファイル /coda/usr/luqi/papers/cscw/paper.tex を保存します。しかし、切断の間に共同の作者が /coda/usr/luqi/papers/cscw/figs というディレクトリを作り、その中に PS ファイルをいくつか保存します。再統合の際、ローカル/グローバルのコンフリクトが /coda/usr/luqi/papers/cscw で検知されます。


% ls -l /coda/usr/luqi/papers/cscw would show 
lr--r--r--  1 root           27 Dec 20 00:36 cscw -> @@7f000279.00000df3.0001f027
% repair
* begin
Pathname of object in conflict?  []  /coda/usr/luqi/papers/cscw
a local-global-conflict repair session started
the conflict is caused by a reintegration failure
use the following commands to repair the conflict:
        checklocal
        listlocal
        preservelocal
        preservealllocal
        discardlocal
        discardalllocal
        setglobalview
        setmixedview
        setlocalview
a list of local mutations is available in the .cml file in the coda spool directory

* !ls -l /coda/usr/luqi/papers/cscw
total 4
drwxr-xr-x  3 luqi         2048 Dec 20 00:51 global
drwxr-xr-x  3 luqi         2048 Dec 20 00:51 local
Back to *

* listlocal
local mutations are:

Mkdir   /coda/usr/luqi/papers/cscw/local/figs
Store   /coda/usr/luqi/papers/cscw/local/paper.tex (length = 19603)

* checklocal
local mutation: mkdir /coda/usr/luqi/papers/cscw/local/figs
conflict: target /coda/usr/luqi/papers/cscw/global/figs exist on servers

* discardlocal
discard local mutation mkdir /coda/usr/luqi/papers/cscw/local/figs

* checklocal
local mutation: store /coda/usr/luqi/papers/cscw/local/paper.tex
no conflict

* preservelocal
store /coda/usr/luqi/papers/cscw/global/paper.tex succeeded

* checklocal
all local mutations processed

* quit
commit the local/global repair session?  [yes]  



Next Previous Contents

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

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