JPS63201864A - 分散型データ処理システム - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるた
め要約のデータは記録されません。

Description

【発明の詳細な説明】 以下にしたがって本発明を説明する。

Ａ、産業上の利用分野 Ｂ、従来技術 Ｃ０発明が解決しようとする問題点 り０問題点を解決するための手段 Ｅ、実施例 Ｅｌ、はじめに（第２図〜第７図） Ｅ２．分散ファイル・システムにおける操作（第１図、
第８図〜第１２図） Ｅ３．ファイル・アクセスの同期モード（第１３図、第
１４図） Ｅ４．ロッキング（第１５図〜第１９図）ＵＮＩＸファ
イル・ロッキング ロック・テーブル ロック待ち デッドロック 分散型ファイル・サポート・ロック制御ファイル・ロッ
キング構造 内部の詳細 ファイル・アクセス構造ロック（第１７図、第１８図） 一例（第１９図） Ｆ０発明の効果 Ａ、産業上の利用分野 本発明は、一般に分散データ処理システム用のオペレー
ティング・システムの改良に関し、さらに具体的には、
ローカル・エリア・ネットワーク（ＬＡＮ）または広域
ネットワーク（ＷＡＮ）で相互接続された多重プロセッ
サ・システム用のオペレーティング・システムに関する
ものである。

ＬＡＮまたはＷＡＮを構成するため、１８Ｍ社のシステ
ム・ネットワーク・アーキテクチャ（ＳＮＡ）を使用す
ることができる。本発明にもとづくオペレーティング・
システムを使うと、ファイルがシステム中のどこにあろ
うと、システム中のプロセッサによってそれらのファイ
ルにアクセスできるようになる。本発明の好ましい実施
例をここではＵＮＩＸ　（ＡＴＴの商標）オペレーティ
ング・システムの１バージヨンで実施された好ましい実
施例の形で開示するが、本発明は他の様々なオペレーテ
ィング・システム中でも実施できる。

Ｂ、従来技術 １台の実計算機を複数台の計算機に見せる仮想計算機オ
ペレーティング・システムが、従来技術で知られている
。こうした計算機は、それを載せる実計算機に非常に類
似することもあり、また非常に異なることもある。多数
の仮想計算機オペレーティング・システムが開発されて
いるが、その中で恐らく最も広く使われているのは、Ｉ
ＢＭシステム／３７０上で走行するＶＭ／３７０である
と思われる。ＶＭ／３７０オペレーティング・システム
は、端末から操作する複数のユーザが、様々なディスク
の量と記憶容量をもつ完璧なシステム／３７０を有する
かのような錯覚を生み出す。

物理的ディスク装置は、ＶＭ／３７０オペレーティング
・システムによって管理される。ディスク上に存在する
物理的ボリュームが様々なサイズの仮想ボリュームに分
割され、ユーザが行なうマウントと呼ばれる処理によっ
て割り振られアクセスされる。マウントとは、物理的ボ
リュームを定義してＶＭ／３７０オペレーティング・シ
ステムに付加し、ボリュームの仮想特性、たとえばサイ
ズ、セキュリティ、所有権などを定義することである。

さらに、ＶＭ／３７０の下では、ユーザは同じローカル
・プロセッサ上でまたは遠隔の別のプロセッサ上でＶＭ
／３７０の下で走行する、他のどのオペレーティング・
システムにもアクセスしそれを使用することができる。

オースチンにいるユーザが、ＶＭ／３７０の「パススル
ー」と呼ばれる機能を使って同じプロセッサ上、または
、たとえば、同じＳＮＡネットワークに接続されたフラ
ンスのパリにあるプロセッサ上の別のＶＭ／３７０マタ
はＭＶ／３７０オペレーティング・システムにアクセス
することができる。ユーザが一度この機能を使うと、そ
のユーザはその別のオペレーティング・システムに接続
されたファイルを処理のために使用することができる。

この手法にはいくつかの大きな欠点がある。第一に、ユ
ーザが「パススルー」特性を使ってローカルなまたは遠
隔の別のオペレーティング・システムにアクセスすると
き、以前使用されていたファイルと操作環境とが、新し
いセツションが終了するまで使えなくなる。他のセツシ
ョンからのファイルを処理する唯一の方法は、それらの
ファイルヲ他のオペレーティング・システムに送って、
両方のディスク上で実際にコピーを複製することである
。

第二に、ユーザは、アクセスしようとするすべてのシス
テムに別々に「ログ・オン」しなければならない。こう
することで、システムの保全性を保護するために必要な
セキュリティがもたらされるが、そのことはまたユーザ
にとっては大変な負担となる。その他の背景知識につい
ては、Ｈ，Ｍ。

ディチル（Ｈａｒｖｅｙ　Ｍ、　Ｄｓｉｔｅｌ）著の教
科書「オペレーティング・システム入門（Ａｎ　Ｉｎｔ
ｒｏｄｕｃｔｉｏｎｔｏ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓ
ｔｅｍｓ）　Ｊ　Ｎ　Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ刊
（１９８４年）、とくにその第２２章ｒＶＭ：仮想計算
機オペレーティング・システム（ＶＭ　：Ａ６一 Ｖｉｒｔｕａｌ　Ｍａｃｈｉｎｅ　Ｏｐｅｒａｔｉｎｇ
　Ｓｙｓｔｅｍ）　Ｊを参照されたい。より詳しい考察
については、Ｈ，ローリン（Ｈａｒｏｌｄ　Ｌｏｒｉｎ
）とＨ，Ｍ、ディチル共著の教科書「オペレーティング
・システム（Ｏｐｅｒａｔ　ｉｎｇＳｙｓｔｅｍｓ）　
Ｊ　Ｎ　Ａｄｄｉｓｏｎ−ＩＪｅｓｌｅｙ刊（１９８１
年）、特にその第１０章［仮想計算機（Ｖｉｒｔｕａｌ
Ｍａｃｈｉｎｅｓ　）　Ｊを参照されたい。

以下では、ＵＮＩＸオペレーティング・システムの１バ
ージヨンで本発明を実施した場合について説明するが、
本発明はＵＮＩＸオペレーティング・システムに類似す
る特徴をもつ他のオペレーティング・システムでも使用
できる。ＵＮＩＸオペレーティング・システムは、ベル
研究所（ＢｅｌｌＴｅｌｅｐｈｏｎｅ　Ｌａｂｏｒａｔ
ｏｒｉｅｓ、　Ｉｎｃ、）がディジタル０エクイツプメ
ント社（Ｄｉｇｉｔａｌ　ＥｑｕｉｐｍｅｎｔＣｏｒｐ
ｏｒａｔｉｏｎ、　ＤＥＣ）のミニコンピユータ用に開
発したものであるが、広範囲のミニコンピユータ用、そ
れに最近ではマイクロコンピュータ用のオペレーティン
グ・システムとして広く使われている。この普及の一因
は、ＵＮＩＸオペレーティング・システムがアセンブリ
言語ではなく、やはりベル研究所で開発されたＣプログ
ラミング言語で書かれており、したがって、プロセッサ
の種類を問わないことである。したがって、様々な計算
機用にそれにＣ能力を与えるために書かれたコンパイラ
を使うと、ＵＮＩＸオペレーティング・システムをある
計算機から別の計算機に移すことが可能になる。すなわ
ち、ＵＮＩＸオペレーティング・システム環境用に書か
れたアプリケーション・プログラムも、計算機間で移植
可能である。ＵＮＩＸオペレーティング・システムの詳
細については、ｒＵＮＩＸＴＭシステム、ユーザーズ・
マニュアル、システムＶ　（Ｕ　Ｎ　Ｉ　ＸＴＭＳｙｓ
ｔｅｍ、　Ｕｓｅｒ’ｓ　Ｍａｎｕａｌ。

Ｓｙｓｔｅｍ　Ｖ）　Ｊ　ｚ　Ｗｅｓｔｅｒｎ　Ｅｌｅ
ｃｔｒｉｃ　Ｃｏ、、　１９８３年１月刊を参照された
い。ＵＮＩＸオペレーティング・システムについての秀
れた概説が、Ｂ、Ｗ。

カーニガン（Ｂｒｉａｎ　ｔＪ、　Ｋｅｒｎｉｇｈａｎ
）とロブ・バイツ（Ｒｏｂ　Ｐｉｋｅ）の共著「ユニッ
クス・プログラミング環境（Ｔｈｅ　Ｕｎｉｘ　Ｐｒｏ
ｇｒａｍｍｉｎｇＥｎｖｉｒｏｎｍｅｎｔ）　Ｊ　、Ｐ
ｒｅｎｔｉｃｅ−Ｈａｌｌｓ　１９８４年刊に出ている
。ＵＮＩＸオペレーティング・システムの設計の詳細に
ついては、Ｍ、Ｊ、バッハ（Ｈａｕｒｉｃｅ　Ｊ、Ｂａ
ｃｈ）著「ユニックス・オペレーティング・システムの
設計（Ｄｅｓｉｇｎ　ｏｆ　ｔｈｅ　Ｕｎｉｘ　Ｏｐｅ
ｒａｔｉｎｇ　Ｓｙｓｔｅｍ）　Ｊ　、Ｐｒｅｎｔｉｃ
ｅ−Ｈａｌｌ、１９８６年刊に出ている。

ＡＴＴのベル研究所は、多数の団体にＵＮＩＸオペレー
ティング・システム使用のライセンスを供与しており、
現在いくつかのバージョンがある。

ＡＴＴから出た最新のバージョンは、バージョン５．２
である。バークレイ・バージロンとして知られるＵＮＩ
Ｘオペレーティング・システムの別のバージロンが、カ
リフォルニア州立大学ハーク１４校で開発された。広く
使われているＭＳ−ＤＯ８（マイクロソフト社の商標）
およびパーソナル・コンピュータ用のＰＣ−ＤＯ８（Ｉ
ＢＭ社の商標）オペレーティング・システムを開発した
マイクロソフト社（旧ｃｒｏｓｏｆｔ　）は、ＸＥＮＩ
Ｘの商標で知られるバージョンを出している。ＩＢＭＲ
Ｔ　　ＰＣ（ＲＩＳＣ（縮小命令セット・コンピユータ
）技術パーソナル・コンピュータ、ＲＴとＲＴＰＣはＩ
ＢＭ社の商標）を１９８５年に発表したのに伴って、Ｉ
ＢＭ社はＡＩＸ　（拡張対話型エグゼクティブ、ＡＩＸ
はＩＢＭ社の商標）と呼ばれる新しいオペレーティング
・システムを公開した。ＡＩＸは、アプリケーション・
インターフェース・レベルでＡＴＴのＵＮＩＸオペレー
ティング・システム、バージョン５．２と互換性かあ）
）、ＵＮＩＸオペレーティング・システム、バージョン
５．２に対する拡張機能を含んでいる。ＡＩＸオペレー
ティング・システムの詳細については、ｒＡＩＸオペレ
ーティング・システム技術解説書（ＡＩＸ　Ｏｐｅｒａ
ｔｉｎｇ　Ｓｙｓｔｅｍ　ＴｅｃｈｎｉｃａｌＲｅｆｅ
ｒｅｎｃｅ　）　Ｊ　、第１版、ＩＢＭ　Ｃｏｒｐｌｌ
　９８５年１１月刊を参照されたい。

本発明は、具体的には、複数のプロセッサがネットワー
ク内で相互接続されることを特徴とする、分散データ処
理システムに関係する。実際に実施された形では、本発
明は、ＩＢＭのシステムネットワーク・アーキテクチャ
（ＳＮＡ）　、さらに具体向にはＳＮＡ　　ＬＵ６．２
拡張プログラム間通信（ＡＰＰＣ）で相互接続された複
数のＩＢＭＲＴ　　ＰＣ上で機能する。ＳＮＡでは、そ
のリンク・レベルとして、ゼロックス社が開発したロー
カル・エリア・ネットワーク（ＬＡＮ）であるイーサネ
ット（Ｅｔｈｅｒｎｅｔはゼロックス社の商標）または
５ＤＬＣ（同期データ・リンク制御）を使う。

イーサネット・ローカル・エリア・ネットワークを含め
てローカル・エリア・ネットワークの簡単な説明は、Ｌ
、Ｅ、ジョーダン（Ｌａｒｒｙ　Ｅ。

Ｊｏｒｄａｎ　）とＢ、チャーチル（Ｂｒｕｃｅ　Ｃｈ
ｕｒｃｈｉｌｌ）の共著ｒＩＢＭ　　ＰＣ用の通信ネッ
トワーキング（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｎｄ
　Ｎｅｔｗｏｒｋｉｎｇ　ｆｏｒ　ｔｈｅ　ＩＢＭＰＣ
）　Ｊ　Ｎ　Ｒｏｂｅｒｔ　Ｊ、Ｂｒａｄｙ　（Ｐｒｅ
ｎｔｉｃｅ−Ｈａｌ１社）、１９８３年刊に出ている。

コンピュータ用通信システム、特にＳＮＡとＳＤＩ、Ｃ
についてのより明確な説明は、Ｒ，Ｊ、シプサー（Ｃｙ
ｐｓｅｒ　）著「分散システム用通信アーキテクチャ （Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　Ａｒｃｈｉｔｅｃｔ
ｕｒｅ　ｆｏｒＤｉｓｔｒｉｂｕｔｅｄ　Ｓｙｓｔｅｍ
ｓ）　Ｊ　、Ａｄｄｉｓｏｎ−ＩＪｅｓｌｅｙｌｌ　９
７８年刊に出ている。ただし、本発明は、イーサネット
・ローカル・エリア・ネットワークやＩＢＭ　　ＳＮＡ
以外のネットワークで相互接続された、ＩＢＭ　　ＲＴ
　　ＰＣ以外の様々なコンピータを用いても実施できる
ことを了解されたい。

前述のように、以下では、通信ネットワーク中の分散デ
ータ処理システムを対象として本発明を説明する。この
環境では、ネットワークのあるノードにある各プロセッ
サは、どのノードにファイルがあろうと、潜在的にその
ネットワーク内のすべてのファイルにアクセスすること
ができる。

第２図に示すように、分散ネットワーク環境１は、通信
リンクまたは通信ネットワーク３を介して接続された２
つ以上のノードＡ１Ｂ、Ｃから構成される。ネットワー
ク３は上記のようなローカル・エリア・ネットワーク（
ＬＡＮ）でも広域ネットワーク（ＷＡＮ）でもよい。後
者は、システムの他のノードまたはＳＮＡネットワーク
への交換回線または専用回線テレプロセッシング（ＴＰ
）接続を含む。ノードＡ、Ｂ１Ｃのどこにも、上記のＩ
ＢＭ　　ＲＴ　　ＰＣのような処理システム１０Ａ、ｌ
０８１１０Ｇがあり得る。こうした処理システムＩＯＡ
、ｌ０８１１０Ｇはそれぞれ単一ユーザ・システムでも
複数ユーザ・システムでもよく、ネットワーク３を使っ
てネットワーク内の遠隔ノードにあるファイルにアクセ
スする能力をもつ。たとえば、ローカル・ノードＡにあ
る処理システム１０Ａは、遠隔ノードＢおよびＣにある
ファイル５Ｂと５０にアクセスできる。

遠隔ノードにアクセスする際にぶつかる問題は、まずス
タンドアロン・システムがどのようにしてファイルにア
クセスするかを検討すると、よく理解できる。第３図に
符号１０で示すようなスタンドアロン・システム内では
、オペレーティング・システム１１中のローカル・バッ
ファ１２を使って永久記憶装置２、たとえばハード・フ
ァイルやパーソナル・コンピュータ中のディスクとユー
ザ・アドレス空間との間で転送されるデータを緩衝記憶
する。オペレーティング・システム１１内のローカル・
バッファ１２は、ローカル・キャッシュあるいはカーネ
ル・バッファとも呼ばれる。ＵＮＩＸオペレーティング
・システムのカーネルの詳細については、上記のカーニ
ガン等の著書およびバッハの著書を参照されたい。

