JP2000322306A - ノード間共用ファイル制御方式 - Google Patents

Abstract

(57)【要約】 【課題】 トークンによるノード間共用ファイルシステ
ムにおいて、ファイルアクセスに伴うオーバヘッドの増
大とシステム性能の低下を抑制し、二重化サーバシステ
ムでのサーバ切替え時のファイル時刻の逆転を防止する
ことにある。 【解決手段】 クライアント部１０２からサーバ部１０
３へのトークンの要求時に、１０３は、複数の１０２間
で競合が無ければ、１０３から１０２へファイル全体の
トークンを応答する。１０２は、ファイルの最終ブロッ
クへのアクセス時のみ、１０３からそのファイルに対応
するサイズトークンを獲得した上でその最終ブロックに
アクセスする。１０３は、ファイル時刻の変更を許容す
るwrite 権の時刻トークンを複数の１０２に同時に応答
できる。１０２は、write 権の時刻トークンを獲得した
後は、１０３にファイル時刻を問い合わせることなく、
ファイルアクセスを実行する。１０３は、所定のタイミ
ングで、１０２からwrite 権の時刻トークンを回収し、
自身が管理するファイル時刻を更新する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、複数のノード（ホ
ストコンピュータ）から同一のファイルを共用すること
を可能とするノード間共用ファイルシステム（分散ファ
イルシステム）のコンシステンシ保証制御技術に関す
る。

【０００２】

【従来の技術】分散ファイルシステムにおいて、トーク
ンを利用して複数のノード上にキャッシュされているデ
ータのコンシステンシ（一貫性、整合性）を保つ方式は
良く知られている。代表的な方式では、ファイルのアク
セス範囲（通常、ブロック番号の始端と終端が用いられ
る）ごとにmultiple-read/single-writeの制御を行うト
ークンが用意される。そして、ファイルにアクセスしよ
うとするノードは、自身がアクセス範囲のトークンを保
持しているか否かを調べ、もし保持していなければトー
クンを管理しているサーバにトークンを要求する。トー
クンを管理しているサーバは、read権は複数のノードに
渡されることを許し（multiple-read ）、write 権は１
つのノードのみに渡されるように（single-write）、ア
クセス権制御を実行する。

【０００３】

【発明が解決しようとする課題】上述の従来方式は、各
ノードにキャッシュされているデータの一貫性を保ちつ
つサーバとクライアントの間の通信を減らすために有効
な方式であるが、以下の問題点を有する。 １）ファイルアクセスの都度にトークンを獲得する必要
がある。例えば、科学技術計算のための巨大なファイル
をユーザがシーケンシャルにアクセスする場合、ユーザ
は、特定バイトずつのファイルアクセス要求を出す都度
に、サーバにトークンを獲得するための要求を発行せざ
るを得ない。この事実は、オーバヘッドの増大を招く。 ２）ファイルが最後にアクセスされた時刻を保持するフ
ァイルアクセス時刻（ファイル時刻）の正当性を保証す
るために、ユーザはファイルアクセス要求を発行する都
度にサーバにそのアクセスの存在を通知せざるを得な
い。この事実は、オーバヘッドの増大を招く。 ３）ユーザはファイルサイズを更新するときにはその旨
をサーバに通知し、サーバは他ノードに発行されている
全てのトークンを回収しなければならない。このため、
例えばファイルを拡張するプログラムとファイルをその
先頭から順に読むプログラムをそれぞれ異なるノードで
同時に実行させることができず、システム全体の性能が
低下するといった問題が生ずる。 ４）サーバが二重化され、障害発生時に運用サーバが待
機系サーバに切り替えられる機能を有するシステムにお
いて、待機系サーバへの切替えの時点でいままで運用さ
れてきた時計も待機系のサーバ内の時計に切り替えられ
るため、ファイル時刻の逆転現象が発生する可能性があ
る。この事実は、データのコンシステンシの喪失を招
く。 ５）メインフレームで採用されるような、ディスクがノ
ード間で直接共用されネットワークを介したデータ転送
が削減される方式を、離散ファイルを特徴とするオープ
ン系のファイルシステムに適用しようとした場合に、各
ノードはファイルシステム上でブロックを割り当てる都
度にサーバと通信する必要が生ずる。この事実は、オー
バヘッドの増大を招く。 一方、トークンを利用した分散ファイルシステムにおい
ては、複数のノードが同時並行的なアクセスを行うた
め、ファイルシステムの耐故障性に関しても十分な配慮
が必要である。一般に、ファイルシステムの耐故障性を
向上させる方式として、ログファイルを設けてメタデー
タの更新をトランザクショナルに行うログ方式が知られ
ている。ログ方式では一般に、１つのトランザクション
の処理途中結果を他のトランザクションに見せてはなら
ないという制約のために、いわゆる２フェーズロック制
御が行われる。この制御では、更新に必要なロックが順
に獲得されてゆき、全ての更新が完了した時点で一括し
て、メタデータの更新内容がログファイルロックに書き
出され、書出しが完了した時点でロックが一括して返却
される。この際に必然的に発生する複数のロック獲得に
伴うデッドロックは、資源獲得を示す有向グラフを用い
て自動的に検出され、デッドロックの原因となっている
一方のトランザクションがキャンセルされ、再試行させ
られることにより解消される方式が、一般的に用いられ
る。

【０００４】しかし、上述のようなログ方式をトークン
システムに適用してデッドロックを自動的に検出し回復
を図る汎用的な方式は考え出されていない。また、従来
のログ方式では、ログがキャッシュブロック単位に採取
されると共に、トランザクション終了時にファイルシス
テムの実更新が発生するため、Ｉ／Ｏ量が相対的に多く
なるという欠陥があった。

【０００５】また上記ログ方式では、トランザクション
のキャンセル時のデータ復元処理がメタデータのみに限
られ、性能向上のために用意きれたメモリに常駐する制
御表は対象外であるため、プログラム作成が難しいとい
う欠陥も持っていた。

【０００６】本発明の課題は、トークンを用いたノード
間共用ファイルシステムにおいて、上述の各問題点を解
決することにあり、ファイルアクセスに伴うオーバヘッ
ドの増大とシステム性能の低下を抑制すると共に、二重
化サーバシステムにおけるサーバ切替え時のファイル時
刻の逆転を防止し、更にメタデータの更新をコンシステ
ントにかつデッドロックフリーで行なうことにより従来
のログ方式の性能上及びプログラム作成上の問題点を解
決することにある。

【０００７】

【課題を解決するための手段】本発明は、ユーザプログ
ラムからのファイル操作要求を受けて、１つのノード内
のクライアント装置がそれと同一の又は他のノード内の
サーバ装置からトークンを獲得した上でそのファイル操
作要求を処理することにより、複数のノードからの同一
ファイルの共用を可能とするノード間共用ファイル制御
システムを前提とする。

【０００８】本発明の第１の態様は、以下の構成を有す
る。まず、クライアント装置からサーバ装置へのトーク
ンの要求時に、サーバ装置において複数のクライアント
装置間でのそのトークンの競合の有無が判定される。

【０００９】そして、その競合が無ければ、サーバ装置
からクライアント装置へファイル全体のトークンが応答
される。以上の構成を有する本発明の第１の態様の構成
では、例えばopen要求時等においてファイル全体のトー
クンが引き渡されることにより、可能な限り新たなトー
クン要求を行わずにファイルへの連続アクセスが可能と
なる。データベースアクセス等を除く一般的なファイル
アクセスでは、１つのノードからのwrite 要求の発行時
に他のノードからread命令が発行される確率は小さい。
従って、１つのノードに引き渡されたファイル全体のト
ークンが回収される確率も低く、ファイルへの連続アク
セス時にアクセス単位ごとにトークン要求が不要になる
ことによる性能向上が期待できる。

【００１０】本発明の第２の態様は、以下の構成を有す
る。まず、クライアント装置とサーバ装置の間で、ファ
イル時刻を制御するための時刻トークンが通信される。

【００１１】また、サーバ装置において、ファイル時刻
の変更を許容するwrite 権の時刻トークンを複数のクラ
イアント装置に同時に応答する制御が実行される。ま
た、クライアント装置において、write 権の時刻トーク
ンが獲得された後は、サーバ装置にファイル時刻を問い
合わせることなく、ファイルアクセスが実行される。

【００１２】また、サーバ装置において、所定のタイミ
ングでクライアント装置からwrite権の時刻トークンが
回収され、自身が管理するファイル時刻が更新される。
以上の構成を有する本発明の第２の態様の構成では、ク
ライアント装置は、ユーザプログラムが１つのファイル
に連続アクセスするような場合において、そのファイル
への最終的なアクセスが終了するまでwrite 権の時刻ト
ークンを返却する必要もまたアクセスの有無をサーバ部
に通知する必要もなく、他のノードとの間でそのファイ
ルのファイル時刻の同期をとる必要がなくなる。このた
め、システム全体の性能を向上させることが可能とな
る。

【００１３】本発明の第３の態様は、以下の構成を有す
る。まず、クライアント装置とサーバ装置の間で、ファ
イルサイズの拡張を制御するためのサイズトークンが通
信される。

【００１４】そして、クライアント装置において、ファ
イルの最終ブロックにアクセスする場合においてのみ、
サーバ装置からそのファイルに対応するサイズトークン
が獲得された上でその最終ブロックにアクセスされる。

【００１５】以上の構成を有する本発明の第３の態様の
構成では、ファイルの最終ブロックにアクセスするので
なければ、サイズトークンを獲得することなくファイル
にアクセスすることが可能となり、これと並行して、他
のノードは、サイズトークンを獲得してファイルの最終
ブロックにアクセスし、ファイルのサイズを拡張するwr
ite 操作処理を実行することができる。このため、例え
ばファイルを拡張するプログラムとファイルをその先頭
から順に読むプログラムをそれぞれ異なるノードで同時
に実行させることが可能となり、システム全体の性能を
向上させることができる。

【００１６】本発明の第４の態様は、以下の構成を有す
る。まず、クライアント装置とサーバ装置の間で、ファ
イルデータのアクセスを制御するためのデータトークン
が通信される。

【００１７】そして、そのデータトークンの通信時に、
そのデータトークンに対応するファイルのディスク上で
の位置を示すエクステント情報が通信される。以上の構
成を有する本発明の第４の態様の構成では、複数のノー
ドは、ディスク装置内のファイルに、ＬＡＮ経由ではな
く直結された制御・データ線を介してアクセスすること
が可能となる。

【００１８】本発明の第５の態様は、上述した本発明の
第１乃至第４のいずれかの態様の構成を前提として、さ
らにサーバ装置が二重化される構成を前提とし、以下の
構成を有する。

【００１９】まず、主系のサーバ装置においてファイル
時刻が設定される際に、そのファイル時刻が従系のサー
バ装置に送信される。そして、その従系のサーバ装置に
おいて、そのファイル時刻が設定される。

【００２０】以上の構成を有する本発明の第５の態様の
構成では、サーバ切替時にも、矛盾のないファイル時刻
の付与が可能となる。本発明の第６の態様は、以下の構
成を有する。

【００２１】まず、サーバ装置において、複数のノード
から共用される１つ以上のディスクボリューム毎に、空
きディスク領域群、使用中ディスク領域群、及び各クラ
イアント装置に対応するリザーブ中ディスク領域群が管
理される。このとき、空きディスク領域群の管理が、デ
ィスク領域の複数のサイズ範囲毎に行われるように構成
することができる。

【００２２】次に、クライアント装置において、サーバ
装置に対して、ディスク領域のリザーブが要求される。
このとき、クライアント装置において、それが管理する
リザーブ中ディスク領域群中のディスク領域が所定量を
下回ったときに、サーバ装置に対して、新たなディスク
領域のリザーブ要求が発行されるように構成することが
できる。

【００２３】次に、そのリザーブ要求に対して、サーバ
装置において、空きディスク領域群からディスク領域が
リザーブ中ディスク領域として確保され、それに関する
情報がそのリザーブ要求を発行したクライアント装置に
通知されると共に、その確保されたリザーブ中ディスク
領域がリザーブ要求を発行したクライアント装置に対応
するリザーブ中ディスク領域群として管理される。

【００２４】続いて、リザーブ要求を発行したクライア
ント装置において、そのリザーブ要求に応答してサーバ
装置から通知された情報に対応するリザーブ中ディスク
領域がリザーブ中ディスク領域群として管理される。こ
のとき、クライアント装置において、リザーブ中ディス
ク領域群の管理が、ディスク領域の複数のサイズ範囲毎
に行われるように構成することができる。

【００２５】更に、クライアント装置において、ユーザ
プログラムによるファイルへのデータ書出し要求に伴っ
て新たなディスク領域を割り当てる必要が発生した場合
に、そのクライアント装置が管理するリザーブ中ディス
ク領域群から最適なリザーブ中ディスク領域が選択さ
れ、そこに対してデータ書出しが実行され、そのリザー
ブ中ディスク領域がリザーブ中ディスク領域群としての
管理からはずされ、そのデータ書出しを実行したリザー
ブ中ディスク領域に関する情報がサーバ装置に通知され
る。この通知は、ユーザプログラムがファイルをクロー
ズし、又はキャッシュが一杯になり、或いはサーバ装置
からデータトークンの回収を要求されるタイミングで行
うように構成することができる。このとき、ユーザプロ
グラムによるファイルへのデータ書出し要求に基づいて
書き出されるデータが、主記憶上にキャッシュされ、リ
ザーブ中ディスク領域の割り当てが遅延させられるよう
に構成することができる。

