JPS63204437A - ロック・システム - Google Patents

Abstract

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

Description

【発明の詳細な説明】 以下、本発明を下記の順序に従って説明する。

Ａ、産業上の利用分野 Ｂ、従来技術 Ｃ０発明が解決しようとする問題点 り１問題点を解決するだめの手段 Ｅ、実施例 Ｅ−１，ファイル・システム Ｅ−２，ファイルの同期モード Ｅ−３，ロック Ｆ０発明の効果 Ａ、産業上の利用分野 本発明は一般に、分散データ処理システム用のオペレー
ティング・システムの改良、特にローカル・エリア・ネ
ットワーク（ＬＡＮ）又は広域ネットワークＣＷＡＮ）
によって相互接続されたマルチ・プロセッサーシステム
用のオペレーテイング・システムの改良に関する。ＬＡ
Ｎ又はＷＡＮを構築するだめにＩＢＭシステム・ネツ゛
トワーク・アーキテクチャ（ＳＮＡ）を使用する事がで
きる。本発明によるオペレーティング・システムは、フ
ァイルがシステム中のどこにあっても、ファイルへのア
クセスを可能にする。本発明の良好な実施例はＵＮＩＸ
（ＵＮＩＸはＡＴ＆Ｔの米国における登録商標である）
オペレーティング・システムの１バージヨンにおいて実
施されたが、他の異なったオペレーティングφシステム
で本発明を実施する事もできる。

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

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

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

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

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

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

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

以下では、ＵＮＩＸオペレーティング・システムの１バ
ージヨンで本発明を実施した場合について説明するが、
本発明はＵＮＩＸオペレーティング・システムに類似す
る特徴をもつ他のオペレーティング・システムでも使用
できる。ＵＮＩＸオヘレーテイング・システムは、ベル
研究所（ＢｅｌｌＴｅｌｅｐｈｏｎｅ　　Ｌａｂｏｒａ
ｔｏｒｉｅｓ、Ｉｎｃ、）がディジタル・エクイツプメ
ント社（ＤｉｇｉｔａｌＥｑｕｉｐｍｅｎｔ　　Ｃｏｒ
ｐｏｒａｔｉｏｎｌＩＤＥＣ）のミニコンピユータ用に
開発したものであるが、広範囲のミニコンピユータ用、
それに最近ではマイクロコンピュータ用のオペレーティ
ング−システムとして広く使われている。この普及の一
因は、ＵＮＩＸオペレー゛ティング・システムがアセン
ブリ言語ではな（、やはりベル研究所で開発されたＣプ
ログラミング言語で書かれており、したがって、プロセ
ッサの種類を問わないことである。したがって、様々な
計算機用のＣコンパイラを使うと、ＵＮＩＸオペレーテ
ィング・システムをある計算機から別の計算機に移すこ
とが可能になる。すなわち、ＵＮＩＸオペレーティング
・システム環境用に書かれたアプリケーション・プログ
ラムも、計算機間で移植可能である。ＵＮＩＸオペレー
ティング・システムの詳細については、［ＵＮＩＸＴＭ
システム、ユーザーズ・マニュアル、システムＶＭ （ＵＮ　ＩＸ　　　Ｓｙｓｔｅｍ、Ｕｓｅｒ’ｓ　　Ｍ
ａｎｕａｌ、Ｓｙｓｔｅｍ　Ｖ）Ｊ、Ｗｅｓｔｅｒｎ　
　Ｅｌｅｃｔｒｉｃ　　Ｃｏ、、１９８３年１月刊を参
照のこと。ＵＮＩＸオペレーティング・システムの秀れ
た概説が、Ｂ、Ｗ、カーニハン（Ｂｒｉａｎ　　Ｗ、Ｋ
ｅｒｎｉｇｈａｎ）とロブーパイク（Ｒｏｂ　　Ｐｉｋ
ｅ）の共著「ユニックス・プログラミング環境（Ｔｈｅ
　Ｕｎｉｘ　　ＰｒｏｇｒａｍｍｉｎｇＥｎｖｉｒｏｎ
ｍｅｎｔ）ｊ　Ｐｒｅｎｔｉｃｅ−）（ａｌｌ、　１９
８４年刊に出ている。ＵＮＩＸオペレーティング・シス
テムの設計の詳細については、Ｍ、Ｊ、バッハ（Ｍａｕ
ｒｉｃｅ　　Ｊ、Ｂａｃｈ）著［ユニックスーオペレー
テイング会システム（７）設計（Ｄｅｓｉｇｎ　　ｏｆ
ｔｈｅ　　Ｕｎｉｘ　　Ｏｐｅｒａｔｉｎｇ　　Ｓｙｓ
ｔｅｍ）Ｊ、ｐｒｅｎｔｉｃｅ−Ｈａｌｌ、１９８６年
刊に出ている。

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

本発明は、具体的には、複数のプロセッサがネットワー
ク内で相互接続されることを特徴とする、分散データ処
理システムに関係する。実際に実施された形では、本発
明は、ＩＢＭのシステムネットワーク・アーキテクチャ
（ＳＮＡ）、さらに具体的にはＳＮＡ　　ＬＵ６．２拡
張プログラム間通信（ＡＰＰＣ）で相互接続された複数
のＩＢＭ　　ＲＴ　　ＰＣ上で機能する。ＳＮＡでは、
そのリンク・レベルとして、ゼロックス社が開発したロ
ーカル・エリア・ネットワーク（ＬＡＮ）であるイーサ
ネット（ＥｔｈｅｒｎｅｔはＸｅｒｏｘ　Ｃｏｒｐｏｒ
ａｔｉｏｎの商標）または５ＤＬＣ（同期データ・リン
ク制御）を使う。イーサネット・ローカル・エリア・ネ
ットワークを含めてローカル・エリア・ネットワークの
簡単な説明は、Ｌ、　　Ｅ、　　ジョーダン（Ｌａｒｒ
ｙ　Ｅ、　Ｊｏｒｄａｎ）とＢ、チャーチル（Ｂｒｕｃ
ｅ　　Ｃｈｕｒｃｈｉｌｌ）の共著ＦＩＢＭ　　ＰＣ用
の通信ネットワーキング（Ｃｏｍｍｕｎｉｃａｔｉｏｎ
３ａｎｄ　Ｎｅｔｗｏｒｋｉｎｇ　ｆｏｒ　ｔｈｅ　　
Ｉ　ＢＭ　　ＰＣ）Ｊ、Ｒｏｂｅｒｔ　Ｊ、　Ｂｒａｄ
ｙ（Ｐｒｅｎｔｉｃｅ−Ｈａｌｌの子会社）、１９８３
年刊に出ている。コンピュータ用通信システム、とくに
ＳＮＡと５ＤＬＣについてのより明確な説明は、Ｒ，Ｊ
、　　シフｆ−（Ｃｙｐｓｅｒ）著［分散システム用通
信アーキテクチャ（Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　　
Ａｒｃｈｉｔｅｃｔｕｒｅｆｏｒ　　Ｄｉｓｔｒｉｂｕ
ｔ、ｅｄ　Ｓｙｓｔｅｍ）ｊ、Ａｄｄｉｓｏｎ　−Ｗｅ
ｓｌｅｙ、１９７８年刊に出ている。ただし、本発明は
、イーサネット・ローカル・エリア・ネットワークやＩ
ＢＭ　　ＳＮＡ以外のネットワークで相互接続された、
ＩＢＭ　　ＲＴ　　ＰＣ以外の様々なコンピュータを用
いても実施できることを了解されたい。

前述のように、以下では、通信ネットワーク中の分散デ
ータ処理システムを対象として本発明を説明する。この
環境では、ネットワークのあるノードにある各プロセッ
サは、どのノードにファイルがあろうと、潜在的にその
ネットワーク内のすべてのファイルにアクセスすること
ができる。第１図に示すように、分散ネットワーク環境
１゛は、通信リンクまたは通信ネットワーク６を介して
接続ちれた２つ以上のノードＡ、Ｂ、Ｃかも構成される
。ネットワーク６は上記のようなローカル・エリア・ネ
ットワーク（ＬＡＮ）でも広域ネットワーク（ＷＡＮ）
でもよい。後者は、システムの他のノードまたはＳＮＡ
ネットワークへの交換回線または専用回線テレプロセッ
シング（ＴＰ）接続を含む。ノードＡ、Ｂ、Ｃのどこに
も、上記のＩＢＭ　　ＲＴ　　ＰＣのような処理システ
ム１０Ａ１１０Ｂ、１０Ｃがあり得る。こうした処理シ
ステムＩＯＡ、１０Ｂ、１０Ｃはそれぞれ単一ユーザ・
システムでも複数ユーザ・システムでもよく、ネットワ
ーク６を使ってネットワーク内の遠隔ノードにあるファ
イルにアクセスする能力をもつ。

たとえば、ローカル・ノードＡにある処理システム１Ｏ
Ａは、遠隔ノードＢおよびＣにあるファイル５Ｂと５Ｃ
にアクセスできる。

遠隔ノードにアクセスする際にぶつかる問題は、まずス
タンドアロン・システムがどのようにしてファイルにア
クセスするかを検討すると、よく理解できる。第２図の
１０のようなスタンドアロン・システム内では、オペレ
ーティング・システム１１中のローカル・バッファ１２
を使って永久記憶装置２、たとえばハード・ファイルや
パーソナル・コンピュータ中のディスクとユーザ・アド
レス空間との間で転送されるデータを緩衝記憶する。

オペレーティング・システム１１内のローカル・バッフ
ァ１２は、ローカル・キャッシュあるいはカーネル・バ
ッファとも呼ばれる。

ＵＮＩＸオペレーティング・システムのカーネルの詳細
については、上記のカーニハン等の著書およびバッハの
著書を参照のこと。ローカル・キャッシュは、メモリ常
駐ディスクとして理解すると最も理解しやすい。データ
はディスク上で持っていた物理的特性を保持するが、情
報は今や、主システム記憶装置で達成される速度に非常
に近い、より速いデータ転送速度を有する媒体中に存在
しているのである。

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

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

同様に、アプリケーション・プログラム４から書き込ま
れたデータは、直接ディスク２には書き込まれず、キャ
ッシュ１２に書き込まれる。このことによっても時間が
節減され、アプリケーション・プログラムのパフォーマ
ンスが向上する。キャッシュ１２内の修正されたデータ
・ブロックは、オペレーティング・システム１１の制御
下で周期的にディスク２に保管される。

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

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

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

ネットワークを介してファイルにアクセスする場合、上
記の２つの競合する問題が生じる。一つの問題は、連続
する読取りと書込みのためにネットワークを介してデー
タを送信するのに時間がかかることである。他方、ネッ
トワークのトラフィックを減らすためにファイル・デー
タをノードに記憶する場合、ファイルの整合性が失われ
るおそれがある。たとえば、いくつかのノードのうちの
一つがファイルに書込みを行なっている場合、そのファ
イルにアクセスしている他のノードが、令書き込まれた
ばかりの最近の更新済みファイルにアクセスしていない
ことがある。したがって、ファイルの整合性が失われ、
ノードがアクセスしているファイルが正しくない古（な
ったものであることがある。

本明細書中では、ファイルを永久的に記憶している処理
システムを指すのに１サーバ」という言葉を使い、その
ファイルにアクセスするプロセスを有する他の任意の処
理システムを指すのに１クライエント」の語を使うこと
にする。

ＵＮＩＸオペレーティングシステム環境内で分散データ
処理システムをサポートする方法は、他にも知られてい
る。たとえば、Ｓｕｎ　Ｍｉｃｒｏｓｙｓｔｅｍｓはネ
ットワーク・ファイル・システム（ＮＦＳ）を発表し、
ベル研究所は遠隔ファイル・システム（ＲＦＳ　）を開
発している。

本発明をその中で実施する分散サービス・システムの、
たとえばＳｕｎ　ＭｉｃｒｏｓｙｓｔｅｍｓのＮＦＳと
は区別される一つの特徴は、Ｓｕｎ　の方法が基本的に
状態非保存（５ｔａｔｅｌｅｓｓ　）の機械を設計する
ためのものであったということである。

もつと具体的に言うと、分散システム内のサーバを状態
非保存型に設計することができる。すなわち、サーバは
、どのクライエント・ノードがサ−バ・ファイルをオー
プンしたか、クライエント・プロセスが読取り専用モー
ドでファイルをオープンしたのかそれとも読取り／書込
みモードでファイルをオープンしたのか、あるいはクラ
イエントがそのファイルのバイト範囲にロックをかけて
いるかどうかを含めて、クライエント・ノードに関する
情報を何も記憶しない。このような実施形態をとると、
クライエント・ノードが故障したり、あるいはサーバ資
源に対する要求を解除したとサーバにきちんと知らせず
にオフラインになったときに生じる、誤り回復状況をサ
ーバが処理する必要がないので、サーバの設計が簡単に
なる。

本発明をその中で実施する分散サービス・システムの設
計では、全（異なる方法が取られた。もつと具体的に言
うと、この分散サービス・システムは、「状態保存型の
インプリメーション」であると特徴づけることができる
。本明細書に記載する［状態保存型の（Ｓｔａｔｅｆｕ
ｌｌ）Ｊサーバは、誰がそのファイルを使っているか、
およびファイルがどのように使われているかに関する情
報を保持する。それには、サーバが何らかの方法である
クライエントとの接触の喪失を検出して、そのクライエ
ントに関する蓄積された状態情報を廃棄できるようにす
る必要がある。しかし、本明細書に記載するキャッシュ
管理戦略は、サーバがそうした状態情報を保持しない限
り実施できない。キャッシュの管理は、下記で説明する
ように、サーバーファイルをオープンせよとの要求を発
行しているクライエント・ノードの数およびそうしたオ
ープンが読取りモードであるかそれとも書込みモードで
あるかによって影響を受ける。

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

