JPH0668733B2 - データ処理システム及び方法 - Google Patents

Description

【発明の詳細な説明】 Ａ．産業上の利用分野 本発明は、一般に分散データ処理システム用のオペレー
ティング・システムの改良に関し、さらに具体的には、
ローカル・エリア・ネットワーク（ＬＡＮ）または広域
ネットワーク（ＷＡＮ）で相互接続された多重プロセッ
サ・システム用のオペレーティング・システムに関する
ものである。本発明にもとづくオペレーティング・シス
テムを使うと、ファイルがシステム中のどこにあろう
と、システム中のプロセッサによってそれらのファイル
にアクセスできるようになる。本発明の好ましい実施例
をここではＵＮＩＸ（ＡＴ＆Ｔが開発しライセンスを供
与されている。ＵＮＩＸは米国内でのＡＴ＆Ｔの登録商
標）オペレーティング・システムの１バージョンで実施
された好ましい実施例の形で開示するか、本発明は他の
様々なオペレーティング・システム中でも実施できる。

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

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

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

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

第二に、ユーザは、アクセスしようとするすべてのシス
テムに別々に「ログ・オン」しなければならない。こう
することで、システムの保全性を保護するために必要な
セキュリティがもたらされるが、そのことはまたユーザ
にとっては大変な負担となる。その他の背景知識につい
ては、Ｈ．Ｍ．ディテル（Harvey M.Deitel）著の教科
書「オペレーティング・システム入門（An Introductio
n to Operating Systems）」、Addison-Wesley刊（１９
８４年）、とくにその第２２章（ＶＭ：仮想計算機オペ
レーティング・システム（ＶＭ：A Virtual Machine Op
erating System）」を参照されたい。より詳しく考察に
ついては、Ｈ．ローリン（Harold Lorin）とＨ．Ｍ．デ
ィテル共著の教科書（オペレーティング・システム（Op
erating Systems）」、Addison-Wesley刊（１９８１
年）、とくにその第１０章「仮想計算機（Virtual Mach
ines）」を参照されたい。

以下では、ＵＮＩＸオペレーティング・システムの１バ
ージョンで本発明を実施した場合について説明するが、
本発明はＵＮＩＸオペレーティング・システムに類似す
る特徴をもつ他のオペレーティング・システムでも使用
できる。ＵＮＩＸオペレーティング・システムは、ベル
研究所（Bell Telephone Laboratories,Inc.）がディジ
タル・エクィップメント社（Digital Equipment Corpor
atino,ＤＥＣ）のミニコンピュータ用に開発したもので
あるが、広範囲のミニコンピュータ用、それに最近では
マイクロコンピュータ用のオペレーティング・システム
として広く使われている。この普及の一因は、ＵＮＩＸ
オペレーティング・システムがアセンブリ言語ではな
く、やはりベル研究所で開発されたＣプログラミング言
語で書かれており、したがって、プロセッサの種類を問
わないことである。したがって、様々な計算機用のＣコ
ンパイラを使うと、ＵＮＩＸオペレーティング・システ
ムをある計算機から別の計算機に移すことが可能にな
る。すなわち、ＵＮＩＸオペレーティング・システム環
境用に書かれたアプリケーション・プログラムも、計算
機間で移植可能である。ＵＮＩＸオペレーティング・シ
ステムの詳細については、「ＵＮＩＸ^TMシステム、ユー
ザーズ・マニュアル、システムＶ（ＵＮＩＸ^TM System,
User's Manual,System Ｖ）」、Western Electric C
o.、１９８３年１月刊を参照のこと。ＵＮＩＸオペレー
ティング・システムの秀れた概説が、Ｂ．Ｗ．カーニハ
ン（Brian W.Kernighan）とロブ・パイク（Rob Pike）
の共著「ユニックス・プログラミング環境（The Unix P
rogramming Environment）」Prentice-Hall、１９８４
年刊に出ている。ＵＮＩＸオペレーティング・システム
の設計の詳細については、Ｍ．Ｊ．バッハ（Maurice J.
Bach）著「ユニックス・オペレーティング・システムの
設計（Design of the Unix Operating System）」、Pre
ntice-Hall、１９８６年刊に出ている。

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

