TW201426305A - Virtual memory device (VMD) application/driver with dual-level interception for data-type splitting, meta-page grouping, and diversion of TEMP files to ramdisks for enhanced flash endurance - Google Patents

Abstract

A Virtual-Memory Device (VMD) driver and application execute on a host to increase endurance of flash memory attached to a Super Enhanced Endurance Device (SEED) or Solid-State Drive (SSD). Host accesses to flash are intercepted by the VMD driver using upper and lower-level filter drivers and categorized as data types of paging files, temporary files, meta-data, and user data files, using address ranges and file extensions read from meta-data tables. Paging files and temporary files are optionally written to flash. Full-page and partial-page data are grouped into multi-page meta-pages by data type before storage by the SSD. ramdisks and caches for storing each data type in the host DRAM are managed and flushed to the SSD by the VMD driver. Write dates are stored for pages or blocks for management functions. A spare/swap area in DRAM reduces flash wear. Reference voltages are adjusted when error correction fails.

Description

Virtual memory device driver, virtual memory device driver for executing on host, method for flashing flash memory, method for flash memory refresh, method for super-enhanced endurance device hard disk solid state driver durable conversion layer , super enhanced endurance equipment and endurance flash memory file system

This application is a U.S. Patent No. 13/540,569, filed on July 2, 2012, "Ultra-Endurance Hard Disk Solid State Drive with Durable Conversion Layer ETL and Temporary File Transfer for Reducing Flash Memory Wear" Continuation-in-part (CIP).

This application is a continuation-in-part of the application "Multi-level striping and truncated channel equalization of flash memory systems" with the US patent number 12/475,457 and the submission date of May 29, 2009. CIP).

This application is a patent number 12/347,306, the filing date is December 31, 2008, and the current application number is 8,112,574. "Local mapping table in a flash memory system with a command sequence for combined flash memory writing. The continuation-in-part (CIP) of the exchangeable set.

This application is a continuation-in-part (CIP) application for the "non-volatile storage based on high performance and endurance of storage systems" with US Patent No. 12/141,879 and submission dated June 18, 2008. ).

This application is related to the application of "High Endurance Non-Volatile Flash Memory Device" to US Patent No. 7,953,931, filed on February 21, 2008.

This application is related to U.S. Patent No. 7,333,364, filed on Apr. 19, 2007, entitled "Degradation of Units for Multi-Bit Flash Memory and Reference Voltage Adjustment".

The present invention relates to flash memory systems, and more particularly to a flash memory drive having enhanced endurance and longevity.

Flash memory is widely used as a primary storage device for peripheral storage and portable devices in computer systems. NAND flash memory was invented in 1987 by Toshiba Corporation's Dr. Fujioka Hiroshi, using an electrically erasable Programmable Read-Only Memory (EEPROM) unit with EEPROM cells at floating gates. Store the charge. The cells are typically programmed by avalanche current and are wiped out through thin oxides using quantum mechanical tunneling. Unfortunately, some electrons may be captured by a thin oxide layer during writing or erasing. Assuming a constant programming voltage, these captured electrons will reduce the charge stored by the memory cells during subsequent programming cycles. Typically, the trapped electrons are compensated by increasing the programming voltage.

As the density and size of the flash memory increase, the size of the unit also becomes smaller. The thickness of the oxide, including the thickness of the tunnel oxide, is also thinned. Oxide thinners make it easier to capture electrons and capture is more likely to fail. The floating gate of the NAND flash memory is used to capture electrons. The amount of electrons in the floating gate can affect the output voltage level. Different voltage levels are obtained by controlling the number of electrons captured by the depletion layer during the writing process. Previously smaller floating gate areas limited the maximum number of electrons that could be captured (now just a few hundred electrons). Electronic leakage or trapping by floating gates due to programming or reading. This change in the number of electrons affects the change in the voltage output level and the result of the reading.

Flash memory can withstand about 100,000 program erases, which makes flash memory have a long life in normal reading and writing. However, smaller flash memory cells already have higher wear resistance. For the two-layer unit, newer flash memory may reach no less than 10,000 program erase cycles, while the third layer The Triple-Level Cells (TLC) is approximately 600 times. If the current trend continues, future flash memory may only allow 300 program erase cycles. Such low endurance can severely limit the application of flash memory, while seriously affecting the application of hard disk solid state drive (SSD).

One way to increase the density of flash memory is to store more than one bit of information stored in each storage unit. Different voltage levels of the storage unit are assigned different multi-bit values, for example, a 4 volt voltage can cover a 2-bit storage unit. However, the noise margin of the multi-level cell (MLC) and the three-layer cell (TLC) is reduced, and the endurance problem is exacerbated.

It is very likely that the potential flash memory endurance will decrease in the future. Flash memory drivers may compensate for the potential for low flash memory potential by various techniques. For example, the DRAM buffer driver on the flash memory driver can be used as a write-back buffer memory to reduce the number of writes to the underlying flash memory when the host performs a write at the same data location.

It is desirable that the flash memory driven host software driver and controller compensate for the low endurance of the underlying flash memory device. It is expected to be connected to a standard hard disk solid state drive (SSD) or super endurance flash memory drive by the host's Virtual-Memory Device (VMD) application and driver. A series of advanced management techniques to reduce the amount of writes to flash memory, thereby reducing the program erase cycle for the underlying flash memory. It is desirable to manage the super endurance flash memory drive by the host's VMD application and driver to build a low endurance flash memory.

A first aspect of the present invention provides a virtual memory device (VMD) driver, the driver being executed on a host, comprising:

a file type identifier for generating a data type for a host write received by the VMD driver;

a data splitting manager for classifying data written by the host according to the type of data identified by the data type identifier;

The data is written into the buffer memory for storing the data of the user data type;

Metadata buffer memory for storing metadata written by the host of the metadata type;

a page buffer memory for storing a host write data of a paging file data type;

Temporary buffer memory for storing data of a temporary data type host;

a user grouping engine for classifying user data stored in the data write buffer memory into a user metapage;

a metadata packet engine for classifying metadata stored in the data write buffer memory into a meta page of the metadata;

An output buffer for sending the grouped meta page and data type messages to the flash memory drive system for storage.

A second aspect of the present invention provides a virtual memory device (VMD) driver for execution on a host, comprising:

a data type allocator for generating a data type for a host write received by the VMD driver;

a task priority allocator for assigning priorities to tasks, including writing a host write data according to a data type, and the priority is a function from a data type of the data type allocator;

a target allocator for classifying the data written by the host according to the type of data generated by the data type allocator;

Data write buffer memory for storing host write data with user data type;

a virtual disk drive for storing host write data having a temporary data type into a host DRAM;

Data read buffer memory for storing host read data;

a packet engine for grouping data stored in the data write buffer memory into a meta page;

The grouping engine is cancelled, and the data stored in the metapage is ungrouped into the ungrouped data stored in the data read buffer memory;

The metadata is sent from the packet engine to the Volume Manager for transmission to the flash memory, and the meta-page stored in the flash memory is received by canceling the packet engine;

Power monitor for detecting power failures;

The refresh manager is configured to refresh the data stored in the host DRAM into the SSD DRAM when the power is lost, and then refresh into the flash memory of the flash memory drive system;

The recovery manager is configured to load the refresh data acquired from the flash memory of the flash memory drive system when the power is restored, and then refresh to the host DRAM.

A third aspect of the present invention provides a method for refreshing a flash memory, including:

Get the current date;

The current block in the block list of the flash memory:

(a) reading a block state table for erasing the current block and writing the date to the current block, the date indicating the date the current block was last written;

Calculating the first time delay as the difference between the write date and the current date;

The first time delay is taken as the retention time;

When the first time delay exceeds the retention time, all valid pages in the current block are moved to blank pages in the spare block of the DRAM (DRAM);

When the spare block in the DRAM is full, the data in the spare block from the DRAM is moved to the spare block in the flash memory;

Erase the current block;

Another block is selected as the current block in the block list of the flash memory, and is repeated from (a) until all the blocks in the block list are processed, and thus the flash memory block is refreshed.

A fourth aspect of the present invention provides a method for flash memory refresh, including:

Get the current date;

For the current page in the current block in the block list of the flash memory:

(a) reading the block status table, the block status table is used for the erase count of the current block;

(b) Read the page status table, the page status table is used for the current page's write date, and the date indicates the date the current page was last written;

Calculating the first time delay as the difference between the write date and the current date;

The first time delay is taken as the retention time;

When the first time delay exceeds the retention time, moving the current page in the current block to a blank page in the spare block of the DRAM (DRAM);

When the spare block in the DRAM is full, the data in the spare block from the DRAM is moved to the spare block in the flash memory;

Select another page in the current block and repeat from (b) until all pages in the current block have been processed;

Select another block as the current block in the block list of the flash memory, and repeat from (a) until all the blocks in the block list are processed, and the flash memory page is refreshed.

A fifth aspect of the present invention provides a super hard endurance equipment (SEED) hard disk solid state drive (SSD) Endurance Transaction Layer (ETL) method for enhancing flash with a low specified erase cycle life Memory endurance, including:

ETL is created in the Dynamic Random Access Memory (DRAM) buffer controlled by the controller and the ETL layer is used to provide temporary storage space to reduce wear on the flash memory;

Create an alternate swap area in the DRAM buffer;

Using a spare swap area in the DRAM buffer to operate the controller to merge valid data in flash memory with new data to produce combined data;

When overwriting all pages or partial pages in an existing block in the flash memory, writing new data to the spare block of the DRAM buffer associated with the existing block in the flash memory, the difference in the flash memory Block, when additional new data requires a spare block, a combination of spare blocks with new data and data from existing blocks of flash memory is written into the spare block in the flash memory, which will be in the flash memory All pages in an existing block, marking the page status as a junk page;

When the power supply is lost, the backup power supply is used to supply power to the DRAM buffer and the flash memory and the controller. The backup power supply has sufficient capacity to enable the controller to back up the data required by the ETL layer to the flash memory. The controller uses the DRAM buffer instead of the flash memory to perform the alternate swap function.

A sixth aspect of the invention provides a super enhanced endurance device (SEED) comprising:

a host interface for receiving host read and host writes from the host;

SEED dynamic random access memory (DRAM) buffer for storing data;

a controller for controlling access to the flash memory and the DRAM buffer to respond to host read and host write received by the host interface, and the controller writes the host data into the DRAM buffer;

SEED Hard Disk Solid State Drive (SSD) Durable Translation Layer (ETL), implemented in DRAM buffers and controlled by controllers using ETL to provide temporary storage to reduce wear on flash memory;

Data write buffer memory, data write buffer memory is stored in the DRAM buffer and managed by the controller;

Flash memory interface for erasing blocks and writing to flash memory pages, where the block is a multiple of the page size;

Flash memory for storing metadata from packets of the SSD DRAM buffer;

When power is lost, the backup power supply is used to power the DRAM buffer, flash memory, and controller. The backup power supply has sufficient capacity to allow the controller to back up the data needed in the ETL to the flash memory.

A seventh aspect of the present invention provides a virtual memory device driver (VMD) for execution on a host, comprising:

Host Durable Translation Layer (ETL) for execution on the host, increasing flash memory endurance, and flash memory with low erase cycle life;

a host dynamic random access memory (DRAM) buffer, located on the host, controlled by the host controller, using the host ETL layer to provide temporary storage on the host to reduce wear on the flash memory;

Super Enhanced Endurance Equipment (SEED) on a hard disk solid state drive (SSD), SEED is used to increase the endurance of flash memory with low erase cycle life;

The SEED Durable Translation Layer (ETL) in the SEED DRAM buffer, controlled by the SEED controller, provides temporary storage to reduce flash memory wear.

An eighth aspect of the present invention provides a virtual memory device (VMD) driver for execution on a host, comprising:

An encryption engine for coupling to receive intercepted high-level host writes and generating encrypted data;

a compression engine for coupling to receive the intercepted high-level secondary host to write data and generate compressed data;

Data write buffer memory for storing data written by the host;

Data read buffer memory for storing host read data;

a grouping engine for dividing the data stored in the data write buffer memory into metapage pages;

Ungrouping the data for ungrouping the data stored in the metapage into stored data that can be stored in the data read buffer memory;

Sending the meta page from the packet engine to the volume manager for transfer to the flash memory, and simultaneously receiving the meta page stored in the flash memory by canceling the packet engine;

Power monitor for detecting power failures;

a host dynamic random access memory (DRAM) buffer for storing a host durable conversion layer (ETL);

The refresh manager is used to flush the data in the host ETL layer stored in the host DRAM buffer to the hard disk solid state drive (SSD) ETL DRAM when the power is lost, and then store it in the hard disk solid state drive machine. (SSD) system in flash memory;

The recovery manager is configured to load the refresh data acquired from the flash memory of the SSD system when the power is restored, and then refresh to the host ETL layer of the host DRAM buffer.

A ninth aspect of the present invention provides an endurance flash memory file system, comprising:

A high-level file filter driver that is executed on the host and intercepts high-level host writes to the flash memory drive;

An encryption and decryption engine for coupling to receive high-level host write data intercepted by a high-level file filter driver, and generating encrypted data and decrypted data;

a compression and decompression engine for coupling to receive high-level secondary host write data intercepted by a high-level file filter driver, and generating compressed data and decompressing data;

The compressed data and the encrypted data are sent to a file system driver (FSD) executed on the host;

a low-level file filter driver for execution on the host and intercepting writes to low-level file system hosts of the flash memory drive;

Data write buffer memory for storing data written by the host;

Data read buffer memory for storing host read data;

a grouping engine for dividing the data stored in the data write buffer memory into metapage pages;

Ungrouping the data for ungrouping the data stored in the metapage into stored data that can be stored in the data read buffer memory;

Sending the meta page from the packet engine to the volume manager for transfer to the flash memory, and simultaneously receiving the meta page stored in the flash memory by canceling the packet engine;

a file priority label classifier for generating a data type for a host;

a task policy allocator for assigning priorities to tasks, including writing data to the host according to the data type, the priority being a function of the data type from the file priority label classifier;

a performance adjuster that adjusts the priority of the task;

a target classifier for classifying the data written by the host according to the data type generated by the file priority label classifier;

a business system for recording events that start and complete writing to flash memory data;

a refresh manager for refreshing data stored in the host DRAM to the SSD DRAM and then to the flash memory in the flash memory drive system when power is lost;

a recovery manager for acquiring the refreshed data from the flash memory in the flash memory drive system, and then refreshing to the host DRAM when the power is restored;

A disk miniport driver that manages the specific protocol functions of the flash memory drive system.

A tenth aspect of the present invention provides a super enhanced endurance device (SEED) comprising:

a host interface for receiving host read and host writes from the host;

Dynamic Random Access Memory (DRAM) buffer for storing data;

a controller for controlling access to the flash memory and the DRAM buffer to respond to host read and host write received by the host interface, and the controller writes the host data into the DRAM buffer;

a data write buffer memory stored in a DRAM buffer for managing a controller that manages non-transitory data;

An enhanced flash memory portion of the flash memory for configuring for use as a robust page, wherein the reserved portion of the flash memory is configured as a weak page;

Programmable erase manager for controlling page write or block erase time of flash memory to enhance endurance and reduce retention time;

A refresh manager that controls the refresh time that remains in the enhanced flash memory portion.

100. . . VMD drive

104. . . Trigger selector

106. . . Compressed encryption engine

108. . . Data split manager

110. . . Output buffer

113. . . Metadata user profile packet processor

114. . . FDB metapage grouping processor

116. . . Page file grouping processor

118. . . Selector

12. . . DRAM interface

120. . . Metadata buffer memory

121. . . Virtual disk data

122. . . Paging file by selector

123. . . Virtual disk power-on refresher

124. . . Temporary file area

125. . . Virtual disk power off refresher

126. . . Disk refresh recovery manager

128, 133’. . . page

132. . . Data read buffer memory

133. . . Host read page

134. . . Grouper

136. . . Packet canceller

138. . . Disk miniport driver

1394. . . firmware

14. . . Flash memory interface

