JPH056895B2 - - Google Patents

Description

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

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

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

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

さらに、VM／370の下では、ユーザは同じロ
ーカル・プロセツサ上でまたは遠隔の別のプロセ
ツサ上でVM／370の下で走行する、他のどのオ
ペレーテイング・システムにもアクセスしそれを
使用することができる。オースチンにいるユーザ
が、VM／370の「パススルー」と呼ばれる機能
を使つて、同じプロセツサ上、または例えば同じ
SNAネツトワークに接続されたフランスのパリ
にあるプロセツサ上の別のVM／370または
MVS／370オペレーテイング・システムにアクセ
スすることができる。ユーザが一度この機能を使
うと、そのユーザはその別のオペレーテイング・
システムに接続されたフアイルを処理のために使
用することができる。

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

第二に、ユーザは、アクセスしようとするすべ
てのシステムに別々に「ログ・オン」しなければ
ならない。こうすることで、システムの保全性を
保護するために必要なセキユリテイがもたらされ
るが、そのことはまたユーザにとつては大変な負
担となる。その他の背景知識については、H.M.
デイテル（Harvey M.Deitel）著の教科書「オ
ペレーテイング・システム入門（An
Introduction to Operating Systems）」、
Addison−Wesley刊（1984年）、とくにその第22
章「VM：仮想計算機オペレーテイング・システ
ム（VM：Ａ Virtual Machine Operating
System）」を参照されたい。より詳しい考察につ
いては、H.ローリン（Harold Lorin）とH.M.デ
イテル共著の教科書「オペレーテイング・システ
ム（Operating Systems）」、Addison−Wesley
刊（1981年）、とくにその第10章「仮想計算機
（Virtual Machines）」を参照されたい。

以下では、UNIXオペレーテイング・システム
の１バージヨンで本発明を実施した場合について
説明するが、本発明はUNIXオペレーテイング・
システムに類似する特徴をもつ他のオペレーテイ
ング・システムでも使用できる。UNIXオペレー
テイング・システムは、ベル研究所（Bell
Telephone Laboratories、Inc.）がデイジタ
ル・エクイツプメント社（Digital Equipment
Corporation、DEC）のミニコンピユータ用に開
発したものであるが、広範囲のミニコンピユータ
用、それに最近ではマイクロコンピユータ用のオ
ペレーテイング・システムとして広く使われてい
る。この普及の一因は、UNIXオペレーテイン
グ・システムがアセンブリ言語ではなく、やはり
ベル研究所で開発されたＣプログラミング言語で
書かれており、したがつて、プロセツサの種類を
問わないことである。したがつて、様々な計算機
用のＣコンパイラを使うと、UNIXオペレーテイ
ング・システムをある計算機から別の計算機に移
すことが可能になる。すなわち、UNIXオペレー
テイング・システム環境用に書かれたアプリケー
シヨン・プログラムも、計算機間で移植可能であ
る。UNIXオペレーテイング・システムの詳細に
ついては、「UNIX^TMシステム、ユーザーズ・マ
ニユアル、システムＶ（UNIX^TMSystem、User′s
Manual、System Ｖ）」、Western Electric Co.、
1983年１月刊を参照のこと。UNIXオペレーテイ
ング・システムの秀れた概説が、B.W.カーニハ
ン（Brian W.Kernighan）とロブ・パイク
（Rob Pike）の共著「ユニツクス・プログラミン
グ環境（The Unix Programming
Environment）」Prentice−Hall、1984年刊に出
ている。UNIXオペレーテイング・システムの設
計の詳細については、M.J.バツハ（Maurice J.
Bach）著「ユニツクス・オペレーテイング・シ
ステムの設計（Desigh of the Unix Operating
System）」、Prentice−Hall、1986年刊に出てい
る。

AT＆Ｔのベル研究所は、多数の団体にUNIX
オペレーテイング・システム使用のライセンスを
供与しており、現在いくつかのバージヨンがあ
る。AT＆Ｔから出た最新のバージヨンは、バー
ジヨン5.2である。バークレイ・バージヨンとし
て知られるUNIXオペレーテイング・システムの
別のバージヨンが、カリフオルニア大学バークレ
イ校で開発された。広く使われているMS−DOS
およびパーソナル・コンピユータ用のPC−DOS
オペレーテイング・システムを開発したマイクロ
ソフト社（Microsoft）は、XENIXの商標で知
られるバージヨンを出している。IBM RT PC
（RISC（縮小命令セツト・コンピユータ）技術パ
ーソナル・コンピユータ、RTとRTPCはIBMコ
ーポレーシヨンの商標）を1985年に発表したのに
伴つて、IBMコーポレーシヨンはAIX（拡張対話
型エグゼクテイブ、AIXはIBMコーポレーシヨ
ンの商標）と呼ばれる新しいオペレーテイング・
システムを公開した。AIXは、アプリケーシヨ
ン・インターフエース・レベルでAT＆Ｔの
UNIXオペレーテイング・システム、バージヨン
5.2と互換性があり、UNIXオペレーテイング・
システム、バージヨン5.2に対する拡張機能を含
んでいる。AIXオペレーテイング・システムの
詳細については、「AIXオペレーテイング・シス
テム技術解説書（AIX Operating System
Technical Reference）」第１版、IBM Corp、
1985年11月刊を参照されたい。

本発明は、具体的には、複数のプロセツサがネ
ツトワーク内で相互接続されることを特徴とす
る、分散データ処理システムに関係する。実際に
実施された形では、本発明は、IBMのシステム
ネツトワーク・アーキテクチヤ（SNA）、さらに
具体的にはSNA LU6.2拡張プログラム間通信
（APPC）で相互接続された複数のIBM RT PC
上で機能する。SNAでは、そのリンク・レベル
として、ゼロツクス社が開発したローカル・エリ
ア・ネツトワーク（LAN）であるイーサネツト
（EthernetはXerox Corporationの商標）または
SDLC（同期データ・リンク制御）を使う。イー
サネツト・ローカル・エリア・ネツトワークを含
めてローカル・エリア・ネツトワークの簡単な説
明は、L.E.ジヨーダン（Larry E.Jordan）とB.
チヤーチル（Bruce Churchill）の共著「IBM
PC用の通信ネツトワーキング
（Communications and Networking for the
IBM PC）」、Robert J.Brady（Prentice−Hallの
子会社）、1983年刊に出ている。コンピユータ用
通信システム、とくにSNAとSDLCについての
より明確な説明は、R.J.シプサー（Cypser）著
「分散システム用通信アーキテクチヤ
（Communications Architecture for
Distributed System）」、Addison−Wesley、
1978年刊に出ている。ただし、本発明は、イーサ
ネツト・ローカル・エリア・ネツトワークや
IBM SNA以外のネツトワークで相互接続され
た、IBM RT PC以外の様々なコンピユータを
用いても実施できることを了解されたい。

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

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

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

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

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

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

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

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

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

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

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

UNIXオペレーテイングシステム環境内で分散
データ処理システムをサポートする方法は、他に
も知られている。たとえば、Sun Microsystems
はネツトワーク・フアイル・システム（NFS）
を発表し、ベル研究所は遠隔フアイル・システム
（RFS）を開発している。

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

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

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

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

Ｄ 問題点を解決するための手段 本発明によれば、これらの目的は、フアイルを
ロツクするのに下記のステツプを用いる事によつ
て達成される。もしフアイルがローカル・フアイ
ルであれば、その時はUNIXオペレーテイング・
システムの標準的なフアイル・ロツキングが使わ
れる。しかし、遠隔フアイルがロツクされるなら
ば、UNIXオペレーテイング・システムの
LOCKF及びFCNTLシステム・コールはインタ
ーセプトされ、遠隔プロセス・コール（RPC）
DFS−LOCK−CONTROLが実行される。サー
バ・ノードはRPCを受け取り、ロツク要求を実
施する。この要求は単一のレコード、１組のレコ
ード又はフアイル全体にロツクを行なう事ができ
る。次に、クライエントの代理ｉノードがDFS
−LOCK−CONTROL RPCからの返答を待機し
ている間に、サーバは、クライエントに通知を送
る。クライエントは、ロツクの受理を確認し
RPCの受信を遠隔サーバに返答する。サーバは、
クライエントの代理ｉノードからの返答の受信後
にロツク・テーブルを更新する。もしサーバが
DFS−LOCK−CONTROLの返答の受信を確認
しなければ、DFS−LOCK−CONTROLがロツ
ク・テーブルからロツクを除去する。

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

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

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

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

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

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

ｃ デイレクトリは、次の形式の項目の列を含
む。

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

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

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

この開示では、「子孫」の語は、他のデイレ
クトリを経由しないと到達できないものも含め
て、フアイル・ツリーの特定のデイレクトリよ
り下方にあるすべてのフアイルを意味するもの
とする。あるデイレクトリの「直属子孫」と
は、そのデイレクトリに名前が出ているフアイ
ル（単純フアイルまたはデイレクトリ）のみを
言う。

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

ある装置のフアイル・システム内のパス“／
dir1／dir2／file”をたどるには、次のような
ステツプをとる。

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

