JP2008544343A - フラッシュメモリシステムの迅速なスリープ解除を促進するための方法およびシステム - Google Patents

Abstract

【課題】フラッシュデータ構造の完全性を損なわずに、フラッシュメモリシステムの迅速なスリープ解除を常に保証できる方法を得る。
【解決手段】フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持するための方法、システムおよびコンピュータ可読コードが開示される。少なくとも１つのフラッシュ管理テーブルおよびイベントログの両方が、フラッシュメモリに維持される。少なくとも１つの時点に関し、最近格納されたフラッシュメモリテーブルが、フラッシュメモリシステムの以前の状態を示し、一方で、以前の状態より最近の少なくとも１つのイベントが、イベントログに格納される。電源投入時に、フラッシュ管理テーブルは、フラッシュメモリから検索される。フラッシュメモリテーブルの最近のイベントが、イベントログの最近のイベントより以前の場合には、フラッシュメモリテーブルを更新するために、イベントがイベントログから検索される。場合により、更新されたフラッシュメモリテーブルは、フラッシュメモリに保存される。
【選択図】図１

Description

本発明は、フラッシュメモリ管理システムのスリープ解除を促進するのに有用なデータ構造を維持するための方法およびシステムに関する。

ラッセル（Ｌａｓｓｅｒ）の「フラッシュメモリシステムの迅速スリープ解除方法（Ｍｅｔｈｏｄ Ｆｏｒ Ｆａｓｔ Ｗａｋｅ−Ｕｐ ｏｆ ａ Ｆｌａｓｈ Ｍｅｍｏｒｙ Ｓｙｓｔｅｍ）」なる名称の米国特許公報第６，５１０，４８８号明細書は、たとえフラッシュシステムソフトウェアが、ゼロからの生成には時間のかかる管理テーブルに依存していても、フラッシュメモリシステムが、その電源投入後に迅速なスリープ解除時間を達成できるようにする方法およびシステムを開示す。この迅速なスリープ解除時間は、データの完全性を犠牲にせずに達成される。ラッセル（Ｌａｓｓｅｒ）の前述の特許は、本明細書に完全に述べられているかのように、あらゆる目的のために参照により組み込まれている。

ラッセル（Ｌａｓｓｅｒ）が説明しているように、コンピュータデータ記憶装置のためにフラッシュメモリ素子を用いることには、従来的に、ホストコンピュータのオペレーティングシステムと装置の低レベルアクセスルーチンとの間に位置するあるソフトウェア変換層が必要である。これは、フラッシュ技術にはいくつかの使用上の制約があり、これらの制約のために、単純なランダムアクセス線形方法でフラッシュ技術を利用することが不可能になるからである。かかる制約の一つが、任意の所望のメモリ位置にランダムに上書きできないことである。したがって、新しい内容をフラッシュメモリ位置に書き込むには、最初に、その位置を含む全ブロックを消去（まだ必要な任意の他の位置の内容を保存して）し、そのときになって始めて、新しい内容を書き込むことが必要になる場合がある。

変換層は、独立したデータセクタのランダムアクセスによってアドレス指定が可能なアレイの仮想ビューを、ホストのオペレーティングシステムに提示する一方で、フラッシュ媒体における実際の位置へのこれら仮想アドレスのマッピングの詳細を隠蔽して管理する。この変換機構は、決して平凡なものではなく、かかるフラッシュメモリ変換層の例が、アミール・バン（Ａｍｉｒ
Ｂａｎ）の米国特許公報第５，９３７，４２５号明細書に開示されており、またこの特許は、本明細書に完全に述べられているかのように組み込まれている。バン（Ｂａｎ）は、仮想フラッシュアドレスと物理フラッシュアドレスとの間でマッピング機構を実現する方法を示す。かかるシステムの別の例が、米国特許公報第６，６７８，７８５号明細書に開示されており、この特許もまた、本明細書に完全に述べられているかのように組み込まれている。

変換プロセスは、ホストコンピュータのデータアクセス要求を実際のフラッシュアクセス要求に変換するために必要な情報をフラッシュシステムソフトウェアに提供する内部変換テーブルに依存する。これらのテーブルは、フラッシュ素子内に格納された制御情報に基づいて、システムスのリープ解除中（または、ホストのソフトウェアが要求する場合には、それより後で）にソフトウェアによって構成される。かかるテーブルを構成せず、代わりにフラッシュからの生の制御データのみを利用することが理論上は可能であるが、これは、アクセス要求に対する応答時間が遅すぎるので、実際上は利用できない。これが遅すぎるのは、フラッシュにおけるデータへのアクセスが、通常のコンピュータＲＡＭメモリにおけるデータへのアクセスよりずっと遅いからであり、またメモリテーブルが、通常、実行時に必要な動作タイプにおける効率のために最適化されるのに対して、フラッシュに格納された制御データは、そのようにされないからである。

たとえば、フラッシュ物理ユニットは、自身にマッピングされた仮想ユニットの番号を含むことができる。プログラムの実行時に、仮想ユニット番号を、その物理的対応物に変換する必要が頻繁にあり得る。フラッシュに格納された制御データにのみ依存しなければならない場合には、指定の仮想ユニット番号を備えたユニットを見つけるまで全てのユニットを走査しなければならない可能性があり、これは、単純な媒体アクセスの標準からすれば、非常に長いプロセスである。しかしながら、システムのスリープ解除時にフラッシュ素子を１回走査し、かつ各仮想ユニット番号を対応する物理ユニット番号にマッピングするテーブルを構成することによって、後で、かかるマッピングを非常に効率的に行うことができる。

問題は、システムのスリープ解除時にフラッシュデータ記憶装置を走査するには、特に大容量装置では、長時間を要するということである。これは、ユーザが速やかなターンオンを期待するシステムおよび装置（すなわち、携帯電話、ＰＤＡ等）にとって、特に厄介である。ただ単にテーブルをフラッシュに格納することは、コンピュータ実行可能コードであって、ユーザが変更できないコードだけを格納するフラッシュ素子などの読み出し専用装置に対しては効果があり得る。しかしながら、ただ単にテーブルをフラッシュに格納することは、頻繁に変化する可能性があるデータ（ＰＤＡ内のテキストファイルまたはスプレッドシート）を格納するために使用される装置を用いる場合には、成功しないであろう。これが成功しないのは、継続的に装置に書き込んで、その内容を変更する場合には、変換テーブルの内容もまた変化するからである。フラッシュ内のテーブルがメモリ内で変化する度にそのコピーを更新することは、生じるオーバーヘッドがシステムをかなり遅くするので、実際的ではない。したがって、フラッシュに格納されたテーブルとメモリ内の「正確な」テーブルとの間の相違が蓄積される。ここで、ユーザが電源を切り、次に、テーブルを更新せずに再び電源を入れた場合には、ソフトウェアは、フラッシュから不正確な変換テーブルを読み出すことになり、結果として、新しいデータを書き込むときに、データ損失が生じる可能性がある。

ラッセル（Ｌａｓｓｅｒ）が開示するいくつかの実施形態によれば、この問題は、フラッシュに変換テーブルを格納すること、および変換テーブルを読み出すときにはいつも検出可能であるようなやり方で、ソフトウェアが変換テーブルを無効にする何らかの手段を追加することによって、解決してもよい。可能なインプリメンテーション（しかし唯一のインプリメンテーションではない）には、全てのエントリの合計をある決まった既知の値に等しくするチェックサム値を追加するか、または格納テーブルに妥当性フラグを加えることが含まれる。さらに、システムをシャットダウンする前に、変換層における特定の機能を呼び出すようにアプリケーションソフトウェアに要求すべきである。

これらの方法で、フラッシュメモリ素子は、システムが正常にシャットダウンした場合に、迅速なスリープ解除を開始することができ、システムが異常にシャットダウンした場合に、通常のスリープ解除に戻ることができる。

この解決法は、多くのケースに対して有用であるが、この解決法が不適切になり得る状況がある。この解決法が不適切になり得る第１の例は、突然の電源異常が頻繁にあり、電源投入イベントの多く（または大部分さえ）が、無効な格納テーブルに遭遇し、遅い通常のスリープ解除に帰着すると予想される場合である。

この解決法が不適切になり得る第２の例は、フラッシュメモリシステムをホストする機器のオペレーティングシステムが、正常なディスマウントまたはシャットダウンのためのサービスを、ソフトウェアアプリケーションに提供しない場合である。リナックスのような複雑なオペレーティングシステムは、かかるサービスを提供するが、電源投入で記憶システムを起動するように設計され、それを決してシャットダウンしない多くのより単純でより小さなオペレーティングシステムがある。かかる場合には、ラッセル（Ｌａｓｓｅｒ）の方法は、フラッシュ管理システムの通常のスリープ解除を行うシステム電源投入に全て帰着し、これらの方法からは何も得られない。

この解決法が不適切になり得る第３の例は、システムの電源を入れることと、システムに動作の準備をさせることとの間の時間間隔の長さに厳密な制限がある場合である。したがって、電源異常がまれで、ほとんど全ての電源投入のケースがフラッシュ管理システムの迅速なスリープ解除に帰着する場合であっても、電源異常が後で通常の電源投入シーケンスをもたらすことは、この発生がどれほどまれかにかかわらず、やはり許容できない。

本開示のために、用語「ブロック」は、単一動作で消去できるフラッシュメモリの最小単位として定義される。用語「ページ」は、単一動作で書き込む（「プログラムする」ともいう）ことができるフラッシュメモリの最小単位として定義される。典型的には、ブロックには多くのページが含まれる。

本開示のために、用語「フラッシュ管理システム」および「フラッシュファイルシステム」は、同義語であり、区別なく用いてもよい。これらの用語のそれぞれは、フラッシュメモリ素子におけるデータの記憶を管理するソフトウェアモジュールを指し、このことは、モジュールによってエクスポートされるインタフェースが、（「ファイルオープン」もしくは「ファイル書き込み」のようなコマンドを備えた）ファイル指向か、または（「ブロック読み出し」もしくは「ブロック書き込み」のようコマンドを備えた）ブロック指向であるかどうかにかかわらず、またソフトウェアモジュールが、もっぱらフラッシュ管理専用のコントローラで動作するか、または記憶システムを用いるアプリケーションが走行しているのと同じホストコンピュータで動作するかにかかわらない。

したがって、フラッシュデータ構造の完全性を損なわずに、フラッシュメモリシステムの迅速なスリープ解除を常に保証できる方法およびシステムの広く認識された必要性があり、この方法およびシステムを有することは、非常に有利であろう。

前述の必要性のいくつかまたは全ておよび他の必要性を、本発明のいくつかの態様によって満たすことが可能である。

ここで本発明者が開示する技術によって、１つまたは複数のフラッシュ管理テーブルが、フラッシュメモリシステムの全てのイベント後ではなく、いくつかのイベント後に、更新されて不揮発性フラッシュメモリに保存される。スリープ解除のときに、不揮発性フラッシュに格納された所与のフラッシュ管理テーブルが古い情報を含むと判明した場合にも、格納されたテーブルを用いて、システムのスリープ解除を促進することがやはり可能であり、古いテーブルを無効にする必要がない。このテーブルを無効にする代わりに、シャットダウンおよび／または電源喪失の前にフラッシュメモリに保存された古いフラッシュメモリテーブルを、スリープ解除のときに用いて、「適切な」テーブル（すなわち、システムの現在の状態を反映した）を再構築してもよい。特定の実施形態において、これは、イベントログを同時にフラッシュメモリに維持することによって実行される。電源喪失またはシャットダウン前に正常な終了がたとえなかったとしても、スリープ解除のときに、イベントログに格納されたデータを用いてフラッシュメモリテーブルを更新し、それによって、データの完全性を維持することができる。特定の実施形態において、フラッシュメモリに格納された「古い」テーブルから「最新」テーブルを導き出すことは、フラッシュ記憶装置を走査することによって最新テーブルを構成することより速くなる可能性がある。

ここで、フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持する方法を初めて開示する。今開示する方法には、（ａ）自身の内容がフラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持することと、（ｂ）イベントログをフラッシュメモリに維持することであって、少なくとも１つの時点に関し、（ｉ）最近格納された少なくとも１つのフラッシュ管理テーブルが、フラッシュメモリシステムの以前の状態を示し、（ｉｉ）この少なくとも以前の状態より最近の少なくとも１つのイベントが、少なくとも１つのイベントログに格納されることと、が含まれる。

いくつかの実施形態によれば、少なくとも１つの時点中に、最近のイベントが、イベントログに格納される。

いくつかの実施形態によれば、少なくとも１つの時点中に、フラッシュメモリシステムの現在の状態が、格納されたイベントログおよび格納された少なくとも１つのフラッシュ管理テーブルの内容に反映される。この特徴は、たとえばスリープ解除のときなど、更新されたフラッシュ管理テーブルが後で構成されるように、データの完全性を維持するために有用であり得る。

いくつかの実施形態によれば、今開示する方法には、（ｃ）以前の状態を示す少なくとも１つのテーブルおよびイベントログから、フラッシュメモリシステムのより現在に近い状態を示す少なくとも１つのテーブルを生成することがさらに含まれる。

いくつかの実施形態によれば、より現在に近い状態は、生成時のフラッシュメモリシステムの最も現在に近い状態である。

いくつかの実施形態によれば、生成は、スリープ解除のときに達成される。

いくつかの実施形態によれば、少なくとも１つの管理テーブルを維持することには、少なくとも１つの時点とは異なる別の時点で、少なくとも１つのフラッシュ管理テーブルを、イベントログの最後に記録されたイベントに同期させることが含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルをフラッシュメモリに維持することには、フラッシュメモリにおいて、少なくとも１つのフラッシュ管理テーブルを現在の状態へ定期的に同期させることが含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルをフラッシュメモリに維持することには、フラッシュメモリシステムのＮ（ここでＮ≧２）番目の状態変化ごとに、フラッシュメモリにおいて、少なくとも１つのフラッシュ管理テーブルを現在の状態に同期させることが含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルをフラッシュメモリに維持することには、ｉ）第１の所定のタイプの状態変化が発生すると、フラッシュメモリにおいて、少なくとも１つのフラッシュ管理テーブルを現在の状態へ同期させることと、ｉｉ）第２の所定のタイプの状態変化が発生すると、フラッシュメモリにおいて、少なくとも１つのフラッシュ管理テーブルを現在の状態へ同期させないことと、が含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルが、フラッシュメモリにおいて更新される頻度は、フラッシュメモリシステムの資源の利用可能性に従って決定される。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルには、仮想ブロック番号を物理ブロック番号にマッピングする変換テーブルが含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルには、フリーブロックテーブルが含まれる。

いくつかの実施形態によれば、維持には、複数のフラッシュ管理テーブルをフラッシュメモリに維持することが含まれる。

いくつかの実施形態によれば、イベントログをフラッシュメモリに維持することには、フラッシュメモリのより迅速な書き込みモードを用いて、フラッシュメモリにデータを書き込むことが含まれる。

いくつかの実施形態によれば、フラッシュメモリは、ＭＬＣおよびＳＬＣモードの両方を提供し、またイベントログをフラッシュメモリに維持することは、ＳＬＣモードを用いて実行される。

いくつかの実施形態によれば、ログの維持は、フラッシュメモリシステムのキャッシュ動作の一部として実行される。

フラッシュメモリシステムにおけるスリープ解除の方法を今初めて開示する。今開示する方法には、Ｉ）スリープ解除のときに、（ａ）フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出すことと、（ｂ）フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログをフラッシュメモリから読み出すことと、（ｃ）イベントログに格納された少なくとも１つのイベントに関し、少なくとも１つのイベントによってもたらされた変化に従って少なくとも１つのフラッシュ管理テーブルを更新することと、が含まれる。

いくつかの実施形態によれば、更新は、少なくとも１つのフラッシュ管理テーブルがイベントログの最近のイベントに従って更新されるまで繰り返される。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルには、仮想ブロック番号を物理ブロック番号にマッピングする変換テーブルが含まれる。

いくつかの実施形態によれば、少なくとも１つのフラッシュ管理テーブルには、フリーブロックテーブルが含まれる。

いくつかの実施形態によれば、複数のフラッシュ管理テーブルが、フラッシュメモリから読み出されて更新される。

今初めて開示するフラッシュメモリシステムには、（ａ）データを格納するためのフラッシュメモリと、（ｂ）フラッシュメモリにアクセスするために用いられるデータ構造を維持するためのフラッシュ管理ソフトウェアとが含まれるが、この場合に、フラッシュ管理ソフトウェアは、ｉ）自身の内容がフラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持するように、ｂ）少なくとも１つの時点に関し、Ｉ）最近格納された少なくとも１つのフラッシュ管理テーブルが、フラッシュメモリシステムの以前の状態を示し、ＩＩ）以前の状態より最近の少なくとも１つのイベントがイベントログに格納されるようにイベントログをフラッシュメモリに維持するように、動作する。

今初めて開示するフラッシュメモリシステムには、（ａ）データを格納するためのフラッシュメモリと、（ｂ）フラッシュメモリにアクセスするために用いられる少なくとも１つのデータ構造を維持するためのフラッシュ管理ソフトウェアとが含まれるが、この場合に、スリープ解除のときに、フラッシュ管理ソフトウェアは、（ｉ）フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出すように、（ｉｉ）フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログをフラッシュメモリから読み出すように、（ｉｉｉ）イベントログに格納された少なくとも１つのイベントに関し、少なくとも１つのイベントによってもたらされた変化に従って少なくとも１つのフラッシュ管理テーブルを更新するように、動作する。

今初めて開示するコンピュータ可読記憶媒体は、コンピュータ可読コードを自身に具現し、このコンピュータ可読コードは、フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持するための命令を含むが、この場合に、これらの命令には、（ａ）自身の内容がフラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持する命令、（ｂ）イベントログをフラッシュメモリに維持する命令であって、少なくとも１つの時点に関し、（ｉ）最近格納された少なくとも１つのフラッシュ管理テーブルが、フラッシュメモリシステムの以前の状態を示し、（ｉｉ）以前の状態より最近の少なくとも１つのイベントをイベントログに格納する命令が含まれる。

今初めて開示するコンピュータ可読記憶媒体は、コンピュータ可読コードを自身に具現し、このコンピュータ可読コードは、フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持するための命令を含むが、この場合に、これらの命令には、（Ｉ）スリープ解除のときに、（ａ）フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出す命令、（ｂ）フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログをフラッシュメモリから読み出す命令、（ｃ）イベントログに格納された少なくとも１つのイベントに関し、少なくとも１つのイベントによってもたらされた変化に従って少なくとも１つのフラッシュ管理テーブルを更新する命令が含まれる。

フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持する方法を今初めて開示するが、この方法には、（ａ）自身の内容がフラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持することと、（ｂ）イベントログをフラッシュメモリに維持することと、（ｃ）少なくとも１つのフラッシュ管理テーブルの維持と同時に、イベントログの特定のイベントを一意に識別するデータをフラッシュメモリに維持することと、が含まれる。

いくつかの実施形態において、特定のイベントは、少なくとも１つのテーブルの内容に対応する最近のイベント（たとえば、テーブルの内容に影響を及ぼし、かつ／または内容を修正した最近のイベント）である。

フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持する方法を今初めて開示する。今開示する方法には、（ａ）自身の内容がフラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持することと、（ｂ）イベントログをフラッシュメモリに維持することと、（ｃ）イベントログの維持と同時に、イベントログの特定のイベントを一意に識別するデータをフラッシュメモリに維持することと、が含まれる。

いくつかの実施形態によれば、データの一意の識別を維持することには、イベントログの最近のイベントの印をフラッシュメモリに維持することが含まれる。

これらおよびさらなる実施形態が、以下の詳細な説明および実例から明白になるであろう。

ここで、特定の例示的な実施形態の点から本発明を説明する。本発明が、開示される例示的な実施形態に限定されないことを理解されたい。また、フラッシュメモリシステムのイベントに従ってデータ構造を維持するための今開示する方法、装置およびコンピュータ可読コードの全ての特徴が、添付の特許請求の範囲における任意の特定の１つにおいて請求されるように本発明を実施するのに必要だとは限らないことも、理解されたい。装置の様々な要素および特徴が、本発明を完全に可能にするために説明される。また、プロセスまたは方法が図示または説明される本開示の全体を通して、一ステップが、最初に実行される別のステップに依存することが文脈から明らかでない場合、本方法のステップは任意の順序でか、または同時に実行してもよいことも理解されたい。

データ構造を維持するための今開示する方法、装置およびコンピュータ可読コードは、たとえば、電源異常に頻繁に遭遇する可能性がある環境において、フラッシュメモリシステムの「迅速なスリープ解除」を促進するのに有用であり得る。しかしながら、これは、本発明の限定として解釈すべきではなく、フラッシュメモリシステムデータ構造を維持するための今開示する技術の１つの非限定的適用として単に開示される。

より具体的には、今開示する技術は、予期しない電源異常が頻繁に発生する条件下であっても、データの完全性を犠牲にせずに、フラッシュ管理システムの迅速なスリープ解除を提供するために用いることができる。

図１は、本発明のいくつかの実施形態による非限定的で例示的なフラッシュメモリシステム１００のブロック図である。この例示的なシステムには、データを格納するためのメモリモジュール１２０と、ホストインタフェース１８０を介してメモリモジュール１２０と通信するホスト装置１１０（たとえば、マイクロコンピュータ、スマートカード端末または任意の他の装置）と、が含まれる。

メモリモジュールには、任意のタイプのフラッシュメモリ１３０だけでなく、ホストインタフェース１８０を通して受信される読み出しおよび／または書き込みおよび／または消去要求に従ってフラッシュメモリにアクセスするコントローラ１４０が含まれる。図１に示す例に関し、コントローラには、ＣＰＵ１５０と、（ＣＰＵによって実行されるコードが格納される）ＲＯＭ１６０と、ＣＰＵによるコードの実行をサポートするためにＣＰＵによって用いられるＲＡＭ１７０と、が含まれる。

非限定的な例のブロックである図１は、セキュアデジタル（ＳｅｃｕｒｅＤｉｇｉｔａｌ）フラッシュメモリカードまたは携帯ＵＳＢフラッシュドライブなどの典型的な不揮発性記憶モジュールを表わしている。

＜フラッシュ管理テーブル＞
フラッシュメモリシステム１００が、典型的には、揮発性メモリに、たとえばメモリモジュール１２０のＲＡＭ１７０にか、ホスト装置１１０のＲＡＭにか、または任意の他の適切な位置に、１つまたは複数のフラッシュ管理テーブルを格納することが注目される。かかるフラッシュ管理テーブルの非限定的一例は、仮想ブロック番号から物理ブロック番号へのアドレス変換、すなわち、たとえば米国特許第５，９３７，４２５号明細書のシステムにおけるように、多くのフラッシュ管理システムに存在するマッピングを提供する変換テーブルである。同じ概念および方法がまた、任意の他のタイプのフラッシュ管理テーブル、たとえば、どのブロックが自由に利用でき、どのブロックができないかを表わすフリーブロックテーブル、仮想ブロック番号から１つまたは複数の物理ブロック番号のグループへのマッピングを表わすテーブル等に適用できることが注目される。

本開示に関し、「フラッシュ管理テーブル」は、フラッシュ管理システムが自身のアルゴリズムの動作をサポートするために用いるデータを含む任意のテーブルであるが、この場合に、任意の特定の時点におけるテーブルのデータは、その特定の時点における記憶システムの状態のある態様を表わす。たとえば、フラッシュ管理テーブルが、フラッシュメモリの各ブロックごとのビットを含むテーブルであり、このビットが、対応するブロックが自由に利用できるかどうかを示す場合には、第１の時点におけるテーブルの内容は、その時点で、どのブロックが自由で、どのブロックが自由でないかに関するシステム状態の態様を表わす第１のビットパターンである。後の時点で、そのテーブルにおけるビットパターンは、第１の時点と異なり、いくつかのフリーブロックが非フリーになり、かついくつかの非フリーブロックがフリーになることによってもたらされるフリーおよび非フリーブロックの異なる混合を意味してもよい。