140. . . Metadata buffer memory

142. . . Temporary file buffer memory

144. . . Buffer memory for paging files

145. . . Refresh data

146. . . Log file page grouping

148. . . Paging archives and mapping tables

150. . . System usage area

151. . . Read buffer memory and mapping table

152. . . Buffer data

154. . . Data write buffer memory

156. . . Spare parts and exchange blocks

16. . . Host interface

162. . . table

164. . . Erase count table

170. . . S.M.A.R.T. data collector

172. . . Partition manager

174. . . Disk sort drive

176. . . backup power

178. . . Operating system core

18. . . Secure erase manager

180. . . VMD application

181. . . SSD internal cleanup

182. . . User application

184. . . Operating system settings

186. . . Configuration settings

188. . . Virtual disk

190. . . High-level file filter driver

192. . . SEED controller

194. . . SSD DRAM buffer

195. . . Power backup

196. . . NAND flash memory

20. . . Data write buffer memory

200. . . Super strong endurance device

200'. . . SEED

202. . . Refresh manager

204. . . Data split manager

206. . . Bad page manager

208. . . Over-provisioning

210. . . LBA table

211. . . Business manager

212. . . Compressed LBA table

214. . . Compressed data

215. . . Security manager

216. . . Recovery manager

217. . . NVRAM

218. . . Schedule manager

22, 24, 26, 28, 232, 234. . . Buffer memory

236. . . Virtual disk _02

238. . . Virtual disk _03

240. . . Encryption and decryption engine

242. . . Compression decompression engine

244. . . Security manager

246. . . Smart data monitor

248. . . Power monitor

250. . . Virtual disk drive

254. . . Target distributor

256. . . Performance regulator

260. . . Task priority allocator

262. . . business system

264. . . File priority classification

266. . . File system driver

268. . . Low-level file filter driver

270. . . Volume management

272. . . Environmental parameters

274. . . IO drive

276. . . User application

277. . . Refresh manager

278. . . VMD drive

280. . . VMD application

282. . . Operating system function

284. . . Virtual disk_00

286. . . Buffer memory

288. . . Virtual disk_01

289. . . Internal storage space

290, 291, 292, 293. . . Read buffer memory

300. . . Host

30. . . NFA/FA split manager

301. . . Buffer memory controller

302. . . Partition _01

303. . . SEED SSD

304. . . Partition _02

305. . . Power management

306. . . System boot image

307. . . Power backup

308. . . Backup boot image

309. . . Internal storage controller

310. . . VMD application

311. . . switch

312, 314. . . Data bank

316. . . Group mapping table

318. . . Group meta page

32. . . NFA/FA split manager

320. . . Local grouping metapage

322, 324. . . section

326. . . High part

328. . . Low part

336. . . Low-level DRAM interface

338. . . ECC Manager

34. . . NRA/RA split manager

340. . . Low-level SSD DRAM

342. . . Flash memory

346. . . Security manager

348. . . Temporary manager

350. . . SSD

352. . . Compressed map manager

358. . . Endurance controller DRAM

36. . . Metapage ungrouping engine

360. . . Endurance controller

372. . . Data recovery analyzer

374. . . Overlay fault data buffer

376. . . Coded LDPC_2 check

378. . . LDPC_2 generator

38. . . Paging area

382. . . RAID buffer

384. . . Voltage adjustment controller

386. . . Triggering iterative controller

388. . . RAID parity generator

39. . . S.M.A.R.T. function

390. . . RAI parity

392. . . Read buffer

394. . . Parity decoder

396. . . Read buffer memory

398. . . Encoder

40. . . Wear equalizer

400. . . Flash memory array

402. . . Flash memory access controller

404, 406. . . Internal bus

41. . . Code erase manager

42. . . TRIM Manager

43. . . Refresh recovery manager

44. . . ECC Manager

46. . . Cryptographic engine

471. . . Bad block erase count table

473. . . Page status table

48. . . Table manager

50. . . RAID controller

52. . . Command queue manager

T1. . . First threshold

T2. . . Second threshold

T3. . . Threshold value

TP. . . Threshold value

TE. . . Threshold value

1002~1008, 1102~1112, 1122~1132, 1142~1152, 1162~1172, 1012~1018, 1120~1128, 1130, 1160, 1062, 1032~1038, 1140, 1042~1048, 1150, 1052~1058, 1202~1218, 1226, 1220, 1228, 1236, 1238, 510, 524, 530~538, 540, 548, 556, 558~570, 572, 576, 582, 584, 586, 592, 594. . . step

Figure 1 is a block diagram of a VMD application and drive on a host, applications and drives to create and manage multiple buffer memories and virtual disks, applications and drives on the host and ultra-endurance with low-endurance flash memory Flash memory drive;

Figure 2 is a more detailed flow chart highlighting the VMD on the host;
Figure 3 is a block diagram of a SEED;
Figure 4 is a flow chart showing the splitting and grouping of the written data by the VMD driver;
Figures 5A through 5B show a flow chart of the data classification and cancellation of the read packet by the VMD driver;
Figure 6 shows the internal storage map of the Endurance Transaction Layer (ETL) in the host DRAM;
Figure 7 is a schematic diagram showing the storage mapping of the Endurance Transaction Layer (ETL) in the SEED SSD DRAM;
Figure 8 is a memory map of a flash memory;
Figure 9 shows that all or part of the page is mapped or grouped into metadata according to the type of data;
Figure 10 shows a map of compressed pages;
The standby and exchange operations are shown in Figures 11A through 11B;
Figure 12 shows a multi-level error check;
13A to 13B are diagrams showing a bad block erase count table and a page status table;
Figure 14 is a block diagram of a Super Enhanced Endurance Device (SEED) with an endurance controller;
15A to 15E are diagrams showing that the VMD driver on the host processes the host write command;
Figures 16A through 16E show the host VMD driver processing host read instructions;
Figures 17A to 17B show the metapage composition process;
Figure 18 shows the encryption and compression process by the VMD driver;
19A to 19B are diagrams showing a backup exchange process in the SEED;
The 20A to 20D diagrams show the detection and processing of bad pages and bad blocks;
21A to 21B are diagrams showing a flash memory block refresh operation using the table in FIG. 13A;
Figure 22 shows the internal cleanup operation performed on the host;
Figure 23 shows the receipt of a log file on the SEED;
Figure 24 is a flow chart recording the host write to the DRAM buffer memory;
Figure 25 is a flow chart showing the recording from the DRAM buffer memory in the SEED to the flash memory;
Figure 26 is a flow chart showing the sequence of power failures on the host;
Figure 27 is a flow chart showing the SEED power supply power-off processing;
Figure 28 is a flow chart of SEED power failure handling;
29A to 29B are flowcharts showing a flash memory page refresh operation using the table in FIG. 13B;
Figures 30A to 30B show the bad page management process in the page writing process in Fig. 30A;
Figures 31A to 31B show the backend garbage collection process;
Figure 32 is a flow chart showing the initialization of the host VMD;
33A to 33B are flowcharts of SSD initialization;
Figure 34 is a flow chart of cleaning the log area;
Figure 35 shows the abnormal power shutdown check performed on the SSD;
Figure 36 shows the abnormal power shutdown check performed on the host.

The present invention is directed to improvements in high endurance flash memory drives. The following description is presented to enable a person of ordinary skill in the art to make and use the invention. Various modifications to the preferred embodiment will be apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other embodiments. Thus, the present invention is not intended to be limited to the embodiments shown and described.

By inhibiting unnecessary writing of flash memory, it is possible to reduce wear on the underlying flash memory device. The application and driver of the Virtual-Memory Device (VMD) executed on the host can prohibit writing or combining before the flash memory is reached, thus reducing the writing frequency to the flash memory. The VMD transfers writes to the host to writes to the buffer memory and virtual disk in the host's DRAM or SSD DRAM.

The DRAM buffer on the host or flash memory drive SSD device can store data. This data does not need to be saved permanently, so there is no need to write to the flash memory. DRAM is not only fast, but also very durable, because it can write more than 1 million times. DRAM was a reliable dynamic storage technology invented in 1966 by Dr. Robert Dennard of IBM.

A typical host creates a number of temporary files, such as when browsing the web or when running some unimportant redundant applications. The invention realizes that these files do not need to be written into the flash memory, thereby reducing the wear of the flash memory.

Typical systems write more frequently on certain types of data. These frequently overwritten data are preferably stored in the DRAM buffer driven by the host or flash memory, and by a strategy (such as time consumption, capacity allocation, etc.) or When the power is cut off or the power fails, these frequently overwritten data are copied to the flash memory. Storing these frequently overwritten data in flash memory can significantly reduce the wear on flash memory devices only when the power is off. Most metadata are small in length and can be stored centrally, for example, they can be stored centrally in the FAT table. Each update involves only writing to a very small portion of the flash memory page. Storing metadata in DRAM can reduce unnecessary writes to flash memory.

The data that is so frequently overwritten includes log files that are frequently updated as new events occur. The latest archive copy is usually detected after a system crash. The File Allocation Table (FAT) is another location that frequently overwrites the file. When the file is created or expanded, the file configuration table is updated. The FAT table is a relatively small part of the internal storage, but if every update to the FAT table is copied to the flash memory, this frequent access will significantly increase the wear of the flash memory. The File Descriptor Block (FDB) has a similar structure of frequent overwrite writing. When the file list is accessed and displayed only in the Windows browser, the file access date is frequently overwritten. FDB and FAT have metadata from the host file system. The various types of tables used with DRAM buffers have metadata that was created to store the file system in DRAM and flash memory.

The bad block table created by the flash memory driver, the erase counter, the garbage collection, the spare and exchange block mapping table, and other files need to be stored in the flash memory according to a certain strategy or power failure or power failure. Similarly, to reduce flash memory loss, the metafile of the flash memory system can also be stored in the DRAM buffer and copied to the flash memory according to a certain strategy or power outage or power failure. The above table and metafile can be stored in the flash memory at power-on. It is installed into a DRAM buffer when the device is initialized. Then, the host data read and write operation changes the data content. When the power is off or a power failure occurs, the dirty table and metafile need to be written or backed up to the flash memory. In the event of a power failure, considering system recovery, if a specific recovery point is required for a particular application, host buffer memory, FIFO buffer, buffer data, permanent spare and swap blocks, and other flash drive drivers The data in the buffer can be copied to the flash memory.

When the image stored in the main DRAM of the host is moved to a hard disk or a flash memory drive, the system uses the paging file for internal storage management. Because the system needs to be restarted, the internal storage management and paging system is reinitialized to clear all stored paging files, so when a power failure occurs, the loss of page swap file is not important. These paging files can be stored in the DRAM buffer. When the power is off or the power is faulty, it is not necessary to copy to the flash memory, thus effectively reducing the wear of the flash memory.

Flash memory driven host requests often follow a regular sequence of data types. For example, a host can access the FAT table and then access the FDB block to read and write data files. This repeat sequence may help the super-endurance flash memory drive to classify data types. Depending on the type of operating system (Windows, Linux, Apple OS, Android, etc.), FAT is always located in a predetermined internal storage location. Therefore, accesses within the address range of the internal storage location are FAT type accesses. The access after FAT access must be an FDB access. Then, the next access is user data access. Therefore, the user profile can be determined as a subsequent FAT access and FDB access. In order to find the extended file, the FDB can be checked by the ultra-endurance flash memory, so that the .tmp file can be detected and processed in a different way from the user profile.

In a typical flash memory drive that does not distinguish between data types, each type of file will cause the flash memory to wear out. This unknowable system processes all information equally. All data is written to the flash memory, at least when the data entry is in the DRAM buffer, if any, the data will be sent to the DRAM buffer by another data from the host with the same buffer memory index. . By identifying the data type and the destination host of the data, and during normal operation, only the actual user data is written to the flash memory, only the important data is written to the flash memory, and when the power fails, according to the strategy, Can significantly reduce flash memory writes.

Further reduction in flash memory wear can be achieved by packaging the material. For example, less than one full page of data (partial page data) in flash memory can be stored in one page of flash memory along with other partial page data, rather than being stored in many separate pages. Multi-channel systems may have larger units, such as meta pages, each page has one page, or the number of channels is several times the page size. Flash memory wear can be further reduced by packaging the data into meta pages instead of smaller pages.

In an unfavorable environment, DRAM buffers may have software errors. Additional DRAM over-provisioning can be used for Error Correction Code (ECC) parity to improve flash memory reliability.

From every technical point of view, the wear savings of flash memory can provide various improvements that, when used together, can significantly increase the endurance of flash memory. VMD applications and drives can provide higher endurance for flash memory drives that use these technologies.

Figure 1 is a block diagram of a VMD application and driver on a host. Applications and drivers create and manage multiple buffer memories and virtual disks, applications and drivers on the host and have ultra-endurance with low endurance flash memory. Flash memory drive. The host 300 has a processor that executes program instructions, such as user application 182 and operating system (OS) core 178 instructions, such as Windows, Linux, and Apple OS or Android. When the main power source fails, the backup power source 176 provides power to the host 300, so that when the power source fails, the host 300 transmits important data from the virtual disk 188 to the super strong endurance device (SEED) 200, and the super endurance device 200 is located at the NAND fast. Flash memory 196. The backup power source 176 can use a battery, or an uninterruptible power supply (UPS) or the like. This gives the host processor time to shut down the application and properly shut down the associated device. The SEED 200 has its own power backup 195 to allow the SEED 200 to write important data to the NAND flash memory 196 when the primary power supply fails. Power backup 195 can use capacitors, supercapacitors or batteries. Alternatively, the power backup 195 in the SEED 200 is not required if the backup power supply 176 has sufficient power to shut down the system normally. For example, the host 300 is a laptop or a smart phone.

The VMD application 180 is an application executed on the host 300. VMD application 180 and VMD driver 100 can be used to relieve the burden on SEED 200. The VMD application 180 and the VMD driver 100 can split or store data, such as temporary files, paging files, etc., but do not imply permanent storage to flash memory. The VMD driver 100 can cause the virtual disk 188 to store such temporary data. Virtual disk 188 can be part of the DRAM of the host.

The VMD driver 100 can perform tasks using a host CPU, such as a compression decompression engine 242, and an encryption decryption engine 240. The data of the user application 182 written by the operating system kernel 178 is intercepted by the high level archive filter driver 190 and passed to the VMD driver 100 for compression or encryption before being sent to the archive system driver 266. The low level file filter driver 268 then intercepts the data again for further processing by the VMD driver 100, for example, for storage in the virtual disk 188.

The material that is ultimately ready to be written to the SEED 200 is sent from the VMD driver 100 to the volume management 270, which manages the storage volume, for example, the SEED 200. The SEED controller 192 in the SEDD 200 can store data in the SSD DRAM buffer 194 and store the data in the NAND flash memory 196 when the power is turned off or when the SSD DRAM buffer 194 is full.

The SSD internal cleanup 181 located in the VMD application 180 performs various high level functions, such as garbage collection, to remove old unused files. The SSD internal cleanup 181 can be performed periodically, such as daily, weekly, or when the VMD driver 100 manages the virtual disk 188. Configuration settings 186 and registry and operating system settings 184 may be set by OS core 178, or other programs may define the size of virtual disk 188 or other system variables, and manage the preferred functions of VMD application 180 and VMD driver 100.

Configuration settings 186 and registry and OS settings 184 may have various settings that improve the durability and performance of flash memory, for example, settings can enable or disable write buffer memory, drive indexing, search indexing, disk defragmentation, Host sleep, prefetch data, super fetch data, and window write buffer memory buffer refresh. Prefetching data, indexing, hibernation, and defragmentation can cause extra writes to the flash memory, thus reducing the endurance of the flash memory. Since the VMD driver has its own write buffer memory and refresh function, the write buffer memory and the write buffer memory buffer refresh can be disabled. Therefore, by disabling these characteristics, the endurance of the flash memory can be improved.