２ そのデイレクトリを探索して、name＝dir1
の項目を見つける。

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

４ そのデイレクトリを探索して、name＝dir2
の項目を見つける。

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

６ そのデイレクトリを探索して、name＝file
の項目を見つける。

７ このデイレクトリ内の「file」に関連するｉ
ノード番号が、パス“／dir1／dir2／file”で
識別される単純フアイルのｉノード番号であ
る。

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

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

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

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

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

マウント・データ構造は揮発性である。すなわ
ちデイスク上に記録されない。初期プログラム・
ロード（IPL）の一部として計算機が電源投入さ
れるたびに、所期のマウントのリストを再発行し
なければならない。以上の議論では、従来の
UNIXオペレーテイング・システムがフアイル・
システム全体のマウントをどのように使つてフア
イル・ツリーを作成し、またそのようなフアイ
ル・ツリー内でどのようにパスをたどるか説明し
た。こうしたインプリメンテーシヨンは、ある装
置上に存在するフアイル・システム全体をマウン
トすることに限定されている。仮想フアイル・シ
ステムの概念は、(1)装置をマウントできる上にフ
アイル（デイレクトリまたは単純フアイル）もマ
ウントできるようにすることにより、ある装置上
に存在するフアイル・システムの一部分をマウン
トすること、および(2)既にフアイル・ツリーの一
部分になつているデイレクトリ上に、遠隔デイレ
クトリまたはローカル・デイレクトリをマウント
すること、さらに(3)既にフアイル・ツリーの一部
分になつている単純フアイルの上に（遠隔または
ローカル）単純フアイルをマウントすることを可
能にする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

〔VN−LOOKUP〕

vnルツクアツプ操作では、フアイル・システ
ム内のパスをたどる際の基本的反復ステツプは、
デイレクトリ内でパス構成要素の名前を探し出
し、関連するｉノード番号を使つてチエーン中の
次のフアイルを探し出すというものである。ロー
カル・フアイル上でのvnルツクアツプ操作の擬
似コードを下記に示す。

LOOKUP機能 入力：デイレクトリのｖノード・ポインタ、デイ
レクトリ中でルツクアツプすべき名前 出力：指定されたフアイル／デイレクトリを指す
ｖノード・ポインタ デイレクトリのｖノード・ポインタをｉノー
ド・ポインタに変換する； −−ｖノード中のポインタを使う デイレクトリのｉノードをロツクする； IF（デイレクトリ中で探索許可をもつていな
い） デイレクトリｉノードをアンロツクする； エラーを戻す； デイレクトリで名前を探索する； IF（見つかつた） 名前に対するフアイル・ハンドルを作成する； −−デイレクトリ・エントリ中で見つかつたｉ
ノードを使う； フアイル・ハンドルに対するｖノードを指すポ
インタを得る； デイレクトリｉノードをアンロツクする； ｖノードを指すポインタを戻す； ELSE−−見つからなかつた デイレクトリｉノードをアンロツクする； エラーを戻す； 〔VN−OPEN〕 vn open機能は、何のオープン・モード（読
取／書込又は読取専用）がフアイルをオープンし
たかを記録するためにフアイル・アクセス構造を
形成（又は既存のものを修正）する。vn−open
動作に関する擬似コードを下記に示す。

vn−open機能 入力：オープンすべきフアイルに関するvnodeポ
インタ オープン・フラグ（例えば、読取専用、読
取／書込） 形成・モード−−新たに形成する場合のフア
イル・モード・ビツト） 出力：成功又は失敗を示す戻りコード ｖノードからフアイルのｉノードへのポインタ
を得る； ｉノードをロツクする； IF（アクセス不許可） ｉノードをアンロツクする； リターン（エラー）； このクライエントに関するフアイル・アクセス
構造を得る； −もしフアイル・アクセス構造がなければ１つ
割り当てる IF（フアイル・アクセス構造の割り当て不可
能） ｉノードをアンロツクする； リターン（エラー） フアイル・アクセス構造を読取専用、読取／
書込、及びテキスト・カウントに更新する； IF（打ち切りモードがセツトされている）フア
イルを打ち切る； ｉノードをアンロツクする； 〔LOOKUPPN〕 lookuppn操作とは、パスをたどる機能である。
その入力はパス（たとえば“／dir1／dir2／
file”）であり、その戻りコードはそのフアイル
を表すｖノードを指すポインタである。

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

LOOKUPPN機能 入力：パス名 出力：指定されたフアイルに対するｖノードを指
すポインタ IF（パスの最初の文字が１／１） 探索すべき現ｖノードはユーザのルート・デイ
レクトリのｖノードである； ELSE 探索すべき現ｖノードはユーザの現デイレクト
リのｖノードである； REPEAT IF（パスの次の要素が“……”なら） WHILE（現ｖノードが仮想フアイル・システ
ムのルートである限り） 現ｖノードは、仮想フアイル・システムがマウ
ント・オーバーされたｖノードとなる； IF（マウント・オーバーされたｖノードがな
い） （エラー）を戻す；−−“……”がフアイル・
システムのルートを通過した vn−lookupを使つて現ｖノード中のパス構成
要素をルツクアツプする； IF（vn lookupが構成要素を見つけた）； 現ｖノードはvn−lookupから戻されたｖノー
ドになる； WHILE（現ｖノードがマウント・オーバーさ
れている限り） マウントされた仮想フアイル・システムを表す
vfs構造へ現ｖノードのポインタをたどる； 現ｖノードはマウントされたvfsのルートｖノ
ードになる； ELSE−−vn−lookupはフアイル構成要素を見
つけられなかつた （エラー）を戻す；−−探索は失敗した UNTIL（追加のパス構成要素がなくなるま
で）； （現ｖノード）を戻す； あるフアイルへのパスをたどりデイレクトリを
マウントするというシナリオを用いて、その操作
を説明することにする。まず、フアイルへのパス
をたどる際に、あるアプリケーシヨン・プロセス
がフアイル“／ｕ／dept54／status”に対するシ
ステム・コール（たとえばオープン）を発行する
ものと仮定する。この要求は、第４図に関して下
記のような形で、オペレーテイング・システムに
よつて実行される（UNIXオペレーテイング・シ
ステムと基本的に異ならない操作については、こ
こでは詳しくは説明しない）。次の仮定を設ける。
第一に、ブロツク２１で表される仮想フアイル・
システムがルート仮想フアイル・システムであ
る。第二に、フアイル“／ｕ”はｖノード・ブロ
ツク２４とｉノード・ブロツク３１で表される。
第三に、以前のマウント操作で装置のフアイル・
システムがデイレクトリ“／ｕ”にマウントされ
ている。このマウントで、ブロツク２５で表され
る仮想フアイル・システムが作成された。第四
に、関係するすべてのデイレクトリとフアイルが
同じ装置上にある。第五に、指示されたデイレク
トリ内に次のデイレクトリ項目が存在する。

デイレクトリ ｉノード番号 名前 ｉノード番号 ２ “ｕ” 15 45 “dept54” 71 71 “status” 12 システム・コールを実施するコードが、そのパ
スをたどるためにlookuppnを呼び出す。
lookuppnはルート仮想フアイル・システム（ブ
ロツク２１）のルートｖノード（ブロツク２３）
からスタートし、このｖノードで表されるデイレ
クトリ・フアイル中で名前“ｕ”をルツクアツプ
するためにvn−lookupを呼び出す。vn−lookup
はそのデイレクトリ中で、名前“ｕ”がブロツク
３１のｉノード１５と関連していることを見つけ
る。vn−lookupはｉノード１５と関連するｖノ
ードを指すポインタを戻さなければならない。そ
のために、まずｉノード１５をｉノードテーブル
に入れる。次に、既にこのｖノードの親仮想フア
イル・システム内にｖノードがある（入力ｖノー
ド（ブロツク２３）が親仮想フアイル・システム
を指すポインタを有する）かどうか検査する。こ
の場合は存在する。vn−lookupは次に、ルート
仮想フアイル・システム（ブロツク２１）内でそ
のｖノード（ブロツク２４）を見つけ、ｖノード
を指すポインタを戻す。lookuppnは、戻された
ｖノードが親仮想フアイル・システム内でマウン
ト・オーバーされていることを発見する。
lookuppnは、ｖノード（ブロツク２４）からマ
ウントされた仮想フアイル・システム（ブロツク
２５）へと「マウント・オーバーされた」そのポ
インタをたどる。lookuppnは、新しい仮想フア
イル・システム（ブロツク２５）のルートｖノー
ド（ブロツク２６）へと「ルートｖノード」ポイ
ンタをたどる。次にlookuppnは今度はルートｖ
ノード（ブロツク２６）を指すポインタと名前
“dept54”を入力して、再びvn−lookupを呼び出
す。前回と同様に、vn−lookupはデイレクトリ
を読み取り、その名前と関連しているｉノードを
見つけ、親仮想フアイル・システム（ブロツク２
５）内にこのｉノードに対するｖノードを見つけ
または作成し、このｖノードを指すポインタを戻
す。lookuppnは、今見つけたばかりのデイレク
トリのｖノードと名前“status”を入力して、も
う一度vn−lookupを呼び出す。vn−lookupはデ
イレクトリを読み取り、その名前に関連するｉノ
ード（ブロツク３４）を見つけ、親仮想フアイ
ル・システム（ブロツク２５）内でこのｉノード
に対するｖノード（ブロツク２８）を見つけまた
は作成し、このｖノードを指すポインタを戻す。
システム・コールを実施したコードは、次にフア
イル上で要求された操作を実行する。

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

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