本発明は、具体的には、複数のプロセッサがネットワー
ク内で相互接続されることを特徴とする、分散データ処
理システムに関係する。実際に実施された形では、本発
明は、ＩＢＭのシステムネットワーク・アーキテクチャ
（ＳＮＡ）、さらに具体的にはＳＮＡ ＬＵ６．２拡張
プログラム間通信（ＡＰＰＣ）で相互接続された複数の
ＩＢＭ ＲＴ ＰＣ上で機能する。ＳＮＡでは、そのリ
ンク・レベルとして、ゼロックス社が開発したローカル
・エリア・ネットワーク（ＬＡＮ）であるイーサネット
(EthernetはXerox Corporationの商標）またはＳＤＬＣ
（同期データ・リンク制御）を使う。イーサネット・ロ
ーカル・エリア・ネットワークを含めてローカル・エリ
ア・ネットワークの簡単を説明は、Ｌ．Ｅ．ジョーダン
（Larry E.Jordan）とＢ．チャーチル（Bruce Churchil
l）の共著「ＩＢＭ ＰＣ用の通信ネットワーキング（C
ommunications and Networking for the IBM PC）」、R
obert J.Brady（Prentice-Hallの子会社）、１９８３年
刊に出ている。コンピュータ用通信システム、とくにＳ
ＮＡとＳＤＬＣについてのより明確な説明は、Ｒ．Ｊ．
シプサー（Cypser）著「分散システム用通信アーキテク
チャ（Communications Architecture for Distributed
System）」、Addison-Wesley、１９７８年刊に出てい
る。ただし、本発明は、イーサネット・ローカル・エリ
ア・ネットワークやＩＢＭ ＳＮＡ以外のネットワーク
で相互接続された、ＩＢＭ ＲＴ ＰＣ以外の様々なコ
ンピータを用いても実施できることを了解されたい。

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

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

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

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

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

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

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

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

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

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

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

ＵＮＩＸオペレーティングシステム環境内で分散データ
処理システムをサポートする方法は、他にも知られてい
る。たとえば、Sun Microsystemsはネトワーク・ファイ
ル・システム（ＮＦＳ）を発表し、ベル研究所は遠隔フ
ァイル・システム（ＲＦＳ）を開発した。Sun Microsys
temsのＮＦＳは一連の刊行物に記載されている。たとえ
ば、Ｓ．Ｒ．クレイマン（Kleiman）「Ｖノード：Sun
ＵＮＩＸにおける多重ファイル・システム・タイプ用ア
ーキテクチャ（Vnodes：An Architecture for Multiple
File System Types in Sun UNIX）」ＵＳＥＮＩＸ １
９８６年夏季国際技術会議・展示会議事録、２３８−２
４７ページ；Ｒ．サンドバーグ（Russel Sandberg）等
の「Sunネットワーク・ファイル・システムの設計と実
施（Design and Implementation of the Sun Network F
ilesystem）」、ＵＳＥＮＩＸ １９８５年会議議事
録、１１９−１３０ページ；Ｄ．ウォールシュ（Dan Wa
lsh）等の「Sunネットワーク・ファイル・システムの概
要（Overview of the Sun Network File System）」１
１７〜１２５ページ；ジョメイ・チャン（Jomei Chan
g）の「状況モニタがＮＦＳに対するネットワーク・ロ
ツキング・サービスをもたらす（Status Monitor Provi
des Network Locking Service for NFS）」；ジョメイ
・チャンの「サンネット（Sunnet）」、７１−７５ペー
ジ；Ｂ．テイラー（Bradley Taylor）の「Sun環境にお
ける安全なネットワーキング（Secure Networking in t
he Sun Environment）」２８−３６ページ。ＡＴ＆Ｔの
ＲＦＳも一連の刊行物に記載されている。たとえば、
Ａ．Ｐ．リフキン（Andrew P.Rifkin）等の「ＲＦＳア
ーキテクチャの概要（ＲＦＳ Arcchitectural Overvie
w）」ＵＳＥＮＩＸ会議議事録、ジョージア州アトラン
タ（１９８６年６月）、１−１２ページ；Ｒ．ハミルト
ン（Richard Hamilton）等の「遠隔ファイル共用に対す
る管理者の意見」、１−９ページ；Ｔ．ヒュートン（To
m Houghton）等の「ファイル・システム・スイッチ（Fi
le Systems Switch）」、１−２ページ；Ｄ．Ｊ．オラ
ンダー（David J.Olander）等の「システムＶにおける
ネットワーキング用フレームワーク（A Framework for
Networkingin System V）」、１−８ページ。

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

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

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

ユーザに分散環境内のどのノードからも単一のシステム
・イメージを与える技法を提供することが、本発明のよ
り具体的な第２の目的である。

Ｄ．問題点を解決するための手段 本発明によれば、これらの目的は、分散ノードがそれぞ
れ使う１組みのマスタ・システム・ファイルを保持し、
遠隔ノードで１組みのスタッブ・ファイルを作成し、マ
スタ・システム・ファイルをスタッブ・ファイルにマウ
ントし、マスタ・システム・ファイルを１組みのローカ
ル・システム・ファイルに複写し、マスタ・システム・
ファイルをアンマウントしてスタッブ・ファイルを削除
し、マスタ・システム・ファイルをローカル・システム
・ファイルの上にマウントすることによって達成され
る。マスタ・システム・ファイルを含むノードが利用で
きない場合は、マスタ・システム・ファイルのローカル
・コピーを使用する。さらに、各ユーザが現在どのノー
ドを使っているかに関わりなく、各ユーザがどのノード
からでも同じファイルに一貫してアクセスできるよう
に、個々の各ユーザーごとに本構造が維持される。

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

この議論に関係のあるファイル・システムの基本的態様
を下記に列挙する。

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

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

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

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

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

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

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

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

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

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

以下の考察では、従来のＵＮＩＸオペレーティング・シ
ステムがファイル・システム全体のマウントをどのよう
に使ってファイル・ツリーを作成し、またそのようなフ
ァイル・ツリー内でどのようにパスをたどるのか説明す
る。

ある装置のファイル・システム内のパス“／dir１／dir
２／file”をたどるには、次のようなステップをとる。

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

２．そのディレクトリを探索して、name＝dir１の項目
を見つける。

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

４．そのディレクトリを探索して、name＝dir２の項目
を見つける。

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

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

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

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

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

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

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

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

マウント・データ構造は揮発性である。すなわちディス
ク上に記録されない。初期プログラム・ロード（ＩＰ
Ｌ）の一部として計算機が電源投入されるたびに、初期
のマウントのリストを再発行しなければならない。以上
の議論では、従来のＵＮＩＸオペレーティング・システ
ムがファイル・システム全体のマウントをどのように使
ってファイル・ツリーを作成し、またそのようなファイ
ル・ツリー内でどのようにパスをたどるか説明した。こ
うしたインプリメンテーションは、ある装置上に存在す
るファイル・システム全体をマウントすることに限定さ
れている。本明細書および参考資料に記載する仮想ファ
イル・システムの概念は、（１）装置をマウントできる
上にファイル（ディレクトリまたは単純ファイル）もマ
ウントできるようにすることにより、ある装置上に存在
するファイル・システムの一部分をマウントすること、
および（２）既にファイル・ツリーの一部分になってい
るディレクトリ上に、遠隔ディレクトリまたはローカル
・ディレクトリをマウントすること、さらに（３）既に
ファイル・ツリーの一部分になっている単純ファイルの
上に（遠隔またはローカル）単純ファイルをマウントす
ることができるという、仮想ファイル・システム概念の
改良である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LOOKUP機能 入力：ディレクトリのｖノード・ポインタ、ディレクト
リ中でルックアップすべき名前 出力：指定されたファイル／ディレクトリを指すｖノー
ド・ポインタ。

ディレクトリのｖノード・ポインタをｉノード・ポイン
タに変換する； −−ｖノード中のポインタを使う ディレクトリのｉノードをロックする； ＩＦ（ディレクトリ中で探索許可をもっていない） ディレクトリｉノードをアンロックする； エラーを戻す； ディレクトリで名前を探索する； ＩＦ（見つかった） 名前に対するファイル・ハンドルを作成する； −−ディレクトリ・エントリ中で見つかったｉノードを
使う； ファイル・ハンドルに対するｖノードを指すポインタを
得る； ディレクトリｉノードをアンロックする； ｖノードを指すポインタを戻す； ＥＬＳＥ−−見つからなかった ディレクトリｉノードをアンロックする； エラーを戻す； ［LOOKUPPN］ ｌｏｏｋｕｐｐｎ操作とは、パスをたどる機能である。
その入力はパス（たとえば“／dir１／dir２／file”）
であり、その戻りコードはそのファイルを表すｖノード
を指すポインタである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、上記の遠隔マウント（クライエントの／etc／foo
の上にサーバの／ｕ／goupをマウントする）を実行した
後、クライエント・プロセスが、ファイル“／etc／foo
／file２”に対して操作するためのシステム・コールを
発行すると仮定する。下記のシナリオのブロック番号に
ついては第１１図および第１２図を参照されたい。第１
１図は初期状態を表し、第１２図はオープン操作後のシ
ステム状態を表す。まず、システム・コールを実施する
コードが、パスをたどるためにlookuppnを呼び出す。lo
okuppnは、ルート仮想ファイル・システム（ブロック５
１）のルートｖノード（ブロック５２）からスタート
し、このｖノードで表されるディレクトリ・ファイル中
で名前“ｕ”をルックアップするためにvn＿lookupを呼
び出す。

vn＿lookupはそのディレクトリ中で、名前“ｕ”がｉノ
ード１５と関連していることを見つける。vn＿lookup
は、ｉノード１５に対するルート仮想ファイル・システ
ム中にｖノードとｉノードを構築し、このｖノードに対
するポインタをlookuppnに戻す。lookuppnは、今度はｉ
ノード１５によって識別されるディレクトリ中で名前
“foo”をルックアップするために、再度vn＿lookupを
呼び出す。

vn＿lookupは指示されたディレクトリを読取り、名前
“foo”がブロック６１中のｉノード７５と関連してい
ることを発見する。ルート仮想ファイル・システム（ブ
ロック５１）中には既にこのｉノード（ブロック６１）
に対するｖノード（ブロック５３）が存在し、したがっ
てvn＿lookupはこのｖノードを指すポインタを戻す。lo
okuppnは、そのｖノードがマウント・オーバーされてい
ることを発見する（ブロック５３中の「マウント・オー
バーされた」ポインタはブロック５４を指している）。
したがって、lookuppnは次の仮想ファイル・システム
（ブロック５４）へと「マウント・オーバーされた」ポ
インタをたどり、その仮想ファイル・システムのルート
ｖノード（ブロック５５）へとそのルートｖノード・ポ
インタをたどる。次にlookuppnはパスの次の要素（“fi
le２”）を探すためにvn＿lookupを呼び出し、ブロック
５５を指すポインタと名前“file２”をvn＿lookupに与
える。探索すべきディレクトリは遠隔ノードにあり、ク
ライエントの代理ｉノード（ブロック６２）に記憶され
ているファイル・ハンドルによって識別される。vn＿lo
okupはそのファイルを保持するサーバにdfs-lookupを発
行し、そのディレクトリを識別するファイル・ハンドル
とルックアップすべき名前（“file２”）を送る。サー
バがdfs-lookupを受け取ると、ファイル・ハンドルを使
って読み取るべきディレクトリを識別し、このディレク
トリ中で名前“file２”を探索するためにvn＿lookupを
発行する。vn＿lookupはディレクトリを読み取り、名前
“file２”に関連するｉノード番号が６７であることを
発見する。vn＿lookupはｉノード６７に対するダミー仮
想ファイル・システム中でｖノードとｉノードを構築
し、このｖノードを指すポインタをlookuppnに戻す。df
s-lookupはvn＿lookupから戻されたデータ構造中の情報
を用いて、ｉノード６７によって識別されるファイルに
対するファイル・ハンドルを構築する。dfs-lookupは、
dfs-lookup要求に対する回答としてこのファイル・ハン
ドルをクライエントに戻し、ｖノードとｉノードを解放
する。クライエント中で、見つかったファイルに対する
ｖノード（ブロック５７）と代理ｉノード（ブロック６
３）が作成される。“file２”はこのパスの最後の要素
なので、lookuppnは見つかったｖノード（ブロック５
７）を指すポインタをその呼出し側に戻す。システム・
コールを実施するコードは、次にそのファイルに対して
要求された操作を実行する。

第７Ａ図、第７Ｂ図、第７Ｃ図を参照すると、上記のマ
ウント技術を用いて、あるノード内のディレクトリ２０
２、２０３の子孫が別のノード内に存在するという、フ
ァイル・ツリー２００、２０１を構築することができ
る。たとえば、 ａ）ディレクトリ２０２は複数の直属子孫デイレクトリ
２０４、２０６、２０８を有することができ、これらの
直属子孫２０４、２０６、２０８はどれもそのネットワ
ーク内のどのノードにでも存在することができる。

ｂ）ディレクトリ２０３は複数の直属子孫ディレクトリ
２０５、２０７と複数の直属子孫単純ファイル２０９、
２１１を有することができ、これらの直属子孫はどれも
そのネットワーク内のどのノードにでも存在することが
できる。

ｃ）ディレクトリ２１２は複数の直属子孫単純ファイル
２１３、２１４、２１５を有することができ、これらの
直属子孫はどれもそのネットワーク内のどのノードにで
も存在することができる。

単一システムのイメージ 単一システム・イメージとは、ユーザが現在ログオンし
ているノードがどれであろうと、一貫した一義的な環境
をユーザに提供する方法をいう。すなわち、ユーザＸは
ユーザＹとは異なるシステムのビューをもつが、ユーザ
ＸはノードＡにログオンしているときに与えられる、通
常使っているシステムのビューおよびファイルのイメー
ジが、ノードＢにログオンしているときにも同様に与え
られる。分散環境で単一システム・イメージを実施し
て、システムに複数のシステム・ファイルの管理の負担
をかけないようにするため、５個のマスタ・システム・
ファイルの単一コピーを各ノードが共用する。これらの
ファイルの単一コピーを各ノードが共用する。これらの
ファイルは、／etc／passwd、etc／opasswd、／etc／ogr
oup、／etc／ogroup、／etc／motdである。単一システム
・イメージ分散環境でファイルがどう使用されるかを理
解するには、ＵＮＩＸオペレーティング・システム・ス
タンドアロン・システム内でのそれらのファイルの動作
を理解することが必要である。

あらゆるＵＮＩＸオペレーティング・システムは、各ユ
ーザに関するすべてのログイン情報を含むファイル／et
c／passwdを有する。／etc／passwd内のフィールドは、
次のようにしてレイアウトされている。

ログインid／暗号化パスワード／ユーザid／グループid
／雑／ログイン・ディレクトリ／シエル最初のフィール
ドである「ログインid」は、ユーザのログイン名識別を
含む。第２のフィールドは、ユーザの英数字パスワード
の暗号化は容易に行なえるが、暗号化パスワードを英数
字パスワードに逆変形するのは非常に難しくなるように
設計された、「暗号化パスワード」である。第３のフィ
ールドは、そのシステムが使う「ユーザのＩＤ」番号で
ある。第４のフィールドは、ユーザの「グループｉｄ」
である。このフィールドは、特定のユーザが読取り、書
込みまたは実行あるいはそのすべてを許可されている１
群のファイルを識別するのに使われる。「雑」フィール
ドは、ユーザをさらに識別する任意の追加文字情報を含
むことができる。このフィールドには、氏名や電話番号
などの情報が入れられることが多い。「ログイン・ディ
レクトリ」フィールドは、ユーザのデフォルト・ディレ
クトリが何であるかを指定する情報を含む。最後のフィ
ールドである「シェル」フィールドは、その下でユーザ
が実行するデフォルト・シェルを含む。

／etc／passwd中の各フィールドは、ＵＮＩＸオペレー
ティング・システムが、ユーザの環境をセットアップし
制御するために使う。やはりユーザの環境をそれよりは
直接的でない形で制御することを司どるもう一つのファ
イルは、／etc／groupファイルである。このファイル
は、グループ名とグループidをコード化し、どのユーザ
がどのグループに含まれるかを指定する。／etc／passw
dファイルはログイン・グループを識別するだけである
が、／etc／groupファイルは、ユーザがどのファイル群
の使用を許可されているかを指定する。システムは、ユ
ーザのユーザid番号とユーザのグループidおよび／etc
／groupファイル中の情報によって与えられる許可にも
とづいて、ユーザがどのファイルにアクセスできるかを
判定する。

／etc／groupファイルのフォーマットは次の通りであ
る。

グループ名／暗号化パスワード／グループid／グループ
内の全ユーザのリスト 「グループ名」は、そのグループに関連する英数字名で
ある。「暗号化パスワード」は／etc／passwdファイル
中のパスワードと類似し、グループ情報に対するアクセ
スを保護する。「グループ内の全ユーザのリスト」は、
このユーザ・グループに含まれるすべてのユーザのリス
トである。ＵＮＩＸオペレーティング・システム中の各
ファイルは、唯一の所有者とそれに関連する「グループ
id」、所有者がそのファイルに対してどんな許可を受け
ているか、およびそのグループがそのファイルに対して
どんな許可を受けているかを含む。許容される許可は読
取り、書込み、実行である。ユーザがシステムにログオ
ンすると、システムはそのユーザのユーザ名を取り／et
c／passwdファイルでそのユーザのユーザidとグループi
dをルックアップする。次にシステムは／etc／groupフ
ァイルを探索して、そのユーザがメンバーとして含まれ
ている追加的グループを決定する。この１組の追加グル
ープを、ユーザの協同グループ・リストは呼ばれる。ユ
ーザのユーザid、グループid、および協同グループ・リ
ストから、ユーザがアクセスを許可されているファイル
が決定される。現グループ・リストは、ユーザのグルー
プidで識別されるグループの他に、そのユーザがメンバ
ーとして含まれているすべてのグループを含んでいる。

／etc／opasswdファイルと／etc／ogroupファイルは、
最終更新前の／etc／passwdファイルと／etc／groupフ
ァイルのコピーである。これらは、／etc／passwdファ
イルや／etc／groupファイルが不注意で壊れてしまった
場合のバックアップ・ファイルである。遠隔操作を実現
するにはもう一つ／etc／motdファイルが必要である。
／etc／motdファイルは、当日メッセージ・ファイルで
ある。あるユーザがＵＮＩＸオペレーティング・システ
ムにログオンすると、その日の情報を示すメッセージが
表示される。遠隔ノードにいるユーザがログオン・メッ
セージを入手するには、／etc／motdをマウントしなけ
ればならない。

単一システム・イメージは、上記の各システム・ファイ
ルのマスタ・コピーを一部だけ保存することにより実現
される。これらのコピーは「マスタ」ノードに保存され
る。各ノードは、システム初期プログラム・ロード（Ｉ
ＰＬ）時間に実行される命令のファイルを備えている。
管理者は、システムＩＰＬ時に「マスタ」システムのフ
ァイルをこれらのファイルのそのノード自身のローカル
・コピーの上にマウントするため、手順を命令ファイル
に入れる。こうしたＩＰＬ手順は、マスタ・システム・
ファイルが存在しないノードによって実行されるが、下
記に５つの遠隔マウントされたシステム・ファイルの一
例として／etc／passwdファイルを使ってこの手順を示
す。

1)スタッブ・ファイルを作成する。

