JPH11272537A - フラッシュ型メモリ及びその管理装置 - Google Patents

Abstract

(57)【要約】 【課題】ブロック消去方式のフラシュ型メモリを使用す
る際に、消去回数の制限を補う効率的なメモリ管理を行
う。 【解決手段】 管理制御情報を物理ブロックのへッダ領
域に記憶し、データファイルをセグメント化したデータ
を、物理ブロックＸ,ＸＸ，ＸＹのデータファイル領域
に割り当て、その連鎖情報もヘッダ領域に格納する。デ
ータファイルを読み出すときは、有効な前ブロックポイ
ンタの中から先頭であるブロックＸを検索するととも
に、その後、その先頭物理ブロックに格納されている後
ブロックポインタの示す物理ブロックＸＹを検索する。
この操作を、後ブロックポインタが最終となる物理ブロ
ックＸＸまで繰り返すことで、連鎖的にファイル読み出
しが行われる。データセグメントのデータの削除・移動
は、ヘッダ情報の更新によって行われる。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、フラッシュ型メモリ及
びその管理装置にかかり、更に具体的には、フラッシュ
型メモリの効率的な管理手法の改良に関するものであ
る。

【０００２】

【従来の技術と発明が解決しようとする課題】フラッシ
ュタイプのフローティングケートトランジスタを含む電
気的消去可能なプログラマブル読み出し専用メモリ（Ｅ
ＥＰＲＯＭ），いわゆるフラッシュメモリは、各方面で
実用化されて広く普及しており、市場で容易に入手可能
である。これらフラッシュメモリは、機能・性能面でＥ
ＰＲＯＭメモリと類似した不揮発メモリであり、メモリ
内で分割されているブロックを消去する回路内プログラ
マプル動作を可能にするという機能を更に有する。

【０００３】フラッシュメモリでは、以前に書き込まれ
たメモリの領域を前もってブロック単位で消去すること
で、その書換えが行なわれる。典型的なコンピュータシ
ステムでは、オペレーティングシステム（以下「ＯＳ」
という）プログラムがそのシステムのデータ記憶装置の
デ−タ管理を担う。ＯＳプログラムとの互換性を達成す
るために必要かつ十分なデータ記憶装置のアトリビュー
ト（属性）は、データ記憶媒体の如何なる位置からもデ
ータを読み出すことができ、またその位置にデータを書
き込むことができることである。しかし、フラッシュメ
モリの場合、データが既に書き込まれている領域には、
その領域に書き込まれているデータを消去しなければ、
新たにデータを書き込むことができない。このため、フ
ラッシュメモリは、典型的な既存のＯＳプログラムとは
互換性がない。

【０００４】このような点に着目し、既存のコンピュー
タオペレーティングプログラムによってフラッシュメモ
リを管理することを可能にするソフトウェアが、例えば
特開平５−１７３８７１号公報，特開平６−９５９５５
号公報，特表平８−５１００７２号公報に開示されてい
る。しかしながら、これらの先行技術は、フラッシュメ
モリを「書き込み１回・読み出し複数回」の装置として
動作させるか、「書き込み複数回・読み出し複数回」の
装置として動作させている。これらのうち、前者は、以
前に書き込まれているメモリ場所を再利用することはで
きない装置であり、補助記憶装置や拡張記憶装置として
使用するものである。後者は、以前に書き込まれている
メモリの場所を再利用可能とし、その中にはフラッシュ
メモリの書き換え回数を少なくするような制御を持つ補
助記憶装置（半導体ファイル記憶装置）がある。

【０００５】このような先行技術に対し、特願平９−３
１７６１２号として出願されたフラッシュメモリがあ
る。これによれば、フラッシュメモリを使用した拡張記
憶装置上では、書き換え回数を少なくなるような制御構
造を持たずに実行プログラムを動作させている。しか
し、フラッシュメモリに対して新たにデータの書き換え
を行なうときは、全ブロックを−括して消去し、その後
データを記憶させる必要がある。

【０００６】また、マルチタスク，マルチスレッド，マ
ルチプロセスに代表される並列実行プログラムやデータ
の共有あるいは占有という管理を行う場合において、−
般のＭＭＵ（メモリ管理ユニット）を駆使しフラッシュ
メモリのブロック（ないしページ）毎に管理する方式で
は、書き換え回数の管理と書き換え回数の低減を図るこ
とは困難である。

【０００７】−方、フラッシュメモリを使用した拡張記
憶装置上でプログラムの実行を可能とする装置にはない
ものの、フラッシュメモリの書き換え回数を少なくする
ような制御構造を持つ装置としては、補助記憶装置（半
導体ファイル記憶装置）があり、書き換え回数を少なく
するためにその情報（書き換え回数テーブル）を異なる
メモリ上に記憶する方式がある。しかし、実行プログラ
ムを主記憶装置にロードすることなくフラッシュメモリ
上で動作させるプログラムにおいて、単純に同−フラッ
シュメモリ上に記憶する場合では、ブロック間にまたが
るデータを無駄なく完全に連続的な配置を可能すること
は困難である。

【０００８】以上のように、従来技術には、次のような
不都合がある。 （１）１つのデータファイルでは複数のデータレコード
を持つことが可能だが、その結合されたデータレコード
の記憶領域としては、１ブロックのデータ記憶領域に収
めなけれはならない。（データファイル：ブロック数＝
１：１のとき）

【０００９】（２）１ブロックの記憶領域を超えるサイ
ズのデータレコード（スパンドレコード）を格納すると
き、そのデータレコードを１ブロックの記憶領域のサイ
ズでブロッキングするとともに、それそれの各セグメン
トにデータファイル名を個別に名付け、アプリケーショ
ン層のプログラム自身が直接各セグメントをそれぞれの
データファイル名で管理・制御しなけれはならない。
（データレコード：データファイル＝１：多）

【００１０】（３）複数のデータレコードを結合し、そ
の結合したデータのサイズが１ブロックを超えるサイズ
であり、その結合したレコードを１ブロックの記憶領域
のサイズでブロッキングし、各セグメントを割り当てら
れたそれぞれのデータファイルのデータ記憶領域に格納
するときも、アプリケーション層のプログラム自身が直
接各セグメントをそれぞれのデ−タファイル名で管理し
制御しなければならない。（データレコード：データフ
ァイル＝多：多）

【００１１】（４）前記（２）や（３）おいて、アプリ
ケーション層のプログラムが結合されたデータレコード
をブロッキングした各セグメントと対比するそれぞれデ
ータファイルとのリンク情報を別メモリに格納するか、
又はデータファイル内にその情報を持たせることにな
る。このリンク情報が別メモリで管理されることになる
と別メモリが必要となり、システムを構築するために
は、低コストや省スペースの点で不利である。また、デ
ータファイルとして格納する方法では、リンク情報の更
新や修正などを行なう際のオーバヘッドが大きいこと
や、管理の複雑化になることは明らかである。

【００１２】この発明は、以上の点に着目してなされた
ものであり、その目的はフラッシュメモリを使用した補
助記憶装置もしくは拡張記憶装置上で、フラッシュメモ
リの書き換え回数を少なくするような制御構造を持つ場
合に、主記憶装置に実行プログラムをロードすることな
く、拡張記憶装置上でプログラムの実行を可能とするこ
とである。他の目的は、同−のフラッシュメモリを使用
し、補助記憶装置もしくは拡張記憶装置として、書き換
え回数を少なくする無駄のない制御構造をもちながら、
マルチフロセッシング，マルチスレッド，マルチタスク
といった高度なプログラムの実行環境においてもメモリ
管理装置によって、安全に実行プログラムのモジュール
やデータファイルの管理の実現を可能とすることであ
る。

【００１３】更に他の目的は、同−のフラッシュメモリ
上で、拡張記憶装置及び補助記憶装置の混在を可能とす
るファイル管理技術を提供することである。更に他の目
的は、フラッシュメモリを使用した補助記憶装置もしく
は拡張記憶装置として、データレコードのブロッキング
サイスが１物理ブロックを超える場合でも１つのデータ
ファイルとして、管理・制御できる装置を実現すること
である。更に他の目的は、補助記憶装置もしくは拡張記
憶装置としてデータファイルを格納するとき、アプリケ
ーション層のプログラムからのアクセスを容易にして、
データアクセスの高速化を実現することである。

【００１４】

【課題を解決するための手段】本発明のフラッシュ型メ
モリは、ブロック単位で記憶内容を消去できるフラッシ
ュ型メモリの物理ブロックに、そのブロックの管理情報
として論理的な前後のブロック番号等を記憶するへッダ
領域と、データファイルを消去ブロック単位に分割した
スパンドレコードを格納する記憶領域とを備えたことを
特徴とする。