デイレクトリ ｉノード番号 名前 ｉノード番号 ２ “ｕ” 15 ２ “etc” 83 15 “gorp” 92 83 “foo” 75 75 “file1” 89 マウント・システム・コールを実施するコード
は、次の操作を実行する。マウント・オーバーさ
れるフアイル“／etc／foo”へのパスをたどるた
め、lookuppnを呼び出す。この操作が完了した
とき、ルート仮想フアイル・システム（ブロツク
４１）は、“／etc／foo”に対するｖノード（ブ
ロツク４４）を含んでいる。このｖノードは、ル
ート仮想フアイル・システム（ブロツク４１）を
指すポインタと、ｉノード７５に対するｉノー
ド・テーブル項目（ブロツク４５）を指すポイン
タを有する。マウントされるフアイル“／ｕ／
gorp”へのパスをたどるため、lookuppnを呼び
出す。この操作が完了したとき、ルート仮想フア
イル・システム（ブロツク４１）は“／ｕ／
gorp”に対するｖノード（ブロツク４９）を含
んでいる。このｖノードは、ルート仮想フアイ
ル・システム（ブロツク４１）を指すポインタ
と、ｉノード９２に対するｉノード・テーブル項
目（ブロツク４８）を指すポインタを有する。こ
こでマウント論理は、新しい仮想フアイル・シス
テムを作成する。それには、まず新しい仮想フア
イル・システム（ブロツク４６）を作成し、次に
遡つて親仮想フアイル・システム（ブロツク４
６）を指すポインタと、ルートｉノード（ｉノー
ド９２、ブロツク４８）を指すポインタとを有す
る、この仮想フアイル・システムに対するルート
ｖノード（ブロツク４７）を作成する。「マウン
ト・オーバーされる」ポインタが、ルート仮想フ
アイル・システム（ブロツク４１）内のカバーさ
れるｖノード（ブロツク４４）に挿入され、マウ
ント・オーバーされるｖノード（ブロツク４４）
を指すポインタが新しい仮想フアイル・システム
に挿入される。

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

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

サーバ・ノードでは、遠隔ノードがサーバのフ
アイルをどのように使用しているかに関する状態
情報をサーバが記録できるように、ある種のデー
タ構造が構築される。もつと具体的に言うと、各
サーバは、遠隔クライエントによつてオープンに
なつているフアイルを保持するための仮想フアイ
ル・システムとして「ダミー仮想フアイル・シス
テム」（たとえばブロツク７１）を有する。ダミ
ー仮想フアイル・システムは、サーバのフアイ
ル・ツリーの一部ではない。遠隔ノードによつて
オープンになつている各フアイルに対して、サー
バのダミー仮想フアイル・システム中にｖノード
（たとえばブロツク７４）がある。遠隔ノードに
よつてオープンになつている各フアイルは、サー
バのｉノード・テーブル中にｉノード・テーブル
項目（たとえばブロツク８５）を有する。このｉ
ノード・テーブル項目は、サーバにあるローカ
ル・プロセスがフアイルをオープンしたために存
在するテーブル項目と同じである。たとえば、遠
隔オープンの故にテーブル中に存在するブロツク
８４は、サーバでの操作の故にテーブル中に存在
するブロツク８８と同じ構造である。

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

フアイル・ハンドルの必要性は、次のシナリオ
からわかる。次のように仮定する。クライエント
がサーバに要求を出して、回答中でフアイル・ハ
ンドルを受け取る。クライエントは、そのフアイ
ル・ハンドルを記憶し覚える。サーバでの何らか
の活動によつてそのフアイルが削除され、ｉノー
ド・スロツトが別のフアイル用に再使用される。
クライエントが記憶しているフアイル・ハンドル
を使つてサーバに要求を出す。サーバはフアイ
ル・ハンドルを受け取り、新しいフアイルで操作
を実行する。そうなると、その操作は許容できな
いものとなるはずである。

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

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

ネツトワーク内の１つのノードが別のノードに
自分のために実行を要求できる操作が少数ある。
こうした操作は、dfs操作と呼ばれる。あるノー
ドが別のノードに要求を出すとき、次に操作が行
なわれる。まず、要求側ノードは、どのdfs操作
を要求しているか指定し、その要求に適したパラ
メータを運ぶメツセージを送る。次に受取側ノー
ドは要求を受け取つて指定された操作を実行す
る。最後に、受取側ノードは、そのdfs操作に適
した回答パラメータを運ぶメツセージを送る。

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

ローカル・フアイルの上に遠隔フアイルをマウ
ントし、フアイルへのパスをたどるというシナリ
オを用いて、この操作を説明することにする。第
一のシナリオでは、クライエント・ノード内のア
プリケーシヨン・プロセスが、ローカル・クライ
エント・フアイル“／etc／foo”の上にサーバ・
ノードのフアイル“／ｕ／gorp”をマウントす
るため、「マウント」システム・コールを発行す
るものとする。この要求がどのように実行される
かは、次のシナリオからわかる。このシナリオで
は第１０図および第１１図を参照する。第１０図
は初期状態を表し、第１１図は最終状態を表す。
ブロツク７１で表される仮想フアイル・システム
（vfs）がサーバのフアイル・ツリーのルート仮想
フアイル・システムであり、関係するサーバのデ
イレクトリおよびフアイルはすべて同一装置上に
ある。指示されたデイレクトリ中には次の項目が
存在する。

サーバ・ノード デイレクトリ ｉノード番号 名前 ｉノード番号 ２ “ｕ” 15 15 “gorp” 92 92 “file2” 67 クライエント・ノード デイレクトリ ｉノード番号 名前 ｉノード番号 ２ “etc” 83 83 “foo” 75 マウント・システム・コールを実施するコード
が、マウント・オーバーされるフアイル“／
etc／foo”へのパスをたどるためにlookuppnを
呼び出す。この操作が完了したとき、ルート仮想
フアイル・システム（ブロツク５１）は、“etc／
foo”に対するｖノード（ブロツク５３）を含ん
でいる。このｖノードは、ルート仮想フアイル・
システム（ブロツク５１）を指すポインタと、ｉ
ノード７５に対するｉノード・テーブル項目（ブ
ロツク６１）を指すポインタを有する。マウント
されるフアイルは遠隔ノードにあるため、dfsマ
ウント要求が、マウントされる目的物へのパスと
してパス“／ｕ／gorp”とともにサーバ・ノー
ドに発行される。dfsマウント要求を受け取ると、
サーバ・ノードは、マウントされるフアイル“／
ｕ／gorp”へのパスをたどるため、lookuppnを
呼び出す。このルツクアツプ操作が完了したと
き、サーバのルート仮想フアイル・システム（ブ
ロツク７１）は“／ｕ／gorp”に対するｖノー
ドを含んでいる。このｖノードは、ルート仮想フ
アイル・システムを指すポインタと、ｉノード９
２に対するｉノード・テーブル項目を指すポイン
タを有する。サーバはｉノード中の情報（装置
ｏ，ｉノード９２）を用いて、フアイル“／ｕ／
gorp”に対するフアイル・ハンドルを構築する。
サーバはdfsマウント要求に対する回答中でこの
フアイル・ハンドルを戻し、次にｖノードとｉノ
ードを解放する。最後に、クライエントはdfsマ
ウント要求に対する回答中でこのフアイル・ハン
ドルを受け取り、次のような新しい仮想フアイ
ル・システムを作成するのに必要な操作を実行す
る。

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

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

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

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

