JP2015201204A - データ記憶装置におけるデータ保全性管理 - Google Patents

Abstract

【課題】データ記憶装置におけるデータ保全性管理のための装置および方法を提供する。【解決手段】コントローラは、ホスト装置とメインメモリとの間でユーザデータブロックを転送する。各ユーザデータブロックは、関連付けられる論理アドレス（ＬＢＡ）を有する。データ保全性マネージャ１３０は、各ユーザデータブロックに対する検証コード（ＶＣ）を生成し、ローカルメモリにおけるテーブル構造において記憶する。データ保全性マネージャ１３０は、検証コードを用いて、ホスト読出要求中に、選択されたユーザデータブロックの最新バージョンが、コントローラによって、メインメモリから取得されていることを独立して検証する。【選択図】図４

Description

発明の詳細な説明
概要
本開示のさまざまな実施例は、一般に、データ記憶装置におけるデータ保全性管理に向けられる。

いくつかの実施例では、コントローラはユーザデータのブロック（たとえばセクタ）をホスト装置とメインメモリとの間で転送する。各ユーザデータブロックは、関連付けられる論理アドレスを有する。独立したデータ保全性マネージャは、各ユーザデータブロック毎に検証コードを生成し、それをローカルメモリにおけるテーブル構造に記憶する。データ保全性マネージャはその検証コードを用いて、選択されたユーザデータブロックの最新バージョンがホスト読出要求中にメインメモリからコントローラによって取得されていることを独立して検証する。

さらなる実施例では、関連付けられる論理アドレスを有する入力されたユーザデータブロックが、メインメモリへの記憶のために受取られる。入力されたユーザデータブロックのユーザデータコンテンツおよびその関連付けられる論理アドレスに応答して、検証コードが生成される。検証コードはローカルメモリにおけるテーブル構造に記憶され、入力されたユーザデータブロックはメインメモリに記憶される。その後、入力されたユーザデータブロックのメインメモリからの取得を要求するホスト読出要求が受取られる。検証コードがローカルメモリにおけるテーブル構造から取得され、その取得された検証コードを用いて、選択されたユーザデータブロックの最新バージョンが、ホスト読出要求に応答してメインメモリからコントローラによって取得されていることを、独立して検証する。

本開示のさまざまな実施例を特徴付けるこれらおよび他の特徴は、以下の詳細な議論および添付の図面に鑑み理解され得る。

本開示のさまざまな実施例に従って動作するデータ記憶装置の機能ブロック図である。 いくつかの実施例に従う別のデータ記憶装置の機能ブロック図である。 いくつかの実施例に従って動作可能なフラッシュメモリモジュールの図である。 さまざまな実施例に従ってデータ保全スキームをサポートすることにおいて検証コードを生成し記憶するデータ保全性マネージャの図である。 ＩＯＥＤＣ（入力／出力エラー検出コード）値として特徴付けられる検証コードの生成の図である。 データ書込動作中においてデータ保全性マネージャによって実行されるステップを示す機能ブロック図である。 データ読出動作中においてデータ保全性マネージャによって実行されるステップを示す機能ブロック図である。 データ保全性マネージャによる使用のためのさまざまな検証コードを生成するよう動作する暗号法（暗号）ブロックの図である。 ＩＯＥＤＣ値の生成、およびその異なる部分を記憶装置内における異なるメモリ位置に記憶することの図である。 本開示のさまざまな実施例に従って実行されるステップの概要を与えるデータ処理ルーチンのためのフローチャート図である。 いくつかの実施例に従う検証テーブルデータ構造のための例を示す図である。 いくつかの実施例に従って実行されるステップを例示する入来読出コマンド処理ルーチンのためのフローチャート図である。 いくつかの実施例に従って実行されるステップを示すキャッシュアクセス処理ルーチンのためのフローチャート図である。 いくつかの実施例に従って実行されるステップを示す書込進行中処理ルーチンのためのフローチャート図である。 いくつかの実施例に従って実行されるステップを示す「同じ書込」処理ルーチンに対するフローチャート図である。 いくつかの実施例に従って実行されるステップを示す書込動作完了処理ルーチンに対するフローチャート図である。 いくつかの実施例に従って実行されるステップを示すテーブルデータ取得ルーチンに対するフローチャート図である。 いくつかの実施例に従って実行されるステップを示すデータテーブル更新ルーチンに対するフローチャート図である。

詳細な記載
本開示は、データ記憶装置に関し、特に、データ記憶装置において異なるデータのバージョンを管理する方法および装置に関する。

データ記憶装置は、一般に、アドレス指定可能なデータのブロック（たとえばセクタ）をメモリに記憶するよう動作する。これらの装置は、データ管理システムを用いてブロックの物理的な位置を追跡して、それらのブロックが、その後、記憶されたデータに対する読出要求に応答して取得され得るようにし得る。

いくつかのタイプのデータ記憶装置は、所与の論理アドレス（たとえば論理ブロックアドレスＬＢＡ）を有するデータを、典型的には、ブロックが書込に対して呈示されるたびに、新たな利用可能な物理メモリ位置に書込むよう構成される。そのような装置は、ここでは、仮想メモリアドレスマッピングスキームを有するとして称される。これらの装置は、しばしば、電子的に「消去可能な」メモリを有し、ソリッドステートドライブ（ＳＳＤ）を消去可能なソリッドステートメモリ（たとえばフラッシュ）とともに含み得る。仮想的にマッピングされた装置は、さらに、たとえばハイブリッドハードドライブのような何らかのハードディスクドライブ（ＨＤＤ）を含み得、さらに、シングルの（部分的に重なる）トラックを有する回転可能な媒体を用いるような、さまざまな位置にデータをキャッシュするＨＤＤを含み得る。

時間が経つにつれて、所与の論理ブロック（セクタ）のさまざまなバージョンがメモリに存在し続け、それらのバージョンのうちの１つが最新データであり、残りのバージョンは、より古い、古くなったデータであるといった状況が生じるかもしれない。メタデータを生成および維持して、ブロックの最新バージョンが記憶される位置を示すポインタを含む、記憶されたデータの位置およびステータスを追跡し得る。

そのようなメタデータに基づくリビジョン制御スキームは、一般的には、メモリの正確なステータスを維持するよう動作可能である一方で、記憶されたメタデータの損失または破損、メタデータにアクセスするのに用いられる回路系における障害、ファームウェアバグ、停電中におけるメタデータの不完全な更新などを含むさまざまな要因によって、しばしばエラーが生じ得る。いくつかの場合では、エラー状態によって、最新バージョンのデータではなく、より古いバージョンのデータがホストに返されるかもしれない。

他の形式のデータ記憶装置は、一般的には、より古いバージョンのデータを、同じ位置において、より新しい更新されたバージョンで上書きする。そのような装置は、ここでは、固定メモリアドレスマッピングスキームを有するとして称され、非シングルの（従来の）ＨＤＤのような「リライタブル」メモリを有する装置、ならびにスピントルク転送ランダムアクセスメモリ（ＳＴＲＡＭ）、抵抗変化型メモリ（ＲＲＡＭ（登録商標））、強磁性ランダムアクセスメモリ（ＦｅＲＡＭ）、不揮発性スタティックランダムアクセスメモリ（ＳＲＡＭまたはＮｖＳＲＡＭ）、バッテリパックのダイナミックランダムアクセスメモリ（ＤＲＡＭ）およびＳＲＡＭなどのようなリライタブル不揮発性メモリを有するソリッドステードデバイスを含み得る。