ローカル・キャッシュは、メモリ常駐ディスクとして理
解すると最も理解しやすい。データはディスク上で持っ
ていた物理的特性を保持するが、情報は今や媒体内に存
在し、主システム記憶装置で達成される速度に非常に近
いより速いデータ転送速度の実現に貢献している。

スタンドアロン・システム内で、カーネル・バッファ１
２はブロック１５により識別される。この番号は装置番
号であり、またその装置内の論理ブロック番号でもある
。読取りシステム・コール１６が発行されるとき、その
コールは、第４図のステップ１０１に示すように、ファ
イル５のファイル記述子およびファイル５内のバイト範
囲と一緒に発行される。オペレーティング・システム１
１はこの情報を取り出し、ステップ１０２でそれを装置
番号および装置内の論理ブロック番号に変換−１４＝ する。次に、オペレーティング・システム１１は、ステ
ップ１０３で、装置番号および論理ブロック番号にもと
づいてキャッシュ１２を読み取る。

ディスク２から読み取られたデータは、キャッシュ・ブ
ロック１５が必要となるまでキャッシュ・ブロック１５
に保管される。その結果、処理システム１０上で走行中
のアプリケーション・プログラム４からディスク２から
以前に読み取られたものと同じデータに対する読取りが
続けて要求されると、それはディスク２からではなくて
キャッシュ１２からアクセスされる。キャッシュ１２か
ら読み取るのは、ディスクへのアクセスはど時間がかか
らない。したがって、キャッシュから読み取ることによ
り、アプリケーション・プログラム４のパフォーマンス
が向上する。明らかに、アクセスしようとするデータが
キャッシュに入ってない場合は、ディスクにアクセスし
なければならないが、それが必要となるのは稀である。

同様に、アプリケーション・プログラム４から書き込ま
れたデータは、直接ディスク２には書き込まれず、キャ
ッシュ１２に書き込まれる。このことによっても時間が
節減され、アプリケーション・プログラムのパフォーマ
ンスが向上する。

キャッシュ１２内の修正されたデータ・ブロックハ、オ
ペレーティング・システム１１の制御下で周期的にディ
スク２に保管される。

本発明を実施した環境であるＡＩＸオペレーティング拳
システムを使ったスタンドアロン・システムでキャッシ
ュを使うと、連続する読取りおよび書込みディスク操作
の必要がなくなるので、システム・ディスクの全体的パ
フォーマンスが向上し、アクセス時間が減少する。

第２図に示したような分散ネットワーキング環境では、
ローカル・ノードＣにある処理システム１０Ｇがノード
Ａからファイル５Ａを読み取る方式が２通りある。１つ
の方式では、処理システム１０Ｃがファイル５Ａの全体
を複写し、それがノードＣにあるローカル・ファイル５
Ｃであるかのように読み取ることができる。このやり方
でファイルを読み取ると、ノードＣでファイル５Ａが複
写された後で、たとえばノードＢにある別の処理システ
ムＩＯＢがファイル５Ａを修正する場合に問題が生じる
。処理システム１０Ｇは、ファイル５Ａに対する最近の
修正にアクセスできないことになる。

処理システム１０ＣがノードＡにあるファイル５Ａにア
クセスするもう一つの方式は、ノードＣにある処理シス
テム１０Ｃが要求したとき、一度に１つのブロックを読
み取るものである。この方式に伴う問題は、読取りのた
びにネットワーク通信リンク３を介してファイルがある
ノードＡまで行かなければならないことである。連続す
る読取りのたびにデータを送るのは時間の浪費である。

ネットワークを介してファイルにアクセスする場合、」
１記の２つの競合する問題が生じる。一つの問題は、連
続する読取りと書込みのためにネ・ソトワークを介して
データを送信するのに時間がかかることである。他方、
ネットワークのトラフィックを減らすためにファイル・
データをノードに記憶する場合、ファイルの整合性が失
われるおそれがある。たとえば、いくつかのノードのう
ちの一つがファイルに書込みを行なっている場合、その
ファイルにアクセスしている他のノードが、令書き込ま
れたばかりの最近の更新済みファイルにアクセスしてい
ないことがある。したがって、ファイルの整合性が失わ
れ、ノードがアクセスしているファイルが正しくない古
くなったものであることがある。本明細書中では、ファ
イルを永久的に記憶している処理システムを指すのに「
サーバ」という言葉を使い、そのファイルにアクセスす
るプロセスを有する他の任意の処理システムを指すのに
「クライエント」の語を使うことにする。以下で説明す
る本発明は、分散情報管理の問題に解決策を与える、オ
ペレーティング・システムの一部分である。

ＵＮＩＸオペレーティングシステム環境内で分散データ
処理システムをサポートする方法は、他にも知られてい
る。たとえば、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓはネ
ットワーク・ファイル・システム（ＮＦＳ）を発表し、
ベル研究所は遠隔ファイル・ンステム（ＲＦＳ）を開発
した。Ｓｕｎ旧ｃｒｏｓｙｓｔｅｍｓのＮＦＳは一連の
刊行物に記載されている。たとえば、Ｓ、Ｒ，クレイマ
ン（Ｋｌｅｉｍａｎ）　ｒ　Ｖノード：　５ｕｎＵＮＩ
Ｘにおける多重ファイル・システム・タイプ用アーキテ
クチ＋　（Ｖｎｏｄｅｓ：　Ａｎ　Ａｒｃｈｉｔｅｃｔ
ｕｒｅｆｏｒ　Ｍｕｌｔｉｐ］ｅ　Ｆｉｌｅ　Ｓｙｓｔ
ｅｍ　Ｔｙｐｅｓ　ｉｎ　Ｓｕｎ　ＵＮＩＸ）　ＪＵＳ
ＥＮＩＸ　　１９８ｅ年夏季国際技術会議・展示会議事
録、２３８−２４７ページ；Ｒ，サンドバーブ（Ｒｕｓ
ｓｅｌ　Ｓａｎｄｂｅｒｇ）等のｒＳｕｎネットワーク
・ファイル・システムの設計と実施（Ｄｅｓ　ｆｇｎａ
ｎｄ　Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ　ｏｆ　ｔｈｅ　
Ｓｕｎ　Ｎｅｔｗｏｒｋ　ＦｉｌｅＳｙｓｔｅｍ）Ｊ、
ＵＮＥＮＩＸ　　１９８５年会議議事録、１１９−１３
０ページ；Ｄ、ウオールシュ（Ｄａｎ　Ｗａｌｓｈ）等
のｒＳｕｎネットワーク・ファイル・システムの概要（
Ｏｖｅｒｖｉｅｗ　ｏｆ　ｔｈｅ　Ｓｕｎ　Ｎｅｔｗｏ
ｒｋＦｉｌｅ　Ｓｙｓｔｅｍ）　Ｊ　１１７〜１２４ペ
ージ；ジロメイ・チャン（Ｊｏｍｅｉ　Ｃｈａｎｇ）の
「状況モニタがＮＦＳに対するネットワーク・ロッキン
グ・サービスをもたらす（Ｓｔａｔｕｓ　Ｍｏｎ１ｔｏ
ｒ　Ｐｒｏｖｉｄｅｓ　ＮｅｔｗｏｒｋＬｏｃｋｉｎｇ
　５ｅｒｖｉｃｅ　ｆｏｒ　ＮＦＳ）Ｊ　；ジョメイ・
チャンの「サンネット（Ｓｕｎｎｅｔ）Ｊ　、７１−７
５ページ；Ｂ、ティラー（Ｂｒａｄｌｅｙ　Ｔａｙｌｏ
ｒ）のｒＳｕｎ環境における安全なネットワーキング（
ＳｅｃｕｒｅＮｅｔｗｏｒｋｉｎｇ　ｉｎ　ｔｈｅ　Ｓ
ｕｎ　Ｅｎｖｉｒｏｎｍｅｎｔ）　Ｊ　２８−３６ペー
ジ。ＡＴ＆ＴのＲＦＳも一連の刊行物に記載されている
。たとえば、Ａ、Ｐ、　　リフキン（Ａｎｄｒｅｗ　Ｐ
、　Ｒｉｆｋｉｎ）等のｒＲＦｓアーキテクチャの概要
（ＲＦＳ　Ａｒｃｃｈｉｔｅｃｔｕｒａｌ　Ｏｖｅｒｖ
ｉｅｗ）　Ｊ　Ｕ　Ｓ　ＥＮＩＸ会ｉｉ議事録、ジョー
シア州アトランタ（１９８６年８月）、１−１２ページ
；Ｒ，ハミルトン（Ｒｉｃｈａｒｄ　Ｈａｍｉｌｔｏｎ
）等の「遠隔ファイル共用に対する管理者の意見Ｊ、１
−９ページ；Ｔ。

ヒユートン（Ｔｏｍ　Ｈｏｕｇｈｔｏｎ　）等の「ファ
イル・システム・スイッチ（Ｆｉｌｅ　Ｓｙｓｔｅｍｓ
　５ｗ１ｔｃｈ）　Ｊ、１−２ページ；Ｄ、Ｊ、オラン
ダ−（Ｄａｖｉｄ　Ｊ。

０１ａｎｄｅｒ）等の「システムＶにおけるネットワー
キング用フレームワーク（Ａ　Ｆｒａｍｅｗｏｒｋ　ｆ
ｏｒＨｅｔｗｏｒｋｉｎｇ　ｉｎ　Ｓｙｓｔｅｍ　Ｖ）
　Ｊ、１−８ページ。

本発明をその中で実施する分散サービス・システムの、
たとえばＳｕｎ　ＭｉｃｒｏｓｙｓｔｅｍｓのＮＦＳと
は区別される一つの特徴は、Ｓｕｎの方法が基本的に非
保存型マシーンを設計するためのものであったというこ
とである。もっと具体的に言うと、分散システム内のサ
ーバを無状態に設計することができる。すなわち、サー
バは、どのクライエント・ノードがサーバ・ファイルを
オープンしたか、クライエント・プロセスが読取り専用
モードでファイルをオープンしたのかそれとも読取り／
書込みモードでファイルをオープンしたのか、あるいは
クライエントがそのファイルのバイト範囲にロックをか
けているかどうかを含めて、クライエント・ノードに関
する情報を何も記憶しない。このような実施形態をとる
と、クライエント・ノードが故障したり、あるいはサー
バ資源に対する要求を解除したとサーバにきちんと知ら
せずにオフラインになったときに生じる、誤り回復状況
をサーバが処理する必要がないので、サーバの設計が簡
単になる。

本発明をその中で実施する分散サービス・システムの設
計では、全く異なる方法が取られた。もつと具体的に言
うと、この分散サービス・システムは、「状態保存型イ
ンプリメーション」であると特徴づけることができる。

本明細書に記載する「状態保存型」サーバは、誰がその
ファイルを使っているか、およびファイルがどのように
使われているかに関する情報を保持する。それには、サ
ーバが何らかの方法であるクライエントとの接触の喪失
を検出して、そのクライエントに関する蓄積された状態
情報を廃棄できるようにする必要がある。しかし、本明
、細書に記載するキャッシュ管理戦略は、サーバがそう
した状態情報を保持しない限り実施できない。キャッシ
ュの管理は、下記で説明するように、サーバ・ファイル
をオープンせよとの要求を発行しているクライエント・
ノードの数およびそうしたオープンが読取りモードであ
るかそれとも書込みモードであるかによって影響を受け
る。

Ｃ０発明が解決しようとする問題点 したがって、ネットワーク内でのファイルの位置および
パフォーマンスに関してユーザ透過性を〜２２− もたらす、通信ネットワーク内で相互接続された多重プ
ロセッサ式データ処理システムをサポートするオペレー
ティング・システム用の分散サービス・システムを提供
することが、本発明の一般的目的である。

本発明の第二のより具体的な目的は、デッドロックの問
題を防ぐためのファイル・アクセス制御構造ロック（ｆ
ａｓロック）を備えた分散型ファイル管理システム（Ｄ
ＦＳ）をもたらす手法を提供することである。

Ｄ２問題点を解決するための手段 本発明によれば、これらの目的は、遠隔システムからア
クセスされる各ファイルごとにｆａｓロックを作成する
ことにより達成される。ｆａｓロックは、ファイルのｉ
ノード（インデックス・ノード、ファイルの保護ビット
、種別、ポインタ等を含むファイル領域）をロックする
代わりにロックするのに使用される。こうすると、ＤＦ
Ｓがファイルに対するアクセスを制御し、デッドロック
の問題の発生を回避することができる。

Ｅ、実施例 Ｅｌ、はじめに 下記の開示では、物理的には異なる複数の計算機内に存
在するファイルが、ローカル計算機のファイル・システ
ムの一部分に見えるように、計算機のファイルを管理す
る論理が変更されるという分散ファイル・システムを構
築するときにぶつかる問題に対する解決策について説明
する。ここで説明するインプリメンテーションは、ＡＩ
Ｘオペレーティング・システムのファイル・システムの
拡張である。このＡＩＸオペレーティング・システムの
詳細については、前記で参照した技術解説書を参照され
たい。木構造ファイル・システム、ディレクトリ、およ
びｉノードを含むファイル・システム構成などのＡＩＸ
ファイル・システムに関する特定の知識があるものと仮
定する。ＵＮＩＸオペレーティング・システムでは、個
々のディスク（またはディスケット、またはディスクの
区画）にファイル・システムが含まれる。この議論に関
係のあるファイル・システムの基本的態様を下記に列挙
する。

ａ）個別のファイル・システム上の各ファイルが、その
ｉノード番号によって一義的に識別される。

ｂ）ディレクトリもファイルであり、したがってディレ
クトリもそのｉノード番号によって一義的に識別できる
。

Ｃ）ディレクトリは、次の形式の項目の列を含む。

名前　−ｉノード番号 ただし、ｉノード番号は、単純ファイルのｉノード番号
でも別のディレクトリのｉノード番号でもよい。

ｄ）規約により、ファイル・システムのルート・ディレ
クトリのｉノード番号は、ｉノード番号２とする。

したがって、ある装置のファイル・システム内のパス”
　／ｄｉｒ　１　／ｄｉｒ　２　／ｆｉｌｅ　”をたど
るには、次のようなステップをとる。

１、ｉノード番号２で識別されるファイル（その装置の
ルート・ディレクトリ）を読み取る。

２、そのディレクトリを探索して、ｎａｍｅ＝ｄｉｒ　
１の項目を見つける。

３、ｄｉｒｌに関連するｉノード番号で識別されるファ
イル（これはパス中の次のディレクトリである）を読み
取る。

４、そのディレクトリを探索して、ｎａｍｅ　＝ｄｉｒ
　２の項目を見つける。

５、ｄｉｒ２に関連するｉノード番号で識別されるファ
イル（これはパス中の次のディレクトリである）を読み
取る。

６、そのディレクトリを探索して、ｎａｍｅ＝ｆｉｌｅ
の項目を見つける。

７、このディレクトリ内のファイルに関連するｉノード
番号が、パス”　／ｄｉｒ　１　／ｄｉｒ　２　／ｆｉ
ｌｅ　”で識別される単純ファイルのｉノード番号であ
る。

個別のファイル・システム上に存在するファイル・ツリ
ーは、あるノードの集合ファイル・ツリーを構築するた
めの構成要素である。あるノードのルート・ファイル・
システムを含む特定の装置（たとえば、ハード・ファイ
ル区画）を装置と呼ぶ。マウント操作の実行により、別
の装置」二にあるファイル・ツリーをノードのファイル
・ツリーに付加することができる。マウント操作の２つ
の主要パラメータは、（１）マウントされるファイル・
ツリーを保持する装置の名前と（２）装置のファイル・
ツリーをマウントするディレクトリへのパスである。こ
のディレクトリは、すてにノードのファイル・ツリーの
一部分でなければならない。すなわち、ルート・ファイ
ル・システム内のディレクトリ、または（マウント操作
によって）ノードのファイル・ツリーにすでに付加され
たファイル・システム内のディレクトリでなければなら
ない。

マウントの実行後は、普通ならｒ上にマウントされた」
ディレクトリを通って流れるはずのパスが、マウントさ
れたファイル・システムのルートｉノードを通って流れ
る。マウント操作は、次のように進行する。