次に、上記の遠隔マウント（クライエントの／
etc／fooの上にサーバの／ｕ／gorpをマウントす
る）を実行した後、クライエント・プロセスが、
フアイル“／etc／foo／file2”に対して操作する
ためのシステム・コールを発行すると仮定する。
下記のシナリオのブロツク番号については第１１
図および第１２図を参照されたい。第１１図は初
期状態を表し、第１２図はオープン操作後のシス
テム状態を表す。まず、システム・コールを実施
するコードが、パスをたどるためにlookuppnを
呼び出す。lookuppnは、ルート仮想フアイル・
システム（ブロツク５１）のルートｖノード（ブ
ロツク５２）からスタートし、このｖノードで表
されるデイレクトリ・フアイル中で名前“ｕ”を
ルツクアツプするためにvn−lookupを呼び出す。
vn−lookupはそのデイレクトリ中で、名前“ｕ”
がｉノード１５と関連していることを見つける。
vn−lookupは、ｉノード１５に対するルート仮
想フアイル・システム中にｖノードとｉノードを
構築し、このｖノードに対するポインタを
lookuppnに戻す。lookuppnは、今度はｉノード
１５によつて識別されるデイレクトリ中で名前
“foo”をルツクアツプするために、再度vn−
lookupを呼び出す。vn−lookupは指示されたデ
イレクトリを読取り、名前“foo”がブロツク６
１中のｉノード７５と関連していることを発見す
る。ルート仮想フアイル・システム（ブロツク５
１）中には既にこのｉノード（ブロツク６１）に
対するｖノード（ブロツク５３）が存在し、した
がつてvn−lookupはこのｖノードを指すポイン
タを戻す。lookuppnは、そのｖノードがマウン
ト・オーバーされていることを発見する（ブロツ
ク５３中の「マウント・オーバー」ポインタはブ
ロツク５４を指している）。したがつて、
lookuppnは次の仮想フアイル・システム（ブロ
ツク５４）へと「マウント・オーバー」ポインタ
をたどり、その仮想フアイル・システムのルート
ｖノード（ブロツク５５）へとそのルートｖノー
ド・ポインタをたどる。次にlookuppnはパスの
次の要素（“file2”）を探すためにvn−lookupを
呼び出し、ブロツク５５を指すポインタと名前
“file2”をvn−lookupに与える。探索すべきデイ
レクトリは遠隔ノードにあり、クライエントの代
理ｉノード（ブロツク６２）に記憶されているフ
アイル・ハンドルによつて識別される。vn−
lookupはそのフアイルを保持するサーバにdfs−
lookupを発行し、そのデイレクトリを識別する
フアイル・ハンドルとルツクアツプすべき名前
（“file2”）を送る。サーバがdfs−lookupを受け
取ると、フアイル・ハンドルを使つて読み取るべ
きデイレクトリを識別し、このデイレクトリ中で
名前“file2”を探索するためにvn−lookupを発
行する。vn−lookupはデイレクトリを読み取り、
名前“file2”に関連するｉノード番号が６７で
あることを発見する。vn−lookupはｉノード６
７に対するダミー仮想フアイル・システム中でｖ
ノードとｉノードを構築し、このｖノードを指す
ポインタをlookuppnに戻す。dfs−lookupはvn−
lookupから戻されたデータ構造中の情報を用い
て、ｉノード６７によつて識別されるフアイルに
対するフアイル・ハンドルを構築する。dfs−
lookupは、dfs−lookup要求に対する回答として
このフアイル・ハンドルをクライエントに戻し、
ｖノードとｉノードを解放する。クライエント中
で、見つかつたフアイルに対するｖノード（ブロ
ツク５７）と代理ｉノード（ブロツク６３）が作
成される。“file2”はこのパスの最後の要素なの
で、lookuppnは見つかつたｖノード（ブロツク
５７）を指すポインタをその呼出し側に戻す。シ
ステム・コールを実施するコードは、次にそのフ
アイルに対して要求された操作を実行する。Ｅ−
２ フアイルの同期モード 本発明が実施された分散サービス・システムで
は、第７図に示すように、各ノードＡ，Ｂ，Ｃに
それぞれローカル・キヤツシユ１２Ａ，１２Ｂ，
１２Ｃが存在する。フアイル５がノードＡのデイ
スク２Ａ上に永久的に存在する場合、ノードＡを
サーバと呼ぶ。サーバＡでは、サーバ・ノードＡ
で実行されるローカルプロセス１３Ａによるキヤ
ツシユ１２Ａの使い方は、上記の従来技術の例で
述べたスタンドアロン・システムの場合と同様で
ある。しかし、ノードＢ，Ｃで実行される遠隔プ
ロセス１３Ｂ，１３Ｃは第１３図に示すように、
サーバ・キヤツシユとクライエント・キヤツシユ
を使つて、２段キヤツシング方式によりフアイル
５にアクセスする。サーバ・ノードＡは、デイス
ク２Ａからフアイル・ブロツク５を入手し、それ
をサーバ・キヤツシユ１２Ａに記憶する。クライ
エント・ノードＢは、ネツトワーク３を介してサ
ーバ・キヤツシユ１２Ａからフアイル・ブロツク
５を入手する。クライエント・ノードＢは、サー
バ・キヤツシユ１２Ａ内にあつたフアイル・ブロ
ツク５をクライエント・キヤツシユ１２Ｂに記憶
する。クライエント・ノードＢのユーザ・アドレ
ス・スペース１４Ｂがフアイル５からのデータを
シークするとき、各アクセスごとにネツトワーク
３を介してアクセスする代りにクライエント・キ
ヤツシユ１２Ｂにアクセスする。クライエント・
キヤツシユ１２Ｂを使つて遠隔フアイル５にアク
セスすると、ネツトワークのトラフイツク及びオ
ーバーヘツドが節減できるので、パフオーマンス
が著しく改善できる。

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

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

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

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

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

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

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

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

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

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

フアイルの同期モードは、どのノードでフアイ
ルがオープンになつているか、およびフアイルが
読取りのためにオープンになつているのか、それ
とも書込みのためにオープンになつているのかだ
けでなく、フアイルの存在する装置がロー
（raw）アクセス・モードでオープンになつてい
るかどうかにも依存する。ある装置に対するロ
ー・アクセスとは、装置２Ａ内のデータ・ブロツ
クLBN１（第１３図）がアクセスされるという
意味である。すなわち、装置２Ａの読取りおよび
書込みは、装置２Ａのデータ・ブロツクLBN１
に対する読取りおよび書込みである。そのデー
タ・ブロツクがどのフアイルに属するのか重要で
はない。装置２Ａは、サーバ・ノードＡでのプロ
セス１３１−１３Ｎからのロー・アクセスのため
にオープンすることができるが、遠隔ノードＢ，
Ｃからのロー・アクセスのためにオープンするこ
とはできない。

第１３図を参照すると、キヤツシユ１２Ａは、
第２図に関して先に説明したスタンドアロン・シ
ステムと同様に、装置２ＡのブロツクLBN１と
して管理される。サーバＡは、サーバ・キヤツシ
ユ１２Ａを装置２Ａ内の論理ブロツクLBN１と
して見る。クライエント・ノードＢは、フアイル
５が装置２Ａ上のどこにあるのか知らない。クラ
イエント・ノードＢが知つているのは、装置２Ａ
のブロツク番号Ｎ１にあるフアイル５にアクセス
していることだけである。クライエント・キヤツ
シユ１２Ｂは、データをフアイル５の論理ブロツ
クＮ１として扱う。サーバ・キヤツシユ１２Ａ内
では、データは装置２Ａの論理ブロツクLBN１
として扱われる。データをこのように扱う際に、
サーバＡは、データがロー（raw）装置としての
装置に書き込まれ、かつそのフアイルの装置に書
き込まれたブロツクと同じブロツクに対する読取
りが別にあつた場合に、新しく書き込まれたデー
タがその読取りで見えることを保証することがで
きる。このため、フアイル・システム・セマンテ
イツクスが保存される。

第１３図に示すようにクライエント・ノードＢ
でフアイルがアクセスされており、かつフアイル
がASYNCモードまたはREADONLYモードの場
合、クライエント・オペレーテイング・システム
１１Ｂは、システムコールREAD（フアイル記述
子、Ｎ１）１６中のフアイル記述子とフアイル内
のバイト範囲を、装置番号および装置内の論理ブ
ロツク番号に変換しない。クライアントは、フア
イル記述子とバイト範囲を、フアイル・ハンド
ル、ノード識別子、およびフアイル内の論理ブロ
ツク番号に変換する。クライエント・キヤツシユ
１２Ｂ内には、フアイル・ハンドル、ノード識別
子、およびフアイル内の論理ブロツク番号により
指定されるブロツク１７が存在する。クライエン
トのアプリケーシヨン・プログラム４Ｂから読取
り要求１６が発行されると、その読取り要求は、
フアイル記述子およびフアイル内のバイト範囲と
共にオペレーテイング・システム１１Ｂに向う。
次にオペレーテイング・システム１１Ｂはクライ
エント・キヤツシユ１２Ｂを見る。フアイル・ハ
ンドル、ノード識別子、およびフアイル内の論理
ブロツク番号がそこにある場合、キヤツシユ１２
Ｂが読み取られる。そこにない場合、その読取り
要求はサーバに送られる。サーバは次にフアイ
ル・ハンドルとフアイル内の論理ブロツク番号を
装置番号と装置内の論理ブロツク番号に変換す
る。この変換が必要なのは、サーバ・キヤツシユ
１２Ａがスタンドアロン・システムと同様に、装
置番号と装置内ブロツク番号によつて管理される
ためである。読取り要求はサーバに送られた後、
第２図に関して先に説明したスタンドアロン・シ
ステムで読取り要求がそれ自体のアプリケーシヨ
ン・プログラムから来ている場合と同様に扱われ
る。

