JP2004164493A - 不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム - Google Patents
不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム Download PDFInfo
- Publication number
- JP2004164493A JP2004164493A JP2002332056A JP2002332056A JP2004164493A JP 2004164493 A JP2004164493 A JP 2004164493A JP 2002332056 A JP2002332056 A JP 2002332056A JP 2002332056 A JP2002332056 A JP 2002332056A JP 2004164493 A JP2004164493 A JP 2004164493A
- Authority
- JP
- Japan
- Prior art keywords
- data
- management information
- data management
- storage area
- created
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
- Memory System (AREA)
Abstract
【課題】不揮発性メモリのデータ管理システムにおいて、前記不揮発性メモリ上の実効容量を増大させ、前記不揮発性メモリ（即ち、各消去ブロック）に対する無用なデータ消去処理を抑制することで前記不揮発性メモリの長寿命化を実現する。
【解決手段】不揮発性メモリＸの消去ブロック（物理ブロック）上に格納するデータのデータサイズと同一サイズのデータ格納領域ａを作成するデータ格納領域作成手段と、前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域ｂを作成するデータ管理情報格納領域作成手段と、前記データを、前記データ格納領域ａに格納するデータ格納手段と、前記データ格納手段による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域ｂに格納するデータ管理情報格納手段と、を具備してなる不揮発性メモリのデータ管理システムとして構成する。
【選択図】図１
【解決手段】不揮発性メモリＸの消去ブロック（物理ブロック）上に格納するデータのデータサイズと同一サイズのデータ格納領域ａを作成するデータ格納領域作成手段と、前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域ｂを作成するデータ管理情報格納領域作成手段と、前記データを、前記データ格納領域ａに格納するデータ格納手段と、前記データ格納手段による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域ｂに格納するデータ管理情報格納手段と、を具備してなる不揮発性メモリのデータ管理システムとして構成する。
【選択図】図１
Description
【０００１】
【発明の属する技術分野】
本発明は、フラッシュメモリ等の不揮発性メモリを用いた記憶装置のデータ管理システムに係り、詳しくは、前記不揮発性メモリの消去ブロック上に形成され、データの書き込み或いはデータの読み出しに利用されるセクタを、前記データのサイズに応じた可変長サイズとすることにより、前記消去ブロックにおける不使用領域の削減と、前記消去ブロックに対するデータ消去処理の頻度を軽減させることによる長寿命化と、を実現し得る不揮発性メモリを用いた記憶装置のデータ管理システムに関する。
【０００２】
【従来の技術】
フラッシュメモリ等の不揮発性メモリは、これまで記憶装置として一般的に用いられていたハードディスクドライブに較べ、１）低消費電力であること、２）低コストであること、３）構造が簡略で小型化できること、４）読み出し速度が高速であること、等の利点を有しており、特に、ＰＤＡや携帯電話等の携帯端末における記憶装置として広く利用されている。
ここで、図８を参照しつつ、フラッシュメモリを用いた記憶装置における従来公知のデータ管理システムについて説明する。
図８に示す如く、フラッシュメモリ（図８では容量が１Ｍバイトであるものを考える）Ｘ１は、所定サイズ（一般的には８ｋ〜２５６ｋ程度であり、図８では６４ｋバイトの場合を示す）の複数の物理ブロック（図８では物理ブロック０〜１４、及びスペアブロックの１６ブロック）に分割される。ここで、該物理ブロックとは、フラッシュメモリのＨ／Ｗ（ハードウェア）によって定義された固定長の領域であり、該物理ブロック単位によってのみ書き込まれたデータを消去することができる。このような特性から、該物理ブロックは、消去ブロックと称される。
該物理ブロックは、更に、固定長（図８では５１２バイトの場合を示す）の複数の仮想セクタ（例えば仮想セクタ０〜１２６、及び管理領域の１２８セクタ）に分割される。ここで、該仮想セクタとは、フラッシュメモリのＳ／Ｗ（ソフトウェア）によって仮想的に分割された領域であり、該仮想セクタ夫々にデータが格納される。
尚、前記仮想セクタの一つである前記管理領域には、ブロック管理情報と、セクタ情報とが格納される。
ここで、前記ブロック管理情報とは、前記物理ブロックに関して管理する必要のある情報を記録しておく領域であり、例えば、消去回数、使用状況等が含まれる。
一方の前記セクタ情報とは、前記各仮想セクタに対応しており、各仮想セクタに関して管理する必要がある情報を夫々記録しておく領域であり、例えば、「仮想セクタの状態」、「仮想論理セクタ番号」等が含まれる。
「仮想セクタの状態」とは、未使用、データ格納中、有効、無効に区分され、該仮想セクタに格納されたデータの状況を判定するためものである。
「仮想論理セクタ番号」とは、上位機器から見たセクタ番号を示しており、格納されるデータに対して一意に定められる。この「仮想論理セクタ番号」を不変（一意）とすることで、データ更新等で他の仮想セクタにデータが移動した場合等にも、上位機器は、この番号に基づいて夫々のデータを特定（区別）することが可能である。
このような構成により、従来公知のフラッシュメモリのデータ管理システムでは、格納するデータを前記仮想セクタに格納する際には、その格納処理に応じて前記セクタ情報（つまりは、「仮想論理セクタ番号」）を記録（更新）し、フラッシュメモリから所定のデータを読み込む際には、前記セクタ情報（「仮想論理セクタ番号」）に基づいて、その所定のデータが格納されている前記仮想セクタを特定可能であり、フラッシュメモリの利点である迅速なる書き込み、読み込みを達成するものであった。
【０００３】
【発明が解決しようとする課題】
しかしながら、前述の従来技術では、前記仮想セクタが固定サイズ長（図８においては５１２バイト）に規定されているため、例えば格納するデータのデータサイズが小さい場合（例えば１０バイト）にも、そのデータを格納するために前記仮想セクタを一つ（５１２バイト）を使用せざるを得ず、該仮想セクタ内に大きな不使用領域（５１２−１０＝４１２バイト）を発生させ、結果としてフラッシュメモリの実効容量を低下させるという不都合が生じ得る。
また、フラッシュメモリの実効容量が低いことは、不要なデータ（例えば論理的に削除されたデータ）が格納された前記仮想セクタ（前記仮想セクタの状態は無効であるもの）を再利用可能な状態にする処理、いわゆるガーベージコレクションを実施する頻度の増加を招き、ユーザの作業効率を低下させる原因になり得る。
また、上述したガーベージコレクションを頻繁に実施することは、結果として、前記物理ブロックのデータを消去する頻度の増大を招くこととなり、消去回数に制限のある（例えば、消去回数に関する保証値は１０万回程度が一般的である）前記物理ブロックの寿命を無用に消費することにも繋がる。
そこで、本発明は、前記事情に鑑みてなされたものであり、その目的とするところは、前記仮想セクタのサイズを可変サイズ長とすることでフラッシュメモリの実効容量を増大させ、ひいては、前記物理ブロックの無用なデータ消去処理を抑制することでフラッシュメモリの長寿命化を実現することにある。
【０００４】
【課題を解決するための手段】
前記目的を達成するために、本発明は、不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成手段と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成手段と、前記データを、前記データ格納領域作成手段により作成された前記データ格納領域に格納するデータ格納手段と、前記データ格納手段による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成手段により作成された前記データ管理情報格納領域に格納するデータ管理情報格納手段と、を具備してなることを特徴とする不揮発性メモリのデータ管理システムとして構成される。
このような構成によって、前記不揮発性メモリに格納されるデータは、該データのデータサイズに応じて作成された前記データ格納領域に格納されることとなり、データサイズに拘わらず画一的に形成された前記仮想セクタにデータを格納する従来構成に比べ、飛躍的に前記不揮発性メモリの実効容量を増大させることができる。
また、実効容量が増大されたことで、前記不揮発性メモリに対しガーベージコレクションを行う頻度を低減させ、前記不揮発性メモリ（前記消去ブロック）に対する無用なデータ消去処理を回避することが可能となり、ひいては、前記不揮発性メモリの長寿命化を達成することができる。
【０００５】
尚、前記データ格納領域作成手段により作成される前記データ格納領域は、前記消去ブロックにおける所定位置から順次隙間無く作成されることが望ましい。これにより、前記データ格納領域に格納されたデータを読み出す処理を行う際に、前記所定位置及び格納されているデータのデータサイズに基づいて、任意のデータのアドレスを特定することが可能となり、読み込み処理の迅速化を実現可能である。
【０００６】
更には、前記データ格納領域の作成が開始される前記所定位置は、前記消去ブロックにおける先頭或いは最後尾であることが望ましい。
このように先頭（或いは最後尾）から隙間無く前記データ格納領域を作成した場合、前記フラッシュメモリの実効容量を増大させることが可能であると共に、前記データ格納領域に格納されているデータのアドレスを特定するに当たり、常に前記消去ブロックにおける先頭或いは最後尾のアドレスが基準となるため、容易且つ迅速なアドレスの特定が可能である。
【０００７】
更には、前記データ管理情報格納領域作成手段により作成される前記データ管理情報格納領域は、前記消去ブロックにおける先頭或いは最後尾のいずれか一方のうち、前記データ格納領域が作成される反対側から順次隙間無く作成されてなることが望ましい。
このように先頭（或いは最後尾）から隙間無く前記データ管理情報格納領域を作成することで、前記フラッシュメモリの実効容量を最大限に増大させることが可能である。
【０００８】
また、前記データを格納する格納手順に特徴点を有する不揮発性メモリのデータ管理方法と捉えることで、本発明は、不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成工程と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成工程と、前記データを、前記データ格納領域作成工程により作成された前記データ格納領域に格納するデータ格納工程と、前記データ格納工程による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成工程により作成された前記データ管理情報格納領域に格納するデータ管理情報格納工程と、を具備してなることを特徴とする不揮発性メモリのデータ管理方法と考えることも可能である。
尚、その作用効果については、前述した形態と同様であるため、ここでは省略する。
【０００９】
また、前記不揮発性メモリのデータ管理システム上で実行されるプログラムと捉えることで、本発明は、不揮発性メモリのデータ管理システムにおいて実行されるプログラムであって、前記不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成機能と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成機能と、前記データを、前記データ格納領域作成機能により作成された前記データ格納領域に格納するデータ格納機能と、前記データ格納機能による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成機能により作成された前記データ管理情報格納領域に格納するデータ管理情報格納機能と、を実行させるためのデータ管理プログラムと考えることも可能である。
尚、その作用効果については、前述した形態と同様であるため、ここでは省略する。
【００１０】
【発明の実施の形態】
以下添付図面を参照しながら、本発明の実施の形態及び実施例について説明し、本発明の理解に供する。尚、以下の実施の形態及び実施例は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
ここに、図１は本発明の実施形態に係るフラッシュメモリのデータ管理システムの概略構成を模式的に示す図、図２は新規データの書き込みを行った際の処理の流れを示すフローチャート、図３は新規データの書き込みを行った際の消去ブロックを模式的に示す図、図４はデータ更新を行った際の処理の流れを示すフローチャート、図５データ更新を行った際の消去ブロックを模式的に示す図、図６はデータの読み込みを行った際の処理の流れを示すフローチャート、図７はデータの読み込みを行った際の消去ブロックを模式的に示す図、図８は従来公知のフラッシュメモリのデータ管理システムの概略構成を模式的に示す図である。
【００１１】
本発明の実施形態係る不揮発性メモリのデータ管理システムは、図１に示す如く具現化される。
同図に示す如く、本発明の実施形態に係るフラッシュメモリＸ（不揮発性メモリの一例に該当）のデータ管理システムは、該フラッシュメモリＸ（図１では容量が１Ｍバイトであるものを考える）を所定サイズ長（一般的には８ｋ〜２５６ｋ程度であり、図１では６４ｋバイトとする）の物理ブロック（物理ブロック０〜１４、及びスペアブロック）に分割する点では、従来構成と同様である。ここで、該物理ブロックとは、フラッシュメモリのＨ／Ｗ（ハードウェア）によって定義された領域であり、該物理ブロック単位によってのみ書き込まれたデータを消去することができる。このような特性から、該物理ブロックは、消去ブロックとも称されるものである。
ここで、本実施形態は、前記物理ブロックを、予め固定サイズ長の仮想セクタに分割することなく、データを格納する都度、該データのデータサイズと同一サイズのデータ格納領域ａを前記物理ブロックの先頭からデータ単位に詰めて順次作成（図１では矢印Ａで示す方向）する点で従来構成と異なる。
更に、本実施形態では、前記データ格納領域ａへのデータの格納処理に応じて、前記データ格納領域ａに格納する前記データに関するデータ管理情報を格納するデータ管理情報格納領域ｂを前記物理ブロックの最後尾（具体的には、後述するブロック管理情報格納領域ｃの次のアドレス）から詰めて順次作成（図１では矢印Ｂで示す方向）する点でも従来構成と異なる。
尚、前記データ管理情報格納領域ｂに格納される前記データ管理情報は、前記物理ブロック内に格納されているデータに関して管理する必要がある情報を記録しておく領域であり、「データの種別」、「レコードＩＤ」、「データサイズ」、「データの状態」、「チェックサム」等が記録される。
「データの種別」とは、前記データ格納領域ａに格納されたデータの種別を示し、例えば、「レコード」である、「マッピング情報」である等を区別するためのものである。
「レコードＩＤ」とは、データを識別するべく各データ毎に一意に付された番号である。
「データサイズ」とは、前記データ格納領域に格納されたデータのデータサイズである。
「データの状態」とは、データ格納中、有効、無効に区分され、前記データ格納領域ａに格納されているデータの状況を判定するためのものである。
「チェックサム」は、チェックサムの計算に用いられる情報であり、データの更新、読み込み、或いは書き込み等が正常終了したかどうかを判定するために用いるものである。
また、本実施形態では、前記物理ブロックの最後尾にはブロック管理情報を格納するブロック管理情報格納領域ｃが作成される。これは、従来構成における前記管理領域（図８参照）に変わるもので、該ブロック管理情報格納領域ｃに格納される前記ブロック管理情報は、従来公知の構成同様、消去回数、使用状況等、前記物理ブロックに関して管理する必要のある情報が記録される。
本実施形態は、このような差異（つまりは、特徴点）により、前記フラッシュメモリＸにおける前記物理ブロック上に無駄な不使用領域を生じさせることを防止し、実効容量を増大させることが可能であり、前記物理ブロック上の未使用領域が不足することでガーベージコレクションを実行せざるを得ない状況に陥ることを極力回避し、ひいては、前記フラッシュメモリＸの長寿命化に寄与し得るものである。
以下に、前記フラッシュメモリＸに対して、１）データの新規書き込みを行う場合、２）データの更新を行う場合、３）データの読み込みを行う場合に分けて、本実施形態の処理の詳細について説明する。
尚、上述説明に用いた図１、並びに以下に用いる図２〜図７では、フラッシュメモリＸにおける複数の前記物理ブロック（０〜１４）のうち、物理ブロック０のみを示しているが、その他の前記物理ブロック１〜１４についても同様の構造を有し、同様の処理を行うことが可能であることは言うまでもない。
【００１２】
１）（データの新規書き込み）
ここでは、前記フラッシュメモリＸ上の前記物理ブロック０に対し新規にデータを書き込む際の処理の流れについて図２、図３を参照しつつ説明する。
図２に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータを書き込むことを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記物理ブロック０における前記データ管理情報格納領域ｂに格納される既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における未使用領域が算出される（Ｓ１）。具体的には、前記データ管理情報に含まれる「データサイズ」に基づいて算出される。つまり、元の物理ブロックの容量（図３では、物理ブロックのデータサイズ６４ｋから前記ブロック管理情報のデータサイズ（例えば１０バイト程度）を際し引いた容量）から、「データサイズ」の総和及び前記データ管理情報のデータサイズ（例えば１０バイト程度）の総和を差し引いた容量が、前記物理ブロック０における未使用領域となる。
次に、前記ステップＳ１において算出された前記未使用領域と、今回書き込むデータ（以下、略して書き込みデータという）のデータサイズの比較が行われる（Ｓ２）。
前記ステップＳ２において、前記未使用領域の方が前記書き込みデータのデータサイズより小さいと判定された場合（図２では前記ステップＳ２のＮｏ）には、データを格納できないため、エラー処理へと処理が移行される（Ｓ３）。かかるエラー処理の一例としては、前記未使用領域の算出（検索）対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対し、前記書き込みデータを格納し得る前記未使用領域を有する物理ブロックを検索する処理が行われる。尚、かかる処理によっても前記書き込みデータを格納し得る前記未使用領域が検出されない場合には、前記物理ブロックにおける前記未使用領域を増大させるべく、前記物理ブロックに対しガーベージコレクションを施すこととなる。更に、ガーベージコレクションを施しても前記未使用領域が確保できない場合には、当該フラッシュメモリにはデータ書き込みが不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ２において、前記未使用領域の方が前記書き込みデータのデータサイズより大きいと判定された場合（図２では前記ステップＳ２のＹｅｓ）には、Ｓ４へと処理が移行される。
このステップＳ４では、既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における書き込み開始アドレスが算出される。具体的には、既存の前記データ管理情報に含まれる「データサイズ」の総和に基づいて、当該物理ブロック０における未使用領域の先頭のアドレスが算出される。例えば、図３に示す場合であれば、既存のデータ管理情報はなく、「データサイズ」総和が「０バイト」であるため、ここでは、前記物理ブロック０の先頭のアドレスが前記書き込み開始アドレスとして算出される（Ｓ４）。
続くステップＳ５では、前記書き込みデータに対応するデータ管理情報（図３ではＢ１で示す）が作成されると共に、前記物理ブロック０上の未使用領域の最後尾から順次作成されるデータ管理情報格納領域（図３ではｂ１で示す）に格納される（図３参照）。尚、この時点では、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」は、「データ格納中」とされる（Ｓ５）。
次に、ステップＳ６では、前記ステップＳ４で算出された前記書き込みアドレスから前記書き込みデータの「データサイズ」に応じた前記データ格納領域（図３ではａ１で示し、１００バイト）が作成（確保）されると共に、該データ格納領域に前記書き込みデータが格納される（Ｓ６）。
そして、前記ステップＳ６において前記データ格納領域に前記書き込みデータの格納が終了した時点で、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」が、「データ格納中」から「有効」に変更される（Ｓ７）。
このような前記データ管理情報における「データの状態」の切り替え処理は、フラッシュメモリが携帯端末等に利用させることが多く、利用形態上発生し得る、接触不良、バッテリ切れ等の不測の事態に備えたものである。つまり、データの格納処理（前記ステップＳ６の処理）が完了（正常終了）する前に何らかの（前述したバッテリ切れ等）事情によってデータの格納処理が異常終了した場合には、その時点で格納していた（つまりは、異常終了した）データに対応する「データの状態」を「データ格納中」のまま維持することで、異常終了したデータを、この「データの状態」に基づいて即時に判断可能とするものである。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸにデータを新規書き込みするに当たり、前記書き込みデータは、該フラッシュメモリＸの前記物理ブロック０における前記未使用領域の先頭から隙間なく順次格納され、そのデータに対応するデータ管理情報は、前記未使用領域の最後尾から隙間なく順次格納される。
このように、本実施形態では、書き込むデータのデータサイズに応じたデータ格納領域が作成されると共に、該データ格納領域にデータを格納する構成を実現することで、常に固定サイズ長の仮想セクタにデータを格納していた従来公知の構成に較べ、著しく前記フラッシュメモリＸの前記未使用領域に関する使用効率を向上させることができる。
尚、図３は、前記フラッシュメモリＸの物理ブロック０にレコードＩＤ０データ（レコードＩＤ：０、データサイズ：１００バイト、データの種別：レコード）が格納される様子を模式的に示すものである。
同図から、前記レコードＩＤ０データが、前記物理ブロック０の未使用領域の先頭に作成された前記データ格納領域ａ１に格納され、該レコードＩＤ０データに対応する前記データ管理情報Ｂ１が、前記データ格納領域ａ１とは逆に前記物理ブロック０の未使用領域の最後尾に作成された前記データ管理情報格納領域ｂ１に格納される様子が理解される。また、前記物理ブロック０には、無駄な不使用領域は存在していないことも同時に理解され得る。
【００１３】
（データの更新）
次に、フラッシュメモリ上の物理ブロック０に対し既に格納されているデータを更新する際の処理の流れについて図４、図５を参照しつつ説明する。
図４に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータを更新することを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記物理ブロック０における前記データ管理情報格納領域（図５ではｂ１で示す）に格納される既存の前記データ管理情報（図５の例では、前記データ管理情報格納領域ｂ１格納されているＢ１が該当）の内容に基づいて、当該物理ブロックにおける未使用領域が算出される（Ｓ１０）。
次に、前記ステップＳ１０において算出された前記未使用領域と、今回更新するデータ（以下、略して更新データという）のデータサイズの比較が行われる。（Ｓ１１）
前記ステップＳ１１において、前記未使用領域の方が前記更新データのデータサイズより小さいと判定された場合（図４では前記ステップＳ１１のＮｏ）には、データを更新できないものとしてエラー処理へと処理を移行させる（Ｓ１２）。該エラー処理の一例としては、上述したデータ書き込み処理の場合と同様に、先ず、前記未使用領域の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対する検索処理が行われる。そして、かかる処理によっても前記書き込みデータを格納し得る前記未使用領域が検出されない場合には、ガーベージコレクションが実施される。更に、ガーベージコレクションを施しても前記未使用領域が確保できない場合には、当該フラッシュメモリＸはデータ更新が不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ１１において、前記未使用領域の方が前記更新データのデータサイズより大きいと判定された場合（図４では前記ステップＳ１１のＹｅｓ）には、Ｓ１３へと処理が移行される。
このステップＳ１３では、既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における書き込み開始アドレスが算出される。具体的には、既存の前記データ管理情報に含まれる「データサイズ」の総和に基づいて、当該物理ブロック０における未使用領域の先頭のアドレスが算出される。例えば、図５に示す場合であれば、データ管理情報格納領域ｂ１に格納された前記データ格納情報がこれに該当し、「データサイズ」総和は「１００バイト」であるため、ここでは、前記物理ブロック０の先頭のアドレスから１００バイト目のアドレスが前記書き込み開始アドレスとして算出される（Ｓ１３）。
続くステップＳ１４では、前記更新データに対応するデータ管理情報（図５ではＢ２で示す）が作成されると共に、前記物理ブロック０上の未使用領域の最後尾に新たに作成されるデータ管理情報格納領域（図５ではｂ２で示す）に格納される。尚、この時点では、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」は、「データ格納中」とされる（Ｓ１４）。
次に、ステップＳ１５では、前記ステップＳ１３で算出された前記書き込みアドレスから前記更新データの「データサイズ」に応じた前記データ格納領域（図５ではａ２で示し、１２０バイト）が作成されると共に、該データ格納領域に前記更新データが格納される（Ｓ１５）。
ここまでの処理、つまりは、前記物理ブロック０の未使用領域における先頭及び最後尾から詰めて作成された前記データ格納領域（図５ではａ２）及び前記データ管理情報格納領域（図５ではｂ２）に対し、夫々前記更新データ及び前記管理情報を格納するまで処理（Ｓ１０からＳ１５に至る処理）は、前述説明したデータの新規書き込み処理の前記ステップＳ１から前記ステップＳ６に至る処理と同一である。しかし、データの更新処理では、今回更新するデータの書き込みが終了した時点で更新前のデータ（図５中にはレコードＩＤ０データ（旧）で示す）を無効にすることで、同じレコードＩＤを有するデータが重複することを回避する処理が必要な点で、前述した新規書き込み処理と異なる。
具体的には、前記ステップＳ１５による前記更新データの書き込みが終了した時点で、ステップＳ１６に処理が移行され、前記データ管理情報に基づいて無効とすべき更新前のデータが検索される。つまり、前記物理ブロック０内に記録されている前記データ管理情報のうち、「レコードＩＤ」が今回更新する前記更新データの「レコードＩＤ」であり、且つ「データの情報」が「有効」である前記データ管理情報を検索する（Ｓ１６）。
ここで、前記ステップＳ１６による検索の結果、該当する前記データ管理情報が無い場合（図５ではステップＳ１７のＮｏで示す）には、処理がエラー処理へと移行する（Ｓ１９）。ここで、該エラー処理の一例としては、先ず、前記データ管理情報の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対する検索処理が行われる。そして、かかる処理によっても前記データ管理情報が検出されない場合には、当該フラッシュメモリＸはデータ更新が不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ１６による検索の結果、該当する前記データ管理情報が有る場合（図４ではステップＳ１７のＹｅｓで示す）には、ステップＳ１８に処理が移行される。
このステップＳ１８では、前記ステップＳ１６で検索（特定）された前記データ管理情報における「データの情報」が「有効」から「無効」に変更される（Ｓ１８）。
そして、処理をステップＳ２０に移行させ、今回更新したデータの前記データ管理情報における「データの情報」が「データ格納中」から「有効」に変更されることで処理が終了する（Ｓ２０）。
尚、このような前記データ管理情報における「データの状態」の切り替え処理は、前述説明したフラッシュメモリの使用形態に鑑みてなされるもので、データの格納（更新）処理（前記ステップＳ１５の処理）が完了（正常終了）する前に異常終了したデータの抽出を可能とするものである。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸに格納されているデータを更新するに当たり、その更新データは、前記フラッシュメモリＸの前記物理ブロック０における前記未使用領域の先頭から隙間なく順次格納され、その更新データに対応するデータ管理情報は、前記未使用領域の最後尾から隙間なく順次格納される。
このように、本実施形態では、データの更新処理においても、更新するデータのデータサイズに応じた前記データ格納領域が作成されると共に、該データ格納領域にデータを格納する構成であるため、データの大小に拘わらず、常に固定サイズ長の仮想セクタにデータを格納していた従来公知の構成に較べ、著しく前記フラッシュメモリＸの未使用領域に関する使用効率を向上させることができる。
尚、図５は、フラッシュメモリの物理ブロック０に格納されていたレコードＩＤ０データ（旧）（レコードＩＤ：０、データサイズ：１００バイト、データの種別：レコード）が、レコードＩＤ０データ（新）（レコードＩＤ：０、データサイズ：１２０バイト、データの種別：レコード）に更新される様子を模式的に示すものである。
同図から、前記レコードＩＤ０データ（新）が、前記物理ブロック０の未使用領域の先頭に作成された前記データ格納領域ａ２に格納され、該レコードＩＤ０データ（新）に対応する前記データ管理情報Ｂ２が、前記データ格納領域ａ２とは逆に前記物理ブロック０の未使用領域の最後尾に作成された前記データ管理情報格納領域ｂ２に格納される様子が理解される。更に、同図から、前記レコードＩＤ０データ（新）の格納処理に伴って、前記レコードＩＤ０データ（旧）に対応する前記データ管理情報Ｂ１における「データの状態」は「無効」に、前記レコードＩＤ０データ（新）に対応する前記データ管理情報Ｂ２における「データの状態」は「有効」に変更される処理が行わわれ、今後「レコードＩＤ：０」により特定されるデータを前記レコードＩＤ０データ（新）とすることが可能であることも理解される。尚、「レコードＩＤ」を指定してデータを読み込む処理については後述する。
また、前記物理ブロック０には、無駄な不使用領域は存在していないことも同時に理解され得る。
【００１４】
（データの読み込み）
次に、フラッシュメモリ上の物理ブロックに対し既に格納されているデータのデータ管理情報を指定することで読み込む際の処理の流れについて図６、図７を参照しつつ説明する。
図６に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータ管理情報が指定され、該データ管理情報に対応するデータを読み込むことを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記データ管理情報格納領域（図７ではｂ１及びｂ２で示す）に格納されている前記データ管理情報を、該物理ブロック０の最後尾から（つまり、図７ではＢ１、Ｂ２の順に）読み出し、読み出された前記データ管理情報に対し、ステップＳ３１により以下の判定処理が行われる（Ｓ３０）。
このステップＳ３１では、最後尾の前記データ管理情報格納領域（図７ではｂ１で示す）から読み出された前記データ管理情報（図７ではＢ１で示す）が、今回読み込むデータ（以下、読み込みデータという）に対応する前記データ管理情報か否かの判定が行われる。具体的には、前記データ管理情報における「レコードＩＤ」が前記読み込みデータの「レコードＩＤ」（図７にはレコードＩＤが０の場合を示す）と一致するか否か、更には、該データ管理情報における前記「データの情報」が「有効」であるか否かによって判定される（Ｓ３１）。
かかる判定がＮｏであった場合、つまりは、そのデータ管理情報が、前記読み込みデータに対応するデータ管理情報と一致しない場合には、処理がステップＳ３４に移行される。
このステップＳ３４では、前記ステップＳ３１の判定処理に使用された前記データ管理情報が最後のデータ管理情報であるか否かを判定する（Ｓ３４）。
かかる判定がＹｅｓであった場合、つまりは、当該物理ブロック０には、前記読み込みデータに該当するデータが格納されていない場合には、データ読み込みが不可である旨を外部に報知すると共に処理を終了させる等のエラー処理が実行される（Ｓ３６）。尚、該エラー処理の一例としては、前述したデータ書き込み、及びデータ更新処理の場合と同様に、前記データ管理情報の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対して処理が行われる。そして、かかる全ブロックに亘る検索処理によっても前記読み込みデータに対応する前記データ管理情報が検出されない場合に、当該フラッシュメモリからのデータ読み込みは不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ３４における判定がＮｏであった場合には、前記ステップ３１の判定処理に使用された前記データ管理情報における「データサイズ」を加算すると共に、処理を前記ステップＳ３１に戻す（Ｓ３５）。無論、このステップＳ３５が始めて実行される場合（つまりは、そのデータ管理情報が、最後尾の前記データ管理情報格納領域（図７ではｂ１）から読み出されたものである場合）には、「データサイズ」の加算値は「０」であるため、単に、前記データ管理情報における「データサイズ」（図７では１００バイト）が記憶される。
ここで、再び処理が戻された前記ステップＳ３１では、最後尾の前記データ管理情報格納領域（図７ではｂ１で示す）の次の前記データ管理情報格納領域（図７ではｂ２で示す）に格納されている前記データ管理情報（図７ではＢ２で示す）に対し、上述した判定処理を行う。
つまり、前記ステップＳ３０で読み出された前記データ管理情報は、最後尾のものから順に前記ステップＳ３１、Ｓ３４、Ｓ３５の処理が行われることとなる。かかる処理は、前記ステップＳ３１の判定結果がＹｅｓになる（即ち、前記データ管理情報が前記読み込みデータのデータ管理情報に合致した場合であって、その処理は後述する）、或いは前記ステップＳ３４の判定がＹｅｓになる（即ち、当該フラッシュメモリＸには、前記読み込みデータに合致する前記データ管理情報は存在しない場合）まで繰り返される。
ここで、前記ステップＳ３１における判定結果がＹｅｓとなった場合、つまりは、その時点で該ステップＳ３１の判定処理を施されていた前記データ管理情報が、前記読み込みデータのデータ管理情報と合致した場合には、処理がＳ３２に移行される。
このステップＳ３２では、前記ステップＳ３５において加算／記憶された「データサイズ」の加算値に基づいて前記読み込みデータの読み込み開始アドレスを算出する。例えば、図７に示す場合であれば、データ管理情報格納領域ｂ１に格納されていたデータ管理情報Ｂ１における前記「データサイズ：１００バイト」が加算されているため、ここでは、前記物理ブロック０の先頭から１００バイト目のアドレスが前記読み込み開始アドレスとして算出される（Ｓ３２）。
そして、前記ステップＳ３２に続くステップＳ３３では、前記ステップＳ３２で算出された前記読み込み開始アドレス（図７では１００バイト目）から、前記データ管理情報のおける前記「データサイズ」に応じたサイズ分（図７では１２０バイト分）だけデータが読み込まれる（Ｓ３３）。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸに格納されている複数のデータから特定のデータを読み込むに当たり、該データの前記データ管理情報に基づいて特定のデータの格納位置、及びデータサイズを容易且つ正確に検索可能である。
このように、本実施形態では、前記物理ブロックに記録されるデータが、該データのデータサイズと同一サイズであって、前記物理ブロックの所定位置（本実施形態では先頭）から隙間なく順次作成されるデータ格納領域に格納される構成を巧妙に利用することで、前記データ管理情報に基づいて特定のデータを正確且つ迅速に読み込むことが可能である。
尚、図７は、「レコードＩＤ：０」を指定してフラッシュメモリの物理ブロック０に格納されているレコードＩＤ０データ（新）（レコードＩＤ：０、データサイズ：１２０バイト、データの種別：レコード）を読み込む様子を模式的に示すものである。
同図から、前記データ管理情報格納領域ｂ１及びｂ２に格納されている前記データ格納情報における「データサイズ」、「データの状態」に基づいて、今回読み込むべき前記レコードＩＤ０データ（新）が、前記物理ブロック０の先頭から１００バイト目のアドレスから１２０バイト分の領域に格納されていることが特定され、しかる後、読み込まれる様子が理解される。
【００１５】
【実施例】
上述した実施形態では、前記物理ブロックの未使用領域の先頭から前記データ格納領域ａが作成され、最後尾から前記データ管理情報格納領域ｂが作成される形態について説明している。
しかしながら、上述の実施形態とは逆に、前記データ格納領域ａが前記物理ブロックの未使用領域の最後尾から作成され、前記データ管理情報格納領域ｂが先頭から作成される形態も考え得る。この場合にも、上述した実施形態と同様に、前記物理ブロック０に無用な不使用領域を生成することなく、フラッシュメモリの実効容量を増大させることが可能であることは理解に易しい。
【００１６】
また、上述した実施形態及び実施例では、前記物理ブロックの未使用領域の先頭或いは最後尾から前記データ格納領域ａ及び前記データ管理情報格納領域ｂが作成される形態について説明している。
しかしながら、前記データ格納領域ａ及び前記データ管理情報格納領域ｂの作成が開始される位置は、前記物理ブロックの未使用領域の先頭或いは最後尾に限定されるものではなく、その作成を開始した所定位置のアドレスが特定可能であればどこから開始されてもかまわない。
つまり、その所定位置（つまりは、アドレス）が特定できれば、前述説明したデータの読み込み処理に際し、そのアドレス分を加味した上で前記読み込み開始アドレスを算出することが可能である。
従って、例えば、前記消去ブロックに予め何らかの消去不可能なデータが格納されている（無論、未使用領域として確保されたたものでもよい）ようなフラッシュメモリであっても、そのデータサイズ（アドレス）を特定（取得）することで本発明を適用することが可能である。
【００１７】
【発明の効果】
以上説明したように、本発明によれば、フラッシュメモリに格納されるデータを、該データのデータサイズに応じて作成された前記データ格納領域に格納することが可能となる。
従って、データサイズに拘わらず画一的に形成された前記仮想セクタに格納していた従来構成に比べ、飛躍的にフラッシュメモリの実効容量を増大させることができる。
また、実効容量が増大したことに伴い、フラッシュメモリに対しガーベージコレクションを行う頻度が低減され、該フラッシュメモリ（前記消去ブロック）に対する無用なデータ消去処理を回避することが可能となり、ひいては、フラッシュメモリの長寿命化を達成することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るフラッシュメモリのデータ管理システムの概略構成を模式的に示す図。
【図２】新規データの書き込みを行った際の処理の流れを示すフローチャート。
【図３】新規データの書き込みを行った際の消去ブロックを模式的に示す図。
【図４】データ更新を行った際の処理の流れを示すフローチャート。
【図５】データ更新を行った際の消去ブロックを模式的に示す図。
【図６】データの読み込みを行った際の処理の流れを示すフローチャート。
【図７】データの読み込みを行った際の消去ブロックを模式的に示す図。
【図８】従来公知のフラッシュメモリのデータ管理システムの概略構成を模式的に示す図。
【符号の説明】
Ｘ …フラッシュメモリ
ａ …データ格納領域
ｂ …データ管理情報格納領域
ｃ …ブロック管理情報格納領域
Ｓ１、Ｓ１、、…処理手順（ステップ）の番号
【発明の属する技術分野】
本発明は、フラッシュメモリ等の不揮発性メモリを用いた記憶装置のデータ管理システムに係り、詳しくは、前記不揮発性メモリの消去ブロック上に形成され、データの書き込み或いはデータの読み出しに利用されるセクタを、前記データのサイズに応じた可変長サイズとすることにより、前記消去ブロックにおける不使用領域の削減と、前記消去ブロックに対するデータ消去処理の頻度を軽減させることによる長寿命化と、を実現し得る不揮発性メモリを用いた記憶装置のデータ管理システムに関する。
【０００２】
【従来の技術】
フラッシュメモリ等の不揮発性メモリは、これまで記憶装置として一般的に用いられていたハードディスクドライブに較べ、１）低消費電力であること、２）低コストであること、３）構造が簡略で小型化できること、４）読み出し速度が高速であること、等の利点を有しており、特に、ＰＤＡや携帯電話等の携帯端末における記憶装置として広く利用されている。
ここで、図８を参照しつつ、フラッシュメモリを用いた記憶装置における従来公知のデータ管理システムについて説明する。
図８に示す如く、フラッシュメモリ（図８では容量が１Ｍバイトであるものを考える）Ｘ１は、所定サイズ（一般的には８ｋ〜２５６ｋ程度であり、図８では６４ｋバイトの場合を示す）の複数の物理ブロック（図８では物理ブロック０〜１４、及びスペアブロックの１６ブロック）に分割される。ここで、該物理ブロックとは、フラッシュメモリのＨ／Ｗ（ハードウェア）によって定義された固定長の領域であり、該物理ブロック単位によってのみ書き込まれたデータを消去することができる。このような特性から、該物理ブロックは、消去ブロックと称される。
該物理ブロックは、更に、固定長（図８では５１２バイトの場合を示す）の複数の仮想セクタ（例えば仮想セクタ０〜１２６、及び管理領域の１２８セクタ）に分割される。ここで、該仮想セクタとは、フラッシュメモリのＳ／Ｗ（ソフトウェア）によって仮想的に分割された領域であり、該仮想セクタ夫々にデータが格納される。
尚、前記仮想セクタの一つである前記管理領域には、ブロック管理情報と、セクタ情報とが格納される。
ここで、前記ブロック管理情報とは、前記物理ブロックに関して管理する必要のある情報を記録しておく領域であり、例えば、消去回数、使用状況等が含まれる。
一方の前記セクタ情報とは、前記各仮想セクタに対応しており、各仮想セクタに関して管理する必要がある情報を夫々記録しておく領域であり、例えば、「仮想セクタの状態」、「仮想論理セクタ番号」等が含まれる。
「仮想セクタの状態」とは、未使用、データ格納中、有効、無効に区分され、該仮想セクタに格納されたデータの状況を判定するためものである。
「仮想論理セクタ番号」とは、上位機器から見たセクタ番号を示しており、格納されるデータに対して一意に定められる。この「仮想論理セクタ番号」を不変（一意）とすることで、データ更新等で他の仮想セクタにデータが移動した場合等にも、上位機器は、この番号に基づいて夫々のデータを特定（区別）することが可能である。
このような構成により、従来公知のフラッシュメモリのデータ管理システムでは、格納するデータを前記仮想セクタに格納する際には、その格納処理に応じて前記セクタ情報（つまりは、「仮想論理セクタ番号」）を記録（更新）し、フラッシュメモリから所定のデータを読み込む際には、前記セクタ情報（「仮想論理セクタ番号」）に基づいて、その所定のデータが格納されている前記仮想セクタを特定可能であり、フラッシュメモリの利点である迅速なる書き込み、読み込みを達成するものであった。
【０００３】
【発明が解決しようとする課題】
しかしながら、前述の従来技術では、前記仮想セクタが固定サイズ長（図８においては５１２バイト）に規定されているため、例えば格納するデータのデータサイズが小さい場合（例えば１０バイト）にも、そのデータを格納するために前記仮想セクタを一つ（５１２バイト）を使用せざるを得ず、該仮想セクタ内に大きな不使用領域（５１２−１０＝４１２バイト）を発生させ、結果としてフラッシュメモリの実効容量を低下させるという不都合が生じ得る。
また、フラッシュメモリの実効容量が低いことは、不要なデータ（例えば論理的に削除されたデータ）が格納された前記仮想セクタ（前記仮想セクタの状態は無効であるもの）を再利用可能な状態にする処理、いわゆるガーベージコレクションを実施する頻度の増加を招き、ユーザの作業効率を低下させる原因になり得る。
また、上述したガーベージコレクションを頻繁に実施することは、結果として、前記物理ブロックのデータを消去する頻度の増大を招くこととなり、消去回数に制限のある（例えば、消去回数に関する保証値は１０万回程度が一般的である）前記物理ブロックの寿命を無用に消費することにも繋がる。
そこで、本発明は、前記事情に鑑みてなされたものであり、その目的とするところは、前記仮想セクタのサイズを可変サイズ長とすることでフラッシュメモリの実効容量を増大させ、ひいては、前記物理ブロックの無用なデータ消去処理を抑制することでフラッシュメモリの長寿命化を実現することにある。
【０００４】
【課題を解決するための手段】
前記目的を達成するために、本発明は、不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成手段と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成手段と、前記データを、前記データ格納領域作成手段により作成された前記データ格納領域に格納するデータ格納手段と、前記データ格納手段による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成手段により作成された前記データ管理情報格納領域に格納するデータ管理情報格納手段と、を具備してなることを特徴とする不揮発性メモリのデータ管理システムとして構成される。
このような構成によって、前記不揮発性メモリに格納されるデータは、該データのデータサイズに応じて作成された前記データ格納領域に格納されることとなり、データサイズに拘わらず画一的に形成された前記仮想セクタにデータを格納する従来構成に比べ、飛躍的に前記不揮発性メモリの実効容量を増大させることができる。
また、実効容量が増大されたことで、前記不揮発性メモリに対しガーベージコレクションを行う頻度を低減させ、前記不揮発性メモリ（前記消去ブロック）に対する無用なデータ消去処理を回避することが可能となり、ひいては、前記不揮発性メモリの長寿命化を達成することができる。
【０００５】
尚、前記データ格納領域作成手段により作成される前記データ格納領域は、前記消去ブロックにおける所定位置から順次隙間無く作成されることが望ましい。これにより、前記データ格納領域に格納されたデータを読み出す処理を行う際に、前記所定位置及び格納されているデータのデータサイズに基づいて、任意のデータのアドレスを特定することが可能となり、読み込み処理の迅速化を実現可能である。
【０００６】
更には、前記データ格納領域の作成が開始される前記所定位置は、前記消去ブロックにおける先頭或いは最後尾であることが望ましい。
このように先頭（或いは最後尾）から隙間無く前記データ格納領域を作成した場合、前記フラッシュメモリの実効容量を増大させることが可能であると共に、前記データ格納領域に格納されているデータのアドレスを特定するに当たり、常に前記消去ブロックにおける先頭或いは最後尾のアドレスが基準となるため、容易且つ迅速なアドレスの特定が可能である。
【０００７】
更には、前記データ管理情報格納領域作成手段により作成される前記データ管理情報格納領域は、前記消去ブロックにおける先頭或いは最後尾のいずれか一方のうち、前記データ格納領域が作成される反対側から順次隙間無く作成されてなることが望ましい。
このように先頭（或いは最後尾）から隙間無く前記データ管理情報格納領域を作成することで、前記フラッシュメモリの実効容量を最大限に増大させることが可能である。
【０００８】
また、前記データを格納する格納手順に特徴点を有する不揮発性メモリのデータ管理方法と捉えることで、本発明は、不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成工程と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成工程と、前記データを、前記データ格納領域作成工程により作成された前記データ格納領域に格納するデータ格納工程と、前記データ格納工程による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成工程により作成された前記データ管理情報格納領域に格納するデータ管理情報格納工程と、を具備してなることを特徴とする不揮発性メモリのデータ管理方法と考えることも可能である。
尚、その作用効果については、前述した形態と同様であるため、ここでは省略する。
【０００９】
また、前記不揮発性メモリのデータ管理システム上で実行されるプログラムと捉えることで、本発明は、不揮発性メモリのデータ管理システムにおいて実行されるプログラムであって、前記不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成機能と、前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成機能と、前記データを、前記データ格納領域作成機能により作成された前記データ格納領域に格納するデータ格納機能と、前記データ格納機能による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成機能により作成された前記データ管理情報格納領域に格納するデータ管理情報格納機能と、を実行させるためのデータ管理プログラムと考えることも可能である。
尚、その作用効果については、前述した形態と同様であるため、ここでは省略する。
【００１０】
【発明の実施の形態】
以下添付図面を参照しながら、本発明の実施の形態及び実施例について説明し、本発明の理解に供する。尚、以下の実施の形態及び実施例は、本発明を具体化した一例であって、本発明の技術的範囲を限定する性格のものではない。
ここに、図１は本発明の実施形態に係るフラッシュメモリのデータ管理システムの概略構成を模式的に示す図、図２は新規データの書き込みを行った際の処理の流れを示すフローチャート、図３は新規データの書き込みを行った際の消去ブロックを模式的に示す図、図４はデータ更新を行った際の処理の流れを示すフローチャート、図５データ更新を行った際の消去ブロックを模式的に示す図、図６はデータの読み込みを行った際の処理の流れを示すフローチャート、図７はデータの読み込みを行った際の消去ブロックを模式的に示す図、図８は従来公知のフラッシュメモリのデータ管理システムの概略構成を模式的に示す図である。
【００１１】
本発明の実施形態係る不揮発性メモリのデータ管理システムは、図１に示す如く具現化される。
同図に示す如く、本発明の実施形態に係るフラッシュメモリＸ（不揮発性メモリの一例に該当）のデータ管理システムは、該フラッシュメモリＸ（図１では容量が１Ｍバイトであるものを考える）を所定サイズ長（一般的には８ｋ〜２５６ｋ程度であり、図１では６４ｋバイトとする）の物理ブロック（物理ブロック０〜１４、及びスペアブロック）に分割する点では、従来構成と同様である。ここで、該物理ブロックとは、フラッシュメモリのＨ／Ｗ（ハードウェア）によって定義された領域であり、該物理ブロック単位によってのみ書き込まれたデータを消去することができる。このような特性から、該物理ブロックは、消去ブロックとも称されるものである。
ここで、本実施形態は、前記物理ブロックを、予め固定サイズ長の仮想セクタに分割することなく、データを格納する都度、該データのデータサイズと同一サイズのデータ格納領域ａを前記物理ブロックの先頭からデータ単位に詰めて順次作成（図１では矢印Ａで示す方向）する点で従来構成と異なる。
更に、本実施形態では、前記データ格納領域ａへのデータの格納処理に応じて、前記データ格納領域ａに格納する前記データに関するデータ管理情報を格納するデータ管理情報格納領域ｂを前記物理ブロックの最後尾（具体的には、後述するブロック管理情報格納領域ｃの次のアドレス）から詰めて順次作成（図１では矢印Ｂで示す方向）する点でも従来構成と異なる。
尚、前記データ管理情報格納領域ｂに格納される前記データ管理情報は、前記物理ブロック内に格納されているデータに関して管理する必要がある情報を記録しておく領域であり、「データの種別」、「レコードＩＤ」、「データサイズ」、「データの状態」、「チェックサム」等が記録される。
「データの種別」とは、前記データ格納領域ａに格納されたデータの種別を示し、例えば、「レコード」である、「マッピング情報」である等を区別するためのものである。
「レコードＩＤ」とは、データを識別するべく各データ毎に一意に付された番号である。
「データサイズ」とは、前記データ格納領域に格納されたデータのデータサイズである。
「データの状態」とは、データ格納中、有効、無効に区分され、前記データ格納領域ａに格納されているデータの状況を判定するためのものである。
「チェックサム」は、チェックサムの計算に用いられる情報であり、データの更新、読み込み、或いは書き込み等が正常終了したかどうかを判定するために用いるものである。
また、本実施形態では、前記物理ブロックの最後尾にはブロック管理情報を格納するブロック管理情報格納領域ｃが作成される。これは、従来構成における前記管理領域（図８参照）に変わるもので、該ブロック管理情報格納領域ｃに格納される前記ブロック管理情報は、従来公知の構成同様、消去回数、使用状況等、前記物理ブロックに関して管理する必要のある情報が記録される。
本実施形態は、このような差異（つまりは、特徴点）により、前記フラッシュメモリＸにおける前記物理ブロック上に無駄な不使用領域を生じさせることを防止し、実効容量を増大させることが可能であり、前記物理ブロック上の未使用領域が不足することでガーベージコレクションを実行せざるを得ない状況に陥ることを極力回避し、ひいては、前記フラッシュメモリＸの長寿命化に寄与し得るものである。
以下に、前記フラッシュメモリＸに対して、１）データの新規書き込みを行う場合、２）データの更新を行う場合、３）データの読み込みを行う場合に分けて、本実施形態の処理の詳細について説明する。
尚、上述説明に用いた図１、並びに以下に用いる図２〜図７では、フラッシュメモリＸにおける複数の前記物理ブロック（０〜１４）のうち、物理ブロック０のみを示しているが、その他の前記物理ブロック１〜１４についても同様の構造を有し、同様の処理を行うことが可能であることは言うまでもない。
【００１２】
１）（データの新規書き込み）
ここでは、前記フラッシュメモリＸ上の前記物理ブロック０に対し新規にデータを書き込む際の処理の流れについて図２、図３を参照しつつ説明する。
図２に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータを書き込むことを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記物理ブロック０における前記データ管理情報格納領域ｂに格納される既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における未使用領域が算出される（Ｓ１）。具体的には、前記データ管理情報に含まれる「データサイズ」に基づいて算出される。つまり、元の物理ブロックの容量（図３では、物理ブロックのデータサイズ６４ｋから前記ブロック管理情報のデータサイズ（例えば１０バイト程度）を際し引いた容量）から、「データサイズ」の総和及び前記データ管理情報のデータサイズ（例えば１０バイト程度）の総和を差し引いた容量が、前記物理ブロック０における未使用領域となる。
次に、前記ステップＳ１において算出された前記未使用領域と、今回書き込むデータ（以下、略して書き込みデータという）のデータサイズの比較が行われる（Ｓ２）。
前記ステップＳ２において、前記未使用領域の方が前記書き込みデータのデータサイズより小さいと判定された場合（図２では前記ステップＳ２のＮｏ）には、データを格納できないため、エラー処理へと処理が移行される（Ｓ３）。かかるエラー処理の一例としては、前記未使用領域の算出（検索）対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対し、前記書き込みデータを格納し得る前記未使用領域を有する物理ブロックを検索する処理が行われる。尚、かかる処理によっても前記書き込みデータを格納し得る前記未使用領域が検出されない場合には、前記物理ブロックにおける前記未使用領域を増大させるべく、前記物理ブロックに対しガーベージコレクションを施すこととなる。更に、ガーベージコレクションを施しても前記未使用領域が確保できない場合には、当該フラッシュメモリにはデータ書き込みが不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ２において、前記未使用領域の方が前記書き込みデータのデータサイズより大きいと判定された場合（図２では前記ステップＳ２のＹｅｓ）には、Ｓ４へと処理が移行される。
このステップＳ４では、既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における書き込み開始アドレスが算出される。具体的には、既存の前記データ管理情報に含まれる「データサイズ」の総和に基づいて、当該物理ブロック０における未使用領域の先頭のアドレスが算出される。例えば、図３に示す場合であれば、既存のデータ管理情報はなく、「データサイズ」総和が「０バイト」であるため、ここでは、前記物理ブロック０の先頭のアドレスが前記書き込み開始アドレスとして算出される（Ｓ４）。
続くステップＳ５では、前記書き込みデータに対応するデータ管理情報（図３ではＢ１で示す）が作成されると共に、前記物理ブロック０上の未使用領域の最後尾から順次作成されるデータ管理情報格納領域（図３ではｂ１で示す）に格納される（図３参照）。尚、この時点では、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」は、「データ格納中」とされる（Ｓ５）。
次に、ステップＳ６では、前記ステップＳ４で算出された前記書き込みアドレスから前記書き込みデータの「データサイズ」に応じた前記データ格納領域（図３ではａ１で示し、１００バイト）が作成（確保）されると共に、該データ格納領域に前記書き込みデータが格納される（Ｓ６）。
そして、前記ステップＳ６において前記データ格納領域に前記書き込みデータの格納が終了した時点で、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」が、「データ格納中」から「有効」に変更される（Ｓ７）。
このような前記データ管理情報における「データの状態」の切り替え処理は、フラッシュメモリが携帯端末等に利用させることが多く、利用形態上発生し得る、接触不良、バッテリ切れ等の不測の事態に備えたものである。つまり、データの格納処理（前記ステップＳ６の処理）が完了（正常終了）する前に何らかの（前述したバッテリ切れ等）事情によってデータの格納処理が異常終了した場合には、その時点で格納していた（つまりは、異常終了した）データに対応する「データの状態」を「データ格納中」のまま維持することで、異常終了したデータを、この「データの状態」に基づいて即時に判断可能とするものである。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸにデータを新規書き込みするに当たり、前記書き込みデータは、該フラッシュメモリＸの前記物理ブロック０における前記未使用領域の先頭から隙間なく順次格納され、そのデータに対応するデータ管理情報は、前記未使用領域の最後尾から隙間なく順次格納される。
このように、本実施形態では、書き込むデータのデータサイズに応じたデータ格納領域が作成されると共に、該データ格納領域にデータを格納する構成を実現することで、常に固定サイズ長の仮想セクタにデータを格納していた従来公知の構成に較べ、著しく前記フラッシュメモリＸの前記未使用領域に関する使用効率を向上させることができる。
尚、図３は、前記フラッシュメモリＸの物理ブロック０にレコードＩＤ０データ（レコードＩＤ：０、データサイズ：１００バイト、データの種別：レコード）が格納される様子を模式的に示すものである。
同図から、前記レコードＩＤ０データが、前記物理ブロック０の未使用領域の先頭に作成された前記データ格納領域ａ１に格納され、該レコードＩＤ０データに対応する前記データ管理情報Ｂ１が、前記データ格納領域ａ１とは逆に前記物理ブロック０の未使用領域の最後尾に作成された前記データ管理情報格納領域ｂ１に格納される様子が理解される。また、前記物理ブロック０には、無駄な不使用領域は存在していないことも同時に理解され得る。
【００１３】
（データの更新）
次に、フラッシュメモリ上の物理ブロック０に対し既に格納されているデータを更新する際の処理の流れについて図４、図５を参照しつつ説明する。
図４に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータを更新することを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記物理ブロック０における前記データ管理情報格納領域（図５ではｂ１で示す）に格納される既存の前記データ管理情報（図５の例では、前記データ管理情報格納領域ｂ１格納されているＢ１が該当）の内容に基づいて、当該物理ブロックにおける未使用領域が算出される（Ｓ１０）。
次に、前記ステップＳ１０において算出された前記未使用領域と、今回更新するデータ（以下、略して更新データという）のデータサイズの比較が行われる。（Ｓ１１）
前記ステップＳ１１において、前記未使用領域の方が前記更新データのデータサイズより小さいと判定された場合（図４では前記ステップＳ１１のＮｏ）には、データを更新できないものとしてエラー処理へと処理を移行させる（Ｓ１２）。該エラー処理の一例としては、上述したデータ書き込み処理の場合と同様に、先ず、前記未使用領域の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対する検索処理が行われる。そして、かかる処理によっても前記書き込みデータを格納し得る前記未使用領域が検出されない場合には、ガーベージコレクションが実施される。更に、ガーベージコレクションを施しても前記未使用領域が確保できない場合には、当該フラッシュメモリＸはデータ更新が不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ１１において、前記未使用領域の方が前記更新データのデータサイズより大きいと判定された場合（図４では前記ステップＳ１１のＹｅｓ）には、Ｓ１３へと処理が移行される。
このステップＳ１３では、既存の前記データ管理情報の内容に基づいて、当該物理ブロック０における書き込み開始アドレスが算出される。具体的には、既存の前記データ管理情報に含まれる「データサイズ」の総和に基づいて、当該物理ブロック０における未使用領域の先頭のアドレスが算出される。例えば、図５に示す場合であれば、データ管理情報格納領域ｂ１に格納された前記データ格納情報がこれに該当し、「データサイズ」総和は「１００バイト」であるため、ここでは、前記物理ブロック０の先頭のアドレスから１００バイト目のアドレスが前記書き込み開始アドレスとして算出される（Ｓ１３）。
続くステップＳ１４では、前記更新データに対応するデータ管理情報（図５ではＢ２で示す）が作成されると共に、前記物理ブロック０上の未使用領域の最後尾に新たに作成されるデータ管理情報格納領域（図５ではｂ２で示す）に格納される。尚、この時点では、前記データ管理情報格納領域に格納された前記データ管理情報における「データの状態」は、「データ格納中」とされる（Ｓ１４）。
次に、ステップＳ１５では、前記ステップＳ１３で算出された前記書き込みアドレスから前記更新データの「データサイズ」に応じた前記データ格納領域（図５ではａ２で示し、１２０バイト）が作成されると共に、該データ格納領域に前記更新データが格納される（Ｓ１５）。
ここまでの処理、つまりは、前記物理ブロック０の未使用領域における先頭及び最後尾から詰めて作成された前記データ格納領域（図５ではａ２）及び前記データ管理情報格納領域（図５ではｂ２）に対し、夫々前記更新データ及び前記管理情報を格納するまで処理（Ｓ１０からＳ１５に至る処理）は、前述説明したデータの新規書き込み処理の前記ステップＳ１から前記ステップＳ６に至る処理と同一である。しかし、データの更新処理では、今回更新するデータの書き込みが終了した時点で更新前のデータ（図５中にはレコードＩＤ０データ（旧）で示す）を無効にすることで、同じレコードＩＤを有するデータが重複することを回避する処理が必要な点で、前述した新規書き込み処理と異なる。
具体的には、前記ステップＳ１５による前記更新データの書き込みが終了した時点で、ステップＳ１６に処理が移行され、前記データ管理情報に基づいて無効とすべき更新前のデータが検索される。つまり、前記物理ブロック０内に記録されている前記データ管理情報のうち、「レコードＩＤ」が今回更新する前記更新データの「レコードＩＤ」であり、且つ「データの情報」が「有効」である前記データ管理情報を検索する（Ｓ１６）。
ここで、前記ステップＳ１６による検索の結果、該当する前記データ管理情報が無い場合（図５ではステップＳ１７のＮｏで示す）には、処理がエラー処理へと移行する（Ｓ１９）。ここで、該エラー処理の一例としては、先ず、前記データ管理情報の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対する検索処理が行われる。そして、かかる処理によっても前記データ管理情報が検出されない場合には、当該フラッシュメモリＸはデータ更新が不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ１６による検索の結果、該当する前記データ管理情報が有る場合（図４ではステップＳ１７のＹｅｓで示す）には、ステップＳ１８に処理が移行される。
このステップＳ１８では、前記ステップＳ１６で検索（特定）された前記データ管理情報における「データの情報」が「有効」から「無効」に変更される（Ｓ１８）。
そして、処理をステップＳ２０に移行させ、今回更新したデータの前記データ管理情報における「データの情報」が「データ格納中」から「有効」に変更されることで処理が終了する（Ｓ２０）。
尚、このような前記データ管理情報における「データの状態」の切り替え処理は、前述説明したフラッシュメモリの使用形態に鑑みてなされるもので、データの格納（更新）処理（前記ステップＳ１５の処理）が完了（正常終了）する前に異常終了したデータの抽出を可能とするものである。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸに格納されているデータを更新するに当たり、その更新データは、前記フラッシュメモリＸの前記物理ブロック０における前記未使用領域の先頭から隙間なく順次格納され、その更新データに対応するデータ管理情報は、前記未使用領域の最後尾から隙間なく順次格納される。
このように、本実施形態では、データの更新処理においても、更新するデータのデータサイズに応じた前記データ格納領域が作成されると共に、該データ格納領域にデータを格納する構成であるため、データの大小に拘わらず、常に固定サイズ長の仮想セクタにデータを格納していた従来公知の構成に較べ、著しく前記フラッシュメモリＸの未使用領域に関する使用効率を向上させることができる。
尚、図５は、フラッシュメモリの物理ブロック０に格納されていたレコードＩＤ０データ（旧）（レコードＩＤ：０、データサイズ：１００バイト、データの種別：レコード）が、レコードＩＤ０データ（新）（レコードＩＤ：０、データサイズ：１２０バイト、データの種別：レコード）に更新される様子を模式的に示すものである。
同図から、前記レコードＩＤ０データ（新）が、前記物理ブロック０の未使用領域の先頭に作成された前記データ格納領域ａ２に格納され、該レコードＩＤ０データ（新）に対応する前記データ管理情報Ｂ２が、前記データ格納領域ａ２とは逆に前記物理ブロック０の未使用領域の最後尾に作成された前記データ管理情報格納領域ｂ２に格納される様子が理解される。更に、同図から、前記レコードＩＤ０データ（新）の格納処理に伴って、前記レコードＩＤ０データ（旧）に対応する前記データ管理情報Ｂ１における「データの状態」は「無効」に、前記レコードＩＤ０データ（新）に対応する前記データ管理情報Ｂ２における「データの状態」は「有効」に変更される処理が行わわれ、今後「レコードＩＤ：０」により特定されるデータを前記レコードＩＤ０データ（新）とすることが可能であることも理解される。尚、「レコードＩＤ」を指定してデータを読み込む処理については後述する。
また、前記物理ブロック０には、無駄な不使用領域は存在していないことも同時に理解され得る。
【００１４】
（データの読み込み）
次に、フラッシュメモリ上の物理ブロックに対し既に格納されているデータのデータ管理情報を指定することで読み込む際の処理の流れについて図６、図７を参照しつつ説明する。
図６に示すフローチャートに示す如く、不図示のＣＰＵ等からの指令により特定のデータ管理情報が指定され、該データ管理情報に対応するデータを読み込むことを要求された当該実施形態に係るフラッシュメモリのデータ管理システムでは、先ず、前記データ管理情報格納領域（図７ではｂ１及びｂ２で示す）に格納されている前記データ管理情報を、該物理ブロック０の最後尾から（つまり、図７ではＢ１、Ｂ２の順に）読み出し、読み出された前記データ管理情報に対し、ステップＳ３１により以下の判定処理が行われる（Ｓ３０）。
このステップＳ３１では、最後尾の前記データ管理情報格納領域（図７ではｂ１で示す）から読み出された前記データ管理情報（図７ではＢ１で示す）が、今回読み込むデータ（以下、読み込みデータという）に対応する前記データ管理情報か否かの判定が行われる。具体的には、前記データ管理情報における「レコードＩＤ」が前記読み込みデータの「レコードＩＤ」（図７にはレコードＩＤが０の場合を示す）と一致するか否か、更には、該データ管理情報における前記「データの情報」が「有効」であるか否かによって判定される（Ｓ３１）。
かかる判定がＮｏであった場合、つまりは、そのデータ管理情報が、前記読み込みデータに対応するデータ管理情報と一致しない場合には、処理がステップＳ３４に移行される。
このステップＳ３４では、前記ステップＳ３１の判定処理に使用された前記データ管理情報が最後のデータ管理情報であるか否かを判定する（Ｓ３４）。
かかる判定がＹｅｓであった場合、つまりは、当該物理ブロック０には、前記読み込みデータに該当するデータが格納されていない場合には、データ読み込みが不可である旨を外部に報知すると共に処理を終了させる等のエラー処理が実行される（Ｓ３６）。尚、該エラー処理の一例としては、前述したデータ書き込み、及びデータ更新処理の場合と同様に、前記データ管理情報の検索対象とする物理ブロックを、当該物理ブロック０から物理ブロック１、２、…と順次変更し、全ての物理ブロックに対して処理が行われる。そして、かかる全ブロックに亘る検索処理によっても前記読み込みデータに対応する前記データ管理情報が検出されない場合に、当該フラッシュメモリからのデータ読み込みは不可能である旨を外部に報知すると共に処理が終了される。
一方、前記ステップＳ３４における判定がＮｏであった場合には、前記ステップ３１の判定処理に使用された前記データ管理情報における「データサイズ」を加算すると共に、処理を前記ステップＳ３１に戻す（Ｓ３５）。無論、このステップＳ３５が始めて実行される場合（つまりは、そのデータ管理情報が、最後尾の前記データ管理情報格納領域（図７ではｂ１）から読み出されたものである場合）には、「データサイズ」の加算値は「０」であるため、単に、前記データ管理情報における「データサイズ」（図７では１００バイト）が記憶される。
ここで、再び処理が戻された前記ステップＳ３１では、最後尾の前記データ管理情報格納領域（図７ではｂ１で示す）の次の前記データ管理情報格納領域（図７ではｂ２で示す）に格納されている前記データ管理情報（図７ではＢ２で示す）に対し、上述した判定処理を行う。
つまり、前記ステップＳ３０で読み出された前記データ管理情報は、最後尾のものから順に前記ステップＳ３１、Ｓ３４、Ｓ３５の処理が行われることとなる。かかる処理は、前記ステップＳ３１の判定結果がＹｅｓになる（即ち、前記データ管理情報が前記読み込みデータのデータ管理情報に合致した場合であって、その処理は後述する）、或いは前記ステップＳ３４の判定がＹｅｓになる（即ち、当該フラッシュメモリＸには、前記読み込みデータに合致する前記データ管理情報は存在しない場合）まで繰り返される。
ここで、前記ステップＳ３１における判定結果がＹｅｓとなった場合、つまりは、その時点で該ステップＳ３１の判定処理を施されていた前記データ管理情報が、前記読み込みデータのデータ管理情報と合致した場合には、処理がＳ３２に移行される。
このステップＳ３２では、前記ステップＳ３５において加算／記憶された「データサイズ」の加算値に基づいて前記読み込みデータの読み込み開始アドレスを算出する。例えば、図７に示す場合であれば、データ管理情報格納領域ｂ１に格納されていたデータ管理情報Ｂ１における前記「データサイズ：１００バイト」が加算されているため、ここでは、前記物理ブロック０の先頭から１００バイト目のアドレスが前記読み込み開始アドレスとして算出される（Ｓ３２）。
そして、前記ステップＳ３２に続くステップＳ３３では、前記ステップＳ３２で算出された前記読み込み開始アドレス（図７では１００バイト目）から、前記データ管理情報のおける前記「データサイズ」に応じたサイズ分（図７では１２０バイト分）だけデータが読み込まれる（Ｓ３３）。
本実施形態では、このような一連の処理を実行することで、前記フラッシュメモリＸに格納されている複数のデータから特定のデータを読み込むに当たり、該データの前記データ管理情報に基づいて特定のデータの格納位置、及びデータサイズを容易且つ正確に検索可能である。
このように、本実施形態では、前記物理ブロックに記録されるデータが、該データのデータサイズと同一サイズであって、前記物理ブロックの所定位置（本実施形態では先頭）から隙間なく順次作成されるデータ格納領域に格納される構成を巧妙に利用することで、前記データ管理情報に基づいて特定のデータを正確且つ迅速に読み込むことが可能である。
尚、図７は、「レコードＩＤ：０」を指定してフラッシュメモリの物理ブロック０に格納されているレコードＩＤ０データ（新）（レコードＩＤ：０、データサイズ：１２０バイト、データの種別：レコード）を読み込む様子を模式的に示すものである。
同図から、前記データ管理情報格納領域ｂ１及びｂ２に格納されている前記データ格納情報における「データサイズ」、「データの状態」に基づいて、今回読み込むべき前記レコードＩＤ０データ（新）が、前記物理ブロック０の先頭から１００バイト目のアドレスから１２０バイト分の領域に格納されていることが特定され、しかる後、読み込まれる様子が理解される。
【００１５】
【実施例】
上述した実施形態では、前記物理ブロックの未使用領域の先頭から前記データ格納領域ａが作成され、最後尾から前記データ管理情報格納領域ｂが作成される形態について説明している。
しかしながら、上述の実施形態とは逆に、前記データ格納領域ａが前記物理ブロックの未使用領域の最後尾から作成され、前記データ管理情報格納領域ｂが先頭から作成される形態も考え得る。この場合にも、上述した実施形態と同様に、前記物理ブロック０に無用な不使用領域を生成することなく、フラッシュメモリの実効容量を増大させることが可能であることは理解に易しい。
【００１６】
また、上述した実施形態及び実施例では、前記物理ブロックの未使用領域の先頭或いは最後尾から前記データ格納領域ａ及び前記データ管理情報格納領域ｂが作成される形態について説明している。
しかしながら、前記データ格納領域ａ及び前記データ管理情報格納領域ｂの作成が開始される位置は、前記物理ブロックの未使用領域の先頭或いは最後尾に限定されるものではなく、その作成を開始した所定位置のアドレスが特定可能であればどこから開始されてもかまわない。
つまり、その所定位置（つまりは、アドレス）が特定できれば、前述説明したデータの読み込み処理に際し、そのアドレス分を加味した上で前記読み込み開始アドレスを算出することが可能である。
従って、例えば、前記消去ブロックに予め何らかの消去不可能なデータが格納されている（無論、未使用領域として確保されたたものでもよい）ようなフラッシュメモリであっても、そのデータサイズ（アドレス）を特定（取得）することで本発明を適用することが可能である。
【００１７】
【発明の効果】
以上説明したように、本発明によれば、フラッシュメモリに格納されるデータを、該データのデータサイズに応じて作成された前記データ格納領域に格納することが可能となる。
従って、データサイズに拘わらず画一的に形成された前記仮想セクタに格納していた従来構成に比べ、飛躍的にフラッシュメモリの実効容量を増大させることができる。
また、実効容量が増大したことに伴い、フラッシュメモリに対しガーベージコレクションを行う頻度が低減され、該フラッシュメモリ（前記消去ブロック）に対する無用なデータ消去処理を回避することが可能となり、ひいては、フラッシュメモリの長寿命化を達成することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るフラッシュメモリのデータ管理システムの概略構成を模式的に示す図。
【図２】新規データの書き込みを行った際の処理の流れを示すフローチャート。
【図３】新規データの書き込みを行った際の消去ブロックを模式的に示す図。
【図４】データ更新を行った際の処理の流れを示すフローチャート。
【図５】データ更新を行った際の消去ブロックを模式的に示す図。
【図６】データの読み込みを行った際の処理の流れを示すフローチャート。
【図７】データの読み込みを行った際の消去ブロックを模式的に示す図。
【図８】従来公知のフラッシュメモリのデータ管理システムの概略構成を模式的に示す図。
【符号の説明】
Ｘ …フラッシュメモリ
ａ …データ格納領域
ｂ …データ管理情報格納領域
ｃ …ブロック管理情報格納領域
Ｓ１、Ｓ１、、…処理手順（ステップ）の番号
Claims (9)
- 不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成手段と、
前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成手段と、
前記データを、前記データ格納領域作成手段により作成された前記データ格納領域に格納するデータ格納手段と、
前記データ格納手段による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成手段により作成された前記データ管理情報格納領域に格納するデータ管理情報格納手段と、
を具備してなることを特徴とする不揮発性メモリのデータ管理システム。 - 前記データ格納領域作成手段により作成される前記データ格納領域は、前記消去ブロックにおける所定位置から順次隙間無く作成されてなる請求項１に記載の不揮発性メモリのデータ管理システム。
- 前記所定位置は、前記消去ブロックにおける先頭或いは最後尾である請求項２に記載の不揮発性メモリのデータ管理システム。
- 前記データ管理情報格納領域作成手段により作成される前記データ管理情報格納領域は、前記消去ブロックにおける先頭或いは最後尾のいずれか一方のうち、前記データ格納領域が作成される反対側から順次隙間無く作成されてなる請求項１〜３のいずれかに記載の不揮発性メモリのデータ管理システム。
- 不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成工程と、
前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成工程と、
前記データを、前記データ格納領域作成工程により作成された前記データ格納領域に格納するデータ格納工程と、
前記データ格納工程による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成工程により作成された前記データ管理情報格納領域に格納するデータ管理情報格納工程と、
を具備してなることを特徴とする不揮発性メモリのデータ管理方法。 - 前記データ格納領域作成工程により作成される前記データ格納領域は、前記消去ブロックにおける所定位置から順次隙間無く作成されてなる請求項５に記載の不揮発性メモリのデータ管理方法。
- 前記所定位置は、前記消去ブロックにおける先頭或いは最後尾である請求項６に記載の不揮発性メモリのデータ管理方法。
- 前記データ管理情報格納領域作成工程により作成される前記データ管理情報格納領域は、前記消去ブロックにおける先頭或いは最後尾のいずれか一方のうち、前記データ格納領域が作成される反対側から順次隙間無く作成されてなる請求項５〜７のいずれかに記載の不揮発性メモリのデータ管理方法。
- 不揮発性メモリのデータ管理システムにおいて実行されるプログラムであって、
前記不揮発性メモリの消去ブロック上に格納するデータのデータサイズと同一サイズのデータ格納領域を作成するデータ格納領域作成機能と、
前記不揮発性メモリの前記消去ブロック上に前記データに関する所定の情報を表すデータ管理情報を格納するデータ管理情報格納領域を作成するデータ管理情報格納領域作成機能と、
前記データを、前記データ格納領域作成機能により作成された前記データ格納領域に格納するデータ格納機能と、
前記データ格納機能による前記データの格納処理に応じて、前記データ管理情報を、前記データ管理情報格納領域作成機能により作成された前記データ管理情報格納領域に格納するデータ管理情報格納機能と、
を実行させるためのデータ管理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002332056A JP2004164493A (ja) | 2002-11-15 | 2002-11-15 | 不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002332056A JP2004164493A (ja) | 2002-11-15 | 2002-11-15 | 不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004164493A true JP2004164493A (ja) | 2004-06-10 |
Family
ID=32809241
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002332056A Pending JP2004164493A (ja) | 2002-11-15 | 2002-11-15 | 不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004164493A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006260468A (ja) * | 2005-03-18 | 2006-09-28 | Nec Electronics Corp | 半導体装置 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS62167695A (ja) * | 1986-01-20 | 1987-07-24 | Shinko Electric Co Ltd | メモリ書込方法 |
| JPH04145596A (ja) * | 1990-10-08 | 1992-05-19 | Fuji Photo Film Co Ltd | メモリカードにおけるデータ管理方式 |
| JPH05158771A (ja) * | 1991-12-03 | 1993-06-25 | Hitachi Ltd | ファイル管理方法及びシステム |
| JPH06223591A (ja) * | 1992-10-30 | 1994-08-12 | Intel Corp | フラッシュｅｅｐｒｏｍアレイのクリーン・アップ方法 |
-
2002
- 2002-11-15 JP JP2002332056A patent/JP2004164493A/ja active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS62167695A (ja) * | 1986-01-20 | 1987-07-24 | Shinko Electric Co Ltd | メモリ書込方法 |
| JPH04145596A (ja) * | 1990-10-08 | 1992-05-19 | Fuji Photo Film Co Ltd | メモリカードにおけるデータ管理方式 |
| JPH05158771A (ja) * | 1991-12-03 | 1993-06-25 | Hitachi Ltd | ファイル管理方法及びシステム |
| JPH06223591A (ja) * | 1992-10-30 | 1994-08-12 | Intel Corp | フラッシュｅｅｐｒｏｍアレイのクリーン・アップ方法 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006260468A (ja) * | 2005-03-18 | 2006-09-28 | Nec Electronics Corp | 半導体装置 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4832521B2 (ja) | フラッシュメモリメディアにおけるデータ管理方法 | |
| KR100453053B1 (ko) | 플래쉬 메모리용 파일 시스템 | |
| KR100644602B1 (ko) | 플래시메모리를 위한 재사상 제어방법 및 그에 따른플래시 메모리의 구조 | |
| US7191306B2 (en) | Flash memory, and flash memory access method and apparatus | |
| US8667213B2 (en) | Flash management techniques | |
| KR100595909B1 (ko) | 저장장치 및 플래시 메모리 장치내 정보 액세스 방법 및 정보 저장 관리 방법 | |
| CA2574756C (en) | Systems, methods, computer readable medium and apparatus for memory management using nvram | |
| US8484432B2 (en) | Memory system | |
| JP4415356B2 (ja) | 二重ジャーナリングの保存方法及びその記憶媒体 | |
| JP2006040264A (ja) | メモリカードの制御方法および不揮発性半導体メモリの制御方法 | |
| JP2006235960A (ja) | ガーベッジコレクション高速化方法 | |
| KR20100080350A (ko) | 전력 손실 이후의 비-휘발성 메모리에 대한 복원 | |
| JP5874525B2 (ja) | 制御装置、記憶装置、記憶制御方法 | |
| JP5183662B2 (ja) | メモリ制御装置及びメモリ制御方法 | |
| CN112596668A (zh) | 一种存储器的坏块处理方法及系统 | |
| US20070005929A1 (en) | Method, system, and article of manufacture for sector mapping in a flash device | |
| JP2008123314A (ja) | 半導体記憶装置への情報記録方法及び情報記録システム | |
| JP4175881B2 (ja) | 不揮発性メモリの記憶方法及び記憶装置 | |
| JP3808842B2 (ja) | 書き換え可能な不揮発性メモリを備えた記憶装置及び記憶装置用不揮発性メモリの制御方法 | |
| US20030200232A1 (en) | Information processor and program | |
| JP4419415B2 (ja) | 記録方式 | |
| JP2004164493A (ja) | 不揮発性メモリのデータ管理システム、不揮発性メモリのデータ管理方法、およびそのプログラム | |
| KR100319254B1 (ko) | 플레쉬 메모리를 이용한 비휘발성 데이터 영역 복구 방법 | |
| JPH0764831A (ja) | データ記憶装置 | |
| JP2001318824A (ja) | フラッシュメモリのデータ管理方式およびそのプログラムを記録した記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050719 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20050801 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20050801 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050913 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20051004 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051201 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20051215 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20060120 |