第 14 部

アーカイブサーバ617

第 1章
序論

1.1

はじめに

分散システムの重要性はますます高まってきている．マイクロプロセッサ技術の急速な進歩によって，マイクロプロセッサをベースとしたコンピュー
タは，大型機，ミニコンピュータに比較して，非常に強力かつ低価格になってきている．大規模なシステムをこのような小さなプロセッサをベースとしたコンピュータを多数用いて構成することは，様々な利点がある．まず，価格／性能の点で，以来の中央集中的なシステムと比較して優れている．
システムを必要に応じて成長させていくことができることも利点の一つである．計算能力を増やしたいときは，その分だけプロセッサの数を増やせば良い．信頼性という点でも以来のシステムより優れている．システムの一部が壊れても，その部分を利用していない人たちは，それによって影響を受けることはない．しかし，システムを多数のプロセッサから構成することによって周辺機器，計算機上の情報などの計算機資源は分散してしまう．そこで，中央集中的なシステムでの利点も残しつつ，分散化を進める
ためのシステムが分散システムである．ネットワークを通じて分散した計算機資源を共有することによって，中央集中的なシステムと同様の機能を提供する．
システムを利用するうえで，ユーザのファイルが複数のコンピュータに分散してしまい，利用するコンピュータによって，持つファイルが異なってしまうのは不便である．また，他のコンピュータからファイルをコピー（遠隔コピー）するにしても，同じファイルを同じネットワーク上の複数のコンピュータに持つのは無駄であるといえる．そこでこれらのファイルは分散（またはネットワーク）ファイルシステムによって，ネットワーク上で共有されるようになってきた．

LAN）は組織の巨大化，またワークス
ローカルエリアネットワーク（
テーションの大量導入によって大きくなり，発展してきた．また，各は電話回線などを用いて接続されていたのが，最近になって電話回線等と

619

LAN

620

1989 年度 WIDE 報告書

比較して高速な専用回線によって接続されるようになってきた．そのようの間でのファイルの転送は以前よりもはるかに容易な環境では，各をまたがってファイルの共有を行なうことも可能になっかつ高速で，てきた．
現在，ファイルのバックアップ，ファイルシステムのダンプ等には磁気テープが主に使用されている．しかし，磁気テープは速度，容量，使い勝
手，テープの保管の繁雑さといった点でバックアップ，ダンプのためのメディアとして満足できるものではない．普通に，ある期間おきにフルダンプをとり，その間はインクリメンタルダンプをとるとすれば，すぐに大量のテープがたまってしまうことになる．それらのテープの管理も大変であるが，それらのテープからリストアする場合はテープのかけかえだけでも大変である．
そこで，インターネットワーク上で大型の追記型の光ディスクド ライ
ブシステムを共有し，バックアップやダンプのために使用するということ）であるうえ，が考えられる．光ディスクは非常に大容量（コンパクトである．追記型（ 一度書き込んだものは消すことができない）
であるということは，バックアップやダンプのためにはそのファイルとしての性格上利点である．
本論文では，追記型の光ディスクを用いたシステムをインターネット
ワーク上でアーカイブファイルサーバーとして使用するため，追記型光ディ
スクの性質，アーカイブファイルサーバーの記憶メディアとして使用する
場合の考慮点，実装方法について議論する．

LAN
LAN

600800MByte

1.2

本論文の構成

本論文は，１章で，本研究の目的を述べ，２章では，背景となる技術について述べる．３章では，光ディスク及びジュークボックスの特性について述べる．４章では，アーカイブファイルサーバーの設計について考察
し，５章で，その実装方法について考える．

第 2章
背景となる技術

分散システムより以前の段階では，現在使用しているのとは異なるコン
ピュータ上のファイル（遠隔ファイル）を使用したいときは，そのファイル
をファイル転送コマンド を実行することによって，コンピュータ間でファイルを移動していた．分散ファイルシステムは，分散したコンピュータのファイルシステムを結び付けようとするものである．分散ファイルシステ
ムによって結びつけられたファイルシステムでは，遠隔ファイルを，ロー
カルなファイルと同様にアクセスすることができる．この時ファイルシス
テムは，複数のコンピュータのファイルシステムから構成されているということが，利用者からは見えない（透明である）ということが重要である．
この場合，ファイルシステムはいくつかの異なったファイルシステムの集合
ではなく，仮想的な一つのファイルシステムとして，ユーザに提供される．

2.1

NFS

UNIX [78] 上では，現在 Sun マイクロシステム社の NFS (Sun Network
FileSystem) [61] が広く使用されている．NFS はファイルシステムへの透過的な遠隔アクセスを提供するものである．NFS は，XDR(External Data
Representation) を機種やシステムに依存しない形でプロトコルを表現するために用い，また RPC(Remote Procedure Call package) の上に実装す1

ることによって，異なったオペレーティングシステムやアーキテクチャのは，クライアント・サー
機種に用意に移植できるように設計された．
バーモデルになっていて，リモートマシンのサーバーが，ローカルマシンのクライアントに対して，ある特定のファイルシステムを利用できるようにしている．

NFS

1

UNIX は AT&T の商標である

621

622

1989 年度 WIDE 報告書

2.1.1

設計目標

NFS は 、同種でない機種を結んだネットワーク上で以下のことを実現することを目標とした．

 機種とオペレーティングシステムに依存しない

NFS サーバーがいろいろな異なった機種のクライアントに対して，ファイルを提供することを可能にするため，使用されるプロトコルはからは独立であるべきである．また，パーソナルコンピュータのような低レベルの機種上にも実装できるように，プロトコルは十分にシンプルでなければならない．

UNIX クラッシュリカバリー容易さ
クライアントがたくさんの異なったサーバーからリモートファイル
システムをマウントできるならば，クライアントがサーバーのクラッ
シュから用意にリカバリーできることが重要になる．

 アクセスの透過性
プログラムから，リモートファイルをローカルファイルと全く同じ方法でアクセスできるようにする．特別なパスネームのパージングも，ライブラリも，再コンパイルも必要とはしない．プログラムは，ファイルがリモートであるかローカルであるか知らせることができるべきではない．

 クライアントでの UNIX のセマンティクスの維持

UNIX マシンでの，透過的なアクセスのために，UNIX ファイルシス

テムのセマンティクスはリモートなファイルに対して維持されなければならない．

 妥当なパフォーマンス

rcp
NFS

のような，以来のネットワークのユーティリティーと比べもし，て，が早くなければ，たとえ使用するのが簡単であっても，誰と同じも使用したくないであろう．
ぐらいのスピードを持つぐらい高速，またはローカルディスクのことが，目標となっている．
2.1.2

基本設計

NFS は，Sun Network Disk protocol(ND)80%

第 14 部

アーカイブサーバ623

 protocol server clientの，三つの主な要素から構成されている．
プロト コル

NFS プロトコルは以下のような特徴を持つ．
 RPC
NFS のプロトコルは，Sun Remote Procedure Call (RPC) を使用している．RPC を持ちいることによって，リモートサービスの定義，構成，実装が用意になっている．NFS プロトコルは，プロシージャ，その引数と結果，副作用の集合から定義されている．RPC は同期的に動き，ローカルマシーンでのプロシジャーコールと同じように動くため，非常に使用しやすいものになっている．

 ステートレス

NFS は，ステートレスプロトコルを使用している．それぞれのプロ

シージャコールへのパラメータは，その呼び出しを完了するために必要なすべての情報を含んでいる．そして，サーバーは，過去の要求についてのいかなる情報も蓄積しない．これによって，クラッシュからのリカバリーは非常に容易になる．サーバーがクラッシュした時，クの要求を帰ってくるまで送るだけである．クライライアントは
アントがクラッシュした時は，クライアントもサーバーもリカバリーのために，何も必要ではない．
しかし，サーバーにおいて，何らかの情報が維持されているならば，リカバリーはもっと大変になる．クライアントもサーバーも，クラッ
シュを確実に探知する必要がある．サーバーは，サーバーの持っているクライアントのための状態を廃棄するため，クライアントのクラッ
シュを見つける必要がある．そして，サーバーの状態を再構成するため，クライアントはサーバーのクラッシュを察知する必要がある．

NFS

ステートレ スなプロトコルを使用することによって，複雑なクラッシュからのリカバリーを避けることができ，またプロトコルをシンプルにすることができる．クライアントが，応答が帰ってくるまで，
単に要求を送り続けるだけならば，データはサーバーのクラッシュに

624

1989 年度 WIDE 報告書
よって失われることはない．実際に，クライアントは，サーバーがクラッシュしてリカバーしたのか，またはサーバーが遅いのか，クライ
アントは，それらの違いを見分けることはできない．

 トランスポートレイヤからの独立

RPC は，トランスポートに依存しないようにできている．そのため，上位レベルのプロトコルのコードに影響を与えることなく，新しいトのインプリメンテーションに埋めランスポートプロトコルを，込むことができる．

RPC

 XDR

NFS プロトコル,RPC は External Data Representation (XDR) のうえに作られている．XDR は，基本的なデータタイプのサイズ，バイ
トオーダー，アラインメント等を定義している．XDR を使用することによってプロトコルは機種や言語から独立になるだけでなく、定義することも容易になる．

NFS プロトコルでは，リモートマウントするための機能は提供していない．MOUNT プロトコルが，そのための機能を提供している．MOUNT
プロトコルは，ディレクトリのパスネームを引数としてとり，クライアン
トがそのディレクトリを含むファイルシステムに対するアクセスパーミッ
ションを持つならば，マウントのための情報を返す．リモートマウントのための機能を，異なったプロトコルにした理由は，プロトコルのオペレー
ティングシステムに依存した面を切り離し，また，新しいファイルシステ
ムのアクセスパーミッションの方法を採用することが容易になる，といったことである．
プロトコルプロシージャの概要は以下の通りである．

NFS

null() returns ()lookup(dirfh, name) returns (fh, attr)
create(dirfh, name, attr) returns (newfh, attr)
remove(dirfh, name) returns (status)
getattr(fh) returns (attr)
setattr(fh, attr) returns (attr)
read(fh, offset, count) returns (attr, data)

第 14 部

アーカイブサーバ625

write(fg, offset, count, data) returns (attr)
rename(dirfh, name, tofh, toname) returns (status)
link(dirfh, name, tofh, toanme) returns (status)
symlink(dirfh, name, string) returns (status)
readlink(fh) returns (string)mkdir(dirfh, name, attr) returns (fh, newattr)
readdir(dirfh, cookie, count) returns (entries)
statfs(fh) returns (fsstats)
サーバー

