JPH035847A - 分散データ処理システムにおけるフアイル・アクセス方式 - Google Patents

Abstract

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

Description

【発明の詳細な説明】 Ａ、産業上の利用分野 本発明は、ネットワークを通じて接続された処理システ
ムに関する。特に、ネットワーク内のローカル及びリモ
ートの処理システムの間のファイルの変更に関する。

Ｂ、従来技術 第５図に示すように、分散ネットワーク環境１は、通信
リンク又はネットワーク３により接続された２以上のノ
ードＡ％Ｂ、Ｃから構成される。

ネットワーク３は、ローカル・エリア・ネットワーク（
ＬＡＮ）又は広域ネットワーク（ＷＡＮ）のどちらでも
よい。

ノードＡ、Ｂ、Ｃには、ワークステーション等の処理シ
ステムＩＯＡ、ＩＯＢ、ＩＯＣが存在しうる。これら処
理システムＩＯＡ、ＩＯＢ、１゜Ｃの各々は、シングル
・ユーザー・システムでも又マルチ・ユーザー・システ
ムでもよく、ネットワーク３を用いて遠隔のノードに位
置するファイルにアクセスする能力を有している。例え
ば、ローカル・ノードＡの処理システムＩＯＡは、各々
遠隔ノードＢ、Ｃにあるファイル５Ｂ、５Ｃにアクセス
する事ができる。

本明細書において、用語「サーバー」は、ファイルが永
久的に保持できる形で記憶されている処理システムを示
すために使われ、用語「クライエント」は、そのファイ
ルにアクセスするプロセスを有する他の処理システムを
意味するために使われる。しかしながら、用語「サーバ
ー」は、あるローカル・エリア−ネットワーク・システ
ムで使われているような専用のサーバーを意味するもの
ではない。本発明が実施される分散サービス・システム
は、システム中の異なったノードで種々のアプリケーシ
ョンが走行し、それらがシステム中のどこに位置するフ
ァイルにもアクセスし得る真の分散システムである。

上述のように、以下説明する発明は、通信ネットワーク
中の分散データ処理システムに関するものである。この
環境において、ネットワーク中のノードの各処理装置は
、ファイルがとのノードにあっても、ネットワーク中の
全てのファイルにアクセスすｂ事ができる。

分散データ処理システムを支援する他の方式も知られて
いる。例えば、ＩＢＭのＡＩＸオペレーティング・シス
テムに関する分散サービスは、１９８７年２月１３日に
出願された米国特許出願第０１４８９７号に開示されて
いる。さらに、サン・マイクロシステムズはネットワー
ク・ファイル・システム（ＮＦＳ）をリリースし、ベル
研究所は、リモート・ファイル・システム（ＲＦＳ）を
開発している。サン・マイクロシステムズのＮＦＳは、
Ｓ、Ｒ，Ｋｌｅｉｍａｎ＋　　”Ｖｎｏｄｅｓ：　Ａｎ
　Ａｒｃｈｉｔｅｃｔｕｒｅ　ｆｏｒＭｕｌｔｉｐｌｅ
　Ｆｉｌｅ　Ｓｙｓｔｅｍ　Ｔｙｐｅｓ　　ｉｎ　Ｓｕ
ｎ　ＵＮＩＸ−。

−２４７；　Ｒｕ５ｓｅｌ　Ｓａｎｄｂｅｒｇ　ｅｔ　
ａｔ−、−Ｄｅｓｉｇｎ　ａｎｄＩｍｐｌｅｍｅｎｔａ
ｔｉｏｎ　　ｏｆ　　ｔｈｅ　　Ｓｕｎ　　Ｎｅｔｗｏ
ｒｋ　　Ｆｉｌｅ−８ｙｓｔｅｍｓ　、　　Ｃｏｎｆｅ
ｒｅｎｃｅ　　Ｐｒｏｃｅｅｄｉｎ　ｓ、　　ＵＳＥＮ
ＩＸ１９８５、　　ｐｐ、　　１１９　−　１３０　　
；　　Ｄａｎ　Ｗａｌｓｈ　　ｅｔ　ａｌ、。

Ｏｖｅｒｖｉｅｗ　ｏｒ　　ｔｈｅ　Ｓｕｎ　Ｎｅｔｗ
ｏｒｋ　Ｆｉｌｅ　Ｓｙｓｔｅｍｓ　。

ｐｐ、　　１１７−１２４　；　ＪｏＭｅｉ　Ｃｈａｎ
ｇ、　　”５ＬａＬｕｓ　Ｍｏｎ１ｔｏｒＰｒｏｖｉｄ
ｅｓ　　Ｎｅｔｗｏｒｋ　Ｌｏｃｋｉｎｇ　５ｅｒｖｉ
ｃｅ　　ｆｏｒ　　ＮＦＳ＋。

ＪｏＭｅｉ　Ｃｈａｎｇ　、　”５ｕｎＮｅｔ−、ｐｐ
、　７１−７５　；及びＢｒａｄｌｅｙ　　Ｔａｙｌｏ
ｒ、　　”５ｅｃｕｒｅ　　Ｎｅｔｗｏｒｋｉｎｇ　　
ｉｎ　　ｔｈｅＳｕｎ　Ｅｎｖｉｒｏｎｍｅｎｔ″ｒ　
ｐｐ、　２８−３６を含む一連の刊行物に記載されてい
る。ＡＴＴｆ）ＲＦＳは、Ａｎｄｒｅｗ　Ｐ、　Ｒｉｆ
ｋｉｎ　ｅＬ　ａｌ、、　”ＲＦＳ＾ｒｃｈｉｔｅｃｔ
ｕｒａｌＯｖｅｒｖｉｅｗ　、　　ＵＳＥＮＩＸ　　Ｃ
ｏｎｆｅｒｅｎｃｅ　　Ｐｒｏｃｅｅｄｉｎ　。

Ａｔ１ａｎｔａ、　Ｇｅｏｒｇｉａ　（Ｊｕｎｅ　１９
６ｇ）＋　ｐｐ、　１−１２　；Ｒｉｃｈａｒｄ　Ｈａ
ｍｉｌｔｏｎ　ｅｔ　ａｌ、＋　　”Ａｎ　Ａｄｍｉｎ
ｉｓｔｒａｔｏｒ’ｓＶｉｅｗ　ｏｆ　Ｒｅｍｏｔｅ　
Ｆｉｌｅ　Ｓｈａｒｉｎｇ　ｔ　ｐｐ、　１−９　；　
ＴｏｍＨｏｕｇｈｔｏｎ　ｅｔ　ａｌ−ｅ　Ｆｉｌｅ　
Ｓｙｓｔｅｍｓ　５ｗ１ｔｃｈ”、　ｐｐ−１−２；及
びＤａｖｉｄ　Ｊ、　Ｏ！ａｎｄｅｒ　ｅｔ　ａｌ、、
　”ＡＦｒａｍｅｗｏｒｋ　ｆｏｒ　Ｎｅｔｗｏｒｋｉ
ｎｇ　ｉｎ　Ｓｙｓｔｅｍ　Ｖ−ｔ　ｐｐ、　１−８を
含む一連の刊行物に記載されている。

本発明が実施される分散サービス・システムの１つの特
徴であって、サン・マイクロシステムズのＮＦＳと異な
る点は、例えば、サンの方式が基本的に状態非保存の（
ｓｔａｔｅ　１ｅｓｓ）サーバーを設計しようとした事
である。これは、サーバーがクライエント・ノードに関
する情報を記憶しない事を意味している。情報としては
、例えば、どのクライエント・ノードがサーバー・ファ
イルをオーブンしているか、又はクライエント・ノード
のプロセスがファイルを読取り専用モード又は読み書き
モードのどちらでオーブンしているかといった事である
。そのような実施形態はサーバーの設計を単純化する。

というのは、クライエントがサーバーの資源に対する要
求を解放しようとしている事をサーバーに適切に伝える
事なしにクライエントが故障したり又はオフライン状態
になったりした時に生じるエラー回復状況を、サーバー
が処理する必要がないからである。

本発明が実施される分散サービス・システムの設計では
、完全に異なった方式が取られた。より具体的には、そ
の分散サービス・システムは「状態保存式の（ｓｔａｔ
ｅｒｕｌ）実現」として特徴付けられる。ここで述べる
ような「状態保存式」サーバーは、そのファイル壱誰が
使用しているか、及びファイルがどのように使用されて
いるかについての情報を保持する。従って、サーバーは
、クライエントに関する蓄積された状態情報を廃棄でき
るように、クライエントとの接触の喪失を検出する何ら
かの方法を有していなければならない。ここで述べるキ
ャッシュ管理方式は、サーバーがそのような状態情報を
保持しなければ実現できない。

遠隔ノードをアクセスする時に出会う問題は、先ず、単
独で用いられるシステムがどのようにファイルにアクセ
スするがを調べる事によって良く理解できる。第２図に
示すノード１ｏのような単独のシステムにおいて、ワー
クステーション中のハード・ファイル又はディスク等の
永久的記憶装置２とユーザーのアドレス空間１４との間
で転送されるデータをバッファするために、オペレーテ
ィング・システム１１中のローカル・バッファ１２が使
用される。オペレーティング・システム１１中のローカ
ル・バッファ１２は、ローカル・キャッシュ又はカーネ
ル・バッファとも呼ばれる。

