HK1220271B - Green nand ssd application and driver - Google Patents

Description

Green Energy and Non-Solid State Drive Applications and Drivers

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to U.S. patent application Ser. No. 13/788,989, filed on March 7, 2013, and entitled "Endurance and Retention Flash Controller with Programmable Binary-Levels-Per-Cell Bits Identifying Pages or Blocks as Having Triple, Multi, or Single-Level Flash-Memory Cells"; and U.S. patent application Ser. No. 13/730,797, filed on December 28, 2012, and entitled "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." No. 13/540,569, filed on July 2, 2012, for “Super-Endurance Solid-State Drive with Endurance Translation Layer (ETL) and Diversion of Temp Files for Reduced Flash Wear”; No. 12/141,879, filed on June 18, 2008, for “High Performance and Endurance Non-volatile Memory Based Storage Systems”; and No. 13/927,435, filed on June 26, 2013, for “Green NAND Device (GND) Driver With DRAM Data Persistence For Enhanced FLASH Endurance and Performance.” Performance), the disclosures of each of which are hereby incorporated by reference in their entirety, and which are all owned by the same assignee.

Technical Field

The present invention relates generally to flash memory and, more particularly, to methods and apparatus for improving the endurance of flash memory.

Background Art

Hard disks with rotating platters are increasingly being replaced by more reliable solid-state drives (SSDs) that utilize semiconductor flash memory. NAND flash memory uses electrically erasable programmable read-only memory (EEPROM) cells that store charge on a floating gate. Cells are typically programmed using an avalanche current and then erased using quantum mechanical tunneling through a thin oxide layer. Unfortunately, during the programming or erasing process, some electrons may become trapped in the oxide layer. Assuming a constant programming voltage, these trapped electrons reduce the charge stored in the cell during subsequent programming cycles. The programming voltage is often increased to compensate for the trapped electrons.

As the density and size of flash memory have increased, the size of the cells, along with their reliability and lifespan, have all decreased. Flash memory is guaranteed to withstand approximately 100,000 program-erase cycles, which is considered a very long lifespan under normal read and write conditions. But smaller flash cells already experience disturbingly high wear rates. Newer secondary cell flash memory has an endurance of less than 10,000 program-erase (P/E) cycles, while triple-level cells (TLC) have an endurance of approximately 500 to approximately 1500 P/E cycles. If current trends continue, future flash memory may only allow for 300 program-erase cycles. Such low endurance could severely limit the possible uses of flash memory, including its application in solid-state drives (SSDs). High-endurance SSD drives and methods for enhancing endurance are needed.

Summary of the Invention

Embodiments of the present invention provide a device and method. The device includes a Green Energy Non-Solid State Drive (GNSD) driver coupled to a host DRAM, the device having a storage manager, a GNSD driver coupled to an upper filter, a data packet engine coupled to the host DRAM, a data unpacking engine coupled to the host DRAM, a power manager coupled to the storage manager, and a refresh/recovery manager coupled to the storage manager. The GNSD driver is coupled to a GNSD application, and the host DRAM is coupled to a non-volatile memory. In an embodiment, the GNSD driver further includes a compression/decompression engine coupled to a file system filter, an encryption/decryption engine coupled to the file system filter, or an advanced error correction code engine coupled to the file system filter. In embodiments employing an encryption/decompression engine, the encryption/decryption engine is configured to perform encryption according to one of a Data Encryption Standard or an Advanced Encryption Standard.

An embodiment of the present invention further includes a GNSD driver coupled to a host DRAM, comprising a data grouper; a DRAM data write buffer coupled to the data grouper; a data degrouper; and a DRAM data read buffer coupled to the data degrouper. The data grouper and the data degrouper are coupled to an upper filter and a lower filter. The GNSD driver is coupled to a GNSD application. The DRAM is coupled to a non-volatile memory. In an embodiment, the GNSD driver further includes a compression/decompression engine coupled to the lower filter; a deduplication engine coupled to the lower filter; an encryption/decryption engine coupled to the lower filter; or an advanced error correction code engine coupled to the lower filter. The GNSD driver may also include an intelligent data monitor coupled to a super-enhanced endurance device (SSD); and a security engine coupled to the host. The advanced error correction code engine employs either pattern-based coding or algebraic coding. In one embodiment, the advanced error correction code engine employs a low-density parity check code based on pattern coding. The data grouper and the ungrouper are each coupled to a metapage grouper for user data; a metapage grouper for the FDB; and a metapage grouper for page file pages.

Embodiments also provide a GNSD application coupled to a host DRAM, including an SSD internal clear module coupled to a GNSD driver; a DRAM allocation module coupled to a GNSD driver; a driver installation module coupled to a GNSD driver; or a cache mode on/off switch coupled to a GNSD driver.

An embodiment provides a computer system host having a GNSD driver coupled to data grouping and data degrouping functions within the computer system host; and a GNSD application coupled to the GNSD driver and the computer system host. In this embodiment, the GNSD driver's data grouping and data degrouping functions are coupled to upper and lower filters within the computer system host, and the computer system host is coupled to a non-volatile memory device. The embodiment also includes configuration and registry settings coupled to an operating system within the computer system host.

An embodiment of the present invention includes a method of operating a GNSD driver and a GNSD application coupled to a host DRAM, the method comprising coupling configuration and registration settings to the host and the GNSD application; coupling a GNSD driver data packet engine to the host DRAM; coupling a GNSD driver de-packet engine to the host DRAM; coupling a GNSD driver power manager to the host; coupling a GNSD driver memory manager to the host; coupling a GNSD driver refresh/recovery manager to the DRAM; coupling the GNSD driver data packet engine and de-packet engine to an upper filter and a lower filter; and coupling the DRAM to a Super Enhanced Endurance Device (SEED) SSD. The method also includes disabling drive indexing, disabling drive search indexing, reducing the size of a page file, disabling system resume, disabling hibernation, disabling prefetching, reducing the size of the recycle bin, disabling a disk defragmenter, reducing logging; and disabling a performance monitor, disabling write caching, or disabling write cache buffer flushing. The SEED SSD endurance is increased to exceed a specified value and write amplification is reduced to less than a specified value.

In one embodiment, the method further includes synchronizing a weak table to a weak table of a SEED SSD block; generating advanced error correction code (ECC) data for page data in the weak table, providing the generated advanced ECC data; storing the generated advanced ECC data in a cache area in a host DRAM or a remaining area of the SEED SSD; and writing the page indicated by the weak table. The method may continue by an ECC engine reading the data in the page and, if the SEED SSD local ECC engine determines that the data in the page is erroneous, the ECC engine reading the generated advanced ECC from the weak table to identify the erroneous page data; and correcting the erroneous page data using the advanced ECC data generated by the ECC engine.

In one embodiment, the method further includes grouping user data into a first metapage, grouping system FDB into a second metapage, grouping page file pages into a third metapage, and storing the first, second, and third metapages in a storage volume of a SEED SSD. In one embodiment, the method includes providing an endurance translation layer (ETL) to control access to flash memory in the SEED SSD and access to a DRAM buffer, checking a flash memory block via the ETL and identifying the block as a bad block via the ETL if all error bits exceed a preselected high level threshold, or entering the block into a weak list via the ETL if all error bits exceed a preselected low level threshold, and synchronizing the weak list of a GNSD driver coupled to the DRAM.

Embodiments of the present invention also include a method for increasing the endurance of a non-volatile flash memory, comprising coupling a GNSD driver having an ECC engine to a host DRAM; coupling a seed SSD to the host DRAM; using the host DRAM to generate advanced ECC for selected data in the seed SSD; and correcting erroneous data in the seed SSD using the advanced ECC. The method of the embodiment also includes synchronizing a weak table of a seed SSD block weak table; generating advanced error correction code (ECC) data for page data in the weak table, providing the generated advanced ECC data; storing the generated advanced ECC data in a cache area of the DRAM or a remaining area of the seed SSD; and writing the page data indicated by the weak table. An embodiment of the method for increasing endurance of claim 18 includes reading data in a page; if the seed SSD local ECC engine determines that the data in the page is erroneous, reading the advanced ECC data generated in the weak table belonging to the page, and correcting the erroneous data using the advanced ECC data generated in the page.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is generally illustrated by reference to the accompanying drawings, in which:

FIG1 is a block diagram of a computer system according to the teachings of the present invention;

FIG2 is a block diagram of a host computer having a green non-solid state hard disk drive (GNSD) according to the teachings of the present invention;

3A is a functional block diagram of a computer system having a GNSD that implements a host read function according to the teachings of the present invention;

3B is a functional block diagram of a GNSD implementing a read operation from a Super Enhanced Endurance Device (SEED) solid state drive according to the teachings of the present invention;

3C is a functional block diagram of a computer system having a GNSD that implements host read functionality in power-down mode according to the teachings of the present invention;

4 is a functional block diagram of a computer system having a GNSD that implements host write functionality in power-down mode according to the teachings of the present invention;

FIG5 is a high-level block diagram illustrating a DES/AES encryption process according to the teachings of the present invention;

FIG6 is a high-level block diagram illustrating a data compression/decompression process according to the teachings of the present invention;

FIG7 is a block diagram illustrating the interaction between the GNSD driver and the SEED during operation of an advanced error correction code according to the teachings of the present invention;

FIG8 is a block diagram illustrating a GNSD implementing operations for an input/output (I/O) request packet (IRP) in accordance with the teachings of the present invention;

FIG9 is a block diagram illustrating a GNSD IRP read process according to the teachings of the present invention;