１、マウント点までパスをたどり、マウントされる装置
がカバーするディレクトリのｉノード番号と装置番号を
入手する。

２、基本的に次のものを含むデータ構造を作成する。

ａ）カバーされるディレクトリの装置番号とｉノード番
号 ｂ）マウントされる装置の装置名 ノーどの集合ファイル・ツリー内でのパスのたどり方は
、（ａ）上にマウントされたｉノード（またはもちろん
パスの終点）にぶつかるまで、装置ファイル・ツリー内
のパスをたどること、（ｂ）マウント点にぶつかるとマ
ウント・データ構造を使って、パス中で次にどの装置が
あるか判定すること、および（Ｃ）マウント構造内で指
示される装置中のｉノード２（ルートｉノード）からパ
スをたどり始めることからなる。

マウント・データ構造は揮発性である。すなわちディス
ク上に記録されない。初期プログラム・ロード（ｒＰＬ
）の一部として計算機が電源投入されるたびに、所期の
マウントのリストを再発行しなければならない。以上の
議論では、従来のＵＮＩＸオペレーティング・システム
がファイル・システム全体のマウントをどのように使っ
てファイル・ツリーを作成し、またそのようなファイル
・ツリー内でどのようにパスをたどるか説明した。

こうしたインプリメンテーションは、ある装置上に存在
するファイル・システム全体をマウントすることに限定
されている。本明細書に記載する仮想ファイル・システ
ム・コンセプトは、（１）装置をマウントできる土にデ
ィレクトリもマウントできるようにすることにより、あ
る装置上に存在するファイル・システムの一部分をマウ
ントすること、および（２）すでにファイル・ツリーの
一部分になっているディレクトリ上に、遠隔ディレクト
リまたはローカル・ディレクトリをマウントすること、
さらに（３）すでにファイル・ツリーの一部分になって
いるファイルの上に（遠隔またはローカル）ファイルを
マウントすることができるという、仮想ファイル・シス
テム・コンセプトの改良である。

仮想ファイル・システムでは、特定の装置ファイル・シ
ステム上で実行される操作が、ノードの集合ファイル・
ツリーの構築および使用に関する操作からはっきり分離
される。ノードの仮想ファイル・システムは、ローカル
・ファイルおよび遠隔ファイルの両方に対するアクセス
を可能にする。

ローカル・ファイルの管理は、遠隔ファイルの管理より
も簡単な問題である。このため、仮想ファイル・システ
ムの考察を２つの部分に分ける。第１の部分では、ロー
カル操作のみについて説明する。この部分は、遠隔操作
を考察するための基礎となる。遠隔操作にもローカル操
作にも同じデータ構造と操作が使われる。ローカル操作
の考察では、データおよび手順のうちスタンドアロン操
作にとって重要な態様について説明する。遠隔操作の考
察では、遠隔操作に関連する情報を付は加えるが、ロー
カル操作の部で考察したことは繰り返さない。

第５図は、仮想ファイル・システムのデータ構造間に存
在する関係を示したものである。各マウント操作で、新
しい仮想ファイル・システム（ｖｆｓ）データ構造が作
成される。この構造中の基本要素は、（ａ）この仮想フ
ァイル・システムのルートＶノード（仮想ノード）を指
すポインタ（たとえば、ブロック２１からブロック２３
への矢印）、および（ｂ）この仮想ファイル・システム
が作成されたときに上にマウントされたＶノードを指す
ポインタ（たとえば、ブロック２５からブロック２４へ
の矢印）である。

ｊノードをファイル・システムとは独立なシステム部分
で表わす必要がある場合、それはＶノードで表わされる
。この構造の基本要素は、次のものである。

ａ）そのＶノードを含む仮想ファイル・システムを指す
ポインタ（たとえば、ブロック２２からブロック２１へ
の矢印）。

ｂ）このＶノードの上にマウントされた仮想ファイル・
システムを指すポインタ（たとえば、ブロック２４から
ブロック２５への矢印）。ただし、すべてのＶノードが
仮想ファイル・システムのマウント点なのではないこと
に留意されたい。すなわち、空白ポインタはこのＶノー
ドがマウント点でないことを示す。

Ｃ）代理ｉノードまたは実ｉノードのどちらかを指すポ
インタ（たとえば、ブロック２６からブロック３２への
矢印）。

ｄ）ノード・テーブル項目を指すポインタ（これはファ
イルが遠隔ファイルであるときだけ空白でない）。

ＡＩＸオペレーティング・システムは、他のＵＮＩＸｔ
ペレーティング・システム操作シく、システムが使用し
ている各１ノードについての情報を含むメモリ常駐テー
ブルを保持する。たとえば、あるファイルをオープンす
るとき、ディスクからそのｉノードが読み取られ、この
ｉノード情報のサブセットが若干の追加情報と共にｉノ
ード・チー′プルに記憶される。ｉノード・テーブル項
目の基本要素は、（ａ）ファイル・アクセス構造リスト
の先頭を指すポインタと、（ｂ）ディスクｉノードから
の情報（その詳細はここでは重要でない）である。

ファイル・アクセス構造は、どのノードでファイルがオ
ープンになっているか、およびそれらのオープンのモー
ド（読取り専用または読取り／書込み）に関する情報を
記録する。ファイルがオープンになっている各ノードご
とに別々のファイル・アクセス構造がある。この状態情
報を使うと、各タライエンドがサーバ・ファイルをどの
ように使っているかをサーバが知ることができる。

ファイル・システムは、その上で実行される１組の操作
をサポートする。次のようにファイル・システム操作を
実行することにより、プロセスがファイル・システムと
対話する。

１、ユーザが（おそらく）いくつかの入力パラメータを
もたらす操作の一つを呼び出す。

２、ファイル・システム論理が、ファイル・システムの
内部データ状態を変更し得る操作を実行する。

３、ファイル・システム論理が、おそらくは若干の戻り
パラメータを戻して、呼出し側ユーザに戻る。

ファイル・システム上で実行できる操作は、＝３３− １“ｖｎ操作“と呼ばれる。いくつかのｖｎ操作がある
が、この考察で重要なものについて下記で説明する。

三ヒお川は戊 ｖｎルックアップ操作では、ファイル・システム内のパ
スをたどる際の基本的反復ステップは、ディレクトリ内
でパス構成要素の名前を探し出し、関連するｉノード番
号を使ってチェーン中の次のファイルを探し出すという
ものである。ｖｎルックアップ操作の擬似コードを下記
に示す。

ルックアップ機能 入カニディレクトリのＶノード・ポインタ、ディレクト
リ中でルックアップすべき名前 出カニ指定されたファイル／ディレクトリを指すＶノー
ド・ポインタ ディレクトリのＶノード・ポインタをｉノード・ポイン
タに変換するニ ーーＶノード中でポインタを使うディレクトリのｉノー
ドをロックする ＩＦ（ディレクトリ中で探索許可をもっていなければ） ディレクトリｉノードをアンロックする；エラーを戻す
； ディレクトリモ名前を探索する； ＩＦ（見つかったなら） 名前に対するファイル・ハンドルを作 成する； ｍ−ディレクトリ・エントリ中で見つかったｉノードを
使う； ファイル・ハンドルに対するＶノードを指すポインタを
得る； ディレクトリｉノードをアンロックする；Ｖノードを指
すポインタを戻す； ＥＬＳＥ−一見つからなかった ディレクトリｉノードをアンロックする；エラーを戻す
； ヱユーｑ且旦ユ ｖｎ　ｏｐｅｎ機能は、どのオープン・モード（読取り
／書込みまたは読取り専用モード）でファイルをオープ
ンするかを記録するファイル・アクセス構造を作成する
（または、既存のファイル・アクセス構造を修正する）
。ｖｎオープン操作の擬似コードを下記に示す。

ｖｎオープン機能 入カニオープンされるファイルに対するＶノード・ポイ
ンタ オープン・フラグ（たとえば、読取り専用または読取り
／書込み） モード作成−一作成する場合はファイル・モード・ビッ
ト 出カニ成功または失敗を示す戻りコードファイルのｉノ
ードを指すポインタをＶノードがら得る： １ノードをロックする； ＩＦ（アクセスを許可されないなら） ｉノードをアンロックする； （エラー）を返す； このタライエンドのためのファイル・アクセス構造を得
る； ｍ−フアイル・アクセス構造がない場合は、一つ割り振
る ＩＦ（ファイル・アクセス構造を割り振ることができな
かったなら） ｉノードをアンロックする； （エラー）を返す； ファイル・アクセス構造読取り専用、読取り／書込み、
およびテキスト・カウントを更新する； ＩＦ（打切りモードがセットされているなら）ファイル
を打ち切る； １ノードをアンロックする； 釦韮翌肚 １ｏｏｋｕｐｐｎ操作とは、パスをたどる機能である。

その入力はパス（たとえば”　／ｄｉｒ　１　／ｄｉｒ
　２　／ｆｉｌｅ“’）で、ｌ、その戻りコードはその
ファイルを表わすＶノードを指すポインタである。

Ｉｏｏｋｕｐｐｎは−っのディレクトリを読み取るため
ｖｎ　Ｉｏｏｋｕｐを呼び出し、次にｖｎ　１ｏｏｋｕ
ｐがら戻されたＶノードがすでに上にマウントされてい
るがどうか検査する。Ｖノードが上にマウントされてい
ない場合、１ｏｏｋｕｐｐｎは同じファイル・システム
中のｖｎ　１ｏｏｋｕρを呼び出す。Ｖノードがすでに
上にマウントされている場合は、１ｏｏｋｕｐｐｎは上
にマウントされたＶノード（たとえば第５図のブロック
２４）からマウントされたファイル・システムの仮想フ
ァイル・システム（たとえば第５図のブロック２５）へ
とポインタをたどる。仮想ファイル・システムから、ル
ートＶノード（たとえば第５図のブロック２６）へとポ
インタをたどり、Ｖノードが単純ファイルではなくディ
レクトリである場合は、その仮想ファイル・システムの
ルートＶノードとパス中の次の要素を構成する名前を入
力として与えて、新しいｖｎ　１ｏｏｋｕｐを発行する
。１ｏｏｋｕｐｐｎ機能の擬似コードを下記に示す。

１ｏｏｋｕｐｐｎ機能 入カニパス名 出カニ指定されたファイルに対するＶノードを指すポイ
ンタ ＩＦ（パスの最初の文字が“／°なら）探索すべき現Ｖ
ノードはユーザのルート・ディレクトリのＶノードであ
る； ＬＳＥ 探索すべき現Ｖノードはユーザの現ディレクトリのＶノ
ードである； 繰り返す ＩＦ（パスの次の要素が“°０．″なら）ＷＨＩＬＥ（
現Ｖノードが仮想ファイル・システムのルートである間
） 現Ｖノードが、仮想ファイル・システ ムが上にマウントされるＶノードと なる； ＩＦ（上にマウントされるＶノードが ない場合） （エラー）を戻す；−−”０．“が ファイル・システムのルートラ通 過した ｖｎ　Ｉｏｏｋｕｐを使って現Ｖノード中のパス構成要
素をルックアップする； Ｉ　Ｆ　（ｖｎ　１ｏｏｋｕｐが構成要素を見つけたな
ら）； 現Ｖノードがｖｎ　１ｏｏｋｕｐから戻されるＶノード
になる； ＷＨＩＬＥ（現Ｖノードが上にマウントする間） マウントされる仮想ファイル・システ ムを表すｖｆｓ構造まで現Ｖノードを たどる； 現Ｖノードがマウントされるｖｆｓのル−トｖノードに
なる； Ｅ　Ｌ　Ｓ　Ｅ　−−ｖｎ　１ｏｏｋｕｐはファイル構
成要素を見つけられなかった （エラー）を戻す；−一探索は失敗したＵＮＴＩＬ（追
加のパス構成要素がなくなるまで）； （現Ｖノード）を戻す； あるファイルへのパスをたどりディレクト１ノをマウン
トするというシナリオを用０て、その操作を説明するこ
とにする。まず、ファイルへのノくスをたどる際に、あ
るアプリケーション・プロセスがファイル”　／　ｕ　
／　ｄｅｐｔ５４　／　５ｔａｔｕｓ″に対するシステ
ム・コール（たとえばオープン）を発行するものと仮定
する。この要求は、第５図に関して下記のような形で、
オペレーティング・システムによって実行される（ＵＮ
　Ｉ　Ｘオペレーティング・システムと基本的に異なら
ない操作については、ここでは詳しくは説明しない）。

次の仮定を設ける。第一に、ブロック２１で表わされる
仮想ファイル・システムがルート仮想ファイル・システ
ムである。第二に、ファイル″／Ｕ″１はＶノード・ブ
ロック２４とｉノード・ブロック３１で表わされる。第
三に、以前のマウント操作で装置のファイル・システム
がディレクトリ“／ｕ′１にマウントされている。この
マウントで、ブロック２５で表わされる仮想ファイル・
システムが作成された。

第四に、関係するすべてのディレクトリとファイルが同
じ装置上にある。第五に、指示されたディレクトリ内に
次に示すディレクトリ項目が存在する。

ディレクトリ ｉノード番号　　　名前　　　ｉノード番号２　　　　
　　”ｕ”　　　　　　　１５４５　　　　°’ｄｅｐ
ｔ５４°“７１７１　　　　　”５ｔａｔｕｓ”　　　
　　　１２システム・コールを実施するコールが、その
パスをたどるために１ｏｏｋｕｐｐｎを呼び出す。　１
ｏｏｋｕｐｐｎはルート仮想ファイル・システム（ブロ
ック２１）のルートＶノード（ブロック２３）からスタ
ートし、このＶノードで表わされるディレクトリ・ファ
イル中で名前７“ｕＩ＋をルックアップするためにｖｎ
−１ｏｏｋｕｐを呼び出す。ｖｎ　１ｏｏｋｕｐはその
ディレクトリ中で、名前“Ｕ“がブロック３１のｉノー
ド１５と関連していることを見つける。ｖｎ　Ｉｏｏｋ
ｕｐはｉノード１５と関連するＶノードを指すポインタ
を戻さなければならない。そのために、まずｉノード１
５をｉノード・テーブルに入れる。次に、すでにこのＶ
ノードの親仮想ファイル・システム内にＶノードがある
（入力Ｖノード（ブロック２３）が親仮想ファイル・シ
ステムを指すポインタを有る）かどうか検査する。この
場合は存在する。ｖｎｌｏｏｋｕｐは次に、ルート仮想
ファイル・システム（ブロック２１）内でそのＶノード
（ブロック２４）を見つけ、Ｖノードを指すポインタを
戻す。

１ｏｏｋｕｐｐｎは、戻されたＶノードが親仮想ファイ
ル・システム内で上にマウントされていることを発見す
る。Ｉｏｏｋｕｐｐｎは、Ｖノード（ブロック２４）か
らマウントされた仮想ファイル・システム（ブロック２
５）へと「上にマウントされた」そのポインタをたどる
。１ｏｏｋｕｐｐｎは、新しい仮想ファイル・システム
（ブロック２５）のルートＶノード（ブロック２６）へ
と「ルートＶノード」ポインタをたどる。次にＩｏｏｋ
ｕｐｐｎは今度はルートＶノード（ブロック２６）を指
すポインタと名前”ｄｅｐｔ５４゛を入力して、再びｖ
ｎ　１ｏｏｋｕｐを呼び出す。前回と同様に、ｖｎ　１
ｏｏｋｕｐはディレクトリを読み取り、その名前と関連
しているｉノードを見つけ、親仮想ファイル・システム
（ブロック２５）内にこのｉノードに対するＶノードを
見つけまたは作成し、このＶノードを指すポインタを戻
す。１ｏｏｋｕｐｐｎは、今見つけたばかりのディレク
トリのＶノードと名前”　５ｔａｔｕｓ　”を入力して
、もう一度ｖｎ　Ｉｏｏｋｕｐを呼び出す。ｖｎ　１ｏ
ｏｋｕｐはディレクトリを読み取り、その名前に関連す
るｉノード（ブロック３４）を見つけ、親仮想ファイル
・システム（ブロック２５）内でこのｉノードに対する
Ｖノード（ブロック２８）を見つけまたは作成し、この
Ｖノードを指すポインタを戻す。システム・コールを実
施したコードは、次にファイル上で要求された操作を実
行する。

