JP3545906B2 - ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 - Google Patents
ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 Download PDFInfo
- Publication number
- JP3545906B2 JP3545906B2 JP13947297A JP13947297A JP3545906B2 JP 3545906 B2 JP3545906 B2 JP 3545906B2 JP 13947297 A JP13947297 A JP 13947297A JP 13947297 A JP13947297 A JP 13947297A JP 3545906 B2 JP3545906 B2 JP 3545906B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- buffer
- nodes
- node
- file system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1858—Parallel file systems, i.e. file systems supporting multiple processors
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は，複数の計算機を高速の接続網で接続した並列計算機上で動作する並列プログラム向けファイルシステム（パラレルファイルシステム）の性能を向上させることができるようにしたファイルシステム制御方法，そのパラレルファイルシステムおよびそれを実現するためのプログラム記憶媒体に関する。
【０００２】
【従来の技術】
ユーザプログラムが動作する複数の計算機（これをクライアントノードという）から，ネットワークを介して他のＩ／Ｏノードである計算機（これをサーバノードという）上のファイルをアクセスする際の高速化手法として，クライアント側にキャッシュを持ち，クライアント・サーバ間を流れるデータ量の最小化を図るクライアントキャッシュ方式がよく知られている。
【０００３】
しかし，クライアントキャッシュ方式においては，複数のノードが同一のファイルを同時に更新する，いわゆるライトシェア（ｗｒｉｔｅ ｓｈａｒｅ）が一般的であるような環境下では，クライアントキャシュの使用権の獲得制御やキャッシュデータの無効化処理に伴うオーバヘッドが増大するという問題がある。
【０００４】
この問題を解決する方法として，ユーザプログラムからリード（ｒｅａｄ）／ライト（ｗｒｉｔｅ）要求が発行される度にサーバノードと通信を行うクライアントキャッシュレス方式もよく採用されている。しかし，クライアントキャッシュレス方式においては，ユーザプログラムが発行するリード／ライトのデータ長が小さいと，通信オーバヘッドが急激に増大し，かつＩ／Ｏノードストライピングの効果を発揮できなくなるという欠点がある。
【０００５】
クライアントキャッシュレス方式のもとでユーザプログラムが発行するリード／ライトのデータ長を大きくする手法として，ストライドアクセスインタフェースが提案されている。ストライドアクセスインタフェースは，ファイルに対する離散シーケンシャルアクセスのパターンを宣言することにより，複数のファイル区画に対するアクセスを一回のリード／ライト要求で処理するものである。すなわち，ストライドアクセスでは，例えばあるファイルの１０００バイト目から２００バイト，２０００バイト目から２００バイト，３０００バイト目から２００バイト，…というような飛び飛びのデータをアクセスする場合に，アクセス対象データの配置パターンを宣言することによって，一回のリード／ライト要求で処理する。
【０００６】
ストライドアクセスインタフェースは，個々にリード／ライト要求を発行する場合に比べて，ファイルシステムによる最適化が可能であり，ネットワークの使用効率を高めることができる。
【０００７】
一方，パラレルファイルシステムの重要な構成要素であるディスク記憶装置（以下，ディスクという）は，シーケンシャルにアクセスされた時に最高の性能を発揮することができ，ランダムにアクセスされるとシーク時間や回転待ち時間のため大幅に性能が劣化するという特性を持つ。この特性を利用し，複数のクライアントノードから発行された互いに関連することを宣言されたストライドアクセスインタフェースの要求をまとめて評価し，ディスクアクセスをシーケンシャルなものに変換する手法としてコレクティブＩ／Ｏが知られている。
【０００８】
コレクティブＩ／Ｏでは，サーバノードは，ディスクアクセスとデータ転送のスケジューリングを行い，関連する全クライアントノードのアクセス要求を合体して入出力（Ｉ／Ｏ）を実行することにより，ディスクアクセスおよび転送時間の最小化を図る。
【０００９】
【発明が解決しようとする課題】
ストライドアクセスインタフェースやコレクティブＩ／Ｏの技法は，並列プログラムの入出力を大幅に向上させる技法ではあるが，従来，並列プログラムを作成する前提となっていた，例えばＵＮＩＸシステムなどの既存のファイルアクセスインタフェースとは大きく異なること，またユーザプログラムが大きなＩ／Ｏバッファを用意しないと効果がないことなどから，既存のプログラムの大幅修正が必要となるという欠点がある。
【００１０】
また，クライアントキャッシュ方式は，データ長の小さいリード／ライト要求を効率よく処理でき，しかも既存のプログラムを無修正で使える利点があるが，キャッシュコンシステンシを保証するためのオーバヘッドが大きいという欠点がある。
【００１１】
本発明は上記問題点の解決を図り，既存のプログラムを大幅に変更することなく，パラレルファイルシステムの性能を向上させる手段を提供することを目的とする。
【００１５】
【課題を解決するための手段】
本発明は，複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおいて，各クライアントノードは，ユーザプログラムの発行したライト要求のデータを一旦バッファに蓄積し，バッファが一杯になった時点またはバッファ内のデータが所定量以上になった時点で一括して複数のサーバノードへ送り出し，ユーザプログラムの発行したリード要求に対しては，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対してバッファ内のデータで解決する（先読みしたバッファ内のデータをユーザバッファへコピーする）ことを特徴とする。
【００１６】
データ長の小さなライト要求を多用するユーザプログラムの場合でも，データが一旦バッファに蓄えられ，バッファが一杯となったところで複数のサーバノードへデータが並列に送られるので，データ長の大小にかかわらずＩ／Ｏノードストライピングの効果を発揮することができる。データ長が小さいリード要求が多発する環境でも全サーバノードからバッファ分のデータが一括して先読みされるので，データ長の大小にかかわらずサーバノード数に比例した性能を発揮することができる。
【００１７】
さらに，各クライアントノードは，前記バッファをファイルがストライプ配置されたサーバノード単位に複数用意し，ユーザプログラムの発行したライト要求のデータにより一つのバッファが一杯になったときに，他のバッファに所定量以上のデータが蓄積されていれば同時に複数のサーバノードへデータを送り出すようにする。
【００１８】
これにより，バッファをサーバノードとの間の通信バッファとしてそのまま使うことができ，例えばユーザバッファからシステムバッファへのコピー，システムバッファから転送用バッファへのコピーというような無駄なメモリコピーを削減できる。また，一つのバッファが一杯になった時に他のノード用バッファ中のデータを同時に送り出すので，データ長がストライプ幅に比べて小さいリード／ライト要求が多い環境下でも，サーバノード数に比例した高い性能を実現できる。
【００１９】
また，本発明に関連する技術は，複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，クライアントノードから直前のアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアントノードからの要求が到着していないかをチェックし，アクセスが記憶媒体のアドレスの昇順になるように要求の処理順序を並べ替えてＩ／Ｏを実行することを特徴とする。
【００２０】
クライアントノード上で動くユーザプログラムがファイルをアドレスの昇順に不連続にアクセスした場合にも，複数のクライアントからの要求を評価し，ディスクアクセスが連続シークエンシャルになるように要求の処理順を並べ替えることにより，ファイルが格納されたディスクの無駄な回転待ちやシーク時間が不要となり，高性能を発揮することができる。
【００２１】
また，本発明に関連する技術は，複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，アクセス要求を記憶媒体のアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとの切り替え手段を持ち，各クライアントノードから発行されたアクセス要求が，記憶媒体のアドレスの昇順であるかどうかをクライアントノード単位に監視し，非シーケンシャルモードのときに，記憶媒体のアドレスの昇順にアクセスする要求がすべてのクライアントノードから所定の回数以上続くとシーケンシャルモードへ遷移し，シーケンシャルモードのときに，前記いずれかのクライアントノードから記憶媒体のアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ遷移することを特徴とする。
【００２２】
このようにシーケンシャルモードと非シーケンシャルモードの自動切り替えを行うことにより，複数のアクセス要求に対する連続的なアクセスを効率的に行うとともに，連続的なアクセスとならないようなケースについて要求の無駄な待ち時間や並べ替えの時間を削減することができる。
【００２３】
以上の処理を実現するためのクライアントノードまたはサーバノードで動作させるプログラムは，計算機が読み取り可能な適当な記憶媒体に格納することができる。
【００２４】
【発明の実施の形態】
図１は，本発明の構成例を示すブロック構成図である。
図１において，１Ａ〜１Ｃは並列プログラムを実行する計算機であるコンピュートノード，２は各コンピュートノード１Ａ〜１Ｃで並列に動作するユーザプログラム（並列プログラム），３は並列プログラムから発行されるＩ／Ｏ要求を受け付けるファイルシステムクライアント部，４Ａ〜４ＣはＩ／Ｏノード単位に用意されるバッファ，５Ａ〜５Ｃはファイルへの入出力を行うＩ／Ｏノード，６はディスクが配置されたＩ／Ｏノード上でファイルシステムクライアント部３からの要求に従い実際にディスクをアクセスするファイルシステムサーバ部，７Ａ〜７Ｃはファイルを格納するディスク，８はディスク７Ａ〜７Ｃにデータがストライプ配置された（所定の大きさで分割して配置された）ファイルを表す。
【００２５】
コンピュートノード１Ａ〜１Ｃはクライアントノード，Ｉ／Ｏノード５Ａ〜５Ｃはサーバノードであり，高速の接続網で接続されている。この例では，３台のコンピュートノード１Ａ〜１Ｃが示されているが，複数台であれば何台でもよい。また，３台のＩ／Ｏノード５Ａ〜５Ｃが示されているが任意の台数でよい。
【００２６】
各コンピュートノード１Ａ〜１Ｃでは，それぞれ並列プログラムとして構成されるユーザプログラム２とファイルシステムクライアント部３とが動作し，各Ｉ／Ｏノード５Ａ〜５Ｃでは，ファイルシステムサーバ部６が動作する。ファイルシステムクライアント部３は，例えばプログラムライブラリの形で提供され，ユーザプログラム２と結合編集される。もちろん，ファイルシステムクライアント部３をオペレーティング・システムの一部として，ユーザプログラム２とは独立に組み込んでもよい。
【００２７】
ファイルシステムクライアント部３は，ユーザプログラム２からの要求によりファイル８のオープン処理を行うオープン部３１，リード要求を処理するリード部３２，ライト要求を処理するライト部３３，ファイル８をクローズするクローズ部３４，ファイル更新通知部３５，Ｉ／Ｏノード毎のバッファ管理部３６を持つ。
【００２８】
また，ファイルシステムサーバ部６は，ある一つのコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５からの通知により該当する他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５へ更新データの無効化を指示するデータ無効化指示部６１と，各ディスク７Ａ〜７Ｃに対するアクセス要求をアドレスの昇順に並べ替える要求アクセス並べ替え部６２と，アクセスに関するシーケンシャルモードと非シーケンシャルモードとを切り替えるモード切り替え部６３とを持つ。
【００２９】
ファイルシステムクライアント部３において，Ｉ／Ｏノード毎のバッファ管理部３６は，ファイル単位に各Ｉ／Ｏノード５Ａ〜５Ｃに対応したバッファ４Ａ〜４Ｃを管理する。
【００３０】
ファイルシステムクライアント部３は，ユーザプログラム２からファイル更新通知部３５が呼ばれる（ｐｒｏｐａｇａｔｅ される）まで，ファイル更新データを自ノード内のバッファ４Ａ〜４Ｃにバッファリングし，ファイル更新通知部３５が呼ばれたら，ファイルの更新をファイルシステムサーバ部６へ通知する。ファイルシステムサーバ部６では，ファイル更新通知があると，他のコンピュートノード１Ａ〜１Ｃが先読みしているデータをチェックし，必要ならデータ無効化指示部６１によりファイルの更新に伴うデータの無効化を他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５に指示する。その通知を受けたファイル更新通知部３５は，バッファ４Ａ〜４Ｃの該当データを無効化する。
【００３１】
リード部３２は，ユーザプログラム２の発行したリード要求に対して，要求されたデータとともに後続するデータを，複数のＩ／Ｏノード５Ａ〜５Ｃからバッファ４Ａ〜４Ｃに一括して先読みし，後続のリード要求に対しては，バッファ４Ａ〜４Ｃ内のデータをユーザプログラム２内のユーザバッファへコピーする。
【００３２】
ライト部３３は，ユーザプログラム２の発行したライト要求のデータを一旦バッファ４Ａ〜４Ｃに蓄積し，バッファ４Ａ〜４Ｃが一杯になった時点で一括してＩ／Ｏノード５Ａ〜５Ｃに送り出す。
【００３３】
ファイルシステムサーバ部６の要求アクセス並べ替え部６２は，直前のディスクアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアント（コンピュートノード）からの要求が到着していないかどうかをチェックし，到着していれば，ディスクアクセスがアドレスの昇順となるように要求を並べ替え，その順にＩ／Ｏ処理を実行する。
【００３４】
ファイルシステムサーバ部６は，要求アクセス並べ替え部６２によってファイルシステムクライアント部３からのアクセス要求を各ディスク７Ａ〜７Ｃのアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとを切り替えるモード切り替え部６３を持つ。モード切り替え部６３は，ファイルシステムクライアント部３から発行されたアクセス要求が，ディスク７Ａ〜７Ｃのアドレスの昇順であるかどうかを，コンピュートノード単位に監視し，ディスク７Ａ〜７Ｃのアドレスの昇順にアクセスする要求がすべてのコンピュートノード１Ａ〜１Ｃから所定の回数以上続くと，シーケンシャルモードへ移行させ，いずれかのコンピュートノード１Ａ〜１Ｃからディスク７Ａ〜７Ｃのアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ移行させる。
【００３５】
ユーザプログラム２は，ファイルシステムクライアント部３に対するオープン要求において，以上の機能を利用するかしないかを宣言することができる。以上の機能を利用しないことを宣言すれば，従来と同様なファイルアクセス制御が行われる。ファイルのライトシェアを行う既存の並列プログラム（ユーザプログラム２）は，ファイルオープン時に本発明の機能を有効にすることを宣言し，ファイルの更新が起こったことを他ノードに通知している個所に，ファイル更新通知部３５をコール（ｐｒｏｐａｇａｔｅ）するステートメントを追加するだけで，大きく変更することなく本機能を利用することができる。逐次プログラムの場合には，ファイルシステムクライアント部３が自動的に本機能を有効にする。
【００３６】
従来のファイルのライトシェアを行う並列プログラムには，データのコンシステンシを保証するための論理が必ず組み込まれている。図２は，ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。プロセス２Ａ（ｐｒｏｃｅｓｓ１）とプロセス２Ｂ（ｐｒｏｃｅｓｓ２）は，並列プログラムを構成するサブプログラムであり，異なるコンピュートノード１Ａ，１Ｂ上で動く。プロセス２Ａは，ファイル８の準備が整ったことを他コンピュートノード１Ｂ上のプロセス２Ｂにメッセージを送ることにより通知している。
【００３７】
すなわち，ライトシェアを行う並列プログラムでは，ファイルを更新したことを他のコンピュートノードで動く並列プログラムに通知する処理（ｎｏｔｉｆｙ ｎｏｄｅＢ）がプログラムに必ず含まれているはずであり，タイミング依存のシーケンシャルコンシステンシだけに頼っている訳はない。
【００３８】
したがって，ライト結果を他のノードに反映するためのステートメントを既存のプログラムに追加するのは極めて容易である。この他に必要となるプログラム変更は，ファイルをオープンするステートメントに本機能を利用することを示すパラメータを追加するだけである。
【００３９】
このように，本発明による並列ファイルアクセスに関する高性能化をユーザプログラムが享受するのに，既存の並列プログラムを若干修正するだけでよく，論理自体を変更する必要がない。逐次プログラムの場合には，システムが自動的に本機能を有効にすることにより，既存プログラムを修正しなくても，リード／ライト要求長にかかわらずコンスタントな高性能を得ることができる。
【００４０】
以下，本発明の実施の形態についてさらに詳しく説明する。
〔１〕バッファの確保
ファイルシステムクライアント部３は，ファイルのオープン要求で，本発明の方式を有効化することをユーザプログラム２から通知されると，使用するＩ／Ｏノード５Ａ〜５Ｃを決め，その数分のバッファ４Ａ〜４Ｃを初期化する。
【００４１】
リード／ライト要求がユーザプログラム２から発行されると，ファイルシステムクライアント部３のリード部３２またはライト部３３が動作し，Ｉ／Ｏノード毎のバッファ４Ａ〜４Ｃを使って要求を処理する。以後このバッファ４Ａ〜４Ｃのことをコヒーレントバッファと呼ぶ。
【００４２】
〔２〕コヒーレントバッファの構造
図３は，コヒーレントバッファの構成例を示す図である。
コヒーレントバッファ４０は，図３に示すように，バッファ中のデータを管理する制御部４１と，実際のデータが入るデータ部４２からなる。制御部４１は，バッファの最下部から最上部に拡張する形をとり，データ部４２は逆にバッファの最上部から最下部の方向に広がる構造となっている。
【００４３】
制御部４１は，制御レコード（コントロールエレメント）の集合からなり，一つの制御レコードが一つのＩ／Ｏノードに対する一つのディスクアクセス要求（ライト要求）を表す。制御部４１のｉ番目の制御レコードには，データ部４２のｉ番目のデータエレメントに格納されるデータのディスクアドレスとデータ長とが格納される。
【００４４】
ユーザが要求したＩ／Ｏ要求が，最後の制御レコードで表わされるディスクアクセス要求と連続したものでない場合には，制御部４１を上方向へ拡張して新たに制御レコードを作り，この中に新しいディスクアクセス要求に関するディスクアドレスとデータ長の情報を格納する。最後の制御レコードで表わされるディスクアクセス要求とディスクアドレスが連続している場合には，最後の制御レコードのデータ長に新しいＩ／Ｏ要求のデータ長を加え，最後の制御レコードを更新して一つのＩ／Ｏ要求にまとめる。
【００４５】
〔３〕ライト（ｗｒｉｔｅ）時の処理
図４は，ライト要求時のバッファへのデータ設定例を示す。図４を用いて，ユーザプログラム２が発行したライト要求がバッファとの関係でどう処理されるかを説明する。
【００４６】
ユーザプログラム２がライトするデータを格納したユーザバッファ２０を指定してライト要求を発行すると，ファイルシステムクライアント部３内のライト部３３が制御を受け取る。ライト部３３は，ライト要求で指定されたユーザバッファ２０中のデータを，予め指定されたＩ／Ｏノードストライピングの指定に従い，各Ｉ／Ｏノード５Ａ〜５Ｃごとのデータに分割し，対応するコヒーレントバッファ４０Ａ〜４０Ｃに入れていく。この例では，ユーザバッファ２０の中のデータのうち，ｄａｔａ１がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに，ｄａｔａ２がＩ／ＯノードＢ用のコヒーレントバッファ４０Ｂに，ｄａｔａ３がＩ／ＯノードＣ用のコヒーレントバッファ４０Ｃに，ｄａｔａ４がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに順に設定されている。
【００４７】
コヒーレントバッファ４０Ａ〜４０Ｃが一杯になると，その内容を対応するＩ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６に送り，応答を待つ。
ファイルシステムサーバ部６から応答を受けると，対応するコヒーレントバッファ４０Ａ〜４０Ｃの先頭から次のデータを埋めていく。したがって，短いデータ長のライト要求では，ユーザバッファ２０からコヒーレントバッファ４０Ａ〜４０Ｃにデータを移動するだけで，ファイルシステムサーバ部６との会話はコヒーレントバッファ４０Ａ〜４０Ｃが一杯になるまで遅らされる。
【００４８】
ライト要求で指定されたデータ長が十分大きければ，一回の要求ですべてのコヒーレントバッファが一杯になり，全Ｉ／Ｏノード５Ａ〜５Ｃを並列に動かすことができる。
【００４９】
しかし，ライト要求のデータ長がコヒーレントバッファ長に比べて小さい場合には，一つのバッファだけが一杯になり，結果として一つのＩ／Ｏノードとだけ会話することになる可能性がある。これでは，複数のＩ／Ｏノード５Ａ〜５Ｃ配下のディスク７Ａ〜７Ｃを並列に動かすことができず，Ｉ／Ｏノードストライピングの効果を十分に発揮することができない。
【００５０】
そこで，短いデータ長のライト要求が多い環境でも，Ｉ／Ｏノードストライピングの効果が発揮できるよう，１つのコヒーレントバッファが一杯になったときに他のＩ／Ｏノード用のコヒーレントバッファの状態も調べ，所定量以上（例えばバッファの半分以上）データが詰まっている場合には，同時にそのバッファに対応するＩ／Ｏノードにもデータを送るようにする。
【００５１】
図５は，バッファフルでのライト要求時の並列転送の例を示している。図５を用いて，ユーザプログラム２がライト要求を発行した結果，コヒーレントバッファ４０Ａが一杯になった場合の処理を説明する。
【００５２】
ユーザプログラム２から，ストライプ４−１のデータのライト要求があったとする。このデータにより，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａだけが一杯になる。本来であれば，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａのデータだけをファイルシステムサーバ部６へ送り出せば，ライト要求の目的は達成される。しかし，Ｉ／Ｏノード５Ａ〜５Ｃにおけるディスクアクセスの並列動作の観点からは効率上望ましくない。そこで，他のコヒーレントバッファ４０Ｂ，４０Ｃにはまだ余裕があっても，データが半分以上詰まっている場合には，コヒーレントバッファ４０Ａ〜４０Ｃのデータを同時にファイルシステムサーバ部６へ送り出す。
【００５３】
この制御により，データ長が小さいライト要求が多いプログラムでも，ストライピング数に比例した並列動作による高速のＩ／Ｏを実現できる。各Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，転送されたバッファの内容を調べ，必要なディスクアクセスを行う。
【００５４】
アクセスするディスクアドレスが連続する連続アクセス要求の場合には，クライアント側，すなわちコンピュートノード１Ａ〜１Ｃ側で複数の要求が一つにまとめられるので，ファイルシステムサーバ部６に送られる制御レコードは一つとなり，ファイルシステムサーバ部６はディスクアクセス要求をローカルのファイルシステムに対して一回発行するだけでよい。
【００５５】
アクセスアドレスが連続していないような離散アクセスの場合には，ユーザが発行したライト要求毎に制御レコードが作られ，ファイルシステムサーバ部６に複数のディスクアクセス要求が伝えられる。この場合，ファイルシステムサーバ部６は受信したデータ中に格納されている複数のライト要求を順に取り出して処理する。
【００５６】
〔４〕リード（ｒｅａｄ）処理
リード（ｒｅａｄ）要求は，ファイルシステムクライアント部３内のリード部３２で処理される。リード処理においては，コヒーレントバッファ４０Ａ〜４０Ｃは先読みバッファの役割を果たす。リード部３２は，コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータが既に入っているなら，コヒーレントバッファ４０Ａ〜４０Ｃからユーザバッファ２０にデータをコピーする。この場合，Ｉ／Ｏノード５Ａ〜５Ｃとの間の通信は発生しない。
【００５７】
コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータがなければ，直前の要求と今回のリード要求の関係から先読みを行うかどうかを決める。同じＩ／Ｏノードに対する直前の要求もリード要求で，かつ今回の要求の開始ディスクアドレスと直前の要求の転送終了ディスクアドレスとの差が所定量以下（例えばコヒーレントバッファ長の半分以下）なら，コヒーレントバッファにバッファ分だけ，先読みをする。
【００５８】
バッファサイズの半分以上アクセスアドレスが離れている場合には，バッファサイズ分先読みするオーバヘッドが，次回のアクセスでバッファ上でヒットすることで得られる効果を相殺してしまうと判断し，先読みは行わない。
【００５９】
図６は，リード要求時のバッファへの同時読み込みの例を示している。図６を用いて，ユーザプログラム２がリード要求を発行してバッファ中のデータを使い切ったときの処理を説明する。
【００６０】
データ長が小さいリード要求が多い環境でも，Ｉ／Ｏノードストライピングの効果を発揮するため，コヒーレントバッファへの先読みが必要となった時には他のコヒーレントバッファの使用状況を調べ，そのバッファ中の所定量以上（例えば半分以上）のデータが既にユーザに送られているなら，そのバッファに対しても並行して先読みを起動する。
【００６１】
例えば，図６に示すように，コヒーレントバッファ４０Ａ〜４０Ｃには，それぞれストライプ３−１の一部，ストライプ３−２の一部，ストライプ３−３の一部が先読みされていて，バッファ中の他のデータは，ユーザプログラム２からのリード要求により既にユーザバッファ２０へ転送されているものとする。この状態でユーザプログラム２からストライプ３−１のリード要求があったとする。このリード要求を満たすにはＩ／ＯノードＡ用のコヒーレントバッファ４０Ａだけにデータを読み込めばいいが，他のコヒーレントバッファ４０Ｂ，４０Ｃ中のデータも大部分が使われているので，同時にＩ／ＯノードＢ，Ｃ用のコヒーレントバッファ４０Ｂ，４０Ｃにもデータを読み込む。ただし，既にバッファ中にあるデータを再度読み込むことはない。
【００６２】
なお，リード要求の対象となったＩ／Ｏノード用のコヒーレントバッファにライトデータが残っていた場合には，そのＩ／Ｏノードへコヒーレントバッファの内容を送り，ファイルに変更を反映する。
【００６３】
〔５〕プロパゲート（ｐｒｏｐａｇａｔｅ）処理
ユーザプログラム２が発行したプロパゲート（ｐｒｏｐａｇａｔｅ）要求はファイルシステムクライアント部３内のファイル更新通知部３５で処理される。
【００６４】
図７はバッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図であり，図８はプロパゲート処理を説明する図である。
以下，図７に示す（ａ） 〜（ｅ） に従って動作を説明する。
【００６５】
（ａ） コンピュートノード１Ｂ上で動作するユーザプログラム２は，ファイルシステムサーバ部６に対してｄａｔａ１のリード要求を行う。このとき，ｄａｔａ１の内容とともにｄａｔａ２およびｄａｔａ３が先読み（ｒｅａｄ ａｈｅａｄ）される。
【００６６】
（ｂ） コンピュートノード１Ａ上で動作するユーザプログラム２は，ｄａｔａ３，ｄａｔａ４，ｄａｔａ５とライト要求を出してデータを書き直しているが，コンピュートノード１Ｂ上のユーザプログラム２は気づかずに動作する。
【００６７】
（ｃ） コンピュートノード１Ａ上のコヒーレントバッファ４０が一杯になると，コンピュートノード１Ａからファイルシステムサーバ部６への実際のライト要求が行われ，コヒーレントバッファ４０の内容が一括転送される。
【００６８】
（ｄ） コンピュートノード１Ａ上のユーザプログラム２は，更新データについてのコンシステンシの保証が必要なタイミングでプロパゲート要求を発行する。この要求は，ファイル更新通知部３５を介してファイルシステムサーバ部６へ通知される。
【００６９】
（ｅ） ファイルシステムサーバ部６では，プロパゲート要求を受け取ると，他のコンピュートノード１Ｂのコヒーレントバッファ４０に先読みされているデータをチェックし，無効化が必要なデータ（ｄａｔａ３）を見つけ出し，コンピュートノード１Ｂにそのデータの無効化を指示する。これにより，コンピュートノード１Ｂ上のバッファが無効化され，以降，必要であれば実際のリード要求の処理によりコンピュートノード１Ｂのユーザプログラム２に正しいデータが伝わる。
【００７０】
なお，上記の処理において，ユーザプログラム２からプロパゲート要求が出されると，コヒーレントバッファ４０内のデータは，バッファが一杯になっていなくても，プロパゲートの指示とともにファイルシステムサーバ部６へ転送され，該当するディスク７への書き出しが行われる。
【００７１】
このプロパゲート処理を，図８の（ａ） 〜（ｆ） に従ってさらに詳しく説明すると，以下のとおりである。
（ａ） 図８に示すように，ユーザプログラム２からライトデータのコンシステンシの保証が必要なときにプロパゲート（ｐｒｏｐａｇａｔｅ）要求があると，そのユーザプログラム２が動作するコンピュートノード１Ａのファイルシステムクライアント部３Ａにあるファイル更新通知部３５Ａに通知される。
【００７２】
（ｂ） ファイル更新通知部３５Ａは，まずコヒーレントバッファ４０Ａに残っているライトデータにプロパゲート指示を付加して，Ｉ／Ｏノード上のファイルシステムサーバ部６へ送る。ファイルシステムサーバ部６は，受け取ったライトデータをディスク７に反映する。
【００７３】
（ｃ） 続いて，ファイルシステムサーバ部６のデータ無効化指示部６１は，コヒーレントバッファにデータを先読みしている他のコンピュートノードの中からデータの無効化が必要なものを見つけ出し，もしコンピュートノード１Ｂのバッファが該当すれば，そのデータの無効化を指示するメッセージを，コンピュートノード１Ｂ上のファイル更新通知部３５Ｂへ送る。ファイル更新通知部３５Ｂがこのメッセージを受けると，コヒーレントバッファに先読みデータが入っているかどうかを調べ，もし入っているならコヒーレントバッファを無効化する。この結果，後続のリード要求では，ファイルシステムサーバ部６に新しいデータを要求するようになる。
【００７４】
（ｄ） 無効化が完了すると，ファイルシステムクライアント部３Ｂのファイル更新通知部３５Ｂは，要求を送ったＩ／Ｏノード上のファイルシステムサーバ部６に完了の通知を応答する。
【００７５】
（ｅ） バッファの無効化完了を通知されたファイルシステムサーバ部６は，プロパゲート要求したファイルシステムクライアント部３Ａのファイル更新通知部３５Ａに応答を返す。
【００７６】
（ｆ） さらに，ファイル更新通知部３５Ａは，ユーザプログラム２にプロパゲート要求の処理の完了を応答する。
以上の処理により，プロパゲート要求発行以前にそのクライアント（コンピュートノード）が行ったファイルの変更が他のクライアント（コンピュートノード）に確実に伝わったという保証を得ることができる。無効化処理はライトの結果無効となった古いデータをクライアント側のコンピュートノード１Ａ〜１Ｃが先読みしている場合だけに行われる。そうでない場合には，ファイルシステムサーバ部６はプロパゲートを要求したコンピュートノード１Ａ〜１Ｃ上のファイルシステムクライアント部３に直ちに応答を返す。
【００７７】
〔６〕クローズ（ｃｌｏｓｅ）時の処理
ユーザプログラム２が発行したファイル８のクローズ（ｃｌｏｓｅ）要求は，ファイルシステムクライアント部３のクローズ部３４で処理される。クローズ部３４はコヒーレントバッファ４０Ａ〜４０Ｃにライトデータが残っていた場合には，Ｉ／Ｏノード５Ａ〜５Ｃのファイルシステムサーバ部６にコヒーレントバッファ４０Ａ〜４０Ｃの内容を送り，ファイル８に変更を反映する。
【００７８】
〔７〕ディスクＩ／Ｏのスケジューリング
Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，ファイルシステムクライアント部３から送られた要求を以下のように処理する。
【００７９】
単一のノードで動作しているユーザプログラムからの要求の場合には，送られてきたディスクアクセス要求を順に処理する。
複数のノード上で動作している並列プログラムからの要求の場合には，モード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，シーケンシャルモードと非シーケンシャルモードとの切り替えを制御する。
【００８０】
図９は，シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
ファイル８は，オープン直後に非シーケンシャルモードに設定される。ファイルシステムサーバ部６のモード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，アドレスの昇順（クライアントノード毎にみて）にアクセスする要求がすべてのクライアントノードから一定回数以上続くと，シーケンシャルモードに変更する。
【００８１】
シーケンシャルモードの時に一つでも，アドレスの昇順でない要求がきたら非シーケンシャルモードに変更する。一旦非シーケンシャルモードになっても，一定回数以上アドレス昇順の要求が全クライアントノードで続けば，シーケンシャルモードに復帰する。
【００８２】
ディスクＩ／Ｏのスケジューリングは，シーケンシャルモードの場合に行われ，ディスクアクセス要求をキューで管理しながら処理する。非シーケンシャルモードのときには，ディスクアクセス要求を受け付けた順に処理する。
【００８３】
図１０は，シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートであり，リード／ライト要求の処理方法を示している。
非シーケンシャルモードからシーケンシャルモードに遷移したときには，直前の各ノードのディスクアクセス要求の中で最もディスクアクセス終端アドレスの小さいものを基準アドレスとして設定する。図中で「連続」とは要求の始端アドレスが基準アドレスと一致するかまたは小さかったことを意味している。
【００８４】
ファイルシステムサーバ部６は，まず受け付けた要求が連続かどうかを調べ，シーケンシャルモード時に受け付けた要求の始端アドレスが基準アドレスに等しいか小さかった場合には（ステップＳ１１），直ちにその要求を処理し，基準アドレスをこの要求の終端アドレスに変更する（ステップＳ１２）。ディスクアクセスが完了したら，キュー上の先頭につながっている要求を取り出し（ステップＳ１３），ステップＳ１１へ戻って同じ基準で評価する。キューに他の要求がなければ処理を終了して，新しい要求の到着を待つ。
【００８５】
基準アドレスより大きい始端を持つ要求の場合には，この要求を要求の始端アドレスの昇順に並べたキューにつなぐ（ステップＳ１４）。
次に，他のノードからの要求が到着していないかどうかを調べ（ステップＳ１５），到着していれば，ステップＳ１１へ戻り，同様に処理する。
【００８６】
遅延させていた要求あるいは到着している要求の始端アドレスがすべて基準アドレスより大きく，かつ要求を受け付けていないクライアントノード（コンピュートノード）がある場合，一定時間そのノードから要求が到着するのを待つ（ステップＳ１６，Ｓ１７）。この間に到着した要求を同じ基準で評価する。
【００８７】
すべてのノードから要求が到着するか，または一定時間待った後にも基準を満たす要求が見つからなかった場合には，キュー上の先頭にある最も小さな始端アドレスを持つ要求を処理し，基準アドレスを変更する（ステップＳ１８）。この要求の処理が完了したら，キューから他の要求を取り出し（ステップＳ１９），ステップＳ１１へ戻って同じチェックを繰り返す。ステップＳ１８，Ｓ１９において，キューに要求が残っていなければ処理を終了し，新しい要求が到着したときに，同様に処理を繰り返す。
【００８８】
以上の処理の過程で，アドレスの昇順でない要求を見つけたら，見つけた要求とキューにつながれている要求を順にすべて処理し，非シーケンシャルモードに遷移する。
【００８９】
本発明の他の実施の形態として，以下のような実施も可能である。
前述した本発明の実施の形態においては，コヒーレントバッファをファイル単位にＩ／Ｏノード数分もち，各Ｉ／Ｏノードに伝えるデータをＩ／Ｏノード毎のコヒーレントバッファに保持するようにしている。さらに制御を単純化するために，メモリコピーのオーバヘッドが増えるが，バッファにユーザプログラムに渡すイメージのデータを持つことも可能である。すなわち，全Ｉ／Ｏノードに対するデータをまとめて格納するバッファを設けて，前記コヒーレントバッファとの間でコピーするようにしてもよい。
【００９０】
また，前述した本発明の実施の形態においては，Ｉ／Ｏサーバでの要求の並べ替えの精度を高めるために全コンピュートノードから要求が到着するのを一定時間待つ方式を採用している。これを既に到着している要求間だけで，並べ替えを行うように変更することも可能である。
【００９１】
図１１は，本発明を用いた処理と従来の処理との処理結果を比較した図であり，図１１（Ａ）は連続するライト要求の場合，図１１（Ｂ）は連続するリード要求の場合のコヒーレントバッファを用いた処理とそうでない処理の結果の比較を表している。
【００９２】
図中，横軸は転送データのレコードサイズ（単位：バイト），縦軸はスループット（単位：メガバイト／秒）である。コンピュートノードで実行されるプログラムは，典型的なＵＮＩＸインタフェースを持つリード／ライト要求を発行する。
【００９３】
“ｕｆｓ ”（−◇−）は，一つのＩ／Ｏノードでローカルファイルシステムがアクセスされている場合の参考のための処理結果，“ｓｐｆｓ１ｎ”（−◆−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ１ｎ（ｃ．ｂ．）”（−□−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）で本発明によるコヒーレントバッファを用いた場合の処理結果，“ｓｐｆｓ３ｎ”（−■−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ３ｎ（ｃ．ｂ．）”（−△−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）で本発明によるコヒーレントバッファを用いた場合の処理結果である。
【００９４】
図１１（Ａ），（Ｂ）に示されるように，コヒーレントバッファを用いない場合の処理結果は，リード／ライト要求時のデータが十分に大きい場合を見る限りではＩ／Ｏノードの数に比例したスループットを得ている。しかし，要求データのサイズが小さい時には，スループットはかなり低い。
【００９５】
一方，本発明によるコヒーレントバッファを使用した場合，スループットはデータ長にかかわらず，Ｉ／Ｏノード数に比例した結果が得られている。
【００９６】
【発明の効果】
以上説明したように，本発明によれば，ファイル更新結果の他ノードへの反映のタイミングをユーザプログラムから通知してもらうメカニズムを設け，同一ファイルに対する更新を各ノードで並行して行えるようにし，かつ複数のノードから発行されたＩ／Ｏ要求をＩ／Ｏノード上でディスクアクセス時間が最短になるように並べ替えることで，ファイルのライトシェアを行っている既存のユーザプログラムのＩ／Ｏ性能を飛躍的に向上させることができる。
【００９７】
具体的には，以下のような効果を奏する。
１）サーバノード上に存在する一つのファイルを複数のクライアントノードが同時に更新する場合にも，ファイルを破壊することなく高速に処理することができる。
【００９８】
２）ファイルが複数のサーバノード上のディスクにストライプ配置（Ｉ／Ｏノードストライピング）された環境で，クライアントノード上で動くユーザプログラムが発行するリード／ライト要求のデータ長が小さくても，ファイルが存在するサーバノード数に比例した高性能を発揮することができる。
【００９９】
３）さらに，バッファをＩ／Ｏノード単位に持つことにより，データのコピー回数を削減することができる。
４）クライアントノード上で動くユーザプログラムがファイルをアドレスの昇順に不連続にアクセスした場合にも，複数のクライアントからの要求を評価し，ディスクアクセスが連続シーケンシャルになるように要求の処理順を並べ替えることにより，高性能を発揮することができる。
【０１００】
５）複数のクライアントノード上で動作する既存の並列プログラムに最小限の変更を加えるだけで，高性能化することができる。
【図面の簡単な説明】
【図１】本発明の構成例を示すブロック構成図である。
【図２】ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。
【図３】コヒーレントバッファの構成例を示す図である。
【図４】ライト要求時のバッファへのデータ設定例を示す図である。
【図５】バッファフルでのライト要求時の並列転送の例を示す図である。
【図６】リード時のバッファへの同時読み込みの例を示す図である。
【図７】バッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図である。
【図８】プロパゲート要求の処理を説明する図である。
【図９】シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
【図１０】シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートである。
【図１１】本発明を用いた処理と従来の処理との処理結果を比較した図である。
【符号の説明】
１Ａ〜１Ｃ コンピュートノード（クライアントノード）
２ ユーザプログラム
３ ファイルシステムクライアント部
３１ オープン部
３２ リード部
３３ ライト部
３４ クローズ部
３５ ファイル更新通知部
３６ Ｉ／Ｏノード毎のバッファ管理部
４Ａ〜４Ｂ Ｉ／ＯノードＡ〜Ｃ用のバッファ
５Ａ〜５Ｃ Ｉ／Ｏノード
６ ファイルシステムサーバ部
６１ データ無効化指示部
６２ 要求アクセス並べ替え部
６３ モード切り替え部
７Ａ〜７Ｃ ディスク
８ ファイル
【発明の属する技術分野】
本発明は，複数の計算機を高速の接続網で接続した並列計算機上で動作する並列プログラム向けファイルシステム（パラレルファイルシステム）の性能を向上させることができるようにしたファイルシステム制御方法，そのパラレルファイルシステムおよびそれを実現するためのプログラム記憶媒体に関する。
【０００２】
【従来の技術】
ユーザプログラムが動作する複数の計算機（これをクライアントノードという）から，ネットワークを介して他のＩ／Ｏノードである計算機（これをサーバノードという）上のファイルをアクセスする際の高速化手法として，クライアント側にキャッシュを持ち，クライアント・サーバ間を流れるデータ量の最小化を図るクライアントキャッシュ方式がよく知られている。
【０００３】
しかし，クライアントキャッシュ方式においては，複数のノードが同一のファイルを同時に更新する，いわゆるライトシェア（ｗｒｉｔｅ ｓｈａｒｅ）が一般的であるような環境下では，クライアントキャシュの使用権の獲得制御やキャッシュデータの無効化処理に伴うオーバヘッドが増大するという問題がある。
【０００４】
この問題を解決する方法として，ユーザプログラムからリード（ｒｅａｄ）／ライト（ｗｒｉｔｅ）要求が発行される度にサーバノードと通信を行うクライアントキャッシュレス方式もよく採用されている。しかし，クライアントキャッシュレス方式においては，ユーザプログラムが発行するリード／ライトのデータ長が小さいと，通信オーバヘッドが急激に増大し，かつＩ／Ｏノードストライピングの効果を発揮できなくなるという欠点がある。
【０００５】
クライアントキャッシュレス方式のもとでユーザプログラムが発行するリード／ライトのデータ長を大きくする手法として，ストライドアクセスインタフェースが提案されている。ストライドアクセスインタフェースは，ファイルに対する離散シーケンシャルアクセスのパターンを宣言することにより，複数のファイル区画に対するアクセスを一回のリード／ライト要求で処理するものである。すなわち，ストライドアクセスでは，例えばあるファイルの１０００バイト目から２００バイト，２０００バイト目から２００バイト，３０００バイト目から２００バイト，…というような飛び飛びのデータをアクセスする場合に，アクセス対象データの配置パターンを宣言することによって，一回のリード／ライト要求で処理する。
【０００６】
ストライドアクセスインタフェースは，個々にリード／ライト要求を発行する場合に比べて，ファイルシステムによる最適化が可能であり，ネットワークの使用効率を高めることができる。
【０００７】
一方，パラレルファイルシステムの重要な構成要素であるディスク記憶装置（以下，ディスクという）は，シーケンシャルにアクセスされた時に最高の性能を発揮することができ，ランダムにアクセスされるとシーク時間や回転待ち時間のため大幅に性能が劣化するという特性を持つ。この特性を利用し，複数のクライアントノードから発行された互いに関連することを宣言されたストライドアクセスインタフェースの要求をまとめて評価し，ディスクアクセスをシーケンシャルなものに変換する手法としてコレクティブＩ／Ｏが知られている。
【０００８】
コレクティブＩ／Ｏでは，サーバノードは，ディスクアクセスとデータ転送のスケジューリングを行い，関連する全クライアントノードのアクセス要求を合体して入出力（Ｉ／Ｏ）を実行することにより，ディスクアクセスおよび転送時間の最小化を図る。
【０００９】
【発明が解決しようとする課題】
ストライドアクセスインタフェースやコレクティブＩ／Ｏの技法は，並列プログラムの入出力を大幅に向上させる技法ではあるが，従来，並列プログラムを作成する前提となっていた，例えばＵＮＩＸシステムなどの既存のファイルアクセスインタフェースとは大きく異なること，またユーザプログラムが大きなＩ／Ｏバッファを用意しないと効果がないことなどから，既存のプログラムの大幅修正が必要となるという欠点がある。
【００１０】
また，クライアントキャッシュ方式は，データ長の小さいリード／ライト要求を効率よく処理でき，しかも既存のプログラムを無修正で使える利点があるが，キャッシュコンシステンシを保証するためのオーバヘッドが大きいという欠点がある。
【００１１】
本発明は上記問題点の解決を図り，既存のプログラムを大幅に変更することなく，パラレルファイルシステムの性能を向上させる手段を提供することを目的とする。
【００１５】
【課題を解決するための手段】
本発明は，複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおいて，各クライアントノードは，ユーザプログラムの発行したライト要求のデータを一旦バッファに蓄積し，バッファが一杯になった時点またはバッファ内のデータが所定量以上になった時点で一括して複数のサーバノードへ送り出し，ユーザプログラムの発行したリード要求に対しては，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対してバッファ内のデータで解決する（先読みしたバッファ内のデータをユーザバッファへコピーする）ことを特徴とする。
【００１６】
データ長の小さなライト要求を多用するユーザプログラムの場合でも，データが一旦バッファに蓄えられ，バッファが一杯となったところで複数のサーバノードへデータが並列に送られるので，データ長の大小にかかわらずＩ／Ｏノードストライピングの効果を発揮することができる。データ長が小さいリード要求が多発する環境でも全サーバノードからバッファ分のデータが一括して先読みされるので，データ長の大小にかかわらずサーバノード数に比例した性能を発揮することができる。
【００１７】
さらに，各クライアントノードは，前記バッファをファイルがストライプ配置されたサーバノード単位に複数用意し，ユーザプログラムの発行したライト要求のデータにより一つのバッファが一杯になったときに，他のバッファに所定量以上のデータが蓄積されていれば同時に複数のサーバノードへデータを送り出すようにする。
【００１８】
これにより，バッファをサーバノードとの間の通信バッファとしてそのまま使うことができ，例えばユーザバッファからシステムバッファへのコピー，システムバッファから転送用バッファへのコピーというような無駄なメモリコピーを削減できる。また，一つのバッファが一杯になった時に他のノード用バッファ中のデータを同時に送り出すので，データ長がストライプ幅に比べて小さいリード／ライト要求が多い環境下でも，サーバノード数に比例した高い性能を実現できる。
【００１９】
また，本発明に関連する技術は，複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，クライアントノードから直前のアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアントノードからの要求が到着していないかをチェックし，アクセスが記憶媒体のアドレスの昇順になるように要求の処理順序を並べ替えてＩ／Ｏを実行することを特徴とする。
【００２０】
クライアントノード上で動くユーザプログラムがファイルをアドレスの昇順に不連続にアクセスした場合にも，複数のクライアントからの要求を評価し，ディスクアクセスが連続シークエンシャルになるように要求の処理順を並べ替えることにより，ファイルが格納されたディスクの無駄な回転待ちやシーク時間が不要となり，高性能を発揮することができる。
【００２１】
また，本発明に関連する技術は，複数のクライアントノードがネットワークを介して１または複数のサーバノード上のファイルを共用するネットワークファイルシステムにおいて，サーバノードは，アクセス要求を記憶媒体のアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとの切り替え手段を持ち，各クライアントノードから発行されたアクセス要求が，記憶媒体のアドレスの昇順であるかどうかをクライアントノード単位に監視し，非シーケンシャルモードのときに，記憶媒体のアドレスの昇順にアクセスする要求がすべてのクライアントノードから所定の回数以上続くとシーケンシャルモードへ遷移し，シーケンシャルモードのときに，前記いずれかのクライアントノードから記憶媒体のアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ遷移することを特徴とする。
【００２２】
このようにシーケンシャルモードと非シーケンシャルモードの自動切り替えを行うことにより，複数のアクセス要求に対する連続的なアクセスを効率的に行うとともに，連続的なアクセスとならないようなケースについて要求の無駄な待ち時間や並べ替えの時間を削減することができる。
【００２３】
以上の処理を実現するためのクライアントノードまたはサーバノードで動作させるプログラムは，計算機が読み取り可能な適当な記憶媒体に格納することができる。
【００２４】
【発明の実施の形態】
図１は，本発明の構成例を示すブロック構成図である。
図１において，１Ａ〜１Ｃは並列プログラムを実行する計算機であるコンピュートノード，２は各コンピュートノード１Ａ〜１Ｃで並列に動作するユーザプログラム（並列プログラム），３は並列プログラムから発行されるＩ／Ｏ要求を受け付けるファイルシステムクライアント部，４Ａ〜４ＣはＩ／Ｏノード単位に用意されるバッファ，５Ａ〜５Ｃはファイルへの入出力を行うＩ／Ｏノード，６はディスクが配置されたＩ／Ｏノード上でファイルシステムクライアント部３からの要求に従い実際にディスクをアクセスするファイルシステムサーバ部，７Ａ〜７Ｃはファイルを格納するディスク，８はディスク７Ａ〜７Ｃにデータがストライプ配置された（所定の大きさで分割して配置された）ファイルを表す。
【００２５】
コンピュートノード１Ａ〜１Ｃはクライアントノード，Ｉ／Ｏノード５Ａ〜５Ｃはサーバノードであり，高速の接続網で接続されている。この例では，３台のコンピュートノード１Ａ〜１Ｃが示されているが，複数台であれば何台でもよい。また，３台のＩ／Ｏノード５Ａ〜５Ｃが示されているが任意の台数でよい。
【００２６】
各コンピュートノード１Ａ〜１Ｃでは，それぞれ並列プログラムとして構成されるユーザプログラム２とファイルシステムクライアント部３とが動作し，各Ｉ／Ｏノード５Ａ〜５Ｃでは，ファイルシステムサーバ部６が動作する。ファイルシステムクライアント部３は，例えばプログラムライブラリの形で提供され，ユーザプログラム２と結合編集される。もちろん，ファイルシステムクライアント部３をオペレーティング・システムの一部として，ユーザプログラム２とは独立に組み込んでもよい。
【００２７】
ファイルシステムクライアント部３は，ユーザプログラム２からの要求によりファイル８のオープン処理を行うオープン部３１，リード要求を処理するリード部３２，ライト要求を処理するライト部３３，ファイル８をクローズするクローズ部３４，ファイル更新通知部３５，Ｉ／Ｏノード毎のバッファ管理部３６を持つ。
【００２８】
また，ファイルシステムサーバ部６は，ある一つのコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５からの通知により該当する他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５へ更新データの無効化を指示するデータ無効化指示部６１と，各ディスク７Ａ〜７Ｃに対するアクセス要求をアドレスの昇順に並べ替える要求アクセス並べ替え部６２と，アクセスに関するシーケンシャルモードと非シーケンシャルモードとを切り替えるモード切り替え部６３とを持つ。
【００２９】
ファイルシステムクライアント部３において，Ｉ／Ｏノード毎のバッファ管理部３６は，ファイル単位に各Ｉ／Ｏノード５Ａ〜５Ｃに対応したバッファ４Ａ〜４Ｃを管理する。
【００３０】
ファイルシステムクライアント部３は，ユーザプログラム２からファイル更新通知部３５が呼ばれる（ｐｒｏｐａｇａｔｅ される）まで，ファイル更新データを自ノード内のバッファ４Ａ〜４Ｃにバッファリングし，ファイル更新通知部３５が呼ばれたら，ファイルの更新をファイルシステムサーバ部６へ通知する。ファイルシステムサーバ部６では，ファイル更新通知があると，他のコンピュートノード１Ａ〜１Ｃが先読みしているデータをチェックし，必要ならデータ無効化指示部６１によりファイルの更新に伴うデータの無効化を他のコンピュートノード１Ａ〜１Ｃのファイル更新通知部３５に指示する。その通知を受けたファイル更新通知部３５は，バッファ４Ａ〜４Ｃの該当データを無効化する。
【００３１】
リード部３２は，ユーザプログラム２の発行したリード要求に対して，要求されたデータとともに後続するデータを，複数のＩ／Ｏノード５Ａ〜５Ｃからバッファ４Ａ〜４Ｃに一括して先読みし，後続のリード要求に対しては，バッファ４Ａ〜４Ｃ内のデータをユーザプログラム２内のユーザバッファへコピーする。
【００３２】
ライト部３３は，ユーザプログラム２の発行したライト要求のデータを一旦バッファ４Ａ〜４Ｃに蓄積し，バッファ４Ａ〜４Ｃが一杯になった時点で一括してＩ／Ｏノード５Ａ〜５Ｃに送り出す。
【００３３】
ファイルシステムサーバ部６の要求アクセス並べ替え部６２は，直前のディスクアクセスと非連続な範囲をアクセスする要求を受け取ると，他のクライアント（コンピュートノード）からの要求が到着していないかどうかをチェックし，到着していれば，ディスクアクセスがアドレスの昇順となるように要求を並べ替え，その順にＩ／Ｏ処理を実行する。
【００３４】
ファイルシステムサーバ部６は，要求アクセス並べ替え部６２によってファイルシステムクライアント部３からのアクセス要求を各ディスク７Ａ〜７Ｃのアドレスの昇順になるように並べ替えて処理するシーケンシャルモードと，アクセス要求を受け付けた順に処理する非シーケンシャルモードとを切り替えるモード切り替え部６３を持つ。モード切り替え部６３は，ファイルシステムクライアント部３から発行されたアクセス要求が，ディスク７Ａ〜７Ｃのアドレスの昇順であるかどうかを，コンピュートノード単位に監視し，ディスク７Ａ〜７Ｃのアドレスの昇順にアクセスする要求がすべてのコンピュートノード１Ａ〜１Ｃから所定の回数以上続くと，シーケンシャルモードへ移行させ，いずれかのコンピュートノード１Ａ〜１Ｃからディスク７Ａ〜７Ｃのアドレスの昇順でないアクセス要求がくると非シーケンシャルモードへ移行させる。
【００３５】
ユーザプログラム２は，ファイルシステムクライアント部３に対するオープン要求において，以上の機能を利用するかしないかを宣言することができる。以上の機能を利用しないことを宣言すれば，従来と同様なファイルアクセス制御が行われる。ファイルのライトシェアを行う既存の並列プログラム（ユーザプログラム２）は，ファイルオープン時に本発明の機能を有効にすることを宣言し，ファイルの更新が起こったことを他ノードに通知している個所に，ファイル更新通知部３５をコール（ｐｒｏｐａｇａｔｅ）するステートメントを追加するだけで，大きく変更することなく本機能を利用することができる。逐次プログラムの場合には，ファイルシステムクライアント部３が自動的に本機能を有効にする。
【００３６】
従来のファイルのライトシェアを行う並列プログラムには，データのコンシステンシを保証するための論理が必ず組み込まれている。図２は，ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。プロセス２Ａ（ｐｒｏｃｅｓｓ１）とプロセス２Ｂ（ｐｒｏｃｅｓｓ２）は，並列プログラムを構成するサブプログラムであり，異なるコンピュートノード１Ａ，１Ｂ上で動く。プロセス２Ａは，ファイル８の準備が整ったことを他コンピュートノード１Ｂ上のプロセス２Ｂにメッセージを送ることにより通知している。
【００３７】
すなわち，ライトシェアを行う並列プログラムでは，ファイルを更新したことを他のコンピュートノードで動く並列プログラムに通知する処理（ｎｏｔｉｆｙ ｎｏｄｅＢ）がプログラムに必ず含まれているはずであり，タイミング依存のシーケンシャルコンシステンシだけに頼っている訳はない。
【００３８】
したがって，ライト結果を他のノードに反映するためのステートメントを既存のプログラムに追加するのは極めて容易である。この他に必要となるプログラム変更は，ファイルをオープンするステートメントに本機能を利用することを示すパラメータを追加するだけである。
【００３９】
このように，本発明による並列ファイルアクセスに関する高性能化をユーザプログラムが享受するのに，既存の並列プログラムを若干修正するだけでよく，論理自体を変更する必要がない。逐次プログラムの場合には，システムが自動的に本機能を有効にすることにより，既存プログラムを修正しなくても，リード／ライト要求長にかかわらずコンスタントな高性能を得ることができる。
【００４０】
以下，本発明の実施の形態についてさらに詳しく説明する。
〔１〕バッファの確保
ファイルシステムクライアント部３は，ファイルのオープン要求で，本発明の方式を有効化することをユーザプログラム２から通知されると，使用するＩ／Ｏノード５Ａ〜５Ｃを決め，その数分のバッファ４Ａ〜４Ｃを初期化する。
【００４１】
リード／ライト要求がユーザプログラム２から発行されると，ファイルシステムクライアント部３のリード部３２またはライト部３３が動作し，Ｉ／Ｏノード毎のバッファ４Ａ〜４Ｃを使って要求を処理する。以後このバッファ４Ａ〜４Ｃのことをコヒーレントバッファと呼ぶ。
【００４２】
〔２〕コヒーレントバッファの構造
図３は，コヒーレントバッファの構成例を示す図である。
コヒーレントバッファ４０は，図３に示すように，バッファ中のデータを管理する制御部４１と，実際のデータが入るデータ部４２からなる。制御部４１は，バッファの最下部から最上部に拡張する形をとり，データ部４２は逆にバッファの最上部から最下部の方向に広がる構造となっている。
【００４３】
制御部４１は，制御レコード（コントロールエレメント）の集合からなり，一つの制御レコードが一つのＩ／Ｏノードに対する一つのディスクアクセス要求（ライト要求）を表す。制御部４１のｉ番目の制御レコードには，データ部４２のｉ番目のデータエレメントに格納されるデータのディスクアドレスとデータ長とが格納される。
【００４４】
ユーザが要求したＩ／Ｏ要求が，最後の制御レコードで表わされるディスクアクセス要求と連続したものでない場合には，制御部４１を上方向へ拡張して新たに制御レコードを作り，この中に新しいディスクアクセス要求に関するディスクアドレスとデータ長の情報を格納する。最後の制御レコードで表わされるディスクアクセス要求とディスクアドレスが連続している場合には，最後の制御レコードのデータ長に新しいＩ／Ｏ要求のデータ長を加え，最後の制御レコードを更新して一つのＩ／Ｏ要求にまとめる。
【００４５】
〔３〕ライト（ｗｒｉｔｅ）時の処理
図４は，ライト要求時のバッファへのデータ設定例を示す。図４を用いて，ユーザプログラム２が発行したライト要求がバッファとの関係でどう処理されるかを説明する。
【００４６】
ユーザプログラム２がライトするデータを格納したユーザバッファ２０を指定してライト要求を発行すると，ファイルシステムクライアント部３内のライト部３３が制御を受け取る。ライト部３３は，ライト要求で指定されたユーザバッファ２０中のデータを，予め指定されたＩ／Ｏノードストライピングの指定に従い，各Ｉ／Ｏノード５Ａ〜５Ｃごとのデータに分割し，対応するコヒーレントバッファ４０Ａ〜４０Ｃに入れていく。この例では，ユーザバッファ２０の中のデータのうち，ｄａｔａ１がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに，ｄａｔａ２がＩ／ＯノードＢ用のコヒーレントバッファ４０Ｂに，ｄａｔａ３がＩ／ＯノードＣ用のコヒーレントバッファ４０Ｃに，ｄａｔａ４がＩ／ＯノードＡ用のコヒーレントバッファ４０Ａに順に設定されている。
【００４７】
コヒーレントバッファ４０Ａ〜４０Ｃが一杯になると，その内容を対応するＩ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６に送り，応答を待つ。
ファイルシステムサーバ部６から応答を受けると，対応するコヒーレントバッファ４０Ａ〜４０Ｃの先頭から次のデータを埋めていく。したがって，短いデータ長のライト要求では，ユーザバッファ２０からコヒーレントバッファ４０Ａ〜４０Ｃにデータを移動するだけで，ファイルシステムサーバ部６との会話はコヒーレントバッファ４０Ａ〜４０Ｃが一杯になるまで遅らされる。
【００４８】
ライト要求で指定されたデータ長が十分大きければ，一回の要求ですべてのコヒーレントバッファが一杯になり，全Ｉ／Ｏノード５Ａ〜５Ｃを並列に動かすことができる。
【００４９】
しかし，ライト要求のデータ長がコヒーレントバッファ長に比べて小さい場合には，一つのバッファだけが一杯になり，結果として一つのＩ／Ｏノードとだけ会話することになる可能性がある。これでは，複数のＩ／Ｏノード５Ａ〜５Ｃ配下のディスク７Ａ〜７Ｃを並列に動かすことができず，Ｉ／Ｏノードストライピングの効果を十分に発揮することができない。
【００５０】
そこで，短いデータ長のライト要求が多い環境でも，Ｉ／Ｏノードストライピングの効果が発揮できるよう，１つのコヒーレントバッファが一杯になったときに他のＩ／Ｏノード用のコヒーレントバッファの状態も調べ，所定量以上（例えばバッファの半分以上）データが詰まっている場合には，同時にそのバッファに対応するＩ／Ｏノードにもデータを送るようにする。
【００５１】
図５は，バッファフルでのライト要求時の並列転送の例を示している。図５を用いて，ユーザプログラム２がライト要求を発行した結果，コヒーレントバッファ４０Ａが一杯になった場合の処理を説明する。
【００５２】
ユーザプログラム２から，ストライプ４−１のデータのライト要求があったとする。このデータにより，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａだけが一杯になる。本来であれば，Ｉ／ＯノードＡ用のコヒーレントバッファ４０Ａのデータだけをファイルシステムサーバ部６へ送り出せば，ライト要求の目的は達成される。しかし，Ｉ／Ｏノード５Ａ〜５Ｃにおけるディスクアクセスの並列動作の観点からは効率上望ましくない。そこで，他のコヒーレントバッファ４０Ｂ，４０Ｃにはまだ余裕があっても，データが半分以上詰まっている場合には，コヒーレントバッファ４０Ａ〜４０Ｃのデータを同時にファイルシステムサーバ部６へ送り出す。
【００５３】
この制御により，データ長が小さいライト要求が多いプログラムでも，ストライピング数に比例した並列動作による高速のＩ／Ｏを実現できる。各Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，転送されたバッファの内容を調べ，必要なディスクアクセスを行う。
【００５４】
アクセスするディスクアドレスが連続する連続アクセス要求の場合には，クライアント側，すなわちコンピュートノード１Ａ〜１Ｃ側で複数の要求が一つにまとめられるので，ファイルシステムサーバ部６に送られる制御レコードは一つとなり，ファイルシステムサーバ部６はディスクアクセス要求をローカルのファイルシステムに対して一回発行するだけでよい。
【００５５】
アクセスアドレスが連続していないような離散アクセスの場合には，ユーザが発行したライト要求毎に制御レコードが作られ，ファイルシステムサーバ部６に複数のディスクアクセス要求が伝えられる。この場合，ファイルシステムサーバ部６は受信したデータ中に格納されている複数のライト要求を順に取り出して処理する。
【００５６】
〔４〕リード（ｒｅａｄ）処理
リード（ｒｅａｄ）要求は，ファイルシステムクライアント部３内のリード部３２で処理される。リード処理においては，コヒーレントバッファ４０Ａ〜４０Ｃは先読みバッファの役割を果たす。リード部３２は，コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータが既に入っているなら，コヒーレントバッファ４０Ａ〜４０Ｃからユーザバッファ２０にデータをコピーする。この場合，Ｉ／Ｏノード５Ａ〜５Ｃとの間の通信は発生しない。
【００５７】
コヒーレントバッファ４０Ａ〜４０Ｃに必要なデータがなければ，直前の要求と今回のリード要求の関係から先読みを行うかどうかを決める。同じＩ／Ｏノードに対する直前の要求もリード要求で，かつ今回の要求の開始ディスクアドレスと直前の要求の転送終了ディスクアドレスとの差が所定量以下（例えばコヒーレントバッファ長の半分以下）なら，コヒーレントバッファにバッファ分だけ，先読みをする。
【００５８】
バッファサイズの半分以上アクセスアドレスが離れている場合には，バッファサイズ分先読みするオーバヘッドが，次回のアクセスでバッファ上でヒットすることで得られる効果を相殺してしまうと判断し，先読みは行わない。
【００５９】
図６は，リード要求時のバッファへの同時読み込みの例を示している。図６を用いて，ユーザプログラム２がリード要求を発行してバッファ中のデータを使い切ったときの処理を説明する。
【００６０】
データ長が小さいリード要求が多い環境でも，Ｉ／Ｏノードストライピングの効果を発揮するため，コヒーレントバッファへの先読みが必要となった時には他のコヒーレントバッファの使用状況を調べ，そのバッファ中の所定量以上（例えば半分以上）のデータが既にユーザに送られているなら，そのバッファに対しても並行して先読みを起動する。
【００６１】
例えば，図６に示すように，コヒーレントバッファ４０Ａ〜４０Ｃには，それぞれストライプ３−１の一部，ストライプ３−２の一部，ストライプ３−３の一部が先読みされていて，バッファ中の他のデータは，ユーザプログラム２からのリード要求により既にユーザバッファ２０へ転送されているものとする。この状態でユーザプログラム２からストライプ３−１のリード要求があったとする。このリード要求を満たすにはＩ／ＯノードＡ用のコヒーレントバッファ４０Ａだけにデータを読み込めばいいが，他のコヒーレントバッファ４０Ｂ，４０Ｃ中のデータも大部分が使われているので，同時にＩ／ＯノードＢ，Ｃ用のコヒーレントバッファ４０Ｂ，４０Ｃにもデータを読み込む。ただし，既にバッファ中にあるデータを再度読み込むことはない。
【００６２】
なお，リード要求の対象となったＩ／Ｏノード用のコヒーレントバッファにライトデータが残っていた場合には，そのＩ／Ｏノードへコヒーレントバッファの内容を送り，ファイルに変更を反映する。
【００６３】
〔５〕プロパゲート（ｐｒｏｐａｇａｔｅ）処理
ユーザプログラム２が発行したプロパゲート（ｐｒｏｐａｇａｔｅ）要求はファイルシステムクライアント部３内のファイル更新通知部３５で処理される。
【００６４】
図７はバッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図であり，図８はプロパゲート処理を説明する図である。
以下，図７に示す（ａ） 〜（ｅ） に従って動作を説明する。
【００６５】
（ａ） コンピュートノード１Ｂ上で動作するユーザプログラム２は，ファイルシステムサーバ部６に対してｄａｔａ１のリード要求を行う。このとき，ｄａｔａ１の内容とともにｄａｔａ２およびｄａｔａ３が先読み（ｒｅａｄ ａｈｅａｄ）される。
【００６６】
（ｂ） コンピュートノード１Ａ上で動作するユーザプログラム２は，ｄａｔａ３，ｄａｔａ４，ｄａｔａ５とライト要求を出してデータを書き直しているが，コンピュートノード１Ｂ上のユーザプログラム２は気づかずに動作する。
【００６７】
（ｃ） コンピュートノード１Ａ上のコヒーレントバッファ４０が一杯になると，コンピュートノード１Ａからファイルシステムサーバ部６への実際のライト要求が行われ，コヒーレントバッファ４０の内容が一括転送される。
【００６８】
（ｄ） コンピュートノード１Ａ上のユーザプログラム２は，更新データについてのコンシステンシの保証が必要なタイミングでプロパゲート要求を発行する。この要求は，ファイル更新通知部３５を介してファイルシステムサーバ部６へ通知される。
【００６９】
（ｅ） ファイルシステムサーバ部６では，プロパゲート要求を受け取ると，他のコンピュートノード１Ｂのコヒーレントバッファ４０に先読みされているデータをチェックし，無効化が必要なデータ（ｄａｔａ３）を見つけ出し，コンピュートノード１Ｂにそのデータの無効化を指示する。これにより，コンピュートノード１Ｂ上のバッファが無効化され，以降，必要であれば実際のリード要求の処理によりコンピュートノード１Ｂのユーザプログラム２に正しいデータが伝わる。
【００７０】
なお，上記の処理において，ユーザプログラム２からプロパゲート要求が出されると，コヒーレントバッファ４０内のデータは，バッファが一杯になっていなくても，プロパゲートの指示とともにファイルシステムサーバ部６へ転送され，該当するディスク７への書き出しが行われる。
【００７１】
このプロパゲート処理を，図８の（ａ） 〜（ｆ） に従ってさらに詳しく説明すると，以下のとおりである。
（ａ） 図８に示すように，ユーザプログラム２からライトデータのコンシステンシの保証が必要なときにプロパゲート（ｐｒｏｐａｇａｔｅ）要求があると，そのユーザプログラム２が動作するコンピュートノード１Ａのファイルシステムクライアント部３Ａにあるファイル更新通知部３５Ａに通知される。
【００７２】
（ｂ） ファイル更新通知部３５Ａは，まずコヒーレントバッファ４０Ａに残っているライトデータにプロパゲート指示を付加して，Ｉ／Ｏノード上のファイルシステムサーバ部６へ送る。ファイルシステムサーバ部６は，受け取ったライトデータをディスク７に反映する。
【００７３】
（ｃ） 続いて，ファイルシステムサーバ部６のデータ無効化指示部６１は，コヒーレントバッファにデータを先読みしている他のコンピュートノードの中からデータの無効化が必要なものを見つけ出し，もしコンピュートノード１Ｂのバッファが該当すれば，そのデータの無効化を指示するメッセージを，コンピュートノード１Ｂ上のファイル更新通知部３５Ｂへ送る。ファイル更新通知部３５Ｂがこのメッセージを受けると，コヒーレントバッファに先読みデータが入っているかどうかを調べ，もし入っているならコヒーレントバッファを無効化する。この結果，後続のリード要求では，ファイルシステムサーバ部６に新しいデータを要求するようになる。
【００７４】
（ｄ） 無効化が完了すると，ファイルシステムクライアント部３Ｂのファイル更新通知部３５Ｂは，要求を送ったＩ／Ｏノード上のファイルシステムサーバ部６に完了の通知を応答する。
【００７５】
（ｅ） バッファの無効化完了を通知されたファイルシステムサーバ部６は，プロパゲート要求したファイルシステムクライアント部３Ａのファイル更新通知部３５Ａに応答を返す。
【００７６】
（ｆ） さらに，ファイル更新通知部３５Ａは，ユーザプログラム２にプロパゲート要求の処理の完了を応答する。
以上の処理により，プロパゲート要求発行以前にそのクライアント（コンピュートノード）が行ったファイルの変更が他のクライアント（コンピュートノード）に確実に伝わったという保証を得ることができる。無効化処理はライトの結果無効となった古いデータをクライアント側のコンピュートノード１Ａ〜１Ｃが先読みしている場合だけに行われる。そうでない場合には，ファイルシステムサーバ部６はプロパゲートを要求したコンピュートノード１Ａ〜１Ｃ上のファイルシステムクライアント部３に直ちに応答を返す。
【００７７】
〔６〕クローズ（ｃｌｏｓｅ）時の処理
ユーザプログラム２が発行したファイル８のクローズ（ｃｌｏｓｅ）要求は，ファイルシステムクライアント部３のクローズ部３４で処理される。クローズ部３４はコヒーレントバッファ４０Ａ〜４０Ｃにライトデータが残っていた場合には，Ｉ／Ｏノード５Ａ〜５Ｃのファイルシステムサーバ部６にコヒーレントバッファ４０Ａ〜４０Ｃの内容を送り，ファイル８に変更を反映する。
【００７８】
〔７〕ディスクＩ／Ｏのスケジューリング
Ｉ／Ｏノード５Ａ〜５Ｃ上のファイルシステムサーバ部６は，ファイルシステムクライアント部３から送られた要求を以下のように処理する。
【００７９】
単一のノードで動作しているユーザプログラムからの要求の場合には，送られてきたディスクアクセス要求を順に処理する。
複数のノード上で動作している並列プログラムからの要求の場合には，モード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，シーケンシャルモードと非シーケンシャルモードとの切り替えを制御する。
【００８０】
図９は，シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
ファイル８は，オープン直後に非シーケンシャルモードに設定される。ファイルシステムサーバ部６のモード切り替え部６３は，各クライアントノード１Ａ〜１Ｃから発行された要求をクライアントノード単位に監視し，アドレスの昇順（クライアントノード毎にみて）にアクセスする要求がすべてのクライアントノードから一定回数以上続くと，シーケンシャルモードに変更する。
【００８１】
シーケンシャルモードの時に一つでも，アドレスの昇順でない要求がきたら非シーケンシャルモードに変更する。一旦非シーケンシャルモードになっても，一定回数以上アドレス昇順の要求が全クライアントノードで続けば，シーケンシャルモードに復帰する。
【００８２】
ディスクＩ／Ｏのスケジューリングは，シーケンシャルモードの場合に行われ，ディスクアクセス要求をキューで管理しながら処理する。非シーケンシャルモードのときには，ディスクアクセス要求を受け付けた順に処理する。
【００８３】
図１０は，シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートであり，リード／ライト要求の処理方法を示している。
非シーケンシャルモードからシーケンシャルモードに遷移したときには，直前の各ノードのディスクアクセス要求の中で最もディスクアクセス終端アドレスの小さいものを基準アドレスとして設定する。図中で「連続」とは要求の始端アドレスが基準アドレスと一致するかまたは小さかったことを意味している。
【００８４】
ファイルシステムサーバ部６は，まず受け付けた要求が連続かどうかを調べ，シーケンシャルモード時に受け付けた要求の始端アドレスが基準アドレスに等しいか小さかった場合には（ステップＳ１１），直ちにその要求を処理し，基準アドレスをこの要求の終端アドレスに変更する（ステップＳ１２）。ディスクアクセスが完了したら，キュー上の先頭につながっている要求を取り出し（ステップＳ１３），ステップＳ１１へ戻って同じ基準で評価する。キューに他の要求がなければ処理を終了して，新しい要求の到着を待つ。
【００８５】
基準アドレスより大きい始端を持つ要求の場合には，この要求を要求の始端アドレスの昇順に並べたキューにつなぐ（ステップＳ１４）。
次に，他のノードからの要求が到着していないかどうかを調べ（ステップＳ１５），到着していれば，ステップＳ１１へ戻り，同様に処理する。
【００８６】
遅延させていた要求あるいは到着している要求の始端アドレスがすべて基準アドレスより大きく，かつ要求を受け付けていないクライアントノード（コンピュートノード）がある場合，一定時間そのノードから要求が到着するのを待つ（ステップＳ１６，Ｓ１７）。この間に到着した要求を同じ基準で評価する。
【００８７】
すべてのノードから要求が到着するか，または一定時間待った後にも基準を満たす要求が見つからなかった場合には，キュー上の先頭にある最も小さな始端アドレスを持つ要求を処理し，基準アドレスを変更する（ステップＳ１８）。この要求の処理が完了したら，キューから他の要求を取り出し（ステップＳ１９），ステップＳ１１へ戻って同じチェックを繰り返す。ステップＳ１８，Ｓ１９において，キューに要求が残っていなければ処理を終了し，新しい要求が到着したときに，同様に処理を繰り返す。
【００８８】
以上の処理の過程で，アドレスの昇順でない要求を見つけたら，見つけた要求とキューにつながれている要求を順にすべて処理し，非シーケンシャルモードに遷移する。
【００８９】
本発明の他の実施の形態として，以下のような実施も可能である。
前述した本発明の実施の形態においては，コヒーレントバッファをファイル単位にＩ／Ｏノード数分もち，各Ｉ／Ｏノードに伝えるデータをＩ／Ｏノード毎のコヒーレントバッファに保持するようにしている。さらに制御を単純化するために，メモリコピーのオーバヘッドが増えるが，バッファにユーザプログラムに渡すイメージのデータを持つことも可能である。すなわち，全Ｉ／Ｏノードに対するデータをまとめて格納するバッファを設けて，前記コヒーレントバッファとの間でコピーするようにしてもよい。
【００９０】
また，前述した本発明の実施の形態においては，Ｉ／Ｏサーバでの要求の並べ替えの精度を高めるために全コンピュートノードから要求が到着するのを一定時間待つ方式を採用している。これを既に到着している要求間だけで，並べ替えを行うように変更することも可能である。
【００９１】
図１１は，本発明を用いた処理と従来の処理との処理結果を比較した図であり，図１１（Ａ）は連続するライト要求の場合，図１１（Ｂ）は連続するリード要求の場合のコヒーレントバッファを用いた処理とそうでない処理の結果の比較を表している。
【００９２】
図中，横軸は転送データのレコードサイズ（単位：バイト），縦軸はスループット（単位：メガバイト／秒）である。コンピュートノードで実行されるプログラムは，典型的なＵＮＩＸインタフェースを持つリード／ライト要求を発行する。
【００９３】
“ｕｆｓ ”（−◇−）は，一つのＩ／Ｏノードでローカルファイルシステムがアクセスされている場合の参考のための処理結果，“ｓｐｆｓ１ｎ”（−◆−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ１ｎ（ｃ．ｂ．）”（−□−）はストライピング・ファクターが１（Ｉ／Ｏノード数が１）で本発明によるコヒーレントバッファを用いた場合の処理結果，“ｓｐｆｓ３ｎ”（−■−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）でコヒーレントバッファを用いない場合の処理結果，“ｓｐｆｓ３ｎ（ｃ．ｂ．）”（−△−）はストライピング・ファクターが３（Ｉ／Ｏノード数が３）で本発明によるコヒーレントバッファを用いた場合の処理結果である。
【００９４】
図１１（Ａ），（Ｂ）に示されるように，コヒーレントバッファを用いない場合の処理結果は，リード／ライト要求時のデータが十分に大きい場合を見る限りではＩ／Ｏノードの数に比例したスループットを得ている。しかし，要求データのサイズが小さい時には，スループットはかなり低い。
【００９５】
一方，本発明によるコヒーレントバッファを使用した場合，スループットはデータ長にかかわらず，Ｉ／Ｏノード数に比例した結果が得られている。
【００９６】
【発明の効果】
以上説明したように，本発明によれば，ファイル更新結果の他ノードへの反映のタイミングをユーザプログラムから通知してもらうメカニズムを設け，同一ファイルに対する更新を各ノードで並行して行えるようにし，かつ複数のノードから発行されたＩ／Ｏ要求をＩ／Ｏノード上でディスクアクセス時間が最短になるように並べ替えることで，ファイルのライトシェアを行っている既存のユーザプログラムのＩ／Ｏ性能を飛躍的に向上させることができる。
【００９７】
具体的には，以下のような効果を奏する。
１）サーバノード上に存在する一つのファイルを複数のクライアントノードが同時に更新する場合にも，ファイルを破壊することなく高速に処理することができる。
【００９８】
２）ファイルが複数のサーバノード上のディスクにストライプ配置（Ｉ／Ｏノードストライピング）された環境で，クライアントノード上で動くユーザプログラムが発行するリード／ライト要求のデータ長が小さくても，ファイルが存在するサーバノード数に比例した高性能を発揮することができる。
【００９９】
３）さらに，バッファをＩ／Ｏノード単位に持つことにより，データのコピー回数を削減することができる。
４）クライアントノード上で動くユーザプログラムがファイルをアドレスの昇順に不連続にアクセスした場合にも，複数のクライアントからの要求を評価し，ディスクアクセスが連続シーケンシャルになるように要求の処理順を並べ替えることにより，高性能を発揮することができる。
【０１００】
５）複数のクライアントノード上で動作する既存の並列プログラムに最小限の変更を加えるだけで，高性能化することができる。
【図面の簡単な説明】
【図１】本発明の構成例を示すブロック構成図である。
【図２】ファイルのライトシェアを行う並列プログラムの一般的な動作を示す図である。
【図３】コヒーレントバッファの構成例を示す図である。
【図４】ライト要求時のバッファへのデータ設定例を示す図である。
【図５】バッファフルでのライト要求時の並列転送の例を示す図である。
【図６】リード時のバッファへの同時読み込みの例を示す図である。
【図７】バッファとユーザプログラムから発行されるプロパゲート要求の関係を示す図である。
【図８】プロパゲート要求の処理を説明する図である。
【図９】シーケンシャルモードと非シーケンシャルモードとの間の遷移を示す図である。
【図１０】シーケンシャルモード時のディスクＩ／Ｏスケジュールの処理フローチャートである。
【図１１】本発明を用いた処理と従来の処理との処理結果を比較した図である。
【符号の説明】
１Ａ〜１Ｃ コンピュートノード（クライアントノード）
２ ユーザプログラム
３ ファイルシステムクライアント部
３１ オープン部
３２ リード部
３３ ライト部
３４ クローズ部
３５ ファイル更新通知部
３６ Ｉ／Ｏノード毎のバッファ管理部
４Ａ〜４Ｂ Ｉ／ＯノードＡ〜Ｃ用のバッファ
５Ａ〜５Ｃ Ｉ／Ｏノード
６ ファイルシステムサーバ部
６１ データ無効化指示部
６２ 要求アクセス並べ替え部
６３ モード切り替え部
７Ａ〜７Ｃ ディスク
８ ファイル
Claims (4)
- 複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおける制御方法であって，
前記各クライアントノードは，
前記ファイルがストライプ配置されたサーバノード単位にバッファを複数個持ち，
ユーザプログラムの発行したライト要求に対して，そのライト要求のデータを一旦，ライト先のサーバノードに対応するバッファに蓄積し，そのライト先のサーバノードに対応するバッファが一杯になったときに，他のサーバノードに対応するバッファの状態を調べて，前記一杯になったバッファのデータをライト先のサーバノードへ送るとともに，他のサーバノードに対応するバッファに所定量以上のデータが詰まっている場合に，そのサーバノードに対しても同時にデータを送り出し，
ユーザプログラムの発行したリード要求に対しては，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対してバッファ内のデータで解決する
ことを特徴とするファイルシステム制御方法。 - 請求項１記載のファイルシステム制御方法において，
前記クライアントノードが複数のサーバノードからデータを一括して先読みする際に，前記バッファの使用状況を調べ，そのバッファ中の所定量以上のデータがユーザプログラムに送られている場合にのみ先読みを行う
ことを特徴とするファイルシステム制御方法。 - 複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおいて，
前記クライアントノードは，
前記ファイルがストライプ配置されたサーバノード単位に用意される複数のバッファを管理する手段と，
ユーザプログラムの発行したライト要求に対して，そのライト要求のデータを一旦，ライト先のサーバノードに対応するバッファに蓄積し，そのライト先のサーバノードに対応するバッファが一杯になったときに，他のサーバノードに対応するバッファの状態を調べて，前記一杯になったバッファのデータをライト先のサーバノードへ送るとともに，他のサーバノードに対応するバッファに所定量以上のデータが詰まっている場合に，そのサーバノードに対しても同時にデータを送り出すライト要求の処理手段と，
ユーザプログラムの発行したリード要求に対して，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対して前記バッファ内のデータで解決するリード要求の処理手段とを備える
ことを特徴とするパラレルファイルシステム。 - 複数のクライアントノードがネットワークを介して複数のサーバノードに接続され，ストライプ配置によりデータが所定の大きさで前記複数のサーバノード上に分割して配置されたファイルを共用するネットワークファイルシステムにおける各クライアントノードで動作するプログラムを格納したプログラム記憶媒体であって，
前記ファイルがストライプ配置されたサーバノード単位に用意される複数のバッファを管理する手段と，
ユーザプログラムの発行したライト要求に対して，そのライト要求のデータを一旦，ライト先のサーバノードに対応するバッファに蓄積し，そのライト先のサーバノードに対応するバッファが一杯になったときに，他のサーバノードに対応するバッファの状態を調べて，前記一杯になったバッファのデータをライト先のサーバノードへ送るとともに，他のサーバノードに対応するバッファに所定量以上のデータが詰まっている場合に，そのサーバノードに対しても同時にデータを送り出すライト要求の処理手段と，
ユーザプログラムの発行したリード要求に対して，複数のサーバノードからデータを一括して先読みし，後続のリード要求に対して前記バッファ内のデータで解決するリード要求の処理手段として，
コンピュータを機能させるためのプログラムを格納した
ことを特徴とするコンピュータ読み取り可能なプログラム記憶媒体。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13947297A JP3545906B2 (ja) | 1997-05-29 | 1997-05-29 | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 |
| US09/042,798 US6385624B1 (en) | 1997-05-29 | 1998-03-17 | File system control method, parallel file system and program storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP13947297A JP3545906B2 (ja) | 1997-05-29 | 1997-05-29 | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 |
Related Child Applications (3)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003103192A Division JP3574649B2 (ja) | 2003-04-07 | 2003-04-07 | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 |
| JP2003330309A Division JP3981057B2 (ja) | 2003-09-22 | 2003-09-22 | ファイルシステム制御方法およびプログラム記憶媒体 |
| JP2003330308A Division JP2004046898A (ja) | 2003-09-22 | 2003-09-22 | ファイルシステム制御方法およびプログラム記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH10334067A JPH10334067A (ja) | 1998-12-18 |
| JP3545906B2 true JP3545906B2 (ja) | 2004-07-21 |
Family
ID=15246048
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP13947297A Expired - Fee Related JP3545906B2 (ja) | 1997-05-29 | 1997-05-29 | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6385624B1 (ja) |
| JP (1) | JP3545906B2 (ja) |
Families Citing this family (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2002196960A (ja) * | 2000-12-25 | 2002-07-12 | Hitachi Ltd | ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム |
| EP1229433A1 (en) * | 2001-01-31 | 2002-08-07 | Hewlett-Packard Company | File sort for backup |
| US7197536B2 (en) * | 2001-04-30 | 2007-03-27 | International Business Machines Corporation | Primitive communication mechanism for adjacent nodes in a clustered computer system |
| JP2005509943A (ja) * | 2001-11-13 | 2005-04-14 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | セマフォを使用する効率的なｆｉｆｏ通信 |
| US20030191761A1 (en) * | 2002-04-04 | 2003-10-09 | International Business Machines Corporation | Methods and apparatus for remote file access |
| US7376713B2 (en) * | 2002-06-27 | 2008-05-20 | International Business Machines Corporation | Apparatus, system and method of distributing block data on a private network without using TCP/IP |
| US8417678B2 (en) * | 2002-07-30 | 2013-04-09 | Storediq, Inc. | System, method and apparatus for enterprise policy management |
| US7805449B1 (en) | 2004-10-28 | 2010-09-28 | Stored IQ | System, method and apparatus for enterprise policy management |
| US8612404B2 (en) * | 2002-07-30 | 2013-12-17 | Stored Iq, Inc. | Harvesting file system metsdata |
| US7610329B2 (en) | 2002-07-30 | 2009-10-27 | Storediq, Inc. | Method and apparatus for managing file systems and file-based data storage |
| US7925246B2 (en) | 2002-12-11 | 2011-04-12 | Leader Technologies, Inc. | Radio/telephony interoperability system |
| US8195714B2 (en) | 2002-12-11 | 2012-06-05 | Leaper Technologies, Inc. | Context instantiated application protocol |
| US20050050135A1 (en) * | 2003-08-25 | 2005-03-03 | Josef Hallermeier | Handheld digital multimedia workstation and method |
| US7273179B2 (en) * | 2004-07-09 | 2007-09-25 | Datalogic Scanning, Inc. | Portable data reading device with integrated web server for configuration and data extraction |
| US7844582B1 (en) | 2004-10-28 | 2010-11-30 | Stored IQ | System and method for involving users in object management |
| US8510331B1 (en) | 2004-10-28 | 2013-08-13 | Storediq, Inc. | System and method for a desktop agent for use in managing file systems |
| JP2010033125A (ja) * | 2008-07-25 | 2010-02-12 | Hitachi Ltd | ストレージ装置及びデータ転送方法 |
| US8082313B2 (en) * | 2009-10-26 | 2011-12-20 | International Business Machines Corporation | Efficient utilization of read-ahead buffer by partitioning read-ahead buffer in correspondence with selectors |
| US8612374B1 (en) | 2009-11-23 | 2013-12-17 | F5 Networks, Inc. | Methods and systems for read ahead of remote data |
| US9015333B2 (en) | 2009-12-18 | 2015-04-21 | Cisco Technology, Inc. | Apparatus and methods for handling network file operations over a fibre channel network |
| US9330055B2 (en) | 2013-06-04 | 2016-05-03 | International Business Machines Corporation | Modular architecture for extreme-scale distributed processing applications |
| JP6503945B2 (ja) * | 2015-07-13 | 2019-04-24 | 富士通株式会社 | 情報処理装置、並列計算機システム、ファイルサーバ通信プログラム及びファイルサーバ通信方法 |
| JP6981473B2 (ja) * | 2017-09-21 | 2021-12-15 | 日本電信電話株式会社 | 秘密読み書き装置、秘密読み書き方法、およびプログラム |
| US11855898B1 (en) | 2018-03-14 | 2023-12-26 | F5, Inc. | Methods for traffic dependent direct memory access optimization and devices thereof |
| CN111104344B (zh) * | 2019-11-06 | 2023-11-03 | 无锡科技职业学院 | 一种基于d-s证据理论的分布式文件***数据读取方法 |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4831552A (en) * | 1987-01-29 | 1989-05-16 | International Business Machines Corporation | Method for concurrently displaying entries from a plurality of different electronic calendars based on interactively entered non-temporal criteria |
| US4853843A (en) * | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
| US5157776A (en) * | 1987-12-30 | 1992-10-20 | Zenith Data Systems Corporation | High speed memory for microcomputer systems |
| US5208914A (en) * | 1989-12-29 | 1993-05-04 | Superconductor Systems Limited Partnership | Method and apparatus for non-sequential resource access |
| US5261059A (en) * | 1990-06-29 | 1993-11-09 | Digital Equipment Corporation | Crossbar interface for data communication network |
| JPH0480841A (ja) | 1990-07-24 | 1992-03-13 | Nec Corp | ファイル更新方式 |
| US5852747A (en) * | 1995-09-08 | 1998-12-22 | International Business Machines Corporation | System for awarding token to client for accessing first data block specified in client request without interference due to contention from other client |
| US5918020A (en) * | 1997-02-28 | 1999-06-29 | International Business Machines Corporation | Data processing system and method for pacing information transfers in a communications network |
-
1997
- 1997-05-29 JP JP13947297A patent/JP3545906B2/ja not_active Expired - Fee Related
-
1998
- 1998-03-17 US US09/042,798 patent/US6385624B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH10334067A (ja) | 1998-12-18 |
| US6385624B1 (en) | 2002-05-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3545906B2 (ja) | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 | |
| US20190075163A1 (en) | Apparatus including an i/o interface and a network interface and related method of use | |
| Lougher et al. | The design of a storage server for continuous media | |
| JP3726484B2 (ja) | 記憶サブシステム | |
| US7124152B2 (en) | Data storage device with deterministic caching and retention capabilities to effect file level data transfers over a network | |
| JP5142995B2 (ja) | メモリページ管理 | |
| US20080270698A1 (en) | Data migration including operation environment information of a host computer | |
| JP2004185349A (ja) | ジャーナルログを利用した更新データ書込方法 | |
| JPH11282631A (ja) | 入出力制御装置および入出力制御方法 | |
| US7275072B2 (en) | Data processing system and method with data sharing for the same | |
| US6687764B2 (en) | File I/O control method | |
| US5822773A (en) | Method and system for accelerating the copying of repetitively copied computer data | |
| JPH06332625A (ja) | ファイルのデータ多重化方法及びデータ処理システム | |
| US20110252205A1 (en) | Managing Access Commands By Multiple Level Caching | |
| JP3609841B2 (ja) | ファイル管理装置 | |
| JPH0622015B2 (ja) | データ処理システムの制御方法 | |
| JP3574649B2 (ja) | ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 | |
| JP4606998B2 (ja) | ネットワークキャッシュ装置およびプログラム | |
| JP3981057B2 (ja) | ファイルシステム制御方法およびプログラム記憶媒体 | |
| JP2004046898A (ja) | ファイルシステム制御方法およびプログラム記憶媒体 | |
| Bosch | Mixed-media file systems | |
| JP2774728B2 (ja) | ディスクアレイ制御方式 | |
| JP2004206424A (ja) | データ処理装置及びデータ処理装置におけるデータ転送方法 | |
| Bosch et al. | Cut-and-Paste file-systems: integrating simulators and file systems | |
| KR20190069134A (ko) | 응용 프로그램간 파일 공유 장치 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20030722 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040113 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040315 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040406 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040409 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080416 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090416 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100416 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110416 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120416 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130416 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140416 Year of fee payment: 10 |
|
| LAPS | Cancellation because of no payment of annual fees |