FIG10 is a block diagram illustrating a GNSD IRP write process according to the teachings of the present invention;

FIG11 is a block diagram illustrating the operation of a GNSD refresh block according to the teachings of the present invention;

FIG12 is a block diagram illustrating SSD I/O control functionality according to the teachings of the present invention;

13 is a block diagram illustrating SSD I/O control functionality relative to a GNSD driver and a GNSD application in accordance with the teachings of the present invention;

FIG14 is an example of SSD I/O control encoding according to the teachings of the present invention;

FIG15 is a block flow diagram illustrating a user-initiated read request (“read send”) in accordance with the teachings of the present invention;

FIG16 is a block flow diagram illustrating a user-initiated write request (“Write Send”) in accordance with the teachings of the present invention;

FIG17 is an exemplary table showing a write-send meta-table according to the teachings of the present invention;

FIG18 is a block flow diagram illustrating TRIM functionality commands according to the teachings of the present invention;

FIG19 is a diagram showing a durable conversion layer according to the teachings of the present invention;

Several embodiments are described in detail with reference to the accompanying drawings. Additional embodiments, features, and/or advantages will appear in the subsequent description or may be learned by practicing the invention. In the drawings, which are not to scale, like reference numerals refer to like features throughout the description. The following description is not intended to be limiting but is provided solely for the purpose of illustrating the general principles of the invention.

Specific embodiments

A green and non-solid state drive (GNSD) application and a GNSD driver executing on a host block, combine, or cache to DRAM before they write to flash memory, thereby reducing the frequency of writes to flash memory. Green or low-energy flash devices use low-endurance NAND flash memory. The GNSD application and GNSD driver on the host create and manage multiple caches on the host and SSD, which may have low-endurance flash memory. Low-endurance flash memory includes, but is not limited to, triple-level cell (TLC) NAND flash memory. The GNSD application and GNSD driver operate with the SSD and the host to convert the SSD into a super-enhanced endurance flash drive, or super-enhanced endurance device (SEED) SSD. The examples herein may be applied to Windows operating systems from Microsoft, Redmond, WA USA, but similar examples with appropriate modifications may be applied to other operating systems.

1 and 2 , a computer system 5 includes a host 300 and a SEED SSD 200. The host 300 includes a GNSD driver 100, which can be coupled to a GNSD application 180. The GNSD driver 100 has a memory manager 106 and a refresh/restore manager 107. In addition, the GNSD driver 100 may include an encryption/decryption engine 240, an advanced error correction code (ECC) engine 241, a compression/decompression engine 242, a deduplication engine 243, and a security engine 244.

"Memory Manager" 106 can provide various functions, such as "DRAM Clear," which resets the DRAM cache area controlled by the GNSD driver. A "Trim Command" is issued to the OS of SSD 200 to actually remove data from the flash memory. For the GNSD driver, if data is cached in DRAM 333, this command can be used to remove the data from DRAM 333. "Format Stealer" allows format commands to pass through to SSD 200 without any interference. "Smart Refresh" can refresh data from DRAM 333 to SSD 200, depending on the user's selection of "Forever" (e.g., not using auto-refresh), 30 seconds, 1 minute, or 5 minutes. The default is to not use auto-refresh to maximize DRAM 333 efficiency. In addition, when DRAM cache usage reaches a predetermined level, selected DRAM cache data (e.g., cold data) can be refreshed to SSD 200. When auto-refresh is selected, a predetermined watermark can be set for the refreshed DRAM cache data and the data still remaining in DRAM. The DRAM cache is only overwritten when the DRAM cache area is full.

The "Flush/Restore Manager" 107 provides a method for quickly refreshing DRAM data to the SSD 200 when the power is turned off or lost, and for restoring the refreshed data from the SSD 200 to the DRAM when the power is restored. It can also refresh the DRAM 333 to the SSD 200 when the DRAM cache reaches a predetermined level mark. If the host is not active on the SSD 200, the GNSD driver 100 can write the DRAM cache data to the SSD 200 based on the user's selection. When the power is turned off or lost, the dirty 50 in the DRAM cache, such as the SSD DRAM 194, is

The data will be saved as an image file to the SEED SSD. This method is much faster than all standard operations. When power is restored, the image file can be read out and reloaded as before.

The function 288 of the GNSD driver 100 is provided to improve the endurance and performance of the SEED SSD by combining the configuration and the operating system settings. The function 288 of the GNSD driver 100 is provided to improve the endurance and performance of the SEED SSD by combining the configuration and the operating system settings.

Disable drive indexing: SSD 200 functions fast, about 0.1 milliseconds, so such indexing is not needed.

Disable drive search indexing: Disabling search indexing can help increase the performance and lifespan of your SSD. Disabling this option prevents the Windows operating system from attempting to track every file search. The downside is that SSD searches may be slower.

Reduce the size of the page file: Leave the page file on the SSD but set it to a fixed, "reasonable" size. The operating system (OS) will allocate a page file that is the same size as the installed DRAM 333. For large DRAM machines, the OS will quickly consume SSD space. How well the OS's page file functions on the SSD depends on the amount of DRAM memory in the system. It can be set to, for example, 1 or 2 GB. When setting the page file value, its parameters can be set to the same, fixed, minimum, and maximum values, which reflect the balance between the available space on the SSD 200 and how much DRAM 333 is available and how much is frequently used.

Disabling System Restore: The System Restore feature allows software, driver, and other updates to be installed and re-run. Disabling this feature can free up between hundreds of megabytes and several gigabytes of storage. The amount of disk space available for System Restore is reduced, or even turned off entirely, with the risk of not being able to automatically recover from problems caused by system changes. However, if this feature is disabled, users can use other forms of backup, such as creating disk image backups.

Disabling Hibernation: By disabling the Windows operating system's hibernation feature, you free up space on the SSD 200 to match the amount of DRAM 333. By default, the size of the hibernation file (Hiberfil.sys) is the same as the amount of DRAM 333 installed on the computer. Of course, disabling the hibernation feature prevents users from using this power-saving mode and from benefiting from faster boot and shutdown times. However, hibernation mode offers no real benefit to the SSD 200 due to its fast 10-20 second SSD boot time, which, in some cases, is equivalent to hibernation. Nevertheless, users can opt in to use the hibernation feature by selecting it from the shutdown menu.

Disabling write caching: By disabling write caching and using the GNSD drive 100 cache, the GNSD drive 100 can fully utilize its cache when backup power is available.

Disabling write cache buffer flushing: Disabling write cache buffer flushing can increase SSD performance.

Disable prefetching: SSDs have extremely low seek times and no rotational latency, so access times do not depend on the location of a specific segment. Prefetching therefore defeats its primary purpose. Furthermore, reducing writes to the SSD 200 is part of optimizing its performance, so prefetching should be disabled.

Enable Superfetch only for cached files: An improved approach to using Superfetch is to enable it only for cached files. Superfetch does have a purpose, and simply turning it off completely will only gain some disk space, especially if only the cached files are deleted after disabling it. Disabling Superfetch will cause the machine to be busy swapping applications from disk to RAM, slowing it down. Just because you have an SSD doesn't mean swapping won't occur or won't be noticeable.

Reduce the Recycle Bin size: Set the Recycle Bin to a fixed, smaller size. The Windows operating system uses approximately 10% of the SSD's size for this size. You can set the Recycle Bin to a different size. For example, using a smaller size of 300MB can free up space and reduce writes to the SSD.

Reduce logging: The operating system (OS) writes a lot of event logs. Except for some necessary ones (log application, security, system, security points), it is safe to stop the periodic logs written to the driver.

Disable Windows Reliability Monitor: This performance monitor provides a long-term overview of hardware and software issues. It writes events to the drive every hour. If the operating system is on an SSD, monitoring activity can slow down system stability.

If "Smart Monitor" 246 detects no activity from the host to SSD 200, it flushes the user-selected amount of DRAM data cache to SSD 200, if "Auto-Flush" is enabled. The DRAM data cache can be tagged based on write volume, and the order of flushes can be prioritized based on write volume. Security 244 implements a cryptographic authentication process before allowing access to data cached by the SEED SSD 200 or the GSND drive 100. Smart Data Monitor 246 sends smart monitoring information from the SEED SSD 200 to the SSD application 180.

The GSND app can have a variety of functions, four of which may include, but are not limited to:

The SSD internal cleaning application 181 in the GNSD application 180 performs various advanced functions, such as garbage collection, and deleting old or useless files. The SSD internal cleaning application 181 can be performed regularly, such as, but not limited to, daily or weekly.

"DRAM Allocation" 183 in the GNSD application 180 allocates and initializes DRAM capacity from the operating system for use with the GNSD driver 100 and returns DRAM to the operating system when the GNSD driver is present or when cache mode is turned off.

"Cache Mode On/Off" 185: With cache mode turned off in the GNSD application 180, the GNSD driver 100 can flush all DRAM cache data to the SSD 200 and keep it active. With cache mode turned on, the GNSD driver 100 can be set to the DRAM cache environment. In "Follow Host Access to Device (Read/Write)": IRPs can be passed directly to the next driver. With cache mode turned on, the GNSD driver can read parameters from the "Register Table" and set to the DRAM cache environment. With "Follow Host Access to Device (Read/Write)", IRPs can be passed directly to the GNSD driver. It should be noted that when receiving the "Flush All" command, the GNSD driver will first switch cache mode to off. After the flush is complete, it can switch cache mode back on. With cache mode turned off, "Follow Host Access to Device (Read/Write)", IRP accesses will be ignored by the GNSD driver and passed directly to the next driver. With cache mode turned on, "Follow Host Access to Device (Read/Write)" will be passed to the GNSD driver and the DRAM cache.