次に、アプリケーション・プロセスが、ファイル”　／
　ｕ　／　ｇｒｏｕｐ　”をディレクトリ”　／　ｕ　
／　ｆｏｏ　”の上にマウントするため、「マウント」
システム・コールを発行するものと仮定する。下記のシ
ナリオで、この要求がオペレーティング・システムによ
ってどのように実行されるかを説明する（この場合も、
ＵＮＩＸオペレーティング・システムと基本的に異なら
ない操作は詳しくは説明しない）。

このシナリオでは、第６図と第７図を参照する。

第６図は初期状態を表わし、第７図は最終状態を表わし
たものである。次の仮定を設ける。まず、ブロック４１
て表わされる仮想ファイル・ブロックがルート仮想ファ
イル・ブロックである。第二に、関係するディレクトリ
とファイルは、すべて同一装置上にある。第三に、下記
のディレクトリ項目が指示したディレクトリ内にある。

ディレクトリ ｉノード番号　　名　前　　　ｉノード番号２　　　　
“ｕ”　　　　　　　　１５２　　　　　”ｅｔｃ“８
３ １５　　　　“’ｇｏｒｐ”　　　　　　９２８３　　
　　　”ｆｏｏ”　　　　　　　７５７５　　　　°’
ｆｉｌｅｌ”　　　　　　８９マウント・システム・コ
ールヲ実施スルコードは、次の操作を実行する。上にマ
ウントされるファイル°“／ｅｔｃ／ｆｏｏ’“へのパ
スをたどるため、１ｏｏｋｕｐｐｎを呼び出す。この操
作が完了したとき、ルート仮想ファイル・システム（ブ
ロック４１）は、“／ｅｔｃ／ｆｏｏ’“に対するＶノ
ード（ブロック４４）を含んでいる。このＶノードは、
ルート仮想フアイル・システム（ブロック４１）を指す
ポインタと、ｉノード７５に対するｉノード・テーブル
項目（ブロック４５）を指すポインタを有する。マウン
トされるファイル“’　／　ｅｔｃ　／　ｇｏｒｐ“°
へのパスをたどるため、１ｏｏｋｕｐｐｎを呼び出す。

この操作が完了したとき、ルート仮想ファイル・システ
ム（ブロック４１）は“’　／　ｅｔｃ　／　ｇａｒｐ
　”に対するＶノード（ブロック４９）を含んでいる。

このＶノードは、ルート仮想ファイル・システム（ブロ
ック４１）を指すポインタと、ｉノード９２に対するｉ
ノード・テーブル項目（ブロック４８）を指すポインタ
を有する。ここでマウント論理は、新しい仮想ファイル
・システムを作成する。それには、まず新しい仮想ファ
イル・システム（ブロック４６）を作成し、次に遡って
親仮想ファイル・システム（ブロック４６）を指すポイ
ンタと、ルートｉノード（ｉノード９２、ブロック４８
）を指すポインタとを有する、この仮想ファイル・シス
テムに対するルートＶノード（ブロック４７）を作成す
る。「上にマウントされる」ポインタが、ルート仮想フ
ァイル・システム（ブロック４１）内のカバーされるＶ
ノード（ブロック４４）に挿入され、上にマウントされ
るＶノード（ブロック４４）を指すポインタが新しい仮
想ファイル・システムに挿入される。

Ｅ２．分散ファイル・システムにおける操作以上、スタ
ンドアロン操作用のデータ構造について説明した。次に
第１図には、本発明をサポートするオペレーティング・
システムを実施した第２図のものと同様の分散システム
が示されている。

以下の説明では、ファイルが永久的に記憶されているノ
ードを指すのに「サーバ」という言葉を使い、そのファ
イルにアクセスするプロセスを有する他の任意のノード
を指すのに「クライエント」の語を使うことにする。た
だし、「サーバ」の語は、一部のローカル・エリア・ネ
ットワーク・システムで使われているような専用サーバ
を意味しないことを了解されたい。本発明をその中で実
施する分散サービス・システムは、システム内の様々な
ノードで走行しシステム内のどこにあるファイルにでも
アクセスする、広範なアプリケーションをサポートする
、真の分散システムである。

第１図に示した分散システム用のデータ構造を第８図に
示し、そのデータ構造の構成部分を第９Ａ図ないし第９
Ｆ図に示す。第８図を参照すると、クライエント・ノー
ドは、遠隔サーバ・ノード内にあるファイルにアクセス
することができる。こうしたクライエントは、サーバの
１つのディレクトリをマウントすることによりサーバの
ファイルに対するアクセス権を得る。そのクライエント
・ノードでは、遠隔マウント操作によって作成されるデ
ータ構造が、ローカル・エンティティをマウントするこ
とによって作成されるデータ構造と同等である。ローカ
ルの場合と同じく、遠隔マウント操作で、クライエント
・ノード中に仮想ファイル・システム（ｖｆｓまたとえ
ばブロック５４）が作成される。ローカルの場合と同じ
く、遠隔ファイルを含む仮想ファイル・システム中のフ
ァイルを使用すると、クライエント・ノード中にＶノー
ド構造（たとえばブロック５７）が作成される。

ローカルの場合と同じく、このＶノード構造はｉノード
・テーブル項目（たとえばブロック６３）を指すポイン
タを何する。ただし、このｉノード・テーブル項目は、
遠隔ファイルからのｉノード情報を含まず、その代わり
に代理ｉノードを含む。

この代理ｉノードは、遠隔ｉノードの代理である。

サーバ・ノードでは、遠隔ノードがサーバのファイルを
どのように使用しているかに関する状態情報をサーバが
記録できるように、ある種のデータ構造が構築される。

もっと具体的に言うと、各サーバは、遠隔クライエント
によってオープンになっているファイルを保持するため
の仮想ファイル・システムとして「ダミー仮想ファイル
・システム」（たとえばブロック７１）を有する。ダミ
ー仮想ファイル・シテスムは、サーバのファイル・ツリ
ーの一部ではない。遠隔ノードによってオープンになっ
ている各ファイルに対して、サーバのダミー仮想ファイ
ル・システム中にＶノード（たとえばブロック７４）が
ある。遠隔ノードによってオープンになっている各ファ
イルは、サーバのｉノー−４９＝ ド・テーブル中にｉノード・テーブル項目（たとえばブ
ロック８８）を有する。このｉノード・テーブル項目は
、サーバにあるローカル・プロセスがファイルをオープ
ンしたために存在するテーブル項目と同じである。たと
えば、遠隔オープンのゆえにテーブル中に存在するブロ
ック８４は、サーバでの操作のゆえにテーブル中に存在
するブロック８８と同じ構造である。

あるクライエントとサーバがあるサーバ・ファイルに関
して通信するとき、ファイルを識別する方法が必要とな
る。これは、ファイル・ハンドルによっもたらされる。

クライエントの要求が出て、サーバが特定ファイルの指
定を伴って回答する（たとえば遠隔ルックアップ要求）
とき、そのファイルはファイル・ハンドルで識別される
。クライエントの要求が特定ファイルの指定を含む（た
とえば遠隔オープン要求）とき、そのファイルはファイ
ル・ハンドルで識別される。ファイル・ハンドルは、装
置番号、ｉノード番号、ｉノード世代番号の各フィール
ドを含んでいる。

−５０＝ ファイル・ハンドルの必要性は、次のシナリオかられか
る。次のように仮定する。クライエントがサーバに要求
を出して、回答中でファイル・ハンドルを受は取る。ク
ライエントは、そのファイル・ハンドルを記憶し覚える
。サーバでの何らかの活動によってそのファイルが削除
され、ｉノード・スロットが別のファイル用に再使用さ
れる。

クライエントが記憶しているファイル・ハンドルを使っ
てサーバに要求を出す。サーバはファイル・ハンドルを
受は取り、新しいファイルで操作を実行する。そうなる
と、その操作は許容できないものとなるばすである。

この欠点は、ｉノード世代番号を使うことによっテ防止
される。ｉノード世代番号は、ｉノード中のフィールド
としてディスク上に記憶される。サーバがあるファイル
を削除するとき、そのｉノード世代番号を増分する。要
求がサーバに届いたとき、ファイル・ハンドルは分離さ
れ、装置番号とｉノード番号がｉノードを探し出すのに
使われ、その後ファイル・ハンドルのｉノード世代番号
がｉノードのｉノード世代番号と比較される。両者が異
なる場合、その要求は拒否される。

クライエントが遠隔サーバ上にあるファイルをオープン
したいとき、ネットワーク移送機構を使ってサーバとの
接続を確立する。このファイルに関する以後のトランザ
クション（たとえば、読取り、書込みなど）は、この接
続上を流れる。各ノードはノード・テーブルを含んでい
る。ノードはそのノード・テーブル内の項目（たとえば
ブロック７０）を用いて、遠隔ノードに対する既存の接
続に関する情報を記録する。

ネットワーク内の１つのノードが別のノードに自分のた
めに実行を要求できる操作が少数ある。

こうした操作は、ｄｆｓ操作と呼ばれる。あるノードが
別のノードに要求を出すとき、次の操作が行なわれる。

まず、要求側ノードは、どのｄｆｓ操作を要求している
か指定し、その要求に適したパラメータを運ぶメツセー
ジを送る。次に受取側ノードは要求を受は取って指定さ
れた操作を実行する。

最後に、受取側ノードは、そのｄｆｓ操作に適した回答
パラメータを運ぶメツセージを送る。

ローカル・ノード内でファイル・システムに対して発行
されるｖｎ操作と、ネットワークを介して発行されるｄ
ｆｓ操作の間には、緊密な関係がある遠隔ファイルに対
する典型的な操作は次の通りである。まず、ローカル・
カーネルが、操作中のファイルが遠隔かそれともローカ
ルか知らずに、Ｖｎ操作を発行する。第二に、そのファ
イルが遠隔ノードにあるので、ファイル・システム・イ
ンプリメンテーション・コードが対応するｄｆｓ操作を
、そのファイルを保持するノードに送る。そのファイル
がローカル・ファイルであった場合、操作が実行され、
戻りパラメータが戻され、タスクが完了しているはずで
あることに留意されたい。第三に、そのファイルを保持
するノードがそのｄｆｓ操作要求を受は取り、そのロー
カル・ファイル・システムに対応するｖｎ操作の実行を
要求する。このｖｎ操作からの戻りパラメータを使って
、そのｄｆｓ操作に対する戻りパラメータが構築される
。第四に、要求側ノードがサーバ・ノードからｄｆｓ操
作回答を受は取り、ｄｆｓ操作戻りパラメータを使って
、元のｖｎ操作要求に対する戻りパラメータを構築する
。

ローカル・ファイルの上に遠隔ファイルをマウントし、
ファイルへのパスをたどるというシナリオを用いて、こ
の操作を説明することにする。第一のシナリオでは、ク
ライエント・ノード内のアプリケーション・プロセスが
、ローカル・クライエント・ファイル”　／ｅｔｃ／ｆ
ｏｏ″の上にサーバ・ノードのファイル”／ｕ／ｇｏｒ
ｐ“をマウントするため、「マウント」システム・コー
ルを発行するものとする。この要求がどのように実行さ
れるかは、次のシナリオかられかる。このシナリオでは
第１０図および第１１図を参照する。第１１図は初期状
態を表わし、第１１図は最終状態を表わす。

ブロック５１で表わされる仮想ファイル・システム（ｖ
ｆｓ）がサーバのファイル・ツリーのルート仮想ファイ
ル・システムであり、関係するサーバのディレクトリお
よびファイルはすべて同一装置上にある。指示されたデ
ィレクトリ中には次の項目が存在する。

サーバ・ノード ディレクトリ ｉノード番号　　名　前　　　ｉノード番号２　　　　
　”Ｕ“　　　　　　１５ 工５　　　　”ｇｏｒｐ“　　　　　　９２９２　　　
　”ｆｉｌｅ２”　　　　　　８７クライエント・ノー
ド ディレクトリ ｉノード番号　　名　前　　　ｉノード番号２　　　　
　”’ｅｔｃ−８３ ８３”ｆｏｏ”　　　　　　　７５ マウント・システム・コールを実施するコードが、上に
マウントされるファイル″ｅｔｃ／ｆｏｏ″へのバスを
たどるためにＩｏｏｋｕｐｐｎを呼び出す。この操作が
完了したとき、ルート仮想ファイル・システム（ブロッ
ク５１）は、”ｅｔｃ／ｆｏｏ″に対するＶノード（ブ
ロック５３）を含んでいる。このＶノードは、ルート仮
想ファイル・システム（ブロック５１）を指すポインタ
と、ｉノード７５に対するｉノード・テーブル項目（ブ
ロック６１）を指すポインタををする。マウントされる
ファイルは遠隔ノードにあるため、ｄｆＳマウント要求
が、マウントされる目的物へのバスとしてバス″／　ｕ
　／ｇｏｒｐ　”を通ってサーバ・ノードに発行される
。

ｄｆｓマウント要求を受は取ると、サーバ・ノードは、
マウントされるファイル″／ｕ／ｇｏｒｐ”へのバスを
たどるため、１ｏｏｋｕｐｐｎを呼び出す。このルック
アップ操作が完了したとき、サーバのルート仮想ファイ
ル・システム（ブロック７１）は／υ／ｇｏｒｐ″に対
するＶノードを含んでいる。このＶノードは、ルート仮
想ファイル・システムを指すポインタと、ｉノード９２
に対するｉノード・テーブル項目を指すポインタを有す
る。サーバはｉノード中の情報（装［Ｕｌ　ｔノード９
２）を用いて、ファイル″／ｕ／ｇｏｒｐ″に対するフ
ァイル・ノ＼ンドルを構築する。サーバはｃｌｆｓマウ
ント要求に対する回答中でこのファイル・ノーンドルを
戻し、次にＶノードとｉノードを解除する。最後に、ク
ライエントはｄｆｓマウント要求に対する回答中でこの
ファイル・ハンドルを受は取り、次のような新しい仮想
ファイル・システムを作成するのに必要な操作を実行す
る。

ａ）ｆｆｒＬい［想ファイル・システム（ブロー／　り
５４）を作成する。

ｂ）Ｊｆｌって親仮想ファイル・システム（ブロック５
４）を指すポインタとルートｉノード（ブロック６２）
を指すポインタとを有する、この仮想ファイル・システ
ムに対するルートｖノード（ブロック５５）を作成する
。この仮想ファイル・システムのルートｉノードは遠隔
ファイルであるため、ルートＶノードから指されるｉノ
ードは代理ｉノードである。この代理ｉノードは、クラ
イエントのｄｒｓマウント要求に対してサーバが戻した
ファイル・ハンドルを含んでいる。

ｃ）「上にマウントされる」ポインタを、ルート仮想フ
ァイル・システム（ブロック５１）内のカバーされたＶ
ノード（ブロック５３）に挿入する。

ｄ）上にマウントされるＶノード（ブロック５３）を指
すポインタを新しい仮想ファイル・システム（ブロック
５４）に挿入する。

次に、上記の遠隔マウント（クライエントの／ｅｔｃ／
Ｔｏｏの上にサーバの／υ／ｇｏｒｐをマウントする）
を実行した後、クライエント・プロセスが、ファイル”
　／ｅｔｃ／ｆｏｏ／ｆｉｌｅ　２　”に対して操作す
るためのシステム・コールを発行すると仮定する。

下記のシナリオのブロック番号については第１１図およ
び第１２図を参照されたい。第１１図は初期状態を表わ
し、第１２図はオープン操作後のシステム状態を表わす
。まず、システム・コールを実施するフードが、バスを
たどうるために１ｏｏｋｕｐｐｎを呼び出す。１ｏｏｋ
ｕｐｐｎは、ルート仮想ファイル・システム（ブロック
５１）のルートＶノード（ブロック５２）からスタート
し、このＶノードで表わされるディレクトリ・ファイル
中で名前”Ｕ″′をルックアップするためにｖｎ　１ｏ
ｏｋｕρを呼び出す。