これらおよび他のタイプの装置においては、所与の物理ブロックアドレス（ＰＢＡ）が特定の論理ブロックアドレス（ＬＢＡ）を割当てられてもよく、所与のブロック（ＬＢＡ）の新たなバージョンが記憶装置に呈示されるたび毎に、その新たなバージョンが、そのとき存在する、より古いバージョン上に上書きされる。これは、通常は、一時点において、任意の特定のＬＢＡの単一のバージョンのみがメモリに存在するという状況をもたらす結果となる。

それにも係わらず、このスキームは、時として、不適切なリビジョン取得エラーをもたらす結果ともなり得る。時に「ゴースト障害」と称されるエラー状態がそのような装置において生じ得るのは、書込動作が新たなバージョンのデータを意図された位置に書込まず、それによって、より古いバージョンのデータがそのままその位置に残るときである。データ保全性値（以下検証コードとも称される）を形成してデータ書込動作を検証し得る。この検証コードは、記憶されたデータと、ＬＢＡ値のような他の識別情報との組合せに基づいてもよい。実際には新しいバージョンのデータが全く書込まれなかったときに、検証コードを用いて動作する読出検証動作のような検証動作が、書込動作の成功を信号送信するかもしれないことが理解され得る。

したがって、本開示のさまざまな実施例は、一般に、データ保全性を増大させるための装置および方法に向けられる。ここに開示されるデータ保全性スキームは、新しいバージョンのデータをメモリの異なる位置またはメモリの同じ位置に書込むメモリを含む、任意の数の異なるタイプのメモリにおける使用に対して好適である。ここに開示されるデータ保全性スキームは、メタデータエラーおよびゴースト障害などであるが、それらに限定はされないさまざまなエラー状態を検出し解決することを支援する。

さまざまな実施例は、一般に、データ要求に応答して最新バージョンのデータが返されることを確実にするよう動作する。いくつかの実施例では、メモリに記憶されるべきホストからの入力データの受取りに応答して、検証コードが生成される。この検証コードはテーブル構造に記憶され、要求されたメモリのリビジョンステータスを検証するために別途用いられる。

いくつかの場合では、検証コードは、いわゆるＩＯＥＤＣ（入力／出力エラー検出コード）値の形式を取り、それは、選択されたブロックにおけるデータを合計し、（排他的論理和（ＸＯＲ）などを介して）その合計されたデータを、その選択されたブロックと関連付けられる論理アドレスと組合せることによって形成される。任意の数の他の形式の検証コードを用い得る。

さらなる例では、検証コードの第１の部分（最上位バイトＭＳＢなど）がテーブル構造に記憶され、検証コードの第２の部分（最下位バイトＬＳＢなど）がメモリに記憶される。代替的に、検証コードの完全なコピーがテーブルおよびメモリの両方に記憶される。さらに別の実施例では、検証コードのコピーがテーブルにのみ記憶され、メモリには記憶されない。

データ保全性マネージャはデータ保全性テーブルを階層構造として構成する。ユーザデータの論理ブロックに対する検証コードのグループがページに結合され、各ページは、そのページに割当てられる論理ブロック（たとえばＬＢＡ）に対する検証コード（またはその一部）を記憶する。各ページは、さらに、エラー検出および訂正（ＥＤＣ）能力を伴う上位レベル検証コードを与えられる。

ページのグループはいわゆる「親」ページに蓄積され、各親ページは、個々のページに対するページレベルＥＤＣコードを記憶する。各親ページも、上位レベル検証コードをＥＤＣコードの形式で有してもよい。最後に、マスターページが親ページに対して生成されて、個々の親ページに対するＥＤＣコードを記憶する。マスターページも、マスター検証コードを与えられる。

このようにして、さまざまなコードをデータ取得およびロード動作中に用いて、個々のＬＢＡに対する個々の検証コードを検証し得る。データ読出および書込動作がその後システムの通常のコントローラ経路（たとえばメインコントローラファームウェア）によって実行され、データ保全性マネージャはデータフローの独立した監査役として動作し得る。

さまざまな開示される実施例のこれらおよび他の局面は、例示的なデータ記憶装置１００を示す図１の検討から始めて、理解され得る。記憶装置１００はコントローラ１０２およびメモリモジュール１０４を含む。

コントローラ１０２は、装置１００がホスト装置（別途示されない）と対話してホストユーザデータを記憶および取得する際に、最上位レベルの制御および通信機能を提供する。データ記憶装置のコントローラは相対的に複雑であることが多く、何千または何百万もの論理ゲートを含み得ることが理解される。メモリモジュール１０４はホストデータの不揮発性記憶を提供する。入出力（Ｉ／Ｏ）通信回路、１つ以上のデータバッファ、階層的キャッシュ構造、読出／書込ドライバ、ローカルダイナミックランダムアクセスメモリ（ＤＲＡＭ）、オン・ザ・フライＥＣＣ生成回路系などのような、ある数のさらなる回路が、記憶装置１００に組込まれてもよいことが理解される。

コントローラ１０２は、装置１００内のコンピュータメモリに記憶されるプログラミングと関連して動作するプログラマブルＣＰＵプロセッサであってもよい。コントローラ１０２は代替的にハードウェアで実現されてもよく、またはコントローラ機能はメモリモジュール１０４に物理的に組込まれてもよい。

図２は、いくつかの実施例に従う別のデータ記憶装置１１０のための機能ブロック図である。装置１１０は、コントローラ１１２、バッファ１１４、フラッシュメモリモジュール１１６、およびディスクメモリ１１８を含む。先のように、他のモジュールが必要に応じて含まれ得る。

コントローラ１１２は、図１におけるように、装置１１０に対して最上位レベルの制御機能を実行する。バッファ１１４は揮発性または不揮発性であってもよく、データ転送（読出／書込）動作中におけるホストデータの一時的な記憶、およびコントローラ１１２によって用いられるプログラミングステップ（たとえばロードされたコントローラファームウェアなど）の記憶を提供する。

フラッシュメモリモジュール１１６は、ユーザデータ、ファームウェア、およびシステムパラメータ（たとえばメタデータなど）の記憶のための消去可能な不揮発性フラッシュメモリセルを提供する。フラッシュメモリセルは、ＮＯＲ構成（ＮＯＲフラッシュ）、ＮＡＮＤ構成（ＮＡＮＤフラッシュ）、またはそれらの両方において構成され得る。ディスクメモリ１１８は、読出／書込トランスデューサの対応のアレイによってアクセスされる１つ以上の回転可能な磁気記録媒体を含む。

装置１１０はハイブリッドドライブとして特徴付けられ、したがって、より優先順位の高いユーザデータブロックは相対的に高速のアクセスフラッシュメモリモジュール１１６に記憶され、優先順位がより低いユーザデータブロックは相対的に低速のアクセスディスクメモリ１１８に記憶され得る。

「標準的な」ＨＤＤは、フラッシュメモリモジュール１１６を除き、図２によって述べられる構成と同様の構成を有し得、ＳＤＤは、ディスクメモリ１１８を省略することによって図２によって述べられるような同様の構成を有し得ることが理解される。他のメモリ構成は単独で、またはフラッシュメモリモジュール１１６およびディスクメモリモジュール１１８のいずれかまたは両方と関連して用いられるリライタブルメモリモジュール（たとえばＳＴＲＡＭ、ＲＲＡＭ、ＰＣＭ、ＦｅＲＡＭ、これらの混合物、および／または他のタイプのソリッドステートメモリなど）を含み得る。図１〜図２は、したがって、本開示に従って管理され得る幅広いさまざまな異なるタイプのメモリを示す。