【００２６】そして、サーバ装置において、クライアン
ト装置から通知された情報に対応するデータ書出しが発
生したリザーブ中ディスク領域が、その通知を行ったク
ライアント装置に対応するリザーブ中ディスク領域群と
しての管理からはずされて使用中ディスク領域として管
理される。

【００２７】上述の本発明の第６の態様の構成におい
て、クライアント装置において、ユーザプログラムによ
るファイルへのデータ書出し要求に伴って新たなディス
ク領域を割り当てる必要が発生した場合に、そのクライ
アント装置が管理するリザーブ中ディスク領域群からフ
ァイルへのデータ書出しが既に行われているディスク領
域に連続するリザーブ中ディスク領域が選択され、その
選択に失敗した場合には、サーバ装置に対して、その連
続するリザーブ中ディスク領域のリザーブ要求が発行さ
れるように構成することができる。

【００２８】また、サーバ装置において、クライアント
装置の障害が監視され、その結果障害が検出されたクラ
イアント装置に対応するリザーブ中ディスク領域群が、
全て空きディスク領域群に変更されるように構成するこ
とができる。

【００２９】以上の構成を有する本発明の第６の態様の
構成では、クライアント装置は、サーバ装置に問い合わ
せることなく、新たなディスク領域をファイルに割り当
てることが可能となる。このため、クライアント装置と
サーバ装置との間の通信回数を削減でき、システム全体
の性能を向上させることが可能となる。また、新たに割
り当てられたディスク領域は、データが書き込まれた後
のクライアント装置からサーバ装置への応答によって初
めて、そのファイルのメタデータ等として記憶される。
このため、悪意をもってデータを覗くことを防止するこ
とが可能となる。

【００３０】本発明の第７の構成は、サーバ装置におい
て、クライアント装置からのトークン回収完了メッセー
ジの受信時に、そのメッセージに対応するトークン回収
の契機となった要求を処理している実行単位が保持して
いたファイルロックを継承して処理を実行することによ
りデッドロックを回避する過程を含むように構成され
る。この場合に、ロックの継承を行える実行単位を１つ
に制限する過程を更に含むように構成することができ
る。

【００３１】上述した本発明の第７の構成によれば、ト
ークン制御において、デッドロックの発生を回避するこ
とのできる効率的なファイルロック制御が実現される。
本発明の第８の構成は、本発明の第７の構成において、
トークン回収の待ち状態を資源として記憶し、他の資源
の獲得待ち状態との関係から、デッドロック状態を自動
的に検出する過程を更に含むように構成される。

【００３２】上述した本発明の第８の構成によれば、ト
ークンに基づいてトランザクション制御されているメタ
データ等の更新処理におけるデッドロックの発生を適切
に検出することができる。

【００３３】本発明の第９の構成は、本発明の第８の構
成において、デッドロック状態が検出されその状態の原
因となっているトランザクションがキャンセルさせられ
る際に、更新されたキャッシュデータの無効化と共に、
主記憶装置に常駐されている関連制御表の再設定を行う
過程を更に含むように構成される。

【００３４】上述した本発明の第９の構成によれば、ト
ランザクションのキャンセルに伴う常駐制御表の高速な
リストアが実現される。本発明の第１０の構成は、本発
明の第７の構成を前提として、デッドロック状態の発生
に備え、ファイル又はディスクに関する属性情報を保持
するメタデータの更新をキャッシュ上でのみ行い、ディ
スクへの書き込みが、要求された処理の完了まで遅延さ
せられるトランザクション制御において、キャッシュデ
ータの更新時に更新されたキャッシュ位置を記録する過
程と、トランザクションの完了時に、前記記録から必要
最小限の変更データのみをログファイルに書き出すこと
によりログデータ量を削減する過程とを含むように構成
される。ここで、更新されたキャッシュ位置を記録する
際に、その記録と先行する記録とをマージすることによ
り、ログファイルに書き出すログデータ量を最小化する
過程を更に含むように構成することができる。

【００３５】上述した本発明の第１０の構成によれば、
ログファイルに書き出されるログデータ量の削減が実現
される。本発明の第１１の構成は、本発明の第１０の構
成において、キャッシュが２次キャッシュを含むように
構成される。

【００３６】上述した本発明の第１１の構成によれば、
ログファイルを実ディスク上に書き出すログフラッシュ
処理を、実行中のトランザクションと独立して行うこと
が可能となり、システム性能の向上が実現される。

【００３７】

【発明の実施の形態】以下、本発明の実施の形態につい
て詳細に説明する。図１は、本発明の実施の形態の構成
を示すブロック構成図である。

【００３８】＃１〜＃３の各ノード１０１は、ファイル
１０５が格納されているディスク装置と直結され、また
ローカルエリアネットワーク（ＬＡＮ）１０６によって
相互に接続される。

【００３９】ファイル１０５を共用する複数のノード１
０１（図中では、＃１〜＃３）の全てにクライアント部
１０２、そのうちの２つのノード１０１（図中では、＃
１と＃２）にサーバ部１０３が存在する。

【００４０】一方のノード１０１（＃１）内のサーバ部
１０３（＃１）は主サーバ、他方のノード１０１（＃
２）のサーバ部１０３（＃２）は従サーバと呼ばれる。
それぞれのノード１０１内のクライアント部１０２は、
主サーバであるノード１０１（＃１）内のサーバ部１０
３（＃１）とのみ通信することにより、ファイル操作処
理を実行する。

【００４１】主サーバであるサーバ部１０３（＃１）
は、任意のクライアント部１０２からの要求（依頼）を
処理して、その処理結果を、自身が保持するメタデータ
１０４（＃１）に反映させる。従サーバであるノード１
０１（＃２）内のサーバ部１０３（＃２）が存在すると
きには、主サーバであるサーバ部１０３（＃１）は、メ
タデータ１０４（＃１）の更新内容（差分）をサーバ部
１０３（＃２）にも送る。従サーバであるサーバ部１０
３（＃２）は、送られてきたデータをノード１０１（＃
２）内のメタデータ１０４（＃２）に反映させる。

【００４２】任意のノード１０１内のクライアント部１
０２は、図２に示されるように、そのノード１０１内の
オペレーティングシステム（ＯＳ）２０１内に存在し、
そのノード１０１内のユーザプログラム２０２からのフ
ァイル操作要求を、主サーバであるノード１０１（＃
１）内のサーバ部１０３（＃１）の助けを借りて処理す
る。＃１又は＃２のノード１０１内のサーバ部１０３
は、そのノード１０１内のオペレーティングシステム２
０１に組み込んでもよいし、ユーザデーモンプログラム
としてオペレーティングシステム２０１の外に実装して
もよい。このサーバ部１０３は、複数のノード１０１上
のクライアント部１０２からのファイル操作要求を、Ｌ
ＡＮ１０６（図１参照）を介して受け付ける。

【００４３】上述の構成のもとでクライアント部１０２
とサーバ部１０３がファイル操作制御を実行する場合、
本実施の形態では、下記のトークンが用いられる。 １）ファイル１０５ごとに複数種類（例えば４種類）の
トークンが用意され、その中に、ファイルサイズの拡張
を制御しmultiple-read/single-write特性を有するサイ
ズトークンが含めさせられる。 ２）ファイル１０５ごとに複数種類（例えば４種類）の
トークンが用意され、その中に、ファイル時刻を制御し
multiple-write/multiple-read特性を有する時刻トーク
ンが含めさせられる。１つのノード１０１は、１つのフ
ァイル１０５について、read権の時刻トークンとwrite
権の時刻トークンを同時に取得できる。ただし、或るノ
ード１０１内のクライアント部１０２がサーバ部１０３
に或るファイル１０５についてのread権の時刻トークン
を要求したときに、他のノード１０１内のクライアント
部１０２がそのファイル１０５についてのwrite 権の時
刻トークンを持っていた場合には、サーバ部１０３は、
その、他のノード１０１内の時刻トークンを回収する。
また逆に、或るノード１０１内のクライアント部１０２
がサーバ部１０３に或るファイル１０５についてのwrit
e 権の時刻トークンを要求したときに、他のノード１０
１内のクライアント部１０２がそのファイル１０５につ
いてのread権の時刻トークンを持っていた場合も、サー
バ部１０３は、その、他のノード１０１内の時刻トーク
ンを取り上げる。すなわち、１つのファイル１０５につ
いては、複数のノードがそれぞれ、そのファイル１０５
についてのread権の時刻トークンとwrite 権の時刻トー
クンを同時に保有するということはない。 ３）ファイル１０５ごとに複数種類（例えば４種類）の
トークンが用意され、その中に、ファイルサイズの縮小
を制御しmultiple-read/single-write特性を有する属性
トークンが含めさせられる。 ４）ファイル１０５ごとに複数種類（例えば４種類）の
トークンが用意され、その中に、ファイル内データのア
クセス権を制御しファイル１０５を構成するブロックご
とに存在するmultiple-read/single-write特性を有する
データトークンが含めさせられる。また、本実施の形態
は、下記の基本的動作を実行する。 ５）各トークンは、サーバ部１０３によって管理され、
トークンが必要なノード１０１内のクライアント部１０
２は、サーバ部１０３に、必要なトークンの獲得を要求
（依頼）する。 ６）サーバ部１０３は、ファイル１０５を格納するディ
スク上のどこが空いているかを示す空きブロック情報
（空きエクステント情報）及び個々のファイル１０５の
ディスク上での存在場所（ファイル１０５のエクステン
ト情報）を、メタデータ１０４として管理している。 ７）クライアント部１０２は、サーバ部１０３に、ディ
スク上の空きブロック群（空きエクステント群）を事前
要求（リザーブ要求）し、ユーザプログラム２０２から
のwrite 要求時には、事前要求で確保しておいた空きエ
クステント群の中から最適なものを割り当て、そこにユ
ーザデータを書き込む。 続いて、本実施の形態の具体的な動作について、以下に
順次説明する。

【００４４】図３は、任意のノード１０１内のクライア
ント部１０２が実行するファイル操作要求制御のメイン
動作フローチャートであり、図５及び図６は、主サーバ
であるノード１０１（＃１）内のサーバ部１０３（＃
１）が実行するファイル操作要求制御のメイン動作フロ
ーチャートである。なお、以下の説明において、特に言
及しない場合には、「サーバ部１０３」と記述した場合
には、主サーバであるノード１０１（＃１）内のサーバ
部１０３（＃１）を指すものとする。 １）クライアント部１０２及びサーバ部１０３でのopen
操作処理 任意のノード１０１において、ユーザプログラム２０２
（図２）がファイル１０５のopen要求を実行すると、同
一のノード１０１内のクライアント部１０２がそのopen
要求を受け取る（図３のステップ３０１の判定がＹＥ
Ｓ）。この結果、クライアント部１０２は、open操作処
理を実行する（図３のステップ３０２）。図４は、クラ
イアント部１０２が実行する図３のステップ３０２のop
en操作処理の動作フローチャートである。

【００４５】まず、クライアント部１０２は、ＬＡＮ１
０６（図１）を介して、サーバ部１０３に、open要求を
送信する。このopen要求には、アクセスの種別を示すオ
ープンモード（read又はwrite ）が付加される。

【００４６】その後、クライアント部１０２は、サーバ
部１０３からの応答を待つ（図４のステップ４０２−＞
４０３−＞４０２の処理ループ）。なお、タイムアウト
時には、クライアント部１０２は、エラー処理を実行し
（図４のステップ４０３−＞４０４）、その後、図３の
メイン動作フローチャートの処理ループに戻る。

【００４７】サーバ部１０３は、クライアント部１０２
からopen要求を受信すると（図５のステップ５００の判
定がＹＥＳ）、open操作処理を実行する（図５のステッ
プ５０１）。図７は、サーバ部１０３が実行する図５の
ステップ５０１のopen操作処理の動作フローチャートで
ある。

【００４８】まず、サーバ部１０３は、受信されたopen
要求によって指定されているファイル１０５（図１）に
ついて、そのopen要求によって指定されているオープン
モードと矛盾するデータトークンを他のノード１０１に
渡しているかどうかを調べる（図７のステップ７０
１）。

【００４９】サーバ部１０３は、上記オープンモードと
矛盾するデータトークンを他のノード１０１に渡してい
ない場合に、ファイル全体のデータトークン及びエクス
テント情報と、属性トークンと、サイズトークンと、時
刻トークンと、属性データを、それぞれ応答データとし
て設定し（図７のステップ７０２〜７０６）、応答処理
を実行する（図７のステップ７０７）。ファイル全体の
データトークンとサイズトークンは、それぞれ、前記op
en要求によって指定されているオープンモードが、read
ならread権のトークン、write ならwrite 権のトークン
である。また、時刻トークンは、write 権のトークンで
ある。さらに、属性データには、例えばファイルサイ
ズ、アクセス権、ファイル作成日付、ファイル更新日付
等のデータが含まれる。