単独のシステムでは、カーネル・バッファ１２はブロッ
ク１５に分割されている。これは、デバイス番号、及び
デバイス内の論理ブロック番号により識別されている。

読取りシステム・コール１６が発行される時、それは第
３図のステップ１０１に示すようにファイル５のファイ
ル記述子及びファイルＳ内のバイト範囲と共に発行され
る。オペレーティング・システム１１は、この情報を受
取り、第３図のステップ１０２に示すようにそれをデバ
イス番号及びデバイス中の論理ブロック番号に変換する
。もしブロックがキャッシュ中にあれば（ステップ１ｏ
３）、データは直接キャッシュから得られる（ステップ
１０５）。キャッシュが、探しているブロックを保持し
ていない場合（ステップ１０３）、データはキャッシュ
中に読み込まれ（ステップ１０４）、その後キャッシュ
からデータが取得される（ステップ１０５）。

ディスク２から読取られたデータは、キャッシュ・ブロ
ック１５が他の目的のために必要になるまで、キャッシ
ュ・ブロック中に保持される。従って、処理システム１
０上で走行しているアプリケーション４からの連続した
読取り要求が、以前に読取ったのと同じデータに関する
場合は、ディスク２ではなくキャッシュ１２にアクセス
が行なわれる。キャッシュからの読取りは、ディスクか
らの読取りよりも遥かに時間を要しない。

同様に、アプリケーション４から書込まれたデータは、
即座にディスク２上には保存されず、キャッシュ１２に
書込まれる。これは、他の書込動作が同じブロックに対
して行なわれる場合にディスクのアクセスを節約する。

キャッシュ１２中の変更されたデータ・ブロックは、周
期的にディスク２に保存される。

ＡＩＸオペレーティング・システムを用いる単独のシス
テムでのキャッシュの使用は、連続した読取りと書込み
に関してディスクのアクセスが不用になるので、システ
ムの全体的性能を改善する。

全体的性能の改善は、永久的記憶装置のアクセスがキャ
ッシュのアクセスよりも低速で且つより高価な事による
。

第５図に示すような、分散環境において、ローカル・ノ
ードＣにある処理システムＩＯＣがノードＡからファイ
ル５Ａを読取る事ができる２つの方法がある。１つの方
法では、処理システム１０Ｃがファイル５Ａ全体をコピ
ーし、あたかもそれがノードＣに存在するローカル・フ
ァイル５Ｃであるかのように読取りを行なう。この方法
のファイル読取りは、もしファイル５Ａがファイル５Ｃ
としてノードＣにコピーされた後で他のノードＡの他の
処理システムＩＯＡがファイル５Ａを変更する場合に、
問題を生じる。その場合、処理システムＩＯＣは、ファ
イル５Ａに対するこれら最新の変更にアクセスしないで
あろう。

ノードＡのファイル５Ａに処理システム１０Ｃがアクセ
スする他の方法は、ノードＣの処理システムが要求する
時に、■ブロック、例えばＮ１を読取る事である。この
方法に伴う問題は、あらゆる読取りが、ネットワーク通
信リンク３を経由して、ファイルが存在しているノード
Ａに行かなければならない事である。各連続した読取り
毎にデータを送信するのは多大の時間を要する。

ネットワークを介してファイルにアクセスする事は、上
述のように２つの競合する問題を生じる。

１つの問題は、連続した読取りと書込みのためにネット
ワークを介してデータを転送するのに必要な時間に関係
している。一方、もしネットワーク・トラフィックを減
少させるためにファイルのデータがノードに記憶される
ならば、ファイルの整合性が失われる可能性がある。例
えば、もし幾つかのノードの１つがファイルに書込みも
行なうと、そのファイルにアクセスしている他のノード
は、ちょうど書込まれた最新の更新されたデータにはア
クセスしない可能性がある。従って、ノードが正しくな
く且つ古くなったファイルにアクセスする可能性がある
という意味で、ファイルの整合性が失われる。

ＵＮＩＸオペレーティング・システムに基すいたオペレ
ーティング・システムでは、ファイル内のあらゆるバイ
トに書込みを行う必要はない。例えば、もしファイルが
１００００バイトであるとすると、プロセスは、ファイ
ルの最初のバイトとファイルの１００００番目のバイト
に書込みを行い、他のバイトには書込みを行わなくても
よい。

もしバイト数１０００１を読取ろうとする試みが行われ
ると、これはファイル終端以遠であり、それを読取る事
はできない。しかしながら、もしバイト２〜９９９９の
読取りが試みられると、それらはファイル終端以遠では
ない。これらの真ん中のバイトは、書込まれた事はなく
、それらに対してディスク・ブロックは割当てられてい
ない。これは、ＵＮＩＸオペレーティング・システムに
基ずくファイル・システムの利点である。これらのファ
イル・システムは、書込まれた事のないバイトにはブロ
ックを割当てない。しかしながら、それらはファイル終
端以遠ではないので、もしプロセスがこれらのバイトか
ら読取りを行おうとすると、プロセスは論理的にゼロの
バイトを得る。

従って、本発明の良好な実施例では、プロセスは、バイ
トを書込む事ができる前に、ｇｅｔ　　ｂｙｔｅｓ要求
でそれらのバイトを要求しなければならない。これらの
バイトを受取ると、プロセスはこれらのバイトに重ね書
きができる。例えば、プロセスが１バイトを書込みたい
ものと仮定する。

プロセスは、ちょうど１バイトを要求する事も又異なっ
た範囲のバイトを要求する事もできるが、４に範囲のバ
イトを要求してもよい。プロセスは、このバイト範囲を
受取ると、受取ったバイト範囲内のバイトの１つに書込
みを行なうことができる。

この例で、４にのバイト範囲が使われたのは、クライエ
ント・データ処理システムが、はぼ４にバイトのページ
−レベル・ベースでそのデータを管理しているからであ
る。

Ｃ１発明が解決しようとする課題 しかしながら、書込みに関する最も頻繁なケースは、プ
ロセスが、既存のデータを持たない新しいファイルに書
込みを行う時である。この場合、プロセスは、新しいフ
ァイルの開始位置で書込みを始め、ファイルの終りまで
書込みを行う。従って、プロセスは、以前には存在して
いなかったファイルの部分に定常的に書込みを行う。以
前のシステムでは、この書込を行う前に、クライエント
・処理システムで走行しているプロセスは、ネットワー
クを介してバイトのページ全体を要求しなければならな
かった。このバイトのページに書込が行われると、次の
バイトのページが要求された。

しかしながら、これは、ただ論理ゼロを有しているバイ
トのブロックを得るだけのためにクライエント・データ
処理システムとサーバー・データ処理システムとの間に
多量のネットワーク・トラフィックを生じる。

９０課題を解決するための手段 分散データ処理システムでは、データは、複数のノード
によってアクセスできる。本発明では、データは、サー
バーとして知られている、このデータ処理システム内の
１つのノードによって制御される。このデータにアクセ
スする他のノードは、クライエントとして知られている
。クライエントも又、サーバーに要求を送る事によって
データにアクセスする。サーバーは、データへのアクセ
スを要求したクライエントに、データを返す。次に、ク
ライエントは、要求されたデータを、読取り及び／又は
変更できる。複数のクライエントがデータに興味を持つ
時、サーバー・ノードは、データを首尾一貫した状態に
保つためにデータへのアクセスを同期化しなければなら
ない。サーバー・ノードは、任意の与えられた時点で、
ノードにおいて変更のためにアクセス可能なデータの各
部分が、他のノードによる読取り又は変更のためにアク
セス可能でない事を保証し、一方読取りのためだけにア
クセス可能なデータの部分が、任意の数のノードにより
アクセス可能である事を許容することにより、これを行
っている。

この同期化を強制するために、ファイルの一部に書込を
行うか又はファイルを拡張したいクライエントは、最初
に、サーバーから、変更されるべきバイトを含むあるバ
イト範囲への書込みアクセスを要求しなければならない
。クライエントは、ｇｅｔ　　ｂｙｔｅｓメツセージを
通じて、サーバーに、バイト範囲を要求する。サーバー
は、要求されたバイトを用いて、その要求に応答する。

次に、クライエントはそれらのバイトを変更できる。

しかしながら、ある状況では、もし異なったクライエン
トから衝突を生じるような要求が発生すると、いくつか
のクライエントからのバイト範囲のアクセスを同期化す
るために、以前にクライエントに配布したデータを、サ
ーバーが取消す必要があるかもしれない。サーバーは、
サーバーからクライエントへのｒｅｖｏｋｅ　　ｂｙｔ
ｅｓメツセージによりバイト範囲を取消す。