分散したファイル及びレコードのロッキング機能を提供
する事が、本発明のより具体的な第２の目的である。

Ｄ６問題点を解決するだめの手段 本発明によれば、これらの目的は、ファイルをロックす
るのに下記のステップを用いる事によって達成される。

もしファイルがローカル・ファイルであれば、その時は
ＵＮＩＸオペレーティング・システムの標準的なファイ
ル・ロッキングが使われる。しかし、遠隔ファイルがロ
ックされるならば、ＵＮＩＸオペレーティング・システ
ムのＬＯＣＫＦ及びＦＣＮＴＩ、システムｅコールはイ
ンターセプトされ、遠隔プロセス・コール（ＲＰＣ）Ｄ
ＦＳ　　ＬＯＣＫ　　Ｃ０ＮＴＲ０Ｌが実行される。

サーバ・ノードはＲＰＣを受は取り、ロック要求を実施
する。この要求は単一のレコード、１組のレコード又は
ファイル全体にロックを行なう事ができる。次に、クラ
イエントの代理ｉノードがＤＦＳ　　ＬＯＣＫ　　Ｃ０
ＮＴＲ０Ｌ　　ＲＰＣからの返答を待機している間に、
サーバは、クライエントに通知を送る。クライエントは
、ロックの受理上確認しＲＰＣの受信を遠隔サーバに返
答する。

サーバは、クライエントの代理ｉノードからの返答の受
信後にロック・テーブルを更新する。もしサーバがＤＦ
Ｓ　　ＬＯＣＫ　　Ｃ０ＮＴＲ０Ｌの返答の受信を確認
しなげれば、ＤＦＳ　　ＬＯＣＫ−ＣＯＮＴＲＯＬがロ
ック・テーブルからロックを除去する。

Ｅ、実施例 Ｅ−１，ファイル・システム 下記の開示では、物理的にはい（つかの異なった計算機
の中に存在するファイルがローカルの計算機のファイル
・システムの一部であるように見える事を可能にするよ
うに、ファイルを管理する論理が変更された分散ファイ
ル・システムを形成する時に出会う問題に対する解決策
について説明する。ここで説明するインプリメンテーシ
ョンは、ＡＩ）ｌ−ベレーテイング・システムのファイ
ル・システムの拡張である。このＡＩＸオペレーティン
グ・システムの詳細については、前記で参照した技術解
説書を参照されたい。木構造ファイル・システム、ディ
レクトリ、およびｉノードを含むファイル・システム構
成などのＡＩＸファイルｅシステムに関する特定の知識
があるものと仮定する。

ＵＮＩＸオペレーティング・システムにおいて、各ディ
スク（又はディスケット又はディスクの区画）がファイ
ル・システムを含んでいる。この議論に関係のあるファ
イル・システムの基本的態様を下記に列挙する。

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

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

注：ある種の文脈中では、ディレクトリであるファイル
とディレクトリでないファイル（たとえば、単に通常の
データを含むだけのファイル、または特殊ファイルやバ
イブなとＵＮＩＸ類似のオペレーティング・システムで
サポートされる他の種類のファイル）′５ｒ：区別する
必要がある。

この開示では、そうしたディレクトリでないファイルを
示すのに「単純ファイル」という言葉を使う。別設の指
示がない限り、「ファイル」という言葉はディレクトリ
・ファイルも単純ファイルも表し、もちろん、「ディレ
クトリ」の語はディレクトリ・ファイルを意味するもの
とする。

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

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

注：ディレクトリは他のディレクトリを含むことがあり
、後者はさらに別のディレクトリまたは単純ファイルを
含むことがある。

したがって、ディレクトリは何段もの子孫ディレクトリ
を含み得る部分木のルートと見なすことができ、その場
合、木の葉が［゛単純ファイル」でるる。

この開示では、「子孫」の語は、他のディレクトリを経
由しないと到達できないものも含めて、ファイル・ツリ
ーの特定のディレクトリより下方にあるすべてのファイ
ルを意味するものとする。

あるディレクトリの「直属子孫」とは、そのディレクト
リに名前が出ているファイル（単純ファイルまたはディ
レクトリ）のみを言う。

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

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

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

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

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

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

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

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

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

個別のファイル・システム上に存在するファイル・ツリ
ーは、あるノードの集合（ａｇｇｒｅｇａｔｅ）ファイ
ル・ツリーを構築するための構成要素である。ある特定
の装置（たとえば、ハード・ファイル区画）は、ノード
のハード・ファイル・システムを含む装置に指定される
。マウント操作の実行により、別の装置上にあるファイ
ル・ツリーをノードのファイル・ツリーて付加すること
ができる。

マウント操作の２つの主要バラメー、夕は、（１）マウ
ントされるファイル・ツリーを保持する装置の名前と（
２）装置のファイル・ツリーをマウントするディレクト
リへのパスである。このディレクトリは、既にノードの
ファイル・ツリーの一部分でなければならない。すなわ
ち、ルート・ファイル・システム内のディレクトリ、ま
たは（マウント操作によって）ノードのファイル・ツリ
ーに既に付加されたファイル・システム内のディレクト
リでなければならない。

マウントの実行後は、普通なら「マウント・オーバーさ
れた」ブイレフ）　ＩＪを通って流れるはずのパスが、
マウントされたファイル・システムのルート１ノードを
通って流れる。マウント操作は、次のように進行する。

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

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

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

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

こうしたインプリメンテーションは、ある装置上に存在
するファイル・システム全体をマウントスることに限定
されている。仮想ファイル・システムの概念は、（１）
装置をマウントできる上にファイル（ディレクトリまた
は単純ファイル）もマウントできるようにすることによ
り、ある装置上に存在するファイル・システムの一部分
をマウントすること、および（２）既にファイル・ツリ
ーの一部分になっているディレクトリ上に、遠隔ディレ
クトリまたはローカル・デ・丁しクトリをマウントする
こと、さらに（３）既にファイル・ツリーの一部分にな
っている単純ファイルの上に（遠隔またはローカル）単
純ファイルをマウントすることを可能にする。

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

ローカル睦ファイルの管理は、遠隔ファイルの管理より
も簡単な問題である。このため、仮想ファイル・システ
ムの考察を２つの部分に分ける。

第１の部分では、ローカル操作のみについて説明する。

この部分は、遠隔操作を考察するための基礎となる。遠
隔操作にもローカル操作にも同じデータ構造と操作が使
われる。ローカル操作の考察では、データおよび手順の
うちスタンドアロン操作にとって重要な態様について説
明する。遠隔操作の考察では、遠隔操作に関連する情報
を付は加えるが、ローカル操作の部で考察したことは繰
り返さない。

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

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

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

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

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

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

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

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

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

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

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

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

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

〔ＶＮ　　ＬＯＯＫＵＰ） ｖｎルックアップ操作では、ファイル・システム内のバ
スをたどる際の基本的反復ステップは、ディレクトリ内
でパス構成要素の名前を探し出し、関連するｉノード番
号を便ってチェーン中の次のファイルを探し出すという
ものである。ローカル・ファイル上でのｖｎルックアッ
プ操作の擬似コードを下記に示す。

ＬＯＯＫＵＰ機能 入カニディレクトリのＶノード・ポインタ、ディレクト
リ中でルックアップすべき名前用カニ指定されたファイ
ル／ディレクトリを指すＶノード・ポインタ ディレクトリのＶノード・ポインタを１ノード・ポイン
タに変換する； 一−ｖノード中のポインタを使う ディレクトリの１ノードをロックする；ＩＦ（ディレク
トリ中で探索許可をもっていない） ディレクトリｉノードをアンロックする；エラーを戻す
； ディレクトリで名前を探索する； ｉｐ（見つかった） 名前に対するファイル・・・ンドルを作成する； ｍ−ディレクトリ・エントリ中で見つかった１ノードを
使う： ′　ファイル會ハンドルに対するＶノードを指すポイン
タを得る； ディレクトリｉノードをアンロックする；Ｖノードを指
すポインタを戻す； ＥＬＳＥ−＝見つからなかった ディレクトリｉノードをアンロックする；エラーを戻す
； （ＶＮ　　０ＰＦＪＮ〕 ｖｎ　　ｏｐｅｎ機能は、何のオーブンφモード（読取
／書込又は読取専用）がファイルをオープンしたかを記
録するためにファイル・アクセス構造を形成（又は既存
のものを修正）する。ｖｎ二ｏｐｅｎ動作に関する擬似
コードを下記に示す。

ｖｎ　　ｏｐｅｎ機能 入カニオープンすべきファイルに関するｖｎｏｄｅポイ
ンタ オープン・フラグ（例えば、読取専用、読取／書込） 形成・モードーー新たに形成する場合のファイル・モー
ド・ビ ット 出カニ成功又は失敗を示す戻りコード Ｖノードからファイルのｉノードへのポインタを得る； ｉノードをロックする； ＩＦ（アクセス不許可） ｉノードをアンロックする； リターン（エラー）； このクライエントに関するファイル・アクセス構造を得
る； −もしファイル・アクセス構造がなげれば１つ割り当て
る ＩＦ（ファイル・アクセス構造の割り当て不可能） ｉノードをアンロックする； リターン（エラー） ファイル・アクセス構造を読取専用、読取／書込、及び
テキスト・カウントに更新する；ＩＦ（打ち切りモード
がセットされている）ファイルを打ち切る； ｉノードをアンロックする； 〔ＬＯＯＫＵＰＰＮ〕 １ｏｏｋｕｐｐｎ操作とは、バスをたどる機能である。

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

１ｏｏｋｕｐｐｎは１つのディレクトリを読み取るため
ｖｎ　　１ｏｏｋｕｐを呼び出し、次にｖｎ　　１ｏｏ
ｋｕｐから戻されたＶノードが既にマウント・オーバー
されているかどうか検査する。Ｖノードがマウント・オ
ーバーされていない場合、１ｏｏｋｕｐｐｎは同じファ
イル・システム中のｖｎ　　１ｏｏｋｕｐを呼び出す。

Ｖノードが既にマウント・オーバーされている場合は、
１ｏｏｋｕｐｐｎはマウント・オーツく−されたＶノー
ド（たとえば第４図のブロック２４）からマウントされ
たファイル番システムの仮想ファイル・システム（たと
えば第４図のブロック２５）へとポインタをたどる。仮
想ファイル・システムから、ルートｖノード（たとえば
第４図のブロック２６）へとポインタをたどり、Ｖノー
ドが単純ファイルではなくディレクトリである場合は、
その仮想ファイル・システムのルートｖノードとバス中
の次の要素を構成す仝名前を入力として与えて、新しい
ｖｎ　　１ｏｏｋｕｐを発行する。

１ｏｏｋｕｐｐｎ機能の擬似コードを下記に示す。

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

ディレクトリ ｉノード番号　　　名前　　　ｉノード番号２　　　　
　　ｕ”　　　　　１５ ４５　　　　　”ｄｅｐｔ　５４”　　　　７１７１　
　　　　”５ｔａｔｕｓ”　　　１２システム・コール
を実施するコードが、そのバスをたどるために１ｏｏｋ
ｕｐｐｎを呼び出す。

１ｏｏｋｕｐｐｎはルート仮想ファイル・システム（ブ
ロック２１）のルートＶノード（ブロック２３）からス
タートし、このＶノードで表されるディレクトリ・ファ
イル中で名前”Ｕ“′をルックアップするためにｖｎ　
１ｏｏｋｕｐ　ｆ呼び出す。ｖｎ　１ｏｏｋｕｐはその
ディレクトリ中で、名前”　ｕ”がブロック３１のｉノ
ード１５と関連していることを見つける。ｖｎ　　１ｏ
ｏｋｕｐはｉノード１５と関連するＶノードを指すポイ
ンタを戻さなければならない。そのために、まずｉノー
ド１５をｉノードテーブルに入れる。次に、既にこのＶ
ノードの親仮想ファイル・システム内にＶノードがある
（入力Ｖノード（ブロック２３）が親仮想ファイル・シ
ステムを指すポインタを有する）かどうか検査する。こ
の場合は存在する。ｖｎ　１ｏｏｋｕｐは次に、ルート
仮想ファイルΦシステム（ブロック２１）内でそのＶノ
ード（ブロック２４）を見つけ、Ｖノードを指すポイン
タを戻す。１ｏｏｋｕｐｐｎは、戻されたＶノードが親
仮想ファイル・システム内でマウント・オーバーされて
いることを発見する。

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

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

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

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