【００５０】一方、サーバ部１０３は、上記オープンモ
ードと矛盾するデータトークンを他のノード１０１に渡
している場合には、ファイル全体のデータトークンは設
定せずに、エクステント情報と、属性トークンと、サイ
ズトークンと、時刻トークンと、属性データのみを、そ
れぞれ応答データとして設定し（図７のステップ７０３
〜７０６）、応答処理を実行する（図７のステップ７０
７）。

【００５１】クライアント部１０２は、サーバ部１０３
から応答を受信すると、その応答に含まれているファイ
ル全体のデータトークン及びエクステント情報と、属性
トークンと、サイズトークンと、時刻トークンと、属性
データを、それぞれメモリ内のキャッシュ領域に保持す
る（図４のステップ４０２−＞４０５〜４０９）。その
後、クライアント部１０２は、ユーザプログラム２０２
へのファイルディスクリプタの応答等の、その他のopen
操作処理を実行し、その後、図３のメイン動作フローチ
ャートの処理ループに戻る。

【００５２】以上のようにして、本実施の形態では、フ
ァイル１０５のopen時に、競合が発生していなければ、
以降のファイルアクセス（readアクセス又はwrite アク
セス）に必要なトークンが全て渡されるため、クライア
ント部１０２は、サーバ部１０３との間で、トークン獲
得のための通信を行う必要が全くなくなるという効果を
有する。

【００５３】また、open要求時にファイル全体のトーク
ンが引き渡されることにより、可能な限り新たなトーク
ン要求を行わずにファイルへの連続アクセスが可能とな
る。データベースアクセス等を除く一般的なファイルア
クセスでは、１つのノード１０１からのwrite 要求の発
行時に他のノード１０１からread命令が発行される確率
は小さい。従って、１つのノード１０１に引き渡された
ファイル全体のトークンが回収される確率も低く、ファ
イル１０５への連続アクセス時にアクセス単位ごとにト
ークン要求が不要になることによる性能向上が期待でき
る。 ２）クライアント部１０２でのread操作処理 任意のノード１０１で、ユーザプログラム２０２がファ
イル１０５のread要求を発行すると、同一のノード１０
１内のクライアント部１０２がそのread要求を受け取る
（図３のステップ３０３の判定がＹＥＳ）。この結果、
クライアント部１０２は、read操作処理を実行する（図
３のステップ３０４）。図８は、クライアント部１０２
が実行する図３のステップ３０４のread操作処理の動作
フローチャートである。

【００５４】まず、クライアント部１０２は、必要な以
下のトークンを保持しているかどうかを調べる（図８の
ステップ８０１）。 ・read要求された範囲のread権のデータトークン ・属性トークン ・write 権の時刻トークン ・read要求が最終ブロックのread要求である場合のみ、
その最終ブロックについてのread権のサイズトークン ここで、属性トークンが存在すれば、ファイル１０５の
最終ブロックの１つ前のブロックまではファイル内容が
変更されていないことが保証されるため、かかるブロッ
クのread操作処理時にはサイズトークンは獲得する必要
はない。一方、read要求が最終ブロックのread要求であ
る場合において、上記サイズトークンが存在しない場合
には、他のノード１０１内のクライアント部１０２がそ
の最終ブロックからのファイルサイズの拡張処理（writ
e 操作処理）を実行している可能性があり、最終ブロッ
クのread可能範囲が保証されない。上記サイズトークン
が獲得された場合には、最終ブロックのread可能範囲が
保証されるため、ユーザプログラム２０２は、その最終
ブロックについてのread操作処理が可能となる。

【００５５】このように本実施の形態では、ファイル１
０５の最終ブロックにアクセスするのでなければ、サイ
ズトークンを獲得することなくファイル１０５にアクセ
スすることが可能となり、これと並行して、他のノード
１０１は、サイズトークンを獲得してファイル１０５の
最終ブロックにアクセスし、ファイル１０５のサイズを
拡張するwrite 操作処理を実行することができる。この
ため、例えばファイルを拡張するプログラムとファイル
をその先頭から順に読むプログラムをそれぞれ異なるノ
ード１０１で同時に実行させることが可能となり、シス
テム全体の性能を向上させることができる。

【００５６】クライアント部１０２は、もし上記トーク
ンを全て保持しているなら、サーバ部１０３にトークン
を要求することなく、クライアント部１０２が保持する
（キャッシュしている）データを使って、ユーザプログ
ラム２０２の要求を処理する（図８のステップ８０１−
＞８０２）。その後、クライアント部１０２は、図３の
メイン動作フローチャートの処理ループに戻る。

【００５７】一方、クライアント部１０２は、もし不足
するトークンが存在するなら、そのトークンをＬＡＮ１
０６（図１）を介してサーバ部１０３に要求し、サーバ
部１０３からの応答を待つ（図８のステップ８０１−＞
８０３，ステップ８０４−＞８０５−＞８０４の処理ル
ープ）。なお、タイムアウト時には、クライアント部１
０２は、エラー処理を実行し（図４のステップ４０３−
＞４０４）、その後、図３のメイン動作フローチャート
の処理ループに戻る。

【００５８】クライアント部１０２は、サーバ部１０３
から応答を受信すると、その応答に基づいてユーザプロ
グラム２０２の要求を処理する（図８のステップ８０４
−＞８０７）。その後、クライアント部１０２は、図３
のメイン動作フローチャートの処理ループに戻る。 ３）クライアント部１０２でのwrite 操作処理 任意のノード１０１で、ユーザプログラム２０２がファ
イル１０５のwrite 要求を発行すると、同一のノード１
０１内のクライアント部１０２がそのwrite 要求を受け
取る（図３のステップ３０５の判定がＹＥＳ）。この結
果、クライアント部１０２は、write 操作処理を実行す
る（図３のステップ３０６）。この処理は、read操作処
理と同様の図８の動作フローチャートによって示され
る。

【００５９】まず、クライアント部１０２は、必要な以
下のトークンを保持しているかどうかを調べる（図８の
ステップ８０１）。 ・write 要求された範囲のwrite 権のデータトークン ・属性トークン ・write 権の時刻トークン ・write 要求が最終ブロックのwrite 要求である場合の
み、その最終ブロックについてのwrite 権のサイズトー
クン ここで、サイズトークンを用いることにより得られる効
果は、read操作処理時の場合と同様である。

【００６０】クライアント部１０２は、もし上記トーク
ンを全て保持しているなら、サーバ部１０３にトークン
を要求することなく、クライアント部１０２が保持する
（キャッシュしている）データを使って、ユーザプログ
ラム２０２の要求を処理する（図８のステップ８０１−
＞８０２）。その後、クライアント部１０２は、図３の
メイン動作フローチャートの処理ループに戻る。

【００６１】一方、クライアント部１０２は、もし不足
するトークンが存在するなら、そのトークンをＬＡＮ１
０６（図１）を介してサーバ部１０３に要求し、サーバ
部１０３からの応答を待つ（図８のステップ８０１−＞
８０３，ステップ８０４−＞８０５−＞８０４の処理ル
ープ）。なお、タイムアウト時には、クライアント部１
０２は、エラー処理を実行し（図４のステップ４０３−
＞４０４）、その後、図３のメイン動作フローチャート
の処理ループに戻る。

【００６２】クライアント部１０２は、サーバ部１０３
から応答を受信すると、その応答に基づいてユーザプロ
グラム２０２の要求を処理する（図８のステップ８０４
−＞８０７）。その後、クライアント部１０２は、図３
のメイン動作フローチャートの処理ループに戻る。 ４）クライアント部１０２でのファイル時刻操作処理 任意のノード１０１において、ユーザプログラム２０２
（図２）がファイル１０５に関するファイル時刻を要求
すると、同一のノード１０１内のクライアント部１０２
がその要求を受け取る（図３のステップ３０７の判定が
ＹＥＳ）。この結果、クライアント部１０２は、ファイ
ル時刻操作処理を実行する（図３のステップ３０８）。
図９は、クライアント部１０２が実行する図３のステッ
プ３０８のファイル時刻操作処理の動作フローチャート
である。

【００６３】まず、クライアント部１０２は、ユーザプ
ログラム２０２から指定されたファイル１０５につい
て、read権の時刻トークンのみを保持しているかどうか
を調べる（図９のステップ９０１）。この判定がＹＥＳ
ならば、クライアント部１０２は、自身が保持するファ
イル時刻をユーザプログラム２０２に応答する（図９の
ステップ９０３）。その後、クライアント部１０２は、
図３のメイン動作フローチャートの処理ループに戻る。

【００６４】上記判定がＮＯならば、クライアント部１
０２は次に、ユーザプログラム２０２から指定されたフ
ァイル１０５について、read権とwrite 権の各時刻トー
クンを保持しており、かつ前回サーバ部１０３から上記
ファイル１０５に関するファイル時刻を取得してからそ
のファイル１０５に未アクセスであるかどうかを調べる
（図９のステップ９０２）。この判定がＹＥＳの場合に
も、クライアント部１０２は、自身が保持するファイル
時刻をユーザプログラム２０２に応答する（図９のステ
ップ９０３）。その後、クライアント部１０２は、図３
のメイン動作フローチャートの処理ループに戻る。

【００６５】上記ステップ９０３の判定もＮＯならば、
クライアント部１０２は、ＬＡＮ１０６を介してサーバ
部１０３に、自クライアント部１０２でのそのファイル
１０５に関するファイルアクセスの有無を付加した要求
であって、read権の時刻トークンの獲得要求を送信する
（図９のステップ９０４）。

【００６６】その後、クライアント部１０２は、サーバ
部１０３からの応答を待つ（図９のステップ９０５−＞
９０６−＞９０５の処理ループ）。なお、タイムアウト
時には、クライアント部１０２は、エラー処理を実行し
（図９のステップ９０６−＞９０７）、その後、図３の
メイン動作フローチャートの処理ループに戻る。

【００６７】クライアント部１０２は、サーバ部１０３
からファイル時刻を受信すると、そのファイル時刻をユ
ーザプログラム２０２に応答する（図９のステップ９０
５−＞９０８）。また、クライアント部１０２は、その
ファイル時刻を、クライアント部１０２内の上記ファイ
ル１０５に対応するキャッシュ領域に保持する（図９の
ステップ９０９）。さらにクライアント部１０２は、上
記キャッシュ領域において、上記ファイル１０５に対し
てファイルアクセスなしの状態を設定する（図９のステ
ップ９１０）。 ５）サーバ部１０３でのread権の時刻トークンの応答処
理 任意のノード１０１において、クライアント部１０２
が、前述した図３のステップ３０８及び図９のファイル
時刻操作処理を実行することによって、サーバ部１０３
にread権の時刻トークンを要求すると（図９のステップ
９０４）、サーバ部１０３が、それを受け取ることによ
り（図５のステップ５０２の判定がＹＥＳ）、read権の
時刻トークンの応答処理を実行する（図５のステップ５
０３）。図１０は、サーバ部１０３が実行する図５のス
テップ５０３の応答処理の動作フローチャートである。

【００６８】サーバ部１０３は、クライアント部１０２
からread権の時刻トークンの獲得要求を受信すると、ま
ずその時刻トークンに対応するwrite 権の時刻トークン
を保持するクライアント部１０２が存在するかどうかを
調べる（図１０のステップ１００１）。

【００６９】この判定がＹＥＳの場合は、クライアント
部１０２は、上記write 権の時刻トークンを保持する全
てのクライアント部１０２に、そのwrite 権の時刻トー
クンの回収要求を発行し、全てのクライアント部１０２
からの応答を待つ（図１０のステップ１００１−＞１０
０２，ステップ１００３−＞１００４−＞１００３の処
理ループ）。なお、タイムアウト時には、サーバ部１０
３は、エラー処理を実行し（図１０のステップ１００４
−＞１００５）、その後、図５及び図６のメイン動作フ
ローチャートの処理ループに戻る。

【００７０】これに対して、各クライアント部１０２で
は、要求されたwrite 権の時刻トークンの回収処理を実
行する（図３のステップ３０９−＞３１０）。具体的に
は、各クライアント部１０２は、要求されたwrite 権の
時刻トークンを無効化すると共に、その時刻トークンに
対応するファイル１０５に対するファイルアクセスの有
無を、サーバ部１０３への応答に付加する。

【００７１】サーバ部１０３は、ステップ１００１の判
定がＮＯであった場合、又は上記write 権の時刻トーク
ンを保持する全てのクライアント部１０２からの応答を
受信した場合に、read権の時刻トークンを要求している
クライアント部１０２に応答するファイル時刻を決定す
る（図１０のステップ１００６）。具体的には、要求元
を含めて（図９のステップ９０４参照）、いずれかのノ
ード１０１のクライアント部１０２がファイルアクセス
有りを応答した場合は、サーバ部１０３は、自身がメタ
データ１０４として保持する該当ファイル時刻を、現時
刻により更新する。なお、各クライアント部１０２から
ファイルアクセス相対時刻間隔（何秒前にアクセスした
かを示すデータ）を応答させるようにし、応答された各
クライアント部１０２からのファイルアクセス相対時刻
間隔のうち最も小さい値によって、メタデータ１０４内
の時刻を更新する（すなわち、［“現時刻”−“最も小
さいファイルアクセス相対時刻間隔］にする）ように構
成されてもよい。一方、いずれのノード１０１もファイ
ルアクセス無しを応答した場合は、サーバ部１０３は、
自身が保持するメタデータ１０４中の該当ファイル時刻
を、そのまま使用する。

