JP2010140507A - 分散ファイルシステム及び分散ファイルシステムの作動方法 - Google Patents

Abstract

【課題】 コンピュータのクラスターに対する分散ファイルシステムを提供する。
【解決手段】 相互接続ネットワークによって接続された、複数の計算ノードと複数のＩ／Ｏノードとを有する分散ファイルシステムを提供し、システムに格納されたファイルの物理的及び論理的な区分の両方のための共通のデータ表現を使用するようになっており、この区分は、リニアにアドレス可能である。複数のＩ／Ｏノードと複数の計算ノードとを有する分散ファイルシステムの作動方法を提供し、ファイルを複数のＩ／Ｏノードに亘って分配された複数のサブファイルに区分し、ファイルをその上にビューを設定することによって論理的に区分し、ファイルの線形空間とサブファイルの線形空間との間のマッピングを計算し、ビュー及びサブファイル間の交差を計算し、データ演算を実行する。
【選択図】図１

Description

本発明は、コンピュータのクラスターに対する分散ファイルシステムを提供する方法、及びそのようなファイルシステムをもたらす装置に関する。

コンピュータプロセッサの処理速度のすさまじい高速化は、入力／出力（Ｉ／Ｏ）サブシステムをコンピュータのクラスターにおける障害として露出している。これは、特に、大容量のデータをディスク記憶装置からメモリに取り込むことを要求するアプリケーションの性能に影響を及ぼす。従って、性能に与えるそれらの影響を最小限にするために、Ｉ／Ｏ作動をできるだけ速く実行することが重要である。

分散ファイルシステム（ＤＦＳ）は、ネットワーキング技術によって接続されたいくつかのコンピューティングノードの記憶容量を管理し、クライアントにファイルシステムのインタフェースを提供するファイルシステムである。ノードのクラスターは、コンピューティングノード及びＩ／Ｏノードという、重なる場合もしない場合もある二組に分けられる。ファイルは、一般にＩ／Ｏノードに亘って配布される。アプリケーションは、計算ノード上で実行される。

並列アプリケーションは、順次アプリケーションと違う方法でファイルにアクセスする。「ＵＮＩＸ（登録商標）」ファイルシステム、及びいくつかの分散ファイルシステムでさえも、ファイルシェアリングはほとんどないという前提で設計されたのに対して、並列アプリケーションは、通常はファイルに同時にアクセスする。これは、並列ファイルシステムのファイル構造が、ファイルに対する並列アクセスを可能にすべきであるだけでなく、スケーラブルであって、可能であれば計算と同じくらいスケーラブルであるべきであるということを意味する。

並列アプリケーションはまた、広い範囲のＩ／Ｏアクセスパターンを有する。同時に、それらは、クラスター上のファイルデータの配置に対して十分な程度の制御を有しない。
従って、それらは、クラスター上のファイルの物理的レイアウトと異なるパターンでアクセスする場合が多い。これは、いくつかの点で性能を阻害する可能性がある。
第１に、レイアウトが悪いと、Ｉ／Ｏノードのディスク上のデータの断片化を引き起こす可能性があり、アクセスの複雑なインデックス計算が必要になる。第２に、データの断片化により、ネットワーク上で少ない大きなメッセージを送る代わりに、多くの小さなメッセージを送ることになる。メッセージの集合化は可能であるが、集めたり分散したりするためのコストは無視できない。第３に、関連する処理のＩ／Ｏノードでのコンテンションによって過負荷になる可能性があり、並列処理の妨げになる可能性がある。第４に、Ｉ／Ｏノードのディスク上のデータの空間的局所性が悪いと、ディスクアクセスが順次以外のものに変わる。また、レイアウトが悪いと、ファイルブロック内の間違ったシェアリングの確率が増える。
特定のファイルレイアウトによって並列アプリケーションの性能が改善される場合があるが、同じレイアウトが別々のアクセスパターンによって使用されるべきである。任意のアクセスパターン及びファイルレイアウト間のマッピングの計算は、扱いにくいものになる場合がある。

並列Ｉ／Ｏアクセスパターン及びファイルアクセス特性のいくつかの研究が存在する。
特に、次のものは本発明を理解するのに関係がある。
Ｎｉｌｓ Ｎｉｅｕｗｅｊａａｒ、Ｄａｖｉｄ Ｋｏｔｚ、Ａｐｒａｔｉｍ Ｐｕｒａｋａｙａｓｔｈａ、Ｃａｒｌａ Ｓｃｈｌａｔｔｅｒ Ｅｌｌｉｓ、Ｍｉｃｈａｅｌ Ｌ．Ｂｅｓｔ他著「並列科学的ワークロードのファイルアクセス特性」、並列及び分散システムに対する「ＩＥＥＥ」会報、７（１０）、１９９６年１０月（Ｎｉｅｕｗｅｊａａｒ他）、
Ｅｖｇｅｎｉａ Ｓｍｉｒｎｉ及びＤａｎｉｅｌ Ａ．Ｒｅｅｄ著「Ｉ／Ｏ集中並列アプリケーションのワークロード特性」、モデリング技術及びコンピュータ性能評価のためのツールに関する会議議事録、コンピュータ科学の「Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ」講演ノート、１９９７年６月（Ｓｍｉｒｎｉ他）、及び
Ｈｕｓｅｙｉｎ Ｓｉｍｉｔｉｃｉ及びＤａｎｉｅｌ Ａ．Ｒｅｅｄ著「論理的及び物理的並列Ｉ／Ｏパターンの比較」、高性能コンピューティングアプリケーションの国際ジャーナル、特別号（並列アプリケーションにおけるＩ／Ｏ）、１２（３）、１９９８年（Ｓｉｍｉｔｉｃｉ他）。

上述の文献から、単一アプリケーション中のいくつかのプロセッサ間のファイルシェアリングは標準的であり、一方で並列アプリケーション間の同時シェアリングは極めて少なく、並列Ｉ／Ｏはバースト状態であり、集中Ｉ／Ｏ作動の期間は計算と交替し、「ＭＩＭＤ」システムにおいては、ある程度、ファイル中の物理的な区分（パーティション）と異なるパターンでプロセッサ間のデータを論理的に区分（パーティショニング）する結果である、多くの小さなＩ／Ｏ要求が存在し、計算ノードは、交互的アクセスパターンでファイルにアクセスすることが多く、これは、Ｉ／Ｏノードでのデータの高いプロセス間空間的局所性をもたらすが、また、低いプロセス内空間的局所性ももたらす場合があり、並列アプリケーションは、ストライドされた、最終的にはネストされたストライドのアクセスパターンを使用し、計算ノードに亘って区分された多次元アレーの使用を示している、ということが結論付けられる。

通常、分散ファイルシステムの実行の中心部分はファイルサーバである。ファイルサーバとは、記憶容量リソースのプールを管理し、遠隔又はローカルのクライアントにファイルサービスを提供する処理である。ファイルサービスとは、クライアントがファイルサーバにサービス（例えば、読み取る、書き込む、シークする）を要求するためのインタフェースである。
分散ファイルシステムの設計目標の１つは、記憶リソースをネットワーク全体に亘って効率よく使用することである。アクセス時間が遅いために、ディスクは、非常に多くの場合にシステムの障害になる。「廉価ディスクの冗長アレー（ＲＡＩＤ）」と呼ばれるシステムは、ディスクに並列にアクセスすることによってディスクの帯域幅を増すスケーラブルな１つの方法であって、データは、利用可能なディスクに亘って重複して配布され、ディスクの１つが故障した場合にリカバリと利用可能性のために冗長性が使用される。分散ファイルシステムは、高性能ネットワークの利用可能な全てのディスクを利用するためのソフトウエア「ＲＡＩＤ」として実行することができる。

分散ファイルシステム実行の主要な目標の１つは、位置の透明性である。これは、クライアント及びサーバ間の対話が、システムのユーザに対して不可視であるべきであることを意味する。ユーザは、システム内の全ての記憶リソースとそれらの抽象化（ファイル）とを、それらがあたかもローカルであるように見るはずである。ファイルのパスを見て、そのファイルが遠隔か又はローカルであるかを識別することができるべきではない。
残念なことに、局所性を隠すことがローカルと遠隔のアクセス時間の差を隠すことにはならない。この問題を軽減するために、キャッシュ及びプリフェッチという２つの手法が広く使用される。

１つのマシンのシステムにおいては、キャッシュが使用されてローカルディスクアクセス時間が改善され、より高速のメモリに低速ディスクのコピーが作られる。補足的分散ファイルシステムのキャッシュは、遠隔リソースのローカルコピーを提供する役目を担う。
キャッシュにより、アクセスの時間的局所性を示すアプリケーションの性能が改善され、すなわち、プログラムにおいて、ブロックがアクセスされた状態で、近い将来にそれが再度アクセスされるという可能性が高い。これがほとんどのアプリケーションに当てはまることを性能測定は示している。

分散ファイルシステムにおいて、最も多いクライアント／サーバの設計を仮定すると、サーバディスクのいくつかのキャッシュのレベルは、クライアントの次のような観点から識別することができる。すなわち、
クライアントのメモリキャッシュ、
サーバのメモリキャッシュ、
他のクライアントのメモリキャッシュ、及び
クライアントのディスクキャッシュ、
である。高性能ネットワークが使用される場合、実際の技術の条件下においては、アクセス時間は、上述の第１から第４までのキャッシュレベルまで増加することになる。

キャッシュレベルは、互いに独立に又は協働して使用することができる。協働キャッシュにより、ローカルキャッシュ（第１レベル）によって満足されない要求が、別のキャッシュレベルにより満足され、最後だけはオリジナルリソースによって満足されることが可能になる。
読取りアクセスの場合は、キャッシュの唯一の制約は、キャッシュサイズである。次に、キャッシュが書き込まれる時、キャッシュの干渉性を確保するために余分の注意が払われるべきであり、すなわち、処理が任意のキャッシュ位置に書き込む場合、それに続くいかなるキャッシュの次の読取りもその変更が分るべきである。

上の定義は、まさしく「Ｕｎｉｘ」の作動が保証することである。１つのマシンのシステムは、それらが通常は処理間で共有される集中型ファイルシステムキャッシュを有するために、これを実施するのは簡単である。分散ファイルシステムにおいては、いくつかのキャッシュエンティティが同一コピーを包含することができ、１つのコピーの変更が他の更新又は無効化のいずれかを開始すべきであり、これは、相当なオーバーヘッドを招くことになる。干渉性プロトコルを必要としない、この手法の代替方法は、分散ファイルシステムの全てのキャッシュを１つの大きなキャッシュと見なし、複製を許可しないことである。しかし、この手法の欠点は、アクセス局所性を低減させることである。

「Ｕｎｉｘ」作動の実行のオーバーヘッドを減少させるために、緩和された作動が提案された。セッション作動においては、開かれた後でファイルに処理によって実行された全ての変更は、処理がファイルを閉じた後でのみ他の処理に対して可視にされることになる。同様であるがより細分化した考えがデータベースファイルシステムで使用され、制御命令の開始トランザクションと終了トランザクションとの間で行われた全ての変更は、最後の命令の実行が終了した後でのみ他の処理に対して可視になることになる。
プリフェッチは、近い将来アクセスされる可能性が非常に高いキャッシュデータのブロックにディスクから予め読み取ることを意味する。予測可能なアクセスパターンを有するアプリケーションは、プリフェッチ処理から最も恩恵を受けることができる。

