JPH11272537A - フラッシュ型メモリ及びその管理装置 - Google Patents
フラッシュ型メモリ及びその管理装置Info
- Publication number
- JPH11272537A JPH11272537A JP10092566A JP9256698A JPH11272537A JP H11272537 A JPH11272537 A JP H11272537A JP 10092566 A JP10092566 A JP 10092566A JP 9256698 A JP9256698 A JP 9256698A JP H11272537 A JPH11272537 A JP H11272537A
- Authority
- JP
- Japan
- Prior art keywords
- block
- data
- physical block
- information
- segment
- 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
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】
【課題】ブロック消去方式のフラシュ型メモリを使用す
る際に、消去回数の制限を補う効率的なメモリ管理を行
う。 【解決手段】 管理制御情報を物理ブロックのへッダ領
域に記憶し、データファイルをセグメント化したデータ
を、物理ブロックX,XX,XYのデータファイル領域
に割り当て、その連鎖情報もヘッダ領域に格納する。デ
ータファイルを読み出すときは、有効な前ブロックポイ
ンタの中から先頭であるブロックXを検索するととも
に、その後、その先頭物理ブロックに格納されている後
ブロックポインタの示す物理ブロックXYを検索する。
この操作を、後ブロックポインタが最終となる物理ブロ
ックXXまで繰り返すことで、連鎖的にファイル読み出
しが行われる。データセグメントのデータの削除・移動
は、ヘッダ情報の更新によって行われる。
る際に、消去回数の制限を補う効率的なメモリ管理を行
う。 【解決手段】 管理制御情報を物理ブロックのへッダ領
域に記憶し、データファイルをセグメント化したデータ
を、物理ブロックX,XX,XYのデータファイル領域
に割り当て、その連鎖情報もヘッダ領域に格納する。デ
ータファイルを読み出すときは、有効な前ブロックポイ
ンタの中から先頭であるブロックXを検索するととも
に、その後、その先頭物理ブロックに格納されている後
ブロックポインタの示す物理ブロックXYを検索する。
この操作を、後ブロックポインタが最終となる物理ブロ
ックXXまで繰り返すことで、連鎖的にファイル読み出
しが行われる。データセグメントのデータの削除・移動
は、ヘッダ情報の更新によって行われる。
Description
【0001】
【産業上の利用分野】本発明は、フラッシュ型メモリ及
びその管理装置にかかり、更に具体的には、フラッシュ
型メモリの効率的な管理手法の改良に関するものであ
る。
びその管理装置にかかり、更に具体的には、フラッシュ
型メモリの効率的な管理手法の改良に関するものであ
る。
【0002】
【従来の技術と発明が解決しようとする課題】フラッシ
ュタイプのフローティングケートトランジスタを含む電
気的消去可能なプログラマブル読み出し専用メモリ(E
EPROM),いわゆるフラッシュメモリは、各方面で
実用化されて広く普及しており、市場で容易に入手可能
である。これらフラッシュメモリは、機能・性能面でE
PROMメモリと類似した不揮発メモリであり、メモリ
内で分割されているブロックを消去する回路内プログラ
マプル動作を可能にするという機能を更に有する。
ュタイプのフローティングケートトランジスタを含む電
気的消去可能なプログラマブル読み出し専用メモリ(E
EPROM),いわゆるフラッシュメモリは、各方面で
実用化されて広く普及しており、市場で容易に入手可能
である。これらフラッシュメモリは、機能・性能面でE
PROMメモリと類似した不揮発メモリであり、メモリ
内で分割されているブロックを消去する回路内プログラ
マプル動作を可能にするという機能を更に有する。
【0003】フラッシュメモリでは、以前に書き込まれ
たメモリの領域を前もってブロック単位で消去すること
で、その書換えが行なわれる。典型的なコンピュータシ
ステムでは、オペレーティングシステム(以下「OS」
という)プログラムがそのシステムのデータ記憶装置の
デ−タ管理を担う。OSプログラムとの互換性を達成す
るために必要かつ十分なデータ記憶装置のアトリビュー
ト(属性)は、データ記憶媒体の如何なる位置からもデ
ータを読み出すことができ、またその位置にデータを書
き込むことができることである。しかし、フラッシュメ
モリの場合、データが既に書き込まれている領域には、
その領域に書き込まれているデータを消去しなければ、
新たにデータを書き込むことができない。このため、フ
ラッシュメモリは、典型的な既存のOSプログラムとは
互換性がない。
たメモリの領域を前もってブロック単位で消去すること
で、その書換えが行なわれる。典型的なコンピュータシ
ステムでは、オペレーティングシステム(以下「OS」
という)プログラムがそのシステムのデータ記憶装置の
デ−タ管理を担う。OSプログラムとの互換性を達成す
るために必要かつ十分なデータ記憶装置のアトリビュー
ト(属性)は、データ記憶媒体の如何なる位置からもデ
ータを読み出すことができ、またその位置にデータを書
き込むことができることである。しかし、フラッシュメ
モリの場合、データが既に書き込まれている領域には、
その領域に書き込まれているデータを消去しなければ、
新たにデータを書き込むことができない。このため、フ
ラッシュメモリは、典型的な既存のOSプログラムとは
互換性がない。
【0004】このような点に着目し、既存のコンピュー
タオペレーティングプログラムによってフラッシュメモ
リを管理することを可能にするソフトウェアが、例えば
特開平5−173871号公報,特開平6−95955
号公報,特表平8−510072号公報に開示されてい
る。しかしながら、これらの先行技術は、フラッシュメ
モリを「書き込み1回・読み出し複数回」の装置として
動作させるか、「書き込み複数回・読み出し複数回」の
装置として動作させている。これらのうち、前者は、以
前に書き込まれているメモリ場所を再利用することはで
きない装置であり、補助記憶装置や拡張記憶装置として
使用するものである。後者は、以前に書き込まれている
メモリの場所を再利用可能とし、その中にはフラッシュ
メモリの書き換え回数を少なくするような制御を持つ補
助記憶装置(半導体ファイル記憶装置)がある。
タオペレーティングプログラムによってフラッシュメモ
リを管理することを可能にするソフトウェアが、例えば
特開平5−173871号公報,特開平6−95955
号公報,特表平8−510072号公報に開示されてい
る。しかしながら、これらの先行技術は、フラッシュメ
モリを「書き込み1回・読み出し複数回」の装置として
動作させるか、「書き込み複数回・読み出し複数回」の
装置として動作させている。これらのうち、前者は、以
前に書き込まれているメモリ場所を再利用することはで
きない装置であり、補助記憶装置や拡張記憶装置として
使用するものである。後者は、以前に書き込まれている
メモリの場所を再利用可能とし、その中にはフラッシュ
メモリの書き換え回数を少なくするような制御を持つ補
助記憶装置(半導体ファイル記憶装置)がある。
【0005】このような先行技術に対し、特願平9−3
17612号として出願されたフラッシュメモリがあ
る。これによれば、フラッシュメモリを使用した拡張記
憶装置上では、書き換え回数を少なくなるような制御構
造を持たずに実行プログラムを動作させている。しか
し、フラッシュメモリに対して新たにデータの書き換え
を行なうときは、全ブロックを−括して消去し、その後
データを記憶させる必要がある。
17612号として出願されたフラッシュメモリがあ
る。これによれば、フラッシュメモリを使用した拡張記
憶装置上では、書き換え回数を少なくなるような制御構
造を持たずに実行プログラムを動作させている。しか
し、フラッシュメモリに対して新たにデータの書き換え
を行なうときは、全ブロックを−括して消去し、その後
データを記憶させる必要がある。
【0006】また、マルチタスク,マルチスレッド,マ
ルチプロセスに代表される並列実行プログラムやデータ
の共有あるいは占有という管理を行う場合において、−
般のMMU(メモリ管理ユニット)を駆使しフラッシュ
メモリのブロック(ないしページ)毎に管理する方式で
は、書き換え回数の管理と書き換え回数の低減を図るこ
とは困難である。
ルチプロセスに代表される並列実行プログラムやデータ
の共有あるいは占有という管理を行う場合において、−
般のMMU(メモリ管理ユニット)を駆使しフラッシュ
メモリのブロック(ないしページ)毎に管理する方式で
は、書き換え回数の管理と書き換え回数の低減を図るこ
とは困難である。
【0007】−方、フラッシュメモリを使用した拡張記
憶装置上でプログラムの実行を可能とする装置にはない
ものの、フラッシュメモリの書き換え回数を少なくする
ような制御構造を持つ装置としては、補助記憶装置(半
導体ファイル記憶装置)があり、書き換え回数を少なく
するためにその情報(書き換え回数テーブル)を異なる
メモリ上に記憶する方式がある。しかし、実行プログラ
ムを主記憶装置にロードすることなくフラッシュメモリ
上で動作させるプログラムにおいて、単純に同−フラッ
シュメモリ上に記憶する場合では、ブロック間にまたが
るデータを無駄なく完全に連続的な配置を可能すること
は困難である。
憶装置上でプログラムの実行を可能とする装置にはない
ものの、フラッシュメモリの書き換え回数を少なくする
ような制御構造を持つ装置としては、補助記憶装置(半
導体ファイル記憶装置)があり、書き換え回数を少なく
するためにその情報(書き換え回数テーブル)を異なる
メモリ上に記憶する方式がある。しかし、実行プログラ
ムを主記憶装置にロードすることなくフラッシュメモリ
上で動作させるプログラムにおいて、単純に同−フラッ
シュメモリ上に記憶する場合では、ブロック間にまたが
るデータを無駄なく完全に連続的な配置を可能すること
は困難である。
【0008】以上のように、従来技術には、次のような
不都合がある。 (1)1つのデータファイルでは複数のデータレコード
を持つことが可能だが、その結合されたデータレコード
の記憶領域としては、1ブロックのデータ記憶領域に収
めなけれはならない。(データファイル:ブロック数=
1:1のとき)
不都合がある。 (1)1つのデータファイルでは複数のデータレコード
を持つことが可能だが、その結合されたデータレコード
の記憶領域としては、1ブロックのデータ記憶領域に収
めなけれはならない。(データファイル:ブロック数=
1:1のとき)
【0009】(2)1ブロックの記憶領域を超えるサイ
ズのデータレコード(スパンドレコード)を格納すると
き、そのデータレコードを1ブロックの記憶領域のサイ
ズでブロッキングするとともに、それそれの各セグメン
トにデータファイル名を個別に名付け、アプリケーショ
ン層のプログラム自身が直接各セグメントをそれぞれの
データファイル名で管理・制御しなけれはならない。
(データレコード:データファイル=1:多)
ズのデータレコード(スパンドレコード)を格納すると
き、そのデータレコードを1ブロックの記憶領域のサイ
ズでブロッキングするとともに、それそれの各セグメン
トにデータファイル名を個別に名付け、アプリケーショ
ン層のプログラム自身が直接各セグメントをそれぞれの
データファイル名で管理・制御しなけれはならない。
(データレコード:データファイル=1:多)
【0010】(3)複数のデータレコードを結合し、そ
の結合したデータのサイズが1ブロックを超えるサイズ
であり、その結合したレコードを1ブロックの記憶領域
のサイズでブロッキングし、各セグメントを割り当てら
れたそれぞれのデータファイルのデータ記憶領域に格納
するときも、アプリケーション層のプログラム自身が直
接各セグメントをそれぞれのデ−タファイル名で管理し
制御しなければならない。(データレコード:データフ
ァイル=多:多)
の結合したデータのサイズが1ブロックを超えるサイズ
であり、その結合したレコードを1ブロックの記憶領域
のサイズでブロッキングし、各セグメントを割り当てら
れたそれぞれのデータファイルのデータ記憶領域に格納
するときも、アプリケーション層のプログラム自身が直
接各セグメントをそれぞれのデ−タファイル名で管理し
制御しなければならない。(データレコード:データフ
ァイル=多:多)
【0011】(4)前記(2)や(3)おいて、アプリ
ケーション層のプログラムが結合されたデータレコード
をブロッキングした各セグメントと対比するそれぞれデ
ータファイルとのリンク情報を別メモリに格納するか、
又はデータファイル内にその情報を持たせることにな
る。このリンク情報が別メモリで管理されることになる
と別メモリが必要となり、システムを構築するために
は、低コストや省スペースの点で不利である。また、デ
ータファイルとして格納する方法では、リンク情報の更
新や修正などを行なう際のオーバヘッドが大きいこと
や、管理の複雑化になることは明らかである。
ケーション層のプログラムが結合されたデータレコード
をブロッキングした各セグメントと対比するそれぞれデ
ータファイルとのリンク情報を別メモリに格納するか、
又はデータファイル内にその情報を持たせることにな
る。このリンク情報が別メモリで管理されることになる
と別メモリが必要となり、システムを構築するために
は、低コストや省スペースの点で不利である。また、デ
ータファイルとして格納する方法では、リンク情報の更
新や修正などを行なう際のオーバヘッドが大きいこと
や、管理の複雑化になることは明らかである。
【0012】この発明は、以上の点に着目してなされた
ものであり、その目的はフラッシュメモリを使用した補
助記憶装置もしくは拡張記憶装置上で、フラッシュメモ
リの書き換え回数を少なくするような制御構造を持つ場
合に、主記憶装置に実行プログラムをロードすることな
く、拡張記憶装置上でプログラムの実行を可能とするこ
とである。他の目的は、同−のフラッシュメモリを使用
し、補助記憶装置もしくは拡張記憶装置として、書き換
え回数を少なくする無駄のない制御構造をもちながら、
マルチフロセッシング,マルチスレッド,マルチタスク
といった高度なプログラムの実行環境においてもメモリ
管理装置によって、安全に実行プログラムのモジュール
やデータファイルの管理の実現を可能とすることであ
る。
ものであり、その目的はフラッシュメモリを使用した補
助記憶装置もしくは拡張記憶装置上で、フラッシュメモ
リの書き換え回数を少なくするような制御構造を持つ場
合に、主記憶装置に実行プログラムをロードすることな
く、拡張記憶装置上でプログラムの実行を可能とするこ
とである。他の目的は、同−のフラッシュメモリを使用
し、補助記憶装置もしくは拡張記憶装置として、書き換
え回数を少なくする無駄のない制御構造をもちながら、
マルチフロセッシング,マルチスレッド,マルチタスク
といった高度なプログラムの実行環境においてもメモリ
管理装置によって、安全に実行プログラムのモジュール
やデータファイルの管理の実現を可能とすることであ
る。
【0013】更に他の目的は、同−のフラッシュメモリ
上で、拡張記憶装置及び補助記憶装置の混在を可能とす
るファイル管理技術を提供することである。更に他の目
的は、フラッシュメモリを使用した補助記憶装置もしく
は拡張記憶装置として、データレコードのブロッキング
サイスが1物理ブロックを超える場合でも1つのデータ
ファイルとして、管理・制御できる装置を実現すること
である。更に他の目的は、補助記憶装置もしくは拡張記
憶装置としてデータファイルを格納するとき、アプリケ
ーション層のプログラムからのアクセスを容易にして、
データアクセスの高速化を実現することである。
上で、拡張記憶装置及び補助記憶装置の混在を可能とす
るファイル管理技術を提供することである。更に他の目
的は、フラッシュメモリを使用した補助記憶装置もしく
は拡張記憶装置として、データレコードのブロッキング
サイスが1物理ブロックを超える場合でも1つのデータ
ファイルとして、管理・制御できる装置を実現すること
である。更に他の目的は、補助記憶装置もしくは拡張記
憶装置としてデータファイルを格納するとき、アプリケ
ーション層のプログラムからのアクセスを容易にして、
データアクセスの高速化を実現することである。
【0014】
【課題を解決するための手段】本発明のフラッシュ型メ
モリは、ブロック単位で記憶内容を消去できるフラッシ
ュ型メモリの物理ブロックに、そのブロックの管理情報
として論理的な前後のブロック番号等を記憶するへッダ
領域と、データファイルを消去ブロック単位に分割した
スパンドレコードを格納する記憶領域とを備えたことを
特徴とする。
モリは、ブロック単位で記憶内容を消去できるフラッシ
ュ型メモリの物理ブロックに、そのブロックの管理情報
として論理的な前後のブロック番号等を記憶するへッダ
領域と、データファイルを消去ブロック単位に分割した
スパンドレコードを格納する記憶領域とを備えたことを
特徴とする。
【0015】本発明のフラッシュ型メモリの管理装置
は、(1)データファイルのスパンドレコードの第1セ
グメントが格納されていることを示す先頭ブロックの情
報,(2)データファイルのスパンドレコードの最終セ
グメントが格納されていることを示す最終ブロックの情
報,(3)データファイルのスパンドレコ−ドの中間セ
グメントが格納されていることを示す中間ブロックの情
報,(4)物理ブロックのセグメントの前のセグメント
が格納されている物理ブロックを示す情報,(5)その
物理ブロックのセグメントの後のセグメントが格納され
ている物理ブロックを示す情報,(6)前記物理ブロッ
ク内の個々の情報が個々に有効か無効かを示す情報,
(7)前記物理ブロック内の個々の管理情報が無効にな
ったときに更新される新管理情報,を備えたことを特徴
とする。
は、(1)データファイルのスパンドレコードの第1セ
グメントが格納されていることを示す先頭ブロックの情
報,(2)データファイルのスパンドレコードの最終セ
グメントが格納されていることを示す最終ブロックの情
報,(3)データファイルのスパンドレコ−ドの中間セ
グメントが格納されていることを示す中間ブロックの情
報,(4)物理ブロックのセグメントの前のセグメント
が格納されている物理ブロックを示す情報,(5)その
物理ブロックのセグメントの後のセグメントが格納され
ている物理ブロックを示す情報,(6)前記物理ブロッ
ク内の個々の情報が個々に有効か無効かを示す情報,
(7)前記物理ブロック内の個々の管理情報が無効にな
ったときに更新される新管理情報,を備えたことを特徴
とする。
【0016】更に、前記管理装置は、(1)ブロック単
位に分割されたデータファイルのスパンドレコードの各
セグメントを、それぞれ物理ブロックに割り当てるとと
もに、各物理ブロックの管理情報を、該当する物理ブロ
ックにそれぞれ格納する手段,(2)システムの復旧や
データの復元を行なう手段,(3)各物理ブロックに格
納されているデータの書き換え回数を低減する手段,の
いずれかを備えたことを特徴とする。
位に分割されたデータファイルのスパンドレコードの各
セグメントを、それぞれ物理ブロックに割り当てるとと
もに、各物理ブロックの管理情報を、該当する物理ブロ
ックにそれぞれ格納する手段,(2)システムの復旧や
データの復元を行なう手段,(3)各物理ブロックに格
納されているデータの書き換え回数を低減する手段,の
いずれかを備えたことを特徴とする。
【0017】
【発明の実施の形態】以下、本発明の実施の形態につい
て詳細を説明する。本形態は、例えば図1に示すよう
に、プロセッサ(CPU)1、フラッシュメモリ2及び
その制御装置3を含む補助記憶装置(もしくは拡張記憶
装置)4、ランダムアクセスメモリ(RAM,主記憶装
置)6を含むコンピュータシステムに適用される。本発
明は、このようなシステムでフラッシュメモリ2の書き
換え寿命を延命させるデータの格納方法と管理・制御の
ための装置を得ようとするものである。
て詳細を説明する。本形態は、例えば図1に示すよう
に、プロセッサ(CPU)1、フラッシュメモリ2及び
その制御装置3を含む補助記憶装置(もしくは拡張記憶
装置)4、ランダムアクセスメモリ(RAM,主記憶装
置)6を含むコンピュータシステムに適用される。本発
明は、このようなシステムでフラッシュメモリ2の書き
換え寿命を延命させるデータの格納方法と管理・制御の
ための装置を得ようとするものである。
【0018】まず、データ領域を管理するために、フラ
ッシュメモリの管理単位をその最小イレース(消去)単
位である1ブロックとする。そして、この最小単位であ
る各ブロック内にはデータ領域と、そのブロックを管理
する情報を持つへッダ領域とが存在する。
ッシュメモリの管理単位をその最小イレース(消去)単
位である1ブロックとする。そして、この最小単位であ
る各ブロック内にはデータ領域と、そのブロックを管理
する情報を持つへッダ領域とが存在する。
【0019】図2には、本形態におけるソフトウェアの
基本構造の−例が示されている。同図のように、OS6
やアプリケーションソフト7とのソケットインタフェー
スとして、いわゆるドライバ層8に相当する部分に、フ
ラッシュ管理マネージャ9を設ける。このフラッシュ管
理マネージャ9は、本形態システム用ドライバ層と考え
ることができる。このようなフラッシュ管理マネージャ
9によって、ブロック情報の管理やデータの読み出し
(リード)/書き込み(ライト)の制御が行なわれる。
基本構造の−例が示されている。同図のように、OS6
やアプリケーションソフト7とのソケットインタフェー
スとして、いわゆるドライバ層8に相当する部分に、フ
ラッシュ管理マネージャ9を設ける。このフラッシュ管
理マネージャ9は、本形態システム用ドライバ層と考え
ることができる。このようなフラッシュ管理マネージャ
9によって、ブロック情報の管理やデータの読み出し
(リード)/書き込み(ライト)の制御が行なわれる。
【0020】例えば、図3[A]に示すように、ブロッ
ク消去がiバイト単位で可能で、かつブロック数がn+
1(16進数)個あるフラッシュメモリが1つあるとす
る。以下、これら各ブロックを「物理ブロック」と呼
ぶ。各物理ブロックには、アドレスの低い方から高い方
へ順に、物理ブロックナンバ「0」〜「n」を割り振
る。図示の例では、図の上方はアドレスが低く、下方は
アドレスが高い。従って、図の上方から、物理ブロック
0,物理ブロック1,物理ブロック2,………,物理ブ
ロックn−1,物理ブロックnとなっている。
ク消去がiバイト単位で可能で、かつブロック数がn+
1(16進数)個あるフラッシュメモリが1つあるとす
る。以下、これら各ブロックを「物理ブロック」と呼
ぶ。各物理ブロックには、アドレスの低い方から高い方
へ順に、物理ブロックナンバ「0」〜「n」を割り振
る。図示の例では、図の上方はアドレスが低く、下方は
アドレスが高い。従って、図の上方から、物理ブロック
0,物理ブロック1,物理ブロック2,………,物理ブ
ロックn−1,物理ブロックnとなっている。
【0021】ここで、各物理ブロックを管理している情
報のへッダ領域としてjバイト分を確保したとすると、
各物理ブロックに割り当てられるデータファイル領域の
サイズは、i−jバイトとなる。この様子を示すと、図
3[B]のようになる。例えば、最上位置のナンバ
「0」の物理ブロックBLAには、jバイトのへッダ領
域HAとi−jバイトのデータファイル領域DAが存在
する。次のナンバ「1」の物理ブロックBLBには、j
バイトのへッダ領域HBとi‐jバイトのデータファイ
ル領域DBが存在する。以下の物理ブロックについても
同様である。
報のへッダ領域としてjバイト分を確保したとすると、
各物理ブロックに割り当てられるデータファイル領域の
サイズは、i−jバイトとなる。この様子を示すと、図
3[B]のようになる。例えば、最上位置のナンバ
「0」の物理ブロックBLAには、jバイトのへッダ領
域HAとi−jバイトのデータファイル領域DAが存在
する。次のナンバ「1」の物理ブロックBLBには、j
バイトのへッダ領域HBとi‐jバイトのデータファイ
ル領域DBが存在する。以下の物理ブロックについても
同様である。
【0022】そして、1データファイルをスパンドレコ
ードとして取り扱い、その中の各セグメントのデータを
物理ブロックのデータファイル領域に格納する。各セグ
メントのデータが格納された物理ブロックにおけるヘッ
ダ領域には、そのセグメント(物理ブロック)の論理的
に連鎖するセグメントの情報や、それらの情報が有効な
情報かそれとも無効な情報かを示す情報が格納される。
また、それらの情報を更新するための情報領域も設けら
れる。
ードとして取り扱い、その中の各セグメントのデータを
物理ブロックのデータファイル領域に格納する。各セグ
メントのデータが格納された物理ブロックにおけるヘッ
ダ領域には、そのセグメント(物理ブロック)の論理的
に連鎖するセグメントの情報や、それらの情報が有効な
情報かそれとも無効な情報かを示す情報が格納される。
また、それらの情報を更新するための情報領域も設けら
れる。
【0023】図4[A]に示す例は、1つのデータファ
イルが3(i−j)−kバイトある複数のデータレコー
ドからなるファイルの例である。このデータファイルを
1つのスパンドレコードとして扱うと、同図[B]に示
すように3つのセグメントに分割される。すなわち、タ
ファイルのレコードの最初の部分からi−jバイト分を
第1のセグメントとし、その続きからi‐jバイト分を
第2のセグメントとし、その続きからi−j‐kバイト
分とその後のkバイト分のFFhデータを第3のセグメ
ントとする。そして、同図[C]に示すように、これら
の第1〜第3の各セグメントに、ブロックヘッダである
BCW(ブロックの管理情報)と、SCW(セグメント
の管理情報)をそれぞれ付加し、物理ブロックを構成す
る。これを前記図3[B]と対比すると、BCW,SC
Wはブロックヘッダ領域に格納され、各セグメントはデ
ータファイル領域に格納される。
イルが3(i−j)−kバイトある複数のデータレコー
ドからなるファイルの例である。このデータファイルを
1つのスパンドレコードとして扱うと、同図[B]に示
すように3つのセグメントに分割される。すなわち、タ
ファイルのレコードの最初の部分からi−jバイト分を
第1のセグメントとし、その続きからi‐jバイト分を
第2のセグメントとし、その続きからi−j‐kバイト
分とその後のkバイト分のFFhデータを第3のセグメ
ントとする。そして、同図[C]に示すように、これら
の第1〜第3の各セグメントに、ブロックヘッダである
BCW(ブロックの管理情報)と、SCW(セグメント
の管理情報)をそれぞれ付加し、物理ブロックを構成す
る。これを前記図3[B]と対比すると、BCW,SC
Wはブロックヘッダ領域に格納され、各セグメントはデ
ータファイル領域に格納される。
【0024】次に、物理ブロックのへッダ領域について
説明する。データファイルをスパンドレコードとして取
り扱った場合、その中のセグメントの情報(SCW),
そのセグメント(物理ブロック)の論理的に連鎖するセ
グメントの情報,それらの情報が有効な情報かそれとも
無効な情報かを示すような情報,が物理ブロックヘッダ
に必要である。そこで、例えば、物理ブロックヘッダ
に、次のような割り当てを行う。
説明する。データファイルをスパンドレコードとして取
り扱った場合、その中のセグメントの情報(SCW),
そのセグメント(物理ブロック)の論理的に連鎖するセ
グメントの情報,それらの情報が有効な情報かそれとも
無効な情報かを示すような情報,が物理ブロックヘッダ
に必要である。そこで、例えば、物理ブロックヘッダ
に、次のような割り当てを行う。
【0025】(1)物理ブロックの状態(有効/無効/
遷移中/初期化)を示すフラグ (2)データファイル名(又はデータファイルを特定す
る情報) (3)該当するファイルの先頭ブロック(先頭セグメン
ト)を示すフラグ又はそれに相当する手段 (4)該当するファイルの最終ブロック(最終セグメン
ト)を示すフラグ又はそれに相当する手段
遷移中/初期化)を示すフラグ (2)データファイル名(又はデータファイルを特定す
る情報) (3)該当するファイルの先頭ブロック(先頭セグメン
ト)を示すフラグ又はそれに相当する手段 (4)該当するファイルの最終ブロック(最終セグメン
ト)を示すフラグ又はそれに相当する手段
【0026】(5)該当するファイルの中間ブロック
(中間セグメント)を示すフラグ又はそれに相当する手
段 (6)該当するブロックの前のブロック番号を示す前ブ
ロックポインタを格納する領域 (7)上記(6)の領域が有効/無効/未格納のいずれ
であるかを示すフラグ (8)該当するブロックの後のブロック番号を示す後ブ
ロックポインタを格納する領域 (9)上記(8)の領域が有効/無効/未格納のいずれ
であるかを示すフラグ
(中間セグメント)を示すフラグ又はそれに相当する手
段 (6)該当するブロックの前のブロック番号を示す前ブ
ロックポインタを格納する領域 (7)上記(6)の領域が有効/無効/未格納のいずれ
であるかを示すフラグ (8)該当するブロックの後のブロック番号を示す後ブ
ロックポインタを格納する領域 (9)上記(8)の領域が有効/無効/未格納のいずれ
であるかを示すフラグ
【0027】(10)該当するブロックの前のブロック
ポインタが示す領域が無効のとき、更新される番号を示
す前ブロックポインタの情報を格納する更新領域 (11)上記(10)の領域が有効/無効/未格納のい
ずれであるかを示すフラグ (12)該当するブロックの後のブロックポインタが示
す領域が無効のとき、更新される番号を示す後ブロック
ポインタの情報を格納する更新領域 (13)上記(12)の領域が有効/無効/未格納のい
ずれであるかを示すフラグ
ポインタが示す領域が無効のとき、更新される番号を示
す前ブロックポインタの情報を格納する更新領域 (11)上記(10)の領域が有効/無効/未格納のい
ずれであるかを示すフラグ (12)該当するブロックの後のブロックポインタが示
す領域が無効のとき、更新される番号を示す後ブロック
ポインタの情報を格納する更新領域 (13)上記(12)の領域が有効/無効/未格納のい
ずれであるかを示すフラグ
【0028】以下、順に説明する。まず、「(1)のフ
ラグ」から説明する。フラッシュ管理マネージャ9は各
ブロックヘッダの内容を読み、フラッシュメモリ2にど
のようにデータが格納されているかを確認して管理す
る。フラッシュメモリ2のメモリセル内のビットデータ
は、論理値の「1」→「0」への変化の処理時間は比較
的に短い。しかし、反対に、「0」→「1」の変化は、
−度ブロックイレース又はチップイレースを行わなけれ
ばならず、長時間を要する。つまり、1ビットのデータ
の書き換えを行なうために、そのブロック内(又はチッ
プ内)のデータを−時待避させるとともに、イレース後
それらを書き戻す必要があり、大きな処理時間を要す
る。
ラグ」から説明する。フラッシュ管理マネージャ9は各
ブロックヘッダの内容を読み、フラッシュメモリ2にど
のようにデータが格納されているかを確認して管理す
る。フラッシュメモリ2のメモリセル内のビットデータ
は、論理値の「1」→「0」への変化の処理時間は比較
的に短い。しかし、反対に、「0」→「1」の変化は、
−度ブロックイレース又はチップイレースを行わなけれ
ばならず、長時間を要する。つまり、1ビットのデータ
の書き換えを行なうために、そのブロック内(又はチッ
プ内)のデータを−時待避させるとともに、イレース後
それらを書き戻す必要があり、大きな処理時間を要す
る。
【0029】そこで、実際には、物理ブロックの状態を
示すフラグを利用してその物理ブロックの状態を管理す
ることになる。すなわち、上述した書き換えに伴うオー
バヘッドを軽減するために、物理ブロックヘッダ内にそ
の物理ブロックが有効な状態なのか,無効な状態なの
か,初期化が完了した状態なのか,有効な状態から無効
な状態への遷移する状態なのか,ブロックイレース後の
初期化完了前の状態なのか,といった状態をそれぞれの
物理ブロック毎に認識する。そして、この状態に基づい
て、データの書き込み,データの無効化,物理ブロック
のイレース,物理ブロックの初期化などの操作を行な
う。
示すフラグを利用してその物理ブロックの状態を管理す
ることになる。すなわち、上述した書き換えに伴うオー
バヘッドを軽減するために、物理ブロックヘッダ内にそ
の物理ブロックが有効な状態なのか,無効な状態なの
か,初期化が完了した状態なのか,有効な状態から無効
な状態への遷移する状態なのか,ブロックイレース後の
初期化完了前の状態なのか,といった状態をそれぞれの
物理ブロック毎に認識する。そして、この状態に基づい
て、データの書き込み,データの無効化,物理ブロック
のイレース,物理ブロックの初期化などの操作を行な
う。
【0030】「(2)のデータファイル名」は、スパン
ドレコードを取り扱っている論理データレコードの名称
である。各物理ブロックは、このデータファイル名によ
り分類される。なお、データファイル名は、データファ
イルが特定できる情報であってもよい。
ドレコードを取り扱っている論理データレコードの名称
である。各物理ブロックは、このデータファイル名によ
り分類される。なお、データファイル名は、データファ
イルが特定できる情報であってもよい。
【0031】「(3)の該当するファイルの先頭ブロッ
ク(先頭セグメント)を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの先頭セグメントが格納されていることを明示する
ものである。
ク(先頭セグメント)を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの先頭セグメントが格納されていることを明示する
ものである。
【0032】「(4)の該当するファイルの最終ブロッ
ク(最終セグメント)を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの最終セグメントが格納されていることを明示する
ものである。
ク(最終セグメント)を示すフラグ又はその手段」は、
その物理ブロックのデータ領域に、該当するデータファ
イルの最終セグメントが格納されていることを明示する
ものである。
【0033】「(5)の該当するファイルの中間セグメ
ントを示すフラグ又はその手段」は、その物理ブロック
のデータ領域に、該当するデータファイルの先頭や最終
ではなく中間のセグメントが格納されていることを明示
するものである。
ントを示すフラグ又はその手段」は、その物理ブロック
のデータ領域に、該当するデータファイルの先頭や最終
ではなく中間のセグメントが格納されていることを明示
するものである。
【0034】「(6)の該当するブロックの前のブロッ
ク番号を示す前ブロックポインタを格納する領域」は、
該当する物理ブロックの前に論理的に連鎖する物理ブロ
ックの番号情報を格納する領域である。なお、前の物理
ブロック番号情報は、そのデータファイルの中における
該当セグメントの前のセグメントのデータが格納されて
いる物理ブロックを示すものである。
ク番号を示す前ブロックポインタを格納する領域」は、
該当する物理ブロックの前に論理的に連鎖する物理ブロ
ックの番号情報を格納する領域である。なお、前の物理
ブロック番号情報は、そのデータファイルの中における
該当セグメントの前のセグメントのデータが格納されて
いる物理ブロックを示すものである。
【0035】「(7)の前記(6)の領域が有効/無効
/未格納のいずれであるかを示すフラグ」は、前記
(6)の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記(6)の領域の情報が最終
の情報であるかどうかが決まる。
/未格納のいずれであるかを示すフラグ」は、前記
(6)の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記(6)の領域の情報が最終
の情報であるかどうかが決まる。
【0036】「(8)の該当する物理ブロックの後の物
理ブロック番号を示す後ブロックポインタを格納する領
域」は、該当する物理ブロックの後に論理的に連鎖する
物理ブロックの番号の情報を格納する領域である。な
お、後の物理ブロック番号の情報は、そのデータファイ
ル中における該当セグメントの後のセグメントのデータ
が格納されている物理ブロックを示すものである。
理ブロック番号を示す後ブロックポインタを格納する領
域」は、該当する物理ブロックの後に論理的に連鎖する
物理ブロックの番号の情報を格納する領域である。な
お、後の物理ブロック番号の情報は、そのデータファイ
ル中における該当セグメントの後のセグメントのデータ
が格納されている物理ブロックを示すものである。
【0037】「(9)の前記(8)の領域が有効/無効
/未格納のいずれであるかを示すフラグ」は、前記
(8)の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記(8)の領域の情報が最終
の情報であるかどうかか決まる。
/未格納のいずれであるかを示すフラグ」は、前記
(8)の領域に書かれている情報が、有効な状態なの
か、無効な状態なのか、未格納な状態なのかを表すもの
である。これによって、前記(8)の領域の情報が最終
の情報であるかどうかか決まる。
【0038】「(10)の該当するブロックの前ブロッ
クポインタが示す領域が無効のとき、新たに更新される
番号を示す前ブロックポインタの情報を格納するための
更新領域」は、最初に有効だった前ブロックポインタ
(最初の情報領域や更新情報領域)の情報領域が無効と
なり、新たに更新したときに情報を格納するための更新
情報領域である。
クポインタが示す領域が無効のとき、新たに更新される
番号を示す前ブロックポインタの情報を格納するための
更新領域」は、最初に有効だった前ブロックポインタ
(最初の情報領域や更新情報領域)の情報領域が無効と
なり、新たに更新したときに情報を格納するための更新
情報領域である。
【0039】「(11)の更新された前ブロックポイン
タを格納する情報の領域が有効/無効/未格納を示すフ
ラグ」は、前記(10)で格納されている情報領域が有
効な状態なのか、無効な状態なのか、未格納な状態なの
かを表すものである。
タを格納する情報の領域が有効/無効/未格納を示すフ
ラグ」は、前記(10)で格納されている情報領域が有
効な状態なのか、無効な状態なのか、未格納な状態なの
かを表すものである。
【0040】「(12)の該当する物理ブロックの後ブ
ロックポインタが示す領域が無効のとき、新たに更新さ
れる番号を示す前ブロックポインタの情報を格納するた
めの更新領域」は、最初に有効だった後ブロックポイン
タ(最初の情報領域や更新情報領域)の情報領域が無効
となり、新たに更新したときに情報を格納するための更
新情報領域である。
ロックポインタが示す領域が無効のとき、新たに更新さ
れる番号を示す前ブロックポインタの情報を格納するた
めの更新領域」は、最初に有効だった後ブロックポイン
タ(最初の情報領域や更新情報領域)の情報領域が無効
となり、新たに更新したときに情報を格納するための更
新情報領域である。
【0041】次に、「(13)の更新された後ブロック
ポインタを格納する情報の領域が有効/無効/未格納を
示すフラグ」は、前記(12)で格納されている情報領
域が、有効な状態なのか、無効な状態なのか、未格納な
状態なのかを表すものである。
ポインタを格納する情報の領域が有効/無効/未格納を
示すフラグ」は、前記(12)で格納されている情報領
域が、有効な状態なのか、無効な状態なのか、未格納な
状態なのかを表すものである。
【0042】次に、物理ブロックのデータファイル領域
について説明する。データファイルの配置は、フラッシ
ュ管理マネージャ9によって行われる。データファイル
として、例えば、図5[A]に示すようなデータレコー
ド1〜nの論理的なデータがあるとする。このデータフ
ァイルは、図5[B]に示すように、物理ブロックヘッ
ダの領域を除くデータファイル領域にスパンドレコード
のセグメントのレコードとして格納されることになる。
について説明する。データファイルの配置は、フラッシ
ュ管理マネージャ9によって行われる。データファイル
として、例えば、図5[A]に示すようなデータレコー
ド1〜nの論理的なデータがあるとする。このデータフ
ァイルは、図5[B]に示すように、物理ブロックヘッ
ダの領域を除くデータファイル領域にスパンドレコード
のセグメントのレコードとして格納されることになる。
【0043】ここで、データの構造として、データファ
イル内の論理的なデータをデータレコードにブロッキン
グ(ブロック化)し、図5[C]に示すように、そのデ
ータレコードDRにデータレコードヘッダDRHやデー
タレコードフッダDRFを付随させた形でデータレコー
ドのパケットDRPを構成する。このようなブロッキン
グの方法としては、固定長レコードと可変長レコードが
ある。本形態ではどちらでもよい。しかし、ブロッキン
グは、OSやアプリケーションソフトに依存することが
多いため、システム上、フラッシュ管理マネージャ9が
ブロッキングの方法を決定して制御する。また、データ
レコードヘッダDRHやデータレコードフッダDRFに
は、線形リスト構造とそのパケットの管理用情報を持た
せるようにする。すると、データレコードパケットDR
Pは、図6に示すようなデータ構造を持つことになる。
このデータレコードパケットDRPのデータ構造のサイ
ズは、i−jバイトの倍数分の3ブロックであり、デー
タレコードパケットDRPが格納される部分以外には
「0xFF」のデータが格納される。
イル内の論理的なデータをデータレコードにブロッキン
グ(ブロック化)し、図5[C]に示すように、そのデ
ータレコードDRにデータレコードヘッダDRHやデー
タレコードフッダDRFを付随させた形でデータレコー
ドのパケットDRPを構成する。このようなブロッキン
グの方法としては、固定長レコードと可変長レコードが
ある。本形態ではどちらでもよい。しかし、ブロッキン
グは、OSやアプリケーションソフトに依存することが
多いため、システム上、フラッシュ管理マネージャ9が
ブロッキングの方法を決定して制御する。また、データ
レコードヘッダDRHやデータレコードフッダDRFに
は、線形リスト構造とそのパケットの管理用情報を持た
せるようにする。すると、データレコードパケットDR
Pは、図6に示すようなデータ構造を持つことになる。
このデータレコードパケットDRPのデータ構造のサイ
ズは、i−jバイトの倍数分の3ブロックであり、デー
タレコードパケットDRPが格納される部分以外には
「0xFF」のデータが格納される。
【0044】このように、データファイルの論理的なデ
ータレコードDRは、割り当てられた物理ブロックのデ
ータファイル領域にデータレコードパケットDRPとし
て格納される。また、図6に示すように、それらのデー
タレコードパケットDRPにしたデータ構造をi−jバ
イトづつブロッキングし、そのブロッキングしたものを
スパンドレコードのセグメントとする。
ータレコードDRは、割り当てられた物理ブロックのデ
ータファイル領域にデータレコードパケットDRPとし
て格納される。また、図6に示すように、それらのデー
タレコードパケットDRPにしたデータ構造をi−jバ
イトづつブロッキングし、そのブロッキングしたものを
スパンドレコードのセグメントとする。
【0045】図7には、ブロッキングした後に各セグメ
ントを物理ブロックに割り当てたときのセグメントデー
タの格納結果を表している。この例では、ブロックXの
データファイル領域には、データファイルAの先頭セグ
メントのデータが格納されており、ヘッダ領域には、先
頭セグメントであることを示す「先頭(有効)」と、次
の中間セグメントデータが格納されている物理ブロック
を示す「XY(有効)」の情報が格納されている。ブロ
ックXYのデータファイル領域には中間セグメントデー
タが格納されており、ヘッダ領域には、前のセグメント
データが格納されている物理ブロックを示す「X(有
効)」と、次のセグメントデータが格納されている物理
ブロックを示す「XX(有効)」の情報が格納されてい
る。更に、ブロックXXのデータファイル領域には最終
セグメントデータが格納されており、ヘッダ領域には、
前のセグメントデータが格納されている物理ブロックを
示す「XY(有効)」と、本物理ブロックに最終のセグ
メントデータが格納されていることを示す「最終(有
効)」の情報が格納されている。フラッシュ管理マネー
ジャ9は、データレコードパケットDRPの管理と、物
理ブロックBLの管理という2重管理を行なう。
ントを物理ブロックに割り当てたときのセグメントデー
タの格納結果を表している。この例では、ブロックXの
データファイル領域には、データファイルAの先頭セグ
メントのデータが格納されており、ヘッダ領域には、先
頭セグメントであることを示す「先頭(有効)」と、次
の中間セグメントデータが格納されている物理ブロック
を示す「XY(有効)」の情報が格納されている。ブロ
ックXYのデータファイル領域には中間セグメントデー
タが格納されており、ヘッダ領域には、前のセグメント
データが格納されている物理ブロックを示す「X(有
効)」と、次のセグメントデータが格納されている物理
ブロックを示す「XX(有効)」の情報が格納されてい
る。更に、ブロックXXのデータファイル領域には最終
セグメントデータが格納されており、ヘッダ領域には、
前のセグメントデータが格納されている物理ブロックを
示す「XY(有効)」と、本物理ブロックに最終のセグ
メントデータが格納されていることを示す「最終(有
効)」の情報が格納されている。フラッシュ管理マネー
ジャ9は、データレコードパケットDRPの管理と、物
理ブロックBLの管理という2重管理を行なう。
【0046】図8,図9には、データファイルをフラッ
シュメモリに格納する様子が示されている。この例で
は、図8に示すように、データファイルA、データファ
イルB、データファイルC、…のファイルがある。そし
て、データファイルAは、論理的なデータをデータレコ
ード毎にパケット化して全体をセグメント化すると3ブ
ロック必要となり、それらを物理ブロック0,2,m+
1にそれぞれ割り当てている。データファイルB,デー
タファイルC,…についても、同様にして複数のブロッ
クを使用し、それぞれの物理ブロックにセグメントデー
タが割り当てられている。データが割り当てられていな
いブロック(未割当てブロック)として、物理ブロック
n‐1,nがある。
シュメモリに格納する様子が示されている。この例で
は、図8に示すように、データファイルA、データファ
イルB、データファイルC、…のファイルがある。そし
て、データファイルAは、論理的なデータをデータレコ
ード毎にパケット化して全体をセグメント化すると3ブ
ロック必要となり、それらを物理ブロック0,2,m+
1にそれぞれ割り当てている。データファイルB,デー
タファイルC,…についても、同様にして複数のブロッ
クを使用し、それぞれの物理ブロックにセグメントデー
タが割り当てられている。データが割り当てられていな
いブロック(未割当てブロック)として、物理ブロック
n‐1,nがある。
【0047】図9は、前記データファイルAについて、
そのパケット化とセグメント化の様子を示している。デ
ータファイルAは、同図[A]に示すように、論理的な
データとして、データレコード[0]〜[9]までを持
っている。次に、同図[B]に示すように、これらの各
データレコードに各々データレコードヘッダDRHやデ
ータレコードフッダDRFを付加し、データレコードパ
ケットDRPを完成する。そして、連結したデータレコ
ードパケットDRPを、データファイルAのスパンドレ
コードとしてセグメント単位に分割し、分割したセグメ
ントをセグメント0〜2とする。データレコード[9]
の後のデータには、すべて「0xFF」が格納される。
これは、フラッシュメモリの特性から、ビットを「1」
から「0」に書き込むことになり、このシステムでは新
データレコードを追記していくことに対応するためであ
る。そして、同図[C]に示すように、セグメント化し
た0〜2のデータを、割り当てられている物理ブロック
[1],物理ブロック[2],物理ブロック[m+1]
のデータファイル領域にそれぞれ格納する。その後、各
物理ブロックヘッダにそれらの内容の管理情報を格納す
る。
そのパケット化とセグメント化の様子を示している。デ
ータファイルAは、同図[A]に示すように、論理的な
データとして、データレコード[0]〜[9]までを持
っている。次に、同図[B]に示すように、これらの各
データレコードに各々データレコードヘッダDRHやデ
ータレコードフッダDRFを付加し、データレコードパ
ケットDRPを完成する。そして、連結したデータレコ
ードパケットDRPを、データファイルAのスパンドレ
コードとしてセグメント単位に分割し、分割したセグメ
ントをセグメント0〜2とする。データレコード[9]
の後のデータには、すべて「0xFF」が格納される。
これは、フラッシュメモリの特性から、ビットを「1」
から「0」に書き込むことになり、このシステムでは新
データレコードを追記していくことに対応するためであ
る。そして、同図[C]に示すように、セグメント化し
た0〜2のデータを、割り当てられている物理ブロック
[1],物理ブロック[2],物理ブロック[m+1]
のデータファイル領域にそれぞれ格納する。その後、各
物理ブロックヘッダにそれらの内容の管理情報を格納す
る。
【0048】次に、物理ブロックの初期化の手順につい
て説明する。フラッシュ管理マネージャ9は、フラッシ
ュメモリ2が管理されていなければ、まず最初に各物理
ブロックの初期化を行なう。初期化する場合は、−度す
べての物理ブロックをイレースして、各物理フロックの
ブロックヘッダに初期化完了フラグの情報を格納する。
また、システムを使用していくうちに、データファイル
領域のセグメントデータを消去できるような状況になっ
たときは、その物理ブロックをブロックイレースして、
その物理ブロックのブロックヘッダに初期化完了フラグ
の情報を格納する。初期化が完了すると、その物理ブロ
ックは、新たなデータファイル領域として、データの新
規書き込みあるいはデータレコードの連結を行なうこと
ができる。
て説明する。フラッシュ管理マネージャ9は、フラッシ
ュメモリ2が管理されていなければ、まず最初に各物理
ブロックの初期化を行なう。初期化する場合は、−度す
べての物理ブロックをイレースして、各物理フロックの
ブロックヘッダに初期化完了フラグの情報を格納する。
また、システムを使用していくうちに、データファイル
領域のセグメントデータを消去できるような状況になっ
たときは、その物理ブロックをブロックイレースして、
その物理ブロックのブロックヘッダに初期化完了フラグ
の情報を格納する。初期化が完了すると、その物理ブロ
ックは、新たなデータファイル領域として、データの新
規書き込みあるいはデータレコードの連結を行なうこと
ができる。
【0049】次に、データファイル領域にデータを格納
するときの手順について説明する。この場合は、まず、
割り当てる物理ブロックヘッダの有効フラグをONに
し、データファイル名を格納する。その後ブロッキング
されたデータレコードをデータ領域内に順次格納してい
く。データレコードは追記していくことになるが、デー
タレコードを書き換えたい場合は、フラッシュメモリの
特徴からその部分を書き換えることは、上述したように
オーバーヘッドが大きい。小さいオーバーヘッドで旧論
理データレコードから新論理データレコードへデータを
書き換える方法としては、(1)旧データレコードを無
効とし、新たにデータレコードを追記していく方法,
(2)その物理ブロックの遷移中フラグをON(処理終
了後無効フラグをONにする)にするとともに、その物
理フロックの代替ブロックを割り当て、この代替ブロッ
クにデータを新たに格納し、連鎖情報を戻す方法があ
る。
するときの手順について説明する。この場合は、まず、
割り当てる物理ブロックヘッダの有効フラグをONに
し、データファイル名を格納する。その後ブロッキング
されたデータレコードをデータ領域内に順次格納してい
く。データレコードは追記していくことになるが、デー
タレコードを書き換えたい場合は、フラッシュメモリの
特徴からその部分を書き換えることは、上述したように
オーバーヘッドが大きい。小さいオーバーヘッドで旧論
理データレコードから新論理データレコードへデータを
書き換える方法としては、(1)旧データレコードを無
効とし、新たにデータレコードを追記していく方法,
(2)その物理ブロックの遷移中フラグをON(処理終
了後無効フラグをONにする)にするとともに、その物
理フロックの代替ブロックを割り当て、この代替ブロッ
クにデータを新たに格納し、連鎖情報を戻す方法があ
る。
【0050】最初の(1)の方法では、無効なデータレ
コードのみならず、有効なデータレコードも無効にし
て、その有効だったデータを新たに追記しなければなら
ない。−方、後述の(2)の方法によれば、ブロック全
体の書き換えを行なうため、データを書き込むための処
理に時間がかかる。従って、前記(1)の方法では小さ
なデータレコードは非常に高速に処理できるが、大きな
データレコードには不向きである。逆に、後述の(2)
の方法では、大きなデータレコードとっては無駄の少な
いシステムとして運用できるが、小さなデータレコード
には不向きである。そこで、本形態では、セグメントを
無効とするか,データレコードを無効とするか,セグメ
ントを書き換えるか,データレコードを更新するか,の
いくつかの方法の組み合わせによって最適なシステムを
構成する。このようにすることで、最終的にフラッシュ
メモリの書き換え回数を低減することができる。
コードのみならず、有効なデータレコードも無効にし
て、その有効だったデータを新たに追記しなければなら
ない。−方、後述の(2)の方法によれば、ブロック全
体の書き換えを行なうため、データを書き込むための処
理に時間がかかる。従って、前記(1)の方法では小さ
なデータレコードは非常に高速に処理できるが、大きな
データレコードには不向きである。逆に、後述の(2)
の方法では、大きなデータレコードとっては無駄の少な
いシステムとして運用できるが、小さなデータレコード
には不向きである。そこで、本形態では、セグメントを
無効とするか,データレコードを無効とするか,セグメ
ントを書き換えるか,データレコードを更新するか,の
いくつかの方法の組み合わせによって最適なシステムを
構成する。このようにすることで、最終的にフラッシュ
メモリの書き換え回数を低減することができる。
【0051】なお、無効となったデータレコードは、デ
ータレコードヘッダ内に無効フラグを持たせることによ
って、フラッシュ管理マネージャ9は無効と判断でき
る。また、物理ブロックのデータファイル領域内でデー
タレコードがすべて無効となった場合、その物理ブロッ
クヘッダの無効フラグをONにすることによって、この
物理ブロックをブロックイレースすることができる。ブ
ロックイレースが完了したときは、前述のブロックヘッ
ダの初期化を行なう。
ータレコードヘッダ内に無効フラグを持たせることによ
って、フラッシュ管理マネージャ9は無効と判断でき
る。また、物理ブロックのデータファイル領域内でデー
タレコードがすべて無効となった場合、その物理ブロッ
クヘッダの無効フラグをONにすることによって、この
物理ブロックをブロックイレースすることができる。ブ
ロックイレースが完了したときは、前述のブロックヘッ
ダの初期化を行なう。
【0052】以上のようにしてシステムを運用すると、
その途中経過として、あるデータファイル内のセグメン
トの中で無効となるデータレコードが多くなり、新規に
割り当てるための物理ブロックが不足する可能性があ
る。このような場合、システムはデータを書き込むため
の領域を失い、システムとして破綻することがある。こ
のような不都合をなくすために、ファイル管理マネージ
ャ9はデフラグメンテーションを行なう必要がある。
その途中経過として、あるデータファイル内のセグメン
トの中で無効となるデータレコードが多くなり、新規に
割り当てるための物理ブロックが不足する可能性があ
る。このような場合、システムはデータを書き込むため
の領域を失い、システムとして破綻することがある。こ
のような不都合をなくすために、ファイル管理マネージ
ャ9はデフラグメンテーションを行なう必要がある。
【0053】あるデータファイルのあるセグメントの中
で、無効なデータレコードが多くある場合、そのセグメ
ントを論理的なデータ構造から取り除くことが望まし
い。しかし、そのセグメント中には有効なデータレコー
ドも存在しているため、そのセグメントをもつ物理ブロ
ックを消去することはできない。そこで、その有効なデ
ータレコードを、そのデータファイル内の別のセグメン
トに移動させることになる。つまり、そのデータファイ
ルのもつ他の物理ブロックにそのデータレコードのコピ
ーを行ない、その後コピー元のセグメントのデータレコ
ードを無効にする。そして、データレコードを無効にし
たセグメントの物理ブロックを無効にしてブロックイレ
ースし、初期化する。このようなデフラグメンテーショ
ン処理によって効果の上がる場合は、その選定基準は−
元的なものではない。物理ブロックの容量,データレコ
ードのパケットサイズ,データファイルの容量,システ
ムのパフォーマンスなどを考慮して、システム全体が効
率的に処理を行なうことができるように、選定基準を選
ぶようにする。
で、無効なデータレコードが多くある場合、そのセグメ
ントを論理的なデータ構造から取り除くことが望まし
い。しかし、そのセグメント中には有効なデータレコー
ドも存在しているため、そのセグメントをもつ物理ブロ
ックを消去することはできない。そこで、その有効なデ
ータレコードを、そのデータファイル内の別のセグメン
トに移動させることになる。つまり、そのデータファイ
ルのもつ他の物理ブロックにそのデータレコードのコピ
ーを行ない、その後コピー元のセグメントのデータレコ
ードを無効にする。そして、データレコードを無効にし
たセグメントの物理ブロックを無効にしてブロックイレ
ースし、初期化する。このようなデフラグメンテーショ
ン処理によって効果の上がる場合は、その選定基準は−
元的なものではない。物理ブロックの容量,データレコ
ードのパケットサイズ,データファイルの容量,システ
ムのパフォーマンスなどを考慮して、システム全体が効
率的に処理を行なうことができるように、選定基準を選
ぶようにする。
【0054】デフラグメンテーシヨンの具体例を図10
に示す。図10は、上述した図9のデータファイルAか
ら、図10[A]に示すように、データレコード4,デ
ータレコード6,データレコード7が無効となった後の
様子を示している。無効となるデータレコード4,6,
7は、図10[B]に示すように、データファイルAの
セグメント1に含まれている。ここで、例えば、セグメ
ント1すなわち物理ブロック[2]を無効化するととも
に(同図[C]参照)、そのイレース・初期化を行った
方がよいと判断されたとする。この場合、有効なデータ
レコード[5]を例えばデータレコード[9]に移動さ
せれば、データファイルAのセグメント1すなわち物理
ブロック[2]をブロックイレース・初期化することが
でき、後にデータを割り当てるブロックとして利用する
ことができる。
に示す。図10は、上述した図9のデータファイルAか
ら、図10[A]に示すように、データレコード4,デ
ータレコード6,データレコード7が無効となった後の
様子を示している。無効となるデータレコード4,6,
7は、図10[B]に示すように、データファイルAの
セグメント1に含まれている。ここで、例えば、セグメ
ント1すなわち物理ブロック[2]を無効化するととも
に(同図[C]参照)、そのイレース・初期化を行った
方がよいと判断されたとする。この場合、有効なデータ
レコード[5]を例えばデータレコード[9]に移動さ
せれば、データファイルAのセグメント1すなわち物理
ブロック[2]をブロックイレース・初期化することが
でき、後にデータを割り当てるブロックとして利用する
ことができる。
【0055】このような処理の結果を示すと、図11の
ようになる。同図[A]に示すデータファイルAの論理
的なデータイメージは、図10[A]に示したデータフ
ァイルAの論理的なデータイメージとは配列が異なるよ
うになる。そして、同図[B],[C]に示すように、
セグメント1は物理的に切り離され、そのブロックはイ
レース可能となってブロックイレース・初期化の処理を
行なうことで、その物理ブロックが未割当てフロックと
なる。このような処理を行うことで、新規のデータの追
加をより多く行うことができるようになる。
ようになる。同図[A]に示すデータファイルAの論理
的なデータイメージは、図10[A]に示したデータフ
ァイルAの論理的なデータイメージとは配列が異なるよ
うになる。そして、同図[B],[C]に示すように、
セグメント1は物理的に切り離され、そのブロックはイ
レース可能となってブロックイレース・初期化の処理を
行なうことで、その物理ブロックが未割当てフロックと
なる。このような処理を行うことで、新規のデータの追
加をより多く行うことができるようになる。
【0056】このように、すべてのデータレコードを新
規に書き換えることなく、論理的なセグメントの情報変
更を行なうことで、すなわち物理ブロックの連鎖情報を
更新することによって、データの書き換えを最小限に抑
えることができる。これにより、フラッシュメモリの書
き換え回数を低減することができる。また、システムの
運用時間を延ばし、フラッシュメモリの書き換え寿命
(回数ではなく時間)を延ばすことも可能となる。
規に書き換えることなく、論理的なセグメントの情報変
更を行なうことで、すなわち物理ブロックの連鎖情報を
更新することによって、データの書き換えを最小限に抑
えることができる。これにより、フラッシュメモリの書
き換え回数を低減することができる。また、システムの
運用時間を延ばし、フラッシュメモリの書き換え寿命
(回数ではなく時間)を延ばすことも可能となる。
【0057】また、連鎖情報の更新はブロックヘッダの
領域に追記されるため、結果的に過去の連鎖情報がある
程度保持されることになる。このため、故意・過失・事
故によって消失や破壊されたデータをある程度復元する
こともできる。これは、コンピュータシステムの異常に
よる停止からの復旧やデータの復元に有効である。な
お、フラッシュメモリによっては、ライト(書き込み)
操作中に他のオペレーションができないチップが存在す
る。このようなときは、タスク,スレッドのようなフロ
グラム技法により排他制御を行なうようにする。
領域に追記されるため、結果的に過去の連鎖情報がある
程度保持されることになる。このため、故意・過失・事
故によって消失や破壊されたデータをある程度復元する
こともできる。これは、コンピュータシステムの異常に
よる停止からの復旧やデータの復元に有効である。な
お、フラッシュメモリによっては、ライト(書き込み)
操作中に他のオペレーションができないチップが存在す
る。このようなときは、タスク,スレッドのようなフロ
グラム技法により排他制御を行なうようにする。
【0058】以下、本形態の実施例について説明する。
図12には、フラッシュメモリに対する物理ブロックヘ
ッダの格納例が示されている。図12[A]の例は、6
4Kバイトを消去ブロック単位とするフラッシュメモリ
で、物理ブロック数がn+1個あるシステムである。各
物理ブロックの先頭には、図12[B]に示すように、
各物理ブロックの管理情報を格納するへッダ領域とし
て、256バイトが割り当てられている。具体的には、
図13[A]に示すように、ブロック消去が64Kバイ
ト単位で可能な2M×8ビットのフラッシュメモリが使
用される。そして、同図に示すように、各物理ブロック
に「0」から「1F」と順に番号(16進数)を付け
る。
図12には、フラッシュメモリに対する物理ブロックヘ
ッダの格納例が示されている。図12[A]の例は、6
4Kバイトを消去ブロック単位とするフラッシュメモリ
で、物理ブロック数がn+1個あるシステムである。各
物理ブロックの先頭には、図12[B]に示すように、
各物理ブロックの管理情報を格納するへッダ領域とし
て、256バイトが割り当てられている。具体的には、
図13[A]に示すように、ブロック消去が64Kバイ
ト単位で可能な2M×8ビットのフラッシュメモリが使
用される。そして、同図に示すように、各物理ブロック
に「0」から「1F」と順に番号(16進数)を付け
る。
【0059】図14には、ヘッダ領域の内容例が示され
ており、その1バイト目が図15[B]に示されてい
る。これらの図に示すように、ヘッダ領域の1バイト目
には、有効/遷移中/無効,初期化完了状態,予約の各
フラグがある。これらのうち、有効/遷移中/無効のフ
ラグは、この物理ブロックが、有効状態か,それとも有
効から無効になる遷移中(過渡)の状態か,完全に無効
になった状態かを示す。初期化完了フラグは、ブロック
イレース後にブロックヘッダの初期化(フォーマット)
が完了したことを示す。予約のフラグあるいは2バイト
目の予約領域は、システムを拡張する場合に利用される
もので、本発明では特に意味はない。
ており、その1バイト目が図15[B]に示されてい
る。これらの図に示すように、ヘッダ領域の1バイト目
には、有効/遷移中/無効,初期化完了状態,予約の各
フラグがある。これらのうち、有効/遷移中/無効のフ
ラグは、この物理ブロックが、有効状態か,それとも有
効から無効になる遷移中(過渡)の状態か,完全に無効
になった状態かを示す。初期化完了フラグは、ブロック
イレース後にブロックヘッダの初期化(フォーマット)
が完了したことを示す。予約のフラグあるいは2バイト
目の予約領域は、システムを拡張する場合に利用される
もので、本発明では特に意味はない。
【0060】次に、物理ブロックの3バイト目から14
バイト目までは、その物理ブロックに割り当てられてい
るデータファイル名を記録する。なお、データファイル
を特定できるコードや番号など、データファイルを識別
できるものであればよい。例えば、パーティション名や
ディレクトリ名を付随させたデータファイル名でもよ
い。あるいは、パーティション名やディレクトリ名自体
でもよい。つまり、データレコードの特性を活かした管
理の方法を選択すればよい。本実施例では、データファ
イル名として、8.3形式で、MS−DOSのような表
現方法を利用する。
バイト目までは、その物理ブロックに割り当てられてい
るデータファイル名を記録する。なお、データファイル
を特定できるコードや番号など、データファイルを識別
できるものであればよい。例えば、パーティション名や
ディレクトリ名を付随させたデータファイル名でもよ
い。あるいは、パーティション名やディレクトリ名自体
でもよい。つまり、データレコードの特性を活かした管
理の方法を選択すればよい。本実施例では、データファ
イル名として、8.3形式で、MS−DOSのような表
現方法を利用する。
【0061】次に、15バイト目,16バイト目には、
その物理ブロックの後ブロックポインタの開始アドレス
が格納される。本例では、例えば「0x0088」を記
録する。次に、17バイト目から138バイト目までは
前ブロックポインタ管理情報の格納領域で、139バイ
ト目から256バイト目までは後ブロックポインタ管理
情報の格納エリアとなる。前ブロックポインタは2バイ
ト構成で、有効/無効/未格納のいずれであるかを示す
フラグ,及び先頭/中間/最終のいずれのブロックであ
るかを示すフラグの管理情報と、ブロックポインタの番
号(16進数)を格納する記憶領域からなる。後ブロッ
クポインタも同様に2バイト構成で、有効/無効/未格
納のいずれであるかを示すフラグ,及び先頭/中間/最
終のいずれのブロックであるかを示すフラグの管理情報
と、ブロックポインタの番号(16進数)を格納する記
憶領域からなる。
その物理ブロックの後ブロックポインタの開始アドレス
が格納される。本例では、例えば「0x0088」を記
録する。次に、17バイト目から138バイト目までは
前ブロックポインタ管理情報の格納領域で、139バイ
ト目から256バイト目までは後ブロックポインタ管理
情報の格納エリアとなる。前ブロックポインタは2バイ
ト構成で、有効/無効/未格納のいずれであるかを示す
フラグ,及び先頭/中間/最終のいずれのブロックであ
るかを示すフラグの管理情報と、ブロックポインタの番
号(16進数)を格納する記憶領域からなる。後ブロッ
クポインタも同様に2バイト構成で、有効/無効/未格
納のいずれであるかを示すフラグ,及び先頭/中間/最
終のいずれのブロックであるかを示すフラグの管理情報
と、ブロックポインタの番号(16進数)を格納する記
憶領域からなる。
【0062】次に、図15[B]を参照して、ブロック
イレースの手順を説明する。フラッシュ管理マネージャ
9の判定により、フラッシュメモリ2にブロックイレー
ス命令が出されたとき(ステップS1)、該当する物理
ブロックのブロックイレースが行われる(ステップS
2)。ブロックイレースを行なった直後、イレースされ
た物理フロックの記憶エリアのデータの値は、すべて
「FFh」となっている。この後すぐに、フラッシュ管
理マネージャ9による初期化(フォーマット)操作によ
って(ステップS3)、ビット4が論理値の「0」とな
り、この記憶エリア(1バイト目)のデータの値は「F
Fh」から「EFh」に遷移する。そして、新たにこの
物理ブロックへの使用要求によってフラッシュ管理マネ
ージャ9がデータの割当てを行なったとすると(ステッ
プS4)、ビット7に論理値の「0」を書き込む。これ
によって、この記憶エリアのデータの値は、「EFh」
から「6Fh」に遷移する。更に、フラッシュ管理マネ
ージャ9がこの物理ブロックの無効要求を認めれば(ス
テップS5)、ビット6に論理値の「0」を書き込み、
この記憶エリアのデータの値は「6Fh」から「2F
h」に遷移する。
イレースの手順を説明する。フラッシュ管理マネージャ
9の判定により、フラッシュメモリ2にブロックイレー
ス命令が出されたとき(ステップS1)、該当する物理
ブロックのブロックイレースが行われる(ステップS
2)。ブロックイレースを行なった直後、イレースされ
た物理フロックの記憶エリアのデータの値は、すべて
「FFh」となっている。この後すぐに、フラッシュ管
理マネージャ9による初期化(フォーマット)操作によ
って(ステップS3)、ビット4が論理値の「0」とな
り、この記憶エリア(1バイト目)のデータの値は「F
Fh」から「EFh」に遷移する。そして、新たにこの
物理ブロックへの使用要求によってフラッシュ管理マネ
ージャ9がデータの割当てを行なったとすると(ステッ
プS4)、ビット7に論理値の「0」を書き込む。これ
によって、この記憶エリアのデータの値は、「EFh」
から「6Fh」に遷移する。更に、フラッシュ管理マネ
ージャ9がこの物理ブロックの無効要求を認めれば(ス
テップS5)、ビット6に論理値の「0」を書き込み、
この記憶エリアのデータの値は「6Fh」から「2F
h」に遷移する。
【0063】デフラグメンテーション操作により使用可
能領域の拡大を図る際、フラッシュ管理マネージャ9の
機能により、物理ブロックにはコピー元,コピー先,ム
ーブなどのような遷移中の状態が存在する。本形態では
特に、前後のブロックポインタの格納エリアがいっぱい
にならないように配慮しなければならないため、このよ
うな物理ブロックをコピーする手段では最適である。物
理ブロックを有効な状態から遷移中の状態にするには、
ビット5を論理値の「0」にし、この記憶エリアのデー
タの値を「6Fh」から「4Fh」に遷移させればよい
(ステップS4からS6)。このような遷移中の状態が
存在することは、遷移に要する時間が少ないことの他
に、電池の消耗に代表されるような電源異常による動作
の不安定や、カード型フラッシュメモリが外されたとき
などにおける安全性を高めるためである。このように遷
移段階の状態を管理することで、故障・事故などによる
データの消失が最小限に抑えられ、復旧させるための情
報が提供される。
能領域の拡大を図る際、フラッシュ管理マネージャ9の
機能により、物理ブロックにはコピー元,コピー先,ム
ーブなどのような遷移中の状態が存在する。本形態では
特に、前後のブロックポインタの格納エリアがいっぱい
にならないように配慮しなければならないため、このよ
うな物理ブロックをコピーする手段では最適である。物
理ブロックを有効な状態から遷移中の状態にするには、
ビット5を論理値の「0」にし、この記憶エリアのデー
タの値を「6Fh」から「4Fh」に遷移させればよい
(ステップS4からS6)。このような遷移中の状態が
存在することは、遷移に要する時間が少ないことの他
に、電池の消耗に代表されるような電源異常による動作
の不安定や、カード型フラッシュメモリが外されたとき
などにおける安全性を高めるためである。このように遷
移段階の状態を管理することで、故障・事故などによる
データの消失が最小限に抑えられ、復旧させるための情
報が提供される。
【0064】フラッシュメモリの消去回数を削減するた
めには、可能な限りデータファイルのセグメント内のデ
ータレコードを有効に活用し、データの中身の書き換え
を行なわない方がよい。すなわち、実際のデータの書き
換えを行なわず、論理データの変更を行い、セグメント
情報の更新を行なう方がよく、前ブロックポインタのス
テータス/そのブロックポインタのデータや、後ブロッ
クポインタのステータス/そのブロックボインタのデー
タを更新すればよい。そこで、この情報を追記すること
により、データの更新を行なう。
めには、可能な限りデータファイルのセグメント内のデ
ータレコードを有効に活用し、データの中身の書き換え
を行なわない方がよい。すなわち、実際のデータの書き
換えを行なわず、論理データの変更を行い、セグメント
情報の更新を行なう方がよく、前ブロックポインタのス
テータス/そのブロックポインタのデータや、後ブロッ
クポインタのステータス/そのブロックボインタのデー
タを更新すればよい。そこで、この情報を追記すること
により、データの更新を行なう。
【0065】ヘッダ領域の1バイト目の各フラグは図1
5[B]に示した通りであり、それらの実際上のビット
割付例を示すと、以下の表1[A]のようになる。ブロ
ックホインタのステータス情報の内容は、例えば図15
[C]に示すようになる。これに対応するブロックポイ
ンタのデータとして、指し示す物理ブロックの番号を記
録する。表1[B],[C],[D]は、ブロックポイ
ンタのステータス情報の内容のビット割り付け例を示し
ている。当初は、図15[A]に示したようにデータが
「FFh」なので、それに対するブロックポインタは未
格納と判断する。表1[B]は、ビット7とビット6を
使用して、そのステータスとそれに対するデータの未格
納/有効/無効のフラグ情報を割り付ける場合を示す。
ビット7が論理値の「0」,ビット6が論理値の「1」
のとき、それに対するブロックポインタは有効と判断す
る。逆に、ビット7が「1」,ビット6が「0」又はビ
ット7が「0」,ビット6が「0」のとき、それに対す
るブロックポインタは無効と判断する。現実的には、ス
テータスは有効から無効になるので、ビット6が「0」
になれば無効と判断する。表1[C]は、ビット5,ビ
ット4を使用し、未格納/先頭/中間/最終のフラグ情
報を割り付けて、その物理ブロック(セグメント)の情
報を取得する場合を示す。表1[D]は、ビット1,ビ
ット0を使用し、未格納/前ブロックポインタ/無効ブ
ロックポインタ/後ブロックポインタを指し示す情報の
フラグを割りつける場合を示す。これらの情報により、
前後のブロックポインタのステータス情報の内容を読み
取ることができる。
5[B]に示した通りであり、それらの実際上のビット
割付例を示すと、以下の表1[A]のようになる。ブロ
ックホインタのステータス情報の内容は、例えば図15
[C]に示すようになる。これに対応するブロックポイ
ンタのデータとして、指し示す物理ブロックの番号を記
録する。表1[B],[C],[D]は、ブロックポイ
ンタのステータス情報の内容のビット割り付け例を示し
ている。当初は、図15[A]に示したようにデータが
「FFh」なので、それに対するブロックポインタは未
格納と判断する。表1[B]は、ビット7とビット6を
使用して、そのステータスとそれに対するデータの未格
納/有効/無効のフラグ情報を割り付ける場合を示す。
ビット7が論理値の「0」,ビット6が論理値の「1」
のとき、それに対するブロックポインタは有効と判断す
る。逆に、ビット7が「1」,ビット6が「0」又はビ
ット7が「0」,ビット6が「0」のとき、それに対す
るブロックポインタは無効と判断する。現実的には、ス
テータスは有効から無効になるので、ビット6が「0」
になれば無効と判断する。表1[C]は、ビット5,ビ
ット4を使用し、未格納/先頭/中間/最終のフラグ情
報を割り付けて、その物理ブロック(セグメント)の情
報を取得する場合を示す。表1[D]は、ビット1,ビ
ット0を使用し、未格納/前ブロックポインタ/無効ブ
ロックポインタ/後ブロックポインタを指し示す情報の
フラグを割りつける場合を示す。これらの情報により、
前後のブロックポインタのステータス情報の内容を読み
取ることができる。
【0066】
【表1】
【0067】図16,図17は、ブロックポインタのス
テータス情報の更新の様子を示している。図16[A]
は、初めて前ブロックポインタの情報を格納している様
子であり、図16[B]は、図16[A]から更新前の
前ブロックポインタを無効にして新たな前ブロックポイ
ンタを更新したときの様子を示している。また、図16
[C]は、図16[B]から更新前の前ブロックポイン
タを無効にして新たな前ブロックポインタを更新したと
きの様子を示している。このように、前ブロックポイン
タ[0h]が無効のときは[1h]となり、[1h]が
無効のときは[2h]となるという具合に、可能な限り
更新情報を連鎖させていく。同様に、後ブロックポイン
タの更新の様子を図17[A],図17[B]、図17
[C]にそれぞれ示す。このように、後ブロックポイン
タ[0h]が無効のときは[1h]となり、[1h]が
無効のときは[2h]となるという具合に、可能な限り
更新情報を連鎖させていく。ここで、ブロックポインタ
が無効であると判断するには、そのブロックポインタの
ステータス情報が無効かどうかを判定すればよい。
テータス情報の更新の様子を示している。図16[A]
は、初めて前ブロックポインタの情報を格納している様
子であり、図16[B]は、図16[A]から更新前の
前ブロックポインタを無効にして新たな前ブロックポイ
ンタを更新したときの様子を示している。また、図16
[C]は、図16[B]から更新前の前ブロックポイン
タを無効にして新たな前ブロックポインタを更新したと
きの様子を示している。このように、前ブロックポイン
タ[0h]が無効のときは[1h]となり、[1h]が
無効のときは[2h]となるという具合に、可能な限り
更新情報を連鎖させていく。同様に、後ブロックポイン
タの更新の様子を図17[A],図17[B]、図17
[C]にそれぞれ示す。このように、後ブロックポイン
タ[0h]が無効のときは[1h]となり、[1h]が
無効のときは[2h]となるという具合に、可能な限り
更新情報を連鎖させていく。ここで、ブロックポインタ
が無効であると判断するには、そのブロックポインタの
ステータス情報が無効かどうかを判定すればよい。
【0068】以上のような構造の物理ブロックヘッダを
用いてフラッシュファイル管理システムを実現する。フ
ラッシュ管理マネージャ9はOSやアプリケーションプ
ログラム等の要求により、データファイルのなどの読み
出し,書き込みを制御する。まず、書き込みに際して
は、フラッシュメモリ2の特徴として書き込み遅延の影
響がある。このため、オーバヘッドを少なくし、効率的
に書き込みを行なうためには、データレコードをデータ
ファイル内に追記していく方式を取ることになる。この
方式を実行するためには、書き換え前の旧データレコー
ドと書き換え後のデータレコードが論理的には変更され
ているが、物理的には旧データレコードが無効となり、
新データレコードがそのデータファイルに追記されるこ
とになる。つまり、物理的には無効とされた旧データレ
コードと新データレコードがデータファイル内に共に存
在するものの、旧データレコードに無効フラグを記すこ
とによって論理的に削除することになる。
用いてフラッシュファイル管理システムを実現する。フ
ラッシュ管理マネージャ9はOSやアプリケーションプ
ログラム等の要求により、データファイルのなどの読み
出し,書き込みを制御する。まず、書き込みに際して
は、フラッシュメモリ2の特徴として書き込み遅延の影
響がある。このため、オーバヘッドを少なくし、効率的
に書き込みを行なうためには、データレコードをデータ
ファイル内に追記していく方式を取ることになる。この
方式を実行するためには、書き換え前の旧データレコー
ドと書き換え後のデータレコードが論理的には変更され
ているが、物理的には旧データレコードが無効となり、
新データレコードがそのデータファイルに追記されるこ
とになる。つまり、物理的には無効とされた旧データレ
コードと新データレコードがデータファイル内に共に存
在するものの、旧データレコードに無効フラグを記すこ
とによって論理的に削除することになる。
【0069】このような操作をフラッシュファイルシス
テム上で繰り返すと、データファイル内に論理的な無効
データレコードが多数存在することになる。場合によっ
ては、新規の未割当てのデータファイル領域がなくなる
危険性すらある。このことを避けるために、フラッシュ
管理マネージャ9は、データの無効化を定期的に検知し
てデフラグメンテーションの操作を行ない、効率よく未
割当てのデータファイル領域を拡大し、確保する。
テム上で繰り返すと、データファイル内に論理的な無効
データレコードが多数存在することになる。場合によっ
ては、新規の未割当てのデータファイル領域がなくなる
危険性すらある。このことを避けるために、フラッシュ
管理マネージャ9は、データの無効化を定期的に検知し
てデフラグメンテーションの操作を行ない、効率よく未
割当てのデータファイル領域を拡大し、確保する。
【0070】データファイル領域としての物理ブロック
の割当ては、フラッシュ管理マネージャ9が行なう。こ
のとき、OSやアプリケーションプログラムの要求によ
ってデータファイル領域を与えることになる。本実施例
では、図5に示したように、論理的なデータファイル内
のデータレコードDRに、データレコードヘッダDRH
とデータレコードフッダDRFを付加して物理的なデー
タファイルを構成するとともに、それをスパンドレコー
ドとしてセグメント化し、データを格納する。すなわ
ち、論理的なデータファイルにデータレコードDRを追
加するとき、その追加されたデータレコードDRにデー
タレコードヘッダDRHとデータレコードフッダDRF
を付加し、そのパケットDRPを物理的なデータファイ
ルとしてその後に追記していく。そして、同様にセグメ
ント化してデータを格納する。データレコードを追加し
ていくときは、以上の操作を繰り返す。
の割当ては、フラッシュ管理マネージャ9が行なう。こ
のとき、OSやアプリケーションプログラムの要求によ
ってデータファイル領域を与えることになる。本実施例
では、図5に示したように、論理的なデータファイル内
のデータレコードDRに、データレコードヘッダDRH
とデータレコードフッダDRFを付加して物理的なデー
タファイルを構成するとともに、それをスパンドレコー
ドとしてセグメント化し、データを格納する。すなわ
ち、論理的なデータファイルにデータレコードDRを追
加するとき、その追加されたデータレコードDRにデー
タレコードヘッダDRHとデータレコードフッダDRF
を付加し、そのパケットDRPを物理的なデータファイ
ルとしてその後に追記していく。そして、同様にセグメ
ント化してデータを格納する。データレコードを追加し
ていくときは、以上の操作を繰り返す。
【0071】また、データファイル内のデータレコード
DRを削除するときは、データレコードDRを削除する
ことをフラッシュ管理マネージャ9に知らせ、データレ
コードのパケットDRPを無効化する。このときの無効
化は、データレコードヘッダDRHあるいはフッダDR
Fにマーキングすることで行われる。これによって、デ
ータレコードDRは論理的に削除することができるが、
物理的に削除することにはならない。物理的に削除する
ためには、物理ブロック内のデータファイル領域に格納
されているデータがすべて無効のときにのみに可能であ
る。そして、この無効後にブロックイレースと初期化を
行なえばよい。しかし、フラッシュ管理マネージャ9
が、データファイル内のセグメントですべて無効なデー
タレコードになるまで待つことは、システムの停止を招
くことになる。このようにならないためには、上述のデ
フラグメンテーションの操作を実行すべきである。ただ
し、デフラグメンテーションの操作の実行やそのアルゴ
リスムは、データレコードの構造に密接に関係するの
で、その最適な方法を見出す必要がある。
DRを削除するときは、データレコードDRを削除する
ことをフラッシュ管理マネージャ9に知らせ、データレ
コードのパケットDRPを無効化する。このときの無効
化は、データレコードヘッダDRHあるいはフッダDR
Fにマーキングすることで行われる。これによって、デ
ータレコードDRは論理的に削除することができるが、
物理的に削除することにはならない。物理的に削除する
ためには、物理ブロック内のデータファイル領域に格納
されているデータがすべて無効のときにのみに可能であ
る。そして、この無効後にブロックイレースと初期化を
行なえばよい。しかし、フラッシュ管理マネージャ9
が、データファイル内のセグメントですべて無効なデー
タレコードになるまで待つことは、システムの停止を招
くことになる。このようにならないためには、上述のデ
フラグメンテーションの操作を実行すべきである。ただ
し、デフラグメンテーションの操作の実行やそのアルゴ
リスムは、データレコードの構造に密接に関係するの
で、その最適な方法を見出す必要がある。
【0072】次に、図18〜図22を参照して、以上の
ようなデフラグメンテーションの−例を説明する。論理
的なデータファイルの各データレコードDRにデータレ
コードヘッダDRH及びフッダDRFを付加して物理的
なデータファイルを構成し、そのデータをスパンドレコ
ードとして取り扱う。そして、64K−256バイト毎
にセグメント化し、そのセグメント化したデータを物理
ブロックのデータファイル領域に格納する。図18に
は、この物理的なデータファイルをセグメント化した様
子が示されている。セグメント化したデータブロックを
識別するために、各ブロックに「A」から「I」までの
呼称を順につける。これらのセグメントA〜Iを、フラ
ッシュメモリ2の物理ブロックに1対1で割り当てる。
ようなデフラグメンテーションの−例を説明する。論理
的なデータファイルの各データレコードDRにデータレ
コードヘッダDRH及びフッダDRFを付加して物理的
なデータファイルを構成し、そのデータをスパンドレコ
ードとして取り扱う。そして、64K−256バイト毎
にセグメント化し、そのセグメント化したデータを物理
ブロックのデータファイル領域に格納する。図18に
は、この物理的なデータファイルをセグメント化した様
子が示されている。セグメント化したデータブロックを
識別するために、各ブロックに「A」から「I」までの
呼称を順につける。これらのセグメントA〜Iを、フラ
ッシュメモリ2の物理ブロックに1対1で割り当てる。
【0073】例えば、この割当ての1例として、セグメ
ントと物理ブロックの対比が以下の表2[A]の通りな
らば、物理ブロックとセグメントの関係は図19[A]
のようになる。この例は、あくまで、物理ブロック0か
ら物理ブロック8の間にセグメントを割り当てただけで
あり、物理ブロックの割当てに当たってセグメントの連
続編成を行う必要はない。また、当然のことながら、物
理ブロック0から物理ブロック8以外の使用可能な物理
フロックを割り当てることもできる。つまり、フラッシ
ュメモリ2の物理ブロック中から未使用の物理ブロック
を任意に割り当てることができる。
ントと物理ブロックの対比が以下の表2[A]の通りな
らば、物理ブロックとセグメントの関係は図19[A]
のようになる。この例は、あくまで、物理ブロック0か
ら物理ブロック8の間にセグメントを割り当てただけで
あり、物理ブロックの割当てに当たってセグメントの連
続編成を行う必要はない。また、当然のことながら、物
理ブロック0から物理ブロック8以外の使用可能な物理
フロックを割り当てることもできる。つまり、フラッシ
ュメモリ2の物理ブロック中から未使用の物理ブロック
を任意に割り当てることができる。
【0074】
【表2】
【0075】図19[A]の例は、その物理ブロックの
中におけるセグメントの前後関係を、前ブロックポイン
タや後ブロックポインタなどで、情報の−部としてブロ
ックヘッダに記憶している例である。フラッシュ管理マ
ネージャ9は、このブロックヘッダを読み取り、セグメ
ントがバラバラに配置されている状態においても、デー
タファイルのセグメントを繋ぎ合わせて、論理的なデー
タファイルを構築することができる。また、前後のブロ
ックポインタを変更することにより、各物理ブロックの
連鎖構造を論理的に変更することができる。これによっ
て、フラッシュメモリ2の大幅な書き換え操作を削減す
ることができる。
中におけるセグメントの前後関係を、前ブロックポイン
タや後ブロックポインタなどで、情報の−部としてブロ
ックヘッダに記憶している例である。フラッシュ管理マ
ネージャ9は、このブロックヘッダを読み取り、セグメ
ントがバラバラに配置されている状態においても、デー
タファイルのセグメントを繋ぎ合わせて、論理的なデー
タファイルを構築することができる。また、前後のブロ
ックポインタを変更することにより、各物理ブロックの
連鎖構造を論理的に変更することができる。これによっ
て、フラッシュメモリ2の大幅な書き換え操作を削減す
ることができる。
【0076】次に、システムの初期段階に多く見られる
ようなデータファイルの物理的な格納例を示す。この例
は、後で述べるデータの修正・変更・追加を具体的に明
示できるようになる。前記表2[B]のようにデータフ
ァイルの各セグメントをそれぞれ物理ブロックに割り当
て、セグメントA〜Iに対して順に物理ブロック0〜8
までを割り振ったとすると、各セグメントと各物理ブロ
ック,フロックヘッダ内の有効な前ブロックポインタや
有効な後ブロックポインタなどは、図19[B]のよう
になる。
ようなデータファイルの物理的な格納例を示す。この例
は、後で述べるデータの修正・変更・追加を具体的に明
示できるようになる。前記表2[B]のようにデータフ
ァイルの各セグメントをそれぞれ物理ブロックに割り当
て、セグメントA〜Iに対して順に物理ブロック0〜8
までを割り振ったとすると、各セグメントと各物理ブロ
ック,フロックヘッダ内の有効な前ブロックポインタや
有効な後ブロックポインタなどは、図19[B]のよう
になる。
【0077】このように、物理ブロックのブロックヘッ
ダ内の前ブロックポインタや後ブロックポインタの内容
によって物理的なデータファイルのセグメントへのデー
タ変換の構造になるため、フラッシュ管理マネージャ9
はブロックヘッダの内容を解析し、鎖構造を作る必要が
ある。また、フラッシュ管理マネージャ9は、物理的な
データファイルのデータをセグメントに分割し、物理ブ
ロックに割り当てを行なう。つまり、フラッシュ管理マ
ネージャ9は、該当する物理的なデータファイル内の各
セグメントを持つ各物理ブロックのブロックヘッダの情
報から、まず、前ブロックポインタが「HEAD」とな
る物理ブロックを検索する。その後、その前ブロックポ
インタが「HEAD」となっている物理ブロックの後ブ
ロックポインタを参照し、それに示されている物理ブロ
ックにおけるブロックヘッダの前ブロックポインタを検
索する。ここで、後ブロックポインタに示された値と、
そのポインタを示すブロックの前ブロックポインタが−
致しない場合は、ブロック構造関係の矛盾となり、その
データファイルは破壊されていることになる。このた
め、前ブロックポインタや後ブロックポインタの管理は
重要となる。
ダ内の前ブロックポインタや後ブロックポインタの内容
によって物理的なデータファイルのセグメントへのデー
タ変換の構造になるため、フラッシュ管理マネージャ9
はブロックヘッダの内容を解析し、鎖構造を作る必要が
ある。また、フラッシュ管理マネージャ9は、物理的な
データファイルのデータをセグメントに分割し、物理ブ
ロックに割り当てを行なう。つまり、フラッシュ管理マ
ネージャ9は、該当する物理的なデータファイル内の各
セグメントを持つ各物理ブロックのブロックヘッダの情
報から、まず、前ブロックポインタが「HEAD」とな
る物理ブロックを検索する。その後、その前ブロックポ
インタが「HEAD」となっている物理ブロックの後ブ
ロックポインタを参照し、それに示されている物理ブロ
ックにおけるブロックヘッダの前ブロックポインタを検
索する。ここで、後ブロックポインタに示された値と、
そのポインタを示すブロックの前ブロックポインタが−
致しない場合は、ブロック構造関係の矛盾となり、その
データファイルは破壊されていることになる。このた
め、前ブロックポインタや後ブロックポインタの管理は
重要となる。
【0078】フラッシュ管理マネージャ9は、物理的な
データファイル内の各セグメントの物理ブロックでブロ
ックヘッダ内の前ブロックポインタとして「HEAD」
を持っているブロックを検索し、その後ブロックポイン
タに示されている物理ブロックのブロックヘッダの情報
をもとにチェインしていく。そして、最後に後ブロック
ポインタに「TAIL」となっているところで、このチ
ェインは終了し、1つの物理的なデータファイルのデー
タとして完結する。
データファイル内の各セグメントの物理ブロックでブロ
ックヘッダ内の前ブロックポインタとして「HEAD」
を持っているブロックを検索し、その後ブロックポイン
タに示されている物理ブロックのブロックヘッダの情報
をもとにチェインしていく。そして、最後に後ブロック
ポインタに「TAIL」となっているところで、このチ
ェインは終了し、1つの物理的なデータファイルのデー
タとして完結する。
【0079】次に、セグメントの削除について説明す
る。フラッシュメモリの特性により、RAMのように簡
単にデータの修正・変更はできない。そこで、セグメン
トの削除は、1つの物理ブロックのデータファイル領域
単位で行うことにする。システムの物理的なデータファ
イル内においてセグメント単位での削除を矛盾なく行な
うということを前提にして、次のような例を想定する。
図18[A]において、セグメントEを削除する場合に
は、図20[A]に示すように、セグメントEを論理上
から削除し、セグメントDの後がセグメントFとなるよ
うににする。なお、図20中において、変更箇所には矢
印が付されている(図21も同様)。
る。フラッシュメモリの特性により、RAMのように簡
単にデータの修正・変更はできない。そこで、セグメン
トの削除は、1つの物理ブロックのデータファイル領域
単位で行うことにする。システムの物理的なデータファ
イル内においてセグメント単位での削除を矛盾なく行な
うということを前提にして、次のような例を想定する。
図18[A]において、セグメントEを削除する場合に
は、図20[A]に示すように、セグメントEを論理上
から削除し、セグメントDの後がセグメントFとなるよ
うににする。なお、図20中において、変更箇所には矢
印が付されている(図21も同様)。
【0080】データ構造としては図20[A]で示す通
りの構造であるが、これが物理ブロックでは、図19
[B]に示す構造から図20[B]に示す構造に変更す
る。この構造変更は、物理ブロックEを削除することで
あるが、この削除の方法は、物理ブロックEのブロック
ヘッダに削除のマーキングをすることによって行う。こ
れにより、高速に削除を行うことができるとともに、物
理的なデータファイルのセグメントと物理ブロックのデ
ータ構造の整合性を保つことができる。その後、物理ブ
ロック4を初期化(ブロックイレース後ブロックヘッダ
に必要情報を格納する)すればよい。
りの構造であるが、これが物理ブロックでは、図19
[B]に示す構造から図20[B]に示す構造に変更す
る。この構造変更は、物理ブロックEを削除することで
あるが、この削除の方法は、物理ブロックEのブロック
ヘッダに削除のマーキングをすることによって行う。こ
れにより、高速に削除を行うことができるとともに、物
理的なデータファイルのセグメントと物理ブロックのデ
ータ構造の整合性を保つことができる。その後、物理ブ
ロック4を初期化(ブロックイレース後ブロックヘッダ
に必要情報を格納する)すればよい。
【0081】次に、物理的なデータファイルにおけるセ
グメントの削除とセグメントの新規追加の例を説明す
る。図20[A]の物理的なデータファイルのデータ構
造において、セグメントCを削除し、その後、新たにセ
グメントKを追記する場合の操作を、図21[A]を用
いて説明する。まず、最初に図20[A]の状態から、
セグメントCの削除を行なう。次にその状態から、変更
前の最後のセグメントIの後にセグメントKを追加す
る。これにより、変更後の最終セグメントはセグメント
Kとなる。
グメントの削除とセグメントの新規追加の例を説明す
る。図20[A]の物理的なデータファイルのデータ構
造において、セグメントCを削除し、その後、新たにセ
グメントKを追記する場合の操作を、図21[A]を用
いて説明する。まず、最初に図20[A]の状態から、
セグメントCの削除を行なう。次にその状態から、変更
前の最後のセグメントIの後にセグメントKを追加す
る。これにより、変更後の最終セグメントはセグメント
Kとなる。
【0082】この−連の操作を順に詳述すると、まず最
初に、フラッシュ管理マネージャ9は、物理ブロック4
が無効になっていることを検知し、この物理ブロック4
のブロックイレースと初期化を行なう。この初期化と
は、簡単に言うと物理ブロックのブロックイレースとそ
の物理ブロックのもつ情報をブロックヘッダへ書き込む
ことである。これらのシーケンスを物理ブロックに置き
換えて示すと、図21[B]の通りである。同図のよう
に、最初に、物理ブロック4のブロックイレースとその
物理ブロックの情報を更新し、新たにその内容をその物
理ブロックのブロックヘッダに書き込む。
初に、フラッシュ管理マネージャ9は、物理ブロック4
が無効になっていることを検知し、この物理ブロック4
のブロックイレースと初期化を行なう。この初期化と
は、簡単に言うと物理ブロックのブロックイレースとそ
の物理ブロックのもつ情報をブロックヘッダへ書き込む
ことである。これらのシーケンスを物理ブロックに置き
換えて示すと、図21[B]の通りである。同図のよう
に、最初に、物理ブロック4のブロックイレースとその
物理ブロックの情報を更新し、新たにその内容をその物
理ブロックのブロックヘッダに書き込む。
【0083】次に、セグメントCを削除するために、物
理ブロック2のブロックヘッダに削除のマーキングを行
なう。更に、各物理ブロックのチェイン構造に従って、
前ブロックポインタや後ブロックポインタ等のブロック
ヘッダの内容をそれぞれ書き換える。そして、フラッシ
ュ管理マネージャ9がセグメントKを物理ブロック4に
割り当てたとすると、ブロック8とブロック4のそれぞ
れの前ブロックポインタや後ブロックポインタなどのブ
ロックヘッダの情報を対応して書き換える。そして新た
に、物理ブロック4にセグメントKのデータの内容を書
き込む。これによって得られた物理ブロック構造は、図
21[B]のようになる。
理ブロック2のブロックヘッダに削除のマーキングを行
なう。更に、各物理ブロックのチェイン構造に従って、
前ブロックポインタや後ブロックポインタ等のブロック
ヘッダの内容をそれぞれ書き換える。そして、フラッシ
ュ管理マネージャ9がセグメントKを物理ブロック4に
割り当てたとすると、ブロック8とブロック4のそれぞ
れの前ブロックポインタや後ブロックポインタなどのブ
ロックヘッダの情報を対応して書き換える。そして新た
に、物理ブロック4にセグメントKのデータの内容を書
き込む。これによって得られた物理ブロック構造は、図
21[B]のようになる。
【0084】このような削除・消去の操作によってセグ
メントの構造を変化させていくと、物理ブロックでは、
実際の前後の物理ブロック間でのチェイン構造はほとん
どなくなるが、論理的なデータ構造自体はブロックヘッ
ダによってフラッシュ管理マネージャ9により管理で
き、データレコードヘッダ,データレコードフッダをデ
フロッキングすれば、アプリケーションプログラムから
はフラッシュ管理マネージャを通して論理的なデータレ
コードとして認識可能である。図18のセグメント構造
が、ブロック0から順に、D、E、A、C、B、I、
H、G、Fとなっているときは、図22[A]のような
ブロックヘッダの内容になる。図18のセグメント構造
が、ブロック0から順に、G、A、I、B、C、F、
E、H、Dとなっているときは、図22[B]のような
ブロックヘッダの内容になる。
メントの構造を変化させていくと、物理ブロックでは、
実際の前後の物理ブロック間でのチェイン構造はほとん
どなくなるが、論理的なデータ構造自体はブロックヘッ
ダによってフラッシュ管理マネージャ9により管理で
き、データレコードヘッダ,データレコードフッダをデ
フロッキングすれば、アプリケーションプログラムから
はフラッシュ管理マネージャを通して論理的なデータレ
コードとして認識可能である。図18のセグメント構造
が、ブロック0から順に、D、E、A、C、B、I、
H、G、Fとなっているときは、図22[A]のような
ブロックヘッダの内容になる。図18のセグメント構造
が、ブロック0から順に、G、A、I、B、C、F、
E、H、Dとなっているときは、図22[B]のような
ブロックヘッダの内容になる。
【0085】以上のように、物理的なデータファイル構
造は、(64K−256)バイトのセグメント単位で分
割され、各物理ブロックに格納されていく。つまり、先
頭のブロックヘッダの前ブロックポインタ部分にあるH
EADマーカと、後ブロックポインタを検索することに
より、物理ブロックのチェイン構造が順次検出されて、
1つのデータファイルが構成されていく。−連のデータ
ファイルは、後ポインタがTAILマーカのときに終わ
りとなる。このTAILマーカを書き換えて、次の物理
ブロックを後ブロックポインタで指定すれば追記可能で
あり、チェイン構造はどんどん膨らんでいく。
造は、(64K−256)バイトのセグメント単位で分
割され、各物理ブロックに格納されていく。つまり、先
頭のブロックヘッダの前ブロックポインタ部分にあるH
EADマーカと、後ブロックポインタを検索することに
より、物理ブロックのチェイン構造が順次検出されて、
1つのデータファイルが構成されていく。−連のデータ
ファイルは、後ポインタがTAILマーカのときに終わ
りとなる。このTAILマーカを書き換えて、次の物理
ブロックを後ブロックポインタで指定すれば追記可能で
あり、チェイン構造はどんどん膨らんでいく。
【0086】OSやアプリケーションからの要求によ
り、フラッシュ管理マネージャ9は、データファイルに
対してデータの書き込みや読み出しの操作を行なうこと
になる。読み出しの場合は、フラッシュ管理マネージャ
9にはフラッシュメモリ2の読み出しを行なう旨が要求
される。許可確認後、物理的なデータファイル内のデー
タレコードパケットがデブロッキングされ、論理的なデ
ータレコードとして扱われるようになる。また、書き込
みの場合、フラッシュ管理マネージャ9にはフラッシュ
メモリ2への書き込みを行なう旨が要求される。許可確
認後、論理的なデータレコードがパケット化され、後段
のセグメントにデータレコードパケットとして追記され
る。データの書き換えは、物理的にデータレコードパケ
ットを無効化し、新たに追記することによって実現され
る。ただし、物理的にメモリエリアは縮小する。この場
合のデータのブロッキング方法は、従来技術により実現
されている。
り、フラッシュ管理マネージャ9は、データファイルに
対してデータの書き込みや読み出しの操作を行なうこと
になる。読み出しの場合は、フラッシュ管理マネージャ
9にはフラッシュメモリ2の読み出しを行なう旨が要求
される。許可確認後、物理的なデータファイル内のデー
タレコードパケットがデブロッキングされ、論理的なデ
ータレコードとして扱われるようになる。また、書き込
みの場合、フラッシュ管理マネージャ9にはフラッシュ
メモリ2への書き込みを行なう旨が要求される。許可確
認後、論理的なデータレコードがパケット化され、後段
のセグメントにデータレコードパケットとして追記され
る。データの書き換えは、物理的にデータレコードパケ
ットを無効化し、新たに追記することによって実現され
る。ただし、物理的にメモリエリアは縮小する。この場
合のデータのブロッキング方法は、従来技術により実現
されている。
【0087】物理ブロックのデータファイル領域内です
べてのデータが無効化された場合、その物理ブロックヘ
ッダの無効フラグをONにすることによって物理ブロッ
ク全体が無効化される。フラッシュ管理マネージャ9は
このことを検知し、その物理ブロックをイレースして初
期化操作を始める。また、デフラグメンテーション操作
により、コピー元のデータファイルが属する物理ブロッ
クヘッダの遷移中フラグをONにする。そして、必要な
データが全部コピーされたなら、その物理ブロックヘッ
ダの無効フラグがONにされ、前述のブロックイレース
・初期化操作が行なわれる。更に、遷移中フラグONか
ら無効フラグONに至るまでの間に何らかの原因によっ
て異常な状態が発生することがある。そこで、システム
が再起動したときなど、それらの状態フラグがフラッシ
ュ管理マネージャ9で監視される。そして、状態を解析
することによって、いずれの状態から停止あるいは異常
となったかが検出され、システムを修復・復旧させる手
助けのための貴重な情報源となる。
べてのデータが無効化された場合、その物理ブロックヘ
ッダの無効フラグをONにすることによって物理ブロッ
ク全体が無効化される。フラッシュ管理マネージャ9は
このことを検知し、その物理ブロックをイレースして初
期化操作を始める。また、デフラグメンテーション操作
により、コピー元のデータファイルが属する物理ブロッ
クヘッダの遷移中フラグをONにする。そして、必要な
データが全部コピーされたなら、その物理ブロックヘッ
ダの無効フラグがONにされ、前述のブロックイレース
・初期化操作が行なわれる。更に、遷移中フラグONか
ら無効フラグONに至るまでの間に何らかの原因によっ
て異常な状態が発生することがある。そこで、システム
が再起動したときなど、それらの状態フラグがフラッシ
ュ管理マネージャ9で監視される。そして、状態を解析
することによって、いずれの状態から停止あるいは異常
となったかが検出され、システムを修復・復旧させる手
助けのための貴重な情報源となる。
【0088】フラッシュ管理マネージャ9は、それぞれ
の物理ブロックの状態を監視し、管理していく。そし
て、OSやアプリケーションプログラムの要求に応じて
該当する物理ブロックを割り当て、有効−>(遷移中)
−>無効−>初期化の状態の監視,管理,実行を行な
う。フラッシュファイルシステムを運用していく中で、
各々物理ブロックの状態の変化としては、初期化−>有
効,有効−>無効,有効−>遷移中,遷移中−>無効,
無効−>初期化,初期化−>無効などが挙げられる。
の物理ブロックの状態を監視し、管理していく。そし
て、OSやアプリケーションプログラムの要求に応じて
該当する物理ブロックを割り当て、有効−>(遷移中)
−>無効−>初期化の状態の監視,管理,実行を行な
う。フラッシュファイルシステムを運用していく中で、
各々物理ブロックの状態の変化としては、初期化−>有
効,有効−>無効,有効−>遷移中,遷移中−>無効,
無効−>初期化,初期化−>無効などが挙げられる。
【0089】[初期化−>有効]:物理ブロックが、初
期化状態からデータファイル領域等として割り当てら
れ、有効フラグがONになった状態で有効となる。
期化状態からデータファイル領域等として割り当てら
れ、有効フラグがONになった状態で有効となる。
【0090】[有効−>無効]:データファイルとして
の物理ブロックが有効で、データ領域内に少なくとも−
つは論理的に有効なデータがある状態から、データ領域
内のすべてが論理的に無効なデータとなったとき、フラ
ッシュ管理マネージャは、その後この物理ブロックの無
効フラグをONとし、物理ブロックの無効化を行なう。
の物理ブロックが有効で、データ領域内に少なくとも−
つは論理的に有効なデータがある状態から、データ領域
内のすべてが論理的に無効なデータとなったとき、フラ
ッシュ管理マネージャは、その後この物理ブロックの無
効フラグをONとし、物理ブロックの無効化を行なう。
【0091】[有効−>遷移中]:少なくとも−つは存
在する論理的に有効なデータレコードパケットを異なる
物理ブロックのデータ領域にコピーするとき、コピー元
となる物理ブロックに対して遷移中フラグをONにす
る。この状態のとき、データレコードパケットがコピー
されていることになる。
在する論理的に有効なデータレコードパケットを異なる
物理ブロックのデータ領域にコピーするとき、コピー元
となる物理ブロックに対して遷移中フラグをONにす
る。この状態のとき、データレコードパケットがコピー
されていることになる。
【0092】[遷移中−>無効]:前述の遷移中の状態
が終了し、物理ブロックが無効となったことを示す。つ
まり、データレコードパケットのコピーが完了し、フラ
ッシュ管理マネージャが無効フラグをONにした状態で
ある。
が終了し、物理ブロックが無効となったことを示す。つ
まり、データレコードパケットのコピーが完了し、フラ
ッシュ管理マネージャが無効フラグをONにした状態で
ある。
【0093】[無効−>初期化]:物理ブロックを無効
な状態からブロックイレースし、物理ブロックヘッダの
初期化が完了したとき、フラッシュ管理マネージャは初
期化フラグをONにする。このとき、物理ブロックヘッ
ダの初期化が完了し、データファイル領域として使用可
能な状態となる。
な状態からブロックイレースし、物理ブロックヘッダの
初期化が完了したとき、フラッシュ管理マネージャは初
期化フラグをONにする。このとき、物理ブロックヘッ
ダの初期化が完了し、データファイル領域として使用可
能な状態となる。
【0094】[初期化−>無効]:物理ブロックが初期
化された状態から無効になった状態を示す。これは、状
態として存在する可能性はあるが、システムとしては多
用すべきではない。
化された状態から無効になった状態を示す。これは、状
態として存在する可能性はあるが、システムとしては多
用すべきではない。
【0095】フラッシュ管理マネージャは、各物理ブロ
ックの状態を管理・監視し、何らかの原因による異常状
態からの脱却後、有効/無効/遷移中/初期化フラグ
を、異常状態以前のデータの復元,復旧のための情報と
して利用する。つまり、これらの変化状態を考慮すれ
ば、システムの停止,異常により、システムの修復やデ
ータレコードパケットの復元を行なうとき、どの状態か
ら異常になったかを検出できる。また、当然、ブロック
ヘッダ内にシステム停止状態の直前のセグメントの連鎖
情報が残っているため、ある程度デ−夕を修復すること
も可能である。
ックの状態を管理・監視し、何らかの原因による異常状
態からの脱却後、有効/無効/遷移中/初期化フラグ
を、異常状態以前のデータの復元,復旧のための情報と
して利用する。つまり、これらの変化状態を考慮すれ
ば、システムの停止,異常により、システムの修復やデ
ータレコードパケットの復元を行なうとき、どの状態か
ら異常になったかを検出できる。また、当然、ブロック
ヘッダ内にシステム停止状態の直前のセグメントの連鎖
情報が残っているため、ある程度デ−夕を修復すること
も可能である。
【0096】この発明には数多くの実施形態があり、以
上の開示に基づいて多様に改変することが可能である。
例えは、次のようなものが含まれる。 (1)前記実施例では、そのブロックポインタのステー
タス情報が最初の格納エリアから順に有効かどうかで、
ブロックポインタが無効であるかどうかを判断してい
る。しかし、その代わりに、ブロックポインタ(ブロッ
クポインタのステータスとブロックポインタのデータの
値)の最終格納エリアから最初の格納エリアに向かって
検索し、その値が「FFFFh」でないところが最新の
情報データと判定するようにしてもよい。
上の開示に基づいて多様に改変することが可能である。
例えは、次のようなものが含まれる。 (1)前記実施例では、そのブロックポインタのステー
タス情報が最初の格納エリアから順に有効かどうかで、
ブロックポインタが無効であるかどうかを判断してい
る。しかし、その代わりに、ブロックポインタ(ブロッ
クポインタのステータスとブロックポインタのデータの
値)の最終格納エリアから最初の格納エリアに向かって
検索し、その値が「FFFFh」でないところが最新の
情報データと判定するようにしてもよい。
【0097】(2)更に、前記(1)の方法と、前記実
施例の方法を組み合わせてもよい。すなわち、通常は前
記実施例のようにブロックポインタが無効であると判断
し、データの後旧・復元を行なう際は、前記(1)のよ
うにブロックポインタが無効であると判断するように切
り替える。また、その逆に、データの後旧・復元を行な
う際は、前記実施例のようにブロックポインタが無効で
あると判断し、通常は前記(1)のようにブロックポイ
ンタが無効であると判断するように切り替える。
施例の方法を組み合わせてもよい。すなわち、通常は前
記実施例のようにブロックポインタが無効であると判断
し、データの後旧・復元を行なう際は、前記(1)のよ
うにブロックポインタが無効であると判断するように切
り替える。また、その逆に、データの後旧・復元を行な
う際は、前記実施例のようにブロックポインタが無効で
あると判断し、通常は前記(1)のようにブロックポイ
ンタが無効であると判断するように切り替える。
【0098】(3)前記実施例のように、同一ブロック
にその管理情報を持たせるという方法ではなく、同一フ
ラッシュメモリ上に管理情報のための領域を別ブロック
に作成し、そこに、それぞれのブロックの管理情報を持
たせても、本発明は同様に適用可能である。
にその管理情報を持たせるという方法ではなく、同一フ
ラッシュメモリ上に管理情報のための領域を別ブロック
に作成し、そこに、それぞれのブロックの管理情報を持
たせても、本発明は同様に適用可能である。
【0099】(4)前記(1),(2)では、図23に
示す通り、ブロックに対してそのブロック内にそのブロ
ックに対する管理情報を持っている。しかし、前記
(3)では、例えば請求項2,3,4,5,6,7又は
8での管理装置にある管理情報をブロック管理情報の体
系から種別管理の体系に変更させる。つまり、種別ごと
に集中管理情報を持たせる。例えば、集中管理情報
(1)として、請求項2の各ブロックの情報を持たせ
る。同様に、集中管理情報(m)には請求項6に記載さ
れているような各ブロックの情報を持たせる。この集中
管理情報は、同一フラッシュメモリ上の別ブロックに格
納させる。このとき、イレース単位のブロックごとに集
中管理情報をそれぞれ格納してもよい。当然、同一ブロ
ックに格納してもかまわない。このように、それぞれブ
ロックの管理情報を個々(同種ごと)に集結させ、同一
のフラッシュメモリ上の別ブロックに持たせても同様に
適用可能である。
示す通り、ブロックに対してそのブロック内にそのブロ
ックに対する管理情報を持っている。しかし、前記
(3)では、例えば請求項2,3,4,5,6,7又は
8での管理装置にある管理情報をブロック管理情報の体
系から種別管理の体系に変更させる。つまり、種別ごと
に集中管理情報を持たせる。例えば、集中管理情報
(1)として、請求項2の各ブロックの情報を持たせ
る。同様に、集中管理情報(m)には請求項6に記載さ
れているような各ブロックの情報を持たせる。この集中
管理情報は、同一フラッシュメモリ上の別ブロックに格
納させる。このとき、イレース単位のブロックごとに集
中管理情報をそれぞれ格納してもよい。当然、同一ブロ
ックに格納してもかまわない。このように、それぞれブ
ロックの管理情報を個々(同種ごと)に集結させ、同一
のフラッシュメモリ上の別ブロックに持たせても同様に
適用可能である。
【0100】(5)前記(1)〜(4)において、物理
ブロックの前セグメントを示す情報あるいは物理ブロッ
クの後セグメントを示す情報のどちらか一方あれば、同
様に適用可能である。ただし、この場合、管理の簡略化
と多少の高速性を得るが、反面、二重管理を行わないた
め、システムの安全性は低下することになる。 (6)また、前記例で、管理情報の一部をフラッシュメ
モリ上ではなく、RAM領域に配置しても同様に適用可
能である。また、一部の管理情報を固定させても適用可
能である。例えば、先頭ブロックの管理情報は常に固定
させる。中間セグメントの管理情報はRAM上に持たせ
る。 (7)前記(1)〜(6)まではフラッシュメモリを1
個使用した例であるが、フラッシュメモリが複数個あっ
ても、本発明の管理形態は同様に適用可能である。
ブロックの前セグメントを示す情報あるいは物理ブロッ
クの後セグメントを示す情報のどちらか一方あれば、同
様に適用可能である。ただし、この場合、管理の簡略化
と多少の高速性を得るが、反面、二重管理を行わないた
め、システムの安全性は低下することになる。 (6)また、前記例で、管理情報の一部をフラッシュメ
モリ上ではなく、RAM領域に配置しても同様に適用可
能である。また、一部の管理情報を固定させても適用可
能である。例えば、先頭ブロックの管理情報は常に固定
させる。中間セグメントの管理情報はRAM上に持たせ
る。 (7)前記(1)〜(6)まではフラッシュメモリを1
個使用した例であるが、フラッシュメモリが複数個あっ
ても、本発明の管理形態は同様に適用可能である。
【0101】(8)前記形態は、フラッシュメモリに本
発明を適用したものであるが、他の類似するメモリがフ
ラッシュメモリと同じ書き込み,読み出し機能を備えて
おり、かつ、書き込み前にブロックの消去特性を有する
メモリであれば、同様に適用可能である。 (9)フラッシュメモリのイレース単位である物理ブロ
ックは、バイト単位やワード単位など、どのようなデー
タ単位であっても、同様に適用可能である。
発明を適用したものであるが、他の類似するメモリがフ
ラッシュメモリと同じ書き込み,読み出し機能を備えて
おり、かつ、書き込み前にブロックの消去特性を有する
メモリであれば、同様に適用可能である。 (9)フラッシュメモリのイレース単位である物理ブロ
ックは、バイト単位やワード単位など、どのようなデー
タ単位であっても、同様に適用可能である。
【0102】
【発明の効果】以上説明したように本発明によれは、次
のような効果がある。 (1)フラッシュ型メモリを使用した補助記憶装置上で
フラッシュメモリの消去回数を低減するような制御構造
をもつため、無駄のないデータ構造で記憶を行なうこと
が可能である。 (2)データの書き換え回数を低減することにより、コ
ンピュータシステムの高速化を図ることができる。
のような効果がある。 (1)フラッシュ型メモリを使用した補助記憶装置上で
フラッシュメモリの消去回数を低減するような制御構造
をもつため、無駄のないデータ構造で記憶を行なうこと
が可能である。 (2)データの書き換え回数を低減することにより、コ
ンピュータシステムの高速化を図ることができる。
【0103】(3)各ブロックの管理情報テーブルのた
めのエリアをそのブロック内に持つこととしたので、別
メモリを新たに必要とせず、コストの削減が可能とな
る。従って、システムとして省スペース・コスト削減を
図ることができる。 (4)物理ブロックの有効/遷移中/無効/初期化とい
った状態フラグや故障以前のブロックの連鎖情報の履歴
の情報源を持つこととしたので、コンピュータシステム
の異常による停止に代表されるような故障原因から、コ
ンピュータシステムの復旧やデータの復元を行なう際に
有効である。
めのエリアをそのブロック内に持つこととしたので、別
メモリを新たに必要とせず、コストの削減が可能とな
る。従って、システムとして省スペース・コスト削減を
図ることができる。 (4)物理ブロックの有効/遷移中/無効/初期化とい
った状態フラグや故障以前のブロックの連鎖情報の履歴
の情報源を持つこととしたので、コンピュータシステム
の異常による停止に代表されるような故障原因から、コ
ンピュータシステムの復旧やデータの復元を行なう際に
有効である。
【0104】(5)データファイルのスパンドレコード
の第一セグメントが格納されていることを示す先頭ブロ
ックの情報を備えたことにより、データファイル構造を
論理的に構成させるとき、データファイルの先頭を高速
にサーチさせるのに有効である。 (6)データファイルのスパンドレコードの最終セグメ
ントが格納されていることを示す最終ブロックの情報を
備えたことにより、新たにデータファイルへのセグメン
トの追加を行う際に有効である。
の第一セグメントが格納されていることを示す先頭ブロ
ックの情報を備えたことにより、データファイル構造を
論理的に構成させるとき、データファイルの先頭を高速
にサーチさせるのに有効である。 (6)データファイルのスパンドレコードの最終セグメ
ントが格納されていることを示す最終ブロックの情報を
備えたことにより、新たにデータファイルへのセグメン
トの追加を行う際に有効である。
【0105】(7)データファイルのスパンドレコード
の中間セグメントが格納されていることを示す中間ブロ
ックの情報を備えたことにより、前後の連鎖があること
を示し、フラッシュメモリ内の状態の管理を行う際に有
効である。これは、前記(2),(4)の効果を得るた
めには必要である。 (8)物理ブロックの前のセグメントが格納されている
ことを示す物理ブロック情報を備えたことにより、デー
タファイル構造を論理的に構成させ、連鎖情報により、
デフラグメンテーション等のデータファイルの再構築や
データの書き換え回数を低減させるための情報として有
効である。
の中間セグメントが格納されていることを示す中間ブロ
ックの情報を備えたことにより、前後の連鎖があること
を示し、フラッシュメモリ内の状態の管理を行う際に有
効である。これは、前記(2),(4)の効果を得るた
めには必要である。 (8)物理ブロックの前のセグメントが格納されている
ことを示す物理ブロック情報を備えたことにより、デー
タファイル構造を論理的に構成させ、連鎖情報により、
デフラグメンテーション等のデータファイルの再構築や
データの書き換え回数を低減させるための情報として有
効である。
【0106】(9)物理ブロックの後のセグメントが格
納されていることを示す物理ブロック情報を備えたこと
により、データファイル構造を論理的に構成させ、連鎖
情報により、デフラグメンテーション等のデータファイ
ルの再構築やデータの書き換え回数を低減させるための
情報として有効である。 (10)物理ブロック内の個々の管理情報が個々に有効
か無効かを示す情報を含ませたことにより、最新の連鎖
構造の実現と旧連鎖構造の復元を行う際に有効である。
納されていることを示す物理ブロック情報を備えたこと
により、データファイル構造を論理的に構成させ、連鎖
情報により、デフラグメンテーション等のデータファイ
ルの再構築やデータの書き換え回数を低減させるための
情報として有効である。 (10)物理ブロック内の個々の管理情報が個々に有効
か無効かを示す情報を含ませたことにより、最新の連鎖
構造の実現と旧連鎖構造の復元を行う際に有効である。
【0107】(11)物理ブロック内の個々の管理情報
が無効になったとき、更新される新管理情報を含むこと
により、データファイルの書き換え回数を低減させ、論
理的にデータファイル内のセグメントの組み替えを可能
とするだけでなく、本来、データの書き込みにかかる時
間を削減できる。つまり、システムの高速性と書き換え
回数の低減を図る際に有効である。
が無効になったとき、更新される新管理情報を含むこと
により、データファイルの書き換え回数を低減させ、論
理的にデータファイル内のセグメントの組み替えを可能
とするだけでなく、本来、データの書き込みにかかる時
間を削減できる。つまり、システムの高速性と書き換え
回数の低減を図る際に有効である。
【図1】この発明の−形態を利用したシステムの基本構
成を示す図である。
成を示す図である。
【図2】前記形態におけるソフトウェア構造を示す図で
ある。
ある。
【図3】前記形態において、フラッシュメモリ内での物
理ブロックの割付を行なったメモリマップを示す概念図
である。
理ブロックの割付を行なったメモリマップを示す概念図
である。
【図4】物理的なデータファイルをセグメント化し、物
理ブロックに格納する様子を示した図である。
理ブロックに格納する様子を示した図である。
【図5】論理的なデータファイルをデータファイル領域
内のデータレコードとしてパケット化する様子を示す図
である。
内のデータレコードとしてパケット化する様子を示す図
である。
【図6】前記ケット化されたデータ構造を物理ブロック
に格納した様子を示す図である。
に格納した様子を示す図である。
【図7】物理ブロック内のブロックヘッダの情報とセグ
メントのデータを割り付けた格納例を示す図である。
メントのデータを割り付けた格納例を示す図である。
【図8】本発明の一形態におけるデータファイルと物理
ブロックの相関関係の例を示す図である。
ブロックの相関関係の例を示す図である。
【図9】本発明の一形態における物理ブロックイメージ
と論理的なデータファイルのイメージとデータレコード
をパケット化し結合したデータをセグメント化する様子
を表す図である。
と論理的なデータファイルのイメージとデータレコード
をパケット化し結合したデータをセグメント化する様子
を表す図である。
【図10】前記図9に示した状態からデータレコードが
削除されたときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化して結合したデータをセグメント化する様子を表す図
である。
削除されたときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化して結合したデータをセグメント化する様子を表す図
である。
【図11】前記図10に示した状態からデータレコード
を移動したときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化し結合したデータをセグメント化する様子を表す図で
ある。
を移動したときの物理ブロックイメージと、論理的なデ
ータファイルのイメージと、データレコードをパケット
化し結合したデータをセグメント化する様子を表す図で
ある。
【図12】ブロックイレースが64Kバイト単位のフラ
ッシュメモリを、物理ブロック単位に分割して256バ
イトのブロックヘッダを確保した例を示す図である。
ッシュメモリを、物理ブロック単位に分割して256バ
イトのブロックヘッダを確保した例を示す図である。
【図13】前記実施例で使用しているフラッシュメモリ
をデータファイル領域に分割したメモリマップの例を示
す図である。
をデータファイル領域に分割したメモリマップの例を示
す図である。
【図14】前記実施例で使用している物理ブロックヘッ
ダのメモリマップの例を示す図である。
ダのメモリマップの例を示す図である。
【図15】前記実施例における物理ブロックヘッダの一
部とシーケンスを表す図である。
部とシーケンスを表す図である。
【図16】前記実施例における前ブロックポインタの更
新の様子を表す図である。
新の様子を表す図である。
【図17】前記実施例における後ブロックポインタの更
新の様子を表す図である。
新の様子を表す図である。
【図18】前記実施例における物理的なデータファイル
をセグメント化した様子を示す図である。
をセグメント化した様子を示す図である。
【図19】前記セグメント化したデータファイルを、物
理ブロックに割り当てた例を示す図である。
理ブロックに割り当てた例を示す図である。
【図20】データファイルセグメントの物理ブロックに
対する割り当て例と、セグメントの削除の様子を示す図
である。
対する割り当て例と、セグメントの削除の様子を示す図
である。
【図21】データファイルセグメントの物理ブロックに
対する割り当て例と、セグメントの削除・追加・移動の
様子を示す図である。
対する割り当て例と、セグメントの削除・追加・移動の
様子を示す図である。
【図22】前記例におけるセグメントの削除・追加・移
動の様子の例を表す図である。
動の様子の例を表す図である。
【図23】管理情報格納の他の例を示す図である。
1…プロセッサ 2…フラッシュメモリ 3…フラッシュメモリ制御装置 4…拡張記憶装置もしくは補助記憶装置 5…ランダムアクセスメモリ 6…オペレーティングシステム 7…アプリケーションソフト 8…ドライバ層 9…フラッシュ管理マネージャ BLA,BLB…物理ブロック DA,DB…データファイル領域 DR…データレコード DRF…データレコードフッタ DRH…データレコードヘッダ DRP…データレコードパケット HA,HB…ヘッダ領域
Claims (11)
- 【請求項1】 ブロック単位で記憶内容を消去できるフ
ラッシュ型メモリのイレース単位である物理ブロック
に、その物理ブロックにおけるデータファイルのスパン
ドレコードを管理する管理情報を記憶するへッダ領域
と、データファイルをスパンドレコードとして取り扱っ
たブロック単位に分割されたデータセグメントを格納す
る記憶領域とを備えたことを特徴とするフラッシュ型メ
モリ。 - 【請求項2】 データファイルのスパンドレコードの第
1セグメントが格納されていることを示す先頭ブロック
の情報を備えたことを特徴とするフラッシュ型メモリの
管理装置。 - 【請求項3】 データファイルのスパンドレコードの最
終セグメントが格納されていることを示す最終ブロック
の情報を備えたことを特徴とするフラッシュ型メモリの
管理装置。 - 【請求項4】 データファイルのスパンドレコ−ドの中
間セグメントが格納されていることを示す中間ブロック
の情報を備えたことを特徴とするフラッシュ型メモリの
管理装置。 - 【請求項5】 物理ブロックのセグメントの前のセグメ
ントが格納されている物理ブロックを示す情報を備えた
ことを特徴とするフラッシュ型メモリの管理装置。 - 【請求項6】 その物理ブロックのセグメントの後のセ
グメントが格納されている物理ブロックを示す情報を備
えたことを特徴とするフラッシュ型メモリの管理装置。 - 【請求項7】 前記物理ブロック内の個々の情報が個々
に有効か無効かを示す情報を含むことを特徴とする請求
項2,3,4,5,又は6のいずれかに記載のフラッシ
ュ型メモリの管理装置。 - 【請求項8】 前記物理ブロック内の個々の管理情報が
無効になったときに更新される新管理情報を含むことを
特徴とする請求項2,3,4,5,6,又は7のいずれ
かに記載のフラッシュ型メモリの管理装置。 - 【請求項9】 ブロック単位に分割されたデータファイ
ルのスパンドレコードの各セグメントを、それぞれ物理
ブロックに割り当てるとともに、各物理ブロックの管理
情報を、該当する物理ブロックにそれぞれ格納する手段
を備えたことを特徴とする請求項1記載のフラッシュ型
メモリの管理装置。 - 【請求項10】 システムの復旧やデータの復元を行な
う手段を備えたことを特徴とする請求項9記載のフラッ
シュ型メモリの管理装置。 - 【請求項11】 各物理ブロックに格納されているデー
タの書き換え回数を低減する手段を備えたことを特徴と
する請求項9又は10に記載のフラッシュ型メモリの管
理装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10092566A JPH11272537A (ja) | 1998-03-20 | 1998-03-20 | フラッシュ型メモリ及びその管理装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP10092566A JPH11272537A (ja) | 1998-03-20 | 1998-03-20 | フラッシュ型メモリ及びその管理装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JPH11272537A true JPH11272537A (ja) | 1999-10-08 |
Family
ID=14057987
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP10092566A Pending JPH11272537A (ja) | 1998-03-20 | 1998-03-20 | フラッシュ型メモリ及びその管理装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JPH11272537A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005301686A (ja) * | 2004-04-12 | 2005-10-27 | Buffalo Inc | データ記憶装置およびその初期化方法 |
JP2006505848A (ja) * | 2002-11-07 | 2006-02-16 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | メインファイルシステム領域及び仮想ファイルシステム領域を有する記録担体 |
JP2007011536A (ja) * | 2005-06-29 | 2007-01-18 | Victor Co Of Japan Ltd | 記録装置 |
JP2009271848A (ja) * | 2008-05-09 | 2009-11-19 | Fujitsu Microelectronics Ltd | ファイルシステム及びデータ管理方法 |
US7680837B2 (en) | 2005-11-08 | 2010-03-16 | Nec Corporation | File management method for log-structured file system for sequentially adding and storing log of file access |
-
1998
- 1998-03-20 JP JP10092566A patent/JPH11272537A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006505848A (ja) * | 2002-11-07 | 2006-02-16 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | メインファイルシステム領域及び仮想ファイルシステム領域を有する記録担体 |
JP2005301686A (ja) * | 2004-04-12 | 2005-10-27 | Buffalo Inc | データ記憶装置およびその初期化方法 |
JP4502689B2 (ja) * | 2004-04-12 | 2010-07-14 | 株式会社バッファロー | データ記憶装置およびその初期化方法 |
JP2007011536A (ja) * | 2005-06-29 | 2007-01-18 | Victor Co Of Japan Ltd | 記録装置 |
US7680837B2 (en) | 2005-11-08 | 2010-03-16 | Nec Corporation | File management method for log-structured file system for sequentially adding and storing log of file access |
JP2009271848A (ja) * | 2008-05-09 | 2009-11-19 | Fujitsu Microelectronics Ltd | ファイルシステム及びデータ管理方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7610434B2 (en) | File recording apparatus | |
KR100453053B1 (ko) | 플래쉬 메모리용 파일 시스템 | |
KR960004738B1 (ko) | 불휘발성 반도체 메모리 장치 | |
US5682497A (en) | Managing file structures for a flash memory file system in a computer | |
USRE46404E1 (en) | Flash memory management method | |
US6571326B2 (en) | Space allocation for data in a nonvolatile memory | |
US7594062B2 (en) | Method for changing data of a data block in a flash memory having a mapping area, a data area and an alternative area | |
KR20010042905A (ko) | 비휘발성 메모리에서의 가변 크기 데이터의 효율적인관리를 위한 동적 할당 | |
US6636941B1 (en) | Enhanced stable disk storage | |
JPWO2005103903A1 (ja) | 不揮発性記憶システム | |
JP2006040264A (ja) | メモリカードの制御方法および不揮発性半導体メモリの制御方法 | |
US20110040931A1 (en) | Memory control method and device, memory access control method, computer program, and recording medium | |
KR100703680B1 (ko) | 플래시 파일 시스템 | |
CN114840449B (zh) | 基于MCU片内flash的数据存储方法、装置、设备及存储介质 | |
KR100907477B1 (ko) | 플래시 메모리에 저장된 데이터의 인덱스 정보 관리 장치및 방법 | |
JP3503448B2 (ja) | フラッシュ型メモリ及びその管理装置 | |
JP2002163139A (ja) | データ管理装置およびそれを用いたデータ管理方法 | |
US7167964B1 (en) | Memory defragmentation in chipcards | |
JPH11272537A (ja) | フラッシュ型メモリ及びその管理装置 | |
EP1046996B1 (en) | Memory defragmentation in chipcards | |
JP3555456B2 (ja) | フラッシュ型メモリの管理装置 | |
JP2001101071A (ja) | フラッシュ型メモリを用いたデータ記憶装置及びフラッシュ型メモリのデータ管理方法 | |
CN111949212B (zh) | 基于自定义开放通道ssd的文件***及文件管理方法 | |
JP3904182B2 (ja) | データ管理システムおよびそれを用いたデータ管理方法 | |
JPH09152983A (ja) | フラッシュメモリに内在するファイルシステムにおけるリエントラントガーベジコレクション処理 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20041130 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20050405 |