【００７２】続いて、サーバ部１０３は、決定したメタ
データ１０４中のファイル時刻を、read権の時刻トーク
ンを要求したクライアント部１０２に応答する（図１０
のステップ１００７）。

【００７３】最後に、サーバ部１０３は、要求元のクラ
イアント部１０２にread権の時刻トークンを渡したこと
をサーバ部１０３の主記憶中に記憶する（図１０のステ
ップ１００８）。

【００７４】その後、サーバ部１０３は、図５及び図６
のメイン動作フローチャートの処理ループに戻る。 ６）サーバ部１０３でのwrite 権の時刻トークンの応答
処理 任意のノード１０１において、クライアント部１０２
が、前述した図３のステップ３０４及び図８のread操作
処理又は図３のステップ３０６及び図８のwrite操作処
理を実行することにより、サーバ部１０３にwrite 権の
時刻トークンを要求すると、サーバ部１０３が、それを
受け取ることにより（図５のステップ５０４の判定がＹ
ＥＳ）、write 権の時刻トークンの応答処理を実行する
（図５のステップ５０５）。図１１は、サーバ部１０３
が実行する図５のステップ５０５の応答処理の動作フロ
ーチャートである。

【００７５】サーバ部１０３は、クライアント部１０２
からwrite 権の時刻トークンの獲得要求を受信すると、
まずその時刻トークンに対応するread権の時刻トークン
を保持するクライアント部１０２が存在するかどうかを
調べる（図１１のステップ１１０１）。

【００７６】この判定がＹＥＳの場合は、クライアント
部１０２は、上記read権の時刻トークンを保持する要求
クライアント部１０２を除く全てのクライアント部１０
２に、そのread権の時刻トークンの回収要求を発行し、
全てのクライアント部１０２からの応答を待つ（図１１
のステップ１１０１−＞１１０２，ステップ１１０３−
＞１１０４−＞１１０３の処理ループ）。なお、タイム
アウト時には、サーバ部１０３は、エラー処理を実行し
（図１１のステップ１１０４−＞１１０５）、その後、
図５及び図６のメイン動作フローチャートの処理ループ
に戻る。

【００７７】これに対して、各クライアント部１０２で
は、要求されたread権の時刻トークンの回収処理を実行
する（図３のステップ３０９−＞３１０）。具体的に
は、各クライアント部１０２は、要求されたread権の時
刻トークンを無効化し、サーバ部１０３に応答を返す。

【００７８】サーバ部１０３は、ステップ１１０１の判
定がＮＯであった場合、又は上記read権の時刻トークン
を保持する全てのクライアント部１０２からの応答を受
信した場合に、write 権の時刻トークンを、要求クライ
アント部１０２に応答する（図１１のステップ１１０
６）。

【００７９】最後に、サーバ部１０３は、要求元のクラ
イアント部１０２にwrite 権の時刻トークンを渡したこ
とをメタデータ１０４中に記憶する（図１１のステップ
１１０７）。

【００８０】その後、サーバ部１０３は、図５及び図６
のメイン動作フローチャートの処理ループに戻る。上述
の２）〜６）で示したように、本実施の形態では、ユー
ザプログラム２０２がファイル１０５のread操作処理又
はwrite 操作処理を実行するときには、該当クライアン
ト部１０２はそのファイル１０５についてのwrite 権の
時刻トークンを使用する。この際、クライアント部１０
２はそのファイル１０５についてのwrite 権の時刻トー
クンを保持していなければサーバ部１０３にそれを要求
する。これに応答してサーバ部１０３は、他のノード１
０１からそのファイル１０５に対応するread権の時刻ト
ークンは回収するが、write 権の時刻トークンは回収し
ない。従って、クライアント部１０２は、ユーザプログ
ラム２０２が１つのファイル１０５に連続アクセスする
ような場合において、そのファイル１０５への最終的な
アクセスが終了するまでwrite 権の時刻トークンを返却
する必要も、またアクセスの有無をサーバ部１０３に通
知する必要もなく、他のノード１０１との間でそのファ
イル１０５のファイル時刻の同期をとる必要がなくな
る。このため、システム全体の性能を向上させることが
可能となる。

【００８１】なお、上述の制御によると、write 権の時
刻トークンは、ユーザプログラム２０２がファイル１０
５のファイル時刻を明示的に要求し、該当クライアント
部１０２からサーバ部１０３にそのファイル１０５につ
いてのread権の時刻トークンが要求された場合に回収さ
れることになるが、これだけだと、ファイル時刻の要求
が発生しない限り、ファイル１０５のファイル時刻がい
つまでたってもサーバ部１０３側で確定しないことにな
る。これを防ぐために、例えば、クライアント部１０２
は、ユーザプログラム２０２がファイル１０５をクロー
ズしたタイミングで、サーバ部１０３にファイルアクセ
スの有無を通知し、サーバ部１０３はそれを受けてメタ
データ１０４中の該当ファイル時刻を更新するように構
成することができる。 ７）サーバ部１０３でのデータトークンの応答処理 任意のノード１０１において、クライアント部１０２
が、前述した図３のステップ３０４及び図８のread操作
処理又は図３のステップ３０６及び図８のwrite操作処
理を実行することにより、サーバ部１０３にデータトー
クンを要求すると（図８のステップ８０３）、サーバ部
１０３が、それを受け取ることにより（図５のステップ
５０６の判定がＹＥＳ）、データトークンの応答処理を
実行する（図５のステップ５０７）。図１２は、サーバ
部１０３が実行する図５のステップ５０７の応答処理の
動作フローチャートである。

【００８２】サーバ部１０３は、クライアント部１０２
からデータトークンの獲得要求を受信すると、まずその
要求に矛盾するデータトークンを保持するクライアント
部１０２が存在するかどうかを調べる（図１２のステッ
プ１２０１）。

【００８３】この判定がＹＥＳの場合は、クライアント
部１０２は、上記データトークンを保持する全てのクラ
イアント部１０２に、そのデータトークンの回収要求を
発行し、全てのクライアント部１０２からの応答を待つ
（図１２のステップ１２０１−＞１２０２，ステップ１
２０３−＞１２０４−＞１２０３の処理ループ）。な
お、タイムアウト時には、サーバ部１０３は、エラー処
理を実行し（図１２のステップ１２０４−＞１２０
５）、その後、図５及び図６のメイン動作フローチャー
トの処理ループに戻る。

【００８４】これに対して、各クライアント部１０２で
は、要求されたデータトークンの回収処理を実行する
（図３のステップ３０９−＞３１０）。具体的には、各
クライアント部１０２は、要求されたデータトークンを
無効化し、サーバ部１０３に応答を返す。また、回収を
要求されたデータトークンがwrite 権のデータトークン
である場合には、各クライアント部１０２は、そのwrit
e 権のデータトークンで示されるファイル１０５の範囲
で自身が更新したデータをキャッシュからディスク上に
書き戻し、新たにそのファイル１０５に割り当てたエク
ステント情報を、上記応答に付加する。

【００８５】サーバ部１０３は、上述のデータトークン
を保持する全てのクライアント部１０２からの応答を受
信した場合に、上記応答がwrite 権のデータトークンに
関するものであるならば、応答されたファイル１０５の
エクステント情報を、自身が保持するメタデータ１０４
に反映させる（図１２のステップ１２０３−＞１２０
６）。

【００８６】その後、サーバ部１０３は、要求元のクラ
イアント部１０２から指定された範囲のエクステント情
報が付加されたデータトークンを、上記クライアント部
１０２に応答する（図１２のステップ１２０７）。

【００８７】一方、クライアント部１０２からのデータ
トークンの獲得要求に矛盾するデータトークンを保持す
るクライアント部１０２が存在せずステップ１２０１の
判定がＮＯで、かつファイル全体のデータトークンを応
答しても競合が発生せずステップ１２０８の判定もＮＯ
である場合には、サーバ部１０３は、ファイル全体のエ
クステント情報とファイル全体のデータトークンを、要
求元のクライアント部１０２に応答する（図１２のステ
ップ１２０１−＞１２０８−＞１２０９）。

【００８８】上記競合が発生する場合には、サーバ部１
０３は、要求元のクライアント部１０２から指定された
範囲のエクステント情報が付加されたデータトークン
を、上記クライアント部１０２に応答する（図１２のス
テップ１２０７）。

【００８９】ステップ１２０７又は１２０９の処理の
後、サーバ部１０３は、図５及び図６のメイン動作フロ
ーチャートの処理ループに戻る。サーバ部１０３からデ
ータトークンを取得したクライアント部１０２は、前述
した図４のステップ４０５又は図８のステップ８０７の
処理において、自身が該当ファイル１０５に対応するデ
ータトークンを保持していること、及び応答されたエク
ステント情報を、メモリ内のキャッシュ領域に記憶す
る。そして、クライアント部１０２は、それ以降のユー
ザプログラム２０２からの要求に基づくファイルアクセ
ス処理（図８のステップ８０２）は、上記エクステント
情報で示される、ディスク上のブロックに対して実行す
る。

【００９０】上述したように、データトークンの応答時
に、ファイル１０５のエクステント情報も同時に応答さ
れる。このため、複数のノード１０１は、ディスク装置
内のファイル１０５に、ＬＡＮ１０６経由ではなく直結
された制御・データ線を介してアクセスすることが可能
となる。 ８）サーバ部１０３におけるサイズトークンの応答処理 サーバ部１０３は、クライアント部１０２からサイズト
ークンを要求された場合には、その要求と矛盾するサイ
ズトークンを他のクライアント部１０２から回収した上
で、要求されたサイズトークンにファイルサイズを付加
して要求元のクライアント部１０２に応答する（図５の
ステップ５０６−＞５０７）。その後、サーバ部１０３
は、図５及び図６のメイン動作フローチャートの処理ル
ープに戻る。 ９）サーバ部１０３における属性トークンの応答処理 サーバ部１０３は、クライアント部１０２から属性トー
クンを要求された場合には、その要求と矛盾する属性ト
ークンを他のクライアント部１０２から回収した上で、
要求された属性トークンにファイル属性を付加して要求
元のクライアント部１０２に応答する（図５のステップ
５０８−＞５０９）。その後、サーバ部１０３は、図５
及び図６のメイン動作フローチャートの処理ループに戻
る。 １０）エクステント管理の詳細 次に、サーバ部１０３及びクライアント部１０２におけ
るエクステント（ディスク領域）の管理の詳細について
説明する。

【００９１】まず、サーバ部１０３は、複数のディスク
ボリュームを管理することができ、メタデータ１０４と
して、ファイル１０５の属性データ、各ディスクボリュ
ーム毎の空きエクステントに関する情報（空きスペース
情報）、及びクライアント部１０２に貸し出したエクス
テントに関する情報（リザーブスペース情報）を保持し
ている。

【００９２】空きスペース情報とリザーブスペース情報
は、図１３に示されるように、空きスペースＢツリー１
３０１として管理され、そのうち空きスペース情報は空
きスペースキュー１３０２からアクセスでき、リザーブ
スペース情報はリザーブスペースキュー１３０３からア
クセスできる。

【００９３】空きスペースキュー１３０２は、ディスク
ボリューム毎に、空きスペースＢツリー１３０１に接続
されている使用可能エクステント（使用中でもリザーブ
中でもないエクステント）を管理する。

【００９４】リザーブスペースキュー１３０３は、クラ
イアント部１０２毎に、そのクライアント部１０２にリ
ザーブされ空きスペースＢツリー１３０１に接続されて
いるエクステントを管理する。

【００９５】また、サーバ部１０３は、使用中のエクス
テントは、ｉノードＢツリー１３０４によって管理す
る。一方、クライアント部１０２は、サーバ部１０３に
要求することによりリザーブしたエクステントを、リザ
ーブキュー１３０５によって管理する。

【００９６】クライアント部１０２は、主記憶上にキャ
ッシュを持ち、ユーザプログラムが要求したディスク上
のデータをキャッシュする。サーバ部１０３内の空きス
ペーアスキュー１３０２とクライアント部１０２内のリ
ザーブキュー１３０５は、ディスクボリューム毎に予め
決められた個数分のヘッダを有しており、各ヘッダがエ
クステントのサイズに対応している。例えば、ヘッダの
個数を４個とすると、各ヘッダが、１〜４ＫＢ（キロバ
イト）、４〜１６ＫＢ、１６〜６４ＫＢ、６４〜２５６
ＫＢの各サイズ範囲のエクステント群（空きスペースＢ
ツリー１３０１）を管理する。ヘッダの個数と各ヘッダ
が表すサイズは、各ディスクボリュームのファイルシス
テムを作成したときに決定される。

【００９７】図１４は、１つのノード１０１（図１参
照）内において、ユーザプログラム２０２（図２参照）
が、ファイル１０５へのデータ書き込み（write 要求）
を依頼したときのエクステント管理のシーケンスを示す
図である。このシーケンスにおいて、クライアント部１
０２が実行する処理は、図３のステップ３０６のwrite
操作処理における図８のステップ８０７の処理の一部で
ある。また、サーバ部１０３が実行する処理は、図５の
サーバ部１０３のメイン動作フローチャート内の特には
図示しない一部の処理である。

