JP2008530708A - フラッシュメモリにおける直接データファイル記憶実施技術 - Google Patents
フラッシュメモリにおける直接データファイル記憶実施技術 Download PDFInfo
- Publication number
- JP2008530708A JP2008530708A JP2007556204A JP2007556204A JP2008530708A JP 2008530708 A JP2008530708 A JP 2008530708A JP 2007556204 A JP2007556204 A JP 2007556204A JP 2007556204 A JP2007556204 A JP 2007556204A JP 2008530708 A JP2008530708 A JP 2008530708A
- Authority
- JP
- Japan
- Prior art keywords
- data
- file
- block
- memory
- host
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
- G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
- G06F3/0607—Improving or facilitating administration, e.g. storage management by facilitating the process of upgrading existing storage systems, e.g. for improving compatibility between host and storage device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/72—Details relating to flash memory management
- G06F2212/7201—Logical to physical mapping or translation of blocks or pages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/72—Details relating to flash memory management
- G06F2212/7205—Cleaning, compaction, garbage collection, erase control
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Techniques For Improving Reliability Of Storages (AREA)
- Read Only Memory (AREA)
- Memory System (AREA)
Abstract
ホストシステムデータファイルは、メモリの中間論理アドレスまたは仮想アドレス空間のいずれをも用いず、各ファイルの固有の識別子とファイル内のデータのオフセットとを用いて大規模な消去ブロックフラッシュメモリシステムに直接に書き込まれる。ファイルがメモリに記憶されたディレクトリ情報は、ホストによるよりはむしろ、メモリシステムコントローラによってメモリシステム内で維持される。ホストとメモリシステムとの間のファイルベースのインターフェイスによって、メモリシステムコントローラは、効率を増大してメモリ内のデータ記憶ブロックを利用することができる
Description
本発明は、半導体フラッシュメモリのような再プログラム可能な不揮発性メモリシステムの動作に関し、特に、ホスト装置とメモリとの間のインターフェイスの管理に関する。本願明細書において参照される特許、特許出願、文献および他の資料、文書並びに事柄のすべては、あらゆる目的のためにその全体が本願明細書において参照により援用されている。
商用フラッシュメモリシステムの初期世代では、長方形アレイのメモリセルは、標準のディスクドライブセクタのデータ量すなわち512バイトを各々記憶する多数のグループのセルに分割されていた。一般的に、誤り訂正符号(ECC)と、場合によっては、ユーザデータおよび/またはユーザデータが記憶されるメモリセルグループに関する他のオーバーヘッドデータとを記憶するために16バイトのような追加のデータ量も、各グループに含まれている。このような各グループのメモリセルは、同時に消去できる最小数のメモリセルである。すなわち、事実上、消去単位は、1つのデータセクタと、含まれている任意のオーバーヘッドデータとを記憶するメモリセルの数である。この種のメモリシステムの例は、米国特許第5,602,987号(特許文献1)および第6,426,893号(特許文献2)に記載されている。メモリセルをデータで再プログラムする前にメモリセルを消去する必要があるということがフラッシュメモリの特性である。
フラッシュメモリシステムは、パーソナルコンピュータおよびカメラなどのような様々なホストと取り外し可能に接続されるメモリカードまたはフラッシュドライブの形態で最も一般的に提供される。しかし、このようなホストシステム内にフラッシュメモリシステムを埋め込むこともできる。データをメモリに書き込むとき、一般的に、ホストは固有の論理アドレスをメモリシステムの連続的な仮想アドレス空間内のセクタ、クラスタまたは他のデータ単位に割り当てる。ディスクオペレーティングシステム(DOS)のように、ホストはデータをメモリシステムの論理アドレス空間内のアドレスに書き込み、このアドレスからデータを読み出す。メモリシステム内のコントローラは、ホストから受信した論理アドレスを、データが実際に記憶されるメモリアレイ内の物理アドレスに変換し、その後、これらのアドレス変換を追跡し続ける。メモリシステムのデータ記憶容量は、メモリシステムに対して定義された論理アドレス空間全体にわたってアドレス指定可能なデータの量と少なくとも同じ大きさである。
後世代のフラッシュメモリシステムでは、消去単位の大きさは、複数のセクタのデータを記憶するのに充分なメモリセルのブロックまで増大された。メモリシステムが接続されているホストシステムがセクタのような小さい最小単位でデータをプログラムし読み出すことができるとしても、多数のセクタは、フラッシュメモリの単一の消去単位に記憶される。ホストが論理セクタのデータを更新または置き換えすると、ブロック内の幾つかのセクタのデータが古くなることは一般的である。ブロックに記憶された任意のデータを上書きできる前にブロック全体を消去する必要があるので、一般的に、新たなデータまたは更新されたデータは、このデータ用に残りの容量を有する消去済みの別のブロックに記憶される。この処理は、古いデータを有しメモリ内に貴重な空間を占有する元のブロックを残す。しかし、ブロック内に有効なデータが残っている場合、このブロックを消去することができない。
従って、メモリの記憶容量をより良く利用するため、有効な部分的ブロック量のデータを消去済みブロックへコピーし、これによって、これらデータがコピーされた(1つ以上の)ブロックをその後に消去し、それら全部の記憶容量を再使用できるように、これらデータを統合または収集するのが一般的である。データセクタを論理アドレスの順序にブロック内にグループ化するようにデータをコピーするのも望ましい。その理由は、このことが、データを読み出し、読み出したデータをホストに転送する速度を増大するためである。このようなデータのコピーがあまりに頻繁に行われる場合、メモリシステムの動作性能は劣化することがある。メモリの記憶容量が、システムの論理アドレス空間を介してホストによってアドレス指定可能なデータの量にすぎない場合、すなわち、一般的な例では、この劣化は、特にメモリシステムの動作に影響を及ぼす。この場合、ホストプログラミングコマンドを実行できる前にデータの統合または収集を必要とすることがある。その結果、プログラミング時間は増大する。
所定の半導体領域内に記憶することができるデータのビット数を増大させるため、メモリシステムの世代ごとにブロックの大きさは増大している。256個のデータセクタを記憶するブロックは、ますます一般的になってきている。さらに、データのプログラムおよび読み出しの並列性の度合いを増大させるため、異なるアレイまたはサブアレイの2,4またはそれ以上のブロックがメタブロック内に論理的に互いに結合されることが多い。このような大規模な容量に加えて、動作単位は、これらを効率良く動作するという点で問題を生じさせる。
米国特許第5,602,987号
米国特許第6,426,893号
米国特許出願第10/915,039号
米国特許第5,570,315号
米国特許第5,774,397号
米国特許第6,046,935号
米国特許第6,373,746号
米国特許第6,456,528号
米国特許第6,522,580号
米国特許第6,771,536号
米国特許第6,781,877号
米国公開特許出願第2003/0147278号
米国公開特許出願第2003/0109093号
米国特許第6,763,424号
米国特許出願第10/749,831号
米国特許出願第10/750,155号
米国特許出願第10/917,888号
米国特許出願第10/917,867号
米国特許出願第10/917,889号
米国特許出願第10/917,725号
米国特許出願第10/749,189号
米国特許出願第10/841,118号
米国特許出願第11/016,271号
米国特許出願第10/897,049号
米国特許出願第11/022,369号
このような大規模な消去ブロックフラッシュメモリシステムを効率良く動作するという点で直面する問題を確信して様々な程度まで克服する多くの技術が開発されている。一方、本発明は、メモリとホストシステムとの間のデータ転送インターフェイスを変更することによってさらに基本的なアプローチをとる。現在行われているように仮想アドレス空間内の論理アドレスを用いてメモリとホストシステムとの間でデータをやり取りするよりはむしろ、データファイルは、ホストによって割り当てられたファイル名と、ファイル内のオフセットアドレスとによって識別される。従って、メモリシステムは、各セクタまたは他のデータ単位が属するホストファイルを識別する。本願明細書で説明されているファイル単位は、例えば、連続的なオフセットアドレスを有することによって順序付けられたデータセットであって、ホストコンピューティングシステム内で動作するアプリケーションプログラムによって生成され一意的に識別される。
現在、ホストは、ファイルを識別することなしに共通の論理アドレスセットによってメモリシステムへの全ファイル内のデータを識別するので、ファイル単位は、現在の商用メモリシステムによって用いられていない。論理アドレスを用いる代わりに、ファイルオブジェクトによってホストデータを識別することによって、メモリシステムコントローラは、このような頻繁なデータ統合および収集の必要性を減少させるようにデータを記憶することができる。従って、データコピー動作の頻度と、コピーされるデータの量とが著しく減少し、これによって、メモリシステムのデータプログラムおよび読み出し性能を増大させる。さらに、メモリシステムコントローラは、ホストファイルが記憶されているメモリブロックのディレクトリおよび索引テーブル情報を維持する。従って、現在、論理アドレスインターフェイスを管理するのに必要とされるファイル割り当てテーブル(FAT)をホストが維持する必要はない。
単独または共同で用いられた場合に動作を改善する一因となる他の幾つかの技術を用いて、本発明のファイルベースのシステムを実施することができる。ホストからのデータは、データがホストによって供給された順に可変長データグループのメモリブロック内に書き込まれる。各データグループ内のデータは、ブロック内に連続的な論理オフセットおよび物理メモリアドレスを有する。すなわち、論理ファイルオフセットアドレス内で途切れが引き起こされるときはいつでも、新たなデータグループが開始される。これと同様に、データがメモリブロックを満たし、別のメモリブロック内に書き込まれ始めると、新たなデータグループも開始される。本システムでのようにホストではなくメモリシステムコントローラは、ホストファイルが記憶されるメモリブロックのディレクトリおよび索引テーブル情報を維持する。索引テーブル内の項目セットは、完全なファイルを形成するデータグループをリストする。
ガーベッジコレクションは、現在行われているメモリブロックごとよりはむしろファイルごとに開始され、従って、このような動作を必要とする所定のファイルのデータを記憶する全メモリブロックについて実行される。バックグラウンドで大部分のガーベッジコレクションを実行することができ、これによって、ホスト書き込みコマンドを実行することができる前に実行する必要があるガーベッジコレクションの頻度を著しく減少させる。
個々のファイルからのデータは、ファイル専用の1つ以上のメモリブロックに書き込まれる。オフセットアドレスの順序にかかわらず、ホストから受信した順にデータを書き込むことができる。ホストによって生成されたファイルデータの論理オフセット分解能と同じ物理メモリ分解能でもデータを書き込むことができる。整数のブロックが各ファイルからのデータでいっぱいになった後、使い残った2つ以上のファイルからの残留データを記憶する1つ以上の共通メモリブロックを維持することができる。
添付図面と併せて理解すべき本発明の例示的な実施形態の説明には、本発明の他の態様、利点、特徴および詳細が含まれる。
フラッシュメモリシステムの概要
図1〜図8に関して、現在のフラッシュメモリシステムと、ホスト装置を用いる一般的な動作とを説明する。このようなシステムでは、本発明の様々な態様を実施することができる。図1のホストシステム1はデータをフラッシュメモリ2に記憶し、データをフラッシュメモリ2から取り出す。フラッシュメモリをホスト内に埋め込むことができるが、メモリ2は、機械的かつ電気的コネクタの嵌め合い部分3,4を介してホストに取り外し可能に接続されるカードの一般的な形態として示されている。現在、数多くの異なるフラッシュメモリカードが市販され、一例として、コンパクトフラッシュ(登録商標)(CF)カード、マルチメディアカード(MMC)、セキュアデジタル(SD)カード、ミニSDカード、メモリスティックカード、スマートメディアカードおよびトランスフラッシュカードが挙げられる。これらカードの各々は、その標準化仕様に従って固有の機械的および/または電気的インターフェイスを有するが、各々に含まれるフラッシュメモリは、ほとんど同じである。これらのカードはすべて、本願の譲受人であるサンディスク コーポレーションから入手可能である。サンディスク コーポレーションは、ホストのユニバーサルシリアルバス(USB)レセプタクルに差し込むことによってホストと接続するUSBプラグを有する小形パッケージ内のハンドヘルドメモリシステムであるCruzer(登録商標)下の一連のフラッシュドライブをも提供する。これらメモリカードおよびフラッシュドライブの各々は、ホストとインターフェイスをとり、それら内に、フラッシュメモリの動作を制御するコントローラを含む。
図1〜図8に関して、現在のフラッシュメモリシステムと、ホスト装置を用いる一般的な動作とを説明する。このようなシステムでは、本発明の様々な態様を実施することができる。図1のホストシステム1はデータをフラッシュメモリ2に記憶し、データをフラッシュメモリ2から取り出す。フラッシュメモリをホスト内に埋め込むことができるが、メモリ2は、機械的かつ電気的コネクタの嵌め合い部分3,4を介してホストに取り外し可能に接続されるカードの一般的な形態として示されている。現在、数多くの異なるフラッシュメモリカードが市販され、一例として、コンパクトフラッシュ(登録商標)(CF)カード、マルチメディアカード(MMC)、セキュアデジタル(SD)カード、ミニSDカード、メモリスティックカード、スマートメディアカードおよびトランスフラッシュカードが挙げられる。これらカードの各々は、その標準化仕様に従って固有の機械的および/または電気的インターフェイスを有するが、各々に含まれるフラッシュメモリは、ほとんど同じである。これらのカードはすべて、本願の譲受人であるサンディスク コーポレーションから入手可能である。サンディスク コーポレーションは、ホストのユニバーサルシリアルバス(USB)レセプタクルに差し込むことによってホストと接続するUSBプラグを有する小形パッケージ内のハンドヘルドメモリシステムであるCruzer(登録商標)下の一連のフラッシュドライブをも提供する。これらメモリカードおよびフラッシュドライブの各々は、ホストとインターフェイスをとり、それら内に、フラッシュメモリの動作を制御するコントローラを含む。
このようなメモリカードおよびフラッシュドライブを用いるホストシステムは、数多くあり様々である。ホストシステムは、パーソナルコンピュータ(PC)、ラップトップおよび他のポータブルコンピュータ、携帯電話、個人用携帯情報端末(PDA)、デジタル静止カメラ、デジタル動画カメラおよびポータブルオーディオプレーヤを含む。一般的に、ホストは、1つ以上の種類のメモリカードまたはフラッシュドライブに対して組み込みレセプタクルを含むが、メモリカードが差し込まれるアダプタを必要とするものもある。
メモリ2が関与する限りにおいて、図1のホストシステム1を、回路およびソフトウェアの組み合わせで構成された2つの主要な部分を有すると見なすことができる。これらの部分は、アプリケーション部分5と、メモリ2とインターフェイスをとるドライバ部分6とである。パーソナルコンピュータでは、例えば、アプリケーション部分5は、プロセッサが実行するワード処理、グラフィックス、制御または他の一般的なアプリケーションソフトウェアを含むことができる。単一の機能セットを実行することを主に専用とするカメラ、携帯電話または他のホストシステムでは、アプリケーション部分5は、写真をとり記憶するようにカメラを動作するソフトウェアや、電話をかけ電話を受けるように携帯電話を動作するソフトウェアなどを含む。
図1のメモリシステム2は、フラッシュメモリ7と、データをやり取りするカードが接続されているホストとインターフェイスをとり、メモリ7を制御する回路8とを含む。一般的に、コントローラ8は、データをプログラムし読み出す間に、ホスト1によって用いられるデータの論理アドレスと、メモリ7の物理アドレスとの間で変換を行う。
図2に関して、図1の不揮発性メモリ2として用いることができる例示的なフラッシュメモリシステムの回路を説明する。一般的に、システムコントローラは、システムバス13を介して1つ以上の集積回路メモリチップ、すなわち、図2に示されている単一のメモリチップ15と並列に接続された単一の集積回路チップ11上に実施されている。図に示す特定のバス13は、データを搬送する別個のセットの導体17と、メモリアドレス用のセット19と、制御およびステータス信号用のセット21とを含む。あるいはまた、単一セットの導体を、これら3つの機能の間で時分割にすることができる。さらに、「リングバス構造とフラッシュメモリシステムにおけるその使用法」という2004年8月9日に出願された米国特許出願第10/915,039号(特許文献3)に記載されている環状バスのような他の構成のシステムバスを用いることができる。
一般的なコントローラチップ11は、それ自体の内部バス23を有し、内部バス23は、インターフェイス回路25を介してシステムバス13とインターフェイスをとる。一般的にバスに接続される主要な機能は、(マイクロプロセッサまたはマイクロコントローラのような)プロセッサ27と、システム初期化(「ブート」)するコードを含む読み出し専用メモリ(ROM)29と、メモリおよびホスト間で転送されるデータをバッファリングするのに主に用いられるランダムアクセスメモリ(RAM)31と、コントローラを介してメモリおよびホスト間で受け渡すデータの誤り訂正符号(ECC)を計算し検査する回路33とである。コントローラバス23は、回路35を介してホストシステムとインターフェイスをとり、回路35がメモリカード内に含まれている図2のシステムの場合、コネクタ4の一部であるカードの外部接点37を介して行われる。クロック39は、コントローラ11の他の構成要素の各々と接続され、これら各々によって用いられる。
一般的に、メモリチップ15は、システムバス13と接続されている他の何らかのメモリチップと同様に、複数のサブアレイまたはプレーン、すなわち、図に示されているような2つのプレーン41,43に編成されているメモリセルのアレイを含む。説明を簡単にするために2つのこのようなプレーン41,43は示されているが、4または8つのような多くのこのようなプレーンを代わりに用いることもできる。あるいはまた、チップ15のメモリセルアレイをプレーンに分割しなくてもよい。しかし、このように分割された場合、各プレーンは、それ自体の列制御回路45,47を有し、列制御回路45,47は互いに独立して動作することができる。回路45,47は、システムバス13のアドレス部分19からそれぞれのメモリセルアレイのアドレスを受信し、これらアドレスを復号化して、それぞれのビット線49,51の特定の1つまたはそれ以上にアドレス指定する。ワード線53は、アドレスバス19で受信したアドレスに応答する行制御回路55を介してアドレス指定される。pウェル電圧制御回路61,63と同様にソース電圧制御回路57,59も、それぞれのプレーンと接続されている。メモリチップ15が単一アレイのメモリセルを有する場合、かつ、2つ以上のこのようなチップがシステム内に存在する場合、前述したような複数プレーンチップ内のプレーンまたはサブアレイに類似して各チップのアレイを動作することができる。
データは、システムバス13のデータ部分17と接続されているそれぞれのデータ入力/出力回路65,67を介してプレーン41,43に転送され、プレーン41,43から転送される。回路65,67は、それぞれの列制御回路45,47を介してプレーンに接続された線69,71を介してデータをそれぞれのプレーンのメモリセルにプログラムし、メモリセルからデータを読み出すために設けられている。
コントローラ11は、データをプログラムし、データを読み出し、消去し、様々なハウスキーピング問題に応えるようにメモリチップ15の動作を制御するが、各メモリチップは、このような機能を実行するためにコントローラ11からのコマンドを実行する何らかの制御回路をも含む。インターフェイス回路73は、システムバス13の制御およびステータス部分21に接続されている。コントローラからのコマンドは状態マシン75に与えられ、状態マシン75は、これらコマンドを実行するために他の回路の特定制御を行う。制御線77〜81は、図2に示されているように、これらの他の回路と状態マシン75とを接続する。状態マシン75からのステータス情報は線83を介してインターフェイス回路73に伝達され、インターフェイス回路73によってバス部分21を介してコントローラ11に伝送される。
メモリセルアレイ41,43のNAND構造は現在のところ好ましい。しかし、NORのような他の構造も代わりに用いることができる。NANDフラッシュメモリおよびメモリシステムの一部としてのNANDフラッシュメモリの動作の例は、米国特許第5,570,315号(特許文献4)、第5,774,397号(特許文献5)、第6,046,935号(特許文献6)、第6,373,746号(特許文献7)、第6,456,528号(特許文献8)、第6,522,580号(特許文献9)、第6,771,536号(特許文献10)、および第6,781,877号(特許文献11)、並びに米国公開特許出願第2003/0147278号(特許文献12)を参照することができる。
図2のメモリシステムのメモリセルアレイ41の一部である図3の回路図によって例示的なNANDアレイを示す。多数のグローバルビット線が設けられている。図3には、説明を簡単にするために4つだけのこのような線91〜94が示されている。多数の直列接続されたメモリセルストリング97〜104は、これらのビット線の1つと基準電位との間で接続されている。代表するものとしてメモリセルストリング99を参照すると、複数の電荷記憶メモリセル107〜110は直列に接続され、ストリングの両端には選択トランジスタ111,112を有する。ストリングの選択トランジスタが導通状態にされる場合、ストリングはビット線と基準電位との間で接続される。その後、このストリング内の1つのメモリセルは同時にプログラムまたは読み出される。
図3のワード線115〜118は個々にメモリセルの多数の各ストリング内の1つのメモリセルの電荷記憶素子にわたって延在し、ゲート119,120は、ストリングの各端にある選択トランジスタの状態を制御する。共通のワード線およびコントロールゲート線115〜120を共有するメモリセルストリングは、同時に消去されるメモリセルのブロック123を形成するように製造されている。セルのこのブロックは、物理的に同時に消去することができる最小数のセルを含む。ワード線115〜118の1つに沿っているメモリセルの1つの行は、同時にプログラムされる。一般的に、NANDアレイの行は、指示された順序でプログラムされ、この場合には、接地点または別の共通電位に接続されたストリングの端部に最も近いワード線118に沿っている行から始まる順序でプログラムされる。ワード線117に沿っているメモリセルの行が次にプログラムされ、その後、ブロック123を通じて次々にプログラムされる。ワード線115に沿っている行が最後にプログラムされる。
第2のブロック125は第1のブロック123と類似し、メモリセルのストリングが、第1のブロック123のストリングと同じグローバルビット線に接続されている。しかし、このブロック125は、異なるセットのワード線およびコントロールゲート線を有する。ワード線およびコントロールゲート線は、行制御回路55によって適切な動作電圧に駆動される。システム内に図2のプレーン1およびプレーン2のような2つ以上のプレーンまたはサブアレイが存在する場合、1つのメモリ構造は、これらプレーンの間に延在する共通のワード線を用いる。あるいはまた、3つ以上のプレーンまたはサブアレイは共通のワード線を共有することができる。他のメモリ構造では、個々のプレーンまたはサブアレイのワード線は別々に駆動される。
前に援用されているNANDに関する特許および公開特許出願の幾つかに記載されているように、3つ以上の検出可能な電荷レベルを各電荷記憶素子または領域に記憶し、これによって、2ビット以上のデータを各電荷記憶素子または領域に記憶するようにメモリシステムを動作することができる。メモリセルの電荷記憶素子は、最も一般的には導電性フローティングゲートであるが、米国公開特許出願第2003/0109093号(特許文献13)に記載されているような非導電性の誘電体電荷トラップ材料とすることもできる。
図4には、以下のさらなる説明において一例として用いられるフラッシュメモリセルアレイ7(図1)の編成を概念的に示す。メモリセルの4つのプレーンまたはサブアレイ131〜134を、単一の集積メモリセルチップ上、2つのチップ(各チップ上のプレーンのうちの2つ)上、または、4つの別個のチップ上に形成することができる。特定の配置は、以下の説明にとって重要ではない。1,2,8,16またはそれ以上のような他の数のプレーンがシステム内に存在しうることもちろんである。プレーンは、図4に示されているように、それぞれのプレーン131〜134に配置されているブロック137,138,139,140のような長方形ごとにメモリセルのブロックに個々に分割される。各プレーンには、数十または何百ものブロックを形成することができる。前述したように、メモリセルのブロックは消去単位であり、最小数のメモリセルは物理的に同時に消去可能である。しかし、増大される並列性のため、ブロックは大規模なメタブロック単位で動作される。各プレーンからの1つのブロックは、メタブロックを形成するように論理的に互いに結合される。4つのブロック137〜140は1つのメタブロック141を形成することが示されている。一般的に、メタブロック内の全セルは同時に消去される。ブロック145〜148で構成された第2のメタブロック143に示されているように、メタブロックを形成するのに用いられるブロックを、それぞれのプレーン内の同じ相対位置に制限する必要はない。一般的に、すべてのプレーンにわたってメタブロックを延在するのが好ましいが、高度なシステム性能の場合、異なるプレーン内の1,2または3つのブロックの一部または全部からメタブロックを動的に形成する機能を用いてメモリシステムを動作することができる。これによって、メタブロックの大きさを、1回のプログラム動作で記憶するのに利用できるデータ量と厳密に一致させることができる。
次に、個々のブロックは、図5に示されているように、動作上の目的のためにメモリセルのページに分割される。例えば、各ブロック131〜134のメモリセルはそれぞれ8つのページP0〜P7に分割されている。あるいはまた、各ブロック内には、16,32またはそれ以上のページのメモリセルを形成することができる。ページは、同時にプログラムされる最小量のデータを含むブロック内にデータをプログラムし読み出す単位である。図3のNAND構造では、ページは、ブロック内のワード線に沿っているメモリセルの形態を成す。しかし、メモリシステムの動作の並列性を増大させるため、2つ以上のブロック内のこのようなページをメタページに論理的に結合することができる。4つの各ブロック131〜134から1つの物理ページの形態を成すメタページ151を図5に示す。例えば、メタページ151は4つの各ブロックのページP2を含むが、メタページのページは必ずしも各ブロック内で同じ相対位置を有する必要はない。最大量のデータを4つのすべてのプレーンにわたって同時にプログラムし読み出すのが好ましいが、高度なシステム性能の場合、異なるプレーン内の別個のブロックの1,2または3つのページの一部または全部からメタページを形成するようにもメモリシステムを動作することができる。これによって、プログラムおよび読み出し動作が、都合良く同時に処理できるデータ量と適応的に一致することができ、メタページの一部が、データでプログラムされずに残る事態を減少させる。
図5に示されているように、複数のプレーンの物理ページの形態を成すメタページは、これら複数のプレーンのワード線行に沿っているメモリセルを含む。1つのワード線行内の全セルを同時にプログラムするよりはむしろ、より一般的には、メモリセルは、2つ以上のインターリーブされたグループで交互にプログラムされる。各グループは、(単一ブロックの)1ページのデータまたは(複数のブロックにまたがる)メタページのデータを記憶する。交互になっているメモリセルを同時にプログラムすることによって、データレジスタおよびセンス増幅器を含む一ユニットの周辺回路をビット線ごとに設ける必要はなくむしろ、隣接するビット線間で時分割にする。このことは、周辺回路に必要とされる基板空間の量を節約し、増大した密度でメモリセルを行に沿って詰めることができる。そうでなければ、所定のメモリシステムから利用できる並列性を最大にするために、行に沿っている全セルを同時にプログラムするのが好ましい。
図3に関して、行に沿っている他のメモリセルごとのデータの同時プログラムは、図に示されている単一行の代わりに、NANDストリングの少なくとも一方の端部に沿って2つの行の選択トランジスタ(図示せず)を設けることによって最も好適に達成される。次に、一方の行の選択トランジスタは、1つの制御信号に応答してブロック内の他のすべてのストリングをそれぞれのビット線に接続し、他方の行の選択トランジスタは、もう1つの制御信号に応答して、介在する他のすべてのストリングをそれぞれのビット線に接続する。従って、2つのページのデータは、各行のメモリセルに書き込まれる。
一般的に、各論理ページ内のデータ量は整数の1つ以上のセクタのデータであり、慣例として各セクタは512バイトのデータを含む。図6には、ページまたはメタページの2つのセクタ153,155のデータの論理データページを示す。一般的に、各セクタは、記憶されているユーザまたはシステムデータの512バイトの部分157と、部分157内のデータに関連するか、または、データが記憶されている物理ページあるいはブロックに関連するオーバーヘッドデータ用の別のバイト数159とを含む。オーバーヘッドデータのバイト数は一般的に16バイトであり、総計で、セクタ153,155ごとに528バイトになる。オーバーヘッド部分159は、プログラミング中にデータ部分157から計算されたECC、論理アドレス、ブロックが消去され再プログラムされた回数の体験数、1つ以上の制御フラグ、動作電圧レベルおよび/またはその類と、このようなオーバーヘッドデータ159から計算されたECCとを含むことができる。あるいはまた、オーバーヘッドデータ159またはその一部を、他のブロックの異なるページに記憶することができる。
メモリの並列性が増大するにつれて、メタブロックのデータ記憶容量が増大し、結果として、データページおよびメタページの大きさも増大する。この場合、データページは3つ以上のセクタのデータを含むことができる。1メタページ当たりに2つのデータページがあり、データページ内には2つのセクタがある場合、メタページには4つのセクタが存在する。従って、各メタページは2,048バイトのデータを記憶する。このことは高度な並列性であり、行内のメモリセルの数が増大するにつれてさらに増大することができる。この理由のため、フラッシュメモリの幅は拡張されてページおよびメタページ内のデータ量を増大させる。
前に確認されている物理的に小さい再プログラム可能な不揮発性メモリカードおよびフラッシュドライブは、512メガバイト(MB)、1ギガバイト(GB)、2GBおよび4GBのデータ記憶容量を伴って市販され、データ記憶容量をそれ以上高くすることができる。図7には、ホストとこのような大容量メモリシステムとの間の最も一般的なインターフェイスを示す。ホストは、ホストによって実行されたアプリケーションソフトウェアまたはファームウェアプログラムによって生成されるか、または用いられるデータファイルに対応する。一例としてワード処理データファイルが挙げられ、別の例としてコンピュータ支援設計(CAD)ソフトウェアの描画ファイルが挙げられ、これらは、主に、パーソナルコンピュータおよびラップトップコンピュータなどのような汎用コンピュータホストに見られる。pdf形式の文書も、このようなファイルがある。デジタルスチルビデオカメラは、メモリカードに記憶された写真ごとのデータファイルを生成する。携帯電話は、電話帳のような内部メモリカード上のファイルからデータを用いる。PDAは、アドレスファイルおよびカレンダファイルなどのような幾つかの異なるファイルを記憶し用いる。任意のこのようなアプリケーションでは、メモリカードは、ホストを動作するソフトウェアをも含むこともできる。
図7には、ホストとメモリシステムとの間の一般的な論理インターフェイスを示す。連続的な論理アドレス空間161は、メモリシステムに記憶できるデータのすべてに対するアドレスを備えるほど充分大きい。一般的に、ホストアドレス空間はクラスタのデータの単位で分割されている。所定のホストシステムにおいて、4〜64セクタくらいが一般的である多数のセクタのデータを含むように各クラスタを設計することができる。標準のセクタは512バイトのデータを含む。
図7の例には、生成された3つのファイル1、ファイル2およびファイル3が示されている。ホストシステム上で実行しているアプリケーションプログラムは、順序付けられたデータセットとして各ファイルを生成し、固有の名前または他の基準によって識別する。他のファイルにまだ割り当てられていない充分に利用可能な論理アドレス空間は、ホストによってファイル1に割り当てられる。ファイル1は利用可能な論理アドレスの連続的な範囲に割り当てられたことが示されている。一般的に、アドレスの範囲は、ホストオペレーティングソフトウェアに対する特定範囲のような特定の目的のためにも割り当てられる。ホストが論理アドレスをデータに割り当てている時点で、これらアドレスが用いられなかったとしても、これらアドレスの範囲は、データを記憶するために回避される。
後にファイル2がホストによって生成されると、図7に示されているように、ホストは、論理アドレス空間161内の連続的なアドレスの2つの異なる範囲を同様に割り当てる。ファイルを連続的な論理アドレスに割り当てる必要はなくむしろ、他のファイルに既に割り当てられたアドレス範囲の間内のアドレス部分に割り当てることができる。この例は、次に、ホストによって生成されたさらなる別のファイル3が、ファイル1、ファイル2および他のデータにまだ割り当てられていないホストアドレス空間の他の部分に割り当てられることを示す。
ホストが様々なホストファイルに割り当てる論理アドレスが維持されるファイルアロケーションテーブル(FAT)を維持することによって、ホストはメモリ論理アドレス空間を追跡し続ける。一般的に、FATテーブルは、ホストメモリだけでなく不揮発性メモリにも記憶され、新たなファイルが記憶されたり、他のファイルが削除されたり、ファイルが修正されたりするので、ホストによって頻繁に更新される。例えば、ホストファイルが削除されると、次に、ホストは、FATテーブルを更新することによって、削除されたファイルに以前割り当てられた論理アドレスを割り当て解除して、これら論理アドレスが今では他のデータファイルで用いるために利用できることを示す。
ホストは、ファイルを記憶するのにメモリシステムコントローラが選択する物理位置について関心を持たない。一般的なホストは、論理アドレス空間、およびホストが様々なファイルに割り当てた論理アドレスだけを知っている。その一方で、メモリシステムは、一般的なホスト/カードインターフェイスを通じて、データが書き込まれた論理アドレス空間部分だけを知っているが、特定のホストファイルに割り当てられた論理アドレスを知らず、または、ホストファイルの数さえも知らない。メモリシステムコントローラは、データを記憶または取り出すためにホストによって供給された論理アドレスを、ホストデータが記憶されるフラッシュメモリセルアレイ内の固有の物理アドレスに変換する。ブロック163は、メモリシステムコントローラによって維持されるこれらの論理−物理アドレス変換の作業テーブルを表す。
メモリシステムコントローラは、システムの性能を高水準に維持するようにデータファイルをメモリアレイ165のブロックまたはメタブロック内に記憶するためにプログラムされる。4つのプレーンまたはサブアレイは、この図のように用いられる。各プレーンからブロックの形態を成すメタブロック全体にわたって、システムが許容できる限りの並列性でデータをプログラムし読み出すのが好ましい。一般的に、少なくとも1つのメタブロック167は、オペレーティングファームウェアと、メモリコントローラによって用いられるデータとを記憶する予約済みブロックとして割り当てられる。ホストオペレーティングソフトウェアおよびホストFATテーブルなどを記憶するために別のメタブロック169または複数のメタブロックを割り当てることができる。物理記憶空間の大部分は、データファイルを記憶するために残る。しかし、メモリコントローラは、受信したデータが様々なファイルオブジェクトのうちでホストによってどのように割り当てられたかを知らない。ホストによって特定の論理アドレスに書き込まれたデータが、コントローラの論理−物理アドレステーブル163によって維持されたような対応する物理アドレスに記憶されていることをすべてのメモリコントローラは一般的にホストとの対話から知る。
一般的なメモリシステムでは、アドレス空間161内にデータ量を記憶することが必要である数個の追加のブロックの記憶容量が設けられている。これら追加のブロックの1つ以上を、メモリの存続期間中に欠陥品になることがある他のブロックの代替とする冗長ブロックとして設けることができる。一般的に、最初はメタブロックに割り当てられた欠陥のあるブロックを冗長ブロックで代替することを含む様々な理由のために、個々のメタブロック内に含まれたブロックの論理グループを変更することができる。一般的に、メタブロック171のような1つ以上の追加のブロックは消去済みブロックプール内に維持される。ホストがデータをメモリシステムに書き込むと、コントローラは、ホストによって割り当てられた論理アドレスを消去済みブロックプール内のメタブロック内の物理アドレスに変換する。次に、データを論理アドレス空間161内に記憶するのに用いられていない他のメタブロックは消去され、その後のデータ書き込み動作中に用いるための消去済みプールブロックとして指定される。
特定のホスト論理アドレスに記憶されたデータは、最初に記憶されたデータが古くなると新たなデータによって頻繁に上書きされる。これに応答して、メモリシステムコントローラは新たなデータを消去済みブロックに書き込み、次に、これらの論理アドレスのデータが記憶される新たな物理ブロックを識別するためにこれらの論理アドレスに対して論理−物理アドレステーブルを変更する。次に、これらの論理アドレスの原データを含むブロックは消去され、新たなデータを記憶するために利用される。消去済みブロックプールからの事前消去済みブロック内の記憶容量が書き込みの開始で足りない場合、多くの場合、このような消去は、現在のデータ書き込み動作が完了できる前に行われる必要がある。このことは、システムデータプログラム速度に悪影響を及ぼすことがある。一般的に、メモリコントローラは、ホストが新たなデータを同一の論理アドレスに書き込むときだけ、所定の論理アドレスのデータが古くなったことがホストによって分かる。従って、メモリの多くのブロックにこのような無効なデータを一時的に記憶することがある。
集積回路メモリチップの領域を効率良く用いるためにブロックおよびメタブロックの大きさは増大している。この結果、個々のデータ書き込みの大部分が、メタブロックの記憶容量に満たないデータ量を記憶することになり、多くの場合、ブロックの記憶容量に満たないデータ量を記憶することさえある。一般的に、メモリシステムコントローラが新たなデータを消去済みプールメタブロックに誘導するので、このことによって、満たされない状態になるメタブロック部分が生じることがある。新たなデータが、別のメタブロックに記憶された一部のデータの更新情報である場合には、新たなデータのメタページの論理アドレスと隣接する論理アドレスを有するこの別のメタブロックから残りの有効なメタページのデータを論理アドレス順で新たなメタブロックへコピーするのも望ましい。古いメタブロックは、他の有効なデータメタページを保存することがある。この結果、長期にわたると、個々のメタブロックの特定のメタページのデータは古い状態にされ無効になり、異なるメタブロックに書き込まれた同一の論理アドレスを有する新たなデータによって置き換えられることになる。
論理アドレス空間161の全体にわたってデータを記憶するのに充分な物理メモリ空間を維持するため、このようなデータは周期的に圧縮または統合される(ガーベッジコレクション)。可能な限り論理アドレスと同じ順序でメタブロック内のセクタのデータを維持することも望ましい。その理由は、このことが、連続的な論理アドレスで効率良くデータを読み出させるためである。従って、この追加の目標を伴ってデータ圧縮およびガーベッジコレクションが一般的に実行される。一部のブロックデータの更新情報を受信するときにメモリを管理する幾つかの態様と、メタブロックの使用とについては、米国特許第6,763,424号(特許文献14)に記載されている。
一般的に、データ圧縮は、処理中、無効データを有するメタページを無視して、すべての有効なデータメタページをメタブロックから読み出し、これらを新たなブロックに書き込むことを含む。また、有効データを有するメタページを、これらに記憶されたデータの論理アドレス順に一致する物理アドレス順で配置するのが好ましい。無効データを含むメタページが新たなメタブロックへコピーされないので、新たなメタブロックに占められるメタページの数は、古いメタブロックに占められるメタページに満たない。次に、古いブロックは消去され、新たなデータを記憶するために利用される。統合によって獲得された容量の追加のメタページをその後に他のデータを記憶するのに用いることができる。
ガーベッジコレクション中、連続的またはほぼ連続的な論理アドレスを有する有効データのメタページは2つ以上のメタブロックから収集され、別のメタブロック、一般的には、消去済みブロックプール内のメタブロックに再度書き込まれる。すべての有効なデータメタページが元の2つ以上のメタブロックからコピーされる場合、それらを将来使用するために消去することができる。
データの統合およびガーベッジコレクションは時間を取り、特に、ホストからのコマンドを実行できる前にデータの統合またはガーベッジコレクションを行う必要がある場合にはメモリシステムの性能に影響を及ぼすことがある。一般的に、このような動作は、可能な限りバックグラウンドで行われるようにメモリシステムコントローラによってスケジュールされるが、これらの動作を実行する必要性によって、コントローラは、このような動作が完了するまでビジーステート信号をホストに与えなければならない。ホストコマンドの実行を遅延する場合がある例として、ホストがメモリに書き込みたいと思う全データを記憶する事前消去済みメタブロックが消去済みブロックプール内に不足し、後で消去できる1つ以上のメタブロックの有効データをクリアするためにデータの統合またはガーベッジコレクションが最初に必要とされる場合が挙げられる。従って、このような混乱を最小限にするため、メモリの制御を管理することに注意が向けられた。多くのこのような技術は、「大きな消去ブロックを有する不揮発性メモリシステムの管理」という2003年12月30日に出願された米国特許出願第10/749,831号(特許文献15)、「不揮発性メモリおよびブロック管理システムを伴う方法」という2003年12月30日に出願された米国特許出願第10/750,155号(特許文献16)、「不揮発性メモリおよびメモリプレーン配列を伴う方法」という2004年8月13日に出願された米国特許出願第10/917,888号(特許文献17)、2004年8月13日に出願された米国特許出願第10/917,867号(特許文献18)、「不揮発性メモリおよびフェーズ化されたプログラム障害処理を伴う方法」という2004年8月13日に出願された米国特許出願第10/917,889号(特許文献19)、および「不揮発性メモリおよび制御データ管理を伴う方法」という2004年8月13日に出願された米国特許出願第10/917,725号(特許文献20)に記載されている。
極めて大規模な消去済みブロックを有するメモリアレイの動作を効率良く制御する1つの課題は、所定の書き込み動作中に記憶されるデータセクタの数をメモリのブロックの容量および境界と一致させ、位置合わせすることである。1つのアプローチは、最大数のブロックに満たないホストから新たなデータを記憶するのに用いられるメタブロックを構成し、必要に応じて、メタブロック全体を満たす量に満たないデータ量を記憶することである。適応メタブロックの使用については、「適応メタブロック」という2003年12月30日に出願された米国特許出願第10/749,189号(特許文献21)に記載されている。データのブロック間の境界とメタブロック間の物理境界との適合については、2004年5月7日出願の米国特許出願第10/841,118号(特許文献22)、および、「データ・ラン・プログラミング」という2004年12月16日に出願された米国特許出願第11/016,271号(特許文献23)に記載されている。
メモリコントローラは、ホストによって不揮発性メモリに記憶されたFATテーブルからデータを使用しても、メモリシステムを効率良く動作することができる。このような使用の1つは、論理アドレスを割り当て解除することによって、データが古いとホストによって識別された時点を知ることである。この時点を知ることは、一般的に、ホストが新たなデータを論理アドレスに書き込むことによってメモリコントローラがそれを知る前に、このような無効データを含むブロックの消去をメモリコントローラにスケジュールさせることができる。このことについては、「不揮発性メモリシステム上のデータを保持するための方法および装置」という2004年7月21日に出願された米国特許出願第10/897,049号(特許文献24)に記載されている。他の技術には、所定の書き込み動作が単一ファイルであるかどうかを推定し、複数ファイルである場合、ファイル間の境界がどこに位置するかを推定するために、新たなデータをメモリに書き込むホストパターンを監視することが含まれる。この種類の技術の使用については、「最適化された一連のクラスタ管理のためのFAT解析」という2004年12月23日に出願された米国特許出願第11/022,369号(特許文献25)に記載されている。
メモリシステムを効率良く動作するため、ホストによって個々のファイルのデータに割り当てられた論理アドレスについてコントローラができる限り良く分かることが望ましい。ファイル境界が分かっていない場合、データファイルが多数のメタブロックの間で分散されるというよりはむしろ、コントローラによってデータファイルを単一メタブロックまたはメタブロックグループに記憶することができる。この結果、データの統合およびガーベッジコレクション動作の数および複雑性を減少させる。結果としてメモリシステムの性能は改善する。しかし、ホスト/メモリインターフェイスが、前述したような論理アドレス空間161(図7)を含む場合、メモリコントローラがホストデータファイル構造を良く分かることは困難である。
図8に関して、図7に既に示されている一般的な論理アドレスホスト/メモリインターフェイスは、図8で異なるように示されている。ホストによって生成されたデータファイルは、ホストによって論理アドレスに割り当てられている。次に、メモリシステムはこれら論理アドレスを見て、データが実際に記憶されるメモリセルのブロックの物理アドレスにマッピングする。
例示的なファイルベースのインターフェイスの実施形態の説明
大容量のデータを記憶するため、ホストとメモリシステムとの間での改善されたインターフェイスは、論理アドレス空間の使用を削減する。代わりに、ホストは固有のファイルID(または、他の固有の基準)によって各ファイルを論理的にアドレス指定し、ファイル内の(バイトのような)データの単位のアドレスをオフセットする。このファイルアドレスはメモリシステムコントローラに直接に与えられ、メモリシステムコントローラは、各ホストファイルのデータが物理的に記憶されるメモリシステムコントローラ自体のテーブルを保持する。この新たなインターフェイスを、図2〜図6に関して前述したのと同じメモリシステムで実施することができる。前述したメモリシステムとの主な違いは、メモリシステムがホストシステムと通信する方法である。
大容量のデータを記憶するため、ホストとメモリシステムとの間での改善されたインターフェイスは、論理アドレス空間の使用を削減する。代わりに、ホストは固有のファイルID(または、他の固有の基準)によって各ファイルを論理的にアドレス指定し、ファイル内の(バイトのような)データの単位のアドレスをオフセットする。このファイルアドレスはメモリシステムコントローラに直接に与えられ、メモリシステムコントローラは、各ホストファイルのデータが物理的に記憶されるメモリシステムコントローラ自体のテーブルを保持する。この新たなインターフェイスを、図2〜図6に関して前述したのと同じメモリシステムで実施することができる。前述したメモリシステムとの主な違いは、メモリシステムがホストシステムと通信する方法である。
このファイルベースのインターフェイスを図9に示す。図9のファイルベースのインターフェイスを、図7の論理アドレスインターフェイスと比較すべきである。ファイル1、ファイル2およびファイル3の各々の識別と、図9のファイル内のデータのオフセットとは、メモリコントローラに直接に受け渡される。次に、この論理アドレス情報は、メモリコントローラ機能173によってメモリ165のメタブロックおよびメタページの物理アドレスに変換される。
ファイルベースのインターフェイスを図10にも示す。図10のファイルベースのインターフェイスを、図8の論理アドレスインターフェイスと比較すべきである。図10には、図8の論理アドレス空間と、ホストによって維持されるFATテーブルとは存在しない。それどころか、ホストによって生成されたデータファイルは、ファイル番号およびファイル内のデータのオフセットによってメモリシステムに識別される。次に、メモリシステムは、ファイルをメモリセルアレイの物理ブロックに直接マッピングする。
図11に関して、本願明細書で説明されている例示的な大容量記憶システムの機能層が示されている。「直接ファイル記憶バックエンドシステム」は、主として本願明細書の主題である。直接ファイル記憶バックエンドシステムは、メモリシステムの動作に対して内側にあり、「直接ファイルインターフェイス」および「ファイルベースのフロントエンドシステム」を介してファイルベースのインターフェイスチャネル上のホストシステムと通信する。各ホストファイルは、例えばファイル名によって一意的に識別される。ファイル内のデータは、ファイルに固有の線形アドレス空間内のオフセットアドレスによって識別される。メモリシステムに対して論理アドレス空間を定義する必要はない。
コマンド
ホストシステムからの一連の直接ファイルインターフェイスコマンドは、メモリシステムの動作を支援する。このような一連のコマンドの一例を図12A〜12Eに示す。本願明細書の残りの部分を通じて参照するため、本願明細書では、これらコマンドを簡単に要約するだけである。図12Aは、定義プロトコルに従ってデータをホストとメモリシステムとの間で転送させるのに用いられるホストコマンドをリストする。ファイル内の特定オフセット(<offset>)の指定されたファイル(<fileID>)内のデータは、メモリシステムに書き込まれるか、またはメモリシステムから読み出される。Write、InsertまたはUpdateコマンドの伝送を行った後に、ホストからメモリシステムへのデータの伝送を行い、メモリシステムは、データをメモリアレイに書き込むことによって応答する。ホストによるReadコマンドの伝送は、指定されたファイルのデータをホストに送信することによってメモリシステムに応答させる。メモリシステムが、ファイルの追加のデータを記憶できる次の記憶位置を識別するポインタを維持する場合、データオフセットをWriteコマンドと一緒に送信する必要はない。しかし、Writeコマンドが、既に書き込まれたファイル内にオフセットアドレスを含む場合、メモリ装置は、オフセットアドレスから開始するファイルデータを更新するコマンドであると解釈することができ、従って、別個のUpdateコマンドの必要性を削減する。Readコマンドに対して、ファイル全体が読み出される場合、ホストによってデータオフセットを指定する必要はない。図12Aに示されているデータコマンドのうち1つのデータコマンドの実行は、ホストシステムによる何か他のコマンドの伝送に応答して終了される。
ホストシステムからの一連の直接ファイルインターフェイスコマンドは、メモリシステムの動作を支援する。このような一連のコマンドの一例を図12A〜12Eに示す。本願明細書の残りの部分を通じて参照するため、本願明細書では、これらコマンドを簡単に要約するだけである。図12Aは、定義プロトコルに従ってデータをホストとメモリシステムとの間で転送させるのに用いられるホストコマンドをリストする。ファイル内の特定オフセット(<offset>)の指定されたファイル(<fileID>)内のデータは、メモリシステムに書き込まれるか、またはメモリシステムから読み出される。Write、InsertまたはUpdateコマンドの伝送を行った後に、ホストからメモリシステムへのデータの伝送を行い、メモリシステムは、データをメモリアレイに書き込むことによって応答する。ホストによるReadコマンドの伝送は、指定されたファイルのデータをホストに送信することによってメモリシステムに応答させる。メモリシステムが、ファイルの追加のデータを記憶できる次の記憶位置を識別するポインタを維持する場合、データオフセットをWriteコマンドと一緒に送信する必要はない。しかし、Writeコマンドが、既に書き込まれたファイル内にオフセットアドレスを含む場合、メモリ装置は、オフセットアドレスから開始するファイルデータを更新するコマンドであると解釈することができ、従って、別個のUpdateコマンドの必要性を削減する。Readコマンドに対して、ファイル全体が読み出される場合、ホストによってデータオフセットを指定する必要はない。図12Aに示されているデータコマンドのうち1つのデータコマンドの実行は、ホストシステムによる何か他のコマンドの伝送に応答して終了される。
別のデータコマンドはRemoveコマンドである。図12Aの他のデータコマンドとは異なって、Removeコマンドの後にデータの伝送は行われない。その効果は、メモリシステムに、指定されたoffset1とoffset2との間のデータに古いとしてマークを付けさせることである。次に、これらのデータは、古いデータが存在するファイルまたはブロックの次のデータの圧縮またはガーベッジコレクション中に除去される。
図12Bには、メモリシステム内のファイルを管理するホストコマンドをリストする。ホストが新たなファイルのデータをメモリシステムに書き込もうとしているとき、ホストは最初にOpenコマンドを送出し、メモリシステムは、新たなファイルを開くことによって応答する。同時に開いたままでいられるファイルの数は一般的に指定される。ホストがファイルを閉じる場合、Closeコマンドは、開いたファイルを維持するのに用いられるリソースを指定変更できることをメモリシステムに伝える。一般的に、メモリシステムは、このようなファイルをガーベッジコレクションのために直ちにスケジュールする。今、説明している直接ファイルインターフェイスを用いて、ガーベッジコレクションは、個々のメモリセルブロックを用いて物理的にではなく、論理的に管理され、主にファイルについて実行される。Close_afterコマンドは、ファイルが閉じられようとしているという先行通知をメモリシステムに与える。ファイルDeleteコマンドは、削除済みファイルからのデータを含むメモリセルブロックを、指定された優先規則に従って消去するようにメモリシステムに直ちにスケジュールさせる。Eraseコマンドは、指定されたファイルのデータをメモリから直ちに消去すべきことを指定する。
DeleteコマンドとEraseコマンドとの主な違いは、指定されたファイルデータを消去するために与えられた優先順位である。ホストは、Eraseコマンドを用いて、最も早い実用的な時間で保護または機密データをメモリから除去することができ、その一方で、Deleteコマンドは、低い優先順位を付けてこのようなデータを消去させる。メモリシステムをパワーダウンするときのEraseコマンドの使用は、メモリ装置がホストから除去される前に機密データを除去し、従って、メモリ装置をその後に使用する間、このデータを他のユーザまたはホストシステムに拡散しないようにする。これらのコマンドの双方をバックグラウンドで実行し、すなわち、主なデータコマンド(図12A)の実行を減速させることなく実行するのが好ましい。いずれにしても、一般的に、ホストから別のコマンドを受信することによって、メモリコントローラはバックグラウンド動作を終了させることになる。
メモリシステム内のディレクトリに関連するホストコマンドを図12Cにリストする。各ディレクトリコマンドは、コマンドが関連するディレクトリの識別子(<directoryID>)を含む。メモリシステムコントローラはディレクトリを維持するが、ディレクトリに関するコマンドおよびディレクトリの指定は、ホストシステムによって与えられる。メモリコントローラは、ホストによって与えられたディレクトリの指定と共にこれらのコマンドを、メモリシステムに記憶されたファームウェアに従って実行する。
<fileID>パラメータを、ファイルの絶対パス名、または本願明細書ではfile_handleと称するファイルの何らかの省略表現識別子のどちらかとすることができる。ファイルパス名は、特定のコマンドと関連して図11の直接ファイルインターフェイスに供給される。これによって、ファイルが初めて開かれたとき、充分に明白な項目をファイルディレクトリに生成することができ、既存のファイルが開かれたとき、ファイルディレクトリ内の正しい既存の項目にアクセスすることができる。ファイルパス名構文は、DOSファイルシステムによって用いられる規格に準拠することができる。パス名は、ディレクトリの階層とディレクトリの最下位のファイルとを記述する。パスセグメントを「\」によって区切ることができる。「\」が前に付いたパスは、ルートディレクトリに関連する。「\」が前に付かないパスは、カレントディレクトリに関連する。「..」のセグメントパスは、カレントディレクトリの親ディレクトリを示す。
あるいはまた、ファイルが最初に生成されたときに記憶装置によって割り当てられたfile_handleパラメータによって、開いたファイルを識別することができる。次に、ホストがファイルを開くたびに、記憶装置は、ホストに指定された省略表現ファイルと通信することができる。次に、ホストは、開いたファイルのWrite、Insert、Update、Read、CloseおよびClose_afterコマンドと共にfile_handleを用いることができる。ファイルディレクトリの階層をナビゲートする必要がないので、一般的に、ホストによるファイルへのアクセスは、絶対パス名が用いられる場合よりも速い。Openコマンドの使用によってファイルが最初に開かれる場合、メモリシステムによってこのファイルにfile_handleがまだ割り当てられてない可能性が高いので、一般的に絶対パス名が用いられる。しかし、既に利用可能である場合、file_handleを用いることができる。fileIDを用いる図12Aおよび図12Bの残りのDeleteおよびEraseコマンドに対して、完全なファイルパス名の使用は、ホストによって供給された誤ったfile_handleに対する安全対策とするのが好ましい。ホストが、意図的ではない既存のファイルの1つに一致する誤ったパス名を不注意で生成するのは困難である。
図12Cのディレクトリコマンドは、これらが関連するディレクトリの<directoryID>識別子と共に図11の直接ファイルインターフェイスによって同じように受信される。絶対パス名は、ディレクトリコマンドと共に受信されたdirectoryIDとするのが好ましい。
file_handleは、直接ファイルインターフェイスにおいて大容量記憶装置によってOpenコマンドに応答してホストに返信される簡易書式の識別子である。ファイルに対するディレクトリ項目に存在するFITへのポインタであるとしてfile_handleを定義するのが便利である。このポインタは、ファイルに対するブロック内の論理FITブロック番号および論理ファイル番号を定義する。ポインタをfile_handleとして用いることによって、最初にファイルディレクトリ内のファイルを検索する必要なしにファイルFIT項目にアクセスすることができる。例えば、メモリ装置が64個までのFITブロックを有することができる場合、各FITブロックは64個までのファイルに索引を付けることができ、この場合、file_handle1107を有するファイルは、FITブロック11内の論理ファイル7に設定されたFIT内のデータグループ項目へのポインタを有する。ファイルに対するディレクトリおよびFIT項目がOpenコマンドに応答して生成されと、このfile_handleはメモリシステムコントローラによって生成され、Closeコマンドに応答して無効になる。
図12Dには、ホストとメモリシステムとの間のインターフェイスの状態を管理するホストコマンドを示す。Idleコマンドは、前もってスケジュールされたデータ消去およびガーベッジコレクションのような内部動作をメモリシステムが実行できることをメモリシステムに伝える。Standbyコマンドの受信に応答して、メモリシステムは、ガーベッジコレクションおよびデータ消去のようなバックグラウンド動作の実行を停止する。Shut−downコマンドは、差し迫っている電源の損失について事前の警告をメモリコントローラに与え、これによって、揮発性コントローラバッファから不揮発性フラッシュメモリへデータを書き込むことを含む保留中のメモリ動作の完了を可能にする。
図12Eに示されているSizeコマンドは、一般的に、Writeコマンドよりも前にホストによって送出される。これに応答して、メモリシステムは、書き込まれるさらなるファイルデータに利用できる容量をホストに報告する。この容量を、利用可能なプログラムされていない物理容量から、定義されたファイルデータ容量の記憶を管理するのに必要とされる物理容量を差し引くことによって計算することができる。
ホストがStatusコマンド(図12E)を送出する場合、メモリ装置は現在の状況で応答する。この応答を、メモリ装置に関する情報の様々な特定の項目をホストに供給する異なるビット領域を有する1つ以上の2進ワードの形態とすることができる。例えば、1つの2ビット領域は、装置がビジー状態であるかどうかを報告し、装置がビジー状態である場合、メモリ装置が何をするためにビジー状態になっているのかに応じて2つ以上のビジーステータスを供給することができる。1つのビジーステータスは、ホストWriteまたはReadコマンドを実行してデータを転送すること、すなわちフォアグラウンド動作にメモリ装置が対応していることを示すことができる。第2のビジーステータスの指示を用いて、メモリシステムがデータの圧縮またはガーベッジコレクションのようなバックグラウンドハウスキーピング動作を実行しているときをホストに伝えることができる。ホストは、別のコマンドをメモリ装置に送信する前にこの第2のビジー状態の終わりまで待機するかどうかを決定することができる。ハウスキーピング動作が完了する前に別のコマンドが送信される場合、メモリ装置はハウスキーピング動作を終了し、コマンドを実行する。
ホストはIdleコマンドと一緒に第2の装置ビジーを用いることができ、これによって、メモリ装置内でハウスキーピング動作を行うことができる。装置がハウスキーピング動作を行う必要性を生じさせる可能性が高いコマンドまたは一連のコマンドをホストが送信した後、ホストはIdleコマンドを送信することができる。後で説明するように、ハウスキーピング動作を開始することによってIdleコマンドに応答し、これと同時に、前述した第2のビジーを開始するようにメモリ装置をプログラムすることができる。例えば、Deleteコマンドは、以下で説明するアルゴリズムに従って、ガーベッジコレクションを実行する必要性を生じさせる。この場合、一連のDeleteコマンドを送出した後のホストからのIdleコマンドは、メモリ装置が次のホストWriteコマンドに応答できるために必要であるガーベッジコレクションを実行する装置時間を可能にする。そうでなければ、次のWriteコマンドを受信した後で、このWriteコマンドを実行することができる前にガーベッジコレクションを実行する必要があり、従って、このコマンドの実行を著しく減速せせることになる。
データの書き込み
新たなデータファイルがメモリにプログラムされるとき、ブロック内の第1の物理位置から始まって、ブロックの位置を連続的に順々に進行するように、データはメモリセルの消去済みブロックに書き込まれる。ファイル内のこのデータのオフセットの順序にかかわらず、データは、ホストから受信した順序でプログラムされる。ファイルの全データがメモリに書き込まれるまでプログラム動作は継続する。ファイルのデータ量が単一メモリブロックの容量を上回る場合、第1のブロックはいっぱいになり、プログラム動作は、消去済みの第2のブロックに継続する。第2のメモリブロックは、ファイルの全データが記憶されるまで、または、第2のブロックがいっぱいになるまで第1の位置から順々に第1のブロックと同様にプログラムされる。ファイルの残りのデータで第3または追加のブロックをプログラムすることができる。単一ファイルのデータを記憶する複数ブロックまたはメタブロックを物理的または論理的に連続にする必要はない。説明を容易にするため、他に特に指定がなければ、本願明細書で用いられる「ブロック」という用語は、特定のシステムにメタブロックが用いられているかどうかに応じて消去のブロック単位または複数ブロック「メタブロック」のどちらかを意味するものとする。
新たなデータファイルがメモリにプログラムされるとき、ブロック内の第1の物理位置から始まって、ブロックの位置を連続的に順々に進行するように、データはメモリセルの消去済みブロックに書き込まれる。ファイル内のこのデータのオフセットの順序にかかわらず、データは、ホストから受信した順序でプログラムされる。ファイルの全データがメモリに書き込まれるまでプログラム動作は継続する。ファイルのデータ量が単一メモリブロックの容量を上回る場合、第1のブロックはいっぱいになり、プログラム動作は、消去済みの第2のブロックに継続する。第2のメモリブロックは、ファイルの全データが記憶されるまで、または、第2のブロックがいっぱいになるまで第1の位置から順々に第1のブロックと同様にプログラムされる。ファイルの残りのデータで第3または追加のブロックをプログラムすることができる。単一ファイルのデータを記憶する複数ブロックまたはメタブロックを物理的または論理的に連続にする必要はない。説明を容易にするため、他に特に指定がなければ、本願明細書で用いられる「ブロック」という用語は、特定のシステムにメタブロックが用いられているかどうかに応じて消去のブロック単位または複数ブロック「メタブロック」のどちらかを意味するものとする。
図13Aに関して、メモリシステムへのデータファイルの書き込みを示す。この例では、データファイル181は、垂直の実線間に延在すると示されたメモリシステムの1つのブロックまたはメタブロック183の記憶容量よりも大きい。従って、データファイル181の部分184は第2のブロック185にも書き込まれている。これらのメモリセルブロックは物理的に連続であるように示されているが、必ずしも連続である必要はない。ファイル181からのデータは、ホストから受信したストリーミングであるので、ファイルの全データがメモリに書き込まれるまで書き込まれる。図13Aの例では、データ181は、図12AのWriteコマンドの後にホストから受信したファイルの初期データである。
記憶されたデータを管理し追跡し続けるメモリシステムにとって好適な方法は、可変サイズのデータグループを用いることである。すなわち、ファイルのデータは、完全なファイルを形成するように、定義された順序で互いに連結できる複数のデータグループとして記憶される。しかし、好ましくは、ファイル内のデータグループの順序は、ファイル索引テーブル(FIT)を用いてメモリシステムコントローラによって維持される。ホストからデータのストリームが書き込まれているとき、ファイルデータの論理オフセットアドレス、または、データが記憶される物理空間のどちらかに途切れがあるときはいつでも、新たなデータグループが開始される。このような物理的な途切れの一例として、ファイルのデータが1つのブロックを満たし、別のブロックに書き込まれ始めるときが挙げられる。このことは図13Aに示され、第1のデータグループが第1のブロック183を満たし、ファイルの残りの部分184は、第2のデータグループとして第2のブロック185内に記憶される。第1のデータグループを(F0,D0)によって表すことができ、ここで、F0は、データファイルの始まりの論理オフセットであり、D0は、ファイルが始まるメモリ内の物理位置である。第2のデータグループは(F1,D1)として表され、ここで、F1は、第2のブロック185の始まりで記憶されるデータの論理ファイルオフセットであり、D1は、データが記憶される物理位置である。
ホスト−メモリインターフェイスを介して転送されるデータの量をデータのバイトの数、データのセクタの数、または、何らかの他の粒度で表現することができる。ほとんどの場合、ホストはファイルのデータをバイト粒度で定義するが、その一方で、現在の論理アドレスインターフェイスを介して大容量メモリシステムと通信する場合、バイトをそれぞれ512バイトのセクタに、または、それぞれ複数セクタのクラスタにグループ化する。一般的に、このことは、メモリシステムの動作を簡単化するために行われる。本願明細書で説明されているファイルベースのホスト−メモリインターフェイスは何らかの他のデータ単位を用いることができるが、一般的に、最初のホストファイルのバイト粒度が好ましい。すなわち、データオフセットおよび長さなどを、(1つ以上の)セクタまたは(1つ以上の)クラスタなどによるよりはむしろ(1つ以上の)バイトすなわち最小の合理的なデータ単位で表現するのが好ましい。これによって、本願明細書で説明されている技術と共にフラッシュメモリ記憶の容量を効率良く用いることができる。
一般的な既存の論理アドレスインターフェイスでは、ホストは、書き込まれるデータの長さをも指定する。このことも、本願明細書で説明されているファイルベースのインターフェイスを用いて行うことができるが、Writeコマンド(図12A)を実行する必要がないので、ホストは、書き込まれるデータの長さを供給しないことが好ましい。
図13Aに示されているようにメモリに書き込まれた新たなファイルは、次に、データグループに対して一連の索引項目(F0,D0),(F1,D1)としてこの順序でFIT内に表される。すなわち、ホストシステムが特定のファイルにアクセスしたいときはいつでも、ホストはfileIDまたは他の識別子をメモリシステムに送信し、メモリシステムはFITにアクセスして、このファイルを構成するデータグループを識別する。個々のデータグループの長さ<length>も、メモリシステムの動作の都合上、個々の項目に含めることができる。使用時、メモリコントローラは、データグループの長さを計算し記憶する。
ホストが、開かれた状態で図13Aのファイルを維持する限りは、物理的な書き込みポインタPも維持して、このファイルに対してホストから受信したさらなるデータを書き込む位置を定義するのが好ましい。ファイルの任意の新たなデータは、ファイル内の新たなデータの論理位置にかかわらず物理メモリのファイルの終わりに書き込まれる。メモリシステムは複数のファイル、例えば4または5個のファイルを同時に開いたままにさせることができ、ファイルごとの書き込みポインタPを維持する。異なるファイルの書き込みポインタは、異なるメモリブロックの位置を指し示す。開いたファイルの数のメモリシステム限界が既に存在するときにホストシステムが新たなファイルを開きたい場合、開かれたファイルの1つが最初に閉じられ、新たなファイルが次に開かれる。ファイルが閉じられた後、このファイルに対して書き込みポインタPを維持する必要はもはやない。
図13Bには、以前に書き込まれたが依然として開いた状態の図13Aのファイルの終わりにホストによってデータを、Writeコマンド(図12A)を用いて付加することを示す。このファイルのデータの終わりの第2のブロック185にも書き込まれているデータ187がホストシステムによってファイルの終わりに追加されると示されている。既存のデータグループ184と、付加されたデータ189との間で論理アドレスにも物理アドレスにも途切れが存在しないので、付加されたデータはデータグループ(F1,D1)の一部となり、従って、データグループ(F1,D1)は、より多くのデータを含むことになる。従って、完全なファイルは、FIT内で一連の索引項目(F0,D0),(F1,D1)として依然として表される。また、ポインタPのアドレスは、記憶された付加されたデータの終わりのアドレスに変更される。
以前に書き込まれた図13Aのファイルへデータ191のブロックを挿入する一例を図13Cに示す。ホストは、データ191をファイルに挿入するが、メモリシステムは、挿入されたデータを、以前にデータが書き込まれたファイルの終わりにある位置193に付加する。データが、開いたファイルにデータが挿入されているとき、ファイルのデータを論理順に再度書き込む必要はない。しかし、このことを、ホストがファイルを閉じた後、バックグラウンドで行うことができる。挿入されたデータは、第2メモリブロック185内に完全に記憶されるので、単一の新たなグループ(F1,D3)を形成する。しかし、この挿入を行うことによって、結果として、図13Aの以前のデータグループ(F0,D0)は2つのグループ、すなわち、挿入前のデータグループ(F0,D0)と挿入後のデータグループ(F2,D1)とに分割される。その理由は、挿入の始まりF1と挿入の終わりF2とで生じるようなデータの論理的な途切れが存在するときはいつでも、新たなデータグループを形成する必要があるためである。グループ(F3,D2)は、第2のブロック185の始まりである物理アドレスD2の結果である。グループ(F1,D3)およびグループ(F3,D2)は、それらが同じメモリブロックに記憶されているとしても別々に維持される。その理由は、それらに記憶されたデータのオフセットに途切れがあるためである。挿入部分を有する原ファイルは、メモリシステムFIT内にデータグループ索引項目(F0,D0),(F1,D3),(F2,D1),(F3,D2)によってこの順序で表される。図13A、図13Bおよび図13Cの例から、新たなファイルまたは既存のファイルの新たなデータを、メモリ内のデータのいずれをも古い状態にしないで書き込むことができることに留意すべきである。すなわち、WriteコマンドおよびInsertコマンド(図12A)の実行によって、他のいかなるデータをも無効または古くさせることはない。
図13Dには、別の例を示す。図13Aに示されているように最初に書き込まれたデータの特定部分は、Updateコマンド(図12A)を用いて更新される。データファイルの部分195は更新されたと示されている。更新情報を用いて全部のファイルをメモリシステムに再度書き込むよりはむしろ、ファイルの更新された部分197は、以前に書き込まれたデータに付加される。以前に書き込まれたデータの部分199は、もう古い。古いデータによって占められた空間を開放するため、一般的に、更新されたファイルを統合するのが望ましいが、ホストが、開かれたファイルを維持している間、一般的にファイルの統合が行われないのではなくむしろ、ファイルが閉じられた後にバックグラウンドで行うことができる。更新後、ファイルは、メモリシステムFIT内にデータグループ索引項目(F0,D0),(F1,D3),(F2,D1),(F3,D2)によってこの順序で表される。図13Aの単一のデータグループ(F0,D0)は、図13Dの部分、すなわち、更新された部分よりも前の部分と、更新された部分と、更新された部分よりも後の部分とにこの場合も分割される。
可変長のデータグループの使用をさらに示すため、同一のファイルを含む一連の幾つかの書き込み動作を、図14〜図14Eによって順々に示す。図14Aに示されているように最初に原ファイルデータW1は、Writeコマンド(図12A)を用いてメモリシステムの2つのブロックに書き込まれる。次に、ファイルは2つのデータグループによって定義される。第1のグループは物理メモリブロックの始まりで開始し、第2のグループは物理メモリブロック境界の後で必要とされる。従って、図14Aのファイルは、一連のデータグループ索引項目(F0,D0),(F1,D1)によって記述される。
図14Bでは、図14Aにおいて書き込まれたファイルデータは、Updateコマンド(図12A)を用いて更新される。更新されたファイルデータU1は以前のグループ(F1,D1)の直後に書き込まれ、更新されたデータの前バージョンは古くなる。図14Aの以前のグループ(F0,D0)は、図14Bの修正されたグループ(F0,D0)に短縮され、以前のグループ(F1,D1)は、グループ(F4,D2)に短縮される。更新されたデータは、それらがメモリブロックの境界に重なり合うので2つのグループ(F2,D3)および(F3,D4)に書き込まれる。データの一部は、第3のメモリブロックに記憶される。ファイルは、一連のデータグループ索引項目(F0,D0),(F2,D3),(F3,D4),(F4,D2)によって記述されようになる。
図14Bのファイルは、Insertコマンド(図12A)を用いて新たなファイルデータI1の挿入によって図14Cにおいてさらに変更される。挿入されたデータがメモリブロックの境界に重なり合うので、新たなデータI1は、図14Bの以前のグループ(F4,D2)の直後に、図14Cの新たなグループ(F5,D6)および(F6,D7)としてメモリに書き込まれる。第4のメモリブロックが用いられる。図14Bの以前のグループ(F0,D0)は、新たなデータI1の挿入のため、図14Cにおいて、短縮されたグループ(F0,D0)および(F7,D5)に分割される。ファイルは、一連のデータグループ索引項目(F0,D0),(F5,D6),(F6,D7),(F7,D5),(F8,D3),(F9,D4),(F10,D2)によって記述されるようになる。
図14Dには、Writeコマンド(図12A)を用いて新たなデータW2をファイルの終わりに付加する図14Cのデータファイルのさらなる変更を示す。新たなデータW2は、図14Dの新たなグループ(F11,D8)として図14Cの以前のグループ(F10,D2)の直後に書き込まれる。ファイルは、一連のデータグループ索引項目(F0,D0),(F5,D6),(F6,D7),(F7,D5),(F8,D3),(F9,D4),(F10,D2),(F11,D8)によって記述されるようになる。
開いたファイルの第2の更新を図14Eに示す。更新されたファイルデータU2は、ホストがUpdateコマンド(図12A)を送出することによって図14Dのファイルに書き込まれる。図14Eにおいて、更新されたデータU2は、図14Dの以前のグループ(F11,D8)の直後に書き込まれ、このデータの前バージョンは古くなる。図14Dの以前のグループ(F9,D4)は、図14Eの修正されたグループ(F9,D4)に短縮され、以前のグループ(F10,D2)は完全に古くなり、以前のグループ(F11,D8)は、新たなグループ(F14,D9)を形成するように短縮される。ブロック境界に重なり合う更新されたデータは、図14Eの新たなグループ(F12,D10)および(F13,D11)に書き込まれる。次に、第5のブロックはファイルを記憶するのに必要とされる。ファイルは、一連のデータグループ索引項目(F0,D0),(F5,D6),(F6,D7),(F7,D5),(F8,D3),(F9,D4),(F12,D10),(F13,D11),(F14,D9)によって記述されようになる。
前述した説明に従ってファイルを生成または変更した後、各ファイルのデータのオフセットを正しい論理順序で連続して維持するのが好ましい。従って、例えば、Insertコマンドを実行する一部として、ホストによって供給された挿入されたデータのオフセットは、挿入の直前にあるオフセットと、挿入されたデータの量だけ挿入が増加された後のファイル内に既にあるデータとから連続する。一般的に、Updateコマンドは、同量の更新されたデータによって置き換えられる既存のファイルの所定のアドレス範囲内にデータを生じさせ、これによって、一般的に、ファイルの他のデータのオフセットを置き換える必要はない。別個のUpdateコマンドの代わりに、Writeコマンドを用いることによってもファイルのデータを更新することができる。その理由は、記憶されたファイルデータに既に存在するオフセットの範囲を有するホストからのデータの受信を、メモリシステムによって、このオフセットの範囲内でデータを更新する命令と解釈することができるためである。
図13および図14によって示されている前述したデータ割り当ておよび索引付け機能のすべてがメモリシステムのコントローラによって実行されることに留意すべきである。ホストは、図12AのWrite、InsertまたはUpdateコマンドの1つと一緒に、メモリシステムに送信されるfileIDおよびファイル内のデータのオフセットを伝達するだけである。メモリシステムは残りの部分を行う。
今述べたようにホストからフラッシュメモリにファイルデータを直接に書き込む利点は、このように記憶されたデータの粒度または分解能を、ホストにおけるデータの粒度または分解能と同じように維持できるということである。例えば、ホストアプリケーションがファイルデータを1バイトの粒度で書き込む場合、このデータを1バイトの粒度でフラッシュメモリにも書き込むことができる。次に、個々のデータグループのデータの量および位置はバイトの数で測定される。すなわち、ホストアプリケーションファイル内に別々にアドレス可能であるデータの同一オフセット単位は、フラッシュメモリ内に記憶されたときにもファイル内で別々にアドレス可能である。従って、ブロック内の同一ファイルのデータグループの間の境界は、索引テーブル内で、最も近いバイトまたは他のホストオフセット単位で指定される。これと同様に、ブロック内の異なるファイルのデータグループの間の境界は、ホストオフセットの単位で定義される。
Deleteコマンドはデータを書き込むのには用いられないが、Deleteコマンドの使用を考慮することは、ファイルの一部を削除することに関連する。その理由は、このような動作がInsertコマンドの逆であるためである。以下のフォーマットすなわちDelete <fileID> <offset> <length>を用いてDeleteコマンドをファイルオフセットアドレスの範囲に適用することができる。<offset>から始まり、このアドレスから削除の<length>の間継続するファイルの部分のデータは削除される。次に、削除後のファイルの残りのデータのオフセットアドレスは、ファイルを通じて連続するオフセットアドレスを維持するために、その値はホストによって減少される。このことは、ホストがデータをファイルの中間に追加し、挿入後に残りのファイルデータのオフセットの値を増加させ、これによって変更されたファイルのオフセットが連続するInsertコマンドの逆である。
ガーベッジコレクション
図14Bおよび図14Eから留意すべきことは、Updateコマンドが、ファイルのデータ量よりも大きいファイルを記憶するのに必要な物理空間を生じさせるということである。その理由は、更新によって置き換えられたデータがメモリに記憶されたままであるためである。従って、古い無効なデータを削減することによってファイルのデータを少ない物理記憶空間に統合すること(ガーベッジコレクション)が極めて望ましい。従って、より多くの記憶空間が他のデータに利用可能になる。
図14Bおよび図14Eから留意すべきことは、Updateコマンドが、ファイルのデータ量よりも大きいファイルを記憶するのに必要な物理空間を生じさせるということである。その理由は、更新によって置き換えられたデータがメモリに記憶されたままであるためである。従って、古い無効なデータを削減することによってファイルのデータを少ない物理記憶空間に統合すること(ガーベッジコレクション)が極めて望ましい。従って、より多くの記憶空間が他のデータに利用可能になる。
図14Bおよび図14Eのファイルデータの更新に加えてさらに留意すべきことは、図14Cのデータの挿入が、狂った順序で記憶されたファイルデータを生じさせるということである。すなわち、更新および挿入は、このことが行われる時点でメモリに記憶されたファイルの終わりに追加され、その一方で、ほとんど常に、ファイル内のどこかに論理的に配置される。このことは、図14B、図14Cおよび図14Eの例の場合である。従って、ファイル内のオフセットの順序を一致させるように、メモリに記憶されたファイルのデータを再配列するのが望ましい。従って、このことは、ページおよびブロックを順序どおりに読み出すことがファイルのデータをオフセット順序に与えることになるので、記憶されたデータを読み出す速度を改善する。また、このことは、ファイルの最大可能なデフラグを行う。しかし、より効率良く読み出しを行うファイルデータの再配列は、他のデータを記憶するのに用いる1つ以上のメモリブロックを解放する可能性があるファイルデータの統合ほどメモリシステムの性能にとって重要ではない。従って、ファイル内のデータの再配列は、それ自体によって一般的に行われず、その利益は、動作オーバーヘッドを追加する価値がない。しかし、追加された動作オーバーヘッドをほとんど持たない多くのガーベッジコレクション動作の一部としてファイル内のデータの再配列を行うことができる。
2つのデータ更新U1,U2が行われたので、図14Eのファイルは、メモリに記憶された古いデータグループ(ぼかし部分)を含む。結果として、図14Eから明らかなように、ファイルを記憶するのに用いられるメモリ容量の量は、ファイルの大きさよりもかなり大きい。従って、ガーベッジコレクションは適している。図15には、図14Eのデータファイルのガーベッジコレクションの結果を示す。ガーベッジコレクション動作前、このファイルはほぼ5つのブロックの記憶容量を占め(図14E)、ガーベッジコレクション動作後の同じファイルは、3つをわずかに上回るメモリセルブロック内に適合する(図15)。ガーベッジコレクション動作の一部としてデータは、データが最初に書き込まれたブロックから他の消去済みブロックへコピーされ、次に、元のブロックは消去される。ファイル全体がデータ収集される場合、ファイル内のデータ論理オフセット順序と同じ物理順序を付けてデータを新たなブロックへコピーすることができる。例えば、更新U1,U2および挿入I1は、それらがホストファイルに現れるのと同じ順序でガーベッジコレクション(図15)後に記憶される。
一般的に、ガーベッジコレクションは、ファイルが統合される新たな異なるデータグループの形成をも生じさせる。図15の場合、ファイルは、新たな一連の新たなデータグループ索引項目(F0,D0),(F1,D1),(F2,D2),(F3,D3)によって記述される。これは、図14Eに示されているファイルの状態で存在するデータグループの数よりもかなり少ない。ファイルのデータがコピーされたメモリセルブロックごとに1つのデータグループが存在するようになる。ガーベッジコレクション動作の一部として、ファイル索引テーブル(FIT)は、ファイルを形成する新たなデータグループを反映するように更新される。
ファイルがガーベッジコレクションの候補である場合、このファイルのFITデータグループ項目は、ファイルがガーベッジコレクションの設定基準を満たすかどうかを決定するために検査される。また、ファイルのデータを含むメモリセルブロックのいずれも古いデータを含む場合、ガーベッジコレクションは開始する。メモリセルブロックのいずれかが古いデータを含まない場合、ガーベッジコレクションは必要とされない。図14Eのファイルが古いデータを含むことは、前に示された一連のデータグループ索引項目から明らかである。例えば、ファイルデータが記憶された最初の2つのブロックに古いデータが存在する2つの連続するデータグループ(F7,D5)および(F8,D3)から見て分かる。物理アドレス位置D5とD3との差は、論理オフセットF7とF8との差よりもかなり大きい。データが論理オフセット順に記憶されなかったファイル索引データグループ項目からも明らかである。あるいはまた、ファイルの個々のFIT項目は、古いと参照が付けられたこのファイルの古いデータグループのレコードを保持することができる。従って、コントローラは、ファイルごとにFIT項目を簡単に走査して、いかなる古いデータグループおよびそれらが記憶されている物理ブロックをも識別することができる。
ホストは、さらなる古いデータを生成し、かつ/または、狂った論理オフセット順序でデータを記憶する更新または挿入をファイルに行い続けることがあるので、一般的に、開いたファイルについてガーベッジコレクションを実行すべきではない。従って、多くのこのようなガーベッジコレクション動作に帰着することがある。しかし、消去済みプールブロックの数が設定レベルを下回る場合には、開いたファイルのガーベッジコレクションは、新たなデータを記憶するため、または他の動作のために充分な消去済みブロックを備えるのに必要とされることがある。
ホストによってファイルを閉じることは、一般的に、このファイルに考慮すべきガーベッジコレクションを生じさせる。ファイルが閉じられた直後にガーベッジコレクションを実行するのではなくむしろ、閉じられたファイルが現在のメモリ動作と干渉しないとき、閉じられたファイルにバックグラウンドでガーベッジコレクションを行うように、閉じられたファイルをメモリコントローラによってスケジュールすることが好ましい。ガーベッジコレクション待ち行列を保持することができる。ファイルが閉じられた後にファイルが待ち行列に追加され、次に、行うべき優先順位の高いメモリシステム動作が他にない場合、待ち行列内で最も長いファイルは、メモリコントローラによって選択され、必要に応じてガーベッジコレクションが行われる。このような選択およびガーベッジコレクション動作を、例えば、ホストからのIdleコマンド(図12D)の受信に応答して行うことができる。
データのコピーは、ガーベッジコレクションの最も時間の要する部分であるので、大きいファイルの場合は特に、どの時点においても短いバーストでファイルのデータの一部分だけをコピーすることによってタスクを構成要素に分割することができる。次に、このような部分的ファイルコピーを他のメモリ動作と交互に行うことができ、ホストがデータをメモリシステムとの間でやり取りしている間でも行うことができる。ある指定された数を下回る消去済みブロックの数に応答して個々のコピーデータバーストの長さを増大させることもできる。
目標は、全体としてバックグラウンドで、ホストシステムとの間でデータを転送する主な動作と干渉することなしに、または、この主な動作を減速することなしにガーベッジコレクションを実行することである。しかし、このことは常に可能とは限らず、特に、新たなデータをプログラムするために消去済みブロックプール内で利用できる消去済みブロックの数が何らかの事前設定の最小値に満たなくなる場合には可能でない。従って、ガーベッジコレクションに優先順位が構成され、優先順位のとおりに待ち行列内のファイルにガーベッジコレクションをフォアグラウンドで行ってデータを統合し、これによって、新たなデータをホストシステムから受信するのに追加の消去済みブロックを利用することができる。待ち行列内にファイルがない場合、開いたファイルにガーベッジコレクションを行わなければならないことがある。ガーベッジコレクションが優先事項になると、一般的に、ホストはビジーステータス信号をメモリシステムから受信し、従って、適切な数の消去済みブロックが再び存在するまで、新たなデータのいかなるプログラミングも中断する。その一方で、充分な数以上の消去済みプールブロックがある場合、ガーベッジコレクション動作の頻度を減少させることができ、メモリシステムの性能に影響を及ぼすことがあるガーベッジコレクションを延期することができる。
ホストデータファイルにガーベッジコレクションが実行されることに留意すべきである。ファイルの状態に応答してファイルにガーベッジコレクションが開始される。ガーベッジコレクションが開始されると、FIT内のファイルの全データグループの索引項目は、処理の一部として検査される。ファイルにガーベッジコレクションが行われると、データは、ファイルのデータグループ索引項目で指定された順序で既存のブロックから、新たに開かれたコピーブロックへ1つのデータグループで同時にコピーされる。このことは、全体として個々のメモリセルブロックの状況に基づく既存のフラッシュメモリガーベッジコレクションと対照をなしている。
しかし、古いデータをも含むファイルのデータを記憶する個々のブロックだけにガーベッジコレクションが行われることが原則である。つまり、ファイルのデータを記憶するブロックのすべてにガーベッジコレクションが行われるわけではない。例えば、ファイルが2つだけのブロックに記憶され、第1のブロックが古いデータを含み、第2のブロックが古いデータを含まない場合、第1のブロックにガーベッジコレクションが行われるが、第2のブロックのデータはそのままにされる。有効データは、第1のブロックから消去済みコピーブロックへコピーされ、従って、コピーブロックは、古いデータの量ぐらい使い残った幾つかの消去済みページまたは他の容量を有する。1つのブロックに満たない消去済み記憶容量の使用を以下で説明する。図14Eの例では、ガーベッジコレクション動作前のメモリ空間は、ファイルのデータを含む5つのブロックのうち4つの各ブロックに古いデータ(ぼかし領域)を有する。
古いデータを含むブロックだけにガーベッジコレクションを行うという原則の変更例として、所定のファイルにガーベッジコレクションが行われるということが決定された後、部分的に満たされたブロック内のファイルのデータのいずれも、ガーベッジコレクション動作に含まれる。従って、図14Eの第5のブロック内のU2データは、このブロックに古いデータがなくてもガーベッジコレクション動作に含まれる。5つのすべてのブロック内のデータは、4つの消去済みブロックへコピーされることによって同時に統合される。その理由は、第5のブロックにデータを含まないことで、結果として生じる4つのコピーブロックの2つは、部分的にだけデータで満たされることになるためである。図15の場合、1つだけのコピーブロックが部分的に満たされたままである。メモリ性能は、部分的に用いられるブロックが少ないことによって改善される。
ホストシステムによって送出された図12Bの特定のファイルコマンドはガーベッジコレクションを開始することができる。ファイルのCloseコマンドの受信は既に説明した。閉じたファイルは、ガーベッジコレクションを行うために待ち行列に配置される。DeleteおよびEraseコマンドもガーベッジコレクションを行うことになる。ファイルの削除によって、古いファイルデータを含むブロックをガーベッジコレクションの待ち行列に配置する。削除済みファイルにガーベッジコレクションを行う効果は、削除済みファイルに有効データがなく、従って、データを他のブロックへコピーすることは行われないということである。削除済みファイルのデータだけを含むブロックのすべては、ガーベッジコレクション処理の一部として単に消去される。消去済みファイルの古いデータだけを含むブロックのガーベッジコレクションを、例えば、ブロックをガーベッジコレクション待ち行列の先頭に配置することによって直ちにまたは優先的に行うことができること以外、Eraseコマンドは類似の効果を有する。
今、説明している直接ファイル記憶システムの重要な利点は、ファイルを削除するためのDeleteコマンドがメモリシステムに直接送出されるため、ホストがファイルを削除する時点をメモリが直ちに分かるということである。次に、メモリコントローラは、メモリの他の動作に悪影響を及ぼすことなしに、削除済みファイルのデータを記憶するブロックを消去することができれば直ちに消去することができる。その後、消去済みブロックは、新たなデータを記憶することに利用される。
説明している実施例では、ファイルを削除または消去するコマンドによって、直接応答としてこのファイルのデータを消去する。その一方で、一般的な論理ベースのインターフェイスでは、このようなコマンドはメモリコントローラに直接に到達しない。むしろ、ホストは、削除済みまたは消去済みファイルによって占有されたメモリ論理アドレス空間の特定のセグメントだけを解放する。ホストが後でデータをこれら同一の論理アドレスの1つ以上に書き込むときだけ、メモリシステムは、再使用された論理アドレスセグメントのデータが古くなっていることが分かる。メモリは、ファイルによって占有された他の論理アドレスセグメントのデータが削除または消去されたことを依然として分からない。メモリは、ホストがデータを他の論理アドレスに書き込むときだけ、論理セグメントに以前書き込まれたデータが古くなっているということが分かる。
共通ブロック
ファイルが閉じられ、ファイルにガーベッジコレクションが行われると、ファイルデータの一部がメモリセルブロックの一部だけを占有することがあるのは、連続的なブロックを単一ファイルのデータで満たした結果である。さらに、小さいファイルのデータは、ブロック全体を満たさないことさえある。この結果、1つのファイルのデータを1つのブロックに記憶できるとしても、個々のブロックのかなりの量の空間が未使用となる。個々のブロック内のページの記憶容量は消去されたままであり、データを記憶するのに利用可能ではあるが、使用されない。
ファイルが閉じられ、ファイルにガーベッジコレクションが行われると、ファイルデータの一部がメモリセルブロックの一部だけを占有することがあるのは、連続的なブロックを単一ファイルのデータで満たした結果である。さらに、小さいファイルのデータは、ブロック全体を満たさないことさえある。この結果、1つのファイルのデータを1つのブロックに記憶できるとしても、個々のブロックのかなりの量の空間が未使用となる。個々のブロック内のページの記憶容量は消去されたままであり、データを記憶するのに利用可能ではあるが、使用されない。
従って、他のブロックがいっぱいになった後、幾つかのメモリセルブロックは、2つ以上の各ファイルから少量のデータ、すなわち、全体に小さいファイルおよび/または使い残った残留ファイルデータのどちらか一方を記憶するのが望ましい。残留ファイルデータは、ブロック全体を占有しない閉じられたファイルのデータであって、1つ以上のデータグループを含むことがある。ファイルマップは、ブロック内のすべてのデータグループが1つのファイルのすべてであるかのように単一メモリセルブロック内の2つ以上のファイルのデータグループを追跡し続けることができる。個々のデータグループのマップは、データグループが一部であるfileIDを含む。共通ブロックを用いる主な目的は、前述したようにファイルのデータをメモリに書き込むことによって生じることがある未使用の物理メモリ記憶容量を最小限にすることである。最も一般的には、ファイルのガーベッジコレクションによって生じる1つ以上のデータグループの残留データは、ガーベッジコレクションの一部として共通ブロックに書き込まれる。一例として、図15のガーベッジコレクションが行われたファイルが挙げられ、最後のデータグループ(F3,D3)は、最後のブロックのごく一部だけを占有する。このようにデータが残留した場合、この最後のブロックの大部分は未使用になる。図15のデータグループ(F3,D3)を、別の1つ以上のファイルから1つ以上のデータグループを含む共通ブロックに書き込むことができ、または、この最後のメモリブロックを共通ブロックとして指定することができる。後者の場合、1つ以上の他のファイルからのデータグループはこの同じブロックにその後書き込まれる。
あるいはまた、指定された共通ブロックのうちの1つ内の消去済み空間に適合する量であると残留データの量が知られている場合、ガーベッジコレクション中、残留ファイルデータをホストから共通ブロックに直接に書き込むことができる。Close_afterコマンド(図12B)を用いて残留ファイルデータを識別することができ、これによって、完全に満たされていない消去プールブロックに残留ファイルデータを書き込むというよりはむしろ、コマンドの一部として指定されたデータの量を記憶するのに充分な空間を有する開いた共通ブロックに残留ファイルデータを書き込むことができる。このことは、その後のガーベッジコレクション動作中、残留データをコピーする必要性を削減することができる。
新たなデータファイルがメモリにプログラムされる場合、図13Aに示し、かつ前述したデータの書き込み方法に代わるものとして、1つ以上の他のファイルに対して残留データを含む開いた共通ブロックに、ブロック内の最初の利用可能な物理位置から始まってブロックの位置を連続的に順々に進行してデータを書き込むことができる。ホストがファイルに対してOpenコマンドを送信し、その直後にClose_afterコマンドを送信し、その後にファイルのデータを送信する場合、ファイルの完全なデータが、開いた共通ブロック内に適合でき、開いた共通ブロックの終わりに達する前にファイルが閉じられることを決定することができる。また、ファイルデータの長さが未知であっても、新たなファイルのデータを、開いた共通ブロックに書き込むことができる。
従って、2つ以上の異なるファイルの共通データグループを記憶するため、多くの共通ブロックをメモリシステムに維持するのが好ましい。共通データグループは、1バイトの粒度を有するブロックの記憶容量のデータまでの大きさを有することができる。共通ブロックの1つだけは所定のファイルのデータを含むのが好ましいが、ファイルの2つ以上のデータグループを含むことができる。しかも、共通データグループを、1つだけの共通ブロックに記憶し、記憶のために複数の共通ブロックに分割しないことが好ましい。このことは、データグループが古くなった場合、複数の共通ブロックにおけるガーベッジコレクションを回避する。共通ブロック内のデータグループが古くなると、共通ブロックにはガーベッジコレクションが課せられる。このような共通ブロック内の(1つ以上の)残りの有効データグループのいずれも、別の共通ブロック内の利用可能な消去済み空間、または消去済みプールブロックに書き込まれ、その後、共通ブロックは消去される。ガーベッジコレクションが行われる共通ブロックが、異なるファイルから2つ以上の有効データグループを含む場合、それらを同時に保持する必要はなくむしろ、異なるブロックへコピーすることができる。
図16には、3つの異なるデータファイルの各々から共通データグループでプログラムされた共通ブロックの一例を示す。データの書き込みが、ブロックの一端のページから他の端のページへ進行するように一般的なNANDアレイにおいて制約されているので、データグループは、互いに隣接するように記憶される。ブロックの一端にある空白は、いかなるデータも書き込まれていないブロックのページを示す。利用可能なデータグループを完全に共通ブロック全体に適合させることは困難である。
2つ以上のファイルの残留データを書き込むことができる開いた共通ブロックとしてメモリシステムによって指定されたブロックの数は、一般的にごくわずかであるが、ガーベッジコレクションが行われる多数のファイルが、任意の既存の開いた共通ブロック内の利用可能な空間に適合しない残留ファイルデータを有する場合には多くなることがある。残留ファイルデータは、メモリ容量全体を最も良く使用する開いた共通ブロックのうちの1つ内に書き込まれる。開いた共通ブロックのいずれかに充分でない消去済み空間が存在する場合、既存の共通ブロックのうちの1つは閉じられ、その代わりに別の共通ブロックが開かれる。あるいはまた、既存の開いた共通ブロックを閉じる必要がなく、開いた共通ブロックの数を増大させることができる。新たな共通ブロックは、消去済みプールブロックのうちの1つとして指定することができるが、好ましくは、利用可能な場合に、残留ファイルデータグループ(F3,D3)だけを含む図15の最後のブロックのような一部の残留ファイルデータを既に含む不完全に書き込まれたブロックとする。しかし、共通ブロックのガーベッジコレクションの場合、消去済みプールブロックを、必要な場合に新たな共通ブロックとして指定するのが好ましい。
図17には、別のファイルから残留データの1つ以上のデータグループを既に含んでいる5つの残留または共通単位(各々異なるブロックまたはメタブロック)が存在する場合に残留ファイルデータを書き込む例示的な処理を示す。図15のガーベッジコレクションが行われたファイルによって生じる最後のデータグループ(F3,D3)は、このような残留ファイルデータの一例である。しかし、このような残留ファイルデータは、単一ファイルから2つ以上のデータグループを含むことができる。3つの可能性を示す。残留単位2が、最も多くの利用可能な消去済み空間を有するので、第1の可能性(A)は残留データを残留単位2に書き込む。残留単位5が5つの残留単位のうちで最も良く適合するので、第2の可能性(B)は残留ファイルデータのために残留単位5を選択する。残留ファイルデータは単位5をほとんど満たし、従って、単位2内で利用できる大容量空間を、大量のデータを将来受信するために残す。単位1、単位3または単位4のいずれにも、残留データを獲得するのに充分な空間が存在しないので、これらの単位は直ちに除外される。
第3の可能性(C)は残留ファイルデータを消去プールからブロックまたはメタブロック単位に書き込む。残留ファイルデータが、完全に消去された単位に書き込まれた後、この単位は残留単位になり、後でメモリシステムコントローラによって共通ブロックとして開くことができる。図示の例では、残留単位2または残留単位5に残留ファイルデータのための空間があるので、一般的に可能性(C)は用いられない。
あるいはまた、異なる共通ブロックに記憶するため、ファイルの残留データを2つ以上の部分に分割させることができる。例えば、既存の開いた共通ブロックのいずれも、特定のファイルの残留データを記憶するのに充分に利用可能な空間を持つことができず、消去済みブロックのいずれも、残留ファイルデータの新たな共通ブロックとして開けるために利用することができない。この場合、2つ以上の開いた共通ブロック間で残留ファイルデータを分割することができる。
共通ブロックがデータでいっぱいになる前に共通ブロックを閉じることができる。前述したように、利用可能な最小量の消去済み空間を有する開いた共通ブロックは、一般的に、別の共通ブロックを開けてファイルの所定量の残留データを記憶することが必要とされるときに閉じられる。一部において、このことは、異なる共通ブロックに記憶するためにファイルの残留データが分割されない場合、好適な動作の結果である。メモリシステムが、Sizeコマンド(図12E)に応答することによって新たなデータの利用可能なメモリ記憶空間の量をホストに報告する場合、閉じられた共通ブロックのこれらの少量の未使用容量は、それらが直ちに使用可能でないので含まれない。
削除または消去された部分であるファイルが原因で、残留ファイルデータが古くなるので、共通ブロック内のデータも統合される。例えば、理由のいかんにかかわらず、共通ブロック内の残留ファイルデータが古いと指定されたときはいつでも、このブロックは、前述した古いファイルデータブロック待ち行列、または別の待ち行列に追加される。ファイルに対するホストDeleteコマンドのため、データが古くなった場合、共通ブロックは待ち行列の終わりに配置される。しかし、このことがEraseコマンドによって生じる場合、共通ブロックは待ち行列の先頭に入るか、さもなければ、ガーベッジコレクションの優先順位が与えられる。
メモリシステムの動作中、コントローラによって維持される5つの異なるガーベッジコレクション待ち行列、すなわち、
(1)古いブロック、すなわち、ファイルに対するEraseコマンド(図12B)の結果として古いデータだけを含むブロックの優先待ち行列、
(2)ファイルに対するEraseコマンドによって古い状態にされたデータを含み、しかも、幾つかの有効データを含む共通ブロックの優先待ち行列、
(3)UpdateまたはDeleteコマンド(図12Aおよび図12B)の実行によって、または、ガーベッジコレクション中、すべての有効データが別のブロックへコピーされたために生じる古いブロック(古いデータだけを含むブロック)の待ち行列、
(4)Deleteコマンドまたは古いデータが共通ブロックに存在するというガーベッジコレクション中の検出に応答する、幾つかの古いデータを含み、しかも、有効データを含む共通ブロックの待ち行列、
(5)CloseまたはClose_afterコマンドが受信されるファイルの待ち行列を、単一の待ち行列の代わりにすることができ、最初の2つの待ち行列の項目には、優先順位が与えられる。これら5つの待ち行列に、前に挙げた順に優先順位を与えることができる。待ち行列(1)の全項目には、待ち行列(2)の項目よりも前にガーベッジコレクションが行われる。ブロックは、DeleteコマンドによるよりはむしろEraseコマンドによってこれらブロックのデータの全部または一部が古い状態にされたため、優先待ち行列(1)および(2)にリストされる。ブロックおよびファイルは、メモリシステムの動作中に識別された順に各待ち行列に追加され、各待ち行列内の最も古いブロックおよびファイルに、最初にガーベッジコレクションが行われる(先入れ先出しすなわちFIFO)。
(1)古いブロック、すなわち、ファイルに対するEraseコマンド(図12B)の結果として古いデータだけを含むブロックの優先待ち行列、
(2)ファイルに対するEraseコマンドによって古い状態にされたデータを含み、しかも、幾つかの有効データを含む共通ブロックの優先待ち行列、
(3)UpdateまたはDeleteコマンド(図12Aおよび図12B)の実行によって、または、ガーベッジコレクション中、すべての有効データが別のブロックへコピーされたために生じる古いブロック(古いデータだけを含むブロック)の待ち行列、
(4)Deleteコマンドまたは古いデータが共通ブロックに存在するというガーベッジコレクション中の検出に応答する、幾つかの古いデータを含み、しかも、有効データを含む共通ブロックの待ち行列、
(5)CloseまたはClose_afterコマンドが受信されるファイルの待ち行列を、単一の待ち行列の代わりにすることができ、最初の2つの待ち行列の項目には、優先順位が与えられる。これら5つの待ち行列に、前に挙げた順に優先順位を与えることができる。待ち行列(1)の全項目には、待ち行列(2)の項目よりも前にガーベッジコレクションが行われる。ブロックは、DeleteコマンドによるよりはむしろEraseコマンドによってこれらブロックのデータの全部または一部が古い状態にされたため、優先待ち行列(1)および(2)にリストされる。ブロックおよびファイルは、メモリシステムの動作中に識別された順に各待ち行列に追加され、各待ち行列内の最も古いブロックおよびファイルに、最初にガーベッジコレクションが行われる(先入れ先出しすなわちFIFO)。
待ち行列(4)および(5)にリストされた項目の優先順位はほぼ同じであり、従って、逆にすることができる。あるいはまた、設定基準に従って、場合によっては、優先順位の高い待ち行列の1つ以上が空になる前であっても、ファイルおよびコマンドブロックが待ち行列(4)および(5)から選択されるさらに複雑な優先順位システムにすることができる。共通ブロックのガーベッジコレクションを管理する2つの目標がある。一方は、共通ブロック内のデータグループが古くなったときに共通ブロックのガーベッジコレクションによって生じるメモリシステムの正常な動作の中断を最小限にすることである。他方は、ブロックのガーベッジコレクション中、共通ブロックからのデータグループが再配置されるとき、更新の索引付けを最小限にすることである。
共通ブロックのガーベッジコレクション中、ブロック内に残っている共通グループの有効データのすべては、空間を有する共通ブロックの1つに1つずつコピーされる。開かれた共通ブロックに、共通グループがコピーされる空間がない場合、共通グループは、消去プールからブロックに書き込まれ、このブロックを次に共通ブロックとして指定することができる。開かれた共通ブロックの1つは次に一般的に処理の一部として閉じられる。すべてのガーベッジコレクション動作でのように、ファイル索引テーブル(FIT)は、コピーされたデータグループの新たな記憶位置を反映するように更新される。
ガーベッジコレクション待ち行列を不揮発性メモリに記録する必要がある。待ち行列情報を含むページまたはメタページに対する読み出し−変更−書き込み動作を実行して、項目を追加または除去する必要がある。ガーベッジコレクション待ち行列情報を含むページを、専用のブロックまたはメタブロック内に入れることができ、または、ブロックまたはメタブロックを、スワップブロックのような他の種類のページと共有することができる。
メタページのバッファリングおよびプログラミング中のメタページの使用
前述したものは、メモリセルブロックがメタブロックとして互いに結合されているかどうかを問わず、メモリシステムの動作について説明した。ホストとメモリシステムとの間のファイルベースのインターフェイスと、前述した関連のメモリシステム動作とは、メタブロックを用いるメモリシステム内でも、メタブロックを用いないメモリシステム内でも動作する。同時に書き込み、読み出されるデータの量(並列性の度合い)を増大させる傾向は間違いなくあり、その理由は、この並列性の度合いを増大させることがメモリ性能を直接に改善するためである。多数のデータビットで表す個々のメモリセルブロックの有効幅は、2つ以上のこのようなブロックの形態を成すメタブロックの使用によって増大される。
前述したものは、メモリセルブロックがメタブロックとして互いに結合されているかどうかを問わず、メモリシステムの動作について説明した。ホストとメモリシステムとの間のファイルベースのインターフェイスと、前述した関連のメモリシステム動作とは、メタブロックを用いるメモリシステム内でも、メタブロックを用いないメモリシステム内でも動作する。同時に書き込み、読み出されるデータの量(並列性の度合い)を増大させる傾向は間違いなくあり、その理由は、この並列性の度合いを増大させることがメモリ性能を直接に改善するためである。多数のデータビットで表す個々のメモリセルブロックの有効幅は、2つ以上のこのようなブロックの形態を成すメタブロックの使用によって増大される。
図3に関して、例えば、単一ブロック内の各ワード線に沿っているメモリセルのすべてを、各行内の512バイトのユーザデータの幾つか、1,2,4またはそれ以上のセクタを記憶する可能性があるページとして同時にプログラムし読み出すことができる。2つ以上のブロックがメタブロックに論理的に結合されている場合、2つ以上の各ブロックの1つの行内の全メモリセルを同時にプログラムし読み出すことができる。同時にプログラムされ読み出される2つ以上のブロックからの2つ以上のページは、メタページを形成する。同時に多くのデータをプログラムする機能を用いると、メタページ内のデータのステージングを、この利用可能な並列性を充分に使用することに役立てることができる。
図18には、3つの各ホストファイルに対するデータの1つのメタページを示す。各メタページは、説明を簡単にするために2つだけのページを含むように示されている。メタページの各ページのデータは、メタブロックの異なるブロックにプログラムされる。
ホストファイル1の場合、メタページは、単一のデータグループ0の一部として連続的なオフセット(論理アドレス)を有するデータで満たされているように図18の(A)に示されている。これらデータは、ファイル1のデータを受信するメタブロック内で順序が次にあるメタページに同時にプログラムされる。図18の(B)では、この例のホストファイル2は、最初のページの一部が、連続的なオフセットを有するデータグループ1の部分を含み、メタページの残りの部分が、連続的なオフセットを有する別のデータグループ2の部分を含むという点で異なって示されている。2つのデータグループがファイル2のメタページ内で結合する箇所でデータのオフセットに途切れが存在するが、これらデータは単一メタページに同時にプログラムされる。前述したように、直接ファイル記憶インターフェイスは、ファイル内のデータのオフセットの順序にかかわらず、ホストファイルのデータを、ホストから受信されたとおりに書き込む。
幾つかのフラッシュメモリは、データを消去済みページに2度以上プログラムすることができない。この場合、図18の(B)のデータグループ1およびデータグループ2の双方は、同時にプログラムされる。しかし、メモリが部分的なページプログラミングを可能にする場合、ファイル2の2つのデータグループを不揮発性メモリの単一メタページに異なる時点でプログラムすることができる。この場合、ページ0は異なる時点でプログラムされ、最初にデータグループ1がプログラムされ、次に、データグループ2がページ0の残りの部分とページ1の全部とにプログラムされる。しかし、システム性能を増大させるため、データグループの双方を同時にプログラムするのが一般的に好ましい。
図18の(C)では、ファイル3のメタページに書き込まれた単一のデータグループ3の終わりが示されている。このような少量のデータが不揮発性メモリのメタページにプログラムされる一方で、メタページの残りの部分が消去されたままである場合、特定の状態が存在する。1つには、データグループ3がデータファイル3の残留ファイルであるファイルに対してCloseコマンド(図12B)をホストが送出するとき、ホストが、許容数を上回って多数のファイルを開こうとすれば、メモリコントローラによっても閉じることができ、ファイル3は選択されて閉じられ、これによって、代わりに別の追加のアクティブファイルを開けることができる。メモリコントローラは、開かれたファイルメタページバッファのすべてに対するバッファメモリ内の容量が不充分である場合にもファイル3を閉じることができる。これらの場合のいずれでも、ファイルバッファの部分的なデータ内容を不揮発性メモリに直ちに書き込む(ファイルバッファを「フラッシュする」)のが望ましい。ホストは、メモリへの電源が失った可能性があり、不揮発性メモリに直ちにプログラムされなければ、揮発性バッファメモリ内の全データは失われることを意味するShut−downコマンド(図12D)をも送信することができる。
ファイル3の別のデータグループ4の始まりを図18の(C)のメモリメタページに書き込むことが後で要求され、メモリによって部分的なページプログラミングが可能でない場合、データグループ4の最初のページは、図18の(D)に示されているようにファイル3のメタページの第2のページに書き込まれる。この結果、不揮発性メモリメタページ内の図18の(D)のデータグループ3とデータグループ4との間の空白部分によって示されるように、一部の未使用のメモリ容量を生じることがある。この未使用の容量を、ファイル3が閉じられた後に実行されるガーベッジコレクション動作によって回復することができ、または、この状況がまれに起こる可能性が高いので存続させることができる。
本発明の直接ファイル記憶技術が、不揮発性メモリのブロック内のこのような満たされていない空隙を許容できることに留意すべきことが重要である。図7および図8によって示されているように、メモリシステムが論理アドレス空間を介してホストとインターフェイスをとる現在のシステムによって、このような空隙を容易に許容することはできない。論理データは同じ大きさをメモリブロックとしてグループ化し、または、メタブロックはこのようなブロックまたはメタブロックにマッピングされる。既存のメモリシステムのブロックまたはメタブロック内に記憶されたデータ内に空隙が存在することになる場合、空隙にマッピングされた論理データアドレスは、ホストによって効果的に使用不可能にされる。このような既存のインターフェイスでは、ホストは、それに利用可能な全部の論理アドレス空間を有すると仮定するが、仮に可能であったとしても、空隙を指定する論理アドレスに新たなデータを書き込むことは極めて困難である。
図2のメモリ31のようなシステムコントローラ内のバッファメモリの一部は、一般的にプログラミングデータバッファとして用いられる。このメモリ内のバッファ容量は、ホストによって書き込まれるアクティブファイルごとに存在する必要がある。このような「ファイルバッファ」の各々は、フラッシュメモリ内の少なくとも1つのメタページに等しい容量を有する必要がある。アクティブファイルは、ホストによってデータが最近書き込まれた開いた状態のファイルである。
どの時点においてもメモリシステムが対応するアクティブホストファイルの数を、現在開いた状態のメモリシステムファイルの数に等しくすることができ、または、これよりも少ない数とすることができる。アクティブファイルの許容最大数は、開いたファイルの許容最大数よりも少ない場合、アクティブ状態と、開いた状態との間でファイルの状況を変更するため、プロビジョンを行う必要があり、逆の場合もまた同様である。このことを可能にするため、フラッシュメモリ内の一時的記憶ブロックはスワップブロックとして指定され、長さが1つのメタページを満たないデータをスワップバッファ内のファイルバッファからメタページに書き込むことができ、逆もまた同様である。有効なスワップされたファイルバッファの索引は、スワップブロックに維持される。ファイルバッファデータは、整数のページとしてスワップブロックへコピーされる。整数のページの後には、各々コピーされたファイルバッファの長さおよび位置の索引を備える単一ページと、それが関連するファイルとが続く。スワップブロックは周期的に圧縮され、いっぱいになったら消去済みブロックに書き込まれる。
開いたファイルAを、このファイルAへのホスト書き込み動作の結果としてアクティブ状態にする必要がある場合、例えば、最も長い間書き込まれなかったアクティブファイルBは識別され、ファイルバッファデータは、コントローラバッファメモリからスワップブロック内の次の利用可能なページへコピーされる。次に、ファイルAのファイルバッファデータはスワップブロック内で識別され、以前にファイルBに割り当てられたコントローラバッファメモリ内の利用可能な空間へコピーされる。
図18に示されている場合のうちの1つに従って、ファイルバッファからのデータを、フラッシュメモリ内のファイルの開いた書き込みブロックの次の利用可能なメタページに書き込むのが好ましい。図18の(A)では、ファイル1内に単一データグループ0の一部を形成する充分なデータがファイル1のバッファ内に存在する場合、このデータグループは単一動作でメタページ全体にプログラムされる。図18の(B)では、ファイル2内にデータグループ1の終わりおよびデータグループ2の始まりを形成する充分なデータがファイル2のバッファ内に存在する場合、これらデータグループは単一動作でメタページ全体にプログラムされる。フラッシュメモリ装置が単一ページでの複数のプログラム動作(部分的なページプログラミング)を支援する場合、ファイル2内にデータグループ1の終わりを形成する充分なデータがファイル2のバッファ内に存在すれば、このデータグループをページ0の一部にプログラムすることができる。ファイル2内にデータグループ2の始まりを形成する充分なデータがファイル2のバッファ内で利用可能になると、次に、このデータグループを、別個のプログラム動作で同じメタページの残りの部分にプログラムすることができる。
図18の(C)に示されているように、ファイル3内にデータグループ3の終わりを形成するデータがファイル3のバッファに存在し、バッファフラッシュ動作を実行する必要がある場合、このデータグループはページ0の一部にプログラムされる。フラッシュメモリ装置が単一ページでの複数のプログラム動作(部分的なページプログラミング)を支援しない場合、ファイル3内のデータグループ4の始まりを形成する充分なデータがファイル3のバッファ内で利用可能になると、次に、このデータグループは、別個のプログラム動作で同じメタページ内のページ1にプログラムされる。
メタページファイルバッファは、ガーベッジコレクション中にも用いられる。ファイルの有効データグループを不揮発性メモリから読み出し、このファイルのコントローラバッファメタページに書き込むことができる。ファイルが同時に再配列される場合、データグループは、ホストデータオフセットの順でバッファに書き込まれる。各データグループのデータが連続的な論理オフセットを有することはもちろんである。メタページバッファがいっぱいになった後、データは並行して不揮発性メモリの新たなブロックにプログラムされる。
ファイル索引付け
メモリシステムに記憶された各ファイルは、特に、図13〜図16を参照して前に説明したようなそれ自体の一連の索引項目によって定義される。これら項目内でファイルのデータが付加、挿入または更新されるので、これらの項目は時間と共に変化し、また、ファイルにガーベッジコレクションが課せられると変化する。図19には、幾つかの異なる各時点0,2,4および5での1つのファイルに対するファイル索引テーブル(FIT)内の一連の索引項目を示す。これらはそれぞれ図14A、図14C、図14Eおよび図15を参照して前に説明した一連の索引項目である。FIT内のデータを書き込み、ホストシステムからの支援なしにメモリコントローラによって現行を保持するのが好ましい。ホストは、データグループ、または、データグループがメモリセルアレイに記憶される箇所を定義することに関与しないが、ホストシステムはデータをメモリシステムに書き込むとき、パス名、ファイル名およびファイル内のデータのオフセットを供給する。図19の項目では、図14および図15のメモリセルブロックに左から、1から始まる番号が付けられる。従って、図14Cに示されている状態のファイルの場合、例えば、3番目のデータグループ(F6,D7)は、図19において、ブロックの先頭のアドレスからD7バイトであって、ブロック004、すなわち左から4番目のブロックに記憶されていると示されている。テーブルの各項目に各データグループの長さも含めるのが好ましい。
メモリシステムに記憶された各ファイルは、特に、図13〜図16を参照して前に説明したようなそれ自体の一連の索引項目によって定義される。これら項目内でファイルのデータが付加、挿入または更新されるので、これらの項目は時間と共に変化し、また、ファイルにガーベッジコレクションが課せられると変化する。図19には、幾つかの異なる各時点0,2,4および5での1つのファイルに対するファイル索引テーブル(FIT)内の一連の索引項目を示す。これらはそれぞれ図14A、図14C、図14Eおよび図15を参照して前に説明した一連の索引項目である。FIT内のデータを書き込み、ホストシステムからの支援なしにメモリコントローラによって現行を保持するのが好ましい。ホストは、データグループ、または、データグループがメモリセルアレイに記憶される箇所を定義することに関与しないが、ホストシステムはデータをメモリシステムに書き込むとき、パス名、ファイル名およびファイル内のデータのオフセットを供給する。図19の項目では、図14および図15のメモリセルブロックに左から、1から始まる番号が付けられる。従って、図14Cに示されている状態のファイルの場合、例えば、3番目のデータグループ(F6,D7)は、図19において、ブロックの先頭のアドレスからD7バイトであって、ブロック004、すなわち左から4番目のブロックに記憶されていると示されている。テーブルの各項目に各データグループの長さも含めるのが好ましい。
1つのファイルに対して図19に示されている一連の索引項目は、ファイルの変更によってファイルのデータグループに変更が生じたとき、または、他の低い頻度の間隔でメモリコントローラによって再度書き込まれる。コントローラはメモリでのこのような変化を記憶することができ、次に、これら変化の多くをフラッシュメモリに同時に書き込むことができる。1つだけの有効な索引セットは、どの時点においても1つのファイルに対して存在する。図19には、異なる時点にファイルを定義する4つのこのような索引セットを示す。次に、追加のデータをファイルにプログラムし、データをファイルから読み出し、ファイルのデータにガーベッジコレクションを行い、可能性がある他の動作を実行するため、必要に応じて、メモリシステムコントローラはファイルの現在の索引セットを用いる。従って、FITは、個々のファイル索引項目がファイルオフセット(Fx)の順に記憶されている場合に使用しやすいが、そうでない場合、コントローラは論理順序で項目を確実に読み出すことができる。特定のファイルに対して索引項目を読み出すメモリコントローラの最も一般的な要因は、ホストコマンドを実行する過程にある。
図20には、ファイルマップの一部としてファイル索引テーブル(FIT)を維持し用いる好適な技術を示す。一連のファイル索引付け構造は、指定されたパス名を有するファイル内に、指定されたオフセットアドレスを有するデータの物理位置を識別するのに用いられる。ファイルマップは、従来の論理アドレスインターフェイスと用いられる標準のディスクオペレーティングシステム(DOS)のルートディレクトリおよびサブディレクトリ構造とほぼ同じ論理構造を有するディレクトリ201を含む。ファイルディレクトリ201を、メモリシステム内の1つ以上の専用のフラッシュブロックに記憶することができる。しかし、ファイルディレクトリ201を、ホストの代わりに記憶システムによって管理するのが好ましい。本願明細書では、図12Cのホストディレクトリコマンドは、メモリシステムコントローラによって実行されるが、コントローラによって決定された時点で、かつ、決定されたように実行される。ホストにファイルディレクトリへ直接書き込ませないのが好ましい。
ディレクトリまたはファイルを各々識別する一様にサイズ設定された項目は、ファイルディレクトリ201内で保持される。連続的な項目セットは、特定のディレクトリ内の要素を指定するのに用いられる。ディレクトリを指定する項目内のポインタ領域は、このディレクトリ内の要素を指定する他の連続的な項目の始まりを識別する。ファイルを指定する項目内のポインタ領域は、関連するファイル索引テーブル(FIT)203内のブロック番号およびファイル番号を定義する。
FIT203は、データグループの一様にサイズ設定された項目を含む。各項目は、データグループの始まりのオフセットと、データグループのメモリシステム内の物理位置とを識別する。論理アドレスがバイト粒度で維持される場合、各FIT項目のオフセットは、データグループの始まりを指定するファイルの始まりから指定された数のバイトを含む。これと同様に、データグループの始まりの物理位置をバイト粒度で指定することができる。異なる時点にある例示的なファイルに対するFIT項目の内容は、図19を参照して前に説明した。別々の項目はデータグループごとに維持されている。各ファイルは、ファイル内のデータグループの一連の連続的な索引項目によって定義されている。1つのファイル当たりのこのような項目の数は一般的に異なる。
ホストによって供給されたファイルのパス名は、FIT内のブロック番号およびファイル番号を獲得するためにファイルディレクトリの階層を全検索するのに用いられる。一般的に、パス名は1、2またはそれ以上のディレクトリおよびサブディレクトリを含む。これらは、アクセスしようとするファイルを含むファイルディレクトリ201内のディレクトリにアクセスするのに用いられる。次に、ディレクトリ内のファイル名は、ホストによって供給されたファイル名に対する項目205を検出するために検索される。項目205が検出されると、項目205は、ポインタを、ファイルに対するFIT203内の連続的な項目グループに供給する。これら項目は、図19を参照して説明した項目の性質を持っている。次に、これら項目のオフセットは、ホストによって供給されたオフセットアドレスと比較されて、正しい項目207、従って、正しいデータグループを識別する。オフセットの完全な一致がない場合は、項目に含まれるオフセットがデータグループの始まりのアドレスだけであるためにしばしば起こることがあり、項目にオフセットを含むデータグループを識別する項目が選択される。この例では、FIT203の選択された項目207は、物理ブロックと、ホストによってアクセスしようとしているデータを含むメモリ位置のバイトとを含む。
ファイルが最初に生成されたときに、または、FIT203内のファイルのデータグループ項目の位置が変更されたときに、図20のファイルに対するディレクトリ項目205のポインタはメモリシステムコントローラによって割り当てられる。このポインタは、前述したfile_handleの一例である。ファイルにアクセスするたびにホストがファイルディレクトリ201の階層を検討してファイルのFIT項目を検出するという必要性を回避するため、メモリシステムはfile_handleをホストに送信することができ、これによって、その後、ホストは、開かれたファイルのFIT項目に直接にアクセスすることができる。
図21には、ファイルディレクトリ201内の個々の項目を記憶するメモリシステム内のページを示す。ポインタをファイルディレクトリ201内のディレクトリに供給する項目もあれば、FIT203内のデータに供給する項目もある。単一メモリページ内に記憶された多くの項目の1つである例示的な項目209は、各項目が4つの領域を有するように示されている。第1の領域は、ホストによって与えられたディレクトリまたはファイルの名前を含む。第2の領域は、ホストによって定義されたディレクトリまたはファイルの属性を含む。ディレクトリの項目の場合、第3の領域内のポインタはファイルディレクトリ内の別の項目を指す。ファイルの項目の場合、第3の領域は、項目207のようなFIT203内のファイル項目へのポインタを含む。「データグループ」と識別される第4の領域は、ディレクトリの項目では空であるが、ファイルの項目の場合、この領域は、ファイルのデータを含むデータグループの数、従って、ファイルに対するFIT203内の項目の数を指定する。
図21に示されているファイルディレクトリページが2つの区域を含むことに留意すべきである。最近書き込まれたページ211では、ディレクトリ項目(1つには、ページ213内で符号209が付されている項目)およびページポインタの双方が存在する。ページ213のような他のディレクトリページでは、ディレクトリ項目は存在するが、ページの一領域は、古いページポインタを含む。現在のページポインタは、最近書き込まれたページ、この場合ではページ211の同じ部分に維持されている。1つのページポインタはディレクトリブロック内の論理ページごとに存在し、メモリコントローラを、アクセスしている論理ページに対応する物理ページに指向する。最近書き込まれたディレクトリページ内のページポインタを維持することによって、ページポインタは、ディレクトリ項目と同時に、かつ、その後に別のページを更新する必要なしに更新される。この技術は、論理アドレス形のファイルシステムについて、ゴロベッツらによる2004年8月13日に出願された米国特許出願第10/917,725号(特許文献20)にさらに詳細に記載されている。
特定の実施例では、ディレクトリブロックは、メモリセルブロック内の全ページのうちの指定された部分(例えば、50%)である一定数の論理ページを含む。ディレクトリブロックを、ディレクトリページの記憶に専用とされるメタブロックとするのが好ましいが、単一消去ブロックとすることができる。ディレクトリブロックは、データグループを記憶するのに用いられるメタブロックと同じ並列性を有することができ、または、低い並列性を有することができる。ファイルディレクトリブロックはいっぱいになると、元のブロックを消去する前に各論理ページの有効部分を新たなブロックへコピーすることによって圧縮される。ディレクトリブロックが圧縮された直後、新たなコピーブロック内のページの(50%のような)定義された部分だけがディレクトリ項目を用いて書き込まれる。残りのページは、更新された項目または新たな項目の書き込みを可能にする消去済み状態にある。
ディレクトリまたはファイルの項目が生成、変更または削除されると、このディレクトリまたはファイルを含むディレクトリの項目セットは、ディレクトリブロック内の次の利用可能な消去済みページに再度書き込まれ、従って、ディレクトリの項目を連続しているように保持する。このことは、このディレクトリの項目を前もって含むページの読み出し/変更/書き込み動作によって行われる。従って、以前のページは古くなる。この論理ページのページポインタ項目も、新たな物理ページを識別するために更新される。このことを、ディレクトリの項目を書き込むために用いられたのと同じページプログラム動作で行うことができる。
項目の生成によって、ディレクトリの項目セットがページをあふれさせる場合、その代わりとして、別のページの最初の項目として項目セットを書き込むことができる。必要に応じて、ディレクトリの項目セットをページの終わりに移動するように既存のページを再度書き込むこともできる。ディレクトリブロック内の論理ページ番号をページポインタに再度割り当てて、ディレクトリの項目を連続しているように保持することができる。
図20のファイル索引テーブル(FIT)203は、装置内の全ファイルを構成するデータグループへの索引を記憶する。FITは、メモリシステムの1つ以上の専用のFITブロックに記憶される。各FITブロックは、最大数までのファイルの索引を記憶することができる。FITは、テーブルによって索引付けられたファイルの1つを指定するファイルディレクトリから論理ポインタを用いてアクセスされる。ポインタは、最近書き込まれたFITページ217の一部として供給されたファイルポインタにアクセスすることによって間接アドレス指定を用い、これによって、索引がFITブロック内で更新され再度書き込まれるときにポインタは変化しない。
項目205のようなファイルディレクトリ201内のファイル項目のFITポインタは、2つの主要な領域を有する。第1の領域は、FITを構成する論理FITブロックの1つを識別するFITブロック番号である。FITブロック番号に割り当てられた実際の物理ブロックアドレスは、別々に管理される。FITポインタの第2の領域は、識別されたFITブロック内の論理ファイル番号を識別するFITファイル番号である。論理ファイル番号は、FITブロックの最近書き込まれたページ内に記憶された特定のファイルポインタによって物理ファイル項目位置に変更される。
FITは、予め定義された大きさを持たず、FITブロックの数は、データが編成されたファイルの数およびデータグループの数の関数である。新たなFITブロックが生成され、装置の動作中、FITブロックは削減される。
図19を参照して前に説明したように、図22に関して、個々のFITページは、多数のデータグループ項目、すなわち、データグループごとの1つの項目219を有する。この特定の例では、各項目219は4つの領域を含む。ファイルオフセット領域は、項目によって識別されるデータグループの始まりのファイル内のオフセットアドレスを指定する。ブロックアドレス領域は、データグループを含むメモリシステム内のブロックまたはメタブロックの物理アドレスを指定する。バイトアドレス領域は、ブロックまたはメタブロック内のページのアドレスと、データグループが開始するページ内のバイトとを指定する。4番目の領域は、データグループの長さである。隣接した項目のデータからデータグループの長さを計算することができるので、すべての場合においてデータグループの長さを必要としなくてもよい。しかし、長さを維持することによって、この計算を、データグループの長さが求められるたびに行う必要はない。論理アドレスの順にデータグループ項目がFIT内に書き込まれていない場合、従って、計算がさらに困難になる場合、データグループの長さは、特に有益な情報である。
ファイルを形成する順序付きデータグループを同時に定義する連続的なデータグループ項目セットによってホストファイルを定義するのが好ましい。図22のページ215に示されている陰影付きの連続的なグループ項目は1つのファイルを定義し、ページ217内のグループ項目は別のファイルを定義する。FITブロック内に維持された個々のファイルに対して、最後に書き込まれたFITページ217内には、FIT内の個々のファイルごとに1つのファイルポインタ221がある。ファイルポインタ221は、FITブロック内に特定のFITファイル番号を有するファイルのファイル項目の始まりを定義する。ファイルポインタ221は、2つの領域を含む。一方の領域は、データグループ索引項目が存在するページの物理番号であり、他方の領域は、このページ内の最初のグループ項目の番号である。FITブロック内の実行可能なファイル番号ごとにファイルポインタが存在する。すなわち、ファイルポインタの数は、FITブロック内のファイルの最大番号に等しい。ファイルポインタ項目内の予備コード(図示せず)は、特定のファイル番号がFITブロック内で未使用であることを示す。ファイルポインタは他のFITページ内に存在しうるが、それらは、FITブロックの最近書き込まれたページのみで有効である。
FITブロックは、FITページを記憶するのに専用とされるメタブロックであるのが好ましい。FITブロックは、データグループを記憶するのに用いられるメタブロックと同じ並列性を有することができ、または、低い並列性を有することができる。その代わりに単一消去ブロックを用いることができる。FITブロックが圧縮された直後、ブロック内のページの(50%のような)定義された部分だけが項目を含む必要がある。残りのページは、更新された項目または新たな項目の書き込みを可能にする消去済み状態である必要がある。多数のファイルが維持される場合、2つ以上のFITブロックを必要とすることがある。
FITは、1つ以上の完全なファイルのデータグループ項目を、FITブロックの次の利用可能なプログラムされていないページに書き込むことによって更新される。ファイルのファイルポインタ項目も、ファイル項目の新たな位置を識別するために更新される。ファイルデータグループ項目およびファイルポインタの双方は、同じページプログラム動作で書き込まれる。従って、ファイル項目の以前の位置は、FITブロック内で古くなる。あるいはまた、ファイル項目を、異なるFITブロックまたは新たなFITブロックに書き込むことによってファイル項目を更新することができる。この場合、双方のブロック内のファイルポインタを更新する必要があり、ファイルディレクトリ内のファイルの論理ポインタを変更する必要がある。
FITブロックがいっぱいになると、有効なグループ項目は、圧縮された形態で、新たな消去済みブロックへコピーされ、以前のFITブロックは消去される。この動作によって論理FITブロック番号および論理ファイル番号は変更される。ページの(50%のような)定義された部分だけが、圧縮されたFITブロックにプログラムされるように、データグループ項目の数を制限する必要がある。必要に応じて、ファイル項目を他のFITブロックに移動する必要があり、ファイルディレクトリの論理ポインタを変更する。
1つのページまたはメタページ内に個々のファイルのFIT項目のすべてを保持するのが望ましい。このことは、ファイルの項目のすべてを読み出すことを比較的容易にする。各FIT項目内に次の物理アドレスを含めることによってファイルのFIT項目を互いにつなげることができるが、このことは、2つ以上のFITページまたはメタページを読み出すことを必要とする可能性が高い。ページ内でFIT項目を連続しているように保持することも望ましい。この結果として、FIT項目の数が増大するにつれて、特に、閉じられたファイルが開かれ、このファイルにデータグループが追加されるときに、新たなページを頻繁に書き込むことができる。新たなFIT項目が新たなページに書き込まれると、既存の項目は別のページからコピーされ、新たな項目と一緒に新たなページに書き込まれる。既存の項目の以前のページ内の古いデータによって占められた空間は、FITブロックが圧縮されるときに用いるために取り出される。
前述したように、個々のデータグループは、単一ブロックまたはメタブロック内に含まれ、ブロック内の任意のバイト境界で開始することができ、任意の整数のバイトの長さを有することができる。データグループがメモリに書き込まれるとき、コントローラによって各データグループにヘッダを追加することができる。このようなヘッドは、2つの領域を含むことができる。第1の領域は、データグループの始まりを識別するコードを含む。このコードを、すべてのデータグループに対して同じにすることができ、このコードは、データグループの一部として記憶されたデータ内にまれに存在するがこのようなデータにコードが決して現れないとは限らないビットパターンとして選択される。メモリコントローラが、このコードに対して、記憶されたデータを走査し、次に、メモリコントローラがコードのビットパターンを検出したときに、それが本当にデータグループの始まりであるか、データグループ内のデータでないかを確認することによってデータグループの始まりを検出することができる。ヘッダの第2の領域によって、この確認を行うことができる。この第2の領域は、データグループを含むファイルに対するFIT203(図20および図22)内のファイル項目へのポインタである。第2の領域は、FITブロック番号およびFITファイル項目を定義する。次に、コントローラはFITファイル項目を読み出して、FITファイル項目が指し返すデータグループからコードが読み出されたかどうかを確かめる。そうである場合、コードは、データグループのヘッダ内に存在する指示であると確認される。そうでない場合、コードのビットパターンは、他のデータから読み出されたと確認され、従って、データグループヘッダとして無視される。
このようなヘッダを、個々のデータグループに記憶されたデータの一部として含むことによって、メモリ内のいずれかのデータグループが属するファイルを、ヘッダを読み出し、ヘッダが指すFIT項目にアクセスすることによって決定することができる。FIT項目219(図22)は、fileIDを含むことができる。本願明細書では、この機能を用いて、例えば、共通ブロックのガーベッジコレクション中、共通ブロック内のデータグループを識別する。共通ブロック内の1つ以上の他のデータグループが古いため、ガーベッジコレクションが行われる場合、残りの各有効データグループが属するファイルを識別できるのが望ましい。
各データグループの一部を形成するヘッダの代わりに、1つのファイル当たり1つのヘッダを供給することができる。ファイル内のデータグループのFIT項目の位置が既知であり、ファイルヘッダがこのことを可能にする場合、ファイルの絶対パス名を識別できるのが有利である。このようなヘッダを、ファイルに対するFIT内の項目セットの始まり、または、ファイルディレクトリ内のディレクトリに対する項目セットの始まりとして供給することができる。
このファイルヘッダは、それをFITファイルヘッダとして識別するコードと、ファイルヘッダを指しているディレクトリ項目への逆ポインタとを含む。FITファイルヘッダは、ファイルの長さおよびデータグループの数のような追加の情報をも含むことができる。あるいはまた、ヘッダ項目は、1つ以上の通常の項目の空間を占有することができる。
これと同様に、ディレクトリヘッダは、それをディレクトリヘッダとして識別するコードと、ディレクトリヘッダを指しているディレクトリ項目への逆ポインタとを含む。ルートディレクトリは、ヘッダ内で明白に識別される。ディレクトリヘッダは、ディレクトリ内の項目の数のような特定の追加情報をも含むことができる。
このようなデータグループまたはファイルヘッダの使用に代わるものとして、索引を各共通ブロックの終わりに書き込んで、共通ブロック内の各データグループが関連するファイルを識別することができる。共通ブロックが閉じられると、このような索引を書き込むことができる。索引は、共通ブロック内の各データグループが開始する共通ブロック内の物理バイトアドレスと、このデータグループへのFIT項目へのポインタとを含むのが好ましい。従って、各共通ブロックデータグループが一部であるファイルを、データグループの索引項目に供給されたFIT項目を参照することによって決定することができる。
これらの共通ブロック索引が用いられる場合であっても、メモリに記憶されたデータグループに対してファイル識別子の何らかの冗長部分を有することが望ましければ、前述したデータグループヘッダを依然として保持することができる。
メモリ装置は、ファイルディレクトリおよびファイル索引付けを管理するので、その結果、ホストに報告される装置構成パラメータを制御することができる。一般的に、このことは、現在の商用システムでのように装置のファイルシステムがホストによって管理される場合には可能でない。メモリ装置は、報告される記憶容量、例えば、全装置の容量および、書き込まれていない利用可能な容量の双方を変更することができる。
ファイルに対して直接ファイルインターフェイスで用いられるパス名は、記憶装置自体のIDと記憶装置内のパーティションとを識別することができる。メモリ装置にパーティションの大きさおよび数を変更させることができるのが有利である。パーティションがいっぱいになると、1つ以上の他のパーティションから未使用の容量を、いっぱいのパーティションに再割り当てすることができる。これと同様に、新たなパーティションが生成される場合、他のパーティションから未使用の容量を割り当てることができる。装置は、前述したように様々なパーティションの報告された容量を変更することができる。
図20および図21に示されているディレクトリ構造は、ディレクトリ項目内のポインタを用いて、このディレクトリ内の要素に対する他の連続的な項目セットの始まりを識別する。このポインタはディレクトリブロック内の論理ページを指し、この論理ページに対応する物理ページが変更される場合にポインタは変わらないままである。しかし、ディレクトリ内の要素の数は頻繁に変更され、特定のディレクトリに対する項目セットを1つの論理ページから別の論理ページに移動する必要、または、現在の論理ページ内に移動する必要が頻繁にある。この結果として、ディレクトリブロック内のポインタ参照を更新する必要性が頻繁に起こることがある。図21のディレクトリ構造に対して代わりとなるディレクトリ構造の項目索引付け技術を図23に示す。図23では、対応する要素に同一の符号が付されているが、この符号にダッシュ記号(’)が付加されている。
図23の構造は、図22のFITの構造と同じであるが、ディレクトリに関して異なる技術を有する。図21において行われたようなページだけというよりはむしろ特定の項目が指し示される。このことは、指定されたディレクトリの項目セットに対するディレクトリブロック内の間接アドレス指定方法であって、図21を参照して前に説明した間接アドレス指定方法よりも効率良い方法を提供する。ディレクトリ(図23)およびFIT(図22)ブロックに対して同じ索引付け方法を用いるのが適切であり、その理由は、双方が極めて類似の特性および要件を有するためである。それらは各々、ディレクトリまたはファイルに関連する連続的な項目セットを記憶する。既存の項目の内容を変更するか、または、項目の数を変更することから、項目セットの更新を構成することができる。
図22を参照して説明したFIT項目の更新方法は、ブロックの圧縮後、消去済み状態で、FIT項目を含む物理ブロック内にページの一部分(例えば、50%)を残す。これによって、更新されたFIT項目を、圧縮されたブロックの残りの部分に書き込むことができる。ブロックによって索引付けられたいかなるファイルも実際に開いていないときでも、すべてのFITブロックは、この容量オーバーヘッドを組み入れる。従って、FITは、望ましいメモリ容量よりも多くのメモリ容量を占有する。
代わりのFIT更新方法は、更新されたFIT項目セットを、FIT項目セットが最初に配置されたブロック内の利用可能な消去済み容量内というよりはむしろ別個のFIT更新ブロック内に書き込ませる。図24および図25は、更新ブロックを用いるファイルディレクトリおよびFIT用の索引付け技術をそれぞれ概説する。ディレクトリおよびFITに用いる用語だけが異なること以外、これらの技術は同一である。
以下の説明は、図25に示されているようなFITブロック内のグループ項目の更新に関するが、ファイルディレクトリ内のグループ項目の更新(図24)に同様に適用することができる。
前に説明したように、FITブロックからグループ項目を読み出す。FITポインタのFITブロック番号領域は、論理FITブロックを定義する。FITブロックリストは一瞬にデータ構造内に含まれ、FITブロック番号を、ブロックが配置されているブロックの物理アドレスに変換する情報を供給する。圧縮または統合動作中、FITブロックが移動されるときはいつでも、FITブロックリスト内のブロックアドレスは更新される。
このブロック内に最近書き込まれたページのファイルポインタ領域によって、FITポインタ内のFITファイル番号値を、指定されたファイルに対するファイルグループ項目セットの始まりを指定するファイルポインタに変換することができる。従って、ファイルグループ項目をFITブロックから読み出すことができる。
グループ項目の内容、またはファイルに対するグループ項目セットのグループ項目の数が更新されると、完全な項目セットは、消去済みページに再度書き込まれる。(このことは、ページがフラッシュメモリ内の最小プログラム単位であり、同じページへの複数の書き込み動作が消去動作間で禁止されているという仮定に基づく。)この項目セットは、必要に応じて複数のページを占有することができる。
今、説明している技術では、このページは、FITブロック内の次の利用可能なページである。修正された方式では、このページは、別個のFIT更新ブロック内の次の利用可能なページである。FIT更新ブロックは、図23に示されているようなFITブロックと同じページ構造を有する。その存在は、FIT更新ブロックリスト内の対象とするFITブロック番号の存在によって識別される。また、FIT更新ブロックリストは、更新ブロックの物理ブロックアドレスと、元のFITファイル番号に対応する更新ファイル番号とを含む。FITブロックごとに別個のFIT更新ブロックを更新することができ、または、好ましくは、FIT更新ブロックは複数のFITブロックに関連することができる。単一のFITブロックも、複数のFIT更新ブロックに関連することができる。
FIT更新ブロックがいっぱいになると、有効データを圧縮形態で消去済みブロックに書き込むことができ、この消去済みブロックは、新たなFIT更新ブロックになる。更新がほんの数ファイルにしか関連しない場合、単一ページの有効データほどしかないことがある。複数のFIT更新ブロックを単一ブロックに同時に圧縮することができる。更新ブロックが、依然として開いた状態であって、更新し続けることができる1つ以上のファイルに関連する場合、ブロック圧縮はブロック統合に好まれる。
FIT更新ブロック内でファイルのグループ項目が更新されると、元のFITブロック内のこのファイルの項目は古くなる。ある段階で、元のFITブロックはガーベッジコレクション動作を受けて、除去される必要がある。このことを、FITブロックおよびFIT更新ブロック内の有効データを消去済みブロックに統合することによって行うことができる。
項目の数が更新処理中に増大した場合、有効データを単一の消去済みブロックに統合することができず、このFITブロックに最初に割り当てられたファイルを2つ以上のFITブロックに再割り当てすることができ、2つ以上のブロックに対して統合を実行することができる。
FIT更新ブロックからの項目を、FITブロックからの項目と共に統合することができ、従って、FIT更新ブロックから削減することができ、その一方で、他のファイルの項目はFIT更新ブロック内にとどまることができる。
さらなる代わりとして、ディレクトリ項目およびファイルグループ項目の双方を含むことができる単一の索引ブロック構造に、ディレクトリブロックおよびFITブロック構造を組み合わせることができる。別個のディレクトリブロックおよびFITブロック構造が存在するか、または、組み合わされた索引ブロック構造が存在する場合、索引更新ブロックは、ディレクトリ項目およびファイルグループ項目の双方の更新ブロックとして作用することができる。
図20〜図25を参照して前に説明したファイルディレクトリおよびFITはDOSシステムに則っていることが分かる。あるいはまた、ファイルディレクトリおよびFITは、Linux(登録商標)、Unix(登録商標)、NTファイルシステム(NTFS)または何らかの他の既知のオペレーティングシステムに則ることができる。
特定のメモリシステム動作の例
図26〜図32の動作フローチャートは、図2〜図6を参照して前に説明したように構成されているが、図9および図10〜図22を参照して説明した直接ファイルインターフェイス技術の特定の組み合わせを用いるメモリシステムの動作の一例を示す。図26〜図32のフローチャートに含まれる機能は、記憶されたファームウェアを実行するコントローラ11(図2)によって主に行われる。
図26〜図32の動作フローチャートは、図2〜図6を参照して前に説明したように構成されているが、図9および図10〜図22を参照して説明した直接ファイルインターフェイス技術の特定の組み合わせを用いるメモリシステムの動作の一例を示す。図26〜図32のフローチャートに含まれる機能は、記憶されたファームウェアを実行するコントローラ11(図2)によって主に行われる。
システム動作全体が示されている図26を最初に参照する。最初のステップ251では、メモリシステムを初期化する。このステップは、プロセッサ27(図2)がROM内のブートコード29を実行して、ファームウェアを不揮発性メモリからRAM31にロードすることを含む。初期化の後、このファームウェアの制御下、次に、ステップ253によって示されているようにメモリシステムはホストシステムからのコマンドを検索する。ホストコマンドが保留中である場合、図12にリストされているコマンドのうちからコマンドを識別する。Readコマンド(図12A)である場合、これをステップ255で識別し、ステップ257によって実行する。ステップ257を図27を参照して以下に詳細に説明する。Readコマンドでない場合、図26のステップ259では、図12AのWrite、InsertまたはUpdateプログラムコマンドのいずれか1つを識別し、ステップ261によって実行する。ステップ261は、図28の主題である。DeleteまたはEraseコマンド(図12B)である場合、これをステップ262で識別し、図30に詳細に説明するようにステップ263で実行する。図26のステップ264では、ホストからIdleコマンド(図12D)を識別し、その結果、図31のフローチャートに示されているガーベッジコレクション動作265を生じる。図26〜図32のこの例を、前述したメタページおよびメタブロックと動作するメモリシステムについて説明するが、ページおよび/またはブロックで編成されたメモリシステムによっても実行することができる。
ホストコマンドが、Read、Write、Insert、Update、Delete、EraseまたはIdle以外である場合、この特定の例では、このような別のコマンドを図26のステップ267によって実行する。これらの他のコマンドのうち、図12Bにリストし、かつ前述したCloseおよびClose_afterコマンドのようなコマンドは、ガーベッジコレクション動作を待ち行列に追加させる。受信されたコマンドをステップ257,261,263,265または267のいずれかによって実行した後、次のステップ268は、ガーベッジコレクション優先待ち行列が空であるかどうかを問い合わせる。ガーベッジコレクション優先待ち行列が空である場合、処理はステップ253に戻って、保留中のコマンドが存在する場合、保留中のホストコマンドを実行する。ガーベッジコレクション優先待ち行列が空でない場合、別のホストコマンドの可能性を実現できるようにするよりはむしろ、処理はステップ265に戻ってガーベッジコレクションを継続する。図26〜図32のフローチャートを参照して説明する特定例の場合、前述した5つの異なるガーベッジコレクション待ち行列がある。すなわち、2つの優先待ち行列は、古いメタブロック(古いデータだけを有するメタブロック)と、古いデータを有する共通メタブロックとに対するものであり、古いデータはEraseコマンドによって生じる。2つの他の待ち行列は、古いメタブロックと、古いデータを有する共通メタブロックとに対するものであり、古いデータは、Eraseコマンドの実行以外によって生じる。1つの待ち行列は、ガーベッジコレクションを行うべきファイルに対するものである。3つの非優先待ち行列にリストされたガーベッジコレクションに対して、別の保留中のホストコマンドには、リストされたガーベッジコレクション動作を行う優先順位が与えられる。しかし、優先待ち行列のガーベッジコレクション動作に対して、ガーベッジコレクションには、新たなホストコマンドの実行よりも上の優先順位が与えられる。すなわち、新たなホストコマンドを実行することができる前、優先ガーベッジコレクション動作のいずれも完了するまでホストを待機させることができる。その理由は、ホストが、Eraseコマンドを用いることによって、メタブロック内のデータの消去に対して予め与えられた優先順位を優先待ち行列内に有するためである。優先ガーベッジコレクションは、結果として、比較的わずかな処理時間で生成される追加の消去済みメタブロックをも生じさせる。しかし、優先事項でない場合、ホストがアイドル状態にあるとき、ガーベッジコレクションはバックグラウンドで実行されるか、または、消去済みブロックプールを維持するのに必要なとき、他の動作と交互に行われる。いかなる優先ガーベッジコレクション動作も保留中にないことがステップ268によって決定された場合、次のステップはステップ253であって、新たなホストコマンドがあれば、これを実行する。
図26のステップ253に戻って、いかなるホストコマンドも保留中にない場合にガーベッジコレクション265を行い、所定の長さの時間中、ホストが非アクティブ状態またはアイドル状態にあること、または、最近受信されたホストコマンドがIdleコマンドであったことがステップ269によって決定された場合、または、保留中のホストコマンドがIdleコマンドであることがステップ264によって決定された場合、ガーベッジコレクション265は非優先ガーベッジコレクションを含む。これらの条件下で、ガーベッジコレクションは完全にバックグラウンドで実行される可能性が高い。
図26のステップ257におけるReadコマンドの実行は、図27のフローチャートの主題である。最初のステップ271は、図19および図22を参照して前に説明されたようにファイル索引テーブル(FIT)を読み出すことである。ホストReadコマンドは、読み出しが開始されるファイルのfileIDおよびファイル内のオフセットを含む(図12A参照)。一部のデータが不揮発性メモリから必要とされるごとに不揮発性メモリからFITを読み出す必要性を回避するために、読み出すべきファイルのFIT項目の全部または一部を不揮発性メモリからコントローラメモリ31(図2)に読み出すのが好ましい。ステップ273では、データグループ番号カウンタを、開始オフセットが位置する要求されたファイルを構成するデータグループの数に初期化する。このことは、ホストによって指定された開始オフセットを、ホストによって指定されたファイルのFIT項目内のデータグループのオフセットと比較することによって行われる。次に、ステップ275では、データグループ長さカウンタを、ホストによって供給されたオフセットからデータグループの終わりまでの最初のデータグループ内のデータの量に初期化する。1つのデータグループは1度に読み出され、ステップ273およびステップ275は、最初のデータグループの読み出しを管理する2つのカウンタをセットアップする。読み出すべきデータの不揮発性メモリ内の最初の物理バイトアドレスを、最初のデータグループのFIT項目から決定する。グループ内のデータの論理オフセットおよび物理バイトアドレスは直線的に関連し、これによって、読み出しがデータグループの始まりで開始しない場合、開始バイトアドレスは、ホストから供給されたファイル内の開始オフセットから計算される。あるいはまた、データグループ長さカウンタの初期化を簡単にするため、各データグループの長さをFITのレコード219(図22)に追加することができる。
フローチャートのこの説明の残りの部分について、メモリシステムがメタブロックと動作し、前述したようにデータがメタページの単位で読み出されプログラムされると仮定される。ステップ277において、開始バイトアドレスを含む不揮発性メモリに記憶された最初のデータグループからデータメタページを読み出す。一般的に、読み出されたデータは、ホストに転送するためにコントローラバッファメモリ(例えば、図2のRAM31)に書き込まれる。次に、ステップ279においてデータグループ長さカウンタを1つのメタページだけ減少させる。次に、ステップ281においてこのカウンタを読み出して、カウンタがゼロに達したかどうかを決定する。ゼロに達していない場合、読み出すべき最初のデータグループのデータがもっとある。しかし、ステップ277に戻って、順番に次のメタページのデータを読み出す前に、ステップ283は、ホストが別のコマンドを送出したかどうかを検査する。ホストが別のコマンドを送出した場合、読み出し動作を終了し、処理は、受信したコマンドを識別し、次にこのコマンドを実行するため、図26のステップ253に戻る。ホストが別のコマンドを送出しなかった場合、図27のステップ277およびステップ279において、次のメタページを読み出すことによって最初のデータグループの読み出しを継続する。この読み出しを、ステップ281によってデータグループ長さカウンタがゼロに到達したと決定されるまで継続する。
データグループ長さカウンタがゼロに到達した場合、ステップ285においてこの場合もファイルのFIT項目を読み出して、ステップ287において、読み出すべき現在のファイルのデータグループがこれ以上あるかどうかを決定する。データグループがある場合、ステップ289において、次のデータグループを識別するためにデータグループ番号カウンタを更新し、ステップ291においてデータグループ長さカウンタを新たなグループ内のデータの長さに初期化する。ステップ283によって、保留中のホストコマンドが他にないと決定された場合、ステップ277において、新たなデータグループの最初のメタページを読み出す。次に、データのすべてを読み出すまで、新たなデータグループのメタページごとにステップ277およびステップ279を繰り返し、データのすべてを読み出した時点で、ステップ285およびステップ287は、さらなる別のデータグループが存在するかどうかを決定するなどである。ホストによって供給されたオフセットが読み出された後、ステップ287によって、ファイルのデータグループのすべてであると決定されると、処理は、別のホストコマンドを実行するために図26のステップ253に戻る。
ファイルが環状バッファとして用いられる特別な場合、図26のステップ253に戻るよりはむしろ図27のステップ287の後、ファイルの読み出しを繰り返すことができる。このことは、ステップ283において、データを同じファイルに書き込むホストコマンドに応答することによって、現在のファイルのデータが読み出し中にホストによってプログラムされる場合に生じうる。
図26のデータプログラム動作261の一例を図28のフローチャートに示す。図12Aのデータプログラムコマンドの1つがホストから受信されるとき、このコマンドは、データが書き込まれるべきファイルのfileIDを含む。最初のステップ295は、プログラミングのため、指定されたファイルが現在開かれているかどうかを決定する。ファイルが開かれている場合、次のステップ297は、このファイルに対して(図2のRAM31のような)コントローラバッファ内にデータがあるかどうかを決定する。データは、ホストシステムによってコントローラバッファメモリに転送され、次に、メモリシステムコントローラによってフラッシュメモリに転送される。
しかし、ホストによって指定されたファイルが開かれていないとステップ295によって決定された場合、次のステップ299は、プログラミングのためにメモリシステムによって現在開かれたファイルの数が、メモリシステムによって許容されている同時に開くことができる最大数N1以上であるかどうかを問い合わせる。数N1はメモリシステム内で事前設定され、ファイルの5,8または何らかの他の数とすることができる。開かれたファイルの数がN1に満たない場合、次のステップ301は、データをプログラムするのに必要とされるシステムリソースをこのファイルに供給することによって新たなファイルを開かせ、処理はステップ297に進行する。しかし、ステップ299において、開いたファイルの数がN1以上であると決定された場合、ステップ303によって示されているように、現在開かれているファイルを最初に閉じる必要があり、その後、ステップ301において、新たなファイルを開くことができる。ステップ303において、開いたファイルを閉じるように選択する基準は変更することができるが、通常、ホストによってデータが最も長い間書き込まれなかった開かれたファイルである。このことから、ホストは、このファイルに近い将来データを書き込む可能性は低いということが推定される。しかし、このファイルにデータを書き込む場合、別の開いたファイルを閉じた後、必要ならば、そのとき、このファイルを再度開く。
ステップ297において、現在のファイルの少なくとも1つのメタページのデータがコントローラバッファ内に存在すると決定されると、次のステップ305は、メモリアレイ内のメタブロックがプログラミングのために開かれているかどうかを決定する。メタブロックが開かれている場合、次に、ステップ307において、開いたメタブロックにコントローラバッファメモリからデータをプログラムする。メタブロックが開かれていない場合、ステップ308において、データをプログラムするのに必要とされるシステムリソースをメタブロックに供給することによって最初にメタブロックを開く。この例では、データは、開いたメモリメタブロックに1つのメタページの単位で一度に書き込まれる。この単位のデータを書き込んだ後、次のステップ309は、開かれた書き込みメタブロックがデータでいっぱいであるかどうかを決定する。書き込みメタブロックがデータでいっぱいでなければ、処理は一般的にステップ311およびステップ313を通過し、ステップ297に戻って、現在開かれているファイル内のデータの次のメタページをプログラムする処理を繰り返す。
しかし、ステップ309によって、書き込みメタブロックがいっぱいであると決定される場合、ステップ315においてメタブロックを閉じ、ステップ317においてFITを更新し、ステップ317は、メモリメタブロック境界に達したので、現在のデータグループを閉じることを含む。次に、ステップ318において、優先順位の低い古いメタブロックガーベッジコレクション待ち行列のメタブロック項目を更新する。ステップ317においてFITを更新する間、書き込みメタブロックがいっぱいであることによって、現在のファイルの古いデータのすべてを含む別のメタブロックか、または、現在のファイルの古いデータを含む共通メタブロックである別のメタブロックが生成されたかどうかを決定する。別のメタブロックが生成された場合、ステップ318によって、このメタブロックを、ガーベッジコレクションのため、優先順位の低い適切なメタブロック待ち行列に追加する。次に、処理はステップ311に戻り、ステップ313を通過してステップ297に戻る。ステップ305およびステップ307を通過して今回は、以前のメタブロックがステップ315によって閉じられたばかりであるので、ステップ308は新たな書き込みメタブロックを開く。
ステップ307を含む経路によって各メタページのデータが書き込まれた後、ステップ311は、消去済みメタブロックプール内に現在存在するメタブロックの数が、メモリシステムを効率良く動作するのに必要な決定された最小数N2を上回るかどうかを問い合わせる。メタブロックの数が最小数N2を上回る場合、ステップ313は、別のホストコマンドが受信されたかどうかを問い合わせる。保留中のホストコマンドが他にない場合、メモリにプログラムすべき次のメタページのデータについてステップ297を繰り返す。しかし、ホストコマンドが受信された場合、ステップ319においてFITを更新して、書き込まれたデータグループを閉じる。ステップ320において、(前述したステップ318に類似して)優先順位の低い古いメタブロックガーベッジコレクション待ち行列内のメタブロック項目を更新した後、処理は図26のステップ253に戻る。
しかし、図28のステップ311において、データの記憶に対して消去済みメタブロックの不足がある(事前設定された数N2以下である)と決定された場合、フォアグラウンドでファイルまたは共通メタブロックにガーベッジコレクションを行うサブルーチンを実行して、消去済みメタブロックの数を増大させる。各メタページのデータがメモリに書き込まれた後ではなくむしろ、N3個ごとにメタページが書き込まれた後だけに、このようなガーベッジコレクションを実行するのが好ましい。書き込みメタブロックメタページプログラムカウンタは、プログラム動作の間でガーベッジコレクションなしに連続してプログラムされたホストデータのメタページの数のカウントを維持する。ガーベッジコレクションが実行されるたび、このカウンタはゼロにリセットされ、次に、メタページのデータがプログラムされるたびに1だけ増大する。ステップ321では、カウントが所定の数N3を上回るかどうかを決定する。プログラムカウンタのカウントが数N3を上回らない場合、ステップ323においてカウンタを1だけ増大して、ステップ307においてメタページがメモリに書き込まれたことを記録する。しかし、プログラムカウンタのカウントが数N3を上回る場合、ガーベッジコレクションはステップ325、ステップ327およびステップ329によって行われ、その後、ステップ331においてプログラムカウンタをゼロにリセットする。
処理中のこの時点でのガーベッジコレクションの目的は、消去済みメタブロックプールに追加の消去済みメタブロックを生成することである。しかし、ステップ325、ステップ327およびステップ329を実行するたびにガーベッジコレクション動作の一部だけ実行するのが好ましい。コピー動作は、ホストがメモリを利用できない間隔の期間を最小限にし、従って、データプログラム性能に与える悪影響を最小限にするために長期にわたって展開される小規模な動作に分割される。これと同じ理由のため、部分的なガーベッジコレクション動作はN3個のプログラム周期ごとだけ実行される。システムにおいて数N2,N3を事前設定することができるが、遭遇することがある特定の条件に適合させるために、これらの数をメモリシステムの動作中でも決定することができる。
1つ以上の追加の消去済みメタブロックを生成するため、ファイルまたは共通メタブロックに対する完全なガーベッジコレクション動作によって必要とされる時間の大部分が、有効データを1つ以上のコピーメタブロックへコピーすることによって要されるので、完全なガーベッジコレクション動作は、このコピー動作であって、このコピー動作は、図28に示されているデータプログラムと主として交互に行われる。ステップ325は、図31のフローチャートに関して説明されるガーベッジコレクション329にフォアグラウンドモードを選択する。次に、ガーベッジコレクションが行われたメタブロックから、予め消去されたコピーメタブロックへ特定の事前設定数のメタページのデータグループを連続してコピーする。ステップ327は、このように交互してコピーされたメタページのカウンタをリセットし、これによって、ステップ329において、事前設定数のメタページをコピーし、その後、動作は、ガーベッジコレクションステップからデータプログラムループへ戻る。次に、ステップ321によって参照される書き込みメタブロックメタページプログラムカウンタを、ガーベッジコレクション動作329ごとの後にステップ331によってリセットする。このことは、フォアグラウンドで別のガーベッジコレクション動作が行われ、従って、ガーベッジコレクションによって生じるデータプログラムの遅延を広げる前にN3個のメタページのデータをメモリに書き込ませる。
ガーベッジ−プログラミングアルゴリズムの交互性を図29の時刻表によって示す。ガーベッジコレクション動作の間で、N3個のメタページのデータはホストからメモリに連続して書き込まれる。各ガーベッジコレクション動作は、N4個のメタページのデータをコピーすることに限定され、その後、別のN3個のメタページのデータがプログラムされる。ガーベッジコレクション段階では、追加のメタページのデータをメモリシステムコントローラバッファに転送する前に、メモリシステムがガーベッジコレクションを完了するためにホストを待機させることができる。
図26の削除ファイルルーチン263の実行を図30のフローチャートによって示す。削除ファイルルーチン263の主な目的は、削除されるファイルの古いデータを有する古いブロックおよび共通ブロックを識別し、次に、これらのブロックを適切なガーベッジコレクション待ち行列に配置することである。削除すべきファイルの名前または他の識別子と一緒にDeleteまたはEraseコマンド(図12B)がメモリシステムによって受信されると、ステップ335は、データグループ番号カウンタをゼロに初期化する。ステップ337では、指定されたファイルを構成するメモリに記憶されているデータグループの識別子を獲得するためにファイルディレクトリおよびファイル索引テーブル(FIT)を読み出す。次に、論理的に順々に各データグループを指すデータグループ番号カウンタの値を増大することによってファイルの各データグループを1つずつ検査する。
データグループに対する最初の問い合わせ339は、データグループが共通メタブロック内に存在するかどうかを決定する。データグループが共通メタブロック内に存在する場合、ステップ341は、このメタブロックを共通ブロックガーベッジコレクション待ち行列の1つに追加する。ファイルがEraseコマンドによって削除される場合、メタブロックは共通メタブロック優先待ち行列に配置され、Deleteコマンドによる場合、他の共通メタブロック待ち行列に配置される。削除すべきファイルのデータグループを有する共通メタブロックのいずれも、ガーベッジコレクションを行うようにスケジュールされる。データグループが共通メタブロック内に存在しないことがステップ339によって決定された場合、次の問い合わせ343は、古いメタブロックガーベッジコレクション待ち行列に存在することによってガーベッジコレクションを行うようにメタブロック内でデータグループが既にスケジュールされたかどうかを決定する。ガーベッジコレクションを行うようにメタブロックが既にスケジュールされた場合、この同じ待ち行列にメタブロックを再度追加する必要はない。しかし、ガーベッジコレクションを行うようにメタブロックがまだスケジュールされていない場合、ステップ345によってメタブロックを古いメタブロックガーベッジコレクション待ち行列の1つに追加する。ファイルがEraseコマンドによって削除された場合、メタブロックは、古いメタブロック優先待ち行列に配置され、Deleteコマンドによる場合、他の古いメタブロック待ち行列に配置される。
ステップ341またはステップ345が実行された後か、または、ステップ343の問い合わせが肯定応答であった場合、1つのデータグループの処理は完了する。次のステップ347は、データグループ番号カウンタの値を増大する。次に、問い合わせ349は、ファイルに別のデータグループが存在するかどうかを決定する。ファイルに別のデータグループが存在する場合、処理はステップ339に戻り、次のデータグループに対して繰り返される。ファイルに別のデータグループが存在しない場合、削除すべきファイルのデータを含むメタブロックのすべてが、古いメタブロックおよび共通メタブロックガーベッジコレクション待ち行列に入っていることが分かる。次に、ステップ351においてFITを更新し、削除すべきファイルのデータグループレコードを古くする。次に、FITが圧縮されると、一般的に、古いデータグループのFITのレコードを削減する。最後のステップ353では、ファイルディレクトリ201(図20)を更新して、そこから削除済みファイルを除去する。
図31のフローチャートには、図26のガーベッジコレクション動作265および図28のガーベッジコレクション動作329の特定例を示す。このアルゴリズムは、ホストがIdleコマンドを送信する場合(図26のステップ264)、または、ホストが一時アイドル状態であった場合、バックグラウンドで実行され(図26のステップ265)、または、N2個に満たない消去済みメタブロックが消去済みメタブロックプールにとどまる場合、プログラム動作中、フォアグラウンドで実行される(図28のステップ329)。最初の問い合わせ355は、まだ完了されていない進行中のガーベッジコレクション動作があるかどうかを決定する。図31のこの説明から、処理は、ホストが別のコマンドを送出する場合、または、データのコピーが他の動作と交互に行われる場合のような特定の条件下、ガーベッジコレクションから生じるということが分かる。従って、保留中の未完成なガーベッジコレクション動作が存在する場合、保留中のガーベッジコレクションに優先順位が与えられているので、次のステップはステップ357である。しかし、保留中のガーベッジコレクション動作が存在しないことがステップ355によって決定された場合、次のステップ356は、様々なガーベッジコレクション待ち行列を検索して、これらの中に少なくとも1つの項目が存在するかどうかを確かめる。ガーベッジコレクション待ち行列に項目が存在する場合、次のステップ358は項目の1つを選択し、項目が2つ以上存在する場合、前述した優先順位に従って項目の1つを選択する。古いメタブロックブロック待ち行列において順序が次にあるメタブロックのガーベッジコレクションには、一般的に、共通メタブロック待ち行列のメタブロック、または、ガーベッジコレクションを行うべきファイルの待ち行列のファイルよりも上の優先順位が与えられる。その理由は、古いメタブロックをガーベッジコレクションすることによって、いかなるデータもコピーする必要がないのでさらに高速に消去済みメタブロックプールの大きさを増大させることができるためである。
処理がファイル、共通メタブロックおよび古いメタブロックに対して異なるので、次の一連のステップ360、ステップ362およびステップ366は、選択された待ち行列項目に対してガーベッジコレクションの対象物を決定する。問い合わせ360は、対象が、ガーベッジコレクションを行うべきファイルであるかどうかを尋ねる。対象がファイルである場合、ステップ370およびステップ372においてファイルのFIT項目を順々に読み出して特定のカウンタおよびカウントを設定する。ステップ370において、第1のカウンタをファイル内のデータグループの数に設定し、第2のカウンタをファイルの最初のデータグループ内のデータのメタページの数(長さ)に設定する。データグループの長さが項目の一部でない場合、この長さをFITデータグループ項目から計算することができる。あるいはまた、図20および図22に示されているように、必要となるたびにデータグループの長さを計算する必要性を削減するため、各データグループの長さを項目の一部としてFITに含めることができる。ステップ372では、古いデータまたは他のファイルからのデータを含むメモリブロックに記憶された現在のファイルデータのメタページの数に第3のカウンタを設定する。これらのデータは、移動する必要がある現在のファイルのデータである。この第3のカウンタは、ファイル内のすべての古いデータグループおよび無効なデータグループを無視するのが好ましい。最後に、ファイルの有効データが整数のメタブロックに圧縮され満たされた場合に生じるデータの残留メタページの数のカウントを行う。すなわち、残留メタページカウントは、ガーベッジコレクションに含まれるファイルのデータをメタブロックのすべてが含めば、共通メタブロックまたは部分的に満たされたメタブロックを占有する必要があるメタブロック未満のファイルのデータの量である。これらの3つのカウンタを設定し、残留メタページカウントを行い記憶した後、次のステップ359は、ファイルのデータにガーベッジコレクションを開始する。
ステップ360に戻り、ステップ358によって選択された項目がファイルでない場合、次の問い合わせ362は、選択された項目が、ガーベッジコレクションを行うべき共通メタブロックであるかどうかを決定する。選択された項目が共通メタブロックである場合、図32の共通メタブロックガーベッジコレクション364を行う。選択された項目が共通メタブロックでない場合、問い合わせ366は、選択された項目が、図30のステップ345によって古いメタブロック待ち行列に追加されたような古いメタブロックかどうかを決定する。選択された項目が古いメタブロックである場合、選択されたメタブロックをステップ368において消去する。共通メタブロックガーベッジコレクション364の後、メタブロック消去368の後、または、問い合わせ366が否定応答を生じた場合、処理は図26のステップ253に戻る。ガーベッジコレクション動作が未完成のままである場合、次回、ガーベッジコレクションアルゴリズムが実行されたときに再開される。
ステップ355に戻り、保留中のガーベッジコレクションがある場合、これをさらに処理する。ガーベッジコレクション待ち行列から選択された新たな項目に対するステップ360のように、図31のステップ357は、保留中の動作がファイルに対するものかどうかを決定する。保留中の動作がファイルに対するものでない場合、新たな項目に対して前に説明されたステップ362、ステップ364、ステップ366およびステップ368の処理を実行し、次に、図26のステップ253に戻ることによってガーベッジコレクションを終了する。
再開されたガーベッジコレクションがファイルに対するものであることが図31のステップ357によって決定された場合、次に、問い合わせ359を行う。以下の処理は、(ステップ357を介して)ガーベッジコレクションが再開されるファイルに対するもの、または、カウンタおよび残留メタページカウントがステップ370およびステップ372によって設定される(ステップ360を介して)待ち行列から選択された新たなファイルに対するものとほぼ同じである。ファイルのガーベッジコレクションが進行中であり、ステップ357を介して再開されている場合、データグループ番号およびファイルメタページ番号カウンタ、並びに残留メタページカウントは、ファイルのガーベッジコレクションが最初に開始されたときに設定されている。データグループ番号およびメタページカウンタは、現在のファイルの以前の部分的なガーベッジコレクションによって最初に計算された値と異なる値に減少されている可能性が高い。ファイルのガーベッジコレクションが一時中断されるとき、4つすべてを記憶し、次に、同じファイルの再開された処理中にアクセスする。
共通のステップ359は、まだコピーされていない現在のデータグループ内に1つ以上のメタページが存在するかどうかを問い合わせる。このことは、データグループ長さカウンタを参照することによって決定される。その後のステップによって有効データグループの1つのメタページを同時に検査しコピーする。ステップ359によって、保留中のデータグループに残っているデータが決定された場合、次の問い合わせ361は、コピーメタブロックが開いているかどうかを決定する。コピーメタブロックが開いている場合、ステップ363によって、ガーベッジコレクションが行われるファイルの現在のデータグループのデータのメタページを、記憶されたメタブロックから読み出し、ステップ365においてコピーメタブロックに書き込む。次に、ステップ367においてデータグループ長さカウンタを1つのメタページだけ減少し、ステップ369においてファイルメタページカウンタを1だけ減少する。
コピーメタブロックが開かれていないことがステップ361によって決定された場合、次のステップ371は、ガーベッジコレクションが行われるファイルが、開いたファイルであるかどうかを決定する。ガーベッジコレクションが行われるファイルが開いたファイルである場合、次のステップ373は、コピーメタブロックを開き、次に、処理は、前述したステップ363に進行する。しかし、ガーベッジコレクションが行われるファイルが開いたファイルでない場合、次のステップ375は、ファイルメタページカウンタの減少されたカウントが残留メタページカウントに等しいかどうかを問い合わせる。ファイルメタページカウンタの減少されたカウントが残留メタページカウントに等しくない場合、ステップ373によってコピーメタブロックを開く。しかし、ファイルメタページカウンタの減少されたカウントが残留メタページカウントに等しい場合、コピーすべき現在のファイル内にメタブロックのデータが残っていないことを意味する。従って、ステップ377では、残留データを共通メタブロックへコピーするため、開いた共通メタブロックを識別する。次に、ステップ363およびそれ以外の処理はコピーであって、現在のファイルの現在のデータグループの残りのメタページは共通メタブロックへコピーされる。別のメタブロックが満たされる現在のファイルに他のデータグループを書き込むことができるので、ステップ371によって決定されるように、ガーベッジコレクションが行われるファイルが、開いたファイルである場合、この経路はとられない。開いたファイルが閉じられた後、閉じられたファイルをガーベッジコレクションの待ち行列に配置し、この時点で、ステップ377によって、いずれの残留データも共通ブロックへコピーする。
追加のメタページのデータを書き込んだ後、図31の問い合わせ379は、現在、コピーメタブロックがいっぱいであるかどうかを決定する。コピーメタブロックがいっぱいである場合、ステップ381においてコピーメタブロックを閉じ、このことを反映するようにステップ383によってFITを更新する。コピーメタブロックがいっぱいでない場合、またはステップ383の後、問い合わせ385は、ガーベッジコレクションが行われるメタブロックの全データが現在古い状態にされているかどうかを決定する。メタブロックの全データが現在古い状態にされている場合、ステップ387においてメタブロックを消去する。メタブロックの全データが現在古い状態にされていない場合、または、メタブロックを消去した後、問い合わせ389は、プログラム動作中、図28のステップ325によってフォアグラウンドモードが設定されたかどうかを尋ねる。フォアグラウンドモードが設定されていない場合、図31のステップ391は、ホストコマンドが保留中であるかどうかを決定する。ホストコマンドが保留中である場合、ステップ392によって決定されたように進行中のガーベッジコレクションが優先事項でなければ、ステップ393においてFITを更新することによってガーベッジコレクションを一時中断し、次に、図26のステップ253に戻る。しかし、ステップ391によって決定されたようにホストコマンドが保留中でない場合、または、保留中のホストコマンドが存在し、ステップ392によって決定されたように進行中のガーベッジコレクションが優先事項でない場合、処理は問い合わせ359に戻って、次のメタページのデータを現在のファイルメタブロックからコピーメタブロックへコピーする。
フォアグラウンドモードが設定されたことを図31の問い合わせ389が決定した場合、次のステップ395は、図28のステップ327によってリセットされたコピーメタブロックメタページカウンタの値を増大する。事前設定の数N4のメタページが連続してコピーされたことをステップ397が決定した場合、次のステップ399はフォアグラウンドモードをリセットし、ステップ393によってFITを更新する。しかし、数N4に達する前に、コピーすべきメタページがもっとある場合、保留中のホストコマンドがあることを問い合わせ391が決定しない限り、処理はステップ359を続ける。保留中のホストコマンドがない場合、コピー動作を中断し、処理を図26のステップ253に戻す。
問い合わせ359に戻り、データグループ長さカウントがゼロである場合、ファイルメタブロックからコピーメタブロックへの1つのデータグループのコピー動作が完了したことを意味する。この条件下、ステップ401は、この条件を反映するようにFITを更新する。次に、ステップ403において、データグループ番号カウンタを参照して、ガーベッジコレクションが行われる現在のファイルが別のデータグループを含むかどうかを決定する。ガーベッジコレクションが行われる現在のファイルが別のデータグループを含まない場合、ファイルのガーベッジコレクションは完了した。次に、処理をステップ356に戻して、待ち行列から順番に次のファイルまたはメタブロックにガーベッジコレクションを行う。現在のファイルのガーベッジコレクションの完了は、再開することができる進行中のファイルのガーベッジコレクションがもはや存在しないことを意味するので、処理はステップ355に戻らない。
ステップ403から、コピーすべき現在のファイルのデータグループが少なくとももう1つ存在すると分かった場合、ステップ405において、この次のデータグループを含むメタブロックが、古い状態にある他のデータも含むかどうかを決定する。前述したように、ファイルの古いデータを含むメタブロックにガーベッジコレクションが行われるが、メタブロックが、ファイルの残留データを含む共通メタブロックまたは未完成なメタブロックでない限り、ファイルの古いデータを含まないメタブロックにガーベッジコレクションを行わないことが好ましい。従って、次のデータグループのメタブロック内に古いデータが存在することがステップ405によって決定された場合、ステップ407によってデータグループ番号カウンタを、順序が次にあるデータグループの数に更新し、ステップ409において、新たなデータグループ内のデータの量でデータグループ長さカウンタを初期化する。次に、処理はステップ361に進み、前述したように、ファイルの新たなデータグループから最初のメタページのデータを、コピーメタブロック内の次の消去済みメタページへコピーする。
しかし、次のデータグループが存在するメタブロック内にいかなる古いデータも存在しないことがステップ405によって決定された場合でも、(1)次のデータグループが共通メタブロック内に存在するか、または、(2)未完成のメタブロック内に存在し、ファイルが、閉じられたファイルであれば、このメタブロック内のデータのガーベッジコレクションを依然として行いうる。最初に、現在のデータグループが共通メタブロック内に存在するかどうかについて問い合わせ411を行う。現在のデータグループが共通メタブロック内に存在する場合、次のステップ413は、後でガーベッジコレクションを行うため、共通メタブロックを共通メタブロックガーベッジコレクション待ち行列に追加するが、処理はステップ407およびステップ409について継続し、データグループ番号カウンタおよびデータグループ長さカウンタを、以下に参照されるステップ361によってコピーする次のメタブロックの数および長さに更新する。しかし、現在のデータグループが共通メタブロック内に存在しない場合、ステップ415は、現在のデータグループが未完成のメタブロック内に存在するかどうかを問い合わせる。すなわち、ステップ415は、現在のデータグループが、(図15のデータグループF3,D3のような)少なくとも最小量の消去済み容量を依然として有するメタブロック内に存在するかどうかを決定する。現在のデータグループが未完成のメタブロック内に存在しない場合、現在のデータグループがコピーされるのではなくむしろ、処理がステップ403に戻って、ファイルの次のデータグループが存在する場合、これを処理する。しかし、現在のデータグループが未完成のメタブロック内に存在する場合、次の問い合わせ417は、未完成のメタブロックが、開いたファイルのデータを含むかどうかを尋ねる。未完成のメタブロックが開いたファイルのデータを含む場合、問い合わせ403に戻って、ファイルのさらなるデータグループについて継続することによって現在のデータグループのコピーもスキップする。しかし、次のデータグループが存在するメタブロックが、開いたファイルのデータを含まない場合、以下に参照されるステップ407、ステップ409およびステップ361を次のデータグループについて行う。
図31のステップ356に戻って、いかなるファイルまたはメタブロックもガーベッジコレクション待ち行列に存在しないと決定された場合であっても、ガーベッジコレクションを行うことができる。いかなるファイルまたはメタブロックもガーベッジコレクション待ち行列に存在しない場合、処理を終了するよりはむしろ、ステップ421が、N2を上回る消去済みメタブロックが消去済みメタブロックプール内に存在するかどうかを検査する。N2を上回る消去済みメタブロックが消去済みメタブロックプール内に存在する場合、ガーベッジコレクション処理を終了し、図26のステップ253に戻る。しかし、N2を上回る消去済みメタブロックがシステム内に存在しない場合、ステップ421からガーベッジコレクションを実行する機会を得る。このようなガーベッジコレクションは、ステップ423によって示されているように、開いたファイルが存在する場合、これについて行うことができる。待ち行列内に何も存在しないので、プール内の消去済みメタブロックの数がN2以下である場合、さらなる消去済みメタブロックの潜在的なソースは他に何も存在しない可能性が高い。2つ以上の開いたファイルが存在する場合、ステップ425において、それらのうちの1つを選択する。次に、処理は、開かれたファイルについて、前述したようにステップ370、ステップ372およびステップ359を介して進行する。
共通メタブロック内のデータグループに対して現在のガーベッジコレクション動作が行われることが図31の問い合わせ362によって決定された場合、ガーベッジコレクション364は、前述した他のメタブロックの場合と多少異なる。図32のフローチャートは、共通メタブロックのガーベッジコレクションを概説する。ステップ431は、ガーベッジコレクションが進行中であるかどうか、従って、再開されるかどうかを尋ねる。ガーベッジコレクションが進行中である場合、データグループ長さカウンタは、ガーベッジコレクションが一時中断されたときの最終値を保持する。ガーベッジコレクションが進行中でない場合、ステップ435において、処理の対象である最初のデータグループのFITを参照することによってデータグループ番号カウンタを最初に初期化し、次に、ステップ433によって、このデータグループの長さを決定する。
データグループ長さカウンタがゼロを上回っていることがステップ433によって決定された場合、現在のデータグループのコピーを開始する。ステップ437によって、現在のデータグループのメタページを共通メタブロックから読み出し、ステップ439によって、開いた共通メタブロックにプログラムする。次に、ステップ441では、データグループ長さカウンタを1つのメタページだけ減少する。ステップ443によって示されているようにガーベッジコレクションをフォアグラウンドで行う場合、ステップ445によって、コピーメタブロックメタページカウンタを1だけ増大する。このカウンタは、連続してコピーされたデータのメタページの数を追跡し続ける。このカウントが所定の数N4を上回っていることをステップ447によって決定された場合、ステップ449において処理はフォアグラウンドモードを終了させる。その後、ステップ451において、FITを更新し、次に、処理は図26のステップ253に戻る。
コピーメタブロックメタページカウンタがN4以下の値を有することが図32のステップ447によって決定された場合、次のステップは、ホストコマンドが保留中であるかどうかを問い合わせる。ホストコマンドが保留中である場合、ステップ451においてFITを更新し、処理は図26のステップ253に戻って、保留中のホストコマンドを実行することができる。ホストコマンドが保留中でない場合、処理は図32のステップ433に戻って、現在のデータグループに別のデータメタページが存在するかどうかを問い合わせ、現在のデータグループに別のデータメタページが存在する場合、古い共通メタブロックからデータメタページを、開いた共通メタブロックへコピーするなどとなる。これと同様に、ステップ443において、ガーベッジコレクションがフォアグラウンドで実行されないことが決定された場合、次に、ステップ453を実行する。ステップ453によって決定されたように、ホストコマンドが保留中である場合を除いて、処理は、ステップ447を迂回したので、コピーメタブロックメタページカウンタがN4を上回っているかどうかにかかわらず、現在のデータグループ内のデータの次のメタページをコピーする可能性があるステップ433に戻る。この場合、ガーベッジコレクションはバックグラウンドで実行される。
図32のステップ433に戻って、データグループ長さカウントがゼロを上回っていない場合、現在のデータグループの全メタページがコピーされたことが分かる。次に、ステップ455においてFITを更新し、ステップ457によって、ガーベッジコレクションが行われる共通メタブロックに別のデータグループが存在するかどうかを決定する。共通メタブロックに別のデータグループが存在しない場合、ステップ459において、古い共通メタブロックを消去し、処理は図26のステップ253に戻る。しかし、共通メタブロックに別のデータグループが存在する場合、ステップ461によってデータグループ番号カウンタを更新する。次に、ステップ463において、共通メタブロック索引からFITポインタを読み出し、ステップ465において、このポインタによって定義されたFIT項目を読み出す。ステップ467によって決定されたように、FIT項目が現在のデータグループに一致する場合、問い合わせ468は、現在のデータグループが、既に識別された残留データの一部であるかどうかを決定する。現在のデータグループが既に識別された残留データの一部である場合、ステップ469によって、データグループ長さカウンタを、FITから読み出されたデータグループの長さに初期化する。
しかし、ステップ468において、現在のデータグループが既存の残留データ内に存在しないと決定された場合、ステップ470において、現在のデータグループが一部である新たな残留データを識別する。次に、ステップ471では、新たな残留データの全データを記憶するのに充分な空間を有する開いた共通ブロックを識別する。このことは、残留データが2つ以上のデータグループを含む場合、2つ以上の異なるメタブロックの間でファイルの残留データを分割しないようにする。残留データを分割することは、2つ以上のデータグループが独立してコピーされる場合にも生じることがある。この場合、第1のデータグループを記憶するのに充分な消去済み空間を有するが、第2のデータグループを記憶するのに充分な空間を持たない共通ブロックに第1のデータグループをコピーすることがある。次に、第2のデータグループを、異なる共通ブロックへコピーすることになる。このことは、ファイルの残留データを2つの異なるメタブロック間で分割すべきでないので望ましくない。ファイルの残留データがこのように分割される場合、ファイルのガーベッジコレクションまたは共通ブロックのガーベッジコレクションには、より多くの時間がかかる。
次に、ステップ469によって、現在のデータグループのデータグループ長さカウンタを初期化する。ステップ437およびステップ439によって、現在のデータグループのデータの最初のメタページを共通メタブロックから、識別された開いた共通メタブロックへコピーする。しかし、FIT項目が現在のデータグループに一致しないことがステップ467によって決定された場合、処理はステップ457に戻って、共通メタブロック内に別のデータグループが存在するかどうかを決定する。
現在の共通メタブロックの有効データグループのすべてが、予め消去されたメタブロックへ、または、1つ以上の開いた共通メタブロックへコピーされるまで、図32のフローチャートに示されているガーベッジコレクションは継続する。予め消去されたメタブロックは、コピー後、新たな共通メタブロックとなる。異なるファイルのデータグループを、異なる開いた共通メタブロックへコピーすることができる。共通メタブロックは古いデータグループを含んでいたので、ガーベッジコレクション待ち行列に前もって配置されていた。共通メタブロック内への各有効なデータグループのデータの全メタページの完全な転送は、図32のステップを介して、このようなメタページごとに一回の受け渡しを要する。ガーベッジコレクションがフォアグラウンドで行われる場合、または、フォアグラウンドまたはバックグラウンドで動作しているときに新たなホストコマンドが受信されるとき、このコピー動作をN4個のメタページごとに中断することができる。
数N3,N4を永続的に事前設定する代わりとして、ホストのデータプログラミングパターンに応答してメモリシステムコントローラによって数N3,N4を変更して、一様なデータプログラム速度を維持することができる。
動作中のメモリブロックの様々な状態
図33には、前述した種類の直接ファイル記憶メモリシステム内におけるシステムのメモリブロックまたはメタブロックの様々な個々の状態とこれら状態の遷移とを示す。
図33には、前述した種類の直接ファイル記憶メモリシステム内におけるシステムのメモリブロックまたはメタブロックの様々な個々の状態とこれら状態の遷移とを示す。
左側の列では、ブロック501が、消去済みブロックプール内で消去済み状態であると示されている。
次の列では、ブロック503,505,507は各々、何らかの有効データを含むが、ホストからのデータを書き込むことができる消去済み容量も有する。書き込みブロック503は単一ファイルの有効データで部分的に書き込まれ、ファイルのさらなるデータがホストによって供給されたとき、このブロックにファイルのさらなるデータを書き込む必要がある。コピーブロック505は単一ファイルの有効データで部分的に書き込まれ、ファイルのさらなるデータがファイルのガーベッジコレクション中にコピーされるとき、このブロックにファイルのさらなるデータを書き込む必要がある。開いた共通ブロック507は2つ以上のファイルの有効データで部分的に書き込まれ、ガーベッジコレクション中、任意のファイルの残留データグループをこのブロックに書き込むことができる。
次の列のブロック509,511はファイルデータで満たされている。ファイルブロック509は、単一ファイルの有効データで満たされている。共通ブロック511は、2つ以上のファイルの有効データで満たされている。
図33の右側の列の1つ手前の列は、何らかの古いデータを各々含むブロック513,515,517,519,521を含む。古いファイルブロック513は、単一ファイルの有効データおよび古いデータの任意の組み合わせで満たされている。古い書き込みブロック515は、単一ファイルの有効データおよび古いデータの任意の組み合わせで部分的に書き込まれ、このファイルのさらなるデータがホストによって供給されたとき、ファイルのさらなるデータをこのブロックに書き込む必要がある。古いコピーブロック517は、単一ファイルの有効データおよび古いデータの任意の組み合わせで部分的に書き込まれている。古い開いた共通ブロック519は、2つ以上のファイルの有効データおよび古いデータの任意の組み合わせで部分的に書き込まれている。古い共通ブロック521は、2つ以上のファイルの有効データおよび古いデータの任意の組み合わせで部分的に満たされている。
図33の右側の列の古いブロック523は、古いデータだけを含む。
図33に示されているブロック状態間の個々のブロックの遷移も、小文字と共にラベル付けされた線によって示されている。これらの遷移は以下のとおりである。
a−消去済みブロック501から書き込みブロック503へ。すなわち、単一ホストファイルのデータは、消去済みブロックに書き込まれる。
b−書き込みブロック503から書き込みブロック503へ。すなわち、ホストからの単一ファイルのデータは、このファイルの書き込みブロックに書き込まれる。
c−書き込みブロック503からファイルブロック509へ。すなわち、ホストからの単一ファイルのデータは、このファイルの書き込みブロックをいっぱいにするために書き込まれる。
d−ファイルブロック509から古いファイルブロック513へ。すなわち、ファイルブロックのデータの一部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれた結果として古くなる。
e−古いファイルブロック513から古いブロック523へ。すなわち、古いファイルブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
f−書き込みブロック503から古い書き込みブロック515へ。すなわち、書き込みブロック内のデータの一部は、更新バージョンのデータがホストによって同じ書き込みブロックに書き込まれたか、または、ガーベッジコレクション中、このデータが別のブロックへコピーされた結果として古くなる。
g−古い書き込みブロック515から古い書き込みブロック515へ。すなわち、ホストからの単一ファイルのデータは、このファイルの古い書き込みブロックに書き込まれる。
h−古い書き込みブロック515から古いファイルブロック513へ。すなわち、ホストからの単一ファイルのデータは、このファイルの古い書き込みブロックをいっぱいにするために書き込まれる。
i−古い書き込みブロック515から古いブロック523へ。すなわち、古い書き込みブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
j−消去済みブロック501からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックから消去済みブロックへコピーされる。
k−書き込みブロック503からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックからこのファイルの書き込みブロックへコピーされる。
l−コピーブロック505からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックからこのファイルのコピーブロックへコピーされる。
m−コピーブロック505からファイルブロック509へ。すなわち、ガーベッジコレクション中、別のブロックから単一ファイルのデータは、このファイルのコピーブロックをいっぱいにするようにコピーされる。
n−コピーブロック505から書き込みブロック503へ。すなわち、ガーベッジコレクション中、ファイルが再度開かれたとき、ホストからの単一ファイルのデータは、このファイルのコピーブロックに書き込まれる。
o−コピーブロック505から古いコピーブロック517へ。すなわち、コピーブロック内のデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、または、このファイルがホストによって削除された結果として古くなる。
p−古いコピーブロック517から古いブロック523へ。すなわち、古いコピーブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
q−書き込みブロック503から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、閉じられた異なるファイルの書き込みブロックに書き込まれる。
r−コピーブロック505から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、異なるファイルの残留データを含むコピーブロックに書き込まれる。
s−開いた共通ブロック507から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、異なるブロックから開いた共通ブロックへコピーされる。
t−開いた共通ブロック507から古い開いた共通ブロック519へ。すなわち、開いた共通ブロック内の1つのファイルのデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
u−古い開いた共通ブロック519から古いブロック523へ。古い開いた共通ブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
v−開いた共通ブロック507から共通ブロック511へ。すなわち、ファイルの残留データグループは、ガーベッジコレクション中、このファイルの開いた共通ブロックをいっぱいにするために別のブロックからコピーされる。
w−共通ブロック511から古い共通ブロック521へ。すなわち、共通ブロック内の1つのファイルのデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
x−古い共通ブロック521から古いブロック523へ。すなわち、古い共通ブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
y−書き込みブロック503から古いブロック523へ。すなわち、書き込みブロック内の単一ファイルのすべての有効データは、このファイルがホストによって削除された結果として古くなる。
z−コピーブロック505から古いブロック523へ。すなわち、コピーブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
aa−ファイルブロック509から古いブロック523へ。すなわち、ファイルブロック内の全データは、ファイルがホストによって削除された結果として古くなる。
ab−古いブロック523から消去済みブロック501へ。すなわち、古いブロックは、ガーベッジコレクション中、消去される。
a−消去済みブロック501から書き込みブロック503へ。すなわち、単一ホストファイルのデータは、消去済みブロックに書き込まれる。
b−書き込みブロック503から書き込みブロック503へ。すなわち、ホストからの単一ファイルのデータは、このファイルの書き込みブロックに書き込まれる。
c−書き込みブロック503からファイルブロック509へ。すなわち、ホストからの単一ファイルのデータは、このファイルの書き込みブロックをいっぱいにするために書き込まれる。
d−ファイルブロック509から古いファイルブロック513へ。すなわち、ファイルブロックのデータの一部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれた結果として古くなる。
e−古いファイルブロック513から古いブロック523へ。すなわち、古いファイルブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
f−書き込みブロック503から古い書き込みブロック515へ。すなわち、書き込みブロック内のデータの一部は、更新バージョンのデータがホストによって同じ書き込みブロックに書き込まれたか、または、ガーベッジコレクション中、このデータが別のブロックへコピーされた結果として古くなる。
g−古い書き込みブロック515から古い書き込みブロック515へ。すなわち、ホストからの単一ファイルのデータは、このファイルの古い書き込みブロックに書き込まれる。
h−古い書き込みブロック515から古いファイルブロック513へ。すなわち、ホストからの単一ファイルのデータは、このファイルの古い書き込みブロックをいっぱいにするために書き込まれる。
i−古い書き込みブロック515から古いブロック523へ。すなわち、古い書き込みブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
j−消去済みブロック501からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックから消去済みブロックへコピーされる。
k−書き込みブロック503からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックからこのファイルの書き込みブロックへコピーされる。
l−コピーブロック505からコピーブロック505へ。すなわち、ガーベッジコレクション中、単一ファイルのデータは、別のブロックからこのファイルのコピーブロックへコピーされる。
m−コピーブロック505からファイルブロック509へ。すなわち、ガーベッジコレクション中、別のブロックから単一ファイルのデータは、このファイルのコピーブロックをいっぱいにするようにコピーされる。
n−コピーブロック505から書き込みブロック503へ。すなわち、ガーベッジコレクション中、ファイルが再度開かれたとき、ホストからの単一ファイルのデータは、このファイルのコピーブロックに書き込まれる。
o−コピーブロック505から古いコピーブロック517へ。すなわち、コピーブロック内のデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、または、このファイルがホストによって削除された結果として古くなる。
p−古いコピーブロック517から古いブロック523へ。すなわち、古いコピーブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
q−書き込みブロック503から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、閉じられた異なるファイルの書き込みブロックに書き込まれる。
r−コピーブロック505から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、異なるファイルの残留データを含むコピーブロックに書き込まれる。
s−開いた共通ブロック507から開いた共通ブロック507へ。すなわち、ガーベッジコレクション中、ファイルの残留データは、異なるブロックから開いた共通ブロックへコピーされる。
t−開いた共通ブロック507から古い開いた共通ブロック519へ。すなわち、開いた共通ブロック内の1つのファイルのデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
u−古い開いた共通ブロック519から古いブロック523へ。古い開いた共通ブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
v−開いた共通ブロック507から共通ブロック511へ。すなわち、ファイルの残留データグループは、ガーベッジコレクション中、このファイルの開いた共通ブロックをいっぱいにするために別のブロックからコピーされる。
w−共通ブロック511から古い共通ブロック521へ。すなわち、共通ブロック内の1つのファイルのデータの一部または全部は、更新バージョンのデータがホストによってこのファイルの書き込みブロックに書き込まれたか、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
x−古い共通ブロック521から古いブロック523へ。すなわち、古い共通ブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
y−書き込みブロック503から古いブロック523へ。すなわち、書き込みブロック内の単一ファイルのすべての有効データは、このファイルがホストによって削除された結果として古くなる。
z−コピーブロック505から古いブロック523へ。すなわち、コピーブロック内のすべての有効データは、ガーベッジコレクション中、このデータが別のブロックへコピーされたか、または、このファイルがホストによって削除された結果として古くなる。
aa−ファイルブロック509から古いブロック523へ。すなわち、ファイルブロック内の全データは、ファイルがホストによって削除された結果として古くなる。
ab−古いブロック523から消去済みブロック501へ。すなわち、古いブロックは、ガーベッジコレクション中、消去される。
結論
本発明の例示的な実施形態を参照して本発明の様々な態様を説明してきたが、当然のことながら、本発明は、特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
本発明の例示的な実施形態を参照して本発明の様々な態様を説明してきたが、当然のことながら、本発明は、特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
Claims (33)
- 任意の新たなデータが書き込まれる前に消去され、少なくとも512バイトのデータを個々に含む複数のデータ単位を記憶する容量を個々に有するブロックに編成されたメモリセルを有する再プログラム可能な不揮発性大容量記憶システムを動作する方法であって、
固有のファイル識別子および前記識別されたファイル内のデータのオフセットを含む論理アドレスを有するデータを受信するステップと、
前記受信したデータをメモリセルの前記ブロック内の物理アドレスにプログラムするステップと、
前記ファイルを構成する可変量のデータのグループを識別し、前記グループ内のデータの連続的な論理オフセットアドレスおよび連続的な物理アドレスの双方を個々に有する前記個々のファイルの前記プログラムされたデータの複数のレコードを維持するステップと、
を含む方法。 - 請求項1記載の方法において、
前記複数のレコードを維持するステップは、前記グループ内の前記データの少なくとも開始論理オフセットアドレスおよび開始物理アドレスを前記個々のレコード内に供給するステップを含む方法。 - 請求項2記載の方法において、
前記複数のレコードを維持するステップは、前記グループ内の前記データの長さを前記個々のレコード内に供給するステップをさらに含む方法。 - 請求項3記載の方法において、
前記個々のファイルの前記レコードをグループ化することによって編成された前記複数のレコードのファイルマップを維持するステップをさらに含む方法。 - 請求項1記載の方法において、
前記データをプログラムするステップは、消去済みブロックの第1の物理アドレスから開始し、必要に応じて物理順に前記消去済みブロックを経て、前記ファイルの前記受信したデータのすべてが1回のプログラム動作でプログラムされるまで他の消去済みブロックに継続することによって、新たなファイルの前記受信したデータをプログラムするステップを含む方法。 - 請求項1記載の方法において、
前記データをプログラムするステップは、前記メモリシステム内に以前に記憶された既存ファイルの受信した追加のデータを、前記既存のファイルデータが前記ブロック内で終了した直後、ブロックの物理アドレスから開始し、必要に応じて物理順に前記ブロックの消去済み部分を経て、前記ファイルの前記追加のデータのすべてが1回のプログラム動作でプログラムされるまで他の消去済みブロックに継続することによってプログラムするステップを含む方法。 - 請求項6記載の方法において、
前記追加のデータをプログラムするステップは、前記以前に記憶されたファイル内へ挿入するデータをプログラムするステップを含む方法。 - 請求項7記載の方法において、
複数のレコードを維持するステップは、前記既存ファイルの前記既存のデータグループのレコードを変更し、少なくとも1つの他のデータグループの少なくとも1つの追加レコードを追加するステップを含む方法。 - 請求項6記載の方法において、
前記追加のデータをプログラムするステップは、前記以前に記憶されたファイルの前記データの一部を更新し、これによって、前記以前に記憶されたファイルの前記データの一部が古くなるデータをプログラムするステップを含む方法。 - 請求項9記載の方法において、
複数のレコードを維持するステップは、前記既存ファイルの前記既存のデータグループのレコードを変更し、少なくとも1つの他のデータグループの少なくとも1つの追加レコードを追加するステップを含む方法。 - 請求項1記載の方法において、
前記個々の単位の少なくとも幾つかは、複数の前記データのグループを含む方法。 - 請求項1記載の方法において、
前記大容量記憶システムは、少なくとも256メガバイトのデータを記憶するのに充分な多数のメモリセルを含む方法。 - 請求項1記載の方法において、
前記個々のデータ単位は、少なくとも1,024バイトを含む方法。 - 請求項1記載の方法において、
少なくとも8つのデータ単位は、前記大容量記憶システムの個々のブロック内に書き込まれる方法。 - ホストシステムと、同時に消去できるメモリセルのブロックに編成されたメモリセルを有する再プログラム可能な不揮発性大容量記憶システムとの間でデータを転送する方法であって、個々のブロックは、新たなデータが前記ブロック内に書き込まれる前に消去され、
前記ホストシステムは、前記ホストシステムが生成する個々のファイルのデータを固有のファイル識別子と前記個々のファイル内の所定サイズのデータ単位のオフセットとによって識別し、
前記大容量記憶システムは、前記個々のファイルのデータを、1つのファイル内に不連続のデータオフセットを有するデータのグループの間、または、前記ファイルオフセットアドレス単位の分解能に等しい物理アドレス分解能で指定された2つの異なるファイルのデータのグループ間に境界を有するメモリセルの少なくとも1つの予め消去されたブロック内に記憶する方法。 - 請求項15記載の方法において、
前記所定サイズのデータ単位は、1バイトのデータを含む方法。 - 請求項15記載の方法において、
前記データのグループは、前記データの連続的な論理オフセットおよび連続的な物理アドレスの双方を有する可変量のデータを個々に含む方法。 - 請求項17記載の方法において、
前記大容量記憶システムは、前記個々のファイルを構成する前記グループのデータの複数のレコードを維持する方法。 - 請求項18記載の方法において、
前記複数のレコードを維持することは、前記グループ内の前記データの少なくとも開始論理オフセットアドレスおよび開始物理アドレスを前記個々のレコード内に供給することを含む方法。 - 請求項19記載の方法において、
前記複数のレコードを維持することは、前記グループ内の前記データの長さを前記個々のレコード内に供給することをさらに含む方法。 - ホストシステムと一緒に再プログラム可能な不揮発性メモリシステムを動作する方法であって、前記メモリシステムは、新たなデータが書き込まれる前に消去されるメモリセルのブロックを有し、
固有のファイル識別子によってアドレス指定されたデータを受信するステップと、
前記受信したファイルデータを前記メモリシステムのブロックの1つ以上に記憶するステップと、
その後、前記記憶されたファイルデータの少なくとも幾つかを、その後の前記ホストからのコマンドに応答した結果として古い状態にするステップと、
その後、少なくとも1つの消去済みブロックを獲得してから、新たなデータを記憶するのに前記消去済みブロックの使用を必要とするデータをプログラムするコマンドを前記ホストが送信するように、前記古いファイルデータを含む1つ以上のブロックにガーベッジコレクションを行うステップと、
を含む方法。 - 請求項21記載の方法において、
前記ブロックにガーベッジコレクションを行うステップは、前記ホストがアイドル状態にある期間中に生じる方法。 - 請求項21記載の方法において、
前記ブロックにガーベッジコレクションを行うステップは、データを書き込むか、または読み出す前記メモリシステムの動作と交互に行われる期間中に生じる方法。 - 請求項21記載の方法において、
前記ブロックにガーベッジコレクションを行うステップは、前記古いファイルのデータを含む前記1つ以上のブロックから有効データを、物理順序で少なくとも1つの他のブロック内にコピーするステップを含み、前記物理順序は、前記コピーされたデータの前記論理オフセットアドレス順序と同じである方法。 - 請求項21記載の方法において、
前記固有のファイル識別子によってアドレス指定されたデータを受信するステップは、前記識別されたファイル内のオフセットを用いてアドレス指定されたデータを受信するステップを含む方法。 - ホストシステムと、同時に消去できるメモリセルのブロックを有する再プログラム可能な不揮発性大容量記憶システムとの間でデータを転送する方法であって、個々のブロックは、前記ブロック内に新たなデータが書き込まれる前に消去され、
前記ホストシステムは、前記ホストシステムが生成する個々のファイルのデータを固有のファイル識別子と前記個々のファイル内の所定サイズのデータ単位のオフセットとによって識別し、前記ファイル識別子および前記オフセットを前記大容量記憶システムに送信し、
前記大容量記憶システムは、前記ホストシステムから受信した順で、前記ファイル内のデータオフセットから独立している連続的な物理アドレスを有するメモリセルの少なくとも1つの予め消去されたブロック内にファイルのデータ単位を書き込む方法。 - 請求項26記載の方法において、
前記大容量記憶システムは、少なくとも1つのメモリブロックを満たすように前記ファイルのデータ単位をさらに書き込み、別のメモリブロックを満たすのに足りない量の任意の残留データが、異なるファイルの残留データも含む共通ブロック内に書き込まれる方法。 - 大容量記憶システムであって、
任意の新たなデータが書き込まれる前に消去され、少なくとも512バイトのデータを個々に含む受信した複数のデータ単位を記憶する容量を個々に有するブロックに編成された不揮発性電荷記憶半導体メモリセルのアレイと、
前記メモリセルアレイと接続され、固有のファイル識別子と、識別されたファイル内のデータのオフセットとを含む論理アドレスを有するデータを受信して、前記受信したデータをメモリセルの前記ブロック内の物理アドレスにプログラムするように適合され、前記ファイルを構成する可変量のデータのグループを識別する前記個々のファイルの前記プログラムされたデータの複数のレコードを維持するようにさらに動作するコントローラであって、前記グループ内のデータは連続的な論理オフセットアドレスおよび連続的な物理アドレスの双方を個々に有し、前記個々のレコードは、前記グループ内の前記データの少なくとも開始論理オフセットアドレスおよび開始物理アドレスを含むコントローラと、
を備える大容量記憶システム。 - 請求項28記載の大容量記憶システムにおいて、
前記個々のレコードは、前記グループ内の前記データの長さをさらに含む大容量記憶システム。 - 請求項28記載の大容量記憶システムにおいて、
前記メモリセルアレイは、少なくとも256メガバイトのデータを記憶するのに充分なメモリセルの数を含む方法。 - 請求項28記載の大容量記憶システムにおいて、
前記個々のデータ単位は、少なくとも1,024バイトのデータを含む方法。 - 大容量記憶システムであって、
任意の新たなデータが書き込まれる前に消去され、少なくとも1,024バイトの受信したデータを記憶する容量を個々に有するブロックに編成された不揮発性電荷記憶半導体メモリセルのアレイと、
前記メモリセルアレイと接続され、固有のファイル識別子と、識別されたファイル内のデータのオフセットとを含む論理アドレスを有するデータを受信して、前記個々のメモリセルブロックの前記容量以下の大きさを個々に有し、連続的な論理アドレスおよび連続的な物理アドレスを有するデータを含む定義されたデータのグループとして、前記受信したデータをメモリセルの前記ブロック内の物理アドレスにプログラムするように適合されたコントローラと、
前記メモリセルアレイに記憶されたデータの個々のグループのレコードを記憶することができるテーブルであって、ファイルのデータの個々のデータレコードは、開始論理オフセットアドレス、開始物理アドレスおよび前記データのグループの長さを含むテーブルと、
を備える大容量記憶システム。 - 請求項32記載の大容量記憶システムにおいて、
前記個々のデータレコードの前記開始物理アドレスは、メモリセルのブロックの識別子と、識別されたブロック内のバイト位置とを含む大容量記憶システム。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/060,248 US20060184719A1 (en) | 2005-02-16 | 2005-02-16 | Direct data file storage implementation techniques in flash memories |
PCT/US2006/004555 WO2006088719A2 (en) | 2005-02-16 | 2006-02-08 | Direct data file storage implementation techniques in flash memories |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2008530708A true JP2008530708A (ja) | 2008-08-07 |
Family
ID=36694483
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2007556204A Pending JP2008530708A (ja) | 2005-02-16 | 2006-02-08 | フラッシュメモリにおける直接データファイル記憶実施技術 |
Country Status (8)
Country | Link |
---|---|
US (3) | US20060184719A1 (ja) |
EP (1) | EP1875334A2 (ja) |
JP (1) | JP2008530708A (ja) |
KR (1) | KR20080000557A (ja) |
CN (1) | CN101147119B (ja) |
IL (1) | IL185307A0 (ja) |
TW (1) | TW200639633A (ja) |
WO (1) | WO2006088719A2 (ja) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2008016081A1 (ja) * | 2006-08-04 | 2009-12-24 | パナソニック株式会社 | メモリコントローラ、不揮発性記憶装置、アクセス装置、及び不揮発性記憶システム |
KR101363422B1 (ko) | 2012-10-04 | 2014-02-14 | 주식회사 디에이아이오 | 비휘발성 메모리 시스템 |
JP2019174941A (ja) * | 2018-03-27 | 2019-10-10 | 東芝メモリ株式会社 | ストレージ装置、コンピュータシステムおよびストレージ装置の動作方法 |
WO2021015174A1 (ja) * | 2019-07-25 | 2021-01-28 | 株式会社ソニー・インタラクティブエンタテインメント | ストレージ管理装置、ストレージ管理方法およびプログラム |
Families Citing this family (170)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060184719A1 (en) * | 2005-02-16 | 2006-08-17 | Sinclair Alan W | Direct data file storage implementation techniques in flash memories |
US9104315B2 (en) | 2005-02-04 | 2015-08-11 | Sandisk Technologies Inc. | Systems and methods for a mass data storage system having a file-based interface to a host and a non-file-based interface to secondary storage |
US20060184718A1 (en) | 2005-02-16 | 2006-08-17 | Sinclair Alan W | Direct file data programming and deletion in flash memories |
US7877539B2 (en) * | 2005-02-16 | 2011-01-25 | Sandisk Corporation | Direct data file storage in flash memories |
JPWO2006090606A1 (ja) * | 2005-02-24 | 2008-07-24 | コニカミノルタホールディングス株式会社 | ファイル又はディレクトリの名称生成方法及び装置 |
US7409489B2 (en) * | 2005-08-03 | 2008-08-05 | Sandisk Corporation | Scheduling of reclaim operations in non-volatile memory |
US7480766B2 (en) * | 2005-08-03 | 2009-01-20 | Sandisk Corporation | Interfacing systems operating through a logical address space and on a direct data file basis |
US7949845B2 (en) | 2005-08-03 | 2011-05-24 | Sandisk Corporation | Indexing of file data in reprogrammable non-volatile memories that directly store data files |
US7669003B2 (en) | 2005-08-03 | 2010-02-23 | Sandisk Corporation | Reprogrammable non-volatile memory systems with indexing of directly stored data files |
US8938217B2 (en) * | 2005-08-22 | 2015-01-20 | Apple Inc. | Communicating and storing information associated with media broadcasts |
US7814262B2 (en) * | 2005-10-13 | 2010-10-12 | Sandisk Corporation | Memory system storing transformed units of data in fixed sized storage blocks |
US8311994B2 (en) | 2005-10-14 | 2012-11-13 | Pivotlink Corp. | Run total encoded data processing |
US20070106842A1 (en) * | 2005-11-04 | 2007-05-10 | Conley Kevin M | Enhanced first level storage caching methods using nonvolatile memory |
US7634585B2 (en) | 2005-11-04 | 2009-12-15 | Sandisk Corporation | In-line cache using nonvolatile memory between host and disk device |
US7877540B2 (en) * | 2005-12-13 | 2011-01-25 | Sandisk Corporation | Logically-addressed file storage methods |
US7769978B2 (en) | 2005-12-21 | 2010-08-03 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US7793068B2 (en) | 2005-12-21 | 2010-09-07 | Sandisk Corporation | Dual mode access for non-volatile storage devices |
US7747837B2 (en) | 2005-12-21 | 2010-06-29 | Sandisk Corporation | Method and system for accessing non-volatile storage devices |
US20070143566A1 (en) * | 2005-12-21 | 2007-06-21 | Gorobets Sergey A | Non-volatile memories with data alignment in a directly mapped file storage system |
US20070143567A1 (en) * | 2005-12-21 | 2007-06-21 | Gorobets Sergey A | Methods for data alignment in non-volatile memories with a directly mapped file storage system |
WO2007073536A2 (en) * | 2005-12-21 | 2007-06-28 | Sandisk Corporation | Non-volatile memories and methods with memory allocation for a directly mapped file storage system |
CN100485681C (zh) * | 2006-03-23 | 2009-05-06 | 北京握奇数据系统有限公司 | 智能卡存储系统及该系统中文件创建管理的方法 |
FI20060427L (fi) * | 2006-05-03 | 2007-11-04 | Tellabs Oy | Menetelmä ja laitteisto peräkkäistiedoston käsittelemiseksi |
US7564721B2 (en) * | 2006-05-25 | 2009-07-21 | Micron Technology, Inc. | Method and apparatus for improving storage performance using a background erase |
JP5019567B2 (ja) * | 2006-08-04 | 2012-09-05 | ソニーモバイルコミュニケーションズ株式会社 | メモリ管理方法および携帯端末装置 |
US8489817B2 (en) | 2007-12-06 | 2013-07-16 | Fusion-Io, Inc. | Apparatus, system, and method for caching data |
WO2008070191A2 (en) | 2006-12-06 | 2008-06-12 | Fusion Multisystems, Inc. (Dba Fusion-Io) | Apparatus, system, and method for a reconfigurable baseboard management controller |
US8935302B2 (en) | 2006-12-06 | 2015-01-13 | Intelligent Intellectual Property Holdings 2 Llc | Apparatus, system, and method for data block usage information synchronization for a non-volatile storage volume |
US8578127B2 (en) | 2009-09-09 | 2013-11-05 | Fusion-Io, Inc. | Apparatus, system, and method for allocating storage |
US8166267B2 (en) * | 2006-12-26 | 2012-04-24 | Sandisk Technologies Inc. | Managing a LBA interface in a direct data file memory system |
US8046522B2 (en) * | 2006-12-26 | 2011-10-25 | SanDisk Technologies, Inc. | Use of a direct data file system with a continuous logical address space interface and control of file address storage in logical blocks |
US7917686B2 (en) | 2006-12-26 | 2011-03-29 | Sandisk Corporation | Host system with direct data file interface configurability |
US7739444B2 (en) | 2006-12-26 | 2010-06-15 | Sandisk Corporation | System using a direct data file system with a continuous logical address space interface |
US8209461B2 (en) | 2006-12-26 | 2012-06-26 | Sandisk Technologies Inc. | Configuration of host LBA interface with flash memory |
US20080155175A1 (en) * | 2006-12-26 | 2008-06-26 | Sinclair Alan W | Host System That Manages a LBA Interface With Flash Memory |
US8510533B2 (en) | 2006-12-27 | 2013-08-13 | Intel Corporation | Method of managing data on a non-volatile memory |
US8380944B2 (en) * | 2007-03-01 | 2013-02-19 | Douglas Dumitru | Fast block device and methodology |
US7987332B2 (en) * | 2007-03-21 | 2011-07-26 | Sandisk Technologies Inc. | Methods for storing memory operations in a queue |
US20080235480A1 (en) * | 2007-03-21 | 2008-09-25 | Shai Traister | Systems for storing memory operations in a queue |
US9207876B2 (en) | 2007-04-19 | 2015-12-08 | Microsoft Technology Licensing, Llc | Remove-on-delete technologies for solid state drive optimization |
US8041883B2 (en) | 2007-05-09 | 2011-10-18 | Stmicroelectronics S.R.L. | Restoring storage devices based on flash memories and related circuit, system, and method |
US7882301B2 (en) * | 2007-05-09 | 2011-02-01 | Stmicroelectronics S.R.L. | Wear leveling in storage devices based on flash memories and related circuit, system, and method |
US7991942B2 (en) | 2007-05-09 | 2011-08-02 | Stmicroelectronics S.R.L. | Memory block compaction method, circuit, and system in storage devices based on flash memories |
US20080282024A1 (en) * | 2007-05-09 | 2008-11-13 | Sudeep Biswas | Management of erase operations in storage devices based on flash memories |
JP4781373B2 (ja) * | 2007-05-14 | 2011-09-28 | 株式会社バッファロー | 記憶装置 |
US8713283B2 (en) * | 2007-06-08 | 2014-04-29 | Sandisk Technologies Inc. | Method of interfacing a host operating through a logical address space with a direct file storage medium |
US20080307156A1 (en) * | 2007-06-08 | 2008-12-11 | Sinclair Alan W | System For Interfacing A Host Operating Through A Logical Address Space With A Direct File Storage Medium |
US8239639B2 (en) * | 2007-06-08 | 2012-08-07 | Sandisk Technologies Inc. | Method and apparatus for providing data type and host file information to a mass storage system |
US8504784B2 (en) * | 2007-06-27 | 2013-08-06 | Sandisk Technologies Inc. | Scheduling methods of phased garbage collection and housekeeping operations in a flash memory system |
US8131972B2 (en) * | 2007-09-19 | 2012-03-06 | International Business Machines Corporation | Method and apparatus for improving memory coalescing in a virtualized hardware environment |
US7836226B2 (en) | 2007-12-06 | 2010-11-16 | Fusion-Io, Inc. | Apparatus, system, and method for coordinating storage requests in a multi-processor/multi-thread environment |
US9519540B2 (en) | 2007-12-06 | 2016-12-13 | Sandisk Technologies Llc | Apparatus, system, and method for destaging cached data |
US8880483B2 (en) * | 2007-12-21 | 2014-11-04 | Sandisk Technologies Inc. | System and method for implementing extensions to intelligently manage resources of a mass storage system |
US8001316B2 (en) * | 2007-12-27 | 2011-08-16 | Sandisk Il Ltd. | Controller for one type of NAND flash memory for emulating another type of NAND flash memory |
US20090249087A1 (en) * | 2008-03-25 | 2009-10-01 | Nir Jacob Wakrat | Power Event Indicator for Managed Memory Device |
US8504759B2 (en) * | 2009-05-26 | 2013-08-06 | Micron Technology, Inc. | Method and devices for controlling power loss |
US20100318720A1 (en) * | 2009-06-16 | 2010-12-16 | Saranyan Rajagopalan | Multi-Bank Non-Volatile Memory System with Satellite File System |
CN101957799B (zh) * | 2009-07-16 | 2012-07-04 | 群联电子股份有限公司 | 用于闪速存储器的数据写入方法及其控制电路与存储系统 |
US9218349B2 (en) * | 2009-07-27 | 2015-12-22 | International Business Machines Corporation | Method and system for transformation of logical data objects for storage |
US8631187B2 (en) * | 2009-08-07 | 2014-01-14 | Intel Corporation | Dual-scope directory for a non-volatile memory storage system |
KR101717644B1 (ko) | 2009-09-08 | 2017-03-27 | 샌디스크 테크놀로지스 엘엘씨 | 고체-상태 저장 디바이스 상에서 데이터를 캐싱하는 장치, 시스템, 및 방법 |
WO2011031899A2 (en) | 2009-09-09 | 2011-03-17 | Fusion-Io, Inc. | Apparatus, system, and method for power reduction in a storage device |
US9223514B2 (en) | 2009-09-09 | 2015-12-29 | SanDisk Technologies, Inc. | Erase suspend/resume for memory |
US9122579B2 (en) | 2010-01-06 | 2015-09-01 | Intelligent Intellectual Property Holdings 2 Llc | Apparatus, system, and method for a storage layer |
TWI489718B (zh) * | 2009-10-14 | 2015-06-21 | Inventec Appliances Corp | 儲存裝置及其運作方法 |
US20110161560A1 (en) * | 2009-12-31 | 2011-06-30 | Hutchison Neil D | Erase command caching to improve erase performance on flash memory |
US9134918B2 (en) * | 2009-12-31 | 2015-09-15 | Sandisk Technologies Inc. | Physical compression of data with flat or systematic pattern |
WO2011143628A2 (en) | 2010-05-13 | 2011-11-17 | Fusion-Io, Inc. | Apparatus, system, and method for conditional and atomic storage operations |
US8626986B2 (en) * | 2010-06-30 | 2014-01-07 | Sandisk Technologies Inc. | Pre-emptive garbage collection of memory blocks |
CN101901263A (zh) * | 2010-07-22 | 2010-12-01 | 华为终端有限公司 | 文件系统的访问方法及装置 |
US8725934B2 (en) | 2011-12-22 | 2014-05-13 | Fusion-Io, Inc. | Methods and appratuses for atomic storage operations |
WO2012016089A2 (en) | 2010-07-28 | 2012-02-02 | Fusion-Io, Inc. | Apparatus, system, and method for conditional and atomic storage operations |
US8984216B2 (en) | 2010-09-09 | 2015-03-17 | Fusion-Io, Llc | Apparatus, system, and method for managing lifetime of a storage device |
US10817502B2 (en) | 2010-12-13 | 2020-10-27 | Sandisk Technologies Llc | Persistent memory management |
WO2012082792A2 (en) | 2010-12-13 | 2012-06-21 | Fusion-Io, Inc. | Apparatus, system, and method for auto-commit memory |
US10817421B2 (en) | 2010-12-13 | 2020-10-27 | Sandisk Technologies Llc | Persistent data structures |
US9218278B2 (en) | 2010-12-13 | 2015-12-22 | SanDisk Technologies, Inc. | Auto-commit memory |
US9047178B2 (en) | 2010-12-13 | 2015-06-02 | SanDisk Technologies, Inc. | Auto-commit memory synchronization |
US9208071B2 (en) | 2010-12-13 | 2015-12-08 | SanDisk Technologies, Inc. | Apparatus, system, and method for accessing memory |
US20120239860A1 (en) | 2010-12-17 | 2012-09-20 | Fusion-Io, Inc. | Apparatus, system, and method for persistent data management on a non-volatile storage media |
US9213594B2 (en) | 2011-01-19 | 2015-12-15 | Intelligent Intellectual Property Holdings 2 Llc | Apparatus, system, and method for managing out-of-service conditions |
JP5917163B2 (ja) * | 2011-01-27 | 2016-05-11 | キヤノン株式会社 | 情報処理装置、その制御方法及びプログラム並びに記憶媒体 |
WO2012106362A2 (en) | 2011-01-31 | 2012-08-09 | Fusion-Io, Inc. | Apparatus, system, and method for managing eviction of data |
US9003104B2 (en) | 2011-02-15 | 2015-04-07 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a file-level cache |
US9201677B2 (en) | 2011-05-23 | 2015-12-01 | Intelligent Intellectual Property Holdings 2 Llc | Managing data input/output operations |
US8874823B2 (en) | 2011-02-15 | 2014-10-28 | Intellectual Property Holdings 2 Llc | Systems and methods for managing data input/output operations |
WO2012116369A2 (en) | 2011-02-25 | 2012-08-30 | Fusion-Io, Inc. | Apparatus, system, and method for managing contents of a cache |
US8966191B2 (en) | 2011-03-18 | 2015-02-24 | Fusion-Io, Inc. | Logical interface for contextual storage |
US9563555B2 (en) | 2011-03-18 | 2017-02-07 | Sandisk Technologies Llc | Systems and methods for storage allocation |
EP3346386B1 (en) | 2011-09-30 | 2020-01-22 | Intel Corporation | Non-volatile random access memory (nvram) as a replacement for traditional mass storage |
WO2013048485A1 (en) | 2011-09-30 | 2013-04-04 | Intel Corporation | Autonomous initialization of non-volatile random access memory in a computer system |
US9430372B2 (en) | 2011-09-30 | 2016-08-30 | Intel Corporation | Apparatus, method and system that stores bios in non-volatile random access memory |
CN107608910B (zh) | 2011-09-30 | 2021-07-02 | 英特尔公司 | 用于实现具有不同操作模式的多级存储器分级结构的设备和方法 |
WO2013048483A1 (en) * | 2011-09-30 | 2013-04-04 | Intel Corporation | Platform storage hierarchy with non-volatile random access memory having configurable partitions |
CN102521289B (zh) * | 2011-11-29 | 2013-12-04 | 华为技术有限公司 | 一种文件同步方法、装置及系统 |
US8762627B2 (en) | 2011-12-21 | 2014-06-24 | Sandisk Technologies Inc. | Memory logical defragmentation during garbage collection |
US9274937B2 (en) | 2011-12-22 | 2016-03-01 | Longitude Enterprise Flash S.A.R.L. | Systems, methods, and interfaces for vector input/output operations |
US9767032B2 (en) | 2012-01-12 | 2017-09-19 | Sandisk Technologies Llc | Systems and methods for cache endurance |
US9251086B2 (en) | 2012-01-24 | 2016-02-02 | SanDisk Technologies, Inc. | Apparatus, system, and method for managing a cache |
US9116812B2 (en) | 2012-01-27 | 2015-08-25 | Intelligent Intellectual Property Holdings 2 Llc | Systems and methods for a de-duplication cache |
WO2013159337A1 (zh) * | 2012-04-27 | 2013-10-31 | 华为技术有限公司 | 存储控制设备、数据归档存储系统和数据存取方法 |
US10339056B2 (en) | 2012-07-03 | 2019-07-02 | Sandisk Technologies Llc | Systems, methods and apparatus for cache transfers |
US9612966B2 (en) | 2012-07-03 | 2017-04-04 | Sandisk Technologies Llc | Systems, methods and apparatus for a virtual machine cache |
US20140052897A1 (en) * | 2012-08-17 | 2014-02-20 | Seagate Technology Llc | Dynamic formation of garbage collection units in a memory |
US10346095B2 (en) | 2012-08-31 | 2019-07-09 | Sandisk Technologies, Llc | Systems, methods, and interfaces for adaptive cache persistence |
US10282286B2 (en) * | 2012-09-14 | 2019-05-07 | Micron Technology, Inc. | Address mapping using a data unit type that is variable |
US10509776B2 (en) | 2012-09-24 | 2019-12-17 | Sandisk Technologies Llc | Time sequence data management |
US10318495B2 (en) | 2012-09-24 | 2019-06-11 | Sandisk Technologies Llc | Snapshots for a non-volatile device |
US8924785B2 (en) * | 2012-09-27 | 2014-12-30 | Apple Inc. | Power shutdown prediction for non-volatile storage devices |
US9569113B2 (en) * | 2012-10-11 | 2017-02-14 | SK Hynix Inc. | Data storage device and operating method thereof |
US9734911B2 (en) | 2012-12-31 | 2017-08-15 | Sandisk Technologies Llc | Method and system for asynchronous die operations in a non-volatile memory |
US9348746B2 (en) | 2012-12-31 | 2016-05-24 | Sandisk Technologies | Method and system for managing block reclaim operations in a multi-layer memory |
US9465731B2 (en) | 2012-12-31 | 2016-10-11 | Sandisk Technologies Llc | Multi-layer non-volatile memory system having multiple partitions in a layer |
US9336133B2 (en) | 2012-12-31 | 2016-05-10 | Sandisk Technologies Inc. | Method and system for managing program cycles including maintenance programming operations in a multi-layer memory |
US9734050B2 (en) * | 2012-12-31 | 2017-08-15 | Sandisk Technologies Llc | Method and system for managing background operations in a multi-layer memory |
US9223693B2 (en) | 2012-12-31 | 2015-12-29 | Sandisk Technologies Inc. | Memory system having an unequal number of memory die on different control channels |
US9329990B2 (en) * | 2013-01-11 | 2016-05-03 | Micron Technology, Inc. | Host controlled enablement of automatic background operations in a memory device |
US9652376B2 (en) * | 2013-01-28 | 2017-05-16 | Radian Memory Systems, Inc. | Cooperative flash memory control |
US10445229B1 (en) * | 2013-01-28 | 2019-10-15 | Radian Memory Systems, Inc. | Memory controller with at least one address segment defined for which data is striped across flash memory dies, with a common address offset being used to obtain physical addresses for the data in each of the dies |
US9842053B2 (en) | 2013-03-15 | 2017-12-12 | Sandisk Technologies Llc | Systems and methods for persistent cache logging |
TWI506430B (zh) * | 2013-03-20 | 2015-11-01 | Phison Electronics Corp | 映射資訊記錄方法、記憶體控制器與記憶體儲存裝置 |
US10558561B2 (en) | 2013-04-16 | 2020-02-11 | Sandisk Technologies Llc | Systems and methods for storage metadata management |
US10102144B2 (en) | 2013-04-16 | 2018-10-16 | Sandisk Technologies Llc | Systems, methods and interfaces for data virtualization |
US9842128B2 (en) | 2013-08-01 | 2017-12-12 | Sandisk Technologies Llc | Systems and methods for atomic storage operations |
US9535628B2 (en) | 2013-10-10 | 2017-01-03 | Apple Inc. | Memory system with shared file system |
CN104572681B (zh) * | 2013-10-17 | 2018-06-22 | 北京同方微电子有限公司 | 一种基于注册表的智能卡文件管理系统及其管理方法 |
US10019352B2 (en) | 2013-10-18 | 2018-07-10 | Sandisk Technologies Llc | Systems and methods for adaptive reserve storage |
US10019320B2 (en) | 2013-10-18 | 2018-07-10 | Sandisk Technologies Llc | Systems and methods for distributed atomic storage operations |
US10073630B2 (en) | 2013-11-08 | 2018-09-11 | Sandisk Technologies Llc | Systems and methods for log coordination |
TWI554944B (zh) * | 2014-06-20 | 2016-10-21 | 慧榮科技股份有限公司 | 快閃記憶體控制裝置、快閃記憶體控制系統以及快閃記憶體控制方法 |
US9971522B2 (en) | 2014-07-21 | 2018-05-15 | Toshiba Memory Corporation | Memory system and method |
US9690823B2 (en) * | 2014-09-25 | 2017-06-27 | Dropbox, Inc. | Synchronizing copies of an extent in an append-only storage system |
US9772783B2 (en) * | 2014-09-25 | 2017-09-26 | Dropbox, Inc. | Constructing an index to facilitate accessing a closed extent in an append-only storage system |
US9720607B2 (en) * | 2014-09-25 | 2017-08-01 | Dropbox, Inc. | Append-only storage system supporting open and closed extents |
US9946607B2 (en) | 2015-03-04 | 2018-04-17 | Sandisk Technologies Llc | Systems and methods for storage error management |
TWI553476B (zh) * | 2015-03-05 | 2016-10-11 | 光寶電子(廣州)有限公司 | 區域描述元管理方法及其電子裝置 |
US10009438B2 (en) | 2015-05-20 | 2018-06-26 | Sandisk Technologies Llc | Transaction log acceleration |
DE102015209486A1 (de) * | 2015-05-22 | 2016-11-24 | Robert Bosch Gmbh | FIFO Speicher mit im Betrieb veränderbarem Speicherbereich |
GB2539429B (en) * | 2015-06-16 | 2017-09-06 | Advanced Risc Mach Ltd | Address translation |
US10120613B2 (en) | 2015-10-30 | 2018-11-06 | Sandisk Technologies Llc | System and method for rescheduling host and maintenance operations in a non-volatile memory |
US10133490B2 (en) | 2015-10-30 | 2018-11-20 | Sandisk Technologies Llc | System and method for managing extended maintenance scheduling in a non-volatile memory |
US9778855B2 (en) | 2015-10-30 | 2017-10-03 | Sandisk Technologies Llc | System and method for precision interleaving of data writes in a non-volatile memory |
US10042553B2 (en) | 2015-10-30 | 2018-08-07 | Sandisk Technologies Llc | Method and system for programming a multi-layer non-volatile memory having a single fold data path |
CN105550345B (zh) * | 2015-12-25 | 2019-03-26 | 百度在线网络技术(北京)有限公司 | 文件操作方法和装置 |
EP3754508B1 (en) * | 2015-12-30 | 2023-03-22 | Huawei Technologies Co., Ltd. | Access request processing method and apparatus, and computer system |
CN108431783B (zh) | 2015-12-30 | 2020-09-18 | 华为技术有限公司 | 访问请求处理方法、装置及计算机系统 |
US9823854B2 (en) * | 2016-03-18 | 2017-11-21 | Qualcomm Incorporated | Priority-based access of compressed memory lines in memory in a processor-based system |
KR102611638B1 (ko) * | 2016-09-27 | 2023-12-08 | 삼성전자주식회사 | 스토리지 장치의 동작 방법 및 스토리지 장치를 포함하는 데이터 저장 시스템 |
CN107122129A (zh) * | 2017-03-20 | 2017-09-01 | 北京握奇智能科技有限公司 | 一种延长可擦写芯片寿命的方法和装置 |
KR20180109139A (ko) * | 2017-03-27 | 2018-10-08 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 메모리 시스템의 동작방법 |
TWI629590B (zh) * | 2017-04-14 | 2018-07-11 | 群聯電子股份有限公司 | 記憶體管理方法、記憶體控制電路單元及記憶體儲存裝置 |
CN109697017B (zh) * | 2017-10-20 | 2022-03-15 | 上海宝存信息科技有限公司 | 数据储存装置以及非挥发式存储器操作方法 |
US11537513B2 (en) * | 2017-12-11 | 2022-12-27 | SK Hynix Inc. | Apparatus and method for operating garbage collection using host idle |
CN108763101B (zh) * | 2018-05-30 | 2021-11-09 | 郑州云海信息技术有限公司 | 一种数据的搬运方法及系统 |
CN108959517B (zh) * | 2018-06-28 | 2021-06-01 | 河南思维轨道交通技术研究院有限公司 | 文件管理方法、装置及电子设备 |
CN109710191B (zh) * | 2018-12-27 | 2022-04-26 | 新华三技术有限公司 | 一种数据存储方法和装置 |
US10901908B2 (en) | 2019-01-16 | 2021-01-26 | International Business Machines Corporation | Storing data into a memory |
CN111258956B (zh) * | 2019-03-22 | 2023-11-24 | 深圳市远行科技股份有限公司 | 一种面向远端海量数据文件预读的方法及设备 |
TWI697778B (zh) * | 2019-06-17 | 2020-07-01 | 慧榮科技股份有限公司 | 資料儲存裝置與資料處理方法 |
US11099758B2 (en) * | 2019-07-16 | 2021-08-24 | Facebook Technologies, Llc | Memory management of computing devices |
KR20210027563A (ko) * | 2019-08-28 | 2021-03-11 | 에스케이하이닉스 주식회사 | 저장 장치 및 그 동작 방법 |
US11301132B2 (en) * | 2019-08-30 | 2022-04-12 | Micron Technology, Inc. | Scheduling media management operations based on provided host system usage requirements |
US10922012B1 (en) | 2019-09-03 | 2021-02-16 | Dropbox, Inc. | Fair data scrubbing in a data storage system |
CN111400201B (zh) * | 2020-03-19 | 2022-08-16 | 合肥兆芯电子有限公司 | 快闪存储器的数据整理方法、存储装置及控制电路单元 |
US11704035B2 (en) | 2020-03-30 | 2023-07-18 | Pure Storage, Inc. | Unified storage on block containers |
KR20220052152A (ko) * | 2020-10-20 | 2022-04-27 | 에스케이하이닉스 주식회사 | 스토리지 장치 및 그 동작 방법 |
KR20220058224A (ko) * | 2020-10-30 | 2022-05-09 | 에스케이하이닉스 주식회사 | 메모리 시스템 및 이에 포함된 메모리 컨트롤러의 동작 방법 |
US11841794B2 (en) * | 2020-12-16 | 2023-12-12 | Micron Technology, Inc. | Memory sub-system write sequence track |
CN113885787B (zh) * | 2021-06-08 | 2022-12-13 | 荣耀终端有限公司 | 一种存储器管理方法及电子设备 |
US20230281121A1 (en) * | 2022-03-01 | 2023-09-07 | International Business Machines Corporation | Increased garbage collection granularity for non-volatile memory |
Family Cites Families (134)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4800520A (en) * | 1985-10-29 | 1989-01-24 | Kabushiki Kaisha Toshiba | Portable electronic device with garbage collection function |
US4802117A (en) * | 1985-12-16 | 1989-01-31 | Pitney Bowes Inc. | Method of preserving data storage in a postal meter |
JP3015377B2 (ja) * | 1988-08-26 | 2000-03-06 | 株式会社東芝 | Icカード |
DE69033438T2 (de) * | 1989-04-13 | 2000-07-06 | Sandisk Corp | Austausch von fehlerhaften Speicherzellen einer EEprommatritze |
GB2251324B (en) * | 1990-12-31 | 1995-05-10 | Intel Corp | File structure for a non-volatile semiconductor memory |
US6256642B1 (en) * | 1992-01-29 | 2001-07-03 | Microsoft Corporation | Method and system for file system management using a flash-erasable, programmable, read-only memory |
JPH05233426A (ja) * | 1992-02-20 | 1993-09-10 | Fujitsu Ltd | フラッシュ・メモリ使用方法 |
US5628014A (en) * | 1992-03-20 | 1997-05-06 | Paranode, Inc. | Methods and apparatus for node caching at the file level |
JP3017892B2 (ja) * | 1992-09-30 | 2000-03-13 | 株式会社東芝 | ファイル管理装置 |
US5404485A (en) * | 1993-03-08 | 1995-04-04 | M-Systems Flash Disk Pioneers Ltd. | Flash file system |
US5388083A (en) * | 1993-03-26 | 1995-02-07 | Cirrus Logic, Inc. | Flash memory mass storage architecture |
KR970008188B1 (ko) * | 1993-04-08 | 1997-05-21 | 가부시끼가이샤 히다찌세이사꾸쇼 | 플래시메모리의 제어방법 및 그것을 사용한 정보처리장치 |
US5619690A (en) * | 1993-06-21 | 1997-04-08 | Hitachi, Ltd. | Computer system including a computer which requests an access to a logical address in a secondary storage system with specification of a local address in the secondary storage system |
US5555204A (en) * | 1993-06-29 | 1996-09-10 | Kabushiki Kaisha Toshiba | Non-volatile semiconductor memory device |
US5353256A (en) | 1993-06-30 | 1994-10-04 | Intel Corporation | Block specific status information in a memory device |
KR0169267B1 (ko) * | 1993-09-21 | 1999-02-01 | 사토 후미오 | 불휘발성 반도체 기억장치 |
US6341293B1 (en) * | 1994-07-13 | 2002-01-22 | Object Technology Licensing Corp | Real-time computer “garbage collector” |
US5809558A (en) * | 1994-09-29 | 1998-09-15 | Intel Corporation | Method and data storage system for storing data in blocks without file reallocation before erasure |
JP2669365B2 (ja) * | 1994-11-24 | 1997-10-27 | 日本電気株式会社 | 書換え可能なromファイル装置 |
GB2291991A (en) * | 1995-09-27 | 1996-02-07 | Memory Corp Plc | Disk drive emulation with a block-erasable memory |
GB2291990A (en) | 1995-09-27 | 1996-02-07 | Memory Corp Plc | Flash-memory management system |
US5933847A (en) * | 1995-09-28 | 1999-08-03 | Canon Kabushiki Kaisha | Selecting erase method based on type of power supply for flash EEPROM |
US6014724A (en) * | 1995-10-27 | 2000-01-11 | Scm Microsystems (U.S.) Inc. | Flash translation layer block indication map revision system and method |
US5867641A (en) * | 1995-10-27 | 1999-02-02 | Scm Microsystems (U.S.) Inc. | Flash translation layer cleanup system and method |
US5987478A (en) | 1995-10-31 | 1999-11-16 | Intel Corporation | Virtual small block file manager for flash memory array |
US5799168A (en) * | 1996-01-05 | 1998-08-25 | M-Systems Flash Disk Pioneers Ltd. | Standardized flash controller |
US5903495A (en) * | 1996-03-18 | 1999-05-11 | Kabushiki Kaisha Toshiba | Semiconductor device and memory system |
GB9606927D0 (en) | 1996-04-02 | 1996-06-05 | Memory Corp Plc | Data storage devices |
US5896393A (en) * | 1996-05-23 | 1999-04-20 | Advanced Micro Devices, Inc. | Simplified file management scheme for flash memory |
US5978893A (en) | 1996-06-19 | 1999-11-02 | Apple Computer, Inc. | Method and system for memory management |
US5996047A (en) | 1996-07-01 | 1999-11-30 | Sun Microsystems, Inc. | Method and apparatus for caching file control information corresponding to a second file block in a first file block |
FR2752072B1 (fr) * | 1996-08-01 | 1999-01-29 | Solaic Sa | Carte a circuit integre comportant des fichiers classes selon une arborescence |
DE19633648A1 (de) * | 1996-08-21 | 1998-02-26 | Grundig Ag | Verfahren und Schaltungsanordnung zur Speicherung von Diktaten bei einem digitalen Diktiergerät |
JPH1069420A (ja) * | 1996-08-29 | 1998-03-10 | Sony Corp | 情報記録装置、情報記録再生装置、情報記録方法および情報再生方法 |
US5907854A (en) * | 1996-09-27 | 1999-05-25 | Alcatel Usa Sourcing, L.P. | Flash memory file system for writing data files without rewriting an entire volume |
US5953538A (en) * | 1996-11-12 | 1999-09-14 | Digital Equipment Corporation | Method and apparatus providing DMA transfers between devices coupled to different host bus bridges |
US6014727A (en) * | 1996-12-23 | 2000-01-11 | Apple Computer, Inc. | Method and system for buffering messages in an efficient but largely undivided manner |
US6279069B1 (en) * | 1996-12-26 | 2001-08-21 | Intel Corporation | Interface for flash EEPROM memory arrays |
FR2759795B1 (fr) | 1997-02-14 | 1999-05-07 | Francois Charles Oberthur Fidu | Procede de stockage de donnees dans une memoire reinscriptible de carte a puce |
US6088759A (en) * | 1997-04-06 | 2000-07-11 | Intel Corporation | Method of performing reliable updates in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture |
US5832493A (en) * | 1997-04-24 | 1998-11-03 | Trimble Navigation Limited | Flash file management system |
US5937425A (en) * | 1997-10-16 | 1999-08-10 | M-Systems Flash Disk Pioneers Ltd. | Flash file system optimized for page-mode flash technologies |
US6021415A (en) * | 1997-10-29 | 2000-02-01 | International Business Machines Corporation | Storage management system with file aggregation and space reclamation within aggregated files |
US5928347A (en) * | 1997-11-18 | 1999-07-27 | Shuttle Technology Group Ltd. | Universal memory card interface apparatus |
US6493811B1 (en) | 1998-01-26 | 2002-12-10 | Computer Associated Think, Inc. | Intelligent controller accessed through addressable virtual space |
US6226728B1 (en) * | 1998-04-21 | 2001-05-01 | Intel Corporation | Dynamic allocation for efficient management of variable sized data within a nonvolatile memory |
US6038636A (en) * | 1998-04-27 | 2000-03-14 | Lexmark International, Inc. | Method and apparatus for reclaiming and defragmenting a flash memory device |
US6223271B1 (en) * | 1998-07-15 | 2001-04-24 | Compaq Computer Corp. | System and method for detecting system memory size using ROM based paging tables |
JP2000148546A (ja) * | 1998-11-10 | 2000-05-30 | Nec Corp | データ入出力装置およびデータ入出力方法、並びに記録媒体 |
US6490649B2 (en) | 1998-11-10 | 2002-12-03 | Lexar Media, Inc. | Memory device |
US6256690B1 (en) * | 1999-01-15 | 2001-07-03 | Todd Carper | System and method for facilitating multiple applications on a smart card |
US6480935B1 (en) | 1999-01-15 | 2002-11-12 | Todd Carper | Smart card memory management system and method |
US6145069A (en) | 1999-01-29 | 2000-11-07 | Interactive Silicon, Inc. | Parallel decompression and compression system and method for improving storage density and access speed for non-volatile memory and embedded memory devices |
KR100704998B1 (ko) * | 1999-02-26 | 2007-04-09 | 소니 가부시끼 가이샤 | 기록방법, 관리방법 및 기록장치 |
JP4779183B2 (ja) * | 1999-03-26 | 2011-09-28 | ソニー株式会社 | 再生装置および再生方法 |
US6148354A (en) | 1999-04-05 | 2000-11-14 | M-Systems Flash Disk Pioneers Ltd. | Architecture for a universal serial bus-based PC flash disk |
US6467015B1 (en) | 1999-04-15 | 2002-10-15 | Dell Products, L.P. | High speed bus interface for non-volatile integrated circuit memory supporting continuous transfer |
US6535949B1 (en) * | 1999-04-19 | 2003-03-18 | Research In Motion Limited | Portable electronic device having a log-structured file system in flash memory |
JP3524428B2 (ja) | 1999-04-20 | 2004-05-10 | 東京エレクトロンデバイス株式会社 | 記憶装置、記憶システム、メモリ管理方法及び記録媒体 |
US6547150B1 (en) * | 1999-05-11 | 2003-04-15 | Microsoft Corporation | Smart card application development system and method |
US6504846B1 (en) * | 1999-05-21 | 2003-01-07 | Advanced Micro Devices, Inc. | Method and apparatus for reclaiming buffers using a single buffer bit |
US6389433B1 (en) * | 1999-07-16 | 2002-05-14 | Microsoft Corporation | Method and system for automatically merging files into a single instance store |
JP2001030531A (ja) * | 1999-07-26 | 2001-02-06 | Alps Electric Co Ltd | 版下フィルムの印刷方法および版下印刷用プリンタ |
KR100684061B1 (ko) * | 1999-07-28 | 2007-02-16 | 소니 가부시끼 가이샤 | 기록 시스템, 데이터 기록 장치, 메모리 장치 및 데이터기록 방법 |
JP3863330B2 (ja) * | 1999-09-28 | 2006-12-27 | 株式会社東芝 | 不揮発性半導体メモリ |
ATE247296T1 (de) | 1999-10-25 | 2003-08-15 | Sun Microsystems Inc | Speichersystem mit unterstützung von dateistufenzugriffen und blockstufenzugriffen |
US6426893B1 (en) * | 2000-02-17 | 2002-07-30 | Sandisk Corporation | Flash eeprom system with simultaneous multiple data sector programming and storage of physical block characteristics in other designated blocks |
US6567307B1 (en) * | 2000-07-21 | 2003-05-20 | Lexar Media, Inc. | Block management for mass storage |
US20020078002A1 (en) * | 2000-08-25 | 2002-06-20 | Bottomley Thomas Mark Walter | Memory garbage collection method and apparatus |
JP3726663B2 (ja) * | 2000-09-07 | 2005-12-14 | 日産自動車株式会社 | 電子制御装置の制御データ記憶装置 |
US6865650B1 (en) | 2000-09-29 | 2005-03-08 | Emc Corporation | System and method for hierarchical data storage |
US6834331B1 (en) | 2000-10-24 | 2004-12-21 | Starfish Software, Inc. | System and method for improving flash memory data integrity |
US6684289B1 (en) * | 2000-11-22 | 2004-01-27 | Sandisk Corporation | Techniques for operating non-volatile memory systems with data sectors having different sizes than the sizes of the pages and/or blocks of the memory |
US6722955B2 (en) * | 2001-01-10 | 2004-04-20 | 3M Innovative Properties Company | Buckup plate assembly for grinding system |
US6763424B2 (en) * | 2001-01-19 | 2004-07-13 | Sandisk Corporation | Partial block data programming and reading operations in a non-volatile memory |
JP3631463B2 (ja) * | 2001-12-27 | 2005-03-23 | 株式会社東芝 | 不揮発性半導体記憶装置 |
JP2002251310A (ja) | 2001-02-21 | 2002-09-06 | Ricoh Co Ltd | フラッシュメモリのファイルシステム作成方式 |
US6779063B2 (en) * | 2001-04-09 | 2004-08-17 | Hitachi, Ltd. | Direct access storage system having plural interfaces which permit receipt of block and file I/O requests |
KR100389867B1 (ko) | 2001-06-04 | 2003-07-04 | 삼성전자주식회사 | 플래시 메모리 관리방법 |
US6522580B2 (en) * | 2001-06-27 | 2003-02-18 | Sandisk Corporation | Operating techniques for reducing effects of coupling between storage elements of a non-volatile memory operated in multiple data states |
GB0116116D0 (en) * | 2001-06-30 | 2001-08-22 | Koninkl Philips Electronics Nv | Receiver apparatus and method |
US7146524B2 (en) * | 2001-08-03 | 2006-12-05 | Isilon Systems, Inc. | Systems and methods for providing a distributed file system incorporating a virtual hot spare |
US6456528B1 (en) * | 2001-09-17 | 2002-09-24 | Sandisk Corporation | Selective operation of a multi-state non-volatile memory system in a binary mode |
US7251747B1 (en) * | 2001-09-20 | 2007-07-31 | Ncr Corp. | Method and system for transferring data using a volatile data transfer mechanism such as a pipe |
GB0123412D0 (en) * | 2001-09-28 | 2001-11-21 | Memquest Ltd | Memory system sectors |
US6678785B2 (en) * | 2001-09-28 | 2004-01-13 | M-Systems Flash Disk Pioneers Ltd. | Flash management system using only sequential write |
US6823417B2 (en) | 2001-10-01 | 2004-11-23 | Hewlett-Packard Development Company, L.P. | Memory controller for memory card manages file allocation table |
JP3641230B2 (ja) * | 2001-10-22 | 2005-04-20 | 株式会社東芝 | メモリカードを制御するための装置および方法 |
US6925007B2 (en) * | 2001-10-31 | 2005-08-02 | Sandisk Corporation | Multi-state non-volatile integrated circuit memory systems that employ dielectric storage elements |
US6883114B2 (en) * | 2001-11-08 | 2005-04-19 | M-Systems Flash Disk Pioneers Ltd. | Block device driver enabling a ruggedized file system |
US6668336B2 (en) | 2001-11-08 | 2003-12-23 | M-Systems Flash Disk Pioneers Ltd. | Ruggedized block device driver |
US6542407B1 (en) * | 2002-01-18 | 2003-04-01 | Sandisk Corporation | Techniques of recovering data from memory cells affected by field coupling with adjacent memory cells |
AU2003213113A1 (en) * | 2002-02-21 | 2003-09-09 | Precise Software Solutions, Inc. | System and method for analyzing input/output activity on local attached storage |
US6771536B2 (en) * | 2002-02-27 | 2004-08-03 | Sandisk Corporation | Operating techniques for reducing program and read disturbs of a non-volatile memory |
DE60210416T2 (de) * | 2002-02-28 | 2006-09-07 | Matsushita Electric Industrial Co., Ltd., Kadoma | Speicherkarte |
US6766432B2 (en) * | 2002-05-24 | 2004-07-20 | Sun Microsystems, Inc. | Memory management system supporting object deletion in non-volatile memory |
US6895464B2 (en) * | 2002-06-03 | 2005-05-17 | Honeywell International Inc. | Flash memory management system and method utilizing multiple block list windows |
US6865659B2 (en) | 2002-06-07 | 2005-03-08 | Sun Microsystems, Inc. | Using short references to access program elements in a large address space |
KR100453053B1 (ko) | 2002-06-10 | 2004-10-15 | 삼성전자주식회사 | 플래쉬 메모리용 파일 시스템 |
TWI246064B (en) * | 2002-07-29 | 2005-12-21 | Milsys Ltd | Data storage and processing device, electronic appliance, electronic system and method of operating an appliance that responds to a plurality of commands |
DE10234971B4 (de) | 2002-07-31 | 2006-08-10 | Giesecke & Devrient Gmbh | Verfahren und Datenträger zum Erzeugen und Korrigieren von Programmcode |
US7249352B2 (en) * | 2002-08-22 | 2007-07-24 | International Business Machines Corporation | Apparatus and method for removing elements from a linked list |
US6895486B2 (en) * | 2002-08-29 | 2005-05-17 | Micron Technology, Inc. | Linear object management for a range of flash memory |
US6970969B2 (en) * | 2002-08-29 | 2005-11-29 | Micron Technology, Inc. | Multiple segment data object management |
US6781877B2 (en) * | 2002-09-06 | 2004-08-24 | Sandisk Corporation | Techniques for reducing effects of coupling between storage elements of adjacent rows of memory cells |
US7526599B2 (en) * | 2002-10-28 | 2009-04-28 | Sandisk Corporation | Method and apparatus for effectively enabling an out of sequence write process within a non-volatile memory system |
US7039788B1 (en) | 2002-10-28 | 2006-05-02 | Sandisk Corporation | Method and apparatus for splitting a logical block |
CN1260642C (zh) | 2002-11-18 | 2006-06-21 | 深圳市朗科科技有限公司 | 一种向移动存储装置发送命令和数据的方法 |
US7433712B2 (en) * | 2003-02-06 | 2008-10-07 | Modu Ltd. | Multi-access solid state memory devices and a telephone utilizing such |
KR100526178B1 (ko) * | 2003-03-31 | 2005-11-03 | 삼성전자주식회사 | 플래시 메모리 액세스 장치 및 방법 |
US6865122B2 (en) | 2003-04-11 | 2005-03-08 | Intel Corporation | Reclaiming blocks in a block-alterable memory |
US7437557B2 (en) * | 2003-06-03 | 2008-10-14 | Lg Electronics Inc. | Garbage collection system and method for a mobile communication terminal |
US6906961B2 (en) * | 2003-06-24 | 2005-06-14 | Micron Technology, Inc. | Erase block data splitting |
JP2005122439A (ja) | 2003-10-16 | 2005-05-12 | Sharp Corp | デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法 |
US7139864B2 (en) * | 2003-12-30 | 2006-11-21 | Sandisk Corporation | Non-volatile memory and method with block management system |
US7433993B2 (en) * | 2003-12-30 | 2008-10-07 | San Disk Corportion | Adaptive metablocks |
US7383375B2 (en) * | 2003-12-30 | 2008-06-03 | Sandisk Corporation | Data run programming |
US8504798B2 (en) * | 2003-12-30 | 2013-08-06 | Sandisk Technologies Inc. | Management of non-volatile memory systems having large erase blocks |
US20050144363A1 (en) * | 2003-12-30 | 2005-06-30 | Sinclair Alan W. | Data boundary management |
US20060004951A1 (en) * | 2004-06-30 | 2006-01-05 | Rudelic John C | Method and apparatus to alter code in a memory |
US8607016B2 (en) * | 2004-07-21 | 2013-12-10 | Sandisk Technologies Inc. | FAT analysis for optimized sequential cluster management |
US7395384B2 (en) * | 2004-07-21 | 2008-07-01 | Sandisk Corproation | Method and apparatus for maintaining data on non-volatile memory systems |
US8375146B2 (en) * | 2004-08-09 | 2013-02-12 | SanDisk Technologies, Inc. | Ring bus structure and its use in flash memory systems |
US7366826B2 (en) * | 2004-12-16 | 2008-04-29 | Sandisk Corporation | Non-volatile memory and method with multi-stream update tracking |
US7412560B2 (en) * | 2004-12-16 | 2008-08-12 | Sandisk Corporation | Non-volatile memory and method with multi-stream updating |
US7386655B2 (en) * | 2004-12-16 | 2008-06-10 | Sandisk Corporation | Non-volatile memory and method with improved indexing for scratch pad and update blocks |
US7315917B2 (en) * | 2005-01-20 | 2008-01-01 | Sandisk Corporation | Scheduling of housekeeping operations in flash memory systems |
US20060184719A1 (en) | 2005-02-16 | 2006-08-17 | Sinclair Alan W | Direct data file storage implementation techniques in flash memories |
US20060184718A1 (en) * | 2005-02-16 | 2006-08-17 | Sinclair Alan W | Direct file data programming and deletion in flash memories |
US7877539B2 (en) * | 2005-02-16 | 2011-01-25 | Sandisk Corporation | Direct data file storage in flash memories |
US7480766B2 (en) * | 2005-08-03 | 2009-01-20 | Sandisk Corporation | Interfacing systems operating through a logical address space and on a direct data file basis |
US7409489B2 (en) * | 2005-08-03 | 2008-08-05 | Sandisk Corporation | Scheduling of reclaim operations in non-volatile memory |
US7558906B2 (en) * | 2005-08-03 | 2009-07-07 | Sandisk Corporation | Methods of managing blocks in nonvolatile memory |
US7669003B2 (en) * | 2005-08-03 | 2010-02-23 | Sandisk Corporation | Reprogrammable non-volatile memory systems with indexing of directly stored data files |
-
2005
- 2005-02-16 US US11/060,248 patent/US20060184719A1/en not_active Abandoned
-
2006
- 2006-01-26 US US11/342,168 patent/US20060184722A1/en not_active Abandoned
- 2006-02-08 CN CN2006800089220A patent/CN101147119B/zh not_active Expired - Fee Related
- 2006-02-08 EP EP20060720547 patent/EP1875334A2/en not_active Ceased
- 2006-02-08 KR KR1020077018767A patent/KR20080000557A/ko not_active Application Discontinuation
- 2006-02-08 WO PCT/US2006/004555 patent/WO2006088719A2/en active Application Filing
- 2006-02-08 JP JP2007556204A patent/JP2008530708A/ja active Pending
- 2006-02-16 TW TW095105280A patent/TW200639633A/zh unknown
-
2007
- 2007-08-15 IL IL185307A patent/IL185307A0/en unknown
-
2010
- 2010-05-05 US US12/774,109 patent/US7984233B2/en active Active
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2008016081A1 (ja) * | 2006-08-04 | 2009-12-24 | パナソニック株式会社 | メモリコントローラ、不揮発性記憶装置、アクセス装置、及び不揮発性記憶システム |
KR101363422B1 (ko) | 2012-10-04 | 2014-02-14 | 주식회사 디에이아이오 | 비휘발성 메모리 시스템 |
JP2019174941A (ja) * | 2018-03-27 | 2019-10-10 | 東芝メモリ株式会社 | ストレージ装置、コンピュータシステムおよびストレージ装置の動作方法 |
WO2021015174A1 (ja) * | 2019-07-25 | 2021-01-28 | 株式会社ソニー・インタラクティブエンタテインメント | ストレージ管理装置、ストレージ管理方法およびプログラム |
JPWO2021015174A1 (ja) * | 2019-07-25 | 2021-12-23 | 株式会社ソニー・インタラクティブエンタテインメント | ストレージ管理装置、ストレージ管理方法およびプログラム |
JP7314276B2 (ja) | 2019-07-25 | 2023-07-25 | 株式会社ソニー・インタラクティブエンタテインメント | ストレージ管理装置、ストレージ管理方法およびプログラム |
US11954328B2 (en) | 2019-07-25 | 2024-04-09 | Sony Interactive Entertainment Inc. | Storage management device, storage management method, and program |
Also Published As
Publication number | Publication date |
---|---|
US7984233B2 (en) | 2011-07-19 |
WO2006088719A2 (en) | 2006-08-24 |
CN101147119A (zh) | 2008-03-19 |
TW200639633A (en) | 2006-11-16 |
US20060184722A1 (en) | 2006-08-17 |
KR20080000557A (ko) | 2008-01-02 |
US20060184719A1 (en) | 2006-08-17 |
US20100217926A1 (en) | 2010-08-26 |
CN101147119B (zh) | 2012-04-25 |
EP1875334A2 (en) | 2008-01-09 |
WO2006088719A3 (en) | 2007-02-15 |
IL185307A0 (en) | 2008-02-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7984233B2 (en) | Direct data file storage implementation techniques in flash memories | |
US7877539B2 (en) | Direct data file storage in flash memories | |
US8214583B2 (en) | Direct file data programming and deletion in flash memories | |
US8055832B2 (en) | Management of memory blocks that directly store data files | |
US7877540B2 (en) | Logically-addressed file storage methods | |
JP4533956B2 (ja) | フラッシュメモリシステムのデータ記憶容量の解放 | |
US20070156998A1 (en) | Methods for memory allocation in non-volatile memories with a directly mapped file storage system | |
US20070143560A1 (en) | Non-volatile memories with memory allocation for a directly mapped file storage system | |
US20070143378A1 (en) | Non-volatile memories with adaptive file handling in a directly mapped file storage system | |
US20070143566A1 (en) | Non-volatile memories with data alignment in a directly mapped file storage system | |
US20070143561A1 (en) | Methods for adaptive file data handling in non-volatile memories with a directly mapped file storage system | |
US20070143567A1 (en) | Methods for data alignment in non-volatile memories with a directly mapped file storage system | |
US20070136553A1 (en) | Logically-addressed file storage systems | |
WO2007081638A2 (en) | Non-volatile memories and methods with adaptive file handling in a directly mapped file storage system | |
WO2007073538A2 (en) | Non-volatile memories and methods with data alignment in a directly mapped file storage system | |
KR20080038368A (ko) | 데이터 파일을 직접 저장하는 재프로그램가능 비휘발성메모리에 파일 데이터의 인덱싱 | |
WO2007073536A2 (en) | Non-volatile memories and methods with memory allocation for a directly mapped file storage system |