(57)【要約】ローカル又は分散されたファイル・システムを効率的に実現するためのシステム及び方法が開示される。本システムは、ファイル・システムに適用されるべきトランザクションを記録するための永続ログ（”ＰＩＬ”）を利用する、分散された仮想ファイル・システム（”ｄＶＦＳ”）を含み得る。ログ記録が安定化されるや否や、論理的作動が完了したと考えられるように、ＰＩＬは、好ましくは安定的な記憶装置に実現される。これによって、作動が、ローカル又は実在のファイル・システムに適用されるのを待つこと無しに、ｄＶＦＳを即座に継続させることが可能とされる。ｄＶＦＳは、更に、一体化した設備として、１つあるいはそれより多い遠隔ファイル・システムへの複製を含み得る。
2008502078.tif 000002
【特許請求の範囲】
【請求項１】
ファイル・システムであって、
前記ファイル・システムへのアクセスを提供する１つあるいはそれより多いフロント・エンド要素、
１つあるいはそれより多いフロント・エンド要素と通信し、データの永続記憶を提供する１つあるいはそれより多いバック・エンド要素、及び、
前記１つあるいはそれより多いフロント・エンド要素から、前記１つあるいはそれより多いバック・エンド要素に通信されたファイル・システム作動を記憶する永続ログ、
を備え、
前記作動が、前記ログに記憶されたときに、前記ファイル・システムが、前記ファイル・システム作動が完了した（complete）ものとして扱うことによって、前記ファイル・システムが、前記作動が、前記１つあるいはそれより多いローカル・ファイルに適用される（applied）ことを待つことなしに、作動を継続することを可能とする、
ファイル・システム。
【請求項２】
前記ファイル・システムが、複数のコンピュータ・システムに亘って分散される（distributed）、請求項１に記載のファイル・システム。
【請求項３】
前記永続ログが、部分的に、複数のコンピュータ・システムの各々に記憶される、請求項２に記載のファイル・システム。
【請求項４】
前記永続ログが、安定した記憶装置（storage）を用いて実現（implemented）される、請求項１に記載のファイル・システム。
【請求項５】
前記安定な記憶装置が、バッテリーで支援された（battery-backed）メモリ、フラッシュ・メモリ、又は、低レイテンシー（low latency）記憶装置を備える、
請求項４に記載のファイル・システム。
【請求項６】
前記１つあるいはそれより多いフロント・エンド要素が、前記永続ログに送られるべき更新をバッファリングする（buffers）第２のログを備える、請求項１に記載のファイル・システム。
【請求項７】
前記１つあるいはそれより多いフロント・エンド要素が、前記作動を前記第２のログに配置する前に、対応するバック・エンド要素上で実行されるべき作動のための十分なリソースが存在することを確認する、請求項６に記載のファイル・システム。
【請求項８】
前記ファイル・システムが、前記永続ログから、故障した（out of order）前記バック・エンド要素に作動を適用できる、請求項１に記載のファイル・システム。
【請求項９】
前記ファイル・システムにおけるデータの一貫性を維持するロック・マネジャを更に備える、請求項１に記載のファイル・システム。
【請求項１０】
前記ロック・マネジャが、一定（certain）の要素だけが、所定の時間（given time）にファイルを更新することを可能とする排他的な（exclusive）ロックを提供する、請求項９に記載のファイル・システム。
【請求項１１】
前記ロック・マネジャが、共有された書き込みロック機能（a shared write lock function）を提供する、請求項９に記載のファイル・システム。
【請求項１２】
前記永続ログが、ペンディング中の作動（pending operations）のインデックスを維持し、
データの首尾一貫性（coherency）を保証する（ensure）ために、データのためのリクエストを受信するときに、前記１つあるいはそれより多いフロント・エンド要素が、前記インデックスをチェックする、
請求項１に記載のファイル・システム。
【請求項１３】
前記１つあるいはそれより多いフロント・エンド要素が、可能なときは常に、永続ログを用いてデータに対するリクエストを充足させる、請求項１２に記載のファイル・システム。
【請求項１４】
オブジェクトが、１つのバック・エンド要素から他のバック・エンド要素に移動（migrate）され得る、請求項１に記載のファイル・システム。
【請求項１５】
前記ファイル・システムが、前記永続ログから、第２のファイル・システムにエントリを送信することによって複製（replication）を提供するようにされる、
請求項１に記載のファイル・システム。
【請求項１６】
前記複製が、同期的である、請求項１５に記載のファイル・システム。
【請求項１７】
前記複製が、非同期的である、請求項１５に記載のファイル・システム。
【請求項１８】
ファイル・システムへのアクセスを提供する複数のフロント・エンド要素、及び、当該フロント・エンド要素と通信し、データの永続記憶を提供する１つあるいはそれより多いバック・エンド要素、を含むファイル・システムを実現するための装置であって、
前記１つあるいはそれより多いフロント・エンド要素から、１つあるいはそれより多いバック・エンド要素に通信されたファイル・システム作動を記憶する永続ログ、及び、
前記作動が前記１つあるいはそれより多いバック・エンド要素に適用されるのを待つこと無しに、一旦前記作動が前記ログに記憶されると前記ファイル・システムが作動すること（operating）を継続することを可能とするプロセス、
を備える装置。
【請求項１９】
前記永続ログが、部分的に、複数のコンピュータ・システムの各々に記憶される、請求項１８に記載の装置。
【請求項２０】
前記永続ログが、安定な記憶装置を用いて実現される、請求項１８に記載の装置。
【請求項２１】
前記安定な記憶装置が、バッテリで支援されたメモリ、フラッシュ・メモリ、又は、低レイテンシー（latency）の記憶装置を備える、請求項２０に記載の装置。
【請求項２２】
前記永続ログに送られるべき更新をバッファリング（buffers）する第２のログ、
を更に備える、請求項１８に記載の装置。
【請求項２３】
前記第２のログが、前記１つあるいはそれより多いフロント・エンド要素に配置される、請求項２２に記載の装置。
【請求項２４】
前記作動を第２のログに配置する前に、対応するバック・エンド要素で実行されるべき作動のための十分なリソースが存在することを確認する第２のプロセス、を更に備える、請求項２３に記載の装置。
【請求項２５】
前記プロセスが、前記永続ログからの作動を、故障した（out of order）前記バック・エンド要素に選択的に適用する、請求項１８に記載の装置。
【請求項２６】
前記ファイル・システム内のデータの一貫性を維持するロック・マネジャを更に備える、請求項１８に記載の装置。
【請求項２７】
前記ロック・マネジャが、一定の要素だけが所定の時間（a given time）にファイルを更新ことを可能とする排他的な（exclusive）ロックを提供する、請求項２６に記載の装置。
【請求項２８】
前記ロック・マネジャが、共有された書き込みロック（shared write lock）機能を提供する、請求項２６に記載の装置。
【請求項２９】
前記永続ログから、第２のファイル・システムにエントリを送信することによって、前記ファイル・システムを複製するための複製プロセス、を更に含む、請求項１８に記載の装置。
【請求項３０】
ファイル・システムへのアクセスを提供する１つあるいはそれより多いフロント・エンド要素、及び、当該１つあるいはそれより多いフロント・エンド要素と通信する１つあるいはそれより多いバック・エンド要素、を有し、データの永続的記憶（persistent storage）を提供するファイル・システムを実現するための方法であって、
永続ログに作動を記憶するステップであって、当該作動が、前記１つあるいはそれより多いフロント・エンド要素から、前記１つあるいはそれより多いバック・エンド要素に通信されるファイル・システム作動を含むものであり、
前記ファイル・システムが、一旦、前記作動が前記ログに記憶されると、前記作動が、前記１つあるいはそれより多いバック・エンド要素に適用されることを待つこと無しに、作動を継続することを可能とするステップ、
を含む方法。
【請求項３１】
前記ファイル・システムが、複数のコンピュータ・システムに亘って分散（distributed）される、請求項３０に記載の方法。
【請求項３２】
前記ログが、部分的に、前記複数のコンピュータ・システムの各々に記憶される、請求項３１に記載の方法。
【請求項３３】
前記永続ログが、安定した記憶装置（storage）を用いて実現される、
請求項３０に記載の方法。
【請求項３４】
前記安定した記憶装置が、バッテリで支援されたメモリ、フラッシュ・メモリ、又は、低レイテンシー記憶装置、を備える、請求項３３に記載の方法。
【請求項３５】
前記永続ログに送られるべき更新を、前記１つあるいはそれより多いフロント・エンド要素内に含まれる第２のログ内にバッファリングするステップを更に含む、請求項３０に記載の方法。
【請求項３６】
前記永続ログからの作動を、故障している（out of order）前記バック・エンド要素に適用するステップを更に含む、請求項３０に記載の方法。
【請求項３７】
ロック・マネジャを用いて、前記ファイル・システム内のデータの一貫性を維持するステップを更に含む、請求項３０に記載の方法。
【請求項３８】
前記ロック・マネジャが、一定の（certain）要素だけが、所定の時間（given time）においてファイルを更新することを可能とする排他的ロックを提供する、請求項３７に記載の方法。
【請求項３９】
前記ロック・マネジャが、共有された書き込みロック機能（shared write lock function）を提供する、
請求項３７に記載の方法。
【請求項４０】
ペンディングの作動のインデックスを、前記永続ログ内に維持し、そして、
データの首尾一貫性を保証するために、前記１つあるいはそれより多いバック・エンド要素からデータをリクエストする前に、前記インデックスをチェックするステップを更に含む、請求項３０に記載の方法。
【請求項４１】
前記永続ログだけ（just）を用いて、データに対するリクエストを充足させるステップを更に含む、請求項４０に記載の方法。
【請求項４２】
オブジェクトを、１つのバック・エンド要素から、他のバック・エンド要素に移動（migrating）させるステップを更に含む、
請求項４０に記載の方法。
【請求項４３】
前記作動を、前記第２のログに配置（placing）する前に、対応するバック・エンド要素で実行されるべき作動のための十分なリソースが存在することを確認するステップを更に含む、請求項３５に記載の方法。
【請求項４４】
前記永続ログから、第２のファイル・システムにエントリを送信することによって前記第１のファイル・システムを複製するステップを更に含む、請求項３０に記載の方法。
【請求項４５】
前記複製が同期的である、請求項４４に記載の方法。
【請求項４６】
前記複製が非同期的である、請求項４４に記載の方法。
【請求項４７】
エントリを、前記第２のファイル・システムに送信する前に、作動を補償するための永続ログからのエントリを評価（review）するステップ、及び、
補償作動（compensating operations）を削除（eliding）するステップ、
を更に含む請求項４４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は全体的にファイル・システムに関連し、より詳細には、ローカル又は分散されたファイル・システムを効率的に実現（implement）するための方法及び装置に関連する。本発明は、１つあるいはそれより多い、ローカル又は他の現実に存在する（underlying）ファイル・システムに適用されるべきトランザクションを記録するための永続インテント・ログ（persistent intent log）を利用する分散された仮想ファイル・システムを提供し得る。
【背景技術】
【０００２】
発明者：William J. Earl, Chetan Rai, Kevin Sheehan, Patric M. Stirling, Brian Byrnes, 及び、Thomas Barszczak。
【０００３】
分散されたファイル・システムは、あたかも、データが彼ら自身のコンピュータにあるように、ユーザが遠隔サーバに格納されたデータにアクセスし、処理することを可能とする。ユーザが、遠隔サーバのファイルにアクセスするときに、サーバはユーザに、ファイルのコピーを送る。データが処理され、次にサーバに戻される間に、このファイルのコピーはユーザのコンピュータ上でキャッシュされる。
【０００４】
分散されたファイル・システムは、一般的に、データ・アクセス失敗（failure）から保護するために、ファイル又はデータベース複製（replication）（複数のサーバ上のデータのコピーを分配すること）を用いる。分散されたファイル・システムの例は、以下の米国特許出願に記載される。特許文献１（発明の名称「Scalable Storage System」のシリアル番号09/709,187）、特許文献２（発明の名称「Storage System Having Partitioned Migratable Metadata」のシリアル番号09/659,107）、特許文献３（発明の名称「File Storage System Having Separation of Components」のシリアル番号09/664,667、及び、特許文献４（発明の名称「Symmetrical Shared File Storage System」のシリアル番号09/731,418）、である。これら全ては、本発明の譲受人に譲渡され、ここに参照として取り込まれる。これらの出願は、今後、集合的に「先行Agami出願」と呼ぶ。
【０００５】
他のタイプの分散されたファイル・システムが、Andrewファイル・システム又はＡＦＳとして知られている。ＡＦＳは、所定のマシンにおいて、マスタ・ファイルのキャッシュされたコピーとして、ファイルのローカルの複製を作り、後に発生した更新をコピーして戻すことをサポートする。しかし、ＡＦＳは、双方のコピーを同時に書き込み可能とする、いかなるメカニズムも提供しない。ＡＦＳはまた、信頼性のために、全ての更新がローカル・ファイル・システムを通じて書き込まれることを要求する。
【０００６】
他の先行技術の分散ファイル・システムが、特許文献５（Hickmanの米国特許第６,５６４,２５２号("Hickman")）で議論されている。Hickmanは、マルチプルのフロント・エンドのウェブサーバを持ったスケーラブルな記憶システム、及び、マルチプルのバック・エンド記憶サーバでアクセスされる、区分されるユーザ・データを説明する。しかし、データは、ユーザによって区分されるため、システムは、一人の集中使用（intensive）ユーザに対して、又は、非常に大きなデータ・ファイルを共有するマルチプルのユーザに対してスケーラブルではない。即ち、従来のAgami出願で説明されるシステムとは異なり、Hickmanは、極端に並列的な作業負荷に対してのみスケーラブルである。これは、Hickmanが説明する応用の分野である、ウェブ・サービングにおいて合理的である。しかし、より一般的な記憶サービス環境のためには合理的ではない。Hickmanはまた、全ての書き込みを、単一の、スケーラブルでない、「ライト・マスター（write master）」を通じて送るので、より初期の、そして現在の応用とは異なり、書き込みはスケーラブルではない。Hickmanが、故障した記憶サーバを復旧させるために使用されうる書き込み（write）のジャーナルの概念（notion）を説明する一方、Hickmanは、復旧のためのジャーナルのみを用い、性能を改善するためにジャーナルを使用することには言及（address）しない。Hickmanは、更に、双方向の再同期化を予想（anticipate）しない。この双方向の再同期化においては、更新は、並列に進行し、２つの同時発生的に書き込まれたジャーナルが、復旧中に一致させられる（reconciled）。
【０００７】
【特許文献１】米国特許出願シリアル番号09/709,187号
【特許文献２】米国特許出願シリアル番号09/659,107号
【特許文献３】米国特許出願シリアル番号09/664,667号
【特許文献４】米国特許出願シリアル番号09/731,418号
【特許文献５】米国特許第６,５６４,２５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
それ故、分散されたファイル・システムを実現するための、改善された方法及び装置を提供することが望ましい。
【課題を解決するための手段】
【０００９】
本発明は、ローカルの、又は分散されたファイル・システムを効率的に実現するための方法及び装置を提供する。実施例において、本システム及び方法は、ファイル・システムに適用されるべきトランザクションを記録するための、永続意図のログ（persistent intent log：”ＰＩＬ”）を利用する、分散された仮想ファイル・システム（”dVPS”）を提供する。ログ記録が安定化されたらすぐに、論理的作動が完了したと考えられ得るように、ＰＩＬは、好ましくは、安定した記憶部（stable storage）で実現される。これは、作動（operation）が、ローカル又は他の現実に存在する（underlying）ファイル・システムに適用されることを待つこと無しに、dVFSが即座に継続することを可能とする。dVFSは、更に、１つあるいはそれより多い遠隔ファイル・システムに、一体化した機能（facility）として、複製を取り込み得る。本発明のシステム及び方法は、恐らく、異なったオペレーティング・システムを走らせ、異なった実在の（underlying）ディスク・レベルのファイル・システムを持つ、１つあるいはそれより多い、コンピュータ・システムの異質の集合内で使用されうる。
【００１０】
本発明の１つの特徴によれば、ファイル・システムが提供される。本ファイル・システムは、ファイル・システムへのアクセスを提供する、１つあるいはそれより多いフロント・エンドの要素（element）、１つあるいはそれより多いフロント・エンドの要素と通信し、永続的なデータの記憶を提供する１つあるいはそれより多いバック・エンドの要素、及び、１つあるいはそれより多いフロント・エンド要素から、１つあるいはそれより多いバック・エンド要素に通信されたファイル・システム作動を記憶する永続ログ、を含む。本ファイル・システムは、作動（operations）がログ内に記憶され、作動が、１つあるいはそれより多いバック・エンド要素（element）に適用される（applied）ことを待つこと無しに、ファイル・システムが作動を継続することを可能としたときに、ファイル・システム作動が完了したものとして扱う。
【００１１】
本発明の他の特徴によれば、ファイル・システムへのアクセスを提供する複数のフロント・エンドの要素、及び、フロント・エンドの要素と通信して、データの永続記憶を提供する１つあるいはそれより多いバック・エンド要素を含むファイル・システムを実現するための装置が提供される。本装置は１つあるいはそれより多いフロント・エンドの要素から、１つあるいはそれより多いバック・エンドの要素に通信されたファイル・システム作動（operations）を記憶する永続ログ、及び、一旦作動がログに記憶された場合に、作動が、１つあるいはそれより多いバック・エンド要素に適用されることを待つこと無しに、ファイル・システムが作動を継続することを可能とするプロセスを含む。
【００１２】
本発明の他の特徴によれば、ファイル・システムへのアクセスを提供する１つあるいはそれより多いフロント・エンド要素、及び、１つあるいはそれより多いフロント・エンド要素と通信し、データの永続記憶を提供する１つあるいはそれより多いバック・エンド要素、を有するファイル・システムを実現するための方法が提供される。本方法は、作動を永続ログ内に記憶するステップであって、作動は、１つあるいはそれより多いフロント・エンド要素から、１つあるいはそれより多いバック・エンド要素に通信されたファイル・システム作動を含むものであり、そして、一旦作動がログ内に記憶された際に、作動が、１つあるいはそれより多いバック・エンド要素に適用されることを待つこと無しに、ファイル・システムが作動を継続することを可能とするステップを含む。
【００１３】
本発明の、これらの、及び他の特徴及び利点が、以下の説明を参照し、添付の図面を参照することことによって明白になるであろう。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明が詳細に説明される。図面は、当業者が本発明を実施することを可能とするような、本発明の説明目的の例として提供される。当業者にとって明白なように、本発明は、ソフトウェア、ハードウェア、及び／又は、ファームウェア、又は、それらの何らかの組合せ、を用いて実現され得る。本発明の好ましい実施例は、ここに、分散された仮想ファイル・システムを含む、記憶システムの模範的実施例を参照して説明される。しかし、本発明は、この模範的実施例に限定されず、如何なる記憶システムにおいても実現され得る。
【００１５】
Ｉ．分散された仮想ファイル・システムの一般的説明
本発明は、その情報を、１つあるいはそれより多いコンピュータ・システムに存在する、１つあるいはそれより多いディスク・レベルの実在ファイル・システムに記憶する、仮想ファイル・システムを提供する。分散された仮想ファイル・システム（”ｄＶＦＳ”）は、実在ファイル・システム又は複数のファイル・システムに先立つ（ahead of）永続意図ログ（Persistent Intent Log("PIL")）の使用によって、更新のための非常に低い待ち時間（latency）を提供する。ＰＩＬは、実在ファイル・システム又は複数のファイル・システ（例えば、ローカル・ファイル・システム（”ＬＦＳ”））に適用されるべき、各々の論理的トランザクションのための記録を記録する。即ち、ファイル・システム又はＬＦＳを修正する各ファイル・システム作動、例えば”create a file”、”write a disk block”、又は、”rename a file”に対しては、ｄＶＦＳは、トランザクション記録をＰＩＬに書き込む。ログ記録が安定化されると直ぐに論理作動が完了したと考えられ得ることによって、作動がＬＦＳに適用されることを待つこと無しにアプリケーションが即座に継続することを可能とする一方、依然として全ての更新が維持されることを保証するように、ＰＩＬは、好ましくは、安定した記憶（in stable storage）で実現される。１つの実施例において、ＰＩＬのために使用される安定な記憶は、電源故障期間、システム・リセット、及び、ソフトウェア再起動の間に亘ってその状態を維持する、バッテリー・バックされたメイン又は補助メモリ、フラッシュ・ディスク、又は、他の短い待ち時間の記憶部、を含み得る。しかし、テンポラリ・ファイル・システムに対する場合のように、もし、電源故障、システム・リセット、及び、ソフトウェア再スタートの間のデータの保管が、所定のファイルに対して必要とされないならば、ＰＩＬのために、通常のメイン・メモリが使用され得る。本発明のシステム及び方法は、恐らく、異なったオペレーティング・システムを走らせており、異なった実在の（underlying）ディスク・レベル・ファイル・システムを持つ、１つあるいはそれより多いコンピュータ・システムの異質な集合内で使用され得る。
【００１６】
マルチプルのＬＦＳインスタンスを熟知して（on top of）ｄＶＦＳが実現されるときに、マルチプルのコンピュータ・システムの上で、コンピュータ・システムの各々の上に、ＰＩＬが部分的に記憶され得る。所定の記録が、コンピュータ・システムに存在するＰＩＬの一部に記録される。このコンピュータ・システムに対しては、所定の作動（operation）が適用される。非故障耐性構成（a non-fault tolerant configuration）における１つのＬＦＳへの書き込みに対しては、記録は、そのＬＦＳにおいてのみ記録されることになる。１つのＬＦＳのディレクトリから、異なったコンピュータ・システム上の他のＬＦＳのディレクトリへの再命名（rename）のような、ＬＦＳインスタンスに亘る（span）作動に対しては、記録は、それが適用される各位置（location）に記録されることになる。所定のデータ項目が、異なったコンピュータ・システム上の２つのＬＦＳインスタンスに記録されるような、非故障耐性構成に対しては、書き込み作動記録さえもが、マルチプルのＰＩＬセクションの上に（書き込みが適用される各システムへ１つずつ）記録されることになる。
【００１７】
ＰＩＬに記録された作動は、作動が記録されると直ぐに、ファイル・システムのユーザの観点から安定（stable）なので、論理的に依存する作動が、（ファイルに書き込む前にファイルを生成するように）順々に（in order）実行される限り、作動を、実在する（underlying）ＬＦＳに適用することは、必ずしも、作動がＰＩＬに加えられた順序とは同じではない順序で、時間とともに為され得る。これによって、各ディスク・シークに対してより論理的な作動をすることによって（例えば、ディスク上で互いに近傍に位置するファイル上での作動のクラスタリングを通じて）、そして、信頼性を犠牲とせずに回転的な位置最適化（rotational position optimization）を可能とするために最新のディスクの書き込みバッファを利用することによって、ディスクであって、当該ディスク上にＬＦＳが記憶されるディスクの性能を最大化するやり方で、作動が記憶されることが可能となる。
【００１８】
ｄＶＦＳは、複製をも可能とする（exhibit）。本発明の文脈での用語「複製（replication）」は、ファイル又はファイルの組又は全体のｄＶＦＳを、他のｄＶＦＳ又はマルチプルの他のｄＶＦＳインスタンスにコピーすることを意味するように理解されるべきである。別の文脈では、しばしば、複製は、「ブロック・レベル（block level）」複製を含むために使用され得る。この「ブロック・レベル（block level）」複製においては、ブロックが、ディスク・ボリューム（a disk volume）に書き込むことが、いくつかの他のボリュームに複製される。しかし、本発明においては、複製は、論理的ファイル又はファイルの組（ファイル・システムを表す物理的ブロックではない）の複製を意味する。
【００１９】
１つの実施例において、複製は、ＰＩＬ内の関連する記録の各々のコピーを、選択されたファイルの複製が維持されるべき遠隔システム又は複数の遠隔システムに送信することによって実現される。複製のために選択されたファイルに関連する記録だけがコピーされる必要があるので、必要とされる帯域幅は、凡そ、それらのファイルへの更新のボリュームに比例し、ソース・ファイル・システムへの更新のトータルのボリュームには比例しない。
【００２０】
更に、もし、非同期複製が選択されるならば、ファイルの生成、書き込み、及び削除、のような、補償作動を省略することが可能である（もしそれら全てが、同時に送信を待っている作動のバッファ内にある場合に、それらの作動が、全く、決して転送されないように）。作動の補償を省略することは、ログ内で所定のファイルに対してペンディングとなっている作動の順序付けられたリストを維持し、もし、削除作動が追加され、リスト内の最初の作動が”create”であるならば、全体の作動のリストを破棄する（discard）ことによって実現され得る。（もし、最初の作動が”create”でないならば、delete以外の全ての作動が、破棄され得る。）
【００２１】
ログ・ベースの複製モデルは、複製が同期的であるか、非同期的である否かに関わらず、オンラインで、かつ無矛盾（consistent）の、複製のビューを可能とするという更なる利点を持つ。複製が行われている間に、遠隔ファイル・システムがマウントされる（mounted）ことを許さない、ブロック・ベースの複製スキームとは異なり、ログ・ベースのモデルは、複製の生の（live）使用を可能とする。複製において作動はＰＩＬ要素に記憶されるので、作動は、故障している（out of order）、実在する（underlying）ディスク・レベルのファイル・システムに適用され得るが、ログ・ベースの複製は複製において、順序立って（in order）作動を論理的に適用するので、これが可能となる。
【００２２】
最後に、分散されたロック・マネジャ（lock manager）が追加されることによって、それが複製における無矛盾のビューを維持するので、ログ・ベースの複製スキームが、ソースと宛先のロール（destination role）の交換をサポートできる。それによって、長距離によって、従って、長い光速遅延によって分離された複製サイトの集合に対する全体的な待ち時間を最小化するための、地理的に拡散させる（migrate geographically）ための、ファイルの集合へのローカル制御及び実時間（real time）アクセスが可能となる。
【００２３】
II．全体的システム・アーィテクチャ
図１は、セクションＩで説明されたｄＶＦＳのような、本発明によるｄＶＦＳ110を取り込んだ、記憶システム100の１つの模範的実施例を示す。記憶システム100は、通信可能にカップルされ、複数の遠隔クライアント102をサービスし得る。システム100は、1つあるいはそれより多いシステムス・マネジメント・サーバ（ＳＭＳ）プロセス104、及び、ライフ・サポート・サービス（ＬＳＳ）プロセス106を含む、複数のリソースを持つ。システム100は、ネットワーク・データ・マネジメント・プロトコル（ＮＤＭＰ）112、ネットワーク・ファイル・システム（ＮＦＳ）114、及び、共通インターネット・ファイル・システム（ＣＩＦＳ）プロトコル116のようなプロトコルを通じてクライアントと通信するための種々のアプリケーションを実装（implement）し得る。システム100は、ｄＶＦＳ110と通信する複数のローカル・ファイル・システム124（その各々が、SnapＶＦＳ126、ジャーナルド・ファイル・システム（ＸＦＳ）128、及び、記憶ユニット130を含む）をも含みうる。
【００２４】
ＳＭＳプロセス104は、従来的なサーバ、コンピューティング・システム、又は、そのような装置の組合せを含み得る。各ＳＭＳサーバは、システム100に関連する状態及び構成情報を記憶する構成データベース（configuration database:ＣＤＢ）を含み得る。ＳＭＳサーバは、種々のシステム管理サービスを実行するように適応されたハードウェア、ソフトウェア、及び／又は、ファームウェアを含み得る。例えば、ＳＭＳサーバは、構造と機能において実質的に、米国特許第６，７０１，９０７号（’９０７特許）に説明されたＳＭＳサーバに類似し得る。この’９０７特許は、本願の出願人に譲渡され、参照として、ここに全体的に完全に取り込まれる。
【００２５】
１つの実施例において、ライフ・サポート・サービス（ＬＳＳ）プロセス106は、そのクライアントに２つのサービスを提供し得る。ＬＳＳプロセスは、そのクライアントが、リレーショナル・テーブルにおけるテーブル・エントリを記録し、検索することを可能とする、更新サービスを提供し得る。それは、ノードからネットワーク構造（fabric）内への所定のパスが、有効（valid）か否かを決定する”ハートビート（heartbeat）”サービスをも提供し得る。ＬＳＳプロセスは、予測可能であって、有界時間（bounded time）において発生する作動を伴う、実時間サービスである。この有界時間（bounded time）において発生とは、所定の期間内、即ち（or）、”ハートビート・インターバル”内であるようなものである。ＬＳＳプロセスは、実質的に、’９０７特許に説明されるＬＳＳプロセスと類似し得る。
【００２６】
図１の実施例において、クライアント通信アプリケーションは、ＮＤＭＰ112、ＣＩＦＳ16、及び、ＮＦＳ114を含みうる。ＮＤＭＰ112は、主及び副記憶装置の間のデータ・バックアップ及び復旧通信を制御するために使用され得る。ＣＩＦＳ116及びＮＦＳ114は、ユーザが、あたかも、遠隔コンピュータ上のファイルが、ユーザのコンピュータに存在するように、遠隔コンピュータ上のファイルをビュー（view）し、選択的に記憶し、更新することを可能とするために使用され得る。他の実施例では、システム100は、追加の、及び／又は、異なった通信プロトコルを提供するアプリケーションを含みうる。
【００２７】
ＳＮＡＰ  ＶＦＳ126は、論理的ファイル・レベルにおけるファイル・システムのスナップ・ショットを提供する機能である。スナップ・ショットは、ファイル・システムのポイント・ツー・ポイントのビューである。それは、スナップ・ショットの時点のデータと現在のデータの双方が記憶されるために、スナップ・ショットが撮られた（taken）の後に修正された何らかの（any）データをコピーすることによって実装され得る。いくつかの先行技術のシステムは、ボリューム（volume）・レベル（ファイル・システムの下位）においてスナップ・ショットを提供する。しかし、これらの”先行技術”のスナップ・ショットは、全ての物理ブロックではなく、ファイル更新によって修正されたディスク割り当てマップのような論理データのみ（特にオーバーヘッド・ブロック）を複製するファイル・レベルのスナップ・ショットの効率と柔軟性を持たない。１つの実施例において、ＸＦＳ128は、元々ＳＧＩ  ＩＲＩＸに実装され、それ以降Ｌｉｎｕｘにポートされた、ＳＧＩによって生成されたＸＦＳファイル・システムである。１つの実施例において、ＸＦＳ128は、ジャーナル化されたファイル・データではない、ジャーナル化されたメタデータを持つ。記憶リソース130は、ＸＦＳ128のための物理的記憶を提供する従来的な記憶装置である。
【００２８】
III．ＤＶＦＳ及びＰＩＬの作動
Ａ．全体的作動
ｄＶＦＳ110において、一般的に、ローカル・アプリケーションへの、及び、ネットワーク・ファイル・アクセス・プロトコル・サービス・インスタンスへのファイル・アクセスを提供する、マルチプルの”フロント・エンド”処理要素が存在する。（これらは、”ゲトウェイ”とも呼ばれ得る。）”フロント・エンド”要素は、ｄＶＦＳ110の上位レベル、例えば、ファイル・システムへのアクセスを提供するハードウェア・モジュール当たりのファイル・システム当たりの１つのインスタンス、である。各フロント・エンドは、そのモジュール上の所定の仮想ファイル・システム・インスタンス、を表し得る。そして、各フロント・エンドは、同じ或いは他のモジュール上の”バック・エンド”要素に特有の、及び、遠隔システム（複製のための）に特有の作動を分配し得る。”バックエンド”要素は、ｄＶＦＳ110の下位レベル、例えば、そのファイル・システムのためのデータを記憶しているハードウェア・モジュール当たりのファイル・システム当たりの１つのインスタンス、である。各バック・エンド要素は、ディスク記憶部のモジュール上のファイル・システムに割り当てられた、如何なるディスク記憶部をも制御し、データの永続（安定）記憶を提供する責任を持つ。
【００２９】
図２は、本発明による、フロント・エンド及びバック・エンド要素の間のデータ及びファイル・システム作動の通信の例を説明する。各”フロント・エンド”要素20Ａ、Ｂは、ローカル・インテント・ログ250Ａ、Ｂ内のＰＩＬ260Ａ、Ｂに宛先がある、その記録のストリームを構築する。このローカル・ログは、ＰＩＬ260Ａ、Ｂ及び複製サイトに送られている更新のためのバッファである。そのため、要求された数値（number）が、ファイル・システムのための信頼性ポリシーによって決定されて、エントリが、ローカル又は遠隔の１つあるいはそれより多いＰＩＬ位置に送信されるまでは、エントリは、永続であるとは考えられない（そして、それ故、ネットワーク・ファイル・アクセス・クライアント又はローカル・アプリケーションに、完了したものとして応答（acknowledge）されない。）。（データ信頼性は、コピーの数値が増加するにつれて増加する。何故なら、全てのコピーの同時故障の機会は、ただ回のコピーの故障の機会より非常に少ないからである。）
【００３０】
ｄＶＦＳ110において、永続記憶は、マルチプルのマシンの全体システムのバック・エンド要素内に存在する。ｄＶＦＳ110において、所定のバック・エンド要素は、一般的に、ファイル・メタデータといくつかのファイル・データの双方を保持する（一般的に、もし、そのファイルに対するメタデータがその要素の上にあり、ファイルが小さいならば、所定のファイルに対してはファイル・データの全てを）。スケーラビリティのために、大きなファイルに対しては、ファイルのセグメントは、他のバック・エンド要素上のＬＦＳファイル・オブジェクトとしても記憶される。先行Agami出願で使用される用語においては、ｄＦＳバック・エンドは、”メタデータ・サーバ”と”記憶サーバ”の機能（functionality）を、１つの要素に結合し得るが、より大きなファイルに対する記憶セグメントは、依然として、一般的に、マルチプルのバック・エンド要素に亘って分散され得る。また、丁度、メタデータが、先行Agami出願でマルチプルの”メタデータ・サーバ”要素に亘って分散されたように、メタデータは、マルチプルのバックエンド要素に亘って分散され得る。図２において、示されるバック・エンド要素は、ＸＦＳ228Ａ、Ｂ、ボリューム・マネジャ229Ａ、Ｂ、及び、記憶装置又はディスク230Ａ、Ｂを含みうる。
【００３１】
ｄＶＦＳフロント・エンド要素200Ａ、Ｂが、所定の論理的リクエストを受信するときに、それは、ローカル・インテント（intent）・ログ250Ａ、Ｂに作動記録を入力し、次に、その記録が、バック・エンド要素内のＰＬＩセグメント260Ａ、Ｂに十分に分配されるまで待つ。本システムは、ローカル・インテント・ログ記録を、それらの宛先にストリーミング（stream）する”ドレイナ（drainer）”スレッド又はステート・マシン（state machines）の組を含み得る。別個の、”応答（acknowledgement）”スレッド又はステート・マシン（state machines）の組が、記録（record）に対する宛先からの応答を取り扱い、それらの記録の完了（持続性（persistence））を、如何なる、待ち状態の論理的リクエストにも通知（post）する。
【００３２】
ＰＩＬは永続的（persistent）なので、ドレイナ・スレッドは、不正常に（out of order）、いくつかの作動に適用され得る（それらが論理的に独立である限り）。例えば、異なったブロックへの２つの書き込み（writes）は、不正常に適用され得、異なった名称で生成された２つのファイルは、不正常に生成され得る。更に、相補的（complementary）作動が削除され得る。例えば、ファイル生成の後のいくつかのファイルへの書き込みの後の当該ファイルの削除によって、ファイル生成が、ユニットとして破棄され得る。フロント・エンドが、作動を本実施例のＰＬＩにエンターする前に、全ての作動が成功せねばならないことを確認する（verify）ので、相補的作動の組が破棄されるならば、後の作動が失敗することは全くない。作動が成功せねばならないという確認（verification）が、実在する（underlying）ファイル・システム又は複数のファイル・システムにおける作動のための十分な空間（space）を確保しておくことを含み得ることに留意して欲しい。作動のトータルの数を削減することと、関連する作動を集合させること（clustering）の双方によって、このアプローチは実質的にＬＦＳの更新効率を改善する。
【００３３】
Ｂ．一貫性（consistency）
所定の記録（record）の宛先は、１つあるいはそれより多いローカルのＰＩＬセグメントを含み得、１つあるいはそれより多い遠隔の複製システムを含み得る。並行的に記録を生成するマルチプルのフロント・エンド要素が存在し、そして、それらをバック・エンド要素及び複製システムに並行的に送信するので、性能（performance）は、要素の数にスケーラブルである。しかし、本システムによって提起される貫性についての、いくつかの課題が存在する。第１に、フロント・エンド要素（例えば200Ａ及び200Ｂ）にとって、同じファイルにおける同じ位置への書き込みを、同時に開始（initiate）することが一般的にあり得る。もし、冗長性の目的のために、ファイルが２つのバック・エンド要素に記憶されるならば、分散された一貫性（distributed consistency）を維持するための解決法が存在しない場合、通信遅延の気紛れ（vagaries）に応じて、１つのバック・エンドのために１つの順序で更新を適用し、そして、他のバック・エンドのために、逆の順序で更新を適用することが可能であろう。
【００３４】
１つの実施例において、本システムは、この問題に対する２つの解決法を提供する。そして、状況に応じて特定の解決法を選択し得る。コンテンションが少ししか存在しないような一般的な場合において、１つのマシンだけが、一度に（at a time）所定のファイル又はファイルの部分（part）に対して更新を行うことを可能とするために、ロック・マネジャ（lock manager）270Ａ、Ｂが用いられ得る。１つの実施例において、ロック・マネジャ270Ａ、Ｂは、バック・エンド要素の各々に亘って分散され得る。ｄＶＦＳのフロント・エンド要素は、所定のオブジェクトに対するロックのためのそれらのリクエストを、そのオブジェクトを記憶するバック・エンド要素上のロック・マネジャ・インスタンスに提出（address）する。（冗長性のために、ファイルに対するデータが２つのバック・エンド要素上に記憶されるときのような）分散されたオブジェクトに対しては、２つのロック・マネジャ（例えば、ロック・メネジャ270Ａ、Ｂ）が、どちらが、主ロック・マネジャであるかをネゴシエートする。（単純なルールは、もし１つが現在、プライマリ（primary）ならば、それが維持されるということである。もし、いずれも、現在、プライマリなければ、より低く番号付けされたモジュール識別子又はアドレスを持つものが、主となる。）プライマリは、その身元（identity）を、そのようなものであるとして、ＬＳＳ内で表示（publishes）する。そして、もし、バックアップが、プライマリに行くべきであったリクエストを受信するならば、ＬＳＳ更新の遅延の成り行きとして、バックアップが、フロント・エンドをプライマリに再指向（redirects）させる。もし、ファイルに対するデータが、マルチプルのバック・エンド要素（複数）に亘って分散されるならば、ファイルのためのデータの一部に対するロック・マネジャが、ファイルのためのメタデータに対するロック・マネジャとは異なり得ることに留意して欲しい。即ち、もし、データが区分されているならば、各区分に対するロック・マネジャは、区分における（with）共同常駐者（co-resident）である。更新ロックの保持者は、ロックによって保護される、何らかの（any）ペンディングのライトを、全ての関連するバック・エンド要素にフラッシュ（flush）することが要求される。このフラッシュには、種々のバック・エンド要素において観察されたリクエストが、迅速に並列化（serialized）されるように、低位レベルの同時実行（concurrency）の犠牲の下、ロックを放棄する（relinquish）前に応答（acknowledgements）を受信することが含まれる。
【００３５】
第２の解決法は、ロック・マネジャが、所定のファイル又はファイルの部分に対する高レベルのロック・オーナーシップ・トランジション（lock ownership transitions）を検知する場合に使用され得る。その場合には、ロック・マネジャは、排他的ロックの代わりに、「共有化された書き込み（shared write）」ロックを認可（grant）する。共有化された書き込みは、各フロント・エンドが、後の読み出し（reading）に対するロックによって保護されるデータのコピーをキャッシュしないこと、及び、ロックによって保護された全ての作動を、そのようなものであるとしてフラグする（flag）ことを要求する。そのようにフラグされている作動を受信しており、２つ或いはそれより多いバック・エンド要素に配送（delivered）されているものとして指定されているバック・エンド要素は、バック・エンド要素が、（１）他の要素又は他の複数の要素（それに対して、その作動が配送された）と順序情報を交換する、又は、（２）無矛盾の順序について合意する、までは、作動を、そのＰＩＬ内に保持せねばならないし、それを適用することも、それによって影響され得る読み出し（reads）に応答することも、いずれもしてはならない。作動はＰＩＬ内では安全なので、クライアントは、進むことができる。従って、大きなファイルの並行書き込み（parallel writes）は、非常に高速であり得る。ＰＩＬで暗黙のバッファリングは、リクエストがマスクされるための一連の順序の決定が見えないこと（latency）を可能とし、及び、その決定が、一度にリクエストのバッチのために為されることによって、オーバーヘッドを削減することをも可能とする。
【００３６】
１つの実施例において、一連の順序を決定するためのシステムによって実現されたアルゴリズムは、バック・エンド要素のいくつかが、一定の作動を受信していない（そして、フロント・エンド故障の場合には、決して受信しない）ような場合を処理する（account for）。これは、既知のリクエスト・リストを交換し、各バック・エンド要素に、そのピア（peer）に、当該ピアが持っていない（missing）何らかの（any）作動を配送（ship）させることによって処理（handle）され得る。一旦、全てのバック・エンド要素が、無矛盾の作動の組を持つと、当該バック・エンド要素は、順序付け情報の周期的な交換（矛盾する書き込み（writes）の一連の順序の指定）を含む通常の作動を再開する。無矛盾の順序に到着する単純な手段は、所定の複製されたデータの組を扱うバック・エンド要素が、（最も低い識別子を持つその要素を選択する等によって）リーダー（leader）を選択（elect）し、作動に対するそれ自身の順序を、グループのための順序として分配することについてリーダーに依存することである。一連の作動の順序を決定することに対するこの要求（requirement）は、「共有化された書き込み（shared write）」モードが、使用されたときにのみ適用可能です。復旧を単純にするために、一連の順序を決定するための通信が、そのような書き込みが目立つ（outstanding）ときにのみ為されるように、「共有化された書き込み」モードで為された書き込みは、そのようにラベリングされるべきである。
【００３７】
Ｃ．首尾一貫性（Coherency）
作動は、ＰＩＬでしばらくバッファリングされ得るので、フロント・エンド要素は、バック・エンド要素に、データ・ブロック又はファイル・オブジェクト（これらに対して、ＰＩＬで更新がバッファリングされる）を求める（ask for）ことができる。もし、データ項目に対するリクエストが、ＰＩＬをバイパスし、実在する（underlying）ファイル・システムからリクエストされた項目（item）を持って来る（fetch）というものならば、当該リクエストは、最も最近の更新を反映していない古いデータを観察（see）するであろう。それ故、ＰＩＬはメモリに、ファイルによって編成された（organized）ペンディングの作動のインデックス、情報のタイプ（メタデータ、ディレクトリ・エントリ、又は、ファイル・データ）、及び、（ファイル・データに対する）オフセットと長さ（length）を維持する。各リクエストは、インデックスをチェックし、何らかの（any）ペンディングの更新を、それが実在するファイル・システム内で発見したものとマージ（merges）する。リクエストが、ＰＩＬから完全に満足されるような、いくつかの場合には、実在するファイル・システムへの参照は為されず、これは効率を改善する。
【００３８】
１つの実施例において、ＰＩＬインデックスは永続的である。停電のような故障からの復旧に際して、ＰＩＬ復旧論理は、ＰＩＬのコンテンツからインデックスを再構築する。
【００３９】
「共有化された書き込み」モードの場合には、協調（coordination）が適用されないならば、2つ或いはそれより多いバック・エンド要素への並行書き込みによって、１つのバック・エンド要素からの読み出しは、他のバック・エンド要素からの読み出しとは異なった結果を観察（see）し得る。従って、システムは、以下の協調を使用し得る。もし、所定のバック・エンド要素が読み出しを受信し、そのインデックス内での一致（match）を発見し、そしてもし、その一致が、書き込みであって、当該書き込みのために一連の順序が決定されていない書き込みのためのものであるならば、一連の順序が決定されるまで読み出しはブロックされる。この場合は、通常の排他的書き込みモードには適用されないことに留意して欲しい。何故なら、その場合には、排他的書き込みロックを保持しているフロント・エンドは、書き込みのための一連の順序を決定し、指定（specifies）するからである。
【００４０】
Ｄ．マイグレーション（migration）
先行Agami出願で議論されたように、分散された記憶システムにおける真のスケーラビリティは、１つのバック・エンド要素から、他のバック・エンド要素にファイル・オブジェクトをマイグレートする能力によって可能とされる。他の従来技術のシステムにおける種々の例とは異なって、先行Agami出願で説明されるマイグレーションは、全区分（partitions）をマイグレートすること、又は、グローバル・パーティショニング述語(predicate)を修正することには基づかない。その代わり、ファイル・ディレクトリ・ツリーの領域（region）（１つのファイルと同程度小さい場合があるが、一般的にはより大きい）が、新しい位置（location）を表示するためにフォワーディング・リンクが残された状態で、マイグレートされる。フロント・エンド要素は、オブジェクトの位置をキャッシュし、区分の中にオブジェクトの親が存在する当該区分（partition）内のオブジェクトを調べる（look up）ためにデフォールト値をとる（default）。
【００４１】
１つの実施例において、ｄＶＦＳ110は、「外部ファイル識別子（External File IDentifier）(EFID)」の概念（notion）を導入することによって、及び、実在する（underlying）ファイル・システムによってオブジェクトのためのハンドル（handle）として用いられる、ＥＦＩＤから「内部ファイル識別子（Internal File IDentifier）(IFID)」へのマッピングによって、マイグレーションへの、このアプローチをサポートする。マッピングは、特定のバック・エンド区分（partition）（この中に所定のＩＦＩＤが存在する）のためのハンドルを含む。ＥＦＩＤテーブルは、ファイルに対してＥＦＩＤｓが参照を行う当該ファイルと同じやり方で区分される。即ち、区分（その中に、そのＥＦＩＤを参照しているディレクトリ・エントリが発見される）内の所定のＥＦＩＤに対して、ＥＦＩＤからＩＦＩＤへのマッピングが調べられる。所定のＥＦＩＤｓの範囲を保持する区分を与える、区分のグローバル・テーブルが存在する。（ＥＦＩＤのために参照されたオブジェクトがそのローカル・キャッシュの中に存在しない、当該ＥＦＩＤを含むＮＦＳファイル・ハンドルと共に提示されたときのように）必要とされたときに、各フロント・エンド要素が、オブジェクトを迅速に位置決めできるように、各フロント・エンド要素は、このグローバル・テーブルのコピーをキャッシュする。
【００４２】
ＰＩＬは、ＥＦＩＤ（ＩＦＩＤが知られているなら、これに対して、一緒に各作動が適用される）を記録する。ＥＦＩＤは、各オブジェクト生成に対して、常に知られている。何故なら、それは、フロント・エンドによって確保されていた、以前に割り当てられていなかったＥＦＩＤｓの組から、フロント・エンドによって割り当てられているからである。（各バック・エンドには、ＥＦＩＤｓの範囲のプライマリ・オーナーシップ（primary ownership）が割り当てられる。次に、各バック・エンドは、当該プライマリ・オーナーシップを、フロント・エンドに確保させることを可能とできる。ＥＦＩＤｓが消費されるにつれて、ＳＭＳ要素が、ＥＦＩＤｓの追加の範囲（ranges）を、ＥＦＩＤｓが枯渇しつつあるバック・エンドに割り当てる。ＥＦＩＤの範囲は、全てのＥＦＩＤｓを使い尽くす実際的な危険が無いように、十分大きく（64ビット）される。）ＬＦＳ内でオブジェクトが生成されたときに、ＩＦＩＤはローカル・ファイル・システムによって戻され、ＰＩＬはＩＦＩＤを記録し、作動が完了であることをマーキングする前に、更新を、ＥＦＩＤからＩＦＩＤへのマッピング・テーブルに適用する。マイグレーション作動は、宛先（destination）のバック・エンドＰＩＬに、オブジェクトの新しいコピーの生成を記録し、次に、双方のバック・エンドにおけるＥＦＩＤからＩＦＩＤへのマップへの更新を行うとともに、オブジェクトの古いコピーの削除のための記録を、ソースのバック・エンドＰＩＬにエンターする。
【００４３】
Ｅ．リソース管理（management）
ｄＶＦＳ110の１つの実施例において、ｄＶＦＳは、一旦作動ログ（例えば、インテント・ログ250Ａ、Ｂ）にエンターされると、作動が完了することを保証する。従って、フロント・エンド要素は、作動をログにエンターする前に、各バック・エンド要素に十分なリソース（作動を完了させるために、このリソースが貢献しなければならない）が存在することになることを保証する。フロント・エンド要素は、前もってリソースを確保し、その確保部分（リザベーション：reservation）を、作動によって要求されることが予想される最大リソースまで削減することによってこれを行い得る。
【００４４】
所定のフロントエンド要素は、それが作動を送っている先の各バックエンド要素上のリソースのリザベーション（主に、ＰＩＬ空間及びＬＦＳ空間）を維持し得る。もし、当該所定のフロント・エンド要素が、リザベーションを消費し尽くしたならば、それは、追加のリザベーションを獲得し得る。もし、フロント・エンド要素が故障したならば、そのリザベーションが開放され、再開された、又は新たに開始されたフロント・エンド要素は、作動を完遂（commit）する前に、新しいリザベーションを獲得することになる。フロント・エンド要素が、作動をフロント・エンド作動ログに配送するときに、フロント・エンド要素は、それが、バック・エンド要素の各々（作動はこれらを宛先としている）のためにリザーブ（確保）していたリソースを減少（decrement）させる。例えば、もし、書き込みが、分散されたミラー化された（ＲＡＩＤ−１）書き込みとして、２つの異なったバック・エンド要素に適用されるならば、それは、２つのバック・エンド要素の各々に空間（space）を要求するであろう。
【００４５】
１つの実施例において、フロント・エンド要素は、所定のバック・エンドに対するワーストケースの要求分だけ、そのリザーブされた空間を減少させる。作動が、実際に、ＰＩＬに記録されるときに、実際の空間は用い尽くされることになり、新しいリザベーションのために利用可能な空間は、その量だけ減少させられる。従って、もし、フロント・エンド要素が、２つのページが要求されることを予測するならば、そして、１つのみが使用されることを予測するならば、例え、フロント・エンドが、そのリザーブされた空間を、２ページ分だけ減少させたとしても、１つのページは依然として将来のリザベーションのために利用可能であることになる。
【００４６】
ワーストケースのリザベーションが大きくなることを避けるために、バック・エンド要素において手当て（care）が為され得る。例えば、もし、１つのページをファイルに書き込みことが、通常のケースにおいて１ページの空間を要求するが、いくつかの割り当てシナリオにおいては１０ページの空間を要求するならば、フロント・エンドは、１０ページを消費せねばならないであろう（これは、人為的に（artificially）ＰＩＬの利用可能なサイズを削減することになる）。よって、バック・エンド要素は、常に、束縛された（bounded）空間を持つＰＩＬに記録された作動を退かせる（retire）ことを可能とすることを工夫（contrive）することになる。一旦、実際の使用が知られると、過剰にリザーブされたリソースは、バック・エンドによって開放され、将来のリザベーションのために利用可能となる。
【００４７】
Ｆ．下位レベルバッファの同期
１つの実施例において、いくつかの作動のメモリにおけるバッファリングは、論理ファイル・システム・レベル、ディスク・ボリューム・レベル、及び／又は、ディスク・ドライブ・レベルにおいて発生し得る。これは、ドレイナにおいて作動を論理ファイル・システムに適用することが、作動が完了し、ＰＩＬから除去されるための資格がある、と考えられ得ることを意味しない。その代わり、それは、後続の、実在する（underlying）論理ファイル・システムのチェックポイントが完了するまでの暫定的なもの（tentative）と考えられることになる。（ここでの、用語「チェックポイント」は、データベース・チェックポイントの意味で使用される。つまり、ジャーナルのセクションに対応するバッファされた更新が、ジャーナルのそのセクションが破棄される前に、実在する（underlying）永続記憶にフラッシュされる（flushed）ということが保証される。）
【００４８】
ＰＩＬは、作動がドレインされる（drained）ときに設定される、各作動に対するチェックポイント世代（generation）を維持し得る。チェックポイント世代数（generation number）の最初の増加（incrementing）の後に、ＰＩＬドレイナは、周期的に、実在する（underlying）論理ファイル・システムに、チェックポイントを実行するように依頼する。チェックポイントが完了した後に、ドレイナは、以前の世代番号を持つ全ての作動（これらは、現時点では、永続記憶の上で安全である）を破棄（discard）する。（これは、従来のデータベース・システム及びジャーナル化されたファイル・システムで使用される技術である。）
【００４９】
Ｇ．リカバリ（recovery）
１．ローカル・リカバリ
もし、原因が、停電、システム・リセット、又は、ソフトウェア故障及びリセット、に関わらず、マシンが故障したならば、ｄＶＦＳのコンテンツは、ＰＩＬの使用によって、無矛盾の状態に回復（recovered）され得る（ＰＩＬが、実質的に被害を受けずに維持されると仮定した場合）。ＰＩＬは、不揮発性の記憶内にあるので、そのような状況におけるリカバリの能力は、正当に存在し得る。更に、クラスタ化された環境においては、双方コピーが同時に破損することがあり得ないように、所定のＰＩＬは、第２のハードウェア・モジュールにミラーリング（mirrored）され得る。（もし、ローカルのコピーが失われたならば、最初のステップは、遠隔ミラーリングの場合に、それを、遠隔コピーから再記憶することである。）
【００５０】
ＰＩＬ復旧は、最初に、作動ログを特定（identify）することによって進行する。これは、データベース又はジャーナル化されたファイル・システム・ログのために一般的に用いられる、従来的な技術を用いるによって実行され得る。例えば、システムは、不完全なブロックが破棄されることを可能とするためのチェックサム、及び、ログ・ブロックの順序を決定するためのシーケンス番号、を取り込んでいるヘッダ及びトレーラ・レコードを伴って各ログ・ブロックを常に書き込んでいる、ログ領域内のログ・ブロックを走査（scan）し得る。ログ記録は、不揮発性の記憶部に別個に記憶される何らかのデータ・ページを特定するために走査（scan）される。そして、他のやり方では特定されない何らかのページは、フリーにマーキングされる（marked free）。
【００５１】
次のステップは、読みだし（reads）の再開を可能とするために、首尾一貫性（coherency）インデックス（例えば、セクションIII．Ｃ．で議論されたもの）を、主メモリ内のＰＩＬに再構築することである。最後に、もし作動が等羃(とうべき)（idempotent）でないならば、各レコードについて、実在する（underlying）論理ファイル・システム（ディスク・レベルのファイル・システム）が、検査されて、特定の作動が実際に、実行されたか否か判断する。”set attributes”又は”write”のような作動に対しては、このチェックは要求されない。つまり、そのような作動は、単に反復されるものである。しかし、”create”や”rename”のような作動に対しては、システムは、複製を避ける。そうするためには、システムは、ログを順々に（in order）走査（scan）する。もし、システムが、作動が、既に完了したことが知られている、より先行する作動から独立であると判断するならば、システムは、新しい作動を、未完了であるとしてマーキング（mark）する。
【００５２】
さもなければ、”create”に対しては、システムは、最初に、ＥＦＩＤによってオブジェクトを調べることを試み得る。もし調査が成功し、次にcreateが成功すれば、たとえオブジェクトがその後再命名されても、システムは、”create”を、実行された（done）ものとしてマーキングする。もし、ＥＦＩＤによる調査が失敗したならば、名称によってオブジェクトが調査され、ＥＦＩＤが一致することが確認（verify）される。ＥＦＩＤが一致せず、発見されたオブジェクトのＥＦＩＤに対してＰＩＬ内で作動が存在しないなら、createは発生しなかったことになる。何故なら、発見されたオブジェクトは、新しいcreateの前に生成されていたはずだからである。もし、ＥＦＩＤが一致するならば、ＥＦＩＤをエンターすることは完了していないので、システムは、ＥＦＩＤ更新が依然として要求される状態で、作動が、部分的に完了したものとしてマーキングする。
【００５３】
”rename”に対しては、システムは最初に、ＥＦＩＤからＩＦＩＤへのマッピングが存在するか否かをチェックし得る。もし、存在しなければ、再命名は完了したはずであり、その後、削除が為されたはずである。何故なら、再命名は、マッピングを破壊せず、マッピングが生成されるまで完了し得ないからである。さもなければ、システムは、作動を分割（split）させて、新しい名称を生成し、古い名称を削除し得る。もし、新しい名称が存在するが、それが、異なったＩＦＩＤに対するものならば、システムは、（もし、リンク・カウントが、１より大きいならば）新しい名称をアンリンク（unlink）するか、或いは、（もし、そのリンク・カウントが１であるならば）それを、オーファン（orphan）ディレクトリに再命名し、新しい名称を、指定された（specified）オブジェクトへのリンクとして生成する。次に、もし、それが、指定されたオブジェクトへのリンクであるならば、システムは古い名称を除去する。復旧の終了において、システムは、オルファン・ディレクトリから全ての名称を除去する。
【００５４】
”delete”に対しては、システムは、”rename”に対する場合のように、もしＩＦＩＤが一致するならば指定された名称を除去するが、もしリンク・カウントが１であるならば、それをオーファン・ディレクトリに再名称付けするように、進行させ得る。
一旦、全ての作動の状態が決定されると、通常の作動が再開する。
【００５５】
２．分散された復旧
マルチプルのバック・エンド要素が、所定のｄＶＦＳインスタンスに参加するときに、復旧は、１つより多いバック・エンド要素に適用される作動を調整（reconcile）する。完全な（complete）作動が、少なくとも１つのバック・エンド要素に記憶されるやいなや、ｄＶＦＳは、作動が永続的であると考えるので、各バック・エンド要素は、その作動の１つによって影響を受けた他の”バック・エンド”が、作動のコピーを持つことを保証しなければならない。そのローカル・ログを復旧させた後に、各バック・エンドは、各々の他のバック・エンドに、それが復旧を行っている対象である作動識別子（フロント・エンドによって設定された、フロント・エンド識別子、及び、シーケンス番号の組からなる）のリストを送ることによってこれを取り扱う。この作動識別子は、他のバック・エンドの作動識別子にも適用される。他のバック・エンドは次に、それが持たない何らかののコンテンツを要求（ask for）し、それらを、そのログに加える。このポイントで、各ログは、関連する作動の完全な組を持つ。（欠けている作動は、勿論、配送されるときに”未完了”とマーキングされている。）
【００５６】
次のステップは、未だ知られていない何らかの作動（主に、”共有書き込み(shared write)”首尾一貫モード（coherency mode）に起因する並行書き込みである）に対する一連の順序を解明（resolve）することである。上述のように通常の作動の一部として取り扱われたそのステップの後に、各バック・エンドは、通常の作動を自由に再開する。
【００５７】
Ｈ．複製（replication）
ｄＶＦＳ110は、同じ作動を、マルチプルの場所で適用することをサポートできるので、ファイル・システム複製は、ｄＶＦＳ作動の固有の部分であり得る。図３は、如何にして、本システムにおいてファイル・システム作動が起こり得るかについての、１つの例を示す。システム100から、遠隔システム200に、作動ログ・エントリーのストリームを送信し、それらをそこで適用することによって、遠隔システム200は、ローカル・システム100の無矛盾のコピーとなる。システムは、同期複製か、非同期複製かのいずれかを採用し得る。もし、システムが、作動が完了した（complete）と考えられる前に、遠隔システム200によって、作動が永続的であるとして応答される（acknowledged）まで待つならば、複製は同期的である。もしシステムが待たないならば、複製は非同期的である。後者の場合には、遠隔サイト200は、依然として無矛盾となるが、過去の、わずかな時間幅（amount）におけるポイントを反映することになる。
【００５８】
主要な観測は、複製のためのこのアプローチが、遠隔システム200に送られる情報の量を最小化させるということである。これは、（帯域幅制限に起因する）待ち時間を削減し、それ故、ボリューム・レベル（論理ファイル・システムの下位）における複製に比較して、性能を増加させる。この、ボリューム・レベルにおいては、ファイル名又はファイル属性（attributes）に対する数バイトだけでなく、論理ファイル・システムのメタデータ・ブロック全体が、一般的にコピーされねばならない。
【００５９】
更に、作動は、論理的に、独立の作動の組に隔離され得るので、もし、作動が、矛盾（conflict）しないならば、各サイトが、時間の流れの中の所定のポイントにおいて、外されたプール（disjoint pools）から新しいＥＦＩＤを割り当てる限り、同じファイル・システム内で、サイトＡからサイトＢに複製された１つの組のファイル、及び、サイトＡからサイトＢに複製された第２の組のファイルが得られる。これは、次に、ファイルの所定の組の制御の主位置（primary locus）が、オーナーシップ・リクエストの単純な交換を介して、サイトＡからサイトＢに移動し（migrate）、作動ログ・ストリームに埋め込まれた作動を許与（grant）することを可能とする。作動ログは、全ての作動を直列化するので、そのような移動（migration）は、非同期複製の場合でさえも動く（works）。これは、関係するサイトが、長距離によって分離され、光速に起因する待ち時間が大きいときに、一般的に要求される場合と同様である。
【００６０】
複製が、１つから多数に、多数から１つに、又は、多数から多数に、行われ得ることに留意して欲しい。これらのケースは、所定のリクエストのストリームに対する別個の宛先の数によってのみ区別される。
【００６１】
復旧は、たとえ、”複製（replica）”サイトが利用不可能であっても、所定のファイルの組に対する”ソース”サイトが、通常の作動と共に進行し得ることを除いて、完全に、ローカルの、マルチプルのバックエンド・インスタンスのケースと同様に進行する。その場合には、複製サイトが利用可能となるときに、欠けている（missing）作動は、複製（replica）に転送され（shipped）、次に、通常の作動が再開される。もし、複製が、余りにも多くの状態（state）を失ったならば、復旧は、先行Agami出願に記載された分散されたＲＡＩＤの場合（新しい作動を転送する一方、全てのファイルが転送され、全ての作動が、複製において適用されるまで、全てのファイルをコピーし、新しい作動を、既に転送された何らかのファイルに適用する）と同様に進行する。過剰な（excessive）状態の損失は、複製のＰＩＬ内の最も新しいエントリが、ソースのＰＩＬ内の、より古いエントリより古いときに検知される。状態の過剰な損失は、ディスク上のより古いＰＩＬエントリをバッファリングすることによって、ソースにおいて遅延され得る（それらが、後に、複製の復旧の一部として読み返され得るように）。
【００６２】
本発明が、特に、その模範的実施例を参照して説明されてきたが、当業者にとって、本発明の思想及び範囲から離れることなしに、形式及び細部における変更及び修正が為され得ることが完全に明白である。添付の請求項は、そのような変更と修正を含むことが意図される。当業者にとって、種々の実施例が、必ずしも排他的（exclusive）でなく、本発明の思想と範囲を維持しつつ、いくつかの実施例の特徴が他の実施例の特徴と結合され得ることが更に明白である。
【図面の簡単な説明】
【００６３】
【図１】本発明による、分散された仮想ファイル・システムを取り込んだ記憶システムのブロック図である。
【図２】本発明による、フロントエンド要素とバックエンド要素の間のファイル・システムの通信を説明する模範的なブロック図である。
【図３】本発明による、ファイル・システム複製を説明する模範的ブロック図である。
【符号の説明】
【００６４】
１００  記憶システム
１０２  遠隔クライアント
１０４  システムス・マネジメント・サーバ（ＳＭＳ）プロセス
１０６  ライフ・サポート・サービス（ＬＳＳ）プロセス
１１２  ネットワーク・データ・マネジメント・プロトコル（ＮＤＭＰ）
１１４  ネットワーク・ファイル・システム（ＮフＳ）
１１６  共通インターネット・ファイル・システム（ＣＩＦＳ）プロトコル
１２４  ローカル・ファイル・システム
１２６  SnapＶＦＳ
１２８  ジャーナルド・ファイル・システム（ＸＦＳ）
１３０  記憶ユニット
２００  遠隔システム
２００Ａ  ｄＶＦＳフロント・エンド要素
２００Ｂ  ｄＶＦＳフロント・エンド要素
２２８Ａ  ＸＦＳ
２２８Ｂ  ＸＦＳ
２２９Ａ  ボリューム・マネジャ
２２９Ｂ  ボリューム・マネジャ
２３０Ａ  記憶装置又はディスク
２３０Ｂ  記憶装置又はディスク
２５０Ａ  ローカル・インテント・ログ
２５０Ｂ  ローカル・インテント・ログ
２６０Ａ  ＰＩＬ
２６０Ｂ  ＰＩＬ
２７０Ａ  ロック・マネジャ（lock manager）
２７０Ｂ  ロック・マネジャ（lock manager）
【図１】
2008502078.tif 000003
【図２】
2008502078.tif 000004
【図３】
2008502078.tif 000005
【国際調査報告】
2008502078.tif 000006