ディレクトリ ｉノード番号　　　名前　　　ｉノード番号２　　　　
　”ｕ”　　　　　　　　１５２　　　　”ｅｔｃ”　
　　　　　８３　　　’１５　　　　　”ｇｏｒｐ”　
　　　　９２８３　　　　　”ｆｏｏ″　　　　　７５
７５　　　　　”ｆｉｌｅｌ”　　　　８９マウント・
システム・コールを実施ｆるコ−）’は、次の操作を実
行する。マウント・オーバーされるファイル”　／　ｅ
　ｔ　ｃ　／　ｆ　ｏ　ｏ”へのパス；ｔ−ｆトるため
、１ｏｏｋｕｐｐｎを呼び出す。この操作が完了したと
き、ルート仮想ファイル・システム（ブロック４１）は
、”／ｅｔｃ／ｆｏｏ”に対するＶノード（ブロック４
４）を含んでいる。このＶノードは、ルート仮想ファイ
ル−システム（ブロック４１）を指すポインタと、ｉノ
ード７５に対するｉノード争テーブル項目（ブロック４
５）を指すポインタを有する。マウントされるファイル
１／　ｕ　／　ｇ　Ｑ　ｆ　ｐ　”　ヘのバスをたどる
ため、１ｏｏｋｕｐｐｎを呼び出す。この操作が完了し
たとき、ルート仮想ファイル拳システム（ブロック４１
）は／Ｕ７ｇｏｒｐ”に対するＶノード（ブロック４９
）を含んでいる。このＶノードは、ルート仮想ファイル
・システム（ブロック４１）’（ｉ＝指すポインタと、
ｉノード９２に対するｉノード番テーブル項目（ブロッ
ク４８）を指すポインタを有する。ここでマウント論理
は、新しい仮想ファイル・システムを作成する。それに
は、まず新しい仮想ファイル−システム（ブロック４６
）を作成し、次に遡って親仮想ファイル・システム（ブ
ロック４６）を指すポインタと、ルートｉノード（ｉノ
ード９２、ブロック４８）を指すポインタとを有する、
この仮想ファイル・システムに対するルートｖノード（
ブロック４７）を作成する。「マウント・オーバーされ
る」ポインタが、ルート仮想ファイル・システム（ブロ
ック４１）内のカバーされるＶノード（ブロック４４）
に挿入され、マウント・オーバーされるＶノード（ブロ
ック４４）を指すポインクが新しい仮想ファイル・シス
テムに挿入される。

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

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

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

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

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

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

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

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

この欠点は、ｉノード世代番号を使うことによって防止
される。ｉノード世代番号は、ｉノード中のフィールド
としてディスク上に記憶される。

サーバがあるファイルを削除するとき、そのｉノード世
代番号を増分する。要求がサーバに届いたとき、ファイ
ル・ハンドルは分離され、装置番号とｉノード番号が１
ノードを探し出すのに使われ、その後ファイル・ハンド
ルのｉノード世代番号がｉノードのｉノード世代番号と
比較される。両者が異なる場合、その要求は拒否される
。

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

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

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

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

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

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

第三に、そのファイルを保持するノードがそのｄｆｓ操
作要求を受は取り、そのローカル・ファイル・システム
に対応するｖｎ操作の実行を要求する。

このｖｎ操作からの戻りパラメータを使って、そのｄｆ
ｓ操作に対する戻りパラメータが構築される。

第四に、要求側ノードがサーバ・ノードからｄｆａ操作
回答を受は取り、ｄｆｓ操作戻りパラメータを使って、
元のｖｎ操作要求に対する戻りパラメータを構築する。

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

このシナリオでは第１０図および第１１図を参照する。

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

サーバーノード ディレクトリ ｉノード番号　　　名前　　　ｉノード番号２　　　　
　”　ｕｌｌ　　　　　　　１５１５　　　　ｇａｒｐ
”　　　　９２ ９２　　　　　”ｆｉｌｅ２”　　　　　６７クライエ
ント・ノード ディレクトリ ｉノード番号　　　名前　　　ｉノード番号２　　　　
°’ｅｔｃ”　　　　８６ ８３　　　、　　”ｆｏｏ”　　　　７５マウント・シ
ステム−コールを実施するコードが、マウント・オーバ
ーされるファイル″／　ｅ　ｔｃ／　ｆ　ｏ　ｏ”への
パスをたどるためにＩｏｏｋｕｐｐｎを呼び出す。この
操作が完了したとき、ルート仮想ファイル・システム（
ブロック５１）は、ｅｔｃ／ｆｏｏ″に対するＶノード
（ブロック５６）を含んでいる。このＶノードは、ルー
ト仮想ファイル・システム（ブロック５１）を指すポイ
ンタと、ｉノード７５に対するｉノード・テーブル項目
（ブロック６１）を指すポインタを有する。マウントさ
れるファイルは遠隔ノードにあるため、ｄｆｓマウント
要求が、マウントされる目的物へのパスとしてパス”／
　ｕ　／　ｇ　ｏ　ｒ　ｐ”とともにサーバ・ノードに
発行される。ｄｆｓマウント要求を受は取ると、サーバ
・ノードは、マウントされるファイル″／ｕ／ｇｏｒｐ
”へのパスをたどるため、１ｏｏｋｕｐｐｎを呼び出す
。このルックアップ操作が完了したとき、サーバのルー
ト仮想ファイル・システム（ブロック７１）は／ｕ７ｇ
ｏｒｐ”に対するＶノードを含んでいる。このＶノード
は、ルート仮想ファイル・システムを指すポインタと、
ｉノード９２に対するｉノード・テーブル項目を指すポ
インタを有する。サーバはｉノード中の情報（装置０１
１ノード９２）を用いて、ファイル”／ｕ／ｇｏｒｐ”
に対するファイル・ノ・ンドルを構築する。サーバはｄ
ｆｓマウント要求に対する回答中でこのファイル・ハン
ドルを戻し、次にＶノードとｉノードを解放する。最後
に、クライエントはｄｆｓマウント要求に対する回答中
でこのファイルのハンドルを受は取り、次のような新し
い仮想ファイル・システムを作成するのに必要な操作を
実行する。

ａ）新しい仮想ファイル・システム（ブロック５４）を
作成する。

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

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

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

次に、上記の遠隔マウント（クライエントの／ｅ　ｔ　
ｅ　／　ｆ　Ｑ　Ｏの上にサーバの／　ｕ　／　ｇ　ｏ
　ｒ　ｐ　ｋマウントする）を実行した後、クライエン
ト健プロセスが、ファイル″／　ｅ　ｔ　ｃ　／　ｆ　
ｏ　ｏ　／　ｆ　ｉ　ｌ　ｅ　２″に対して操作するた
めのシステム・コールを発行すると仮定する。下記のシ
ナリオのブロック番号については第１１図および第１２
図を参照されたい。第１１図は初期状態を表し、第１２
図はオーブン操作後のシステム状態を表す。まず、シス
テム・コールを実施するコードが、パスをたどるために
１ｏｏｋｕｐｐｎを呼び出す。１ｏｏｋｕｐｐｎは、ル
ート仮想ファイル・システム（ブロック５１）のルート
Ｖノード（ブロック５２）からスタートし、このＶノー
ドで表されるディレクトリ・ファイル中で名前”Ｕ”を
ルックアップするためにｖｌ−１ｏｏｋｕｐを呼び出す
。ｖｎ　　１ｏｏｋｕｐ　はそのディレクトリ中で、名
前″Ｕ”が１ノード１５と関連していることを見つける
。ｖｎ　　１ｏｏｋｕｐは、ｉノード１５に対するルー
ト仮想ファイル・システム中にＶノードとｉノードを構
築し、このＶノードに対するポインタを１ｏｏｋｕｐｐ
ｎに戻す。

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

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

ｖｎ　１ｏｏｋｕｐはそのファイルを保持するサーバに
ｄｆｓ−１ｏｏｋｕｐを発行し、そのディレクトリを識
別するファイル・ハンドルとルックアップすべき名前（
”ｆｉｌｅ２”）を送る。サーバがｄｆ　ｓ　−１ｏｏ
ｋｕｐを受は取ると、ファイル・ハンドルを使って読み
取るべきディレクトリを識別し、このディレクトリ中で
名前゛。

ｆｉｌｅ２”を探索するためにｖｎ　１ｏｏｋｕｐを発
行する。ｖｎ二１ｏｏｋｕｐはディレクトリを読み取り
、名前”　ｆｉｌｅ　２”に関連するｉノード番号が６
７であることを発見する。ｖｎ　１ｏｏｋｕｐはｉノー
ド６７に対するダミー仮想ファイル・システム中でＶノ
ードとｉノードを構築し、このＶノードを指すポインタ
を１ｏｏｋｕｐｐｎに戻す。ｄｆａ−１ｏｏｋｕｐはｖ
ｎ　１ｏｏｋｕｐから戻されたデータ構造中の情報を用
いて、ｉノード６７によって識別されるファイルに対す
るファイル・ノ・ンドルを構築する。ｄｆｓ−１ｏｏｋ
ｕｐは、ｄｆｓ−１ｏｏｋｕｐ要求に対する回答として
このファイル・ノ・ンドルをクライエントに戻し、■ノ
ードとｉノードを解放する。クライエント中で、見つか
ったファイルに対するＶノード（ブロック５７）と代理
ｉノード（ブロック６３）が作成される。”　ｆｉｌｅ
　２”はこのパスの最後の要素なので、１ｏｏｋｕｐｐ
ｎは見つかったＶノード（ブロック５７）を指すポイン
タをその呼出し側に戻す。システム・コールを実施する
コードは、次にそのファイルに対して要求された操作を
実行する。

Ｅ−２，ファイルの同期モード 本発明が実施された分散サービス・システムでは、第７
図に示すように、各ノードＡ、ＥＳＣにそれぞれローカ
ル・キャッシュ１２Ａ、１２Ｂ。

１２Ｃが存在する。ファイル５がノードＡのディスク２
Ａ上に永久的に存在する場合、ノードＡをサーバと呼ぶ
。サーバＡでは、サーバ・ノードＡで実行されるローカ
ルプロセス１３Ａによるキャッシュ１２Ａの使い方は、
上記の従来技術の例で述べたスタンドアロン・システム
の場合と同様である。しかし、ノードＢ、Ｃで実行され
る遠隔プロセス１３Ｂ、１３Ｃは第１３図に示すように
、サーバ・キャッシュとクライエント・キャッシュを使
って、２段キャッシング方式によりファイル５にアクセ
スする。サーバ・ノードＡは、ディスク２Ａからファイ
ル−ブロック５を入手し、それをサーバ・キャッシュ１
２Ａに記憶する。クライエント・ノードＢは、ネットワ
ーク３を介してサーバ・キャッシュ１２Ａからファイル
・ブロック５を入手する。クライエント・ノードＢは、
サーバ・キャッシュ１２Ａ内にあったファイル・ブロッ
ク５をクライエント・キャッシュ１２Ｂに記憶する。ク
ライエントφノードＢのユーザ・アドレス・スペース１
４Ｂがファイル５からのデータをシークするとき、各ア
クセスごとにネットワーク３を介してアクセスする代り
にクライエント・キャッシュ１２Ｂにアクセスする。ク
ライエント・キャッシュ１２Ｂを使って遠隔ファイル５
にアクセスすると、ネットワークのトラフィック及びオ
ーバーヘッドが節減できるので、パフォーマンスが著し
く改善できる。

アプリケーション・プログラム・レベルでのファイル・
アクセス・セマンティックスを保存しながら高パフォー
マンスを達成するように、分散環境でクライエント−キ
ャッシュ１２Ｂ、！：サーバ・キャッシュ１２Ａの使用
が管理され′る。こうすることにより、スタンドアロン
・システムで走行する既存のプログラムを、修正なしに
分散システムで走行させることができる。ファイル−ア
クセス・セマンティックスは、別のプロセスがファイル
をオープンして、読取りおよび書込みシステム・コール
を発行してファイルにアクセスし、それを修正するとき
、ファイルの整合性を保つ。このファイル・アクセス・
セマンティックスの要件は、どの時間のどのバイト範囲
でも１つの入出力操作だけしか許されず、一度ある入出
力操作が始まると、同じファイルのバイト範囲に対する
別の入出力操作がその入出力操作を強制排除できないこ
とである。

再度第１６図を参照して、その−例を示す。プロセス１
６１がファイル５内のバイト範囲Ｎ１−Ｎ２に対して書
込みシステム・コールを発行した場合、バイト範囲Ｎ　
１−Ｎ　２全体にプロセス１５１がアクセスでき、かつ
バイト範囲Ｎ１−Ｎ２に関する読取り操作が実行されて
いないときだけ、書込みシステム・コールを実行できる
。書込みシステム・コールの実行中、ファイル５のバイ
ト範囲Ｎ１−Ｎ２に関する他のすべての操作は、その書
込みが完了するまで中断される。ローカル・キャッシュ
１２Ａにバイトが書き込まれて始めて、書込みが完了す
る。書込み要求が完了すると、キャッシュ１２Ａに書き
込まれたデータは、他のプロセス１３１−１３Ｎのいず
れかによる次の読取り操作で見えるようになる。

ファイル春アクセス・セマンティックスのもう一つの要
件は、Ｎ１−Ｎ２などのファイルのバイト範囲（１つの
レコードでも、同じ入出力操作でアクセスする関連する
１組のレコードでもよい）が読取り操作で見えるとき、
ファイルのバイト範囲Ｎ１−Ｎ２は、必ずこの範囲に対
する最近の更新を反映した一貫した１組のデータを含ん
でいなげればならない。書込み操作の実行中は、このバ
イト範囲にアクセスできない。こうして、あるプロセス
から出された次の読取り要求では、古（なった更新前の
データではな（、令書かれたデータが読み取られる。

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