利用可能なディスクから並行して予め読み取るために、分散ファイルシステムにおいては、並行プリフェッチ処理を使用することができる。例えば、ソフトウエア「ＲＡＩＤ」は、ネットワーク内のディスクを均衡のとれた方法で使用することができる。積極的なプリフェッチ処理は、データを非常に早期にキャッシュに入れるために使用することができるが、これは、キャッシュ交換の選択を悪くする可能性があり、実質的にアクセスの回数を増加させる場合がある。言い換えれば、早過ぎてプリフェッチされたデータは、まだ必要なブロックがキャッシュから追い出される可能性を増大し、また、データがフェッチされるのが遅すぎる場合、アクセス処理は、Ｉ／Ｏが完了するのを待たなければならない。
キャッシュ及びプリフェッチの方針の間で最適な妥協点を見出すために、いくつかのアルゴリズムが提案されている。残念ながら、分散ファイルシステム内のキャッシュ間の協力が欠如しているために、それらは広く実行されておらず、試験もまだである。

ログ構造ファイルシステムの設計は、キャッシュが大部分の読取りを吸収し、ディスクのトラフィックが小さな書込みによって支配されるという、２つの主な仮定によって導きかれる。その結果、ディスク時間の大部分は、正しいセクターをシークするために費やされる。ログ構造ファイルシステムは、全ての書込みをログと呼ばれるメモリセグメントに集め、それが一杯になった時に１回の作動でそれをディスクに書き込むことにより、この２つの主要な問題に対処している。この手法は、小さな書込みに対する平均ディスク時間のマグニチュードを１桁改善する。
ログ構造ファイルシステムは、リカバリのためにチェックポイント戦略を使用する。故障の場合は、最後のチェックポイントがロードされて利用可能なログが実行される。

分散ファイルシステムは、この考えを引継ぎ、ソフトウエア「ＲＡＩＤ」と組み合わせてそれを効率的に実行した。「ＮＦＳ」として公知のネットワークファイルシステム用のプロトコルは、サン・マイクロシステムズ・インコーポレーテッドによって開発され、「コメントの要求「ＲＦＣ」１０９４」に説明され、インターネットを通じて「ｈｔｔｐ：／／ｗｗｗ．ｆａｑｓ．ｏｒｇ／ｒｆｃｓ／ｒｆｃ１０９４．ｈｔｍｌ」で利用可能である。「ＮＦＳ」は、最も一般的な分散ファイルシステムである。「ＮＦＳ」アーキテクチャの基本的なエンティティは、サーバとクライアントである。サーバは、処理状態を把握せず、主な仕事は、ローカルファイルシステムのエクスポートである。クライアントは、遠隔ディレクトリに、それらをマウントすることによってアクセスする。位置の透明性は保証される。

実行は、この場合はアクセスの局所性／遠隔性を隠すために使用される「Ｕｎｉｘ」仮想ファイルシステム（ＶＦＳ）インタフェースに基づいている。クライアントがファイルにアクセスすると、適切な「ＶＦＳ」機能に対する呼び出しが行われる。ファイルがローカルの場合、ローカルファイルシステムによって要求にサービス提供が為される。そうでなければ、要求を満たすためにサーバと接触がとられる。

「ＮＦＳ」は制限された形態の協働キャッシュを使用する。サーバ及びクライアントは、両方ともキャッシュを有する。アクセスされたブロックが１つのクライアントのキャッシュ内に発見することができない場合、サーバのキャッシュ内が探索され、その時だけディスクから取り出される。残念なことに、ブロックは、それをディスクから取り出すよりも速いであろう他のクライアントのキャッシュ内では探索されない。

「ＮＦＳ」の主な欠点は、キャッシュが非干渉性になる可能性があることである。クライアントがそのキャッシュを変更すると、その変更は、データブロックに対して遅くとも３秒後、及びディレクトリブロックに対して３０秒後にサーバに送ることができる。従って、他のクライアントは、それまで変更を見ないことになる。この選択は、「ＤＦＳ」ではファイル共有が稀であるという仮定に基づいている。
「ＮＦＳ」サーバはまた、スケーラブルでないことについて批判されてきた。クライアントの数が増加すると、それらが飽和してシステムの障害になる。また、サーバ及びクライアントは無停止型でもない。それらの１つが故障すると、マニュアルで再開しなければならず、変更されたキャッシュの内容は失われる場合がある。
「ＮＦＳ」は、空間的局所性に基づいて単純なプリフェッチポリシーを使用する（ブロックがアクセスされた時、隣接する次のブロックが近い将来必要になる可能性が非常に高い）。通常、クライアントは、現在アクセスしているブロックが得られた後に、ファイルの次の隣接ブロックを予め読み取る。

「ペタル」は、分散論理ディスクである。それは、物理的ディスクのプールを管理するために協働する記憶サーバの集合として設計される。ペタルは、記憶リソースの局所性／遠隔性を隠すカーネルドライバインタフェースを提供する。従って、全ての現存するファイルシステムは、その上で変更なしで実行することができる。
ペタルは、任意の構成要素、すなわち、サーバ、ディスク、及びネットワークの故障に耐え、それから透過的に回復することができる。それはまた、スケーラブルであり、システムに対して新しい記憶装置を透過的に追加／削除することができる。

「フランジパーニ」は、ペタルの上で実行される「ＤＦＳ」である。いくつかの独立ファイルサーバは、ペタル分散ディスクを共有し、分散ロックサービスを使用して同期する。それらは、非協働的に「Ｕｎｉｘ」バッファキャッシュを使用する。システムは、スケーラブルであり、ファイルサーバは、システムに対して性能の劣化なく透過的に追加／削除することができる。
「ゼブラ」は、長構造ファイルシステム及び「ＲＡＩＤ」という２つの考えを初めて組み合わせた「ＤＦＳ」である。各クライアントは、常に自分自身のログに書き込む。ログが一杯になると、それはストライピングされ、このストライプは、別々の記憶マネージャに書き込まれ、マネージャは、次に、それらをディスクに並列に書き込むことができる。

サーバは、記憶マネージャによって記憶及び管理される、データに対するポインタを含む管理情報（メタデータ）に関してのみ責任を負う。サーバは、データ転送の義務から解放される。従って、それらは、小さなファイルの頻繁なアクセスの場合にだけ性能上の障害となる可能性がある。
ゼブラは、単一の記憶マネージャの故障に耐え、それから回復することができる。それはまた、システムクラッシュから回復するために、長構造ファイルシステムと同様にチェックポイント戦略を使用する。ファイルサーバは、そのメタデータを記憶マネージャに保ち、クラッシュ時にメタデータをそこから回復することができる。

「ＸＦＳ」は、サーバなしのネットワークファイルシステムを提案し、最初に協働キャッシュを実行した。システムは、密接に協働するワークステーションから成り、全てのファイルシステムサービスをスケーラブルな方法で提供する。
ゼブラと同様に、「ＸＦＳ」は、書込みの性能と信頼性を改善するためにログ構造ファイルシステムと「ＲＡＩＤ」の考えとの組合せを使用する。ゼブラ と違って、「ＸＦＳ」は、制御情報をファイルの細分性でシステムに亘って配布し、アクセス特性を改善するために協働キャッシュを使用する。ブロックがローカルキャッシュで発見されない時はいつでも、それは、他のクライアントで探索し、最後の解決手段としてのみディスクから取り込まれる。局所性は、アクセスされる可能性が高いマシンのキャッシュにブロックを保つように試みることによって促進される。キャッシュ交換ポリシーにおいては、複数のコピーを有するブロックには、非複製ブロックに対して、交換される優先権がある。「ＸＦＳ」は、アプリケーションに対して「Ｕｎｉｘ」作動を保証するトークンベースのキャッシュ整合性スキームを使用する。

ファイルシステムの古典的なサーバ／クライアント設計の制約は、サーバマシンが急速に障害になる可能性があるということである。提案された解決法の１つは、記憶装置をホストから切り離し、それを高性能ネットワークに取り付けることであった。サーバは、データ転送の義務から解放され、一方、スマート記憶システム（専用プロセッサを有する）は、転送及び最適配置を含むデータ管理に関して責任を負う。

「ネットワーク取付け安全ディスク（ＮＡＳＤＡ）」プロジェクトは、ファイル管理をファイル記憶から分離することを目標にしている。ファイルサーバの責任は、アクセスポリシー及び決定に低減される。従って、ファイルを開くためにクライアントがサーバに接触（通信）する時、クライアントは、認可トークンを受け取り、サーバをバイパスしてディスクにアクセスするために次にそれを使用することができる。

モバイルコンピューティングがますます進展し、頻繁に接続性が悪くなるので、脆弱に接続されたサービスに対する必要性を生み出した。クライアントは、接続が切れた時、又は接続が弱い時に作業を続け、復帰の後でそれ自体及びシステムを更新することができるべきである。コーダは「ＤＦＳ」であり、モバイルファイルアクセスのために弱い接続を利用する。積極的プリフェッチ（蓄積）は、切断を予期してデータを収集するために使用される。間違ったデータが蓄積された場合、切断された時に進行が妨げられる。別の欠点は、キャッシュの干渉性問題がより起こりやすく、それらがユーザの介入を要求する場合があることである。残念なことに、上述の欠点は、両方ともシステム設計では解決することができず、接続性をもたらすことによって解決される。

多くの分散ファイルシステムの実行は、最も一般的なアクセスパターン及びハードウエア構成を仮定しており、誰にでも使用されるべき一般的な機構及びポリシーを実行する。
これにより、実行仮定の下で作動していないアプリケーションの性能が犠牲にされることになる。アプリケーションにそれら自体のポリシーを実施する可能性を与えるか、又はポリシーの交換を容易にすると、システムの性能が向上するであろう。外部カーネル及びマイクロカーネルは、実行者がリソース管理をユーザスペースに移動し、モノリシックカーネルと比較して比較的容易なシステム機能性の増強を提供することにより、アプリケーションの必要性に対してポリシーを容易に調整することを可能にする単なる２つの提案である。「ＤＦＳ」の場合の局所性においては、キャッシュ及びプリフェッチポリシーは、アプリケーションの必要性を考慮に入れた実行から最も利益を得ることができると考えられる。