"Cache Mode On": If the cache mode status is off, read the parameters from the registry editor and perform memory requirements and allocations from the operating system.

Cache Mode Off: If the cache mode is on, the cache in DRAM is flushed or the DRAM is cleared based on user instructions, and the allocated storage is released back to the operating system.

The "Drive Installation" 187 in the GNSD application 180 installs the user-selected SSD 200 when the GNSD driver is launched. The SSD 200 driver may be, but is not limited to, a USB SSD, SATA SSD, PCI SSD, or M.2 SSD. Other SSDs 200 may also be used.

Super Enhanced Endurance Device (SEED) SSD 200 may include, but is not limited to, NAND flash memory 196, and a SEED controller 192; SEED 200 may also include SSD DRAM 194 and power backup 195. The SEED controller 192 in the SEED SSD 200 may store data in the SSD DRAM buffer 194 and subsequently save it to the NAND flash memory 196, for example, upon power loss or when the SSD DRAM buffer 194 is full.

The host 300 includes a processor 325 for executing instructions for programs such as user applications 182 and for an operating system (OS) kernel 178, such as Windows, Linux, Apple OS, Android, or other operating system kernels. The host 300 also includes a second processor 350, which serves as a secondary or backup processor. Processor 350 is also part of a multi-core system. The GNSD application 180 can be an executable application, for example, on the host 300. The GNSD application 180 and the GNSD driver 100 can be used to erase the payload of the Super Enhanced Endurance Device (SEED) SSD 200. The GNSD application 180 and the GNSD driver 100 can work together to separate data, such as temporary files, paging file pages, etc., that is not meant to be permanently stored on flash memory. The GNSD driver 100 can manage a cache to store this temporary (temporary) data. The cache is part of the host DRAM 333.

The GNSD driver 100 forwards write operations from the host 300 to a cache in the host DRAM 333 and/or the SSD DRAM 194, particularly when sufficient backup power is available. Data from the user application 182 written by the operating system kernel 178 is intercepted by the upper-level file filter driver 190 and passed to the GNSD driver 100 for compression and/or deduplication by the compression engine 242 and/or deduplication engine 243, respectively, before being sent to the file system driver 266. The encryption/decryption engine 240 may, for example, use one of the AES and DEA encryption techniques (see FIG5 ). The lower-level file filter driver 268 then intercepts the data again for further processing by the GNSD driver 100, such as for storage in the cache 301.

File prioritization 264 classifies data based on the data type specified by the low-level file filter driver 268, or the data type indicated by the logical block address, such as metadata (FAT/FDB), temporary files, page files, or user data. FAT refers to the file allocation table, and FDB is the file description block. Temporary files include Windows operating system temporary files, browser temporary files, etc. Alternatively, this function can be disabled for certain applications such as servers. The priority of the operation is given by the priority task transferor 260 so that higher priority tasks can be executed before lower priority tasks. The performance regulator 256 can periodically adjust these priorities to improve performance. The target transferee 254 then sends the data to the magnetic data write cache 20.

Data that is ultimately ready to be written to the SEED SSD 200 may be sent from the GNSD driver 100 to a volume manager 270, for example, which manages storage volumes such as the SEED SSD 200. The SEED controller 192 in the SEED SSD 200 stores the data in the SSD DRAM buffer 194 and then to the NAND flash memory 196, for example, when power is turned off or when the SSD DRAM buffer 194 is full.

Transaction system 262 ensures that data is fully written to SEED SSD 200. Recovery manager 216 determines which write transactions were incomplete, for example, due to an abnormal power outage, and assists applications in performing necessary redo or undo operations to make the data persistent. Recovery manager 216 is therefore designed to ensure that no errors occur during data updates, particularly in the event of power outages during data updates. Scheduler 218 manages transaction system 262 to manage and record write SSD transactions, such as initiation, termination, and commitment.

Initializes the file system during the system boot process; specifically, the I/O system is initialized. File system filter driver 179 is an optional driver that adds to or modifies the behavior of the file system. File system filter driver 179 may be a kernel-mode component that runs as part of the Windows operating system. File system filter driver 179 can filter I/O operations for one or more file systems or file system volumes. Depending on the nature of the driver, filtering can be logging, observing, modifying, selecting, or even blocking. Typical applications for file system filter driver 179 include compression programs, antivirus applications, encryption programs, and hierarchical storage management systems.

The file system filter driver 179 can also work with one or more file systems to manage file input/output operations. These operations include creating, opening, closing, and enumerating files and directories; getting and setting file, directory, and volume information; and reading and writing file data. In addition, the file system filter drivers 266, 190, and 268 can support file system-specific features such as caching, locking, sparse files, disk quotas, compression, security, recovery, reparse points, and volume points. Configuration settings 186, as well as registry and operating system settings 184, can be set by the operating system kernel 178 or the GSND application 180 to define the size of caches or other system variables, as well as to manage the preferred functionality of the GSND application 180 and the GNSD driver 100.

The security engine 244 can perform a cryptographic authentication process before allowing access to the SEED SSD 200 or data cached by the GNSD driver 100. The GNSD driver 100 employs the host CPU 325 to perform functions such as compression/decompression, deduplication, and encryption/decryption. The smart data monitoring 246 can transmit smart monitoring information from the SEED SSD 200 to the GNSD application 180. Smart data monitoring 246 represents a self-monitoring, analysis, and reporting technology.

The smart drive 39 works with the smart monitor 246 to process smart commands, or vendor commands, from the host 300, such as to monitor and control error correction, wear, bad blocks, and other flash memory management. The host 300 uses smart commands to set important data from the SSD drive 200 from the smart drive 39 to the monitor, such as, but not limited to, power-on time, wear level, etc. The host 300 uses this data to determine and identify the expected lifespan of the SSD 200. This information can also be used to determine warranty coverage based on usage. Using the smart drive 39, the host 300 can cause the SSD drive 200 to be replaced before it experiences a failure, thereby improving the overall uptime of the computer system 5. In a RAID configuration, the host can use smart commands, for example, to avoid more expensive RAID 2, 5, or 6 configurations.

In the smart monitor 246 of Figure 1, when 1) automatically refreshed by AP stimulation; or 2) in the Windows operating system (or similar functions in other operating systems), the driver starts and cannot read parameters from the registry editor, the "Start Timer" activates the timer, and then sets the timer to read parameters from the registry editor at regular intervals until continuous, and then configures the memory.

Also in the smart monitor 246, when 1) the AP notifies to stop auto-refresh; or 2) the driver has read out parameters from the registry editor and configured the memory, "Stop Timer" is called to stop the timer.

The deduplication engine 243 detects and detects duplicate copies of data files to reduce the write burden. An engine within the GNSD driver 100, such as the compression/decompression engine 242, can compress, for example, 128 data portions into 48 compressed data portions. These 48 compressed data portions include a header and some compressed data stored in the first compressed page, and two or more pages of compressed data, for a total of three compressed pages. This effectively reduces the number of uncompressed pages from eight. Configuration settings 186 and registry and operating system settings 184 are selected to improve the durability and performance of the flash memory. For example, settings 184 and 186 can enable or disable write caching, drive indexing, search indexing, disk defragmentation, host hibernation, prefetching, super prefetching, and Windows operating system write cache buffer flushing. Prefetching, indexing, hibernation, and disk defragmentation can cause additional writes to the flash memory and reduce durability. Therefore, flash memory durability can be improved by disabling these features. Furthermore, since the GNSD driver 100 has its own write caching and flushing functionality, write caching and write cache buffer flushing can be disabled.

When the main power fails, backup power supply 176 provides power to host 300, allowing host 300 to send critical data 188 from cache to SEED SSD 200 for storage in NAND flash memory 196 during the power outage. Backup power supply 176 can be powered by, for example, but not limited to, a battery, supercapacitor, uninterruptible power supply (UPS), or other backup power sources. The capacity of backup power supply 176 is sized to give host processor 300 sufficient time to shut down applications and properly shut down attached devices. SEED SSD 200 may have its own independent backup power supply 195, allowing SEED SSD 200 to write critical data to NAND flash memory 196 during a main power outage. Backup power supply 195 can be powered by, but not limited to, a capacitor, supercapacitor, or battery. Alternatively, if host backup power supply 176 has sufficient power to gracefully shut down the system, the SSD backup power supply 195 in SEED SSD 200 is not required, for example, when host 300 is a laptop or smartphone.

The disk miniport driver 138 manages the vendor-specific functionality of the attached SSD. The unpacking function 136 unpacks group data recovered from the SEED SSD 200 before transferring it to the data read cache. Because the GNSD driver has its own independent write cache and flushing functions, write caching and write cache buffer flushing can be disabled. Therefore, disabling these features can improve flash memory endurance. Data that can be written to the SEED SSD 200 is grouped into metapages using the grouping engine 134 before being sent to the volume manager 270 and, further, to the SEED SSD 200. By storing metapages, the total amount of data written to the SEED SSD 200 can be reduced.

The CPU register and cache controller 301 writes CPU registers and caches to the host and then to the SEED SSD 200, for example, during a power outage. When enabled, the switch 311 isolates unnecessary components on the host from receiving backup power, thereby extending the time that backup power is available to critical components. The storage controller 309 can be used to transfer data between the host DRAM 333 and the SEED SSD 200 during abnormal power outages and power restoration.