NFS サーバーはステートレスであるため，NFS リクエストを処理する
時，結果を返す前に，変更されたデータを安定した記憶装置に書き留めてをベースとしたサーバーでは，ファイルシス
おかなければならない．
テムを変更したリクエストは，そのリクエストが返る時に変更されたデー
タはすべてディスクに書き込まれなければならない．つまり，例えば write
リクエストにおいては，変更されたデータブロックだけではなくて，変更されたならば，を含むブロックも書き込まれなければならない．
へのもう一つの変更は，サーバーを動作させるために必要な内のジェネレーションナンバーと，スーパーブロックにおけるファイルシ
ステム の追加である．
ジェネレーションナンバーは，再利用されを以前のものと区別するために必要である．ジェネレーションナ
たがフリーになる度に増加される．
ンバーは，

UNIX

inode

id
inode

UNIX

inode

inode

inode

クライアント

NFSへの透過的なインターフェースを提供しクライアントの側では，ている．リモートファイルへの透過的なアクセスをするために，パスネー
ムの構造を変えない，リモートファイルのロケーティングの方法を使用すをベースとしたリモートファイルアク
る必要があった．いくつかのセスの方法は，リモートファイルの名前に host:path を使用するものである．しかし，この方法では，パスネームをパーズする既に存在するプログ
ラムは，変更されなければならないため，透過的なアクセスができているとは言えない．

UNIX

626

1989 年度 WIDE 報告書

クライアントが，リモートファイルシステムをディレクトリへアタッチすることを許すことによって，ホストネームルックアップとファイルアドレ．この方法は，
スバインディングを一度に行なうことができる
クライアントはマウントする時のみ，ホストネームを扱うだけで良いという利点を持つ．また，クライアントをチェックすることによって，サーバー
はファイルシステムのアクセスを制限することもできる．欠点は，マウン
トが完了するまで，リモートファイルが使用可能にならないことである．

(Figure 2.1)

一つのマシンにマウントされた，異なった型のファイルシステムへの透過的なアクセスは，カーネル内の新しいファイルシステムのインターフェースによって，提供される．それぞれのファイルシステムタイプは，二種類イのオペレーションの集合をサポートする．
ンターフェースは，ファイルシステム全体に対するオペレーションのプロ
インターフェースは，あるファシージャを定義する．
イルシステム内のファイルへのオペレーションのプロシージャを定義する．

VFS (Virtual File System)

vnode (Virtual Node)(Figure 2.2)
2.1.3

ファイルシステムインターフェース

VFS インターフェースは，一つのファイルシステム全体に対してなされるオペレーションを含んだストラクチャを用いてインプリメントされる．
インターフェースは，ファイルシステム内のノード（ファ同様に，イルまたはディレクトリ）に対してなされるオペレーションを含んだストストラ
ラクチャである．マウントされたファイルシステム毎に一つのストラクチャ
クチャが、それぞれのアクティブなノード 毎に一つのがカーネル内にある．この抽象データ型のインプリメンテーションを使用することによって，カーネルは，使用しているファイルシステムがどのよ
うにインプリメントされているかに関係なく，すべてのファイルシステム
やノードを同じように扱うことができる．

vnode

vnode

vnode

VFS

VFS

VFS

は，その親
とその上にマウントされたへのポ
各々のインタを持っている．これは，ファイルシステムのどのノードも，他のファ
オペ
イルシステムのマウントポイントになれることを意味している．
においてマウントされたファイルシステムのルート
レーションが，を返すために提供されている．これは，カーネルないのパスネームのトラバースのルーチンの中で，マウントポイントを越えるために使用さは，マウントされたところれる．マウントされたファイルシステムのへのポインタも，持っている．それによって，を含んだパスのネームはマウントポイントを越えて，トラバースすることができる．

vnode

vnode

root

VFS

VFS

\.."

VFS，vnode オペレーションに加えて，各々のファイルシステムタイプ

第 14 部

627

アーカイブサーバ

















machine-a

1A
11 AA

/localmachine-b

1A
1
1 AA

/src

3 T TT eg.c
T


src
TT
TT
 eg.c
図2.1: ファイルシステムのリモートマウント
CLIENTSERVER

System Calls

System Calls?

?
- VNODE/VFS

VNODE/VFS?

?

?

PC Filesystem

4.2 Filesystem

NFS Filesystem

?

?

?

FloppyDisk

RPC/XDR?
図

Server Routines

6

RPC/XDR

6

NETWORK2.2: VFS，vnode の位置付け

?

628

1989 年度 WIDE 報告書

mount

，
は，普通のそしてルートファイルシステムをマウントするために，
オペレーションを提供しなければならない．
ファイルシステムインターフェースのために定義されたオペレーション
は，以下の通りである．

mount root

 ファイルシステムオペレーション
mount(varies)
mount root() VFS オペレーション
unmount(vfs) retruns (vnode)

statfs(vfs) retruns (fsstatbuf)sync(vfs)

 Vnode オペレーション
open(vnode, flags)
close(vnode, flags)rdwr(vnode, uio, rwflag, flags)
ioctl(vnode, cmd, data, rwflag)
select(vnode, rwflag)

getattr(vnode) returns (attr)
setattr(vnode, attr)
access(vnode, mode)

lookup(dvnode, name) returns (vnode)create(dvnode, name, attr, excl, mode) returns (vnode)
remove(dvnode, name)link(vnode, todvnode, toname)rename(dvnode, name, todvname, toname)mkdir(dvnode, name, attr) returns (dvnode)
rmdir(dvnode, name)readdir(dvnode) returns (entries)
symlink(dvnode, name, attr, to name)第 14 部

アーカイブサーバ

629

readlink(vp) returns (data)
fsync(vnode)
inactive(vnode)bmap(vnode, blk) returns (devnode, mappedblk)
strategy(bp)break(vnode, blockno) returns (buf)brelse(vnode, buf)

vnode

NFS

1 1
NFS

多くの
プロシージャは，
プロトコルプロシージャと 対に対応している．一方，に依存した open，close，ioctl は，プロトコルには現れない．bmap，strategy，break，brelse プロシージャ
は，バッファキャッシュを使用した読み書きをするために，使用される．
2.1.4

UNIX

UNIX のファイルセマンティクス

NFS のクライアントでは，サーバーやプロトコルを変更すること無しに，UNIX ファイルシステムのセマンティクスにできるだけ従うようにしている．例えば，UNIX はオープンされたファイルを消去することを許している．プロセスは，ファイルをオープンし，そしてディレクトリエント
リーからそのファイルを消去する．それによって，ファイルシステム内には，そのファイルの名前はなくなってしまうが，そのファイルに対して，読
み書きを行なうことはできる．これは，ささいなことであるが，いやなことなので，最初はサポートされようとはされなかった．しかし，変更を加，など ）プログラムが，テンポラ
えたくない多くの（ 例えばリーファイルとして，その様なファイルを使用しているため，サポートをする必要があった．
リモートファイルについて，オープンされたファイルを消去できるよ
うにするためには，

csh sendmail

1. クライアントの VFS で，ファイルがオープンされているかど うか，
remove オペレーションの時にチェックする
2. もしそうならば，消去する代わりに，rename オペレーションを行なうといったことをする必要があった．これによって，クライアントにとっては見えないような感じになって，読み書きは可能なままである．クライアン
がアクティブでなくなった時に，その新しい名前
トのカーネルは，を消去する．しかし，これは完全な解決方法とはなっていない．もし，ク

vnode

630

1989 年度 WIDE 報告書

rename removeとの間でクラッシュしたならば，ごみのファライアントがイルがサーバー上に残されてしまうからである．
リモートオープンファイルに関連した別の問題として，そのファイルのアクセスパーミッションが，リモートにオープンされている間に，変更され得るといったものがある．ローカルにアクセスする場合には，パーミッ
ションはファイルがオープンされる時にのみチェックされるが，リモートコールの度にチェックされる．これは，もにアクセスする場合には，
しクライアントプログラムがファイルをオープンし，そしてパーミッショ
ンビットが変更されたならば，クライアントプログラムはもうリード パー
リクエストはフェイルしてしまミッションを持たないため，その後のう．この問題を避けるために，オープンする時に、どのクライアントがそのファイルをオープンしているのかをファイルテーブルに入れておき、その後のアクセス時のチェックはそれを用いる，といったことをしている．

NFS

read

同じ リモートファイルを複数のクライアントが使用しているような場
合，一つのクライアントで，それをコントロールすることはできないため，が維持されているわけではない．例えば，
全てのあるクライアントがファイルをオープンし 、別のクライアントがそのファ要求は失敗する．
イルを消去した時、最初のクライアントのUNIX open le semantics

read

2.2

Andrew File System

CMU ITC

AFS3.0[42]ので開発されたは，多くの実装技術を使用しており，以下に挙げる目標の多くを実現している．このシステムは， 年に及ぶ大規模分散ファイルシステムに関する研究の成果として誕生した．
2.2.1

6

広域ファイルシステム

Wide-Area File System

広域ファイルシステム（）を用いれば，正式に認められたコンピュータユーザならば ，遠く離れた （ たとえそれが大陸を挟んだ反対側や海を隔てた向こう側であっても）他の組織によって保存されているファイルを透過的にアクセスしたり，アップデートすることが可能となる．一般にこのようなシステムは，一つの権威によってではなく，いくつかのユーザ連合によって支えられている．ユーザのグループは，他のグループに自分たちのネットワークファイルシステム（セル (cell) ）にア
クセスできるようにしたのち，リモートセルにアクセスできるようになる．
さらに，そのような連合の間では，共有ディレクトリ，保護，認証，ファ
イル転送プロトコル（あるいは機構）について同意する必要があるが，各自のセルについてのポリシーや管理については，各メンバが個別に行なっ

第 14 部

アーカイブサーバ

631

ていく．
）のファイ
以上のようなシステムは，慣例的に「国家規模（
ルシステム」と呼んではいる．またこのようなタイプのシステムでは，シ
ステムの下にぶらさがっているネットワークの存在を隠して，クライアン
トが（ネットワークを介してファイルにアクセスする場合でも）普通のファ，，，など ）を使えるように
イルシステムコマンド（している．すなわち，広域ファイルシステムは，巨大な分散型の抽象デー
タオブジェクトであり，限定されているとはいえ強力なデータベースにアクセスするための統一的な手段を提供する．また，広域ファイルシステム
は，リモートログイン，ファイル転送，電子メールといった既存のネット
ワークサービスのごく自然な拡張であると考えることもできる．広域ファ， ，といった下位のネットワークプロトコ
イルシステムは，ルに依存するが，ハイパフォーマンスとリモートデータへの透過的なアクセスを実現するためには，セッション層，プレゼンテーション層，アプリ
ケーション層のプロトコルを新たに多数用意する必要がある．国家規模のファイルサービスが必要な理由は，以下に挙げるようなもである．