【００１５】本発明のフラッシュ型メモリの管理装置
は、（１）データファイルのスパンドレコードの第１セ
グメントが格納されていることを示す先頭ブロックの情
報，（２）データファイルのスパンドレコードの最終セ
グメントが格納されていることを示す最終ブロックの情
報，（３）データファイルのスパンドレコ−ドの中間セ
グメントが格納されていることを示す中間ブロックの情
報，（４）物理ブロックのセグメントの前のセグメント
が格納されている物理ブロックを示す情報，（５）その
物理ブロックのセグメントの後のセグメントが格納され
ている物理ブロックを示す情報，（６）前記物理ブロッ
ク内の個々の情報が個々に有効か無効かを示す情報，
（７）前記物理ブロック内の個々の管理情報が無効にな
ったときに更新される新管理情報，を備えたことを特徴
とする。

【００１６】更に、前記管理装置は、（１）ブロック単
位に分割されたデータファイルのスパンドレコードの各
セグメントを、それぞれ物理ブロックに割り当てるとと
もに、各物理ブロックの管理情報を、該当する物理ブロ
ックにそれぞれ格納する手段，（２）システムの復旧や
データの復元を行なう手段，（３）各物理ブロックに格
納されているデータの書き換え回数を低減する手段，の
いずれかを備えたことを特徴とする。

【００１７】

【発明の実施の形態】以下、本発明の実施の形態につい
て詳細を説明する。本形態は、例えば図１に示すよう
に、プロセッサ（ＣＰＵ）１、フラッシュメモリ２及び
その制御装置３を含む補助記憶装置（もしくは拡張記憶
装置）４、ランダムアクセスメモリ（ＲＡＭ，主記憶装
置）６を含むコンピュータシステムに適用される。本発
明は、このようなシステムでフラッシュメモリ２の書き
換え寿命を延命させるデータの格納方法と管理・制御の
ための装置を得ようとするものである。

【００１８】まず、データ領域を管理するために、フラ
ッシュメモリの管理単位をその最小イレース（消去）単
位である１ブロックとする。そして、この最小単位であ
る各ブロック内にはデータ領域と、そのブロックを管理
する情報を持つへッダ領域とが存在する。

【００１９】図２には、本形態におけるソフトウェアの
基本構造の−例が示されている。同図のように、ＯＳ６
やアプリケーションソフト７とのソケットインタフェー
スとして、いわゆるドライバ層８に相当する部分に、フ
ラッシュ管理マネージャ９を設ける。このフラッシュ管
理マネージャ９は、本形態システム用ドライバ層と考え
ることができる。このようなフラッシュ管理マネージャ
９によって、ブロック情報の管理やデータの読み出し
（リード）／書き込み（ライト）の制御が行なわれる。

【００２０】例えば、図３［Ａ］に示すように、ブロッ
ク消去がｉバイト単位で可能で、かつブロック数がｎ＋
１（１６進数）個あるフラッシュメモリが１つあるとす
る。以下、これら各ブロックを「物理ブロック」と呼
ぶ。各物理ブロックには、アドレスの低い方から高い方
へ順に、物理ブロックナンバ「０」〜「ｎ」を割り振
る。図示の例では、図の上方はアドレスが低く、下方は
アドレスが高い。従って、図の上方から、物理ブロック
０，物理ブロック１，物理ブロック２，………，物理ブ
ロックｎ−１，物理ブロックｎとなっている。

【００２１】ここで、各物理ブロックを管理している情
報のへッダ領域としてｊバイト分を確保したとすると、
各物理ブロックに割り当てられるデータファイル領域の
サイズは、ｉ−ｊバイトとなる。この様子を示すと、図
３［Ｂ］のようになる。例えば、最上位置のナンバ
「０」の物理ブロックＢＬＡには、ｊバイトのへッダ領
域ＨＡとｉ−ｊバイトのデータファイル領域ＤＡが存在
する。次のナンバ「１」の物理ブロックＢＬＢには、ｊ
バイトのへッダ領域ＨＢとｉ‐ｊバイトのデータファイ
ル領域ＤＢが存在する。以下の物理ブロックについても
同様である。

【００２２】そして、１データファイルをスパンドレコ
ードとして取り扱い、その中の各セグメントのデータを
物理ブロックのデータファイル領域に格納する。各セグ
メントのデータが格納された物理ブロックにおけるヘッ
ダ領域には、そのセグメント（物理ブロック）の論理的
に連鎖するセグメントの情報や、それらの情報が有効な
情報かそれとも無効な情報かを示す情報が格納される。
また、それらの情報を更新するための情報領域も設けら
れる。

【００２３】図４［Ａ］に示す例は、１つのデータファ
イルが３（ｉ−ｊ）−ｋバイトある複数のデータレコー
ドからなるファイルの例である。このデータファイルを
１つのスパンドレコードとして扱うと、同図［Ｂ］に示
すように３つのセグメントに分割される。すなわち、タ
ファイルのレコードの最初の部分からｉ−ｊバイト分を
第１のセグメントとし、その続きからｉ‐ｊバイト分を
第２のセグメントとし、その続きからｉ−ｊ‐ｋバイト
分とその後のｋバイト分のＦＦｈデータを第３のセグメ
ントとする。そして、同図［Ｃ］に示すように、これら
の第１〜第３の各セグメントに、ブロックヘッダである
ＢＣＷ（ブロックの管理情報）と、ＳＣＷ（セグメント
の管理情報）をそれぞれ付加し、物理ブロックを構成す
る。これを前記図３［Ｂ］と対比すると、ＢＣＷ，ＳＣ
Ｗはブロックヘッダ領域に格納され、各セグメントはデ
ータファイル領域に格納される。

【００２４】次に、物理ブロックのへッダ領域について
説明する。データファイルをスパンドレコードとして取
り扱った場合、その中のセグメントの情報（ＳＣＷ），
そのセグメント（物理ブロック）の論理的に連鎖するセ
グメントの情報，それらの情報が有効な情報かそれとも
無効な情報かを示すような情報，が物理ブロックヘッダ
に必要である。そこで、例えば、物理ブロックヘッダ
に、次のような割り当てを行う。

【００２５】（１）物理ブロックの状態（有効／無効／
遷移中／初期化）を示すフラグ （２）データファイル名（又はデータファイルを特定す
る情報） （３）該当するファイルの先頭ブロック（先頭セグメン
ト）を示すフラグ又はそれに相当する手段 （４）該当するファイルの最終ブロック（最終セグメン
ト）を示すフラグ又はそれに相当する手段

【００２６】（５）該当するファイルの中間ブロック
（中間セグメント）を示すフラグ又はそれに相当する手
段 （６）該当するブロックの前のブロック番号を示す前ブ
ロックポインタを格納する領域 （７）上記（６）の領域が有効／無効／未格納のいずれ
であるかを示すフラグ （８）該当するブロックの後のブロック番号を示す後ブ
ロックポインタを格納する領域 （９）上記（８）の領域が有効／無効／未格納のいずれ
であるかを示すフラグ

【００２７】（１０）該当するブロックの前のブロック
ポインタが示す領域が無効のとき、更新される番号を示
す前ブロックポインタの情報を格納する更新領域 （１１）上記（１０）の領域が有効／無効／未格納のい
ずれであるかを示すフラグ （１２）該当するブロックの後のブロックポインタが示
す領域が無効のとき、更新される番号を示す後ブロック
ポインタの情報を格納する更新領域 （１３）上記（１２）の領域が有効／無効／未格納のい
ずれであるかを示すフラグ

【００２８】以下、順に説明する。まず、「（１）のフ
ラグ」から説明する。フラッシュ管理マネージャ９は各
ブロックヘッダの内容を読み、フラッシュメモリ２にど
のようにデータが格納されているかを確認して管理す
る。フラッシュメモリ２のメモリセル内のビットデータ
は、論理値の「１」→「０」への変化の処理時間は比較
的に短い。しかし、反対に、「０」→「１」の変化は、
−度ブロックイレース又はチップイレースを行わなけれ
ばならず、長時間を要する。つまり、１ビットのデータ
の書き換えを行なうために、そのブロック内（又はチッ
プ内）のデータを−時待避させるとともに、イレース後
それらを書き戻す必要があり、大きな処理時間を要す
る。

【００２９】そこで、実際には、物理ブロックの状態を
示すフラグを利用してその物理ブロックの状態を管理す
ることになる。すなわち、上述した書き換えに伴うオー
バヘッドを軽減するために、物理ブロックヘッダ内にそ
の物理ブロックが有効な状態なのか，無効な状態なの
か，初期化が完了した状態なのか，有効な状態から無効
な状態への遷移する状態なのか，ブロックイレース後の
初期化完了前の状態なのか，といった状態をそれぞれの
物理ブロック毎に認識する。そして、この状態に基づい
て、データの書き込み，データの無効化，物理ブロック
のイレース，物理ブロックの初期化などの操作を行な
う。

【００３０】「（２）のデータファイル名」は、スパン
ドレコードを取り扱っている論理データレコードの名称
である。各物理ブロックは、このデータファイル名によ
り分類される。なお、データファイル名は、データファ
イルが特定できる情報であってもよい。

【００３１】「（３）の該当するファイルの先頭ブロッ
ク（先頭セグメント）を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの先頭セグメントが格納されていることを明示する
ものである。

【００３２】「（４）の該当するファイルの最終ブロッ
ク（最終セグメント）を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの最終セグメントが格納されていることを明示する
ものである。