Ｎｉｌｓ Ｎｉｅｕｗｅｊａａｒ、Ｄａｖｉｄ Ｋｏｔｚ、Ａｐｒａｔｉｍ Ｐｕｒａｋａｙａｓｔｈａ、Ｃａｒｌａ Ｓｃｈｌａｔｔｅｒ Ｅｌｌｉｓ、Ｍｉｃｈａｅｌ Ｌ．Ｂｅｓｔ他著「並列科学的ワークロードのファイルアクセス特性」、並列及び分散システムに対する「ＩＥＥＥ」会報、７（１０）、１９９６年１０月（Ｎｉｅｕｗｅｊａａｒ他） Ｅｖｇｅｎｉａ Ｓｍｉｒｎｉ及びＤａｎｉｅｌ Ａ．Ｒｅｅｄ著「Ｉ／Ｏ集中並列アプリケーションのワークロード特性」、モデリング技術及びコンピュータ性能評価のためのツールに関する会議議事録、コンピュータ科学の「Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ」講演ノート、１９９７年６月（Ｓｍｉｒｎｉ他） Ｈｕｓｅｙｉｎ Ｓｉｍｉｔｉｃｉ及びＤａｎｉｅｌ Ａ．Ｒｅｅｄ著「論理的及び物理的並列Ｉ／Ｏパターンの比較」、高性能コンピューティングアプリケーションの国際ジャーナル、特別号（並列アプリケーションにおけるＩ／Ｏ）、１２（３）、１９９８年（Ｓｉｍｉｔｉｃｉ他） Ｓｈａｎｋａｒ Ｒａｍａｓｗａｍｙ及びＰｒｉｔｈｖｉｒａｊ Ｂａｎｅｒｊｅｅ著「分散メモリマルチコンピュータ用の効率的アレー再配布ルーチンの自動生成」、「フロンティア９５」会報、超並列計算のフロンティアに関する第５回シンポジウム、マクリーン、１９９５年２月（Ｒａｍａｓｗａｍｙ他）

従って、コンピュータのクラスターに対する分散ファイルシステムを提供する方法、及びそのようなファイルシステムをもたらす装置が必要である。

本発明は、相互接続ネットワークによって接続された、複数の計算ノードと複数の入力／出力（Ｉ／Ｏ）ノードとを有する分散ファイルシステムを提供し、本システムは、システムに格納されたファイルの物理的及び論理的な区分の両方のための共通のデータ表現を使用するようになっており、この区分は、線形的（リニア）にアドレス可能である。
本システムは、複数のＩ／Ｏノードからファイルに関する情報を集め、このＩ／Ｏノードを整合性のある状態に保持するようになっているメタデータマネージャを含むことができる。好ましくは、計算ノードは、ファイル作成、ファイルオープン、ファイルクローズ、及びメタデータに関わる要求のリストから選択されたイベントの場合に、メタデータマネージャと接触（通信）するようになっている。
本システムは、好ましくは、各計算ノードが、ファイルの線形空間（リニア空間）とサブファイルの線形空間（リニア空間）との間のマッピングの計算と、ビュー及びサブファイル間の交差アルゴリズムの実行と、データ演算の実行とを含む複数のファイル操作を実行するようにプログラムされるようなシステムである。

本システムの好ましい実施形態においては、ファイル構造は、そのコアに「プロセッサ指標付き標識ラインセグメント群（ＰＩＴＦＡＬＬＳ）」と呼ばれる通常のデータ分散のための表現を有し、これは、「フロンティア９５」会報におけるＳｈａｎｋａｒ Ｒａｍａｓｗａｍｙ及びＰｒｉｔｈｖｉｒａｊ Ｂａｎｅｒｊｅｅ著「分散メモリマルチコンピュータ用の効率的アレー再配布ルーチンの自動生成」、超並列計算のフロンティアに関する第５回シンポジウム、マクリーン、１９９５年２月（Ｒａｍａｓｗａｍｙ他）に詳しく紹介されている。
「ＰＩＴＦＡＬＬＳ」は、イリノイ州立大学において、効率的アレー再配布（再分配）ルーチンの自動生成のために「ＰＡＲＡＤＩＧＭ」コンパイラに使用されていた。「ＰＩＴＦＡＬＬＳ」表現は、より多くのアクセス形式を表現することができるように拡張される。例えば、全ての「ＭＰＩ」データ形式は、本発明の表示を使用して表現することができる。

本発明は、更に、複数の入力／出力（Ｉ／Ｏ）ノードと複数の計算ノードとを有する分散ファイルシステムの作動方法を提供し、本方法は、ファイルを複数のＩ／Ｏノードのそれぞれに亘って配布された（Distributed）複数のサブファイルに区分する段階と、ファイルをその上にビューを設定することによって論理的に区分する段階と、このファイルの線形空間（linear space）とサブファイルの線形空間との間のマッピングを計算する段階と、ビュー及びサブファイル間の交差（Intersection）を計算する段階と、データ演算を実行する段階とを含む。
本発明はまた、複数の入力／出力（Ｉ／Ｏ）ノードと複数の計算ノードとを有する分散ファイルシステムを作動する方法を提供し、本方法は、ファイルをサブファイルに物理的に区分する段階と、ファイルをビューに論理的に区分する段階と、サブファイル及びビュー間のマッピング機能（Mapping Function）を実行する段階と、区分間でデータ再配布（Data Redistribution）を実行する段階とを含む。

本発明のシステム内でプログラムすることができる、本発明の方法を実行するためのアルゴリズムは、ファイルの線形空間からサブファイルの線形空間上への位置ｘのマッピングを計算するためのアルゴリズムと、サブファイルの線形空間からファイルまでのマッピングを計算するためのアルゴリズムと、サブファイル及びビュー間のマッピングを計算するためのアルゴリズムと、ラインセグメント群ｆ₁及びｆ₂の交差を表すための一組のネストされたラインセグメント群を計算するためのアルゴリズムと、二組のネストされたラインセグメント群Ｓ₁及びＳ₂の交差を計算するためのアルゴリズムと、各交差する組の各々によって記述される線形空間上への二組のラインセグメント群の交差の投射を計算するためのアルゴリズムとを含む。
ここで、本発明の好ましい実施形態を添付図面を参照して単に例示的に以下に説明する。

本発明は、アプリケーションがファイル上に任意のビューを設定することを可能にする。この並列ファイルシステムは、例えばｎ次元アレー分布のような、通常のアクセスパターン及びファイルレイアウトを表現するコンパクトな方法を提供する。それはまた、レイアウト間の便利な変換を可能にする。

本発明の分散ファイルシステムの概略図である。 「ＦＡＬＬＳ」例（５，７，７，３）を示す図である。 ネストされた「ＦＡＬＬＳ」例を示す図である。 ネストされた「ＦＡＬＬＳ」のツリー表示を示す図である。 「ＰＩＴＦＡＬＬＳ」例（２，３，６，４，２，３）を示す図である。 ネストされた「ＰＩＴＦＡＬＬＳ」例を示す図である。 ファイル区分の例を示す図である。 更に別のファイル区分の例を示す図である。 Ｉ／Ｏノード上のサブファイル割当の例を示す図である。 ビュー／サブファイルマッピングを示す図である。 「ＦＡＬＬＳ」交差アルゴリズムを概略的に示す図である。 更に別の「ＦＡＬＬＳ」例（３，５，６，５）を示す図である。 ネストされた「ＦＡＬＬＳ」交差アルゴリズムを概略的に示す図である。 本発明の書込み作動を概略的に示す図である。 マトリックス区分の例を示す図である。

全体的に１０で示す分散ファイルシステムを図１に概略的に示す。システム１０は、相互接続ネットワーク１６によって接続された、複数の計算ノード１２と複数のＩ／Ｏノード１４とを有する。
図２を参照すると、ラインセグメント（ＦＡＬＬＳ）１８群の例が示されている。ラインセグメント（ＬＳ）、例えばラインセグメント２０は、一対の数（ｌ，ｒ）によって定義され、ｌで始まりｒで終了するファイルの連続した部分を記述する。

ラインセグメント（ＦＡＬＬＳ）群は、タプル（共有メモリ空間に保存されたメッセージ）（ｌ，ｒ，ｓ，ｎ）であり、等間隔に配置された同サイズのｎ個のラインセグメントの組を表す。図２に示すように、第１のＬＳ２０の左側のインデックスｌは５であり、第１のＬＳの右側のインデックスｒは７で、ストライドと呼ばれｓで表される２つのＬＳ毎の間の距離は７である。図２において、ｎは３に等しい。ラインセグメント（ｌ，ｒ）は、「ＦＡＬＬＳ」（ｌ，ｒ，−，１）と表現することができる．図２は、従って、「ＦＡＬＬＳ」（５，７，７，３）の例を示す。

ネストされた「ＦＡＬＬＳ」は、タプル（ｌ，ｒ，ｓ，ｎ，Ｓ）であり、一組の内側「ＦＡＬＬＳ」Ｓと共に、外側「ＦＡＬＬＳ」と呼ばれる「ＦＡＬＬＳ」（ｌ，ｒ，ｓ，ｎ）を表す。内側「ＦＡＬＬＳ」ｓは、ｌとｒの間に配置され、ｌを基準にする。ネストされた「ＦＡＬＬＳ」を構成する時、外側「ＦＡＬＬＳ」から始めて内側「ＦＡＬＬＳ」にするのが賢明である。図３はネストされた「ＦＡＬＬＳ」（０，３，８，２，｛０，０，２，２，Ｏ｝）の例を示す。外側「ＦＡＬＬＳ」２２は、太線２４で示されている。

ネストされた「ＦＡＬＬＳ」はまた、ツリーでも表すことができる。ツリーの各ノードは「ＦＡＬＬＳ」ｆを含み、その子は、ｆの内側「ＦＡＬＬＳ」である。図４は、ネストされた「ＦＡＬＬＳ」（０，１５，３２，２，｛（０，０，４，２，Ｏ），（８，９，４，２，Ｏ）｝）を示す。
一組のネストされた「ＦＡＬＬＳ」は、ラインセグメントの集合として見られ、ファイルの部分集合をコンパクトに表す。ファイルのｘ番目のバイトは、Ｓのラインセグメントの１つに置かれる場合、一組のネストされた「ＦＡＬＬＳ」Ｓに属する。

一組の「ＦＡＬＬＳ」は、パラメータ化された「ＦＡＬＬＳ」である「ＰＩＴＦＡＬＬＳ」表示を使用して簡単に表現することができ、パラメータは、プロセッサ（Ｉ／Ｏノード）番号である。「ＰＩＴＦＡＬＬＳ」は、タプル（ｌ、ｒ、ｓ、ｎ、ｄ、ｐ）から成り、等間隔に配置されたｐ個の「ＦＡＬＬＳ」の組を表し、始めの２つの連続する「ＦＡＬＬＳ」間の距離は、ｄ：（ｌ＋ｉｄ，ｒ＋ｉｄ，ｓ，ｎ）であり、ｉ＝０，ｐ−１である。「ＦＡＬＬＳ」（ｌ，ｒ，ｓ，ｎ）は、「ＰＩＴＦＡＬＬＳ」（ｌ，ｒ，ｓ，ｎ，−，１）、及び、ラインセグメント（ｌ，ｒ）は、（ｌ，ｒ，−，１，−，１）と表すことができる。図５は、「ＰＩＴＦＡＬＬＳ」（２，３，６，４，２，３）を示し、これは、ｄ＝２：（２，３，６，４），（４，５，６，４）、及び（６，７，６，４）の間隔を置いて配置されたｐ＝３「ＦＡＬＬＳ」のコンパクトな表示である。