【００９８】図１４において、ユーザプログラム２０２
がファイル１０５に対するwrite 要求を発行すると、ク
ライアント部１０２は、キャッシュにデータを保持す
る。ユーザプログラム２０２がファイル１０５をクロー
ズし、又はキャッシュが一杯になり、或いはサーバ部１
０３からデータトークンの回収を要求される（図１２の
ステップ１２０２参照）ことにより、キャッシュされて
いるデータをディスクに書き出す必要が発生した場合
に、クライアント部１０２は、サーバ部１０３から受け
取っていたファイル１０５のエクステント情報（図４の
ステップ４０５参照）を調べ、その要求が既にディスク
領域が割り当てられているファイル領域に対するもので
あるか否かを認識し、ファイル１０５毎にキャッシュ内
でエクステントが割り当てられていない領域で隣接する
ものをまとめる（このまとめられたファイル領域を書出
し対象領域と呼ぶ）。次に、クライアント部１０２は、
書出し対象領域のサイズを調べると共に、その領域の性
質に従って、以下の何れかの処理を実行する。 書出し対象領域に隣接する（直前の）領域に、同じフ
ァイル１０５に関するエクステントが既にサーバ部１０
３から割り当てられている場合：クライアント部１０２
は、割り当てられているエクステントのブロックアドレ
スと書出し対象領域のサイズを指定して、それに続くエ
クステントのリザーブ（貸し出し）をサーバ部１０３に
依頼し、応答されたエクステントにデータを書き込む。
なお、サーバ部１０３は、依頼されたエクステントが既
に割当て済みの場合には、他のエクステントを返す。 書出し対象領域に隣接する（直前の）領域に、同じフ
ァイル１０５に関するエクステントがいまだサーバ部１
０３から割り当てられていない場合：クライアント部１
０２は、書出し対象領域のサイズに対応するリザーブキ
ュー１３０５の先頭に接続されているエクステントにデ
ータを書き出す。クライアント部１０２は、リザーブキ
ュー１３０５から、そのエクステントを取り除く。 以上の動作の後、クライアント部１０２は、サーバ部１
０３に書出し完了を通知する。この際、クライアント部
１０２は、使用したエクステント（リザーブスペース）
のアドレスと、書出し対象領域のサイズを通知する。

【００９９】サーバ部１０３は、通知されたエクステン
ト（リザーブスペース）のアドレスと、書出し対象領域
のサイズとから、メタデータ１０４内の対象ファイル１
０５に関する属性データを更新し、リザーブスペースキ
ュー１３０３及び空きスペースＢツリー１３０１上か
ら、クライアント部１０２から通知されたエクステント
を取り除き、そのエクステントをＩノードＢツリー１３
０４に接続する。書き出されたエクステントのサイズが
使用されたリザーブスペースよりも小さい場合には、サ
ーバ部１０３は、残りのエクステントを、空きスペース
として空きスペースキュー１３０２の当該エクステント
のサイズに対応するヘッダに接続する。 １１）エクステント群のリザーブ制御処理 クライアント部１０２は、一定時間が経過するごとに、
エクステント群リザーブ要求処理を実行する（図３のス
テップ３１１−＞３１２）。この処理では、クライアン
ト部１０２は、自身がリザーブキュー１３０５にリザー
ブしているエクステント群を調べ、リザーブ量が一定値
以下になった場合に、サーバ部１０３に一定個数のエク
ステント群のリザーブを要求する。この処理は、各サイ
ズのヘッダ毎に行われ、不足が発生したヘッダ以外につ
いても、各リザーブ量が所定値以上となるように、各ヘ
ッダに対して上記リザーブ処理が実行される。

【０１００】サーバ部１０３は、エクステント群のリザ
ーブ要求を受信すると、エクステント群のリザーブ処理
を実行する（図６のステップ５１２−＞５１３）。この
処理では、サーバ部１０３は、空きスペースキュー１３
０２に接続されている空きスペースＢツリー１３０１中
から、使用可能なエクステント群を探し、それらを空き
スペースキュー１３０２からリザーブスペースキュー１
３０３に繋ぎ替えた後に、そのリザーブしたエクステン
ト群をクライアント部１０２に応答する。その後、サー
バ部１０３は、図５及び図６のメイン動作フローチャー
トの処理ループに戻る。

【０１０１】クライアント部１０２は、図３のステップ
３１２において、サーバ部１０３から応答されたエクス
テント群をリザーブキュー１３０５に繋ぎ、ステップ３
１２を終了して、図３のメイン動作フローチャートの処
理ループに戻る。

【０１０２】サーバ部１０３は、自身に対してmount を
行っているクライアント部１０２の障害を検出した場
合、又はクライアント部１０２からunmount 要求を受信
した場合には、そのクライアント部１０２に対してリザ
ーブしていたリザーブスペースキュー１３０３中のエク
ステント群の解放処理を実行して、それらを空きスペー
スキュー１３０２に繋ぎ替える（図５のステップ５１４
−＞５１５）。その後、サーバ部１０３は、図５及び図
６のメイン動作フローチャートの処理ループに戻る。

【０１０３】上述のように、本実施の形態では、空きエ
クステント群がリザーブされることにより、クライアン
ト部１０２は、サーバ部１０３に問い合わせることな
く、キャッシュを活用して新たなエクステントをファイ
ル１０５に割り当てることが可能となる。このため、ク
ライアント部１０２とサーバ部１０３との間の通信回数
を削減でき、システム全体の性能を向上させることが可
能となる。

【０１０４】また、新たに割り当てられたエクステント
は、データが書き込まれた後のクライアント部１０２か
らサーバ部１０３への応答によって初めて、そのファイ
ル１０５のメタデータ１０４として記憶される。このた
め、悪意をもってデータを覗くことを防止することが可
能となる。 １２）主サーバと従サーバの同期処理 主サーバであるノード１０１（＃１）内のサーバ部１０
３（＃１）は、例えば図７、図１０、図１１、図１２な
どにおいて、メタデータ１０４（＃１）を更新する場合
は、従サーバであるノード１０１（＃２）内のサーバ部
１０３（＃２）に対して、メタデータ変更分と時刻デー
タを送信し、従サーバがそれらを受信したことを確認し
た後に、クライアント部１０２に応答を返す。

【０１０５】従サーバであるノード１０１（＃２）内の
サーバ部１０３（＃２）は、上述のメタデータ変更分と
時刻データを受信すると、メタデータ変更分を自身のメ
タデータ１０４（＃２）に反映させると共に、送られて
きた時刻データを記憶する（図６のステップ５１６−＞
５１７）。その後、サーバ部１０３（＃２）は、図５及
び図６のメイン動作フローチャートの処理ループに戻
る。 １３）主サーバにおける障害発生時の、従サーバへの切
替処理 従サーバであるノード１０１（＃２）内のサーバ部１０
３（＃２）は、主サーバであるノード１０１（＃１）内
のサーバ部１０３（＃１）の障害を監視しており、その
障害を検出した場合には、サーバ切替処理を実行する
（図６のステップ５１８−＞５１９）。このとき、サー
バ部１０３（＃２）は、最後に主サーバであるサーバ部
１０３（＃１）から送られてきた時刻を過ぎるまで、自
身の時刻の待ち合せを実行する。その後、サーバ部１０
３（＃２）は、図５及び図６のメイン動作フローチャー
トの処理ループに戻る。

【０１０６】上述の制御により、サーバ切替時にも、矛
盾のないファイル時刻の付与が可能となる。次に、上述
したようなノード間ファイル共用管理システムにおい
て、分散ファイルシステムの耐故障性を高めるためのロ
グ制御機構を実現するための実施の形態について説明す
る。

【０１０７】図１５は、ログ制御機構を実装したノード
間ファイル共用管理システムの基本構成図である。共用
ファイル管理装置１５０１（図１のサーバ部１０３を有
するノード１０１に対応する）は、共用されるファイル
の「属性」や「実ディスク上での格納位置」などの、フ
ァイルごとに存在する制御情報（ファイル情報と呼ぶ）
と、実ディスクの空き領域などを示す制御情報（ディス
ク情報と呼ぶ）を保持している。これら２つの管理情報
を総称してメタデータ１５０２（図１のメタデータ１０
４に対応する）と呼び、障害に備えディスク上に格納さ
れている。

【０１０８】共用ファイル管理装置１５０１は、データ
を共用する＃１〜＃ｎの各ノード１５０３（クライアン
ト部１０２を有するノード１０１に対応する）からの要
求に従い、メタデータ１５０２をディスクから読み込み
或いは更新し、ファイル情報を応答として返す。この
際、異なる複数のメタデータブロックがアクセスされる
可能性がある。

【０１０９】各ノード１５０３は、返されたファイル情
報をメモリ上にキャッシュし、それ以降必要が生ずるま
で、共用ファイル管理装置１５０１と通信することな
く、キャッシュされたメモリ上のファイル情報のみを用
いて処理を実行する。

【０１１０】各ノード１５０３がそれぞれのキャッシュ
上に保持するファイル情報相互間の一貫性を保証するた
めに、トークンが使用される。トークンは、ファイル情
報がノード１５０３に返される際に共用ファイル管理装
置１５０１によりそのノード１５０３に対して発行さ
れ、共用ファイル管理装置１５０１が或るノード１５０
３から矛盾する要求を受け付けたときに共用ファイル管
理装置１５０１によって必要なノード１５０３から回収
される。

【０１１１】回吸を指示されたノード１５０３は、トー
クンによって指示されるキャッシュデータを無効化し、
他ノード１５０３に伝えられるべき自身が行なったファ
イル情報の変更を応答する。

【０１１２】応答を受けた共用ファイル管理装置１５０
１は、通知された変更をメタデータ１５０２に反映した
後に、要求に基づく処理を再開し、要求元に対して結果
を応答すると共にトークンを発行する。

【０１１３】共用ファイル管理装置１５０１が各ノード
１５０３からの要求を処理するためには、メタデータ１
５０２へのアクセスが必要となる。この場合に、毎回デ
ィスクをアクセスしていたのでは性能が悪くなる。この
ため、ディスク上のデータを保持するバッファキャッシ
ュ１５０４が共用ファイル管理装置１５０１内に設けら
れ、ディスクアクセスが削減される。バッファキャッシ
ュ１５０４は、ディスク上の各ブロックに対応したエン
トリを持ち、各エントリにそのエントリのロックの有無
を表示するためのロックワードが用意されることによ
り、或るスレッドが更新中のデータを他の要求を処理し
ている他のスレッドが参照することが抑止される。

【０１１４】メタデータ１５０２の実ディスクへの反映
は、要求処理が全て正常に終了した時点、いわゆるトラ
ンザクション完了時まで遅らされる。トランザクション
が正常に終了すると、バッファキャッシュ１５０４上に
保持されている更新データが一括してログファイル１５
０５に書き出され、その後、更新データのディスクへの
反映タイミングがスケジュールされる。

【０１１５】ログファイル１５０５はサイクリックに使
用され、実ディスクへの書き込みが完了するたびに、書
出しが完了した変更を保持するログ領域は空き領域に戻
される。従って、実ディスクへの書出しがまだ完了して
いない、成功した要求に伴うメタデータの変更は必ずロ
グファイル１５０５上に存在するので、共用ファイル管
理装置１５０１で障害が発生しても、メタデータ１５０
２の復旧は容易にかつ高速に行なえるという特徴を有す
る。

【０１１６】次に、本実施の形態に係る上記基本構成に
基づくロック継承制御処理につき、図１６の説明図に基
づいて説明する。尚、複数のクライアントから発行れる
同一ファイルに対する操作要求を逐次化するためのファ
イル管理装置１５０１はファイル毎に用意するファイル
ロックを使用する。

【０１１７】本実施の形態では、１つのノード１５０３
からの要求を処理するために共用ファイル管理装置１５
０１上で実行される第１の実行単位（スレッド）は、他
のノード１５０３に発行しているトークンを回収する場
合に、トークン処理の対象となっているファイルを示す
情報を保持したトークン回収制御表１６０２をトークン
回収待ちキュー１６０１につなぎ、該当するノード１５
０３に対してトークン回収要求を送信した後、トークン
回収完了メッセージの到着を待ち合わせる。

【０１１８】トークンを保持しているノード１５０３に
おけるキャッシュの無効化が完了しそこから共用ファイ
ル管理装置１５０１（図１５）にトークン回収完了メッ
セージが通知されると、トークン回収完了メッセージを
処理するために共用ファイル管理装置１５０１上で実行
される第２の実行単位（スレッド）が、トークン回収待
ちキュー１６０１を調べ、そのメッセージに対応するト
ークン回収制御表１６０２がキュー上に存在するなら
ば、その制御表に「ロック縫承中」を表示した上で、メ
タデータ１５０２（図１５）の更新処理及びトークンの
解放処理を実行する。