Figure 1 shows some of the optional parts that are useful for situations where the power supply is abnormally powered down. When the power is turned on, the power management 305 and the power backup 307 (in some system environments, if there is no backup power 176) store energy, and when the power fails, the power management 305 and the power backup 307 provide power to the host 300. When the power fails, the CPU register and buffer memory controller 301 will write the CPU scratchpad and buffer memory to the host DRAM and then to the SEED 200. In another embodiment, the SEED SSD 303 is connected to the host 300 and another SSD, for example, may be connected by a PCIe port, a USB port, an NVMe port, or the like. In another embodiment, the SEED SSD 303 can be built into the DRAM module and controlled by the internal storage controller 309. Alternatively, when a power failure occurs, the CPU scratchpad and buffer memory controller 301 will write the CPU scratchpad and buffer memory to the write host DRAM and then to the SEED 200 or SEED 303. The preset switch 311 isolates unnecessary portions of the host 300 so that these portions cannot receive backup power, thereby prolonging the use time of the backup power source for transmitting important files. The internal storage controller 309 will block the transfer of data between the host DRAM and the SEED SSD 303 during abnormal power down and power recovery.

2 is a more detailed flow chart highlighting the VMD on the host. Before the number of hosts is sent to the file system driver 266, the host data is transferred to the VMD driver 100 for compression by the compression engine 242 or by the encryption engine 240. Encrypted, host data is written by the OS core and intercepted by the high level file filter driver 190. The low level archive filter driver 268 then intercepts the data again for further processing by the VMD driver 100.

The file priority classification 264 classifies the data according to the data type. The data type is assigned by the low-level file filter driver 268 or by the LBA. For example, the data type can be a metadata (FAT, FDB) temporary file, a paging file, or a user. data. Temporary files include: temporary files for Windows, temporary files for Internet browsers, etc. In addition, this feature can be selectively disabled for specific use, for example, a server. All operations have priority assigned by task priority allocator 260 so that high priority tasks can take precedence over low priority tasks. Performance adjuster 256 can periodically adjust the priority of these materials to improve system performance. Depending on the type of data, the target allocator 254 sends the data to the virtual disk drive 250 in the virtual disk 188 for storage, or the data write buffer memory 20.

The data written to the SSD may be grouped by the packetizer 134 before being sent to the Recovery Manager Volume Management 270 and the SEED 200. Partition manager 172 and disk sort drive 174 can send a plurality of data to a selected partition or disk. The disk miniport driver 138 manages the specific protocol functions that are connected to the SSD. The packet canceller 136 cancels the packet of the material acquired from the SEED 200 before the data is transferred to the material read buffer memory 132.

The business system 262 ensures that the data is completely written to the SEED 200. The recovery manager 216 determines which write service was not completed due to an abnormal power outage and helps the application to do the necessary redo or undo to ensure data persistence. The schedule manager 218 manages the business system 262 to manage and record writes to the SSD service, such as launch, suspend, and commit.

When the power monitor 248 detects a power outage or a failure, the virtual disk refresh recovery manager 126 is triggered to transfer data from the data write buffer memory 20 and the virtual disk 188 to the SEED 200 in the flash memory. Save it. When the refresh is complete, the disk refresh recovery manager 126 will issue protocol commands to the SEED 200 and the backup power source 176 or the power manager 305. If there is a backup power supply, the system will be powered off and only the SEED 200 will be powered. In the case of power management 305, power management 305 will continue to power the DRAM, SEED SSD 303, switch 311, and internal storage controller 309. The refresh recovery manager 126 periodically flushes the contents of the data write buffer memory 20 and the virtual disk 188 to the SEED 200 before the power-off loss. The security manager 244 can perform a password verification process before allowing the SEED 200 or data buffer memory to be accessed by the VMD driver 100. The smart data monitor 246 sends a S.M.A.R.T. monitoring message from the SEED 200 to the VMD driver 180. The Endurance Flash Memory File System has a high-level file filter driver that is executed on the host and intercepts writes to the high-level host of the flash memory drive. The encryption and decryption engine receives high-level host writes intercepted by a high-level file filter driver and encrypts the data and decrypts the data. The compression and decompression engine also receives high-level host writes from high-level file filter drives and generates compressed data and decompressed data. The compressed data and the encrypted data are sent to a File System Driver (FSD) that is executed on the host.

The low-level file filter driver can also execute on the host and intercept writes to the low-level file system host of the flash memory drive system. The data write buffer memory stores the host write data, and the data read buffer memory stores the data read by the host. The packet engine divides the data stored in the data write buffer memory into metadata. The ungrouping engine ungroups the data stored in the metapage into stored data that can be stored in the data read buffer memory. The meta page is sent from the packet engine to the recovery manager to transfer it to the flash memory, while the meta page stored in the flash memory is received by the cancellation packet engine.

The file priority tag classifier generates data types for data written and received by the host. The task policy allocator assigns priorities to tasks, including writing data to the host based on the data type. The priority is a function from the data type of the file priority tag classifier. The performance adjuster adjusts the priority of the task. The target classifier classifies the host write data according to the data type generated by the file priority label classifier.

The business system logs events, which indicate the start and completion of flash data writes. When power is lost, the refresh manager flushes the data stored in the host DRAM to the SSD DRAM and then flushes it to the flash memory of the flash memory drive system. The recovery manager reacquires the refresh data from the flash memory of the flash memory drive system and then sends it to the host DRAM when the power is restored. The disk miniport driver manages the specific protocol functions of the flash memory drive system. Smart data monitor 246, power CPU detector 248, security manager 244, and virtual disk drive 250 are optional.

Figure 3 is a block diagram of a SEED. The SEED 200 has a host interface 16, and the SEED 200 communicates with the host 300 (as shown in FIG. 1) via a bus, for example, PCIe, SATA, or Universal-Serial-Bus (USB), NVMe, lightning interface, eMMC. , iSSD, etc. Host data retrieved from host interface 16 is sent to SEED controller 192, which performs various functions to reduce wear on NAND flash memory 196, for example, flushing files from VMD driver 100 on host 300 to SSD The DRAM buffer 194 is instead of the NAND flash memory 196.

The SSD DRAM buffer 194 can store the spare file of the host virtual disk 188 and refresh other data and tables from the VMD 100. Other data can be stored, including metadata, spare and exchange blocks, bad page management tables, and other buffers and data sheets.

The NAND flash memory 196 can store security messages, forms, SSD file systems, and various other tables and buffers, as well as user profiles and data in the refreshed virtual disk 188. Some areas of NAND flash memory 196 may remain as bad blocks or over-provisioned.

The DRAM interface 12 reads and writes the SSD DRAM buffer 194, and the multi-channel flash memory interface 14 reads the page, the program data page, and the blocks in the NAND flash memory 196 can be organized into multiple channels.

The Native Command Queue (NCQ) manager 52 can rearrange the host commands retrieved from the host 300 and manage the sequence of host commands received from the host interface 16. The manager loads the host command as a command queue, and the write data is reordered to reduce flash memory writes.

The RAID controller 50 writes new data through multiple channels of the NAND flash memory 196 and may copy data to provide redundancy and data recovery. The ECC manager 44 generates an Error-Correction Code (ECC) attached to the written material and compares the stored ECC to regenerate the ECC, thereby detecting and correcting errors in reading. The ECC Manager 44 further manages the need for additional ECC to protect flash memory pages, generate ECC for these pages, and manage the storage and recycling of ECC data when needed. Instead of executing the EC, the ECC manager 44 can be used for Low Density Parity Check (LDPC) codes. Bad page manager 206 tracks the location of page states in all NAND flash memory 196. This can extend the life of each block, since only one page may be a bad block, so other pages can continue to be used. More complex bad block management may reduce the overall wear of the flash memory drive.

Wear equalizer 40 provides two methods of wear leveling. One method is to dynamically select the lowest wear leveling block write data from the available empty blocks. Another method is to count the threshold based on the wear leveling. Once this threshold is reached, the flash memory block will move from one physical block (with low loss equalization count) in NAND flash memory 196 to another empty physical block (with high loss equalization count). The logical physical mapping table managed by table manager 48 will be updated. The table manager 48 also tracks the type of material stored in each logical block or page to track temporary files, paging files, FAT, FDB, and user profile when the data splitting manager 204 identifies and categorizes the data. Alternatively, the host can pass the data type message to the SEED SSD by a protocol command, so the data splitting manager 204 does not have to repeat the work done by the VMD driver 100. Optionally, in some specific cases, the function can be selected to be disabled.

If the function is not completed by the VMD driver 100, the encryption engine 46 performs write data encryption and read data decryption. The TRIM Manager 42 processes TRIM commands from the file system or the operating system on the host 300. The TRIM command indicates that the host no longer needs a part and can be wiped or erased. The trimmed page is marked as a junk page in the page status table, such as '100b' or '101b'. When doing back-end garbage collection, if a block is identified as a erasable block, the page will not be copied to a new block. At this point, the TRIM command is complete. The TRIM manager 42 performs system overhead, for example, it is no longer necessary to track partitions or pages in a block. The garbage collector can also be used to track blocks that are ready to be erased. Once a complete block is no longer needed, the TRIM manager 42 will trigger a garbage collector or other erase mechanism to erase the block so that the block can be reused.

The S.M.A.R.T. function 39 processes S.M.A.R.T. commands or protocol commands from the host, such as monitoring or controlling error correction, wear, bad blocks, and other flash memory management. S.M.A.R.T. represents self-monitoring, analysis and reporting techniques. The host can use S.M.A.R.T.'s command set to monitor some important information from the SSD device, such as shutdown time, wear leveling, and so on. The host can use this information to diagnose and identify the useful life of the SSD. Based on usage, the host can use these messages to determine the warranty coverage. The host can replace the SSD drive before the SSD drive is damaged. In RAID, hosts can use the S.M.A.R.T. command to avoid more expensive RAID 5 configurations.

The service manager 211 can ensure that the data is completely written or transferred to the NAND flash memory. Over-provisioning 208 sets and manages spare blocks in NAND flash memory 196. The secure partition of the NAND flash memory 196 is not allowed until the security manager 215 can perform the password verification process. A partition can be part of an entire drive or drive. The refresh manager 202 can refresh the data in the NAND flash memory 196 periodically (e.g., daily or weekly). The secure erase manager 18 can perform a more secure erase operation, for example, when needed, all 1s or all 0s can be written to a block to delete data in the block.

The power backup 195 provides backup power so that when a power failure occurs, the SEED 200 can write data from the SSD DRAM buffer 194 to the NAND flash memory 196. NVRAM 217 provides more non-volatile storage for important metadata messages, such as business logs, metadata, and configuration messages.

Figure 4 shows a flow chart for splitting and grouping write data by a VMD driver. The host sends a write command to the data split manager 108, and if the compressed encryption engine 106 is enabled, the host writes the data after the compressed encryption engine 106 compresses or encrypts the write data. The compressed entry for encrypting or compressing the archive can be modified in the metadata buffer memory 120.

The data splitting manager 108 inside the VMD driver 100 (as shown in FIG. 2) classifies the host data according to the data type, for example, by checking the file's file name or parsing the FAT and FDB. The temporary file is stored in the temporary file area 124 of the virtual disk_01 and has a table which is completely modified in the metadata buffer memory 120. When the power is turned off and the fault occurs, the temporary file is not stored in the flash memory. Alternatively, the temporary file area can be overflowed and grouped into the SSD. Alternatively, for a particular operation, the function can be disabled, for example, a server.

The paging file is stored in the paging area 38 in the buffer memory, and is grouped into the meta page by the page file grouping processor 116 together with other paging files containing the same paging file data type. The grouped pages are then sent to the SEED 200 by the output buffer 110 and can be stored in the DRAM and then stored in the flash memory. Output buffer 110 generates an ECC code. The entries of the group archive can be modified in the metadata buffer memory 120.

The metadata files, for example, FAT and FDB are all stored in the metadata buffer memory 120. With the FDB metapage grouping processor 114, the FDB can be divided into metapages. The grouped pages are then sent to the SEED 200 by the output buffer 110, which may be stored in the DRAM. The ECC code may be generated and carried by the output buffer 110. The grouped metadata archive entries can be modified in the metadata buffer memory 120.

The user profile is stored in the data write buffer memory 20, and the metafile user profile packet processor 113 divides the user profile into other metafiles along with other user profiles containing the same user or non-transitory profile type. The grouped pages are sent to the SEED 200 by the output buffer 110 and can be stored in the DRAM, followed by the flash memory. The ECC code may be generated and carried by the output buffer 110. The group table entry of the grouped file can be modified in the metadata buffer memory 120.

When the refresh recovery manager 126 detects a power failure, the virtual disk 188 is refreshed by the virtual disk power off refresher 125. The data of the virtual disk 188 is sent by the SEED 200 to the output buffer 110 for storage. In addition, the data write buffer memory 20, the metadata buffer memory 120, and the page break area 38 in the buffer memory can be in the virtual disk. The temporary file area 124 of the virtual disk_01 can be in the buffer memory.

Figures 5A through 5B show a flow chart of data classification and cancellation of read packets by the VMD driver. The host sends a read command to the data split manager 108. The data split manager 108 is further used to distribute the host read data, after the data compression and encryption engine 106 decompresses or decrypts the host read data. The data splitting manager 108 built into the VMD driver 100 (as shown in FIG. 2) classifies the host write data according to the material type, and the trigger selector 104 selects the material according to the data type.

In Figure 5A, the user profile may be recently written and still available from the data write buffer memory 20. The data can be stored in SEED 200 and must first be received by buffer 110, which is ungrouped by metapage ungrouping engine 36 and then selected by selector 104. The data for canceling the group meta page is stored in one of the four read buffer memories. The NRA/RA split manager 34 separates recent access data from Non-Recently-Accessed (NRA) data. The NFA/FA split manager 30, 32 separates frequently accessed data from Non-Frequently-Accessed (NFA). The selector 104 selects one of the four read buffer memories 22, 24, 26, 28 depending on whether the material is identified as recent access or frequent access.

In FIG. 5B, the temporary file is not stored in the flash memory and can only be read from the temporary file area 124 of the virtual disk_01 by the data splitting manager 108 in response to the host read. The paging file is selected by the selector 122 from the paging area 38 in the buffer memory or from the paging file element page cancellation packet processor 116 to unselect the selected flash memory. The metadata, for example, the FAT and FDB entries are selected by the selector 118 from the metadata buffer memory 120, or read from the output buffer 110 and the FAT/FDB metapage cancels the flash memory selection after the packet engine 114 cancels the packet. . When the power is restored, the virtual disk power-on refresher 123 is triggered to read the refreshed virtual disk material 121 from the SSD or flash memory 20.

Figure 6 shows the internal storage map of the Endurance Transaction Layer (ETL) in the host DRAM. The internal storage space 289 contains several virtual disks, which can be independently defined for direct storage access or for file system based access. The virtual disk_00 284 stores the OS boot image and the alternate OS boot image. Virtual Disk_01 288 stores temporary files. The virtual disk _02 236 stores the browser file, and the browser file can be discarded when the power is turned off. The virtual disk _03 238 stores the temporary file used by the application, and the temporary file can be discarded when the power is lost. Alternatively, the data in virtual disk_02 236 and virtual disk_03 238 can be grouped and written to SEED 200.

Buffer memory 286 stores metadata and tables such as FAT, FDB, compressed tables, grouped tables, and buffered memory maps. The buffer memory 232 stores the paging file. Buffer memory 234 stores data writes. These buffer memories will be backed up in the event of a power failure. The read buffer memories 290, 291, 292, 293 store data for FA, NFA, RA, and NRA, and may be discarded in the event of a power failure.

VMD driver 278 and VMD application 280 are also stored with operating system function 282, refresh manager 277, user application 276, proprietary IO driver 274, and setup and environment parameters 272.

