JP2008530709A - フラッシュメモリにおける直接ファイルデータプログラミングおよび削除 - Google Patents

フラッシュメモリにおける直接ファイルデータプログラミングおよび削除 Download PDF

Info

Publication number
JP2008530709A
JP2008530709A JP2007556210A JP2007556210A JP2008530709A JP 2008530709 A JP2008530709 A JP 2008530709A JP 2007556210 A JP2007556210 A JP 2007556210A JP 2007556210 A JP2007556210 A JP 2007556210A JP 2008530709 A JP2008530709 A JP 2008530709A
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
Application number
JP2007556210A
Other languages
English (en)
Inventor
ウェルシュ シンクレア,アラン
ジョン スミス,ピーター
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SanDisk Corp
Original Assignee
SanDisk Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by SanDisk Corp filed Critical SanDisk Corp
Publication of JP2008530709A publication Critical patent/JP2008530709A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/0223User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023Free address space management
    • G06F12/0238Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10Program control for peripheral devices
    • G06F13/12Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608Saving storage space on storage systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0652Erasing, e.g. deleting, data cleaning, moving of data to a wastebasket
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input 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/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0673Single storage device
    • G06F3/0679Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20Employing a main memory using a specific memory technology
    • G06F2212/202Non-volatile memory
    • G06F2212/2022Flash memory
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72Details relating to flash memory management
    • G06F2212/7205Cleaning, compaction, garbage collection, erase control
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11CSTATIC STORES
    • G11C16/00Erasable programmable read-only memories
    • G11C16/02Erasable programmable read-only memories electrically programmable
    • G11C16/06Auxiliary circuits, e.g. for writing into memory
    • G11C16/10Programming or data input circuits
    • G11C16/14Circuits for erasing electrically, e.g. erase voltage switching circuits
    • G11C16/16Circuits for erasing electrically, e.g. erase voltage switching circuits for erasing blocks, e.g. arrays, words, groups

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)
  • Read Only Memory (AREA)
  • Techniques For Improving Reliability Of Storages (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〜図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に関して前述したのと同じメモリシステムで実施することができる。前述したメモリシステムとの主な違いは、メモリシステムがホストシステムと通信する方法である。
このファイルベースのインターフェイスを図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つのデータコマンドの実行は、ホストシステムによる何か他のコマンドの伝送に応答して終了される。
別のデータコマンドは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または追加のブロックをプログラムすることができる。単一ファイルのデータを記憶する複数ブロックまたはメタブロックを物理的または論理的に連続にする必要はない。説明を容易にするため、他に特に指定がなければ、本願明細書で用いられる「ブロック」という用語は、特定のシステムにメタブロックが用いられているかどうかに応じて消去のブロック単位または複数ブロック「メタブロック」のどちらかを意味するものとする。
図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のファイルデータの更新に加えてさらに留意すべきことは、図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つのブロックに記憶できるとしても、個々のブロックのかなりの量の空間が未使用となる。個々のブロック内のページの記憶容量は消去されたままであり、データを記憶するのに利用可能ではあるが、使用されない。
従って、他のブロックがいっぱいになった後、幾つかのメモリセルブロックは、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)。
待ち行列(4)および(5)にリストされた項目の優先順位はほぼ同じであり、従って、逆にすることができる。あるいはまた、設定基準に従って、場合によっては、優先順位の高い待ち行列の1つ以上が空になる前であっても、ファイルおよびコマンドブロックが待ち行列(4)および(5)から選択されるさらに複雑な優先順位システムにすることができる。共通ブロックのガーベッジコレクションを管理する2つの目標がある。一方は、共通ブロック内のデータグループが古くなったときに共通ブロックのガーベッジコレクションによって生じるメモリシステムの正常な動作の中断を最小限にすることである。他方は、ブロックのガーベッジコレクション中、共通ブロックからのデータグループが再配置されるとき、更新の索引付けを最小限にすることである。
共通ブロックのガーベッジコレクション中、ブロック内に残っている共通グループの有効データのすべては、空間を有する共通ブロックの1つに1つずつコピーされる。開かれた共通ブロックに、共通グループがコピーされる空間がない場合、共通グループは、消去プールからブロックに書き込まれ、このブロックを次に共通ブロックとして指定することができる。開かれた共通ブロックの1つは次に一般的に処理の一部として閉じられる。すべてのガーベッジコレクション動作でのように、ファイル索引テーブル(FIT)は、コピーされたデータグループの新たな記憶位置を反映するように更新される。
ガーベッジコレクション待ち行列を不揮発性メモリに記録する必要がある。待ち行列情報を含むページまたはメタページに対する読み出し−変更−書き込み動作を実行して、項目を追加または除去する必要がある。ガーベッジコレクション待ち行列情報を含むページを、専用のブロックまたはメタブロック内に入れることができ、または、ブロックまたはメタブロックを、スワップブロックのような他の種類のページと共有することができる。
メタページのバッファリングおよびプログラミング中のメタページの使用
前述したものは、メモリセルブロックがメタブロックとして互いに結合されているかどうかを問わず、メモリシステムの動作について説明した。ホストとメモリシステムとの間のファイルベースのインターフェイスと、前述した関連のメモリシステム動作とは、メタブロックを用いるメモリシステム内でも、メタブロックを用いないメモリシステム内でも動作する。同時に書き込み、読み出されるデータの量(並列性の度合い)を増大させる傾向は間違いなくあり、その理由は、この並列性の度合いを増大させることがメモリ性能を直接に改善するためである。多数のデータビットで表す個々のメモリセルブロックの有効幅は、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番目のブロックに記憶されていると示されている。テーブルの各項目に各データグループの長さも含めるのが好ましい。
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を最初に参照する。最初のステップ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には、前述した種類の直接ファイル記憶メモリシステム内におけるシステムのメモリブロックまたはメタブロックの様々な個々の状態とこれら状態の遷移とを示す。
左側の列では、ブロック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へ。すなわち、古いブロックは、ガーベッジコレクション中、消去される。
結論
本発明の例示的な実施形態を参照して本発明の様々な態様を説明してきたが、当然のことながら、本発明は、特許請求の範囲の全範囲内においてその権利が保護されるべきであることが理解できよう。
ホストと、現在の実施状況では接続された不揮発性メモリシステムとを示す概要図である。 図1の不揮発性メモリシステムとして用いる例示的なフラッシュメモリシステムを示すブロック図である。 図2のシステムに用いることができるメモリセルアレイの代表的な回路図である。 図2のシステムの物理メモリ編成例を示す。 図4の物理メモリの一部を示す拡大図である。 図4および図5の物理メモリの一部を示すさらなる拡大図である。 ホストと再プログラム可能なメモリシステムとの間の一般的な従来技術の論理アドレスインターフェイスを示す。 ホストと再プログラム可能なメモリシステムとの間の一般的な従来技術の論理アドレスインターフェイスを、図7とは異なるように示す。 本発明によるホストと再プログラム可能なメモリシステムとの間の直接ファイル記憶インターフェイスを示す。 本発明によるホストと再プログラム可能なメモリシステムとの間の直接ファイル記憶インターフェイスを、図9とは異なるように示す。 例示的なメモリシステムの機能的階層を示す。 例示的な一連の直接ファイルインターフェイスコマンドを示す。 例示的な一連の直接ファイルインターフェイスコマンドを示す。 例示的な一連の直接ファイルインターフェイスコマンドを示す。 例示的な一連の直接ファイルインターフェイスコマンドを示す。 例示的な一連の直接ファイルインターフェイスコマンドを示す。 データファイルをメモリに直接書き込む第1の例を示す。 データファイルをメモリに直接書き込む第2の例を示す。 データファイルをメモリに直接書き込む第3の例を示す。 データファイルをメモリに直接書き込む第4の例を示す。 単一データファイルをメモリに直接書き込む一連の書き込みを示す。 単一データファイルをメモリに直接書き込む一連の書き込みを示す。 単一データファイルをメモリに直接書き込む一連の書き込みを示す。 単一データファイルをメモリに直接書き込む一連の書き込みを示す。 単一データファイルをメモリに直接書き込む一連の書き込みを示す。 図14Eに示されているデータファイルにガーベッジコレクションを行った結果を示す。 共通ブロックの一例を示す。 共通データグループを、幾つかの開いた共通ブロックのうちの1つにプログラムすることを示す。 異なるファイルで不揮発性メモリにプログラムされたデータのメタページの幾つかの例を示す。 図14A、図14C、図14Eおよび図15の例からのファイル索引テーブル(FIT)の構造および項目を示す。 例示的なファイル索引付けデータ構造を概念的に示す。 図20のファイルディレクトリのページに対する構造を示す。 図20のファイル索引テーブルのページに対する構造を示す。 図21のファイルディレクトリの代わりとして図20のファイルディレクトリのページに対する構造を示す。 図21および図23のファイルディレクトリの動作を示す。 図22のファイル索引テーブルの動作を示す。 本願明細書で説明されているメモリシステムの一連の動作全体を示すフローチャートである。 図26の「ファイルデータの読み出し」ブロックのフローチャートである。 図26の「ファイルデータのプログラム」ブロックのフローチャートである。 図28のフローチャートに含まれる2つの動作の相対的なタイミングを示す。 図26の「ファイルの削除」ブロックのフローチャートである。 図26の「ガーベッジコレクション」ブロックのフローチャートである。 図31の「共通ブロックガーベッジコレクション」ブロックのフローチャートである。 本願明細書で説明された例示的なメモリシステムの動作中のメモリセルブロックの状態図である。