nationwide

read write open close

TCP IP X.25

 広域ファイルサービスによって，個人やグループからなる共同研究は促進される．計算機産業だけをみても，組織間の共同研究が急速に広がりつつある．

 広域ファイルサービスによって，機動力が増大する．家庭や旅行先にいても，ネットワークを介して，オフィスにいるような感覚でデータにアクセスすることができるのである．

 広域ファイルシステムをデータベースとして使用すれば，遠隔地の情報をまるで手元にあるかのように参照することができる．適切なインデックスの形式が与えられていれば，広域ファイルサービスはレポー
ト，設計仕様，プログラムソースを配布するための，非常に有効な手段になりうる．

 適当な機密保護が確立できれば，購入したりライセンスを取りたいソ
フトウェアについて，ソフトウェアのベンダーのマシンの上のプログ
ラムを遠隔操作で実行するということが可能なので，簡単に試すことができる．
以上を総合すると，広域ファイルサービスによって，コンピュータ支援による共同作業が非常に増加し，また簡単になると思われる．すなわち，国家規模のファイルシステムによって，多くの人々の作業環境は本質的に変化し，作業の柔軟性や生産性が大幅に向上するのである．

632

1989 年度 WIDE 報告書

2.2.2

設計目標

アンド リューファイルシステムで目標とした，広域ファイルシステムモ
デルは，以下のようなものである．

 アクセス透過性

read write

や）するシ
ローカルシステム上でファイルをアクセス（
ステムコマンドが，リモートシステムに存在するファイルについても同様に扱えるようになっている必要がある．

 認証と機密性サーバーとクライアントは，望ましくないアクセスに対してデータが保護されることを保証するために自分自身を認証できなくてはならない．

 セルの自律性
セル（ファイルサーバーおよびクライアントの集まりであり，普通一つの組織に対してサービスし，普通一つの部屋とか建物といった場所の配分，ファイルサーバーの割当の中にある）の管理者は，ユーザて，ユーザに対する記憶領域の割当ての管理，システムの構成といったことを，他のセルに影響を受けることなく独自に行なえなくてはな
らない．

ID

 他のファイルシステムとの共存
広域ファイルシステムは，一つの組織によって使用されるファイルシ
ステムのみであるとは限らない．したがって，クライアントが他のファイルシステムも同様に使えることが不可欠となる．

 通信の効率的利用
広域ファイルシステムはできるだけ通信の必要を減らすべきである．
それによってパフォーマスが向上し，ネットワークの負荷のシステムへの影響も減少し，通信にかかるコストも下げることができる．

 異常に対するセマンティクス
システムやネットワークに異常が発生した場合，それによる影響を最小限にくいとめるべきである．さらにその影響を素早く解析できなけ
ればならない．

第 14 部

アーカイブサーバ

633

 多様性
広域ネットワークには，異なるハード ウェア，異なるソフトウェアが含まれていることを考えれば，ファイルシステムは多くのマシン，大半のオペレーティングシステムをサポートしなければならない．ファで走っていると限定するにしても，クイルサーバーについてはと同様に，マッキントッシュ ，上ライアントはでも走らせられるようにすべきである．

UNIX

UNIX
DOS

OS OS/2

 名前の透過性
ユーザはファイルを名前で参照できるようにして，その場所を突き止めるのはシステムに任せるべきである．ファイルの存在するセルを特定する必要はあるかも知れないが，ファイルの収められているファイルサーバーを特定する必要はないようにすべきである．

 パフォーマンス
広域ファイルシステムは，ユーザに遠隔ファイルを使う気をなくさせないだけのパフォーマンスを保たなくてはならない．共同作業や共有の数を増やすには，十分なパフォーマンスが必要である．

 機密保護データの共有を適度に許す一方で，細かい機密保護ができるように，
保護情報はデータに付けるようにするべきである．

 システムの再構成
セルの管理者は，ど のクライアントにも影響を及ぼさないで，セルの構成を変えることができなければならない．たとえば，あるユーザのファイルをあるファイルサーバーから他のファイルサーバーへ，その変更をクライアントに知らせることなく，移動できなければ ならない．

 システムの規模
広域ファイルシステムは数千個のセルを取り扱い，各セルが数千台のクライアントコンピュータをサポートできる必要がある．

 共有アクセスのセマンティクス
広域ファイルシステム上のファイルへの共有アクセスに関するセマン
ティクスが合理性を欠くものであってはならない．このセマンティク
スは，ローカルファイルで用いられるセマンティクスと同様でなければならない．

634

1989 年度 WIDE 報告書

2.2.3

有効な技術

これまで述べてきたような特徴を有する広域ファイルシステムを開発するのに役立つ技術がいくつか存在する．

 キャッシュキャッシングは，おそらくそのうち最も重要な技術である．ファイル
やディレクトリやそれらのアドレ スをキャッシュすることによって，クライアントがネットワークを介してデータを転送したり，ファイル
サーバーに要求を出したりする必要が減る．クライアントが（ディスなどを用いて ）大きなローカルキャッシングを行なえば，クや必要なファイルをいちいちファイルサーバーから取り出さずにアクセスすることが可能になる．

RAM コールバックコールバックは，キャッシュの整合性を保ったり，キャッシュされた情報がアップデートされた場合の情報の保証に役立つ．コールバック
プロシージャが起動されていれば，キャッシュされているデータに不都合が生じた場合，ファイルサーバーがそのことをクライアントに告げることができる．

 論理ボリューム
論理ボリュームを用いて，特定のユーザやプロジェクトに属しているファイルやディレクトリをまとめることができる．論理ボリュームは，記憶領域の割当てを管理したり，ファイルサーバー間でデータを移動する際に便利な概念である．

 デ ィレクトリサービス
ディレクトリサービスを用いて，ファイル名やディレクトリ名を特定のファイルサーバーにマッピングすることができる．参照の局所性により，ディレクトリ情報はキャッシュするべきである．

 アクセス制御リスト
ディレクトリ（場合によっては各ファイル）に付けられるアクセス制
御リストは，ファイルへのアクセスを許すユーザやグループを規定する手段を提供する．これによって，管理者は広域ファイルシステムへの共有アクセスを細かく制御することができる．

 オーセンティケーション

第 14 部

635

アーカイブサーバ

MIT の Kerberos で用いられたような，暗号による認証技術によって，クライアントやファイルサーバーは互いに自分達を認証することができる．

 高速なネットワーク

NFSNet のような高速ネットワークを用いれば，T1（ 1 秒間に 1.5 メ

ガバイトの速さ）を実現したり，ローカルエリアネットワーク間をより高速で接続することができる．

 RPC
大きなファイルの塊を効率良く送ることのできるリモートプロシー
ジャコールは，かなり細かい要求を出したり，高速でデータを効率良く転送するために必要である．各パケットを認識する，簡単な要求と反応のプロトコルでは，長距離ネットワークを介した場合，十分なバ
ンド 幅を得ることができない．

 レプリケーション
何台かのサーバー上にディレクトリ，データ，ファイルの複製を作っておけば，ファイルシステムやネットワークの異常発生を防ぐだけでなく，システムのパフォーマンスを上げるのにも役立つ．
やのデータの複製を作っておくのが最も簡単である．

read-only

read-mostly

2.2.4

インプリメンテーション

ファイルシステムそのものは，抽象的なれたいくつかの要素から成り立っている．

AFS を実現するために用意さファイルサーバー

AFS において最も重要なプログラムはファイルサーバープロセスであり（ 実際には，歴史的理由から，2 つの UNIX プロセスとして実装されている），各サーバーマシン上で稼働し，クライアントにファイルを提供する役目を担っている．
ファイルサーバーは，ボリュームと呼ばれるオブジェクトをほとんど排）他的にに扱う．これは，小さなディスクパーティション（普通 〜と考えることができ，サーバーマシンには数千のボリュームがロード される．ボリュームはファイルとディレクトリの集まりであり， ビットのファの連結されるサブツリーを形成すイル （ ）で識別される．これがる．普通のシステムにおいて各ディスクパーティションがマウント

1 50MB

ID d
UNIX

AFS

96

636

1989 年度 WIDE 報告書

されて一つのファイルシステムを形成するように，システム内の各ボリューの名前空間をなす．
ムがマウントポイントで繋がって，グローバルな

AFS

もちろん，両者には違いがある．パーティションの場合と違い，ボリュー
ムには常時固定されたディスクスペースは割り当てられない．その代わりのディに，ボリュームの多くがファイルサーバーマシン上の一つのスクパーティションを共有する．そして各ボリュームは，一つのボリュー
ムに対する割当て量やそのディスクパーティションの使用可能なスペースの合計に制約があるものの，時間によって大きくなったり小さくなったりする．システム管理者がボリュームの割当て調整を動的に行なうことができるのである．

UNIX

UNIX のマウントポイントの場合と異なり，AFS のボリュームのマウン
トポイントはファイルシステムのオブジェクトである．したがって，AFS にア

クセスしているワークステーションは，すべて同じファイルシステムツリー
構造を見ることになる．例えば，ファイルは，というボリュームのマウントポイントである．このボリューの所有するファイルを含んでいる．
ムはユーザ/afs/andrew.cmu.edu/usr/kazar

usr.kazar
Kazar

さらに，ボリュームはあるサーバーのディスクから他のサーバーのディ
スクへ，名前を変えることなく移動できる．このことは，システムにおける場所の透過性を実現するのに重要である．
ファイルサーバーは，ボリューム全体に対する操作（ 例えば，バック
アップテープからボリュームをリストアする）およびボリューム内の各ファ
イルやディレクトリに対する操作（例えば，ファイルからデータブロック
を用いている．
を取り出す）の両方に

RPC

キャッシュマネージャ

AFSの各クライア
ファイルシステムにとって次に重要な要素として，ントマシン上に置かれるキャッシュマネージャが挙げられる．キャッシュマ
ネージャは，一番最近に使われたファイルやディレクトリをキャッシュし，のファイルシステムコールをキャッシュ参照の組み合わせおよび一つ
もしくはそれ以上のサーバーに対するに変換する．また，キャッシュが一杯になった場合に，キャッシュからエントリを削除するということもキャッシュマネージャの大事な仕事である．