Figure 7 shows a schematic diagram of the Endurance Transaction Layer (ETL) storage map in SEED SSD DRAM. The internal storage space of the SSD DRAM buffer 194 includes the metadata buffer memory 140, the temporary file buffer memory 142, the buffer memory 144 of the paging file, the refresh data 145, the read buffer memory and mapping table 151, the buffer data 152, and The data is written to the buffer memory 154. These buffer memories can store data from buffer memory located in the internal storage space 289 of the host DRAM. The paging archive and mapping table 148 and log archive page grouping 146 are also assigned internal storage space. The system usage area 150 is reserved. The spare and exchange block 156 provides spare and exchange operational blocks. Table 162 stores the status of the flash memory page and the bad block message. The block and erase count table 164 stores the erase count and the block information based on the basic contents of the block. The S.M.A.R.T. data collector 170 collects and stores status messages of lower level flash memory modules and controllers that may be read by the host software.

Figure 8 is a memory map of a flash memory. The flash memory storage space in the NAND flash memory 196 includes a partition_01 302, the partition includes a boot usage 0x80 with a simplified VMD program and an encryption/decryption function, partition_02 304, and partition_02 304 has other images, such as The operating system boot image 306, the backup boot image 308, and the boot usage 0x00. The VMD application 310 is stored in the flash memory and acts as a virtual disk manager. The data bank 312 stores frequently used images, while the data bank 314 stores images that are infrequently used.

Figure 9 shows the mapping or grouping of all or part of a page into metadata based on the type of material. Each data type has its own group mapping table 316, such as paging files, temporary files, metadata, and general user data. In this embodiment, only the user profile is mapped into the flash memory, although in other embodiments, the access memory may map additional data to the flash memory.

The metapage is a larger storage unit than a flash memory page. Flash memory is organized into multiple channels and multiple chips or each channel includes a plurality of cores and each core has multiple layers. The size of the metapage is the number of channels multiplied by the number of layers multiplied by the number of flash memory layers. For example, the meta page size for four channels and two planes is 8 pages.

When a full page (FP) is grouped into metapages 318, the location X of the page write of the page stores entries in the packet mapping table 316 of the host LBA and has a pointer to the packet metapage 318. YY-DRAM-MP.

When a partial page (PP) is grouped into a local packet metapage 320, a local page start position A(N), and a partial page length LEN(N) partial page host LBA group mapping table 316 are stored as one Recorded and has a pointer to the partial page grouping page 320, YY-DRAM-MP. After the host LBA and length are attached to the data, the data is stored in page 320 of the PP packet page.

Figure 10 shows a map of compressed pages. By storing compressed data on flash memory pages instead of conventional data, flash memory durability may increase because compression reduces the size of the data, which is required to store data in flash memory. The compressed data may buffer the memory in the host DRAM or SSD DRAM buffer 194 and back up the compressed data to the NAND flash memory 196 when the buffer memory is full.

The VMD driver 100 may compress some of the data before storing the data in the virtual disk 188 or in the data write buffer memory 20. The host writes a few pages of data in the normal way, indicating the logical address (LBA), the page number, and the total sector count for the length of the statistics. For example, the host can write DATA1 to the LBA 2048, SC = 128, 8 pages, 16 sectors per page. The compression engine, for example, the encryption decryption engine 240 in the VMD driver 100, compresses 128 sectors of data into 48 sectors of compressed data. The compressed data of 48 sectors includes the data header, some compressed data is stored in the first page compressed page, and the compressed data storage of more than two pages can store 3 compressed pages. This is a significant reduction over the uncompressed 8 pages.

The VMD driver 100 stores the compressed data of 3 pages in the virtual disk 188, or in the material write buffer memory 20, when pointing to a page of the compressed material 214 by the pointer MAP_PAGE_PTR stored in the compressed LBA table 212.

The VMD driver 100 further creates an entry LBA table 210, which may be part of a unified mapping table or part of the metadata buffer memory 120. However, the entries in the LBA table 210 are special mapping codes to compress the data.

The mapping entries in LBA table 210 include the first two bits of compression status bits. The first compressed state bit 1 represents a compressed access and 0 represents a host access to an uncompressed data rule. For example, page 127 maps to uncompressed data using PTR1.

When the first compression status bit is 1 and the second compression status bit is 0, the entire size (page number) of the uncompressed data segments is included in the entry of the LBA table 210. When the first compression status bit is 1 and the second compression status bit is 1, an offset is included in the entry of the LBA table 210. The offset is the first entry of the compressed data segment, and the entry contains the size of the segment.

In the example where the host writes DATA1, SC=128, 8 pages to the LBA 2048, there are 8 page entries in the LBA table 210 in the DATA1 segment. LB A of 2048 selects 128 pages in LBA table 210. A total of 8 pages of entries in the LBA table 210 are used. The first entry represents the total data size, and the next seven entries contain the offset of the first entry back.

When the host reads page 133 (LBA = 2128, SC = 16), then the entry in the LBA table 210 of page 133 is read. The offset stored in page 133' is 5, which points backwards to the entry of page 128, which contains 3 pages of all compressed material. The entry of page 128 is read from the compressed LBA table 212 and the entries of the two compressed LBA tables 212 below, for a total of 3 pages of entries, which is the size of the compressed material. Each entry points to a virtual disk 188, SSD DRAM buffer 194 or a compressed data page in NAND flash memory 196. These three compressed pages are read and decompressed to recover the original 8 pages of uncompressed data blocks. Then, extract the data that the host is reading from the uncompressed data. Among them, online compression can be performed using hardware circuits or firmware control algorithms or software.

The standby and swap operations are shown in Figures 11A through 11B. As shown in FIG. 11A, the spare block is in Flash, for example, in NAND flash memory 196. The data has been written to the flash memory block X, and the occupied portion 322 includes several full pages and one partial page. The data will also be written to the spare flash block Y of portion 324, which also includes several full pages and partial partial pages. The data in blocks X and Y will be combined from the free spare block Y.

The entire page from portion 322 is written to the upper portion 326 of swap block Z. The partial pages from blocks X and Y are then written into DRAM page buffer 330 and combined and then written together into one of the swap blocks Z. The next full page from portion 324 is written to lower portion 328 of swap block Z. Finally, blocks X and Y are erased.

As shown in FIG. 11B, the spare block Y is in the DRAM, such as in the SSD DRAM buffer 194. The data is written into the flash memory block X, occupying a portion 322 containing a few full pages and one partial page. This material is copied into the spare block Y in the DRAM, occupying the upper portion 332. The data is written to the spare flash block Y in the lower portion 324, which is a few full pages and one partial page. The data in blocks X and Y are combined into an idle spare block Y. Since the spare blocks are in DRAM, the partial pages from blocks X and Y can be directly combined. The entire spare block Y is then copied to the swap block Z, including the upper portion 326 and the lower portion 328. Finally, because block Y is in DRAM and no erase operation is required, the unique block is erased. Having a spare block Y in the DRAM can improve performance and reduce the loss of the flash memory block, depending on the time required for the erase operation.

Figure 12 shows the multi-level error check. The flash memory array 400 can use multi-level cells, which are more susceptible to bit errors when the flash memory access controller 402 on the internal bus 404 reads. Encoder 398 is capable of generating a low density parity check code and is appended to the data from read buffer memory 396 as a spare byte before being written to flash memory array 400. When data is read into the read buffer 392 of the flash memory array 400, the parity decoder 394 checks the stored parity against the generated parity to detect and correct the read error. When it is not possible to use LDPC_1 encoding error correction, a longer, more complex encoding LDPC_2 check 376 is enabled for pages and blocks of flash memory data.

The LDPC_2 generator 378 generates a longer parity code LDPC_2 and is buffered to the bus 404 by the LDPC_2 write buffer 380. Due to the degradation of the physical cells in the selected flash memory page, more protection is required, resulting in LDPC_2. LDPC_2 is generated and appended to the data to be written to the enabled page or block in the block of flash memory array 400.

RAID parity 390 is enabled when the LDPC_2 code cannot correct the read error. RAID verification can span multiple physical devices in a flash memory array. The RAID parity code is generated by the RAID parity generator 388 and buffered by the RAID buffer 382 before the RAID parity code is written to the bus 404 along with the write data. It occurs because the selected flash memory page requires more protection due to degradation of the physical unit.

When the RAID parity code fails to correct the read error, iterative controller 386 is triggered to test the adjustment voltage. The read data is stored in the iteration fault data buffer 374. The voltage adjustment controller 384 is controlled by the flash memory controller, and the flash memory controller writes a specific value into the flash memory to read the data adjustment reference voltage for the flash memory array 400. Data readback to test if the newly set reference voltage can reduce errors. Therefore, another round of LDPC_1/LDPC_2/RAID verification will be performed. If still unreadable, the read data is stored in the iteration fault data buffer 374 and another voltage is selected to perform another round of readback testing. When all of the voltage iterations have been tested and failed, the iteration fault data buffer 374 loads the test results to cause the data recovery analyzer 372 to determine if the data on the internal bus 406 is usable or if a fatal error has occurred. The multi-level of error correction code and parity improves the life and endurance of the flash memory.

Figures 13A through 13B show the bad block erase count table and the page status table. As shown in Fig. 13A, a write date is stored at the beginning of the block. The bad block erase count table 471 stores entries of the flash memory block. Each entry contains a block status field, using 3 bits to indicate if the block is empty (erased), used, blocks with some junk pages, all bad blocks, or a bad page with some bad pages and some bad pages Piece.

Each block entry has a 13-bit erase count and a 16-bit write date. When the device is produced, the 13-bit erase count starts counting 0. Each time the block is erased, the count is incremented once. This erase count can be used for wear leveling control and can be used to check the health of the device at S.M.A.R.T. The date written is the date the block was last written. It is used for refresh functions. For TLC devices, the time within one year can be reserved. The date of writing can be a coded material (MM-DD-YY) or a value, for example, it can be the date of manufacture of the device that was initialized at the time of production.

There are entries for all pages in the page status table 473 block. Each page has a 3-bit page status field. Since each page entry is only 3 bits long, many page entries may be packaged together. The page status indicates an empty, used, junk page, bad page, or a higher level error correction page. For example, a longer ECC code.

As shown in Fig. 13B, the write date is stored on a base page instead of being stored on a base block. The bad block erase count table 471 records the entries of the flash memory block. Each entry contains a 13-bit erase counter and block status field, with 3 bits indicating whether the block is empty (erased), used, some blocks of junk pages, all bad blocks, or some bad pages and Some bad blocks of good pages.

The bad block erase count table 471 does not store the write date. Instead, the page status table 473 stores the write date. For the 13B picture, the write date is the date the page was written. For Figure 13A, it is the date the block was written. Because each block has a lot of pages, storing data for pages instead of blocks requires more storage tables, however, it increases endurance. The refresh is for the page and not for the entire block.

Figure 14 is a block diagram of a Super Enhanced Endurance Device (SEED) with an endurance controller. As shown in Figures 1 and 3, optionally, the SEED 200' is docked with the SSD 350 and then connected to the flash memory 342 instead of being directly connected to the NAND flash memory 196. The SSD 350 can be integrated with the SEED 200'. The SEED 200' can work independently without using a host VMD drive. Some of the features that reside on the host VMD drive may be implemented.

SEED 200' has a host interface 16, SEED 200' uses a bus, such as PCIe, SATA, or Universal-Serial-Bus (USB), NVMe, lightning interface, eMMC, iSSD, etc. with host 300 (such as the first Figure) Communication. The data from the host interface 16 is sent to the endurance controller 360. The endurance controller 360 replaces the SEED controller 192 in Fig. 3, and many portions have the same reference numerals as already described in Fig. 3.

The endurance controller DRAM 358 can store one or more virtual disks, buffer memory, S.M.A.R.T. messages, firmware and other buffers and tables. The low-level SSD DRAM 340 can store security messages, bad page management tables, mapping tables, erase counter tables, spare and swap blocks, other buffers and tables. The low level DRAM interface 336 is read and written from the endurance DRAM controller 358. The refresh manager 202 can periodically refresh the data in the low level SSD flash memory 342. The refresh recovery manager 43 manages the recovery operation using the refresh data. The temporary manager 348 controls the temporary data, and the compression map manager 352 manages the compressed table. The security manager 346 manages security functions.

The multi-channel flash memory interface 14 programs the data pages and erases the blocks in the flash memory 342 and may be organized into several channels. The ECC manager 338 generates a low level error correction code (ECC) to add data to the person and compares the stored ECC with the regenerated ECC to detect and correct read errors. It also manages flash memory pages that require additional protection, generates ECC for these pages, and stores and recycles ECC when needed. The bad page manager 206 tracks the bad page locations in the flash memory 342. This can extend the life of a single block because only one page in the block can be bad, while other pages can be used continuously. More complex bad block management may reduce the overall wear of the flash memory drive.

Wear equalizer 40 provides two methods of wear leveling. One method is to dynamically select the lowest wear leveling block write data from the available empty blocks. Another method is to count the threshold based on the wear leveling. Once this threshold is reached, the flash memory block will move from one physical block (with low loss equalization count) in flash memory 342 to another empty physical block (with high loss equalization count). The endurance controller 360 and the SSD 350 controller can be functionally integrated or separated.

Figures 15A through 15E show the VMD driver processing host write instructions on the host. In step 1002, the host request includes a logical address, such as an LBA for unifying the index of the mapping table. Read the unified mapping table matching entries, or parse the entries of the files FAT and FDB to determine the file extension (File Extension) and data type. The first few bits in the matching entry are data type bits to indicate what type of data is stored in the logical address. Different processes are scheduled depending on the data type bit.

In step 1004, when the data type bit of the matching entry is 10, the data is a FAT or FDB entry. The metadata writing process is called, which is described in detail in Figure 15B.

In step 1006, when the data type bit is 11, the user profile file process file is called. The user data writing process is described in detail in Fig. 15C. The user profile is the user and application data that should be stored in DRAM and then flushed to the flash memory.

In step 1008, when the data type bit of the matching entry is 001, the data of the paging file is used to exchange the peripheral storage of the main storage. These exchanges are performed by the storage manager on the host. These files do not need to be stored in flash memory to reduce losses. The paging data writing process is called, which is described in detail in Fig. 15D.

When the data type bit of the matching entry is 01 (non-practical type), in step 1008, the temporary profile data need not be stored in the flash memory. The temporary data writing process is called and has been described in detail in Figure 15E.

Figure 15B shows the metadata writing process. In step 1102, the host data is written into the metadata file area buffer memory in the DRAM of the host (286 in Fig. 6). In step 1104, when the buffer memory is full, In step 1106, the metadata of the buffer memory is moved to the metadata packet buffer in the DRAM. Step 1108, after the standard size is reached or the data is received, the grouping process is performed on the metadata of the packet buffer.

The grouping process divides the metadata into metapages. Step 1110, when the metapage is full, in step 1112, the page of the full material is written to the SEED, SSD or flash memory.

Figure 15C shows the process of writing user data. In step 1122, the host data is written to the user profile area of the host DRAM (234 in Figure 6) to buffer the memory. Step 1124, when the buffer memory is full, in step 1126, the user data in the buffer memory is transferred to the user data packet buffer in the DRAM. In step 1128, when the standard size is met, the grouping process is performed according to the packet buffer user profile.

The grouping process divides the user data into meta pages. Step 1130, when the metapage is full, in step 1132, the full user data metapage will be written to the SEED, SSD, or flash memory.

Figure 15D shows the paging data writing process. In step 1142, the host data is written into the paging data file area buffer memory in the host's DRAM (232 in FIG. 6). Step 1144, when the buffer memory is full, in step 1146, the page data in the buffer memory is moved to the page data packet buffer in the DRAM. Step 1148, when the standard size is satisfied, the grouping process is performed according to the packet buffer paging data.

The grouping process divides the paging data into metapages. In step 1150, when the metapage is full, in step 1152, the metapage of the full paged material is written to the SEED, SSD, or flash memory.

Figure 15E shows the temporary file writing process. In step 1162, the host data is written into the temporary file area of the host's DRAM virtual disk_01 (288 in Figure 6). Step 1164, when the virtual disk is full, in step 1166, the temporary file in the virtual disk is moved to the temporary data packet buffer in the DRAM. Step 1168, when the standard size is met, the grouping process is performed according to the temporary data in the packet buffer.

The grouping process groups the temporary data into a metapage. In step 1170, when the metapage is full, in step 1172, the metapage of the full temporary data is written to the SEED or SSD instead of the flash memory.