Claims (16)

  1. ホストシステムと一緒に再プログラム可能な不揮発性メモリシステムを動作する方法であって、前記メモリシステムは、新たなデータが書き込まれる前に消去されるメモリセルのブロックを有し、
    固有のファイル識別子によってアドレス指定されたデータを受信するステップと、
    指定されたデータファイルを前記メモリシステムから削除するコマンドを受信するステップと、
    前記削除するコマンドの結果として古い状態にされたデータを含むメモリセルのブロックを識別するステップと、
    その後、前記識別されたブロックからデータを消去するステップと、
    を含む方法。
  2. 請求項1記載の方法において、
    古いデータを含むものと識別されたメモリセルの少なくとも1つのブロックは、古いデータで満ちる方法。
  3. 請求項1記載の方法において、
    古いデータを含むものと識別されたメモリセルの少なくとも1つのブロックは、少なくとも1つの他のファイルからのデータをも含む方法。
  4. 請求項3記載の方法において、
    少なくとも1つの他のファイルからのデータをも含むものと識別されたメモリセルの前記少なくとも1つのブロックを消去する前に、前記少なくとも1つの他のファイルからの前記データは、別のブロック内にコピーされる方法。
  5. 請求項1記載の方法において、
    前記固有のファイル識別子によってアドレス指定されたデータを受信するステップは、前記識別されたファイル内のオフセットを用いてアドレス指定されたデータを受信するステップを含む方法。
  6. ホストシステムと一緒に再プログラム可能な不揮発性メモリシステムを動作する方法であって、前記メモリシステムは、新たなデータが書き込まれる前に消去されるメモリセルのブロックを有し、
    固有のファイル識別子によってアドレス指定されたデータを受信するステップと、
    ファイルの前記受信したデータを、他のいかなるファイルのデータも含まない1つ以上のブロック内に記憶し、必要に応じて、別のブロックの一部内に記憶するステップと、
    前記ブロック内に記憶されたデータを有するファイルを削除するための前記ホストからのコマンドに応答して、前記ファイルのデータを含むが他のいかなるファイルのデータも含まない前記ブロックのデータを古い状態にするステップと、
    その後、新たなデータを記憶するのに前記古いデータブロックのいずれかを用いる必要があるデータをプログラムするコマンドを前記ホストが送信する前に前記古いデータブロックを消去するステップと、
    を含む方法。
  7. 請求項6記載の方法において、
    前記古いデータブロックを消去するステップは、前記ホストがアイドル状態にある期間中に生じる方法。
  8. 請求項6記載の方法において、
    ホストファイルを古くする前記コマンドは、前記メモリシステムから前記ファイルを削除または消去するコマンドを含む方法。
  9. 請求項6記載の方法において、
    前記固有のファイル識別子によってアドレス指定されたデータを受信するステップは、前記識別されたファイル内のオフセットを用いてアドレス指定されたデータを受信するステップを含む方法。
  10. 任意の新たなデータが書き込まれる前に消去されるブロックに編成されたメモリセルを有する再プログラム可能な不揮発性大容量記憶システムを動作する方法であって、
    固有のファイル識別子によってアドレス指定されたデータを受信するステップと、
    メモリセルの前記ブロック内の物理アドレスに、前記受信したデータをプログラムするステップと、
    メモリセルのブロック内に予めプログラムされた所定のファイルを削除するコマンドの受信に応答して、前記所定のファイルのデータだけを含む前記ブロックを消去するようにスケジュールし、前記所定のファイルのデータと何か他のファイルの有効データとを含む少なくとも1つのブロックを、前記他のファイルの前記有効データを別のブロック内に統合するようにスケジュールするステップと、
    を含む方法。
  11. 請求項10記載の方法において、
    前記データをプログラムするステップは、整数の1つ以上のブロックを前記所定のファイルのデータで満たし、前記少なくとも1つのブロックを前記所定のファイルの残留データで部分的に満たすように、前記受信したデータをプログラムするステップを含む方法。
  12. 請求項10記載の方法において、
    前記固有のファイル識別子によってアドレス指定されたデータを受信するステップは、前記識別されたファイル内のオフセットを用いてアドレス指定されたデータを受信するステップを含む方法。
  13. メモリシステムであって、
    新たなデータが書き込まれる前に同時に消去されるメモリセルの複数の個々のブロックに編成された不揮発性電荷記憶半導体メモリセルのアレイと、
    (a)前記メモリシステムによって受信されたデータを、一意的に識別されたファイル内のオフセットアドレスを用いて、前記メモリアレイの前記ブロックの選択された1つ以上のブロック内に記憶させ、(b)前記一意的に識別されたファイルのデータがオフセットアドレスによって記憶される前記ブロックを追跡し続け、(c)特定ファイルを削除するコマンドの受信に応答して、前記選択された1つ以上のブロック内に記憶された前記特定ファイルのデータを削除させるように動作するため、前記メモリセルアレイと接続されたコントローラと、
    を含むメモリシステム。
  14. 請求項13記載のメモリシステムにおいて、
    前記コントローラは、(c)前記受信した削除コマンドに応答して、最初に、前記特定ファイルだけの受信したデータを含む前記1つ以上のブロックのいずれかに記憶された前記データに古いとしてマークを付けさせ、その後、古いとしてマークを付けられたすべての受信したデータを有する前記1つ以上のブロックを消去させるようにさらに動作するメモリシステム。
  15. 請求項14記載のメモリシステムにおいて、
    前記コントローラは、前記受信した削除コマンドに応答して、(c)別のファイルの有効データも含む前記選択された1つ以上のブロックの任意の共通ブロック内の前記特定ファイルの受信したデータに古いとしてマークを付け、次に、前記共通ブロックの前記有効データを、別のブロック内の他の有効データと統合させ、その後、前記共通ブロックを消去させるようにさらに動作するメモリシステム。
  16. 請求項13記載のメモリシステムにおいて、
    前記コントローラは、最初に、ファイルを削除するコマンドの受信を含まない動作の結果として他のブロックもリストする統合待ち行列内に、前記選択された1つ以上のブロックをリストし、次に、前記選択された1つ以上のブロックの前記データを前記待ち行列内の位置の順に後で削除することによって、前記選択された1つ以上のブロック内に記憶された前記特定ファイルのデータを削除させるようにさらに動作するメモリシステム。