UNIX

RPC

AFS 3.0 のキャッシュマネージャは，Sun Microsystems の vnode イン
タフェースを介して UNIX のカーネルとインタフェースをとる．vnode は
もともとカーネルと Sun の NFS の間のすっきりしたインタフェースを提供するために設計されたものである．UNIX のカーネルはシステムコール

を，外部のファイルシステムモジュールに対するプロシージャコールのセッ第 14 部

637

アーカイブサーバ

トに変換し，必要な機能を実現する．

96

キャッシュマネージャとファイルサーバーの間では，ファイルは ビッ
トのによって識別される．他のシステムにあるようなと違って，のは不変なオブジェクトを名前をつけるものではない．同じに名付られたファイルでも，別の時間には別の中身であることもありうる．

d

d

d

d

AFS

ファイルは，データ部分とステイタス部分に分けられる．データ部分は，
ビットバイトのストリームからなっている．ステイタス部分は，ファイルの大きさ，そのファイルが作られた日付，保護モード といった情報が含まれている．重要なステイタス情報の一つは，ファイルのデータバージョン
ナンバーである．これはファイルのデータが変更される度にインクリメン
トされ，我々が使用する整合性のアルゴリズムの多くで用いられる．キャッシュマネージャは，ファイルの データ部分とステイタス部分を独立にキャッ
シュする．

8

d

は，ファイルサーバーからファイルのデータ部分や状態
ファイルのに関する部分をいつでも検索できるようにするために必要となる重要な情報である．ファイルは不変ではないので，別の時間には別のデータを含むとデータバージョン数をこともある．しかしながら，そのファイルの確かめることによって，その内容を一意に識別することができる．

d

AFS を設計する過程において，パス名をそのファイルの d に変換するのに要する処理時間が問題となると考えられた．
．特に，パス名を基本にした広範囲に渡る計算を処理するのに使える計算資源を，ファイルサーバーが十分に持てないのではないかと考えられた．このような理由か，パス名を取り扱う要求のすべてと共にパス名に関する情報のすべてをファイルサー
バーインタフェースの外に置くことにされた．サーバーは，キャッシュマ
によってのみファイルを識別する．パネージャがパス名から割り出した
ス名に関する情報のすべてはキャッシュマネージャが管理する．キャッシュの構成要素であり，サーバーが提供する自由に移動でマネージャは，
きるボリュームの集まりをつなげて一つのツリーにする．それは，パス名のマウントポイントに出会ったら，それを翻訳することによっの中でて行なわれる．

d

AFS

AFS

加えて，システムのどのボリュームがどのセルに属しているかを知っているのもキャッシュマネージャである．一人のユーザが異なるセルで持接
ち得るいろいろな識別子を追いかけることや，適切に認証された
続を正しい時に用いるのもキャッシュマネージャの義務である．すなわち，キャッシュマネージャには，一人のユーザに対して，一つのセル当たり一
つの識別子の集合が与えられ，そのユーザについてあるセルを参照したときには適切に同一視できることを仮定している．

RPC

638

1989 年度 WIDE 報告書

ボリュームロケーションサーバー
キャッシュマネージャは，どのサーバーがそのファイルを提供しているのかをど うやって知るのであろうか．ボリュームロケーションサーバーと呼ばれるプロセスが，この情報をキャッシュマネージャやネットワーク内の各所にある管理用プログラムに送っているのである．
キャッシュマネージャが，それまでにアクセスしたことのないボリュー
ム内にのファイルを操作する必要が生じた場合，キャッシュマネージャはそのセルのボリュームロケーションサーバーにコンタクトをとって，どのサーバーがそのボリュームにアクセスできるかという情報を手に入れる．
（ 現在のボリュームだけが複数のサイトに存在してもよい）のところ，
キャッシュマネージャはこの情報をキャッシュしているので，ボリュームを参照する場合のほとんどはボリュームロケーションサーバーとコンタクトをとる必要がない．場合によっては，オペレータコントロールによってボリュームがサーバー間を移動する．そのような場合に，キャッシュマネー
ジャがそのボリュームを移動前の場所に参照しに行くと，特別なエラーコードが発生し，そのボリュームの移動先に関する情報をボリュームロケーショ
ンサーバーから手に入れるよう指示する．

read-only

オーセンティケーションサーバー
ファイルサーバーは，ファイルにアクセスにきたクライアントの認証をでは基本的にに，クライアントのワークステーショ行う必要がある．
ンは本質的に安全ではない，と考えている．つまり，物理的に操作できないような計算機センターのワークステーション上で実際にどのようなソフ
トウェアが走っているかを知る方法はないということである．したがって，のカーネルに対して，ファイルにそのようなワークステーションのアクセスしようとしているユーザの身元を確認することはできない．

AFS

UNIX

それに加えて，このような特殊な環境下では，ワークステーションや
パーソナルコンピュータがネットワークの中を自由に行き来できる．以上のような理由から，ネットワークを介してパスワード を送るというようなことは認めないものとした．イーサの中を飛び交うパスワードを捕まえる
ようなプログラムを書くことなど誰にでも簡単にできる．その代わりとしとて，ネットワーク環境において相互の認証を確立するためにによるアルゴ リズムを採用した認証サーバーが書かれた．
では，オリジナルのオーセンティケーションサーバーをのアテナ
プロジェクトのを採用した認証システムに置き変えた．

Schroeder
3.0

Kerberos

Needham
AFS
MIT

Kerberos はかなり複雑ではあるが，その背後にある基本的な考え方は

第 14 部

アーカイブサーバ639

極めて単純である．クライアントは，（ パスワード のような）共有秘密情報をネットワークを介して送ることによってではなく，共有秘密情報をも知っているサーバーからの暗号化された要求に答えることによって身元確認をパッケージが共有秘密情報で行なっている．すなわち，サーバーの暗号化を行ない，それをクライアントに対して送る．クライアントのパッケージがその要求を受け取り，暗号を外し，要求に答え，結果を共有
秘密情報で暗号化してサーバーに返す．同じ要求が繰り返されることは決してないので，ある要求に対して行なった対応をその後の要求に対して単純に繰り返すことはあり得ない．

RPC

RPC

保護モード

RPC

インタフェースの向こう
ファイルサーバーは，認証機構によって側に位置するクライアントの身元を確認する．そして，ファイルサーバー
は，システム内の各ディレクトリに付随したアクセス制御リストを調べる
ことによって，いろいろなディレクトリやファイルに対するクライアントのアクセス権を規定する．このリストは，ディレクトリ自身およびそのディレクトリに含まれるすべてのファイルのアクセス権を規定している．アクセス制御リストは，対からなる配列である．対の最初の項目がユーザ名およびグループ名で，二番目がそのユーザやグループに関する権利情報である．
デ ィレクトリに対して記されているアクセス権は，次にあげたものの内の一つかいくつかである．

 lookup
デ ィレクトリ内の名前の参照を許す．

 insert
デ ィレクトリに新たなエントリを追加することを許す．

 deleteデ ィレクトリからのエントリの削除を許す．

 administer
デ ィレクトリのアクセス制御リストの修正を許す．
デ ィレクトリ内のファイルに対するアクセス権は，以下のようである．

 readデ ィレクトリ内のどのファイルについても読むことを許す．

640

1989 年度 WIDE 報告書

 writeデ ィレクトリ内のどのファイルについても書き込をを許す．

 lockディレクトリ内のどのファイルについてもロックをセットすることを
許す．

AFS

UNIX

は，特別な方法を用いてのオーナ保護モードビット
さらにを解釈し，オーナのやのビットの立っていないファイルを保護のホームディレクトリのアクセスリストは次する．例えば，ユーザのようになる．

write readkazar

Access list for/afs/andrew.cmu.edu/usr7/kazar is
Normal rights:
System:AnyUser rl
kazar rlidwka
これは，グループ System:AnyUser （システム内の全員からなっている）のメンバは kazar のホームディレクトリにあるファイルを読んだり，
ディレクトリの中の名前を参照することができる．しかし，kazar として認証されたユーザだけがディレクトリやその中の任意のファイルを更新できる．

AFS ユーザは，ユーザグループ全体に対して特別の権利を認めるために，新しいアクセス制御グループを作ることが許されている．グループの構成員のデータベースは，プロテクションサーバーと呼ばれるサーバーによって維持され，このサーバーは「このグループのメンバーは誰か？」と「このユーザは，どのグループに属しているか？」という関連する つの問いに答えることができる．このサーバーは，新しいユーザアカウ
ントを作るための機能も備えている．このサーバーは，キャッシュマネー
を経由して
ジャや数多くのシステム管理用ユーティリティと同様に，
ファイルサーバープロセスからアクセスされる．

2

AFS

RPC

オペレーションサーバー

UNIXのプロセスとしてこれまでに挙げたサーバーはすべて，個々のはプロ実現されている．これらのプロセスを管理する手助けとして，
セスマネージャを提供している．このサーバーの仕事は，システム内の他のサーバーを制御したり，新しいプログラムをファイルサーバーマシン上にインストールしたり，失敗したプロセスを再起動したり，再起動するプ

AFS

第 14 部

アーカイブサーバ641

ロセスのステイタスの報告を行なったり，それ以外にはシステムの操作を補助したりすることである．

キャッシュの整合性とパフォーマンス
分散ファイルシステムによってもたらされる整合性の保証は，そのファイルシステムの可能な実現方法に強い影響を与える．ハイパフォーマンス
の分散ファイルシステムを構築する際には，まず整合性に関する適切なセ
マンティクスが求められる．それに加えて，整合性に関するセマンティク
スは，アプリケーション，とりわけ分散アプリケーションの構築における分散ファイルシステムの有用性にも影響してくる．もしその分散ファイル
システが，分散アプリケーションの構築に十分な整合性を持ち合わせていないと，記憶領域や共有について分散ファイルシステムを用いることができずにシステムは失敗に陥ってしまう．