ネストされた「ＰＩＴＦＡＬＬＳ」は、一組の内側「ＰＩＴＦＡＬＬＳ」Ｓと共に、外側「ＰＩＴＦＡＬＬＳ」と呼ばれる「ＰＩＴＦＡＬＬＳ」（ｌ，ｒ，ｓ，ｎ，ｄ，ｐ，Ｓ）を表すタプル（ｌ，ｒ，ｓ，ｎ，ｄ，ｐ，Ｓ）である。外側「ＰＩＴＦＡＬＬＳ」は、ｐ個の外側「ＦＡＬＬＳ」（ｌ＋ｉｄ，ｒ＋ｉｄ，ｓ，ｎ）をコンパクトに表し、ｉ＝０，ｐ−１である。各「ＦＡＬＬＳ」は、ｌ＋ｉｄとｒ＋ｉｄとの間にｌ＋ｉｄに対するインデックスを有する一組の内側「ＰＩＴＦＡＬＬＳ」を含む。ネストされた「ＰＩＴＦＡＬＬＳ」を構成する時、外側「ＰＩＴＦＡＬＬＳ」から始めて内側「ＰＩＴＦＡＬＬＳ」にするのが賢明である。図６は、４個のＩ／Ｏノード／プロセッサに亘る４×４マトリックスの二次元ブロックの周期的分布を表すネストされた「ＰＩＴＦＡＬＬＳ」の一例を示す。この分布は、｛（０，３，８，２，４，２，｛（（０，０，２，２，１，２，Ｏ））｝）｝のようにコンパクトに表される。外側「ＰＩＴＦＡＬＬＳ」は、２つの「ＦＡＬＬＳ」の（０，３，８，２）と（４，７，８，２）のコンパクトな表示であり、各々、内側「ＰＩＴＦＡＬＬＳ」（０，０，２，２，１，２）を含む。

好ましい実施形態は、Ｉ／Ｏノード上へのファイルの物理的区分、計算ノード上へのファイルの論理的区分、及び、それらの間のマッピングを表すために、ネストされた「ＰＩＴＦＡＬＬＳ」の組を使用する。しかし、プログラミングインタフェースが、ネストされた「ＰＩＴＦＡＬＬＳ」の複雑性を回避する。論理的及び物理的配布の指定は、「高性能フォートラン」と同様の方法で実行することができる。

データ表現のコアとしてネストされた「ＰＩＴＦＡＬＬＳ」を選択する主な理由は３つある。第１に、柔軟性が十分でデータの任意の配布を表現することができる。
例えば、一組のネストされた「ＰＩＴＦＡＬＬＳ」を使用して、任意の「ＭＰＩ」データタイプを表現することができる。これは、極端な場合に、ネストされた「ＰＩＴＦＡＬＬＳ」がｎ＝１及びｐ＝１の単なるラインセグメントであるという事実のためである。従って、一組のネストされた「ＰＩＴＦＡＬＬＳ」は、不規則なパターンも表すことができる。第２に、それらは、複雑で規則的な配布を表現するコンパクトな方法を提供する。例えば、いくつかのＩ／Ｏノード又はプロセッサ上の多次元アレー分布は、ネストされた「ＰＩＴＦＡＬＬＳ」として単純に表現することができる。第３に、１つの配布を別の配布に変換する効率のよいアルゴリズムがある。例えば、Ｒａｍａｓｗａｍｙ他の文献は、「ＰＩＴＦＡＬＬＳ」形式で表現されたデータの効率の良い多次元アレー再配布を実行するアルゴリズムの記述を含む。このアルゴリズムから始め、データ表現としてネストされた「ＰＩＴＦＡＬＬＳ」の組を使用して、任意の再配布を実行するアルゴリズムが設計された。

この場合、１つの配布の別の配布への変換は、２つのシナリオにおいて有用である。第１に、アプリケーションの要求に応じて物理的区分（Ｉ／Ｏノード及びそのディスク上へのデータの配布）を論理的区分に変換し、またその逆の変換も為される。これは、物理的区分が正確にアプリケーションの要求に対応しない時の場合である。第２に、２つの物理的配布間での変換が許される。これは、アプリケーションが現存する配布からよりも新しい物理的配布から実行時に更に利益を得る必要がある時に有用となり得る。

「ＦＡＬＬＳ」ｆのブロック長は、ＬＥＮ_fで表され、ｆｓブロックでのバイト数を表す。
ＬＥＮ_f＝ｒ_f−ｌ_f＋１ （１）
例えば、図３のネストされた「ＦＡＬＬＳ」の外側「ＦＡＬＬＳ」のブロック長は４であり、内側「ＦＡＬＬＳ」のブロック長は１である。
ネストされた「ＦＡＬＬＳ」は、ファイルの部分集合を表す一組のインデックスである。ネストされた「ＦＡＬＬＳ」ｆのサイズは、ｆで定義される部分集合のバイト数である。一組のネストされた「ＦＡＬＬＳ」Ｓのサイズは、その要素全てのサイズの総計である。以下に示す２つの相互回帰方程式は、上述の２つの定義を形式的に表すものである。

例えば、図３のネストされた「ＦＡＬＬＳ」のサイズは４である。
一組の「ＦＡＬＬＳ」は、ｌとｒの間にホールがない領域を記述する場合は、ｌとｒの間で連続であると呼ばれる。例えば、図２の「ＦＡＬＬＳ」を含む組は、１１と１４の間で連続であるが、３と８の間で連続ではない。
好ましい実施形態は、クラスターのノードを計算ノード及びＩ／Ｏノードという、重なるか又は重ならなくてもよい二組に区分する。Ｉ／Ｏノードは、ファイルデータを保存する。アプリケーションは、計算ノード上で作動する。また、ファイルのメタデータを集中させるメタデータマネージャも１つある。

好ましい実施形態におけるファイルは、線形的にアドレス可能なバイトシーケンスである。ファイルは、サブファイルに物理的に区分することができ、ビューに論理的に区分することができる。ファイルは、１つ又はそれ以上の重ならない線形的にアドレス可能なサブファイルに物理的に区分することができる。区分は、ファイルの変位及び区分パターンによって記述される。変位は、ファイルの始まりに対する絶対バイト位置である。区分パターンＰは、各々がサブファイルを形成するｎ組のネストされた「ＦＡＬＬＳ」Ｓ₀，Ｓ₁，．．．，Ｓ_n-1の和集合から成る。

この集合は、ファイルの非オーバーラップ領域を記述すべきである。更に、Ｐは、ファイルの連続領域を記述すべきである。区分パターンは、サブファイル内のサブファイル対の位置上にファイルの各バイトを独特にマッピングし、変位から始めてファイルの線形空間を通して繰り返し適用される。
区分パターンＰのサイズをそのネストされた「ＦＡＬＬＳ」の全てのサイズの総計として定義する。

図７は、変位２を有し、「ＦＡＬＬＳ」（０，１．６．１．Ｏ）、（２，３，６，１、Ｏ）、及び（４，５，６，１，Ｏ）として定義された３つのサブファイルに物理的に区分されたファイルを示す。区分パターンのサイズは６である。矢印は、ファイルの線形空間からサブファイルの線形空間へのマッピングを示す。ビュー内のファイルの論理的区分のために同じ機構が適用される。
ネストされた「ＰＩＴＦＡＬＬＳ」を使用する通常の区分の場合、ファイルのそのサブファイル上への区分パターンは、よりコンパクトに表現することができる。図８は、２つの例によってファイル構成を示す。図８（ａ）の例においては、ファイルは、変位２に対して「ＰＩＴＦＡＬＬＳ」（０，１，−，１，２，３，Ｏ）を使用することによって作り出された３つのサブファイルから成る。これは、変位２で３つのサブファイルで構成されたファイルを表す。ファイルは、サブファイル上に円形ロビン状に配置される。

図８（ｂ）の例は、ネストされた「ＰＩＴＦＡＬＬＳ」（０，３，−，１，４，２，｛（（０，０，２，２，１，２，Ｏ））｝）を使用して構築された４つのサブファイルから成るファイルを示す。これは、サブファイルにおけるファイルの二次元ブロック循環配布を示す。
ｎがファイルに割り当てられたＩ／Ｏノードの数で、ｂがファイルブロックのサイズとすると、ファイルブロックの円形ロビン状配布は、「ＰＩＴＦＡＬＬＳ」（０，ｂ−１，−，１，ｂ，ｎ，Ｏ）で表される。この表示は、ファイルをｎ個のサブファイルに区分する。それらは、各々、別のＩ／Ｏノード上にあることができる。

サブファイルは、単一のＩ／Ｏノードで連続して書き込まれるか、又はいくつかのＩ／Ｏノードに分散されるかのいずれかである。
サブファイルの数がＩ／Ｏノードの数を超える場合、各サブファイルは、単一のＩ／Ｏノードで連続して書き込まれる。サブファイルは、Ｉ／Ｏノードに円形ロビン状に割り当てられる。図９は、４つのサブファイルで構成され、２つのＩ／Ｏノードに書き込まれたファイルを示す。サブファイル０と２は、Ｉ／Ｏノード０に割り当てられ、それに対して、サブファイル１と３は、Ｉ／Ｏノード１に割り当てられる。

ファイルのサブファイル数がＩ／Ｏノード数よりも小さい場合、サブファイルは、接続をはずされたＩ／Ｏノードの組にデフォルトで分散される。この手法は、ファイル内の並列性を最大にして、全てのＩ／Ｏノードの集合帯域幅をアプリケーションが利用することを可能にする。例えば、単一サブファイルの構造を有するファイルは，そのデータを全てのＩ／Ｏノード上に円形ロビン状に配布することができる。図９（ｂ）の別の例は、２つのサブファイルで構成され、４つのＩ／Ｏノード上に保存されたファイルを示す。２つのサブファイルは、各々、２つのＩ／Ｏノードに亘って円形ロビン状にストライピングされる。

物理的な区分は、非常に柔軟性があるが、同じファイルレイアウトに関するアプリケーションの要求は違う場合がある。従って、アプリケーションは、ビューを設定することによってファイルを論理的に区分することができる。ビューは、線形的にアドレス可能なバイトシーケンスであり、開いているファイルのデータの部分集合上にマップされる。アプリケーションは、ファイルを開くと、全体のファイルに関するビューをデフォルトで保持する。次に、それは、それ自身の必要に応じてビューを変更することができる。ビューを使用する主な利点は、複雑なインデックスの計算をすることからプログラマーを解放することである。ビューが設定された状態で、アプリケーションは、必要とされるデータセットの論理的に連続したビューを保持し、通常のファイルにアクセスするのと同じようにそのビューにアクセスすることができる。