JP2007556210A 2005-02-16 2006-02-08 フラッシュメモリにおける直接ファイルデータプログラミングおよび削除 Pending JP2008530709A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/060,174 US20060184718A1 (en) 2005-02-16 2005-02-16 Direct file data programming and deletion in flash memories
PCT/US2006/004585 WO2006088723A2 (en) 2005-02-16 2006-02-08 Direct file data programming and deletion in flash memories

Publications (1)

Publication Number Publication Date
JP2008530709A true JP2008530709A (ja) 2008-08-07

Family

ID=36560759

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007556210A Pending JP2008530709A (ja) 2005-02-16 2006-02-08 フラッシュメモリにおける直接ファイルデータプログラミングおよび削除

Country Status (8)

Country Link
US (3) US20060184718A1 (ja)
EP (1) EP1849079A2 (ja)
JP (1) JP2008530709A (ja)
KR (1) KR101344688B1 (ja)
CN (1) CN101147133B (ja)
IL (1) IL185175A0 (ja)
TW (1) TW200639632A (ja)
WO (1) WO2006088723A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013136836A1 (ja) * 2012-03-15 2013-09-19 株式会社 東芝 ビデオ配信サーバ、ssd制御方法

Families Citing this family (227)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970969B2 (en) * 2002-08-29 2005-11-29 Micron Technology, Inc. Multiple segment data object management
KR100876084B1 (ko) 2007-02-13 2008-12-26 삼성전자주식회사 플래시 저장 장치로 삭제 정보를 전달할 수 있는 컴퓨팅시스템
US7877539B2 (en) * 2005-02-16 2011-01-25 Sandisk Corporation Direct data file storage in flash memories
US20060184718A1 (en) * 2005-02-16 2006-08-17 Sinclair Alan W Direct file data programming and deletion in flash memories
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
US7634494B2 (en) * 2005-05-03 2009-12-15 Intel Corporation Flash memory directory virtualization
US7409489B2 (en) * 2005-08-03 2008-08-05 Sandisk Corporation Scheduling of reclaim operations in non-volatile memory
US7669003B2 (en) 2005-08-03 2010-02-23 Sandisk Corporation Reprogrammable non-volatile memory systems with indexing of directly stored data files
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
KR101378031B1 (ko) 2005-08-03 2014-03-27 샌디스크 테크놀로지스, 인코포레이티드 데이터 파일을 직접적으로 저장하는 메모리 블록의 관리
US8140813B2 (en) * 2005-09-15 2012-03-20 Eye-Fi, Inc. Endless memory
US7702821B2 (en) 2005-09-15 2010-04-20 Eye-Fi, Inc. Content-aware digital media storage device and methods of using the same
US7814262B2 (en) * 2005-10-13 2010-10-12 Sandisk Corporation Memory system storing transformed units of data in fixed sized storage blocks
US7634585B2 (en) * 2005-11-04 2009-12-15 Sandisk Corporation In-line cache using nonvolatile memory between host and disk device
US20070106842A1 (en) * 2005-11-04 2007-05-10 Conley Kevin M Enhanced first level storage caching methods using nonvolatile memory
US7877540B2 (en) * 2005-12-13 2011-01-25 Sandisk Corporation Logically-addressed file storage methods
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
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
US7747837B2 (en) 2005-12-21 2010-06-29 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
US7769978B2 (en) 2005-12-21 2010-08-03 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
CN100485681C (zh) * 2006-03-23 2009-05-06 北京握奇数据系统有限公司 智能卡存储系统及该系统中文件创建管理的方法
JP4785660B2 (ja) * 2006-07-21 2011-10-05 株式会社リコー 画像処理装置
US8489817B2 (en) 2007-12-06 2013-07-16 Fusion-Io, Inc. Apparatus, system, and method for caching data
CN101681282A (zh) 2006-12-06 2010-03-24 弗森多系统公司(dba弗森-艾奥) 用于共享的、前端、分布式raid的装置、系统和方法
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
US7515500B2 (en) 2006-12-20 2009-04-07 Nokia Corporation Memory device performance enhancement through pre-erase mechanism
US7917686B2 (en) 2006-12-26 2011-03-29 Sandisk Corporation Host system with direct data file interface configurability
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
US8166267B2 (en) * 2006-12-26 2012-04-24 Sandisk Technologies Inc. Managing a LBA interface in a direct data file memory system
US20080155175A1 (en) * 2006-12-26 2008-06-26 Sinclair Alan W Host System That Manages a LBA Interface With Flash Memory
JP2010515163A (ja) * 2006-12-26 2010-05-06 サンディスク コーポレイション ダイレクトデータファイルメモリシステムにおけるlbaインターフェイスの管理
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
KR100823171B1 (ko) * 2007-02-01 2008-04-18 삼성전자주식회사 파티션된 플래시 변환 계층을 갖는 컴퓨터 시스템 및플래시 변환 계층의 파티션 방법
US7917479B2 (en) 2007-03-20 2011-03-29 Micron Technology, Inc. Non-volatile memory devices, systems including same and associated methods
US20080235480A1 (en) * 2007-03-21 2008-09-25 Shai Traister Systems for storing memory operations in a queue
US7987332B2 (en) * 2007-03-21 2011-07-26 Sandisk Technologies Inc. Methods for storing memory operations in a queue
JP5224706B2 (ja) * 2007-03-23 2013-07-03 キヤノン株式会社 記憶装置及び記憶装置の制御方法
US8032724B1 (en) * 2007-04-04 2011-10-04 Marvell International Ltd. Demand-driven opportunistic garbage collection in memory components
US8364918B1 (en) 2007-04-06 2013-01-29 Marvell International Ltd. Sensed opportunistic garbage collection in memory components
US9207876B2 (en) 2007-04-19 2015-12-08 Microsoft Technology Licensing, Llc Remove-on-delete technologies for solid state drive optimization
US7996642B1 (en) 2007-04-25 2011-08-09 Marvell International Ltd. Digital locked loop on channel tagged memory requests for memory optimization
US20080294492A1 (en) * 2007-05-24 2008-11-27 Irina Simpson Proactively determining potential evidence issues for custodial systems in active litigation
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
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
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
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
JP4949176B2 (ja) * 2007-09-10 2012-06-06 ソニー株式会社 情報処理装置、記録方法およびコンピュータプログラム
US8566504B2 (en) * 2007-09-28 2013-10-22 Sandisk Technologies Inc. Dynamic metablocks
US11226947B1 (en) * 2007-10-10 2022-01-18 United Services Automobile Association (Usaa) Systems and methods for storing time-series data
US8959307B1 (en) 2007-11-16 2015-02-17 Bitmicro Networks, Inc. Reduced latency memory read transactions in storage devices
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
US8805897B2 (en) * 2007-12-13 2014-08-12 Redknee Inc. Method and system for storage
US8572043B2 (en) 2007-12-20 2013-10-29 International Business Machines Corporation Method and system for storage of unstructured data for electronic discovery in external data stores
US8112406B2 (en) 2007-12-21 2012-02-07 International Business Machines Corporation Method and apparatus for electronic data discovery
US20090164745A1 (en) * 2007-12-21 2009-06-25 Alan Sinclair System and Method for Controlling an Amount of Unprogrammed Capacity in Memory Blocks of a Mass Storage System
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
US8140494B2 (en) 2008-01-21 2012-03-20 International Business Machines Corporation Providing collection transparency information to an end user to achieve a guaranteed quality document search and production in electronic data discovery
US8352703B2 (en) * 2008-02-20 2013-01-08 Infineon Technologies Ag Address mapping of program code and data in memory
US8275720B2 (en) 2008-06-12 2012-09-25 International Business Machines Corporation External scoping sources to determine affected people, systems, and classes of information in legal matters
US9830563B2 (en) 2008-06-27 2017-11-28 International Business Machines Corporation System and method for managing legal obligations for data
US8515924B2 (en) 2008-06-30 2013-08-20 International Business Machines Corporation Method and apparatus for handling edge-cases of event-driven disposition
US8489439B2 (en) 2008-06-30 2013-07-16 International Business Machines Corporation Forecasting discovery costs based on complex and incomplete facts
US8327384B2 (en) 2008-06-30 2012-12-04 International Business Machines Corporation Event driven disposition
US8484069B2 (en) 2008-06-30 2013-07-09 International Business Machines Corporation Forecasting discovery costs based on complex and incomplete facts
US7792945B2 (en) * 2008-06-30 2010-09-07 Pss Systems, Inc. Method and apparatus for managing the disposition of data in systems when data is on legal hold
US8073729B2 (en) 2008-09-30 2011-12-06 International Business Machines Corporation Forecasting discovery costs based on interpolation of historic event patterns
JP2010026933A (ja) * 2008-07-23 2010-02-04 Toshiba Corp メモリシステム、ホスト装置
US8204869B2 (en) 2008-09-30 2012-06-19 International Business Machines Corporation Method and apparatus to define and justify policy requirements using a legal reference library
US20100131726A1 (en) * 2008-11-26 2010-05-27 Nokia Corporation Methods, apparatuses, and computer program products for enhancing memory erase functionality
US8407401B2 (en) * 2008-11-26 2013-03-26 Core Wireless Licensing S.A.R.L. Methods, apparatuses, and computer program products for enhancing memory erase functionality
US8205063B2 (en) * 2008-12-30 2012-06-19 Sandisk Technologies Inc. Dynamic mapping of logical ranges to write blocks
US8452940B2 (en) * 2008-12-30 2013-05-28 Sandisk Technologies Inc. Optimized memory management for random and sequential data writing
US8918365B2 (en) 2009-06-19 2014-12-23 Blekko, Inc. Dedicating disks to reading or writing
EP2665002A3 (en) * 2009-06-19 2014-04-02 Blekko, Inc. A method of counting unique items in a database system
WO2011013125A1 (en) 2009-07-27 2011-02-03 Storwize Ltd. Method and system for transformation of logical data objects for storage
US8176284B2 (en) * 2009-08-11 2012-05-08 Texas Memory Systems, Inc. FLASH-based memory system with variable length page stripes including data protection information
US8930622B2 (en) 2009-08-11 2015-01-06 International Business Machines Corporation Multi-level data protection for flash memory system
US7941696B2 (en) * 2009-08-11 2011-05-10 Texas Memory Systems, Inc. Flash-based memory system with static or variable length page stripes including data protection information and auxiliary protection stripes
US7818525B1 (en) * 2009-08-12 2010-10-19 Texas Memory Systems, Inc. Efficient reduction of read disturb errors in NAND FLASH memory
US8189379B2 (en) 2009-08-12 2012-05-29 Texas Memory Systems, Inc. Reduction of read disturb errors in NAND FLASH memory
US20110040600A1 (en) * 2009-08-17 2011-02-17 Deidre Paknad E-discovery decision support
JP2013502647A (ja) * 2009-08-21 2013-01-24 ラムバス・インコーポレーテッド インサイチュでのメモリのアニール
TWI450271B (zh) * 2009-09-02 2014-08-21 Silicon Motion Inc 用來管理一快閃記憶體的複數個區塊之方法以及相關之記憶裝置及其控制器
US8665601B1 (en) 2009-09-04 2014-03-04 Bitmicro Networks, Inc. Solid state drive with improved enclosure assembly
US9135190B1 (en) * 2009-09-04 2015-09-15 Bitmicro Networks, Inc. Multi-profile memory controller for computing devices
US8447908B2 (en) 2009-09-07 2013-05-21 Bitmicro Networks, Inc. Multilevel memory bus system for solid-state mass storage
US9122579B2 (en) 2010-01-06 2015-09-01 Intelligent Intellectual Property Holdings 2 Llc Apparatus, system, and method for a storage layer
US8560804B2 (en) * 2009-09-14 2013-10-15 Bitmicro Networks, Inc. Reducing erase cycles in an electronic storage device that uses at least one erase-limited memory device
CN102033812B (zh) * 2009-09-24 2013-04-10 慧荣科技股份有限公司 用于管理闪存多个区块的方法和相关记忆装置及其控制器
US20110119462A1 (en) * 2009-11-19 2011-05-19 Ocz Technology Group, Inc. Method for restoring and maintaining solid-state drive performance
US8655856B2 (en) 2009-12-22 2014-02-18 International Business Machines Corporation Method and apparatus for policy distribution
US8250041B2 (en) 2009-12-22 2012-08-21 International Business Machines Corporation Method and apparatus for propagation of file plans from enterprise retention management applications to records management systems
US8489855B2 (en) * 2010-05-07 2013-07-16 Ocz Technology Group Inc. NAND flash-based solid state drive and method of operation
US20120173795A1 (en) * 2010-05-25 2012-07-05 Ocz Technology Group, Inc. Solid state drive with low write amplification
JP4829365B1 (ja) * 2010-05-31 2011-12-07 株式会社東芝 データ記憶装置及びデータ書き込み方法
US8832148B2 (en) 2010-06-29 2014-09-09 International Business Machines Corporation Enterprise evidence repository
US8566903B2 (en) 2010-06-29 2013-10-22 International Business Machines Corporation Enterprise evidence repository providing access control to collected artifacts
US8402359B1 (en) 2010-06-30 2013-03-19 International Business Machines Corporation Method and apparatus for managing recent activity navigation in web applications
KR101686590B1 (ko) * 2010-09-20 2016-12-14 삼성전자주식회사 플래시 메모리 시스템 및 그것의 워드 라인 인터리빙 방법
US10558705B2 (en) * 2010-10-20 2020-02-11 Microsoft Technology Licensing, Llc Low RAM space, high-throughput persistent key-value store using secondary memory
US20120144123A1 (en) * 2010-12-01 2012-06-07 International Business Machines Corporation Read-ahead processing in networked client-server architecture
TWI506523B (zh) * 2010-12-10 2015-11-01 Chiun Mai Comm Systems Inc 圖示訪問系統及方法
WO2012083308A2 (en) 2010-12-17 2012-06-21 Fusion-Io, Inc. Apparatus, system, and method for persistent data management on a non-volatile storage media
US8819328B2 (en) * 2010-12-30 2014-08-26 Sandisk Technologies Inc. Controller and method for performing background operations
CN102591738B (zh) * 2011-01-07 2015-09-30 群联电子股份有限公司 数据管理方法、存储器控制器与嵌入式存储器储存装置
CN102081577B (zh) * 2011-01-12 2013-02-13 厦门雅迅网络股份有限公司 对Flash存储器的数据存储结构进行数据操作的方法
US8848731B2 (en) 2011-01-31 2014-09-30 Qualcomm Incorporated System and method for facilitating data transfer using a shared non-deterministic bus
US9201677B2 (en) 2011-05-23 2015-12-01 Intelligent Intellectual Property Holdings 2 Llc Managing data input/output operations
US9003104B2 (en) 2011-02-15 2015-04-07 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a file-level cache
US8874823B2 (en) 2011-02-15 2014-10-28 Intellectual Property Holdings 2 Llc Systems and methods for managing data input/output operations
US9141527B2 (en) 2011-02-25 2015-09-22 Intelligent Intellectual Property Holdings 2 Llc Managing cache pools
WO2012129191A2 (en) 2011-03-18 2012-09-27 Fusion-Io, Inc. Logical interfaces for contextual storage
US9311229B2 (en) 2011-03-29 2016-04-12 Blackberry Limited System and method for managing flash memory
US9965381B1 (en) * 2011-06-30 2018-05-08 EMC IP Holding Company LLC Indentifying data for placement in a storage system
CN102511044B (zh) * 2011-09-06 2013-10-02 华为技术有限公司 一种数据删除方法及装置
US9372755B1 (en) 2011-10-05 2016-06-21 Bitmicro Networks, Inc. Adaptive power cycle sequences for data recovery
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
CN102622307B (zh) * 2012-02-27 2016-03-30 记忆科技(深圳)有限公司 硬盘数据的操作方法和硬盘控制器
US9213632B1 (en) 2012-02-29 2015-12-15 Marvell International Ltd. Systems and methods for data storage devices to use external resources
US8996782B2 (en) 2012-03-23 2015-03-31 Kabushiki Kaisha Toshiba Memory system and bank interleaving method
US9043669B1 (en) 2012-05-18 2015-05-26 Bitmicro Networks, Inc. Distributed ECC engine for storage media
US9612966B2 (en) 2012-07-03 2017-04-04 Sandisk Technologies Llc Systems, methods and apparatus for a virtual machine cache
US10339056B2 (en) 2012-07-03 2019-07-02 Sandisk Technologies Llc Systems, methods and apparatus for cache transfers
US10346095B2 (en) 2012-08-31 2019-07-09 Sandisk Technologies, Llc Systems, methods, and interfaces for adaptive cache persistence
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
US9569113B2 (en) * 2012-10-11 2017-02-14 SK Hynix Inc. Data storage device and operating method thereof
KR20140080660A (ko) * 2012-12-13 2014-07-01 에스케이하이닉스 주식회사 반도체 메모리 장치 및 시스템의 동작 방법
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
US9734911B2 (en) 2012-12-31 2017-08-15 Sandisk Technologies Llc Method and system for asynchronous die operations in a non-volatile 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
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
US9535836B2 (en) * 2013-03-13 2017-01-03 Hewlett Packard Enterprise Development Lp Non-volatile memory update tracking
US9423457B2 (en) 2013-03-14 2016-08-23 Bitmicro Networks, Inc. Self-test solution for delay locked loops
US9858084B2 (en) 2013-03-15 2018-01-02 Bitmicro Networks, Inc. Copying of power-on reset sequencer descriptor from nonvolatile memory to random access memory
US9916213B1 (en) 2013-03-15 2018-03-13 Bitmicro Networks, Inc. Bus arbitration with routing and failover mechanism
US9400617B2 (en) 2013-03-15 2016-07-26 Bitmicro Networks, Inc. Hardware-assisted DMA transfer with dependency table configured to permit-in parallel-data drain from cache without processor intervention when filled or drained
US9875205B1 (en) 2013-03-15 2018-01-23 Bitmicro Networks, Inc. Network of memory systems
US9501436B1 (en) 2013-03-15 2016-11-22 Bitmicro Networks, Inc. Multi-level message passing descriptor
US9842053B2 (en) 2013-03-15 2017-12-12 Sandisk Technologies Llc Systems and methods for persistent cache logging
US9720603B1 (en) 2013-03-15 2017-08-01 Bitmicro Networks, Inc. IOC to IOC distributed caching architecture
US9798688B1 (en) 2013-03-15 2017-10-24 Bitmicro Networks, Inc. Bus arbitration with routing and failover mechanism
US10482009B1 (en) 2013-03-15 2019-11-19 Google Llc Use of a logical-to-logical translation map and a logical-to-physical translation map to access a data storage device
US9430386B2 (en) 2013-03-15 2016-08-30 Bitmicro Networks, Inc. Multi-leveled cache management in a hybrid storage system
US9971524B1 (en) 2013-03-15 2018-05-15 Bitmicro Networks, Inc. Scatter-gather approach for parallel data transfer in a mass storage system
US9672178B1 (en) 2013-03-15 2017-06-06 Bitmicro Networks, Inc. Bit-mapped DMA transfer with dependency table configured to monitor status so that a processor is not rendered as a bottleneck in a system
US9734067B1 (en) 2013-03-15 2017-08-15 Bitmicro Networks, Inc. Write buffering
US10489318B1 (en) 2013-03-15 2019-11-26 Bitmicro Networks, Inc. Scatter-gather approach for parallel data transfer in a mass storage system
US9842024B1 (en) 2013-03-15 2017-12-12 Bitmicro Networks, Inc. Flash electronic disk with RAID controller
US10102144B2 (en) 2013-04-16 2018-10-16 Sandisk Technologies Llc Systems, methods and interfaces for data virtualization
US10558561B2 (en) 2013-04-16 2020-02-11 Sandisk Technologies Llc Systems and methods for storage metadata management
CN105683926A (zh) * 2013-06-25 2016-06-15 美光科技公司 按需块管理
US9842128B2 (en) 2013-08-01 2017-12-12 Sandisk Technologies Llc Systems and methods for atomic storage operations
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
KR20150068747A (ko) 2013-12-12 2015-06-22 삼성전자주식회사 비휘발성 메모리 시스템, 이를 포함하는 모바일 장치 및 비휘발성 메모리 시스템의 동작방법
JP2015138272A (ja) * 2014-01-20 2015-07-30 ソニー株式会社 情報処理装置、情報処理方法、および情報処理プログラム
US9582205B2 (en) * 2014-04-17 2017-02-28 Sandisk Technologies Llc Protection scheme with dual programming of a memory system
US10055150B1 (en) 2014-04-17 2018-08-21 Bitmicro Networks, Inc. Writing volatile scattered memory metadata to flash device
US10078604B1 (en) 2014-04-17 2018-09-18 Bitmicro Networks, Inc. Interrupt coalescing
US9952991B1 (en) 2014-04-17 2018-04-24 Bitmicro Networks, Inc. Systematic method on queuing of descriptors for multiple flash intelligent DMA engine operation
US10042792B1 (en) 2014-04-17 2018-08-07 Bitmicro Networks, Inc. Method for transferring and receiving frames across PCI express bus for SSD device
US9811461B1 (en) 2014-04-17 2017-11-07 Bitmicro Networks, Inc. Data storage system
US10025736B1 (en) 2014-04-17 2018-07-17 Bitmicro Networks, Inc. Exchange message protocol message transmission between two devices
US9658788B2 (en) * 2014-05-28 2017-05-23 Sandisk Technologies Llc Systems and methods for immediate physical erasure of data stored in a memory system in response to a user command
US10430328B2 (en) 2014-09-16 2019-10-01 Sandisk Technologies Llc Non-volatile cache and non-volatile storage medium using single bit and multi bit flash memory cells or different programming parameters
US9690823B2 (en) * 2014-09-25 2017-06-27 Dropbox, Inc. Synchronizing copies of an extent in an append-only storage system
US9946607B2 (en) 2015-03-04 2018-04-17 Sandisk Technologies Llc Systems and methods for storage error management
US10305976B2 (en) * 2015-09-21 2019-05-28 Intel Corporation Method and apparatus for dynamically offloading execution of machine code in an application to a virtual machine
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
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
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
US10133490B2 (en) 2015-10-30 2018-11-20 Sandisk Technologies Llc System and method for managing extended maintenance scheduling in a non-volatile memory
US9823854B2 (en) * 2016-03-18 2017-11-21 Qualcomm Incorporated Priority-based access of compressed memory lines in memory in a processor-based system
KR20170110808A (ko) * 2016-03-24 2017-10-12 에스케이하이닉스 주식회사 데이터 저장 장치를 포함하는 데이터 처리 시스템
JP2018010507A (ja) * 2016-07-14 2018-01-18 富士通株式会社 メモリ管理プログラム、メモリ管理方法及びメモリ管理装置
CN107634895B (zh) * 2016-07-19 2020-09-22 上海诺基亚贝尔股份有限公司 用于基于文件或单个消息的批量操作处理方法和设备
KR102611638B1 (ko) * 2016-09-27 2023-12-08 삼성전자주식회사 스토리지 장치의 동작 방법 및 스토리지 장치를 포함하는 데이터 저장 시스템
US10481798B2 (en) * 2016-10-28 2019-11-19 Pure Storage, Inc. Efficient flash management for multiple controllers
JP6677627B2 (ja) * 2016-12-20 2020-04-08 株式会社ソニー・インタラクティブエンタテインメント 情報処理装置およびメモリアクセス方法
US11169871B2 (en) 2017-02-23 2021-11-09 SK Hynix Inc. Data storage device and operating method thereof
KR20180126921A (ko) * 2017-05-19 2018-11-28 에스케이하이닉스 주식회사 데이터 저장 장치 및 그것의 동작 방법
TWI653533B (zh) 2017-03-07 2019-03-11 慧榮科技股份有限公司 資料儲存裝置以及其操作方法
US10552050B1 (en) 2017-04-07 2020-02-04 Bitmicro Llc Multi-dimensional computer storage system
US20190012259A1 (en) * 2017-07-06 2019-01-10 Futurewei Technologies, Inc. Lba eviction in pcm media
US10474391B2 (en) * 2017-09-05 2019-11-12 Western Digital Technologies, Inc. Storage system and method for executing file-based firmware commands and collecting response data
US11733873B2 (en) 2017-12-01 2023-08-22 Micron Technology, Inc. Wear leveling in solid state drives
CN108037725B (zh) * 2017-12-08 2019-09-03 中冶南方工程技术有限公司 一种读写plc数据的方法和装置
CN109992402B (zh) * 2017-12-29 2021-07-09 Oppo广东移动通信有限公司 内存处理方法和装置、电子设备、计算机可读存储介质
KR20190092941A (ko) * 2018-01-31 2019-08-08 에스케이하이닉스 주식회사 메모리 장치, 이를 포함하는 메모리 시스템 및 메모리 시스템의 동작 방법
US10678458B2 (en) * 2018-02-09 2020-06-09 Micron Technology, Inc. Data storage device idle time processing
US10489085B2 (en) * 2018-02-28 2019-11-26 Micron Technology, Inc. Latency-based scheduling of command processing in data storage devices
US10846955B2 (en) 2018-03-16 2020-11-24 Micron Technology, Inc. Black box data recorder for autonomous driving vehicle
TWI664527B (zh) * 2018-03-20 2019-07-01 慧榮科技股份有限公司 用來於一記憶裝置中進行初始化之方法、記憶裝置及其控制器以及電子裝置
CN108958651A (zh) * 2018-06-04 2018-12-07 北京小米移动软件有限公司 脏数据块擦除方法、装置、设备
US11094148B2 (en) 2018-06-18 2021-08-17 Micron Technology, Inc. Downloading system memory data in response to event detection
KR102660399B1 (ko) * 2018-09-20 2024-04-25 에스케이하이닉스 주식회사 메모리 시스템 및 그것의 동작방법
US20200117722A1 (en) * 2018-10-12 2020-04-16 Goke Us Research Laboratory Efficient file storage and retrieval system, method and apparatus
JP2020071632A (ja) * 2018-10-31 2020-05-07 レノボ・シンガポール・プライベート・リミテッド 情報処理装置、制御方法、及びプログラム
US11782605B2 (en) * 2018-11-29 2023-10-10 Micron Technology, Inc. Wear leveling for non-volatile memory using data write counters
KR20200066906A (ko) * 2018-12-03 2020-06-11 에스케이하이닉스 주식회사 메모리 시스템, 그것의 동작방법 및 컨트롤러
KR20200068944A (ko) * 2018-12-06 2020-06-16 에스케이하이닉스 주식회사 메모리 시스템 및 그것의 동작방법
KR20200141212A (ko) * 2019-06-10 2020-12-18 에스케이하이닉스 주식회사 가비지콜렉션 동작을 위한 메모리 시스템 및 메모리 시스템의 동작방법
TWI697778B (zh) * 2019-06-17 2020-07-01 慧榮科技股份有限公司 資料儲存裝置與資料處理方法
KR20210016191A (ko) * 2019-08-01 2021-02-15 삼성전자주식회사 스토리지 장치
KR20210027563A (ko) * 2019-08-28 2021-03-11 에스케이하이닉스 주식회사 저장 장치 및 그 동작 방법
US10922012B1 (en) 2019-09-03 2021-02-16 Dropbox, Inc. Fair data scrubbing in a data storage system
CN110795400B (zh) * 2019-10-12 2022-03-22 苏州浪潮智能科技有限公司 一种文件的管理方法、装置、设备及介质
CN110750467B (zh) * 2019-10-22 2021-11-02 深圳芯邦科技股份有限公司 一种Nand Flash中干扰页的检测方法、系统
TWI724696B (zh) * 2019-12-18 2021-04-11 財團法人工業技術研究院 工件孔洞量測方法
TWI727842B (zh) 2020-02-20 2021-05-11 大陸商長江存儲科技有限責任公司 存儲器件及其編程方法
US11704035B2 (en) 2020-03-30 2023-07-18 Pure Storage, Inc. Unified storage on block containers
CN113495681A (zh) * 2020-04-07 2021-10-12 杭州萤石软件有限公司 一种nand flash文件数据存取方法、装置及存储介质
KR20220018060A (ko) * 2020-04-23 2022-02-14 양쯔 메모리 테크놀로지스 씨오., 엘티디. 메모리 디바이스 및 그것의 프로그래밍 방법
CN112162935B (zh) * 2020-09-30 2021-06-08 深圳市时创意电子有限公司 存储芯片的数据处理方法、装置、计算机设备及存储介质
TWI808384B (zh) * 2021-02-23 2023-07-11 慧榮科技股份有限公司 儲存裝置、快閃記憶體控制器及其控制方法
KR20220142192A (ko) * 2021-04-14 2022-10-21 에스케이하이닉스 주식회사 저장 장치 및 그 동작 방법
US20230097115A1 (en) * 2021-09-27 2023-03-30 Advanced Micro Devices, Inc. Garbage collecting wavefront

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10124384A (ja) * 1996-08-28 1998-05-15 Toshiba Corp 不揮発性半導体メモリの制御方法
JP2003187203A (ja) * 2001-10-01 2003-07-04 Hewlett Packard Co <Hp> メモリカード用のメモリコントローラによるファイルアロケーションテーブル管理
US20030229753A1 (en) * 2002-06-10 2003-12-11 Samsung Electronics Co., Ltd. Flash memory file system

