JP3984789B2 - データのセーブ、使用、回復におけるデータの汚染および共用ディスクを扱うための方法、ならびにコンピュータ読み取り可能な記録媒体 - Google Patents

Description

【０００１】
【著作権情報／許可】
本特許の開示内容には、部分的に著作権保護の対象となるものが含まれる。当該著作権者は、特許庁の特許ファイルまたは記録にある特許文献または特許開示を何人が複製することに対しても異論はないが、その他の目的での使用に対しては全ての著作権を留保する。下記の著作権表示は、以下および図中に記載する、ソフトウェアおよびデータに適用される。Copyright 1999, Wild File, Inc. All Rights Reserved.
【０００２】
【文献の援用】
1998年6月26日付けで出願された、「データをセーブ、使用、および回復するための方法、ソフトウェア、および装置」という名称の、米国特許出願番号09/105,733の出願全体を本明細書中に援用する。
【０００３】
【発明の技術分野】
本発明は、デジタルデータの記憶に関し、より詳細には、デジタルコンピュータに記憶されたデータのバックアップおよび回復のための方法および装置に関する。
【０００４】
【発明の背景】
1998年6月26日付けで出願された、「データをセーブ、使用、および回復するための方法、ソフトウェア、および装置」という名称の、米国特許出願番号09/105,733(以下、U.S.'733とする)に係るシステムの1つの実施例において、上書きされようとしているデータを保存するためにディスクライトの転送を行うことが扱われているが、そこでは2つの要素、すなわち循環履歴バッファシステムとメインマップが含まれている。当初、履歴バッファは転機（転記）された新規に書込まれたデータを受け取り、メインマップがオペレーティングシステム(転送に気づいていない)から見たあるページのデータの実際の現在位置をトラッキングする。Temp法では、時間が許すときに、転送されたデータと履歴「上書き」データをハードディスクの適切なマップされていないロケーションに交換するためにスワップが行われる。Always法では、通常、データが放置されることになる代替の物理ディスクロケーションに新規に書込まれたデータを転送することにより、スワッピングが最小に抑えられる。そのためにリマッピングに時間がかかる。
【０００５】
U.S.'733では、ある状況においては、Temp法およびAlways法で必要とされるスワップアクティビティが履歴データの再循環よりも遅延することがあることが想定されている。言い換えれば、ユーザーがあまりにたくさんのデータを上書きしてしまったため、ロケーションXが本来の位置である(最適な編成のため、すなわち、関連データの付近)ロケーションYへのスワッピング待ちの非常に古い履歴データHDを含むような状況が発生し、あるロケーションでは新規データNDによる上書きが発生する。新規データNDが、古い履歴データHD（通常はロケーションYに存在するが一時的にXに存在する）を上書きするために転送されるため、NDがロケーションXに書込まれ、それに伴いマップも更新されるプロセスについてU.S.'733に記載されている。このプロセスは、インターリンクされた合理的に複雑なマップを伴う。'733には、安定ページおよび遷移ページを利用してスイッチページの制御下で、インターリンクされたマップを管理することが記載されている。
【０００６】
U.S.'733は、完全な技術の世界では、大変うまくいく。しかし、実経験によって、U.S.'733の潜在的欠点が明らかになった。すなわち、パーソナルコンピュータの多くは、バグだらけのコードや誤動作するハードウェアを含んでおり、データ汚染を引き起こす。
【０００７】
【発明の概要】
本発明の種々の実施例によれば、記録媒体上に加えられた変更の記録を保持し、先の時間における媒体の状態を復元できるようにする方法が提供されている。このプロセスを向上、改善するため、他の種々の代替実施例が提供されている。この中には、記録媒体に転送される前に汚染を検出ために比較されるデータの2つのコピーをRAMに保持することと、ロジック保護とビューとを分離し、互換性のないソフトウェアから保護するためにディスクを隠蔽することと、所定の時間が経過したことを保証することにより書き込みキャッシュをフラッシュすることと、所定のフリータイムが経過したことを保証し、かつ必要に応じて遅延を挿入することにより、書き込みキャッシュをフラッシュすることと、ディスクアクティビティの速度が低下した後にセーフポイントを挿入することと、定期的にセーフポイントを挿入することと、ひとりのユーザに対してセーフポイントを設定する必要性が検出された後にOSキャッシュ全体をフラッシュすることと、ディレクトリやファイルを監視することによりユーザアクティビティを分離することや、汚染が発生した場合に順次編成されたテーブルから概ね再構築することのできるエンジンを実現するために、複雑にリンクされたデータ構造を使用することを含む。
【０００８】
【発明実施の形態】
【データ汚染の問題】
バグだらけのコード問題の性質は、Ｕ.S.'733を実行しているソフトウェア(エンジン)の一部ではなく、オペレーティングシステムの他の部分、デバイスドライバ、またはアプリケーションのコードに関係する可能性が高い。「バグ」には、ウイルスによる意図的悪意も含まれる。バグのソースの如何に関わらず、結果として起こるのは、ロジック(コード)および／またはエンジンと関連するデータの汚染である。大規模のデータ汚染はコンピュータをすぐに作動不能にすることが多く、特に汚染がコンピュータの内部メモリ(RAM)からディスクへと伝播する前に動作不能になる。そのような場合は、単にコンピュータを再始動すれば解決する。ディスクは影響を受けていないため、ディスクの汚染されていないデータからRAMが再初期化される。しかし、小さな汚染でも、もっと重大な混乱を招くことがある。ソフトウェアによくあるバグは、ワイルドポインタ(すなわち配列インデックス)であるが、これによりRAM内のいくつかのランダムバイトが汚染される(すなわち、影響されたRAM内のバイトのロケーションは予想できない)。
【０００９】
コードが汚染されると、それがたとえわずかであっても、その結果は概して破滅的である。なぜなら、コードは異なる長さ(バイト数)を有するコンピュータ命令のシーケンスだからである。ワイルドポインタによって1つの命令が「ヒット」（変更）されると、この命令のアクションが変更されるばかりでなく、それに続く全ての命令のアクションも変更されることが多い。命令をランダムに変更された結果、その長さ(命令を構成しているバイト数)が変えられれば、次の命令の開始点が誤った位置にあることになる。したがって、1つの汚染された命令をコンピュータが実行すると、続く全ての命令は概してランダムな使い物にならないものであり、命令の他の部分が次々と誤解釈され、通常、カレントプロセスがすぐに動作不能になる。オペレーティングシステムは、(マイクロプロセッサのハードウェアに組み込まれたメカニズムにより)コンピュータ上の処理を分離しようとするため、1つの処理が失敗しても、その被害は抑えられ、処理も中止される。ウィンドウズ95では通常、「一般保護違反」のエラーが表示され、いくつかのアプリケーションまたはオペレーティングシステムの構成要素が終了される。しかし、オペレーティングシステムのエンジン等のきわめて重要な構成要素が中止されると、システム全体が動作不能になることがほとんどである。したがって、エンジンコードがわずかに汚染された後のコンピュータの挙動は、大規模な汚染とほとんど同様である。影響を受けたコードが呼び出される(実行される)と、コンピュータは、おそらく汚染がディスクに伝播する前にクラッシュする。
【００１０】
【わずかな汚染の方がやっかいである】
エンジンのデータにわずかな汚染が発生したときに、本当の問題が起こる。これにより、ディスクを変更するエンジンのロジックが、汚染された(RAM内の)データに基づくことになり、ディスクに汚染が伝播するため、より危険である。一度これが起きると、コンピュータを再始動させた後でも、ディスク上のエンジンデータは汚染されたままである。したがって、エンジンの主要な機能、すなわち、ユーザのカレントデータがどこにマップされたかを特定することに始まり、過去におけるディスクと同じイメージを表現する能力までもが概ね失われる。この一因として、ディスクをリマップする技術がディスク上のデータを混乱させることがあり、マップが無いのではデータは実質上無意味である。
【００１１】
更に悪いことに、ディスク上のエンジンデータの汚染は、RAMから発生していないこともある。現実の社会では、コンピュータのメインマイクロプロセッサとディスクコントローラの間の通信に汚染が入り込むことがある。ページを書込むロケーション、またはページを読取るためのロケーションが、改ざんされたり、通信処理最中にデータが汚染されることがある。長期間には、ディスクに記憶された少量のデータがだめになることがある(バッドページ)。または、エンジンとは互換性のないソフトウェアでも、ディスクに直接アクセスできるものなら、エンジンのデータ(「ドクター」ユーティリティ等)を汚染することができる。
【００１２】
前述の通り、大規模なハードウェア障害が問題なのではない。コンピュータのハードディスクが全く機能しなければ、できることはあまりない(ソフトウェアの観点からは)。しかし、逆の極端な事例として、ディスクのほとんどのデータが損なわれていない状態で1つのまたはたまにしか発生しない故障のためにディスクの全ての情報が使用不能になることも合理的ではない。多くの場合、ディスクの大部分は機能している。
【００１３】
【データ書込み順序の制御（書き込みキャッシュ）】
U.S.'733の技術に内在する最後の興味深い問題は、データがディスクに書込まれる順序の制御の必要性である。例えば、ある安定した状態から他の状態に移行する際に、ディスクに遷移データが書込まれ(フラッシュされ)、スイッチページが更新される。しかし、近年のディスクドライブは、その性能を向上させるべく、書き込みキャッシュも含んでいる。これらの書き込みキャッシュは、書き込みをバッファリングし、書込まれているのとは別の順序でデータをディスク媒体に記録する。これにより、例えばディスクヘッドの動きが減少するような順序でディスクコントローラにより実際にデータが書込まれるのを可能にすることで、書き込み処理の全体的な速度が加速される。しかし、ディスク上(書込み待機中)に既に存在していると仮定されるデータより先に、ディスク上でスイッチページを更新することが可能となる。停電の際には、ある安定した状態から他の状態への安全な遷移を行うことができない。
【００１４】
ディスクドライブに送られ、そのような書き込みキャッシュ最適化を禁止することのできるコマンドが存在することが判明している。しかし、これらのコマンドは他の有用な最適化さえも禁止してしまうため、性能の低下が著しい。書き込みキャッシュを特別にフラッシュするためのフラッシュコマンドの使用をサポートするディスクもあるが、これらのコマンドは入手が困難である。言い換えれば、現代のコンピュータには、ディスクから読取り、また書込みを行うための標準手段がBIOSに備わっているが、書き込みキャッシュをフラッシュするための標準手段がない。よって、コンピュータのディスクドライブがフラッシュコマンドをサポートするかどうかに関わらず、エンジンがBIOSの標準インターフェースを使用している以上、エンジンが容易にフラッシュを開始することはできない。エンジンは、ディスクに直接データ伝送ができなければならず、したがって特定のハードウェア知識も必要である。これは、いかなるコンピュータ上でも実行可能な汎用プログラムの観点からは不可能である。コンピュータメーカは通常、特定の種類のハードディスクとこのタイプのディスクが制御できるBIOSとを合体させてきた。それに従った全てのソフトウェアは通常、ディスクにデータ伝送をする際にBIOSによるインターフェース−SCSI、IDE等があるが−に依存しており、現在のインターフェースにはフラッシュコマンドが含まれていない。したがって、エンジンに特殊なディスク(ハードウェア)知識を組み込もうとすることなく、改良されたエンジンデザインにより、以下のことが可能となる。すなわち、それをフラッシュする方法を必要とせずに、書き込みキャッシュを存在させることが容易になる。これは、次のことを意味する。すなわち、エンジンはディスクコントローラに書込まれるデータが異なった順序でディスク媒体に実際に入れられることがあることを考慮しなければならない。そしてそれにもかかわらず、エンジンは、クラッシュリカバリのためにそのディスク上のデータの完全性を常に維持する必要がある。
【００１５】
【ロバストなエンジン要件】
要約すれば、エンジンは、コンピュータ世界のあらゆるソースから発生する、RAM内およびディスク内のデータ汚染の両方に対して的確に対処する必要がある。汚染されたRAMデータがディスクに基づくデータ(ワイルドポインタ等)に伝播するのを防ぐ必要がある。ディスクに起因するめったに起こらない汚染から回復しなければならない(例えば、汚染された転送、誤指示された書き込みまたは読み出し、および駄目になったページ)。安定したデータ構造を保持し、クラッシュ時にそれらを回復できなければならない。たとえ、ディスクコントローラに書込まれたデータの一部のみがクラッシュ直前に生き残ったとしても同様である(他の部分は、書き込みキャッシュから出られずに失われた)。U.S.'733の技術がこれらの問題を特に考慮するのでなければ、重要なエンジンデータの汚染によりデータが完全に失われてしまうことになる。
【００１６】
これらの問題に取り組んだ本発明の説明を続ける前に、現在のコンピュータがこれらの状況において通常どのように機能しているかについて疑問をもたれるかもしれない。その答えの一部はScanDiskにあるが、これはWindowsベースのコンピュータが始動した際に、前回何らかの理由で正しくシャットダウンされなかったと判断されたときに自動的に実行されるものである。あるいは、ディスクに問題があるかもしれないと疑いを抱いたときにユーザ自信が手動でプログラムを開始することもできる。ScanDiskはオペレーティングシステムのディスクに基づくデータを検査し、可能な限り修復しようとする。重要なことは、ScanDiskは損害を逆戻りさせたり、ある既知の先の良好な状態に戻すことができず、単に、オペレーティングシステムのデータ構造が再使用できるようになるまで様々なリンクを修正したり調整したりするにすぎないということである。多くの場合、かなりの量のデータが失われるか汚染される。すなわち、ファイルの一部が失われたり変更されたり、場合によってはファイル全体が消滅する。しかし、コンピュータ上にはたくさんのファイルがあり、その多くは全く使用されないか、使用されたとしてもごくたまにである。したがって、コンピュータが機能しなくなる前にはかなりの汚染が発生することがある。現在のコンピュータはどのコンピュータも多かれ少なかれ「病気」になるのであり、時間の経過につれて、システムの様々な部分が徐々に汚染される。定期的にディスクを一掃してオペレーティングシステムやアプリケーションやデータを再インストールするユーザもいる。
【００１７】
【時間遡及の保証】
この徐々に進行する汚染は、エンジンの約束事とは相反するものである。エンジンの目的は、先のある時点と全く同じ状態にディスクを戻すことであり、徐々に必ず起こる汚染に対して免疫を有さなければならない。これは、現在のところ、ScanDiskの能力(または同等の修復ユーティリティ)の範囲で最大限修正されている。
【００１８】
より完全な世界では、オペレーティングシステムはエンジンおよびそのデータをワイルドポインタやウィルスから守ことができ、ディスク上のデータの冗長性に少し注意するだけで(時々発生する転送不良に備えるため)、U.S.'733の技術で十分である。しかしながら、オペレーティングシステムはその最下位レベルにおいて拡張可能でなければならず、したがって、それらによってあるデバイスドライバを他のデバイスドライバから完璧に保護できるようにするのは困難である。また、オペレーティングシステムは通常、非常に大きなプログラムであるため、その中から全てのバグを除去するのは困難である。
【００１９】
全てのプログラムが相互間における「完璧な」保護を望んでいるように見えるかもしれない。マイクロプロセッサに組み込まれたハードウェア手段(プログラムから制御を取り除くための割込みや、迷書き込みをトラップする記憶保護機構等)により、オペレーティングシステムが完璧に保護しようとしているのも事実である。しかし同時に、オペレーティングシステムの保護とその効率性はバランスされていなければならない。効率的なコードは保護境界の負担を望まないことが多い(タスクを他のタスクから常に保護するには時間がかかる)。しかし、エンジンは単なるプログラムではない。その役割は、不測の事態が発生したときに、コンピュータを再始動し、あるより良い状態まで全てを戻すことである。このフォールバックポジションは保護される必要がある。ユーザは通常、プログラムはコンピュータ内のRAMの領域内で実行されていると理解しており、コンピュータを再始動した際にディスクの内容が損なわれていないことを当然と考えるか、少なくともそう希望する。したがって、エンジンおよびディスクを保護するには、オペレーティングシステムから得られる妥協されたレベルを上回るハードウェアおよび／または技術でなければ無理だという意見もある。
【００２０】
以下に、エンジンが取り組む必要のある問題の概要を示す。
・ワイルドポインタデータ汚染
・ディスクからの汚染されたデータの読取り(転送不良、バッドページ等)
・ディスクに直接アクセスできる互換性のないソフトウェアの使用
【００２１】
U.S.'733では、メインマイクロプロセッサ(ファイアウォール)および／またはマザーボードに特別なハードウェアを設けるか、エンジンを実際にディスクコントローラ内のコンピュータに移動させることによりエンジンを保護することを構想していた。これにより、ワイルドポインタの問題(エンジンにバグが存在しないと仮定して)がなくなり、互換性のないソフトウェアが直接ディスクにアクセスすることもなくなる。しかし、現在使用されているコンピュータには、ハードウェアを変更するという選択肢が与えられていないものが既に多数ある。本発明は、データの冗長性の原理に基づいた解決方法を提供する。
【００２２】
【汚染を検出するためのＲＡＭデータの複製】
ワイルドポインタ(あるいは他の手段)による迷書き込みに対処するために、本発明のエンジンは、RAM内の全ての主要なデータ構造を複製する。ディスク上に記憶されたデータに対応するデータに関しては、そのデータの中にディスク上のデータロケーションが含まれる。汚染の発生さえなければ有効であるディスクイメージに、汚染が入り込む重大な瞬間は、キャッシュデータがディスクにライトバックされる直前である。したがって、ライトの直前に、RAMの2つのコピーを比較して、それらがディスク上の意図された行先に関連していることを示しており、そのデータがマッチしていることを保証する。比較の結果、否であれば、何らかの(RAM)汚染要素が作用していることになる。汚染を識別し修正するために他の技術を追加することもできるが、一番よいのは、ユーザに警告してシステムを再始動させることである。一旦汚染が検出されると、システム全体が信用できない。そのまま処理を続ければ、もう二度と回復ができないまでの重大な汚染がディスクに伝播するリスクが大き過ぎる。よりおだやかな対応は、更にディスクを変更しようとする試みを全てブロックして、ユーザに警告してシステムの実行を継続することである。ユーザはこの期間に、別の記憶装置にデータをセーブすることができる(例えば、ワードプロセッサ文書をフロッピーに保存する)。
【００２３】
コンピュータが、様々なベンダーによって提供される多くの複雑なソフトウェアによって動作することを考えると、迷書き込みが時々発生するのはほぼ確実である。エンジンに使用されるデータの量は、非常に大きなディスクをリマップすることを考えると、マイクロプロセッサのアドレススペースに比べて非常に多い(数メガバイトのRAM)。したがって、ハードウェアの保護無しでは、エンジンのデータが時々汚染される合理的な機会がある。例えば、32ビットのアドレススペース(4096M)を有し、エンジンがそのうち2メガバイト(2M)を占めるマイクロプロセッサでは、1つの迷書き込みがエンジンデータをヒットする可能性が2000分の1の確率で存在する。しかし、エンジンデータの2つの重複コピーを2つの迷書き込みがヒットして同様の変更を加えた場合、その汚染を引き起こしている何らかの原因が大規模な汚染につながらない確率は、極めて低い。
【００２４】
エンジンによってRAMの2つのコピー相互の妥当性が確認されると、そのデータがディスクに書込まれる。ディスクコントローラにデータが正しく転送されたことを保証するため、エンジンは、すぐさま読み出してデータを確認することができる。2つのコピーは、ディスクベースデータに冗長性を付加するために、ディスクの異なるロケーションに書込まれる。したがって、ディスクが何らかの理由から1つのコピーを読み出すのに失敗するようなことがあっても、もう1つのコピーがある。冗長性によってデータの完全性を保証する方法は、RAIDシステムで利用されているように周知の原理である。しかしこの場合、冗長性は、同一の物理デバイス上に存在する2つのコピーに限られる。
【００２５】
【エンジンの分割】
本明細書およびU.S.'733中に記載された、エンジンとそのデータを保護するための最善の解決方法は、ハードウェア保護を設け、マザーボード上(メインマイクロプロセッサを使って)またはディスクコントロール内にエンジンを設けることである。実質的なRAMおよび処理時間の要件から、理想的なエンジンの位置はマザーボード上(ディスクコントローラでなく)であると言われている。しかし、実際のところエンジンは、2つのある程度独立した機能を果たしている。すなわち、履歴データの管理とディスクのリマッピングである。エンジンが、オペレーティングシステムにディスクの異なる複数の「ビュー」を提供するのはこのリマッピングを通してであり、これにより、カレントイメージや過去に基づく状況が示される。しかし、ディスクのリマッピングおよびビューが一時的に汚染されるようなことになっても、ユーザがコンピュータを再始動でき、ディスクと、時間を遡及する能力とが保護されることが(合理的に)保証される範囲なら許容される。それは、期待しなかった結果をユーザが見たり経験した場合は、コンピュータを再始動することによって「クリア」するよりほかない。結果が同じであれば、汚染されたものがアプリケーションであるか、オペレーティングシステムであるか、エンジンのある一部であるかは問題ではないからである。
【００２６】
したがって、エンジンの機能の一部を、保護されていないメインプロセッサ(およびマザーボード)とディスクコントローラの間で分割することが可能である。メモリと処理が集約されたタスクがリマッピングと同様にメインプロセッサ(馬力がある)にまかされ、より要求の少ないロジックがディスクコントローラに付加されてエンジンのデータ構造を保護する。エンジンの保護されていない部分はOSフィルタと呼ばれ、ディスクコントローラ部はエンフォーサと呼ばれる。したがって、リマッピングを扱うメインプロセッサベースのOSフィルタは、オペレーティングシステムに様々なビューを提供するのに使用されるマップを生成管理するために必要とされる情報やデータを、ディスクコントローラベースのエンフォーサから読取る。データを書込むのはオペレーティングシステムであり、新規のデータをディスク上の代替のロケーションに割り当て、それを保証するのはエンフォーサである。しかし、新規のデータが転送されると、OSフィルタに新規のロケーションが伝えられ、それにしたがってマップが調整される。OSフィルタのデータが汚染された場合でも、ユーザがコンピュータを再始動することができ、OSフィルタはエンフォーサから提供されたデータに基づき自らのデータを再構築する。
【００２７】
エンフォーサとしての役割を実行するためにディスクコントローラが改良されると、ディスクコントローラ(エンフォーサ)によって要求され実施されるディスクオペレーションが正常なページ読み出し要求およびページ書き込み要求から変化する。エンジンのデータおよび古い履歴データの読取りを防止する理由(*)は何もないため、読み出し要求は変化しない。しかし、書き込み要求は、これからエンフォーサが実際の書き込みを別のロケーションに転記し、この新規のロケーションをOSフィルタに知らせることを意味している。オペレーティングシステムが将来、書込まれたばかりのロケーションを読取った場合に、書き込みが転記されたロケーションにリマップすることを覚えているのが、OSフィルタの役目である。書き込みをどこに転記させるかを決定するためのアルゴリズムは幾つも存在する。これらは、U.S.'733のTemp法およびAlways法で説明されている。いずれの場合においても、書き込みが初めに転記された位置は、性能上の理由から後になって更新されることが予想される。このディスクの再配置は、スワップ処理により実行される。このプロセスには、カレントデータおよび履歴データの読取りおよび書込みが伴うため、エンフォーサ内で実行される。
【００２８】
セキュリティ上の理由から、ディスクの古い履歴状態が無許可にビューされることを防ぎたいとユーザが望む場合がある。ディスク上の秘密情報は、過去のある時点で削除または暗号化されている可能性があり、この時点より前の時点へのアクセスを制御することが重要である。
【００２９】
OSフィルタは、エンフォーサからのデータによってマップを再構築することができるが、ディスク上へのマップの保持を必要とすることもある。したがって、エンフォーサは、ある程度の半一時的ディスクスペースに対するアクセスを提供する必要がある。すなわち、OSフィルタはディスク上にそのデータ構造をセーブするが、データ構造が汚染されたと思われたときには、エンフォーサの保護されたデータからデータ構造が再構築される。エンフォーサは、シャットダウンコマンドにより、OSフィルタの半一時的データの全てが書き出されたことを知らされる。OSフィルタはコマンド中に、そのルートページのロケーションをそのデータ構造に含めて保管する。OSフィルタは特別な読み出し要求により、エンフォーサの読取専用データ構造を示す「ヘッダ」情報を得、このデータ構造からそのマップを再構築する。このヘッダページは、前回のシャットダウン直前にOSフィルタから供給された半一時的ルートロケーションを含んでいるか、あるいは先にクラッシュが起きていた場合には空で戻される。
【００３０】
要約すれば、エンフォーサベースのディスクコントローラは他のものに加えて以下の基本オペレーションを受け取る。追加的オペレーションは履歴バッファを急速に超過するのを防いだり(すなわち、過去に対する一定最低限の距離を保証する)、少なとも1つのSOSDイメージに関連した履歴データをロックしたりするためのサポートをするように構想される。
・ページN読取り、データDを戻す
・データDをロケーションXに書込み、転記されたロケーションYを戻す
・半一時的ロケーションを要求し、ロケーションSXを戻す
・半一時的データDをロケーションSXに書込む
・半一時的ロケーションSX(または全部)の解放
・ロケーションXとYの内容をスワップ(または移動)
・ヘッダページを読取り、データDを戻す
・ディスクシャットダウン時の半一時的ロケーションSXをルートとする
【００３１】
エンフォーサは、適応可能なデータ構造に関する知識を有するので、OSフィルタによるスワップ要求を有効にする。OSフィルタは、エンフォーサが生成したデータ構造を読取り、参照することができるが、信用されていないため、エンフォーサのデータ構造を無効にするような変更をしたり、アクションを要求することはできない。言い換えれば、エンフォーサは、上書きされたOS可視データが履歴化され、その履歴データが時系列処理（エージング）されて適当にリサイクルされ、ディスクの再編成が自らのデータ構造を汚染する可能性なく実行されること、ということを保証するためのエンジン部分を実行する。OSフィルタは反対に、オペレーションシステムから供給されたディスクロケーションを現在位置にリマップする等のエンジンの残りの部分を実行する(エンフォーサによる制御で)。
【００３２】
OSフィルタ／エンフォーサモードで動作しているディスクは、OSフィルタでそのアクセスを適切にリマップされなければオペレーションシステムによって使用できない。したがって、ディスクコントローラがこのモードにある場合、ノーマルコマンド(例えば、リードやライトページ)を受け取らないことが推奨されている。しかし、ディスクは、ノーマルとOSフィルタ／エンフォーサモードで交換可能に構想されている。OSフィルタ／エンフォーサモードからスイッチする場合、全ての履歴データが廃棄され、メインイメージを構成しているページがそのマップされていないロケーションに移動される。
【００３３】
【ハードウェア保護無しでのソフトウェア保護】
OSフィルタ／エンフォーサの分割は、ハードウェア保護によるエンジンの実装である。そのような場合には、ディスクに直接アクセスしようとする互換性のないソフトウェアから保護することができる。例えば、市場の様々なユーティリティにより、マスタブートレコード(MBR)ページが変更される。エンジン(すなわちOSフィルタ)が適当にロードされていることを保証するため、このページはエンジンの制御下になければならない。さらに、ユーザがハードディスクではなくフロッピーディスクから起動した場合は、ハードディスクをビューするのに必要なエンジン(すなわちOSフィルタ)をロードしない。しかし、エンフォーサがディスクコントローラ内で実行されている場合は、そのような互換性のないソフトによってエンジンのデータ構造が損傷を受けることはない。
【００３４】
新しいソフトウェアをリリースするのと比較して、数百万ものPCのハードウェアを更新するのは実際的でないと先に述べたが、新規のハードドライブを導入する方が、より困難が少ない。結局、容量の増大に伴い、PCのハードドライブは機械的にアップグレードされる。したがって、メインCPU(マザーボード)で動作する新規のソフトウェアを伴うような、ハードドライブに対するハードウェア的解決方法を提供することが有益である。ハードドライブの「ハードウェア」的解決方法は、そのファームウェアの変更から成ることに注意する必要がある。
【００３５】
ハードウェア保護が無い場合、互換性のないソフトウェアによってディスクが変更されるのを防ぐため、エンジンはディスクを隠蔽する。エンジンは、FATやパーティションテーブル等の重要なOSデータ構造を新しいロケーションに移動し、隠蔽されたディスクを表すデータ構造と置き換える。隠蔽は、2つの形態のいずれかを取る。使用不能ディスク(修正や変更を試みる範囲が及ばないほど汚染されている)または完全に有効であるが無害のフェイクディスクである。後者の場合、FATおよびパーティションテーブルは、ディスク全体に埋め込まれた非常に小さいが、正しく構成された「フェイク」ディスクを表す。このフェイクディスクの全てが有効であるため、リペアユーティリティはフェイクディスクの境界内にとどまることになる。しかし、実データおよびディスクの境界がどこにあるかということをエンジンは知っている。エンジンは、フェイクディスクに関連したどのデータにも依拠していないため、フェイクディスクに変更が加えられてもエンジンのデータ構造が汚染されることはない。
【００３６】
【損失を防ぐためにディスク上のデータを複製】
RAM内で、エンジンデータが汚染されていないことが確認され、ディスクにそのデータが書込まれる際には、データは、2つの異なるロケーションに書込まれる。したがって、1つのコピーの検索が失敗してももう1つのコピーがある。2つのコピーは、ディスクの一部で汚染が発生したときに両方とも失われてしまわぬよう、ある程度距離をおいたロケーションに書込まれるべきである。また、実際の書き込み処理は、2つの独立した書き込み要求に分離して、1つの要求によって両方のコピーがマザーボードからディスクコントローラに移動しないようにする。一旦データがディスクコントローラに到達すると、おそらく待機用の書き込みバッファにキャッシュされ、実際に最適な方法でディスク媒体に書込まれるのはある短い時間が経過した後であろう(頭出しおよび転送時間の最小化)。
【００３７】
ディスクエラーが発生したとしても、他の複製されたデータ構造からあるエンジンデータ構造を再構築できることがわかっていれば、そのエンジンデータ構造のコピーを1つだけ書込むことが道理にかなっている場合がある。例えば、メインエリアマップは履歴データから構築することができる。
【００３８】
【フラッシュコマンド無しで書き込みキャッシュをフラッシュする】
エンジンに書き込みキャッシュを制御する能力がないと仮定すると、キャッシュは、クラッシュ時に困難な問題を提示する。例えば、停電によって書き込みキャッシュの一部がディスクに書込まれなくなる可能性が大きい。エンジンにとっての問題は、そのデータの一部はディスクに書込まれたかもしれないが、他の部分が書込まれていないということである。しかし、書き込みキャッシュにより、エンジンによって書込まれたデータの順序がディスクに到達したデータの順序に相関しないという事態が発生する。したがって、エンジンによってディスクロケーション1、2、3に書込まれた後にクラッシュしたとすると、ロケーション1と3は更新されてもロケーション2が更新されないということが起こりうる。
【００３９】
一部が欠けていても完全に役に立つデータ構造は少ないため、本発明ではディスクに書込まれるデータの完全性を保証するために時間エージングを使用する。通常、書き込みキャッシュアルゴリズムは、そのデータのディスクへの転送が無期限に遅延するようなことはないと仮定されている。これはコンスタントに読み出し動作（アクティビティ）および書き込み動作（アクティビティ）が行われる状況でも当てはまると仮定されている。もしそうでなければ、朝方に書込まれたファイルのデータは、書き込みキャッシュに詰まったままディスクに書込まれるための「最適」な時を待ち続けているため、何時間経ってもディスク媒体に到達していないということも考えられる。本発明は、ディスクコントローラに1つのページを書込むと、ある最小限の時間(待ち時間)が経過した後、実際にディスク媒体に書込まれる(よってクラッシュ時には不揮発性記憶装置にセーブされている)という仮定のもとに成り立っている。
【００４０】
したがって、本発明はデータの時間経過を使用しており、待ち時間以上前の時点でディスクコントローラに書込まれた場合に限って、回復の際にそのデータを信用する(システムの再始動)。ディスクコントローラに書込まれるデータのブロックとともに、ある形態のタイムスタンプやタイムマーカが含まれており、1つのブロックは複数のディスクページから成る。待ち時間以上後の時点で書込まれた次のタイムスタンプまたはタイムマーカが発見されれば、ブロックの全体が実際にディスク媒体に転送されたと仮定される。タイムスタンプとは、クロックの示数に対応する値のことである。2つのタイムスタンプを比較することにより、表されたタイムインターバルの長さを判別することができる。逆に、タイムマーカは単に、先のタイムマーカから待ち時間が経過したことを示すだけである。
【００４１】
ディスクコントローラに転送されたデータの量を監視することにより、待ち時間を近似することができる。ディスクコントローラへの転送速度はわかっているので、これに待ち時間を掛ければ、あるページの書き込み後にこのページが実際にディスク媒体に書込まれたことを保証するために転送されなければならないデータの量がわかる。このために、転送は継続的に行われていると仮定する。
【００４２】
先に書込まれたデータは適当な待ち時間の後実際にディスクに到達するという仮定は、あるディスクコントローラには当てはまらない場合がある。このような場合には、他の方法が使用される。ここで、エンジンは、ディスクコントローラがその書き込みキャッシュの全てをディスクにフラッシュするのに十分な「フリータイム」が、ある書き込みから経過したことを保証する。エンジンはディスクコントローラへの平均転送数を監視することができる。これが既知または最大の転送速度(データが実際に読取り可能、またはディスク媒体に書込み可能な速度を反映している)と比較され、書き込みキャッシュがフラッシュされたのが当然と考えるのが合理的であるかが判断される。フラッシュが必要であり、不十分なフリータイムしか経過していなければ、エンジンは単に遅延(またはディスクアクティビティの急激な休止を防止するための一連の小さな遅延)を挿入する。最悪のケースのドライブの転送速度は、非常に大きなデータブロック(合理的なキャッシュサイズをはるかに上回る)を読取って、書込むタイミング較正プログラムによって推測することができる。転送数、相対近接度、サイズ、のそれぞれが独立して全体的な転送速度に寄与しているため、計算には、それらを考慮しなければならない。言い換えれば、各転送の開始時点と関連したディスクヘッドを物理的に動かす時間的オーバーヘッドと、ディスクの媒体に実際にデータを転送するのにかかる時間と、が存在するのである。
【００４３】
ディスクコントローラのキャッシュをフラッシュするためのフリータイム法のアナロジーとして、コップで水をバケツに加えるようなものとしてキャッシュを考えることができる。バケツの底には穴が空いており、一定の速度で水が排出される。穴から排出される水は、ディスクコントローラからディスク媒体にデータが書込まれるのと等しい。コップで水を足すプロセスは、ディスクコントローラにデータを書込むのと等しい。バケツが一杯なら、待つ必要がある。ディスクコントローラからデータを読取るのは、瞬間的に穴をふさぐのに等しい。何も排出されず、何も加えられないが、時間だけが経過する(リードキャッシュは書き込みキャッシュから独立しているものと仮定する)。また、書き込みキャッシュをフラッシュする状況はちょうど、バケツに加えられたある1杯のコップの水が排出されたことを時々保証したいが、実際にバケツを覗いたり、水がまだ排出されているかどうかを検出することができないのに似ている。また、バケツにコップ1杯の水を加えると、それは先に加えられた水やその後に加えられる水と混ざりあう。
【００４４】
問題となっているコップの水が本当に排出されたかを知るための唯一の方法は、そのコップの水が加えられた後のある時点においてバケツが瞬間的に空になったことを保証することである。バケツの中を覗くことも、それが排出途中にあるのかどうかも知ることができないため、このイベントをいつにするか、またはどのようにして起こすかを決定するのは難しい。言い換えれば、ディスクコントローラにそのキャッシュがフラッシュされたかを尋ねるための標準インターフェースがないのである。解決方法は、バケツから水が排出される際の最悪の場合の速度を決定することである。これは、待たなくてはいけなくなるまで、すなわちバケツがいっぱいになるまで、できるだけ速くコップで水を加えるというテストによって決定される。この点以降は、バケツが空になるのに伴いコップで水を加え(次のコップが受け入れられる)、その速度を測定する。このプロセスにより、バケツの緩衝効果が効果的に無効にされ、実際の排出速度(すなわちディスクコントローラがそのキャッシュを空にする速度)が測定できる。
【００４５】
バケツの排出速度がわかれば、コップで水を足す際の速度を監視することができる。排出されたことを確実にしたいコップの水を足したら、その後加える水の速度を遅くして、新しく加えられるコップの水よりもバケツから排出される水の速度を速くする。計算可能なある点において、コップで水を加え続けているにも関わらずバケツはゆっくりではあるが完全に空になる。もちろん、更にコップで水を加える前にバケツが空になったことを比較的速く保証する必要がある場合は、算出されたバケツが空になるまでの時間待てばよいだけである。実際、バケツに対する水の追加速度を継続的に監視することにより、排出されるべきコップの水を加えた時点で、バケツがどの程度いっぱいであったかをある程度知ることができる。これによって、遅延を減らすことが可能になる。この近似の環境では、たくさんの水増しをする必要がある(例えば、完全に空になるまでに1秒かかると思えば、計算のわずかな誤差をカバーするために2秒待つ)。
【００４６】
この水とバケツのアナロジーは、書き込みキャッシュをフラッシュする際のフリータイム法を表している。バケツが空になる速度と書き込みキャッシュがフラッシュされる速度が等しいことに注意する必要がある。ここで、書き込みキャッシュがフラッシュされる速度とは、シークタイムと転送速度の関数である。したがって、書き込みキャッシュ内のデータのディスク近接度、すなわち、ディスクのどこに書込まれるのか、によってキャッシュをフラッシュするのにかかる時間が大きく左右される。言い換えれば、ディスク媒体の1つの領域に大量のデータを書込む方が、データを少しずつディスク媒体全体にわたって書込むよりもはるかに短時間でできる。しかし、通常の実際の速度の方がはるかに良いであろうことを認めた上で、最悪のケースのフラッシュ速度として測定でき、使用できるのは後者の方である。ディスクコントローラによってどのデータが最初にキャッシュから書込まれたかを推測することはできないので、ディスクコントローラに書込まれたページロケーションを監視し、転送時間に対するシークタイムの比を予測することができず、したがって、動的に推定カレントフラッシュ速度を生成することもできない。
【００４７】
ディスクコントローラの問題に戻ると、書き込みキャッシュがフラッシュされたことを保証するために、概していつ遅延を挿入するのか、という問題がある。書き込みを転記するプロセスがある。一般にユーザは、ディスクアクティビティ休止があった時点(セーフポイント)を選択してアクセスすることしかできない。これにより、変更処理中の過去データへのアクセスが防止される。したがって、休止が十分に長ければ、書き込みキャッシュのフラッシュは、セーフポイントを識別する目安となる。クラッシュ後にコンピュータを再始動させる際、ユーザは、先の時間、すなわちセーフポイントに戻るか、単にクラッシュ直前の状態のディスクを使用するか、選択することができる。後者の場合、ディスクアクティビティに休止が存在しなかった可能性のある時点までエンジンはそのデータ構造を回復する。言い換えれば、長いディスクアクティビティのシーケンスの途中でクラッシュが発生したのである。待ち時間に基づくフラッシュ法を使用した場合、クラッシュ以前に待ち時間までに書込まれた全てのデータが存在する。しかし、ディスクコントローラが待ち時間後にディスク媒体にデータを実際に書込んだかどうか信用できない場合、エンジンはディスクアクティビティに記録された最後のフラッシュタイムマーカよりも前に書込まれた全てのデータを破棄するより他ない。言い換えれば、データのブロックが実際にディスク媒体に転送されたことを保証するのに十分なフリータイムが経過したとエンジンによって判断されたら、エンジンは適切なタイムマーカを書くのである。このマーカが一旦ディスクメディアに到達すると、ブロックの妥当性が確立される。クラッシュから回復する際、媒体に書込まれはしたがそれに続くタイムマーカを有さないデータは、データの一部が欠けている可能性があるとして破棄される。実際、ユーザは通常、クラッシュ時に書かれた、または書かれている最中であったデータに興味がないので、このデータを破棄しても問題はない。
【００４８】
フラッシュを必要とする他のエンジンアクティビティは、ディスク内のデータの並べ替え（スワップ）を行う時である。このプロセスは、プロセスクラッシュプルーフ(クラッシュの際に、データが失われることなくプロセスを再開することができる)にするために、ある特定の時点でディスクにフラッシュされたと仮定される明確な転送ステップを伴う。移動させるデータがたくさんあり、フラッシュを行わなければならない点がたくさんあることも考えられる。したがって、書き込みが実際にディスクに到達したことを保証するために、遅延が特定の時点で要求されるのはこのアクティビティにおいてである。
【００４９】
適度に効率のよいスワッププロセスの単純な例には、50メガバイトスワップ領域の使用が含まれる。1メガバイト毎秒の平均転送速度では、このデータ全てを書込むのに50秒かかる。ディスクコントローラが1メガバイトの書き込みキャッシュを有するとしたら、キャッシュをディスクにフラッシュするのに1秒のフリータイムがかかる。したがって、50メガバイトのスワップ領域を書込んだ後のある時点で、1メガバイトのキャッシュが(1メガバイト毎秒で)フラッシュされたことを保証するために、ディスクからディスクコントローラへの転送に(累積型の)1秒の遅延が挿入される。スワップ領域への書込み50秒に対して1秒の遅延という比率は妥当である(2%のパフォーマンスヒットである)。
【００５０】
この比を妥当な値にするための重要な観点は、ディスクにフラッシュされたことがわかっていなくてはいけない時点の間に書込まれるデータの量は、多くてもよいということである(前の例では50メガバイトであった)。一方、フラッシュが必要とされるまでに1メガバイトしか書込まれないとしたら、データ転送にかかる時間と、挿入される遅延の比が好ましくなくなる(1秒のライト毎に1秒の遅延、すなわち50%のパフォーマンスヒット)。実際に実装する際には、ディスクコントローラの正確なタイミングが分かり難いので、エンジンは遅延時間に大幅な誤差を設ける必要がある。（有効な）フラッシュの合間に書き込まれる大きな領域を持つ必要がある場合、エンジン設計は、与えられたディスクロケーションが、変更、およびその後のフラッシング、さらにその後の変更（前述のように、フラッシュの合間の書き込みよりも速い速度で行われる）を要求してはならないような、エンジン設計でなければならない。このことについては後述するが、U.S.'733に記載されたスワッププロセスも頻繁なフラッシュを必要としたが、本発明よってその必要性も克服された点に注意する必要がある。
【００５１】
スワッピングは通常バックグラウンドで実行され、ユーザに要求されたディスクアクティビティにより割込み可能である。スワッピングプロセスでフリータイムに基づくフラッシュが必要とされ、ディスクアクティビティのバーストを始めた場合、ユーザのアクティビティ終了後に必要な遅延が挿入される。
【００５２】
キャッシュがフラッシュされなければならない他の時点は、履歴バッファが急激に上書きされて転記プロセスが中止されている時と、システムがシャットダウンする時である。どちらのイベントも頻繁に起こるものではなく、少しの遅延を追加することなど取るに足らない。
【００５３】
データのブロックが有効であることをディスク上に示す実際の方法は、タイムスタンプやタイムマーカ等の終了フラグを十分な待ち時間の後、または、ディスクアクティビティフリータイムが経過した後に書くことである。
【００５４】
【一定のディスクアクティビティおよびセーフポイント】
セーフポイントという概念は、ディスクに合理的に属する全てのものが存在する (そして実際に媒体に書込まれている)という時点を意味している。これは、ファイルのセーブ等のディスクベースのオペレーションが完了し、全てのサポートオペレーティングシステム構造が更新されたことを意味する。そのような点においてシステムを突如停止させて(リセットまたは電源を切る)も、コンピュータを再始動させる際にそのデータが損なわれていないことをユーザは当然と考えることができる。通常エンジンは、ディスクアクティビティの休止を利用してそのような点をマークする。（もちろん、オペレーティングシステムからエンジンに信号を送ってもよい。）大量のディスクアクティビティの最中にコンピュータがリセットされるような状況では、ディスク媒体に実際に書込まれたデータはあてにならないとして、ユーザは普通、何も期待できないと理解する。また、別の状況もある。これは、ディスクアクティビティが比較的一定だが量が少ないときに発生する。そのような状況は、例えば、速度の遅いモデムを使用して大きなファイルをダウンロードしているときに起こる。さらに、このアクティビティは、ワードプロセッサ文書のセーブ等の他のアクティビティと概ね同時に起こることがある(すなわち、ユーザはダウンロードすると同時にエディットすることができる)。
【００５５】
軽いが長期にわたるディスクアクティビティでは、(ディスクアクティビティ内の)単純な休止を使用してセーフポイントを設定しようとしても失敗する。これはゆっくりと書込まれたデータにとってはたいした問題ではないが、混ざり合った無関係かつ独立した更新にとっては重大な問題である。4時間かかるダウンロード中に、ユーザがあるファイルをエディットし、繰り返しセーブするケースを考えてみる。コンピュータがクラッシュしたときに備えて、ダウンロードした大部分およびあるファイルの異なるバージョンを回復可能なセーフポイントを設けることが重要である。
【００５６】
本発明では、いつセーフポイントを挿入するかを検出するために、より複雑な手段を使用している。ある最小期間におけるディスクアクティビティの完全な休止を探す代わりに、エンジンはディスクアクティビティの速度を監視する。アクティビティ速度が急激に落ちたときにセーフポイントが挿入される。また、ディスクアクティビティ速度が最大レベルを反映した (すなわち、オペレーティングシステムが頻繁にそのキャッシュをフラッシュしていると思われるような速度) 速度以下である限り、合理的な速度でセーフポイントを自動的に挿入（強制）することができる。強制的に挿入されたセーフポイントでの状態でディスクを見れば、選択された時間までに書込まれた大部分のデータが得られるであろうが、ファイルの中には更新中に被害を受けたものもあるだろう。
【００５７】
強制的なセーフポイントはさらに、オペレーティングシステムによって処理されるファイルを開いたり閉じたりするオペレーション速度の急激な低下が観測された後に挿入されてもよい。いずれの場合も、強制的なセーフポイントは、いかなるディスク書き込み動作の後においてもある最小限の時間インターバルで定期的に挿入され、いつでもいくらかの予備位置(セーフポイント)が利用可能であるようにしなければならない。
【００５８】
【共用ディスク】
先のセーフポイントの説明では、エンジンがユーザのアクティビティをディスクアクティビティから推論できるような単一ユーザコンピュータシステムを想定した。例えば、ディスク書き込み動作のバーストが行われているときは、ユーザはファイルをセーブしようとしていることが多い。バースト以前に溯ってディスクをビューすれば、更新される前のファイルが見られ、バースト後には変更された状態のファイルが見られる。しかし、共用ディスク環境(例えば、ネットワークファイルサーバ)では、ふたり以上のユーザのアクティビティが全体のディスクアクティビティの中で混ざりあっている。あるユーザのディスクアクティビティにおける休止は、他のユーザのアクティビティの最中に発生することもあるので、システム全体のセーフポイントを特定する手だては全くない。したがって、複数のユーザをサポートするためには、それぞれのユーザのアクティビティを分離して、そのアクティビティの終了後にディスクにフラッシュされたことを保証する手段が必要である。さらに、ひとりのユーザがディスクを激しく使うことによって、他のユーザに対する回復能力が低下するのは好ましくない。したがって、ユーザの観点から言えば、各々が自分の履歴バッファを有することが好ましいのである。
【００５９】
単一ユーザコンピュータシステムと共用ディスクシステムの大きな違いは、単一ユーザシステムの場合、最近入り込んだがその性質が実際には分かっていない問題を解決するために、時間を溯るのが良い解決方法であることが多いということである。言い換えれば、たとえユーザのコンピュータが現在は作動していなくても1時間前に作動していれば、一番簡単な方法は、1時間前に戻り、この破棄された1時間の間に変更された所望のファイルを回復することである。しかし、共用ディスクの場合は、あるユーザしか経験していない問題を解決するために、そのユーザがシステム全体の時間を戻すことを他のユーザは望まない。共用ディスク環境では通常、システムは正常に作動しており、ユーザは特定のファイルやディレクトリを回復する必要がある。しかし、単一または複数のユーザによって共用されるシステムが、もはや機能しないまでに汚染された時に、システム全体の時間を戻すことはよい解決方法である。共用環境では、ディスクの構成を記述している内部データ構造がオペレーティングシステムによって定期的にフラッシュされると仮定されるので(RAMからディスクに)、ある時点まで溯ることにより概ね利用可能なシステムが得られる。例えばWindowsNTでは、エンジンはOSキャッシュのフラッシュを開始することができ(オペレーティングシステムキャッシュとディスクコントローラのキャッシュとが異なる)、このプロセスがある好ましい速度で行われることを保証することができる。
【００６０】
共用ディスクを過去のある時点に戻すことは、全てのユーザに影響を及ぼすことであり、主としてシステム全体が作動不能になったときに有用なことである。例えば、大規模なソフトウェアアップグレードまたは更新を行うときに発生する。
【００６１】
共用ディスクシステムが作動不能になる場合以外は、ディスク全体を戻すことは有用ではない。その代わりに、あるファイルやディレクトリだけを戻したい(復元したい)と願うかもしれない。ユーザアクティビティを分離し、彼らのデータがOSキャッシュからフラッシュされたことを保証する必要性が生じる。例えば、あるユーザがファイルを変更して、その変更がOSキャッシュに入れられるとする。そして、他のユーザがたくさんの入出力を行ったためにOSキャッシュがフラッシュされなくなり、先ほどのユーザがまた先ほどのファイルを変更した場合、このアクティビティは全くディスクには書込まれていないことになり、ディスクに書込まれたことに基づいて変更されたファイルの最初のバージョンを復元することは全くできない。
【００６２】
これに対する解決方法は、エンジンがユーザアクティビティを監視してユーザをそれぞれ分離して、あるユーザが一連のファイル変更を終えたと思われたときに、これらの変更がOSキャッシュからフラッシュされるように強制することである。OSキャッシュのどのデータがどのユーザと関連しているかを分離するのは、複数のユーザによって変更されるデータがあるかもしれないことを考慮すると、困難なことであるということが判明するかもしれない。解決方法は、たとえ他のユーザが変更を加えている最中であっても、あるユーザに対してセーフポイントを確立する必要性に対応する時点（ポイント）において、キャッシュ全体を単純にフラッシュすることである。
【００６３】
次の問題は、どのようにしてあるユーザのファイルアクティビティと他のユーザのそれとを分離するかである。エンジンが、各ファイルリクエストとそれを発したユーザを見られるレベルでオペレーティングシステムを動かせるとしたら、各ユーザのアクティビティの休止を容易に探すことができる。休止が検出されると、OSキャッシュ全体がフラッシュでき、特定のユーザためにセーフポイントが設定できる。
【００６４】
個別のユーザをファイルリクエストと関連付けられるレベルでオペレーティングシステムを操るすべがない場合、次によい方法は、ファイルおよびディレクトリに対するアクセスの頻度を監視することである。非共用ディレクトリへのアクセスの休止を探すこともできる。また、変更されたファイルのリストを保持することもできる。ファイルが最後に変更されてからある最小限の時間が経過した後、ファイルを変更するという別のリクエストが発生した場合、新しいリクエストが処理される前にOSキャッシュをフラッシュしてセーフポイントを設定することができる。これにより、必要に応じてファイルの先の状態が回復できることが保証される。この強制的なセーフポイントは当然、複数のユーザのアクティビティが重複するときにのみ生成される。あるユーザのアクティビティが、他のユーザアクティビティと重複することなくバーストとして発生する場合、フラッシングおよびセーフポイントの作成は必然的に、そのユーザのアクティビティのバースト後に続く休止で行われることになる(すなわち、単一のユーザにとってのシナリオとなる)。エンジンが覚えていることができないほどの大量のファイルが変更される場合、強制的にフラッシュしてセーフポイントを作成して、トラッキングをやり直せばよいだけである。言い換えれば、必要以上にセーフポイントを設けても、性能低下以外は損害を受けないということである。反対に、ユーザがそれに対応した時点に戻ることができなくならないよう、セーフポイントを逸しないことの方が重要である。
【００６５】
ある特定のファイルが2度目に変更されようとしていて、最初の変更からある最小限の時間が経過しているときに、セーフポイントを強制的に挿入することによりユーザアクティビティを分離するという方法は間接的である。エンジンは単に、ファイルの異なるバージョンを合理的に分離するためのセーフポイントが存在することを保証しているに過ぎず、これによってユーザアクティビティを分離しているのである。どのユーザに対しても必要以上のセーフポイントが存在することになり、入手可能なセーフポイントの全ての中から各ユーザは自分のアクティビティに関連するセーフポイントを見つけ出すことになる。
【００６６】
【単純な復元可能マッピングシステム】
エンジンのデータ構造の汚染の問題に戻ると、U.S.'733には、何らかのデータの損失が全てのデータの損失を引き起こす可能性のある、複雑なデータ構造の使用(義務づけてはいないが)についての記載がある。例えば、ディスクをリマップするためにツリーデータ構造が使用されていて、ツリーの一部(ノード)が失われたら、ツリー全体が使用不能となる可能性がある。ツリーは、ユーザのデータがディスク上のどこに実際に位置するかを示すものであるため、ツリーがなくてはユーザのデータは実際上失われる(厳密に言えば、ごちゃまぜになる)。
【００６７】
U.S.'733には、履歴ヘッダおよびメインエリアマップの使用についての記載がある。U.S.'733のTemp法でも、時間が許せば履歴データとメインエリアデータが適切なロケーションにスワップされたが、スワップされていない履歴ページが再使用される可能性があった。それらには、新規のメインエリアデータや、内部エンジンデータや、エンジンによって処理されるあらゆる種類のデータが含まれる可能性がある。例えば、OS可視ロケーション10に対応するデータAAを含むロケーション10を有するディスクの場合を考える(マッピングは不要)。ユーザがこのデータをデータBBで上書きすると、エンジンはこのデータをロケーション10からロケーション50に転記する。ロケーション10には履歴データが保持されることになる。しばらくすると、より多くのデータが変更され新しい履歴状態が保持され、履歴データAAは非常に古いものになる。最終的にロケーション10は最も古い履歴データとなり、マップ内のノードや、転記された書き込みを受け入れる等の何らかの目的のために使用するための次のロケーションがエンジンにとって必要となる。このシナリオのポイントは、記載されたTemp法により、どのように様々な種類のデータがディスクの媒体全体にわたって記憶されるのか(すなわち、ユーザのカレントイメージデータと混ぜ合わせるのか)ということを示すことである。
【００６８】
ある未知のソースによって引き起こされる修正不能な汚染の問題について説明する。前述した技術では、ディスク上およびRAM内のデータを複製して慎重に確認を行い、ディスクに汚染が伝播する前にRAM汚染を検出することにより、汚染の可能性を概ね低減することができるとされたが、それでもなお、汚染が発生することがある。例えば、ページAがBをポイントするデータを含み、BはCにポイントするデータを含むような、データ構造がリンクを伴うものであれば、ページBのデータが失われればCも失われることになる。したがって、複雑なリンクに基づくデータ構造の汚染は概して破滅的である。
【００６９】
一方、部分的汚染に当然強いのはページの順次シーケンスである。例えば、ページロケーション#5、#6、#7、#8に文書のASCIIテキストが含まれ、ページ#6が汚染されたら、ページロケーション#5、#7、および#8からテキストの一部を検索することができる。一方、ページ#5のデータの一部に次のページのロケーションを示すデータが含まれ、このページが汚染されたとしたら、文書の残りの部分を検索することはできない。
【００７０】
したがって、本発明は、Temp法ベースで記載されたデータ構造およびプロセスを調整する。図1は、New Temp法の最初の状態を示す。一連のメイン領域ページ、マップ、および、一連のエキストラページおよび履歴ヘッダ（右側にある隣り合わせになった2列）を示す。図2は、オペレーティングシステムによってデータ「d2a」がロケーション2に書込まれた後のできごとを示す。書き込みがエキストラページに転記されて、対応する履歴ヘッダにデータがどこに属するかを示す注記が書込まれている。オペレーティングシステムのロケーション#2が実際にどこに位置しているかを示すためにメインマップが更新されたことにも注目すべきである。図3では、セーフポイントが設定されている。図4には、さらに3つの書き込みが図示されている。変更されるページが、現在形成されつつあるグループの一部であるとき、セーフポイントによって境界づけられた先の状態を保存することなくデータを直接上書きすることができることに注目すべきである。図4のロケーション#1は2度書込まれており、エキストラページエリアには最終的な状態がセーブされている。図5および6は転記されたデータと履歴データが交換されるスワップと、それに伴い更新されるマップとを示している。(いずれのスワップサイクルに関するページも、セーフポイント境界に対応する必要はない。)

【００７１】
一見したところ、これらのデータ構造およびプロセスは、Temp法で説明されたものと同様のようである。しかし、このNew Temp法では、エキストラページ／履歴ヘッダテーブル内の次の書き込みロケーションがスワップされていないデータに進むことを許可しない。したがって、もし図5および6においてスワッピングが起きなかった場合は、前述したアルゴリズムを継続することができない。どんな書き込みアクティビティのバーストをも吸収するのに十分なエキストラページとそれに対応する履歴ヘッダがあり、それに引き続いてスワッピングが実行できる時間があることが望まれる。それにより、オーバランする状況がほとんどなくなるからである。しかし、大量のデータが急激に書込まれ(かつ転記され)てオーバランが発生し、後にスワップされた利用可能なエキストラページが無ければエンジンはシャットダウンする。この際に、ユーザに(可能ならば)全ての履歴データが失われようとしていることが警告され、メインマップに最後に示された位置へデータが書込まれる。最終的に、フリータイムが発生したときにスワップが実行され、履歴ヘッダがリセットされる(セーブされた他の履歴状態がないことを示すために再初期化)。
【００７２】
New Temp法は、強制的にシャットダウンされうるという点においてオリジナルの(古い)方法とは異なる。オリジナルの方法は、ある種の断片化の発生を伴いながら、スワッピングなしでどこまでも継続される。結果として、スワッピングためのフリータイムなしでユーザが書込みを続けると、書き込みは非常に断片化されたロケーションに転記されることになる。実際にこのパフォーマンスヒットでオリジナル方法を使用してシャットダウンを行うと、断片化と応答性が優先され、履歴状態のトラッキングが犠牲にされる。もしユーザが大量のデータを急激に変更するあまり、ごく最近の変更しか保存できないならば、これはあまり役に立たない、という議論があった。したがって、シャットダウンして速く動作する方がよいのである。
【００７３】
新しいTemp法でも古いTemp法でもシャットダウンするが、その違いは、新しい方法の方が早くシャットダウンするということである。しかし、スワップされていないデータに次の書き込みロケーションをラップさせないことにより、データ構造が簡単になる。ある時点でメインマップが失われると、履歴ヘッダから容易に再構築することができる。古いTemp法では、2つのメイン領域ページが相手に要求されたロケーションにあることを示すことができたため、スワッピングが必要であった。
【００７４】
このため、メインマップを失えば重大なスワッピング情報も同時に失われた。しかし、この状況は新しいTemp法では発生しないため、メインマップは、あるOS可視ページが実際はどこに位置しているのかを履歴ヘッダから判断し、ヘッダから再構築するための最適な方法である。
【００７５】
メインマップが失われた場合の回復プロセスは、次の書き込みポインタの最後の位置を見つけてメインマップをリセットし、履歴ヘッダをサイクルさせることで簡単に行える。各ヘッダが処理される毎に、対応するエキストラページにマップされるOS可視ロケーションがメインマップに追加される。ヘッダ内の動きの方向により、メインマップ内の先のリンクを上書きして複製が作成されるか、破棄される。例えば、図4においてメインマップの全てのリンクを廃棄する。次の書き込みポインタから始めて上向きに動く。最初に遭遇する履歴ヘッダはロケーション2を示しており、「d2b」にマップされる必要があり、次のヘッダはロケーション#1を示しており、「d1b」にマップされる必要がある。最後のヘッダはロケーション#2の繰り返しであり、ここではヘッダの時間を溯ろうとしており、メインマップに最も新しいユーザ書き込みが反映されているため、複製は無視される。これでメインマップが再構築された。実際これは、履歴ヘッダがメインマップの役割を果たしうることを示しており、各OS可視アクセスに対してマップをスキャンすることにより、参照が実際にどこに向けられるべきかが分かる。しかし、全てのディスクアクセスの莫大なテーブルをスキャンするのは非常に効率が悪く、より最適化された第二の検索手段の構成が必要とされる。
【００７６】
メインマップは複雑にリンクされたデータ構造(ツリーのように)であることが多く、汚染が発見されると破棄されて再構築される。履歴ヘッダの一部が汚染されると、履歴状態が失われるか、最近書かれた新規のデータ(上書きされた履歴データとスワップされていない)が失われる。いずれのケースにおいても、汚染の量は限られていると仮定すれば、ユーザデータのほとんどが無傷で使用可能である可能性が高く、また履歴状態も利用可能である。スワップされていないページが失われた場合は、ユーザに対して汚染が発生したということが通知され、ユーザは所望のファイルを確認してバックアップするか、復元する。汚染の状態は、ユーザのコンピュータが重大な問題を抱えていることを示す。
【００７７】
エキストラページおよび履歴ヘッダの連続的またはテーブルのような性質は、実質的な再構築を容易にし、複雑なマップの重要な部分が失われたことによる破滅的なユーザデータ損失が発生する可能性を実質的に排除する。
【００７８】
ユーザがデータを書込むのに伴い履歴ヘッダおよびエキストラページが順次更新されていく性質は、書き込みキャッシュによってフラッシュされたことを保証するためにデータを時間エージングさせる前述の方法に容易にぴったり当てはまる。言い換えれば、ユーザが変更を加えると、次の書き込みポインタに従いつつそれを進めながら、履歴ヘッダおよび対応するエキストラページにデータが書込まれる。クラッシュ時に書き込みキャッシュからフラッシュされる途中であったエリアを明らかにするために時間エージングノートを埋め込むことは容易である。
【００７９】
エンジンの他の重要な処理であるディスク上のデータの再編成またはスワッピングも、時間エージングフラッシングをサポートするために実行することができる。単一のスワップエリアを設け、スイッチページを利用して遷移状態を制御する代わりに、スワップエリアのテーブルが設定される。これにより、一連のスワップサイクルが開始され、ペンディングになっているスワップサイクルの1段階のデータが時間エージングされている(フラッシュされてディスク上に安定化されている)間に、他のスワップサイクルの現在の段階に対するセットアップを進行させることができる。フラッシュを達成するために遅延を挿入する必要がある場合、複数のスワップエリアを使用することにより、少なくともディスクアクティビティに対するフラッシュ率が最適(少しのフラッシュ)に保たれる。スワップ段階には、スワップに関係するデータをスワップエリアに集めることが含まれており、このバックアップコピーがディスクに安全に存在するようになると(かつフラッシュされると)、クラッシュの際に失われる心配なく、移動させることができる。詳細については、書き込みキャッシュのフラッシュに関するセクションを参照のこと。
【００８０】
回復性について扱うためにTemp法を用いて概要を説明した原理は、Always法にも同様に適用できる。
【図面の簡単な説明】
【図１】 本発明に係る新Temp法の初期状態を示す図。
【図２】 図1の例におけるロケーション2に、オペレーティングシステムによりデータ「d2a」が書込まれた後に起こることを示す図。
【図３】 本発明の1つの実施例にしたがって確立されたセーフポイントを示す図。
【図４】 本発明の1つの実施例に係る、更に3つの書き込みを示す図。
【図５】 本発明の1つの実施例に係る、転記されたデータと履歴データが交換されるスワッピングと、それに伴い更新されるマップを示す図。
【図６】 本発明の1つの実施例に係る、転記されたデータと履歴データが交換されるスワッピングと、それに伴い更新されるマップを示す図。

Claims (12)

1. データ回復動作中のデータの妥当性を判定するための方法であって、
   ディスクの書き込みキャッシュに書き込まれたデータブロックが、前記ディスクに書き込まれたことを保証する期間である待ち時間を決定する工程と、
   前記書き込みキャッシュを用いて、時間に関連する第１のマーカを含むデータブロックを、前記ディスクに書き込む工程と、
   データ回復動作中に、前記データブロックを前記ディスクから読み出す工程と、
   前記データブロックの前記第１のマーカを検査する工程と、
   前記第１のマーカが書き込まれた後の特定の期間に、前記ディスク上に第２のマーカが書き込まれた場合には、前記データブロックを妥当であると判断する工程と、を備え、
   前記特定の期間は、前記待ち時間以上の長さである、方法。
2. 請求項１に記載の方法であって、さらに、前記第１のマーカが書き込まれた後の前記特定の期間に、前記ディスク上に他のマーカが書き込まれていない場合には、前記データブロックを妥当ではないと判断する工程を備える、方法。
3. 請求項１に記載の方法であって、
   前記第２のマーカは、前のマーカが書き込まれてから、前記待ち時間に等しい期間が経過したことを示すタイムマーカである、方法。
4. 請求項１に記載の方法であって、
   前記第１のマーカは、前記データブロックが前記ディスクに送られた時間を示すタイムスタンプである、方法。
5. 請求項４に記載の方法であって、
   前記第１のマーカは、第２のタイムスタンプと比較され、前記第１のマーカが、前記第２のタイムスタンプの前の前記待ち時間以上の長さの期間に書き込まれたか否かが判定される、方法。
6. 請求項１に記載の方法であって、さらに、妥当であると判断されたデータブロックを前記データ回復動作中に用いる工程を備える、方法。
7. データ回復動作中のデータの妥当性を判定するためのコンピュータプログラムを格納するコンピュータ読み取り可能な媒体であって、前記コンピュータプログラムは、
   ディスクの書き込みキャッシュに書き込まれたデータブロックが、前記ディスクに書き込まれたことを保証する期間である待ち時間を決定するためのプログラムコードと、
   前記書き込みキャッシュを用いて、時間に関連する第１のマーカを含むデータブロックを、前記ディスクに書き込むためのプログラムコードと、
   データ回復動作中に、前記データブロックを前記ディスクから読み出すためのプログラムコードと、
   前記データブロックの前記第１のマーカを検査するためのプログラムコードと、
   前記第１のマーカが書き込まれた後の特定の期間に、前記ディスク上に第２のマーカが書き込まれた場合には、前記データブロックを妥当であると判断するためのプログラムコードと、を備え、
   前記特定の期間は、前記待ち時間以上の長さである、コンピュータ読み取り可能な媒体。
8. 請求項７に記載のコンピュータ読み取り可能な媒体であって、
   前記コンピュータプログラムは、さらに、前記第１のマーカが書き込まれた後の前記特定の期間に、前記ディスク上に他のマーカが書き込まれていない場合には、前記データブロックを妥当ではないと判断するためのプログラムコードを備える、コンピュータ読み取り可能な媒体。
9. 請求項７に記載のコンピュータ読み取り可能な媒体であって、
   前記第２のマーカは、前のマーカが書き込まれてから、前記待ち時間に等しい期間が経過したことを示すタイムマーカである、コンピュータ読み取り可能な媒体。
10. 請求項７に記載のコンピュータ読み取り可能な媒体であって、
    前記第１のマーカは、前記データブロックが前記ディスクに送られた時間を示すタイムスタンプである、コンピュータ読み取り可能な媒体。
11. 請求項１０に記載のコンピュータ読み取り可能な媒体であって、
    前記第１のマーカは、第２のタイムスタンプと比較され、前記第１のマーカが、前記第２のタイムスタンプの前の前記待ち時間以上の長さの期間に書き込まれたか否かが判定される、コンピュータ読み取り可能な媒体。
12. 請求項７に記載のコンピュータ読み取り可能な媒体であって、
    前記コンピュータプログラムは、さらに、妥当であると判断されたデータブロックを前記データ回復動作中に用いるためのプログラムコードを備える、コンピュータ読み取り可能な媒体。

Images