クローズされているフアイルには、同期モード
がない。しかし、あるプロセスによつてフアイル
が始めてオープンされると、第１６図に示すよう
に下記の通り、フアイルの同期モードが初期設定
される。フアイルが存在する装置（Ｄ）がクロー
ズされている、すなわち特別装置としてオープン
されていず且つフアイルが１つの遠隔ノードでの
書込みアクセスに対してオープンされる場合、フ
アイルの同期モードはASYNCモード１０４に初
期設定される。フアイルが存在する装置がクロー
ズされ、１つまたは複数のノードでの読取り専用
アクセスのためにフアイルがオープンにされる場
合、あるいは装置もフアイルも読取り専用アクセ
スのためにオープンされる場合、フアイルの同期
モードはREADONLY１０５である。フアイル
が存在する装置が読取り／書込みアクセスのため
にブロツク特別装置としてオープンになつている
場合、あるいはフアイルが複数のノードでオープ
ンし、少なくとも１つのオープンが書込みに対す
るものである場合、フアイルの同期モードは
FULLSYNCモード１０６に初期設定される。ブ
ロツク特別装置とは、その装置に対するロー・ア
クセスがあるという意味である。

フアイルがあるモードに初期設定されても、条
件が変われば、フアイル・モードも変わることが
ある。第１６図で線１１８ないし１２３によつて
示すようなあるモードから別のモードへの移行
が、下記の条件で起こり得る。フアイルが現在
ASYNCモード１０４であり、そのフアイル
（Ｆ）がオープンになつているノードの数が２以
上になつた場合124、第１６図で線１１９によつ
て示すように同期モードはFULLSYNCモード１
０６に変わる。また、フアイルが存在するブロツ
ク特別装置Ｄのオープンがある場合125、同期モ
ードはASYNCモード１０４からFULLSYNCモ
ード１０６に変わる。フアイルのクローズ動作に
ついては、そのクローズ動作がフアイルの最終ク
ローズではなく、フアイルは書込みに対しては依
然としてオープンである場合は、モード変更は起
こらない。しかし、そのクローズ動作がそのフア
イルの書込みアクセスに対する最終クローズであ
り、残つているオープンはすべて読込みアクセス
に対するものである場合126は、線１２１で示す
ようにREADONLYモード１０５が新しいモー
ドになる。そのクローズ動作がそのフアイルの最
終クローズである場合、同期モードはない。

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

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

フアイルおよび装置に対するすべてのオープン
動作およびクローズ動作は、サーバ・ノードで解
決される。サーバは、同期モードを変更する可能
性がある任意の動作を実行するとき、オープン・
フアイルの同期モードを決定する。また、サーバ
は同期モードの変更を実行する。サーバがそのフ
アイルに対する新しいオープンまたはクローズを
獲得するとき、そのフアイルの同期モードの変更
がトリガされることがある。必要とされる同期モ
ードが現在のモードではない場合、サーバはその
フアイルがオープアンになつているすべてのクラ
イエントに「同期モード変更」遠隔手順コール
（rpc）を送る。フアイルが初めてオープンされた
後、そのフアイルをオープンしたクライエントに
は、そのフアイルのモードが知らされる。モード
がASYNCまたはREADONLYである場合、クラ
イエントは、第１３図に示すように、読取りのた
め、あるいはASYNCモードの場合は書込みのた
めにも、クライエント・キヤツシユの使用を開始
することができる。クライエントは、通信リンク
を介してサーバに対して読取りまたは書込みを行
なう必要はない。第１５図に示すようにモードが
FULLSYNCモードである場合は、クライエン
ト・キヤツシユは使われず、クライエントは通信
リンク３を介してサーバに対し読取りまたは書込
みを送る必要がある。

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

Ｅ−３ ロツク UNIXオペレーテイング・システムにおいて、
プロセスは、他のプロセスがアクセスしないよう
に、フアイル中のバイト範囲をロツクする事がで
きる。そのようなロツキングに関するサポート
は、UNIXオペレーテイング・システムのバージ
ヨン毎に違つているが、多くのインプリメンテー
シヨンにおいてはロツクはフアイルのバイト範囲
に適用される。フアイル全体にわたるロツクはフ
アイルをロツクし、しばしばフアイル・ロツクと
呼ばれる。規約により、長さゼロ・バイトの範囲
をロツクする要求は、範囲の始めからフアイルの
終りまでの全てのバイトをロツクすべき事を示
す。これにより、プロセスがフアイルに付加的な
バイトを追加する前にフアイルをロツクし、そし
て新しいバイト全部に対して制御を維持する事が
可能となる。任意のバイト範囲にわたるロツクは
しばしばレコード・ロツクと呼ばれるが、本明細
書中ではフアイル及びレコード（バイト範囲）に
対する全てのロツクは単にロツクと呼ぶ。

AIXオペレーテイング・システムにおいては、
lockf(2)及びfcntl(2)が読取ロツク及び書込みロツ
クの両者に関するサポートを与えている。書込み
ロツクは排他的なロツクである。即ち、もしフア
イルのある範囲が書込みロツクされると、いずれ
の種類の他のロツクもその範囲には存在する事が
できない。読取ロツクは共有的ロツクである。即
ち、任意の数の重なり合つた読取ロツクをフアイ
ルのセグメントにかける事ができる。既存の読取
ロツクは他の読取ロツクを阻止する事はないが、
他の書込ロツクは阻止する。また既存の書込ロツ
クは重なり合つた範囲上の他の全てのロツクを阻
止する。

AIXオペレーテイング・システムにおいて、
フアイルは強制的ロツキング・モード又は勧告的
ロツキング・モードのいずれかの状態にある。フ
アイルのロツキング・モードはchmodシステ
ム・コールを用いてフアイルの許可コードを変更
する事によつて制御される。強制的ロツキング・
モードのフアイルに対するロツクは強制的ロツク
と呼ばれ、勧告的ロツキング・モードのフアイル
に対するロツクは勧告的ロツクと呼ばれる。勧告
的ロツクはフアイル又はレコードに対して絶対的
な保護は与えない。というのはそれは、ロツクさ
れたフアイル又はレコードをプロセスが読み書き
するのを妨げないからである。勧告的ロツクは
lockf(2)又はfcnte(2)に対する呼び出しの結果にし
か影響せず、従つてそれは共有フアイルに対する
ロツクの状態をlockf(2)又はfcntl(2)を用いて照会
するように、協調的に動作するプロセスによつて
使用されなければならない。勧告的ロツクの利点
は、通常の読取り又は書込み動作の間にカーネル
によつて質問されなくてよい点である。強制的ロ
ツクは、おそらく、より頻繁に使用される。強制
的ロツクは、勧告的ロツクのように、lockf(2)及
びfcntl(2)に対するその後の呼び出しに影響を与
えるが、それに加えて、read(2)，write(2)，open
(2)，creat(2)，fclear(2)，ftruncate(2)及びshmat
(2)の各々により、フアイルの読取り又は書込みロ
ツクされた部分が変更されず、且つフアイルの書
込みロツクされた部分がアクセスされない事が保
証される。

fcntl(2)システム・コールの３つの異なつたコ
マンドがロツキングに関係している。

Ｆ−GETLK：これは、fcntl(2)の引数によつて記
述されたロツクを呼び出し例プロセスに許可
するのを妨げる、最初の既存のロツクを見い
出す。

Ｆ−SETLK：これは、fcntl(2)の引数によつて記
述されたロツクを呼び出し側プロセスに許可
する。もし既存のロツクが要求と干渉するた
めにロツクが許可できないならば、その既存
のロツクの記述を返す。

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

これらのコマンドの各々に関して、構造体、即
ちロツクを記述するflock構造体へのポインタが
fcntl(2)コールの引数として与えられる。flock構
造体は下記の形成を有する。

struct flock｛ short ｌ−type； short ｌ−whence； long ｌ−start； long ｌ−len； unsigned long ｌ sysid； short ｌ−pid； 第１８図に示すようなflock構造体のフイール
ドは下記の意味を有している。

ｌ−type２００は、ロツクが読取ロツクか又は
書込ロツクかを示すために使われる。

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

ｌ−start２０１は、ｌ−whenceにより指定さ
れた位置に対する、ロツクすべき範囲の開始点
のオフセツトである。

ｌ−len２０２は、ロツクすべき範囲のサイズ
である。

ｌ−pid２０４は、Ｆ−GETLKコマンドに応
答してfcntlにより返される、ロツクの所有者
のプロセスidである。

ｌ−sysid２０３は、ロツクの所有者が存在す
るノードのノードidである。

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

struct filock｛ struct flock set； union｛ int wakeflg； struct｛ unsigned long sysid； short
pid； ｝blk； ｝stat； struct filock ＊prev； srtuct filock ＊next； ｝ filock構造体２２１，２２２，２２３は、各々
現在何らかのロツクをセツトしているフアイル毎
に、別個のリストの形に連鎖される。リストの先
頭要素はそのフアイルのｉノード構造体２２０の
メンバーによつて指示される。filock構造体の１
つの付加的なリストがAIXオペレーテイング・
システムによつて維持される。このリストはスリ
ーブ・リスト２３０，２３１，２３２（第２０
図）であり、スリーブ・ロツク２２９により指示
される。スリーブ・リストは、現在ロツクを確立
しようとしているが既存の、干渉的なロツクによ
りそうする事を妨げられている（従つてスリーブ
状態にある）プロセス毎に１つのエントリを有し
ている。フアイル上のロツクの連鎖リストの要素
２２１，２２２，２２３として使われている時、
filock構造体のメンバーは下記の意味を有する。

