JP3878412B2 - データを保存し使用し及び回復する方法 - Google Patents

データを保存し使用し及び回復する方法 Download PDF

Info

Publication number
JP3878412B2
JP3878412B2 JP2000509037A JP2000509037A JP3878412B2 JP 3878412 B2 JP3878412 B2 JP 3878412B2 JP 2000509037 A JP2000509037 A JP 2000509037A JP 2000509037 A JP2000509037 A JP 2000509037A JP 3878412 B2 JP3878412 B2 JP 3878412B2
Authority
JP
Japan
Prior art keywords
disk
data
location
time
page
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2000509037A
Other languages
English (en)
Other versions
JP2004504645A (ja
JP2004504645A5 (ja
Inventor
ディー． シュナイダー，エリック
シー． ファーリル，ウィリアム
エヌ． ウィーラー，ダグラス
イー． シュワルツ，ローレンス
ダブリュ． ブラッジマン，エドワード
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NortonLifeLock Inc
Original Assignee
Symantec Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Symantec Corp filed Critical Symantec Corp
Publication of JP2004504645A publication Critical patent/JP2004504645A/ja
Publication of JP2004504645A5 publication Critical patent/JP2004504645A5/ja
Application granted granted Critical
Publication of JP3878412B2 publication Critical patent/JP3878412B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1873—Versioning file systems, temporal file systems, e.g. file system supporting different historic versions of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1456—Hardware arrangements for backup
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Library & Information Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Description

【０００１】
（著作権表示／許可）
本特許書類の開示の一部は著作権保護の対象となる資料を含む。著作権所有者は、特許書類または特許開示が特許出願または記録中にある場合何者かによるそのファクシミリ複写に意義はないが、それ以外はいかなる場合にも全ての著作権を留保する。次の表示は以下図面中で説明されるソフトウェアとデータに適用される。著作権(c) １９９８、Ｗｉｌｄ Ｆｉｌｅ，Ｉｎｃ．全ての権利を留保する。
【０００２】
（発明の技術的分野）
本発明は一般にデジタル・データの記憶に関し、特に、デジタル・コンピュータによって保存されたデータのバックアップと回復のための方法と装置に関する。
（発明の背景）
コンピュータ上で実行されるアプリケーションは通常、とりわけハードディスクの情報の保管と再現に責任を負うオペレーティング・システム（ＯＳ）の元で動作する。情報は通常ファイルに編成される。ＯＳは、ファイルと、ファイルの情報が保持されるハードディスク上の関連する位置の間のマッピングの方法を維持する。
【０００３】
現在のコンピュータは一般に、情報（データ）が永久記憶用ディスクから読み出しされそこに書き込みされるような形で動作する。次の２種類の問題に対処するため、通常ディスクの周期的なバックアップ（コピー）がなされる。第１に、ディスク自体が物理的に故障し、そこに含まれていた情報がアクセスできなくなる。第２に、ディスク上の情報が変化し、元の状態が望ましかったと判断される場合、ユーザはバックアップを使用してこの元の状態を回復する。バックアップは同じディスクまたは代替媒体（ディスク、テープ駆動装置等）になされる。
【０００４】
本発明は、１つの例示実施形態では、この第２の状況に焦点を合わせた情報回復のための方法と装置を提供するが、これは物理的なディスクの故障は含まれず、情報が変更されておりその元の状態へのアクセスが望ましい場合である。通常の例には、情報の一部のアップデート中にコンピュータ・システムが「クラッシュ」し、情報が元の状態でも「新しい」状態でもなくなった場合、情報を変更したユーザが後になって初めて元の状態を復元（または単に参照）したいと思った場合、コンピュータ・ウイルスによる情報の変更、またはファイルが不用意に削除された場合がある。
【０００５】
以下は既存のバックアップ方法及びシステムである。
１．テープ・バックアップ
２．光ディスク・バックアップ（ＷＯＲＭ）
３．ＲＡＩＤシステム
４．Ｔｉｌｉｏｓセキュア・ファイリング・システム
５．ファイル・コピー
テープ・バックアップは従来ファイルまたはディスク・セクタ・イメージとして編成されたディスクの内容を磁気テープ上に複製することを含んでいる。このテープは通常取外し可能なので、オフサイトに保存して、ディスク駆動装置の誤動作や、さらには例えば火災による（ディスク駆動装置を含む）サイト全体の破壊に対する回復を提供することができる。
【０００６】
情報がセクタ・レベル・ディスク・イメージの形態でディスクからテープにコピーされる（すなわち、情報がディスク上と同じ形でテープ上に編成される）場合、復元は同一のディスク駆動装置に対して最も効率的に行われる。この編成の理由は速度である。最初から最後までディスクを順次読むことは、ディスク上を跳び回って一度に各ファイルを１つずつ読むよりはるかに高速である。これは、ファイルはディスクの１つの領域に連続的に保存されていないことが多く、ディスク全体に広がって他のファイルと混ざっていることがあるからである。情報が一度に１ファイルずつテープにコピーされる場合、異なっておりかつすでにデータを含むディスクに１つかそれ以上のファイルを効率的に復元することができる（すなわち、保管されたディスク・イメージを復元する場合、ディスク上の以前のデータは全て上書き（重書き）される）。
【０００７】
テープ・バックアップはある時点でのディスク全体または特定のファイルのバックアップに焦点を合わせている。通常この処理は長い時間がかかるので、まれに（例えば夕方に）行われる。増分（インクレメンタル）バックアップは最終バックアップ以降変更されたデータだけを保管するので、必要なテープの量とバックアップ時間が低減される。しかし、完全なシステム回復には、最初の全システム・バックアップとその後の全ての増分バックアップを読み出して結合し、最終増分バックアップの時点まで復元することが必要である。
【０００８】
テープ・バックアップの主要な欠点は、最新のバックアップを行わないことがあるため、バックアップ後に生成された情報または作業が失われることがあるということである。本発明は、連続動作するディスク・バックアップ・システムを提供し、変化するディスク情報状態を保管する新しい状態を利用することで、この問題に対処する。テープ駆動装置はディスク駆動装置の基本的なランダム読み出し及び書き込み能力を共有しているので、この方法はテープ駆動装置でも実現できる。しかし、テープ駆動装置はディスクとして使用する場合一般にあまり有効でない、すなわち、ランダム・アクセス時間が非常に低速であるため、同じ理由からこれは現実的ではない。
【０００９】
ＷＯＲＭ駆動装置によって行われる追記型光ディスク・バックアップは、テープ・バックアップと同じ多くの特性を有する。しかし、関連する技術のため、データを上書きすることはできない。従ってそれは変更できないバックアップのためにある程度の法律的な「アカウンティング」システムを提供する。ＷＯＲＭ駆動装置は、最終的には一杯になってしまうため変化するディスク情報の連続的なバックアップを提供することはできない。
【００１０】
ＲＡＩＤシステムは、集合的に１つの記憶システムとして動作する駆動装置の集まりであるが、データを失うことなく１つの駆動装置の故障を許容し、互いに独立に動作することができる。ＲＡＩＤに含まれる２つの主要な技術はストライピングとミラーリングである。ストライピングはデータを駆動装置間で分割し、高いデータ・スループットを得る。ミラーリングは全てのデータを１つの駆動装置から他の駆動装置に複製することで、冗長性を提供する。１つの駆動装置が故障しても、他の駆動装置が別のコピーを有しているので、データは失われない。
【００１１】
ＲＡＩＤシステムは物理的駆動装置の故障に対するバックアップという形で速度とデータの冗長性に関連する。これは変更された情報を検索するため後の時点で復帰することに対処しない。従って、ＲＡＩＤは、本発明と共に使用して、物理的なディスク駆動装置の故障や望ましくない変更から回復するための手段を提供するという選択肢以外には、本発明には関連しない。
【００１２】
Ｔｉｌｉｏｓオペレーティング・システムは数年前に本譲受人によって開発された。これはディスクの状態を保護するために提供され、ユーザによるその継続及び修正を可能にした。このオペレーティング・システムは保護されたものと現行の２つの状態を維持した。現行状態が失われるかまたは無効になるクラッシュの場合、ディスクが容易にその保護された状態に復帰し、ログが再生されるように、キーストロークのロギングが行われた。これは、例えばファイルを編集するユーザをシミュレートすることでクラッシュの時点までの全てのディスク情報を回復した。保護されたディスク・イメージは現行のものと共に常に利用可能であったので、情報は先の時点にコピーできた、すなわち、保護バックアップの時点で保管された情報は現行状態にコピーできた。
【００１３】
Ｔｉｌｉｏｓオペレーティング・システムは、全ての作業がディスク上で行われ（例えば、テープへの転送がない）、変化の増分的性質（すなわち、現行状態と保護された状態には通常小さな差しかない）を利用する技術が使用されていたため、より高速なバックアップを行うことができた。それにもかかわらず、ユーザはやはり保護（バックアップ）を行う特定の時間を選択する問題に直面し、キーストロークの再生方法はバックアップ後の状態を再現する場合全面的に信頼できるものではなかった。例えば、キーストロークがフロッピーディスクまたはインターネットからデータをコピーする指令だった場合、それらの対話はどちらも再現するＣＰＵ及びディスクの範囲外である。
【００１４】
通常ファイルの拡張子だけを変更して、新しいファイル名でコピーを作成する（例えば、「ａｂｃ．ｄｏｃ」を「ａｂｃ．ｂａｋ」にコピーする）ことにより簡単にファイルのバックアップを作成することが長い間行われてきた。主ファイル（ａｂｃ．ｄｏｃ）が破損または紛失した場合、バックアップ（ａｂｃ．ｂａｋ）から復元することができる。この処理は選択的なテープ・バックアップを行うのとほぼ同じであり、バックアップを管理する問題（いつ行うか、いつ廃棄するか等）は保持される。
【００１５】
要約すると、ＲＡＩＤシステムだけは物理的な駆動装置の故障の意味でバックアップを取り扱っている。テープ、ＷＯＲＭ、Ｔｉｌｉｏｓ及びファイル・コピーは、変更された（失われた）情報の回復の意味でもバックアップに対処している。
特定のバックアップ要求または時間が存在しない
従来のバックアップ処理は、一定の時間停止してディスクの情報の複製コピーを作成する必要がある。これには、ディスク全体が再現されるか、または特定の情報が再現されるように、ディスク全体を見てコピーを作成する必要がある。この処理には通常テープへの書き込みが含まれる。また、ユーザは、特定の時点から凍結されたコピーを表す複製を作成することで、ファイルの特定の集合をバックアップすることもある。オリジナルの変更は継続されることが想定される。この処理は通常、オリジナルと同じディスク駆動装置上にバックアップ・ファイルを作成することを含む。「ディスク」とは実際には、１つかそれ以上のディスク駆動装置であるかディスク駆動装置と同様に作動する装置（記憶手段）であることに注意されたい。
【００１６】
これらのどちらの場合でも、ユーザはバックアップを作成するという意識的な決定を行わなければならない。第２の場合、テキスト・エディタのような特定のアプリケーションがファイル（情報）の最後の少数のバージョンを保持する。しかし結局は、ファイルが安定した後の長期間に全てを複製することになるため、これはディスク空間の浪費につながる。別言すれば、文書を処理中、ユーザは前のバージョンに戻りたいと思うことは多いが、一度完了して何年もたった後、ユーザが最終状態の前の最後の状態を再訪することに関心を持つことはありそうにない。
【００１７】
本発明の技術は、休止してバックアップを行うことや、短期間情報回復の意味でそのファイルをバックアップするか選択することの必要を除去しようとする。それは、例えば長期間失われていた情報を回復することとは対照的に、ある程度最近知られた情報を回復する。
ディスクのディレクトリのバックアップは重要である
情報の回復が非常に重要なもう１つの状況は、ファイルがどのディスクのどこに存在しているかを特定するディスク用のディレクトリ・システムが破損した場合である。これは例えば、ディレクトリのアップデート（更新）中のシステム・クラッシュや、オペレーティング・システムまたは他のユーティリティ中のバグによって発生する。どちらの場合でも、ディスク内容のディレクトリを失うことは、たとえ参照されるファイルがディスク上に存在しても、それらを失う結果となる。この場合、ユーザが復元したいと思う情報はディスクのディレクトリである。
【００１８】
ユーザがバックアップに戻りたいと思う理由の最後の例は、例えば、動作しない新しいソフトウェアまたはデバイスドライバのインストールによりオペレーティング・システム（コンピュータを実行するために不可欠な実行可能またはデータ・ファイル）が破損した場合である。
明らかに、コンピュータのディスク上で操作された情報の意味でユーザが前の時点に戻りたいと思う理由は多い。従来のバックアップはバックアップの時点への回復を提供した。しかし、こうしたシステム全体にわたるバックアップは、ディスクを走査しその内容を複製するために必要な時間の量により頻度が制限されている。別言すれば、ディスク全体のバックアップは大きな動作休止と莫大な量の記憶装置を必要とするため、それを数分毎に行うことは実行可能ではない。時間的進行に連れてファイルの履歴（ヒストリー）コピーを保持することは、ディスクのオーバーフローを回避するためユーザは結局アーカイブを管理しコピーを消去しなければならなくなるという欠点を有している。明らかに、ファイルが変更される度毎に全てのファイルのバックアップをディスク上に保持することは、無制限のディスクがなければできないが、それは存在していない。
【００１９】
廃棄されたデータをある程度連続的に保存する１つのアプローチは、Ｌｏｎｇ他に対する「アーカイブ・ロールバック能力を有する故障耐性コンピュータ」と題された米国特許第５，３２５，５７９号（「’５７９号特許」）で開示されている。’５７９号特許は、記憶装置の対応する位置にあるデータを変更するアクセス要求を検出し、その要求を実行する前に、その位置にあるデータを記憶装置の監査パーティション領域に保存する処理回路を含む記憶装置を開示する。’５７９号特許の装置は監査パーティション領域に保存されたデータを装置の前の位置に順次復元し、それによって記憶装置を以前の状態に戻すことができる。しかし、’５７９号特許の装置とアプローチは、本質的に記憶装置へのデータの書き込みに遅延をもたらす。場合によっては、この遅延のためにこの技術の使用が実行不可能になることがある。従って、コンピュータ・システムのヒストリー情報を保存するより高速、柔軟かつ動的な方法に対する必要はやはり存在している。
【００２０】
（発明の概要）
本発明は、コンピュータ・システムにおいてディスクに基づく情報回復のための方法及び装置である。これは１つかそれ以上のハードディスク（または同等物）を利用する全ての種類のコンピュータ・システムに適用されるが、ここでディスクとは不揮発性記憶システム（単数または複数）を表す。この種類のコンピュータはパーソナル・コンピュータ、ネットワーク・サーバ、ファイル・サーバまたはメインフレームであるが、それらには制限されない。本発明は、最近の元の状態の情報を変更されたディスクに保存するため、ハードディスク上のさもなければ使用されていないページか、または専用のページを循環的に使用することを規定する。この余分のページ（エキストラページ、ｅｘｔｒａ ｐａｇｅ）を集合的にヒストリーバッファと呼ぶ。このヒストリーページはＯＳのデータと混合されるので、本発明はＯＳと実際のハードディスクの間のディスク位置の再マッピングに依存する。ヒストリーバッファに保存された情報を使用して、別のマッピングがなされ、それを通じて、ヒストリーバッファが情報を含んでいる限り過去のどの時点についても、（余分のページを除く）ディスク全体の状態が復元される。保存される情報とはディスク・セクタ、ファイルまたはファイルの一部である。
【００２１】
別の実施形態では、本発明は、データ記憶装置を操作するために必要なコンピュータ上のリソースを保護する方法と対応する装置を提供するが、その際コンピュータはプログラム・コードを実行するプロセッサを有する。本方法は、プロセッサによって実行されるコードが信用されたコードであってリソースの変更を許可されているかを検査するゲートをプログラム・コードの実行が通過しない限り、プロセッサによるリソースの変更を禁止する。信用されたコードは、プロセッサが信用されていないコードの実行に戻る前に、リソースの保護を再び可能にする。
【００２２】
また別の実施形態では、本発明は、ある期間内の様々な時点のディスクのイメージを再現するのに十分な、ある期間にわたるディスク上の変更されたデータの元の状態を記録するステップと、様々な時点で媒体を使用してディスクのオペレーティング・システム（ＯＳ）管理下の状態を再現できるように、記録されたデータをディスクの現在のＯＳ管理下のイメージと共に別の２次記憶媒体に書き込むステップとを含む、方法と対応する装置を提供する。
【００２３】
（発明の詳細な説明）
本発明は、 ディスクを時間的に限界まで以前の状態に戻す方法を提供する。いつの時点にでも（現在の限界の範囲内で）戻れるようにすることにより、 ユーザーは、 バックアップを行うポイントを特に呼び出したり、 どの情報をバックアップするか決定することから免れる。どの程度さかのぼって情報を検索できるかについては時間的に限界があるので、このテクノロジーは短期情報回復に重点を置いている。
【００２４】
ほとんどの情報回復はかなり最近の時点についてであることが一般的に認められている。したがって、 バックアップのために必要な記憶域をファイルでではなく時間で管理すると有利である。本発明のテクノロジーを使えば、 情報は妥当な期間保存され、 その後自動的に廃棄される。バックアップ情報に含まれるものは、 ディスクにとってアクティビティのほぼすべてである。したがって、 ユーザーは、 限界までどの時点のディスク状態にでも戻ることができる。この限界は、 使用可能なバックアップ記憶域および情報が書き込まれる速度（ユーザー・アクティビティ）によって決まる。
【００２５】
今日のテクノロジーにおいて、パソコンは４ギガバイトのディスク・スペースをゆうに持つことができる。本発明のシステムが使用するヒストリー・バッファに１０％を割り当てると、 この例においては４００メガバイトの記憶域を持つことになる。毎年この数字が二倍になることを期待しても不当ではない。ほどほどに頻繁にPCを使用するユーザーは１日に約１００メガバイトの記憶に変更を加える。したがって、 ユーザー・ディスクの１０％を使用するだけで４日間の情報回復が可能である。これは、単に毎日の終了時に４回バックアップができるのではなく、 この４日間の枠のどの時点にでも回復できるようにすることに留意しなければならない。
【００２６】
本発明は、 ディスク・セクタ・レベルであるいはファイル・レベルで（またはファイルの部分レベルで）データを管理するようにインプリメントできる。各々の利点および不利点について以下に論じる。
オペレーティング・システムより下位で（プレディスク・コントローラとして）本発明のディスク・セクタ態様をインプリメントすることにより、 本発明はオペレーティング・システムと非干渉化される。本発明のこの実施態様は、 ディスクをそれ以前の状態に逆戻りさせることができるので、 そうでなければ１つの不適切なディスク書き込みにより悲惨な情報損失を生じるようなオペレーティング・システムのバグから回復することができる。オペレーティング・システムおよびそのファイリング・システムと緊密に結合しているバックアップ技法の場合、自身でバグから回復する能力をこれほど持たない。ただし、 本発明は、 オペレーティング・システムの一部としてインプリメントすることもできる。
【００２７】
本発明のテクノロジーには下記の３つの基本的コンポーネントがある：
１）セーブ・プロセス：ディスク・ベースの情報に加えられるディスク（またはその他の恒久的）変更以前の原状態の保存。
２）回復プロセス：一方では、時間逆戻り（時間回復）ディスクをシミュレートしながら、 同時にユーザーが現在のディスクを引き続き使用できるようにする（したがって、 たとえば過去から現在まで情報を前向きにコピーできるようにする）能力。他方で、 ディスクを時間的に以前の状態に完全に逆戻りさせる能力。
【００２８】
３）管理プロセス：ファイルの使用可能バージョンの決定、 ウィルス・アクティビティの探索およびその他の有益なヒストリー割り込み可能オペレーションのためにセーブされた情報に作用するユーティリティの提供。
様々な一般的マッピング技法により、「ディスク」は実際には物理的ディスク・ドライブの一部であったり、１つのディスク・ドライブであったり、 複数のディスク・ドライブまたはデバイスとすることができ、その記憶域は、 オペレーティング・システムにより他の記憶手段から独立した記憶手段として識別され、 使用される。たとえば、 PCが、ドライブＡとしてフロッピー・ディスク、１つのパーティションＣを持つハード・ディスク、２つのパーティションＤおよびＥを持つ別のハード・ディスク、およびドライブF としてセットアップされるRAIDディスク・アレイを持つとする。ここでPCのオペレーティング・システムのユーザーとして６つの独立した「ディスク」ドライブ、すなわちＡ、Ｂ、Ｃ、Ｄ、ＥおよびＦがある。本文書において説明されるプロセスは、 物理的にマッピングされるのがハードディスクの一部か、 ハードディスク全体かあるいは複数のハードディスク・ドライブまたはその他の記憶手段であるかに関係なく、 これらの独立して識別されるディスク・ドライブに個別に応用される。
【００２９】
書き込み
ヒストリー・バッファは、 変更される以前のセクタの原状態をディスクに記録することによって機能する。変更時点は不可欠ではないが、場合によっては変更が加えられた時ではなくその順序を知るために必要なので、 変更時点も記録される。このプロセスについては図１に図解されている。つまり、あるセクタ10が値A を含み、 値B を書き込むよう要求がある場合、 本発明の方法は書き込みをインターセプトし、 セクタ・ロケーション10を読み取り（Ａ値をピックアップし）、このオリジナルの値を循環ヒストリー・バッファに書き込んだ後、 復帰して新しいB 値の書き込みを完了する。すでに述べたように、 ヒストリー・バッファがいっぱいになって古い状態が廃棄されるほど多くの情報がユーザーの書き込みアクティビティによって転送されるには数日かかるだろう。実際には、 セクタ書き込みシーケンスのキューに入り、 すべてを一度にヒストリー・バッファに移した後、 すべての書き込みを完了するほうが最適かも知れない。
【００３０】
変更前のオリジナルの情報をセーブするプロセスは、データ書き込みに必要な時間に大きな影響を及ぼす。この場合書き込みごとに、１回の読み取りと２回の書き込みが伴う。ただし、Windows95 などのオペレーティング・システムの場合、 アプリケーションはデータの書き込み後実際にデータがディスクに書き込まれるまで実行を継続できる。書き込みは、バックグラウンド・タスクとしてセーブされ、 実行される。この場合、 実際の書き込みプロセスの減速はユーザーには分からない。
【００３１】
このテクノロジーは読み取り性能には影響を及ぼさず、希望のすべての読み取りが完了するまでアプリケーションは実行しつづけることができないので、 ユーザーはこれを意識する。
原状態セーブのその他の方法
情報が変化するとき原状態をセーブするための別の方法は、 書き込みを代替ロケーションにリダイレクトする方法である。このリダイレクトについてはマップにおいて注釈がつけられる。たとえば、 ディスク・ロケーションＸの古いデータが新しい現在状態でオーバーライトされるとする。ディスク・ロケーションＸに予想される現在データは実際にはY に記憶される。Ｘにあるオリジナルの「古い」データはこのロケーションに残される。のちに、「現在」データがオリジナル・ロケーションＸで読み取られると、 システムは、マップを調べることによってそのデータが実際にはＹに記憶されていることを知り、 読み取りをリダイレクトする。最終的にはＸにある古いデータが古くなりすぎて変更をマッピングするために新しいロケーションが必要になると、ロケーションが再循環される。
【００３２】
この方法に伴う問題は、読み取りおよび書き込み両方のディスク転送のためにマッピングが必要となることである。これは、 重要な読み取りアクセス中のオーバーヘッドを増大し、処理の増加がユーザーにとって明らかである。さらに、実際にデータを動かす代わりに単に書き込みをリダイレクトするのは最適に見えるかも知れないが、 リダイレクトにはマップの更新が伴う。このマップは予期せぬクラッシュから回復するために常にディスクに保存されなければならず、 マップの更新にはおそらく読み取りおよび書き込みアクセスが伴うので、 この方法における全体的オーバーヘッドは、 単にデータを動かす場合（書き込み２回、 読み取り１回）と同様かも知れない。
【００３３】
書き込みのりダイレクトの別のバリエーションは、この機能をオペレーティング・システムに組み込む方法である。オペレーティング・システムはすでに各種のマップを保存しているので、新しいデータを代替ロケーションに書き込みながら同時にどこが古いデータのロケーションであるかを覚えているのに適任であろう。オペレーティング・システムの一部としてマッピングする場合、 不利点が２つある。
【００３４】
まず、予期せぬクラッシュが生じた場合、 マップが完全に書き出されておらず、ディスクが非常に混乱した状態で残される可能性がある。
Tiliosオペレーティング・システムは、 ディスクの現在の状態および保護された状態を保存した。保護状態は、 特定の時に凍結されたバックアップの形態である。現在状態は、 差で定義される（最新の変更とオリジナル・データの組み合わせ）。クラッシュが生じると、 システムは保護状態に逆戻りする。ディスクに記憶される現在バージョンのほとんどは、 実際にはディスクに書き出されていないかも知れないので−変更はRAM で行われて、クラッシュ時にはキャッシュからフラッシュ（書き込み）されていないので、これを当てにすることはできなかった。
【００３５】
Tiliosの問題点は、 保護のプロセスのために、 ユーザーがシステムを停止して、「現在バージョンを保護状態にコピーする」ようシステムに要求しなければならなかった点である。保護された状態との差で現在バージョンを表すインプリメンテーション技法は、 記憶域を最小限に抑え、 保護プロセスをスピード・アップした。それでもまだ、ユーザーはこのバックアップを「要求」し、クラッシュの結果現在バージョンを失う危険を負わなければならなかった。さらに、この方法は、 タイム・ベースではなくファイル・ベースだったので、 長い間変更されていないデータの場合古いバージョンが保存されることになった。この点が情報回復を最近のバージョンに集中させる上記の特徴と異なる。
【００３６】
オペレーティング・システムに原状態のセーブを組み込むことが望ましくない第二の理由は、 複雑さとバグである。オペレーティング・システムのファイリング・システムと古い状態マッピングが絡み合うことによりバグが生じて、 すべてをだめにしてしまう可能性がある。ただし、 オリジナルの古いディスク状態の管理をオペレーティング・システムから隔離することによって、この相対的に単純な管理システムはオペレーティング・システムのファイリング・システムのバグから回復できる。
【００３７】
オーバーライトされる前に古いデータをヒストリー・バッファに実際に動かすことの最後のしかし重要な利点は、 ユーザーが、本発明のソフトウェアを所定の場に持たなくても現在状態を使用できることである。つまり、ディスクおよびその内容はオペレーティング・システムによって直接使用でき、 オペレーティング・システムは単にヒストリー・バッファを無視するだけである。もちろん、 本発明のソフトウェアを所定の場に持たずにオペレーティング・システムが加える変更は、 ヒストリー・バッファを無効にするだろう。しかし、これはオペレーティング・システム更新などの移行を容易にする（この場合、 本発明をすぐにインストールするのは可能でないかも知れない）。また、総称的な「フロッピー」ディスクから立ち上げて、 主ドライブにアクセスする選択肢を与える（本発明は総称的なオペレーティング・システム立ち上げディスクに収められないので）。
【００３８】
いずれにしても、 どの程度古い状態が保存されるかに関係なく、 古いディスク・データがオーバーライトされる前にこれを実際に動かすか、 書き込みをリダイレクトしてマッピング・システムを保存するか、 あるいは機能をオペレーティング・システムに移すことによって、本発明の基本的概念は、 短期的自動情報回復保護を与える。
【００３９】
ヒストリー・バッファに保存されるその他の情報
ヒストリー・バッファに変更時点といっしょにオリジナル・データを記憶するほかに、どのタスクが書き込みを要求したかについて注釈を加えることができる。これによって監査証跡が与えられるので、ヒストリー・バッファを調べることにより、だめになった情報を突き止め適切な情報を復元するだけでなく、 損害の原因となったタスク（たとえば、 ウィルス）を判定できる。
【００４０】
ヒストリー・バッファに記憶できるその他の情報は、 いつシステムが立ち上げられたかに関する情報である。これは、通常、 必要な場合の適切な逆戻りポイントを示す。また、オペレーティング・システムのキャッシュ状態を監視することにより、 オペレーティング・システムがすべての情報をディスクにフラッシュしたと感じた時点について注釈を加えることができる。これも優れた逆戻りポイントを示す。
【００４１】
キーストロークおよびその他のユーザーの対話も、 ヒストリー・バッファにログすることができる。この種の情報は、 ユーザーが所定の時点に何をしていたかを特定するのに役立つ。たとえば、 ユーザーが逆戻り時点を確定するときにタイム・セレクタを前後に動かすと、 システムは、 その時点でセーブされるキーストロークおよびその他のユーザー対話情報に基づきその時点の前後のユーザーの対話の要約を示すことができる。ユーザーが時間的に振り返るとき提示可能なその他の情報の例は、 そのときアクセスしていたファイルの名前である。問題の逆戻り時点を特定するために特定のファイル名またはキーストロークのパターンを探して検索を行うことができる。別の例は、 スクリーン・ショットである。コンピュータは、ユーザーの画面のスナップショットを周期的にたとえば5 分ごとにとって、これをヒストリー・バッファにセーブできる。
【００４２】
情報回復プロセス
その３の２
図２に示されるとおり、 本発明は、２つの基本的な回復形式を提供する。第一のケースでは、 ユーザーがドライブＣで実行中と仮定して、 時間的に振り返りたいとする。本発明のテクノロジーは、 システムが、実ディスク・ドライブではなくシミュレートされたドライブつまり仮想ドライブである別のドライブＤをサポートできると仮定する。ドライブＤの画像はオリジナルのドライブＣとヒストリー・バッファ（通常はドライブＣの一部）上の情報を組み合わせることによって作成される。時間的に振り返るプロセスには、ドライブＤについて基準時を設定して、 ドライブＤが指定時点にドライブＣからコピーされた内容をもつ別の物理的ディスク・ドライブであるかのようにドライブＤにアクセスすることが含まれる。
【００４３】
実際には、 これは、テキスト・エディタにおいてドライブＤの時間を11：30に設定しながら、 希望の「古い」ファイルを開いて、 もっと前のバージョンが欲しいと判断して、 時間を11：15に調整しなおして、 もう一度試してみることができることを意味する。現時点でファイルが削除されているかあるいはそのディレクトリが削除されているかは問題ではない。なぜなら、ドライブＤについて時間を設定することによって、時間を戻ってドライブＣについて参照するからである。
【００４４】
そのバックアップ時点を入力できる新しいドライブをシミュレートするこの方法は、 特定の時点（バックアップが要求されたとき）にしか使用できない実コピー（テープなど）を扱うよりずっと柔軟性がある。
回復の第二の形式は、 主ドライブＣを前の状態に逆戻りさせるものである。この状況では、 模擬ドライブＤから古い情報を現在に動かすのではなく、 主ドライブが完全に時間的に戻されるだけである。この回復方法は、 特に、 現在状態が使えなくなったり（ファイルを立ち上げまたはアクセスできない）望ましくなくなった（新しいソフトウェアまたはハードウェア・ドライバのインストールが期待通りに機能しない）場合に有益である。このインプリメンテーションは、 該当のセーブされたオリジナル・データを所定の場にコピーし直し、 逆戻りを反映するようヒストリー・バッファを更新し、 システムを再スタートするだけという単純さである。
【００４５】
主ドライブＣを完全に逆戻りさせるプロセスは、 まず、模擬ドライブＤを使って希望の時点に戻ることによって行うことができる。これにより、ある情報を確認して、 場合によってはこれを修正し、 その後本発明のソフトウェアにドライブＤをＣに「コピー」するよう要求するチャンスがユーザーに与えられる。この完全な逆戻りもヒストリー・バッファにログされるので、 この逆戻りを可逆的にすることに留意しなければならない。言い換えると、 ヒストリー・バッファに充分なスペースがあると仮定して、 ユーザーは、 T1の時点でディスク状態S1を作成し、 その後のT2の時点で新しい状態S2に進み、 その後T3の時点でS3に進んでから、 問題があることに気付くかも知れない。T4の時点のユーザーはディスクを状態S1まで完全に逆戻りさせることができる。この時点で認識すべきことは、 ヒストリー・バッファは逆戻りされずログしつづけていることである。したがって、 ユーザーが実際には状態S1では時間的に戻りすぎであると分かった場合、 T5の時点で状態S2への逆戻りを開始できる。このプロセスは下記のように表される：
時： T1 - ＞ T2 - ＞ T3 - ＞ T4 - ＞ T5 - ＞ T6
ディスク： S1 S2 S3 S1 S2 ？
興味深いことに、 この場合も充分な大きさのヒストリー・バッファがあると仮定して、 ユーザーは、 T6の時点でT5の時点からS2に逆戻りし、 さらにT4の時点からS1に、また実際にはT4またはT5より後の状態であるT3の時点からS3に逆戻りできる。言い換えると、 ディスク状態S1およびS2は、時間の経過の中で２回発生する。
【００４６】
本発明は、 ディスク・ドライブが物理的に故障している場合に回復するためのものではない。ただし、 ユーザーがドライブＣではなく模擬ドライブＤをバックアップできるようにすることによって、標準のフル・ドライブ・バックアップ（テープなどに）の使用を可能にする。これは、ユーザーがその仕事において、システムを戻したい時点に戻り、 ドライブＤの時間を現在に設定し（このようにして凍結し）、Ｄをベースとするバックアップを開始し、 その後バックアップが完了するのを待つことなく仕事を続けることができることを意味する。これはバックアップの完了を待つ時間を大幅に節約するだろう。
【００４７】
米国特許第5,553,160 号Bemis 特許は、 バックアップ中ディスクへの書き込み要求がトラップされるという関連方法について説明している。書き込み中のディスク・ロケーションがまだバックアップされていない場合、 バックアップを続けることができるように、オリジナルの内容は代わりの一時的記憶装置にコピーされる。最終的には、 この一時的記憶もバックアップにコピーされる。本発明はこの限定された状況で同じ結果−つまり、 特定の凍結時点のディスクまたはディスクのシステムのバックアップ−を生じるが、他のアプリケーションと違ってバックアップが行われていることを特に認識することはない。したがって、 Bemis と違って、バックアップのフォーマット（余分な原状態情報が最後に付加されない）またはバックアップおよび復元アルゴリズムに影響はない。さらに、本発明とBemis は、プロセスに違いがある。本発明は、 特定の時点に凍結され逆戻りされるディスクのシミュレーションに関するものであるのに対して、 Bemis は特定のバックアップ中のディスク情報の流れに重点を置いている。
【００４８】
本発明の方法は、 ヒストリー・バッファのサイズによって限定される比較的少量のディスク・スペースがディスク使用中に行われる可能性のあるすべてのバックアップを効果的に表すことができるようにすることにより、実コピーがしばしば行われる方法とは異なる。ヒストリー・バッファの中の差だけを追跡することにより、 バックアップを作成するために転送される情報量は、 情報が変更されるごとにシステム全体をバックアップするのに比べて減少する。
【００４９】
たとえばテープ・ドライブにインクリメント式にバックアップするためのソフトウェアが存在する。テープを調べるとき、アクセスしたいファイルのどのバージョンか指定することができる。ただし、本発明のテクノロジーは、 ログされるのがセクタかあるいはファイル転送かに関係なく、 特定のバックアップ・ステップを排除する。また、このプロセスは、 循環バッファを想定しているので、 テープの「フィル・アップ」および（または）1 セットのテープ（各バックアップを別個のテープに行うと仮定して）の管理の問題はない。インクリメント式バックアップは、 通常、 ある基準点からスタートし、 最後のバックカップ以降変更されたファイルのみログし直すように設計される。全システム回復のためには、基準点に戻り、 この時点からすべての増分変化をマージしなければならない。一方、 本発明は、 現在の「不良」状態から始まり、 増分変化のヒストリーをさかのぼる。本発明を特徴付ける品質のひとつは、循環ヒストリー・バッファに増分変化を保存することである。スタート・ポイントを持たないインクリメント式バックアップを提案することは、 伝統的には特に貴重とは見なされないだろう。アプローチの差は、 主ドライブが使用可能か否かの仮定および特定の時点からの回復の保証に見いだすことができる。
【００５０】
伝統的なテープ・バックアップ法は物理的なドライブ故障から回復して、 特定の時点から情報が利用できることを保証するので、 本発明は、 従来のテープ・バックアップ法に代わるものとして設計されたのではないことに留意する必要がある。このようなバックアップは、 それが提供するものについて完全に保証されている。一方、 本発明は、 ヒストリー・バッファのサイズが許容する限り時間的に戻れるだけである。時間量は、 ユーザーの書き込みアクティビティによって決まる。ディスクに大量に書き込めば、 原状態を利用するために時間的に戻れる距離は小さくなる。ただし、 妥当な大きさのヒストリー・バッファと平均的使用量の場合、 予想される期間内の希望のバックアップ状態を利用できるチャンスが充分あるだろう。
【００５１】
本発明を予想可能にするために、 システムは、 データが循環ヒストリー・バッファに書き込まれる（またこれから廃棄される）平均速度を監視する。使用量が急激に増加したり、 ユーザーが指定するルック・バック（振り返り）時間最小値に近づきつつある場合、ユーザーに警報が発せられる。ルック・バック時間とは、 本発明のシステムおよび方法がバックアップを作成し直す際に現時点から時間的に戻れる時間量である。
【００５２】
本発明のセクタ（vs. ファイル）ベースのインプリメンテーションにおいて基礎となる仮定は、 ディスクは安定状態に置かれることが多いので、 逆戻りして情報を回復できる時点があるということである。ほとんどのオペレーティング・システムは、いくつもの理由でシステムがクラッシュするかも知れないと仮定しなければならない。理由の中でもごくたわいもないのは、 適切にシャットダウンせずにユーザーが偶発的に電源をオフしてしまうものである。そのため、 オペレーティング・システムは周期的にRAM およびキャッシュから重要な情報を実ディスクにフラッシュするものと仮定される。また、オペレーティング・システムはディスクのディレクトリおよび連想テーブル（ここからファイリング・システムが実行される）を更新する際はある程度の注意を払うものと仮定される。
【００５３】
以上の仮定から、本発明のセクタ・ベースのインプリメンテーションに基づく情報回復機能は、 オペレーティング・システムがディスクにすべてをフラッシュしそうな期間を突き止めるために、ヒストリー・バッファの中にセーブされるすべてのオリジナル・データと対応付けられるタイム・スタンプを利用する。この時点はディスク・アクティビティに時間的に充分に大きなギャップがあることで識別される。回復インターフェイスは、 通常、たとえばグラフィック・プログラムがグリッド・ポイントまで動くのと同じように、回復タイム・スライダが動かされるとき自動的に上記の「セイフ」ポイントまで素早く動く。図３は、スライディング・バーを使用するタイム選択インターフェイスを図解している。図３左の一番黒っぽい部分矢印20は、逆戻りが可能であるが、 ディスク（ヒストリー・バッファ）スペースが使えなくなると消えるかも知れない時点を示している。適切な逆戻り時点としてディスク・アクティビティの大きな時間的ギャップを突き止めるほかに、オペレーティング・システムにより固有の注釈を生成することができる。ヒストリー・バッファにログされる上記の注釈はそのキャッシュのフラッシュに対応するので、 適切なディスク状態（たとえばシステムがクラッシュして再スタートするような場合に使用できる状態）を示す。図３は矢印22で表されるスライダを含むユーザー・インターフェイスを示している。
【００５４】
ディスクの以前の状態に逆戻りするとき、 本発明のソフトウェアは逆戻り画像のディレクトリ構造をスキャンして、 これを有効になるように調整できることに留意しなければならない。たとえば、 Windows3. ｘおよび95オペレーティング・システムの一部として提供される標準ScanDiskソフトウェアもこの機能を提供する。この調整は逆戻りバージョンを改変することになる。変更は一時領域に保管され、 ユーザーが逆戻りを終了するとともに廃棄される。一般的には逆戻り模擬ディスクＤは読み取り専用と思われるかも知れないが、 最初は時間的に振り返るビューなので、 完全に変更可能である。ただし、 長時間変更を保存しようとすると、 循環ヒストリー・バッファに関してあらゆる種類の問題を引き起こし、 本質的に時間的分岐を生じる（すなわち、時間的に戻って現在の状態を暗示するものに変更を加える場合）。したがって、 模擬ディスクＤに加えられる変更は、 常に一時的逆戻りの一部と見なされる。主ディスクＣを完全に逆戻りする場合、 Ｄへの変更は、 逆戻りに基づくＣの新たな望ましい状態の確定および試験の一部である。Ｄのこの新たな状態が、 最終的に主ディスクＣに「コピー」される。
【００５５】
ライトワンス光ディスク（WORM）は本発明のテクノロジーといくつか類似点を持っている。WORMドライブにおいては情報をオーバーライトできないので、 様々な時点でWORMを見る手段を提供できる。ただし、 WORMドライブは無制限に使用することはできず本文書において列挙される本発明の目的のため使用されないので、 このテクノロジーは、循環ヒストリー・バッファに関係するものではない。
【００５６】
本発明のハードウェア・インプリメンテーション
本発明は、 主CPU に( ソフトウェア・ソリューション) インプリメントするか、本質的にディスク・コントローラの一部として（ハードウェア・ソリューション）インプリメントして、オペレーティング・システムから本当の意味で隔離できる。たとえば、 本発明が埋め込まれたディスクを（ディスク・コントローラを含めて）購入したとする。コンピュータにインストールするとき、 ディスクは２つのディスク、 ドライブＣおよびＤとして現れる。ディスクＣは、1000メガバイトの記憶域を持つと知らせるかも知れない。しかし、 ディスクはヒストリー・バッファのために余分に560 メガバイトを確保しているので、 実際には1560メガバイトの記憶域を持つ。
【００５７】
ドライブＤに関する最大逆戻り時間および現在逆戻りを示すディスクに対する小さい独立インターフェイスが提供される。物理的には、 このインターフェイスはほぼ時計サイズで２つの時/ 日ディスプレイおよびその他のインディケータおよびセレクタを持つ。現在逆戻り時点の調節は、 ディスクがその模擬ドライブＤをいかに示すべきかをディスクに知らせる。この種のハードウェア・ソリューションは、 本当の意味で透過的なので（ドライブＤが通常のディスク・ドライブではないことが分からない）オペレーティング・システムと調和して機能する。
【００５８】
ハードウェア・ソリューションに伴うその他の形態は、さらにオペレーティング・システムに対するインターフェイスを区分するかも知れない（すなわち、小さい独立インターフェイスを使用する代わりに、 オペレーティング・システムを通じてドライブＤの逆戻り制御が行われる）。この状況においては、ディスクを動的にマッピングしなおして、実際にデータを動かすことなく原状態をセーブするために代替ロケーション（浮動ヒストリー・バッファ）に変更を向かわせるほうが、 望ましいかも知れない。
【００５９】
模擬ドライブＤに関する逆戻り時点の設定の様々な方法について論じたが、 オペレーティング・システムに通常の方法でディスクから立ち上げるよう要求することなく主ディスクＣを逆戻りするための手段をユーザーに提供すると、 有益である。これは、クラッシュが生じてユーザーがコンピュータを適切に立ち上げられなくなって、オペレーティング・システムを実行し始める状況において、非常に有益である。この場合、 この状況を検出し、 ユーザーが主ディスクＣを逆戻りできるようにするための手段を与えて、 システムが適切にオペレーティング・システムを立ち上げられるようにすることができる。このような手段は、 時間的に（ディスクにとって最後の安定時点に）主ディスクを逆戻りさせることができるRESET スウィッチと同様のスウィッチの形態をとることができる。その代わりに、 ユーザーの要求に応えて逆戻りを行えるようにする追加のソフトウェアを、 オペレーティング・システム立ち上げプロセスに追加することができる。この手段はCMOS(PC 設定) の編集に切り替えるために立ち上げ中にF2を押す一般的方法に似ている。1 回要求すれば、 特にディスクに置かれる本発明に基づく逆戻りを行うための立ち上げコードによりまたは他の代替の不揮発性記憶装置（ROM またはFLASH ）を立ち上げることにより、このプレオペレ−ティング・システム立ち上げ逆戻りを実行することができる。もちろん、「回復」フロッピー・ディスクから簡単に立ち上げることもできるので、特別なハードウェアまたはオペレーティング・システムの立ち上げプロセス変更は必要ない。
【００６０】
本発明のソフトウェア専用インプリメンテーションは、 そのマッピング（ヒストリー）情報をディスクに記憶しなければならない。しかし、ハードウェア・インプリメンテーションにおいては、ディスク・ドライブ（コントローラ）のバッテリ・バックアップのRAM またはFLASH にマッピング・テーブルを保存することができる。ここで、ディスク・アクセスなしでテーブルを素早く修正することができ、しかも主CPU がクラッシュした場合マッピング情報が失われることがない。マッピング情報はディスク・ドライブの一部なので、 オペレティング・システムが期待するとおりの構成に実際にディスクを維持することに関して問題はない。ハードウェア・インプリメンテーションがどのように機能するかについて詳しくは、 本文書の情報回復プロセスの項を参照のこと。
【００６１】
読み取り
ディスクが時間的に完全に逆戻りされる場合、 関連アルゴリズムはかなり簡単になり得る。すなわちヒストリー・バッファを通って、 希望の時点に達するまで原状態を戻す。このコピー中書き込みがトラップされて、古い状態が記録されるのでこの逆戻りが事実上可逆的であることに留意しなければならない。
【００６２】
模擬ドライブの他のケースはもっと複雑である。模擬ディスク（Ｄとして参照される）について逆戻り時点が選択されるとき、情報が主ディスク（Ｃとして参照される）に引き続き書き込まれるかも知れない。模擬ディスクＤはＣをベースにしており、 Ｃは継続される書き込みアクティビティによって変化するかも知れないので、 シミュレーションは、Ｃで変化するディスクＤ情報を継続的に明らかにしなければならない。
【００６３】
本発明のテクノロジーをこれほど効果的にしているのは、ドライブＤを使って以前の状態を振り返りながら同時に主ディスクＣを継続的に使用できるようにするこのプロセスである。基本的に、これによって、ユーザーは、 以前の時点から現在時点に古い情報を前向きにコピーできる。
本発明のセクタ・インプリメンテーションの要点として、 模擬ドライブＤがすべての読み取りおよび書き込みディスク転送をトラップすることによって「作成」される点がある。読み取りアクセスの場合、 望みのディスク・セクタの真のロケーションを示すマップを調べる。このマップは、 逆戻り時点が選択されるときに最初に構成される。通常、 マップは、いくつかの連続セクタについて実際のロケーションに対するオリジナル・ロケーションをマッピングするツリーまたはテーブルの形態をとる。マップにエントリがない場合、 オリジナル・ロケーションがまだ有効である（マッピングが必要ない）と想定することができる。しかし、 ドライブＣへの書き込みは、ドライブＤを通じてアクセスできる「凍結」データの移動を生じる可能性があるので、 マップは継続的に保存されなければならない。本発明のファイル・インプリメンテーションは、 上位（たとえば、 オープンおよびクローズ）要求のトラップを含む。
【００６４】
ヒストリー・バッファのスペースは少量しかないので、ドライブＣへの大量の書き込みアクティビティがヒストリー・バッファの古いデータを侵食しつづける（その結果記憶域が最近変更された原状態を保存するためにリサイクルされて、古いデータが廃棄される）可能性がある。ドライブＤについて逆戻り時点を選択する際、 システムは、 使用可能な「フリー」ヒストリー・スペースの量を報告できる。これは、現在の逆戻り時点より古いデータを含む循環ヒストリー・バッファの記憶域の量である。ドライブＤに新しい書き込みが行われると、 このスペースが減少する。スペースが限界になるかまたは限界に近づくと、 ドライブＤからＣ以外のドライブに希望の古いデータをコピーするようユーザーに知らされるので、 Ｄの使用可能性が保証される。
【００６５】
書き込みが継続して、 Ｄを表すために必要なデータが失われる場合、ドライブＤはアクセス不能になる。さらにドライブＤにアクセスしようとするとディスク・エラーを生じる。ドライブＣへの書き込みは、 たとえば、 ユーザー・アクセス（ファイルを時間的に前向きにコピーするなど）により直接またはマップおよびドライブＤのシミュレートに関連するその他のデータを表すためのオーバーヘッドから生じる可能性がある。
【００６６】
ファイル・レベルでの本発明のテクノロジー
本発明は、 セクタ（ディスク）・レベルでインプリメントするか、あるいはファイル・レベルでオペレーティング・システムのファイリング・システムの一部としてインプリメントすることができる。仮想ディスクを通じてあるいは実ディスク上でディスクのセクタを時間的に以前の状態に逆戻りするという概念は、 かなり理解しやすい。たとえば、12 ：19に逆戻りすると、 その時点のその形態のディスク上のデータを見ることができる。
【００６７】
本発明のファイル・レベルのインプリメンテーションにおいては、オペレーティング・システムにしっかりと組み込まれていて、 同様に最近の変更の原状態をセーブするという原則に基づいてはいるが、 情報検索の方法およびユーザーによるその理解はかなり異なるかも知れない。たとえば、 オペレーティング・システムは単に所定のファイルについて以前の状態のリストをユーザーに提示するだけで、何でも前向きコピーできるようにするかも知れない。これはディスクを逆戻りするのとは全く異なる。本発明のファイル・レベルのインプリメンテーションは、 循環システムにおいて変更前にファイルのバックアップ・コピーを自動的に保存する。新しいバックアップ・ファイルが追加され、バックアップ・ファイル専用のディスク記憶域の容量が予め設定された限界に近づくと、 古いほうのバックアップ・ファイルが自動的に廃棄される。当然、 （ファイリング・システムとして知られる）ディスク上に使用可能なフリー・スペースがある場合には、 この限界を無視できる。ヒストリー・バッファについて予め設定されたスペース限界を維持するまでフリー・スペースを回復しなければならない場合、 廃棄が行われる。
【００６８】
ファイル・レベルの本発明は可能ではあるが、 インプリメントして、正確であることを証明し、 サブシステムとして隔離するのが、 難しいかも知れない。この種のインプリメンテーションは、 ファイルが開けられ修正の意図の明らかなときその直前に先行ファイル状態全体をセーブすることができ、 修正されるファイルの部分の以前の状態だけをセーブしようと思えばそうすることができる。後者はセクタ・ベースの方法と似てくるが、 本発明のコンピュータ・システム・テクノロジーにおいて挿入されるレベル−つまり、オペレーティング・システムのファイリング・システムの上位で挿入されるか、ディスクI/O パスのもっと低いレベルで挿入されるか−に違いがある。
【００６９】
ユーザーが逆戻りディスクのディレクトリ構造を見ることが許容される場合、 ファイル・レベルのインプリメンテーションは、 ヒストリー・システムにディレクトリ構造情報も保存しなければならない。たとえば、 ファイルのサブディレクトリ全体がファイリング・システム階層の別のロケーションに動かされる場合がある。ディレクトリおよびマッピング情報が本発明が処理するシステム・ファイルに保存されると仮定される場合には上記のケースが処理される。
【００７０】
ファイル・レベルでの本発明の限定的インプリメンテーションは、 セーブされたバックアップ・ファイル・コピーだけにしかアクセスを許容しようとせず、 逆戻りディスク全体をシミュレートしない。したがって、 ユーザーは、 単に循環ヒストリー・システムの中に何があるかを見て望みのファイルを開いて検索することが許容される。
【００７１】
ヒストリー・バッファ
ドライブＣについて述べるとき、 これは単一のファイリング・システムの下で組織される情報を含むディスクの部分を意味する。ディスクはこの種のファイリング・システムを１つだけ持つことが多いので、 ドライブＣまたはディスクＣが意味するものは同じになり、 交換可能である。ただし、 実ハードディスク・ドライブは、 各々が独自のファイリング・システムおよび組織方法を持つ独立のパーティションに構成することができる。DOS オペレーティング・システムの下では、 本発明のソフトウェアをオペレーティング・システムと非干渉化するために、 ヒストリ・バッファが独自のパーティションに割り当てられ、 本発明のソフトウェア（オペレーティング・システムではなく）だけにより直接管理される。ドライブＣにおいてアクセスできる隠しファイルまたはその他のファイル・タイプとしてヒストリー・バッファを表現しようとすると、 ヒストリー・バッファがオペレーティング・システムと対話する道を開く。たとえば、 オペレーティング・システムはこのファイルを動かすことにするかも知れない。パーティションはDOS オペレーティング・システムの下でハード・ディスクを細分するための定評ある方法である。Windows3.xおよび95オペレーティング・システムは、本質的にDOS の最上位で、 ディスクのそのパーティションにおいて実行されることに留意する必要がある。異なるオペレーティング・システムが異なるパーティションを相互に干渉しあうことなく管理することができる。このようにして、 本発明のソフトウェアは、その専用ヒストリー・バッファ・パーティションにとってのオペレーティング・システムとなる。
【００７２】
本発明のテクノロジーは、 実際には、 循環ヒストリー・バッファがどこに維持されるかあるいはこれが同じスポットに位置すること（動的リマッピング・システムの場合にディスク中を動き回るのに対して）に関するものではないことに留意しなければならない。以上のコメントはDOS およびWindows3.xおよび95オペレーティング・システムの下でこのヒストリー・バッファをインプリメントするための多くの方法のうち１つに関してのものである。他のオペレーティング・システムはヒストリー・バッファを隔離するために異なる技法を必要とするかも知れない。必要なスペースを縮小するためにヒストリー・バッファにデータ圧縮技術を応用できるものと思われる。
【００７３】
ブロック化された循環ヒストリーバッファ
本発明の技術は、ディスクセクタ書込み及び他のアクティビティを循環ヒストリーバッファにログを行う段階を含んでいる。循環ヒストリーバッファは固定サイズバッファであり、書込みが行われてバッファの最後に到達したなら、その最初にラップバック(wrap back) するものである。故に、新たなデータは最も古いものに重ね書きされる。而して復旧プロセスは、最も最近に書込まれたデータから開始し、データが書込まれた古い方に戻る様にスキャンする段階を含んでいる。多くのユーザは、喪失された情報を復旧する為なら喜んで対価を支払うであろうが、それは合理的な時間内に行われねばならない。ヒストリーバッファに対しては数ギガバイトを専用とすることも可能である。一定の時点までの復旧を開始する為に必要なマップを生成するプロセスは、これらの数ギガバイトのデータをスキャンする段階を含み得る。ディスクは高速であり得るが、もし時間的に相当以前であれば数分かかることもある。時間的に近い処を見返すのであれば時間が相当に短くなることは当然である。
【００７４】
ヒストリーバッファの高速のスキャンを可能とすべく、その構造は簡単な循環バッファ( エリア) から改変される。代わりに、上記バッファは複数のブロックに構成され、各ブロックがディスク上のシリンダの内容に最適に対応する。この方式30は図４に示されている。
各ブロック32の前方には、各エントリをマッピングするテーブルがあり、各テーブルエントリは次のものを含んでいる：
1)タイプ；
2)タイムスタンプ；及び
3)原ディスク位置。
【００７５】
上記マッピングヘッダの後で、第２テーブル内には原状態のセクタイメージ( データページ) が保持される。故に書込プロセスは、自身上に重ね書きされようとする古いデータを先ず読み、現在のヒストリーバッファブロックの最後に書込み、対応するマッピングテーブルエントリを更新し、最後に新たなデータを所定位置に書込む、という段階を含んでいる。故に、本来は１回だけ書込まれたものが、１回の読み取りと３回の書込みとなる。マッピングテーブルは常に拡張されることから、それは既にキャッシュ内にロードされていると思われ、故に上記第1 更新の前には一回のみ読み取られる。従って、この読み取りは通常書込毎の平均オーバヘッドには算入されない( すなわち、通常書込の内の僅かな割合が２回の読み取り及び３回の書込みとなる) 。
【００７６】
上記マッピングテーブルにおけるタイプフィールドに依り、原セクタ状態以外のデータをセーブすべく一定のデータページが使用され得る。たとえば各ページは、復旧の間に必要とされるマッピングツリーに対し、又は、逆戻りされたディスクへと書込まれたデータに対して、使用され得る( すなわち、シミュレートされたドライブＤを時間的に逆戻りさせて実際にそれに書込むことが可能であり、但し、これらの変更は逆戻りが終了したときに失われる) 。
【００７７】
上記マッピングエントリにおけるタイムスタンプフィールドは、エントリが再使用される毎に時間的に進行する。対応するデータページが書込まれた時間を識別することに加え、上記フィールドはシステムがスタートしたときに使用される。隣接する各エントリ間のタイムスタンプにおける後方中断を探すことにより、システムは書込みが最後に停止した箇所を決定し得る。
【００７８】
上記マッピングテーブルを各データページから分離することにより、復旧プロセスは、全体復旧システムを構成するときに各ブロック( シリンダ) の前にてマッピングテーブル全体を容易にスキャンし得る。これは、ツリーテーブルを構築するに必要な、又は、マッピングテーブルのみがスキャンされる必要がある場合に任意の他の分析を行う為に必要な時間を相当に減少する( これは、当該データページの大きなサイズの故に読み取りに相当の時間を要するデータページと対照的である) 。
【００７９】
データページに関する情報をマッピングテーブルに分離するとヒストリーバッファのスキャン速度は改善されるが、各エントリが変更されるときのマッピングテーブルの更新に問題を引き起こす。もしシステムがマッピングテーブルの更新の間にクラッシュすると、ディスクへと書込まれつつあるテーブルの部分は無効となる可能性がある。マッピングテーブルが常に有効であることを確かなものとする為に、２つのコピーが書込まれる。クラッシュは最悪でもこれらのコピーの一方のみを破損し得るにすぎない。これは通常の書込プロセスに対して更なるひとつの書込段階を付加するが、２つのマッピングテーブルセクタ及びデータページの書込は、全て同一のエリア( シリンダ) に配置されている。故に、元のセクタ箇所とブロックとの間を行き来するディスクシークと比較して、殆どオーバヘッドは付加されない。
【００８０】
このブロック化体系は本発明によりファイルレベルでも実施され得るものであり、その場合にデータページはディスクセクタの代わりにファイル情報に対応する。他の詳細もまた、プログラミング分野の熟練者に明らかな如く変更される。
時間に基づくディスクアクティビティのグループ化
既に論じた如く、ヒストリーバッファ内のどの箇所が時間的に安定箇所であるかを知ることにより、斯かる箇所にてオペレーティングシステムが好首尾にかつ有効にリスタートされ得ることが重要である。これらの箇所は、たとえば、本発明を実施するソフトウェアもしくはハードウェアに対してオペレーティングシステムが明示的に通知することで該オペレーティングシステムにより定期的に生成され得る。少なくとも可能な限りにおいてオペレーティングシステムは、不測のクラッシュから復旧( リスタート) すべくディスクを合理的に使用可能に保持すべきであることを前提とする代替的手法が呈示された。故に、ディスクのアクティビティが無い長期間は、オペレーティングシステムが全てのデータをディスクへと送り込んだ期間に対応することから、安定な期間を表すものと見做される。
【００８１】
ディスクのアクティビティおよび時間に基づいて安定期間を識別するというこの第２手法は、本発明を実施するソフトウェアとインタフェースする様には設計されていないオペレーティングシステムと協働するという利点を有している。但しこの場合、特に書込みなどの鈍重(heavy) なディスクアクティビティの丁度途中であった時間的箇所への逆戻り(reverting) は用途が限られている、と言うのも、ディスクは明らかに遷移期間に在ったからである。
【００８２】
故に、実施上の事項として、所望の逆戻り時点が斯かる鈍重な作用の中間に陥るのであれば、本発明のソフトウェアは逆戻り時点を鈍重なディスク使用期間の前もしくは後のいずれかへと自動的に調節するのが典型的である。もしこの調節が常に必要とされるのであれば、ディスクアクティビティは一群のディスクアクティビティのシーケンスと見做され得るものであり、その場合に逆戻りは各グループ境界の間における時間的箇所に割当てられる。オペレーティングシステムが安定箇所を明示的に確立する場合、オペレーティングシステムはグループ境界を確立する。
【００８３】
この点まで、本発明のプロセスは、新データが書込まれるときに古いディスク状態が略々保持されるものであった。但し、ユーザが時間的に任意の時点では無く各グループ間の期間に対してのみ逆戻りし得るのであれば、ヒストリーバッファは、グループ内のディスクアクティビティの間に一回以上変更されたデータのグループ境界の前の原状態を記録することのみが必要である。これは、グループ内における所定箇所への二重書込を省略することにより、ヒストリーバッファ内に記憶されるデータの量を減少し得るものである。故に、古い状態は所定箇所への書込みの全てに対して継続的に記録されるのでは無く、グループ内における所定箇所への最初の書込み時点にて一回だけ記録されることが必要である。
【００８４】
当業者であれば、現在のグループ(current group) 内で既に生じた箇所への書込みを検出する多くの技術は公知である。
安定箇所の間の時点がシステムブートに制限されるとすれば、上記プロセスは殆ど、ブート箇所において変更されたデータのみの段増的なバックアップを生成している様なものである。しかし乍ら主な相違は、オーバーフロー無しで常にアクティブとされ得る循環ヒストリーバッファシステムへとバックアップが行くことである。例えば従来のテープによるバックアップは、情報を廃棄することは無い。
【００８５】
本発明の簡素な形態は、変更された一切のデータの初期状態を非循環ヒストリーバッファへとセーブすることである。バッファがオーバーフローしないものとすれば、ユーザはプロセスをスタートする前の箇所へと逆戻りし得る。もしバッファがオーバーフローしたなら、ユーザに対しては全ての変更を廃棄するか又は逆戻りが既に可能で無いことを知るかの問い合わせが為される。この手法は、例えば( 新たなソフトウェアがコンピュータの操作と干渉するが故に又は単なる後知恵から新たなソフトウェアが望ましく無いが故に) 後退回復するかも知れない新たなソフトウェアをインストールする場合に有用である。
【００８６】
本発明は、時間的な箇所をマークする能力をユーザに対して提供することが予期される。ヒストリーバッファが時間的にマークされた箇所へともはや逆戻りし得ないことが分かったとすれば、逆戻りするかログを継続するかに関する質問を受けることをユーザは期待する。
ディスクアクティビティを遮断する方法
本発明の技術は、ディスクに対する転送を遮断(intercept) して変更することに基づいている。それを行う方法はオペレーティングシステムに依存するが、典型的には、通常的に使用されるハードディスク用のデバイスドライバの前へのデバイスドライバの書込みを含む。DOS の場合、この技術はこの効果を達成することが公知である。INT 13要求を参照。既述の如く、部分的なハードウェア機器は、まさにディスクコントローラ内への本発明のロジックの載置を含み得る。
【００８７】
現在のドライブの読取り／書込みアルゴリズム
図５Ａおよび図５Ｂには、現在のドライブの読取り／書込みアルゴリズムが示されている。ディスク読取要求40は通常的に処理される(47)。
所定のディスク位置(disk location) への書込み要求56はステップ57〜63を含むが、これらに依れば、古いデータがディスクから読取られ、ヒストリーバッファへ書込まれ(58 、59) 、マッピングされ(60)、且つ、新データが上記箇所へと書込まれる(61)。シミュレートされた逆戻りが進行中であれば(62)、上記シミュレートされたディスクドライブのマップは更新される(63)。
【００８８】
シミュレートされたドライブの読取り／書込みアルゴリズム
図６Ａおよび図６Ｂには、シミュレートされたドライブの読取り／書込みアルゴリズムが示されている。ディスク位置の読取り要求60の後に、マッピングツリーにおける箇所がルックアップされる(61)。上記箇所が発見されたなら、マップ内で発見された箇所は読取りの為に使用され(62)、その他の場合には、最初に要求された箇所が使用される(63)。
【００８９】
書込み要求70の後には、マッピングツリーにおいて上記箇所がルックアップされ、発見されたならそれが原状態からのものか否かがチェックされ(72)、もしそうであれば新たなページはヒストリーバッファ内に割当てられる(73)。もしそうでなければ、新たなデータはマップされた箇所へと書込まれる(74)。ステップ71にてマッピングツリー内に箇所が発見されなければ、新たなデータページはヒストリーバッファ内に割当てられ、マップエントリが付加され、且つ、新データは新たな箇所へと書込まれる(75)。
【００９０】
ヒストリーバッファの検索および視認
上記ヒストリーバッファは継続的に実行される最近のディスク変更および他の情報を記憶することから、この情報はディスク逆戻り(disk reversion)以外の点でも使用され得る。特に上記ヒストリーバッファは検索され得ることから、特定のイベントもしくは状態を時間的に遡及して探すのを効果的に許容する。典型的に検索の結果は、復旧の為の所望情報が存在し得る良好な逆戻り箇所を特定する上でユーザを案内すべく使用される。以下は、検索の状況展開の例である：
１．オペレーティングシステムのファイリングシステム情報( ディレクトリ) はディスク上に保持されることから、一切の変更はヒストリーバッファ内に記録されている。故に、一個以上のファイルに対する利用可能状態のリストを生成すべく上記ファイリングシステム情報に対する一定の変更のみを探すべくヒストリーバッファを後方へとスキャンすることが可能である。概略的に、変更されるファイルに対する最後の変更日を見るものとする。最後の変更日にてディレクトリが変更を受けた時間の付近において、この時間に対して又はこの時間の付近で逆戻りが為されるとすれば、対応するファイルは新たな状態で存在することが期待される。各々のファイルを復旧すべくディスク全体を逆戻りする代わりに、ヒストリーバッファに対する更に分化したアクセスにより所望のファイルのみのバージョンを発見して復旧することが可能である。本質的に、ユーザの観点からは、ユーザがファイルを選択して本発明のソフトウェアを要求することにより、ヒストリーバッファ内に依然として存在するそのファイルの経時的に利用可能な全てのバージョンを発見し得る。
【００９１】
２．キーストロークを仮定すると、オープンされたファイルの名称および開始されたアプリケーションの名称は全てヒストリーバッファにログされ、この情報は、ユーザが経時的なディスク状態を自身のアクティビティと相関させるのを補助すべく読取られて呈示され且つ／又は検索され得る。
３．ウィルスの作用を調べると共にデータが良好であった時点（汚染の前) および不良となった時点（汚染の後) を特定すべく、特定の検索が設計され得る。
【００９２】
付加的なキャッシング
次の技術は、以前の状態情報を実際に代替的箇所へと移動し、対比リダイレクトを行い、引き続き読取りを新たな箇所へとマッピングすることによりヒストリーバッファが実現される状況に適用される。
目的は、ユーザのコンピュータ使用に対する影響を最小限とすべく、データの読取りに対する実施の影響を最小化すると共にバックグラウンドアクティビティである書込みに頼るべく本発明を実施することである。もし書込みがバックグラウンドで行われれば、ユーザに対する応答に影響すること無くオーバヘッドが付加され得る。ヒストリーバッファを保持すべく現実には一定の付加的作業( オーバヘッド) が実行されるべきことを理解し、本発明者はオペレーティングシステムのキャッシュに頼り、データ書込みの完了およびアプリケーションの継続を許容することは既述した。故に、実際のディスク書込みはバックグラウンドで行われ、このときにオーバヘッドは、ユーザに対して付加的なオーバヘッドの完了を待たせずに付加され得る。
【００９３】
この手法は非常に有効であるが、書込みサイクル( 例えば、ワードプロセッサからの文書のセーブ、または、適切なエディタからのフォトグラフのセーブなど) の間においてアプリケーションにより生成された全ての書込みを保持する上でオペレーティングシステムのキャッシュが十分で無い場合は例外である。これらの状況において、バックグラウンド書込みに対してキャッシュ内に残され得るものを除き、アプリケーション( ユーザ) はディスクに対して書込みが実際に実行されるまで待たされる。
【００９４】
ユーザの遅延をヒストリーバッファに応じさせずに、利用可能なRAM キャッシュより大きい書込みサイクルをカバーすべく、別レベルのキャッシングが導入される。此処で、新データの書込みは、データが実際に何処に属するかに関する適切な情報と共にヒストリーバッファの端部(end) に直接的に書込まれる。通常、ヒストリーバッファ内に載置されるのは原（古い) 状態である。ヒストリーバッファの端部への新データの載置はその様に一時的にのみ行われ、キャッシュの別レベルと見做される。バックグラウンドアクティビティとして、書込みサイクルが完了した後、新データが検索されて通常の書込プロセスが実施される。換言すると、新データはバックグラウンドにおける原状態と交換される。
【００９５】
最終結果は、相当数の書込みが、その本来的に意図された箇所へのデータの書込みと略々等しいタイムコストにて直ちに処理され得ることである。故に多くのアプリケーションはそれらの書込みサイクルを完了してユーザによる継続的アクティビティを許容し得る。その後、バックグラウンドにて、ヒストリーバッファのオーバヘッドがユーザへの遅延を引き起こすこと無く実行される。
【００９６】
このキャッシュに対して書込まれ得る新データの量は２つの要因により制限される：第１に、利用可能なヒストリーバッファ空間である。第２に、一時的リダイレクトを書き留めるべく利用可能なRAM の量は、上記キャッシュのサイズを制限する。バックグラウンド処理が情報を所定位置へと移動する機会を有する前に上記キャッシュ内の情報が読取られた場合、このRAM 内で為された書き留めは読取りが適切にリダイレクトされるのを確かなものとする。
【００９７】
このキャッシング技術は単に、制限された様式で使用される本手法の読取りに関する書込みリダイレクト手法およびマッピング手法であり、ヒストリーバッファ手段内への以前の状態の実際の移動を伴うものである。両方の手法を使用することにより、所定限界までの高速の読取りおよび書込みアクセス、並びに、実質的にオペレーティングシステムが期待する如く構成された現在ディスクの保持をもたらす。読取マッピングはディスクキャッシュ内に一時的に載置されたデータのみに対するものであることから、そのオーバヘッドはディスク全体をマッピングするより少ないと思われる( すなわち、洗練された手法は現在ディスクの読取の処理に関して更に高速である) 。
【００９８】
バックグラウンドアクティビティが新たな状態と古い状態とを交換する機会を有する前に、且つ、本発明のソフトウェアを所定位置に置くこと無く、システムがキャッシュする場合には、ディスクへの通常アクセスを許容する前に処理を終了すべく特別なブート処理が使用され且つされねばならない。このソフトウェアが所定位置とされれば、それは状況を検出してバックグラウンド処理を再開すると共に、クラッシュに先立ちRAM 内に在った覚書きを復元し得る。
【００９９】
データをセーブ、使用および復旧する方法
本出願の残りの部分は、ユーザにより通常的に使用されるのと同一のハードディスク上にバックアップ（ヒストリー的）データが保持されるという本発明に従い情報を復旧する５つのソフトウェア方法を記述する。これに加え、第２ハードディスクを活用して所定度合のハードウェア冗長性をその様に提供するバックアップ機能を拡張する方法が記述される。また、通常的に使用されるものに基づき乍らもそれから隔離されたディスクイメージからユーザがコンピュータをブートし得る方法も記述される。更に、コンピュータシステムのメモリ(RAM) およびディスク状態を時間的に逆戻しする方法も記述される。
【０１００】
ディスク上の情報バックアップおよび復旧
コンピュータのオペレーティングシステム（ＯＳ）は通常、ハードディスク上に情報を記憶する。本発明の好適実施例は、情報が変更される前に該情報の原状態を記録する５つの基本的方法を提供する。最初の４つの方法は実質的に、ＯＳのファイルをディスクページへと構成して割当てるＯＳの方法の外部で作動する。それらは、機能およびディスク活用方法において相当に異なる。最後の方法は、変更された情報の原状態をＯＳのファイリングシステム内に直接的にセーブかつ検索する処理を統合することを必要とする。
【０１０１】
1.Move方法: 重ね書きの前に移動する。
2.Divert方法: 迂回させ、後で自由時間の間に所定位置へとスワップする。
3.Temp方法: 一時的に再マップし、自由時間の間に所定位置へとスワップする。
4.Always方法: 定常的に再マップされ、自由時間の間に再構成する。
【０１０２】
5.File方法: ファイルまたはファイルレベルの一部にてファイリングシステム内で実施される。
簡単な要約
上記の全ての方法に対する然るべき目的は、ユーザに対してトランスペアレントである短期的(near-term) バックアップ機能を提供することである。トランスペアレントとは、ユーザがバックアップを特に呼び出す必要が無く、ユーザの日常的業務が影響されないことを意味する。これは、変更されたデータの以前の状態をそれらのハードディスク上に自動的にセーブして早期時点へと復元(restore) する手段を提供することで達成される。しかし乍ら、ユーザの業務への影響を回避すべく、このセーブ処理はユーザが慣れているディスクアクセスのスループットを実質的に減少してはならない。
【０１０３】
上記Move方法は、自身上に重ね書きされようとするデータを先ず読取り、それをディスクを基にしたヒストリーバッファ内にセーブする段階を含む。該方法は基本的に低速であるという欠点を有している。Divert方法は新たに書込まれたデータをセーブすべくディスク上で比較的に小さなエリアを使用することから、以前の状態をセーブする作業をバックグラウンドへと移動する。該方法は、固定サイズのバッファが最終的にオーバーフローしてMove方法へと劣化する。
【０１０４】
次の３つの方法はスループット問題に対して更に良好な解決策を提供する。上記Temp方法はマッピングを活用して、ヒストリーバッファおよびＯＳによりアクセスされたエリア( メインエリア) が役割を交換するのを許容する。故にユーザは、ディスクアクセススループットに関する顕著な影響無しで極めて大量のデータを書込み得る。しかし該方法は、各ページをそれらの未マップ箇所へと戻すべく大量のバックグラウンドスワップが行われねばならないという欠点を有している。上記Always方法は新たに書込まれるデータを最も古いヒストリーデータ上に直接的に載置することを試行することから、データを移動することの問題を完全に回避することも多い。該方法は、ＯＳのページ割当ての永続的な再マップを要するという問題を有している。File方法はオペレーティングシステムとの統合を前提とすると共に、ＯＳのファイルマッピングを使用してAlways方法から各マップのひとつを排除する。
【０１０５】
添付図面と共に本明細書の最後に向けて見られる各方法の比較の欄は、これらの種々の方法の性質を更に十分に視覚的に示すものである。
用語
本明細書を通し、現在のディスクイメージ(current disk image)、シミュレートされたディスクイメージ(simulated disk image)、およびエキストラページエリア(extra page area) という語句が使用される。現在のディスクイメージとは、ディスクの非ヒストリー的ビューを指す。それは、ユーザにより最後に書込まれたデータから構成される。もしディスク上の所定位置にヒストリーログが無ければ、その現在のイメージは現在においてディスクが含むデータである。シミュレートされたディスクは、ユーザおよびＯＳに対して完全に独立したディスクである。但し、ＯＳ以下のレベルにおけるエンジン(engine)は、現在のイメージおよびセーブされたヒストリーデータからオンザフライ(on the fly)でこのディスクを生成する。実際のハードディスクは略々、メイン(main)およびエキストラ(extra) ページから成る２つの基本エリアに分割される。メインエリアは、現在のイメージに属するページを保持する。エキストラページエリアにはヒストリーデータが保持される。メインエリアマップは、現在のイメージへのアクセスを、エンジンにより割当てられた可能的な代替箇所へと経路変更する。ヒストリーマップ内におけるヒストリーページ記述はヒストリーページを管理する。メインおよびエキストラページは、それら自体のエリア内において、または、相対するエリアからのページにより、役割を一時的にスワップし得る。故に、現在のイメージの一部は一時的に、エキストラページエリアに属するページにマップされ得るが、これはヒストリーデータを通常的に保持している。
【０１０６】
「重ね書きされたデータ(overwritten data)」という表現もまた、注意深く理解されねばならない。最初に、それは物理的に重ね書きされたデータを指すものと見做されるかも知れない。しかし、そうではない。ファイルというものはアプリケーションにより重ね書きされ得るデータから成っている。しかし乍ら、本発明はデータの原状態をセーブすることに関している。これは、データが物理的に重ね書きされる前にデータをコピー（移動）するか、または、書込みをリダイレクトして真の重ね書きを回避することにより達成される。故に該表現は、ＯＳが重ね書きする前に存在しており、今はエンジンによりヒストリーデータとして保存されているデータを指す。
【０１０７】
ディスク管理機能はオペレーティングシステムからファイリングシステムへと分離され得る( 例えば、Windows NTのNTFS) 。本明細書の目的に対し、ＯＳを参照するときに該参照は、ディスク管理に包含される他の一切のサブシステムを含んでいる。
エンジンという語句は、現在論じている方法を実施するロジックを指している。種々の方法が論じられるが、各々がそれ自体のエンジンを有している。
【０１０８】
‘エキストラページエリア’という語句における「エキストラ(extra) 」という語句は概念的に、ユーザに対して可視でないものがエキストラであるという思想に基づいている。また、ディスクは物理的に所定の容量を有している。しかし、Move方法、Divert方法およびTemp方法においてこのディスクの幾分かは確保されてユーザに対して隠される。故に、ＯＳにより報告されてユーザが可視であるディスクサイズ（メインエリア）は、その真のサイズよりも少ない。ユーザが可視でないものが「エキストラ」であり、これをエンジンが活用する。
【０１０９】
ＯＳはディスク位置を、自身の制御下で種々の構造（例えばファイル）に割当てる。しかし乍ら、各エンジンの幾つかは「ディスク位置」の使用に関してＯＳとエンジンとの間を区別すべくＯＳのディスク位置を他の位置へと再マップすることから、ＯＳディスク位置はロケーションキー(locatin key) と称される。
Move 方法
Move方法の基本要素は、上記‘579 号特許に記述されている。該方法において、ハードディスクの一部はヒストリー情報を記憶すべく確保される( ヒストリーバッファ) 。ＯＳがハードディスクに対して書込みを行うとき、自身上に重ね書きされようとする情報は読取られてヒストリーバッファ内にセーブされてから、本来の書込みが実行される。この処理の合理的な最適化は、ディスクヘッドを移動する比較的に極度のタイムコストに対処している。一連の近傍書込(nearby writes) が遅延されて組合され得ることから、影響を受けたデータはブロックとして読取られ、ヒストリーバッファへ移動されてから本来の書込みが実行される。
【０１１０】
変更された情報の原状態をセーブする一切の方法を使用しなければ、単一の書込みは、データが書込まれるべきディスク上の特定位置にディスクヘッドを位置決めするステップを含むのが典型的である。Move方法はこれを、１回のディスク読取りと２回のディスク書込みに増加する。これはディスクヘッドの３回の位置決めを含み：１回は、自身上に重ね書きされようとする目的エリアへのものであることからそのデータが読取り可能であり、別の１回はこの原データをセーブすべくヒストリーバッファへのものであり、最後は新データを重ね書きすべく目的エリアへと戻るものである。
その４の２
書込みをメモリへとキャッシュすると共に自由時間の間にディスクに対する該書込みをコミットすることはユーザに対する影響を減少もしくは排除し得るが、実際のデータ書込みは時間的に３倍となる。ユーザがコンピュータアプリケーションを介してディスクにデータを書込むとき、ＯＳはそのデータを実際にはRAM 内に記憶し、如何にも書込みが実際に生じたかの様にユーザの継続操作を許容する。その後のいずれかの時点で、ファイリングシステムは実際のディスク書込みを実行する。Move方法を使用して原状態をセーブすると、このバックグラウンド書込み処理の所要時間は３倍になるが、理論的にユーザは自由に作業を継続した筈であることから機能低下を認識することは無い。
【０１１１】
この処理の欠陥は、典型的に書込まれるデータ量を保持する上でRAM キャッシュが不十分なことが多いことである。例えば、ワード処理文書は直ぐにメガバイトのサイズとなり得る。グラフィックイメージのファイルは更に大きい。キャッシュがオーバーフローすれば書込みは遅延され得ないことから、ユーザはそれが完了するまで待たねばならない。故に、ユーザは書込時間の３倍化を知る。例えば0.1 秒から0.3 秒へと時間が３倍化したとしても、少量のデータの書込みは大量のデータほど重要では無いと論ずることも可能である。しかしファイルのセーブに10秒を要すればそれは30秒となり、殆どのユーザは、原状態をセーブするMove方法を使用することは深刻でおそらくは不当な機能影響と考えるであろう。
【０１１２】
Divert （迂回）方法
Divert方法のひとつの好適実施例に依れば、新データはヒストリーバッファの端部に書込まれ、後で自由時間の間にそれはヒストリーデータと共に所定ロケーションにスワップされる。これは、重ね書きの前にデータを移動すべく元に戻ること無く書込まれ得る新データの量を増加する。最近に書込まれた所望データが未だ所定ロケーションにスワップされていないとすれば、制限要因はヒストリーバッファのサイズと、読取りをヒストリーバッファにリダイレクトするに必要なマッピング処理である。換言すると、所定ロケーションから移動されてしまったデータに対する読取りおよび書込みを処理せねばならない。
【０１１３】
この方法のマイナス面もまた、この方法が使用され得ないほど多くのデータが書込まれるときに生ずる問題に対する解答に在る。すなわち、Move方法が使用されねばならないことから、システムの機能は影響を受ける。例えば、CD-ROMをロードする為に通常は10分を要するとすれば、それは代わりに1/2 時間を要し得る。殆どのユーザはこれを受入れられない。また、この方法が低速化の可能性を減少したとすれば機能低下無しで大きなファイルが書込まれ得るが、更に大量のデータをロードする状況は依然として問題である。
【０１１４】
再マッピング
殆どのユーザにより受け入れられるべく、原状態をセーブする合理的な方法は該方法が使用されない場合と類似したディスクアクセス機能をもたらさねばならない。これは、新たなソフトウェアシステムをインストールするときなどに生ずる大きなファイルの書込みもしくは大量のデータのロードなどの一般的状況に対して当てはまる。この技術の重要な側面は、Move方法および問題のあるそのオーバヘッドに再び陥ることなく再マッピング技術を使用して代替的ロケーションへのデータの載置を許容することである。
【０１１５】
次の２つの方法は、原ディスク状態をセーブすべく再マッピングを活用する範疇に入る。本明細書中に示された詳細は、再マッピングに伴う機能問題を本発明が回避したことを記述している。
Temp 方法
Temp方法は、大量のデータが重ね書きされるという状況下においてさえも、該方法を使用しない場合（以前の状態をセーブしない場合）と比較して同様のディスクアクセス機能をもたらす。Temp方法は、新たに書込まれたデータはヒストリーバッファの端部に迂回されると共に後で所定ロケーションにスワップされる、というDivert方法を基礎にしている。但し、Temp方法は代替的バッファへの書込みの迂回に焦点を合わせていない。寧ろ、Temp方法はバッファの本来的サイズ制限を回避することによりオーバーフローの可能性を回避する。もしオーバーフローが生じればMove方法は低速なMove方法へと押しやられる。他方、Temp方法は固定サイズのバッファにおける変更を蓄積せずに変更を直ちに再マップされたロケーションへと書込む。故に、相当数の書込みによりMove方法のバッファリングはオーバーフローし得るが、Temp方法は新データを書込む一定の代替的ロケーションを常に有している。
【０１１６】
ディスクの以前の状態は、変更された情報の古いコピーがセーブされる「エキストラ(extra) 」エリアをディスク上に確保することにより保持される（図７参照）。故に、ＯＳが可視であるディスクのエリアであるメインエリア(main area) にＯＳが書込むとき、自身上に重ね書きされようとするページは、少なくとも最終的に、循環ヒストリーバッファ（エキストラページ）に移動される。故に、ディスクの以前の状態は、現在のイメージをヒストリーバッファ内の適切なデータと組合せることにより復元され得る。（勿論、時間的に戻れるのはヒストリーバッファ内に以前の状態がセーブされた限りにおいてである。）
既に論じた如く、自身上に重ね書きされようとするデータをヒストリーバッファへと単純に移動する上では機能問題が在る。その場合、メインエリアへの書込みは３つの段階を必要とする：(1) 自身上に重ね書きされようとするデータの読取り、(2) この古いデータのヒストリーバッファ内への書込み、および、(3) 本来の書込みの完了、である。問題は、この余分な作業が必要なことでは無く、この作業が書込みの時点で行われねばならないことから全体の書込み機能が影響を受けることである。ＯＳのRAM キャッシュもしくは他のタイプのキャッシュが集中的な書込みを保持するに十分であると共に上記方法のエキストラディスクアクセスがバックグラウンドで行われる場合、オーバヘッドはユーザに認識されない。しかし乍ら、キャッシュがオーバーフローする如き多くの書込みが行われたとすれば、結果的な３倍の低速化は過剰となる。
【０１１７】
本発明に係るひとつの解決策は、書込みを代替的ロケーションへとリダイレクトするのを許容するマップを活用し、古いロケーションはマップ内で為される覚書きによりヒストリーバッファの「一部(part)」となることである。故に、利用可能なヒストリーページＹへ迂回されるという一定のロケーションＸへの書込みが生じたとき、上記マップが調節される。元はＸと関連したロケーションは今や、上記ヒストリーバッファの一部であるヒストリーデータとなる。極めて古いヒストリーデータを含んでいたＹに関連するロケーションは今や、ＯＳが可視である主要イメージの一部となる。図８は、メインエリアおよびヒストリーバッファを表すべく２つのマップが如何に使用され得るかを示している。
【０１１８】
上記マッピング手法に依れば、該方法は継続的に作動すると共に、データを中断したり動き回すこと無く、変更されたデータの古い状態を保持する。
而して、経時的に生ずる問題は、メインエリアにおいて連続エリアであったものが事実上ディスク全体に亙り断片化されることである。これは、ディスクアクセス機能を相当に低減する。殆どのオペレーティングシステムおよび関連ユーティリティは、ディスク上のデータの構成を管理して断片化を最小化することに努力しており、すなわち、( ひとつのファイルの如く) ブロックとして読取られる可能性が高いデータは隣接ロケーションに配置される。ＯＳの割当てを再マッピングすることにより、上記エンジンは断片化を導入してしまう。
【０１１９】
この問題を解決すべく上記エンジンは、ディスクに対する鈍重な書込みアクセスを許容するが、同時に、メインおよびエキストラページエリアが何処に在るかの情報が保持されるというマップを採用する。故に、バックグラウンドにおいて各ページは所定ロケーションに戻され、メインおよびエキストラページエリアをそれらの独立的な非マップ状態へと戻す。
【０１２０】
殆どの状況において該手法は、ディスク機能に関して認識し得る影響を殆ど有さない。但し、再マッピングに由来する断片化に依り機能の低下をユーザが認識する可能性がある。
上記マッピングシステムはキャッシュされて効率的であることから、それはオーバヘッドを殆ど導入しないと思われる。（ユーザがワード処理文書をセーブするときの様に）データは大きなブロックで書込まれ得ることから、エキストラページエリアへの最初の迂回は断片化を引き起こさない。実際に書込み機能は強化される、と言うのも、通常は時間的に集中的なシークを伴うというディスクの異なるエリアへの書込みが、連続的なエキストラページエリアに代替的にリダイレクトされるからである。引き続きヒストリーバッファを通るパス(pass)の間に断片化が生ずるが、これは、最初のパスの後にその各ページがメインエリアに関して散在される場合である。更なるパスが為されるにつれ、問題は悪化する。これは、再マッピングの故にシステムの機能が低下する場合である。
【０１２１】
しかし乍ら２つの理由により、機能の低下は生じないと思われる。第1 に、鈍重であるが短い書込みアクセスの相互間には相当の時間的なギャップが在るのが典型的である。故に、セーフポイントが確立されると共に、エンジンはメインおよびエキストラページを所定ロケーションへとスワップバックする時間をバックグラウンドに有することになる。換言すると、ディスクアクティビティにおける各ギャップの間、エンジンは断片化解消を行う。時間的なギャップの例は、大きな文書もしくはグラフィックファイルを編集している間における、各ファイルセーブ間の合間である。図９は、短いバースト書込作用を示している。
【０１２２】
機能低下は起きないであろうという第２の理由は、上記エンジンが合理的に鈍重な長期間の書込みストリームの下では作動停止することである。書込まれるデータの量は、エキストラページエリアのサイズに対して大きい必要がある。斯かる大量の書込みは例えば、CD-ROMからデータをロードするときに生ずる。この状況は、同一の書込みセッション内においてエキストラページエリアの殆どが重ね書きされたときに検出される。書込みセッションは、書込みの前後のみにおける安定状態による遷移的な一連の書込みである。この場合、メインエリアマップはフリーズされると共にヒストリーデータのログは中止される。
【０１２３】
再マッピングに起因して深い断片化を引き起こすには、エンジンの断片化解消（スワップ）に利用可能なバックグラウンド時間が殆ど無くて大量のデータが書込まれると共にエンジンの作動停止を引き起こすほどには一定では無い、という一連の書込みが必要である。しかし、少なくともパーソナルコンピュータ上では斯かる状況はおそらく希である。すぐ上で説明した如く、ディスク書込みの短いバーストおよび長いバーストはこのタイプの断片化（フラグメンテーション）に繋がらない。
【０１２４】
鈍重な書込みの下で上記エンジンが作動停止したとき、機能に対する実質的な影響は無い。もしエキストラページエリアがディスク全体の約10％であれば、おそらくは多数回に亙りディスク全体は重ね書きされつつあるとしてもこのメインエリアマップはこのエリアをカバーするだけである。作動停止時において、エンジンはログをあきらめ、マッピングが所定ロケーションへと最後に載置した処であれば何処でもデータを書込み、且つ、通常作動の継続を許容すべく最善を尽くすことを試行するのみである。この状況においてエンジンは、一切の復旧機能を提供し得ないことを確認する。図１０は、合理的に連続的な書込みアクティビティの拡張期間を示している。
【０１２５】
ユーザは長時間の連続的なデータ書込みシーケンスの中央の点に復元することを望まないこともある、と言うのも、ディスク上に何が在るかは一般的に保証されないからである。例えば、多くのオペレーティングシステムは、ファイルの存在に関する情報がディスクに書込まれる前にアプリケーションがファイルをクローズすることを要求する。それ以前においては、たとえ数日間に亙る書込みが生じていたとしても、書込まれたデータはクラッシュの場合において復旧されない。故に、大きな書込みシーケンスが循環バッファの端部から逸れる如き多くのデータが循環ヒストリーバッファ内にログされたとき、継続してログを行う意味は無い。ログは、シーケンスの開始時点におけるディスクの状態への戻り経路を生成するのである。それが喪失されたのであれば、上記シーケンスの残りの更なる部分を如何にして復元するかを認識することは無意味である。故に、合理的に連続的なデータ書込みによりヒストリーバッファがオーバーランされたときにログを作動停止することは是認され得る。上記定義の「連続的」という部分は、ＯＳが途中でセーフポイント状態を提供しないことであると銘記されたい。
【０１２６】
図１１は、深い断片化に繋がる状況を示している。それは長いシーケンスの書込みを含んでいる。但し、時間的ギャップまたは他の情報は多くのセーフポイントを提供することからログを有用とする。ユーザは、バッファの端部から逸れた長いシーケンスのスタート点に復元し得ないこともあるが、更に先には多くのセーフポイントが在る。図１１は、この頻繁な書込みアクティビティであり乍らもセーフポイントを確立するに十分なギャップを有する場合を示している。各ギャップはバックグラウンドのスワップに対して十分でないことから、断片化解消を阻害している。故に断片化はいよいよ問題となり；再マッピングの故にエンジンは、ディスク上で連続的なエリアであるとＯＳが可視であったものを破断することから、これらのエリアに対するアクセスは更に低速となる。速度低下が生ずる、と言うのも、大きな連続的ブロックのデータであるとＯＳが認識していたものを読取る為にディスク表面上の多くの異なるロケーションへとディスクヘッドが移動せねばならないからである。
【０１２７】
エンジンがマップをフリーズして更なるログを無効にするという鈍重で連続的な書込みアクティビティに関しては構造の相対的サイズを考慮するのが有用である。この例に対しては、エキストラページに対して100 メガバイトが割当てられた１ギガバイトのディスクドライブを仮定する。メインエリアマップは、100 メガバイトをカバーすべく増大すると共に約3.2 ％のオーバヘッド(16 バイト／572 バイトのページとする) もしくは約3.2 メガバイトを含んでいる。これは、全体的にRAM 内にフィットし得ないほど大きなものである。ひとつのルート(root)と、ひとつの中間レベルノード、および、200 個の低レベルノード（ノード毎に1,000 個であれば200,000 個のエントリが記憶される）が必要とされる。但し、上記ツリーの最初の２つのレベルは概略的にRAM 内であり、低レベルノードは1,000 ページアクセス毎にフェッチされる。これは、ＯＳのアクセスは典型的に連続したロケーションに割当てられた一連のページを含むことからエンジンはひとつの低レベルノードから別の低レベルノードへと常にジャンプするものでないことを前提としている。
【０１２８】
上記ツリーの上位部分は、低レベルノードのフェッチが必要か否かを示している。もしＯＳ可視のディスク全体（メインエリア）が書込まれたならば(900メガバイト) 、11％の時間は低レベルノードを通過する。故に、低レベルノードのマッピング境界が交差したときに、1,000 回毎に１回のアクセスは別のノードへのフェッチを必要とする。これは無視できるオーバヘッドである。他の89％のアクセスにおいては、上記ツリーの上位の２つのレベルはキャッシュされて直接的な（未マップの）アクセスを示すことから、これも無視できるオーバヘッドである。
【０１２９】
次に、鈍重であるが間欠的なディスク書込みによりメインマップが認識可能な900 メガバイト全体に及んだ状況を考える。上記マッピングは先のサイズの９倍であり、すなわち28.8メガバイトである。これは、ひとつのルートと、ふたつの中間レベルノード、および、1,800 個の低レベルノード（ノード毎に1,000 個であれば180 万[1,800,000] 個のエントリが記憶される）を必要とする。此処でも、ツリーの上位の２つのレベルは略々キャッシュされる。但しこの場合、全てのアクセスが低レベルノードを通過する。合理的に最悪の場合において20回のアクセス毎に低レベルノードがフェッチされるとすれば、オーバヘッドは５％である。これは、スワップに対する十分なバックグラウンド時間が与えられたときに自動的に解決されることを銘記すれば、最悪状態に対して依然として非常に合理的である。
【０１３０】
図１２は、メインおよびエキストラエリアの両者におけるページを２つのマップが参照している処を示している。換言すると、ひとつのエリアに属するページが一時的に他のエリアからのページとスワップしている。図１３は、ヒストリーマップはエキストラページにおけるページを参照すると共にメインマップはメインエリアにおけるページのみを参照するというスワップの効果を示している。
【０１３１】
メインおよびシミュレートされたイメージマップに必要な空間を減少すべく、当然乍ら、上記マッピング内に示されない一切のロケーションは示された記憶箇所に直接的に対応すると仮定する。換言すると、上記ロケーションはマップされない。故に、バックグラウンド処理が各ページをそれらが属するエリアへとスワップするときにメインエリアマップは収縮して無くなる。図１４は、メインエリアマップのリンクが除去され、全ての記憶内容がその正式のロケーションに在るところを示している。上記シミュレートされたイメージマップも示されている。それはメインエリアマップ反映ページとは異なり、ヒストリーから「復元」されることにより、早期時点からのメインエリア、並びに、シミュレートされたバージョンに対して為された時点からの一切の変更を反映せねばならない。メインおよびシミュレートされたバージョンが時間的に一定の時点で共通の状態を共有していたが両者は引き続き異なる様に変更された可能性がある場合、シミュレートされたバージョンが変更されたならそれは時間的に分岐物を示すことを銘記されたい。
【０１３２】
セーフポイントおよび切換状態
上記エンジンの基本目的は、ディスクの状態を以前の時点へとロールバックする手段を提供するにある。これは、原状態および現在状態を保持することと、これらが如何に組合されることにより過去における一定の特定時点に対応する所定状態を生成するかをガイドするマッピングシステムとを含むものである。実際、更新されつつある処理に情報が含まれていたという遷移的状態へとディスクを復元することは有用でない。例えば、ワード処理文書をセーブするものとすれば、セーブの前もしくは後のいずれかでディスクを見ることが望まれよう。書込プロセスの間における時点への復元は回避されねばならない、と言うのも、ユーザが何を見出すかの保証が無いからである。故に、ディスクが合理的に使用可能である時点に対応するセーフポイントの概念が導入される。これらの時点は、ＯＳがそのキャッシュを完全に放出したことを示すものと思われるディスクアクティビティの大きなギャップ、または、利用可能であればその様なことを示すＯＳからの特定信号、により識別される。
【０１３３】
ユーザは、逆戻りすべき時間的なセーフポイントのみを選択することが許容される。このことは、エンジンがこれらの時点においてのみ自身の情報をディスクに完全に放出する必要があることを意味する。それはまたログの処理が、各書込みおよびその原データを記録したもので無く、時間的に所定のセーフポイントにおけるひとつの状態から次のセーブポイントの状態までの変更であることを意味する。故に、エンジンによりディスク上に保持された安定（非遷移的）情報は、時間的に別個の点、すなわちセーフポイント、にて切換わり、次のディスク表現を包含する。全ての変更に対して以前の状態をログすれば各セーフポイントにおける遷移に対して必要な情報を提供するが、それは過剰である。
【０１３４】
各セーフポイントの間において何度も変化すると共に上記ヒストリーバッファ内に記録される必要があるのは、所定ページの最初の原状態のみである。主要イメージの一部としてセーブされるのは、上記ページの最後の状態のみである。換言すると、もし遷移期間の間にＯＳ（アプリケーション）が同一のディスクロケーションに反復的に書込めば、来るべきセーフポイントを示すべく最後の状態のみを保持する必要がある。
【０１３５】
エンジンの内部データを新たな安定状態へ切換えることは概略的に、ＯＳ内からのデータの一切の放出から独立していることを銘記されたい。上記エンジンは時間的な一定の任意のポイントで中断し、其処までＯＳにより書込まれたデータを示す為に必要なマップおよび他のデータの全てを完全に放出し得る。但し、もしＯＳのデータが不完全（遷移的）であれば、この時点への復旧を提供するポイントは無いことが指摘される。故に、ＯＳに対してエンジンを同期すれば、エンジンにおける無駄な安定遷移は回避される。
【０１３６】
もしＯＳが合理的に使用可能なディスクイメージを常に保持すると共に、復旧されるべき合理的ポイントのみを示す上で時間ギャップが十分でなければ、時間的な任意のポイントへ復旧することをユーザに許容するという最後の手段に出ても良い。これは、全ての変更および更新処理の以前の状態をログしてエンジンの内部データを常に現在状態に保持することを必要とする。斯かる設計態様はパーソナルコンピュータに対しては正当化されず、示された方法においては対処されない。
【０１３７】
各セーフポイントの間の時間においてはディスクが遷移的となるが、この時間は書込みセッションと称される。此処でも、もし所定の書込みセッションの間に一個以上の書込みが所定ロケーションに対して生ずれば、最初の書込みの前におけるデータの初期状態のみがセーブされる。故に、引き続く書込みはページ上に直接的に重ね書きされる。所定書込みセッションの間における中間状態をセーブする必要は無い。ヒストリーバッファから後続書込みを除去し得なくとも余分に空間を取る以外の弊害は無い。
【０１３８】
後続書込みを検出するひとつの技術は、再マッピング情報と共にセッションインデックスを保持することである。もしディスクの小さな部分のみが再マップされるのであれば、付加的なディスクオーバヘッドは最小限である。しかし乍ら、ディスクの大部分をマップすることは可能である。この全体マッピングは、来るべきAlways方法におけるルールである。再マッピング機構からページ毎の４バイト（セッションインデックス）オーバヘッドを減少すべく、RAM 内にビットマップを保持することが推奨される。各ビットは、対応ページが現在の書込みセッションにおいて重ね書きされたか否かを示す。572 バイトのページサイズとすれば、100kのRAM は400 メガバイトの状態を示す。現在におけるアクティブエリアのみをマップし、ディスク全体に400 メガバイトが展開され得る如くビットマップがブロック化されるのであれば、この100kは所定書込みセッション内における400 メガバイトのデータの重ね書きを取り扱い得る。この比率は、RAM およびディスクのコスト、並びに、書込みセッション内において変化し得るデータの量を考慮すれば合理的である。次のセーフポイントが開始したとき、このビットマップは単にクリアされる。
【０１３９】
使用中ビットマップ
ヒストリーデータに加え、エンジンはディスク上に他の種々の「オーバヘッド」情報を保持せねばならない；例えば、マップである。もしシステムがクラッシュしてリスタートしたのであればオーバヘッド情報は破損したであろう時間的なポイントを導入すること無く該オーバヘッド情報を変更する方法に関しては、概略的問題が生ずる。上記エンジンはセーフポイントのみへ逆戻りすることが期待されることから、クラッシュの場合、ディスクは最後のセーフポイント時点の状態まで戻ると推測される。
【０１４０】
最後のセーフポイントのデータを常に確実に利用可能とする如くエンジンのオーバヘッド情報を保持する方法は、斯かる情報の全てに対して空間を二重に割当てることである。いずれの方のコピーが最後のセーフポイントに対応すると共に、もし在るなら、いずれのコピーが遷移的データに対応するかを示すべく、２つのビットマップが使用される。最後のセーフポイントの時点からの一切の変化は遷移的と見做され、「他方の」割当てに書込まれる。故に、安定なビットマップは、いずれの割当てが最後のセーフポイントに対応するオーバヘッド情報を構成するかを示す。クラッシュが生じれば、リスタート時に安定なバージョンがロードされる。その他の場合、すなわち通常の状況下で、遷移的ビットマップは安定ビットマップにおけるのと同一の割当て、または、変更された遷移的データを含む他方の割当てのいずれかを示す。やがて次のセーフポイントに到達すると共に全てのデータがディスクへと完全に放出されたとき、現在の遷移的ビットマップは新たな安定ビットマップとなる。
【０１４１】
スイッチページ
上記使用中ビットマップ(In Use Bit Maps) は、遷移の間において変化した内部エンジンデータの複製を容易化する。スイッチページ(switch page) は、２つの使用中ビットマップのどちらが安定および遷移の役割を夫々演じているかを示すべく使用される。スイッチページは、エンジンの内部データの全てに対するルートである。それは、２つのコピーに対する空間と共に所定ロケーションに割当てられる。上記ページが更新されるときは常に、両方のコピーが書込まれる。何らかの理由（例えば、システムがクラッシュすること）により第１コピーが好首尾に書込まれなければ、第２コピーが有効であると見做される。故に、ブートアップしてスイッチページを読取るとき、第1 コピーが読取られ、その読取りが不首尾であれば（例えば書込みの間にディスクがクラッシュしていれば）、第２コピーが読取られる。
【０１４２】
上記スイッチページはクラッシュに先立ち好首尾に部分的に書込まれ得ると仮定することが推奨される。故に、上記ページの読取りは、ディスクエラーを生成するのではなく破損したデータをもたらす。上記スイッチページのフロントおよびスタートにおいてインクリメントするスイッチページの更新カウント、並びに、CRC もしくはチェックサムを含めることにより、この問題ケースは回避される。上記スイッチページを読取るとき、２つの更新カウントは比較されてCRC が有効化される。上記スイッチページはブート時点においてのみ読取られ、RAM 内に載置され、引き続き、ユーザのセッションの間に周期的に書込まれる。
【０１４３】
使用中ビットマップに関する情報に加えられた情報もまた、スイッチページ内に保持され得る。スイッチページ内に何を保持するかの制限要因は、その更新が比較的に効率的なことを確実にすることである（例えば、多すぎて書込めないデータでないこと）。スイッチページで典型的に見られる他の情報は：バージョン番号、次の書込みエリア、現在のおよびシミュレートされたイメージマップに対するルートリンク、低レベルのスワップ情報、および、総括的にログされたデータページをトラックするパラメータである。
【０１４４】
メインエリアおよびヒストリーマップ
メインエリアおよびシミュレートされたマップを実現すべく、ツリーが使用される。十分なバックグラウンドのスワップ時間が与えられたとすれば、メインエリアマップは減少されて無くなり、それは再マッピングがアクティブでないことを示す。メインエリアマップ内の各エントリは、次のフィールドを含んでいる：
1.対応データの実際のロケーション(0＝再マッピングなし) 。
【０１４５】
2.訪れているページロケーション（このロケーションに実際に記憶されたデータに対応）。
各エキストラページに対してひとつのエントリが在る場合、上記ヒストリーマップはテーブルとして実現されねばならない。これらのエントリは典型的には常にアクティブであり、それらの関連エキストラページの元のロケーションを示している。任意の時点において、上記「ヒストリーバッファ」は、アクティブであるときには一時的スワップリンクに従うことにより、または、関連するエキストラページを参照することにより示されたページの集まりである。ヒストリーマップを構成するヒストリーページ記述(HPD) 内の各フィールドは次のものである：
1.ページタイプ（使用中でなく、ヒストリー的で特別なもの）。
【０１４６】
2.示されたデータの元のロケーション。
3.スワップリンク。このエントリに対応するエキストラページ内に通常的に見られるデータを一時的に受け取ったロケーション(0= なし) 。
4.リターンリンク。訪れているページロケーション（このエントリのエキストラページ内に実際に記憶されたデータに対応する) 。それが別のエキストラページを示すときにのみ保持される。
【０１４７】
上記スワップリンクは、HPD のエキストラページに通常的に関連するデータを実際に有するページを示す。このリンクは、メインページもしくはエキストラページを示す。もしナル（null）であれば再マッピングは有効でない。上記リターンリンクは、スワップリンクがエキストラページを示すときにのみ使用される。この場合、参照されたエキストラページに関連するHPD は、参照しているスワップリンクを有するHPD を示すべくセットされたリターンリンクを有している。換言すると、二重リンクリストに関連する如く、スワップリンクは「次の」リンクの如きものであり、リターンリンクは「最後の」リンクである。
【０１４８】
これらのリンクはリンクリストを形成すると見做すのが適切である。上記システムは、HPD ＸからＹへのリンクおよびＹからＸへのリンクが在るという単なる２つのHPD に限られるものでは無い。エンジンが実行されてHPD を複数回通過した後、経時変化した進展ならびにスワップリンクおよびリターンリンクは、２つより多いHPD を包含し得る。例えば、ＡのロケーションにてＢを見出し、ＢのロケーションにおいてＣを見出し、ＣのロケーションにおいてＡを見出すこともある。故に、データを所定ロケーションに戻すには３通りのスワップが必要とされる。図１５はこの状況を示している。
【０１４９】
メインエリアへの書き込み
以下は、ＯＳが特定のディスクロケーション（ＳＬ）に新しいデータを書き込むときにエンジンにより行われる８つのステップである。エンジンはディスエイブルされていないと仮定する。もしこのロケーションに書き込まれた最後のデータが現在の書き込みセッションからでると、新しいデータはそれに重ね書きするものであることに注意すべきである。そうでなければ、次のステップはヒストリーバッファの原データをセーブするように行動する。
【０１５０】
１．データを受けるために次に利用可能な「論理的」ロケーションは、書き込むためのヒストリーバッファ（マップ）の次のロケーションを見守ることによって決定される（ＨＰ）。
２．ヒストリーバッファにおけるこの論理的ロケーションのためのスワップリンクは、実際エキストラページを直接使うべきか、または代わりに、そのコンテンツが一時的に置かれたところに行くかどうかを見るためにチェックされる。これは効果的な書き込みロケーションである（ＥＷ）。
【０１５１】
３．新しいデータはＥＷに書き込まれる。
４．ノートは正常な状況の下で書き込みにより重ね書きされたデータの実際のロケーション（ＯＬ）から作られる。言い換えれば、ＳＬについてのデータを現在示しているメインエリアマップエントリーがどこに位置しているかを決める。
５．ＳＬについてのメインエリアマップエントリーは、そのデータがＥＷにあることを示すために更新される。
【０１５２】
６．論理的エキストラページロケーションのためのスワップリンクは更新される。それはＯＬに変更され、ＳＬについてのデータを含んだ実際のロケーションを示す。
７．ＥＷがメインエリアページなら、ＥＷからＳＬのためのビジターリンクをセットする。
【０１５３】
８．ＯＬがメインエリアページなら、ＯＬからＨＰのためのビジターリンクをセットする。
書き込み例
以下の例は、３つがメインエリアに割当られ、他の２つがエキストラページに割り当てられた５つのページロケーションをもつディスクを仮定している。図１６参照。この例において、如何に種々のＨＰＤおよびツリーが実際に動作しているか、また如何にＨＰＤおよびエキストラページの割当が働くかについての詳細を説明し、または示すための試みはなされていない。ＨＰＤにおけるリターンリンクは書き込みシーケンスについて示されていない。
【０１５４】
この例では、ロケーション１、２、３、そして３、および２へ、如何に５つの書き込みが扱われるかを描くことによって開始される。この例では次にスワップセクションに続く。
２つのエキストラページについては関連するＨＰＤがある。複製ディスクレイアウトを指している矢はＨＰＤのスワップリンクの値を表している。矢は参照エキストラページ（ＨＰＤ）から示されたディスクロケーションに行っている。複製ディスクレイアウトは、新しいまたは追加のストーレッジではないことに注意されたい。それは単に「実ページ内のデータ」の見出しの下で示されたのと同じストーレッジである。図１７を参照されたい。そこには、２つのヒストリーページについてのスワップリンクが、「ｘ２ｂ」と「ｄ２ａ」が「ｘ１ａ」と「ｄ１ａ」と同様にスワップされたことを示している。
【０１５５】
より明確にリンクを示すためにディスクレイアウトを複製する特徴を保持し、別のコピーが「ビジターリンク」の見出しの下で作られる。メインエリアマップは各ページロケーションについて２つのリンクを持っている。１つは関連するロケーションについてのデータが実際にどこに見いだせるかを示し、他はその内容が与えられたロケーションに一時的に置かれたページを示している。図１８において、ロケーション＃１についてのメインエリアマップは、このロケーションについてのデータ「Ｄ１ｂ」は実際に第１のヒストリーページにある。しかし、もしロケーション＃１が実際に読み取られたなら、ビジターリンクはロケーション＃３に属するデータ「ｄ３ａ」がリターンされることを示している。
【０１５６】
データは３つのキャラクタによって表される。第１は通常の「ｄ」であるが、ロケーションがエキストラページエリアに最後に書き込まれたロケーションに対応する時には「Ｄ」に変化する。これは次のロケーションは、そのエリアのトップの周囲を包んでおり、そこでヒストリーデータをセーブするための次のロケーションを表すことを意味している。第２のキャラクタはデータが属する正確なロケーションを示す数である。例えば、すべてのリダイレクションマッピングがされなかった時の「ｄ３ｂ」はロケーション＃３に現れる。最後のキャラクタはデータのバージョンを表す。「Ｄ１ａ」はロケーション＃１に最初に書き込まれたものであり、「ｄ１ｂ」はこのロケーションに次に書き込まれたものであり、以下同様である。
【０１５７】
もしデータアイテムを表す３つのキャラクタがアンダーラインされたなら、データはヒストリック（先に重ね書きされたデータのセーブされたコピー）であり、そうでなければそれはメイン（現在の）ディスクイメージの一部である。ＯＳに可視のメインディスクイメージの一部分は決して廃棄されないので、ヒストリックデータのみが、トスされる（投げ捨てられる）。
【０１５８】
図１９Ａにおいて、エンジンの初期状態が示されている。エキストラページにはなにもない。メインエリアマップにおいてはどのリンクもアクティブではなく、例えば、ロケーション＃１についてのコンテンツは実際ロケーション＃１に位置していることを示している。メインエリアはそれらのそれぞれのロケーションに「ｄ１ａ」、「ｄ２ａ」、および「ｄ３ａ」を含んでいる。
【０１５９】
図１９Ｂにおいて、「ｄ１ｂ」の書き込みはロケーション＃１になされる。システムは先の状態を失うことなしにロケーション＃１に書き込むことができないので、書き込みはエキストラページエリアの第１のロケーションにリダイレクションされる。このぺージのスワップリンクは、これがそのデータが実際に属するところであるので、ロケーション＃１にセットされる。同様に、もしロケーション＃１に行けば、「ｄ１ａ」を見いだす。これはそれが属するところにスワップできるまでこのロケーションをビジットしているだけである。示されているように、ビジターリンクは第１のエキストラページロケーションを示している。もしロケーション＃１と第１のエキストラページロケーションを交換したなら、すべてのリンクは消えるであろう。しかし、図１９Ｃにおいてラッシュと別の書き込みが生じる。スワッピングは延期される。
【０１６０】
図１９Ｃにおいて、「ｄ２ｂ］の書き込みはロケーション＃２に対して行われる。そのプロセスは図１９Ｂとほぼ同じである。しかし、データは先のフレームに書き込まれた最後のものである「Ｄ１ｂ」の後の「次」である第２のエキストラページに行くことに注意されたい。また、別の書き込みが、スワッピングのための時間が存在する以前に発生する。
【０１６１】
図１９Ｄにおいて、「ｄ３ｂ」の書き込みはロケーション＃３に対してなされる。最初の問題は、書き込みをどこに転換すべきかである。図１９Ｃにおいて、「Ｄ２ｂ」は第２（ボトム）である最後の書き込まれたエキストラページのロケーションであったことを注意されたい。それゆえ、再使用するための次−最も古いヒストリックデータを表す−は最初のもの（アドバンス、トップにラッピングバックする）である。しかし、再び図１９Ｃに戻ると、このページの内容はロケーション＃１とスワップされていることがわかる。そのため、新しいデータはロケーション＃１に書き込まれ、永久に廃棄される「ｄ１ａ」に重ね書きする。マップはロケーション＃３のデータ「ｄ３ｂ」がロケーション＃１で見いだされることを示すために更新される。
【０１６２】
次に、スワップリンクは第１のエキストラページのために更新される。このスワップリンクはその実データが今最も新しいヒストリックデータであるロケーションを示す。これは、丁度重ね書きされたデータを示す。書き込み要求はロケーション＃３に対してなされ、その以前の状態はエキストラ（ヒストリック）ページと関連した状態として参照される。図１９Ｃにおいて、マッピングは行われず、データ「ｄ３ａ」が正常に重ね書きされる。スワップリンクはここに示すためにセットされ、このロケーションのデータは今もヒストリックであるのでアンダーラインされる。
【０１６３】
ビジターリンクに注目すると、これらはその内容またはそれらの内容の解釈が変化したロケーションにおいて実際のデータのオーナーを反映していることがわかる。そこで第１に、書き込みはロケーション＃１に迂回されたロケーション＃３に対して行われる。そのため、ロケーション＃１についてのビジターリンクはロケーション＃３を示す。第２に、ロケーション＃３に記憶されたデータは、もし時間があれば、第１のエキストラページに移動される。そのため、＃３についてのビジターリンクは第１のエキストラページを示す。
【０１６４】
スワッピングページ
スワッピングはバックグラウンドにおいて実行される（システムがアイドリングしている間）。プロセスは２つの段階に分割される。第１に、すべてのメインエリアページは適当な場所にスワップされる。第２に、リダイレクトが生じないように、エキストラページは相互間でスワップされる。このことは、ヒストリーマップ中を進んで行くと、対応するエキストラページもシーケンシャル順となることを保証する。これは書き込みのシーケンスをヒストリーバッファへ迂回させる場合最適化される。
【０１６５】
先の例は、メインイメージにいかに書き込むかを示している。次に、ページスワッピングが検討される。図１９Ｇにおいて、いくらかのフリータイムが検出され、エンジンがメインエリアを認識することを開始すると仮定する。このアプローチは一般にマップを通して進むことであり、それらが実際に属するところにページをスワップバックすることである。図１９において処理されたマップエントリはロケーション＃１についてのものである。マップは、ロケーション＃１のデータが第１のエキストラページに見いだされることを示している。このデータは実際にロケーション＃１にあるものとスワップされる。マップのビジターリンクの後は、実際にロケーション＃１にある第２のエキストラページからのデータであることがわかる（図１９Ｆから）。
【０１６６】
そのため、メインページのスワップを別のものと行うため、４つのステップがある。
１．ロケーション＃１のデータがロケーション＃１にあることを示すためにマップエントリを変える。これはリダイレクトとビジターリンクをナルにセットすることによってなされる。
【０１６７】
２．それから、ロケーション＃１、すなわち第２のエキストラページを訪れているデータに関連したＨＰＤに行き、そのスワップリンクを、その訪問しているデータがスワップされた場所を示す様に変更する。これは、ロケーション＃１が元々迂回された場所、すなわち第１のエキストラページである。もしこのロケーションがメインエリアに有ったならば、そのマップリンクは更新を求めるであろう。
【０１６８】
３．第１のエキストラページはロケーション＃１のデータを含んでいる。しかし、もしそれがメインエリアにあったとすれば、実際はそうでなかったが、そのビジターリンクを第２のエキストラページにセットする（第１のエキストラページに移動しているロケーション＃１の当初のビジター）。もちろん、もしビジターリンク更新がそれ自身にリンクする結果となると、リンクは単にクリアされる。しかし、この後者のケースは先のステップにおいてすでに扱われており、更新はスキップされる。
【０１６９】
４．次にマップが更新される。これは遷移マップであり、変更され安定したマップではないことに注意すべきである。実際のデータ「Ｄ１ｂ」と「ｄ３ｂ」はスワップされ、遷移マップは結局は安定化される。
マップデータのフラッシングとディスクアクセスを最適化するため、スワップアルゴリズムはかなり大きなスワップシリーズをバッファし、かつディスクアクセスを最適化しなければならない。言い換えれば、もしロケーション＃１を＃１０とスワッピングし、ロケーション＃２を＃１１とスワッピングするなら、ディスクヘッドムーブメントを減少させる意味で、両方のスワップ、＃１と＃２と＃１０と＃１１を同時に行うことは更に効率的である。これは低レベルスワップセクションにおいて詳細に検討する。
【０１７０】
図１９Ｈにおいて、ロケーション＃２についてのスワッピングが処理される。これはメインマップについてすべてのリンクのクリーニングをもたらし、すべてのメインエリアデータはその望みの位置にある。求められる唯一のさらなるスワッピングはエキストラページエリアにある。再組織化することの利点は、ヒストリックページはセーブされているので、それらは次々と互いにディスク上に配置されることである。これはディスク転送（シーク）時間を減ずる。
【０１７１】
スワップアルゴリズムの別の例として、図１９Ｅの書き込み後の状態を見てみる。図１９Ｊにおいて、「ｄ１ｄ」はロケーション＃１に書き込まれる。図１９Ｋはロケーション＃１にスワップを実行した結果を示している。図１９Ｋから続いて、図１９Ｌにおいて、ロケーション＃２は適所にスワップバックされる。ロケーション＃３の適所へのスワップバックの結果は、第１と第２のエキストラページが「Ｄ１ｂ」と「ｄ３ｂ」を含んでいることを除いて図１９Ｉとほぼ同じである。
【０１７２】
スワップ操作は順番に係わらずそれを求めるロケーションで実行することができる。これを説明するために、図１９Ｊの最終状態を参照する。図１９Ｍはロケーション＃２を適所にスワッピングバックする効果を示している（先に、ロケーション＃１はスワップされた）。ロケーション＃１を適所にスワップバックすると、図１９Ｎとなる。そして、最後に図１９Ｏは、ロケーション＃３をスワッピングした後適所に戻ったすべてを示している。
【０１７３】
図１９Ｐにおいて、メインエリアページのみを含むスワップを設定する。これまでのすべての例は、常にメインエリアおよびエキストラエリアページを含んでいる。図１９Ｑは適所へのロケーション＃１のスワップを示す。
この時点までにおいて、書き込みとスワップメインページアルゴリズムが検討されて来た。実施されたスワッピングはメインエリアを再組織化するために用いられた。そうすることによって、２つのエリア間、即ちメインおよびエキストラページエリア間のページの一時的な交換が解決される。２つのエリアは独立となる。即ち、メインエリアは現在のものであってそして直接ＯＳによって見ることが出来るページのみを含んでいる（再マッピングはなし）。エキストラページエリアはすべてのヒストリックにセーブされたページを含んでおり、メインエリアからは何も含んでいない。この状態の例は図１９Ｈに示されている。
【０１７４】
図１９Ｈにはさらに、他のエキストラページにはかかわらず、ＨＰＤのデータがリダイレクトされていることを、ＨＰＤが未だ示している。メインエリアで達成された直接マッピング（マップはロケーション＃１がロケーション＃１にあること、等を示している）は、さらにエキストラページエリアで達成されなければならない。図１９Ｈにおいて、交換を必要とする２つのエキストラページが見られる。もし、スワッピングが単に一対のエキストラページに限定されたなら、プロセスはクリアであり、ＨＰＤを通して実行される。そしてもしＨＰＤがそのデータが別のエキストラページに位置していることを示しているなら、それらを交換する。
【０１７５】
このアプローチの欠点は、２ページより多いページが１スワップ操作に含まれることである。言い換えれば、それはクロスリンクシステムに含まれる３またはそれ以上のページのセットでありうる。これを図１９Ｒを参照して説明する。
マップの下に位置しているリターンリンクの追加に注意されたい。これらはボトム上でそれらから横切って表されたエキストラページに対応する。スワップリンクが別のエキストラページを示すＨＰＤにセットされるときはいつでも、このＨＰＤのリターンリンクはポイントバックにセットされる。このように、２つのエキストラページは互いに向き合っている。
【０１７６】
図１９Ｒにおいて、３つのメインページと３つのエキストラページが見られる。図１９Ｓにおいて、ロケーション＃１、＃２、および＃３に対しこの順序で書き込みがある。これは図１９Ｓに繋がる。図１９Ｔ、１９Ｕおよび１９Ｖにおいて、＃３、＃１および＃２への書き込みがある。終了した場合、エキストラページエリアには、ＨＰＤとそれらの各エキストラページ間の直接マッピングを回復するために必要な３つの方法のスワップが残されている。これは図２０に示されている。
【０１７７】
エキストラページエリアを再組織化するための１つのアプローチは、最初のＨＰＤで開始し、全体のつながり（チェイン）を知るまでスワップリンクを追いかけることである。残念ながら、つながり（チェイン）が多くのページ（ＨＰＤ）を含まないことの保証はなく、したがって、１つのタイムリーなステップにおいてスワップするためのシステムの能力を超える。そのため、つながり（チェイン）をより短い円形のリストに壊さなければならない。しかし、これは全体のリストをスキャンすることを含んでおり、それは一般的に多くの労力を要する。
【０１７８】
この解決は、容易に編集できるダブルリンクリストシステムを作成するリターンリンクを加えることである。エキストラページエリアスワップアルゴリズムは、ただ１つのエリアが含まれる−そのアルゴリズムはダブルリンク削除である、ものとして知られている点を除いて、メインエリアに対して使用されるものと殆ど一緒である。エキストラページエリアにおけるリンキングは、２つのエリアが独立にされたとき（メインエリアを最初に再組織化することにより）のみ終了するということを覚えておかれたい。
【０１７９】
ｍｙ＿ｌｏｃａｔｉｏｎおよびそのｍｙ＿ｄａｔａにおけるエキストラエリアページを別のエキストラページとスワップするためのアルゴリズムは、
１．マッピングデータをｍｙ＿ｏｌｄ＿ｖｉｓｉｔｏｒにおけるｍｙ＿ｌｏｃａｔｉｏｎおよびｏｔｈｅｒ＿ｌｏｃａｔｉｏｎのためにセーブする。両者（ｏｔｈｅｒ＿ｈｈｅおよびｖｉｓｉｔ＿ｈｈｅ）のためにＨＰＤを得る。スワップリンク（両者をカバーする）をクリアする。
【０１８０】
２．ｍｙ＿ｏｌｄ＿ｖｉｓｉｔｏｒはｏｔｈｅｒ＿ｌｏｃａｔｉｏｎと同じであり、このことはｍｙエキストラページにおいてｍｙ＿ｄａｔａが記憶されるページに属していたデータを意味する。そのため、スワップを行った後、他のページもまたその所望のデータを持つ。そのスワップリンク（両者をカバーする）をクリアして、同じＨＰＤに対してｏｔｈｅｒ＿ｈｈｅおよびｖｉｓｉｔ＿ｈｈｅポイントを知らせる。
【０１８１】
しかし、もしｍｙ＿ｄａｔａを持った他のページおよびそのデータを私（ビジター）が持っていたページが同じでないなら、それらのＨＰＤを調整する。その関連するエキストラページに丁度書き込まれたデータをどこに置くかを知るために他のページをセットする（そのビジターはｍｙスワップページであった）。そのデータがどこでスワップされたか知るためにｍｙビジターをセットする（ｍｙスワップページであったものに）。
【０１８２】
３．スワップを実行し、変更をセーブする。
もしｍｙ＿ｌｏｃａｔｉｏｎが次の書き込みエリアの割り当てられないゾーンにあれば、スワップステップのための最適化は動かすためにそれを減ずることである。ページが最後にこのゾーンに終わるとき、そのコンテンツは不安定であると定義されており、そのため更新は求められない。この最適化の実際の使用は、リンキングが次の書き込みエリアに存在するエキストラページエリアはありそうもないこと認識するので、最小である。例えｏｔｈｅｒ＿ｌｏｃａｔｉｏｎが次の書き込み領域にあっても、これはデータの最終的な行き先でないかもしれないので、ｏｔｈｅｒ＿ｌｏｃａｔｉｏｎへのデータの移動を廃棄することはできない。
【０１８３】
図２１において、エキストラページスワップアルゴリズムは、図１９Ｖに基づいた状況下で実行される。図２２は適所へのロケーショ＃１のスワップを示している。図２３において、適所へのロケーション＃２のスワップは、本質的にロケーション＃３のスワップも取り扱う。
ヒストリーバッファに割り当て
ここでは、エキストラページがどのように実際に割り当てられるかが述べられており、それらの有効なロケーションがメインエリアにおいて事実上一時的であることに注意する。エキストラページエリアにおける次の書き込み場所（割り当て）が使用される場合、そのとき、全ての割り当てのための次の書き込み場所を含むスイッチページを更新することが必要である。言い換えると、一つには、適当なページか又はそれをちょうど飛び越えて次の書き込み場所（割り当てることが出来ないどのページも飛び越える）を見つけるために、ＨＰＤの方を見る。一つには、ページのタイプを「使用されてない」（それ故、その内容は正式に知られない）に変更することによって割り当てを行い、次の書き込み場所に進める。次に、一つには、新しく取得したページを修正することができるように、安定したバージョンの変更部分を作ることが必要である。これは、たった１ページを得るのに多くのディスクが溢れることになる。図２４を参照のこと。
【０１８４】
次の書き込み場所に反して、次の書き込みエリアを使用するとは、自由に割り当てができる全エリアを別にしてセットするために、スイッチページの単一の更新を許容する構成である。本質的には、一度、ページが次の書き込みエリアに含まれると、その内容は、遷移的なものと見做される。それ故、安定したバージョンの観点から、このエリアにおいて割り当てできるページは、安定したＨＰＤにおけるそれらの対応するページのタイプにかかわらず、全て使用されない（使用されてない）ものとして扱われる。従って、その安定したバージョンは割り当てできるストレージのブロックを調整することができる。これは、スイッチページの簡単な単一の更新に対して、一連の割り当てを処理することが要求されているディスクフラッシングを最小のものとする遷移的な処理の間に行われる。図２５は次の書き込みエリアの概念を示す。
【０１８５】
書き込みエリアのサイズは、より大きなエリアに交換されることによって選択され、所定の移行の間にエリアに頻繁に進むことを回避するという要望によって、ほんの僅かな割り当てが要求されたけれども、より多くのヒストリー情報が、一つのステップで廃棄される。
ログされた通常データ
変更したページの元の状態をトラッキングすることに加えて、エンジンは、種々の他のデータをも追跡しなければならない。他の情報ばかりでなく、例えば、ファイルのアクティビティ（オープンとクローズ）、プログラムのアクティビティ（始動）、システムのブーツ、キー・ストローク及びマウスのアクティビティがある。エンジンは、最小限で、ヒストリーバッファ中のセーフポイントのロケーションを追跡しなければならない。ログされた通常データのページは、この必要性を支持している。これらは、普通に割り当てられたヒストリーバッファ（ヒストリック）ページの流れにミックスされるページである。
【０１８６】
ヒストリックページに関して、それらは、サーキュラーシステムがそのページを取り囲み、そして再使用するように、割り当てられない。ヒストリックページでミックスされるログされた通常データのページにおいて、種々雑多なデータをセーブするこの方法は、ヒストリックデータとほとんど同じ方法で行ったり来たりするような情報をセーブするのに良い方法である。確かに他の方法が可能である。ページ自身が廃棄される以前に、ヒストリックページについての「ノート」を早まって失うことを避けることに注意すべきである。例えば、全てのヒストリックデータを廃棄する前であり、セーフポイントがポイントのないこの全てのヒストリックデータのセーブをする後に、最も古いセーフポイントのロケーションに関する情報を廃棄することである。セーフポイントのマーカー無くして使用できない。
【０１８７】
ファイルに関して過去を調べること
時間を選択することに基づいた、ディスクのより早い状態をアクセスする能力は、「ロスト」データを取り戻すのに役立ちそして基礎の方法を提供するが、時間を選択する処理が、しばしば、通常のログ（前の説で記述された）に記憶されたファイル変更時間のような情報に基づいてなされる。実際に、全体の回復オペレーションは、シミュレートされたディスクを確立する処理を隠すかもしれない。例えば、リストが通常のログにある情報で構成されており、リストから回復するためにファイルを選択する行為は、適当にシミュレートされたディスクを作成し、ファイルをコピーし、そして、シミュレートされたディスクをクローズ（活性化しない）するステップに自動的に導くことができる。従って、ユーザは、時間を直接選択することより他の選択に基づいたヒストリック情報にアクセスすることができる。
【０１８８】
過去に間接的にインデックスする最も良い方法の一つは、ファイルネームを通すことである。例えば、先月に終わったそれらのヒストリックディスクの状態にアクセスする能力を有するユーザを考慮する。時々、この期間に、ユーザがファイルを作成したり、それを１時間使用したり、そして、そのときそれを削除したりする。ユーザが先月に何らかのポイントにシミュレートされたディスクを確立することができるが、そのファイルを回復するために、正確に何時に行ったかの知識は、通常のログに記憶されたファイルのアクティビティ情報の利用を要求する。時間に関連した通常のログの内容を現すことは、サーチ能力とともに、現在の例にあるファイルを回復するための効果的な方法をユーザに提供する。
【０１８９】
しかしながら、もはや存在しないファイルをロケーションするための追加的方法がある。この方法は、ファイルを見つけるための産業用の標準 Windous95 Explorer ユティリティともっと一致するものである。 Explorer は２つのウインドウを使用し、本質的にユーザにファイルの階層におけるレベルを通り過ぎることを許容しており、一つのウインドウは、階層の現在の拡大と階層内の場所を示し、他のものは、この場所で利用できるファイル（及び他の追加的ディレクトリ）を示している。
【０１９０】
本発明は、 Explorer の拡張を提供するものであり、ユーザが、特定のファイル上でライトクリック（right click ）することができ、ファイルの旧バージョンのリストを調べるオプションを持つことができる。このリストは、通常のログをスキャンすることによって構成される。しかしながら、そのアプローチは、ファイルが削除されてしまったり、新たにネームを付け替えたり、又は移動させたり、選択することができいようにされているケースを扱えない。
【０１９１】
追加的方法は、 Explorer を通して調べることができる特別な新しいタイプの「ディスク」を作り出すことであり、このディスクは、如何なる標準の物理的ハードディスクに該当しないばかりでなく、その内容がファイルアクティビティに基づいて発生される代わりに、通常のログにエントリーするものである。この特別のディスクのためのファイルの階層は、通常のログに現在発見されている全ての関連ファイルのエントリーを結合し、それらを分類することによって形成される。複写は除かれるが、それらの関連したリファレンスタイム（即ち、ファイルがちょうど良いときに存在した場合である）は記録され、旧バージョンのリストを提出するのに使われており、そのようにリクエストされている。この特別なディスクは、その基礎とする実ディスクのようにほぼ見え、階層内のあるロケーションにファイルがいつか存在した場合、そのファイルがセーブされたヒストリックディスクの状態を使用してまだ取り戻されることを提供でき、そのファイルは、その後に削除され、新しいネームを付け替えたり、又は移動されたりされることにかかわらず、存在したままである。要約すると、この特別なディスクは、 Explorer によって提供されているように、階層の形態による別のディスクに関してファイル及びディレクトリーの利用できる全ての旧バージョンを示している。
【０１９２】
ユーザが過去から取り戻せるファイルを選択できることは有益であり、そしてシミュレートされたディスク上のファイルのどれかを参照し、又はシミュレートされたディスクから一時的なディレクトリにコピーして、ファイルを見るための適当なアプリケーションを自動的に開始することも有益であることに注意すべきである（この一時的なディレクトリの内容が、もはや使用されない場合には、最後に自動的に除去される）。これは、ユーザがファイルの旧バージョンの存在を知ることができるばかりでく、見たファイルが自動的に廃棄されるとき、実際に正式にそのファイルを取り戻すことなく、その内容を見ることができる。それ故、取り戻されるという面から見たファイルの存在はユーザから隠れて見えない、つまりユーザはディスク上で見たファイルを管理する必要がない。
【０１９３】
シミュレートされたイメージ
シミュレートされたディスクのイメージは、早い時間からＯＳの目に見えるディスクのデータに最初に相当する一つである。ユーザは、典型的に、簡単な他のディスクドライブとしてＯＳを通して、シミュレートされたイメージを見ることができる。一度確立されると、ユーザは、そのシミュレートされたイメージを書き込むことができ、やがては、変更することによって、分岐（fork）を効果的に作成できる。結局、シミュレートされたイメージが廃棄されると、如何なる変更も失われる。
【０１９４】
シミュレートされたディスクのイメージを確立する方法は、現在の時間でスタートするＨＰＤを通して動かすことであり、所望のリバージョンタイム（セーフポイント）まで戻る。各ＨＰＤについて、対応するエントリーがシミュレートされたマップに加えられ、従って、元の状態に現在のロケーションをマップする。実際上、処理された各ＨＰＤは、変更されていない。エントリーがシミュレートされたマップ中に既に存在すると、重ね書きとなる。このケースは、所望のリバージョンポイントから多数回変更さている所定のロケーションを示している。マップが最初に構築されるとき、その全てのエントリーが元のデータと関連しているとして知らされる。続いて、データがシミュレートされたディスクに書き込まれる場合、そのとき、第２のタイプのエントリーがマップに加えられる。初期状態からの差異をホールドするページにポイントされる。
【０１９５】
シミュレートされたディスクのイメージを確立する第２の要求が現在のシミュレートされたディスクのイメージより早い時間を指定し、現在のシミュレートされたディスクのイメージに書き込まれるものが何もない場合、現在のシミュレートされたイメージ（マップ）からウォークバック（walk back ）をスタートできる。これは、この仕事が既に間近かにたやすい場合には、現在の時間からスタートすることと、現在のシミュレートされたイメージの時間まで構築することとを避ける。シミュレートされたイメージの読み出し及び書き込みを扱うためのアルゴリズムは、前に参照された米国出願No.08/924798に説明されている。
【０１９６】
リバージョン及び遅延されたムーブマップ
ディスクを前の状態に戻す普通の方法は、シミュレートされたドライブ上に前の状態を確立すること、いくらか更に要望された調整をすること、シミュレートされたドライブをカレント（実際上、元のカレント状態をセーブする）に「コピーすること」を含む。あるケースでは、リバージョンより前に元のカレント状態を直にセーブすることを許容するには、ヒストリーバッファ中に十分なスペースがない。この特別なケースは、後で議論される。
【０１９７】
カレントとシミュレートされたイメージとの間に差異がない場合、要求は無視される。特有の状態は、ログ関連の考察のために戻される。図２６Ａ乃至２６Ｈは、メインエリアに一つのロケーションがあるディスクでのアクティビティを示す。図２６Ａは、ロケーション＃１がマップされる初期状態を示し、値Ｈ１を含む。図２６Ｂでは、新しい値Ｎ１がロケーション＃１に書き込まれ、スワッピング処理が何でもみなその所望のロケーションに入力することを実行する。図２６Ｃでは、Ｈ１に戻るリバージョンが生じ、基本的にロケーション＃１にＨ１をコピーすることを含んでいる。Ｈ１の新しいコピーは、値が同一であっても、Ｈ２に示される。フレームＤ乃至Ｈはこの繰り返し処理を示し、Ｈ２及びＨ３と名付けられたＨ１の２つの追加的コピーを実際上作成し、ともにハイライトされる。
【０１９８】
重要なリバージョンを実行する場合、つまり、多くのページが影響を受けるものの一つであるが、セーブされた古い元の状態を複写し、それらをカレントにすることに多くの時間が費やされる。カレントにシミュレートされたマップをコピーすることにおいて、ある量のオーバーヘッドがあり、実際にはセーブされた状態を複写することに多くの時間が費やされる。マッピングシステムが使用されるけれども、データが異なるロケーション（メインエリア内にある）において有効であることを必要とするから、その複写が実行されなければならない。さらに、リバージョンを確立するのに使用されるヒストリックデータは、いくらか遅れた時間にヒストリーバッファの末尾に落ちる（そして廃棄される）。それ故、複写が存在しなければならない。しかしながら、システムが使用される前の複写による長い遅延を避けるために、別の「遅延されたムーブマップ」が導入される。
【０１９９】
ネームを含むとき、この新しいマップは、実際には移動を実行せずに、ディスク上にデータを移動することを準備する。リバージョンと関連したこのマップを使用することについて魅力的なことは、図２６のシーケンスに示されるように、そのリバージョンが、複写と最後のスワップとを共に含むことである。遅延されたムーブマップの使用は、スワップ処理に複写処理を合体する。例えば、ＡをＢに移動する代わりに、ＢをＣとスワップすると、このスワップは、Ｂの代わりにＡから簡単に読むことができる。さらに、その処理は、バックグラウンド処理となり、ユーザに対しより早い応答をもたらす。
【０２００】
マップされた各ロケーションに関し、遅延されたムーブマップのエントリーは２つのフィールドを有する。エントリーは読み出し側か書き込み側かのどちらかのタイプに分類される。読み出し側のケースでは、ソースロケーションは、読み出しに関し、データの真実のロケーションを示す。リンクフィールドは、論理的にソースロケーションの値を有する全てのロケーションに（実際の複写がまだ実行されていないけれども）関連付けられる。読み出し側のエントリーに書き込みが生じると、そのとき廃棄される。これはそれをリンクしないことを含む。マップへのキーとしてそのソースロケーションのフィールドを使用して、書き換えられたページに配置されたリストヘッダが発見され、これを参照するエントリーが識別され、そして最後にマッピングエントリーがリンクされず、廃棄される。図２７を参照。
【０２０１】
書き込み側のケースは、ページを表し、その内容は、他のページについて読み出しを処理するのに参照されるものである。読み出しがそのようなページに実行される場合、マッピングは効果がない。しかしながら、書き込みが書き込み側ページに実行されることについてである場合、そのページの内容は、リンクされたページ全てに最初に書き込まれなければならない。複写が実行された後、読み出し側及び書き込み側のエントリーは廃棄される。
【０２０２】
普通は、ヒストリックページに相当する書き込み側エントリーを期待し、その内容は、マップを使用して新しいページに「コピー」されることである。最後には、このヒストリックページは、サーキュラー・ヒストリーバッファの末尾に落ち、そして再使用され、その時間に、その値が変更される。その変更の直前に、元の値が読み出され、参照される読み出し側エントリーの全てに書き込まれる。書き込み側エントリーの読み出しのケースは、例えば、シミュレートされたドライブがページを参照することを確立されると生じる。
【０２０３】
再び、遅延されたムーブマップの意図は、それが、リバージョンの後で、標準のスワップ処理の役割として次第に除去されることである。そのように、リバージョンと関連した複写のオーバーヘッドは減らされ、そして遅延される。しかしながら、結果的に、影響を受けたデータがアクセスされるか、そして／又は修正される以前に、スワップ処理は実行されず、そのマップは、事態を整頓しておき、そして要求されてますます増加する複写を実行する。
【０２０４】
バックグラウンドの再編成は、一般に、遅延されたムーブマップを全くないか又は全くない近さまで減らす。最後のバックグラウンドのフラッシュ処理は、いかなるマッピングも、結局除去されることを意味する。
図２６Ｉ乃至２６Ｍは図２６Ｃに続くものであり、それらはいかなるスワップ処理（又は遅延されたムーブマップの他のリソリューション）をしない多数のリバージョンがマップの方法によってページに積み上げられた（一つより多い）書き直しを生じる状態を説明する。図２６Ｃから図２６Ｄあるいはそれを越えて、その進行は、遅延されたムーブマップを使うポイントが解決されるスワップ処理を含む。遅延されたムーブマップのリンキングは、図２６のシーケンス中に突進線と矢印によって代表される。
【０２０５】
マップ中でだけ実行されたリバージョンは、実際のデータ複写より少なくとも一桁早いものであるべきである。その理由は、それぞれ遅延されたマップの低レベルのノードが約１０００ページをマップし、また低レベルのノード当たりにアクセスされた少なくとも１０ページの所定の密集をマップし、複写処理が１０回ほど早くなる。結局、スワップは、実行されて、その全部の影響が二重実行より少ないという精神を留めておくべきである（スワップはコピーより強烈である）。しかしながら、マップは、バックグラウンドで実行される全ての仕事を許容し、これは、あるいは、より重要な特徴である。
【０２０６】
遅延されたムーブマップにマッピングすることを加え、ソースが既にマップされていることを見つけるケースにおいて、簡単にソースのリンクリストに付加する。この状況は、多くのリバージョンが最初のマッピングを巻き戻すための時間を有することなく生じる場合に起こる。
所定のリンクリストは、リバージョン当たり一つのエントリーより多いと決して成長しない。本質的に、これは、所定のロケーションに関する変更が、前の時間に同じロケーションに表されたページに対してであるからである。ロケーションは、ユーザが見るように、別のロケーションに表れたページに決して書き換えられない。
【０２０７】
リバージョンおいて、ソースが、シミュレートされたディスクイメージにいつもあり、変更されたページが新しいページにあるから、そして同じロケーションを共に変更するから、その２つの間でリンクを付加されるのは一つだけである。それ故、シミュレートされたディスクが、二度同じページを参照することがでず、新しいリバージョン内でこれが発生することができない場合、新しいリバージョン内に一つのエントリーより多く書き込み側リンクリストを拡張することができない。言い換えると、Ａが独自にページＡｐを参照し、Ｂが独自にページＢｐを参照し、そしてリバージョン内でＡがＢに変更されるだけである場合、リンクリストの拡張は、コントロールされる。図２８を参照。
【０２０８】
この最大のリスト拡張の仮定は、最も悪いケースであると考えて、書き込み側エントリーが重ね書きされるとき、実行されなければならない多くの遅延されたムーブを処理する低レベルのスワップによって使用される。
リバージョンを実行するための特別なコアアルゴリズムは、シミュレートされたマップを通して循環することであり、現在のイメージに各エントリーを「コピー」することである。これは、実際上、メインイメージに書き込むことであるから、所望されるなら、標準の処理は、リバージョンの不実行を可能にする。コピー処理は、普通、遅延されたムーブマップを使用して行われる。
【０２０９】
特別なケースのリバージョン
リバージョンを実行する上で複雑なファクタは、データの複写が多くリバージョンと干渉するときに発生する。エキストラページの大部分が所望の状態の復帰に含まれる場所の例をとりあげる。この処理ではメインイメージにこの情報をコピーするために呼び出し、事実上、メインエリアの元の状態の全てをエキストラページエリアにコピーする。もしデータの実際のコピーがリバージョン処理の間に実行されるなら、リバージョンを完了するために必要とされるデータの損失のポテンシャルが存在する。言い換えれば、エンジンはヒストリーバッファの一部を読み出し他に書き込むので、バッファのその部分は、その部分がメインイメージに移される以前に再使用されるだろう。図２９を参照のこと。
【０２１０】
図３０は、リバージョンに含まれるデータの量が、エキストラページエリアの比較的小さい部分である場所のより典型的な状況を図示する。リバージョンは、ヒストリーエリアへの通常の書込みを含む複写の処理である。エキストラページエリアが複写をするには小さすぎる従来の場所では、特別な場合の処理が必要とされる。
【０２１１】
リバージョン処理は、他の順番、例えば、ロケーションの順に対抗するように、ヒストリーバッファにて年代順にページを処理することを考慮しなければならない。これは、ＨＰＤがその内容が処理されるまで再使用されないことを保証する。この処理をクラッシュプルーフさせるように注意しなければならない。リバージョン以前の初期状態がリバージョンの一部として無視されるので、クラッシュ後の回復はリバージョンを完了しなければならない。この場合、必要なデータが失われたので、以前のリバージョン(pre-reversion) 状態に戻ることはできない。
【０２１２】
この問題を解消するために基本的な２つのアプローチがある。第１に、リバージョンは単純に２つの状態、即ち、メイン及びシミュレーテッドマップにより表される元の現状及び所望の状態、を認識する。リバージョン処理はスイッチングの役割を含む。このアプローチの下流側は、現状が失われる以前の全ての状態である。しかしながら、ヒストリーバッファの大部分が所望のリバージョンを実行することを必要としている場所の状況に固有のものである。マップ上で全ての仕事を実行することは、クラッシュプルーフの処理を可能にする。リバージョン前に戻るかリバージョン後に戻るかである。マップはエキストラページエリアが無くても複写される。
【０２１３】
第２のアプローチは、ＨＰＤを経て注意深く循環することであり、まだ処理されていない重ね書きデータが決してないような方法で「コピー」を行う。エキストラページエリアの大部分が含まれ、含まれない部分はコピー処理のために最初に利用されるので、このアプローチは第１のアプローチに効果的に同等な結果を生じる。しかしながら、この処理は実際にユーザのデータを動かし、従って、多くの時間を必要とするはずである。一方、マップを調整し、バックグランド（スワップ（ＳＷＡＰ））にて生じる実際の動きを可能にすることは、より速いユーザレスポンスを生む。
【０２１４】
従って、第２のアプローチには利点がない。両方の場合において、現在及びシミュレーテッド（リバージョンされた）イメージが交換される。一連のリバージョンは「アンドー」（ｕｎｄｏ）を実行することができるが、しかしこの処理は時間的にさらなるリバージョンに進むことはできない。従って、より速いという理由から第１のアプローチが推奨される。
【０２１５】
図３１Ａ乃至図３１Ｄは、現在及びシミュレーテッドイメージが交換された場所のマップベースリバージョン及び捨てられた全てのヒストリーデータ（６及び８）を図示する。現在のイメージマップは維持されないが、必要とされた他のリバージョンが再構築されることに注目すべきである。
最初に、図３１Ａにおいて、現在のイメージマップは１，３，５及び４のディスクイメージをユーザに表す。シミュレーテッドイメージは２，７，５及び４を表す。「ｎ」はシミュレーテッドマップに書かれたページへのリンクを表す。現在のイメージマップを減らすためにリバージョンを開始する以前にページを並び換える(re-ordering) スワップ処理を必要とするが、これは時間的に集中するものであり、他の並び換えがリバージョンの後に実行される。リバージョンを再マッピング無しで実行することはアルゴリズムとしては容易であるが、ストレートな再マッピングにおいて如何なる遅延も避け、平凡でない現在のイメージマップに基づいてリバージョンを可能にすることが最良である。平凡なマッピングは再マッピングがないものである。
【０２１６】
図３１Ｂは、元のシミュレーテッドマップを示す新たに確立された現在のイメージマップを示す。図３１Ｂに示すリンクは、通常の「スワップ」処理を達成するためには、如何にしてページが交換されねばならないかを示す。図３１Ｃはスワッピングの結果を示し、最終的に、図３１Ｄはエキストラページエリアにパックされたヒストリーデータを示す。
【０２１７】
このシーケンスで実証された４つのキー処理がある。
１）現在及びシミュレーテッドマップを新たなマップに結合し、
２）スワップ処理をサポートするためにページ間のリンクを確立し、
３）可能な再リバージョンをサポートするために初期化し、そして
４）エキストラページエリア内でヒストリーデータをパックする。
【０２１８】
パッキングは、元の現在イメージと関連したページの再使用を要求する以前に、使用可能な未使用のエキストラページを最大化するために実行される。そのようなページが再循環されるやいなや、元の現在イメージへのリバージョンは最早可能ではない。パッキング処理は、スワップ処理と異なり実際に動くＨＰＤ及びその関連データを含むことに注目すべきである。スワップ処理において、ＨＰＤはその場所に留まり、データページのみが移動される。
【０２１９】
パッキングの必要性は、リバージョンがステップオーバーしそうな時間間隔の間に、同じロケーションが多重の回数で書かれるときに起こる。従って、この時間間隔に対応するエキストラページエリアは、同じページの多重バージョンを含む。リバージョンの後に２つの状態が保持されるので、同じページの多重バージョンにより表されるこれらの中間状態は捨てられる。ヒストリーバッファにおけるこれらの存在は、パッキングにより回復された未使用の穴を表す。パッキングが実行されなかったときは、元の現在イメージと関連した第１及び最後のエキストラページの数は不必要に大きくなる。
【０２２０】
リバージョンを如何にして実行するかを決める方法は、時間的（通常）に進んでデータをコピーすることにより、又は特別な場合の論理により、如何に多くのデータが通常の状況の下で進んでコピーされるべきであるかを最初に評価することである。これはシミュレーテッドマップにより能動的に表される効果的なページの数である。次は、シミュレーテッドマップの表示に含まれるデータに到達する以前に書込みが可能なエキストラページアリアのサイズを決定しなければならない。重ね書きページの元の状態をセーブするためのスペースとして十分であれば、通常のリバージョンが実行され、他の場合は特別な場合の論理が使用される。
【０２２１】
オールウェイズメソッド（Ａｌｗａｙｓ ｍｅｔｈｏｄ）
ディスクのヒストリー状態をセーブするムーブ（Ｍｏｖｅ），ダイバート（Ｄｉｖｅｒｔ），テンプ（Ｔｅｍｐ）メソッドの中心的な技術は、ＯＳにより読み出され書き込まれたデータの性質の知識を特に必要としない。時間的な全ての方法は、データがＯＳにより期待された場所に位置される状態にディスクを戻す。セーブされたヒストリーデータ及び関連したオーバヘッドは、ディスク上の前もって割り当てられた「オフ−ツー−サイド」(off-to-the-side) エリアに維持される。
【０２２２】
オールウェイズメソッドは、幾つかの基本的な知識が、ディスク上のデータの構成に関してＯＳにより提供されると仮定する３つの従来例から分離される。この知識と共に、オールウェイズメソッドのエンジンは、データがディスク上の置かれる場所を実際に決める役割を引き継ぐ。
この新たな役割のメインな掛かり合いは、エンジンが伝統的なデ・フラグメンテーション(de-fragmentation)問題をカバーしなければならないことである。即ち、ＯＳは、所定のファイルのセットの利用可能なディスクロケーションのプールから割り当てるので、これらのロケーションが連続的である見込みが、時間とともに減少する。従って、ファイルを読み出し又は書き込むときに、その内容がディスク上でまき散らされるならば、ファイルの内容が全て近くに位置されるときとは反対に、全体のアクセス時間は劇的に増大する。
【０２２３】
ＯＳにより提供される情報
物理的に近いディスクロケーションに関する情報は、デ・アロケイト(de-allocated)されたものと同様に、ＯＳにより周期的に提供される。情報は、中間プログラムによりＯＳから間接的に来る。この中間プログラムは、例えば、ＯＳディレクトリを走査し、ディスク割り当て構成はそれらを最後のスキャンでなされたノートと比較し、その差を適当に進める。
【０２２４】
１．近くにあるべきロケーションのセット〔ｌｏｃ ｉｄ，．．〕，．．
２．デ・アロケイトされたロケーションのセット〔ｌｏｃ ｉｄ，．．〕，．．
情報は、ディスクアクセスから何が推論されたかと同様に、特定された最後ののものに基づいて立てられる（例えば、ＯＳにより重ね書きされた、以前のデ・アロケイトされたページ）。最初に、全てのディスクロケーションは利用可能と仮定される（ＯＳによりデ・アロケイトされた）。幾つかの条件の下で、エンジンは、全ての隣接及びデ・アロケイトされた情報が既知の状態からの増加方向の更新の代わりに、再供給されることを要求する。
【０２２５】
システムが運用されると、隣接情報は日付が与えられ、最適な構成を反映していないことが認められる。この情報がディスクを最適化するために使用されるので、最も悪い誤った隣接情報が、非最適性能に導かれる。誤った隣接情報の割合が比較的小さい限り、性能に与えるインパクトは一般的に小さい。
利点と欠点
このエンジンは、エンジン自身のマッピングシステムに単なる参照キーとしてＯＳにより供給されたディスクロケーションを処理することにより他の方法から飛躍している。ＯＳにより書かれたデータを、直ちに又は結果的に、そのロケーションで幾つかの特定なロケーションに置く試みはない。例外として、エンジンが取り去られ、ＯＳがディスクの直接制御を回復する場合である。ディスクロケーションを発生したＯＳはロケーションのキーとして参照される。
【０２２６】
以前の方法がディスク上のデータの移動をＯＳにより期待した以外のロケーションに避けた３つのメインな理由がある。第１はディスクをアクセスする読み出し側にオーバヘッドを加える処理である（オールウェイズメソッドエンジンにおいて、再マッピングは通常要求される）。第２の理由は、ＯＳ（又は関連したデ・フラグメンティング・ユウティリティ）が提供されたロケーションにてデータを置くためのよい理由を持つという仮定である。そして、第３に、ディスク上に割り当てを再配置することにより、マップされない状態に戻すことはより多くの時間を消費する。この第３の理由への微妙な態様は心理学的である。ユーザは、ディスク上にそのデータを「再配置」しそのプログラムがデータをアクセスするために運用されることを必要とするソフトウェアプログラムを懸念するだろう。
【０２２７】
常に再マッピングを回避するための理由に関して、この方法は最初の２つをまともにアドレスする。再マッピングによる読み出しアクセスオーバヘッドを最小にするためにキャッシングを採用する。ディスクを最適に構成する責任は、案内情報を提供するＯＳとともにエンジンに移される。
ＯＳにより直接的には有用でないフォームにて、ディスクを長期間置くことについて、そして、直接的に有用となるための著しい努力をすることについては、エンジンを迅速に使用不可にする必要のあるこれらのユーザに対して現実的である。多分、彼らはディスクを直接アクセスするソフトウェアを運用することを望む（例えば、エンジンによりサポートされない他のＯＳ）。一方、それはより心理学的でもあるだろう。人々は、それらのデータをアクセスするために固有に運用する他のプログラム（エンジン）を持つことを欲しない。「何かが悪くなったか？」は典型的な質問である。一方、エンジンの目的は、事態が悪化した状況からの回復に尽力することであり、これらの場合、事態をより悪化させないことを望むものである。
【０２２８】
このエンジンの利点は、５つにまとめられる。第１に、エンジンはしばしばディスク上の比較的に最終的に残ったスポットに直接データを書き込み、従って、如何なるスワッピングを回避する。テンプメソッド(Temp Method) はユーザの可視的な性能の下落を避けるために管理するとしても、スワッピングはディスクアクセスの全体に意味のあるように加えられる。第２に、デ・フラグメンティングは自動的に実行される。第３に、全てのＯＳの割り当てられないディスクスペースは、ヒストリー状態を保持するために使用される。エンジンはヒストリー情報を格納するためにディスクスペースの最小量を持つが、割り当てられない記憶部分を使用するための性能は時間的に戻ってユーザの到達を大いに増大する。大抵のユーザはそのディスク上の自由なスペースについて重要な量をもっており、他の理由がなければ、実質的にディスクを満たすことは智恵のないことである（オーバフローすることは容易であるので）。
【０２２９】
第４の利点は、エンジンはＯＳとの間で少ないインタフェースを持つことであり、より容易に適合し、種々のオペレーティングシステムから絶縁されることである。そして、第５に、エンジンは、より深いフラグメンテーションの状態に陥ることなく、より一定なディスク書込み作用の下で保持しようとする。ファイルサイズに関連して、もし、その大きな連続的なセクションが重ね書きされるならば、エンジンはディスク上でこれらを最適に割り当てる。もしファイルの小さなランダムセクションが変形されたならば、アクセスの性質は既に非連続的であり、ファイルをフラグメントすることは性能上のインパクトを少なくする。テンプメソッドを参照し、深いフラグメンテーションの議論に関心が持たれる。
【０２３０】
所望のロケーションマップ
図３２はＯＳからエンジンを経てディスクドライブへ如何にしてディスクリードアクセスを動かすかを示す。ＯＳはファイルに関連したロケーションのリードを開始する。エンジン無しで、これは所望のデータのディスク上のロケーションである。しかしながら、エンジンを使用するときに、このロケーションは単純に参照キーである。エンジンはこのロケーションを参照し、実際に割り当てられた場所を決定する。この所望のロケーションは一時的に再マッピングするときを示す現在のイメージマップを経て運用される。ディスクは最終的にアクセスされる。
【０２３１】
エンジンにおける所望のロケーションマップの役割は、実際に割り当てられた場所（所望のロケーション）へＯＳにより特定されたようにロケーションをマップすることである。この段階がすぎると、エンジンは、他の方向への向き直しを許容する現在のイメージマップへの提供に際してテンプメソッドから借用する。この向き直しは、種々の理由で、所望のロケーションが得られずにそれによりデータが他のロケーションに格納されるときに生じる。従って、所望のロケーションマップは、所定のデ・フラグメンテーション及び他の関連してデータが最適にロケーションされるべき場所は何処かを反映し、現在のイメージマップは必要性と瞬間的な実際の構成を反映する。
【０２３２】
二重マップシステムのエンジンの使用は非常に強力である。ディスク上のデータの迅速な主要な再構成を可能にし、従って、作業を継続するためのユーザの能力との相互干渉を最少にする。最初に所望のロケーションマップを使用して論理的な「ムーブ」データのみにより即時性が達成される。ムーブは実際にディスクに行きデータを動かすよりむしろマップを調整することにより達成される。マップの変更は、実際にディスクデータを動かすより速く多くの回数ある。許容されると、ユーザは、論理的なムーブにより如何なる性能の獲得も実現しない。ディスクヘッドは、不適切に構成されたデータをピックアップするために遠くかつ広く進行する。しかしながら、フレームワークはバックグランドにおいてインクリメントしながらより最適な構成に移ろうとする。
【０２３３】
二重マッピングはディスク上のデータを実際に動かすことなく、所望のロケーションマップに変更することが可能である。第２の現在のイメージマップは実際にデータを動かすより速く多くの回数調整され、この第２の調整は所望のロケーションマップへの変更を補償することができる。従って、例えば、マップを変更する以前に、ＯＳはディスクロケーションＹのデータに関連するロケーションキーＸに存在する（図３３Ａ）。このデータへの全体的なアクセスは、ロケーションＺにあるときにより良く達成されることが決定される。将来の参照をＺに指向させるためにデータを動かしＯＳを要求するが、これは時間的な集中であり、従ってユーザを遅延させる。代わりに、所望のロケーションマップは、ロケーションキーＸへのＯＳによるいずれの参照も、実際にＺであることを示すように調整される。同時に、データは実際にＺではないので、現在のイメージマップは、一時的にＺに対するデータが実際にＹにおけるものであることを示すように調整される（図３３Ｂ）。しかる後、バックグランドにおいて、エンジンは、結果的にデータをＺに移動し、現在のイメージマッピングは取り除かれる（図３３Ｃ）。
【０２３４】
シミュレーテッドドライブを経て時間的に戻ってアクセスするときに、所望のロケーションマップ及びブロックマップは回復されねばならないことに注目すべきである。これらのマップへの変更は、ゼネラルログデータ(General Logged Data) を扱う同じ機構を使用してログされる。このことは、それらが時間的に種々のポイントにあるので、それらの再創作を容易にする。
【０２３５】
ディスクのブロッキング
マネジメントオーバヘッドを別にして、ディスクは基本的に、ＯＳによって見ることができるデータと、ＯＳによって重ね書きされたデータの初期状態を表すヒストリックデータを含む。Ｔｅｍｐ法に密接に関連して、ＯＳによって見ることができるデータは現在のイメージと呼ばれ、一般的にメインページのエリアの中に位置している。ヒストリックデータは一般にエキストラページエリアの中に位置している。現在のイメージからのどのような適切なデータと一緒でも、シミュレートされたディスクを通じてＯＳは見ることができる。エンジンのマッピングの結果として、これらの「エリア」は一般に混ぜられ、物理的なディスクを横切って広げられる。
【０２３６】
エンジンの目標は、一般に、そして、メインエリアに対して、物理的に組織することであり、その結果、与えられたファイルに対応する連続するページの配置は、全てのマッピングの後で、連続的にディスク上に割り当てられる。与えられた互いに近接するディレクトリの範囲内で小さなファイルを配置することが望ましいことは少ない。言い換えれば、ＯＳからの近接する推薦に基づいて、エンジンはメインエリアを非細分化(defragment)された状態で保持しようとする。このように、ファイルを連続的に読むと、対応するページがディスク上の連続するロケーションから物理的にフェッチされる。このことにより、ディスクヘッドを動かす必要性を低減することができる。
【０２３７】
エキストラページエリアに対する目標は、一般に、循環システムの中で、年代順のヒストリックページを物理的に作り上げることである。従って、最も古いヒストリックページを再使用のために配置し、ＯＳによって新たに書かれたデータを保持すると、配置が連続したものとなる。
ディスクの全ての内容のあちこちをシフトさせるような単一の変更を行うことは望ましくない。このことが正しければ、殆どどのようなディスクの書込動作を行っても、ディスクを大規模に再編成するようになり、たとえそれがバックグランドにおいて行われたとしても満足できるものではない。従って、取り得るアプローチとしては、互いに合理的に独立したページのブロックにディスクを構成することである。このようにすれば、小さな変更は一般に、もし、それが多数であっても、ほんの小数のブロックに影響を与えるだけである。このエンジンに対して前述したものの大きな利点は、ＯＳから新たに書き込まれたデータを取込み易く、それをディスク上の相対的に活動していない最後のスポットに置くことができるということに注意されたい。
【０２３８】
ブロックの中のページ数は、ディスクヘッドのシーク（位置決め）時間に対するディスクの転送速度に重み付けを行うことによって選択される。ブロックが十分に大きければ、１つのブロックを読み込んでから他のブロックへジャンプするために追加された時間の量は、２つのブロックからデータを読み出すための時間と比較して相対的に小さい。他方では、ブロックの中でページを処理する時にシフトされなければならないデータ量を低減するために、最小で適切なブロックサイズを使用することが最良である。更に、小さなブロックサイズは、ＲＡＭの中のキャッシングブロックの処理を促進する。
【０２３９】
エンジンには４つの主要なブロックタイプがある。メインエリアブロックは、ＯＳが一般に見ることができるページだけを含む。エキストラページエリアブロックは、ヒストリックページだけを含む。１つのＣＴＥＸブロックは、かつては１つのメインエリアブロックであったが、現在はエキストラページエリアブロックになる過程にあるものである。ＣＴＥＸはConverting To EXtra ページを意味している。ＣＴＭＡブロックはＣＴＥＸブロックと反対のものである。そのページはエキストラからメインエリアページへの変換過程の中にある。
【０２４０】
４つの他のブロックタイプが存在する。未使用タイプは書き込まれる前に常に記憶装置と遣り取りを行う。オーバヘッドタイプはエンジンの内部（オーバヘッド）にデータを保持するようにデータを配置する。ページがマッピングを要求しない特別なメインエリアダイレクトブロックがある。それゆえに、このようなブロックにおける読み出しアクセスは、所望のロケーション、現在のイメージ、或いは遅延移動マップ(delayed-move map)のチェックを受けない。未使用ページを備えた特別なＣＴＥＸブロックは、未使用ページが交換され、セーフポイントにおける統合の一部としてＣＴＥＸブロックに入るという状況を支持する。
【０２４１】
ブロックタイプ
1. メインエリアブロック
2. エキストラベージエリアブロック
3. ＣＴＥＸブロック
4. ＣＴＭＡブロック
5, 未使用ブロック
6. オーバヘッドブロック
7. メインエリアブロック，ダイレクト
8. ＣＴＥＸブロック，未使用ページを備える
ディスクに記憶されたエンジンの種々の内部データ構造の配置は、異なるオーバヘッドブロックのセットからできており、各セットは与えられた固定サイズのデータ構造に対応している。それゆえに、オーバヘッドブロックの各セットは、固定サイズエントリのアレイのように管理される。ビットマップはエントリが可能であるか、又は使用中であるかどうかを示す。サイズを分割することにより、こま切れ的な未使用領域の発生を防止することができる。与えられたセットの中の多くとも２つのブロックは、両者が半分満たされた状態を下回った時に結合されるべきであり、この結果、ブロックをヒストリックデータの保持に使用するように戻すことができる。要求されるオーバヘッドブロックの最大数は計算されるべきであり、エキストラページエリアブロック用に、対応する最小限の数のブロックが用意されるべきである。このことから、オーバヘッドブロックが得られ、最小限の所有が確立されることにより、オーバヘッドブロックが必要な時に常に使用可能であることが分かる。
【０２４２】
図３４は、４つの重要な役割を交替で果たすブロック間の関係を示すものである。ブロックタイプは一緒にグループ化されて集合的に示されているが、実際にはブロックタイプはディスク上では混合されている。グループ化は、ポインタのテーブルのような非物理的手段を通じて確立されている。ブロックのページの中の「Ｍ」はメインエリアデータ（ＯＳで見られる）を示しており、「Ｘ」はヒストリックを示しており、「−」は未使用ページを示している。
【０２４３】
エキストラページブロックの配置の順番は、ディスク上のブロックの実際の順番に対応することが望ましい。従って、もし非常に大きな量のデータが書き込まれた場合は、（ブロックの範囲内で）メインエリアページが（ディスク上で）互いに近接して配置されるばかりでなく、ブロック自体も近接して配置される。このような最適化は望ましいが、ファイルのデータを少なくともブロックの範囲内に配置することほど重要ではない。エキストラページブロックの順番を完全なものにするためには、ヒストリックページをあちこちとスワップしなければならないかもしれない。本質的には、全てのヒストリックデータは年代順に並べられる。このことは、まさにＴｅｍｐ法によってそのヒストリックデータがどのように構成されるかを示すことに注意すべきである。しかしながら、メインエリアの配置はこのエリアから作られるが、これらは後退させられるので、ファイルはこの初期の良好な順番を保ち続けることはない。
【０２４４】
実際に、大きなファイルが配置されることがなく、それゆえに作業が無駄に終わった時に、バックグランドの中であろうとも、ヒストリックデータを再編成するために、何故に全ての作業を全て行わなければならないのかという質問が発せられなければならない。再編成が行われず、大きなファイルが実際に書き込まれるまで待機するのであれば、同じ最終的な結果を得るために、結局はバックグランドスワッピングに行き着くための近接規定に頼らざるを得ないであろう。このようにして、直ちに、大きなファイルをより最適なロケーションにできる限り書き込むために、バックグランド作業を最初に行い、それが無駄に終わることを知ることが交互に行われる。広範囲にエキストラページブロックを再編成することが有益であるようには思われない。
【０２４５】
しかしながら、ほんの少しの作業で、特別な形式の最適化が可能となる。エキストラページブロックの最後に、最後のＮ個のブロックが一緒に配置された配置ウインドウを得ることができる。このことは、それらのヒストリックコンテンツがトスされたことを伴うが、同時に、ブロックが（ブロッキングマップの中の）ポインタを使用して簡単に再配置されることになる。このようにして、最も古いＮ個のエキストラエリアブロックのウインドウが、これからＣＴＭＡブロックが形成されるように維持される。新たなブロックがこのウインドウに入り、それらの内容が捨てられるので、適切であれば、再整理による最適化が行われる。メガバイトのウインドウ、或いは、おおよそ１０個のブロックのウインドウが適切である。最終的な結果は、ディスクに大きな連続する部分を再形成することであり、このことは非細分化(de-fragmenting)において有益である。しばしばユーザーは、ファイルのセットのロケーションを定めない(de-allocate) か、或いは重ね書きして、全てを同じ物理的なエリアの中に存在するようにしてしまうので、この最適化の機会が実行されることは良いことである。この初期のグループ化は、ファイルが最初から同じ時期にかなり適切に作られた場合に起こる。
【０２４６】
このエキストラページブロックの再編成に対する１つの最終的な修正は、Ｎページのウインドウを、２つに切断されたセーフポイントまでずっと延長して増大させることができることである。このことは、与えられたセーフポイント用のヒストリックデータのセットの一部分は使用することができないからであり、その全てのページは、このセットの最初のページが取り込まれると同時に、本質的に「未使用」状態となるからである。
【０２４７】
ディスクへの書込
ＯＳがデータを重ね書きすると、新たなデータはＣＴＭＡブロックの中に位置決めされる。新たなデータは、ここの記載を避けてＣＴＭＡブロックの中の未使用ページの中に位置決めされるので、ファイルの観点からは、本質的に重ね書きされたデータを保護することになる。この保護された（ヒストリック）データが再生される(tracked) ことについて手短に論ずる。ここでは新たなデータの書き込みに焦点を当てて説明する。
【０２４８】
データとこれに関連するロケーションキーの供給に加えて、ＯＳは、書き込み時に、ファイル識別子も供給する。詳述すると、この識別子により、エンジンは異なるファイルから異なるＣＴＭＡブロックへの新たなデータを指示することができる。エンジンにより、限られた数のＣＴＭＡブロックが共存するが、これはＯＳをサポートしてＯＳが同時に限られた数のファイルに書き込みを行うためである。各ファイル用の新たなデータを異なるＣＴＭＡブロックに送ることにより、エンジンはファイルを細分化しない。多くのＣＴＭＡブロックが同時にサポートされるので、ヒストリックデータは急速に捨てられる。
【０２４９】
言い換えれば、ＣＴＭＡブロックはエキストラページブロックの数を減らし、これにより、ユーザが過去において調査することができる区域が減る。もちろんこのことは全て相関がある。もし、ブロックが５６ｋバイトで、２０個のファイルが書き込まれて同時にサポートされていると、ディスクの１メガバイトが使用される。これはギガバイトのエキストラページが存在するような場合に比べるとほんの僅かな割合である。
【０２５０】
もし、各書き込み要求に伴ってＯＳがファイル識別子を供給せず、かつ、異なるファイルからのロケーションキーのデータを識別する方法が他になければ、新たなデータは単純に１つのＣＴＭＡブロックの中のページ毎に書き込まれる。しかしながら、ファイルが一度に１つずつ書き込まれることはよくあることであり、この場合には断片化の問題は発生しない。長期的に見ると、要求により、ＯＳはファイルのレイアウト情報を供給し、これが非細分化を助けることになる。
【０２５１】
一般に、ＣＴＭＡブロックは、最も古いヒストリックデータを含んだエキストラページブロックを取込み、データを廃棄し、その部分に新たにデータを書き込んで満たすことによって作られる。ＣＴＭＡブロックが完全に満たされると、メインエリアブロックになる。図３５参照。しかしながら、初期状態ではディスクは未使用ブロックを含んでおり、このことからＣＴＭＡブロックはそれらが無くなるまでとっておかれる。
【０２５２】
ＣＴＭＡブロックを未使用プールから割り当てる時は、マッピングの最適化として、ＯＳが指定したロケーションキー、それに対してＣＴＭＡブロックが割り当てられるが、未使用ブロックの範囲内でページに対応するかどうかが検討されるべきである。もしそうであって、かつ、システムの中にページを再マッピングする方法がなければ、この未使用ブロックは割り当てられ、指示されたページが使用されるべきである。もしこのことが実行されれば、好適なロケーションマッピング、現在のイメージマッピング、或いは遅延移動マッピングは要求されない。更に、論理によって連続するＯＳの書き込みロケーションと、これらが実際にディスク上に割り当てられるロケーションとの間の１対１の関係の維持が試みられる。もしＣＴＭＡブロック全体が書き込みで満たされ、関連するディスクロケーションに対するＯＳのロケーションキーのマッピングが要求されなければ、ブロックはメインエリアブロックタイプの特別なケースである、メインエリアダイレクトブロックに変換される。これに対する読み出しアクセスが検出されると、これはブロッキングマップの使用を素早くチェックするものであるが、通常の再マッピングチェックは回避され、アクセス効率が高められる。たいていのユーザーにとっては、ハードディスクにロードされる初期データ量があり、この最適化が有効である。もちろん、どのようなデータでもダイレクトブロックの中に重ね書きすれば再マッピングとなり、従ってブロックはダイレクトの地位を失う。
【０２５３】
新たなデータが書き込まれるように、所望のロケーションマップが調整され、ＣＴＭＡブロックの中のページを伴ったＯＳのロケーションキーと結合させられる。これらのロケーションのための現在のイメージマップは、データが最初に書き込まれたとしても、一時的な再マッピングを示していることに注意されたい。
データは、ＯＳによって新たなデータで重ね書きされた時に、ヒストリックになる。ＣＴＭＡページへの新たなデータの書き込みをそらすことは、本質的に元のデータをセーブすることになる。セーフポイント間の時間に、エンジンは１つ以上のＣＴＥＸブロックをサポートする。これらのブロックは、ヒストリックデータ（エキストラページ）と同様に、ＯＳ可視データ（メインエリア）も含む。ページがヒストリックになると、それが既にＣＴＥＸブロックの中にあった場合でも、その新たなステータスを示し、移動させられる必要がない。もし、ページがメインエリアブロックの中にあり、ＣＴＥＸページの数が限界に達していない場合は、メインエリアページがＣＴＥＸタイプに変更される。ＣＴＥＸページの数は、ＣＴＭＡページが制限されているのと同じ理由で、制限されている。
【０２５４】
もしＣＴＥＸページの数がその最大限に達しており、そして、メインエリアブロックの中のページがヒストリックになっていた場合は、メインエリアブロックとＣＴＥＸブロックの１つとの間で、ページスワップが実行される。全てのＣＴＥＸブロックが少なくとも１つのメインページを含んでいることは知られており、そうでなければ、ブロックはエキストラページブロックになるであろう。それゆえに、ＣＴＥＸブロックの中のメインエリアページは識別することができ、そのメインエリアブロックの中の新たなヒストリックページとスワップされる。もし、ディスク上でデータスワップが実際に実行された場合には、相当な時間がかかるであろう。その代わりに、スワップはマップを更新することによって最初になし遂げられる。この状況はＴｅｍｐ法の中の技術から借用しているものである。
【０２５５】
ＯＳは最近書き込まれたデータを重ね書きすることができるが、同じ書き込みセッション（セーフポイント）への書き込みほど速くはない。従って、重ね書きされるデータはヒストリックデータを持つことができないＣＴＭＡページの中にあるであろう。解決方法は、データをスワップしてＣＴＥＸページの中に入れ、ＣＴＥＸページからメインエリアデータを取り出し、それをＣＴＭＡページの中に入れることである。
【０２５６】
要約すると、ＯＳがデータ（それをヒストリックにする）の重ね書きを：
1. メインエリアブロックの中にする場合、次にはＣＴＥＸページへの移行が発生する（図３６）、あるいは、スワップが発生し（図３７）、
2. エキストラページエリアブロックの中にする場合、このブロックのページはＯＳにとっては見えないのでこれは不可能であり、
3. ＣＴＥＸブロックの中にする場合、次にはこのブロックのエキストラページブロックへのコンバージョンが進展し（図３８）、または、
4. ＣＴＭＡブロックの中にする場合、次にはＣＴＥＸページを伴ったスワップが実行され、両方のブロックのコンバージョンが進展する（図３９）。
【０２５７】
書き込みセッションの後、ＣＴＥＸブロックが結合されて１つになって終了する。このプロセスによりメインエリアブロックが生じ、十分な数のメインエリアページの与えられるであろう。同様に、エキストラページブロックも作られ、十分な数のエキストラページが与えられる。いくらかのページがある場合、後回しにするものによって単一のＣＴＥＳブロックが確立され、それが次の書き込みセッションに持ち越される。書き込みセッションの間に、ＣＴＥＸブロックは統合されて１つになるので、エキストラページのセットの中の単一の点と最後のＣＴＥＸブロックはセッションを終了させる。ページの実際の動きと再編成は、マップにおいて最初の段階で統合を行うことにより、バックグランドに対して残される。
【０２５８】
メインエリアブロックを形成するためにＣＴＥＸメインエリアページを結合する場合は、エンジンは近接するメインエリアページの連続するプログラムの実行(run) の分散を最小限にしようとする。このようなプログラムの実行は、最適化の点では、とりわけ互いに隣り合うように位置するメインエリアページを表すと推定される。他のメインエリアページを備えた与えられたＣＴＥＸブロックを単純に一杯になるまで満たし、次いで移動して他のＣＴＥＸページを満たす技術は、プログラムの実行を適切な数に分散するように思われる。通常は、プログラムの実行は、充填プロセスがＣＴＥＸブロックから他に飛ぶ毎に分散される。充填プロセスにおける最初の移動に対する適切なアプローチは、分散が発生しない連続したプログラムの実行である。そのために最初は小さなプログラムの実行から開始し、次に大きなプログラムの実行を行って書き込みを行う(fill in) ことにより、メインエリアブロックを形成するべきである。
【０２５９】
図４０に示されていないものに、ＣＴＥＸページのセットまたはサブセットがあり、統合中に、それらの内容は最終的に部分的に満たされたＣＴＥＸページに移動されるという状況である。メインエリアページをＣＴＥＸブロックから移動することは、これらのブロックをエキストラページエリアブロックに変える。このプロセスにより統合が完成するが、これに代わるものとして、メインエリアページを最終的にＣＴＥＸページに移動させるものがある。メインページのスクラップを最終的にＣＴＥＸページにダンピングする際の問題点は、次の回の統合において、同じ理由によってそれらが再び移動するかもしれないことである。１つのブロックが１００ページもの余裕を与えられている状況では、同じメインエリアページをＣＴＥＸブロックが満たされるまで多数回移動して、メインエリアブロックになるようにすることを考慮しても良いと思われる。これに代わるメインエリアページのスクラップ化の目的は、ＣＴＭＡページまたは複数ページ（または１枚のページ、もし要求された場合は）である。これらをここに移動させることにより、依然としてＣＴＥＸブロックのエキストラページブロックへの所望の変形がなされるが、移動されたデータはその後の統合において再移動が可能となるわけではない。
【０２６０】
図４０Ａから図４０Ｏにおけるこれに続く使用では、実際の使用において異なるであろう詳細およびプロセスがある。実施例ではその点を作る一形態に焦点が当てられているが、動作システムにおける本当のステップを表すものではない。ＣＴＥＸとＣＴＭＡページの間の差異に関してはやがて説明されるパラグラフを参照されたい。
【０２６１】
図４０Ａから図４０Ｈは最終的にＣＴＥＸブロックにスクラップを移動させる効果を示すものであり、これに対して、図４０Ｉから４０ＮはページをＣＴＭＡブロックに移動させる効果を示すものである。ＣＴＥＸブロックが目標である場合に、シーケンスの中の重要な差異は、ページ「Ａ」の移動が２度起こることである。この実施例は普通ではない小さな数のページでブロックが形成されていることを含んでいるので、実際には、多数の「Ａ」の移動が多数倍されるであろうということを理解すべきである。
【０２６２】
図４０Ａは開始点を示している。丸で囲まれた２つの「Ａ」は「ａ」というデータで重ね書きされる。その結果が図４０Ｂに示される。他の２つの「Ａ」ページは重ね書きされ（丸で囲まれている）、その結果が図４０Ｃに示される。ここで、仮定したセーフポイントにおいて、統合があり、スクラップが移動されて残っているＣＴＥＸブロック（♯７）に入る。図４０Ｄでは、最初に「Ａ」の移動が見られる。ここでは４つの「Ｂ」ページが「ｂ」データで重ね書きされる。その結果が図４０Ｅである。図４０Ｆは別の統合を示しており、２つの「Ｃ」ページが重ね書きされ、その結果が図４０Ｇに示される。最後の１つの統合が図４０Ｈに示されており、「Ａ」の第２の移動が生じている。
【０２６３】
ここでは、ＣＴＭＡページに達するまでのスクラップに対してのみ、この書込みプロセスが繰り返される。図40I は、図33C と同じものであり、第１の整理統合（consolidation ）の際にピックアップ動作を行う。このような整理統合の結果は、図40J に示されている。「Ｂ」の重ね書きが生じると、図40K のようになる。この場合の整理統合は、図40L に示されている。また一方で、「Ｃ」のページが重ね書きされると、図40M のようになる。この図40M は、図40N にて整理統合される。
【０２６４】
システム内のデータに関しては、両方のシーケンス共、同様の実質的な効果（net effect）を有することに注意すべきである。図40O は、システム内のデータを数え上げ、上記のシーケンスが同じ結果をもたらしたことを確認する。しかしながら、上記のシーケンスは、データが配置される場所において異なると共に、このような結果に到達するためにどれくらい多くの移動（move）が要求されるかという点において異なる。この例には示されていないけれども、複数のマップが、ページのロケーションのトラッキングを行っている点に注意していただきたい。
【０２６５】
メインエリアを整理統合する場合に、使用するＣＴＥＸとＣＴＭＡとの間で差異が生じてくる。メインエリアの複数のページを整理統合して一つのブロックを生成することに加えて、この一つのブロックはまた、上記ページを移動させている。このような動作は交換である。ＣＴＥＸブロックの場合、このＣＴＥＸブロックは、現在出現している書込みセションに属するヒストリー付きのページである。このヒストリー付きのページは、他のＣＴＥＸページへ容易に移動し得る（来たるべき順序付けに関する通知を考慮に入れて）。しかしながら、ＣＴＭＡブロック内のヒストリー付きのページは「クリア」され（未使用の状態に設定され）、そして、それゆえに、ＣＴＥＸブロック内に移動することができない。上記の問題は、未使用のページを含み得る特殊なＣＴＥＸブロックをサポートし、かつ、未使用の状態になっていないページを所定の時間だけ移動させることによって解消することが可能である。このようなプロセスは、上記のＣＴＥＸブロックを未使用のタイプに変換する。この種の最適化は、複雑性と増大するバックグラウンドスワッピングとの間のトレードオフである。図34P を参照していただきたい。ここでは、「Ｘ」のページが、現時点で、現在の書込みセションからのヒストリーのデータを有するページ用の「Ｙ」、および、未使用状態の空のページ用の「Ｚ」として識別される。
【０２６６】
合体（combine ）が行われている間中、複数のＣＴＥＸブロック間で複数のエキストラページを移動させているときに、一般的にいって、これらのエキストラページが同じ書込みセションから生じている限りにおいては、複数のブロック内でのエキストラページの順序は問題にはならない。しかしながら、重複する書込み（duplicated write）のトラッキングが不可能になる場合は、重複する書込みの順序を変えないことが重要である。換言すれば、第１番目に記録された書込み（原状態）は、第１番目の書込みのままになっていなければならない。もし、スワップによって、最初に現れるように再配置されるべきであるような非所望の重複する書込みが生じるならば、真の最初の原状態を損なわないようにするために、上記スワップはもはや無意味なものになる。
【０２６７】
最終のＣＴＥＸブロック内の全てのエキストラページは、次の書込みセション用のヒストリーのデータがその後に付加されるブロックに対してポイントを付記することを容易に可能にするために、一方の側に配置されるように調整される。さらに、最後の書込みセションから生じるエキストラページの後に、全ての新しいヒストリーのデータが、一揃いのエキストラページに付加されることを保証するために、次の書込みセッションの期間では、上記のＣＴＥＸブロックが、最初に満たされた状態になることが必要であり、かつ、一つのエキストラページのブロックへ移動することが必要である。
【０２６８】
ディスクの割当解除（ de-allocating ）の効果
この時点で、Temp法の書込みプロセスとAlways法の書込みプロセスとを対比させることは、価値あるものである。両方の書込みプロセスのケース共、ＯＳにより指定されたロケーション以外の或る代替的なロケーションに新しいデータが書き込まれる。Temp法においては、迂回（ダイバージョン）が、重ね書きしたデータの原状態を保存する。この迂回の注目すべき点は、過去の状態を保持することである。しかしながら、Always法の範囲は、新たに書き込まれたデータを、適切な断片的になっていないロケーション（unfragmented locations）に配置するよう試みることを包含する。これらのロケーションは、データのアクセスを行うときに、そのデータの最も適切な文脈（context ）において、すなわち、そのデータのファイルに関連した残りのデータとの関係において、ほぼ最適なディスクのアクセスが遂行されるような場所である。
【０２６９】
Temp法によるページへの書込みは、ページの以前の文脈をヒストリーバッファへ移動させる。ページの現在の状態をＯＳにより指定されたロケーションに戻すと共に、原状態をヒストリーバッファに取り込むために、スワップが必要になる。
Always法の主たる利点の一つは、書込みが、必ずしもスワッピングを必要としないことである。まず第１に、大きなファイルに対して重ね書きを行うケースを想定する。このケースで起こることは、一般的に、複数のエキストラページのブロックが選択され、新しいデータでもって満たされてから、メインエリアのブロックに移されることである。ここで、上記のエキストラページのブロックはヒストリーのデータを含んでいるので、ファイルの原データを記憶していたメインエリアのブロックは、エキストラページのブロックに取って代わることになる。新しいデータをディスクに書き込むこと以外に（この新しいデータの書込みは、任意の方法によって遂行されなければならない）、他のアクティビティは、マップ、ブロック、およびページ記述における状態を調整することのみに限定される。この場合、大がかりなスワッピングは必要ではない。
【０２７０】
ＯＳ内での割当解除に関する知識が、定期的にAlways法に提供される。割当解除を知ることの利点は、この割当解除に影響されるエリアが、このエリアの重ね書きを待っていることを必要とせずに、ヒストリーを有するようになることである。さらに、多数の小さな（ファイル）割当解除が整理統合されるために、メインエリアのブロックをエキストラページのブロックに完璧に変換する機会が増加することになる。このように、「重ね書きした」データにヒストリーを持たせるプロセスは、後ほど、データが再使用されてから割当解除を受けるまでの適当な時期に、データを移動させる。このプロセスは、それ自体は、性能上の大きな改善であるとは思われない。上記の小さな割当解除が組み合わされ、他の任意のメインエリアのデータを移動させることを必要とせずに、比較的多くのエキストラページを生成することができるという事実によって、スワッピングが不要になる。これらの事項が、割当解除に関する知識を得ることの理由になる。
【０２７１】
しかしながら、逆にいえば、ＯＳ内での割当解除を知るためには、この割当解除に関する情報が正しくなければならない。エンジンが割当解除の記憶にヒストリーを持たせた場合に、このエンジンは、正しい割当解除の情報を示すように所望のロケーションマップを調整する。それゆえに、ＯＳが割当解除された記憶を読み出すことを試みる場合、この記憶は既に存在しないので、エンジンは或る調和した状態に戻る（また一方で、フラグが、起こり得る誤りの状態に戻ることもある）。このように、エンジンを通して見たディスクの振舞は、エンジンがない場合のディスクの振舞とは異なる。エンジンがあるべきロケーションにない場合、ＯＳが割当解除されたページを読み出すときは、このＯＳは最後に書き込まれたデータを参照することになる。技術的には、一つのＯＳは、割当解除されたページの状態の持続に基づいた仮定をすることが可能である。しかしながら、このようなＯＳは好ましいものではなく、ユーティリティ（utility ）が断片化の解除を実行する動作とは逆の方向に動作することになる。このようなユーティリティは、割当解除されたページ内のデータの無意味性に関して、エンジンと同じような仮定をするであろう。
【０２７２】
エンジンが、割当解除されたページを知ることについては、重要な理由が存在する。このエンジンは、メインエリアのブロックとエキストラページのブロックとの間のバランスを変える。割当解除をする予定のページは、メインエリアのブロックをエキストラページのブロックに変換する。それゆえに、ヒストリーの情報を保持するために、さらに多くの記憶が使用可能になる。このことは、過去に戻って比較的多くのリカバリの範囲に対応する情報をユーザに提供する。もし、エンジンが割当解除の情報を受け取らなければ、複数のページは、新しいデータを書き込むことによってのみヒストリーを有するようになる。このように新しいデータを書き込む動作は、メインエリアのブロックとエキストラページのブロックとの間でページを交換するプロセスである。ここでは、上記のバランスはずっと同じになっている。
【０２７３】
もし、ＯＳが、割当解除されたページをエンジンに通知しなければ、このエンジンは、ヒストリーの状態を保持するのに使用するために上記のページのリサイクルを行うことができない。この場合、割当解除されたページの内容が要求されないので、ユーザのリカバリの範囲が不必要に減少する。それゆえに、記憶がより効果的に使用され得るようになる。
【０２７４】
Move法、Divert法、およびTemp法は、割当解除されたページを利用していない。これらの方法は、ヒストリーを有する情報を保持するために、固定されたエリアを別にして置くことを要求する。これに対し、Always法は、ディスク上の未使用の（割当解除された）スペースを利用する。このことは、動的なサイズのヒストリーバッファを予め見込んでおく。ここでは、ユーザが、ディスクの利用を少なくしている場合でも、自動的に比較的多くのリカバリの範囲を有することになる。これと同時に、ユーザが比較的多くの記憶を要求している場合は、ヒストリーバッファが、過去に戻って上記記憶を取得する。時間的に或る最小限度の間隔だけ過去に戻るような選択権をユーザに与えたときに、強制的にオーバーフローの状態を生じさせることによって、最小のヒストリーバッファのサイズを提供することができる。
【０２７５】
ＯＳのキャッシュ
一般的に、エンジンは、再順序付け（re-ordering ）がなされることなく、このエンジンに沿って書込みが伝えられることを仮定する。それゆえに、アプリケーションが、一つのファイルのページにＡ、Ｂ、およびＣを書き込んだ場合、エンジンは、最終的に上記３つの書込みが同じ順序で伝えられるようにする。しかしながら、オペレーティングシステムは、書込みの再順序付けのポテンシャル（potential ）を有するキャッシュを使用するのが好ましい。例えば、前述のＡ、Ｂ、およびＣの書込みがキャッシュに取り込まれる場合を想定する。その後、キャッシュが書き込まれたデータを出力した（flushed ）ときに、ページがエンジンに送り込まれるが、これらのＡ、Ｂ、およびＣの書込みの順序は変更され得る。例えば、上記ページが、Ｂ、Ｃ、およびＡの順序でエンジンに入る可能性がある。この順序は、エンジンによって仮定された順序とは異なるものなので、将来の読出しアドレスに対する好ましい順序を表してはいないであろう。
【０２７６】
それゆえに、ＯＳによってエンジンを積分する場合は、キャッシュが書込みの順序に及ぼす影響を認識しなければならない。書込みの順序が、将来の読出しの順序を適度に予測することを保証するために、適切なステップが選定されなければならない。
ＯＳによる同期から外れた場合
ここでは、断片化を解除することを目的として或るＯＳに知識を持たせることの利点について議論する。エンジンは、どのページを順序良くアクセスすることが好ましいかを知ることを望んでいる。ここで考えられ得る理由の中で、特に、所定のファイル内で上記ページが連続的に現れることが、最大の理由として挙げられる。さらに、ヒストリーのデータを保持する目的でページを再使用することができるように、エンジンが、当該ページの割当解除の状態を知ることは有益なことである。このような情報は、定期的にエンジンに提供される。このように、上記の情報は即刻エンジンに提供されるわけではないので、このエンジンは、誤った情報に基づいて「動作」してしまうおそれがある。このような事態は、ＯＳがエンジンに情報を提供してから、次の更新の前にその情報を変更したときに起こる。相異なる更新の間の期間では、情報の何パーセントかが誤っている可能性がある。実際に、ある一つの更新から次の更新までの間にエンジンに供給される情報が互いに異なっている場合、エンジンは、２つの更新間の所定の期間では誤った情報を有することになる。
【０２７７】
このようなことが生じた場合、誤った情報に基づいて動作するステップの分岐（ramification）に関して問題が発生する。断片化解除に関係するファイル内のデータ配置に関して、発生し得る最悪事態は、誤った断片化解除がなされることである。この場合には、互いに近隣に位置する所定のファイルに属するページにデータを配置することになると想定して、ディスク上のページを再構築する。しかしながら、上記の想定は事実と異なるので、正しいデータ配置を行っていないことになる。このような弊害によって、コンピュータは、データに対する最適のアクセス以下の状態に制限される。この最適のアクセスは、一般的にいって、コンピュータの全体的な動作を妨害しないという効果に対応するものである。
【０２７８】
関係する次のエリアは、ページの割当解除の状態を考慮に入れる。ここで考えられ得る次の２つのケースが存在する。第１に、エンジンが、一つのページが割当解除されたものと考えているときに、当該ページの割当がなされる旨がエンジンに「通知される」前に、当該ページに対しデータが割り当てられ書き込まれるケースである。実際に、このような第１のケースがほとんど全てである。新しいファイルにデータを書き込む場合に、ＯＳは未割当のページを入手してから、このページに新しいデータを取り込み、さらに、このデータをディスクに書き込む。ＯＳにより使用される種々のディレクトリおよびマップは、ディスク上で、ページに対し書込みが行われる前の状態でのページの変更を全く反映しない。
【０２７９】
ＯＳは、ただ単にページにデータを書き込むことのみでなく、物理的に互いにすぐ隣の位置にマッピングされるような一揃いの割当の中に当該ページを包含することによっても、当該ページの割当がなされた旨をエンジンに通知する。しかしながら、このような情報は、定期的にかつバックグラウンドにて提供されるにすぎないので、更新されるまでファイルに書き込まれたデータが出力されないことは、好ましいことではない。
【０２８０】
それゆえに、割当解除がなされたページにデータを書き込む動作は、問題になることはなく、むしろ正常なことである。ＯＳが、ページの割当解除がなされた旨を最初にエンジンに通知したときは、所望のロケーションマップにおいて適切な通知がなされたことになる。その後、エンジンは、以前に割当解除がなされたページに対していつ書込みが生じたかを検知する。エンジンは、物理的なディスク上のロケーションと、ＯＳにより指定された上記ロケーションのロケーションキーとを関連付けることはしないので、上記書込みが、任意のデータを重ね書きしていることであると解釈することはできない。このエンジンは、ただ単に、非常に古いヒストリーのデータ（ＣＴＭＡのブロックからの）を含んでいた新しいディスク上のロケーションを取り込み、このロケーションをＯＳのロケーションキーに割り当てるだけである。
【０２８１】
割当解除に関係する第２のケースは、エンジンが、所定のロケーションキーについて、実際に割当解除がなされているにもかかわらず、割当解除がまだなされていないと考えているケースである。このような状況は、それ自体では、ただ単に、エンジンが、ヒストリーのデータを保存するためのページを利用することができないという結果を招くだけである。このために、ユーザが時間的に戻る範囲が減少する。しかしながら、このような状況は、次の更新において解消される。割当解除がなされた旨を比較的迅速にエンジンに通知するために、特殊な監視用プログラム（ＯＳの下で実行される）が、急に行われる重大なディスクスペースの割当解除を探索する。もし、このような割当解除が検出されたならば、上記プログラムは更新を開始させ、このことによって、エンジンを厳密に同期状態に保持することが可能になる。しかしながら、ユーザが、ヒストリーのデータを保存するために適度な最小の量のディスクを指定したと仮定した場合、ヒストリーバッファを展開する際の時間的な遅れは、通常、それほど心配することではないであろう。
【０２８２】
上記のシナリオにおける次のステップは、ページが一つのファイルに割り当てられて書き込まれたときに生じる。この場合、当該ページが実際に上記ファイルに割り当てられ、その後、当該ページが、おそらくは別のファイルに再度割り当てられて書き込まれたときに、エンジンは、当該ページが或るファイルに属していると考える。書込みと同時に供給されるファイル識別子（もし、存在すれば）が現時点で通用しているので、エンジンは、誤って、新たに書き込まれたデータと古いファイルとを関連付けることはしないであろう（このことは、古いファイルに対しても、同時に書込みが生じている場合のみ重要である）。実際に、書込みプロセスの間中、エンジンは、最新の更新の期間で供給された全体的なファイルの情報を全く参照しないようにしている。エンジンが調べることは、幾つかのデータが重ね書きされていることである。
【０２８３】
エンジンが認識することなく、割当解除がなされてから別のファイルに再度割り当てられたページの重ね書きは、ただ単に、当該ページが同じファイル内で変更された場合とほぼ同様に取り扱われる。重ね書きしたページはヒストリーを持つようになり、適切なＣＴＭＡブロックから新たに割り当てられたロケーションが、変更目のロケーションの役割を引き継ぐ。エンジンは、データをＣＴＭＡブロック内に残しておくことを選択し、それゆえに、所望のロケーションマップを調整することが可能である。代替的に、エンジンは、存在する重ね書きのロケーションにデータを戻すよう探索することが可能である。このようにすれば、所望のロケーションマップは変わらないので、新しいロケーションは単に一時的なものにすぎないとみなされるであろう（再マッピングを通して）。そして、最終的に、スワップは、所望のロケーションマップにより指定されたロケーションにデータを戻す。このようなシナリオは、Temp法によって生じるものと同様である。
【０２８４】
このように、新しいデータの重ね書きのダイバージョンが、一時的であるとみなされるケースにおいては、スワップを未決定の状態（pending ）にして次のＯＳの更新を待つことにより、最適化が達成される。ＯＳの更新が、バックグラウンドのスワッピングの前に生じた場合、次の二重の移動を回避するように、スワップに対する調整がなされる。第１の移動は、古いファイルのデータでもってページを配置するものであり、第２の移動は、このページの割当解除を行って上記ページを新しいファイルのページの近傍に移動させるものである。換言すれば、もし、エンジンが、スワップを未決定の状態にするプロセスに先立って、ページが実際は別のファイルに属していることを知らされたならば、このエンジンは、当該ページを新しいファイルに配置するように未決定状態のスワップを調整することが可能になる。
【０２８５】
移動するかまたは移動しないこと
前述したように、古いデータに重ね書きする新しいデータが、最終的にどの場所に配置されるべきかに関して、すなわち、新しいエリアに配置されるべきかまたは重ね書きしたデータの場所に配置されるべきかに関して、興味ある問題が生じてきた。後者の配置の選択は、スワップを遂行することが必要であることを意味する。少なくとも重ね書きの時点では、上記の問題に回答するすべはない。
【０２８６】
この場合、２つの基本的な重ね書きの状況が存在する。第１の状況は、ファイル内の小さなデータの量について重ね書きがなされる場合である。この場合は、現存のファイル割当が最適であると仮定すると、原状態を移動させると共に、場所的に戻って新しいデータをスワップすることが最良である。また一方で、ファイル内の大半の部分が重ね書きされる場合、新たに割り当てられたロケーションが最適であると思われるので、この新たに割り当てられたロケーションに新しいデータを残しておくことが最良である。上記の２つの場合のいずれにおいても、その目標は、スワッピングの量を節減することである。書込みの時点では、上記の２つの場合を識別することは難しい。この理由として、将来どのくらい多くのデータが書き込まれるかを予測したり、どれくらいの速さでデータが書き込まれるか（すなわち、長時間にわたることなくファイルを重ね書きすることができるか）を予測したりすることは、誰もできない点が挙げられる。さらに、ファイルのサイズが変化した場合、新しいデータを最初に書き込んだロケーションに残しておくことは、さらなる再配置の可能性を少なくするおそれがある。より詳しくいえば、ファイルのサイズが減少した場合、リカバリ（パッキング）を行うためのスペースが存在することになるであろう。また一方で、ファイルのサイズが増大した場合、おそらくは、分離しているエリアを結合することが必要であろう。
【０２８７】
ここで、重ね書きは、Temp法に見られるように、一時的なダイバージョンとして取り扱うのではなく、新たに書き込まれたデータを最適なロケーションに配置する試みとして取り扱うことが推奨される。データロケーションの近隣関係（adjacency ）に関する仮定が誤っているような状況を修正できるようにするために、エンジンは、長期間の割当解除（ＯＳの更新に基づいている）に依存している。このような修正は、最初に割り当てられたロケーションに戻ってデータをスワップするように設定する形をとる。それゆえに、最悪の場合、スワップを確立させて遂行する動作が遅れる。この問題を回避する方策は、重ね書きしたデータがさらに最適化された状態に移行することがないように、多数のブロックの重ね書きしたデータを移動させることである。
【０２８８】
このようにしてデータが重ね書きされた場合、このデータが望んでいるのは、新しい最適な場所であることを示すために、エンジンが所望のロケーションマップを修正する。この場合、Temp法から借用したスワッピングのメカニズムは、Temp法とは異なる形で利用される。より詳しくいえば、上記スワッピングのメカニズムは、最初に重ね書きしたロケーションに戻ってページをスワップするために使用されていない。例えば、上記スワッピングのメカニズムは、複数のブロックの内容を再配置する際に使用され、一つのブロックのタイプから別のブロックのタイプへの遷移を容易にしている。
【０２８９】
当然のことながら、ファイルの記憶が再度割り当てられる前に当該ファイルの記憶の割当解除がなされた旨がエンジンに通知された場合、全面的な重ね書きの状態は回避される。割当解除がなされた記憶はヒストリーを有しており、この記憶が再使用されるときに新しい記憶が割り当てられる。しかしながら、アプリケーションは、新しいデータを書き込む前にファイルの割当解除を行うことを選択するか、または、ただ単に重ね書きを行って任意の残りの記憶を解放状態にすることを選択することができる。この場合、一般的にいって、最小の量の移動を意味する短期間の仮定を行うことが最良である。もし、使用しているディスク上のページ、および、互いに近隣に位置すべきページに関してより広範囲な眺望が与えられたならば、エンジンは、適当な時期に、さらに最適な割当を行うことが可能になる。
【０２９０】
上記の事項のいずれもTemp法とは関係ない。なぜならば、このTemp法は、重ね書きしたデータを最適に近いロケーションに「迂回する（divert）」ために、最終的に最適に近いロケーションを選定することを試みることをしないからである。Temp法によるダイバージョンは、常に一時的なものであり、Always法の目標とは相反するものである。
【０２９１】
ディスクアクセス性能
現在、重ね書きされたデータの以前の状態を維持する要求は忘れられている。エンジンの性能は、直接ディスクにアクセスするＯＳとどのように比較するのか。最初に書き込みを考える。それらは適度に連続した領域に転用されるので、新たなデータ転送それ自体は影響を受けない。メインエリアマップは起こり得る一時的リマッピングに対して顧慮されなければならないが、このマップは時には全くリマッピングを含まず、従って少しの遅れをもたらす。望ましいロケーションマップの更新時及び、もしあるとしても重ね書きデータのヒストリーとして記憶する際に顕著な臨時の仕事が発生する。重ね書きページが相互に隣接して配置されているとすると、一般的に多ページ更新は同じＣＴＥＸブロックのヒストリーマッピングテーブル中で発生する。影響されたメインエリアブロックがＣＴＥＸに変換できないのでヒストリー及びメインエリアページの交換が要求される場合には、スワップを設定するためにより多くのディスクが必要とされる。しかしながら、単一のファイルを書き込む場合は、これはめったにないケースであろう。
【０２９２】
主たる関心事は、望ましいロケーションマップの顧慮である。このマップは、一時的なマッピングのためにＯＳのロケーションキーを実際のディスクロケーションに転送する。この転送も又、ＯＳからの読み取り要求を処理する際の主たる付加的なステップである。
望ましいロケーションマップは、ダンプエントリのテーブル、即ち各ロケーションキーに対するテーブルである。ダンプエントリは、３ビット型フィールド、典型的には４バイトがパックされたディスクロケーションフィールドから構成される。望ましいロケーションマップは、変更は遷移バージョンに製作され得るように二度配置されるので、各ロケーションキーは実際に望ましいロケーションマップ支持の８バイトを要求する。もしディスクページサイズが５７２バイトであれば、マップは５７２当たり１６バイト又はディスクの約１．６％を使用し、これは妥当である。
【０２９３】
１つのデマップ（dmap）形式は、対応するキーロケーションは配置されないことを示している。この場合、このキーロケーションに割り当てられた実際のページはない。それがＯＳによって読み取られるべきであれば、いくつかの恣意的な、しかし矛盾のないデータが戻され、ユーザ警報状態が設定される。他の形式は、短く説明される隣接結合である。
【０２９４】
エンジンがＯＳの文脈読み取り以外でこの状況に遭遇したならば、それはディスクエラーを表示する形式を予約し、そのロケーションの後の読み取りに応答したＯＳへの最後の報告のためにそれを記憶することを必要とする。１つのシナリオは、スワップが実行され、エンジンが少しもデータを読み取ることができないことである。スワップが進行するに従って、不具合箇所は新データで書き換えられて、状態を矯正される。しかしながら、一般的に、ディスクエラー状態は通常は一時的である修正可能な問題であるので、エンジンがそのバックグラウンド書き込みプロセスを中断することが推奨される。従って、ユーザに警告し、ディスクは多分一時的に信頼性を失っているので、新しい安全ポイントへのいかなる遷移をも排除することが最良である。
【０２９５】
このデマップ形式は、それがメインエリアにロケーションキーをリマッピングしていることを表示することが可能である。メインエリアマップは再度このロケーションをリマップすることに注意せよ。また、近傍の情報は、短く説明されるようにこの形式中に組み込まれる。
以下の表は、デマップ形式及びエントリ用残存ビットの使用の概略である。
【０２９６】
Figure 0003878412
【０２９７】
Figure 0003878412
５７２バイトのページサイズで、リマッピングディスクロケーションのために２９ビットを使用すると、アドレス可能な空間は２６２ギガバイトとなる。付加的な詳細が適当に付加されるかもしれない。
【０２９８】
ディスクアクセス性能の確認に戻ると、ディスクの中間のどこかに配置された単一ページから構成されるファイルの場合を考える。ＯＳがこのページを読み取る場合は、所定のロケーションマップ（これは最早キャッシュ中にはないと仮定する）の適当なセクション中に入るためには１回のディスクアクセスが要求される。従って、いったんページの実際のロケーションが検出されると、第２のディスクアクセスが要求される。１回のディスクアクセスだけがマッピングなしで要求されるので、性能は半分に落とされる。しかしながら、ごく僅かのファイルが小さく、ＯＳが連続して小ファイルをアクセスする場合は、キャッシングはオーバーヘッドの大部分を隠すであろう。
【０２９９】
次に、ＯＳがディスク上の５つの領域にわたって割り付けするが、エンジンは近傍のディスクロケーションにリマップする大きいファイルの場合を考える。そして、データが読み取られたときに、５回ではなく、１回のディスク探索だけが要求される。しかしながら、問題は、ファイルのＯＳの割り付けを反映して、単一領域へのＯＳのロケーションキーをマッピングするエントリが所定のロケーションマップ内で拡大されることである。従って、もしかするとマップの５つの異なるセクションが調べられなければならず、２度の全回数の探索が要求される。もしファイルが一ページを一時に読み取るならば、多数のディスクヘッド探索が要求されるので、重複が発生する。所定のロケーションマップの一部分をピックアップするために一回の探索が、指示されたデータを読み取るためにジャンプが、マップの他の部分を読み取るためにジャンプが、さらなるデータを獲得するためにジャンプバックが要求される。所定のロケーションマップへの混合されたアクセスを処理するためにジャンプは常に要求されるので、ファイルデータが共に配置されてしまったことは重要ではない。このオーバーヘッドは、長期間のリマッピングを排除するためにＴｅｍｐ法が探索を実行したためである。
【０３００】
所定のロケーションマップのキャッシュングは、オーバーヘッド上で多分中止するであろう。これは、データの密度の６４倍の密度を有する。換言すれば、８バイトのデマップエントリは５７２バイトのデータをマップするが、これは典型的なサイズである。従って、キャッシュされたマッピングの１００Ｋはディスクの６．４ギガバイトを覆う。ＯＳの割り付けによって観察されるように、アクセスは「ディスク」の領域内にある傾向があるかもしれない。これは、同時に関連ファイルが割り付けされ、割り付けが取り消されるために発生する。断片化は全体的にランダムではなく、ディスク全体にわたって拡散するかもしれない。従って、先の例において、所定のロケーションマップの所定のセクションがキャッシュされた場合は、ファイルのアクセスにおいて５倍の改善が存在するかもしれない。しかしながら、これはキャッシュングを組み立てるための時間を要し、初期アクセスはまだ低速である。
【０３０１】
所定のロケーションマップ全体に拡散したデータであるべきものに対応するロケーションキーを有する問題に対する解決は、近隣マップの使用である。このマップはＯＳの更新時に独自の領域内に構築され、保存される。このマップは、ロケーションキーをリマップされたロケーションに関連付ける単なるテーブルである。所定のロケーションマップ中の対応するエントリは、近隣マップへの結合の代わりにリマップされたロケーションの表示を中止する。
【０３０２】
ＯＳによって割り付けされるような５領域にわたって拡散されたファイルの例は、今再考される。エンジンはディスク上に全データを配置し、最後のＯＳ更新の間に、単一のマップ中にファイルの全ページがリマップされた場所を表示するように近隣マップが構築される。そして、ファイルの第１ページの読み取り要求が獲得される。読み取りが所定のロケーションマップに発生するが、順番に近隣マップの読み取りを惹起し、最終的にディスク上のページの実際にロケーションにそれを向ける。従って、性能の大きい低下である３回のディスク探索が第１ページを読み取るために要求される。しかしながら、ファイルの読み取りは５領域にわたって継続するので、近隣マップの初期転送は残存するアクセスをリマップするのに十分である。ファイルデータが１つの領域中に合併されるので、残存データを読み取るために更なるディスク探索はまったく要求されない。従って、ＯＳはエンジンなしの５つの領域、もしくは所定のロケーションマップだけを有する６又はそれ以上の領域の周囲にジャンプしなければならなかったので、近隣マップの使用は３に対するカウントを低減する。キャッシングによって、ファイルの引き続く読み取りは１回の探索だけを要求する。
【０３０３】
明らかに、１又は２の領域に分かれるロケーションキーを含むファイルに対して近隣マップのオーバーヘッドを導入することは望まない。これらの場合に、所定のロケーションマップを使用することはよりよいことである。しかしながら、エンジンがこれらの領域中のページが物理的に近くに割り付けられるべきであることを知ることは依然として重要である。ＯＳ更新中に供給される近隣情報の記録は、ページのダンプ形式中に近隣の開始、中間及び最後を符号化することによって維持される。第４の状態は、ページが他のいかなるページに隣接することをフラグされていないことを示している。
【０３０４】
隣接していることをフラグされた割り付けが依然として残っていることを確認するために、エンジンは所定のロケーションマップ及び近隣マップを走査する。重ね書きされたデータ中に（エンジンによって割り付けられた）何処かに配置される結果となる重ね書きデータは、何が良い状態であるかを変更することができる。書き込まれたデータ量に依存して、所定の近隣は失われるかもしれない。小量のデータが重ね書きされた場合は、その内容が実際に割り付けられるファイルは今異なる領域に配置されるかもしれない。これはある限定されたスワッピングによって訂正される。一方、全ファイルが重ね書きされた場合は、その新しいロケーションは妥当な近隣を維持する。この場合、エンジンの所定のゴールであるスワッピングはまったく要求されない。最初の少量の重ね書きの場合は、ファイルが断片化されたことをエンジンが実現したときに導入されるスワッピングは、データが重ね書きされたときに発生する一時的方法中の処理とほぼ同様に動作する。しかしながら、Ａｌｗａｙｓ法においては、何がスワップされるかの選択はブロック形式の要求のためにより複雑である。
【０３０５】
近隣マップへの下降部分は、そのエンジンのディスクスペースオーバーヘッドへのより多い付加である。マップ（ロケーションキー及びリマップされたロケーション）中の各エントリに対して典型的には８バイトが要求される。これは各エントリに対する所定のロケーションマップ中に対応する８バイトに対する付加である。従って、各ページは１６バイトのオーバーヘッドを有するが、安定なかつ移行時のバージョンをつかまえるために３２に２倍にされなければならない。典型的なページサイズが５７２バイトであると仮定すると、ディスクの６．２５％はリマッピングで使用され得る。あり得るパッキングはもちろん近隣マップの選択的使用及び遷移を取り扱うための異なる機構はパーセンテージを低下することが可能である。
【０３０６】
近隣マップへの代替え接近は、ファイルのロケーションキーの配列の再決定の手段を有することである。処理はヒストリー情報を含むので、処理が割り付けされないストレージの使用を排除しなければならないという例外の下に、これはエンジンの始めで走る基本的な標準断片化解消である。最良のアプローチは、ディスクスペースとＯＳに統合され、ＯＳについて知ることのできる "コスト" の間のトレードオフを反映している。標準の断片化解消はＯＳのコアデータ構造を変更する。
【０３０７】
ＯＳのロケーションキーの断片化に関しては、ウインドウス９５（登録商標）ＯＳに具備された標準の断片化解消ユーティリティを使用する多くの重使用されるコンピュータの迅速なサンプリングは、使用１年後であっても、断片化が低レベルであることを報告している。ほぼギガバイトの記憶を有するシステムにおいては、３から１０パーセントは典型的であった。低パーセンテージの理由は、ディスクの大部分はシステムが最初に立ち上げられたとき、即ちディスクが相対的に断片化解消されているときに、ロードされたアプリケーションによって占有される。断片化された領域は、ファイルが生成され、削除され、重ね書きされるユーザの日々の仕事に対応する。これらの仮定のもとに、主たるアプリケーションのロードは断片化されていないスペースの大部分を占めるので断片化は妥当に局所化されることとなる。これは、断片化された領域の圧倒的なパーセンテージが、アプリケーションによって使用される領域の外部になければならないことを意味する。ディスク上には自由領域以外なにも存在しないので、断片化は局所化される。
【０３０８】
断片化された記憶領域のパーセンテージが小であっても、頻繁にアクセスされたら性能の顕著な劣化をもたらすことに注意せよ。ここで、焦点はＯＳの断片化を "固定" するために要求されるエンジンオーバーヘッドの量に関連するディスクの典型的な断片化量の程度を考察すること、及びより高いアクセス性能を得ることである。
【０３０９】
断片化の集中化された現実が与えられると、ファイルの小さいパーセンテージだけが近隣マップを要求することとなり、従ってディスク領域の言葉でより入手しやすいマップを作成する。さらに、ディスクアクセスは一般に局所化されるので、これはキャッシングの効率化を付与する。キャッシング中に展開される所定のロケーションマップの一部分は適度にユーザの使用領域を覆うこととなる。すべてのこれら信号は、時間的及びディスク領域的に、エンジンの付加されたマッピングオーバーヘッドが合理的に維持され得るという主張を援助する。
【０３１０】
データ構造支持の概要
以下はエンジンによって使用される主なデータ構造、及びそれらの典型的な隣接ディスクオーバーヘッドである。 "２" は安定遷移バージョンのためにデータが二重に割り付けられていることを示す。
Figure 0003878412
全ての内部マップが最大サイズである場合の、要求されるものに応じたヒストリー領域の最小量の確保は、ディスクオーバーフローロジックの具備しなければならないことを回避する。ヒストリー情報を犠牲にして、マップに対する領域は常時使用可能であるべきである。この計算に対する重要性のマップは星（＊）印が付され、使用可能なディスク領域の最小約１０％が保留して設定されていることを示している。オーバーフローロジックは、代替システムとしてヒストリー情報の記録を中止し、既存のディスクマッピングだけを活性とし得ることを心に留めつつ、これを最小に低減し得る。
【０３１１】
図４１はマップ間の一般的な関係を示す。
ブロックマップはポインタの表である。テーブルの各エントリはディスク記憶装置のブロックに対応する。１ブロックは典型的には１００Ｋバイトである。例えば、４ギガバイトをマップするために約４８，０００のエントリあるいは１６８ｋのＲＡＭを必要とする。予約値は、メインエリア（通常及び直接）、ＣＴＥＸ（通常及び不使用ページ付き）、ＣＴＭＡ、不使用かつオーバーヘッドブロック形式である。そうでなければ、付加的なページ領域ブロックを取り扱う。このマップ値はブロックのヒストリページ記述子（ＨＰＤ）を含むヘッダへの連結であり、年代順の次のそのようなブロックへの連結である。表の終端における付加的なエントリは、付加的なページブロックに対するリストヘッダとして作用する。図４１において、年代順の結合はブロッキングマップの始めに示されていることに注意せよ。これは、結合が、いま説明するように、ヘッダ中に存在するとしての概念である。
【０３１２】
多くのページに対して結合がマッピングシステム中で発生しているときは、遷移形式においてページ形式（それらは実際に重複したページ形式を含む）を束縛するために付加的な処理が要求することに留意して、この形式はブロッキングマップから迅速に導き出され得る。
ブロック中のページ数は、ページ中に記憶され得るヒストリーページ記述子の数の最適化から生起する。５７２バイトのページサイズ及び１２バイトのヒストリーページ記述子サイズが与えられると、１ページ中に約４８の記述子が配置され得る。これは、ヒストリーデータの２１ｋバイトに対応する。１００ｋ近傍のブロックサイズが、容易に取り扱われる量として推奨される。従って、ヒストリーページ記述子の５ディスクページは、付加的な領域ブロックごとに割り付けられる。しかしながら、遷移的な処理のために、これらは二重に割り付けられ、従って１０ページを要求する。従って、付加的なページブロックは２１２ページ（２１２＝５＊５７２／１２丸め処理）又は１０６ｋで最適となる。記述子はそれらの付加的なページを含むブロックから分離して記憶されることに留意せよ。メインエリアブロック中の全ページがヒストリーとなる場合に、ヒストリーページ記述子に対する領域を作るために何も移動されないようにこれが実行される。
【０３１３】
所望のロケーションマップは、デマップエントリの単なる表である。ディスクの５７２バイト当たり８バイトにおいて、新しい安定バージョンへの安全な移行を提供するための二重割り付けを含んで、４ギガバイトのディスクマップは６４メガバイトである。マップの一部は必要に応じて読み取られキャシュされる。マップは、ＯＳによって供給された近隣情報を直接間接に記憶するだけでなく、エンジンのリマップされたロケーション中にＯＳのロケーションキー（ディスクロケーションのバージョン）を翻訳する。マップのエントリは、与えられたロケーションキーがＯＳによって割り付けされない場合に、リマップされたロケーションをまったく有しないことを示す。マップはまた、ページマッピングはマッピングの他のレベル、近隣マップ中に見出されることを示しているかもしれない。
【０３１４】
いくつかの細かい変更によって、可能な場合にマップに対するロケーションキーを同一の物理的ディスクロケーションの生起させることが可能である。リマップする場合が存在しない状況は、いかにしてシステム動作を得るかということと共通する初期空であるディスク上に大きいアプリケーションをロードするときに発生し易い。ＯＳが割り付けを生起し、これらの割り付けは（ワイヤを介して）エンジンに転送されるので、エンジンは可能であれば一致している物理ディスクロケーションを使用しようとする。所望のロケーションマップが表である場合には、マップの大部分が効果的なリマッピングをまったく示さないことを有する場合にまったく記憶が存在しない。マップは依然として調査されなければならず、ページがリマップされないことを発見したときに、リマッピングを引き出すことはまったく容易となる。しかしながら、マップが存在しないノードによって覆われた領域に対する包含されたリマッピングを有するツリーとして組み込まれた場合に、マップに対して使用されるディスク領域の量は多分低減される。
【０３１５】
ディスク領域を節約することは、それは性能を改善することであるので、多分それほど重要ではない。特別の "メインエリア直接" ブロック形式は、ページのリマッピングはまったく要求されない。ＲＡＭ中に存在するブロックマップ中におけるこのブロック形式の検出は、所望のロケーションマップの大部分は決してロードされないことを含んでいる。これはマップ読み取りにおいて時間を節約するだけでなく、キャッシュの外部でマップのこれらにセクションを維持する。従って、補修されたキャッシュ領域はマップの他の領域に対して使用され得る。この増強は推奨される。マップに対するツリーの使用の下側は近隣情報の喪失である。
【０３１６】
再マッピングを実現する方法は、可能なら、別の未使用ブロックタイプを設定することである。初期において、ディスクはそのようなブロックで構成される。ブロックが要求される際、このプールが空になるまでそこからブロックが割り当てられる。このトリックは、ブロックを割り当てる時に、適当に前記ブロックにマッピングされるロケーションキーを特定することである。従って、ロケーションキーに直接対応して生じる未使用ブロックが存在するなら、それは割り当て用に選択される。もし、前記ブロックをメインエリアデータと共にファイリングした後、全てのロケーションキーが対応する物理ロケーションに直接マッピングされることが判明した場合、ブロックタイプは特定の直接形式に変更される。
【０３１７】
書き込みセッション重ね書きマップ (Write Session Overwrite Map) はＲＡＭ内にのみ存在するビットマップである。各ビットは、ディスク上のページに対応し、そのページが現在の書き込みセッション中に書込まれたか否かを示す。それは、初期書き込みの後、重ね書きされる前に、ページの元の状態のヒストリーをとることを回避する。このことは、初期のヒストリーを取った後に、同じ書き込みセッションにおける続く書き込みが、単に既存のロケーションを重ね書きすることを暗示している。前記マップは、制限された容量のＲＡＭ内におけるマップがディスクのアクティブエリアを表すよう、ディスク上のどこでも配置可能なセクション内にブロック化することを推奨している。これは必須ではないが、全てのアクティブエリアをカバーし、情報を配置可能とするために、不十分なサイズのマップが存在すべきである。これにより、元の状態のヒストリーを取る必要がなくなる。前記ヒストリーに害はないが、ユーザによる過去への履行が低減される。４ギガバイトのＲＡＭディスクへ完全にマッピングするには１メガバイト必要である。
【０３１８】
使用中マップ (In Use Map) は、遷移及び安定データの間の識別を行なうビットマップである。その一般的な概念は、一時的方法セクション (Temp Method section) に表されている。遷移処理に続く全ての割当ては、隣接するペアに割り当てられる。１つのユニットとして書込まれた所定のデータ構造が１ページ以上を使用する場合には、その第１のコピーのための全てのページが続く第２のコピーのためのページと一緒にグループ化される。前記第１のページに対応する使用中状態ビットは２つのコピーのいずれが指示されているかを制御する。重複した割当てのため、２つのコピー毎にマップ内には１つのビットだけが存在する。ページに対応するビットを検索するには、単にページロケーションを２で除算し、マップにオフセットされたビットとしてその結果を使用する。
【０３１９】
奇数ページ境界上に割当てを開始する場合、対応ビットが、ラウンデング(rounding)によって、前記割当て部分でないその前のぺージに適用される。しかしながら、確かに前のぺージは使用中マップによって追跡された割当ての先頭部分となり得ない。そうでなければ、問題の割当ての開始を記すその後の偶数ページが必要となる。従って、前のページに対しても同様な、状態ビットを用いた奇数割当てに全く問題ない。
【０３２０】
４ギガバイトを表す使用中マップを保持するのに１メガバイトのＲＡＭが使われる。しかしながら、遷移処理に基くこれらのエリアだけがこのマップを必要とする。これはオーバヘッド割当てに制限される。従って、ビットマップは、全ディスクの小さな比率（通常１０％以下）であるオーバヘッド・ブロックタイプの維持だけに使われる。よって、オーバヘッド・ブロックに対するマップセグメントはＲＡＭに容易に適合する。それらは、そのブロックに伴うセグメントに関する情報と共にディスク上の連続した適用エリアに記憶される。
【０３２１】
隣接マップ(Adjacency Map) は、それらの数値範囲を超えて広がるファイル内の連続したページに対応するロケーションキーの問題が言われている。これは断片化された割当てを生成するＯＳによる結果であり、通常はそれらの関連する物理ディスクロケーションに対する散在するロケーションキー値を翻訳する際に多くの所望のロケーションマッピングページへのアクセスを引き起こす。しかしながら、ファイルアクセス時に、再マップを生成する所望のロケーションマップに代えて隣接マップが使われる。このマップはキャッシュされ所望のロケーションマップへ戻る前に後のアクセスに関して参照される。
【０３２２】
隣接マップはロケーションキーをそれらの再マップディスクロケーションと関連させるが、ロケーションキーインデックスではなくＯＳによって提供される隣接情報によって構成される。隣接マップは、続くロケーションキー参照に良い予測をあたえるファイル関係に基いて再マップ情報をクラスタ化する。これは、所定のファイル内で一連のアクセス処理を行なうため実際に読み込まれるマッピング情報の量を最小化する。
【０３２３】
隣接マップは、そのテーブルサイズとロケーションキーテーブル、及び再マップロケーションから成る。テーブルサイズは、２つの独立したテーブルを比較するような非常に大きなテーブルを有する実質的な利益が無いため制限されるべきである。隣接マップは、空間が少ないなら、所望のロケーションマップに際組み込みされたそのマッピング情報と共に廃棄可能である。この場合、ＯＳはその情報を再度提供して状態を変更すべきである。マップは可変長であり、特定のオーバヘッドブロック「サイズ」のセットはそれらの割当て及び管理に用いられる。もし、新たなマップが形成されてそれが他に属するロケーションキーを参照するならば、これ以前の参照はすでに旧いと仮定され、それが旧マップから削除されて新たなものが追加される。
【０３２４】
最大メインデータブロックサイズ（１１１Ｋ）に対応して最大テーブルサイズが選択された場合は、マップは２２２エントリと１レングス、又は１７８０バイトを必要とする。マップは遷移処理のため二重に割り当てる必要がある。
メインエリアマップ(Main Area Map) には、ページの短期再マッピングが言われている。この再マッピングは所望ロケーションマップ(Desired Location Map)のレベルよりも低い。メインエリアマップの作業は一時的方法におけるそれと類似したものである。確かに、所定のロケーションに再マッピング情報が見つからなければ、マッピングはされない。バックグランドスワッピングはマッピングを解決し、それによるマッピングはしばしば空である。所定のロケーションキー（所有者）に対するマッピングエントリは、実際のロケーションとその内容が現在ロケーションする所有者のディスク上のスポットで構成される。メインエリアページは他のメインエリアページ又はヒストリーページと共にスワップ可能であり、メインエリアマップは前記スワップをサポートするリンクを含む。もし、スワップがヒストリーページを含むなら、関連するヒストリーページ記述子(Historic Page Descriptor)はそのリンクを含む。
【０３２５】
全てのエキストラページエリアが集合的に区画化されている場合、これらのブロック内の全てのページに対してヒストリーページマップが存在する。このマップはヒストリーページ記述子から成り、それは関連するヒストリーページの当所の物理ディスクロケーションを示す。それはまたスワップを含み、短期再マッピングに利用されるリンクを戻す。これらのリンクは、メインエリアマップのリンクと共に、通常一時的方法で述べられたように機能する。これら３つのフィールドは典型的には記述子に対して１２バイト（フィールド当たり４バイト）の大きさである。
【０３２６】
ヒストリーページ記述子はヒストリーページに必要なだけであり一般的にはエキストラページブロックにのみ発見されるだけであるから、記述子のセットはそのページに対して適当なオーバヘッドブロックサイズから割当てられる。これらの割当てはヒストリーページマップセグメント(Historic Page Map Segments)と呼ばれ、システム内のヒストリーデータ量に比例して存在する。ヒストリーページはまた遷移的なＣＴＭＡ及びＣＴＥＸブロックタイプにおいても発見され、従ってこれらのタイプも関連するマップセグメントを有する。マッピングは前記セグメントをそれらのブロックに関連付ける。
【０３２７】
遅延ムーブマップ(Delayed Move Map)は、エンジンによるあるロケーションから別のロケーションへのコピーの延期を可能にする。それは、例えば、直ちに元に戻すために使用される。前記マップは各々がソースフィールドと次のリンクを有したエントリから成る。より詳細には一時的マップを参照のこと。マップはディスクデータの５７２バイト当たり１６バイトから４ギガバイトディスク当たり１２８メガバイトまで拡張し得るが、このことは確かではなく時間内にマップは除去される。
【０３２８】
書込みの一例
図４２のシーケンスは、ファイルに対する書込みを描いている。ファイルは１０ページの長さであり、漸次重ね書きされる。「オペレーティングシステム」下では、ファイル内容はヘディングに示される。それらはその側に対応するロケーションキーを備えたボックス内にある。例では、ＯＳによって割当てられたような、幾らかの断片化されたファイルを示している。所望のロケーションとメインエリアマップが示されている。図４２Ａのリンクはロケーションキーを非断片化する所望ロケーションマップを示している。如何なる一時マッピングもメインエリアに影響を与えない。
【０３２９】
「ディスク上の実ページ」の下では、ディングはディスクの内容である。左側へのＯｆｆは関連するディスクロケーションである。前記内容はブロック化されそしてラベルが付けられ、ＸＵＳＥは未使用ブロックを示す。ＥＸＴＲはエキストラページエリアブロックであり、ＭＡＩＮ、ＣＴＭＡ、及びＣＴＥＸはそれぞれのブロックタイプを示す。図の右側へのＯｆｆはＨＰＤの一般的な表現である。エントリが有効な時、矢印は各ボックスをディスク上のロケーションへリンクする。このリンクは、物理ページを直接指示することを示しているが、実際にはメインエリアマップに従う。本図ではそのような表現が便宜的でないからである。
【０３３０】
図４２Ａは本例の初期状態を示している。図４２Ｂでは、ファイルの最初のページの重ね書きが発生する。新データは現在のＣＴＭＡブロックに案内される。メインエリアページと共にファイルされたブロックはＭＡＩＮブロックタイプに変更される。ＨＰＤは重ね書きされたデータのロケーションを示す。重ね書きは図４２Ｃへと続き、そこで新ＣＴＭＡブロックが開始する。一般に、その時間中、ＣＴＭＡブロックは最も旧いエキストラページエリアブロックから割り当てられるが、この場合には幾つかの全く使用されていないブロックが使用可能である。図４２Ｄ、４２Ｅ、及び４２Ｆでは、重ね書きされたものは２つのＣＴＥＸブロックへ導かれる。
【０３３１】
図４２Ｇでは、セーフポイントが発生する。これはファイルへの書込み途中の異常を示すが、本例のために示してある。スワッピングデータは２つのＣＴＥＸブロックを統合する。しかしながら、ユーザに対する一層の対応のため、実スワップは遅延され、ポインタを通して一時的に実行される。よって、メインエリアマップは初期化される。図４２Ｈで、スワップが実行され、メインエリアマップは無効に戻る。別の重ね書きが発生する。図４２Ｉは次の３つの重ね書きを描いている。そして最終的に、図４２Ｊにおいて、重ね書き処理がファイルの先頭に対して開始される。エキストラページブロックの割り当てが行なわれ、そしてＣＴＭＡブロックとして新データを受け取る。ここでは、「次の」セーフポイントまでの全てのヒストリーデータは、前記セーフポイントの前のヒストリーデータの始めの部分のリサイクリング結果として廃棄される点に注意すべきである。
【０３３２】
一時的及び常時的方法の共通要素
次のエリアは、少なくとも概念的には、一時的(Temp)及び常時的(Always)方法の間で実質的に同様に操作される。
１．セーフポイント
２．シュミレーションイメージの生成、
３．リバージョン及びリバージョンの特別ケース
４．遅延ムーブマップ
５．大きなディスク変更時間中のシャットダウン
６．低レベルディスクスワッピング及びページコピー
７．ある安定状態から他の状態への遷移
８．メインエリアマップ及びヒストリーページのためのＨＰＤを伴う内部リンク
９．ページ切替え及び使用中マップ
ファイル方法
ファイル方法は、過去のデータを回復又は表示できるように前の状態を保存するＯＳに組み込まれた機能の一つである。ＯＳにおけるこの機能を実現する１つの方法は、常時的方法をＯＳにマージさせることである。そのような結合システムにおいては、所望ロケーション及び隣接マップはそのファイルをマッピングするＯＳの方法として組み込まれているため消失する。常時的方法下でのエンジンの隣接処理は、そのエンジンへの周期的なＯＳの更新を含み、ファイルに割当てられたディスクロケーションの再配列をＯＳ内に含む。関連するページスワッピングを伴うこの非断片化は、エンジン内のバックグランド機構によって達成される。
【０３３３】
方法の比較
重ね書きされたデータの前の状態を保存する５つの基本的な方法が存在する。その方法は次の点で異なる、すなわち
１．「書込み」を実行するのに必要な全ディスクアクセスの数、
２．ユーザが継続可能となる前に必要なディスクアクセスの数、
３．ディスクスペースオーバヘッド（マップ等）の量、
４．ディスク読み出しに関するインパクト、
５．オペレーティングシステムとの統合
である。
【０３３４】
前記方法がどのように異なるかを調べる前に、通常、データが書き込まれる時に起きることを考察するとよい。このことが図４３に描かれている。外部のボックスは番号付けされたフレームであり、各フレームは１つ又はそれ以上のディスクアクセスに対応する。その内部には２つのコラムボックスが存在する。左側のコラムはファイルを表す。各ボックスはファイル内のページ値を含む。コラム左のＯｆｆはＯＳによって割当てられたディスクロケーション（ロケーションキー）である。ここでは、ロケーションは２つのグループに関係しており、従ってファイルがその割当てにおいて少し断片化されることに注意されたい。右コラムはその側へのディスクロケーションを有する物理ディスクを表している。本例では、ファイル内容が左コラムに示す新たな値で重ね書きされる。このコラムはＲＡＭ内のデータに対応する。矢印は、回転するディスク上のソース又はデスティネーションを伴う主要なディスク転送を表している。主要なディスク転送とはディスクヘッドの再ポインティングを伴うような転送をいう。
【０３３５】
フレーム１において、ファイルの第１の部分はディスクに書込まれる。フレーム２は書込まれた第２の部分を示している。この時点で、ユーザはその活動を継続する必要はない。以降の処理はバックグランド作業を含む。その場合、ユーザが作業を継続した後にフレームが生じる。
【０３３６】
【表１】
Figure 0003878412
【０３３７】
図４４はムーブ方法を描いている。各フレームでは、２つのコラムを準備するため別のコラムが右側に付加される。これらのコラムにはハードディスクの内容が反映される。２つの内で、第１（左）コラムはＯＳの可視エリアを表す。第２（右）コラムはエンジンだけが見ることのできるヒストリーバッファである。フレーム１で、ファイルは、少なくともＲＡＭにおいて、重ね書きされるが、ハードディスクが変更される前であり、その影響を受けるページはヒストリーバッファに移動される。フレーム１は重ね書きされるべきデータの読み出しを示しており、最終的なロケーションを示している。しかしながら、さしあたり前記データはバッファに収納される。フレーム２は、読み出される第２のエリアを示しており、ここでは既にバッファにロードされていものを含む両方のエリアがディスクベースのヒストリーバッファに書込まれる。フレーム３及び４は実際の重ね書きを示しており、その後ユーザは引き継ぐことができる。
【０３３８】
【表２】
Figure 0003878412
【０３３９】
まだフレーム１の間に、ディスク上の元のデータをメモリの新たなデータに置き換えることで、フレーム３のディスクヘッドの再ポジショニングを回避できるかもしれない。これは実際可能であるが、それは元のデータが保存される前にデータを重ね書きするという黄金律に反するものである。すなわち、重ね書きの後でクラッシュが発生し、それが元のデータをヒストリーバッファに与えらる前の場合には、元のデータを回復する手立ては無い。
【０３４０】
全ての方法において、保存事項に関する事項を維持するための付加的なディスクアクセスオーバヘッドが存在する。ムーブ方法ですら、前記事項はヒストリーデータの大元を示すヒストリーバッファに書込む必要がある。これらの付加的なアクセスは、前記方法の基本的な特徴に焦点を合わせるため、本例の目的から除かれている。さらには、ある瞬間から瞬間までのオーバヘッド情報のキャッシングは、性能上の一貫したインパクトの予測を可能とするものである。
【０３４１】
一時的方法（Ｔｅｍｐ法）は図４５に描かれている。ハードディスクデータと関連する各フレームにおける別のコラムが、ディスク上のスワップエリアを表すために付加される。一時的方法下では、ページがディスク上で交換される際に、スワップが完了する以前にシステムがクラッシュする場合のバックアップとして、そのデータがスワップエリアに格納される。これにより、システムが元の状態を喪失したある遷移ポイントにおいてクラッシュすることを回避できる。フレーム１では、変更のない元の状態は残したまま、新たに書込まれた全てのデータがヒストリーバッファへ再び向けられる。種々のマップを更新することで、ユーザはこのポイント後の継続が可能になる。その後、バックグランドで、エンジンは全ての前記データを収集し、それを交換する。
【０３４２】
一時的方法は、一時的に新データをヒストリーバッファに置き、通常のＯＳ可視メインエリアに新たなヒストリーデータを残す。フレーム２は、メモリに読み出される新データを示しており、それは最終的にスワップエリアに書込まれる。フレーム３及び４は、読み出されるファイルの元の内容を示している。前記スワップに含まれる収集された全てのデータを持つことで、そのデータのバックアップがフレーム４に書込まれる。次に、前記データはそれらの適当なロケーションに書込まれる。フレーム５はファイルの第１の部分の重ね書きを示しており、フレーム６は第２の部分、そしてフレーム７はヒストリーデータを示している。このポイントでマップは更新され、全てがその場所にあることを示す。
【０３４３】
【表３】
Figure 0003878412
【０３４４】
直接スワップエリアに新データが書き込まれるＴｅｍｐ法としてはＤｉｖｅｒｔ法を思いつくことができる。これは、Ｔｅｍｐ法よりも全ディスクアクセスを少なくするが、スワップエリアに適合するよりも一層多くのデータが書き込まれる場合にはＭｏｖｅ法に戻るという受け入れ難い不利益を有する。
図４６に見られるのは、Ａｌｗａｙｓ法及びＦｉｌｅ法のための単一フレームである。それにおいては、ファイルの新データがディスク上の単一エリアに単純に書き込まれる。しかしながら、ファイルの原データは、どこか他の場所に配置され、それ故、過去を再生するために利用可能な状態にある。その書き込みは、トラッキングがもはや可能でない非常に古いヒストリックデータに重ね書きする。マップに対する種々の更新もまた実行されるが、示されてはいない。Ｆｉｌｅ法は、所望の位置マップがそのファイルについてのＯＳの通常のマッピングに折り込まれるため、Ａｌｗａｙｓ法よりも一層効率的なビットであろう。
【０３４５】
【表４】
Figure 0003878412
【０３４６】
要約すると、Ａｌｗａｙｓ法及びＦｉｌｅ法は、マッピングオーバヘッドにおけるいくらかのディスクスペースを犠牲にすることによって、最良の全体性能を生み出す。一般に、それらの書き込み及び読み取りのアクセススループットは、ＯＳが直接ディスクをアクセスするときのものと近似する。Ｔｅｍｐ法は、ユーザ応答の観点から、Ａｌｗａｙｓ法及びＦｉｌｅ法と全く同様に実行する。しかしながら、ＯＳがレイアウトするのと全く同一の方法でディスクを物理的に維持する上で、Ｔｅｍｐ法は、実質的なバックグラウンドスワッピングを必要とする。このスワッピングは、所与の書き込みと関連するディスクアクセスの全体的総量を増大せしめる。平均的ユーザでなかったら、追加のアクセスが隠される限り、それらはおそらく関係しないであろう。
【０３４７】
ディスクアクセス性能の範囲外でこれらの方法に対する他の利益及び不利益が存在することを思い起こされたい。これらは、先に取り扱われた。Ｔｅｍｐ法、Ａｌｗａｙｓ法及びＦｉｌｅ法は、ユーザ可視ディスク性能に対し一般的な影響を与えることなく、バックアップサービスを提供する。これは、ユーザがデータを読み取り及び書き込むのに要する時間（「継続」の欄に列記）によって測定される。Ｍｏｖｅ法は、まっすぐ進むものであるが、その単純さにおいて、ユーザが慣れている性能を犠牲にする。
【０３４８】
【表５】
Figure 0003878412
【０３４９】
被シミュレートディスクからのブーティング
被シミュレートディスクによって、ユーザは、同時にメインディスク（イメージ）をランオフ(run off) し続けながら、過去からデータをアクセスすることができる。「ディスクをランオフする」という表現は、一般に、ディスクからのブーティング(booting) の処理（ＯＳのスタートアップ）をいう。アプリケーションが一般に使用するように構成されるのも、また、ディスクを対象としてである（例えば、アプリケーションは、ファイルが"C:/windows/example"にあることに気づく可能性がある）。用語「ディスク」及び「ドライブ」は、ここでは、交換可能である。
【０３５０】
被シミュレートディスクは、典型的に、それ自身のドライブ識別子又は文字を通してアクセスされる。かくして、ユーザ及びＯＳの観点から、被シミュレートディスクは、過去の所望の時点にバックアップがなされた他のハードディスクとなる方がましであろう。ちょうど第２のハードディスクを有するように、初期の開始ポイント時点が設定された後に、被シミュレートディスクに変更をなすことが可能である。１より多くの被シミュレートディスクが、各々それ自身のマップを備えて、一時に使用されることができない理由はないことに留意されたい。
【０３５１】
ユーザは、ランオフされているディスクに対する変更案をテストすることを望可能性がある。最初に、そのプロセスが、現時点に被シミュレートディスクを確立し、該変更を加え、次いでそれらをテストするであろうと思われる。しかしながら、ディスクをランオフする状況で変更をテストするためには、ユーザは、ディスクをブートアップ（ＯＳをロード）し、かつ、それに被期待ドライブ文字を割り当てなければならない。例えば、ＭＳ−ＤＯＳ及びマイクロソフトウィンドウズにおいては、これはドライブＣである。
【０３５２】
かくして、このプロセスをサポートするために、エンジンは、再ブーティング時にドライブ文字を切り換える。これによって、ユーザは、被シミュレートディスクをランオフすることができる。システム構成の全体を通して埋め込まれた全てのドライブ文字割り当ては、テストを実行するための修正を必要としない。さらに、ユーザが通常ランオフするであろうメインディスクは、新ドライブ文字を通して依然として利用可能である。ひとたびテストが完結すると、ユーザは、単に被シミュレートディスクの役割とメインディスクの役割とを再び交換するか、又は被シミュレートドライブの状態への永久的なリバージョン（戻り）を要求するか、のいずれかによって再ブーティングする。
【０３５３】
別のプロセスは、メインイメージを変更し、それをテストし、及び欠陥(flaw)が見つかるならば変更がなされる前にそれを戻らしめるのを単に必要とするであろう。唯一の危険は、どういうわけか、欠陥バージョンが、リバージョン経路を見失うほど多くの新データを書き込むことである。このシナリオは、被シミュレートイメージをランオフするならば、この場合ディスクオーバフローが起こるため、不可能である。おそらく一層重要なことには、一時的なコンテクストにおいてテストし、次いで変更を永久的なものとすることが、変更を取り消すよりも良いと心理的に思われる。
【０３５４】
被シミュレートディスクに対する変更が、ヒストリー情報を保持するために使用される記憶プールから割り当てられることに、留意されたい。該プールを使い果たすあまりにも多くの変更は、ディスクオーバフローの形に結果する。それは、ＯＳの正常報告方法が正確でないことにおいてわずかに異常なディスクオーバフローであり、これはそれらがメインディスクに対応するからである。しかしながら、ユーザは、合理的に大量のディスクを別にしておくことができ、そしてオーバフローからセーフ状態にいることができる。被シミュレートドライブに対する変更を維持しつつ消費されるディスクスペースの量に対し、ヒストリー情報の過度の損失を防ぐために、キャップ(cap) を課すことができる。エンジンから情報を得る別個のディスク使用法報告システムが、被シミュレートディスク上の利用可能スペースについてユーザに報告する。この報告システムは、スペースが低いときにユーザに警告する早期警告システムを含む。これらの発行の全ては、一つが被シミュレートディスク又はメインディスクをランオフしているかどうかにかかわらず、適用される。
【０３５５】
被シミュレートディスクのランオフの有効な例は、共通の起源を共用する実質的に２つのディスクをユーザに提供することである。これは、親が、子の使用のためにドライブを確立するのを可能にする。最初に、該ドライブは、メインドライブのコピーとしてスタートする。しかしながら、親は、次いで所望のファイルを削除して、それらを子に対してアクセス不能にすることができる。被シミュレートドライブに割り当て可能なディスクスペース上にキャップを置くことは、子がメインディスク上に与えうるであろうあらゆるインパクト及びヒストリー情報を制限する。パスワードシステムがメインディスクを保護する。
【０３５６】
長期被シミュレートディスクを創作することにおける問題は、メインディスクに対する変更が被シミュレートマップに対する更新を頻繁に必要とすることである。このことは、親がコンピュータを使用している間、スループットを減少させる。一つの解決法は、子がコンピュータの使用を欲する度に被シミュレートイメージを確立し及び解放することである。親は、私的なファイル及びディレクトリィのリストを指定する。これらは、子の被シミュレートイメージ創作の間に自動的に削除される。
【０３５７】
外部バックアップ
原ディスク状態をセーブするための、これまでに提示された全ての方法は、単一ディスクの周囲に概念的に設計される。もちろん、１より多くのディスクが含まれ、これらの集合的記憶が１つの大きな論理的ディスク内にプールされてもよい。種々の方法によって提供される障害許容性は、ユーザによるファイルの事故的重ね書き又はファイルに対して不正行為をなすアプリケーションのバグのような非ハードウェア故障を取り扱う。しかしながら、ディスクが機能を現実に停止する場合（すなわち、壊れてそれに含まれる情報が失われる場合）もまた存在する。そのような故障からの回復は、新ハードディスクをインストールし、オペレーティングシステムを再インストールし、次いでバックアップテープ又は類似のデバイスからファイルを回復することを典型的に包含する。これは、時間を消費するプロセスであり、データの損失をしばしば伴い、バックアップ後に影響を受けるであろう。
【０３５８】
周知の解決法は、ＲＡＩＤシステムである。並列に維持される冗長なディスクドライブが、ディスクの１つが故障した場合に無中断サービスを提供する。しかし、かかるシステムは、同時に２つのディスクに書き込む必要があり、このことは、比較的複雑で構築する上で高価となる。大抵のパーソナルコンピュータは、たとえディスクが比較的安価であっても、かかるシステムを使用しない。
【０３５９】
外部バックアップ（テープ）を生成するプロセスは、被シミュレートディスクイメージの使用によって強化される。ユーザは、現時点に対応する被シミュレートイメージを確立し、そのバックアップをスタートさせ、そして作業を継続することができる。
外部バックアップを達成することへの、全体的に異なる解決法は、メインディスクのように、原ディスク状態をセーブする方法を使用する外部ディスクドライブを持つことである。かくして、特定の時点のバックアップを創作する代わりに、バックアップ上の情報がヒストリー情報を含み、バックアップが「バックアップ」時間の範囲を再創作するのを可能にする。換言すれば、外部ディスクは、一般に、メイン内部ディスクを鏡のように反映する。これが、ＲＡＩＤシステムが一般に作業する仕方である。
【０３６０】
しかしながら、内部ディスクも外部ディスクも同時に並列にランせしめるために何らの試みもなされない。その代わり、変更のリストの創作としてメイン内部ディスク上のログのアクティビィティを眺めるならば、これらの変更は、時間が許す範囲で外部ドライブに送られる。事実として、より段階的な転送（メインディスクと非並列）において、バックグラウンドにおける変更の再生を容易にするメインディスク上のヒストリーログが存在する。さらに、中継された情報が、年代順であり、それ故、セーフポイントを含むため、外部ディスクは、一般に、最悪でも、回復しうる時間の範囲内にて遅延する。このことは、冗長なドライブの１つがＯＳによって眺められる現在の状態よりも遅延するならばその内容が制限的に使用されるものとなるＲＡＩＤシステムと相違する。クラッシュが起こり、遅延したディスクが使用されるとしたならば、過去のある単一の任意のポイントにユーザを回復させるであろう。他方、メインドライブから年代順に変更を受け取る外部ドライブは、どんな時点へも回復させることが可能である。かくして、クラッシュ後、外部ドライブは、クラッシュに先立つ過渡的変化の前のセーフポイントをおそらく含む。過渡的変化は、不完全故に無用であるため、セーフポイントへと戻る。
【０３６１】
かくして、保証された有効なバックアップイメージが利用可能であるため、変更の転送における遅延に依存して、このポイントは、おそらく、時間的にそれほど戻ることはない。ＲＡＩＤシステムを用いると、物理的ディスクドライブ故障からの保護が達成されるが、クラッシュして過渡のディスク最終状態から離れたコンピュータに対して何も提供されない。
【０３６２】
本発明の外部バックアッププロセスは、内部ディスクドライブが他の媒体（例えば、ディスク又はテープドライブ）上に単にコピーされるものとは異なる。かかる複製は、非常に時間を消費する。その代わり、外部ドライブ及び内部ドライブの状態が比較され、適切なヒストリー的なかつ現在のイメージデータが転送され、やがて両者は同期する。この転送プロセスは、非同期であり、現在のイメージに対する最近の変更よりも実質的に遅延し得る。それ故、それは、安価で比較的低速のバス上に構築されることができる。例えば、並列プリンタ又はＵＳＢポートである。
【０３６３】
ＲＡＩＤシステムが故障ディスクから冗長ディスクへと切り換えるのと同じ方法で、もしもメインディスクが故障するならば、エンジンは外部ディスクに自動的に切り換える。２つのディスクが同期からはずれる可能性があり、現在のイメージになされた変更は、故障に先立って外部ディスクへ転送されてはいないであろう。この状況においては、エンジンは、直近のセーフポイントの時点で、ユーザに警告し、外部ディスクをランオフすべく再ブーティングを強制する（かくして、エンジンは、アプリケーションの観点から無中断のディスクサービスを提供しない）。ユーザが外部ディスクをランオフしているため、メイン内部ディスクが交換される。エンジンは、次いで、自動的に、バックグラウンドにおいて、内部ディスクを同期へと至らしめ、このポイントにおいてプライマリディスクとして再開する（すなわち、それらは役割を切り換える）。換言すれば、内部ディスクが故障して交換されるとき、内部ディスク及び外部ディスクによって通常演じられる役割が逆にされ、やがてそれらは一度再び同一となり、その後通常の動作が再開する。
【０３６４】
外部ディスクは、除去可能である。可搬型コンピュータの場合、外部ユニットを作動中のままとしておき、可搬型コンピュータを家に持っていくことができる。外部ディスクに再び取り付けられたとき、情報の転送が始まる。かくして、ある期間における可搬型コンピュータの除去は、既に遅延した転送における「ディレー」を単に導入するだけである。
【０３６５】
ディスクアクティビィティを再指示し、ディスクの以前の状態に時間的に戻って参照し、そのバックグラウンドにおいて仕事を実行する、エンジンの能力は、全て、強化されたバックアップサービスを提供することに貢献する。その１つは、種々の時点への回復及び物理的ディスク冗長性の双方を提供する。
ここで、その詳細として、最初に空白の外部ディスクを接続してエンジンの管理下で作動させるとき、エンジンは、直近のセーフポイントに被シミュレートディスクを確立する。そして、このイメージが外部ドライブに転送される。次に、被シミュレートディスクがセットされた時点よりも前の期間からの全てのヒストリーデータが送られる。これらのプロセスの双方が外部ディスクをセットアップすることにおいて特殊であり、したがって、書き込みは再指示されず、先行の状態はセーブされない。ひとたび外部ディスクが現在のイメージ（おそらく内部ディスクと比較されたデータからであるが）及びヒストリーデータを収容すると、外部ディスクは通常の使用のためにレディとなる。
【０３６６】
セットアップされた外部ディスクがコンピュータに接続されるとき、エンジンは、それを外部ディスクと同期せしめるようシークする。これは、直近に転送された情報に対応する内部ディスクのヒストリーにおける最後のポイントを識別することを伴う。かかるポイントが内部ディスクのヒストリーバッファの終わりをロールオフしたものの中に存在しないならば、外部ディスクは、空白で完全に再初期化されたものとして取り扱われる。そうでなければ、エンジンは、内部ディスクのヒストリー中を前進し、被シミュレートディスクと関連する時点にスタートする。各ヒストリーページの新状態は、基本的に外部ディスクへの正常な書き込みとして下り方向に転送される。外部ディスクの通常のエンジン管理は、正に重ね書きされるようとしているデータをセーブし及びそのページの新しい値を受け入れる。ヒストリーバッファを伴う従来のケースは、所与の位置が複数回重ね書きされたときに生ずるが、過去のある時の「新」状態は、現在の状態ではなく間の１つである可能性がある。
【０３６７】
本質的に、エンジンは、外部ディスクに一般に年代順に（少なくとも書き込みセッションの期間に）内部ディスクに起こった書き込みを書き込む。それは新データであって外部ディスクに転送されたヒストリーデータでないため、外部ディスクは既にヒストリーデータを有している。ひとたび両ディスクが同期せしめられると、エンジンは、内部ディスクに対する更なる変更を待ち、次いで同期を再開する。
【０３６８】
図４７Ａは、接続を断たれた内部ドライブ及び外部ドライブを図示する。各ドライブは、現在のイメージ及びヒストリーデータを含む。最初、内部ドライブの４ページが、値「Ａ」、「Ｂ」、「Ｃ」及び「Ｄ」を含む。外部ディスクは、空白である。図４７Ｂにおいて、値「ａ」及び「ｂ」は、それぞれ「Ａ」及び「Ｂ」上に重ね書きされる。かくして、原状態は、ヒストリーバッファに移動し、現在のイメージは該変更を反映する。次いで、外部ドライブが図４７Ｃにおいて接続される。エンジンは、内部ドライブの現在の状態に基づいて被シミュレートディスクを確立することによって応答する（各書き込みはまたセーフポイントであると仮定される）。図４７Ｃにおけるダッシュラインはこの時間を表す。
【０３６９】
図４７Ｄにおいて、ユーザは、「Ｃ」に「ｃ」を重ね書きし、「Ｃ」をヒストリーバッファに移す。この変更は被シミュレートディスクが確立された後に起こったので、初期に送られたものの一部ではない。図４７Ｃは、また、外部ディスクに転送され書き込まれつつある被シミュレートディスクのイメージを示している。フレーム４７Ｅにおいて、ユーザは、「Ｄ」に重ね書きする。被シミュレートイメージを明らかにしたので、被シミュレートディスクの参照時に先立つヒストリーデータが送られる。同期化プロセス中のユーザの継続アクティビィティの結果が利用可能なヒストリーデータの量をより少なくすることにつながることに注意されたい（すなわち、「Ａ」バッファの終わりをロールオフしている）。
【０３７０】
図４７Ｆは、エンジンが２つのディスクの同期を維持するように試みていることを示す。被シミュレートディスクが確立された後に起こった変更が送られる。これは、エンジンの下での正常な書き込みとしてフレーム４７Ｇにおいて起こり、重ね書きデータが外部ディスクのヒストリーバッファに移動している。このポイントで、２つのディスクは同期せしめられた。しかしながら、フレーム４７Ｈにおいて、「Ｅ」に重ね書きされる。内部ディスクは、この変更を直ちに反映し、外部ディスクへの変更の転送が始まる。ある時間後、フレーム４７Ｉが再び同期せしめられたディスクを示す。
【０３７１】
ネットワークを介した外部ディスク
全セクションからの外部ディスクの概念は、ネットワークを介して標的コンピュータにインターフェースされるディスクを含む様に拡張することが可能である。このネットワークは単に高速バスである。ネットワークからの外部ディスクへのアクセスは通常、ディスクへまたはディスクからの転送を制御しかつ実際に実行する関連のサーバを必要とする。
【０３７２】
ネットワーク上のサーバは一個以上のＰＣと通信が可能であるため、その結果このサーバは独立してＯＳ可視ディスクイメージおよびワンセットのＰＣのためのヒストリー状態を維持することができる。例えば、１０ギガバイトディスクを有するサーバは、ネットワーク上で、２、３、３および１ギガバイトのサイズの内部ディスクを有する４個の各ＰＣのバックアップをする（全９ギガバイト、その結果サーバは少なくともこの場合全ＰＣを合わせたものよりも多くのストレージを有する）。
【０３７３】
さらに特定すると、各ＰＣは、その一部がＯＳ可視データを示し残りがヒストリー（重ね書きされたＯＳ可視データ）である内部ディスクを有している。このＯＳ可視部分は典型的には、ＰＣの内部ディスクのサイズマイナスヒストリーデータ（ゼロであり得る）の他に設定された最小値、によって限定される。このサーバは、各ＰＣに対して、ＰＣの内部ディスクのＯＳ可視部分のために少なくとも十分なスペースを有することを必要とする。与えられたＰＣへのサーバ上に割り当てられた追加のディスク容量は、ヒストリーデータを保持するために使用される。若し、外部ディスクを更新が遅れたＰＣの内部ディスクの単なる第２のコピーであると見ると、この２個のディスクは同じサイズで有るべきである。しかしながら、内部ディスク上に保存されたものに比べてヒストリー状態のために使用される多少の追加のストレージを持つことができないと言う理由はない。このことは、更に多くのヒストリー情報を有している場合外部ディスクが過去の状態を再生するにあたってさらに過去に到達することが可能であり、もし少なければあまり遠くまで戻れないことを暗示している。
【０３７４】
したがって、バックアップしているＰＣディスクのＯＳ可視部分を表すためにその利用可能なディスクストレージ（一個またはそれ以上のディスクであり得る）エリアにマップすることは、全くそのサーバによって決まることである。各バックアップされたＰＣに対してヒストリー状態をセーブするために、サーバはさらにエリアを割り当てる。このエリアのサイズは、それぞれのＰＣ上にヒストリーデータを維持するために委ねられるストレージに対して独立している。ＰＣソフトウエアにおける規定は、内部データ上で利用可能なものよりも多くのヒストリー情報を有しかつそのアクセスが望まれる外部ディスクに迂回させ、かつこれを利用する。
【０３７５】
ＰＣに関係する一セットの内部ディスクに対してネットワーク上で冗長バックアップを提供するために、本発明に一致する方法でサーバを使用することによって、維持し、拡張しかつ管理するための簡単に管理することができる単一の点が提供される。さらに、除去可能なバックアップ（テープ）サービスは、この冗長ストレージから直接に提供され、それによって種々のＰＣ内部ディスクに対する如何なる相互作用、したがってローディングまたパフォーマンスインパクト、をも回避できる。図面ではＰＣからサーバへのデータの流れを示しているが、実際はデータは両方向に流れる（例えば、サーバ上でかつサーバによって効果的に表現される「外部ディスク」が、ＰＣ内部ディスクの役割を引き継いだ場合）。
【０３７６】
ディスクコントローラまたはサーバベースのファイアウォール保護
この時点において、記載した方法の一つを実行するために、標的コンピュータにおいて走行するエンジンを、本発明ではあてにしている。標的コンピュータの内部ディスクに加えて、外部バックアップを使用する場合においても、外部ディスクからの読み出しおよび書き込みは依然としてエンジン（標的コンピュータ内で走行する）によって制御されている。このエンジンは、ユーザがディスク（メインイメージ）の全体または一部を以前の時間に向かって再記憶することを可能とすることによって、ウイルス保護を提供する。しかしながら、これは、ウイルスがエンジンおよびディスク間に入り込むことが出来ないと言うことを仮定している。ウイルスが直接に内部または外部ディスクの何れかにアクセスすると、このエンジンのデータは取り返しがつかないほど汚染される。
【０３７７】
ディスクおよびエンジンを保護する方法は、エンジンの論理の適当な部分を「ディスク」中に、ディスクコンピュータの一部分として移動することである。この結果、ディスク（コントローラ）に送られる読み出しおよび書き込みアクセスは、ＯＳによって発生されたものに一致する（即ち、ＯＳとディスクコントローラ間の再マッピングをするエンジンは存在しない）。マッピングおよびリダイレクションは、ディスクコントローラ内で発生し、ディスクコントローラのみがエンジンの内部データにアクセスすることが可能である。ウイルスはその後ディスク上に格納されたヒストリーデータまたはエンジンの内部データにアクセスして汚染することは出来ない。したがって、このモードにおいて、ユーザは、標的コンピュータ上でウイルスに対して真のセキュリティを提供される。
【０３７８】
ユーザデータを攻撃するためにウイルスに残された唯一の道は、時間上での変化を追跡するエンジンの能力が効果的に失われるように、多くのデータをウイルスが重ね書きすることである。言い換えると、ウイルスが非常に多くのデータを繰り返し書き込みその結果ヒストリーログがこれらの変化によって一杯となり、ウイルス以前のディスク状態のメモリを押し出してしまうことである。この傷を受けやすいウインドウは、ディスクが過剰に変更されたように見えた場合、エンジンによってディスクをシャットダウンすることによって、アドレスされる。これによりヒストリーデータが保護され、したがってユーザがかなりの距離に渡って時間を逆上る能力が保護される。
【０３７９】
エンジンがシャットダウン状態が目前に迫っていると信じた場合、エンジンはユーザに警鐘を与え、安全手段によってシャットダウンを強行する状態を撃破し、または調整させる。ここで、「安全手段」とは、ウイルスがユーザのふりをしてシャットダウンを撃破することができない手段である。例えば、ユーザはエンジンに直接インターフェースするボタンを押すことを要求されることがある。エンジンのある部分がディスクコントローラ内で走行している場合に、これは特に有用である。別の「安全手段」は、標的コンピュータに（それが入力される前において）未知であるパスワードを入力することを含んでいる。
【０３８０】
ディスクコンピュータ内へエンジンの一部を移動することは、内部または外部ディスクドライバの一方または両者上でなされる。外部ディスクがネットワーク上のサーバを利用して実現される場合、エンジンのある部分はそのローカルプロセッサ上で実行し（サーバはＰＣがエンジンの内部データを直接に変更することを許可しない）、ファイアウォール保護が達成される。したがって、ファイアウォール保護は、ハードウエアの変更を伴うことなく、ＰＣおよびサーバに適当なエンジンソフトウエアを追加することによって、通常に利用可能なＰＣおよびサーバによって達成される。
【０３８１】
このファイアウォールは、ウイルスがＰＣ内に入り込み、ファイアウォールを通りその後ディスク上に書き込まれるデータの性質に干渉するすることを防止するものではないことに注意されたい。ユーザがウイルスの存在を検出し、ディスクをウイルスの攻撃以前の時間に復帰させるための十分な能力を有していることが望まれる。ファイアウォールは復帰するためのユーザの能力を保護する。セーブされたヒストリーデータを復帰させるための能力を越えて長時間に渡ってウイルスがデータに感染しかつ汚染させた場合、ウイルスは成功したものとされる。
【０３８２】
メモリおよびディスクスのスナップショト
ディスクに対して直接に何もすることがないコンピュータにおいて発生する別の範疇の故障が存在する。これらは、長時間に渡ってアプリケーションを使用し、この期間中に情報がメモリ中で操作されかつ周期的にその情報がディスクに書き込まれる場合を含んでいる。通常の故障は、ユーザのエラーかまたはアプリケーション中のバグによって発生し、あるものは恐ろしく悪くなる。この様に悪くなる場合、実際、容易に回復する道は無い。全てのセーブされていない仕事は失われる。幾つかのアプリケーションでは、セーブされていない仕事が危険にさらされるのをどの程度最小化するか（自動セーブによって）にトライしてはいるが、クラッシュが発生しユーザがセーブしていない仕事に投資したかなりの時間を失うことが未だに一般的である。
【０３８３】
一般的な解決方法は、ディスクを時間的に復帰させる能力をエンジン上に形成する事である。安全ポイントが確立された後であるがしかし何らかのさらなるディスク変更の前において、アプリケーションによって使用されるＲＡＭの複数のスナップショットを周期的に複数の瞬間で取ると、ディスクおよびアプリケーション（ＲＡＭ）の両者を同一の以前の時間に復帰させることが可能である。これらのスナップショットはまたＯＳのＲＡＭ（またはその一部）を含むことが可能で、その点において、全コンピュータ、ＯＳおよび全ては、復旧が可能である。以前の時間から再スタートする場合、ディスクおよびＲＡＭ以外のデバイス、例えば、プリンタ、ビデオカードまたはネットワーク接続が正当に再スタートする様に注意を払う必要がある。
【０３８４】
ＲＡＭスナップショットは、一定の間隔でおよび／または一定量のユーザアクティビティ（例えば、キイストロークまたはマウスアクティビティ）の後に、取ることが可能である。スナップショットの圧縮はメモリ要求を減少させる。
ナイスバックグラウンド
バックグラウンドにおいて仕事を実行する意図は、ユーザに干渉しない為である。最も良い方法は、ユーザのアクティビティを検出し、ユーザの最後のアクティビティの後かなりの期間が経過するまで全てのバックグラウンドのアクティビティを中止することを含む。この結果、ユーザが少しでも活動している間は、バックグラウンド処理が発生しない。
【０３８５】
キイストロークの様な短期間のユーザアクティビティの間の利用可能な時間を使用しない理由は、各ユーザイベントの後に小さな遅延を導入することによってそれが蓄積されて全体の干渉にまで達するからである。それ自身による１秒の１／１００の遅延はユーザが気づくことはない。しかしながら、スクリーンの更新がコンスタントに遅れると、その影響を簡単に見ることができる。基本的な問題は、バックグラウンドアクティビティを含む殆どのアクティビティが直ちに中止しうるものでは無いことである。真にアイドリングしているシステムに比べて「リアル」タスクを走行させることによって導入される大きな粒状のスイッチング時間が存在する。勿論、タスクを即座に中止することができれば、ユーザの自由時間の小さなギャップにおいて実行されている場合であっても、干渉が起こることは殆どない。
【０３８６】
ロウレベルのスワッピング
エンジンは書き込みを別のロケーションに一時的に迂回させることができる。エンジンはさらにポインタを用いて種々のページのコピーを遅らせることができる。バックグラウンドにおいて、エンジンはスワップをやり遂げ、遅延された移動（ムーブ）と同様にデータをそれらの所望のロケーションに置く。スワップの順序をキューに登録し、かつ提出をムーブしそれらをブロックとして最適時間内でかつクラッシュ防止マナーにおいて実行することが、ロウレベルスワップ処理の仕事である。
【０３８７】
バックグラウンド処理の前後関係において、ロウレベルスワップおよびスワップハンドラにおける遅延されたムーブマップ処理は、ユーザのデータに対する門番である。データのいかなる交換もマップ中に適正に反映されなければならず、スワップハンドラは２つのステップを同時に効果的に実行する。即ち、データを移動し、マップを更新する。常に処理中のクラッシュチャンスが存在するため、これは重要である。スワップハンドラを呼び出すのに先立って、全ての所望のマップは、移行バージョンとして作られる。関連するユーザデータの移動は、キューに登録される。これの全ては次にスワップハンドラに送られ、オペレーションを終了する。ユーザデータは移動され、その後移行バージョンが、スイッチページへの最後の一個の書き込みにおいて、安定化される。
【０３８８】
一旦スワップハンドラがユーザデータを変更する点まで要求を処理すると、この処理は取消出来ないものとなる。この要求は、ユーザがディスクをアクセスするために終了されまたは反転されねば成らない。終了することができる場合、オペレーションを反転する理由は存在しない。
図４８は、２個の３ページセットをスワッピングする単純な場合を説明している。図４８Ａは、スワップハンドラが仕事を始める直前の状態を示している。スワップするページは、エンジンの内部データの移行コピー中に実現されている対応のマップチェンジと同様に提出されている。
【０３８９】
スワップに含まれる全てのページは、ディスク上のスワップエリアに書き込まれる（９ページから１４ページまで）のと同様に図４Ｂのメモリ中に読み込まれる。図４８Ｃにおいて、スイッチページが更新され、スワップが進行していることを示しかつスワップ中の全ページの到達先（デスティネーション）が表記される。スワップが終了する以前にシステムがクラッシュすると、再スタートに当たって、オペレーションを終了することが可能である。図４８Ｄは、ページを（メモリから）新しいロケーションに書き込むことを示している。そして最後に、全てのものを適正な位置において、図４８Ｅで、スワップ−イン−プログレス（スワップ進行中）状態をクリアし、移行データで有ったものが現在の安定状態に到達したことによって終了する。図４４はムーブ方法（Ｍｏｖｅ Ｍｅｔｈｏｄ）の基本と同じプロセスを効果的に説明している。
【０３９０】
スワップおよびムーブを実行する場合、オペレーショングループをキューに登録することが望ましい。複数のオペレーションをわたって最適化を可能とするのと同様に、これによってスイッチページ更新に対するユーザデータムーブの割合を縮小させる効果が存在する。例えば、ＢとＣをスワップするのと同様にＡとＢをスワップする場合、ＡからＢへ、その後Ｃへのムーブは、ＡからＣに縮小される。他の最適化は、読み出しおよび書き込みに先立ってロケーションをソーティングすることを含んでおり、これによってディスクシークの数および距離を最小化する。前記の例では、一回のオペレーションで実行された３ページスワップを明示している。
【０３９１】
２個のスワップは相互に依存的であっても良い。例えば、ＡとＢの２個のスワップはＣとＤと同様に独立している。これらは如何なる順序でも実施することができる。しかしながら、ＡとＢのスワップはＢとＣと同様に、順序に依存している。スワップＡとＢの第１の提出を受信していると結論付けることは出来ず、しかしながら、実際、交換されるのはこれらのロケーションである。ＢとＣをスワップするための第２の提出は、第１の提出からのデータが実際にワインドアップした場所を修正する。この特別な場合、もしＡ、ＢおよびＣをメモリ中に読み込むならば、ＡをＣの古いロケーションに書き込み、ＢをＡの古いロケーションに書き込みＣをＢの古いロケーションに書き込むであろう。
【０３９２】
明らかに、近いグループのスワップを共に処理することは非常に有益である。しかしながら、ディスクに広がるデータに関する１バッチのスワップを処理する事にも同様に幾らかの有益性がある。この有益性は、データを集めかつ再分布させることから発生する。ディスクを横切る２個のパス中に読み出しおよび書き込みを分類することによって、シーク数は縮小されないけれども、ヘッドのムーブ距離が減少する。ディスクドライブ技術に依存して、これは重要でありまたは重要でない。しかしながら、この２個のパスは更にスワップエリアおよびスイッチページにデータをセーブすることを含み、そしてこれらのオペレーションの全オーバーヘッドは複数のスワップが結合される場合、減少する。
【０３９３】
多くの異なるエリア中の複数のスワップを最適に取り扱う能力は、２個の大きなエリア、その後者は明らかなゴールである、のスワップを効果的に取り扱う事とによって、非常に低いコストで達成される。これらの問題の両方を解決するアプローチは読み出しおよび書き込みを単純に分類することである。
図４９は３個のスワップ提出を説明しており、それぞれは３個の特別なページのスワップを含んでいる。この図は、スワップハンドラ要求中に含まれる全てのロケーションのリストを作ることおよびそれらを読み出しおよび書き込みパス中に分類するための簡単なアプローチを示している。
【０３９４】
分類された読み出しリストを形成するアルゴリズムは明白である。全てのページロケーションを取り出しそれらを分類し、如何なる複製も放り捨てる。勿論、書き込みロケーションは読み出しロケーションと同じである。問題は、それらがスワップされた場所に対応するようにページをメモリ中に並べ替えることである。それらのロケーションが既に処理されていない限りにおいて、あなたは基本的にスワップリスト中に入り込み、左側、次に右側を処理する。各側に対して、その対応するスワップロケーションが他の側において特定されたものであることを、あなたは先ず仮定する。次に、あなたは残りのスワップエントリ中に走り込み、もし現在のロケーションがもう一つに対してスワップされているかを追跡する。もしそうであれば、あなたは現在のロケーションを更新し、次のスワップエントリに続いていく。あなたがサーチを終了する時、あなたが残したものは最終書き込みロケーションである。図５０は、このアルゴリズムがどの様にして図４９の第２コラムにおけるスワップを実行するかを示している。
【０３９５】
スワップおよびムーブの提出は、プレスワップセットアップルーチンに提出される。ここで、それらは、遅延されたムーブマップを介して実行され、このマップが調整され、さらに全ての関連するムーブオペレーションが追加される。オペレーションは、限界に達するまで蓄積され、あるいはタイムアウトが起こった場合、排出される（フラッシュされる）。一個のオペレーションでスワップが可能なページの全数に関して、２個の限定因子が存在する。これらは、スワップエリア（およびＲＡＭバッファ）のサイズとディスク上にアクセスされた異なる遠方エリアの数である。
【０３９６】
エリア限定は、スワップ要求期間の最も悪いケースを制御するために生じる。ディスクシークに１０ｍｓを要し、それぞれが１００ページの２個の大きなエリアがスワップされる場合、シーク時間は、２ビジット（読み出し＋書き込み）＊２エリア＊１０ｍｓ、すなわち４０ｍｓのオーダーである。１メガバイト／秒の転送時間は、１００ｍｓのオーダーである。全てを計算に入れると、全体の時間は容易に１秒以下となる。しかしながら、もし各ページがディスク上の異なるエリアのシークを要する場合、シーク時間はそれ自身、２ビジット＊２００エリア＊１０ｍｓ、すなわち４秒のオーダーとなる。これはバックグラウンドオペレーションを終了するために待つには長い時間である。この時間は、所定のスワップハンドラ要求においてビジットされる異なるエリアの数を限定することによって制御される。
【０３９７】
あまり重要でない注意として、個々のスワップ（およびムーブ）を結合スワップ要求中に蓄積する場合、エリアの最大数を越えると、新しい提出を受け入れる必要があり、その後このようにして更に蓄積されたオペレーションは、新しい提出を要することなく処理されることがある。その理由は、エリア限界に達した場合、現在の提出および蓄積されたものは共に処理され、あなたは、最後の提出を全て同じエリア内となるであろうその後の提出から分離したいと思うためである。
【０３９８】
スワップ（即ちムーブ）提出は次の形を有している：
do swap A location,B location,A to B only
スワップの後、移行状態は安定化されることが理解される。しかしながら、さらにこのステップは、複数の提出を蓄積し共に処理することを可能とするために遅延されることが理解される。言い換えると、小さな移行ステップが大きな移行ステップに蓄積される。これはより大きな移行ステップを失う機会を増やすが（クラッシュに利用可能なより多くの時間）、全ての仕事はクリーンアップされ如何なるユーザ情報も含まない、即ちその仕事は再生が可能である。
【０３９９】
スワップハンドラ要求を蓄積し構築するとき、各ｄｏ＿ｓｗａｐ提出は、遅延ムーブマップを通じてその２つのスワップロケーションを走らせる。その１つが読取り側マッピングを有しているとわかる場合、データを取り込むための本ロケーションが更新される。スワップの一部としてそのロケーションが重ね書きされるので、読取り側マッピングの処理の一部としてマッピングエントリ自体が（遅延ムーブマップから）検出される。一方、書込み側マッピングであるとわかる場合、その他のページはその読取りがこのページに転換されつつあり、適切とされるページのデータを持つに違いない。従って、書込み側エントリのリンクリストにわたって循環し、適切なムーブがスワップ要求に追加される。これら全ては共通のソースであるＡからＢ、ＡからＣ、ＡからＤ等と共有する点に注目すべきである。そして書込み側および関連する読取り側のエントリは、マップから検出される。
【０４００】
どのロケーションが全体的に読み取られ書き込まれているかを見るとき、ムーブ提出の結果として、同じページを異なる書込みに対するソースとして読み取ることができる。それゆえ、実際は１つの読取りが多数の場所にルートをとるが、所与のページの１つより多い「読取り」が存在し得る。その一方で、２つのエントリは同じロケーションに対して書き込むべきではない。これは情報の喪失を意味し、起きてはならないことである。
【０４０１】
提出が処理されているとき、３つのテーブルが生成される。第１のものは、実際のロケーションと同様に最初に述べられたロケーションを保持して（後遅延ムーブマップ処理）、提出を順序立てた単なるリストである。他の２つのテーブルは、読取り及び書込みエリアをトラックする。各々は、関連するサイズを有するソートされた開始エリアロケーションを表わす。ページリファレンスがどちらのテーブルに追加されるときでも、リファレンスが既存のエントリに編入されるかあるいはその中に見つかり（変化しないかあるいはエリアのサイズが増加する）、２つのエリアが合体するかあるいは新しいエリアが開始される。それゆえ、追加後のテーブルによって表わされるエリアの数は、同じであるか増えるか少なくなるかのいずれかとなる。しかしながら、存在する読取りエリアよりも多数の書込みエリアが常に存在する（これは２つの読取りが同じ書込みロケーションに対して向けられることはできないということからくる）。図５１を参照されたい。
【０４０２】
読取りテーブル内のロケーションは、可能性のあるあらゆる遅延ムーブマップ処理を反映する。換言すれば、それらは実際のものかオリジナルのものかを言及したロケーションである。読み取られているロケーションのみがリダイレクトされることに注目されたい。遅延ムーブマップは書込みロケーションをリダイレクトしない。
【０４０３】
（ムーブ提出と対立する）スワップ提出のために、Ａ＿ｌｏｃ及びＢ＿ｌｏｃは読取り及び書込みの両方のテーブルに追加される。どのデータが実際に読み取られ書き込まれているかについてこの時点では何とも言えないが、実質的に全ロケーションのＯＲを取ることによって作用されたロケーション（エリア）を識別することができる。ムーブ提出では、Ａ＿ｌｏｃは読取りテーブルに追加され、Ｂ＿ｌｏｃは書込みに追加される。
【０４０４】
特定されたロケーションがムーブの目的地として以前に書き込まれている場合は、読取りテーブルに対する追加は無視される。この書込みがスワップの一部であった場合は、関連する読取りもまた処理されており、既にテーブルに存在するので追加は無視される。一方で、書込みが前のムーブの目的地であった場合は、そのロケーションは読み取られる必要はない。例えば、ＡがＢにムーブされてＢがＣとスワップされる場合は、Ｂのオリジナルの値は、書き込まれたものの一部というわけではなく、それゆえ読み取られる必要はない。従ってムーブ提出の右側のみチェックする必要がある。
【０４０５】
読取り及び書込みエリアの全体数を超えるように、あるいは転送されているページの全体数がその限界に等しいように、あるいはタイムアウトが生じるようにということが一旦試みられると、処理はスワップハンドラ要求のセットアップへ進む。
次の主要なステップは、指示されたデータをメモリに読み取ること、及び、読取りインデックスを集合的データ読取りにし、関連する書込みページインデックスを生成するマッピングテーブルを確立することである。書込みインデックスは、書込みエリアテーブルによって表わされる集合的データ内のどこに属するかを示す。既に述べたように、読取りデータ全体のサイズは、書き込まれているものよりも小さくてもよい。これは、読み取られるいくつかのページは書込みデータ内に複製されるべきであるからである。
【０４０６】
何が読取りであり書き込みであるかの（スワップエリアを通じての）全体のページカウントにおける差は、読取り側の複製を「独立」しているものとしてみなし、実際に何が読み取られたかのページ（インデックス）にそれらを複製することによって処理される。それゆえ、読取りインデックス範囲は書き込み範囲に等しいであろう。新しいインデックスが割り当てられるのでオリジナルの読取りデータが拡張される。図５２を参照されたい。
【０４０７】
読取り−書込みインデックスマップの生成方法は、言及された読取りロケーション全てを通じて循環する既に論じた最終目的地アルゴリズムを実質的に使うことである。ムーブ提出及び複製を処理するためにいくつかの変更が必要である。
提出を通じて循環しているとき、目標は、読み取られている「言及された」ページを識別し、集合的読取りデータのどこに位置させるかを決定する点にある。このページの移動は、その最終書込みロケーションを決定する提出を通じてトラックされる。このロケーションは、書込みページインデックスを生成するために書込みエリアテーブルと相互に関係づけられる。書込みインデックス関連に対する読取りは、マップに格納される（すなわち、マップを通じて読み取られているページに対してインデックスを走らせることによって、その結果生じる書込みインデックスは、そのページが書込みバッファのどこに位置するかを識別する）。書込みインデックスは決して２回生じるべきはではない。更に、全ての読取り及び書込みロケーションが処理されるべきである。読取りページインデックスが決定されたとき、既にそれが使われているとわかっているのならば、新しい「複製ページ」読取りページインデックスが割り当てられ、ページが複製される。
【０４０８】
図５３の例は、何が読み取られ、それが結局どこに書き込まれるかを決定する処理について説明している。符号←→はスワップを表し、符号→はムーブを表す。最終の読取り及び書込みデータパターンが、手によってなされたように、太字部分の読取り及び書込みの組のみで示されている。
最終目的地アルゴリズムは読取り−書込みインデックスマップを生成する。このアルゴリズムは、全てのスワップ及びムーブ要求を通じて循環し、各読取りロケーションが最終的にどこに書き込まれることになるのかを決定する。読取り及び書込みロケーションは、読取り及び書込みエリア内のページインデックスへ変換され、読取り−書込みマップを更新する。情報のトラッキングは、それが直面したとき、ムーブ提出のソース（左）側において更新される。ムーブ提出はソースの分岐を表わす。アルゴリズムは全提出を通じて循環するか、それぞれに対して残りの提出を通じて循環するので、その動作は、ｎ＋（ｎ−１）＋（ｎ−２）＋・・・＋（ｎ−（ｎ−１））すなわち自然数ｎ2 としてモデル化される。これは特別なことではない。１００個の提出が存在するかもしれない。アルゴリズムの動作は、走査の多くを取り除くために、全ての類似のロケーションともリンクすることによって多いに改良される。このアルゴリズムはｎ1 のオーダーである。
【０４０９】
図５４は読取り−書込みマップの構築を例示している。全ロケーションは、読取りデータ及び書き込みデータアレイ内と共にマップ内で一度に更新されるということに注目されたい。最終結果は図５３で手によって前に決定されたものと整合する。
読取り−書き込みマップは、拡張された読取りデータを書込みデータへ再オーダーする手段を提供する。この形式では、書込みデータはスワップエリアに書き込まれる。オペレーション完了前にシステムがクラッシュした場合データがどこに書き込まれることになるのかを反映するためにスイッチページが更新されるので、オペレーションの再スタートが可能である。
【０４１０】
図５５Ａに示されるアルゴリズムは、読取りデータを再オーダーする。これは２つのテンポラリページバッファの使用を伴い、そのバッファを通じて置き換えられたページがシフトする。ｗｒｉｔｅ＿ｄａｔａ＿ｏｒｄｅｒアレイは、各ページに対して読取りデータかあるいは書込みデータかのいずれのオーダーであるかを指示する。最初、このアレイは偽（ｆａｌｓｅ）である。このアルゴリズムは、ｗｒｉｔｅ＿ｄａｔａ＿ｏｒｄｅｒアレイのトップで開始し、「書込みオーダー」にまだないページを捜索する。それが見つかったとき、読取り−書込みマップは、ページが本来どこに属するかを決定するために調べられる。それをこのロケーションにコピーする前に、（読取りデータのオーダーにもあるべき）現在の内容はテンポラリページにムーブされる。その後、読取り−書込みマップは、テンポラリページをどこに置くかを見つけるために再度調べられる。ついにはテンポラリページが原開始点に書き込まれるまで処理がループする。図５５Ｂはアルゴリズムを例示している。ディスク上のスワップしているページのように、スワップしている読取りデータは閉ループ交換の組の処理の問題である。
【０４１１】
再オーダーのアルゴリズムは、シフトするページをテンポラリページを通じて取り除くために最適化することができる。基本的には、呈示されたアルゴリズムがさかのぼって実行される。書き込まれる初期ページに対するデータは、テンポラリバッファに保持される。テンポラリバッファのデータに対応する最終ロケーションに循環して戻るまでムーブが実行される。最終ロケーションのデータをムーブアウトしたあと、テンポラリバッファがムーブインされる。
【０４１２】
図５６は、（図５３に始まる）現在の例での再オーダーアルゴリズムの実行を例示するものである。２つの閉ループが処理される。第２の閉ループの処理は、既存の（丸で囲まれた）「Ｈ」上に生じる「Ｈ」の書込みで示される。重ね書きされたロケーションは複製されたページであり、そのロケーションの割当ては任意である。ページは複製され、それでも独立のものとして取り扱われるので、そのエリアに重ね書きする必要はない。最適化はこのような重ね書きを招き、それらを取り除くために読取り−書込みマップを調節することができるが、おそらくその効果は値するほどのものではない。複製は復帰するディスクから発生するムーブ提出から生じるが、これはそうはしばしば生じるものではない。
【０４１３】
遅延ムーブマップ及びスワップ処理が合体する例は、ロケーションのうちの２つがその他の場所の共通のロケーションにマップされるような２つのスワップを含む状況である。特に、（遅延ムーブマップを介して）読取りを目的として、ＡがＢにスワップされＣがＤにスワップされるがＡ及びＣは両方ともＲにマップされる場合を取り上げる。読取りエリアはＲ、Ｂ及びＤである。ロケーションＲはスワップエリアで複製され、そしてＡ、Ｂ、Ｃ及びＤが書き込まれる。
【０４１４】
図５７は、復帰(Reversion) 及び遅延ムーブマップセクションの例から導かれる図２６Ｊに基づく。他のこのセクションにおいては、スワップが同時に示されている。図５７は、全てのスワップは１つのスワップハンドラ要求（Ｈ１、Ｈ２及びＨ３と全て同じであることに注目されたい）でなされること以外、図２６Ｍと同じ結果を例示する。スワップ前の遅延ムーブマップはロケーションＣ及びＥの読取りをＢにリダイレクトする。図５７のスワップ提出は、図２６Ｊ以後のスワップ（全てがロケーションＡを通じてスワップされる）に従うことによって構成される。
【０４１５】
スワップセットアップの動作の項に戻ると、最終目的地アルゴリズムはｎ2 のオーダーであることを既に確認している。更に、ロケーションのＯＲを取って書込みエリアテーブルに入れるとき、アルゴリズムは、新しい提出の所与の側がムーブの目的地であるかどうかを知る必要がある。その結果生じる走査もまたｎ2 のオーダーである。両方のアルゴリズムともインデックスやリンクを使うことによってｎ1 に低減される。
【０４１６】
ハッシュヘッダテーブルと、整合が見つかるまで（あるいは新しいエントリが追加されるまで）続く不一致のリストと、を通じて全てのディスクロケーションが走らされる。ロケーションされたエントリはロケーションに対してインデックスを識別する。このインデックスはヘッダのテーブル内のテーブルエントリを識別する。インデックスのテーブルエントリは、関連するロケーションの提出テーブルにおける最初の発生を識別する。それは、そのロケーションがムーブの目的地である場合にセットされるフラグも含む。このフラグは走査を置き換え、そして読取り−書込みインデックスマップアルゴリズムは相対的に短いリストに従うことができる。左右のリンクフィールドが提出テーブルに追加されリンクがサポートされる。図５８を参照されたい。
【０４１７】
スワップ中の読取り処理
応答を最大化するために、スワップ要求の最中に、ユーザの読取り要求が即座に処理される。換言すれば、エンジンは、時間がいくらかかかるスワップ要求を完了しなければならないがいくつかのユーザの読取り処理を中止することができる。読取りに対して効果的なロケーションが遷移マップを使って決定され、そして、現在のスワップ要求によってページが作用されるかどうかを知るためにチェックされる。もし作用されないならば、読取りが渡され、さもなければ適切にリダイレクトされる。
【０４１８】
スワップハンドラの処理段に依存して、スワップに含まれるページの読取り要求が別様に処理される。ハンドラがスワップに含まれるデータを収集している（読込んでいる）間に読取りがなされる場合は、読取りはプリスワップされたロケーションに向けられる。読取りロケーションは、スワップが完了したと推定される遷移マップに基づく。しかしながら、スワップされているデータはその適切なロケーションにはないので、読取りロケーションはそのプリスワップロケーションにリダイレクトされる。処理すべき他の段は、全データが集められスワップエリアに書き込まれた後である。この時点で、スワップハンドラはデータを適切なロケーションに書き込み始める。しかしながら、この処理が完了するまで、作用されるロケーションは基本的に過渡的である。従って、結果的に読取りロケーションに書き込まれることになるページのコピーを保持するスワップエリア内のロケーションに読取りロケーションがリダイレクトされる。もちろん、スワップエリアはメモリに保持されるので、単にデータを戻し、読み取られた実ディスクをスキップすることもできる。
【０４１９】
どんなユーザの読取りについても即座に処理するようにエンジンは試みるが、切れ目のない読取りのストリームはスワップ要求の完了を延期することはできない。これは、遷移の不確定な遅延を新しい安定したイメージにするものである。最大遅延を超えた後は、スワップ要求が勝る。
読取り要求が生じる場合は、オペレーティングシステムはスワップ要求が完了するまで待機する。これは、ユーザ応答には大きな影響はない。この理論は、新しい書込みがオペレーティングシステムのキャッシュに対してなされている（しかしまだエンジンに対してではない）初期の期間中、フォアグラウンドアクティビティが検出されるということである。それゆえ、エンジンは（キャッシュがフラッシュされるかオーバーフローするとき）実際の書込みをいくらか予告し、その間、現在のスワップハンドラ要求を完了する。スワップは通常、バックグラウンドにおいて実行される最適化である。
【０４２０】
全書込みデータがオペレーティングシステムのキャッシュにぴったり合う場合、書込み処理を即座にする必要はない。多くのデータが書き込まれてキャッシュがオーバーフローする場合、現在のスワップ要求を完了するために追加される時間は、それほど重要ではない。「キャッシュのサイズよりも多い量の」データを書き込むために多くの時間がかかり、ユーザはこの期間が過ぎ去るのを待たなければならない。
【０４２１】
書込み要求に応答して、エンジンが停止し得る（要求を受けるのをストップできる）ので、現在のスワップ要求を完了することができる。従って、ユーザがデータを書き込むという行為はエンジンが速く応答することを妨げ、読取り要求が将来現れるに違いない。例えば、アプリケーションが少量のデータを書き込み、停止し、いくつかのデータを読み取る場合について取り上げる。停止中、オペレーティングシステムは、書込みをフラッシュし、それをエンジンへ渡す。仮に書込みが即座に完了するとしたら、アプリケーションの読取りが続くであろう。しかしながら、エンジンは、書込みに取り組む前にバックグラウンドの仕事（スワップ要求）を済ますのに忙しい。読取りが処理される前に書込みは完了すべきである。ユーザは図５９に示されるように待機する。
【０４２２】
この応答遅延は、２つの技術のいずれでも避けられる。第１は、ＯＳは、そのキャッシュのフラッシュを開始する前にエンジンの状態を問い合わせ、エンジンがスワップホルダ要求の最中にある場合に遅延する。この待機の間、ＯＳはエンジンに対してフォアグラウンドアクティビティ中であることを知らせ、エンジンが素早くそのバックグラウンドの仕事を終えて書込み処理ができるようにする。エンジンの準備ができるのを待機する間、ＯＳは、（フラッシュの前に）即座にエンジンに渡される読取り要求をアプリケーションが生成できるようにする。読取りを取り扱うためにそのバックグラウンド処理を中断することができるので、ユーザ応答は最適になる。この解決策は、オペレーティングシステムのキャッシュフラッシュ処理を修正することを呈する。図６０を参照されたい。
【０４２３】
第２の技術は、キャッシュをフラッシュする前にオペレーティングシステムが待機する時間よりも長い時間期間をバックグラウンドの仕事を開始する前に単に持たせるだけである。換言すれば、エンジンのバックグラウンドアクティビティがＯＳのフラッシュ後に生じることを確保するということである。
第１の技術の利点は、エンジンのバックグラウンドアクティビティのためのキャッシュをフラッシュする前の時間を使用することができるという点である。しかし、第２の技術はＯＳの修正なく実現できる。結局そのキャッシュをフラッシュする前にＯＳが遅延するのはどれくらいの長さかとそれはなぜであるのかという疑問が生じる。一般的な理由は、ユーザの応答性を改善することにあるようである。取り消しが早くても（すなわち全キャッシュの一部分だけがフラッシュされる）、待機することで完了する処理はないので、応答が改善される。「良好なバックグラウンドセクション」を参照されたい。
【０４２４】
スワップ要求が完了する間、いくつかの書込みを吸収できるように、バッファするレイヤをエンジンに対して追加することができる。しかしながら、これはほとんどのオペレーティングシステムによって提供されるキャッシングで冗長である。従って、タイミングを含む技術が好ましい。
ファイルレスキュー
ユーザはディスクデータの汚染のため、コンピュータをブートすることができ ないかもしれない。例えば、ウィルスがスタートのために必要なファイルを汚染できたのかもしれないし、あるいはユーザが通常のオペレーションの邪魔をする新しいソフトウェアドライバをインストールしたかもしれない。エンジンのうちの１つが使用されていると仮定すると、早い時間、例えば１日前にディスクを復帰することは簡単である。（コンピュータがスタートしないという問題のときに、そのディスクを復帰させるという要求に対してコンピュータをどのようにスタートすることができるか疑問に思うかもしれない。その答えは、ハードディスクからコンピュータを完全にスタートすることはできないが、エンジンはそのブートする能力をコンピュータのメモリに保護しているからということである。それゆえ、エンジンはＯＳを完全にスタートさせようとする前に入り込み、システムが完全にスタートできたときには復帰できる。）
ところで、ユーザは新しい問題に直面する。コンピュータは機能しているにもかかわらず、あたかも１日前の状態に戻っている場合である。その時間以来なされた仕事は、もはやディスク（メインエリア）には現れていない。しかしながら１日前とコンピュータのブートが止まったときとの差の全ては、復帰の一部としてヒストリバッファに大体記憶されていた。従って、最近の仕事は本当は失われてはいない。問題は、スタートできないでいる（クラッシュしている）コンピュータに何をもたらすかであるので、ユーザは必ずしも全てのヒストリ情報を現在に持ち込むことは望んでいるわけではないという点である。その代わりに、選択して回復させることが望まれるのである。
【０４２５】
汎用ログデータの取扱いの一部として、エンジンは、変更された全てのファイルのネーム、辞書ロケーション及びアクセス時間をログする。したがって、クラッシュからの回復の後で、エンジンはリバージョン（復帰）からクラッシュまでの間の期間（回復期間）の間に変更されたファイルのリストを確立することができる。次にユーザは、回復させたい特定のファイルをこのリストの中から選択することができる。それに応答して、エンジンは、シミュレートされたドライブを通じて、適切な時間だけ遡り、前述の特定ファイルに現在のイメージをコピーする。この様にして、ファイルはレスキューされる。
【０４２６】
提示されたファイルは、最新のバージョンのリストと供に記憶される。これは、ユーザに提示される情報量を減少させる。非ユーザファイルをフィルタリングすることは、さらにリストを減少させる。他の形態の提示としては、ディレクトリ及び回復期間内に変更のあったファイルにのみ対応するファイルエントリ（file entries）を含むディレクトリツリーを作ることである。ユーザは、Microsoft Windows Explorerを使用するのと類似する方法で、そのツリーを閲覧し、回復するためのファイルを選択する。
【０４２７】
リバージョンを過ぎるとユーザはある時間に進んで作業を続けるので（コンピュータを再スタートして）、回復期間の開始及び終了時間は変化しない。このように、ファイルに関連したリストは、参照されるヒストリー情報が利用可能である限りにおいて、安定している。このメカニズムを通じ、回復期間中に変更されたファイルのみを参照することによって、ユーザが全てのファイルの回復を期待するということは非常に重要なことである。例えば、ユーザがかれらのコンピュータを再スタートし、あるワードプロセッシング文書を読出し、幾つかの変更をして記憶し、そこでユーザは回復期間に「失った」バージョンを必要としていたことを認識したとする。「回復」可能なファイルを見たとき、リバージョン後に作成されたバージョンを含んでいることは混乱を生じさせることとなる。
【０４２８】
したがって、ファイルレスキュープロセスは、リバージョンが為された時間後ではなく、リバージョンに先立って変更されたファイルのセットを識別することを含む。このリストは、一般に安定しており、ユーザに対してこの期間中に変更のあったファイルを（回復のために）選択する手段を提供する。リストの提示は、ソート、フィルタリング、及びツリー構造（階層）を含む。
【０４２９】
データリバージョンの実施形態の実際の使用
要約すると、上述される本発明に係わる主な実際のアプリケーションは、以下の機能を実行するものである。
１．早い時間におけるユーザディスクの現在のイメージを回復させる。このプロセスは、ハードディスクからの完全なＯＳの通常のブートの前又は後に開始される。
【０４３０】
２．早い時間に対応したユーザディスクのシミュレートされたイメージを確立し、ユーザに対して、まるでそれが実際のディスクであるかのように、このシミュレートされたディスクへのアクセスを許容する。
３．ユーザに対してシミュレートされたディスクへの書込みを許容し、このようにしてユーザのための作業スペースを作る。作業スペースの内容は、現在の又は早い状態のそれらのディスクイメージに由来するものである。
【０４３１】
４．辞書及びＯＳのファイルプレゼンテーション手段にフック又は補足され、ユーザにファイルのより早いバージョンのリストをユーザに見せることを許容する。リストから選択することが可能であり、回復されたファイルは、現在のバージョンを置き換えるか、又は新しいファイルとしてコピーされる。リストは、エンジンによってログされるＯＳのファイルアクティビティから生成される。与えられたファイルに対して、エンジンは、そのログを走査することによってファイルの利用可能な早いバージョンのリストを構成し、パスに従って、選択されたファイルに対して、そのファイルの修正、ファイルのリネイム、およびファイルの移動（１つのディレクトリから他への）を行う。
【０４３２】
５．与えられた期間である時間だけ戻って現在のイメージが復帰した後、この期間内に変更されたファイルのリストが確立され、それらの回復が許容される。
６．現在及びシミュレートされたディスクの役割を一時的にスイッチすることをユーザに許容する。したがって、ユーザが現在のイメージにアクセスしたとき、ディスクへのアクセスが方向付けらるのはシミュレートされたイメージであり、その逆も同様である。
【０４３３】
７．ハードディスクの冗長性のレベルを達成するために、現在のイメージ及びヒストリー情報の同期と連続的なダウンロードが外部ハードディスクに対して提供される。メイン内部ハードディスクが失敗したとき、ユーザは外部ハードディスクから実行することができる。また、失敗したディスクが置き換えられた後に、外部ディスクは内部ディスクの再初期化に使用される。このプロセスは、ユーザに作業の継続を許容することと同時に発生する。
【０４３４】
８．ディスクリバージョンの安全ポイントと関連したメモリ（ＲＡＭ）スナップショットを使用することによって、ある時間の早いポイントからアプリケーションが再スタートすることを許容する。
発明の実施形態
本発明に係わる種々の実施形態は、１つ又はそれ以上の不揮発性記憶システムであるハードディスクを利用する全てのタイプのコンピュータに適用することができる。そのようなタイプのコンピュータは、それに限定されるわけではないが、パーソナルコンピュータ、ネットワークサーバ、ファイルサーバ又はメインフレームであり得る。図６１は、本発明が構築されることができるパーソナルコンピュータ１００の一例を図示している。図６１に示される、パーソナルコンピュータ１００の一例は、モニタ１１０、キーボード１１２、中央処理ユニット１１３及びハードディスク１１４を含んでいる。
【０４３５】
さらに、図６２は、本発明の異なる実施形態を図示している。本発明、特にここで記載される「エンジン」は、ソフトウエア上に構築され、フロッピーディスク１１６、ＣＤ−ＲＯＭ１１８又は永久的または一時的なメモリ１２０のようなキャリア媒体上に、又は電子データ送信１２２として、コンピュータが読取り可能な形態で記憶され、さらにハードディスク１１４に記憶される。
【０４３６】
上述した種々のコンピュータが構築する実施形態の構築のために本発明に係わるソフトウエアは、一つの例示的な形態として、フロッピーディスク１１６又はＣＤ−ＲＯＭ１１８のようなキャリア媒体として、又は電子データ送信１２２によって販売され、限定的な意味ではないが、ＩＢＭコンパチブルのパーソナルコンピュータのようなハードデバイスにインストールされる。さらに、本発明の一つの実施形態に従えば、ＩＢＭコンパチブルのパーソナルコンピュータのようなハードデバイスには、WindowsTM Operating System（Microsoft Corporationから許可されているもので、Windows95TMを含み、Version3.1以降のもの）のコピーも、コンピュ−タのオペレーティングシステム機能を実行するためにインストールされている。代わりに、他の実施形態に従えば、本発明の他の実施形態に係わるソフトウエアは、Apple Computerから許可されているMacintoshTMコンピュータシステムに適用することができる。しかしながら、実施形態の例は、本発明を適用することができるコンピュータプラットフォームを限定するようなものではない。
【０４３７】
ここに開示される実施形態は、ソフトウエア又はハードウエアとして構築されるものとして記載されているが、限定して記載されていない限り、ここに言及される発明は、ソフトウエア又はハードウエアのいづれか一方での構築に完全に限定されるものではない。さらに、ソフトウエアは、ファームウエア及びシリコンベース又は他の形態のハードワイヤロジック、又はハードワイヤロジック、ファームウエア及びソフトウエアの組み合わせ、又は適当な代替物によって構築されることができ、したがってその逆も可能である。
メインプロセッサを基礎としたファイアウォール保護
多くのパーソナルコンピュータのコアは、メインプロセッシングユニット（例えば、Intel Pentium）、ＲＡＭ及びハードディスクから構成される。重要な関心事項は、ハードディスクに記憶されているデータの完全性の保護である。従来の方法は、バックアップを取る、全て又は重要データをハードディスクから他の媒体にコピーすることである。変更された情報を取り戻すための能力を提供するために、上記において種々のリバージョン方法を記載してきた。これらは、失われたデータを保護するための強い手段を提供し、そこでユーザは、ある予め決められた時間において停止やバックアップを取ることを要求されていない。それら自身によって、リバージョン方法は、それらの回復情報を最新のユーザデータと共に同じディスク上に記憶する。また、メインディスクに対する変更が複製されている２次外部ディスクを作る方法も上述されている。これは、ハードウエアの冗長性レベルを追加するものである。
【０４３８】
全てまたは一部のリバージョン方法はディスクコントローラの一部として構築されると述べてきたが、これは、もしそうでなければ相対的に簡素であったコンピュータの一部に大きなコストを追加することとなる。しかしながら、メインプロセッシングユニットから独立したハードウエア中のリバージョン方法における動作している重要部分は、重要な効果を有している。それは、リバージョンソフトウエア及び物理的なディスクを、メインプロセッシングユニット中のバグやウイルスから分離する。例えば、ディスクを制御する適当なハードウエアと直接データを伝送することによって、悪意のあるソフトウエアがパーソナルコンピュータのディスクを汚染することをほとんど止めさせる。新しいディスクドライバの追加を許容することとなるが、傷つけ易いウインドウ（window of vulnerability）が存在する汎用のオペレーティングシステムの性質として、それはほとんど固有のことと言える。
【０４３９】
したがって、データの損失に対する保護は、メインプロセッサにおいて実行されるリバージョン方法によって強力に高められるが、それは多くの方法によって傷つけられ易い。バグやウイルスはリバージョン方法を一回りして、直接ディスクを制御し、リバージョン方法によって使用されているＲＡＭを損ない、隠れ、又は誤ったダイアログをユーザに表す。リバージョン方法の重要な要素がハードウエアとは独立に構築されているときには、ファイアウォールの形態を、メインプロセッシングユニットに表れる悪意のある行動がディスクの初期状態を保護するリバージョン方法と干渉することができないように確立する。ハードウエアとは独立に確立すること又はディスクコントローラに適当に追加することにおける問題は、コストが追加されることである。
【０４４０】
一般に、メインプロセッシングユニットは、既に十分なＲＡＭ、処理力、及びリバージョン方法の活動を実行するための時間を有している。しかしながら、バグやウイルスの影響を受け易い。したがって方法は、多くの新しいハードウエアを要求せずに、どのようにしてリバージョン方法の重要な要素と残りのシステムとの間にファイアウォールを確立するかを記述することとなる。重要な技術は、誰でも扱える手段を通じて、メインプロセッサのＲＡＭ及びハードディスクへのインタフェースをメインプロセッサによって通常にアクセス可能なものから分離することである。内容を変更することができないので、ＲＯＭ（読出し専用メモリ）へのアクセスは制御する必要がない。
【０４４１】
一般に、メインプロセッシングユニットによる、保護リソースへのアクセスは不可能である。しかしながら、メインプロセッサがある一連のインストラクションを実行したときには、保護リソースへのアクセスは可能となり、メインプロセッサは保護されたＲＡＭ又はＲＯＭの予め決められたロケーションのコードの実行を開始する。同時に、未知のコードへの分岐からメインプロセッサを保護するために、一般に割込みは不可能となる。
【０４４２】
予め決められたロケーションに対するプログラムコントロールを送信するというコンセプトは、ゲートの形態である。ゲートを通り抜ける前に、保護リソースへのアクセスは不可能となる。一旦、ゲートを抜けてしまえば、保護リソースへのアクセスは可能となる。ゲート（又は複数のゲート）を通じたプログラムコントロールの送信は、次に保護リソースへのアクセスを可能とするハードウエア（「ゲートモニタ」）によって検出される。
【０４４３】
悪意のある又は制御不可能なプログラムは、通常ゲートを通り抜けた後に実行されるコードの一部であるコード（ＲＯＭ）の中間へジャンプする。これは、通常そのようなアクセスをするコードから、保護リソースへアクセスするように導くことを可能とするが、それは（即ち、制御不可能な方法における）間違って入力されたものである。コントロールはゲートを通じてこのコードへはフローしないので、ゲートモニタは保護リソースへアクセスすることができない。このように、不都合な結果は生じない、即ち、ディスクインタフェースはアクセスされず、またリバージョン方法のＲＡＭは変更されない。おそらく、オペレーティングシステムは、結局はオフェンディングタスク（offending task）を打ち切るであろう。
【０４４４】
ゲートを構築する１つの技術は、外部割込み及び関連するゲートモニタハードウエアを利用するものである。メインプロセッサのレジスタ（又はＲＡＭ）における種々のパラメータを設定し、外部割込みをトリガすることによって（例えば、i/oポート又はあるメモリロケーションに書込むことによって）、コントロールはリバージョン方法のコアコード（「ドライバ」）を通過させる。プロセッサーはこの割込みに応答するので、ゲートモニタはそうでなければ保護されているリソースへのアクセスを可能とする。他の技術は、割込みを制御するためのインストラクションを含んだコードの特定のロケーションへ分岐又は送られるというものである。ゲートモニタがこのロケーションにおける実行を検出すると、次に保護リソースへのアクセスが可能となる。ドライバ及びエンジンの概念は、基本的には等しい。
【０４４５】
ドライバがそのオペレーションを完了すると、保護リソースへのアクセスが不可能となり、メインプロセッサは通常の保護されていない実行を再開することを許容される。そのようなケースは、ディスクへのアクセス要求のサービスと、割込みのサービスが許容されたときのドライバからのディスクへのアクセス要求のサービスの両方で起きる。後者のケースは、ドライバの中から、定期的にゲートを閉じ（保護リソースへのアクセスが不可能となる）、割込みを許容し（それらのサービスを許容し）、次にリエントリ（re-entry）ゲートを通じて戻されるコードへ分岐することによって構築される。このゲートは再度割込みを不可能とし、処理は現在の要求に戻る。
【０４４６】
ドライバを含んでいるＲＯＭは不揮発メモリであって、コンピュータの開始に際しては常に正常な状態であることが重要である。ドライバのコードが通常のブート処理の一部としてロードされる場合、それは汚染される可能性がある。しかしながら、バッテリバックアップＲＡＭ、ＥＰＲＯＭ、及びフラッシュのような他の不揮発技術を使用することもできる。それらの内の幾つかは、不揮発メモリの変更が許容されている。そのような場合、現状のドライバの全て又は一部を置きかえる新しいソフトウエア（コード）の暗号化及び正当性の検証が、ドライバの汚染を防止する。
【０４４７】
ドライバの制御下にあるハードディスク又はディスクは、コンピュータの内部又は外部にある。メインプロセッサからディスクへのインタフェースは、通常バス、例えばＩＤＳ、ＳＡＣＳ及びＵＳＢを使用して行われる。
コンピュータのユーザへ利用し易い物理的スイッチを追加することは、回復不可能なオペレーションを実行することが可能なドライバへ信号を送る手段をユーザに提供する。そのようなオペレーションの例は、トータルなヒストリー情報の消去及び再記憶が要求されているヒストリー情報の廃棄である。後者の例において、ウイルスは非常に多くの新しいデータを書込もうとするので、言うなれば、一日前に再度記憶しようとする能力は失われることとなる。ドライバが（ＯＳを通じて）ユーザにこれがアクセス可能か尋ねるとき、ウイルスはその質問を遮り、ユーザからの情報なしにポジティブに応答してしまう。ユーザに物理的スイッチを押させることを要求することによって、ドライバはその質問に対する応答が本当にユーザからのものであるかどうかを検証することができる。ドライバがキーボードコントローラに直接アクセスすることができる限りおいて、このスイッチはキーを押すような形態を取ることができる（即ち、ウイルスはその応答を偽装することができない）。
【０４４８】
図６３は、一般のパーソナルコンピュータの内部アーキテクチャを図示している。ディスクへのアクセスは、メインメモリに適切にロードされているいかなるソフトウエアによっても可能である。図６４では、ディスクへのアクセスは、ゲートを通じてのみ可能である。一旦、メインプロセッサがゲートを通じて送ったら、ディスクへのアクセスを提供するエンジンの汚染しないバージョンが実行されているものと推定される。
【０４４９】
図６４において、一般にドライバのＲＡＭ及び汎用ＲＡＭは、メモリチップの同じシステムを用いて構築される。しかしながら、ドライバのＲＡＭのために確保されているロケーションへのアクセスは、ゲートモニタが保護リソースへのアクセスを許容したか否かに応じて条件付きで行われる。そのような許可がなされていないとき、ドライバのＲＡＭ（又は他の保護リソース）へのアクセスの発生は、無視されなければならない。また、システム欠陥が生成され得る。
【０４５０】
コンピュータの内部ディスクに加えて、着脱可能な２次外部ディスクを用いるコンセプトは、ハードウエアの冗長性を確立する手段として記載されている。２つのディスクは、外部ディスクにまだ記憶されていない内部ディスクに対する変更の移行に基づいて、同期が保持される。変更はその年代順に外部ディスクに書込まれて行くので、ドライバは原状態の再記憶又は回復を促進するための適切な構成を維持する。
【０４５１】
このアプローチには、３つの重要な利点がある。
１）コントローラにはめ込まれたドライバによって提供されるファイアウォール
ドライバは、内部ディスクに対するものと類似するバス上で外部ディスクと供にメインプロセッサで実行することができる。この場合、ドライバは、直接ディスクへの及びからの情報の送信を制御することができる。他の構築例では、ドライバは外部ディスクコントローラと協働する。ここで、ドライバは、ディスクインタフェースを通じて要求を受信する。これらの２つのケースにおける差異は、どちらのディスクインタフェースのサイドにドライバがあるかということである。これは、図６５に図示されている。
【０４５２】
完璧な状況であれば、どちらサイドにドライバがあっても問題はない。しかしながら、コンピュータ（ＰＣ）中には、ウイルス、バグ及びオペレータのミスによる汚染の可能性が存在する。したがって、コンピュータのメインプロセッサ中で実行されるドライバが汚染された場合、ディスク書込み信号は外部ディスクに保存されている全ての情報を無効にすることができる。したがって、ドライバが（ディスクの一部である）ディスクコントローラ中で協働することによって、クリーンな分離（「ファイアウォール」）がコンピュータと外部ディスクとの間に確立されるので、悪意のある又はそうでなければ好ましくない実行コードはドライバの作業及び不揮発性記憶を汚染することができない。
【０４５３】
ファイアウォール保護は、ドライバが、コンピュータからの要求を有効とし、同様にそれ自身の内部構造を保護することを許容している。このように、コンピュータが間違って、外部ディスクに記憶されているそれ自身のフィリングシステムを汚染したとしても、依然外部ディスクは一般的に汚染される前の状態に復帰することができる。言いかえれば、リバージョン及び回復を促進するドライバのデータ構造は、メインプロセッサによる汚染から安全である。
【０４５４】
ゲ−トモニタを使用してドライバの限界状態にある資源を保護して同時に主プロセッサ上でドライバを実行させる方法は、ドライバをディスクコントロ−ラに移すのと同じ結果を達成する。しかし、そのような方法は、コンピュ−タを必要とし、そのコンピュ−タの設計にはゲ−トに関する電子工学を含むことになる。一般に利用可能なコンピュ−タは、この設計がなされていない。これを考慮に入れて、ディスクに内蔵のドライバを提供することは、ファイアウオ−ル保護を提供する実用上の手段となる。
【０４５５】
ファイアウオ−ルの「ホ−ル」のみは、コンピュ−タがそれだけ多くの新しいデ−タをそのディスクに、従って外部ディスクに書き込むことができ、最終的には重要なヒストリ−状態が循環バッファの末端から押し出されるということである。これは予め規定された時間での再生能力の低下が差し迫っている場合にドライバがユ−ザに警報を出してシャットダウン（変更の受け入れを中断）する手段を提供することにより指向される。
【０４５６】
ヒストリ−ディスクセクタの状態を維持し保護するドライバをディスクコントロ−ラに配置してファイアウオ−ルを作り出す。ファイルレベルで実現されるドライバをディスクコントロ−ラに組み込んでもファイアウオ−ルを作り出す。このドライバは変更されるファイルの全体または一部を記憶する。ファイルレベルドライバに対するプロトコルはネットワ−クファイルサ−バに対するそれと類似している。しかし、この「サ−バ」は一つのコンピュ−タにサ−ビスするだけでヒストリ−状態の維持もまた行う。
【０４５７】
２） 1 セッションでのバックワ−ド・ルッキング・インクレメンタル・バックアップ・テ−プの書き込み
外部ディスクはまた実質的にはテ−プドライブとして実現されるか、あるいはテ−プドライブにより補われるかしてよい。テ−プドライブは、逐次でない記憶ブロックへのアクセスが高頻度ベ−スでは実用的でないということを除いて、ディスクドライブと同じ基本的特性を有している。外部「ディスク」に送られたデ−タが、テ−プに逐次書き込まれたデ−タの代わりか、あるいはそれに加えられる場合は、そのようなテ−プを使用して、テ−プ上に得られた与えられた時間に関連して与えられた状態からデ−タを回復することが出来る。ある固定時間間隔でのテ−プのインクレメンタル変化（増分変化）と共にユ−ザディスク（内部又は外部）のベ−スイメ−ジを書き込むプロセスは、テ−プが有限の容量を有するので、二つの再生モ−ドを助ける。第一番目は、得られたある時点の完全なディスク状態をそれは再び生じさせる。ここで、ベ−スイメ−ジは再生され、所望の時点までの間ずっとオ−ダ−された変化が読み取られてこのイメ−ジに適用される。別の第二番目の再生モ−ドはベ−スとディスクへの変化の全てあるいは一部の量の両方とも同時に再生することを含んでいる。この場合ドライバはテ−プから読み取られた情報をディスクに書き込むのに使用され、従ってテ−プは、ある時間にわたって一連の状態を表すように、再生される。
【０４５８】
勿論、テ−プはドライバの制御のもとにディスクの正確なイメ−ジを表すこともでき、従って十分に大きなディスクの再生は、ある時間にわたりユ−ザディスクの状態を再生もすることになる。このバックアップの場合、テ−プはユ−ザデ−タとともにドライバの内部デ−タ構造も含んでいる。そのようなテ−プは、本来ディスクとテ−プの両方が順次に処理されるので、直ぐに作られる。しかしそれはバックアップが書き込まれている間、休止を要求するか、ソ−スディスクの変更をそらしてしまうという欠点を有している。換言すれば、テ−プに書き込まれたデ−タはある一時点でディスクに対応しなければならない。テ−プ上に冗長性のあるバックアップを提供するというこの前進は、ある一時点でとは反対に、ある時間範囲にわたってテ−プベ−スのデ−タ再生を容易にする。それがディスクセクタベ−スでありまた同期（安全点）情報とドライバにより維持される他のログデ−タ（例えばファイルアクティビティ）を含むという点で、それは一般に伝統的な「ベ−スイメ−ジプラスインクリメンタルバックアップ」とは異なっている。それはまたテ−プがどのようにして作りだされるかという点でも異なっている。伝統的なインクリメンタルバックアップでは、ソ−スディスクの初期コピ−はテ−プに作られ、そのあと特定の遅れ時点で、どのような変更デ−タも更にテ−プにコピ−される。従って、ソ−スディスクのバックアップコピ−が作られている期間中、ユ−ザは絶えずバックアップテ−プに加えていくことになる。
【０４５９】
本発明について重要なことは、ユ−ザにデ−タの変更を続けることを許すと同時にバックアップテ−プをドライバが作りだすということである。基本的な処理は冗長性のある外部ディスクを維持するのと同じである。変更の生ずるのが多過ぎる場合は、テ−プバックアップ処理は、再スタ−トしなければならない（外部ディスクの変化の追跡が内部ディスクでなされた変化に遅れると同じ状況が起こる）。
【０４６０】
伝統的なインクリメンタルバックアップと違って、ドライバにより生成されるテ−プは一つの記録セッションで作りだされ、そしてテ−プが書き込まれた時間から後戻りする時間ウインドウをカバ−する。ドライバがソ−スディスクにインクリメンタル変化情報を記録しているので、このことが可能である。一つの記録セッションでインクリメンタルテ−プバックアップを作りだすことはバックアップ処理の複雑さを低減する。伝統的なインクリメンタルバックアップを作り出す理由は、節約差が一般に「完全バックアップ」よりも少ない時間となるという点で、バックアップ時間を低減するためであったが、また使用する物理的なテ−プ量の低減（記録が少なければスペ−スも小さい）のためであった。しかし、これらの利点は追加の処理と再生の複雑さという犠牲を払って得られた。これに反して、時間ウインドウに及ぶバックアップテ−プをドライバが作る理由は実際にこの特徴を得るためである。結果のテ−プは、他のより早い時期のテ−プに依存しないという点で完全バックアップであるということと、時間ウインドウにわたる再生能力を提供するということの両方の利点を有する。さらに、ユ−ザがインクリメンタルバックアップ実行を行った時間まで再生が可能なだけの伝統的なインクリメンタルバックアップと違って、ドライバのバックアップテ−プはバックアップされる時間ウインドウの実質的にどの使用可能な点からの再生を考慮している。これらのアプロ−チの差は、作業日の始めから終わりまで絶えずデ−タをテ−プにコ−するのと、単にその日の終わりに一つのテ−プを作ることとの差に類似している。
【０４６１】
３）バックワ−ド・ルッキング・インクリメンタル・テ−プ・バックアップのためのディレクトリ
前の段落でインクレメンタル・バックアップ・テ−プを作り出す新しい処理を検討している。実際は、テ−プは時間ウインドウ内のさまざまな時点からデ−タを再生するのに必要な全ての情報を含んでいるが、テ−プ上のデ−タ編成は選択的再生（例えば、単一ファイル）が複雑になるようなものである。ディスクドライブのバックアップとそのドライバのデ−タとして、テ−プ全体のディスクへの再生と、それに続く再生のための正規ドライバソフトウエアの使用は、テ−プのデ−タにアクセスする最も自然で簡単な手段である。しかし、テ−プを再生するのに利用可能なディスクドライブを必ずしも持てるとは限らない。従って、テ−プのデ−タを関連するファイルと相互関係をもたせるディレクトリを、ある時間に書き込まれるようにして、テ−プ上に含むと有用である。このようにして、テ−プからデ−タを再生するとき、このディレクトリを調べて読み取りに必要なテ−プの部分を決定する事が出来る。この事前解析はテ−プが単一経路で読み取られるようにする（ディレクトリがテ−プの前にあると仮定して）。ディレクトリは様々なバ−ジョンのファイルの全てをバックアップされる時間ウインドウの全体にわたって、或いは一度だけで割り当てる。後者の場合、時間ウインドウをこえてファイルにアクセスするためにテ−プはディスクに再生されなければならない。
【０４６２】
（結論）
本発明はコンピュ−タシステムに於けるディスクベ−スの情報再生の方法および装置である。これは一つ以上のハ−ドディスクを利用している全ての種類のコンピュ−タシステムに適用され、ここで、ディスクは一つ或いは複数の不揮発性記憶システムである。そのような種類のコンピュ−タは、限定はされないが、パ−ソナルコンピュ−タ、ネットワ−クサ−バ、ファイルサ−バ或いはメインフレ−ムであってよい。従って、本発明の様々な実施態様はディスク或いは他の記憶装置がインクレメンタルにまた連続してバックアップされることを規定している。これを可能とする本発明の特徴の幾つかは、ディスク情報のもとの状態を新しいほうの情報のために古いほうの情報が廃棄されるようなサイズの制限された循環ヒストリ−バッファにセ−ブすることを含んでいる。これらのオペ−ションを以下に要約する。
【０４６３】
1. デ−タをどのようにセ−ブするか。デ−タの「セ−ブ（保管）」或いは「コピ−」はデ−タが読み取られて別のロケ−ションに複製されることを必ずしも意味しない。本発明のセクタ或いはファイルの実現のいずれにおいても、これらのオペレ−ションは、たびたびポインタ（又はリンク）を調節して容易に実行される。実デ−タの移動を避けるためのポインタの操作はプログラミングの技法で良く知られている。
【０４６４】
2. セ−ブするのは何か。これはディスクセクタ、ファイル全体或いはファイルの一部のいずれかになる。セ−ブするものによって、本発明のセクタ（ディスク）レベルの実現かあるいはファイル（オペレ−ティングシステム）レベルの実現のいずれかが利用される。これら二つの実現は方法において本質的に異なるが上記ステ−トメントによれば両方とも同じ終了結果をユ−ザに与える。
【０４６５】
3. デ−タをどこにセ−ブするか。「循環バッファ」という術語を使う場合、たいていのプログラマは順方向書き込み及び順方向読み取りポインタ(next-write and next read pointer)のあるメモリ(RAM) のバッファを思い描くであろう。バッファが満杯になる場合、また古いデ−タは書き込みポインタが進むにつれて自動的に押し出されると仮定すると、順方向書き込みと順方向読み取りポインタは本質的には同じものとなる。メモリの代わりにディスク上で実現されるそのようなバッファはヒストリ−バッファを概念化する良い方法である。しかし、本発明はそれ自体をこの実現に限定しようと決して意図するものではない。代わりに、この実現は、上記ステ−トメントの効果を達成するシステムを得るための多くの良く知られた方法の一つにすぎない。それは、ヒストリ−「バッファ」で維持されるべき情報の全量に関して制限された新しく与えられた幾らかの情報のために古いほうのデ−タを廃棄するというものである。
【０４６６】
本発明のセクタ実現の場合、「循環バッファ」を実現するために二つの方法が述べられている。第一の方法は実際にバッファにデ−タを動かすことを含んでいる（あるならヘッダ情報の阻止とともに）。これは伝統的な循環バッファにそっくりである。第二の方法は、上記ステ−トメントの効果を達成するようなやり方で管理されるディスクロケ−ションにディスクの読み取りと書き込みを転送するためのマップ（それに限定はされないが、ツリ−かテ−ブルとして実現される）の使用を含んでいる。マップは通常、現在のデ−タが実際にどこに配置されているかを知っていなければならないが、それはオペレ−ティングシステムにより与えられたロケ−ションと関連付けられる。マップはこれらの与えられたロケ−ションにたいして古いほうの（もとの）状態が実際に何処に配置されているかを知っていなければならない。最後に、マップは最も古い状態を廃棄して再利用できるように古いほうの状態の相対年齢についての情報を維持しなければならない。
【０４６７】
本発明のファイル実現の場合、オペレ−ティングシステムにより維持されるファイルの配置とリンク情報は、マッピングシステムそのものであるかのように、変更できると仮定されている。ファイル全体かファイルの一部の前の状態をセ−ブしまた廃棄することを達成するために、その変更は前の段落で丁度述べられたマッピングの行に機能性を追加するであろう。
【０４６８】
４．制限されたサイズ。サイズが制限されているヒストリ−バッファの概念は、ヒストリ−バッファが新しい情報をある時間にわたて受け入れ続ける、またそれは利用可能な記憶空間の制限された一部の量を有するのみであるが、同時に「満杯になる」ことは決して求められないという事実を反映している。従ってそれは「循環的」でありその結果オ−バフロ−を避けるために情報を自動的に廃棄する。しかし、ヒストリ−バファの利用可能な空間は、例えば、サイズが固定されている、あらかじめ割り当てられている或いはディスクのある領域だけに限定されていると仮定すべきではない。ヒストリ−バッファの実現は、例えば、ダイナミックに空間を割りつける、その内容をあちこちと動かす、独立して或いはオペレ−ティングシステムのファイルシステムの下に存在する、或いは前記ステ−トメントの効果を達成する何か他のやり方で空間を管理してもよい。 制限することに焦点を合わせることは、記録装置が無限ではないという事実を単に反映しており、それにもかかわらず本発明は、制限されない量の時間と書き込みアクティビティにたいして新しい情報の再生を提供するものである。
【０４６９】
ヒストリ−バッファを実現できる様々な方法を確立したら、ヒストリ−バッファのサイズで制限されているが、どの時点のバックアップでも、前もって作成されるように要求することなしに、作成される情報をヒストリ−バッファは確立する。
本発明は、下記により、ヒストリ−バッファの使用を新しい情報の再生に向けている。
【０４７０】
1. ディスク（パ−ティション）を時間的に前の状態に戻す。
2. 主要な現在のディスクと共存する戻された疑似ディスク（パ−ティッション）を作成する。
3. ユ−ザが様々な時にディスクの状態を知るのを助けるためにディスクアクティビティを他のアクティビティと関連付ける手段を提供する。
【０４７１】
4. ヒストリ−バッファにある、またはヒストリ−バッファから引き出せる情報について探索と報告を行うためにヒストリ−バッファに関する専用のオペレーションを提供する。
従って、前述したように、本発明は時間的に前の新しい状態にディスクドライブ（パ−ティション）を取り戻すための方法と装置を提供する。本発明は、ディスクドライブを特にバックアップしていなくても「古い」ファイルかデ−タが再生できるということを規定している。本発明はその好ましい形式に関して述べられているが、他の多くの実現が可能でありまた当業者の技術の範囲内である。特に、本発明はディスクベ−スの記録媒体に限定されるものではなく、ランダムアクセスメモリのようなどの記憶装置にも適用できるものである。
【図面の簡単な説明】
【図１】 本発明による履歴バッファの動作を示す。
【図２】 以前の時点の別の駆動装置の状態を反映する仮想駆動装置を復元する履歴バッファの動作を示す。
【図３】 シミュレートまたは仮想駆動装置の選択された時点への復帰を示す。
【図４】 本発明による履歴バッファの構造を示す。
【図５Ａ】 現行駆動装置の読み出し／書き込みアルゴリズムを示す。
【図５Ｂ】 現行駆動装置の読み出し／書き込みアルゴリズムを示す。
【図６Ａ】 シミュレートされた駆動装置の読み出し／書き込みアルゴリズムを示す。
【図６Ｂ】 シミュレートされた駆動装置の読み出し／書き込みアルゴリズムを示す。
【図７】 記憶装置ディスクの主要領域と余分のページを示す。
【図８】 ２つのマップを使用してディスクの主要範囲と履歴バッファを表す方法を示す。
【図９】 ディスクへの短バースト書き込みアクティビティを示す。
【図１０】 長期間のディスクへの適度に連続する書き込みアクティビティを示す。
【図１１】 安全な点を確立する十分なギャップを有する、ディスクへの頻繁な書き込みアクティビティの例を示す。
【図１２】 主要範囲と余分の範囲両方のページを参照する２つのマップを示す。
【図１３】 履歴マップが余分のページ範囲のページだけを参照し、主要マップが主要範囲のページだけを参照するようなスワッピングの効果を示す。
【図１４】 除去された主要範囲マップのリンクを示す。
【図１５】 ３方向スワップを示す。
【図１６】 書き込みの例を示すが、その際ディスクは多数のページ位置を有し、一部のページ位置が主要範囲に割り当てられ、他のページ位置が余分のページに割り当てられる。
【図１７】 書き込みの例を示す。
【図１８】 書き込みの例を示す。
【図１９Ａ】 書き込みの例を示す。
【図１９Ｂ】 書き込みの例を示す。
【図１９Ｃ】 書き込みの例を示す。
【図１９Ｄ】 書き込みの例を示す。
【図１９Ｅ】 書き込みの例を示す。
【図１９Ｆ】 書き込みの例を示す。
【図１９Ｇ】 書き込みの例を示す。
【図１９Ｈ】 書き込みの例を示す。
【図１９Ｉ】 書き込みの例を示す。
【図１９Ｊ】 書き込みの例を示す。
【図１９Ｋ】 書き込みの例を示す。
【図１９Ｌ】 書き込みの例を示す。
【図１９Ｍ】 書き込みの例を示す。
【図１９Ｎ】 書き込みの例を示す。
【図１９Ｏ】 書き込みの例を示す。
【図１９Ｐ】 書き込みの例を示す。
【図１９Ｑ】 書き込みの例を示す。
【図１９Ｒ】 書き込みの例を示す。
【図１９Ｓ】 書き込みの例を示す。
【図１９Ｔ】 書き込みの例を示す。
【図１９Ｕ】 書き込みの例を示す。
【図１９Ｖ】 書き込みの例を示す。
【図２０】 書き込みの例を示す。
【図２１】 書き込みの例を示す。
【図２２】 書き込みの例を示す。
【図２３】 書き込みの例を示す。
【図２４】 履歴バッファの割り当てを示す。
【図２５】 履歴バッファの割り当てを示す。
【図２６Ａ】 以前の状態へのディスクの復帰を示す。
【図２６Ｂ】 以前の状態へのディスクの復帰を示す。
【図２６Ｃ】 以前の状態へのディスクの復帰を示す。
【図２６Ｄ】 以前の状態へのディスクの復帰を示す。
【図２６Ｅ】 以前の状態へのディスクの復帰を示す。
【図２６Ｆ】 以前の状態へのディスクの復帰を示す。
【図２６Ｇ】 以前の状態へのディスクの復帰を示す。
【図２６Ｈ】 以前の状態へのディスクの復帰を示す。
【図２６Ｉ】 以前の状態へのディスクの復帰を示す。
【図２６Ｊ】 以前の状態へのディスクの復帰を示す。
【図２６Ｋ】 以前の状態へのディスクの復帰を示す。
【図２６Ｌ】 以前の状態へのディスクの復帰を示す。
【図２６Ｍ】 以前の状態へのディスクの復帰を示す。
【図２７】 以前の状態へのディスクの復帰を示す。
【図２８】 以前の状態へのディスクの復帰を示す。
【図２９】 以前の状態へのディスクの復帰を示す。
【図３０】 以前の状態へのディスクの復帰を示す。
【図３１Ａ】 以前の状態へのディスクの復帰を示す。
【図３１Ｂ】 以前の状態へのディスクの復帰を示す。
【図３１Ｃ】 以前の状態へのディスクの復帰を示す。
【図３１Ｄ】 以前の状態へのディスクの復帰を示す。
【図３２】 ディスクの読み出しアクセスがオペレーティング・システムからエンジンを通じてディスク駆動装置に移動する方法を示す。
【図３３Ａ】 ディスクの読み出しアクセスがオペレーティング・システムからエンジンを通じてディスク駆動装置に移動する方法を示す。
【図３３Ｂ】 ディスクの読み出しアクセスがオペレーティング・システムからエンジンを通じてディスク駆動装置に移動する方法を示す。
【図３３Ｃ】 ディスクの読み出しアクセスがオペレーティング・システムからエンジンを通じてディスク駆動装置に移動する方法を示す。
【図３４】 ディスクのブロッキングを示す。
【図３５】 ディスクへの書き込みを示す。
【図３６】 ディスクへの書き込みを示す。
【図３７】 ディスクへの書き込みを示す。
【図３８】 ディスクへの書き込みを示す。
【図３９】 ディスクへの書き込みを示す。
【図４０】 ディスクへの書き込みを示す。
【図４０Ａ】 ディスクへの書き込みを示す。
【図４０Ｂ】 ディスクへの書き込みを示す。
【図４０Ｃ】 ディスクへの書き込みを示す。
【図４０Ｄ】 ディスクへの書き込みを示す。
【図４０Ｅ】 ディスクへの書き込みを示す。
【図４０Ｆ】 ディスクへの書き込みを示す。
【図４０Ｇ】 ディスクへの書き込みを示す。
【図４０Ｈ】 ディスクへの書き込みを示す。
【図４０Ｉ】 ディスクへの書き込みを示す。
【図４０Ｊ】 ディスクへの書き込みを示す。
【図４０Ｋ】 ディスクへの書き込みを示す。
【図４０Ｌ】 ディスクへの書き込みを示す。
【図４０Ｍ】 ディスクへの書き込みを示す。
【図４０Ｎ】 ディスクへの書き込みを示す。
【図４０Ｏ】 ディスクへの書き込みを示す。
【図４０Ｐ】 ディスクへの書き込みを示す。
【図４１】 マップ間の一般的な関係を示す。
【図４２Ａ】 ファイルへの書き込みを示す。
【図４２Ｂ】 ファイルへの書き込みを示す。
【図４２Ｃ】 ファイルへの書き込みを示す。
【図４２Ｄ】 ファイルへの書き込みを示す。
【図４２Ｅ】 ファイルへの書き込みを示す。
【図４２Ｆ】 ファイルへの書き込みを示す。
【図４２Ｇ】 ファイルへの書き込みを示す。
【図４２Ｈ】 ファイルへの書き込みを示す。
【図４２Ｉ】 ファイルへの書き込みを示す。
【図４２Ｊ】 ファイルへの書き込みを示す。
【図４３】 データが書き込まれるときの通常の動作を示す。
【図４４】 移動方法を示す。
【図４５，前半】 一時的方法を示す。
【図４５，後半】 一時的方法を示す。
【図４６】 Ａｌｗａｙｓ法およびＦｉｌｅ法のための単一フレームを示す。
【図４７Ａ】 ディスクのマップ間の関係を示す。
【図４７Ｂ】 ディスクのマップ間の関係を示す。
【図４７Ｃ】 ディスクのマップ間の関係を示す。
【図４７Ｄ】 ディスクのマップ間の関係を示す。
【図４７Ｅ】 ディスクのマップ間の関係を示す。
【図４７Ｆ】 ディスクのマップ間の関係を示す。
【図４７Ｇ】 ディスクのマップ間の関係を示す。
【図４７Ｈ】 ディスクのマップ間の関係を示す。
【図４７Ｉ】 ディスクのマップ間の関係を示す。
【図４８Ａ】 ファイルへの書き込みの順序を示す。
【図４８Ｂ】 ファイルへの書き込みの順序を示す。
【図４８Ｃ】 ファイルへの書き込みの順序を示す。
【図４８Ｄ】 ファイルへの書き込みの順序を示す。
【図４８Ｅ】 ファイルへの書き込みの順序を示す。
【図４９】 正常な書き込み操作を示す。
【図５０】 データをディスクに書き込むＭｏｖｅ法を示す。
【図５１】 データをディスクに書き込むＴｅｍｐ法を示す。
【図５２】 データをディスクに書き込むＡｌｗａｙｓ及びＦｉｌｅ法のための１つのフレームを示す。
【図５３】 外部バックアップ手順を示す。
【図５４】 読取り−書込みマップの構築を示す。
【図５５Ａ】 読取りデータの再オーダーとそのための方法を示す。
【図５５Ｂ】 読取りデータの再オーダーとそのための方法を示す。
【図５６】 再オーダーアルゴリズムの実行を示す。
【図５７】 スワップ法の一例を示す。
【図５８】 リンクをサポートするためのハッシュテーブルと提出テーブルの使用を示す。
【図５９】 書込みを処理する前にスワップを終了した結果を示す。
【図６０】 読取りが発生するバックグランドが完了するまで遅延されたキャッシュフラッ シュ処理に関連する書込みを示す。
【図６１】 本発明の実施形態の例を示す。
【図６２】 本発明の実施形態の例を示す。
【図６３】 従来のコンピュータ・アーキテクチャを示す。
【図６４】 リソースが保護される、本発明の実施形態を示す。
【図６５】 本発明が実現される代替実施形態を示す。

Claims (40)

  1. 位置Ｘのオリジナルデータを保持するために、いくつかのディスク位置Ｘ及びＹの役割の記録を保持する段階、
    新データを位置Ｘにあるオリジナルデータに重ね書きすることをオペレーティングシステムが要求した場合、オリジナルデータがディスク位置Ｘに残るように、位置Ｘにあるオリジナルデータの場所を占める代りに新データの記憶をディスク位置Ｙに迂回させる段階、
    前記オペレーティングシステムが位置Ｘの読み取りを要求した場合に、読み取りを位置Ｙに迂回させるために前記記録を参照する段階、
    （ｉ）先行状態が発生する前にオペレーティングシステムが重ね書きするよう要求しなかったデータをディスクから読みとり、（ｉｉ）ディスク上に保持されたオリジナルデータを読みとり、（ｉｉｉ）両方のソース（ｉ）及び（ｉｉ）から読みとられたデータを組合わせることによって、先行時に対応する、ディスク上に記憶されたデータの先行状態を再構築する段階、および、
    Ｘがオペレーティングシステムによってその後の迂回書き込みのデータを受信するように、前記オペレーティングシステムによって重ね書きされたオリジナルデータに関連するディスク位置を自動的に再利用する段階、
    を含んで成る方法。
  2. ディスク位置を重ね書きするためのオペレーティングシステムの要求に応えて、前の時間的基準点以降初めてその位置が修正されつつあるのか否かを決定し、そうでない場合にはその位置に直接重ね書きを行なう段階をさらに含んで成り、ここでその原状態は廃棄され、特定の時間的基準点として、ディスク上に重ね書きされているデータの原状態が保存される請求項１に記載の方法。
  3. 前記時間的基準点は、自動的に選択され、そのディスクのデータがオペレーティングシステムによってディスクに完全に書込まれた時点に対応する確率が高い時刻であり、前記自動的に選択される時間的基準点は、少なくとも部分的に、オペレーティングシステムによる非ディスク書込みアクティビティ周期の観察に基づき選択される請求項２に記載の方法。
  4. 前記時間的基準点は、少なくとも部分的に、オペレーティングシステムが内部メモリーからディスクにその全てのキャッシュドデータを書き込んだ場合、このオペレーティングシステムからの信号により選択される請求項３に記載の方法。
  5. いくつかのディスク位置ＸおよびＹの役割の記録を保持する段階であって、新データを位置Ｘにあるオリジナルデータに重ね書きすることをオペレーティングシステムが要求した後で、新データの記憶作業が少なくとも最初は、位置Ｘにあるオリジナルデータの場所を占める代わりに異なるディスクの位置Ｙへと迂回させられ、オリジナルデータがディスク上のそのオリジナル位置にとどまる段階、および
    （ｉ）先行状態が発生する前にオペレーティングシステムが重ね書きするよう要求しなかったディスクからのデータを読みとり、（ｉｉ）ディスク上に保持されたオリジナルデータを読みとり、（ｉｉｉ）両方のソース（ｉ）及び（ｉｉ）から読みとられたデータを組合わせることによって、先行時に対応する、ディスク上に記憶されたデータの先行状態を再構築する段階、を含み、
    前記記録が、ディスク上に維持され、前記記録は、１回だけのディスク書込みでは更新され得ない複雑なデータ構造がこれに関与しており、又、記録の１つの使用可能な状態からもう１つの状態への安全な遷移は、記録が２つの記録の存在を提供する１組の構成要素へと分割されるマッピングシステムを用いて記録を表現することによって提供され、そのうちの一方は先行する有効状態であり、もう一方は遷移状態であり、ここで両方のバージョンは共通の構成要素を共有することができ、前記先行する有効状態は完全にフラッシュされ物理ディスク上に存在し、ディスク上のスイッチページは前記先行する有効状態のマッピングを位置づけするのに充分な情報を保持しており、前記遷移状態のマッピングは先行する有効状態に存在する構成要素ならびに新しい有効状態を達成するのに所望の変化を反映する構成要素の形で定義されており、遷移状態と結びつけられた全てのデータがディスクに記憶された後、新しい先行する有効状態としてこの遷移状態を確立するようスイッチページが更新され、この更新が中断された場合はその結果としてスイッチページが実際に元の先行する有効状態又は遷移状態に結びつけられた新しい状態のいずれかを表示することになる方法。
  6. オペレーティングシステムが観察可能なディスクの状態は、データを移動させかつ／又は現行の及びオリジナルデータを再マッピングしてさまざまなディスク位置へのオペレーティングシステムによるアクセスが、早期時点のデータを含むディスク位置まで再度導かれるようにし、それと同時にディスク上に現行データを維持することによって、実際に早期時点のディスクの状態まで戻される請求項１に記載の方法。
  7. オペレーティングシステムにより検分可能である早期時点のディスクの状態の一部を成す古いデータは、現行のものとみなされ、早期時点のディスクの状態へ戻るためにその実際の重ね書きが必要とされた現行のデータであったものが今度は最近重ね書きされたデータとみなされ、オペレーティングシステムによりその重ね書きが要求されているデータの状態の連続的使用及びトラッキングが、請求項１に記載のとおりに行なわれる請求項６に記載の方法。
  8. 先行時からの実物理ディスクの状態へのアクセスを可能にするためディスクドライブの存在をシミュレートするために、実物理ディスクのアクセス方法と実質的に一貫性あるオペレーティングシステムに対するシミュレートされたディスクの存在を確立する段階をさらに含んで成り、シミュレートされたディスクのデータは、再構築された先行状態のデータである、請求項１に記載の方法。
  9. シミュレートされたディスクの初期の存在が確立された後、オペレーティングシステムはシミュレートされたディスク上でそのデータを新データで重ね書きすることが許される請求項８に記載の方法。
  10. 利用可能な場合に、実物理ディスクの現行イメージを表現する上で使用されない又は重ね書きの後の時点でシミュレートされたディスクを表現するのに関与する記憶位置を割当てる段階を含んで成り、これらの位置に新データが記憶され、シミュレートされたディスクのためのマッピングが適切に調整される請求項９に記載の方法。
  11. かかる記憶位置を割当てることができない場合には、ディスクエラー状況は、オペレーティングシステムの重ね書き要求に応えてオペレーティングシステムに戻される請求項１０に記載の方法。
  12. オペレーティングシステムが検分する通りの現行のディスクイメージを維持しているマッピングシステムを調整し、かくして現行のディスクイメージがシミュレートされたイメージとなり、以前のディスクイメージ内に実際に重ね書きされたデータが保存されることになる段階をさらに内含する請求項９に記載の方法。
  13. シミュレートされたディスクの役割及びシミュレートされたディスクにとってその早期状態がベースとなっている現行ディスクの役割が、オペレーティングシステムによるシミュレートされたディスクの全ての参照を現行ディスクへ、あるいはその逆の経路で、再度導くことによって交換され、かくしてディスクベースのデータ内に埋込まれた現行ディスクへの全ての参照がシミュレートされたディスクへと実際に経路指定されるようになっている請求項８に記載の方法。
  14. シミュレートされたディスクが現行ディスクの役割へとスワップされ得る請求項８に記載の方法。
  15. ディスクを有するコンビュータシステムを再スタートさせた時点又はユーザーからの適切な信号送りの時点で、役割が自動的に復活され、現行ディスクの状態がシミュレートされたディスクの状態まで逆戻りさせられるシミュレートされたディスク及び現行ディスクの役割を復活する請求項８に記載の方法。
  16. 選択時間の間に発生するコンピュータの種々のアクティビティを記録することによってディスクが逆戻りされ得る選択時刻を注釈づけする段階を含み、ここで、前記記録は循環式であり、そのため選択時刻が利用不能になるにつれて付随する注釈が廃棄されるようになっている請求項６に記載の方法。
  17. 選択時刻の間に発生するコンピュータの種々のアクティビティを記録することによってシミュレートされたディスクが逆戻りされ得る選択時刻を注釈づけする段階を含み、ここで前記記録は循環式であり、そのため選択時刻が利用不能になるにつれて付随する注釈が廃棄されるようになっている請求項８に記載の方法。
  18. 前記コンピュータの種々のアクティビティには、プログラムのロード実行が含まれる請求項１７に記載の方法。
  19. 前記コンピュータの種々のアクティビティには、ファイル新規作成、修正、消去、再命名又はファイルシステム階層内での移動が含まれる請求項１７に記載の方法。
  20. 前記コンピュータの種々のアクティビティには、システムブートが含まれる請求項１７に記載の方法。
  21. 前記コンピュータの種々のアクティビティには、スクリーンショットが含まれる請求項１７に記載の方法。
  22. 前記コンピュータの種々のアクティビティには、ユーザーキーストローク及びマウスアクティビティが含まれる請求項１７に記載の方法。
  23. シミュレートされたディスクからの所望のファイルを、ユーザーによって選択された宛先へとコピーする段階をさらに内含する請求項８に記載の方法。
  24. ログ内に記憶されたアクティビティノートの走査に基づいてファイルの重ね書きバージョンを検索し、シミュレートされたディスクを確立できる考えられる時刻とこれらのノートを相関させ、結果として得られたファイルと選択時刻のセットをユーザーに提示し、かかる時刻の１つを選択した時点でもう１つの位置へコピーされるべきファイルを検索するための、請求項１６に記載の方法。
  25. ユーザに提示されるファイルと選択時刻のセットが、ファイル名、ファイル拡張、ディレクトリ位置及び選択時刻のうちのいずれか１つに基づいたろ過を受ける請求項１６に記載の方法。
  26. ユーザに提示されるファイルと選択時刻のセットが、特定のディレクトリ経路位置における特定のファイルに制限されている請求項１６に記載の方法。
  27. 記録の中にファイル新規作成、消去、修正、再命名及び移動アクティビティエントリの記録を維持し各々を時間的基準点と結びつける段階、アクティビティエントリをソートする段階、ソートされたリスト内の一意的ファイル及びディレクトリエントリに基づいてユーザに対しファイル階層を提示する段階、ユーザがファイルを選択できるようにしその後利用可能なバージョンのリストがその選択されたファイルについて発見された複製エントリに基づいて提示される段階、特定のバージョンの選択を可能にする段階、及びもう１つの位置にコピーされるべきファイルを検索する段階、を含んで成るファイルの早期バージョンにアクセスするための請求項１９に記載の方法。
  28. 過去の特定の時刻にディスクを逆戻りさせる段階、過去の特定の時刻と要求された逆戻りの直前の時刻の間で変化したファイルのリストを作成するため先行するファイルアクティビティの記録を走査する段階、前記ファイルリストをユーザーに提示し、ファイルを選択できるようにする段階、及び逆戻り後の一時点で逆戻りの直前の前記ファイルの最終状態を検索する段階を含んで成る、或る種のファイルをその現行状態に維持しながら同時に早期状態までディスクを逆戻りさせるための請求項６に記載の方法。
  29. 第２のハードディスク及びそれとメインハードディスクがインタフェースされているコンピュータとの間の通信リンクを提供する段階を含む、現行オペレーティングシステムの可視イメージならびに重ね書きされたディスク位置の先行状態の循環記録を共に維持しているメインディスクのためのハードウェア冗長性を提供する段階をさらに含み、重ね書きされたデータの原状態が両方のディスク上に維持され、２つのディスクの間の同期化が維持されていることから、第２のディスクがメインディスクからのデータを全く含まないか又はかかるデータがきわめて古いためにメインディスク上で確立されたシミュレートされたディスクが第２のディスク上で最後に確立された現行イメージを反映するのに充分なほど時間的にさかのぼったところに達し得ない場合には、第２のディスクの中味は廃棄され、第２のディスクの通常の処理を中断し、現行時刻の近くでメインディスク上のシミュレートされたディスクを確立し、第２のディスクにシミュレートされたイメージを転送し、又、万一、メインディスク上に発生した変更によりメインディスクのシミュレートされたイメージがオーバーランした場合には、プロセスを再スタートさせることによって再度初期化されるようになっており、シミュレートされたイメージがひとたび転送された時点で、シミュレートされたディスクが確立された時点で開始しより離れた時刻までさかのぼって移動するメインディスク上に重ね書きされたデータの利用可能なヒストリ上先行する状態は、メインディスク上にそのようなデータが存在しそれを受け入れるのに充分なディスク空間が第２のディスク上にあるかぎり、第２のディスクまで転送されるようになっている請求項１に記載の方法。
  30. 第２のディスク上の現行イメージに対応するメインディスク上での或る一定の時刻現在でシミュレートされたディスクを確立することがひとたび可能となった時点で、第２のディスクは、そのデータに対し行なわれた変更をトラッキングし始め、ヒストリ記録はこの一定の時刻から順方向に走査され、メインディスクに対し経時的に発生した書込みのうちの少なくともいくつかを年代順に再度作成する適切な書込みが生成されると同時にヒストリ記録に関係するメインディスク上に保たれたその他のあらゆる適切な情報が転送され、記録全体がひとたび走査された時点で、記録に対しさらにデータが付加されるまでポーズ状態とされ、その後、走査及び転送プロセスが続行する請求項２９に記載の方法。
  31. コンピュータシステムを再スタートさせる段階、第２のディスクを最後のセーフポイントまで逆戻りさせる段階及び第２のディスクに対するメインディスクの全てのアクセスを再度導いて、第２のディスクが透明な形で原メインディスクの役割を引き継ぎ、それと同時に故障した原メインディスクの冗長なコピーの維持に関するアクティビティを停止するようにする段階を含んで成る、第２の冗長ディスクが維持された完全なメインディスクの故障から回復するための、請求項３０に記載の方法。
  32. 作動可能となるような形でメインディスクを交換又は修繕する段階、あたかもメインディスクであるかのように第２のディスクを扱い続ける段階、メインディスクを冗長ディスクとして扱う段階、２つのディスクを再初期化し同期化する段階を含んで成り、この時点で両方のディスクが現行のオペレーティングシステムの可視イメージに対し完全に同期化された時、役割が交換され、第２のディスクはメインディスクに対するタイムラグのある冗長性を提供することを再開する、第２の通常は冗長性のディスクがメインディスクの役割を引き継ぐコンピュータシステム内での故障したメインディスクを置換する請求項３１に記載の方法。
  33. 第２のディスクが、並列ポート、直列ポート、汎用直列バス、ファイアワイヤ又はネットワークインタフェースを用いてメインディスクと結びつけられたコンピュータに対しインタフェースする請求項２９に記載の冗長ディスク記憶の提供方法。
  34. 第２のディスクが同様に、その中に埋込まれた形又はそれに結びつけられた形で、その記憶を管理する能力をもつ独自のコンピュータシステムをも収納している請求項３３に記載の冗長ディスク記憶の提供方法。
  35. 各々のバックアップされたコンピュータシステムに対しその集合的記憶の一部分を割当てしマッピングすることによって、独自のメインディスクを各々有する多数のコンピュータに対しバックアップサービスを提供するような形でその記憶が管理されている冗長ディスク記憶システムを内含する請求項３３に記載の方法。
  36. 全体としてか又はその記憶媒体の形で第２のディスクが取外し可能でかつポータブル式となりうるようにすることによって、メインディスクの冗長かつオフサイトバックアップを提供する段階を含む請求項３３に記載の方法。
  37. コンピュータシステム上で実行中のアプリケーションを時間的に逆戻りさせるために、シミュレートされたディスクの新規作成又はディスク逆戻りが可能である時間中、現行時刻に対する参照と合わせてアプリケーションに付随する内部メモリーのコピーを周期的にセーブし、かくして過去におけるセーブされた時点でアプリケーションを再スタートさせることができると同時に過去における前記時点で存在していた状態までディスクの状態を実際に復活させることができるようになる段階を含んで成る、請求項８に記載の方法。
  38. シミュレートされたディスクのディスク逆戻り又は新規作成が可能である時間中、現行時刻に対する参照と合わせてアプリケーションに付随する適切な内部メモリーのコピーを周期的にセーブし、かくして過去におけるセーブされた時点でアプリケーションを再スタートさせることができると同時に過去における前記時点で存在していた状態までディスクの状態を実際に復活させることができるようになる段階を含んで成る、コンピュータシステム上で実行中のアプリケーションを時間的に逆戻りさせることをさらに内含し、アプリケーションの再スタート時点で、シミュレートされたディスクを確立し、再スタートされたアプリケーションによって行なわれた全てのメインディスクアクセスをシミュレートされたディスクへと導くことにより、ディスクが過去における前記時点にまで復活される請求項１に記載の方法。
  39. セーブされた内部メモリースナップショットが圧縮される請求項３７に記載の方法。
  40. データ要素Ｘ中のオリジナルデータを保持するために、オペレーティングシステムによって管理されかつファイルに関連付けられて、ディスクベースのデータ要素ＸおよびＹの役割の記録を保持し、
    読み出しをデータ要素Ｙに迂回させるために、データ要素Ｘに関係するファイルの一部分の読み出しをオペレーティングシステムが要求する場合、前記記録を参照し、この場合、前記記録はオペレーティングシステムのファイルマッピング機構内で実行され、あるいは異なるマッピングしとして保持され、
    （ｉ）先行状態が発生する前にオペレーティングシステムが重ね書きされるよう要求しなかったディスクからのデータを読みとり、（ｉｉ）ディスク上に保持されたオリジナルデータを読みとり、（ｉｉｉ）両方のソース（ｉ）及び（ｉｉ）から読みとられたデータを組合わせることによって、先行時に対応するオペレーティングシステムにより管理されたディスクベースデータの先行状態の全てあるいは一部分を再構築し、さらに、
    例えばデータ要素Ｘであるオリジナルデータに関連するディスク記憶領域をオペレーティングシステムにより次の迂回書き込みの新データを受信するために自動的に再利用する、各段階を含む方法。
JP2000509037A 1997-09-05 1998-09-04 データを保存し使用し及び回復する方法 Expired - Fee Related JP3878412B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US92419897A 1997-09-05 1997-09-05
US3965098A 1998-03-16 1998-03-16
US09/105,733 US6016553A (en) 1997-09-05 1998-06-26 Method, software and apparatus for saving, using and recovering data
PCT/US1998/018863 WO1999012101A2 (en) 1997-09-05 1998-09-04 Method, software and apparatus for saving, using and recovering data

Publications (3)

Publication Number Publication Date
JP2004504645A JP2004504645A (ja) 2004-02-12
JP2004504645A5 JP2004504645A5 (ja) 2004-12-24
JP3878412B2 true JP3878412B2 (ja) 2007-02-07

Family

ID=27365582

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000509037A Expired - Fee Related JP3878412B2 (ja) 1997-09-05 1998-09-04 データを保存し使用し及び回復する方法

Country Status (5)

Country Link
US (3) US6016553A (ja)
JP (1) JP3878412B2 (ja)
AU (1) AU9383298A (ja)
DE (1) DE19882659T1 (ja)
WO (1) WO1999012101A2 (ja)

Families Citing this family (314)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9605338D0 (en) 1996-03-13 1996-05-15 Arendee Ltd Improvements in or relating to computer systems
US6434663B1 (en) * 1996-09-06 2002-08-13 Intel Corporation Disk block allocation optimization methodology with accommodation for file system cluster size greater than operating system memory page size
US6016553A (en) * 1997-09-05 2000-01-18 Wild File, Inc. Method, software and apparatus for saving, using and recovering data
US7389442B1 (en) * 1997-12-26 2008-06-17 Samsung Electronics Co., Ltd. Apparatus and method for self diagnosis, repair, removal by reversion of computer problems from desktop and recovery from booting or loading of operating system errors by removable media
US6363487B1 (en) * 1998-03-16 2002-03-26 Roxio, Inc. Apparatus and method of creating a firewall data protection
US6732293B1 (en) 1998-03-16 2004-05-04 Symantec Corporation Method, software and apparatus for recovering and recycling data in conjunction with an operating system
US6202124B1 (en) * 1998-05-05 2001-03-13 International Business Machines Corporation Data storage system with outboard physical data transfer operation utilizing data path distinct from host
GB9809885D0 (en) 1998-05-09 1998-07-08 Vircon Limited Protected storage device for computer system
US6163856A (en) * 1998-05-29 2000-12-19 Sun Microsystems, Inc. Method and apparatus for file system disaster recovery
US6289355B1 (en) * 1998-09-16 2001-09-11 International Business Machines Corp. Fast log apply
US6714935B1 (en) * 1998-09-21 2004-03-30 Microsoft Corporation Management of non-persistent data in a persistent database
US6314567B1 (en) * 1998-11-13 2001-11-06 Hewlett-Packard Company Apparatus and method for transferring state data when performing on-line replacement of a running program code and data
AU2355500A (en) * 1998-12-07 2000-06-26 Network Ice Corporation A method and apparatus for remote installation of network drivers and software
US7181486B1 (en) 1998-12-07 2007-02-20 Network Ice Corporation Method and apparatus for remote installation of network drivers and software
IL143573A0 (en) 1998-12-09 2002-04-21 Network Ice Corp A method and apparatus for providing network and computer system security
US6751604B2 (en) * 1999-01-06 2004-06-15 Hewlett-Packard Development Company, L.P. Method of displaying temporal and storage media relationships of file names protected on removable storage media
US6317875B1 (en) * 1999-01-15 2001-11-13 Intel Corporation Application execution performance through disk block relocation
US7774315B1 (en) 1999-03-12 2010-08-10 Eldad Galker Backup system
JP2000284987A (ja) * 1999-03-31 2000-10-13 Fujitsu Ltd コンピュータ、コンピュータネットワークシステム及び記録媒体
US6148354A (en) 1999-04-05 2000-11-14 M-Systems Flash Disk Pioneers Ltd. Architecture for a universal serial bus-based PC flash disk
US7055055B1 (en) 1999-04-23 2006-05-30 Symantec Corporation Write cache flushing method for reducing data corruption
AU4486200A (en) * 1999-04-23 2000-11-10 Wild File, Inc. Method and apparatus for dealing with data corruption and shared disks in the context of saving, using and recovering data
JP2003503792A (ja) 1999-06-30 2003-01-28 マイクロソフト コーポレイション コンピュータの前状態への回復
US7051055B1 (en) 1999-07-09 2006-05-23 Symantec Corporation Optimized disk storage defragmentation with swapping capabilities
AU6081200A (en) * 1999-07-09 2001-01-30 Eric D. Schneider Optimized disk storage defragmentation with swapping capabilities
US7035880B1 (en) 1999-07-14 2006-04-25 Commvault Systems, Inc. Modular backup and retrieval system used in conjunction with a storage area network
US7395282B1 (en) 1999-07-15 2008-07-01 Commvault Systems, Inc. Hierarchical backup and retrieval system
US7389311B1 (en) * 1999-07-15 2008-06-17 Commvault Systems, Inc. Modular backup and retrieval system
US7346929B1 (en) * 1999-07-29 2008-03-18 International Business Machines Corporation Method and apparatus for auditing network security
US6948099B1 (en) * 1999-07-30 2005-09-20 Intel Corporation Re-loading operating systems
US6742137B1 (en) * 1999-08-17 2004-05-25 Adaptec, Inc. Object oriented fault tolerance
US6775339B1 (en) 1999-08-27 2004-08-10 Silicon Graphics, Inc. Circuit design for high-speed digital communication
US7337360B2 (en) * 1999-10-19 2008-02-26 Idocrase Investments Llc Stored memory recovery system
US6594780B1 (en) * 1999-10-19 2003-07-15 Inasoft, Inc. Operating system and data protection
US6591377B1 (en) * 1999-11-24 2003-07-08 Unisys Corporation Method for comparing system states at different points in time
US6883120B1 (en) * 1999-12-03 2005-04-19 Network Appliance, Inc. Computer assisted automatic error detection and diagnosis of file servers
US8006243B2 (en) * 1999-12-07 2011-08-23 International Business Machines Corporation Method and apparatus for remote installation of network drivers and software
US6526418B1 (en) * 1999-12-16 2003-02-25 Livevault Corporation Systems and methods for backing up data files
US6625623B1 (en) * 1999-12-16 2003-09-23 Livevault Corporation Systems and methods for backing up data files
US6779003B1 (en) 1999-12-16 2004-08-17 Livevault Corporation Systems and methods for backing up data files
US6847984B1 (en) 1999-12-16 2005-01-25 Livevault Corporation Systems and methods for backing up data files
US6460055B1 (en) * 1999-12-16 2002-10-01 Livevault Corporation Systems and methods for backing up data files
US7031420B1 (en) 1999-12-30 2006-04-18 Silicon Graphics, Inc. System and method for adaptively deskewing parallel data signals relative to a clock
US6658436B2 (en) 2000-01-31 2003-12-02 Commvault Systems, Inc. Logical view and access to data managed by a modular data and storage management system
US7003641B2 (en) * 2000-01-31 2006-02-21 Commvault Systems, Inc. Logical view with granular access to exchange data managed by a modular data and storage management system
US7155481B2 (en) 2000-01-31 2006-12-26 Commvault Systems, Inc. Email attachment management in a computer system
GB2359386B (en) * 2000-02-16 2004-08-04 Data Connection Ltd Replicated control block handles for fault-tolerant computer systems
US7194504B2 (en) * 2000-02-18 2007-03-20 Avamar Technologies, Inc. System and method for representing and maintaining redundant data sets utilizing DNA transmission and transcription techniques
US6704730B2 (en) 2000-02-18 2004-03-09 Avamar Technologies, Inc. Hash file system and method for use in a commonality factoring system
US7062648B2 (en) * 2000-02-18 2006-06-13 Avamar Technologies, Inc. System and method for redundant array network storage
US6826711B2 (en) 2000-02-18 2004-11-30 Avamar Technologies, Inc. System and method for data protection with multidimensional parity
PL355475A1 (en) * 2000-02-21 2004-05-04 Trek 2000 International Ltd. A portable data storage device
AU2001241956B2 (en) 2000-03-01 2006-11-30 Computer Associates Think, Inc. Method and system for updating an archive of a computer file
US6714720B1 (en) * 2000-03-06 2004-03-30 Ati International Srl Method and apparatus for storing multi-media data
US20050257827A1 (en) * 2000-04-27 2005-11-24 Russell Gaudiana Rotational photovoltaic cells, systems and methods
WO2001084285A2 (en) * 2000-04-28 2001-11-08 Internet Security Systems, Inc. Method and system for managing computer security information
AU2001257400A1 (en) * 2000-04-28 2001-11-12 Internet Security Systems, Inc. System and method for managing security events on a network
US6484187B1 (en) * 2000-04-28 2002-11-19 International Business Machines Corporation Coordinating remote copy status changes across multiple logical sessions to maintain consistency
US7111201B2 (en) * 2000-05-19 2006-09-19 Self Repairing Computers, Inc. Self repairing computer detecting need for repair and having switched protected storage
US7100075B2 (en) * 2000-05-19 2006-08-29 Sel Repairing Computers, Inc. Computer system having data store protected from internet contamination by virus or malicious code and method for protecting
US20060277433A1 (en) * 2000-05-19 2006-12-07 Self Repairing Computers, Inc. Computer having special purpose subsystems and cyber-terror and virus immunity and protection features
US7096381B2 (en) * 2001-05-21 2006-08-22 Self Repairing Computer, Inc. On-the-fly repair of a computer
TWI305319B (en) 2000-05-19 2009-01-11 Vir2Us Inc Computer having proctected data stores and switchable components providing isolated computing for vital and haker immunity
US7137034B2 (en) * 2000-05-19 2006-11-14 Vir2Us, Inc. Self repairing computer having user accessible switch for modifying bootable storage device configuration to initiate repair
US6496840B1 (en) * 2000-05-31 2002-12-17 International Business Machines Corporation Method, system and program products for atomically and persistently swapping resource groups
US6907531B1 (en) 2000-06-30 2005-06-14 Internet Security Systems, Inc. Method and system for identifying, fixing, and updating security vulnerabilities
US6754682B1 (en) * 2000-07-10 2004-06-22 Emc Corporation Method and apparatus for enabling consistent ancillary disk array storage device operations with respect to a main application
US7093239B1 (en) * 2000-07-14 2006-08-15 Internet Security Systems, Inc. Computer immune system and method for detecting unwanted code in a computer system
US7248635B1 (en) 2000-07-20 2007-07-24 Silicon Graphics, Inc. Method and apparatus for communicating computer data from one point to another over a communications medium
US6779072B1 (en) 2000-07-20 2004-08-17 Silicon Graphics, Inc. Method and apparatus for accessing MMR registers distributed across a large asic
US6831924B1 (en) 2000-07-20 2004-12-14 Silicon Graphics, Inc. Variable mode bi-directional and uni-directional computer communication system
US6703908B1 (en) 2000-07-20 2004-03-09 Silicon Graphic, Inc. I/O impedance controller
US6839856B1 (en) 2000-07-20 2005-01-04 Silicon Graphics, Inc. Method and circuit for reliable data capture in the presence of bus-master changeovers
US7333516B1 (en) 2000-07-20 2008-02-19 Silicon Graphics, Inc. Interface for synchronous data transfer between domains clocked at different frequencies
US6763428B1 (en) * 2000-08-02 2004-07-13 Symantec Corporation Methods and systems for performing push-pull optimization of files while file storage allocations are actively changing
US7539828B2 (en) * 2000-08-08 2009-05-26 Faronics Corporation Method and system for automatically preserving persistent storage
US6681293B1 (en) 2000-08-25 2004-01-20 Silicon Graphics, Inc. Method and cache-coherence system allowing purging of mid-level cache entries without purging lower-level cache entries
US6879996B1 (en) * 2000-09-13 2005-04-12 Edward W. Laves Method and apparatus for displaying personal digital assistant synchronization data using primary and subordinate data fields
GB2367656A (en) * 2000-10-06 2002-04-10 Hewlett Packard Co Self-repairing operating system for computer entities
EP1195679A1 (en) * 2000-10-06 2002-04-10 Hewlett-Packard Company, A Delaware Corporation Performing operating system recovery from external back-up media in a headless computer entity
US9027121B2 (en) 2000-10-10 2015-05-05 International Business Machines Corporation Method and system for creating a record for one or more computer security incidents
US7146305B2 (en) * 2000-10-24 2006-12-05 Vcis, Inc. Analytical virtual machine
US6618794B1 (en) * 2000-10-31 2003-09-09 Hewlett-Packard Development Company, L.P. System for generating a point-in-time copy of data in a data storage system
US6810398B2 (en) 2000-11-06 2004-10-26 Avamar Technologies, Inc. System and method for unorchestrated determination of data sequences using sticky byte factoring to determine breakpoints in digital sequences
US7089449B1 (en) * 2000-11-06 2006-08-08 Micron Technology, Inc. Recovering a system that has experienced a fault
US6968462B2 (en) 2000-12-11 2005-11-22 International Business Machines Corporation Verifying physical universal serial bus keystrokes
US7130466B2 (en) * 2000-12-21 2006-10-31 Cobion Ag System and method for compiling images from a database and comparing the compiled images with known images
US7340776B2 (en) * 2001-01-31 2008-03-04 International Business Machines Corporation Method and system for configuring and scheduling security audits of a computer network
US7395281B2 (en) * 2001-03-27 2008-07-01 British Telecommunications Public Limited Company File synchronisation
US7010696B1 (en) 2001-03-30 2006-03-07 Mcafee, Inc. Method and apparatus for predicting the incidence of a virus
US20020169880A1 (en) * 2001-04-19 2002-11-14 Koninklijke Philips Electronics N.V. Method and device for robust real-time estimation of the bottleneck bandwidth in the internet
US7440972B2 (en) * 2001-04-26 2008-10-21 Sonic Solutions Interactive media authoring without access to original source material
US7392541B2 (en) * 2001-05-17 2008-06-24 Vir2Us, Inc. Computer system architecture and method providing operating-system independent virus-, hacker-, and cyber-terror-immune processing environments
US7849360B2 (en) * 2001-05-21 2010-12-07 Vir2Us, Inc. Computer system and method of controlling communication port to prevent computer contamination by virus or malicious code
US7526811B1 (en) * 2001-05-22 2009-04-28 Novell, Inc. Methods for detecting executable code which has been altered
WO2002097587A2 (en) * 2001-05-31 2002-12-05 Internet Security Systems, Inc. Method and system for implementing security devices in a network
US20040139125A1 (en) * 2001-06-05 2004-07-15 Roger Strassburg Snapshot copy of data volume during data access
US7640582B2 (en) 2003-04-16 2009-12-29 Silicon Graphics International Clustered filesystem for mix of trusted and untrusted nodes
US7657419B2 (en) * 2001-06-19 2010-02-02 International Business Machines Corporation Analytical virtual machine
CN100432962C (zh) * 2001-06-28 2008-11-12 特科2000国际有限公司 数据传送的方法与装置
WO2003003295A1 (en) * 2001-06-28 2003-01-09 Trek 2000 International Ltd. A portable device having biometrics-based authentication capabilities
TWI246028B (en) * 2001-06-28 2005-12-21 Trek 2000 Int Ltd A portable device having biometrics-based authentication capabilities
US7673343B1 (en) 2001-07-26 2010-03-02 Mcafee, Inc. Anti-virus scanning co-processor
US6773083B2 (en) 2001-08-29 2004-08-10 Lexmark International, Inc. Method and apparatus for non-volatile memory usage in an ink jet printer
US20030046605A1 (en) * 2001-09-03 2003-03-06 Farstone Technology Inc. Data protection system and method regarding the same
US6832301B2 (en) * 2001-09-11 2004-12-14 International Business Machines Corporation Method for recovering memory
US6880101B2 (en) * 2001-10-12 2005-04-12 Dell Products L.P. System and method for providing automatic data restoration after a storage device failure
US7324983B1 (en) * 2001-11-08 2008-01-29 I2 Technologies Us, Inc. Reproducible selection of members in a hierarchy
US6668336B2 (en) 2001-11-08 2003-12-23 M-Systems Flash Disk Pioneers Ltd. Ruggedized block device driver
US6883114B2 (en) * 2001-11-08 2005-04-19 M-Systems Flash Disk Pioneers Ltd. Block device driver enabling a ruggedized file system
US7536598B2 (en) * 2001-11-19 2009-05-19 Vir2Us, Inc. Computer system capable of supporting a plurality of independent computing environments
GB2382889A (en) * 2001-12-05 2003-06-11 Cambridge Consultants microprocessor design system
US7181560B1 (en) 2001-12-21 2007-02-20 Joseph Grand Method and apparatus for preserving computer memory using expansion card
US7007152B2 (en) * 2001-12-28 2006-02-28 Storage Technology Corporation Volume translation apparatus and method
US7467274B2 (en) * 2001-12-31 2008-12-16 Hewlett-Packard Development Company, L.P. Method to increase the life span of limited cycle read/write media
US7673137B2 (en) * 2002-01-04 2010-03-02 International Business Machines Corporation System and method for the managed security control of processes on a computer system
JP2003248596A (ja) * 2002-02-26 2003-09-05 Hitachi Ltd 多重計算機システムにおける処理の引継方法
US7788699B2 (en) 2002-03-06 2010-08-31 Vir2Us, Inc. Computer and method for safe usage of documents, email attachments and other content that may contain virus, spy-ware, or malicious code
US6993539B2 (en) 2002-03-19 2006-01-31 Network Appliance, Inc. System and method for determining changes in two snapshots and for transmitting changes to destination snapshot
TW200401267A (en) * 2002-04-04 2004-01-16 Sonic Solutions Optimizing the recording on a rewritable interactive medium of revisions to an existing project on that medium
US7370360B2 (en) * 2002-05-13 2008-05-06 International Business Machines Corporation Computer immune system and method for detecting unwanted code in a P-code or partially compiled native-code program executing within a virtual machine
CN1605069A (zh) 2002-05-13 2005-04-06 特科2000国际有限公司 对便携式数据存储设备中存储的数据进行压缩及解压缩的系统和设备
US7844577B2 (en) * 2002-07-15 2010-11-30 Symantec Corporation System and method for maintaining a backup storage system for a computer system
US6980698B2 (en) * 2002-07-22 2005-12-27 Xerox Corporation Image finder method and apparatus for pixography and other photo-related reproduction applications
US6907504B2 (en) * 2002-07-29 2005-06-14 International Business Machines Corporation Method and system for upgrading drive firmware in a non-disruptive manner
TW588243B (en) * 2002-07-31 2004-05-21 Trek 2000 Int Ltd System and method for authentication
US6957362B2 (en) * 2002-08-06 2005-10-18 Emc Corporation Instantaneous restoration of a production copy from a snapshot copy in a data storage system
US7124322B1 (en) * 2002-09-24 2006-10-17 Novell, Inc. System and method for disaster recovery for a computer network
US7206961B1 (en) * 2002-09-30 2007-04-17 Emc Corporation Preserving snapshots during disk-based restore
US7340486B1 (en) * 2002-10-10 2008-03-04 Network Appliance, Inc. System and method for file system snapshot of a virtual logical disk
US20040083357A1 (en) * 2002-10-29 2004-04-29 Sun Microsystems, Inc. Method, system, and program for executing a boot routine on a computer system
US7010645B2 (en) * 2002-12-27 2006-03-07 International Business Machines Corporation System and method for sequentially staging received data to a write cache in advance of storing the received data
US7913303B1 (en) 2003-01-21 2011-03-22 International Business Machines Corporation Method and system for dynamically protecting a computer system from attack
GB2399188B (en) * 2003-03-04 2005-11-30 Fujitsu Serv Ltd Reducing the boot-up time of a computer system
US7454569B2 (en) 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
US7401092B2 (en) 2003-06-26 2008-07-15 Standbysoft Llc Method and apparatus for exchanging sub-hierarchical structures within a hierarchical file system
DE10334815B4 (de) * 2003-07-30 2005-12-01 Siemens Ag Verfahren zum Abspeichern und Auslesen von Daten
US20050033625A1 (en) * 2003-08-06 2005-02-10 International Business Machines Corporation Method, apparatus and program storage device for scheduling the performance of maintenance tasks to maintain a system environment
US7506198B2 (en) * 2003-08-11 2009-03-17 Radix Israel, Ltd. Protection and recovery system and automatic hard disk drive (HDD) instant recovery
US7565382B1 (en) 2003-08-14 2009-07-21 Symantec Corporation Safely rolling back a computer image
US7409587B2 (en) * 2004-08-24 2008-08-05 Symantec Operating Corporation Recovering from storage transaction failures using checkpoints
US7577806B2 (en) * 2003-09-23 2009-08-18 Symantec Operating Corporation Systems and methods for time dependent data storage and recovery
US7730222B2 (en) * 2004-08-24 2010-06-01 Symantec Operating System Processing storage-related I/O requests using binary tree data structures
US7725760B2 (en) * 2003-09-23 2010-05-25 Symantec Operating Corporation Data storage system
US7991748B2 (en) * 2003-09-23 2011-08-02 Symantec Corporation Virtual data store creation and use
US7296008B2 (en) * 2004-08-24 2007-11-13 Symantec Operating Corporation Generation and use of a time map for accessing a prior image of a storage device
US7631120B2 (en) * 2004-08-24 2009-12-08 Symantec Operating Corporation Methods and apparatus for optimally selecting a storage buffer for the storage of data
US7904428B2 (en) * 2003-09-23 2011-03-08 Symantec Corporation Methods and apparatus for recording write requests directed to a data store
US7239581B2 (en) * 2004-08-24 2007-07-03 Symantec Operating Corporation Systems and methods for synchronizing the internal clocks of a plurality of processor modules
US7827362B2 (en) * 2004-08-24 2010-11-02 Symantec Corporation Systems, apparatus, and methods for processing I/O requests
US7287133B2 (en) * 2004-08-24 2007-10-23 Symantec Operating Corporation Systems and methods for providing a modification history for a location within a data store
US7577807B2 (en) * 2003-09-23 2009-08-18 Symantec Operating Corporation Methods and devices for restoring a portion of a data store
US7225208B2 (en) * 2003-09-30 2007-05-29 Iron Mountain Incorporated Systems and methods for backing up data files
US7707374B2 (en) * 2003-10-22 2010-04-27 International Business Machines Corporation Incremental data storage method, apparatus, interface, and system
US7171538B2 (en) 2003-10-22 2007-01-30 International Business Machines Corporation Incremental data storage method, apparatus, interface, and system
US7657938B2 (en) * 2003-10-28 2010-02-02 International Business Machines Corporation Method and system for protecting computer networks by altering unwanted network data traffic
US7721062B1 (en) 2003-11-10 2010-05-18 Netapp, Inc. Method for detecting leaked buffer writes across file system consistency points
US7401093B1 (en) 2003-11-10 2008-07-15 Network Appliance, Inc. System and method for managing file data during consistency points
US7546324B2 (en) 2003-11-13 2009-06-09 Commvault Systems, Inc. Systems and methods for performing storage operations using network attached storage
US7412583B2 (en) * 2003-11-14 2008-08-12 International Business Machines Corporation Virtual incremental storage method
US7206973B2 (en) * 2003-12-11 2007-04-17 Lsi Logic Corporation PCI validation
JP4477370B2 (ja) * 2004-01-30 2010-06-09 株式会社日立製作所 データ処理システム
US20050204186A1 (en) * 2004-03-09 2005-09-15 Rothman Michael A. System and method to implement a rollback mechanism for a data storage unit
US7779463B2 (en) 2004-05-11 2010-08-17 The Trustees Of Columbia University In The City Of New York Systems and methods for correlating and distributing intrusion alert information among collaborating computer systems
US7257684B1 (en) 2004-05-25 2007-08-14 Storage Technology Corporation Method and apparatus for dynamically altering accessing of storage drives based on the technology limits of the drives
US7353242B2 (en) 2004-07-09 2008-04-01 Hitachi, Ltd. File server for long term data archive
US7664983B2 (en) * 2004-08-30 2010-02-16 Symantec Corporation Systems and methods for event driven recovery management
US20060047714A1 (en) * 2004-08-30 2006-03-02 Mendocino Software, Inc. Systems and methods for rapid presentation of historical views of stored data
US8495023B1 (en) * 2004-09-01 2013-07-23 Symantec Operating Corporation Delta catalogs in a backup system
JP2006085279A (ja) * 2004-09-14 2006-03-30 Konica Minolta Business Technologies Inc ファイル管理プログラムおよびファイル管理方法
US7591018B1 (en) 2004-09-14 2009-09-15 Trend Micro Incorporated Portable antivirus device with solid state memory
US7873782B2 (en) * 2004-11-05 2011-01-18 Data Robotics, Inc. Filesystem-aware block storage system, apparatus, and method
JP5055125B2 (ja) * 2004-11-05 2012-10-24 ドロボ， インコーポレイテッド 種々のサイズの格納デバイスを許容する動的にアップグレード可能な故障許容格納システムおよび方法
US7814367B1 (en) * 2004-11-12 2010-10-12 Double-Take Software Canada, Inc. Method and system for time addressable storage
US7949665B1 (en) 2004-11-19 2011-05-24 Symantec Corporation Rapidly traversing disc volumes during file content examination
US7784097B1 (en) * 2004-11-24 2010-08-24 The Trustees Of Columbia University In The City Of New York Systems and methods for correlating and distributing intrusion alert information among collaborating computer systems
US7440398B2 (en) * 2004-11-29 2008-10-21 Honeywell International Inc. Fault tolerant communication apparatus
US20060130144A1 (en) * 2004-12-14 2006-06-15 Delta Insights, Llc Protecting computing systems from unauthorized programs
US7509530B2 (en) * 2005-01-19 2009-03-24 Sonic Solutions Method and system for use in restoring an active partition
US20060200589A1 (en) * 2005-02-18 2006-09-07 Collins Mark A Automated driver reset for an information handling system
US7440979B2 (en) * 2005-03-30 2008-10-21 Sap Ag Snapshots for instant backup in a database management system
US7694088B1 (en) * 2005-03-31 2010-04-06 Symantec Operating Corporation System and method for efficient creation of aggregate backup images
US20090132613A1 (en) * 2005-04-25 2009-05-21 Koninklijke Philips Electronics, N.V. Apparatus, Method and System For Restoring Files
US7327167B2 (en) * 2005-04-28 2008-02-05 Silicon Graphics, Inc. Anticipatory programmable interface pre-driver
US20060265756A1 (en) * 2005-05-11 2006-11-23 Microsoft Corporation Disk protection using enhanced write filter
US8335768B1 (en) * 2005-05-25 2012-12-18 Emc Corporation Selecting data in backup data sets for grooming and transferring
US8521752B2 (en) * 2005-06-03 2013-08-27 Osr Open Systems Resources, Inc. Systems and methods for arbitrary data transformations
WO2007002397A2 (en) * 2005-06-24 2007-01-04 Syncsort Incorporated System and method for high performance enterprise data protection
US9378099B2 (en) 2005-06-24 2016-06-28 Catalogic Software, Inc. Instant data center recovery
US7653682B2 (en) * 2005-07-22 2010-01-26 Netapp, Inc. Client failure fencing mechanism for fencing network file system data in a host-cluster environment
US7536583B2 (en) * 2005-10-14 2009-05-19 Symantec Operating Corporation Technique for timeline compression in a data store
US7610320B2 (en) * 2005-10-14 2009-10-27 Symantec Corporation Technique for remapping data in a storage management system
JP2009512939A (ja) * 2005-10-21 2009-03-26 ヴァー２アス インコーポレイテッド 複数のオペレーティングシステムのインスタンスが単一のマシン資源を安全に共有することを可能とする、オペレーティングシステムの仮想化、を有するコンピュータセキュリティ方法
US7756834B2 (en) * 2005-11-03 2010-07-13 I365 Inc. Malware and spyware attack recovery system and method
US8677087B2 (en) 2006-01-03 2014-03-18 Emc Corporation Continuous backup of a storage device
US20070174664A1 (en) * 2006-01-04 2007-07-26 Ess Data Recovery, Inc. Data recovery application
US7693883B2 (en) * 2006-01-30 2010-04-06 Sap Ag Online data volume deletion
US8341127B1 (en) * 2006-02-02 2012-12-25 Emc Corporation Client initiated restore
US8042172B1 (en) * 2006-02-02 2011-10-18 Emc Corporation Remote access architecture enabling a client to perform an operation
US8886902B1 (en) 2006-02-02 2014-11-11 Emc Corporation Disk backup set access
US7574621B2 (en) * 2006-03-14 2009-08-11 Lenovo (Singapore) Pte Ltd. Method and system for identifying and recovering a file damaged by a hard drive failure
US7975304B2 (en) * 2006-04-28 2011-07-05 Trend Micro Incorporated Portable storage device with stand-alone antivirus capability
EP2021926A4 (en) 2006-05-05 2009-07-15 Hybir Inc SYSTEM FOR SAVING INCREMENTAL AND COMPLETE COMPUTER-BASED FILE FILES BASED ON THE GROUP, PROCESS AND APPARATUS
US7793110B2 (en) * 2006-05-24 2010-09-07 Palo Alto Research Center Incorporated Posture-based data protection
ATE440322T1 (de) * 2006-06-29 2009-09-15 Incard Sa Komprimierungsverfahren zur verwaltung der speicherung von persistenten daten eines nichtflüchtigen speichers in einen sicherungspuffer
US7512748B1 (en) 2006-08-17 2009-03-31 Osr Open Systems Resources, Inc. Managing lock rankings
US8539228B1 (en) 2006-08-24 2013-09-17 Osr Open Systems Resources, Inc. Managing access to a resource
US8301673B2 (en) * 2006-12-29 2012-10-30 Netapp, Inc. System and method for performing distributed consistency verification of a clustered file system
WO2008092031A2 (en) * 2007-01-24 2008-07-31 Vir2Us, Inc. Computer system architecture having isolated file system management for secure and reliable data processing
US8219821B2 (en) 2007-03-27 2012-07-10 Netapp, Inc. System and method for signature based data container recognition
US8260748B1 (en) * 2007-03-27 2012-09-04 Symantec Corporation Method and apparatus for capturing data from a backup image
US8024433B2 (en) * 2007-04-24 2011-09-20 Osr Open Systems Resources, Inc. Managing application resources
US7827350B1 (en) 2007-04-27 2010-11-02 Netapp, Inc. Method and system for promoting a snapshot in a distributed file system
US8219749B2 (en) * 2007-04-27 2012-07-10 Netapp, Inc. System and method for efficient updates of sequential block storage
US7882304B2 (en) * 2007-04-27 2011-02-01 Netapp, Inc. System and method for efficient updates of sequential block storage
US7844853B2 (en) * 2007-08-07 2010-11-30 International Business Machines Corporation Methods and apparatus for restoring a node state
US7949693B1 (en) 2007-08-23 2011-05-24 Osr Open Systems Resources, Inc. Log-structured host data storage
US7996636B1 (en) 2007-11-06 2011-08-09 Netapp, Inc. Uniquely identifying block context signatures in a storage volume hierarchy
CN101459679A (zh) * 2007-12-12 2009-06-17 华为技术有限公司 网络存储设备及数据读写控制方法
US8271454B2 (en) * 2007-12-18 2012-09-18 Microsoft Corporation Circular log amnesia detection
US7857420B2 (en) * 2007-12-27 2010-12-28 Infoprint Solutions Company, Llc Methods and apparatus to identify pages to be discarded in a print system
US7831861B1 (en) * 2008-02-07 2010-11-09 Symantec Corporation Techniques for efficient restoration of granular application data
US8180744B2 (en) * 2008-03-05 2012-05-15 Hewlett-Packard Development Company, L.P. Managing storage of data in a data structure
US8725986B1 (en) 2008-04-18 2014-05-13 Netapp, Inc. System and method for volume block number to disk block number mapping
US8271751B2 (en) * 2008-04-24 2012-09-18 Echostar Technologies L.L.C. Systems and methods for reliably managing files in a computer system
US20100061207A1 (en) 2008-09-09 2010-03-11 Seagate Technology Llc Data storage device including self-test features
JP2010123233A (ja) * 2008-11-21 2010-06-03 Hitachi Global Storage Technologies Netherlands Bv 磁気ディスク・ドライブ及び磁気ディスクへのデータ記録方法
US8738621B2 (en) * 2009-01-27 2014-05-27 EchoStar Technologies, L.L.C. Systems and methods for managing files on a storage device
US8307154B2 (en) * 2009-03-03 2012-11-06 Kove Corporation System and method for performing rapid data snapshots
US8788751B2 (en) * 2009-05-01 2014-07-22 Ca, Inc. Restoring spanned volumes of data
US8131928B2 (en) * 2009-05-01 2012-03-06 Computer Associates Think, Inc. Restoring striped volumes of data
US8731190B2 (en) * 2009-06-09 2014-05-20 Emc Corporation Segment deduplication system with encryption and compression of segments
US8918779B2 (en) * 2009-08-27 2014-12-23 Microsoft Corporation Logical migration of applications and data
US8386731B2 (en) * 2009-09-14 2013-02-26 Vmware, Inc. Method and system for optimizing live migration of persistent data of virtual machine using disk I/O heuristics
US9244716B2 (en) 2009-10-30 2016-01-26 Avaya Inc. Generation of open virtualization framework package for solution installations and upgrades
US8793288B2 (en) * 2009-12-16 2014-07-29 Sap Ag Online access to database snapshots
WO2011096201A1 (ja) * 2010-02-04 2011-08-11 パナソニック株式会社 情報再生装置および情報再生方法
JP2011170680A (ja) * 2010-02-19 2011-09-01 Nec Corp フォールト・トレラントサーバ
US8612398B2 (en) * 2010-03-11 2013-12-17 Microsoft Corporation Clean store for operating system and software recovery
US8412899B2 (en) 2010-04-01 2013-04-02 Autonomy, Inc. Real time backup storage node assignment
WO2021220058A1 (en) * 2020-05-01 2021-11-04 Monday.com Ltd. Digital processing systems and methods for enhanced collaborative workflow and networking systems, methods, and devices
WO2021161104A1 (en) 2020-02-12 2021-08-19 Monday.Com Enhanced display features in collaborative network systems, methods, and devices
WO2021099839A1 (en) 2019-11-18 2021-05-27 Roy Mann Collaborative networking systems, methods, and devices
WO2021144656A1 (en) 2020-01-15 2021-07-22 Monday.Com Digital processing systems and methods for graphical dynamic table gauges in collaborative work systems
US11410129B2 (en) 2010-05-01 2022-08-09 Monday.com Ltd. Digital processing systems and methods for two-way syncing with third party applications in collaborative work systems
US8452735B2 (en) 2010-05-26 2013-05-28 International Business Machines Corporation Selecting a data restore point with an optimal recovery time and recovery point
US8818962B2 (en) 2010-05-26 2014-08-26 International Business Machines Corporation Proactive detection of data inconsistencies in a storage system point-in-time copy of data
US8468365B2 (en) 2010-09-24 2013-06-18 Intel Corporation Tweakable encryption mode for memory encryption with protection against replay attacks
US8756361B1 (en) 2010-10-01 2014-06-17 Western Digital Technologies, Inc. Disk drive modifying metadata cached in a circular buffer when a write operation is aborted
US8954664B1 (en) * 2010-10-01 2015-02-10 Western Digital Technologies, Inc. Writing metadata files on a disk
WO2012053085A1 (ja) * 2010-10-21 2012-04-26 富士通株式会社 ストレージ制御装置およびストレージ制御方法
US10073844B1 (en) * 2010-11-24 2018-09-11 Federal Home Loan Mortgage Corporation (Freddie Mac) Accelerated system and method for providing data correction
US9021198B1 (en) 2011-01-20 2015-04-28 Commvault Systems, Inc. System and method for sharing SAN storage
TW201239612A (en) * 2011-03-31 2012-10-01 Hon Hai Prec Ind Co Ltd Multimedia storage device
US20120284474A1 (en) * 2011-05-06 2012-11-08 International Business Machines Corporation Enabling recovery during data defragmentation
US8756382B1 (en) 2011-06-30 2014-06-17 Western Digital Technologies, Inc. Method for file based shingled data storage utilizing multiple media types
US11016702B2 (en) * 2011-07-27 2021-05-25 Pure Storage, Inc. Hierarchical event tree
US8903874B2 (en) 2011-11-03 2014-12-02 Osr Open Systems Resources, Inc. File system directory attribute correction
US9372910B2 (en) * 2012-01-04 2016-06-21 International Business Machines Corporation Managing remote data replication
KR102050732B1 (ko) * 2012-09-28 2019-12-02 삼성전자 주식회사 컴퓨팅 시스템 및 컴퓨팅 시스템의 데이터 관리 방법
US9633035B2 (en) * 2013-01-13 2017-04-25 Reduxio Systems Ltd. Storage system and methods for time continuum data retrieval
US9189409B2 (en) * 2013-02-19 2015-11-17 Avago Technologies General Ip (Singapore) Pte. Ltd. Reducing writes to solid state drive cache memories of storage controllers
US9471485B2 (en) * 2013-03-12 2016-10-18 Macronix International Co., Ltd. Difference L2P method
US9110847B2 (en) 2013-06-24 2015-08-18 Sap Se N to M host system copy
US9342419B2 (en) * 2013-11-11 2016-05-17 Globalfoundries Inc. Persistent messaging mechanism
JP5953295B2 (ja) * 2013-12-12 2016-07-20 京セラドキュメントソリューションズ株式会社 ファクシミリ装置
KR20150081810A (ko) * 2014-01-07 2015-07-15 한국전자통신연구원 데이터 저장장치에 대한 다중 스냅샷 관리 방법 및 장치
US9830329B2 (en) 2014-01-15 2017-11-28 W. Anthony Mason Methods and systems for data storage
US9423961B2 (en) * 2014-09-08 2016-08-23 Apple Inc. Method to enhance programming performance in multilevel NVM devices
US10110572B2 (en) 2015-01-21 2018-10-23 Oracle International Corporation Tape drive encryption in the data path
US10089481B2 (en) 2015-09-23 2018-10-02 International Business Machines Corporation Securing recorded data
US10083096B1 (en) * 2015-12-15 2018-09-25 Workday, Inc. Managing data with restoring from purging
US10296418B2 (en) * 2016-01-19 2019-05-21 Microsoft Technology Licensing, Llc Versioned records management using restart era
US10382436B2 (en) * 2016-11-22 2019-08-13 Daniel Chien Network security based on device identifiers and network addresses
US10761743B1 (en) 2017-07-17 2020-09-01 EMC IP Holding Company LLC Establishing data reliability groups within a geographically distributed data storage environment
JP6940768B2 (ja) * 2017-11-01 2021-09-29 富士通株式会社 テスト制御プログラム、テスト制御装置及びテスト制御方法
KR101975880B1 (ko) * 2017-11-30 2019-08-28 부경대학교 산학협력단 메모리 절약을 지원하는 실시간 협업 편집방법
US11698890B2 (en) 2018-07-04 2023-07-11 Monday.com Ltd. System and method for generating a column-oriented data structure repository for columns of single data types
US11436359B2 (en) 2018-07-04 2022-09-06 Monday.com Ltd. System and method for managing permissions of users for a single data type column-oriented data structure
US11126505B1 (en) * 2018-08-10 2021-09-21 Amazon Technologies, Inc. Past-state backup generator and interface for database systems
US11188622B2 (en) 2018-09-28 2021-11-30 Daniel Chien Systems and methods for computer security
US11436203B2 (en) 2018-11-02 2022-09-06 EMC IP Holding Company LLC Scaling out geographically diverse storage
US10848489B2 (en) 2018-12-14 2020-11-24 Daniel Chien Timestamp-based authentication with redirection
US10826912B2 (en) 2018-12-14 2020-11-03 Daniel Chien Timestamp-based authentication
US11748004B2 (en) 2019-05-03 2023-09-05 EMC IP Holding Company LLC Data replication using active and passive data storage modes
KR102070885B1 (ko) * 2019-07-24 2020-03-02 주식회사 이글루시스템즈 블록단위의 분산 데이터 동기화 시스템
US11449399B2 (en) * 2019-07-30 2022-09-20 EMC IP Holding Company LLC Mitigating real node failure of a doubly mapped redundant array of independent nodes
US11228322B2 (en) 2019-09-13 2022-01-18 EMC IP Holding Company LLC Rebalancing in a geographically diverse storage system employing erasure coding
US11449248B2 (en) 2019-09-26 2022-09-20 EMC IP Holding Company LLC Mapped redundant array of independent data storage regions
US11288139B2 (en) 2019-10-31 2022-03-29 EMC IP Holding Company LLC Two-step recovery employing erasure coding in a geographically diverse data storage system
US11435910B2 (en) 2019-10-31 2022-09-06 EMC IP Holding Company LLC Heterogeneous mapped redundant array of independent nodes for data storage
US20210149553A1 (en) 2019-11-18 2021-05-20 Monday.Com Digital processing systems and methods for real-time resource and capacity allocation in collaborative work systems
US11435957B2 (en) 2019-11-27 2022-09-06 EMC IP Holding Company LLC Selective instantiation of a storage service for a doubly mapped redundant array of independent nodes
US11677754B2 (en) 2019-12-09 2023-06-13 Daniel Chien Access control systems and methods
US11231860B2 (en) 2020-01-17 2022-01-25 EMC IP Holding Company LLC Doubly mapped redundant array of independent nodes for data storage with high performance
CN111352617B (zh) * 2020-03-16 2023-03-31 山东省物化探勘查院 一种基于Fortran语言的磁法数据辅助整理方法
US11507308B2 (en) 2020-03-30 2022-11-22 EMC IP Holding Company LLC Disk access event control for mapped nodes supported by a real cluster storage system
US20240184989A1 (en) 2020-05-01 2024-06-06 Monday.com Ltd. Digital processing systems and methods for virtualfile-based electronic white board in collaborative work systems systems
US11277361B2 (en) 2020-05-03 2022-03-15 Monday.com Ltd. Digital processing systems and methods for variable hang-time for social layer messages in collaborative work systems
US11288229B2 (en) 2020-05-29 2022-03-29 EMC IP Holding Company LLC Verifiable intra-cluster migration for a chunk storage system
US11509463B2 (en) 2020-05-31 2022-11-22 Daniel Chien Timestamp-based shared key generation
US11438145B2 (en) 2020-05-31 2022-09-06 Daniel Chien Shared key generation based on dual clocks
US11693983B2 (en) 2020-10-28 2023-07-04 EMC IP Holding Company LLC Data protection via commutative erasure coding in a geographically diverse data storage system
US11687216B2 (en) 2021-01-14 2023-06-27 Monday.com Ltd. Digital processing systems and methods for dynamically updating documents with data from linked files in collaborative work systems
US11847141B2 (en) 2021-01-19 2023-12-19 EMC IP Holding Company LLC Mapped redundant array of independent nodes employing mapped reliability groups for data storage
US11625174B2 (en) 2021-01-20 2023-04-11 EMC IP Holding Company LLC Parity allocation for a virtual redundant array of independent disks
US11354191B1 (en) 2021-05-28 2022-06-07 EMC IP Holding Company LLC Erasure coding in a large geographically diverse data storage system
US11449234B1 (en) 2021-05-28 2022-09-20 EMC IP Holding Company LLC Efficient data access operations via a mapping layer instance for a doubly mapped redundant array of independent nodes
US20230071375A1 (en) * 2021-09-03 2023-03-09 Motional Ad Llc Protecting confidentiality of air-gapped logs
US11775399B1 (en) * 2022-03-28 2023-10-03 International Business Machines Corporation Efficient recovery in continuous data protection environments
US11797394B1 (en) * 2022-05-30 2023-10-24 Vast Data Ltd. Snapshot restore
US11741071B1 (en) 2022-12-28 2023-08-29 Monday.com Ltd. Digital processing systems and methods for navigating and viewing displayed content
US11886683B1 (en) 2022-12-30 2024-01-30 Monday.com Ltd Digital processing systems and methods for presenting board graphics
US11893381B1 (en) 2023-02-21 2024-02-06 Monday.com Ltd Digital processing systems and methods for reducing file bundle sizes

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5089958A (en) * 1989-01-23 1992-02-18 Vortex Systems, Inc. Fault tolerant computer backup system
CA2063379C (en) * 1989-07-11 1998-02-10 Peter Bryan Malcolm Method of operating a data processing system
DE69126066T2 (de) * 1990-06-29 1997-09-25 Oracle Corp Verfahren und Gerät zur Optimierung des Logbuchaufhebungsgebrauchs
JP2993528B2 (ja) * 1991-05-18 1999-12-20 富士通株式会社 テキスト管理・復元方式
EP0516900B1 (en) 1991-06-04 1996-05-01 International Business Machines Corporation Data backup and recovery in a data processing system
US5325519A (en) * 1991-10-18 1994-06-28 Texas Microsystems, Inc. Fault tolerant computer with archival rollback capabilities
US5802264A (en) * 1991-11-15 1998-09-01 Fujitsu Limited Background data reconstruction in a storage device array system
US5369758A (en) * 1991-11-15 1994-11-29 Fujitsu Limited Checking for proper locations of storage devices in a storage array
US5297258A (en) * 1991-11-21 1994-03-22 Ast Research, Inc. Data logging for hard disk data storage systems
US5339406A (en) * 1992-04-03 1994-08-16 Sun Microsystems, Inc. Reconstructing symbol definitions of a dynamically configurable operating system defined at the time of a system crash
US5331646A (en) * 1992-05-08 1994-07-19 Compaq Computer Corporation Error correcting code technique for improving reliablility of a disk array
US5404361A (en) * 1992-07-27 1995-04-04 Storage Technology Corporation Method and apparatus for ensuring data integrity in a dynamically mapped data storage subsystem
US5530855A (en) * 1992-10-13 1996-06-25 International Business Machines Corporation Replicating a database by the sequential application of hierarchically sorted log records
US5487160A (en) * 1992-12-04 1996-01-23 At&T Global Information Solutions Company Concurrent image backup for disk storage system
US5557770A (en) * 1993-03-24 1996-09-17 International Business Machines Corporation Disk storage apparatus and method for converting random writes to sequential writes while retaining physical clustering on disk
US5659747A (en) * 1993-04-22 1997-08-19 Microsoft Corporation Multiple level undo/redo mechanism
US5835953A (en) 1994-10-13 1998-11-10 Vinca Corporation Backup system that takes a snapshot of the locations in a mass storage device that has been identified for updating prior to updating
US5649152A (en) * 1994-10-13 1997-07-15 Vinca Corporation Method and system for providing a static snapshot of data stored on a mass storage system
US5604862A (en) * 1995-03-14 1997-02-18 Network Integrity, Inc. Continuously-snapshotted protection of computer files
JPH096546A (ja) * 1995-06-19 1997-01-10 Toshiba Corp ディスク制御システム
US6016553A (en) * 1997-09-05 2000-01-18 Wild File, Inc. Method, software and apparatus for saving, using and recovering data

Also Published As

Publication number Publication date
WO1999012101A3 (en) 1999-08-19
US6199178B1 (en) 2001-03-06
AU9383298A (en) 1999-03-22
US6240527B1 (en) 2001-05-29
WO1999012101A2 (en) 1999-03-11
JP2004504645A (ja) 2004-02-12
DE19882659T1 (de) 2000-10-12
US6016553A (en) 2000-01-18

Similar Documents

Publication Publication Date Title
JP3878412B2 (ja) データを保存し使用し及び回復する方法
US5086502A (en) Method of operating a data processing system
US8296264B1 (en) Method and system for file-level continuous data protection
KR100962055B1 (ko) 컴퓨터 시스템들간의 객체 공유
JP2703479B2 (ja) タイム・ゼロ・バックアップ・セッションの安全保護機能を有するデータ処理方法及びシステム
US6732293B1 (en) Method, software and apparatus for recovering and recycling data in conjunction with an operating system
EP2391968B1 (en) System and method for secure and reliable multi-cloud data replication
US6460054B1 (en) System and method for data storage archive bit update after snapshot backup
US7246211B1 (en) System and method for using file system snapshots for online data backup
US8051044B1 (en) Method and system for continuous data protection
US8005797B1 (en) File-level continuous data protection with access to previous versions
US9606875B2 (en) Migration of computer data
US20020049883A1 (en) System and method for restoring a computer system after a failure
US7318135B1 (en) System and method for using file system snapshots for online data backup
US7363540B2 (en) Transaction-safe FAT file system improvements
US7383465B1 (en) Undoable volume using write logging
US20070061540A1 (en) Data storage system using segmentable virtual volumes
WO2010038558A1 (ja) 情報バックアップ／リストア処理装置、及び情報バックアップ／リストア処理システム
CZ9701859A3 (cs) Ukládání počítačových dat
JPH07104808B2 (ja) 設置可能なファイルシステムにおいてダイナミックボリュームトラッキングを行う方法及び装置
KR20010007111A (ko) 데이터 프로세서 제어형 데이터 저장 시스템, 동적재동기화 방법 및 컴퓨터 프로그램
KR20000022716A (ko) 로그 구조화 목표 저장장치를 사전에 구성하여 볼륨을 효율적으로 복사하는 방법 및 장치
JP2008146408A (ja) データ記憶装置、そのデータ再配置方法、プログラム
US6629203B1 (en) Alternating shadow directories in pairs of storage spaces for data storage
EP0483174B1 (en) A method of operating a data processing system

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040921

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20041220

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20050104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20050318

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20050705

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20050705

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20051128

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20051128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060124

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20060421

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20060501

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060724

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20061003

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20061102

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20091110

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101110

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees