(57)【要約】  データ記憶のための装置は、複数のＮＦＳサーバにてなるクラスタを含む。各サーバは、到来するファイルシステム要求と、サーバ間のクラスタトラフィックとのための複数のネットワークポートを有する。本装置は、複数のサーバと通信する複数の記憶装置アレイを含む。サーバは、ストライプ化されたファイルシステムを使用してデータを格納する。また、データ記憶のための方法と、ファイルの記憶領域を確立する方法と、記憶領域からファイルを除去する方法と、ファイルにおけるデータを読み出す方法と、ファイルにデータを書き込む方法とが存在する。
2007537501.tif 000002
【特許請求の範囲】
【請求項１】
データ記憶のための装置であって、
複数のＮＦＳサーバにてなるクラスタを備え、各サーバは、到来するファイルシステム要求と、サーバ間のクラスタトラフィックとのための複数のネットワークポートを有し、
上記複数のサーバと通信する複数の記憶装置アレイを備え、上記複数のサーバはストライプ化されたファイルシステムを使用してデータを格納する装置。
【請求項２】
各サーバはネットワーク構成要素とディスク構成要素とを有する請求項１記載の装置。
【請求項３】
各ディスク構成要素は仮想ファイルシステムを有し、上記各ディスク構成要素の仮想ファイルシステムは、ストライプ化されたＶＦＳをともに形成する請求項２記載の装置。
【請求項４】
仮想ファイルシステムのためのすべてのディスク構成要素はメタデータサーバとして動作する請求項３記載の装置。
【請求項５】
ファイルは複数の属性を有し、
各ファイルのための各サーバは、上記ファイルに係る既知の最新バージョンの属性と、書き込み処理動作の結果へ割り当てるための更新時刻及び状態変更時刻の値の範囲とを格納するキャッシュ構成要素を保持する請求項４記載の装置。
【請求項６】
上記仮想ファイルシステムのメタデータサーバではない各ディスク構成要素は、入出力セカンダリ装置である請求項５記載の装置。
【請求項７】
ファイルの更新時刻又はファイルの状態変更時刻の範囲は、上記メタデータサーバから上記入出力セカンダリ装置によって予約される請求項６記載の装置。
【請求項８】
上記メタデータサーバから取得される範囲内の更新時刻及び状態変更時刻は、上記入出力セカンダリ装置においてすでにキューイングされている処理動作に対して発行される請求項７記載の装置。
【請求項９】
上記メタデータサーバから取得される範囲内の更新時刻及び状態変更時刻は、上記範囲が上記メタデータサーバから上記入出力セカンダリ装置によって予約された後の時間ウィンドウの間に受信される処理動作に対して発行される請求項８記載の装置。
【請求項１０】
ファイルのすべてのストライプに影響する処理動作は、最初に上記メタデータサーバにおいてファイルに対して実行し始め、次にすべての入出力セカンダリ装置において実行し、よって、上記入出力セカンダリ装置における処理動作は、上記メタデータサーバとの通信をすでに終えているすでに実行中の処理動作のみを待機する請求項９記載の装置。
【請求項１１】
処理動作は少なくとも２つのロック処理モデルのうちの一方に従い、
その第１のモデルは、最初に上記メタデータサーバと同期化し、次に上記入出力セカンダリ装置において実行中の他の処理動作との同期化によりコア実行を開始するものであり、
その第２のモデルは、最初に上記メタデータサーバにおいて同期化し、次に、上記入出力セカンダリ装置においてコア実行を開始している１つ又は複数の入出力セカンダリ装置における処理動作と同期化するというものである請求項１０記載の装置。
【請求項１２】
上記クラスタネットワークはスター型トポロジーで接続される請求項１１記載の装置。
【請求項１３】
上記クラスタネットワークはスイッチドイーサネットである請求項１２記載の装置。
【請求項１４】
データ記憶のための方法であって、
複数のＮＦＳサーバにわたってファイルを作成するステップと、
上記複数のサーバにおける複数のデータストリップとしてデータを上記ファイルへ書き込むステップとを含み、上記複数のストリップはともに、ストライプを形成し、
上記複数のサーバから複数のデータストリップを読み出すステップと、
上記ストリップを上記複数のサーバから削除するステップとを含む方法。
【請求項１５】
ＮＦＳサーバの仮想ファイルシステムのためのディスク構成要素をメタデータサーバとして識別し、上記メタデータサーバとしては識別されない複数のＮＦＳサーバのための複数のディスク構成要素を複数の入出力セカンダリ装置として識別するステップを含む請求項１４記載の方法。
【請求項１６】
メタデータサーバにおけるアクティブな各ファイルのための各入出力セカンダリ装置におけるキャッシュ構成要素に、処理延期期間において有効な上記ファイルに係る既知の最新バージョンの属性を格納するステップを含む請求項１５記載の方法。
【請求項１７】
書き込み処理動作へ割り当てるための更新時刻及び状態変更時刻の値の範囲を上記キャッシュ構成要素に格納するステップを含む請求項１６記載の方法。
【請求項１８】
ファイルの現在の属性を取得するために、上記キャッシュ構成要素により上記メタデータサーバに対して状態要求を行うステップを含む請求項１７記載の方法。
【請求項１９】
上記状態要求を行うステップは、上記メタデータサーバから更新時刻及び状態変更時刻の範囲を取得するステップを含む請求項１８記載の方法。
【請求項２０】
ファイル読み出し及びファイル書き込み要求が上記キャッシュ構成要素により許可されて実行完了となるまで、上記入出力セカンダリ装置において上記ファイル読み出し及びファイル書き込み要求をキューイングするステップを含む請求項１９記載の方法。
【請求項２１】
上記キャッシュ構成要素により、上記ファイルに関して実行されているファイル読み出し及びファイル書き込み要求と、読み出し又は書き込み中である範囲とを追跡するステップを含む請求項２０記載の方法。
【請求項２２】
読み出し処理動作が実行されなければならないときに、上記キャッシュ構成要素の無効モードから読み出しモードへの移行を要求するステップを含む請求項２１記載の方法。
【請求項２３】
ファイル読み出し要求によって影響されるバイト範囲をチェックし、以前に許可されて現時点で実行中である任意のファイル書き込み要求のバイト範囲にそれが重複しないことを保証するステップを含む請求項２２記載の方法。
【請求項２４】
ファイル書き込み要求に応答して、上記キャッシュ構成要素が書き込みモードへ移行することを要求するステップを含む請求項２３記載の方法。
【請求項２５】
許可されかついまだ実行中の任意のファイル読み出し要求又はファイル書き込み要求との重複について、上記ファイル書き込み要求によって影響されるバイト範囲を上記キャッシュ構成要素によりチェックするステップを含む請求項２４記載の方法。
【請求項２６】
書き込み要求を実行するときに、上記キャッシュ構成要素に格納されている更新時刻及び状態変更時刻の範囲から、更新時刻及び状態変更時刻にてなるペアを割り当てるステップを含む請求項２５記載の方法。
【請求項２７】
処理待機中のファイル読み出し及びファイル書き込み要求のキューの先頭をチェックし、先頭の要求が、ファイル読み出し又はファイル書き込み要求のいずれかの完了後に上記キャッシュ構成要素により許可され得るか否かを確認するステップを含む請求項２６記載の方法。
【請求項２８】
ファイル書き込み要求に応答してファイル長が更新されなければならないことを上記キャッシュ構成要素により検出するステップと、
上記キャッシュ構成要素を排他モードへ移行させるステップと、
上記ファイルの長さ属性を更新するために上記メタデータサーバへのファイル書き込み状態呼び出しを発生させるステップとを含む請求項２７記載の方法。
【請求項２９】
メタデータサーバにおけるアクティブな各ファイルのための各入出力セカンダリ装置におけるキャッシュ構成要素に、処理延期期間において有効な上記ファイルに係る既知の最新バージョンの属性を格納するステップを含む請求項１４記載の方法。
【請求項３０】
書き込み処理動作へ割り当てるための更新時刻及び状態変更時刻の値の範囲を上記キャッシュ構成要素に格納するステップを含む請求項１４記載の方法。
【請求項３１】
ファイルの現在の属性を取得するために、上記キャッシュ構成要素により上記メタデータサーバに対して状態要求を行うステップを含む請求項１４記載の方法。
【請求項３２】
上記状態要求を行うステップは、上記メタデータサーバから更新時刻及び状態変更時刻の範囲を取得するステップを含む請求項３１記載の方法。
【請求項３３】
読み出し処理動作が実行されなければならないときに、キャッシュ構成要素の無効モードから読み出しモードへの移行を要求するステップを含む請求項１４記載の方法。
【請求項３４】
ファイル書き込み要求に応答して、キャッシュ構成要素が書き込みモードへ移行することを要求するステップを含む請求項１４記載の方法。
【請求項３５】
ファイル書き込み要求に応答してファイル長が更新されなければならないことを上記キャッシュ構成要素により検出するステップと、
上記キャッシュ構成要素を排他モードへ移行させるステップと、
上記ファイルの長さ属性を更新するためにメタデータサーバへのファイル書き込み状態呼び出しを発生させるステップとを含む請求項１４記載の方法。
【請求項３６】
ファイルの記憶領域を確立する方法であって、
ネットワーク構成要素においてＮＦＳ作成要求を受信するステップと、
メタデータサーバにおいて、上記ネットワーク構成要素からファイル作成要求を受信するステップと、
上記メタデータサーバにおいて、上記ファイルのためのｉノード番号を割り当てるステップと、
入出力セカンダリ装置に対して作成呼び出しを発生させて、複数の入出力セカンダリ装置により割り当てられたように上記ファイルをマーキングするステップと、
上記メタデータサーバにおいてファイルの作成を実行するステップとを含む方法。
【請求項３７】
ファイルを記憶領域から除去する方法であって、
メタデータサーバにおいてファイル削除要求を受信するステップと、
上記メタデータサーバにおいて、当該メタデータサーバにより親ディレクトリから上記ファイルのファイル名を除去するステップと、
上記メタデータサーバにおいて、当該メタデータサーバにより上記ファイルをファイル削除リストへ入れるステップと、
複数の入出力セカンダリ装置へ削除呼び出しを送信するステップと、
上記メタデータサーバにおいて、上記複数の入出力セカンダリ装置から、上記ファイルを削除したという複数の確認応答呼び出しを受信するステップと、
上記メタデータサーバにおいて上記ファイルを削除するステップと、
上記ファイル削除リストから上記ファイルを除去するステップと、
上記メタデータサーバにおいて、当該メタデータサーバにより、上記ファイルに関連付けられたｉノード番号をフリーリストに入れるステップとを含む方法。
【請求項３８】
ファイルにおけるデータを読み出す方法であって、
ネットワーク構成要素において、上記ファイルにおけるデータに対するＮＦＳ読み出し要求を受信するステップと、
上記ネットワーク構成要素により、上記データを含む少なくとも１つのストリップをどのＶＦＳが格納しているかを決定するステップと、
上記ネットワーク構成要素から、上記データのストリップを格納している複数のサーバの少なくとも１つのディスク構成要素へファイル読み出し要求を送信するステップと、
各ディスク構成要素により、上記ファイルに関連付けられた現在の属性を取得するステップと、
上記ストリップを有する各ディスク構成要素から上記ファイルのストリップを読み出すステップと、
上記ファイル読み出し要求に関連する応答を生成するステップとを含む方法。
【請求項３９】
ファイルにデータを書き込む方法であって、
ネットワーク構成要素において、ファイルに対するＮＦＳ書き込み要求を受信するステップと、
上記ネットワーク構成要素により、どのＶＦＳが上記ファイルに関連付けられているかを決定するステップと、
上記ネットワーク構成要素から、上記ＶＦＳのストライプを有する複数のサーバの少なくとも１つのディスク構成要素へファイル書き込み要求を送信するステップと、
上記ファイルに関連付けられた現在の属性を取得するステップと、
上記データの予め決められたバイト数を、上記データがすべて上記ファイルに書き込まれるまで各ＶＦＳストリップへ連続して書き込むステップとを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のＮＦＳサーバによるストライピングを用いたデータの記憶に関する。より特定的には、本発明は、更新時刻（modification time）及び状態変更時刻（change time）を含む属性の範囲が考慮される、複数のＮＦＳサーバによるストライピングを用いたデータの記憶に関する。
【背景技術】
【０００２】
データ記憶における重要な課題は、高速ネットワークを介して接続された多数の独立したプロセッサを備えて構成される計算クラスタのための共有されたファイルアクセスを提供することである。いくつかの興味深い場合では、計算クラスタは単一のファイルにアクセスしようとするが、この場合、計算クラスタ全体からこの単一のファイルへの十分な帯域幅を提供することはかなり困難である。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
この課題に対するこれまでのアプローチは、２つのアーキテクチャのうちの一方に従っている。例えばシスティナ（Sistina）及びポリサーブ（PolyServe）が実装している１つのクラスのソリューションでは、単一のファイルへの帯域幅は、複数のサーバを提供することによってスケーリングされるが、このとき、これら複数のサーバは、上記ファイルを保持する論理記憶装置アレイ（ＬＵＮ）への当該複数のサーバによるアクセスを調節している。これらのシステムは、ＬＵＮへのアクセスを調節する複雑な分散型ロック方法を実行し、特に、ディスクブロックの割り当て、ファイルへのブロックの割り当て、ファイルへのｉノード（inode）番号の割り当て、及び間接的なブロックツリーの構築といった、複数の処理動作（オペレーション）を調節する。これらのシステムは、そのロック処理のオーバーヘッドが非常に高いので、典型的には効率が悪い。
【０００４】
ＰＶＦＳシステムに代表される別のクラスのソリューションでは、データは、通常のファイルシステムの上に構築される追加のファイルシステムの層を介して複数のサーバ間にわたってストライプ化される。ＰＶＦＳでは、最終的に生じるファイルシステムにおける様々なストリップファイルへの更新はさほど綿密には調節されず、また、ファイル長などのグローバルなファイル特性について対処する処理動作は、実装時にはなはだ手間又は費用がかかったり、あるいは近似値を用いて実装されたりするが、ここで近似値を用いた場合には、アプリケーションエラーを引き起こす可能性がある。例えばＰＶＦＳでは、ファイルの長さを決定するには、すべてのストリップから個々のファイル長を読み取り、返された最大の結果を採用することが必要であり、手間がかかる手順である。同様に、ネットワークファイルシステム（Network File System：ＮＦＳ）プロトコルを介してエクスポートされるデータを有するファイルシステムの場合は、正確な更新時刻が重要である。ここで、ＮＦＳプロトコルは、ファイルの更新時刻をバージョン番号として使用する。しかしながら、ＰＶＦＳや、それに類似した同様のファイルシステムは、ファイル長を返す手順に類似した手順を用いて、ファイルの更新時刻を返す。すなわちこれらは、すべてのサーバをチェックして、最大の更新時刻フィールドを返す。異なるサーバは少なくとも数マイクロ秒は相違したクロックを有するので、あるストライプを担当するサーバであって、たまたま最も進んだクロックを有するサーバにおいて書き込みが実行される可能性があり、次に、より古いクロックを有する別のサーバへの書き込みが実行されるが、その結果として第２の書き込みがシステム全体のファイル更新時刻を早めることはない。同じ更新時刻を有する２つのバージョンのファイルを有していることは、更新時刻をバージョン番号として使用するＮＦＳのようなプロトコルによる不正確な挙動を引き起こす可能性がある。これらの問題点に起因して、ＰＶＦＳファイルシステムは、ＮＦＳを用いたネットワーク上でのエクスポートには不適である。
【課題を解決するための手段】
【０００５】
本発明は、ＰＶＦＳのようなストライプ化されるソリューションの効率的なロック処理を、ＮＦＳによるデータのエクスポートに要求される正確かつ効率的なファイル属性検索と組み合わせるソリューションを提供するという点において、現行技術とは異なる。
【０００６】
本発明は、データ記憶のための装置に関する。本装置は、複数のＮＦＳサーバにてなるクラスタを備える。各サーバは、到来するファイルシステム要求とサーバ間のクラスタトラフィックとのための複数のネットワークポートを有する。本装置は、上記複数のサーバと通信する複数の記憶装置アレイを備える。上記複数のサーバは、ストライプ化されたファイルシステムを使用してデータを格納する。
【０００７】
本発明は、データ記憶のための方法に関する。本方法は、複数のＮＦＳサーバにわたってファイルを作成する（生成する）ステップを含む。複数のサーバにおける複数のデータストリップとしてデータをファイルへ書き込むステップが存在する。上記複数のストリップはともに、１つのストライプを形成する。また、上記複数のサーバから複数のデータストリップを読み出すステップと、上記複数のサーバから複数のストリップを削除するステップとが存在する。
【０００８】
本発明は、ファイルの記憶領域を確立する方法に関する。本方法は、あるネットワーク構成要素においてＮＦＳ作成要求を受信するステップを含む。また、メタデータサーバにおいて上記ネットワーク構成要素からファイル作成要求を受信するステップと、上記メタデータサーバにおいてファイルにｉノード番号を割り当てるステップと、複数の入出力セカンダリ装置（input output secondary）に対する複数の作成呼び出し（作成コール）を発生させて、上記複数の入出力セカンダリ装置によって割り当てられるファイルをマーキングするステップと、上記メタデータサーバにおいてファイル作成を実行するステップとが存在する。
【０００９】
本発明は、記憶領域からファイルを除去する方法に関する。本方法は、メタデータサーバにおいてファイル削除要求を受信するステップを含む。また、上記メタデータサーバにおいて、当該メタデータサーバにより親ディレクトリからファイルのファイル名を除去するステップと、上記メタデータサーバにおいて、当該メタデータサーバにより上記ファイル名をファイル削除リストに入れるステップと、上記入出力セカンダリ装置へ削除呼び出しを送るステップと、メタデータサーバにおいて、上記入出力セカンダリ装置がファイルを削除したという確認応答呼び出しを上記入出力セカンダリ装置から受信するステップと、上記メタデータサーバにおいてファイルを削除するステップと、上記ファイル削除リストからファイルを削除するステップと、上記メタデータサーバにおいて、上記ファイルに関連付けられたｉノード番号を上記メタデータサーバによりフリーリストに入れるステップとが存在する。
【００１０】
本発明は、ファイルにおけるデータを読み出す方法に関する。本方法は、ネットワーク構成要素において、ファイル内のデータに対するＮＦＳ読み出し要求を受信するステップを含む。また、上記データを含む少なくとも１つのストリップをどのＶＦＳが格納しているかをネットワーク構成要素により決定するステップと、上記ネットワーク構成要素から、上記データのストリップを格納する複数のサーバのうちの少なくとも１つのディスク構成要素へ、ファイル読み出し要求を送信するステップと、各ディスク構成要素により、上記ファイルに関連付けられた現在の属性を取得するステップと、上記ファイルの複数のストリップを、当該ストリップを有する各ディスク構成要素から読み出すステップと、上記ファイル読み出し要求に関連する応答を生成するステップとが存在する。
【００１１】
本発明は、ファイルにデータを書き込む方法に関する。本方法は、ネットワーク構成要素において、ファイルに対するＮＦＳ書き込み要求を受信するステップを含む。また、どのＶＦＳが上記ファイルに関連付けられるかを上記ネットワーク構成要素により決定するステップと、上記ネットワーク構成要素から、上記ＶＦＳのストライプを有する複数のサーバのうちの少なくとも１つのディスク構成要素へ、ファイル書き込み要求を送信するステップと、上記ファイルに関連付けられた現在の属性を取得するステップと、上記ファイルへすべてのデータが書き込まれるまで、予め決められたバイト数のデータを各ＶＦＳストリップへ連続して書き込むステップとが存在する。
【発明を実施するための最良の形態】
【００１２】
添付の図面に、本発明の好適な実施形態及び本発明を実施する好適な方法を示す。
【００１３】
次に、諸図面及び特にその各図を参照すると、データ記憶のための装置１０が示されている。ここで、同じ参照番号は、いくつかの図を通じて類似の部分又は同一の部分を示す。装置１０は、複数のＮＦＳサーバ１４にてなるクラスタ１２を備える。各サーバ１４は、到来するファイルシステム要求と、サーバ１４間のクラスタ１２におけるトラフィックとのための、複数のネットワークポート１６を有する。装置１０は、複数のサーバ１４と通信する複数の記憶装置アレイ１８を備え、複数のサーバ１４は、ストライプ化されたファイルシステムを使用してデータを格納する。
【００１４】
好適には、各サーバ１４は、ネットワーク構成要素２０とディスク構成要素２２とを有する。各ディスク構成要素２２は、好適には仮想ファイルシステム（virtual file system）２４を有し、各ディスク構成要素２２の仮想ファイルシステム２４はともに、ストライプ化されたＶＦＳを形成する。好適には、仮想ファイルシステム２４の１つのディスク構成要素２２は、メタデータサーバ２６として動作する。
【００１５】
好適には、１つのファイルは複数の属性を有し、各ファイルの各サーバ１４は、ファイルに係る既知の最新バージョンの属性と、書き込み処理動作の結果へ割り当てるための更新時刻及び状態変更時刻の値の範囲とを格納するキャッシュ構成要素を保持する。仮想ファイルシステム２４のためのメタデータサーバ２６ではない各ディスク構成要素２２は、好適には入出力セカンダリ装置である。好適には、ファイルの更新時刻又はファイルの状態変更時刻の範囲は、メタデータサーバ２６から入出力セカンダリ装置によって予約される。メタデータサーバ２６から取得される範囲内の更新時刻及び状態変更時刻は、好適には、入出力セカンダリ装置においてすでにキューイングされている（すなわち、待ち行列に入って待機させられている）処理動作に対して発行される。
【００１６】
好適には、メタデータサーバ２６から取得される範囲内の更新時刻及び状態変更時刻は、上記範囲がメタデータサーバ２６から入出力セカンダリ装置によって予約された後の時間ウィンドウの間に受信される処理動作に対して発行される。あるファイルのすべてのストライプに影響する処理動作は、好適には、まずメタデータサーバ２６においてあるファイルについて実行し始め、次にすべての入出力セカンダリ装置２８において実行する。よって、入出力セカンダリ装置２８における処理動作は、メタデータサーバ２６との通信をすでに終えているすでに実行中の処理動作のみを待機する。
【００１７】
好適には、処理動作は少なくとも２つのロック処理モデルのうちの一方に従う。その第１のモデルは、まずメタデータサーバ２６と同期化し、次に入出力セカンダリ装置で実行中である他の処理動作との同期化によりコア実行を開始するものであり、その第２のモデルは、まずメタデータサーバ２６において同期化し、次に入出力セカンダリ装置２８においてコア実行を開始している１つ又は複数の入出力セカンダリ装置２８における処理動作と同期化するというものである。クラスタ１２のネットワークは、好適にはスター型トポロジーで接続される。好適には、クラスタ１２のネットワークはスイッチドイーサネットである。
【００１８】
本発明は、データ記憶のための方法に関する。本方法は、複数のＮＦＳサーバ１４にわたってファイルを作成するステップを含む。複数のサーバ１４における複数のデータストリップとしてデータをファイルへ書き込むステップが存在する。これら複数のストリップはともに、１つのストライプを形成する。また、複数のサーバ１４から複数のデータストリップを読み出すステップと、複数のサーバ１４から複数のストリップを削除するステップとが存在する。
【００１９】
好適には、ＮＦＳサーバ１４の仮想ファイルシステム２４のためのディスク構成要素２２を、メタデータサーバ２６として識別し、メタデータサーバ２６として識別されない複数のＮＦＳサーバのための複数のディスク構成要素２２を複数の入出力セカンダリ装置２８として識別するステップが存在する。好適には、メタデータサーバ２６におけるアクティブな各ファイルのための各入出力セカンダリ装置におけるキャッシュ構成要素に、処理延期期間（dally period）において有効な上記ファイルに係る既知の最新バージョンの属性を格納するステップが存在する。好適には、書き込み処理動作へ割り当てるための更新時刻及び状態変更時刻の値の範囲をキャッシュ構成要素に格納するステップが存在する。
【００２０】
好適には、ファイルの現在の属性を取得するために、キャッシュ構成要素によりメタデータサーバ２６に対して状態要求を行うステップが存在する。好適には、上記状態要求を行うステップは、メタデータサーバ２６から更新時刻及び状態変更時刻の範囲を取得するステップを含む。好適には、ファイル読み出し要求及びファイル書き込み要求がキャッシュ構成要素により許可されて実行完了となるまで、入出力セカンダリ装置においてファイル読み出し要求及びファイル書き込み要求をキューイングするステップが存在する。
【００２１】
好適には、キャッシュ構成要素により実行されるステップであって、ファイルに関してどのファイル読み出し要求及びファイル書き込み要求が実行中であり、どの範囲が読み出し中又は書き込み中であるかを追跡するステップが存在する。好適には、読み出し処理動作が実行されなければならない場合に、キャッシュ構成要素の無効モードから読み出しモードへの移行を要求するステップが存在する。好適には、ファイル読み出し要求によって影響されるバイト範囲をチェックし、以前に許可されて現在実行中である任意のファイル書き込み要求のバイト範囲にそれが重複しないことを保証するステップが存在する。好適には、ファイル書き込み要求に応答して、キャッシュ構成要素が書き込みモードへ移行することを要求するステップが存在する。好適には、許可されかついまだ実行中の任意のファイル読み出し要求又はファイル書き込み要求との重複について、上記ファイル書き込み要求によって影響されるバイト範囲を上記キャッシュ構成要素によりチェックするステップが存在する。
【００２２】
好適には、書き込み要求の実行に際して、キャッシュ構成要素に格納されている更新時刻及び状態変更時刻の範囲から更新時刻及び状態変更時刻のペアを割り当てるステップが存在する。好適には、処理待機中（又は保留中）のファイル読み出し要求及びファイル書き込み要求のキューの先頭をチェックして、その先頭にあるものがファイル読み出し要求又はファイル書き込み要求のいずれかの完了後にキャッシュ構成要素により許可され得るか否かを確認するステップが存在する。好適には、ファイル書き込み要求に応答してファイル長が更新されなければならないことをキャッシュ構成要素により検出するステップと、キャッシュ構成要素を排他モードへ移行させるステップと、ファイルの長さ属性を更新するためにメタデータサーバ２６へファイル書き込み状態呼び出しを発生させるステップとが存在する。
【００２３】
本発明は、ファイルの記憶領域を確立する方法に関する。本方法は、ネットワーク構成要素２０においてＮＦＳ作成要求を受信するステップを含む。また、メタデータサーバ２６においてネットワーク構成要素２０からファイル作成要求を受信するステップと、メタデータサーバ２６において、ファイルのためのｉノード番号を割り当てるステップと、複数の入出力セカンダリ装置２８に対する複数の作成呼び出しを発生させて、これら複数の入出力セカンダリ装置２８によって割り当てられるファイルをマーキングするステップと、メタデータサーバ２６においてファイルの作成を実行するステップとが存在する。
【００２４】
本発明は、記憶領域からファイルを除去する方法に関する。本方法は、メタデータサーバ２６においてファイル削除要求を受信するステップを含む。また、メタデータサーバ２６において、当該メタデータサーバ２６により親ディレクトリからファイルのファイル名を除去するステップと、メタデータサーバ２６において、当該メタデータサーバ２６によりファイルをファイル削除リストへ入れるステップと、複数の入出力セカンダリ装置２８へ複数の削除呼び出しを送信するステップと、メタデータサーバ２６において、ファイルを削除したという確認応答呼び出しを複数の入出力セカンダリ装置２８から受信するステップと、メタデータサーバ２６においてファイルを除去するステップと、ファイル削除リストからファイルを削除するステップと、メタデータサーバ２６において、上記ファイルに関連付けられたｉノード番号をメタデータサーバ２６によりフリーリストに入れるステップとが存在する。
【００２５】
本発明は、ファイルにおけるデータを読み出す方法に関する。本方法は、ネットワーク構成要素２０において、ファイル内のデータに対するＮＦＳ読み出し要求を受信するステップを含む。また、ネットワーク構成要素２０により、上記データを含む少なくとも１つのストリップをどのＶＦＳが格納しているかを決定するステップと、ネットワーク構成要素２０から、上記データのストリップを格納している複数のサーバ１４の少なくとも１つのディスク構成要素２２へ、ファイル読み出し要求を送信するステップと、各ディスク構成要素２２により、上記ファイルに関連付けられた複数の現在の属性を取得するステップと、上記ファイルの複数のストリップを、当該ストリップを有する各ディスク構成要素２２から読み出すステップと、上記ファイル読み出し要求に関連する応答を生成するステップとが存在する。
【００２６】
本発明は、ファイルにデータを書き込む方法に関する。本方法は、ネットワーク構成要素２０において、ファイルのためのＮＦＳ書き込み要求を受信するステップを含む。また、ネットワーク構成要素２０により、どのＶＦＳが上記ファイルに関連付けられるかを決定するステップと、ネットワーク構成要素２０から、ＶＦＳの複数のストライプを有する複数のサーバ１４の少なくとも１つのディスク構成要素２２へ、ファイル書き込み要求を送信するステップと、上記ファイルに関連付けられた複数の現在の属性を取得するステップと、上記データの予め決められたバイト数を、上記データがすべてファイルに書き込まれるまで各ＶＦＳストリップへ連続して書き込むステップとが存在する。
【００２７】
実施に際しては、本発明はスピンサーバ（ＳｐｉｎＳｅｒｖｅｒ）の上部に実装される。スピンサーバの基本アーキテクチャは、国際出願番号ＰＣＴ／ＵＳ０１／４６７９２号の明細書に記載され、その内容は参照によりここに含まれている。ただし、この場合、単一のグローバルな名前空間が、複数のネットワーク構成要素（ＮＥ）２０と複数のディスク構成要素（ＤＥ）２２との集合物によって実装される。
【００２８】
好適な実施形態では、単一のＮＥとＤＥとが組み合わされてサーバ１４となり、このサーバ１４が、前述のように、到来するファイルシステム要求のための複数のネットワークポート１６と、スピンサーバ間のクラスタ１２トラフィックのための他の複数のネットワークポート１６との双方を有している。図２において、図２の上部のリンクは、複数のスピンサーバと、それらに接続された複数の記憶装置アレイ１８との間のファイバチャネルリンクを表す。水平に伸びる黒い線は、異なるスピンサーバのＮＥ構成要素及びＤＥ構成要素をともに接続する専用のクラスタ１２ネットワークを表す。ただし、図２では、クラスタ１２のリンクはスピンサーバ２を通過してスピンサーバ３に到達するようになっているが、実際には、クラスタ１２ネットワークはスイッチドギガビットイーサネットであり、複数のマシンはスター型トポロジーで接続されることに留意されたい。
【００２９】
上述のように構成されるシステムを想定すると、複数のＤＥから単一のＶＦＳであるかのように見えるものへの帯域幅を提供する方法として、データは複数のＶＦＳ間でストライプ化される。
【００３０】
ＶＦＳ内のデータは、国際出願番号ＰＣＴ／ＵＳ０１／４８７４１号の明細書に記載され、参照によりここに含まれた、複数のｉノードにてなるアレイとして実装されるか、又は、バークレー高速ファイルシステムに実装されているような方法で実装される。バークレー高速ファイルシステムの設計及びフル実装は、ｈｔｔｐ：／／ｗｗｗ．ｆｒｅｅｂｓｄ．ｏｒｇで入手可能であり、参照によりここに含まれている。
【００３１】
ストライプ化されたＶＦＳは、ＮＦＳ名前空間においては単一のＶＦＳとして現れるが、内部的には、いくつかのＤＥ間において、ＤＥ毎に１つのＶＦＳが存在するように分散された複数のストリップＶＦＳにてなる集合から構成される。この集合物を、ストライプ化されたＶＦＳ又はストライプ化された集合と呼ぶ。ＶＦＳのうちの１つに係る１つのサーバ１４は、メタデータサーバ２６又はＭＤＳとして識別される。次にデータは、複数のＶＦＳにてなる集合物全体にわたって、以下のように分散される。ストライプ化されたＶＦＳにおけるすべてのファイルがＭＤＳにおいて表示され、正規のデータファイルを除くすべてのファイルについて、ＭＤＳはそのオブジェクトのための全データを格納する。従って、特に、すべてのディレクトリ、シンボリックリンク、マウントポイントが、ＭＤＳにおいて完全に格納される。
【００３２】
複数のデータファイルは、異なる方法で処理される。ファイルのデータに係る異なるストリップを、ストライプ化された集合における異なるＶＦＳに配置し、ストライプ化された各ＶＦＳ内ですべてに同じｖノード（vnode）番号を共有させることにより、データファイルは、ストライプ化された集合におけるすべてのＶＦＳ間にわたってストライプ化される。例えば、ＶＦＳ  ＩＤとしてＡを有し、そのＶＦＳ内のｖノードとしてＢを有し、一意的な生成番号としてＣを有するファイルをＡ．Ｂ．Ｃと表すとき、ストライプ化されたＶＦＳ  ＡがＶＦＳ  Ａ１、Ａ２及びＡ３で構成されていれば、ファイルＡ．Ｂ．Ｃの様々なストライプは、ファイルＩＤとしてＡ１．Ｂ．Ｃ、Ａ２．Ｂ．Ｃ及びＡ３．Ｂ．Ｃを有するファイルに格納される。すなわち、ｖノードとしてＢを有するストライプ化されたＶＦＳにおけるファイルは、各構成要素ＶＦＳ内に同じｖノードと一意的なフィールドとを有するファイルにおけるすべての構成要素ＶＦＳ内にそのデータを格納させる。ｖノードＢのストリップＮは、ストライプ集合におけるＩ番目のサーバ１４上に格納される。ここで、次式が成り立つ。
【００３３】
［数１］
Ｉ＝（Ｂ＋Ｎ）  ｍｏｄ  ＳＴＲＩＰＥ＿ＷＩＤＴＨ
【００３４】
ＳＴＲＩＰＥ＿ＷＩＤＴＨは、ストライプ化されたＶＦＳを保持するすべての記憶装置アレイ１８にわたるストライプ全体におけるストリップの数である。
【００３５】
図３は、３つの個別のＶＦＳであるＡ１、Ａ２及びＡ３から作成される、ストライプ化された仮想ファイルシステム２４（ＶＦＳ  Ａ）におけるファイルを示す。このファイルのｖノード番号はＢであり、その一意的なフィールドはＣである。連結されたファイルのストリップ０はファイルＡ２．Ｂ．Ｃの第１のストリップに格納され、ストリップ１はファイルＡ３．Ｂ．Ｃのストリップ０に格納され、ストリップ２はファイルＡ１．Ｂ．Ｃのストリップ０として格納され、連結されたファイルのストリップ３はファイルＡ２．Ｂ．Ｃへ戻るが、今回はファイルのストリップ１として戻る。
【００３６】
データは、図３に示すように、各サーバ１４上にＸバイトが存在し、そして次のＸバイトのために次のサーバ１４へ移動し、これを何度も繰り返すことによってストライプ化される。ストリップのサイズはＸであり、ストライプのサイズはＸ×＜サーバ数＞である。すなわち、各サーバ１４上へ３２ＫＢが書き込まれ、次のものへ移動し、クラスタ１２に参加しているサーバが８つある場合、ストリップのサイズは３２Ｋであり、ストライプのサイズは１２８Ｋになる。
【００３７】
ファイルシステムの処理動作の大部分はＭＤＳ上で実行され、ＭＤＳは単独で、属性の検索、ディレクトリの参照（ルックアップ）、シンボリックリンクの読み出し、ディレクトリの読み出し、アクセスチェック、属性の設定（ファイル長の変更を除く）、ディレクトリの作成、ディレクトリの除去、ファイル及びディレクトリの名前変更、ロック処理、ハードリンクの作成、シンボリックリンクの作成、及びアクセス制御リストの設定といった各処理動作を実行する。
【００３８】
いくつかの他の処理動作は、主として単一のストリップに影響するが、このストリップによる要求処理は、ＭＤＳとの通信を要求してもよい。これには、読み出し及び書き込み双方の処理動作が含まれる。最終的に、通常のファイル作成、ファイル除去、及びファイル長の更新はすべて、ストライプ集合におけるすべてのファイルに影響する。以下、これらの処理動作について詳述する。
【００３９】
ｓｐｉｎ＿ｒｅａｄ（スピン読み出し）及びｓｐｉｎ＿ｗｒｉｔｅ（スピン書き込み）を除くすべての基本的なデータ処理動作は、ＭＤＳにおいて処理される。ｓｐｉｎ＿ｒｅａｄ及びｓｐｉｎ＿ｗｒｉｔｅに対する呼び出しは、適切なファイルのストリップを保持する適切なＤＥに向けて、ＮＥによって送信される。先に述べたように、このストリップは、ファイルのｖノード番号と組み合わされてデータファイル内の相対ストリップの関数として計算され、よってストライピングは、ストライプ化されたＶＦＳ内の異なるファイルのための異なるサーバで開始される。特定の要求は、ｓｐｉｎ＿ｒｅａｄ又はｓｐｉｎ＿ｗｒｉｔｅ等の、好適な実施形態の命名法と矛盾せずに識別されることは留意されるべきである。これらの要求は、読み出し要求、書き込み要求又は状態要求等の、それに関連付けられたより一般的な要求を代表している。
【００４０】
ＮＦＳ読み出しがＮＥによって受信されると、ＮＥは、読み出されているデータを含む１つ又は複数のストリップを格納する実ＶＦＳを計算し、次いでＮＥは、上記データを格納する（１つ又は複数の）ＤＥへ読み出し要求を送信する。要求を実行することの一部として、ＤＥはファイルに関連付けられた複数の属性を要求し、キャッシュされた最新の情報を使用するか、又はその時点でＭＤＳからこれを取得する。この情報はファイル長の決定に使用され、このファイル長はさらに、ファイル読み出しをトリミングするために使用される。またこれは、ファイル属性を決定してｓｐｉｎ＿ｒｅａｄの呼び出しの発生側へ返すためにも使用される。
【００４１】
図４は、これがどのように動作するのかを示す。ＮＦＳ読み出し要求は左側からＮＥへ入り、対応するストライプのための対応するｓｐｉｎ＿ｒｅａｄ要求へマッピングされる。ここで、対応するストライプは、上から２番目のＩＯＳ上へ格納されている。このＩＯＳに格納されているキャッシュ属性が現在の属性であれば、読み出し処理動作が即時に実行され、応答が生成される。そうでなければ、ｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ（スピンｍｄｓ読み出し状態）呼び出しがメタデータサーバ（ＭＤＳ）２６へ送られ、ファイルに係る現在の属性が検索される。書き込み要求の場合も同じ経路が使用され、ＮＦＳ書き込み要求がＮＥへ入ると、ｓｐｉｎ＿ｗｒｉｔｅ呼び出しに変換され、キャッシュ構成要素が上記要求を即時に処理することができなければ、ＩＯＳはＭＤＳに対してｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ（スピンｍｄｓ書き込み状態）により呼び出しを発生する。さらに、書き込みの場合、ファイル長が更新されれば、書き込み呼び出しのｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しが、ＭＤＳにおいてファイル長を更新する。
【００４２】
書き込みは、書き込み処理動作の実行に必要とされるデータを保持する１つ又は複数のサーバ１４を決定することに関して、読み出し処理動作と同様に実行される。ｓｐｉｎ＿ｗｒｉｔｅ処理動作はまた、ＤＥによって処理される場合は、ＭＤＳに格納されているファイル属性を更新することが必要になる。この更新は、ＩＯＳからＭＤＳへ要求を送ることによって処理されるが、ＩＯＳは、以下に説明する最適化により、ＭＤＳへの単一の状態更新呼び出しを使用して２つ以上のｓｐｉｎ＿ｗｒｉｔｅ処理動作を処理することができる。
【００４３】
ＩＯＳがＭＤＳに対して実行することができる呼び出しは、２つ存在する。ｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ処理動作は、現在のファイル属性を返す。ｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ処理動作は、現在ファイルの属性とともに、ＩＯＳ自体が割り当てることのできるｍｔｉｍｅ及びｃｔｉｍｅの値の範囲を返す。ｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しは、更新された属性を返す前にファイルへ書き込むオプションの属性を取得する場合もある。このオプションは、典型的には、ＩＯＳにおけるｓｐｉｎ＿ｗｒｉｔｅ呼び出しがファイル長の更新を実際に必要とする場合において、ファイル長を更新するために使用される。
【００４４】
各ＩＯＳは、ＭＤＳにおけるアクティブファイルの各々について、ファイルに係る既知の最新バージョンの属性を格納するとともに、書き込み処理動作へ割り当てるためのｍｔｉｍｅ及びｃｔｉｍｅの値のオプションの範囲を格納するキャッシュ構成要素を保持する。ＩＯＳにおいて、このキャッシュ構成要素は、キューイングされている読み出し及び書き込み処理動作（ｓｐｉｎ＿ｒｅａｄ呼び出し及びｓｐｉｎ＿ｗｒｉｔｅ呼び出し）を下記のように処理する。ファイル属性はキャッシュされ、ＭＤＳから取得された後の処理延期期間と呼ばれる一定の（短い）期間にわたり有効とされる。キャッシュ構成要素が読み出しモードであれば、これはファイル属性をキャッシュしているが、書き込みに使用されるｍｔｉｍｅ及びｃｔｉｍｅの範囲はキャッシュしていない。キャッシュ構成要素が書き込みモードであれば、これは読み出しモードと同様にファイル属性をキャッシュし、さらには書き込み処理動作に使用するｍｔｉｍｅ及びｃｔｉｍｅの値の範囲もキャッシュしている。古くて使用できない情報をキャッシュしている構成要素は、無効モードにある。キャッシュ構成要素は、ｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出しを発生させてＭＤＳから最新の属性を取得することにより、無効モードから読み出しモードへ移行する。無効又は読み出しモードのいずれかにあるキャッシュ構成要素は、ｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しを発生させて現在の属性とｍｔｉｍｅ及びｃｔｉｍｅの範囲とを取得することにより、書き込みモードへ移行することができる。
【００４５】
ｍｔｉｍｅはファイルの更新時刻であり、これは、ファイル内のデータが最後に修正された時刻を意味する。ｃｔｉｍｅはファイルの状態変更時刻であり、これは、そのデータを含むファイルの任意のプロパティが変化すると進む。よって、ファイルへの書き込みを行う場合は、そのｍｔｉｍｅ及びｃｔｉｍｅの双方が変化するが、ファイルに対してそのプロテクト又はファイル所有者の変更のような処理動作を行う場合は、ｃｔｉｍｅのみが変化する。ｃｔｉｍｅはｍｔｉｍｅが変化すれば必ず変化するが、ｍｔｉｍｅはｃｔｉｍｅが変化する毎に変化するわけではない。
【００４６】
ＩＯＳにおけるｓｐｉｎ＿ｒｅａｄ呼び出し及びｓｐｉｎ＿ｗｒｉｔｅ呼び出しはすべて、ＩＯＳにおける実行が可能になる前にキャッシュ構成要素への許可を得なければならない。これらの呼び出しは、許可を得るまでは、キャッシュ構成要素においてキューイングされる。キャッシュ構成要素は、対応するファイルに関してどのｓｐｉｎ＿ｒｅａｄ又はｓｐｉｎ＿ｗｒｉｔｅ処理動作が実行中であるか、及び上記処理動作がどの範囲について読み出し又は書き込みを行っているかを追跡する。上記構成要素が無効モードにある場合、キューイングされているｓｐｉｎ＿ｒｅａｄ呼び出しは最初に、キャッシュ構成要素が無効モードから読み出しモードへ移行することを要求する。上記構成要素が読み出しモード又は書き込みモードのいずれかにあれば、ｓｐｉｎ＿ｒｅａｄ呼び出しによって影響されるバイト範囲が、以前に許可されていてその時点で実行中である任意のｓｐｉｎ＿ｗｒｉｔｅ呼び出しのバイト範囲に重複しないことを保証するためにチェックされる。この条件もパスすれば、ｓｐｉｎ＿ｒｅａｄ呼び出しは許可され、キャッシュ構成要素にその時点で格納されている属性に対する処理が完了する。キューイングされているｓｐｉｎ＿ｗｒｉｔｅ呼び出しは、キャッシュ構成要素が書き込みモードへ移行することを要求する。次にこれは、ｓｐｉｎ＿ｗｒｉｔｅ呼び出しによって影響されるバイト範囲を、許可されかついまだ実行中である任意のｓｐｉｎ＿ｒｅａｄ呼び出し又はｓｐｉｎ＿ｗｒｉｔｅ呼び出しとの重複についてチェックする。競合する呼び出しが存在しなければ、ｓｐｉｎ＿ｗｒｉｔｅ呼び出しが許可されて、キャッシュ構成要素に格納されている範囲からｍｔｉｍｅ／ｃｔｉｍｅのペアが割り当てられ、ｓｐｉｎ＿ｗｒｉｔｅがローカルに実行される。ｓｐｉｎ＿ｗｒｉｔｅ呼び出しが完了すると、割り当てられたｍｔｉｍｅ／ｃｔｉｍｅのペアを用いて応答が送られる。ｓｐｉｎ＿ｒｅａｄ呼び出し又はｓｐｉｎ＿ｗｒｉｔｅ呼び出しのいずれかが完了するときは常に、処理待機中のｓｐｉｎ＿ｒｅａｄ要求及びｓｐｉｎ＿ｗｒｉｔｅ要求のキューの先頭がチェックされて、それが許可されてもよいか否かが確認され、その時点で実行中のｓｐｉｎ＿ｒｅａｄ呼び出し及びｓｐｉｎ＿ｗｒｉｔｅ呼び出しの集合に競合する呼び出しに遭遇するまでは、新たな呼び出しが許可される。
【００４７】
キャッシュ構成要素への許可を受けている書き込み呼び出しは、ファイル長も更新しなければならないことを検出する場合がある。この場合、キャッシュ構成要素は排他モードへ移行され、このモードでは、ｓｐｉｎ＿ｗｒｉｔｅ処理動作が進行できるようになる前に他のすべての処理動作が完了することが要求される。すべての処理動作の完了後、ファイル長属性を更新するｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しが発生され、新たなｍｔｉｍｅ及びｃｔｉｍｅの値の範囲が返され、書き込み処理動作が進行する。
【００４８】
図５は、ストライプ化されたシステムにおいてｓｐｉｎ＿ｗｒｉｔｅ処理動作の実行することの一部として交換される複数の呼び出しを示す。この例では、３つのＮＦＳ書き込み呼び出しが１つのＮＥへ到来し、ＮＥは対応する３つのｓｐｉｎ＿ｗｒｉｔｅ呼び出しを１つのＩＯＳへ送る。ＩＯＳのキャッシュ構成要素は書き込みモードにはなく、よってこれはｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しをＭＤＳに対して発生させて上記構成要素を書き込みモードにする。この間、ＩＯＳへの他のｓｐｉｎ＿ｗｒｉｔｅ呼び出しは、キャッシュ構成要素が書き込みモードへ移行することを待機するようにキューイングされる。
【００４９】
ネットワーク構成要素２０への所定の読み出し呼び出し及び書き込み呼び出しは、ファイルシステム内のストリップの境界を横断する。このことは、典型的には、偶然にストリップの境界にわたることになる大規模なＮＦＳ読み出し又は書き込み呼び出しにおいて発生する。この場合、様々なディスク構成要素２２への複数のスピンＦＳ（ＳｐｉｎＦＳ）呼び出しの結果は、ＮＥが適切なＮＦＳ応答を発生できるようになる前に連結される。図６に、この場合を示す。
【００５０】
これらの場合に使用可能な２つのアプローチが存在する。第１のアプローチでは、影響される各ストリップにつき１つ存在する、２つ以上のＤＥ  ｓｐｉｎ＿ｒｅａｄ又はｓｐｉｎ＿ｗｒｉｔｅ処理動作が実行され、結果は、クライアント装置へ返される前に連結される。複数の属性似てなる複数の集合を組み合わせるために使用される処理動作は、最古の（最小の）ｃｔｉｍｅフィールドを有する状態エントリに関連付けられた属性を返すことである。第２のアプローチでは、ＮＦＳｖ３及びＮＦＳｖ４処理動作は短い読み出し又は書き込み処理動作を実行できるという事実が利用され、上記読み出し又は書き込み処理動作のうちで、影響される第１のストリップ内に適合する部分のみが実行され、データの部分集合のみが転送されているという指示情報がＮＥからＮＦＳクライアント装置へ返される。この場合、クライアント装置は残りのデータに関して別の要求を送信することが知られている。
【００５１】
好適な実施形態では、実際には、基礎となるアクセスプロトコルに依存してハイブリッド型のアプローチが使用される。特に、要求されたものより少ないバイト数での読み出し又は書き込みをサーバ１４に実行させるプロトコルであって、残りのバイトに関して新たな転送を要求する責任を記憶装置のクライアント装置が有するプロトコルに対しては、サーバ１４は上述の第２のアプローチを実施する。各呼び出しについて全バイトが転送されることを要求する残りのプロトコルに対しては、第１のアプローチが使用される。可能であれば短い読み出し及び書き込みを使用することは、記憶装置の複数のクライアント装置がそれらのキャッシュの各ページにおける的確なバージョンのデータをより正確に追跡することを可能にし、よって記憶装置のクライアント装置における不必要なキャッシュ無効処理動作を防止する。
【００５２】
ＭＤＳでは、２つのクラスの処理動作が実行される。ただし、これらの処理動作はシステム内の複数のＩＯＳにも影響を与える。一方のクラスは、ファイルの作成及び削除処理動作を含み、第２のクラスはファイルの切り詰めを含む。以下、双方のクラスについて説明する。
【００５３】
マルチストリップ処理動作はＭＤＳへと方向づけられ、ＭＤＳは処理動作に関連する様々なＩＯＳへ要求を送出する。このシステムにおける他のすべての処理動作の場合と同様に、これらはそれらのファイルのｃｔｉｍｅの値によって直列に順序付けられる。図７を見れば、これらの処理動作がシステムをたどる際の経路が分かる。図７において、ＮＦＳ作成要求はＮＥによって受信され、ＮＥはこれをｓｐｉｎ＿ｃｒｅａｔｅ（スピン作成）呼び出しに変換し、これがＭＤＳ（右端のボックス）へ転送される。ＭＤＳは、問題となっている複数のＶＦＳストリップを格納するすべてのＩＯＳに対していくつかのｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ（スピンｉｏｓ作成）処理動作を発行することによって、上記処理動作を実行する。図面では後述のように、ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しは、この処理動作に関連する他の呼び出しとは逆に、右から左へ移動することに留意されたい。
【００５４】
ファイル作成及び削除処理動作は複数のストリップに影響し、ＭＤＳへ直接送られる。ＭＤＳは、その処理を下記のように実行する。
【００５５】
ファイル作成は、非常に明快かつ簡単である。ストライプ化されたＶＦＳの場合、実際に作成を行う前に、使用されるｉノード番号が予約され、複数のｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しが複数のＩＯＳに対して発生される。ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しは、指定されたファイルにデータが残っていないことと、ファイルのｉノードが、ＭＤＳに格納されているものと同じ一意的なフィールドをＩＯＳ上に有することと、ファイルのファイルタイプフィールドが、上記ファイルが正規なファイルであると示していることとを保証する。ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しは、ｉノード割り当てを割り当てるトランザクションをＭＤＳが行う前に実行され、よって、各ＩＯＳにおいてｉノードが作成される前にクラッシュした場合、ＭＤＳでは何の変更も行われず、ファイルの割り当ては結局はスクラッチから開始する。
【００５６】
任意のサイトにおいてクラッシュした場合、ファイル作成は、任意のファイルのエントリが作成される前に、かつ任意のｉノードがＭＤＳにおける割り当ての通りにマーキングされる前に、失敗することになる。従って、ファイル作成における失敗した試行によってリソースが失われることなく、作成の再試行が継続される。また、作成されるファイルが最終的に可視になり、ＭＤＳにおいてディレクトリのエントリが作成されかつｉノードがロックされていない状態になるまでに、ファイルはＭＤＳ及びすべてのＩＯＳ上において作成されていることにも留意されたい。従って、ＭＤＳ又はＩＯＳがクラッシュした場合でも、部分的に作成されたストライプ化されたファイルが可視であるようなウィンドウは存在しない。
【００５７】
削除は作成の場合と同じルールに従い、ディレクトリのエントリを破壊して正規ファイルのｉノードを解放するトランザクション更新がファイル削除処理動作の最終段階として実行されることを保証する。すなわち、ファイル削除は、遠隔の複数のＶＦＳのそれぞれへｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ（スピンｉｏｓ削除）呼び出しを送ることによって開始される（これらのＶＦＳがｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ呼び出しを並列に実行する）。これらの呼び出しが完了すると、ＭＤＳにおけるストリップはトランザクションにおいて除去され、ファイルは消滅する。
【００５８】
ファイル作成においては発生しないがファイル削除では発生する１つの厄介な問題点は、処理動作の開始時にすでにファイルが存在することに起因して、削除中において、読み出し又は書き込み処理動作を実行する者にとって削除の間の中間状態が可視になることである。典型的にはこのことは、削除中において読み出し又は書き込み処理動作が、単にブロックして次にＥＳＴＡＬＥを返す代わりに、削除中にＥＳＴＡＬＥを返してもよいことを意味する。このこと自体は本来は問題ではないが、ＭＤＳがこのフェーズの間にクラッシュすれば、復元されたとき、ストリップのうちの一部が削除されているように見え、このバイト範囲の読み出し時にＥＳＴＡＬＥが返される一方、他のものは引き続き機能するようになる。新たなファイル削除処理動作は継続されるが、このファイルの全体的な状態はユーザを混乱させることになる。
【００５９】
従って、ファイル削除処理動作を開始する前において、削除処理中のオブジェクトにてなるリストに上記ファイルを追加しかつこれをその親ディレクトリから除去するトランザクションが行われる。システムは次に、ｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ呼び出しをすべてのＩＯＳへ送り、最後に、ＭＤＳと削除されているファイルのリストとから上記ファイルを除去する第２のトランザクションを実行する。ファイルは、ｓｐｉｎ＿ｒｅｍｏｖｅ（スピン除去）呼び出しが少しでも変更を行う前に、安定した記憶領域に「削除されるべきもの」として記録されるので、いつか除去が開始されるときに上記ファイルは最終的に削除されることが保証される。従って、削除処理中のファイルへのアクセスに起因するＥＳＴＡＬＥエラーはどれも短命であり、ファイルがその親ディレクトリにおいて不可視になった後にのみ発生する。
【００６０】
ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出し及びｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ呼び出しは、関連ファイルのためのＩＯＳ上のキャッシュ構成要素が排他モードにあることを要求する。効果的には、このことは、これらの処理動作が、ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ又はｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅをＩＯＳにおいて実行可能になるまで、このファイルに関して許可されたすべての処理動作が完了するのを待機することを意味する。
【００６１】
ファイルの切り詰めは、ファイル削除と同様に、ＭＤＳと様々なＩＯＳとの双方で実行される。切り詰めは、複数のＩＯＳにおける他の複数の処理動作に関して直列に順序付けられることが望ましい。特に、切り詰めが、ｍｔｉｍｅとして２００で復帰し、書き込みが、ｍｔｉｍｅとして１９９を返すＩＯＳにおいて実行されれば、そのＩＯＳにおいて書き込まれるデータはまた、この切り詰めの効果を反映するはずである。これに対して、ｍｔｉｍｅとして２０１を返す書き込みが実行されても、その書き込みが切り詰めに影響されるようには見えない。
【００６２】
このことは、ＭＤＳにおいてファイルの作成及び削除処理動作が直列に順序付けられるのと同じ方法で、ＭＤＳにおいて複数の切り詰めを直列に順序付けすることにより達成される。特に、ｓｐｉｎ＿ｓｅｔａｔｔｒがＭＤＳにおいて実行され、その実行持続時間にわたって、到来するｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出し及びｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しがブロックされる。この時間の間、それはＭＤＳにおいて切り詰め処理動作を実行し、すべてのＩＯＳへｓｐｉｎ＿ｉｏｓ＿ｔｒｕｎｃａｔｅ（スピンｉｏｓ切り詰め）処理動作を送る。ｓｐｉｎ＿ｉｏｓ＿ｔｒｕｎｃａｔｅ処理動作は、実際に、ＩＯＳにおいて切り詰め処理動作を実行する。
【００６３】
ＩＯＳは、ｓｐｉｎ＿ｉｏｓ＿ｔｒｕｎｃａｔｅ処理動作を下記のようにして処理する。まず、ＩＯＳにおいてすでに許可されているすべての処理動作が完了する。これらの処理動作は、ＭＤＳからすでに取得されているｍｔｉｍｅ及びｃｔｉｍｅの値に基づいて実行され、切り詰め処理動作より前に直列に順序付けられる。次に、切り詰め処理動作が実行される。ｓｐｉｎ＿ｉｏｓ＿ｔｒｕｎｃａｔｅ呼び出しのパラメータには、切り詰められているファイルのファイルＩＤと、その新たな長さとが含まれ、切り詰めが実行された後のファイルの属性は、更新されたｍｔｉｍｅフィールド及びｃｔｉｍｅフィールドを含む。切り詰め処理動作を実行した後、キャッシュのエントリは読み出しモードになり、キャッシュのエントリの状態変更のためにキューイングされているＩＯＳにおける追加処理動作が実行可能になる。
【００６４】
この設計では、複数のＤＥ構成要素内のスレッドリソースのデッドロックを回避する目的で、ＩＯＳ及びＭＤＳの各々に到来する要求を処理するための、スレッドの２つの追加プールが予約される。
【００６５】
任意のシステムは、同時に（異なる複数の仮想ファイルシステム２４のための）ＭＤＳ及びＩＯＳの双方であってもよいので、複数のＩＯＳから複数のＭＤＳへ送られる少なくとも１つの要求が実行可能であることを保証し、かつ複数のＭＤＳから複数のＩＯＳへの少なくとも１つの要求が実行可能であることを保証するのに十分なスレッドリソースが予約される。特に、到来するｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出し及びｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しを処理しかつこれらの呼び出しのみを処理するために少なくとも１つのスレッドが予約され、ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出し、ｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ呼び出し及びｓｐｉｎ＿ｉｏｓ＿ｔｒｕｎｃａｔｅ呼び出しを処理しかつこれらの呼び出しのみを処理するもう１つのスレッドが予約される。
【００６６】
以下のセクションでは、上述のストライプ化されたシステムの処理動作のウォークスルー例について記述する。
【００６７】
本例はファイル作成に始まり、いくつかのストライプ化された書き込みと、いくつかのストライプ化された読み出しとがこれに続き、ファイル削除で終わる。
【００６８】
最初のファイル作成はＭＤＳにおいて開始され、新たなファイルのためのｖノード番号を割り当てることによって開始される。ＭＤＳは次に、ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しをすべてのＩＯＳに対して同時に発生させ、ファイルを、すべてのＩＯＳ上へ割り当てられた通りにマーキングする。ｓｐｉｎ＿ｉｏｓ＿ｃｒｅａｔｅ呼び出しが完了すると、ＭＤＳにおいてファイルを実際に作成するＭＤＳでのトランザクションが行われ、これらの変更は永続的なものとなる。
【００６９】
ファイルを作成した後、複数のマシンがそのファイルへの書き込みを行うことができる。具体的には、３つのサーバＩ０、Ｉ１及びＩ２が存在し、Ｉ０はファイルのためのメタデータサーバ２６であることを想定し、クライアント装置Ｃ０及びＣ１がファイルへの書き込みを行っているものとする。時間は６４ビット量で表現し、１９７０年１月１日以降のナノ秒数を示す。ファイルが作成された時点では、そのｍｔｉｍｅ及びｃｔｉｍｅの値は同じであり、例えば１００００００である。次いで、Ｃ０が、Ｉ１に格納されているストリップに対する５０個のｓｐｉｎ＿ｗｒｉｔｅ呼び出しを行うものとする。Ｉ１はまず書き込みモードへ移行し、Ｉ０からｍｔｉｍｅ及びｃｔｉｍｅの値の範囲を受信する。この場合、書き込みがＩ１に到達する時点の現在時刻は２００００００であり、よってＭＤＳは、Ｉ１のためのｍｔｉｍｅ及びｃｔｉｍｅの範囲が２００００００乃至２０００９９９であることを指定することにより、Ｉ１に対して、そのｍｔｉｍｅ及びｃｔｉｍｅの範囲の値１０００を与えるものとする。次に、ＭＤＳは、ファイルのｍｔｉｍｅ及びｃｔｉｍｅを２００１０００に設定する。５０個の書き込みには、ｍｔｉｍｅ及びｃｔｉｍｅにてなる５０個の別個のペアが割り当てられ、このペアはｍｔｉｍｅ及びｃｔｉｍｅともに２００００００から始まってｍｔｉｍｅ及びｃｔｉｍｅともに２００００４９で終わる。これらの書き込みを処理する間、Ｃ０及びＣ１は、Ｉ２に格納されている１つ又は複数のストリップに対する別の５０個の書き込みを送ることもできる。Ｉ２は、ＩＯＳとして、同様に書き込みモードへ移行しなければならず、ｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しを発生させてその固有のｍｔｉｍｅ及びｃｔｉｍｅの値にてなる集合を取得することにより、これを行う。ＭＤＳは、Ｉ１を書き込みモードに移行させた時点でタイムスタンプを２００１０００へ進めているので、Ｉ２へ返される範囲は２００１０００乃至２００１９９９である。次にＩ２において５０個の書き込みが実行され、Ｉ２により２００１０００乃至２００１０４９のｍｔｉｍｅ及びｃｔｉｍｅの値が与えられる。ここで、Ｉ１及びＩ２上では、Ｉ０への２つの簡単なＲＰＣを利用するだけで、１００個の書き込み処理動作が実行されたということに留意されたい。
【００７０】
次に、クライアント装置Ｃ０及びＣ１からＩＯＳ  Ｉ１へ５０個の読み出し処理動作が送られることを想定する。上記集合のうちの最初の読み出しがＩ１へ到達したとき、ＩＯＳが書き込みモードであり続けることができる最大時間は満了していて、ＩＯＳはアイドル状態に戻っているということが発見されるものとする。ｓｐｉｎ＿ｒｅａｄ呼び出しの処理は、ＩＯＳが読み出しモードにあることを必要とし、それは、ＭＤＳへｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出しを送ることによってこのことを達成する。この呼び出しは、ファイルのｍｔｉｍｅ及びｃｔｉｍｅの現在の値である２００２０００を含む、現在の属性を返す。ｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出しが完了した後で、ＩＯＳ  Ｉ１は、処理延期期間が満了するまでに、ｍｔｉｍｅ及びｃｔｉｍｅの値２００２０００を返すことができる。本例では、これらの読み出し処理動作はすべて処理延期期間の満了前に到達することを想定していて、ｓｐｉｎ＿ｒｅａｄ処理動作はすべて、ファイルがｍｔｉｍｅ及びｃｔｉｍｅの値２００２０００を有することを示す属性を返す。
【００７１】
本例では、すべての処理動作がｃｔｉｍｅによって直列に順序付けられることに留意されたい。すなわち、Ｉ１におけるストリップへの書き込みはすべて、ストリップＩ２へのどの書き込みよりも前であるように直列に順序付けられ、ストリップＩ２への書き込み自体は、Ｉ１において実行されるどの読み出しよりも前であるように直列に順序付けられる。
【００７２】
最後に、ファイルが削除されるとき、ＭＤＳは、削除をトリガするｓｐｉｎ＿ｒｅｍｏｖｅ呼び出しを受信する。ＭＤＳは親ディレクトリからファイル名を除去し、削除されているファイルの安定した記憶領域上のリストへ上記ファイルを入れて、トランザクションを行う。この時点からファイルは、複数のシステムクラッシュが発生する場合であっても、ＭＤＳ及びすべてのＩＯＳ上で最終的には削除される。次にＭＤＳは、すべてのＩＯＳへ並列にｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ処理動作を送信して削除の第２のフェーズを実行する。すべてのＩＯＳが、ｓｐｉｎ＿ｉｏｓ＿ｄｅｌｅｔｅ呼び出しの実行が成功したことについて確認応答した後、ＭＤＳにおいてファイルが破壊され、ｉノードがＭＤＳにおけるフリーリストに戻される。
【００７３】
上述の技術は、単一のファイルに対する極めて高い読み出し又は書き込み性能を提供する複数のＮＡＳサーバ１４にてなるクラスタ１２の作成を可能にするので、高速ネットワークを介して接続される多数の独立したプロセッサから構成される計算クラスタ１２に対する共有ファイルアクセスを提供するという課題を解決する。
【００７４】
例えば、読み出し又は書き込み性能に関しては、単一のファイルに向かって動作する１００個のサーバを管理者が必要とする場合、管理者は単に、所望されるファイルを含むＶＦＳを１００個のサーバにわたってストライプ化する。各サーバ１４上の各ネットワーク構成要素２０は、上記ファイルに対する総負荷の約１００分の１を有し、各サーバ１４上の各ディスク構成要素２２もまた、上記ファイルに対する総負荷の約１００分の１を有し、よってすべてのＩＯＳ上の負荷は非常に均等に分散される。ＭＤＳ上の負荷は、次のように評価することができる。５０００個のクライアント装置が存在する場合、各ＩＯＳはおそらく、任意の一時点において当該ＩＯＳにアクセスする５０個のクライアント装置を有する。各クライアント装置は、任意の瞬間において未解決の、おそらくは８乃至１６個のＩＯ要求を有しているが、このことは、任意の瞬間にキューイングされている４００乃至８００個の要求をＩＯＳが有するということを意味する。キューイングされている１００個の要求毎に１つのｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出し又はｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しが存在し、各要求が８Ｋの読み出し又は書き込み処理動作である場合、ＩＯＳからＭＤＳへの各呼び出しは約８００ＫＢのデータ転送に相当する。ＭＤＳが、控えめに見積もって毎秒２５，０００個のｓｐｉｎ＿ｍｄｓ＿ｒｅａｄ＿ｓｔａｔｕｓ呼び出し又はｓｐｉｎ＿ｍｄｓ＿ｗｒｉｔｅ＿ｓｔａｔｕｓ呼び出しを処理することができる場合、単一のファイルに対してサポートされる総帯域幅はおよそ、毎秒２５，０００×８００ＫＢ又は２０ギガバイトになる。これは１６０ギガビットのイーサネットポートと等価であり、同等の技術により製造されるいかなるクラスタ型ＮＦＳサーバ１４システムの性能をも遙かに凌ぐ。
【００７５】
ある好適な実施形態では、装置１０は、４ＧＢのメインメモリを有するデュアルプロセッサのインテル（Ｉｎｔｅｌ）ＰＣ上で動作する。この装置１０は、４つのギガビットイーサネットカードと、到来するＮＦＳ要求のための２つのユーザポートと、クラスタ１２内の他のＮＦＳサーバ１４と通信するための２つのクラスタ１２ポートとを有する。クラスタ１２ポートを介して伝送される呼び出しは、（あるネットワーク構成要素２０からあるディスク構成要素２２宛ての）ｓｐｉｎ＿ｒｅａｄ、ｓｐｉｎ＿ｗｒｉｔｅ、ｓｐｉｎ＿ｃｒｅａｔｅ及びｓｐｉｎ＿ｄｅｌｅｔｅの各呼び出しとともに、（あるディスク構成要素２２から別のディスク構成要素２２宛ての）ｓｐｉｎ＿ｉｏｓ＿ＸＸＸ及びｓｐｉｎ＿ｍｄｓ＿ＸＸＸの各呼び出しとである。各システムはまた４ＧＢのメインメモリを有し、システムはこれをファイルデータをキャッシュするために使用するとともに、汎用プログラムメモリとして使用する。
【００７６】
装置１０はデュアルプロセッサ上で動作し、また、以下のことは必須ではないが、ネットワーク構成要素２０のコードはＣＰＵのうちの一方で実行され、ディスク構成要素２２のコード及びクラスタ処理のコードは他方のＣＰＵ上で実行される。従って、ネットワーク構成要素２０のプロセッサはＮＦＳ及びＣＩＦＳサーバのコードを実行し、一方、ディスク構成要素２２のプロセッサはＭＤＳ及びＩＯＳのコードを実行する（おそらくは、異なる複数の仮想ファイルシステム２４のために同時に）。
【００７７】
本発明について、前述の実施形態において例示を目的として詳細に説明してきたが、このような詳細事項は単に上記目的のためだけであること、及び添付の請求の範囲に記述されているもの以外にも当業者により本発明の精神及び範囲を逸脱することなく変形を行い得ることは理解されるべきである。
【図面の簡単な説明】
【００７８】
【図１】本発明に係る装置を概略的に示す図である。
【図２】本発明に係る上記装置を概略的に示す図である。
【図３】３つのストリップを示す図である。
【図４】読み出し時のデータ経路とメタデータサーバへの要求とを概略的に示す図である。
【図５】ストライプ化されたシステムにおいて書き込み処理動作を実行することの一部として交換される呼び出しを示す。
【図６】ネットワーク構成要素が適切なＮＦＳ応答を生成できるようになる前に連結されている、様々なディスク構成要素への複数の呼び出しの結果を示す図である。
【図７】作成／削除／切り詰めの通信を概略的に示す図である。
【図１】
2007537501.tif 000003
【図２】
2007537501.tif 000004
【図３】
2007537501.tif 000005
【図４】
2007537501.tif 000006
【図５】
2007537501.tif 000007
【図６】
2007537501.tif 000008
【図７】
2007537501.tif 000009
【手続補正書】
【提出日】平成18年7月28日(2006.7.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
データ記憶のための装置であって、
複数のＮＦＳサーバにてなるクラスタを備え、各サーバは、到来するファイルシステム要求と、サーバ間のクラスタトラフィックとのための複数のネットワークポートを有し、
上記複数のサーバと通信する複数の記憶装置アレイを備え、上記複数のサーバはストライプ化されたファイルシステムを使用してデータを格納する装置。
【請求項２】
各サーバはネットワーク構成要素とディスク構成要素とを有し、
各ディスク構成要素は仮想ファイルシステムを有し、上記各ディスク構成要素の仮想ファイルシステムは、ストライプ化されたＶＦＳをともに形成する請求項１記載の装置。
【請求項３】
仮想ファイルシステムのためのすべてのディスク構成要素はメタデータサーバとして動作し、
ファイルは複数の属性を有し、
各ファイルのための各サーバは、上記ファイルに係る既知の最新バージョンの属性と、書き込み処理動作の結果へ割り当てるための更新時刻及び状態変更時刻の値の範囲とを格納するキャッシュ構成要素を保持する請求項２記載の装置。
【請求項４】
上記仮想ファイルシステムのメタデータサーバではない各ディスク構成要素は、入出力セカンダリ装置であり、
ファイルの更新時刻又はファイルの状態変更時刻の範囲は、上記メタデータサーバから上記入出力セカンダリ装置によって予約され、
ファイルのすべてのストライプに影響する処理動作は、最初に上記メタデータサーバにおいてファイルに対して実行し始め、次にすべての入出力セカンダリ装置において実行し、よって、上記入出力セカンダリ装置における処理動作は、上記メタデータサーバとの通信をすでに終えているすでに実行中の処理動作のみを待機し、
処理動作は少なくとも２つのロック処理モデルのうちの一方に従い、その第１のモデルは、最初に上記メタデータサーバと同期化し、次に上記入出力セカンダリ装置において実行中の他の処理動作との同期化によりコア実行を開始するものであり、その第２のモデルは、最初に上記メタデータサーバにおいて同期化し、次に、上記入出力セカンダリ装置においてコア実行を開始している１つ又は複数の入出力セカンダリ装置における処理動作と同期化するというものである請求項３記載の装置。
【請求項５】
データ記憶のための方法であって、
複数のＮＦＳサーバにわたってファイルを作成するステップと、
上記複数のサーバにおける複数のデータストリップとしてデータを上記ファイルへ書き込むステップとを含み、上記複数のストリップはともに、ストライプを形成し、
上記複数のサーバから複数のデータストリップを読み出すステップと、
上記ストリップを上記複数のサーバから削除するステップとを含む方法。
【請求項６】
ＮＦＳサーバの仮想ファイルシステムのためのディスク構成要素をメタデータサーバとして識別し、上記メタデータサーバとしては識別されない複数のＮＦＳサーバのための複数のディスク構成要素を複数の入出力セカンダリ装置として識別するステップと、
メタデータサーバにおけるアクティブな各ファイルのための各入出力セカンダリ装置におけるキャッシュ構成要素に、処理延期期間において有効な上記ファイルに係る既知の最新バージョンの属性を格納するステップと、
書き込み処理動作へ割り当てるための更新時刻及び状態変更時刻の値の範囲を上記キャッシュ構成要素に格納するステップとを含む請求項５記載の方法。
【請求項７】
上記メタデータサーバからファイルの現在の属性と更新時刻及び状態変更時刻の範囲とを取得するために、上記キャッシュ構成要素により上記メタデータサーバに対して状態要求を行うステップと、
ファイル読み出し及びファイル書き込み要求が上記キャッシュ構成要素により許可されて実行完了となるまで、上記入出力セカンダリ装置において上記ファイル読み出し及びファイル書き込み要求をキューイングするステップとを含む請求項６記載の方法。
【請求項８】
上記キャッシュ構成要素により、上記ファイルに関して実行されているファイル読み出し及びファイル書き込み要求と、読み出し又は書き込み中である範囲とを追跡するステップと、
読み出し処理動作が実行されなければならないときに、上記キャッシュ構成要素の無効モードから読み出しモードへの移行を要求するステップと、
ファイル読み出し要求によって影響されるバイト範囲をチェックし、以前に許可されて現時点で実行中である任意のファイル書き込み要求のバイト範囲にそれが重複しないことを保証するステップとを含む請求項７記載の方法。
【請求項９】
ファイル書き込み要求に応答して、上記キャッシュ構成要素が書き込みモードへ移行することを要求するステップと、
許可されかついまだ実行中の任意のファイル読み出し要求又はファイル書き込み要求との重複について、上記ファイル書き込み要求によって影響されるバイト範囲を上記キャッシュ構成要素によりチェックするステップと、
書き込み要求を実行するときに、上記キャッシュ構成要素に格納されている更新時刻及び状態変更時刻の範囲から、更新時刻及び状態変更時刻にてなるペアを割り当てるステップとを含む請求項８記載の方法。
【請求項１０】
処理待機中のファイル読み出し及びファイル書き込み要求のキューの先頭をチェックし、先頭の要求が、ファイル読み出し又はファイル書き込み要求のいずれかの完了後に上記キャッシュ構成要素により許可され得るか否かを確認するステップと、
ファイル書き込み要求に応答してファイル長が更新されなければならないことを上記キャッシュ構成要素により検出するステップと、
上記キャッシュ構成要素を排他モードへ移行させるステップと、
上記ファイルの長さ属性を更新するために上記メタデータサーバへのファイル書き込み状態呼び出しを発生させるステップとを含む請求項９記載の方法。
【国際調査報告】
2007537501.tif 000010