JPH10334067A - ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 - Google Patents

ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体

Info

Publication number
JPH10334067A
JPH10334067A JP9139472A JP13947297A JPH10334067A JP H10334067 A JPH10334067 A JP H10334067A JP 9139472 A JP9139472 A JP 9139472A JP 13947297 A JP13947297 A JP 13947297A JP H10334067 A JPH10334067 A JP H10334067A
Authority
JP
Japan
Prior art keywords
data
node
nodes
request
file
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.)
Granted
Application number
JP9139472A
Other languages
English (en)
Other versions
JP3545906B2 (ja
Inventor
Yoshitake Shinkai
慶武 新開
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP13947297A priority Critical patent/JP3545906B2/ja
Priority to US09/042,798 priority patent/US6385624B1/en
Publication of JPH10334067A publication Critical patent/JPH10334067A/ja
Application granted granted Critical
Publication of JP3545906B2 publication Critical patent/JP3545906B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

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)

Abstract

(57)【要約】 【課題】複数のクライアントノードとサーバノードとを
高速の接続網で接続した並列計算機上で動作する並列プ
ログラム向けファイルシステムの技術に関し，既存のユ
ーザプログラム2 を大きく変更することなく，Ｉ／Ｏ性
能を向上させることができるようにする。 【解決手段】ライト部33は，ユーザプログラム2 の発行
したライト要求のライトデータを一旦Ｉ／Ｏノード毎に
用意したバッファ4A〜4Cに蓄積し，一杯になったところ
で一括して複数のＩ／Ｏノード5A〜5Cに送出する。リー
ド部32は，ユーザプログラム2 の発行したリード要求に
対しデータを先読みし，後続のリード要求は自ノードの
バッファ4A〜4Cのデータで解決する。ファイル更新結果
の他ノードへの反映は，ユーザプログラム2 からファイ
ル更新通知部35を呼び出すことで行う。

Description

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