ｖｎ　Ｉｏｏｋｕｐはそのディレクトリ中で、名前″Ｕ
″がｉノード１５と関連していることを見つける。ＶＱ
ｌｏｏｋｕｐは、ｉノード１５に対するルート仮想ファ
イル・システム中にＶノードとｉノードを構築し、この
Ｖノードに対するポインタを１ｏｏｋｕｐｐｎに戻す。

１ｏｏｋｕｐｐｎは、今度はｉノード１５によって識別
されるディレクトリ中で名前“ｆｏｏ”をルックアップ
するために、再度ｖｎ　１ｏｏｋｕｐを呼び出′す。

ｖｎ　１ｏｏｋｕｐは指示されたディレクトリを読取り
、名前“’ｆｏｏ’“がブロック６１中のｉノード７５
と関連していることを発見する。ルート仮想ファイル・
システム（ブロック５１）中には既にこのｉノード（ブ
ロック６１）に対するＶノード（ブロック５３）が存在
し、したがってｖｎ　ＩｏｏｋｕｐはこのＶノードを指
すポインタを戻す。Ｉｏｏｋｕｐｐｎは、そのＶノード
が」二にマウントされていることを発見する（ブロック
５３中の「上にマウントされた」ポインタはブロック５
４を指している）。したがって、１ｏｏｋｕｐｐｎは次
の仮想ファイル・システム（ブロック５４）へと「上に
マウントされた」ポインタをたどり、その仮想ファイル
・システムのルートｖノード（ブロック５５）へとその
ルートＶノード・ポインタをたどる。次にＩｏｏｋｕｐ
ｐｎはパスの次の要素（”ｆｉｌｅ　２　”　）を探す
ためにｖｎ　１ｏｏｋｕｐを呼び出し、ブロック５５を
指すポインタと名前”ｆｉｌｅ２”をｖｎ　１ｏｏｋｕ
ｐに与える。探索すべきディレクトリは遠隔ノードにあ
り、クライエントの代理ｉノード（ブロック６２）に記
憶されているファイル・ハンドルによって識別される。

ｖｎ　１ｏｏｋｕｐはそのファイルを保持するサーバに
ｄｆｓ−１ｏｏｋｕｐを発行し、そのディレクトリを識
別するファイル・ハンドルとルックアップすべき名前（
”ｆｉｌｅ２“′）を送る。サーバがｄｆｓ−１ｏｏｋ
ｕｐを受は取ると、ファイル・ハンドルを使って読み取
るべきディレクトリを識別し、このディレクトリ中で名
前ＩＩ　ｆｉ　ｌｅ　２　ｔｌを探索するためにｙｎｌ
ｏｏｋｕｐを発行する。ｖｎ　１ｏｏｋｕｐはディレク
トリを読み取り、名前”ｆｉｌｅ２“に関連するｉノー
ド番号が６７であることを発見する。ｖｎ　１ｏｏｋｕ
ｐはｉノード６７に対するダミー仮想ファイル・システ
ム中でＶノードとｉノードを構築し、このＶノードを指
すポインタを１ｏｏｋｕｐｐｎに戻す。　ｄｆｓ−１ｏ
ｏｋｕｐはｖｎ　１ｏｏｋｕｐから戻されたデータ構造
中の情報を用いて、ｉノード６７によって識別されるフ
ァイルに対するファイル・ハンドルを構築する。ｄｆｓ
−１ｏｏｋｕｐは、ｄｆｓ−１ｏｏｋｕｐ要求に対する
回答としてこのファイル・ノＡンドルをクライエントに
戻し、Ｖノードとｉノードを解除する。クライエント中
で、見つかったファイルに対するＶノード（ブロック５
５）と代理ｉノード（ブロック６３）が作成される。

”ｆｉｌｅ２”はこのパスの最後の要素なので、１ｏｏ
ｋｕｐｐｎは見つかったＶノード（プロ・ンク５５）を
指すポインタをその呼出し側に戻す。システム・６ｃｘ
ｚコールを実施するコードは、次にそのファイルに対し
て要求された操作を実行する。

Ｅ３．ファイル・アクセスの同期モード本発明が実施さ
れる第１図に示すような分散型サービス・システムでは
、ローカル・キヤ、ソシュ１２Ａ、１２Ｂおよび１２Ｃ
がノードＡ１ＢおよびＣごとに存在する。ファイル５が
ノードＡのディスク２Ａに永久的に存在する場合、サー
バ・ノードＡで実行されるローカル・プロセス１３Ａに
よるキャッシュ１２Ａの使い方は、上述のスタンドアロ
ン・システムの場合と同じである。しかし、ノードＢお
よびＣでそれぞれ実行される遠隔プロセス１３Ｂおよび
１３Ｇは、第３図に示すようにサーバ・キャッシュおよ
びクライエント・キヤ・ソシュを使用する２ステツプ・
キャッシュ方式によってファイル５にアクセスする。サ
ーバ・ノードはディスク２Ａからファイル・ブロック５
を得、それをサーバ・キャッシュ１２Ａに記憶する。ク
ライエント・ノードＢはネットワーク３を介して出て行
き、サーバ・キャッシュ１２Ａからファイル５のブロッ
ク５を得る。クライエント・ノードＢは、ファイル５の
ブロック５を、サーバ・キヤ・ソシュ１２Ａ内に存在し
ていた通りに、クライエント・キャッシュ１２Ｂに記憶
する。クライエント・ノードＢのユーザ・アドレス・ス
ペース１４Ｂがファイル５の任意のブロックからデータ
をシークするとき、各アクセスごとにネットワーク３を
介して出て行く代わりに、クライエント・キヤ、ツシュ
１２Ｂがアクセスされる。クライエント・キャッシュ１
２Ｂを使って遠隔ファイル５にアクセスナると、ネット
ワーク・トラフィックおよびオーバーヘッドを節約でき
るので、処理能力を大幅に向上させることができる。

本発明のシステムおよび方法は、アプリケーション・プ
ログラム・レベルでファイル・アクセス意味論を保持し
ながら高い処理能力を得るように、分散型環境でクライ
エント・キャッシュ１２Ｂおよびサーバ・キャッシュ１
２Ａの使用を管理するものである。これにより、スタン
ドアロン・システムで実行される既存のプログラムが、
何らの変更もなく分散型システムで実行することが可能
になる。ファイル・アクセス意味論は、ファイルにアク
セスしてそれを変更するために読取りおよび書込みシス
テム・コールを発行する様々な処理によってオープンさ
れるとき、ファイルの整合性を保持する。ファイル・ア
クセス意味論は、任意のバイト範囲で一度に一つの入出
力動作のみが許されることを要求し、−底入出力動作が
開始すると、ファイルの同じバイト範囲に対して他の入
出力動作が優先使用を行なうことはできない。

第１３図を参照して上記の例を示す。プロセス１３１が
ファイル５のバイト範囲Ｎ　１−Ｎ２に書込みシステム
・コールを発行した場合、バイト範囲Ｎ１−Ｎ２全体が
プロセス１３１によるアクセスのために使用可能なとき
、その書込みシステム・コールだけが実行でき、バイト
範囲Ｎ１−Ｎ２に関する読取り動作は全く実行されない
。書込みシステム・コールの実行中、ファイル５のバイ
ト範囲Ｎ１−Ｎ２に関する他のすべての動作は、書込み
が終了するまで延期される。バイトがローカル・キャッ
シュ１２Ａに書き込まれるまで、書込みは終了しない。

書込み要求が終了すると、キヤ、ツシュ１２Ａに書き込
まれたデータは、他のプロセス１３１ないし１３Ｎのい
ずれかによる後続の読取り動作に見えるようになる。

ファイル・アクセス意味論のもう一つの要件は、Ｎ１−
Ｎ２等のファイル・バイト範囲（同じ入出力動作によっ
てアクセスされるレコードまたは一組の関連レコードで
よい）が読取りプロセスから見えるとき、ファイル・バ
イト範囲Ｎ１−Ｎ２は常に、この範囲に対する最後の更
新を反映する一貫した一組のデータを含まなければなら
ないということである。この範囲は、書込み動作が実行
されている間、アクセスのために使用することができな
い。このようにして、プロセスによって発行される次の
読取りは書き込まれたばかりのデータを読み取り、古い
陳腐化したデータを読み取ることはない。

第１図に示す本発明の分散型ネットワーク環境では、異
なるアプリケーション・プログラム４Ａおよび４Ｂ、プ
ロセス１３１ないし１３Ｎおよび２３１ないし２３Ｎか
らの読取りおよび書込みシステム・コールの実行が、前
述のファイル・アクセス意味論が保持されるように同期
される。本発明のシステムおよび方法では、種々のキャ
ッシュ同期モードを用いて同期を保証する。特定のファ
イル５に対して、入出力コールは、アクセスのためにフ
ァイル５をオープンするプロセス１３１ないし１３Ｎま
たは２３１ないし２３Ｎの位置および同期モードに応じ
て、クライエント１３またはサーバＡによって同期され
る。

３種類の同期モードを第１４図に示し、第１図と関連し
て説明する。最初のモード１０４は非同期モードと呼ば
れる。第１４図のブロック１０７に示すように、ただ一
つのクライエント遠隔ノードＣで実行されるプロセス１
３Ｃによる読取り／書込みアクセスのためにファイル５
がオープンされる場合、ファイル５はこのモード１０４
で動作する。このモード１０４では、制御権はすべてク
ライエント・ノードＣにある。サーバ・キャッシュ１２
Ａおよびクライエント・キャッシュ１２Ｃがこれらの読
取り／書込み動作のため使用される。

読取りまたは書込み動作では、クライエント・キャッシ
ュ１２Ｃから満足され得ない場合のみ、サーバ・キャッ
シュ１２Ａに対するアクセスが必要となる。ファイル５
がクライエント・ノードＣのすべてのプロセス１３Ｇに
よってクローズされるとき、または、クライエント・ノ
ードＣで他のデータにもっと場所が必要とされるとき、
クライエント１２Ｃにある修正されたブロックが周期的
−６６＝ 同期動作によりサーバ１２Ａに書き込まれる。また、フ
ァイルが非同期モードから全同期モードに変わるとき、
修正されたブロックがサーバに書き込まれる。

第二のモード１０５は読取専用モードである。

読取専用モード１０５は、第１４図のブロック１０８に
示すように、ただ一つのノードＣ内のプロセス１３Ｃか
らの、または複数のノードＢおよびＣ内のプロセス１３
Ｂおよび１３Ｇからの読取り専用アクセスのためにオー
プンされるファイル５に使用される。このモード１０５
では、サーバ・キャッシュ１２Ａおよびクライエント・
キャッシュ１２Ｂまたは１２Ｃあるいはその両方が使用
される。読取り要求は一度に１ブロツクまたは複数のブ
ロックに対して発行される。同じクライエントＢまたは
Ｃからの特定のブロックに対する１回おきの読取り要求
はサーバ１２に行かず、その代わりに、当該のクライエ
ント・キャッシュＢまたはＣから読み取られる。言い換
えると、読取り動作では、クライエント・キャッシュ１
２Ｃまたは１２Ｂから満足される場合、サーバ１２Ａに
対するアクセスが必要でない。要するに、ノードＡ１Ｂ
またはＣのいずれかにおけるプロセス１３Ａ１１３Ｂま
たは１３Ｃのいずれかによる読取り専用アクセスのため
にファイル５がオープンされる場合は、ファイル５はモ
ード１０５で動作する。

第三のモード１０６は全同期モードである。全同期モー
ド１０６は複数のファイルＡ、Ｂでオープンされている
ファイル５のため使用され、少なくとも１つのノードが
書込みアクセスのためにファイルをオープンしている。

全同期モード１０Ｂでは、クライエント・キャッシュ１
２Ｃまたは１２Ｂは迂回され、サーバ・キャッシュ１２
Ａのみが使用される。読取りおよび書込み動作はすべて
サーバ１２Ａで実行される。

第１図に示す分散型環境１では、大部分のファイル５は
、第１４図に示す読取専用モード１０５である複数のノ
ードＡ１ＢおよびＣにおけるプロセス１３Ａ、１３Ｂお
よび１３Ｃによる読取りのみのためにオープンされたり
、非同期モード１０４にあるただ一つのノードでの更新
のためにオープンされる場合が多く、全同期モードにあ
る複数ノードで実行されるプロセスによる読取りおよび
書込みアクセスのためにオープンされることはそれほど
頻繁ではない。第１３図に示すように、読取専用モード
１０５および非同期モード１０４でクライエント・キャ
ッシュ１２Ｂを使用するため、ファイル５にアクセスす
る遠隔読取り／書込み応答時間が大幅に減少し、システ
ムの全体的処理能力が向上する。

第１５図に示すように、全同期モードでは、クライエン
ト・キャッシュは使用されない。クライエント・ノード
Ｂは、各読取りおよび書込み動作ごとにネットワーク３
を介してサーバＡからのファイル５にアクセスする。こ
のモードでは読取り／書込み応答時間は増加するが、ク
ライエントは、ローカル・キャッシュ中に、サーバに存
在している対応するファイルと共に更新されなかったフ
ァイル５を保持しないので、ファイル・アクセス意味論
は保持される。

３種類のモードを使用してクライエント・キヤ・ソシュ
の使用を管理すると、読取り／書込み応答速度が全体と
して平均的に増加することとファイルの整合性が組み合
わされて、システムの全体的処理能力が最適になる。あ
る場合にはクライエント・キャッシュの使用で読取り／
書込み応答時間が減少し、別の場合にはクライエント・
キヤ・ソシュを使用しないことでファイル・システムの
意味論が保持される。

ファイルの同期モードは、どのノードがファイルをオー
プンするか、およびファイルが読取りのためにオープン
されるのかそれとも書込みのためにオープンされるのか
だけでなく、ファイルが存在する装置が生アクセス・モ
ードでオープンされるかどうかによっても決まる。装置
に対する生アクセスとは、装置２Ａ内の第１３図に示す
データ・ブロックＬＢＮ１がアクセスされるという意味
である。したがって、装置２Ａの読取りおよび書込みは
、装置２ＡのブロックＬＢＮ１に対する読取りおよび書
込みとなる。ブロックがどのファイルに属するかは関係
ない。サーバ・ノードＡにある処理１３１ないし１３Ｎ
からの生アクセスのために装置２Ａをオープンすること
ができる。遠隔ノードＢまたはＣからの生アクセスのた
めに装置２Ａをオープンすることはできない。

第１３図では、第３図に関連して上述したスタンドアロ
ン・システムと同様に、キャッジユニ２Ａは装置２人の
ブロックＬＢＮＩとして管理される。サーバＡは、サー
バ・キャッシュ１２Ａを装置２Ａ内の論理ブロックＬＢ
ＮＩとして見る。クライエントＢは、ファイル５が装置
２Ａのどこにあるか、全く知らない。クライエントＢが
知っていることは、装置２Ａ上のブロック番号Ｎ１にあ
るファイルにアクセスしていることだけである。

クライエント・キャッシュ１２Ｂは、データをファイル
５の論理ブロックＮ１として処理する。サーバ・キャッ
シュ１２Ａでは、データは装置２Ａの論理ブロックＬＢ
Ｎ１として処理される。データをこのように処理する際
、データが主装置としての装置に書き込まれる場合、お
よび、装置に書き込まれたブロックと同じファイルのブ
ロックが次に読み取られる場合、この読取りで新たに書
き込まれたデータが見えることをサーバは保証すること
ができる。このため、ファイル・システムの意味論が保
持される。