【００３３】「（５）の該当するファイルの中間セグメ
ントを示すフラグ又はその手段」は、その物理ブロック
のデータ領域に、該当するデータファイルの先頭や最終
ではなく中間のセグメントが格納されていることを明示
するものである。

【００３４】「（６）の該当するブロックの前のブロッ
ク番号を示す前ブロックポインタを格納する領域」は、
該当する物理ブロックの前に論理的に連鎖する物理ブロ
ックの番号情報を格納する領域である。なお、前の物理
ブロック番号情報は、そのデータファイルの中における
該当セグメントの前のセグメントのデータが格納されて
いる物理ブロックを示すものである。

【００３５】「（７）の前記（６）の領域が有効／無効
／未格納のいずれであるかを示すフラグ」は、前記
（６）の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記（６）の領域の情報が最終
の情報であるかどうかが決まる。

【００３６】「（８）の該当する物理ブロックの後の物
理ブロック番号を示す後ブロックポインタを格納する領
域」は、該当する物理ブロックの後に論理的に連鎖する
物理ブロックの番号の情報を格納する領域である。な
お、後の物理ブロック番号の情報は、そのデータファイ
ル中における該当セグメントの後のセグメントのデータ
が格納されている物理ブロックを示すものである。

【００３７】「（９）の前記（８）の領域が有効／無効
／未格納のいずれであるかを示すフラグ」は、前記
（８）の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記（８）の領域の情報が最終
の情報であるかどうかか決まる。

【００３８】「（１０）の該当するブロックの前ブロッ
クポインタが示す領域が無効のとき、新たに更新される
番号を示す前ブロックポインタの情報を格納するための
更新領域」は、最初に有効だった前ブロックポインタ
（最初の情報領域や更新情報領域）の情報領域が無効と
なり、新たに更新したときに情報を格納するための更新
情報領域である。

【００３９】「（１１）の更新された前ブロックポイン
タを格納する情報の領域が有効／無効／未格納を示すフ
ラグ」は、前記（１０）で格納されている情報領域が有
効な状態なのか、無効な状態なのか、未格納な状態なの
かを表すものである。

【００４０】「（１２）の該当する物理ブロックの後ブ
ロックポインタが示す領域が無効のとき、新たに更新さ
れる番号を示す前ブロックポインタの情報を格納するた
めの更新領域」は、最初に有効だった後ブロックポイン
タ（最初の情報領域や更新情報領域）の情報領域が無効
となり、新たに更新したときに情報を格納するための更
新情報領域である。

【００４１】次に、「（１３）の更新された後ブロック
ポインタを格納する情報の領域が有効／無効／未格納を
示すフラグ」は、前記（１２）で格納されている情報領
域が、有効な状態なのか、無効な状態なのか、未格納な
状態なのかを表すものである。

【００４２】次に、物理ブロックのデータファイル領域
について説明する。データファイルの配置は、フラッシ
ュ管理マネージャ９によって行われる。データファイル
として、例えば、図５［Ａ］に示すようなデータレコー
ド１〜ｎの論理的なデータがあるとする。このデータフ
ァイルは、図５［Ｂ］に示すように、物理ブロックヘッ
ダの領域を除くデータファイル領域にスパンドレコード
のセグメントのレコードとして格納されることになる。

【００４３】ここで、データの構造として、データファ
イル内の論理的なデータをデータレコードにブロッキン
グ（ブロック化）し、図５［Ｃ］に示すように、そのデ
ータレコードＤＲにデータレコードヘッダＤＲＨやデー
タレコードフッダＤＲＦを付随させた形でデータレコー
ドのパケットＤＲＰを構成する。このようなブロッキン
グの方法としては、固定長レコードと可変長レコードが
ある。本形態ではどちらでもよい。しかし、ブロッキン
グは、ＯＳやアプリケーションソフトに依存することが
多いため、システム上、フラッシュ管理マネージャ９が
ブロッキングの方法を決定して制御する。また、データ
レコードヘッダＤＲＨやデータレコードフッダＤＲＦに
は、線形リスト構造とそのパケットの管理用情報を持た
せるようにする。すると、データレコードパケットＤＲ
Ｐは、図６に示すようなデータ構造を持つことになる。
このデータレコードパケットＤＲＰのデータ構造のサイ
ズは、ｉ−ｊバイトの倍数分の３ブロックであり、デー
タレコードパケットＤＲＰが格納される部分以外には
「０ｘＦＦ」のデータが格納される。

【００４４】このように、データファイルの論理的なデ
ータレコードＤＲは、割り当てられた物理ブロックのデ
ータファイル領域にデータレコードパケットＤＲＰとし
て格納される。また、図６に示すように、それらのデー
タレコードパケットＤＲＰにしたデータ構造をｉ−ｊバ
イトづつブロッキングし、そのブロッキングしたものを
スパンドレコードのセグメントとする。

【００４５】図７には、ブロッキングした後に各セグメ
ントを物理ブロックに割り当てたときのセグメントデー
タの格納結果を表している。この例では、ブロックＸの
データファイル領域には、データファイルＡの先頭セグ
メントのデータが格納されており、ヘッダ領域には、先
頭セグメントであることを示す「先頭（有効）」と、次
の中間セグメントデータが格納されている物理ブロック
を示す「ＸＹ（有効）」の情報が格納されている。ブロ
ックＸＹのデータファイル領域には中間セグメントデー
タが格納されており、ヘッダ領域には、前のセグメント
データが格納されている物理ブロックを示す「Ｘ（有
効）」と、次のセグメントデータが格納されている物理
ブロックを示す「ＸＸ（有効）」の情報が格納されてい
る。更に、ブロックＸＸのデータファイル領域には最終
セグメントデータが格納されており、ヘッダ領域には、
前のセグメントデータが格納されている物理ブロックを
示す「ＸＹ（有効）」と、本物理ブロックに最終のセグ
メントデータが格納されていることを示す「最終（有
効）」の情報が格納されている。フラッシュ管理マネー
ジャ９は、データレコードパケットＤＲＰの管理と、物
理ブロックＢＬの管理という２重管理を行なう。

【００４６】図８，図９には、データファイルをフラッ
シュメモリに格納する様子が示されている。この例で
は、図８に示すように、データファイルＡ、データファ
イルＢ、データファイルＣ、…のファイルがある。そし
て、データファイルＡは、論理的なデータをデータレコ
ード毎にパケット化して全体をセグメント化すると３ブ
ロック必要となり、それらを物理ブロック０，２，ｍ＋
１にそれぞれ割り当てている。データファイルＢ，デー
タファイルＣ，…についても、同様にして複数のブロッ
クを使用し、それぞれの物理ブロックにセグメントデー
タが割り当てられている。データが割り当てられていな
いブロック（未割当てブロック）として、物理ブロック
ｎ‐１，ｎがある。

【００４７】図９は、前記データファイルＡについて、
そのパケット化とセグメント化の様子を示している。デ
ータファイルＡは、同図［Ａ］に示すように、論理的な
データとして、データレコード［０］〜［９］までを持
っている。次に、同図［Ｂ］に示すように、これらの各
データレコードに各々データレコードヘッダＤＲＨやデ
ータレコードフッダＤＲＦを付加し、データレコードパ
ケットＤＲＰを完成する。そして、連結したデータレコ
ードパケットＤＲＰを、データファイルＡのスパンドレ
コードとしてセグメント単位に分割し、分割したセグメ
ントをセグメント０〜２とする。データレコード［９］
の後のデータには、すべて「０ｘＦＦ」が格納される。
これは、フラッシュメモリの特性から、ビットを「１」
から「０」に書き込むことになり、このシステムでは新
データレコードを追記していくことに対応するためであ
る。そして、同図［Ｃ］に示すように、セグメント化し
た０〜２のデータを、割り当てられている物理ブロック
［１］，物理ブロック［２］，物理ブロック［ｍ＋１］
のデータファイル領域にそれぞれ格納する。その後、各
物理ブロックヘッダにそれらの内容の管理情報を格納す
る。

【００４８】次に、物理ブロックの初期化の手順につい
て説明する。フラッシュ管理マネージャ９は、フラッシ
ュメモリ２が管理されていなければ、まず最初に各物理
ブロックの初期化を行なう。初期化する場合は、−度す
べての物理ブロックをイレースして、各物理フロックの
ブロックヘッダに初期化完了フラグの情報を格納する。
また、システムを使用していくうちに、データファイル
領域のセグメントデータを消去できるような状況になっ
たときは、その物理ブロックをブロックイレースして、
その物理ブロックのブロックヘッダに初期化完了フラグ
の情報を格納する。初期化が完了すると、その物理ブロ
ックは、新たなデータファイル領域として、データの新
規書き込みあるいはデータレコードの連結を行なうこと
ができる。