ファイルへの殆どの書込みは、各新しいブロックが新規
に割当てられ、且つゼロ・バイトだけしか含んでいない
終端部で行われるが、プロセスが遠隔ファイルのブロッ
クに書込み又は記憶を行う最も一般的な場合では、書込
み又は記憶を行う事ができる以前に、ファイルのサーバ
ーからブロックが取得されなければならない。一般的な
機構のコストを緩和するために、本発明は、重要な特別
な場合、即ち以前にファイル中に存在しなかったブロッ
クへの書込み及び記憶を最適化する。これは、既存のフ
ァイルに付加を行いそして新しいファイルを形成するコ
ストを減少させる。

もしファイル中のブロックが新しいブロックであって、
これまでファイル中に存在しなかったものである事を、
クライエントが知っていれば、クライエントは、サーバ
ーに接触せずに、ゼロのブロックを形成し、それを使う
事ができるであろう。

これは、ｇｅｔ　　ｂｙｔｅｓ要求のコストを避ける事
ができるが、またそれは、ファイルのサーバーにおける
対応するディスク・ブロックの割当てなしにクライエン
トでブロックを形成するであろう。クライエントがサー
バーの資源をオーバーコミットしないように且つ２つの
場所に同じブロックを形成する事によって互に干渉する
事のないようにするために、サーバーは、新しいページ
の割当てに対して制御を保持する。

サーバーは、クライエントに実際のバイトに加えて初期
ゼロ（ｎａｓｃｅｎｔ　ｚｅｒｏ）を送る事によって、
新しいファイル・ブロックの分散割当てを管理する。サ
ーバーが、ｇｅｔ　　ｂｙｔｅｓ要求に応答する時、そ
れは、任意的に、要求されていない初期ゼロの範囲を返
しても良い。初期ゼロは、まだファイル中に含まれてい
ない、新しい、論理的にゼロのバイトである。返される
初期ゼロの範囲は、通常、要求されたバイトの範囲より
も大きい。初期ゼロは、これまで記憶又は書込みが行わ
れておらず、ファイルの現在の範囲の外側にあるかもし
れない。ファイルからの実際のバイトと同様に、初期ゼ
ロの範囲は、他のクライエントがその範囲と重なり合う
どのようなデータ（実際の又は初期の）も有していない
場合に限って、それらに書込みを行う可能性のあるクラ
イエントに送られる。

実バイトと同様に、初期ゼロは、ｒｅｖｏｋｅ−ｂｙｔ
ｅｓメツセージを用いてサーバーにより取消す事ができ
る。

本発明は、プロセスがサーバー・データ処理システムか
らのバイトを要求する毎に、サーバーが、要求されたバ
イトを送り返すだけではなく、これまで書込まれた事の
ないデータを含む付加的なバイト範囲も送り返す事を可
能にする。この型のデータは、ここでは、初期ゼロと呼
ばれる。サーバーは、もしこれらの付加的なバイトにク
ライエントが書込みを行いたいかもしれないと判定する
と、この付加的なバイト範囲を送り渇す。サーバーは、
クライエントが元々要求したものよりも大きなバイト範
囲への書込みの許可をクライエントに与えている。

クライエントが以前に書込まれていたバイト範囲に勝手
に書込みを行う事ができる代りに、サーバーがこの付加
的なバイト範囲を管理する事が重要である。サーバーは
、利用可能な物理的記憶域の大きさに対して制御を有し
ているので、この付加的なバイト範囲に対する書込みの
許可をクライエントに与えるものがサーバーである事は
重要である。ファイルがクローズされる時及びデータが
返される時、サーバーがこの付加的なデータを記憶する
ための十分なスペースを有している事を、サーバーは保
証しなければならない。従って、サーバーがクライエン
トに初期ゼロの範囲を与える前に、サーバーは、もしク
ライエントがこの付加的な範囲に書込みを行う事を決定
する場合に、ディスク・スペースが確保されている事を
確認しなければならない。

しかしながら、クライエントは、この付加的な範囲に書
込みを行わないように決定する事もできる。この場合、
サーバーは依然としてディスク・スペースを予約したま
まである。サーバーは、クライエントがこのファイルを
クローズする時、この付加的なバイト範囲が書込まれて
いるか否かを判定する。もしクライエントが初期ゼロの
この付加的なバイト範囲に書込みを行っていなければ、
サーバーはこのディスク・スペースを解放できる。

クライエントがこれらのバイトに書込みを行う可能性を
有している限り、サーバーは単にディスク・スペースを
保持する。

本発明の良好な実施例では、サーバーは、以前にクライ
エントに与えた初期ゼロのバイト範囲を取消す必要があ
るかもしれない。というのは、他のクライエントがこの
付加的なバイト範囲を要求するかもしれないからである
。従って、サーバーは、クライエントにより要求された
バイト範囲のみならず、（たとえクライエントが特に要
求しなかったとしても、サーバーによってクライエント
に与えられた）付加的な初期ゼロ・バイトの範囲も取消
す事ができる。

本発明のいくつかの利点は下記の通りである。

サーバーは、ファイルＷ端からだけでなく、以前に書込
まれていないファイル内の任意のバイト範囲から、初期
ゼロの範囲を返す事ができる。例えば、クライエントは
ファイル内のバイトの範囲を要求してもよい。もし、ク
ライエントの要求している範囲に隣接して初期ゼロの範
囲が存在していると、サーバーが判断すると、サーバー
は、この付加的な初期ゼロの範囲をクライエントに与え
るという選択肢も有する。

他の利点は次の例に示されている。クライエントは、フ
ァイルの最後のブロックを表わすバイト範囲を要求し得
る。サーバーは、この最後のバイトのブロックだけでな
く、初期ゼロの任意の数の付加的なページも返す事がで
きる。説明のために、サーバーは４つの付加的なページ
を返すものとする。クライエントが、この最後のバイト
のブロック及び付加的な４つの初期ゼロのページへの書
込みを終了する時、クライエントはサーバーに他のブロ
ックのバイトを要求する事ができる。次に、サーバーは
、クライエントが次に要求したバイトのブロックだけで
なく、他の付加的な４ページの初期ゼロもクライエント
に返す事ができる。この場合、クライエントは、各要求
されたブロック毎にではなく、各５番目のブロック毎に
サーバーにアクセスするだけでよいので、ネットワーク
・トラフィックが減少する。

本発明の結果、ファイルを拡張するために必要な特別の
プロトコルは存在しない。ファイルの拡張は、サーバー
が、初期ゼロの付加的な範囲をクライエントに提供する
事により、自動的に行われる。各ｇｅｔ　　ｂｙｔｅｓ
要求毎に、サーバーは、初期ゼロの付加的な範囲のバイ
トを返す選択肢を有する。

プロトコルのこの態様によれば、サーバーは、初期ゼロ
を返す事は要求されない。従って、初期ゼロに関する要
求を取扱うためにこのプロトコルを設計する上で何の余
分のメツセージも必要でなかった。従って、サーバーは
、初期ゼロが返されるべきことを要求するプロトコルに
固執する必要はない。従って、初期ゼロを返すように設
計されたサーバーは、分散データ処理システム中の他の
サーバーが任意的に初期ゼロを返すように設計されてい
ないようなシステム中でも、依然として機能できる。同
様に、クライエントは、返された初期ゼロを使用する義
務はない。クライエントは、この付加的な初期ゼロの範
囲を使用せず、クライエントがバイト範囲を必要とする
毎にサーバーに要求するという選択波を有している。従
って、初期ゼロが返された事を認識し、それらに書込む
事のできるクライエントは、他のクライエントがこの付
加的な初期ゼロの範囲を認識しないような分散データ処
理システム中でも機能できる。このようにして、分散デ
ータ処理システム中で、高性能サーバーは、低機能クラ
イエントとも依然として通信でき、また逆も真である。

よって、サーバーとクライエントとの間の通信中にどの
レベルのサポートが使用されるかに関して、サーバーと
クライエントとの間で交渉する必要はない。

クライエントがどれ位の要求をする必要があるかをクラ
イエントに決定させて、サーバーにその要求に応答させ
る代りに、これら付加的な範囲の初期ゼロ−バイトがク
ライエントに渡されるかどうかに関して、サーバーが決
定を行う。例えば、もしいくつかのクライエントがファ
イルの終端に書込みを行っているならば、サーバーは、
ｒｅｖ。ｋｅ　　ｂｙｔｅｓメツセージのトラフィック
が非常に高いと判定するかもしれない。この場合、サー
バーは、付加的な範囲の初期ゼロを与えないように決定
する事ができる。さらに、サーバーは、ディスクが容量
の限界に接近しようとしていると判定するかもしれない
。この場合、サーバーは、ディスク上のスペースを確保
するために、それ以上の初期ゼロ範囲を与えないように
決定する事ができる。逆に、もしディスク上に多くのス
ペースが残されていれば、サーバーは、どれかのクライ
エントが十分なディスク・スペース有しなくなるという
危険を犯すことなく、クライエントに大きな範囲の初期
ゼロを与えることができる。