注：スタッブとは、他のファイルまたはディレクトリを
その上にマウントできる点として作成されたファイルま
たはディレクトリをいう。

2)「マスタ」の／etc／passwdを上記のようにスタッブ
にマウントする（このステップで、マスタ・ファイルへ
のパスができる）。

3)「マスタ」の／etc／passwdをローカル／etc／passwd
ファイル中に複写する。

4)「マスタ」の／etc／passwdファイルをマウント解除
し、スタッブ・ファイルを削除する。

5)ローカル／etc／passwdファイルの上に「マスタ」の
／etc／passwdをマウントする。

他の４つのシステム・ファイルについてこの手順を繰り
返した後、そのノードはそれらのファイルをマスタとし
て使う。／etc／passwdファイルまたは／etc／groupフ
ァイルを変更する、ＡＤＤＵＳＥＲ（１）コマンドなど
の標準ＵＮＩＸオペレーティング・システム・コマンド
は、今や「マスタ」または（当該の許可を得ている）遠
隔ノードから走行することができる。

複数のノードが／etc／passwdファイルの同じコピーを
共用するという上記の例では、単純ファイルの上に単純
ファイルをマウントすることを用いている。この場合に
（ディレクトリの上にディレクトリをマウントするので
はなく）単純ファイルの上に単純ファイルをマウントす
る必要があるのは、下記の理由からである。