第１４図に６つの同期モードを示し、第７図を参照しな
がら説明を行なう。第１のモードはＡＳＹＮＣ同期モー
ド、すなわち非同期モードと呼ばれる。第１４図のブロ
ック１０７に示すように１つのクライエント遠隔モード
のみで実行されるプロセス１５ｃによる読取り／書込み
アクセスのためにファイル５がオープンされている場合
に、ファイル５がこのモード１０４で動作する。このモ
ード１０４では、制御権はすべてクライエント・ノード
Ｃにある。これらの読取り／書込み操作には、サーバー
キャッシュ１２Ａもクライエント・キャッシュ１２Ｃも
使われる。クライエ／ト−キャッシュ１２Ｃから充たせ
ない場合にのみ、読取りまたは書込み操作でサーバ・キ
ャッシュ１２Ａへのアクセスが必要になる。周期的同期
操作てよつて、あるいはクライエント・ノードＣ中での
すべてのプロセス１３Ｃによってファイル５がクローズ
されたとき、または他のデータをキャッシュに入れるス
ペースを空けるためにブロックを書き込まなければなら
ないとき、クライエント・ノード１２Ｃにある修正済み
のデータ・ブロックがサーバ１２Ａに書き込まれる。さ
らに、ファイルがＡＳＹＮＣ同期モードからＦＵＬＬＳ
ＹＮＣ同期モードに変更されるとき、修正済みのデータ
・ブロックがサーバ１２Ａに書き込まれる。

第２のモード１０５はＲＥＡＤＯＮＬＹ同期モード１０
５である。ＲＥＡＤＯＮＬＹ同期モード１０５は、第１
４図のブロック１０８に示すように、１つのノードＣ内
のプロセス１３Ｃからの、または複数のノード８％Ｃ内
のプロセス１３Ｂ１１３Ｃからの読取シ専用アクセスの
ためにオープンされているファイル５に用いられる。こ
のモード１０５では、サーバ・キャッシュ１２Ａとクラ
イエント・キャッシュ１２Ｃの一方または両方が使われ
る。一時に１つまたは複数のブロックに対して、読取り
要求が発行される。同じクライエント・ノードＢまたは
Ｃからの特定のデータ・ブロックに対する他の読取シ要
求は、どれもサーバ１２に行かず、尚該のクライエント
・キャッシュ１２Ａまたは１２Ｃから読み取られる。言
い換えれば、クライエント・キャッシュ１２Ｃまたは１
２Ｂから充たせる場合、読取シ操作でサーバ１２Ａへの
アクセスは必要ではない。まとめると、任意のノードＡ
、Ｂ１Ｃ内のプロセス１３Ａ、１３Ｂ。

１３Ｃのいずれかによる読取シ専用アクセスのためにフ
ァイル５がオープンされている場合に、ファイル５はＲ
ＥＡＤＯＮＬＹ同期モード４２で動作する。

第３のモード１０６はＦＵＬＬＳＹＮＣ同期モードであ
る。ＦＵＬＬＳＹＮＣ同期モード１０６は、第１４図の
ブロック１１１で示すように、サーバ・ノードＡ内のプ
ロセス１゛３Ａによる書込みアクセスのためにオープン
されているファイル５に用いられる。この同期モード１
０６は、第１４図のブロック１０９．１１０で示すよう
に、サーバ・ノードＡおよび他の少なくとも１つのノー
ドＢ％Ｃでファイル５がオープンし、かつ少なくとも１
つのプロセス１３Ａ１１３Ｂ、１３Ｃで書込みアクセス
のためにファイル５がオープンされている場合にも用い
られる。一般に複数のノードでファイル５がオープンし
、それらのノードのうちの１つで書込みアクセスのため
にファイルがオープンしている場合、そのファイルはＦ
ＵＬＬＳＹＮＣ同期モードである。ＦＵＬＬＳＹＮＣ同
期モード１０６では、クライエント・キャッシュ１２Ｃ
または１２Ｂは迂回し、サーバ・キャッシュ１２Ａだけ
が用いられる。読取り操作と書込み操作はすべてサーバ
１２Ａで実行される。

第７図の分散ネットワーキング環境１では、大部分のフ
ァイル５は、ＲＥＡＤＯＮＬＹ同期モード１０５（第１
４図）で複数のノードＡ、　Ｂ”、Ｃでのプロセス１３
Ａ、１３Ｂ１１３Ｃによる読取専用アクセスのためにオ
ープンしたり、あるいはＡＳＹＮＣＨ同期モード１０４
で１つのノードで更新のためにオープンしたりする方が
、ＦＵＬＬＳＹＮＣ同期モード１０６で複数のノードで
実行されるプロセスによる読取シ／書込みアクセスのた
めにオープンするよりも頻繁である。ＲＥＡＤＯＮＬＹ
同期モード１０５でもＡＳＹＮＣ同期モード１０４でも
、クライエント・キャッシュ１２Ｂ（第１３図）を使用
するため、遠隔読取１）／書込みのファイル５にアクセ
スする応答時間が著しく減少シ、全体的システム・パフ
ォーマンスが向上する。

第１５図に示すように、ＦＵＬＬＳＹＮＣ同期モードで
は、クライエント・キャッシュは使われない。クライエ
ント・ノードＢは、各読取シおよび書込みのたびにサー
バＡからネットワーク３を介してファイル５にアクセス
する。このモードでは、読取り／書込み応答時間は増加
するが、サーバＡに常駐する対応するファイルと一緒に
更新されていないファイル５をクライエント・ノードが
ローカル・キャッシュに保持しないので、ファイル・ア
クセス・セマンティックスは保存される。

この３つのモードを使ってクライエント・キャツシ二の
使用を管理すると、読取り／書込み応答速度が全体的に
平均して増加し、かつファイルの整合性が保たれるため
に、全体的システム・パフォーマンスが最適になる。あ
る状況ではクライエント・キャッシュを使うので読取り
／書込み応答時間が減少し、別の状況ではクライアント
・キャラシュラ使ワないので、ファイル・システム・セ
マンティックスが保存される。

ファイルの同期モードは、どのノードでファイルがオー
プンになっているか、およびファイルが読取シのために
オープンになっているのか、それとも書込みのためにオ
ープンになっているのかだけでなく、ファイルの存在す
る装置がロー（ｒａｗ）アクセス・モードでオープンに
なっているかどうかにも依存する。ある装置に対するロ
ー・アクセスとは、装置２人内のデータ・ブロックＬＢ
Ｎ　１（第１３図）がアクセスされるという意味である
。

すなわち、装置２Ａの読取シおよび書込みは、装置２人
のデータ・ブロックＬＢＮ１に対する読取シおよび書込
みである。そのデータ・ブロックがどのファイルに属す
るのか重要ではない。装置２Ａは、サーバ・ノードＡで
のプロセス１３１−１３Ｎからのロー・アクセスのため
にオープンすることができるが、遠隔ノードＢ、Ｃから
のロー・アクセスのためにオープンすることはできない
。

第１３図を参照すると、キャッシュ１２Ａは、第２図に
関して先に説明したスタンドアロン・システムと同様に
、装置２人のブロックＬＢＮ１として管理される。サー
バＡは、サーバ・キャッシュ１２Ａを装置２人内の論理
ブロックＬＢＮＢ：して見る。クライエント嚇ノードＢ
は、ファイル５が装置２人上のどこにあるのか知らない
。クライエント−ノードＢが知っているのは、装置２Ａ
ノブロック番号Ｎ１にあるファイル５にアクセスしてい
ることだけである。クライアント・キャッシュ１２Ｂは
、データをファイル５の論理ブロックＮ１として扱う。

サーバ・キャッシュ１２Ａ内では、データは装置２人の
論理ブロックＬＢＮｉとして扱われる。データをこのよ
うに扱う際に、サーバＡは、データがロー（ｒａｗ）装
置としての装置に書き込まれ、かつそのファイルの装置
に書き込まれたブロックと同じブロックに対する読取シ
が別にあった場合に、新しく書き込まれたデータがその
読取りで見えることを保証することができる。このため
、ファイル・システム・セマンティックスが保存される
。

第１３図に示すようにクライエント・ノードＢでファイ
ルがアクセスされておシ、かつファイルがＡＳＹＮＣモ
ードまたはＲＥＡＤＯＮＩ、Ｙモードの場合、クライア
ント・オペレーティング・システム１１Ｂは、システム
コールＲＥＡＤ　（ファイル記述子、Ｎ１）１６中のフ
ァイル記述子とファイル内のバイト範囲を、装置番号お
よび装置内の論理ブロック番号に変換しない。クライア
ントは、ファイル記述子とバイト範囲を、ファイル・ハ
ンドル、ノード識別子、およびファイル内の論理ブロッ
ク番号に変換する。クライエント・キャッシュ１２Ｂ内
にハ、ファイル拳ハンドル、ノード識別子、およびファ
イル内の論理ブロック番号によシ指定されるブロック１
７が存在する。クライエントのアプリケーション・プロ
グラム４Ｂから読取シ要求１６が発行されると、その読
取シ要求は、ファイル記述子およびファイル内のバイト
範囲と共にオペレーティング・システム１１８に向う。

次にオペレーティング・システム１１Ｂはクライエント
・キャッシュ１２Ｂを見る。ファイル・ハンドル、ノー
ド識別子、およびファイル内の論理ブロック番号がそこ
にある場合、キャッシュ１２Ｂが読み取られる。そこに
ない場合、その読取り要求はサーバに送られる。サーバ
は次にファイル・ハンドルとファイル内の論理ブロック
番号を装置番号と装置内の論理ブロック番号に変換する
。この変換が必要なのは、サーバ・キャッシュ１２Ａが
スタンドアロン・システムと同様に、装置番号と装置内
ブロック番号によって管理されるためである。読取シ要
求はサーバに送られた後、第２図に関して先に説明した
スタンドアロン・システムで読取シ要求がそれ自体のア
プリケーション・プログラムから来ている場合と同様に
扱われる。

クローズされているファイルには、同期モードがない。

しかし、あるプロセスによってファイルが始めてオープ
ンされると、第１６図に示すように下記の通シ、ファイ
ルの同期モードが初期設定される。ファイルが存在する
装置（Ｄ）がクローズされている、すなわち特別装置と
してオープンされていす且つファイルが１つの遠隔ノー
ドでの書込みアクセスに対してオープンされる場合、フ
ァイルの同期モードはＡＳＹＮＣモード１０４に初期設
定される。ファイルが存在する装置がクローズされ、１
つまたは複数のノードでの読取り専用アクセスのために
、ファイルがオープンにされる場合、あるいは装置もフ
ァイルも読取シ専用アクセスのためにオープンされる場
合、ファイルの同期モードはＲＥＡＤＯＮＬＹ　１０５
である。ファイルが存在する装置が読取シ／書込みアク
セスのためにブロック特別装置としてオープンになって
いる場合、あるいはファイルが複数のノードでオープン
シ、少なくとも１つのオープンが書込みに対するもので
ある場合、ファイルの同期モードはＦＵＬＬＳＹＮＣモ
ード１０６に初期設定される。

ブロック特別装置とは、その装置に対するロー・アクセ
スがあるという意味である。

ファイルがあるモードに初期設定されても、条件が変わ
れば、ファイル・モードも変わることがある。第１６図
で線１１８ないし１２６によって示すようなあるモード
から別のモードへの移行が、下記の条件で起こり得る。

ファイルが現在ＡＳＹＮＣモード１０４であり、そのフ
ァイル（Ｆ）がオープンになっているノードの数が２以
上になった場合（１２４）、第１６図で線１１９によっ
て示すように同期モードはＦＵＬＬＳＹＮＣモード１０
６に変わる。また、ファイルが存在するブロック特別装
置りのオープンがある場合（１２５）、同期モードはＡ
ＳＹＮＣモード１［］４からＦＵＬＬＳＹＮＣモード１
０６に変わる。ファイルのクローズ動作については、そ
のクローズ動作がファイルの最終クローズではな（、フ
ァイルは書込みに対しては依然としてオープンである場
合は、モード変更は起こらない。しかし、そのクローズ
動作がそのファイルの書込みアクセスに対する最終クロ
ーズであり、残っているオープンはすべて読込みアクセ
スに対するものである場合（１２６）は、線１２１で示
すようにＲＥＡＤＯＮＬＹモード１０５が新しいモード
になる。そのクローズ動作がそのファイルの最終クロー
ズである場合、同期モードはない。

ファイルが現在ＲＥＡＤＯＮＬＹ同期モード１０５であ
り、ファイル・オープン動作がある場合、そのオープン
が読取りに対するものなら、モード変更はない。しかし
、そのオープンが書込みに対するものなら、＋１１２０
で示すようにすべてのオープンが１つのクライエント・
ノードで行なわれる場合（１２７）、ＡＳＹＮＣ％−ド
１０４が新しい同期モードとなる。そうでなければ、同
期モード＆！ＦＵＬＬＳＹＮＣモー）’１０６である。

さらに、ファイルが存在する装置が読取り／書込みアク
セスに対してオープンされる場合（１３０）、そのファ
イルの新しい同期モードはＦＵＬＬＳＹＮＣモード１０
６である。クローズ動作について、そのクローズがその
ファイルの最終クローズである場合、そのファイルの同
期モードはない。クローズ動作の後、ファイルが１つま
たは複数のノードで依然としてオープンになっている場
合、同期モードに変更はない。