setは、ロツクされた領域の記述、並びにロツ
クを所有しているプロセスのノードid及びプロセ
スidを含むflock構造体である。

stat.wakeflyは、プロセスがスリーブ状態にあ
つて、このエントリに対応するロツクが解除され
るのを待機している時にセツトされる。

stat.blk.sysid及びstat.blk.pidは使用しない。

prev及びnextは（二重連鎖）リスト中の先行
及び後続要素へのポインタである。

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

set３００は、スリーブ状態のプロセスがロツ
クしようと望んでいる範囲の記述、並びにスリー
ブ状態のプロセスのプロセスid及びノードidを含
むflock構造体である。

stat.wakefly３０４は使用されない。

stat.blk.sysid３０４は、setのメンバーによつ
て記述される要求を阻止しているロツクを所有し
ているプロセスのノードidである。

stat.blk.pid３０１は、setのメンバーによつて
記述される要求を阻止しているロツクを所有して
いるプロセスのプロセスidである。

prev３０２及びnext３０３は、（２重連鎖）リ
スト中の先行及び後続要素へのポインタである。

AIXオペレーテイング・システムにおいてロ
ツクを行なうために使う事のできる２つの異なつ
たシステム・コールが存在する。その両者は
reclockと呼ばれるルーチンを呼び出す事によつ
て実施される。このルーチンは次のように動作す
る。

〔reclock〕

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

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

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

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

このアーキテクチヤには２つの重要な含意が存
在する。第１に、プロセスはロツクをセツト又は
テストするために遠隔手続き呼出し（RPC）を
使用しなければならない。これらのRPCはフア
イルのサーバ上で走行する。第２に、フアイルの
同期モードが変化する時、フアイルのロツク・リ
ストはクライエントからサーバへ又はその逆方向
に移動されなければならない。ｉノードのロツ
ク・テーブルのエントリはｉノードのフアイルの
セグメント上のロツクに対応する。ロツクを表現
するために、ロツク・リストのエントリは、ロツ
クされたバイト範囲、ロツクの型（読取又は書
込）、ロツクの所有者を識別する情報を含まなけ
ればならない。

スタンド・アロンのUNIXオペレーテイング・
システムでは、ロツクを確立しようとするプロセ
スは、最初に既存のロツクがクリアされるのを待
たなければならない。待機する（スリーブ状態に
なる）前に、プロセスは待機を行なつた場合にデ
ツドロツクが生じない事を保証するためにスリー
ブ・リストをチエツクしなければならない。待機
中のプロセスは、それが待機しているロツク・テ
ーブルのエントリを指すためにprocテーブルの
Ｗ−CHANフイールドを使用する。

分散システムにおいて、待機は容易な事ではな
い。阻止しているロツクを待機するために２つの
方法がある。第１は、直接的に、ローカルのロツ
ク・リスト・エントリに対して、第２は間接的に
サーバのロツク・リスト・エントリに対して待機
する事である。直接的待機は上述のスタンド・ア
ロンの待機と同一である。それは、ロツク・テー
ブル中でローカルに生じたロツクをプロセスが待
機しなければならない時に使われる。フアイルに
関するロツク・リストは１つのノードにしか存在
しない事に留意するのは重要である。呼び出した
側のプロセスが同じノード中に存在しなければ、
ロツク・リストはサーバ中に存在する。そのロツ
ク・リストが遠隔ノード（サーバ）中に存在する
フアイルの領域をロツクしようとするプロセス
は、間接的にロツクを待機する。この間接的な待
機は、サーバでトランザクシヨン・プログラムを
起動しロツクを待機するRPCによつて行なわれ
る。スタンド・アロンのUNIXオペレーテイン
グ・システムでは、ロツクが許可されるか又は待
機がデツドロツクを生じ得るならば、プロセスは
決してスリーブ状態に入らない。分散型システム
では、ロツク・テーブルと同じノードに存在しな
い、ロツク要求を行なうプロセスは、少なくとも
短期間、常にスリーブ状態に入る。RPCに関し
て返答を待機している間、それはそうしなければ
ならない。不必要なネツトワーク通信を避けるた
めに、dfs−flock RPCからの返答を待機するプ
ロセスは、RPCトランザクシヨン・プログラム
が阻止的なロツクに関して待機しているのでそれ
が待機を行なつているのか又は阻止的なロツクは
何も見つからなかつたがサーバ中でトランザクシ
ヨン・プログラムがまだ終了していないので待機
しているのかを知らないであろう。

他にロツクが存在しないフアイルにロツクが最
初にかけられる時、フアイルがFULLSYNCHモ
ード又はREADONLYモードでオープンしてい
れば、サーバのロツク・テーブルに記入が行なわ
れ、またフアイルがASYNCHモードでオープン
していれば、クライエントのロツク・テーブルに
記入が行なわれる。オープン、クローズ又は
chmodシステム・コールがフアイルの同期モー
ドを変更しない限り、付加的な記入は同じテーブ
ルに行なわれ、一緒に連鎖される。（chmodはフ
アイルを強制的ロツキング・モードにする事によ
つてフアイル同期モードを変更し得る事に注意さ
れたい。強制的ロツキング・モードのフアイル
は、フアイルをオープンしているプロセスの数に
かかわりなく、FULLSYNCHモードであるかの
ように扱われる。）例えばオープンによりフアイ
ルの同期モードが変化する時、ロツク・リスト及
びスリーブ状態のプロセスは１つのノードから他
のノードに移動される。

強制的ロツキング・モードのフアイルは
FULLSYNCH同期モードを有し、他の
FULLSYNCHフアイルと同様に、強制的ロツキ
ング・モードのフアイルに関するロツク・リスト
はサーバに保持される。

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

〔raix−flock〕

入力： ｖノード・ポインタ、ロツクすべきフアイル に関するｖノードへのポインタ フアイル・ポインタ、ロツクすべきフアイル に関するフアイル構造体へのポインタ、フア イル構造体は現在のオフセツト及びフアイル のオープン・モードを含んでいる 要求、ロツク又はアンロツクすべき領域の記 述を含むflock構造体へのポインタ 出力： ロツク要求が許可されると０を返し、さもな ければエラー表示を返す 手続： ／＊要求を標準形式にする＊／ 要求中の範囲（ｌ−whence，ｌ−start、 及びｌ−len）を、ｌ−startがフアイルの 開始点に対するものであるような形式に変換 する； ／＊エラー又は終了まで試行を続ける＊／ while（TRUE） ｛ ifフアイルがASYNCHモード ｛ ／＊ローカル処理を行なう。＊／ ／＊可能になるまで待機して、フアイ＊／ ／＊ルの代理ｉノードをロツクする。＊／ ／＊フアイルの代理ｉノードはフアイ＊／ ／＊ルのｖノード構造体のメンバーに＊／ ／＊よつて指示される。＊／ 代理ｉノードがアンロツクされるまで待機し、
次にそれをロツクする； ／＊以前のステツプでスリーブしてい＊／ ／＊たならば、同期モードを再びテス＊／ ／＊トする＊／ ifフアイルがASYNCHモードでない ／＊モードが変更されているので再＊／ ／＊試行する＊／ goto retry； ／＊OK。依然としてASYNCHモ＊／ード
＊／ if要求が領域のアンロツクである 呼び出したプロセスによつて所有されているロ
ツクに関してロツク・リストを走査する； アンロツク要求の範囲と交わるロツクの部分を
アンロツクする； そのロツク範囲に関連してスリーブ状態にあつ
たプロセスを起こす； goto success； ／＊else、要求はロツクをセツトする事である
＊／ ／＊干渉的なロツクがあるかテストする＊／ while干渉的なロツクが存在 ｛ ／＊デツドロツクをチエツク＊／ if要求がデツドロツクを生じる ／＊許可できない＊／ goto errorexit； ifロツク・テーブルに余地がない ／＊呼び出したプロセスをスリーブさせられな
い＊／ goto errorexit； ／＊呼び出したプロセスをスリーブ＊／ ／＊させる。ロツク・テーブルのエ＊／ ／＊ントリはスリーブ・リスト上に＊／ ／＊連鎖される。スリーブ・リスト＊／ ／＊は、スリーブ状態にあつてロツ＊／ ／＊ク範囲がアンロツクされるのを＊／ ／＊待つている各プロセス毎に１つ＊／ ／＊のエントリを有する。スリーブ＊／ ／＊・リスト上のロツク・テーブル＊／ ／＊エントリはスリーブ状態のプロ＊／ ／＊セス及びそのプロセスが待機し＊／ ／＊ているロツクを所有しているプ＊／ ／＊ロセスの両者を識別する。＊／ スリーブ・リストにエントリを付加する； ／＊こうして、走行中のプロセスを＊／ ／＊スリーブさせる準備が殆んど整＊／ ／＊つた。しかし、最初に、ｉノー＊／ ／＊ドがロツクされていればそれを＊／ ／＊解放する。これは、強制的ロツ＊／ ／＊キング・モードでフアイルを読＊／ ／＊取り又は書込みする間にこのコ＊／ ／＊ードが実行されている場合に起＊／ ／＊き得る。＊／ ifiノードがロツクされている ｉノードを解放する； ／＊最終的に準備完了＊／ スリーブ、割込みを捕獲する； ifスリーブからの割込み有り goto errorexit； ／＊正規のスリーブ解除＊／ ／＊干渉的なロツクは終る＊ ／もはやスリーブの必要はない＊／ スリーブ・リストからエントリを除去する； ／＊同期モードが変更されているか？＊／ ifフアイル同期モードがASYNCHでない goto retry； if代理ｉノードが以前にロツクされた 代理ｉノードを再ロツクする； ／＊ループ・バツクし再度試行する＊／ ｝ ／＊今や、干渉的なロツクは存在しない＊／ 新しいロツクをフアイルのロツク・リストに付
加する； if要求がリストに付加できた goto success；／＊成功＊／ else goto errorexit； ｝ else／＊フアイルがASYNCHモードでない
＊／ ｛ dfs−flock RPCを用いて、サーバに おける
ロツクを要求する； ／＊dfs−flockは、遠隔ロツキング＊／ ／＊を行なうためにサーバでaix−＊／ ／＊flockを起動する＊／ ifエラー goto errorexit； else ifエラーなし goto success； ／＊エラーでも成功でもない。同期モ＊／ ／＊ード変更中にロツク要求が起きた＊／ ／＊ので、再試行する。＊／ ｝ retry： if代理がアンロツクされた代理をアンロツクす
る； ／＊ループ・バツクし再度試行する＊／ ｝ errorexit： if代理がアンロツクされた 代理をアンロツクする； エラーを返す； success： if代理がアンロツクされた 代理をアンロツクする； ０を返す； この関数raix−flockは、遠隔フアイルに関す
るlockf又はfcntlへの呼び出しによつて起動され
る。即ち、クライエント・ノードのプロセスが、
サーバ・ノードのフアイルに対してlockf又は
fcntlを使用する時、クライエントにおいてraix
flockが実行される。クライエントでASYNCH
フアイル同期モードでフアイルがオープンされる
と、raix−flockはローカル動作しか実行しない。
またクライエントでフアイルがASYNCH以外の
モードでオープンされると、raix−flockはdfs−
flock RPCを使用し、サーバにおいてカーネル・
プロセスを走行させる。このカーネル・プロセス
は、この場合にフアイルのロツク・リストが存在
する、サーバにおいて指定範囲をロツク又はアン
ロツクする。クライエントにより送られたdfs−
flock RPCは、サーバにおいて、カーネル・プロ
セスにより、dfs−flock関数を走行させる。dfs
−flock関数の動作は下記のように記述できる。