第一に、システム内の多数のプログラムが、パスワード
・ファイルへのパスは“／etc／passwd”であると仮定
するように設計されている。パスワード・ファイルが異
なるディレクトリ、たとえば“／etc／remote／passw
d”へ移された場合、そうしたプログラムをすべて変更
しなければならなくなる。そうなれば、ユーザ、プログ
ラマ、管理者にとって著しく不都合である。

第二に、／etcディレクトリ中には異なる多数のシステ
ム構成ファイルが入っている。単一システム・イメージ
の場合、こうしたファイルのいくつか、例えば／etc／m
asterが各非マスタ計算機にとって一義的なローカル・
ファイルであり、他方／etc／passwdのようなマスタ計
算機から共用されるファイルも共存している。

ディレクトリの上にディレクトリをマウントすることに
よって、非マスタ計算機をマスタの／etc／passwdファ
イルにアクセスさせようと試みると、非マスタ計算機の
／etcディレクトリ全体がマスタの／etcディレクトリで
カバーされるようになるか、あるいは非マスタが異なる
パス、たとえば／etc／master／passwdからpasswdファ
イルにアクセスすることが必要となるはずである。前者
は、非マスタのローカル構成ファイル（たとえば／etc
／master）をも隠してしまうので受け入れられない。後
者は、プログラムや操作員がpasswdファイルにアクセス
するのに使うパスを変えてしまうので受け入れられな
い。また、スタッブファイルに予め遠隔ファイルをマウ
ントする理由が問題となる。これは一旦スタッブという
定位値のマウント点を設けないと該ローカルノードから
マスタノードへの定まったパスの形成ができず、従っ
て、次の「マスタの／／ect／passwdをローカル／ect／
passwdに複写」というステッブがとりえないことに起因
する。ここで、つねにスタッブに対してかかる機能を担
保させているのはこのマウント点がノード・システムフ
ァイルによってバラバラであると、前述したとおりプロ
グラム作成上著しい不都合が生じるためである。