【００４９】次に、データファイル領域にデータを格納
するときの手順について説明する。この場合は、まず、
割り当てる物理ブロックヘッダの有効フラグをＯＮに
し、データファイル名を格納する。その後ブロッキング
されたデータレコードをデータ領域内に順次格納してい
く。データレコードは追記していくことになるが、デー
タレコードを書き換えたい場合は、フラッシュメモリの
特徴からその部分を書き換えることは、上述したように
オーバーヘッドが大きい。小さいオーバーヘッドで旧論
理データレコードから新論理データレコードへデータを
書き換える方法としては、（１）旧データレコードを無
効とし、新たにデータレコードを追記していく方法，
（２）その物理ブロックの遷移中フラグをＯＮ（処理終
了後無効フラグをＯＮにする）にするとともに、その物
理フロックの代替ブロックを割り当て、この代替ブロッ
クにデータを新たに格納し、連鎖情報を戻す方法があ
る。

【００５０】最初の（１）の方法では、無効なデータレ
コードのみならず、有効なデータレコードも無効にし
て、その有効だったデータを新たに追記しなければなら
ない。−方、後述の（２）の方法によれば、ブロック全
体の書き換えを行なうため、データを書き込むための処
理に時間がかかる。従って、前記（１）の方法では小さ
なデータレコードは非常に高速に処理できるが、大きな
データレコードには不向きである。逆に、後述の（２）
の方法では、大きなデータレコードとっては無駄の少な
いシステムとして運用できるが、小さなデータレコード
には不向きである。そこで、本形態では、セグメントを
無効とするか，データレコードを無効とするか，セグメ
ントを書き換えるか，データレコードを更新するか，の
いくつかの方法の組み合わせによって最適なシステムを
構成する。このようにすることで、最終的にフラッシュ
メモリの書き換え回数を低減することができる。

【００５１】なお、無効となったデータレコードは、デ
ータレコードヘッダ内に無効フラグを持たせることによ
って、フラッシュ管理マネージャ９は無効と判断でき
る。また、物理ブロックのデータファイル領域内でデー
タレコードがすべて無効となった場合、その物理ブロッ
クヘッダの無効フラグをＯＮにすることによって、この
物理ブロックをブロックイレースすることができる。ブ
ロックイレースが完了したときは、前述のブロックヘッ
ダの初期化を行なう。

【００５２】以上のようにしてシステムを運用すると、
その途中経過として、あるデータファイル内のセグメン
トの中で無効となるデータレコードが多くなり、新規に
割り当てるための物理ブロックが不足する可能性があ
る。このような場合、システムはデータを書き込むため
の領域を失い、システムとして破綻することがある。こ
のような不都合をなくすために、ファイル管理マネージ
ャ９はデフラグメンテーションを行なう必要がある。

【００５３】あるデータファイルのあるセグメントの中
で、無効なデータレコードが多くある場合、そのセグメ
ントを論理的なデータ構造から取り除くことが望まし
い。しかし、そのセグメント中には有効なデータレコー
ドも存在しているため、そのセグメントをもつ物理ブロ
ックを消去することはできない。そこで、その有効なデ
ータレコードを、そのデータファイル内の別のセグメン
トに移動させることになる。つまり、そのデータファイ
ルのもつ他の物理ブロックにそのデータレコードのコピ
ーを行ない、その後コピー元のセグメントのデータレコ
ードを無効にする。そして、データレコードを無効にし
たセグメントの物理ブロックを無効にしてブロックイレ
ースし、初期化する。このようなデフラグメンテーショ
ン処理によって効果の上がる場合は、その選定基準は−
元的なものではない。物理ブロックの容量，データレコ
ードのパケットサイズ，データファイルの容量，システ
ムのパフォーマンスなどを考慮して、システム全体が効
率的に処理を行なうことができるように、選定基準を選
ぶようにする。

【００５４】デフラグメンテーシヨンの具体例を図１０
に示す。図１０は、上述した図９のデータファイルＡか
ら、図１０［Ａ］に示すように、データレコード４，デ
ータレコード６，データレコード７が無効となった後の
様子を示している。無効となるデータレコード４，６，
７は、図１０［Ｂ］に示すように、データファイルＡの
セグメント１に含まれている。ここで、例えば、セグメ
ント１すなわち物理ブロック［２］を無効化するととも
に（同図［Ｃ］参照）、そのイレース・初期化を行った
方がよいと判断されたとする。この場合、有効なデータ
レコード［５］を例えばデータレコード［９］に移動さ
せれば、データファイルＡのセグメント１すなわち物理
ブロック［２］をブロックイレース・初期化することが
でき、後にデータを割り当てるブロックとして利用する
ことができる。

【００５５】このような処理の結果を示すと、図１１の
ようになる。同図［Ａ］に示すデータファイルＡの論理
的なデータイメージは、図１０［Ａ］に示したデータフ
ァイルＡの論理的なデータイメージとは配列が異なるよ
うになる。そして、同図［Ｂ］，［Ｃ］に示すように、
セグメント１は物理的に切り離され、そのブロックはイ
レース可能となってブロックイレース・初期化の処理を
行なうことで、その物理ブロックが未割当てフロックと
なる。このような処理を行うことで、新規のデータの追
加をより多く行うことができるようになる。

【００５６】このように、すべてのデータレコードを新
規に書き換えることなく、論理的なセグメントの情報変
更を行なうことで、すなわち物理ブロックの連鎖情報を
更新することによって、データの書き換えを最小限に抑
えることができる。これにより、フラッシュメモリの書
き換え回数を低減することができる。また、システムの
運用時間を延ばし、フラッシュメモリの書き換え寿命
（回数ではなく時間）を延ばすことも可能となる。

【００５７】また、連鎖情報の更新はブロックヘッダの
領域に追記されるため、結果的に過去の連鎖情報がある
程度保持されることになる。このため、故意・過失・事
故によって消失や破壊されたデータをある程度復元する
こともできる。これは、コンピュータシステムの異常に
よる停止からの復旧やデータの復元に有効である。な
お、フラッシュメモリによっては、ライト（書き込み）
操作中に他のオペレーションができないチップが存在す
る。このようなときは、タスク，スレッドのようなフロ
グラム技法により排他制御を行なうようにする。

【００５８】以下、本形態の実施例について説明する。
図１２には、フラッシュメモリに対する物理ブロックヘ
ッダの格納例が示されている。図１２［Ａ］の例は、６
４Ｋバイトを消去ブロック単位とするフラッシュメモリ
で、物理ブロック数がｎ＋１個あるシステムである。各
物理ブロックの先頭には、図１２［Ｂ］に示すように、
各物理ブロックの管理情報を格納するへッダ領域とし
て、２５６バイトが割り当てられている。具体的には、
図１３［Ａ］に示すように、ブロック消去が６４Ｋバイ
ト単位で可能な２Ｍ×８ビットのフラッシュメモリが使
用される。そして、同図に示すように、各物理ブロック
に「０」から「１Ｆ」と順に番号（１６進数）を付け
る。

【００５９】図１４には、ヘッダ領域の内容例が示され
ており、その１バイト目が図１５［Ｂ］に示されてい
る。これらの図に示すように、ヘッダ領域の１バイト目
には、有効／遷移中／無効，初期化完了状態，予約の各
フラグがある。これらのうち、有効／遷移中／無効のフ
ラグは、この物理ブロックが、有効状態か，それとも有
効から無効になる遷移中（過渡）の状態か，完全に無効
になった状態かを示す。初期化完了フラグは、ブロック
イレース後にブロックヘッダの初期化（フォーマット）
が完了したことを示す。予約のフラグあるいは２バイト
目の予約領域は、システムを拡張する場合に利用される
もので、本発明では特に意味はない。

【００６０】次に、物理ブロックの３バイト目から１４
バイト目までは、その物理ブロックに割り当てられてい
るデータファイル名を記録する。なお、データファイル
を特定できるコードや番号など、データファイルを識別
できるものであればよい。例えば、パーティション名や
ディレクトリ名を付随させたデータファイル名でもよ
い。あるいは、パーティション名やディレクトリ名自体
でもよい。つまり、データレコードの特性を活かした管
理の方法を選択すればよい。本実施例では、データファ
イル名として、８．３形式で、ＭＳ−ＤＯＳのような表
現方法を利用する。

【００６１】次に、１５バイト目，１６バイト目には、
その物理ブロックの後ブロックポインタの開始アドレス
が格納される。本例では、例えば「０ｘ００８８」を記
録する。次に、１７バイト目から１３８バイト目までは
前ブロックポインタ管理情報の格納領域で、１３９バイ
ト目から２５６バイト目までは後ブロックポインタ管理
情報の格納エリアとなる。前ブロックポインタは２バイ
ト構成で、有効／無効／未格納のいずれであるかを示す
フラグ，及び先頭／中間／最終のいずれのブロックであ
るかを示すフラグの管理情報と、ブロックポインタの番
号（１６進数）を格納する記憶領域からなる。後ブロッ
クポインタも同様に２バイト構成で、有効／無効／未格
納のいずれであるかを示すフラグ，及び先頭／中間／最
終のいずれのブロックであるかを示すフラグの管理情報
と、ブロックポインタの番号（１６進数）を格納する記
憶領域からなる。