ビューを設定すると、ファイルの論理的区分及び物理的区分間のマッピングを早期に計算する機会が得られる。マッピングは、次に、メッセージ内に又はそれからデータを収集／分散するために読取り／書込み演算で使用される。この手法の利点は、計算のアクセスインデックスのオーバーヘッドがビュー設定の時に一度だけ費やされることである。ビューはまた、オペレーティングシステムに対するヒントとして見ることができる。それらは、実際に可能性のある将来のアクセスパターンを開示し、Ｉ／Ｏのスケジューリング、キャッシュ、及びプリフェッチポリシーによって使用される。例えば、これらのヒントは、ディスク要求の整理、ディスク上のファイルブロックの配置、ネットワークメッセージの最適サイズの決定、バッファキャッシュの交換ポリシーなどを助けることができる。

アプリケーションの論理的区分は、ファイルのサブファイルへの物理的区分と同じではないかもしれない。従って、ビューが設定される度にビュー及びファイル間の直接のマッピングが計算されるべきである。図１０（ａ）は、「ＰＩＴＦＡＬＬＳ」（０，１，４，２，１，２，Ｏ）を使用した、ファイルの２つのサブファイルへの区分を示す。図１０（ｂ）は、物理的区分と異なる２つの計算ノードによるファイルの論理的区分を示す。ノード０は、「ＰＩＴＦＡＬＬＳ」（１，２，４，２，−，１，Ｏ）とノード１（３，４，４，２，−，１，Ｏ）とを使用する。図１０（ｃ）は、論理的区分及び物理的区分間の直接マッピングを示す。

例えば、多次元アレー分布のような通常の配布の場合に、直接マッピング計算を効率的にするために、Ｒａｍａｓｗａｍｙ他によって記述されたアレーの再配布アルゴリズムが使用される。このアルゴリズムにおいては、２つの通常の配布は、「ＰＩＴＦＡＬＬＳ」として表され、それらの交差が計算される。交差は、１つの配布の他の配布上へのマッピングを表す。ネストされた「ＰＩＴＦＡＬＬＳ」の組の任意の交差を計算するために、アルゴリズムは変更される。ビューとサブファイルは、両方ともネストされた「ＰＩＴＦＡＬＬＳ」の組として表すので、図９（ｃ）に示すように直接マッピングを表すそれらの間の交差を計算するためにこのアルゴリズムが使用される。

アクセスパターンとファイルのレイアウトとが適合しない場合、直接マッピングにより、小さなメッセージがネットワーク全体に亘って送られることになるであろう。より小さなメッセージを単一メッセージに融合させるために、直接マッピングは、ビュー及びサブファイルの間でビューマッピングとサブファイルマッピングという２つの部分に区分される。
ビューマッピングは、ネットワークがビューデータを転送するために計算ノードによって使用される、所定のサブファイルに対するビューの線形バッファ上へのマッピングである。サブファイルのマッピングは、サブファイルデータのネットワーク転送のためにＩ／Ｏノードによって使用される、所定のビューに対するサブファイルの線形バッファ上へのマッピングである。図１０（ｄ）は、図１０（ｃ）の直接マッピングがどのようにビューマッピングとサブファイルマッピングとに区分されるかを示すものである。ビューマッピング及びサブファイルマッピングは、ビューが設定された後に計算ノードで計算される。
ビューマッピングは、計算ノードで保存され、サブファイルマッピングは、サブファイルがあるＩ／Ｏノードに送られる。

ビュー及びサブファイルマッピングは、計算ノードとＩ／Ｏノードとの間でビュー／サブファイルの不連続領域を転送すべきである場合にだけ必要である。それらは、ビューの設定時に予め計算され、必要に応じて分散／収集演算でアクセス時間によって使用される。そうでなければ、転送は、再複製することなく行われる。例えば、ビューの連続する領域がサブファイル上に連続してマップされる場合、データを融合させるための補助バッファは必要ない。

データの読取り及び書込みは、２段階作動と見ることができる。第１の段階は、上述のマッピングの予備計算によって表される。第２の段階は、効果的なデータの読取り又は書込みである。
効果的なデータの読取り及び書込みは、ビュー上で行われ、第１段階で予め計算されたマッピングを使用する。アプリケーションがファイルにバッファを書込みたい場合、次の段階が行われる。すなわち、（ａ）関連する全てのサブファイルに対して、ビューマッピングを使用して単一メッセージのビューからデータを収集する、（ｂ）メッセージがＩ／Ｏノードに送られる、（ｃ）Ｉ／Ｏノードは、データをサブファイル上に書き込むためにサブファイルマッピングを使用する。データ読取りの時は、逆の処理が行われる。例えば、図１０（ｄ）において、既にビューを設定した計算ノード０は、４つの要素のバッファを１から４までのビューに書き込む。サブファイル０に対するビューマッピングがバイト２及び４をメッセージに融合させるために使用され、これは、サブファイル０のＩ／Ｏノードに送られる。サブファイル０のＩ／Ｏノードにおいては、ビュー０に対するサブファイルマッピングは、アドレス３及び５においてデータを書き込むために使用される。アドレス０及び２においてサブファイル１に書き込まれるビュー０のバイト１及び３に対して同じ処理が行われる。

本発明の手法の効率を実証するために、「ＬＩＮＵＸ」上で実行される実験的な並列ファイルシステムを構築し、それを完全にユーザレベルで実施した。
好ましい実施形態は、メタデータマネージャ、Ｉ／Ｏサーバ、及びＩ／Ｏライブラリの３つの主要な構成要素を有する。クラスターの各ノードは、計算ノード、Ｉ／Ｏサーバ、又はその両方（パートタイムＩ／Ｏノード）の役割を果たすことができるが、唯一のノードのみがメタデータマネージャであることができる。
並列ファイルシステムで作動する１つのメタデータマネージャが存在する。このメタデータマネージャは、ファイルに関する情報をＩ／Ｏノードから周期的又は要求によって収集し、それらを安定した状態で保存する。それはまた、ファイルのメタデータに関する要求によるサービスを計算ノードに提供する。データ転送には、メタデータマネージャは関わらない。

メタデータは、ファイル構造（サブファイルへのファイルの区分、ファイルが書き込まれるＩ／Ｏサーバ）、ファイルサイズ、作成、及び変更時間などのようなファイルに関する情報を表す。
メタデータマネージャは、ファイル作成、オープン、クローズ、又はファイルのメタデータに関わる任意の要求時に計算ノードによって接触される。
ファイルが作り出され、計算ノードがファイルに対するレイアウトを指定しない場合、デフォルトのレイアウト（全てのＩ／Ｏノードに亘って円形ロビン状の形態でファイルブロックをストライピングする）が選択される。ファイルのレイアウトが指定されると、それがメタデータに保存される。それに続く各再オープンは、固有のファイル記述子と共にレイアウト情報を検索することになる。

並列ファイルシステム内の各Ｉ／Ｏノード上で作動するＩ／Ｏサーバが１つ存在する。
Ｉ／Ｏサーバの主なタスクは、サブファイルに対するデータの書込み及び読取りである。計算ノード及びＩ／Ｏサーバ間の接続は、ビューの設定において、又は予めビューが設定されていない場合は最初のアクセスにおいて確立される。ビューが設定されると、Ｉ／Ｏサーバは、ビューのサブファイルマッピングを受け取り、それは、上述の通り、将来のアクセスのために使用される。Ｉ／Ｏサーバは、メタデータを各サブファイルに関して保存し、要求に応じてそれをメタデータマネージャに配信する。

各計算ノードは、ファイルシステム上の作動をＩ／Ｏライブラリを使用して指定する。
Ｉ／Ｏライブラリは、「ＵＮＩＸ」標準ファイルシステムインタフェースを実行する。この時、それはユーザレベルで実行される。計算ノードとメタデータマネージャ又はＩ／Ｏサーバとの間の通信は、ライブラリによってアプリケーションから隠される。
アプリケーションは、標準「ＵＮＩＸ」の「ｉｏｃｔｌ」作動のユーザレベルの変形を使用して、ファイルのレイアウトを設定することができる。レイアウトの設定は、「ｃｒｅａｔｅ」コールに従わなければならない。レイアウトは、メタデータマネージャで送られるが、計算ノードでも保存される。
ファイル上へのビューの設定はまた、「ｉｏｃｔｌ」によって行われる。上述の通り、これは、ビュー及びサブファイルマッピングが計算される時である。サブファイルマッピングは、対応するＩ／Ｏノードに送られ、一方、ビューマッピングは、計算ノードで保存される。

一組のネストされた「ＦＡＬＬＳ」Ｓによって記述されたサブファイル／ビューが与えられると、ファイルの線形空間とサブファイルの線形空間との間のマッピングを計算する２つの関数ＭＡＰ_S（ｘ）及びＭＡＰ_S ^-1（ｘ）を構築する方法がここで説明される。例えば、サブファイルが図７のようにネストされた「ＦＡＬＬＳ」｛（２，３，６，１，Ｏ）｝の組によって記述されるとすれば、ファイルの１０番目のバイトは、サブファイル（ＭＡＰ_S（１０）＝２）の第２のバイト上にマップされるか、又はその逆（ＭＡＰ_S ^-1（２）＝１０）である。

ＭＡＰ_S（ｘ）は、ファイルの線形空間からＳによって定義されたサブファイルの線形空間上への位置ｘのマッピングを計算し、Ｓは、区分パターンＰに属する。ＭＡＰ_S（ｘ）は、現在の区分パターンの始めのマップ値と区分パターン内の位置のマップとの総計である。
ＭＡＰ_S（ｘ）
１：（（ｘ−ｄｉｓｐｌ） ｄｉｖ ＳＩＺＥ_P）ＳＩＺＥ_S＋ＭＡＰ−ＡＵＸ_S（（ｘ−ｄｉｓｐｌ） ｍｏｄ ＳＩＺＥ_P）

ＭＡＰ−ＡＵＸ_S（ｘ）は、一組のネストされた「ＦＡＬＬＳ」に対するファイル／サブファイルマッピングを計算する。ＭＡＰ−ＡＵＸ_S（ｘ）の行１は、ｘがマップされるＳのネストされた「ＦＡＬＬＳ」ｊを特定する。返されたマップ値（行２）は、「ＦＡＬＬＳ」の全サイズとｆ_jの始めでｌ_fjに対するｆ_j上へのマッピングとの総計である。
ＭＡＰ−ＡＵＸ_S（ｘ）
１：ｊ←ｍｉｎ｛ｋ｜ｘ＞ｌ_fk｝

ＭＡＰ−ＡＵＸ_f（ｘ）は、ネストされた「ＦＡＬＬＳ」ｆによって記述された線形空間上へファイルの位置ｘをマップする。返される値は、ｆの以前のブロックのサイズと現在のブロックの始まりに対する内側「ＦＡＬＬＳ」の組上へのマッピングとの総計である。
ＭＡＰ−ＡＵＸ_f（ｘ）
１：Ｉｆ Ｉ_f＝Ｏ ｔｈｅｎ
２：ｒｅｔｕｒｎ（ｘ ｄｉｖ ｓ_f）ＬＥＮ_f＋ｘ ｍｏｄ ｓ_f
３：ｅｌｓｅ
４：ｒｅｔｕｒｎ（ｘ ｄｉｖ ｓ_f）ＳＩＺＥ_If＋ＭＡＰ−ＡＵＸ_If（ｘ ｍｏｄ ｓ_f）
５：ｅｎｄ ｉｆ

