JP2002196960A - ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム - Google Patents

ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム

Info

Publication number
JP2002196960A
JP2002196960A JP2000392686A JP2000392686A JP2002196960A JP 2002196960 A JP2002196960 A JP 2002196960A JP 2000392686 A JP2000392686 A JP 2000392686A JP 2000392686 A JP2000392686 A JP 2000392686A JP 2002196960 A JP2002196960 A JP 2002196960A
Authority
JP
Japan
Prior art keywords
file
processes
request
buffer
collective
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.)
Pending
Application number
JP2000392686A
Other languages
English (en)
Inventor
Koji Sonoda
浩二 薗田
Naoki Utsunomiya
直樹 宇都宮
Hiroyuki Kumazaki
裕之 熊▲崎▼
Toshiya Kurakake
稔也 鞍掛
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2000392686A priority Critical patent/JP2002196960A/ja
Priority to US10/024,336 priority patent/US6687764B2/en
Publication of JP2002196960A publication Critical patent/JP2002196960A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0862—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with prefetch
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
    • G06F3/0656—Data buffering arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0689—Disk arrays, e.g. RAID, JBOD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/6022—Using a prefetch buffer or dedicated prefetch cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/60—Details of cache memory
    • G06F2212/6028—Prefetching based on hints or prefetch instructions

Abstract

(57)【要約】 【課題】 複数のプロセスが同一ファイルを共有アクセ
スするコレクティブＩ／Ｏにおいて、各プロセスのＩ／
Ｏ待ち時間を短縮し、プロセッサ稼働率を向上させる。 【解決手段】 Ｉ／Ｏ要求を発行する各ユーザプロセス
１１１０、１２１０、１３１０、１４１０は、Ｉ／Ｏ要
求を発行するとき、関連する全プロセスの発行するＩ／
Ｏ要求と共に、プロセスの全てがアクセスするファイル
領域情報、プリフェッチを行うか否かを指定する情報、
ディスクのプリアロケートを行うか否かを指定する情報
を、ヒント情報としてシステムに通知する。システム
は、このヒント情報に基づいて、プロセスの全てがアク
セスするファイル領域のデータを格納するバッファを用
意して、全プロセスのＩ／Ｏ処理をこのバッファを使用
して行う。

