JP2002543493A

JP2002543493A - データのセーブ、使用、回復におけるデータの汚染および共用ディスクを扱うための方法、ソフトウェアおよび装置

Info

Publication number: JP2002543493A
Application number: JP2000614125A
Authority: JP
Inventors: シュナイダー・エリック・ディー．; ガスタフソン・マイケル・ジェイ．; ハグラー・ダニエル・ジェイ．
Original assignee: ワイルドファイル，インコーポレイティド
Priority date: 1999-04-23
Filing date: 2000-04-24
Publication date: 2002-12-17
Anticipated expiration: 2020-04-24
Also published as: DE60016866T2; ATE285602T1; JP3984789B2; EP1090348A1; EP1090348B1; AU4486200A; WO2000065447A1; DE60016866D1

Abstract

(57)【要約】データに対する変更の記録を記録媒体上に保持し、先の時間における媒体の状態を再構築可能にする方法が記載されている。このプロセスを向上させ、改良するために他の実施例も提供されている。この中には、記録媒体に転送される前に汚染を検出するために比較されるデータの2つのコピーをRAM内に保持すること、ロジック保護とビューとを分離すること、互換性のないソフトウェアから保護するためにディスクを隠蔽すること、一定の時間が経過したことを保証することにより書き込みキャッシュをフラッシュすること、一定のフリータイムが経過したことを保証し、かつ必要に応じて遅延を挿入することにより、書き込みキャッシュをフラッシュすること、ディスクアクティビティの速度が低下した後にセーフポイントを挿入すること、セーフポイントを定期的に挿入すること、ひとりのユーザに対してセーフポイントを設定する必要性が検出された後にOSキャッシュ全体をフラッシュすること、ディレクトリおよびファイルを監視することによりユーザアクティビティを分離すること、汚染の際に、順次編成されたテーブルから概ね再構築することができる、複雑にリンクされたデータ構造を使用してエンジンを実行すること、が含まれる。

Description

【発明の詳細な説明】

【０００１】

【著作権情報／許可】

本特許の開示内容には、部分的に著作権保護の対象となるものが含まれる。当
該著作権者は、特許庁の特許ファイルまたは記録にある特許文献または特許開示
を何人が複製することに対しても異論はないが、その他の目的での使用に対して
は全ての著作権を留保する。下記の著作権表示は、以下および図中に記載する、
ソフトウェアおよびデータに適用される。Copyright 1999, Wild File, Inc. Al
l Rights Reserved.

【０００２】

【文献の援用】

1998年6月26日付けで出願された、「データをセーブ、使用、および回復する
ための方法、ソフトウェア、および装置」という名称の、米国特許出願番号09/1
05,733の出願全体を本明細書中に援用する。

【０００３】

【発明の技術分野】

本発明は、デジタルデータの記憶に関し、より詳細には、デジタルコンピュー
タに記憶されたデータのバックアップおよび回復のための方法および装置に関す
る。

【０００４】

【発明の背景】

1998年6月26日付けで出願された、「データをセーブ、使用、および回復する
ための方法、ソフトウェア、および装置」という名称の、米国特許出願番号09/1
05,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はオペレーティングシステムのディスクに基づくデータを検査し、可能な限り修復しようとする。重要なことは、Sc anDiskは損害を逆戻りさせたり、ある既知の先の良好な状態に戻すことができず、単に、オペレーティングシステムのデータ構造が再使用できるようになるまで様々なリンクを修正したり調整したりするにすぎないということである。多くの場合、かなりの量のデータが失われるか汚染される。すなわち、ファイルの一部が失われたり変更されたり、場合によってはファイル全体が消滅する。しかし、コンピュータ上にはたくさんのファイルがあり、その多くは全く使用されないか、使用されたとしてもごくたまにである。したがって、コンピュータが機能しなくなる前にはかなりの汚染が発生することがある。現在のコンピュータはどのコンピュータも多かれ少なかれ「病気」になるのであり、時間の経過につれて、システムの様々な部分が徐々に汚染される。定期的にディスクを一掃してオペレーティングシステムやアプリケーションやデータを再インストールするユーザもいる。

【００１７】

【時間遡及の保証】

この徐々に進行する汚染は、エンジンの約束事とは相反するものである。エン
ジンの目的は、先のある時点と全く同じ状態にディスクを戻すことであり、徐々
に必ず起こる汚染に対して免疫を有さなければならない。これは、現在のところ
、ScanDiskの能力(または同等の修復ユーティリティ)の範囲で最大限修正されて
いる。

【００１８】より完全な世界では、オペレーティングシステムはエンジンおよびそのデータ
をワイルドポインタやウィルスから守ことができ、ディスク上のデータの冗長性
に少し注意するだけで(時々発生する転送不良に備えるため)、U.S.'733の技術で
十分である。しかしながら、オペレーティングシステムはその最下位レベルにお
いて拡張可能でなければならず、したがって、それらによってあるデバイスドラ
イバを他のデバイスドライバから完璧に保護できるようにするのは困難である。
また、オペレーティングシステムは通常、非常に大きなプログラムであるため、
その中から全てのバグを除去するのは困難である。