経時的に、フラッシュメモリに格納されるデータは変化してもよく、フラッシュメモリに関連する様々な補助データもまた変化してもよい。フラッシュメモリシステムの「状態」は、フラッシュ管理システムの異なるイベント（たとえば、書き込み要求、ハウスキーピング動作等）が生じると共に経時的に変化する。

各フラッシュ管理テーブルが、フラッシュ管理システムの全体的な「状態」の１つまたは複数の態様を表わすことが注目される。したがって、任意の所与のフラッシュ管理テーブルまたはテーブルセットは、システムの完全な状態を必ずしも表わさず、そのある態様だけを表わす。上述のフリーブロックテーブルの例において、どのブロックがフリーで、どのブロックがフリーでないかの知識は、システムの完全な状態を定義するためには、確かに十分ではない。非フリーブロックは、１つの使用済みページを含むだけかも知れないし、またはそのブロックの全てのページが、有効データを書き込まれているかも知れない。これは、フリーブロックテーブルによって反映されず、他のフラッシュ管理テーブルによってか、または何か他の手段によって反映されるが、しかしやはりこのテーブルは、システム状態のある態様を表わし、したがって、フラッシュ管理テーブルの定義内に入る。

したがって、フラッシュメモリシステムの「現在の状態」または「以前の状態」または「後の状態」または「最近の状態」を表わす特定のフラッシュメモリテーブルが、揮発性または不揮発性メモリに格納される場合には、これは、特定のフラッシュメモリテーブルによって表わされるフラッシュメモリシステムの態様の「以前」または「現在」または「後」または「最近」の状態を表わす。

経時的に、フラッシュ管理テーブルは一連の状態間を移動するが、各状態は、所与の時点に対して、その時点におけるフラッシュメモリシステムの１つまたは複数の態様を表わす。テーブルによってモデル化されるシステム状態の態様は、フラッシュメモリシステムのイベントに対応する明確な転移点を備えた別個の状態間を切り替わる。

＜例示的なフラッシュ管理テーブル＞
図２Ａは、第１の時点（ｔ＝ｔ_１）において、仮想ブロック番号を物理ブロック番号にマッピングする例示的なフラッシュ管理テーブルの内容を示す。テーブルは、仮想ブロック番号によってインデックスを付けられ、また対応する仮想ブロックのデータを現在含む物理ブロック番号を生成する。実際のインプリメンテーションでは、仮想ブロック番号を格納するためのスペースを割り当てる必要がない場合もある。なぜなら、テーブルは、これらの仮想ブロック番号によって順序よく並べられ、したがって、正しいエントリに直接インデックスを付けられ得るからである。しかしながら、説明の利便性のために、テーブルは、両方の列が物理的に表わされるかのように示される。

図２Ａに表わす仮想対物理マッピングの状態は、仮想ブロック番号２にアクセスする必要がある場合には、テーブルが、対応する物理ブロックがブロック番号１７２であると教えてくれるようなものである。ある時点において、フラッシュ管理システムに送られるコマンド（またはガーベジコレクション動作などの外部コマンドなしであってもシステムによって行われる内部ハウスキーピング動作）が、マッピングを変化させてもよい。たとえば、新しいデータを仮想ブロック番号２に書き込み、かくして、その番号の前のデータに上書きするコマンドが、フラッシュ管理システムに、仮想ブロック番号２に対応する別の物理ブロックを割り当てさせてもよく、その結果、新しいデータは、そのブロックへ格納される。

図２Ｂは、この変化が後の時点（ｔ＝ｔ_２）で発生した後の仮想対物理フラッシュ管理テーブルの内容を示す。今や、仮想ブロック番号２は、テーブルにおいて、物理ブロック番号７７７に対応し、もはや物理ブロック１７２には対応しない。かくして、テーブルは、第１の状態から第２の状態へ切り替わった。フラッシュ管理テーブルの内容におけるどんな変化も、そのテーブルの状態変化として定義される。

フラッシュ管理システムに生じる全ての書き込み動作が、システムの全てのフラッシュ管理テーブルにおける状態変化を引き起こすというのは事実でないことを強調すべきである。たとえば、物理ブロック１７２が、そのページのいくつかを利用しておらず、またフラッシュ管理システムのアルゴリズムに従って新しいデータが物理ブロック１７２のこれらの未利用のページへ格納されるように、書き込み動作が仮想ブロック番号２に向けられる場合には、仮想対物理マッピングには変更がなされず、テーブルは、その書き込み動作のあと、不変のままである。したがって、フラッシュ管理テーブルの状態変化の割合は、典型的には、システム内で実行される動作の割合より低い。また、多数のフラッシュ管理テーブル（それぞれが、システムの状態の異なる態様を表わす）が、同じフラッシュ管理システム内に維持される場合には、テーブルのそれぞれは、異なる時点でその状態を変化させてもよい。

＜スリープ解除のときに有用なデータ構造（すなわちテーブルおよびイベントログ）の格納＞
上記のように、電源投入後にシステムを初期化する場合に、管理ソフトウェアは、それが用いる任意のフラッシュ管理テーブルの完全に更新されたコピーをＲＡＭに作成することが必要になり得る。システムの迅速なスリープ解除を達成するためには、記憶システムのブロック全体にわたって分散されたデータからのみテーブルの内容を再生成することは、通常、許容できない。なぜなら、これは遅すぎるからである。テーブルの状態が変化するたびに、テーブルのコピーを不揮発性フラッシュメモリに保存するという根本的に異なる代替案もまた、許容することができない。なぜなら、それは、高オーバーヘッドを追加し、システム性能を低減させるからである。

本発明の様々な実施形態によって提供される技術は、これらの２つの先行技術のアプローチ間に歩み寄りをもたらす。かくして、フラッシュ管理テーブルは、いくつかの状態変化に対してのみ不揮発性フラッシュメモリに保存してもよいが、状態変化があるたびごとではない。

これを図３に示すが、図３は、本発明のいくつかの実施形態に従って、フラッシュ管理システムのデータ構造をフラッシュメモリに維持するための例示的なルーチンを説明している。本明細書で用いる限りでは、「フラッシュメモリに維持すること」には、フラッシュメモリに格納することが含まれる。典型的には、フラッシュメモリに維持することには、テーブルを揮発性メモリ／ＲＡＭに格納するために、テーブルおよび／または関連データを維持することと、複数の時点に対して、テーブルの更新された（すなわち、フラッシュメモリシステムの現在状況に同期された）バージョンをフラッシュメモリに保存することと、が含まれる。

図３の非限定的実施形態によると、システムは、非限定的実施形態において、いくつかの時点でアイドルであってもよく、またシステムは、次のイベントを待ってもよい２０６。フラッシュ管理システムのイベントを処理すると２１０、典型的には、１つまたは複数のテーブルが、発生したイベントに従って揮発性メモリにおいて更新される２１４。これらのテーブルは、所与のイベント後に、不揮発性フラッシュにおいて更新してもしなくてもよい。

＜例示的なイベントログの説明＞
ここで本発明者は、全てのイベントではなく、いくつかのイベントの発生後にフラッシュ管理テーブルが保存される状況において、イベントログをフラッシュメモリに維持することがまた有用であり得ることを開示する。例示的な実施形態において、このイベントログには、複数の記録が含まれ、各記録には、フラッシュ管理システムの特定のイベントを説明するデータが含まれる。本発明を限定するわけではないが、典型的には、このイベントログが、各イベント後にフラッシュメモリにおいて更新されることが注目される。これは、更新された（すなわち、フラッシュメモリシステムの最新のイベントに従って更新された）テーブルが、フラッシュメモリに必ずしも保存されるとは限らない状況に対して、データの完全性を維持するために有用であり得る。

典型的には任意の所与の瞬間にデータの完全性が提供される（すなわち、たとえ電源喪失があった場合でも）実施形態については、以下の条件の１つが真である。すなわち、ａ）最近のイベントに従って更新されたテーブルが不揮発性フラッシュに格納されることと、ｂ）以前の状態（すなわち最近のイベントより以前、すなわち「以前の」イベント以後に他のイベントが、フラッシュメモリシステムにおいて発生した）に従って更新されたテーブルが、フラッシュメモリに格納され、フラッシュメモリに格納されたイベントログに、「以前のイベント」の時点以後に発生した全てのイベントの記録が含まれることとである。

