(57)【特許請求の範囲】
【請求項１】
少なくとも１つのコンピュータシステム上のファイルを維持する方法であって、
ファイルシステム上の第１のファイルについての第１ファイルシステム動作を実行する第１要求を、前記ファイルシステムで受け取るステップであって、前記第１要求は、該第１要求がプログラムにより特定されたトランザクションに関連することを前記ファイルシステムに示すデータを含む、第１要求を受け取るステップと、
前記第１ファイルシステム動作を実行するステップと、
前記ファイルシステム上の第２のファイルについての第２ファイルシステム動作を実行する第２要求であって、前記トランザクションに関連する第２要求を前記ファイルシステムで受け取るステップと、
前記第２ファイルシステム動作を実行するステップと、
前記第１ファイルシステム動作および前記第２ファイルシステム動作が前記トランザクションに関連することを示す、前記ファイルシステム内の情報を維持するステップと、
前記トランザクションがコミットされる場合に、前記第１ファイルシステム動作および前記第２ファイルシステム動作をコミットするステップと
を備えることを特徴とする方法。
【請求項２】
前記ファイルシステムで、前記トランザクションがコミットしたことを示す情報を受け取るステップとをさらに備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記トランザクションがコミットされない場合に、前記第１ファイルシステム動作を元に戻すことを特徴とする請求項１に記載の方法。
【請求項４】
前記第１ファイルシステム動作は、ファイルの作成を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記第１ファイルシステム動作は、ファイルの削除を含むことを特徴とする請求項１に記載の方法。
【請求項６】
前記第１ファイルシステム動作は、ファイル名の変更を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記第１ファイルシステム動作に対応する情報を少なくとも１つのログに記録するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記トランザクションがコミットされない場合に、前記少なくとも１つのログにアクセスすること、および、前記少なくとも１つのログ内の前記情報に基づいて前記第１ファイルシステム動作を元に戻すことを特徴とする請求項７に記載の方法。
【請求項９】
前記トランザクションが中断したことを示す情報を前記ファイルシステムで受け取るステップと、それに応答して、前記第１ファイルシステム動作を元に戻すステップとをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１０】
前記第１ファイルシステム動作をコミットするステップは、前記第１ファイルシステム動作が前記トランザクションに関連することを示す情報を変更するステップを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記第１ファイルシステム動作は、ファイルのオープンを含むことを特徴とする請求項１に記載の方法。
【請求項１２】
前記トランザクションに関連するファイルのバージョンを維持するステップをさらに備えることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記第１要求がトランザクションに関連することを前記ファイルシステムに示すデータは、要求パケット内のフラグを含むことを特徴とする請求項１に記載の方法。
【請求項１４】
前記第１要求がトランザクションに関連することを前記ファイルシステムに示すデータはコンテキストを含み、前記ファイルシステムは、前記コンテキスト内のデータを使用して前記第１の要求を前記トランザクションと関連づけることを特徴とする請求項１に記載の方法。
【請求項１５】
前記コンテキストはスレッドに関連することを特徴とする請求項１４に記載の方法。
【請求項１６】
前記コンテキストはプロセスに関連することを特徴とする請求項１４に記載の方法。
【請求項１７】
前記第１の要求がトランザクションに関連することを前記ファイルシステムに示すデータは、前記第１のファイルのファイルハンドルに関連するコンテキストを含むことを特徴とする請求項１に記載の方法。
【請求項１８】
前記ファイルシステムは第１のネットワークコンピュータ装置および第２のネットワークコンピュータ装置上に分散して存在し、
前記第１のファイル、および前記第１ファイルシステム動作が前記トランザクションに関連することを示す情報は前記第１のネットワークコンピュータ装置内に保持され、
前記第２のファイル、および前記第２ファイルシステム動作が前記トランザクションに関連することを示す情報は前記第２のネットワークコンピュータ装置内に保持され、
前記第１ファイルシステム動作は第１のネットワークコンピュータ装置で実行され、前記トランザクションに関連する第２のファイルシステム動作は、前記第１のネットワークコンピュータ装置から送信された前記第２要求に応答して前記第２のネットワークコンピュータ装置で実行されることを特徴とする請求項１に記載の方法。
【請求項１９】
コンピュータ環境において、
ファイルシステムにおいて、第１のファイルおよび該第１のファイルに関して実行するための要求された動作に対応する第1の要求を受け取るステップであって、前記第１の要求は、該第１の要求がプログラムにより特定されたトランザクションに関連することを前記ファイルシステムに示すデータと関連する、第１の要求を受け取るステップと、
前記ファイルシステムにおいて、前記第１のファイルが前記トランザクションに関連することを認識するステップと、
前記第１のファイルに対し前記要求された動作の実行を試みるステップと、
前記ファイルシステムにおいて、第２のファイルおよび該第２のファイルに関して実行するための要求された動作に対応する第２の要求を受け取るステップであって、前記第２の要求は、該第２の要求が前記第１のファイルにも関連するトランザクションに関連することを前記ファイルシステムに示すデータに関連する、第２の要求を受け取るステップと、
前記ファイルシステムにおいて、前記第２のファイルが前記トランザクションに関連することを認識するステップと、
前記第２のファイルに対し前記要求された動作の実行を試みるステップと、
前記第１のファイル上で試みられた前記要求された動作または前記第２のファイル上で試みられた前記要求された動作が失敗した場合、または両方とも失敗した場合、前記ファイルシステムにおいて、成功裡に実行された前記トランザクションに関連する全てのファイルシステム動作を取り消すステップと
を備えることを特徴とする方法。
【請求項２０】
前記第１および第２の動作は成功裡に実行され、前記ファイルシステムにおいて、前記トランザクションがコミットされたことを示す情報を前記ファイルシステムにおいて受け取り、これに応答して、前記第１および第２の動作をコミットするステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記第１および第２の動作は成功裡に実行され、前記ファイルシステムにおいて、前記トランザクションが中止されたことを示す情報を前記ファイルシステムにおいて受け取り、これに応答して、前記第１および第２の動作を取り消すステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項２２】
前記ファイルシステム動作は、ファイルを作成することを含み、前記第１のファイルが前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップは、フラグを判断するステップを含むことを特徴とする請求項１９に記載の方法。
【請求項２３】
前記第１のファイルが前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップは、前記第１のファイルに対応するファイルハンドルに関連するコンテキストを判断するステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項２４】
前記第1のファイルシステム動作に対応する情報をログに記録するステップをさらに備えることを特徴とする請求項１９に記載の方法。
【請求項２５】
前記第１の動作は成功裡に実行され、前記第1のファイルシステム動作を取り消すステップは、前記ログ内の情報を読み出すステップをさらに備えることを特徴とする請求項２４に記載の方法。
【請求項２６】
コンピュータ環境において、
ファイルシステムにおいて第１の要求を受け取るステップであって、前記第１の要求は第１のファイルおよび該第１のファイルに関して実行するための要求された動作に対応し、前記第１の要求は、該第１の要求がプログラムにより特定されたトランザクションに関連することを示す第１の要求に関連するデータを有する、第１の要求を受け取るステップと、
前記ファイルシステムにおいて、前記第１のファイルが前記トランザクションに関連することを認識するステップと、
前記第１のファイルに対し前記要求された動作を実行するステップと、
前記ファイルシステムにおいて第２の要求を受け取るステップであって、前記第２の要求は第２のファイルおよび該第２のファイルに関して実行するための要求された動作に対応し、前記第２の要求は、該第２の要求がトランザクションに関連することを示す第２の要求に関連するデータを有する、第２の要求を受け取るステップと、
前記ファイルシステムにおいて、前記第２のファイルが前記第１のファイルにも関連するトランザクションに関連することを認識するステップと、
前記第２のファイルに対して前記要求された動作を実行するステップと、
前記トランザクションが成功裡にコミットされたか否かに関する情報を前記ファイルシステムにおいて受け取り、前記トランザクションが成功裡にコミットされた場合、前記第１および第２のファイルシステム動作をコミットするステップと、
前記トランザクションが成功裡にコミットされなかった場合、前記第１および第２のファイルシステム動作を取り消すステップと
を備えることを特徴とする方法。
【請求項２７】
前記第１のファイルおよび前記第２のファイルは共通のディレクトリ内に作成され、前記第１および第２のファイルが前記トランザクションに関連することを認識するステップは、前記共通のディレクトリに関連するデータを認識するステップを含むことを特徴とする請求項２６に記載の方法。
【請求項２８】
前記第１のファイルおよび前記第２のファイルは共通のスレッドにより作成され、前記第１および第２のファイルが前記トランザクションに関連することを認識するステップは、前記共通のスレッドに関連するデータを認識するステップを含むことを特徴とする請求項２６に記載の方法。
【請求項２９】
前記第１のファイルおよび前記第２のファイルは共通のプロセスにより作成され、前記第１および第２のファイルが前記トランザクションに関連することを認識するステップは、データが前記共通のプロセスに関連するデータを認識するステップを含むことを特徴とする請求項２６に記載の方法。
【請求項３０】
前記第１のファイルは、前記第１の要求に関連するデータを使用して、前記第１のファイルが前記トランザクションに関連すべきであることを前記ファイルシステムに知らせる機能により作成されることを特徴とする請求項２６に記載の方法。
【請求項３１】
前記第１のファイルが前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップは、前記第１のファイルに対応するファイルハンドルに関連するコンテキストを判断するステップを含むことを特徴とする請求項２６に記載の方法。
【請求項３２】
コンピュータ環境において、
ファイルシステムにおいて、実行するための要求された動作に対応する第１の要求を受け取るステップであって、前記第１の要求は、該第１の要求がプログラムにより特定されたトランザクションに関連することを前記ファイルシステムに示すデータに関連する、第１の要求を受け取るステップと、
前記第１の要求が前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップと、
前記ファイルシステムにおいて、実行するための要求された動作に対応する第２の要求を受け取るステップであって、前記第２の要求は、該第２の要求が前記第１の要求にも関連するトランザクションに関連することを前記ファイルシステムに示すデータに関連する、第２の要求を受け取るステップと、
前記第２の要求が前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップと、
前記第２の要求された動作を実行するステップと、
前記トランザクションが中止すると、前記ファイルシステムにおいて前記トランザクションに関連する全ての実行されたファイルシステム動作を取り消すステップと
を備え、前記第１の要求は第１のファイルに対応し、前記第２の要求は第２のファイルに対応することを特徴とする方法。
【請求項３３】
前記ファイルシステムにおいて、前記トランザクションがコミットされたことを示す情報を受け取り、これに応答して、前記第１および第２の動作をコミットするステップをさらに備えることを特徴とする請求項３２に記載の方法。
【請求項３４】
前記第１のファイルシステム動作は第１のファイルを作成することを含み、前記第１の要求がトランザクションに関連することを前記ファイルシステムにおいて認識するステップは、フラグを判断するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項３５】
前記第１の要求が前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップは、前記第１のファイルに対応するファイルハンドルに関連するコンテキストを判断するステップを含むことを特徴とする請求項３４に記載の方法。
【請求項３６】
前記第１のファイルシステム動作に対応する情報をログに記録するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項３７】
前記第１のファイルシステム動作を取り消すステップは、前記ログ内の情報を読み出すステップを含むことを特徴とする請求項３６に記載の方法。
【請求項３８】
前記第１のファイルおよび第２のファイルは共通のディレクトリ内に作成され、前記第１および第２の要求が前記トランザクションに関連することを認識するステップは、前記共通のディレクトリに関連するデータを認識するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項３９】
前記第１のファイルおよび第２のファイルは共通のスレッドにより作成され、前記第１および第２の要求が前記トランザクションに関連することを認識するステップは、前記共通のスレッドに関連するデータを認識するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項４０】
前記第１のファイルおよび第２のファイルは共通のプロセスにより作成され、前記第１および第２の要求が前記トランザクションに関連することを認識するステップは、前記共通のプロセスに関連するデータを認識するステップを含むことを特徴とする請求項３２に記載の方法。
【請求項４１】
前記第１のファイルは、第１の要求に関連するデータを使用して前記第１のファイルが前記トランザクションに関連すべきであることを知らせる機能により作成されることを特徴とする請求項３２に記載の方法。
【請求項４２】
前記第１のファイルが前記トランザクションに関連することを前記ファイルシステムにおいて認識するステップは、前記第１のファイルに対応するファイルハンドルに関連するコンテキストを判断するステップを含むことを特徴とする請求項３２に記載の方法。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、一般的にコンピュータシステムおよびファイルシステムを対象とする。
【０００２】
（発明の背景）
通常のファイルシステムは、ファイルまたはディレクトリの新規作成、ファイルまたはディレクトリの削除または名前の変更、およびファイル内容の操作を含む、ファイル階層を操作する機構を提供する。特定のファイルシステムは、単一の下位動作すなわちプリミティブの完了に関するある保証を提供する。たとえば、ファイルを新規作成するプリミティブは、成功裡に完了するか、またはそのファイル作成動作の何らかの部分的な効果がシステムによって元に戻される（アンドゥされる）かのいずれかになる。
【０００３】
しかし、ユーザレベルでの複数のファイルシステム動作は、ファイルシステム内で一緒に結びつけられない可能性がある。たとえば、現在、ファイルシステムが、４つのファイルを作成し、３つの他のファイルを削除し、もう１つのファイルの名前を変更するが、これらの動作のどれかが失敗した場合に、他の動作のいずれかを元に戻す方法はない。その結果、アプリケーションなどの上位（ユーザレベル）処理が、そのような複数の動作の管理すなわち、どのアクションをどのファイルおよび／またはディレクトリに適用するかをファイルシステムに指定するのに使用される。
【０００４】
しかし、この解決策にはそれ自体の短所がある。ウェブサイトが、一貫したルックアンドフィールをサイトに与える形で互いにリンクされた２０個のウェブページを有する例を検討する。サイトの更新中に、システムに障害が発生し、一貫性のない状態が引き起こされる可能性がある。たとえば、更新を実行するアプリケーションが、障害の時点で、一部のファイルを削除し終えたが、これらのファイルをポイントしていた他のファイルからのリンクを削除していない場合がある。このサイトを見るユーザは、ウェブページの一部を見るが、削除されたページへのリンクをクリックした時にエラーメッセージを受け取る。
【０００５】
一貫性のない状態で終わる可能性に対して保護するためには、ウェブページファイル階層全体を、階層内のファイルを変更する前に普通にコピーする。障害の場合に、保存された階層をコピーバックする。しかし、このファイルのコピーは低速であり、コピープログラムが、システムのどの部分が更新されるかを事前に知る必要があり、ファイルのどれかが偶然にコピーされない場合に回復不能になるので、エラーになりやすいという点で比較的ぎこちない。
【０００６】
ファイルが定位置で変更される場合、上位処理を使用してファイルを更新する時に、進行中のどんな変更も、サイトを見るユーザに可視になる。たとえば、上で説明したウェブサイトでは、どんな変更も、ファイル（および名前階層）がアプリケーションによって変更されている間に、システムの既存のユーザに可視になる。システム状態は、通常、すべての変更が行われるまでは一貫性がないので、ユーザは、その一貫性のなさを見る可能性がある。たとえば、既存のユーザが、ウェブページ内のリンク（ＵＲＬ）を見、それをクリックし、削除されたページで終わる場合があり、これは、アプリケーションがページを削除したが、そのページをポイントするリンクをまだ除去していない時に発生するイベントである。
【０００７】
ウェブページ更新のほかに、他のプログラムが、一貫性のある形で情報を保存する能力を同様に制限される。たとえば、通常のワードプロセッサアプリケーションまたはスプレッドシートアプリケーションは、システム障害の後に発生する可能性がある一貫性のない状態を回避するために、一時ファイルを使用して、名前の変更動作および削除動作によって完全な保存を実行する。そのようなアプリケーションが、異なるデータソースにまたがって情報を分配しようとする場合もある。たとえば、アプリケーションが、表データをＳＱＬ  Ｓｅｒｖｅｒに保管し、ファイルをファイルサーバおよび／またはインターネットサーバに保管しようとする場合があり、たとえば、そのようなファイルに、ワードプロセッサ文書、プレゼンテーションチャート、および／またはウェブページが含まれる場合がある。しかし、調整され統一された形でのそのような情報の保存をサポートする機構は、現在存在しない。たとえば、そのような情報の保存中にシステムが障害を発生する場合に、情報の一部が保存されるが、それ以外は保存されず、やはり一貫性のない状態につながる。
【０００８】
（発明の概要）
簡単に言えば、本発明は、それを介して複数のファイルシステム動作を単一のユーザレベルトランザクションの一部として実行することができる、システムおよび方法を提供する。本発明のトランザクショナルファイルシステムは、ユーザが、ファイルシステム内のトランザクションのスコープおよび期間を選択的に制御できるようにする。
【０００９】
ファイルのオープン中または作成中に、アプリケーションが、そのファイルオープンのインスタンスに対する動作がトランザクションの一部として扱われなければならないかどうかを指定する。さらに、このシステムは、トランザクショナルに操作することだけができるファイルを永続的にマークする能力を提供し、アプリケーションは、オープン／作成時にグローバル一意ｉｄ（ＧＵＩＤ）を介してトランザクションを指定する。新規ファイル作成に関して、親ディレクトリが、被トランザクションとしてマークされ、アプリケーションは、トランザクションをスレッド／プロセスに関連付けることができ、これによって、そのようなスレッド／プロセスによるファイル操作が、指定されたトランザクションのコンテキスト内でトランザクション処理される。さらに、アプリケーションは、子スレッド／プロセスがトランザクションコンテキストを継承することをシステムに指示する（たとえばＡＰＩを介して）ことを選択することができ、アプリケーションが、アプリケーションソースコードに対する大きい変更なしで、トランザクションを利用できるようになる。
【００１０】
ファイルがトランザクション的にオープンされた後に、このシステムは、ファイルのハンドルに対する読取、書込、削除、または名前の変更などの動作を、トランザクションの一部として自動的に含める。その結果、アプリケーションは、既存のファイルシステムＡＰＩを呼び出し、既存の動作単位のセマンティクスを見続け、なおかつトランザクションの一部として動作を含めることができる。アプリケーションは、使いたいだけいくつでもトランザクションを使用することができ、他のアプリケーションとトランザクションを共有することができ、望みの数のスレッド／プロセスにトランザクションを共有させることなどができる。トランザクションは、異なるコンピュータに常駐するファイルに関して行われるファイルオープンの際に指定することができる。
【００１１】
本発明の他の態様は、障害が発生したトランザクションからの回復可能性を使用可能にするためのログ記録を対象とする。トランザクションの下で、システムによって行われる変更は、システム障害およびアプリケーション障害を含むなんらかの理由でトランザクションに障害が発生した場合に元に戻され、そのトランザクションに関してシステムによって行われる変更は、システムがアプリケーションの代わりにトランザクションを成功裡にコミットする場合に、システム障害（たとえば停電）に耐えることが保証される。これは、複数レベルログ記録機構と、より下位のログ記録される動作が成功裡にコミットされたかどうかを判定し、これによって、より上位のログ記録される動作が実際に発生したかどうかを判定する機構とを介して達成される。
【００１２】
データ変更は、動作イベントを１つのログに、また、トランザクションの実際のデータ書込の詳細を別のログ、たとえばページストリームに分離することによってもログ記録される。ある機構がログ記録された署名を書き込み、後でログ記録されたレコードおよびデータの両方と比較して、ログ記録されたレコードがそれに対応するデータページと同期化されているかどうかを判定し、ログがデータに関して特定の順序でディスクに書き込まれるという要件をなくす。
【００１３】
本発明の他の態様には、トランザクションおよび他のファイルシステム動作の間での名前空間およびファイルデータの分離の提供が含まれる。名前空間分離は、どの名前がどのトランザクションに属するかを追跡する分離ディレクトリの使用によって達成される。その結果、変更するトランザクションがまだアクティブである間、所与のトランザクションについてシステムによって行われる変更のどれもが他のトランザクションにとって不可視になり、変更するトランザクションが成功裡にコミットした後に限って可視になる。トランザクション非対応ファイルハンドルは、変更が起きた時にその変更を見る。したがって、第１トランザクション中に削除されるファイルは、もはやその第１トランザクションまたは非トランザクションによって見られなくなるが、第１トランザクションが完了するまでは、他のトランザクションから可視のままになる。
【００１４】
そのような名前空間分離を達成するために、元のＮＴＦＳディレクトリにリンクされた分離ディレクトリが作成され、通常のＮＴＦＳ親ディレクトリではなく、分離ディレクトリに適当なファイル名が追加される。たとえば、削除動作に関して、削除されるファイルの名前が、そのファイルがＮＴＦＳ親ディレクトリから除去されるのと同時に、分離ディレクトリに追加される。コミットの前には、異なるトランザクションによるこのファイルへの後続アクセスが、分離ディレクトリを使用してサービスされ、これによって、そのファイルが見つかり、削除されていないとみなされる。同様に、トランザクションがファイルを作成する場合に、その名前が、ＮＴＦＳディレクトリならびに親ＮＴＦＳディレクトリにリンクされた分離ディレクトリに追加される。そのファイルを作成したトランザクションは、そのファイルを見るが、他のトランザクションにとって、その名前は、ファイルのオープンまたは親ＮＴＦＳディレクトリのリスティングに関してフィルタアウトされる。分離ディレクトリエントリは、トランザクションがコミットするか中断する時に、分離ディレクトリから除去される。
【００１５】
したがって、本発明は、トランザクション機構をファイルシステムに組み込み、アプリケーションが１つまたは複数のファイルに対して複数のトランザクショナル動作を簡単に実行できるようにし、外部トランザクション機構に関連する問題を克服する。このようにして、複数のファイルシステム動作を、ファイルシステム内でトランザクション的な形で一緒に結び付け、動作が一緒にコミットされるか、部分的なアクションのいずれもが元に戻されるかのどちらかになるようにする。さらに、１つのトランザクションの動作およびデータ変更が、別のトランザクションの動作およびデータから分離される。
【００１６】
他の長所は、図面と共に下の詳細な説明を考慮することから明白になる。
【００１７】
（発明の詳細な説明）
例示的オペレーティング環境
図１および以下の説明は、本発明を実施することができる適当なコンピューティング環境の短い一般的な説明を提供することを意図されたものである。必要ではないが、本発明を、プログラムモジュールなどのパーソナルコンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で説明する。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造体、および、特定のタスクを実行するかまたは特定の抽象データ型を実施する類似物が含まれる。
【００１８】
さらに、当業者は、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルな消費者電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および類似物を含む、他のコンピュータシステム構成を用いて本発明を実践できることを諒解するであろう。本発明は、通信ネットワークを介してリンクされたリモート処理装置によってタスクが実行される分散コンピューティング環境でも実践することができる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリストレージデバイスに配置することができる。
【００１９】
図１を参照すると、本発明を実施する例示的システムに、普通のパーソナルコンピュータ２０または類似物の形の汎用コンピューティングデバイスが含まれ、このパーソナルコンピュータ２０には、処理ユニット２１、システムメモリ２２、および、システムメモリを含むさまざまなシステム構成要素を処理ユニット２１に結合するシステムバス２３が含まれる。システムバス２３は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを含む、複数のタイプのバス構造のいずれかとすることができる。システムメモリには、読取専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５が含まれる。起動中などにパーソナルコンピュータ２０内の要素の間の情報の転送を助ける基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）が、ＲＯＭ２４に保管される。パーソナルコンピュータ２０には、さらに、図示されないハードディスクから読み取り、これに書き込むハードディスクドライブ２７、取外し可能磁気ディスク２９から読み取り、これに書き込む磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光学媒体などの取外し可能光ディスク３１から読み取り、これに書き込む光ディスクドライブ３０が含まれる。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光学ドライブインターフェース３４によってシステムバス２３に接続される。ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造体、プログラムモジュール、およびパーソナルコンピュータ２０の他のデータの不揮発性ストレージを提供する。本明細書で説明する例示的実施形態ではハードディスク、取外し可能磁気ディスク２９、および取外し可能光ディスク３１が使用されるが、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、および類似物などの、コンピュータによってアクセス可能なデータを保管することができる他のタイプのコンピュータ可読媒体を、例示的動作環境で使用できることを、当業者は諒解するであろう。
【００２０】
オペレーティングシステム３５（好ましくは、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎ社のＷｉｎｄｏｗｓ（登録商標）２０００、旧称Ｗｉｎｄｏｗｓ（登録商標）ＮＴ）を含む複数のプログラムモジュールを、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４、またはＲＡＭ２５に保管することができる。コンピュータ２０には、Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）ファイルシステム（ＮＴＦＳ）などの、オペレーティングシステム３５に関連するか含まれるファイルシステム３６、１つまたは複数のアプリケーションプログラム３７、他のプログラムモジュール３８、およびプログラムデータ３９が含まれる。ユーザは、キーボード４０およびポインティングデバイス４２などの入力デバイスを介してパーソナルコンピュータ２０にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナ、または類似物を含めることができる。これらおよび他の入力デバイスは、しばしば、システムバスに結合されるシリアルポートインターフェース４６を介して処理ユニット２１に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ  ｓｅｒｉａｌ  ｂｕｓ（ＵＳＢ）などの他のインターフェースによって接続することができる。モニタ４７または他のタイプのディスプレイデバイスも、ビデオアダプタ４８などのインターフェースを介してシステムバス２３に接続される。モニタ４７のほかに、パーソナルコンピュータには、通常は、スピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）が含まれる。
【００２１】
パーソナルコンピュータ２０は、リモートコンピュータ４９などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ４９は、もう１つのパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、メモリストレージデバイス５０だけが図１に示されているが、通常は、パーソナルコンピュータ２０に関して上で説明した要素の多数またはすべてが含まれる。図１に示された論理接続には、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２が含まれる。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【００２２】
ＬＡＮネットワーキング環境で使用される時には、パーソナルコンピュータ２０は、ネットワークインターフェースまたはネットワークアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境で使用される時には、パーソナルコンピュータ２０に、通常はモデム５４または、インターネットなどの広域ネットワーク５２を介する通信を確立する他の手段が含まれる。モデム５４は、内蔵または外付けとすることができるが、シリアルポートインターフェース４６を介してシステムバス２３に接続される。ネットワーク化された環境では、パーソナルコンピュータ２０に関して図示されたプログラムモジュール、またはその一部を、リモートメモリストレージデバイスに保管することができる。図示のネットワーク接続が、例示的であり、コンピュータの間で通信リンクを確立する他の手段を使用することができることを諒解されたい。
【００２３】
本発明を、Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティングシステムおよびＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）ファイルシステム（ＮＴＦＳ）に関して説明するが、当業者は、他のオペレーティングシステムおよび／またはファイルシステムを実施でき、本発明から利益を得ることができることを諒解するであろう。
【００２４】
トランザクショナルファイルシステムの一般的アーキテクチャ
一般に、本明細書で使用される用語「トランザクション」、「トランザクショナル」などは、本発明で複数のファイルシステム動作に適用される、ある共通のプロパティを有する動作を指す。トランザクショナルプロパティを、通常は「ＡＣＩＤ」プロパティと称し、これは、ａｔｏｍｉｃｉｔｙ（原子性）、ｃｏｎｓｉｓｔｅｎｃｙ（一貫性）、ｉｓｏｌａｔｉｏｎ（分離）、およびｄｕｒａｂｉｌｉｔｙ（耐久性）を表す。以下で理解されるように、本発明は、ファイルシステムと共同してこれらのプロパティを達成し、アプリケーションおよびコンピューティング一般に多数の利益をもたらす。
【００２５】
図２に一般的に示されているように、アプリケーション６０または類似物からＭｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）ファイルシステム（ＮＴＦＳ）３６（図１）などのトランザクション対応ファイルシステム６２（本発明に関して本明細書で説明される）に向けられたファイルシステム要求５８が、ディスパッチ機構６６を介してＮＴＦＳコンポーネント６４に達する。従来のファイルシステムに関して既知のように、たとえばＩ／Ｏ要求パケット（ＩＲＰ）がＩ／Ｏマネージャによってファイルシステムに送られることをもたらす可能性があるこれらの要求を生成するために、アプリケーション６０が、アプリケーションプログラミングインターフェース（ＡＰＩ）呼出しを行うことができる。本発明によれば、以下で説明するように、ファイルシステム要求５８のいくつかが、トランザクションに関連し、それ以外はそうでない可能性がある。
【００２６】
（発明の背景）
通常のファイルシステムは、ファイルまたはディレクトリの新規作成、ファイルまたはディレクトリの削除または名前の変更、およびファイル内容の操作を含む、ファイル階層を操作する機構を提供する。特定のファイルシステムは、単一の下位レベルの動作、すなわちプリミティブの完了に関する一定の保証を提供する。たとえば、ファイルを新規作成するプリミティブは、成功裡に完了するか、またはそのファイル作成動作の何らかの部分的な効果がシステムによって元に戻される（アンドゥされる）かのいずれかになる。
【００２７】
図２に示され、以下で説明されるように、ＴｘＦコンポーネント７０には、外部トランザクションサービス７２およびログ記録サービス７４へのインターフェースが含まれ、ＴｘＦコンポーネント７０は、ＮＴＦＳコンポーネント６４と共に働いて、トランザクショナル要求を処理する。外部トランザクションサービス７２には、クライアント（たとえばアプリケーション６０）が、トランザクションを開始するために呼び出し、後に、動作をコミットまたは中断するために呼び出す、Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎの分散トランザクションコーディネータ（ＭＳ  ＤＴＣ、または単にＭＴＣまたはＤＴＣ）を含めることができる。ＤＴＣは、明確に文書化され、短い要約およびＴｘＦ７０に関してそれが機能する範囲までを除いて、本明細書では詳細に説明しない。
【００２８】
一般に、図３に表されているように、ＭＳ  ＤＴＣでは、ＣＯＭ／ＯＬＥを介して、アプリケーション６０などのアプリケーションが、トランザクションコーディネータ７６（図３）のメソッドすなわち、ＢｅｇｉｎＴｒａｎｓａｃｔｉｏｎメソッドを呼び出すことによって、トランザクションを開始する。トランザクションコーディネータ７６は、ネットワーク内のトランザクションサーバまたはそのローカルプロキシとすることができる。この呼び出しによって、トランザクションを表すトランザクションオブジェクト／コンテキスト７８が作成される。その後、アプリケーション６０は、１つまたは複数のリソースマネージャを呼び出して、トランザクションの作業を行う。本発明では、ＴｘＦコンポーネント７０が、トランザクショナルファイルシステム動作に関するリソースマネージャとして働く。やはり図３に示され、以下で説明されるように、ファイルシステム６２へのＡＰＩ呼出し（たとえば、ＣｒｅａｔｅＦｉｌｅＥｘ  ８０および他のファイルシステム動作）によって、ＴｘＦコンポーネント７０へのコールアウトが生成される。
【００２９】
ファイルシステム６２へのアプリケーションの最初の呼出しで、ファイル、ディレクトリ、またはアプリケーションの現在のスレッド／プロセスが識別され、これにトランザクションコンテキスト７８を関連付けることができる。トランザクションコンテキストが関連付けられる場合に、ファイルシステム６２は、ＴｘＦ７０をコールアウトする。ＴｘＦ７０は、トランザクションの代わりの作業を初めて実行する時に、トランザクションコーディネータ７６を呼び出し、これによって、ＴｘＦ７０がこのトランザクションに用いられるリソースマネージャであることをトランザクションコーディネータ７６に知らせることによって、トランザクションに参加する。他のリソースマネージャ８４（たとえばデータベースコンポーネントの）が、トランザクションに同様に参加することができ、それによって、データベースの動作およびファイルシステムの動作を、同一のトランザクション内で一緒にコミット（または中断）できることに留意されたい。
【００３０】
ＴｘＦ７０が、図３に一般的に示されているように、ＩＴｒａｎｓａｃｔｉｏｎオブジェクト７８と共に来るトランザクション識別子（ＩＤ）を使用して、トランザクションに関する参加を必要とする時を判定するために、ＴｘＦコンポーネント７０のトランザクションマネージャ８２レイヤが、トランザクションＩＤのトランザクションテーブル８６内で維持される既知の参加しているトランザクションに対してＩＤを検査する。既にリストされている場合に、トランザクションＩＤおよびトランザクション参照が、Ｉ／Ｏ要求パケット（ＩＲＰ）で記録され、ＩＲＰが継続する。ＮＴＦＳでのＩＲＰの使用は、明確に文書化され、説明を簡単にするために本明細書では詳細に説明しない。しかし、トランザクションがテーブル８６にリストされていない場合には、ＴｘＦは、ＴｘＦ７０が、このトランザクションに関連付けられる必要があるリソースマネージャであることをトランザクションコーディネータ７６に通知し、参加したトランザクションのテーブル８６にトランザクション識別子を保管する。
【００３１】
具体的に言うと、トランザクションが、テーブル８６にリストされていない新規トランザクションである時に、トランザクションコーディネータ７６への参加が必要である。このために、ＴｘＦマネージャ８２は、プロキシ８８を使用して、ＯＬＥトランザクションまたは別のプロトコルを使用してトランザクションコーディネータ７６と通信する。本発明と共に使用するのに適する代替プロトコルおよび類似物には、ＸＡ（Ｘ／Ｏｐｅｎの）、ＴＩＰ（Ｔｒａｎｓａｃｔｉｏｎ  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、および／またはオペレーティングシステム内の固有のトランザクションコントロールが含まれる。ＣｒｅａｔｅＦｉｌｅＥｘ  ８０要求は、ＩＴｒａｎｓａｃｔｉｏｎオブジェクト７８を（たとえばＤＴＣのＩｔｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒメソッドを介して）バイトのフラットコレクションにマーシャリングする。参加が必要な場合には、これらのバイトが、プロキシ８８に送られ、プロキシ８８は、ＤＴＣのＩＴｒａｎｓａｃｔｉｏｎＲｅｃｅｉｖｅｒメソッドを呼び出して、参加に必要なＩＴｒａｎｓａｃｔｉｏｎオブジェクト７８を取り戻す。プロキシ８８は、ＤＴＣオブジェクトＩＴｒａｎｓａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃおよびＩＴｒａｎｓａｃｔｉｏｎＥｎｌｉｓｔｍｅｎｔＡｓｙｎｃを維持する。ＩＴｒａｎｓａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃは、トランザクションコーディネータ７６が２フェーズコミットを駆動するために呼び出すＴｘＦコールバックルーチンを実装し、参加呼出しと共に供給される。ＩｔｒａｎｓａｃｔｉｏｎＥｎｌｉｓｔｍｅｎｔＡｓｙｎｃは、ＩＲｅｓｏｕｒｃｅＭａｎａｇｅｒ：：ｅｎｌｉｓｔ（）によって返され、これには、２フェーズコミットコントロールの確認のためにＴｘＦ７０が呼び出すメソッドが含まれる。プロキシ８８は、ＩｔｒａｎｓａｃｔｉｏｎＲｅｓｏｕｒｃｅＡｓｙｎｃおよびＩｔｒａｎｓａｃｔｉｏｎＥｎｌｉｓｔｍｅｎｔＡｓｙｎｃのメソッドと、ＴｘＦコンポーネント８２とプロキシ８８との間の通信に関するファイルシステムコントロール（ＦＳＣＴＬ）ベースのリモートプロシージャコール（ＲＰＣ）との間の仲介物として働く。
【００３２】
ＴｘＦコーディネータプロキシに、ＤＴＣコーディネータプロセスと同一のプロセスで動作させることが実行可能であり、トランザクションマネージャをカーネル内に移動し、これによってプロセス切換えのオーバーヘッドを除去することも実行可能であることに留意されたい。ＤＴＣプロキシスタブをカーネル内に移動して、ユーザモードプロキシを作成する際のＴｘＦ作業の必要をなくし、これと同時に、ＴｘＦプロキシからトランザクションマネージャへの余分なプロセス切換えを除去することもできる。ＴｘＦプロキシは、ＴｘＦプロキシによる作業を必要とするＤＴＣコーディネータと同一プロセス内で動作することができるが、これは、前の解決策と同数のプロセス切換えを有することになる。
【００３３】
参加の後に、トランザクションが進行する際に、トランザクションコーディネータ７６は、トランザクションに参加したＴｘＦ７０（および、おそらくは、他のＴｘＦまたはデータベースリソースマネージャなど、他のリソースマネージャ８４）を含むリソースマネージャのそれぞれを記憶する。これによって、ファイルシステム情報もコミットするトランザクションの一部として、他の情報（たとえばデータベース情報）をコミットできるようになり、また、複数のトランザクション対応ファイルシステム（たとえばリモートマシン上の）ファイルを、同一のトランザクションの一部としてコミットできるようになることに留意されたい。
【００３４】
通常、アプリケーション６０は、トランザクションをコミットするためにトランザクションコーディネータ７６のＣｏｍｍｉｔトランザクションメソッドを（ＣＯＭを介して）呼び出すことによって、トランザクションを完了する。トランザクションコーディネータ７６は、２フェーズコミットプロトコルをすべて実行して、参加したリソースマネージャのそれぞれにコミットさせる。２フェーズコミットプロトコルによって、すべてのリソースマネージャがトランザクションをコミットするか、または中断することが保証される。第１フェーズで、トランザクションコーディネータ７６が、ＴｘＦコンポーネント７０を含むリソースマネージャのそれぞれに、コミットの準備ができているかどうかを尋ねる。リソースマネージャが肯定的に応答する場合に、第２フェーズで、トランザクションコーディネータ７６が、リソースマネージャにコミットメッセージをブロードキャストする。リソースマネージャのどれかが否定的に応答するか、または準備要求に応答できない場合、および／またはトランザクションの一部で障害が発生する場合に、トランザクションコーディネータ７６は、トランザクションが中断することをリソースマネージャに通知する。また、アプリケーションが完了できない場合に、アプリケーション６０が、Ａｂｏｒｔトランザクションメソッドを呼び出す。アプリケーションに障害が発生した場合には、トランザクションコーディネータ７６が、アプリケーションの代わりにトランザクションを中断する。その後、ＴｘＦ７０を含むさまざまなリソースマネージャが、以下で説明するように、部分的なアクションを元に戻す。
【００３５】
したがって、ＴｘＦコンポーネント７０は、標準トランザクションサービス（ＤＴＣなど）に関してリソースマネージャとして働き、これによって、真のユーザ定義トランザクションサポートが、ファイルシステムに拡張される。ＮＴＦＳを用いると、以下で説明するように、ＴｘＦが、過渡的なファイルごとおよびストリームごとのトランザクション状態を普通のＮＴＦＳ構造体にリンクできるようになることに留意されたい。
【００３６】
本発明の一態様によれば、アプリケーション６０は、トランザクションにファイルシステム動作を含めることを選択することができる。これは、ファイルがトランザクショナルとしてマークされ、それに対する動作がトランザクショナルに実行されるようにファイルごとに、または、スレッド／プロセスがトランザクショナルとしてマークされ、そのスレッド／プロセスによって行われる動作がトランザクショナルに実行されるスレッド／プロセスごとに、達成することができる。
【００３７】
トランザクションにファイルを含めるために、ＣｒｅａｔｅＦｉｌｅ  ＷＩＮ３２  ＡＰＩの変形であるＣｒｅａｔｅＦｉｌｅＥｘアプリケーションプログラミングインターフェース（ＡＰＩ）呼出し（以下で説明する）と共に使用することができるトランザクショナルモードフラグ（たとえばビット）を定義する。このフラグがセットされている時に、本発明のシステムは、このファイルを自動的にトランザクションコンテキストに含める。この目的のために、図３に一般的に示されているように、作成要求８０がＩ／Ｏ要求パケット（ＩＲＰ）を介してファイルシステム（ＮＴＦＳ）６２に来る時に、既存のトランザクションコンテキスト７８を、そのコンテキスト７８にポインタを渡すことによって要求にアタッチすることができ、これによって、ファイルを、既存のトランザクションコンテキスト７８の一部として作成／オープンできるようになる。その代わりに、ＣｒｅａｔｅＦｉｌｅＥｘ  ＡＰＩ呼出しのＩｔｒａｎｓａｃｔｉｏｎポインタへのポインタがＮＵＬＬである場合に、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ｔｒａｎｓａｃｔｉｏｎ  Ｓｅｒｖｅｒ（ＭＴＳ）／コンポーネントオブジェクトモデル（ＣＯＭ）のように、コンテキストがスレッドから自動的に選択される。成功裡の作成／オープン要求８０に応答して返されるファイルハンドル９０に、トランザクションコンテキスト７８へのポインタが含まれる。その後、そのハンドル９０を用いて行われる呼出しは、ポインタを介して、トランザクションコンテキストを関連付けられているものとして認識され、そのトランザクションコンテキストから関連するトランザクションが識別され、そのハンドルを使用するファイルシステム動作が、トランザクションが終了されるまでトランザクションの代わりに実行される。
【００３８】
ＣｒｅａｔｅＦｉｌｅＥｘ  ＡＰＩは、既存のＣｒｅａｔｅＦｉｌｅ  Ｗｉｎ３２  ＡＰＩの適当なスーパーセットであり、トランザクションモードをセットするためのフラグ「ＦＩＬＥ＿ＦＬＡＧ＿ＴＲＡＮＳＡＣＴＥＤ」をとる「ｄｗＡｄｄｉｔｉｏｎａｌＦｌａｇｓ」ＤＷＯＲＤパラメータが追加されている。また、トランザクションコンテキストオブジェクトをポイントすることができるパラメータ、ＬＰＵＮＫＮＯＷＮ  ｐｕｎｋＴｒａｎｓａｃｔｉｏｎも定義され、これがＮＵＬＬの場合には、上で説明したように、オブジェクトが現在のＭＴＳ／ＣＯＭコンテキストから選択される。
【００３９】
スレッド／プロセスをトランザクショナルとしてマークするために、ＳｅｔＴｒａｎｓａｃｔｅｄＦｉｌｅｓ  ＡＰＩが設けられ、このＡＰＩでは、ＣｒｅａｔｅＦｉｌｅ／ＣｒｅａｔｅＦｉｌｅＥｘ呼出しの組を、効果的にそれらがトランザクショナルモードフラグをセットされているかのように扱う。特定のＣｒｅａｔｅＦｉｌｅＥｘが、ヌルでないＩＴｒａｎｓａｃｔｉｏｎオブジェクトポインタを指定する場合には、そのオブジェクトが、トランザクションコンテキスト７８に使用され、そうでない場合には、ＭＴＳトランザクションオブジェクトが、スレッドから選択される。
【００４０】
ＳｅｔＴｒａｎｓａｃｔｅｄＦｉｌｅｓ  ＡＰＩは、スレッド／プロセスをトランザクショナルとしてマークし、これによって、そのスレッド／プロセスを介するすべてのファイルシステムアクセスをトランザクション処理するのに使用される。３つの異なるフラグをセットすることができる、すなわち、セットされた時に、現在のスレッドからのすべてのファイルシステムアクセスをトランザクション処理されるようにするフラグと、セットされた時に、現在のプロセス内のスレッドのそれぞれからのすべてのファイルシステムアクセスをトランザクション処理されるようにするフラグと、セットされた時に、現在のプロセスから作成された子プロセスがこれらのフラグのうちの第２および第３をセットされるようにするフラグである。したがって、スレッド／プロセスを、作成されるプロセスがこのモードを継承する形でマークすることが可能であり、これは、既存のアプリケーションがトランザクション処理されるＮＴＦＳを利用できるようになるので、非常に強力な機構である。さらに、これによって、アプリケーションが、トランザクショナルモードビットを有しない、ｄｅｌｅｔｅＦｉｌｅおよびｃｏｐｙＦｉｌｅなどのファイルシステム動作を行えるようになる。この特徴は、トランザクション処理されるコマンドラインバッチスクリプトを可能にするに使用することもできる。以下で、ＳｅｔＴｒａｎｓａｃｔｅｄＦｉｌｅｓ  ＡＰＩを説明する。
【００４１】
0004219589.tif 000002
【００４２】
正しいフラグ値は、次の通りである。
0004219589.tif 000003
【００４３】
図４に示されているように、作成／オープン以外のファイル動作について、アプリケーション６０は、たとえばファイル読取動作を要求するＡＰＩ呼出し９２を介して、ハンドル９０をファイルシステムに供給し、これによって、その中のトランザクションコンテキストポインタを介して、ファイルシステムが、トランザクションコンテキストを突き止めることができる。上で説明したように、ＴｘＦ７０がトランザクションに参加しなければならない場合があることに留意されたい。ファイルハンドル９０内でポイントされるトランザクションコンテキストのゆえに、ファイルシステムは、この動作がトランザクションに含まれることならびに特定の関連するトランザクションの識別子を知る。トランザクションコンテキストにファイルを含めることは、読取、書込、ファイル作成、および削除を含むファイルに対する動作がトランザクション処理されることを意味する。任意の数のファイルシステム要求を、単一のトランザクション内でグループ化し、原子的で耐久性がある形でコミットまたは中断することができる。さらに、どの瞬間でも、任意の数のトランザクションを進行中にすることができ、各トランザクションはお互いから分離される。
【００４４】
トランザクショナルアクセス−読取および書込の分離
上で説明したように、トランザクション処理されるアクセスに関してファイルをオープンまたは作成することができる。現在、率直で安全で予測可能な挙動をもたらすために、このシステムでは、システム内のアップデータ（ライタ）トランザクションの数を、すべての所与の時刻に１つに制限する、すなわち、複数のトランザクションが読取／書込（ＲＷ）アクセスのためにファイルを同時にオープンすることを試みる場合に、ファイルオープンの時にエラーが返される。したがって、これらの制約は、（ストリームレベルではなく）ファイルレベルに置かれる。この制約は、ファイルのコミットまたは中断まで、ファイルと共にとどまる。
【００４５】
しかし、より微細な粒度を有するシステムを実施することが、代替案として実行可能であり、たとえば、ファイルを複数のライタがオープンすることができるが、どのライタも、ファイル内の別のライタが書き込んだ（ダーティ）ページを上書きできない、すなわち、ページがダーティになった後に、そのページがロックされる。また、「ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ（最後のライタが有効）」タイプのアクセスを、ここで実施することができる。これらのタイプのファイル「書込」アクセスが、所与のシステムで相互排他的でないことに留意されたい。というのは、あるＡＰＩで、ファイル全体をロックする書込アクセス用にファイルをオープンし、もう１つのＡＰＩで、ページ（または他のファイルセクション）ごとのロックを有する書き込みアクセス用にファイル（その時点でロックされたファイルではない）をオープンし、かつ／またはもう１つのＡＰＩで、ｌａｓｔ−ｗｒｉｔｅｒ−ｗｉｎｓ書込アクセスを用いることが可能だからである。しかし、本明細書では、説明を単純にするために、ファイル全体を、トランザクションによる読取／書込アクセスのために所与の時に１回だけオープンできる（すなわち、他のアクセスがシリアライズされる）ものとして本発明を説明する。ファイルの非トランザクショナルアップデータも、書込用のトランザクショナルオープンを用いてシリアライズされる。これによって、同一のトランザクションに属する複数のスレッドが書込のために同時にファイルをオープンできなくなるのではないことに留意されたい。ファイルをオープンできるリーダーすなわち読取専用アクセスを用いるリーダーの数に対する重要な制限はない。
【００４６】
本発明によれば、読取アクセスのためにあるトランザクションによってオープンされるファイルは、ライタがリーダーの前と後のどちらにファイルをオープンしたかに無関係に、別のトランザクションによってファイルに対して行われる同時変更から分離される。さらに、ファイルを変更したトランザクションがそのトランザクションをコミットするかどうかに無関係に、分離は、読取専用トランザクションのアクセスが終了するまで継続される。たとえば、図５に示されているように、図５でタイムラインの先頭のＸ／ＲＯによって表される、読取専用アクセスのためにページのファイルＶ０をオープンするトランザクショナルリーダーＸを検討されたい。ファイル内の各ページの大文字の「Ｏ」は、オープンの時の元のデータを表すことに留意されたい。ライタＹが、後に、別のトランザクションで読取／書込アクセスのためにファイルＶ１をオープンし（Ｙ／ＲＷ）、それに対する変更を行う（Ｙ／書込）場合に、トランザクショナルリーダーＸは、ライタＹのＶ１での変更ではなく、ファイルＶ０の元のデータを見続ける。非トランザクションが、変更の際にファイル変更を見ることに留意されたい。
【００４７】
以下で説明するトランザクショナル分離を達成するために、ファイルの「バージョン」Ｖ０が、（少なくとも）リーダーＸがそのファイルをオープンしている時間、リーダーＸのために保持される。これは、トランザクショナルライタＹがコミットした場合であってもそのままである。ライタＹが、ファイル自体に変更を加え、リーダーＸによって見られるバージョンが、以下で詳細に説明するように、変更が書き込まれる前に作られた元のデータのページごとのコピーであるが、その逆すなわち、リーダーＸのために元のファイルを未変更のままに保ち、ライタＹのために変更されたページのバージョンを保持することが実現可能であることに留意されたい。また、本明細書で使用される用語「バージョン」、「バージョン管理される」、「バージョン管理」および類似物が、タイムスナップショットの１点を指す（ソースコード管理システムなどの永続的バージョン管理と混同してはならない）ことに留意されたい。さらに、トランザクショナルリーダーを、非トランザクショナルライタとシリアライズして、実装を容易にすることができることに留意されたい。その代わりに、非トランザクショナルライタを、分離だけの目的で「システム所有」トランザクションに含めることができる。したがって、予測可能なトランザクショナル読取セマンティクスがもたらされ、これによって、トランザクショナルリーダーが、所与の時点のファイルの「凍結された」イメージに頼ることができる。
【００４８】
図５に戻って、トランザクショナルライタＹが、ファイルＶ１をコミットした後に、トランザクショナルライタＺが、図５に示されているように、読取−書込アクセスのためにファイルＶ２（Ｖ１から変更されていない）をオープンする（Ｚ／ＲＷ）ことができる。ライタＺは、ライタＹのコミットした変更を見、さらにそれを変更することができる（Ｚ  書込）。しかし、この時に、リーダーＸが、このファイルがＸによって最初にオープンされた時にＸが見た元のファイルページを見続け、Ｙがコミットした変更を一切見ないことに留意されたい。リーダーＸがファイルをクローズし、再オープンする場合に限って、リーダーＸが、おそらくＹの変更を見る。リーダーＸは、図５に示されているように、リーダーＸがファイルをクローズし、Ｚがコミットした後にファイルＶ２を再オープンするならば、ライタＺのコミットした変更も見ることができる。言い換えると、リーダーＸは、Ｚがコミットする前にクローズし、再オープンする場合には、バージョンＶ１を見るが、リーダーＸが、Ｚがコミットした後でクローズし、再オープンする場合には、ファイルバージョンＶ２を見る。以下で説明するように、その代わりに、オープンの時に最新のコミットされたバージョンより古いバージョンを維持し、そのオープンを可能にすることが実現可能である。
【００４９】
これらのセマンティクスが、既存のファイル共有モードを使用して表現可能ではないことに留意されたい。本明細書に記載のトランザクション分離セマンティクスでは、ハンドルをお互いに分離するファイル共有モードと異なって、トランザクションの効果をお互いに分離する。既存のファイル共有モードは、変更されず、追加のシリアライゼーションに使用することができる。たとえば、「書込拒否」ファイル共有モードを指定する、同一のトランザクションの２つの異なるスレッドによるトランザクショナル更新のためのオープンの場合に、第２のオープンが、共有違反によって拒否される。これによって、分散アプリケーションが、複数のスレッド、プロセス、またはコンピュータにトランザクション作業負荷を割り当てられるようになると同時に、トランザクションによって行われる変更が、他のトランザクションまたは非トランザクションワーカーから保護される。さらに、これらのセマンティクスでは、各リーダーが、オープンされながら安定した状態を保つためにファイルの内容に頼ることができる予測可能なバージョン管理された読取が保証される。
【００５０】
下に示す互換性マトリックスで、「はい」は、モードが追加のトランザクショナルな制限に関する互換性を有することを意味する。
【００５１】
【表１】
0004219589.tif 000004
【００５２】
したがって、トランザクションの更新により、その変更を含むファイルの最新のバージョンを見ることになるが、トランザクショナルな読取では、ファイルのコミットされたバージョンが得られる。１つの代替案（上で一般的に説明したもの）が、オープンの時点でファイルの最新のコミットされたバージョンを提供し、トランザクショナル読取のためにオープンされている間は、さらに変更が行われ、コミットされる際に、バージョンの変更を許可しないことである。これの長所は、リーダーが、オープンの期間中に、データのトランザクショナルに一貫性のあるビューを見るようになることである。
【００５３】
第２の代替案では、リーダーが見るバージョンを、最初のファイルシステムアクセス時または他のより早い時（すなわち、ＴｘＦログでのより早い点）でのバージョンとすることができる。これによって、このリーダーが開始された時の最も最近にコミットされたバージョンを提供することができる。この開始の時は、トランザクションが最初にシステム内のＮＴＦＳオブジェクトにアクセスした時とすることができ、あるいは、その代わりに、この時を、統合されたシナリオで他のＡＰＩを使用して定義することができる（たとえば、ログシーケンス番号またはＬＳＮを使用する）。この特徴の長所は、トランザクションが、複数のファイルにまたがってある時点のスナップショットを得ることであり、これは、複数のファイル依存性およびリンクがある時（たとえばＨＴＭＬファイルまたはＸＭＬファイル）に有用になる可能性がある。この代替案では、同一トランザクション内の１つのファイルの複数のオープンが、そのトランザクション内の最初のオープン時に選択されたバージョンを得ることができることに留意されたい。しかし、諒解できるように、システムによって維持される必要があるバージョンヒストリの量は、この第２の代替案で増加する。
【００５４】
用語「バージョンウィンドウ」は、その間に、選択されたバージョン管理法式をサポートするために、前にコミットされたバージョンの組が維持される時間隔を指す。上で説明した第１の代替案では、バージョンウィンドウが、各ファイルによって変化し、まだアクティブであるファイルの最も古いオープンから現在の時刻までの間の時間である。第２の方式では、ウィンドウは、システム内の最も古いトランザクションの開始ＬＳＮから現在の時刻までの時間として定義される。これらの方式の一方または両方をサポートすることができ、バージョンを維持するためにＴｘＦ７０によって行われる作業は、本質的に同一である。説明を単純にするために、本発明を、本明細書では主に第１の方式に関して説明するが、この場合、リーダーが見るバージョンは、トランザクションでの最初のオープンの時点でのファイルの最も最近にコミットされたバージョンである。したがって、この第１の方式では、ストリームバージョンがオープン時に決定されるので、アプリケーションは、最新のコミットされたデータを望む場合に、ハンドルをクローズし、再オープンする必要がある。これは、ウェブサーバのシナリオに特に関係する可能性が高く、この場合には、ウェブサイトを、トランザクショナルにオンラインで更新することができ、したがって、リーダーは、新たにコミットされた状態を見るために、ハンドルをクローズし、再オープンする必要がある。
【００５５】
一実施形態では、変更が最終的にライタによってコミットされると仮定されるので、ファイルへの書込が、実際のファイルに対する書込である。コミットされない場合には、すべての変更が、以下で説明するように、ログに取り込まれたアンドゥ情報を介してロールバックされる。したがって、バージョン分離をもたらすために、ページに向けられた各書込は、まず、古いページがトランザクショナルリーダーのために保存されることをもたらす。しかし、これを逆に行うこと、すなわち、変更がコミットされるまで元のファイルを手付かずで残し、これによって、リーダーではなくライタが、それのために新しいページを作成されるようにすることが可能である。
【００５６】
Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ（登録商標）２０００（またはＮＴ（登録商標））オペレーティングシステムを使用する好ましい実施形態では、古いバージョンのためにディスクに別のファイルを作成するのではなく、キャッシュマネージャおよび仮想メモリマネージャまたはＶＭＭの観点から、別のインメモリストリームを提示する。キャッシュマネージャ、ＶＭＭ、および非トランザクショナルＮＴＦＳに対するこれらの関係は、参照によって本明細書に組み込まれる参考文献、「Ｉｎｓｉｄｅ  Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）」、ｂｙ  Ｈｅｌｅｎ  Ｃｕｓｔｅｒ、Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ（１９９３）、「Ｉｎｓｉｄｅ  ｔｈｅ  Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）Ｆｉｌｅ  Ｓｙｓｔｅｍ」、Ｈｅｌｅｎ  Ｃｕｓｔｅｒ  Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ（１９９４）、および「Ｉｎｓｉｄｅ  Ｗｉｎｄｏｗｓ  ＮＴ（登録商標）、Ｓｅｃｏｎｄ  Ｅｄｉｔｉｏｎ」、ｂｙ  Ｄａｖｉｄ  Ａ．Ｓｏｌｏｍｏｎ、Ｍｉｃｒｏｓｏｆｔ  Ｐｒｅｓｓ（１９９８）に記載されている。
【００５７】
トランザクショナルリーダーのためのバージョン維持に関する仮想メモリマネージャおよびキャッシュマネージャの展望からは、ファイルのより古いバージョンの読取が、異なるファイルの読取のように管理される。これによって、アプリケーションが、より古いバージョンを自分のアドレス空間に単純にマッピングできるようになり、メモリ記述子リストを使用してデータにアクセスするクライアント（たとえばリダイレクタ）が、透過的に動作できるようにもなる。これが可能であるのは、Ｗｉｎｄｏｗｓ（登録商標）２０００オペレーティングシステムで、ＶＭＭおよびキャッシュマネージャが、ファイルシステム入出力（Ｉ／Ｏ）に参加するからである。ファイルシステム（キャッシングされないアクセスのためにオープンされたファイルを除く）では、キャッシュマネージャを使用して、データをシステムメモリにマッピングし、キャッシュマネージャは、ＶＭＭを使用してＩ／Ｏを開始する。ダーティページ書込は、通常は、バックグラウンドスレッドで、遅延モードで発生する。このアーキテクチャの結果として、アプリケーションアドレス空間に直接にマッピングされるファイルは、キャッシュマネージャとページを共有し、キャッシュマネージャは、それを得るのにどのシステムサービスが使用されるかに無関係に、データの一貫性のあるビューを提供する。その結果、ネットワークリダイレクタ（以下で説明する）が、データをローカルにキャッシングすると同時に、他のクライアントとの一貫性がある形でサーバのデータを得ることに留意されたい。
【００５８】
分離を達成するために、まだ読取中の最も古いコミットされたバージョンから始めて最後に更新されたバージョンまで、複数のバージョンが維持される。各バージョンは、最新バージョンに対する変更を追跡する、バージョンに関連するデータ構造体を有する。未変更のページが読み取られる場合に、そのページは、ファイル（キャッシュ内にあるかディスクに書き込まれた可能性がある）から読み取られ、変更されたページが読み取られる場合には、そのページは、変更されたページデータ（やはりキャッシュ内にある可能性がある）から読み取られる。いくつかのバージョンが、それを読み取るトランザクションを有しない場合があるが、それらがバージョンウィンドウ内にあり、将来にオープン要求を受ける可能性があるので、それらバージョンのインメモリ構造体を維持することができることに留意されたい。一度もオープンされたことがないバージョンは、データページを保管するためにメモリを占有しない。最新バージョンは、ベースファイルストリームに対応し、更新される可能性がある。
【００５９】
図６に示されているように、各バージョンは、ＴｘＦ「バージョンストリーム制御ブロック」（ＴｘＦＶＳＣＢ）によって記述される。ファイルのバージョンストリーム制御ブロックは、時間の順でリスト内でリンクされ、最新以外の各バージョンが、コミット／中断され、読取専用である。最新のバージョンは、コミットされる場合とされない場合がある。
【００６０】
各ＴｘＦＶＳＣＢ（たとえば９４）に、ＴｘＦログに記録される、トランザクションのコミットＬＳＮが保管されるバージョンログシーケンス番号９６（バージョンＬＳＮ）が含まれる。（最も最近の）コミットされていないバージョンについて、一実施形態で、このＬＳＮが、たとえば現在の時点未満の最高のＬＳＮを見つけるのを容易にする、ＴｘＦ定義の「ＭＡＸ＿ＬＳＮ」である。このバージョンより以前の、コミットされたデータの読取を望むリーダーは、変更テーブル（たとえば９８）内のエントリを使用することによって、それにアクセスすることができ、変更テーブルは、ＴｘＦＶＳＣＢによってポイントされるバージョンによって変更されたページ番号を記録するインメモリテーブル９８である。ＴｘＦＶＳＣＢ９４などの各ＴｘＦＶＳＣＢには、このバージョンに対応するセクションオブジェクトポインタ（ＳＯＰ）構造体１００も含まれ、これは、キャッシュマネージャおよび仮想メモリマネージャによって使用され、メモリに格納されたストリームを表す。状態フラグ１０２も設けられ、そのうちの１つが、バージョンがコミットされたか否かを示す。最も新しいバージョンだけが、未コミットになりえることに留意されたい。やはり含まれるのが、ＶｅｒｓｉｏｎＬｅｎｇｔｈ１０４データフィールドと変更テーブルポインタフィールド１０６であり、後者には、このバージョンによって変更されたページ番号を記録する変更テーブル９８へのポインタが含まれる。
【００６１】
図６に示されているように、変更テーブル（たとえば９８）内に、ディスクアドレスをページ番号に関連して保管して、ディスク上のページの前のバージョンを見つけることができる（このバージョンでページが少なくとも１回書き込まれているものとして）。図６からわかるように、主にメモリを節約するために、ページがディスク上で連続的に保管される場合に、ページ範囲を１エントリに保管することができる。図７に、ファイルの複数のバージョンに関する変更テーブル９８１〜９８３を示す。木構造などの効率的な検索構造を使用して、変更テーブルを編成することができる。
【００６２】
ファイルが、トランザクション内で読取専用アクセスのためにオープンされる場合に、適当なコミットされたバージョンが選択される。バージョン番号は、「ｒｅａｄＬＳＮ」によって識別される。ｒｅａｄＬＳＮは、上で説明したように、どのタイプのバージョン管理が使用されるかに応じて、現在のＬＳＮまたは古いＬＳＮのいずれかになる。選択されたバージョンは、ｒｅａｄＬＳＮの前の最後にコミットされたバージョンである。たとえばバージョンが古すぎるなど、そのようなバージョンが存在しない場合には、オープンが失敗する。ファイルが、ＴｘＦＶＳＣＢを関連付けられていない場合には、新しいＴｘＦＶＳＣＢが、空の変更テーブルと共に作成され、未コミットとマークされる。デフォルトのインメモリストリームが使用され、その結果、既存のキャッシュデータを読取に使用することができるようになる。書込アクセスの場合、最新のバージョンがコミットされていない場合には、それがそのまま使用されるが、そうではなく、未コミットとマークされていない場合には、新しいＶＳＣＢが作成され、未コミットとしてマークされる。
【００６３】
ファイルに書き込む時の分離を容易にするために、データのページ（たとえば、ユーザレベルバッファ１０８）がトランザクションによって変更されるたびに、そのページが、本質的にその場で、すなわちキャッシュ１１０（図８）内で編集される。その後、キャッシュ１１０が、キャッシュマネージャおよび／またはＶＭＭ１１２によって、適当な時にディスク（または他の適当な不揮発性ストレージメディア）１１４に書き込まれる。上で一般的に説明したように、データは、ファイルをメモリ内でマッピングすることまたは書込ＡＰＩを使用することのいずれかによって、変更することができる。書込ＡＰＩを使用する時には、通常は、キャッシュマネージャ１１２が、変更をメモリ常駐ページ１１６にコピーするのに使用される。キャッシュマネージャ１１２が、ファイルをシステムメモリ内にマッピングするのに使用されることに留意されたい。メモリマッピングが使用される時には、変更は、アプリケーションによってシステムメモリページ（たとえばページ１１６）に対して直接に行われ、このページは、キャッシュマネージャ１１２がマッピングしたページと同一である。変更は、「ダーティ」ビットを介して記録され、このビットは、メモリマッピングされたＩ／Ｏの場合にプロセスプライベートなページテーブルエントリ（ＰＴＥ）１１８に変更が存在することを示す。通常、これらのビットは、メモリマネージャがプロセスのワーキングセットからページをトリミングする時に、共有（ページフレーム番号）ＰＦＮ構造体１２０に伝搬される。これらのビットは、アプリケーション６０によって、システムＡＰＩを使用してマッピングされたセクションをフラッシュすることによって、明示的に伝搬することもできる。ダーティページが、バックグラウンドで周期的に書き出される可能性もあることに留意されたい。
【００６４】
メモリマッピングされた変更がトランザクションに含まれることを保証するために、システムは、各アプリケーションがマッピングしたセクションの仮想アドレス範囲をコミット時にフラッシュする。このフラッシュは、それをマッピングしたアプリケーションのコンテキスト内から開始される。アプリケーションによって明示的にフラッシュされたページだけがトランザクションに含まれるようにするトランザクショナルセマンティクスを定義することができる（たとえば、ユーザセクション内のバイトへの個々の修正ではなく、フラッシュをトランザクショナルにする）。その代わりに、セクションをマッピングし、フラッシュを行うプロセスにアタッチ（ＫｅＡｔｔａｃｈＰｒｏｃｅｓｓ）されるシステムスレッドを介してこれを達成することができる。セクションのリストは、対応するトランザクションテーブルエントリ内で維持される。ファイルＡＰＩによって行われた変更も、コミット時にディスクにフラッシュされる必要があることに留意されたい。これは、ページング書込の時に、前のトランザクションから残っているダーティページ書込と、現在のトランザクションでメモリマッピングによって行われた変更とを区別することが不可能だからである。
【００６５】
したがって、ＴｘＦは、トランザクションによる読取専用および読取／書込の両方のファイルオープンをサポートする。トランザクションが、現在他のトランザクションによってオープンされていないファイルを、読取専用アクセスを用いてオープンする時に、そのファイルに関するセマンティクスは、非トランザクショナルオープンと同一である。トランザクションが、読取／書込のためにファイルをオープンする場合には、ＴｘＦが、図９に示されているように、トランザクションごとのコンテキストを保管するために、ファイルに関して１つ、ストリームごとに１つ、ストリームバージョンごとに１つの構造体を必要とする。このオープンに関するデータ構造体を、図９に示すが、図９では、「ファイルオブジェクト」が、ユーザのファイルハンドルによってマッピングされたオブジェクトであり、「ＦＣＢ」が、ＮＴＦＳファイル制御ブロックであり、「ＳＣＢ」が、オープンされた指定されたストリームのＮＴＦＳストリーム制御ブロックであり、「ＮＰ  ＳＣＢ」が、主にファイルマッピング用のセクションオブジェクトポインタを保持するのに使用される非ページングストリーム制御ブロックであり、「ＣＣＢ」が、ＦｉｌｅＯｂｊｅｃｔごとのコンテキスト構造体である。ＴｘＦＦＯ内のフラグが、ファイルがトランザクションによって読取についてオープンされた時を示すことに留意されたい。
【００６６】
図９では、ＴｘＦＣＢ構造体が、ＴｘＦによって維持されるファイルごとの変更のアンドゥデータのアンカであり、ＴｘＦＣＢ構造体に、トランザクションへの参照も含まれる。ＴｘＦＳＣＢは、ストリームバージョンのアンカであり、ＴｘＦＶＳＣＢは、ストリームの特定のバージョンのアンドゥデータのアンカである。ＴｘＦＯ構造体は、ストリームのバージョンへの特定のトランザクションのアクセスを記述し、そのバージョンの関係する共有ＴｘＦ構造体へのポインタを取り込む。
【００６７】
図１０に示されているように、第２のトランザクションｔ３が、前の読取専用トランザクションが終了する前に読取／書込のためにファイルをオープンする場合に、ファイルの古いバージョンが、本質的にシフト（図１０では右に）されて、新しいバージョンを表す構造体の余地が作られる。したがって、図１０は、ファイルの現在のバージョンを変更するトランザクションｔ３による１つの読取／書込オープンと、ファイルの最も最近にコミットされたバージョンにアクセスするトランザクションｔ２による読取専用オープンと、前にコミットされたバージョンにアクセスするトランザクションｔ１によるもう１つの読取専用オープンを表す。単純にするために、各ＦｉｌｅＯｂｊｅｃｔが同一のＳＣＢをポイントし、これによって、ＮＴＦＳがファイルバージョンを意識しないことに留意されたい。また、各ＦｉｌｅＯｂｊｅｃｔが、一意のページングされないＳＣＢ内にセクションオブジェクトポインタのそれ自体の組を有する。普通は、ユーザが実際にストリームをマッピングしない限り、読取専用トランザクションのセクションオブジェクトポインタが使用されないことに留意されたい。キャッシングされるアクセスは、未変更のページの現在のストリームと、変更されたページのログファイルからサービスされる。各ファイルオブジェクトのＴｘＦＯは、効果的に、トランザクションがアクセスしているファイルのバージョンを取り込む。
【００６８】
一般に、ＴｘＦトランザクションが、ＮＴＦＳハンドルと独立の寿命を有するので、ＴｘＦ構造体は、ＮＴＦＳ構造体と独立の寿命を有する。両方が存在する時には、これらが、図９〜１０に示されているように一緒にリンクされ、ここでは、単一方向のリンクが、両側での明確に定義されたインターフェースを使用してセットアップされる。たとえば、ファイルへの被トランザクションアクセスが発生する時に、ＴｘＦＣＢへのＦＣＢリンクが検査される。ＮＵＬＬの場合には、ＴｘＦルーチンを使用してＴｘＦＣＢがセットアップされる。しかし、ＴｘＦＣＢが既に存在する場合には、ＴｘＦファイルテーブルからＴｘＦによってファイルＩｄを使用してルックアップされ、そうでない場合には新しいＴｘＦＣＢが割り振られる。同様に、ＦＣＢが割振り解除され、ＴｘＦＣＢリンクがＮＵＬＬでない時には、単一方向（ＮＴＦＳからＴｘＦへの）リンク削除のためにＴｘＦルーチンが呼び出される。
【００６９】
ファイルに関するＴｘＦ構造体は、被トランザクションリーダーがファイルをオープンしていない時、または将来にそのファイルのそのバージョンをオープンできない時に、割振り解除される。ディレクトリは、ＮＴＦＳディレクトリがディレクトリ自体の削除に起因してなくなる（再帰的削除で発生する）場合であっても、ＴｘＦＳＣＢ構造体に名前空間分離情報がある限り、維持される。ＴｘＦ構造体の寿命は、参照カウントを介して管理される。
【００７０】
ログ記録サービス
本発明のもう１つの態様によれば、一般的に以下で説明するように、永続的状態のログ記録および回復のために、ＴｘＦ７０は、ログ記録サービス７４（図２）を使用し、ログ記録サービス７４は、長時間動作するトランザクションをサポートするために、普通のＮＴＦＳログだけに頼るのではなく、複数レベルのログ記録を可能にする。以下で明白になるように、これによって、多数の利益がもたらされる。たとえば、通常のＮＴＦＳログは、サイズにおいて４メガバイト程度であり、これは、現在は短期間のメタデータログ記録に適当であるが、通常のユーザ定義トランザクションは、そのようなログを素早く使い果たす。また、ログ記録されるＴｘＦトランザクショナル動作の数に対して相対的に多数のログ記録されるＮＴＦＳ動作がある可能性が高い。さらに、ＮＴＦＳメタデータコミット動作は、ディレクトリをロックアップし、これによって、長時間を要するＴｘＦトランザクションが、ファイルシステムの性能に悪影響を及ぼす（単一レベルログ記録方式を仮定した場合）。
【００７１】
従来ののＮＴＦＳログは、明確に文書化されており、したがって、短い要約と本発明のトランザクショナルファイルシステムと共に使用される範囲を除いて、本明細書では詳細に説明しない。ＮＴＦＳは、ＮＴＦＳが変更を行う前に、ＮＴＦＳに対するファイルシステム動作のアンドゥレコードおよび／またはやり直すレコードを書き込むことによって、ファイルシステム動作の中断／クラッシュ回復を提供する。ＮＴＦＳログは、ファイル作成コマンド、名前の変更など、ＮＴＦＳデータ構造を変更する動作を含む、ＮＴＦＳボリュームに影響する動作を記録する、ボリュームごとのファイルである。たとえば書き込まれたバイトなどのユーザファイルデータではなく、メタデータがログ記録されることに留意されたい。ログは、ファイルとして維持され、システム障害からの回復のためにアクセスされる、すなわち、システムがクラッシュした場合に、部分的に完了した動作を、周知の技法を使用して元に戻すかやり直すことができる。ＮＴＦＳは、耐久性を提供しない、すなわち、ＮＴＦＳは、コミット時にそのログを強制しない。
【００７２】
本発明の一態様によれば、ＴｘＦトランザクションおよび回復管理は、複数レベル回復機構内で、ＮＴＦＳの上に階層化される。上で説明したように、ＴｘＦは、ＮＴＦＳ動作を下位コンポーネントとして扱って、ユーザレベルトランザクションを構築する。回復に関して、ＴｘＦは、より上位のログを維持し、ログ記録されたＮＴＦＳ動作を、ＴｘＦが「データ」の前のそれ自体のＴｘＦログを強制するという意味で、より上位のログに関する「データ」として扱う。この場合の「データ」は、ＮＴＦＳログであり、回復可能ストア自体である。
【００７３】
複数レベルログ記録を達成するために、図１１に一般的に示されているように、より下位レベルのＮＴＦＳログ１２６記録の前に、より上位のＴｘＦログ１２４記録を実施することは、既に使用可能なＮＴＦＳ６４の回復可能性を利用する方法で各ログのＬＳＮ（本明細書ではＴｘＦ  ＬＳＮおよびＮＴＦＳ  ＬＳＮと称する）を調整することによって達成される。ＮＴＦＳトランザクションによって管理されないデータ（すなわち、ストリームバイト自体）について、ＴｘＦ７０は、本質的に、以下で説明するように、回復可能性を完全に管理する。
【００７４】
より上位のＴｘＦログ１２４が、その「データ」すなわちＮＴＦＳログ１２６のレコードの前に強制される（ＴｘＦログをすべてのＮＴＦＳ動作の前に非効率的に強制せずに）ことを保証するために、ＮＴＦＳ６４がそのログ１２６にデータを強制しようとするたびにＮＴＦＳ６４が呼び出すＴｘＦコールバックが提供される。この呼出しでは、ＮＴＦＳ６４が、フラッシュされようとしている最高のＮＴＦＳ  ＬＳＮを示す。それと同時に、ＴｘＦ７０は、ＮＴＦＳコミットＬＳＮを各々のＴｘＦ  ＬＳＮにマッピングするために、ＴｘＦが使用した最近のＮＴＦＳトランザクションのマップ１２８を維持する。ＴｘＦがＮＴＦＳコミットＬＳＮの知識を有するように、名前空間変更動作が設計されることに留意されたい。ＮＴＦＳログは、比較的低い頻度でディスクにフラッシュされるという点で、耐久性がない。その結果、適度な数のＴｘＦレコードが、ログバッファ内に存在し、単一のＩ／Ｏ動作で一緒にディスクにフラッシュされる可能性が高い。
【００７５】
コールバックに応答して、ＴｘＦ７０は、ＮＴＦＳログで強制されている最高のＮＴＦＳコミット−ＬＳＮに対応するＴｘＦレコードまで、ＴｘＦログ１２４を強制する。しかし、この最高のレコードまでのＴｘＦログ１２４のフラッシュが、より最適であるに過ぎないことに留意されたい。というのは、より上位のログが先にフラッシュされることを保証する他の方法（たとえば、ＮＴＦＳがそのログをフラッシュしようとしている時に、いつでも新しいＴｘＦレコードのすべてをフラッシュする）で十分であるからである。回復中に、ＴｘＦがその回復を開始できるようになる前に、ＮＴＦＳが、その回復を完了する。
【００７６】
これによって、ＴｘＦログ１２４がＮＴＦＳログ１２６の前にフラッシュされるようになるが、ＴｘＦログの末尾付近の一部のログレコードが、ＮＴＦＳによってコミットされないＮＴＦＳ動作を実行した場合があり、そのようなレコードが、コミットされたレコードに混ざっている可能性がある。対応するＮＴＦＳ動作がコミットされたＴｘＦログレコードを、コミットされていないものと区別することが重要である。というのは、これによって、ＴｘＦログレコードが回復中に適用されるか否かが決定されるからである。
【００７７】
理解されるように、これが重要であるのは、やり直し中に動作を繰り返すことも、実際には行われなかった動作を元に戻すことも正しくないからである。例として、ＴｘＦログにログ記録される可能性がある下記の情況を検討されたい。
【００７８】
【表２】
0004219589.tif 000005
【００７９】
上の情況では、名前変更動作を逆転（元に戻す）ことが正しいかどうかを知ることができない。毎回逆転を単純に実行することは正しくない。というのは、名前の変更が、ＮＴＦＳ内で実際に発生していない場合に、ＹがＸに名前を変更され、Ｘを置き換えるからである。その後、システムリンクをオープンしようとする試みの際に、ＮＴＦＳ動作が行われなかったのでリンクが存在しないので、そのオープンが失敗する。ファイルＸが失われ、ＹがＸに名前を変更された。しかし、ＴｘＦ７０が、名前変更が行われたか否かを確認できる場合には、アンドゥ動作を適用するか否かを正確に判定することができる。
【００８０】
動作が実際に起こった、すなわち、ＮＴＦＳ６４によってコミットされたかどうかを判定するために、動作を要求する前に、ＴｘＦが、対応するレコードをそのログ１２４に書き込む。その後、ＴｘＦは、ＴｘＦ  ＬＳＮを受け取り、これを、所与のファイルについて要求された動作と共にＮＴＦＳ６６に供給する。ＮＴＦＳ６６に、コミットに続いて対応する（１つまたは複数の）ＮＴＦＳログレコードにＴｘＦ  ＬＳＮを置かせることが可能ではあるが、これは非効率的である。その代わりに、ＮＴＦＳが動作をコミットする時に、コミットの一部として、ＮＴＦＳが、ＴｘＦ  ＬＳＮを、そのファイルのＮＴＦＳボリューム上で維持されるレコードに書き込む。ＮＴＦＳでは、マスタファイルテーブル１３０として知られる構造体内で、ボリューム上の各ファイル（およびディレクトリ）に関するレコードが、既に維持されている。したがって、ＴｘＦ  ＬＳＮは、図１１に一般的に示されているように、このファイル（たとえばファイル３）のレコードのフィールド（たとえば１３２３）に書き込まれる。その代わりに別のデータ構造体を使用することができるが、ファイルごとのレコードが、各ＮＴＦＳボリューム上で既に使用可能であることに留意されたい。
【００８１】
その後、クラッシュに続いて、回復中に、ＴｘＦがＮＴＦＳにその回復を完全に実行させた後に、ＴｘＦは、まず、ＴｘＦログにログ記録された動作がクラッシュの前にディスクに対して行われたか否かを判定するために検査する（ＮｔｆｓＴｘＦＧｅｔＴｘＦＬＳＮ（ｆｉｌｅ−ｉｄ、＊ＴｘＦＬｓｎ）呼出しを介してＮＴＦＳを呼び出すことによって）。ファイルに関するＮＴＦＳ動作が、クラッシュの前にコミットされ、ディスクに存在した場合には、ＴｘＦログ１２４のレコードのＴｘＦ  ＬＳＮが、ファイルレコードフィールド内のＴｘＦ  ＬＳＮ以下である。というのは、ＮＴＦＳ回復によって、ファイルレコードが復元されることが保証されるからである。ファイルレコード内のＴｘＦ  ＬＳＮが、ＴｘＦログレコード内のＬＳＮ未満である（またはそのファイルのファイルレコード内にない）場合には、ＮＴＦＳ動作がコミットされなかったこと、対応するＴｘＦログレコードを元に戻すために適用してはならないことがわかる。
【００８２】
しかし、正しい回復を保証するために、回復ウィンドウ中にオブジェクトが削除される場合に、ＴｘＦは、削除ログレコードがログ内で忘れられるまで、ファイルレコードの削除を遅延する（したがって、ｆｉｌｅ−ｉｄを保存する）。これは、ファイルへのシステムリンクを作成することによって行われる。さらに、新しいファイルが作成される場合に、ＴｘＦログレコードは、ＮＴＦＳが、作成に使用しようとしているｆｉｌｅ−ｉｄを決定する後まで、書き込まれない。これによって、ＴｘＦログ内にｆｉｌｅ−ｉｄが正確に記録される。非トランザクショナル作成についても、ＮＴＦＳは、ファイルレコード内に現在のＴｘＦ  ＬＳＮを書き込み、これによって、ｆｉｌｅ−ｉｄ（シーケンス番号を含む）が回復ウィンドウ中に再利用される場合を処理し、ＴｘＦに、この作成の前のログレコードをスキップさせることが期待されることに留意されたい。
【００８３】
次に、ＮｔｆｓＴｘＦＧｅｔＴｘＦＬＳＮ呼出しから、ｆｉｌｅ−ｉｄが回復時に存在しないことがわかった場合には、トランザクションがコミットされた後だがクラッシュの前に非トランザクショナルにファイルが削除されたか、作成動作のすぐ後にクラッシュが起きたかのいずれかである。第１の場合に、ＴｘＦが、かかわっておらず、ファイルレコードが、回復ウィンドウ中に削除されたことに留意されたい。第２の場合には、ＴｘＦ作成ログレコードが、ＴｘＦログディスクに送られたが、それに関するＮＴＦＳコミットが、持続しなかった。この第２の場合は、作成ログレコードを処理する時に限って検出される。
【００８４】
アンドゥレコードが、不完全なトランザクションの中断に使用されるので、ｆｉｌｅ−ｉｄが存在しないことがＮｔｆｓＴｘＦＧｅｔＴｘＦＬＳＮによって見られるレコードを、単純に無視することができる。
【００８５】
中断中、クラッシュ回復中およびロールフォワード回復中に、ログによって駆動されるやり直しアクションおよびアンドゥアクションが、ＮＴＦＳフィルタドライバモデルのフィルタドライバスタックの最上部で開始され、中間のフィルタドライバがそのアクションを見ることができるようになることに留意されたい。やり直しアクションおよびアンドゥアクションに対応するＩＲＰは、特別にマークされ、その結果、フィルタドライバが、それらを無視することを選択できるようになる。これらのＩＲＰには、通常のトランザクション状態が含まれ、ファイルオブジェクトは、普通にトランザクションオブジェクトをポイントする。しかし、トランザクションが、特別な状態であるから、ＴｘＦは、それらを特別に扱う必要があることを知る。たとえば、ＴｘＦは、これらのアクションをトランザクションに含めることを試みず、また、それらを非トランザクショナルとして扱わない。
【００８６】
名前空間動作をログ記録するほかに、ＴｘＦコンポーネント７０は、他の動作の中でも、ページ変更を記録するためにログ記録サービス７４と共に働く。上で述べたように、バージョンを保存し、中断の場合のアンドゥ動作もサポートするために、変更がＡＰＩを介してメモリ内のページに対して実際に行われる前に、対応するアンドゥレコードが、ＴｘＦログ１２６に書き込まれる（強制されない）。図１２に示されているように、その後、ページ全体が書き込まれ（通常は、以下で説明するＴＯＰＳストリーム１３４と称する、ページのインメモリおよびオンディスクのストリームに）、これによって、バージョン管理されるリーダーが、単一のＩ／Ｏ動作でページを読み取ることが可能になる。ログ書込の後に、このファイルの変更テーブル９８が、ログシーケンス番号（ＴｘＦ  ＬＳＮおよびＴＯＰＳストリーム１３４内のオフセット）を用いてマークされ、その後、変更がページに適用される。
【００８７】
ページングＩ／Ｏを介して変更されたページ、たとえば、ユーザがマッピングしたセクションによって変更されたページおよび／または現在書き込まれつつあるＡＰＩの前の呼出しによって変更されたページから生じるものなどについて、ページング書込が実行される。このページング書込は、バックグラウンドスレッド内とすることができ、あるいは、コミット時のフラッシュの一部とすることができる。どの場合でも、ＴｘＦ７０は、まず、変更テーブル９８（図６）を検査して、アンドゥがＴｘＦログ１２６に取り込まれているかどうかを調べる。そうである場合には、システムは、テーブル９８内でマークされたＴｘＦ  ＬＳＮまでＴｘＦログ１２６を強制し、これは、ほとんどの場合に、Ｉ／Ｏなしでリターンする。変更テーブル９８がマークされていない場合には、ページのアンドゥバージョンが、獲得され、ＴＯＰＳストリーム１３４およびＴｘＦログ１２６に書き込まれる。複数ページＩ／Ｏが、一般的である。というのは、バックグラウンドスレッドが、ファイル−オフセットの順でページを一緒にグループ化することを試みるからである。これらの場合には、複数のアンドゥが、単一の大きいＩ／Ｏで書き込まれる。そのような場合のアンドゥは、単一の大きいＩ／Ｏで読み取られる。
【００８８】
準備レコードをＴｘＦログ１２６に強制した後に、アンドゥイメージが、ディスク上でＴｘＦログ１２６およびＴＯＰＳストリーム１３４にあり、変更されたファイルページが、ファイル内のそれぞれの位置にある。その結果、コミットが、コミットレコードをログ１２６に書き込むという単純なことになる。中断は、アンドゥレコードを逆の順序で進み、それをベースファイルに適用し、その後にファイルをフラッシュし、その後に中断レコードを強制的に書き込むことによって達成される。これらのアンドゥレコードは、中断レコードがログ１２６に存在する場合には回復時に無視される。頻繁でない動作（中断）中にファイルをフラッシュすることによって、大きい（ページサイズの）補正ログレコード（ＣＬＲ）をやり直しレコードとして書き込む必要がなくなり、スペースが大幅に節約されることに留意されたい。
【００８９】
アンドゥイメージの取得は、ページの前にコミットされたバージョンを得るのと同一すなわち、ファイルのアンドゥイメージは、まず、ファイルの前のバージョン内で検索される。イメージがメモリ内に常駐する場合には、アンドゥイメージが、メモリから検索される。そうでない場合には、イメージは、キャッシングされないＩ／Ｏ動作によってディスクから読み取られる。というのは、ダーティビットが、プロセスプライベートであり、必ずしも既知ではないので、現在常駐しているメモリイメージがダーティであるかどうかを判定する方法がないからである。
【００９０】
上で説明したように、書込用にファイルをオープンしたトランザクションによってページが変更されるたびに、そのページが、その場ですなわちキャッシュ内で編集される。キャッシュは、その後、さまざまな時にディスクに書き込まれる（図８）。しかし、ページデータを変更する前に、古いページデータを保存する必要があり、その結果、トランザクションが中断されるかシステムが障害を発生した場合に、古いページデータを復元できるようにする。この目的のために、古いページが、ＴＯＰＳストリーム１３４にコピーされ、その変更が、ＴｘＦログ１２６にログ記録される。図１２に示されているように、ログレコード（たとえばＸ２）に、このページ内のオフセットが含まれ、これによって、ログ１２６がデータを維持する必要がなくなり、それに対応するレコードだけが維持される。したがって、ページの復元をイネーブルするために、ＴｘＦは、経時的な変更をシーケンシャルに記録する変更ログを使用する。バージョン管理のために、ＴｘＦログ１２６にアクセスするのではなく、効率のために、変更テーブル９８内のＴＯＰＳストリーム１３４へのオフセットが使用されることに留意されたい。しかし、システム障害の場合には、インメモリ構造体であるバージョンストリーム制御ブロックが、回復時に存在しない。さらに、インメモリだけのファイルのすべてのバージョンが、回復不能である。したがって、回復のために、ログ内のレコードを、障害中のトランザクションを中断し、障害の前にコミットされたトランザクションを耐久性のある形で完了するのに使用することができる。ログエントリ（またはログレコード）のシーケンシャルな性質によって、変更の順序が保存される。
【００９１】
本発明では、ページ書込に関するログレコードが、性能および他の理由から２つの部分に分割される。メインログとインラインの部分では、他のログに関する順序が保存され、他方の部分には、動作の詳細を提供する（かなり多数の）バイトすなわち変更されたページデータが含まれる。したがって、本発明の一態様によれば、図１２に示されているように、ページがトランザクションを介して変更されるたびに、古いページデータが、（隣接する）ＴＯＰＳストリーム１３４にコピーされ、変更がＴｘＦログ１２６にログ記録される。上で説明したように、トランザクショナルリーダーをコピーされたページにマッピングするためにテーブルを調整した後に、そのページを変更することができる。図１２に示されているように、ログレコード（たとえばＸ２）に、コピーされたページのストリーム内のこのページへのオフセットが含まれ、これによって、メインログでデータを維持する必要がなくなり、それに対応するオフセットを有するレコードを維持するだけでよい。
【００９２】
しかし、性能の理由から、これらのログは、異なる形でディスクにフラッシュされる。その結果、ページもログ１２６も、所与の時点で持続していない場合があり、たとえば、ログ１２６がディスクにフラッシュされ、かつ／またはページがディスクにフラッシュされる前にシステムに障害が発生する場合がある。ページデータが失われないことを保証する単純な方法が、この２つの間の順序付けを強制する、すなわち、ログレコードをディスクにフラッシュする前に必ずページをディスクにフラッシュすることである。その後、回復時にログを使用する時に、ログレコードが存在する場合に、そのレコードに対応する正しいページバージョンが、持続していることも既知になる。しかし、この順序依存性は、ログフラッシュ動作が、多数の関連しない要因に依存して異なるログに対してより効率的に動作するという点で、システム性能を大きく低下させることがわかった。たとえば、性能を改善するために、ページは、通常は、遅延書込を使用して、たとえば１時に１６ページなど、複数のセットでフラッシュされるが、ログは、満杯の時またはバックグラウンドプロセスで異なる時にフラッシュされる可能性がある。
【００９３】
本発明のもう１つの態様によれば、ページおよびログを、互いに関して任意の順序で、なおかつ障害の場合に正しいページが復元されることを保証する形で、永続ストレージにフラッシュできるようにするシステムおよび方法が提供される。これは、ログ１２６およびページデータに、事実上、この２つの情報を互いに一貫性のある状態で、たとえば時間的にリンクする情報を追加することによって達成される。具体的に言うと、ページの現在の状態を表すサイクルカウント１３６（たとえば、１バイトだが、任意選択として１ワードまたはさらに長い単位を使用することができる）が維持され、たとえば、サイクルカウントは、ＴＯＰＳストリーム１３４へのポインタが先頭にラップアラウンドするたびに増分され、そのサイクルカウントが、ログレコードと同期化される。
【００９４】
本発明の一態様によれば、図１２に示されているように、ＴＯＰＳストリーム１３４にコピーされたページに関連するログレコード内でサイクルカウント値を維持することによって、同期化が達成される。これは、図１２では、一般的に、レコードのデータフィールドの一部の展開された表現を提供する、符号１３８の箱によって表される。やはり図示されているように、各セクタの最後の部分（たとえばバイト）が、それを保存するためにログレコードにコピーされる。ページが、本明細書に記載のようにそれぞれ５１２バイトの８つのセクタを含むが、諒解されるように、他のページサイズおよび／またはセクタサイズが可能であることに留意されたい。また、ストリームデータ内の各セクタの最後の部分は、図１２で、各セクタの最後の部分で置換されたサイクルカウントを有するページデータの展開された表現を提供する符号１４０の箱によって一般的に示されるように、サイクルカウントに置換される。図１２で表されているように、ページとログレコードの両方がフラッシュされる場合に、各セクタの末尾のサイクルカウント値が、レコード内のサイクルカウント値と一致する、すなわち、両方が、一致する署名を有する。
【００９５】
ページデータ（インラインでない部分）だけがディスクに書き込まれた場合には、システムは、インライン（ログ）レコードを見つけず、したがって、そのページは、見つからず、復元されるものはない。この状態は、一貫性があることがわかっている。
【００９６】
しかし、レコードがログに存在する場合には、ページは、システムクラッシュの前にフラッシュされた場合とそうでない場合がある。図１３は、一般的に、ロールバック中にレコードに達した時に、ページおよびそのログレコードの両方がディスクにフラッシュされたかどうかを判定する論理を表す。まず、ステップ１３００で、レコードにアクセスして、ストリーム１３４への保管されたオフセットを介してページを見つける。次に、ステップ１３０２で、ページを読み取り、それから抽出された各セクタの最後の部分を読み取り、ステップ１３０４で、ログレコードに保管されたサイクルカウントと比較する。インライン（ログ）レコードだけがディスクに書き込まれた場合には、クラッシュの後に、インラインでない部分（ページデータ）の各セクタに保管された一意の署名（各サイクルカウント）が、インラインレコードデータに保管されたサイクルカウントと一致しない。この場合には、ステップ１３０６に示されているように、システムは、古いページがディスクに書き込まれなかったので、新しいページも書き込まれなかった（これは、２つのログがフラッシュされる場合に限ってフラッシュされる）と結論する。したがって、このページは、すでに、その前の、古い状態であることがわかる。
【００９７】
逆に、ステップ１３０４で、ログのサイクルカウントが、対応するページの各セクタの最後の部分のサイクルカウントと一致する場合には、ログとページの両方が、成功裡にフラッシュされたことがわかる。したがって、コピーされたページは、持続したことがわかり、これによって、ステップ１３０８で、ログレコードに保管された各セクタの最後の部分が、コピーされたページに復元される。
【００９８】
この時に、コピーされるページに、リーダーがアクセスすることができ、適当なバージョンを提供することができる。現在のページに対して行われたログ記録された変更のすべてを、新しいリーダーおよび／またはライタが見るのに使用することができる（ステップ１３１０）。この場合に、古いデータが正しく取り込まれ、中断の一部としてファイルページに復元されなければならないことがわかる。中断にもかかわらず、既存のトランザクショナルリーダーが、ＴＯＰＳストリーム１３４から古いデータを読み取り続けることに留意されたい。
【００９９】
各セクタの末尾の一意の署名の使用によって、さらに、ページのすべてではなく一部がコピーされた、引き裂かれた（部分的な）書込が検出されることに留意されたい。ディスクハードウェアは、セクタが完全に書き込まれることを保証するが、データのページ（たとえば８セクタ）が一単位として書き込まれることは保証しないことに留意されたい。その場合には、サイクルカウントが、「ｎ」と（おそらくは）「ｎ−１」の値の何らかの混合物になり、署名が、ログ記録された署名情報と一致しなくなる。そのような情況は、ページ全体が持続しなかったかのように扱われる。
【０１００】
サイクルカウント自体がラップアラウンドする時に、既存のページ（たとえば比較的長い時間にわたってメモリ内にあったページ）の署名を構成するカウントと一致し、したがって、部分的な書込が検出不能になる可能性があることに留意されたい。たとえば、ラップしたサイクルカウントが使用され、かつ、それがページに保管された既存のサイクルカウントと一致する場合に、署名は、ページのすべてまたはページの一部のどちらがコピーされる場合でも同一になる。理解されるように、この場合の署名検査は、実際にはそうでない時にページデータ全体が持続したことを示すはずである。
【０１０１】
この問題は、複数の方法で解決することができる。そのような解決策の１つが、各サイクルラップアラウンドイベントの後で一度ページを読み取って、一致がないことを検証することである。一致がある場合には、２つのサイクルカウントの一方を調整して、一致を回避することができる。これがサイクルラップアラウンドごとに１回だけ（すなわち、サイクルカウントが０にラップするたびに）発生することを保証するために、別の検証ビットマップ１４１を使用して、各ページの「検証」状態を維持することができる。すなわち、各ビットが、ラップの後にある状態になり、サイクルカウント一致についてページが初めて検査される時にトグルされる。フリースペースビットマップを使用して、ページが空いているか使用中かを追跡し、効率のために、上の解決策で、追加のビットマップを追加して検証状態を追跡することに留意されたい。
【０１０２】
代替の解決策（上で説明した読取および比較動作に対する）は、やはり検証状態を追跡することであるが、「検証」状態がページ使用の時にセットされる時に、サイクルカウントを、上で説明したようにページに書き込み、書込を強制することである。書込に成功する場合には、その書込は部分的でない。大きいＴＯＰＳストリームの場合に、この代替案は、サイクルカウントがページと一致することが比較的まれである可能性が高いので、少数の入出力Ｉ／Ｏ動作に起因してよくスケーリングされる。
【０１０３】
もう１つの代替案は、最初の２つの解決策を、ページ冗長性の検査と組み合わせることである。すなわち、ページが高速メモリに常駐する場合に、実際のディスク読取が不要なので第１（読取）代替案を実行し、そうでない場合に第２（書込）代替案を実行する。
【０１０４】
遅延やり直しの代替案
上で説明した回復機構は、ファイルのダーティページをコミット時にディスクに書き込み、これによって、トランザクションにまたがるページ書込のバッチ化が妨げられる。トランザクションにまたがるページ書込のバッチ化を達成するために、回復に関してその逆を実行する、代替の「遅延やり直し」方式を提供することができる。この方式では、やり直しレコードをログに書き込み、ベースファイルを読み取っているリーダーがない時に、古いコミットされたトランザクションをベースファイルに適用する。古いコミットされたバージョンの読取をサポートするために、変更を、インプレース（その場）で行うのではなく、ページの既存のインプレースバージョンがもはや不要である時に限ってインプレースでファイルに適用することができる。
【０１０５】
遅延やり直し方式は、インプレース更新方式によって使用される原理の多数を共有し、たとえば、非常に似た形のバージョン管理を、バージョン制御ブロックおよび複数のインメモリストリームを用いてサポートする。しかし、変更テーブルは、アンドゥではなく、やり直しページのＬＳＮを保持する。図１４に一般的に示されているように、最も古いディスクバージョンが、必ずベースファイルになり、より新しいバージョンは、その上での増分変更を構築する。より古いバージョンは、リーダーがいなくなる時に、ベースファイルにマージされる。この方式の主な長所を活用するために、複数のバージョンを、同一時にベースファイルにマージすることができ、したがって、Ｉ／Ｏ効率が得られる。複数のバージョンを同一時にマージすることのもう１つの利益は、ログを長い読取で効率的に読み取ることができることである。
【０１０６】
しかし、ログに、（おそらくは多数の）アクティブファイルについてメモリをバッキングするページが書き込まれる可能性があり、本質的に、シーケンシャルログが、回復ログの二役にもなるランダムページファイルになり、これがシステムのボトルネックになる可能性がある。
【０１０７】
インプレース更新方式に似て、最新バージョンは、更新可能である。すべてのバージョンに関連するバージョン制御ブロック（ＴｘＦＶＳＣＢ）があり、各ＴｘＦＶＳＣＢは、バージョンによって変更されたページ番号を記録するインメモリテーブルである変更テーブルをポイントする。各ページ番号と共に、少なくとも１回書き込まれている（やり直しイメージ）場合に、ディスク上のページを見つけるためにディスクアドレスを保管することができる。ディスクアドレスがないことは、ページが一度もディスクに書き込まれていないことを意味する。メモリを節約するために、ページがディスクに連続的に保管されている場合に、ページ範囲を１エントリに保管することができる。
【０１０８】
バージョンＬＳＮは、そのバージョンをコミットしたトランザクションのコミットレコードのＬＳＮである。現在更新可能なバージョンについては、そのようなＬＳＮはない。ＳＯＰポインタは、このバージョンに対応するセクションオブジェクトポインタ構造体へのポインタである。このポインタを使用して、インメモリページを見つけることができる。バージョン長も、同様に提供される。
【０１０９】
バージョン制御ブロックは、リスト内で時間順にリンクされる。最も古いバージョンが、ベースストリームであり、変更テーブルには、このバージョンのエントリが一切含まれない。
【０１１０】
オープンの時に、バージョンの１つが、上で説明した代替方式と同様に、ファイルハンドルに与えられる。最新バージョンのインメモリストリームは、ログによって部分的にバッキングされる（完全にベースファイルによるのではない）。したがって、ストリームに対する変更は、ログに書き込まれる。読取は、ページがバージョンウィンドウ内のどのバージョンでも変更されていない場合にはベースファイルから行われ、そうでない場合には、ログから行われる。
【０１１１】
読取の時に、そのバージョンに対応する変更テーブルに問い合わせて、ページがそのバージョンで変更されているかどうかを判定する。そうである場合には、Ｉ／Ｏを、ログ内の適当な場所に向けて、ページを取り込んで、フォールトを満足する。そうでない場合には、ページについて、次に前のバージョンに問い合わせる。この処理は、ページの最も最近にコミットされたコピーが見つかるまで継続される。複数のバージョンに、ページのコピーが含まれる場合には、ＶＭＭ呼出しによってそれらのメモリ常駐性（ｒｅｓｉｄｅｎｃｙ）を検査する。メモリ常駐ページが見つかった場合には、それをコピーし、そうでない場合には、最も最近のバージョンのＬＳＮを使用してログから読み取る。ページが、常駐性が検査された時とコピーが行われた時の間にシステムメモリからトリミングされたかどうかが重要でないことに留意されたい。というのは、再帰的なフォールトが生成され、その後にページがコピーされるからである。これらのページをコピーする先のシステムアドレスを得るために、キャッシュマネージャを使用して、それらをシステムアドレス空間にマッピングする。
【０１１２】
図１４では、４つのバージョンＶ０〜Ｖ３が示されており、（他の個数が実現可能であるが）、「Ｘ」を用いてマークされたページが、バージョン内の変更を表す。変更テーブル１４２０〜１４２３に、書き込まれたページのＬＳＮが示されている。最も最近の（更新可能な）バージョンの一部のページは、まだ書き込まれていない。このシナリオでは、ＦｉｌｅＯｂｊｅｃｔＢがページ５０にアクセスする例を検討されたい。ファイルバージョンＶ１の変更テーブル１４２１に、このページがそのバージョンで変更されていないことが示されている。したがって、フォールトは、そのページのファイルバージョンＶ０の常駐性を検査し、常駐する場合に（フォールトをとりあげないで）それをコピーすることによって処理される。ファイルバージョンＶ０が、ページ常駐を有しない場合には、ディスクから読み取る（この場合には、ベースファイルから）。
【０１１３】
もう１つの例として、ＦｉｌｅＯｂｊｅｃｔＢが、ページ２００にアクセスし、そのページが、メモリ内にある場合に、アクセスは単純に機能する。しかし、そうでない場合には、ページフォールトが生成され、読取は、ログのＬＳＮ２５００から読み取ることによって満足される。
【０１１４】
もう１つの例として、ページ１００にアクセスするＦｉｌｅＯｂｊｅｃｔＣを検討されたい。 このページは、バージョンＶ２で変更されていないので、バージョンＶ１が検査され、読取は、メモリイメージ（常駐する場合）から、またはログのＬＳＮ２０００を読み取ることのいずれかによって満足される。
【０１１５】
ファイル書込について、ページアウトの時に、ページが、ストリームオフセットおよびストリーム名も記述するやり直しレコードの形でログに書き込まれる。この時に、ＬＳＮが、そのバージョンの変更テーブルのページスロット内でマークされる。ページ書込は、システムスレッドの１つによってバックグラウンドで行われ、通常は、シーケンシャルページ順で書き込まれる。コミットの時に、そのバージョン内のダーティページが、ログに書き込まれ、それにコミットレコードが続く。ページが、トランザクション中に複数回書き出される場合には、複数のログ書込が行われる。これらの書込は、ログの末尾に行き、変更テーブルエントリが、新しい位置をポイントするように変更される。間に入る読取トランザクションなしでコミットの後に新しい書込トランザクションがスタートする場合には、メインメモリストリームが、新しいトランザクションによって再利用される。そうでない場合には、メインメモリストリームが、リーダーによって請求され、ライタトランザクションは、新しいストリームを作成し、これを処理する。遅延やり直し方式では、変更されたページが、ＴＯＰＳストリームに書き込まれて（まさにインプレース更新方式と同様に）、関連する利益が達成されることに留意されたい。
【０１１６】
クラッシュの後に、回復は、比較的簡単である。というのは、コミットされたトランザクションのやり直し情報が、ログにあり、メインデータストリームに簡単に適用できるからである。バージョン制御ブロックが、インメモリ構造体であり、したがって、回復時に存在しないことに留意されたい。
【０１１７】
古いリーダーがトランザクションを終了する時に、古いバージョンは、もはや保存する必要がない。そのような時に、バージョンが、最も古いものから始めて、１時に１バージョンずつメインストリームにマージされる。バージョンは、マージされる時に、バージョンのリンクリストから除去される。マージは、そのバージョンの変更されたページ（ページ番号は変更テーブル内でルックアップされる）をベースストリームにコピーし、ディスクに強制することによって、１時に１ページずつ行われる。このコピー動作では、現在常駐していないページについて、ログを読み取る。可能な場合には、ログからページ範囲を取り込むために、大量のＩ／Ｏが行われる。たとえば、図１４では、バージョン管理をサポートするためにバージョンＶ０がこれ以上必要でない場合に、バージョンＶ１をバージョンＶ０にマージすることができる。このマージは、バージョンＶ１をロックせずに行うことができる。というのは、マージが進行中である間は、各ページのコピーが、バージョンＶ１およびバージョンＶ０に存在し、バージョンＶ１の変更テーブルが、この処理を介して変更されないからである。
【０１１８】
マージが完了した後に、バージョンＶ１がバージョンウィンドウ内にない場合には、Ｖ１のバージョン制御ブロックを、単純にバージョンのリストから除去する。一般に、マージは、複数のバージョンがリーダーから解放されるまで遅延される。この例では、Ｖ０、Ｖ１、およびＶ２を、これらがバージョンウィンドウから出た時に、一緒にベースファイルにマージすることができる。複数バージョンマージについて、変更テーブルが、まず、同一エントリが複数のテーブル内で変更される時に、最高のバージョン番号からのＬＳＮが選択される形でマージされる。これは、本質的に、トランザクションにまたがる書込をバッチ化し、この方式の長所の１つである。バージョンをマージした後に、そのログレコードは、アクティブログからの除去の資格がある。
【０１１９】
一般に、マージは、できる限り早く行われる。リーダーがいなくなるたびに、バージョンウィンドウが前方に移動する。その時に、いくつかのバージョンを、マージの資格があるものとしてマークすることができる。複数のバージョンがマークされた時に、作業アイテムが、マージを行うためにシステムスレッドの１つに置かれる。
【０１２０】
インプレース更新方式と遅延やり直し方式の両方が、ほぼ同一の数のＩ／Ｏを実行する。インプレース更新方式は、アンドゥを同期式に読み取る（並列リーダーが最近読み取った場合など、アンドゥが時々メモリ内で見つかる場合があるので）。インプレース更新方式は、ページをベースファイルに書き出し、アンドゥをログにシーケンシャルに書き込む。対照的に、遅延やり直し方式は、やり直しを多数のランダムＩ／Ｏで書き込む必要があり、ログをランダムに読み取ってバージョンをマージする必要がある。さらに、遅延やり直し方式は、バージョンにまたがる書き込みを最小にするが、ファイルページをディスクに書き込む必要がある。これらのログページがメモリ内で見つかる可能性は、したがって、マージが遅延される長さに関して、非常に低い。
【０１２１】
いつどこでＩ／Ｏが行われるかに、定性的な差がある。遅延やり直し方式では、最も最近のメモリストリームが、ベースファイルではなく、ログによってバッキングされる。これは、最も一般的に使用されるストリームになる可能性が非常に高い。というのは、これが、更新された作業を処理し、比較的にログに重荷を課すからである。バージョン管理されるリーダーについて、両方の方式が、ログをページングデバイスとして使用する。
【０１２２】
遅延やり直し方式は、大量のトランザクション作業がバックグラウンドで実行されるので、コミット処理と同期して行う作業がより少ないが、書込ＡＰＩまたはメモリ更新がキャッシュに対して実行されるので、書込ＡＰＩまたはメモリ更新のそれぞれについて、ライタにとってより高速には見えない。その代わりに、コミット時のフラッシュに、コミットの応答性の差が現れる。より大きい更新トランザクションについて、バックグラウンドシステムスレッドが、非同期書込をスケジューリングする可能性が高く、これによって、多少は応答性の差が減る。同様に、インプレース更新方式は、ファイルＡＰＩに関するアンドゥ作業をバックグラウンドで行うことによって、多少はコミット時の重荷を減らすことができるが、ユーザがマッピングしたセクションで行われた変更について実現可能ではない。
【０１２３】
インプレース更新方式は、遅延やり直し方式より複雑でない。というのは、インプレース更新方式が、非同期マージ動作のスケジューリングの問題を扱う必要がないからである。また、インプレース更新方式は、フォアグラウンドアクティビティとバックグラウンドアクティビティの間の速度不一致の問題を扱う必要がない。この速度不一致は、時々、ログスペースをブロックし、リソース獲得問題を生じる。
【０１２４】
最後に、アーカイブ作成およびロールフォワードは、遅延やり直し方式を用いる場合に、やり直しレコードがログ内で使用可能なので、通常のランタイムログ記録アルゴリズムを変更せずに可能である。しかし、アンドゥレコードがないので、トランザクションに関してやり直しを適用する前に、トランザクションのコミット状況を見つけるために、ログの多少の前方スキャンを行う必要がある。
【０１２５】
ネットワークを介するファイルシステムトランザクション
リモートファイルは、図１５に一般的に示されているように、内部カーネル対カーネル「リダイレクタ」プロトコル（たとえば、ＳＭＢプロトコル）を介してアクセスされる。このプロトコルは、クライアントコンピュータ１４６で実行されるファイルシステム動作を、リモートコンピュータ１４８、たとえばサーバ上で反映する。もちろん、他のプロトコルおよび機構（たとえば、Ｗｅｖ  ＤＡＶ、ＮＦＳなど）によって、同等の結果を達成することができる。この目的のために、非トランザクショナルファイルシステムアクセスと同様に、リモートファイルが、識別され、ＩＲＰが、クライアントコンピュータ１４６上のリダイレクタファイルシステムドライバ１５０に向けられる。既知のように、このドライバ１５０は、クライアントコンピュータのキャッシュと対話して、データを読み取り、書き込む。リモートコンピュータのファイルシステム１５４に向けられたアプリケーション１５２からのファイルシステム要求などの要求（たとえば、リモートディスク１５６上のファイルＧ：＼Ｆｎａｍｅへのアクセス）は、リダイレクタドライバ１５０によってインターセプトされ、リモートコンピュータ１４８に送信され、ここで、エージェント１５８（デーモン）スレッドが、それらをドライバスタックの最上のファイルシステム動作に変換する。
【０１２６】
リモートトランザクショナルファイルシステム動作に関して、ファイルをオープンするために、クライアントリダイレクタが、たとえば、ＣＯＭ／ＯＬＥを使用して、ＤＴＣトランザクションオブジェクト１６０Ｃを、サーバ１４８にオープン要求と共に供給されるフラットバイトストリームにマーシャリングする。諒解できるように、他の機構が、同等の機能および／または結果を達成することができ、ＣＯＭ／ＯＬＥ動作を本明細書で説明するが、本発明のこの態様は、ＣＯＭ／ＯＬＥに制限されない。ＣＯＭ／ＯＬＥの例では、トランザクションオブジェクト１６０Ｃが、オープンを要求するクライアントスレッドにアタッチされる。サーバコンピュータ１４８は、そのカーネル空間内にＤＴＣトランザクションオブジェクト１６０Ｓのコピーを保持できる限り、トランザクションがどこから発するかに関係しないことに留意されたい。同様に、サーバ１４８は、トランザクションの代わりにどのスレッドまたはプロセスが働くかに関心を持たない。そうではなく、サーバ１４８のエージェント１５８が、フラットバイトストリームを使用可能なオブジェクトに変換し、このオブジェクトが、カーネル内で使用可能になる。この時に、サーバは、要求をローカルトランザクション１６０Ｓと同様に扱い、それをサーバ上の対応するＤＴＣプロキシ１６２Ｓに参加させ、本質的に、ＤＴＣに、後続のトランザクション作業についてサーバ１４８（および、リソースマネージャとしてその中のＴｘＦコンポーネント１６４）に連絡するように指示する。サーバが、このトランザクションオブジェクト１６０Ｓを所有するので、これが適当であることに留意されたい。トランザクションＩＤは、分散名前空間にあるので、トランザクションは、どこからでも発することができるが、トランザクションｉｄに基づく正しいファイル同期化は、サーバ１４８で行われる。
【０１２７】
サーバは、本質的に、ファイルシステム要求を、ローカルの場合に関するものであるかのように扱い、これによって、ローカルＴｘＦコンポーネント１６４が、トランザクショナルファイルシステム要求を処理する。しかし、サーバ１４８は、対応するファイルオブジェクトが、クライアント１４６によってオープンされたファイルに関するものであることを記憶し、クライアントがページをキャッシングしたことを記憶する。したがって、コミット時に、サーバ１４８は、クライアント１４６に（リダイレクタプロトコルを介して）そのキャッシュをサーバにフラッシュし、クライアント側でオープンされた可能性があるマッピングされたセクションのすべてをフラッシュする（クライアントが、マッピングされたセクションについて追跡する）ように通知する。データは、普通に、多少遅れた形で、すなわち、クライアントのキャッシュ／メモリからページアウトされる時に必ず、サーバ１４８に到達する。データが到達する時に、そのデータによって、サーバのキャッシングされたコピーが上書きされる。これが、複数のオープンハンドルまたはマッピングされたセクションがお互いを上書きする、従来のファイルシステムモデルに類似することに留意されたい。
【０１２８】
リダイレクタベースのファイル作成動作に関して、ユーザモードのＣｒｅａｔｅＦｉｌｅＥｘがＩＴｒａｎｓａｃｔｉｏｎオブジェクトを（たとえばＤＴＣのＩｔｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒメソッドを介して）バイトのフラットコレクションにマーシャリングするという、上で説明した概念が、ネットワークを介するＩＴｒａｎｓａｃｔｉｏｎのマーシャリングにも使用される。ＩＴｒａｎｓａｃｔｉｏｎＴｒａｎｓｍｉｔｔｅｒ呼出しではトランザクションマネージャとの通信が不要なので、これは比較的安価であり、したがって、作成ごとに行うことができる。しかし、Ｒｅｃｅｉｖｅ呼出し（上で説明した）は、トランザクションコーディネータ（またはそのプロキシ）との通信を必要とし、このトランザクションコーディネータは、リダイレクタベースの場合に、リモートコンピュータ１４８上にある。それにもかかわらず、ＩＴｒａｎｓａｃｔｉｏｎＲｅｃｅｉｖｅｒが、ネットワーク全体で（サーバ１４８上で）トランザクションごとに１回だけ行われるので、このトランザクションコーディネータ１６２Ｓとの通信のコストは、大きくない。
【０１２９】
したがって、このようにして、トランザクショナルリモートファイルアクセスが、透過的にサポートされる。すなわち、アプリケーションが、本質的に、リモートファイルアクセスを使用して、ならびに複数のコンピュータでアプリケーションプロキシを作成することによって直接に、ネットワーク上のどこにあるファイルでもアクセスすることができる。その結果として、同一のトランザクションに、１つまたは複数のローカルプロセスとリモートプロセスを同時に含めることができる。
【０１３０】
リダイレクタプロトコルは、一般的に、単一のクライアントがファイルをリモートアクセス用にオープンさせた場合について最適化される。その場合に、ファイルのローカルディスクキャッシュを保持することによって、多数のネットワークトラフィックが、回避される。変更は、必要な時だけすなわち、ファイルのクローズの時だけフラッシュされる。しかし、この配置は、別のクライアントが同一のファイルを同時にオープンした時に、必ずディスエーブルされる。便宜的ロック（ｏｐｐｏｒｔｕｎｉｓｔｉｃ  ｌｏｃｋ）（Ｏｐｌｏｃｋ、本質的に所有権を示すトークン）によってこれがイネーブルされ、これによって、上の「クローズ時にフラッシュ」方式に対する変更が最小になる。具体的に言うと、コミット時に、クライアントが、通常のように、サーバに変更をフラッシュするように求められる。中断の時には、クライアントが、クライアントハンドルを「運が尽きた」としてマークするように求められ、ハンドルがクローズされた後に、変更が単純に捨てられるようになる。リダイレクタプロトコルを強化して、サーバが、ローカルの場合と同様に、いくつかの情況でクライアントがマッピングしたセクションを無効化できるようにすることができることに留意されたい。
【０１３１】
名前空間分離
トランザクションの変更を他のトランザクションから分離することが、トランザクションの重要なプロパティである。トランザクショナルファイルシステムでは、分離が、ファイルに保管されるデータ（上で説明した）だけではなく、ファイルおよびファイルがその下で編成されるディレクトリの名前階層にも適用される。本発明のもう１つの態様によれば、ファイル／ディレクトリ名前階層内で名前空間分離を実施する技法が提供される。この技法は、トランザクションの期間にわたる名前またはディレクトリのロックを必要とせず、トランザクションに使用されているファイルに対して試みられる非トランザクショナル動作と共に動作する。
【０１３２】
たとえば、まだコミットしていないトランザクションによって作成されたファイルを検討されたい。ファイルの代わりに、ディレクトリを作成することができるが、説明を単純にするために、本発明を、主にファイルに関して説明することに留意されたい。しかし、ファイルおよびディレクトリが、以下で説明する名前空間動作に関して一般的に同等に扱われることを理解されたい。トランザクションによって作成されたファイル（またはディレクトリ）は、それを作成するトランザクションからは制約なしでアクセス可能でなければならないが、他のトランザクション、たとえばそれをオープンしようとする別のトランザクションまたはその親ディレクトリをリストしようとする別のトランザクションに可視になってはならない。作成するトランザクションがコミットする時に限って、そのファイルを他のトランザクションに可視にしなければならず、そのかわりに中断された場合には、ファイルが他のトランザクションに可視になってはならない。非トランザクション（たとえば、親ディレクトリの列挙を要求するもの）は、そのようなファイルを見るが、しかし、そのようなファイルを、コミットされるまで非トランザクションに不可視にすることが、代替的に可能である。
【０１３３】
同様に、ファイル（またはディレクトリ）が、まだコミットしていないトランザクションによって削除される場合に、削除されるファイルは、コミットの時まで、削除が全く発生しなかったかのように、他のトランザクションからアクセス可能であり続ける必要がある。しかし、削除するトランザクションは、削除の影響を見、その場所で同一の名前を持つ異なるファイルを作成することができる。コミット時に、削除されたファイルが、除去される。非トランザクションは、削除の影響を見る。すなわち、削除されたファイルを見ないが、非トランザクションは、そのファイル／ディレクトリを削除したトランザクションが中断し、削除が元に戻される場合の衝突を避けるために、コミットしていないトランザクションによって削除されたものと同一の名前の新しいファイルを作成することができない。やはり、その代わりに、非トランザクションを、異なるトランザクションであるかのように扱い、したがって、トランザクションによって削除されたファイルを見続けるようにすることが、実現可能ではあるが、これは好ましくない。
【０１３４】
さらに、ファイル（またはディレクトリ）が、トランザクションによって名前を変更される場合に、そのファイルは、他のトランザクションに関して元のディレクトリ内で元の名前で使用可能であり続け、新しい名前は、他のトランザクションに可視にならない。名前を変更するトランザクションは、名前変更の影響を見、古い名前を使用して異なるファイルを作成することができる。名前変更が、本質的に、新しいリンクの作成と古いリンクの削除の組合せであることに留意されたい。
【０１３５】
上で説明したシナリオを処理するために名前空間分離を達成するために、本発明は、トランザクションの期間について、他のトランザクションによる使用のために名前空間の状態を保存する。この目的のために、図１６〜１８に示されているように、分離ディレクトリ１７０１〜１７０４と称する別のディレクトリが、作成され、名前空間動作を実行するトランザクションによって変更される各々のＮＴＦＳディレクトリにリンクされる。具体的に言うと、各分離ディレクトリ（たとえば１７０１）には、親ディレクトリ（たとえばディレクトリＤ３）のＴｘＦＳＣＢ構造体に関連する検索構造体（たとえば、２進検索木）が含まれる。さらに、分離ディレクトリ検索構造体および関連する操作ルーチンに、エントリの追加、名前を用いるエントリの高速ルックアップをサポートし、ディレクトリ列挙アルゴリズムもサポートする一般インターフェースが含まれる。
【０１３６】
これらの分離ディレクトリには、名前空間変更を行ったトランザクションによって影響される個々の名前が含まれ、これらの分離ディレクトリは、メインメモリ構造体だけである。この構造体の各エントリには、名前に関連するトランザクションＩＤ（Ｔｉｄ）と、トランザクションＴｉｄに可視と他者に可視の２つのフラグを有する可視性ディスポジション（ｖｉｓｉｂｉｌｉｔｙ  ｄｉｓｐｏｓｉｔｉｏｎ）も含まれる。これらの可視性フラグの一方または両方を、独立にセットすることができる。分離ディレクトリ構造には、ＳｈｏｒｔＮａｍｅ／ＬｏｎｇＮａｍｅフラグも含まれ、ここで、ペアリングが使用可能である場合に、構造体に、ペアリングされた名前に対応する構造体へのポインタが含まれる。名前がＴｉｄによって予約され、他者がそれを請求できないことを示すフラグ、Ｆｉｄ（削除された名前および変更された名前に関してｃｒｅａｔｅ（）をリダイレクトするのに使用される）、および他の情報すなわち、ディレクトリ列挙に使用される、タイムスタンプおよび類似物などのＮＴＦＳによって複製される情報も提供される。スペース効率のために、構造体を、Ｎａｍｅ、情報へのポインタ、他の名前へのポインタ、および他の情報に分離することができる。これによって、２つの名前によって共有される他の情報の単一の組がもたらされる。
【０１３７】
分離ディレクトリが使用される方法の例として、図１６に示されているように、ファイルＦ３が、トランザクションＴ１によって削除される場合に、ファイルＦ３の名前およびさまざまな情報が、その名前がＮＴＦＳディレクトリＤ３から除去されるのと（本質的に）同時に、分離ディレクトリ１７０１に追加される。ＮＴＦＳでファイルを削除するためには、オープンファイルが削除についてマークされ、ファイルシステムが、オープンハンドルのカウントを維持しながらそのファイルをクローズし、オープンされたままのハンドルがなくなった時に削除を実行することに留意されたい。さらに、分離ディレクトリ１７０１は、このトランザクションＴ１または別のトランザクション（たとえばＴ２）による以前の動作から既に存在する可能性があり、あるいは、この削除動作をサポートするのに必要な場合に作成される可能性があることに留意されたい。削除動作を、さらに、以下で図１９の流れ図に関して説明する。
【０１３８】
このファイルＦ３への、異なるトランザクション（たとえばＴ２）による後続のアクセスは、分離ディレクトリ１７０１を使用してサービスされ、これによって、トランザクションＴ２が、ファイルＦ３を見続ける。しかし、ファイルＦ３を削除したのと同一のトランザクションＴ１（または非トランザクション）が、ファイルＦ３を探す場合には、このファイルが見つからない。この情況を処理するために、上で説明したように、ファイルの名前、その可視性ディスポジション、ファイルを削除したトランザクションのＩＤ、リダイレクトファイルＩＤ、＄ＴｘＦファイル識別子（たとえば、単調増加するシーケンス番号）、および複製情報（日付スタンプ、サイズ、属性）が、ファイルについて維持される。
【０１３９】
図１９に、オープンされているファイルの削除の要求を処理する一般的な論理の表現を示す。図１９および類似する流れ図が、分離ディレクトリが使用される方法の理解を提供するために単純化されており、基礎となるコードの正確な表現とみなされてはならず、たとえば、特殊な場合、エラー処理などが含まれないことに留意されたい。どの場合でも、ステップ１９００で開始されて、トランザクショナルな要求の要求元エンティティとトランザクショナルでない要求の要求元エンティティの間の区別を行う。というのは、トランザクショナルな要求に係るユーザが、トランザクショナルでない要求に係るユーザの削除動作と異なる動作をもたらすからである。トランザクショナルでない要求がファイルの削除を要求している（そのハンドルによって識別される）場合には、削除が、それ以外は通常の形で実行される。すなわち、ステップ１９０２で、指定されたファイルがディスクから削除される。削除は、最後のハンドルがクローズされた時に始まる。
【０１４０】
ステップ１９００で、トランザクション（たとえばＴｉｄ１）が削除を要求している場合に、ステップ１９０４が実行され、ここで、本質的にファイルの名前が変更される。たとえば、図１６に一般的に示されているように、任意の名前（たとえば「０」）が、隠されたディレクトリ１６８（＄ＴｘＦ）に追加され、この名前が、マスタファイルテーブル１３０（図１１）のファイルのレコードにリンクされる。それと同時に、削除されたファイルＦ３からのリンクが、親ディレクトリＤ３から除去される。
【０１４１】
その後、削除情報すなわち、ファイル名Ｆ３、元の親に関する参照、および新しいリンク情報が、ステップ１９０６で削除レコードにログ記録される。ファイルを削除しつつあるトランザクションがコミットする前にシステムがクラッシュする場合には、トランザクションが中断され、ログから、上で説明したようにファイルの名前を単純に変更することによって、すなわち、前のリンクを復元することによって（＄ＴｘＦディレクトリは、インメモリ構造体なのでなくなる）ファイルが正しく復元される。
【０１４２】
本発明によれば、ファイル情報が、通常のディレクトリＤ３にリンクされた分離ディレクトリ１７０１に追加される。分離ディレクトリ１７０１は、通常のディレクトリに関連して既に存在する場合があるが、そうでない場合には作成される。ステップ１９１０を実行して、トランザクションＴｉｄ１がこのファイルの削除を要求したことを示すように可視性ディスポジションフラグを適用に調整し、その結果、このファイルが、他のトランザクションにはまだ可視であるが、Ｔｉｄ１には不可視になるようにする。ステップ１９１２で、任意の名前を付けられたリンクを、後に（すなわちトランザクションがコミットした後に）ディスクから削除されるファイルのリストに追加する。
【０１４３】
トランザクションに対応する名前エントリは、そのトランザクションが終了する時に分離ディレクトリから除去され、分離ディレクトリは、そこに残っているエントリがなくなった時に、削除することができる。システムがクラッシュする場合に、インメモリ構造体である分離ディレクトリが、失われることに留意されたい。しかし、クラッシュによって、コミットされていないトランザクションが中断されるので、分離ディレクトリは、もはや分離のために必要ではなくなり、ログファイルのアンローリングによって、ファイルの状態が適当にリセットされる。
【０１４４】
ファイルの作成は、ファイルがトランザクション（たとえばＴｉｄ２）によってディレクトリ内で作成される時に、名前が、（親）ＮＴＦＳディレクトリにリンクされた分離ディレクトリに実際に追加されるという点で、削除に多少似ている。他のトランザクションに関して、名前は、トランザクションがコミットするまで、ファイルをオープンする目的に関するまたは親ＮＴＦＳディレクトリをリストする時の可視性フラグの設定によってフィルタアウトされる。Ｔｉｄ２および非トランザクションに関して、作成されたファイルは、コミットされる前に可視である。
【０１４５】
名前を付けられたエントリは、追加された後に、トランザクションによって変更することができる。たとえば、ファイルが削除され、同一の名前を使用して別のファイルが作成される場合に、作成によって、エントリの状態が変更され、他のトランザクションが、削除の前に存在したファイルを見続けるが、このトランザクションが、作成されたばかりの新しいファイルを見るようになる。ＮＴＦＳディレクトリまたは分離ディレクトリに対して、トランザクションレベルのロックが保持されないことに留意されたい。これによって、システムが、ベースファイルシステムより並列性が低くならないようにすることができる。
【０１４６】
図１８に示されているように、ファイルＦ６が、トランザクションＴｉｄ２によって作成される（作成は、普通の親ディレクトリＤ４内で要求される）場合に、Ｆ６が、ディレクトリＤ４内に作成され、それのためのエントリが、親ディレクトリＤ４に関連する分離ディレクトリ１７０２に追加される。分離ディレクトリ１７０２は、必要であれば作成される。フラグが、Ｔｉｄ２の作成状況を反映するように適当に調整される。すなわち、Ｔｉｄ２に可視であるが、他のトランザクションには不可視になり、名前がＴｉｄ２用に予約される。トランザクションＴｉｄ２が、Ｔｉｄ２がコミットする前に、新たに作成されたファイルＦ６を削除することもできるが、この場合に、ファイルＦ６は、Ｔｉｄ２にも他者にも可視にならないことに留意されたい。そのような作成−削除動作を処理する方法の１つが、ディレクトリＤ４からエントリを除去し、分離ディレクトリ１７０２からエントリを除去することである。もう１つの方法は、分離ディレクトリ１７０２にエントリを残し、ディスポジションフラグを、作成するＴｉｄ２と他者の両方に対して不可視にセットし、これによって、Ｔｉｄ２がコミットまたは中断するまでファイル名が他者によって使用されなくすることである。
【０１４７】
トランザクションＴｉｄ２によってＦ６が作成されるが、削除されない、通常の情況に戻ると、トランザクションＴｉｄ２がコミットまたは中断する時に（その場合に）、分離エントリが、分離ディレクトリ１７０２から除去され、したがって、作成されたファイルＦ６が、コミットの場合にどのトランザクションにも可視にされる。トランザクションＴ２が中断する場合には、ファイルが、通常のＮＴＦＳディレクトリＤ４から削除される。各分離エントリは、それに関連するトランザクションの終了まで残され、コミットまたは中断の時に除去される。除去を容易にするために、各トランザクションは、そのトランザクションが少なくとも１つのエントリを有するＴｘＦＳＣＢポインタのリストを維持する。トランザクションはまた、ＴｘＦＳＣＢのそれぞれの参照カウンタを適当に増分または減分し、その結果、ＴｘＦＳＣＢが、それを使用するトランザクションによって存在を維持されるようにする。
【０１４８】
図２０に、要求がＮｅｗ＿Ｆｉｌｅ＿Ｃｒｅａｔｅ（たとえば、同一のファイル名を有するファイルが既に存在する場合に作成が許可されないタイプの）である場合の、ファイルの作成に関する要求を処理する一般的な論理の表現を示す。ステップ２０００で開始して、テストを実行して、ファイル名（たとえば図１７のＦ６）が、普通の親ディレクトリ、たとえば親ディレクトリＤ４に既に存在するかどうかを判定する。そうである場合には、ファイルを作成することができず、ステップ２０００は、ステップ２００２に分岐し、ここでエラーを返す。ファイルＦ６が、親ディレクトリＤ４で見つからない場合に、ファイル名が既にトランザクションによって使用されている可能性がある。これをテストするために、ステップ２０００は、ステップ２００４に分岐し、ここで、Ｄ４に関連する分離ディレクトリ１７０２を、このファイル名について検索する。このファイルＦ６（または分離ディレクトリ）のエントリが存在しない場合には、ステップ２００４は、ステップ２００６に分岐し、ここで、トランザクションまたは非トランザクションのどちらが作成を要求しているのかに関する判定を行う。非トランザクションが要求している場合には、ステップ２００６は、ステップ２０１８に分岐し、ここで、普通のディレクトリＤ４にファイルを作成する。そうでない場合には、トランザクション（たとえばＴｉｄ２）が作成を要求しており、ステップ２０１０が実行されて、そのファイルのエントリが分離ディレクトリ１７０２に追加される（親ディレクトリＤ４についてまだ存在していない場合には分離ディレクトリ１７０２を作成した後に）。その後のステップ２０１４は、適当なフラグを設定すること、このエントリに関する他の情報を得ることなどを表す。ステップ２０１４は、ステップ２０１８に継続し、ここで、ファイルＦ６が、実際に普通のディレクトリＤ４に作成される。ＮＴＦＳでは、作成時に、ファイルが割り振られ、ファイルレコードがそのファイルのマスタファイルテーブル内で作成され、作成レコードがログに追加されることに留意されたい。
【０１４９】
ステップ２００４で、名前が分離ディレクトリ１７０２で見つかった場合には、指定されたファイルが、現在作成を要求しているものと同一のＴｉｄ（たとえばＴｉｄ２）によって削除されない限り、作成は許可されない。このようにして、トランザクションは、それが削除したファイルを作成することができるが、他のトランザクションまたは非トランザクションは、ファイルを作成し、かつ／または削除したトランザクションがコミットするか中断するまで、そのファイル名を使用することができない。見つかった場合には、ステップ２０１２を実行して、フラグ状況をテストして、同一のトランザクションが現在作成を要求しているかどうかを判定する。そうである場合には、ステップ２０１２は、ステップ２０１４に分岐して、このエントリのフラグの状況を変更し、本質的に「Ｔｉｄ２によって削除」（Ｔｉｄ２に不可視、おそらく他者に可視）ではなく、「Ｔｉｄ２によって作成」（Ｔｉｄ２に可視、他者に不可視）を表すようにする。別のトランザクションまたは非トランザクションが作成を要求している場合には、ステップ２０１２が、ステップ２０１６に分岐して、エラーを返し、トランザクションがこのファイル名を予約していることを示す。
【０１５０】
図１８は、本質的にリンク作成要求とリンク削除要求を組み合わせたものである、トランザクショナルファイル名前変更動作を表す。したがって、トランザクションＴ１が、ファイルの名前「＼Ｄ２＼Ｄ３＼Ｆ２」を「＼Ｄ２＼Ｄ３＼Ｄ４＼Ｆ７」に変更する場合に、リンクＦ２が、ディレクトリＤ３から削除され、リンクＦ７が、ディレクトリＤ４に作成される。しかし、トランザクションが名前の変更にかかわっているので、この動作は、適当な分離ディレクトリ１７０３および１７０４で反映される。ファイルが、同一の親ディレクトリ内で名前を変更される場合があり、あるいは、ファイルが同一のファイル名を有するが、異なるディレクトリにあるように名前を変更される場合があることに留意されたい。
【０１５１】
本発明によれば、ファイルのトランザクショナル名前変更に関して、名前変更に用いられる各親ディレクトリの分離ディレクトリ、たとえば、トランザクションの削除動作を示す分離ディレクトリ、およびトランザクションの作成動作を示す分離ディレクトリが提供される。同一の親ディレクトリ内での名前変更が、古いファイルの削除に関する１エントリと、新しいファイルの作成に関する１エントリとを有する１つの分離ディレクトリだけを必要とすることに留意されたい。上で説明した図１９（削除）および２０（作成）から理解できるように、他のトランザクションは、トランザクションがコミットするまで、名前が変更されなかったかのようにファイルを見、名前を変更されたファイルを見ない。トランザクションが中断する場合には、他のトランザクションは、使用中のファイル名がトランザクションの寿命の間に一時的に予約されることを潜在的に見ることを除いて、名前変更が行われたことを示すものを一切見ない。
【０１５２】
最後に、図２１〜２２は、ファイルのオープンまたはそのファイル情報を得る（たとえば列挙の一部として）ことを試みる時などに、ファイルの状態に応じて、トランザクションが指定されたファイルを見るか否かを表す。ステップ２１００は、ファイルが普通の親ディレクトリにあるかどうかのテストを表す。そうである場合には、分離ディレクトリが存在する場合に、このファイルのエントリについて分離ディレクトリを検索して、ファイルが要求元に可視であるかどうかを判定する必要がある（ステップ２１０２）。普通のディレクトリにない場合には、ファイルが、進行中のトランザクションによって普通のディレクトリから削除された可能性があり、これは、下の図２２で処理される。
【０１５３】
ファイルが普通のディレクトリにあり（ステップ２１００）、ステップ２１０２でファイルのエントリが分離ディレクトリにない場合には、そのファイルは、普通にアクセス可能なファイルすなわち、まだコミットしていないトランザクションによって作成されたものではないファイルである。そうである場合には、ファイルシステムは、トランザクションの前と同様に動作する（ステップ２１０４によって表される）。すなわち、ファイルハンドルを返すことができ（たとえば、ファイルオープン要求の場合に）、あるいは、マスタファイルテーブル内の情報からファイル情報を返すことができる（たとえば、列挙要求の場合に）。
【０１５４】
ファイルのエントリが、分離ディレクトリツリーにある場合には、そのファイルは、進行中のトランザクションによって作成されたものである必要があり、ステップ２１０２は、ステップ２１０６に分岐し、テストを実行して、ファイルを作成したトランザクションが、現在アクセスまたはその情報を要求しているトランザクションと同一であるかどうかを判定する。そうである場合には、ステップ２１０６は、ステップ２１０８に分岐し、可視性ディスポジションフラグ（このＴｉｄに可視であるかどうか）をテストすることができる。可視の場合には、ファイルハンドル（またはファイル情報）を、要求しているトランザクションに返す（ステップ２１１０）。本実施形態では、ファイルが普通のディレクトリにあり、そのエントリが分離ディレクトリにある（トランザクションによる作成のゆえに）が、ファイルを作成したトランザクションにファイルを可視にしてはならないことをフラグが示す情況があってはならないことに留意されたい。したがって、本実施形態では、ステップ２１０８のテストが、普通のディレクトリおよび／または分離ディレクトリの破損または類似物を検出するのに使用されるのでない限り、本質的に不要である。
【０１５５】
ファイルのエントリが、普通のディレクトリにあり（ステップ２１００）、分離ディレクトリツリーにある（ステップ２１０２）が、ステップ２１０６で、同一のトランザクションが要求を行っているのではないと判定される場合には、本実施形態では、ファイルが、ステップ２１１４で、他者に可視である場合もそうでない場合もある。可視でない場合には、ステップ２１１６で、要求の一部として、他のトランザクションがそのファイル名を使用することを要求している場合に、ファイルが別のトランザクションによって使用中であることを示すエラーが返されることを除いて、見つからなかったものとしてファイルを扱う。たとえば、指定されたファイルが見つからない場合に新規ファイルの作成を試みるタイプのファイルオープン要求は、名前が使用中なのでエラーになる。ステップ２１１４で他者に可視である（ファイルが、削除された後に作成された）場合には、リダイレクトＦｉｄを使用して、＄ＴｘＦディレクトリから削除されたファイルをオープンする（ステップ２１１８）。
【０１５６】
図２２では、ファイルが普通のディレクトリにない情況を処理する。まだコミットも中断もしていないトランザクションがファイルを削除した場合には、そのファイルのエントリが、分離ディレクトリにあり、これによって、そのトランザクションはこのファイルを見ることができないが、他者は見ることができる。ステップ２２００で、ファイルのエントリが分離ディレクトリにない（かつ、図２１のステップ２１００を介して普通のディレクトリにない）かどうかをテストし、ない場合には、ステップ２２０２で、ファイルが見つからず、それに応じて扱われる。
【０１５７】
そうではなく、ステップ２２００で、名前が分離ディレクトリに存在する場合には、あるトランザクションがそれを削除している。ステップ２２０４で、ファイルを削除したのと同一のトランザクションがそのファイルへのアクセス（またはそれに関する情報）を要求しているかどうかをテストする。そうである場合には、ステップ２２０６で、ファイルが、それを削除したトランザクションに可視ではなく、したがって、見つからない状態（ステップ２２０６）が存在する。なんらかの理由でファイルがトランザクションに可視である場合には、エラーが存在することに留意されたい。
【０１５８】
ステップ２２０４で、ファイルを削除したものと異なるトランザクションが、そのファイルへのアクセス（またはそれに関する情報）を要求している場合。ステップ２２１２によるテストで、ファイルが他者に可視である場合には、ステップ２２１４で、そのファイルのハンドルまたはファイル情報（以下で説明するように、保存されたファイルＩＤまたはＦｉｄからの、複製された情報を含む）を返す。
【０１５９】
１つの他の可能性は、進行中のトランザクションが、ファイルを作成し、その後、削除し、これによって、そのファイルが普通のディレクトリにないことである。上で説明したように、ファイル名は、他者に使用可能として扱われるか、トランザクションのコミットまたは中断のいずれかが発生するまで進行中のトランザクションに予約されるかのいずれかになることができる。前者は、ファイルを作成したトランザクションがそのファイルを削除する時に、普通のディレクトリおよび分離ディレクトリの両方からファイルのエントリを単純に除去することによって達成することができるが、そのようなファイルエントリが分離ディレクトリから除去される場合に、ステップ２２１２に到達しないことに留意されたい。後者は、削除の際にファイルを普通のディレクトリから除去するが、分離ディレクトリ内のファイルのエントリを残し、どのトランザクションにも不可視であることを示すようにフラグをセットすることによって、達成することができる。諒解されるように、これが可能であるのは、可視性ディスポジションフラグが独立にセットされる（すなわち、相互排他的ではない）からである。しかし、ファイルが分離ディレクトリに残され、他者に（ならびに、それを作成したトランザクションに）不可視とマークされる場合に、ステップ２２１６で、ファイルが見つからない状態が存在するが、ファイル名は進行中のトランザクションに予約される。
【０１６０】
このようにして、本発明は、ＮＴＦＳ照合ルールおよびＮＴＦＳルーチンを使用して、たとえば照合された順序で次の名前を見つける、照合検索を容易にする。本発明は、スペース効率がよく、並列読取／書込アクセスを可能にする。
【０１６１】
見るものまたは見ないものにおいて、非トランザクションが、単純に、普通のディレクトリにあるものを見ることに留意されたい。しかし、既存ファイル名の使用において、非トランザクションは、トランザクションに予約された名前を使用することができない。この目的のために、非トランザクションが普通のディレクトリに存在しない名前を有するファイルの作成を試みる時に、上で説明したように、分離ディレクトリが検査される。
【０１６２】
上の例および説明に鑑みて、以下の説明で、トランザクションが分離ディレクトリ内のエントリをどのように使用し、変更するかを示す。まず、ディレクトリＸでＹｉｓＡＶｅｒｙＬｏｎｇＮａｍｅという名前の新しいファイルを作成する、すなわち、Ｘ＼ＹｉｓＡＶｅｒｙＬｏｎｇＮａｍｅを作成するトランザクションＴｉｄ１０を検討されたい。分離ディレクトリに、下記の２つのエントリが追加される。
0004219589.tif 000006
【０１６３】
これによって、Ｘの後続のディレクトリ列挙で、それがＴｉｄ１０以外のトランザクションによって行われる場合にこれらの名前のどれもが返されないが、非トランザクションが２つの名前を見ることが保証される。さらに、別のトランザクションＴｉｄ２０が、この２つの名前のいずれかの作成またはオープンを試みる場合に、そのトランザクションが、上の分離構造体から検出される、「ファイルが既に存在するが共有違反」エラーを受け取る。
【０１６４】
トランザクショナルでないスレッドがこの名前のどちらかをオープンする場合に、そのスレッドは、書込、削除、または他の種類の変更のためにオープンする場合に、共有違反を受け取る。そのような非トランザクションは、読取専用でオープンすることができる。これは、上で説明したように別に実施される、ＴｘＦのファイルロッキングセマンティクスに起因する。
【０１６５】
第２の例である、親ディレクトリＸからの既存ファイルＹｉｓＡＶｅｒｙＬｏｎｇＮａｍｅのトランザクショナルな削除を検討されたい。この例では、この名前に関する短い名前のリンクもディレクトリＸにある（リンク削除の場合ではなく、名前対の場合）。やはり、トランザクションは、識別子Ｔｉｄ１０を有し、これによって、分離ディレクトリに、下記の２つのエントリが追加される。
Name:YisAVeryLongName;
Tid:10;
(Visible to Tid:FALSE, Visible to others:TRUE);
LongName:TRUE;
pairedNamePtr: 短い名前のエントリへのポインタ;
Reserved: TRUE;
Fid: ファイルId;
他の複製された情報。
Name:YisAVery;
LongName: FALSE;
pairedNamePtr: 長い名前のエントリへのポインタ.
【０１６６】
２つのリンクは、ディレクトリＸのインデックスＳＣＢからも削除されるが、さしあたり、ファイルが物理的に除去されないことをＴｘＦが保証すると仮定する。というのは、ＴｘＦが、削除の前にファイルにシステム所有のリンクを追加するからである。その結果、２つの名前のどちらもが、Ｔｉｄ１０以外のものが新しいファイルの作成またはリンクに使用することができなくなる。これは、Ｔｉｄ１０が、中断し、名前を再請求することを決定できるからである。また、これらの名前は、ディレクトリ列挙またはＣｒｅａｔｅでＴｉｄ１０に可視でないが、このＣｒｅａｔｅによって、Ｔｉｄ１０が、２つの名前のいずれかを用いて新しいリンク／ファイルを作成することができるようになる。これらの名前は、他のトランザクションに可視であり、これは、他のトランザクションが、ファイルＩＤ（Ｆｉｄ）を使用してそれらをオープンできることを意味する。トランザクショナルでない要求に係るユーザは、これらのファイルを見ることができないが、これらの名前を新規作成に使用することもできない。
【０１６７】
第３の例では、第１の例が前に発生した、すなわち、ファイルが作成されたと考慮されたい。その後、名前がトランザクションＴｉｄ１０に可視なので、Ｔｉｄ１０は、自由にこのファイルをオープンでき、Ｔｉｄ１０と同様に削除することができる。したがって、Ｔｉｄ１０が、書込のためにファイルをオープンし、後にこれを削除した場合に、削除の後の分離エントリは、次のようになる。
0004219589.tif 000007
【０１６８】
これらのエントリでは、トランザクションのために名前が予約されるが、すべてに不可視にされる。予約が、ロールバックを動作可能にするために実行されることに留意されたい。
【０１６９】
浮動化されたメモリマッピングされたセクション
本発明のもう１つの態様は、アプリケーションが、書込アクセスのためにオープンされた１つまたは複数のファイルに対するメモリマッピングを実行しており、アプリケーションがその一部であるトランザクションが中断した（またはコミットした）ことを意識しない場合の問題の解決を対象とする。これは、たとえば、分散トランザクションが、もう１つのノードネットワークノード上で中断した時に発生する可能性がある。アプリケーションは、そのような時に、不適当にまたは不当に振る舞う場合もある。
【０１７０】
アプリケーションが、書込アクセスのためにオープンされたファイルに対してメモリマッピングを実行しており、それに関連するトランザクションが中断（またはコミット）したことを意識せず、かつ／または、不適当にまたは不当に振る舞っている時に、もう１つのライタが、書込アクセスのためにまだメモリマッピングされているファイルをオープンすることができる。その結果、複数の同時ライタ（ｓｉｍｕｌｔａｎｅｏｕｓ  ｗｒｉｔｅｒｓ）が存在する可能性があるので、ファイルデータに関する衝突が発生する可能性がある。具体的に言うと、アプリケーションによって実行される時に、メモリマッピングは、セクションオブジェクト（共有メモリのブロック）を使用して、ファイルをプロセスアドレス空間にマッピングすることを指す。アプリケーションがページを修正する場合に、メモリマネージャが、通常のページング動作中に変更をディスクのファイルに書き戻すことができ、あるいは、アプリケーションが直接にフラッシュを引き起こすことができる。トランザクショナル環境では望ましくないが、アプリケーションは、メモリマッピングを実行することを許可され、したがって、別のトランザクショナルアプリケーションによって書込アクセスのためにオープンされているファイルへの書込を引き起こす可能性を有する。
【０１７１】
ファイルシステムは、トランザクションがコミットまたは中断する時を知っており、たとえば、そのトランザクションによって影響されたデータ構造体をクリーンアップするが、メモリマネージャに照会して、トランザクションのアプリケーションプロセス（の１つまたは複数）がメモリマッピングを行っているか、すなわち、セクションハンドルを作成したかどうかを判定する。そのようなアプリケーションが存在する場合には、ファイルシステムは、そのアプリケーションの動作状態を知らず、直接にアプリケーションをシャットダウンすることも、またはアプリケーションがマッピングされたセクションに書き込み続けないことを保証することもできない。
【０１７２】
図２３に、ファイルシステム６２が、別のアプリケーション１８２によって書込アクセスのためにオープンされるマッピングされたファイルにアプリケーション１８０（もはやトランザクションの一部ではない）が書き込まないようにする方法の１つを示す。この目的のために、ファイルシステムは、セクション制御ブロック（ＳＣＢ）１８８を調整し、その結果、各々のアプリケーション１８０および１８２のファイルオブジェクト１８４および１８６が、別個のセクションオブジェクトポインタ１９０および１９２をポイントするようにする。無効なトランザクショナルアプリケーション１（１８０）のセクションオブジェクトポインタ１９０は、空であるが、有効なトランザクショナルアプリケーション２（１８２）のセクションオブジェクトポインタ１９２は、そのアプリケーション１８２のメモリ１９６へのポインタを有する。これによって、メモリセクション１９４が、浮動化される。
【０１７３】
無効なトランザクショナルアプリケーション１８０は、浮動化されたメモリセクション１９４から読み取るか、それに書き込むことを継続することができるが、このメモリセクションは、もはやファイルに対応しない。それと同時に、ページが、有効なアプリケーション１８２の代わりにファイルシステム６２を介してキャッシュ／メモリマネージャ１１４によってページがフォールトされる時に、必ず、適当な仮想メモリページ１９８が（したがって、アプリケーション１８２によって使用されるメモリ１９６も）、トランザクショナルに正しいファイル、たとえば、ＴＯＰＳストリームバージョンで維持される正しいページから、またはディスクのファイルから、適宜データを書き込まれる。ファイルシステム６２は、同様に、有効なアプリケーションによって変更されたページを、メモリマネージャ１１４による指示に従ってディスク１１２に書き込む。
【０１７４】
しかし、無効なアプリケーション１８０にマッピングされたセクション内のページについて、メモリセクション１９４に対応するファイルシステム６２に達するメモリマネージャ１１４からのすべての書込要求が、ファイルシステム６２によって受け入れられるが、実際にはディスクに書き込まれない。その結果、マッピングされたメモリが、浮動化されたセクションになり、メモリ内での書込が許可されるが、その変更は、絶対にディスクにフラッシュされない。メモリマネージャ１１４によるディスク１１２からのページのフォールトインの要求は、０がそこに返されることをもたらす。その結果、セクション１９４のこのバージョンは、もはやディスク上のファイルによってバッキングされない。このようにして、有効なトランザクショナルアプリケーションのファイルデータが、無効なアプリケーションによってマッピングされたファイルに対して行われるデータ変更から分離される。
【０１７５】
代替案では、メモリのマッピングされたセクションを、無効なアプリケーションに対してアクセスなしまたは読取専用に変更し、これによって、無効なアプリケーションによるそれへの書込がアクセス違反を引き起こすようにすることが可能である。読取が許容される場合には、無効なアプリケーションは、有効なアプリケーションによって行われた変更がセクション１９４にフォールトされる時に、必ず、そのような変更を見ることができる。
【０１７６】
上の解決策のどれもが、無効なアプリケーション１８０のクラッシュを引き起こす可能性があるが、有効なアプリケーション１８２のデータが、正しく分離されることに留意されたい。無効なアプリケーション１８０のクラッシュを避けるために、それによって行われた変更を、ディスクの別のファイルに書き込むことができるが、現在、そのようなポストトランザクションバージョンのサポートは、そのようなアプリケーションに関して無用にコストが高いと見なされている。
【０１７７】
0004219589.tif 000008
0004219589.tif 000009
0004219589.tif 000010
0004219589.tif 000011
0004219589.tif 000012
0004219589.tif 000013
0004219589.tif 000014
0004219589.tif 000015
0004219589.tif 000016
0004219589.tif 000017
0004219589.tif 000018
0004219589.tif 000019
0004219589.tif 000020
0004219589.tif 000021
0004219589.tif 000022
0004219589.tif 000023
【０１７８】
前述の詳細な説明からわかるように、アプリケーションが１つまたは複数のファイルに対して複数のトランザクショナル動作を簡単に実行できるようにするトランザクショナルファイルシステムおよび方法が提供される。複数のファイルシステム動作が、ファイルシステム内でトランザクショナルな形で一緒に結び付けられ、動作が、一緒にコミットされるか、すべての部分的なアクションが元に戻されるかのいずれかになる。さらに、あるトランザクションの動作およびデータ変更が、別のトランザクションの動作およびデータから分離される。したがって、たとえば、本発明は、素早く効率的で安全な形で、ファイルシステムコンポーネントによって処理される単一のトランザクションとしてウェブサイトを更新することができる。それと同時に、進行中の変更が、トランザクションがコミットするまで他者から分離される。
【０１７９】
本発明は、さまざまな修正構成および代替構成の余地があるが、ある例示の実施形態が、図面に示され、上で詳細に説明された。しかし、開示された特定の形態に本発明を制限する意図はなく、逆に、本発明は、本発明の趣旨および範囲に含まれるすべての修正構成、代替構成、および均等物を含むことを理解されたい。
【図面の簡単な説明】
【図１】  本発明を組み込むことができるコンピュータシステムを表すブロック図である。
【図２】  本発明の一態様によるトランザクショナルファイルシステムを実施する一般的なアーキテクチャを表すブロック図である。
【図３】  本発明の一態様による、トランザクション処理されるファイルの作成／オープンに関する要求を表すブロック図である。
【図４】  本発明の一態様による、オープンされたトランザクション処理されるファイルに対してファイルシステム動作を実行する要求を表すブロック図である。
【図５】  本発明の一態様による、ある時間の期間にわたるトランザクション処理されるファイルの分離を表すブロック図である。
【図６】  本発明の一態様による、ファイルバージョンを追跡するデータ構造体を表すブロック図である。
【図７】  本発明の一態様による、経時的に維持される複数のファイルバージョンを表すブロック図である。
【図８】  トランザクショナルにオープンされたファイルのデータの、書き込まれるページを表すブロック図である。
【図９】  本発明の一態様による、トランザクションでの読取アクセスおよび書込アクセスのためにオープンされたファイルの分離をサポートするデータ構造体の間の関係を表すブロック図である。
【図１０】  本発明の一態様による、トランザクションでの読取アクセスおよび書込アクセスのためにオープンされたファイルの分離をサポートするデータ構造体の間の関係を表すブロック図である。
【図１１】  本発明の一態様による、２レベルログ記録機構およびログが同期化されているかどうかを検証する機構を表すブロック図である。
【図１２】  本発明の一態様による、ログ記録されるページデータと、ページデータがログと同期化されているかどうかを検証する機構を表すブロック図である。
【図１３】  本発明の一態様による、ページデータがログ記録されたレコードと同期化されているかどうかに基づいて行われるアクションを表す流れ図である。
【図１４】  本発明の一態様による、代替バージョン管理法式で経時的に維持される複数のファイルバージョンを表すブロック図である。
【図１５】  本発明の一態様による、ネットワークを介するトランザクショナルファイルシステム動作を表すブロック図である。
【図１６】  本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離ディレクトリの使用を表すブロック図である。
【図１７】  本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離ディレクトリの使用を表すブロック図である。
【図１８】  本発明の一態様による、名前空間分離をもたらす階層ファイル構造および分離ディレクトリの使用を表すブロック図である。
【図１９】  本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関する一般的なルールを示す流れ図である。
【図２０】  本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関する一般的なルールを示す流れ図である。
【図２１】  本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関する一般的なルールを示す流れ図である。
【図２２】  本発明の一態様による、名前空間分離をもたらす分離ディレクトリの使用に関する一般的なルールを示す流れ図である。
【図２３】  本発明の一態様による、メモリマッピングされたセクションの浮動化を表すブロック図である。
【図１】
0004219589.tif 000024
【図２】
0004219589.tif 000025
【図３】
0004219589.tif 000026
【図４】
0004219589.tif 000027
【図５】
0004219589.tif 000028
【図６】
0004219589.tif 000029
【図７】
0004219589.tif 000030
【図８】
0004219589.tif 000031
【図９】
0004219589.tif 000032
【図１０】
0004219589.tif 000033
【図１１】
0004219589.tif 000034
【図１２】
0004219589.tif 000035
【図１３】
0004219589.tif 000036
【図１４】
0004219589.tif 000037
【図１５】
0004219589.tif 000038
【図１６】
0004219589.tif 000039
【図１７】
0004219589.tif 000040
【図１８】
0004219589.tif 000041
【図１９】
0004219589.tif 000042
【図２０】
0004219589.tif 000043
【図２１】
0004219589.tif 000044
【図２２】
0004219589.tif 000045
【図２３】
0004219589.tif 000046