第１３図に示すように、ファイルがクライエント・ノー
ドＢでアクセスされ、ファイルが非同期モードまたは読
取専用モードにある場合、クライエント・オペレーティ
ング・システム１１Ｂは読取りシステム・コール１６に
おけるファイル内のファイル記述子およびバイト範囲（
ファイル記述子、Ｎ１）を装置番号および装置内の論理
ブロック番号に変換しない。クライエントは、ファイル
記述子およびバイト範囲をファイル・ハンドル、ノード
識別子、およびファイル内の論理ブロック番号に変換す
る。クライエント・キャッシュ１２Ｂでは、ファイル・
ハンドル、ノード識別子、およびファイル内の論理ブロ
ック番号によって指定されるブロック１７がある。クラ
イエント・アプリケーション４Ｂから読取りコール１６
が発行されると、読取り要求が、ファイル内のファイル
記述子およびバイト範囲と共にオペレーティング・シス
テムに送られる。オペレーティング・システムは次にク
ライエント・キャッシュ１２Ｂを調べる。ファイル・ハ
ンドル、ノード識別子、およびファイル内の論理ブロッ
ク番号がそこにある場合は、キャッシュ１２Ｂを読み取
り、そこにない場合は、その読取り要求がサーバに送ら
れる。サーバはそこでファイル・ハンドルおよびファイ
ル内の論理ブロック番号を取り出し、それを装置番号お
よび装置内の論理ブロック番号に変換する。この変換が
必要なのは、サーバ・キャッシュ１２Ａは、スタンドア
ロン・システムの場合と同様に、装置番号および装置内
のブロック番号によって管理されるためである。読取り
要求はサーバに送られた後、第３図と関連して説明した
スタンドアロン・システム内でそれ自体のアプリケーシ
ョンからきた場合上同様に処理される。

クローズされたファイルは同期モードを持たない。しか
し、一度フアイルがまずプロセスによっ−７３〜 てオープンされると、ファイルの同期モードは、第１６
図に示すように、以下に従って初期設定される。ファイ
ルが存在する装置がクローズされている（１１２）、す
なわち、特別な装置としてオープンされていす、かつフ
ァイルが１つの遠隔ノードでの書込みアクセスのために
オープンされている（１１３）場合は、ファイルの同期
モードは非同期１０４に初期設定される。ファイルが存
在する装置がクローズされており、かつファイルが一つ
または複数のノードでの読取り専用アクセスのためにオ
ープンされている（１１４）か、または、装置およびフ
ァイルの両方が読取専用アクセスのためにオープンされ
ている（１１５）場合は、ファイルの同期モードは読取
専用モード１０５である。

ファイルが存在する装置が読取り／書込みアクセスのた
めにブロック特別装置としてオープンされており（１１
ｆ３）、または、ファイルが複数のノードでオープンさ
れ、オープンの少な（とも１つは書込みのためである場
合は、ファイルの同期モードは全同期モード１０６に初
期設定される。ブロッり特別装置とは、装置に対して生
アクセスがあるという意味である。

一度フアイルがあるモードに初期設定されると、状態が
変化した場合、ファイル・モードが変わることがある。

第１６図の線１１８ないし１２３に示すように、あるモ
ードから別のモードへの移行は以下の条件下で行なわれ
る。ファイルが現在非同期モード１０４にあり、ファイ
ルがオープンされているノードの数が２以上になる場合
（１２４）、同期モードは、線１１９で示すように、全
同期１０６に変わる。さらに、ファイルが存在するブロ
ック特別装置りがオープンされている場合（１２５）、
同期モードは非同期モード１０４がら全同期モード１０
６に変わる。ファイルに対するクローズ動作では、その
クローズ動作がファイルの最後のクローズでなくして、
ファイルが書込みのため依然としてオープンされている
場合、モードの変化はない。しかし、クローズ動作が書
込みアクセスに対するファイルの最後のクローズであり
、残りのすべてのオープンが読取りアクセスのためであ
る場合（８３）は、新しいモードは、線１２１で示すよ
うに読取専用モード１０５になる。

クローズ動作がファイルの最後のクローズである場合、
同期モードはない。

ファイルが現在読取専用同期モード１０５にあり、ファ
イル・オープン動作が行なわれる場合、そのオープンが
読取りのためであれば、モードの変化はない。しかし、
そのオープンが書込みのためである場合は、線１２０で
示すように、すべてのオープンが一つのクライエント・
ノードにある（１２７）なら、新しい同期モードは非同
期モード１０４である。さもなければ、同期モードは全
同期モードである。さらに、ファイルが存在する装置が
読取り／書込みアクセスのためにオープンである場合（
１３０）、そのファイルに対する新しい同期モードは全
同期モードエ０６である。クローズ動作については、そ
のクローズがファイルの最後のクローズである場合、そ
のファイルに同期モードはない。クローズ動作後に、１
つまたは複数のノードでファイルが依然としてオープン
されている場合、同期モードは変わらない。

ファイルが現在全同期モード１０６にあり、そのファイ
ルに対して別のオープンがある場合、またはファイルが
存在する装置がオープンされる場合は、同期モードの変
更はない。ファイルのクローズ動作後、読取り／書込み
アクセスのためのオープンが遠隔ノードに残っており、
ファイルが存在するブロック特別装置がオープンされて
いない場合、線１１８を介してブロック１４１に示すよ
うに、同期モードは非同期モード１０４に変わる。

ファイルが存在するブロック特別装置がオープンされて
おらず、線１２２を介してブロック１４２で示すように
、ファイルが１つまたは複数のノードで読取り専用アク
セスのためにオープンされる場合、または、ファイルが
存在するブロック特別装置が読取り専用アクセスのため
にオープンされ、線１２２を介してブロック１４３で示
すように、ファイルが読取り専用アクセスのためにオー
プンされる場合は、同期モードは全同期モード１０６か
ら読取専用モード１０５に変わる。

７フー ファイルに対するすべてのオープンおよびクローズ動作
はサーバ・ノードで解決される。サーバは、モードを変
更する可能性がある動作を実行するとき、オープンの同
期モードを判定する。サーバはまた、同期モードの変更
を行なう。サーバがファイルに対する新しいオープンま
たはクローズを受は取るとき、ファイルに対する同期モ
ードの変更がトリガされることがある。必要とされる同
期モードが現在の同期モードでない場合、サーバは、フ
ァイルがオープンされているすべてのクライエントに「
同期モード変更」遠隔手順コールを送る。ファイルが初
めてオープンされた後で、そのファイルをオープンした
クライエントにファイルのモードが知らされる。モード
が非同期モードまたは読取専用モードのどちらかである
場合、クライエントは読取り用のクライエント・キャッ
シュを使って開始することができ、さらに、第１３図に
示すように、モードが非同期モードの場合は、書込み用
のクライエント・キャッシュをも使って開始することが
できる。クライエントが通信リンクを介してサーバに対
して読取りまたは書込みを行なう必要はない。第１５図
に示すようにモードが全同期モードである場合は、クラ
イエント・キャッシュは使用されず、クライエントは通
信リンク３を一介して読取りまたは書込みをサーバに送
らねばならない。

第１５図でサーバＡは常にファイル５のモード１５１を
セットする。ファイルのモードは、ファイルをオープン
したすべてのノードで同じである。

サーバＡはまた、どのノードがファイルをオープンした
か、およびそれらのオープンが読取りのためかそれとも
書込みのためかを知っている。サーバＡは、ノード内の
どの処理１３１ないし１３Ｎ１２３１ないし２３Ｎがフ
ァイルをオープンしたかを知っている必要はない。第１
５図に示すように、サーバは上記情報をすべてファイル
・アクセス構造リスト１５０に保持する。ファイル・ア
クセス構造リスト１５０の各要素は、ファイルをオープ
ンしたノード１５２、そのノードでの読取りのためのオ
ープンの数１５３、およびノードでの書込みのためのオ
ープンの数１５４を含んでいる。

Ｅ４．ロッキング ＵＮＩＸファイル・ロッキング ＵＮＩＸオペレーティング・システムでは、処理がファ
イル内のバイト範囲をロックして、他の処理がその範囲
にアクセスできないようにすることができる。ロックは
ファイルのバイト範囲に適用される。ファイルの全域に
渡るロックはファイルをロックし、ファイル・ロックと
呼ぶことができる。任意のバイト範囲に渡るロックは、
レコード・ロックと呼ばれることがある。ただし、この
開示では、レコード・ロックおよびファイル・ロックを
単にロックと呼ぶことにする。

このシステムでは２種類のロックがサポートされる。す
なわち、書込みロックおよび読取りロックである。書込
みロックは排他的ロックである。

ファイルのある範囲が書込みロックされた場合、他のロ
ックがその範囲に存在することはできない。

もう一つの種類のロック、すなわち、読取りロックは共
用ロックである。オーバーラツプする任意の数の読取り
ロックをファイルのあるセグメントに適用することがで
きる。既存の読取りロックは他の読取りロックを妨げな
いが、他の書込みロックを妨げることに留意されたい。

既存の書込みロックは特定の範囲に対する他のすべての
ロックを妨げる。書込みロックは、書込みアクセスでオ
ープンされたファイル記述子だけに適用できる。

ファイルは強制モードにあるか、または強制モードにな
いかのいずれかである。強制モードにないファイルに対
するロックは勧告ロックと呼ばれる。

勧告ロックはファイルまたはレコードに対する絶対的保
護をもたらさない。しかし、勧告ロックは、処理がロッ
クされたファイルまたはレコードの読取りまたは書込み
を行なうのを妨げる。勧告ロックは１ｏｃｋｆ　（２）
またはｆｃｎｔｌ　（２）に対するコールの結果に影響
を及ぼすだけである。１ｏｃｋｆ　（２）またはｆｃｎ
ｔｌ　（２）を使って、勧告ロックを使わなければらな
いのは、協働して勧告ロックがアクセスしている共用フ
ァイルに対するロックの状況を照会中のプロセスである
。勧告ロックの利点は、それらが読取りまたは書込み動
作中にオペレーティング・システムのカーネルから問い
合わせる必要がないということである。強制ロックは、
勧告ロックと同様に、１ｏｃｋｆ　（２）およびｆｃｎ
ｔｌ　（２）に対する後続のコールに影響を及１ボす。

さらにＮ　ｒｅａｄ（２）　）ｗｒｉｔｅ　（２）　１
ｏｐｅｎ　（２）　）ｃｒｅａｔ　（２）　Ｎｆｃｌｅ
ａｒ　（２）　、ｆｔｒｕｎｃａｔｅ　（２）　、およ
びｓｈｍａｔ　（２）は、それぞれ、ファイルの読取り
ロックまたは書込みロックされた部分が変更されないこ
と、およびファイルの書込みロックされた部分がアクセ
スされないことを保証しなければならない。

ｆｃｎｔｌ　（２）システム・コールの異なる３つのＵ
ＮＩＸオペレゎ−ティング・システム・コマンドがロッ
キングに関係する。

Ｆ−ＧＥＴＬＫ　　ｆｃｎｔｌ（２）の引数によって記
述されるロックが呼出し側に許可されるのを妨げる最初
の既存のロックを見つける。

Ｆ−８ＥＴＬＫ　　ｆｃｎｔｌ　（２）の引数によって
記述されるロックを呼出し側に許可する。既存のロック
が要求とインターフェースするので、ロックを許可でき
ない場合は、この既存のロックの記述を戻す。

Ｆ−８ＥＴＬＫＷ　　ｆｃｎｔｌ　（２）の引数によっ
て記述されるロックを呼出し側に許可する。既存のロッ
クが要求とインターフェースするので、ロックを許可で
きない場合は、デッドロックの有無を検査し、デッドロ
ックが生じない場合は、呼出し側を待たせる。妨害ロッ
クがクリアされる度に、カーネルは、再度妨害ロックの
有無を探索することにより、要求されたロックを確立し
ようと試みる。プロセスはいつまでも待つことができる
。単一ノード上でのファイル・ロックのみに関するデッ
ドロックが検出されるが、複数ノード上での複数ファイ
ル・ロックによるデッドロックが発生し得る。プロセス
は決してデッドロックにはならないが、交互にセットさ
れる種々のファイルに対する妨害ロックのためにライブ
・ロック（ｌ　１ｖｅ−１ｏｃｋ　）になる可能性はあ
る。

ロック・テーブル ロックはオープン・ファイルと関連するので、ロック情
報をオープン・ファイルに関する情報と一緒にファイル
のｉノード構造に保持するのが自然である。ｉノード構
造はＵＮＩＸオペレーティング・システムでは固定サイ
ズなので、ｉノードにはロック構造が存在するアドレス
だけを入れて、ロック情報は別の構造に記憶されねばな
らなかった。ロックは、ロック・テーブルと呼ばれるカ
ーネル・データ構造からの一組の項目として、連係され
たリストに保持される。

ＵＮＩＸオペレーティング・システムは、分散型ファイ
ル・システムに対するサポートを提供しなかった。分散
型システムでは、数個のノードが同じファイルを使用す
ることがあり得る。あるファイルに対するロック・テー
ブルは常に単一ノードにある。ファイルが非同期モード
にある場合、ロック・テーブルは（活動ノード情報と共
に）、ファイルがオープンされている単一ノードに保持
される。ファイルが読取専用モードまたは全同期モード
にある場合、ロック・テーブルはサーバに保持される。

このアーキテクチャには２つの重要な意味がある。第一
に、プロセスが遠隔手順コール（ＲＰＣ）を使ってロッ
クをセットまたはテストしなければならないことがある
。これらのＲＰＣはファイルのサーバで実行される。第
二に、ファイルの同期モードが変わるとき、ファイルの
ロック・テーブルをクライエントからサーバに、または
サーバからクライエントに移さなければならないことが
ある。ｉノード・ロック・テーブルの項目は、ｉノード
・ファイルのセグメントに対するロックに対応する。ロ
ックを表わすには、ロック・セット項目が、ロックされ
るバイトの範囲、ロックの種類（読取りまたは書込み）
、ロックの所有者を識別する情報を含まなければならな
い。

プロセスが項目のロックを待っているかどうかを示すフ
ラグをロック項目に記憶することにより、カーネル・デ
ータ構造の幾つかの探索が不要になる。このフラグは、
ロック・セット項目の実際のインプリメンテーションに
含まれる情報のもう１８５一 つの部分である。最後に、ロック・セット項目は多分、
同じファイルに属する項目を互いにリンクするために使
用されるポインタ・フィールドを含んでいる。ロック・
セットの要素を処理するための以下の動作を詳細に調べ
ることにより、インプリメンテーションの詳細について
考察する。

１）特定のｉノードと関連するロック・セット中のロッ
クを繰り返す方法。

２）あるｉノードに対するロック・セットにロックを追
加する機能。

３）あるｉノードに対するロック・セットからロックを
除去する機能。

ロック・テーブルの項目は、ロックを、ロックされる最
小のバイト範囲とそのロックに対する所有者情報で表わ
す。ロックの以下の属性を戻す動作が必要である。　　
　　′ １）ロックされるセグメントの範囲　２）ロックの種類
（読取り、書込みまたは一時的）　３）ロック所有者 所有者があるロックと関連しているとき問題が８６一 生じる。ロックの所有者は、所有者のｐｒｏｃテーブル
を指すポインタによって識別される。ｐｒｏｃテーブル
とは、システム内の各活動プロセスに関する管理情報の
集合である。ｐｒｏｃテーブルに対するデータ構造ソー
ス・コードを、各フィールドの目的を説明する情報と共
に下に示す。