ファイルが現在ＦＵＬＬＳＹＮＣモード１０６であり、
そのファイルに対して別のオープンがある場合、あるい
はファイルが存在する装置がオープンされる場合、同期
モードの変更はない。ファイルのクローズ動作の後、１
つの遠隔ノードで読取り／書込みアクセスのためのオー
プンが残っており、かつそのファイルが存在するブロッ
ク特別装置がオープンされていない場合、線１１８を介
してブロック１４１で示されるよ゛うに、同期モードは
ＡＳＹＮＣ同期モード１０４に変わる。ファイルが存在
するブロック特別装置がオープンされず、かつ線１２２
上のブロック１４２で示されるように、そのファイルが
１つまたは複数のノードでの読取り専用アクセスに対し
てオープンされる場合、あるいはファイルが存在するブ
ロック特別装置が読取り専用アクセスに対してオープン
され、かつそのファイルが読取り専用アクセスに対して
オープンされる場合、同期モードはＦＵＬＬＳＹＮＣモ
ード１０６からＲＥＡＤＯＮＬＹモード１０５に変わる
。

ファイルおよび装置に対するすべてのオープン動作およ
びクローズ動作は、サーバΦノードで解決される。サー
バは、同期モードを変更する可能性がある任意の動作を
実行するとき、オープン・ファイルの同期モードを決定
する。また、サーバは同期モードの変更を実行する。サ
ーバがそのファイルに対する新しいオープンまたはクロ
ーズを獲得するとき、そのファイルの同期モードの変更
がトリガされることがある。必要とされる同期モードが
現在のモードではない場合、サーバはそのファイルがオ
ープンになっているすべてのクライエントに「同期モー
ド変更」遠隔手順コール（ｒｐｃ）を送る。ファイルが
初めてオープンされた後、そのファイルをオープンした
クライエントには、そのファイルのモードが知らされる
。モードがＡＳＹＮＣまたはＲＥＡＤＯＮＬＹである場
合、クライエントは、第１５図に示すように、読取りの
ため、あるいはＡＳＹＮＣモードの場合は書込みのため
にも、フライエン）・キャッシュの使用を開始すること
ができる。クライエントは、通信リンクを介してサーバ
に対して読取りまたは書込みを行なう必要はない。第１
５図に示すようにモードがＦＵＬＬＳＹＮＣモードであ
る場合は、クライエント・キャッシュは使われず、クラ
イエントは通信リンク３を介してサーバに対し読取りま
たは書込みを送る必要がある。

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

Ｅ−６，ロック ＵＮＩＸオペレー亨インダイングテムにおいて、プロセ
スは、他のプロセスがアクセスしないように、ファイル
中のバイト範囲をロックする事ができる。そのようなロ
ッキングに関するサポートは、ＵＮＩＸオペレーティン
グ・システムのバージョン毎に違っているが、多くのイ
ンプリメンテーションにおいてはロックはファイルのバ
イト範囲に適用される。ファイル全体にわたるロックは
ファイルをロックし、しばしばファイル・ロックと呼ば
れる。規約により、長さゼロ・バイトの範囲をロックす
る要求は、範囲の始めからファイルの終りまでの全ての
バイトをロックすべき事を示す。

これにより、プロセスがファイルに付加的なバイトを追
加する前にファイルをロックし、そして新しいバイト全
部に対して制御を維持する事が可能となる。任意のバイ
ト範囲にわたるロックはしばしばレコード・ロックと呼
ばれるが、本明細書中ではファイル及びレコード（バイ
ト範囲）に対する全てのロックは単にロックと呼ぶ。

ＡＩＸオペレーティング・システムにおいては、１０ｅ
ｋｆ（２）及びｆｃｎｔｌ（２）が読取ロック及び書込
みロックの両者に関するサポートを与えている。書込み
ロックは排他的なロックである。即ち、もしファイルの
ある範囲が書込みロックされると、いずれの種類の他の
ロックもその範囲には存在する事ができない。読取ロッ
クは共有的ロックである。即ち、任意の数の重なり合っ
た読取ロックをファイルのセグメントにかげる事ができ
る。既存の読取ロックは他の読取ロックを阻止する事は
ないが、他の書込ロックは阻止する。また既存の書込ロ
ックは重なり合った範囲上の他の全てのロックを阻止す
る。

ＡＩＸオペレーティング・システムにおいて、ファイル
は強制的ロッキング・モード又は勧告的ロッキング・モ
ードのいずれかの状態にある。ファイルのロッキング・
モードはｃｈｍｏｄシステム・コールを用いてファイル
の許可コードを変更する事によって制御される。強制的
ロッキング・モードのファイルに対するロックは強制的
ロックと呼ばれ、勧告的ロッキング・モードのファイル
に対するロックは勧告的ロックと呼ばれる。勧告的ロッ
クはファイル又はレコードに対して絶対的な保護は与え
ない。というのはそれは、ロックされたファイル又はレ
コードをプロセスが読み書きするのを妨げないからであ
る。勧告的ロックは１ｏｃｋｆ（２）又はｆｃｎｔｅ（
２）に対する呼び出しの結果にしか影響せず、従ってそ
れは共有ファイルに対するロックの状態を１ｏｃｋｆ（
２）又はｆｃｎｔｌ（２）を用いて照会するように、協
調的に動作するプロセスによって使用されなければなら
ない。勧告的ロックの利点は、通常の読取り又は書込み
動作の間にカーネルによって質問されなくてよい点であ
る。強制的ロックは、おそらく、より頻繁に使用される
。

強制的ロックは、勧告的ロックのように、１ｏｃｋｆ　
（２）及びｆｃｎｔｌ（２）に対するその後の呼び出し
に影響を与えるが、それに加えて、ｒｅａｄ（２）、ｗ
ｒｉｔｅ（２）、ｏｐｅｎ（２）、ｃｒｅａｔ（２）、
ｆｃｌｅａｒ（２）、ｆｔｒｕｎｃａｔｅ（２）及びｓ
ｈｍａｔ（２）の各々により、ファイルの読取り又は書
込みロックされた部分が変更されず、且つファイルの書
込みロックされた部分がアクセスされない事が保証され
る。

ｆｃｎｔｌ（２）システム・コールの３つの異なったコ
マンドがロッキングに関係している。

Ｆ　　ＧＥＴＬＫ：これは、ｆｃｎｔｌ（２）の引数に
よって記述されたロックを 呼び出し例プロセスに許可−ｒ るのを妨げる、最初の既存の ロックを見い出す。

Ｆ　　５ＥＴＬＫ：これは、ｆｃｎｔｔ（２）の引数に
よって記述されたロックを 呼び出し側プロセスに許可す る。もし既存のロックが要求 と干渉するためにロックが許 可できないならば、その既存 の「ロックの記述を返す。

Ｆ　　５ＥＴＬＫＷ：これはｆｃｎｔｌ（２）の引数に
よって記述されたロックを呼 び出し側プロセスに許可する。

もし既存のロックが要求と干 渉する事によってロック７５ｆ許 可できないならば、デッド口 ツクをチェックし、もしデッ ドロックの原因がなければ、 呼び出し側プロセスを待機さ せる。干渉を起こすロックが クリアされる毎に、カーネル は再び、干渉するロックを探 索する事によって、要求され たロックを確立しようと試み る。プロセスは永久に待機す る事も可能である。単一ノー ド上のファイル・ロックにし か関係しないデッドロックは 検出されても、複数ノード上 のファイル−ロックによるデ ラドロックが生じ得る。また、 プロセスはデッドロックを生 じなくても、干渉的ロックが クリアされた時に既に他の干 渉的ロックがセットされてい る事により、不定期間、ロッ クを取得できない事もある。

これらのコマンドの各々に関して、構造体、即ちロック
を記述するｆｌｏｃｋ構造体へのポインタがｆｃｎｔｌ
（２）コールの引数として与えられる。

ｆｌｏｃｋ構造体は下記の形成を有する。

５ｔｒｕｃｔ　　ｆｌｏｃｋ　　（ ｓｈｏｒｔ　　　１．、Ｊｙｐｅ　　；５ｈｏｒむ　　
ｌ−ｗｈｅｎｃｅ　　；ｌｏｎｇ　　　　ｌ　　５ｔａ
ｒｔ　　；ｌｏｎｇ　　　　１　１ｅｎ　　； ｕｎｓ′ｉ’ｇ＋）ｅｄｚｌｏｎｇ　ｌ　５ｙｓｉｄ　
；５ｈｏｒｔ　　　１　　ｐｉｄ　　； 第１８図に示すようなｆｌｏｃｋ構造体のフィールドは
下記の意味を有している。

１　　ｔｙｐｅ　２００は、ロックが読取ロックか又は
書込ロックかを示すために使われる。

ｌ　　ｗｈｅｎｃｅ２０５は、このロックに関するバイ
ト範囲がファイルの開始点を基準としてそれに相対的に
定められた位置で始まるならば０であり、範囲が現在の
位置を基準とする位置で始まるならば１であり、そして
範囲がファイルの終りを基準とする位置で始まるならば
２である。

ｌ　　５ｔａｒｔ２［３１は、１　　ｗｈｅｎｃｅによ
り指定された位置に対する、ロックすべき範囲の開始点
のオフセットである。

１　１ｅｎ２０２は、ロックすべき範囲のサイズである
。

ｌ　　ｐｉｄ２０４は、Ｆ　　ＧＥＴＬＫコマンドに応
答してｆｃｎｔｌにより返される、ロックの所有者のプ
ロセスｉｄでアル。

ｌ　　５ｙｓｉｄ２０３は、ロックの所有者が存在する
ノードのノードｉｄである。

ロックはオープンしたファイルに伴なうものであり、ロ
ック情報をオープン・ファイルに関する他の情報と共に
、ファイルのｉノード構造中に置（のは自然な事である
。ＡＩＸオペレーティング・システムではこれは非実際
的である。というのはｉノード構造は固定サイズを有し
、ファイルのロックに伴なう可変長のデータを含む事が
できないからである。その代りに、ロック情報は、ｉノ
ード構造２１０（第１９図）から到達可能であるがその
中には含まれないよ５に記憶される。ファイル・ロック
に付随するデータは、ｉノード構造２１０のフィールド
２２０によって指し示される連鎖リスト中に保持される
。この連鎖リスト２２１．２２２．２２３は、ロック・
テーブルと呼ばれるテーブル中のエントリのリストであ
る。ロック・テーブルの各エントリは下記の形式を有す
る。

５ｔｒｕｃｔ　　ｆｉｌｏｃｋ　　（ ｓｔｒｕｃｔ　　ｆｌｏｃｋ　　ｓｅｔ　　’ｕｎｉｏ
ｎ　　（ ｉｎｔ　　ｗａｋｅｆｌｇ　　； ５ｔｒｕｃｔ　　（ ｕｎｓｉｇｎｅｄ　　ｌｏｎｇ　５ｙｓｉｄ　　；５ｈ
ｏｒｔ　　　ｐｉｄ　　； ｌ　　ｂｌｋ　　； ）ｓｔａｔ　　； ５ｔｒｕｃｔ　　ｆｉｌｏｃｋ　　＊ｐｒｅｖ　　；５
ｔｒｕｃｔ　　ｆｉｌｏｃｋ　　＊ｎｅｘｔ　　；ｆ　
ｉ　１ｏｃｋ構造体２２１．２２２．２２３は、各々現
在例らかのロックをセットしているファイル毎に、別個
のリストの形に連鎖される。リストの先頭要素はそのフ
ァイルのｉノード構造体２２０のメンバーによって指示
される。ｆｉｌｏｃｋ構造体の１つの付加的なリストが
ＡＩＸオペレーティング・システムによって維持される
。このリストはスリーブ脅リスト２’３０，２１１．２
６２（第２０図）であり、スリーブ・ロック２２９によ
ｒ［示される。スリーブ・リストは、現在ロックを確立
しようとしているが既存の、干渉的なロックによりそう
する事を妨げられている（従ってスリーブ状態にある）
プロセス毎に１つのエントリを有している。

ファイル上のロックの連鎖リストの要素２２１．２２２
．２２３として使われている時、ｆｉｌｏｃｋ構造体の
メンバーは下記の意味を有する。

ｓｅｔは、ロックされた領域の記述、並びにロックを所
有しているプロセスのノードｉｄ及びプロセスｉｄを含
むｆｌｏｃｋ構造体である。

５ｔａｔ、　ｗａｋｅｆｌｙは、プロセスがスリーブ状
態にあって、このエントリに対応するロックが解除され
るのを待機して〜・る時にセットされる。

５ｔａｔ、　ｂｌｋ、　５ｙｓｉｄ及び５ｔａｔ、　ｂ
ｌｋ、　ｐｉｄは使用しない。

ｐｒｅｖ及びｎｅｘｔは（二重連鎖）リスト中の先行及
び後続要素へのポインタである。

ｆｉｌｏｃｋ構造体のメンバーは、スリーブ・リスト２
３０．２６１．２３２の要素として使われる時には、下
記の意味を有する。（第２１図参照）。

ｓｅｔ　３００は、スリーブ状態のプロセスがロックし
ようと望んでいる範囲の記述、並びにスリーブ状態のプ
ロセスのプロセスｉｄ及びノードｉｄを含むｆｌｏｃｋ
構造体である。

５ｔａｔ、　ｗａｋｅｆ　ｌｙ　３０４は使用されない
。

５ｔａｔ、　ｂｌｋ、　５ｙｓｉｄ　３０４は、ｓｅｔ
のメンバーによって記述される要求を阻止しているロッ
クを所有しているプロセスのノードｉｄである。

５ｔａｔ、　ｂｌｋ、　ｐｉｄ　３０１は、ｓｅｔのメ
ンバーによって記述される要求を阻止しているロックを
所有しているプ・ロセスのプロセスｉｄである。

ｐｒｅｖ　３０２及びｎｅｘｔ　３０３は、　（２重連
鎖）リスト中の先行及び後続要素へのポインタである。

