WO2007019220A2 - Data consolidation and garbage collection in direct data file storage memories - Google Patents

Data consolidation and garbage collection in direct data file storage memories Download PDF

Info

Publication number
WO2007019220A2
WO2007019220A2 PCT/US2006/030242 US2006030242W WO2007019220A2 WO 2007019220 A2 WO2007019220 A2 WO 2007019220A2 US 2006030242 W US2006030242 W US 2006030242W WO 2007019220 A2 WO2007019220 A2 WO 2007019220A2
Authority
WO
WIPO (PCT)
Prior art keywords
file
data
block
blocks
erased
Prior art date
Application number
PCT/US2006/030242
Other languages
French (fr)
Other versions
WO2007019220A3 (en
Inventor
Alan W. Sinclair
Barry Wright
Original Assignee
Sandisk Corporation
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 Corporation filed Critical Sandisk Corporation
Priority to EP06789293A priority Critical patent/EP1920337A2/en
Priority to JP2008525181A priority patent/JP4537482B2/en
Priority to CN2006800284045A priority patent/CN101258473B/en
Publication of WO2007019220A2 publication Critical patent/WO2007019220A2/en
Publication of WO2007019220A3 publication Critical patent/WO2007019220A3/en
Priority to KR1020087004662A priority patent/KR101377147B1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/023—Free address space management
    • G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
    • G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1847—File system types specifically adapted to static storage, e.g. adapted to flash memory or SSD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G06F3/0605—Improving or facilitating administration, e.g. storage management by facilitating the interaction with a user or administrator
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0608—Saving storage space on storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G06F3/0613—Improving I/O performance in relation to throughput
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0643—Management of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/0644—Management of space entities, e.g. partitions, extents, pools
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0652—Erasing, e.g. deleting, data cleaning, moving of data to a wastebasket
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0673—Single storage device
    • G06F3/0679—Non-volatile semiconductor memory device, e.g. flash memory, one time programmable memory [OTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7202—Allocation control and policies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/72—Details relating to flash memory management
    • G06F2212/7205—Cleaning, compaction, garbage collection, erase control
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C16/00—Erasable programmable read-only memories
    • G11C16/02—Erasable programmable read-only memories electrically programmable
    • G11C16/04—Erasable programmable read-only memories electrically programmable using variable threshold transistors, e.g. FAMOS
    • G11C16/0483—Erasable programmable read-only memories electrically programmable using variable threshold transistors, e.g. FAMOS comprising cells having several storage transistors connected in series
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11C—STATIC STORES
    • G11C16/00—Erasable programmable read-only memories
    • G11C16/02—Erasable programmable read-only memories electrically programmable
    • G11C16/06—Auxiliary circuits, e.g. for writing into memory
    • G11C16/10—Programming or data input circuits
    • G11C16/102—External programming circuits, e.g. EPROM programmers; In-circuit programming or reprogramming; EPROM emulators

Definitions

  • This application relates generally to the operation of re-programmable nonvolatile memory systems such as semiconductor flash memory, including management of the interface between a host device and the memory system, and, more specifically, to the efficient use of a data file interface rather than the common mass memory logical address space (LBA) interface.
  • LBA logical address space
  • Data consolidation is treated differently herein than garbage collection and the two processes are implemented at least partially by different algorithms.
  • a garbage collection operation is utilized to move valid data of the file or block to one or more other blocks. This gathers valid data into a fewer number of blocks, thus freeing up capacity occupied by obsolete data once the original source block(s) are erased.
  • valid data of one partially filled block such as is usually created as the result of writing a new file, are combined with valid data of another partially filled block.
  • One or both of the original blocks that were the source of the data, now containing obsolete duplicate data are then scheduled for garbage collection.
  • queues are provided for scheduling individual garbage collection operations to recover memory storage capacity occupied by obsolete data
  • data consolidation preferably occurs when no garbage collection is scheduled and conditions are otherwise satisfactory for consolidation.
  • the file based memory does not retain data files that have been deleted by the host, contrary to the case when a logical interface is used, the memory will usually have a sufficient number of erased blocks even though the consolidation is delayed. The time taken by the omitted consolidation is therefore saved, and the performance of the memory improved as a result.
  • Garbage collection of a file does not create a common block that contains data from another file. Data for the file, which must be copied during the garbage collection, are programmed to the current program block for the file. The program block remains partially programmed at the end of the garbage collection.
  • Data are transferred between the memory system controller buffer memory and the memory cell array in complete sectors of data. This allows the generation of an ECC during programming and checking of an ECC during data read.
  • a swap block within the flash memory is used to make a security copy of data held in the volatile controller buffer memory for an open file that is not active; that is, when the most recent write command relates to a different file. It may also be used as part of a virtual buffer structure, to allow the available buffer memory capacity to support a larger number of open files through the use of swap operations between them.
  • Data in a FIT update block for a FIT range is consolidated with data in the FIT block for the range when the amount of data for the range in the FIT update block exceeds a threshold value. This allows data for new files to be consolidated to a FIT block.
  • a FIT file for a closed file is relocated to the FIT block for its range if sufficient erased space exists. Otherwise, it is relocated to the compacted FIT update block.
  • a host may use write_pointer and read_pointer commands to control all files in a set to have equal size, the same as the size of a metablock, and may use close and idle commands to cause a file in the set to be consolidated into a single metablock immediately after the file is closed.
  • the set of host commands includes read and write commands for a specified fileID that include companion commands for the values of the Write_pointer and Read_pointer that give the memory addresses at which the commanded data write or read is to begin.
  • FIG. 1-1 Memory Card with Direct Data File Platform
  • Figure 1-2 Direct Data File Platform Components
  • FIG. 6 Device Commands
  • Figure 3-1 Format of a Plain File
  • FIG 3-2 Format of a Common File
  • Figure 3-3 Format on an Edited Plain File
  • Figure 3-4 Format of an Edited Common File
  • FIG. 4-1 Flow Chart for Device Operations
  • FIG. 5-1 Flow Chart for Programming File Data
  • Figure 6-1 Flow Chart for Reading File Data
  • Figure 7-1 Flow Chart for Deleting a File
  • FIG. 8-1 Interleaved Operations for Foreground Garbage Collection
  • Figure 8-2 Principle of Operation for Adaptive Scheduling of Garbage Collection
  • FIG. 8-3 Flow Chart for Garbage Collection Selection
  • FIG. 8-4 Flow Chart for File Garbage Collection
  • FIG. 8-5 Flow Chart for Common Block Garbage Collection
  • FIG. 8-6 Flow Chart for Block Consolidation
  • FIG. 8-7A through 8-7D Common Block Garbage Collection Example, showing four time sequential stages
  • FIG. 9-1 Continuous Host Data Programming
  • FIG. 9-2 Interrupted Host Data Programming
  • FIG. 9-3 Buffer Flush Programming
  • FIG. 9-4 Buffer Swap-Out Programming
  • FIG. 9-5 Host Data Programming after Buffer Flush
  • FIG. 9-7 Host Data Programming after Buffer Swap-In
  • Figure 9-8 Aligned Data Read to Buffer
  • Figure 9-9 Aligned Data Programming from Buffer
  • Figure 9-12 Non- Aligned Non-Sequential Data Read to Buffer
  • Figure 9-13 Non-Aligned Non-Sequential Data Programming from Buffer
  • FIG. 1 File Indexing
  • FIG. 10-2 File Indexing Structures
  • FIG. 3 Directory Block Format
  • FIG. 10-4 File Index Table (FIT) Logical Structure
  • Figure 10-5 FIT Page Format
  • Figure 10-7 Examples of FIT File Update Operations
  • FIG. 11-1 Block State Diagram
  • FIG. 12-1 Control Block Format
  • FIG. 12-2 Common Block Log Format
  • FIG 13-1 Command Set Used with Static Files (in parts A and B that should be taken together).
  • FIG. 1-1 A memory card with a direct data file platform is illustrated in Figure 1-1.
  • the direct data file platform is a file-organized data storage device in which data is identified by filename and file offset address. It acts as the storage platform in a memory card that may incorporate functions other than data storage. File data is accessed in the platform by an external file interface channel.
  • the storage device has no logical addresses. Independent address spaces exist for each file, and the memory management algorithms organize data storage according to the file structure of the data.
  • the data storage organization employed in the direct data file platform produces considerable improvement of operating characteristics, in comparison with those of a file storage device that integrates a conventional file system with conventional logically-blocked memory management.
  • the direct data file platform has the following components, structured in layers of functionality as shown in Figure 1-2:
  • Direct Data File Interface A file API that provides access from other functional blocks in the card to data identified by filename and file offset address.
  • File-to-Flash Mapping Algorithm A scheme for file-organized data storage that eliminates file fragmentation and provide maximum performance and endurance.
  • Programming File Data Programming file data in accordance with the file-to-flash mapping algorithm.
  • Reading File Data Reading data specified by file offset address from flash memory.
  • Deleting File Identifying blocks containing data for a deleted file and adding them to garbage collection queues.
  • Garbage Collection Operations performed to recover memory capacity occupied by obsolete data. These may entail copying valid data to another location, in order to erase a block.
  • File indexing allows the locations of the valid data groups for a file to be identified, in offset address order.
  • Data Buffering & Programming The use of a buffer memory for data to be programmed, and the sequence of programming file data in program blocks.
  • Erased Block Management Management of a pool of erased blocks in the device that are available for allocation for storage of file data or control information.
  • Block State Management Transitions between the eight states into which blocks for storage of file data can be classified.
  • Control Data Structures Control data structures stored in flash blocks dedicated to the purpose.
  • the Direct Data File interface is an API to the Direct Data File platform, which forms the back-end system for flash memory management within a device incorporating flash mass data storage.
  • a file is an object that is independently identified within the device by a filelD.
  • a file may comprise a set of data created by a host, or may have no data, in which case it represents a directory or folder.
  • the create command creates an entry identified by ⁇ fileID> within the directory in the device. If the ⁇ fileID> parameter is omitted, the device assigns an available value to the file and returns it to the host. This is the normal method of creating a file.
  • the host may alternatively assign a ⁇ fileID> value to a file. This method may be used if a specific value of filelD denotes a specific type of file within the host interface protocol. For example, a root directory may be assigned a specific filelD by the host.
  • This command enables execution of subsequent data commands for the file specified by ⁇ fileID>. If the file does not exist, an error message is returned.
  • the write_pointer for the file is set to the end of the file, and the read_pointer for the file is set to the beginning of the file.
  • the info_write_pointer for the file_info is set to the end of the file_info, and the info_read_pointer for the file is set to the beginning of the file_info.
  • There is a maximum number of files that can be concurrently open If this number is exceeded, the command is not executed and an error message is returned.
  • the maximum number of concurrently open files for example, may be 8.
  • Resources within the device for writing to the specified file are made available only after receipt of a subsequent write, insert or remove command.
  • the delete command indicates that directory, file index table and info table entries for the file specified by ⁇ fileID> should be deleted. Data for the files may be erased. The deleted file may not be subsequently accessed.
  • the erase command indicates that directory, file index table and info table entries for the file specified by ⁇ fileID> should be deleted. File data must be erased before any other command may be executed. The erased file may not be subsequently accessed.
  • FiIeID values for all files in the directory may be streamed from the device in numerical order following receipt of the list_files command. FiIeID streaming is terminated when the last file is reached, and this condition may be identified by the host by means of a status command. The list_files command is terminated by receipt of any other command.
  • the data commands are used to initiate data input and output operations for a specified file, and to define offset address values within the file.
  • the specified file must have been opened by the host. If this is not the case, an error is returned.
  • ⁇ fileID> is the file handle that was returned to the host when the file was last opened.
  • the remove command deletes sequential data defined by ⁇ length> from the specified file at the offset address defined by the current value of the write_pointer.
  • the file size is reduced by ⁇ length>.
  • Data in the specified file at the offset address defined by the current value of the read_pointer may be streamed from the device following receipt of the read command.
  • Data streaming is terminated when the end of file is reached, and this condition may be identified by the host by means of a status command.
  • the read command is terminated by receipt of any other command.
  • the data is restored to the buffer when a subsequent write or insert command is received, and is programmed to flash together with data relating to the command.
  • the write_pointer command sets the writejpointer for the specified file to the specified offset address.
  • the write__pointer is incremented by the device as data is streamed to the device following a write or insert command.
  • the read_pointer command sets the read_pointer for the specified file to the specified offset address.
  • the read_pointer is incremented by the device as data is streamed from the device following a read command.
  • File_info is information generated by a host that is associated with a file. The nature and content of file_info is determined by the host, and it is not interpreted by the device. The info commands are used to initiate file_info input and output operations for a specified file, and to define offset address values within file_info. 2.1.3.1 Write_info
  • File_info streamed to the device following receipt of the write_info command overwrites file_info for the specified file at the offset address defined by the current value of the info_write_ ⁇ ointer.
  • the content and length of file_info for the specified file is determined by the host.
  • the write_info command is terminated by receipt of any other command.
  • File_info for the specified file at the offset address defined by the current value of the info_read_pointer may be streamed from the device following receipt of the read_info command.
  • File_info streaming is terminated when the end of the file_info is reached, and this condition may be identified by the host by means of a status command.
  • the read_info command is terminated by receipt of any other command.
  • the info_write_pointer command sets the info_write_pointer for the specified file to the specified offset address.
  • the info_write_pointer is incremented by the device as file_info is streamed to the device following a write_info command.
  • the info_read_pointer command sets the info_read_pointer for the specified file to the specified offset address.
  • the info_read_pointer is incremented by the device as filej ⁇ fo is streamed from the device following a read_info command.
  • Stream commands are used only with a behavioural model of the direct data file platform. Their purpose is to emulate streaming data to and from a host, in association with the data commands.
  • the stream command emulates an uninterrupted stream of data defined by ⁇ length> that should be transferred by a host to or from the platform.
  • a variable representing the remaining length of the stream is decremented by the model of the platform as data is added or removed from the buffer memory.
  • the pause command inserts a delay of length ⁇ time> that is inserted before execution of the following command in a command list that is controlling operation of the direct data file model.
  • ⁇ time> is defined in microseconds.
  • State commands control the state of the device.
  • the idle command indicates that the host is putting the direct data file device in an idle state, during which the device may perform internal housekeeping operations. The host will not deliberately remove power from the device in the idle state.
  • the idle state may be ended by transmission of any other command by the host, whether or not the device is busy with an internal operation. Upon receipt of such other command, any internal operation in progress in the device must be suspended or terminated within a specified time. An example of this time is 10 milliseconds or less.
  • the standby command indicates that the host is putting the direct data file device in a standby state, during which the device may not perform internal housekeeping operations. The host will not deliberately remove power from the device in the standby state.
  • the standby state may be ended by transmission of any other command by the host.
  • the shutdown command indicates that power will be removed from the device by the host when the device is next not in the busy state. All open files are closed by the device in response to the shutdown command.
  • Device commands allow the host to interrogate the device.
  • the device In response to the capacity command, the device reports the capacity of file data stored in the device, and the capacity available for new file data.
  • the device In response to the status command, the device reports its current status.
  • Status includes three types of busy status:
  • the device is busy performing a foreground operation for writing or reading data.
  • the device is busy performing a background operation initiated whilst the device was in the idle state.
  • the buffer memory is busy, and is not available to the host for writing or reading data.
  • Offset is a logical address within a file or file_info, in bytes, relative to the start of the file or file_info.
  • the file-to-flash mapping algorithm adopted by the direct data file platform is a new scheme for file-organized data storage that has been defined to provide the maximum system performance and maximum memory endurance, when a host performs file data write and file delete operations via a file-based interface.
  • the mapping algorithm has been designed to minimize copying of file data between blocks in flash memory. This is achieved by mapping file data to flash blocks in a manner that achieves the lowest possible incidence of blocks containing data for more than one file.
  • a file is a set of data created and maintained by the host. Data is identified by the host by a filename, and can be accessed by its offset location from the beginning of the file. The file offset address may be set by the host, and may be incremented as a write pointer by the device.
  • the direct data file platform stores all data for files in fixed-size metablocks.
  • the actual number of flash erase blocks comprising a metablock that is, the erase block parallelism, may vary between products.
  • block is used to denote “metablock”.
  • metapage is used to denote a page with the full parallelism of a metablock.
  • a metapage is the maximum unit of programming.
  • page is used to denote a page within a plane of the memory, that is, within a flash erase block.
  • a page is the minimum unit of programming.
  • ctor is used to denote the unit of stored data with which an ECC is associated.
  • the sector is the minimum unit of data transfer to and from flash memory.
  • a data group is a set of file data with contiguous offset addresses within the file, programmed at contiguous physical addresses in a single memory block.
  • a file will normally be programmed as a number of data groups.
  • a data group may have any length between one byte and one block.
  • Each data group is programmed with a header, containing file identifier information for cross reference purposes.
  • Data for a file is indexed in physical memory according to the data groups it comprises.
  • a file index table provides file offset address and physical address information for each data group of a file.
  • a file must be opened by the host to allow file data to be programmed.
  • Each open file has a dedicated block allocated as a program block, and data for that file is programmed at a location defined by a program pointer within the program block.
  • a program block for the file is opened, if one does not already exist.
  • the program pointer is set to the beginning of the program block. If a program block already exists for a file that is opened by the host, it continues to be used for programming data for the file.
  • File data is programmed in a program block in the order it is received from the host, irrespective of its offset address within the file or whether data for that offset address has previously been programmed.
  • a program block becomes full, it is known as a file block, and an erased block from the erased block pool is opened as a new program block. There is no physical address relationship between blocks storing data for a file.
  • a common block contains data groups for more than one file. If multiple data groups for the same file exist in a common block, they are located contiguously and the contiguous unit is known as a file group. Data is programmed to a common block only during a block consolidation operation or a common block garbage collection operation.
  • a plain file comprises any number of complete file blocks and one partially programmed program block.
  • a plain file may be created by the programming of data for the file from the host, usually in sequential offset address order, or by garbage collection of an edited file.
  • An example plain file is shown in Figure 3-1.
  • a plain file may be either an open file or a closed file.
  • Further data for the file may be programmed at the program pointer in the program block. If the file is deleted by the host, blocks containing its data may be immediately erased without the need to copy data from such blocks to another location in flash memory.
  • the plain file format is therefore very efficient, and there is advantage in retaining files in this format for as long as possible.
  • a common file comprises any number of complete file blocks and one common block, which contains data for the file along with data for other unrelated files. Examples are shown in Figure 3-2.
  • a common file may be created from a plain file during a garbage collection operation or by consolidation of program blocks.
  • a common file is normally a closed file, and does not have an associated write pointer. If the host opens a common file, a program block is opened and the program pointer is set to the beginning of the program block. If the file is deleted by the host, its file blocks may be immediately erased, but data for an unrelated file or unrelated files must be copied from the common block to another location in flash memory in a garbage collection operation before the common block is erased.
  • a plain file may be edited at any time by the host, which writes updated data for previously-programmed offset addresses for the file. Examples are given in Figure 3-3. Such updated data is programmed in the normal way at the program pointer in the program block, and the resulting edited plain file will contain obsolete data in one or more obsolete file blocks, or in the program block itself.
  • the edited plain file may be restored to a plain file in a garbage collection operation for the file. During such garbage collection, any valid file data is copied from each obsolete file block to the program pointer for the file, and the resultant fully-obsolete blocks are erased. The garbage collection is not performed until after the file has been closed by the host, if possible.
  • An open common file may be edited at any time by the host, which writes updated data for previously-programmed offset addresses for the file. Examples are shown in Figure 3-4. Such updated data is programmed in the normal way at the program pointer in the program block, and the resulting edited common file will contain obsolete data in one or more obsolete file blocks, in the common block, or in the program block itself.
  • the edited common file may be restored to plain file format in a garbage collection operation for the file.
  • garbage collection any valid file data is copied from each obsolete file block and the common block to the program pointer for the file.
  • the resultant fully-obsolete file blocks are erased, and the obsolete common block is logged for a separate subsequent garbage collection operation.
  • Garbage collection operations are performed to recover memory capacity occupied by obsolete data. These may entail copying valid data to another location, in order to erase a block. Garbage collection need not be performed immediately in response to the creation of obsolete data. Pending garbage collection operations are logged in garbage collection queues, and are subsequently performed at an optimum rate in accordance with scheduling algorithms.
  • the direct data file platforms supports background garbage collection operations that may be initiated by a host command. This allows a host to allocate quiescent time to the device for internal housekeeping operations that will enable higher performance when files are subsequently written by the host. [0077] If sufficient background time is not made available by the host, the device performs garbage collection as a foreground operation. Bursts of garbage collection operations are interleaved with bursts of programming file data from the host. The interleave duty cycle may be controlled adaptively to maintain the garbage collection rate at a minimum, whilst ensuring that a backlog is not built up.
  • Each plain file in the device includes an incompletely filled program block, and a significant volume of erased capacity can be locked up in such program blocks.
  • Common blocks may also contain erased capacity.
  • An ongoing process of consolidating program blocks for closed files and common blocks is therefore implemented, to control the locked erased capacity.
  • Block consolidation is treated as part of the garbage collection function, and is managed by the same scheduling algorithms.
  • Data in a program block or a common block is consolidated with data for one or more unrelated files by copying such unrelated data from another common block or program block. If the original block was a program block, it becomes a common block. It is preferable to consolidate a program block with an obsolete common block, rather than with another program block. An obsolete common block contains obsolete data, and it is therefore unavoidable to have to relocate valid data from the block to another location. However, a program block does not contain obsolete data, and copying data from the block to another location is an undesirable overhead.
  • the operating sequence of the device is determined by the flow of commands supplied by a host. When a host command is received, the current device operation is interrupted and the command is normally interpreted. Certain commands will cause execution of one of the four main device operations, as follows:
  • Data for a file is programmed to flash memory as it is streamed to the device from a host following a write or insert command from the host. When sufficient data has been accumulated in the buffer memory for the next program operation, it is programmed in the program block for the file. See chapter 9 for a description of this operation.
  • a program block When a program block becomes full, it is designated as a file block and an erased block from the erased block pool is allocated as the program block. In addition, the file index table and garbage collection queues for common blocks and obsolete blocks are updated.
  • the file data programming procedure initiates bursts of foreground garbage collection, according to interleave parameter Nl that is established by the garbage collection scheduling algorithm (see section 8.4).
  • An interleave program counter is incremented whenever a metapage program operation is initiated in flash memory, and a garbage collection operation in foreground mode is initiated when this counter exceeds the value Nl.
  • FIG. 5-1 A flow chart illustrating an example of programming file data appears as Figure 5-1.
  • FIT file index table
  • File data is read in units of one metapage until the end of file is reached, or until the host transmits another command.
  • FIT entries for the file are evaluated, initially to identify a common block that may contain data for the file. Thereafter, FIT entries for the file are evaluated in offset address order, and the data blocks in which data groups are located are added to either the common block queue or the obsolete block queue, for subsequent garbage collection. The file directory and file index table are then updated, to remove entries for the file.
  • the main device operations sequence then ensures that garbage collection operations for these blocks are performed before any other host command is executed. This ensures that data for the file identified by the erase command is immediately erased.
  • FIG. 7-1 A flow chart of a file deletion process appears as Figure 7-1.
  • Garbage collection is an operation that must be performed to recover flash memory capacity occupied by obsolete file data. Garbage collection may be necessary as a result of deletion of a file or of edits to the data of a file.
  • Block consolidation is a form of garbage collection, which is performed to recover erased capacity in blocks that are incompletely filled with file data, to allow their use for storing unrelated files. Consolidation may be performed on program blocks in plain files, to convert them to common blocks, or on common blocks, to reduce their number.
  • garbage collection and block consolidation relocated valid file data from a source flash block to one or more destination blocks, as dictated by the file-to-flash mapping algorithm, to allow the source block to be erased.
  • Pending garbage collection operations are performed not immediately, but according to a scheduling algorithm for phased execution. Entries for objects requiring garbage collection are added to three garbage collection queues from time to time during operation of the device. Separate queues exist for files, obsolete blocks, and common blocks. Objects are selected from the queues for the next garbage collection operation in a predefined order of priority. If the queues are empty, block consolidation may be performed.
  • Garbage collection operations may be scheduled in two ways. Background operations may be initiated by the host when it is not making read or write access to the device, and are executed continuously by the device until the host makes another access. Foreground operations may be scheduled by the device whilst it is being accessed by the host, and are executed in bursts interleaved with bursts of program operations for file data received from the host. The lengths of the interleaved bursts may be adaptively controlled to maintain the garbage collection rate to the minimum required at all times.
  • Garbage collection queues contain entries for objects for which there is a pending garbage collection operation. Three queues each contain entries for obsolete blocks, common blocks and files, respectively. Two additional queues are given higher priority than these three, and contain entries for obsolete blocks and common blocks respectively. The five garbage collection queues are stored in the control log in the control block in flash memory. 8.2.1 Priority Obsolete Block Queue
  • This queue contains entries for blocks that have been made fully obsolete as a result of an erase command from the host. It is the highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue must be completed before any other command is accepted from the host, or before garbage collection operations are initiated on objects from any other queue.
  • This queue contains entries for common blocks that have been made partially obsolete as a result of an erase command from the host. It is the second highest priority garbage collection queue. Garbage collection operations on all common blocks identified in the queue must be completed before any other command is accepted from the host, or before garbage collection operations are initiated on objects from a lower priority queue.
  • This queue contains entries for blocks that have been made fully obsolete as a result of a delete command from the host, or of edits to the data of a file. It is the third highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue should be completed before operations are initiated on objects from a lower priority queue.
  • This queue contains entries for common blocks that have been made partially obsolete as a result of a delete command from the host, or of edits to the data of a file. It is the fourth highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue should be completed before operations are initiated on objects from a lower priority queue.
  • This queue contains entries for files that have obsolete data as a result of edits to the data of a file. It is the lowest priority garbage collection queue. When a file is closed by the host, an entry for it is added to the file queue unless the file is a plain file. It is therefore necessary to perform an analysis on the FIT entries for a file at the time the file is closed by the host, to determine if the file is a plain file or an edited file (plain or common).
  • the FIT entries in the relevant FIT file are evaluated in offset address order.
  • the physical capacity occupied by file data is determined. This is the number of blocks other than the program block containing data for the file, plus the used capacity in the program block.
  • the file is determined to be a plain file.
  • An example of the value of X is 98%. X% is less than 100%, to allow for unprogrammed space resulting from a buffer flush operation to persist in a plain file.
  • An obsolete block contains only obsolete data, and may be erased without the need to relocate data to another block.
  • the common block is the source block, and contains one or more partially or fully obsolete data groups for one or more files. Valid data must be relocated from this source block to one or more destination blocks.
  • Data is relocated in units of a complete file group, where a file group comprises one or more data groups for the same file within the common block. Each file group is relocated intact to a destination block, but different file groups may be relocated to different blocks.
  • a common block is the preferred choice for destination block, followed by program block if no suitable common block is available, followed by an erased block if no suitable program block is available.
  • the garbage collection operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
  • FIG. 8-5 A flow chart for the common block garbage collection operation is shown in Figure 8-5.
  • File garbage collection is performed to recover capacity occupied by obsolete data for the file. It restores a file in the edited plain file state or edited common file state to the plain file state.
  • the first step is to perform an analysis on the FIT entries in its FIT file, to identify obsolete file blocks and common block from which data groups must be copied during the garbage collection. The procedure for this analysis is as follows:
  • the FIT entries in the relevant FIT file are evaluated in offset address order.
  • a data group list is constructed to relate data groups to physical blocks. Data groups in the program block are excluded from this list.
  • the block is determined to be a file block.
  • An example of the value of X is 98%. X% is less than 100%, to allow for unprogrammed space resulting from a buffer flush operation to persist in a file block.
  • Data groups referenced in the revised data group list are contained in obsolete file blocks or a common block, and are copied to a program block during the file garbage collection operation.
  • the data group structure of the file may be modified as a result of the file garbage collection operation, that is, a relocated data group may be split into two by a block boundary, or may be merged with an adjacent data group.
  • the program block for the file is used as the destination block. When this is filled, another program block is opened.
  • the garbage collection operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
  • FIG. 8-4 A flow chart for the file garbage collection operation is shown in Figure 8-4.
  • Block consolidation is performed to recover erased capacity in program blocks and common blocks that have been incompletely programmed, and to make the capacity available for storing data for other files.
  • the source block for a consolidation is selected as the block in the program block log or common block log with the lowest programmed capacity, to allow the block to be erased after the minimum possible data relocation.
  • Data is relocated in units of a complete file group, where a file group comprises one or more data groups for the same file within the program block or common block. Each file group is relocated intact to a destination block, but different file groups may be relocated to different blocks.
  • a common block is the preferred choice for destination block, followed by program block if no suitable common block is available. In the rare event that no destination block is available, a file group may be split to be relocated to more than a single destination block.
  • the block consolidation operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
  • FIG. 8-6 A flow chart for a block consolidation operation is shown in Figure 8-6.
  • Garbage collection is preferably performed as a background task during periods when the host device is accessing the card. Background garbage collection initiated by the host is supported in the direct data file platform. [00126] However, it may also be necessary to perform garbage collection as a foreground task whilst the host is writing data to the device. In this mode, a complete garbage collection operation need not be completed as a single event. Bursts of garbage collection can be interleaved with bursts of programming data from a host, such that a garbage collection operation may be completed in a number of separate stages and there is limited interruption to availability of the device to the host.
  • Background garbage collection is initiated when the host sends an idle command to the device. This indicates that the host will not deliberately remove power from the device, and does not immediately intend to access the device. However, the host may end the idle state at any time by transmitting another command.
  • the device performs continuous garbage collection operations until the occurrence of one of the following conditions; the host transmits another command, or all garbage collection queues are empty and no block consolidation operations are possible.
  • Interleaved garbage collection operations are initiated by the direct data file process for programming file data.
  • An interleaved operation is illustrated in Figure 8- 1.
  • the device switches into a garbage collection phase. In this phase, part of one or more garbage collection operations are performed until N2 program operations to flash memory are completed.
  • a garbage collection operation in progress may be suspended at the end of a garbage collection phase, and restarted in the next such phase.
  • the values of Nl and N2 are determined by an adaptive scheduling algorithm.
  • An adaptive scheduling method is used to control the relative lengths of interleaved bursts of host data programming and garbage collection, so that the interruption to host data write operations by garbage collection operations can be kept to a minimum. This is achieved whilst also ensuring that a backlog of pending garbage collection that could cause subsequent reduction in performance is not built up.
  • the device state comprises capacity occupied by previously written host data, erased capacity in blocks in the erased block pool, and recoverable capacity that can be made available for writing further host data by garbage collection operations.
  • This recoverable capacity may be in program blocks, common blocks, or obsolete file blocks shared with previously written host data, or in fully obsolete blocks.
  • Adaptive scheduling of garbage collection controls the interleave ratio of programming incremental host data and relocating previously written host data, such that the ratio can remain constant over an adaptive period during which all recoverable capacity can be made available for host data. If the host deletes files, which converts previously written host data to recoverable capacity, the interleave ratio is changed accordingly and a new adaptive period started.
  • the optimum interleave ratio can be determined as follows:
  • the number of erased blocks in the erased block pool erased Jplocks
  • the number of metapages relocated during garbage collection is given by datajpages * (datajolocks - datajpages I pages jper_block) I data_blocks
  • the optimum interleave ratio N1:N2 is the ratio of the number of incremental data metapages that may be written to the number of metapages that must be relocated during garbage collection. Therefore,
  • N1:N2 (pages jper_block * ( erasedjblocks + obsolete _blocks + data_blocks) — datajpages) / (datajpages * (datajblocks — datajpages I pages jperjblock) I data_ blocks)
  • the interleave ratio N1:N2 is defined in three bands, as follows.
  • a maximum limit to the interleave ratio is set, to ensure that garbage collection can never be totally inhibited.
  • An example of this maximum limit is 10 to 1.
  • N1:N2 (pages _per_block * (erased _blocks + obsolete Jblocks + data_ blocks) - data_pages) / (datajpages * (data_blocks - data j pages I pages jper_hlock) I datajblocks), where Nl and N2 are defined as numbers of page program operations.
  • a value of N2 is defined, representing the preferred duration of a burst of garbage collection. An example of this value is 16.
  • the interleave ratio is not adaptively defined, but is set to a fixed minimum limit.
  • An example of this minimum limit is 1 to 10.
  • Erased block count A count of the number of blocks in the erased block pool is maintained. This is updated when blocks are added to and removed from the erased block pool.
  • Program & common block count A count of the combined number of program blocks and common blocks is maintained. Common blocks may contain obsolete data. The count is updated when blocks are added to and removed from the program block log and the common block log.
  • Program & common block page count A count of the number of valid data pages in program blocks and common blocks is maintained. The count is updated when blocks are added to and removed from the program block log and the common block log.
  • Obsolete block count A count of the number of fully obsolete blocks awaiting garbage collection is maintained. The count is updated when blocks are added to and removed from the obsolete block garbage collection queue.
  • Figure 8-3 A flow chart of a specific algorithm for selecting one of several particular garbage collection operations is given in Figure 8-3.
  • Figure 8-4 is a flow chart for the "File garbage collection” block of Figure 8-3.
  • a flow chart for the "Common block garbage collection” block of Figure 8-3 is the subject of Figure 8-5.
  • the "Block consolidation" function of Figure 8-3 is shown by the flow chart of Figure 8-6.
  • Figures 8-7A through 8-7D show an example garbage collection of a common block that can result from the process of Figure 8-5.
  • Figure 8-7A shows an initial condition
  • Figures 8-7B through 8-7C illustrate three steps in the garbage collection process.
  • the arrows show the transfer of valid data from obsolete blocks into file blocks that are not full, and these destination file blocks then become common blocks.
  • a buffer memory exists in SRAM in the controller (RAM 31 of the Prior Applications), for temporary storage of data being programmed to and read from flash memory.
  • An allocated region of the buffer memory is used to accumulate sufficient data for a file to allow a full metapage to be programmed in a single operation in flash memory.
  • the offset addresses of data for a file in the buffer memory is unimportant.
  • the buffer memory may store data for multiple files.
  • the buffer memory comprises a set of sector buffers. Individual sector buffers may be allocated for temporary storage of data for a single file, and deallocated when the data has been transferred to its final destination. Sector buffers are identified by a sector buffer number 0 to N-I. An example of the number of sector buffers (N) is 64.
  • Available sector buffers are allocated cyclically in order of their sector buffer number. Each sector buffer has a file label, and two associated pointers defining the start and end of data contained within it. File offset address ranges within the data in the sector buffer are also recorded. Both the sector buffers and the control information associated with them exist only within volatile memory in the controller.
  • a metapage is the maximum unit of programming in flash memory. Data should be programmed in units of a metapage wherever possible, for maximum performance.
  • a page is a subset of a metapage, and is the minimum unit of programming in flash memory.
  • a sector is a subset of a page, and is the minimum unit of data transfer between controller and flash memory.
  • a sector usually comprises 512 bytes of file data.
  • An ECC is generated by the controller for each sector (such as by the controller ECC circuit 33 of Figure 2 of the Prior Applications), and is transferred to flash appended to the end of the sector. When data is read from flash, it must be transferred to the controller in multiples of a complete sector, to allow the ECC to be checked.
  • Data for a file is normally accumulated in sector buffers until sufficient data is available for programming a complete metapage in flash memory.
  • one or more sector buffers remain with file data for part of a metapage. This data remains in buffer memory, to allow the host to write further data for the file.
  • data in buffer memory must be committed to flash memory in an operation known as a buffer flush.
  • a buffer flush operation causes all data for a file that is held in sector buffers to be programmed in one or more pages within a metapage.
  • a buffer flush operation is performed in the following two events:
  • a shut-down command is received by the host.
  • data for a file that is closed by the host has been swapped-out to the swap block, it should be restored to the buffer memory and a buffer flush should be performed. Data that is in the swap block during initialization of the device following power removal should be restored to the buffer memory and a buffer flush should be performed.
  • Buffer swap is an operation in which data for a file in one or more sector buffers is programmed in a temporary location known as a swap block, to be subsequently restored to buffer memory when the host continues writing data for the file.
  • the swap block is a dedicated block that stores data for files that has been swapped-out from sector buffers. Data for a file is stored contiguously in one or more pages dedicated to that file in the swap block. When data is subsequently swapped-in back to buffer memory, it becomes obsolete in the swap block.
  • a swap block index is maintained in flash memory, containing for each file in the swap block a copy of the information previously recorded for the file in the buffer memory (see 9.1).
  • a swap-out operation occurs when insufficient sector buffers are available to be allocated to a file that has been opened by the host, or to a file that must be swapped-in from the swap block as a result of a write command for the file from the host.
  • the file selected for swap-out should be the least recently written file of those for which buffers exist in the buffer memory.
  • a swap-out may be performed for any file in the buffer memory which is not related to the most recent write command from the host. In this case, data for the file may remain in buffer memory, and a subsequent swap-in operation is not required if there has not been a removal of power.
  • the complete data for a file is read from the swap block to one or more sector buffers.
  • the file data need not have exactly the same alignment to sector buffers as before its swap-out. Alignment may have changed as a result of a compaction of the swap block. Data for the file in the swap block becomes obsolete.
  • Examples given in this section relate to a flash memory configuration with two pages per metapage, and two sectors per page.
  • Data for a file is streamed from a host and is accumulated in successively allocated sector buffers. When sufficient sector buffers have been filled, their data is transferred to flash memory together with an ECC for each sector, and the destination metapage in the program block for the file is programmed.
  • An example of continuous host data programming is shown in Figure 9-1.
  • FIG. 9-2 shows an example of host data programming that has been interupted. The stream is interrupted after data segment 2A, whilst a write operation for a different file is executed. When a further write command for the file is received, data streamed from the host is accumulated in the same sector buffer as before, beginning at data segment 2B. When sufficient sector buffers have been filled, their data is transferred to flash memory together with an ECC for each sector, and the destination metapage in the program block for the file is programmed.
  • Data for a file is streamed from a host and is accumulated in successively allocated sector buffers. However, insufficient data is present to be programmed in a complete metapage. An example is given in Figure 9-3. Data segments 1 and 2A, together with padding segment 2B, is transferred to flash memory together with an ECC for each sector, and the destination page in the program block for the file is programmed.
  • File data supplied by a host subsequent to a buffer flush operation for the file is programmed separately from the data flushed from buffer memory. Programming must therefore begin at the next available page in the program block for the file. Sufficient data is accumulated to complete the current metapage, and it is transferred with ECC and programmed as shown for sectors 3 and 4 of Figure 9-5.
  • file data from the host is accumulated in buffer sectors.
  • Data segments 1, 2A/2B, 3A/3B and 4A/4B are transferred to flash memory together with ECC for each sector, and are programmed as sectors 1, 2, 3 and 4.
  • Source and destination metapages are said to be aligned when data to be copied to a full destination metapage occupies a single full source metapage, as illustrated in Figure 9-8.
  • Data sectors 1, 2, 3 and 4 are read from the source metapage to four sector buffers, and the ECC is checked on each sector.
  • on-chip copy within the flash chip may be used to increase the speed of the copy operation.
  • Data is programmed to the destination metapage if the ECC check shows no error.
  • the start of each file group within a common block should be forced to align with start of metapage.
  • Data groups in a program block also align with the start of the first metapage in the block. Therefore, all data copy operations for a common block, such as consolidating program blocks into a common block and copying file groups from one common block to a program block or to another common block, will operate with data copy between aligned metapages.
  • On-chip copy within the flash chip should be used when copying data to or from a common block to increase the speed of the copy operation.
  • Source and destination metapages are said to be non-aligned when data to be copied to a full destination metapage is contiguous, but occupies two sequential source metapages.
  • An example of reading the source metapage is shown in Figure 9- 10.
  • Data sectors lA/lB, 2, and 3 are read from the first source metapage to three sector buffers, and data sectors 4 and 5A/5B are read from the second source metapage to a further two sector buffers.
  • the ECC is checked on each sector.
  • Data portions 1A/1B, 2A/2B, 3A/3B, and 4A/4B are programmed from the sector buffers to sectors 1, 2, 3 and 4 in the destination metapage, as shown if Figure 9-11.
  • An ECC is generated and stored for sectors 1, 2, 3 and 4.
  • the copy may be partially pipelined. Data is read from the source location to the buffer memory in full metapages. N+l source metapages must be read in order to program N destination metapages.
  • Source and destination metapages are said to be non-aligned and nonsequential when data to be copied to a full destination metapage is not contiguous, and occupies two or more non-sequential source metapages. This case represents copying part of two or more non-contiguous data groups within a file to a single destination metapage.
  • Data sectors 1A/1B, 2, and 3A/3B, as shown in Figure 9-12, are read from the first source metapage to three sector buffers, and data sectors 4A/4B and 5A/5B are read from the second source metapage to a further two sector buffers. The ECC is checked on each sector.
  • Data portions 1A/1B, 2A/2B, 3A/3B, and 4A/4B are then programmed from the sector buffers to sectors 1, 2, 3 and 4 in the destination metapage, as shown in Figure 9-13.
  • An ECC is generated and stored for sectors 1, 2, 3 and 4.
  • File indexing is shown generally in Figure 10-1.
  • Data for a file is stored as a set of data groups, each spanning a run of contiguous addresses in both file offset address space and physical address space. Data groups within the set for a file need not have any specific physical address relationship with each other.
  • a file index table (FIT) allows the locations of the valid data groups for a file to be identified, in offset address order.
  • a set of FIT entries for a file is identified by a file data pointer.
  • Information associated with a file that is generated by a host is stored as file_info in an info table (IT). The nature and content of file_info is determined by the host, and it is not interpreted by the device. File_info may include filename, parent directory, child directories, attributes, rights information, and file associations for a file. File_info for a file in the IT is identified by a file info pointer.
  • a directory contains a file data pointer and file info pointer for every valid file in the device. These directory entries for a file are identified by a filelD, which is a numerical value.
  • Figure 10-2 shows an example of the file indexing structures.
  • the filelD is a numerical identifier for a file existing within the direct data file platform. It is allocated by the direct data file platform in response to a create command, or may be specified as a parameter with a create command.
  • a cyclic pointer to entries in the directory is used to locate the next available filelD.
  • the directory entry identified by the file's filelD is marked as available.
  • a filelD value defines an entry in the directory, which contains fields for the file data pointer and file info pointer for a file.
  • the maximum number of files that may be stored in the device is determined by the number of bits allocated for the filelD.
  • a file data pointer is a logical pointer to an entry for a file in the FIT block list, and possibly also the FIT update block list, within the control log.
  • a file data pointer has two fields:
  • a file data pointer for a file exists even when the file has zero length.
  • a FIT range is a subset of the FIT. Each FIT range is mapped to a separate physical FIT block. A FIT range may contain between one FIT file and a maximum number of FIT files, which may be 512, for example.
  • a FIT file no. is a logical number used to identify a FIT file within the FIT.
  • a file info pointer is a logical pointer to an entry for a file in the info block list, and possibly also the info update block list, within the control log.
  • a file info pointer has two fields:
  • An info range is a subset of the info table. Each info range is mapped to a separate physical info block. An info range may contain between one set of file_info and a maximum number of sets of file_info, which may be 512, for example.
  • An info no. is a logical number used to identify a set of file_info within the info block.
  • the directory is stored in a flash block dedicated to the purpose.
  • Figure 10-3 shows an example directory block format.
  • the directory is structured as a set of pages, within each of which a set of entries exists for files with consecutive fileID values. This set of entries is termed a directory range.
  • the directory is updated by writing a revised version of a directory page at the next erased page location defined by a control pointer. Multiple pages may be updated simultaneously, if necessary, by programming them to different pages in a metapage.
  • Both the File Index Table and the Info Table comprise a series of logical ranges, where a range has a correlation with a physical flash block.
  • Block lists are maintained in the control log to record the correlations between range defined in a file data pointer or file info pointer and a physical block, and between logical number defined in a file data pointer or file info pointer and the logical number that is used in physical blocks within the File Index Table and the Info Table.
  • the FIT Block List is a list in the control log that allocates a FIT file pointer for entries in the FIT for a file.
  • the FIT file pointer contains the address of the physical flash block that is allocated to the range defined in a file data pointer, and the same FIT file number that is defined in the file data pointer.
  • An entry in the FIT block list contains a single field, a block physical address.
  • the FIT Update Block List is a list in the control log that allocates a FIT file pointer for entries for a file in the FIT that are being updated.
  • the FIT file pointer contains the address of the physical flash block that is currently allocated as the FIT update block entry, and the FIT update file number that is allocated in the FIT update block to the FIT file being updated.
  • An entry in the FIT update block list contains three fields:
  • FIT update file number is searched to determine if an entry relating to the file data pointer is present. If none exists, the entry relating to the file data pointer in the FIT block list is valid.
  • File_info written by a host is stored directly in the info table, identified by a file info pointer.
  • Info block lists exist to allocate an info pointer to file_info in the info table.
  • the indexing mechanisms for these info block lists is completely analogous to those described for the FIT block lists.
  • An entry in the info block list contains a single field, a block physical address.
  • An entry in the info update block list contains three fields:
  • the File Index Table comprises a string of FIT entries, where each FIT entry identifies the file offset address and the physical location in flash memory of a data group.
  • the FIT contains entries for all valid data groups for files stored in the device. Obsolete data groups are not indexed by the FIT.
  • An example FIT logical structure is given in figure 10-4.
  • a set of FIT entries for data groups in a file is maintained as consecutive entries, in file offset address order.
  • the set of entries is known as a FIT file.
  • the FIT is maintained as a series of FIT ranges, and each FIT range has a correlation with a physical flash block.
  • the number of FIT ranges will vary, depending on the number of data groups in the device. New FIT ranges will be created and FIT ranges eliminated during operation of the device.
  • the FIT block lists are used to create a FIT file pointer from the file data pointer, by which a location in the FIT may be identified. 10.5.1 FIT FiIe
  • a FIT file is a set of contiguous FIT entries for the data groups within a file. The entries in the set are in order of file offset address. FIT entries in a FIT file are consecutive, and are either contained within a single FIT range, or overflow from one FIT range to the next consecutive FIT range.
  • the first entry in a FIT file is the FIT header. It has three fields:
  • the FIT header has a fixed length equal to an integral number of FIT entries. This number may be one.
  • the fileID identifies the entry for the file in the directory.
  • the current physical location of the program block for a file is recorded in the FIT header whenever an updated version of the FIT file is written in the FIT. This is used to locate the program block for a file, when the file is re-opened by the host. It may also be used to validate the correspondence between a FIT file and the program block for the file, which has been selected for program block consolidation.
  • the current value of the program pointer within the program block for a file is recorded in the FIT header whenever an updated version of the FIT file is written in the FIT. This is used to define the location for programming data within the program block for a file, when the file is re-opened by the host, or when the program block has been selected for program block consolidation.
  • a FIT entry specifies a data group. It has four fields: 1) Offset address,
  • the offset address is the offset in bytes within the file relating to the first byte of the data group.
  • the pointer has two fields:
  • Block address defining the physical block containing the data group
  • the EOF flag is a single bit that identifies a data group as being the end of file.
  • a FIT range is mapped to a single physical block, known as a FIT block. Updated versions of data in these blocks is programmed in a common update block, known as a FIT update block. Data is updated in units of one page. Multiple pages within a metapage may be updated in parallel, if necessary.
  • a FIT file is identified by a FIT file pointer.
  • the FIT file number field within this pointer is a logical pointer, which remains constant as data for a FIT file is moved within the physical structures used for indexing. Pointer fields within the physical page structures provide logical to physical pointer translation.
  • a page is subdivided into two areas, the first for FIT entries and the second for file pointers.
  • An example is given in Figure 10-5.
  • the first area contains FIT entries that each specifies a data group or contains a FIT header for a FIT file.
  • An example of the number of FIT entries in a FIT page is 512.
  • a FIT file is specified by a contiguous set of FIT entries, within one FIT page or overlapping two or more FIT pages.
  • the first entry of a FIT file, containing a FIT header, is identified by a file pointer in the second area.
  • the second area contains valid file pointers only in the FIT page that was most recently programmed.
  • the second area in all other pages is obsolete, and is not used.
  • the file pointer area contains one entry for each FIT file that may be contained in the FIT block, that is, the number of file pointer entries is equal to the maximum number of FIT files that may exist in a FIT block.
  • File pointer entries are stored sequentially, according to FIT file number.
  • the Nth file pointer entry contains a pointer to FIT file N within the FIT block. It has two fields:
  • Entry number specifying a FIT entry within the physical page.
  • the file pointer entries provide the mechanism for translating a logical FIT file number within a FIT block to a physical location within the block.
  • the complete set of file pointers is updated when every FIT page is programmed, but is only valid in the most recently programmed page.
  • a FIT file is updated in the FIT update block, its previous location in either the FIT block or FIT update block becomes obsolete, and is no longer referenced by a file pointer.
  • the file data pointer is a logical pointer to a FIT file. Its FIT range field is used to address a FIT block list to identify the physical block address of the FIT block that is mapped to this FIT range. The FIT file number field of the FIT file pointer then selects the correct file pointer for the target FIT file in the FIT block.
  • Both FIT range field and FIT file number field of the file data pointer are used to address a FIT update block list, to identify if the target FIT file has been updated. If an entry is found in this list, it provides the physical block address of the FIT update block, and the FIT file number within the update block of the updated version of the FIT file. This may be different from the FIT file number used for the FIT file in the FIT block.
  • the FIT update block contains the valid version of the FIT file, and the version in the FIT block is obsolete.
  • a FIT block is programmed only during a consolidation operation. This results in the FIT files being close packed within the block.
  • a FIT update block is updated when FIT entries are modified, added or removed, and during a compaction operation.
  • Figure 10-7 shows examples of update operations on FIT files.
  • FIT files are closely packed in the FIT block, as a result of a consolidation operation.
  • the FIT block may not be entirely filled, as there is a maximum number of FIT files that can exist within it.
  • FIT files may overflow from one page to the next.
  • a FIT file in a FIT block becomes obsolete when it is updated and rewritten in the FIT update block.
  • FIT file When a FIT file is updated, it is rewritten in its entirety in the next available page in the FIT update block. Updating a FIT file may consist of either changing the content of existing FIT entries, or changing the number of FIT entries. FIT files may overflow from one page to the next. The FIT files within a FIT update block need not all relate to the same FIT range.
  • a FIT block is not immediately created. New data within this range is initially written to the FIT update block. A FIT block is subsequently created when a consolidation operation is performed for the range.
  • FIT update block When a FIT update block becomes filled, its valid FIT file data may be programmed in compacted form to an erased block, which then becomes the update block. There may be a little as one page of compacted valid data to be programmed, if updates have related to only a few files.
  • the FIT file to be relocated in the compaction operation relates to a closed file, and the FIT block for the range contains sufficient unprogrammed pages, the FIT file may be relocated to the FIT block, rather than to the compacted update block.
  • FIT entries When FIT entries are updated, the original FIT file in the FIT block becomes obsolete. Such FIT blocks should undergo garbage collection periodically, to recover obsolete space. This is achieved by means of a consolidation operation. In addition, new files may have been created within a range and have entries in an update block, but no corresponding obsolete entries in the FIT block may exist. Such FIT files should be relocated to the FIT block periodically.
  • FIT files in an update block may be consolidated into a FIT block for the relevant range, and therefore be eliminated from the update block, whilst other FIT files remain in the update block.
  • a consolidation operation for a range should be performed when the capacity of valid data for that range in a FIT update block reaches a defined threshold. An example of this threshold is 50%.
  • Compaction should be performed in preference to consolidation for active FIT files relating to files that are still open, and which the host may continue to access.
  • the info table uses the same structures, indexing mechanisms and update techniques that are defined for the File Index Table in section 10.5.
  • file_info for a file comprises a single string of information that is not interpreted within the direct data file platform.
  • a data group is a set of file data with contiguous offset addresses for a file, programmed at contiguous physical addresses in a single memory block.
  • a file will normally be programmed as a number of data groups.
  • a data group may have any length between one byte and one block.
  • Each data group is programmed with a header, containing file identifier information for cross reference purposes.
  • the header contains the FIT file pointer for the file of which the data group forms part.
  • Blocks for storage of file data can be classified in the following eight states, as shown in the state diagram of Figure 11-1.
  • An erased block is in the erased state in an erased block pool. A possible transition from this state is as follows:
  • a program block is partially programmed with valid data for a single file, and contains some erased capacity.
  • the file may be either open or closed. Further data for the file should be programmed to the block when supplied by the host, or when copied during garbage collection of the file.
  • Data for a single file is programmed to a program block for that file, when it is supplied from the host or when it is copied during garbage collection for the file.
  • Data for a single file from the host is programmed to fill a program block for that file.
  • All data for a file in a program block becomes obsolete, as a result of valid data being copied to another block during garbage collection, or of all or part of the file being deleted by the host.
  • Part of the data in a program block becomes obsolete as a result of an updated version of the data being written by the host in the same program block, or of part of the file being deleted by the host.
  • Residual data for a file is programmed to a program block for a different closed file during garbage collection of the file or of a common block, or during consolidation of program blocks.
  • a file block is filled with fully valid data for a single file. [00245] Possible transitions from this state are as follows:
  • Part of the data in a file block becomes obsolete as a result of an updated version of the data being programmed by the host in a program block for the file.
  • All data in a file block becomes obsolete, as a result of an updated version of the data in the block being programmed by the host in a program block for the file, or of all or part of the file being deleted by the host.
  • An obsolete file block is filled with any combination of valid data and obsolete data for a single file.
  • All data in an obsolete file block becomes obsolete, as a result of an updated version of valid data in the block being programmed by the host in a program block for the file, of valid data being copied to another block during garbage collection, or of all or part of the file being deleted by the host.
  • An obsolete program block is partially programmed with any combination of valid data and obsolete data for a single file, and contains some erased capacity. Further data for the file should be programmed to the block when supplied by the host. However, during garbage collection, data for the file should not be copied to the block and a new program block should be opened.
  • Data for a single file is programmed to an obsolete program block for that file, when it is supplied from the host.
  • Data for a single file is programmed to fill an obsolete program block for that file, when it is supplied from the host.
  • a common block is programmed with valid data for two or more files, and normally contains some erased capacity. Residual data for any file may be programmed to it during garbage collection or consolidation of program blocks.
  • Residual data for a file is programmed to a common block during garbage collection of the file or a common block, or during consolidation of program blocks.
  • Part or all of the data for one file in a common block becomes obsolete as a result of an updated version of the data being programmed by the host in a program block for the file, of the data being copied to another block during garbage collection of the file, or of all or part of the file being deleted by the host.
  • An obsolete common block is programmed with any combination of valid data and obsolete data for two or more files, and normally contains some erased capacity. Further data should not be programmed to the block.
  • Data for all files in an obsolete common block becomes obsolete as a result of an updated version of the data for one file being programmed by the host in a program block for the file, of the data for one file being copied to another block during garbage collection of the file, or of all or part of one file being deleted by the host.
  • An obsolete block contains only obsolete data, but is not yet erased.
  • An obsolete block is erased during garbage collection, and added back to the erased block pool.
  • the erased block pool is a pool of erased blocks in the device that are available for allocation for storage of file data or control information. Each erased block in the pool is a metablock, and all metablocks have the same fixed parallelism.
  • Erased blocks in the pool are recorded as entries in the erased block log in the control block. Entries are ordered in the log according to the order of erasure of the blocks. An erased block for allocation is selected as the entry at the head of the log. An entry is added to the tail of the log when a block is erased.
  • Control data structures are stored in flash blocks dedicated to the purpose. Three classes of blocks are defined, as follows:
  • the control block stores control information in four independent logs. A separate page is allocated for each of the logs. This may be extended to multiple pages per log, if necessary.
  • An example format of a control block is shown in Figure 13-1.
  • a log is updated by writing a revised version of the complete log at the next erased page location defined by a control pointer. Multiple logs may be updated simultaneously, if necessary, by programming them to different pages in a metapage. The page locations of the valid versions of each of the four logs are identified by log pointers in the last written page in the control block.
  • the common block log records information about every common block existing in the device.
  • the log entries in the common block log are subdivided into two areas, the first for block entries and the second for data group entries, as illustrated in Figure 13-2.
  • Each block entry records the physical location of a common block. Entries are fixed size, and a fixed number exist in the common block log. Each entry has the following fields:
  • a data group entry records information about a data group in a common block.
  • a set of contiguous data group entries defines all data groups in a common block. There is a variable number of data groups in a common block.
  • Each entry preferably has the following fields: 1) Byte address within common block, and
  • the program block log records information about every program block existing in the device for closed files. One entry exists for each program block, and has the following fields:
  • the erased block log records the identity every erased block existing in the device. One entry exists for each erased block. Entries are ordered in the log according to the order of erasure of the blocks. An erased block for allocation is selected as the entry at the head of the log. An entry is added to the tail of the log when a block is erased. An entry has a single field: Block physical address.
  • control log records diverse control information in the following fields:
  • This field contains information about each of the currently open files, as follows:
  • This field contains the total number of common blocks recorded in the common block log. 13.3.4.3 Program Block Count
  • This field contains the total number of program blocks recorded in the program block log. The count is updated when blocks are added to and removed from the program block log.
  • This field contains the total number of erased blocks recorded in the erased block log. The count is updated when blocks are added to and removed from the erased block log.
  • This field contains a count of the number of valid data pages in program blocks and common blocks. The count is updated when blocks are added to and removed from the program block log and the common block log.
  • This field contains a count of the number of fully obsolete blocks awaiting garbage collection. The count is updated when blocks are added to and removed from the obsolete block garbage collection queue.
  • This field contains information for mapping FIT range to FIT block. It contains an entry defining FIT block physical address for each FIT range.
  • This field contains information for mapping FIT range and FIT file number to FIT update file number. It contains an entry for each valid FIT file that exists in the update block. An entry has the following three fields:
  • This field contains information for mapping directory range to directory block. It contains an entry defining directory block physical address for each directory range. 13.3.4.10 Directory Update Block List
  • This field contains information for mapping directory range and subdirectory number to update subdirectory number. It contains an entry for each valid subdirectory that exists in the update block. An entry has the following three fields:
  • This field contains an index of valid data groups in the swap block.
  • the index for each data group contains the following fields:
  • This field contains the block addresses of all blocks in the priority obsolete block queue for garbage collection.
  • This field contains the block addresses of all blocks in the priority common block queue for garbage collection.
  • This field contains the block addresses of all blocks in the obsolete block queue for garbage collection.
  • This field contains the block addresses of all blocks in the common block queue for garbage collection.
  • This field contains the FIT file pointers of all files in the file queue for garbage collection. 14. Static Files
  • Some hosts may store data in a direct data file device by creating a set of files with identical sizes, and updating data periodically within files in the set.
  • a file that is part of such a set is termed a static file.
  • the host may be external to the memory card or may be a processor within the memory card that is executing an on- card application.
  • the direct data file device manages the storage of a static file in exactly the same way as for any other file.
  • the host may use commands in the direct data file command set in a way that optimizes behavior and performance of the device with static files.
  • Static files are stored as a set in a dedicated partition in the device. All static files in a partition have identical file size.
  • File size is defined by host, via the range of offset addresses written to the file.
  • Static files have a size equal to the size of a metablock.
  • the host manages the file offset values represented by the write_pointer and readjpointer, to maintain them within the range of values permitted for a static file at all times.
  • the host does not delete a static file during normal operation.
  • a static file is created by the host, then exists continuously in the device. Data written at any time to the file overwrites existing file data.
  • a host always has the ability to delete a static file, for example, during an operation by the host to reformat the device or to reduce the size of the partition for static files in the device.
  • Figure 14-1 gives a command set for use with static files, a subset of that shown in Figures 2-1 through 2-6, which support all operations required for static files.
  • a static file is created in the device by use of the create command from the host.
  • the host will normally specify the fileID with which it wishes to identify the file.
  • the host may either track which files it has created in the device, or it may create a file in response to an error message from the device after the host has attempted to open a file whose fileID does not already exist in the device.
  • the host opens a static file by sending an open command using the fileID for the file as a parameter.
  • the host may operate with the set of static files in the device in such a way that it controls the number of the files that are concurrently open in the device or the number of files of a specific type defined by the host that are concurrently open in the device. The host may therefore close one or more static files before opening another static file.
  • Subsequent writes to the static file cause data to be updated within this offset address range.
  • the host controls the file offset address at which data is being updated by controlling the write_pointer value for the file by means of the write_pointer command.
  • the host does not allow the writejpointer value to exceed the end of the offset address range relating to the size of a static file. Similarly, the host constrains the read_pointer value to within this range.
  • a program block for a static file becomes full, but it does not contain all the valid data for the file, some of the data in the program block is obsolete because multiple updates have been made to the same offset address. In this case, the program block cannot become a file block, and another empty program block is not opened when further data for the file is received. An erased block is allocated to which valid data from the program block is copied (the program block is compacted), and this partially filled block then becomes the program block for the file. All data in the previous program block for the file is now obsolete, and the block is added to the obsolete block garbage collection queue.
  • the host can force a consolidation of a file block and a program block, each of which contains some valid data for a file, by closing the file as described in the following section 14.6.
  • the host may elect to temporarily close a file when a partially obsolete program block becomes full, rather than allow the direct data file device to compact the program block when further data for the file is received.
  • Closure of a static file causes the file to be put into the file garbage collection queue, if only part of the data for the file has been updated. This allows a subsequent garbage collection operation for the file as described in the following section 14.7. However, the host may force an immediate garbage collection operation on the file, as also described in section 14.7.
  • a static file with an entry in the file garbage collection queue has been closed following the update of part of the data in the file.
  • the file block for the file contains some valid data and some obsolete data
  • the program block contains some valid data, possibly some obsolete data, and possible some erased capacity.
  • the file garbage collection operation consolidates all valid data for the file to a single block. If the program block contains no obsolete data, valid data is copied to the program block from the file block, and the file block is erased. If the program block contains obsolete data, all valid data from both the file block and the program block are copied to an erased block, and both the file block and program block are erased.
  • File garbage collection is performed when the entry reaches the head of the queue, at a time determined by the garbage collection-scheduling algorithm.
  • the host may force an immediate garbage collection operation on a file when it closes the file. It does this by sending an idle command immediately after the close command for the file, which causes the device to perform garbage collection or block consolidation operations continuously, until another command is received.
  • the host monitors the internal busy status of the device, until it detects that the device is no longer busy performing internal operations, before sending another command. By this mechanism, consolidation of file and program blocks for a file immediately the file has been closed may be ensured by the host.
  • the direct data file platform acts as a universal back-end system for managing data storage in flash memory.
  • the direct data file interface is an internal file storage interface supporting multiple sources of data.
  • Direct data file storage is a back-end system that organizes data storage on a file-by-file basis.
  • Peak data write speed can be increased when files deleted by a host are erased in a background operation.
  • the direct data file interface should be independent of the operating system in a host:
  • Files with a numerical identifier are managed in a flat hierarchy; Data associated with a file may be stored, to allow construction and maintenance of a hierarchical directory at a level above the interface.
  • the direct data file interface preferably supports various formats of file data transfer:
  • Data within a file has random write and read access, with a granularity of one byte.
  • Data may be appended to, overwrite, or be inserted within, existing data for a file.
  • File data being written or read is streamed to or from the device with no predefined length.
  • a current operation is terminated by receipt of another command.
  • Files are opened for writing data and closed at the end of the file, or when the file is inactive.
  • a file handle is returned by the device for files specified by the host.
  • a hierarchical directory is supported but not maintained.
  • Associated information for a file may be stored.
  • a state within which the device may perform internal operations in the background may be initiated by the host.
  • a file is a set of data created and maintained by a host
  • the host may be an external host or may be an application program within the memory card;
  • a file is identified by a filename created by the host, or by a file handle created by the direct data file platform;
  • Data within a file is identified by file offset addresses
  • the sets of offset addresses for different files act as independent logical address spaces within the device. There is no logical address space for the device itself.
  • a data group is a set of data for a single file with contiguous offset addresses within the file;
  • a data group is stored at contiguous physical addresses in a single block;
  • a data group may have any length between one byte and one block;
  • the data group is the basic unit for mapping logical file address to physical flash address.
  • a program block is dedicated to data for a single file
  • File data in a program block may be in any order of file offset address, and a program block may contain multiple data groups for a file;
  • a program block becomes a file block when its last location has been programmed.
  • a common block contains data groups for more than one file
  • a common block is created by programming data groups for unrelated files to a program block during garbage collection of a common block or during a block consolidation operation;
  • Data groups may be written to a common block during garbage collection of another common block or during a block consolidation operation.
  • a plain file comprises any number of complete file blocks and one partially written program block.
  • a plain file may be deleted without need to relocate data from any block prior to its erasure.
  • Common file (see Figure 3-2):
  • a common file comprises any number of complete file blocks and one common block, which contains data for the file along with data for other unrelated files.
  • a garbage collection operation on only the common block must be performed subsequent to the file being deleted.
  • An edited file contains obsolete data in one or more of its blocks, as a result of data at an existing offset address having been overwritten.
  • Memory capacity occupied by obsolete data may be recovered by a file garbage collection operation.
  • a file garbage collection operation restores an edited file to plain file format.
  • Garbage collection operations are performed to recover memory capacity occupied by obsolete data.
  • Pending operations are logged in garbage collection queues, and are performed subsequently at an optimum rate according to scheduling algorithms.
  • Garbage collection may be initiated by a host command and performed in the background whilst the host interface is quiescent. Operations are suspended on receipt of any other host command.
  • Garbage collection may also be performed as foreground operations, in bursts interleaved with host data write operations.
  • An ongoing process of block consolidation may be implemented to recover erased capacity locked up in program blocks and common blocks. Only necessary if the distributions of capacities of file data in program blocks and of capacities of obsolete data for deleted files in common blocks are imbalanced.
  • Data in multiple program or common blocks is consolidated to allow erasure of one or more blocks.
  • Data for a file identified by a file handle is programmed to flash memory as it is streamed from a host following a write or insert command.
  • the initial file offset address of the data is defined by a write pointer, whose value may be set by the host.
  • Data group indexing structures are updated in flash memory whenever a program block becomes filled, or whenever another host command is received.
  • the file data programming procedure initiates bursts of foreground garbage collection, at intervals in the host data stream that are determined by an adaptive scheduling algorithm.
  • Data for a file identified by a file handle is read from flash memory and is streamed to a host following a read command.
  • the initial file offset address of the data is defined by a read pointer, whose value may be set by the host.
  • File data is read in units of one metapage until the end of the file is reached, or until another host command is received.
  • Data is transferred to the host in file offset address order.
  • the location of data groups to be read for the file is defined by file indexing structures.
  • the file data reading procedure is exited when another host command is received.
  • blocks containing data for the file are identified and added to garbage collection queues for subsequent garbage collection operations.
  • Garbage collection is an operation to recover flash capacity occupied by obsolete data.
  • Obsolete block queue - When a block becomes fully obsolete as a result of update of file data or deletion of a file, it is added to this queue.
  • Common block queue - When data in part of a block containing data for multiple files becomes obsolete as a result of file data update, deletion of a file, or garbage collection of a file, it is added to this queue.
  • File queue - When a file is closed by the host, it is added to this queue.
  • Objects may be designated for priority garbage collection. Garbage collection operations may be scheduled in two ways: Background operations may be initiated by the host when it it is not making read or write access to the device.
  • Foreground operations may be initiated by the direct data file platform whilst it is being accessed by the host.
  • Background garbage collection is initiated by a host.
  • An idle state in which the device is permitted to perform internal operations is initiated by the host via a specific command at the direct data file interface. Garbage collection of objects from the garbage collection queues continues whilst the idle state persists. Garbage collection is suspended when any command is received from the host.
  • the host may optionally monitor the busy state of the device to allow garbage collection operations to complete before sending the next command.
  • Foreground garbage collection is initiated by the direct data file platform when a host has not initiated background operations. Garbage collection is scheduled according to an adaptive algorithm. Bursts of program and erase operations for a current garbage collection operation are interleaved with bursts of program operations for file data received from the host. The lengths of the bursts may be adaptively controlled to define the duty cycle of interleaved garbage collection.
  • Flash memory normally has recoverable capacity that is required for writing further host data, contained in program blocks, common blocks and obsolete file blocks.
  • Adaptive garbage collection controls the interleave ratio of programming further host data and relocating previously written host data. Recoverable capacity is made available for new host data by converting it to erased capacity. The garbage collection rate remains constant over the adaptive period
  • the next entry for a partially obsolete file is selected.
  • a source block and destination blocks are selected for a block consolidation operation.
  • Valid files contain some data in either a program block or a common block.
  • valid file groups are relocated from the source common block to one or more selected destination blocks.
  • the destination block is selected individually for each file group.
  • Priorities for selection of a destination block are as follows:
  • File garbage collection may be performed after a file has been closed, to recover capacity occupied by obsolete data for file. This is only necessary if data for the file has been over-written during an edit.
  • a file in the edited plain file state or edited common file state is restored to the plain file state (containing a single program block and no common block).
  • File garbage collection is performed by copying valid data groups from blocks containing obsolete data to the program block for the file.
  • valid file groups are relocated from a selected source block to one or more selected destination blocks.
  • the source block is selected as the common block or program block with the lowest capacity of data.
  • the destination block is selected individually for each file group.
  • Priorities for selection of a destination block are as follows:
  • a file is identified by a FiIeID that is allocated by the direct data file device when a file is created by a host.
  • a flat directory specifies a File Data Pointer and File Info Pointer for each FiIeID.
  • the File Data Pointer identifies a set of entries in a File Index Table, with each entry specifying a data group for the file to which the set relates.
  • the File Info Pointer identifies a string of information for the file in an Info Table:
  • File_info is written by a host and is not interpreted by the direct data file device.
  • File_info may include filename, parent directory, child directories, attributes, rights information, and file associations for a file.
  • the FIT contains entries for all valid data groups for files in flash memory.
  • Obsolete data groups are not indexed by the FIT.
  • the FIT is divided into logical ranges, each of which is mapped to a physical block.
  • a FIT file is a set of consecutive entries for a file, in file offset address order.
  • a FIT file is identified by a FIT file pointer, defining physical block and logical file number.
  • File Indexing - Updating File Indices (see Figures 10-6 and 10-7)
  • the same structure is used for file index table and info table.
  • Block lists are used to relate a logical file data pointer to FIT files within a physical FIT block or FIT update block.
  • FIT files are stored in the FIT block in compacted format.
  • Updated versions of FIT files are stored in a shared FIT update block, with a single FIT file in a page.
  • Compaction of the FIT update block and consolidation of FIT files in a FIT block are performed from time to time.
  • Information is programmed in units of one page.
  • a page is subdivided into two areas, for FIT entries and file pointers.
  • File pointers translate a logical file number within a range to a page number and entry number for the start of the corresponding FIT file.
  • a FIT file comprises physically consecutive FIT entries.
  • the resolution of data group boundaries is one byte, but data is transferred to and from flash in multiples of one sector, for ECC generation and checking.
  • Data from the buffer is programmed in flash in units of a metapage, where possible.
  • a buffer flush operation programs only part of a page when a file is closed or a shutdown is pending.
  • the file indexing techniques allow the unprogrammed part of the page to persist.
  • a buffer swap-out operation allows file data in the buffer to be stored temporarily in a common swap block, for management of buffer space and back-up of data in buffer.
  • On-chip copy may be used for most data relocation in flash.
  • the direct data file system maintains eight states for blocks associated with the storage of data (see Figure 11-1).
  • Direct data file stores all data for files and all control information in fixed- size metablocks. (The term “block” is often used to designate "metablock.”).
  • Erased blocks that are available for allocation for storing data or control information are held in an erased block pool.
  • Erased blocks are recorded as entries in an erased block log.
  • An erased block for allocation is selected as the entry at the head of the log.
  • Control data structures are stored in a dedicated control block.
  • Control information is stored in four independent logs. Each log occupies one or more pages in the control block. Valid log pages are tracked by log pointers in the last page written.
  • the common block log contains entries for all common blocks existing in flash memory, in order of the available erased capacity they contain.
  • the program block log contains entries for all program blocks existing in flash memory, in order of the available erased capacity they contain.
  • the erased block log contains entries for all erased blocks existing in flash memory, in order of the sequence of their erasure.
  • the control log contains predefined fields for control parameters, counts and lists.
  • a log is updated by writing a revised version of the complete log at the next erased page location in the control block.

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)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Memory System (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)
  • Read Only Memory (AREA)
  • Communication Control (AREA)