【００１９】全てのプログラムが相互間における「完璧な」保護を望んでいるように見える
かもしれない。マイクロプロセッサに組み込まれたハードウェア手段(プログラ
ムから制御を取り除くための割込みや、迷書き込みをトラップする記憶保護機構
等)により、オペレーティングシステムが完璧に保護しようとしているのも事実
である。しかし同時に、オペレーティングシステムの保護とその効率性はバラン
スされていなければならない。効率的なコードは保護境界の負担を望まないこと
が多い(タスクを他のタスクから常に保護するには時間がかかる)。しかし、エン
ジンは単なるプログラムではない。その役割は、不測の事態が発生したときに、
コンピュータを再始動し、あるより良い状態まで全てを戻すことである。このフ
ォールバックポジションは保護される必要がある。ユーザは通常、プログラムは
コンピュータ内のRAMの領域内で実行されていると理解しており、コンピュータ
を再始動した際にディスクの内容が損なわれていないことを当然と考えるか、少
なくともそう希望する。したがって、エンジンおよびディスクを保護するには、
オペレーティングシステムから得られる妥協されたレベルを上回るハードウェア
および／または技術でなければ無理だという意見もある。

【００２０】以下に、エンジンが取り組む必要のある問題の概要を示す。・ワイルドポインタデータ汚染・ディスクからの汚染されたデータの読取り(転送不良、バッドページ等) ・ディスクに直接アクセスできる互換性のないソフトウェアの使用

【００２１】 U.S.'733では、メインマイクロプロセッサ(ファイアウォール)および／または
マザーボードに特別なハードウェアを設けるか、エンジンを実際にディスクコン
トローラ内のコンピュータに移動させることによりエンジンを保護することを構
想していた。これにより、ワイルドポインタの問題(エンジンにバグが存在しな
いと仮定して)がなくなり、互換性のないソフトウェアが直接ディスクにアクセ
スすることもなくなる。しかし、現在使用されているコンピュータには、ハード
ウェアを変更するという選択肢が与えられていないものが既に多数ある。本発明
は、データの冗長性の原理に基づいた解決方法を提供する。

【００２２】

【汚染を検出するためのRAMデータの複製】

ワイルドポインタ(あるいは他の手段)による迷書き込みに対処するために、本
発明のエンジンは、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.'7
33に記載されたスワッププロセスも頻繁なフラッシュを必要としたが、本発明よ
ってその必要性も克服された点に注意する必要がある。

【００５１】スワッピングは通常バックグラウンドで実行され、ユーザに要求されたディス
クアクティビティにより割込み可能である。スワッピングプロセスでフリータイ
ムに基づくフラッシュが必要とされ、ディスクアクティビティのバーストを始め
た場合、ユーザのアクティビティ終了後に必要な遅延が挿入される。

【００５２】キャッシュがフラッシュされなければならない他の時点は、履歴バッファが急
激に上書きされて転記プロセスが中止されている時と、システムがシャットダウ
ンする時である。どちらのイベントも頻繁に起こるものではなく、少しの遅延を
追加することなど取るに足らない。

【００５３】データのブロックが有効であることをディスク上に示す実際の方法は、タイム
スタンプやタイムマーカ等の終了フラグを十分な待ち時間の後、または、ディス
クアクティビティフリータイムが経過した後に書くことである。

【００５４】

【一定のディスクアクティビティおよびセーフポイント】

セーフポイントという概念は、ディスクに合理的に属する全てのものが存在す
る (そして実際に媒体に書込まれている)という時点を意味している。これは、
ファイルのセーブ等のディスクベースのオペレーションが完了し、全てのサポー
トオペレーティングシステム構造が更新されたことを意味する。そのような点に
おいてシステムを突如停止させて(リセットまたは電源を切る)も、コンピュータ
を再始動させる際にそのデータが損なわれていないことをユーザは当然と考える
ことができる。通常エンジンは、ディスクアクティビティの休止を利用してその
ような点をマークする。（もちろん、オペレーティングシステムからエンジンに
信号を送ってもよい。）大量のディスクアクティビティの最中にコンピュータが
リセットされるような状況では、ディスク媒体に実際に書込まれたデータはあて
にならないとして、ユーザは普通、何も期待できないと理解する。また、別の状
況もある。これは、ディスクアクティビティが比較的一定だが量が少ないときに
発生する。そのような状況は、例えば、速度の遅いモデムを使用して大きなファ
イルをダウンロードしているときに起こる。さらに、このアクティビティは、ワ
ードプロセッサ文書のセーブ等の他のアクティビティと概ね同時に起こることが
ある(すなわち、ユーザはダウンロードすると同時にエディットすることができ
る)。

【００５５】軽いが長期にわたるディスクアクティビティでは、(ディスクアクティビティ
内の)単純な休止を使用してセーフポイントを設定しようとしても失敗する。こ
れはゆっくりと書込まれたデータにとってはたいした問題ではないが、混ざり合
った無関係かつ独立した更新にとっては重大な問題である。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つの実施例に係る、転記されたデータと履歴データが交換されるス
ワッピングと、それに伴い更新されるマップを示す図。