イベントログの例示的な一インプリメンテーションが、順次キューであるが、この順次キューでは、外部書き込みコマンドであれ内部ハウスキーピング動作であれ状態に影響する任意の他のイベントであれ、システムの状態（すなわち、１つまたは複数のフラッシュ管理テーブルに格納された「システムの少なくとも１つの態様」の状態）に影響する全てのイベントが登録される。図４に図示する、かかる順次イベントログの非限定的で可能なインプリメンテーションが、最上位アドレスに達した後で最下位アドレスへ折り返す循環キューである。図４の例によれば、循環キューのサイズは、「Ｍ」（Ｍイベントまで格納可能）である。

図４の例によれば、典型的にはフラッシュには、２つのポインタが維持される。１つのポインタ（図４ではイベントＭ−２を指す）が、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}として表示されている。このポインタは、ログに最後に登録されたエントリを指す。新しいエントリをログに追加する必要が有る場合にはいつでも、ポインタは、最初に、次のエントリ位置を指すように循環的に増分され（図３のステップ２１８）、次に、新しいエントリ（図３のステップ２２２）が、エントリポイントに記録される。

フラッシュメモリシステムのイベントをイベントログに反復的に記録すること２２２が、「イベントログをフラッシュメモリに維持する」として定義されることが注目される。

典型的には、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}は、（Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}の位置を決定できるように、ログに指示データを格納することによって明確にまたは暗黙のうちに）フラッシュに保存される２１８。一例では、明確なＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}はなく、イベントログは、追加情報を必要とせずに、その内容を走査することによってその最新のエントリを識別できるように構築される。この例によれば、この特徴は、各エントリ内に「生成」フィールドを含めることによって容易に実現できるが、この生成は、各連続的エントリに基づいて増加する数である。次に、ログの最新エントリは、最も高い生成フィールドを備えたエントリである。また、この特徴を実現するための他のインプリメンテーション（たとえば、明確なＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}を格納すること）もまた可能である。

Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}を示すデータは、フラッシュの任意の位置に格納してもよく、また必ずしもフラッシュの単一の位置にイベントログと共に格納しなくてもよいことが理解される。

「循環キュー」の非限定的な例によれば、ログに割り当てられるスペースが、任意のフラッシュ管理テーブルの２つの連続的な保存動作の間に決して一杯にならないほど大きい場合には、キューの内容を監視する必要はなく、新しいエントリは、キューの端部における最古のエントリに安全に上書きすることができる。

ここで、図４における第２のＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}を説明する。図３に示すように、フラッシュ管理テーブルは、フラッシュメモリシステムの全てのイベントではなくいくつかのイベントに対して（すなわち、「テーブル保存」条件が満たされた２２６イベントに対してだけ−この条件は以下で解説する）、フラッシュに保存される２３０。したがって、いくつかの実施形態において、フラッシュ管理テーブルが不揮発性フラッシュに保存されるときはいつでも、最近のイベントの更新された指示Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}もまた保存される２３４。このときに、不揮発性フラッシュに保存されるフラッシュ管理テーブルは、フラッシュメモリシステムの「最新状態」または「最新イベントに同期される」と言われる。このときに、図４に示す「ギャップ」は消える。

更新されたテーブルを（少なくとも１つのイベントのために）フラッシュメモリに保存せずに、ログが引き続き更新される場合には、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}は、（Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}によって表わされる）最近のイベントから遅れ始め、ギャップが再現される。

ステップ２３０を参照すると、フラッシュメモリシステムの現在の状態を示すテーブルが、不揮発性フラッシュに保存される場合には、これは、「フラッシュメモリにおけるテーブルを現在の状態に同期させる」こととしてが定義されることが注目される。

全体として、フラッシュ管理テーブルが、様々なイベント後に（しかし必ずしも全てのイベント後ではない）フラッシュメモリに格納されるプロセスは、「テーブルをフラッシュメモリに維持する」こととして定義される。したがって、異なる時点には、フラッシュ管理テーブルの別のバージョン（典型的には、フラッシュメモリシステムの後の状態を示すそれぞれ後のバージョン）が、フラッシュメモリに格納される。したがって、「テーブルをフラッシュメモリに維持する」ことは、任意の所与の瞬間について、最近フラッシュメモリに保存されたテーブルが、フラッシュメモリシステムの現在の状態と同期されていることを必要としない。図３を調べれば、最近格納されたフラッシュメモリテーブルが、フラッシュメモリシステムの以前の状態（すなわち、より最近のイベントがフラッシュメモリシステムに発生した前のシステムの状態）を示す期間があり得ることが示される。指示Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}は、後で、たとえばフラッシュシステムの電源投入後に、フラッシュから検索してもよいことが注目される。Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}をＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}と比較することによって、保存フラッシュ管理テーブルが、システムの最近の状態（すなわちテーブルに表わされた状態の態様）を反映するかどうかを、任意の所与の時間に決定することができる。

イベントログの上記のインプリメンテーションは、非常に簡単で、実行が容易であるが、それは、可能な唯一のものではなく、他のインプリメンテーションもまた可能である。

いくつかの実施形態において、イベントログの各イベントのために記録されるデータには、システムの状態に影響をもたらしたイベントの影響を再生成するために必要な全てのデータが少なくとも含まれることが注目される。イベントに関連する実データをイベントログに記録する必要はなく、例示的な実施形態において、実データは記録されない。たとえば、イベントが、外部ホストシステムからの、１ページのデータを書き込むコマンドである場合には、ログにおける対応する記録には、書き込むべきデータではなく、書き込むべきセクタの仮想アドレスが含まれる。上記のように、いくつかの実施形態において、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}は、全てのイベントの後に保存してもよいが、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}を示すデータは、テーブルがフラッシュにおいて更新される場合で、いくつかのイベント後にのみ保存される。

＜更新されたフラッシュ管理テーブルを不揮発性フラッシュメモリにいつ保存すべきかを決定するための方針＞
更新されたテーブルがフラッシュメモリに保存されることになるイベントを構成するのは何かを決定するための任意の方針−すなわちステップ２２６の「保存条件」は、本発明の範囲内である。

本発明者は、本発明の特定の実施形態に従って多数の方針を開示する。

（図５に示す）第１の実施形態では、テーブルは、テーブルのＮ番目の状態変化ごとに保存されるが、この場合にＮは、予め決定される。Ｎは、保存オーバーヘッドが低い場合には、２ほどに小さくすることができ、またはたとえば保存オーバーヘッドが高い場合には、１００かそれを超える大きさにすることができる。したがって、図５に示すように、カウンタ変数は、ゼロに初期化される２１８。各イベント後に、このカウンタ変数は増分される２４０。カウンタ変数が所定の値Ｎを超える場合には２４４、１つまたは複数のテーブルがフラッシュメモリに保存され２３０、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}は、フラッシュメモリにおいて、イベントログにおけるイベントの最近のイベントと同期される。

（図６に示す）第２の実施形態では、（ステップ２２６に現われるような）「テーブル保存」条件は、最近のイベントによってトリガされた状態変化に従って決定される。その目的のために、状態変化は、「マイナー（小さい）」変化または「メジャー（主要な）」変化のいずれかとして分類される。テーブル状態のマイナーな変化は、テーブルの即時（すなわち、次のイベントを処理する２１０前）の保存をもたらさない（すなわち、ステップ２２６Ｂ後の「ＮＯ」ブランチ）のに対して、メジャーな変化は、即時の保存をもたらす。マイナーおよびメジャーへの変化の分類のための非限定的な例は、フリーブロックフラッシュ管理テーブルであるが、このテーブルでは、フリーブロックを非フリーブロックへ変える変化がマイナーと見なされる一方で、非フリーブロックをフリーブロックへ変える変化が、メジャーと見なされる。フラッシュ管理テーブルを不揮発性フラッシュメモリにいつ保存すべきかの方針の他の実施形態もまた可能である。