分散単一システム・イメージ環境では、ネットワーク管
理者が、ユーザがどのノードにログオンされていようと
同じディレクトリとファイルが見えるように、各ユーザ
のファイル・ツリーを構成する。このファイル・ツリー
は、どの機械からでもログオンし、どのノードからも同
じインターフェースを提供する能力を提供し、実際上ど
のノードからも単一な環境のシステム・イメージをもた
らす。前述の遠隔マウント能力を用いて、管理者は上記
のようなファイル・ツリーを構築することができる。フ
ァイル・ツリー構成の一例およびそのツリーを実施する
のに必要なステップを下記に示す。

この例では、ＤＥＰＴ５４４＿Ａ、ＤＥＰＴ５４４＿
Ｂ、ＤＥＰＴ５４４＿Ｃと３つのノードがある。共用の
部門資源は、ノードＤＥＰＴ５４４＿Ａのディレクトリ
／ＤＥＰＴ５４４に保持されている。ユーザーＪＯＥの
ファイルは、ノードＤＥＰＴ５４４＿Ｂのディレクトリ
／Ｕ／ＪＯＥに保持されている。上記の単一システム・
イメージ・ファイル・ツリーをセットアップするため、
ネットワーク管理者は、ＤＥＰＴ５４４＿ＢとＤＥＰＴ
５４４＿Ｃの空のスタッブ・ディレクトリ／ＤＥＰＴ５
４４をセットアップし、２つのノードのそれぞれでロー
カル・スタッブ・ディレクトリの上にＤＥＰＴ５４４＿
Ａの／ＤＥＰＴ５４４をマウントする遠隔マウントを実
行するはずである。さらに、ネットワーク管理者は、Ｄ
ＥＰＴ５４４＿ＡとＤＥＰＴ５４４＿Ｃの空のスタッブ
・ディレクトリ／Ｕ／ＪＯＥをセットアップし、２つの
ノードのそれぞれでローカル・スタッブ・ディレクトリ
の上にＤＥＰＴ５４４＿Ｂのディレクトリ／Ｕ／ＪＯＥ
をマウントする遠隔マウントを実行するはずである。こ
のようにして、ネットワーク管理者は、遠隔マウントを
用いて、各ユーザに対して環境を一義的に指定する、分
散環境の単一システム・イメージを作り出す。