Ｅ、実施例 分散データ処理システムにおいては、共有データにアク
セスする複数のノードが存在する。本発明は、この分散
データ処理システムにおける複数のノードによるファイ
ルへのアクセスを管理する。

ファイルは、サーバーとよばれるノードに物理的に記憶
されている。サーバーは、ファイルの長期的な記憶を行
う処理システムである。ｊ１信ネットワークによりサー
バーに接続された他のノードも、このファイルにアクセ
スする事ができる。これらのノードは、これらの状況の
下では、クライエントとして知られている。どのノード
も、何らかのファイルに関してはサーバーであり、他の
ファイルに関してはクライエントであり得る。ノードは
、同時に両方の機能で動作できる、即ちクライエントと
して遠隔のファイルにアクセスし、一方サーバーとして
他のノードにサービスを提供する事ができる。

クライエントとしてのノードの活動及びサーバーとして
のノードの活動は、互に独立である。従って、たとえこ
れら２つの活動が並行して生じることが可能であるとし
ても、これら２つの活動は別々に説明する。

第４Ａ〜４Ｄ図を参照すると、ここで使われているノー
ド間メツセージが説明されている。

第４Ａ図は、クローズ動作をサーバーに知らせるために
クライエントによって使われるクローズ・メツセージ４
１０を示している。変更カウント４１１は、クライエン
トにおける変更を反映する値である。アクセス・カウン
ト４１２は、クライエントにおけるアクセスを反映する
値である。

第４Ｂ図は、ファイルからデータ・バイトを要求するｇ
ｅｔ　　ｂｙｔｅｓメツセージ４４０を示している。オ
フセット４４１は、要求されたデータの開始点を示すフ
ァイルのオフセットである。

長さ４４２は、要求されたバイトの数である。読取り／
書込みフラグ４４３は、クライエントが、データの読取
り専用のコピーを要求しているか又は書込み可能のコピ
ーを要求しているかを示すために使われる。Ｒ／Ｗフラ
グの許された値は、もしクライエントがバイト範囲を読
取るだけの場合は０ｘＯ０００であり、もしクライエン
トがバイトを変更しうる場合は０ｘＯＯＯ１である。も
しクライエント・ノードが互換モードでファイルを以前
にオーブンしていて、まだクローズしていなければ、サ
ーバーはｇｅｔ　　ｂｙｔｅｓ動作だけを実行する。も
しＲ／Ｗフラグ４４３が読取り専用であれば、クライエ
ントはファイルを読取りのためにオーブンさせたはずで
ある。もしＲ／Ｗフラグ４４３が読み書きであれば、ク
ライエントはファイルを書込みのためにオープンさせた
はずである。

ｇｅｔ　　ｂｙｔｅｓメツセージ４４０の応答において
、ＮＺオフセット４４４は、初期（ｎａｓｃｅｎｔ、）
ゼロが存在するバイトが要求されているファイル内のオ
フセットである（初期ゼロは、本発明の関連出願に説明
されている）。このフィールドは、フィールドＮＺ長さ
がゼロよりも大きい時にのみ意味を持つ。フィールドＮ
Ｚ長さ４４５は、初期ゼロのバイト数であり、これはＮ
Ｚオフセット４４．４から始まる。サーバーは、要求者
に返すためにＮＺオフセットを選択する。サーバーは、
常に初期ゼロの処置を行なわないように選択しても良く
、このフィールドにゼロを返す事によってこの事を示す
。長さ４４６は、返されるデータの長さである。データ
４４７は、要求された実際のデータ・バイトである。

第４ＣｒＪＡは、ｐｕｔ　　ｂｙｔｅｓメツセージ４６
ｏを示す。クライエントは、ｐｕｔ　　ｂｙｔｅＳメツ
セージ４６０を用いてサーバーに変更データを返す。も
しクライエントが以前にオープンされていて且つまだク
ローズされていす、ファイルが書込み用であれば、サー
バーは単にｐｕｔ　　ｂｙｔｅｓ動作だけを実行する。

オフセット４６１は、長さ４６２のデータ・バイト４８
３が置かれるべきファイル内のオフセ・ントである。

第４Ｄ図は、ｒｅｖｏｋｅ　　ｂｙｔｅｓメツセージ４
７０を示す。このメツセージは、ｇｅｔ−ｂｙｔｅｓメ
ツセージ４４０に対する応答の中でクライエントに以前
与えられた。バイトを取消すためにファイルのサーバー
からクライエントに送られる。クライエントは、オフセ
ット４７１及び畏さ４７２によって示されるバイト範囲
に関して、それが全てのクリーンなキャッシュされたデ
ータ及び初期ゼロを廃棄し、全ての汚れたデータをサー
バーに書込み応答を受取るまでは、応答を送らない。ク
ライエントが応答を送る時、それは、取消されたバイト
範囲に関するキャッシュされたデータを全く有していな
いはずである。このメツセージは、取消し範囲内に入る
、以前に返された初期ゼロをクライエントが使用する権
利を取消す。

ｒｅｖｏｋｅ　　ｂｙｔｅｓが処理される時に未解決で
あったｇｅｔ　　ｂｙｔｅｓ要求により返された取消さ
れたバイト範囲内のどのデータ又は初期ゼロも、それら
が到着する時に取消されなければならない。クライエン
トは、要求されたよりも大きなバイト範囲を取消す事を
選択しても良く、又要求された範囲よりも大きな範囲中
に取消すものが存在しない事を判定できても良い。その
ような場合、応答オフセット４７３及び応答長さ４７４
が、クライエントがキャッシュされたページを持たない
範囲を示す。応答オフセット４７３及び応答長さ４７４
は、少なくとも、オフセット４７１及び長さ４７２によ
って示された範囲を含まなければならない。

第４Ａ〜４Ｄ図とともに第６図を参照すると、クライエ
ントがファイル中のデータにアクセスすることを望む時
、クライエントは、ｇｅｔ　　ｂｙｔｅｓＷ求又はメツ
セージとして知られる要求を、ファイルのサーバーに送
る（ステップ６０１，６０２）。ｇｅｔ　　ｂｙｔｅｓ
要求は、他の項目に加えて、クライエントがアクセスし
ようとしているバイトの範囲４４１．４４２（第４Ｂ図
）を指定する。ｇｅｔ　　ｂｙｔｅｓ要求４４０は、ク
ライエントからサーバーに送られる。サーバーは、準備
ができると、要求を行っているクライエントにその範囲
のデータを送り返す事によってｇｅｔ−ｂｙｔｅｓ要求
に応答する（ステップ６０３．６０４）。このｇｅｔ　
　ｂｙｔｅｓ応答は、クライエントがこのデータにアク
セスする事を可能にする。

サーバーが以前に満足させた他のｇｅｔ　　ｂｙｔｅｓ
要求（ステップ６０３）の後に、ｇｅｔ　　ｂｙｔｅｓ
要求４４０が、サーバーに到着する（ステップ６０５．
６０６）場合、サーバーは、以前に他のクライエントに
送ったバイトを取消す必要があるかもしれない（ステッ
プ６０７）。バイトは、ｒｅｖｏｋｅ　　ｂｙｔｅｓメ
ツセージ４７０（第４Ｄ図）を用いて取消される。ｒｅ
ｖｏｋｅ　　ｂｙｔｅｓメツセージ４７０は、サーバー
からクライエントに送られる。クライエントは、取消さ
れようとしているバイト範囲中の変更データを送り返す
事によって、ｒｅｖｏｋｅ　　ｂｙｔｅｓ要求に応答す
る義務がある。又クライエントは、その範囲中の変更さ
れなかったデータを廃棄する義務もある。

クライエントは、ｐｕｔ　　ｂｙｔｅｓメツセージ４Ｇ
ｏ（第４Ｃ図、及び第６図、ステップ６Ｑ９）を用いて
サーバーに変更データを送り返す。

このメツセージは、ｇｅｔ　　ｂｙｔｅｓメツセージ及
びｒｅｖｏｋｅ−ｂｙｔｅｓメツセージと同様に、受取
り側が送信側に送り返す応答を有している（ステップ６
１１）。３つの場合全部で、応答は、宛先の受信者がメ
ツセージを受取りそれに基すいて活動した事を、送信側
に知らせる。ｇｅｔｂｙｔｅｓ要求４４７（第４Ｂ図）
に対する応答中でサーバーからクライエントに、及びｐ
　ｕ、　を−ｂｙｔｅｓメツセージ４６３（第４Ｃ図）
に対する応答中でクライエントからサーバーに、データ
が実際に移動している事に注意されたい。

サーバーがｒｅｖｏｋｅ　　ｂｙｔｅｓ要求を発行しな
ければならない状況（ステップ６０７）は、この範囲の
バイトに書込みアクセスを行いたいクライエントからサ
ーバーにｇｅｔ　　ｂｙｔｅｓ要求が到着する（ステッ
プ６０６）時に、起きる。サーバーは、以前にクライエ
ントに送られその後取消されていないこの範囲内の全バ
イトを取消さなければならない。フライエンｌ−がｇｅ
ｔ　　ｂｙｔｅｓ要求を発行する毎に、サーバーは、サ
ーバーがそのクライエントに発行したｇｅｔ、　　ｂｙ
ｔｅＳ応答の記録（第１図）を保持する。このようにし
て、サーバーは、クライエント・ノードに送り出された
ファイルに属するデータの全てのコピーを追跡できる。