これらおよび他の形式の装置においては、同じ論理ブロックアドレス（ＬＢＡ）を有するブロック（たとえばセクタ）の複数バージョン（リビジョンレベル）が異なる物理メモリ位置に記憶され得る。たとえば、図２における装置１１０の動作中における異なるときにおいて、同じユーザデータブロックの異なるバージョンが、バッファ１１４、フラッシュメモリモジュール１１６および／またはディスクメモリ１１８に記憶されるかもしれない。同様に、同じブロックの複数バージョンが、同じメモリ装置内における異なる位置に記憶され得る（たとえばフラッシュメモリモジュール１１６における複数バージョンなど）。

図３は、図２におけるフラッシュメモリモジュール１１６とおおむね同様のフラッシュメモリモジュール１２０の一部の論理表現を示す。モジュール１２０は、さまざまな制御線（別途図示されず）によってアクセス可能なＮＡＮＤ構成において構成されるフラッシュメモリセルを利用する。これらのメモリセルは、ある数の消去ブロック１２２に配置される。ブロック１２２は１回に消去され得るメモリセルの最小増分を表現する。ある複数のブロック１２２が、１つの単位として消去および割当てられる、より大きなマルチブロックガベージコレクションユニット（ＧＣＵ、それらの１つが１２４として表現されている）に配置される。

各ブロック１２２は、ある選択された数の行のメモリセルを有する。データはそれらの行にページの形式で記憶される。ある例示的な消去ブロックサイズは１２８行のオーダであってもよく、各行は８１９２バイトを記憶する。他のサイズおよび構成の消去ブロック１２２も用いられ得る。

読出、書込および消去（Ｒ／Ｗ／Ｅ）動作がメモリ１２０上においてＲ／Ｗ／Ｅ回路１２６によって実行され、回路１２６は装置コントローラ１２７と通信する。メタデータが、読出／書込／消去動作中における使用のために近接する揮発性メモリ（たとえばＤＲＡＭ）１２８におけるメタデータテーブル１２８にシーケンシャルにロードされて、データのステータスおよび位置を追跡してもよい。図３における例示的なフラッシュメモリセルは新たなデータがそこに書込まれ得る前に消去される必要があるので、１２６のようなＲ／Ｗ／Ｅ回路は、共通のＬＢＡ値を共有するブロックの更新されたバージョンをメモリ１２０内における異なる位置に書込むことが一般的である。ホストが、ある選択されたブロックの新たな連続するバージョンを書込むよう書込コマンドを与えるたび毎に、装置はデータをメモリ１２０内における次の利用可能なページに書込む。

最も最近記憶されたブロックのバージョンは「現行」データを表現し、すべての以前に記憶されたバージョンは、より古い「古くなった」データを構成する。メタデータは、正方向ポインタを利用して、（通常、）システムが、ある特定のＬＢＡに対する読出要求に応答して、現行バージョンのデータを見つけ出すことを可能にする。これは、図３において、論理アドレスＬＢＡ Ｘを有する選択されたブロックに対して示されており、その５つの異なるバージョンがメモリ１２０に記憶されている。

バージョン５（ｖ５）は、ＬＢＡ Ｘに対するブロックデータの、現行の、最も最近記憶されたバージョンを表現し、メタデータは、理想的には、この位置を指す。つまり、通常の条件下では、ＬＢＡ Ｘに対する読出要求に応答して、ｖ５データがホストに返されることになる。残りのバージョンｖ１〜ｖ４は、ＬＢＡ Ｘに対する、より古い、古くなったデータを表現し、そのブロックに対する読出動作中においては無視されることになる。異なるバージョンのＬＢＡ Ｘが異なるデータセットを記憶してもよく、各後に生ずるバージョンは、ホストアプリケーションなどによって、各先の連続するバージョンと比較して、修正されていることが理解される。これは、しかしながら、必ずしも必要ではなく、なぜならば、メモリにおける所与のブロックの異なるバージョンが同じユーザデータを記憶してもよいからである。

ガベージコレクション動作は、装置１２０によって定期的に実行されて、古くなったデータを記憶するＧＣＵ１２４を解放する。ガベージコレクション動作は、バックグラウンドで生じ、適切なとき、たとえばホストＩ／Ｏ活動度が低い休止期間中、または記憶に対して利用可能な空いているページの量が選択されたしきい値よりも下に下がったときなどに予定されてもよい。選択されたＧＣＵ１２４のデータのほとんどまたはすべてが古くなっていると判断される場合には、ガベージコレクションプロセスは、現行データを新たなＧＣＵに移動させ、選択されたＧＣＵを消去し、メタデータを更新し、消去されたＧＣＵを利用可能なブロックの割当プールに戻すことになる。ブロックにおける現行データは、消去動作前に、新たに割当てられたブロックにコピーされることになる。複数のＧＣＵがともにグループ化され、並行して、所望のように消去動作を受けてもよい。

進行中のガベージコレクション動作が、より古い、古くなった所与のブロックのバージョンを除去する傾向があることになる一方で、少なくとも一部のブロックのいくつかのバージョンが、任意の所与の時間においてメモリ１２０に持続するかもしれないことが考えられ得る。これは、特に、ある所与の時間間隔にわたって書込および／または読出アクセス動作を相対的により多い回数受ける相対的に高優先度のデータ（「ホット」データ）を伴う場合に生じそうである。

上に注記されたように、問題がこのように起こり得るのは、図３のメモリ１２０または図１〜図２において論じられた他の例示的メモリのいずれかが所与のブロックの複数バージョンを記憶し、メタデータ（または他のデータ管理スキーム）がそのブロックの最新バージョンを正確に指さないときである。たとえば、再び図３を参照して、メタデータテーブルは、ＬＢＡ Ｘに対する最新のメタデータ入力を、最新バージョン５（ｖ５）ではなく、バージョン４（ｖ４）に対応するそれであるとして認識するかもしれない。そのような場合においては、Ｒ／Ｗ／Ｅ回路１２６は、最新ｖ５データではなく、より古いｖ４データを誤ってホストに返すかもしれない。これらおよび他のタイプのデータ保全性エラーの発生を低減するため、本開示のさまざまな実施例は、図４に概略的に示されるように、データ保全性マネージャ１３０の使用を組込む。データ保全性マネージャ１３０は、ハードウェアまたはソフトウェア（たとえばファームウェア）において実現され得、一般的に、以下に説明されるように動作して、データ転送動作中においてリビジョン検証を提供する。一部の実施例では、マネージャ１３０は、装置コントローラによって用いられるプログラミングの一部を形成するが、（ここではメインコントローラファームウェア１３２と称される）コントローラコードの残りからは別のモジュールであり、それとは独立して動作する。

メモリに書込まれるべき選択されたブロックに対するデータは、関連付けられる論理アドレス（たとえばＬＢＡ）とともに、データ保全性マネージャ１３０に供給される。マネージャ１３０は、メインコントローラファームウェア１３２による処理のための検証コード（ＶＣ）を生成する。マネージャ１３０は、さらに、検証コードを、別のメモリ１３４におけるテーブル構造に転送する。

いくつかの場合では、検証コードは、ＩＯＥＤＣ（入力／出力エラー検出コード）の形式を取り得る。ＩＯＥＤＣは図５に示されるように生成され得る。ある特定のＬＢＡ値を有するブロックデータ１４０が記憶のためにホスト装置から与えられる。ブロックデータ１４０は一時的にローカルキャッシュに記憶される。データは、５１２バイト、４０９６バイトなどのような、ある選択された数のバイトを構成してもよい。

巡回冗長符号（ＣＲＣ）値１４２のようなデータエラー検出コードが、入力されたブロックデータの個々の８ビットバイトをともに畳込むことによって生成され得る。ＣＲＣ１４２は、排他的論理和（ＸＯＲ）のような好適な組合せ論理関数を用いて、畳込まれたＬＢＡ値１４４とともに組合せられて、ＩＯＥＤＣ値を生成する。いくつかの実施例では、ＬＢＡ値１４４は、ブロックに対する論理ブロックアドレス番号のハッシュであり、ハッシュアルゴリズムを、ＩＯＥＤＣ値と同じ（ビットにおける）幅とともに用いる。代替的に、入力されたブロックデータ１４０は、論理ブロックアドレスまたはＬＢＡ値１４４とともに直接ＣＲＣされて、ＩＯＥＤＣ値を生成してもよい。他のタイプのコード値も用いられ得ることが理解される。

ＩＯＥＤＣは、セクタの論理アドレスをデータとともに畳込んで、そのデータに対するあるレベルのエラー検出および訂正を提供する、ＬＢＡがシードされたエラー検出コードである。図５におけるＩＯＥＤＣ値１４４は長さが２バイト（１６ビット）となることが考えられるが、他のサイズも用いられ得る。

再び図３を参照して、ＬＢＡ Ｘの５つのバージョンの各々に対するＩＯＥＤＣ値は、関連付けられるブロックデータ間における差と関係して異なることになるが、各ＩＯＥＤＣ値におけるＬＢＡ成分は同じであることになることに注目されたい。したがって、ＬＢＡがシードされた値をこれらのＩＯＥＤＣ符号語の各々から抽出することは、すべて、同じＬＢＡ値を生じさせることとなり、それは、正しいＬＢＡ値が識別されたと判断する際に有用である。これは、しかしながら、正しいバージョンのデータが取得されたかどうかを確認することを助けはしない。

したがって、図６は、選択されたブロックをメモリに書込むデータ書込動作の文脈において図４のデータ保全性マネージャ１３０の動作を示すよう、別の記憶装置１５０の関連部分を示す。データ保全性マネージャの検証コード生成部１５２は検証コード（ＶＣ）を生成するが、それは、本議論の目的のため、図５にあるようにＩＯＥＤＣ値を構成することになる。先に注記されたように、これは単なる例示であり、限定的ではなく、なぜならば、任意の数の異なる形式の検証コードが所望のように生成および用いられ得るからである。

ＩＯＥＤＣ値は、データ保全性テーブル１５４に記憶され、および（図４のメインコントローラファームウェア１３２の制御の下）データ経路処理モジュール１５６に転送され、それは、入力されたデータを処理し、究極的にはその入力されたデータをメモリ１５８に記憶する。いくつかの場合では、ＩＯＥＤＣはさらにメモリ１５８にも記憶されてもよい。メタデータ生成部１６０は、記憶されたデータの位置およびステータスを記述するようメタデータを生成する。

図７は、記憶されたデータを要求側ホスト装置に戻す、後の読出動作中における図６の記憶装置１５０のさらなる特徴を示す。データ要求がメタデータルックアップブロック１６２に与えられ、メタデータルックアップブロック１６２は、最新バージョンのデータが記憶される物理アドレス（たとえば物理ブロックアドレスＰＢＡ）を（名目上）識別する。データが、その識別された位置から取得され、メモリ検証コード（ＶＣ）処理ブロック１６４に転送され、ブロック１６４は、その取得されたデータに基づいて検証コード（「計算されたＶＣ」）を生成する。計算されたＶＣは、最初のＶＣを生成するよう用いられるのと同じアルゴリズムを用いて生成される（たとえば図５参照）。ブロック１６４は、メインコントローラファームウェアの制御下にあり、データ経路処理ブロック１５６（図６）の一部を構成してもよいことが考えられる。

データ要求は、さらに、データ保全性マネージャにも転送され、データ保全性マネージャは、関連付けられるＬＢＡについて、データ保全性テーブル１５４から最初の検証コード（「テーブルＶＣ」）を取得する。比較モジュール１６６が、計算されたＶＣをテーブルＶＣと比較し、いくつかの場合においては、さらに、メモリに記憶された検証コード（「取得されたＭＥＭ ＶＣ」）を比較する。コードが一致する場合には、要求されたデータの転送が許可される。

このようにして、データ保全性マネージャ（１３０、図４）は、通常の装置データ経路処理システムの独立した監査役として動作する。これは、データの妥当性を確認するよう別途動作する２つの独立したハードウェア／ファームウェアを与える。この独立性は、システムのうちの一方の部分における管理ミスが他方の部分によって検出されることを確実にする。データ保全性マネージャは、ホストロジックと緊密に結合されることになり、利用可能なＤＲＡＭメモリのうちの専用の部分（たとえば図２のバッファ１１４）に対するアクセスを有することになることが考えられる。

ＩＯＥＤＣ値が例として開示されているが、任意の好適なアルゴリズムを用いて検証コードを生成し得る。図８は、選択されたアルゴリズム（暗号）を用いて、入力されたデータ（「平文」）を出力データ（「暗号文」）に変換する一般的な暗号ブロック１６８を示す。ユーザデータは暗号ブロック１６８を通過させられ得、その出力の一部がＩＯＥＤＣとして用いられ得る。入力されるキー値、たとえばＬＢＡが、変換プロセスの一部として用いられ得る。任意の数の好適な暗号が用いられ得る。

上記のものと同様の他のシステムが、図９において１７０で示される。システム１７０は、選択されたブロックに対する入力データおよび関連付けられるＬＢＡ値に応答して２バイトＩＯＥＤＣ値を生成するＩＯＥＤＣ生成部ブロック１７２を含む。システム１７０においては、生成されたＩＯＥＤＣ値の、最上位バイト（ＭＳＢ）１７４（たとえば最初の８ビット）のような第１の部分は、データ保全性テーブル１５４に記憶される。生成されたＩＯＥＤＣ値の、最下位バイト（ＬＳＢ）１７６（たとえば最後の８ビット）のような第２の部分は、メモリ１５８に記憶される。この例では、ＩＯＥＤＣの全体がデータ経路処理ブロック（１５６、図６）に供給されてもよいが、ほんの一部のみが実際にはメモリ１５８に記憶される。しかしながら、他の実施例では、ＩＯＥＤＣ（または他の生成された検証コード）の如何なる部分もメモリには記憶されない。

図１０は、前述の議論のまとめを与えるデータ処理ルーチン２００のフローチャートを示す。本議論の目的のため、ルーチン２００は、図６〜図７によって述べられるような書込および読出動作中において、図５において生成されるようなＩＯＥＤＣ値を用いることが考えられる。ルーチン２００は単なる例示であり、さまざまなステップが、異なる順序で修正、追加、実行などされ得ることが理解される。

メモリに記憶されるべき入力されたデータは、まず、ステップ２００において受取られる。入力されたデータは、関連付けられる論理アドレス（たとえばＬＢＡ）を各々が有する１つ以上のブロックとして構成される。各ブロック毎に、ブロックデータおよびＬＢＡ値を用いて、入力された書込データに対して第１の検証コード（テーブルＶＣ）を生成する（ステップ２０４）。第１の検証コードは（テーブル１５４のような）テーブル構造に記憶される（ステップ２０６）。第１の検証コードまたはその一部は、さらに、好適な処理の適用を受けた後に、入力された書込データとともにメモリ（たとえばメモリ１５８）に記憶されてもよい（ステップ２０８）。