【０１１９】トークン回収完了メッセージの到着を待ち
合わせていた第１の実行単位の待ちは、第２の実行単位
によるトークン解放処理の結果解かれる。各ノード１５
０３は、共用ファイル管理装置１５０１からの要求に基
づかずに自律的に、トークン回収完了メッセージを共用
ファイル管理装置１５０１に通知することもできる。従
って、トークン回収完了メッセージが共用ファイル管理
装置１５０１に到着した際に、トークン回収待ちキュー
１６０１に該当するトークン回収制御表１６０２がつな
がっていない場合が起こり得る。このようなときには、
上記第２の実行単位は、通常のファイルロック獲得処理
を実行し、この結果他の実行単位がファイルロックを保
持していればファイルロックの解放を待ち合わせ、ファ
イルロックがはずれたらメタデータの更新処理及びトー
クン解放処理を実行する。

【０１２０】上記第１の実行単位は、複数のノード１５
０３に対してトークン回収要求を送信する可能性があ
る。このような場合には、共用ファイル管理装置１５０
１は、複数のノード１５０３からトークン回収完了メッ
セージを相次いで受信する可能性がある。上記第２の実
行単位は、第１番目のトークン回収完了メッセージを受
信した時点で該当するトークン回収制御表１６０２にロ
ック継承中を表示する。そして、第２番目以降のトーク
ン回収完了メッセージを受信した他の各実行単位は、対
応するトークン回収制御表１６０２にロック継承中が表
示されていた場合には、継承中表示がオフとなるのを待
ち合わせ、待ちが解けた時点でメタデータの更新処理及
びトークン解放処理を実行する。このように、ロックの
継承を行うことのできる実行単位は１つに制限される。

【０１２１】以上のロック継承制御により、トークン制
御において、デッドロックの発生を回避することのでき
る効率的なファイルロック制御が実現される。次に、本
実施の形態に係る図１５に示される基本構成に基づくデ
ッドロック検出処理について、図１７の説明図に基づき
説明する。

【０１２２】共用ファイル管理装置１５０１（図１５）
は、各ファイルを管理するファイル制御表１７０１に、
ファイルロックワード１７０１ａに対応して、そのファ
イルロックを保持している実行単位（スレッド）を示す
オーナ１７０１ｂを設定し、また、各バッファキャッシ
ュ１５０４（図１５）のエントリを管理するバッファキ
ャッシュ制御表１７０２に、バッファキャッシュロック
ワード１７０２ａに対応して、そのバッファキャッシュ
ロックを保持している実行単位（スレッド）を示すオー
ナ１７０２ｂを設定する。

【０１２３】また、共用ファイル管理装置１５０１は、
各実行単位（スレッド）を管理するスレッド制御表１７
０３に、その実行単位が待ち合わせしている対象を特定
する情報である待ちリソース１７０３ａと、その待ち合
わせの原因を示す情報であるタイプ１７０３ｂを設定す
る。待ちリソース１７０３ａとタイプ１７０３ｂには下
記の何れかの設定が行われる。 １．ファイルロックの解放を待ち合わせる場合： ・タイプ１７０３ｂには、ファイルロック待ちを設定。

【０１２４】・待ちリソース１７０３ａには、該当する
ファイル制御表１７０１内のファイルロックワード１７
０１ａを指示する情報を設定。 ２．バッファキャッシュロックの解放を待ち合わせる場
合： ・タイプ１７０３ｂには、バッファキャッシュロック待
ちを設定。

【０１２５】・待ちリソース１７０３ａには、該当する
バッファキャッシュ制御表１７０２内のバッファキャッ
シュロックワード１７０２ａを指示する情報を設定。 ３．トークン回収を待ち合わせる場合： ・タイプ１７０３ｂには、トークン回収待ちを設定。

【０１２６】・待ちリソース１７０３ａには、該当する
ファイルを指示する情報を設定。 以上の情報を使い、各スレッド（実行単位）は、以下の
ようにデッドロックを検出する。 ＜スレッド（以下、スレッドＡという）がファイルロッ
クを要求した場合＞ ステップ１：スレッドＡは、ファイルロックの解放待ち
に入る前に、そのファイルに対応するファイル制御表１
７０１内のファイルロックワード１７０１ａとオーナ１
７０１ａとから、そのファイルロックを保持しているス
レッド（以下、スレッドＢという）に対応するスレッド
制御表１７０３を取得する。 ステップ２：スレッドＡは、そのスレッド制御表１７０
３内の待ちリソース１７０３ａとタイプ１７０３ｂとか
ら、スレッドＢが待ち合わせている資源を求める。スレ
ッドＢが待ち合わせている資源がないかスレッドＢがト
ークン回収を待ち合わせているならば、スレッドＡは、
デッドロックは発生していないと判定し、ファイルロッ
クの解放待ちに入る。 ステップ３：スレッドＢがトークン回収の待ち合わせ以
外の待ち合わせをしている場合には、スレッドＡは、ス
レッドＢが待ち合わせている資源に対するロックを保持
しているスレッドを求める。 ステップ４：スレッドＡは、ステップ３で求めたスレッ
ドがスレッドＡ自身ならば、デッドロックが発生したと
判定し、スレッドＡ自身が実行しているトランザクショ
ンをキャンセルする。そうでなければ、スレッドＡは、
ステップ２の処理を繰り返す。 ＜スレッドＡがバッファキャッシュロックを要求した場
合＞ ステップ１：スレッドＡは、バッファキャッシュロック
の解放待ちに入る前に、そのバッファキャッシュエント
リに対応するバッファキャッシュ制御表１７０２内のバ
ッファキャッシュロックワード１７０２ａとオーナ１７
０２ｂとから、そのバッファキャッシュロックを保持し
ているスレッドＢに対応するスレッド制御表１７０３を
取得する。 ステップ２：スレッドＡは、そのスレッド制御表１７０
３内の待ちリソース１７０３ａとタイプ１７０３ｂとか
ら、スレッドＢが待ち合わせている資源を求める。スレ
ッドＢが待ち合わせている資源がないならば、スレッド
Ａは、デッドロックは発生していないと判定し、バッフ
ァキャッシュロックの解放待ちに入る。 ステップ３：スレッドＡは、スレッドＢが待ち合わせて
いる資源がトークン回収待ちという資源で且つトークン
回収待対象ファイルのファイルロックをスレッドＡが保
持しているならば、デッドロックが発生したと判定す
る。 ステップ４：スレッドＡは、スレッドＢが待ち合わせて
いる資源に対するロックを保持しているスレッドを求め
る。 ステップ５：スレッドＡは、ステップ４で求めたスレッ
ドがスレッドＡ自身ならば、デッドロックが発生したと
判定し、スレッドＡ自身が実行しているトランザクショ
ンをキャンセルする。そうでなければ、スレッドＡは、
ステップ２の処理を繰り返す。 以上説明したデッドロックの検出処理により、トークン
に基づいてトランザクション制御されているメタデータ
１５０２等の更新処理におけるデッドロックの発生を適
切に検出することができる。

【０１２７】次に、本実施の形態に係る図１５に示され
る基本構成に基づくログファイルの２次キャッシュ制御
処理につき、図１８の説明図に基づいて説明する。２次
キャッシュ１８０１は、ログファイル１５０５（図１
５）には書出しが完了しているが、ディスクへの反映は
完了していないメタデータ１５０２を保持するキャッシ
ュで、トランザクションキャンセル時の性能劣化の防
止、通常処理での性能向上を図るために、共用ファイル
管理装置１５０１上に設けられる。

【０１２８】トランザクションが正常終了した場合、バ
ッファキャッシュ１５０４上で更新されたデータは２次
キャッシュ１８０１に送られ、変更表示がオンされる。
ログファイル１５０５の空き領域が不足してくると、２
次キャッシュ１８０１上の変更表示がオンになっている
データが実ディスクに書き出され、変更表示がリセット
される。

【０１２９】バッファキャッシュ１５０４から２次キャ
ッシュにデータが移動させられる際に、２次キャッシュ
１８０１の空き領域がなければ、変更表示がオンされて
いない２次キャッシュ領域が再使用される。

【０１３０】もし、全てのページの変更表示がオンされ
ているならば、一定の量の変更されたページが実ディス
クに書き出され、変更表示がオフにさせられた後に再使
用される。

【０１３１】必要なメタデータ１５０２がバッファキャ
ッシュ１５０４上に存在しない場合には、２次キャッシ
ュ１８０１にデータが存在するならばそのデータが２次
キャッシュ１８０１からバッファキャッシュ１５０４に
コピーされる。必要なデータが２次キャッシュ１８０１
にも存在しない場合には、そのデータがディスクからバ
ッファキャッシュ１５０４に読み込まれる。

【０１３２】以上説明した２次キャッシュ制御処理によ
り、バッファキャッシュ１５０４の変更内容を実ディス
ク上に書き出すログフラッシュ処理を、実行中のトラン
ザクションと独立して行うことが可能となり、システム
性能の向上が実現される。

【０１３３】続いて、本実施の形態に係る図１５に示さ
れる基本構成に基づく、ログデータ量を削減できるログ
制御処理につき、図１９の説明図に基づいて説明する。
メタデータ１５０２がバッファキャッシュ１５０４上で
更新された場合に、スレッドごとに存在するログキュー
１９０１に、更新されたメタデータ１５０２の範囲を示
す情報を記憶したログ制御表１９０２が追加される。こ
の情報は、図１９に示されるように、バッファキャッシ
ュ１５０４上のエントリを指示するエントリＩＤと、そ
のエントリに属する範囲の始点アドレスｓｔａｒｔと終
点アドレスｅｎｄとからなる。

【０１３４】この際、ログキュー１９０１がサーチさ
れ、ログキュー１９０１上に、更新されたメタデータ１
５０２の範囲に対してオーバラップするか隣接する範囲
を表すログ制御表１９０２が既に存在するならば、旧制
御表１９０２の範囲が変更させられるだけで、新しいロ
グ制御表１９０２は作成されない。

【０１３５】トランザクションが正常に終了した場合、
ログキュー１９０１上のログ制御表１９０２から、変更
されたメタデータ１５０２が認識され、それがログファ
イル１５０５にログデータとして書き出される。書出し
が完了したら、該当するバッファキャッシュ１５０４の
エントリに対するロックが解放される。

【０１３６】トランザクションが失敗に終った場合に
は、ログキュー１９０１から更新されたメタデータ１５
０２が認識され、該当するバッファキャッシュ１５０４
上のエントリが無効化される。

【０１３７】以上説明したログ制御処理により、ログフ
ァイル１５０５に書き出されるログデータ量の削減が実
現される。最後に、本実施の形態に係る図１５に示され
る基本構成に基づく、トランザクションキャンセル時に
おけるメモリ常駐制御表のリストア制御処理につき、図
２０の説明図に基づいて説明する。

【０１３８】トランザクション処理の途中でデッドロッ
ク条件が検出されたり要求元のエラーなどが検出される
ことによりトランザクションがキャンセルされる場合に
は、バッファキャッシュ１５０４（図１５）の無効化が
行なわれる。これと共に、スレッドごとに存在するファ
イルロックキュー２００１に接続されている各ファイル
制御表２００２がサーチされることにより、トランザク
ションの過程で獲得され解放されていないファイルロッ
クが、全て解放させられる。

【０１３９】ここで、ファイル制御表２００２には、フ
ァイルロックの獲得に伴って、共用ファイル管理装置１
５０１（図１５）内のメモリ上に存在する常駐制御表２
００３が書き換えられた場合に、その更新を示す制御表
更新フラグが設定される。なお、１つのファイル制御表
２００２には、複数の常駐制御表２００３に対応する複
数の制御表更新フラグを、制御表更新マップとして設定
することができる。

【０１４０】今、トランザクションのキャンセルに伴い
ファイルロックが解除される際に、それに対応するファ
イルロックワードが設定されていたファイル制御表２０
０２において何れかの制御表更新フラグがオンになって
いる場合には、ファイルロックの再獲得時にその制御表
更新フラグに対応する常駐制御表２００３のリロードが
必要なことを示すリロードインジケータ（複数可）が表
示された上で、ファイルロックが解放させられる。

【０１４１】トランザクションがデッドロック検出等に
よりキャンセルされた場合には、その後、そのトランザ
クションに対応する要求が始めからから再試行される。
そして、ファイルロックの再獲得時に、それに対応する
ファイルロックワードが設定されていたファイル制御表
２００２に何れかのリロードインジケータが表示されて
いるならば、ファイルロックの獲得後に上記リロードイ
ンジケータによって指示される常駐制御表２００３が、
メタデータ１５０２（図１５）の情報を使ってメモリ上
に再構築される。

【０１４２】以上説明したリストア制御処理により、ト
ランザクションのキャンセルに伴う常駐制御表２００３
の高速なリストアが実現される。ここで、本発明は、コ
ンピュータにより使用されたときに、上述の本発明の実
施の形態によって実現されるクライアント部１０２の機
能又はサーバ部１０３の機能と同様の機能をコンピュー
タに行わせるためのコンピュータ読出し可能記録媒体と
して構成することもできる。この場合に、例えばフロッ
ピィディスク、ＣＤ−ＲＯＭディスク、光ディスク、リ
ムーバブルハードディスク等の可搬型記録媒体や、ネッ
トワーク回線経由で、本発明の実施の形態の各種機能を
実現するプログラムが、ノードを構成するコンピュータ
の本体内のメモリ（ＲＡＭ又はハードディスク等）にロ
ードされて、実行される。