AFS では，キャッシュマネージャへの呼び出しは，キャッシュから最新のデータを返す必要がある．AFS は，キャッシュ内に無効なデータが含まれている場合に，ファイルサーバーがそれをクライアントのワークステーションに知らせるコールバックシステムを使っており，キャッシュマネージャの各呼び出しについてサーバーをポーリングしたり，単純にキャッシュのデータが最新のものであると仮定したりしない．ファイルサーバーが，ファイルのデータやステイタスをクライアントのワークステーションに送る場合，サーバーがそれらを変更する前にワークステーションに知らせるものとす
る，という取り決めを行なっても良い．
（ これは，他のユーザがファイルを書き換えに行く際に起こる）このような取り決めのことを，コールバックと呼ぶ．特定のファイルが変わったことを，適当なワークステーションに通知する プロセスのことをコールバックをブレイクすると言う．またこれは，そのファイルの内容や状態が変わる前に行なわれなければならない．
ワークステーションがキャッシュ内のあるファイルについてコールバッ
クを終わらせない限り，情報が古いものかどうか気にすることなくそのファ
イルのデータやステイタスを読むことができる．これによってワークステー
ションがファイルサーバーにかける負荷を著しく減少させ，キャッシュの整合性の保証を弱めることもない．また，コールバック自体は本質的にシンプルな機能であるが，そのインプリメントはたいへんなものである．問題
は二つの領域で生じる．一つはファイルサーバーの呼び出しとその同じファ
イルサーバーからのコールバックをブレ イクするメッセージとの同期，もう一つはコールバックの取り決めをブレイクするときの通信の失敗である．

642

1989 年度 WIDE 報告書

通信

AFS はマシン内部およびマシン間でのプロセス間通信のすべてに，Rxと呼ばれる RPC 機構を採用している．RPC は良く理解された通信モデル
であるが，Rx にはユニークな特徴がいくつか存在する．
1. コア Rx パッケージとその認証モジュール間のインタフェースはそれ自体高度にモジュール化されているので，新しい認証モジュールの定義が容易であり，複数の異なる認証構成の共存が可能である．例えば，ので現在稼働しているファイルサーバーは，我々の古い認証のトークンとの認証のチケットの両方をサポートしている．

CMU ITC

Kerberos

2. Rx コールのパラメータとして大きさに制限のないバイトストリームを渡すことができるような高度な RPC インタフェースを，Rx は持っている．このような呼び出しが行われる場合，クライアント側の Rx
コールは二つの部分に分かれて現れる．一方は入力パラメータを受渡しする部分で，もう一方は出力パラメータを返す部分である．このストリームに対しデータを読み二つの部分の間に，呼び出し側は書きできる．このデータはサーバーで呼ばれたプロシージャからも読み書きできる．結果として，リモートプロシージャコールで大きさに制限のないデータを受渡しするのに，非常に効率的で便利な方法であは，大きなファイルの塊（例えば，）をキャッシュマ
る．
ネージャとファイルサーバーの間で転送する際には，この機構を用い
ている．

Rx

AFS

64KB

3. Van Jacobson による TCP の改良においてなされた幾つかの細かい
チューニングを用いて Rx は設計されている．これによって Rx が，
少なくとも現在の TCP 程度にネットワーク輻輳や可変速度の通信リンクに適用できるようになることが，期待されている．初期のテスト
が，の長距離リンク上で約では，最初のバージョンののデータ転送能力を持っていた．

400Kbps

Rx

500Kbps

相互操作性

AFS 3.0 のキャッシュマネージャは，NFS の実装と共存して，ワークス
テーションが NFS サーバーと AFS サーバーの両方にアクセスできるようにすることができるようになっている．さらに，CMU の計算機科学部において，NFS のプロトコルを用いて AFS のファイルを提供するサーバーが実装された．このサーバーによって NFS のクライアントは，ローカルエ

第 14 部

643

アーカイブサーバ

リアネットワーク上の中継機を介して広域ファイルシステムのサービスをとによって提供される最低受けることができる．システムは，レベルの機密性を提供する．
ベースのどんなマシン上でも稼働して，しかもそのマシ
将来，ンから見えるようなファイルシステムを提供するようなエクスポートサーのクライアンバーの構築が計画されている．そうした点においても，
トに対し，どのような分散ファイルシステムからでもファイルを提供することが可能にになるであろう．

NFS AFS

UNIX

AFS

第 3章
光ディスクと光ジュークボックス

2

コンピュータの 次記憶装置に用いられているメディアは，現在はほとんどが磁気ディスクである．磁気ディスクは再書き込み可能であり，かつ他のメディアに比べて比較的高速であるため，広く使用されている．しかし，単位記憶容量に対するコストは比較的高い．また，ポータビリティも悪い．ここで用いる光ディスクは追記型であり，それほど 高速ではないが，大容量で，ポータブルであるといった点では磁気ディスクより優れている．ここでは，光ディスク，多数の光ディスクを格納できる光ジューク
ボックスの特徴について述べ，それらを用いて提供することのできるサービスについて考察する．

3.1

光ディスク

Write Once

ここで用いる光ディスクは，一度だけ書き込むことのできるといった性質を持つものである．一般的には追記型と呼ばれるものである．即ち，一度書いてしまった部分は書き換えることはできない．そのため，以来磁気ディスクが用いられていた分野での使用は困難である．しかしながら，その容量は磁気ディスクと比較して非常に大きいといった特徴を持つ．
光ディスクの長所をまとめると次のようになる．

Read Multiple(WORM)

 大容量
 容量と比較して低価格
 耐久性が高い
 寿命が長い5.25

600800MByte

インチの光ディスクの両面に記憶した場合一枚あたり容量は，記録することができる．光ディスクを一枚ずつフロッピーディスクのよう644

第 14 部

アーカイブサーバ

形式

645

追記型

5.25 インチ
記憶容量800MByte（両面）デ ィスク回転数
1800rpm
アクセスタイム
85 msec（平均）セクタ長512byte/セクタ
記憶再生速度
5.5Mbps
ビットエラーレート
100 （ 訂正後）
インターフェース
SCSI
データ転送速度
最大 1.5MByte/sec
デ ィスクローディング時間
最大 4sec
デ ィスクアンローディング時間 最大 4sec
デ ィスク径12

表3.1: 光ディスクの仕様に持ち運びできる耐久性を考えれば，この容量は非常に大きく最も大容量倍以上で，耐久性はもっと高い．
のフロッピーディスクと比較しても60

逆に，短所は以下のような点である．

 書き換えができない メディアの信頼性に若干の問題がある
 速度が遅い
これらのうち，メディアの信頼性は改善されてきており，現在ではほとん
ど 磁気ディスクと比較して遜色ない．速度の点ではシークに特に時間がかかり，かなり低速のハードディスクなみである．また，データの転送速度も若干低速である．
仕様の詳細は

3.2

Table 3.1の通りである．

光ジュ−クボックス

光ジュークボックスはアーカイブファイルサーバーで使用するシステム
である．多数のディスクを格納することができ，ディスクド ライバにディ
スクをリモートにマウント，アンマウントして使用する．光ジュークボッ
クスは次のような長所を持つ．

646

1989 年度 WIDE 報告書

56 枚
内蔵ディスクド ライブ
2 ド ライブデ ィスクローディング時間
4sec（平均）デ ィスクアンローディング時間 4sec（平均）デ ィスクマウント時間
5sec（平均）デ ィスクアンマウント時間
6sec（平均）
収容ディスク枚数表3.2: 光ジュークボックスの仕様

 大容量

45GByte，システムを組み合わせることによっ
単一システムで最大て最大（ 最高 システムまで組み合わせることができる）

314GByte7 複数のディスクド ライブによる高スループットの実現 デ ィスクの入れ換えが容易
光ジュークボックスは以上のように非常に大きな容量を持つことができる．しかしながら，全てのディスクがディスクド ライブにマウントされているわけではない．ディスクに読み書きをするためには，ディスクがディス
クド ライブにマウントされていなければマウントする必要がある．そのために必要な時間は，それ以外にアクセスをするために必要なシークタイム，
回転待ち時間等と比較して，非常に大きくなってしまう．そのため，異なったディスクに次々とアクセスするような場合には非常に効率が悪くなる．
の通りである．
光ジュークボックスの詳細な仕様はTable 3.2

3.3

システムの特徴