５つのシステム・ファイルの遠隔マウントと単一システ
ム・イメージ・ファイル・ツリーの使用を組み合わせて
複数ノードから同じインターフェースをもたらすと、
「マスタ」が活動状態のとき活動化される単一システム
・イメージが提供される。「マスタ」が使用できないと
きは、遠隔ノードは、「マスタ」が使用可能になるまで
読取り専用モードで自分のシステム・ファイルを使用す
る。システム・ファイルの初期遠隔マウントを実行する
ときにスタッブ・ファイルを使うのはその故である。
「マスタ」が使用できない場合、ローカル／etc／passw
dファイルと他のシステム・ファイルは依然システムか
らアクセスでき、「マスタ」が使用可能になるまで正常
にシステム操作が続く。ただし、「マスタ」ファイルの
遠隔マウントが首尾よく行なわれるまでは、システム・
ファイルのローカル更新は許されない。

【図面の簡単な説明】

第１図は、本発明にもとづく分散データ処理システムを
示す構成図である。 第２図は、通常のスタンドアロン・プロセッサ・システ
ムの構成図である。 第３図は、プロセッサ上で走行するアプリケーション・
プログラムが読取りシステム・コールを行なうとき、オ
ペレーティング・システムが実行する各ステップの流れ
図である。 第４図は、本発明をサポートするオペレーティング・シ
ステムによって実行される、ローカル・ノードでファイ
ル操作へのパスをたどるためのシナリオを示す、データ
構造の構成図である。 第５図および第６図は、オペレーティング・システムに
よって実行される、ローカル・ノードでのファイル・マ
ウント操作のシナリオの前後条件を示す、データ構造の
構成図である。 第７Ａ図は、その直属子孫がすべてディレクトリであ
る、ファイル・ツリーの説明図である。 第７Ｂ図は、その直属子孫がディレクトリと単純ファイ
ルの集合である、ファイル・ツリーの説明図である。 第７Ｃ図はその直属子孫がすべて単純ファイルであるフ
ァイル・ツリーの説明図である。 第８図は、第１図に示す分散ファイル・システム用のデ
ータ構造の構成図である。 第９Ａ図ないし第９Ｆ図は、第８図に示したデータ構造
の構成要素の構成図である。 第１０図、第１１図、および第１２図は、オペレーティ
ング・システムによって実行される、ファイル・マウン
ト操作のシナリオ、ローカル・ノードおよび遠隔ノード
でファイルへのパスをたどるためのシナリオを示す、デ
ータ構造の構成図である。 第１３図は、本発明をその中で機能するように設計した
通常の分散データ処理システムの構成図である。 １……分散型データ処理システム、２Ａ、２Ｂ、２Ｃ…
…ディスク、３……ネットワーク、４Ａ、４Ｂ、４Ｃ…
…アプリケーション・プログラム、５Ａ、５Ｂ、５Ｃ…
…ファイル、１０Ａ、１０Ｂ、１０Ｃ……処理装置、１
１Ａ、１１Ｂ、１１Ｃ……オペレーティング・システ
ム、１２Ａ、１２Ｂ、１２Ｃ……サーバ・キャッシュ。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ドツド・アレン・スミス アメリカ合衆国テキサス州オウスチン、ア プリコツト・グレン1802番地 (56)参考文献 ＵＳＥＮＬＸ Ａｓｓｏｃｉａｔｉｏｎ Ｓｕｍｍｅｒ Ｃｏｎｆｅｒｅｎｃｅ Ｐｒｏｃｅｅｄｉｎｇｓ 1986（1986− ６）Ｐ．248−259