The SEED SSD 200 has a host interface 355 that interacts with the host 300 via a bus such as PCIe, SATA, USB, NVMe, Thunderbolt, eMMC, iSSD, etc. Host data from the host interface 355 can be sent to the SEED controller 192. The SEED controller 192 performs various functions to reduce wear on the NAND flash memory 196, such as by storing refresh files from the NAND flash drive 100 in the host 300 in the SSD DRAM buffer 194 that are not in the NAND flash memory 196.

The SSD DRAM buffer 194 stores a backup of the host cache and other flush data or tables from the GNSD driver 100. It may also store metadata, spare and swap blocks, tables for bad page management, and other buffers and tables. The NAND flash memory 196 stores security information, tables, file systems, and various other tables and buffers for the SSD, in addition to user data and a flush cache. Some areas of the NAND flash memory 196 are reserved for bad blocks or over-provisioning. If this occurs, the host backup power supply 176 shuts off power to the system and provides power only to the SEED SSD 200. If power management 305 is used, power may continue to be provided to the DRAM 333, SEED 303, switch 311, and storage controller 309. The refresh/restore management 126 periodically flushes the contents of the data write cache 20 to the SEED SSD 200, for example, before a power outage.

The deduplication engine 243 detects and deletes duplicate data files to reduce write load. The underlying file filter driver 268 then intercepts more data processed by the GNSD driver 100. Alternatively, the host 300 translates the data type information from the vendor command to the SEED SSD 200 so that the SEED SSD 200's data separation management does not duplicate work already performed by the GNSD driver 100's data separation manager 108. Alternatively, this function can be selectively disabled in certain circumstances.

Examples of modes that exist in the system 5 include, but are not limited to, power-down mode, power-save mode, and persistent mode. In power-down mode, the computer system 5 performs an orderly shutdown process, flushing cache to the SEED SSD 200. In power-save mode, sometimes referred to as "sleep mode," the computer system 5 removes power to selected components, but other remaining components continue to operate, possibly at a reduced power level. Selected cache is written to the SEED SSD drive 200 to maintain selected data. In persistent mode, data is saved as if the computer system 5 were in power-save mode, but the computer system 5 is powered off. Although present, typical sleep modes are not used or are disabled because all DRAM cache needs to be stored in the SEED SSD 200, which may cause unnecessary write operations.

As shown in Figures 3A, 3B, and 3C, in power-down mode and persistent mode, when data is sorted and unpacked by the GNSD driver 100, the host 300 sends a read command to the data separation manager 108, which also passes the host read data after deduplication, decompression, or decryption by the deduplication engine 243, the decompression engine 242, or the decryption engine 240. The data separation manager 108 within the GNSD driver 100 sorts the host read data by data type and selects the data based on the data type.

User data may have been recently written and may still be available from the data write cache 20. Data may be stored in the SSD drive volume 201 of the SEED SSD 200, and the user data is first ungrouped by the user data metapage ungrouping process and loaded into the data read cache 20. FAT/FDB data stored in the SSD 200 drive volume is ungrouped by the FAT/FDB metapage ungrouping process 116 before it is placed in the metadata cache 120. Vendor commands sent to the SSD 200 may be used to disable certain duplication functions, such as deduplication, compression, encryption, or data separation, performed by the GNSD driver 100.

Many encodings of data type bits and other state sets, pointers, etc. are possible. The data type state bit does not have to be the first bit in an entry. The entry should be connected to entries in other tables, such as a separate table for tags or valid bits. Temporary files should have extension variables and new extensions should be added to the list to facilitate searching. Temporary files generated by known programs, such as word processors and Internet browsers are known file extensions, but additional extensions can be added at any time. These additional file extensions can be added by updating the firmware to the control software of the SEED SSD 200, or by software updates to the GNSD application 180 and GNSD driver 100. The SEED controller 192 in the SEED SSD 200 stores data in the SSD DRAM buffer 194 and then to the NAND flash memory 196 upon power failure or when the SSD DRAM buffer 194 is full.

To accommodate additional writes during persistent mode, or during power-down mode, such as when power is off or a load fails, the buffer can be copied to persistent mode DRAM image 203, typically not SSD drive volume 201. As shown in FIG3B , interprocessor (IP) information can be stored in IPDRAM 213, rather than SSD drive volume 201. Interprocessor memory (IPDRAM 213) can be used when only selected DRAM contents are stored in persistent mode DRAM image 203. The first byte can be a symbol such as 0x55AA. Each record has a definition filed as DEF, i.e., 0x00 indicates that the record does not need to be backed up during a power failure; 0x01 indicates that the record does need to be backed up; or 0xFF represents the last valid record in IPDRAM. Further details can be implemented using the remaining digits, 0x02 to 0xFE, to identify different data types, such as 0x02 for processor range 207, 0x03 for data write buffer 20, etc. Each record also contains a pointer to the starting address in host DRAM memory and a length field to indicate the total length of the associated data. Each record will have a total of 10 bytes. For a 512-byte sector, it can accommodate 51 records. The 0xFF record is unnecessary and is located at the last record.

When power fails, NVM CTRL 109 or a power failure program executed by CPU 325 will read each record of IPDRAM (in the case of partial storage in DRAM) and decide whether to copy data from DRAM to SSD when the DEF field is not 0x00 or 0xFF. IPDRAM will be set at a fixed known address in DRAM so that CPU 325 or another CPU 350, which can be internal or external, and NVM CTRL 109 access the same location without confusion.

When power is turned off or fails and persistent mode is enabled, the SSD driver 100 flushes and prepares information such as the processor scope 207 and CPU cache 209 and the recovery scope 213 to the host DRAM 333 and updates the IPDRAM 213 before storing the DRAM update in the persistent mode DRAM image 203. The battery or other backup power source can then complete the data written to the persistent mode DRAM image 203 for a period of time. Then, when the main power is restored, the data can be restored from the persistent mode DRAM image 203. Note that write data processed by the GNSD paging file stored in the SSD drive volume 201 of the SEED SSD 200 is typically first unpacked by the paging metapage unpacking process and loaded into the cached paging area 38. Temporary files are not stored in flash memory and are read from the cached temporary file area 124 by the data separation manager 108. Using persistent mode during power-up, cache and metapage groups 113, 114, 116 stored in the persistent mode DRAM image 203 can be loaded back to their same locations in DRAM 333 when power is turned off or fails. Caches are copied from the persistent mode DRAM image 203. Refresh information such as processor-wide, CPU cache, and restore-wide information can be copied from the persistent mode DRAM image 203.

In power-down mode as shown in FIG3C , SSD drive volume 201 provides non-temporary file data types in metapages grouped by the user or by the metapage user file grouping process. SSD drive volume 201 also provides data types for paging files, which are divided into metapages grouped by the paging file grouping process 116, and file descriptor block (FDB) data, which are grouped into metapages grouped by the FDB metapage grouping process 114. Temporary files are stored in the temporary file area 124 in the cache and will be lost once the cache power is exhausted. FDB data may include directories, subdirectories, FAT1, FAT2, etc.

A typical GND driver 100 does not utilize DRAM caching to prevent loss of critical data during a power failure. As shown in FIG4 , during a host write during a power outage, the data separation manager 108 in the GND driver 100 classifies host write data by data type, for example by checking file extensions or analyzing the FAT and FDB. Temporary files are stored in a cached temporary file area 124 with table entries, which are modified in the metadata cache 120. Upon shutdown or power failure, the temporary file area 124 is stored in the persistent mode DRAM image in the SSD DRAM 194 of the SEED SSD 200. Alternatively, temporary files may not be stored in the persistent mode DRAM image, depending on the user's preference.

When data is split and grouped for writing via the GNSD driver 100, the host 300 sends a write command to the data separation manager 108. If permitted, the host can also receive the host write data after deduplication, compression, or encryption by the deduplication engine or compression/encryption engine. The deduplication/compression table entry or metapage grouping table for the deduplication or compression file can be modified in the metapage data cache of the DRAM 333.

As shown in Figure 4, the SSD drive volume 201 receives user or non-temporary file data types in the metapage 113 grouped by the metapage user file grouping process. The SSD drive volume 201 also receives data types for the paging file, which are divided into metapages that have been grouped by the paging file grouping process 116, and FDB that have been grouped into metapages that have been grouped by the FDB metapage grouping process 114. During normal operation, once the corresponding metapage is full, all of these three metapage groups 113, 114, and 116 will be sent from the host 300 to the SSD drive volume 201. In the event of a power outage, the incomplete metapage groups 113, 114, and 116 may be lost. Alternatively, if the SEED SSD has these three metapage groups mirroring the DRAM area 202, data loss can be minimized during a power outage. Temporary files stored in the temporary file area of the cache 124 will be lost when the system is shut down or a power failure occurs.

Figure 5 illustrates encryption. The Data Encryption Standard (DES) is the predominant symmetric key algorithm used to encrypt electronic data. It is highly influenced by modern cryptographic advances in academia. Developed in the 1970s by IBM and based on an earlier design by Horst Feistel, the algorithm was submitted to the National Bureau of Standards (NBS) at the request of the agency responsible for protecting sensitive, unclassified electronic government data.

The Advanced Encryption Standard (AES) is a specification for electronic data encryption, established by the United States National Institute of Standards and Technology (NIST) in 2001. For AES, NIST selected three members of the Rijndael cipher family, each with a 128-bit block size but three different key lengths: 128, 192, and 256 bits.