ＡＩＸオペレーティング・システムにおいてロックを行
なうために使う事のできる２つの異なったシステム・コ
ールが存在する。その両者はｒｅｃｌｏｃｋと呼ばれる
ルーチンを呼び出す事によって実施される。このルーチ
ンは次のように動作する。

（ｒｅｃｌｏｃｋ　） 入カニ １ノード・ポインタ、即ちロックすべきファイルに関す
るｉノードへのポインタ ファイル・ポインタ、即ちロックすべきファイルに関す
るファイル構造へのポインタ、ファイル構造はファイル
のオーブン・モード及び現在のオフセットを含んでいる 要求、即ちロック又はアンロックすべき範囲の記述を含
むｆｌｏｃｋ構造体へのポインタ出カニ ロック要求が許されると０を返し、さもなければエラー
表示を返す 手続： ／宋要求を標準形式にする＊／ 範囲（ｌ　ｗｈｅｎｃｅ、　１ｓｔａｒｔ、及びｅ−１
ｅｎ　）を、１　５ｔａｒｔがファイルの開始点に対す
るものになるような形に変換する；／＊ロック・リスト
を取得する＊／ ロック・リストはｉノード構造体のメンバーによって指
し示される； ／＊要求を試みる＊／ ｉｆ要求がアンロックである ｒｅｃｌｏｃｋを要求したプロセスによって所有されて
いるロックを探すためにロック・リストを走査する： 要求の範囲と交わるロックの部分をアンロックする； アンロックされた部分を含むロック範囲上でスリーブ状
態にあったプロセスを起こす；０を返す／＊成功＊／ ／＊そうでなければ、要求はロックにセットされている
べきである＊／ ／＊ファイル上の干渉的なロックをテストする＊／ ｗｈｉ１ｅ干渉的なロックが存在する ／＊デッドロックをチェックする＊／ ｉｆ要求がデッドロックを生じさせる エラーを返す； ｉｆロック・テーブルに余地が存在しない／＊即ち呼び
出し側プロセスをスリープさせられない＊／ エラーを返す； ／＊呼び出し側プロセスをスリーブ状態＊／／＊にする
；＊／ ／＊ロック・テーブルのエントリはスリ＊／／＊−プ・
リストに連鎖される；＊／ ／＊スリーブ・リストは、スリーブ状態＊／／＊にあっ
て、ロック範囲がアンロック＊／／＊されるのを待機し
ている各プロセス＊／／＊毎に１つのエントリを有する
；＊／／＊スリーブ・リスト上のロック・チー＊／／＊
プル・エントリは、スリーブ状態の＊／／＊プロセス及
びそれが待機している口＊／／＊ツクを所有するプロセ
スを識別する；＊／スリーブ・リストにエントリを付加
する；／＊こうして、走行中のプロセスをスリ＊／／＊
−ブさせる用意がほぼ整っだ；＊／／＊シかし、最初に
、もしｉノードが口未／／＊ラックれていればそれを解
放する；＊／／＊これは、強制的ロッキング・モード＊
／／＊でのファイルの読み書きの間にこの＊／／＊コー
ドが実行されている場合に起き＊／／＊得る；＊／ ｌｆ　ｉノードがロックされている ｉノードを解放する； ／＊最終的に準備が整う＊／ スリーブさせる、割り込みを捕獲する；ｉｆスリーブか
らの割り込み エラーを返す； ｅ　１　ｓ　ｅ　／　＊正・規のめざめ；＊／／＊干渉
的なロックは終了した；＊／ ／＊もうスリーブの必要はない；＊／ スリーブ・リストからエントリを除去 する； ｉｆ　ｉノードが以前ロックされていたｉノードを再ロ
ックする； ／＊ループ・バックしリスト全体を再び＊／／＊走査す
る；＊／ ／＊ススリーブ中ロックが変化した可能＊／／＊性があ
る；＊／ イ ／＊今や、干渉的なロックは存在しない＊／新しいロッ
クをファイルのロック・リストに付加する： ／＊いくつかのエントリが併合された可能性に注意＊／ ｉｆ要求がロック・リストに付加できた０を返す；／＊
成功＊／ ｌｓｅ ／＊エラー、おそらくロック・テーブル＊／中に余地が
ないのであろう　　　　＊／エラーを返す： 分散環境においては、２以上のノードのプロセスが同時
に１つのファイルをオープンする事ができる。ロックが
付加又は除去される毎に、ファイルのロック・リスト全
体が走査及び更新されなければならない。そのようなシ
ステムの単純な設計はロックφリスト及びスリーブ・リ
ストをファイルのサーバ上に保持する事である。従って
ロックが行なわれる毎に、（そのサーバにローカルなプ
ロセスがロックを行なうのでな−げれば）ロック・リス
ト及びおそらくスリーブ・リストに対して必要な活動を
行なうために要求がサーバに送られる。

この単純な設計に基づいたシステムは、ファイルをオー
プンしている唯一のプロセスが１つの非サーバ・ノード
で走行しているものだけである時に、不必要なネットワ
ーク・トラフィック及び遅延という欠点を有する。

最も頻繁には、ＡＩＸオペレーティング・システム中の
ファイルは１つのプロセスによってオープンされる。プ
ロセスがクライエント（非サーバ）ノードで走行してい
るならば、上述の単純な設計は遠隔サーバとの通信の不
所望のコストを導入する。時々、ＡＩＸオペレーティン
グ・システム中のファイルは、分散環境中の異なったノ
ードに存在し得る多くの異なったプロセスによって同時
にオープンされる。ＡＩＸオペレーティング・システム
におけるファイル及びレコードのロックに関して何らか
の設計を行なうと、単純で一般的な場合には上記単純な
設計のコストを避は且つより一般的でないより複雑な場
合には効率的でなくとも正しく動作するであろう。本明
細書中で述べる発明は、これらの相反する目的を達成す
る。

この問題に対する１つの解は、スリーブ・リスト及びロ
ック・リストのコピーを、それが有用であるような全て
のノードにおいて保持する事である。この方式に伴なう
問題は、１つのリストがマスクに指定されなければ、変
更が行なわれるにつれてリストが互いに矛盾を含むよう
になる事である。しかしマスクを指定した場合には、全
ての変更がマスクとの間で通信されなければならず、単
純な設計を上回る利益はない。また、各リストに対する
変更を、そのリストのコピーを持つ他のノードとの間で
注意深く交渉するようにすると、ネットワーク・トラフ
ィックに付加的な不所望のオーバーヘッドが生じ、ロッ
クが変更される毎に遅延を生じる。

本明細書で説明する発明は、各ファイル毎にロック・リ
ストの１つだけのコピーを保持する。ロック・リスト情
報は、異なったノードに存在する複数のプロセスがファ
イルをオープンしている時にはサーバに保持され、また
ファイルをオープンしている全てのプロセスが単一のノ
ードで走行しているという頻繁な場合にはロック・リス
ト情報は非サーバ・ノードに保持される。複数コピーの
無矛盾性の問題は回避され、且つ全てのオープンが１つ
のノードに関するものである普通の場合には各ロック動
作のためにネットワーク・メツセージを必要とする事の
非効率さも避けられる。

このアーキテクチャには２つの重要な含意が存在する。

第１に、プロセスはロックをセット又はテストするため
に遠隔手続き呼出しくＲＰＣ）を使用しなければならな
い。これらのＲＰＣはファイルのサーバ上で走行する。

第２に、ファイルの同期モードが変化する時、ファイル
のロック・リストはクライエントからサーバへ又はその
逆方向に移動されなければならない。ｉノードのロック
・テーブルのエントリはｉノードのファイルのセグメン
ト上のロックに対応する。ロックを表現するために、ロ
ック・リストのエントリは、ロックされたバイト範囲、
ロックの型（読取又は書込）、ロックの所有者を識別す
る情報を含まなければならない。

スタンド・アロンのＵＮＩＸオペレーティング・システ
ムでは、ロックを確立しようとするプロセスは、最初に
既存のロックがクリアされるのを待たなければならない
。待機する（スリーブ状態になる）前に、プロセスは待
機を行なった場合にデッドロックが生じない事を保証す
るためにスリーブ・リストをチェックしなげればならな
い。待機中のプロセスは、それが待機しているロック・
テーブルのエントリを指すためにｐｒｏｃテーブルのＷ
　　ＣＨＡＮフィールドを使用する。

分散システムにおいて、待機は容易な事ではない。阻止
しているロックを待機するために２つの方法がある。第
１は、直接的に、ローカルのロック−リスト・エントリ
に対して、第２は間接的にサーバのロック・リスト・エ
ントリに対して待機する事である。直接的待機は上述の
スタンド・アロンの待機と同一である。それは、ロック
・テーブル中でローカルに生じたロックをプロセスが待
機しなければならない時に使われる。ファイルに関する
ロック・リストは１つのノードにしか存在しない事に留
意するのは重要である。呼び出した側のプロセスが同じ
ノード中に存在しなげれば、ロック・リストはサーバ中
に存在する。そのロック・リストが遠隔ノード（サーバ
）中に存在するファイルの領域をロックしようとするプ
ロセスは、間接的にロックを待機する。この間接的な待
機は、サーバテトランザクジョン・プログラムを起動し
ロックを待機するＲＰＣによって行なわれる。スタンド
・アロンのＵＮＩＸオペレーティング・システムでは、
ロックが許可されるか又は待機がデッドロックを生じ得
るならば、プロセスは決してスリーブ状態に入らない。

分散型システムでは、ロック・テーブルと同じノードに
存在しない、ロック要求を行なうプロセスは、少なくと
も短期間、常にスリーブ状態に入る。ＲＰＣに関して返
答を待機している間、それはそうしなければならない。

不必要なネットワーク通信を避けるために、ｄｆｓ−ｆ
ｌｏｃｋ　　ＲＰＣからの返答を待機するプロセスは、
ＲＰＣトランザクション嗜プログラムが阻止的なロック
に関して待機しているのでそれが待機を行なっているの
か又は阻止的なロックは何も見つからなかったがサーバ
中でトランザクション・プログラムがまだ終了していな
いので待機しているのかを知らないであろう。

他にロックが存在しないファイルにロックが最初にかけ
られる時、ファイルがＦＵＬＬＳＹＮＣＨモード又はＲ
ＥＡＤＯＮＬＹモードでオープンしていれば、サーバの
ロック・テーブルに記入が行なわれ、またファイルがＡ
ＳＹＮＣＨモードでオープンしていれば、クライエント
のロック・テーブルに記入が行なわれる。オープン、ク
ローズ又はｃｈｍｏｄシステム・コールがファイルの同
期モードを変更しない限り、付加的な記入は同じテーブ
ルに行なわれ、−緒に連鎖される。（ｃｈｍｏｄはファ
イルを強制的ロッキング・モードにする事によってファ
イル同期モードを変更し得る事に注意されたい。強制的
ロッキング・モードのファイルは、ファイルをオープン
しているプロセスの数にかかわりなく、ＦＵＬＬＳＹＮ
ＣＨモードであるかのように扱われる。）例えばオープ
ンによりファイルの同期モードが変化する時、ロック・
リスト及びスリーブ状態のプロセスは１つのノードから
他のノードに移動される。

強制的ロッキング−モードのファイルはＦＵＬＬＳＹＮ
ＣＨ同期モードを有し、他のＦＵＬＬＳＹＮＣＨファイ
ルと同様に、強制的ロッキング・モードのファイルに関
するロック・リストはサーバに保持される。

本発明において考慮しなければならない点は、いつロッ
ク・リスト情報がノード間で移動されるか、どのように
してロック・リスト情報がノード間で移動されるか、及
びどのようにしてロックを待機している間スリープして
いるプロセスを管理するかの問題である。分散環境でフ
ァイル及びレコードのロックを行なうためにＡＩＸで使
用されるデータ構造は上述のスタンド・アロン動作に関
して述べたものと同じであるが、ロックを付加及び除去
するために使われる手続きは分散システムでは異なって
いる。クライエント・ノード、即ちロックすべきファイ
ルを含んでいない分散環境中のノード上のシステム・コ
ール１ｏｃｋｆ及びｆｃｎｔｌは、ｒａｉ’ｘ　　ｆｌ
ｏｃｋへの呼び出しを用いてインプリメントされる。ル
ーチンｒａｉｘ　ｆｌｏｃｋは下記のように動作する。

（ｒａｉｘ　　ｆｌｏｃｋ　） 入カニ Ｖノード・ポインタ、ロックすべきファイルに関するＶ
ノードへのポインタ ファイル・ポインタ、ロックすべきファイルに関するフ
ァイル構造体へのポインタ、ファイル構造体は現在のオ
フセット及びファイルのオープン・モードを含んでいる 要求、ロック又はアンロックすべき領域の記述を含むｆ
Ｌｏｃｋ構造体へのポインタ出カニ ロック要求が許可されると０を返し、さもなければエラ
ー表示を返す 手続： ／＊＊＊金標準形式にする＊／ 要求中の範囲（１ｗｈｅｎｃｅ、１　５ｔａｒｔ。

