[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


5. システムの概要

それぞれの Coda クライアントは Coda のファイルシステムを /coda という単一のツリーとして見ます。 実際には、このツリーは システム・コントロール・マシン (SCM) といくつかの専用ファイルサーバ、ローカル・エリア・ネットワーク によってサポートされているものです。一つのサーバは (SCM) として二重になります。 図 XXX はサーバの構成を示しています。

典型的な Coda サーバの構成

5.1 構成

Coda のアーキテクチャは、クライアントサーバシステム・コントロール・マシン (or SCM) の3つから構成されます。 クライアントのマシンは、共有情報にアクセスするために使われるシングル・ユーザのワークステーションです。 これらのマシンは、認証されたログインのセッションが有効な間を除いて、サーバからは信用されません。 サーバ・マシンは共有データに対するクライアントのリクエストにサービスを提供する目的の、セキュアで信用されたマシンです。 共有情報の管理で、ユーザのクライアント・ワークステーションに共有情報を解放する前に、サーバはそれぞれのユーザに認証を要求します。 3つ目はシステム・コントロール・マシン (SCM) です。SCM は管理を楽にするための制御をします。 必然的に、SCM はサーバとは別個になりますが、物理的にはサーバとして動きます。

5.2 プロセス

それぞれの専用ファイルサーバではたくさんのプロセスが走っていなければなりません。これらのプロセスについては、図 XXX と以下に述べます。


ファイルサーバのプロセス
codasrv プロセスはクライアントの venus プロセスと相互に働きます。共に、サーバにある共有データに対するユーザのリクエストを 実行します。起動時にサーバプロセスは、ファイルシステムを持ち出します。 /vice/srv ディレクトリにある SHUTDOWN というファイルは、 サーバが正常終了したことを示します。
認証サーバ・プロセス auth2 プロセスは全てのサーバで走ります。これはユーザのパスワードを有効にして、パスワードが正しければ ユーザに対してトークンを出します。パスワードを SCM 以外で変更することはできません。 それ故、パスワードのデータベースは全てのサーバに読み込み専用でレプリカされて、SCM はレプリカの読み書きを 管理します。パスワードファイルに対する変更は、以下に示される updateclnt/updatesrv プロセスを通じて 自動的に更新されます。全てのサーバ (SCM を除く) で auth2 は -chk オプションで呼び出されます。
アップデート・クライアント・プロセス updateclnt プロセスは、(SCM で走る)updatesrv プロセスと共に働きます。 システムファイルの読み込み専用コピーと、読み書きをするコピーと同期を取っているデータベースを管理するためです。 updateclnt プロセスはこのサーバにある読み込み専用のコピーが最新であるようにするために、SCM では定期的に theupdatesrv プロセスでチェックします。 このように、読み書きをするコピーが更新されると、読み込み専用のコピーは若干の遅れの後自動的に更新されます。
サーバ・プロセス

XXX は走っているファイルサーバの典型的なプロセスを示しています。

  PID TT STAT  TIME COMMAND
    0 ?  R <   53hr  (kernel idle)
    1 ?  SW    0:00     init -a (init)
    2 ?  U <  10:00  (inode_pager)
    3 ?  S <   0:00  (device pager)
    4 ?  S <   0:00  (device server)
    5 ?  S     0:00  (exception hdlr)
    6 ?  SW    0:00 /etc/mach_init -a
  152 ?  SW    0:00 updatesrv       -s -p /vice/db
  156 ?  SW    0:00 auth2
  179 ?  SW    3:19 /etc/update
  182 ?  SW    0:00 /etc/cron
  190 ?  SW    0:07 /usr/cs/etc/nanny -init /usr/cs/etc/nanny.config
  202 ?  SW    0:00 /etc/inetd
  203 ?  SW    0:07 /etc/named
  204 ?  SW    0:00 /usr/cs/etc/supfilesrv
  205 ?  SW    0:00 /usr/cs/lib/lpd -l
  206 ?  SW    0:00 RFS Listener.
 1217 ?  SW    0:00 sh /vice/bin/startserver
 1222 ?  S     6:56 codasrv           -time -maxworktime 15 -nodumpvm -trunc 1 -rvm
/dev/rrz3c /dev/rrz0h 69206016
 1358 t0 R     0:00 ps axww

5.3 データの配置

Coda サーバにある情報はいくつかのディレクトリによって構成されています。 ディレクトリは以下の通りです。

これらのディレクトリにあるファイルの詳細については、XXX の章にあります。

5.4 ファイルシステムの一貫性

クラッシュの後、Coda の多くのサブシステムはファイルシステムの一貫性を維持するためにチェックされます。 Coda のデータ・パーティションが内部的に一貫性があることを確認するために、fsck の CMU による改良版がリブート時に走ります。 名前ではなく inode によって Coda はファイルにアクセスします。普通の fsck はファイルに名前がないせいで、無視してしまします。 初期化の間にファイル・プロセスによって走る salvager は、あらゆる inode が少なくとも一つの Coda ディレクトリに参照されている ことを確認します。このように CMU の fsck とサルベージは、fsck が Unix のファイルシステムで普通に行うようなことをします。 fsck が Coda のファイルシステムで十分なチェックをしない理由は、Coda のディレクトリを認識しないからであって (Coda ディレクトリは Unix ファイルシステムの通常ファイルとして現れる)、inode を参照するチェックができないからです。


Next Previous Contents

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

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