その後、ステップ２１０において、先に記憶されたデータを取得するよう、要求側ホスト装置から読出要求が受取られる。ステップ２１２で、メタデータルックアップ動作（ブロック１６２、図７）によって、最新バージョンのデータがどこに記憶されるかの、システムによって示されるとおりの物理的位置が識別される。識別された位置（物理ブロックアドレス）におけるデータがステップ２１４において取得される。

第２の検証コードが、ステップ２１６において、取得されたデータを用いて、上に記載されるようにブロック１６４（図７）によって生成される（計算されたＶＣ）。第１の検証コードがステップ２１８においてテーブルから取得され（テーブルＶＣ）、所望のように、記憶された検証コードがステップ２２０においてメモリから取得される（取得されたＭＥＭ ＶＣ）。

比較動作が判断ステップ２２２によって示されるように実行される。コードが一致する場合には、データ転送動作がステップ２２４において示されるように許可される。コードのうちの１つ以上が一致しない場合には、エラーステータスがホストに返される（ステップ２２６）。代替的に、または加えて、コード不一致の結果において、読出動作を繰返す、新たなメタデータ検索を行なう、検証コードのうちの１つ以上を再計算するなどを含む、さらなる訂正ステップが取られてもよい。

図１１〜図１８は、いくつかの実施例に従って上において論じられたデータ保全性スキームの特定の実現例のための詳細を示す。ここに論じられるデータ構造およびルーチンは、さまざまな環境および検証コードフォーマットに対して容易に適合され得ることが理解される。

図１１は、例示的なデータ保全性テーブル構造２３０を概論的に示す。テーブル構造２３０は、図９において上で論じたような１６ビットＩＯＥＤＣ値のＭＳＢのような、システムにおける各ＬＢＡに対する単一バイト（８ビット）検証コードを記憶する。

連続する４，０９６個のＬＢＡのグループのような、連続するＬＢＡのグループがページ２３２に構成される。このようにして、１番目のページ（ページ０）は、ＬＢＡ ０〜ＬＢＡ ４０９５に対する検証コードを記憶し、２番目のページ（ページ１）は、ＬＢＡ ４０９６〜ＬＢＡ ８１９１に対する検証コードを記憶する、などとなる。参考のため、ＬＢＡ ０に対する８ビット検証コードはＶＣ０として識別され、ＬＢＡ １に対する８ビット検証コードはＶＣ１として識別される、などとなる。各検証コードは単一バイト（８ビット）であるため、ページ全体のコンテンツのサイズは４０９６バイトとなる。

ページレベル検証コードを生成して、各ページのコンテンツを保護する。１番目のページ（ページ０）に対する検証コードはＶＣＰ０として示される。ＣＲＣのような任意の好適なエラー検出コードアルゴリズムを用いてページレベル検証コードを生成し得る。いくつかの場合においては、ページレベル検証コードはリードソロモン符号の形式を取り、コードは、ページコンテンツにおいて、選択された数までのエラーを検出および訂正し得る。他の形式も用いられ得る。一実施例においては、ページレベル検証コードは３２ビット（４バイト）値である。

ページ（ページレベル検証コードを含む）は、利用可能なフラッシュメモリのような好適な不揮発性メモリに記憶され、必要に応じてローカルの揮発性ＲＡＭに取得される。以下に説明されるように、ページがロードされるたびに、ＥＤＣ検証が自動的に実行され得る。

図１１は、さらに、ある数の親ページ２３４を示す。各親ページは、関連付けられるページのグループに対して、ページレベル検証コードを蓄積する。図１１の例示的フォーマットでは、各親ページは、１，０２４の連続するページに対するページレベル検証コードを記憶する。各親ページ２３４の全体的なサイズ（親ページを記憶するのに必要とされるデータ容量に関して）は、（図１１にあるように）各ページ２３２の全体的なサイズに名目上等しいように設定され得るか、または何らかの他の好適なサイズであり得る。

親ページレベル検証コードが各親ページに対して生成される。参考のため、第１番目の親ページ（親ページ０）に対する親ページレベル検証コードはＶＣＰＰ０として示される。先のように、任意の好適なアルゴリズムを用いて、ＣＲＣまたはリードソロモン符号を含むがそれらに限定されない親ページレベル検証コードを生成し得る。先のように、親ページレベル検証コードは、いくつかまでの検出されたビットエラーの検出および訂正を可能にするよう適合されてもよい。一実施例では、親ページレベル検証コードも３２ビット（４バイト）ワードである。

マスターページが２３６にて表わされる。マスターページ２３６は、親ページの各々毎に、親ページレベル検証コードを記憶する。マスターページ２３６は、さらに、全体的なマスターＥＤＣ値（ＶＣＭａｓｔｅｒ）で完結する。先のように、ＶＣＭａｓｔｅｒはＥＤＣであり、ＣＲＣまたはリードソロモン符号または何らかの他の形式を取ってもよい。一実施例では、マスターＥＤＣ値も３２ビット（４バイト）ワードである。

それぞれのデータ構造の各々が不揮発性メモリに記憶され、必要に応じて揮発性ＲＡＭにロードされる。それぞれの階層のＥＤＣ値によってデータ保全性が保証される。一例を挙げるため、ある選択されたページ、この例においてはページ０にアクセスすることは、マスターページ２３６を取得することを伴ってもよい。マスターページ２３６のコンテンツは、ＶＣＭａｓｔｅｒコードを用いて検証される。これは、親ページ０に対する検証コードであるＶＣＰＰ０を含む、親ページレベル検証コードのすべての妥当性を確認することになる。

選択されたページに対する親ページ（親ページ０）が次いで取得され、ＶＣＰＰ０を用いて検証される。この検証は、マスターページ２３６からの取得された値を、親ページからの取得された値と比較することを含み得る。新たな親ページレベル検証コードが、さらに、その取得されたデータに基づいて計算され、当該親ページおよびマスターページのいずれかまたは両方における記憶された値と比較され得る。

親ページ（親ページ０）の検証は、選択されたページ（ページ０）に対するページレベル検証コード（ＶＣＰ０）の妥当性を確認する。次いで、ページ２３２が取得され得、親ページからの妥当性を確認されたコードが、その取得されたページに対する取得された（および／または計算された）コードと比較され得る。

最後に、ある所与のブロックに対するＬＢＡが識別され得（たとえばＬＢＡ ０）、関連付けられる検証コード（たとえばＶＣ０）がテーブル構造から取得され、上記のように用いられて、データブロックの最新バージョンがホストに返されていることを検証し得る（たとえば図１０を参照のこと）。

まとめると、最下位レベル（ページ２３２）は、各々、４０９６バイトを含み、各エントリは、ＬＢＡ毎にＩＯＥＤＣデータの単一バイト（８ビット）を構成する。ページレベル検証コードは４バイト（３２ビット）ＥＤＣ値であり得、それらは親ページ２３４に記憶される。個々のページ２３２とマスターページ２３６との間には僅かに１つの中間レベルのみが示されるが、任意の数のさらなるレベルが必要に応じて挿入され得る。