Claims (10)

    【特許請求の範囲】
  1. 【請求項１】 複数の計算機のノードがネットワークを
    介してファイルを共用するネットワークファイルシステ
    ムにおける制御方法であって，ファイルの更新を他のノ
    ードに伝えるファイル更新通知機構を持ち，各ノード
    は，前記ファイルに対するリードデータまたはライトデ
    ータを自ノード内にバッファリングし，あるノードにお
    けるプログラムは，ファイルの更新データに関するコン
    システンシが必要なときに，前記ファイル更新通知機構
    を呼び出し，前記ファイル更新通知機構は，前記各ノー
    ドがバッファに保持する該当データを無効化することを
    特徴とするファイルシステム制御方法。
  2. 【請求項２】 複数のクライアントノードがネットワー
    クを介して複数のサーバノード上にストライプ配置され
    たファイルを共用するネットワークファイルシステムに
    おける制御方法であって，前記各クライアントノード
    は，ユーザプログラムの発行したライト要求のデータを
    一旦バッファに蓄積し，バッファが一杯になった時点ま
    たはバッファ内のデータが所定量以上になった時点で一
    括して複数のサーバノードへ送り出し，ユーザプログラ
    ムの発行したリード要求に対しては，複数のサーバノー
    ドからデータを一括して先読みし，後続のリード要求に
    対してバッファ内のデータで解決することを特徴とする
    ファイルシステム制御方法。
  3. 【請求項３】 請求項２記載のファイルシステム制御方
    法において，前記各クライアントノードは，前記バッフ
    ァを，前記ファイルがストライプ配置されたサーバノー
    ド単位に複数個持ち，ユーザプログラムの発行したライ
    ト要求のデータにより一つのバッファが一杯になったと
    きに，他のバッファに所定量以上のデータが蓄積されて
    いれば同時に複数のサーバノードへデータを送り出すこ
    とを特徴とするファイルシステム制御方法。
  4. 【請求項４】 複数のクライアントノードがネットワー
    クを介して１または複数のサーバノード上のファイルを
    共用するネットワークファイルシステムにおける制御方
    法であって，前記サーバノードは，前記クライアントノ
    ードから直前のアクセスと非連続な範囲をアクセスする
    要求を受け取ると，他のクライアントノードからの要求
    が到着していないかをチェックし，アクセスが記憶媒体
    のアドレスの昇順になるように要求の処理順序を並べ替
    えて入出力を実行することを特徴とするファイルシステ
    ム制御方法。
  5. 【請求項５】 複数のクライアントノードがネットワー
    クを介して１または複数のサーバノード上のファイルを
    共用するネットワークファイルシステムにおける制御方
    法であって，前記サーバノードは，アクセス要求を記憶
    媒体のアドレスの昇順になるように並べ替えて処理する
    シーケンシャルモードと，アクセス要求を受け付けた順
    に処理する非シーケンシャルモードとの切り替え手段を
    持ち，前記各クライアントノードから発行されたアクセ
    ス要求が，記憶媒体のアドレスの昇順であるかどうかを
    クライアントノード単位に監視し，非シーケンシャルモ
    ードのときに，記憶媒体のアドレスの昇順にアクセスす
    る要求がすべてのクライアントノードから所定の回数以
    上続くと前記シーケンシャルモードへ遷移し，シーケン
    シャルモードのときに，前記いずれかのクライアントノ
    ードから記憶媒体のアドレスの昇順でないアクセス要求
    がくると前記非シーケンシャルモードへ遷移することを
    特徴とするファイルシステム制御方法。
  6. 【請求項６】 複数のクライアントノードがネットワー
    クを介して複数のサーバノード上にストライプ配置され
    たファイルを共用するネットワークファイルシステムに
    おいて，前記クライアントノードは，前記ファイルがス
    トライプ配置されたサーバノード単位に用意される複数
    のバッファを管理する手段と，自クライアントノードで
    動作する並列プログラムからのファイルに対するアクセ
    ス要求を処理する手段と，自クライアントノードで動作
    する並列プログラムからの指示により該当する前記サー
    バノードへファイル更新通知を行うとともに，前記サー
    バノードからのファイル更新通知により自バッファ内の
    データを無効化する手段とを有するファイルシステムク
    ライアント部を備え，前記サーバノードは，前記クライ
    アントノードからの要求によりファイルに対するアクセ
    スを処理する手段と，前記クライアントノードからのフ
    ァイル更新通知により，該当するデータを保持する他の
    クライアントノードへそのデータの無効化を指示する手
    段とを有するファイルサーバ部を備えることを特徴とす
    るパラレルファイルシステム。
  7. 【請求項７】 複数のクライアントノードがネットワー
    クを介して複数のサーバノード上にストライプ配置され
    たファイルを共用するネットワークファイルシステムに
    おける各クライアントノードで動作するプログラムを格
    納したプログラム記憶媒体であって，前記ファイルがス
    トライプ配置されたサーバノード単位に用意される複数
    のバッファを管理する手段と，自クライアントノードで
    動作する並列プログラムからのファイルに対するアクセ
    ス要求を処理する手段と，自クライアントノードで動作
    する並列プログラムからの指示により該当する前記サー
    バノードへファイル更新通知を行うとともに，前記サー
    バノードからのファイル更新通知により自バッファ内の
    データを無効化する手段とを実現するプログラムを格納
    したことを特徴とするプログラム記憶媒体。
  8. 【請求項８】 複数のクライアントノードがネットワー
    クを介して複数のサーバノード上にストライプ配置され
    たファイルを共用するネットワークファイルシステムに
    おける各サーバノードで動作するプログラムを格納した
    プログラム記憶媒体であって，前記クライアントノード
    からの要求によりファイルに対するアクセスを処理する
    手段と，前記クライアントノードからのファイル更新通
    知により，該当するデータを保持する他のクライアント
    ノードへそのデータの無効化を指示する手段とを実現す
    るプログラムを格納したことを特徴とするプログラム記
    憶媒体。
  9. 【請求項９】 複数のクライアントノードがネットワー
    クを介して複数のサーバノード上にストライプ配置され
    たファイルを共用するネットワークファイルシステムに
    おいて，前記クライアントノードは，前記ファイルがス
    トライプ配置されたサーバノード単位に用意される複数
    のバッファを管理する手段と，ユーザプログラムの発行
    したライト要求のデータを前記サーバノード単位に用意
    されるバッファに蓄積し，バッファが一杯になった時点
    またはバッファ内のデータが所定量以上になった時点で
    一括して複数のサーバノードへ送り出すライト要求の処
    理手段と，ユーザプログラムの発行したリード要求に対
    して，複数のサーバノードからデータを一括して先読み
    し，後続のリード要求に対して前記バッファ内のデータ
    で解決するリード要求の処理手段とを備えることを特徴
    とするパラレルファイルシステム。
  10. 【請求項１０】 複数のクライアントノードがネットワ
    ークを介して複数のサーバノード上にストライプ配置さ
    れたファイルを共用するネットワークファイルシステム
    における各クライアントノードで動作するプログラムを
    格納したプログラム記憶媒体であって，前記ファイルが
    ストライプ配置されたサーバノード単位に用意される複
    数のバッファを管理する手段と，ユーザプログラムの発
    行したライト要求のデータを前記サーバノード単位に用
    意されるバッファに蓄積し，バッファが一杯になった時
    点またはバッファ内のデータが所定量以上になった時点
    で一括して複数のサーバノードへ送り出すライト要求の
    処理手段と，ユーザプログラムの発行したリード要求に
    対して，複数のサーバノードからデータを一括して先読
    みし，後続のリード要求に対して前記バッファ内のデー
    タで解決するリード要求の処理手段とを実現するプログ
    ラムを格納したことを特徴とするプログラム記憶媒体。