【００６２】次に、図１５［Ｂ］を参照して、ブロック
イレースの手順を説明する。フラッシュ管理マネージャ
９の判定により、フラッシュメモリ２にブロックイレー
ス命令が出されたとき（ステップＳ１）、該当する物理
ブロックのブロックイレースが行われる（ステップＳ
２）。ブロックイレースを行なった直後、イレースされ
た物理フロックの記憶エリアのデータの値は、すべて
「ＦＦｈ」となっている。この後すぐに、フラッシュ管
理マネージャ９による初期化（フォーマット）操作によ
って（ステップＳ３）、ビット４が論理値の「０」とな
り、この記憶エリア（１バイト目）のデータの値は「Ｆ
Ｆｈ」から「ＥＦｈ」に遷移する。そして、新たにこの
物理ブロックへの使用要求によってフラッシュ管理マネ
ージャ９がデータの割当てを行なったとすると（ステッ
プＳ４）、ビット７に論理値の「０」を書き込む。これ
によって、この記憶エリアのデータの値は、「ＥＦｈ」
から「６Ｆｈ」に遷移する。更に、フラッシュ管理マネ
ージャ９がこの物理ブロックの無効要求を認めれば（ス
テップＳ５）、ビット６に論理値の「０」を書き込み、
この記憶エリアのデータの値は「６Ｆｈ」から「２Ｆ
ｈ」に遷移する。

【００６３】デフラグメンテーション操作により使用可
能領域の拡大を図る際、フラッシュ管理マネージャ９の
機能により、物理ブロックにはコピー元，コピー先，ム
ーブなどのような遷移中の状態が存在する。本形態では
特に、前後のブロックポインタの格納エリアがいっぱい
にならないように配慮しなければならないため、このよ
うな物理ブロックをコピーする手段では最適である。物
理ブロックを有効な状態から遷移中の状態にするには、
ビット５を論理値の「０」にし、この記憶エリアのデー
タの値を「６Ｆｈ」から「４Ｆｈ」に遷移させればよい
（ステップＳ４からＳ６）。このような遷移中の状態が
存在することは、遷移に要する時間が少ないことの他
に、電池の消耗に代表されるような電源異常による動作
の不安定や、カード型フラッシュメモリが外されたとき
などにおける安全性を高めるためである。このように遷
移段階の状態を管理することで、故障・事故などによる
データの消失が最小限に抑えられ、復旧させるための情
報が提供される。

【００６４】フラッシュメモリの消去回数を削減するた
めには、可能な限りデータファイルのセグメント内のデ
ータレコードを有効に活用し、データの中身の書き換え
を行なわない方がよい。すなわち、実際のデータの書き
換えを行なわず、論理データの変更を行い、セグメント
情報の更新を行なう方がよく、前ブロックポインタのス
テータス／そのブロックポインタのデータや、後ブロッ
クポインタのステータス／そのブロックボインタのデー
タを更新すればよい。そこで、この情報を追記すること
により、データの更新を行なう。

【００６５】ヘッダ領域の１バイト目の各フラグは図１
５［Ｂ］に示した通りであり、それらの実際上のビット
割付例を示すと、以下の表１［Ａ］のようになる。ブロ
ックホインタのステータス情報の内容は、例えば図１５
［Ｃ］に示すようになる。これに対応するブロックポイ
ンタのデータとして、指し示す物理ブロックの番号を記
録する。表１［Ｂ］，［Ｃ］，［Ｄ］は、ブロックポイ
ンタのステータス情報の内容のビット割り付け例を示し
ている。当初は、図１５［Ａ］に示したようにデータが
「ＦＦｈ」なので、それに対するブロックポインタは未
格納と判断する。表１［Ｂ］は、ビット７とビット６を
使用して、そのステータスとそれに対するデータの未格
納／有効／無効のフラグ情報を割り付ける場合を示す。
ビット７が論理値の「０」，ビット６が論理値の「１」
のとき、それに対するブロックポインタは有効と判断す
る。逆に、ビット７が「１」，ビット６が「０」又はビ
ット７が「０」，ビット６が「０」のとき、それに対す
るブロックポインタは無効と判断する。現実的には、ス
テータスは有効から無効になるので、ビット６が「０」
になれば無効と判断する。表１［Ｃ］は、ビット５，ビ
ット４を使用し、未格納／先頭／中間／最終のフラグ情
報を割り付けて、その物理ブロック（セグメント）の情
報を取得する場合を示す。表１［Ｄ］は、ビット１，ビ
ット０を使用し、未格納／前ブロックポインタ／無効ブ
ロックポインタ／後ブロックポインタを指し示す情報の
フラグを割りつける場合を示す。これらの情報により、
前後のブロックポインタのステータス情報の内容を読み
取ることができる。

【００６６】

【表１】

【００６７】図１６，図１７は、ブロックポインタのス
テータス情報の更新の様子を示している。図１６［Ａ］
は、初めて前ブロックポインタの情報を格納している様
子であり、図１６［Ｂ］は、図１６［Ａ］から更新前の
前ブロックポインタを無効にして新たな前ブロックポイ
ンタを更新したときの様子を示している。また、図１６
［Ｃ］は、図１６［Ｂ］から更新前の前ブロックポイン
タを無効にして新たな前ブロックポインタを更新したと
きの様子を示している。このように、前ブロックポイン
タ［０ｈ］が無効のときは［１ｈ］となり、［１ｈ］が
無効のときは［２ｈ］となるという具合に、可能な限り
更新情報を連鎖させていく。同様に、後ブロックポイン
タの更新の様子を図１７［Ａ］，図１７［Ｂ］、図１７
［Ｃ］にそれぞれ示す。このように、後ブロックポイン
タ［０ｈ］が無効のときは［１ｈ］となり、［１ｈ］が
無効のときは［２ｈ］となるという具合に、可能な限り
更新情報を連鎖させていく。ここで、ブロックポインタ
が無効であると判断するには、そのブロックポインタの
ステータス情報が無効かどうかを判定すればよい。

【００６８】以上のような構造の物理ブロックヘッダを
用いてフラッシュファイル管理システムを実現する。フ
ラッシュ管理マネージャ９はＯＳやアプリケーションプ
ログラム等の要求により、データファイルのなどの読み
出し，書き込みを制御する。まず、書き込みに際して
は、フラッシュメモリ２の特徴として書き込み遅延の影
響がある。このため、オーバヘッドを少なくし、効率的
に書き込みを行なうためには、データレコードをデータ
ファイル内に追記していく方式を取ることになる。この
方式を実行するためには、書き換え前の旧データレコー
ドと書き換え後のデータレコードが論理的には変更され
ているが、物理的には旧データレコードが無効となり、
新データレコードがそのデータファイルに追記されるこ
とになる。つまり、物理的には無効とされた旧データレ
コードと新データレコードがデータファイル内に共に存
在するものの、旧データレコードに無効フラグを記すこ
とによって論理的に削除することになる。

【００６９】このような操作をフラッシュファイルシス
テム上で繰り返すと、データファイル内に論理的な無効
データレコードが多数存在することになる。場合によっ
ては、新規の未割当てのデータファイル領域がなくなる
危険性すらある。このことを避けるために、フラッシュ
管理マネージャ９は、データの無効化を定期的に検知し
てデフラグメンテーションの操作を行ない、効率よく未
割当てのデータファイル領域を拡大し、確保する。

【００７０】データファイル領域としての物理ブロック
の割当ては、フラッシュ管理マネージャ９が行なう。こ
のとき、ＯＳやアプリケーションプログラムの要求によ
ってデータファイル領域を与えることになる。本実施例
では、図５に示したように、論理的なデータファイル内
のデータレコードＤＲに、データレコードヘッダＤＲＨ
とデータレコードフッダＤＲＦを付加して物理的なデー
タファイルを構成するとともに、それをスパンドレコー
ドとしてセグメント化し、データを格納する。すなわ
ち、論理的なデータファイルにデータレコードＤＲを追
加するとき、その追加されたデータレコードＤＲにデー
タレコードヘッダＤＲＨとデータレコードフッダＤＲＦ
を付加し、そのパケットＤＲＰを物理的なデータファイ
ルとしてその後に追記していく。そして、同様にセグメ
ント化してデータを格納する。データレコードを追加し
ていくときは、以上の操作を繰り返す。

【００７１】また、データファイル内のデータレコード
ＤＲを削除するときは、データレコードＤＲを削除する
ことをフラッシュ管理マネージャ９に知らせ、データレ
コードのパケットＤＲＰを無効化する。このときの無効
化は、データレコードヘッダＤＲＨあるいはフッダＤＲ
Ｆにマーキングすることで行われる。これによって、デ
ータレコードＤＲは論理的に削除することができるが、
物理的に削除することにはならない。物理的に削除する
ためには、物理ブロック内のデータファイル領域に格納
されているデータがすべて無効のときにのみに可能であ
る。そして、この無効後にブロックイレースと初期化を
行なえばよい。しかし、フラッシュ管理マネージャ９
が、データファイル内のセグメントですべて無効なデー
タレコードになるまで待つことは、システムの停止を招
くことになる。このようにならないためには、上述のデ
フラグメンテーションの操作を実行すべきである。ただ
し、デフラグメンテーションの操作の実行やそのアルゴ
リスムは、データレコードの構造に密接に関係するの
で、その最適な方法を見出す必要がある。