【０１４３】

【発明の効果】本発明の第１の態様の構成によれば、例
えばopen要求時等においてファイル全体のトークンが引
き渡されることにより、可能な限り新たなトークン要求
を行わずにファイルへの連続アクセスが可能となる。デ
ータベースアクセス等を除く一般的なファイルアクセス
では、１つのノードからのwrite 要求の発行時に他のノ
ードからread命令が発行される確率は小さい。従って、
１つのノードに引き渡されたファイル全体のトークンが
回収される確率も低く、ファイルへの連続アクセス時に
アクセス単位ごとにトークン要求が不要になることによ
る性能向上が期待できる。

【０１４４】本発明の第２の態様の構成によれば、クラ
イアント装置は、ユーザプログラムが１つのファイルに
連続アクセスするような場合において、そのファイルへ
の最終的なアクセスが終了するまでwrite 権の時刻トー
クンを返却する必要もまたアクセスの有無をサーバ部に
通知する必要もなく、他のノードとの間でそのファイル
のファイル時刻の同期をとる必要がなくなる。このた
め、システム全体の性能を向上させることが可能とな
る。

【０１４５】本発明の第３の態様の構成によれば、ファ
イルの最終ブロックにアクセスするのでなければ、サイ
ズトークンを獲得することなくファイルにアクセスする
ことが可能となり、これと並行して、他のノードは、サ
イズトークンを獲得してファイルの最終ブロックにアク
セスし、ファイルのサイズを拡張するwrite 操作処理を
実行することができる。このため、例えばファイルを拡
張するプログラムとファイルをその先頭から順に読むプ
ログラムをそれぞれ異なるノードで同時に実行させるこ
とが可能となり、システム全体の性能を向上させること
ができる。

【０１４６】本発明の第４の態様の構成によれば、複数
のノードは、ディスク装置内のファイルに、ＬＡＮ経由
ではなく直結された制御・データ線を介してアクセスす
ることが可能となる。

【０１４７】本発明の第５の態様の構成によれば、サー
バ切替時にも、矛盾のないファイル時刻の付与が可能と
なる。本発明の第６の態様の構成によれば、クライアン
ト装置は、サーバ装置に問い合わせることなく、新たな
ブロックをファイルに割り当てることが可能となる。こ
のため、クライアント装置とサーバ装置との間の通信回
数を削減でき、システム全体の性能を向上させることが
可能となる。更に、サイズ毎にリザーブすることにより
最適な連続ブロックを割り当てフラグメンテーションを
防止すると共にファイルアクセス性能を向上させること
ができる。また、新たに割り当てられたエクステント
は、データが書き込まれた後のクライアント装置からサ
ーバ装置への応答によって初めて、そのファイルのメタ
データ等として記憶される。このため、悪意をもってデ
ータを覗くことを防止することが可能となる。

【０１４８】本発明の第７の構成によれば、トークン制
御において、デッドロックの発生を回避することのでき
る効率的なファイルロック制御が実現される。本発明の
第８の構成によれば、トークンに基づいてトランザクシ
ョン制御されているメタデータ等の更新処理におけるデ
ッドロックの発生を適切に検出することができる。

【０１４９】本発明の第９の構成によれば、トランザク
ションのキャンセルに伴う常駐制御表の高速なリストア
が実現される。本発明の第１０の構成によれば、ログフ
ァイルに書き出されるログデータ量の削減が実現され
る。

【０１５０】本発明の第１１の構成によれば、ログファ
イルを実ディスク上に書き出すログフラッシュ処理を、
実行中のトランザクションと独立して行うことが可能と
なり、システム性能の向上が実現される。

【図面の簡単な説明】

【図１】本発明の実施の形態のシステム構成図である。

【図２】ノード内のソフトウェア構成図である。

【図３】クライアント部のメイン動作フローチャートで
ある。

【図４】クライアント部のopen操作処理の動作フローチ
ャートである。

【図５】サーバ部のメイン動作フローチャート（その
１）である。

【図６】サーバ部のメイン動作フローチャート（その
２）である。

【図７】サーバ部のopen操作処理の動作フローチャート
である。

【図８】クライアント部のread/write操作処理の動作フ
ローチャートである。

【図９】クライアント部のファイル時刻操作処理の動作
フローチャートである。

【図１０】サーバ部でのread権の時刻トークンの応答処
理の動作フローチャートである。

【図１１】サーバ部でのwrite 権の時刻トークンの応答
処理の動作フローチャートである。

【図１２】サーバ部でのデータトークンの応答処理の動
作フローチャートである。

【図１３】エクステント管理の詳細を示す図である。

【図１４】エクステント管理のシーケンス図である。

【図１５】ログ制御機構を実装したノード間ファイル共
有管理システムの基本構成図である。

【図１６】ロック継承制御処理の説明図である。

【図１７】デッドロック検出処理の説明図である。

【図１８】ログファイルの２次キャッシュ制御の説明図
である。

【図１９】ログデータ量を削減できるログ制御処理の説
明図である。

【図２０】トランザクションキャンセル時におけるメモ
リ常駐制御表のリストア処理の説明図である。

【符号の説明】

１０１、１５０３ ノード １０２ クライアント部 １０３ サーバ部 １０４、１５０２ メタデータ １０５ ファイル １０６ ＬＡＮ ２０１ オペレーティングシステム（ＯＳ） ２０２ ユーザプログラム １５０１ 共用ファイル管理装置 １５０４ バッファキャッシュ １５０５ ログファイル １６０１ トークン回収待ちキュー １６０２ トークン回収制御表 １７０１、２００２ ファイル制御表 １７０１ａ、１７０２ａ ファイルロック １７０１ｂ、１７０２ｂ オーナ １７０２ バッファキャッシュ制御表 １７０３ スレッド制御表 １７０３ａ 待ちリソース １７０３ｂ タイプ １８０１ ２次キャッシュ １９０１ ログキュー １９０２ ログ制御表 ２００１ ファイルロックキュー ２００３ 常駐制御表

───────────────────────────────────────────────────── フロントページの続き (72)発明者 村上 岳生 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5B082 DE03 EA07 FA18 HA02 5B089 GA11 GA21 GB02 HA06 JB15 KA06 KB09 KB11

Claims (35)

【特許請求の範囲】
1. 【請求項１】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイル制御方法であって、 前記クライアント装置から前記サーバ装置へのトークン
   の要求時に、前記サーバ装置において複数の前記クライ
   アント装置間での該トークンの競合の有無を判定し、 該競合が無ければ、前記サーバ装置から前記クライアン
   ト装置へファイル全体のトークンを応答する、 過程を含むことを特徴とするノード間共用ファイル制御
   方法。
2. 【請求項２】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該サーバ
   装置であって、 前記クライアント装置から前記サーバ装置へのトークン
   の要求時に、複数の前記クライアント装置間での該トー
   クンの競合の有無を判定する判定手段と、 該判定手段が該競合が無いと判定した場合に、前記クラ
   イアント装置へファイル全体のトークンを応答する応答
   手段と、 を含むことを特徴とするサーバ装置。
3. 【請求項３】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該サーバ
   装置であるコンピュータにより使用されたときにそれに
   よって読み出されるプログラムを記録した記録媒体であ
   って、 前記クライアント装置から前記サーバ装置へのトークン
   の要求時に、複数の前記クライアント装置間での該トー
   クンの競合の有無を判定する機能と、 該判定手段が該競合が無いと判定した場合に、前記クラ
   イアント装置へファイル全体のトークンを応答する機能
   と、 を前記コンピュータに行わせるためのプログラムを記録
   したコンピュータ読出し可能記録媒体。
4. 【請求項４】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイル制御方法であって、 前記クライアント装置と前記サーバ装置の間で、ファイ
   ル時刻を制御するための時刻トークンを通信し、 前記サーバ装置において、前記ファイル時刻の変更を許
   容するwrite 権の時刻トークンを複数の前記クライアン
   ト装置に同時に応答する制御を実行し、 前記クライアント装置において、前記write 権の時刻ト
   ークンを獲得した後は、前記サーバ装置にファイル時刻
   を問い合わせることなく、ファイルアクセスを実行し、 前記サーバ装置において、所定のタイミングで前記クラ
   イアント装置から前記write 権の時刻トークンを回収
   し、自身が管理するファイル時刻を更新する、 過程を含むことを特徴とするノード間共用ファイル制御
   方法。
5. 【請求項５】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該クライ
   アント装置であって、 前記サーバ装置との間で、ファイル時刻を制御するため
   の時刻トークンを通信する通信手段と、 前記サーバ装置から複数の前記クライアント装置に同時
   に応答され得るトークンであって前記ファイル時刻の変
   更を許容するwrite 権の時刻トークンを前記サーバ装置
   から獲得した後は、前記サーバ装置にファイル時刻を問
   い合わせることなく、ファイルアクセスを実行するアク
   セス制御手段と、 を含むことを特徴とするクライアント装置。
6. 【請求項６】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該クライ
   アント装置であるコンピュータにより使用されたときに
   それによって読み出されるプログラムを記録した記録媒
   体であって、 前記サーバ装置との間で、ファイル時刻を制御するため
   の時刻トークンを通信する機能と、 前記サーバ装置から複数の前記クライアント装置に同時
   に応答され得るトークンであって前記ファイル時刻の変
   更を許容するwrite 権の時刻トークンを前記サーバ装置
   から獲得した後は、前記サーバ装置にファイル時刻を問
   い合わせることなく、ファイルアクセスを実行する機能
   と、 を前記コンピュータに行わせるためのプログラムを記録
   したコンピュータ読出し可能記録媒体。
7. 【請求項７】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該サーバ
   装置であって、 前記クライアント装置との間で、ファイル時刻を制御す
   るための時刻トークンを通信する通信手段と、 前記ファイル時刻の変更を許容するwrite 権の時刻トー
   クンを複数の前記クライアント装置に同時に応答する制
   御を実行する応答手段と、 所定のタイミングで前記クライアント装置から前記writ
   e 権の時刻トークンを回収し、自身が管理するファイル
   時刻を更新するファイル時刻更新手段と、 を含むことを特徴とするサーバ装置。
8. 【請求項８】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイルシステムを構成する当該サーバ
   装置であるコンピュータにより使用されたときにそれに
   よって読み出されるプログラムを記録した記録媒体であ
   って、 前記クライアント装置との間で、ファイル時刻を制御す
   るための時刻トークンを通信する機能と、 前記ファイル時刻の変更を許容するwrite 権の時刻トー
   クンを複数の前記クライアント装置に同時に応答する制
   御を実行する機能と、 所定のタイミングで前記クライアント装置から前記writ
   e 権の時刻トークンを回収し、自身が管理するファイル
   時刻を更新する機能と、 を前記コンピュータに行わせるためのプログラムを記録
   したコンピュータ読出し可能記録媒体。
9. 【請求項９】 ユーザプログラムからのファイル操作要
   求を受けて、１つのノード内のクライアント装置がそれ
   と同一の又は他のノード内のサーバ装置からトークンを
   獲得した上で該ファイル操作要求を処理することによ
   り、複数のノードからの同一ファイルの共用を可能とす
   るノード間共用ファイル制御方法であって、 前記クライアント装置と前記サーバ装置の間で、ファイ
   ルサイズの拡張を制御するためのサイズトークンを通信
   し、 前記クライアント装置において、ファイルの最終ブロッ
   クにアクセスする場合においてのみ、前記サーバ装置か
   ら該ファイルに対応するサイズトークンを獲得した上で
   該最終ブロックにアクセスする、 過程を含むことを特徴とするノード間共用ファイル制御
   方法。
10. 【請求項１０】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であって、 前記サーバ装置との間で、ファイルサイズの拡張を制御
    するためのサイズトークンを通信する通信手段と、 ファイルの最終ブロックにアクセスする場合においての
    み、前記サーバ装置から該ファイルに対応するサイズト
    ークンを獲得した上で該最終ブロックにアクセスするア
    クセス手段と、 を含むことを特徴とするクライアント装置。
11. 【請求項１１】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であるコンピュータにより使用されたときに
    それによって読み出されるプログラムを記録した記録媒
    体であって、 前記サーバ装置との間で、ファイルサイズの拡張を制御
    するためのサイズトークンを通信する機能と、 ファイルの最終ブロックにアクセスする場合においての
    み、前記サーバ装置から該ファイルに対応するサイズト
    ークンを獲得した上で該最終ブロックにアクセスする機
    能と、 を前記コンピュータに行わせるためのプログラムを記録
    したコンピュータ読出し可能記録媒体。
12. 【請求項１２】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイル制御方法であって、 前記クライアント装置と前記サーバ装置の間で、ファイ
    ルデータのアクセスを制御するためのデータトークンを
    通信し、 該データトークンの通信時に、該データトークンに対応
    するファイルのディスク上での位置を示すエクステント
    情報を通信する、 過程を含むことを特徴とするノード間共用ファイル制御
    方法。
13. 【請求項１３】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であって、 前記サーバ装置との間で、ファイルデータのアクセスを
    制御するためのデータトークンを通信する第１の通信手
    段と、 該データトークンの通信時に、該データトークンに対応
    するファイルのディスク上での位置を示すエクステント
    情報を通信する第２の通信手段と、 を含むことを特徴とするクライアント装置。