第３の実施形態では、テーブルは、定期的に、所定の時間間隔が終了したときにはいつでも保存される。テーブルがどれくらい頻繁に更新されるかと、フラッシュ管理テーブルを不揮発性フラッシュに保存する際に消費されるシステム資源量との間には、トレードオフが典型的にある。他方では、管理テーブルをより頻繁に保存することは、平均して、スリープ解除中にフラッシュメモリから検索されるテーブルが、より最新である可能性があり、それによって、より迅速なスリープ解除に備えることを意味する。任意の時間間隔が本発明の範囲内であることが注目される。例示的で非限定的な実施形態において、時間間隔は、１０分の１秒と５分以上との間である。

第４の実施形態では、テーブルが更新される頻度は、システム資源の利用可能性に従って決定される。一例において、コントローラ１４０が、多くの読み出し／書き込み／消去要求を処理する場合か、または多くのハウスキーピング動作がある期間中には、フラッシュ管理テーブルは、システム資源を節約するために、より少ない頻度で不揮発性フラッシュに保存される。システムが、事情次第でアイドルになるかまたは低レベルの使用を免れない「低使用」期間中は、フラッシュシステム性能への著しい影響なしに、フラッシュ管理テーブルを不揮発性フラッシュにより頻繁に保存することが可能になり得る。フラッシュ管理テーブルをフラッシュにより頻繁に保存することは、特に、正常な終了でなかった状況（たとえば予期しない電源喪失）において、より迅速なスリープ解除を可能にする場合がある。

全ての状態変化がテーブルの保存をトリガするとは限らないので、テーブルの最後に保存されたコピーとＲＡＭにおけるその最新のコピーとの間で、ギャップまたは不一致が、結局は生成される。テーブルが保存されるときはいつでも、ギャップは除去されて、２つのコピー（すなわち、揮発性ＲＡＭメモリにおけるコピーおよび不揮発性フラッシュに格納されたコピー）は同一になるが、しかし次に再び、テーブルの保存をもたらさない新しい状態変化が、再びギャップを生成する。

＜スリープ解除＞
いくつかの実施形態において、アプリケーションが正常に終了する場合には、更新されたフラッシュ管理テーブル（すなわち、フラッシュメモリシステムの最近のイベントに従って更新された）が、フラッシュメモリに保存される。スリープ解除のときには、これらのフラッシュ管理テーブルが、フラッシュメモリから検索される。

正常な終了でない場合には、スリープ解除のときに、フラッシュメモリから揮発性メモリへと「古い」フラッシュ管理テーブルを取り出し、次に、イベントログに格納された記録に従い、揮発性メモリにおいて、古いフラッシュ管理テーブルを更新することが可能である。

したがって、本発明によって提供される実施形態は、ラッセル（Ｌａｓｓｅｒ）の米国特許第６，５１０，４８８号明細書に開示されているように古いテーブルを無効にする必要性を除去する。

図７は、本発明のいくつかの実施形態に従って例示的なスリープ解除ルーチンを説明するフローチャートを提供する。電源投入４１０後に、フラッシュ管理システムは、フラッシュ管理テーブルの保存コピーを検索する４１４。次に、フラッシュ管理システムは、フラッシュ管理テーブルが不揮発性フラッシュに保存された時点における最近のイベントを指すＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}を検索する４１８。

次に、フラッシュ管理システムは、たとえば、イベントログを走査してその最新のエントリを識別することによってか、不揮発性フラッシュメモリから明確な値を検索することによってか、または任意の他の技術によって、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}を決定する４２２。Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}は、最後にログされたイベント、すなわちシステムがシャットダウンされる直前に終了した最新のイベントを指す。

システムが、フラッシュ管理テーブルの最後の保存の直後で、テーブルの状態の追加変化が発生する前にシャットダウンされた場合には（たとえば、「正常な終了」があった場合か、または任意の他の状況において）、２つのポインタ（すなわちＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}およびＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}）は同一のはずである。しかしながら、フラッシュ管理テーブルの１つまたは複数の状態変化が、テーブルの最後の保存後かつシステムシャットダウンの前に発生した場合には、２つのポインタ間に相違が見られるはずである。

Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}は、保存テーブルがテーブルの状態に対する影響を既に反映している、イベントログにおける最近のイベントを指す。そのイベントから、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}によって示されるログの最後のイベントまでの、ログに現われる全てのイベントは、保存テーブルにはまだ反映されていない。

この時点で、テーブルにまだ反映されていない新しいイベントを「再生」することが可能である。この目的で、イベントログからのエントリ（すなわち、最近の電源投入４１０の前にイベントログに保存された「予め格納された」イベント）を、最も古いもの（すなわち、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}によって示された）から最新のもの（すなわち、Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}によって示された）へ一つずつ読み出してもよい４３４。かかる各イベントに対して、フラッシュ管理テーブルの状態を、本来のイベントがその状態に影響したのと同じ方法で、正確に更新（たとえば揮発性メモリにおいて）してもよい４３８。この目的で、いくつかの非限定的インプリメンテーションにおいて、「一時」ポインタＰｏｉｎｔｅｒ_ＴＥＭＰを定義することが有利になり得るが、このポインタは、「イテレータ」変数として機能し、イベントログの現在処理されるイベントを指す。最初に、Ｐｏｉｎｔｅｒ_ＴＥＭＰの値は、（図８Ａに示すように）Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}４２６に設定される。

ログテーブルから検索４３４された各イベント（すなわち図８Ａ−８Ｃで示すような）に対して、各フラッシュ管理テーブル（複数ある場合）は、自身に適用される特定の状態変化を反映するように更新される４３８。イベントログに格納された各イベント（たとえば、Ｐｏｉｎｔｅｒ_ＴＥＭＰによって示された）を処理した後、ポインタ（たとえばＰｏｉｎｔｅｒ_ＴＥＭＰ）は、イベントログの次のイベントを指すように進めてもよい４４２。ひとたび最新のログエントリが処理されると（図を８Ｃを参照）、Ｐｏｉｎｔｅｒ_ＴＥＭＰ＝Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}であり、完了である。所与のログエントリが、「最新」のログエントリかどうかを決定することは、いくつかの実施形態において、「繰り返し」ポインタ（たとえばＰｏｉｎｔｅｒ_ＴＥＭＰ）の値をＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}と比較すること４３０によって達成される。

この時点で、Ｐｏｉｎｔｅｒ_ＴＥＭＰ＝Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}の場合には、今やフラッシュ管理テーブルは完全に更新され、それぞれが、システムシャットダウンの前のその最近の状態を反映する。

場合により、１つまたは複数の今や更新されたフラッシュ管理テーブルが、（更新されたＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}と共に）不揮発性フラッシュメモリに保存され４４６、その結果、（必要な場合には）テーブルの任意の将来の再生成が、現在の状態から開始する。

フラッシュメモリテーブルが、揮発性メモリおよび場合により不揮発性メモリにおいて更新されたと判定された後、次に、フラッシュメモリシステムの通常の動作を続行すること４５０が可能である。

＜性能についての全般的な解説＞
本発明のある実施形態によって提供される１つの利点は、フラッシュ管理テーブルの保存コピーの読み出し、およびテーブルの保存コピーにはまだ反映されていないログエントリの再生が、典型的には、記憶システムの多くのブロックを走査することによるゼロからのテーブルの再現より、はるかに短い時間しかかからないということである。テーブルを保存した後で、追加的な状態変化が発生する前にシステムがシャットダウンした場合には（たとえば、正常な終了があるか、またはＰｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＥＶＥＮＴ}＝Ｐｏｉｎｔｅｒ_{ＭＯＳＴ＿ＲＥＣＥＮＴ＿ＴＡＢＬＥ＿ＳＡＶＥ}のときにシャットダウンするほど「幸運」な場合には）、スリープ解除時間は、いくつかの実施形態において最も迅速で、正常なシャットダウンが行れた場合のラッセル（Ｌａｓｓｅｒ）の方法と同じであろう。しかし、たとえテーブルの最後の保存後にいくつかの状態変化が起こったとしても、システムのスリープ解除時間は、正常なシャットダウンがなかった場合のラッセル（Ｌａｓｓｅｒ）の方法に関して生じるほど悪くないであろう。多くの状況で、ログのほんの少数のエントリが読み出され、かつテーブルの状態に対するそれらの影響が再現される必要があるだけである。これにかかる正確な時間は、典型的には、再生されなければならないエントリ数に依存する。今度はこのエントリ数は、テーブルが不揮発性メモリに保存される割合に依存し得る。割合が高ければ高いほど、平均して再生すべきエントリはそれだけ少なく、平均してスリープ解除はそれだけ迅速である。他方では、保存割合が高ければ高いほど、システムの通常動作中に保存オーバーヘッドに費やされる時間はそれだけ高い。