AES has been adopted by the US government and is now used worldwide. It replaced the Data Encryption Standard (DES) published in 1977. The algorithm described by AES is a symmetric key algorithm, meaning that the same key is used for both encryption and decryption.

If the user chooses to enable encryption, encryption is performed when data is flushed/written to the flash memory device, for example, by encryption engine 240. The user can select whether the encryption is AES or DES encryption. In Figure 5, full data encryption 500 can be performed by flushing the data, for example, from a cache, to encryption engine 520. In one example, AES encryption 520 can be performed on the data before it is stored in SEED SSD drive 530. Furthermore, full data encryption 550 can include flushing the data to encryption engine 240 to perform DES encryption 570 before it is stored in SEED SSD drive 580. Decryption can be the reverse process of encryption. For example, if data is read from the flash memory device, decryption engine 240 can decrypt previously encrypted data. Encryption engines 520 and 570 can have similar functionality to encryption/decryption engine 240.

FIG6 illustrates the compression/decompression process employed by the GNSD driver 100. If enabled by user selection, this process is performed when a user application writes data. The GNSD driver compresses the data before sending it to the "file system driver" (then to the DRAM cache, and then to the flash memory). When the user application reads the data, the GNSD driver decompresses the data. Deduplication can be performed in the same manner as data compression.

Data compression is a technique for encoding data using fewer bits than the original data representation. Compression reduces the storage required to write data to a SEED SSD drive, thereby increasing durability. In an example of data compression for writing to a SEED SSD drive, operating system 600 may write file 605 with an intended destination in SEED SSD driver 635. SEED SSD driver 635 has similar functionality to SEED SSD 200. Write file 605 may be intercepted, processed, and sent to compression engine 615 by file system filter 610 for compression. The compressed data is then passed to filter system driver 620 and, in turn, to filter driver 625 and bus driver 630 for storage on SEED SSD drive 635. Decompression on reads can be the reverse of the compression function, where compressed data read from SEED SSD driver 635 can be transmitted to file system driver 660, via bus driver 640 and filter driver 650. File system driver 660 provides decompression engine 665 with the compressed data, which converts the compressed data into decompressed data. The decompressed data is then intercepted by the file system filter 670, generating a read file operation 675, whereby the operating system 600 reads the uncompressed data. The LZ method is a well-known technique in the art and is the compression/decompression technique used by the compression/decompression engine. Other well-known methods may also be used.

FIG7 illustrates advanced error correction codes (ECC). To increase the endurance of the SEED SSD driver 750, the GNSD driver 775 works with the SEED SSD driver 750 to generate advanced ECC protection codes to help weaker pages extend their useful life. The SEED SSD driver 750 determines and manages the location of degraded pages, including those that are no longer protected by a specified ECC level generated by the SEED controller 192. The GNSD driver 775 can synchronize the "weak table" 720 with the weak table 710 of the SEED driver 700 using a "read weak table command" 745. The DRAM translation layer (DTL) 715 can be the DRAM within the SEED SSD driver 750, where operations are performed by the GNSD 775 to reduce unnecessary writes to the flash memory 700. Whenever the GNSD driver 775 identifies data to be written to a page in the weak table 720, it can generate higher-level ECC data for that page 735 and store the generated ECC data 730 in a DRAM cache area or a spare portion of the SEED driver 750. When the data is read back, if the SEED ECC read is error-free, no additional work is required. If the SEED ECC is erroneous, it sends the erroneous data back to the GNSD driver 775, and the GNSD driver 775 can retrieve the generated ECC data from the DRAM cache or the SEED driver 750. The generated ECC data can be used together with the erroneous data to retrieve the correct data.

In Figure 7, "Advanced ECC" can use LDPC (Low Density Parity Check) to generate additional ECC protection bits by designing LDPC codes to provide a higher level of protection for data and store it in the backup area of the SEED SSD. When an error occurs when the protected data is read, for example, the data cannot be recovered by the SSD device controller, the corresponding ECC/LDPC code of the storage is read and used to make corrections. Therefore, the use of an effective LDPC-like ECC can improve durability. Note that in addition to graph-based codes similar to LDPC, such as algebraic-based codes, it is not limited to BCH, Hamming codes, and Reed-Solomon codes. Although LDPC codes tend to be generated faster and use fewer bits when protecting data of the same size compared to other codes.

FIG8 shows a block diagram of the GNSD driver 100 , wherein:

“Add Device” 800: The GNSD driver creates and initializes a new filter device object for the corresponding physical device object.

IRP refers to an I/O Request Packet, as commonly understood in the art, for example, in connection with Microsoft Windows-based systems but may also be used with other operating system environments. Examples of IRPs include:

“IRP_MN_Start_Device” 805 : Starts a procedure to prepare the SSD 200 for the GNSD driver.

“Allocate Memory Initialize Memory” 810: Request a portion of memory from the host main memory under the control of the operating system and then initialize it for subsequent use with the GNSD driver.

“IRP_MN_REMOVE_DEVICE” 815 : Initiates a procedure to remove the SSD 200 from the GNSD driver.

“Memory Detaching” 820: Returning the requested and allocated memory from the host main memory to the operating system.

"IRP Dispatch" 825: Identifies the type of IRP: read, write, or device control. "IRP Dispatch" includes "IRP_MJ_Device_Control", "IRP_MJ_Read", and "IRP_MJ_Write".

"IRP_MJ_READ": a read request from the I/O manager or file system driver.

"Logical to DRAM Unit" 830: 1. Check the "Logical to DTL" table to see if any DRAM cache unit associated with this unit exists; 2. If so, check the "Logical to DTL" table, "DTL_Unit_SEC_CNT" table and "DTL_Bitmap" table 832.

"Read DRAM" 834: If the associated "Logic to DTL", and the other three tables indicate that the data is valid and all data is in DRAM.

“Read Device” 836 : If there is no associated “Logic to DTL”, or the other three tables indicate that the data is invalid or the data is partially in DRAM and partially in SSD 200 .

"IRP_MJ_WRITE" 827: A write request from the I/O manager or the file system driver.

"Logic to DRAM Cell" 838: 1. Check the "Logic to DTL" table to see if any DRAM cache cells associated with this cell exist; 2. If so, check the "Logic to DTL" table, "DTL_Cell_Status" table and "DTL_Bitmap" table 840.

"Write to New DRAM" 842: If "Logic to DTL" is not relevant, write the data to the unused cache cells of DRAM. Update all four tables.

"Write to Old DRAM" 844: If "Logic to DTL" is relevant, rewrite the data to the pointed DRAM cache unit. Update the other three tables.

"Check Refresh Required?" 846: Checks whether the number of DRAM cache cells that are used but not sent to the SEED exceeds a predetermined threshold level. If not, do nothing. If so, refresh the selected DRAM cache cells and update the other three tables.

"IRP_MJ_Device_Control" 828: Device control operations for user applications and GNSD drivers.

"Fixed Format" 848: If it is a "Format" command, it needs to be updated to the SEED device. Write operation: data can be written to DRAM and all four tables are updated and then sent to the device; read operation: data is read from the device.

“Read Table” 850: Send four table data of Max_DRAM_Unit, DRAM_Usage, and AP.

"Refresh" 852: "DRAM Refresh All", "IDLE Refresh" (e.g., if Idle > 30 seconds, refresh 15 items every 5 seconds), and "Secure Erase" (click the "Secure Erase" button on the GNSD AP, turn off the computer power, or click Device Secure Erase on the taskbar). All are related to this.

“Read and Write Counters” 854: Read/write counts from user applications and actual read and write counts to SEED.

FIG8 shows IRP read traffic 900, which is also shown in FIG9, where:

"Logic to DRAM Unit" 905 is to read data from the user application. "Check if data is all in DRAM?" 910 determines whether the read data is located in the DRAM cache.

If all data is in the DRAM cache, the process proceeds to "While Loop Sector Count" 915. If the reading of the sector data is not complete, "Copy Memory" 920 reads the data from the corresponding sector of the DRAM cache unit. The process then returns to "While Loop Sector Count" 915.

If the user application has read all the sector data as requested, the response "IRP Completed" 940 is sent to the user application.

If the data is not completely in the DRAM buffer, "Send IRP to Next" 925 will set up the "GNSD Read Complete" process. The next step may be the hard drive or the upper filter of the hard drive. At this point, "Check DRAM Data" 930 verifies that valid data is in DRAM. If so, "Copy Memory" 935 is executed and it can respond with "IRP Complete" 940 to the requesting user application. If not, it can respond with "IRP Complete" 940 to the user application.

The IRP write process 1000 is shown in FIG. 8 and also in FIG. 10 , where:

"Logic to DRAM Cell" 1010 is for writing data from the user application. "While Loop Sector Count" 1020 determines that all write data is written to the DRAM cache cell.

If all are written ("Check for Flush Required" 1070), it checks whether the area of the DRAM cache currently being used but not yet sent to the SEED exceeds a predetermined threshold level. If not, it does nothing. If so, it flushes the selected DRAM cache unit and updates the other three tables. Once this is done, it responds with "IRP Completed" 1080 to the user application.

If there is still data not written to the DRAM cache, it can proceed to "Check DRAM Data?" 1030 (determine whether this is the initial write of the data unit). If the logical address data unit does not have an associated DRAM cache unit, a new DRAM cache unit can be mapped to the logical address (updating the "Logical to DTL" and "DTL to Logical" tables). Then it proceeds to "Modify Bitmap" 1040.