例えば、図７のネストされた「ＦＡＬＬＳ」Ｓ＝（０，１，６，１，Ｏ）によって記述されたサブファイルに対して、ファイル／サブファイルマッピングは、次の関数によって計算される。
ＭＡＰ_S（ｘ）＝２（（ｘ−２） ｄｉｖ ６）＋（ｘ−２） ｍｏｄ ６ （６）
ＭＡＰ_S（ｘ）は、ｘがＳのラインセグメントの１つに属する場合のみ、Ｓによって定義されたサブファイル上へのｘのマッピングを計算することに注意すべきである。例えば、図７において、ファイルの５番目のバイトは、サブファイル０上でマップされない。しかし、所定のサブファイル上に直接マップする、ファイルの次の又は以前のバイトのいずれかのマッピングを計算するために、ＭＡＰ−ＡＵＸ_fを僅かに変更することは可能である。この考えは、ｘがｆの任意のブロックの外側に位置する時に検知し、ＭＡＰ−ＡＵＸ_fの本体を実行する前に、ｘを現在のストライドの終端（次のバイトマッピング）か、又は以前のブロックの終端（以前のバイトのマッピング）まで移動させることである。図７の場合、サブファイル０上へのファイルオフセット５の以前のマップは、サブファイルオフセット１であり、次のマップは、サブファイルオフセット２である。

は、Ｓで記述されたサブファイルの線形空間からファイルへのマッピングを、現在の区分パターンの開始位置と現在の区分パターン内の位置との総計として計算する。

は、ｘが配置されたＦＡＬＬＳｆ_j∈Ｓを探す。結果はｌ_fjと、ｆ_jの開始位置と、残りのオフセットのｆ_j内のマッピングとの総計である。

は、ネストされた「ＦＡＬＬＳ」ｆによって記述された線形空間の位置ｘをファイル上にマップする。結果は、ｆの内側「ＦＡＬＬＳ」の開始位置のマッピングと、内側「ＦＡＬＬＳ」上の残りの位置のマッピングとの総計である。

１：Ｉｆ Ｉ_f＝Ｏ ｔｈｅｎ
２：ｒｅｔｕｒｎ（ｘ ｄｉｖ ＬＥＮ_f）ｓ_f＋ｘ ｍｏｄ ＬＥＮ_f
３：ｅｌｓｅ

５：ｅｎｄ ｉｆ
例えば、図７のネストされた「ＦＡＬＬＳ」Ｓ＝（０，１，６，２，Ｏ）によって記述されたビューの場合、サブファイル／ファイルマッピングは、次の関数によって計算される。

サブファイルＳ及びビューＶが与えられると、Ｓ及びＶ間のｘの直接マッピングは、

として計算される。例えば、図１０（ｂ）において、サブファイル上へのビューオフセット４のマッピングは、

である。

は、実際に、同じＳに関してＭＡＰ_Sの逆を表すことが分る。

その結果、論理的区分及び物理的区分が同じ場合、各ビューは、正確にサブファイル上にマップされる。従って、全ての連続するビューのアクセスは、連続するサブファイルのアクセスに変わる。これは、所定の論理的分布に対して最適の物理的分布を表す。
好ましい実施形態は、ネストされた「ＦＡＬＬＳ」の組を使用してビュー及びサブファイルの区分の両方を表す。ファイルの線形空間内の一組のインデックスを表すネストされた「ＦＡＬＬＳ」の各組は、ファイルの部分集合を記述する。ビューを通してファイルデータにアクセスすることにより、アクセスされた領域は、いくつかのサブファイル上にマップされるかもしれない。従って、データを正しいサブファイルに再配布するために、ビューと各サブファイルとの間の交差が演算されるべきである。以下に説明する交差アルゴリズムは、ネストされた「ＦＡＬＬＳ」の二組の表示に共通するデータを表すのに使用することができるネストされた「ＦＡＬＬＳ」の組を計算する。ネストされた「ＦＡＬＬＳ」のインデックスは、ファイルの線形空間において与えられる。これらのインデックスの組は、ビュー又はサブファイルの線形空間上に投影することができる。

以下のネストされた「ＦＡＬＬＳ」交差アルゴリズムは、Ｒａｍａｓｗａｍｙ他による「ＦＡＬＬＳ」交差アルゴリズムである「ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ（ｆ₁，ｆ₂）」に基づいており、これは、ｆ₁及びｆ₂の交差を表すネストされた「ＦＡＬＬＳ」の組を効率的に計算する。
図１１は、（ａ）ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ（（０，７，１６，２），（０，３，８，４））＝（０，３，１６，２）と、（ｂ）ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ（（０，１，４，１），（０，０，２，２））＝（０，０，４，１）という２つの例を示す。
Ｒａｍａｓｗａｍｙ他の方法においては、アレー再配布に「ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ」が使用される。ｎ次元アレーの古い配布及び新しい配布は、各次元上の「ＦＡＬＬＳ」として表され、各次元上で交差が別々に実行される。好ましい実施形態の狙いが任意の再配布を提供することなので、多次元アレー再配布は適していない。任意の再配布を可能にし、同時に多次元アレー再配布を効率的に実行するアルゴリズムが要求される。

以下の手順は、最小限ｌ及び最大限ｒ間の「ＦＡＬＬＳ」ｆの切断からもたらされる「ＦＡＬＬＳ」の組を計算する。得られる「ＦＡＬＬＳ」は、ｌに対して計算される。この手順をネストされた「ＦＡＬＬＳ」交差アルゴリズムに使用する。
ＣＵＴ−ＦＡＬＬＳ（ｆ，ｌ，ｒ）
１：ＤＥＦ ｇ：ＦＡＬＬＳ
２：ｌ_g←ｌ：ｒ_g←ｒ；ｓ_g←ＬＥＮ_g；ｎ_g←１
３：Ｓ←ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ（ｆ，ｇ）
４：ｆｏｒ ａｌｌ ｈ∈Ｓ ｄｏ
５：ｌ_h←ｌ_h−１
６：ｒ_h←ｒ_h−１
７：ｅｎｄ ｆｏｒ
８：ｒｅｔｕｒｎ Ｓ

例えば、図１２からのＦＡＬＬＳ（３，５，６，５）をｌ＝４とｒ＝２８の間で切断すると、ｌ＝４に対して計算された集合｛（０，１，１，２），（５，７，６，３），（２３，２４，２，１）｝がもたらされる。
それぞれ区分パターンＰ₁及びＰ₂に属する、ネストされた「ＦＡＬＬＳ」Ｓ₁及びＳ₂の交差する集合に対するアルゴリズムについて以下に説明する。その集合は、ツリー表示に「ＦＡＬＬＳ」を含む。このアルゴリズムは、一般性を損なうことなく、ツリーの高さは同じと仮定する。同じでない場合は、低いツリーの高さは、外側「ＦＡＬＬＳ」を追加して変えることができる。

「ＩＮＴＥＲＳＥＣＴ」は、交差の区分パターンＰのサイズをＰ₁及びＰ₂（行１）のサイズの最小公倍数として計算する。続いて、Ｓ₁及びＳ₂は、Ｐのサイズ（行２〜７）の上で交差することができるように拡張される。
ＩＮＴＥＲＳＥＣＴ（Ｓ₁，Ｓ₂）
１：ＳＩＺＥ_p←ｌｃｍ（ＳＩＺＥｐ₁、ＳＩＺＥｐ₂）
２：ｆｏｒ ａｌｌ ｆ∈Ｓ₁ ｄｏ
３：ｎ_f←ｎ_fＳＩＺＥ_p／ＳＩＺＥ_p2
４：ｅｎｄ ｆｏｒ
５：ｆｏｒ ａｌｌ ｆ∈Ｓ₂ ｄｏ
６：ｎ_f←ｎ_fｌｃｍ（ＳＩＺＥ_p1、ＳＩＺＥ_p2）／ＳＩＺＥ_p2
７：ｅｎｄ ｆｏｒ
８：ｒｅｔｕｒｎ ＩＮＴＥＲＳＥＣＴ−ＡＵＸ（Ｓ１、０、；ＳＩＺＥ_p、Ｓ₂、０、ＳＩＺＥ_p）

「ＩＮＴＥＲＳＥＣＴ−ＡＵＸ」は、「ＦＡＬＬＳ」をペアで交差した後で（行８）、「ＦＡＬＬＳ」ツリーを回帰的に横断することにより（行１２）、二組のネストされた「ＦＡＬＬＳ」Ｓ₁及びＳ₂間の交差の計算をする。
「ＩＮＴＥＲＳＥＣＴ−ＡＵＸ」は、ｆ₁∈Ｓ₁及びｆ₂∈Ｓ₂であるような可能な全ての対（ｆ₁，ｆ₂）を最初に考慮する。「ＦＡＬＬＳ」は、Ｓ１及びＳ２（行４）の外側「ＦＡＬＬＳ」の交差の左側及び右側インデックスであるｌ₁及びｒ₁の間で切断される。インデックスｌ₁及びｒ₁は、Ｓ₁の外側「ＦＡＬＬＳ」に対して計算され、回帰コールのパラメータとして行１２から受け取られる。同じ説明がｆ₂（行５）に当てはまる。「ＣＵＴ−ＦＡＬＬＳ」は、内側「ＦＡＬＬＳ」の特性が外側「ＦＡＬＬＳ」の左側インデックスに対してであることを保証するために使用される。「ＦＡＬＬＳ」は、切断ｆ₁及びｆ₂からもたらされ、続いてペアで交差される（行８）。回帰コールは、サブツリーｆ₁及びｆ₂に下り、その内側「ＦＡＬＬＳ」の交差を回帰的に計算する（行１２）。

ＩＮＴＥＲＳＥＣＴ−ＡＵＸ（Ｓ₁，ｌ₁，ｒ₁，Ｓ₂，ｌ₂，ｒ₂）
１：Ｓ←０
２：ｆｏｒ ａｌｌ ｆ₁∈Ｓ₁ ｄｏ
３：ｆｏｒ ａｌｌ ｆ₂∈Ｓ₂ ｄｏ
４：Ｃ₁←ＣＵＴ−ＦＡＬＬＳ（ｆ₁、ｌ₁、ｒ₁）
５：Ｃ₂←ＣＵＴ−ＦＡＬＬＳ（ｆ₂、ｌ₂、ｒ₂）
６：ｆｏｒ ａｌｌ ｇ₁∈Ｃ₁ ｄｏ
７：ｆｏｒ ａｌｌ ｇ₂∈Ｃ₂ ｄｏ
８：Ｓ←Ｓ∪ＩＮＴＥＲＳＥＣＴ−ＦＡＬＬＳ（ｇ₁、ｇ₂）
９：ｅｎｄ ｆｏｒ
１０：ｅｎｄ ｆｏｒ
１１：ｆｏｒ ａｌｌ ｆ∈Ｓ ｄｏ
１２：Ｉ←ＩＮＴＥＲＳＥＣＴ−ＡＵＸ（Ｉ_f1，（ｌ_f−ｌ_f1） ｍｏｄ ｓ_f1，（ｒ_f−ｌ_f1） ｍｏｄ ｓ_f1，Ｉ_f2；（ｌ_f−ｌ_f2） ｍｏｄ ｓ_f2，（ｒ_f−ｌ_f2） ｍｏｄ ｓ_f2）
１３：ｅｎｄ ｆｏｒ
１４：ｅｎｄ ｆｏｒ
１５：ｅｎｄ ｆｏｒ
１６：ｒｅｔｕｒｎ Ｓ