【００７２】次に、図１８〜図２２を参照して、以上の
ようなデフラグメンテーションの−例を説明する。論理
的なデータファイルの各データレコードＤＲにデータレ
コードヘッダＤＲＨ及びフッダＤＲＦを付加して物理的
なデータファイルを構成し、そのデータをスパンドレコ
ードとして取り扱う。そして、６４Ｋ−２５６バイト毎
にセグメント化し、そのセグメント化したデータを物理
ブロックのデータファイル領域に格納する。図１８に
は、この物理的なデータファイルをセグメント化した様
子が示されている。セグメント化したデータブロックを
識別するために、各ブロックに「Ａ」から「Ｉ」までの
呼称を順につける。これらのセグメントＡ〜Ｉを、フラ
ッシュメモリ２の物理ブロックに１対１で割り当てる。

【００７３】例えば、この割当ての１例として、セグメ
ントと物理ブロックの対比が以下の表２［Ａ］の通りな
らば、物理ブロックとセグメントの関係は図１９［Ａ］
のようになる。この例は、あくまで、物理ブロック０か
ら物理ブロック８の間にセグメントを割り当てただけで
あり、物理ブロックの割当てに当たってセグメントの連
続編成を行う必要はない。また、当然のことながら、物
理ブロック０から物理ブロック８以外の使用可能な物理
フロックを割り当てることもできる。つまり、フラッシ
ュメモリ２の物理ブロック中から未使用の物理ブロック
を任意に割り当てることができる。

【００７４】

【表２】

【００７５】図１９［Ａ］の例は、その物理ブロックの
中におけるセグメントの前後関係を、前ブロックポイン
タや後ブロックポインタなどで、情報の−部としてブロ
ックヘッダに記憶している例である。フラッシュ管理マ
ネージャ９は、このブロックヘッダを読み取り、セグメ
ントがバラバラに配置されている状態においても、デー
タファイルのセグメントを繋ぎ合わせて、論理的なデー
タファイルを構築することができる。また、前後のブロ
ックポインタを変更することにより、各物理ブロックの
連鎖構造を論理的に変更することができる。これによっ
て、フラッシュメモリ２の大幅な書き換え操作を削減す
ることができる。

【００７６】次に、システムの初期段階に多く見られる
ようなデータファイルの物理的な格納例を示す。この例
は、後で述べるデータの修正・変更・追加を具体的に明
示できるようになる。前記表２［Ｂ］のようにデータフ
ァイルの各セグメントをそれぞれ物理ブロックに割り当
て、セグメントＡ〜Ｉに対して順に物理ブロック０〜８
までを割り振ったとすると、各セグメントと各物理ブロ
ック，フロックヘッダ内の有効な前ブロックポインタや
有効な後ブロックポインタなどは、図１９［Ｂ］のよう
になる。

【００７７】このように、物理ブロックのブロックヘッ
ダ内の前ブロックポインタや後ブロックポインタの内容
によって物理的なデータファイルのセグメントへのデー
タ変換の構造になるため、フラッシュ管理マネージャ９
はブロックヘッダの内容を解析し、鎖構造を作る必要が
ある。また、フラッシュ管理マネージャ９は、物理的な
データファイルのデータをセグメントに分割し、物理ブ
ロックに割り当てを行なう。つまり、フラッシュ管理マ
ネージャ９は、該当する物理的なデータファイル内の各
セグメントを持つ各物理ブロックのブロックヘッダの情
報から、まず、前ブロックポインタが「ＨＥＡＤ」とな
る物理ブロックを検索する。その後、その前ブロックポ
インタが「ＨＥＡＤ」となっている物理ブロックの後ブ
ロックポインタを参照し、それに示されている物理ブロ
ックにおけるブロックヘッダの前ブロックポインタを検
索する。ここで、後ブロックポインタに示された値と、
そのポインタを示すブロックの前ブロックポインタが−
致しない場合は、ブロック構造関係の矛盾となり、その
データファイルは破壊されていることになる。このた
め、前ブロックポインタや後ブロックポインタの管理は
重要となる。

【００７８】フラッシュ管理マネージャ９は、物理的な
データファイル内の各セグメントの物理ブロックでブロ
ックヘッダ内の前ブロックポインタとして「ＨＥＡＤ」
を持っているブロックを検索し、その後ブロックポイン
タに示されている物理ブロックのブロックヘッダの情報
をもとにチェインしていく。そして、最後に後ブロック
ポインタに「ＴＡＩＬ」となっているところで、このチ
ェインは終了し、１つの物理的なデータファイルのデー
タとして完結する。

【００７９】次に、セグメントの削除について説明す
る。フラッシュメモリの特性により、ＲＡＭのように簡
単にデータの修正・変更はできない。そこで、セグメン
トの削除は、１つの物理ブロックのデータファイル領域
単位で行うことにする。システムの物理的なデータファ
イル内においてセグメント単位での削除を矛盾なく行な
うということを前提にして、次のような例を想定する。
図１８［Ａ］において、セグメントＥを削除する場合に
は、図２０［Ａ］に示すように、セグメントＥを論理上
から削除し、セグメントＤの後がセグメントＦとなるよ
うににする。なお、図２０中において、変更箇所には矢
印が付されている（図２１も同様）。

【００８０】データ構造としては図２０［Ａ］で示す通
りの構造であるが、これが物理ブロックでは、図１９
［Ｂ］に示す構造から図２０［Ｂ］に示す構造に変更す
る。この構造変更は、物理ブロックＥを削除することで
あるが、この削除の方法は、物理ブロックＥのブロック
ヘッダに削除のマーキングをすることによって行う。こ
れにより、高速に削除を行うことができるとともに、物
理的なデータファイルのセグメントと物理ブロックのデ
ータ構造の整合性を保つことができる。その後、物理ブ
ロック４を初期化（ブロックイレース後ブロックヘッダ
に必要情報を格納する）すればよい。

【００８１】次に、物理的なデータファイルにおけるセ
グメントの削除とセグメントの新規追加の例を説明す
る。図２０［Ａ］の物理的なデータファイルのデータ構
造において、セグメントＣを削除し、その後、新たにセ
グメントＫを追記する場合の操作を、図２１［Ａ］を用
いて説明する。まず、最初に図２０［Ａ］の状態から、
セグメントＣの削除を行なう。次にその状態から、変更
前の最後のセグメントＩの後にセグメントＫを追加す
る。これにより、変更後の最終セグメントはセグメント
Ｋとなる。

【００８２】この−連の操作を順に詳述すると、まず最
初に、フラッシュ管理マネージャ９は、物理ブロック４
が無効になっていることを検知し、この物理ブロック４
のブロックイレースと初期化を行なう。この初期化と
は、簡単に言うと物理ブロックのブロックイレースとそ
の物理ブロックのもつ情報をブロックヘッダへ書き込む
ことである。これらのシーケンスを物理ブロックに置き
換えて示すと、図２１［Ｂ］の通りである。同図のよう
に、最初に、物理ブロック４のブロックイレースとその
物理ブロックの情報を更新し、新たにその内容をその物
理ブロックのブロックヘッダに書き込む。

【００８３】次に、セグメントＣを削除するために、物
理ブロック２のブロックヘッダに削除のマーキングを行
なう。更に、各物理ブロックのチェイン構造に従って、
前ブロックポインタや後ブロックポインタ等のブロック
ヘッダの内容をそれぞれ書き換える。そして、フラッシ
ュ管理マネージャ９がセグメントＫを物理ブロック４に
割り当てたとすると、ブロック８とブロック４のそれぞ
れの前ブロックポインタや後ブロックポインタなどのブ
ロックヘッダの情報を対応して書き換える。そして新た
に、物理ブロック４にセグメントＫのデータの内容を書
き込む。これによって得られた物理ブロック構造は、図
２１［Ｂ］のようになる。

【００８４】このような削除・消去の操作によってセグ
メントの構造を変化させていくと、物理ブロックでは、
実際の前後の物理ブロック間でのチェイン構造はほとん
どなくなるが、論理的なデータ構造自体はブロックヘッ
ダによってフラッシュ管理マネージャ９により管理で
き、データレコードヘッダ，データレコードフッダをデ
フロッキングすれば、アプリケーションプログラムから
はフラッシュ管理マネージャを通して論理的なデータレ
コードとして認識可能である。図１８のセグメント構造
が、ブロック０から順に、Ｄ、Ｅ、Ａ、Ｃ、Ｂ、Ｉ、
Ｈ、Ｇ、Ｆとなっているときは、図２２［Ａ］のような
ブロックヘッダの内容になる。図１８のセグメント構造
が、ブロック０から順に、Ｇ、Ａ、Ｉ、Ｂ、Ｃ、Ｆ、
Ｅ、Ｈ、Ｄとなっているときは、図２２［Ｂ］のような
ブロックヘッダの内容になる。