Abstract

Host system data files are written directly to a large erase block flash memory system with a unique identification of each file and offsets of data within the file but without the use of any intermediate logical addresses or a virtual address space for the memory. Directory information of where the files are stored in the memory is maintained within the memory system by its controller, rather than by the host.

Description

DATA CONSOLIDATION AND GARBAGE COLLECTION IN DIRECT DATA FILE STORAGE MEMORIES
BACKGROUND AND SUMMARY
[0001] This application relates generally to the operation of re-programmable nonvolatile memory systems such as semiconductor flash memory, including management of the interface between a host device and the memory system, and, more specifically, to the efficient use of a data file interface rather than the common mass memory logical address space (LBA) interface.
[0002] Described herein are developments in various operations of a flash memory that are described in pending United States patent applications nos. 11/060,174, 11/060,248 and 11/060,249, all filed on February 16, 2005 naming either Alan W. Sinclair alone or with Peter J. Smith (hereinafter referenced as the "Prior Applications").
[0003] Further developments are described in related United States patent applications of Alan W. Sinclair and Barry Wright, namely non-provisional applications nos. 11/382,224 and 11/382,232, and provisional applications nos. 60/746,740 and 60/746,742, all filed on May 8, 2006, and non-provisional applications entitled "Indexing Of File Data In Reprogrammable Non- Volatile Memories That Directly Store Data Files," "Reprogrammable Non- Volatile Memory Systems With Indexing of Directly Stored Data Files," "Methods of Managing Blocks in Nonvolatile Memory" and "Nonvolatile Memory With Block Management," all filed July 21, 2006.
[0004] All patents, patent applications, articles and other publications, documents and things referenced herein are hereby incorporated herein by this reference in their entirety for all purposes. To the extent of any inconsistency or conflict in the definition or use of terms between any of the incorporated publications, documents or things and the present application, those of the present application shall prevail.
[0005] Data consolidation is treated differently herein than garbage collection and the two processes are implemented at least partially by different algorithms. When a file or memory block contains obsolete data, a garbage collection operation is utilized to move valid data of the file or block to one or more other blocks. This gathers valid data into a fewer number of blocks, thus freeing up capacity occupied by obsolete data once the original source block(s) are erased. In data consolidation, valid data of one partially filled block, such as is usually created as the result of writing a new file, are combined with valid data of another partially filled block. One or both of the original blocks that were the source of the data, now containing obsolete duplicate data, are then scheduled for garbage collection. Although queues are provided for scheduling individual garbage collection operations to recover memory storage capacity occupied by obsolete data, data consolidation preferably occurs when no garbage collection is scheduled and conditions are otherwise satisfactory for consolidation.
[0006] Rather than scheduling data consolidation of a newly written file right after the file is closed, data of a newly written file are maintained in the original blocks to which they were programmed after receipt from a host. This most commonly includes a block that is partially filled with the new data. Since it is not uncommon for a data file to be deleted or updated in a way that creates obsolete data, consolidation of the data of the partially filled block is postponed as long as possible after the file is closed. The file may be deleted without the need to relocate any data. Therefore, if the file is deleted or updated before such a consolidation becomes necessary, the consolidation is avoided. Such a consolidation can become necessary, as the memory becomes full, for there to be enough erased blocks for further programming of new data. But because the file based memory does not retain data files that have been deleted by the host, contrary to the case when a logical interface is used, the memory will usually have a sufficient number of erased blocks even though the consolidation is delayed. The time taken by the omitted consolidation is therefore saved, and the performance of the memory improved as a result.
[0007] There are several other developments in the direct file storage, described below, that may be summarized:
1. Once a file is closed, it is not added to the file garbage collection queue unless it contains obsolete data. 2. Garbage collection of a file does not create a common block that contains data from another file. Data for the file, which must be copied during the garbage collection, are programmed to the current program block for the file. The program block remains partially programmed at the end of the garbage collection.
3. When data must be relocated from a common block as a result of a file group in the block being made obsolete by deletion of a file, remaining valid data are relocated into an available space of a program block.
4. Movement of host data written directly into a full or portion of a program block is avoided.
5. During garbage collection of a file, data are relocated to a program block for the file. There is no dedicated intermediate copy block.
6. Data are transferred between the memory system controller buffer memory and the memory cell array in complete sectors of data. This allows the generation of an ECC during programming and checking of an ECC during data read.
7. The start of a data group or file group in a common block is aligned to the start of a metapage. On-chip copy may consequently be used for block consolidation. Data groups in program blocks have no specific alignment to physical structures.
8. A swap block within the flash memory is used to make a security copy of data held in the volatile controller buffer memory for an open file that is not active; that is, when the most recent write command relates to a different file. It may also be used as part of a virtual buffer structure, to allow the available buffer memory capacity to support a larger number of open files through the use of swap operations between them.
9. When a FIT file is moved to another FIT range because its current range overflows, the file data pointer in the directory is updated to reflect the new FIT range. *
10. Data in a FIT update block for a FIT range is consolidated with data in the FIT block for the range when the amount of data for the range in the FIT update block exceeds a threshold value. This allows data for new files to be consolidated to a FIT block. 11. During compaction of a FIT update block, a FIT file for a closed file is relocated to the FIT block for its range if sufficient erased space exists. Otherwise, it is relocated to the compacted FIT update block.
12. A host may use write_pointer and read_pointer commands to control all files in a set to have equal size, the same as the size of a metablock, and may use close and idle commands to cause a file in the set to be consolidated into a single metablock immediately after the file is closed.
13. The set of host commands includes read and write commands for a specified fileID that include companion commands for the values of the Write_pointer and Read_pointer that give the memory addresses at which the commanded data write or read is to begin.
DRAWINGS
[0008] The following listed drawings are included as part of the present application and referenced in the descriptions below:
Figure 1-1: Memory Card with Direct Data File Platform;
Figure 1-2: Direct Data File Platform Components;
Figure 2-1: File Commands;
Figure 2-2: Data Commands;
Figure 2-3: Info Commands;
Figure 2-4: Stream Commands;
Figure 2-5: State Commands;
Figure 2-6: Device Commands;
Figure 3-1: Format of a Plain File;
Figure 3-2: Format of a Common File;
Figure 3-3: Format on an Edited Plain File; Figure 3-4: Format of an Edited Common File;
Figure 4-1: Flow Chart for Device Operations;
Figure 5-1: Flow Chart for Programming File Data;
Figure 6-1: Flow Chart for Reading File Data;
Figure 7-1: Flow Chart for Deleting a File;
Figure 8-1: Interleaved Operations for Foreground Garbage Collection;
Figure 8-2: Principle of Operation for Adaptive Scheduling of Garbage Collection;
Figure 8-3: Flow Chart for Garbage Collection Selection;
Figure 8-4: Flow Chart for File Garbage Collection;
Figure 8-5: Flow Chart for Common Block Garbage Collection;
Figure 8-6: Flow Chart for Block Consolidation;
Figure 8-7A through 8-7D: Common Block Garbage Collection Example, showing four time sequential stages;
Figure 9-1: Continuous Host Data Programming;
Figure 9-2: Interrupted Host Data Programming;
Figure 9-3: Buffer Flush Programming;
Figure 9-4: Buffer Swap-Out Programming;
Figure 9-5: Host Data Programming after Buffer Flush;
Figure 9-6: Swap-In Data Read;
Figure 9-7: Host Data Programming after Buffer Swap-In;
Figure 9-8: Aligned Data Read to Buffer; Figure 9-9: Aligned Data Programming from Buffer;
Figure 9-10: Non-Aligned Data Read to Buffer;
Figure 9-11: Non- Aligned Data Programming from Buffer;
Figure 9-12: Non- Aligned Non-Sequential Data Read to Buffer;
Figure 9-13: Non-Aligned Non-Sequential Data Programming from Buffer;
Figure 10-1: File Indexing;
Figure 10-2: File Indexing Structures;
Figure 10-3: Directory Block Format;
Figure 10-4: File Index Table (FIT) Logical Structure;
Figure 10-5: FIT Page Format;
Figure 10-6: Physical FIT Blocks;
Figure 10-7: Examples of FIT File Update Operations;
Figure 11-1: Block State Diagram;
Figure 12-1: Control Block Format;
Figure 12-2: Common Block Log Format; and
Figure 13-1: Command Set Used with Static Files (in parts A and B that should be taken together).
DESCRIPTION OF EXAMPLE EMBODIMENTS 1. Direct Data File Platform
1.1 Summary
[0009] A memory card with a direct data file platform is illustrated in Figure 1-1. The direct data file platform is a file-organized data storage device in which data is identified by filename and file offset address. It acts as the storage platform in a memory card that may incorporate functions other than data storage. File data is accessed in the platform by an external file interface channel.
[0010] The storage device has no logical addresses. Independent address spaces exist for each file, and the memory management algorithms organize data storage according to the file structure of the data. The data storage organization employed in the direct data file platform produces considerable improvement of operating characteristics, in comparison with those of a file storage device that integrates a conventional file system with conventional logically-blocked memory management.
1.2 Platform Components
[0011] The direct data file platform has the following components, structured in layers of functionality as shown in Figure 1-2:
Direct Data File Interface: A file API that provides access from other functional blocks in the card to data identified by filename and file offset address.
File-to-Flash Mapping Algorithm: A scheme for file-organized data storage that eliminates file fragmentation and provide maximum performance and endurance.
Programming File Data: Programming file data in accordance with the file-to-flash mapping algorithm.
Reading File Data: Reading data specified by file offset address from flash memory.
Deleting File: Identifying blocks containing data for a deleted file and adding them to garbage collection queues. Garbage Collection: Operations performed to recover memory capacity occupied by obsolete data. These may entail copying valid data to another location, in order to erase a block.
File Indexing: File indexing allows the locations of the valid data groups for a file to be identified, in offset address order.
Data Buffering & Programming: The use of a buffer memory for data to be programmed, and the sequence of programming file data in program blocks.
Erased Block Management: Management of a pool of erased blocks in the device that are available for allocation for storage of file data or control information.
Block State Management: Transitions between the eight states into which blocks for storage of file data can be classified.
Control Data Structures: Control data structures stored in flash blocks dedicated to the purpose.
2. Direct Data File Interface
[0012] The Direct Data File interface is an API to the Direct Data File platform, which forms the back-end system for flash memory management within a device incorporating flash mass data storage.
2.1 Command Set
[0013] The following sections define a generic command set to support file-based interfacing with multiple sources. Commands are defined in six classes.
1. File commands
2. Data commands
3. File info commands
4. Stream commands (for modeling only)
5. State commands
6. Device commands
2.1.1 File Commands (see Figure 2-1)
[0014] A file is an object that is independently identified within the device by a filelD. A file may comprise a set of data created by a host, or may have no data, in which case it represents a directory or folder.
2.1.1.1 Create
[0015] The create command creates an entry identified by <fileID> within the directory in the device. If the <fileID> parameter is omitted, the device assigns an available value to the file and returns it to the host. This is the normal method of creating a file.
[0016] The host may alternatively assign a <fileID> value to a file. This method may be used if a specific value of filelD denotes a specific type of file within the host interface protocol. For example, a root directory may be assigned a specific filelD by the host.
2.1.1.2 Open
[0017] This command enables execution of subsequent data commands for the file specified by <fileID>. If the file does not exist, an error message is returned. The write_pointer for the file is set to the end of the file, and the read_pointer for the file is set to the beginning of the file. The info_write_pointer for the file_info is set to the end of the file_info, and the info_read_pointer for the file is set to the beginning of the file_info. There is a maximum number of files that can be concurrently open. If this number is exceeded, the command is not executed and an error message is returned. The maximum number of concurrently open files, for example, may be 8.
[0018] Resources within the device for writing to the specified file are made available only after receipt of a subsequent write, insert or remove command.
2.1.1.3 Close
[0019] This command disables execution of subsequent data commands for the • specified file. Write_pointer, readjpointer, info_write__pointer and info_read_pointer values for the file become invalid.
2.1.1.4 Delete
[0020] The delete command indicates that directory, file index table and info table entries for the file specified by <fileID> should be deleted. Data for the files may be erased. The deleted file may not be subsequently accessed.
2.1.1.5 Erase
[0021] The erase command indicates that directory, file index table and info table entries for the file specified by <fileID> should be deleted. File data must be erased before any other command may be executed. The erased file may not be subsequently accessed.
2.1.1.6 Listjiles
[0022] FiIeID values for all files in the directory may be streamed from the device in numerical order following receipt of the list_files command. FiIeID streaming is terminated when the last file is reached, and this condition may be identified by the host by means of a status command. The list_files command is terminated by receipt of any other command.
2.1.2 Data Commands (see Figure 2-2)
[0023] The data commands are used to initiate data input and output operations for a specified file, and to define offset address values within the file. The specified file must have been opened by the host. If this is not the case, an error is returned. <fileID> is the file handle that was returned to the host when the file was last opened.
2.1.2.1 Write
[0024] Data streamed to the device following receipt of the write command is overwritten in the specified file at the offset address defined by the current value of the write_pointer. The write command is used to write new data for a file, append data to a file, and update data within a file. The write command is terminated by receipt of any other command.
2.1.2.2 Insert
[0025] Data streamed to the device following receipt of the insert command is inserted in the specified file at the offset address defined by the current value of the writejpointer. The file size is increased by the length of the inserted data. The insert command is terminated by receipt of any other command. 2.1.2.3 Remove
[0026] The remove command deletes sequential data defined by <length> from the specified file at the offset address defined by the current value of the write_pointer. The file size is reduced by <length>.
2.1.2.4 Read
[0027] Data in the specified file at the offset address defined by the current value of the read_pointer may be streamed from the device following receipt of the read command.
[0028] Data streaming is terminated when the end of file is reached, and this condition may be identified by the host by means of a status command. The read command is terminated by receipt of any other command.
2.1.2.5 Save_buffer
[0029] Data for the specified file that is contained in the device buffer and has not yet been programmed to flash memory is saved at a temporary location in flash memory.
[0030] The data is restored to the buffer when a subsequent write or insert command is received, and is programmed to flash together with data relating to the command.
2.1.2.6 Write_pointer
[0031] The write_pointer command sets the writejpointer for the specified file to the specified offset address. The write__pointer is incremented by the device as data is streamed to the device following a write or insert command.
2.1.2.7 Read_pointer
[0032] The read_pointer command sets the read_pointer for the specified file to the specified offset address. The read_pointer is incremented by the device as data is streamed from the device following a read command.
2.1.3 Info Commands (see Figure 2-3)
[0033] File_info is information generated by a host that is associated with a file. The nature and content of file_info is determined by the host, and it is not interpreted by the device. The info commands are used to initiate file_info input and output operations for a specified file, and to define offset address values within file_info. 2.1.3.1 Write_info
[0034] File_info streamed to the device following receipt of the write_info command overwrites file_info for the specified file at the offset address defined by the current value of the info_write_ρointer. The content and length of file_info for the specified file is determined by the host. The write_info command is terminated by receipt of any other command.
2.1.3.2 Read_info
[0035] File_info for the specified file at the offset address defined by the current value of the info_read_pointer may be streamed from the device following receipt of the read_info command. File_info streaming is terminated when the end of the file_info is reached, and this condition may be identified by the host by means of a status command. The read_info command is terminated by receipt of any other command.
2.1.3.3 Info_write_pointer
[0036] The info_write_pointer command sets the info_write_pointer for the specified file to the specified offset address. The info_write_pointer is incremented by the device as file_info is streamed to the device following a write_info command.
2.1.3.4 Info_read_pointer
[0037] The info_read_pointer command sets the info_read_pointer for the specified file to the specified offset address. The info_read_pointer is incremented by the device as filejύαfo is streamed from the device following a read_info command.
2.1.4 Stream Commands (see Figure 2-4)
[0038] Stream commands are used only with a behavioural model of the direct data file platform. Their purpose is to emulate streaming data to and from a host, in association with the data commands.
2.1.4.1 Stream
[0039] The stream command emulates an uninterrupted stream of data defined by <length> that should be transferred by a host to or from the platform. A variable representing the remaining length of the stream is decremented by the model of the platform as data is added or removed from the buffer memory. 2.1.4.2 Pause
[0040] The pause command inserts a delay of length <time> that is inserted before execution of the following command in a command list that is controlling operation of the direct data file model. <time> is defined in microseconds.
2.1.5 State Commands (see Figure 2-6)
[0041] State commands control the state of the device.
2.1.5.1 Idle
[0042] The idle command indicates that the host is putting the direct data file device in an idle state, during which the device may perform internal housekeeping operations. The host will not deliberately remove power from the device in the idle state. The idle state may be ended by transmission of any other command by the host, whether or not the device is busy with an internal operation. Upon receipt of such other command, any internal operation in progress in the device must be suspended or terminated within a specified time. An example of this time is 10 milliseconds or less. "
2.1.5.2 Standby
[0043] The standby command indicates that the host is putting the direct data file device in a standby state, during which the device may not perform internal housekeeping operations. The host will not deliberately remove power from the device in the standby state. The standby state may be ended by transmission of any other command by the host.
2.1.5.3 Shutdown
[0044] The shutdown command indicates that power will be removed from the device by the host when the device is next not in the busy state. All open files are closed by the device in response to the shutdown command.
2.1.6 Device Commands (see Figure 2-6)
[0045] Device commands allow the host to interrogate the device.
2.1.6.1 Capacity
[0046] In response to the capacity command, the device reports the capacity of file data stored in the device, and the capacity available for new file data.
2.1.6.2 Status
[0047] In response to the status command, the device reports its current status.
[0048] Status includes three types of busy status:
1. The device is busy performing a foreground operation for writing or reading data.
2. The device is busy performing a background operation initiated whilst the device was in the idle state.
3. The buffer memory is busy, and is not available to the host for writing or reading data.
2.1.7 Command Parameters
[0049] The following parameters are used with commands as defined below.
2.1.7.1 FiIeID
[0050] This is a file identifier that is used to identify a file within the directory of the device.
2.1.7.2 Offset
[0051] Offset is a logical address within a file or file_info, in bytes, relative to the start of the file or file_info.
2.1.7.3 Length
[0052] This is the length in bytes of a run of data for a file with sequential offset addresses.
2.1.7.4 Time
[0053] This is a time in microseconds.
3. File-to-Flash Mapping Algorithm
[0054] The file-to-flash mapping algorithm adopted by the direct data file platform is a new scheme for file-organized data storage that has been defined to provide the maximum system performance and maximum memory endurance, when a host performs file data write and file delete operations via a file-based interface. The mapping algorithm has been designed to minimize copying of file data between blocks in flash memory. This is achieved by mapping file data to flash blocks in a manner that achieves the lowest possible incidence of blocks containing data for more than one file.
3.1 File-to-Flash Mapping Principles
3.1.1 Files
[0055] A file is a set of data created and maintained by the host. Data is identified by the host by a filename, and can be accessed by its offset location from the beginning of the file. The file offset address may be set by the host, and may be incremented as a write pointer by the device.
3.1.2 Physical Memory Structures
[0056] The direct data file platform stores all data for files in fixed-size metablocks. The actual number of flash erase blocks comprising a metablock, that is, the erase block parallelism, may vary between products. Throughout this specification, the term "block" is used to denote "metablock".
[0057] The term "metapage" is used to denote a page with the full parallelism of a metablock. A metapage is the maximum unit of programming.
[0058] The term "page" is used to denote a page within a plane of the memory, that is, within a flash erase block. A page is the minimum unit of programming.
[0059] The term "sector" is used to denote the unit of stored data with which an ECC is associated. The sector is the minimum unit of data transfer to and from flash memory.
[0060] There is no specified alignment maintained between offset addresses for a file and the physical flash memory structures.
3.1.3 Data Groups
[0061] A data group is a set of file data with contiguous offset addresses within the file, programmed at contiguous physical addresses in a single memory block. A file will normally be programmed as a number of data groups. A data group may have any length between one byte and one block. Each data group is programmed with a header, containing file identifier information for cross reference purposes. Data for a file is indexed in physical memory according to the data groups it comprises. A file index table provides file offset address and physical address information for each data group of a file.
3.1.4 Program Blocks
[0062] A file must be opened by the host to allow file data to be programmed. Each open file has a dedicated block allocated as a program block, and data for that file is programmed at a location defined by a program pointer within the program block. When a file is opened by the host, a program block for the file is opened, if one does not already exist. The program pointer is set to the beginning of the program block. If a program block already exists for a file that is opened by the host, it continues to be used for programming data for the file.
[0063] File data is programmed in a program block in the order it is received from the host, irrespective of its offset address within the file or whether data for that offset address has previously been programmed. When a program block becomes full, it is known as a file block, and an erased block from the erased block pool is opened as a new program block. There is no physical address relationship between blocks storing data for a file.
3.1.5 Common Blocks
[0064] A common block contains data groups for more than one file. If multiple data groups for the same file exist in a common block, they are located contiguously and the contiguous unit is known as a file group. Data is programmed to a common block only during a block consolidation operation or a common block garbage collection operation.
[0065] The start of an individual data group or a file group within a common block must align with the start of a metapage.
[0066] Data groups within a file group do not have intervening spaces. The boundary between such data groups may occur within a page. A file should have data in only a single common block (see 8.3.4 for an exception to this). 3.2 File Types
3.2.1 Plain File
[0067] A plain file comprises any number of complete file blocks and one partially programmed program block. A plain file may be created by the programming of data for the file from the host, usually in sequential offset address order, or by garbage collection of an edited file. An example plain file is shown in Figure 3-1. A plain file may be either an open file or a closed file.
[0068] Further data for the file may be programmed at the program pointer in the program block. If the file is deleted by the host, blocks containing its data may be immediately erased without the need to copy data from such blocks to another location in flash memory. The plain file format is therefore very efficient, and there is advantage in retaining files in this format for as long as possible.
3.2.2 Common File
[0069] A common file comprises any number of complete file blocks and one common block, which contains data for the file along with data for other unrelated files. Examples are shown in Figure 3-2. A common file may be created from a plain file during a garbage collection operation or by consolidation of program blocks.
[0070] A common file is normally a closed file, and does not have an associated write pointer. If the host opens a common file, a program block is opened and the program pointer is set to the beginning of the program block. If the file is deleted by the host, its file blocks may be immediately erased, but data for an unrelated file or unrelated files must be copied from the common block to another location in flash memory in a garbage collection operation before the common block is erased.
3.2.3 Edited Plain File
[0071] A plain file may be edited at any time by the host, which writes updated data for previously-programmed offset addresses for the file. Examples are given in Figure 3-3. Such updated data is programmed in the normal way at the program pointer in the program block, and the resulting edited plain file will contain obsolete data in one or more obsolete file blocks, or in the program block itself. [0072] The edited plain file may be restored to a plain file in a garbage collection operation for the file. During such garbage collection, any valid file data is copied from each obsolete file block to the program pointer for the file, and the resultant fully-obsolete blocks are erased. The garbage collection is not performed until after the file has been closed by the host, if possible.
3.2.4 Edited Common File
[0073] An open common file may be edited at any time by the host, which writes updated data for previously-programmed offset addresses for the file. Examples are shown in Figure 3-4. Such updated data is programmed in the normal way at the program pointer in the program block, and the resulting edited common file will contain obsolete data in one or more obsolete file blocks, in the common block, or in the program block itself.
[0074] The edited common file may be restored to plain file format in a garbage collection operation for the file. During such garbage collection, any valid file data is copied from each obsolete file block and the common block to the program pointer for the file. The resultant fully-obsolete file blocks are erased, and the obsolete common block is logged for a separate subsequent garbage collection operation.
3.3 Garbage Collection and Block Consolidation
3.3.1 Garbage Collection
[0075] Garbage collection operations are performed to recover memory capacity occupied by obsolete data. These may entail copying valid data to another location, in order to erase a block. Garbage collection need not be performed immediately in response to the creation of obsolete data. Pending garbage collection operations are logged in garbage collection queues, and are subsequently performed at an optimum rate in accordance with scheduling algorithms.
[0076] The direct data file platforms supports background garbage collection operations that may be initiated by a host command. This allows a host to allocate quiescent time to the device for internal housekeeping operations that will enable higher performance when files are subsequently written by the host. [0077] If sufficient background time is not made available by the host, the device performs garbage collection as a foreground operation. Bursts of garbage collection operations are interleaved with bursts of programming file data from the host. The interleave duty cycle may be controlled adaptively to maintain the garbage collection rate at a minimum, whilst ensuring that a backlog is not built up.
3.3.2 Block Consolidation
[0078] Each plain file in the device includes an incompletely filled program block, and a significant volume of erased capacity can be locked up in such program blocks. Common blocks may also contain erased capacity. An ongoing process of consolidating program blocks for closed files and common blocks is therefore implemented, to control the locked erased capacity. Block consolidation is treated as part of the garbage collection function, and is managed by the same scheduling algorithms.
[0079] Data in a program block or a common block is consolidated with data for one or more unrelated files by copying such unrelated data from another common block or program block. If the original block was a program block, it becomes a common block. It is preferable to consolidate a program block with an obsolete common block, rather than with another program block. An obsolete common block contains obsolete data, and it is therefore unavoidable to have to relocate valid data from the block to another location. However, a program block does not contain obsolete data, and copying data from the block to another location is an undesirable overhead.
3.3.3 Equilibrium State
[0080] When file data occupies a high percentage of the device capacity, a host must perform delete operations on files in order to create capacity for writing new files. In this state, most files in the device will have common file format, as there will be little capacity available for erased space in program blocks for files in plain file format.
[0081] Deletion of a common file requires valid data for unrelated files to be relocated from its common block during garbage collection. Data for such file groups is most commonly relocated to available capacity in one or more program blocks for a closed file. There is frequently equilibrium between available unused capacity in program blocks for files recently written then closed by a host, and required capacity for relocating file data from common blocks as a result of files being deleted by a host. This general state of equilibrium reduces the need to relocate file data from a program block, and contributes to the efficiency of the file-to-flash mapping algorithm.
4. Device Operation
4.1 Execution of Device Operations
[0082] The operating sequence of the device is determined by the flow of commands supplied by a host. When a host command is received, the current device operation is interrupted and the command is normally interpreted. Certain commands will cause execution of one of the four main device operations, as follows:
1. Data reading;
2. Data programming;
3. File deleting; or
4. Garbage collection.
The device operation continues, until one of the following conditions is reached:
1. The operation is completed;
2. Another host command is received; or
3. The end of an interleaved burst is reached in foreground garbage collection mode.
[0083] If priority garbage collection operations are queued for execution, these are completed before any new command is interpreted.
[0084] An overall flow chart showing the device operations appears as Figure 4-1.
5. Programming File Data
5.1 Principles for Programming File Data
[0085] Data for a file is programmed to flash memory as it is streamed to the device from a host following a write or insert command from the host. When sufficient data has been accumulated in the buffer memory for the next program operation, it is programmed in the program block for the file. See chapter 9 for a description of this operation.
[0086] When a program block becomes full, it is designated as a file block and an erased block from the erased block pool is allocated as the program block. In addition, the file index table and garbage collection queues for common blocks and obsolete blocks are updated.
[0087] The file data programming procedure initiates bursts of foreground garbage collection, according to interleave parameter Nl that is established by the garbage collection scheduling algorithm (see section 8.4). An interleave program counter is incremented whenever a metapage program operation is initiated in flash memory, and a garbage collection operation in foreground mode is initiated when this counter exceeds the value Nl.
[0088] File data programming continues in units of one metapage, until the host transmits another command.
[0089] A flow chart illustrating an example of programming file data appears as Figure 5-1.
6. Reading File Data
6.1 Principles for Reading File Data
[0090] In response to a read command from a host, data for file offset addresses beginning at that specified by the readjpointer is read from flash memory and returned sequentially to the host, until the end of file is reached. The file index table (FIT) is read, and FIT entries for the file evaluated to identify the location corresponding to the read_pointer. Subsequent FIT entries specify the locations of data groups for the file.
[0091] File data is read in units of one metapage until the end of file is reached, or until the host transmits another command.
[0092] An example process of reading file data is given in Figure 6-1. 7. Deleting a File
7.1 Principles for Deleting a File
[0093] In response to a delete command for a file from a host, blocks containing data for the file are identified and are added to garbage collection queues for subsequent garbage collection operations. The procedure for deleting a file does not initiate these garbage collection operations, and data for the file is therefore not immediately erased.
[0094] FIT entries for the file are evaluated, initially to identify a common block that may contain data for the file. Thereafter, FIT entries for the file are evaluated in offset address order, and the data blocks in which data groups are located are added to either the common block queue or the obsolete block queue, for subsequent garbage collection. The file directory and file index table are then updated, to remove entries for the file.
7.2 Erasing a File
[0095] In response to an erase command for a file from a host, the same procedure as for a delete command should be followed, but with the blocks containing data for the file being added to the priority common block queue and the priority obsolete block queue for garbage collection.
[0096] The main device operations sequence then ensures that garbage collection operations for these blocks are performed before any other host command is executed. This ensures that data for the file identified by the erase command is immediately erased.
[0097] A flow chart of a file deletion process appears as Figure 7-1.
8. Garbage Collection
8.1 Principles for Garbage Collection
[0098] Garbage collection is an operation that must be performed to recover flash memory capacity occupied by obsolete file data. Garbage collection may be necessary as a result of deletion of a file or of edits to the data of a file. [0099] Block consolidation is a form of garbage collection, which is performed to recover erased capacity in blocks that are incompletely filled with file data, to allow their use for storing unrelated files. Consolidation may be performed on program blocks in plain files, to convert them to common blocks, or on common blocks, to reduce their number.
[00100] The processes of garbage collection and block consolidation relocated valid file data from a source flash block to one or more destination blocks, as dictated by the file-to-flash mapping algorithm, to allow the source block to be erased.
[00101] Pending garbage collection operations are performed not immediately, but according to a scheduling algorithm for phased execution. Entries for objects requiring garbage collection are added to three garbage collection queues from time to time during operation of the device. Separate queues exist for files, obsolete blocks, and common blocks. Objects are selected from the queues for the next garbage collection operation in a predefined order of priority. If the queues are empty, block consolidation may be performed.
[00102] Garbage collection operations may be scheduled in two ways. Background operations may be initiated by the host when it is not making read or write access to the device, and are executed continuously by the device until the host makes another access. Foreground operations may be scheduled by the device whilst it is being accessed by the host, and are executed in bursts interleaved with bursts of program operations for file data received from the host. The lengths of the interleaved bursts may be adaptively controlled to maintain the garbage collection rate to the minimum required at all times.
8.2 Garbage Collection Queues
[00103] Garbage collection queues contain entries for objects for which there is a pending garbage collection operation. Three queues each contain entries for obsolete blocks, common blocks and files, respectively. Two additional queues are given higher priority than these three, and contain entries for obsolete blocks and common blocks respectively. The five garbage collection queues are stored in the control log in the control block in flash memory. 8.2.1 Priority Obsolete Block Queue
[00104] This queue contains entries for blocks that have been made fully obsolete as a result of an erase command from the host. It is the highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue must be completed before any other command is accepted from the host, or before garbage collection operations are initiated on objects from any other queue.
8.2.2 Priority Common Block Queue
[00105] This queue contains entries for common blocks that have been made partially obsolete as a result of an erase command from the host. It is the second highest priority garbage collection queue. Garbage collection operations on all common blocks identified in the queue must be completed before any other command is accepted from the host, or before garbage collection operations are initiated on objects from a lower priority queue.
8.2.3 Obsolete Block Queue
[00106] This queue contains entries for blocks that have been made fully obsolete as a result of a delete command from the host, or of edits to the data of a file. It is the third highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue should be completed before operations are initiated on objects from a lower priority queue.
8.2.4 Common Block Queue
[00107] This queue contains entries for common blocks that have been made partially obsolete as a result of a delete command from the host, or of edits to the data of a file. It is the fourth highest priority garbage collection queue. Garbage collection operations on all blocks identified in the queue should be completed before operations are initiated on objects from a lower priority queue.
8.2.5 File Queue
[00108] This queue contains entries for files that have obsolete data as a result of edits to the data of a file. It is the lowest priority garbage collection queue. When a file is closed by the host, an entry for it is added to the file queue unless the file is a plain file. It is therefore necessary to perform an analysis on the FIT entries for a file at the time the file is closed by the host, to determine if the file is a plain file or an edited file (plain or common).
[00109] The procedure for this analysis is as follows:
1. The FIT entries in the relevant FIT file are evaluated in offset address order.
2. The cumulative capacity of data groups and data group headers is determined.
3. The physical capacity occupied by file data is determined. This is the number of blocks other than the program block containing data for the file, plus the used capacity in the program block.
4. If the data group capacity exceeds X% of the physical capacity, the file is determined to be a plain file. An example of the value of X is 98%. X% is less than 100%, to allow for unprogrammed space resulting from a buffer flush operation to persist in a plain file.
8.3 Garbage Collection Operations
8.3.1 Obsolete Block
[00110] An obsolete block contains only obsolete data, and may be erased without the need to relocate data to another block.
8.3.2 Common Block
[00111] The common block is the source block, and contains one or more partially or fully obsolete data groups for one or more files. Valid data must be relocated from this source block to one or more destination blocks.
[00112] Data is relocated in units of a complete file group, where a file group comprises one or more data groups for the same file within the common block. Each file group is relocated intact to a destination block, but different file groups may be relocated to different blocks.
[00113] A common block is the preferred choice for destination block, followed by program block if no suitable common block is available, followed by an erased block if no suitable program block is available.
[00114] The garbage collection operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
[00115] A flow chart for the common block garbage collection operation is shown in Figure 8-5.
8.3.3 File Garbage Collection
[00116] File garbage collection is performed to recover capacity occupied by obsolete data for the file. It restores a file in the edited plain file state or edited common file state to the plain file state. The first step is to perform an analysis on the FIT entries in its FIT file, to identify obsolete file blocks and common block from which data groups must be copied during the garbage collection. The procedure for this analysis is as follows:
1. The FIT entries in the relevant FIT file are evaluated in offset address order.
2. A data group list is constructed to relate data groups to physical blocks. Data groups in the program block are excluded from this list.
3. The physical capacity occupied by data groups and data group headers in each block referenced in the list is determined.
4. If the data group capacity exceeds X% of the capacity of a block, the block is determined to be a file block. An example of the value of X is 98%. X% is less than 100%, to allow for unprogrammed space resulting from a buffer flush operation to persist in a file block.
5. Data groups in blocks that are determined to be file blocks are removed from the data group list constructed above.
[00117] Data groups referenced in the revised data group list are contained in obsolete file blocks or a common block, and are copied to a program block during the file garbage collection operation. The data group structure of the file may be modified as a result of the file garbage collection operation, that is, a relocated data group may be split into two by a block boundary, or may be merged with an adjacent data group. The program block for the file is used as the destination block. When this is filled, another program block is opened. [00118] The garbage collection operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
[00119] A flow chart for the file garbage collection operation is shown in Figure 8-4.
8.3.4 Block Consolidation
[00120] Block consolidation is performed to recover erased capacity in program blocks and common blocks that have been incompletely programmed, and to make the capacity available for storing data for other files.
[00121] The source block for a consolidation is selected as the block in the program block log or common block log with the lowest programmed capacity, to allow the block to be erased after the minimum possible data relocation. Data is relocated in units of a complete file group, where a file group comprises one or more data groups for the same file within the program block or common block. Each file group is relocated intact to a destination block, but different file groups may be relocated to different blocks.
[00122] A common block is the preferred choice for destination block, followed by program block if no suitable common block is available. In the rare event that no destination block is available, a file group may be split to be relocated to more than a single destination block.
[00123] The block consolidation operation can continue until the occurrence of one of the following conditions; the operation is completed, the host sends a command, or the end of an interleaved burst is reached in foreground mode.
[00124] A flow chart for a block consolidation operation is shown in Figure 8-6.
8.4 Scheduling of Garbage Collection Operations
[00125] Garbage collection is preferably performed as a background task during periods when the host device is accessing the card. Background garbage collection initiated by the host is supported in the direct data file platform. [00126] However, it may also be necessary to perform garbage collection as a foreground task whilst the host is writing data to the device. In this mode, a complete garbage collection operation need not be completed as a single event. Bursts of garbage collection can be interleaved with bursts of programming data from a host, such that a garbage collection operation may be completed in a number of separate stages and there is limited interruption to availability of the device to the host.
8.4.1 Background Operation
[00127] Background garbage collection is initiated when the host sends an idle command to the device. This indicates that the host will not deliberately remove power from the device, and does not immediately intend to access the device. However, the host may end the idle state at any time by transmitting another command.
[00128] In the idle state, the device performs continuous garbage collection operations until the occurrence of one of the following conditions; the host transmits another command, or all garbage collection queues are empty and no block consolidation operations are possible.
8.4.2 Interleaved Operation
[00129] Interleaved garbage collection operations are initiated by the direct data file process for programming file data. An interleaved operation is illustrated in Figure 8- 1. After a host data write phase within which the host interface is active and Nl program operations are made to flash memory, the device switches into a garbage collection phase. In this phase, part of one or more garbage collection operations are performed until N2 program operations to flash memory are completed.
[00130] A garbage collection operation in progress may be suspended at the end of a garbage collection phase, and restarted in the next such phase. The values of Nl and N2 are determined by an adaptive scheduling algorithm.
8.4.3 Adaptive Scheduling
[00131] An adaptive scheduling method is used to control the relative lengths of interleaved bursts of host data programming and garbage collection, so that the interruption to host data write operations by garbage collection operations can be kept to a minimum. This is achieved whilst also ensuring that a backlog of pending garbage collection that could cause subsequent reduction in performance is not built up.
8.4.3.1 Principle of Operation
[00132] At any time, the device state comprises capacity occupied by previously written host data, erased capacity in blocks in the erased block pool, and recoverable capacity that can be made available for writing further host data by garbage collection operations. This recoverable capacity may be in program blocks, common blocks, or obsolete file blocks shared with previously written host data, or in fully obsolete blocks. These types of capacity utilization are shown in Figure 8-2.
[00133] Adaptive scheduling of garbage collection controls the interleave ratio of programming incremental host data and relocating previously written host data, such that the ratio can remain constant over an adaptive period during which all recoverable capacity can be made available for host data. If the host deletes files, which converts previously written host data to recoverable capacity, the interleave ratio is changed accordingly and a new adaptive period started.
[00134] The optimum interleave ratio can be determined as follows:
If
The number of erased blocks in the erased block pool = erased Jplocks;
The combined number of program and common blocks = data_blocks;
The total number of valid data pages in program and common blocks = data_pages;
The number of obsolete blocks = obsolete Jblocks; and
The number of pages in a block = pages _per_block, Then
The number of erased blocks that can be created by garbage collection is given by datajblocks - (data_pages I pages_per_block);
The total number of erased blocks after garbage collection is given by erased_blocks + obsolete Jolocks + datajblocks — (data_pages I pages _per_block) ;
The number of incremental data metapages that may be written is given by pages jper_b lock. * ( erased_blocκs + oosoietejyiocKs + datajblocks) - data_pages. If
It is assumed that valid data is evenly distributed throughout the program and common blocks (a pessimistic assumption, since blocks with low data page counts are selected as source blocks for block consolidation operations) Then
The number of metapages relocated during garbage collection is given by datajpages * (datajolocks - datajpages I pages jper_block) I data_blocks The optimum interleave ratio N1:N2 is the ratio of the number of incremental data metapages that may be written to the number of metapages that must be relocated during garbage collection. Therefore,
N1:N2 = (pages jper_block * ( erasedjblocks + obsolete _blocks + data_blocks) — datajpages) / (datajpages * (datajblocks — datajpages I pages jperjblock) I data_ blocks)
[00135] Note that recovery of obsolete capacity in obsolete file blocks has not been included in the adaptive scheduling algorithm. Such capacity results only from editing of files, and is not a common occurrence. If significant capacity exists in obsolete file blocks, the adaptively determined interleave ratio may not be optimum, but switching to operation with minimum ratio (described in 8.4.3.2) will ensure efficient garbage collection of such blocks.
8.4.3.2 Interleave Control
[00136] The interleave ratio N1:N2 is defined in three bands, as follows.
1) Maximum: A maximum limit to the interleave ratio is set, to ensure that garbage collection can never be totally inhibited. An example of this maximum limit is 10 to 1.
2) Adaptive: In the adaptive band, the interleave ratio is controlled to be optimum for pending garbage collection of common blocks and obsolete blocks, and the consolidation of program blocks and common blocks. It is defined by the relationship N1:N2 = (pages _per_block * (erased _blocks + obsolete Jblocks + data_ blocks) - data_pages) / (datajpages * (data_blocks - datajpages I pages jper_hlock) I datajblocks), where Nl and N2 are defined as numbers of page program operations. A value of N2 is defined, representing the preferred duration of a burst of garbage collection. An example of this value is 16.
3) Minimum: If the number of blocks in the erased block pool falls below a defined minimum, the interleave ratio is not adaptively defined, but is set to a fixed minimum limit. An example of this minimum limit is 1 to 10.
8.4.3.3 Control Parameters
[00137] The following parameters are maintained in the control log in the control block in flash memory, for control of adaptive scheduling:
Erased block count: A count of the number of blocks in the erased block pool is maintained. This is updated when blocks are added to and removed from the erased block pool.
Program & common block count: A count of the combined number of program blocks and common blocks is maintained. Common blocks may contain obsolete data. The count is updated when blocks are added to and removed from the program block log and the common block log. Program & common block page count: A count of the number of valid data pages in program blocks and common blocks is maintained. The count is updated when blocks are added to and removed from the program block log and the common block log.
Obsolete block count: A count of the number of fully obsolete blocks awaiting garbage collection is maintained. The count is updated when blocks are added to and removed from the obsolete block garbage collection queue.
8.5 Flow Charts for Garbage Collection
[00138] A flow chart of a specific algorithm for selecting one of several particular garbage collection operations is given in Figure 8-3. Figure 8-4 is a flow chart for the "File garbage collection" block of Figure 8-3. A flow chart for the "Common block garbage collection" block of Figure 8-3 is the subject of Figure 8-5. The "Block consolidation" function of Figure 8-3 is shown by the flow chart of Figure 8-6.
[00139] Four Figures 8-7A through 8-7D show an example garbage collection of a common block that can result from the process of Figure 8-5. Figure 8-7A shows an initial condition, while Figures 8-7B through 8-7C illustrate three steps in the garbage collection process. The arrows show the transfer of valid data from obsolete blocks into file blocks that are not full, and these destination file blocks then become common blocks.
9. Data Buffering & Programming
[00140] The data buffering and programming method described in this section is constrained to use the same flash interface and error correction code (ECC) structures that are employed on current products. Alternative optimised methods may be adopted in the future if new flash interface and ECC structures are introduced.
9.1 Data Buffers
[00141] A buffer memory exists in SRAM in the controller (RAM 31 of the Prior Applications), for temporary storage of data being programmed to and read from flash memory. An allocated region of the buffer memory is used to accumulate sufficient data for a file to allow a full metapage to be programmed in a single operation in flash memory. The offset addresses of data for a file in the buffer memory is unimportant. The buffer memory may store data for multiple files.
[00142] To allow pipelining of both write and read operations with a host, buffer memory space with a capacity of two metapages should be available for each file being buffered. The buffer memory comprises a set of sector buffers. Individual sector buffers may be allocated for temporary storage of data for a single file, and deallocated when the data has been transferred to its final destination. Sector buffers are identified by a sector buffer number 0 to N-I. An example of the number of sector buffers (N) is 64.
[00143] Available sector buffers are allocated cyclically in order of their sector buffer number. Each sector buffer has a file label, and two associated pointers defining the start and end of data contained within it. File offset address ranges within the data in the sector buffer are also recorded. Both the sector buffers and the control information associated with them exist only within volatile memory in the controller.
9.2 Data Programming
9.2.1 Metapage
[00144] A metapage is the maximum unit of programming in flash memory. Data should be programmed in units of a metapage wherever possible, for maximum performance.
9.2.2 Page
[00145] A page is a subset of a metapage, and is the minimum unit of programming in flash memory.
9.2.3 Sector
[00146] A sector is a subset of a page, and is the minimum unit of data transfer between controller and flash memory. A sector usually comprises 512 bytes of file data. An ECC is generated by the controller for each sector (such as by the controller ECC circuit 33 of Figure 2 of the Prior Applications), and is transferred to flash appended to the end of the sector. When data is read from flash, it must be transferred to the controller in multiples of a complete sector, to allow the ECC to be checked.
9.3 Buffer Flush
[00147] Data for a file is normally accumulated in sector buffers until sufficient data is available for programming a complete metapage in flash memory. When the host stops streaming data for a file, one or more sector buffers remain with file data for part of a metapage. This data remains in buffer memory, to allow the host to write further data for the file. However, under certain circumstances, data in buffer memory must be committed to flash memory in an operation known as a buffer flush. A buffer flush operation causes all data for a file that is held in sector buffers to be programmed in one or more pages within a metapage.
[00148] A buffer flush operation is performed in the following two events:
1) The file is closed by the host, or
2) A shut-down command is received by the host. [00149] If data for a file that is closed by the host has been swapped-out to the swap block, it should be restored to the buffer memory and a buffer flush should be performed. Data that is in the swap block during initialization of the device following power removal should be restored to the buffer memory and a buffer flush should be performed.
9.4 Buffer Swap
[00150] Buffer swap is an operation in which data for a file in one or more sector buffers is programmed in a temporary location known as a swap block, to be subsequently restored to buffer memory when the host continues writing data for the file.
9.4.1 Format of Swap Block
[00151] The swap block is a dedicated block that stores data for files that has been swapped-out from sector buffers. Data for a file is stored contiguously in one or more pages dedicated to that file in the swap block. When data is subsequently swapped-in back to buffer memory, it becomes obsolete in the swap block.
[00152] When the swap block becomes full, valid data within it is written in compacted form to an erased block, which then becomes the swap block. This compacted form allows data for different files to exist within the same page. Only a single swap block preferably exists.
9.4.2 Indexing Data stored in Swap Block
[00153] A swap block index is maintained in flash memory, containing for each file in the swap block a copy of the information previously recorded for the file in the buffer memory (see 9.1).
9.4.3 Moving Data to Swap Block (Swap-Out)
[00154] A swap-out operation occurs when insufficient sector buffers are available to be allocated to a file that has been opened by the host, or to a file that must be swapped-in from the swap block as a result of a write command for the file from the host. The file selected for swap-out should be the least recently written file of those for which buffers exist in the buffer memory. [00155] Optionally, to improve security of data in the event of unscheduled removal of power, a swap-out may be performed for any file in the buffer memory which is not related to the most recent write command from the host. In this case, data for the file may remain in buffer memory, and a subsequent swap-in operation is not required if there has not been a removal of power.
9.4.4 Restoring Data from Swap Block (Swap-in)
[00156] The complete data for a file is read from the swap block to one or more sector buffers. The file data need not have exactly the same alignment to sector buffers as before its swap-out. Alignment may have changed as a result of a compaction of the swap block. Data for the file in the swap block becomes obsolete.
9.5 Programming File Data from Host
[00157] Examples given in this section relate to a flash memory configuration with two pages per metapage, and two sectors per page.
9.5.1 Programming Continuous Data from Host
[00158] Data for a file is streamed from a host and is accumulated in successively allocated sector buffers. When sufficient sector buffers have been filled, their data is transferred to flash memory together with an ECC for each sector, and the destination metapage in the program block for the file is programmed. An example of continuous host data programming is shown in Figure 9-1.
9.5.2 Programming Interrupted Data from Host
[00159] Data for a file is streamed from a host and is accumulated in successively allocated sector buffers. Figure 9-2 shows an example of host data programming that has been interupted. The stream is interrupted after data segment 2A, whilst a write operation for a different file is executed. When a further write command for the file is received, data streamed from the host is accumulated in the same sector buffer as before, beginning at data segment 2B. When sufficient sector buffers have been filled, their data is transferred to flash memory together with an ECC for each sector, and the destination metapage in the program block for the file is programmed.
9.5.3 Programming Data being Flushed from Buffer
[00160] Data for a file is streamed from a host and is accumulated in successively allocated sector buffers. However, insufficient data is present to be programmed in a complete metapage. An example is given in Figure 9-3. Data segments 1 and 2A, together with padding segment 2B, is transferred to flash memory together with an ECC for each sector, and the destination page in the program block for the file is programmed.
9.5.4 Programming Data being Swapped-Out from Buffer
[00161] This operation is identical to that for buffer flush programming, except that the destination page is the next available in the swap block, instead of in the program block for the file. Figure 9-4 illustrates this.
9.5.5 Programming Data from Host following a Flush from Buffer
[00162] File data supplied by a host subsequent to a buffer flush operation for the file is programmed separately from the data flushed from buffer memory. Programming must therefore begin at the next available page in the program block for the file. Sufficient data is accumulated to complete the current metapage, and it is transferred with ECC and programmed as shown for sectors 3 and 4 of Figure 9-5.
9.5.6 Programming Data from Host following a Swap-In to Buffer
[00163] When further data for a file that has been swapped-out from the buffer memory is received, it is accumulated in sector buffers allocated in the buffer memory. The swapped-out data is also restored to the buffer memory from the swap block. When sufficient data has been accumulated, a full metapage is programmed in a single operation.
[00164] As illustrated in Figure 9-6, data segments 1 and 2A, together with padding segment 2B, is read from the swap block and restored in two sector buffers. The ECC is checked on both sectors.
[00165] As shown in the example of Figure 9-7, file data from the host is accumulated in buffer sectors. Data segments 1, 2A/2B, 3A/3B and 4A/4B are transferred to flash memory together with ECC for each sector, and are programmed as sectors 1, 2, 3 and 4. 9.6 Programming Data Copied from Flash
9.6.1 Copying Data from Aligned Metapage
[00166] Source and destination metapages are said to be aligned when data to be copied to a full destination metapage occupies a single full source metapage, as illustrated in Figure 9-8. Data sectors 1, 2, 3 and 4 are read from the source metapage to four sector buffers, and the ECC is checked on each sector.
9.6.1.1 Write-Back from Buffer
[00167] Data is programmed from the four sector buffers to the destination metapage, as shown in Figure 9-9. An ECC is generated and stored for sectors 1, 2, 3 and 4.
9.6.1.2 On-Chip Copy
[00168] When the metapage alignment of data to be copied is the same in the source and destination metapages, on-chip copy within the flash chip may be used to increase the speed of the copy operation. Data is programmed to the destination metapage if the ECC check shows no error.
9.6.1.3 Metapage Alignment within Common Block
[00169] The start of each file group within a common block should be forced to align with start of metapage. Data groups in a program block also align with the start of the first metapage in the block. Therefore, all data copy operations for a common block, such as consolidating program blocks into a common block and copying file groups from one common block to a program block or to another common block, will operate with data copy between aligned metapages. On-chip copy within the flash chip should be used when copying data to or from a common block to increase the speed of the copy operation.
9.6.2 Copying Data from Non-Aligned Sequential Metapages
[00170] Source and destination metapages are said to be non-aligned when data to be copied to a full destination metapage is contiguous, but occupies two sequential source metapages. An example of reading the source metapage is shown in Figure 9- 10. Data sectors lA/lB, 2, and 3 are read from the first source metapage to three sector buffers, and data sectors 4 and 5A/5B are read from the second source metapage to a further two sector buffers. The ECC is checked on each sector.
[00171] Data portions 1A/1B, 2A/2B, 3A/3B, and 4A/4B are programmed from the sector buffers to sectors 1, 2, 3 and 4 in the destination metapage, as shown if Figure 9-11. An ECC is generated and stored for sectors 1, 2, 3 and 4.
[00172] When the metapage data being copied is part of a larger run of continuous data, the copy may be partially pipelined. Data is read from the source location to the buffer memory in full metapages. N+l source metapages must be read in order to program N destination metapages.
9.6.3 Copying Data from Non-Aligned Non-Sequential Metapages [00173] Source and destination metapages are said to be non-aligned and nonsequential when data to be copied to a full destination metapage is not contiguous, and occupies two or more non-sequential source metapages. This case represents copying part of two or more non-contiguous data groups within a file to a single destination metapage. Data sectors 1A/1B, 2, and 3A/3B, as shown in Figure 9-12, are read from the first source metapage to three sector buffers, and data sectors 4A/4B and 5A/5B are read from the second source metapage to a further two sector buffers. The ECC is checked on each sector.
[00174] Data portions 1A/1B, 2A/2B, 3A/3B, and 4A/4B are then programmed from the sector buffers to sectors 1, 2, 3 and 4 in the destination metapage, as shown in Figure 9-13. An ECC is generated and stored for sectors 1, 2, 3 and 4.
10. File Indexing
10.1 Principles of File Indexing
[00175] File indexing is shown generally in Figure 10-1. Data for a file is stored as a set of data groups, each spanning a run of contiguous addresses in both file offset address space and physical address space. Data groups within the set for a file need not have any specific physical address relationship with each other. A file index table (FIT) allows the locations of the valid data groups for a file to be identified, in offset address order. A set of FIT entries for a file is identified by a file data pointer. [00176] Information associated with a file that is generated by a host is stored as file_info in an info table (IT). The nature and content of file_info is determined by the host, and it is not interpreted by the device. File_info may include filename, parent directory, child directories, attributes, rights information, and file associations for a file. File_info for a file in the IT is identified by a file info pointer.
[00177] A directory contains a file data pointer and file info pointer for every valid file in the device. These directory entries for a file are identified by a filelD, which is a numerical value.
10.2 File Indexing Structures
[00178] Figure 10-2 shows an example of the file indexing structures.
10.3 Directory
10.3.1 FilelD
[00179] The filelD is a numerical identifier for a file existing within the direct data file platform. It is allocated by the direct data file platform in response to a create command, or may be specified as a parameter with a create command.
[00180] When a filelD value is allocated by the device, a cyclic pointer to entries in the directory is used to locate the next available filelD. When a file is deleted or erased, the directory entry identified by the file's filelD is marked as available.
[00181] A filelD value defines an entry in the directory, which contains fields for the file data pointer and file info pointer for a file.
[00182] The maximum number of files that may be stored in the device is determined by the number of bits allocated for the filelD.
10.3.2 File Data Pointer
[00183] A file data pointer is a logical pointer to an entry for a file in the FIT block list, and possibly also the FIT update block list, within the control log.
[00184] A file data pointer has two fields:
1) FIT range, and 2) FIT file no.
[00185] A file data pointer for a file exists even when the file has zero length.
10.3.2.1 FIT Range
[00186] A FIT range is a subset of the FIT. Each FIT range is mapped to a separate physical FIT block. A FIT range may contain between one FIT file and a maximum number of FIT files, which may be 512, for example.
10.3.2.2 FIT FiIe No.
[00187] A FIT file no. is a logical number used to identify a FIT file within the FIT.
10.3.3 File Info Pointer
[00188] A file info pointer is a logical pointer to an entry for a file in the info block list, and possibly also the info update block list, within the control log.
[00189] A file info pointer has two fields:
1) Info range; and
2) Info no.
10.3.3.1 Info Range
[00190] An info range is a subset of the info table. Each info range is mapped to a separate physical info block. An info range may contain between one set of file_info and a maximum number of sets of file_info, which may be 512, for example.
10.3.3.2 Info No.
[00191] An info no. is a logical number used to identify a set of file_info within the info block.
10.3.4 Directory Structure
[00192] The directory is stored in a flash block dedicated to the purpose. Figure 10-3 shows an example directory block format. The directory is structured as a set of pages, within each of which a set of entries exists for files with consecutive fileID values. This set of entries is termed a directory range. [00193] The directory is updated by writing a revised version of a directory page at the next erased page location defined by a control pointer. Multiple pages may be updated simultaneously, if necessary, by programming them to different pages in a metapage.
[00194] The current page locations for the directory ranges are identified by range pointers in the last written page in the directory block.
10.4 Block Lists
[00195] Both the File Index Table and the Info Table comprise a series of logical ranges, where a range has a correlation with a physical flash block. Block lists are maintained in the control log to record the correlations between range defined in a file data pointer or file info pointer and a physical block, and between logical number defined in a file data pointer or file info pointer and the logical number that is used in physical blocks within the File Index Table and the Info Table.
10.4.1 FIT Block Lists
[00196] The FIT Block List is a list in the control log that allocates a FIT file pointer for entries in the FIT for a file. The FIT file pointer contains the address of the physical flash block that is allocated to the range defined in a file data pointer, and the same FIT file number that is defined in the file data pointer. An entry in the FIT block list contains a single field, a block physical address.
[00197] The FIT Update Block List is a list in the control log that allocates a FIT file pointer for entries for a file in the FIT that are being updated. The FIT file pointer contains the address of the physical flash block that is currently allocated as the FIT update block entry, and the FIT update file number that is allocated in the FIT update block to the FIT file being updated. An entry in the FIT update block list contains three fields:
1) FIT range,
2) FIT file number, and
3) FIT update file number. [00198] When a FIT file pointer corresponding to a file data pointer should be determined from the FIT block lists, the FIT update block list is searched to determine if an entry relating to the file data pointer is present. If none exists, the entry relating to the file data pointer in the FIT block list is valid.
10.4.2 Info Block Lists
[00199] File_info written by a host is stored directly in the info table, identified by a file info pointer. Info block lists exist to allocate an info pointer to file_info in the info table. The indexing mechanisms for these info block lists is completely analogous to those described for the FIT block lists.
[00200] An entry in the info block list contains a single field, a block physical address.
[00201] An entry in the info update block list contains three fields:
1) Info range,
2) Info number, and
3) Update info number.
10.5 File Index Table
[00202] The File Index Table (FIT) comprises a string of FIT entries, where each FIT entry identifies the file offset address and the physical location in flash memory of a data group. The FIT contains entries for all valid data groups for files stored in the device. Obsolete data groups are not indexed by the FIT. An example FIT logical structure is given in figure 10-4.
[00203] A set of FIT entries for data groups in a file is maintained as consecutive entries, in file offset address order. The set of entries is known as a FIT file. The FIT is maintained as a series of FIT ranges, and each FIT range has a correlation with a physical flash block. The number of FIT ranges will vary, depending on the number of data groups in the device. New FIT ranges will be created and FIT ranges eliminated during operation of the device. The FIT block lists are used to create a FIT file pointer from the file data pointer, by which a location in the FIT may be identified. 10.5.1 FIT FiIe
[00204] A FIT file is a set of contiguous FIT entries for the data groups within a file. The entries in the set are in order of file offset address. FIT entries in a FIT file are consecutive, and are either contained within a single FIT range, or overflow from one FIT range to the next consecutive FIT range.
10.5.2 FIT Header
[00205] The first entry in a FIT file is the FIT header. It has three fields:
1) FiIeID,
2) Program block, and
3) Program pointer.
[00206] The FIT header has a fixed length equal to an integral number of FIT entries. This number may be one.
10.5.2.1 FiIeID
[00207] The fileID identifies the entry for the file in the directory.
10.5.2.2 Program Block
[00208] The current physical location of the program block for a file is recorded in the FIT header whenever an updated version of the FIT file is written in the FIT. This is used to locate the program block for a file, when the file is re-opened by the host. It may also be used to validate the correspondence between a FIT file and the program block for the file, which has been selected for program block consolidation.
10.5.2.3 Program Pointer
[00209] The current value of the program pointer within the program block for a file is recorded in the FIT header whenever an updated version of the FIT file is written in the FIT. This is used to define the location for programming data within the program block for a file, when the file is re-opened by the host, or when the program block has been selected for program block consolidation.
10.5.3 FIT Entry
[00210] A FIT entry specifies a data group. It has four fields: 1) Offset address,
2) Length,
3) Pointer, and
4) EOF flag.
10.5.3.1 Offset Address
[00211] The offset address is the offset in bytes within the file relating to the first byte of the data group.
10.5.3.2 Length
[00212] This defines the length in bytes of file data within the data group. The length of the complete data group is longer than this value by the length of the data group header.
10.5.3.3 Pointer
[00213] This is a pointer to the location in a flash block of the start of the data group. The pointer has two fields:
1) Block address, defining the physical block containing the data group, and
2) Byte address, defining the byte offset within the block of the start of the data group. This address contains the data group header.
10.5.3.4 EOF Flag
[00214] The EOF flag is a single bit that identifies a data group as being the end of file.
10.5.4 FIT Block Format
[00215] A FIT range is mapped to a single physical block, known as a FIT block. Updated versions of data in these blocks is programmed in a common update block, known as a FIT update block. Data is updated in units of one page. Multiple pages within a metapage may be updated in parallel, if necessary.
10.5.4.1 Indirect Addressing
[00216] A FIT file is identified by a FIT file pointer. The FIT file number field within this pointer is a logical pointer, which remains constant as data for a FIT file is moved within the physical structures used for indexing. Pointer fields within the physical page structures provide logical to physical pointer translation.
10.5.4.2 Page Format
[00217] The page formats employed in FIT blocks and FIT update blocks are identical.
[00218] A page is subdivided into two areas, the first for FIT entries and the second for file pointers. An example is given in Figure 10-5.
[00219] The first area contains FIT entries that each specifies a data group or contains a FIT header for a FIT file. An example of the number of FIT entries in a FIT page is 512. A FIT file is specified by a contiguous set of FIT entries, within one FIT page or overlapping two or more FIT pages. The first entry of a FIT file, containing a FIT header, is identified by a file pointer in the second area.
[00220] The second area contains valid file pointers only in the FIT page that was most recently programmed. The second area in all other pages is obsolete, and is not used. The file pointer area contains one entry for each FIT file that may be contained in the FIT block, that is, the number of file pointer entries is equal to the maximum number of FIT files that may exist in a FIT block. File pointer entries are stored sequentially, according to FIT file number. The Nth file pointer entry contains a pointer to FIT file N within the FIT block. It has two fields:
1) Page number, specifying a physical page within the FIT block, and
2) Entry number, specifying a FIT entry within the physical page.
[00221] The file pointer entries provide the mechanism for translating a logical FIT file number within a FIT block to a physical location within the block. The complete set of file pointers is updated when every FIT page is programmed, but is only valid in the most recently programmed page. When a FIT file is updated in the FIT update block, its previous location in either the FIT block or FIT update block becomes obsolete, and is no longer referenced by a file pointer.
10.5.5 FIT Update Blocks
[00222] Changes to FIT files in a FIT block are made in a single FIT update block that is shared amongst all FIT blocks. An example of physical FIT blocks is shown in figure 10-6.
[00223] The file data pointer is a logical pointer to a FIT file. Its FIT range field is used to address a FIT block list to identify the physical block address of the FIT block that is mapped to this FIT range. The FIT file number field of the FIT file pointer then selects the correct file pointer for the target FIT file in the FIT block.
[00224] Both FIT range field and FIT file number field of the file data pointer are used to address a FIT update block list, to identify if the target FIT file has been updated. If an entry is found in this list, it provides the physical block address of the FIT update block, and the FIT file number within the update block of the updated version of the FIT file. This may be different from the FIT file number used for the FIT file in the FIT block. The FIT update block contains the valid version of the FIT file, and the version in the FIT block is obsolete.
10.5.6 Update Operations
[00225] A FIT block is programmed only during a consolidation operation. This results in the FIT files being close packed within the block. A FIT update block is updated when FIT entries are modified, added or removed, and during a compaction operation. Figure 10-7 shows examples of update operations on FIT files.
[00226] FIT files are closely packed in the FIT block, as a result of a consolidation operation. The FIT block may not be entirely filled, as there is a maximum number of FIT files that can exist within it. FIT files may overflow from one page to the next. A FIT file in a FIT block becomes obsolete when it is updated and rewritten in the FIT update block.
[00227] When a FIT file is updated, it is rewritten in its entirety in the next available page in the FIT update block. Updating a FIT file may consist of either changing the content of existing FIT entries, or changing the number of FIT entries. FIT files may overflow from one page to the next. The FIT files within a FIT update block need not all relate to the same FIT range.
10.5.7 Creation of a FIT Range
[00228] When a new FIT range must be created to accommodate additional storage space for FIT files, a FIT block is not immediately created. New data within this range is initially written to the FIT update block. A FIT block is subsequently created when a consolidation operation is performed for the range.
10.5.8 Compaction and Consolidation
10.5.8.1 Compaction of Directory Update Block or FIT Update Block
[00229] When a FIT update block becomes filled, its valid FIT file data may be programmed in compacted form to an erased block, which then becomes the update block. There may be a little as one page of compacted valid data to be programmed, if updates have related to only a few files.
[00230] If the FIT file to be relocated in the compaction operation relates to a closed file, and the FIT block for the range contains sufficient unprogrammed pages, the FIT file may be relocated to the FIT block, rather than to the compacted update block.
10.5.8.2 Consolidation of Directory Block or FIT Block
[00231] When FIT entries are updated, the original FIT file in the FIT block becomes obsolete. Such FIT blocks should undergo garbage collection periodically, to recover obsolete space. This is achieved by means of a consolidation operation. In addition, new files may have been created within a range and have entries in an update block, but no corresponding obsolete entries in the FIT block may exist. Such FIT files should be relocated to the FIT block periodically.
[00232] FIT files in an update block may be consolidated into a FIT block for the relevant range, and therefore be eliminated from the update block, whilst other FIT files remain in the update block.
[00233] If the number of FIT entries in a FIT file has increased during the update process, and valid data for the FIT range cannot be consolidated into a single erased block, some FIT files originally assigned to that FIT range may be assigned to another FIT range, and consolidation may be performed into two blocks in separate operations. In the case of such reassignment of a FIT file, the file data pointer in the directory must be updated to reflect the new FIT range. [00234] A consolidation operation for a range should be performed when the capacity of valid data for that range in a FIT update block reaches a defined threshold. An example of this threshold is 50%.
[00235] Compaction should be performed in preference to consolidation for active FIT files relating to files that are still open, and which the host may continue to access.
10.6 Info Table
[00236] The info table uses the same structures, indexing mechanisms and update techniques that are defined for the File Index Table in section 10.5. However, file_info for a file comprises a single string of information that is not interpreted within the direct data file platform.
10.7 Data Groups
[00237] A data group is a set of file data with contiguous offset addresses for a file, programmed at contiguous physical addresses in a single memory block. A file will normally be programmed as a number of data groups. A data group may have any length between one byte and one block.
10.7.1 Data Group Header
[00238] Each data group is programmed with a header, containing file identifier information for cross reference purposes. The header contains the FIT file pointer for the file of which the data group forms part.
11. Block State Management
11.1 Block States
[00239] Blocks for storage of file data can be classified in the following eight states, as shown in the state diagram of Figure 11-1.
11.1.1 Erased Block
[00240] An erased block is in the erased state in an erased block pool. A possible transition from this state is as follows:
(a) Erased Block to Program Block [00241] Data for a single file is programmed to an erased block, when it is supplied from the host or when it is copied during garbage collection for the file.
11.1.2 Program Block
[00242] A program block is partially programmed with valid data for a single file, and contains some erased capacity. The file may be either open or closed. Further data for the file should be programmed to the block when supplied by the host, or when copied during garbage collection of the file.
[00243] Possible transitions from this state are as follows:
(b) Program Block to Program Block
Data for a single file is programmed to a program block for that file, when it is supplied from the host or when it is copied during garbage collection for the file.
(c) Program Block to File Block
Data for a single file from the host is programmed to fill a program block for that file.
(f) Program Block to Obsolete Block
All data for a file in a program block becomes obsolete, as a result of valid data being copied to another block during garbage collection, or of all or part of the file being deleted by the host.
(h) Program Block to Obsolete Program Block
Part of the data in a program block becomes obsolete as a result of an updated version of the data being written by the host in the same program block, or of part of the file being deleted by the host.
(1) Program Block to Common Block
Residual data for a file is programmed to a program block for a different closed file during garbage collection of the file or of a common block, or during consolidation of program blocks.
11.1.3 File Block
[00244] A file block is filled with fully valid data for a single file. [00245] Possible transitions from this state are as follows:
(d) File Block to Obsolete File Block
Part of the data in a file block becomes obsolete as a result of an updated version of the data being programmed by the host in a program block for the file.
(g) File Block to Obsolete Block (g)
All data in a file block becomes obsolete, as a result of an updated version of the data in the block being programmed by the host in a program block for the file, or of all or part of the file being deleted by the host.
11.1.4 Obsolete File Block
[00246] An obsolete file block is filled with any combination of valid data and obsolete data for a single file.
[00247] Possible transitions from this state are as follows:
(e) Obsolete File Block to Obsolete Block (e)
All data in an obsolete file block becomes obsolete, as a result of an updated version of valid data in the block being programmed by the host in a program block for the file, of valid data being copied to another block during garbage collection, or of all or part of the file being deleted by the host.
11.1.5 Obsolete Program Block
[00248] An obsolete program block is partially programmed with any combination of valid data and obsolete data for a single file, and contains some erased capacity. Further data for the file should be programmed to the block when supplied by the host. However, during garbage collection, data for the file should not be copied to the block and a new program block should be opened.
[00249] Possible transitions from this state are as follows:
(i) Obsolete Program Block to Obsolete Program Block
Data for a single file is programmed to an obsolete program block for that file, when it is supplied from the host.
(j) Obsolete Program Block to Obsolete Block All data for a file in an obsolete program block becomes obsolete, as a result of valid data being copied to another block during garbage collection, or of all or part of the file being deleted by the host.
(k) Obsolete Program Block to Obsolete File Block
Data for a single file is programmed to fill an obsolete program block for that file, when it is supplied from the host.
11.1.6 Common Block
[00250] A common block is programmed with valid data for two or more files, and normally contains some erased capacity. Residual data for any file may be programmed to it during garbage collection or consolidation of program blocks.
[00251] Possible transitions from this state are as follows:
(m) Common Block to Common Block
Residual data for a file is programmed to a common block during garbage collection of the file or a common block, or during consolidation of program blocks.
(n) Common Block to Obsolete Common Block
Part or all of the data for one file in a common block becomes obsolete as a result of an updated version of the data being programmed by the host in a program block for the file, of the data being copied to another block during garbage collection of the file, or of all or part of the file being deleted by the host.
11.1.7 Obsolete Common Block
[00252] An obsolete common block is programmed with any combination of valid data and obsolete data for two or more files, and normally contains some erased capacity. Further data should not be programmed to the block.
[00253] Possible transitions from this state are as follows:
(o) Obsolete Common Block to Obsolete Block
Data for all files in an obsolete common block becomes obsolete as a result of an updated version of the data for one file being programmed by the host in a program block for the file, of the data for one file being copied to another block during garbage collection of the file, or of all or part of one file being deleted by the host.
11.1.8 Obsolete Block
[00254] An obsolete block contains only obsolete data, but is not yet erased.
[00255] A possible transition from this state is as follows:
(p) Obsolete Block to Erased Block (p)
An obsolete block is erased during garbage collection, and added back to the erased block pool.
12. Erased Block Management
12.1 Metablock Linking
[00256] The method of linking erase blocks into metablocks is unchanged from that defined for an earlier 3rd generation LBA system.
12.2 Erased Block Pool
[00257] The erased block pool is a pool of erased blocks in the device that are available for allocation for storage of file data or control information. Each erased block in the pool is a metablock, and all metablocks have the same fixed parallelism.
[00258] Erased blocks in the pool are recorded as entries in the erased block log in the control block. Entries are ordered in the log according to the order of erasure of the blocks. An erased block for allocation is selected as the entry at the head of the log. An entry is added to the tail of the log when a block is erased.
13. Control Data Structures
[00259] Control data structures are stored in flash blocks dedicated to the purpose. Three classes of blocks are defined, as follows:
1) File directory block,
2) File index table block, and
3) Control block. 13.1 File Directory Block
[00260] The structure of file directory blocks is has been described previously.
13.2 File Index Table Block
[00261] The structure of file index table blocks has been described previously
13.3 Control Block
[00262] The control block stores control information in four independent logs. A separate page is allocated for each of the logs. This may be extended to multiple pages per log, if necessary. An example format of a control block is shown in Figure 13-1.
[00263] A log is updated by writing a revised version of the complete log at the next erased page location defined by a control pointer. Multiple logs may be updated simultaneously, if necessary, by programming them to different pages in a metapage. The page locations of the valid versions of each of the four logs are identified by log pointers in the last written page in the control block.
13.3.1 Common Block Log
[00264] The common block log records information about every common block existing in the device. The log entries in the common block log are subdivided into two areas, the first for block entries and the second for data group entries, as illustrated in Figure 13-2. Each block entry records the physical location of a common block. Entries are fixed size, and a fixed number exist in the common block log. Each entry has the following fields:
1) Block physical address,
2) Pointer to the next available page in the common block for programming,
3) Pointer to the first of the data group entries for the block, and
4) Number of data group entries.
[00265] A data group entry records information about a data group in a common block. A set of contiguous data group entries defines all data groups in a common block. There is a variable number of data groups in a common block. Each entry preferably has the following fields: 1) Byte address within common block, and
2) FIT file pointer.
13.3.2 Program Block Log
[00266] The program block log records information about every program block existing in the device for closed files. One entry exists for each program block, and has the following fields:
1) Block physical address,
2) Pointer to the next available page in the program block for programming, and
3) FIT file pointer.
13.3.3 Erased Block Log
[00267] The erased block log records the identity every erased block existing in the device. One entry exists for each erased block. Entries are ordered in the log according to the order of erasure of the blocks. An erased block for allocation is selected as the entry at the head of the log. An entry is added to the tail of the log when a block is erased. An entry has a single field: Block physical address.
13.3.4 Control Log
[00268] The control log records diverse control information in the following fields:
13.3.4.1 Open File List
[00269] This field contains information about each of the currently open files, as follows:
1) Pathname,
2) Filename,
3) FIT file pointer, and
4) Program block physical address.
[00270] The program blocks for open files are not included in the program block log.
13.3.4.2 Common Block Count
[00271] This field contains the total number of common blocks recorded in the common block log. 13.3.4.3 Program Block Count
[00272] This field contains the total number of program blocks recorded in the program block log. The count is updated when blocks are added to and removed from the program block log.
13.3.4.4 Erased Block Count
[00273] This field contains the total number of erased blocks recorded in the erased block log. The count is updated when blocks are added to and removed from the erased block log.
13.3.4.5 Program/Common Block Page Count
[00274] This field contains a count of the number of valid data pages in program blocks and common blocks. The count is updated when blocks are added to and removed from the program block log and the common block log.
13.3.4.6 Obsolete Block Count.
[00275] This field contains a count of the number of fully obsolete blocks awaiting garbage collection. The count is updated when blocks are added to and removed from the obsolete block garbage collection queue.
13.3.4.7 FIT Block List
[00276] This field contains information for mapping FIT range to FIT block. It contains an entry defining FIT block physical address for each FIT range.
13.3.4.8 FIT Update Block List
[00277] This field contains information for mapping FIT range and FIT file number to FIT update file number. It contains an entry for each valid FIT file that exists in the update block. An entry has the following three fields:
1) FIT range,
2) FIT file number, and
3) FIT update file number.
13.3.4.9 Directory Block List
[00278] This field contains information for mapping directory range to directory block. It contains an entry defining directory block physical address for each directory range. 13.3.4.10 Directory Update Block List
[00279] This field contains information for mapping directory range and subdirectory number to update subdirectory number. It contains an entry for each valid subdirectory that exists in the update block. An entry has the following three fields:
1) Directory range,
2) Subdirectory number, and
3) Update subdirectory number.
13.3.4.11 Buffer Swap Block Index
[00280] This field contains an index of valid data groups in the swap block. The index for each data group contains the following fields:
1) FIT file pointer,
2) Byte address within swap block, and
3) Length.
13.3.4.12 Priority Obsolete Block Queue
[00281] This field contains the block addresses of all blocks in the priority obsolete block queue for garbage collection.
13.3.4.13 Priority Common Block Queue
[00282] This field contains the block addresses of all blocks in the priority common block queue for garbage collection.
13.3.4.14 Obsolete Block Queue
[00283] This field contains the block addresses of all blocks in the obsolete block queue for garbage collection.
13.3.4.15 Common Block Queue
[00284] This field contains the block addresses of all blocks in the common block queue for garbage collection.
13.3.4.16 File Queue
[00285] This field contains the FIT file pointers of all files in the file queue for garbage collection. 14. Static Files
14.1 Static Files
[00286] Some hosts may store data in a direct data file device by creating a set of files with identical sizes, and updating data periodically within files in the set. A file that is part of such a set is termed a static file. The host may be external to the memory card or may be a processor within the memory card that is executing an on- card application.
[00287] An example application of the use of static files is described in a patent application of Sergey Anatolievich Gorobets, entitled "Interfacing systems Operating Through A Logical Address Space and on a Direct Data File Basis," filed concurrently herewith. In that application, the logical address space of a host is divided by the memory controller into such static files.
[00288] The direct data file device manages the storage of a static file in exactly the same way as for any other file. However, the host may use commands in the direct data file command set in a way that optimizes behavior and performance of the device with static files.
14.1.1 Static File Partition
[00289] Static files are stored as a set in a dedicated partition in the device. All static files in a partition have identical file size.
14.1.2 Static File Size
[00290] File size is defined by host, via the range of offset addresses written to the file. Static files have a size equal to the size of a metablock.
[00291] The host manages the file offset values represented by the write_pointer and readjpointer, to maintain them within the range of values permitted for a static file at all times.
14.1.3 Deleting Static Files
[00292] Unlike other files in a direct data file device, the host does not delete a static file during normal operation. A static file is created by the host, then exists continuously in the device. Data written at any time to the file overwrites existing file data. [00293] However, a host always has the ability to delete a static file, for example, during an operation by the host to reformat the device or to reduce the size of the partition for static files in the device.
14.2 Command Set used with Static Files
[00294] Figure 14-1 gives a command set for use with static files, a subset of that shown in Figures 2-1 through 2-6, which support all operations required for static files.
14.3 Creating Static Files
[00295] A static file is created in the device by use of the create command from the host. The host will normally specify the fileID with which it wishes to identify the file.
[00296] The host may either track which files it has created in the device, or it may create a file in response to an error message from the device after the host has attempted to open a file whose fileID does not already exist in the device.
14.4 Opening Static Files
[00297] The host opens a static file by sending an open command using the fileID for the file as a parameter.
[00298] The host may operate with the set of static files in the device in such a way that it controls the number of the files that are concurrently open in the device or the number of files of a specific type defined by the host that are concurrently open in the device. The host may therefore close one or more static files before opening another static file.
14.5 Writing to Static Files
[00299] When a static file is first written, it occupies a single complete file block in the device, because the file size is defined by the host as being exactly equal to the size of a metablock in flash memory. The offset address range for the file is therefore exactly equal to the size of a metablock in flash memory.
[00300] Subsequent writes to the static file cause data to be updated within this offset address range. The host controls the file offset address at which data is being updated by controlling the write_pointer value for the file by means of the write_pointer command. The host does not allow the writejpointer value to exceed the end of the offset address range relating to the size of a static file. Similarly, the host constrains the read_pointer value to within this range.
[00301] When existing data in a static file is updated after the file has been opened, a program block is opened to which updated data is programmed. Data with corresponding offset address in the file block becomes obsolete. If the complete static file is updated, all data in the program block is valid and the program block becomes the file block for the file. All data in the previous file block for the file has become obsolete, and the block is added to the obsolete block garbage collection queue. An erased block is assigned as a program block if further updated data is received for the file.
[00302] If a program block for a static file becomes full, but it does not contain all the valid data for the file, some of the data in the program block is obsolete because multiple updates have been made to the same offset address. In this case, the program block cannot become a file block, and another empty program block is not opened when further data for the file is received. An erased block is allocated to which valid data from the program block is copied (the program block is compacted), and this partially filled block then becomes the program block for the file. All data in the previous program block for the file is now obsolete, and the block is added to the obsolete block garbage collection queue.
[00303] Note that the host can force a consolidation of a file block and a program block, each of which contains some valid data for a file, by closing the file as described in the following section 14.6. The host may elect to temporarily close a file when a partially obsolete program block becomes full, rather than allow the direct data file device to compact the program block when further data for the file is received.
14.6 Closing Static Files
[00304] The host closes a static file by sending a close command using the fileID for the file as a parameter. [00305] Closure of a static file causes the file to be put into the file garbage collection queue, if only part of the data for the file has been updated. This allows a subsequent garbage collection operation for the file as described in the following section 14.7. However, the host may force an immediate garbage collection operation on the file, as also described in section 14.7.
14.7 Garbage Collection of Static Files
[00306] A static file with an entry in the file garbage collection queue has been closed following the update of part of the data in the file. The file block for the file contains some valid data and some obsolete data, and the program block contains some valid data, possibly some obsolete data, and possible some erased capacity.
[00307] The file garbage collection operation consolidates all valid data for the file to a single block. If the program block contains no obsolete data, valid data is copied to the program block from the file block, and the file block is erased. If the program block contains obsolete data, all valid data from both the file block and the program block are copied to an erased block, and both the file block and program block are erased.
[00308] File garbage collection is performed when the entry reaches the head of the queue, at a time determined by the garbage collection-scheduling algorithm. However, the host may force an immediate garbage collection operation on a file when it closes the file. It does this by sending an idle command immediately after the close command for the file, which causes the device to perform garbage collection or block consolidation operations continuously, until another command is received. The host monitors the internal busy status of the device, until it detects that the device is no longer busy performing internal operations, before sending another command. By this mechanism, consolidation of file and program blocks for a file immediately the file has been closed may be ensured by the host.
OUTLINE QF AN EXAMPLE MEMORY SYSTEM ACCORDING TO THE
FOREGOING DESCRIPTION
[00309] Direct Data File Platform
[00310] The direct data file platform acts as a universal back-end system for managing data storage in flash memory. [00311] The direct data file interface is an internal file storage interface supporting multiple sources of data.
[00312] File access interface with random read/write access of file data without predefined length.
[00313] Object interface with transfer of complete file objects with predefined length.
[00314] LBA interface to conventional hosts incorporating a file system. Logical blocks are stored as logical files.
[00315] Embedded application programs with random access to data within files.
[00316] Direct data file storage is a back-end system that organizes data storage on a file-by-file basis.
[00317] No logical address space for storage device.
[00318] No file system.
Direct Data File v. Prior Systems
[00319] The direct data file platform offers benefits over prior systems:
[00320] High data write speed:
Progressive performance reduction due to file fragmentation is eliminated;
Peak data write speed can be increased when files deleted by a host are erased in a background operation.
[00321] Uniformity of data write speed:
Sustained write speed for streaming data can be improved when garbage collection is performed in the background or in bursts interleaved with writing of host data. [00322] Benefits are a consequence of the characteristics of the algorithms used in the direct data file platform:
Limited file fragmentation Limited file and block consolidation True file delete Optimum file data indexing Efficient garbage collection
Direct Data File Interface - Desirable Features
[00323] The direct data file interface should be independent of the operating system in a host:
Files with a numerical identifier are managed in a flat hierarchy; Data associated with a file may be stored, to allow construction and maintenance of a hierarchical directory at a level above the interface.
[00324] The direct data file interface preferably supports various formats of file data transfer:
Files whose size is undefined to which data can be streamed; Files whose size is defined before they are written; Files whose size is fixed and which exist permanently.
Direct Data File Interface - Implementation
[00325] Data within a file has random write and read access, with a granularity of one byte.
[00326] Data may be appended to, overwrite, or be inserted within, existing data for a file.
[00327] File data being written or read is streamed to or from the device with no predefined length.
[00328] A current operation is terminated by receipt of another command.
[00329] Files are opened for writing data and closed at the end of the file, or when the file is inactive.
[00330] A file handle is returned by the device for files specified by the host.
[00331] A hierarchical directory is supported but not maintained.
[00332] Associated information for a file may be stored.
[00333] A state within which the device may perform internal operations in the background may be initiated by the host.
Direct Data File Interface - Command Set [00334] File commands:
Commands for controlling file objects, Create, Open, Close, Delete, Erase, List_files.
[00335] Data commands:
Commands for writing and reading file data,
Write, Insert, Remove, Read, Save_buffer, Writejpointer, Readjpointer.
[00336] Info commands:
Commands for writing and reading information associated with a file, Write_info, Read_info, Info_write_pointer, Info_read_pointer.
[00337] State commands:
Commands for controlling the state of the device, Idle, Standby, Shut-down.
[00338] Device commands:
Commands for interrogating the device, Capacity, Status.
File-to-Flash Mapping Algorithm [00339] Data structures: Files
Data groups
[00340] Block types:
Program blocks File blocks Common blocks
[00341] File types:
Plain file Common file Edited file
[00342] Memory recovery:
Garbage collection Block consolidation
File-to-Flash Mapping Algorithm - Data Structures [00343] Files:
A file is a set of data created and maintained by a host;
The host may be an external host or may be an application program within the memory card;
A file is identified by a filename created by the host, or by a file handle created by the direct data file platform;
Data within a file is identified by file offset addresses;
The sets of offset addresses for different files act as independent logical address spaces within the device. There is no logical address space for the device itself.
[00344] Data groups:
A data group is a set of data for a single file with contiguous offset addresses within the file; A data group is stored at contiguous physical addresses in a single block; A data group may have any length between one byte and one block; The data group is the basic unit for mapping logical file address to physical flash address.
File-to-Flash Mapping Algorithm - Block Types [00345] Program blocks:
All data written by a host is programmed in a program block;
A program block is dedicated to data for a single file;
File data in a program block may be in any order of file offset address, and a program block may contain multiple data groups for a file;
Separate program blocks exist for each open file, and for an unspecified number of closed files.
[00346] File blocks:
A program block becomes a file block when its last location has been programmed.
[00347] Common blocks:
A common block contains data groups for more than one file;
A common block is created by programming data groups for unrelated files to a program block during garbage collection of a common block or during a block consolidation operation;
Data groups may be written to a common block during garbage collection of another common block or during a block consolidation operation.
File-to-Flash Mapping Algorithm - File Types [00348] Plain file (see Figure 3-1):
A plain file comprises any number of complete file blocks and one partially written program block.
A plain file may be deleted without need to relocate data from any block prior to its erasure. [00349] Common file (see Figure 3-2):
A common file comprises any number of complete file blocks and one common block, which contains data for the file along with data for other unrelated files.
A garbage collection operation on only the common block must be performed subsequent to the file being deleted.
[00350] Edited file (see Figures 3-3 and 3-4)
An edited file contains obsolete data in one or more of its blocks, as a result of data at an existing offset address having been overwritten.
Memory capacity occupied by obsolete data may be recovered by a file garbage collection operation.
A file garbage collection operation restores an edited file to plain file format.
File-to-Flash Mapping Algorithm - Memory Recovery [00351] Garbage collection:
Garbage collection operations are performed to recover memory capacity occupied by obsolete data.
Pending operations are logged in garbage collection queues, and are performed subsequently at an optimum rate according to scheduling algorithms.
Garbage collection may be initiated by a host command and performed in the background whilst the host interface is quiescent. Operations are suspended on receipt of any other host command.
Garbage collection may also be performed as foreground operations, in bursts interleaved with host data write operations.
[00352] Block consolidation:
An ongoing process of block consolidation may be implemented to recover erased capacity locked up in program blocks and common blocks. Only necessary if the distributions of capacities of file data in program blocks and of capacities of obsolete data for deleted files in common blocks are imbalanced.
Data in multiple program or common blocks is consolidated to allow erasure of one or more blocks.
Programming File Data
[00353] Data for a file identified by a file handle is programmed to flash memory as it is streamed from a host following a write or insert command.
[00354] The initial file offset address of the data is defined by a write pointer, whose value may be set by the host.
[00355] When sufficient data has been accumulated in buffer memory, a metapage is programmed in the program block for the file.
[00356] When a program block becomes filled, it is designated as a file block and an erased block is allocated as a new program block for the file.
[00357] Data group indexing structures are updated in flash memory whenever a program block becomes filled, or whenever another host command is received.
[00358] The file data programming procedure initiates bursts of foreground garbage collection, at intervals in the host data stream that are determined by an adaptive scheduling algorithm.
[00359] The file data programming procedure is exited when another host command is received.
Reading File Data
[00360] Data for a file identified by a file handle is read from flash memory and is streamed to a host following a read command.
[00361] The initial file offset address of the data is defined by a read pointer, whose value may be set by the host.
[00362] File data is read in units of one metapage until the end of the file is reached, or until another host command is received. [00363] Data is transferred to the host in file offset address order.
[00364] The location of data groups to be read for the file is defined by file indexing structures.
[00365] The file data reading procedure is exited when another host command is received.
Deleting a File
[00366] In response to a delete command for a file, blocks containing data for the file are identified and added to garbage collection queues for subsequent garbage collection operations.
[00367] The file directory and file index table are updated, to remove entries for the file.
[00368] The procedure for deleting a file does not initiate garbage collection operations, and data for the file is not immediately erased.
[00369] In response to an erase command for a file, the same procedure is followed as for the delete command, but garbage collection operations are initiated and completed before any other host command is executed.
Garbage Collection
[00370] Garbage collection is an operation to recover flash capacity occupied by obsolete data.
[00371] Objects are added to 3 garbage collection queues from time to time during operation of the device, to define subsequent garbage collection operations:
Obsolete block queue - When a block becomes fully obsolete as a result of update of file data or deletion of a file, it is added to this queue. Common block queue - When data in part of a block containing data for multiple files becomes obsolete as a result of file data update, deletion of a file, or garbage collection of a file, it is added to this queue. File queue - When a file is closed by the host, it is added to this queue. Objects may be designated for priority garbage collection. Garbage collection operations may be scheduled in two ways: Background operations may be initiated by the host when it it is not making read or write access to the device.
Foreground operations may be initiated by the direct data file platform whilst it is being accessed by the host.
Garbage Collection - Scheduling
[00372] Background garbage collection is initiated by a host. An idle state in which the device is permitted to perform internal operations is initiated by the host via a specific command at the direct data file interface. Garbage collection of objects from the garbage collection queues continues whilst the idle state persists. Garbage collection is suspended when any command is received from the host. The host may optionally monitor the busy state of the device to allow garbage collection operations to complete before sending the next command.
[00373] Foreground garbage collection is initiated by the direct data file platform when a host has not initiated background operations. Garbage collection is scheduled according to an adaptive algorithm. Bursts of program and erase operations for a current garbage collection operation are interleaved with bursts of program operations for file data received from the host. The lengths of the bursts may be adaptively controlled to define the duty cycle of interleaved garbage collection.
Garbage Collection - Adaptive Scheduling (see Figure 8-2)
[00374] Flash memory normally has recoverable capacity that is required for writing further host data, contained in program blocks, common blocks and obsolete file blocks.
[00375] Adaptive garbage collection controls the interleave ratio of programming further host data and relocating previously written host data. Recoverable capacity is made available for new host data by converting it to erased capacity. The garbage collection rate remains constant over the adaptive period
Garbage Collection - Priority of Operations
[00376] The operation for a scheduled garbage collection is selected from the garbage collection queues with the following order of priority: 1. Obsolete block priority garbage collection:
The next entry for an obsolete block created as a result of a file erase command is selected.
2. Common block priority garbage collection:
The next entry for a partially-obsolete common block created as a result of a file erase command is selected.
3. Obsolete block garbage collection:
The next entry for an obsolete block is selected.
4. Common block garbage collection:
The next entry for a partially-obsolete common block is selected
5. File garbage collection:
The next entry for a partially obsolete file is selected.
6. Block consolidation:
When no entries exist in the garbage collection queues, a source block and destination blocks are selected for a block consolidation operation.
Garbage Collection - Common Block Garbage Collection
[00377] Valid files contain some data in either a program block or a common block.
[00378] When a file is deleted, any common block containing obsolete data for the file experiences a common block garbage collection operation.
[00379] Data groups for unrelated files are relocated to another common block or program block (see Figures 8-7A through 8-7D).
[00380] During a common block garbage collection operation, valid file groups are relocated from the source common block to one or more selected destination blocks.
[00381] The destination block is selected individually for each file group.
[00382] Priorities for selection of a destination block are as follows:
1. The common block with available erased capacity that is the best-fit for the source file group to be relocated;
2. The program block with available erased capacity that is the best-fit for the source file group to be relocated; and 3. An erased block, which is then designated a program block.
Garbage Collection - File Garbage Collection
[00383] File garbage collection may be performed after a file has been closed, to recover capacity occupied by obsolete data for file. This is only necessary if data for the file has been over-written during an edit.
[00384] A file in the edited plain file state or edited common file state is restored to the plain file state (containing a single program block and no common block).
[00385] File garbage collection is performed by copying valid data groups from blocks containing obsolete data to the program block for the file.
[00386] Data groups are copied in sequential order from the offset address following the initial program pointer, with wrap-around at the end of the file.
Garbage Collection - Block Consolidation
[00387] During a block consolidation operation, valid file groups are relocated from a selected source block to one or more selected destination blocks.
[00388] The source block is selected as the common block or program block with the lowest capacity of data.
[00389] The destination block is selected individually for each file group.
[00390] Priorities for selection of a destination block are as follows:
1. A common block with available erased capacity that is the best-fit for the source file group to be relocated.
2. A program block with available erased capacity that is the best-fit for the source file group to be relocated.
3. A program block or common block with the highest available erased capacity, to which part of the file group is written In this situation, it is permissible for a file to share two blocks with other unrelated files.
4. A second program block or common block with available erased capacity that is the best-fit for the remainder of the source file group, to which the remainder of the file group is written. 5. An erased block, which is then designated a program block, to which the remainder of the file group is written.
File Indexing (see Figure 10-1)
[00391] A file is identified by a FiIeID that is allocated by the direct data file device when a file is created by a host.
[00392] A flat directory specifies a File Data Pointer and File Info Pointer for each FiIeID.
[00393] The File Data Pointer identifies a set of entries in a File Index Table, with each entry specifying a data group for the file to which the set relates.
[00394] The File Info Pointer identifies a string of information for the file in an Info Table:
File_info is written by a host and is not interpreted by the direct data file device.
File_info may include filename, parent directory, child directories, attributes, rights information, and file associations for a file.
File Indexing - Indexing Structures [00395] See Figure 10-2
File Indexing - File Index Table (Fm - See Figure 10-4
[00396] The FIT contains entries for all valid data groups for files in flash memory.
Obsolete data groups are not indexed by the FIT.
[00397] The FIT is divided into logical ranges, each of which is mapped to a physical block.
[00398] A FIT file is a set of consecutive entries for a file, in file offset address order.
[00399] A FIT file is identified by a FIT file pointer, defining physical block and logical file number. File Indexing - Updating File Indices (see Figures 10-6 and 10-7) [00400] The same structure is used for file index table and info table.
[00401] Block lists are used to relate a logical file data pointer to FIT files within a physical FIT block or FIT update block.
[00402] FIT files are stored in the FIT block in compacted format.
[00403] Updated versions of FIT files are stored in a shared FIT update block, with a single FIT file in a page.
[00404] Compaction of the FIT update block and consolidation of FIT files in a FIT block are performed from time to time.
File Indexing - Index Page Format (see Figure 10-5)
[00405] The same structure is used for, FIT block, FIT update block, info block, and info update block.
[00406] Information is programmed in units of one page.
[00407] A page is subdivided into two areas, for FIT entries and file pointers.
[00408] File pointers translate a logical file number within a range to a page number and entry number for the start of the corresponding FIT file.
[00409] A FIT file comprises physically consecutive FIT entries.
Data Buffering and Programming
[00410] Data written by host or being relocated within flash memory is buffered in a set of sector buffers.
[00411] The resolution of data group boundaries is one byte, but data is transferred to and from flash in multiples of one sector, for ECC generation and checking.
[00412] Data from the buffer is programmed in flash in units of a metapage, where possible. [00413] A buffer flush operation programs only part of a page when a file is closed or a shutdown is pending. The file indexing techniques allow the unprogrammed part of the page to persist.
[00414] A buffer swap-out operation allows file data in the buffer to be stored temporarily in a common swap block, for management of buffer space and back-up of data in buffer.
[00415] The start of a file group in a program block or common block is aligned to the start of a metapage.
[00416] On-chip copy may be used for most data relocation in flash.
Block State Management
[00417] The direct data file system maintains eight states for blocks associated with the storage of data (see Figure 11-1).
Erased Block Management
[00418] Direct data file stores all data for files and all control information in fixed- size metablocks. (The term "block" is often used to designate "metablock.").
[00419] The method of linking erase blocks into blocks is unchanged from that used in a system with a, logical address space (LBA) interface that is described in the following pending United States patent applications: serial no. 10/749,831, filed December 30, 2003, entitled "Management of Non- Volatile Memory Systems Having Large Erase Blocks"; serial no. 10/750,155, filed December 30, 2003, entitled "Non- Volatile Memory and Method with Block Management System"; serial no. 10/917,888, filed August 13, 2004, entitled "Non- Volatile Memory and Method with Memory Planes Alignment"; serial no. 10/917,867^ filed August 13, 2004; serial no. 10/917,889, filed August 13, 2004, entitled "Non- Volatile Memory and Method with Phased Program Failure Handling"; and serial no. 10/917,725, filed August 13, 2004, entitled "Non- Volatile Memory and Method with Control Data Management," serial no. 11/192,200, filed July 27, 2005, entitled "Non- Volatile Memory and Method with Multi-Stream Update Tracking," serial no. 11/192,386, filed July 27, 2005, entitled "Non- Volatile Memory and Method with Improved Indexing for Scratch Pad and Update Blocks," and serial no. 11/191,686, filed July 27, 2005, entitled "Non- Volatile Memory and Method with Multi-Stream Updating".
[00420] Erased blocks that are available for allocation for storing data or control information are held in an erased block pool.
[00421] Erased blocks are recorded as entries in an erased block log.
[00422] An erased block for allocation is selected as the entry at the head of the log.
[00423] An entry is added at the tail of the log when a block is erased.
Control Data Structures
[00424] Control data structures are stored in a dedicated control block.
[00425] Control information is stored in four independent logs. Each log occupies one or more pages in the control block. Valid log pages are tracked by log pointers in the last page written.
[00426] The common block log contains entries for all common blocks existing in flash memory, in order of the available erased capacity they contain.
[00427] The program block log contains entries for all program blocks existing in flash memory, in order of the available erased capacity they contain.
[00428] The erased block log contains entries for all erased blocks existing in flash memory, in order of the sequence of their erasure.
[00429] The control log contains predefined fields for control parameters, counts and lists.
[00430] A log is updated by writing a revised version of the complete log at the next erased page location in the control block.

Claims

IT IS CLAIMED:
1. For a re-programmable non- volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein and that operates with an inventory of a minimum number of erased blocks ready to have data stored therein, a method of operation, comprising: receiving data logically addressed by unique file identifiers and offsets within the files, storing the received data of a first file as pages within one or more of the erased blocks that only partially fill one of the erased blocks, thereby leaving erased data storage capacity within the partially filled block, and postponing consolidating valid data from the partially filled block with valid data of a second file into another one of the erased blocks until at least the inventory of the number of erased blocks is deemed insufficient to maintain the minimum number.
2. The method of claim 1, additionally comprising, in response to a need to provide another erased block, consolidating valid data from the first file and second file into another one of the erased blocks and thereafter erasing at least the partially filled block, thereby to add another erased block to the inventory.
3. The method of claim 1, additionally comprising, in response to receiving a command to delete the first file, mark all the data of the first file in at least the partially filled block as obsolete, thereby eliminating any valid data from the first file in at least the partially filled block, whereby no consolidation of data of the first file in the partially filled block is necessary.
4. The method of claim 1, additionally comprising maintaining a plurality of records that identify groups of variable amounts of data making up the first file, wherein the individual groups have both contiguous logical offset addresses and contiguous physical addresses of data within the group.
5. A method of operation of a re-programmable non-volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein and which receives data having logical addresses of unique file identifiers and offsets within the individual files, wherein: valid data from a first group of two or more blocks partially programmed with data of two or more files are occasionally consolidated into another block, blocks containing valid data from a second group of one or more blocks that also contain obsolete data are occasionally garbage collected, only one of the data consolidation or garbage collection is carried out at one time, and priority is given to garbage collection over data consolidation.
6. A method of operation of a re-programmable non- volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein and which receives data having logical addresses of unique file identifiers and offsets within the individual files, wherein: received data of individual files are programmed into one or more erased blocks in a manner that data of at least a first file may only partially fill a first block and thereby leave erased storage capacity in the first block, subsequent operations on data within the memory system cause at least some of the data of a second file stored in a second block to become obsolete, in response to at least some of the data of the second file in the second block becoming obsolete, any remaining valid data in the second block are copied into a third block, in response to the first block having erased storage capacity, valid data are copied from the first block into a fourth block, and priority is given to the above-recited copying of valid data from the second block into the third block over the above-recited copying of valid data from the first block into the fourth block.
7. The method of claim 6, wherein at least one of the third or fourth blocks is an erased block into which the copied data are written.
8. The method of claim 6, wherein at least one of the third or fourth blocks contains data of a third file at the time the copied data are written therein.
9. The method of claim 6, additionally wherein a plurality of records that identify groups of variable amounts of data making up the individual files are maintained, wherein the groups individually have both contiguous logical offset addresses and contiguous physical addresses of data within the group.
10. A re-programmable non-volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein, wherein: an inventory of a minimum number of erased blocks ready to have data stored therein are maintained, data of files logically addressed by unique file identifiers and offsets within the files are stored in the memory blocks by storing the received data of a first file as pages within one or more of the erased blocks that only partially fill one of the erased blocks, thereby leaving erased data storage capacity within the partially filled block, and consolidation of valid data from the partially filled block with valid data of a second file into another one of the erased blocks is postponed until at least the inventory of the number of erased blocks is deemed insufficient to maintain the minimum number.
11. The memory system according to claim 10, further wherein valid data from the first file and second file are consolidated in another one of the erased blocks in response to a need to provide another erased block, and thereafter at least the partially filled block is erased, thereby adding another erased block to the inventory.
12. The memory system according to claim 10, further wherein all the data of the first file in at least the partially filled block are marked as obsolete in response to receiving a command to delete the first file, thereby eliminating any valid data from the first file in at least the partially filled block, whereby no consolidation of data of the first file in the partially filled block is necessary.
13. A re-programmable non-volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein, wherein: data having logical addresses of unique file identifiers and offsets within the individual files are accepted, valid data from a first group of two or more blocks partially programmed with data of two or more files are occasionally consolidated into another block, blocks containing valid data from a second group of one or more blocks that also contain obsolete data are occasionally garbage collected, only one of the data consolidation or garbage collection is carried out at one time, and priority is given to garbage collection over data consolidation.
14. A re-programmable non-volatile memory system having a plurality of blocks of memory cells that are individually erased prior to data being written therein, wherein: data having logical addresses of unique file identifiers and offsets within the individual files are accepted, received data of individual files are programmed into one or more erased blocks in a manner that data of at least a first file may only partially fill a first block and thereby leave erased storage capacity in the first block, subsequent operations on data within the memory system cause at least some of the data of a second file stored in a second block to become obsolete, any remaining valid data in the second block are copied into a third block in response to at least some of the data of the second file in the second block becoming obsolete, valid data are copied from the first block into a fourth block in response to the first block having erased storage capacity, and priority is given to the above-recited copying of valid data from the second block into the third block over the above-recited copying of valid data from the first block into the fourth block.
15. The memory system of claim 14, wherein the copied data are written into at least one of the third or fourth blocks when an erased block.
16. The memory system of claim 14, wherein data of a third file at the time the copied data are written therein are contained in at least one of the third or fourth blocks.
PCT/US2006/030242 2005-08-03 2006-08-01 Data consolidation and garbage collection in direct data file storage memories WO2007019220A2 (en)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP06789293A EP1920337A2 (en) 2005-08-03 2006-08-01 Data consolidation and garbage collection in direct data file storage memories
JP2008525181A JP4537482B2 (en) 2005-08-03 2006-08-01 Data integration and garbage collection in direct data file storage memory
CN2006800284045A CN101258473B (en) 2005-08-03 2006-08-01 Data consolidation and garbage collection in direct data file storage memories
KR1020087004662A KR101377147B1 (en) 2005-08-03 2008-02-27 Data consolidation and garbage collection in direct data file storage memories

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US70538805P 2005-08-03 2005-08-03
US60/705,388 2005-08-03

Publications (2)

Publication Number Publication Date
WO2007019220A2 true WO2007019220A2 (en) 2007-02-15
WO2007019220A3 WO2007019220A3 (en) 2007-06-07

Family

ID=37402587

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/US2006/030093 WO2007019174A2 (en) 2005-08-03 2006-08-01 Data operations in flash memories utilizing direct data file storage
PCT/US2006/030242 WO2007019220A2 (en) 2005-08-03 2006-08-01 Data consolidation and garbage collection in direct data file storage memories

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/US2006/030093 WO2007019174A2 (en) 2005-08-03 2006-08-01 Data operations in flash memories utilizing direct data file storage

Country Status (7)

Country Link
US (12) US7984084B2 (en)
EP (2) EP1920336A2 (en)
JP (2) JP4537482B2 (en)
KR (2) KR20080038364A (en)
CN (7) CN101278267B (en)
TW (6) TW200731065A (en)
WO (2) WO2007019174A2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008134163A1 (en) * 2007-04-27 2008-11-06 Microsoft Corporation Managing object lifetime for native/managed peers
JP2009230205A (en) * 2008-03-19 2009-10-08 Toshiba Corp Memory system
JP2010532061A (en) * 2007-06-27 2010-09-30 サンディスク コーポレイション Staged garbage collection and housekeeping operations in flash memory systems
JP2011222057A (en) * 2011-08-12 2011-11-04 Toshiba Corp Memory system
US8484432B2 (en) 2008-03-11 2013-07-09 Kabushiki Kaisha Toshiba Memory system
US9710326B2 (en) 2014-07-28 2017-07-18 SK Hynix Inc. Encoder by-pass with scrambler
US11487657B1 (en) * 2013-01-28 2022-11-01 Radian Memory Systems, Inc. Storage system with multiplane segments and cooperative flash management

Families Citing this family (542)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7108975B2 (en) * 2001-09-21 2006-09-19 Regents Of The University Of Michigan Atlastin
US7490197B2 (en) 2004-10-21 2009-02-10 Microsoft Corporation Using external memory devices to improve system performance
US7934064B1 (en) * 2004-12-21 2011-04-26 Acronis Inc. System and method for consolidation of backups
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
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
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
US9384818B2 (en) 2005-04-21 2016-07-05 Violin Memory Memory power management
US8200887B2 (en) 2007-03-29 2012-06-12 Violin Memory, Inc. Memory management system and method
JP2006350476A (en) * 2005-06-13 2006-12-28 Sony Computer Entertainment Inc Content distribution device and system
US8015606B1 (en) 2005-07-14 2011-09-06 Ironkey, Inc. Storage device with website trust indication
US8321953B2 (en) * 2005-07-14 2012-11-27 Imation Corp. Secure storage device with offline code entry
US8335920B2 (en) * 2005-07-14 2012-12-18 Imation Corp. Recovery of data access for a locked secure storage device
US8438647B2 (en) * 2005-07-14 2013-05-07 Imation Corp. Recovery of encrypted data from a secure storage device
US7627733B2 (en) * 2005-08-03 2009-12-01 Sandisk Corporation Method and system for dual mode access for storage devices
US7984084B2 (en) * 2005-08-03 2011-07-19 SanDisk Technologies, Inc. Non-volatile memory with scheduled reclaim operations
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
US7552271B2 (en) * 2005-08-03 2009-06-23 Sandisk Corporation Nonvolatile memory with block management
US7949845B2 (en) * 2005-08-03 2011-05-24 Sandisk Corporation Indexing of file data in reprogrammable non-volatile memories that directly store data files
US7558906B2 (en) * 2005-08-03 2009-07-07 Sandisk Corporation Methods of managing blocks in nonvolatile memory
US7669003B2 (en) * 2005-08-03 2010-02-23 Sandisk Corporation Reprogrammable non-volatile memory systems with indexing of directly stored data files
JP4394047B2 (en) * 2005-08-05 2010-01-06 信越ポリマー株式会社 Cover member for key frame and push button switch
US20070067620A1 (en) * 2005-09-06 2007-03-22 Ironkey, Inc. Systems and methods for third-party authentication
US12061519B2 (en) 2005-09-30 2024-08-13 Purage Storage, Inc. Reconstructing data segments in a storage network and methods for use therewith
US7529905B2 (en) * 2005-10-13 2009-05-05 Sandisk Corporation Method of storing transformed units of data in a memory system having fixed sized storage blocks
US7814262B2 (en) * 2005-10-13 2010-10-12 Sandisk Corporation Memory system storing transformed units of data in fixed sized storage blocks
US20070094445A1 (en) * 2005-10-20 2007-04-26 Trika Sanjeev N Method to enable fast disk caching and efficient operations on solid state disks
US20070116023A1 (en) * 2005-11-23 2007-05-24 Broadcom Corporation Method and apparatus for dynamically configuring a generic processing module
US20070136671A1 (en) * 2005-12-12 2007-06-14 Buhrke Eric R Method and system for directing attention during a conversation
US7877540B2 (en) 2005-12-13 2011-01-25 Sandisk Corporation Logically-addressed file storage methods
US20070136553A1 (en) * 2005-12-13 2007-06-14 Sinclair Alan W Logically-addressed file storage systems
US8914557B2 (en) 2005-12-16 2014-12-16 Microsoft Corporation Optimizing write and wear performance for a memory
US7769978B2 (en) 2005-12-21 2010-08-03 Sandisk Corporation Method and system for accessing non-volatile storage devices
US7793068B2 (en) * 2005-12-21 2010-09-07 Sandisk Corporation Dual mode access for non-volatile storage devices
US7747837B2 (en) 2005-12-21 2010-06-29 Sandisk Corporation Method and system for accessing non-volatile storage devices
US8639873B1 (en) 2005-12-22 2014-01-28 Imation Corp. Detachable storage device with RAM cache
US8266378B1 (en) 2005-12-22 2012-09-11 Imation Corp. Storage device with accessible partitions
US7818726B2 (en) * 2006-01-25 2010-10-19 Microsoft Corporation Script-based object adaptation
US7454587B1 (en) * 2006-02-06 2008-11-18 Xilinx, Inc. Method and apparatus for memory management in an integrated circuit
CN100485681C (en) * 2006-03-23 2009-05-06 北京握奇数据系统有限公司 Smart card storage system and managing method for file creation in the system
US20070233752A1 (en) * 2006-03-30 2007-10-04 Kiran Bangalore Method and apparatus to reclaim nonvolatile memory space
US7469329B2 (en) 2006-03-30 2008-12-23 International Business Machines Corporation Methods for dynamically resizing memory pools
JP4135747B2 (en) * 2006-04-06 2008-08-20 ソニー株式会社 Data processing apparatus and flash memory access method
US8176249B2 (en) * 2006-05-21 2012-05-08 Amiram Grynberg Methods for embedding session secrets, within application instances
DE102006025133A1 (en) * 2006-05-30 2007-12-06 Infineon Technologies Ag Storage and storage communication system
US20070300031A1 (en) * 2006-06-22 2007-12-27 Ironkey, Inc. Memory data shredder
US8429242B1 (en) * 2006-06-26 2013-04-23 Emc Corporation Methods and apparatus for providing content
JP2008009803A (en) * 2006-06-30 2008-01-17 Sony Corp Information storage device, information transfer method, information transfer system, program and recording medium
US20080010323A1 (en) * 2006-07-06 2008-01-10 An Chen Computer Co., Ltd. Method for duplicating data
KR100758301B1 (en) * 2006-08-04 2007-09-12 삼성전자주식회사 Memory card and method storing data thereof
US7451265B2 (en) * 2006-08-04 2008-11-11 Sandisk Corporation Non-volatile memory storage systems for phased garbage collection
US7444461B2 (en) * 2006-08-04 2008-10-28 Sandisk Corporation Methods for phased garbage collection
US8949555B1 (en) 2007-08-30 2015-02-03 Virident Systems, Inc. Methods for sustained read and write performance with non-volatile memory
US7441071B2 (en) * 2006-09-28 2008-10-21 Sandisk Corporation Memory systems for phased garbage collection using phased garbage collection block or scratch pad block as a buffer
US7444462B2 (en) * 2006-09-28 2008-10-28 Sandisk Corporation Methods for phased garbage collection using phased garbage collection block or scratch pad block as a buffer
US7464216B2 (en) * 2006-09-29 2008-12-09 Sandisk Corporation Method for phased garbage collection with state indicators
US7444463B2 (en) * 2006-09-29 2008-10-28 Sandisk Corporation System for phased garbage collection with state indicators
KR100849221B1 (en) * 2006-10-19 2008-07-31 삼성전자주식회사 Method for managing non-volatile memory, and memory-based apparatus including the non-volatile memory
US8745315B2 (en) * 2006-11-06 2014-06-03 Rambus Inc. Memory Systems and methods supporting volatile and wear-leveled nonvolatile physical memory
US8719501B2 (en) 2009-09-08 2014-05-06 Fusion-Io Apparatus, system, and method for caching data on a solid-state storage device
US20080140724A1 (en) 2006-12-06 2008-06-12 David Flynn Apparatus, system, and method for servicing object requests within a storage controller
US8706968B2 (en) 2007-12-06 2014-04-22 Fusion-Io, Inc. Apparatus, system, and method for redundant write caching
US9104599B2 (en) 2007-12-06 2015-08-11 Intelligent Intellectual Property Holdings 2 Llc Apparatus, system, and method for destaging cached data
US9116823B2 (en) 2006-12-06 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for adaptive error-correction coding
US8443134B2 (en) 2006-12-06 2013-05-14 Fusion-Io, Inc. Apparatus, system, and method for graceful cache device degradation
US8074011B2 (en) * 2006-12-06 2011-12-06 Fusion-Io, Inc. Apparatus, system, and method for storage space recovery after reaching a read count limit
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
US8489817B2 (en) 2007-12-06 2013-07-16 Fusion-Io, Inc. Apparatus, system, and method for caching data
US9495241B2 (en) 2006-12-06 2016-11-15 Longitude Enterprise Flash S.A.R.L. Systems and methods for adaptive data storage
US8151082B2 (en) 2007-12-06 2012-04-03 Fusion-Io, Inc. Apparatus, system, and method for converting a storage request into an append data storage command
US8161353B2 (en) 2007-12-06 2012-04-17 Fusion-Io, Inc. Apparatus, system, and method for validating that a correct data segment is read from a data storage device
US8209605B2 (en) * 2006-12-13 2012-06-26 Pado Metaware Ab Method and system for facilitating the examination of documents
EP1939751A1 (en) * 2006-12-22 2008-07-02 Telefonaktiebolaget LM Ericsson (publ) Storing compressed data
EP2097825B1 (en) 2006-12-26 2013-09-04 SanDisk Technologies Inc. Use of a direct data file system with a continuous logical address space interface
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
US20080155175A1 (en) * 2006-12-26 2008-06-26 Sinclair Alan W Host System That Manages a LBA Interface With Flash Memory
US7739444B2 (en) 2006-12-26 2010-06-15 Sandisk Corporation System using a direct data file system with a continuous logical address space interface
US8166267B2 (en) * 2006-12-26 2012-04-24 Sandisk Technologies Inc. Managing a LBA interface in a direct data file memory system
US8209461B2 (en) 2006-12-26 2012-06-26 Sandisk Technologies Inc. Configuration of host LBA interface with flash memory
US20080177782A1 (en) * 2007-01-10 2008-07-24 Pado Metaware Ab Method and system for facilitating the production of documents
KR100877609B1 (en) * 2007-01-29 2009-01-09 삼성전자주식회사 Semiconductor memory system performing data error correction using flag cell array of buffer memory and driving method thereof
KR100869675B1 (en) * 2007-02-05 2008-11-21 지인정보기술 주식회사 System and method for controling flash memory using descriptor array
KR100825802B1 (en) * 2007-02-13 2008-04-29 삼성전자주식회사 Data write method of non-volatile memory device copying data having logical pages prior to logical page of write data from data block
US7639540B2 (en) * 2007-02-16 2009-12-29 Mosaid Technologies Incorporated Non-volatile semiconductor memory having multiple external power supplies
KR100875294B1 (en) * 2007-03-16 2008-12-23 삼성전자주식회사 Flash memory and its method for checking block status register during programming
US7987332B2 (en) * 2007-03-21 2011-07-26 Sandisk Technologies Inc. Methods for storing memory operations in a queue
US20080235480A1 (en) * 2007-03-21 2008-09-25 Shai Traister Systems for storing memory operations in a queue
US9632870B2 (en) * 2007-03-29 2017-04-25 Violin Memory, Inc. Memory system with multiple striping of raid groups and method for performing the same
US11010076B2 (en) 2007-03-29 2021-05-18 Violin Systems Llc Memory system with multiple striping of raid groups and method for performing the same
DE102007015535A1 (en) * 2007-03-30 2008-10-02 Siemens Ag Method for digital storage of data on a data storage with limited available storage space
US8768898B1 (en) * 2007-04-26 2014-07-01 Netapp, Inc. Performing direct data manipulation on a storage device
US8041883B2 (en) 2007-05-09 2011-10-18 Stmicroelectronics S.R.L. Restoring storage devices based on flash memories and related circuit, system, and method
US7882301B2 (en) * 2007-05-09 2011-02-01 Stmicroelectronics S.R.L. Wear leveling in storage devices based on flash memories and related circuit, system, and method
US20080282024A1 (en) * 2007-05-09 2008-11-13 Sudeep Biswas Management of erase operations in storage devices based on flash memories
US7991942B2 (en) 2007-05-09 2011-08-02 Stmicroelectronics S.R.L. Memory block compaction method, circuit, and system in storage devices based on flash memories
US8041847B1 (en) * 2007-05-10 2011-10-18 Marvell International Ltd. Periodic and conditional execution of DMA operations
US8010507B2 (en) * 2007-05-24 2011-08-30 Pado Metaware Ab Method and system for harmonization of variants of a sequential file
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
US9396103B2 (en) * 2007-06-08 2016-07-19 Sandisk Technologies Llc Method and system for storage address re-mapping for a memory device
US20100180072A1 (en) * 2007-06-22 2010-07-15 Shigekazu Kogita Memory controller, nonvolatile memory device, file system, nonvolatile memory system, data writing method and data writing program
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
US7822791B2 (en) * 2007-06-28 2010-10-26 Intel Corporation Method and apparatus for flash memory reclaim
US20090006506A1 (en) * 2007-06-28 2009-01-01 Nokia Corportion Method and system for garbage collection of native resources
US8201188B2 (en) * 2007-09-20 2012-06-12 Microsoft Corporation Device-hosted services over media transfer protocol
US7805632B1 (en) * 2007-09-24 2010-09-28 Net App, Inc. Storage system and method for rapidly recovering from a system failure
US8195912B2 (en) 2007-12-06 2012-06-05 Fusion-io, Inc Apparatus, system, and method for efficient mapping of virtual and physical addresses
US9519540B2 (en) 2007-12-06 2016-12-13 Sandisk Technologies Llc Apparatus, system, and method for destaging cached data
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
US8316277B2 (en) 2007-12-06 2012-11-20 Fusion-Io, Inc. Apparatus, system, and method for ensuring data validity in a data storage process
CA2708669A1 (en) * 2007-12-13 2009-06-18 Redknee Inc. Method and system for storage
US9032154B2 (en) * 2007-12-13 2015-05-12 Sandisk Technologies Inc. Integration of secure data transfer applications for generic IO devices
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
US8621138B2 (en) 2007-12-27 2013-12-31 Sandisk Enterprise Ip Llc Flash storage controller execute loop
US20090228716A1 (en) * 2008-02-08 2009-09-10 Pado Metawsre Ab Method and system for distributed coordination of access to digital files
US9060046B2 (en) * 2008-02-18 2015-06-16 Google Technology Holdings LLC Method and apparatus for transferring media data between devices
US8307180B2 (en) 2008-02-28 2012-11-06 Nokia Corporation Extended utilization area for a memory device
TWI385520B (en) * 2008-02-29 2013-02-11 Via Tech Inc Management methods and systems for storage units
KR101477047B1 (en) * 2008-02-29 2014-12-30 삼성전자주식회사 Memory system and block merge methods thereof
JP2009211234A (en) * 2008-03-01 2009-09-17 Toshiba Corp Memory system
JP4675985B2 (en) * 2008-03-01 2011-04-27 株式会社東芝 Memory system
WO2009109877A1 (en) * 2008-03-04 2009-09-11 Nxp B.V. Mobile communication device and method for implementing mifare memory multiple sectors mechanisms
CN101251788A (en) * 2008-03-07 2008-08-27 威盛电子股份有限公司 Storage unit management method and system
US20090271562A1 (en) * 2008-04-25 2009-10-29 Sinclair Alan W Method and system for storage address re-mapping for a multi-bank memory device
WO2009137371A2 (en) * 2008-05-02 2009-11-12 Ironkey, Inc. Enterprise device recovery
US8880775B2 (en) * 2008-06-20 2014-11-04 Seagate Technology Llc System and method of garbage collection in a memory device
EP2297707B1 (en) 2008-06-24 2013-10-02 Nxp B.V. Method of accessing applications in a secure mobile environment
US8843691B2 (en) 2008-06-25 2014-09-23 Stec, Inc. Prioritized erasure of data blocks in a flash storage device
US20090327581A1 (en) * 2008-06-30 2009-12-31 Coulson Richard L Nand memory
KR100954039B1 (en) 2008-08-11 2010-04-20 (주)인디링스 Device and method of controlling flash memory
US8281062B2 (en) * 2008-08-27 2012-10-02 Sandisk Il Ltd. Portable storage device supporting file segmentation and multiple transfer rates
TWI399651B (en) * 2008-09-12 2013-06-21 Communication protocol method and system for input / output device
US20100070544A1 (en) * 2008-09-12 2010-03-18 Microsoft Corporation Virtual block-level storage over a file system
US9032151B2 (en) 2008-09-15 2015-05-12 Microsoft Technology Licensing, Llc Method and system for ensuring reliability of cache data and metadata subsequent to a reboot
CN101676882B (en) * 2008-09-16 2013-01-16 美光科技公司 Built-in mapping message of memory device
US7953774B2 (en) * 2008-09-19 2011-05-31 Microsoft Corporation Aggregation of write traffic to a data store
CN101685381B (en) * 2008-09-26 2013-07-24 美光科技公司 Data streaming of solid-state large-capacity storage device
US8429658B2 (en) * 2008-10-16 2013-04-23 International Business Machines Corporation Lock deferral for real-time garbage collection
US8205203B2 (en) * 2008-10-16 2012-06-19 International Business Machines Corporation Scheduling for real-time garbage collection
CN101727398B (en) * 2008-10-31 2012-07-11 西安奇维测控科技有限公司 Methods for realizing storage and reduction of management data of flash controller by information serialization
JP5364340B2 (en) * 2008-11-07 2013-12-11 株式会社ケーヒン BACKUP METHOD AND DEVICE AND VEHICLE ELECTRONIC CONTROL DEVICE
US8341311B1 (en) 2008-11-18 2012-12-25 Entorian Technologies, Inc System and method for reduced latency data transfers from flash memory to host by utilizing concurrent transfers into RAM buffer memory and FIFO host interface
KR101469771B1 (en) * 2008-12-03 2014-12-08 삼성전자주식회사 Semiconductor device comprising flash memory and address mapping method thereof
US8849856B2 (en) * 2008-12-16 2014-09-30 Sandisk Il Ltd. Discardable files
US20120173593A1 (en) * 2008-12-16 2012-07-05 Fabrice Jogand-Coulomb System and Method for Managing Discardable Objects
US9104686B2 (en) * 2008-12-16 2015-08-11 Sandisk Technologies Inc. System and method for host management of discardable objects
JP5268617B2 (en) * 2008-12-17 2013-08-21 キヤノン株式会社 Image forming apparatus, image forming apparatus control method, and computer program
JP4551958B2 (en) * 2008-12-22 2010-09-29 株式会社東芝 Semiconductor memory device and method for controlling semiconductor memory device
US8452940B2 (en) * 2008-12-30 2013-05-28 Sandisk Technologies Inc. Optimized memory management for random and sequential data writing
US8327040B2 (en) 2009-01-26 2012-12-04 Micron Technology, Inc. Host controller
US8386723B2 (en) * 2009-02-11 2013-02-26 Sandisk Il Ltd. System and method of host request mapping
US20100235605A1 (en) * 2009-02-13 2010-09-16 Nir Perry Enhancement of storage life expectancy by bad block management
US9098396B2 (en) * 2009-02-13 2015-08-04 Sandisk Il Ltd. Enhancement of efficiency in power failure handling in flash memory
KR20100094241A (en) * 2009-02-18 2010-08-26 삼성전자주식회사 Nonvolatile memory device not including reserved blocks
US20100228906A1 (en) * 2009-03-06 2010-09-09 Arunprasad Ramiya Mothilal Managing Data in a Non-Volatile Memory System
WO2010103760A1 (en) * 2009-03-13 2010-09-16 パナソニック株式会社 Access module, information recording module, controller, and information recording system
US8832354B2 (en) 2009-03-25 2014-09-09 Apple Inc. Use of host system resources by memory controller
US8090905B2 (en) * 2009-03-27 2012-01-03 Sandforce, Inc. System, method, and computer program product for converting logical block address de-allocation information in a first format to a second format
US8671258B2 (en) 2009-03-27 2014-03-11 Lsi Corporation Storage system logical block address de-allocation management
US20100250830A1 (en) * 2009-03-27 2010-09-30 Ross John Stenfort System, method, and computer program product for hardening data stored on a solid state disk
KR101574540B1 (en) * 2009-04-15 2015-12-07 삼성전자주식회사 Data storage device and data storage system including of the same
WO2010125574A1 (en) 2009-04-27 2010-11-04 Kamlesh Gandhi Description
US8341501B2 (en) 2009-04-30 2012-12-25 International Business Machines Corporation Adaptive endurance coding of non-volatile memories
US8219776B2 (en) * 2009-09-23 2012-07-10 Lsi Corporation Logical-to-physical address translation for solid state disks
TWI455133B (en) * 2009-05-26 2014-10-01 Silicon Motion Inc Method for managing a plurality of blocks of a flash memory, and associated memory device and controller thereof
US8504759B2 (en) * 2009-05-26 2013-08-06 Micron Technology, Inc. Method and devices for controlling power loss
WO2010143209A1 (en) * 2009-06-10 2010-12-16 Francesco Falanga Suspension of memory operations for reduced read latency in memory arrays
WO2010144587A2 (en) 2009-06-12 2010-12-16 Violin Memory, Inc. Memory system having persistent garbage collection
US8364931B2 (en) * 2009-06-29 2013-01-29 Mediatek Inc. Memory system and mapping methods using a random write page mapping table
US20110004718A1 (en) 2009-07-02 2011-01-06 Ross John Stenfort System, method, and computer program product for ordering a plurality of write commands associated with a storage device
US20110002169A1 (en) 2009-07-06 2011-01-06 Yan Li Bad Column Management with Bit Information in Non-Volatile Memory Systems
US9792074B2 (en) * 2009-07-06 2017-10-17 Seagate Technology Llc System, method, and computer program product for interfacing one or more storage devices with a plurality of bridge chips
JP5254141B2 (en) * 2009-07-14 2013-08-07 富士通株式会社 Archive device, data storage program, and data storage method
US9218349B2 (en) 2009-07-27 2015-12-22 International Business Machines Corporation Method and system for transformation of logical data objects for storage
US8683088B2 (en) * 2009-08-06 2014-03-25 Imation Corp. Peripheral device data integrity
US8745365B2 (en) * 2009-08-06 2014-06-03 Imation Corp. Method and system for secure booting a computer by booting a first operating system from a secure peripheral device and launching a second operating system stored a secure area in the secure peripheral device on the first operating system
US9235350B2 (en) * 2009-08-27 2016-01-12 International Business Machines Corporation Dispersed storage unit and methods with metadata separation for use in a dispersed storage system
WO2011031903A2 (en) * 2009-09-09 2011-03-17 Fusion-Io, Inc. Apparatus, system, and method for allocating storage
US9223514B2 (en) 2009-09-09 2015-12-29 SanDisk Technologies, Inc. Erase suspend/resume for memory
US9122579B2 (en) 2010-01-06 2015-09-01 Intelligent Intellectual Property Holdings 2 Llc Apparatus, system, and method for a storage layer
US8429436B2 (en) 2009-09-09 2013-04-23 Fusion-Io, Inc. Apparatus, system, and method for power reduction in a storage device
US8838877B2 (en) * 2009-09-16 2014-09-16 Apple Inc. File system derived metadata for management of non-volatile memory
US8234250B1 (en) * 2009-09-17 2012-07-31 Netapp. Inc. Processing data of a file using multiple threads during a deduplication gathering phase
TWI506422B (en) * 2009-09-23 2015-11-01 Silicon Motion Inc Method for managing a memory device having multiple channels and multiple ways, and associated memory device and controller thereof
US8364929B2 (en) * 2009-10-23 2013-01-29 Seagate Technology Llc Enabling spanning for a storage device
US8745353B2 (en) * 2009-10-23 2014-06-03 Seagate Technology Llc Block boundary resolution for mismatched logical and physical block sizes
US8549223B1 (en) 2009-10-29 2013-10-01 Symantec Corporation Systems and methods for reclaiming storage space on striped volumes
US8635422B1 (en) * 2009-10-29 2014-01-21 Symantec Corporation Systems and methods for reclaiming storage space from deleted volumes on thin-provisioned disks
US8140740B2 (en) * 2009-10-29 2012-03-20 Hewlett-Packard Development Company, L.P. Data defragmentation of solid-state memory
US9110594B2 (en) * 2009-11-04 2015-08-18 Seagate Technology Llc File management system for devices containing solid-state media
JP5593682B2 (en) * 2009-11-17 2014-09-24 セイコーエプソン株式会社 Printer, printer control method, and program
TWI423024B (en) * 2009-11-23 2014-01-11 Phison Electronics Corp Data storing method for a flash memory, and flash memory controller and flash memory storage system using the same
JP5480913B2 (en) * 2009-12-03 2014-04-23 株式会社日立製作所 Storage device and memory controller
US8176234B2 (en) * 2009-12-04 2012-05-08 International Business Machines Corporation Multi-write coding of non-volatile memories
US8176235B2 (en) * 2009-12-04 2012-05-08 International Business Machines Corporation Non-volatile memories with enhanced write performance and endurance
US8473669B2 (en) * 2009-12-07 2013-06-25 Sandisk Technologies Inc. Method and system for concurrent background and foreground operations in a non-volatile memory array
US8468294B2 (en) * 2009-12-18 2013-06-18 Sandisk Technologies Inc. Non-volatile memory with multi-gear control using on-chip folding of data
US20110153912A1 (en) * 2009-12-18 2011-06-23 Sergey Anatolievich Gorobets Maintaining Updates of Multi-Level Non-Volatile Memory in Binary Non-Volatile Memory
US8725935B2 (en) 2009-12-18 2014-05-13 Sandisk Technologies Inc. Balanced performance for on-chip folding of non-volatile memories
TWI484334B (en) * 2009-12-24 2015-05-11 Univ Nat Taiwan Method for region-based management of non-volatile memory
TWI409633B (en) * 2010-02-04 2013-09-21 Phison Electronics Corp Flash memory storage device, controller thereof, and method for programming data
CN101799820B (en) * 2010-02-08 2013-03-20 深圳市同洲电子股份有限公司 Flash memory, file system mounted method and device, data management method and device
JP2011192260A (en) * 2010-02-16 2011-09-29 Toshiba Corp Semiconductor storage device
US8671265B2 (en) 2010-03-05 2014-03-11 Solidfire, Inc. Distributed data storage system providing de-duplication of data using block identifiers
US8108447B2 (en) * 2010-03-11 2012-01-31 Symantec Corporation Systems and methods for garbage collection in deduplicated data systems
JP2011192240A (en) * 2010-03-17 2011-09-29 Sony Corp Storage apparatus and storage system
JP5066209B2 (en) 2010-03-18 2012-11-07 株式会社東芝 Controller, data storage device, and program
US8725931B1 (en) 2010-03-26 2014-05-13 Western Digital Technologies, Inc. System and method for managing the execution of memory commands in a solid-state memory
JP2011209973A (en) * 2010-03-30 2011-10-20 Hitachi Ltd Disk array configuration program, computer and computer system
US10013252B2 (en) * 2010-04-16 2018-07-03 Oracle International Corporation Software development compliance system
TW201140315A (en) * 2010-05-11 2011-11-16 Jmicron Technology Corp Method for estimating capacity usage status of storage unit, and associated memory device and controller thereof
US8782327B1 (en) * 2010-05-11 2014-07-15 Western Digital Technologies, Inc. System and method for managing execution of internal commands and host commands in a solid-state memory
US9026716B2 (en) 2010-05-12 2015-05-05 Western Digital Technologies, Inc. System and method for managing garbage collection in solid-state memory
WO2011143628A2 (en) 2010-05-13 2011-11-17 Fusion-Io, Inc. Apparatus, system, and method for conditional and atomic storage operations
US9104546B2 (en) * 2010-05-24 2015-08-11 Silicon Motion Inc. Method for performing block management using dynamic threshold, and associated memory device and controller thereof
US8683148B2 (en) * 2010-06-30 2014-03-25 Sandisk Il Ltd. Status indication when a maintenance operation is to be performed at a memory device
US9141538B2 (en) * 2010-07-07 2015-09-22 Marvell World Trade Ltd. Apparatus and method for generating descriptors to transfer data to and from non-volatile semiconductor memory of a storage drive
US8369156B2 (en) 2010-07-13 2013-02-05 Sandisk Technologies Inc. Fast random access to non-volatile storage
CN101901263A (en) * 2010-07-22 2010-12-01 华为终端有限公司 Access method and device of file system
EP2598996B1 (en) 2010-07-28 2019-07-10 SanDisk Technologies LLC Apparatus, system, and method for conditional and atomic storage operations
US8725934B2 (en) 2011-12-22 2014-05-13 Fusion-Io, Inc. Methods and appratuses for atomic storage operations
US20120036301A1 (en) * 2010-08-03 2012-02-09 Caspole Eric R Processor support for filling memory regions
US9146875B1 (en) * 2010-08-09 2015-09-29 Western Digital Technologies, Inc. Hybrid drive converting non-volatile semiconductor memory to read only based on life remaining
JP5569936B2 (en) * 2010-08-11 2014-08-13 国立大学法人 東京大学 Control device and data storage device
US8468007B1 (en) * 2010-08-13 2013-06-18 Google Inc. Emulating a peripheral mass storage device with a portable device
US8667248B1 (en) * 2010-08-31 2014-03-04 Western Digital Technologies, Inc. Data storage device using metadata and mapping table to identify valid user data on non-volatile media
US8984216B2 (en) 2010-09-09 2015-03-17 Fusion-Io, Llc Apparatus, system, and method for managing lifetime of a storage device
US9164886B1 (en) 2010-09-21 2015-10-20 Western Digital Technologies, Inc. System and method for multistage processing in a memory storage subsystem
US9021192B1 (en) 2010-09-21 2015-04-28 Western Digital Technologies, Inc. System and method for enhancing processing of memory access requests
US8452911B2 (en) 2010-09-30 2013-05-28 Sandisk Technologies Inc. Synchronized maintenance operations in a multi-bank storage system
US8769374B2 (en) 2010-10-13 2014-07-01 International Business Machines Corporation Multi-write endurance and error control coding of non-volatile memories
CN102455973A (en) * 2010-10-19 2012-05-16 厦门华侨电子股份有限公司 Method for setting data field to erase data by using residual space of Flash chip
CN102004697B (en) * 2010-10-21 2012-09-19 北京握奇数据系统有限公司 Flash recovery method and device
CN102467522B (en) * 2010-11-10 2013-09-11 中兴通讯股份有限公司 Self-programming method and device of file system based on NAND flash
US10817421B2 (en) 2010-12-13 2020-10-27 Sandisk Technologies Llc Persistent data structures
US8527693B2 (en) 2010-12-13 2013-09-03 Fusion IO, Inc. Apparatus, system, and method for auto-commit memory
US9208071B2 (en) 2010-12-13 2015-12-08 SanDisk Technologies, Inc. Apparatus, system, and method for accessing memory
US9047178B2 (en) 2010-12-13 2015-06-02 SanDisk Technologies, Inc. Auto-commit memory synchronization
US9218278B2 (en) 2010-12-13 2015-12-22 SanDisk Technologies, Inc. Auto-commit memory
US10817502B2 (en) 2010-12-13 2020-10-27 Sandisk Technologies Llc Persistent memory management
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
US9213594B2 (en) 2011-01-19 2015-12-15 Intelligent Intellectual Property Holdings 2 Llc Apparatus, system, and method for managing out-of-service conditions
JP5917163B2 (en) * 2011-01-27 2016-05-11 キヤノン株式会社 Information processing apparatus, control method and program thereof, and storage medium
WO2012106362A2 (en) 2011-01-31 2012-08-09 Fusion-Io, Inc. Apparatus, system, and method for managing eviction of data
KR20120088454A (en) * 2011-01-31 2012-08-08 에스케이하이닉스 주식회사 Non-Volatile Memory System and Apparatus, Program Method Therefor
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
US9201677B2 (en) 2011-05-23 2015-12-01 Intelligent Intellectual Property Holdings 2 Llc Managing data input/output operations
US9575842B2 (en) * 2011-02-24 2017-02-21 Ca, Inc. Multiplex backup using next relative addressing
US9141527B2 (en) 2011-02-25 2015-09-22 Intelligent Intellectual Property Holdings 2 Llc Managing cache pools
US8621328B2 (en) 2011-03-04 2013-12-31 International Business Machines Corporation Wear-focusing of non-volatile memories for improved endurance
US8972696B2 (en) 2011-03-07 2015-03-03 Microsoft Technology Licensing, Llc Pagefile reservations
FR2965079A1 (en) * 2011-03-15 2012-03-23 Continental Automotive France Method for managing e.g. Flash electrically EPROM to form residual data storage during power failure, involves utilizing non volatile memory zones electrically erasable by sector and writable through page, where sector is larger than page
US8661221B2 (en) * 2011-03-16 2014-02-25 International Business Machines Corporation Leasing fragmented storage between processes
WO2012129191A2 (en) 2011-03-18 2012-09-27 Fusion-Io, Inc. Logical interfaces for contextual storage
US9563555B2 (en) 2011-03-18 2017-02-07 Sandisk Technologies Llc Systems and methods for storage allocation
US9311229B2 (en) * 2011-03-29 2016-04-12 Blackberry Limited System and method for managing flash memory
US9342446B2 (en) 2011-03-29 2016-05-17 SanDisk Technologies, Inc. Non-volatile memory system allowing reverse eviction of data updates to non-volatile binary cache
CN102736985B (en) * 2011-03-30 2015-10-14 群联电子股份有限公司 data merging method, controller and storage device
US9009438B2 (en) 2011-06-01 2015-04-14 International Business Machines Corporation Space reclamation in multi-layered and thin provisioned storage systems
US9449692B2 (en) 2011-08-03 2016-09-20 Micron Technology, Inc. Functional data programming and reading in a memory
CN102508784B (en) * 2011-11-02 2015-01-07 杭州海康威视数字技术股份有限公司 Data storage method of flash memory card in video monitoring equipment, and system thereof
KR101298191B1 (en) 2011-11-04 2013-08-20 에스케이하이닉스 주식회사 Semiconductor Memory Apparatus, Control Circuit for Successive Program and Program Method Therefor
US8832411B2 (en) * 2011-12-14 2014-09-09 Microsoft Corporation Working set swapping using a sequentially ordered swap file
US9274945B2 (en) * 2011-12-15 2016-03-01 International Business Machines Corporation Processing unit reclaiming requests in a solid state memory device
US8762627B2 (en) 2011-12-21 2014-06-24 Sandisk Technologies Inc. Memory logical defragmentation during garbage collection
US9274937B2 (en) 2011-12-22 2016-03-01 Longitude Enterprise Flash S.A.R.L. Systems, methods, and interfaces for vector input/output operations
US9054992B2 (en) 2011-12-27 2015-06-09 Solidfire, Inc. Quality of service policy sets
US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
KR20130075018A (en) * 2011-12-27 2013-07-05 한국전자통신연구원 Data update apparatus for flash memory file system and method thereof
WO2013098463A1 (en) 2011-12-29 2013-07-04 Nokia Corporation Method for erasing data entity in memory module
KR20130078973A (en) * 2012-01-02 2013-07-10 삼성전자주식회사 Method for managing bed storage space in memory device and storage device using method thereof
US10102117B2 (en) 2012-01-12 2018-10-16 Sandisk Technologies Llc Systems and methods for cache and storage device coordination
US9251052B2 (en) 2012-01-12 2016-02-02 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for profiling a non-volatile cache having a logical-to-physical translation layer
US9767032B2 (en) 2012-01-12 2017-09-19 Sandisk Technologies Llc Systems and methods for cache endurance
US9251086B2 (en) 2012-01-24 2016-02-02 SanDisk Technologies, Inc. Apparatus, system, and method for managing a cache
US9116812B2 (en) 2012-01-27 2015-08-25 Intelligent Intellectual Property Holdings 2 Llc Systems and methods for a de-duplication cache
US8868978B2 (en) 2012-02-14 2014-10-21 International Business Machines Corporation Reclaiming discarded solid state devices
US10019353B2 (en) 2012-03-02 2018-07-10 Longitude Enterprise Flash S.A.R.L. Systems and methods for referencing data on a storage medium
DE102012006046A1 (en) * 2012-03-27 2013-10-02 Heidelberger Druckmaschinen Ag Adaptive Remote Service Protocol
EP2842039A4 (en) * 2012-04-25 2015-12-09 Hewlett Packard Development Co Dynamic memory allocation
US8681548B2 (en) 2012-05-03 2014-03-25 Sandisk Technologies Inc. Column redundancy circuitry for non-volatile memory
US9116792B2 (en) * 2012-05-18 2015-08-25 Silicon Motion, Inc. Data storage device and method for flash block management
TWI477966B (en) * 2012-05-31 2015-03-21 Silicon Motion Inc Data storage device and operating method for flash memory
US9846641B2 (en) 2012-06-18 2017-12-19 International Business Machines Corporation Variability aware wear leveling
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
US8799561B2 (en) * 2012-07-27 2014-08-05 International Business Machines Corporation Valid page threshold based garbage collection for solid state drive
US9699263B1 (en) 2012-08-17 2017-07-04 Sandisk Technologies Llc. Automatic read and write acceleration of data accessed by virtual machines
US9921954B1 (en) * 2012-08-27 2018-03-20 Avago Technologies General Ip (Singapore) Pte. Ltd. Method and system for split flash memory management between host and storage controller
US10346095B2 (en) 2012-08-31 2019-07-09 Sandisk Technologies, Llc Systems, methods, and interfaces for adaptive cache persistence
US9201784B2 (en) * 2012-09-07 2015-12-01 Kabushiki Kaisha Toshiba Semiconductor storage device and method for controlling nonvolatile semiconductor memory
US10282286B2 (en) * 2012-09-14 2019-05-07 Micron Technology, Inc. Address mapping using a data unit type that is variable
US10509776B2 (en) 2012-09-24 2019-12-17 Sandisk Technologies Llc Time sequence data management
US10318495B2 (en) 2012-09-24 2019-06-11 Sandisk Technologies Llc Snapshots for a non-volatile device
US9490035B2 (en) 2012-09-28 2016-11-08 SanDisk Technologies, Inc. Centralized variable rate serializer and deserializer for bad column management
US9076506B2 (en) 2012-09-28 2015-07-07 Sandisk Technologies Inc. Variable rate parallel to serial shift register
US8897080B2 (en) 2012-09-28 2014-11-25 Sandisk Technologies Inc. Variable rate serial to parallel shift register
TWI479492B (en) * 2012-11-20 2015-04-01 Phison Electronics Corp Memory storage device, memory controller thereof, and method for programming data thereof
US9411718B2 (en) * 2012-12-21 2016-08-09 Seagate Technology Llc Method to apply fine grain wear leveling and garbage collection
US9430376B2 (en) * 2012-12-26 2016-08-30 Western Digital Technologies, Inc. Priority-based garbage collection for data storage systems
US9612948B2 (en) 2012-12-27 2017-04-04 Sandisk Technologies Llc Reads and writes between a contiguous data block and noncontiguous sets of logical address blocks in a persistent storage device
US9348746B2 (en) 2012-12-31 2016-05-24 Sandisk Technologies Method and system for managing block reclaim operations in a multi-layer memory
US9734911B2 (en) 2012-12-31 2017-08-15 Sandisk Technologies Llc Method and system for asynchronous die operations in a non-volatile memory
US8873284B2 (en) 2012-12-31 2014-10-28 Sandisk Technologies Inc. Method and system for program scheduling 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
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
US11249652B1 (en) 2013-01-28 2022-02-15 Radian Memory Systems, Inc. Maintenance of nonvolatile memory on host selected namespaces by a common memory controller
US9652376B2 (en) * 2013-01-28 2017-05-16 Radian Memory Systems, Inc. Cooperative flash memory control
JP5619198B2 (en) * 2013-02-04 2014-11-05 株式会社フィックスターズ Information processing apparatus, information processing method, and program
US9361040B1 (en) * 2013-02-27 2016-06-07 Marvell International Ltd. Systems and methods for data storage management
US9383924B1 (en) * 2013-02-27 2016-07-05 Netapp, Inc. Storage space reclamation on volumes with thin provisioning capability
US9870830B1 (en) 2013-03-14 2018-01-16 Sandisk Technologies Llc Optimal multilevel sensing for reading data from a storage medium
US9842053B2 (en) 2013-03-15 2017-12-12 Sandisk Technologies Llc Systems and methods for persistent cache logging
US8656255B1 (en) * 2013-03-15 2014-02-18 Avalanche Technology, Inc. Method for reducing effective raw bit error rate in multi-level cell NAND flash memory
US10558561B2 (en) 2013-04-16 2020-02-11 Sandisk Technologies Llc Systems and methods for storage metadata management
US10102144B2 (en) 2013-04-16 2018-10-16 Sandisk Technologies Llc Systems, methods and interfaces for data virtualization
US10417123B1 (en) * 2013-05-16 2019-09-17 Western Digital Technologies, Inc. Systems and methods for improving garbage collection and wear leveling performance in data storage systems
CN103268291B (en) * 2013-05-23 2016-02-24 清华大学 The method of persistence index metadata is postponed in flash-memory storage system
US9256371B2 (en) 2013-05-28 2016-02-09 Globalfoundries Inc. Implementing reinforcement learning based flash control
US9349450B2 (en) 2013-06-10 2016-05-24 Micron Technology, Inc. Memory devices and memory operational methods including single erase operation of conductive bridge memory cells
US10102148B2 (en) 2013-06-13 2018-10-16 Microsoft Technology Licensing, Llc Page-based compressed storage management
US9690837B1 (en) * 2013-06-28 2017-06-27 EMC IP Holding Company LLC Techniques for preserving redundant copies of metadata in a data storage system employing de-duplication
US9785545B2 (en) * 2013-07-15 2017-10-10 Cnex Labs, Inc. Method and apparatus for providing dual memory access to non-volatile memory
US9477484B2 (en) 2013-07-23 2016-10-25 Samsung Electronics Co., Ltd. System and method for boot acceleration of a data processing system wherein a nonvolatile memory is pre-configured before boot time
US9524235B1 (en) 2013-07-25 2016-12-20 Sandisk Technologies Llc Local hash value generation in non-volatile data storage systems
US9842128B2 (en) 2013-08-01 2017-12-12 Sandisk Technologies Llc Systems and methods for atomic storage operations
US9639463B1 (en) * 2013-08-26 2017-05-02 Sandisk Technologies Llc Heuristic aware garbage collection scheme in storage systems
JP6271939B2 (en) * 2013-10-11 2018-01-31 キヤノン株式会社 Information processing apparatus, control method therefor, and program
US10019320B2 (en) 2013-10-18 2018-07-10 Sandisk Technologies Llc Systems and methods for distributed atomic storage operations
US10019352B2 (en) 2013-10-18 2018-07-10 Sandisk Technologies Llc Systems and methods for adaptive reserve storage
US10073630B2 (en) 2013-11-08 2018-09-11 Sandisk Technologies Llc Systems and methods for log coordination
US9569447B2 (en) * 2013-11-08 2017-02-14 Texas Instruments Incorporated File access method and system thereof
US9703816B2 (en) 2013-11-19 2017-07-11 Sandisk Technologies Llc Method and system for forward reference logging in a persistent datastore
US9520197B2 (en) 2013-11-22 2016-12-13 Sandisk Technologies Llc Adaptive erase of a storage device
US9520162B2 (en) 2013-11-27 2016-12-13 Sandisk Technologies Llc DIMM device controller supervisor
US9582058B2 (en) 2013-11-29 2017-02-28 Sandisk Technologies Llc Power inrush management of storage devices
CN104699688A (en) * 2013-12-04 2015-06-10 杭州鹰湾科技有限公司 File searching method and electronic device
KR20150068747A (en) 2013-12-12 2015-06-22 삼성전자주식회사 on-volatile memory system and host communicating with the same
WO2015089488A1 (en) 2013-12-12 2015-06-18 Memory Technologies Llc Channel optimized storage modules
CN104731710B (en) * 2013-12-18 2018-06-29 群联电子股份有限公司 Storage management method, memorizer control circuit unit and memorizer memory devices
US20150186257A1 (en) * 2013-12-26 2015-07-02 Anand S. Ramalingam Managing a transfer buffer for a non-volatile memory
CA2881206A1 (en) 2014-02-07 2015-08-07 Andrew WARFIELD Methods, systems and devices relating to data storage interfaces for managing address spaces in data storage devices
US20150244795A1 (en) 2014-02-21 2015-08-27 Solidfire, Inc. Data syncing in a distributed system
US9703636B2 (en) 2014-03-01 2017-07-11 Sandisk Technologies Llc Firmware reversion trigger and control
US9454448B2 (en) 2014-03-19 2016-09-27 Sandisk Technologies Llc Fault testing in storage devices
US9448876B2 (en) 2014-03-19 2016-09-20 Sandisk Technologies Llc Fault detection and prediction in storage devices
US11537290B2 (en) 2014-03-20 2022-12-27 International Business Machines Corporation Managing high performance storage systems with hybrid storage technologies
US9684625B2 (en) 2014-03-21 2017-06-20 Microsoft Technology Licensing, Llc Asynchronously prefetching sharable memory pages
KR102164617B1 (en) 2014-03-24 2020-10-12 삼성전자주식회사 Method for operating a data storage device and method for operating a system including the same
US9626399B2 (en) 2014-03-31 2017-04-18 Sandisk Technologies Llc Conditional updates for reducing frequency of data modification operations
US9626400B2 (en) 2014-03-31 2017-04-18 Sandisk Technologies Llc Compaction of information in tiered data structure
US9697267B2 (en) 2014-04-03 2017-07-04 Sandisk Technologies Llc Methods and systems for performing efficient snapshots in tiered data structures
US9996303B2 (en) * 2014-05-08 2018-06-12 Kabushiki Kaisha Toshiba Hybrid-HDD that gives up old NAND data at the last moment
KR102211709B1 (en) 2014-05-19 2021-02-02 삼성전자주식회사 Non-volatile Memory System and Host Device improving a signal characteristic and Operating Method of thereof
US9383926B2 (en) * 2014-05-27 2016-07-05 Kabushiki Kaisha Toshiba Host-controlled garbage collection
US10114557B2 (en) 2014-05-30 2018-10-30 Sandisk Technologies Llc Identification of hot regions to enhance performance and endurance of a non-volatile storage device
US10656842B2 (en) 2014-05-30 2020-05-19 Sandisk Technologies Llc Using history of I/O sizes and I/O sequences to trigger coalesced writes in a non-volatile storage device
US10162748B2 (en) 2014-05-30 2018-12-25 Sandisk Technologies Llc Prioritizing garbage collection and block allocation based on I/O history for logical address regions
US10146448B2 (en) 2014-05-30 2018-12-04 Sandisk Technologies Llc Using history of I/O sequences to trigger cached read ahead in a non-volatile storage device
US9703491B2 (en) 2014-05-30 2017-07-11 Sandisk Technologies Llc Using history of unaligned writes to cache data and avoid read-modify-writes in a non-volatile storage device
US10656840B2 (en) 2014-05-30 2020-05-19 Sandisk Technologies Llc Real-time I/O pattern recognition to enhance performance and endurance of a storage device
US10372613B2 (en) 2014-05-30 2019-08-06 Sandisk Technologies Llc Using sub-region I/O history to cache repeatedly accessed sub-regions in a non-volatile storage device
KR102148389B1 (en) 2014-06-11 2020-08-27 삼성전자주식회사 Memory system having overwriting operation and therefore operation control method
US9652381B2 (en) 2014-06-19 2017-05-16 Sandisk Technologies Llc Sub-block garbage collection
TWI554944B (en) * 2014-06-20 2016-10-21 慧榮科技股份有限公司 Flash memory controlling apparatus, flash memory controlling system and flash memory controlling method
JP6119682B2 (en) * 2014-06-27 2017-04-26 株式会社デンソー Electronic control unit
TWI524180B (en) * 2014-08-15 2016-03-01 財團法人資訊工業策進會 Byte addressable storing system
US9600409B2 (en) * 2014-08-29 2017-03-21 EMC IP Holding Company LLC Method and system for garbage collection in a storage system based on longevity of stored data
US9652382B1 (en) * 2014-09-04 2017-05-16 Sk Hynix Memory Solutions Inc. Look-ahead garbage collection for NAND flash based storage
US10552085B1 (en) 2014-09-09 2020-02-04 Radian Memory Systems, Inc. Techniques for directed data migration
US9542118B1 (en) 2014-09-09 2017-01-10 Radian Memory Systems, Inc. Expositive flash memory control
JP2016057876A (en) * 2014-09-10 2016-04-21 富士通株式会社 Information processing apparatus, input/output control program, and input/output control method
US9934872B2 (en) 2014-10-30 2018-04-03 Sandisk Technologies Llc Erase stress and delta erase loop count methods for various fail modes in non-volatile memory
US9658966B2 (en) 2014-11-24 2017-05-23 Sandisk Technologies Llc Systems and methods of write cache flushing
US20160188495A1 (en) * 2014-12-26 2016-06-30 Intel Corporation Event triggered erasure for data security
US9224502B1 (en) 2015-01-14 2015-12-29 Sandisk Technologies Inc. Techniques for detection and treating memory hole to local interconnect marginality defects
KR102277521B1 (en) 2015-01-23 2021-07-16 삼성전자주식회사 Storage device and read reclaim and reading method thereof
CN105988935B (en) * 2015-02-04 2019-04-23 群联电子股份有限公司 Smart card management method, memory storage apparatus and memorizer control circuit unit
US10032524B2 (en) 2015-02-09 2018-07-24 Sandisk Technologies Llc Techniques for determining local interconnect defects
US9632924B2 (en) 2015-03-02 2017-04-25 Microsoft Technology Licensing, Llc Using memory compression to reduce memory commit charge
US9946607B2 (en) 2015-03-04 2018-04-17 Sandisk Technologies Llc Systems and methods for storage error management
JP2016170583A (en) * 2015-03-12 2016-09-23 株式会社東芝 Memory system and information processing system
US9269446B1 (en) 2015-04-08 2016-02-23 Sandisk Technologies Inc. Methods to improve programming of slow cells
US9564219B2 (en) 2015-04-08 2017-02-07 Sandisk Technologies Llc Current based detection and recording of memory hole-interconnect spacing defects
US10037270B2 (en) 2015-04-14 2018-07-31 Microsoft Technology Licensing, Llc Reducing memory commit charge when compressing memory
US9811462B2 (en) 2015-04-30 2017-11-07 Toshiba Memory Corporation Memory system executing garbage collection
KR102402783B1 (en) * 2015-05-11 2022-05-27 삼성전자 주식회사 Electronic device for merging pages and method thereof
US10009438B2 (en) 2015-05-20 2018-06-26 Sandisk Technologies Llc Transaction log acceleration
US10289327B2 (en) 2015-06-05 2019-05-14 Western Digital Technologies, Inc. Scheduling scheme(s) for a multi-die storage device
US9875053B2 (en) 2015-06-05 2018-01-23 Western Digital Technologies, Inc. Scheduling scheme(s) for a multi-die storage device
US10884945B2 (en) 2015-06-30 2021-01-05 International Business Machines Corporation Memory state indicator check operations
US10248418B2 (en) 2015-06-30 2019-04-02 International Business Machines Corporation Cleared memory indicator
US10635307B2 (en) 2015-06-30 2020-04-28 International Business Machines Corporation Memory state indicator
CN106326136A (en) * 2015-07-02 2017-01-11 广明光电股份有限公司 Method for collecting garage block in solid state disk
CN106325764B (en) * 2015-07-08 2021-02-26 群联电子股份有限公司 Memory management method, memory control circuit unit and memory storage device
JP2016026345A (en) * 2015-09-03 2016-02-12 マイクロン テクノロジー， インク． Temporary stop of memory operation for shortening reading standby time in memory array
US10268400B2 (en) * 2015-09-03 2019-04-23 Sandisk Technologies Llc System and method for file detection and usage during compaction
KR102387956B1 (en) 2015-09-09 2022-04-19 삼성전자주식회사 Memory system including nonvolatile memory device
KR102501751B1 (en) * 2015-09-22 2023-02-20 삼성전자주식회사 Memory Controller, Non-volatile Memory System and Operating Method thereof
EP3353627B1 (en) * 2015-09-25 2022-01-19 Hitachi Vantara LLC Adaptive storage reclamation
US9778855B2 (en) 2015-10-30 2017-10-03 Sandisk Technologies Llc System and method for precision interleaving of data writes in a non-volatile memory
US10042553B2 (en) 2015-10-30 2018-08-07 Sandisk Technologies Llc Method and system for programming a multi-layer non-volatile memory having a single fold data path
US10102119B2 (en) * 2015-10-30 2018-10-16 Sandisk Technologies Llc Garbage collection based on queued and/or selected write commands
US10133490B2 (en) 2015-10-30 2018-11-20 Sandisk Technologies Llc System and method for managing extended maintenance scheduling 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
KR102468992B1 (en) * 2015-11-06 2022-11-22 에스케이하이닉스 주식회사 Memory device and operating method therefof
US10303371B2 (en) 2015-12-02 2019-05-28 Toshiba Memory Corporation Data storage device that stabilizes write latency
TWI609323B (en) * 2016-01-29 2017-12-21 捷鼎國際股份有限公司 Data storing method and system thereof
US10929022B2 (en) 2016-04-25 2021-02-23 Netapp. Inc. Space savings reporting for storage system supporting snapshot and clones
US10739996B1 (en) 2016-07-18 2020-08-11 Seagate Technology Llc Enhanced garbage collection
US10481830B2 (en) * 2016-07-25 2019-11-19 Sandisk Technologies Llc Selectively throttling host reads for read disturbs in non-volatile memory system
KR20180014975A (en) * 2016-08-02 2018-02-12 에스케이하이닉스 주식회사 Data storage device and operating method thereof
US10642763B2 (en) 2016-09-20 2020-05-05 Netapp, Inc. Quality of service policy sets
KR102618699B1 (en) 2016-09-28 2024-01-02 삼성전자주식회사 Computing system including storage device controlled by host
KR102697927B1 (en) 2016-11-11 2024-08-22 삼성전자주식회사 Storage device and method of operating the same
US10255179B2 (en) * 2016-12-30 2019-04-09 Western Digital Technologies, Inc. Garbage collection read throttling
CN106598508A (en) * 2016-12-30 2017-04-26 郑州云海信息技术有限公司 Solid-state hard disc and write-in arbitrating method and system thereof
US10838634B1 (en) * 2016-12-30 2020-11-17 EMC IP Holding Company LLC Managing storage capacity in version families having both writable and read-only data objects
CN108509349B (en) * 2017-02-27 2022-10-14 得一微电子股份有限公司 NAND FLASH data source block recovery method and solid state disk
JP6765322B2 (en) * 2017-02-28 2020-10-07 キオクシア株式会社 Memory system and control method
CN108572887A (en) * 2017-03-14 2018-09-25 上海骐宏电驱动科技有限公司 Data detection bearing calibration
CN107015764B (en) * 2017-03-17 2020-03-27 深圳市江波龙电子股份有限公司 Data processing method and device for Nand flash and Nand flash
US11893265B2 (en) * 2017-05-02 2024-02-06 Google Llc Garbage collection for data storage
US10521106B2 (en) 2017-06-27 2019-12-31 International Business Machines Corporation Smart element filtering method via gestures
US10379765B2 (en) * 2017-06-27 2019-08-13 Western Digital Technologies, Inc. Geometry-aware command scheduling
KR102430791B1 (en) * 2017-07-19 2022-08-10 에스케이하이닉스 주식회사 Controller and operation method thereof
CN107678684B (en) * 2017-08-22 2020-11-10 深圳市硅格半导体有限公司 Invalid data clearing method and device of memory and memory
US11100996B2 (en) 2017-08-30 2021-08-24 Micron Technology, Inc. Log data storage for flash memory
CN110709810B (en) * 2017-10-09 2021-12-24 华为技术有限公司 Junk data cleaning method and equipment
KR20190052368A (en) * 2017-11-08 2019-05-16 에스케이하이닉스 주식회사 Memory system and operation method thereof
CN108021630B (en) * 2017-11-21 2021-03-30 深圳市雷鸟网络传媒有限公司 Junk file cleaning method, intelligent terminal and computer readable storage medium
US10445230B2 (en) * 2017-12-08 2019-10-15 Macronix International Co., Ltd. Managing block arrangement of super blocks
US10642602B2 (en) * 2017-12-12 2020-05-05 Nxp Usa, Inc. NVM architecture with OTA support
US11099760B2 (en) * 2017-12-14 2021-08-24 Intel Corporation Background data refresh using a system timestamp in storage devices
TWI644207B (en) * 2017-12-29 2018-12-11 國科美國研究實驗室 Method for garbage collection of data storage device
CN114035749B (en) * 2018-01-12 2023-02-28 珠海极海半导体有限公司 Electronic equipment and Flash memory
CN110109868B (en) * 2018-01-18 2023-07-18 伊姆西Ip控股有限责任公司 Method, apparatus and computer program product for indexing files
JP6443571B1 (en) * 2018-02-02 2018-12-26 富士通株式会社 Storage control device, storage control method, and storage control program
KR20190102790A (en) * 2018-02-27 2019-09-04 에스케이하이닉스 주식회사 Controller and method for operating the same, and memory system including the same
US10884916B2 (en) * 2018-03-29 2021-01-05 Intel Corporation Non-volatile file update media
CN108536614A (en) * 2018-03-30 2018-09-14 天津麒麟信息技术有限公司 A kind of direct random write implementation method of Flash, device and storage medium
KR20190120966A (en) * 2018-04-17 2019-10-25 에스케이하이닉스 주식회사 Storage device and operating method thereof
KR102603916B1 (en) * 2018-04-25 2023-11-21 삼성전자주식회사 Storage device comprising nonvolatile memory device and controller
US11301376B2 (en) 2018-06-11 2022-04-12 Seagate Technology Llc Data storage device with wear range optimization
CN110633225B (en) 2018-06-25 2022-11-15 慧荣科技股份有限公司 Apparatus and method for generating entity storage comparison table
KR20200016075A (en) * 2018-08-06 2020-02-14 에스케이하이닉스 주식회사 Apparatus and method for searching valid data in memory system
US10891224B2 (en) * 2018-09-06 2021-01-12 Micron Technology, Inc. Maintaining data consistency in a memory sub system that uses hybrid wear leveling operations
TWI703438B (en) 2018-09-11 2020-09-01 慧榮科技股份有限公司 Mapping table updating method
US11175802B2 (en) * 2018-09-21 2021-11-16 Sap Se Configuration object deletion manager
KR102645142B1 (en) * 2018-10-25 2024-03-07 삼성전자주식회사 Storage devices, methods and non-volatile memory devices for performing garbage collection using estimated valid pages
TWI709042B (en) * 2018-11-08 2020-11-01 慧榮科技股份有限公司 Method and apparatus for performing mapping information management regarding redundant array of independent disks, and associated storage system
CN112997162A (en) * 2018-11-20 2021-06-18 华为技术有限公司 Method and device for deleting index entry in memory
KR20200067035A (en) * 2018-12-03 2020-06-11 에스케이하이닉스 주식회사 Data Storage Device and Operation Method Thereof, Storage System Having the Same
KR20200073017A (en) * 2018-12-13 2020-06-23 에스케이하이닉스 주식회사 Data storage device and operating method thereof
JP7435470B2 (en) * 2018-12-19 2024-02-21 ソニーグループ株式会社 Information processing device, information processing method, and information processing program
US10915444B2 (en) * 2018-12-27 2021-02-09 Micron Technology, Inc. Garbage collection candidate selection using block overwrite rate
US11288185B2 (en) 2019-01-03 2022-03-29 Silicon Motion, Inc. Method and computer program product for performing data writes into a flash memory
CN111399750B (en) * 2019-01-03 2023-05-26 慧荣科技股份有限公司 Flash memory data writing method and computer readable storage medium
US10976950B1 (en) * 2019-01-15 2021-04-13 Twitter, Inc. Distributed dataset modification, retention, and replication
US11113270B2 (en) 2019-01-24 2021-09-07 EMC IP Holding Company LLC Storing a non-ordered associative array of pairs using an append-only storage medium
US10658045B1 (en) * 2019-05-15 2020-05-19 Western Digital Technologies, Inc. Enhanced solid-state drive write performance with background erase
US11327809B2 (en) 2019-06-19 2022-05-10 International Business Machines Corporation Virtual machine memory removal increment selection
EP3993273A4 (en) * 2019-07-22 2022-07-27 Huawei Technologies Co., Ltd. Method and apparatus for data compression in storage system, device, and readable storage medium
US11508021B2 (en) * 2019-07-22 2022-11-22 Vmware, Inc. Processes and systems that determine sustainability of a virtual infrastructure of a distributed computing system
KR20210012329A (en) * 2019-07-24 2021-02-03 에스케이하이닉스 주식회사 Memory system and operating method of the memory system
TWI688956B (en) * 2019-08-28 2020-03-21 群聯電子股份有限公司 Memory control method, memory storage device and memory control circuit unit
CN112486404B (en) * 2019-09-12 2024-07-02 伊姆西Ip控股有限责任公司 Method, apparatus and computer program product for managing memory blocks
US11494311B2 (en) 2019-09-17 2022-11-08 Micron Technology, Inc. Page table hooks to memory types
US10963396B1 (en) 2019-09-17 2021-03-30 Micron Technology, Inc. Memory system for binding data to a memory namespace
US11269780B2 (en) 2019-09-17 2022-03-08 Micron Technology, Inc. Mapping non-typed memory access to typed memory access
US11650742B2 (en) 2019-09-17 2023-05-16 Micron Technology, Inc. Accessing stored metadata to identify memory devices in which data is stored
KR20210044564A (en) 2019-10-15 2021-04-23 삼성전자주식회사 Storage device and garbage collection method thereof
US11762569B2 (en) * 2019-10-29 2023-09-19 International Business Machines Corporation Workload based relief valve activation for hybrid controller architectures
KR20210051873A (en) * 2019-10-31 2021-05-10 에스케이하이닉스 주식회사 Controller and memory system
CN111049729A (en) * 2019-11-29 2020-04-21 苏州浪潮智能科技有限公司 Persistent message transmission method and device
US11157179B2 (en) 2019-12-03 2021-10-26 Pure Storage, Inc. Dynamic allocation of blocks of a storage device based on power loss protection
JP2021099642A (en) * 2019-12-20 2021-07-01 キヤノン株式会社 Information processing device and method for controlling information processing device
KR20210100265A (en) 2020-02-06 2021-08-17 삼성전자주식회사 Storage device and method for operating the same
US11748277B2 (en) 2020-03-05 2023-09-05 Seagate Technology, Llc Client input/output (I/O) access rate variation compensation
US11704035B2 (en) 2020-03-30 2023-07-18 Pure Storage, Inc. Unified storage on block containers
US12079162B2 (en) 2020-03-30 2024-09-03 Pure Storage, Inc. Snapshot management in a storage system
CN113495681B (en) * 2020-04-07 2024-09-24 杭州萤石软件有限公司 NAND FLASH file data access method, NAND FLASH file data access device and storage medium
US11599546B2 (en) 2020-05-01 2023-03-07 EMC IP Holding Company LLC Stream browser for data streams
US11604759B2 (en) 2020-05-01 2023-03-14 EMC IP Holding Company LLC Retention management for data streams
US11586385B1 (en) 2020-05-06 2023-02-21 Radian Memory Systems, Inc. Techniques for managing writes in nonvolatile memory
KR20210138996A (en) 2020-05-13 2021-11-22 삼성전자주식회사 Memory device, storage device including the same and method of operating the storage device
US11599420B2 (en) 2020-07-30 2023-03-07 EMC IP Holding Company LLC Ordered event stream event retention
US11567665B2 (en) * 2020-08-31 2023-01-31 Micron Technology, Inc. Data dispersion-based memory management
US11513871B2 (en) 2020-09-30 2022-11-29 EMC IP Holding Company LLC Employing triggered retention in an ordered event stream storage system
US11755555B2 (en) 2020-10-06 2023-09-12 EMC IP Holding Company LLC Storing an ordered associative array of pairs using an append-only storage medium
KR20220048864A (en) * 2020-10-13 2022-04-20 에스케이하이닉스 주식회사 Storage device and operating method thereof
US11599293B2 (en) 2020-10-14 2023-03-07 EMC IP Holding Company LLC Consistent data stream replication and reconstruction in a streaming data storage platform
KR20220060385A (en) * 2020-11-04 2022-05-11 에스케이하이닉스 주식회사 Storage device and operating method thereof
US11494111B2 (en) * 2020-12-17 2022-11-08 Micron Technology, Inc. Data operation based on valid memory unit count
US11556270B2 (en) * 2021-01-07 2023-01-17 EMC IP Holding Company LLC Leveraging garbage collection for raid transformation
US11816065B2 (en) 2021-01-11 2023-11-14 EMC IP Holding Company LLC Event level retention management for data streams
US20220222008A1 (en) * 2021-01-14 2022-07-14 Silicon Motion, Inc. Method for managing flash memory module and associated flash memory controller and memory device
US12099513B2 (en) 2021-01-19 2024-09-24 EMC IP Holding Company LLC Ordered event stream event annulment in an ordered event stream storage system
CN114780014A (en) * 2021-01-22 2022-07-22 伊姆西Ip控股有限责任公司 Method, electronic device and computer program product for managing metadata storage unit
TWI766582B (en) * 2021-02-17 2022-06-01 群聯電子股份有限公司 Valid data merging method, memory storage device and memory control circuit unit
US12099742B2 (en) * 2021-03-15 2024-09-24 Pure Storage, Inc. Utilizing programming page size granularity to optimize data segment storage in a storage system
JP7566676B2 (en) 2021-03-22 2024-10-15 キオクシア株式会社 MEMORY SYSTEM AND INFORMATION PROCESSING SYSTEM
US11775197B2 (en) * 2021-03-25 2023-10-03 Kyocera Document Solutions Inc. Single command for reading then clearing dynamic random access memory
US11740828B2 (en) * 2021-04-06 2023-08-29 EMC IP Holding Company LLC Data expiration for stream storages
US12001881B2 (en) 2021-04-12 2024-06-04 EMC IP Holding Company LLC Event prioritization for an ordered event stream
US11740821B2 (en) * 2021-04-12 2023-08-29 EMC IP Holding Company LLC Cost-aware garbage collection for cloud storage
US11500578B2 (en) * 2021-04-19 2022-11-15 Micron Technology, Inc. Memory access threshold based memory management
US11954537B2 (en) 2021-04-22 2024-04-09 EMC IP Holding Company LLC Information-unit based scaling of an ordered event stream
US11681460B2 (en) 2021-06-03 2023-06-20 EMC IP Holding Company LLC Scaling of an ordered event stream based on a writer group characteristic
US11513720B1 (en) * 2021-06-11 2022-11-29 Western Digital Technologies, Inc. Data storage device having predictive analytics
US11543993B1 (en) * 2021-06-17 2023-01-03 Western Digital Technologies, Inc. Fast garbage collection in zoned namespaces SSDs
US11735282B2 (en) 2021-07-22 2023-08-22 EMC IP Holding Company LLC Test data verification for an ordered event stream storage system
US11733893B2 (en) * 2021-07-28 2023-08-22 International Business Machines Corporation Management of flash storage media
US11907564B2 (en) * 2021-08-03 2024-02-20 Yadro International Ltd. Method of and system for initiating garbage collection requests
US20230082636A1 (en) * 2021-09-16 2023-03-16 Micron Technology, Inc. Parity data modification for partial stripe data update
US11922047B2 (en) * 2021-09-16 2024-03-05 EMC IP Holding Company LLC Using RPO as an optimization target for DataDomain garbage collection
JP2023044330A (en) * 2021-09-17 2023-03-30 キオクシア株式会社 Memory system and control method
US11847334B2 (en) * 2021-09-23 2023-12-19 EMC IP Holding Company LLC Method or apparatus to integrate physical file verification and garbage collection (GC) by tracking special segments
US11971850B2 (en) 2021-10-15 2024-04-30 EMC IP Holding Company LLC Demoted data retention via a tiered ordered event stream data storage system
US11822813B2 (en) 2021-12-28 2023-11-21 Samsung Electronics Co., Ltd. Storage device, operation method of storage device, and storage system using the same
JP2024508064A (en) * 2022-01-28 2024-02-22 長江存儲科技有限責任公司 Memory, memory control method and memory system
US12019899B2 (en) * 2022-03-03 2024-06-25 Western Digital Technologies, Inc. Data relocation with protection for open relocation destination blocks
US11886735B2 (en) * 2022-03-22 2024-01-30 Micron Technology, Inc. Data movement based on address table activity
US11934656B2 (en) * 2022-04-11 2024-03-19 Netapp, Inc. Garbage collection and bin synchronization for distributed storage architecture
US11941297B2 (en) 2022-04-11 2024-03-26 Netapp, Inc. Garbage collection and bin synchronization for distributed storage architecture
US11947452B2 (en) * 2022-06-01 2024-04-02 Micron Technology, Inc. Controlling variation of valid data counts in garbage collection source blocks
US20240012579A1 (en) * 2022-07-06 2024-01-11 Samsung Electronics Co., Ltd. Systems, methods, and apparatus for data placement in a storage device
US11977758B2 (en) * 2022-08-12 2024-05-07 Micron Technology, Inc. Assigning blocks of memory systems
CN115292247B (en) * 2022-09-28 2022-12-06 北京鼎轩科技有限责任公司 File reading method and device, electronic equipment and storage medium
US11960742B1 (en) * 2022-10-14 2024-04-16 Oracle International Corporation High-performance, block-level fail atomicity on byte-level non-volatile media
US12056378B1 (en) * 2023-01-27 2024-08-06 Dell Products L.P. Storage management system and method
US20240295981A1 (en) * 2023-03-03 2024-09-05 Western Digital Technologies, Inc. Data Storage Device and Method for Host-Assisted Efficient Handling of Multiple Versions of Data
CN116610596B (en) * 2023-07-19 2023-10-03 合肥康芯威存储技术有限公司 Memory device and data processing method thereof
CN116610597B (en) * 2023-07-20 2023-10-17 合肥康芯威存储技术有限公司 Storage device and garbage recycling control method thereof
CN117632039B (en) * 2024-01-25 2024-05-03 合肥兆芯电子有限公司 Memory management method, memory storage device and memory control circuit unit

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020184436A1 (en) * 2001-06-04 2002-12-05 Samsung Electronics Co., Ltd. Flash memory management method
US20030229753A1 (en) * 2002-06-10 2003-12-11 Samsung Electronics Co., Ltd. Flash memory file system
US20040073727A1 (en) * 2002-07-29 2004-04-15 M-Systems Flash Disk Pioneers, Ltd. Portable storage media as file servers
WO2004040453A2 (en) * 2002-10-28 2004-05-13 Sandisk Corporation Method and apparatus for grouping pages within a block
WO2005066793A2 (en) * 2003-12-30 2005-07-21 Sandisk Corporation Non-volatile memory and method with non-sequential update block management
US20060161724A1 (en) * 2005-01-20 2006-07-20 Bennett Alan D Scheduling of housekeeping operations in flash memory systems

Family Cites Families (206)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US614509A (en) * 1898-11-22 Hose-coupling
US5774A (en) * 1848-09-19 Steam-hammer
US676632A (en) * 1901-01-30 1901-06-18 Frederick G Rogers Boiler.
US4369754A (en) * 1980-11-04 1983-01-25 Bob Lofman Vacuum responsive injection system for engines
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
US4864511A (en) 1987-01-27 1989-09-05 Storage Technology Corporation Automated cartridge system
GB2204973A (en) 1987-05-19 1988-11-23 Gen Electric Co Plc Data processing system
JP3015377B2 (en) 1988-08-26 2000-03-06 株式会社東芝 IC card
DE69033438T2 (en) 1989-04-13 2000-07-06 Sandisk Corp., Santa Clara Exchange of faulty memory cells of an EEprom matrix
US5388086A (en) * 1989-06-13 1995-02-07 Kabushiki Kaisha Toshiba Electro-magnetic actuator for driving an objective lens
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 (en) * 1992-02-20 1993-09-10 Fujitsu Ltd Flash memory using method
JP2839060B2 (en) 1992-03-02 1998-12-16 インターナショナル・ビジネス・マシーンズ・コーポレイション Data processing system and data processing method
US5628014A (en) 1992-03-20 1997-05-06 Paranode, Inc. Methods and apparatus for node caching at the file level
JP3017892B2 (en) * 1992-09-30 2000-03-13 株式会社東芝 File management device
US5479633A (en) 1992-10-30 1995-12-26 Intel Corporation Method of controlling clean-up of a solid state memory disk storing floating sector data
US5341339A (en) 1992-10-30 1994-08-23 Intel Corporation Method for wear leveling in a flash EEPROM memory
US5454103A (en) * 1993-02-01 1995-09-26 Lsc, Inc. Method and apparatus for file storage allocation for secondary storage using large and small file blocks
US5581723A (en) 1993-02-19 1996-12-03 Intel Corporation Method and apparatus for retaining flash block structure data during erase operations in a flash EEPROM memory array
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
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
US5640529A (en) 1993-07-29 1997-06-17 Intel Corporation Method and system for performing clean-up of a solid state disk during host command execution
US7137011B1 (en) 1993-09-01 2006-11-14 Sandisk Corporation Removable mother/daughter peripheral card
KR0169267B1 (en) * 1993-09-21 1999-02-01 사토 후미오 Nonvolatile semiconductor memory device
US5553261A (en) * 1994-04-01 1996-09-03 Intel Corporation Method of performing clean-up of a solid state disk while executing a read command
JP3507132B2 (en) 1994-06-29 2004-03-15 株式会社日立製作所 Storage device using flash memory and storage control method thereof
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
US5754817A (en) * 1994-09-29 1998-05-19 Intel Corporation Execution in place of a file stored non-contiguously in a non-volatile memory
ES2101584T3 (en) 1994-09-30 1997-07-01 Sel Alcatel Ag METHOD OF MANAGING AN INSTANT MEMORY.
JP2669365B2 (en) * 1994-11-24 1997-10-27 日本電気株式会社 Rewritable ROM file device
US5568423A (en) 1995-04-14 1996-10-22 Unisys Corporation Flash memory wear leveling system providing immediate direct access to microprocessor
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
FR2740237B1 (en) 1995-10-18 1997-11-14 Schlumberger Ind Sa ELECTRONIC COMPONENT WITH SYNCHRONIZED MEMORY
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
US5875477A (en) * 1995-12-22 1999-02-23 Intel Corporation Method and apparatus for error management in a solid state disk drive using primary and secondary logical sector numbers
US5799168A (en) 1996-01-05 1998-08-25 M-Systems Flash Disk Pioneers Ltd. Standardized flash controller
US5867341A (en) 1996-01-30 1999-02-02 Seagate Technology, Inc. Disc drive system using multiple pairs of embedded servo bursts
US6038571A (en) * 1996-01-31 2000-03-14 Kabushiki Kaisha Toshiba Resource management method and apparatus for information processing system of multitasking facility
US5787445A (en) 1996-03-07 1998-07-28 Norris Communications Corporation Operating system including improved file management for use in devices utilizing flash memory as main memory
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
JPH09319645A (en) 1996-05-24 1997-12-12 Nec Corp Non-volatile semiconductor memory device
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 (en) 1996-08-01 1999-01-29 Solaic Sa CARD WITH INTEGRATED CIRCUIT COMPRISING FILES CLASSIFIED ACCORDING TO A TREE
US5761536A (en) * 1996-08-21 1998-06-02 International Business Machines Corporation System and method for reducing memory fragmentation by assigning remainders to share memory blocks on a best fit basis
DE19633648A1 (en) * 1996-08-21 1998-02-26 Grundig Ag Method and circuit arrangement for storing dictations in a digital dictation machine
JPH1069420A (en) * 1996-08-29 1998-03-10 Sony Corp Information recording and reproducing device and information recording and reproducing method
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
US6681239B1 (en) 1996-12-23 2004-01-20 International Business Machines Corporation Computer system having shared address space among multiple virtual address spaces
US6279069B1 (en) * 1996-12-26 2001-08-21 Intel Corporation Interface for flash EEPROM memory arrays
FR2759795B1 (en) 1997-02-14 1999-05-07 Francois Charles Oberthur Fidu METHOD FOR STORING DATA IN A WRITTEN CARD MEMORY
US6182188B1 (en) * 1997-04-06 2001-01-30 Intel Corporation Method of performing reliable updates in a symmetrically blocked nonvolatile memory having a bifurcated storage architecture
US5966047A (en) 1997-03-27 1999-10-12 Motorola, Inc. Programmable analog array and method
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
JPH10326227A (en) 1997-05-23 1998-12-08 Nec Corp System for managing storage device using flash memory as storage medium
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
US6029168A (en) * 1998-01-23 2000-02-22 Tricord Systems, Inc. Decentralized file mapping in a striped network file system in a distributed computing environment
US6493811B1 (en) 1998-01-26 2002-12-10 Computer Associated Think, Inc. Intelligent controller accessed through addressable virtual space
DE19980546B4 (en) 1998-03-02 2011-01-27 Lexar Media, Inc., Fremont Flash memory card with advanced operating mode detection and easy-to-use interface system
KR100319598B1 (en) * 1998-03-18 2002-04-06 김영환 Flash memory array access method and device
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
US6151666A (en) * 1998-05-27 2000-11-21 Storage Technology Corporation Method for reclaiming fragmented space on a physical data storage cartridge
US6901457B1 (en) * 1998-11-04 2005-05-31 Sandisk Corporation Multiple mode communications system
JP2000148546A (en) 1998-11-10 2000-05-30 Nec Corp Data input/output device, its method and recording medium
US6490649B2 (en) * 1998-11-10 2002-12-03 Lexar Media, Inc. Memory device
US6256690B1 (en) 1999-01-15 2001-07-03 Todd Carper System and method for facilitating multiple applications on a smart card
US6480935B1 (en) 1999-01-15 2002-11-12 Todd Carper Smart card memory management system and method
US6145069A (en) 1999-01-29 2000-11-07 Interactive Silicon, Inc. Parallel decompression and compression system and method for improving storage density and access speed for non-volatile memory and embedded memory devices
JP2000227871A (en) 1999-02-05 2000-08-15 Seiko Epson Corp Non-volatile storage device, control method therefor and information recording medium
GB9903490D0 (en) 1999-02-17 1999-04-07 Memory Corp Plc Memory system
WO2000050997A1 (en) * 1999-02-22 2000-08-31 Hitachi, Ltd. Memory card, method for allotting logical address, and method for writing data
KR100704998B1 (en) 1999-02-26 2007-04-09 소니 가부시끼 가이샤 Recording method, managing method and recording apparatus
JP4779183B2 (en) * 1999-03-26 2011-09-28 ソニー株式会社 Playback apparatus and playback method
GB9907280D0 (en) * 1999-03-31 1999-05-26 Philips Electronics Nv A method of scheduling garbage collection
US6401160B1 (en) * 1999-03-31 2002-06-04 Intel Corporation Method and apparatus to permit adjustable code/data boundary in a nonvolatile memory
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
US6449625B1 (en) * 1999-04-20 2002-09-10 Lucent Technologies Inc. Use of a two-way stack approach to optimize flash memory management for embedded database systems
JP3524428B2 (en) 1999-04-20 2004-05-10 東京エレクトロンデバイス株式会社 Storage device, storage system, memory management method, and recording medium
US6547150B1 (en) 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
JP3863330B2 (en) * 1999-09-28 2006-12-27 株式会社東芝 Nonvolatile semiconductor memory
EP1100001B1 (en) 1999-10-25 2003-08-13 Sun Microsystems, Inc. Storage system supporting file-level and block-level accesses
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
JP3726663B2 (en) 2000-09-07 2005-12-14 日産自動車株式会社 Electronic control device control data storage device
US6865650B1 (en) 2000-09-29 2005-03-08 Emc Corporation System and method for hierarchical data storage
US7039727B2 (en) 2000-10-17 2006-05-02 Microsoft Corporation System and method for controlling mass storage class digital imaging devices
US6834331B1 (en) 2000-10-24 2004-12-21 Starfish Software, Inc. System and method for improving flash memory data integrity
US20020112116A1 (en) 2000-11-17 2002-08-15 Nelson Mark Edward Methods, systems, and computer program products for storing data in collections of tagged data pieces
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
KR100365725B1 (en) * 2000-12-27 2002-12-26 한국전자통신연구원 Ranked Cleaning Policy and Error Recovery Method for File Systems Using Flash Memory
US6763424B2 (en) 2001-01-19 2004-07-13 Sandisk Corporation Partial block data programming and reading operations in a non-volatile memory
US6591358B2 (en) 2001-01-26 2003-07-08 Syed Kamal H. Jaffrey Computer system with operating system functions distributed among plural microcontrollers for managing device resources and CPU
JP3631463B2 (en) * 2001-12-27 2005-03-23 株式会社東芝 Nonvolatile semiconductor memory device
JP2002251310A (en) 2001-02-21 2002-09-06 Ricoh Co Ltd Method for preparing file system for flash memory
US6571326B2 (en) 2001-03-08 2003-05-27 Intel Corporation Space allocation for data in a nonvolatile memory
CN1284356C (en) * 2001-04-06 2006-11-08 索尼公司 Digital camera and data transfer method
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
JP2002333384A (en) * 2001-05-10 2002-11-22 Fujikura Ltd Method of estimating angle deviation of plane of polarization of constant-polarization optical fiber and method of connecting constant-polarization optical fiber
US20020188592A1 (en) * 2001-06-11 2002-12-12 Storage Technology Corporation Outboard data storage management system and method
JP4256600B2 (en) 2001-06-19 2009-04-22 Ｔｄｋ株式会社 MEMORY CONTROLLER, FLASH MEMORY SYSTEM PROVIDED WITH MEMORY CONTROLLER, AND FLASH MEMORY CONTROL METHOD
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
JP4812192B2 (en) * 2001-07-27 2011-11-09 パナソニック株式会社 Flash memory device and method for merging data stored therein
US6456528B1 (en) 2001-09-17 2002-09-24 Sandisk Corporation Selective operation of a multi-state non-volatile memory system in a binary mode
GB0123412D0 (en) 2001-09-28 2001-11-21 Memquest Ltd Memory system sectors
US6823417B2 (en) 2001-10-01 2004-11-23 Hewlett-Packard Development Company, L.P. Memory controller for memory card manages file allocation table
JP3641230B2 (en) 2001-10-22 2005-04-20 株式会社東芝 Apparatus and method for controlling a memory card
US6859856B2 (en) * 2001-10-23 2005-02-22 Flex P Industries Sdn. Bhd Method and system for a compact flash memory controller
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
US20040049627A1 (en) 2001-11-09 2004-03-11 Flex-P Industries Method and system for controlling compact flash memory
TWI240861B (en) * 2002-01-11 2005-10-01 Integrated Circuit Solution In Data access method and architecture of flash memory
JP2003208352A (en) 2002-01-17 2003-07-25 Fujitsu Ltd Flash memory enabling restriction of writing frequency and ware levelling
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
JP2003215495A (en) 2002-01-28 2003-07-30 Fuji Photo Optical Co Ltd Optical system for projector and projector device using the same
US6771536B2 (en) 2002-02-27 2004-08-03 Sandisk Corporation Operating techniques for reducing program and read disturbs of a non-volatile memory
EP1355268B1 (en) 2002-02-28 2006-04-05 Matsushita Electric Industrial Co., Ltd. Memory card
JP4206688B2 (en) 2002-04-15 2009-01-14 ソニー株式会社 Data processing apparatus and data processing method
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
JP4059711B2 (en) 2002-06-04 2008-03-12 株式会社日立グローバルストレージテクノロジーズ Multiple write storage device
US6865659B2 (en) * 2002-06-07 2005-03-08 Sun Microsystems, Inc. Using short references to access program elements in a large address space
KR100541366B1 (en) * 2002-07-19 2006-01-16 주식회사 하이닉스반도체 DRAM for high speed Data access
DE10234971B4 (en) 2002-07-31 2006-08-10 Giesecke & Devrient Gmbh Method and data carrier for generating and correcting program code
US6979481B2 (en) * 2002-08-19 2005-12-27 Mohawk Paper Mills, Inc. Microporous photo glossy inkjet recording media
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
US7093071B2 (en) 2002-10-09 2006-08-15 Intel Corporation Queued copy command
US7103732B1 (en) * 2002-10-28 2006-09-05 Sandisk Corporation Method and apparatus for managing an erase count block
US7035967B2 (en) 2002-10-28 2006-04-25 Sandisk Corporation Maintaining an average erase count in a non-volatile storage system
US7039788B1 (en) 2002-10-28 2006-05-02 Sandisk Corporation Method and apparatus for splitting a logical block
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
EP1556861B1 (en) 2002-10-30 2008-03-12 Matsushita Electric Industrial Co., Ltd. Recording method and recording apparatus
CN1260642C (en) 2002-11-18 2006-06-21 深圳市朗科科技有限公司 Method for transmitting command and data to portable storage device
EP1435576B1 (en) * 2003-01-03 2013-03-20 Austria Card Plastikkarten und Ausweissysteme GmbH Method and apparatus for block-oriented memory management provided in smart card controllers
US7433712B2 (en) 2003-02-06 2008-10-07 Modu Ltd. Multi-access solid state memory devices and a telephone utilizing such
CN1689116A (en) 2003-02-28 2005-10-26 富士通株式会社 Flash memory and memory control method
US8041878B2 (en) 2003-03-19 2011-10-18 Samsung Electronics Co., Ltd. Flash file system
JP4245959B2 (en) 2003-04-09 2009-04-02 日本電信電話株式会社 Memory management method for IC card and IC card
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
WO2005001701A1 (en) 2003-06-27 2005-01-06 Matsushita Electric Industrial Co., Ltd. Slave device and communication setting method
JP4318075B2 (en) * 2003-08-29 2009-08-19 富士フイルム株式会社 USB function device
TWI240863B (en) * 2003-09-05 2005-10-01 Megawin Technology Co Ltd Method for efficiently controlling flash memory read/write
JP2005122439A (en) 2003-10-16 2005-05-12 Sharp Corp Device equipment and format conversion method for recording device of device equipment
US8504798B2 (en) * 2003-12-30 2013-08-06 Sandisk Technologies Inc. Management of non-volatile memory systems having large erase blocks
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
US20050144516A1 (en) 2003-12-30 2005-06-30 Gonzalez Carlos J. Adaptive deterministic grouping of blocks into multi-block units
US20050144363A1 (en) 2003-12-30 2005-06-30 Sinclair Alan W. Data boundary management
US7519639B2 (en) 2004-01-05 2009-04-14 International Business Machines Corporation Method and apparatus for dynamic incremental defragmentation of memory
US20060004950A1 (en) 2004-06-30 2006-01-05 Jeffrey Wang Flash memory file system having reduced headers
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
KR100631765B1 (en) 2004-10-18 2006-10-09 삼성전자주식회사 Apparatus and method for processing data in flash memory
US20060101084A1 (en) * 2004-10-25 2006-05-11 International Business Machines Corporation Policy based data migration in a hierarchical data storage system
US7287145B1 (en) * 2004-12-13 2007-10-23 Nvidia Corporation System, apparatus and method for reclaiming memory holes in memory composed of identically-sized memory devices
US7315916B2 (en) 2004-12-16 2008-01-01 Sandisk Corporation Scratch pad block
US7386655B2 (en) 2004-12-16 2008-06-10 Sandisk Corporation Non-volatile memory and method with improved indexing for scratch pad and update blocks
US7366826B2 (en) 2004-12-16 2008-04-29 Sandisk Corporation Non-volatile memory and method with multi-stream update tracking
US7412560B2 (en) * 2004-12-16 2008-08-12 Sandisk Corporation Non-volatile memory and method with multi-stream updating
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
US7877539B2 (en) * 2005-02-16 2011-01-25 Sandisk Corporation Direct data file storage in flash memories
US20060184719A1 (en) * 2005-02-16 2006-08-17 Sinclair Alan W Direct data file storage implementation techniques in flash memories
KR100706242B1 (en) 2005-02-07 2007-04-11 삼성전자주식회사 Memory system and run level address mapping table forming method thereof
US7849253B2 (en) * 2005-04-04 2010-12-07 Standard Microsystems Corporation Method for fast access to flash-memory media
US20080162782A1 (en) 2005-06-15 2008-07-03 Nagarajan Suresh Using Transacted Writes and Caching Mechanism to Improve Write Performance in Multi-Level Cell Flash Memory
EP1910928A2 (en) 2005-08-03 2008-04-16 SanDisk Corporation Non-volatile memory with scheduled reclaim operations
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
EP1920335B1 (en) 2005-08-03 2011-05-11 SanDisk Corporation Reclaiming data storage capacity in flash memory systems
US7669003B2 (en) 2005-08-03 2010-02-23 Sandisk Corporation Reprogrammable non-volatile memory systems with indexing of directly stored data files
US7984084B2 (en) 2005-08-03 2011-07-19 SanDisk Technologies, Inc. Non-volatile memory with scheduled reclaim operations
US7552271B2 (en) * 2005-08-03 2009-06-23 Sandisk Corporation Nonvolatile memory with block management
US7558906B2 (en) 2005-08-03 2009-07-07 Sandisk Corporation Methods of managing blocks in nonvolatile memory
KR101378031B1 (en) 2005-08-03 2014-03-27 샌디스크 테크놀로지스, 인코포레이티드 Management of memory blocks that directly store data files
US7627733B2 (en) 2005-08-03 2009-12-01 Sandisk Corporation Method and system for dual mode access for storage devices
US7949845B2 (en) 2005-08-03 2011-05-24 Sandisk Corporation Indexing of file data in reprogrammable non-volatile memories that directly store data files
US7814262B2 (en) * 2005-10-13 2010-10-12 Sandisk Corporation Memory system storing transformed units of data in fixed sized storage blocks
US7529905B2 (en) * 2005-10-13 2009-05-05 Sandisk Corporation Method of storing transformed units of data in a memory system having fixed sized storage blocks
US20070136553A1 (en) 2005-12-13 2007-06-14 Sinclair Alan W Logically-addressed file storage systems
US7877540B2 (en) * 2005-12-13 2011-01-25 Sandisk Corporation Logically-addressed file storage methods
US7769978B2 (en) 2005-12-21 2010-08-03 Sandisk Corporation Method and system for accessing non-volatile storage devices
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
US7426606B2 (en) 2006-03-31 2008-09-16 Intel Corporation Method, apparatus and system for reverting FAT cluster number to file ID and offset of non-FAT flash file system
KR100806343B1 (en) 2006-10-19 2008-02-27 삼성전자주식회사 Memory system including flash memory and mapping table management method thereof
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
US7739444B2 (en) 2006-12-26 2010-06-15 Sandisk Corporation System using a direct data file system with a continuous logical address space interface

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020184436A1 (en) * 2001-06-04 2002-12-05 Samsung Electronics Co., Ltd. Flash memory management method
US20030229753A1 (en) * 2002-06-10 2003-12-11 Samsung Electronics Co., Ltd. Flash memory file system
US20040073727A1 (en) * 2002-07-29 2004-04-15 M-Systems Flash Disk Pioneers, Ltd. Portable storage media as file servers
WO2004040453A2 (en) * 2002-10-28 2004-05-13 Sandisk Corporation Method and apparatus for grouping pages within a block
WO2005066793A2 (en) * 2003-12-30 2005-07-21 Sandisk Corporation Non-volatile memory and method with non-sequential update block management
US20060161724A1 (en) * 2005-01-20 2006-07-20 Bennett Alan D Scheduling of housekeeping operations in flash memory systems

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
CHIANG M-L ET AL: "Cleaning policies in mobile computers using flash memory" JOURNAL OF SYSTEMS & SOFTWARE, ELSEVIER NORTH HOLLAND, NEW YORK, NY, US, vol. 48, 1999, pages 213-231, XP001155235 ISSN: 0164-1212 *
WU M ET AL: "ENVY: A NON-VOLATILE, MAIN MEMORY STORAGE SYSTEM" ACM SIGPLAN NOTICES, ACM, ASSOCIATION FOR COMPUTING MACHINERY, NEW YORK, NY, US, vol. 29, no. 11, 1 November 1994 (1994-11-01), pages 86-97, XP000491727 ISSN: 0362-1340 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008134163A1 (en) * 2007-04-27 2008-11-06 Microsoft Corporation Managing object lifetime for native/managed peers
US9785549B2 (en) 2007-04-27 2017-10-10 Microsoft Technology Licensing, Llc Managing object lifetime for native/managed peers
JP2010532061A (en) * 2007-06-27 2010-09-30 サンディスク コーポレイション Staged garbage collection and housekeeping operations in flash memory systems
US8484432B2 (en) 2008-03-11 2013-07-09 Kabushiki Kaisha Toshiba Memory system
JP2009230205A (en) * 2008-03-19 2009-10-08 Toshiba Corp Memory system
JP2011222057A (en) * 2011-08-12 2011-11-04 Toshiba Corp Memory system
US11487657B1 (en) * 2013-01-28 2022-11-01 Radian Memory Systems, Inc. Storage system with multiplane segments and cooperative flash management
US11640355B1 (en) 2013-01-28 2023-05-02 Radian Memory Systems, Inc. Storage device with multiplane segments, cooperative erasure, metadata and flash management
US11704237B1 (en) * 2013-01-28 2023-07-18 Radian Memory Systems, Inc. Storage system with multiplane segments and query based cooperative flash management
US11762766B1 (en) 2013-01-28 2023-09-19 Radian Memory Systems, Inc. Storage device with erase unit level address mapping
US11868247B1 (en) 2013-01-28 2024-01-09 Radian Memory Systems, Inc. Storage system with multiplane segments and cooperative flash management
US9710326B2 (en) 2014-07-28 2017-07-18 SK Hynix Inc. Encoder by-pass with scrambler

Also Published As

Publication number Publication date
KR20080038364A (en) 2008-05-06
CN101233498B (en) 2014-03-12
US7409489B2 (en) 2008-08-05
CN101288045A (en) 2008-10-15
US7984084B2 (en) 2011-07-19
CN101288045B (en) 2012-08-29
US20070033330A1 (en) 2007-02-08
US20070030734A1 (en) 2007-02-08
EP1920336A2 (en) 2008-05-14
US20070033328A1 (en) 2007-02-08
US20070033376A1 (en) 2007-02-08
US7581057B2 (en) 2009-08-25
TW200745930A (en) 2007-12-16
JP4537481B2 (en) 2010-09-01
US8055832B2 (en) 2011-11-08
JP2009503738A (en) 2009-01-29
TW200741526A (en) 2007-11-01
CN101233498A (en) 2008-07-30
CN101258473A (en) 2008-09-03
US20070033327A1 (en) 2007-02-08
TWI421684B (en) 2014-01-01
CN101278267A (en) 2008-10-01
TW200805134A (en) 2008-01-16
US20070033324A1 (en) 2007-02-08
US20070033325A1 (en) 2007-02-08
US7610437B2 (en) 2009-10-27
TW200731065A (en) 2007-08-16
CN101278267B (en) 2012-08-22
WO2007019174A3 (en) 2007-07-19
KR101377147B1 (en) 2014-03-24
US7590795B2 (en) 2009-09-15
TW200745929A (en) 2007-12-16
US7562181B2 (en) 2009-07-14
CN101233499A (en) 2008-07-30
CN101233479B (en) 2012-09-05
CN101233479A (en) 2008-07-30
CN101233480B (en) 2012-08-29
US8291151B2 (en) 2012-10-16
US20070033326A1 (en) 2007-02-08
US20070033329A1 (en) 2007-02-08
WO2007019174A2 (en) 2007-02-15
CN101233480A (en) 2008-07-30
WO2007019220A3 (en) 2007-06-07
US20070186032A1 (en) 2007-08-09
JP4537482B2 (en) 2010-09-01
US7450420B2 (en) 2008-11-11
CN101258473B (en) 2012-05-30
EP1920337A2 (en) 2008-05-14
US20070033378A1 (en) 2007-02-08
KR20080038363A (en) 2008-05-06
US20070033377A1 (en) 2007-02-08
JP2009503746A (en) 2009-01-29
TW200728977A (en) 2007-08-01
US7590794B2 (en) 2009-09-15
US7558905B2 (en) 2009-07-07

Similar Documents

Publication Publication Date Title
US7590795B2 (en) Flash memory systems utilizing direct data file storage
US7877539B2 (en) Direct data file storage in flash memories
US8214583B2 (en) Direct file data programming and deletion in flash memories
US7984233B2 (en) Direct data file storage implementation techniques in flash memories
US9396103B2 (en) Method and system for storage address re-mapping for a memory device
EP2254053B1 (en) FAT-analysis for optimized sequential cluster management
EP2286341B1 (en) Method and system for storage address re-mapping for a multi-bank memory device
EP1782211B1 (en) Fat analysis for optimized sequential cluster management
KR101430097B1 (en) Non-volatile memory and method for class-based update block replacement rules
KR100907477B1 (en) Apparatus and method for managing index of data stored in flash memory

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200680028404.5

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006789293

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2008525181

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 1020087004662

Country of ref document: KR