Figures 16A through 16E show the host VMD driver processing host read instructions. The host request contains a logical address, such as an LBA for unifying the index of the mapping table, step 1012. Read the unified mapping table matching entries, or parse the entries of the files FAT and FDB to determine the archive file extension and data type. The first few bits in the matching entry are data type bits to indicate what type of data is stored in the logical address. Different processes are scheduled depending on the data type bit.

In step 1014, when the data type bit of the matching entry is 10, the data is a FAT or FDB entry. It is called during the metadata reading process, which is described in detail in Figure 16B.

In step 1016, when the data type bit is 11, the user profile read process is called. The user profile read process is detailed in Figure 16C.

In step 1018, when the data type bit of the matching entry is 001, the data is a paging file. These files do not need to be stored in flash memory to reduce losses. The paging data read process is called, and the calling process is detailed in Figure 16D.

In step 1018, when the data type bit of the matching item is 01 (non-existing type), the data of the temporary file is not stored in the flash memory. The temporary data read process is called, and the calling process is detailed in Figure 16E.

Figure 16B shows the metadata reading process. Step 1120, when the requested metadata is found in the metadata file buffer memory of the host DRAM (in 286 of FIG. 6), step 1022, the requested metadata is read from the buffer memory, and Transferred to the host.

Step 1120: When the requested metadata is not in the buffer memory, in step 1024, the metadata is extracted from the SSD and written into the metadata cancellation packet buffer in the host DRAM. Step 1026, if the metadata is grouped, the ungrouping process is performed on the packet metadata. In step 1028, the unpacking metadata is read from the metadata cancellation packet buffer and transmitted to the host.

Figure 16C shows the user data reading process. Step 1130, when the requested user profile is found in the user profile area write buffer memory of the host DRAM (286 in FIG. 6), step 1032, and then, the request user data is read from the write buffer memory, and is Transfer to the host. The write buffer memory retains the data written by the most recent host. The requested user profile may also be one of four read buffer memories combined for four types of data, namely RA/FA, RA/NFA, NRA/FA, and NRA/NFA, loading user data according to read access, Not necessarily when the host writes data.

Step 1160, when the requested user profile is found in one of the four read buffer memories (290, 291, 292, 293 in FIG. 6) of the host DRAM, step 1062, reading the requested user profile from the read buffer memory. And transferred to the host.

Steps 1130 and 1160, when the requested user profile is not in any of the five buffer memories, in step 1034, the user profile is obtained from the SSD, and then written into the user profile cancellation packet buffer in the host DRAM. In step 1036, if the user profile is grouped, the ungroup process is performed to ungroup the user profile. Step 1038: Unpacked user data is read from the user data cancellation packet buffer and transmitted to the host. The ungrouped data is stored in one of the four read buffer memories.

Figure 16D shows the paging data reading process. Step 1140, when the requested paging data is found in the DRAM (Fig. 6 232) paging data file area buffer memory of the host, in step 1042, the requested paging data is read from the buffer memory and transmitted to the host.

Step 1140: When the requested paging data is not in the buffer memory, in step 1044, the paging data is obtained from the SSD and written into the paging data cancellation packet buffer in the host DRAM. In step 1046, if the paging data is grouped, the ungrouping process is performed to ungroup the paging data. In step 1048, the unpacking page data is canceled from the paging data cancellation packet buffer and transmitted to the host.

Figure 16E shows the temporary data reading process. Step 1150, when temporary data is found in the temporary data file area buffer memory in the virtual disk_01 in the DRAM of the host (280 in FIG. 6), in step 1052, the requested temporary data is read from the buffer memory. And transferred to the host.

In step 1150, when the requested temporary data is not in the buffer memory, in step 1054, the temporary data is retrieved from the SSD and written into the temporary file cancellation packet buffer in the host DRAM. Step 1056, if the temporary data is grouped, the ungrouping process is performed to ungroup the temporary data. In step 1058, the unpacked temporary data is read from the temporary data cancellation packet buffer and transmitted to the host.

Figures 17A through 17B show the metapage composition process. A metapage is a multiple of a page size. Two separate meta pages are used to form each data type group, and one meta page constitutes the entire page and the second meta page constitutes a partial page.

In step 1202, the size of the new ungrouped material added to the packet data is determined. In step 1204, when the size of the new material is within 512 bytes of the full page size, the new material is considered to be a complete page. If the new data exceeds the size of one page, each page can be processed separately.

In step 1204, when the new material is a complete page, in step 1206, in the current meta page Z, the next available page position X can be found, and the current meta page Z constitutes a complete page. At step 1210, the new full page is moved to location X within metapage Z. In step 1212, the corresponding composition map entry is updated to the newly added material. The LBA of the host data, the HOST-LBA, the material type YY00, the number of metapages Z, and the page position X in the metapage Z are recorded in the entry.

Step 1208, when the meta page Z is full, in step 1216, the meta page Z is written to the SEED or SSD. In step 1218, the group mapping table entry of the host LBA is modified to point to the complete metapage in the SSD by the pointer SSD-LBA-MF, but still represents the location X of the page. The last data type bit is modified to 1 to indicate SSD storage, not DRAM storage, YY01.

Figure 17B shows the division of a new partial page into a metapage M for grouping partial pages. In step 1226, the location A(N) for the partial page material in the next available metapage M is fixed. In step 1220, the new partial page data is moved to the beginning of the metapage M, position A(N). The overhead is also moved with new data, for example, headers.

In step 1222, the corresponding entry in the composition mapping table is updated to the latest added data. When the host uses LBA for new data, HOST-LBA, data type YY10, number of metapages M, starting position A(N) in metapage M, data length and overhead are recorded in the entry. The third data type bit is set to 1 to indicate a partial page, not a full page.

In step 1228, when the metapage M is full, in step 1236, the metapage M is written to the SEED or SSD. Step 1238 shows the group mapping table entry of the host LBA, modified by the pointer SSD-LBA-MP to point to the local metapage in the SSD, and still represents the starting position A(N) and length. Change the last data type bit to 1 to indicate SSD storage, YY11.

Figure 18 shows the encryption and compression process by the VMD driver. These functions can be performed in the compression decompression engine 242 in FIGS. 1 and 2, and in the encryption decryption engine 240. When the host write data is intercepted by the VMD driver 100, the file extension is checked. Audio, video, graphics, libraries, and other file extensions may indicate that the data has been compressed, for example, by a user program. In step 510, the file file extension file name is prohibited from being compressed.

Step 512, when encryption is enabled, in step 514, the file is encrypted using an encryption key. In step 516, in the file system, an encryption flag is set for the file. Alternatively, the temporary and paged material types may not be encrypted or decrypted.

Step 518, if compression is enabled, step 520, the file is compressed. In step 522, a header file is added, the header file having an identifier using a compression algorithm and a new data size. Step 524, in the file system, set a compression flag for the file. Alternatively, the temporary and paged material types may not be compressed or decompressed.

Figures 19A through 19B show the process of performing backup or exchange in SEED. Step 530, when new data arrives in the existing page in the flash memory block, in step 532, when the flash memory page is writable, in step 534, the new data is written to the flash memory page.

Step 532, when the flash memory page cannot be written, for example, in the block, the page has been written before the other pages, and the flash memory only pages are written in the forward sequence, step 536, but the spare block Available for block, step 538, then new data is written to the same page in the spare block of the SSD DRAM buffer 194.

In step 528, when the flash memory page cannot be written, or there is no spare block available, the new data is written to the empty spare block in the SSD DRAM buffer 194. The process continues in Figure 19B. In step 540, when other empty spare blocks are available, the process ends.

Step 540, when no more spare blocks are available, step 542, selecting the spare block that is written the most, or not frequently accessed. In step 543, the dirty page in the selected spare block is combined with the valid page in the old block to be written into the selected spare block. In step 546, the combined page in the selected spare block is written into the empty block of the flash memory, and the block is exchanged. At step 548, the selected old block is erased.

Figures 20A through 20D show the detection and processing of bad and bad blocks. In Fig. 20A, in step 554, once the block in the flash memory is erased, the erase counter of the physical block is incremented, and the state of the block is changed to an empty block according to the previous block state and the current page state (000). ) or an empty block with a bad page (100). The bad block erase count table is stored in the SSD DRAM buffer 194, and when there is not enough space in the DRAM, the table is backed up to the NAND flash memory 196. The bad block erase count table includes the number of erases for each physical block and the state of the block. The block state can be a 3-bit value, 000 for good empty blocks, 011 and 111 for bad blocks, and 100 for some bad pages and some good pages for bad blocks.

The bad block erase count table further includes a page status table that tracks bad blocks within a block. The page status value of 000 indicates a good page, 001 indicates a protected page, the page uses a 100-bit secondary ECC, rather than a 25-bit first-level ECC, 010 indicates that the page is used, and 110 indicates that the page has garbage or trim data. 11X indicates a bad page.

After the block is erased, check the status of each page in the block. Step 556, reading the page status table of the physical block, and the current page is initialized to 0 pages. Step 562, when the current page status is 11X, the current page has been marked as a bad page. This page does not require further processing. Step 560, when the last page in the block is not currently exceeded, in step 558, the current page is incremented to the next page in the block, and step 562 is repeated for the processing of the next page.

In Figure 20B, all of the physical blocks in the block have been processed. In step 564, the number of bad pages in the block is determined. Step 566, when the number of bad pages in the block exceeds the threshold value T3, the block is considered to be a bad block. In step 568, in the block bad erase count table, the block state of the physical block is modified to 011. The physical block will no longer be used. At step 570, the local bad block counter (BAD_BP_CNT) count is decreased and the bad block counter count is incremented.

In Fig. 20C, step 562 (Fig. 20A), the current page is not marked as a bad page before. The erase operation erases the value of all bits in the erased page to an erase value, such as 1. Reads the bits in the current page to determine if all bits have been erased. In step 574, a count value is obtained, the count value being the number of bits in the page in the unerased state, such as 0 bits. These are the wrong bits. However, ECC can correct these errors, so if the number of error bits is small, the page may still be available.

Step 572, when the unerased bit count is less than the first threshold T1 (indicating too many error bits, increasing the risk of using these pages, even if there is additional ECC software protection), step 576, and the current page state needs protection (XX1), then, the page has been marked as requiring ECC secondary protection. At step 582, the page status is modified to a blank page (001) that needs to be protected. Return to Figure 20A to process the next current page.

Step 572, when the unerased bit count is less than the first threshold T1, step 576, and the current page state is not a page to be protected (XX1), and the page has not been protected by the secondary ECC. Step 578, when the unerased bit count is greater than the second threshold T2 (indicating that the level of the error bit is an error that may result in a fatal error and requiring additional ECC software to help correct), step 584, secondary ECC counter The value is incremented. In step 582, the page status is changed to 001. When the host data is stored in the physical page, the secondary ECC will be used. Return to Figure 20A to process the next current page.

In step 576, when the page has not been protected by the secondary ECC, step 578, the unerased protection bit count is not greater than the second threshold T2, and the status of the page is a good page. The first level of ECC is sufficient to correct errors that may occur in the current page. Step 580, if it has not been marked as a good page, the state of the page is changed to 000. Return to Figure 20A to process the next current page.

In Fig. 20D, step 572 (Fig. 20C), the current page has unerased bits that exceed the first threshold T1. Exceeding the T1 threshold indicates the number of ECCs that can be corrected for the unerased bits in the page that exceed the second level. The page is bad and cannot be used safely.

In step 586, when the state of the physical block in the block (1XX) is a bad page, in the bad block erase count table, the block has been marked as a bad page block. There are other bad pages in the block, and no block state needs to be changed. However, in step 592, the current page is marked as a bad page by changing the page state to 11X in the page status table. In step 594, the bad page counter is incremented, returning to Figure 20A to process the next current page.

In step 586, when the physical status block is not 1XX, the block has not been marked as a local bad block in the bad block erasure count table. There are no other bad blocks in this block. In step 588, at the block erase count table 164, the state of the block is changed to an empty block having a bad block (100). In step 590, the local bad block counter (BAD_BP_CNT) is incremented. Further, in step 592, the previous page is marked as a bad page by changing the page state to 11X in the page status table. In step 594, the bad page counter is incremented, returning to Figure 20A to process the next current page.

SSDs may contain many flash memory chips (eg, 16 flash memory chips). Some special cases may be encountered, for example, when one layer of the flash memory chip is bad or the entire chip is bad. In the case of over-provisioning, the SSD's flash memory capacity can absorb a full layer of capacity loss or loss of capacity of the entire flash memory chip. The special algorithm of the device controller can be used to ignore the loss, for example, to recover the data, and then adjust the size of the metapage unit of the flash memory device to avoid layer errors or chip errors. Over-provisioning can also be achieved by using a free chip instead of a faulty chip.

Figures 21A through 21B show the flash memory block using the table in Figure 13A for the refresh operation. When the refresh is initiated, for example, periodically (once a week, etc.), step 602, the current date is obtained. In step 604, the current block is set to the first block, and in step 608, if the block is not a bad block, then, in step 610, the block erase count and the block write date are read from the bad block erase count table. Step 612, calculating the number of days from the last write to the current date, for example, subtracting the last written date from the current date. Step 614, when the number of days of the last write to the current date exceeds the retention time, then, in step 618, all valid pages in the block are moved to the blank page in the spare block, and to pages in other previously refreshed blocks. Packed together.

In Fig. 21B, in step 620, when the spare block in the DRAM fills up, the data of the spare block in the DRAM is moved to the spare block in the flash memory having the lowest erase count. In step 624, the old flash memory block is erased. In step 628, when there are more blocks to process, in step 630, the current block advances to the next block.

Figure 22 shows the internal cleanup operations performed on the host. Internal cleanup operations can be performed on some or all of the host's files. Select an archive, step 650, to obtain the last access date of the archive. Step 652, using the current date to calculate the number of days since the file was last accessed. In step 654, the number of days is less than the cleaning threshold. In step 656, the file will be skipped and the next file selected. Step 654, when the number of days since the last access of the file exceeds the cleaning threshold, step 658, if the file type is a temporary file, log or page, the file will be deleted and automatic cleaning is configured. In step 670, the user can be prompted and asked whether to delete the file. If the user responds, the file is deleted. Step 672, if the user does not choose to delete the file, repeat the file search and file deletion until the next internal clear file is selected.

Figure 23 shows the log file that the SEED SSD receives from the host. Step 674, when the SEED receives a log file from the host, the SEED moves the log file into the log grouping table. In step 676, any metadata related log files are transferred to the metadata buffer memory. In step 678, the completion flag is sent back from the SEED to the host to indicate that the log file has been successfully written.

Step 680, when the log table is full, in step 682, the log grouping table is written to the flash memory.

Figure 24 is a flow chart of the host writing data to the SEED SSD DRAM buffer memory. When the host data is written to the SSD DRAM buffer 194, in step 684, the enable 1 key or flag bit along with its LBA address, serial number, and data checksum are written to the log packet table. In step 681, a write data checksum is generated. The log is written first before the actual data movement is written. In step 686, the host writes the data in the form of a metapage, and the metapage data is transferred to the associated buffer memory. In step 688, various metadata tables, such as FAT, FDB, grouping table, compressed table, and other metadata tables are transferred to the associated ETL table area in the SSD DRAM buffer 194. In step 685, if the same LBA is found to have the old serial number, but the LBA does not find the log with the commit2 flag, the abort1 identifier is recorded. The new data will cover the old data of the same LBA address. Old data is not written to flash memory. Step 690, when the log table is full, in step 692, the log grouping table is written to the flash memory.

Figure 25 shows a flow chart for writing from DRAM buffer memory to flash memory in SEED. When the SEED transfers data from the SSD DRAM buffer 194 to the NAND flash memory 196, in step 694, the START2 key or flag is written to the log packet table. In step 696, the data written to the flash memory is represented in the form of a metapage. Step 698, various metadata tables, such as grouping tables, compression tables, and other metadata tables, are transferred from the ETL table area associated with the SSD DRAM buffer 194 to the flash memory. In step 695, the commit2 flag is recorded to the log grouping table. Step 699, when the log table is full, in step 697, the log grouping table is written into the flash memory. The "START1" mark record starts to move to the DRAM data, and the "START2" record starts to write data to the flash memory, the "commit2" record completes the movement to the DRAM data, and the "abort1" record the same LBA position data is added to the new data. cover.