ここでは光ディスク，光ジュークボックスをアーカイブファイルサー
バーの記憶装置として使用した場合の特徴を述べる．まず，利点となるものは次のような点である．

 光ディスクの性質によるもの
{ 大容量
{ 追記性

3 履歴が残る

第 14 部

アーカイブサーバ647

3 領域管理の容易さ
3 読みだしの高速化
 光ジュークボックスの性質によるもの{ オペレ−タによるディスクの入れ変え{ デ ィスク一枚毎の管理追記型であるということは，二度と消すことができないことが非常に大きな欠点であることのように思われ，その利点は取り上げられることは少ない．しかし，二度と消すことができないため，一般に一度作製したら消去することの少ないないアーカイブファイル，ダンプファイルのためのメディアとしては非常に優れているといえる．人為的なミスによって，間違って消してしまうことがあり得ないからである．
また，追記型であることは領域の管理を非常に容易にする．消去でき，再書き込みのできるブロック型のディスクの場合，使用できる領域は連続でなくなり個別に管理しなくてはならない．そのため，現在使用できる領域を管理することは追記型の場合と比較して複雑になる．また，一つのファイルの内容を記憶する領域がディスク上に分散してしまった場合は，読み出しの効率は非常に悪くなるため，そのようなことがあまり起こらないよ
うに管理する必要がある．
以上のような消去，再書き込み可能なディスクの場合に考慮すべき問題
は，追記型の場合は起こらない．一度書き込まれたブロックは再び使用可
能になるということはあり得ない．書き込みは常に連続的に使用されていき，簡単にいえば，どこまで使用されたかだけを記憶しておけば良い．このように，連続的に領域は使用されていくため，読みだし時にセクターのシークといったことが頻繁に起こることはない．これによって，読み出しは高速に行なうことが可能になる．また，領域が分散してしまうことに配慮する必要もない．
光ジュークボックスは，光ディスクを容易に入れ換えることができる．
もし，ジュークボックス内に光ディスクが入りきらなくなってきたら，人為的に，例えばオペレータが光ディスクを入れ換えて使用するということが考えられる．ジュークボックス内に格納していないディスクをも管理下に置くことによって，さらにジュークボックスの持つ容量は拡大する．
光ディスクはそれ自身を管理することも容易である．メディアとしての耐久性は比較的高く，例えばフロッピーディスク，ディスクパックなどのように管理に気をつける必要はあまりない．アーカイブファイルサーバー
によって管理される必要のないディスクは取り外し，個別に管理されるこ648

1989 年度 WIDE 報告書とが望ましい．しかし，ある光ディスクに様々な人のファイルが書かれてしまっている場合は，そのディスクが誰によって管理されるべきかはっきりしない．即ち，ディスクの所有者，管理者が明確になるようにディスクには書き込まれる必要がある．

3.4

提供されうるサ−ビス

光ジュークボックスを使用し，ネットワークに接続された時に，提供されると望ましいと考えられるサービスをあげてみる．それらは，バックアップ的なサービス，要求に対して持っている情報を検索するようなデー
タベース的なサービス，管理的なサービス，バックアップをする際に補助的に利用するようなサービス等に分類することができる．

 バックアップ
{ ftp
{ rcp
{ rdump{ NFS{ nntp (ニュースの配布){ smtp （ メッセージ又はメール・サービス）{ ソフトウェアのバージョン管理{ コピー

 デ−タベ−ス{ デ ィレクトリサ−ビス{ SQL(System Query Language) 的インターフェース

 管理的なサービス{ アカウントの管理{ オーセンティケーション{ デ ィスクの登録{ デ ィスクの保存期間{ （ 自動的な）ソフトウェアのバージョン管理{ ユーザのトランザクションの保存、管理

第 14 部

アーカイブサーバ649{ クォータ{ ミラー{ CD の使用のされかたについての管理サービス（パッキングのされかたなど ） 補助的なサービス{ コンプレッション{ バッチ処理{ 暗号化
これらの全てを最初からサポートすることはできない．バックアップ
的なサービスの中で特に強い要求があり，また最初からサポートすべきだと考えられるのは

 ftp
 rdumpの二つでである．
ダンプは現在においても一つのファイルシステムに対して，磁気テープを数本用いて行い，磁気テープは交換しなければならない．そして，ダンプがとられるハードデ ィスクは増加し続けているため，毎週インクリメ
ンタルダンプをとるといったことは非常に苦痛になってきている．そこで，をアーカイブファイルサーバーに対して使用することができれば，その様な苦痛から開放され，また毎週きちんとダンプをとることが可能になるため，環境を維持していくのに非常に役立つといえる．

rdump

ftp はインターネットワーク上でファイルのやりとりをする場合に，もっとも一般的に使用されるコマンドである．インテラクティブにファイルを転送できるものは他にないため，サポートすべきであると考えられる．
管理的なサービスは，サービスを正しく行なうためには必要不可欠なもの含んでいるため，それらは提供されなければならない．運営のために
必要最小限なサービスは ユーザの管理 デ ィスクの管理650

1989 年度 WIDE 報告書
バックアップ

表

ftp
rdump
rcp

管理

ユーザの管理デ ィスクの管理

補助

バッチ処理

3.3: アーカイブファイルサーバーで提供されるサービス

といったものである．
補助的なサービスはそれだけでは意味をなさず，他のサービスと組み合わせて使用される種類のものである．その中で特に必要であると考えられるサービスは，バッチ処理である．インターネットワーク上で使用されるシステムが，そのシステムを使用する全ての人に対して使いやすいインテ
ラクティブなサービスを提供することは難しい．アーカイブファイルサー
バーでは，ディスクの交換等を含めて低速な記憶装置を使用するため，さらに難しいといえる．ところが，バックアップのサービスにおいて，ファイ
ルシステムのダンプをとる場合はインテラクティブである必要はない．また，ファイル転送であっても，バックアップを光ディスク上にとるような場合では，インテラクティブである必要はない．このような場合，バッチ処理は非常に有効であるといえる．
（ インテラクティブな方法でなく，ファといったものがある．
）
イルを転送できるコマンドとしては，例えば

rcp

これまで，提供されうるサービスと提供すべきサービスをあげてきたのようになる．
が，提供すべきサービスをまとめるとTable 3.3

Table 3.3

でこれからの章では，提供されうるサービスも考慮しつつ，示されるサービスを提供できるシステムの構築について述べていく．

第 4章
ア−カイブファイルサーバーの設計

アーカイブファイルサーバーは，光ディスク，光ジュークボックスといった以来の一般に使用されてきた磁気ディスクとは異なったメディア，記憶装
置を用いる．これらは追記型であるとか，アクセスに時間がかかるといった点で，磁気ディスクとは大きく異なっている．また，インターネットワー
ク上で使用されることから，以来扱われなかったような多くの異なった背景を持つユーザーをサポートする必要がある．そこで，アーカイブファイ
ルサーバーを設計する上で，ポイントとなる点，考慮すべき点について，
この章では考察する．

4.1

ファイルシステム

アーカイブファイルサーバーは，光ディスクを主な記憶メディアとして使用する．ユーザーによって書き込まれたファイルは，基本的にすべて光
ディスク上に書き込まれる．アーカイブファイルサーバーの管理するファ
イルはユーザーのファイルの他に，ユーザーを登録したファイル，ネット
ワーク上の他のホストを登録したファイルなど ，システムを管理していくために必要なファイル，システムを動かすためのソフトウェア等がある．
これらの中には時間とともに変化していき，また頻繁に参照されるため光ディスク上に作られるべきではないものもある．これらのファイルを記憶するためのメディアとしは，書き換え可能，かつ高速な磁気ディスクが適していると，考えられる．
このようにアーカイブファイルサーバーは，光ディスクと磁気ディスクを組み合わせて，ファイルシステムを構成するのであるが，それぞれはどのようにファイルシステム上に位置付けられ，どのように使用されるべきなのであろうか．

651

652
4.1.1

1989 年度 WIDE 報告書
光ディスク，磁気ディスクのファイルシステム上での位置付け

光ディスクの，ファイルシステムを構成するメディアとしての位置付けを考える際のポイントは

 追記性
 低速性
 ポータビリティである．
追記型であるために，頻繁に書き換えられる，または書き加えられる可能性があり，古いものは必要なくなるようなファイルは光ディスク上に記録されるべきではない．
光ディスクは磁気ディスクと比較すると低速である．そこで，頻繁に利用されるファイルは光ディスク上に存在すると，読み出すのに非常に時間がかかる．そのようのなファイルは光ディスク上に記録されるべきではな
い．しかし，ユーザーのファイルは基本的にすべて光ディスク上に記録される．そのため，これは効率の問題と深く関係しているが，磁気ディスク
上に読み出されキャシングされるということが考えられる．
ポータビ リティは，光ディスクにどのようにユーザーのファイルを詰めていくかという，パッキングの方法に依存してくる．理想としては，一枚のディスクには同一ユーザーのファイルだけが存在するというのが望ましいが，現実にはこれは不可能であろう．ということは，あるユーザーのファイルは複数のディスク上に分散して格納されている．これらのファイルは，そのユーザーのディレクトリの下に存在するべきなので，そこにあるように見せかける必要がある．
磁気ディスクは，光ディスクが追記性を持ち，また比較的低速であるの
に対して，

 高速
 消去，再書き込み可能といった特徴を持つ．
高速であるため，よく読み出されるファイル，ディレクトリは，磁気ディスク上に置かれ，キャッシュされるべきであろう．
磁気ディスクにおいては，一度書き込まれた部分は何度も書き換えることが可能である．また，細かく書き加えていくことも可能である．これ

第 14 部

アーカイブサーバ

653

/
@
@
@@
@@
33 ll
l
@
@
pds
home
@@
@@
HHH
GNU
shui.keio@
HHH @@@
4
Name Space@@
Hbackup-2
4
H @@GNU-Emacs
backup-1
@@ 3
@@
C
C
3
C
3
C
3
@@ 3 @@ @@@ @C @Optical Disk
@ GNU-Emacs @ @ buckup-1@@ @@ buckup-2@@
@
@ @
@ @
@

図

4.1: ネームスペースから光ディスクへのマッピング

は特にディレクトリを管理するためには重要で，光ディスク上にディレクトリ構造を作成することは難しい．
以上のことから，ユーザーのファイルは光ディスク上に記録するが，補助的に磁気ディスクを使用し，ディレクトリ構造は磁気ディスク上に作成する，という方法がとられるべきである．即ち，ネームスペースは磁気ディスク上に作られ，ユーザーのファイルは光ディスクにマッピングされ．
る(Figure 4.1)

4.1.2

ジュ−クボックスの外のディスクの取り扱い

光ジュークボックスの中に，格納できるディスクの枚数には限りがた
め，すべてのディスクを格納できるとは限らない．扱いたいディスクの枚
数が，光ジュークボックスに格納できるディスクの枚数を越えてしまったら，ジュークボックスに格納できないディスクが出てくる．それらのジュークボックス内に格納できないディスクは，どのように取り扱われるべきであろうか．
ジュークボックス内に格納されていないディスクをアクセスするためには，誰かの手によってジュークボックス内に格納されなければならない．

654

1989 年度 WIDE 報告書

そのためには，さらに時間がかかり，さらに低速になる．もしジュークボッ
クスにディスクをいれるスペースがないとしたら，どれかディスクを抜いて，新しくディスクをいれる必要がある．アーカイブファイルサーバーが，ジュークボックス内に格納されているディスクしか管理対象にいれないな
らば，各ユーザーは，どのディスクにどのファイルが入っているかを知るには，一々ディスクを格納しなければならず，またどのディスクがアーカ
イブファイルサーバーに格納させられるかも，各ユーザーが知っている必
要がある．
ジュークボックスの外にあるディスクもアーカイブファイルサーバーが管理する対象にいれるとすると，どのディスクが現在使用できるのか，どのディスクが今外に出されてしまっているのか，といったことについてユー
ザーが管理する必要はなく，アーカイブファイルサーバーから情報を得ることができる．
さらに，ジュークボックスの外にあるディスクも，格納されているディ
スクも同様にユーザーから見えるとしたら，ど うなるであろうか．そうなれば ，ユーザーはディスクの所在について全く意識する必要はなくなる．
しかし，速度の点で問題が残る．あるジュークボックスの外に出てしまっているディスクにはいっているファイルのリストを出したい時，そこで長時間待たされるというのでは，うかつにファイルのリストも見ることができない．この問題は，ファイル名だけはキャッシュしておく，という方法
で解決できる．これによって，ほぼユーザーはディスクの所在について意識することはなくなる．
4.1.3

ユ−ザのファイル管理

ユーザーのファイルは，ユーザーのホームディレクトリの下に置かれる．ユーザーのファイルは，いくつかの光ディスク上に分散しておかれている．これらのファイルは，ユーザーにどのように見えるべきであろうか．
も参照 ．
ここで，二つの方法が考えられる(Figure 4.2)

1. どのディスクにはいっているかに関係なく，ホームディレクトリの下にあるように見える

2. どのディスクにはいっているかわかるように，各ディスク別にディスク名をつけたディレクトリを作る
そのディスクにはいっているファイルはそのディスクの名前のついたのディレクトリの下に見える

1

光ディスクの存在を，ユーザーに意識させないという点では， の方法の方が優れている．いくつかのファイルは同一のディスクに集めていれた第 14 部

(1)

TT
T
TT

アーカイブサーバ

TT
TT
T
TT
home
TT
T
TT
user1.keio
HHH
#
T
#
H
TT
backup-1
backup-2
6
6
/

T
TT
T
T
Name Space T

T backup-1T T backup-2T
TT
T
TT TT
Optical Disk TT
T
T T
(2)

TT
TT
T
TT
T
TT
T

TT
TT
TT
home
T
TT
TT
user1.keio
T
0 bbb
TT
0
b
OD1
OD2
T
TT
TT
TT
T
backup-1
backup-2
T
6
6

/

TT
T
Name Space T

OD1

OD2

T backup-1T T backup-2T
T
TT TT
TT
Optical Disk TT
T TT
図4.2: ユーザーのファイル管理

655

656

1989 年度 WIDE 報告書

1

方がいいという場合は存在するが，そのような時， の方法では，どのファ
イルがどのディスクにはいっているのかそのままではわからないので，どのファイルはどのディスクにはいっているかを知らせる方法を提供する必
要がある．

2

そこで， の方法のように，ホームディレクトリの下に光ディスクの名前をつけたディレクトリを置くようにすれば，どのファイルはどのディス
クにはいっているかは，明らかになる．また，このようにすることによって，ファイルを記録するディスクの指定を明らかにすることができる．
光ディスク上には，ディレクトリは作りにくいので，光ディスク別のディレクトリの下には，ディレクトリは作らない．
4.1.4

保護

ファイルは，アクセスから保護される必要がある．許可を得たユーザー
のみが，そのファイルをアクセスできるようにしなければならない．十分に保護をすることができなければ，ユーザーのプライバシーを保つことはできない．ところが，アーカイブファイルサイバーは光ディスクという，今
迄とは異なった特徴を持つメディアを使用し，インターネットワーク上で使用されるため，様々なユーザーからアクセスされる．そのため，現在のような少数を対象としたオペレーティングシステムでとられているような保護の考え方とは，異なった考えをする必要がある．そこで，ここではアクセスからのファイル，ディスクの保護について，どのように対処すべ
きか考察する．

UNIX

アクセスの型
一般的なファイルシステムでは，ファイルに対するいくつかの異なった
アクセスの型に対して，制御されたアクセス機能を提供している．
においては，

UNIX read write executeを，別々に制御することができる．これらは，普通の再書き込みが可能な
磁気ディスクをメディアとして使用しているような場合は意味がある．

\wirte",\execute" は必要なのでアーカイブファイルサーバーの場合，あろうか．
については，次のことが言える．

\write"第 14 部

657

アーカイブサーバ

1. アーカイブファイルサーバーは，本来バックアップファイル，ダンプ
ファイルといったファイルを対象としている．これらのファイルは再は意
書き込みされるような性質のものではない．そのため，味を持たない．

\wirte"2. ファイルへの書き出し，再書き込みは，もとの情報が書き込まれていたディスク上のブロックについてみれば，それらが消去されることになる．しかし消去することは，追記型では不可能であるので，は意味を持たない．

\write"2

一度書き込まれた部分を無視するようにすれば， で言われていることは正しくない．しかし，そのためには，一度書き込まれた部分は無駄となってしまう．そこまでコストがかかるならば， の理由もさらに考慮すると，はこの場合意味がないといえる．
に関しては，アーカイブファイルサーバーの管理する対象であるファイルの性質からいって，本質的に意味がないといえる．
したがって，アーカイブファイルサーバーの提供する必要のあるファイだけである．
ルに対するアクセスの型の制御は

1\wirte"\execute"\read"

光ディスクを表すディレクトリの場合はど うであろうか．再び，

 read write executeUNIX\write"\read"の三つについて考えてみる．
においては，
はそのディレクト
リを読めるかど うか，はそのディレクトリに書き込めるかど うか，はそのディレクトリをサーチすることができるかど うか，の許可を意味する．
アーカイブファイルサーバーにおいても，ファイルの作成時のみ，書き込みは行なわれる．書き込みは，光ディスクに対して行なわれる．そのたのパーミッションを得るユーザーは，その光ディスクの所有者
め，達ということになる．
は，においてはコマンドを他のユーザーに使用させても良いが，そのコマンドがあるディレクトリを見せたくはないような場合に使用される．しかし，アーカイブファイルサーバーでは，実行可能形式のファイルは扱わないため，これは意味がない．ディレクトリのには，そのディレクトリへ移動することができるかど うかの意味もある．
ディレクトリを読むことはできるが，そこへ移動することも，そのディレ\execute"\write"\execute"

UNIX\execute"

658

1989 年度 WIDE 報告書

クトリの下に存在するファイルを読むこともできないというのでは，あまにの持つディレクトリへの移動
り意味はない．そこで，の許可の意味も持たせることにする．

\read" \execute"\read" および \wirte"

従って，光ディスクを表すディレクトリの場合，を，アクセスの型の制御として提供する必要がある．
誰に許すかの指定

ファイルは，他のユーザーからのアクセスから保護されなければならな
い．では，誰に対してアクセスを許可するかは，どの様にして指定すべきも含めて，多くのオペレーティングシステムではユーであろうか．
ザーを三つの分類：

UNIX owner （ 所有者）
 group （グループ ） other （その他すべてのユーザー）にわけ，識別する．しかし，インターネットワーク上での使用を考えた場
合，この方法で十分であろうか．
インターネットワーク上では，ユーザーの属するオーガニゼーション，
グループ等によって，より細かくしていできる方が望ましい．自分の属している組織のユーザーには見せてもよい，大学関係者には見せてもよい，といった要求は十分に考えられる．そこで，アーカイブファイルサーバー
はこれに対処すべきで，十分な情報を持つアクセスリストを設定できなけ
ればならない．
単位
アクセスからファイルを保護するに当たって，どの単位でパーミッショ
おいては，アクセスパー
ンを指定することができるかを考えてみる．
において，こミッションはファイル単位で指定することができる．
れを指定するために必要な情報は，

UNIX

 所有者のユーザー ID
 所有者のグループ ID
 ファイルのアクセスモード

UNIX第 14 部

アーカイブサーバ

16

659

6

と，僅かである．
（ それぞれに ビットとっても， バイトである．
）
アーカイブファイルサーバーにおいては，より細かいアクセス制御をすべきなので，これより遥かに多くの情報を必要とする．各ファイルがそのアクセスリストを持つとすると，
4.1.5

一枚の光ディスクの持つアト リビュ−ト

一枚の光ディスクは，ファイルだけでなく，そのディスク自体の情報を持っている必要がある．また，ディスクに書かれたデータについての情報も持っていなくてはならない．一枚の光ディスクが持ってる必要のある情報はつぎのものである．

 デ ィスクの名前 デ ィスクに含まれるファイルの種類
 アクセス権リスト
 常駐かど うか インデックスリストの領域（どこからどこまで） インデックスリストの空き領域の開始アドレス
 ファイルのデータ領域
 ファイルの空きデータ領域の開始アドレス
しかし，これらのうち，すべてをディスク上に記録しておくことはできない．ファイルをディスクに書き込むたびに変化するパラメータは，ディス
ク上に記録しておくことは，不可能である．そのようなパラメータは，書き込まれたコンクリートな情報から，取り出す必要がある．
次のものが，実際にディスクに書き込まれるデータである．

 デ ィスクの名前 デ ィスクに含まれるファイルの種類
 アクセス権リスト
 常駐かど うか インデックスリストの領域
 ファイルのデータの領域
インデックスリスト及びファイルのデータ領域の空き領域の開始アドレス
は，既に書かれているインデックスリストから計算される．

660
4.1.6

1989 年度 WIDE 報告書
ファイルの持つアト リビュ−ト

UNIX

ファイルは，論理的には単なるデータの集まりであり，例えば
では，バイトの並びに過ぎない．ファイルには，名前が付けられ，その名前で参照される．他に，ファイルは，作成者，作成日時，長さ等の属性を持つ．
ファイルの属性として一般的に持たれるが，光ディスクの場合持たれることのない，または持てない属性としては，

 最後にアクセスされた時間
 最後に変更が加えられた時間
といったものがある．これらは，アクセスされるたびに変更が加えられるため，光ディスク上に記録することはできない．
光ディスク上に書かれるファイルの持つ属性は，次の通りである．

 ファイルの名前
 ファイルの所有者
 ファイルの作成された日付
 アクセス権 (パ−ミッション)
 ファイルのサイズ
 デ ィスク上のアドレス
4.2

効率

光ディスク，光ジュークボックスは，一般に使用される磁気ディスクと比較して，非常に低速である．光ジュークボックスを，磁気ディスクと同じように使用すると，ディスクの入れ換え等に時間がかかり過ぎ，使用に耐えられないと思われる．そこで，何らかの対策をすることによって，その低速性をカバーする必要がある．
低速性を補うための方法として，ここでは

 磁気ディスクをキャッシュとして使用
 デ ィスクへのアクセスのスケジューリング
を，考える．

第 14 部
4.2.1

661

アーカイブサーバ

キャッシュ

CPU

CPU

高速な
を持つコンピュータは，主記憶はそののスピードには，主記憶からデータ
おいつかないため，主記憶にアクセスする時はが読み出されるまで待たなければならない．そこで，容量は小さいけれど
も，非常に高速なメモリを用意し，これから読み出されると思われるデー
を高速に動作させようとする
タを，そこにおいておくことによって，方法が用いられている．ここで，主記憶と比較して，容量は小さいけれども非常に高速なメモリをキャッシュという．
同様に，光ディスク，光ジュークボックスと比較して高速な磁気ディス
クを，キャッシュとして使用することが，考えられる．頻繁に参照される
ファイルは，磁気ディスクに一時的に記録しておき，そのファイルがアクセスされたら，磁気ディスク上にキャッシュしてあるファイルをアクセスすることによって，それらのファイルは高速に読み出すことができる．

CPU

CPU

光ディスク上にファイルを書き出す時も，一度磁気ディスク上に書きだ
し，その後，光ディスク上にコピーすることによって，ファイルの書き出
しは早く終了することができる．
また，ネットワークを通じてファイルが送られてきた場合，光ディスク
へ書いている途中で，コネクションが切れ，正しくファイルが転送されなかったとすると，途中まで光ディスク上に書かれたファイルは無効となり，書かれた領域は無駄になってしまう．そこで，一度ファイルを磁気ディスク上に記録することによって，光ディスクの追記性による無駄を無くすことができる．
4.2.2

スケジューリング

磁気ディスクによるファイルのキャッシングは，光ディスクとの間に高速な磁気ディスクをいれることによって，読み書きを高速に終わらせようというものであった．光ジュークボックスをアクセスする時，非常に時間がかかるのはディスクが ド ライブ上になく，目的のディスクをド ライブにマウントしなければならない 光ジュークボックスに格納されてなく，目的のディスクを格納しド ラ
イブにマウントしなければならない場合である．従って，これらの動作をなるべく起こさないようにすれば，全体としての動作は早くなる．そこで，光ディスクへのアクセス要求をスケ

662

1989 年度 WIDE 報告書

ジューリングすることによって，これらの時間の消費が大きい動作を減らし，スループットをあげようとするものである．
光ジュークボックスへのアクセスのスケジューリングをするにあたって，アクセスとしては

 READ
 WRITE\READ"\WRITE"の二つがあるが，これらのうち
アクセスの方が多いだろうと思われる．また，光ディスクへする場合は磁気ディスク上に一度書かれる必要があるため，ユーザーは直接アクセスの遅さの影響を受けることはない．
したがって，スケジューリングはなわれるべきである．

4.3\READ" の場合を，主に考慮して行

ユ−ザーインタ−フェ−ス

アーカイブファイルサーバーは，ユーザーのファイルを受け取ってディ
スク上に書き込んだり，ディスク上からファイルをユーザーへ送ったりする．そのために，ユーザーはアーカイブファイルサーバーに対してあるコ
マンドを送ることによって，ファイルの出し入れを行なう．これらは，アーカイブファイルサーバーがユーザーに対して提供する機能を用いて行なわれる．そこで，ここでは，アーカイブファイルサーバーがユーザーに提供する機能の，ユーザーインターフェースについて考える．
ユーザーインターフェースを基本的に分類すると，

 インテラクティブな方式
 バッチ式の二つに分けられる．バッチ式は，ジョブを一まとめにして送り，結果を待つ方法である．インテラクティブな方式は，文字どおり会話的に処理を進めていく方式である．ここでは，この二つの方式について考えてみる．
4.3.1

インテラクティブな方式

インテラクティブなユーザーインターフェースのもとでは，コマンド，（少は打ち込まれたらすぐに解釈，実行され，結果が出力される．
し古いが ）
といったユーザーフレンド リーなオペレーティングシス

TOPS

UNIX

第 14 部

663

アーカイブサーバ

テムでは，このようなインテラクティブなユーザーインターフェースが用いられている．
インテラクティブなユーザーインタフェースのもとでは，コマンドを打ち込み，実行させてから，その結果が得られるまでの時間が，問題になる．
あまりにも長過ぎると，非常に使い難く感じてしまう．一つのコマンド を実行し，結果を得るまでに数十秒から数分かかるとしたら，現在のワーク
ステーションを使用しているようなユーザーにとっては，そのシステムは使いものにならないと感じるであろう．
アーカイブファイルサーバーにおいては，ディスクのドライブからの出し入れ，交換に平均 秒前後の時間がかかり，ディスクがジュークボック
スの外にある場合は 分前後の時間がかかると思われる．すなわち，ディ
スクをアクセスするコマンドを実行するたびに，最大 分の待ち時間がありえる．このままでは，とても使い易いインターフェースを作ることはできない．
ファイルの操作で，ディスクにアクセスする必要があるのは，

20
1

1

 ファイルのリード ファイルのライト ファイルのリストの出力である．これらのうち，実際にディスクにアクセスしなければ，結果を得られないのは， ファイルのリード と ファイルのリストの出力 である．
ファイルのライト は，磁気ディスクへ一度キャッシュする必要があるた
め，光ディスクへの書き込みは後で行なえば良い．
ファイルのリストの出力 は， ファイルのリード と比較して，また他のオペレーションと比較しても頻繁に行なわれると思われる．また，ファイルの属性だけ取り出した場合，その大きさは小さいものである．そこで，属性のみを磁気ディスク上にキャッシュしておき，リストを出力する時はそれらを持ちいる．それによって，光ディスクをアクセスする必要がなくなるので，光ディスクへのアクセスは減り，リストの出力は高速に行なわれる．
ファイルのリード に関しては，キャッシュが効果的に用いられること以外に，特に高速化の方法はない．

\

\

" \

"

\

\

4.3.2

"

\

"

"

"

バッチ式の処理バッチ式の処理では，一度に行ないたい処理をまとめて送り，それらのジョブはスケジューリングされ，順番が回ってきたら処理される．この664

1989 年度 WIDE 報告書

場合，ある時間内に終了すれば良く，インテラクティブなインターフェー
スに比べ，その応答速度は遅くとも良い．また，一度に行ないたい処理をまとめて送ることができるため，ある時間になったら自動的にバックアッ
プをとるなどの処理も行ないやすい．そのため，アーカイブファイルサー
バーのインターフェースとしては，インテラクティブな方式よりも，優れているといえる．

第 5章
実装

前章で考察された設計方法に基づいて，本章では実装方法について考
察する．

5.1

全体的な構成従来のハードデ ィスクの特性とは非常に異なっている光ディスクの特性，ジュークボックスの存在によって，カーネル内にファイルシステムを作ることは非常に難しい．従って，ここでは光ディスクのためのファイルシ
ステムを，カーネルの外に構成する．カーネル内には，光ディスク，ジュー
クボックスを操作するための必要最小限の機能のみを持たせ，光ディスク
ファイルシステムはそれらを利用して構成される．光ディスクを使用する
アプリケーションプログラムは，光ディスクファイルシステムの提供する機能を用いる．

(Figure 5.1)
この方法では，UNIX のファイルシステム内に組み込まれることはない
ため，それまでのプログラムを用いて，光ディスク上のファイルを，UNIX

ファイルシステム内のファイルと同じようにアクセスすることはできない．
アクセスするために，新しいプログラムが必要となってくる．しかし，逆
ファイルシステムのセマンティクスにとらわれる必要はなくなり，に
光ディスク，ジュークボックスの特徴をいかすようにファイルシステムを作ることが可能になる．

UNIX

カーネル内にファイルシステムを組み込まないため，光ディスクファイ
ルシステムは，スケジューリングを行なうために，カーネル内のスケジュー
リングを利用することができない．そのため，光ディスクファイルシステム
内に，独自のディスパッチループを持たなければならない．各アプリケー
ションが，ファイルシステムを同時に使用するためには，

1. 光ディスクファイルシステムを，ライブラリとして提供し，その中に相互排除の機能を設ける

665

666

1989 年度 WIDE 報告書

Application
OpticalDisk
FileSystem
KERNELHARDWARE
8

Network
図

HD

9

OD

5.1: アーカイブファイルサーバーの構成

2. 光ディスクファイルシステムを一つのプロセスとして実現し，各アプ
リケーションはそのプロセスと交信することによって，ファイルシス
テムの持つ機能を利用する （ クライアント・サーバー型）

2

1

といった方法が考えられるが，ここでは の方法を用いる． の方法では，ライブラリの大きさが非常に大きくなり，各アプリケーションのサイズを非常に大きくしてしまう．また，光ディスクファイルシステムの構造を変更したい時，そのライブラリを用いているアプリケーションは，再び新しいライブラリとリンクし直す必要がある． の方法では，それらの点は解決されている．

2

5.2

ファイルシステムの構成

光ディスクファイルシステムは主に， 光ディスクファイルサブシステム
 ファイルキャッシュ ライブラリインターフェース

第 14 部

6667

アーカイブサーバ

application

6
library ?interface
6?

OpticalDisk Filesystem

OD le subsystem6?

6

le cache

?

6
?

?

kernel図5.2: 光ディスクファイルシステムの構成

668

1989 年度 WIDE 報告書から構成される．

(Figure 5.2)

光ディスクファイルサブシステムは，光ディスクファイルシステムを構成する最も大きな部分で，ファイルシステムの木構造の構成，光ディスクの管理等が行なわれる．
5.2.1

ファイルキャッシュ

ファイルキャッシュは，ファイルの出し入れを効率良く処理するために使用され，高速なハードディスクを用いて構成される．ファイルキャッシュ
は，ファイルアーカイブを一時的に記憶するためのものである．ファイルの小さなファイルが多くある
アーカイブは，普通のファイルが 〜のとは異なり，かなりの大きさを持つと考えられる．アプリケーションプ
によってアーカイブし，
ログラムのソースファイルを，によって圧縮したものでも，から程度の大きさを持つものは，多く存在する．例えば，エディタとして非常に良く使用されているは，されされたもので
である．

1 5KB

\tar"
200KB

Emacs"\tar"\compress"\compress"

1MB

500KB

\GNU

このような，大きなファイルをキャッシュし，効率を良くするためには，
そのために用いるハードデ ィスクは，十分な容量を持ち，また高速でなければならない．十分な容量を持たなければ，頻繁にアクセスされるファイルをハードディスク上に置くことができない．その結果，ハードデ ィスク
上にない，ファイルがアクセスされるたびに，光ディスクとハードデ ィスクの間での，ファイルのコピーばかりが頻繁に起こり，キャッシュとしての役割を果たさないばかりか，返って効率を落すことになってしまう．また，十分に高速でなければ，キャッシュとして役に立たない．
5.2.2

ライブラリインターフェース

ライブラリインターフェースは，アプリケーションに対して，光ディスクを利用するためのインターフェースを提供する．アプリケーションプロ
グラムは，このライブラリを用いることによって，容易にアーカイブファ
イルサーバーの機能を用いることができるようにする．ここでは，光ディ
スクファイルシステムと，その機能を用いるアプリケーションは，クライ
アント・サーバー型の形態を取るため，ライブラリはファイルシステムとの交信をサポートするものとなる．
ライブラリインターフェースは，次の関数から構成される．

 OD Open Server（光ディスクファイルシステムのサーバープロセスとの交信を開始する）

第 14 部

アーカイブサーバ

 OD Close Server（ サーバープロセスとの交信を終了する）

 OD Open（ファイルのオープンをする）

 OD Close（ファイルのクローズをする）

 OD Create（ファイルの作成をする）

 OD Read（ファイルの読み込みを行なう）

 OD Write（ファイルへの書き込みを行なう）

 OD Lseek（ファイルでのシークを行なう）

 OD GetAttr（ファイルのアトリビュートを得る）

 OD GetFsStat（ファイルシステムのステータスを得る）

 OD ChangeDir（ カレントデ ィレクトリを移動する）

669

670

1989 年度 WIDE 報告書