If it has an associated DRAM cache unit 1060, it may proceed to "Modify Bitmap" 1040.

"Modify Bitmap" 1040: This updates the "DTL_Bitmap" and "DTL_Unit_Status" tables. Then "Copy Memory" 1050 (copies the sector data from the logical address to the corresponding DRAM cache unit sector). For the unfinished sector data, enter the "While Loop Sector Count".

FIG11 shows a refresh block diagram 1100, wherein:

"Flush PTR = Next Null PTR" 1105: Let the refresh pointer point to the next empty DRAM cell.

"Check Unit_status = DTL_Host_Data" 1110 determines the data status of the DRAM cache unit. If it is not host data, enter "Flush PTR++" 130 to refresh the pointer and increase it by 1.

If it is host data? "Check Unit_Status = DTL_Data_Full" 1115. If the data is not full, "Check Unit_Status = DTL_Overwrite2" 1140. If it is in overwrite2 status, "Move to new unit" 1145 moves the data to the new unit and enters "FLUSH PTR++" 1130 to refresh the pointer and increase it by 1.

If it is not in overwrite2 state, "Modify Image Table" 1125 (Logic to DTL, DTL to Logic, DTL_Unit_status, DTL_Bitmap), then "Refresh" 1135 the data to the SEED device.

If the data is full, "Check Data Sequence" 1120, if "No" then "Refresh" 1135 the data to the SEED device.

If yes, "Modify Image Table" 1125 (Logical to DTL, DTL to Logic, DTL_Unit_status, DTL_Bitmap?), then enter "Refresh PTR++" 1130 to refresh the pointer and increase it by 1.

FIG12 shows a device input and output control 1200, wherein:

"Fixed format" 1205: If the received IRP is, for example, 0x002d0c141207 then 0x00700001207 or 0x002d0c14 then 0x0070000 then 0x002d1400, or x002d0c14 then 0x0070000 then 0x002d1400 then 0x002d1080, it indicates "formatting on" 1211. Of course, the hexadecimal code shown here is for example purposes only, and other codes may also be used.

If the received IRP is 0x002d51901213 or 0x0066001B 1215 , it means “Formatting Off” 1217 .

"Read Table" 1219 sends data of four tables, max_dram_unit, Dram_Using, to AP.

"Max DRAM Unit" 1221: allocated DRAM unit counter.

“DRAM Usage” 1223: Counter of DRAM units currently in use.

“Logical to DTL” table 1227: The entry count value is the maximum DRAM unit, indicating the DRAM unit address corresponding to each logical unit, and “DTL” represents the DRAM translation layer, which is part of the DRAM and is used to reduce unnecessary write refreshes, as described elsewhere in the text, such as Figure 19.

“DTL to Logic” table 1229: The entry count value is the maximum DRAM unit, indicating the logical unit address corresponding to each DRAM unit.

"DTL_Bitmap" table 1231: The entry count value is the maximum DRAM unit, each entry represents a DRAM unit, and each bit of this item represents an LBA (logical box address), 1 means that the LBA data is in the DRAM, and 0 means it is not in the DRAM.

"DTL_STATUS" table 1233: The entry count value is the maximum DRAM unit, and each entry represents the status of each DRAM unit.

“Refresh” 1235 : Write data from DRAM 333 to the physical device.

"Refresh One" 1237 does 15 consecutive refreshes (the refresh size depends on the calculation and is not fixed).

"Refresh All" 1241 turns off cache mode and then refreshes all data in DRAM.

"Read Counter" 1243: The number of times the driver enters IRP_MJ_READ.

"Write Counter" 1245: The number of times the driver enters IRP_MJ_WRITE.

"Read parameters" 1247 sends all file system write counters, all device write counters, max_dram_units, DRAM_usage, overwrite counters, read counters, and write counters to the AP.

Figures 13-14 illustrate I/O request packets (IRPs), kernel-mode structures used by Windows driver models and Windows NT device drivers to communicate with each other and the operating system. Similar packets can be used by operating systems other than Windows. Figure 13 shows an alphabetical list of device type values available to the system I/O manager. Figure 14 shows a table of SSD control codes available for system I/O control. An IRP is a data structure that describes an I/O request and is considered a good equivalent to an "I/O request descriptor" or similar. Instead of passing a large number of small variables (such as buffer address, buffer size, I/O function type, etc.) to the driver, all these parameters are passed through a single pointer to this persistent data structure. If an I/O request cannot be executed immediately, these IRPs with all the parameters are queued. I/O completions are reported back to the I/O manager by passing the address of the program designated for this purpose, an I/O completion request. If I/O completions are reported to the requesting thread, IRPs can be used for specific kernel APC targets. Typically, an IRP is generated by an input/output manager in response to an input/output request from a user mode. However, an IRP is sometimes generated by a plug-and-play manager, a power manager 305, and other system components, and may also be generated by a driver and then sent to other drivers.

The read schedule 1500 is shown in FIG15 , where:

In user mode, during the "User Application Initiated Read Request" 1505, the file record information is read from the subdirectory by the operating system, which then passes the information to the kernel-mode "File System Driver" 1510. Following the execution of the GNSD driver, the "Hard Drive Upper Filter" intercepts the IRP from the "File System Driver" (1.) 1517 and sends it to the "Hard Drive." The "Hard Drive Upper Filter" checks the "Logical to DTL" table. If the data is already in the DRAM cache (2.) 1545, it reads the data from the DRAM cache (A.3) 1540 and sends an "Input/Output Completion Request" (A.4) 1542 along with the data to the "Volume," then to the "File System Driver" (A.5) 1544, and then to the user-mode (A.6) 1546. If the data is not in the DRAM cache (2.) 1545, it sends a request to the "Hard Drive" and sets up the input/output completion procedure (B.3) 1550. The data may be read from the flash memory device and sent to the GNSD Read Complete (B.4) 1555. If some of the data is already stored in the DRAM cache, the read data in the DRAM cache may be updated (B.5) 1560, and the hard drive may send an IRP to the lower drivers until it finally returns to user mode and completes the read scheduler.

The write schedule 1600 is shown in FIG16 , where:

In user mode, during "User Application Initiated Write Request" 1605, the operating system writes file record information to the current subdirectory, for example, and transmits this information to kernel mode "File System Driver" 1610. As the GNSD driver 100 executes, the "Hard Disk Top Filter" 1615 intercepts the IRP from the "File System Driver" (1.) 1612 and sends it to the "Hard Drive" 1620. The "Hard Disk Top Filter" writes the data to the DRAM cache and updates the "Logical to DTL" table (2.) 1645. The DRAM cache usage is then checked (3.) 1650. If the usage does not exceed a predetermined threshold (max_dram_units=1024), an "Input/Output Completion Request" (4.B) 1640 is returned to the "File System Driver" 1610, completing the write scheduler. If usage exceeds a predetermined threshold (max_dram_units - 1024), a predefined "data_refresh" (4.) 1655 may be executed and the refreshed data may be sent to the flash memory device via the "hard drive" 1620 which may send an IRP to lower driver A 1625 and lower driver B 1630 to endpoint 1635, returning to user mode and completing the write scheduler.

FIG17 illustrates a write scheduling metatable 1700. There are four metatables, for example, used to supply a DRAM cache. The first table is a "Logical to DTL" table 1710. DTL stands for "DRAM Translation Layer." Each table entry's offset from the "file system driver" can be a logical address, for example, in 128K byte units, and its content can be the offset starting address of the DRAM cache where the data is allocated, for example, in 128K byte units. All required entries represent the capacity of the flash memory device. The remaining three tables all have their respective offsets as the starting addresses of the DRAM cache cells, for example, in 128K byte units. All required entries are all available cells in the DRAM cache. The second table is a "DTL to Logical" table 1720. Its content is the logical cell address, which is the starting address of the logical address from the "file system driver," for example, in 128K byte units. The third table is a "DTL_Cell_Status" table 1730. Its content is the status of the corresponding DRAM cache cell. One bit for data validity; one bit for its refresh status; one bit for host data; one bit for queued writes; one bit for a single overwrite; one bit for two overwrites; and one bit for the complete data usage of the DRAM cache cell. The fourth table is the "DTL_Bitmap" table 1740. Its contents are a bitmap of the 256 sectors of the DRAM cache cell. Each bit represents the usage of its corresponding sector in the DRAM cache cell. In the DRAM cache cell, a logical "0" represents empty or invalid data, and a logical "1" represents valid data, e.g., 256 bits.

FIG18 illustrates the trimming function (TRIM) 1800 of the GNSD driver. TRIM 1800 allows the operating system to notify the solid-state drive (SSD) that a data block is no longer considered in use and can be internally erased. An SSD typically does not know which sectors/pages are actually in use and which can be considered free space. In a hard drive, delete operations are electronically limited to marking data blocks. While a hard drive can simply overwrite old data, TRIM allows the SSD to be aware of deleted data. Without TRIM 1800, the SSD would move the data to a new page within the block, wasting time and causing unnecessary writes to the SSD. Using the GNSD driver 100, the TRIM command notifies the GNSD driver 100 not to flush the deleted data to the SSD, eliminating unnecessary writes. This reduces write-amplification and increases the endurance of the SSD. The TRIM manager processes TRIM commands 1835 from the file system or operating system on the host 300. TRIM commands 1835 indicate sectors no longer needed by the host and erase or remove them. The trimmed page is recorded as deleted in the Page Status Table. When background garbage collection is performed, if a block is identified as an erase candidate, the page is not copied to a new block. At that time, the TRIM command 1835 is completed. The TRIM manager performs housekeeping operations such as keeping track of which sectors and pages in the block are no longer needed. The Recycle Bin can also be used to track blocks ready for erasure. Once the entire block is no longer needed, the TRIM manager will activate the Recycle Bin or other erase mechanism to erase the block so that it can be reused.