Figure 26 shows a flow chart of the power down sequence on the host. Step 1302: When the host power supply is powered off, and the host does not have a standby power host, in step 1306, the protocol command is used to notify the SEED or the SSD that the power failure is detected. Step 1308, the host refreshes the scratchpad and the CPU buffer memory, the buffer memory, and the SEED SSD virtual disk. The system provides power to help complete the data refresh to the SEED SSD.

Step 1302: When the backup power source can be obtained, in step 1304, the protocol command is used to notify the SEED or the SSD that the power supply is powered off. Step 1308, the host refreshes the metadata buffer memory and the data write buffer memory to the SSD. Due to the controllable power outage, the CPU scratchpad, other buffer memory and virtual disk will not be refreshed, and the host will retain important data. In step 1310, the host sends a protocol command to the SSD to indicate that the data is refreshed.

Figure 27 shows the flow chart of the SEED power supply shutdown process. Step 1312: When the host sends a protocol command to the SEED, the SEED exits the garbage collection. In step 1314, the data from the host continues to be received, and at the same time, the data in the DRAM block is exchanged or exchanged, and the data in the metadata buffer memory and the direction are started. The data of the data write buffer memory is refreshed to the flash memory. Step 1316, once the host data refresh is complete, in step 1318, the SEED no longer refreshes any temporary files or paging archives in the DRAM, marks any FDB entries as obsolete, clears any FAT entries, and marks the page markers in the bad page table. For garbage. In step 1320, the ETL table and data are flushed to the flash memory. At step 1322, the S.M.A.R.T. monitoring message and the normal power down state are recorded.

Figure 28 is a flow chart of SEED power failure handling. When the host sends a power failure protocol command to the SEED, in step 1332, the SEED exits the garbage collection and receives the refresh data written by the various hosts to the preset flash memory area.

Step 1334, the refresh data area of the SSD DRAM buffer 194 receives the data of the scratchpad and buffer memory of the CPU refreshed from the host, and then writes to the predetermined flash memory area. In step 1336, the refresh data area receives the refresh data from the buffer memory of the host, and then writes the data to the predetermined flash memory area. In step 1338, the refresh data area receives the virtual disk refresh data received from the host, and then writes the data into the predetermined flash memory area.

In step 1339, the data from the SSD DRAM buffer 194 for the spare or swap DRAM block, the user data, the bad page status table, the ETL data, and the ETL table are written to the preset area in the flash memory. At step 1324, the S.M.A.R.T. monitoring message and the abnormal power down state are recorded.

Figures 29A through 29B show a flow chart for performing a flash memory page refresh operation using the table in Figure 13B. When the refresh is initiated, for example, periodically (once a week, etc.), step 603, the current date is obtained. The current block and page are set to the first block, the first page. In step 605, the retention time of the current block is calculated as a function of the number of erasures of the current block. For example, a block with a low erase count may have a longer retention time.

Step 609, when the current page is a valid use page, in step 611, the page status table is read to obtain the page write date. In step 613, the number of days since the last write is calculated, for example, the current date minus the date written by the page. In step 615, the number of days exceeds the retention time. In step 619, the content of the current page is moved to an empty page in the spare block and packaged with other pages that need to be refreshed.

In Fig. 29B, in step 621, when the spare block in the DRAM is full, the data block in the DRAM spare block is moved to the spare block in the flash memory having the lowest erase count. At step 625, the old flash memory block is erased. In step 617, when there are more pages in the current block to process, in step 623, the current page is advanced to the next page. At step 629, when there are more blocks in the current block to process, in step 631, the current page is advanced to the next block.

Figures 30A to 30B show the bad page management process in the page writing process in Fig. 30A. When a page is written to the flash memory, step 1440, the page status table is read, the page is not a bad page, but an empty page. Step 1442, when the page state is protected XX1, step 1452, generates a second level of error correction code, ECC2, for the page. Step 1454, verifying the write data, step 1456, when the data is smaller than the error occurrence threshold T1, step 1458, the page status is written as 011 in the page status table, that is, a protected page of the use status.

Step 1442, when the page state is not protected state XX1, step 1444, verify write data, step 1446, when less than the error occurrence threshold T1, step 1448, and when less than the error occurrence threshold T2, step 1450, in page state The page state is written as 010, a page that uses the state. In step 1448, when more than T2 errors are detected, in step 1452, a second level of ECC2 is generated and the page becomes a protected page.

When more than T1 errors occur in step 1446 or 1456, the processing in FIG. 30B continues. In step 587, when the block status is read as 1XX, the block is a block with a bad page, step 593, and in the page table, the page status is written as 11X, which is a bad page. In step 595, the bad page count is incremented, step 599, and a new empty page is located for receiving data written at the host.

At step 587, when the chunk status read is not 1XX, step 589, the state of the block is modified 1XX in the bad block erase count table. In step 591, the counter of the block (BP) with the bad page is incremented, and in step 593, the page state is modified to 11X.

Figures 31A through 30B illustrate the backend garbage collection process. When the backend garbage collection process is triggered periodically, step 1460, each block entry in the bad block erase count table is checked to locate a junk page that contains discarded pruned or outdated material. Step 1462, when the block status is X10, the block has a junk page, step 1464, the page status table is read for the block and the number of junk pages is calculated. Step 1466, when the number of garbage pages exceeds the threshold TP, in step 1468, the pages used in the block (not garbage, 010 and 011) are moved to the empty blocks selected from the empty block pool, and the empty block has the lowest Erase the number of counts. At step 1470, the block with the junk page is erased, and the bad block erase count table and the page status table are updated to display the erase status.

In Figure 31B, step 1472, a list of blocks from the empty block pool is created for the lowest erase count block. Step 1474, reading the erase count for each block, step 1480, when the erase count of a non-empty block is less than the threshold TE, moving the data from the low erase count block to the highest erase count block. At step 1482, the threshold value can be increased. Moving old data that has not been updated for a long time to a more wear-resistant block, so more wear-resistant blocks can receive fewer updates, releasing a low erase count block for future write/erase cycles.

Figure 32 shows a flow chart of host VMD initialization. After the host operating system startup process is completed, in step 1500, the host checks to see if the VMD is enabled. Step 1502, if enabled, the host loads and executes the VMD application 180. In step 1504, the VMD application sets the metadata and table of the buffer memory, and in step 1506, sets the virtual disk_01 for the temporary data. Step 1508, setting a buffer memory for the paging data, and in step 1510, creating a buffer memory for writing the data.

In step 1518, the virtual disk _02 of the browser data is set up, and in step 1516, the virtual disk _03 of the user application is set up. In step 1514, the data refreshed into the refresh data area of the SEED DRAM or the flash memory is loaded into the buffer memory and the virtual disk. In step 1512, four read data buffer memories are created for the FA, RA combination.

Figures 33A through 33B are flow diagrams of SSD initialization. In step 1522, the SSD firmware is loaded from the flash memory and the SSD firmware is executed. In step 1524, the firmware creates a buffer memory for the metadata and the table. In step 1526, a buffer memory is created for the temporary data. In step 1528, a buffer memory is created for the paging data. In step 1530, a buffer memory is created for writing the data. In step 1532, additional steps are performed, such as Figure 33B, before an abnormal power outage occurs.

Step 1534, reading the flash memory preset area, writing data to the SSD DRAM buffer 194 for backup or exchange, user data, bad page and status table, ETL data and ETL table. In step 1535, the buffer memory and the virtual disk load the refresh data obtained from the refresh data area of the flash memory. In step 1533, the preset area of the flash memory is erased to provide space for another abnormal power outage.

Figure 34 is a flow chart of the cleanup log area. The process is executed after the checkpoint log is inserted. In step 1536, a check serial number is selected, step 1538, and the serial number is compared to the checkpoint serial number used for the cleaning purpose insertion. Step 1538, when the serial number is before the checkpoint, step 1540, the Commit2 flag is recorded for the sequence, step 1544, since the sequence data is successfully submitted to the flash memory, all log records associated with the serial number are deleted. Step 1542, when the sequence has an abort1 flag record, step 1544, delete all logs related to the sequence number, because the original LBA data is covered by the larger serial number data in the DRAM, and no longer needs to be moved to fast. Flash memory. In step 1546, when there are no more serial number checks before the checkpoint, in step 1548, the log of the checkpoint is deleted.

Figure 35 shows an abnormal power-off check performed on the SSD at the next power-up. At step 1550, the log of the selected serial number is scanned. Step 1556, when the commit2 flag is found, or, in step 1558, when the flag of abort1 is found, in step 1569, the log associated with the serial number is deleted. If an additional serial number is reserved, step 1552, another serial number is selected and the process is repeated.

Steps 1556, 1558, when neither the commit2 nor the abort1 flag is found, step 1560, but the start2 flag is found, step 1564, then the LBA data is read, a checksum is generated and compared to the stored log checksum. . In step 1568, when the checksum matches, the log associated with the serial number is deleted. In step 1569, although the power is abnormally turned off, the data is correctly written.

Step 1568, when no matching checksum occurs, or, at step 1560, the START2 flag is not found, step 1562, then during the abnormal power down, the LBA associated with the sequence is reported to the host as a failed write. In step 1569, the log associated with the serial number will be deleted. In step 1552, if the additional serial number is retained, another serial number is selected and the process is repeated.

Figure 36 shows the abnormal power-off check performed on the host at the next power-up. Step 1580, receiving and reading the failed data write list and their LBA location from the SSD (step 1562), step 1582, and selecting the failed LBA in the list. In step 1584, the service numbers in the log table are compared to the LBA to determine if they are relevant. Step 1586, when the LBA is irrelevant, another LBA in the list, step 1582, may be selected. Step 1586, when the LBA is related, step 1588, and the commit flag is found, then the service is redone. In step 1592, each LBA in the write service log is checked and updated along with the new data record in the log. In step 1588, when the commit flag is not found, the service is revoked. Step 1590, in the write service log, checks each LBA and is updated along with the old data recorded in the log, step 1594, when more failed LBAs remain in the list, step 1582, then another LBA in the list May be selected.

Optional implementation

Several other embodiments contemplated by the present invention. It has been described to move a full meta page to SEED, SSD, or flash memory, and an almost full meta page can be moved before it is completely filled. Therefore, full can refer to the fullness of some threshold values, for example, it can be the metapage size minus 512 bytes.

Multiple encodings, pointers, etc. of data type bits and other status fields are possible. The data type status bit does not need to be in the first bit of the entry. Entries can be linked to entries in other tables, such as a separate table for tags or valid bits. Temporary files can have multiple extensions, and new extensions can be added to the list for searching. Temporary files created by well-known programs have well-known file extensions, such as word processing software and Internet browsers, and you can add additional extensions at any time. These additional archive file extensions can be added to the SEED and SSD controller's control software via firmware updates, or updated to the VMD application 180 and VMD driver 100 via software.

The size of the DRAM buffer used by each part of the ETL can be fixed by the firmware of the SSD controller. Based on the user's usage or preferences, each part of the ETL can be dynamically adjusted automatically or manually by the controller firmware. Due to the limitation of the DRAM buffer size, not all ETL functions are accommodated by the DRAM buffer at the same time. Various ETL functions can be adapted to the actual working environment. The controller can be resized by each ETL to optimize the DRAM buffer. Adaptive adjustments can be made periodically based on the device usage pattern.

For TLC flash memory devices, DRAM buffers can be replaced with NVRAM, for example, phase-change memory (PCM), ferroelectric random-access memory (FRAM), and magnetoresistance. Memory (Magnetoresistive RAM, MRAM), memristor, PRAM, Resistive RAM (RRAM), track memory and nano memory (NRAM). The advantage of NVRAM is that all ETL support tables can be kept in NVRAM (not necessary in flash memory), and other flash memory target data (such as data write buffer memory) pages can be retained even if The power is turned off because there is no need for a backup power circuit even when the power is suddenly turned off. Temporary mapping table, read buffer memory mapping table can choose to discard when the power is off or during the next power-on initialization. In addition to MLC, the disadvantage of NVRAM is cost. For MLC, the disadvantage is that it is slow and limited by the number of writes or erases. The MLC can be obtained from the TLC by allocating a TLC with only a strong programming page. In SEED 200, some of the features of ETL can be implemented in an SRAM.

In TLC flash memory devices, DRAM buffers can also be combined in combination, such as DRAM+SRAM, DRAM+MLC, DRAM+PCRAM or DRAM+MRAM. When using a combination of DRAM buffer memory, such as DRAM+MLC, the functions supported by ETL are managed in DRAM, but some of them are stored in the MLC. Some data in the final DRAM buffer can be discarded, such as temporary data and mapping tables, read buffer memory and mapping table, when the power is off, the data will not move to the MLC. When the power is suddenly turned off, the tables and data that need to be maintained, such as the block erase counter, the page status table, the SMART data acquisition controller, etc., do not need to be stored in the MLC. Copying to MLC is faster than copying to TLC flash memory. In the case of server applications, the temporary data and mapping tables, read buffer memory and mapping tables cannot be discarded; when the power is suddenly turned off, the backup power is used and these areas are stored in the MLC. Another method is to copy these areas to the MLC in order to ensure the benefit of the data in the ETL of the DRAM. A copy of the data in a valid ETL can remain in the MLC when the power is turned off. When the power is turned on, the data in the ETL can be loaded from the MLC into the DRAM. The copy method can be modified by recording subtle differences, which will reduce the amount of copy data, thus reducing the write to the MLC.

It is not necessary for DRAM and MLC, or DRAM and SLC, to use different types of flash memory 196, 342, such as SLC, MLC, TLC, QLC, PLC, 3D NAND, and the like. Conversely, the MLC can be obtained from the TLC by allocating a TLC with only a strong page programming. The SLC can be obtained from MLC, TLC, QLC, PLC, etc. by allocating a part of MLC, TLC, QLC, PLC, etc., which has only strong page programming. For example, an enhanced TLC flash memory can be implemented by using a part of the TLC configuration SLC (robust page), such as using one quarter of the TLC as the SLC (robust page) and prompting the TLC as the TLC (weak page) ). Or configure a part of the TLC as an MLC (robust page) and prompt TLC as a TLC (weak page). In addition, the code erase manager 41 (Fig. 14) may slow page write and block erase time to extend the life of the flash memory cell oxide layer. Reducing page write or block erase time can be applied to enhanced TLC flash memory at the expense of increased endurance to reduce retention time. By using the refresh manager 202, the retention time can be increased. Since the enhanced TLC flash memory includes flash memory SLC (robust page) and TLC (weak page) with different retention times, the refresh manager 202 can track as an SLC (robust page) or TLC (weak page) block. Use and then adjust the corresponding refresh time. Also, MLC can be used as a combination of SLC (robust page) / MLC (weak page), and QLC can be used in combination, for example, SLC (robust page) / QLC (weak page), or SLC / MLC / TLC / QLC random combination. The above functions can also be implemented in SEED 200.

The endurance technique described herein attempts to address the endurance problem of NAND flash memory. There are some non-volatile memory such as MRAM, PCM, RRAM, memristor, NRAM, etc. These memories are using competitive technology to replace NAND flash memory.

The ultra-endurance flash memory drive can be combined with a hard disk drive (HDD) that can be used as a buffer memory for storage. The ultra-endurance flash memory drive has high endurance and is more suitable as a buffer memory. The overall performance of this hybrid device may increase. Another way to ensure that the data in the ET's ETL is copied to the HHD. In the event of a power outage, a valid copy of the data in the ETL can be saved in the HDD. In the case of power-up, these data can be loaded from the HDD into the DRAM. The copy method can be modified by recording subtle differences, which will reduce the amount of copy data, thus reducing the write to the HDD.

