(57)【要約】【課題】トランザクション用にメタデータ・ディスク構成内のマップ・エクステントおよびアンマップ・エクステントの自動更新を提供する。【解決手段】トランザクションは、マップ・エクステントの変更およびアンマップ・エクステントの変更を含む。マップ・エクステントの変更は、１０ＭＢのメタデータ・データディスク領域のどこでも起こり得るし、アンマップ・エクステントの変更も同様である。ライト・ジャーナルは、すべての移行に追加される。移行ごとにトランザクションが作成され、トランザクションはマップ変更およびアンマップ変更を含む。リブート後、ライト・ジャーナルが適用される。より優れたデータの整合性を提供するために、ブロック・レベルのシーケンス番号、ブロック番号およびＣＲＣが２次コピーおよび１次コピー用に維持される。【選択図】図１
2013143124.tif 000002
【特許請求の範囲】
【請求項１】
階層ドライブ・システムのためのスワップ処理においてメタデータを永続化する方法であって、
カレント・トランザクション・エントリを作成し、
前記トランザクション・エントリに、マップ情報およびアンマップ情報を含むエクステント情報と言われる、メタデータの変更を追加し、
ライト・ジャーナルが前記カレント・トランザクション・エントリを前記ライト・ジャーナル内の次の空きエントリ位置へ書き込むことにより、前記トランザクション・エントリを前記メタデータのディスク領域にフラッシュし、
影響を受けたブロック用の前記カレント・トランザクションのメタデータ情報に基づいて、前記メタデータ・モジュールが前記メタデータ領域を更新する、ことを含む方法。
【請求項２】
すべてのメタデータ・ブロック用のＣＲＣ、シーケンス番号およびブロック番号を計算すること、ならびに１次コピーおよび２次コピーを保持することをさらに含む、請求項１に記載の方法。
【請求項３】
前記階層ドライブ・システムがＲＡＩＤシステムである、請求項１に記載の方法。
【請求項４】
トランザクション・エントリをフラッシュした後で階層ドライブへの停電が起きたときには、ライト・ジャーナルを介して前記マップ情報およびアンマップ情報を復旧することをさらに含む、請求項１に記載の方法。
【請求項５】
階層ドライブ・システムの階層間でデータを移動するときにメタデータを永続化するシステムであって、
ホスト・コンピュータと、
複数のエクステントの情報を含むメタデータ・モジュールと、
ライト・ジャーナルと、を含み、
カレント・トランザクション・エントリが前記ホスト・コンピュータによって作成され、エクステント情報が前記トランザクション・エントリに追加され、前記トランザクション・エントリが前記メタデータ・モジュール内のメタデータにフラッシュされ、前記トランザクションが前記ライト・ジャーナル内の待ち行列に入れられ、前記ライト・ジャーナルが前記カレント・トランザクション・エントリを次の空きエントリ位置に書き込み、前記メタデータ・モジュールが、前記カレント・トランザクションのメタデータ情報に基づいて前記メタデータを更新し、影響を受けたあらゆるデータのブロックをフラッシュする、システム。
【発明の詳細な説明】
【背景技術】
【０００１】
階層的記憶管理（ＨＳＭ）は、高コスト記憶媒体と低コスト記憶媒体−ホット層とコールド層の間で、データを自動的に移動させるデータ記憶技法である。ＨＳＭシステムは、ハードディスク・ドライブ・アレイなどの高速記憶装置が、光ディスクおよび磁気テープ・ドライブなどの低速装置よりも、（格納バイト当たりで）高価であるために存在する。ＨＳＭシステムは、大容量の企業データを低速装置に格納し、次いで必要なときにデータを高速ディスク・ドライブにコピーする。事実上、ＨＳＭは、高速ディスク・ドライブを低速大容量記憶装置用のキャッシュに変えてしまう。ＨＳＭシステムは、データの使われ方を監視し、どのデータが安全に低速装置へ移動できるか、および、どのデータが高速装置に留まるべきかに関して最良の推測を行う。通常のＨＳＭのシナリオでは、頻繁に使用されるデータファイルはディスク・ドライブに格納されるが、一定時間、通常数ヶ月使用されないと、最終的にテープに移行される。ユーザがテープ上にあるファイルを再び使用するときは、そのファイルは自動的にディスク記憶装置に戻される。ＨＳＭの利点は、格納データの総量が、利用可能なディスク記憶装置の容量よりもはるかに大きくなり得ることであるが、ほとんど使用されないファイルだけがテープ上にあるため、ほとんどのユーザは通常いかなる減速にも気付くことはない。ＨＳＭは階層型記憶装置と呼ばれることもある。ＨＳＭ（最初はＤＦＨＳＭ、現在はＤＦＳＭＳｈｓｍ）は、データ記憶装置のコストを削減し、低速媒体からのデータの検索を単純化するために、ＩＢＭにより彼らのメインフレーム・コンピュータに初めて実装された。ユーザは、データがどこに格納されたか、およびそれをどのように取り戻すかを知る必要がなく、コンピュータが自動的にデータを検索する。ユーザにとっての唯一の相違は、データが戻される速度であった。後に、ＩＢＭは、ＨＳＭを彼らのＡＩＸオペレーティング・システムに移植し、次いでＳｏｌａｒｉｓ、ＨＰ−ＵＸおよびＬｉｎｕｘなどの、他のＵｎｉｘライクなオペレーティング・システムに移植した。また、ＨＳＭは、ＤＥＣのＶＡＸ／ＶＭＳシステムおよびＡｌｐｈａ／ＶＭＳシステムに実装された。最初の実装日時は、ＶＭＳシステム実装マニュアルまたはＶＭＳ製品記述パンフレットから容易に特定されるべきである。最近、シリアルＡＴＡ（ＳＡＴＡ）ディスクの開発が、３段式ＨＳＭ（データが高性能なファイバチャネル・ストレージ・エリア・ネットワーク・デバイスから、若干低速だがかなり安価な、合計数テラバイト以上のＳＡＴＡディスク・アレイに移行され、次いで最終的にＳＡＴＡディスクからテープに移行される）の大きな市場を創出した。ＨＳＭにおける最新の開発は、ハードディスク・ドライブおよびフラッシュメモリを用いるものであり、フラッシュメモリはディスクより３０倍を超えて高速であるが、ディスクはフラッシュメモリよりかなり安価である。
【発明の概要】
【０００２】
したがって、本発明の実施形態は、階層ドライブ・システムのためのスワッピング処理において、メタデータを永続化する方法を含むことができる。この方法は、カレント・トランザクション・エントリを作成することと、トランザクション・エントリへのメタデータの変更、すなわちマップ情報およびアンマップ情報を含むエクステント情報を追加することと、ライト・ジャーナルがカレント・トランザクション・エントリをライト・ジャーナル内の次の空きエントリ位置へ書き込むことにより、トランザクション・エントリをメタデータのディスク領域にフラッシュすることと、影響を受けたブロック用のカレント・トランザクションのメタデータ情報に基づいて、メタデータ・モジュールがメタデータ領域を更新することを含むことができる。
【０００３】
さらに、本発明の実施形態は、階層ドライブ・システムの階層間でデータを移動させるときにメタデータを永続化するためのシステムを含むことができる。このシステムは、ホスト・コンピュータと、メタデータ・モジュール、すなわち複数のエクステントの情報を含むモジュールと、ライト・ジャーナルとを含むことができる。カレント・トランザクション・エントリがホスト・コンピュータによって作成され、エクステント情報がトランザクション・エントリに追加される。トランザクション・エントリがメタデータ・モジュール内のメタデータにフラッシュされる。トランザクションがライト・ジャーナル内の待ち行列に入れられ、ライト・ジャーナルがカレント・トランザクション・エントリを次の空きエントリ位置に書き込む。メタデータ・モジュールがカレント・トランザクションのメタデータ情報に基づいてメタデータを更新し、影響を受けたあらゆるデータのブロックをフラッシュする。
【図面の簡単な説明】
【０００４】
【図１】階層ドライブの構成を示す図である。
【図２】仮想のマップ・エクステントおよびアンマップ・エクステントを示す図である。
【図３】マップ・エクステント・テーブルおよびアンマップ・エクステント・テーブルを示す図である。
【図４ａ】ＴＤ構成の例を示す図である。
【図４ｂ】図４ａの初期マップ・エクステント・メタデータの詳細を示す図である。
【図４ｃ】図４ａの初期アンマップ・エクステント・メタデータの詳細を示す図である。
【図４ｄ】図４ｂおよび図４ｃにおいてＴＤエクステント０をアンマップ・エクステントにホット・スワップするメタデータ・エントリの変更を示す図である。
【図４ｅ】ＴＤエクステント２をアンマップ・エクステントにホット・スワップするメタデータ・エントリの変更を示す図である。
【図４ｆ】ＴＤエクステント１７をコールド・スワップするメタデータ・エントリの変更を示す図である。
【図４ｇ】ＴＤエクステント０をコールド・スワップするメタデータ・エントリの変更を示す図である。
【図４ｈ】ＴＤエクステント２をコールド・スワップするメタデータ・エントリの変更を示す図である。
【図５】メタデータ設計のデータ構造を示す図である。
【図６】ディスク上のメタデータのデータ・フォーマットを示す図である。
【図７】ディスク上のメタデータの構成を示す図である。
【図８】メタデータ・モジュールと他のモジュールとのインタフェースを示す図である。
【図９】スワップ処理用のトランザクション・エントリの状態図である。
【発明を実施するための形態】
【０００５】
概念的に、ＨＳＭはほとんどのコンピュータのＣＰＵにおいて見られるキャッシュと似ており、ほとんどのコンピュータのＣＰＵでは、非常な高速で動作する少量の高価なＳＲＡＭメモリが、頻繁に使用されるデータを格納するために使用されるが、新しいデータをロードしなければならないとき、最も長い間使われていないデータが、低速だが非常に大きなメインＤＲＡＭメモリへと移される（ｅｖｉｃｔ）。
【０００６】
データは多くの理由で移行される。いくつかの理由は情報の価値の変化に関係しており、他の理由はさまざまな基本原理に関係している。
【０００７】
１ＴＢのホット層サイズ用のメタデータ（マップ・エクステントおよびアンマップ・エクステント）を保持するために、メタデータは、一般に、一定の大きさをもつホット層の仮想ドライブ（ＶＤ）の内部に保持される。メタデータ（マップおよびアンマップ）は、スワッピング処理中、ホット層ＶＤの領域内部のどこでも変更することができる。リブート後のデータの整合性を維持するために−スワップ処理では−、マップ再配置情報およびアンマップ情報は、原子的な方式でディスク領域の内部に維持（永続化）されるべきである。このことは、マップ情報が更新されアンマップ情報が更新されないと、または一部のマップ情報が更新されると、データ破壊が起きることを意味する。２５６Ｋのブロックがメタデータをディスクに書き込むために利用されると、データ破壊が続いて起こり得る。スワップ処理ごとにマップ・データおよびアンマップ・データをディスクに書き込むことは、全領域を更新する必要があるので、領域の無駄な使用を伴う。ホット層のライフサイクルは、全領域への継続的な書き込みが原因で減少する。
【０００８】
したがって、本発明の実施形態は、階層化のためのシステムおよび方法、たとえばＬＳＩ製ＭｅｇａＲＡＩＤカード内部のＬＳＩ製Ｃａｃｈｅｃａｄｅのシステムおよび製品を介した階層化のためのシステムおよび方法を含むことができる。この実施形態は、ＰＣＩベースのＲＡＩＤアダプタ内部の階層化を含む。階層ドライブ（ＴＤ）を作成することができ、これはホストからは仮想ドライブ（ＶＤ）のように見える。ＴＤの内部で、データは、ＳＡＳ、ＳＡＴＡハードディスク（コールド層）などの低速ドライブか、ＳＡＳ、ＳＡＴＡ  ＳＳＤドライブ（ホット層）のような比較的高速なドライブのどちらかにコピーされる。ＴＤ上のＩＯは、そのアクセスがホストの読み書き性能の加速を必要とするなら、ホット層のドライブに移動する。ＳＳＤドライブを性能向上に利用することが可能な場合、ＤＲＡＭへのデータ・キャッシングなどのさまざまな方法があり得るが、高速記憶媒体の容量は、ユーザには利用可能でない可能性がある。ＳＳＤの容量はＴＤに含まれ、階層化はホストのＩＯ性能を加速させる。ＣａｃｈｅｃａｄｅおよびＬＳＩ製ＭｅｇａＲＡＩＤカードは例示目的で使用されるので、これらより性能の高いものにも適用可能であることを当業者は理解するであろう。
【０００９】
本発明の実施形態において、データは、エクステントと呼ばれるデータ・ユニットを単位として、階層間を移動する。エクステントは、階層化処理で使用される連続ブロックのデータを含むデータ・セットである。コールド層データは、より少ない頻度でアクセスされ、そのため当分の間比較的重要ではないデータであると考えられ得るデータである。ホット層データは、より高い頻度でアクセスされ、そのため当分の間比較的重要なデータであると考えられ得るデータである。階層化モジュールは、階層ドライブの相異なる階層間でデータをスワップする。１ＭＢのエクステント・サイズは、移動のデータ・ユニットとして使うことができ、ＴＤのエクステントの再配置された位置（マップ・データおよびアンマップ・データ）を保持するためにメタデータ・インタフェースを使用する。階層化機能は、２つの基本的なスワップ処理−コールド・スワップおよびホット・スワップ−を有する。スワップ処理は、アンマップ領域−ホット層上またはコールド層上であり得る−からアンマップ・エクステントを取り出し、ホット層またはコールド層の元の位置からデータを移動し、マップされた新しい位置を更新し、元のエクステントをアンマップされたとして更新する。コールド・スワップ処理は、ホット・エクステントからコールド・エクステントへデータを移動し、このデータ移動に関連したマップ・メタデータ・セクションおよびアンマップ・メタデータ・セクションを更新する。コールド・スワップでは、コールド層のアンマップ領域が使用される。ホット・スワップ処理は、コールド・エクステントからホット・エクステントへデータを移動し、このデータ移動に関連したマップ・メタデータ・セクションおよびアンマップ・メタデータ・セクションを更新する。ホット・スワップでは、ホット層のアンマップ領域が使用される。
【００１０】
本発明の実施形態において、３つのタイプのエクステントが存在する。仮想エクステントは、コールド層エクステントのトラッキング情報を記録するために利用される。マップ・エクステントは、ホット層のマップ情報を保持するために利用され、アンマップ・エクステントは、ＴＤのアンマップ・エクステント情報を保持するために利用される。ＴＤホット層サイズの５％が、ＴＤの作成中、アンマップ・エクステント用に確保される。この５％はユーザが利用することはできない。移行後、このアンマップ領域は、コールド層領域またはホット層領域の中に存在することができる。このように、全体としてＴＤサイズの５％がアンマップ・エクステント用に確保される。スワップされるエクステントは、反対の層の上のアンマップ・エクステントにコピーされる（たとえばホット・エクステントがアンマップ・コールド・エクステントに移動する）。このことは、スワップ処理の回数を削減し、データ破壊を回避する。たとえ停電がスワップ処理の後に発生しても、メタデータがマップ位置およびアンマップ位置に更新されるまで、データはその元の位置に置かれる。アンマップ・エクステント用に確保される空き領域の割合は、性能要求に応じて変化することができる。
【００１１】
本発明の実施形態において、１ＴＢホット層サイズ用のメタデータ（マップ・エクステントおよびアンマップ・エクステント）を保持するために、約１０ＭＢが必要になる。そのメタデータは、ホット層ＶＤの内部に保持される。メタデータのディスク構成は、ヘッダ、ジャーナル領域、マップ領域およびアンマップ領域を有する。メタデータ（マップおよびアンマップ）の変更は、スワップ処理に基づいて、ホット層ＶＤの１０ＭＢ領域内部のどこでも起こり得る。スワップ処理では、リブート後のデータの整合性を保証するために、マップ再配置情報およびアンマップ情報は、原子的な方式でディスクの内部に永続化されるべきである。このことは、マップ・データが更新されアンマップ・データが更新されないと、またはマップ・データが部分的に更新されると、データ破壊が起きるであろうことを意味する。本発明の実施形態においては、スワップ処理ごとにトランザクションが作成される。このトランザクションは、マップ・エクステントおよびアンマップ・エクステントを更新する前に、ジャーナル領域に書き込まれる。
【００１２】
図１は、階層ドライブの構成図である。階層ドライブ１００は、複数のドライブ・レベル１１０を示す。ＴＤはＶＤ上に作成され、新しい論理ドライブとしてホストに紹介される。ＶＤの作成は当技術分野では既知である。ＴＤの最上層は、コールド層またはコールドＶＤを表す。本発明の実施形態においては、複数のコールドＶＤ１２０が存在する。ＴＤの最下層は、ホット層またはホットＶＤを表す。本発明の実施形態においては、複数のホットＶＤ１３０が存在する。コールドＶＤ１２０とホットＶＤの間には、ポリシーの基本設定に応じて重要度にコールドからホットまでの幅がある、複数の中間ＶＤ１４０が存在する。
【００１３】
データの移行ごとにトランザクションが作成される。本記述で説明したように、このトランザクションは、マップ変更およびアンマップ変更を含むことができる。新しいトランザクションは、スワップ処理ごとに作成され得る。トランザクションは、マップ・エクステント変更およびアンマップ・エクステント変更を含む。ライト・ジャーナルがすべての移行に追加され得る。リブート後、ライト・ジャーナルは、メモリ内のメタデータ領域およびメタデータのディスク領域に適用される。データの整合性を向上させるために、ブロック・レベルのシーケンス番号およびＣＲＣを、２次コピーおよび１次コピー用に維持することができる。
【００１４】
メタデータ・マネージャは、メタデータを１つずつまたはサイズ２５６Ｋの連続ブロックで、ディスク上に書き込む。ブロックのサイズは、ホット層の仕様に応じた性能要求のために、増加または減少させることができる。トランザクションが複数のブロックにわたって広がると、停電が発生した場合メタデータは整合性のない状態になり、データ破壊をまねく可能性がある。メタデータ・ジャーナルを実装することにより、トランザクション・レコードは、永続的な記憶領域、たとえばメタデータ領域内に確保された空き領域に記録され、ブートアップ中にジャーナル・エントリを適用することができ、それによってメタデータ更新の自動性を実現することができる。本発明の実施形態においては、ジャーナルのコピーが１つだけ維持される。ジャーナル・エントリが利用できない、またはその他の方法で読むことができないと、ＴＤ全体がオンラインにならない。
【００１５】
図２は、仮想のマップ・エクステントおよびアンマップ・エクステントを示す図である。コールドＶＤ１２０は、少なくとも１つであって、複数の可能性もある仮想エクステント１２２を含む。これらの仮想エクステント１２２は、１ＭＢのエクステント・サイズになることができ、ホット・スワップ用に記録することができる。ホットＶＤ１３０は、少なくとも１つであって、複数の可能性もあるマップ・エクステント１３２を含む。これらのマップ・エクステント１３２は、１ＭＢのエクステント・サイズとすることができる。マップ・エクステント１３２は、移行後コールドＶＤエクステント用にマップされるか、または初期ボリューム作成中にホットＶＤエクステント用にマップされる。コールドＶＤ１２０とホットＶＤ１３０はそれぞれ、少なくとも１つであって、複数の可能性もあるアンマップ・エクステント１２４と１３４を含む。アンマップ・エクステント１２４と１３４は、１ＭＢのエクステント・サイズとすることができる。アンマップ・エクステント１２４と１３４は、スワップ（ホットまたはコールド）処理用に使用することができる。ＴＤホット層サイズの５％がアンマップ・エクステント用に確保される。
【００１６】
図３は、マップ・エクステント・テーブルおよびアンマップ・エクステント・テーブルを示す図３００である。マップ・エクステント・テーブル３１０は、ホットＴＤエクステント・インデックス番号３１２、ソースＴＤ整列エクステント３１４およびリンクＴＤ整列エクステント番号３１６を含む。アンマップ・エクステント・テーブル３２０は、ホットＴＤエクステント・インデックス番号３２２、ＬＤ番号３２４およびＬＤエクステント番号３２６を含む。
【００１７】
初期構成が作成されるとき、ソースＴＤ整列エクステント３１４はＴＤ整列エクステント番号３１２を含むことができ、リンクＴＤ整列エクステント番号３１６は無効になる。アンマップ・エクステント・テーブル３２０は、ホスト・データを何も有していないＴＤエクステントを含む。ＴＤホット層サイズの５％がアンマップ・エクステント用に確保され、この５％はＴＤの作成中ユーザが利用することはできない。移行後、アンマップ領域はコールド層またはホット層に位置することができる。アンマップ・エクステント・テーブルのサイズは、ＬＤターゲット番号およびＬＤエクステント番号の代わりに、ＴＤ整列エクステントを保持することによって削減することができると理解される。
【００１８】
コールド・スワップ処理およびホット・スワップ処理は、バックグラウンド処理である。コールド・スワップは、ホットＶＤエクステント領域からアンマップ・コールド・エクステント領域へのデータの移行であり、それに応じてマップ・エクステントおよびアンマップ・エクステント用のメタデータを更新する。同様に、ホット・スワップは、コールド層からホット層へのデータの移行であり、メタデータ情報を更新する。現在ホット層にあるコールド層の線形マップ・エクステント・データを、システムがコールド層に戻したい場合、コールド層の元の線形マップ位置に戻される。たとえば、１５ＭＢのコールド層および１７ＭＢのホット層を有するＴＤを考察されたい。構成を理解するために、２つのアンマップ・エクステントを、１つの別のアンマップ・エクステントになるように結合する。１ＴＢのホット層サイズには、１８ＭＢのメタデータが必要とされる（マップ・エクステント用に８ＭＢ、アンマップ・エクステント用、１次データおよび２次データそれぞれのヘッダ用に４１０ＫＢ）。図４ａはＴＤ構成の例である。ＴＤ構成４００は、ＴＤ整列エクステント番号４１０、エクステント情報４２０およびＬＤ情報４３０の列から構成される。ＴＤのサイズは、ＶＤ（仮想エクステント４４０、マップ・エクステント４５０、アンマップ・エクステント４６０およびメタデータ４７０）のサイズの合計からアンマップ・エクステント４６０のサイズおよびメタデータのサイズを引いたものである。３０ＭＢである図４ａのＴＤの場合、ＴＤサイズは３３ＭＢ−２ＭＢ−１ＭＢ＝３０ＭＢである。
【００１９】
図４ｂは、図４ａの初期マップ・エクステント・メタデータの詳細を示す。ソースＴＤ整列番号４１０が図４ａのソースＴＤ整列番号（１６〜２９）に対応する。マップ・インデックス４１２は、０から１５までである。図４ｃは、図４ａの初期アンマップ・エクステント・メタデータの詳細を示す。アンマップ・インデックス４１２は、０から１までである。
【００２０】
図４ｄは、図４ｂおよび図４ｃのＴＤエクステント０をアンマップ・エクステントにホット・スワップする、エントリ変更を示す。４１２のインデックス１４は、図４ｂのインデックス１４と関連しており、４１２のインデックス０は、図４ｃのインデックス０と関連している。
【００２１】
図４ｅは、アンマップ・エクステントへのＴＤエクステント２のホット・スワップを示す。マップ・エントリの変更は、４１２のインデックス１５に示される。アンマップ・エントリの変更は、４１２のインデックス１に示される。
【００２２】
図４ｆは、ＴＤエクステント１７のコールド・スワップを示す。マップ・エントリの変更は、４１２のインデックス１および１４に示される。アンマップ・エントリの変更は、４１２のインデックス０に示される。
【００２３】
図４ｇは、ＴＤエクステント０のコールド・スワップを示す。マップ・エントリの変更は、４１２のインデックス１４および１５に示される。アンマップ・エントリの変更は、４１２のインデックス１に示される。この例には、２つの移行処理が存在する。第１の処理は、既存のコールド・データを次の使われていないコールド空き領域へ移動させるというものである。第２の処理は、ＴＤエクステント０のホット領域をコールド領域へ移動させるというものである。
【００２４】
図４ｈは、ＴＤエクステント２のコールド・スワップを示す。示されている例では、ＴＤエクステント２は現在ホットに存在する。マップ・エントリの変更は、４１２のインデックス１および１５に示される。アンマップ・エントリの変更は、４１２のインデックス０に示される。この例には、２つの移行処理が存在する。第１の処理は、リンク・エクステントをその次のアンマップ・コールド位置へ移動させるというものである。コールドにはアンマップ位置がないため、リンク・エクステントは、他のどこかへ移動する代わりにその元の位置へ行く。ＴＤエクステント１７がホット・エクステント１４へ移動し、コールド・エクステント２のその元の位置へのスワップが回避されると、空きホット・エクステントの数が失われる可能性がある。本発明の目的は、コールド・エクステント２の移動によっては満足されない。エクステント１７をその元の位置へ移動させる代わりに、ＴＤエクステント１７はホット１４へ移動するので、処理を複雑にする。本発明の本実施形態においては、エクステントがそのマップ位置からその元の（ホットまたはコールド）位置へ移動するとき、処理は単純に保たれる。第２の処理は、ＴＤエクステント２をその元のコールド位置へ移動させるというものである。
【００２５】
本発明の実施形態において、仮想エクステントは、ホット領域への移動用のアクセス・カウントに基づいて記録される。使用されるアクセス・カウントは、トラッキング情報または他の情報になることができる。同様に、マップ・エクステント（ホット領域）は、コールド領域への移動用のアクセス・カウントに基づいて記録される。仮想エクステントの用意ができると、すなわちエクステントがホット領域へ移動するために十分な数のアクセス・カウントを取得すると、マップ・エクステントの割り当て後ヒート・インデックス・バケットへ入る資格が与えられる。最長時間未アクセス・リストがエクステントのアクセスを記録する。
【００２６】
図５は、メタデータ設計のデータ構造を示す。メタデータ設計５００は、マップ構造５１０、アンマップ構造５２０および移行モデル５３０を含む。５１０の構造体ｔｍ＿ｍｅｔａｄａｔａ＿ｍａｐｐｅｄ＿ｅｘｔｅｎｔ＿ｄａｔａ＿ｔは、移行コンポーネントからメタデータ・モジュールへデータを渡すために使用される。また、それはマップ・エクステント情報用のディスク・データ・フォーマット上にある。５２０の構造体ｔｍ＿ｍｅｔａｄａｔａ＿ｕｎｍａｐｐｅｄ＿ｅｘｔｅｎｔ＿ｄａｔａ＿ｔは、移行コンポーネントからメタデータ・モジュールへデータを渡すために使用され、また、アンマップ・エクステント情報用のディスク・データ・フォーマット上にある。
【００２７】
構造体ｔｍ＿ｍｅｔａｄａｔａ＿ｅｘｔｅｎｔ＿ｉｎｆｏ＿ｔは、「プット」および「ゲット」の処理用に、移行マネージャから渡される。前に述べたように、ｍｅｔａｄａｔａ＿ｔａｂｌｅ＿ｉｎｄｅｘフィールドは、マップ配列またはアンマップ配列へのインデックスを有する。フィールドｉｓ＿ｍａｐｐｅｄ＿ｅｘｔｅｎｔは、移行モジュールがマップ・エクステント情報を要求すると、「真」を含む。ｍａｐｐｅｄ＿ｄａｔａはマップ・エクステント情報を有し、ｕｎｍａｐｐｅｄ＿ｅｘｔｅｎｔはアンマップ・エクステント情報を含む。移行モジュールは、ｍｉｇｒａｔｉｏｎ＿ｔａｇを渡す。その後、移行モジュールは、メタデータの更新をキャンセルするために、ｍｉｇｒａｔｉｏｎ＿ｔａｇを使用することができる。これはロールバック・セマンティクスを可能にする。
【００２８】
図６は、ディスク上のメタデータのデータ・フォーマットを示す。オンディスク・データ構造６００は、マップ構造６１０、マップ・ブロック用およびアンマップ・ブロック用のブロック・ヘッダ構造６２０、メタデータ・ヘッダ構造６３０、ジャーナル構造６４０、ジャーナル・ブロック・ヘッダ構造６５０ならびにアンマップ構造６６０を含む。
【００２９】
図７は、ディスク上のメタデータの構成を示す。構成７００は、メタデータ・ヘッダ・ブロック７１０、ライト・ジャーナル領域７２０、マップ・エクステント領域７３０およびアンマップ・エクステント領域７４０を含む。ＴＤ永続データ（ＤＤＦデータ）は、ＶＤ内部のメタデータ領域へのポインタを有する。このポインタは、図７ではＸと呼ばれる。７１０のｔｍ＿ｍｅｔａｄａｔａ＿ｈｄｒ＿ｔは、メタデータ構成の開始時に確保される。次の２５６Ｋブロックがライト・ジャーナル７２０用に確保され、ｔｍ＿ｍｅｔａｄａｔａ＿ｊｏｕｒｎａｌ＿ｂｌｏｃｋ＿ｈｄｒ＿ｔは、図７に示すようにＸ＋２５６Ｋに書かれる。その後、ｔｍ＿ｍｅｔａｄａｔａ＿ｊｏｕｒｎａｌ＿ｅｘｔｅｎｔ＿ｉｎｆｏ＿ｔのメタデータ配列は永続化される。メタデータ・マップ・セクションは、Ｘ＋２５６Ｋ＋２５６Ｋから始まり、すべての２５６Ｋブロックは、ｔｍ＿ｍｅｔａｄａｔａ＿ｂｌｏｃｋ＿ｈｄｒ＿ｔから始まる。ｔｍ＿ｍｅｔａｄａｔａ＿ｂｌｏｃｋ＿ｈｄｒ＿ｔは、そのブロックに関連するＣＲＣおよびシーケンス番号を有する。アンマップ・セクションの残りの部分は、ｔｍ＿ｍｅｔａｄａｔａ＿ｕｎｍａｐｐｅｄ＿ｅｘｔｅｎｔ＿ｄａｔａ＿ｔの配列としてマップされる。ブロック・サイズである２５６Ｋは一例として使用されている。これは、ＳＳＤドライブの場合、性能が向上しているからである。しかしながら、より良い性能、書き込み耐久性および寿命のために選ばれた、さまざまなＶＤサイズに最適化するために、異なるブロック・サイズが選択可能であることが理解される。すべてのブロックのシーケンス番号、ＣＲＣ、マジック、ブロック番号は、リブート中、ブロック・エントリを検証するために利用される。１次記憶装置または２次記憶装置から正しいブロックが選択される。
【００３０】
メタデータ・ヘッダも、１次記憶装置または２次記憶装置を区別するため、かつメタデータ・ブロックを識別するために、マジック、番号のフィールドを有する。ヘッダは、マップ・エントリの数、アンマップ・エントリの数およびジャーナル開始アドレスを保持するためのフィールドを含む。フィールドｔｄ＿ｅｘｔｅｎｔ＿ｓｉｚｅは、外部インポート用に使用される。
【００３１】
本発明の実施形態において、以下が図８のメタデータの処理である。
【００３２】
ｔｍ＿ｍｅｔａｄａｔａ＿ｉｎｉｔ
本発明の実施形態において、これは、モジュール・レベルでのメモリおよび他の資源の初期化のために、システム・ブート中に呼び出される。
【００３３】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｆｉｎｉ
本発明の実施形態において、これは、モジュール・レベルでのメモリおよび他の資源のクリーンアップのために、システム・シャットダウン中に呼び出される。
【００３４】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｉｎｉｔ
本発明の実施形態において、これは、ＴＤ内のホット層の一部であるＶＤを識別する。図７で言及したように、ホット層を形成するＶＤの内部に、メタデータの格納用空き領域を切り出す。作成時のＴＤサイズにかかわらず、ＴＤごとに１ＴＢまでのホット層２次記憶装置をサポートするために、ホット層上に十分な空き領域を事前に割り当てる。メタデータ・ヘッダは、コア・メモリで更新されるが、次のフラッシュが、ヘッダ、ジャーナル初期エントリおよびマップ／アンマップ初期エントリを一度フラッシュする。また、メモリのマップ、アンマップおよびジャーナル・バッファを割り当てることができる。
【００３５】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｌｏａｄ
本発明の実施形態において、これは、ＴＤがオンラインになったとき、またはリブート中に起動される。このアプリケーション・プログラミング・インタフェース（ＡＰＩ）は、ヘッダ、ジャーナル・エントリ、マップ・エントリおよびアンマップ・エントリを含むオンディスク・メタデータ構成をメモリの中に読み込む。また、これは、ブロック・レベルのシーケンス番号を使用して、メタデータの最新コピーを選択する。さらに、メモリ内の正しいデータを得るために、開始インデックスから始まり終了インデックスまでのジャーナル・エントリを再適用する。１次コピーおよび２次コピーを、検証されたコア内コピーで更新する。最後に、メタデータ更新の完了を示すために、呼び出し元から渡されたコールバック・プロシージャを起動する。コールバックは、他のコードへの引数として渡される、実行可能コードへの参照、または１本の実行可能コードである。これによって、低レベルのソフトウェア層が、高レベル層で定義されたサブルーチン（または関数）を呼ぶことが可能になる。
【００３６】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｇｅｔ
本発明の実施形態において、これは、ロードが起動された後のエクステント情報を、呼び出し元に渡す。
【００３７】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｐｕｔ
本発明の実施形態において、ホット／コールド・スワップ処理の後、移行モジュールは、このＡＰＩを使用して、メタデータのコア内領域のメタデータ変更を更新する。このモジュールは、カレント・トランザクションにエントリを追加する。
【００３８】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｆｌｕｓｈ
本発明の実施形態において、さまざまなエクステントに対するプット処理を完了させた後、移行モジュールは、これを使用して、Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｐｕｔを使用して渡されたメタデータを永続化するために、トランザクションを完了させる。移行モジュールは、カレント・トランザクションをライト・ジャーナル待ち行列に追加する。ディスク上のライト・ジャーナルの永続化が現在進行中でなければ、ライト・ジャーナルを開始する。おそらく、ライト・ジャーナルは、２５６Ｋのブロックを迅速に完了させる。ライト・ジャーナル・ブロックの完了後、トランザクションは、２５６Ｋブロック・サイズのメタデータ書き込みに移動する。変更されたブロックだけが、このトランザクションに書き込まれる。影響を受けたメタデータの更新を完了させた後、ライト・ジャーナルに保留中のトランザクションがあると、そのトランザクション用のジャーナル・エントリを開始する。特定のトランザクション用のすべての影響を受けたブロックを完了させた後、フラッシュ処理に渡されるコールバックを起動する。
【００３９】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｑｕｉｅｓｃｅ
本発明の実施形態において、このＡＰＩは、所与のＴＤ上のすべてのメタデータ・マネージャの処理が完了し、かつ新しいメタデータの処理が開始されるようにスケジュールされていないことを、保証するために呼ばれる。また、このＡＰＩは、バックエンドＶＤへのあらゆる未処理のＩＯが消去または終了されたことを保証するために、ＴＤの削除時に起動され得る。すべての保留中の処理が完了した後、コールバックはコールバック引数付きで呼び出される。
【００４０】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｄｅｌｅｔｅ
本発明の実施形態において、これは、マップ・エントリ、アンマップ・エントリおよびジャーナル・エントリ用の初期化中に割り当てられたメタデータ・バッファを解放する。
【００４１】
Ｔｍ＿ｍｅｔａｄａｔａ＿ｔｄ＿ｒｏｌｌｂａｃｋ
本発明の実施形態において、これは、移行モジュールに呼び出されて、ｍｉｇｒａｔｉｏｎ＿ｔａｇを渡したメタデータを削除する。
【００４２】
図９は、スワップ処理用のトランザクション・エントリの状態図である。スワップ処理９００は、トランザクション用にメタデータを更新するステップを示す。トランザクションは、変更されるマップ・エントリおよびアンマップ・エントリを含むスワップ処理について作成される。第１のステップ９１０において、カレント・トランザクション・エントリがない場合、ｔｍ＿ｍｅｔａｄａｔａ＿ｐｕｔ（プット）がトランザクションを作成する。次のステップ９２０において、プットがカレント・トランザクションに、エクステント情報エントリを追加する。次のステップ９３０において、フラッシュがトランザクションをジャーナル待ち行列に入れる。次のステップ９４０において、ｔｍ＿ｍｅｔａｄａｔａ＿ｆｌｕｓｈ（フラッシュ処理）がジャーナル・ライトを開始する。ステップ９４０のジャーナル・ライトは、ジャーナル・エントリおよびジャーナル・ブロック・エントリ９４５として図９に示される。次いで、この処理は、９５０でトランザクションをメタデータ・フラッシュ待ち行列に入れる。メタデータ・フラッシュ待ち行列の移動後、メタデータ・モジュールはトランザクションを取り出し、トランザクションのメタデータ情報に基づいてメタデータ領域（マップおよびアンマップ）のブロックを更新し、影響を受けたブロック９６０、９６５、９７０、９７５だけフラッシュする。ＣＲＣおよびシーケンス番号がすべてのブロックについて計算される。メタデータの１次領域および２次領域が更新される。メタデータのフラッシュが完了した後、９８０でスワップ処理が完了する。
【００４３】
リブート後、マップとアンマップ両方のメタデータ領域がディスクから読み込まれる。ジャーナル・トランザクション・エントリは、最古のジャーナル・エントリから順に適用される。すべてのブロック用のＣＲＣが計算され、すべてのメタデータ・ブロック用のシーケンス番号が更新される。次いで、ジャーナル・メタデータ領域が、次の更新用に消去される。更新されたメタデータ・ブロックは、メタデータ領域で永続化される。
【００４４】
カレント・トランザクションをメタデータ・フラッシュ待ち行列に移動するステップ９５０の後、メタデータの更新中に停電が発生した場合、マッピング情報はライト・ジャーナル・エントリによって復旧される。９３０でカレント・トランザクションをメタデータにフラッシュするステップの後、ステップ９４０のジャーナル・ライトの前に停電が発生すると、メタデータ・エントリは存在しない。この場合、元のエクステントがデータを有する。
【００４５】
メモリ内の位置にデータを書き込むことは、潜在的に他の位置を整合性のないデータに預ける可能性がある。この問題は、異なるアドレス空間用の非並行メモリ構成を使用することによって解決することができ、そうでなければ、メモリ（またはその一部）は、マッピング変更時にフラッシュされなければならない。また、ＣＲＣは巡回冗長検査である。これは、生データへの偶発的な変更を検出するために、デジタル・ネットワークおよび記憶装置で一般に使用されるエラー検出コードである。これらのシステムに入力されるデータのブロックは、その中身を多項式除算した結果の余りに基づいて、短いチェック値コンポーネントを付加される。検索に際し、計算が繰り返され、チェック値が一致しないと、想定されるデータ破壊に対して修正処置を取ることができる。通常、「チェック」値は、データに何の情報も追加しないような冗長量であり、アルゴリズムの実装は比較的単純である。フラッシングおよびＣＲＣの実装は、データの整合性を維持するために利用できる方法の例であることが、当業者によって理解される。更新シーケンス番号はデータの最新コピーを決定し、ブロック番号は追加データの整合性チェックを与え、１次および２次はブロック・レベルの障害から復旧するのを助ける。
【００４６】
本発明の前述した説明を、例示および説明を目的として提示してきた。前述の説明は、本発明のすべてを説明することや、本発明を開示した形そのものに限定することを意図したものではなく、他の修正形態および変形形態が上記教示に照らして実現可能であり得る。本実施形態は、本発明の原理およびその実際の応用を最適に説明するために選択かつ記載されており、したがって、考えられる特定の用途に適合されるさまざまな実施形態およびさまざまな修正形態において、当業者が本発明を最適に利用することが可能になる。従来技術によって制限される場合を除き、添付の特許請求の範囲が本発明の他の代替実施形態を含むと解釈されることが意図される。
【図１】
2013143124.tif 000003
【図２】
2013143124.tif 000004
【図３】
2013143124.tif 000005
【図４ｄ】
2013143124.tif 000006
【図４ｅ】
2013143124.tif 000007
【図４ｆ】
2013143124.tif 000008
【図４ｇ】
2013143124.tif 000009
【図４ｈ】
2013143124.tif 000010
【図５】
2013143124.tif 000011
【図６】
2013143124.tif 000012
【図７】
2013143124.tif 000013
【図８】
2013143124.tif 000014
【図９】
2013143124.tif 000015
【図４ａ】
2013143124.tif 000016
【図４ｂ】
2013143124.tif 000017
【図４ｃ】
2013143124.tif 000018