関連する可能性がある他の一要因は、イベントログにエントリを書き込むために費やされるオーバーヘッドである。典型的には、データの完全性が提供される実施形態では、ログは、全てのイベントに関して書き込まれが、それは、ログが、フラッシュ管理テーブルの状態に影響する可能性がある全てのシステム状態変化に関して、書き込まれなければならないことを意味する。

イベントログを維持するオーバーヘッドコストは、各状態変化に対してフラッシュ管理テーブルを保存するオーバーヘッドほど高くないかどうか疑問に思うかも知れない。したがって、いくつかの実施形態において、フラッシュ管理システムは、最も迅速な書き込み方法で、イベントログにイベント記録を書き込むように設計してもよい。この目的で、フラッシュ媒体が複数の書き込みモードを提供する場合には、（イベントに対する記録のうちの少なくとも１つ、およびフラッシュ管理テーブルを示すデータを、不揮発性フラッシュメモリに書き込むための）より迅速な書き込みモードを用いることが可能である。例として、マルチレベルセル（ＭＬＣ）およびシングルレベルセル（ＳＬＣ）モードの両方を提供するフラッシュメモリ素子を用いるフラッシュシステムがある。かかる装置が、米国特許第６，４５６，５２８号明細書でチェン（Ｃｈｅｎ）によって開示されており、またこの特許は、本明細書に完全に述べられているかのように組み込まれている。システムに格納される「通常データ」（たとえば、ホスト装置１１０からの書き込み要求で送られるデータ）が、最高の記憶密度を達成するためにより遅いＭＬＣモードを用いて書き込まれる一方で、イベントログは、はるかに速いＳＬＣモードを用いて書き込まれる。

＜フラッシュメモリシステムのキャッシュ動作の一部としてのログ維持＞
いくつかの実施形態において、１つまたは複数の今開示する技術は、フラッシュ管理テーブルの要件にかかわらずとにかくイベントログを維持しなければならない状況において、特定の利点を提供することができる。これは、フラッシュ管理システムが着信データに対してキャッシングを用いる場合に事実となり得るが、この場合に、着信データは、最初、その到着時にフラッシュメモリにおける第１の位置に格納され、後で、長期記憶のための第２の位置に移動される。本明細書で用いる限りでは、「キャッシング」は、第１の位置に書き込むことである。

したがって、かかるシステムでは、第１の位置におけるデータの格納（すなわちキャッシング）は、イベントログの機能性もまた提供するように実行することができる。したがって、かかる場合には、ログを実現するための余分なオーバーヘッドコストがなく、本発明の方法の利点は最大になる。

上記の説明は、フラッシュ管理システム内の単一のフラッシュ管理テーブルに主として集中したけれども、本発明は、多数のフラッシュ管理テーブルにも等しく適用可能であり、各フラッシュ管理テーブルは、システム状態の異なる態様を表わす。多数のテーブルが存在する場合に、それぞれは、必ずしも同じ時点にではなく、それ自身の保存方式を用いて保存することができる。電源投入時に、上記の方法を用いてフラッシュ管理テーブルを再構成し、同じイベントログが全てのテーブルのためにサービスするようにしてもよい。

＜今開示したシステムについての追加的解説＞
今開示した技術は、ハードウェア、ファームウェアおよびソフトウェアの任意の組み合わせを用いて実現してもよい。

非限定的な一例において、フラッシュ管理テーブルの保存ならびに電源投入時におけるこれらのテーブルのリカバリおよび再構成は、コントローラ１４０によって、またはより正確には、ＲＯＭ１６０からのコードを実行するＣＰＵ１５０によって全て実行される。しかしながら、これは、本発明を用いるために可能な唯一のシステムアーキテクチャーではない。たとえば、本発明の方法は、ホストコンピュータ１１０において実行されるコードによって実行することが可能であるが、これは、記憶モジュールが内蔵ＮＡＮＤフラッシュ素子であり、かつスタンドアロンコントローラがない場合のケースである。別の可能性として、本発明の方法は、ホストコンピュータ１１０によって少なくとも部分的に実行され、コントローラ１４０によって部分的に実行される。これら全てのアーキテクチャおよび他の多くのものが、全て本発明の範囲内にある。

本出願の説明および特許請求の範囲において、動詞「含む」および「有する」の各々またはそれらの活用形は、動詞の目的語（単数または複数）が、必ずしも、動詞の主語（単数または複数）の部材、構成要素、要素または部分の完全なリストではないことを示すために用いられる。

本明細書に挙げた全ての参考文献は、参照によりその全体において組み込まれている。参考文献の引用は、その参考文献が先行技術であるという承認を構成しない。

冠詞「１つの」は、冠詞の文法的な目的語の１つまたは複数（すなわち少なくとも１つ）を指すために、本明細書で用いられる。例として、「１つの要素」は１つの要素または複数の要素を意味する。

用語「含む」は、句「含むが、しかしそれに限定されない」を意味するために、およびこの句と区別なく本明細書で用いられる。

用語「または」は、文脈によってはっきりと別に示されなければ、用語「および／または」を意味するために、およびそれと区別なく本明細書で用いられる。用語「など」は、句「〜などだが、しかしそれらに限定されない」を意味するために、およびこの句と区別なく本明細書で用いられる。

例として提示され、かつ本発明の範囲を限定するようには意図されていない、本発明の実施形態の詳細な説明を用いて、本発明を説明した。説明した実施形態には様々な特徴が含まれるが、それらの全てが、本発明の全ての実施形態において必要とされるというわけではない。本発明のいくつかの実施形態は、特徴のうちのいくつかまたは特徴の可能な組み合わせだけを利用する。本発明の説明した実施形態の変形、および説明した実施形態において言及した特徴の異なる組み合わせを含む本発明の実施形態が、当業者に思い浮かぶであろう。

本発明のいくつかの実施形態による例示的なフラッシュメモリシステムのブロック図である。 本発明のいくつかの実施形態による例示的な変換テーブルの実例を提供する。 本発明のいくつかの実施形態による例示的な変換テーブルの実例を提供する。 本発明のいくつかの実施形態に従って、１つまたは複数のフラッシュ管理テーブルおよびイベントログをフラッシュメモリに維持するための様々なルーチンを説明するフローチャートを提供する。 本発明のいくつかの実施形態による例示的なイベントログの実例を提供する。 本発明のいくつかの実施形態に従って、１つまたは複数のフラッシュ管理テーブルおよびイベントログをフラッシュメモリに維持するための様々なルーチンを説明するフローチャートを提供する。 本発明のいくつかの実施形態に従って、１つまたは複数のフラッシュ管理テーブルおよびイベントログをフラッシュメモリに維持するための様々なルーチンを説明するフローチャートを提供する。 スリープ解除のための例示的なルーチンのフローチャートを提供する。 本発明のいくつかの実施形態による例示的なイベントログの実例を提供する。 本発明のいくつかの実施形態による例示的なイベントログの実例を提供する。 本発明のいくつかの実施形態による例示的なイベントログの実例を提供する。

Claims (27)

1. フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持する方法であって、
   ａ）自身の内容が前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持することと、
   ｂ）イベントログを前記フラッシュメモリに維持することを含み、少なくとも１つの時点に関し
   ｉ）最近格納された前記少なくとも１つのフラッシュ管理テーブルが、前記フラッシュメモリシステムの以前の状態を示し、
   ｉｉ）前記以前の状態より最近の少なくとも１つのイベントが、前記イベントログに格納される、方法。