Family Cites Families (134)

* Cited by examiner, † Cited by third party
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カード
EP1031992B1 (en) * 1989-04-13 2006-06-21 SanDisk Corporation Flash EEPROM system
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 フラッシュ・メモリ使用方法
JP3508114B2 (ja) * 1992-03-05 2004-03-22 セイコーエプソン株式会社 液晶装置及びその駆動方法並びに駆動回路
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ファイル装置
GB2291990A (en) 1995-09-27 1996-02-07 Memory Corp Plc Flash-memory management system
GB2291991A (en) * 1995-09-27 1996-02-07 Memory Corp Plc Disk drive emulation with a block-erasable memory
US5933847A (en) * 1995-09-28 1999-08-03 Canon Kabushiki Kaisha Selecting erase method based on type of power supply for flash EEPROM
US5867641A (en) * 1995-10-27 1999-02-02 Scm Microsystems (U.S.) Inc. Flash translation layer cleanup system and method
US6014724A (en) * 1995-10-27 2000-01-11 Scm Microsystems (U.S.) Inc. Flash translation layer block indication map revision 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
JP4079506B2 (ja) * 1997-08-08 2008-04-23 株式会社東芝 不揮発性半導体メモリシステムの制御方法
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
US6480935B1 (en) 1999-01-15 2002-11-12 Todd Carper Smart card memory management system and method
US6256690B1 (en) * 1999-01-15 2001-07-03 Todd Carper System and method for facilitating multiple applications on a smart card
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 版下フィルムの印刷方法および版下印刷用プリンタ
WO2001008014A1 (en) 1999-07-28 2001-02-01 Sony Corporation Recording system, data recording device, memory device, and data recording method
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
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
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
US6668336B2 (en) 2001-11-08 2003-12-23 M-Systems Flash Disk Pioneers Ltd. Ruggedized block device driver
US6883114B2 (en) * 2001-11-08 2005-04-19 M-Systems Flash Disk Pioneers Ltd. Block device driver enabling a ruggedized file system
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
US7035949B2 (en) * 2002-07-29 2006-04-25 M-System Flash Dist Pioneers Ltd. Multipurpose processor, system and method
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
US6987478B2 (en) * 2003-02-06 2006-01-17 Symbol Technologies, Inc. Multi-function portable device
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 デバイス機器、及びデバイス機器の記録装置のフォーマット変換方法
US7383375B2 (en) * 2003-12-30 2008-06-03 Sandisk Corporation Data run programming
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
US20050144363A1 (en) * 2003-12-30 2005-06-30 Sinclair Alan W. Data boundary management
US8504798B2 (en) * 2003-12-30 2013-08-06 Sandisk Technologies Inc. Management of non-volatile memory systems having large erase blocks
US20060004951A1 (en) * 2004-06-30 2006-01-05 Rudelic John C Method and apparatus to alter code in a memory
US7395384B2 (en) * 2004-07-21 2008-07-01 Sandisk Corproation Method and apparatus for maintaining data on non-volatile memory systems
US8607016B2 (en) * 2004-07-21 2013-12-10 Sandisk Technologies Inc. FAT analysis for optimized sequential cluster management
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
US7386655B2 (en) * 2004-12-16 2008-06-10 Sandisk Corporation Non-volatile memory and method with improved indexing for scratch pad and update blocks
US7412560B2 (en) * 2004-12-16 2008-08-12 Sandisk Corporation Non-volatile memory and method with multi-stream updating
US20060161724A1 (en) * 2005-01-20 2006-07-20 Bennett Alan D Scheduling of housekeeping operations in flash memory systems
US7315917B2 (en) * 2005-01-20 2008-01-01 Sandisk Corporation Scheduling of housekeeping operations in flash memory systems
US20060184718A1 (en) * 2005-02-16 2006-08-17 Sinclair Alan W Direct file data programming and deletion in flash memories
US20060184719A1 (en) 2005-02-16 2006-08-17 Sinclair Alan W Direct data file storage implementation techniques in flash memories
US7877539B2 (en) * 2005-02-16 2011-01-25 Sandisk Corporation Direct data file storage in flash memories
US7669003B2 (en) * 2005-08-03 2010-02-23 Sandisk Corporation Reprogrammable non-volatile memory systems with indexing of directly stored data files
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10124384A (ja) * 1996-08-28 1998-05-15 Toshiba Corp 不揮発性半導体メモリの制御方法
JP2003187203A (ja) * 2001-10-01 2003-07-04 Hewlett Packard Co <Hp> メモリカード用のメモリコントローラによるファイルアロケーションテーブル管理
US20030229753A1 (en) * 2002-06-10 2003-12-11 Samsung Electronics Co., Ltd. Flash memory file system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013136836A1 (ja) * 2012-03-15 2013-09-19 株式会社 東芝 ビデオ配信サーバ、ssd制御方法
JP2013191150A (ja) * 2012-03-15 2013-09-26 Toshiba Corp ビデオ配信サーバ、ssd制御方法
US9807428B2 (en) 2012-03-15 2017-10-31 Kabushiki Kaisha Toshiba Video distribution server and SSD control method