書込みのためにこれらのバイトを要求するクライエント
からｇｅｔ　　ｂｙｔｅｓ要求が到着すると、サーバー
は、他のクライエントが現在その同ｂバイトを読取り又
は書込みのために検査していない事を確認するために、
記録を調べる。もし他のクライエントがそれらのバイト
を検査していれば、最初にサーバーは、そのバイトを検
査しているクライエントの各々にｒｅｖｏｋｅｂｙｔｅ
ｓメツセージを送る事により、それらを取消す。これら
のクライエントは、バイトが変更されている場合には％
　ｐｕｔ　　ｂｙｔｅｓメウセージを用いてサーバーに
バイトを送り返し、そしてバイトが変更されていない場
合は、クライエントはバイトを廃棄する。しかしながら
、全部の場合において、バイトが取消された後、クライ
エントはそれらのバイトにアクセスしない。ｐｕｔｂｙ
ｔｅｓ応答（ステップ６１２）を受取った後、クライエ
ントは、返されたデータがサーバーによって受取られた
事を知らされ、クライエントはｒｅｖｏｋｅ　　ｂｙｔ
ｅｓ要求に応答する（ステップ６１３）。

（取消しによりトリガされたｐｕｔ　　ｂｙｔｅＳメ・
ンセージを受取った後で）サーバーがｒｅｖｏｋｅ　　
ｂｙｔｅｓ応答を受取る時（ステップ６１４）、サーバ
ーは、ｇｅｔ　　ｂｙｔｅｓ応答中で要求側クライエン
トにバイトを送り、それらのバイトを変更する許可をそ
のクライエントに与える事によって、書込みのためのｇ
ｅｔ　　ｂｙｔｅＳ要求に応答する事ができるようにな
る。このようにして、ファイル中のデータは、１つの場
所でのみ変更される。もしデータが変更されている最中
ならば、他のクライエントはそのデータの範囲にはアク
セスしない。これは、クライエントが再びそのデータへ
のアクセスを取得する時までに、クライエントが、その
後の全ての書込み動作の結果として得られたデータを見
る事を保証する。

重要なルールは、ファイル内のどのバイトに関しても、
１つの計算機だけが書込みのためにそのバイトを所持で
きるが、一方任意の数の計算機が読取りのためにバイト
を検査できる事である。良好な実施例では、バイトは個
々には追跡されない。

その代りに、クライエントによって要求されたバイト範
囲が追跡される。良好な実施例では、任意のバイト範囲
に関して、１つだけのクライエントが、書込みアクセス
のためにそのバイト範囲にアクセスできる。

本発明のシステム及び方法は、どのようにしてクライエ
ント計算機が、効率的にファイルを拡張でき、且つ以前
にデータによって占有されていなかったファイルの領域
に書込む事ができるかを制御する。クライエントとサー
バーとの間で送受されるメツセージの数を最小限にする
事が望ましい。

また、サーバーで管理されているディスク・スペースを
、クライエントがオーバーコミットする可能性を最小限
にする事が望ましい。

ファイルへの殆どの書込みは、各折しいブロックが新規
に割当てられ、且つゼロ・バイトだけしか含んでいない
終端部で行われるが、プロセスが遠隔ファイルのブロッ
クに書込み又は記憶を行う最も一般的な場合では、書込
み又は記憶を行う事ができる以前に、ファイルのサーバ
ーからプロ・ンクが取得されなければならない。一般的
な機構のコストを緩和するために、本発明は、重要な特
別な場合、即ち以前にファイル中に存在しなかったブロ
ックへの書込み及び記憶を最適化する。これは、既存の
ファイルに付加を行いそして新しいファイルを形成する
コストを減少させる。

もしファイル中のブロックが新しいブロックであって、
これまでファイル中に存在しなかったものである事を、
クライエントが知っていれば、クライエントは、サーバ
ーに接触せずに、ゼロのブロックを形成し、それを使う
事ができるであろう。

これは、ｇｅｔ　　ｂｙｔｅｓＷ求のコストを避ける事
ができるが、またそれは、ファイルのサーバーにおける
対応するディスク・ブロックの割当てなしにクライエン
トでブロックを形成するであろう。クライエントがサー
バーの資源をオーバーコミットしないように且つ２つの
場所に間じブロックを形成する事によって互に干渉する
事のないようにするために、サーバーは、新しいページ
の割当てに対して制御を保持する。

サーバーは、クライエントに実際のバイトに加えて初期
ゼロ（ｎａｓｃｅｎｔ　ｚｅｒｏ）を送る事によって、
新しいファイル・ブロックの分散割当てを管理する。サ
ーバーが、ｇｅｔ　　ｂｙｔｅｓ要求に応答する時、そ
れは、任意的に、要求されていない初期ゼロの範囲を返
しても良い。初期ゼロは、まだファイル中に含まれてい
ない、新しい、論理的にゼロのバイトである。返される
初期ゼロの範囲は、通常、要求されたバイトの範囲より
も大きい。初期ゼロは、これまで記憶又は書込みが行わ
れておらず、ファイルの現在の範囲の外側にあるかもし
れない。ファイルからの実際のバイトと同様に、初期ゼ
ロの範囲は、他のクライエントがその範囲と重なり合う
どのようなデータ（実際の又は初期の）も有していない
場合に限って、それらに書込みを行う可能性のあるクラ
イエントに送られる。

実バイトと同様に、初期ゼロは、ｒ６ｖｏｋｅ−ｂｙｔ
ｅｓメ・ンセージを用いてサーバーにより取消す事がで
きる。

クライエント計算機は、決して明示的に初期ゼロを要求
しない。その代りに、クライエントは、要求しなかった
初期ゼロを受取るが、これはｇｅｔ　　ｂｙｔｅｓ要求
に対する応答中でしか受取れない。これは、サーバーが
クライエントに初期ゼロを返す義務がない事を意味して
おり、単純なサーバーの実施形態は初期ゼロを与える事
なく正しく機能する。しかしながら、そのような実施形
態は、初期ゼロを使用する実施形態程には効率的にクラ
イエントをサポートしない。初期ゼロがクライエント計
算機に分配された時、それらは、与えられた実バイトと
同様に追跡されなければならない。もし異なったクライ
エントに与えられていた初期ゼロ又は実バイトに重なる
バイト範囲を、矛盾を生じる形で（即ち、読取りアクセ
ス対書込みアクセス）、あるクライエントが要求すると
、サーバーは、実バイト及び初期ゼロの両者を取消さな
ければならない。ｒｅｖｏｋｅ　　ｂｙｔｅｓ要求は、
指定された範囲の実バイト及び初期ゼロの両者を取消す
ので、サーバーは、バイト又はゼロを保持している各ク
ライエントに１つのメツセージだけを送りさえすれば良
い。サーバーは、単に、ファイルの実バイト又は初期ゼ
ロのどれかを有している各クライエントから、ファイル
に関する全てのバイト及び初期ゼロを取消す事によって
、与えたバイト及びゼロに関する勘定を維持する事がで
きる。これを行うサーバーは、どのバイト及び初期ゼロ
がどのクライエントに与えられたかを顧慮することなく
、何らかのバイト又はゼロを有しているクライエントを
記憶しておくだけで良い。

より洗練されたサーバーは、より細かな粒度でバイト及
び初期ゼロについての情報を保持する事によって、クラ
イエント間のより高い並列性をサポートできる。

第１図を参照すると、サーバー５０２のディスク５１２
上に記憶されたファイル５１３に関して、ファイルから
バイトを取得してクライエント５゜１のキャッシュ５０
３に入れるために、通信リンク５１４を介してクライエ
ントによりサーバーにｇｅｔ　　ｂｙｔｅｓ要求が送ら
れる。サーバーでのｇｅｔ　　ｂｙｔｅｓ要求の処理は
、クライエント−リスト５１６を調べる。クライエント
・リストの位置は、ファイルに関するｉノード構造を５
０４を調べる事によって、求められる。使用中の全ての
ファイルは、ｉノード構造を有している。

クライエント計算機により使用されているファイルに関
するｉノード構造は、そのファイルに関するクライエン
ト・リスト５１５の開始点へのリンク又はポインタ５０
５を含んでいる。このポインタは、最初のクライエント
・リストのエントリ５０８を指示している。これは、さ
らに、クライエント・リスト上の後続のエントリへのポ
インタ５０６を含んでいてもよい。クライエント・リス
ト上の最後のエントリは、クライエント・リスト上にそ
れ以上のエントリが存在しない事を示すヌル値をポイン
タ６０７に関して含んでいる。各エントリ５０８は、３
つの構成要素を有する。第１の構成要素５０９は、遠隔
のクライエント・ノードを識別する。第２の構成要素５
１０は、クライエントに送られ、まだ取消されていない
全バイト範囲を識別する。さらに、これに加えて、これ
らのバイト範囲の各々に関して、クライエントがその範
囲を変更する許可を与えられているか否かに関する表示
も含まれる。同様に、構成要素５１１は、クライエント
に与えられた初期ゼロの全範囲を識別する。ファイルを
使用する各遠隔クライエント毎にクライエント・リスト
上に１つのエントリ５０８が存在する。