〔dfs−flock〕

入力： （dfs−flock RPCの一部として受け取る） フアイル・ハンドル、ロツクすべきフアイルに
関するフアイル・ハンドル フアイル構造体、現在のオフセツト及びフアイル
のオープン・モードを含んでいる、ロツクすべき
フアイルに関するフアイル構造体要求、ロツク又
はアンロツクすべき領域の記述を含む構造体 出力： （dfs−flock RPCに対する返答の一部として
返される） ロツク要求が許可されると０を返す エラーの場合はエラー番号を返す 動作が失敗し、同期モード変更により再試行す
べき場合にはEBUSYを返す 手続き： ifフアイル・ハンドルに対応するｖノードが存
在しない ｛ ／＊フアイルはもはやオープンしていない＊／ 返答にエラーを送る； ／＊要求者は依然として返答を待ち続け＊／ ／＊る事はできない。というのはそれは＊／ ／＊フアイルがまだオープンしていた事＊／ ／＊を意味するからである＊／ ｝ aix−flockを使つてロツク動作を行なう； ／＊aix−flockはvn−flockを通じ＊／ ／＊て間接的に呼び出される＊／ ifエラー 返答にエラーを送る； else if EBUSY 返答にEBUSYを送る； else 成功の表示を有する返答を送る（これは確認返
答が要求される）； if確認返答が、どのプロセスも返答を受け取ら
なかつた事を示す ｛ ／＊元の要求を出したプロセスは終了＊／ ／＊した。従つて元の要求されたロツ＊／ ／＊クをアンロツクする＊／ ｝ dfs−flock関数は、dfs−flock RPC要求に応
答してサーバでロツキングを行なうためにvn−
lockf ｖノード動作を起動する。サーバのvn−
lockf ｖノード動作はaix−flock関数の呼び出し
に写像される。この関数はraix−flockルーチン
に類似しているが、フアイル・アクセス構造体の
ロツクの操作に関係している。このロツク及びｉ
ノードに対するロツクを取得する試みの後で、
aix−flockはフアイルの同期モードの変化する可
能性を許容しなければならない。これらのロツク
を待機する間にスリーピングが起きる可能性があ
る。スリーブ期間中、さらに別のオープン又はク
ローズがそのフアイルに対して行なわれる事もあ
り得る。

aix−flockの詳細な動作の説明は次の通りであ
る。

〔aix−flock〕

入力： ｖノード・ポインタ、ロツクすべきフアイルに
関するｖノードへのポインタ フアイル・ポインタ、ロツクすべきフアイルに
関するフアイル構造体へのポインタ、 フアイル
構造体は現在のオフセツト及びフアイルのオープ
ン・モードを含んでいる 要求、ロツク又はアンロツクすべき領域の記述
を含むflock構造体へのポインタ 出力： ロツク要求が許められれば０を返し、さもなけれ
ばエラー表示を返す 手続： ／＊要求を標準形式にする＊／ 要求中の範囲（ｌ−whence，ｌ−start及びal
−len）を、ｌ−startがフアイルの開始点に対す
るような形式に変換する； ／＊ロツク・リストを取得する＊／ ロツク・リストはｉノード構造体のメンバーに
よつて指示され、ｉノード構造体はｖノード構造
体のメンバーによつて指示される； ／＊フアイル・アクセス・ロツクを得る＊／ フアイル・アクセス・ロツクを待機し、それを
ロツクする； ／＊スリーブ状態であつた可能性がある、＊／ ／＊モードをチエツクする＊／ ifフアイル同期モードがASYNCH goto ebusy； ／＊サーバでフアイルがオープンしてい＊／ ／＊る時にこの事は起こり得ない事に注＊／ ／＊意＊／ ／＊要求を試みる＊／ if要求がアンロツクを行なう事 reclockを呼び出したプロセスによつて所有さ
れているロツクを求めて、ロツク・リストを走査
する； 要求の範囲と交わるそのようなロツクの部分を
アンロツクする； アンロツクされた部分を有していたロツク範囲
の上でスリーブしていたプロセスを起こす； goto success； ／＊そうでなければ、要求はロツクをセツトす
る事である＊／ ／＊フアイル上の干渉的なロツクをテストする
＊／ while干渉的なロツクが存在する ｛ ／＊デツドロツクをチエツクする＊／ if要求がデツドロツクを生じる goto errorexit； ifロツク・テーブル中に余地がない ／＊即ち呼び出したプロセスをスリーブ＊／ ／＊させることができない＊／ goto errorexit； ／＊呼び出しを行なつたプロセスをスリ＊／ ／＊ーブさせる；＊／ ／＊ロツク・テーブルのエントリはスリ＊／ ／＊ーブ・リストに連鎖される；＊／ ／＊スリーブ・リストは、スリーブ状態＊／ ／＊にあつてロツク範囲がアンロツクさ＊／ ／＊れるのを待機しているプロセス毎に＊／ ／＊１つのエントリを有する；＊／ ／＊スリーブ・リスト上のロツク・テー＊／ ／＊ブル・エントリはスリーブ中のプロ＊／ ／＊セス及びそれが待機しているロツク＊／ ／＊を所有しているプロセスを識別する＊／ エントリをスリーブ・リストに付加する； ／＊こうして、走行中のプロセスをスリ＊／ ／＊ーブさせる用意が殆んど整つた；＊／ ／＊しかし最初に、ｉノードがロツクさ＊／ ／＊れていれば、それを解放する；＊／ ／＊これはこのノードが強制的ロツキン＊／ ／＊グ・モードでフアイルの読取り又は＊／ ／＊書込みを行なつている場合に生じ得＊／ ／＊る＊／ if ｉノードがロツクされている ｉノードを解放する； フアイル・アクセス構造体のロツクを解放す
る； ／＊最終的に準備完了＊／ スリーブ、割込みを捕獲する； ifスリーブからの割込み goto errorexit； if同期モードがASYNCH ／＊スリーブ中にそれが変化した＊／ goto ebusy；／＊再試行を要する＊／ スリーブ・リストからエントリを除去する； フアイル・アクセス構造体ロツクをロツクす
る； if ｉノードが以前にロツクされている ｉノードを再ロツクする； ／＊ここでループ・バツクし、リスト全＊／ ／＊体を再び走査する、スリーブ状態の＊／ ／＊間にロツクが変化した可能性がある＊／ ｝ ／＊干渉的なロツクは存在しない＊／ 新しいロツクをフアイルのロツク・リストに付
加する； ／＊いくつかのエントリが併合された可能性に
注意＊／ if要求をロツク・リストに付加する事ができた goto success；／＊成功＊／ else ／＊エラー、おそらく、ロツク・テーブ＊／ ／＊ルにもう余地がないのであろう ＊／ goto errorexit； errorexit： フアイル・アクセス構造体のロツクを解放す
る； エラーを返す； ebusy： フアイル・アクセス構造体のロツクを解放す
る； EBUSYを返す； success： ０を返す； フアイル同期モードの変化が起きている期間中
に、フアイルを記述した構造体は、サーバ及びあ
る非サーバ・ノードの両者で更新されている。更
新には遠隔ノードとの通信が関与するので、更新
が開始した後、それが終了する以前、プロセツサ
は優先使用され得る。同期モードが変更されつつ
ある期間中にフアイルに関する、部分的に更新さ
れ従つて矛盾した情報をプロセスが見い出す事を
防止するために、AIXオペレーテイング・シス
テムはフアイル・アクセス構造のロツクを使用す
る。各オープンされたフアイルはフアイル・アク
セス構造体ロツクを有し、これはフアイルに関す
るオペレーテイング・システム情報がおそらく矛
盾している事を他のプロセスに示すためにセツト
し得る。

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

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