各親ページ２３４からの各４バイトＥＤＣは、マスターページ２３６に記憶され、４バイトＥＤＣ（ＶＣＭａｓｔｅｒ）によって保護される。マスターページは、（ＮＯＲフラッシュなどのような）メインの大容量記憶メモリとは別の不揮発性メモリにおけるような電源喪失を通して常に維持されることが考えられる。

所与のデータ保全性テーブルの実際のサイズは、記憶装置のブロックサイズおよび全体的なデータ容量を含むさまざまな要因に依存することになることが理解される。テーブル全体を、利用可能な揮発性ＤＲＡＭにロードし得、マスターページが、利用可能な揮発性ＳＲＡＭまたはレジスタにフィットするよう十分小さくあることになることが考えられる。表１は、異なる動作環境下における図１１のさまざまな要素に対する例示的サイズを示す。

他の装置データ容量およびブロックサイズは、対応の値を与えることになる。表１に示されるメモリサイズは２の累乗であり、したがって、Ｂ＝バイト（８ビット）、ＫＢ＝１０２４Ｂ、ＭＢ＝１０４８５７６Ｂ、などである。ドライブ容量は、装置の定格の全体的なデータ記憶能力を指し、オーバープロビジョン、予備ブロックなどを考慮しない。ブロックサイズは、一般的には、ホストの視点からの個々のブロック（セクタ）のサイズ（たとえば、オーバーヘッド処理ビット、ＥＣＣビットなどを含まない、各ＬＢＡに関連付けられるユーザデータビットの数）である。すべてのＶＣは、テーブル構造からの検証コードのすべてを記憶するのに必要とされる全記憶容量を指す。親ページは、親ページ（図１１の２３４）のすべてを記憶するのに必要とされる、全体の必要とされる記憶容量である。マスターページは、マスターページ（図１１の２３６）を記憶するのに必要とされる、全体の必要とされる記憶容量である。

データ保全性データ構造の全体的なサイズは、ＳＳＤ、ＨＤＤ、ハイブリッドドライブなどを含むさまざまな異なるタイプの記憶装置に対して合理的に管理可能であることがわかる。

通常の条件下では、少なくともマスターページおよび親ページの各々が、初期設定中にローカルＲＡＭにロードされ、必要に応じて検証され、システム電源供給動作中にＲＡＭにおいて維持され得ることが考えられる。マスターページに対する更新は実行記録され得、１つのリビジョンから次のリビジョンへの変更は、追跡され不揮発性メモリに記憶される。しかしながら、マスターページに対する相対的に小さなサイズのため、更新されたページ全体がシステム電力の喪失で不揮発性メモリに書込まれ得ることが考えられる。ページのダーティビットのテーブルが維持され得、ダーティなデータ保全性ページが、電力喪失で不揮発性メモリに掻き集められるか、または電力回復で再建され得る。

ブロックサイズおよび記憶装置容量に依存して、最下位ページ（図１１のＶＣページ２３２）は、すべて、装置動作中に揮発性ＲＡＭに維持され得るか、または必要に応じてＲＡＭにロードされ得る。テーブル構造は、検出されたエラーに応答して再建され得る。データ保全性テーブル構造に関連付けられる、再発するデータ保全性エラーは、装置との初期障害信頼性問題を示し得、再建または置換に対するホスト通知をもたらす結果となる。

データ保全性マネージャは、通常のコントローラファームウェア（システムコントローラ）と通信する別途のコントローラとして動作し得る。ページの、ローカルＤＲＡＭメモリへの、またはそれからの移動は、システムコントローラに対して発行されるコマンドを介して実行され得る。データ保全性マネージャは、ページの目標ＤＲＡＭアドレス、ページ番号、および動作が書込であるかまたは読出であるか、を通信するよう構成され得る。システムコントローラは、要求されたページを記憶またはフェッチし、データ保全性マネージャに戻って通信する。ページをフェッチする際に生ずる媒体エラーは、データ保全性エラーではないが、ページ再建動作を必要とする。特定のページが成功裏に再建され得ない場合には、障害を起こしたページによってカバーされるすべてのデータが回復不能状態にされる。

図１２〜図１８は、図１１における２３０のようなテーブル構造を用いるデータ保全性マネージャによって実行されるルーチンに関するさまざまな詳細なフローチャートを示す。図１２は、新たな入来読出コマンドの処理に関連付けられるルーチン３００に関するフローチャートである。ルーチン３００は概して、上に記載される比較動作に備えて１つ以上の関連付けられるＬＢＡ（この場合ではＬＢＡ Ｘ）に関してデータ保全性テーブルからページデータをフェッチおよび検証するよう動作する。

ルーチンはステップ３０２で開始し、データ保全性マネージャ（以下「ＤＩＭ」）は、ＬＢＡ Ｘに対するＩＯＥＤＣ値に対する要求を処理する。判断ステップ３０４は、Ｘが有効なＬＢＡ番号であるかどうかを判断する。そうである場合には、判断ステップ３０６は、ブロック（ＬＢＡ Ｘ）がＤＩＭによる処理のためにキャッシュメモリにロードされたかどうかを判断する。判断ステップ３０８は、ＬＢＡ Ｘに対するＩＯＥＤＣ値が既にローカルメモリに存在するかどうかを判断し、存在しない場合には、ページがステップ３１０で取得される。その後、ステップ３１２においてＩＯＥＤＣバイトが取得され、キャッシュに記憶され、プロセスはステップ３１４で完結する。

図１３は、ＴＩＭ（「ホストブロック」とも称される）がＴＩＭキャッシュにおけるデータにアクセスする際に実行されるステップを示す。ステップ３２２で、ホストブロックはＤＩＭキャッシュからＬＢＡ Ｘに対するＩＯＥＤＣバイトを要求する。判断ステップ３２４で、ＬＢＡ Ｘに対するＩＯＥＤＣバイトがＤＩＭキャッシュにロードされるかどうかを判断する。そうである場合には、ＩＯＥＤＣバイトがステップ３２６にて返される。フェッチ要求がステップ３２８において次のＬＢＡ（たとえばＬＢＡ Ｘ＋１）に対して発行され、これは図１２のルーチン３００に従って処理され、ルーチンはステップ３３０で終了する。しかしながら、ＬＢＡ Ｘに対するＩＯＥＤＣがＤＩＭキャッシュにロードされない場合には、ルーチンは判断ステップ３２４からステップ３３０に通過し、そこでエラー割込がアサートされる。

図１４は、書込動作中に実行されるステップを示すルーチン３４０を示す。メインメモリに書込まれるべき書込データがステップ３４２において受取られる。ＩＯＥＤＣ、ＬＢＡ番号、および所望のように、さらなるタグ値がステップ３４４で受取られ、これらの要素は、ステップ３４６において、メモリへの書込まで、待ち状態書込待ち行列に付加される。プロセスは、次いで、ステップ３４８にて完結する。

図１５は、複数のＬＢＡに適用可能な「同じ書込」動作（たとえばある数のシーケンシャルなＬＢＡに同じユーザデータを反復して書込む動作）中におけるステップに対するルーチン３５０を示す。部分的なＩＯＥＤＣ（ユーザデータ上のＥＤＣ、たとえば図５の１４２）、ＬＢＡ番号、ＬＢＡ数、およびタグデータがステップ３５２にて受取られる。ＩＯＥＤＣバイトがその計数されたＬＢＡに対して生成され、生成されたＩＯＥＤＣバイトはステップ３５４にて書込待ち行列に追加され、その後、プロセスはステップ３５６にて終了する。