第７Ａ図を参照すると、ｇｅｔ　　ｂｙｔｅｓ要求の処
理は、サーバーにおいてステップ７０１で始まる。ステ
ップ７０２で、クライエント・リストが調べられ、・ク
ライエント・リスト上の最初のエントリが見つけられる
。もし現在のクライエント・リストのエントリが、ｇｅ
ｔ　　ｂｙｔｅｓ要求中でバイトを要求しているのと同
口クライエントに関するものであれば、クライエント・
リスト中のこのエントリに関するそれ以上の処理は、必
要がなく、ステップ７１０が次に実行される。もしそう
でなければ、処理はステップ７０４に続き、そこで現在
のｇｅｔ　　ｂｙｔｅｓ要求の性質が調べられる。もし
要求が、バイトを変更する許可を求めるものであれば、
処理はステップ７０５に続く。もしそうでなければ、処
理はステップ７０６に続き、そこで現在のクライエント
・リストのエントリが調べられる。もしクライエント・
リストのエントリにより、そのエントリのクライエント
が、現在のｇｅｔ　　ｂｙｔｅｓ要求の範囲内で、変更
許可付きのバイト又は初期ゼロを受取っている事が示さ
れると、処理はステップ７０７に続く。

もしそうでなければ、このクライエント・リスト・エン
トリに関してはそれ以上の処理は必要でなく、処理はス
テップ７１０に続く。ステップ７０５で、現在のクライ
エント・リストのエントリが調べられ、もし要求された
バイト範囲内に、エントリのクライエントに送られ、取
消されていない何らかのバイト又は初期ゼロが存在すれ
ば、処理はステップ７０７に続く。もしそうでなければ
、このエントリに関するそれ以上の処理は、必要でなく
、処理はステップ７０７に続く。ステップ７０７で、（
ここには、クライエント・リストのエントリ中に示され
たクライエントからバイトが取消されなければならない
場合に到達する）、ｒｅｖｏｋｅｂｙｔｅｓメツセージ
が、ｇｅｔ　　ｂｙｔｅｓ要求中で要求されたバイト範
囲に対応するバイト範囲に関して現在のリスト・エント
リに示されたクライエントに送られる。処理はステップ
７０８に続き、そこでｒｅｖｏｋｅ　　ｂｙｔｅｓメツ
セージに対する応答を待機する。ステップ７０９で、ク
ライエント・リストのエントリは、バオト範囲が取消さ
れたという事実を反映するように更新される。次に処理
はステップ７１０に続く。ステップ７１０で、クライエ
ント・リストのエントリが、クライエント・リストの最
後のエントリか否かを判定するために、調べられる。も
しそうでなければ、ステップ７１１で、クライエント・
リストの次のエントリが現在のエントリになり、処理は
ステップ７０３に続く。ステップ７１０で、もし現在の
エントリがクライエント・リストの最後のエントリであ
れば、処理はステップ７１２に続き、そこで、このｇｅ
ｔ　　ｂｙｔｅｓ要求に対する応答で返される初期ゼロ
の範囲が選択される。返される初期ゼロの選択に関する
これ以上の詳細は、第７Ｂ図に見出される。処理はステ
・シブ７’１３に続き、そこで、要求を行っているクラ
イエントに関するクライエント・リスト・エントリが、
そのクライエントに送られる初期ゼロを反映するように
更新される。ステップ７１４で、このエントリは、ｇｅ
ｔ　　ｂｙｔｅｓ応答で返されるバイト範囲を反映する
ように更新され、ステップ７１５で、ｇｅｔ　　ｂｙｔ
ｅｓ応答が実際に送られる。ｇｅｔ　　ｂｙｔｅｓ要求
の処理は、ステ・シブ７１６で終る。

上記説明は、下記のプログラミング設計言語コード中に
記述されている。

ｇｅＬｂｙｔｅｓ（ｇｂ−ｃｌｉｅｎｔ、　ｇｂゴｉ　
ｌｅ、　ｇｂ−ｒａｎｇｅ、　ｇｂ−ｒｗ）−−ｇｂｊ
ｉｌｅ中の −−ｇｂ−ｒａｎｇｅバイトに関する −−ｇｂ−ｃｌｉｅｎｔからの要求 −−ｇＪｒｗ　＝＝　ｔｒｕｅ　：要求が変更のためな
らばＥＧＩＮ ＦＯＲｅｎｔｒｙ　＝　ｇｂ　ｆｉｌｅに関するクライ
エント・リスト上の最初のエントリ ＴＯクライエント・リスト上の最後のエントリＩＦエン
トリのクライエントがｇＪｃ　ｌ　ｉ　ｅｎ　ｔでない ＨＥＮ ＩＰ　（ｇｂ−ｒｗ　＝＝　ｔｒｕｅ ＡＮＤ　（エントリがｇＬｒａｎｇｅと重なるバイト範
囲を有する ＯＲ エントリがｇｂ−ｒａｎｇｅと重なる 初期ゼロを有する）） ＯＲ（ｇＪｒｗ　＝＝　ｆａｌｓｅ ＡＮＤ　（エントリがｇｌ）−ｒａｎｇｅと重なる変更
のためのバイト範囲を有する ＯＲ エントリがｇｂ、、−ｒａｎｇｅと重なる初期ゼロを有
する）） ＴＩ（ＥＮ ｇｂ−ｒａｎｇｅに関するエントリのクライエントにｒ
ｅｖｏｋｅ−ｂｙｔｅｓを送る；ｒｅｖｏｋｅＪｙＬｅ
ｓ応答を待機する；ｇｂ−ｒａｎｇｅに関するエントリ
のバイト範囲及び初期ゼロをクリアする； ＮＤＩＦ ＮＤＩＦ ＮＤＦＯＲ −全ての取消しが終了し、要求に答えるＣＡＬＬ　ｓｅ
ｌｅｃｔ−ｎａｓｃｅｎｔ−ｚｅｒｏ−ｒａｎｇｅ；ｇ
Ｊｃｌｉｅｎｔに関するクライエント・リスト・エント
リ中に選択された初期ゼロを記録する；ｇＪｃｌ　１ｅ
ｎｔに関するクライエント・リスト・エントリ中にｇＪ
ｒｗと共にｇｂ−ｒａｎｇｅバイトを記録する； 選択された初期ゼロと共に、ｇｅｔＪｙｔｅｓ要求に対
する応答を送る； ＮＤ 第７Ｂ図を参照すると、初期ゼロが選択されようとして
いるｇ、ｅｔ　　ｂｙｔｅｓ要求が、ステップ７２０で
調べられる。もしこのｇｅｔ　　ｂｙｔｅｓ要求が、変
更の許可を伴わないバイトの要求であれば、即ちバイト
の読取り専用のコピーに関するものであれば、処理はス
テップ７３０に続き、そこで、ステップ７３１でリター
ンする前に、初期ゼロが選択されなかった事が示される
。そうでない場合、もし要求が変更する許可に関するも
のであれば、ステップ７２１で、このファイルに関して
高率の取消しが必要であったか否かに関する判定が行わ
れる。もしそうであれば、処理はステップ７３０に続き
、そこで初期ゼロが選択されなかった事が決定される。

そうでなければ、高率の取消しは存在せず、処理はステ
ップ７２３に続く。

そこでディスク上の利用可能なスペースが調べられる。

もしディスク・スペースが余りにも少なければ、処理は
ステップ７３０に続き、そこで初期ゼロなしが選択され
る。そうでない場合は、ステップ７２４で、ｇｅｔ　　
ｂｙｔｅｓ要求が調べられる。ｇｅｔ　　ｂｙｔｅｓ要
求がファイルを拡張すると判定され、且つ次の１６にバ
イトが既に初期ゼロに割当てられていなければ、ステッ
プ７２７で、このｇｅｔ　　ｂｙｔｅｓ要求において返
される初期ゼロとして、次の１６にバイトが選択される
。次に、ステップ７３２で、これらの初期ゼロのために
ディスク・スペースが予約され、処理はステップ７３１
でリターンする。もしステップ７２４で、このｇｅｔ　
　ｂｙｔｅｓ要求がファイルを拡張しないと判定される
と、処理はステップ７２５に続く。ステップ７２５で、
ｇｅｔ　　ｂｙｔｅｓ要求が調べられる。もし、要求さ
れたバイトが、ファイル中の最後のプロ・ンクであって
、次の８にバイトがまだ初期ゼロとして割当てられてい
なければ、ステップ７２８で、次の８にバイトが選択さ
れ、処理はステップ７３２に続いて、そこでディスク・
スペースが予約される。もしステップ７２５で、ｇｅｔ
　　ｂｙｔｅｓ要求がファイル中の最後のブロックに関
するものではないと判定されると、処理はステップ７２
６に続く。ここでは、要求されたバイトに隣接するブロ
ックが調べられる。もし、初期ゼロとして割当てられて
いない４にの論理的にゼロのバイトが、要求されたバイ
ト範囲に隣接して見出されると、ステップ７２９で、こ
れらのバイトが選択され、ステップ７３２でディスク・
スペースが予約される。ファイル中の論理的にゼロのバ
イトが初期ゼロとして割当てられているか否かの判定は
、クライエント・リストのエントリを調べる事によって
行われる。