及びｌ　　１ｅｎ）を、１　５ｔａｒｔがファイルの開
始点に対するものであるような形式に変換する； ／＊エラー又は終了まで試行を続ける＊／ｗｈｉｌｅ（
ＴＲＵＥ） ｉｆファイルがＡＳＹＮＣＨモード ／＊コロ−ル処理を行なう。＊／ ／＊可能になるまで待機して、ファイ＊／／＊ルの代理
ｉノードをロックする。＊／／−にファイルの代理ｉノ
ードはファイ＊／／末ルのＶノード構造体のメンバーに
＊／／ネよって指示される。　　　　　　　＊／代理ｉ
ノードがアンロックされるまで待機し、次にそれをロッ
クする； ／＊以前のステップでスリープしてい＊／／＊たならば
、同期モードを再びテス＊／／＊トする　　　　　　　
　　　　　　＊／ｉｆファイルがＡＳＹＮＣＨモードで
ない／＊モードが変更されているので再＊／／＊試行す
る　　　　　　　　　　＊／ｇｏｔｏ　　ｒｅｔｒｙ　
； ／＊ＯＫ。依然としてＡＳＹＮＣＨモ＊／−ド　　　　
　　　　　　　　＊／ ｉｆ要求が領域のアンロックである 呼び出したプロセスによって所有されているロックに関
してロック・リストを走査する； アンロック要求の範囲と交わるロックの部分をアンロッ
クする； そのロック範囲に関連してスリーブ状態にあったプロセ
スを起こす； ｇｏｔｏ　　５ｕｃｃｅｓｓ　； ／　＊　ｅ　ｌ　ｓ　ｅ　、要求はロックをセットする
事である＊／ ／＊干渉的なロックがあるかテストする＊／ｗｈｉｌｅ
干渉的なロックが存在 ／＊デッドロックをチェック＊／ ｉｆ要求がデッドロックを生じる ／＊許可できない＊／ ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　； ｉｆロック・テーブルに余地がない ／＊呼び出したプロセスをスリーブさ せられない＊／ ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　； ／＊呼び出したプロセスをスリーブ＊／／＊させる。ロ
ック・テーブルの工＊／／＊ントリはスリーブ・リスト
上に＊／／＊連鎖される。スリーブ−リスト＊／／＊は
、スリーブ状態にあってロツ＊／／＊り範囲がアンロッ
クされるのを＊／／＊待っている各プロセス毎に１つ＊
／／＊のエンｈ　ＩＪを有する。スリーブ＊／／＊・リ
スト上のロック・テーブル＊／／＊エントリはスリーブ
状態のプロ＊／／＊セス及びそのプロセスが待機し＊／
／＊ているロックを所有しているプ＊／／＊ロセスの両
者を識別する。　　＊／スリーブ・リストにエントリを
付加する；／＊こうして、走行中のプロセスを＊／／＊
スリープさせる準備が殆んど整＊／／＊つた。しかし、
最初に、ｉノー＊／／＊ドがロックされていればそれを
＊／／＊解放する。これは、強制的ロツ＊／／＊キング
・モードでファイルを読＊／／木取り又は書込みする間
にこのコ＊／／＊−ドが実行されている場合に起＊／／
＊き得る。　　　　　　　　　　　　＊／ｉｆ　ｉノー
ドがロックされている ｉノードを解放する； ／＊最終的に準備完了＊／ スリーブ、割込みを捕獲する； ｉｆスリーブからの割込み有り ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　； ／＊正規のスリーブ解除＊／ ／＊干渉的なロックは終る＊／ ／＊もはやスリーブの必要はない＊／ スリーブ・リストからエントリを除去する； ／＊同期モードが変更されているか？＊／ｉｆ　ファイ
ル同期モードがＡＳＹＮＣＨでない ｇｏｔｏ　　ｒｅｔｒｙ　； 百代理ｉノードが以前にロックされた 代理ｉノードを再ロックする； ／＊ループ・バックし再度試行する＊／／＊今や、干渉
的なロックは存在しない＊／新しいロックをファイルの
ロック・リストに付加する； ｉｆ要求がリストに付加できた ｇｏｔｏ　　５ｕｃｃｅｓｓ　；／＊成功＊／ｌｓｅ ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　　’ｅｌｓｅ／＊フ
ァイルがＡＳＹＮＣＨモードでない＊／ ｄｆｓ　　ｆｌｏｃｋ　　ＲＰＣを用いて、サーバにオ
けるロックを要求する； ／＊ｄｆｓ　　ｆｌｏｃｋは、遠隔ロッキング＊／／＊
を行なうためにサーバでａｉｘ　　＊／／＊ｆｌｏｃｋ
を起動する　　　　　　＊／ｉｆ　　エラー ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　　’ｅｌｓｅ　　ｉ
ｆ　　エラーなし ｇｏｔｏ　　５ｕｃｃｅｓｓ　　’ ／＊エラーでも成功でもない。同期モ＊／／＊−ド変更
中にロック要求が起きた＊／／＊ので、再試行する。　
　　　　　〕ト／ｒｅｔｒｙ　　： ｉｆ代理がアンロックされた 代理をアンロックする； ／＊ループ・バックし再度試行する＊／ｅｒｒｏｒｅｘ
ｉｔ　　： ｉｆ代理がアシロツクされた 代理をアンロックする； エラーを返す； ５ｕｃｃｅｓｓ　　　。

ｉｆ代理がアンロックされた 代理をアンロックする； ０を返す・； この関数ｒａｉｘ　ｆｌｏｃｋは、遠隔ファイルに関す
る１ｏｃｋｆ又はｆｃｎｔｌへの呼び出しによって起動
される。即ち、クライエント・ノードのプロセスが、サ
ーバφノードのファイルに対して１ｏｃｋｆ又はｆｃｎ
ｔｌを使用する時、クライエントにおいてｒａｉｘ　　
ｆｌｏｃｋが実行される。クライエントでＡＳＹＮＣＨ
ファイル同期モードでファイルがオープンされると、ｒ
ａｉｘ　　ｆｌｏｃｋはローカル動作しか実行しない。

またクライエントでファイルがＡ　Ｓ　Ｙ　Ｎ　ＣＨ以
外のモードでオープンされると、ｒａｉｘ　ｆｌｏｃｋ
はｄｆａ　　ｆｌｏｃｋ　　ＲＰ、Ｃを使用し、サーバ
においてカーネル・プロセスを走行させる。このカーネ
ル・プロセスは、この場合にファイルのロック・リスト
が存在する、サーバにおいて指定範囲をロック又はアン
ロックする。

クライエントにより送られたｄｆｓ　　ｆｌｏｃｋ　Ｒ
ＰＣは、サーバにおいて、カーネル・プロセスにより、
ｄｆｓ　　ｆｌｏｃｋ関数を走行させる。ｄｆｓ　　ｆ
ｌｏｃｋ関数の動作は下記のように記述できる。

（ｄｆｓ　　ｆｌｏｃｋ　） 入カニ （ｄｆｓ　　ｆｌｏｃｋ　　ＲＰＣの一部として受は取
る） ファイル・ハンドル、ロックすべきファイルに関するフ
ァイル・ハンドル ファイル構造体、現在のオフセット及びファイルのオー
プン働モードを含んでいる、ロックすべきファイルに関
するファイル構造体要求、ロック又はアンロックすべき
領域の記述を含む構造体 出カニ （ｄｆｓ　　ｆｌｏｃｋ　　ＲＰＣに対する返答の一部
として返される） ロック要求が許可されると０を返す エラーの場合はエラ一番号を返す 動作が失敗し、同期モード変更により再試行すべき場合
にはＥＢＵＳＹを返す 手続き： ｉｆ　ファイル争ハンドルに対応するＶノードが存在し
ない ／＊ファイルはもはやオープンして℃・ない＊／返答に
エラーを送る； ／＊要求者は依然として返答を待ち続げ＊／／＊る事は
できない。というのはそれは＊／／＊ファイルがまだオ
ープンしていた事＊／／　〕＋＝を意味するからである
　　　　　　　木／ａｉｘ　　ｆｌｏｃｋを使ってロッ
ク動作を行なう；／＊ａｉｘ　　ｆｌｏｃｋはｖｎ　　
ｆｌｏｃｋを通じ＊／／＊て間接的に呼び出される　　
　　　　＊／ｉｆ　　エラー 返答にエラーを送る； ｅｌｓｅ　　　ｉｆ　　ＥＢＵＳＹ 返答ＫＥＢＵＳＹを送る； ｅｌｓｅ 成功の表示を有する返答を送る（これは確認返答が要求
される）； ｉｆ確認返答が、どのプロセスも返答を受は取らなかっ
た事を示す ／＊元の要求を出したプロセスは終了＊／／＊シた。従
つズ元の要求されたロツ＊／／＊りをアンロックする　
　　　　　＊／ｄｆｓ　　ｆＬｏｃｋ関数は、ｄｆｓ　
　ｆｌｏｃｋ　　ＲＰＣ要求に応答してサーバでロッキ
ングを行なうためにｖｎ　　１ｏｃｋｆ　　ｖノード動
作を起動する。サーバのｖｎ　　１ｏｃｋｆ’　Ｖノー
ド動作はａｉｘ　　ｆｌｏｃｋ関数の呼び出しに写像さ
れる。この関数はｒａｉｘ−ｆｌｏａｋルーチンに類似
しているが、ファイル拳アクセス構造体のロックの操作
に関係している。

このロック及びｉノードに対するロックを取得する試み
の後で、ａｉｘ　　ｆｌｏｃｋはファイルの同期モード
の変化する可能性を許容しなければならない。これらの
ロックを待機する間にスリーピングが起きる可能性があ
る。スリーブ期間中、さらに別のオーブン又は゛クロー
ズがそのファイルに対して行なわれる事もあり得る。

ａｉｘ　　ｆｌｏｃｋの詳細な動作の説明は次の通りで
ある。

（ａｉｘ　　ｆＬｏｃｋ　） 入カニ Ｖノード・ポインタ、ロックすべきファイルに関するＶ
ノードへのポインタ ファイル・ポインタ、ロックすべきファイルに関するフ
ァイル構造体へのポインタ、ファイル構造体は現在のオ
フセット及びファイルのオーブンΦモードを含んでいる 要求、ロック又はアンロックすべき領域の記述を含むｆ
ｌｏｃｋ構造体へのポインタ出カニ ロック要求が許められれば０を返し、さもなければエラ
ー表示を返す 手続： ／＊要求を標準形式にする＊／ 要求中の範囲（ｌ　　ｗｈｅｎｃｅ、１　５ｔａｒｔ及
び１　１ｅｎ）を、ｌ　　５ｔａｒｔがファイルの開始
点に対するような形式に変換する； ／＊ロック・リストを取得する＊／ ロック・リストはｉノード構造体のメンバーによって指
示され、１ノ一ド構造体はＶノード構造体のメンバーに
よって指示される； ／＊ファイル・アクセス・ロックを得る＊／ファイル拳
アクセス・ロックを待機し、それをロックする： ／＊スリーブ状態であった可能性がある、＊／／＊モー
ドをチェックする　　　　　　　＊／ｉｆ　ファイル同
期モードがＡＳＹＮＣＨｇｏｔｏ　　ｅｂｕｓ７　： ／＊サーバでファイルがオープンしてぃ＊／／＊る時に
この事は起こり得ない事に注＊／／＊意　　　　　　　
　　　　　　＊／／＊要求を試みる＊／ ｉｆ要求がアンロックを行なう事 ｒｅｃｌｏｃｋを呼び出したプロセスによって所有され
ているロックを求めて、ロック・リストを走査する； 要求の範囲と交わるそのようなロックの部分をアンロッ
クするニ アンロックされた部分を有していたロック範囲の上でス
リーブしていたプロセスを起こす；ｇｏｔｏ　　５ｕｃ
ｃｅｓｓ　； ／＊そうでなげれば、要求はロックをセットする事であ
る＊／ ／★スフアイル上干渉的なロックをテストするに／ｗｈ
　ｉ　１　ｅ　干渉的なロックが存在する／＊デッドロ
ックをチェックする＊／ ｉｆ要求がデッドロックを生じる ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　； １ｆロツク・テーブル中に余地がない ／＊即ち呼び出したプロセスをスリーブ＋：／／＊させ
ることができない　　　　　　＊／ｇｏｔｏ　　ｅｒｒ
ｏｒｅｘｉｔ　； ／＊呼び出しを行なったプロセスをスリ＊／／＊−ブさ
せる；　　　　　　　　　　　　木／／＊ロック・テー
ブルのエントリはスリ＊／／＊−プ・リストに連鎖され
る；＊／ ／＊スリーブ・リストは、スリーブ状態＊／／＊にあっ
てロック範囲がアンロックさ＊／／＊れるのを待機して
いるプロセス毎に＊／／／本１つのエントリを有する；
　　　　　★／／＊スリーブφリスト上のロック・チー
＊２／／＊プル・エントリはスリーブ中のプロ＊／／＊
セス及びそれが待機しているロック＊／／＊を所有して
いるプロセスを識別する＊／エントリをスリーブ・リス
トに付加する；／＊こうして、走行中のプロセスをスリ
＊／／＊−プさせる用意が殆んど整った；＊／／＊シか
し最初に、ｉノードがロックさ＊／／＊れていれば、そ
れを解放する；＊／／＊これはこのノードが強制的ロツ
キン＊／／＊グ・モードでファイルの読取り又は＊／／
＊書込みを行なっている場合に生じ得＊／／＊る　　　
　　　　　　　　　　　＊／ｉｆ　ｉノードがロックさ
れている ｉノードを解放する； ファイル・アクセス構造体のロックを解放する； ／＊最終的に準備完了＊／ スリーブ、割込みを捕獲する： ｉｆ　スリーブからの割込み ｇｏｔｏ　　ｅｒｒｏｒｅｘｉｔ　； ｉｆ　　同期モードがＡＳＹＮＣＨ ／＊スリーブ中にそれが変化した＊／ ｇｏｔｏ　　ｅｂｕｓｙ　；／＊再試行を要する＊／ス
リーブ・リストからエントリを除去する；ファイル・ア
クセス構造体ロック全ロックする； ｉｆ　ｉノードが以前にロックされているｉノードを再
ロックする； ／＊ここでループ・バックし、リスト全＊／／＊体を再
び走査する、スリーブ状態の＊／／＊間にロックが変化
した可能性がある＊／／＊干渉的なロックは存在しない
＊／ 新しいロックをファイルのロック・リストに付加する； ／＊いくつかのエン）　ＩＪが併合された可能性に注意
＊／ ｉｆ要求をロック・リストに付加する事ができた ｇｏｔｏ　　５ｕｃｃｅｓｓ　；／＊成功＊／ｌｓｅ ／＊エラー、おそらく、ロック・テープ＊／／＊ルにも
う余地がないのであろう　　＊／ｇｏｔｏ　　ｅｒｒｏ
ｒｅｘｉｔ　； ｅｒｒｏｒｅｘｔｔ　　： ファイル・アクセス構造体のロックを解放する； エラーを返す； ｅｂｕｓｙ　： ファイル・アクセス構造体のロックを解放する； ＥＢＵＳＹを返す； ５ｕｃｃｅｓｓ　　： ０を返す； ファイル同期モードの変化が起きている期間中に、ファ
イルを記述した構造体は、サーバ及びある非サーバ・ノ
ードの両者で更新されている。更新には遠隔ノードとの
通信が関与するので、更新が開始した後、それが終了す
る以前、プロセッサは優先使用され得る。同期モードが
変更されつつある期間中にファイルに関する、部分的し
て更新され従って矛盾した情報をプロセスが見い出す事
を防止するために、ＡＩＸオペレーティング・システム
はファイル・アクセス構造のロックを使用する。各オー
プンされたファイルはファイル・アクセス構造体ロック
を有し、これはファイルに関するオペレーティング・シ
ステム情報がおそらく矛盾している事を他のプロセスに
示すためにセットし得る。