【００８５】以上のように、物理的なデータファイル構
造は、（６４Ｋ−２５６）バイトのセグメント単位で分
割され、各物理ブロックに格納されていく。つまり、先
頭のブロックヘッダの前ブロックポインタ部分にあるＨ
ＥＡＤマーカと、後ブロックポインタを検索することに
より、物理ブロックのチェイン構造が順次検出されて、
１つのデータファイルが構成されていく。−連のデータ
ファイルは、後ポインタがＴＡＩＬマーカのときに終わ
りとなる。このＴＡＩＬマーカを書き換えて、次の物理
ブロックを後ブロックポインタで指定すれば追記可能で
あり、チェイン構造はどんどん膨らんでいく。

【００８６】ＯＳやアプリケーションからの要求によ
り、フラッシュ管理マネージャ９は、データファイルに
対してデータの書き込みや読み出しの操作を行なうこと
になる。読み出しの場合は、フラッシュ管理マネージャ
９にはフラッシュメモリ２の読み出しを行なう旨が要求
される。許可確認後、物理的なデータファイル内のデー
タレコードパケットがデブロッキングされ、論理的なデ
ータレコードとして扱われるようになる。また、書き込
みの場合、フラッシュ管理マネージャ９にはフラッシュ
メモリ２への書き込みを行なう旨が要求される。許可確
認後、論理的なデータレコードがパケット化され、後段
のセグメントにデータレコードパケットとして追記され
る。データの書き換えは、物理的にデータレコードパケ
ットを無効化し、新たに追記することによって実現され
る。ただし、物理的にメモリエリアは縮小する。この場
合のデータのブロッキング方法は、従来技術により実現
されている。

【００８７】物理ブロックのデータファイル領域内です
べてのデータが無効化された場合、その物理ブロックヘ
ッダの無効フラグをＯＮにすることによって物理ブロッ
ク全体が無効化される。フラッシュ管理マネージャ９は
このことを検知し、その物理ブロックをイレースして初
期化操作を始める。また、デフラグメンテーション操作
により、コピー元のデータファイルが属する物理ブロッ
クヘッダの遷移中フラグをＯＮにする。そして、必要な
データが全部コピーされたなら、その物理ブロックヘッ
ダの無効フラグがＯＮにされ、前述のブロックイレース
・初期化操作が行なわれる。更に、遷移中フラグＯＮか
ら無効フラグＯＮに至るまでの間に何らかの原因によっ
て異常な状態が発生することがある。そこで、システム
が再起動したときなど、それらの状態フラグがフラッシ
ュ管理マネージャ９で監視される。そして、状態を解析
することによって、いずれの状態から停止あるいは異常
となったかが検出され、システムを修復・復旧させる手
助けのための貴重な情報源となる。

【００８８】フラッシュ管理マネージャ９は、それぞれ
の物理ブロックの状態を監視し、管理していく。そし
て、ＯＳやアプリケーションプログラムの要求に応じて
該当する物理ブロックを割り当て、有効−＞（遷移中）
−＞無効−＞初期化の状態の監視，管理，実行を行な
う。フラッシュファイルシステムを運用していく中で、
各々物理ブロックの状態の変化としては、初期化−＞有
効，有効−＞無効，有効−＞遷移中，遷移中−＞無効，
無効−＞初期化，初期化−＞無効などが挙げられる。

【００８９】［初期化−＞有効］：物理ブロックが、初
期化状態からデータファイル領域等として割り当てら
れ、有効フラグがＯＮになった状態で有効となる。

【００９０】［有効−＞無効］：データファイルとして
の物理ブロックが有効で、データ領域内に少なくとも−
つは論理的に有効なデータがある状態から、データ領域
内のすべてが論理的に無効なデータとなったとき、フラ
ッシュ管理マネージャは、その後この物理ブロックの無
効フラグをＯＮとし、物理ブロックの無効化を行なう。

【００９１】［有効−＞遷移中］：少なくとも−つは存
在する論理的に有効なデータレコードパケットを異なる
物理ブロックのデータ領域にコピーするとき、コピー元
となる物理ブロックに対して遷移中フラグをＯＮにす
る。この状態のとき、データレコードパケットがコピー
されていることになる。

【００９２】［遷移中−＞無効］：前述の遷移中の状態
が終了し、物理ブロックが無効となったことを示す。つ
まり、データレコードパケットのコピーが完了し、フラ
ッシュ管理マネージャが無効フラグをＯＮにした状態で
ある。

【００９３】［無効−＞初期化］：物理ブロックを無効
な状態からブロックイレースし、物理ブロックヘッダの
初期化が完了したとき、フラッシュ管理マネージャは初
期化フラグをＯＮにする。このとき、物理ブロックヘッ
ダの初期化が完了し、データファイル領域として使用可
能な状態となる。

【００９４】［初期化−＞無効］：物理ブロックが初期
化された状態から無効になった状態を示す。これは、状
態として存在する可能性はあるが、システムとしては多
用すべきではない。

【００９５】フラッシュ管理マネージャは、各物理ブロ
ックの状態を管理・監視し、何らかの原因による異常状
態からの脱却後、有効／無効／遷移中／初期化フラグ
を、異常状態以前のデータの復元，復旧のための情報と
して利用する。つまり、これらの変化状態を考慮すれ
ば、システムの停止，異常により、システムの修復やデ
ータレコードパケットの復元を行なうとき、どの状態か
ら異常になったかを検出できる。また、当然、ブロック
ヘッダ内にシステム停止状態の直前のセグメントの連鎖
情報が残っているため、ある程度デ−夕を修復すること
も可能である。

【００９６】この発明には数多くの実施形態があり、以
上の開示に基づいて多様に改変することが可能である。
例えは、次のようなものが含まれる。 （１）前記実施例では、そのブロックポインタのステー
タス情報が最初の格納エリアから順に有効かどうかで、
ブロックポインタが無効であるかどうかを判断してい
る。しかし、その代わりに、ブロックポインタ（ブロッ
クポインタのステータスとブロックポインタのデータの
値）の最終格納エリアから最初の格納エリアに向かって
検索し、その値が「ＦＦＦＦｈ」でないところが最新の
情報データと判定するようにしてもよい。

【００９７】（２）更に、前記（１）の方法と、前記実
施例の方法を組み合わせてもよい。すなわち、通常は前
記実施例のようにブロックポインタが無効であると判断
し、データの後旧・復元を行なう際は、前記（１）のよ
うにブロックポインタが無効であると判断するように切
り替える。また、その逆に、データの後旧・復元を行な
う際は、前記実施例のようにブロックポインタが無効で
あると判断し、通常は前記（１）のようにブロックポイ
ンタが無効であると判断するように切り替える。

【００９８】（３）前記実施例のように、同一ブロック
にその管理情報を持たせるという方法ではなく、同一フ
ラッシュメモリ上に管理情報のための領域を別ブロック
に作成し、そこに、それぞれのブロックの管理情報を持
たせても、本発明は同様に適用可能である。

【００９９】（４）前記（１），（２）では、図２３に
示す通り、ブロックに対してそのブロック内にそのブロ
ックに対する管理情報を持っている。しかし、前記
（３）では、例えば請求項２，３，４，５，６，７又は
８での管理装置にある管理情報をブロック管理情報の体
系から種別管理の体系に変更させる。つまり、種別ごと
に集中管理情報を持たせる。例えば、集中管理情報
（１）として、請求項２の各ブロックの情報を持たせ
る。同様に、集中管理情報（ｍ）には請求項６に記載さ
れているような各ブロックの情報を持たせる。この集中
管理情報は、同一フラッシュメモリ上の別ブロックに格
納させる。このとき、イレース単位のブロックごとに集
中管理情報をそれぞれ格納してもよい。当然、同一ブロ
ックに格納してもかまわない。このように、それぞれブ
ロックの管理情報を個々（同種ごと）に集結させ、同一
のフラッシュメモリ上の別ブロックに持たせても同様に
適用可能である。

【０１００】（５）前記（１）〜（４）において、物理
ブロックの前セグメントを示す情報あるいは物理ブロッ
クの後セグメントを示す情報のどちらか一方あれば、同
様に適用可能である。ただし、この場合、管理の簡略化
と多少の高速性を得るが、反面、二重管理を行わないた
め、システムの安全性は低下することになる。 （６）また、前記例で、管理情報の一部をフラッシュメ
モリ上ではなく、ＲＡＭ領域に配置しても同様に適用可
能である。また、一部の管理情報を固定させても適用可
能である。例えば、先頭ブロックの管理情報は常に固定
させる。中間セグメントの管理情報はＲＡＭ上に持たせ
る。 （７）前記（１）〜（６）まではフラッシュメモリを１
個使用した例であるが、フラッシュメモリが複数個あっ
ても、本発明の管理形態は同様に適用可能である。

【０１０１】（８）前記形態は、フラッシュメモリに本
発明を適用したものであるが、他の類似するメモリがフ
ラッシュメモリと同じ書き込み，読み出し機能を備えて
おり、かつ、書き込み前にブロックの消去特性を有する
メモリであれば、同様に適用可能である。 （９）フラッシュメモリのイレース単位である物理ブロ
ックは、バイト単位やワード単位など、どのようなデー
タ単位であっても、同様に適用可能である。