図１６は、書込（プログラム）動作が完了し（たとえば入力された書込データがメモリに書込まれ）書込完了ステータスがホストシステムに転送されるステップを示す別のルーチン３６０を示す。ホストシステムは、ステップ３６２にて（たとえば図１４の３４４で生成されるような）タグＸについてのステータスを送る。判断ステップ３６４は、書込動作が成功したかどうかを判断する。そうである場合には、ＩＯＥＤＣバイトは、ステップ３６６にて、タグと関連付けられる待ち状態の書込待ち行列におけるすべてのエントリに対して更新され、プロセスはステップ３６８にて終了する。そうではなく、書込が成功しなかった場合には、すべてのタグＸエントリは、ステップ３７０にて、待ち状態の書込待ち行列から消される。

図１７は、データ保全性テーブルからの、選択されたＬＢＡ（ＬＢＡ Ｘ）に対する関連付けられるＩＯＥＤＣページの取得を示すルーチン３８０である。ＩＯＥＤＣページに対する要求がステップ３８２にてＤＩＭに転送される。判断ステップ３８４は、関連付けられるページがローカルのＲＡＭメモリにあるかどうかを判断する。ない場合には、ページがステップ３８６にて要求される。判断ステップ３８８は、ＬＢＡ Ｘに対する親ページがＲＡＭにロードされるかどうかを判断する。ロードされない場合には、親ページの転送に対する要求がステップ３９０にて実行される。

判断ステップ３９２は、マスターページを用いる親ページデータのデータ検証検査を与える。不一致が生ずる場合には、データ保全性エラー状態が宣言され（ステップ３９４）、適切な訂正アクションが取られる。

一旦親ページがＲＡＭに成功裏にロードされると、判断ステップ３９６が、さらに、親ページを用いて、最下位レベルページデータのデータ検証検査を実行する。不一致が生ずる場合には、エラー状態が宣言され（ステップ３９８）、ページデータの再建を含む、適切な訂正アクションが取られる。一方、最下位レベルページデータが検証された場合には、ＬＢＡ Ｘに対するＩＯＥＤＣ値が検証され、リビジョンレベル認証における使用に対して利用可能となり、ルーチンはステップ３９９にて終了する。

図１８は、ＬＢＡ Ｘに対する所与のＩＯＥＤＣバイト（値）を更新するための要求に対するルーチン４００である。そのようなリビジョンは、たとえば、ブロックデータの最も新しいバージョンがメインメモリに書込まれるデータ書込動作の結果として生じてもよい。

このルーチンは、現行の最下位レベルページをテーブルからＲＡＭに取得するステップと、所望されるように、コンテンツを検証するステップとを含む（ステップ４０２）。次に、ステップ４０４にて、ＬＢＡ Ｘに対するＩＯＥＤＣバイトがその最下位レベルページにおいて更新され、その最下位レベルページに対するＥＤＣ（ページレベル検証コード）が再計算され記憶される。

ステップ４０６にて、その新たなページレベル検証コードは対応する親ページに書込まれ、新たな親ページレベル検証コードが生成され、さらに、親ページに記憶される。同様に、ステップ４０８にて、その新たな親ページレベル検証コードはマスターページに書込まれ、ステップ４１０にて、マスターページに対する新たなマスターＥＤＣ値が生成され記憶される。ステップ４１２にて、最下位レベルページ、親ページ、およびマスターページの、より古いバージョンは、その後は、「ダーティ」（古くなった、またはより古いリビジョンデータ）として記され、適切に破棄される。

最後に、データ記憶装置の有効寿命の開始における初期化において、ホスト装置によって与えられるユーザデータブロックの数は相対的に制限されるかもしれないことが注記される。この状態では、メインメモリ（たとえばフラッシュメモリモジュール１１６、１２０、ディスクメモリ１１８など）およびローカルメモリにおけるテーブル構造（たとえばデータ保全性テーブル１５４など）の両方は、それぞれ、ユーザデータブロックおよび対応の検証コードを疎に事前設定されるかもしれない。

いくつかの場合においては、ダミーデータを用いて、さまざまな最下位レベルページ２３２、親ページ２３４およびマスターページ２３６に対する初期検証コードを生成してもよい。乱数または擬似乱数生成部を用いてそのようなダミーデータを生成し得るか、または「初期テーブル値」のマスターセットをロードしてもよい。代替的に、記憶されたデータの妥当性を記憶するビットが検証コードテーブルに保持されてもよい。記憶装置の認定中に用いられる製造処理を用いて、メインメモリにおいて個々の物理位置に書込まれるさまざまな「パターン」を反映する、初期に事前設定されたテーブル構造を、ローカルメモリにおいて生成し得る。

データ保全性テーブルデータ構造が初期に事前設定される態様に係わらず、新たなユーザデータがメインメモリに転送されるなか、有効なユーザデータブロック検証コードおよび対応のページ／マスターレベル検証コードは必要に応じてリアルタイムで生成および更新されることになることが考えられる。記憶装置の電源がオフにされるたび毎に、バックアップ電力（スタンバイバッテリ、キャパシタ、回転するディスクからのエネルギなど）を含む十分な資源が与えられて、テーブル構造全体またはその最も重要な部分（たとえばマスターページおよび親ページ）が（メインメモリを含む）不揮発性メモリに安全に書込まれ、装置再初期化で十分かつ成功する回復を可能にすることを確実にすることになる。

さまざまな動作環境が前述の実施例に従って述べられたが、開示される主題は、携帯装置、ネットワーク接続される通信および伝送システム、大容量記憶システム、ＲＡＩＤ（独立ディスクの冗長アレイ）に基づくシステム、クラウドコンピューティング環境、分散型オブジェクト記憶システムなどを含む、実質的に任意の形態のメモリおよび任意の形態の動作環境に適合され得ることが理解される。

本開示のさまざまな実施例の多数の特性および利点が前述の記載にて述べられたが、本記載は例示的なものに過ぎず、変更が、詳細に、特に、本開示の原理内における構造および構成の事項において、特許請求の範囲が表現される文言の幅広い一般的な意味によって示される十分な程度にまでなされてもよいことが理解される。

１０２ コントローラ、１０４ メモリ、１３０ データ保全性マネージャ、２３０ テーブル構造、ＬＢＡ 論理アドレス、ＶＣ 検証コード

Claims (20)

1. ホスト装置とメモリとの間でユーザデータのブロックを転送するコントローラを含み、ユーザデータの各ブロックは、関連付けられる論理アドレスを有し、さらに、
   ユーザデータの各ブロック毎に検証コードを生成し、ローカルメモリにおけるテーブル構造に記憶し、前記検証コードを用いて、ホスト読出要求中に、選択されたユーザデータのブロックの最新バージョンが前記メモリから前記コントローラによって正確に取得されたことを独立して検証するデータ保全性マネージャを含む、装置。