14. 【請求項１４】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であるコンピュータにより使用されたときに
    それによって読み出されるプログラムを記録した記録媒
    体であって、 前記サーバ装置との間で、ファイルデータのアクセスを
    制御するためのデータトークンを通信する機能と、 該データトークンの通信時に、該データトークンに対応
    するファイルのディスク上での位置を示すエクステント
    情報を通信する機能と、 を前記コンピュータに行わせるためのプログラムを記録
    したコンピュータ読出し可能記録媒体。
15. 【請求項１５】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該サーバ
    装置であって、 前記クライアント装置との間で、ファイルデータのアク
    セスを制御するためのデータトークンを通信する第１の
    通信手段と、 該データトークンの通信時に、該データトークンに対応
    するファイルのディスク上での位置を示すエクステント
    情報を通信する第２の通信手段と、 を含むことを特徴とするサーバ装置。
16. 【請求項１６】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該サーバ
    装置であるコンピュータにより使用されたときにそれに
    よって読み出されるプログラムを記録した記録媒体であ
    って、 前記クライアント装置との間で、ファイルデータのアク
    セスを制御するためのデータトークンを通信する機能
    と、 該データトークンの通信時に、該データトークンに対応
    するファイルのディスク上での位置を示すエクステント
    情報を通信する機能と、 を前記コンピュータに行わせるためのプログラムを記録
    したコンピュータ読出し可能記録媒体。
17. 【請求項１７】 請求項１、２、４、５、７、９、１
    ０、１２、１３、又は１５のいずれか１項に記載のノー
    ド間共用ファイルシステムにおいて前記サーバ装置が二
    重化される構成を有するノード間共用ファイル制御方法
    であって、 主系のサーバ装置においてファイル時刻が設定される際
    に、該ファイル時刻を従系のサーバ装置に送信し、 該従系のサーバ装置において、該ファイル時刻を設定す
    る、 過程を含むことを特徴とするノード間共用ファイル制御
    方法。
18. 【請求項１８】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイル制御方法であって、 前記サーバ装置において、複数のノードから共用される
    １つ以上のディスクボリューム毎に、空きディスク領域
    群、使用中ディスク領域群、及び前記各クライアント装
    置に対応するリザーブ中ディスク領域群を管理し、 前記クライアント装置において、前記サーバ装置に対し
    て、ディスク領域のリザーブを要求し、 該リザーブ要求に対して、前記サーバ装置において、前
    記空きディスク領域群からディスク領域をリザーブ中デ
    ィスク領域として確保し、それに関する情報を該リザー
    ブ要求を発行したクライアント装置に通知すると共に、
    該確保したリザーブ中ディスク領域を前記リザーブ要求
    を発行したクライアント装置に対応する前記リザーブ中
    ディスク領域群として管理し、 前記リザーブ要求を発行したクライアント装置におい
    て、該リザーブ要求に応答して前記サーバ装置から通知
    された情報に対応するリザーブ中ディスク領域をリザー
    ブ中ディスク領域群として管理し、 前記クライアント装置において、ユーザプログラムによ
    るファイルへのデータ書出し要求に伴って新たなディス
    ク領域を割り当てる必要が発生した場合に、該クライア
    ント装置が管理する前記リザーブ中ディスク領域群から
    最適なリザーブ中ディスク領域を選択し、そこに対して
    データ書出しを実行し、該リザーブ中ディスク領域を前
    記リザーブ中ディスク領域群としての管理からはずし、
    該データ書出しを実行したリザーブ中ディスク領域に関
    する情報を前記サーバ装置に通知し、 前記サーバ装置において、前記クライアント装置から通
    知された情報に対応する前記データ書出しが発生したリ
    ザーブ中ディスク領域を、該通知を行ったクライアント
    装置に対応する前記リザーブ中ディスク領域群としての
    管理からはずして前記使用中ディスク領域として管理す
    る、 過程を含むことを特徴とするノード間共用ファイル制御
    方法。
19. 【請求項１９】 請求項１８に記載の方法であって、 前記サーバ装置における前記空きディスク領域群及びリ
    ザーブ中ディスク領域群の管理と、前記クライアント装
    置における前記リザーブ中ディスク領域群の管理を、前
    記ディスク領域の複数のサイズ範囲毎に行う、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
20. 【請求項２０】 請求項１８に記載の方法であって、 前記クライアント装置において、前記ユーザプログラム
    によるファイルへのデータ書出し要求に伴って新たなデ
    ィスク領域を割り当てる必要が発生した場合に、該クラ
    イアント装置が管理する前記リザーブ中ディスク領域群
    から前記ファイルへのデータ書出しが既に行われている
    ディスク領域に連続するリザーブ中ディスク領域を選択
    し、該選択に失敗した場合には、前記サーバ装置に対し
    て、該連続するリザーブ中ディスク領域のリザーブ要求
    を発行する、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
21. 【請求項２１】 請求項１８に記載の方法であって、 前記サーバ装置において、前記クライアント装置の障害
    を監視し、その結果障害が検出されたクライアント装置
    に対応する前記リザーブ中ディスク領域群を、全て前記
    空きディスク領域群に変更する、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
22. 【請求項２２】 請求項１８に記載の方法であって、 前記クライアント装置において、それが管理する前記リ
    ザーブ中ディスク領域群中のディスク領域が所定量を下
    回ったときに、前記サーバ装置に対して、新たなディス
    ク領域のリザーブ要求を発行する、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
23. 【請求項２３】 請求項１８に記載の方法であって、 前記クライアント装置において、前記ユーザプログラム
    によるファイルへのデータ書出し要求に基づいて書き出
    されるデータを、主記憶上にキャッシュし、前記リザー
    ブ中ディスク領域の割り当てを遅延させる、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
24. 【請求項２４】 請求項１８に記載の方法であって、 前記クライアント装置において、前記データ書出しを実
    行したリザーブ中ディスク領域に関する情報の前記サー
    バ装置への通知は、前記ユーザプログラムがファイルを
    クローズし、又はキャッシュが一杯になり、或いは前記
    サーバ装置からデータトークンの回収を要求されるタイ
    ミングで行う、 過程を更に含むことを特徴とするノード間共用ファイル
    制御方法。
25. 【請求項２５】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であって、 前記サーバ装置に対して、ディスク領域のリザーブを要
    求するリザーブ要求手段と、 該リザーブ要求に応答して前記サーバ装置から通知され
    た情報に対応するリザーブ中ディスク領域をリザーブ中
    ディスク領域群として管理するリザーブ中ディスク領域
    群管理手段と、 ユーザプログラムによるファイルへのデータ書出し要求
    に伴って新たなディスク領域を割り当てる必要が発生し
    た場合に、前記リザーブ中ディスク領域群管理手段が管
    理する前記リザーブ中ディスク領域群から最適なリザー
    ブ中ディスク領域を選択し、そこに対してデータ書出し
    を実行し、前記リザーブ中ディスク領域群管理手段に対
    して該データ書出しを実行したリザーブ中ディスク領域
    の管理をはずさせ、該リザーブ中ディスク領域に関する
    情報を前記サーバ装置に通知するクライアント側データ
    書出し制御手段と、 を含むことを特徴とするクライアント装置。
26. 【請求項２６】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成する当該クライ
    アント装置であるコンピュータにより使用されたときに
    それによって読み出されるプログラムを記録した記録媒
    体であって、 前記サーバ装置に対して、ディスク領域のリザーブを要
    求する機能と、 該リザーブ要求に応答して前記サーバ装置から通知され
    た情報に対応するリザーブ中ディスク領域をリザーブ中
    ディスク領域群として管理する機能と、 ユーザプログラムによるファイルへのデータ書出し要求
    に伴って新たなディスク領域を割り当てる必要が発生し
    た場合に、自身が管理する前記リザーブ中ディスク領域
    群から最適なリザーブ中ディスク領域を選択し、そこに
    対してデータ書出しを実行し、該リザーブ中ディスク領
    域を前記リザーブ中ディスク領域群としての管理からは
    ずし、該データ書出しを実行したリザーブ中ディスク領
    域に関する情報を前記サーバ装置に通知する機能と、 を前記コンピュータに行わせるためのプログラムを記録
    したコンピュータ読出し可能記録媒体。
27. 【請求項２７】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成するサーバ装置
    であって、 複数のノードから共用される１つ以上のディスクボリュ
    ーム毎に、空きディスク領域群、使用中ディスク領域
    群、及び前記各クライアント装置に対応するリザーブ中
    ディスク領域群を管理するディスク領域管理手段と、 前記クライアント装置からのディスク領域のリザーブ要
    求に対して、前記空きディスク領域群からディスク領域
    をリザーブ中ディスク領域として確保し、それに関する
    情報を該リザーブ要求を発行したクライアント装置に通
    知すると共に、該確保したリザーブ中ディスク領域を前
    記リザーブ要求を発行したクライアント装置に対応する
    前記リザーブ中ディスク領域群として管理するリザーブ
    中ディスク領域確保手段と、 前記クライアント装置から通知された情報に対応するデ
    ータ書出しが発生したリザーブ中ディスク領域を、該通
    知を行ったクライアント装置に対応する前記リザーブ中
    ディスク領域群としての管理からはずして前記使用中デ
    ィスク領域として管理するサーバ側データ書出し制御手
    段と、 を含むことを特徴とするサーバ装置。
28. 【請求項２８】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイルシステムを構成するサーバ装置
    であるコンピュータにより使用されたときにそれによっ
    て読み出されるプログラムを記録した記録媒体であっ
    て、 複数のノードから共用される１つ以上のディスクボリュ
    ーム毎に、空きディスク領域群、使用中ディスク領域
    群、及び前記各クライアント装置に対応するリザーブ中
    ディスク領域群を管理する機能と、 前記クライアント装置からのディスク領域のリザーブ要
    求に対して、前記空きディスク領域群からディスク領域
    をリザーブ中ディスク領域として確保し、それに関する
    情報を該リザーブ要求を発行したクライアント装置に通
    知すると共に、該確保したリザーブ中ディスク領域を前
    記リザーブ要求を発行したクライアント装置に対応する
    前記リザーブ中ディスク領域群として管理する機能と、 前記クライアント装置から通知された情報に対応するデ
    ータ書出しが発生したリザーブ中ディスク領域を、該通
    知を行ったクライアント装置に対応する前記リザーブ中
    ディスク領域群としての管理からはずして前記使用中デ
    ィスク領域として管理する機能と、 を前記コンピュータに行わせるためのプログラムを記録
    したコンピュータ読出し可能記録媒体。
29. 【請求項２９】 ユーザプログラムからのファイル操作
    要求を受けて、１つのノード内のクライアント装置がそ
    れと同一の又は他のノード内のサーバ装置からトークン
    を獲得した上で該ファイル操作要求を処理することによ
    り、複数のノードからの同一ファイルの共用を可能とす
    るノード間共用ファイル制御方法であって、 前記サーバ装置において、前記クライアント装置からの
    トークン回収完了メッセージの受信時に、該メッセージ
    に対応するトークン回収の契機となった要求を処理して
    いる実行単位が保持していたファイルロックを継承して
    処理を実行することによりデッドロックを回避する過程
    を含む、 ことを特徴とするノード間共用ファイル制御方法。
30. 【請求項３０】 請求項２９に記載の方法であって、 前記ロックの継承を行える実行単位を１つに制限する過
    程を更に含む、 ことを特徴とするノード間共用ファイル制御方法。
31. 【請求項３１】 請求項２９に記載の方法であって、 前記トークン回収の待ち状態を資源として記憶し、他の
    資源の獲得待ち状態との関係から、デッドロック状態を
    自動的に検出する過程を更に含む、 ことを特徴とするノード間共用ファイル制御方法。
32. 【請求項３２】請求項３１に記載の方法であって、 前記デッドロック状態が検出され該状態の原因となって
    いるトランザクションがキャンセルさせられる際に、更
    新されたキャッシュデータの無効化と共に、主記憶装置
    に常駐されている関連制御表の再設定を行う過程を更に
    含む、 ことを特徴とするノード間共用ファイル制御方法。
33. 【請求項３３】 請求項２９に記載の方法であって、 デッドロック状態の発生に備え、ファイル又はディスク
    に関する属性情報を保持するメタデータの更新をキャッ
    シュ上でのみ行い、ディスクへの書き込みが、要求され
    た処理の完了まで遅延させられるトランザクション制御
    において、 キャッシュデータの更新時に更新されたキャッシュ位置
    を記録する過程と、 トランザクションの完了時に、前記記録から必要最小限
    の変更データのみをログファイルに書き出すことにより
    ログデータ量を削減する過程と、 を含むことを特徴とするノード間共用ファイル制御方
    法。
34. 【請求項３４】 請求項３３に記載の方法であって、 更新されたキャッシュ位置を記録する際に、該記録と先
    行する記録とをマージすることにより、ログファイルに
    書き出すログデータ量を最小化する過程を更に含む、 ことを特徴とするノード間共用ファイル制御方法。
35. 【請求項３５】 請求項３３に記載の方法であって、 前記キャッシュは２次キャッシュを含む、 ことを特徴とするノード間共用ファイル制御方法。