STRUCT FILE−ACCESS ｛／＊フアイル・アクセス構造体ポインタ＊／ STRUCT FILE−ACCESS ＊Ｆ Ａ−NEXT； ／＊フアイル・アクセス構造体フラグ＊／ SHORT FA−FLAG； ／＊フアイル・アクセス構造体トータル・ユー
ザー＊／ SHORT FA−COUNT； ／＊フアイル・アクセス構造体読取専用カウン
ト＊／ SHORT FA−OROCNT； ／＊フアイル・アクセス構造体読取／書込カウ
ント＊／ SHORT FA−ORWCNT； ／＊フアイル・アクセス構造体実行中プロセス
＊／ SHORT FA−TXTCNT； ／＊フアイル・アクセス構造体ノード構造ポイ
ンタ＊／ STRUCT NODE ＊FA−NID； ／＊フアイル・アクセス構造体ノードID＊／ INT FA−NID； ／＊フアイル・アクセス構造体代理ｉノード・
ポインタ＊／ STRUCT INODE ＊FA−SIP；｝； フアイル・アクセス構造ロツク、fasロツクは、
分散型フアイル・システム（DFS）でオープ
ン・フアイルに対するｉノードおよび代理ｉノー
ドの使用を同期するために使われる。この同期は
デツドロツク状況を回避するために実行される。
デツドロツク状態は、ｉノードおよび代理ｉノー
ドがロツクされた場合に発生し得る。

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

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

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

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

ｂ ０２がサーバで実行されている。０２はｉノ
ードをロツクし、フアイルをオープンするため
にクライエント・ノードに対してRPCを開始
する。クライエント・ノードでのRPC要求は
代理ｉノードを待つて、それをロツクしてから
実行される。

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

上記問題の発生を防ぐため、サーバは、代理ｉ
ノードをロツクするためのRPCをクライエント
に出す前に、ｉノードをアンロツクすることがで
きる。オープン動作の実行中にｉノードをアンロ
ツクすると、上記の問題が解決される。しかし、
そうすると複数のオープン動作またはクローズ動
作あるいはその両方が同時にサーバで行なわれる
可能性があるので、オープン・フアイルのための
同期モード変更の管理が複雑になる。第１７図に
示すようなもう１つの問題が生じる可能性もあ
る。第１７図に示すように、フアイルＦが、クラ
イエント・ノードＣ−１内のただ１つのプロセス
によつて、ASYNCモードでオープンされてい
る。２つの動作が進行中である。すなわち、クラ
イエントＣ−１からのクローズ動作と、別のクラ
イエントＣ−２からの、同じフアイルＦに対する
オープン動作６０である。クライエントＣ−１か
らのクローズ動作は代理ｉノード（使用カウント
１を有する）をロツクし、「dfs−close」RPC５
０をサーバに送る。クライエントＣ−２からのオ
ープン動作は「dfs−open」７０をサーバに送
る。このRPCはサーバに到達し、クライエント
Ｃ−１からの「dfs−close」RPC５０の前に実行
される。フアイルＦに対する同期モードは
ASYNCなので、サーバはｉノードをアンロツク
し、「dfs−chng−sync−mode（dfs同期モード変
更）」RPC８０をクライエントＣ−１に送り、フ
アイルＦがFULLSYNCモードに変更されること
を要求する。このRPCがクライエントＣ−１に
到着し、代理ｉノードがアンロツクされるのを待
つ。次に、「dfs−close」RPC５０がサーバに到
着する。フアイルＦに対するｉノードはサーバで
はロツクされないので、クローズ動作がサーバで
実行され、「dfs−close−Ack（dfsクローズ肯定
応答）」RPC９０がクライエントＣ−１に送られ
る。「dfs−close−Ack」RPC９０がクライエン
トＣ−１に到着すると、代理ｉノードに関する使
用カウントが減分され、使用カウントの値が０に
なつたので、代理ｉノードは１００に示すように
解放される。これにより、同期モード変更をクラ
イエントＣ−１に適用するための代理ｉノードは
残らない。

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

サーバからクライエントに対してRPCを発生
する動作は、RPCを送る前に、fasロツクを獲得
しなければならない。UNIXオペレーテイング・
システムまたはAIXオペレーテイング・システ
ム環境における状況の例は以下の通りである。

遠隔手順コール（RPC）： ＊DFS−OPEN＊DFS−CREATE ＊DFS−CLOSE＊DFS−GET−ATTR ＊DFS−SET−ATTR＊DFS−LOOKUP ＊DFS−CHNG−SYNC−MODE サーバ・プロセスからのUNIXシステム・コー
ル： ＊OPEN＊CLOSE ＊CREAT＊STAT ＊FULLSTAT＊CHMOD ＊EXIT 上記UNIXオペレーテイング・システムおよび
AIXオペレーテイング・システムの動作は以下
のvn動作に対応する。

＊vn−open＊vn−create ＊vn−close＊vn−getattr ＊vn−setattr＊vn−lookup vn動作実行の一例を以下に考察する。動作
（オープン）はクライエント・ノードで実行され、
何らかのローカル処理が必要な場合は、通常通り
代理ｉノードをロツクする。上記に列挙した
RPCの１つ（dfsオープン）がサーバに送られた
場合、RPCが送られる前に、代理ｉノードがア
ンロツクされる。サーバでは、RPC要求はfasロ
ツクをロツクするか、あるいはfasロツクが使用
中の場合はそれを待ち、次に、フアイルＦに対す
るｉノードをロツクする。RPC要求がローカ
ル・サーバ動作である場合は、実行中のプロセス
はfasロツクを獲得し、次にｉノードをロツクす
る。DFS−CHNG−SYNC−MODEまたはDFS
−GET−ATTR−RPCがサーバからクライエン
トに送られる場合、RPCが送られる前に、ｉノ
ードがアンロツクされる。したがつて、サーバ
は、RPCが送られた後で、読取りおよび書込み
動作を受託することができる。すべてのクライエ
ントからの応答メツセージを受け取ると、サーバ
はｉノードをロツクして、残りのローカル処理を
終了する。動作がクライエント・ノードで開始さ
れた場合は、そのクライエントに肯定応答が送ら
れる。ｉノードが次にアンロツクされ、fasロツ
クが解除される。

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

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

【図面の簡単な説明】

第１図は本発明が適用される典型的な分散型デ
ータ処理システムのブロツク図、第２図は典型的
なスタンドアロン型プロセツサ・システムのブロ
ツク図、第３図は読取りシステム・コールが発行
された時にオペレーテイング・システムが行なう
ステツプを示す図、第４図はローカル・ノードに
おけるフアイル管理のために使われるデータ構造
の一例を示す図、第５図及び第６図はローカル・
ノードにおけるマウント動作の前後のフアイル管
理用データ構造の例を示す図、第７図は第１図と
同様の分散型データ処理システムのブロツク図、
第８図は分散型フアイル・システムのためのデー
タ構造の一例を示す図、第９Ａ図〜第９Ｆ図は第
８図の各要素のブロツク図、第１０図、第１１図
及び第１２図は、分散型システムのローカル・ノ
ード及び遠隔ノードにおけるフアイル管理用デー
タ構造の一例を示す図、第１３図は第７図の分散
型データ処理システムをより詳細に示すブロツク
図、第１４図は同期モードの状態図、第１５図は
第１３図と同様のブロツク図、第１６図は第１４
図と同様の状態図、第１７図はフアイル・アクセ
ス動作の一例を示す図、第１８図はflockデータ
構造の図、第１９図はロツク・テーブルとｉノー
ドとの関係を示す図、第２０図はロツク・テーブ
ルとスリーブ・ロツク・リストとの関係を示す
図、第２１図はfilockデータ構造の図である。

Claims (1)

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