2. ユーザデータの各ブロックに対する前記検証コードは、前記ブロックのユーザデータコンテンツおよび前記ブロックの前記関連付けられる論理アドレスに応答して生成される、請求項１に記載の装置。
3. ユーザデータの各ブロックに対する前記検証コードは、重複しない第１および第２の部分を含み、前記検証コードの前記第１の部分のみが前記ローカルメモリにおける前記テーブル構造に記憶され、前記検証コードの前記第２の部分のみがメインメモリに記憶される、請求項２に記載の装置。
4. 前記第１および第２の部分のうちの選択された一方は、前記検証コードの最上位バイト（ＭＳＢ）を含み、前記第１および第２の部分の残りの一方は、前記検証コードの最下位バイト（ＬＳＢ）を含む、請求項３に記載の装置。
5. 前記メモリは、仮想的にマッピングされたメモリとして特徴付けられるメインメモリであり、共通の論理アドレスを有する、ユーザデータブロックの各連続して受取られるバージョンは、前記メモリ内において、新たな、異なる物理位置に書込まれる、請求項１に記載の装置。
6. 前記メインメモリは、フラッシュメモリ、または部分的に重なるデータトラックを用いる回転可能な磁気記録媒体、のうちの少なくとも選択された一方である、請求項５に記載の装置。
7. 前記メモリはリライタブルメモリとして特徴付けられるメインメモリであり、共通の論理アドレスを有する、ユーザデータブロックの各連続して受取られるバージョンは、名目上は、前記メモリ内における同じ物理位置に書込まれる、請求項１に記載の装置。
8. 前記メモリは、重ならないトラックを有する回転可能な磁気記録媒体、スピントルク転送ランダムアクセスメモリ（ＳＴＲＡＭ）、抵抗変化型メモリ（ＲＲＡＭ）、強磁性ランダムアクセスメモリ（ＦｅＲＡＭ）のうちの少なくとも選択された１つである、請求項７に記載の装置。
9. 前記メモリは、Ｎ個の対応する論理的ブロックアドレス（ＬＢＡ）を有するＮ個のユーザデータブロックに対応するよう全体的なデータ記憶容量を有するメインメモリであり、Ｎは複数であり、前記ローカルメモリにおける前記テーブル構造は、前記データ保全性マネージャによって複数Ｍ個の最下位レベルページに構成され、前記Ｍ個の最下位レベルページの各々は、Ｎ個のＬＢＡの異なるシーケンシャルなサブセットに対する対応する検証コードを記憶し、ページレベル検証コードが前記データ保全性マネージャによって生成されて、各ページに記憶される前記検証コードに対するエラー検出および訂正（ＥＤＣ）能力を与える、請求項１に記載の装置。
10. 前記ローカルメモリにおける前記テーブル構造は、さらに、前記データ保全性マネージャによって複数Ｐ個の親ページに構成され、前記Ｐ個の親ページの各々は、前記Ｍ個の最下位レベルページの異なるシーケンシャルなサブセットに対するページレベル検証コードを記憶し、親ページレベル検証コードが前記データ保全性マネージャによって生成されて、各親ページに記憶される前記ページレベル検証コードに対するＥＤＣ能力を与える、請求項９に記載の装置。
11. 前記ローカルメモリにおける前記テーブル構造は、さらに、前記データ保全性マネージャによって、前記Ｐ個の親ページの各々に対する前記親ページレベル検証コードを記憶するマスターページに構成され、マスター検証コードが前記データ保全性マネージャによって生成され、前記マスターページに組み込まれて、前記マスターページに記憶される前記親ページレベル検証コードに対するＥＤＣ能力を与える、請求項１０に記載の装置。
12. 前記データ保全性マネージャによって生成される前記検証コードは、関連付けられるユーザデータブロックのユーザデータコンテンツおよび前記関連付けられるユーザデータブロックの論理アドレスから計算されるＩＯＥＤＣ（入力／出力エラー検出コード）値として特徴付けられる、請求項１に記載の装置。
13. 前記データ保全性マネージャは、前記選択されたユーザデータブロックの前記最新バージョンが、前記コントローラによって、前記ローカルメモリにおける前記テーブル構造から前記記憶された検証コードを取得することによって取得されていることを独立して検証し、メインメモリからの前記取得されたユーザデータブロックに応答して新たな検証コードを生成し、前記取得された検証コードを前記生成された新たな検証コードと比較する、請求項１に記載の装置。
14. メインメモリへの記憶のために、関連付けられる論理アドレスを有する、入力されたユーザデータのブロックを受取ることと；
    前記入力されたユーザデータブロックのユーザデータコンテンツおよび前記関連付けられる論理アドレスに応答して検証コードを生成することと；
    前記検証コードをローカルメモリにおけるテーブル構造に、および前記入力されたユーザデータブロックを前記メインメモリに記憶することと；
    その後、前記メインメモリから前記入力されたユーザデータブロックを取得するよう、ホスト読出要求を受取ることと；
    前記ローカルメモリにおける前記テーブル構造から前記検証コードを取得することと；
    前記取得された検証コードを用いて、前記ホスト読出要求に応答して、選択されたユーザデータブロックの最新バージョンが、コントローラによって、前記メインメモリから取得されていることを独立して検証することとを含む、方法。
15. 前記取得された検証コードを用いて、選択されたユーザデータブロックの最新バージョンが、前記コントローラによって、前記メインメモリから取得されていることを独立して検証することは、前記メインメモリからの前記取得されたユーザデータブロックに応答して新たな検証コードを生成することと、前記取得された検証コードを前記生成された新たな検証コードと比較することとを含む、請求項１４に記載の方法。
16. 前記メインメモリは、Ｎ個の対応する論理的ブロックアドレス（ＬＢＡ）を有するＮ個のユーザデータブロックに対応するよう全体的なデータ記憶容量を有し、Ｎは複数であり、前記方法はさらに、
    前記ローカルメモリにおける前記テーブル構造を、複数Ｍ個の最下位レベルページを含むよう構成することを含み、前記Ｍ個の最下位レベルページの各々は、前記Ｎ個のＬＢＡの異なるシーケンシャルなサブセットに対する対応する検証コードを記憶し、前記方法はさらに、
    各ページに記憶される前記検証コードに応答して、ページレベル検証コードを生成することと、
    前記ページレベル検証コードを用いて、各ページに記憶される前記検証コードを認証する、請求項１４に記載の方法。
17. 前記ローカルメモリにおける前記テーブル構造を、複数Ｐ個の親ページを含むよう構成することをさらに含み、前記Ｐ個の親ページの各々は、前記Ｍ個の最下位レベルページの異なるシーケンシャルなサブセットに対するページレベル検証コードを記憶し、前記方法はさらに、
    各親ページに記憶される前記ページレベル検証コードに応答して、親ページレベル検証コードを生成することと、
    前記親ページレベル検証コードを用いて、各ページに記憶される前記ページレベル検証コードを認証することとを含む、請求項１６に記載の方法。
18. 前記ローカルメモリにおける前記テーブル構造を、前記Ｐ個の親ページの各々に対する親ページレベル検証コードを記憶するマスターページを含むよう構成することと、
    前記マスターページに記憶される前記親ページレベル検証コードに応答して、マスター検証コードを生成することと、
    前記マスター検証コードを用いて、前記マスターページに記憶される前記親ページレベル検証コードを認証することとをさらに含む、請求項１７に記載の方法。
19. 前記検証コードは、関連付けられるユーザデータブロックのユーザデータコンテンツを合計し、前記合計されたユーザデータコンテンツと前記関連付けられるユーザデータブロックの論理ブロックアドレス（ＬＢＡ）との排他的論理和（ＸＯＲ）組合わせを実行することにより形成されるＩＯＥＤＣ（入力／出力エラー検出コード）値として特徴付けられる、請求項１４に記載の方法。
20. 前記検証コードは異なる第１および第２の部分に分割され、前記第１の部分は前記第２の部分を伴わずに前記ローカルメモリにおける前記テーブル構造において記憶され、前記第２の部分は前記第１の部分を伴わずに前記メインメモリにおいて記憶される、請求項１４に記載の方法。

Images