例えば、図１３は、サイズ３２の区分パターンに属する二組のネストされた「ＦＡＬＬＳ」であるＳ₁＝（０，７，１６，２，（０，１，４，１，Ｏ））と、Ｓ₂＝（０，３，８，４，（０，０，２，２，Ｏ））との交差を示す。外側及び内側「ＦＡＬＬＳ」の交差は、図１１に既に示されている。交差の結果は、Ｖ∩Ｓ＝（０，３，１６，２，（０，０，４，１，Ｏ））であり、これは、（０，１，１６，２，Ｏ）に簡略化することができる。

上述のアルゴリズムは、二組の「ＦＡＬＬＳ」Ｓ₁及びＳ₂の交差Ｓを計算する。その結果、Ｓは、Ｓ₁とＳ₂の両方の部分集合である。投影の手順は、Ｓ₁とＳ₂によって記述された線形空間（ビュー又はサブファイル）上にＳを投影するための手順である。以下に示すように、この投影は、計算ノード及びＩ／Ｏノード間で交換されたデータの拡散及び収集に使用される。
ＰＲＯＪ_S（Ｒ）は、Ｓ上へのＲの投影を計算する。それは、単に補助手順「ＰＲＯＪ−ＡＵＸ」を呼び出す。
ＰＲＯＪ_S（Ｒ）
１：ＰＲＯＪ−ＡＵＸ_S（Ｒ，０）

ＰＲＯＪ−ＡＵＸ_S（Ｒ，オフセット）は、Ｒの「ＦＡＬＬＳ」を表すツリーを横切り、各「ＦＡＬＬＳ」をＳによって記述されたサブファイル上に投影する。内側「ＦＡＬＬＳ」の各組が外側「ＦＡＬＬＳ」の左側インデックスに対して与えられるので、引数オフセットが必要である。従って、オフセットは、サブファイルの開始からの絶対変位を累積する。
ＰＲＯＪ−ＡＵＸ_S（Ｒ，オフセット）
１：Ｐ←０
２：ｆｏｒ ａｌｌ ｆ∈Ｒ ｄｏ
３：Ｐ←ＰＲＯＪ−ＡＵＸ_S（ｆ，オフセット）
４：ｉｆ Ｉ_f≠０ ｔｈｅｎ
５：Ｉ_P←ＰＲＯＪ−ＡＵＸ_S（Ｉ_f，オフセット＋ｌ_f）
６：ｅｎｄ ｉｆ
７：Ｐ←Ｐ∪｛ｐ｝
８：ｅｎｄ ｆｏｒ
９：ｒｅｔｕｒｎ Ｐ

ＰＲＯＪ−ＡＵＸ_S（ｆ，オフセット）は、オフセットと共に変位した「ＦＡＬＬＳ」ｆをＳによって記述されたサブファイルに投影する。
ＰＲＯＪ−ＡＵＸ_S（ｆ，オフセット）
１：ＤＥＦ ｇ：ＦＡＬＬＳ
２：ｌ_g←ＭＡＰ_S（ｌ_f＋オフセット）−ＭＡＰ_S（オフセット）
３：ｒ_g←ＭＡＰ_S（ｒ_f＋オフセット）−ＭＡＰ_S（オフセット）
４：ｓ_g←ＭＡＰ_S（ｓ_f＋オフセット）−ＭＡＰ_S（オフセット）
５：ｎ_g←ｎ_f
６：ｒｅｔｕｒｎ ｇ

例えば、交差に関連して上に与えられた例においては、ＰＲＯＪ_V（Ｖ∩Ｓ）＝（０，０，４，２，Ｏ）（図１３（ｃ））、及び、ＰＲＯＪ_S（Ｖ∩Ｓ）＝（０，０，４，２，Ｏ）（図１３（ｄ））である。
「ＩＮＴＥＲＳＥＣＴ」と「ＰＲＯＪ_S」は、両方とも同じ組のツリーを横切るので単一アルゴリズムにコンパクト化することができる。明確にするために、それらは別々に表されてきた。

ここで、好ましい実施形態のデータ演算においてマッピング機能と交差アルゴリズムがどのように使用されるかを示す。書込み及び読取りは逆対称なので、ここでは書込み演算だけ説明する。図１３に示すビュー及びサブファイルに対して、以下の説明は図１４に示す例と共に為される。
一組のネストされた「ＦＡＬＬＳ」Ｓと、左及び右の限界ｌ及びｒとがそれぞれ与えられると仮定する。Ｓによって定義された不連続な領域と連続バッファ「ｂｕｆ」（又は、サブファイル）との間のデータをコピーするために２つの手順が実行される。
・ＧＡＴＨＥＲ（ｄｅｓｔ，ｓｒｃ，ｍ，Ｍ，Ｓ）は、Ｍとｍの間のＳによって定義されるように、不連続データを「ｓｒｃ」バッファから連続バッファ（又は、サブファイル）「ｄｅｓｔ」にコピーする。例えば、図１４（ｂ）において、計算ノードは、ＦＡＬＬＳ｛（０，０，４，２，Ｏ）｝の組を使用して、ｍ＝０及びＭ＝４の間でデータをビューからバッファ「ｂｕｆ₂」に収集する。
・ＳＣＡＴＴＥＲ（ｄｅｓｔ，ｓｒｃ，ｍ，Ｍ，Ｓ）は、ｍとＭの間のＳによって定義されるように、連続バッファ（又は、サブファイル）「ｓｒｃ」からバッファ「ｄｅｓｔ」上に非連続的にデータを配布する。例えば、図１４（ｂ）において、Ｉ／Ｏノードは、ＦＡＬＬＳ｛（０，０，４，２，Ｏ）｝の組を使用して、ｍ＝０及びＭ＝４の間で「ｂｕｆ₂」からサブファイルにデータを分散する。

実行は、ネストされた「ＦＡＬＬＳ」のツリー表示の組のＳからの回帰的横断から成る。複製する演算は、ツリーの葉で発生する。
計算ノードが現存するファイルを開くと、それは、メタデータマネージャから変位「ｄｉｓｐｌ」及び区分パターンＰを受け取る。
計算ノードが、変位「ｄｉｓｐｌ」及び区分パターンＰと共に、開いているファイル上にＶによって記述されたビューを設定すると、Ｖ及び各サブファイル間の交差が計算される（行２）。Ｖ上への交差の投影が計算されて（行３）、計算ノードに保存される。Ｓ上への交差の投影が計算されて（行４）、対応するサブファイルのＩ／Ｏノードに送られる（行５）。
１：ｆｏｒ ａｌｌ Ｓ∈Ｐ ｄｏ
２：Ｖ∩Ｓ←ＩＮＴＥＲＳＥＣＴ（Ｖ，Ｓ）

６：ｅｎｄ ｆｏｒ
図１４（ｂ）からの例は、投影に関連して上述の例で計算されたビュー及び１つのサブファイルに対する投影、

を示す。
計算ノードが「ｄｉｓｐｌ」及びＰによって定義されたファイルを開き、その上にビューＶを設定したと仮定する。上述の通り、計算ノードは

を保存し、サブファイルＳのＩ／Ｏノードは、全てのＳ∈Ｐに関して、

を保存する。次に、ｍ_VとＭ_V間のビューの連続する部分のバッファ「ｂｕｆ」からファイルへの書込みに関連する段階を示す（図１４及び以下の２つの擬似コード部分も参照）。
Ｓによって記述された各サブファイル（１）と交差Ｖ（２）に対して、計算ノードは、ｍ_V及びＭ_Vのサブファイル上へのマッピングｍ_S及びＭ_Sをそれぞれ計算し（３及び４）、次に、それらをサブファイルＳのＩ／Ｏサーバに送る（５）。続いて、

が、ｍ_V及びＭ_V間で連続する場合、Ｉ／Ｏサーバに「ｂｕｆ」が直接送られる（７）。そうでなければ、「ｂｕｆ」の不連続領域がバッファ「ｂｕｆ₂」に収集されて（９）、Ｉ／Ｏノードに送られる（１０）。
１：ｆｏｒ ａｌｌ Ｓ∈Ｐ ｄｏ

５：ＳのＩ／ＯサーバにサブファイルＳの（ｍ_S，Ｍ_S）を送る。

７：Ｓによって定義されたサブファイルのＩ／Ｏサーバに、ｍ_V及びＭ_V間のＭ_V−ｍ_V＋１バイトを送る。
８：ｅｌｓｅ

１０：Ｓによって定義されたサブファイルのＩ／Ｏサーバに、ｂｕｆ₂を送る。
１１：ｅｎｄ ｉｆ
１２：ｅｎｄ ｉｆ
１３：ｅｎｄ ｆｏｒ
Ｉ／Ｏサーバは、ｍ_S及びＭ_S間でＳによって定義されたサブファイルに対する書込み要求（１）と、バッファ「ｂｕｆ」に書き込まれるデータ（２）とを受け取る。

が連続の場合、「ｂｕｆ」は、連続的にサブファイルに書き込まれる（４）。そうでなければ、データは、「ｂｕｆ」からファイルに分散される（６）。
１：計算ノードからｍ_S及びＭ_Sを受け取る。
２：データをｂｕｆに受け取る。

４：ｂｕｆをｍ_S及びＭ_S間でサブファイルＳに書き込む。
５：ｅｌｓｅ

７：ｅｎｄ ｉｆ

「Ｍｙｒｉｎｅｔ」によって相互接続された、２５６ｋＢのＬ２キャッシュ及び５１２ＭＢのＲＡＭを有する１６個の「Ｐｅｎｔｉｕｍ（登録商標） ＩＩＩ」８００ＭＨｚのクラスター上で実験が行われた。各マシンは、「ＩＤＥ」ディスクを備えている。それらは、全て「ＬＩＮＵＸ」カーネルを作動させた。バッファディスクの読取り処理量は、「ｈｄｐａｒｍ」ユーティリティで測定して、毎秒２５．５０ＭＢである。「ＴＣＰ」処理量は、「ｔｔｃｐ」ベンチマークで測定して、毎秒８２ＭＢである。

好ましい実施形態においてファイルに対して二次元マトリックスを書き込み及び読み取りするベンチマークが書き込まれた。２５６×２５６、５１２×５１２、１０２４×１０２４、及び２０４８×２０４８の別々のサイズのマトリックスに対して実験が繰り返された。各サイズに対して、行のブロック（ｒ）、列のブロック（ｃ）、及び正方形ブロック（ｂ）の３つの方法で、ファイルを４つのサブファイルに物理的に区分した（図１５参照）。各サブファイルは、１つのＩ／Ｏノードに書き込まれた。各サイズ及び各物理的区分に対して、行のブロックの４つのプロセッサ間でファイルを論理的に区分した。全ての測定は数回繰り返され、最小値と最大値が削除されて平均値が計算された。
Ｉ／Ｏノードがそれらのバッファキャッシュ及びそれらのディスクにそれぞれ書き込んでいる時に、書込み及び読取り作動の異なる位相に対するタイミングが計測された。表１は、１つの計算ノードに対する平均的な結果を示し、表２は、１つのＩ／Ｏノードに対する平均的な結果を示す。