下記のプログラミング設計言語コードは、上記説明を表
現している。

ｓｅｌｅｃＬｎａｓｃｅｎｔ−ｚｅｒｏ−ｒａｎｇｅＯ
ＥＧＩＮ ＩＦ　ｇｂ−ｒｗ　＝＝　ｆａｌｓｅ ＯＲｇｂＪｉｌｅに関する高いｒｅｖｏｋｅ−ｂｙｔｅ
トラフィック ＯＲｇｂＪｉｌｅに関する少ないディスク・スペースＨ
ＥＮ ｓｅ　ｌｅａｎｅｄ−ｒａｎｇｅは空；ＲＥＴＵＲＮ　
； ＥＮＤＩＦ； ＩＦ　ｇＪｒａｎｇｅがｇｂＪｉｌｅに関するファイル
終端を越えている 八ＮＤ　ｇＬｒａｎｇｅを越える１６にバイトが論理的
にゼロ ＡＮＤ　ｇＬｒａｎｇｅを越える１６にバイトがｇｂｒ
ｉｌｅに関するどのクライエント・リスト− エントリ中の初期ゼロでもない １１ＥＮ ｓｅｌｅｃｔｅ＋Ｌｒａｎｇｅはｇｂ−ｒａｎｇｅを越
えた１６ＫＬＳＥ ＩＦ　ｇＬｒａｎｇｅがｇｂＪｉｌｅのファイル終端で
終了する ＡＮＤ　ｇｂ−ｒａｎｇｅから先の８にバイトが論理的
にゼロ ＡＮＤ　ｇｂ−ｒａｎｇｅから先の８にバイトがｇｂＪ
ｉｌｅに関するどのクライエント・リスト ・エントリ中の初期ゼロでもない ＩＩＥＮ ｓｅｌｅｃｔｅｃＬｒａｎｇｅはｇｂ−ｒａｎｇｅを越
えた８ＫＬＳＥ ＩＦ　ｇｂ−ｒａｎｇｅが、論理的にゼロで且つｇｂＪ
ｉｌｅに関するどのクライエント・リスト・エントリ中
の初期ゼロでも ない４にのブロックに隣接している ＨＥＮ ｓｅ　１ｅｃｔｄ、−ｒａｎｇｅはその４にのブロック
；ＬＳＥ ｓｅｌｅｃｔｅｄ−ｒａｎｇｅは空； ＲＥＴＵＲＮ　； ＥＮＤＩＦ ＥＮＤＩＦ ＥＮＤＩＦ ｓｅｌｅｃｔｅｄ−ｒａｎｇｅのためにディスク°スペ
ースを予約する： ＲＥＴＵＲＮ ＮＤ もしクライエント計算機上のプロセスが、ファイルのサ
ーバーから以前に要求されていなかったファイル中のバ
イトにアクセスする必要がある場合、それは、そのファ
イルに関してサーバーから受取った初期ゼロのどれかを
使用しうる。クライエントにおける初期ゼロへの記憶又
は書込みは、それを変更された実バイトにし、最終的に
は、変更されたバイトが返されるようにｐｕｔ　　ｂｙ
ｔｅｓメツセージでサーバーに返される。サーバーは、
要求された範囲内の全ての変更されたバイトを（本来、
実バイトであったもの及び初期ゼロであったものの両方
を）、クライエントが送り返すように強制するために、
ｒｅｖｏｋｅ　　ｂｙｔｅＳを使う事ができる。その範
囲内の未変更の実バイト及び初期ゼロは、単にクライエ
ントによって廃棄される。もし初期ゼロが再び使用され
るならば、それらは再取得されなければならない。

初期ゼロは、既にサーバーにおいてディスクを予約して
おり、サーバーに知らせる事なくクライエントによりフ
ァイルに安全に付は加える事ができる。サーバーでは、
ディスクの予約は、クライエントがサーバーのディスク
・スペースをオーバーコミットしないようにしている。

予約されたディスク・ブロックは、サーバーにバイトが
返された場合にのみ、ディスクの一部になる。もし初期
ゼロがクライエントにより使用されなければ、それらは
サーバーに返されず、ディスクの予約は最終的には再利
用される。

クライエントは、ファイル・サーバーがそれらに送った
初期ゼロを追跡する必要はない。単純なりライエン、ト
の実施形態では、初期ゼロを無視して、依然として正し
く動作できる。それは、これらのゼロを決して使用せず
、従ってそれらをサーバーに返さない。そのようなりラ
イエンドは、たとえ新しいブロックがファイル終端を越
えている場合であっても、それに書込みを行う前にバイ
トのブロックを要求しなければならず、初期ゼロを利用
するタライ・エンドのように効率的には新しいファイル
に付加又は書込みを行わない。

クライエントがファイルをクローズする時、サーバーは
、ｃｌｏｓｅメツセージ４１０で通知される。ｃｌｏｓ
ｅメツセージを送る前に、クライエントは、そのファイ
ルに関する全ての変更されたデータをサーバーに送る義
務がある。クライエントは、これを、ｐｕｔ　　ｂｙｔ
ｅｓメツセージ４６０で行う。ｃｌｏｓｅ要求を受取る
と、サーバーは、そのファイルに関するクライエント・
リストからそのクライエントを除去でき、そのクライエ
ントに関して記録されていた初期ゼロ用の予約済ディス
ク・スペースを回復する。サーバーは、ｒｅｖｏｋｅ　
　ｂｙｔｅｓメツセージを用いて取消す事により、初期
ゼロに関して予約されていたディスク・スペースを回復
する事もできる。サーバーは、ディスク・スペースに関
する需要が、初期ゼロの予約に関する勘定の後で利用可
能なレベルを越える時、これを行うように選択してもよ
い。

取消された初期ゼロを有するクライエントは、取消され
た範囲内のバイトを使う時の余分のｇｅｔｂｙｔｅｓメ
ツセージという性能上のペナルティを被る。

Ｆ０発明の効果 本発明によれば、分散データ処理システムにおいてファ
イルに書込みを行う際のネットワーク・トラフィックを
減少させる事ができる。

【図面の簡単な説明】

第１図は本発明の分散データ処理システム中のクライエ
ント・データ処理システムとサーバー・データ処理シス
テムを示す図、 第２図ははシステム・コールを通じてファイルにアクセ
スする事に関して従来技術のスタンドアローンのデータ
処理システムを示すブロック図、第３図はシステム・コ
ールを通じてファイルにアクセスする第２図のデータ処
理システムの流れ図、 第４Ａ〜４１は種々のメ・ンセージのデータ構造を示す
図、 第５図は従来技術で知られている分散データ処理システ
ムのブロック図、 第６図はサーバーと２つのクライエントとの間のノード
間のメツセージの流れを示す図、第７Ａ図はサーバーに
おけるｇｅｔ　　ｂｙｔｅＳ要求の動作を示す流れ図、 Ｍ７　Ｂｌｌはファイル内のバイトへのアクセスに関す
る要求に応答してクライエントに送られる初期ゼロの選
択を説明する流れ図である。 第２図 。、。５Ｅづ一４゛０ 要求 １１１４Ａ口 ｌ１１４日図 ＰＵＴ　　日ＹＴＥＳ 要求 ＲＥＶＯＫＥ　８ＹＴＥＳ−−”” 要求 １１１４０図

Claims (19)

【特許請求の範囲】
1. （１）サーバー・データ処理システム及び少なくとも１
   つのクライエント・データ処理システムが通信手段を介
   して接続され、上記サーバー・データ処理システムに存
   在するファイル中の所定のバイト範囲に、上記少なくと
   も１つのクライエント・データ処理システムからアクセ
   スするための、上記サーバー・データ処理システムにお
   ける方法であって、 上記サーバー・データ処理システムにより実行される動
   作に関する上記少なくとも１つのクライエント・データ
   処理システムの１つからの要求に応答して、上記サーバ
   ー・データ処理システムによって決定されるとおりに、
   上記ファイル内の現在不使用のバイトの範囲の記述を返
   すステップと、上記クライエント・データ処理システム
   に、上記記述されたバイト範囲を使用する許可を認める
   ステップとを含む方法。
2. （２）上記記述された範囲を使用する許可を認める前に
   、上記サーバー・データ処理システムにおいて物理的記
   憶空間を予約するステップを含む請求項１に記載の方法
   。