Also Published As

Publication number Publication date
WO2006088723A2 (en) 2006-08-24
US20100223423A1 (en) 2010-09-02
TW200639632A (en) 2006-11-16
CN101147133B (zh) 2012-05-23
US20060184718A1 (en) 2006-08-17
EP1849079A2 (en) 2007-10-31
US8214583B2 (en) 2012-07-03
KR101344688B1 (ko) 2013-12-26
IL185175A0 (en) 2007-12-03
CN101147133A (zh) 2008-03-19
KR20070116793A (ko) 2007-12-11
WO2006088723A3 (en) 2007-01-11
US20060184723A1 (en) 2006-08-17

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
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
US20070143567A1 (en) Methods for data alignment in non-volatile memories with 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
US20070136555A1 (en) Logically-addressed file storage methods
US20070136553A1 (en) Logically-addressed file storage systems
WO2007019155A1 (en) Reclaiming data storage capacity in flash memory 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
JP2009512066A (ja) 固定サイズ格納ブロックを有するメモリシステムにおける変換データ単位格納
KR20080038368A (ko) 데이터 파일을 직접 저장하는 재프로그램가능 비휘발성메모리에 파일 데이터의 인덱싱
WO2007073536A2 (en) Non-volatile memories and methods with memory allocation for a directly mapped file storage system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090106

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110607

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110822

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110829

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111206

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20120724