JP3797864B2 - オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 - Google Patents
オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 Download PDFInfo
- Publication number
- JP3797864B2 JP3797864B2 JP2000308367A JP2000308367A JP3797864B2 JP 3797864 B2 JP3797864 B2 JP 3797864B2 JP 2000308367 A JP2000308367 A JP 2000308367A JP 2000308367 A JP2000308367 A JP 2000308367A JP 3797864 B2 JP3797864 B2 JP 3797864B2
- Authority
- JP
- Japan
- Prior art keywords
- disk
- data
- history
- location
- state
- 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
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/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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Library & Information Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
Description
【発明の属する技術分野】
本発明は、一般にデジタルデータの格納に関し、特に、オペレーティングシステム(OS)によって同システム管理下のファイルになされた変更を、デジタルコンピュータによって格納されたデータのバックアップおよび回復を支援する変更追跡システムとの関連のもとで追跡するための、方法および装置に関する。
【0002】
【発明の背景】
コンピュータ上で実行されるアプリケーションは、特にハードディスクからの情報の保存および再呼び出しに責任を負う、オペレーティングシステム(OS)のもとで動作するのが通常である。情報は、通常はファイルに編成されている。OSは、ファイルと、そのファイル情報を保持するハードディスク上の関連位置との間でマッピングを行う方法を保持している。
【0003】
現在のコンピュータは、一般に、情報(データ)を読み出して永続記憶用のディスクに書き込む形で動作する。通常は、ディスクを周期的にバックアップ(コピー)することによって、次の2種類の問題に対処している。第1に、ディスク自体が物理的に故障すると、そこに含まれていた情報がアクセス不能となる。第2に、ディスク上の情報が変更され、もとの状態が望ましかったと判断されると、ユーザは、バックアップを使用してこのもとの状態を回復する。バックアップは、同じディスクまたは代替の媒体(ディスクやテープ装置等)に対して行うことができる。
【0004】
テープバックアップとしては、従来、ファイルまたはディスクセクタイメージとして編成されたディスクの内容を、磁気テープ上に複製する手法がある。このようなテープは、通常は取り外し可能であるので、サイトの外に格納して、ディスクドライブの誤動作や、さらには例えば火災による(ディスクドライブを含む)サイト全体の破壊に対して回復を提供することができる。
【0005】
情報がセクタレベルのディスクイメージの形態でディスクからテープにコピーされる(すなわち、情報がディスク上と同じ形でテープ上に編成される)場合は、同一のディスク駆動装置に対して最も効率的に復元を行うことができる。このように編成する理由は、速度である。ディスクを最初から最後まで順次読み出す方が、ディスク上を跳び回って一度に1ファイルづつ読み出すより遥かに高速である。これは、ファイルがディスクの1領域に連続的に保存されていないことが多く、ディスク全体に広がって他のファイルと混ざっている可能性があるからである。情報を一度に1ファイルづつテープにコピーする場合は、1つまたはそれ以上のファイルを、すでにデータを含んでいる異なるディスクで効率的に復元することができる。
【0006】
テープバックアップは、ある時点におけるディスク全体または特定のファイルをバックアップすることに焦点を合わせている。この処理は、長時間かかるのが通常であるため、例えば夕方等に低頻度で行われる。増分(インクレメンタル)バックアップは、最終のバックアップ以降に変更されたデータのみを保存するため、必要なテープ量およびバックアップ時間が低減される。しかしながら、システムを完全に回復させるには、システム全体の最初のバックアップとその後の増分バックアップ全てを読み出して結合し、最終の増分バックアップの時点まで復元しなければならない。テープバックアップの主要な欠点は、最新のバックアップが実行されていない場合に、最後のバックアップ後に生成された情報や作業が失われる可能性があるということである。
【0007】
WORMドライブによって行われるような追記型のディスクバックアップは、データバックアップと同じ特性を多数有する。しかし、その関連技術のためデータを上書きすることができない。したがってWORMドライブは、変更できないバックアップのある程度のリーガル「アカウンティング」システム(legal "accounting" system)を提供する。WORMドライブは、最終的に一杯になってしまうため、変化するディスク情報に連続的なバックアップを提供することはできない。
【0008】
RAIDシステムは、集合的に1つの記憶システムとして動作するドライブの集まりであり、1つのドライブの故障をデータの損失なしに許容し、且つ互いに独立して動作することができる。RAIDに含まれる2つの主要な技術は、ストライピングとミラーリングである。ストライピングは、データをドライブ間で分割して高いデータスループットを得る。ミラーリングは、全てのデータを1つのドライブから他のドライブに複製することによって冗長性を提供する。一般に、1つのドライブが故障しても、他のドライブが別のコピーを有しているため、データが失われることはない。
【0009】
RAIDシステムは、物理的なドライブの故障に対するバックアップという形で、速度およびデータの冗長性に関連する。しかしながら、RAIDシステムでは、変更された情報を検索する目的で時間を遡ることはない。
【0010】
Tiliosオペレーティングシステムは、ディスクの状態を保護し、ユーザによるその継続および修正を可能にするために、数年前に開発されたものである。このオペレーティングシステムでは、保護状態と現行状態の2つの状態が維持される。現行状態が失われるかまたは無効になるクラッシュが生じた場合に、ディスクを容易にその保護状態に復帰させ、ログを再生できるように、キー入力(キーストローク)のロギングが実行された。ここでは、例えばファイルを編集しているユーザをシミュレートすることによって、クラッシュした時点に至るまでのディスク情報を、全て回復することができる。保護されたディスクイメージが、現行のものと共に常に利用可能であるため、情報を後の時点にコピーする、すなわち保護バックアップの時点で保存された情報を現行状態にコピーすることができる。
【0011】
Tiliosオペレーティングシステムでは、全ての作業がディスク上で行われ(たとえば、テープへの転送がない)、変更の増分を記録するという特質(すなわち、現行状態と保護状態の差が通常は小さい)を利用した技術が使用されているため、バックアップをより高速で行うことができる。それにもかかわらず、ユーザは、やはり保護(バックアップ)を行う特定の時間を選択するという問題に直面しなければならず、キー入力の再生方法は、バックアップ後の状態を再現するのに全面的に信頼できるものではない。例えば、キー入力がフロッピィディスクまたはインターネットからデータをコピーするコマンドだった場合、それらの対話は、いずれもCPUおよびディスクで再現できる範囲の外にある。
【0012】
これまでは、ファイルの拡張子だけを変更した新しいファイル名でファイルのコピーを作成する(例えば、「abc.doc」を「abc.bak」にコピーする)ことにより、ファイルのバックアップが簡単に作成されてきた。この場合、メインファイル(abc.doc)が破損または紛失した時に、バックアップ(abc.bak)からそのファイルを復元することができる。しかしながら、この処理は、選択的なテープバックアップとほぼ同じであるため、バックアップ管理の問題(いつ行うか、いつ廃棄するか等)を伴う。
【0013】
要するに、RAIDシステムは、物理的ドライブの故障に関係したバックアップのみを取り扱っている。テープ、WORM、Tilios、およびファイルコピーは、変更された(失われた)情報の回復に関係したバックアップにも対処している。
【0014】
従来のバックアップ処理は、一定の期間停止してディスク情報の複製コピーを作成する作業を含む。これは、ディスク全体が再現されるか、または特定の情報が再呼び出しされるように、ディスク全体を見てコピーを作成する作業を含む。この処理は、テープへの書き込みを含むのが通常である。あるいはユーザは、特定の時点以降の凍結されているコピーを表す複製を作成することで、ファイルの特定の集合をバックアップしても良い。ここでは、オリジナルが継続して変更されることを想定している。この処理は、通常、オリジナルと同じディスクドライブ上にバックアップファイルを作成することを含む。ここで、「ディスク」とは実際には、1つもしくはそれ以上のディスクドライブ、またはディスクドライブと同様に作動する装置を意味することに注意が必要である。
【0015】
上述したいずれの場合も、ユーザは、バックアップを作成することを意識的に決定しなければならない。後者の場合は、テキストエディタのような特定のアプリケーションが、最後の数バージョンのファイル(情報)を保持している。しかしながら、ファイルがスタビライズされて長期間経た後には最終的に全てが複製されて、ディスク空間が浪費される原因となる。つまり、ユーザが、文書の処理中に前のバージョンに戻りたいケースは多くても、完了して何年も経過した後に、最終状態の直前の状態を再訪したいと思うことは滅多にない。
【0016】
情報の回復が非常に重要となるもう1つの状況は、どのファイルがディスク上のどの場所に位置しているかを識別するディスク用のディレクトリシステムが破損した場合である。これは、例えば、ディレクトリのアップデート(更新)中に生じるシステムクラッシュや、オペレーティングシステムまたは他のユーティリティ内でのバグが原因で発生する。いずれの場合も、ディスク内容のディレクトリが失われると、たとえ参照ファイルがディスク上に存在していたとしても、それら参照ファイルも失われる結果となる。この場合、ユーザが復元したい情報はディスクのディレクトリである。
【0017】
ユーザがバックアップに復帰したいと思う最後のケースは、例えば、動作しない新しいソフトウェアまたはデバイスドライバをインストールしたことが原因で、オペレーティングシステムが破損した場合である。
【0018】
ユーザが、コンピュータディスク上で操作されている情報の内容を、時間的に遡りたいと思う理由は数多くある。従来のバックアップでは、バックアップした時点まで回復することができた。しかしながら、システム全体に渡るこれらのバックアップは、ディスクを走査してその内容を複製するのに長時間必要であるため、行える頻度に限界がある。つまり、このバックアップでは、大きな動作休止と莫大な量の記憶領域とが必要であり、ディスク全体を数分毎にバックアップすることは不可能である。時間の進行に従ってファイルの履歴コピーを保持するには、結局はユーザがアーカイブの管理およびコピーの消去を行って、ディスクのオーバーフローを回避する必要がある。
【0019】
ファイルの名前を変更し、ファイルのデータを別のファイルと再び関連付ける(re-associate)技術は、データのコピーおよび古いファイルの検出に伴うオーバーヘッドを回避するのに使用される周知の技術である。OSのもとでファイルの名前を変更する動作は、一般に、割り当ての集合をOSのファイルシステム内であるファイルから別のファイルへと再び関連付けることを含む。大体の場合は、1ファイルが1集合のディスク割り当てを表し、記憶領域の管理は、同一のファイル内または異なるファイル間でこれらの割り当てを操作することによって行われる。例えば、PC上の自由記憶領域自体をファイルと見なすことができる。ファイルの作成時には、記憶領域が自由ファイルから引き出されて別のファイルと再び関連付けられる。ファイルを削除する技術は、その定義上、あるファイルデータを保持するのに使用された記憶領域が汎用プールに戻れることを、信号で示すためにOSのもとで使用される方法である。汎用プールは、OSが、新しく作成されたファイルに記憶領域を割り当てるもととなる領域である。これらの概念は、OSの設計技術の当業者に周知である。
【0020】
従来技術によるデータのバックアップアプリケーションに固有な別の問題点は、データがディスクに書き込まれる順番を制御する必要があることである。例えば、ある状態から別の状態に移行する場合は、移行データをディスク上に書き込み(フラッシュし)、次いで、データのバックアップアプリケーションで必要とされる内部バックアップデータを更新する。しかしながら、現在のディスクドライブは、性能向上のために書き込みキャッシュを備えているのが一般的である。書き込みキャッシュは、書き込みをバッファリングし、書き込みとは異なる順序でデータをディスク媒体上に格納(コミット)する。この処理は、例えばディスクコントローラが、ディスクヘッドの動きを低減する順序でデータを書き込むことを可能とすることにより、書き込み処理全体のスピードアップを図るものである。しかしながら、ディスク上にすでに存在すると想定されるデータ(書き込まれるのをまだ待機している)よりも、内部バックアップデータの方が先に更新される。電源障害が発生すると、ある安定状態から別の安定状態への安全な移行が不可能となる。
【0021】
ディスクドライブに送信されて、このような書き込みキャッシュの最適化を使用不可にできるコマンドが存在する。しかしながら、これらのコマンドは、他の有用な最適化をも使用不可とするため、深刻な性能低下を生じる原因となる。ディスクのなかには、フラッシュコマンドをサポートし書き込みキャッシュを特別にフラッシュするものもあるが、このようなコマンドを使用可能とするのは容易でない。つまり、今日のコンピュータには、ディスクでの読み取りおよび書き込みを行う基本入出力システム(BIOS)の標準手段が含まれているが、書き込みキャッシュをフラッシュする標準手段は含まれていない。したがって、コンピュータのディスクドライブがフラッシュコマンドをサポートするか否かに関わらず、データのバックアップアプリケーションは、標準的なBIOSインターフェースを使用していることが原因で、容易に初期化フラッシュを行うことができない。データのバックアップアプリケーションは、ディスクと直接通信を行う必要があるため、特別なハードウェア知識を有している。これは、あらゆるコンピュータ上で実行されることを期待される、汎用プログラムの見地からは不可能である。コンピュータメーカがとった一般的な方法は、特定タイプのハードディスクを、そのタイプのディスクの制御方法を知るBIOSと結合させることであった。その後のソフトウェアは全て、BIOSによって提供されたSCSIやIDE等のインターフェースに依存してディスクと送話するのが一般的であり、今日のインターフェースにフラッシュコマンドがは含まれていない。
【0022】
したがって、改良バックアップ方法は、専門のディスク(ハードウェア)知識をエンジン内に構築しなくても、書き込みキャッシュの存在を、それをフラッシュする必要なしに容易にするものである。これは、この方法が、ディスクコントローラに書き込まれるデータが実際には異なる順序でディスク媒体に格納(コミット)され得ることを考慮に入れなければならないこと、そしてそれにもかかわらず、この方法がディスク上のデータ保全性を維持してクラッシュの回復を可能とする必要があること、を意味する。
【0023】
【発明が解決しようとする課題】
以上から、データを回復させるための改良方法が必要とされていることがわかる。この改良方法は、コンピュータディスクの以前の状態を、安全且つ発生順に制御する方法で再構築することを可能とする必要がある。
【0024】
【発明の概要】
本発明は、大まかにいえば、コンピュータディスクの現行の状態と履歴データとを共に使用し、そのディスクの以前の状態を再構築する方法を提供することにより、上述したニーズを満たすものである。本発明では、セクタレベルのバックアップをファイルレベルのバックアップと組み合わせることにより、効率および信頼度の向上を図る。
【0025】
1実施形態では、データを回復させる方法を開示する。先ず、ディスク位置X、ディスク位置Y、ディスク位置Z等の種々のディスク位置を含むディスクについて、ディスクの履歴状態の記録を作成する。ディスク位置Xにあるもとのデータを新しいデータで上書きする要求に応じ、その新しいデータをディスク位置Yに格納する。次いで、履歴状態の記録内に、ディスク位置XおよびYの役割を示す標識を設定する。これらの役割は、履歴データを含むというディスク位置Xの役割、そして、ディスク位置Xの新しいデータを含むというディスク位置Yの役割を、規定することができる。また、この方法は、コマンドをインターセプトしてディスク位置Zにあるデータを解放し、履歴状態の記録内に、ディスク位置Zが履歴データを含むことを示す標識を設定することを含む。
【0026】
別の1実施形態では、コンピュータディスクの以前の状態を復元するためのコンピュータプログラムを開示する。このコンピュータプログラムは、オペレーティングシステムからのファイル管理コマンドをインターセプトすることができるコードセグメントと、ディスク位置の状態を示すマップとを含む。このコンピュータプログラムはさらに、メイン領域に履歴データをマッピングする履歴表をも含む。履歴表は、オペレーティングシステムによって解放されたディスク位置も示す。履歴表の各エントリは、発生順にアクセスされることができる。このコンピュータプログラムはさらに、ディスク更新の標識を実質上発生順に履歴表に記録するコードセグメントも含む。
【0027】
さらに別の1実施形態では、コンピュータ読み取り可能媒体の以前の状態を復元する方法を開示する。先ず、コンピュータ読み取り可能媒体への履歴変更のエントリを有したデータ構造を設定する。データ構造は、第1のデータ位置Xにあるもとのデータを新しいデータで上書きすることに関する書き込みエントリと、オペレーティングシステムによってデータ位置Zを解放することに関する解放エントリとを含む。次いで、コンピュータ読み取り可能媒体を再構築する要求に応じ、データ構造内で最新のエントリを検証する。書き込みエントリの検証に応じ、第1のデータ位置Xにある新しいデータをもとのデータで置き換える。さらに、解放エントリの検査に応じ、オペレーティングシステムが解放データ位置Zにアクセスできるようにする。すると、データ構造内で最新のエントリが廃棄され、同方法が、コンピュータ読み取り可能媒体の以前の状態が復元されるまで繰り返される。
【0028】
以下の説明から、本発明が、コンピュータディスクの以前の状態の再構築を安全且つ発生順の制御方法で行えることが、当業者にとって明らかとなる。本発明の他の態様および利点は、本発明の原理を例示した添付の図面と関連させて行う以下の詳細な説明から明らかとなる。
【0029】
【発明の実施の形態】
本発明は、履歴変更が追跡されるオペレーティングシステムとの関連のもとで、上書きされたディスク記憶領域を再生することを目的として開示されるものである。本発明は、オペレーティングシステムがデータを書き込む実際の格納位置を選択することを可能とする一方で、ディスクの以前の状態を再成するのに必要な古い履歴データをオペレーティングシステムから確実に保護する。本発明はまた、デフラグと、実際のディスク媒体への安全なデータの移行とを支援する。
【0030】
以下の説明では、本発明の完全な理解を促すために多くの詳細について特定している。しかしながら本発明は、これらの詳細の一部または全てを特定しなくても実施することが可能であることは当業者に明らかである。そのほか、本発明を不必要に不明瞭化するのを避けるため、周知の処理操作の詳細な説明は省略した。
【0031】
以下の議論をさらに明確にするため、次に、幾つかの用語、すなわちカレントディスクイメージ、シミュレートされたディスクイメージ、メイン領域、およびエキストラページ領域に関して説明する。カレントディスクイメージとは、過去のものではないディスクのビューを指し、ユーザが最後に書き込んだデータからなる。ディスク上に履歴ロギングが存在しない場合は、ディスクに現在含まれるデータがカレントイメージとなる。シミュレートされたディスクとは、ユーザおよびOSから完全に独立したディスクを指す。しかしながら、OSより下のレベルのエンジンは、カレントイメージおよび保存された履歴データをもとに、他のことをしているときに、このディスクを作成される。
【0032】
実際のハードディスクは、メインおよびエキストラのページからなる2つの基本領域に分割されるのが一般的である。メイン領域は、カレントイメージに属するページを保持する。エキストラのページ領域には、履歴データが保持されている。メイン領域のマップは、カレントイメージへのアクセスを転送して、エンジンによって割り当てられた位置の置き換えを可能とする。履歴マップの履歴ページ記述子は、履歴ページを管理する。メインおよびエキストラのページは、自身の領域内でまたは反対領域からのページとの間で、一時的に役割を交換することができる。したがって、通常なら履歴データを保持するエキストラページ領域に属するページに、カレントイメージの一部を一時的にマッピングしても良い。
【0033】
「上書きデータ」という表現にも注意する必要がある。上書きデータは、物理的に上書きされたデータを意味するのではない。ファイルには、アプリケーションによって上書きされ得るデータが含まれる。しかしながら、本発明は、データのもとの状態を保存することに関するものである。これは、物理的に上書きされる前にデータをコピーする(移動させる)か、または書き込みの宛先を変更して本当に上書きされるのを回避することによって達成される。したがって、「上書きデータ」という表現は、OSによる上書きに先だって存在するファイルのデータであって、履歴データとしてエンジンに保持されているデータを意味する。
【0034】
ディスク管理の責務は、オペレーティングシステムからファイリングシステム(例えばウィンドウズNTのNTFS)へと分離され得る。本明細書の目的に沿って、OSに言及する際は、ディスク管理に伴うあらゆる他のサブシステムを含むものとする。
【0035】
エンジンという用語は、目下議論中の方法を実現するためのロジックを意味する。種々の方法が議論され、それぞれの方法は独自のエンジンを有する。
【0036】
「エキストラページ領域」の「エキストラ」という用語は、概念的に、ユーザから可視でないものがエキストラであるという思想に基づく。ディスクは、物理的に所定の容量を有する。しかしながら、ディスクのなかには、保留されてユーザから隠されている領域がある。このため、OSによって報告される、ユーザにとって可視のディスクサイズ(メイン領域)は、そのディスクの真のサイズよりも小さい。したがって、ユーザにとって可視でない記憶領域が「エキストラ」であり、エンジンが利用するものである。
【0037】
OSは、その制御下にある種々の構造(例えばファイル)にディスク位置を割り当てる。しかしながら、エンジンのなかには、OSのディスク位置を他の位置に再マッピングするものもあるため、OSに関連した「ディスク位置」とエンジンに関連した「ディスク位置」とを区別するために、OSのディスク位置を位置キーと呼ぶ。
【0038】
本発明は、上書きデータのもとの状態を保持するための3つの方法、すなわちTemp、Always、File方法を改良するものである。Temp方法およびAlways方法では、所定の時点におけるディスクのもとの状態をオペレーティングシステム(OS)およびアプリケーション(例えばゲーム)から保護する機構(エンジン)は隔離されている。ここで、保護された「状態」は、エンジンを介してOSによってビューされるものであり、エンジンは、OSによる関連ディスク領域へのデータの割り当てを再マッピングまたは管理する。保護機構がOSにおけるバグまたは望ましくないディスク書き込み動作に影響されないため、このような隔離によって信頼性を向上させることができる。
【0039】
また、エンジンの隔離は、保護メカニズムがハードウェアにマイグレーションすることも可能とする。すでに議論したように、ハードウェアへのマイグレーションは、例えばCPU、ディスクインターフェース、および/またはハードディスクコントローラへの、保護エレメント(ロジック)の組み込みを含むことができる。
【0040】
一般に、OSによる記憶領域の割り当ておよび解放をエンジンによるそれと密接に協調させて、冗長または余分な工程を低減または排除することが望ましい。このような余分な工程(オーバヘッド)は、エンジンをOSから隔離したいという要求が原因で導入されるものである。換言すると、エンジンは、OSとの信頼できない関係を想定していることがある。つまり、OSが、自身がアクセス可能なあらゆるデータを破壊するように作動する可能性があることを想定している。Temp方法は、ディスク上のOSのデータ編成を維持するように努めているため、データを実際のディスク位置に割り当てるのに際しての、OSとエンジンとの協調はほとんどない。
【0041】
Always方法では、エンジンへの割り当て解除の情報の提供を含む、より密接な関係を使用する。Always方法を実装するエンジンは、一般に、この情報およびその他の情報を使用して、データを移動させる必要を回避することにより、所定のディスク位置(ファイル)におけるもとの内容を保存または最適化する。換言すると、OSが新しいデータを書き込む場合、ディスク上に最初に割り当てられた位置は、(Temp方法の場合と比べて)かなり永続的である。
【0042】
本発明は、Temp、Always、およびFile方法の変形例を詳細化しており、OSは、データを書き込む実際の格納位置の選択において、より重要な役割を果たす。しかしながら、本発明は同時にまた、ディスクの以前の状態を再現するのに必要な古い履歴データを、OSから確実に保護する。このため、エンジンロジックの一部分は、オペレーティングシステムに対する多少とも標準的な動作か、または増補動作によって処理される。本発明はまた、デフラグ処理と、ディスクの実際の媒体へのデータの安全な推移とを支援する。
【0043】
本発明の方法は、OSとエンジンの間における、割り当て情報および割り当て解除情報の交換に基づくものである。しかしながら本発明では、特定の方法をディテイルする。そうすることによって、あるファイルから別のファイルへの記憶領域の再関連付け(ファイルの名前変更)と、記憶領域の解放(ファイルの削除)と、を行うためのOS機構は、方法と組み合わされ、これらの動作がエンジンの復元能力に害を及ぼさないようにされる。
【0044】
本発明は一般に、データに対する少なくとも最終的なディスク上の位置はどこであるかをOSが決めることを可能とする。このためファイルシステムは、少なくとも最終的には、エンジンがデータを実際に配置したディスク位置にファイルを直接マッピングして、これ以上の再マッピングを不要とする。
【0045】
本発明の1実施形態を、ATF方法(Always、Temp、およびFileの3つの方法を組み合わせたもの)と呼ぶことにする。ATF方法では、OSが新しいデータの大部分に対して、スワッピングが不要となるように、最終的なディスク位置を選出できるようにして、スワップされなければならないデータの量の低減を図る。この方法はまた、デフラグ処理を分離することによって、OSまたは別のユーティリティが、提供されたエンジンへのインターフェースを使用して、動作を実行できるようにする。
【0046】
本発明では、OSとエンジン(ATF方法)との間にインターフェースを追加することによって、未割り当ての(「真に未使用である」)OSディスク位置に関する通知をはじめにエンジンが受け取るようにする。ここでは、特定の位置が真に未使用であることをエンジンに通知することによって、エンジンがこれらの位置を効果的にゼロ化することができる、というルールが成り立つ。ここで注意する必要があるのは、エンジンはこれらの位置に実際にデータを格納し得るものの、OSがこれらの位置のどれかを読み出そうと試みると、エンジンからはゼロデータが戻されるという点である。この後者の工程は、エンジンによる内部目的のために使用される、履歴データを含む領域にOSがアクセスするのを防ぐものである(このため同データに一定レベルのセキュリティを提供する)。
【0047】
OSが、使用中のディスク位置への書き込みを行うと、エンジンは、Temp方法に従って書き込みの宛先を変更して、その後、新しいデータと履歴データとをスワップする。オペレーティングシステムが、記憶領域が真に未使用であることをフラグする(後ほど簡単に説明する)と、フラグされたページは、(セキュリティのために)少なくとも実効的にゼロ化される。OSが、真に未使用であることをフラグされた位置に書き込みを行う場合、データは、エンジンによって直接その場所に書き込まれる。したがって、エンジンは、OSによって真に未使用であるとフラグされた場所を示したマップを保持する。
【0048】
ATF方法は、アクティブ(メイン領域)を含むデータから履歴(エキストラページ)を含むデータへのOSディスク位置の移行が、OSまたは拡張OSのいずれに移動したかをFile方法から取得する。拡張OSは、標準OSに補足コードを組み合わせることによって、エンジンが必要とする動作を実現するものであり、OSに既存のものではない。記憶領域は、基本的に、オペレーティングシステムによって解放されるのに伴って「ほとんど未使用」の状態に移行する。この状態は、以下の点において「真に未使用」な状態とは異なる。すなわち、その記憶領域は、オペレーティングシステムによって正式に解放されているものの、その内容は以前の状態の回復に使用される可能性に備えて維持されて、経年処理を経てほとんど未使用から真に未使用な状態に移行する。換言すると、ほとんど未使用な記憶領域は、単なる古い履歴データである。このような記憶領域は、エンジンとの関連において履歴データ(OSによって上書きされてエンジンによって保存されているディスク位置)と呼ばれる。本発明では、OSがこの記憶領域を認識しているため、この記憶領域は、OSとの関連においてほとんど未使用な記憶領域と呼ばれる。
【0049】
ディスクおよびファイルは、OSを通常に使用している最中に様々な形で変更される。ファイルは、部分的に(例えば途中の数バイトを)上書きされることができる。新しいファイルを形成したり、ファイルを削除したりすることもできる。既存ファイルの内容を廃棄して新しいデータで置き換えたり(削除と作成の組み合わせ)、ファイルを切りつめたり(ファイルのうち特定の点以降のデータを全て廃棄する)することもできる。OSは、多種類の動作を支援することができる。ユーザに可視のファイルに関連していないディスクデータは、OSのファイル管理に関連しているのが通常である。例として、特定のディスク位置を特定のファイルに関連付ける表が挙げられる。このような情報は、すでに言及したように、少なくとも概念的には特別な内部OSファイルと見なされることができる。本発明の課題の1つは、(OSによってビューされる)早い時間におけるディスクの内容を再現する方法を提供することにある。
【0050】
ATF方法は、ディスクの一般的な変更の保存を、Temp方法に類似の方法を使用して処理する。しかしながら、ATF方法は、「削除」された記憶領域、すなわちその内容はもう不要であるが回復での使用の可能性に備えてエンジンで追跡する必要があるような記憶領域を、OSに通知する。
【0051】
一般に、容易にインターセプトされ調整されて、少なくともいくらかの割り当て解除をキャッチすることができる動作は2つある。すなわち、ファイル削除の動作と、ファイル内容の廃棄および置き換えの動作である。いずれの場合も、少なくとも部分的に、動作を、例えばファイル名の変更に変換することにより、解放された記憶領域の保存が行われる。記憶領域は、単に保存されるのではなく記憶領域のブロックとして保存され、OSにおける通常の自由(利用可能)なディスク記憶領域トラッキングによりマッピングされ続けるため、再使用されることはない。
【0052】
任意ファイルの中間の修正(上書き)など、ファイル名の変更技術(またはそれに同等な技術)で処理されない動作が多く存在する。さらに、OSの内部データの修正も存在する。ATF方法は、もとの状態の追跡を目的として、特定の割り当て解除動作上につきOSと協調するが、カバーされないその他全ての動作に対しては、Temp方法を使用して処理を行う。本発明は、スワッピングを低減する方法の詳細を詳述し、記憶領域の少なくとも最終的なディスク位置を一般的に割り当てる際のOSの役割を保存し、隔離(例えばファイアウォール)により全体的な復元能力を保護する。
【0053】
ATF方法では、OSが記憶領域のブロックを解放すると、同ブロックは自由プールに返される代わりに、ほとんど未使用な部類に分類されてラベル付けされ、エンジンが同ブロックの解放に関する通知を受ける。実際のこの処理は、標準OSをファイル名の変更に拡張することによって、ファイルの記憶領域が解放される直前に達成され得る。エンジンは、このほとんど未使用な記憶領域に関連付けられたディスクの割り当てを通知されるため、エンジンは、その記憶領域をどんなさらなる警告(alerting)からも保護することができる。この保護は、ほとんど未使用な記憶領域がOSによって修正されうる形態を採るが、エンジンは、ほとんど未使用な記憶領域のもとの状態を追跡する手段を採る。つまり、Temp方法が実装されているのに関わらず、エンジンも、ほとんど未使用な記憶領域の位置を(その位置がOSによってどのようにラベル付けされているか、ということと共に)通知される。
【0054】
好都合なことに、OSのビューにおいて、ほとんど未使用な記憶領域は除かれているので、上述の動作によって、OSは、一般にほとんど未使用な記憶領域を再使用しないこととなる。これは、OSがほとんど未使用な記憶領域に上書きしない限り、Temp方法が宛先を変更して、その後、新しい状態と以前の状態とをスワップする必要はないことを意味する。
【0055】
ほとんど未使用な記憶領域は、エンジン内の一般的な履歴データと共に経年処理を経て、真に未使用な記憶領域に移行する。これは、エンジンの制御のもとで行われるのが一般的である。この処理は、Always方法の一般的なアウトラインに従う。Always方法においては、記憶領域のブロックは、メインOSイメージの一部分である状態(MAINブロック)から履歴データである状態(EXTRブロック)を経て新しいデータを受信できる状態(CTMAブロック)に到達する。ATF方法においては、一般的なTemp方法機構に加えて、記憶領域のブロックは、ファイルに関連付けられた状態からほとんど未使用な記憶領域に関連付けられた状態(履歴データを保存している)を経て再び再使用が可能な状態(自由ディスクプール内にある)へと移行する。ATF方法における「ブロック」は、一般に、解放されたファイル全体を指す。Always方法がある程度の組み込みデフラグを含む一方で、ATF方法はデフラグをより外部の処理に格下げする(つまりATF方法は、OSまたはユーティリティがディスクの記憶領域の再整理を指示することを可能とする)。
【0056】
ATF方法のもとでの「ブロック」サイズに関して興味深い点は、ほとんど未使用な記憶領域のブロックをファイルと関連付けると、そのブロックのサイズが劇的に変動し得るという点である。つまり、ユーザが削除したのは巨大なファイルかもしれないし小さいファイルかもしれない。したがって、ほとんど未使用な記憶領域が真に未使用な記憶領域に移行するのに伴って、OSの自由プールに戻される記憶領域の量は、かなりの量かもしれない。初めは、履歴データを追跡する記憶領域をもっと徐々に移行させてOSの自由プールに戻し、本当に必要なときまで履歴データを解放しない方が良いように思える。
【0057】
しかしながら、複数のファイルであったものに複数のブロックが対応する場合、履歴ファイルの内容の半分を保持して、一方で、もう半分の再利用を許可することは、データ復元の観点から見て意味をなさない。したがって、古い履歴データのブロック全体が使用のために必要とされている限り、大きな記憶領域のブロックをOSの自由プールに返し、そのために古い履歴データを追跡するというこれらブロックの以前の役割を断念しても、何ら問題は生じない。履歴データの追跡に使用される記憶領域が複数の安全点(safe point)に対応する複数のブロック単位で解放され得るAlways方法に関しても、同様な一般的観測がなされる。これは、所定の安全ポイントに対応する履歴データの部分集合が、どの回復目的にも使用できないと考えられるためである。
【0058】
ATF方法の詳細は2つの工程で表される。第1の工程は、New Temp方法によるもので、同方法からの進行を示すとともに一定事項を強調することを意図するものである。さらに、異なる実装を使用したATF方法が、第2の工程として表される。第2の工程は、第1の工程の設計における問題点を解決するものであり、しかし、前述した方法のデータ構造からのさらなるジャンプであると言える。
【0059】
New Temp方法では、エンジンは、OSによって一般にアクセス可能なメイン領域ページに加えて、比較的単純なデータ構造を有しエキストラページに対応した履歴ヘッダを保持している。ATF方法は、2つの追加のデータ構造を追加する。すなわち、ほとんど未使用なOS位置(AUOS/almost unused OS locations)にあるブロックの発生順の円形表と、どのメイン領域ページが真に未使用またはほとんど未使用である(TUUN/truly unused or almost unused)かを示すマップの2つである。AUOS表の各ブロックに対し、そのブロックをOS内で識別する方法が格納される(例えばファイル名)。また、そのブロックがいつ作成されたかを示す履歴ヘッダへのリンクも格納されており、それによって、そのブロックを履歴ヘッダの全時間追跡機構にリンクさせる。代表的なAUOS表エントリを表1に示した。
【0060】
【表1】
【0061】
OSが、ファイルに関連付けられた活動状態からほとんど未使用な状態へと記憶領域を移行させるのに伴って、AUOS表の一端にブロックが追加され、TUUNマップが、現在はほとんど未使用な状態にある新しいディスク位置を示すように更新される。OSが利用可能な空きスペースを充分な量だけ確保する必要があるため、ブロックは表の他端から取り出される。関連付けられた記憶領域がOSによる再使用に提供されて、TUUNマップが更新される(ほとんど未使用なディスク位置が真に未使用となる)。名前変更の動作を使用して履歴データを破棄した場合、OSは、削除動作を使用してその記憶領域を自身による再使用に供するのが通常である。ディスク位置が真に未使用であることを示すTUUN状態によって、エンジンが通常の転用処理およびスワップ処理を回避することが可能となる。
【0062】
TUUNマップは、ほとんど未使用な状態のディスク位置を追跡することにより、エンジンが、このような記憶領域に対するOS読み出し要求をキャッチして、実際の内容の代わりにゼロデータを返すことを可能とする。こうするには2つの理由がある。先ず第1に、ほとんど未使用な記憶領域は、履歴データを含むため一般的なセキュリティ問題を伴う。ユーザは、自分のディスクの以前の状態に容易にアクセスできることを望まないかもしれない。セキュリティは、前掲したようにこのようなアクセスをエンジンでインターセプトするか、またはOSセキュリティ機構を使用する(ファイルをアクセスからロックしたり、ファイルの属性ビットを設定したり等など)ことによって、実現することができる。しかしながら、エンジン全般の目的は、ユーザがそのディスクの以前の状態にアクセスできることを保証することであることに、注意が必要である。
【0063】
このセキュリティ問題は、それほど重要な関心事ではない。最も重要なのは、ディスクの以前の状態にアクセスできることを保証するという概念である。ユーザ(OS)が、あたかも通常のディスクイメージの一部であるかのように履歴データにアクセスできるようにすることには、履歴データがメインイメージの一部になるという問題点が伴う。このため、OS上で実行されるアプリケーションが、履歴データを利用することが可能となって、履歴データにより容易に依存するようになる。このような状態が生じ、データが通常の経年処理の一部として解放されると、ディスク全体を時間的に復帰させることが不可能となる。つまり、OSが履歴データを直接参照できると、時間を遡るというコンセプトが弱体化してしまう。
【0064】
エンジンが提供する機構は、履歴データをメインイメージから明確に区別するのが一般的である。つまり、ユーザは、メインドライブではなく仮想のドライブを介して以前の状態にアクセスし、特別なアプリケーションを介して上書きバージョンまたは削除バージョンのファイルにアクセスする(を引き出す)。したがって、履歴データとディスクの現行のメインイメージとが合理的に区別される。ここで、ほとんど未使用なデータを保持している名前変更されたファイルの使用によって、特別なアプリケーションを履歴データに直接アクセスできるようにすることが可能であることに、注意が必要である。このためには、エンジン(またはOS)と協調してデータの通常保護(例えばゼロ化)を無効とする必要がある。
【0065】
重要なのは、アプリケーションが、OSによって管理されユーザが利用可能な「通常」ファイルに単純にアクセスするのではなく、エンジン/OSの履歴追跡からファイル(データ)を「抽出する」ためには、特別なアプリケーションが必要であるということである。
【0066】
しかしながら、ほとんど未使用だとフラグされたディスク位置をOSで読み出す際に、エンジンがリターンデータを一般にゼロ化することには、最も重要な理由が存在する。この理由は、メインイメージと履歴データとを明確に区別することが何故重要なのかに関する前述の議論にある。履歴データとメインイメージとの混合が可能となると、そこに僅かな相互依存を生じるため、履歴データを実際に解放した際には、その相互依存が全て切断されることになる。ここで、履歴データの解放が永続的で不可逆性であることに、留意する必要がある。履歴データを追跡するのは、定義によってある程度の可逆性をユーザに提供するため、つまり、一定期間中に幾らかのデータを取り戻せるようにするためである。ユーザが不可逆性の動作により深く関わるようになると、エンジンの目的が部分的に弱まってしまう。
【0067】
以下に挙げる実施例は、メインイメージとの関連でOSによってなされる一般アクセスからゼロの履歴データを戻し、または履歴データを隠すことの、重要な理由の1つを示している。すなわち、大量のデータを永久に消去するダイアログにおいて、ユーザは意識的または無意識にOKをクリックする。まさにこの状況において、エンジンは、ある程度の可逆性を提供することを期待される。履歴追跡システムがOSのトップに実装されていると、履歴データを含んだファイルをOSが失う結果をもたらす動作またはバグは、致命的なものとなる。
【0068】
しかしながら、ATF方法は、それ自身OSの複雑性から隔離されているのが一般的である。ここで、大量のディスク記憶領域がほとんど未使用であることをエンジンに合図したプログラム(またはウィルス)に対し、ユーザがOKをクリックした場合を考える。ただし、この通信はOSに対してなされたのではないため、影響を受けた記憶領域は、依然としてOSによるアクセスが可能である。OSがデータにアクセスしてエンジンがそれをゼロ化しなかった場合は、ユーザから見ると、そのディスクの内容に問題はないように思える。しかしながら、少なくともエンジンから見ると、ユーザは、メインイメージの一部としての履歴データに知らずにアクセスしていることになる。後になって、エンジンがこの履歴データを解放して再使用すると、ディスクのメインイメージであったものが、突然且つ不可逆的に変化する。さらに、エンジンを使用して時間を遡っても、ユーザやOSが表示するメインイメージは再現されない。
【0069】
一方で、OSによる読み出しの際に履歴データを強制的にゼロ化すると、時間を遡る際に、メインイメージが整合性を保って完全に復元される。履歴データとメインイメージデータの相互依存は、合理的に回避される。このため、上述した筋書きでは、ユーザがOKをクリックし、データの多くがほとんど未使用(履歴)であることをフラグされると、そのデータが有効にゼロ化される。したがって、ユーザは、自身のアクションが引き起こす実際の結果を直ちに経験し、そのアクションをエンジンによって取り消すことができる。つまり、エンジンが提供する履歴経年処理によって失われたデータを検索するために、ユーザがメインディスクを介してデータの「損失」を実際に経験する、ということが非常に重要である。
【0070】
したがって、ほとんど未使用な記憶領域をエンジンに通知するOSのアクションが、OSが後に読み出そうとするデータをエンジンによって有効にゼロ化することを、必ず伴うことが推奨される。ここで、ほとんど未使用な記憶領域の履歴内容が、実際にはゼロに設定されないことに注意する必要がある。履歴データにアクセスする方法は、特別なアプリケーションを介して許容可能である。
【0071】
例えばアプリケーションは、エンジンおよびOSによって管理されるデータを利用して、ディスクの以前の状態を再構築したり特定のファイルを検索したりする。この筋書きは、ほとんど未使用なものとして記憶領域を保存するのに使用されているファイルの、ゼロ化されていない実際の内容に、特別なアプリケーションを介してアクセスすることを単純に許可することによって、特定のファイルを復旧することを含む。より厳密に言うと、特定ファイルの以前の状態にアクセスするこの方法は、OSで管理されているように、この状態を保持しているファイルの内容へのアクセスを許可することを含む。この方法は、ディスク全体を、望ましいファイルの検索元の仮想ドライブとして有効に再構築するアプローチと異なり、それを簡略化したものである。OSがほとんど未使用の記憶領域に突然上書きしてしまった、すなわちOSが自身の履歴追跡を破壊してしまったことをエンジンが検出した場合は、一般に、この簡略化された方法を採用するべきでない。しかしながら、エンジンは依然として、Temp方法を介して以前のディスク状態へのアクセスを提供することができる。
【0072】
ここで、OSが、ほとんど未使用な記憶領域を直ちにエンジンに通知することを望まなかったりできなかったりする可能性があることに、注意する必要がある。OSは、アプリケーションによって解放されると同時に記憶領域を収集して、関連付けられたディスク位置および他の情報とともに、後ほどエンジンに引き渡すことを選択しても良い。
【0073】
次に示した表2は、OSおよびエンジンによる関連処理の概略を示したものである。
【0074】
【表2】
【0075】
ATF方法の的確な特徴の1つは、ほとんどおよび真に未使用な記憶領域の追跡に関連してOSとエンジンとが非同期であっても、一般に何の悪影響も及ぼさないということである。次に示した表3および表4は、同期条件からの種々の出力およびその結果を示したものである。ここで、情報を「失う」という表現が、その情報が単にOSとエンジンの間で上手く転送されないことを暗示していることに、注意する必要がある。これには、その情報が、全く上手く転送されず、ディスクへの不完全な状態/データフラッシュの一部として失われた場合を含む。
【0076】
【表3】
【0077】
【表4】
【0078】
次に示した表5および表6は、記憶領域を分類することができる3つの状態、およびこれらが各状態から別の状態へとどのように移行するかを示したものである。
【0079】
【表5】
【0080】
【表6】
【0081】
TUUNマップは、メイン領域マップの一部として実装されることができる。換言すると、OSがディスクにアクセスするのに伴って指定位置をメイン領域マップに通すのは、保留中の宛先変更があるかを見るためだけでなく、ほとんどまたは真に未使用な記憶領域がアクセスされているかを見るためでもある。しかしながら、メイン領域マップが破損される可能性があり、そうすると再構築が必要となるため、TUUNマップの再構築もまた必要となる。ATFの設計では(第2の工程で)手短に宛名を変更できるため、当座はTUUNマップの再構築の問題を無視することにする。ただし、真に未使用な場合に真に未使用でないとするような、誤った位置分類の原因となる最新の情報損失は、無害であるのが一般的であり、転用が不要な場合に書き込みを転用させる結果をもたらす。
【0082】
許されないのは、ユーザ(OS)が、真に未使用な位置LLに何らかのデータDDを書き込めることである。すると、この位置が真に未使用な状態から移行するが、この移行はなんらかの故障が原因で破損される。LLの内容をDDに変更することが許可され、OSでこの新しい値を読み出すことができる一方で、エンジンが真に未使用であるとフラグされた位置を依然として有していると、望ましくない状況が生じる。問題は、ユーザがこの新しいデータDD(重要なファイルである)の存在に依存するようになるのに関わらず、後になってOSが再び位置LLへの書き込みを行うと、エンジンがその書き込みを直接通すために、データDDが上書きされて永久に失われることである。解決策の1つは、すでに議論したように、エンジンによって真に未使用であることをフラグされた位置全てに対してゼロデータを戻すように強制することである。したがって、この場合、真に未使用な状態が破損されるとデータDDもまた破損されるため、ユーザが、データが存在していて安全である(もし上書きされたならば追跡されている)と誤解することはない。
【0083】
エンジンが、真に未使用な状態からメイン領域の状態にランダムに破損されることは考えられないが、クラッシュ時に、一連の書き込みの末端が廃棄される可能性はある。つまり、真に未使用な位置のなかには新しいデータで上書きされるものもあるが、ディスク上のTUUNマップが更新されるまでは、コンピュータがクラッシュした際にエンジンが復元するのは、安定ではあるがTUUNマップの更新以前の状態である。したがって、新しいデータがディスクに書き込まれたものの、エンジンにその移行を記録する時間がなかったため、コンピュータは、あたかも新しいデータがディスク上に書き込まれなかったかのように復元される。
【0084】
ほとんどおよび真に未使用なビットが、幅広い範囲のディスク位置に跨って変動する(変化する)ことから、TUUNマップは、ビットマップとして実装されることが好ましい。コンピュータが納品された最初の時点では、ディスクの大部分が真に未使用な状態である。しかしながら、データがロードされて更新されるのに伴って、幅広い範囲に跨る多数のビットが変更される。したがって、マップはまばらであるとは考えにくい。ある状態から別の状態への安全な移行と、TUUNマップの耐障害性とを考慮すると、何らかの形の円形表を追加することが推奨される。真に未使用な位置が、上書きされてメイン領域の位置に移行すると、TUUNマップが更新されて、対応のエントリが新しい円形表に加えられる。この新しい円形表への追加は、AUOS表とともに、あらゆる更新の後に比較的高速でディスクへとフラッシュされる。一方のTUUNマップは、クラッシュ時に再構築できると想定されるため、システムのシャットダウン時にのみフラッシュされる。これによって、更新且つキャッシュされたTUUNマップページを数多く生じる頻繁なフラッシュが回避される。
【0085】
上述したように、現在のディスクドライブには、性能向上を目的とした書き込みキャッシュが含まれるのが通常である。これらの書き込みキャッシュは、書き込みを一時記憶領域に入れて、書き込みと異なる順序でデータをディスク媒体に引き渡す。この処理は、例えばディスクコントローラを、ディスクヘッドの動きを低減する順序で実際のデータ書き込みを行えるようにすることによって、書き込み処理全体を高速化することができる。しかしながら、TUUNマップや履歴ヘッダデータなどの内部のバックアップデータは、ディスク上にすでに存在すると想定されるデータ(依然として書き込みを待機中)より前に、ディスク上で更新され得る。電源異常が発生すると、ある安定な状態から別の状態への安全な移行が不可能となってしまう。
【0086】
エンジンに書き込みキャッシュのフラッシュ制御能力がないことを想定すると、キャッシュによって、クラッシュ時に難しい問題が提起される。例えば電源異常によって、書き込みキャッシュの一部が永遠にディスク上に書き込まれなくなるかもしれない。エンジンの問題点は、ディスクに書き込まれたデータと書き込まれなかったデータが存在する場合に、書き込みキャッシュ側の要因によって、エンジンがデータを書き込んだ順番とデータがディスクに到達した順番とが対応しないということにある。したがって、エンジンがディスク位置1,2,3への書き込みを行った後にクラッシュしたとすると、位置1,3は更新されたが位置2は更新されなかったという事態が生じ得る。
【0087】
部分的に失われてもなお完全に有用なデータ構造はほとんどないため、本発明では、ディスクに書き込まれるデータ保全性を確実にする手段として経年処理を使用する。書き込みキャッシュのアルゴリズムは、一般に、ディスクへのデータのコミットが無制限に先送りされる(hold off)ことはないことを想定している。これは、コンスタントな読み出しおよび書き込み活動を行う場合であっても同様であると想定される。そうでないと、書き込みに「最適な」時間を待機するデータが書き込みキャッシュ内に詰まり、朝書き込まれたデータが数時間後になってもディスク媒体に到達しない事態が考えられる。本発明は、ディスクコントローラにページを書き込むに当たり、一定の最小時間(待ち時間)の経過後にはそのページがディスク媒体に実際に書き込まれる(そして、クラッシュ時には不揮発性の記憶領域に保存される)ことを想定して構築されている。
【0088】
したがって、本発明は、過去の最小待ち時間内にデータがディスクコントローラに書き込まれた場合にのみデータの経年処理を使用し、回復(システム再始動)との関連でデータをトラステッドにする。ディスクコントローラに書き込まれたデータブロックには、何らかの形態の時刻スタンプまたは時刻点が含まれることができる。ここで、1つのブロックは複数のディスクページからなる。最小待ち時間後に書き込まれた続く時刻スタンプまたは時刻点が発見された場合、ブロックは、ディスク媒体に完全に転送されたと想定される。時刻スタンプは、ブロックの読み出しに直接対応する値である。2つの時刻スタンプを比較することにより、表された時間間隔の長さを決定することが可能となる。これに対して時刻点は、前の時刻点から待ち時間分が経過したことを単純に示すものである。
【0089】
ディスクコントローラにどれだけの量のデータが転送されたかを監視することにより、待ち時間を概算することができる。ディスクコントローラへの転送速度が周知であるため、この転送速度を待ち時間で掛けて、所定ページの書き込み後に転送されるべきデータの量を算出し、このページが確かにディスク媒体に書き込まれたことを保証することができる。これは、転送が連続して行われることを想定している。
【0090】
事前に書き込まれたデータが、適切な待ち時間の経過後にディスクに実際に到達するという仮定は、特定のディスクコントローラには当てはまらない。このような場合は、代替の方法が使用される。ここで、エンジンは、所定の書き込み以降、ディスクコントローラがその書き込みキャッシュをディスクにフラッシュするのに十分な「自由時間」があったことを保証するものである。エンジンは、ディスクコントローラへの平均転送回数をモニタすることができる。この平均転送回数は、既知または概算の最大転送速度(ディスク媒体で実際にデータの読み出しまたは書き込みを行える速度を反映している)と比較されて、書き込みキャッシュがフラッシュされていることが妥当か否かが決定される。フラッシュが必要である場合は、充分な量の自由時間が引き渡され、エンジンは単純に遅延(または、ディスク活動の突然の休止を回避するための一連の短い遅延)を挿入することができる。最悪の場合は、ドライブの転送速度を、非常に大きい(どんな適度なキャッシュサイズよりも遥かに大きい)データブロックの読み出しおよび書き込みを行うタイミング調整プログラムから推察することができる。ここで、転送の回数、相対的な接近性、およびサイズが全体の転送速度にそれぞれ個別に影響を及ぼすことから、ドライブの転送速度の計算でこれらの各要素を考慮するべきであることに、注意する必要がある。つまり、ディスクヘッドを物理的に動かすまでの各転送の開始に関連付けられた時間と、ディスク媒体に実際にデータを転送するのにかかる一定の時間とが存在する。
【0091】
ディスクコントローラのキャッシュをフラッシュする自由時間方法への類似点は、キャッシュをコップで水を加えるバケツに譬えられることである。バケツの底には穴が1つ空いており、一定速度での排水を可能としている。穴から流出する水は、ディスク媒体にデータを書き込むディスクコントローラと同等である。コップで水を加える処理は、ディスクコントローラにデータを書き込む動作と同等である。もしバケツが満杯であれば、待機する必要がある。ディスクコントローラからのデータの読み出しは、穴を一時的に塞ぐことと同等であり、何も排出されたり追加されたりしないまま、時間だけが経過する(読み出しキャッシュは書き込みキャッシュから独立していると仮定する)。ここで、書き込みキャッシュをフラッシュする状況は、バケツに加えられた一杯の水が排出されたかを刻々と保証する必要がある状況と非常に似通っているが、実際にバケツの中をのぞいたり、バケツがまだ排水しているかを検知したりすることはできない。さらに、水を1カップ分だけバケツに加えると、この水は、続けて加えられる水とも前に加えられた水とも混合する。
【0092】
問題の水が本当に排出されたかを知る唯一の方法は、水を加えた後のある時点において、バケツが一時的に完全に排水されるようにすることである。バケツの中身を見たり、まだ排水中かを知ったりすることができないため、これをいつどのように実施するかは難しいところである。つまり、キャッシュがフラッシュされたかをディスクコントローラに尋ねる現行の標準インターフェースは存在しない。解決策の1つとして、水がバケツから排出される最悪の場合の速度を決定することが挙げられる。これは、バケツが満杯になって待機を強制されるまで、可能な限り高速で水を加え続けるという試験を行うことによって達成される。この時点以降は、バケツに余裕ができる(次のカップを受け付る)たびに水を加え続け、その速度を測定すれば良い。この処理によって、バケツの「緩衝」効果を効果的に無効とすることができ、実際の排出速度(またはディスクコントローラがキャッシュを空にする速度)が測定される。
【0093】
バケツの排水速度がわかれば、水を加える速度をモニタすることができる。加えた水を確実に排出したい場合は、新しい水を加えるよりバケツの排水の方が速くなるように、次に水を加える速度を遅くする必要がある。算出可能なある時点では、ゆっくりであるにもせよ水を加え続けているのにも関わらず、バケツが完全に排水される。もちろん、さらに1カップ分の水を加える前にバケツを直ちに確実に排水させたい場合は、単にバケツの排水に必要な算出時間分だけ待機することができる。事実、バケツに水を加える速度を連続的にモニタすることにより、排出が必要な水を加えた時点でバケツがどのくらい満杯だったかを、ある程度把握することができる。これによって、遅延の低減が可能となる。もちろん、近似を行うこの環境では、遊びをたくさん設ける必要がある(例えば、完全に排水するのに1秒間必要だと考えるならば、2秒間待機して、計算で生じる僅かな誤差を全てカバーする)。
【0094】
このバケツへの譬えは、書き込みキャッシュをフラッシュする自由時間方法を表している。ここで、バケツが空になる速度は、書き込みキャッシュがフラッシュされる速度に等しくて、シーク時間および転送速度の関数であることに、注意する必要がある。したがって、書き込みキャッシュにおけるデータのディスク接近性(disk proximity)、すなわちディスク上で書き込まれるべき位置は、キャッシュのフラッシュに必要な時間に大きく影響する。つまり、ディスク媒体上の1領域にたくさんのデータを書き込むのに必要な時間は、媒体全体に渡って少しずつ書き込むのに比べて遥かに短くてすむ。しかしながら、最悪の場合のフラッシュ速度として計時および使用できるのは後者の場合であるので、一般的な実際の速度を認める方がずっと良い。ディスクコントローラによって最初にキャッシュから書き込まれるデータがどれかを推測することができないため、ディスクコントローラに書き込まれたページ位置をモニタして、シーク時間対転送時間の比を予測し、現行の予測フラッシュ速度を動的に生成することは不可能である。
【0095】
再びディスクコントローラの件に戻り、次に問題となるのは、書き込みキャッシュのフラッシュを確実にするにはいつ遅延を挿入するか、ということである。書き込みの転用を行う工程がある。ユーザは一般に、ディスクの活動が一時休止する時点(安全点)を選択してアクセスすることしかできない。こうして、変更処理中の過去の時点からデータにアクセスすることが回避される。したがって、一時休止が充分に長い限り、書き込みキャッシュのフラッシュは安全点の識別に固有である。クラッシュ後にコンピュータを再起動する際に、ユーザは、安全点である過去の時点に復帰したり、単にクラッシュ直前の状態でディスクを使用したりする選択肢を有する。後者の場合、エンジンは、ディスク活動が一時休止をしていない時点までデータ構造を回復させる。つまり、クラッシュが、一連の長いディスク活動の中間で生じた場合である。フラッシュ方法に基づいた待ち時間を使用すると、クラッシュ前の待ち時間までに書き込まれたデータが全て存在することになる。しかしながら、ディスクコントローラがトラステッドされず、待ち時間後実際にディスク媒体にデータを書き込むことができないと、エンジンは、ディスク活動中最後に記録されたフラッシュ時刻点より以前に書き込まれたデータを全て廃棄するしか方法がない。つまりエンジンは、充分な長さの自由時間が経過したことを決定し、データブロックが実際にディスク媒体に転送されたことを保証するとともに、適切な時刻マーカを書き出す。この時刻マーカがディスク媒体上に到達すると、ブロックの妥当性が確立される。クラッシュからの回復時には、媒体に書き込まれたが続く時刻マーカを有さないデータが、データの一部が失われているかもしれないとして廃棄される。ユーザは実際には、クラッシュ時に書き込み中だったまたはクラッシュ時にちょうど書き出されたところだったデータに興味を示さないのが一般的であるため、このデータの廃棄が問題になることはない。
【0096】
フラッシュが必要な別のエンジン活動は、ディスクの内容が再配置(スワップ)されている場合である。この処理は、特定の時点でディスクにフラッシュされて、耐クラッシュ性となる(クラッシュ発生時にデータを損失することなく再開できる)ことを前提とした、明確な転送工程を含む。データが大量に移動するために、多くの時点でフラッシュを行わなければならない可能性もある。したがって、この活動の最中は、特定の時点で遅延を生じることにより、ディスクへの書き込みがなされたことを確証する必要がある。
【0097】
適度に有効なスワップ工程の簡単な実施例では、50メガバイトのスワップ領域を使用する。平均1メガバイト毎秒の転送速度では、このデータを全て書き込むのに50秒間かかる。ディスクコントローラが1メガバイトの書き込みキャッシュを有する場合は、そのキャッシュをディスクにフラッシュするのに1秒間の自由時間が必要である。したがって、50メガバイトのスワップ領域を書き込んだ後のある時点で、ディスクコントローラに対するディスク転送の(累積)遅延を1秒間挿入し、1メガバイトのキャッシュが(1メガバイト毎秒で)確実にフラッシュされるようにする。スワップ領域の書き込み50秒間に対して1秒間の遅延は妥当な比率である(2%の性能ヒット率[performance hit])。
【0098】
ここで、この比率を妥当なものとする重要な要素の1つは、ディスクへのフラッシュとして知られる時点と時点の間に書き込まれるデータの量が大きくて良いこと(前の実施例では50メガバイトを使用した)である点に、注意する必要がある。これに反し、フラッシュが必要とされるまでに1メガバイトしか書き込まれなかった場合は、データ転送にかかった時間と挿入された遅延との比が望ましい値でなくなる(1秒間の書き込み後に1秒間の遅延が続く、すなわち50%の性能ヒット率)。(有効な)フラッシュ間に書き込まれる領域が大きい必要があることから、上述したようにエンジンは、所定のディスク位置が修正を必要とせず、その後にフラッシュとフラッシュ間で大領域を書き込むより速い速度で行われる修正とが続くように、設計される。
【0099】
スワッピングは一般に、バックグラウンドで行われ、ユーザが要求したディスク活動による割り込みが可能である。スワッピング処理において、自由時間に基づいたフラッシュが必要とされ且つユーザがディスク活動の切り離し(バースト)を開始する場合は、ユーザ活動の完了後に必要な遅延が単純に挿入される。
【0100】
書き込みキャッシュのフラッシュは、ほかに、履歴バッファが高速で上書きされている場合と、逸脱処理が中断されている場合と、システムがシャットダウンしている場合とに必要である。これらの事態は、いずれも頻繁に生じるものではないため、ある程度の遅延を加えても一向に構わない。
【0101】
データブロックがいつ有効であるかをディスク上で示す方法の1つは、充分な長さの待ち時間またはディスク活動の自由時間が経過した後に、スタンプや時刻点などの結びフラグ(concluding flag)を書き出すことである。
【0102】
図1は、システムの代表的な初期状態を示したものである。「メイン領域ページ」と題された第1の列は、メイン領域の内容を示している。位置#1〜#5はデータを含み、位置#6〜#9はOSによる割り当てを受けていない。エンジンは、OSがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ/TUUN」と題された次の列は、TUUNマップと、OS指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のOS位置が真に未使用であることを示す。「エキストラページ/履歴ヘッダ」と題された第3の列は、エキストラページ領域の内容と、その関連の履歴ヘッダとを示している。列の頂上部に示された矢印は、次の書き込み位置を示す。「AUOS」と題された最後の列は、ほとんど未使用なOS記憶領域の追跡をエンジンに依頼するためにOSから発信された、エントリを表している。履歴ヘッダおよびAUOS表は、最初は何の情報もトラックしていない。
【0103】
図2では、OSが位置#1への書き込みを行うため、値「DI1」が値「DI2」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、履歴ヘッダ内にメモを作成する。いくらかの自由時間を与えられた後、最終的には、転用後の新しいデータともとの履歴データとが交換(スワップ)される。位置#1からのOS読み出し要求を指定のエキストラページへと転用するメインマップには、エントリが1つ追加される。
【0104】
図3では、OSが、「FA1」を含んだ位置#2を解放する。これは例えば、もとの内容が位置#2にあったファイルの内容を、ユーザが置き換えることによって生じ得る。OSは、OSの汎用割り当てプールに位置#2を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、TUUNマップを更新し、AUOS表にエントリを1つ追加する。ファイルの新しい内容が書き込まれると、その新しいデータ「FA1B」は、次に利用可能なOS位置#6に配置される。エンジンとOSとが、この位置が真に未使用であることに同意しているため、データは(エキストラページに転用される代わりに)直接その場所に書き込まれる。図2で生じた書き込みと異なり、図3での書き込みは保留スワップを必要としない。
【0105】
図4は、4つのアクションの結果を示している。先ず第1に、位置#3が、OSによって新しいデータ「FB1B」で上書きされる。第2に、データ「FC1」および「FC2」を含んだ位置#4および#5が、OSによってほとんど未使用な状態に移行する。第3に、位置#1が、OSによって新しいデータ「DI3」で上書きされる。位置#3および#1を上書きした第1および第3のアクションでは、各書き込みがエンジンによって転用される。位置#4および#5がほとんど未使用な状態に移行する際には、エンジンによってTUUNマップおよびAUOS表が更新される。これら2つの位置の解放は、例えばユーザがファイルを削除することによって生じ得る。続く第4のアクションでは、OSが、位置#7および#8に新しいデータ「FD1」および「FD2」を書き込む。この上書きは、ユーザが新しいファイルを作成してそのファイルに「FD1」および「FD2」を書き込むことによって生じ得る。OSは、続く2つの真に未使用な位置を選択し、新しいデータ(#7および#8)を受信する。TUUNマップは更新されて、位置#7および#8はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。
【0106】
この実施例の次の工程は、OSが、割り当て可能な(真に未使用な)記憶領域において低いことを認識していることを前提とする。OSはエンジンに対し、ほとんど未使用であるとしてOSが以前に保留した記憶領域の位置(またはOSラベル)を、信号で返すことを要求する。図4において、システム内で最も古い履歴データは、図2で生じた第1の転用である。しかしながら、この履歴データを保持するのに使用される記憶領域(保留スワップが実行されたと想定する)は、アクセス可能なOS領域より外側のエキストラページ領域にある。次に古い履歴データは、図3で作成されたAUOSメモである。この記憶領域は、OSによって戻されて使用されることができる。しかしながら、ギャップを超える(時間を遡る)データが、ギャップ内にあったデータに依存したかもしれず、一般に使用不能であるため、履歴ログ内にギャップを設ける理由はないのが一般的である。
【0107】
したがって、2つの選択肢が可能である。1つ目としては、エンジンは、OSに戻すことができるAUOS記憶領域を獲得するまでは、エキストラページ領域内の履歴データを廃棄または「トリム」することができる。2つ目としては、エンジンは、AUOS記憶領域を早めに戻すが、このような記憶領域のOSによる再使用を保存が必要な上書きデータとして扱うことによって、転用を行うことができる。
【0108】
図5は、第1の選択肢すなわちトリミングを示している。ここでは、データ「DI1」の履歴追跡が廃棄(トリム)される。この廃棄は、「DI2」をエキストラページ領域からメイン領域の位置#1へと強制的にスワップさせることを含み、位置#2は、エントリがAUOS表から取り除かれるのに伴って、真に未使用な状態へと移行する。OSが位置#2を割り当てて、この位置にデータを書き込む際には、エンジン(およびOS)によって廃棄された古い履歴データを上書きし、直接データを書き込むことができる。
【0109】
図6は、第2の選択肢すなわち転用を示している。ここでは、エントリがAUOS表から取り除かれ、それに伴ってOSが通知を受ける。しかしながら、影響を受ける位置に関しては、TUUNマップが「早期」状態に更新される。これは、この位置には、ディスクの過去の状態を再構築する目的で、エンジンが必要とする履歴データが含まれるため、OSがこの位置を上書きしようと試みると、履歴データを保存するために変更が転用されることを意味する。ある位置をフラグで「早期」と示す必要があるということは、OSがこの位置を読み出そうと試みると、ゼロ化されたデータが戻されることを意味する。これによって、OSによる履歴データへのアクセスが回避される。ここで、この「早期」状態が、ほとんど未使用な記憶領域を早めに解放することを含む上記解決策の一部として導入されたことに、注意する必要がある。
【0110】
上述した「トリム」および「方向変換」の方法が利用されるのは、履歴が発生順のイベント列であるためである。これに固有なのは、ある履歴ログの異なる部分を記録した2つの「ブック」が、これらのブックの組み合わせによって完全な履歴を知り得る限り、完全な履歴を表すことができるという事実である。しかしながら、この実施例が示しているように、完全な履歴は、必要な全ソースからの全情報が利用可能である時点までしか遡ることができない。ATF方法の場合は、履歴ログのうち、一部がエキストラページ/履歴ヘッダシステムで追跡されて、別の部分がOSおよびAUOSシステムで追跡される。これら2つのシステムは、OSがデータの上書きおよび/または解放ならびに割り当てを行う相対頻度に応じ、それぞれ異なる速度でデータの経年処理を行う。相対速度は、動的で任意の使用パターンに依存しており、保証がないのが一般的である。例えば、OSによって生じているのがほとんど上書きである場合、エキストラページ/履歴ヘッダシステムは、大部分の履歴データの追跡を、OSの制御下にある使用され得る記憶領域を一度も利用せずに行う。
【0111】
利用可能(真に未使用)なディスクスペースをフル活用するためには、1つの「ログ」を使用することが好ましい。TempおよびAlways方法におけるエンジンは、履歴の追跡に利用可能なディスクスペースの管理を、比較的完全に制御していた。これに対してFile方法では、履歴追跡処理をOSに組み込むことを想定していた。このため、OSは1つの履歴ログを効果的に維持していた。
【0112】
1実施形態において、ATF方法は、記憶領域の大部分がOSから動的に取り出されてOSに動的に戻されるように、変更される。すると、図5に至る場面は、「DI1」を保持した(スワップが実行されたと仮定する)「エキストラページ領域」内の記憶領域の一部分を、エンジンが解放してOSに戻すことを含む。
【0113】
好ましい1実施形態において、ATF方法は、組み合わされることにより必要な完全ログを形成する、2つの履歴ログを利用する。したがって、ATF方法は、OS制御下の利用可能な「自由」スペースの一部分を利用するとともに、自身のエキストラページ領域を有することにより、OSからの適度な独立性を維持する。ATF方法は、自身による制御下に専用の記憶領域のブロック(履歴バッファ)を有することにより、簡潔性(およびOSからの相対的独立性)を達成する。ATF方法は、記憶領域の割り当ておよび割り当て解除、ならびに履歴データの保守においてOSと協調することにより、性能の向上を達成する。
【0114】
実際は、履歴追跡のほとんどが、(履歴バッファよりも)エンジンおよびOSによる協調ハンドオフ処理を経るようである。しかしながら、何かの手違いが生じ、その変更の大部分が方向変換を必要とする上書きであった場合に、回復可能性を提供できるように、履歴バッファは充分に大きい必要がある。ディスクスペースが比較的高価であることを考慮すると、履歴追跡に割り当てられた記憶領域の半分が履歴バッファに割り振られ、もう半分が動的に取り出されてOSの割り当て可能スペースに戻されるように、ATF方法を実装することが推奨される。履歴追跡の大部分がエンジン/OSハンドオフ処理を経てなされることが判明すると、履歴バッファの使用が相対的に制限されるため、ATF方法による過去への到達がいっそう可能となる。
【0115】
トリムまたは転用の選択肢に再び戻り、決定は、どれだけ時間的に遡ることが維持するのに妥当であるかを考慮してなされることが好ましい。履歴バッファの履歴データが非常に古いと予測される場合は、その履歴データを廃棄することができる。しかしながら、その履歴データが適度に新しく、履歴バッファに充分なスペースがある場合は、OSに早めに記憶領域を戻し、書き込みを転用して、OSによる再使用を処理することが最適となる。この際スワップ時間が追加されるが、回復可能性は保持される。ユーザによるPCの使用頻度が(履歴追跡に割り当てられた記憶領域の量に比して)低いことが判明した場合は、どんなイベントに対しても、一般に、より多くの履歴データが必要とされる、すなわち時間的により古く遡ることが必要とされる。
【0116】
再び図6に戻り、転用を行う決定がなされた。図7において、OSは位置#2を新しいデータ「FE1」で上書きする。この上書きは、位置#2が履歴データを含むため転用される。位置#7および#8もまた、OSによって新しいデータ「FD1B」および「FD2B」で上書きされる。そして最終的には、OSが、真に未使用な記憶領域の位置#9に新しいデータ「FF1」を書き込むため、エンジンは、そのデータを場所に直接書き込む。図8では、転用された全データをスワップする時間がエンジンにあったため、履歴バッファは履歴データのみを含み、「生の」データは場所に入る。したがって、これ以上のマッピングは不要である。
【0117】
図9は、データが移動し、少なくとも概念的にこの実施例の開始時(図1)に回復した場合の結果を示したものである。ここで、ある所定の位置がOSによって2度以上上書きされた場合は、その位置こそが復元された最も古い履歴データであるということに、注意する必要がある。AUOSエントリを「復元させた」ことによる効果は、ほとんど未使用な状態を取り除くことであり、これは、影響位置がこれ以上強制的にゼロ化されるべきでないことを意味する。この復帰がAUOSエントリに跨らなかった場合は、復帰されたイメージにおいて影響位置がゼロ化される。
【0118】
図10は図1の初期状態を示し、図11は、データを全て場所に入れた場合の結果を示している。ここで、もとから真に未使用な位置であった場所には残留物が残されることに注意する必要がある。この残留物は、ほとんど未使用な記憶領域から真に未使用な記憶領域への移行を表すエントリが、履歴ログに含まれないことが原因で生じる。このため、他の種々の概念的要素が検討された。次に、残留物をアドレッシングするATF設計の第2の工程を説明する。
【0119】
ATFの第2の工程
第2のATF設計では、履歴ヘッダをAUOS表と組み合わせ、真に未使用な移行のロギングを追加する。この組み合わせを達成するために、新しい履歴ヘッダと関連の円形表が作成された。これらの新しい履歴ヘッダは、履歴ヘッダエントリと異なり、エキストラページに直接関連付けられてはいない。したがって、方向変換タイプのエントリが追加されると、割り当てられたエキストラページが好ましく割り当てられて、リンケージが設定される。いずれも利用可能でない場合は、エキストラページが解放されるまで、新しい履歴ヘッダ表の他端からエントリを取り除くことができる。ここで、この処理が、AUOS記憶領域の解放という結果をもたらし得ることに、注意する必要がある。
【0120】
次に示す表7は、新しい履歴ヘッダおよびその関連の属性の、3つの形態をまとめたものである。
【0121】
【表7】
【0122】
第2のATF設計が、履歴ヘッダとAUOSデータとを組み合わせた表を使用していることから、図12には、第1のATF設計の実施例における初期状態を示した。「メイン領域ページ」と題された第1の列は、メイン領域の内容を示している。位置#1〜#5はデータを含み、位置#6〜#9はOSによる割り当てを受けていない。エンジンは、OSがこれらの非割り当て位置を読み出した際にゼロ化データを戻す。「マップ/TUUN」と題された次の列は、TUUNマップと、OS指定のディスク位置を実際の物理位置に変換するメインマップとの、複合状態を示している。空のボックスは、マッピングが不要であることを示す。「真」という状態は、関連のOS位置が真に未使用であることを示す。「新しい履歴ヘッダ」と題された第3の列は、履歴ヘッダの内容を示しており、この履歴ヘッダは、「エキストラページ」と題された最後の列に示されるエキストラページ領域に関連付けられている。新しい履歴ヘッダ表は、エキストラページ領域から独立しており、さらに、ほとんど未使用なOS記憶領域の追跡をエンジンに依頼するためにOSから発信された、AUOSデータをも含む。図12に示されるように、新しい履歴ヘッダは、最初は何の情報もトラックしていない。
【0123】
図13では、OSが位置#1への書き込みを行うため、値「DI1」が値「DI2」で上書きされる。エンジンは、この書き込みをエキストラページへと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換(スワップ)する。スワップが生じた後、新しい履歴ヘッダ表は、転用が生じて新しいデータ「DI2」が位置#1に配置されたことを示す、1つのエントリを含む。また、このエントリは、エキストラページ領域内で古いデータ「DI1」が含まれる位置も示している。
【0124】
図14では、OSが、「FA1」を含んだ位置#2を解放する。これは例えば、もとの内容が位置#2にあったファイルの内容を、ユーザが置き換えることによって生じ得る。OSは、OSの汎用割り当てプールに位置#2を戻す代わりに、その記憶領域を保留し、その旨をエンジンに通知する。するとエンジンは、TUUNマップを更新し、位置#2が今では履歴データを含んでいることを示すエントリを、新しい履歴ヘッダに1つ追加する。
【0125】
図15に示されるように、ファイルの新しい内容が書き込まれると、その新しいデータ「FA1B」は、次に利用可能なOS位置#6に配置される。エンジンとOSとが、この位置が真に未使用であることに同意しているため、データは(エキストラページへと転用される代わりに)直接その場所に書き込まれる。図2で生じた書き込みと異なり、図3での書き込みはスワッピングを必要としない。また、位置#6において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に1つ作成される。
【0126】
図16は、2つのアクションの結果を示している。先ず第1に、位置#1が、OSによって新しいデータ「DI3」で上書きされる。第2に、位置#3が、OSによって新しいデータ「FB1B」で上書きされる。位置#1が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第2の位置へと新しいデータ「DI3」を転用させ、次いで、余分な時間がある時に、前の履歴データ「DI2」を新しいデータ「DI3」とスワップする。同様に、位置#3が上書きされるに際には、エンジンは先ず、次に利用可能なエキストラページ、すなわちこの場合はエキストラページ領域の第3の位置へと新しいデータ「FB1B」を転用させ、次いで、余分な時間がある時に、前の履歴データ「FB1」を新しいデータ「FB1B」とスワップする。図16は、データのスワップが生じた結果の構成を示している。
【0127】
図17は、データ「FC1」および「FC2」を含んだ位置#4および#5が、例えばユーザがファイルを削除したために、OSによってほとんど未使用な状態に移行する状況を示している。位置#4および#5がほとんど未使用な状態に移行すると、エンジンは、TUUNマップおよび新しい履歴ヘッダ表を更新する。
【0128】
図18は、OSが、位置#7および#8に新しいデータ「FD1」および「FD2」を書き込む状況を示している。この上書きは、ユーザが新しいファイルを作成し、そのファイルに「FD1」および「FD2」を書き込むことによって生じ得る。OSは、続く2つの真に未使用な位置を選択し、新しいデータ(#7および#8)を受信する。TUUNマップは更新されて、位置#7および#8はもう真に未使用だとは示されず、空のボックスは、マッピングが不要な状態を表している。また、位置#7および#8において、履歴データを何ら保存することなく直接の書き込みが生じたことを示すエントリが、新しい履歴ヘッダ表に1つ作成される。
【0129】
図19は、位置#2がOSの要求によって戻された状況を示している。TUUNマップ内の関連の位置が「早期」状態に更新される。これは、ディスクの前の状態を再構築するためにエンジンが必要とする履歴データが、この位置に含まれることを示している。このため、OSが位置#2を上書きしようと試みると、履歴データ「FA1」を保存するために変更が転用される。上述したように、「早期」であるとフラグされた位置をOSが読み出そうと試みると、ゼロ化されたデータが戻される。これによって、OSによる履歴データへのアクセスが回避される。
【0130】
図20は、OSが位置#2を新しいデータ「FE1」で上書きする状況を示している。位置#2が履歴データ「FA1」を含むため、この上書きは、先ずエキストラページ領域へと転用される。次いで、時間がある時に、履歴データ「FA1」を新しいデータ「FE1」でスワップする。図20は、スワップが生じた後の結果構成を示している。上述した転用後の書き込みのように、新しい履歴ヘッダ表は更新されて、転用が生じたことを示す。この新しい表では、位置#2に新しいデータが配置されて、関連の履歴データを含んだエキストラページへのリンクが含まれる。
【0131】
図21では、位置#7および#8が、OSによって新しい値「FD1B」および値「FD2B」で上書きされる。エンジンは、この書き込みをエキストラページ領域へと転用し、新しい履歴ヘッダ内にメモを作成する。そして、自由時間が生じたら、転用後の新しいデータともとの履歴データとを交換(スワップ)する。
【0132】
図22では、OSが、位置#9における真に未使用な記憶領域に新しいデータ「FF1」を書き込むことから、エンジンは、そのデータを場所に直接書き込む。図22は、前の実施例の全工程が適用された(そしてスワッピングが実行された)後の、最終状態を示している。
【0133】
図23〜33は、新しい履歴ヘッダを段階的に「ポッピング」すなわち取り消して、カレントイメージを初期状態に復帰させる状況を示している。特に図23は、図22との関連で説明した最後の動作に復帰した結果を示したものである。エンジンは、新しい履歴ヘッダ表内の最新のエントリ、すなわり「真に#9書き込み」を検討する(examine)。よってエンジンは、位置#9に関連した位置のTUUNマップを、真に未使用であると記録する。さらに、OSが位置#9にアクセスすると、ゼロ化情報が戻されるようになる。ここで、エンジンがOSによって位置#9にアクセスされてゼロ化データを戻す限り、位置#9の実際の内容を消去する必要はないことに、注意する必要がある。
【0134】
図24では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい#7/8、古い」を検討する。このエントリは、転用が実行されて、位置#7および#8に新しいデータが格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置#7および#8に、古いデータ「FD1」および「FD2」が書き込まれる。
【0135】
図25では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい#2、古い」を検討する。エンジンは、図24との関連で説明したのと同様な方法によって、位置#2に古いデータ「FA1」を書き込む。
【0136】
図26は、新しい履歴ヘッダ表内の次のエントリ、すなわち「AUOS(早期)#2」にエンジンが立ち戻った結果を示しており、これは、OSが位置#2を取り戻す要求をしたことを意味する。よって、TUUNマップを変更し、関連の「早期」エントリを「ほとんど」エントリで置き換えることにより、位置#2を、OSからの要求以以前の状態に復帰させる。
【0137】
エンジンは次に、図27に示された新しい履歴ヘッダ表内の次のエントリ、すなわち「真に#7、#8書き込み」を検討する。よって、エンジンは、位置#7および#8に関連した位置のTUUNマップを、真に未使用であると記録する。さらに、OSが位置#7および#8にアクセスすると、ゼロ化情報が戻されるようになる。
【0138】
図28では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「AUOS(追加)#4、#5」は、OSが位置#4および#5を解放したことを示す。よってエンジンは、TUUNマップを変更し、これらの位置に関連した「ほとんど」エントリを取り除くことにより、OSによる位置#4および#5の解放以以前の状態に復帰する。
【0139】
図29では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい#3、古い」を検討する。このエントリは、転用が実行されて、新しいデータが位置#3に格納されたことを示している。また、このエントリは、エキストラページ領域内に配置された古いデータへのリンクも含んでいる。したがって、位置#3に、古いデータ「FB1」が書き込まれる。
【0140】
図30では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい#1、古い」を検討する。エンジンは、図29との関連で説明したのと同様な方法によって、位置#1に古いデータ「DI2」を書き込む。
【0141】
図31は、次に最新の動作に復帰した結果を示している。エンジンは、新しい履歴ヘッダ表内の次のエントリ、すなわち「真に #6 書き込み」を検討する。よってエンジンは、位置#6に関連した位置のTUUNマップを、真に未使用であると記録する。さらに、OSが位置#6にアクセスすると、ゼロ化情報が戻されるようになる。
【0142】
図32では、新しい履歴ヘッダ表の次のエントリが検討される。エントリ「AUOS (追加) #2」は、OSが位置#2を解放したことを示す。よってエンジンは、TUUNマップを変更し、位置#2に関連した「ほとんど」エントリを取り除くことにより、OSによる位置#2の解放以以前の状態に復帰する。
【0143】
図33では、エンジンが、新しい履歴ヘッダ表内の次に最新のエントリ、すなわち「転用、新しい#1、古い」を検討する。エンジンは、図30との関連で説明したのと同様な方法によって、位置#1に古いデータ「DI1」を書き込む。図11と異なり、図33での最終結果は初期状態に一致する。したがって、この設計では、過去の様々な時点におけるOS可視ディスクの再現を支援する必要情報を取り込むことができる。
【0144】
1実施形態では、新しいデータを追加するのと同様な方法で履歴エントリを追加することにより、ディスクを前の状態に復帰させることができる。この実施形態におけるエンジンは、上述した方法で履歴データを獲得する。しかしながら、これらのデータのディスクへの書き込みは、まるで新しいデータであるかのようにエンジンを使用して行われる。この方法では、履歴データの書き込みを再びエキストラページ領域へと転用した後、適切な安全点において、前の「現在の」データとスワップされる。この方法では、ディスクが上述した前の状態に復帰した後、ディスクの「現在の」状態が「履歴状態」となる。
【0145】
したがって、クラッシュ発生時には、システムの最新スナップショットと組み合わされた新しい履歴ヘッダ表から、現在のTUUNマップを再構築することができる。スナップショットは、新しい履歴ヘッダ表内のどこかの時点に対応する。スナップショットは、表からのスナップショット基準点におけるエントリまたは同基準点を超えたエントリを使用して実行されて、その現在の状態を再構築する。
【0146】
ATF方法は、ファイルシステムの知識をある程度有しており、特定の履歴情報が、OSによる高速なデータアクセスが可能な方法で維持される(すなわち、ファイルの古いヴァージョンが単に、名前を変更された一時ファイル内によけられる)。したがって、例えば、ほとんど未使用な記憶領域から非常に高速で特定のファイルを検索することができる。しかしながら、一般には、ほとんど未使用な記憶領域に直接アクセスするか、または部分的に同記憶領域に基づいて仮想ドライブを作成することにより、充分に高速な検索を提供することができる。
【0147】
ATF方法には、File方法コンポーネントから取り入れられた大きな利点がある。これは、ファイルの内容を完全に置き換える等の、少なくとも特定タイプの動作に対して有効である。OSは、記憶領域を保留することによって初期状態を保存するため、ユーザが同じファイルを素早く何度も上書きする場合、OSは各ヴァージョンを全て保存する。これは、上書きヴァージョンがRAM内にのみ存在し、ディスクに実際に書き込まれることはない場合(あまりに素早く置き換えられるため)ですら生じ得る。安全点をファイル(およびその他の)活動に関連付ける汎用システムの活動記録ログは、置き換えられたファイル内容(データ)がどこに保留されたかに関するメモ(例えばOSラベル)を記録して、この情報を検索に使用することができる。これは、OSが、単一の安全点内ではAUOS記憶領域を再利用しないことを想定している。
【0148】
ATFおよびAlways方法が、ソフトウェアに実装され破壊の可能性に曝されている場合は、ATF方法を「放棄(walk off)」し、有用なディスクイメージを何らかの形態で得ることが合理的に可能である。方法を放棄するという概念は、そのアルゴリズムを、最低限のディスク変更によって使用不可とすることである。ATF方法は、一般に、OS可視データを直接OS内において割り当て位置として保持するため、そのアルゴリズムを突然使用不可とすると、直接OSが利用可能な状態に近い何らかのディスクが生じる。これに対し、Always方法の永久的な再マッピングは、同方法がディスクから引き出された場合(すなわち、データにアクセスするためにマッピングを知る必要がある)に、ディスクが使用に適さない(スクランブルされている)ことを、かなりの程度で保証する。どちらかの方法がファイアウォールより後ろで作動している場合は、ディスクからの方法の放棄は適用されない。
【0149】
AlwaysおよびATF方法はいずれも、非標準のディスクデフラグソフトウェアと共に使用することができる。ATF方法がディスクを自然な編成に維持する傾向にあることから、既存のデフラグプログラムを適用し、単純にエンジンのインターフェースを通して再配置する方が、容易に思える。これに対してユーザは、1つのデフラグユーティリティのみを必要とするのが一般的であり、このようなユーティリティは、ほぼ同様な試みを行ういずれの方法のもとでも提供することができる。
【0150】
以上では、理解を明確にする目的で本発明を詳しく説明したが、添付した特許請求の範囲を逸脱しない範囲内ならば、特定の変更および修正を加えられることは明らかである。したがって、本明細書で取り上げた実施形態は、例示を目的としたものであって、本発明の内容を限定するものではない。このため本発明は、本明細書で特定した詳細に限定されることなく、添付した特許請求の範囲の範囲および同等物の範囲内で、種々の変更を加えることが可能である。
【図面の簡単な説明】
【図1】代表的なシステムの初期状態を、本発明の1実施形態に従って示したブロック図である。
【図2】代表的なシステムにおいて、オペレーティングシステム(OS)が位置#1に書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図3】代表的なシステムにおいて、OSが位置#2を解放し、位置#6に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図4】代表的なシステムにおいて、OSが位置#1および#3に書き込み、位置#4および#5を解放し、位置#7および#8に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図5】代表的なシステムにおいて、ディスク位置を再生させるためにトリミングが実行された様子を、本発明の1実施形態に従って示したブロック図である。
【図6】代表的なシステムにおいて、OSが位置#2を再生した様子を、本発明の1実施形態に従って示したブロック図である。
【図7】代表的なシステムにおいて、OSが位置#2、#7、および#8を上書きし、位置#9に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図8】代表的なシステムにおいて、転用後の全データをスワップする時間がエンジンにあった場合の様子を、本発明の1実施形態に従って示したブロック図である。
【図9】コンピュータディスクの再構成を、本発明の1実施形態に従って示したブロック図である。
【図10】図1から得られる初期状態を、本発明の1実施形態に従って示したブロック図である。
【図11】コンピュータディスクを再構成した結果を、本発明の1実施形態に従って示したブロック図である。
【図12】代表的なシステムの初期状態を、本発明の1実施形態に従って示したブロック図である。
【図13】代表的なシステムにおいて、オペレーティングシステム(OS)が位置#1に書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図14】代表的なシステムにおいて、OSが位置#2を解放する様子を、本発明の1実施形態に従って示したブロック図である。
【図15】代表的なシステムにおいて、OSが位置#6に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図16】代表的なシステムにおいて、OSが位置#1および#3に書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図17】代表的なシステムにおいて、OSが位置#4および#5を解放する様子を、本発明の1実施形態に従って示したブロック図である。
【図18】代表的なシステムにおいて、OSが位置#7および#8に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図19】代表的なシステムにおいて、OSが位置#2を再生した様子を、本発明の1実施形態に従って示したブロック図である。
【図20】代表的なシステムにおいて、OSが位置#2を上書きする様子を、本発明の1実施形態に従って示したブロック図である。
【図21】代表的なシステムにおいて、OSが位置#7および#8に書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図22】代表的なシステムにおいて、OSが位置#9に直接書き込む様子を、本発明の1実施形態に従って示したブロック図である。
【図23】代表的なシステムにおいて、エンジンが、OSが位置#9に直接書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図24】代表的なシステムにおいて、エンジンが、OSが位置#7および#8に書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図25】代表的なシステムにおいて、エンジンが、OSが位置#2に上書きするより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図26】代表的なシステムにおいて、エンジンが、OSが位置#2を再生させるより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図27】代表的なシステムにおいて、エンジンが、OSが位置#7および#8に直接書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図28】代表的なシステムにおいて、エンジンが、OSが位置#4および#5を解放するより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図29】代表的なシステムにおいて、エンジンが、OSが位置#3に書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図30】代表的なシステムにおいて、エンジンが、OSが位置#1に書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図31】代表的なシステムにおいて、エンジンが、OSが位置#6に直接書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図32】代表的なシステムにおいて、エンジンが、OSが位置#2を解放するより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
【図33】代表的なシステムにおいて、エンジンが、OSが位置#1に書き込むより以前の状態に復帰する様子を、本発明の1実施形態に従って示したブロック図である。
Claims (19)
- データを回復させるための方法であって、
ディスク位置Xと、前記ディスク位置Xとは異なるディスク位置Yと、ディスク位置Zとを含んだディスクにつき、ディスクの履歴状態の記録を作成する動作と、
前記ディスク位置Xにあるもとのデータに上書きする要求に応じ、
前記ディスク位置Yに新しいデータを格納し、
前記履歴状態の記録内に、上書きを指示されたデータであって前記上書きがなされずに保存されている履歴データを含むという前記ディスク位置Xの役割と、前記ディスク位置Xの前記新しいデータを含むという前記ディスク位置Yの役割と、を示す標識を設定する動作と、
前記ディスク位置Zにあるデータを解放するコマンドに応じ、
前記データを解放するコマンドをインターセプトし、
前記履歴状態の記録内に、前記ディスク位置Zが履歴データを格納し、前記ディスク位置Zの読み出し要求があった場合にはゼロが返されるべきことを示す標識を設定する動作と、
オペレーティングシステムが後に使用するために前記ディスク位置Zを再生させる要求を受信する動作と、
前記ディスク位置Zが新しいデータの格納に利用可能であることを示す標識を、前記履歴状態の記録内に設定する動作と、を備えた方法。 - 請求項1記載の方法であって、
前記履歴状態の記録は新しい履歴ヘッダ表である、方法。 - 請求項1記載の方法であって、前記ディスク位置Xおよび前記ディスク位置Yの役割を示す前記履歴状態の記録内の標識は、転用が発生したことを示す、方法。
- 請求項1記載の方法であって、前記ディスク位置Zが履歴データを格納することを示す前記履歴状態の記録内の標識は、ディスク位置Zの状態を「ほとんど未使用」に設定する、方法。
- 請求項1記載の方法であって、さらに、
前記ディスクの過去の状態を再構成するのに必要な履歴データを含まないディスク位置Tに、新しいデータを書き込む要求を受信する動作と、
前記ディスク位置Tへの前記書き込み要求に応じ、前記新しいデータを前記ディスク位置Tに直接格納する動作と、
前記ディスク位置Tに関する過去の履歴データがもはや利用可能ではないことを示す標識を、前記履歴状態の記録内に設定する動作と
を備えた方法。 - 請求項1記載の方法であって、
前記ディスク位置Zが新しいデータの格納に利用可能であることを示す前記履歴状態の記録内の標識は、ディスク位置Zの状態が「早期」であることを示す、方法。 - 請求項6記載の方法であって、さらに、
前記ディスク位置Zにあるもとのデータに上書きする要求に応じ、新しいデータをディスク位置Y’に格納する動作と、
前記ディスク位置Zおよび前記ディスク位置Y’の役割を示す標識を、前記履歴状態の記録内に設定する動作と
を備えた方法。 - 請求項1記載の方法であって、さらに、
前記ディスク位置Xにある前記もとのデータを前記ディスク位置Yに転送する動作と、
前記ディスク位置Yの前記新しいデータを前記ディスク位置Xに転送する動作と
を備えた方法。 - 請求項1記載の方法であって、
前記履歴状態の記録は、
ディスク位置の状態を示すマップと、
前記履歴データをメイン領域にマッピングする履歴表であって、さらに、前記オペレーティングシステムによって解放されたディスク位置を示し、前記履歴表内のエントリに発生順にアクセスすることができる、履歴表と、を含み、
前記方法は、さらに、
オペレーティングシステムからのファイル管理コマンドをインターセプトする動作と、
前記標識を前記エントリとして実質上発生順に前記履歴表内に記録する動作と
を備えた方法。 - 請求項9記載の方法であって、
前記マップは、前記オペレーティングシステムによって「ほどんと未使用」であるとして解放された削除ディスク位置の状態を示す、方法。 - 請求項10記載の方法であって、さらに、
前記削除ディスク位置が履歴データを含むことを示す標識を、前記履歴表内に記録する動作を備えた、方法。 - 請求項11記載の方法であって、
前記マップは、前記削除ディスク位置を再生させるという前記オペレーティングシステムからの要求に応じ、前記削除ディスク位置の状態を「早期」であると示す、方法。 - 請求項9記載の方法であって、
前記マップは、前記ディスクの過去の状態を再構成するのに必要な履歴データを有さない未使用なディスク位置の状態を、「真に未使用」であると示す、方法。 - 請求項13記載の方法であって、さらに、
前記未使用なディスク位置に書き込むという前記オペレーティングシステムからの要求に応じ、前記未使用なディスク位置が直接の書き込みを受信したことを示す標識を、前記履歴表内に記録する動作を備えた、方法。 - 請求項9記載の方法で処理した前記ディスクの過去の状態を復元するための方法であって、
(a)前記ディスクを再構成する要求に応じ、前記履歴表内の最新のエントリを検討する動作と、
(b)前記ディスクのディスク位置Pにあるもとのデータを新しいデータで上書きすることに関する書き込みエントリが、前記最新のエントリ内において検知された場合に、前記ディスク位置Pにある前記新しいデータを前記もとのデータで置き換える動作と、
(c)前記ディスクのディスク位置Qの解放に関する解放エントリが、前記最新のエントリ内において検知された場合に、前記解放されていたディスク位置Qに前記オペレーティングシステムがアクセスするのを許可する動作と、
(d)前記履歴表内の前記最新のエントリを廃棄する動作と、
(e)前記ディスクの前記過去の状態が復元されるまで、動作(a)〜(d)を繰り返す動作と
を備えた方法。 - 請求項15記載の方法であって、
前記工程(e)は
真の書き込みディスク位置への書き込みに関する真の書き込みエントリが、前記最新のエントリ内において検知された場合に、真の書き込みディスク位置からデータを取り除く動作を備え、
前記真の書き込みディスク位置は、前記コンピュータ読み取り可能媒体を再構成するのに必要な履歴データを含まないディスク位置である、方法。 - 請求項15記載の方法であって、
前記動作(c)における、前記オペレーティングシステムが前記ディスク位置Qにアクセスするのを許可する前記動作は、前記ディスク位置Qの「ほとんど未使用」の状態を解除することを含む、方法。 - 請求項17記載の方法であって、
前記ディスク位置Qについての前記「ほとんど未使用」の状態は、複数のディスク位置の状態を記録するマップに記録される、方法。 - 請求項15記載の方法であって、さらに、
前記コンピュータ読み取り可能媒体を再構成するのに必要な履歴データを格納するエキストラページメモリを設定する動作を備える、方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US15833699P | 1999-10-07 | 1999-10-07 | |
US60/158336 | 1999-10-07 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2001184246A JP2001184246A (ja) | 2001-07-06 |
JP3797864B2 true JP3797864B2 (ja) | 2006-07-19 |
Family
ID=22567658
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000308367A Expired - Fee Related JP3797864B2 (ja) | 1999-10-07 | 2000-10-06 | オペレーティングシステムとの関連でデータを回復および再生する方法、ソフトウェア、および装置 |
Country Status (2)
Country | Link |
---|---|
EP (1) | EP1091299A2 (ja) |
JP (1) | JP3797864B2 (ja) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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 |
US7055055B1 (en) | 1999-04-23 | 2006-05-30 | Symantec Corporation | Write cache flushing method for reducing data corruption |
AU6081200A (en) | 1999-07-09 | 2001-01-30 | Eric D. Schneider | Optimized disk storage defragmentation with swapping capabilities |
US7051055B1 (en) | 1999-07-09 | 2006-05-23 | Symantec Corporation | Optimized disk storage defragmentation with swapping capabilities |
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 |
US7949665B1 (en) | 2004-11-19 | 2011-05-24 | Symantec Corporation | Rapidly traversing disc volumes during file content examination |
EP1713008B1 (en) | 2005-04-14 | 2013-03-13 | Rajesh Kapur | Method and system for preserving access to deleted and overwritten documents by means of a system recycle bin |
JP2009258825A (ja) * | 2008-04-14 | 2009-11-05 | Hitachi Ltd | ストレージシステム、仮想化装置、及び計算機システム |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH04165543A (ja) * | 1990-10-30 | 1992-06-11 | Matsushita Electric Ind Co Ltd | 電子フアイリング装置 |
-
2000
- 2000-10-06 JP JP2000308367A patent/JP3797864B2/ja not_active Expired - Fee Related
- 2000-10-06 EP EP20000308805 patent/EP1091299A2/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
EP1091299A2 (en) | 2001-04-11 |
JP2001184246A (ja) | 2001-07-06 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6732293B1 (en) | Method, software and apparatus for recovering and recycling data in conjunction with an operating system | |
JP3878412B2 (ja) | データを保存し使用し及び回復する方法 | |
US8296264B1 (en) | Method and system for file-level continuous data protection | |
US10762039B2 (en) | Backup and restoration for storage system | |
US8005797B1 (en) | File-level continuous data protection with access to previous versions | |
US5086502A (en) | Method of operating a data processing system | |
US9699255B2 (en) | Device driver | |
US7246211B1 (en) | System and method for using file system snapshots for online data backup | |
US7849257B1 (en) | Method and apparatus for storing and retrieving data | |
US6738863B2 (en) | Method for rebuilding meta-data in a data storage system and a data storage system | |
US6816941B1 (en) | Method and system for efficiently importing/exporting removable storage volumes between virtual storage systems | |
US7325159B2 (en) | Method and system for data recovery in a continuous data protection system | |
US7406488B2 (en) | Method and system for maintaining data in a continuous data protection system | |
EP0733235B1 (en) | Incremental backup system | |
US7363540B2 (en) | Transaction-safe FAT file system improvements | |
US7318135B1 (en) | System and method for using file system snapshots for online data backup | |
KR100510808B1 (ko) | 데이터 저장 장치 및 시스템을 위한 로그 구조 기록 캐시 | |
KR100437199B1 (ko) | 컴퓨터시스템및그에저장된데이터를액세싱하기위한방법 | |
US6718427B1 (en) | Method and system utilizing data fragments for efficiently importing/exporting removable storage volumes | |
US20020049883A1 (en) | System and method for restoring a computer system after a failure | |
EP2333653A1 (en) | Information backup/restoring apparatus and information backup/restoring system | |
US20080147756A1 (en) | Method and system for restoring a volume in a continuous data protection system | |
US7383465B1 (en) | Undoable volume using write logging | |
JPH1055298A (ja) | コンピュータのディスクボリュームをバックアップするシステム | |
US20070061540A1 (en) | Data storage system using segmentable virtual volumes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040514 |
|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A711 Effective date: 20040528 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040514 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20040528 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050201 |
|
A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20050427 |
|
A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20050506 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050728 |
|
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: 20060328 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060418 |
|
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: 20090428 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110428 Year of fee payment: 5 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: R3D02 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120428 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130428 Year of fee payment: 7 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140428 Year of fee payment: 8 |
|
LAPS | Cancellation because of no payment of annual fees |