In FIG19 , and also referring to FIG1 , a durable translation layer (ETL) is generated in the DRAM buffer of SSD DRAM 194 and provides temporary storage to reduce flash memory wear. This ETL is provided by a SEED controller 192 that works with DRAM 194 to reduce unnecessary write operations to flash memory 196. DRAM 20 may represent the DRAM buffer found in DRAM 194. This ETL is used to manage the interaction between DRAM 194 and flash memory 196 during power-up, normal operation, and power failure. The temporary area of DRAM buffer 20 stores temporary files, which are identified by the controller 192 reading the file extension in the FDB/FAT. This file extension is the file extension stored in the FAT area or FDB area. Temporary files have well-known extensions, such as those used by operating systems, word processors, internet browsers, CAD systems, or spreadsheet systems. Other applications may use their own unique file extensions for temporary files. Both areas have a table for allocating each temporary file. This table can be accessed by a host logical address. The ETL, controlled by the controller, can be generated in the DRAM buffer. The ETL can be used to provide temporary storage to reduce flash memory wear. Data is allocated in the DRAM buffer to form a data structure distribution in the DRAM buffer, which can be managed by the controller in order to write new data across multiple flash memory channels. The controller manages non-temporary data by searching the mapping table, finding a matching entry using a logical address from a standard host write operation, reading the data type bits and pointer from the matching entry, and identifying the data type as a non-temporary data type. Pairing DRAM with the SEED SSD includes using an enduring translation layer (ETL) to control access to the flash memory and access to the dynamic random access memory (DRAM) cache. The ETL checks blocks of the flash memory and identifies the block as bad if all error bits exceed a preselected high level threshold, or registers the block in a weak table if all error bits exceed a preselected low level threshold. Typically, the weak table is synchronized with the GNSD driver 100, which can be coupled to the host DRAM 333.

FIG19 illustrates a memory map representing the persistent translation layer (ETL) representing various data types stored in ETL DRAM 20, which may also be SSD DRAM 194 as shown in FIG1 . ETL DRAM 20 represents a portion of SSD DRAM 194. The firmware of SEED controller 192 uses the ETL to manage the interaction between ETL DRAM 20 and flash memory 196 in DRAM 194 at power-up, during normal operation, and during power-down. A temporary area 1940 in ETL buffer 20 stores temporary files, identified by a read file extension in the FDB/FAT, which is the file extension stored in FAT area 1958 or FDB area 1960. Temporary files have extensions such as .tmp, .temp, .tmt, .tof, .trs, .tst, etc. System-related temporary files include ._mp, .log, .gid, .chk, .old, and .bak. Temporary files associated with AutoCAD include .SV$, .DWL, and .AC$. Temporary files associated with Word include .asd files. Temporary files associated with Excel include .xar files. Other applications may use their own file extensions for temporary files. The temporary internet file area 1942 stores files with extensions such as .gif, .jpg, .js, .htm, .png, .css, .php, .tmp, .mp3, .swf, .ico, .txt, .axd, .jsp, and .aspx. Areas 1940 and 1942 each have a table for allocating each temporary file. The table can be indexed by a logical address from the host 300.

Fetch data area 1944 stores fetch data and a table of entries in fetch data area 1944. Each time the computer is started, the Windows operating system keeps track of how the computer was started and which programs are typically opened. The Windows operating system saves this information as several small files in a prefetch folder. The next time the computer is started, the Windows operating system points to these files to help speed up the startup process.

The prefetch folder is a subfolder of the system folder in the Windows operating system. The prefetch folder is self-perpetuating and does not need to be deleted or its contents emptied. Log files with the extension .log or .evt are stored in the log file area 1946. They may also have an image table for log files stored in this area or be treated as temporary files.

The paging file used to exchange data between a peripheral storage device, such as a hard drive or SEED SSD drive 200, and the host main memory is stored and mapped in paging area 1948. The read cache of data read from flash memory 196 and stored in ETL DRAM buffer 20 is located in read cache area 1951. A mapping table of read cache entries is available and includes a tag, valid bit, and pointer to the data in flash memory 196. System area 1950 stores flash system data for the operating system of SEED SSD controller 192. Buffer 1952 stores raw host data (including LBAs) that has been written to SEED SSD drive 200. This actual host data is then moved to data write cache 1954 before being written to flash memory 196. The super write cache technology associated with data write cache 1954 is used to cache data in flash memory 196 to reduce write/erase times to flash memory 196, and backup/swap blocks 1956 further reduce write/erase times in flash memory 196.

Data write operations from host 300 first write data to buffer 1952. After processing by GNSD driver 100, such as compression, the data is written to data write cache 1954 and then to flash memory 196. When large amounts of data are continuously written from host 300, writing to flash memory 196 may become a bottleneck. Data may be continuously written to data write cache 1954 until it is full, at which point the flow of data from buffer 1952 to data write cache 1954 stops. If data in buffer 1952 is also full, host 300 is notified to stop blocking.

The data write cache 1954 employs a durable write cache algorithm that stores write data in the ETL DRAM buffer 20 rather than in the flash memory 196 until evicted. Therefore, multiple writes with the same LBA can be overlapped and written to the data write cache 1954 and written to the flash memory 196 using stripe preparation units based on rules (e.g., based on elapsed time, allocated capacity, etc.) or upon shutdown or power failure. The data write cache 1954 also supports partial page writes until the entire page is grouped into multiple partial pages. Therefore, multiple partial page writes can be written to the flash memory 196 based on rules (e.g., based on elapsed time, allocated capacity, etc.) or upon shutdown or power failure.

In a multi-channel controller architecture, device controller 192 writes data arranged into multiple pages (the number of pages equals the number of channels) from data write buffer 1954 to the flash memory in the data stripe preparation unit to optimize the use of the flash memory interface bandwidth. For each device controller 192, there are C channels, F flash chips attached to each channel, D dies stacked per die, and P faces per die. The channel stripe size can be set to F*D*P pages. The stripe depth can be set to C*F*D*P pages. Device controller 192 selects data from data write buffer 1954 and writes it to the selected stripe of flash memory 196, then updates the associated mapping table entry corresponding to the PBA address. Each channel has only one bus and can therefore access only one die. F*D dies are interleaved to share the bus to maximize bus utilization. The stripe preparation unit size can be C or up to C*F*D*P pages.

A durable translation layer (ETL) method for increasing the endurance of flash memory has a low specified erase cycle life. The flash memory interface has multiple buses for channels; each channel has multiple flash chips; each chip has multiple dies; and each die has multiple faces. All channels can be accessed simultaneously. Not all dies in the same channel can be accessed simultaneously; only one die in the same channel can be accessed at a time. While writing or reading from other dies, other dies in the channel can be accessed. Interleaving writes or reads increases flash memory access performance. Data write cache is stored in a DRAM buffer and managed by a controller according to rules. When dirty data in the data write cache is larger than a stripe ready unit, the device controller manages the dirty data and writes it to the flash memory through the flash memory interface. The device controller manages data distribution for each channel of the flash memory. The device controller manages data interleaving for one die of one chip in each channel and manages mapping table entries to track LBA to PBA mappings.

In another alternative design, in a multi-channel controller structure, each channel has its own data write cache 1954. The write stripe preparation unit is synchronized with each flash memory channel to maximize the flash memory interface speed. User file data can be identified as frequently accessed data based on a hit rate >= n (e.g., 2) and infrequently accessed data with a hit rate < n. They are written to the two data write caches 1954 separately. Multiple writes with the same LBA address in the frequently accessed area will overwrite the old content in the DRAM, i.e., not refreshed, thereby reducing the number of writes to the flash memory 196. The buffered data in the frequently accessed area of the data write cache will be stored in the flash memory 196 of the stripe preparation unit according to rules such as elapsed time, allocated capacity, or shutdown or power failure. The buffered data in the infrequently accessed area of the data write cache will be stored in the flash memory 196 of the stripe preparation unit according to other rules such as elapsed time (e.g., 15 minutes), allocated capacity, or shutdown or power failure.

When the LBA address deviates from the host address, compensation is added to the LBA address to align the LBA address with the page address of the flash memory 196 before writing data to the write cache 1954 to make subsequent writes to the flash memory more efficient.

Durable spare and swap blocks 1956 are used for garbage collection to consolidate valid data and remove data from the write cache before being written to the flash memory. Page status table 1963 contains a table with page status entries, such as free pages, used pages, trash pages (TRIMed), bad pages, and pages requiring additional ECC protection. Compressed LBA table 1961 is an entry for the compressed user data image. Block erase count table 1964 keeps track of the erase counter and block status for each physical block in flash memory 196.

Partial page mapping table 1966 stores partial page mapping information. DRAM 20 does not have enough space for the entire mapping table, so only a portion is loaded into DRAM. When an LBA table entry is not in DRAM, some portion of the partial mapping table is removed and the associated LBA table is loaded into DRAM. Partial sub-sector group mapping table 1968 stores sub-sector mapping information for data files and is smaller than a page. The partial mapping table of partial sub-sector group mapping table 1968 has a mapping table entry that can be set to N, with only one entry. The remaining N-1 entries are stored in flash memory and loaded into the DRAM buffer in the event of a partial mapping table miss.