Claims (2)

【特許請求の範囲】
1. 【請求項１】階層ファイルシステムを有し、少なくとも
   一つのローカルノードが通信リンクを介して遠隔ノード
   に接続されており、前記遠隔ノードの階層ファイルシス
   テムが少なくとも一つの第一のファイルを含み、前記ロ
   ーカルノードの階層ファイルシステムが少なくとも一つ
   の直属子孫である第二のファイルを有するデイレクトリ
   を含む、データ処理システムであって、 前記遠隔ノードに含まれているｉノード、前記ｉノード
   が存在する遠隔装置を特定する情報、および、ｉノード
   世代番号を有する代理ｉノードと前記ローカルノード内
   の前記階層ファイルシステムとをポインタによって論理
   的に関連付け、前記第二のファイルの内容を維持しつつ
   前記デイレクトリに前記第一のファイルをマウントし、
   前記ローカルノード内の前記階層ファイルシステムから
   前記遠隔ノードの前記階層ファイルシステムの一部に対
   してパスを形成するマウント手段と、 前記第一のファイルに記憶されている前記第一のファイ
   ルに係わるバージョンを示す第一のｉノード世代番号と
   前記代理ｉノードが有する前記ｉノード世代番号とが同
   一であるときに、前記パスを利用して前記第一のファイ
   ルに対してアクセスするアクセス手段と、 を含むデータ処理システム。