読取りに関する結果が書込みに非常に近かったので、書込みタイミングだけを示すことにする。それによると以下の所見が得られた。
・物理的及び論理的区分が与えられる時、交差を実行して投影を計算する時間は、マトリックスのサイズによって大きくは変わらない。予想通り、区分が同じであればｔ_iは小さく、区分が適合しないとより大きい。尚、ｔ_iがビュー設定時のみに費やす必要があり、何回かのアクセスに亘って償却することができることが分る。
・サブファイルｔ_m上にビューのアクセス間隔の端点をマップする時間は非常に短い。
・収集時間ｔ_gは、マトリックスサイズと、物理的及び論理的区分の適合の程度とによって変化する。それは、最適な適合では全てのサイズに対して０である。所定のマトリックスサイズに対しては、区分の適合が不良の場合、再区分によりバッファに集まるデータの小さな部分が多くなるのでｔ_gは最大になる。
・所定のサイズに対しては、

の時間は、計算ノードで測定されるネットワーク及びＩ／Ｏサーバの作動の合計を含む。
それらの値は、最も遅いＩ／Ｏサーバによって制約される。
・性能は、Ｉ／Ｏノードコンテンション、すなわち、１つのＩ／Ｏノードと接触する計算ノードの平均数によって影響される。適合が不良のパターンに対してコンテンションは大きく、従って、計算ノードの並列性，及び暗に拡張容易性を妨げる。例えば、ブロックの列とコラムの列との間のデータの再配布により、４つの計算ノードは、各々、全ての４つのＩ／Ｏサーバと接触することになる（表２の４番目のコラムを参照）。最適な適合に対しては、コンテンションは１であり、従って、各計算ノードの要求は、異なるＩ／Ｏノードに送られる。
・分散時間、

は、不連続バッファをバッファキャッシュとディスクとにそれぞれ書き込むための時間を含む。ネットワークカードからバッファキャッシュに直接書き込む連続書込みの場合は最適化されなかった。従って、追加の複製が実行される。その結果、配布の全ての３つの異なる対に対する数値は、大きなメッセージに関しては近い値である。しかし、小さなサイズ（２５６と５１２）に関しては、バッファキャッシュ，及び特にディスクに対する書込み性能は、最適な配布の適合に対して最良になる。

表３は、１クライアントの平均処理量を示す。５番目と７番目のコラムは、同じマトリックスサイズについて、不良適合パターンに対する最適適合パターンに関して著しい性能の改善を示し、バッファキャッシュへの書込みでは、１１１％から２９５％の範囲であり、ディスクへの書込みでは、１１１％から３２２％の範囲である。

実験の結果は、物理的区分及び論理的区分が適合する時に並列アプリケーションの性能が最適になることを示している。

本発明が説明されて、クラスター上のファイルレイアウトの高度な制御を提供する並列ファイルシステムが示された。本発明はまた、アプリケーションがファイル上に任意のビューを設定することを可能にする。この並列ファイルシステムは、例えばｎ次元アレー分布のような、通常のアクセスパターン及びファイルレイアウトを表現するコンパクトな方法を提供する。それはまた、レイアウト間の便利な変換を可能にする。本明細書の実験部分において、アクセスパターン及びファイルレイアウト間の適合がいかに本発明の性能に影響を与えるかが示された。アクセスパターンと適度に適合するファイルレイアウトを使用して、並列アプリケーションがそのＩ／Ｏ性能を改善することができることが見出された。これは、Ｉ／Ｏサーバの並列性、及び、ディスク及びネットワーク帯域幅のより良い利用法をもたらす。従って、物理的及び論理的区分の共通の内部データ表現は、柔軟性のある本発明の物理的レイアウトと共に、Ｉ／Ｏサブシステムのより広範囲で効率の良い利用法に貢献することができる。

マッピング機能及びデータ再配布という並列ファイルシステムにおけるデータ演算の実行のための２つの機構が示された。好ましい実施形態は、ファイルの物理的及び論理的区分の両方のために共通のデータ表現を使用する。区分（サブファイル又はビュー）の全てのエンティティは、線形的にアドレス可能とすることができる。そのような２つの線形空間の間のマッピングを計算するために、マッピング機能が使用される。データ再配布アルゴリズムは、２つの任意の配布間で変換する必要があるインデックスの組を計算する。これらの組は、ビュー設定時に一度だけ計算され、数回のアクセスに亘って償却される。その後、それらは、計算ノード及びＩ／Ｏノード間で通信中にデータ分散及び収集で使用される。
当業者によって様々な小さな変更及び修正が提案されるかもしれないが、特許請求の範囲は、分散ファイルシステムの分野への本発明の寄与の範囲に無理なく含まれるであろうそのような変更及び修正を含むように意図されていることが理解されるものとする。

１０ 分散ファイルシステム
１２ 計算ノード
１４ Ｉ／Ｏノード
１６ 相互接続ネットワーク

Claims (9)

1. 相互接続ネットワーク（１６）によって接続された、複数の計算ノード（１２）と複数の入力／出力（Ｉ／Ｏ）ノード（１４）とを含む分散ファイルシステム（１０）であって、前記システムは、
   前記システムに保存されたファイルの物理的及び論理的パーティションの両方のために共通のデータ表現を使用するようになっており、
   前記パーティションの要素は、リニアにアドレス可能であり、
   それぞれの計算ノード（１２）は、複数のファイル操作を実行するようにプログラムされ、前記ファイル操作は、
   ファイルのリニア空間とサブファイルのリニア空間との間のマッピングを計算する段階と、
   ビューのリニア空間とサブファイルのリニア空間との間のマッピングを計算する段階と、
   ビュー及びサブファイル間で交差アルゴリズムを実行する段階と、
   データ演算を実行する段階と、を含み、
   それによって、プロセッサ指標付き標識ラインセグメント群（ＰＩＴＦＡＬＬＳ）が、外側ラインセグメント群（ＦＡＬＬＳ）を形成する、一組の等間隔で配置されたラインセグメント群（ＦＡＬＬＳ）を表わすデータ表現のために使用され、それによって、それぞれの外側ＦＡＬＬＳは、Ｉ／Ｏノード（１４）上へファイルの物理的パーティショニングを、計算ノード（１２）上へファイルの論理的パーティショニングを表わすためのネストしたＰＩＴＦＡＬＬＳを形成し、それらの間をマッピングする、一組の内側ＰＩＴＦＡＬＬＳを含み、それによって利用可能な記憶媒体上及び幾つかの計算ノード（１２）の中のデータをそれぞれ任意にパーティショニングすることができる
   ことを特徴とするシステム。
2. 前記複数のＩ／Ｏノード（１４）からファイルに関する情報を収集し、該Ｉ／Ｏノード（１４）を整合性のある状態に維持するようになっているメタデータマネージャを含むことを特徴とする請求項１に記載の分散ファイルシステム（１０）。
3. 各Ｉ／Ｏノード（１４）は、それぞれのＩ／Ｏノード（１４）上に保存されたサブファイルにデータを書き込み、かつそこからデータを読み取るタスクを実行するＩ／Ｏサーバを含むことを特徴とする請求項２に記載の分散ファイルシステム（１０）。
4. Ｉ／Ｏサーバが、前記Ｉ／Ｏノード（１４）で保存されたサブファイルの各々に関するメタデータを維持し、要求に応じてそれを前記メタデータマネージャに配信するようになっていることを特徴とする請求項２に記載の分散ファイルシステム（１０）。
5. 前記計算ノード（１２）は、システムのメタデータに関わる任意のファイル操作のために前記メタデータマネージャと通信するようになっていることを特徴とする請求項２に記載の分散ファイルシステム（１０）。
6. ファイルがサブファイルに物理的にパーティショニングされている複数のＩ／Ｏノード（１４）、及びファイルがビューに論理的にパーティショニングされている複数の計算ノード（１２）を含む分散ファイルシステム（１０）を動作させる方法であって、前記方法は、
   （ｉ）前記システムがサブファイルとビューとの間のマッピング機能を実行する段階と、
   （ｉｉ）前記システムがパーティションの間でデータを再分配する段階であって、
   それによって、プロセッサ指標付き標識ラインセグメント群（ＰＩＴＦＡＬＬＳ）が、外側ラインセグメント群（ＦＡＬＬＳ）を形成する、一組の等間隔で配置されたラインセグメント群（ＦＡＬＬＳ）を表わすデータ表現のために前記システムによって使用され、それによって、それぞれの外側ＦＡＬＬＳは、Ｉ／Ｏノード（１４）上へファイルの物理的パーティショニングを、計算ノード（１２）上へファイルの論理的パーティショニングを表わすためのネストしたＰＩＴＦＡＬＬＳを形成し、それらの間をマッピングする、一組の内側ＰＩＴＦＡＬＬＳを含み、それによって利用可能な記憶媒体上及び前記システムの幾つかの計算ノード（１２）の中のデータをそれぞれ任意にパーティショニングすることができる
   ことを特徴とする方法。
7. 前記再分配は、前記システムによって、
   （ａ）２つの物理的パーティション間、
   （ｂ）２つの論理的パーティション間、及び
   （ｃ）論理的パーティション及び物理的パーティション間、
   で行うことができる、
   ことを特徴とする請求項６に記載の方法。
8. （ａ）ファイルのリニア空間からサブファイルのリニア空間上へのファイルオフセットのマッピングを前記システムによって計算するためのアルゴリズムと、
   （ｂ）サブファイルのリニア空間からファイルへのマッピングを前記システムによって計算するためのアルゴリズムと、
   （ｃ）サブファイル及びビュー間のマッピングを前記システムによって計算するためのアルゴリズムと、
   （ｄ）ネストされたラインセグメント群の組の交差を前記システムによって計算するためのアルゴリズムと、
   （ｅ）ラインセグメント群の別の組によって記述されたリニア空間上への一組のラインセグメント群の投影を前記システムによって計算するためのアルゴリズムと、
   を含む複数のアルゴリズムが前記システムによって実行される、
   ことを特徴とする請求項６に記載の方法。
9. 前記方法は、
   （ａ）前記システムが、ビュー設定において、前記ファイルの前記論理的パーティショニングと前記物理的パーティショニングとの間のマッピングの計算を実行する段階と、
   （ｂ）前記システムが、計算のアクセスインデックスのオーバーヘッドがビュー設定の時に前記システムによって一度だけ費やされるように、メッセージ内に又はそれからデータを収集／分散するための読取り／書込み演算において前記マッピングを使用する段階と、を含むことを特徴とする請求項６に記載の方法。

Images