５ＴＲＩＩＣＴ　　ＰＲＯＣ（ ＳＴＲＵＣＴ　ＳＥＧ　ＬＩＳＴ　　　セグメントＩＤ
Ｐ　５ＥＧＳ； ＩＮＴ　　　Ｐ　ＦＬＡＧ；　　　　テスト用フラッグ
ＣＩＩＡＲＰ　５ＴＡＴ；　　　　プロセスの状況ＣＨ
ＡＲＰ　ＰＲＩ；　　　　優先順位、ネガティブ・ハイ ＣＨＡＲＰ　　ＴＩＭＥ；　　　　　　　常駐■寺間ス
ケジュールＣ１（ＡＲＰ　ＣＰ口：ＣＰ■使用法 ＣＩＩＡＲＰ　　ＮＩＣＥ； ＵＳＩＩＯＲＴ　Ｐ　ＵＩＤｉ　　　　　実ユーザＩＤ
ＵＳＩＩＯＲＴ　Ｐ　５ＵＩＤ：　　　　実効ユーザＩ
Ｄ５ＨＯＲＴ　　　Ｐ　　ＰＧＲＰｉ　　　　　　　プ
ロセス・グループ・リーグ５ＨＯＲＴ　　Ｐ　ＰＩＩ）
；　　　　固有プロセスＩＤ５ＨＯＲＴ　　　Ｐ　　Ｐ
ＰＩＤ；　　　　　　　ペアレントのプロセスＩＤＬＯ
ＮＧ　　Ｐ　ＡＤＤＲ；　　　　処理アドレス５ＩＩＯ
ＲＴ　　Ｐ　５ＩＺＥ；　　　　イメージのサイズ５Ｔ
ＲＵＣＴ　ＵＳＥＲ”Ｐ　ＵＰＴＲｉ　　このプロセス
に；対するＵブロック ；の位置 ＣＨＡＲＰ　ＣＵＲＳＩＧｉ ＩＮＴ　　　Ｐ　５ＩＧｉ　　　　保留信号ＩＨＴ　　
　Ｐ　ＳＩＧＭＡＳＫｉ　　信号マスクＩＮＴ　　　Ｐ
　５ＩＧＩＧＨＯＲＥ；無視される信号ＩＮＴ　　　Ｐ
　５ＩＧＣＡＴＣＨ；　　捕捉すべき信号ＩＮＴ　　　
　　Ｐ　　５ＩＧＡＣＴＩＯＨｉ　　１＝ベル・スタイ
ル；　　０＝４．２　　スタイル Ｕｎｉｏｎ　　（ ＣＡＤＤＲＴ　Ｐ　ＣＡＤ； ＩＮＴ　Ｐ　ＩＨＴ； ）　Ｐ−■ＮＷ； ＃ＤＥＦＩＨＥ　　Ｐ　　Ｗ　　ＣＨＡＮ　　Ｐ−ロＮ
υ、Ｐ　　ＣＡＤ；　　プロセスが待ってい；　るロッ
ク・テーブルを指 ；すポインタ ｕＤＥＦＩＮＥ　　Ｐ　　ＡＲＧ　　　　Ｐ　　ＵＮＷ
、Ｐ　　ＩＨＴ；５ＴＲＵＣＴ　ＴＥＸＴ　”Ｐ　ＴＥ
ＸＴＰ；　テキスト構造を；指すポインタ ５ＴＲＵＣＴ　ＰＲＯＣ＊Ｐ　ＬＩＮＫ　；　　実行中
のプロセスの；連係リスト ＩＮＴ　　　　Ｐ　ＣＬＫＴＩＭ；　　警報クロック信
号ＩＮＴ　　　　Ｐ　ＳＭＢＥＧ；　　　共有メモリの
始まりＩ）ＩＴ　　　　Ｐ　ＳＭＥＨＩ）；　　　共有
メモリの終わりＣＡＤＤＲＴ　　　Ｐ　　ＦＲＥＱｉ　
　　　　空白またはレグセットＬＯＮＧ　　　Ｐ　ＰＦ
ＬＴ；　　　ページ不在の数ＩＮＴ　　　　　　　Ｐ　
　ＥＰＩＤｉ　　　　　ロッキングＩＤプロセスＩＮＴ
　　　　　　　Ｐ　　５ＹＳＩＤ；　　　　リモート・
ブｌ１２ｔスのＨＩＤ構造の終わり デッドロックの検出には各ロックの所有者用のｐｒｏｃ
テーブルにアクセスする必要があるので、ｐｒｏｃテー
ブルはロック要素の所有者を識別するための有用な方法
である。分散型システムでは、所有者はローカル・プロ
セスではないかも知れない。

所有者が遠隔プロセスである場合、所有者情報には、所
有者が存在するノードに対するノードｉｄを含める必要
がある。必要とされる情報は以下の通りである。

１）所有者のｐｒｏｃテーブルのアドレスを戻す動作。

−２）２人の所有者を比較し、これらの所有者が同じプ
ロセスである場合はＴＲＵＥを戻し、さもない場合はＦ
ＡＬＳＥを戻す動作。

３）所有者のノードｉｄを戻す動作。これらの動作は構
造内のフィールド参照を使って、指示された動作を実行
する。

ロック待ち スタンドアロン・オペレーティング・システムでは、ロ
ックを確立しようと試みるプロセスは、まず既存のロッ
クがクリアされるのを待たなければならないことがある
。待つ（休眠する）前に、そのプロセスはシステムのす
べてのｉノードのロック・セットを調べて、待っても、
デッドロックが生じないことを確かめねばならない。待
機しているプロセスのｐｒｏｃテーブルが、ｐｒｏｃテ
ーブルのＷＣＨＡＮフィールドを使って、待っているロ
ック・テーブル項目を指す。

ＤＦＳでは、待つことは容易ではない。ブロッキング・
ロックを待つための２つの方法がある。

すなわち、１）ローカル・ロック・セット項目を直接待
つ方法と、２）サーバ・ロック・セット項目を間接に待
つ方法である。直接待機は上述のスタンドアロン待機と
同じである。直接待機は、ロック・テーブル内で局所的
に生じるロックをプロセスが待たねばならないときに使
用される。あるファイルに対するロック・テーブルは１
つのノードのみに存在することを思い起こされない。呼
出し側プロセスが同じノードにない場合、ロック・テー
ブルはサーバ内にある。ロック・テーブルが遠隔ノード
（サーバ）内にあるファイルのある領域をロックしよう
と試みるプロセスは、ロックを間接的に待つ。この間接
待機は、サーバ内のＲＰＣがトランザクション・プログ
ラムを呼び出し、ロックを待つことによって行なわれる
。スタンドアロ７ＵＮＩＸオペレーテイング・システム
では、ロックが許可されることが可能な場合、または、
待機がデッドロックを生じる可能性がある場合、プロセ
スは決して休眠状態に入らない。分散型システムでは、
ロック・テーブルと同じノードに存在しないロック要求
を実行するプロセスは常に（少なくとも一時的に）休眠
状態に入る。そのプロセスは、ＲＰＣが戻るのを待って
いる間、そうしなければならない。不必要なネットワー
ク通信を避けるために、ロックＲＰＣを待つプロセスは
、ＲＰＣトランザクション・プログラムがブロッキング
・ロックを待っているので待つのか、それともブロッキ
ング・ロックが発見されなかったサーバでトランザクシ
ョン・プログラムが実行を終了していないので待つのか
を知らない。分散型システムでは、デッドロックは数ノ
ードにわたる可能性がある。

したがって、スタンドアロン環境と疑似のアーキテクチ
ャを使って、デッドロックがない場合にのみプロセスが
待つようにすることは、そのオーバーヘッドおよび検査
を行なわねばならないことのために、実用的ではない。

本発明は、スタンドアロン・デッドロック防止の分散型
バージョンに付随するオーバーヘッドおよび複雑性を伴
わずにそのような能力を提供するための方法である。

デッドロック 連鎖状のプロセスが実行され、それらのプロセスが、既
に使用中の資源を求めて競合するとき、デッドロックが
生じる。たとえば、プロセス２が支配する資源をプロセ
ス１が待ち、プロセス３が支配する資源をプロセス２が
待ち、以下同様に、プロセス１が支配する資源を最後の
プロセスが待つ場合である。スタンドアロ７ＵＮＩＸオ
ペレーテイング・システムは、ファイルおよびレコード
のロッキングを伴うデッドロックが発生するのを防ぐ。

従来は１．ＵＮＩＸオペレーティング・システムは分散
型システムをサポートせず、そのようなデッドロックの
発生を防ぐことができなかった。

防止したいデッドロックを形成する循環連鎖状プロセス
は２種類のリンクによってリンクされる。

すなわち、１）プロセスｐｒｏテーブルのプロセスｗ　
ｃｈａｎフィールドを介してロックを指すプロセスと、
２）ロックの所有者フィールドを介してプロセスを指す
ロックである。これらのリンクをたどることにより、循
環の有無の探索を実行して、デッドロックが発生するか
どうか判定することができる。ＵＮＩＸオペレーティン
グ・システムは１つのこと（単−ｗｃｈａｎ）を待つこ
とができるだけであり、ロックは１つのプロセスのみが
所有するので、連鎖の探索は難しくない。唯一の厄介な
点は間接待機の可能性である。別のノードに送られたＲ
ＰＣからの応答をプロセスが待つとき、間接待機が生じ
る。間接待機を処理するには、ＲＰＣを実行する前にタ
イマーをセットして、デッドロックが生じた場合に警報
アプリケーションが必要とされる。

分散型ファイル・サポート・ロック制御ＵＮＩＸオペレ
ーティング・システム環境におケルファイル・アクセス
・コールは、ＦＬＯＣＫと呼ばれるデータ構造を使用す
る。ＦＬＯＣＫの構造を下に示す。

５ＴＲＵＣＴ　ＦＬＯＣＫ　（ ＳＨＯＲＴ　　Ｌ　ＴＹＰＥｉ ＳＨＯＲＴ　　Ｌ　ＷＨＥＮＣＥｉ ＬＯＮＧ　　　Ｌ　５ＴＡＲＴ； ＬＯＮＧ　　　Ｌ　ＬＥＮ； ５ＨＯＲＴ　　　Ｌ　ＰＩＤ； ５ＨＯＲＴ　　　Ｌ　ＨＩＤ； ］； 分散型ファイル・サボー）　（ＤＦＳ）を実施するため
のもう１つの重要な構造はファイル・アクセス構造であ
る。ファイル・アクセス構造のソース・フードを、詳細
な論理を示すための若干の説明情報と共に下に示す。

５ＴＲＵＣＴ　　ＦＩＬＥ　ＡＣＣＥＳＳ［１０ ファイル・アクセス構造ポインタ ＳＴＩ？ｔｌＣＴ　　ＦＩＬＥ　ＡＣＣＥＳＳ　”ＦＡ
　ＮＥＸＴ；　；　　　　／”ファイル・アクセス構造
フラッグ ５ＲＯＲＴ　　　ＦＡ　ＦＬＡＧ；　　／′ファイル・
アクセス構造全ユーザ ５ＨＯＲＴ　　　　ＦＡ　Ｃ０ＵＮＴ；　　／”ファイ
ル・アクセス構造読取り／専用カウント５ＨＯＲＴ　　
　ＦＡ　０ＲＯＣＮＴ；　／”ファイル・アクセス構造
読取り／書込みカウント ５ＨＯＲＴ　　　ＦＡ−０ＲＷＣＮＴ；　　／’ファイ
ル・アクセス構造実行プロセス ″／ ５ＩＩＯＲＴ　　　ＦＡ　ＴＸＴＣＮＴ；　／”ファイ
ル・アクセス構造ノード構造ポインタＳＴＲ［ＩＣＴ　
　Ｎ０ＤＥ　”ＦＡ　ＨＩＤ；　／”ファイル・アクセ
ス構造ノードＩＤ ＩＮＴ　　　　ＦＡ　ＮＩＤ１　／” ファイル・アクセス構造Ｓ　ｌＮ０ＤＨポインタ５ＴＲ
ＵＣＴ　　　　ｌＮ０ＤＥ　　”ＦＡ　　ＳＩＰ；　　
）；ＤＦＳは分散型環境でファイルのロッキングを調整
するためのロック制御サブルーチンを提供する。

詳細な論理を示すため、サブルーチンのインターフェー
ス・ソース・コードヲ下に示ス。

５ＴＲｔｌＣＴ　　ＦＬＯＣＫ　（ Ｓ１１０ＲＴ　　　Ｌ　ＴＹＰＥ； ５ＨＯＲＴ　　　Ｌ　ＷＨＥＨＣＥ； ＬＯＮＧ　　　Ｌ　５ＴＡＲＴ； ＬＯＮＧ　　　Ｌ　ＬＥＮ； ５ＨＯＲＴ　　　Ｌ　ＰＩＤ； ５ｌ（ＯＲＴ　　　Ｌ　ＨＩＤ； ）； ＤＦＳ　ＬＯＣＫ　Ｃ０ＮＴＲ０Ｌ（ＦＨ，、ＬＯＣＫ
　ＩＮＦＯ，ＣＭＤ。

ＦＡＳ　ＦＬＡＧ） ＦＩＬＥ　　ｌ！八へＤＬＥ　　Ｔ　　ＦＨ；５ＴＲＵ
ＣＴ　ＦＬＯＣＫ　”ＬＯＣＫ　ＩＮＦ□；５ＨＯＲＴ
　ＣＭＤ、　ＦＡＳ　ＦＬＡＧ；ＲＥＴＵＲＮ（ＥＲＲ
ＮＯ，ＭＯＤＥ、　５ＴＡＩ？Ｔ、　ＬＥＮＧＴ）Ｉ、
　ＨＩＤ。

ＰＩＤ） ＤＦＳロック制御サブルーチンは、パラメータＦＨ（フ
ァイル・ハンドル）、ＬＯＣＫ　　ＩＮＦＯ（ＦＬＯＣ
Ｋ構造のポインタ（アドレス））、ＣＭＤ　（実行すべ
きプロセス）およびＦＡＳ　　ＦＬＡＧ　（ファイル・
アクセス構造フラッグ））を有する。ファイル・ハンド
ルは、コマンドが実行される対象となるファイルを一義
的に識別するために必要である。ＬＯＣＫ　　ＩＮＦＯ
は、ＦＬＯＣＫ構造と、その中に含まれるファイルに関
するシステム情報を識別するために必要である。ＣＭＤ
は、すべてのロックが除去されるまで遠隔プロセスを待
たせ、それから指定されたＣＭＤを処理するようにセッ
トされる。０ＭＳフィールドは、アンロツタ、テスト、
セットまたはテスト／セット・コマンドを実行するよう
にセットすることができる。ＦＬＯＣＫ構造の１１ｅｎ
および１５ｔａｒｔフイールドは、コマンドが適用され
るロック範囲を指定するのに使われる。ＦＡＳ−ＦＬＡ
Ｇは、ＦＵＬＬＳＹＮＣ同期モードにあるかどうか知る
ため、ファイル・アクセス構造ロック内の同期モードを
調べよとサーバに命令するようにセットされる。ファイ
ルがＦＵＬＬＳＹＮＣ同期モードにある場合、サーバは
コマンドを実行する。しかし、そうでない場合は、エラ
ーが戻される。ファイル・アクセス構造フラッグがセッ
トされていない場合は、ファイルは、実行を始める前に
、ファイル・アクセス構造ロックの獲得および検査を行
なわない。この検査によって処理の前に照会が可能とな
り、デッドロックの可能性が回避される。

ファイル・ロッキング構造 ＬＯＣＫＦサブルーチンは、書込み排他特権のためにフ
ァイルをロックまたはアンロックするのにアプリケーシ
ョンが使用する主なインターフェースである。その使用
法を例示するため、このサブルーチンのインターフェー
ス・ソース・コードを下に示す。

１ｉｎｃｌｕｄｅ　＜ＳＹＳ／ＬＯＣＫＦ、ｔ（＞ｉｎ
ｔ　１ｏｃｋｆ（ｆｉｌｄｅｓ、　ｆｕｎｃｔｉｏｎ、
　５ｉｚｅ）；ｉｎｔ　ｆｉｌｃｌｅｓ、　ｆｕｎｃｔ
ｉｏｎ；ｌｏｎｇ　５ｉｚｅ； ロックは、ＵＮＩＸオペレーティング・システムＦＣＮ
ＴＬ　（２）によりＬＯＣＫＦと同様の方法でセットま
たは解除するこ七ができる。アプリケーションとＬＯＣ
ＫＦサブルーチンおよびＦＣＮＴＬサブルーチンの間の
外部インターフェースは、ＵＮＩＸオペレーティング・
システムと本発明で違いはない。ただ、分散型環境をサ
ポートするために間隔が修正されている。

内部の詳細 遠隔ファイルがロックされる場合は、ＵＮＩＸオペレー
ティング・システムのＬＯＣＫＦおよびＦＣＮＴＬシス
テム・コールが中断され、ＲＰＣＤＦＳ　　ＬＯＣＫ　
　Ｃ０ＮＴＲ０Ｌが実行される。

