(57)【特許請求の範囲】
【請求項１】
複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおけるファイルシステム制御方法であって，
各クライアントノードは，
自クライアントノードで動作する並列プログラムからの前記ファイルに対するアクセス要求を処理し，前記ファイルに対するリード要求に対してはリードデータを自ノード内にバッファリングし，前記ファイルに対するライト要求に対してはライトデータの変更部分だけを自ノード内にバッファリングし，
自クライアントノードで動作する並列プログラムから，ライト要求とは異なるタイミングの，更新データについてのコンシステンシの保証が必要なタイミングで発行されたプロパゲート要求を受けて，前記サーバノードへファイル更新通知を行うとともに，前記サーバノードからのデータの無効化指示により自バッファ内の該当データを無効化する
ことを特徴とするファイルシステム制御方法。
【請求項２】
複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおいて，
前記クライアントノードは，
前記ファイルがストライプ配置されたサーバノード単位に用意される複数のバッファを管理する手段と，
自クライアントノードで動作する並列プログラムからの前記ファイルに対するアクセス要求を処理し，前記ファイルに対するリード要求に対してはリードデータを自ノード内にバッファリングし，前記ファイルに対するライト要求に対してはライトデータの変更部分だけを自ノード内にバッファリングする手段と，
自クライアントノードで動作する並列プログラムから，ライト要求とは異なるタイミングの，更新データについてのコンシステンシの保証が必要なタイミングで発行されたプロパゲート要求を受けて，前記サーバノードへファイル更新通知を行うとともに，前記サーバノードからのデータの無効化指示により自バッファ内の該当データを無効化する手段と，
を有するファイルシステムクライアント部を備え，
前記サーバノードは，
前記クライアントノードからの要求によりファイルに対するアクセスを処理する手段と，
前記クライアントノードからのファイル更新通知により，該当するデータを保持する他のクライアントノードへそのデータの無効化を指示する手段と，
を有するファイルシステムサーバ部を備える
ことを特徴とするパラレルファイルシステム。
【請求項３】
複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおける，各クライアントノードで動作するプログラムを格納したコンピュータ読み取り可能なプログラム記憶媒体であって，
前記ファイルがストライプ配置されたサーバノード単位に用意される複数のバッファを管理する手段と，
自クライアントノードで動作する並列プログラムからの前記ファイルに対するアクセス要求を処理し，前記ファイルに対するリード要求に対してはリードデータを自ノード内にバッファリングし，前記ファイルに対するライト要求に対してはライトデータの変更部分だけを自ノード内にバッファリングする手段と，
自クライアントノードで動作する並列プログラムから，ライト要求とは異なるタイミングの，更新データについてのコンシステンシの保証が必要なタイミングで発行されたプロパゲート要求を受けて，前記サーバノードへファイル更新通知を行うとともに，前記サーバノードからのデータの無効化指示により自バッファ内の該当データを無効化する手段として，
コンピュータを機能させるためのプログラムを格納した
ことを特徴とするプログラム記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，複数の計算機を高速の接続網で接続した並列計算機上で動作する並列プログラム向けファイルシステム（パラレルファイルシステム）の性能を向上させることができるようにしたファイルシステム制御方法，そのパラレルファイルシステムおよびそれを実現するためのプログラム記憶媒体に関する。
【０００２】
【従来の技術】
ユーザプログラムが動作する複数の計算機（これをクライアントノードという）から，ネットワークを介して他のＩ／Ｏノードである計算機（これをサーバノードという）上のファイルをアクセスする際の高速化手法として，クライアント側にキャッシュを持ち，クライアント・サーバ間を流れるデータ量の最小化を図るクライアントキャッシュ方式がよく知られている。
【０００３】
しかし，クライアントキャッシュ方式においては，複数のノードが同一のファイルを同時に更新する，いわゆるライトシェア（ｗｒｉｔｅ  ｓｈａｒｅ）が一般的であるような環境下では，クライアントキャッシュの使用権の獲得制御やキャッシュデータの無効化処理に伴うオーバヘッドが増大するという問題がある。
【０００４】
この問題を解決する方法として，ユーザプログラムからリード（ｒｅａｄ）／ライト（ｗｒｉｔｅ）要求が発行される度にサーバノードと通信を行うクライアントキャッシュレス方式もよく採用されている。しかし，クライアントキャッシュレス方式においては，ユーザプログラムが発行するリード／ライトのデータ長が小さいと，通信オーバヘッドが急激に増大し，かつＩ／Ｏノードストライピングの効果を発揮できなくなるという欠点がある。
【０００５】
クライアントキャッシュレス方式のもとでユーザプログラムが発行するリード／ライトのデータ長を大きくする手法として，ストライドアクセスインタフェースが提案されている。ストライドアクセスインタフェースは，ファイルに対する離散シーケンシャルアクセスのパターンを宣言することにより，複数のファイル区画に対するアクセスを一回のリード／ライト要求で処理するものである。すなわち，ストライドアクセスでは，例えばあるファイルの１０００バイト目から２００バイト，２０００バイト目から２００バイト，３０００バイト目から２００バイト，…というような飛び飛びのデータをアクセスする場合に，アクセス対象データの配置パターンを宣言することによって，一回のリード／ライト要求で処理する。
【０００６】
ストライドアクセスインタフェースは，個々にリード／ライト要求を発行する場合に比べて，ファイルシステムによる最適化が可能であり，ネットワークの使用効率を高めることができる。
【０００７】
一方，パラレルファイルシステムの重要な構成要素であるディスク記憶装置（以下，ディスクという）は，シーケンシャルにアクセスされた時に最高の性能を発揮することができ，ランダムにアクセスされるとシーク時間や回転待ち時間のため大幅に性能が劣化するという特性を持つ。この特性を利用し，複数のクライアントノードから発行された互いに関連することを宣言されたストライドアクセスインタフェースの要求をまとめて評価し，ディスクアクセスをシーケンシャルなものに変換する手法としてコレクティブＩ／Ｏが知られている。
【０００８】
コレクティブＩ／Ｏでは，サーバノードは，ディスクアクセスとデータ転送のスケジューリングを行い，関連する全クライアントノードのアクセス要求を合体して入出力（Ｉ／Ｏ）を実行することにより，ディスクアクセスおよび転送時間の最小化を図る。
【０００９】
【発明が解決しようとする課題】
ストライドアクセスインタフェースやコレクティブＩ／Ｏの技法は，並列プログラムの入出力を大幅に向上させる技法ではあるが，従来，並列プログラムを作成する前提となっていた，例えばＵＮＩＸシステムなどの既存のファイルアクセスインタフェースとは大きく異なること，またユーザプログラムが大きなＩ／Ｏバッファを用意しないと効果がないことなどから，既存のプログラムの大幅修正が必要となるという欠点がある。
【００１０】
また，クライアントキャッシュ方式は，データ長の小さいリード／ライト要求を効率よく処理でき，しかも既存のプログラムを無修正で使える利点があるが，キャッシュコンシステンシを保証するためのオーバヘッドが大きいという欠点がある。
【００１１】
本発明は上記問題点の解決を図り，既存のプログラムを大幅に変更することなく，パラレルファイルシステムの性能を向上させる手段を提供することを目的とする。
【００１２】
【課題を解決するための手段】
本発明は，複数のノードがネットワークを介してファイルを共用するネットワークファイルシステムにおいて，ファイルを使用するプログラムからの要求によりファイルの更新を他のノードに伝えるファイル更新通知機構を持ち，各ノードは，ファイルに対するリードデータまたはライトデータを自ノード内にバッファリングし，あるノードにおいてファイルを使用するプログラムは，ファイルの更新データに関するコンシステンシが必要なときに，前記ファイル更新通知機構を呼び出し，ファイル更新通知機構によって各ノードがバッファに保持する該当データを無効化することを特徴とする。
【００１３】
各ノードにおけるバッファリングは実際にライトしたデータのみに対して行われるので，キャッシュ制御の場合のように同一キャッシュラインを複数ノードが同時に更新するのを避けるために行われる排他制御が不要である。このため，各ノードが完全に並列に動作できる。しかも変更部分だけを保持することにより，各ノードからの要求によりＩ／Ｏを実行するノードで複数のライト要求をマージしてもファイルが破壊されることもない。したがって，一つのファイルを複数のノードが同時に更新する場合にも，ファイルを破壊することなく高速に処理することができる。
【００１４】
特に，ファイルのライトシェアを行う既存の並列プログラムは，ファイルオープン時に本制御を有効にすることを宣言し，ファイルの更新が起こったことを他ノードに通知している個所にファイル更新通知機構をコール（ｐｒｏｐａｇａｔｅ）  するステートメントを追加するだけの変更で対処することができる。したがって，既存の並列プログラムに最小限の変更を加えるだけで，高性能化することが可能になる。
【００１５】
上記システムに関連する技術として，次のようなシステムを用いることもできる。複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおいて，各クライアントノードは，ユーザプログラムの発行したライト要求のデータを一旦バッファに蓄積し，バッファが一杯になった時点またはバッファ内のデータが所定量以上になった時点で一括して複数のサーバノードへ送り出し，ユーザプログラムの発行したリード要求に対しては，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対してバッファ内のデータで解決する（先読みしたバッファ内のデータをユーザバッファへコピーする）。
【００１６】
この関連技術では，データ長の小さなライト要求を多用するユーザプログラムの場合でも，データが一旦バッファに蓄えられ，バッファが一杯となったところで複数のサーバノードへデータが並列に送られるので，データ長の大小にかかわらずＩ／Ｏノードストライピングの効果を発揮することができる。データ長が小さいリード要求が多発する環境でも全サーバノードからバッファ分のデータが一括して先読みされるので，データ長の大小にかかわらずサーバノード数に比例した性能を発揮することができる。
【００１７】
さらに，各クライアントノードは，前記バッファをファイルがストライプ配置されたサーバノード単位に複数用意し，ユーザプログラムの発行したライト要求のデータにより一つのバッファが一杯になったときに，他のバッファに所定量以上のデータが蓄積されていれば同時に複数のサーバノードへデータを送り出すようにする。
【００１８】
これにより，バッファをサーバノードとの間の通信バッファとしてそのまま使うことができ，例えばユーザバッファからシステムバッファへのコピー，システムバッファから転送用バッファへのコピーというような無駄なメモリコピーを削減できる。また，一つのバッファが一杯になった時に他のノード用バッファ中のデータを同時に送り出すので，データ長がストライプ幅に比べて小さいリード／ライト要求が多い環境下でも，サーバノード数に比例した高い性能を実現できる。
【００１９】
また，上記システムに関連する技術として，次のようなシステムを用いることもできる。複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，クライアントノードから直前のアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアントノードからの要求が到着していないかをチェックし，アクセスが記憶媒体のアドレスの昇順になるように要求の処理順序を並べ替えてＩ／Ｏを実行する。
【００２０】
クライアントノード上で動くユーザプログラムがファイルをアドレスの昇順に不連続にアクセスした場合にも，複数のクライアントからの要求を評価し，ディスクアクセスが連続シークエンシャルになるように要求の処理順を並べ替えることにより，ファイルが格納されたディスクの無駄な回転待ちやシーク時間が不要となり，高性能を発揮することができる。
【００２１】
また，上記システムに関連する技術として，次のようなシステムを用いることもできる。複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，アクセス要求を記憶媒体のアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとの切り替え手段を持ち，各クライアントノードから発行されたアクセス要求が，記憶媒体のアドレスの昇順であるかどうかをクライアントノード単位に監視し，非シーケンシャルモードのときに，記憶媒体のアドレスの昇順にアクセスする要求がすべてのクライアントノードから所定の回数以上続くとシーケンシャルモードへ遷移し，シーケンシャルモードのときに，前記いずれかのクライアントノードから記憶媒体のアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ遷移する。
【００２２】
このようにシーケンシャルモードと非シーケンシャルモードの自動切り替えを行うことにより，複数のアクセス要求に対する連続的なアクセスを効率的に行うとともに，連続的なアクセスとならないようなケースについて要求の無駄な待ち時間や並べ替えの時間を削減することができる。
【００２３】
以上の処理を実現するためのクライアントノードまたはサーバノードで動作させるプログラムは，計算機が読み取り可能な適当な記憶媒体に格納することができる。
【００２４】
【発明の実施の形態】
図１は，本発明の構成例を示すブロック構成図である。
【００２５】
図１において，１Ａ〜１Ｃは並列プログラムを実行する計算機であるコンピュートノード，２は各コンピュートノード１Ａ〜１Ｃで並列に動作するユーザプログラム（並列プログラム），３は並列プログラムから発行されるＩ／Ｏ要求を受け付けるファイルシステムクライアント部，４Ａ〜４ＣはＩ／Ｏノード単位に用意されるバッファ，５Ａ〜５Ｃはファイルへの入出力を行うＩ／Ｏノード，６はディスクが配置されたＩ／Ｏノード上でファイルシステムクライアント部３からの要求に従い実際にディスクをアクセスするファイルシステムサーバ部，７Ａ〜７Ｃはファイルを格納するディスク，８はディスク７Ａ〜７Ｃにデータがストライプ配置された（所定の大きさで分割して配置された）ファイルを表す。
【００２６】
コンピュートノード１Ａ〜１Ｃはクライアントノード，Ｉ／Ｏノード５Ａ〜５Ｃはサーバノードであり，高速の接続網で接続されている。この例では，３台のコンピュートノード１Ａ〜１Ｃが示されているが，複数台であれば何台でもよい。また，３台のＩ／Ｏノード５Ａ〜５Ｃが示されているが任意の台数でよい。
【００２７】
各コンピュートノード１Ａ〜１Ｃでは，それぞれ並列プログラムとして構成されるユーザプログラム２とファイルシステムクライアント部３とが動作し，各Ｉ／Ｏノード５Ａ〜５Ｃでは，ファイルシステムサーバ部６が動作する。ファイルシステムクライアント部３は，例えばプログラムライブラリの形で提供され，ユーザプログラム２と結合編集される。もちろん，ファイルシステムクライアント部３をオペレーティング・システムの一部として，ユーザプログラム２とは独立に組み込んでもよい。
【００２８】
ファイルシステムクライアント部３は，ユーザプログラム２からの要求によりファイル８のオープン処理を行うオープン部３１，リード要求を処理するリード部３２，ライト要求を処理するライト部３３，ファイル８をクローズするクローズ部３４，ファイル更新通知部３５，Ｉ／Ｏノード毎のバッファ管理部３６を持つ。
【００２９】
また，ファイルシステムサーバ部６は，ある一つのコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５からの通知により該当する他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５へ更新データの無効化を指示するデータ無効化指示部６１と，各ディスク７Ａ〜７Ｃに対するアクセス要求をアドレスの昇順に並べ替える要求アクセス並べ替え部６２と，アクセスに関するシーケンシャルモードと非シーケンシャルモードとを切り替えるモード切り替え部６３とを持つ。
【００３０】
ファイルシステムクライアント部３において，Ｉ／Ｏノード毎のバッファ管理部３６は，ファイル単位に各Ｉ／Ｏノード５Ａ〜５Ｃに対応したバッファ４Ａ〜４Ｃを管理する。
【００３１】
ファイルシステムクライアント部３は，ユーザプログラム２からファイル更新通知部３５が呼ばれる（ｐｒｏｐａｇａｔｅ  される）まで，ファイル更新データを自ノード内のバッファ４Ａ〜４Ｃにバッファリングし，ファイル更新通知部３５が呼ばれたら，ファイルの更新をファイルシステムサーバ部６へ通知する。ファイルシステムサーバ部６では，ファイル更新通知があると，他のコンピュートノード１Ａ〜１Ｃが先読みしているデータをチェックし，必要ならデータ無効化指示部６１によりファイルの更新に伴うデータの無効化を他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５に指示する。その通知を受けたファイル更新通知部３５は，バッファ４Ａ〜４Ｃの該当データを無効化する。
【００３２】
リード部３２は，ユーザプログラム２の発行したリード要求に対して，要求されたデータとともに後続するデータを，複数のＩ／Ｏノード５Ａ〜５Ｃからバッファ４Ａ〜４Ｃに一括して先読みし，後続のリード要求に対しては，バッファ４Ａ〜４Ｃ内のデータをユーザプログラム２内のユーザバッファへコピーする。
【００３３】
ライト部３３は，ユーザプログラム２の発行したライト要求のデータを一旦バッファ４Ａ〜４Ｃに蓄積し，バッファ４Ａ〜４Ｃが一杯になった時点で一括してＩ／Ｏノード５Ａ〜５Ｃに送り出す。
【００３４】
ファイルシステムサーバ部６の要求アクセス並べ替え部６２は，直前のディスクアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアント（コンピュートノード）からの要求が到着していないかどうかをチェックし，到着していれば，ディスクアクセスがアドレスの昇順となるように要求を並べ替え，その順にＩ／Ｏ処理を実行する。
【００３５】
ファイルシステムサーバ部６は，要求アクセス並べ替え部６２によってファイルシステムクライアント部３からのアクセス要求を各ディスク７Ａ〜７Ｃのアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとを切り替えるモード切り替え部６３を持つ。モード切り替え部６３は，ファイルシステムクライアント部３から発行されたアクセス要求が，ディスク７Ａ〜７Ｃのアドレスの昇順であるかどうかを，コンピュートノード単位に監視し，ディスク７Ａ〜７Ｃのアドレスの昇順にアクセスする要求がすべてのコンピュートノード１Ａ〜１Ｃから所定の回数以上続くと，シーケンシャルモードへ移行させ，いずれかのコンピュートノード１Ａ〜１Ｃからディスク７Ａ〜７Ｃのアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ移行させる。
【００３６】
ユーザプログラム２は，ファイルシステムクライアント部３に対するオープン要求において，以上の機能を利用するかしないかを宣言することができる。以上の機能を利用しないことを宣言すれば，従来と同様なファイルアクセス制御が行われる。ファイルのライトシェアを行う既存の並列プログラム（ユーザプログラム２）は，ファイルオープン時に本発明の機能を有効にすることを宣言し，ファイルの更新が起こったことを他ノードに通知している個所に，ファイル更新通知部３５をコール（ｐｒｏｐａｇａｔｅ）するステートメントを追加するだけで，大きく変更することなく本機能を利用することができる。逐次プログラムの場合には，ファイルシステムクライアント部３が自動的に本機能を有効にする。
【００３７】
従来のファイルのライトシェアを行う並列プログラムには，データのコンシステンシを保証するための論理が必ず組み込まれている。図２は，ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。プロセス２Ａ（ｐｒｏｃｅｓｓ１）とプロセス２Ｂ（ｐｒｏｃｅｓｓ２）は，並列プログラムを構成するサブプログラムであり，異なるコンピュートノード１Ａ，１Ｂ上で動く。プロセス２Ａは，ファイル８の準備が整ったことを他コンピュートノード１Ｂ上のプロセス２Ｂにメッセージを送ることにより通知している。
【００３８】
すなわち，ライトシェアを行う並列プログラムでは，ファイルを更新したことを他のコンピュートノードで動く並列プログラムに通知する処理（ｎｏｔｉｆｙ  ｎｏｄｅＢ）がプログラムに必ず含まれているはずであり，タイミング依存のシーケンシャルコンシステンシだけに頼っている訳はない。
【００３９】
したがって，ライト結果を他のノードに反映するためのステートメントを既存のプログラムに追加するのは極めて容易である。この他に必要となるプログラム変更は，ファイルをオープンするステートメントに本機能を利用することを示すパラメータを追加するだけである。
【００４０】
このように，本発明による並列ファイルアクセスに関する高性能化をユーザプログラムが享受するのに，既存の並列プログラムを若干修正するだけでよく，論理自体を変更する必要がない。逐次プログラムの場合には，システムが自動的に本機能を有効にすることにより，既存プログラムを修正しなくても，リード／ライト要求長にかかわらずコンスタントな高性能を得ることができる。
【００４１】
以下，本発明の実施の形態についてさらに詳しく説明する。
【００４２】
〔１〕バッファの確保
ファイルシステムクライアント部３は，ファイルのオープン要求で，本発明の方式を有効化することをユーザプログラム２から通知されると，使用するＩ／Ｏノード５Ａ〜５Ｃを決め，その数分のバッファ４Ａ〜４Ｃを初期化する。
【００４３】
リード／ライト要求がユーザプログラム２から発行されると，ファイルシステムクライアント部３のリード部３２またはライト部３３が動作し，Ｉ／Ｏノード毎のバッファ４Ａ〜４Ｃを使って要求を処理する。以後このバッファ４Ａ〜４Ｃのことをコヒーレントバッファと呼ぶ。
【００４４】
〔２〕コヒーレントバッファの構造
図３は，コヒーレントバッファの構成例を示す図である。
【００４５】
コヒーレントバッファ４０は，図３に示すように，バッファ中のデータを管理する制御部４１と，実際のデータが入るデータ部４２からなる。制御部４１は，バッファの最下部から最上部に拡張する形をとり，データ部４２は逆にバッファの最上部から最下部の方向に広がる構造となっている。
【００４６】
制御部４１は，制御レコード（コントロールエレメント）の集合からなり，一つの制御レコードが一つのＩ／Ｏノードに対する一つのディスクアクセス要求（ライト要求）を表す。制御部４１のｉ番目の制御レコードには，データ部４２のｉ番目のデータエレメントに格納されるデータのディスクアドレスとデータ長とが格納される。
【００４７】
ユーザが要求したＩ／Ｏ要求が，最後の制御レコードで表わされるディスクアクセス要求と連続したものでない場合には，制御部４１を上方向へ拡張して新たに制御レコードを作り，この中に新しいディスクアクセス要求に関するディスクアドレスとデータ長の情報を格納する。最後の制御レコードで表わされるディスクアクセス要求とディスクアドレスが連続している場合には，最後の制御レコードのデータ長に新しいＩ／Ｏ要求のデータ長を加え，最後の制御レコードを更新して一つのＩ／Ｏ要求にまとめる。
【００４８】
〔３〕ライト（ｗｒｉｔｅ）時の処理
図４は，ライト要求時のバッファへのデータ設定例を示す。図４を用いて，ユーザプログラム２が発行したライト要求がバッファとの関係でどう処理されるかを説明する。
【００４９】
ユーザプログラム２がライトするデータを格納したユーザバッファ２０を指定してライト要求を発行すると，ファイルシステムクライアント部３内のライト部３３が制御を受け取る。ライト部３３は，ライト要求で指定されたユーザバッファ２０中のデータを，予め指定されたＩ／Ｏノードストライピングの指定に従い，各Ｉ／Ｏノード５Ａ〜５Ｃごとのデータに分割し，対応するコヒーレントバッファ４０Ａ〜４０Ｃに入れていく。この例では，ユーザバッファ２０の中のデータのうち，ｄａｔａ１がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに，ｄａｔａ２がＩ／ＯノードＢ用のコヒーレントバッファ４０Ｂに，ｄａｔａ３がＩ／ＯノードＣ用のコヒーレントバッファ４０Ｃに，ｄａｔａ４がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに順に設定されている。
【００５０】
コヒーレントバッファ４０Ａ〜４０Ｃが一杯になると，その内容を対応するＩ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６に送り，応答を待つ。
【００５１】
ファイルシステムサーバ部６から応答を受けると，対応するコヒーレントバッファ４０Ａ〜４０Ｃの先頭から次のデータを埋めていく。したがって，短いデータ長のライト要求では，ユーザバッファ２０からコヒーレントバッファ４０Ａ〜４０Ｃにデータを移動するだけで，ファイルシステムサーバ部６との会話はコヒーレントバッファ４０Ａ〜４０Ｃが一杯になるまで遅らされる。
【００５２】
ライト要求で指定されたデータ長が十分大きければ，一回の要求ですべてのコヒーレントバッファが一杯になり，全Ｉ／Ｏノード５Ａ〜５Ｃを並列に動かすことができる。
【００５３】
しかし，ライト要求のデータ長がコヒーレントバッファ長に比べて小さい場合には，一つのバッファだけが一杯になり，結果として一つのＩ／Ｏノードとだけ会話することになる可能性がある。これでは，複数のＩ／Ｏノード５Ａ〜５Ｃ配下のディスク７Ａ〜７Ｃを並列に動かすことができず，Ｉ／Ｏノードストライピングの効果を十分に発揮することができない。
【００５４】
そこで，短いデータ長のライト要求が多い環境でも，Ｉ／Ｏノードストライピングの効果が発揮できるよう，１つのコヒーレントバッファが一杯になったときに他のＩ／Ｏノード用のコヒーレントバッファの状態も調べ，所定量以上（例えばバッファの半分以上）データが詰まっている場合には，同時にそのバッファに対応するＩ／Ｏノードにもデータを送るようにする。
【００５５】
図５は，バッファフルでのライト要求時の並列転送の例を示している。図５を用いて，ユーザプログラム２がライト要求を発行した結果，コヒーレントバッファ４０Ａが一杯になった場合の処理を説明する。
【００５６】
ユーザプログラム２から，ストライプ４−１のデータのライト要求があったとする。このデータにより，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａだけが一杯になる。本来であれば，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａのデータだけをファイルシステムサーバ部６へ送り出せば，ライト要求の目的は達成される。しかし，Ｉ／Ｏノード５Ａ〜５Ｃにおけるディスクアクセスの並列動作の観点からは効率上望ましくない。そこで，他のコヒーレントバッファ４０Ｂ，４０Ｃにはまだ余裕があっても，データが半分以上詰まっている場合には，コヒーレントバッファ４０Ａ〜４０Ｃのデータを同時にファイルシステムサーバ部６へ送り出す。
【００５７】
この制御により，データ長が小さいライト要求が多いプログラムでも，ストライピング数に比例した並列動作による高速のＩ／Ｏを実現できる。各Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，転送されたバッファの内容を調べ，必要なディスクアクセスを行う。
【００５８】
アクセスするディスクアドレスが連続する連続アクセス要求の場合には，クライアント側，すなわちコンピュートノード１Ａ〜１Ｃ側で複数の要求が一つにまとめられるので，ファイルシステムサーバ部６に送られる制御レコードは一つとなり，ファイルシステムサーバ部６はディスクアクセス要求をローカルのファイルシステムに対して一回発行するだけでよい。
【００５９】
アクセスアドレスが連続していないような離散アクセスの場合には，ユーザが発行したライト要求毎に制御レコードが作られ，ファイルシステムサーバ部６に複数のディスクアクセス要求が伝えられる。この場合，ファイルシステムサーバ部６は受信したデータ中に格納されている複数のライト要求を順に取り出して処理する。
【００６０】
〔４〕リード（ｒｅａｄ）処理
リード（ｒｅａｄ）要求は，ファイルシステムクライアント部３内のリード部３２で処理される。リード処理においては，コヒーレントバッファ４０Ａ〜４０Ｃは先読みバッファの役割を果たす。リード部３２は，コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータが既に入っているなら，コヒーレントバッファ４０Ａ〜４０Ｃからユーザバッファ２０にデータをコピーする。この場合，Ｉ／Ｏノード５Ａ〜５Ｃとの間の通信は発生しない。
【００６１】
コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータがなければ，直前の要求と今回のリード要求の関係から先読みを行うかどうかを決める。同じＩ／Ｏノードに対する直前の要求もリード要求で，かつ今回の要求の開始ディスクアドレスと直前の要求の転送終了ディスクアドレスとの差が所定量以下（例えばコヒーレントバッファ長の半分以下）なら，コヒーレントバッファにバッファ分だけ，先読みをする。
【００６２】
バッファサイズの半分以上アクセスアドレスが離れている場合には，バッファサイズ分先読みするオーバヘッドが，次回のアクセスでバッファ上でヒットすることで得られる効果を相殺してしまうと判断し，先読みは行わない。
【００６３】
図６は，リード要求時のバッファへの同時読み込みの例を示している。図６を用いて，ユーザプログラム２がリード要求を発行してバッファ中のデータを使い切ったときの処理を説明する。
【００６４】
データ長が小さいリード要求が多い環境でも，Ｉ／Ｏノードストライピングの効果を発揮するため，コヒーレントバッファへの先読みが必要となった時には他のコヒーレントバッファの使用状況を調べ，そのバッファ中の所定量以上（例えば半分以上）のデータが既にユーザに送られているなら，そのバッファに対しても並行して先読みを起動する。
【００６５】
例えば，図６に示すように，コヒーレントバッファ４０Ａ〜４０Ｃには，それぞれストライプ３−１の一部，ストライプ３−２の一部，ストライプ３−３の一部が先読みされていて，バッファ中の他のデータは，ユーザプログラム２からのリード要求により既にユーザバッファ２０へ転送されているものとする。この状態でユーザプログラム２からストライプ３−１のリード要求があったとする。このリード要求を満たすにはＩ／ＯノードＡ用のコヒーレントバッファ４０Ａだけにデータを読み込めばいいが，他のコヒーレントバッファ４０Ｂ，４０Ｃ中のデータも大部分が使われているので，同時にＩ／ＯノードＢ，Ｃ用のコヒーレントバッファ４０Ｂ，４０Ｃにもデータを読み込む。ただし，既にバッファ中にあるデータを再度読み込むことはない。
【００６６】
なお，リード要求の対象となったＩ／Ｏノード用のコヒーレントバッファにライトデータが残っていた場合には，そのＩ／Ｏノードへコヒーレントバッファの内容を送り，ファイルに変更を反映する。
【００６７】
〔５〕プロパゲート（ｐｒｏｐａｇａｔｅ）処理
ユーザプログラム２が発行したプロパゲート（ｐｒｏｐａｇａｔｅ）要求はファイルシステムクライアント部３内のファイル更新通知部３５で処理される。
【００６８】
図７はバッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図であり，図８はプロパゲート処理を説明する図である。
【００６９】
以下，図７に示す（ａ）  〜（ｅ）  に従って動作を説明する。
【００７０】
（ａ）  コンピュートノード１Ｂ上で動作するユーザプログラム２は，ファイルシステムサーバ部６に対してｄａｔａ１のリード要求を行う。このとき，ｄａｔａ１の内容とともにｄａｔａ２およびｄａｔａ３が先読み（ｒｅａｄ  ａｈｅａｄ）される。
【００７１】
（ｂ）  コンピュートノード１Ａ上で動作するユーザプログラム２は，ｄａｔａ３，ｄａｔａ４，ｄａｔａ５とライト要求を出してデータを書き直しているが，コンピュートノード１Ｂ上のユーザプログラム２は気づかずに動作する。
【００７２】
（ｃ）  コンピュートノード１Ａ上のコヒーレントバッファ４０が一杯になると，コンピュートノード１Ａからファイルシステムサーバ部６への実際のライト要求が行われ，コヒーレントバッファ４０の内容が一括転送される。
【００７３】
（ｄ）  コンピュートノード１Ａ上のユーザプログラム２は，更新データについてのコンシステンシの保証が必要なタイミングでプロパゲート要求を発行する。この要求は，ファイル更新通知部３５を介してファイルシステムサーバ部６へ通知される。
【００７４】
（ｅ）  ファイルシステムサーバ部６では，プロパゲート要求を受け取ると，他のコンピュートノード１Ｂのコヒーレントバッファ４０に先読みされているデータをチェックし，無効化が必要なデータ（ｄａｔａ３）を見つけ出し，コンピュートノード１Ｂにそのデータの無効化を指示する。これにより，コンピュートノード１Ｂ上のバッファが無効化され，以降，必要であれば実際のリード要求の処理によりコンピュートノード１Ｂのユーザプログラム２に正しいデータが伝わる。
【００７５】
なお，上記の処理において，ユーザプログラム２からプロパゲート要求が出されると，コヒーレントバッファ４０内のデータは，バッファが一杯になっていなくても，プロパゲートの指示とともにファイルシステムサーバ部６へ転送され，該当するディスク７への書き出しが行われる。
【００７６】
このプロパゲート処理を，図８の（ａ）  〜（ｆ）  に従ってさらに詳しく説明すると，以下のとおりである。
【００７７】
（ａ）  図８に示すように，ユーザプログラム２からライトデータのコンシステンシの保証が必要なときにプロパゲート（ｐｒｏｐａｇａｔｅ）要求があると，そのユーザプログラム２が動作するコンピュートノード１Ａのファイルシステムクライアント部３Ａにあるファイル更新通知部３５Ａに通知される。
【００７８】
（ｂ）  ファイル更新通知部３５Ａは，まずコヒーレントバッファ４０Ａに残っているライトデータにプロパゲート指示を付加して，Ｉ／Ｏノード上のファイルシステムサーバ部６へ送る。ファイルシステムサーバ部６は，受け取ったライトデータをディスク７に反映する。
【００７９】
（ｃ）  続いて，ファイルシステムサーバ部６のデータ無効化指示部６１は，コヒーレントバッファにデータを先読みしている他のコンピュートノードの中からデータの無効化が必要なものを見つけ出し，もしコンピュートノード１Ｂのバッファが該当すれば，そのデータの無効化を指示するメッセージを，コンピュートノード１Ｂ上のファイル更新通知部３５Ｂへ送る。ファイル更新通知部３５Ｂがこのメッセージを受けると，コヒーレントバッファに先読みデータが入っているかどうかを調べ，もし入っているならコヒーレントバッファを無効化する。この結果，後続のリード要求では，ファイルシステムサーバ部６に新しいデータを要求するようになる。
【００８０】
（ｄ）  無効化が完了すると，ファイルシステムクライアント部３Ｂのファイル更新通知部３５Ｂは，要求を送ったＩ／Ｏノード上のファイルシステムサーバ部６に完了の通知を応答する。
【００８１】
（ｅ）  バッファの無効化完了を通知されたファイルシステムサーバ部６は，プロパゲート要求したファイルシステムクライアント部３Ａのファイル更新通知部３５Ａに応答を返す。
【００８２】
（ｆ）  さらに，ファイル更新通知部３５Ａは，ユーザプログラム２にプロパゲート要求の処理の完了を応答する。
【００８３】
以上の処理により，プロパゲート要求発行以前にそのクライアント（コンピュートノード）が行ったファイルの変更が他のクライアント（コンピュートノード）に確実に伝わったという保証を得ることができる。無効化処理はライトの結果無効となった古いデータをクライアント側のコンピュートノード１Ａ〜１Ｃが先読みしている場合だけに行われる。そうでない場合には，ファイルシステムサーバ部６はプロパゲートを要求したコンピュートノード１Ａ〜１Ｃ上のファイルシステムクライアント部３に直ちに応答を返す。
【００８４】
〔６〕クローズ（ｃｌｏｓｅ）時の処理
ユーザプログラム２が発行したファイル８のクローズ（ｃｌｏｓｅ）要求は，ファイルシステムクライアント部３のクローズ部３４で処理される。クローズ部３４はコヒーレントバッファ４０Ａ〜４０Ｃにライトデータが残っていた場合には，Ｉ／Ｏノード５Ａ〜５Ｃのファイルシステムサーバ部６にコヒーレントバッファ４０Ａ〜４０Ｃの内容を送り，ファイル８に変更を反映する。
【００８５】
〔７〕ディスクＩ／Ｏのスケジューリング
Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，ファイルシステムクライアント部３から送られた要求を以下のように処理する。
【００８６】
単一のノードで動作しているユーザプログラムからの要求の場合には，送られてきたディスクアクセス要求を順に処理する。
【００８７】
複数のノード上で動作している並列プログラムからの要求の場合には，モード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，シーケンシャルモードと非シーケンシャルモードとの切り替えを制御する。
【００８８】
図９は，シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
【００８９】
ファイル８は，オープン直後に非シーケンシャルモードに設定される。ファイルシステムサーバ部６のモード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，アドレスの昇順（クライアントノード毎にみて）にアクセスする要求がすべてのクライアントノードから一定回数以上続くと，シーケンシャルモードに変更する。
【００９０】
シーケンシャルモードの時に一つでも，アドレスの昇順でない要求がきたら非シーケンシャルモードに変更する。一旦非シーケンシャルモードになっても，一定回数以上アドレス昇順の要求が全クライアントノードで続けば，シーケンシャルモードに復帰する。
【００９１】
ディスクＩ／Ｏのスケジューリングは，シーケンシャルモードの場合に行われ，ディスクアクセス要求をキューで管理しながら処理する。非シーケンシャルモードのときには，ディスクアクセス要求を受け付けた順に処理する。
【００９２】
図１０は，シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートであり，リード／ライト要求の処理方法を示している。
【００９３】
非シーケンシャルモードからシーケンシャルモードに遷移したときには，直前の各ノードのディスクアクセス要求の中で最もディスクアクセス終端アドレスの小さいものを基準アドレスとして設定する。図中で「連続」とは要求の始端アドレスが基準アドレスと一致するかまたは小さかったことを意味している。
【００９４】
ファイルシステムサーバ部６は，まず受け付けた要求が連続かどうかを調べ，シーケンシャルモード時に受け付けた要求の始端アドレスが基準アドレスに等しいか小さかった場合には（ステップＳ１１），直ちにその要求を処理し，基準アドレスをこの要求の終端アドレスに変更する（ステップＳ１２）。ディスクアクセスが完了したら，キュー上の先頭につながっている要求を取り出し（ステップＳ１３），ステップＳ１１へ戻って同じ基準で評価する。キューに他の要求がなければ処理を終了して，新しい要求の到着を待つ。
【００９５】
基準アドレスより大きい始端を持つ要求の場合には，この要求を要求の始端アドレスの昇順に並べたキューにつなぐ（ステップＳ１４）。
【００９６】
次に，他のノードからの要求が到着していないかどうかを調べ（ステップＳ１５），到着していれば，ステップＳ１１へ戻り，同様に処理する。
【００９７】
遅延させていた要求あるいは到着している要求の始端アドレスがすべて基準アドレスより大きく，かつ要求を受け付けていないクライアントノード（コンピュートノード）がある場合，一定時間そのノードから要求が到着するのを待つ（ステップＳ１６，Ｓ１７）。この間に到着した要求を同じ基準で評価する。
【００９８】
すべてのノードから要求が到着するか，または一定時間待った後にも基準を満たす要求が見つからなかった場合には，キュー上の先頭にある最も小さな始端アドレスを持つ要求を処理し，基準アドレスを変更する（ステップＳ１８）。この要求の処理が完了したら，キューから他の要求を取り出し（ステップＳ１９），ステップＳ１１へ戻って同じチェックを繰り返す。ステップＳ１８，Ｓ１９において，キューに要求が残っていなければ処理を終了し，新しい要求が到着したときに，同様に処理を繰り返す。
【００９９】
以上の処理の過程で，アドレスの昇順でない要求を見つけたら，見つけた要求とキューにつながれている要求を順にすべて処理し，非シーケンシャルモードに遷移する。
【０１００】
他の実施の形態として，以下のような実施も可能である。
【０１０１】
前述した本発明の実施の形態においては，コヒーレントバッファをファイル単位にＩ／Ｏノード数分もち，各Ｉ／Ｏノードに伝えるデータをＩ／Ｏノード毎のコヒーレントバッファに保持するようにしている。さらに制御を単純化するために，メモリコピーのオーバヘッドが増えるが，バッファにユーザプログラムに渡すイメージのデータを持つことも可能である。すなわち，全Ｉ／Ｏノードに対するデータをまとめて格納するバッファを設けて，前記コヒーレントバッファとの間でコピーするようにしてもよい。
【０１０２】
また，前述した本発明の実施の形態においては，Ｉ／Ｏサーバでの要求の並べ替えの精度を高めるために全コンピュートノードから要求が到着するのを一定時間待つ方式を採用している。これを既に到着している要求間だけで，並べ替えを行うように変更することも可能である。
【０１０３】
図１１は，本発明を用いた処理と従来の処理との処理結果を比較した図であり，図１１（Ａ）は連続するライト要求の場合，図１１（Ｂ）は連続するリード要求の場合のコヒーレントバッファを用いた処理とそうでない処理の結果の比較を表している。
【０１０４】
図中，横軸は転送データのレコードサイズ（単位：バイト），縦軸はスループット（単位：メガバイト／秒）である。コンピュートノードで実行されるプログラムは，典型的なＵＮＩＸインタフェースを持つリード／ライト要求を発行する。
【０１０５】
“ｕｆｓ  ”（−◇−）は，一つのＩ／Ｏノードでローカルファイルシステムがアクセスされている場合の参考のための処理結果，“ｓｐｆｓ１ｎ”（−◆−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ１ｎ（ｃ．ｂ．）”（−□−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）で本発明によるコヒーレントバッファを用いた場合の処理結果，“ｓｐｆｓ３ｎ”（−■−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ３ｎ（ｃ．ｂ．）”（−△−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）で本発明によるコヒーレントバッファを用いた場合の処理結果である。
【０１０６】
図１１（Ａ），（Ｂ）に示されるように，コヒーレントバッファを用いない場合の処理結果は，リード／ライト要求時のデータが十分に大きい場合を見る限りではＩ／Ｏノードの数に比例したスループットを得ている。しかし，要求データのサイズが小さい時には，スループットはかなり低い。
【０１０７】
一方，本発明によるコヒーレントバッファを使用した場合，スループットはデータ長にかかわらず，Ｉ／Ｏノード数に比例した結果が得られている。
【０１０８】
【発明の効果】
以上説明したように，本発明によれば，ファイル更新結果の他ノードへの反映のタイミングをユーザプログラムから通知してもらうメカニズムを設け，同一ファイルに対する更新を各ノードで並行して行えるようにすることで，ファイルのライトシェアを行っている既存のユーザプログラムのＩ／Ｏ性能を飛躍的に向上させることができる。
【０１０９】
具体的には，以下のような効果を奏する。
【０１１０】
１）サーバノード上に存在する一つのファイルを複数のクライアントノードが同時に更新する場合にも，ファイルを破壊することなく高速に処理することができる。
【０１１１】
２）ファイルが複数のサーバノード上のディスクにストライプ配置（Ｉ／Ｏノードストライピング）された環境で，クライアントノード上で動くユーザプログラムが発行するリード／ライト要求のデータ長が小さくても，ファイルが存在するサーバノード数に比例した高性能を発揮することができる。
【０１１２】
３）さらに，バッファをＩ／Ｏノード単位に持つことにより，データのコピー回数を削減することができる。
【０１１３】
４）複数のクライアントノード上で動作する既存の並列プログラムに最小限の変更を加えるだけで，高性能化することができる。
【図面の簡単な説明】
【図１】本発明の構成例を示すブロック構成図である。
【図２】ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。
【図３】コヒーレントバッファの構成例を示す図である。
【図４】ライト要求時のバッファへのデータ設定例を示す図である。
【図５】バッファフルでのライト要求時の並列転送の例を示す図である。
【図６】リード時のバッファへの同時読み込みの例を示す図である。
【図７】バッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図である。
【図８】プロパゲート要求の処理を説明する図である。
【図９】シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
【図１０】シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートである。
【図１１】本発明を用いた処理と従来の処理との処理結果を比較した図である。
【符号の説明】
１Ａ〜１Ｃ  コンピュートノード（クライアントノード）
２          ユーザプログラム
３          ファイルシステムクライアント部
３１        オープン部
３２        リード部
３３        ライト部
３４        クローズ部
３５        ファイル更新通知部
３６        Ｉ／Ｏノード毎のバッファ管理部
４Ａ〜４Ｂ  Ｉ／ＯノードＡ〜Ｃ用のバッファ
５Ａ〜５Ｃ  Ｉ／Ｏノード
６          ファイルシステムサーバ部
６１        データ無効化指示部
６２        要求アクセス並べ替え部
６３        モード切り替え部
７Ａ〜７Ｃ  ディスク
８          ファイル
【図１】
0003574649.tif 000002
【図２】
0003574649.tif 000003
【図３】
0003574649.tif 000004
【図４】
0003574649.tif 000005
【図５】
0003574649.tif 000006
【図６】
0003574649.tif 000007
【図７】
0003574649.tif 000008
【図８】
0003574649.tif 000009
【図９】
0003574649.tif 000010
【図１０】
0003574649.tif 000011
【図１１】
0003574649.tif 000012