【手続補正書】

【提出日】平成１３年３月２日（２００１．３．２）

【手続補正１】

【補正対象書類名】明細書

【補正対象項目名】特許請求の範囲

【補正方法】変更

【補正の内容】

【特許請求の範囲】

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｇ１１Ｂ 20/10 Ｇ１１Ｂ 20/10 Ｈ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者ハグラー・ダニエル・ジェイ．アメリカ合衆国ミネソタ州55946 ケニヨン，カウンティ・14・ブルバード， 42002 Ｆターム(参考） 5B005 JJ01 KK12 LL11 MM11 WW00 WW15 5B018 GA01 GA04 HA03 KA02 MA03 MA12 QA15 5B065 BA01 PA02 PA12 5B082 FA12 5D044 AB01 BC01 CC05 EF03 FG10 GK12 【要約の続き】とができる、複雑にリンクされたデータ構造を使用してエンジンを実行すること、が含まれる。

Claims

【特許請求の範囲】

【請求項１】記録媒体上のデータへの変更の記録を保持することと、前記記録媒体に転送される前に汚染を検出するために比較されるデータの2つの
コピーをRAM内に保持すること、を含む方法。
【請求項２】記録媒体上のデータへの変更の記録を保持することと、ロジック保護とビューとを分離すること、を含む方法。
【請求項３】記録媒体上のデータへの変更の記録を保持することと、互換性のないソフトウェアから保護するためにディスクを隠蔽すること、を含む
方法。
【請求項４】記録媒体上のデータへの変更の記録を保持することと、一定の時間が経過したことを保証することにより書き込みキャッシュをフラッシ
ュすること、とを含む方法。
【請求項５】記録媒体上のデータへの変更の記録を保持することと、一定のフリータイムが経過したことを保証し、かつ必要に応じて遅延を挿入する
ことにより、書き込みキャッシュをフラッシュすることと、を含む方法。
【請求項６】記録媒体上のデータへの変更の記録を保持することと、ディスクアクティビティの速度が低下した後にセーフポイントを挿入すること、
を含む方法。
【請求項７】記録媒体上のデータへの変更の記録を保持することと、セーフポイントを定期的に挿入すること、を含む方法。
【請求項８】記録媒体上のデータへの変更の記録を保持することと、ひとりのユーザに対してセーフポイントを設定する必要性が検出された後にOSキ
ャッシュ全体をフラッシュすること、とを含む方法。
【請求項９】記録媒体上のデータへの変更の記録を保持することと、ディレクトリおよびファイルを監視することによりユーザアクティビティを分離
すること、を含む方法。
【請求項１０】記録媒体上のデータへの変更の記録を保持することと、汚染が発生した場合に、順次編成されたテーブルから概ね再構築することができ
るエンジンを実現するために、複雑にリンクされたデータ構造を使用すること、
と、を含む方法。
【請求項１１】記録媒体上のデータへの変更の記録を保持する手段と、記録媒体に転送される前に汚染を検出するために比較されるデータの2つのコピ
ーをRAM内に保持する手段と、を有する装置。
【請求項１２】記録媒体上のデータへの変更の記録を保持する手段と、ロジック保護とビューとを分離する手段と、を有する装置。
【請求項１３】記録媒体上のデータへの変更の記録を保持する手段と、互換性のないソフトウェアから保護するためにディスクを隠蔽する手段と、を有
する装置。
【請求項１４】記録媒体上のデータへの変更の記録を保持する手段と、一定の時間が経過したことを保証することにより書き込みキャッシュをフラッシ
ュする手段と、を有する装置。
【請求項１５】記録媒体上のデータへの変更の記録を保持する手段と、一定のフリータイムが経過したことを保証し、かつ必要に応じて遅延を挿入する
ことにより、書き込みキャッシュをフラッシュする手段と、を有する装置。
【請求項１６】記録媒体上のデータへの変更の記録を保持する手段と、ディスクアクティビティの速度が低下した後にセーフポイントを挿入する手段と
、を有する装置。
【請求項１７】記録媒体上のデータへの変更の記録を保持する手段と、セーフポイントを定期的に挿入する手段と、を有する装置。
【請求項１８】記録媒体上のデータへの変更の記録を保持する手段と、ひとりのユーザに対してセーフポイントを設定する必要性が検出された後にOSキ
ャッシュ全体をフラッシュする手段と、を有する装置。
【請求項１９】ディレクトリおよびファイルを監視することによりユーザ
アクティビティを分離する手段を有する装置。
【請求項２０】記録媒体上のデータへの変更の記録を保持する手段と、汚染が発生した場合に、順次編成されたテーブルから概ね再構築することができ
るエンジンを実現するために、複雑にリンクされたデータ構造を使用する手段、
を有する装置。
【請求項２１】適当に構成されたコンピュータで実行された場合には、請
求項１、２、３、４、５、６、７、８、９または１０に記載の方法を実行するコ
ンピュータプログラムを格納するコンピュータ読取り可能媒体。