上述の手続きａｉｘ　ｆｌｏｃｋは、ある条件の下で干
渉的なロックに関して待機しながら、スリーブ状態にな
る。そうする前にファイル・アクセス構造体ロックが解
放される事が重要である。もしａｉｘ　ｆｌｏｃｋが、
何らかのロックを待機する前にファイル・アクセス構造
体を解放しなければ、デッドロックが生じ得る。

ファイル・アクセス構造体に関するソース・コードを下
記に与える。詳細な論理を示すために説明的な情報を付
けた。

５ＴＲＵＣＴ　　ＦＩＬＥ　　ＡＣＣＥＳＳ（／〕七フ
ァイル・アクセス構造体ポインタ」′／５ＴＲＵＣＴ　
　ＦＩＬＥ　　ＡＣＣＥＳＳ　　＊ＦＡ　　　ＮＥＸＴ
； ／＊ファイル・アクセス構造体フラグ＊／５ＨＯＲＴ　
　　ＦＡ　　　ＦＬＡＧ；／＊ファイル・アクセス構造
体トータル・ユーザー＊／ ５ＨＯＲＴ　　ＦＡ　　Ｃ０ＵＮＴ； ／＊ファイル・アクセス構造体読取専用カウント＊／ ５Ｉ（ＯＲＴ　　ＦＡ　　０ＲＯＣＮＴ；／＊ファイル
・アクセス構造体読取／書込カウント＊／ ５）（ＯＲＴ　　ＦＡ　　０ＲＷＣＮＴ；／＊ファイル
・アクセス構造体実行中プロセス＊／５ＨＯＲＴ　　　
ＦＡ　　ＴＸＴＣＮＴ；／＊ファイル争アクセス構造体
ノード構造ポインタ＊／ ５ＴＲＵＣＴ　　Ｎ０ＤＥ’＊ＦＡ　　ＮＩＤ；／＊フ
ァイル・アクセス構造体ノードＩＤ’＊／ＩＮＴ　　　
ＦＡ　　　ＮＩＤ； ／＊ファイル・アクセス構造体代理ｉノード・ポインタ
＊／ ５ＴＲＵＣＴ　　ｌＮ０ＤＥ　　＊ＦＡ　　ＳＩＰ；）
；ファイル・アクセス構造ロック、ｆａｓロックは、分
散型ファイル・システム（ＤＦＳ）でオーブン・ファイ
ルに対するｉノードおよび代理ｉノードの使用を同期す
るために使われる。この同期はデッドロック状況を回避
するために実行される。デッドロック状態は、ｉノード
および代理ｉノードがロックされた場合に発生し得る。

スタンドアロンのＡＩＸオペレーティング・システムで
は、ファイルＦに対するアクセスを必要とするシステム
・コールの実行は、そのファイル　　。

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

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

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

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

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

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

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

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

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

第１７図に示すように、ファイルＦが、クライエント・
ノードＣ−１内のただ１つのプロセスによって、ＡＳＹ
ＮＣモードでオープンされている。

２つの動作が進行中である。すなわち、クライエントＣ
−１からのクローズ動作と、別のクライエントＣ−２か
らの、同じファイルＦに対・するオープン動作６０であ
る。クライエントｃ−１からのクローズ動作は代理ｉノ
ード（使用カウント１を有する）をロックし、「ｄｆｓ
　　ｃｌｏｓｅＪＲＰｃ５０をサーバに送る。クライエ
ントｃ−２からのオープン動作は［ｄｆｓ　　ｏｐｅｎ
Ｊ７０をサーバに送る。このＲＰＣはサーバに到達し、
クライエントＣ−１からのｌ’−ｄｆｓ　　ｃｌｏｓｅ
ＪＲＰｃ５０の前に実行される。ファイルＦに対する同
期モードはＡＳＹＮＧなので、サーバはｉノードをアン
ロックし、［ｄｆｓ　　ｃｈｎｇ　　５ｙｎｃ　　ｍｏ
ｄｅ（ｄｆｓ同期モード変更）ＪＲＰＣ８０をクライエ
ントｃ−ｉに送り、ファイルＦがＦＵＬＬＳＹＮＣモー
ドに変更されることを要求する。このＲＰＣがクライエ
ントＣ−１に到着し、代理ｉノードがアンロックされる
のを待つ。次に、「ｄｆｓ　　ｃｌｏｓｅＪＲＰｃ５０
がサーバに到着する。ファイルＦに対するｉノードはサ
ーバではロックされないので、クローズ動作がサーバで
実行され、ｆ−ｄｆｓ　　ｃｌｏｓｅ−Ａｃｋ（ｄｆｓ
クローズ肯定応答）ＪＲＰＣ９０がクライエントＣ−１
に送られる。ｌｄ’ｆｓ　　ｃｌｏｓｅ−ＡｃｋＪＲＰ
Ｃ９０がクライエントＣ−１に到着すると、代理ｉノー
ドに関する使用カウントが減分され、使用カウントの値
が０になったので、代理ｉノードは１００に示すように
解放される。これにより、同期モード変更をクライエン
トＣ−１に適用するための代理ｉノードは残らない。

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

サーバからクライエントに対してＲＰＣを発生する動作
は、ＲＰＣを送る前に、ｆａｓロックを獲得しなければ
ならな〜・。ＵＮＩＸオペレーティング・システムまた
はＡＩＸオペレーティング・システム環境における状況
の例は以下の通りである。

遠隔手順コール（ＲＰＣ）： ＊ＤＦＳ　　０ＰＥＮ　　　　　＊ＤＦＳ’ＣＲＥＡＴ
Ｅ＊ＤＦＳ　　ＣＬＯ８Ｅ　　　＊ＤＦＳ　　ＧＥＴ　
　ＡＴＴＲ＊ＤＦＳ　　ＳＥＴ　　ＡＴＴＲ＊ＤＦＳ　
　ＬＯＯＫＵＰ＊ＤＦＳ　　ＣＨＮＧ　　５ＹＮＣＭＯ
ＤＥサーバ・フ０　セスカラのＬＴＮＩＸシステム・コ
ール：＊０ＰＥＮ　　　　　　　　　　＊ＣＬＯ８Ｅ＊
ＣＲＥＡＴ　　　　　　　　　＊５ＴＡＴ＊ＦＵＬＬＳ
ＴＡＴ　　　　　　＊ＣＨＭＯＤ＊ＥＸＩＴ 上記ｕ　Ｎ　Ｉ　Ｘオペレーティング−システムおよヒ
Ａ　Ｉ　Ｘ、ｔ−ベレーテイング串システムの動作は以
下のｖｎ動作に対応する。

＊ｖｎ　ｏｐｅｎ　　　　　　　＊ｖｎ　ｃｒｅａｔｅ
＊ｖｎ　ｃｌｏｓｅ　　　　　　　＊ｖｎ　ｇｅｔａｔ
ｔｒ＊ｖｎ　５ｅｔａｔｔｒ　　　　　　＊ｖｎ　　１
ｏｏｋｕｐｖｎ動作実行の一例を以下に考察する。動作
（オープン）はクライエント・ノードで実行され、何ら
かのローカル処理が必要な場合は、通常通り代理ｉノー
ドをロックする。上記に列挙したＲＰＣの１つ（ｄｆｓ
オープン）がサーバに送られた場合、ＲＰＣが送られる
前に、代理ｉノードがアンロックされる。す二バでは、
ＲＰＣ要求はｆａｓロックをロックするか、あるいはｆ
ａｓロックが使用中の場合はそれを待ち、次に、ファイ
ルＦに対するｉノードをロックする。ＲＰＣ要求がロー
カル・サーバ動作である場合は、実行中のプロセスはｆ
ａｓロックを獲得し、次にｉノードをロックする。

ＤＦＳ　　ＣＨＮＧ　　５ＹＮＣＭＯＤＥまたはＤＦＳ
　　ＧＥＴ　　ＡＴＴＲＲＰＣがサーバからクライエン
トに送られる場合、ＲＰＣが送られる前に、ｉノードが
アノロックされる。したがって、サーバは、ＲＰＣが送
られた後で、読取りおよび書込み動作を受諾することが
できる。すべてのクライエントからの応答メツセージを
受は取ると、サーバはｉノードをロックして、残りのロ
ーカル処理を終了する。動作がクライエント・ノードで
開始された場合は、そのクライエントに肯定応答が送ら
れる。ｉノードが次にアノロックされ、ｆａｓロックが
解除される。

ｆａｓロックは、ｉノードの使用を同期化し、デッドロ
ック動作を回避する手段を提供する。それは分散ファイ
ル・システムに投入されなければならない必要なソフト
ウェア・オーバーヘッドを最小限のものにする。

Ｆ１発明の効果 本発明によれば、分散型データ処理システムにおいて効
果的なファイルのロックが実現される。

【図面の簡単な説明】

第１図は本発明が適用される典型的な分散型データ処理
システムのブロック図、 第２図は典型的なスタンドアロン型プロセッサ・システ
ムのブロック図、 第６図は読取りシステム・コールが発行された時にオペ
レーティング・システムが行なうステップを示す図、 第４図はローカル・ノードにおけるファイル管理のため
に使われるデータ構造の一例を示す図、第５図及び第６
図はローカル・ノードにおけるマウント動作の前後のフ
ァイル管理用データ構造の例を示す図、 第７図は第１図と同様の分散型データ処理システムのブ
ロック図、 第８図は分散型ファイル・システムのだめのデータ構造
の一例を示す図、 第９Ａ図〜第９Ｆ図は第８図の各要素のブロック図、 第１０図、第１１図及び第１２図は、分散型システムの
ローカル・ノード及び遠隔ノードにおけるファイル管理
用データ構造の一例を示す図、第１５図は第７図の分散
型データ処理システムをより詳細に示すブロック図、 第１４図は同期モードの状態図、 第１５図は第１３図と同様のブロック図、第１６図は第
１４図と同様の状態図、 第１７図はファイル・アクセス動作の一例を示す図、 第１８図はｆＬｏｃｋデータ構造の図、第１９図はロッ
ク・テーブルとｉノードとの関係を示す図、 第２０図はロック・テーブルとスリーブ中ロック・リス
トとの関係を示す図、 第２１図はｆ　ｉｌｏ　ｃｋデータ構造の図である。 出願人　　インターフウタナノービジネスφマシーンズ
ｅコ１ｆレーション代理人　弁理士　　頓　　　宮　　
　孝　　　−（外１名） 第３図 クライエント −Ｉｔ−ノぐ 第１０図 クライエ〉ト サーノに 第１１図 フライ１：／ト →トーノ（ ｆｓ ｎｏｄｅ 第１２図

Claims (3)

【特許請求の範囲】
1. （１）第１のノードに存在し且つ少なくとも１つの第２
   のノード上のプロセスによりアクセス可能なファイルの
   所定バイト範囲をロックするためのシステムであつて、 上記第１のノードの上記ファイルに関する少なくとも１
   つのロックを記述するデータ構造と、上記少なくとも１
   つの第２のノードへ上記データ構造中のデータを移動さ
   せる手段とを有するシステム。
2. （２）上記ファイルをオープンしている全てのプロセス
   が上記第２のノードに存在する時に上記データ構造中の
   データが上記第２のノードに移動される特許請求の範囲
   第１項記載のシステム。
3. （３）上記ファイルが強制的にロック・モードにある時
   に上記データ構造中のデータが上記第１のノードに移動
   される特許請求の範囲第２項記載のシステム。