【０１０２】

【発明の効果】以上説明したように本発明によれは、次
のような効果がある。 （１）フラッシュ型メモリを使用した補助記憶装置上で
フラッシュメモリの消去回数を低減するような制御構造
をもつため、無駄のないデータ構造で記憶を行なうこと
が可能である。 （２）データの書き換え回数を低減することにより、コ
ンピュータシステムの高速化を図ることができる。

【０１０３】（３）各ブロックの管理情報テーブルのた
めのエリアをそのブロック内に持つこととしたので、別
メモリを新たに必要とせず、コストの削減が可能とな
る。従って、システムとして省スペース・コスト削減を
図ることができる。 （４）物理ブロックの有効／遷移中／無効／初期化とい
った状態フラグや故障以前のブロックの連鎖情報の履歴
の情報源を持つこととしたので、コンピュータシステム
の異常による停止に代表されるような故障原因から、コ
ンピュータシステムの復旧やデータの復元を行なう際に
有効である。

【０１０４】（５）データファイルのスパンドレコード
の第一セグメントが格納されていることを示す先頭ブロ
ックの情報を備えたことにより、データファイル構造を
論理的に構成させるとき、データファイルの先頭を高速
にサーチさせるのに有効である。 （６）データファイルのスパンドレコードの最終セグメ
ントが格納されていることを示す最終ブロックの情報を
備えたことにより、新たにデータファイルへのセグメン
トの追加を行う際に有効である。

【０１０５】（７）データファイルのスパンドレコード
の中間セグメントが格納されていることを示す中間ブロ
ックの情報を備えたことにより、前後の連鎖があること
を示し、フラッシュメモリ内の状態の管理を行う際に有
効である。これは、前記（２），（４）の効果を得るた
めには必要である。 （８）物理ブロックの前のセグメントが格納されている
ことを示す物理ブロック情報を備えたことにより、デー
タファイル構造を論理的に構成させ、連鎖情報により、
デフラグメンテーション等のデータファイルの再構築や
データの書き換え回数を低減させるための情報として有
効である。

【０１０６】（９）物理ブロックの後のセグメントが格
納されていることを示す物理ブロック情報を備えたこと
により、データファイル構造を論理的に構成させ、連鎖
情報により、デフラグメンテーション等のデータファイ
ルの再構築やデータの書き換え回数を低減させるための
情報として有効である。 （１０）物理ブロック内の個々の管理情報が個々に有効
か無効かを示す情報を含ませたことにより、最新の連鎖
構造の実現と旧連鎖構造の復元を行う際に有効である。

【０１０７】（１１）物理ブロック内の個々の管理情報
が無効になったとき、更新される新管理情報を含むこと
により、データファイルの書き換え回数を低減させ、論
理的にデータファイル内のセグメントの組み替えを可能
とするだけでなく、本来、データの書き込みにかかる時
間を削減できる。つまり、システムの高速性と書き換え
回数の低減を図る際に有効である。

【図面の簡単な説明】

【図１】この発明の−形態を利用したシステムの基本構
成を示す図である。

【図２】前記形態におけるソフトウェア構造を示す図で
ある。

【図３】前記形態において、フラッシュメモリ内での物
理ブロックの割付を行なったメモリマップを示す概念図
である。

【図４】物理的なデータファイルをセグメント化し、物
理ブロックに格納する様子を示した図である。

【図５】論理的なデータファイルをデータファイル領域
内のデータレコードとしてパケット化する様子を示す図
である。

【図６】前記ケット化されたデータ構造を物理ブロック
に格納した様子を示す図である。

【図７】物理ブロック内のブロックヘッダの情報とセグ
メントのデータを割り付けた格納例を示す図である。

【図８】本発明の一形態におけるデータファイルと物理
ブロックの相関関係の例を示す図である。

【図９】本発明の一形態における物理ブロックイメージ
と論理的なデータファイルのイメージとデータレコード
をパケット化し結合したデータをセグメント化する様子
を表す図である。

【図１０】前記図９に示した状態からデータレコードが
削除されたときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化して結合したデータをセグメント化する様子を表す図
である。

【図１１】前記図１０に示した状態からデータレコード
を移動したときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化し結合したデータをセグメント化する様子を表す図で
ある。

【図１２】ブロックイレースが６４Ｋバイト単位のフラ
ッシュメモリを、物理ブロック単位に分割して２５６バ
イトのブロックヘッダを確保した例を示す図である。

【図１３】前記実施例で使用しているフラッシュメモリ
をデータファイル領域に分割したメモリマップの例を示
す図である。

【図１４】前記実施例で使用している物理ブロックヘッ
ダのメモリマップの例を示す図である。

【図１５】前記実施例における物理ブロックヘッダの一
部とシーケンスを表す図である。

【図１６】前記実施例における前ブロックポインタの更
新の様子を表す図である。

【図１７】前記実施例における後ブロックポインタの更
新の様子を表す図である。

【図１８】前記実施例における物理的なデータファイル
をセグメント化した様子を示す図である。

【図１９】前記セグメント化したデータファイルを、物
理ブロックに割り当てた例を示す図である。

【図２０】データファイルセグメントの物理ブロックに
対する割り当て例と、セグメントの削除の様子を示す図
である。

【図２１】データファイルセグメントの物理ブロックに
対する割り当て例と、セグメントの削除・追加・移動の
様子を示す図である。

【図２２】前記例におけるセグメントの削除・追加・移
動の様子の例を表す図である。

【図２３】管理情報格納の他の例を示す図である。

【符号の説明】

１…プロセッサ ２…フラッシュメモリ ３…フラッシュメモリ制御装置 ４…拡張記憶装置もしくは補助記憶装置 ５…ランダムアクセスメモリ ６…オペレーティングシステム ７…アプリケーションソフト ８…ドライバ層 ９…フラッシュ管理マネージャ ＢＬＡ，ＢＬＢ…物理ブロック ＤＡ，ＤＢ…データファイル領域 ＤＲ…データレコード ＤＲＦ…データレコードフッタ ＤＲＨ…データレコードヘッダ ＤＲＰ…データレコードパケット ＨＡ，ＨＢ…ヘッダ領域

Claims (11)

【特許請求の範囲】
1. 【請求項１】 ブロック単位で記憶内容を消去できるフ
   ラッシュ型メモリのイレース単位である物理ブロック
   に、その物理ブロックにおけるデータファイルのスパン
   ドレコードを管理する管理情報を記憶するへッダ領域
   と、データファイルをスパンドレコードとして取り扱っ
   たブロック単位に分割されたデータセグメントを格納す
   る記憶領域とを備えたことを特徴とするフラッシュ型メ
   モリ。
2. 【請求項２】 データファイルのスパンドレコードの第
   １セグメントが格納されていることを示す先頭ブロック
   の情報を備えたことを特徴とするフラッシュ型メモリの
   管理装置。
3. 【請求項３】 データファイルのスパンドレコードの最
   終セグメントが格納されていることを示す最終ブロック
   の情報を備えたことを特徴とするフラッシュ型メモリの
   管理装置。
4. 【請求項４】 データファイルのスパンドレコ−ドの中
   間セグメントが格納されていることを示す中間ブロック
   の情報を備えたことを特徴とするフラッシュ型メモリの
   管理装置。
5. 【請求項５】 物理ブロックのセグメントの前のセグメ
   ントが格納されている物理ブロックを示す情報を備えた
   ことを特徴とするフラッシュ型メモリの管理装置。
6. 【請求項６】 その物理ブロックのセグメントの後のセ
   グメントが格納されている物理ブロックを示す情報を備
   えたことを特徴とするフラッシュ型メモリの管理装置。
7. 【請求項７】 前記物理ブロック内の個々の情報が個々
   に有効か無効かを示す情報を含むことを特徴とする請求
   項２，３，４，５，又は６のいずれかに記載のフラッシ
   ュ型メモリの管理装置。
8. 【請求項８】 前記物理ブロック内の個々の管理情報が
   無効になったときに更新される新管理情報を含むことを
   特徴とする請求項２，３，４，５，６，又は７のいずれ
   かに記載のフラッシュ型メモリの管理装置。
9. 【請求項９】 ブロック単位に分割されたデータファイ
   ルのスパンドレコードの各セグメントを、それぞれ物理
   ブロックに割り当てるとともに、各物理ブロックの管理
   情報を、該当する物理ブロックにそれぞれ格納する手段
   を備えたことを特徴とする請求項１記載のフラッシュ型
   メモリの管理装置。
10. 【請求項１０】 システムの復旧やデータの復元を行な
    う手段を備えたことを特徴とする請求項９記載のフラッ
    シュ型メモリの管理装置。
11. 【請求項１１】 各物理ブロックに格納されているデー
    タの書き換え回数を低減する手段を備えたことを特徴と
    する請求項９又は１０に記載のフラッシュ型メモリの管
    理装置。