The boot image of the operating system can be preloaded into the DRAM buffer to speed up the host boot. Once the boot process is complete, the DRAM buffer is released for subsequent normal operation.

When the host is in sleep or standby mode, the dirty DRAM buffer must be written to the flash memory. When the user's host logs out, the dirty DRAM buffer can be written to the flash memory.

The grouping of data to be written is not limited to one page as a unit. Grouped data can be placed in larger units, such as multiple pages (meta pages) and entire blocks, and so on.

The classification of the data types accessed by the host has been described, and the logical addresses from the host to one or more address ranges have been compared. This comparison may only compare ranges representing a portion of the logical addresses representing the range of addresses. The data type can be identified by parsing the data into a host of a specific format, such as a FAT format or an FDB format. In a sequence, earlier host writes can also check their data format. The FAT file system can be used as an example. FDB/FAT is the metadata of the FAT file system. Other file systems, such as LINUX, Apple OS, and Android, have their own meta-data of different names, but their role is equivalent.

Each block can be divided into multiple page areas. For example, a block can have 16 pages, 4 regions, and 4 regions per region. In alternative embodiments, some of the mappings may be regions rather than separate pages or blocks. Optionally, in a special case, there is one page per area. The zone mode requires fewer map entries than the page mode because each zone is multi-page.

A cluster or zone can be selected from the upper bits of the host's logical-sector address (LSA). All entries in the mapping table can be in the same zone. When the zone number from the LSA matches the zone number of all entries in the mapping table, the LBA from the LSA selects the entry in the mapping table. Mixed or multiple level mapping tables can also be used. Since the LBA range of FAT1/2 is known, the content data type bit "100" in the table can be deleted. A mapping table can have a granularity of one block or page.

For page mapping, block copying for relocation is less frequent because the write order rules for non-SLC flash memory are less violated in page mode than in block mode. This increases the endurance of the flash memory system and improves performance.

The mapping table can be located in an extended address space and can use a virtual address or an illegal address that is larger than the largest address in the user address space. Pages can remain in the host page order or may be remapped to any page location. In another embodiment, such as for data center applications, pagination and temporary files can be considered normal user profiles to simplify controller operation, but at the expense of flash memory endurance. By using a DRAM buffer as an endurance spare swap buffer instead of flash memory, the endurance spare swap area can provide extended over-provisioning. In the case of a compression function already provided by the host, the compression function may choose to turn off. In other embodiments, the controller can use the paging file as user profile to simplify the functionality of the controller.

Many variations of the block diagram are possible. A ROM, such as an EEPROM, can be connected to a portion of the controller and dedicated to the virtual memory processor to store the firmware. This firmware can also be stored in the main flash memory module. The host interface bus can be a Serial Hardware-Interface (SATA) bus, a Peripheral Components Interconnect Express (PCIE) bus, and a compact flash (CF) bus. , or Universal-Serial-Bus (USB), NVME, firmware 1394 bus, Fibre Channel (FC) bus, lightning bus, etc. The internal bus can use standards such as SATA bus, integrated device electronics (IDE) bus, Peripheral Components Interconnect Express (PCIE) bus, CF bus, USB bus, Secure Digital (Secure Digital, SD) bus, Secure Digital (MMC) bus, firmware 1394 bus, FC bus, various Ethernet buses, etc. SCFD can include only SLC or MLC flash memory, or a combination of SLC/MLC flash memory.

Flash memory can be embedded on the motherboard or SSD board or can be on a separate module. Capacitors, buffers, resistors and other components can also be added. The controller can be integrated on the motherboard or on a separate board or module. The flash memory can be integrated with the controller or the original NAND flash memory chip as a separate chip device or plug-in module or motherboard.

Use multi-level controllers, such as in the controller's main control arrangement, compared to the controller's single-level loss balance, bad block management, remapping, buffer memory, voltage management, etc., controllers in SEED may Not complicated. An inexpensive hard drive can be used in the controller. For example, use the 8051 processor as a controller or a virtual storage or a business manager instead of a more powerful processing core, such as the CPU core of the advanced RISC machine ARM-9. For an application, consider a more powerful processor.

Different quantities and layouts of flash memory blocks can be connected to the SEED. Instead of using an LBA storage bus interface or a differential serial packet bus and other serial buses, for example, Synchronous Double-Data-Rate (DDR), ONFI, Toggle NAND, Differential Serial Packet Bus , the traditional flash memory interface and so on.

The mode logic recognizes the state of the pin only when the power is turned on, rather than identifying the state of the dedicated pin. A mix or arrangement of pin states can be used to initiate a mode change or to set an internal register, such as a configuration register. A multi-bus protocol chip can have an additional personality pin to select which serial bus interface to use, or a programmable register-to-hub mode or switch mode.

Service managers, controllers, processes and functions can be implemented in a variety of different ways. Functions and processes can be programmed and executed by a CPU or other processor, as well as by dedicated hardware, firmware, or some combination thereof. Many split features can be replaced. The SEED controller can be hard or include hardware or software or a combination of software and hardware.

By using multiple flash memory channel parity/multi-flash memory channel ECC and splitting the data side into multiple NVM blocks, the reliability of the entire system is greatly improved. For example, a ninth flash memory chip can be used for the flash memory interface. The parity of the other eight flash memory chips is written to the ninth flash memory chip to provide additional protection data to prevent the eighth flash memory chip from encountering a fatal read error. Happening. However, it may be necessary to use a CPU engine with DDR, SDRAM buffer memory to meet complex ECC/parity calculations and the resulting computational energy requirements. Another benefit is that even if the flash memory block or flash memory module is damaged, the data can be recovered, or SEED can initiate a new flash memory module during the "failback recovery" or "automatic reconstruction" process. And recover or rebuild "loss" or "damage" information. The fault tolerance of the entire system has been significantly improved.

The floating gate of the flash memory cell is programmed by the electronics that inject it. The flash memory controls the electron injection during page writes to maintain it at two reference voltage levels. The bit lines of the NAND flash memory structure are connected as a string of 32 cells, each cell being connected to 32 different word lines. After a cell's data is written, any adjacent cell write and read will cause interference to the cell. Interference will either inject the floating gate of the cell or remove the electron from the floating gate of the cell. For a long time it will affect the number of electrons in the floating gate of the unit. Due to the change in the number of electrons in the floating gate, the output voltage level will drift when reading data. If the output voltage level drifts across the reference voltage boundary, the result of the readout will be erroneous.

A wider or narrower data bus and flash memory chip can be replaced, such as a 16-bit or 32-bit data channel. An alternate bus architecture of nested or segmented buses can be used for internal or external SEED. Two or more internal buses can be used in SEED to increase throughput. More complex switch fabrics can replace internal or external buses.

Data striping can occur in a variety of ways, such as parity and error correction code (ECC). Packet reordering can be adjusted based on the data layout used to prevent overlapping internal storage locations from being reordered. SEED can be integrated with other components or it can be a standalone chip.

Additional pipelines or temporary buffers and FIFOs can be added. A separate page buffer can be provided in each channel. You can increase the clock source.

A single packet, a single chip, or a multi-chip package may contain one or more channels of flash memory or SEED or SSD. The invention is not limited to use with SCFD. SCFD can be replaced with any type of non-volatile device with non-volatile flash memory and controllers.

The MLC-based flash memory device can have four MLC flash memory chips with two parallel data channels, but different combinations can be used to form other flash memory modules. For example, four, eight or more data channels, or eight, 16 or more MLC chips. Flash memory devices and by means can be located in chains, branches or arrays. For example, a branch with 4 flash memory devices can be connected as a chain to the SEED. Other sized aggregation or partitioning schemes can be used for different internal storage accesses.

The host can be a desktop PC motherboard or other PC platform, such as a server, a notebook, a netbook, a tablet, a smart phone, a mobile communication device, a personal digital assistant (PDA), a digital camera, a production tool. Or a tester, combination, or other device. The host bus or host device interface can be SATA, PCIE, lightning, SD, USB, NVMe, eMMC, ISSD, or other host bus, while the internal bus connected to the flash memory module can be PATA, using multiple SD/MMC Channel SSD, CF, USB, or other parallel interface. The flash memory module can be a standard PCB or a multi-chip module packaged in TSOP, BGA, LGA, COB, PIP, SIP, CSP, POP, Multi-Chip Package (MCP), or Can include raw NAND flash memory chips, or existing NAND flash memory in separate flash memory chips, other types of NVM flash memory, such as switching, ONFI, eMMC, iSSD, 3D NAND chip. SEED SSD can use eMMC with RAID, and eMMC can also use SEED structure. The internal bus can be shared in whole or in part, or it can be a separate bus. SSD systems can use boards with other components such as LEDs, capacitors, resistors, and more. Power management may be added at one or more levels. SEED SSDs are available with or without VMD drives. The PCIE RAID DRAM buffer memory card can include a VMD driver and SEED of multiple SSD structures.

Directional terms such as, for example, high, low, top, bottom, top, bottom, etc. are relative and variable. Because the system or data is alternating, flipped, etc., these terms are used to describe the device, but not absolute.

NVM flash memory may be in a flash memory module. The flash memory module may have a package controller and a flash memory core in a single chip package. The flash memory core can be integrated into the PCBA, or Directly packaged onto the motherboard to further simplify assembly, reduce manufacturing costs, and reduce overall thickness. Flash memory chips can also be used in other embodiments, including open frame cards.

Using a controller is not just for flash memory storage, but may add additional functionality. For example, a music player can include a controller for playing MP3 data stored in flash memory. Audio jacks may be added to the device to allow the user to plug in the headphones to listen to music. A wireless transmitter, such as a Bluetooth transmitter, can be added to the device to connect to the wireless headset instead of the audio jack used. Infrared emitters, such as IrDA, can also be added. Bluetooth headsets can also be added to wireless mice, PDAs, keyboards, printers, digital cameras, MP3 players, or other wireless devices. The Bluetooth transceiver can replace the connector as the primary connector. Bluetooth adapter devices can have connectors, RF (radio frequency) transceivers, baseband controllers, antennas, flash memory (EEPROM), voltage regulators, transistors, LEDs (light-emitting diodes), resistors, capacitors and inductors. These components can be mounted on a printed circuit board (PCB) before being packaged in a plastic or metal enclosure.

The size of the data, such as sectors, pages, and blocks may change. A sector can have 512 bytes, a page can have 16 sectors, and a block can have 128 pages. There are many examples.

The write data in the ETL can be packaged and recorded one by one by the flash memory controller to the data write buffer memory as a page unit. The size of the data packet from the host can be large, for example, larger than the metapage unit, or small, such as smaller than the size of the sector. Add a title to show the relationship of the data to the host LBA. A separate package table maps the host LBA to the data page of the data write buffer memory and the offset position of the header. The capacity of the data write buffer memory can be greater than the size of more than two metapage units. When the data write buffer memory is full or the time is up, the selected metapage unit will move from the data write buffer memory to the flash memory. The encapsulation table maps the host LBA to the data of the metapage unit of the data write buffer memory and the offset position of the header. In case the old data of the host is overwritten, if the package data is still in the data write buffer memory, the old data can be discarded by moving the package data package and adding the new update data to the data write buffer memory, and Update the package table. Otherwise, if the package data is in the flash memory, the new data and the old data are compared, and an incremental data is generated to show the difference. Incremental data and headers are appended to the data write buffer memory. The header also includes the location of the previous old data. The encapsulation table will map the LBA to the incremental data location.

The prior art of part of the present invention may contain prior art messages or inventive environments relating to this problem, rather than describing other known techniques. Therefore, the technology included in the prior art section is not a prior art recognized by the applicant.

Any of the methods or processes described herein are either mechanically implemented or computer implemented and are intended to be performed by a machine, computer or other device, rather than by a separate person without machine assistance. The resulting tangible results may include reports or other machine generated display results, the results being displayed on a display device, which may be computer displays, projection devices, audio producing devices, and related media devices, and may include mechanically generated hard copy printouts. . Computer control of other machines is another tangible result.

Any advantages and benefits may not apply to all embodiments of the invention. When the “method” is quoted in the scope of the patent application, the applicant intends to make the scope of the patent application fall within the scope of paragraph 6 of Article 112 of the US Patent Law. Usually one or more tags appear before the "method". One or more words that precede the "method" are a label that is used to reference the scope of the patent application and is not intended to convey structural limitations. The scope of the patent application of this method is intended to cover not only the functions described above but also its equivalent structure, but also to cover the equivalent structure. For example, although nails and screws have different structures, they are equivalent structures because they can perform fixed functions. The scope of the patent application does not use the "method". It is not intended to fall within the scope of paragraph 6 of Article 112 of the US Patent Law. The signal usually refers to an electronic signal, but it may also be an optical signal that can be transmitted by optical fiber.

The embodiments of the invention described above are for the purpose of illustrating and describing the invention. It is not intended to be exhaustive or to limit the specific forms disclosed. Many modifications and variations are possible in light of the above teachings. The scope of the invention is not limited by the detailed description, but is determined by the scope of the appended claims.

100. . . VMD drive

176. . . backup power

178. . . Operating system core

180. . . VMD application

181. . . SSD internal cleanup

182. . . User application

184. . . Operating system settings

186. . . Configuration settings

188. . . Virtual disk

190. . . High-level file filter driver

192. . . SEED controller

194. . . SSD DRAM buffer

195. . . Power backup

196. . . NAND flash memory

200. . . Super strong endurance device

240. . . Encryption and decryption engine

242. . . Compression decompression engine

266. . . File system driver

268. . . Low-level file filter driver

270. . . Volume management

300. . . Host

301. . . Buffer memory controller

303. . . SEED SSD

305. . . Power management

307. . . Power backup

309. . . Internal storage controller

311. . . switch

Claims (25)