2. 前記少なくとも１つの時点に関し、最近のイベントが前記イベントログに格納される、請求項１に記載の方法。
3. 前記少なくとも１つの時点に関し、前記フラッシュメモリシステムの現在の状態が、前記格納されたイベントログおよび前記格納された少なくとも１つのフラッシュ管理テーブルの内容によって反映される、請求項１に記載の方法。
4. ｃ）前記以前の状態を示す前記少なくとも１つのテーブルから、および前記イベントログから、前記フラッシュメモリシステムのより現在に近い状態を示す少なくとも１つのテーブルを生成すること、
   をさらに含む、請求項２に記載の方法。
5. 前記より現在に近い状態が、前記生成時において前記フラッシュメモリシステムの最も現在に近い状態である、請求項４に記載の方法。
6. 前記生成が、スリープ解除のときに達成される、請求項４に記載の方法。
7. 前記少なくとも１つの管理テーブルの前記維持が、前記少なくとも１つの時点とは異なる別の時点で、前記少なくとも１つのフラッシュ管理テーブルを前記イベントログの最新の記録されたイベントに同期させることを含む、請求項１に記載の方法。
8. 前記フラッシュメモリにおける前記少なくとも１つのフラッシュ管理テーブルの前記維持が、前記フラッシュメモリにおいて、前記少なくとも１つのフラッシュ管理テーブルを現在の状態に定期的に同期させることを含む、請求項１に記載の方法。
9. 前記フラッシュメモリにおける前記少なくとも１つのフラッシュ管理テーブルの前記維持が、前記フラッシュメモリシステムのＮ（Ｎ≧２）番目の状態変化ごとに、前記フラッシュメモリにおいて、前記少なくとも１つのフラッシュ管理テーブルを現在の状態に同期させることを含む、請求項１に記載の方法。
10. 前記フラッシュメモリにおける前記少なくとも１つのフラッシュ管理テーブルの前記維持が、
    ｉ）第１の所定のタイプの状態変化が発生すると、前記フラッシュメモリにおいて、前記少なくとも１つのフラッシュ管理テーブルを現在の状態に同期させることと、
    ｉｉ）第２の所定のタイプの状態変化が発生すると、前記フラッシュメモリにおいて、前記少なくとも１つのフラッシュ管理テーブルを前記現在の状態に同期させないことと、
    を含む、請求項１に記載の方法。
11. 前記少なくとも１つのフラッシュ管理テーブルが前記フラッシュメモリにおいて更新される頻度が、前記フラッシュメモリシステムの資源の利用可能性に従って決定される、請求項１に記載の方法。
12. 前記少なくとも１つのフラッシュ管理テーブルが、仮想ブロック番号を物理ブロック番号にマッピングする変換テーブルを含む、請求項１に記載の方法。
13. 前記少なくとも１つのフラッシュ管理テーブルが、フリーブロックテーブルを含む、請求項１に記載の方法。
14. 前記維持が、複数の前記フラッシュ管理テーブルを前記フラッシュメモリに維持することを含む、請求項１に記載の方法。
15. 前記フラッシュメモリにおけるイベントログの前記維持が、前記フラッシュメモリのより迅速な書き込みモードを用いて、前記フラッシュメモリにデータを書き込むことを含む、請求項１に記載の方法。
16. 前記フラッシュメモリが、ＭＬＣおよびＳＬＣモードの両方を提供し、前記フラッシュメモリにおけるイベントログの前記維持が、前記ＳＬＣモードを用いて実行される、請求項１に記載の方法。
17. 前記ログの前記維持が、前記フラッシュメモリシステムのキャッシュ動作の一部として実行される、請求項１に記載の方法。
18. フラッシュメモリシステムにおけるスリープ解除の方法であって、
    Ｉ）スリープ解除のときに、
    （ａ）前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出すことと、
    （ｂ）前記フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログを前記フラッシュメモリから読み出すことと、
    （ｃ）前記イベントログに格納された少なくとも１つのイベントに関し、前記少なくとも１つのイベントによってもたらされた変化に従って前記少なくとも１つのフラッシュ管理テーブルを更新することと、
    を含む方法。
19. 前記更新が、前記少なくとも１つのフラッシュ管理テーブルが前記イベントログの最近のイベントに従って更新されるまで繰り返される、請求項１８に記載の方法。
20. 前記少なくとも１つのフラッシュ管理テーブルが、仮想ブロック番号を物理ブロック番号にマッピングする変換テーブルを含む、請求項１８に記載の方法。
21. 前記少なくとも１つのフラッシュ管理テーブルが、フリーブロックテーブルを含む、請求項１８に記載の方法。
22. 複数の前記フラッシュ管理テーブルが、前記フラッシュメモリから読み出されて更新される、請求項１８に記載の方法。
23. ａ）データを格納するためのフラッシュメモリと、
    ｂ）前記フラッシュメモリにアクセスするために用いられるデータ構造を維持するためのフラッシュ管理ソフトウェアと、
    を含むフラッシュメモリシステムであって、
    前記フラッシュ管理ソフトウェアが、
    ｉ）自身の内容が前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、前記フラッシュメモリに維持するように、
    ｂ）少なくとも１つの時点に関し、
    Ｉ）最近格納された前記少なくとも１つのフラッシュ管理テーブルが、前記フラッシュメモリシステムの以前の状態を示し、
    ＩＩ）前記以前の状態より最近の少なくとも１つのイベントが、イベントログに格納されるように前記イベントログを前記フラッシュメモリに維持するように動作するフラッシュメモリシステム。
24. ａ）データを格納するためのフラッシュメモリと、
    ｂ）前記フラッシュメモリにアクセスするために用いられる少なくとも１つのデータ構造を維持するためのフラッシュ管理ソフトウェアと、
    を含むフラッシュメモリシステムであって、
    スリープ解除のときに、前記フラッシュ管理ソフトウェアが、
    （ｉ）前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出すように、
    （ｉｉ）前記フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログを前記フラッシュメモリから読み出すように、
    （ｉｉｉ）前記イベントログに格納された少なくとも１つのイベントに関し、前記少なくとも１つのイベントによってもたらされた変化に従って前記少なくとも１つのフラッシュ管理テーブルを更新するように動作するフラッシュメモリシステム。
25. コンピュータ可読コードを自身に具現し、前記コンピュータ可読コードが、フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持するための命令を含むコンピュータ可読記憶媒体であって、前記命令が、
    （ａ）自身の内容が前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持する命令、
    （ｂ）イベントログを前記フラッシュメモリに維持する命令であって、少なくとも１つの時点に関し、
    （ｉ）最近格納された前記少なくとも１つのフラッシュ管理テーブルが、前記フラッシュメモリシステムの以前の状態を示し、
    （ｉｉ）前記以前の状態より最近の少なくとも１つのイベントが、前記イベントログに格納される命令を含むコンピュータ可読記憶媒体。
26. コンピュータ可読コードを自身に具現し、前記コンピュータ可読コードが、フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持するための命令を含むコンピュータ可読記憶媒体であって、前記命令が、
    Ｉ）スリープ解除のときに、
    （ａ）前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルをフラッシュメモリから読み出す命令、
    （ｂ）前記フラッシュメモリシステムの予め格納されたイベントの記録を含むイベントログを前記フラッシュメモリから読み出す命令、
    （ｃ）前記イベントログに格納された少なくとも１つのイベントに関し、前記少なくとも１つのイベントによってもたらされた変化に従って前記少なくとも１つのフラッシュ管理テーブルを更新する命令を含むコンピュータ可読記憶媒体。
27. フラッシュメモリシステムのイベントに従ってフラッシュデータ構造を維持する方法であって、
    ａ）自身の内容が前記フラッシュメモリシステムの状態を示す少なくとも１つのフラッシュ管理テーブルを、フラッシュメモリに維持することと、
    ｂ）イベントログを前記フラッシュメモリに維持することと、
    ｃ）前記少なくとも１つのフラッシュ管理テーブルの前記維持と同時に、前記イベントログの特定のイベントを一意に識別するデータを前記フラッシュメモリに維持することであって、前記特定のイベントが、前記少なくとも１つのテーブルの前記内容に対応する最近のイベントであることと、
    を含む方法。

Images