The intelligent data collector 1970 has data tables and other information for use by the SMART function 39 (FIG. 1) of the SMART monitor 246 and can be requested by the host through SMART commands or vendor commands.

The size of the region in the ETL DRAM buffer 20 can be determined by the overall ETL DRAM 20 size, the page size, the block size, and the sector size of the flash memory, and by using page mapping or block mapping, or by estimating the proportion of entries where the region is page-mapped rather than block-mapped. For example, the ETL DRAM buffer 20 can be a 512-megabyte DRAM, with 240 megabytes allocated for the temporary area 1940, 160 megabytes for the internet temporary area 1942, 12 megabytes for fetch data, 6 megabytes for log files, and so on.

In the multi-channel controller structure, the device controller 192 reads data from the flash memory 196 and passes through the multi-channel structure to various ETL tables (FAT/sub-image table 1958, FBD/sub-image table 1960, page status table 1962, compressed LBA table 1961, block erase count table 1964, partial page image table 1966 and partial sub-sector group image table 1968).

In a multi-channel controller architecture, the device controller 192 may write various ETL tables (FAT/sub-image table 1958, FBD/sub-image table 1960, page status table 1962, compressed LBA table 1961, block erase count table 1964, partial page map table 1966, and partial sub-sector group map table 1968), which are arranged into a number of pages (the number of which is equal to the number of channels) to refresh the stripe preparation units, according to rules (e.g., based on elapsed time, allocated capacity, etc.) or depending on shutdown or power failure, to achieve the best use of the flash interface bandwidth.

The green energy and non-solid state drive application 180 and embodiments of the drive 100 described herein have a profound effect on the endurance of SSD devices. In fact, the GNSD drive 100 can provide more than a 10x improvement in SSD write amplification. For example, a standard TLC SSD has a standard endurance of 500-1500 program/erase (P/E) cycles, while the embodiments of the invention herein can enhance the endurance of a TLC SSD to 5000-15000 (P/E) cycles. In addition, the endurance of multi-layer cell (MLC) SSDs and single-layer cell (SLC) SSDs has experienced an improvement of more than 10 times the endurance of current MLC and SLC SSD standards. Moreover, write amplification is reduced relative to the standard value of the SSD.

The GNSD driver is not limited to improving the endurance/performance of SSDs. It can also be used to improve other non-volatile storage devices, such as, but not limited to, Secure Digital (SD), MultiMediaCard (MMC), Embedded MultiMediaCard (eMMC), M.2, Hard Disk Drive (HDD), and hybrid SSD/HDD.

Although the present invention has been described by way of example with reference to the circuit diagrams, it should be noted herein that various changes and modifications may occur to those skilled in the art. Therefore, unless such changes and modifications depart from the spirit of the present invention, they should all be included in the construction of the present invention.

Claims (20)

1. A green and non-solid-state driver coupled to host DRAM, comprising: Storage manager, coupled to upper filter; and The data packet engine coupled to the host DRAM; The de-packetization engine is coupled to the host DRAM; The power manager coupled to this storage manager, and The refresh/recovery manager is coupled to this storage manager. The green energy and non-solid-state drive is coupled to the green energy and non-solid-state drive application, and the host DRAM is coupled to the non-volatile memory. 2. The green energy and non-solid-state actuator as described in claim 1, further comprising: Compression/decompression engine, coupled to file system filter; Alternatively, the deduplication engine could be coupled to a file system filter. Alternatively, an encryption/decryption engine could be coupled to a file system filter; or an advanced error correction code engine could be coupled to a lower-level filter. 3. The green energy and non-solid-state drive as described in claim 2, wherein the encryption/decryption engine is configured to encrypt according to a data encryption standard or an advanced encryption standard. 4. A green and non-solid-state driver coupled to host DRAM, comprising: Data grouper; DRAM data write cache, coupled to the data grouper; Cancel the data grouper; and DRAM data read cache, coupled to the data de-packer; The data grouper and the de-grouper are coupled to the upper filter and the lower filter, respectively. Among them, green energy and non-solid-state drives are coupled to green energy and non-solid-state drive applications, and Among them, DRAM is coupled to non-volatile memory. 5. The green energy and non-solid-state actuator as described in claim 4, further comprising: Compression/decompression engine, coupled to file system filter; Alternatively, the deduplication engine could be coupled to a file system filter. Alternatively, the encryption/decryption engine could be coupled to a file system filter. Alternatively, an advanced error correction coding engine could be coupled to the lower-level filter. 6. The green energy and non-solid-state actuator as described in claim 4, further comprising: Intelligent data monitor, coupled to ultra-durable SSDs; and The security engine is coupled to the host. 7. The green energy and non-solid-state drive as described in claim 5, wherein the advanced error correction coding engine employs either graph-based coding or algebraic coding. 8. The green energy and non-solid-state actuator of claim 7, wherein the advanced error correction code engine employs a low-density parity check code based on graph coding. 9. The green energy and non-solid-state drive as claimed in claim 4, wherein each of the data packetizer and the de-data packetizer is coupled to: Meta page grouper for user data; FDB's metapage grouper; and Meta-page grouper for page file pages. 10. A method for operating a green and non-solid-state drive and a green and non-solid-state drive application coupled to a host DRAM, comprising: Couple configuration and registration settings to host and green energy and non-solid-state drive applications; Couple green energy and non-solid-state drive data packet engine to host DRAM; Couple green energy to host DRAM and eliminate data packet engine from non-solid-state drives; Memory management that couples green energy to non-solid-state drives in the host system; Couple the host DRAM with green energy and the non-solid-state drive refresh/recovery manager; and Couple the upper and lower filters with green energy and non-solid-state drive data packetization engine and de-packetization engine; and Couple DRAM to SSDs in ultra-durable devices; and one: Disable driver indexing, disable driver search indexing, reduce page file size, disable system restore, disable hibernation, disable prefetching, reduce recycle bin size, disable disk defragmenter, reduce logging; and disable performance monitor, disable write caching, or disable write cache buffer flushing. Among them, the durability of the Super Durable Device SSD is increased to exceed the specified value and the write amplification is reduced to less than the specified value. 11. The method of claim 10, further comprising: Synchronize weak tables to weak tables in Super Durable Device SSD blocks; Advanced ECC data that generates page data in weak tables, providing the generated advanced ECC data; The generated advanced ECC data is stored in a cache area of the host DRAM, or in the remaining area of an ultra-durable SSD; and Write the page data indicated by the weak table. 12. The method of claim 11, further comprising: Read data from the page using the ECC engine; If the Ultra Durable SSD's native ECC engine determines that the data in the page is incorrect: The weak table generated by the ECC engine is considered erroneous page data by the advanced ECC; and The erroneous page data is corrected using advanced ECC generated by the ECC engine. 13. The method of claim 10, further comprising: Grouped user data is on the first meta page; The grouping system FDB uses second-level pages; Grouped page file pages are third-level pages; and Store the first, second, and third meta pages in the storage volume of the Super Durable Device SSD. 14. The method of claim 10, further comprising: Provides ETL to control access to flash memory in Ultra Durable Device SSDs as well as access to DRAM buffers; Inspect flash memory blocks via ETL; The ETL process identifies a flash memory block as bad if all error bits exceed a pre-selected high-level threshold, or it identifies a flash memory block as bad if all error bits exceed a pre-selected low-level threshold. Synchronous coupling of green energy to DRAM and weak table of non-solid-state driver. 15. A computer system host, including a green and non-solid-state drive application coupled to the host DRAM, the green and non-solid-state drive application comprising: An internal SSD cleanup module coupled to green energy and non-solid-state drives is used to perform periodic garbage collection and delete old or useless files; A DRAM allocation module coupled to the green and non-solid-state drive is used to allocate and initialize DRAM capacity from the operating system, use the green and non-solid-state drive when the green and non-solid-state drive is present or when cache mode is off, and return DRAM to the operating system. A driver installation module coupled to the green and non-solid-state drives is used to install a user-selected SSD drive when the green and non-solid-state drives boot; or A cache mode on/off switch coupled to green energy and non-solid-state drives. 16. A computer system host, comprising: Green energy and non-solid-state drives are coupled to and decoupled from data packets in the host computer system; and The green energy and non-solid-state drive application as described in claim 15; Among them, the upper and lower filters of the computer system host are used to couple data packets and decouple data packets from green energy and non-solid-state drives, and Computer system host coupled to non-volatile memory devices. 17. The computer system host as claimed in claim 16, further comprising coupling configuration and registration settings of the operating system coupled to the computer system host. 18. A method for increasing the durability of non-volatile flash memory, comprising: Couple green energy and non-solid-state drives with ECC engines to host DRAM; Couple the ultra-durable device SSD to the host DRAM; Generate advanced ECC for selected data in a Super Durable Device SSD using host DRAM; and Use this advanced ECC to correct erroneous data in Super Durable Device SSDs. 19. The method of claim 18, further comprising: Synchronize the weak table to the SSD block weak table of the super-durable device; Advanced ECC data that generates page data in weak tables, providing the generated advanced ECC data; The generated advanced ECC data is stored in a cache area of DRAM or the remaining area of an ultra-durable SSD; and Write the page data indicated by the weak table. 20. The method of claim 18, further comprising: Read data from the page; If the Ultra Durable SSD's local ECC engine determines that the data in the page is incorrect; Then read the high-level ECC data generated in the weak table belonging to the page; and The page generates advanced ECC data to correct the error.