3. （３）上記クライエント・データ処理システムがファイ
   ルをクローズする時に上記記述されたバイト範囲に上記
   クライエント・データ処理システムによる書込みが行わ
   れたか否かを判定し、クライエント・データ処理システ
   ムが上記記述されたバイト範囲に書込みを行っていなけ
   れば上記予約された物理的記憶空間を解放するステップ
   を含む請求項２に記載の方法。
4. （４）上記少なくとも１つのクライエント・データ処理
   システムの１つからの要求が、上記ファイル内の要求さ
   れたバイト範囲への書込みアクセスを得る動作に関する
   ものである請求項１に記載の方法。
5. （５）上記記述された範囲の認められた使用が、書込み
   に関するものである請求項４に記載の方法。
6. （６）上記サーバー・データ処理システムにより、上記
   記述されたバイト範囲を使用する許可を取消すステップ
   を含む請求項１に記載の方法。
7. （７）サーバー・データ処理システム及び少なくとも１
   つのクライエント・データ処理システムが通信手段を介
   して接続され、上記サーバー・データ処理システムに存
   在するファイル中の所定のバイト範囲に、上記少なくと
   も１つのクライエント・データ処理システムからアクセ
   スするための、上記サーバー・データ処理システムにお
   ける方法であって、 上記バイト範囲に対する書込みアクセスに関する上記少
   なくとも１つのクライエント・データ処理システムの１
   つからの要求に応答して、上記要求されたバイト範囲を
   用いて上記サーバー・データ処理システムにより決定さ
   れる論理的にゼロのバイトの付加的な範囲の記述を返す
   事により、上記クライエント・データ処理システムに、
   要求されたよりも大きなバイト範囲に書込む許可を与え
   るステップと、 上記クライエント・データ処理システムが上記付加的な
   バイト範囲に書込む許可を有している間、上記付加的な
   バイト範囲に関して上記サーバー・データ処理システム
   において物理的記憶空間を予約するステップとを含む方
   法。
8. （８）サーバー・データ処理システム及び少なくとも１
   つのクライエント・データ処理システムが通信手段を介
   して接続され、上記サーバー・データ処理システムに存
   在するファイル中の所定のバイト範囲に、上記少なくと
   も１つのクライエント・データ処理システムからアクセ
   スするための、上記サーバー・データ処理システムにお
   ける方法であって、 上記バイト範囲に対する書込みアクセスに関する上記ク
   ライエント・データ処理システムの１つからの要求に応
   答して、上記要求されたバイト範囲を用いて上記サーバ
   ー・データ処理システムにより決定される、未書込みの
   ゼロのバイトの、要求されない付加的な範囲の記述を返
   す事により、上記クライエント・データ処理システムに
   、要求されたよりも大きなバイト範囲に書込む許可を与
   えるステップと、 上記クライエント・データ処理システムから上記ファイ
   ルへのアクセスを、上記サーバー・データ処理システム
   により、制御するために、上記クライエント・データ処
   理システムにより要求されたバイト範囲及び上記要求さ
   れない付加的なバイト範囲に書込む許可を取消すステッ
   プとを含む方法。
9. （９）サーバー・データ処理システム及び少なくとも１
   つのクライエント・データ処理システムが通信手段を介
   して接続され、上記サーバー・データ処理システムに存
   在するファイル中の所定のバイト範囲に、上記少なくと
   も１つのクライエント・データ処理システムからアクセ
   スするための、上記サーバー・データ処理システムにお
   ける、方法であって、上記ファイルの最後のブロックを
   表わすバイト範囲に対する書込みアクセスに関する上記
   クライエント・データ処理システムの１つからの要求に
   応答して、上記要求されたバイト範囲を用いて上記サー
   バー・データ処理システムにより決定される、未書込み
   のゼロのバイトの、要求されない付加的なブロックの記
   述を少なくとも１つ返す事により、上記クライエント・
   データ処理システムに、要求されたよりも大きなバイト
   範囲に書込む許可を与えるステップと、 上記クライエント・データ処理システムが、上記ファイ
   ルの上記要求された最後のブロック及び上記少なくとも
   １つの要求されなかった付加的なブロックに書込んだ後
   に、上記ファイルの次のバイトのブロックに対する次の
   要求を受け取る事により、上記クライエント・データ処
   理システムから新しいバイトのブロックが要求される回
   数を最小限にするステップとを含む方法。
10. （１０）通信手段により接続された複数のデータ処理シ
    ステムを有する分散データ処理システムにおいて、上記
    データ処理システムの第１のものに存在するファイル中
    のバイト範囲であって少なくとも１つの第２のデータ処
    理システムにより要求されるものにアクセスするための
    方法であって、上記第２のデータ処理システムから要求
    されたバイト範囲を、上記第１のデータ処理システムか
    ら返すステップと、 上記返される要求されたバイト範囲と共に、付加的な未
    書込みのゼロ・バイトの範囲が返されるか否かを上記第
    １のデータ処理システムで判定して、選択的に上記付加
    的な範囲を返すステップと、上記第２のデータ処理シス
    テムが上記付加的な未書込みのゼロ・バイトの範囲を認
    識し且つ上記第２のデータ処理システムが上記付加的な
    未書込みのゼロ・バイトの範囲に書込みを行う事を選択
    する場合、上記第２のデータ処理システムにより上記返
    された付加的な未書込みのゼロ・バイトの範囲に書込み
    を行うステップとを含む方法。
11. （１１）通信手段により接続された複数のデータ処理シ
    ステムの少なくとも第１のもので使用するための装置で
    あって、 上記第１のデータ処理システムによりファイルに対して
    実行される動作に関する上記データ処理システムの第２
    のものからの要求に応答して、上記第１のデータ処理シ
    ステムにより決定される、上記ファイル内の現在不使用
    のバイトの範囲の記述を返す手段と、 上記第２のデータ処理システムに、上記記述されたバイ
    トの範囲を使用する許可を認める手段とを含む装置。
12. （１２）上記記述された範囲を使用する許可を認める前
    に、上記第１のデータ処理システムにおいて物理的記憶
    空間を予約する手段を含む請求項１１に記載の装置。
13. （１３）上記第２のデータ処理システムが上記ファイル
    をクローズする時に上記第２のデータ処理システムが上
    記記述されたバイト範囲に書込みを行ったか否かを上記
    第１のデータ処理システムにより判定する手段と、上記
    第２のデータ処理システムが上記記述されたバイト範囲
    に書込みを行っていない場合、上記予約された物理的記
    憶空間を解放する手段とを含む請求項１２に記載の装置
    。
14. （１４）上記第２のデータ処理システムからの要求が、
    上記ファイル内の要求されたバイト範囲への書込みアク
    セスを得る動作に関するものである請求項１１に記載の
    装置。
15. （１５）上記記述された範囲の、認められた使用が、書
    込みに関するものである請求項１４に記載の装置。
16. （１６）上記第１のデータ処理システムにより、上記記
    述されたバイト範囲を使用する許可を取消す手段を有す
    る請求項１１に記載の装置。
17. （１７）通信リンクにより接続された複数のデータ処理
    システムの少なくとも第１のもので使用するための装置
    であって、 第１のバイト範囲への書込み許可アクセスに関する上記
    第２のデータ処理システムからの要求に応答して、上記
    第１のデータ処理システムにより決定される、未書込み
    のゼロ・バイトの付加的な範囲を、上記要求された第１
    のバイト範囲と共に返す手段と、 上記第２のデータ処理システムによるファイルへのアク
    セスを上記第１のデータ処理システムにより制御するた
    めに、上記第２のデータ処理システムによって上記要求
    されたバイト範囲及び上記付加的なバイト範囲への書込
    みの許可を取消す手段とを含む装置。
18. （１８）通信手段により接続された複数のデータ処理シ
    ステムで使用するためのコンピュータ・プログラム製品
    であって、 第２のデータ処理システムから要求されたバイト範囲を
    、第１のデータ処理システムから返す手段と、 上記第１のデータ処理システムにおける決定により、上
    記返される要求されたバイト範囲と共に、付加的な未書
    込みのゼロ・バイトの範囲を選択的に返す手段と、 上記第２のデータ処理システムが上記付加的な未書込み
    のゼロ・バイトの範囲を認識し、且つ上記第２のデータ
    処理システムが上記付加的な未書込みのゼロ・バイトの
    範囲に書込む事を選択する場合に、上記第２のデータ処
    理システムにより上記返された付加的な未書込みのゼロ
    ・バイトの範囲に書込みを行う手段とを含む装置。
19. （１９）第１のデータ処理システムに存在するファイル
    中のバイト範囲に第２のデータ処理システムからアクセ
    スする手段を含み、上記第１のデータ処理システムと上
    記第２のデータ処理システムとが通信手段によって接続
    されたシステムであって、上記ファイルに対して上記第
    １のデータ処理システムによって実行される動作に関す
    る上記第２のデータ処理システムからの要求に応答して
    、上記第１のデータ処理システムにより決定される、フ
    ァイル内の現在不使用のバイトの範囲の記述を返す手段
    と、 上記記述されたバイト範囲を使用する許可を上記第２の
    データ処理システムに認める手段とを含むシステム。