サーバ・ノードは遠隔プロセス・コールを受は取り、ロ
ック要求を実行する。要求は単一レコード、−組のレコ
ードまたはファイル全体のロックを伴うことがある。次
に、サーバは、クライエント代理ｉ／−ＦがＤＦＳ　　
ＬＯＣＫ　　Ｃ０ＮＴＲ０ＬのＲＰＣからの応答を待つ
間に、信号を送ることにより、クライエントが目を覚ま
すように命令する。クライエントはロックの受取りを確
認し、肯定応答を遠隔サーバに送る。サーバは、クライ
エント代理ｉノードから肯定応答を受は取った後、ロッ
ク・テーブルを更新する。サーバがＤＦＳ−ＬＯＣＫ　
　Ｃ０ＮＴＲ０Ｌの肯定応答の受取りを確認しない場合
、ＤＦＳ　　ＬＯＣＫ　　Ｃ０ＮＴＲ０Ｌはそのロック
をロック・テーブルから除去する。

ファイル・アクセス構造ロック ファイル・アクセス構造ロック、ｆａｓロツタは、分散
型ファイル・システム（ＤＦＳ）でオープン・ファイル
に対するｊノードおよび代理ｉノードの使用を同期する
ために使われる。この同期はデッドロック状況を回避す
るために実行される。デッドロック状態は、ｉノードお
よび代理ｉノードがロックされた場合に発生し得る。

スタンドアロンＡＩＸオペレーティング・システムでは
、ファイルＦに対するアクセスを必要とするシステム・
コールの実行は、そのファイルに対するシステム・コー
ルの全実行時間中にＦに対するｉノードをロックするこ
とにより直列化される。ＤＦＳでは、ファイルＦが遠隔
ノードＣでオープンされている場合は、ファイルＦを表
わす代理ｉノードがノードＣで作成される。したがって
、２つの資源が関係する。すなわち、ファイルが存在す
るサーバ・ノードにおける特定のファイルに対するｉノ
ードと、ファイルがオープンされているクライエント・
ノードにおける代理ｉノードでアル。クライエントＣで
実行されるシステム・コールを直列化するため、各コー
ルの実行時間中ファイルＦに対する代理ｉノードがロッ
クされる。クライエント・キャッシュで使用可能でない
データ・ブロックを読み取るためにサーバに対するアク
セスが必要な場合、ファイルＦに対するｉノードもロッ
クされる。

サーバにあるファイルＦに対するｉノードとクライエン
トにあるファイルＦに対する代理ｊノードを各システム
・コールの全実行時間中ロックすると、２つの資源を獲
得する順序が常に同じ順序で実施されない場合、デッド
ロック状況をもたらす可能性がある。一般には、代理ｉ
ノードが最初にロックされ、次に遠隔手順コール（ＲＰ
Ｃ）を介してサーバがアクセスされ、ｉノードがロック
される。しかし、上記の順序には幾つかの例外がある。

特定の条件の下で、サーバはｉノードをロックし、次に
、代理ｉノードのロックを必要とするクライエントにＲ
ＰＣを送ることができる。

第１８図に示すように、２つの動作が現在０１および０
２を実行している以下の状況のいずれか一方でデッドロ
ックが発生する可能性がある（０１は読取り動作、０２
はオープン動作である）。

ａ）０１がクライエント・ノードで実行されている。０
１は代理ｉノードをロックし、読取り動作のためサーバ
でｉノードをロックしようとする。

ｂ）０２がサーバで実行されている。０２はｉノードを
ロックし、ファイルをオープンするためにクライエント
・ノードに対してＲＰＣを開始する。

クライエント・ノードでのＲＰＣ要求は代理ｉノードを
待って、それをロックしてから実行される。

両方の動作が実行されており、かつ２つの同じ資源を必
要とし、それぞれ１つの資源を獲得し、かつ他方のロッ
クされた資源を待っているので、デッドロック状態が存
在する。原因を調べるに当たっては、サーバからクライ
エントに対するＲＰＣの実行中にデッドロックが発生す
ることに留意されたい。サーバ上のｉノードがまずロッ
クされ、代理ｉノードをロックしようとする試みがなさ
れる。これは、代理ｉノードがまずロックされ、次にｉ
ノードをロックするためにＲＰＣを送る大部分の場合と
は逆である。

上記問題の発生を防ぐため、サーバは、代理ｉノードを
ロックするためのＲＰＣをクライエントに出す前に、ｉ
ノードをアンロックすることかできる。オープン動作の
実行中にｉノードをアンロックすると、上記の問題が解
決される。しかし、そうすると複数のオープン動作また
はクローズ動作あるいはその両方が同時にサーバで行な
われる可能性があるので、オープン・ファイルのための
同期モード変更の管理が複雑になる。第１７図に示すよ
うなもう１つの問題が生じる可能性もある。　　　　−
第１７図では、１０にあるファイルＦが、２０にあるク
ライエント・ノードＣ−１内でのただ１つの処理によっ
て、非同期モードでオープンされている。２つの動作が
進行中である。すなわち、２０にあるＣ−１からのクロ
ーズ動作と、４０にある別のクライエントＣ−２からの
、１０でと同じファイルＦに対する６０でのオープン動
作である。

２０にあるＣ−１からのクローズ動作は代理ｉノード（
使用カウント１を有する）をロックし、５０でのｒｄｆ
ｓクローズＪ　ＲＰＣを３０にあるサーバに送る。４０
にあるＣ−２からのオープン動作は７０でのｒｄｆｓオ
ープン」を３０にあるサーバに送る。このＲＰＣはサー
バに到着し、２０にあるＣ−１からの５０でのｒｄｆｓ
クローズ」ＲＰＣの前に実行される。ファイルＦに対す
る同期モードは非同期なので、サーバはｉノードをアン
ロックし、８０でのｒｄｆｓ同期モード変更」ＲＰＣを
２０にあるＣ−１に送り、１０にあるファイルＦが全同
期モードに変更されることを要求する。このＲＰＣが２
０にあるＣ−ｔに到着し、代理ｉノードがアンロックさ
れるのを待つ。次に、５０でのｒｄｆｓクローズＪ　Ｒ
ＰＣがサーバに到着する。１０にあるファイルＦに対す
るｉノードハサーバではロックされないので、クローズ
動作がサーバで実行され、９０でのｒｄｆｓクローズ肯
定応答Ｊ　ＲＰＣが２０にあるＣ−１に送られる。

９０でのｒｄｆｓクローズ肯定応答ＪＲＰＣが２０にあ
るＣ−１に到着すると、代理ｉノードに関する使用カウ
ントが減分され、使用カウントの値が０になったので、
代理ｉノードは１００で解放される。これにより、同期
モード変更を２０にあるＣ−１に適用するための代理ｉ
ノードは残らない。

この問題に対する解決策は、それを待つ前に同期モード
変更手順に代理ｉノードの使用カウントを増分させるこ
とである。しかし、この時点では、ファイルＦはＣ−１
でオープンされていす、その同期モードは全同期ではな
いので、この手法はファイル管理システムにとって一層
の管理上の問題をもたらす。それよりも望ましい手法は
新しいロック、すなわちファイルに対するアクセス・リ
ストをアクセスまたは変更する動作を直列化するための
ファイル・アクセス構造ロック（ｆａｓロック）を導入
することである。ｆａｓロックを使用することにより、
ｉノードは重要な資源ではなくなる。２つの重要な資源
はクライエント・ノードにある代理ｉノードとサーバに
あるｆａｓロックである。デッドロックを防ぐには、ｆ
ａｓロックの保持を必要とするクライエント・ノードで
実行中の動作が、ＲＰＣがサーバに送られる前に、代理
ｉノードをアンロックしなければならない。

サーバからクライエントに対してＲＰＣを発生する可能
性がある動作は、サーバでの実行を開始する前に、ｆａ
ｓロックを獲得しなければならない。

ＵＮＩＸオペレーティング・システムまたはＡＩＸオペ
レーティング・システム環境における状況の例は以下の
通りである。

遠隔手順コール（ＲＰＣ）： ＊　ＤＦＳ　ＳＥＴ　ＡＴＴＲ＊ＤＦＳ　ｌ、０ＯＫＵ
Ｐ：　ＤＦＳ　ＣＨＮＧ　５ＹＮＣＭＯＤＥサーバ処理
からのシステム・コール： ネ叶ＥＮ　　　　　　　　　：　ＣＬＯ３Ｅ＊ＣＲＥΔ
Ｔ　　　　　　　　　＊　５ＴＡＴ＊ＦＵＬＬＳＴＡＴ
　　　　　　　：　ＣＨＭＯＤ＊ＥＸＩＴ 上記ＵＮＩＸオペレーティング・システムおよびＡＩＸ
オペレーティング・システムの動作は以下のｖｎ動作に
対応する。

＊　ｖｎ　ｏｐｅｎ　　　　　　　　＊　ｖｎ　ｃｒｅ
ａｔｅ＊ｖｎ　ｃｌｏｓｅ　　　　　　　＊　ｖｎ　ｇ
ｅｔａｔｔｒ＊　ｖｎ　５ｅｔａｔｔｒ　　　　　　ｓ
’；　ｖｎ　１ｏｏｋｕｐ二Ｍ ｖｎ動作実行の一例を以下に考察し、第１９図に示す。

動作（オープン）はクライエント・ノードで実行され、
何らかのローカル処理が必要な場合は、通常通り代理ｉ
ノードをロックする。上記に列挙したＲＰＣの１つ（ｄ
ｆｓオーブン）がサーバに送られた場合、ＲＰＣが送ら
れる前に、代理ｉノードがアンロックされる。サーバで
は、ＲＰＣ要求はｆａｓロツタをロックするか、あるい
はｆａｓロツタが使用中の場合はそれを待ち、次に、フ
ァイルＦに対するｉノードをロックする。ＲＰＣ要求が
ローカル・サーバ動作である場合は、実行中のプロセス
はｆａｓロツタを獲得し、次にｉノードをロックする。

ＤＦＳ　　ＣＨＮＧ　　５ＹＮＣＭＯＤＥまたはＤＦＳ
　　ＧＥＴ　　ＡＴＴＲＲＰＣがサーバからクライエン
トに送られる場合、ＲＰＣが送られる前に、ｉノードが
アン口・ツクされる。

したがって、サーバは、ＲＰＣが送られた後で、読取り
および書込み動作を受諾することができる。

すべてのクライエントからの応答メ・ソセージを受は取
ると、サーバはｉノードを口・ツクして、残りのローカ
ル・プロセスを終了する。動作がクライエント・ノード
て開始された場合は、そのクライエントに肯定応答が送
られる。ｉノードが次にアンロックされ、ｆａｓロック
が解除される。

ｆａｓロックは、ｉノードの使用を同期し、デ、ソドロ
ツタ動作を回避する手段を提供する。ｆａｓ口、ソりは
、ファイルをオープンしているノードに関する情報を含
むファイル・アクセス構造リストに対するアクセスを同
期する。ｆａｓロックは、プロセスがファイルをオープ
ンまたはクローズするとき、またはファイル・アクセス
構造リストが照会されているとき、ロックされる。ｆａ
ｓロックは、ファイルが全同期モードにあるときは、書
込み動作中もロックされる。

ｉノード・ロックはサーバにあるファイルのデータに対
するアクセスを同期する。ｉノード・ロックは、サーバ
にあるファイルに対する読取りまたは書込み動作中ロッ
クされる。遠隔手順コールが代理ｉノード・ロックに対
するロックを必要とする場合、サーバが遠隔手順コール
をクライエントに送る前に、ｉノード・ロックがアンロ
ックされる。

代理ｉノード・ロックはクライエント・プロセス内のフ
ァイル・アクセスを同期する。クライエントでの動作が
ファイルにアクセスしている場合、代理ｉノードはロッ
クされる。クライエントでの動作がｆａｓロツタをロッ
クする場合は、代理ｉノードがアンロックされる。代理
ｉノードはまた、遠隔手順コールがクライエントからサ
ーバに送られる前にアンロックされる。

ｆａｓロックおよびｉノード・ロックの両方がロックさ
れている場合は、ｉノード・ロックは、サーバがクライ
エントに対して遠隔手順コールを発生する前に、アンロ
ックされる。このため、ｆａｓロックおよび代理ｉノー
ド・ロックがロックできるようになる。これらのロック
は、ロックされたのと逆の順序でアンロックされる。

特定のオペレーティング・システム環境における好まし
い実施例に関して本発明を説明してきたが、当業者なら
気付くように、頭記の特許請求の範囲の精神および範囲
内で、変更を加えることにより、他の様々なオペレーテ
ィング・システムでも本発明を実施することができる。

Ｆ０発明の詳細 な説明したように本発明によればファイルに対するアク
セスのリストの変更をロックする構成を採用しているの
で分散型ファイル・アクセスにおけるデッドロックを解
消することができる。

【図面の簡単な説明】

第１図は、本発明による分散型データ処理システムを示
す、第１図と同様の構成図である。 第２図は、本発明をその中で機能するように設計した通
常の分散データ処理システムの構成図である。 第３図は、通常のスタンドアロン・プロセッサ・システ
ムの構成図である。 第４図は、プロセッサ上で走行するアプリケーション・
プログラムが読取りシステム・コールを行なうとき、オ
ペレーティング・システムが実行する各ステップの流れ
図である。 第５図は、本発明をサポートするオペレーティング・シ
ステムによって実行される、ローカル・ノードでファイ
ル操作へのパスをたどるためのシナリオを示す、データ
構造の構成図である。 第６図および第７図は、オペレーティング・システムに
よって実行される、ローカル・ノードでのファイル・マ
ウント操作のシナリオの前後条件を示す、データ構造の
構成図である。 第８図は、第７図に示す分散型ファイル・システム用の
データ構造の構成図である。 第９Ａ図ないし第９Ｆ図は、第８図に示すデータ構造の
構成要素の構成図である。 第１０図、第１１図および第１２図は、オペレーティン
グ・システムが実行する、分散型システムのローカル・
ノードおよび遠隔ノードでのファイル・マウント動作の
ための、およびファイルに至るパスをたどるためのシナ
リオを示す、データ構造の構成図である。 第１３図は、第７図に示す分散型データ処理システムの
一部分をさらに詳細に示す構成図である。 第１４図は、本発明をサポートするオペレーティング・
システムが使用する種々の同期モードを示す状態図であ
る。 第１５図は、同期モード動作を示す第１３図と同様な構
成図である。 第１６図は、分散型ファイル・システムの同期モードの
一例を示す、第１４図の状態図と同様な状態図である。 第１７図は、２つのクライエント・ノードによるファイ
ルに対するアクセスの制御の流れを示すダイヤグラムで
ある。 第１８図は、２つの動作が現在実行されているときのデ
ッドロックを示すダイヤグラムである。 第１９図は、クライエントからのオープン要求の実行ス
テップを示すダイヤグラムである。 １・・・・分散型データ処理システム、２Ａ、２Ｂ。 ２Ｃ・・・・ディスク、３・・・・ネットワーク、４Ａ
１４Ｂ、４Ｃ・・・・アプリケーション・プログラム、
５Ａ、５Ｂ、５Ｃ・・・・ファイル、１０Ａ１１０Ｂ１
１０Ｃ・・・・処理装置、ｌｌＡ１１１Ｂ１１１Ｃ・・
・・オペレーティング・システム、１２Ａ１１２８１１
２Ｃ・・・・サーバ・キャッシュ。 第４図 クライエント サーノ、パ 第１０図 ））−フイエンに 舟−八・・

Claims (1)

1. 【特許請求の範囲】 サーバー・データ処理装置にファイル・データを常駐さ
   せ、複数のクライエント・データ処理装置の複数のプロ
   セスがそのファイル・データをアクセスできるようにし
   た分散型データ処理システムにおいて、 現に上記ファイル・データをアクセスしているデータ処
   理装置に関するリストへのアクセスに一貫性を付与する
   第１のロック手段と、 上記サーバー・データ処理装置上のファイル・データへ
   のアクセスに一貫性を付与する第２のロック手段と、 上記複数のクライエント・データ処理装置のうちの１つ
   におけるファイル・アクセスに一貫性を付与する第３の
   ロック手段とを有することを特徴とする分散型データ処
   理システム。