(57)【要約】【課題】データ処理装置においてファイル・システム内のデータを管理するための方法、装置、およびコンピュータ・プログラムを提供すること。【解決手段】ファイル・システム内のデータ・ブロックを変更する要求が、ファイル・システム回復時間中に検出される。要求の検出に応答して、データ・ブロックを記述するメタデータがスナップショット・イメージに書き込まれる。ファイル・システム内のデータ・ブロックに関するデータがスナップショット・イメージにコピーされる。データがスナップショット・イメージにコピーされた後で、ファイル・システム内のデータ・ブロックが変更される。スナップショット・イメージを使用すると、ファイル・システムを、ファイル・システム内のデータ・ブロックを変更する前の状態に戻すことができる。【選択図】図３
2005228329.tif 000002
【特許請求の範囲】
【請求項１】
データ処理システムにおいてファイル・システム内のデータを管理するための方法であって、
前記ファイル・システム内のデータ・ブロックを変更する要求を検出するステップと、
前記要求の検出に応答して、前記ファイル・システム内の前記データ・ブロックを記述するメタデータをスナップショット・イメージに書き込むステップと、
前記ファイル・システム内の前記データ・ブロックに関するデータを前記スナップショット・イメージにコピーするステップと、
前記ファイル・システム内の前記データ・ブロックを、前記データ・ブロック内の前記データの前記スナップショット・イメージへのコピーが発生した後に変更するステップと
を含む方法。
【請求項２】
前記コピーするステップが、前記データを見出すのに使用される情報の識別を前記スナップショット・イメージ内部のテーブル内に保存するステップを含み、前記テーブルが前記ファイル・システム内の異なるデータ・ブロックを見出すのに使用される、請求項１に記載の方法。
【請求項３】
前記スナップショット・イメージが、スナップショット要約マップと、スナップショット・マップと、１組のセグメントとを含み、前記要約マップが前記スナップショット・マップ内のスナップショット・マップ・ページに関する初期化済み状態を識別し、前記スナップショット・マップが前記ファイル・システム内で使用中のデータ・ブロックを識別するスナップショット・マップ・ページを含んでおり、前記１組のセグメントが前記ファイル・システムからのデータ・ブロックのコピーを含む、請求項１に記載の方法。
【請求項４】
前記メタデータが、スナップショット要約マップ、要約マップ、およびセグメント・ヘッダを含む、請求項１に記載の方法。
【請求項５】
選択されたイベントが、前記ファイル・システム内の前記データ・ブロックを変更中の前記データ処理システムの障害である、請求項４に記載の方法。
【請求項６】
選択されたイベントが、前記ファイル・システムの整合状態への回復を要求するユーザ入力である、請求項４に記載の方法。
【請求項７】
前記書き込むステップが、スナップショット・マップ・グループの参照するどのような変更前イメージ・データ・ブロックをスナップショット・イメージに書き込むよりも前に、スナップショット・マップ・エントリに対応する前記スナップショット・マップ・グループの使用中状態を前記スナップショット・イメージに書き込むステップを含む、請求項１に記載の方法。
【請求項８】
前記書き込むステップが、前記スナップショット・マップ・グループに対応するデータ・ブロックの前記使用中状態をスナップショット・イメージに書き込んだ後で、スナップショット要約マップ・エントリを初期化済みであるとマークし、前記スナップショット・マップ・グループの場所をマークするステップをさらに含む、請求項７に記載の方法。
【請求項９】
前記書き込むステップが、先行セグメントが新しい最後のセグメントを指すように変更されるより前に、セグメントのリスト内の前記新しい最後のセグメントのセグメント・ヘッダを初期化するステップをさらに含む、請求項８に記載の方法。
【請求項１０】
前記スナップショット・マップがスナップショット・マップ・ページを含んでおり、前記スナップショット・マップ・ページが回復操作中に再構築される、請求項４に記載の方法。
【請求項１１】
前記回復操作が、前記回復操作が変更すべき前記ファイル・システム内のデータ・ブロックの変更前イメージのコピー操作をハンドルする、請求項１０に記載の方法。
【請求項１２】
ファイル・システム内のデータを管理するためのデータ処理システムであって、
前記ファイル・システム内のデータ・ブロックを変更する要求を検出するための検出手段と、
前記要求の検出に応答して、前記ファイル・システム内の前記データ・ブロックを記述するメタデータをスナップショット・イメージに書き込むための書き込み手段と、
前記要求を検出するのに応答して、前記ファイル・システム内の前記データ・ブロックに関するデータを前記スナップショット・イメージにコピーするためのコピー手段と、
前記ファイル・システム内の前記データ・ブロックを、前記データ・ブロック内の前記データの前記スナップショット・イメージへのコピーが発生した後に変更するための変更手段と
を含むデータ処理システム。
【請求項１３】
前記コピー手段が、前記データを見出すのに使用される情報の識別を前記スナップショット・イメージ内部のテーブル内に保存するための保存手段を含み、前記テーブルが前記ファイル・システム内の異なるデータ・ブロックを見出すのに使用される、請求項１２に記載のデータ処理システム。
【請求項１４】
前記スナップショット・イメージが、スナップショット要約マップと、スナップショット・マップと、１組のセグメントとを含み、前記要約マップが前記スナップショット・マップ内のスナップショット・マップ・ページに関する初期化済み状態を識別し、前記スナップショット・マップが前記ファイル・システム内で使用されるデータ・ブロックを識別するスナップショット・マップ・ページを含んでおり、前記１組のセグメントが前記ファイル・システムからのデータ・ブロックのコピーを含む、請求項１２に記載のデータ処理システム。
【請求項１５】
前記メタデータが、スナップショット要約マップ、要約マップ、およびセグメント・ヘッダを含む、請求項１２に記載のデータ処理システム。
【請求項１６】
選択されたイベントが、前記ファイル・システム内の前記データ・ブロックを変更中の前記データ処理システムの障害である、請求項１５に記載のデータ処理システム。
【請求項１７】
選択されたイベントが、前記ファイル・システムの整合状態への回復を要求するユーザ入力である、請求項１５に記載のデータ処理システム。
【請求項１８】
データ処理システムにおいてファイル・システム内のデータを管理するためのコンピュータ・プログラムであって、コンピュータに
前記ファイル・システム内のデータ・ブロックを変更する要求を検出するための第１の機能と、
前記要求の検出に応答して、前記ファイル・システム内の前記データ・ブロックを記述するメタデータをスナップショット・イメージに書き込むための第２の機能と、
前記要求の検出に応答して、前記ファイル・システム内の前記データ・ブロックに関するデータを前記スナップショット・イメージにコピーするための第３の機能と、
前記ファイル・システム内の前記データ・ブロックを、前記データ・ブロック内の前記データの前記スナップショット・イメージへのコピーが発生した後に変更するための第４の機能と
を実現させるためのコンピュータ・プログラム。
【請求項１９】
前記第３の機能が、前記データを見出すのに使用される情報の識別を前記スナップショット・イメージ内部のテーブル内に保存するための機能を含み、前記テーブルが前記ファイル・システム内の異なるデータ・ブロックを見出すのに使用される、請求項１８に記載のコンピュータ・プログラム。
【請求項２０】
前記スナップショット・イメージが、スナップショット要約マップと、スナップショット・マップと、１組のセグメントとを含み、前記要約マップが前記スナップショット・マップ内のスナップショット・マップ・ページに関する初期化済み状態を識別し、前記スナップショット・マップが前記ファイル・システム内で使用されるデータ・ブロックまたは前記スナップショットにコピーされるデータ・ブロックを識別するスナップショット・マップ・ページを含んでおり、前記１組のセグメントが前記ファイル・システムからのデータ・ブロックのコピーを含む、請求項１８に記載のコンピュータ・プログラム。
【請求項２１】
前記メタデータが、スナップショット要約マップ、要約マップ、およびセグメント・ヘッダを含む、請求項１８に記載のコンピュータ・プログラム。
【請求項２２】
選択されたイベントが、前記ファイル・システム内の前記データ・ブロックを変更中の前記データ処理システムの障害である、請求項２１に記載のコンピュータ・プログラム。
【請求項２３】
選択されたイベントが、前記ファイル・システムの整合状態への回復を要求するユーザ入力である、請求項２１に記載のコンピュータ・プログラム。
【請求項２４】
バス・システムと、
前記バス・システムに接続され、１組の命令を含むメモリと、
前記バス・システムに接続された処理ユニットとを含み、前記処理ユニットが、ファイル・システム内のデータ・ブロックを変更する要求を検出し、前記要求を検出したのに応答して、前記ファイル・システム内の前記データ・ブロックを記述するメタデータをスナップショット・イメージに書き込み、前記ファイル・システム内の前記データ・ブロックに関するデータを前記スナップショット・イメージにコピーし、前記ファイル・システム内の前記データ・ブロックを、前記データ・ブロック内の前記データの前記スナップショット・イメージへのコピーが発生した後に変更するための１組の命令を実行する、
データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、改善されたデータ処理システムに関し、詳細には、データを処理するための方法および装置に関する。さらに詳細には、本発明は、ファイル・システムを管理するための方法、装置、およびコンピュータ・プログラムを提供する。
【背景技術】
【０００２】
ファイル・システムは、ファイルをディスクに格納したり、ディスクから取り出したりするための機構である。ファイル・システムにより、ファイルについて常に把握しておくためのディレクトリ構造およびファイルにアクセスするために必要なパス構成規則が定義される。また、ファイル・システムにより、ファイルを名付ける方法、および、ファイルまたはボリュームの最大ファイル・サイズが定義される。ファイル・システムは、一般に、２つの異なる部分、ファイルの集合とディレクトリ構造とから構成される。ファイルの集合中の各ファイルには関連するデータが格納される。ディレクトリ構造により、ファイル・システム内のファイルについての情報が整理され、提供される。
【０００３】
ファイル・システムに関する問題に、ファイル・システム内で生じる破損およびエラーに関するものがある。ファイル・システム・スナップショットは、ある時点でのファイル・システムの整合ブロック・レベル・イメージを確立するために使用される。ブロックは、一緒に同時に送信または処理される一群のデータである。ブロックは、データ・ブロックとも呼ばれる。たとえば、１ブロックは１キロバイトのサイズとすることができる。ファイル・システムのスナップショットは、ファイル・システムのバックアップを作成するために使用される。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
こうしたスナップショットは、ファイル・システムを再構築するために使用される。現在のスナップショットは、データ処理システムのクラッシュに関して永続的ではない。本発明での認識によれば、現在利用可能なスナップショット・システムは、ファイル・システム回復操作の間に維持されなくなる。その結果、こうしたタイプのスナップショットはシステム・リブートの前後で永続的ではない。
【０００５】
したがって、ファイル・システムに対するスナップショットを作成し管理するための改善された方法、装置、およびコンピュータ・プログラムを有することは、有利であろう。
【課題を解決するための手段】
【０００６】
本発明は、データ処理システムにおいてファイル・システム内のデータを管理するための方法、装置、およびコンピュータ・プログラムを提供する。
【０００７】
ファイル・システム内のデータ・ブロックを変更する要求が、ファイル・システム回復時間中に検出される。その要求の検出に応答して、データ・ブロックを記述するメタデータがスナップショット・イメージに書き込まれる。ファイル・システム内のデータ・ブロックに関するデータがスナップショット・イメージにコピーされる。そのデータがスナップショット・イメージにコピーされた後で、ファイル・システム内のデータ・ブロックが変更される。スナップショット・イメージを使用すると、ファイル・システム内のデータ・ブロックを変更する前の状態にファイル・システムを戻すことができる。
【０００８】
本発明の特徴となると思われる新規な特徴は、添付の特許請求の範囲に述べる。しかし、本発明自体および使用の好ましい態様、そのさらなる目的および利点は、例示的な実施形態についての下記の詳細な説明を添付の図面と併せ読むときに最もよく理解されるであろう。
【発明を実施するための最良の形態】
【０００９】
次に図面を、特に図１を参照すると、本発明の好ましい一実施形態による、本発明が実施できるデータ処理システムが示されている。システム・ユニット１０２、ビデオ・ディスプレイ端末１０４、キーボード１０６、フレキシブル・ディスク・ドライブその他の永続ストレージおよび取り外し可能ストレージを含んでもよいストレージ装置１０８、ならびにマウス１１０を含むコンピュータ１００が示してある。パーソナル・コンピュータ１００には、たとえばジョイスティック、タッチパッド、タッチ・スクリーン、トラックボール、マイクロフォンなど追加の入力装置が、これに付随する形で含まれていてもよい。コンピュータ１００は、ＩＢＭ  ｅＳｅｒｖｅｒコンピュータやＩｎｔｅｌｌｉＳｔａｔｉｏｎコンピュータなど適切などんなコンピュータを使用して実装することも可能である。これらはニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションの製品である。図１にはコンピュータが示してあるが、本発明の他の実施形態をネットワーク・コンピュータなどの他のタイプのデータ処理システム内に実装することもできる。コンピュータ１００はまた、好ましくは、コンピュータ１００の内部で動作する、コンピュータ可読媒体内にあるシステム・ソフトウェアによって実装できるグラフィカル・ユーザ・インターフェース（ＧＵＩ）を含む。
【００１０】
次に図２を参照すると、本発明を実施できるデータ処理システムの構成が示されている。データ処理システム２００は、本発明のプロセスを実施するコードまたは命令を搭載できる、図１のコンピュータ１００などのコンピュータの一例となっている。データ処理システム２００では、ＰＣＩローカル・バス・アーキテクチャを使用している。ここに図示された例ではＰＣＩバスを使用しているが、ＡＧＰやＩＳＡを使用してもよい。プロセッサ２０２およびメイン・メモリ２０４は、ＰＣＩブリッジ２０８によってＰＣＩローカル・バス２０６に接続されている。ＰＣＩブリッジ２０８はまた、プロセッサ２０２用の内蔵メモリ・コントローラおよびキャッシュ・メモリを含むことができる。ＰＣＩローカル・バス２０６への追加の接続は、直接のコンポーネント相互接続によって、またはアドイン・コネクタによって行うことができる。ここに図示された例では、ＬＡＮアダプタ２１０、ＳＣＳＩホスト・バス・アダプタ２１２、および拡張バス・インターフェース２１４が、直接のコンポーネント接続によってＰＣＩローカル・バス２０６に接続されている。それとは異なり、オーディオ・アダプタ２１６、グラフィックス・アダプタ２１８、およびオーディオ／ビデオ・アダプタ２１９は、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス２０６に接続されている。拡張バス・インターフェース２１４は、キーボードおよびマウス・アダプタ２２０、モデム２２２、および追加メモリ２２４に対する接続を提供する。ＳＣＳＩホスト・バス・アダプタ２１２は、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０に対する接続を提供する。典型的なＰＣＩローカル・バス実装では、３個または４個のＰＣＩ拡張スロットまたはアドイン・コネクタがサポートされる。
【００１１】
オペレーティング・システムは、プロセッサ２０２上で動作し、図２のデータ処理システム２００内部の様々なコンポーネントの制御を調整し、提供するのに使用される。オペレーティング・システムは、マイクロソフト・コーポレーションから入手できるＷｉｎｄｏｗｓ（Ｒ）ＸＰなど市販のオペレーティング・システムでよい。オペレーティング・システムとともに、Ｊａｖａ（Ｒ）などのオブジェクト指向プログラミング・システムが動作していてもよく、これにより、データ処理システム２００上で実行されるＪａｖａ（Ｒ）プログラムまたはアプリケーションからオペレーティング・システムへの呼び出しが提供される。オペレーティング・システム、オブジェクト指向プログラミング・システム、およびアプリケーションまたはプログラムのための命令は、ハード・ディスク・ドライブ２２６などのストレージ装置上にあり、プロセッサ２０２による実行のためにメイン・メモリ２０４へとロードすることができる。
【００１２】
図２のハードウェアは、実装に応じて変わりうることが当業者には理解されよう。フラッシュＲＯＭ、同等な不揮発性メモリ、または光ディスク・ドライブなどの他の内部ハードウェアまたは周辺装置を、図２に示されているハードウェアに追加してまたはその代わりに使用することができる。また、本発明のプロセスは、マルチプロセッサ・データ処理システムに適用することも可能である。
【００１３】
たとえば、データ処理システム２００は、任意選択でネットワーク・コンピュータとして構成されている場合、ＳＣＳＩホスト・バス・アダプタ２１２、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８およびＣＤ−ＲＯＭ２３０を含まなくてもよい。その場合、そのコンピュータは、適切にはクライアント・コンピュータと呼ばれるが、ＬＡＮアダプタ２１０、モデム２２２などのあるタイプのネットワーク通信インターフェースを含む。別の例として、データ処理システム２００は、それがあるタイプのネットワーク通信インターフェースを含むと否とにかかわらず、そのネットワーク通信インターフェースを利用しなくてもブート可能なように構成されたスタンド・アロン・システムでもよい。さらに別の例として、データ処理システム２００は、携帯情報端末（ＰＤＡ）でもよく、これは、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方を格納するための不揮発性メモリを提供するＲＯＭまたはフラッシュＲＯＭあるいはその両方付きで構成される。
【００１４】
図２に示された例および上記の例は、アーキテクチャ上の制限を示唆するものではない。またたとえば、データ処理システム２００は、ＰＤＡの形をとるほかに、ノートブック・コンピュータまたはハンド・ヘルド・コンピュータでもよい。またデータ処理システム２００は、キオスクまたはＷｅｂアプライアンスであってもよい。
【００１５】
本発明のプロセスは、プロセッサ２０２により、コンピュータ実装命令を使用して実行されるが、それらの命令は、たとえばメイン・メモリ２０４、メモリ２２４などのメモリ内に、あるいは１つまたは複数の周辺装置２２６〜２３０内に置くことができる。
【００１６】
次に図３に移ると、本発明の好ましい実施形態によるファイル・システムのスナップショットを作成し管理するのに使用するコンポーネントが示されている。本明細書では、「スナップショット」という用語はファイル・システムのスナップショットを指すのに使用するが、これはまた「ファイル・システム・スナップショット」と呼ぶこともできる。
【００１７】
この例では、ユーザ空間３００およびカーネル空間３０２が存在している。スナップショットＵＩ（ユーザ・インターフェース）３０４および回復ＵＩ３０６は、ユーザ空間３００内にある。これらのユーザ・インターフェースは、ユーザ入力を受け取ってスナップショットを作成し、また、ファイル・システムが以前の状態に復元される場合に回復プロセスを実行するのに使用される。特に、スナップショットＵＩ３０４は、スナップショットの作成を開始するのに使用される。このインターフェースは、作成または削除の問い合わせなどのコマンドを受け取るのに使用される。ユーザは、人でもアプリケーションでもよい。回復ＵＩ３０６は、システム・クラッシュまたは電源障害の後でファイル・システムの復元を開始するのに使用される。
【００１８】
カーネル空間３０２は、ファイル・ハンドリング・スレッド３０８、ファイル・システム・スナップショット・スレッド３１０、論理ボリューム・マネージャ３１２、ファイル・システム装置３１４、およびスナップショット装置３１６を含んでいる。ファイル・システム３１８は、ファイル・システム装置３１４の内部にある。この２つの装置は、これらの例では、論理ボリュームである。ファイル・ハンドリング・スレッド３０８は、読み取り操作、書き込み操作、またはドライブ・マウント操作などのデータ・アクセスに使用される。こうした操作は、ファイル・システム装置３１４内のファイル・システム３１８などのファイル・システム内に存在するデータに対して実行される。ファイル・ハンドリング・スレッド３０８のプロセスは、通常のファイル・システム操作中に、データ・アクセスに対する要求を受け取ると、使用される。
【００１９】
ファイル・システム・スナップショット・スレッド３１０は、スナップショット装置３１６内にあるスナップショット３２０などのスナップショットを作成するプロセスを実装するのに使用される。この装置は、様々な場所にあってよい。たとえば、スナップショット３２０は、ファイル・システム３１８と同じ物理ハード・ドライブ上に置くことができる。代替方法として、スナップショット３２０は、不揮発性ランダム・アクセス・メモリ（ＮＶＲＡＭ）などの別の記憶メディア上、別の物理ハード・ディスク・ドライブ上、または光メディア上に置くこともできる。論理ボリューム・マネージャ３１２は、ファイル・ハンドリング・スレッド３０８およびファイル・システム・スレッド３１０と、論理装置であるファイル・システム装置３１４およびスナップショット装置３１６との間のインターフェースをとるのに使用される。
【００２０】
ランタイム中、万一のデータ処理システムのクラッシュの際にスナップショット３２０内の状態を再構築できるような方式でスナップショット・メタデータが構築され、スナップショット３２０に書き込まれる。これらの例示的な例では、ファイル・システムの回復または修復中には、スナップショット装置３１６内の再構築されたスナップショットを、回復または修復プロセスが、再マウント時の再構築されたスナップショットの状態と再マウント時の修復されたファイル・システム状態とが整合するように、絶えず更新する。ファイル・システムの回復または修復操作が完了した後、スナップショットは、そのスナップショットが作成された時点のファイル・システムの整合ブロック・レベル・イメージを引き続き含むことになる。
【００２１】
具体的には、ファイル・システム３１８への書き込みや、そこからの削除など、ファイル・システム内でデータを変更すべきときには、スナップショット３２０はファイル・システムからのデータで更新される。これらの例では、ファイル・システム３１８内で変更すべきデータ・ブロックは、その実際の変更の前に、スナップショット３２０にコピーされる。データ・ブロックからのデータのほかに、変更前のデータ・ブロックを記述するメタデータもスナップショット３２０にコピーされる。スナップショット３２０内のメタデータ、およびランタイム中にデータ・ブロックに関して作成されたデータを使用すると、ファイル・システム３１８をそのデータ・ブロックの更新前の状態にすることができる。
【００２２】
次に図４に移ると、本発明の好ましい実施形態によるスナップショット・メタデータが示されている。スナップショット・メタデータ４００は、図３のスナップショット３２０など、ファイル・システム内のファイル・システム・ブロックを把握しておくためのスナップショット・メタデータの一例となっている。スナップショット・メタデータ４００は、図３のファイル・システム・スナップショット・スレッド３１０などのスナップショット・プロセスによって作成される。例示の実施形態では、このスナップショットは、データ処理システムのシステム・リブートの前後で永続的である。スナップショットの永続性（パーシスタンス）は、スナップショット・イメージがファイル・システムの回復または修復操作によって維持可能なときに生じる。
【００２３】
この例では、スナップショット・メタデータ４００は、スナップショット要約マップ４０２、スナップショット・マップ４０４、およびスナップショット・セグメント４０６を含んでいる。スナップショット要約マップ４０２内部のエントリは、スナップショット・マップ４０４内にあるスナップショット・マップ・ページを記述するのに使用される。この例では、スナップショット要約マップ４０２内の各エントリは、スナップショット・マップ４０４内の１つのスナップショット・マップ・グループの初期化済み状態を記述する。１つのスナップショット・マップ・グループは、３２個のスナップショット・マップ・ページを含んでいる。スナップショット・マップ４０４内部のデータは、ファイル・システム内のあらゆるデータ・ブロックに関する使用中およびコピー済み状態を記述する。スナップショット・セグメント４０６は、スナップショット・セグメント４０６にコピーされたデータ・ブロックを記述する変更前イメージ記述子）、およびファイル・システムの変更以前からのデータ・ブロックを含んでいる。
【００２４】
ランタイム中に、ファイル・システム上のデータ・ブロックへの変更が行われることになると、スナップショット・メタデータ４００にオン・ディスク構造状態が保存される。こうした変更には、書き込み時コピー（ＣＯＷ）および削除時コピー（ＣＯＤ）が含まれる。データ・ブロックに関するこうした状態の保存により、ファイル・システム内のデータ・ブロックの変更より前の状態にそのファイル・システムを戻すことが可能になる。スナップショット・マップ４０４内の１つのスナップショット・マップ・グループが割り当てられ、スナップショット・メタデータ４００内で初期化されたあらゆるスナップショット・マップ・グループについて、各スナップショット・マップ・エントリの使用中状態が初期化され、同期的にディスクに書き込まれる。スナップショット要約マップ・エントリは、ランタイム中、同期的に初期化され更新される。
【００２５】
次に図５に移ると、本発明の好ましい実施形態によるファイル・システムのスナップショットの先頭部分が示されている。セクション５００は、スナップショット・スーパーブロック５０２、ブロック・マップＸｔｒｅｅコピー５０４、およびスナップショット要約マップ５０６を含む、ハード・ディスク・ドライブ上のセクションである。
【００２６】
スナップショット要約マップ５０６が、図４のスナップショット・メタデータ４００などのスナップショットの先頭になっている。スナップショット・スーパーブロック５０２は、スナップショットの先頭を識別し、ファイル・システムの最後のマウント以降に書き込まれたスナップショット内のスナップショット・セグメントの先頭および末尾を指している。ファイル・システムのマウントは、データ処理システム内で、ファイル・システムがアクセスのために利用可能にされたとき行われる。ブロック・マップＸｔｒｅｅコピー５０４は、ファイル・システム内の異なるブロックに関する使用中状態を記述する、ファイル・システム構造のマップを含んでいる。スナップショット要約マップ５０６はエントリを含んでおり、各エントリは、１つのスナップショット・マップ・グループと、初期化されたスナップショット・マップ・グループ内の各スナップショット・マップ・ページに関する使用中状態の要約とを含むスナップショット・セグメントを指している。
【００２７】
次に図６を参照すると、本発明の好ましい実施形態によるスナップショット・マップ内のスナップショット・マップ・グループが示されている。スナップショット・マップ・グループ６００は、図４のスナップショット・マップ４０４などのスナップショット・マップ内部にあるページの一例となっている。これらの例では、スナップショット・マップ・グループ６００は、３２ページを含むが、この図ではそのうちの４ページ、スナップショット・マップ・ページ６０２、スナップショット・マップ・ページ６０４、スナップショット・マップ・ページ６０６、スナップショット・マップ・ページ６０８だけが示されている。スナップショット・マップ・グループ６００内の各スナップショット・マップ・ページは、当該ページによりマップされたあらゆるファイル・システム・ブロックについて、使用中状態で初期化され、ディスクに同期的に書き込まれる。ファイル・システム・ブロックのコピー済み状態は、そのファイル・システム・ブロックの変更前イメージのコピー後に、スナップショット・マップ・ページに非同期的に書き込まれる。
【００２８】
次に図７に移ると、本発明の好ましい実施形態によるスナップショット・マップ・グループ内のスナップショット・マップ（ｓＭａｐ）ページが示されている。スナップショット・マップ・ページ７００は、図６のスナップショット・マップ・ページ６０２などのスナップショット・マップ・ページの一例となっている。このページまたはエントリは、スナップショット・セグメント内のこの特定のページに関連付けられたあらゆるデータ・ブロックの使用中状態の記述を含んでいる。たとえば、エントリ７０２、７０４、７０６、７０８、７１０、７１２、および７１４では、ファイル・システム・データ・ブロックが使用中であるものとして記述されている。この例では、ファイル・システム内で、ファイル・システム・ブロック（ｆｓｂｌｋ）０、１、２、５０８、５０９、５１０、および５１１が、スナップショットが作成されたときに使用中であったことが示されている。エントリ７１６、７１８、および７２０では、ファイル・システム・ブロックがコピーされたものとして示されている。この例では、ファイル・システム・ブロック５０９、５１０、および５１１は、その変更前イメージがスナップショットにコピーされていることが示されている。エントリ７２６、７２８、および７３０では、ファイル・システム・ブロックに関する変更前イメージがコピーされたスナップショット内の場所が示されている。この例では、ファイル・システム・ブロック５０９の変更前イメージがスナップショット・ブロック５１６にコピーされ、ファイル・システム・ブロック５１０の変更前イメージがスナップショット・ブロック５１７にコピーされ、ファイル・システム・ブロック５１１の変更前イメージがスナップショット・ブロック５１８にコピーされたことが示されている。エントリ７２２および７２４は、使用中でもコピー済みでもないものとして示されている。これらの例では、スナップショット・マップ・ページ７００内に５１２エントリが存在する。例示の目的で、スナップショット・マップ・ページ７００内に実際に存在するエントリのいくつかだけが示してある。
【００２９】
次に図８に移ると、本発明の好ましい実施形態によるセグメントが示されている。セグメント・ヘッダ８００は、図４のスナップショット・セグメント４０６などのスナップショット・セグメント内にあるセグメント・ヘッダの一例となっている。この例では、セグメント・ヘッダ８００は、セグメント８０１内のあるページにあり、そのサイズはこの例では１２８ｋバイトである。もちろん、実装に応じてどのような大きさのセグメントも使用することができる。
【００３０】
セグメント８０１は、リンク、セルフ・バリュー、およびエクステント数、ならびに２４８個のスナップショット・ログ（ｓＬｏｇ）エントリが入った、セグメント・ヘッダ８００を含んでいる。リンクは、次のセグメントへのアドレスであり、セルフ・バリューは、現在のセグメントのアドレスである。エクステント数の値により、そのセグメントにコピーされたエクステントの数が識別される。エクステントとは、ファイル・システム・オブジェクトに単位として割り当てられた一連の連続するファイル・システム・ブロックである。ここに示すように、ｓＬｏｇエントリ８０４、８０６、および８０８は、スナップショットにコピーされたファイル・システム変更前イメージを記述するヘッダ・エントリである。各ｓＬｏｇエントリは、巡回冗長性検査（ＣＲＣ）データ、開始データ・ブロック・アドレス（ｓＡｄｄｒ）、および連続するデータ・ブロックの数を識別する長さを含む。変更前イメージ・ファイル・システム・データ・ブロックは、この例ではセクションすなわちエクステント８１０または８１２にある。ここで、「変更前イメージ」とは、スナップショットが作成されたときに、ファイル・システム内に存在していた通りのファイル・システム・ブロックを意味する。ブロック・イメージは、そのブロック・イメージを変更しようとする試みが行われたときに、「変更前イメージ」になる。また、この新しいブロック・イメージを、「変更後イメージ」と呼ぶことも可能である。ファイル・システムは、スナップショットがファイル・システム・ブロックの変更前イメージのコピーを得た後に、変更後イメージ・ブロックをその装置に書き込むことができる。
【００３１】
セグメント８０１などのセグメントについて述べると、変更前イメージ・データ・ブロックはこれらのセグメントに同期的に書き込まれる。これらのセグメントは、図５のスナップショット・スーパーブロック５０２などのスーパーブロック内のリンク・リストで記述される。このリンク・リスト内の最後のセグメントのヘッダは、最後の１つ前のセグメント・ヘッダがこの最後のセグメントを指すように書き換えられる前に、必ず初期化される。これらのセグメントはまた、そのセグメントにコピーされたデータ・ブロックを記述する変更前イメージ記述子を含んでいる。これらの例では、ＣＲＣデータ・フィールドなどのチェックサム・フィールドを使用して、クラッシュが発生したときに、最後の変更前イメージ・エクステントのページ・アウトが確認される。
【００３２】
図９および１０は、本発明の好ましい実施形態に従ってファイル・システムのスナップショットを更新するプロセスの流れ図である。図９および１０のプロセスは、図３のファイル・システム・スナップショット・スレッド３１０などのスナップショット・プロセスの中に実装することができる。
【００３３】
プロセスは、書き込みまたは削除の要求など、ファイル・システム内のデータを変更する要求を受け取ることから始まる（ステップ９００）。次に、ファイル・システムのスナップショットが存在するかどうか判断が行われる（ステップ９０２）。スナップショットが存在する場合、ブロックＸに関するスナップショット要約マップ（ｓｓＭａｐ）エントリが初期化されているかどうか判断が行われる（ステップ９０４）。この例では、ｓｓＭａｐエントリは、図４のスナップショット要約マップ４０２などのｓｓＭａｐ内にある。ブロックＸは、ファイル・システム内で変更されようとしているデータ・ブロックを表す。ブロックＸに関するｓｓＭａｐエントリが初期化されていない場合、このｓｓＭａｐエントリに対応する３２個のｓＭａｐページについて、使用中状態が初期化される（ステップ９０６）。これらのｓＭａｐページは、たとえば、図６のスナップショット・マップ・グループ６００内のページであってもよい。
【００３４】
この後、３２個のスナップショット・マップ（ｓＭａｐ）ページがスナップショットに同期的に書き込まれる（ステップ９０８）。次に、ｓｓＭａｐエントリは初期化済みとマークされ、ｓＭａｐグループの場所がエントリ内でマークされ、スナップショット内のスナップショット要約マップに同期的に書き込まれる（ステップ９１０）。
【００３５】
次に、スナップショットが作成されたときにブロックＸが使用中であったかどうか判断が行われる（ステップ９１２）。スナップショットが作成されたときにファイル・システムにおいてブロックＸが使用中であった場合、ブロックＸがスナップショットにコピーされているかどうか判断が行われる（ステップ９１４）。ブロックＸがファイル・システムからスナップショットにコピーされていない場合、ブロックＸの変更前イメージが、ファイル・システムから読み込まれる（ステップ９１６）。
【００３６】
この後、スナップショット内の現在のセグメントが満杯かどうか判断が行われる（ステップ９１８）。現在のセグメントが満杯でない場合、現在のセグメント・ヘッダが次の情報、すなわち、ブロックＸの変更前イメージのスナップショット内での場所、このデータ・ブロックのファイル・システム内での場所、およびブロックＸの変更前イメージのチェックサムで変更される（ステップ９２０）。次に、セグメント・ヘッダおよびブロックＸの変更前イメージがスナップショットに同期的に書き込まれる（ステップ９２２）。言い換えれば、ファイル・システム内のこのデータ・ブロックの更新以前にファイル・システムから読み込まれた、このデータ・ブロックに関するデータがスナップショットへと書き込まれるのである。この後、ブロックＸがスナップショットにコピーされていることと、ブロックＸの変更前イメージの場所とを示すために、ｓＭａｐページが非同期的に更新される（ステップ９２４）。このｓＭａｐページは、たとえば、図６のスナップショット・マップ・ページ６０２でよい。次に、ファイル・システムの書き込みまたは削除の操作などのファイル・システム変更が行われ（ステップ９２６）、この後プロセスは終了する。
【００３７】
ステップ９０２に戻って、スナップショットが存在しない場合、プロセスは上で説明したステップ９２６に進む。次に、ステップ９０４に戻って、ブロックＸに関するｓｓＭａｐエントリが初期化されていた場合、プロセスは直接、上で説明したステップ９１２に進む。ステップ９１２で、スナップショットが作成されたときにブロックＸが使用中でなかった場合、プロセスは上で説明したステップ９２６に進む。ステップ９１４に戻って、ブロックＸがスナップショットにコピーされていた場合、プロセスはやはり上で説明したステップ９２６に進む。
【００３８】
ステップ９１８に戻って、現在のセグメントが満杯の場合、スナップショット内に新しいセグメントのためのスペースが割り当てられる（ステップ９２８）。次に、新しいセグメントが空であり、いまやスナップショット内の最後のセグメントであることを示すために、新しいセグメントのヘッダが初期化される（ステップ９３０）。次いで、新しいセグメント・ヘッダが同期的に書き込まれる（ステップ９３２）。さらに、１つ前の先行セグメントは、新しいセグメントを次のセグメントとして指すようにマークされる（ステップ９３４）。次に、先行セグメント・ヘッダが同期的に書き込まれる（ステップ９３６）。これらのセグメント・ヘッダは、両方がディスクに書き込まれる前に起きるシステム・クラッシュに対する保護のため、同期的に、この特定の順番で書き込まれる。ファイル・システム回復プロセスは、リスト内の最後に書き込まれたセグメントを判定できるかどうかにかかっている。次いで、新しいセグメントが現在のセグメントとしてマークされる（ステップ９３８）。そうして、プロセスは上で説明したステップ９２０に進む。
【００３９】
図１１〜１４の流れ図には、ファイル・システムを整合状態に戻すための回復プロセスが示されている。本発明の機構により、ファイル・システムの回復または修復が起きるときに、スナップショットを保存する方法が提供される。
【００４０】
要約マップ・ページのコピー済み状態が、変更前イメージ・データ・セグメントのリンク・リストをたどることによって再構築され、スナップショットにコピーされたファイル・システム・ブロックが見つけられる。さらに、以下に述べるプロセスは、回復または修復プロセスによって、ファイル・システムのどのような書き込みまたは削除に対しても、書き込み時コピー（ＣＯＷ）および削除時コピー（ＣＯＤ）の処理を行う。システム・クラッシュ、またはファイル・システムのアンマウントを行わない電源断の後では、ファイル・システム・メタデータは非整合状態にある可能性がある。たとえば、ブロックによっては、ディスクにフラッシュされていたり、されていなかったりする。回復／修復プロセス（ｆｓｃｋコードまたはｌｏｇｒｅｄｏ）が、ファイル・システム・メタデータを整合状態に戻すために使用される。この状態は、現在のスナップショットの状態と必ずしも同じではない。カーネル側コードは、非整合状態にあるファイル・システムをハンドルせず、したがってファイル・システムは、またマウントできるようになる前に、修復されなければならない。さらに、以下に述べるプロセスにより、ランタイムのオン・ディスク構造状態が維持されて、回復または修復が中断された場合、その継続が可能になる。
【００４１】
図１１は、本発明による好ましい実施形態に従って回復手続きを開始するプロセスである。図１１のプロセスは、図３の回復ＵＩ３０６などのプロセス中に実装することができる。
【００４２】
プロセスは、スーパーブロックから指されている最初のセグメント・ヘッダを読み取ることから始まる（ステップ１０００）。このスーパーブロックは、たとえば、図５のスナップショット・スーパーブロック５０２である。次に、セグメント内の未処理のｓＬｏｇエントリが選択される（ステップ１００２）。エントリは、図８に示したｓＬｏｇエントリと同等のものである。次いで、この選択されたセグメントが、スナップショット・セグメント・リスト内の最後のセグメントであるかどうか判断が行われる（ステップ１００４）。これが最後のセグメントである場合、チェックサムを確認することにより、データ・ブロックがコピーされているかどうか判断が行われる（ステップ１００６）。ステップ１００６は、更新前イメージが、システムが停止する前にディスクに完全に書き込まれたかどうかを判断するのに使用される。たとえば、ファイル・システムからのデータ・ブロックはスナップショットにコピーされていないが、そのデータ・ブロックに関するメタデータはスナップショットに書き込まれていて、システムがクラッシュした場合、チェックサムが一致しないことになる。この場合、このデータ・ブロックは、スナップショットにはコピーされていないが、ファイル・システム上で変更されていないので、ファイル・システム上にそのまま残っている。このチェックは、セグメント・ヘッダが同期的に書き込まれるため、最後のセグメントに対してだけ必要である。
【００４３】
次に、エントリ内のチェックサムが正常かどうか判断が行われる（ステップ１００８）。チェックサムが正常である場合、そのデータ・ブロックがｓＭａｐでコピー済みとマークされているかどうか判断が行われる（ステップ１０１０）。データ・ブロックがそのときｓＭａｐでコピー済みとマークされていない場合、そのデータ・ブロックはここでコピー済みとマークされる（ステップ１０１２）。
【００４４】
さらに、このセグメントに何か別のエントリが存在するかどうか判断が行われる（ステップ１０１８）。このセグメントに別のエントリが存在しない場合、別の未処理セグメントが存在するかどうか判断が行われる（ステップ１０２０）。別の未処理セグメントが存在する場合、次の未処理セグメントが読み込まれる（ステップ１０２２）。次いで、プロセスは上で説明したステップ１００２に進む。１０１８に戻って、セグメントにまだ未処理エントリがある場合、プロセスはやはり上で説明したステップ１００２に進む。
【００４５】
ステップ１０２０に戻って、別の未処理セグメントが存在しない場合、回復処理が開始される（ステップ１０１４）。次に、ランタイム・ハンドリング・プロセスが開始され（ステップ１０１６）、この後プロセスは終了する。ステップ１０１４は、図１３のステップ１２０８または図１４のステップ１３０６と同じである。ステップ１０１６は、図１３のステップ１２１４または図１４のステップ１３１２と同じである。
【００４６】
ステップ１００４に戻って、それが最後のセグメントでない場合、プロセスは上で説明したステップ１０１０に進む。ステップ１００８に戻って、チェックサムが正常でない場合、プロセスは上で説明したステップ１０１４に進む。ステップ１０１０で、ブロックがｓＭａｐでコピー済みとマークされている場合、プロセスは上で説明したステップ１０１８に進む。
【００４７】
次に図１２に移ると、本発明の好ましい実施形態に従ってファイル・システムを検査するプロセスが示されている。図１２のプロセスは、図３の回復ＵＩ３０６などの回復ＵＩ中に実装することができる。このプロセスにより、ｆｓｃｋコードなどのファイル・システム回復が開始したときのフローを例示する。
【００４８】
プロセスは、ｌｏｇｒｅｄｏを実行することから始まる（ステップ１１０２）。ｌｏｇｒｅｄｏのために実行される諸ステップは、以下に図１４でより詳細に説明する。次に、高速ファイル・システム・チェックが要求され、ファイル・システムがクリーンとマークされているかどうか判断が行われる（ステップ１１０４）。ファイル・システム・スーパーブロックが検査されて、ファイル・システムがクリーンであるかどうかが判断される。ｌｏｇｒｅｄｏがファイル・システムを修復できていない場合、状態はダーティとマークされることになる。高速ファイル・システム・チェックが要求されていない、またはファイル・システムがクリーンとマークされていない場合、ファイル・システム・チェックが実行され（ステップ１１０６）、この後、プロセスが終了する。ファイル・システム・チェックの諸ステップは、以下の図１３でより詳細に説明する。ステップ１１０４に戻って、高速ファイル・システム・チェック要求され、ファイル・システムがクリーンとマークされている場合、プロセスはその後で終了する。
【００４９】
図１３には、本発明の好ましい実施形態に従ってファイル・システムに対してファイル・システム・チェック回復プロセスを実行するプロセスが示されている。ファイル・システム・チェック回復プロセスは、ファイル・システム・メタデータのすべてを調べることにより、ファイル・システム・メタデータの整合性を確認し修復する方法である。このプロセスは、ｆｓｃｋとも呼ばれる。図１３のプロセスは、図３の回復ＵＩ３０６などの回復ＵＩ中に実装することができる。
【００５０】
プロセスは、ファイル・システム・チェックがファイル・システムに対する書き込み許可をもっているかどうか判断が行われることから始まる（ステップ１２０２）。ファイル・システム・チェックがファイル・システムに対する書き込み許可をもっている場合、スナップショットとの接続のためにランタイム構造体が初期化される（ステップ１２０４）。ランタイム構造体は、回復操作中にスナップショットに書き込まれるデータを保持するのに使用されるバッファである。
【００５１】
次に、セグメント・リストをたどることにより、ｓＭａｐページが再構築される（ステップ１２０６）。ステップ１２０６は、図１１のステップ１０００〜１０１４および１０１８〜１０２２に関してより詳細に説明してある。ｓＭａｐページが回復されるが、これはｓＭａｐページそのものがランタイム中に非同期的に書き込まれていたからである。ｓＭａｐページは、必ずしもファイル・システム・ブロックに関する正しいコピー済み状態を有していない。この後、通常の読み取り／書き込み（ＲＷ）ファイル・システム処理が進行する（ステップ１２０８）。ステップ１２０８中に、ｆｓｃｋコードがファイル・システム・メタデータのすべてを調べ、ファイル・システム・メタデータ内に何らかの非整合性が存在するかどうかを判断する。ｆｓｃｋコードは、何らかの非整合性を見出した場合、どのようにファイル・システム・メタデータを修復するかを決定する。ｆｓｃｋコードにより、そのファイル・システム・オブジェクトを削除するか、そのファイル・システム・オブジェクトのメタデータを修復するかのいずれかが可能である。削除する場合はＣＯＤとなり、修復する場合はＣＯＷとなる。
【００５２】
次いで、ファイル・システム・チェックが、書き込み時コピー（ＣＯＷ）操作または削除時コピー（ＣＯＤ）操作によってファイル・システムを変更するかどうか判断が行われる（ステップ１２１０）。ファイル・システム・チェックが、ＣＯＷ操作またはＣＯＤ操作によってファイル・システムを変更しない場合、スナップショットは、バッファを使用したｓＭａｐページの書き込みを、あればすべてディスクへとフラッシュすることによってクローズされ（ステップ１２１２）、プロセスはその後で終了する。
【００５３】
ステップ１２０２に戻って、ファイル・システム・チェックがファイル・システムに対する書き込み許可をもっていない場合、読み取り専用ファイル・システム・チェックをスナップショットとのやり取りなしで進め（ステップ１２１６）、プロセスはその後で終了する。読み取り専用の検査中には、ｆｓｃｋコードはファイル・システム・メタデータのすべてを調べ、何らかの非整合性が見出した場合、警告メッセージを発行し、ファイル・システムに対しては何も変更を行わない。ステップ１２１０に戻って、ファイル・システム・チェックが、ＣＯＷ操作またはＣＯＤ操作によってファイル・システムを変更する場合、ファイル・システム・ブロックがすでにスナップショットにコピーされているかどうかのランタイム検査が行われ（ステップ１２１４）、次いで、プロセスは上に説明したステップ１２０８に進む。この検査は図９および１０に関して説明したのと同じ方式で行われる。これは、図３の回復ＵＩ３０６で現在実行されているｆｓｃｋコード・プロセスと同じプロセスのもとで行われる。
【００５４】
次に図１４に移ると、本発明の好ましい一実施形態に従ってファイル・システム・ジャーナル・ログのためにｌｏｇｒｅｄｏ回復プロセスを実行するプロセスの流れ図が示されている。図１４のプロセスは、図３の回復ＵＩ３０６などの回復ＵＩの中に実装することができる。
【００５５】
プロセスは、スナップショットとの接続のためにランタイム構造体を初期化することから始まる（ステップ１３０２）。次に、セグメント・リストをたどることにより、ｓＭａｐページが再構築される（ステップ１３０４）。ステップ１３０４は、図１１のステップ１０００〜１０１４および１０１８〜１０２２に関してより詳細に説明してある。その後、通常のｌｏｇｒｅｄｏ処理が進められる（ステップ１３０６）。ファイル・システムに関連付けられているジャーナル・ログが読み込まれる。ファイル・システムでは、データベースのジャーナル技法を使用して、ファイル・システム・メタデータへの変更をジャーナル・ログ中で常に把握しておくことによって、ファイル・システムの構造的整合性を維持する。ログ・レコードは再生される。各ログ・レコードは、ファイル・システム・メタデータへの変更についての情報を含んでいる。ログ・レコードを再生することにより、ファイル・システム・メタデータはログ・レコードに従って変更される。ログの最後から始まって後ろ向きに進むログ・レコードはすべて、最後の同期点まで再生される。次に、ｌｏｇｒｅｄｏがＣＯＷ操作またはＣＯＤ操作によってファイル・システムを変更するかどうか判断が行われる（ステップ１３０８）。ｌｏｇｒｅｄｏが、ＣＯＷ操作またはＣＯＤ操作によってファイル・システムを変更しない場合、ｓＭａｐページのバッファリングされた書き込みを、あればすべてディスクへとフラッシュすることにより、スナップショットはクローズされ（ステップ１３１０）、プロセスはその後で終了する。
【００５６】
ステップ１３０８に戻って、ｌｏｇｒｅｄｏが、ＣＯＷ操作またはＣＯＤ操作によってファイル・システムを変更する場合、ファイル・システム・ブロックがすでにスナップショットにコピーされているかどうかのランタイム検査が行われる（ステップ１３１２）。ｆｓｃｋコードの図と同様に、ステップ１３１２は図９および１０で前に説明したプロセスと同等のものである。次いで、プロセスは上で説明したステップ１３０６に進む。
【００５７】
このようにして、本発明は、システム・クラッシュから回復し、ファイル・システムの本発明のプロセスによって作成されたスナップショットを保存するための改善された方法、装置、およびコンピュータ・プログラムを提供する。本発明の機構により、ファイル・システムのスナップショットが動的に更新される。メタデータは、ファイル・システム内で変更が施されるデータ・ブロックについてのスナップショットに含まれている。これらの例では、変更は、ファイル・システム内のデータ・ブロックに対する書き込み操作および削除操作である。そのような操作が施されるデータ・ブロックは、ファイル・システム内のデータ・ブロックに対して実行される変更操作より前にスナップショットにコピーされる。さらに、データ・ブロックの変更前のファイル・システム内での場所やデータ・ブロックのスナップショット内での場所などのデータが、スナップショットには含まれている。データ・ブロックについてのメタデータは、そのデータ・ブロックがスナップショットに書き込まれる前に、スナップショットに書き込まれる。スナップショットに書き込まれたデータ・ブロックは、スナップショットが作成されたときにファイル・システムに存在していた通りの、そのデータ・ブロックの「変更前イメージ」を表している。ファイル・システム内のデータ・ブロックの変更は、そのデータ・ブロックのメタデータおよび変更前イメージのスナップショットへの書き込みの後に生じる。この変更の結果、そのデータ・ブロックの「変更後イメージ」バージョンが生じる。ファイル・システムの状態を、スナップショットが作成されたときの状態に復元することが望ましい場合、スナップショットを使用して復元を行うことが可能である。
【００５８】
本発明の説明を完全に機能するデータ処理システムの状況で行ってきたが、本発明の方法がコンピュータ可読媒体の形式および様々な形式での配布に堪えること、および本発明が配布を実施するのに実際に使用される信号担持媒体の特定の型にかかわらず等しく適用されることは、当業者には理解されるであろうことに留意されたい。コンピュータ可読媒体の例は、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ならびに、たとえば無線周波数および光波伝送などの伝送形式を用いる、デジタルおよびアナログ通信リンク、有線または無線通信リンクなどの伝送型媒体を含む。コンピュータ可読媒体は、特定のデータ処理システムでの実際の使用のために復号化される符号化されたフォーマットの形式をとることもできる。
【００５９】
本発明の説明は、例示および説明の目的で提示されており、網羅的であることまたは開示した形式の発明に限定することを意図するものではない。多くの修正形態および変形形態が当業者には明らかであろう。実施形態の選択および説明は、本発明の原理、現実的用途を最もよく説明し、予想される特定の使用に適した様々な修正を伴う様々な実施形態に関して、当業者が本発明を理解できるようにすることを目的としている。
【図面の簡単な説明】
【００６０】
【図１】本発明の好ましい一実施形態による、本発明を実施できるデータ処理システムの外観を示す図である。
【図２】本発明を実施できるデータ処理システムの構成図である。
【図３】本発明の好ましい一実施形態による、ファイル・システムのスナップショットを作成および管理するのに使用するコンポーネントを示す図である。
【図４】本発明の好ましい一実施形態によるスナップショット・メタデータの図である。
【図５】本発明の好ましい一実施形態によるファイル・システムのスナップショットの先頭部分を示す図である。
【図６】本発明の好ましい一実施形態によるスナップショット・マップ内のスナップショット・マップ・グループの図である。
【図７】本発明の好ましい一実施形態によるスナップショット・マップ・グループ内のスナップショット・マップ・ページの図である。
【図８】本発明の好ましい一実施形態によるセグメントを示す図である。
【図９】本発明の好ましい一実施形態に従ってファイル・システムのスナップショットを更新するプロセスの流れ図である。
【図１０】本発明の好ましい一実施形態に従ってファイル・システムのスナップショットを更新するプロセスの流れ図である。
【図１１】本発明の好ましい一実施形態に従って回復手続きを開始するプロセスの流れ図である。
【図１２】本発明の好ましい一実施形態に従ってファイル・システムを検査するプロセスの流れ図である。
【図１３】本発明の好ましい一実施形態に従ってファイル・システムに対するファイル・システム・チェック回復プロセスを実行するプロセスの流れ図である。
【図１４】本発明の好ましい一実施形態に従ってファイル・システム・ジャーナル・ログに関してｌｏｇｒｅｄｏ回復プロセスを実行するプロセスの流れ図である。
【図１】
2005228329.tif 000003
【図２】
2005228329.tif 000004
【図３】
2005228329.tif 000005
【図４】
2005228329.tif 000006
【図５】
2005228329.tif 000007
【図６】
2005228329.tif 000008
【図７】
2005228329.tif 000009
【図８】
2005228329.tif 000010
【図９】
2005228329.tif 000011
【図１０】
2005228329.tif 000012
【図１１】
2005228329.tif 000013
【図１２】
2005228329.tif 000014
【図１３】
2005228329.tif 000015
【図１４】
2005228329.tif 000016