2. 【請求項２】複数のノードで構成されており、前記ノー
   ドは各々データ処理システムの状態情報を保持するシス
   テムファイル群と各ユーザに固有のデフォルトファイル
   トリー組織情報を少なくとも含むとともに、前記複数の
   ノードのうちの少なくとも一のノードであるマスタノー
   ドにシステム内で共通なユーザ情報やユーザグループ情
   報を含むマスタシステムファイル群を含んでいるデータ
   処理システムにおいて、全ての上記ユーザに対して共通
   のシステムイメージを作り出す方法であって、 前記ユーザの各々に対して前記デフォールトファイルト
   リー組織情報を維持するステップと、 前記複数のノードの各々においてスタッブファイル群を
   作成するステップと、 前記スタッブファイル群に対して前記マスタシステムフ
   ァイル群をマウントし、前記各々のノードと前記マスタ
   システムファイル群を結ぶパスを形成するステップと、 前記マスタシステムファイル群を前記各ノードのシステ
   ムファイル群に複写するステップと、 前記マスタシステムファイル群をマウント解除し、スタ
   ッブファイル群を削除するステップと、 前記各ノードにおける前記システムファイル群に対して
   前記マスタシステムファイル群をマウントするステップ
   と、 前記デフォールトファイルトリー組織情報を利用して前
   記各ユーザごとに一のデフォールトファイルトリーを作
   成するステップと、 を含む方法。