Description

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、ファイル入出力制
御方法、ファイル管理サーバ及び並列計算機システムに
係り、特に、複数のプロセスを協調動作させて計算を行
う並列計算機におけるファイル入出力制御方法、ファイ
ル管理サーバ及び並列計算機システムに関する。
【０００２】
【従来の技術】並列計算機上に複数のプロセスを起動
し、それら複数のプロセスを協調させて計算を行う並列
計算は、全プロセスが同一のプログラムコードを実行
し、それぞれ異なるデータに対して演算を行うＳＰＭＤ
(Single Program Multiple Data stream）モデルが用い
られて行われる場合が多い。このモデルは、全プロセス
が同一のプログラムコードを実行しているため、ほぼ同
じタイミングで全プロセスからＩ／Ｏ要求が発行される
ことが多い。特に、科学技術計算向けの並列プログラム
における処理は、処理に使用するファイルに格納されて
いるデータが配列データであり、同配列データを複数プ
ロセス間で領域分割することが多く、その場合、ある１
つのプロセスが特定の行や列のデータをアクセスするこ
とになる。特定の行や列のデータは、ファイル上で不連
続状に配置されている。このため、前述のような並列プ
ログラムにおける各プロセスのファイルアクセスパター
ンは不連続領域に対するアクセスとなる。
【０００３】“Dynamic file-access characteristicso
f a production parllel scientific workload”David
Kots，Song Bac Tho，and Sriram Radhakrishanan．Pro
ceedings of Supercomputing '94、pp．640-649、Novem
ber 1994(以下、Kots-94）には、前述したようなファイ
ルアクセスパターンを持つプログラムが、従来のＵＮＩ
Ｘ（登録商標）インタフェースを用いてＩ／Ｏ要求を発
行した場合の欠点として、次の２点を挙げている。
【０００４】（１）各プロセスは、不連続領域の数分の
Ｉ／Ｏ要求を発行することになるため、システムコール
のオーバヘッドが増加する。
【０００５】（２）システムは、複数のプロセスが発行
するＩ／Ｏ要求相互間の関係を把握することができない
ため、各Ｉ／Ｏ要求に応じてランダムなディスクアクセ
スが発生する。
【０００６】一般に、ディスクアクセスは、メモリアク
セスに比べてそのアクセス速度が遅い。さらに、ランダ
ムなディスクアクセスの性能は、ディスクヘッドの移動
を伴うため、連続領域に対するアクセス性能に比べて悪
い。前述のように並列プログラムを実行するプロセスが
それぞれ不連続領域ファイルアクセスを行うと、各プロ
セスから発行されるＩ／Ｏ要求順序が一定していないた
め、不連続なディスク領域アクセスが発生し、ファイル
の入出力性能が大幅に低下することになる。
【０００７】Kots-94 には、さらに、これらの欠点は、
ＵＮＩＸ型のファイル入出力インタフェースが不連続領
域アクセス機能と、複数プロセスのファイル入出力間の
関係を指定する機能とを持たないことに起因するもので
あることを指摘し、それらを解決するための手段とし
て、ストライドＩ／Ｏインタフェースや、関連する全て
のプロセスが同一ファイルに対するＩ／Ｏ要求を発行す
るコレクティブＩ／Ｏインタフェースの使用が有効であ
ると指摘している。
【０００８】ストライドＩ／Ｏインタフェースは、ファ
イル上の不連続領域を１回のＩ／Ｏ要求でアクセスする
ことができるインタフェースであり、コレクティブＩ／
Ｏインタフェースは、複数のプロセスの全てが同一のフ
ァイルに対してＩ／Ｏ要求を発行するインタフェースで
ある。
【０００９】前述のインタフェースの代表例として、
“MPI-2：Extensions to the Message-Passing Interfa
ce”，Message Passing Interface Forum,http：//ww
w．mpi-forum．org/docs/docs．html(以下、ＭＰＩ−２
という）の９章で定義されているＭＰＩ−ＩＯを挙げる
ことができる。また、“Data Sieving and コレクティ
ブI/O in ROMIO”，Rajeev Thakur，William Gropp，Ew
ing Lusk，Proceedings ofthe 7th Symposium on the F
rontiers of Massively Parallel Computaion，Februar
y 1999，pp．182-189（以下、ＲＯＭＩＯという）が知
られており、これは、ＭＰＩ−ＩＯの実現例である。
【００１０】前述のＲＯＭＩＯによれば、前述のような
並列プログラムは、各プロセスが発行するＩ／Ｏ要求が
不連続領域に対するアクセスの場合にも、コレクティブ
Ｉ／Ｏによってそれら全てのＩ／Ｏ要求をマージするこ
とにより連続領域に対するアクセスに変換することがで
き、ファイルの入出力性能を向上させることができる。
ＲＯＭＩＯは、関連する全プロセスがコレクティブＩ／
Ｏ要求を発行し終わるのを待ち合わせ、全てのコレクテ
ィブＩ／Ｏ要求が揃った時点で、全Ｉ／Ｏ要求をマージ
して連続領域に対するアクセスに変換した後にディスク
Ｉ／Ｏを行い、その結果を各プロセスに通知する。前述
のように、ストライドＩ／Ｏインタフェースとコレクテ
ィブＩ／Ｏインタフェースとを用いることにより、複数
プロセスからのファイル入出力性能の向上を図ることが
できる。
【００１１】
【発明が解決しようとする課題】前述した従来技術によ
るコレクティブＩ／Ｏは、関連する全てのプロセスがコ
レクティブＩ／Ｏ要求を発行するまで待ち合わせを行う
ため、プロセス間でコレクティブＩ／Ｏ要求の発行時刻
にばらつきがあった場合、最初にコレクティブＩ／Ｏ要
求を発行したプロセスが全プロセスからコレクティブＩ
／Ｏ要求が発行されるまで待たされ、このため、コレク
ティブＩ／Ｏ要求を発行したプロセスが待ち時間の間、
他の処理を実行することができず、プロセッサの稼動率
を低下させてしまうという問題点を有している。
【００１２】本発明の目的は、前述した従来技術の問題
点を解決し、複数のプロセスからのファイル入出力に係
るファイル入出力性能をコレクティブＩ／Ｏと同等に保
ちながら、各プロセスのファイルＩ／Ｏ待ち時間を短縮
させることのできるファイル入出力制御方法、ファイル
管理サーバ及び並列計算機システムを提供することにあ
る。
【００１３】また、本発明の他の目的は、従来のコレク
ティブＩ／Ｏインタフェースを変更することなく、各プ
ロセスのコレクティブＩ／Ｏ要求の待ち時間を短縮する
ことができるファイル入出力制御方法、ファイル管理サ
ーバ及び並列計算機システムを提供することにある。
【００１４】
【課題を解決するための手段】本発明によれば前記目的
は、複数のプロセスが同一のファイルを共有してアクセ
スするファイル入出力制御方法において、前記複数のプ
ロセスのそれぞれが、自プロセスのファイル入出力要求
と、前記複数のプロセスの全てがアクセスするファイル
領域情報を含むヒント情報とをファイル管理サーバに通
知し、ファイル管理サーバは、前記ヒント情報により通
知されたファイル領域に対し入出力を行うためのバッフ
ァを用意し、前記複数のプロセスからのファイル入出力
要求がファイル読み込み要求の場合、前記用意したバッ
ファに前記ヒント情報で指定されたファイル領域のデー
タをディスクから読み込み、ディスクからの読み込み終
了後、各プロセスがファイル入出力要求で指定したデー
タ領域に、前記用意したバッファの対応するメモリ領域
からメモリコピーを行い、前記複数のプロセスからのフ
ァイル入出力要求がファイル書き込み要求の場合、各プ
ロセスがファイル入出力要求で指定したデータ領域から
前記用意したバッファの対応する領域へのメモリコピー
を行い、前記複数のプロセス全てからのメモリコピーの
終了後、前記用意したバッファのデータを前記ヒント情
報で通知されたファイル領域に対してディスク書き込み
を行うことにより達成される。
【００１５】前述した処理を備える本発明は、コレクテ
ィブＩ／Ｏ発行時に各ユーザプロセスが、自分の担当領
域に加えて、全ユーザプロセスが読み込みを行うファイ
ル領域をヒント情報として指定する。ファイル管理サー
バは、各ユーザプロセスのコレクティブＩ／Ｏ要求発行
時に、ヒント情報により全ユーザプロセスのＩ／Ｏ要求
を把握できるため、その情報を用いて全ユーザプロセス
分のデータを一括してディスクから読み出すことができ
る。この結果、本発明は、他のプロセスのコレクティブ
Ｉ／Ｏ要求発行を待ち合わせる必要がなく、ユーザプロ
セスに早く制御を返すことができプロセッサの利用率の
向上を図ることができる。
【００１６】また、本発明は、一旦ディスクから読み出
したデータを、全ユーザプロセスがコレクティブＩ／Ｏ
要求を発行し終えるまでファイル管理サーバ内のバッフ
ァに保持しておく。そして、他のユーザプロセスがコレ
クティブＩ／Ｏ要求を発行したとき、そのバッファから
該当するデータのみをユーザ空間にコピーする。このた
め、本発明は、必要なディスクアクセスを最初のプロセ
スがコレクティブＩ／Ｏ要求を発行したときの１回のみ
とすることができ、従来のコレクティブＩ／Ｏ方法と同
等の性能を実現することができる。
【００１７】また、本発明は、複数のユーザプロセスが
同一の並列ファイルにＷＲＩＴＥアクセスを行う場合に
おいても前述と同様に適用することができる。すなわ
ち、各ユーザプロセスは、ＷＲＩＴＥコレクティブＩ／
Ｏ要求を発行するとき、全ユーザプロセスが書き込みを
行うファイル領域をヒント情報として指定する。ファイ
ル管理サーバは、このヒント情報を用いて、マージした
Ｉ／Ｏデータの格納に必要なバッファサイズを把握する
ことができ、ファイルサーバ内に即座にバッファを確保
することができる。このため、本発明は、ユーザプロセ
スのコレクティブＩ／Ｏデータを、バッファの該当する
領域にコピーした後、すぐに制御をユーザプロセスに戻
すことができ、プロセッサの利用率を向上させることが
できる。
【００１８】さらに、本発明は、ファイルサーバ内に確
保したバッファを、全ユーザプロセスがコレクティブＩ
／Ｏ要求の発行を完了するまで保持し、全ユーザプロセ
スのコレクティブＩ／Ｏ要求データがそろった時点で１
度だけディスクへの書き込みを行えばよいので、従来の
コレクティブＩ／Ｏ方法と同等の性能を実現することが
できる。
【００１９】
【発明の実施の形態】以下、本発明によるファイル入出
力制御方法、ファイル管理サーバ及び並列計算機システ
ムの一実施形態を図面により詳細に制御する。
【００２０】図１は本発明が適用される並列計算機シス
テムの構成を示すブロック図であり、まず、これについ
て説明する。
【００２１】図示並列計算機システムは、複数の計算ノ
ード１１００、１２００、１３００、１４００と複数の
Ｉ／Ｏノード１５００、１６００、１７００、１８００
とがネットワーク１９００により結合されて構成されて
いる。各計算ノード及び各Ｉ／Ｏノードのそれぞれは、
プロセッサ１１３０、１２３０、１３３０、１４３０、
１５３０、１６３０、１７３０、１８３０とメモリ１１
４０、１２４０、１３４０、１４４０、１５４０、１６
４０、１７４０、１８４０とを備えている。
【００２２】各Ｉ／Ｏノード１５００、１６００、１７
００、１８００のそれぞれには、ディスク１５２０、１
６２０、１７２０、１８２０が接続され、メモリ内に
は、ファイルを管理するファイルサーバ１５１０、１６
１０、１７１０、１８１０が格納されている。また、各
計算ノード上のメモリには、ユーザプロセス１１１０、
１２１０、１３１０、１４１０と、ユーザプロセスから
のＩ／Ｏ要求を受け取り、Ｉ／Ｏノードのファイルサー
バにＩ／Ｏ要求を発行するファイルサーバエージェント
１１２０、１２２０、１３２０、１４２０が格納されて
いる。
【００２３】Ｉ／Ｏサーバ内のファイルサーバ１５１
０、１６１０、１７１０、１８１０は、複数のディスク
１５２０、１６２０、１７２０、１８２０上に並列ファ
イルシステムを構成している。並列ファイルシステムの
構成方法としては、“TFLOPS PFS：Architecture and D
esign of A Highly Efficient Parallel File System-
ユ，Sharad Garg，Proceedings of Super Computing” '
９８，Nov．10 1998 に記載された方法、特開平１１−
１５７２０号公報に記載の方法等を利用することができ
る。
【００２４】図１に示す例は、特開平１１−１５７２０
号公報に記載の方法を用いて並列ファイルシステムを構
築している。すなわち、図１において、各ファイルサー
バ１５１０、１６１０、１７１０、１８１０及びファイ
ルサーバエージェント１１２０、１２２０、１３２０、
１４２０は、並列ファイル内のオフセットとディスクと
を対応付けるファイル構造テーブルを保持しており、フ
ァイル入出力時に、ファイル構造テーブルを参照して各
ディスク毎のアクセス要求を作成する。
【００２５】簡単のため、本発明の実施形態は、並列フ
ァイルが一定サイズのブロックを単位として各ディスク
に分散して格納され、ユーザプロセスがブロック単位で
ファイルにアクセスする例を用いて説明する。しかし、
ファイル構造の定義を任意のファイルオフセットとサイ
ズとで指定したり、あるいは、アクセス範囲を任意のフ
ァイルオフセットとサイズとを用いて指定するようにす
ることも可能である。
【００２６】なお、図１に示すシステムは、計算ノード
内にファイルサーバエージェントを備え、Ｉ／Ｏノード
内にファイルサーバを備えるとしているが、ファイルサ
ーバエージェントとファイルサーバとは、全体で１つの
ファイル管理サーバを構成するものであり、図１に示す
ように分離されていてもよいが、計算ノード内にファイ
ルサーバエージェントとファイルサーバとによるファイ
ル管理サーバを備えるようにしてもよい。また、ファイ
ルサーバエージェントとファイルサーバとによるファイ
ル管理サーバを独立した構成として、ネットワーク１９
００に接続しておいてもよい。
【００２７】図２は各ユーザプロセスが担当する配列デ
ータと、その配列データが格納されている並列ファイル
と、並列ファイルの各ブロックを格納する各ディスク上
のストライプファイルとの関係を説明する図である。
【００２８】各ユーザプロセスが担当する配列データ２
１００、その配列データが格納されている並列ファイル
２２００、及び、並列ファイル２２００の各ブロックを
格納する各ディスク１５２０、１６２０、１７２０、１
８２０上のストライプファイル１５２１、１６２１、１
７２１、１８２１の関係を示している。
【００２９】配列データ２１００は、図示例の場合、４
×４の行列による１６個のブロックからなるとしてお
り、各ユーザプロセスは、それぞれ配列データの異なる
行を担当する。配列データ２１００の各ブロックは、並
列ファイル２２００に行方向優先に格納される。このた
め、各ユーザプロセスは、並列ファイル２２００上の異
なる領域を連続にアクセスすることが可能である。例え
ば、ユーザプロセス１１１０は、配列データのブロック
１〜４からなるサブファイルをアクセスする。これらの
ブロックは、並列ファイル２２００上の先頭の４ブロッ
クに連続配置されているため、並列ファイル２２００の
先頭から４ブロックが連続してアクセスされることにな
る。
【００３０】ところが、並列ファイル２２００は、ブロ
ック単位で異なるディスクのストライプファイル１５２
１、１６２１、１７２１、１８２１に分散格納されてい
るため、ユーザプロセス１１１０の発行するコレクティ
ブＩ／Ｏ要求は、ストライプファイル１５２１、１６２
１、１７２１、１８２１の全てに対してアクセスを行う
ことになる。複数のディスクへのアクセスは、一般に、
並列に実行することができ、このため、高速に分散格納
されている複数のブロックを読み出すことが可能であ
る。
【００３１】図３は各ユーザプロセスが用いるコレクテ
ィブＩ／Ｏインタフェースを説明する図である。
【００３２】コレクティブＩ／Ｏインタフェースは、図
３に示すように、ユーザプロセス自身のＩ／Ｏ要求１１
３０とヒント情報１１４０とにより構成される。Ｉ／Ｏ
要求１１３０には、ファイル識別子fd１１３１、アクセ
スするファイルブロック番号req１１３２、Ｉ／Ｏバッ
ファのアドレス buf１１３３が含まれる。また、ヒント
情報１１４０には、全ユーザプロセスがアクセスするフ
ァイルブロック番号 all_blk１１４１とバッファの保持
期間time１１４２とが含まれる。
【００３３】図３に示す例は、ファイル識別子４で示さ
れるファイルのブロック１から４に対し、 bufで示され
るバッファとの間でＩ／Ｏを行うことを示しており、ヒ
ント情報が、全プロセスのアクセスするファイル領域が
ブロック１から１６であること、及び、ファイルサーバ
内に保持するバッファの保持期間を１０秒とすることを
指定している。なお、バッファの保持期間は、システム
管理者あるいはユーザにより任意に設定することがで
き、長いほどよいが、ファイルサイズによって最適な値
を予測することもできる。
【００３４】図４はファイルサーバエージェントが、ユ
ーザプロセスが指定したコレクティブＩ／Ｏ要求から各
ストライプファイル毎のサブコレクティブＩ／Ｏ要求を
作成するために使用するファイル管理テーブルとファイ
ル構造テーブルとについて説明する図であり、以下、こ
れについて説明する。
【００３５】ファイル管理テーブル１１２１は、オープ
ンしたファイルを管理するためのテーブルであり、オー
プンファイル毎に１つのエントリが用意される。各エン
トリは、ファイル識別子fd１１５０、グループ識別子 G
ID１１５１、全プロセス数 total１１５３、ファイル構
造テーブルへのポインタinfo１１５４により構成され
る。
【００３６】グループ識別子 GID１１５１は、コレクテ
ィブＩ／Ｏを行うプロセスのグループに対し、オープン
ファイル毎にシステムが与える識別子である。全プロセ
ス数total１１５３は、コレクティブＩ／Ｏを行うプロ
セスのグループに含まれる全プロセス数を示す。そし
て、グループ識別子 GID１１５１、全プロセス数 total
１１５３は、ファイルサーバエージェントが作成する各
ストライプファイルへのサブコレクティブＩ／Ｏ要求に
付加され、ファイルサーバが複数プロセスからのサブコ
レクティブＩ／Ｏ要求のマッチングを行うために使用さ
れる。
【００３７】図４において、エントリ１１６０は、ユー
ザプロセス１１１０がコレクティブＩ／Ｏ要求を発行す
るオープンファイルのエントリ例を示しており、ファイ
ル識別子が４、グループ識別子が４３２１、全プロセス
数が４、ファイル構造テーブルへのポインタが１１８０
を指していることを示している。
【００３８】ファイル構造テーブル１１２２は、並列フ
ァイルを構成する全ストライプファイルの識別子 sfile
１１７０と、各ストライプファイルに格納する並列ファ
イルのブロック番号リストblocks１１７１とにより構成
される。このファイル構造テーブル１１２２は、並列フ
ァイル内のあるブロックが、どのストライプファイルに
格納されているかの対応関係を保持している。ファイル
サーバエージェントは、このファイル構造テーブルを参
照してユーザプロセスの発行するコレクティブＩ／Ｏ要
求を各ストライプファイルに対するサブコレクティブＩ
／Ｏ要求に変換する。
【００３９】図４において、１つのファイル構造テーブ
ル１１８０は、ユーザプロセス１１１０がコレクティブ
Ｉ／Ｏを発行している並列ファイルの構造を示してお
り、ストライプファイル１５２１、１６２１、１７２
１、１８２１が、それぞれ（１、５、９、１３）、
（２、６、１０、１４）、（３、７、１１、１５）、
（４、８、１２、１６）のブロックを格納していること
を示している。ここで、ファイル構造テーブルに記述さ
れているブロック番号は、並列ファイルの先頭からのブ
ロック番号である。そして、ブロック番号リスト１１７
１内の順番が、各ストライプファイル内でのブロック番
号に対応しており、ファイルサーバエージェントが作成
する各ストライプファイルに対するサブコレクティブＩ
／Ｏ要求は、このストライブファイル内でのブロック番
号を指定する。
【００４０】図５はファイルサーバエージェントがユー
ザプロセスのコレクティブＩ／Ｏ要求を元に作成するス
トライプファイルへのサブコレクティブＩ／Ｏ要求を説
明する図である。
【００４１】サブコレクティブＩ／Ｏ要求１９１０は、
ストライブファイル識別子 r-sfile１９１１、グループ
識別子 r-GID１９１２、全プロセス数 r-total１９１
４、全ユーザプロセスがアクセスするストライプファイ
ルブロック番号all_sblk１９１５、Ｉ／Ｏ種別 r-cmd１
９１６、Ｉ／Ｏ要求ストライプファイルブロック r-req
１９１７、データr-data１９１８、ファイルサーバ上で
のバッファ保持期間time１９１９により構成される。
【００４２】ストライプファイル識別子 r-sfile１９１
１は、ファイル構造テーブル１１２２内のストライプフ
ァイル識別子リスト sfile１１７０から取得する。グル
ープ識別子 r-GID１９１２と全プロセス数 r-total１９
１４とは、ファイル管理テーブル１１２１内のグループ
識別子 GID１１５１と全プロセス数 total１１５３とか
ら取得する。Ｉ／Ｏ種別 r-cmd１９１６は、ユーザのコ
レクティブＩ／Ｏ要求から取得する。Ｉ／Ｏ要求ストラ
イプファイルブロック r-req１９１７と全ユーザプロセ
スがアクセスするストライプファイルブロック番号all_
sblk１９１５とは、ユーザが指定したコレクティブＩ／
Ｏ要求とヒント情報とを用い、ファイル構造テーブル１
１２２を参照して作成する。なお、サブコレクティブＩ
／Ｏ要求の作成処理の詳細は後述する。
【００４３】図６はファイルサーバが保持するコレクテ
ィブＩ／Ｏ管理テーブルの構成を説明する図であり、以
下、これについて説明する。
【００４４】図示コレクティブＩ／Ｏ管理テーブル１５
１１は、ファイルサーバがコレクティブＩ／Ｏの制御を
行うためのテーブルである。コレクティブＩ／Ｏ管理テ
ーブル１５１１には、コレクティブＩ／Ｏ毎に１つのエ
ントリが割り当てられる。また、各エントリに対応し
て、コレクティブＩ／Ｏバッファ１５６０が１つずつ割
り当てられる。各エントリは、複数のコレクティブＩ／
Ｏ要求を識別するためのストライプファイル識別子 sfi
le１５５１、グループ識別子 GID１５５２、全プロセス
数 total１５５４、コレクティブＩ／Ｏ処理完了プロセ
ス数done１５５５、ヒント情報で与えられたストライプ
ファイルブロック番号リストall_sbuf１５５６、Ｉ／Ｏ
種別 cmd１５５７、コレクティブＩ／Ｏバッファへのア
ドレス buf１５５８、及び、バッファの保持期間time
（１５５９）により構成される。
【００４５】図６に示す例は、ストライプファイル１５
２１に対しグループ識別子４３２１を持つグループが２
回目のコレクティブＩ／Ｏを実行していることを示して
いる。また、当グループを構成するプロセス数は４、全
プロセスがアクセスするストライプファイルブロックは
１、２、３、４の読み込み要求であり、すでに1つのプ
ロセスがＩ／Ｏ要求を完了している。そして、r-dataが
指すバッファの有効期間は１０秒である。
【００４６】次に、本発明の実施形態におけるコレクテ
ィブＩ／Ｏ方法の処理について説明する。
【００４７】図７はファイルサーバエージェントの処理
動作を説明するフローチャート、図８はファイルサーバ
エージェントのサブコレクティブＩ／Ｏ要求作成の処理
動作を説明するフローチャート、図９はファイルサーバ
の処理動作を説明するフローチャート、図１０はコレク
ティブＩ／Ｏバッファのタイムアウト処理の動作を説明
するフローチャートであり、以下、これらのフローを参
照して、本発明の実施形態におけるコレクティブＩ／Ｏ
方法の処理について説明する。
【００４８】最初に図７を用いてファイルサーバエージ
ェントの処理動作を説明する。
【００４９】（１）ユーザプロセスがコレクティブＩ／
Ｏインタフェースを用いて発行したコレクティブＩ／Ｏ
要求は、まず始めにユーザプロセスの存在するノード上
のファイルサーバエージェントにより受け取られる（ス
テップ７００１）。
【００５０】（２）コレクティブＩ／Ｏ要求を受け取っ
たファイルサーバエージェントは、ユーザプロセスのＩ
／Ｏデータを各ファイルサーバとの間で通信するための
転送バッファを確保し、コレクティブＩ／Ｏ要求が WRI
TE要求であるか否かを判定する（ステップ７００２、７
００３）。
【００５１】（３）ステップ７００３での判定で、コレ
クティブＩ／Ｏ要求が WRITE要求であった場合、ユーザ
プロセスが指定したデータ領域から、転送バッファにデ
ータをコピーし、ファイルサーバに転送することができ
るようにする（ステップ７００４）。
【００５２】（４）ステップ７００４の処理後、また
は、ステップ７００３で、コレクティブＩ／Ｏ要求が W
RITE要求でなかった場合、ファイルサーバエージェント
は、ユーザプロセスのコレクティブＩ／Ｏ要求を各スト
ライプファイルに対するサブコレクティブＩ／Ｏ要求に
分割する。なお、このステップでのサブコレクティブＩ
／Ｏ要求への分割処理は、図８を参照して後述する（ス
テップ７００５）。
【００５３】（５）ステップ７００５の処理で全ストラ
イプファイルに対するサブコレクティブＩ／Ｏ要求が作
成できると、ファイルサーバエージェントは、各サブコ
レクティブＩ／Ｏ要求を、各ストライプファイルを管理
するファイルサーバに並列に送信して、それらからの応
答を待つ。このとき、送信するサブコレクティブＩ／Ｏ
要求が WRITE要求の場合、転送バッファのデータも同時
に転送する（ステップ７００６）。
【００５４】（６）各ファイルサーバからの応答を受信
すると、Ｉ／Ｏ要求がREADであるか否かを判断し、READ
要求の場合、転送バッファに受信データが格納されてい
るため、該当するデータをユーザプロセスのデータ領域
にコピーする（ステップ７００７〜７００９）。
【００５５】（７）ステップ７００９の処理後、また
は、ステップ７００８でＩ／Ｏ要求がREADでなかった場
合、全てのファイルサーバからの応答受信が完了したか
否かを判断し、完了していた場合、転送バッファを解放
して処理を終了する。また、まだ、応答受信が完了して
いない場合、残りのファイルサーバからの受信待ちから
の処理継続する（ステップ７０１０、７０１１）。
【００５６】次に、前述のステップ７００５でのファイ
ルサーバエージェントがサブコレクティブＩ／Ｏ要求を
作成する処理動作を図８を参照して説明する。このサブ
コレクティブＩ／Ｏ要求の作成は、ファイル管理テーブ
ル１１２１及びファイル構造テーブル１１２２を用いて
おこなわれる。
【００５７】（１）まず、ユーザプロセスが指定したフ
ァイル識別子を用いて、図４に示すファイル管理テーブ
ル１１２１を検索し、オープンファイルエントリ１１６
０を取得する（ステップ７１０１）。
【００５８】（２）次に、オープンファイルエントリに
含まれるファイル構造テーブルへのポインタinfo１１５
４のフィールドを参照して、ファイル構造テーブル１１
２２の該当するエントリ１１８０を取得する（ステップ
７１０２）。
【００５９】（３）前述で説明したように、ステップ７
１０２で取得したエントリ１１８０には並列ファイルを
構成する全ストライプファイルと、各ストライプファイ
ルが格納している並列ファイル内のブロック番号のリス
トが記述されているので、ファイルサーバエージェント
は、各ストライプファイルのブロック番号リストを取得
しする（ステップ７１０３）。
【００６０】（４）そして、ファイルサーバエージェン
トは、ユーザプロセスが指定したＩ／Ｏ要求ブロックと
ヒント情報で指定された全ユーザプロセスアクセスブロ
ックとのうち、各ストライプファイルに格納されている
ブロックを抽出する（ステップ７１０４）。
【００６１】（５）さらに、ファイルサーバエージェン
トは、抽出したブロックの番号を各ストライプファイル
内のブロック番号に変換し、ブロック番号の変換が完了
すると、そのブロック番号とオープンファイルエントリ
の情報をまとめてサブコレクティブＩ／Ｏ要求を作成す
る。サブコレクティブＩ／Ｏ要求の構成は、図５に示し
た通りである（ステップ７１０５、７１０７）。
【００６２】（６）全てのストライプファイルに対する
サブコレクティブＩ／Ｏ要求の作成処理が完了したか否
かを調べ、完了していなければステップ７１０３からの
処理を繰り返し実行し、完了している場合、ここでの処
理を終了する（ステップ７１０８）。
【００６３】図９はファイルサーバにおける処理動作を
説明するフローチャートであり、次に、これについて説
明する。
【００６４】（１）ファイルサーバは、サブコレクティ
ブＩ／Ｏ要求を受信すると、コレクティブＩ／Ｏ管理テ
ーブル１５１１を検索する。この検索処理は、受信した
サブコレクティブＩ／Ｏ要求に含まれるストライプファ
イル識別子１９１１とグループ識別子１９１２とをキー
として行われる（ステップ７２０１、７２０２）。
【００６５】（２）ステップ７２０２での検索処理の結
果、該当するエントリが存在するか否かを判定し、該当
するエントリが存在しない場合、新規なエントリを作成
してコレクティブＩ／Ｏ管理テーブル１５１１に登録す
る。このとき、登録するエントリの初期化は、サブコレ
クティブＩ／Ｏ要求に含まれるストライプファイル識別
子１９１１、グループ識別子１９１２、全プロセス数１
９１４、全プロセスがアクセスするブロックリスト１９
１５、Ｉ／Ｏ種別１９１６、コレクティブＩ／Ｏバッフ
ァの保持期間１９１９の情報を、コレクティブＩ／Ｏ管
理テーブル１５１１のストライプファイル識別子１５５
１、グループ識別子１５５２、全プロセス数１５５４、
全プロセスがアクセスするブロックリスト１５５６、Ｉ
／Ｏ種別１５５７、コレクティブＩ／Ｏバッファの保持
期間１５５９に格納し、コレクティブＩ／Ｏ処理完了プ
ロセス数done１５５５を“０”にクリアすることにより
行う（ステップ７２０３、７２０４）。
【００６６】（３）ステップ７２０４の処理後、また
は、ステップ７２０３の判定で、該当するエントリが存
在していた場合、すなわち、コレクティブＩ／Ｏ管理テ
ーブル１５１１のエントリが取得できると、次にコレク
ティブＩ／Ｏバッファが割り当てられているか否かをチ
ェックする（ステップ７２０５）。
【００６７】（４）ステップ７２０５のチェックで、コ
レクティブＩ／Ｏバッファが割り当てられていなかった
場合、コレクティブＩ／Ｏバッファを確保し、コレクテ
ィブＩ／Ｏ管理テーブルのコレクティブＩ／Ｏバッファ
アドレス１５５８への登録を行ってエントリを登録する
と共にタイマを起動する。このとき、タイマのタイムア
ウト期間は、コレクティブＩ／Ｏ管理テーブルのバッフ
ァの保持期間１５５９に設定する（ステップ７２０
６）。
【００６８】（５）ステップ７２０６の処理で、コレク
ティブＩ／Ｏバッファの確保を行うことができると、Ｉ
／Ｏ要求種別がREAD要求か否かを調べ、READ要求の場
合、全プロセスがアクセスするブロックの内容をディス
クからコレクティブＩ／Ｏ用バッファに読み込む（ステ
ップ７２０７、７２０８）。
【００６９】（６）ステップ７２０８の処理で、全プロ
セスがアクセスするブロックの内容をディスクからコレ
クティブＩ／Ｏ用バッファに読み込んだ後、ステップ７
２０５でのチェックで、コレクティブＩ／Ｏバッファが
すでに割り当てられていた場合、または、ステップ７２
０７の判定で、Ｉ／Ｏ要求種別がREAD要求でなかった場
合、再びＩ／Ｏ要求種別がREAD要求か否かを調べる（ス
テップ７２０９）。
【００７０】（７）ステップ７２０９での判定で、Ｉ／
Ｏ要求種別がREAD要求であった場合、コレクティブＩ／
Ｏバッファ上の該当するデータをサブコレクティブＩ／
Ｏ要求を送信してきたファイルサーバエージェントに送
信し、Ｉ／Ｏ要求種別がREAD要求でない場合（すなわ
ち、WRITEの場合)、サブコレクティブＩ／Ｏ要求に含ま
れる書き込みデータをコレクティブＩ／Ｏ用バッファの
該当する領域に書き込む（ステップ７２１０、７２１
１）。
【００７１】（８）前述までの処理で、１つのファイル
サーバエージェントからのサブコレクティブＩ／Ｏ要求
の処理が完了するので、コレクティブＩ／Ｏ管理テーブ
ルのコレクティブＩ／Ｏ処理完了プロセス数done１５５
５をインクリメントする（ステップ７２１２）。
【００７２】（９）さらに、コレクティブＩ／Ｏ処理完
了プロセス数done１５５５と全プロセス数 total１５５
４とを比較し、全プロセスのコレクティブＩ／Ｏ処理が
完了したか否かを調べ、全プロセスのコレクティブＩ／
Ｏ処理が完了していなければ、ここでの処理終了し、次
のサブコレクティブＩ／Ｏ要求の受信を待つ（ステップ
７２１３）。
【００７３】（10）ステップ７２１３の判定で、全プロ
セスのコレクティブＩ／Ｏ処理が完了していれば、Ｉ／
Ｏ要求種別がWRITE要求か否かを調べ、WRITE要求の場
合、コレクティブＩ／Ｏ用バッファの内容をディスクに
書き込む（ステップ７２１４、７２１５）。
【００７４】（11）ステップ７２１５の処理後、また
は、ステップ７２１４の判定で、Ｉ／Ｏ要求種別が WRI
TE要求でなかった場合、コレクティブＩ／Ｏ用バッファ
とコレクティブＩ／Ｏ管理テーブルのエントリとを解放
し、タイマをキャンセルして、ファイルサーバでの処理
を終了する（ステップ７２１６）。
【００７５】図１０はコレクティブＩ／Ｏバッファの保
持期間が過ぎた場合のファイルサーバでのタイムアウト
処理の動作を説明するフローチャートであり、次に、こ
れについて説明する。
【００７６】（１）コレクティブＩ／Ｏバッファの保持
期間が過ぎタイムアウトが発生すると、そのコレクティ
ブＩ／ＯバッファのＩ／Ｏ種別が WRITE要求か否かを調
べ、 WRITE要求であった場合、コレクティブＩ／Ｏバッ
ファのデータをディスクに書き込む（ステップ７３０１
〜７３０３）。
【００７７】（２）ステップ７３０３でのデータのディ
スクへの書き込みの終了後、または、ステップ７３０２
の判定で、コレクティブＩ／ＯバッファのＩ／Ｏ種別が
WRITE要求でなかった場合、そのコレクティブＩ／Ｏバ
ッファアドレスをコレクティブＩ／Ｏ管理テーブルから
抹消して、コレクティブＩ／Ｏバッファを解放して処理
を終了する（ステップ７３０４）。
【００７８】前述したようなタイムアウトの処理によ
り、一定時間以上の間メモリを保持する必要をなくすこ
とができる。また、タイムアウト発生後に残りのサブコ
レクティブＩ／Ｏ要求を受信した場合、そのときに再び
コレクティブＩ／Ｏバッファを取得することができるた
め、バッファを開放してしまっても問題が生じることは
ない。
【００７９】前述した本発明の実施形態によれば、ユー
ザプロセスがコレクティブＩ／Ｏ要求と共にヒント情報
を通知し、ファイルサーバ内部にコレクティブＩ／Ｏバ
ッファを設けることにより、グループ内の全プロセスの
コレクティブＩ／Ｏ要求を待ち合わせる必要をなくすこ
とができ、この結果、各ユーザプロセスがコレクティブ
Ｉ／Ｏ処理で無駄に待たされることがなく、ＣＰＵの稼
働率を上げることができる。また、前記した本発明の実
施形態によれば、コレクティブＩ／Ｏバッファの保持期
間を指定することができるので、長時間メモリが占有さ
れるという無駄を避けることができる。
【００８０】次に、本発明の他の実施形態を図１１〜図
１５を参照して説明する。
【００８１】以下に説明する本発明の他の実施形態は、
コレクティブＩ／Ｏ要求とヒント情報通知とを分離した
点が前述下実施形態と異なっている。すなわち、前述し
た実施形態は、コレクティブＩ／Ｏ要求時にヒント情報
を通知していたが、他の実施形態は、コレクティブＩ／
Ｏ要求に先立ってヒント情報を通知するようにしてい
る。このようにヒント情報通知とコレクティブＩ／Ｏ要
求とを分離することにより従来のコレクティブＩ／Ｏイ
ンタフェースを変更することなく、ＣＰＵの稼働率を向
上させることがが可能となる。
【００８２】本発明の他の実施形態は、前述した場合と
同様に、図１に示す並列計算機システムに適用されて動
作する。また、各ユーザプロセスも、前述した場合と同
様に、図２に示す配列データをアクセスする。そして、
この実施形態が、前述までに説明した実施形態と異なる
点は、ユーザプロセスからのＩ／Ｏ要求発行方法、ファ
イルサーバエージェントが保持するファイル管理テーブ
ル、及び、ファイルサーバエージェントの処理方法の３
点であり、その他は同様である。このため、以下では、
前述までに説明した実施形態との相違点についてのみ説
明する。
【００８３】図１１は本発明の他の実施形態で使用され
るファイル管理テーブルの構造を説明する図であり、ま
ず、これについて説明する。
【００８４】図示ファイル管理テーブルのエントリは、
ファイル識別子fd３３１０、グループ識別子 GID３３２
０、全プロセス数 total３３３０、ファイル構造テーブ
ルへのポインタinfo３３４０、全プロセスがアクセスす
るブロックリスト all_blk３３５０、コレクティブＩ／
Ｏバッファの保持期間time３３６０、プリフェッチ指示
フィールドpf３３７０、プリアロケート指示フィールド
pa３３８０により構成される。これらのうち、ファイル
識別子３３１０、グループ識別子３３２０、全プロセス
数３３３０、ファイル構造テーブルへのポインタ３３４
０は、図４により説明したものと同一である。
【００８５】そして、全プロセスがアクセスするブロッ
クリスト３３５０、コレクティブＩ／Ｏバッファの保持
期間３３６０、プリフェッチ指示フィールド３３７０、
プリアロケート指示フィールド３３８０は、何れも後述
するヒント情報通知インタフェースで与えられる情報を
保持するためのフィールドである。
【００８６】図１２は本発明の他の実施形態で使用する
ユーザインタフェースを説明する図である。ここで使用
するユーザインタフェースは、何れも MPI-2に定義され
ているインタフェースであるため、インタフェースの具
体的な使用方法はここでは説明せず、本発明の実施形態
で新規に定義する部分についてのみ説明する。
【００８７】説明している本発明の実施形態において、
ユーザプログラムは、コレクティブＩ／Ｏ要求を発行す
る前に、ヒント情報の通知を行う。MPI-IOは、ヒント情
報の通知を、ヒントオブジェクトの作成４１１０、ヒン
トオブジェクトに対する情報の設定４１２０、４１４
０、４１６０、４１９０、ヒント情報の通知４１３０、
４１５０、４１７０、４２００の手順で行う。
【００８８】MPI-2 で予め定義されているヒント情報
は、コレクティブＩ／Ｏでシステムが使用するバッファ
サイズ、コレクティブＩ／Ｏ処理を実行するノード数、
並列ファイルの構成等の静的な情報のみであり、また、
ヒント情報通知インタフェース自身もコレクティブに実
行する必要がある。
【００８９】そして、本発明の他の実施形態は、ヒント
情報として、全プロセスがアクセスする領域のヒント情
報“collective_region”４１２０、コレクティブＩ／
Ｏバッファの保持期間“collbuf_lifetime”４１４０、
プリアロケートを指示する“prealloc”４１６０、プリ
フェッチを指示する“prefetch”４１９０を新設してい
る。また、ヒント情報通知インタフェースは、これらの
ヒント情報を通知する場合、プロセス間の待ち合わせを
行わないようにし、さらに、“collective_region” の
ヒント情報が設定されたファイル識別子を指定したコレ
クティブＩ／Ｏ要求についても、プロセス間の待ち合わ
せを行わないようにする。
【００９０】コレクティブ WRITE要求MPI_WRITE_AT_ALL
４１８０、及び、コレクティブREAD要求 MPI_READ_AT_A
LL４２１０は、“collective_region” ヒント情報が設
定されたとき、プロセス間の待ちあわせを行わないこと
以外、MPI-2 と同一である。
【００９１】図１３はユーザのプリフェッチヒント情報
及びプリアロケートヒント情報によりファイルサーバエ
ージェントから各ストライプファイルのファイルサーバ
に送信されるプリアロケート／プリフェッチ要求のフォ
ーマットを示す図である。
【００９２】プリアロケート／プリフェッチ要求は、ス
トライプファイル識別子 sfile８００１、グループ識別
子 GID８００２、全プロセスがアクセスするブロック番
号 blk８００３、プリアロケート（ＰＡ）かプリフェッ
チ（ＰＦ）かを指定するコマンドフィールド cmd８００
４、コレクティブＩ／Ｏバッファの保持期間time８００
５により構成される。
【００９３】図１４はユーザプロセスがヒント情報通知
インタフェースを実行した場合のファイルサーバエージ
ェントでの処理動作を説明する図であり、以下、これに
ついて説明する。
【００９４】（１）ユーザプロセスがヒント情報を通知
してくると、ファイルサーバエージェントは、ヒント情
報に指定されているファイル識別子を用いてファイル管
理テーブルを検索し、オープンファイルエントリを取得
する（ステップ９００１、９００２）。
【００９５】（２）ヒント情報のタイプが“collective
_region” であるか否かをチェックして、ヒント情報の
タイプが“collective_region” であれば、オープンフ
ァイルエントリの全プロセスがアクセスするブロックを
格納するフィールド３３５０にヒント情報で指定された
値を格納して処理を終了する（ステップ９００３、９０
０７）。
【００９６】（３）ステップ９００３のチェックで、ヒ
ント情報のタイプが“collective_region” でなけれ
ば、ヒント情報のタイプが“collbuf_lifetime”である
か否かをチェックして、ヒント情報のタイプが“collbu
f_lifetime”であれば、オープンファイルエントリのコ
レクティブＩ／Ｏバッファ保持期間を格納するフィール
ドにヒント情報で指定された値を格納して処理を終了す
る（ステップ９００４、９００８）。
【００９７】（４）ステップ９００４のチェックで、ヒ
ント情報のタイプが“collbuf_lifetime”でなければ、
ヒント情報のタイプが“prealloc”であるか否かをチェ
ックして、ヒント情報のタイプが“prealloc”であれ
ば、各ストライプファイルを管理しているファイルサー
バにプリアロケート要求を送信して処理を終了する（ス
テップ９００５、９００９）。
【００９８】（５）ステップ９００５のチェックで、ヒ
ント情報のタイプが“prealloc”でなければ、ヒント情
報のタイプが“prefetch”であるか否かをチェックし
て、ヒント情報のタイプが“prefetch”であれば、各ス
トライプファイルを管理しているファイルサーバにプリ
フェッチ要求を送信し、ヒント情報のタイプが“prefet
ch”でなければ、何もせずに処理を終了する（ステップ
９００６、９０１０）。
【００９９】前述のステップ９００９、９０１０で、各
ファイルサーバに送信するプリアロケート要求やプリフ
ェッチ要求は、図１３により説明したフォーマットで作
成される。そのとき、各ストライプファイルからプリフ
ェッチするブロックやプリアロケートするブロックは、
ファイル管理テーブルのエントリに登録されている全プ
ロセスがアクセスするブロック all_blk３３５０をすで
に説明した本発明の実施形態におけるサブコレクティブ
Ｉ／Ｏ要求作成時と同様に各ストライプ毎のブロック番
号に変換して作成される。また、ファイルサーバエージ
ェントは、プリアロケート要求やプリフェッチ要求の応
答を待たずに処理を終了する。
【０１００】図１５はプリフェッチ要求、プリアロケー
ト要求を受信したファイルサーバでの処理の動作を説明
するフローチャートであり、以下、これについて説明す
る。
【０１０１】（１）ファイルサーバは、プリアロケート
要求またはプリフェッチ要求を受信すると、コレクティ
ブＩ／Ｏ管理テーブルを検索する。この検索は、キーと
して、すでに説明した本発明の実施形態入出力おけるフ
ァイルサーバの処理の場合と同様に、ストライプファイ
ル識別子とグループ識別子とを使用して行われる（ステ
ップ９１０１、９１０２）。
【０１０２】（２）ステップ９１０２での検索の結果、
該当するエントリが存在するか否かを判定し、該当する
エントリが存在しなければ、新規エントリを作成して初
期化した後、そのエントリをコレクティブＩ／Ｏ管理テ
ーブルに登録する。エントリの初期化は、プリフェッチ
要求またはプリアロケート要求に含まれるストライプフ
ァイル識別子８００１、グループ識別子８００２、全プ
ロセスのアクセスするブロック８００３、コレクティブ
Ｉ／Ｏバッファの保持期間８００５を使用して行う（ス
テップ９１０３、９１０４）。
【０１０３】（３）ステップ９１０４の処理により初期
化済みのエントリを取得した後、または、ステップ９１
０３の判定で、コレクティブＩ／Ｏ管理テーブルに該当
するエントリが存在した場合、コレクティブＩ／Ｏバッ
ファが割り当てられているか否かを調べ、コレクティブ
Ｉ／Ｏバッファが割り当てられていなければ、新しくコ
レクティブＩ／Ｏバッファを割り当てて、前記エントリ
への登録と、タイマの起動を行う（ステップ９１０５、
９１０６）。
【０１０４】（４）ステップ９１０６の処理でコレクテ
ィブＩ／Ｏバッファを取得した後、または、ステップ９
１０５の判定で、コレクティブＩ／Ｏバッファがすでに
存在していた場合、要求がプリフェッチ要求であるか否
かを調べ、要求がプリフェッチ要求であった場合、コレ
クティブＩ／Ｏバッファにストライプファイルからデー
タを読み込んで処理を終了する（ステップ９１０７、９
１０８）。
【０１０５】（５）ステップ９１０７の判定で、要求が
プリフェッチ要求でなければ、次に要求がプリアロケー
ト要求か否かを調べる。この結果、プリアロケート要求
でなければ、何もせずに処理を終了し、プリアロケート
要求であった場合、ディスクブロックの確保を行って処
理を終了する（ステップ９１０９、９１１０）。
【０１０６】前述で説明した処理において、プリフェッ
チ要求の場合もプリアロケート要求の場合も、使用する
ファイルブロックとしては全プロセスがアクセスするブ
ロック blk８００３が使用される。
【０１０７】前述で説明した本発明の他の実施形態にお
いて、ユーザプロセスがコレクティブＩ／Ｏ要求を発行
したときのファイルサーバエージェント及びファイルサ
ーバでの処理は、基本的にすでに説明した実施形態の場
合と同様である。唯一異なる点は、ファイルサーバエー
ジェントがサブコレクティブＩ／Ｏ要求を作成する場合
に必要とする全プロセスがアクセスするファイルブロッ
クとコレクィブＩ／Ｏバッファの保持期間との情報を、
すでに説明した実施形態の場合、ユーザがコレクティブ
Ｉ／Ｏ要求と同時に指定したヒント情報から取得してい
たのに対し、他の実施形態の場合、ファイル管理テーブ
ルのエントリから取得する点である。
【０１０８】前述した本発明の他の実施形態によれば、
ヒント情報通知インタフェースを設け、ファイル管理テ
ーブル内にヒント情報を保持しておくようにしているの
で、従来のコレクティブＩ／Ｏインタフェースを変更す
ることなくＣＰＵの稼働率を向上させることが可能とな
る。また、前述した本発明の他の実施形態によれば、ヒ
ント情報通知インタフェースを分離し、プリアロケート
やプリフェッチのヒント情報を新設しているので、これ
らの処理とユーザプロセスの処理とを並列に実行するこ
とが可能となり、システムの処理性能の向上をはかるこ
とができる。
【０１０９】
【発明の効果】以上説明したように本発明によれば、複
数のプロセスが同一ファイルを共有アクセスするコレク
ティブＩ／Ｏにおいて、各プロセスのＩ／Ｏ待ち時間を
短縮し、プロセッサ稼働率を向上させることができる。
【図面の簡単な説明】
【図１】本発明が適用される並列計算機システムの構成
を示すブロック図である。
【図２】各ユーザプロセスが担当する配列データと、そ
の配列データが格納されている並列ファイルと、並列フ
ァイルの各ブロックを格納する各ディスク上のストライ
プファイルとの関係を説明する図である。
【図３】各ユーザプロセスが用いるコレクティブＩ／Ｏ
インタフェースを説明する図である。
【図４】各ストライプファイル毎のサブコレクティブＩ
／Ｏ要求を作成するために使用するファイル管理テーブ
ルとファイル構造テーブルとを説明する図である。
【図５】ユーザプロセスのコレクティブＩ／Ｏ要求を元
に作成するストライプファイルへのサブコレクティブＩ
／Ｏ要求を説明する図である。
【図６】ファイルサーバが保持するコレクティブＩ／Ｏ
管理テーブルの構成を説明する図である。
【図７】ファイルサーバエージェントの処理動作を説明
するフローチャートである。
【図８】ファイルサーバエージェントのサブコレクティ
ブＩ／Ｏ要求作成の処理動作を説明するフローチャート
である。
【図９】ファイルサーバの処理動作を説明するフローチ
ャートである。
【図１０】コレクティブＩ／Ｏバッファのタイムアウト
処理の動作を説明するフローチャートである。
【図１１】本発明の他の実施形態で使用されるファイル
管理テーブルの構造を説明する図である。
【図１２】本発明の他の実施形態で使用するユーザイン
タフェースを説明する図である。
【図１３】ファイルサーバエージェントから各ストライ
プファイルのファイルサーバに送信されるプリアロケー
ト／プリフェッチ要求のフォーマットを示す図である。
【図１４】ユーザプロセスがヒント情報通知インタフェ
ースを実行した場合のファイルサーバエージェントでの
処理動作を説明する図である。
【図１５】プリフェッチ要求、プリアロケート要求を受
信したファイルサーバでの処理の動作を説明するフロー
チャートである。
【符号の説明】
１１００、１２００、１３００、１４００ 計算ノード １１１０、１２１０、１３１０、１４１０ ユーザプロ
セス １１１１ Ｉ／Ｏバッファ １１２０、１２２０、１３２０、１４２０ ファイルサ
ーバエージェント １１２１ ファイル管理テーブル １１２２ ファイル構造テーブル １１２３ 転送バッファ 1130、1230、1330、1430、1530、1630、1730、1830 プ
ロセッサ 1140、1240、1340、1440、1540、1640、1740、1840 メ
モリ １５００、１６００、１７００、１８００ Ｉ／Ｏノー
ド １５１０、１６１０、１７１０、１８１０ ファイルサ
ーバ １５１１ コレクティブＩ／Ｏ管理テーブル １５１２ コレクティブＩ／Ｏバッファ １５２０、１６２０、１７２０、１８２０ ディスク １５２１、１６２１、１７２１、１８２１ ストライプ
ファイル １９００ ネットワーク
───────────────────────────────────────────────────── フロントページの続き (72)発明者 熊▲崎▼ 裕之 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 (72)発明者 鞍掛 稔也 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 Ｆターム(参考） 5B065 BA01 CA11 CE11 CH20 ZA16 5B082 FA01 5B098 AA03 GA04 GB13 GD03 GD12 GD15

Claims (10)

    【特許請求の範囲】
  1. 【請求項１】 複数のプロセスが同一のファイルを共有
    してアクセスするファイル入出力制御方法において、前
    記複数のプロセスのそれぞれが、自プロセスのファイル
    入出力要求と、前記複数のプロセスの全てがアクセスす
    るファイル領域情報を含むヒント情報とをファイル管理
    サーバに通知し、ファイル管理サーバは、前記ヒント情
    報により通知されたファイル領域に対し入出力を行うた
    めのバッファを用意し、前記複数のプロセスからのファ
    イル入出力要求がファイル読み込み要求の場合、前記用
    意したバッファに前記ヒント情報で指定されたファイル
    領域のデータをディスクから読み込み、ディスクからの
    読み込み終了後、各プロセスがファイル入出力要求で指
    定したデータ領域に、前記用意したバッファの対応する
    メモリ領域からメモリコピーを行い、前記複数のプロセ
    スからのファイル入出力要求がファイル書き込み要求の
    場合、各プロセスがファイル入出力要求で指定したデー
    タ領域から前記用意したバッファの対応する領域へのメ
    モリコピーを行い、前記複数のプロセス全てからのメモ
    リコピーの終了後、前記用意したバッファのデータを前
    記ヒント情報で通知されたファイル領域に対してディス
    ク書き込みを行うことを特徴とするファイル入出力制御
    方法。
  2. 【請求項２】 前記ファイル管理サーバが用意するバッ
    ファは、前記複数のプロセスの中の最初のプロセスがヒ
    ント情報を通知したときに用意され、前記複数プロセス
    の中の最後のプロセスのファイル入出力要求が終了した
    ときに破棄されることを特徴とする請求項１記載のファ
    イル入出力制御方法。
  3. 【請求項３】 前記プロセスのそれぞれは、入出力要求
    と同時に、あるいは、入出力要求に先立って前記ヒント
    情報を前記ファイル管理サーバに通知することを特徴と
    する請求項１または２記載のファイル入出力制御方法。
  4. 【請求項４】 前記プロセスのそれぞれからのファイル
    入出力要求がファイル読み込み要求の場合、前記用意し
    たバッファに対する前記ヒント情報で指定されたファイ
    ル領域データのディスクからの読み込みは、前記複数プ
    ロセスの最初のプロセスがヒント情報をファイル管理サ
    ーバに通知したときに行われることを特徴とする請求項
    １、２または３記載のファイル入出力制御方法。
  5. 【請求項５】 前記プロセスのそれぞれから通知される
    ファイル入出力要求は、他のプロセスからのファイル入
    出力要求がファイル管理サーバに通知されたか否かに関
    わらず、前記ファイル管理サーバが用意したバッファと
    各プロセスが指定したデータ領域との間のメモリコピー
    が完了した時点で完了することを特徴とする請求項１な
    いし４のうちいずれか１記載のファイル入出力制御方
    法。
  6. 【請求項６】 前記プロセスのそれぞれが通知するヒン
    ト情報は、前記ファイル管理サーバが用意するバッファ
    の保持期間を含み、前記ファイル管理サーバは、前記複
    数プロセスの全てが通知したファイル入出力要求の処理
    が完了するか、または、前記ヒント情報に含まれる保持
    期間が経過するまで前記用意したバッファを保持するこ
    とを特徴とする請求項１ないし４のうちいずれか１記載
    のファイル入出力制御方法。
  7. 【請求項７】 前記プロセスのそれぞれが通知するヒン
    ト情報は、ファイル読み込み要求の発行に先立ってプリ
    フェッチを行うか否かを指定する情報、あるいは、ファ
    イル書き込み要求の発行に先立ってディスクのプリアロ
    ケートを行うか否かを指定する情報を含み、ファイル管
    理サーバは、前記ヒント情報でプリフェッチを行うよう
    に指定されていた場合、前記ファイル管理サーバが用意
    するバッファに指定されたファイル領域のデータをディ
    スクから予め読み込み、前記ヒント情報でプリアロケー
    トを行うように指定されていた場合、前記複数のプロセ
    スの全データを格納するための領域を予めディスク上に
    確保することを特徴とする請求項１ないし６のうちいず
    れか１記載のファイル入出力制御方法。
  8. 【請求項８】 複数のプロセスが同一のファイルを共有
    してアクセスすることを可能にするファイル管理サーバ
    において、前記複数のプロセスのそれぞれからのそのプ
    ロセスのファイル入出力要求、及び、前記複数のプロセ
    スの全てがアクセスするファイル領域情報を含むヒント
    情報を受領する手段と、前記ヒント情報により通知され
    た前記複数のプロセスの全てがアクセスするファイル領
    域のデータを保持するためのバッファを確保する手段
    と、前記複数のプロセスからのファイル入出力要求がフ
    ァイル読み込み要求の場合に、前記ヒント情報で指定さ
    れた前記複数のプロセスの全てがアクセスするファイル
    領域のデータをディスクから一括して前記確保したバッ
    ファに読み込む手段と、前記複数のプロセスからのファ
    イル入出力要求がファイル書き込み要求の場合に、前記
    バッファの内容を一括してディスクに書き込む手段と、
    各プロセスからのファイル入出力要求時に、プロセスの
    データ領域と前記バッファの対応する領域との間でのメ
    モリコピーを行うことによりファイル入出力処理を完了
    させる手段とを備えることを特徴とするファイル管理サ
    ーバ。
  9. 【請求項９】 前記プロセスのそれぞれが通知するヒン
    ト情報に含まれるファイル読み込み要求の発行に先立っ
    てプリフェッチを行うか否かを指定する情報、あるい
    は、ファイル書き込み要求の発行に先立ってディスクの
    プリアロケートを行うか否かを指定する情報を受領する
    手段と、前記ヒント情報でプリフェッチを行うように指
    定されていた場合に、前記プロセスの処理と非同期に前
    記バッファにディスクから予めデータを読み込む手段
    と、前記ヒント情報でプリアロケートを行うように指定
    されていた場合に、前記プロセスの処理と非同期にディ
    スク領域のプリアロケートを行う手段とを備えることを
    特徴とする請求項８記載のファイル管理サーバ。
  10. 【請求項１０】 並列プログラムを実行する複数のプロ
    セスを協調動作させて計算を行う並列計算機システムに
    おいて、請求項８または９記載のファイル管理サーバを
    備え、前記並列プログラムを実行する複数のプロセスが
    同一のファイルに対して同時にアクセスを行う場合に、
    前記複数のプロセスのそれぞれは、自プロセスのファイ
    ル入出力要求を発行する前に、前記複数の全プロセスが
    アクセスするファイル領域情報を含むヒント情報をファ
    イル管理サーバに通知することを特長とする並列計算機
    システム。
JP2000392686A 2000-12-25 2000-12-25 ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム Pending JP2002196960A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2000392686A JP2002196960A (ja) 2000-12-25 2000-12-25 ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム
US10/024,336 US6687764B2 (en) 2000-12-25 2001-12-21 File I/O control method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2000392686A JP2002196960A (ja) 2000-12-25 2000-12-25 ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム

Publications (1)

Publication Number Publication Date
JP2002196960A true JP2002196960A (ja) 2002-07-12

Family

ID=18858636

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000392686A Pending JP2002196960A (ja) 2000-12-25 2000-12-25 ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム

Country Status (2)

Country Link
US (1) US6687764B2 (ja)
JP (1) JP2002196960A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7689573B2 (en) 2002-12-11 2010-03-30 Hitachi, Ltd. Prefetch appliance server
JP2013196066A (ja) * 2012-03-16 2013-09-30 Hitachi Information & Control Solutions Ltd ファイルサーバ、データ入出力方法、ｉ／ｏフックモジュールプログラム及びｉ／ｏ代行デーモンプログラム

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7047321B1 (en) * 2002-08-26 2006-05-16 Network Appliance, Inc. Unblocking an operating system thread for managing input/output requests to hardware devices
US7188128B1 (en) 2003-12-12 2007-03-06 Veritas Operating Corporation File system and methods for performing file create and open operations with efficient storage allocation
US7433928B1 (en) * 2003-12-31 2008-10-07 Symantec Operating Corporation System pre-allocating data object replicas for a distributed file sharing system
US20060080350A1 (en) * 2004-10-13 2006-04-13 Timothy Mark Allocation of file storage based on pattern recognition
US7519782B2 (en) * 2006-08-24 2009-04-14 Sun Microsystems, Inc. Ring optimization for data sieving writes
US8370456B2 (en) * 2006-09-22 2013-02-05 Microsoft Corporation Intelligent pre-fetching using compound operations
US7899811B2 (en) * 2006-12-01 2011-03-01 Stephen L. Adams Boosting throughput of a computer file server
US8326804B2 (en) * 2008-06-06 2012-12-04 Symantec Corporation Controlling resource allocation for backup operations
US8180793B2 (en) * 2009-03-19 2012-05-15 Hewlett-Packard Development Company, L.P. Access to data stored in a file system
US8850116B2 (en) * 2010-03-10 2014-09-30 Lsi Corporation Data prefetch for SCSI referrals
US9767107B1 (en) * 2013-06-29 2017-09-19 EMC IP Holding Company LLC Parallel file system with metadata distributed across partitioned key-value store
US9940336B2 (en) * 2014-10-24 2018-04-10 Splunk Inc. File monitoring
US9612756B1 (en) * 2015-03-26 2017-04-04 EMC IP Holding Company LLC Data storage system with parallel handling of sub-I/O requests for individual host I/O requests
US9934172B1 (en) * 2015-12-17 2018-04-03 EMC IP Holding Company LLC Data storage system with dynamic throttling of parallel sub-I/O request for individual host I/O requests
US10037289B1 (en) 2015-12-17 2018-07-31 EMC IP Holding Company LLC Data storage system with efficient processing of single mapping callback for host I/O requests
US10996989B2 (en) * 2016-06-13 2021-05-04 International Business Machines Corporation Flexible optimized data handling in systems with multiple memories
CN113253933B (zh) * 2017-04-17 2024-02-09 伊姆西Ip控股有限责任公司 用于管理存储系统的方法、设备和计算机可读存储介质
CN110209353B (zh) * 2019-05-17 2022-10-21 青岛海洋科学与技术国家实验室发展中心 区域耦合预报系统中roms模式的i/o并行加速方法、装置及介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07191899A (ja) * 1993-12-27 1995-07-28 Hitachi Ltd ファイル転送方法、データアクセス方法およびデータ書き込み方法
JP3371044B2 (ja) * 1994-12-28 2003-01-27 株式会社日立製作所 ディスクアレイのための領域割り当て方法およびディスクアレイアクセス方法
US5758149A (en) * 1995-03-17 1998-05-26 Unisys Corporation System for optimally processing a transaction and a query to the same database concurrently
JP3545906B2 (ja) * 1997-05-29 2004-07-21 富士通株式会社 ファイルシステム制御方法，パラレルファイルシステムおよびプログラム記憶媒体
JP3817339B2 (ja) * 1997-06-26 2006-09-06 株式会社日立製作所 ファイル入出力制御方法
JP3324572B2 (ja) * 1999-03-30 2002-09-17 三菱電機株式会社 情報処理装置並びにコンピュータに実行させるためのプログラムを記録した記録媒体

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7689573B2 (en) 2002-12-11 2010-03-30 Hitachi, Ltd. Prefetch appliance server
JP2013196066A (ja) * 2012-03-16 2013-09-30 Hitachi Information & Control Solutions Ltd ファイルサーバ、データ入出力方法、ｉ／ｏフックモジュールプログラム及びｉ／ｏ代行デーモンプログラム

Also Published As

Publication number Publication date
US20020091751A1 (en) 2002-07-11
US6687764B2 (en) 2004-02-03

Similar Documents

Publication Publication Date Title
JP2002196960A (ja) ファイル入出力制御方法、ファイル管理サーバ及び並列計算機システム
US8117615B2 (en) Facilitating intra-node data transfer in collective communications, and methods therefor
Raveendran et al. A framework for elastic execution of existing mpi programs
US7380039B2 (en) Apparatus, method and system for aggregrating computing resources
KR101697937B1 (ko) 멀티프로세서 시스템에서 동적 태스크 마이그레이션을 위한 방법 및 시스템
Nukada et al. NVCR: A transparent checkpoint-restart library for NVIDIA CUDA
US20090125907A1 (en) System and method for thread handling in multithreaded parallel computing of nested threads
Beynon et al. Optimizing execution of component-based applications using group instances
JP3628595B2 (ja) 少なくとも１つのｎｕｍａ（ｎｏｎ−ｕｎｉｆｏｒｍｍｅｍｏｒｙａｃｃｅｓｓ）データ処理システムとして構成可能な相互接続された処理ノード
US8738890B2 (en) Coupled symbiotic operating system
JP2006508468A (ja) マルチスレッド・プロセッサ性能を制御する装置及び方法
JP2008287631A (ja) デプロイ対象計算機、デプロイメントシステムおよびデプロイ方法
Dagum et al. Polytopes, permanents and graphs with large factors
CN110457261B (zh) 数据访问方法、装置及服务器
JP2005056077A (ja) データベース制御方法
US10289306B1 (en) Data storage system with core-affined thread processing of data movement requests
US20100005275A1 (en) Multiprocessing system
JP3169624B2 (ja) プロセッサ間通信方法およびそのための並列プロセッサ
JPH09146904A (ja) アドレス空間共有システム
JPH07129518A (ja) 計算機システム
JPH07152640A (ja) 分散共有メモリ方式
JPH07248949A (ja) 入出力実行方法
JP2001022614A (ja) 階層形記憶システム
JPH08212090A (ja) サーバシステム
JP2003076562A (ja) メモリ量的制御方法、装置、コンピュータプログラム及び記録媒体