A virtual memory device driver (VMD) that is executed on a host and includes:
a file type identifier for generating a data type for a host write received by the virtual memory device driver;
a data splitting manager, configured to classify data written by the host according to the type of data identified by the data type identifier;
The data is written into the buffer memory for storing the data of the user data type;
Metadata buffer memory for storing metadata of a metadata type;
a page buffer memory for storing a host write data of a paging file data type;
Temporary buffer memory for storing data of a temporary data type host;
a user grouping engine, configured to classify user data stored in the data write buffer memory into a user metapage;
a metadata packet engine for classifying metadata stored in the data write buffer memory into a meta page of the metadata;
An output buffer for sending the grouped meta page and data type messages to the flash memory drive system for storage. The virtual memory device driver of claim 1, further comprising:
A high-level file filter driver for execution on the host and intercepting high-level host writes to flash memory drives;
An encryption engine for connecting to receive high-level host writes intercepted by the high-level file filter driver and generating encrypted data;
a compression engine for connecting to receive high-level host writes intercepted by the high-level file filter drive and generating compressed data;
Wherein, the compressed data and the encrypted data are sent to a file system driver executed on the host;
a low-level file filter driver for executing on the host, intercepting a lower-level file system host write to the flash memory drive, and sending the lower-level file system host to write data to the data split manager for classification The host writes the data. The virtual memory device driver of claim 1, further comprising:
The virtual disk drive is configured to store data in the temporary buffer memory, data in the browser buffer memory, or data in the application buffer memory into the virtual disk, and the virtual disk is stored in the host dynamic random memory. In-body dynamic random access memory (DRAM). The virtual memory device driver of claim 1, further comprising:
The first data reading buffer memory is used for storing frequently accessed data read by the host, and recently accessed data;
a second data read buffer memory for storing frequently accessed, and non-nearestally accessed data read by the host;
a third data read buffer memory for storing non-frequently accessed, and recently accessed data read by the host;
The fourth data reading buffer memory is used for storing non-frequently accessed and non-recently accessed data read by the host;
a first split data manager for dividing data received from the flash memory drive system into recently accessed data and non-nearestally accessed data;
The second split data manager is configured to split the data received from the flash memory drive system into frequently accessed data and non-frequently accessed data. The virtual memory device driver of claim 1, wherein the flash memory drive system is a super enhanced endurance device (SEED), the super enhanced endurance device comprising:
Hard Disk Solid State Drive (SSD) Durable Translation Layer (ETL) for execution in Dynamic Random Access Memory (DRAM) and controlled by a controller that uses the ETL layer to provide temporary storage to reduce fast Flash memory wear;
a dynamic random access memory (SSD DRAM) buffer of a hard disk solid state drive machine for storing packet metadata;
a dynamic random access memory (DRAM) interface for accessing a dynamic random access memory (SSD DRAM) buffer of a hard disk solid state drive;
An error correction code (ECC) manager for generating an error correction code that is included in a packet element page written in the flash memory;
Bad page manager for tracking bad pages in flash memory;
Wear equalizer for allocating new data to empty blocks in flash memory with low erase counts;
A flash memory interface for erasing and writing a block in a flash memory, the block being a multiple of a page size;
Flash memory for storing packet metapages in a dynamic random access memory (SSD DRAM) buffer from a hard disk solid state drive. A virtual memory device driver (VMD) for execution on a host, comprising:
a data type allocator for generating a data type for a host write received by the virtual memory device driver;
a task priority allocator for assigning priorities to tasks, including writing a host write data according to a data type, the priority being a function from a data type of the data type allocator;
a target allocator for classifying the data written by the host according to the type of data generated by the data type allocator;
Data write buffer memory for storing host write data with user data type;
a virtual disk drive for storing a host write data having a temporary data type into a dynamic random access memory (DRAM) of the host;
Data read buffer memory for storing host read data;
a packet engine for grouping data stored in the data write buffer memory into a meta page;
The grouping engine is cancelled, and the data stored in the metapage is ungrouped into the ungrouped data stored in the data read buffer memory;
The metadata is sent from the packet engine to the volume manager for transmission to the flash memory, and the meta-page stored in the flash memory is received by canceling the packet engine;
Power monitor for detecting power failures;
The refresh manager is configured to refresh the data stored in the dynamic random access memory (DRAM) of the host into the dynamic random access memory (SSD DRAM) of the hard disk solid state drive when the power is lost, and then refresh to Flash memory in the flash memory drive system;
The recovery manager is configured to load the refresh data obtained from the flash memory of the flash memory drive system when the power is restored, and then refresh to the dynamic random access memory (DRAM) of the host. The virtual memory device driver of claim 6, further comprising:
a service manager for recording the start and completion of writing to flash memory data;
The recovery manager is used to read events recorded by the business manager to undo or redo the data written to the flash memory after the power is restored. The virtual memory device driver of claim 6, further comprising:
Configuration Settings Manager to disable settings to improve flash memory endurance, including at least one drive index, search index, defragmentation, host sleep state, prefetch, super data fetch, write buffer memory, write buffer memory The body buffer is refreshed. A method of refreshing flash memory, comprising:
Get the current date;
The current block in the block list of the flash memory:
(a) reading a block status table for the erase count of the current block and the write date to the current block, the date indicating the date the current block was last written;
Calculating the first time delay as the difference between the write date and the current date;
Taking the first time delay as a retention time;
When the first time delay exceeds the retention time, moving all valid pages in the current block to a blank page in a spare block of a dynamic random access memory (DRAM);
When a spare block in a dynamic random access memory (DRAM) is full, moving data from a spare block of a dynamic random access memory (DRAM) to a spare block in the flash memory;
Erase the current block;
Another block is selected as the current block in the block list of the flash memory, and is repeated from (a) until all the blocks in the block list are processed, and thus the flash memory block is refreshed. A method of flash memory refreshing, comprising:
Get the current date;
For the current page in the current block in the block list of the flash memory:
(a) reading a block status table for the erase count of the current block;
(b) reading a page status table for the date of writing of the current page, the date indicating the date when the previous page was last written;
Calculating the first time delay as the difference between the write date and the current date;
Taking the first time delay as a retention time;
When the first time delay exceeds the retention time, moving the current page in the current block to a blank page in a spare block of a dynamic random access memory (DRAM);
When a spare block in a dynamic random access memory (DRAM) is full, moving data from a spare block of a dynamic random access memory (DRAM) to a spare block in the flash memory;
Select another page in the current block and repeat from (b) until all pages in the current block have been processed;
Select another block as the current block in the block list of the flash memory, and repeat from (a) until all the blocks in the block list are processed, and the flash memory page is refreshed. The method of flash memory refreshing as described in claim 10, further comprising:
This retention time is calculated as a function of the erase count for the current block. A super-enhanced endurance device (SEED) hard disk solid state drive (SSD) durable conversion layer (ETL) method for enhancing the endurance of a flash memory having a low specified erase cycle life, including:
Creating a durable conversion layer (ETL) in a dynamic random access memory (DRAM) buffer controlled by the controller and using the durable conversion layer (ETL) to provide temporary storage space to reduce the flash memory Wear and tear
Creating an alternate swap area in a dynamic random access memory (DRAM) buffer;
Using a spare swap area operation controller in the dynamic random access memory (DRAM) buffer to merge valid data in flash memory with new data to generate combined data;
When overwriting all pages or partial pages in an existing block in the flash memory, the new data is written to a spare block of a dynamic random access memory (DRAM) buffer associated with an existing block in the flash memory. For different blocks in the flash memory, when additional new data requires a spare block, a combination of spare blocks with new data and data from existing blocks of the flash memory is written to the flash memory for backup. In the block, all the pages in the existing block in the flash memory are marked as the garbage page;
When the power supply is lost, the backup power supply is used to provide power to the dynamic random access memory (DRAM) buffer and the flash memory and the controller, and the backup power supply has sufficient capacity to enable the controller to convert the durable conversion layer ( ETL) Backs up the required data to the flash memory, whereby the controller uses a dynamic random access memory (DRAM) buffer instead of flash memory to perform the alternate swap function. A Super Enhanced Endurance Equipment (SEED) that includes:
a host interface for receiving host read and host writes from the host;
Super Enhanced Endurance Equipment (SEED) Dynamic Random Access Memory (DRAM) buffer for storing data;
a controller for controlling access to the flash memory and the dynamic random access memory (DRAM) buffer in response to host read and host writes received by the host interface, the controller writing the host data to the dynamic random Access memory (DRAM) buffer;
Super Enhanced Endurance Equipment (SEED) Hard Disk Solid State Drive (SSD) Durable Translation Layer (ETL), implemented in this Dynamic Random Access Memory (DRAM) buffer, and controlled by the use of a Durable Translation Layer (ETL) Control to provide temporary storage to reduce wear on flash memory;
Data write buffer memory, the data write buffer memory is stored in a dynamic random access memory (DRAM) buffer, and is managed by the controller;
Flash memory interface for erasing blocks and writing to flash memory pages, where the block is a multiple of the page size;
Flash memory for storing metadata from packets of a hard disk solid state drive dynamic random access memory (SSD DRAM) buffer;
When the power supply is lost, the backup power supply is used to supply power to the dynamic random access memory (DRAM) buffer, the flash memory, and the controller, and the backup power supply has sufficient capacity so that the controller will be in a durable conversion The data required in the layer (ETL) is backed up to the flash memory. The super-enhanced endurance device according to claim 13 of the patent application, further comprising:
An alternate swap block in a dynamic random access memory (DRAM) buffer;
a controller that uses the alternate swap area in the dynamic random access memory (DRAM) buffer to merge valid data in the flash memory with new data to generate combined data, when the overlay write flashes When all pages or partial pages in the existing block in the memory are written, the new data is written to the spare block of the dynamic random access memory (DRAM) buffer associated with the existing block in the flash memory, and the flash memory is Different blocks in the block, when additional new data requires a spare block, a combination of spare blocks with new data and data from existing blocks of the flash memory is written into the spare block in the flash memory, which will be fast The status of the tag page of all pages in the existing block in flash memory is used as a junk page. The super-enhanced endurance device according to claim 13 of the patent application, further comprising:
Bad page manager for tracking bad pages in flash memory;
The bad page manager is used to perform the following operations, including:
When the erase block in the flash memory is erased, in the erase count table, an erase count is added for the erase block;
Reading a page status table for erasing a block, the page status table having a plurality of page entries, each page entry storing a state of a page in the erase block, the state comprising indicating a bad page or a good page;
Each page in the block should be erased, and the page entry of the page is read from the page state table;
When the page status obtained from the page status table is bad, the next page is processed;
When the page status obtained from the page status table is good, continue processing the unerased bits in the page;
When the number of unerased bits exceeds the first threshold, the page state is modified to indicate in the page entry that the page is a bad page, and the bad page count is incremented;
When the number of the unerased bits is between the first threshold and the second threshold, and the page state of the page state table indicates that an error-correction code (ECC) protection is required, processing the next page;
When the number of the unerased bits is between the first threshold and the second threshold, and the page state of the page state table indicates that no error correction code (ECC) protection is required, changing the state of the page in the page entry, By marking the page state of the page as a protection page to indicate that an error correction code (ECC) protection is required, an error correction code (ECC) is added to protect the page count;
When the number of the unerased bits exceeds the third threshold, indicating that the erase block is a bad block, by marking the page state of the page as a bad page, no new data is written to the erase block;
The erase block is identified by calculating the bad page in the erase block, and a bad page is allowed in the good block to extend the endurance of the flash memory. The super-enhanced endurance device of claim 15, wherein the method further comprises:
An error correction code (ECC) generator for generating an error correction code (ECC) such that each unit of data has more bits, the data being stored in a flash memory having a lower reliability page;
Low Density Parity Check (LDPC) generator, triggered by an Error Correction Code (ECC) Manager, for low-density parity check (LDPC) for high-reliability data in flash memory The code, therefore, the error correction code (ECC) code is dynamic. A virtual memory device driver for execution on a host, comprising:
Host Durable Translation Layer (ETL) for execution on the host to increase flash memory endurance, the flash memory has a low erase cycle life;
a host dynamic random access memory (DRAM) buffer, located on the host, controlled by the host controller, using the host durable conversion layer (ETL) to provide temporary storage on the host to reduce wear on the flash memory;
Super Enhanced Endurance Equipment (SEED) on a hard disk solid state drive (SSD) for increasing the endurance of flash memory with low erase cycle life;
Super Enhanced Endurance Equipment (SEED) Durable Conversion Layer (ETL) in the Super Enhanced Endurance Device Hard Disk Solid State Drive (SEED DRAM) buffer, controlled by Super Enhanced Endurance Equipment (SEED) controller, this super enhanced endurance The Equipment Durable Conversion Layer (SEED ETL) provides temporary storage to reduce flash memory wear. The virtual memory device driver of claim 17, further comprising:
A refresh manager for refreshing data in the host's Durable Translation Layer (ETL) stored in the host DRAM buffer to the Super Enhanced Endurance Device Dynamic Random Access Memory (SEED DRAM) buffer for super-enhanced endurance devices In the layer (SEED ETL), and when the power supply is lost, it is refreshed into the flash memory of the flash memory drive system;
The recovery manager is configured to reload the refresh data obtained from the flash memory of the flash memory drive system and the super-enhanced device dynamic random access memory (SEED DRAM) buffer when the power is restored, and refreshed to Host Dynamic Random Access Memory (DRAM) buffer in the Host Durable Translation Layer (ETL). The virtual memory device driver of claim 17, further comprising:
A system service manager for creating logs to track ongoing write activity to a hard disk solid state drive (SSD) and periodically establish checkpoints to remove fully completed services;
A hard disk solid state drive (SSD) service manager for creating logs to track persistent write activity to flash memory and periodically establishing checkpoints to remove fully completed services. The virtual memory device driver of claim 17, further comprising an internal clearing process on the host, comprising:
Get the date the file was last accessed;
Use the current date to calculate the delay time since the last file access date;
When the delay time exceeds the time threshold and the automatic cleaning setting is enabled, the file, the log, and the paging are deleted, and the file has a temporary file type;
Find duplicate files and delete the duplicate file;
Repeat the other files on the host. A virtual memory device driver executing on a host, comprising:
An encryption engine for coupling to receive intercepted high-level host writes and generating encrypted data;
a compression engine for coupling to receive the intercepted high-level secondary host to write data and generate compressed data;
Data write buffer memory for storing data written by the host;
Data read buffer memory for storing host read data;
a grouping engine for dividing the data stored in the data write buffer memory into a metapage;
Ungrouping the data for ungrouping the data stored in the metapage into stored data that can be stored in the data read buffer memory;
The meta page is sent from the packet engine to the volume manager for transfer to the flash memory, and the meta page stored in the flash memory is received by canceling the packet engine;
Power monitor for detecting power failures;
a host dynamic random access memory (DRAM) buffer for storing a host durable conversion layer (ETL);
The refresh manager is used to flush data in the host's Durable Translation Layer (ETL) stored in the host dynamic random access memory (DRAM) buffer to the hard disk solid state drive (SSD) when the power supply is lost. Translation layer (ETL) dynamic random access memory (DRAM), and then stored in the flash memory of the hard disk solid state drive (SSD) system;
Recovery manager for loading refresh data obtained from the flash memory of the hard disk solid state drive (SSD) system when the power is restored, and then refreshing the host to the host dynamic random access memory (DRAM) buffer In the durable conversion layer (ETL). The virtual memory device driver of claim 21, further comprising:
a service manager for recording events that start and complete writing to flash memory data;
The recovery manager is configured to read an event recorded by the service manager to undo or redo the data written to the flash memory after the power is restored. An endurance flash memory file system comprising:
A high-level file filter driver that is executed on the host and intercepts high-level host writes to the flash memory drive;
An encryption and decryption engine for coupling to receive high-level host write data intercepted by a high-level file filter driver, and generating encrypted data and decrypted data;
a compression and decompression engine for coupling to receive high-level secondary host write data intercepted by a high-level file filter driver, and generating compressed data and decompressing data;
The compressed data and the encrypted data are sent to a File System Driver (FSD) executed on the host;
a low-level file filter driver for execution on the host and intercepting writes to low-level file system hosts of the flash memory drive;
Data write buffer memory for storing data written by the host;
Data read buffer memory for storing host read data;
a grouping engine for dividing the data stored in the data write buffer memory into metapage pages;
Ungrouping the data for ungrouping the data stored in the metapage into stored data that can be stored in the data read buffer memory;
The meta page is sent from the packet engine to the volume manager for transfer to the flash memory, and the meta page stored in the flash memory is received by canceling the packet engine;
a file priority label classifier for generating a data type for a host;
a task policy allocator for assigning priorities to tasks, including writing data to a host according to a data type, the priority being a function of a data type from a file priority label classifier;
a performance adjuster that adjusts the priority of the task;
a target classifier, configured to classify the host write data according to the data type generated by the file priority label classifier;
a business system for recording events that start and complete writing to flash memory data;
The refresh manager is used to refresh the data stored in the host dynamic random access memory (DRAM) to the hard disk solid state drive dynamic random access memory (SSD DRAM) when the power is lost, and then to the fast Flash memory in a flash memory drive system;
a recovery manager for acquiring the refreshed data from the flash memory in the flash memory drive system, and then refreshing into the host dynamic random access memory (DRAM) when the power is restored;
A disk miniport driver that manages the specific protocol functions of the flash memory drive system. A super-enhanced endurance device comprising:
a host interface for receiving host read and host writes from the host;
Dynamic Random Access Memory (DRAM) buffer for storing data;
a controller for controlling access to the flash memory and the dynamic random access memory (DRAM) buffer in response to host read and host writes received by the host interface, the controller writing the host data to the dynamic random Access memory (DRAM) buffer;
a data write buffer memory stored in a dynamic random access memory (DRAM) buffer for managing the controller, the controller managing non-transitory data;
An enhanced flash memory portion of the flash memory for configuring for use as a robust page, wherein the reserved portion of the flash memory is configured as a weak page;
Programmable erase manager for controlling page write or block erase time of flash memory to enhance endurance and reduce retention time;
A refresh manager that controls the refresh time that remains in the enhanced flash memory portion. The super-enhanced endurance device of claim 24, further comprising:
A controller for controlling access to the enhanced flash memory portion to control the page write or block erase time to enhance the endurance of the flash memory.