JP13947297A 1997-05-29 1997-05-29 ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体 Expired - Fee Related JP3545906B2 (ja)

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 true JPH10334067A (ja) 1998-12-18
JP3545906B2 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)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005509943A (ja) * 2001-11-13 2005-04-14 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ セマフォを使用する効率的なｆｉｆｏ通信
JP2017021618A (ja) * 2015-07-13 2017-01-26 富士通株式会社 情報処理装置、並列計算機システム、ファイルサーバ通信プログラム及びファイルサーバ通信方法
WO2019059069A1 (ja) * 2017-09-21 2019-03-28 日本電信電話株式会社 秘密読み書き装置、秘密読み書き方法、およびプログラム
CN111104344A (zh) * 2019-11-06 2020-05-05 无锡科技职业学院 一种基于d-s证据理论的分布式文件系统数据读取方法

Families Citing this family (21)

* Cited by examiner, † Cited by third party
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
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
WO2004012379A2 (en) * 2002-07-30 2004-02-05 Deepfile Corporation Method and apparatus for managing file systems and file-based data storage
US8612404B2 (en) * 2002-07-30 2013-12-17 Stored Iq, Inc. Harvesting file system metsdata
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
US8195714B2 (en) 2002-12-11 2012-06-05 Leaper Technologies, Inc. Context instantiated application protocol
US7925246B2 (en) 2002-12-11 2011-04-12 Leader Technologies, Inc. Radio/telephony interoperability system
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
US8510331B1 (en) 2004-10-28 2013-08-13 Storediq, Inc. System and method for a desktop agent for use in managing file systems
US7844582B1 (en) 2004-10-28 2010-11-30 Stored IQ System and method for involving users in object management
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
US11855898B1 (en) 2018-03-14 2023-12-26 F5, Inc. Methods for traffic dependent direct memory access optimization and devices thereof

Family Cites Families (8)

* Cited by examiner, † Cited by third party
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

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005509943A (ja) * 2001-11-13 2005-04-14 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ セマフォを使用する効率的なｆｉｆｏ通信
JP2017021618A (ja) * 2015-07-13 2017-01-26 富士通株式会社 情報処理装置、並列計算機システム、ファイルサーバ通信プログラム及びファイルサーバ通信方法
WO2019059069A1 (ja) * 2017-09-21 2019-03-28 日本電信電話株式会社 秘密読み書き装置、秘密読み書き方法、およびプログラム
CN111108540A (zh) * 2017-09-21 2020-05-05 日本电信电话株式会社 秘密读写装置、秘密读写方法、以及程序
JPWO2019059069A1 (ja) * 2017-09-21 2020-10-01 日本電信電話株式会社 秘密読み書き装置、秘密読み書き方法、およびプログラム
AU2018336413B2 (en) * 2017-09-21 2020-11-26 Nippon Telegraph And Telephone Corporation Secure reading and writing apparatus, secure reading and writing method, and program
CN111104344A (zh) * 2019-11-06 2020-05-05 无锡科技职业学院 一种基于d-s证据理论的分布式文件系统数据读取方法
CN111104344B (zh) * 2019-11-06 2023-11-03 无锡科技职业学院 一种基于d-s证据理论的分布式文件系统数据读取方法

Also Published As

Publication number Publication date
US6385624B1 (en) 2002-05-07
JP3545906B2 (ja) 2004-07-21

Similar Documents

Publication Publication Date Title
JP3545906B2 (ja) ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体
JP4186602B2 (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
US6381677B1 (en) Method and system for staging data into cache
JP2986088B2 (ja) バッファ・メモリを動作させる方法及び関連する装置
US6230239B1 (en) Method of data migration
US7124152B2 (en) Data storage device with deterministic caching and retention capabilities to effect file level data transfers over a network
US7266538B1 (en) Methods and apparatus for controlling access to data in a data storage system
JP4955677B2 (ja) 領域を解放するための、ストレージボリューム上のファイルから代替ロケーションへのデータの移動
US20040199727A1 (en) Cache allocation
WO2012026034A1 (ja) スケジューラ、マルチコアプロセッサシステムおよびスケジューリング方法
JP5909566B2 (ja) 計算機システム及びその制御方法
JPH11282631A (ja) 入出力制御装置および入出力制御方法
JPH0950667A (ja) ディスク・ドライブを制御する方法
US8776158B1 (en) Asynchronous shifting windows caching for forward and backward video streaming
Van Hensbergen et al. Dynamic policy disk caching for storage networking
JPH08115241A (ja) キャッシュ管理方法およびコンピュータ・システム
JP2000298554A (ja) Ｒａｉｄデータ記憶システムにおける瞬時バックアップを提供する方法及びシステム
CN108139974B (zh) 分布式缓存动态迁移
KR20080031279A (ko) 공간을 비워두기 위해 저장 볼륨 상의 파일로부터 대안의장소로의 데이터 이동
US5822773A (en) Method and system for accelerating the copying of repetitively copied computer data
JP3981057B2 (ja) ファイルシステム制御方法およびプログラム記憶媒体
JP4606998B2 (ja) ネットワークキャッシュ装置およびプログラム
JP3574649B2 (ja) ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体

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