JPH058455B2 - - Google Patents

Description

【発明の詳細な説明】 以下にしたがつて本発明を説明する。 Ａ 産業上の利用分野 Ｂ 従来技術 Ｃ 発明が解決しようとする問題点 Ｄ 問題点を解決するための手段 Ｅ 実施例 E1 はじめに（第２図〜第７図） E2 分散フアイル・システムにおける操作（第
１図、第８図〜第１２図） E3 フアイル・アクセスの同期モード（第１３
図、第１４図） E4 ロツキング（第１５図〜第１９図） UNIXフアイル・ロツキング ロツク・テーブル ロツク待ち デツドロツク 分散型フアイル・サポート・ロツク制御 フアイル・ロツキング構造 内部の詳細 フアイル・アクセス構造ロツク（第１７図、第
１８図） 一例（第１９図） Ｆ 発明の効果 Ａ 産業上の利用分野 本発明は、一般に分散データ処理システム用の
オペレーテイング・システムの改良に関し、さら
に具体的には、ローカル・エリア・ネツトワーク
（LAN）または広域ネツトワーク（WAN）で相
互接続された多重プロセツサ・システム用のオペ
レーテイング・システムに関するものである。
LANまたはWANを構成するため、IBN社のシ
ステム・ネツトワーク・アーキテクチヤ（SNA）
を使用することができる。本発明にもとづくオペ
レーテイング・システムを使うと、フアイルがシ
ステム中のどこにあろうと、システム中のプロセ
ツサによつてそれらのフアイルにアクセスできる
ようになる。本発明の好ましい実施例をここでは
UNIX（ATTの商標）オペレーテイング・システ
ムの１バージヨンで実施された好ましい実施例の
形で開示するが、本発明は他の様々なオペレーテ
イング・システム中でも実施できる。 Ｂ 従来技術 １台の実計算機を複数台の計算機に見せる仮想
計算機オペレーテイング・システムが、従来技術
で知られている。こうした計算機は、それを載せ
る実計算機に非常に類似することもあり、また非
常に異なることもある。多数の仮想計算機オペレ
ーテイング・システムが開発されているが、その
中で恐らく最も広く使われているのは、IBMシ
ステム／370上で走行するVM／370であると思わ
れる。VM／370オペレーテイング・システムは、
端末から操作する複数のユーザが、様々なデイス
クの量と記憶容量をもつ完璧なシステム／370を
有するかのような錯覚を生み出す。 物理的デイスク装置は、VM／370オペレーテ
イング・システムによつて管理される。デイスク
上に存在する物理的ボリユームが様々なサイズの
仮想ボリユームに分割され、ユーザが行なうマウ
ントと呼ばれる処理によつて割り振られアクセス
される。マウントとは、物理的ボリユームを定義
してVM／370オペレーテイング・システムに付
加し、ボリユームの仮想特性、たとえばサイズ、
セキユリテイ、所有権などを定義することであ
る。 さらに、VM／370の下では、ユーザは同じロ
ーカル・プロセツサ上でまたは遠隔の別のプロセ
ツサ上でVM／370の下で走行する、他のどのオ
ペレーテイング・システムにもアクセスしそれを
使用することができる。オースチンにいるユーザ
が、VM／370の「パススルー」の呼ばれる機能
を使つて同じプロセツサ上、または、たとえば、
同じSNAネツトワークに接続されたフランスの
パリにあるプロセツサ上の別のVM／370または
MV／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
Cororation，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）著「ユニツクス・オペレーテイング・シ
ステムの設計（Design of the Unix Operating
System）」、Prentice−Hall、1986年刊に出てい
る。 ATTのベル研究所は、多数の団体にUNIXオ
ペレーテイング・システム使用のライセンスを供
与しており、現在いくつかのバージヨンである。
ATTから出た最新のバージヨンは、バージヨン
5.2である。バークレイ・バージヨンとして知ら
れるUNIXオペレーテイング・システムの別のバ
ージヨンが、カリフオルニア州立大学バークレイ
校で開発された。広く使われているMS−DOS
（マイクロソフト社の商標）およびパーソナル・
コンピユータ用のPC−DOS（IBM社の商標）オ
ペレーテイング・システムを開発したマイクロソ
フト社（Microsoft）は、XENIXの商標で知ら
れるバージヨンを出している。IBMRT PC
（RISC（縮小命令セツト・コンピユータ）技術パ
ーソナル・コンピユータ、RTとRTPCはIBM社
の商標）を1985年に発表したのに伴つて、IBM
社はAIX（拡張対話型エグゼグテイブ、AIXは
IBM社の商標）と呼ばれる新しいオペレーテイ
ング・システムを公開した。AIXは、アプリケ
ーシヨン・インターフエース・レベルでATTの
UNIXオペレーテイング・システム、バージヨン
5.2と互換性があり、UNIXオペレーテイング・
システム、バージヨン5.2に対する拡張機能を含
んでいる。AIXオペレーテイング・システムの
詳細については、「AIXオペレーテイング・シス
テム技術解説書（AIX Operating System
Technical Reference）」、第１版、IBM Corp、
1985年11月刊を参照されたい。 本発明は、具体的には、複数のプロセツサがネ
ツトワーク内で相互接続されることを特徴とす
る、分散データ処理システムに関係する。実際に
実施された形では、本発明は、IBMのシステム
ネツトワーク・アーキテクチヤ（SNA）、さらに
具体的にはSNA LU6.2拡張プログラム間通信
（APPC）で相互接続された複数のIBMRT PC上
で機能する。SNAでは、そのリンク・レベルと
して、ゼロツクス社が開発したローカル・エリ
ア・ネツトワーク（LAN）であるイーサネツト
（Ethernetはゼロツクス社の商標）または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 Systems）」、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
は一連の刊行物に記載されている。たとえば、S.
R.クレイマン（Kleiman）「Ｖノード：Sun
UNIXにおける多重フアイル・システム・タイプ
用アーキテクチヤ（Vnodes：An Architecture
for Multiple File System Types in Sun
UNIX）」USENIX 1986年夏季国際技術会議・
展示会議事録、238−247ページ；R.サンドバー
グ（Russel Sandberg）等の「Sunネツトワー
ク・フアイル・システムの設計と実施（Design
and Implementation of the Sun Network
File System）」、UNENIX 1985年会議議事録、
119−130ページ；D.ウオールシユ（Dan Walsh）
等の「Sunネツトワーク・フアイル・システムの
概要（Overview of the Sun Network File
System）」117〜124ページ；ジヨメイ・チヤン
（Jomei Chang）の「状況モニタがNFSに対する
ネツトワーク・ロツキング・サービスをもたらす
（Status Monitor Provides Network Locking
Service for NFS）」；ジヨメイ・チヤンの「サン
ネツト（Sunnet）」、71−75ページ；B.テイラー
（Bradley Taylor）の「Sun環境における安全な
ネツトワーキング（Secure Networking in the
Sun Environment）」28−36ページ。AT＆Ｔの
RFSも一連の刊行物に記載されている。たとえ
ば、A.P.リフキン（Andrew P.Rifkin）等の
「RFSアーキテクチヤの概要（PFS
Arcchitectural Overview）」USENIX会議議事
録、ジヨージア州アトランタ（1986年６月）、１
−12ページ；R.ハミルトン（Richard
Hamilton）等の「遠隔フアイル共用に対する管
理者の意見」、１−９ページ；T.ヒユートン
（Tom Houghton）等の「フアイル・システム・
スイツチ（File Systems Switch）」、１−２ペー
ジ；D.J.オランダー（David J.Olander）等のシ
ステムＶにおけるネツトワークキング用フレーム
ワーク（Ａ Framework for Networking in
System Ｖ）」、１−８ページ。 本発明をその中で実施する分散サービス・シス
テムの、たとえばSun MicrosystemsのNFSとは
区別される一つの特徴は、Sunの方法が基本的に
非保存型マシーンを設計するためのものであつた
ということである。もつとも具体的に言うと、分
散システム内のサーバを無状態に設計することが
できる。すなわち、サーバは、どのクライエン
ト・ノードがサーバ・フアイルをオープンした
か、クライエント・プロセスが読取り専用モード
でフアイルをオープンしたのかそれとも読取り／
書込みモードでフアイルをオープンしたのか、あ
るいはクライエントがそのフアイルのバイト範囲
にロツクをかけているかどうかを含めて、クライ
エント・ノードに関する情報を何も記憶しない。
このような実施形態をとると、クライエント・ノ
ードが故障したり、あるいはサーバ資源に対する
要求を解除したとサーボにきちんと知らせずにオ
フラインになつたときに生じる、誤り回復状況を
サーバが処理する必要がないので、サーバの設計
が簡単になる。 本発明をその中で実施する分散サービス・シス
テムの設計では、全く異なる方法が取られた。も
つと具体的に言うと、この分散サービス・システ
ムは、「状態保存型インプリメーシヨン」である
と特徴づけることができる。本明細書に記載する
「状態保存型」サーバは、誰がそのフアイルを使
つているか、およびフアイルがどのように使われ
ているかに関する情報を保持する。それには、サ
ーバが何らかの方法であるクライエントとの接触
の喪失を検出して、そのクライエントに関する蓄
積された状態情報を廃棄できるようにする必要が
ある。しかし、本明細書に記載するキヤツシユ管
理戦略は、サーバがそうした状態情報を保持しな
い限り実施できない。キヤツシユの管理は、下記
で説明するように、サーバ・フアイルをオープン
せよとの要求を発行しているクライエント・ノー
ドの数およびそうしたオープンが読取りモードで
あるそれとも書込みモードであるかによつて影響
を受ける。 Ｃ 発明が解決しようとする問題点 したがつて、ネツトワーク内でのフアイルの位
置およびパフオーマンスに関してユーザ透過性を
もたらす、通信ネツトワーク内で相互接続された
多重プロセツサ式データ処理システムをサポート
するオペレーテイング・システム用の分散サービ
ス・システムを提供することが、本発明の一般的
目的である。 本発明の第二のより具体的な目的は、デツドロ
ツクの問題を防ぐためのフアイル・アクセス制御
構造ロツク（fasロツク）を備えた分散型フアイ
ル管理システム（DFS）をもたらす手法を提供
することである。 Ｄ 問題点を解決するための手段 本発明によれば、これらの目的は、遠隔システ
ムからアクセスされる各フアイルごとにfasロツ
クを作成することにより達成される。fasロツク
は、フアイルのｉノード（インデツクス・ノー
ド、フアイルの保護ビツト、種別、ポインタ等を
含むフアイル領域）をロツクする代わりにロツク
するのに使用される。こうすると、DFSがフア
イルに対するアクセスが制御し、デツドロツクの
問題の発生を回避することができる。 Ｅ 実施例 E1 はじめに 下記の開示では、物理的には異なる複数の計
算機内に存在するフアイルが、ローカル計算機
のフアイル・システムの一部分に見えるよう
に、計算機のフアイルを管理する論理が変更さ
れるという分散フアイル・システムを構築する
ときにぶつかる問題に対する解決策について説
明する。ここで説明するインプリメンテーシヨ
ンは、AIXオペレーテイング・システムのフ
アイル・システムの拡張である。このAIXオ
ペレーテイング・システムの詳細については、
前記で参照した技術解説書を参照されたい。木
構造フアイル・システム、デイレクトリ、およ
びｉノードを含むフアイル・システム構成など
のAIXフアイル・システムに関する特定の知
識があるものと仮定する。UNIXオペレーテイ
ング・システムでは、個々のデイスク（または
デイスケツト、またはデイスクの区画）にフア
イル・システムが含まれる。この議論に関係の
あるフアイル・システムの基本的態様を下記に
列挙する。 (a) 個別のフアイル・システム上の各フアイル
が、そのｉノード番号によつて一義的に識別
される。 (b) デイレクトリもフアイルであり、したがつ
てデイレクトリもそのｉノード番号によつて
一義的に識別できる。 (c) デイレクトリは、次の形式の項目の列を含
む。 名前−ｉノード番号 ただし、ｉノード番号は、単純フアイルのｉ
ノード番号でも別のデイレクトリのｉノード
番号でもよい。 (d) 規約により、フアイル・システムのルー
ト・デイレクトリのｉノード番号は、ｉノー
ド番号２とする。 したがつて、ある装置のフアイル・システム内
のパス“／dir1／dir2／file”をたどるには、次
のようなステツプをとる。 １ ｉノード番号２で識別されるフアイル（その
装置のルート・デイクトリ）を読み取る。 ２ そのデイレクトリを探索して、name＝dir1
の項目を見つける。 ３ dir1に関連するｉノード番号で識別されるフ
アイル（これはパス中の次のデイレクトリであ
る）を読み取る。 ４ そのデイレクトリを探索して、name＝dir2
の項目を見つける。 ５ dir2に関連するｉノード番号で識別されるフ
アイル（これはパス中の次のデイレクトリであ
る）を読み取る。 ６ そのデイレクトリを探索して、name＝file
の項目を見つける。 ７ このデイレクトリ内のフアイルに関連するｉ
ノード番号が、パス“／dir1／dir2／file”で
識別される単純フアイルのｉノード番号であ
る。 個別のフアイル・システム上に存在するフアイ
ル・ツリーは、あるノードの集合フアイル・ツリ
ーを構築するための構成要素である。あるノード
のルート・フアイル・システムを含む特定の装置
（たとえば、ハード・フアイル区画）を装置と呼
ぶ。マウント操作の実行により、別の装置上にあ
るフアイル・ツリーをノードのフアイル・ツリー
に付加することができる。マウント操作の２つの
主要パラメータは、(1)マウントされるフアイル・
ツリーを保持する装置の名前と(2)装置のフアイ
ル・ツリーをマウントするデイレクトリへのパス
である。このデイレクトリは、すでにノードのフ
アイル・ツリーの一部分でなければならない。す
なわち、ルート・フアイル・システム内のデイレ
クトリ、または（マウント操作によつて）ノード
のフアイル・ツリーにすでに付加されたフアイ
ル・システム内のデイレクトリでなければならな
い。 マウントの実行後は、普通なら「上にマウント
された」デイレクトリを通つて流れるはずのパス
が、マウントされたフアイル・システムのルート
ｉノードを通つて流れる。マウント操作は、次の
ように進行する。 １ マウント点までパスをたどり、マウントされ
る装置がカバーするデイレクトリのｉノード番
号と装置番号を入手する。 ２ 基本的に次のものを含むデータ構造を作成す
る。 (a) カバーされるデイレクトリの装置番号とｉ
ノード番号 (b) マウントされる装置の装置名 ノードの集合フアイル・ツリー内でのパスのた
どり方は、(a)上にマウントされたｉノード（また
はもちろんパスの終点）にぶつかるまで、装置フ
アイル・ツリー内のパスをたどること、(b)マウン
ト点にぶつかるとマウント・データ構造を使つ
て、パス中で次にどの装置があるか判定するこ
と、および(c)マウント構造内で指示される装置中
のｉノード２（ルートｉノード）からパスをたど
り始めることからなる。 マウント・データ構造は揮発性である。すなわ
ちデイスク上に記載されない。初期プログラム・
ロード（IPL）の一部として計算機が電源投入さ
れるたびに、所期のマウントのリストを再発行し
なければならない。以上の議論では、従来の
UNIXオペレーテイング・システムがフアイル・
システム全体のマウントをどのように使つてフア
イル・ツリーを作成し、またそのようなフアイ
ル・ツリー内でどのようにパスをたどるか説明し
た。こうしたインプリメンテーシヨンは、ある装
置上に存在するフアイル・システム全体をマウン
トすることに限定されている。本明細書に記載す
る仮想フアイル・システム・コンセプトは、(1)装
置をマウントできる上にデイレクトリもマウント
できるようにすることにより、ある装置上に存在
するフアイル・システムの一部分をマウントする
こと、および(2)すでにフアイル・ツリーの一部分
になつているデイレクトリ上に、遠隔デイレクト
リまたはローカル・デイレクトリをマウントする
こと、さらに(3)すでにフアイル・ツリーの一部分
になつているフアイルの上に（遠隔またはローカ
ル）フアイルをマウントすることができるとい
う、仮想フアイル・システム・コンセプトの改良
である。 仮想フアイル・システムでは、特定の装置フア
イル・システム上で実行される操作が、ノードの
集合フアイル・ツリーの構築および使用に関する
操作からはつきり分離される。ノードの仮想フア
イル・システムは、ローカル・フアイルおよび遠
隔フアイルの両方に対するアクセスを可能にす
る。 ローカル・フアイルの管理は、遠隔フアイルの
管理よりも簡単な問題である。このため、仮想フ
アイル・システムの考察を２つの部分に分ける。
第１の部分では、ローカル操作のみについて説明
する。この部分は、遠隔操作を考察するための基
礎となる。遠隔操作にもローカル操作にも同じデ
ータ構造と操作が使われる。ローカル操作の考察
では、データおよび手順のうちスタンドアロン操
作にとつて重要な態様について説明する。遠隔操
作の考察では、遠隔操作に関連する情報を付け加
えるが、ローカル操作の部で考察したことを繰り
返さない。 第５図は、仮想フアイル・システムのデータ構
造間に存在する関係を示したものである。各マウ
ント操作で、新しい仮想フアイル・システム
（vfs）データ構造が作成される。この構造中の基
本要素は、(a)はこの仮想フアイル・システムのル
ートｖノード（仮想ノード）を指すポインタ（た
とえば、ブロツク２１からブロツク２３への矢
印）、および(b)この仮想フアイル・システムが作
成されたときに上にマウントされたｖノードを指
すポインタ（たとえば、ブロツク２５からブロツ
ク２４への矢印）である。 ｉノードをフアイル・システムとは独立なシス
テム部分で表わす必要がある場合、それはｖノー
ドで表わされる。この構造の基本要素は、次のも
のである。 (a) そのｖノードを含む仮想フアイル・システム
を指すポインタ（たとえば、ブロツク２２から
ブロツク２１への矢印）。 (b) このｖノードの上にマウントされた仮想フア
イル・システムを指すポインタ（たとえば、ブ
ロツク２４からブロツク２５への矢印）。ただ
し、すべてのｖノードが仮想フアイル・システ
ムのマウント点なのではないことに留意された
い。すなわち、空白ポインタはこのｖノードが
マウント点でないことを示す。 (c) 代理ｉノードまたは実ｉノードのどちらかを
指すポインタ（たとえば、ブロツク２６からブ
ロツク３２への矢印）。 (d) ノード・テーブル項目を指すポインタ（これ
はフアイルが遠隔フアイルであるときだけ空白
でない）。 AIXオペレーテイング・システムは、他の
UNIXオペレーテイング・システムと同じく、シ
ステムが使用している各ｉノードについての情報
を含むメモリ常駐テーブルを保持する。たとえ
ば、あるフアイルをオープンするとき、デイスク
からそのｉノードが読み取られ、このｉノード情
報のサブセツトが若干の追加情報と共にｉノー
ド・テーブルに記憶される。ｉノード・テーブル
項目の基本要素は、(a)フアイル・アクセス構造リ
ストの先頭を指すポインタと、(b)デイスクｉノー
ドからの情報（その詳細はここでは重要ではな
い）である。 フアイル・アクセス構造は、どのノードでフア
イルがオープンになつているか、およびそれらの
オープンのモード（読取り専用または読取り／書
込み）に関する情報を記録する。フアイルがオー
プンになつている各ノードごとに別々のフアイ
ル・アクセス構造がある。この状態情報を使う
と、各クライエントがサーバ・フアイルをどのよ
うに使つているかをサーバを知ることができる。 フアイル・システムは、その上で実行される１
組の操作をサポートする。次のようにフアイル・
システム操作を実行することにより、プロセスが
フアイル・システムと対話する。 １ ユーザが（おそらく）いくつかの入力パラメ
ータをもたらす操作の一つの呼び出す。 ２ フアイル・システム論理が、フアイル・シス
テムの内部データ状態を変更し得る操作を実行
する。 ３ フアイル・システム論理が、おそらくは若干
の戻りパラメータを戻して、呼びし側ユーザに
戻る。 フアイル・システム上で実行できる操作は、
“vn操作”と呼ばれる。いくつかのvn操作がある
が、この考察で重要なものについて下記で説明す
る。 vn−lookup vnルツクアツプ操作では、フアイル・システ
ム内のパスをたどる際の基本的反復ステツプは、
デイレクトリ内でパス構成要素の名前を探し出
し、関連するｉノード番号を使つてチエーン中の
次のフアイルを探し出すというものである。vn
ルツクアツプ操作の擬似コードを下記に示す。 ルツクアツプ機能 入力：デイレクトリのｖノード・ポインタ、デイ
レクトリ中でルツクアツプすべき名前 出力：指定されたフアイル／デイレクトリを指す
ｖノード・ポインタ デイレクトリのｖノード・ポインタをｉノー
ド・ポインタに変換する； −−ｖノード中でポインタを使うデイレクトリ
のｉノードをロツクする IF（デイレクトリ中で探索許可をもつていなけ
れば） デイレクトリｉノードをアンロツクする； エラーを戻す； デイレクトリで名前を探索する； IF（見つかつたなら） 名前に対するフアイル・ハンドルを作成する； −−デイレクトリ・エントリ中で見つかつたｉ
ノードを使う； フアイル・ハンドルに対するｖノードを指すポ
インタを得る； デイレクトリｉノードをアンロツクする； ｖノードを指すポインタを戻す； ELSE−−見つからなかつた デイレクトリｉノードをアンロツクする； エラーを戻す； vn open vn open機能は、どのオープン・モード（読
取り／書込みまたは読取り専用モード）でフアイ
ルをオープンするかを記録するフアイル・アクセ
ス構造を作成する（または、既存のフアイル・ア
クセス構造を修正する）。vnオープン操作の擬似
コードを下記に示す。 vnオープン機能 入力：オープンされるフアイルに対するｖノー
ド・ポインタ オープン・フラグ（たとえば、読取り専用また
は読取り／書込み） モード作成−−作成する場合はフアイル・モー
ド・ビツト 出力：成功または失敗を示す戻りコードフアイル
のｉノードを指すポインタをｖノードから得
る： ｉノードをロツクする； IF（アクセスを許可されないなら） ｉノードをアンロツクする； （エラー）を返す； このクライエントのためのフアイル・アクセス
構造を得る； −−フアイル・アクセス構造がない場合は、一
つ割り振る IF（フアイル・アクセス構造を割り振ることが
できなかつたなら） ｉノードをアンロツクする； （エラー）を返す； フアイル・アクセス構造読取り専用、読取り／
書込み、およびテキスト・カウントを更新す
る； IF（打切りモードがセツトされているなら） フアイルを打ち切る； ｉノードをアンロツクする； lookuppn lookuppn操作とは、パスをたどる機能である。
その入力はパス（たとえば“／dir1／dir2／
file”）であり、その戻りコードはそのフアイル
を表わすｖノードを指すポインタである。 lookuppnは一つのデイレクトリを読み取るため
vn lookupを呼び出し、次にvn lookupから戻
されたｖノードがすでに上にマウントされている
かどうか検査する。ｖノードが上にマウントされ
ていない場合、lookuppnは同じフアイル・シス
テム中のvn lookupを呼び出す。ｖノードがす
でに上にマウントされている場合は、lookuppn
は上にマウントされたｖノード（たとえば第５図
のブロツク２４）からマウントされたフアイル・
システムの仮想フアイル・システム（たとえば第
５図のブロツク２５）へとポインタをたどる。仮
想フアイル・システムから、ルートｖノード（た
とえば第５図のブロツク２６）へとポインタをた
どり、ｖノードが単純フアイルではなくデイレク
トリである場合は、その仮想フアイル・システム
のルートｖノードとパス中の次の要素を構成する
名前を入力として与えて、新しいvn lookupを
発行する。lookuppn機能の擬似コードを下記に
示す。 lookuppn機能 入力：パス名 出力：指定されたフアイルに対するｖノードを指
すポインタ IF（パスの最初の文字が‘／’なら） 探索すべき現ｖノードはユーザのルート・デイレ
クトリのｖノードである； ELSE 探索すべき現ｖノードはユーザの現デイレクトリ
のｖノードである； 繰り返す 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はデイレ
クトリを読み取り、その名前に関連するｉノード
（ブロツク３４）を見つけ、親仮想フアイル・シ
ステム（ブロツク２５）内でこのｉノードに対す
るｖノード（ブロツク２８）を見つけまたは作成
し、このｖノードを指すポインタを戻す。システ
ム・コールを実施したコードは、次にフアイル上
で要求された操作を実行する。 次に、アプリケーシヨン・プロセスが、フアイ
ル“／ｕ／group”をデイレクトリ“／ｕ／foo”
の上にマウントするため、「マウント」システ
ム・コールを発行するものと仮定する。下記のシ
ナリオで、この要求がオペレーテイング・システ
ムによつてどのように実行されるかを説明する
（この場合も、UNIXオペレーテイング・システ
ムと基本的に異ならない操作は詳しくは説明しな
い）。 このシナリオでは、第６図と第７図は参照す
る。第６図は初期状態を表わし、第７図は最終状
態を表わしたものである。次の仮定を設する。ま
ず、ブロツク４１で表わされる仮想フアイル・ブ
ロツクがルート仮想フアイル・ブロツクである。
第二に、関係するデイレクトリとフアイルは、す
べて同一装置上にある。第三に、下記のデイレク
トリ項目が指示したデイレクトリ内にある。 デイレクトリ ｉノード番号 名前 ｉノード番号 ２ “ｕ” 15 ２ “etc” 83 15 “gorp” 92 83 “foo” 75 75 “filel” 89 マウント・システム・コールを実施するコード
は、次の操作を実行する。上にマウントされるフ
アイル“／etc／foo”へのパスをたどるため、
lookuppnを呼び出す。この操作が完了したとき、
ルート仮想フアイル・システム（ブロツク４１）
は、“／etc／foo”に対するｖノード（ブロツク
４４）を含んでいる。このｖノードは、ルート仮
想フアイル・システム（ブロツク４１）を指すポ
インタと、ｉノード７５に対するｉノード・テー
ブル項目（ブロツク４５）を指すポインタを有す
る。マウントされるフアイル“／etc／gorp”へ
のパスをたどるため、lookuppnを呼び出す。こ
の操作が完了したとき、ルート仮想フアイル・シ
ステム（ブロツク４１）は“／etc／gorp”に対
するｖノード（ブロツク４９）を含んでいる。こ
のｖノードは、ルート仮想フアイル・システム
（ブロツク４１）を指すポインタと、ｉノード９
２に対するｉノード・テーブル項目（ブロツク４
８）を指すポインタを有する。ここでマウント論
理は、新しい仮想フアイル・システムを作成す
る。それには、まず新しい仮想フアイル・システ
ム（ブロツク４６）を作成し、次に遡つて親仮想
フアイル・システム（ブロツク４６）を指すポイ
ンタと、ルートｉノード（ｉノード９２、ブロツ
ク４８）を指すポインタとを有する、この仮想フ
アイル・システムに対するルートｖノード（ブロ
ツク４７）を作成する。「上にマウントされる」
ポインタが、ルート仮想フアイル・システム（ブ
ロツク４１）内のカバーされるｖノード／ブロツ
ク４４）に挿入され、上にマウントされるｖノー
ド（ブロツク４４）を指すポインタが新しい仮想
フアイル・システムに挿入される。 E2 分散フアイル・システムにおける操作 以上、スタンドアロン操作用のデータ構造に
ついて説明した。次に第１図には、本発明をサ
ポートするオペレーテイング・システムを実施
した第２図のものと同様の分散システムが示さ
れている。以下の説明では、フアイルが永久的
に記憶されているノードを指すのに「サーバ」
という言葉を使い、そのフアイルにアクセスす
るプロセスを有する他の任意のノードを指すの
に「クライエント」の語を使うことにする。た
だし、「サーバ」の語は、一部のローカル・エ
リア・ネツトワーク・システムで使われている
ような専用サーバを意味しないことを了解され
たい。本発明をその中で実施する分散サービ
ス・システムは、システムの様々なノードで走
行しシステム内のどこにあるフアイルにでもア
クセスする、広範なアプリケーシヨンをサポー
トする、真の分散システムである。 第１図に示した分散システム用のデータ構造
を第８図に示し、そのデータ構造の構成部分を
第９Ａ図ないし第９Ｆ図に示す。第８図を参照
すると、クライエント・ノードは、遠隔サー
ド・ノード内にあるフアイルにアクセスするこ
とができる。こうしたクライエントは、サーバ
の１つのデイレクトリをマウントすることによ
りサーバのフアイルに対するアクセス権を得
る。そのクライエント・ノードでは、遠隔マウ
ント操作によつて作成されるデータ構造が、ロ
ーカル・エンテイテイをマウントすることによ
つて作成されるデータ構造と同等である。ロー
カルの場合と同じく、間隔マウント操作で、ク
ライエント・ノード中に仮想フアイル・システ
ム（vfs、たとえばブロツク５４）が作成され
る。ローカルの場合と同じく、遠隔フアイルを
含む仮想フアイル・システム中のフアイルを使
用すると、クライエント・ノード中にｖノード
構造（たとえばブロツク５７）が作成される。
ローカルの場合と同じく、このｖノード構造は
ｉノード・テーブル項目（たとえばブロツク６
３）を指すポインタを有する。ただし、このｉ
ノード・テーブル項目は、遠隔フアイルからの
ｉノード情報を含まず、その代わりに代理ｉノ
ードを含む。この代理ｉノードは、遠隔ｉノー
ドの代理である。 サーバ・ノードでは、遠隔ノードがサーバの
フアイルをどのように使用しているかに関する
状態情報をサーバが記録できるように、ある種
のデータ構造が構築される。もつと具体的に言
うと、各サーバは、遠隔クライエントによつて
オープンになつているフアイルを保持するため
の仮想フアイル・システムとして「ダミー仮想
フアイル・システム」（たとえばブロツク７１）
を有する。ダミー仮想フアイル・システムは、
サーバのフアイル・ツリーの一部ではない。遠
隔ノードによつてオープンになつている各フア
イルに対して、サーバのダミー仮想フアイル・
システム中にｖノード（たとえばブロツク７
４）がある。遠隔ノードによつてオープンにな
つている各フアイルは、サーバのｉノード・テ
ーブル中にｉノード・テーブル項目（たとえば
ブロツク８８）を有する。このｉノード・テー
ブル項目は、サーバにあるローカル・プロセス
がフアイルをオープンしたために存在するテー
ブル項目と同じである。たとえば、遠隔オープ
ンのゆえにテーブル中に存在するブロツク８４
は、サーバでの操作のゆえにテーブル中に存在
するブロツク８８に同じ構造である。 あるクライエントとサーバがあるサーバ・フ
アイルに関して通信するとき、フアイルを識別
する方法が必要となる。これは、フアイル・ハ
ンドルによつもたらされる。クライエントの要
求が出て、サーバが特定フアイルの指定を伴つ
て回答する（たとえば遠隔ルツクアツプ要求）
とき、そのフアイルはフアイル・ハンドルで識
別される。クライエントの要求が特定フアイル
の指定を含む（たとえば遠隔オープン要求）と
き、そのフアイルはフアイル・ハンドルで識別
される。フアイル・ハンドルは、装置番号、ｉ
ノード信号、ｉノード世代番号の各フイールド
を含んでいる。 フアイル・ハンドルの必要性は、次のシナリ
オからわかる。次のように仮定する。クライエ
ントがサーバに要求を出して、回答中でフアイ
ル・ハンドルを受け取る。クライエントは、そ
のフアイル・ハンドルを記憶し覚える。サーバ
での何らかの活動によつてそのフアイルが削除
され、ｉノード・スロツトが別のフアイル用に
再使用される。クライエントが記憶しているフ
アイル・ハンドルを使つてサーバに要求を出
す。サーバはフアイル・ハンドルを受け取り、
新しいフアイルで操作を実行する。そうなる
と、その操作は許容できないものとなるばすで
ある。 この欠点は、ｉノード世代番号を使うことに
よつて防止される。ｉノード世代番号は、ｉノ
ード中のフイールドとしてデイスク上に記憶さ
れる。サーバがあるフアイルを削除するとき、
そのｉノード世代番号を増分する。要求がサー
バに届いたとき、フアイル・ハンドルは分離さ
れ、装置番号とｉノード番号がｉノードを探し
出すのに使われ、その後フアイル・ハンドルの
ｉノード世代番号がｉノードのｉノード世代番
号と比較される。両者が異なる場合、その要求
は拒否される。 クライエントが遠隔サーバ上にあるフアイル
をオープンしたいとき、ネツトワーク移送機構
を使つてサーバとの接続を確立する。このフア
イルに関する以後のトランザクシヨン（たとえ
ば、読取り、書込みなど）は、この接続上を流
れる。各ノードはノード・テーブルを含んでい
る。ノードはそのノード・テーブル内の項目
（たとえばブロツク７０）を用いて、遠隔ノー
ドに対する既存の接続に関する情報を記録す
る。 ネツトワーク内の１つのノードが別のノード
に自分のために実行を要求できる操作が少数あ
る。こうした操作は、dfs操作と呼ばれる。あ
るノードが別のノードに要求を出すとき、次の
操作が行なわれる。まず、要求側ノードは、ど
のdfs操作を要求しているか指定し、その要求
に適したパラメータを運ぶメツセージを送る。
次に受取側ノードは要求を受け取つて指定され
た操作を実行する。最後に、受取側ノードは、
そのdfs操作に適した回答パラメータを運ぶメ
ツセージを送る。 ローカルノード内でフアイル・システムに対
して発行されるvn操作と、ネツトワークを介
して発行されるdfc操作の間には、緊密な関係
がある遠隔フアイルに対する典型的な操作は次
の通りである。まず、ローカル・カーネルが、
操作中のフアイルが遠隔かそれともローカルか
知らずに、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マウント要求に対する
回答中でこのフアイル・ハンドルを受け取り、
次のような新しい仮想フアイル・システムを作
成するのに必要な操作を実行する。 (a) 新しい仮想フアイル・システム（ブロツ
ク５４）を作成する。 (b) 遡つて親仮想フアイル・システム（ブロツ
ク５４）を指すポインタとルートｉノード
（ブロツク６２）を指すポインタとを有する、
この仮想フアイル・システムに対するルート
ｖノード（ブロツク５５）を作成する。この
仮想フアイル・システムのルートｉノードは
遠隔フアイルであるため、ルートｖノードか
ら指されるｉノードは代理ｉノードである。
この代理ｉノードは、クライエントのdfsマ
ウント要求に対してサーバが戻したフアイ
ル・ハンドルを含んでいる。 (c) 「上にマウントされる」ポインタを、ルー
ト仮想フアイル・システム（ブロツク５１）
内のカバーされたｖノード（ブロツク５３）
に挿入する。 (d) 上にマウントされるｖノード（ブロツク５
３）を指すポインタを新しい仮想フアイル・
システム（ブロツク５４）に挿入する。 次に、上記の遠隔マウント（クライエント
の／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は見つかつたｖノード（ブロツク５
５）を指すポインタをその呼出し側に戻す。シ
ステム・6cxzコールを実施するコードは、次
にそのフアイルに対して要求された操作を実行
する。 E3 フアイル・アクセスの同期モード 本発明が実施される第１図に示すような分散
型サービス・システムでは、ローカル・キヤツ
シユ１２Ａ，１２Ｂおよび１２ＣがノードＡ，
ＢおよびＣごとに存在する。フアイル５がノー
ドＡのデイスク２Ａに永久的に存在する場合、
サーバ・ノードＡで実行されるローカル・プロ
セス１３Ａによるキヤツシユ１２Ａの使い方
は、上述のスタンドアロン・システムの場合と
同じである。しかし、ノードＢおよびＣでそれ
ぞれ実行される遠隔プロセス１３Ｂおよび１３
Ｃは、第３図に示すようにサーバ・キヤツシユ
およびクライエント・キヤツシユを使用する２
ステツプ・キヤツシユ方式によつてフアイル５
にアクセスする。サーバ・ノードはデイスク２
Ａからフアイル・ブロツク５を得、それをサー
バ・キヤツシユ１２Ａに記憶する。クライエン
ト・ノードＢはネツトワーク３を介して出て行
き、サーバ・キヤツシユ１２Ａからフアイル５
のブロツク５を得る。クライエント・ノードＢ
は、フアイル５のブロツク５を、サーバ・キヤ
ツシユ１２Ａ内に存在していた通りに、クライ
エント・キヤツシユ１２Ｂに記憶する。クライ
エント・ノードＢのユーザ・アドレス・スペー
ス１４Ｂがフアイル５の任意のブロツクからデ
ータをシークするとき、各アクセスごとにネツ
トワーク３を介して出て行く代わりに、クライ
エント・キヤツシユ１２Ｂがアクセスされる。
クライエント・キヤツシユ１２Ｂを使つて遠隔
フアイル５にアクセスすると、ネツトワーク・
トラフイツクおよびオーバーヘツドを節約でき
るので、処理能力を大幅に向上させることがで
きる。 本発明のシステムおよび方法は、アプリケー
シヨン・プログラム・レベルでフアイル・アク
セス意味論を保持しながら高い処理能力を得る
ように、分散型環境でクライエント・キヤツシ
ユ１２Ｂおよびサーバ・キヤツシユ１２Ａの使
用を管理するものである。これにより、スタン
ドアロン・システムで実行される既存のプログ
ラムが、何らの変更もなく分散型システムで実
行することが可能になる。フアイル・アクセス
意味論は、フアイルにアクセスしてそれを変更
するために読取りおよび書込むシステム・コー
ルを発行する様々な処理によつてオープンされ
るとき、フアイルの整合性を保持する。フアイ
ル・アクセス意味論は、任意のバイト範囲で一
度に一つの入出力動作のみが許されることを要
求し、一度入出力動作が開始すると、フアイル
の同じバイト範囲に対して他の入出力動作が優
先使用を行なうことはできない。 第１３図を参照して上記の例を示す。プロセ
ス１３１がフアイル５のバイト範囲N1−N2に
書込みシステム・コールを発行した場合、バイ
ト範囲N1−N2全体がプロセス１３１によるア
クセスのために使用可能なとき、その書込みシ
ステムコールだけが実行でき、バイト範囲N1
−N2に関する読取り動作は全く実行されない。
書込みシステム・コールの実行中、フアイル５
のバイト範囲N1−N2に関する他のすべての動
作は、書込みが終了するまで延期される。バイ
トがローカル・キヤツシユ１２Ａに書き込まれ
るまで、書込みは終了しない。書込み要求が終
了すると、キヤツシユ１２Ａに書込まれたデー
タは、他のプロセス１３１ないし１３Ｎのいず
れかによる後続の読取り動作に見えるようにな
る。 フアイル・アクセス意味論のもう一つの要件
は、N1−N2等のフアイル・バイト範囲（同じ
入出力動作によつてアクセスされるレコードま
たは一組の関連レコードでよい）が読取りプロ
セスから見えるとき、フアイル・バイト範囲
N1−N2は常に、この範囲に対する最後の更新
を反映する一貫した一組のデータを含まなけれ
ばならないということである。この範囲は、書
込み動作が実行されている間、アクセスのため
に使用することができない。このようにして、
プロセスによつて発行される次の読取りは書き
込まれたばかりのデータを読み取り、古い陳腐
化したデータを読み取ることはない。 第１図に示す本発明の分散型ネツトワーク環
境では、異なるアプリケーシヨン・プログラム
４Ａおよび４Ｂ、プロセス１３１ないし１３Ｎ
および２３１ないし２３Ｎからの読取りおよび
書込みシステム・コールの実行が、前述のフア
イル・アクセス意味論が保持されるように同期
される。本発明のシステムおよび方法では、
種々のキヤツシユ同期モードを用いて同期を保
証する。特定のフアイル５に対して、入出力コ
ールは、アクセスのためにフアイル５をオープ
ンするプロセス１３１ないし１３Ｎまたは２３
１ないし２３Ｎの位置および同期モードに応じ
て、クライエント１３またはサーバＡによつて
同期される。 ３種類の同期モードを第１４図に示し、第１
図と関連して説明する。最初のモード１０４は
非同期モードと呼ばれる。第１４図のブロツク
１０７に示すように、ただ一つのクライエント
遠隔ノードＣで実行されるプロセス１３Ｃによ
る読取り／書込みアクセスのためにフアイル５
がオープンされる場合、フアイル５はこのモー
ド１０４で動作する。このモード１０４では、
制御権はすべてクライエント・ノードＣにあ
る。サーバ・キヤツシユ１２Ａおよびクライエ
ント・キヤツシユ１２Ｃがこれらの読取り／書
込み動作のため使用される。読取りまたは書込
み動作では、クライエント・キヤツシユ１２Ｃ
から満足され得ない場合のみ、サーバ・キヤツ
シユ１２Ａに対するアクセスが必要となる。フ
アイル５がクライエント・ノードＣのすべての
プロセス１３Ｃによつてクローズされるとき、
または、クライエント・ノードＣの他のデータ
のもつと場所が必要とされるとき、クライエン
ト１２Ｃにある修正されたブロツクが周期的同
期動作によりサーバ１２Ａに書き込まれる。ま
た、フアイルが非同期モードから全同期モード
に変わるとき、修正されたブロツクがサーバに
書き込まれる。 第二のモード１０５は読取専
用モードである。 読取専用モード１０５は、第１４図のブロツ
ク１０８に示すように、ただ一つのノードＣ内
のプロセス１３Ｃからの、または複数のノード
ＢおよびＣ内のプロセス１３Ｂおよび１３Ｃか
らの読取り専用アクセスのためにオープンされ
るフアイル５に使用される。このモード１０５
では、サーバ・キヤツシユ１２Ａおよびクライ
エント・キヤツシユ１２Ｂまたは１２Ｃあるい
はその両方が使用される。読取り要求は一度に
１ブロツクまたは複数のブロツクに対して発行
される。同じクライエントＢまたはＣからの特
定のブロツクに対する１回おきの読取り要求は
サーバ１２に行かず、その代わりに、当該のク
ライエント・キヤツシユＢまたはＣから読み取
られる。言い換えると、読取り動作では、クラ
インエント・キヤツシユ１２Ｃまたは１２Ｂか
ら満足される場合、サーバ１２Ａに対するアク
セスが必要でない。要するに、ノードＡ，Ｂま
たはＣのいずれかにおけるプロセス１３Ａ，１
３Ｂまたは１３Ｃのいずれかによる読取り専用
アクセスのためにフアイル５がオープンされる
場合は、フアイル５はモード１０５で動作す
る。 第三のモード１０６は全同期モードである。
全同期モード１０６は複数のフアイルＡ，Ｂで
オープンされているフアイル５のため使用さ
れ、少なくとも１つのノードが書込みアクセス
のためにフアイルをオープンしている。全同期
モード１０６では、クライエント・キヤツシユ
１２Ｃまたは１２Ｂは迂回され、サーバ・キヤ
ツシユ１２Ａのみが使用される。読取りおよび
書込み動作はすべてサーバ１２Ａで実行され
る。 第１図に示す分散型環境１では、大部分のフ
アイル５は、第１４図に示す読取専用モード１
０５である複数のノードＡ，ＢおよびＣにおけ
るプロセス１３Ａ，１３Ｂおよび１３Ｃによる
読取りのみのためにオープンされたり、非同期
モード１０４にあるただ一つのノードでの更新
のためにオープンされる場合が多く、全同期モ
ードにある複数ノードで実行されるプロセスに
よる読取りおよび書込みアクセスのためにオー
プンされることはそれほど頻繁ではない。第１
３図に示すように、読取専用モード１０５およ
び非同期モード１０４でクライエント・キヤツ
シユ１２Ｂを使用するため、フアイル５にアク
セスする遠隔読取り／書込み応答時間が大幅に
減少し、システムの全体的処理能力が向上す
る。 第１５図に示すように、全同期モードでは、
クライエント・キヤツシユは使用されない。ク
ライエント・ノードＢは、各読取りおよび書込
み動作ごとにネツトワーク３を介してサーバＡ
からのフアイル５にアクセスする。このモード
では読取り／書込み応答時間は増加するが、ク
ライエントは、ローカル・キヤツシユ中に、サ
ーバに存在している対応するフアイルと共に更
新されなかつたフアイル５を保持しないので、
フアイル・アクセス意味論は保持される。 ３種類のモードを使用してクライエント・キ
ヤツシユの使用を管理すると、読取り／書込み
応答速度が全体として平均的に増加することと
フアイルの整合性が組み合わされて、システム
の全体的処理能力が最適になる。ある場合にク
ライエント・キヤツシユの使用で読取り／書込
み応答時間が減少し、別の場合にはクライエン
ト・キヤツシユを使用しないことでフアイル・
システムの意味論が保持される。 フアイルの同期モードは、どのノードがフア
イルをオープンするか、およびフアイルが読取
りのためにオープンされるのかそれとも書込み
のためにオープンされるのかだけでなく、フア
イルが存在する装置が生アクセス・モードでオ
ープンされるかどうかによつても決まる。装置
に対する生アクセスとは、装置2A内の第１３
図に示すデータ・ブロツクLBN1がアクセスさ
れるという意味である。したがつて、装置２Ａ
の読取りおよび書込みは、装置２Ａのブロツク
LBN1に対する読取りおよび書込みとなる。ブ
ロツクがどのフアイルに属するかは関係ない。
サーバ・ノードＡにある処理１３１ないし１３
Ｎからの生アクセスのために装置２Ａをオープ
ンすることができる。遠隔ノードＢまたはＣか
らの生アクセスのために装置２Ａをオープンす
ることはできない。 第１３図では、第３図に関連して上述したス
タンドアロン・システムと同様に、キヤツシユ
１２Ａは装置２ＡのブロツクLBN1として管理
される。サーバＡは、サーバ・キヤツシユ１２
Ａを装置２Ａ内の論理ブロツクLBN1として見
る。クライエントＢは、フアイル５が装置２の
どこにあるか、全く知らない。クライエントＢ
が知つていることは、装置２Ａ上のブロツク番
号N1にあるフアイルにアクセスしていること
だけである。クライエント・キヤツシユ１２Ｂ
は、データをフアイル５の論理ブロツクN1と
して処理する。サーバ・キヤツシユ１２Ａで
は、データは装置２Ａの論理ブロツクLBN1と
して処理される。データをこのように処理する
際、データが生装置としての装置に書き込まれ
る場合、および、装置に書き込まれたブロツク
と同じフアイルのブロツクが次に読み取られる
場合、この読取りで新たに書き込まれたデータ
が見えることをサーバは保証することができ
る。このため、フアイル・システムの意味論が
保持される。 第１３図に示すように、フアイルがクライエ
ント・ノードＢでアクセスされ、フアイルが非
同期モードまたは読取専用モードにある場合、
クライエント・オペレーテイング・システム１
１Ｂは読取りシステム・コール１６におけるフ
アイル内のフアイル記述子およびバイト範囲
（フアイル記述子、N1）を装置番号および装置
内の論理ブロツク番号に変換しない。クライエ
ントは、フアイル記述子およびバイト範囲をフ
アイル・ハンドル、ノード識別子、およびフア
イル内の論理ブロツク番号に変換する。クライ
エント・キヤツシユ１２Ｂでは、フアイル・ハ
ンドル、ノード識別子、およびフアイル内の論
理ブロツク番号によつて指定されるブロツク１
７がある。クライエント・アプリケーシヨン４
Ｂから読取りコール１６が発行されると、読取
り要求が、フアイル内のフアイル記述子および
バイト範囲と共にオペレーテイング・システム
に送られる。オペレーテイング・システムは次
にクライエント・キヤツシユ１２Ｂを調べる。
フアイル・ハンドル、ノード識別子、およびフ
アイル内の論理ブロツク番号がそこにある場合
は、キヤツシユ１２Ｂを読み取り、そこにない
場合は、その読取り要求がサーバに送られる。
サーバはそこでフアイル・ハンドルおよびフア
イル内の論理ブロツク番号を取り出し、それを
装置番号および装置内の論理ブロツク番号に変
換する。この変換が必要なのは、サーバ・キヤ
ツシユ１２Ａは、スタンドアロン・システムの
場合と同様に、装置番号および装置内のブロツ
ク番号によつて管理されるためである。読取り
要求はサーバに送られた後、第３図と関連して
説明したスタンドアロン・システム内でその自
体のアプリケーシヨンからきた場合と同様に処
理される。 クローズされたフアイルは同期モードを持た
ない。しかし、一度フアイルがまずプロセスに
よつてオープンされると、フアイルの同期モー
ドは、第１６図に示すように、以下に従つて初
期設定される。フアイルが存在する装置がクロ
ーズされている（１１２）、すなわち、特別な
装置としてオープンされていず、かつフアイル
が１つの遠隔ノードでの書込みアクセスのため
にオープンされている（１１３）場合は、フア
イルの同期モードは非同期１０４に初期設定さ
れる。フアイルが存在する装置がクローズされ
ており、かつフアイルが一つまたは複数のノー
ドでの読取り専用アクセスのためにオープンさ
れている（１１４）か、または、装置およびフ
アイルの両方が読取専用アクセスのためにオー
プンされている（１１５）場合は、フアイルに
同期モードは読取専用モード１０５である。フ
アイルが存在する装置が読取り／書込みアクセ
スのためにブロツク特別装置としてオープンさ
れており（１１６）、または、フアイルが複数
のノードでオープンされ、オープンの少なくと
も１つは書込みのためである場合は、フアイル
の同期モードは全同期モード１０６に初期設定
される。ブロツク特別装置とは、装置に対して
生アクセスがあるという意味である。 一度フアイルがあるモードに初期設定される
と、状態が変化した場合、フアイル・モードが
変わることがある。第１６図の線１１８ないし
１２３に示すように、あるモードから別のモー
ドへの移行は以下の条件下で行なわれる。フア
イルが現在非同期モード１０４にあり、フアイ
ルがオープンされているノードの数が２以上に
なる場合１２４、同期モードは、線１１９で示
すように、全同期１０６に変わる。さらに、フ
アイルが存在するブロツク特別装置Ｄがオープ
ンされている場合（１２５）、同期モードは非
同期モード１０４から全同期モード１０６に変
わる。フアイルに対するクローズ動作では、そ
のクローズ動作がフアイルの最後のクローズで
なくして、フアイルが書込みのため依然として
オープンされている場合、モードの変化はな
い。しかし、クローズ動作が書込みアクセスに
対するフアイルの最後のクローズであり、残り
のすべてのオープンが読取りアクセスのためで
ある場合（８３）は、新しいモードは、線１２
１で示すように読取専用モード１０５になる。
クローズ動作がフアイルの最後のクローズであ
る場合、同期モードはない。 フアイルが現在読取専用同期モード１０５に
あり、フアイル・オープン動作が行なわれる場
合、そのオープンが読取りのためであれば、モ
ードの変化はない。しかし、そのオープンが書
込みのためである場合は、線１２０で示すよう
に、すべてのオープンが一つのクライエント・
ノードにある（１２７）なら、新しい同期モー
ドは非同期モード１０４である。さもなけれ
ば、同期モードは全同期モードである。さら
に、フアイルが存在する装置が読取り／書込み
アクセスのためにオープンである場合（１３
０）、そのフアイルに対する新しい同期モード
は全同期モード１０６である。クローズ動作に
ついては、そのクローズがフアイルの最後のク
ローズである場合、そのフアイルに同期モード
はない。クローズ動作後に、１つまたは複数の
ノードでフアイルが依然としてオープンされて
いる場合、同期モードは変わらない。 フアイルが現在全同期モード１０６にあり、
そのフアイルに対して別のオープンがある場
合、またはフアイルが存在する装置がオープン
される場合は、同期モードの変更はない。フア
イルのクローズ動作後、読取り／書込みアクセ
スのためのオープンが遠隔ノードに残つてお
り、フアイルが存在するブロツク特別装置がオ
ープンされていない場合、線１１８を介してブ
ロツク１４１に示すように、同期モードは非同
期モード１０４に変わる。フアイルが存在する
ブロツク特別装置がオープンされておらず、線
１２２を介してブロツク１４２で示すように、
フアイルが１つまたは複数のノードで読取り専
用アクセスのためにオープンされる場合、また
は、フアイルが存在するブロツク特別装置が読
取り専用アクセスのためにオープンされ、線１
２２を介してブロツク１４３で示すように、フ
アイルが読取り専用アクセスのためにオープン
される場合は、同期モードは全同期モード１０
６から読取専用モード１０５に変わる。 フアイルに対するすべてのオープンおよびク
ローズ動作はサーバ・ノードで解決される。サ
ーバは、モードを変更する可能性がある動作を
実行するとき、オープンの同期モードを判定す
る。サーバはまた、同期モードの変更を行な
う。サーバがフアイルに対する新しいオープン
またはクローズを受け取るとき、フアイルに対
する同期モードの変更がトリガされることがあ
る。必要とされる同期モードが現在の同期モー
ドでない場合、サーバは、フアイルがオープン
されているすべてのクライエントに「同期モー
ド変更」遠隔手順コールを送る。フアイルが初
めてオープンされた後で、そのフアイルをオー
プンしたクライエントにフアイルのモードが知
らされる。モードが非同期モードまたは読取専
用モードのどちらかである場合、クライエント
は読取り用のクライエント・キヤツシユを使つ
て開始することができ、さらに、第１３図に示
すように、モードが非同期モードの場合は、書
込み用のクライエント・キヤツシユをも使つて
開始することができる。クライエントが通信リ
ンクを介してサーバに対して読取りまたは書込
みを行なう必要はない。第１５図に示すように
モードが全同期モードである場合は、クライエ
ント・キヤツシユは使用されず、クライエント
は通信リンク３を介して読取りまたは書込みを
サーバに送らねばならない。 第１５図でサーバＡは常にフアイル５のモー
ド１５１をセツトする。フアイルのモードは、
フアイルをオープンしたすべてのノードで同じ
である。サーバＡはまた、どのノードがフアイ
ルをオープンしたか、およびそれらのオープン
が読取りのためかそれとも書込みのためかを知
つている。サーバＡは、ノード内のどの処理１
３１ないし１３Ｎ，２３１ないし２３Ｎがフア
イルをオープンしたかを知つている必要はな
い。第１５図に示すように、サーバは上記情報
をすべてフアイル・アクセス構造リスト１５０
に保持する。フアイル・アクセス構造リスト１
５０の各要素は、フアイルをオープンしたノー
ド１５２、そのノードでの読取りのためのオー
プンの数１５３、およびノードでの書込みのた
めのオープンの数１５４を含んでいる。 E4 ロツキング UNIXフアイル・ロツキング UNIXオペレーテイング・システムでは、処
理がフアイル内のバイト範囲をロツクして、他
の処理がその範囲にアクセスできないようにす
ることができる。ロツクはフアイルのバイト範
囲に適用される。フアイルの全域に渡るロツク
はフアイルをロツクし、フアイル・ロツクと呼
ぶことができる。任意のバイト範囲に渡るロツ
クは、レコード・ロツクと呼ばれることがあ
る。ただし、この開示では、レコード・ロツク
およびフアイル・ロツクを単にロツクと呼ぶこ
とにする。 このシステムでは２種類のロツクがサポート
される。すなわち、書込みロツクおよび読取り
ロツクである。書込みロツクは排他的ロツクで
ある。フアイルのある範囲が書込みロツクされ
た場合、他のロツクがその範囲に存在すること
はできない。もう一つの種類のロツク、すなわ
ち、読取りロツクは共用ロツクである。オーバ
ーラツプする任意の数の読取りロツクをフアイ
ルのあるセグメントに適用することができる。
既存の読取りロツクは他の読取りロツクを妨げ
ないが、他の書込みロツクを妨げることに留意
されたい。既存の書込みロツクは特定の範囲に
対する他のすべてのロツクを妨げる。書込みロ
ツクは、書込みアクセスでオープンされたフア
イル記述子だけに適用される。 フアイルは強制モードにあるか、または強制
モードにないかのいずれかである。強制モード
にないフアイルに対するロツクは勧告ロツクと
呼ばれる。勧告ロツクはフアイルまたはレコー
ドに対する絶対的保護をもたらさない。しか
し、勧告ロツクは、処理がロツクされたフアイ
ルまたはレコードの読取りまたは書込みを行な
うのを妨げる。勧告ロツクはlockf(2)または
fcntl(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)システム・コールの異なる３つの
UNIXオペレーテイング・システム・コマンド
がロツキングに関係する。 Ｆ−GETLK fcntl(2)の引数によつて記述さ
れるロツクが呼出し側に許可されるのを妨げる
最初の既存のロツクを見つける。 Ｆ−SETLK fcntl(2)の引数によつて記述さ
れるロツクを呼出し側に許可する。既存のロツ
クが要求とインターフエースするので、ロツク
を許可できない場合は、この既存のロツクの記
述を戻す。 Ｆ−SETLKW fcntl(2)の引数によつて記述
されるロツクを呼出し側に許可する。既存のロ
ツクが要求とインターフエースするので、ロツ
クを許可できない場合は、デツドロツクの有無
を検査し、デツドロツクが生じない場合は、呼
出し側を持たせる。妨害ロツクがクリアされる
度に、カーネルは、再度妨害ロツクの有無を探
索することにより、要求されたロツクを確立し
ようと試みる。プロセスはいつまでも待つこと
ができる。単一ノード上でのフアイル・ロツク
のみに関するデツドロツクが検出されるが、複
数ノード上での複数フアイル・ロツクによるデ
ツドロツクが発生し得る。プロセスは決してデ
ツドロツクにはならないが、交互にセツトされ
る種々のフアイルに対する妨害ロツクのために
ライブ・ロツク（live−lock）になる可能性は
ある。 ロツク・テーブル ロツクはオープン・フアイルと関連するの
で、ロツク情報をオープン・フアイルに関する
情報と一緒にフアイルのｉノード構造に保持す
るのが自然である。ｉノード構造はUNIXオペ
レーテイング・システムでは固定サイズなの
で、ｉノードにはロツク構造が存在するアドレ
スだけを入れて、ロツク情報は別の構造に記憶
されねばならなかつた。ロツクは、ロツク・テ
ーブルと呼ばれるカーネル・データ構造からの
一組の項目として、連係されたリストに保持さ
れる。 UNIXオペレーテイング・システムは、分散
型フアイル・システムに対するサポートを提供
しなかつた。分散型システムでは、数個のノー
ドが同じフアイルを使用することがあり得る。
あるフアイルに対するロツク・テーブルは常に
単一ノードにある。フアイルが非同期モードに
ある場合、ロツク・テーブルは（活動ノード情
報と共に）、フアイルがオープンされている単
一ノードに保持される。フアイルが読取専用モ
ードまたは全同期モードにある場合、ロツク・
テーブルはサーバに保持される。このアーキテ
クチヤには２つの重要な意味がある。第一に、
プロセスが遠隔手順コール（RPC）を使つて
ロツクをセツトまたはテストしなければならな
いことがある。これらのRPCはフアイルのサ
ーバで実行される。第二に、フアイルの同期モ
ードが変わるとき、フアイルのロツク・テーブ
ルをクライエントからサーバに、またはサーバ
からクライエントに移さなければならないこと
がある。ｉノード・ロツク・テーブルの項目
は、ｉノード・フアイルのセグメントに対する
ロツクに対応する。ロツクを表わすには、ロツ
ク・セツト項目が、ロツクされるバイトの範
囲、ロツクの種類（読取りまたは書込み）、ロ
ツクの所有者を識別する情報を含まなければな
らない。 プロセスが項目のロツクを待つているかどう
かを示すフラグをロツク項目に記憶することに
より、カーネル・データ構造の幾つかの探索が
不要になる。このフラグは、ロツク・セツト項
目の実際のインプリメンテーシヨンに含まれる
情報のもう１つの部分である。最後に、ロツ
ク・セツト項目は多分、同じフアイルに属する
項目を互いにリンクするために使用されるポイ
ンタ・フイールドを含んでいる。ロツク・セツ
トの要素を処理するための以下の動作を詳細に
調べることにより、インプリメンテーシヨンの
詳細について考察する。 (1) 特定のｉノードと関連するロツク・セツト
中のロツクを繰り返す方法。 (2) あるｉノードに対するロツク・セツトにロ
ツクを追加する機能。 (3) あるｉノードに対するロツク・セツトから
ロツクを除去する機能。 ロツク・テーブルの項目は、ロツクを、ロツ
クされる最小のバイト範囲とそのロツクに対す
る所有者情報で表わす。ロツクの以下の属性を
戻す動作が必要である。 (1)ロツクされるセグメントの範囲 (2)ロツク
の種類（読取り、書込みまたは一時的） (3)ロ
ツク所有者 所有者があるロツクと関連しているとき問題
が生じる。ロツクの所有者は、所有者のproc
テーブルを指すポインタによつて識別される。
procテーブルとは、システム内の各活動プロ
セスに関する管理情報の集合である。procテ
ーブルに対するデータ構造ソース・コードを、
各フイールドの目的を説明する情報と共に下に
示す。 【表】 【表】 デツドロツクの検出には各ロツクの所有者用
のprocテーブルにアクセスする必要があるの
で、procテーブルはロツク要素の所有者を識
別するための有用な方法である。分散型システ
ムでは、所有者はローカル・プロセスではない
かも知れない。所有者が遠隔プロセスである場
合、所有者情報には、所有者が存在するノード
に対するノードidを含める必要がある。必要と
される情報は以下の通りである。 (1) 所有者のprocテーブルのアドレスを戻す
動作。 (2) ２人の所有者を比較し、これらの所有者が
同じプロセスである場合はTRUEを戻し、
さもない場合はFALSEを戻す動作。 (3) 所有者のノードidを戻す動作。これらの動
作は構造内のフイールド参照を使つて、指示
された動作を実行する。 ロツク待ち スタンドアロン・オペレーテイング・システ
ムでは、ロツクを確立しようと試みるプロセス
は、まず既存のロツクがクリアされるのを待た
なければならないことがある。待つ（休眠す
る）前に、そのプロセスはシステムのすべての
ｉノードのロツク・セツトを調べて、待つて
も、デツドロツクが生じないことを確かめねば
ならない。待機しているプロセスのprocテー
ブルが、procテーブルのＷ CHANフイール
ドを使つて、待つているロツク・テーブル項目
を指す。 DFSでは、待つことは容易ではない。ブロ
ツキング・ロツクを待つための２つの方法があ
る。すなわち、(1)ローカル・ロツク・セツト項
目を直接待つ方法と、(2)サーバ・ロツク・セツ
ト項目を間接に待つ方法である。直接待機は上
述のスタンドアロン待機と同じである。直接待
機は、ロツク・テーブル内で局所的に生じるロ
ツクをプロセスが待たねばならないときに使用
される。あるフアイルに対するロツク・テーブ
ルは１つのノードのみに存在することを思い起
こされない。呼出し側プロセスが同じノードに
ない場合、ロツク・テーブルはサーバ内にあ
る。ロツク・テーブルが遠隔ノード（サーバ）
内にあるフアイルのある領域をロツクしようと
試みるプロセスは、ロツクを間接的に待つ。こ
の間接待機は、サーバ内のRPCがトランザク
シヨン・プログラムを呼び出し、ロツクを待つ
ことによつて行なわれる。スタンドアロン
UNIXオペレーテイング・システムでは、ロツ
クが許可されることが可能な場合、または、待
機がデツドロツクを生じる可能性がある場合、
プロセスは決して休眠状態に入らない。分散型
システムでは、ロツク・テーブルと同じノード
に存在しないロツク要求を実行するプロセスは
常に（少なくとも一時的に）休眠状態に入る。
そのプロセスは、RPCが戻るのを待つている
間、そうしなければならない。不必要なネツト
ワーク通信を避けるために、ロツクRPCを待
つプロセスは、RPCトランザクシヨン・プロ
グラムがブロツキング・ロツクを待つているの
で待つのか、それともブロツキング・ロツクが
発見されなかつたサーバでトランザクシヨン・
プログラムが実行を終了していないので待つの
かを知らない。分散型システムでは、デツドロ
ツクは数ノードにわたる可能性がある。したが
つて、スタンドアロン環境と疑似のアーキテク
チヤを使つて、デツドロツクがない場合にのみ
プロセスが待つようにすることは、そのオーバ
ーヘツドおよび検査を行なわねばならないこと
のために、実用的ではない。本発明は、スタン
ドアロン・デツドロツク防止の分散型バージヨ
ンに付随するオーバーヘツドおよび複雑性を伴
わずにそのような能力を提供するための方法で
ある。 デツドロツク 連鎖状のプロセスが実行され、それらのプロ
セスが、既に使用中の資源を求めて競合すると
き、デツドロツクが生じる。たとえば、プロセ
ス２が支配する資源をプロセス１が待ち、プロ
セス３が支配する資源をプロセス２が待ち、以
下同様に、プロセス１が支配する資源を最後の
プロセスが待つ場合である。スタンドアロン
UNIXオペレーテイング・システムは、フアイ
ルおよびレコードのロツキングを伴うデツドロ
ツクが発生するのを防ぐ。従来は、UNIXオペ
レーテイング・システムは分散型システムをサ
ポートせず、そのようなデツドロツクの発生を
防ぐことができなかつた。防止したいデツドロ
ツクを形成する循環連鎖状プロセスは２種類の
リンクによつてリンクされる。すなわち、(1)プ
ロセスproテーブルのプロセスｗ chanフイー
ルドを介してロツクを指すプロセスと、(2)ロツ
クの所有者フイールドを介してプロセスを指す
ロツクである。これらのリンクをたどることに
より、循環の有無の探索を実行して、デツドロ
ツクが発生するかどうか判定することができ
る。UNIXオペレーテイング・システムは１つ
のこと（単一ｗ chan）を待つことができる
だけであり、ロツクは１つのプロセスのみが所
有するので、連鎖の探索は難しくない。唯一の
厄介な点は間接待機の可能性である。別のノー
ドに送られたRPCからの応答をプロセスが待
つとき、間接待機が生じる。間接待機を処理す
るには、RPCを実行する前にタイマーをセツ
トして、デツドロツクが生じた場合に警報アプ
リケーシヨンが必要とされる。 分散型フアイル・サポート・ロツク制御 UNIXオペレーテイング・システム環境にお
けるフアイル・アクセス・コールは、FLOCK
と呼ばれるデータ構造を使用する。FLOCKの
構造を下に示す。 STRUCT FLOCK｛ SHORT Ｌ TYPE； SHORT Ｌ WHENCE； LONG Ｌ START； LONG Ｌ LEN； SHORT Ｌ PID； SHORT Ｌ NID； ｝； 分散型フアイル・サポート（DFS）を実施
するためのもう１つの重要な構造はフアイル・
アクセス構造である。フアイル・アクセス構造
のソース・コードを、詳細な論理を示すための
若干の説明情報と共に下に示す。 STRUCT FILE ACCESS ｛／^* フアイル・アクセス構造ポインタ ^*／ STRUCT FILE ACCESS ^*FA
NEXT；； ／^* フアイル・アクセス構造フラツグ ^*／ SHORT FA FLAG； ／^* フアイル・アクセス構造全ユーザ ^*／ SHORT FA COUNT；／^* フアイル・アクセス構造読取り／専用カウント ^*／ SHORT FA OROCNT；／^* フアイル・アクセス構造読取り／書込みカウン
ト ^*／ SHORT FA ORWCNT；／^* フアイル・アクセス構造実行プロセス^* ／ SHORT FA TXTCNT；／^* フアイル・アクセス構造ノード構造ポインタ ^*／ STRUCT NODE ^*FA NID；／^* フアイル・アクセス構造ノードID ^*／ INT FA NID；／^* フアイル・アクセス構造Ｓ INODEポインタ ^*／ STRUCT INODE ^*FA SIP；｝； DFSは分散型環境でフアイルのロツキング
を調整するためのロツク制御サブルーチンを提
供する。詳細な論値を示すため、サブルーチン
のインターフエース・ソース・コードを下に示
す。 STRUCT FLOCK｛ SHORT Ｌ TYPE； SHORT Ｌ WHENCE； LONG Ｌ START； LONG Ｌ LEN； SHORT Ｌ PID； SHORT Ｌ NID； ｝； DFS LOCK CONTROL（FH，LOCK
INFO，CMD， FAS FLAG） FILE HANDLE Ｔ FH； STRUCT FLOCK^*LOCK INFO； SHORT CMD，FAS FLAG； RETURN（ERRNO，MODE，START，
LENGTH，NID， PID） DFSロツク制御サブルーチンは、パラメー
タFH（フアイル・ハンドル）、LOCK INFO
（FLOCK構造のポインタ（アドレス））、CMD
（実行すべきプロセス）およびFAS FLAG
（フアイル・アクセス構造フラツグ））を有す
る。フアイル・ハンドルは、コマンドが実行さ
れる対象となるフアイルを一義的に識別するた
めに必要である。LOCK INFOは、FLOCK
構造と、その中に含まれるフアイルに関するシ
ステム情報を識別するために必要である。
CMDは、すべてのロツクが除去されるまで遠
隔プロセスを待たせ、それから指定された
CMDを処理するようにセツトされる。CMSフ
イールドは、アンロツク、テスト、セツトまた
はテスト／セツト・コマンドを実行するように
セツトすることができる。FLOCK構造の１
lenおよび１ startフイールドは、コマンドが
適用されるロツク範囲を指定するのに使われ
る。FAS−FLAGは、FULLSYNC同期モード
にあるかどうか知るため、フアイル・アクセス
構造ロツク内の同期モードを調べよとサーバに
命令するようにセツトされる。フアイルが
FULLSYNC同期モードにある場合、サーバは
コマンドを実行する。しかし、そうでない場合
は、エラーが戻される。フアイル・アクセル構
造フラツグがセツトされていない場合は、フア
イルは、実行を始める前に、フアイル・アクセ
ス構造ロツクの獲得および検査を行なわない。
この検査によつて処理の前に照会が可能とな
り、デツドロツクの可能性が回避される。 フアイル・ロツキング構造 LOCKFサブルーチンは、書込み排他特権の
ためにフアイルをロツクまたはアンロツクする
のにアプリケーシヨンが使用する主なインター
フエースである。その使用法を例示するため、
このサブルーチンのインターフエース・ソー
ス・コードを下に示す。 ＃include＜SYS／LOCKF.H＞ itn lockf（fildes，function，size）； int fildes，function； long size； ロツクは、UNIXオペレーテイング・システ
ム下CNTL(2)によりLOCKFと同様の方法でセ
ツトまたは解除することができる。アプリケー
シヨンとLOCKFサブルーチンおよびFCNTL
サブルーチンの間の外部インターフエースは、
UNIXオペレーシヨン・システムと本発明で違
いはない。ただ、分散型環境をサポートするた
めに間隔が修正されている。 内部の詳細 遠隔フアイルがロツクされる場合は、UNIX
オペレーテイング・システムのLOCKFおよび
FCNTLシステム・コールが中断され、
RPCDFS LOCK CONTROLが実行される。
サーバ・ノードは遠隔プロセス・コールを受け
取り、ロツク要求を実行する。要求は単一レコ
ード、一組のレコードまたはフアイル全体のロ
ツクを伴うことがある。次に、サーバは、クラ
イエント代理ｉノードがDFS LOCK
CONTROLのRPCからの応答を待つ間に、信
号を送ることにより、クライエントが目を覚す
ように命令する。クライエントはロツクの受取
りを確認し、肯定応答を遠隔サーバに送る。サ
ーバは、クライエント代理ｉノードから肯定応
答を受け取つた後、ロツク・テーブルを更新す
る。サーバがDFS LOCK CONTROLの肯
定応答の受取りを確認しない場合、DFS
LOCK CONTROLはこのロツクをロツク・
テーブルから除去する。 フアイル・アクセス構造ロツク フアイル・アクセス構造ロツク、fasロツク
は、分散型フアイル・システム（DFS）でオ
ープン・フアイルに対するｉノードおよび代理
ｉノードの使用を同期するために使われる。こ
の同期はデツドロツク状況を回避するために実
行される。デツドロツク状態は、ｉノードおよ
び代理ｉノードがロツクされた場合に発生し得
る。 スタンドアロンAIXオペレーテイング・シ
ステムは、フアイルＦに対するアクセスを必要
とするシステム・コールの実行は、そのフアイ
ルに対するシステム・コールの全実行時間中に
Ｆに対するｉノードをロツクすることにより直
列化される。DFSでは、フアイルＦが遠隔ノ
ードＣでオープンされている場合は、フアイル
Ｆを表わす代理ｉノードがノードＣで作成され
る。したがつて、２つの資源が関係する。すな
わち、フアイルが存在するサーバ・ノードにお
ける特定のフアイルに対するｉノードと、フア
イルがオープンされているクライエント・ノー
ドにおける代理ｉノードである。クライエント
Ｃで実行されるシステム・コールを直列化する
ため、各コールが実行時間中フアイルＦに対す
る代理ｉノードがロツクされる。クライエン
ト・キヤツシユで使用可能でないデータ・ブロ
ツクを読み取るためにサーバに対するアクセス
が必要な場合、フアイルＦに対するｉノードも
ロツクされる。 サーバにあるフアイルＦに対するｉノードと
クライエントにあるフアイルＦに対する代理ｉ
ノードを各システム・コールの全実行時間中ロ
ツクすると、２つの資源を獲得する順序が常に
同じ順序で実施されない場合、デツドロツク状
況をもたらす可能性がある。一般には、代理ｉ
ノードが最初にロツクされ、次に遠隔手順コー
ル（RPC）を介してサーバがアクセスされ、
ｉノードがロツクされる。しかし、上記の順序
には幾つかの例外がある。特定の条件の下で、
サーバはｉノードをロツクし、次に、代理ｉノ
ードのロツクを必要とするクライエントに
RPCを送ることができる。 第１８図に示すように、２つの動作が現在01
および02を実行している以下の状況のいずれか
一方でデツトロツクが発生する可能性がある
（01は読取り動作、02はオープン動作である）。 (a) 01がクライエント・ノードで実行されてい
る。01は代理ｉノードをロツクし、読取り動
作のためサーバでｉノードをロツクしようと
する。 (b) 02がサーバで実行されている。02はｉノー
ドをロツクし、フアイルをオープンするため
にクライエント・ノードに対してRPCを開
始する。クライエント・ノードでのRPC要
求は代理ｉノードを待つて、それをロツクし
てから実行される。 両方の動作が実行されており、かつ２つの同
じ資源を必要とし、それぞれ１つの資源を獲得
し、かつ他方のロツクされた資源を持つている
ので、デツドロツク状態が存在する。原因を調
べるに当たつては、サーバからクライエントに
対するRPCの実行中にデツドロツクが発生す
ることに留意されたい。サーバ上のｉノードが
まずロツクされ、代理ｉノードをロツクしよう
とする試みがなされる。これは、代理ｉノード
がまずロツクされ、次にｉノードをロツクする
ためにRPCを送る大部分の場合とは逆である。 上記問題の発生を防ぐため、サーボは、代理
ｉノードをロツクするためのRPCをクライエ
ントに出す前に、ｉノードをアンロツクするこ
とができる。オープン動作の実行中にｉノード
をアンロツクすると、上記の問題が解決され
る。しかし、そうすると複数のオープン動作ま
たはクローズ動作あるいはその両方が同時にサ
ーバで行なわれる可能性があるので、オープ
ン・フアイルのための同期モード変更の管理が
複雑になる。第１７図に示すようなもう１つの
問題が生じる可能性もある。第１７図では、１
０にあるフアイルＦが、２０にあるクライエン
ト・ノードＣ−１内でのただ１つの処理によつ
て、非同期モードでオープンされている。２つ
の動作が進行中である。すなわち、２０にある
Ｃ−１からのクローズ動作と、４０にある別の
クライエントＣ−２からの、１０でと同じフア
イルＦに対する６０でのオープン動作である。
２０にあるＣ−１からのクローズ動作は代理ｉ
ノード（使用カウント１を有する）をロツク
し、５０での「dfsクローズ」RPCを３０にあ
るサーバに送る。４０にあるＣ−２からのオー
プン動作は７０での「dfsオープン」を３０に
あるサーバに送る。このRPCはサーバに到着
し、２０にあるＣ−１からの５０での「dfsク
ローズ」RPCの前に実行される。フアイルＦ
に対する同期モードは非同期なので、サーバは
ｉノードをアンロツクし、８０での「dfs同期
モード変更」RPCを２０にあるＣ−１に送り、
１０にあるフアイルＦが全同期モードに変更さ
れることを要求する。このRPCが２０にある
Ｃ−１に到着し、代理ｉノードがアンロツクさ
れるのを持つ。次に、５０での「dfsクローズ」
RPCがサーバに到着する。１０にあるフアイ
ルＦに対するｉノードはサーバではロツクされ
ないので、クローズ動作がサーボで実行され、
９０での「dfsクローズ肯定応答」RPCが２０
にあるＣ−１に送られる。９０での「dfsクロ
ーズ肯定応答」RPCが２０にあるＣ−１に到
着すると、代理ｉノードに関する使用カウント
が減分され、使用カウントの値が０になつたの
で、代理ｉノードは１００で解放される。これ
により、同期モード変更を２０にあるＣ−１に
適用するための代理ｉノードは残らない。 この問題に対する解決策は、それを持つ前に
同期モード変更手順に代理ｉノードの使用カウ
ントを増分させることである。しかし、この時
点では、フアイルＦはＣ−１でオープンされて
いず、その同期モードは全同期ではないので、
この手法はフアイル管理システムにとつて一層
の管理上の問題をもたらす。それよりも望まし
い手法は新しいロツク、すなわちフアイルに対
するアクセス・リストをアクセスまたは変更す
る動作を直列化するためのフアイル・アクセス
構造ロツク（fasロツク）を導入することであ
る。fasロツクを使用することにより、ｉノー
ドは重要な資源ではなくなる。２つの重要な資
源はクライエント・ノードにある代理ｉノード
とサーバにあるfasロツクである。デツドロツ
クを防ぐには、fasロツクの保持を必要とする
クライエント・ノードで実行中の動作が、
RPCがサーバに送られる前に、代理ｉノード
をアンロツクしなければならない。 サーバからクライエントに対してRPCを発
生する可能性がある動作は、サーバでの実行を
開始する前に、fasロツクを獲得しなければな
らない。UNIXオペレーテイング・システムま
たはAIXオペレーテイング・システム環境に
おける状況の例は以下の通りである。 遠隔手順コール（RPC）： ＊DFS OPEN＊DFS CREATE ＊DFS CLOSE＊DFS GET ATTR ＊DFS SET ATTR＊DFS LOOKUP ＊DFS CHNG SYNC MODE サーバ処理からのシステム・コール： ＊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ロツクは、ｉノードの使用を同期し、デ
ツドロツク動作を回避する手段を提供する。
fasロツクは、フアイルをオープンしているノ
ードに関する情報を含むフアイル・アクセス構
造リストに対するアクセスを同期する。fasロ
ツクは、プロセスがフアイルをオープンまたは
クローズするとき、またはフアイル・アクセス
構造リストが照会されているとき、ロツクされ
る。fasロツクは、フアイルが全同期モードに
あるときは、書込み動作中もロツクされる。 ｉノード・ロツクはサーバにあるフアイルの
データに対するアクセスを同期する。ｉノー
ド・ロツクは、サーバにあるフアイルに対する
読取りまたは書込み動作中ロツクされる。遠隔
手順コールが代理ｉノード・ロツクに対するロ
ツクを必要とする場合、サーバが遠隔手順コー
ルをクライエントに送る前に、ｉノード・ロツ
クがアンロツクされる。 代理ｉノード・ロツクはクライエント・プロ
セス内のフアイル・アクセスを同期する。クラ
イエントでの動作がフアイルにアクセスしてい
る場合、代理ｉノードはロツクされる。クライ
エントでの動作がfasロツクをロツクする場合
は、代理ｉノードがアンロツクされる。代理ｉ
ノードはまた、遠隔手順コールがクライエント
からサーバに送られる前にアンロツクされる。 fasロツクおよびｉノード・ロツクの両方が
ロツクされている場合は、ｉノード・ロツク
は、サーバがクライエントに対して遠隔手順コ
ールを発生する前に、アンロツクされる。この
ため、fasロツクおよび代理ｉノード・ロツク
がロツクできるようになる。これらのロツク
は、ロツクされたのと逆の順序でアンロツクさ
れる。 特定のオペレーテイング・システム環境にお
ける好ましい実施例に関して本発明を説明して
きたが、当業者なら気付くように、頭記の特許
請求の範囲の精神および範囲内で、変更を加え
ることにより、他の様々なオペレーテイング・
システムでも本発明を実施することができる。 Ｆ 発明の効果 以上説明したように本発明によればフアイルに
対するアクセスのリストの変更をロツクする構成
を採用しているので分散型フアイル・アクセスに
おけるロツドロツクを解消することができる。

【図面の簡単な説明】

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

Claims (1)

1. 【特許請求の範囲】 １ サーバー・データ処理装置にフアイル・デー
   タを常駐させ、複数のクライエント・データをア
   クセスできるようにした分散型データ処理システ
   ムにおいて、 現にどのフアイルがオープンされているか、及
   びそれらのオープンのモード（読取り専用かまた
   は読取り／書込みか）に関するリストへのアクセ
   スと同期して該リストをロツクする第１のロツク
   手段と、 上記サーバー・データ処理装置上の上記リスト
   の先頭を指すポインタを含むフアイル・データへ
   のアクセスと同期して該フアイル・データをロツ
   クする第２のロツク手段と、 上記複数のクライエント・データ処理装置のう
   ちの１つにおいて、上記フアイル・データを識別
   するための情報を含むフアイルへのアクセスと同
   期して該フアイルをロツクする第３のロツク手段
   とを有することを特徴とする分散型データ処理シ
   ステム。