ZNS protection with small SLC cache using region groups

Abstract

The present disclosure generally relates to using a dual temporary data protection method and a small SLC cache to achieve an acceptable uncorrectable bit error rate (UBER) by adding temporary XOR protection to a group of regions rather than storing another copy of the regions within the driver. The parity data may be stored with the user data (e.g., as part of the group of regions, thereby effectively increasing the size of the group of regions by 1) or in a separate location, such as in an SLC block or another separate MLC block.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Non - Provisional Application No. 18 / 354,446, filed on July 18, 2023, with the title "ZNS Protection With Small SLC Cache Using Zone Groups", and this application incorporates by reference in its entirety the entire content of the U.S. Non - Provisional Application for all purposes. The U.S. Non - Provisional Application claims the priority of U.S. Provisional Application No. 63 / 478,280, filed on January 3, 2023. Background Art Technical Field

[0003] Embodiments of the present disclosure generally relate to writing in a zone - name - space (ZNS) environment.

[0004] Description of the Related Art

[0005] The zone - name - space (ZNS) solid - state drive (SSD) architecture expects host applications to always perform sequential writes and deallocate data at the boundaries of the drive's block size, thus eliminating the need for garbage collection (GC) operations in the drive and also eliminating the need for over - provisioning to support GC. Thus, ZNS provides better utilization of drive space and higher durability.

[0006] A ZNS zone group combines multiple small zones that are allocated together and will be accessed together when writing data into and possibly reading data from the zone group. The zone group is intended for performance acceleration by allowing the system to write in parallel to multiple plane blocks and even multiple dies. When using a zone group, the host submits a perfect interleaving of write operations for different zones within the same zone group.

[0007] For "small - zone" ZNS SSDs, these zones can be as small as a single memory device (e.g., NAND) erase block on a single plane. For small - zone ZNS SSDs, there is no way to maintain permanent XOR parity protection across multiple planes / dies because each zone spans a limited number of planes or even simply a single plane, and the lifetimes of different zones are different. Thus, small - zone ZNS SSDs generally do not have permanent XOR parity protection stored in the memory device for recovering from defects or high bit - error rates (BERs) that may occur after writing to a zone. 17Compared with usually 1 UECC in a sector, under a given expectation, the uncorrectable bit error rate (UBER) requirement is usually reduced to 10 14 uncorrectable error correction code (UECC) in 1 of the sectors.

[0008] However, even with the reduced UBER requirement, without full area (also known as block) protection, the incoming host-written data is vulnerable to defects that can cause failure to achieve 10 14 1 UECC required in. Therefore, a typical implementation option stores another copy of the area data in the drive (e.g., by writing the area to a single-level cell (SLC) or elsewhere), in a multi-level cell (MLC) such as a triple-level cell (TLC) or a quad-level cell (QLC), and no failure is detected during the area programming phase. This other copy can be written as the first level and then the data is copied to the MLC, or potentially this other copy can be written in parallel with writing the data to the MLC. This other copy can be used to recover the entire area data in case of a failure.

[0009] Various types of failures may occur in an SSD. Some failures are limited to a small amount of the latest written data, and some failures may eventually lose most of the erase block being written, potentially losing all the data. In some systems, to meet the 1e-14 UBER requirement, data recovery for the entire area (or most of the area) needs to be supported during the MLC programming phase until the data is successfully written, so an "other copy" of the area should be allocated for the entire area programming phase.

[0010] A "small area" ZNS SSD can support many open small areas that can be written in parallel, such as 16K open areas per 64TB drive. In parallel, the size of a single erase block may be large, such as 200MB. Therefore, storing another copy in all open areas of the SSD will result in a significant portion of the drive capacity being lost, thus significantly increasing the SSD cost.

[0011] Therefore, there is a need in the art to utilize different schemes to achieve the required UBER. Summary of the Invention

[0012] The present disclosure generally relates to achieving an acceptable uncorrectable bit error rate (UBER) by using a dual temporary data protection method and a small SLC cache by adding temporary XOR protection to a region group rather than storing another copy of the region within the drive. The parity data can be stored together with the user data (e.g., as part of the region group, thus effectively increasing the region group size by 1) or stored in a separate location, such as stored in an SLC block or another separate MLC block.

[0013] In one embodiment, the protection scheme for "standalone regions" still uses traditional methods by storing another copy of the region data for the region programming phase. When the host opens a new region, the host determines whether the region should be allocated as part of a region group or as a "standalone region". The controller should declare during initialization how many open regions are supported when opened as part of a "region group" and how many open regions are supported when opened as a "standalone region". The controller also declares the size of the region group. It is expected that the number of "standalone regions" is significantly less than the total number of open regions. For example, if the number of "standalone regions" accounts for 25% of all open regions and the region group size is 16, the total space required to protect all regions becomes <30% compared to the space required when protecting all regions by keeping an "another copy" of the data. This allows for significant savings in the cost of SSD drives.

[0014] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command for one or more regions in a partitioned namespace (ZNS) environment of the memory device; determine whether the write command is to write data to a region of a standalone region or a region of a region group; if the write command is to write data to a region of a region group, generate parity data for the user data corresponding to the write command; and store the parity data.

[0015] In another embodiment, a data storage device having a small SLC cache and utilizing a dual temporary data protection method includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: temporarily store XOR parity data of multiple open region groups in the memory, and store another temporary copy of the user data of the standalone regions without XOR parity in the small SLC cache or MLC.

[0016] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: open a region within a standalone region or a region group based on a command received from a host device; and write to the region within the standalone region or the region group.

[0017] In another embodiment, a data storage device includes: a component for storing data; and a controller coupled to the component for storing data, wherein the controller is configured to: allocate a first predetermined amount of the component for storing data for a standalone region; and allocate a second predetermined amount of the component for storing data for a region group, wherein the second predetermined amount is greater than the first predetermined amount. Description of the Drawings

[0018] To be able to understand the above features of the present disclosure in detail, the present disclosure briefly outlined above can be described more specifically by referring to the implementation examples, some of which are illustrated in the accompanying drawings. However, it should be noted that the drawings only illustrate typical implementation examples of the present disclosure and should not be considered as a limitation on the scope of the present disclosure, because the present disclosure may allow other equivalent implementation examples.

[0019] Figure 1 is a schematic block diagram illustrating a storage system in which a data storage device can be used as a storage device of a host device according to some implementation examples.

[0020] Figure 2 is a schematic diagram of writing to a zone in a ZNS environment according to one implementation example.

[0021] Figure 3 is a schematic diagram of writing to a zone in a ZNS environment according to another implementation example.

[0022] Figure 4 is a flowchart illustrating a method of writing to a zone in a ZNS environment according to one implementation example.

[0023] For ease of understanding, whenever possible, the same reference numerals are used to denote the same elements common to the accompanying drawings. It is contemplated that elements disclosed in one implementation example can be beneficially used in other implementation examples without specific recitation. Detailed Description

[0024] Reference is made below to the implementation examples of the present disclosure. However, it should be understood that the present disclosure is not limited to the specifically described implementation examples. On the contrary, any combination of the following features and elements (whether or not they relate to different implementation examples) is contemplated to implement and practice the present disclosure. Moreover, although the implementation examples of the present disclosure may achieve advantages over other possible solutions and / or over the prior art, whether a particular advantage is achieved by a given implementation example does not limit the present disclosure. Thus, the following aspects, features, implementation examples, and advantages are merely illustrative and are not to be considered elements or limitations of the appended claims, unless expressly recited in the claims. Similarly, reference to "the present disclosure" should not be construed as a generalization of any inventive subject matter disclosed herein and should not be considered an element or limitation of the appended claims, unless expressly recited in the claims.

[0025] The present disclosure generally relates to achieving an acceptable uncorrectable bit error rate (UBER) by using a dual temporary data protection method and a small SLC cache by adding temporary XOR protection to a region group rather than storing another copy of the region within the drive. Parity data may be stored with the user data (e.g., as part of the region group, effectively increasing the region group size by 1) or stored in a separate location, such as in an SLC block or another separate MLC block.

[0026] Figure 1 FIG. 4 is a schematic block diagram illustrating a storage system 100 according to some embodiments, the storage system having a data storage device 106 that can function as a storage device for a host device 104. For example, the host device 104 can utilize the non-volatile memory (NVM) 110 included in the data storage device 106 to store and retrieve data. The host device 104 includes host DRAM 138. In some examples, the storage system 100 can include multiple storage devices, such as the data storage device 106, which can operate as a storage array. For example, the storage system 100 can include multiple data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID), which together act as a mass storage device for the host device 104.

[0027] The host device 104 can store data to and / or retrieve data from one or more storage devices, such as the data storage device 106. As Figure 1 illustrated, the host device 104 can communicate with the data storage device 106 via an interface 114. The host device 104 can include any of a wide range of devices, including computer servers, network-attached storage (NAS) units, desktop computers, notebook (i.e., laptop) computers, tablet computers, set-top boxes, telephone handsets (such as so-called "smart" phones), so-called "smart" tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices capable of transferring or receiving data from the data storage device.

[0028] The host DRAM 138 may optionally include a host memory buffer (HMB) 150. The HMB 150 is a portion of the host DRAM 138 that is allocated to the data storage device 106 for exclusive use by the controller 108 of the data storage device 106. For example, the controller 108 may store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, etc. in the HMB 150. In other words, the HMB 150 can be used by the controller 108 to store data that would typically be stored in the volatile memory 112, buffer 116, internal memory of the controller 108 (such as static random access memory (SRAM), etc.). In an example where the data storage device 106 does not include DRAM (i.e., the optional DRAM 118), the controller 108 can utilize the HMB 150 as the DRAM of the data storage device 106.

[0029] The data storage device 106 includes a controller 108, NVM 110, power supply 111, volatile memory 112, interface 114, write buffer 116, and optional DRAM 118. In some examples, the data storage device 106 may include additional components not shown for clarity in Figure 1 the figure. For example, the data storage device 106 may include a printed circuit board (PCB) to which the components of the data storage device 106 are mechanically attached, and the printed circuit board includes conductive traces, etc. that electrically interconnect the components of the data storage device 106. In some examples, the physical size and connector configuration of the data storage device 106 may conform to one or more standard form factors. Some example standard form factors include, but are not limited to, 3.5” data storage devices (e.g., HDD or SSD), 2.5” data storage devices, 1.8” data storage devices, Peripheral Component Interconnect (PCI), Extended PCI (PCI-X), PCI Express (PCIe) (e.g., PCIe x1, x4, x8, x16, PCIe Mini Card, Mini PCI, etc.). In some examples, the data storage device 106 may be directly coupled to the motherboard of the host device 104 (e.g., directly soldered or inserted into a connector).

[0030] Interface 114 may include one or both of a data bus for exchanging data with host device 104 and a control bus for exchanging commands with host device 104. Interface 114 may operate according to any suitable protocol. For example, interface 114 may operate according to one or more of the following protocols: Advanced Technology Attachment (ATA) (e.g., Serial ATA (SATA) and Parallel ATA (PATA)), Fibre Channel Protocol (FCP), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface eXtension (CCIX), Open Channel SSD (OCSSD), etc. Interface 114 (e.g., the data bus, the control bus, or both) is electrically connected to controller 108, thereby providing an electrical connection between host device 104 and controller 108, thereby allowing data to be exchanged between host device 104 and controller 108. In some examples, the electrical connection of interface 114 may also permit data storage device 106 to receive power from host device 104. For example, as Figure 1 illustrated, power supply 111 may receive power from host device 104 via interface 114.

[0031] NVM 110 may include a plurality of memory devices or memory cells. NVM 110 may be configured to store and / or retrieve data. For example, the memory cells of NVM 110 may receive data and a message indicating to store the data from controller 108. Similarly, the memory cells may receive a message from controller 108 indicating to retrieve data from the memory cells. In some examples, each of the memory cells may be referred to as a die. In some examples, NVM 110 may include a plurality of dies (i.e., a plurality of memory cells). In some examples, each memory cell may be configured to store a relatively large amount of data (e.g., 128 MB, 256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB, 256 GB, 512 GB, 1 TB, etc.).

[0032] In some examples, each memory cell may include any type of non-volatile memory device, such as a flash memory device, a phase change memory (PCM) device, a resistive random access memory (ReRAM) device, a magnetoresistive random access memory (MRAM) device, a ferroelectric random access memory (F-RAM), a holographic memory device, and any other type of non-volatile memory device.

[0033] The NVM 110 may include multiple flash memory devices or memory cells. The NVM flash memory devices may include NAND- or NOR-based flash memory devices and may store data based on the charge contained in the floating gate of the transistor of each flash memory cell. In the NVM flash memory devices, the flash memory devices may be divided into multiple dies, where each die of the multiple dies includes multiple physical or logical blocks, and the multiple physical or logical blocks may be further divided into multiple pages. Each of the multiple blocks within a particular memory device may include multiple NVM cells. The rows of the NVM cells may be electrically connected using word lines to define the pages among the multiple pages. The corresponding cells in each of the multiple pages may be electrically connected to corresponding bit lines. Additionally, the NVM flash memory devices may be 2D or 3D devices and may be single-level cells (SLCs), multi-level cells (MLCs), triple-level cells (TLCs), or quad-level cells (QLCs). The controller 108 may write data to and read data from the NVM flash memory devices at the page level and erase data from the NVM flash memory devices at the block level.

[0034] The power supply 111 may supply power to one or more components of the data storage device 106. When operating in the standard mode, the power supply 111 may use the power provided by an external device (such as the host device 104) to supply power to one or more components. For example, the power supply 111 may use the power received from the host device 104 via the interface 114 to supply power to one or more components. In some examples, the power supply 111 may include one or more power storage components configured to supply power to one or more components when operating in the shutdown mode (such as when power is no longer received from an external device). In this way, the power supply 111 may be used as an on-vehicle backup power supply. Some examples of the one or more power storage components include, but are not limited to, capacitors, supercapacitors, batteries, etc. In some examples, the amount of electric power that may be stored by the one or more power storage components may be a function of the cost and / or size (e.g., area / volume) of the one or more power storage components. In other words, as the amount of electric power stored by the one or more power storage components increases, the cost and / or size of the one or more power storage components also increases.

[0035] The controller 108 may use the volatile memory 112 to store information. The volatile memory 112 may include one or more volatile memory devices. In some examples, the controller 108 may use the volatile memory 112 as a cache. For example, the controller 108 may store the cached information in the volatile memory 112 until the cached information is written to the NVM 110. As Figure 1As illustrated, the volatile memory 112 may consume the power received from the power supply 111. Examples of the volatile memory 112 include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static RAM (SRAM), and synchronous dynamic RAM (SDRAM) (e.g., DDR1, DDR2, DDR3, DDR3L, LPDDR3, DDR4, LPDDR4, etc.). Similarly, the optional DRAM 118 may be used to store mapping data, buffered commands, logical-to-physical (L2P) tables, metadata, cache data, etc. in the optional DRAM 118. In some examples, the data storage device 106 does not include the optional DRAM 118, such that the data storage device 106 is DRAM-less. In other examples, the data storage device 106 includes the optional DRAM 118.

[0036] The controller 108 may manage one or more operations of the data storage device 106. For example, the controller 108 may manage reading data from and / or writing data to the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 may initiate a data storage command to store the data in the NVM 110 and monitor the progress of the data storage command. The controller 108 may determine at least one operating characteristic of the storage system 100 and store the at least one operating characteristic in the NVM 110. In some embodiments, when the data storage device 106 receives a write command from the host device 104, the controller 108 temporarily stores the data in an internal memory or a write buffer 116 before transferring the data associated with the write command to the NVM 110.

[0037] The controller 108 may include an optional second volatile memory 120. The optional second volatile memory 120 may be similar to the volatile memory 112. For example, the optional second volatile memory 120 may be SRAM. The controller 108 may allocate a portion of the optional second volatile memory to the host device 104 as a controller memory buffer (CMB) 122. The CMB 122 may be directly accessed by the host device 104. For example, the host device 104 may utilize the CMB 122 to store one or more submission queues that are typically maintained in the host device 104, rather than maintaining one or more submission queues in the host device 104. In other words, the host device 104 may generate commands and store the generated commands (with or without associated data) in the CMB 122, where the controller 108 accesses the CMB 122 to retrieve the stored generated commands and / or associated data.

[0038] As discussed herein, ZNS utilizes regions in a memory device to store data. Traditional regions are very large and can be referred to as individual regions or stand-alone regions. A trend in the industry is emerging to utilize smaller regions, where the smaller regions can be grouped together to collectively reach the size of a traditional or stand-alone region. Such grouped-together smaller regions are referred to as region groups. An example of the smaller regions of a region group is a plane in a die of a memory device, while a stand-alone or individual region can include multiple dies. Thus, a region group can span multiple dies.

[0039] One way to handle the lack of region protection is to grade all incoming host-written region data in SLC. Then, after writing the entire region, the data is copied to QLC. In doing so, in the case of a block failure being hit when programming the data in QLC, the data can be recovered from SLC. This method is also effective for region groups, where the individual smaller regions of the region group are written to SLC and then copied to QLC only after the entire region group has been written to SLC. In either case, once the data is in QLC and valid, the SLC can be released and / or erased.

[0040] Figure 2 is a schematic diagram 200 of writing to a region in a ZNS environment according to one embodiment. As Figure 2 shown, incoming region data (whether it is a smaller region or an individual region) is demultiplexed into the SLC cache. Once all the data is in the SLC cache, the data is demultiplexed and written to QLC. Due to QLC 4-plane programming, the demultiplexing occurs for 4 full regions at a time. Optionally, the data in QLC can be verified. In any case, after all the data is written to QLC or after verification, the data no longer needs the SLC cache, and garbage collection of the SLC cache can be performed.

[0041] It is expected that data can be written to SLC and then copied to QLC. Alternatively, it is also expected that data can be written to SLC in parallel with writing to QLC. One of the copies of the data (usually the data written in SLC, but it can also be the data written in QLC) will be a temporary copy that can be used to protect the data written in another location. It is also expected that data can be written to other locations (such as MLC or even QLC) instead of writing to SLC. In any case, a set of data is temporary and is maintained until the data is written in two locations and verified in the permanent location. Once the data is valid in the permanent location, the temporary data can be discarded.

[0042] To protect the data and potentially recover the data from potential bit flips, parity data can be created for the incoming region data demultiplexed into SLC. As Figure 2As shown, parity data may be included in a die such as die 31. A temporary copy of the data in the SLC may be written across multiple planes / dies and is also protected by the parity data. In the case where data is first written to the SLC and then an error is encountered, the parity data may be used and the error may be corrected. More specifically, if an error occurs, the parity data is used to recover the data. Once there is no error, the data may be copied to the QLC. If there is an error when copying to the QLC, the copy stored in the SLC may be used to recover the data. In one embodiment, the parity data is XOR (exclusive OR) parity data. The parity data may be stored in the SLC together with the incoming region data that is multiplexed. In one embodiment, the parity data may be stored in a location separate from the SLC. In Figure 2 As can be seen in the embodiment shown, the region data is set in 31 dies, and separate dies are dedicated to the parity data. In one embodiment, the parity data is not written to the QLC. In another embodiment, the parity data is written to the QLC.

[0043] For small region ZNS, tiering all the region data in the SLC can utilize a large amount of SLC memory. For example, for every 1TB of 256 open regions, the size of the SLC cache must be determined based on the number of active regions of the drive plus some additional SLC capacity (OP). The reasons for determining the size and OP are because a certain amount of SLC garbage collection (GC) may occur. Even if each region is a single NAND QLC erase block, the number of blocks in the SLC cache for 32TB and 64TB ZNS drives means that the SLC cache size becomes huge.

[0044] One way to reduce the huge SLC cache is to use a region write group (ZWG) to assist the data storage device and the host device in data recovery. The ZNS will include a host region and a parity region. The data storage device controller receives an indication of damaged data associated with the ZNS, requests one or more buffers stored in the ZWG, and performs data recovery using the one or more buffers. This scenario involves releasing the ZWG data and parity blocks only after the host releases all the participating regions. More specifically, the use of the parity blocks is only temporary when the data is programmed, and later the parity blocks are released and the data is no longer protected. This scenario may be a significant drawback because the host may release these regions independently, but the recycled space cannot be utilized until the last region is released.

[0045] One proposal for reducing the SLC cache size is to keep only the last few WLs programmed to each region in the SLC, which should allow recovery of failures limited to the last few WLs, but not block-level failures. In many NAND generations, the individual block-level failures can reach an UBER of 1e -12 with an UBER that is too high and does not meet the 1e -14 requirement. Thus, due to the high UBER, additional SLC cache for the entire region is not needed as it remains a problem even in the case of SLC cache block-level failures. Caching only the last few word lines (including the last word line) will save a significant amount of SLC cache, enabling the SLC cache size to be reduced.

[0046] As discussed herein, a dual approach can be used to protect data. The first branch of the dual approach is to use temporary parity for data written as region groups, which will eliminate and / or reduce the SLC cache size. As mentioned above, a region group is multiple regions written simultaneously to achieve a specific minimum write performance (e.g., 100 MB / s). Region groups can be used in systems that allow direct writes to QLC blocks (such as MLC / FN programming schemes), or in systems that require data staging through the SLC (such as in FG / FN programming schemes). However, with the first branch approach, block-level failures can be recovered even if only a limited portion of the regions in the SLC area are kept as required by FG / FN staging.

[0047] The second branch of the dual approach is to stage the entire region data of independent regions through the SLC cache. If there is no minimum performance requirement (i.e., writing a single NAND erase block will only provide, for example, 6 MB / s to 7 MB / s) and the application does not expect to write data in region group amounts immediately, then independent regions can be written. Assume that the number of required independent open regions is significantly lower than the total number of open regions, and thus the SLC cache size is reduced proportionally to that number.

[0048] Keeping parity (e.g., XOR parity) within parity stripes (i.e., giant blocks) until all data is invalidated and released will not work properly for region groups because regions (i.e., each plane block) can be released independently at different times, which will cause garbage collection (GC). GC is the opposite of ZNS which is designed to eliminate GC.

[0049] Therefore, for host data written as a region group, the SSD will create temporary parity stripes. For example, if there is a region group of 15 regions (which will achieve a write performance of approximately 100 MB / s), the SSD will write 1 additional erase block as parity. In other words, there will be a 15 + 1 plane stripe. Then, the parity block is released immediately after the entire region group has been fully written. Optionally, data verification such as enhanced post-write read (EPWR) checks can be performed. In the case of any programming failures that occur while filling the region group, even if an entire erase block fails, the parity block will be used to recover the lost data, which provides the required UBER protection (i.e., equivalent to a large SLC cache data path).

[0050] Figure 3 is a schematic diagram 300 of writing to a region in a ZNS environment according to another embodiment. In Figure 3 , the region group data is written directly to the QLC block and not tiered in the SLC cache. However, as performed in the embodiment of Figure 2 , individual regions are tiered through the SLC cache. For individual regions, similar to Figure 2 , the expected data can be written to the SLC as a temporary copy and then copied to the QLC as a permanent copy. Alternatively, it is also expected that data can be written to the SLC in parallel with writing to the QLC. One of the copies of the data (usually the data written in the SLC, but it can also be the data written in the QLC) will be the temporary copy that can be used to protect the permanent data written in another location. It is also expected that the temporary data can be written to a different location (such as MLC or even QLC) instead of writing to the SLC. In any case, a set of data is temporary and is maintained until the data is written in two locations and verified in the permanent location. Once the data is valid in the permanent location, the temporary data can be discarded.

[0051] To protect the data and potentially recover the data from potential bit flips, parity data can be created for the incoming region data that is multiplexed into the SLC. The temporary copies of the data in the SLC can be written across multiple planes / dies and are also protected by the parity data. In the case where the data is first written to the SLC and then an error is encountered, the parity data can be used and the error can be corrected. More specifically, if an error occurs, the parity data is used to recover the data. Once there is no error, the data can be copied to the QLC. If there is an error when copying to the QLC, the copy stored in the SLC can be used to recover the data. In one embodiment, the parity data is XOR (exclusive OR) parity data.

[0052] For a region group, there are 16 small regions for illustration, where 15 small regions are user data and 1 small region is parity data. It should be noted that the 16 small regions are only examples. The number of small regions is not limited to 16. The region group and parity data are simultaneously written to the QLC in 4-plane programming. For individual regions, the data is tiered through the SLC cache by multiplexing the data into the SLC cache and parity locations (die 31 in this example). Then these regions are demultiplexed and written to the QLC in 4-plane programming. It should be noted that in the Figure 3 example, the parity data from individual regions is not copied to the QLC. The parity data can be retained in the SLC or even stored in a location separate from the SLC and QLC. The region group can be considered similar to a giant block with blocks written in parallel, but these blocks are independent. Parity can be created for such a giant block.

[0053] The overhead for storing temporary parity for open region groups is minimal. For example, on a 64TB ZNS drive, it will have approximately 16k open regions, and then 15 region groups, which will be approximately 1K open region groups. Therefore, in a 64TB drive with 1M blocks, the parity overhead will be approximately 1K blocks, which is only a 0.1% capacity overhead.

[0054] Although Figure 3 shows a region group written directly to the QLC where the parity data is maintained in the QLC in the plane blocks within the region group, this arrangement is not the only option. The parity data does not have to be maintained in the QLC but can be kept in the SLC. Additionally, the parity data for the region group does not need to be part of the region group.

[0055] It should be noted that the data storage device can support both region groups and individual regions. The controller of the data storage device can notify the host device of the threshold amounts of space allocated to the region groups and individual regions. When the threshold is reached (e.g., the threshold of the region group is reached), the host device will have to switch to another (e.g., individual regions) for writing.

[0056] Figure 4FIG. 400 is a flow chart illustrating a method of writing to a region in a ZNS environment according to one embodiment. The method begins by receiving a host command to write in the ZNS environment at 402. Then, at 404, the controller of the data storage device determines whether the write is for a region group or for an individual region. If the write is for an individual region, it is determined at 405 whether an individual region threshold has been reached. If the threshold has been reached, at 422, the controller rejects individual region creation and notifies the host device. If the threshold has not been reached, the data is written to the SLC cache at 406. Parity data is also created and may be stored in the SLC cache or some other location. Then it is determined at 408 whether all the data has been written to the SLC cache. If there is more data to write, the method loops back to 406. If all the data has been written, the data is written to the QLC at 412. It should be noted that the data can be written to the SLC and QLC in parallel or serially. If the data is written serially, the data is first written to the SLC, as Figure 4 shown, and parity data is created to protect the data written to the SLC. Once the data is valid, the data in the SLC is copied to the QLC. Then the SLC data can be discarded because the SLC data is only temporary in serial writing. If the data is written to the SLC and QLC in parallel, the parity data may not be included with the SLC data. The point is that in the case of an individual region, there are two data sets, a temporary data set and a permanent data set. The temporary data set is the SLC data, and the permanent data is the QLC data. It is determined at 414 whether there are any errors. If there are no errors, the SLC cache can be released at 418. If there are errors, the data can be recovered from the SLC at 416 and then checked again at 414 to confirm that there are no errors.

[0057] If the write is for a region group, it is determined at 420 whether a region group threshold has been reached. If the threshold has been reached, at 422, the controller rejects region group creation and notifies the host device. If the threshold has not been reached, a region group with multiple small regions is created at 424. The first set of small regions is written directly to the QLC at 426, and then the second set of small regions is written to the SLC at 428. Then the second set of small regions is written to the QLC at 430, and the method continues to 412. The first set of small regions includes user data. The second set of small regions may include some user data as well as parity data and / or the last few word lines of the user data. If the last few word lines of the user data are stored in the SLC, at least the last word line of the user data is stored in the SLC to assist in data recovery.

[0058] By leveraging the parity data of a region group, a desired UBER is achieved while enabling at least partial data recovery. Additionally, writing most user data directly to MLC while writing only a small portion of user data (specifically, at least the last word line of the user data) to SLC reduces the SLC cache. The embodiments discussed herein will significantly reduce the SLC cache size (and achieve cost / margin) because the total number of open regions requiring SLC tiering is significantly reduced (assuming most host writes are using region groups).

[0059] In one embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command for one or more regions in a zoned namespace (ZNS) environment of the memory device; determine whether the write command is to write data to an independent region or a small region of a region group; generate parity data for user data corresponding to the write command; and store the parity data. The controller is configured to determine that the write command is to write data to the region group. The controller is configured to determine whether a region group threshold has been reached. The controller is configured to directly write a first portion of the user data to a multi-level cell (MLC) memory. The controller is configured to write a second portion of the user data to a single-level cell (SLC) memory. The controller is further configured to at least partially recover data to achieve an uncorrectable bit error rate (UBER) below a predetermined threshold. The controller is configured to store the parity data in a single-level cell (SLC) memory or a quad-level cell (QLC) memory. The controller is configured to store the parity data in a location separate from one or more regions. The controller is configured to determine that the write command is to write data to the independent region. The controller is configured to store all data in a single-level cell (SLC) memory and copy the data from the SLC memory to a multi-level cell (MLC) memory after all data has been written to the SLC memory. The controller is configured to provide the region group threshold to a host device. The parity data is exclusive-or (XOR) parity data.

[0060] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: receive a write command to write user data to a plurality of small regions in a region group of a partitioned namespace (ZNS) environment; write a first portion of the user data to at least one first small region of the plurality of small regions, wherein the first portion is written in a multi-level cell (MLC) memory of the memory device; write a second portion of the user data to at least one second small region of the plurality of small regions, wherein the second portion is written in a single-level cell (SLC) memory of the memory device, wherein the second portion is less than all of the user data. The first portion is not written to the SLC memory. Copy the second portion to the MLC memory. Erase the second portion from the SLC memory after it is copied to the MLC memory. The second portion includes parity data.

[0061] In another embodiment, a data storage device includes: a memory component; and a controller coupled to the memory component, wherein the controller is configured to: receive a write command to write user data to a plurality of small regions in a region group of a partitioned namespace (ZNS) environment of the memory component; allocate a plurality of small regions for the user data; allocate additional storage locations for parity data; write the user data to the plurality of small regions, wherein at least a first small region of the plurality of small regions is provided in a single-level cell (SLC) of the memory component, and at least a second small region of the plurality of small regions is provided in a multi-level cell (MLC) of the memory component; and write the parity data in an additional region. The additional region is stored in a location separate from the SLC and the MLC. The controller is further configured to demultiplex the user data in the first small region and write the user data from the first small region in the MLC.

[0062] In another embodiment, a data storage device having a small SLC cache and utilizing a dual temporary data protection method includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: temporarily store XOR parity data of a plurality of open region groups in the memory, and store another temporary copy of independent region user data without XOR parity in the small SLC cache or MLC. The controller is configured to evict the independent region data from the SLC cache memory to a multi-level cell (MLC) memory. The controller is further configured to close the region group upon completion of a write command to the region group, and is configured to release the XOR parity of the region group. The controller is further configured to use the region group XOR parity to at least partially recover data when the region group is open to achieve an uncorrectable bit error rate (UBER) below a predetermined threshold. The controller is further configured to write the region group data directly to a multi-level cell (MLC) memory. In the case of QLC programming using a two-level fuzzy-fine scheme, the controller is further configured to grade a small amount of rolling WL data in the SLC cache or volatile memory temporarily for the fine programming level. The controller is configured to store the XOR parity data in a location separate from the plurality of region groups or in an additional block that is part of the region group. The maximum number of open region groups and independent regions managed by the controller simultaneously is predetermined.

[0063] In another embodiment, a data storage device includes: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: open a region within an independent region or a region group based on a command received from a host device; and write to the region within the independent region or the region group. The controller is configured to allow a first predetermined number of independent regions and a second predetermined number of region groups. The first predetermined number is less than the second predetermined number. The controller is configured to notify the host device of the size of the region group. The controller is configured to notify the host device of the number of open regions supported for the region group. The controller is configured to notify the host device of the number of open regions supported for the independent region. The controller is configured to store the XOR (exclusive OR) parity data of the region group in the memory device. The controller is configured to store independent region user data without XOR (exclusive OR) parity in a single-level cell (SLC) cache. The controller is configured to write to the multi-level cell (MLC) of the memory device.

[0064] In another embodiment, a data storage device includes: a component for storing data; and a controller coupled to the component for storing data, wherein the controller is configured to: allocate a first predetermined amount of the component for storing data for an independent region; and allocate a second predetermined amount of the component for storing data for a region group, wherein the second predetermined amount is greater than the first predetermined amount. The controller is further configured to at least partially recover data to achieve an uncorrectable bit error rate (UBER) below a predetermined threshold. The controller is configured to store parity data in a location separate from user data.

[0065] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope of the invention is determined by the appended claims.

Claims

1. A data storage device having a small SLC cache and utilizing a dual temporary data protection method, the data storage device comprising: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: temporarily store exclusive OR (XOR) parity data of a plurality of open region groups in the memory; and store another temporary copy of user data of independent regions without XOR parity in a small SLC cache or MLC.

2. The data storage device according to claim 1, wherein the controller is configured to evict independent region data from the small SLC cache to a multi-level cell (MLC) memory.

3. The data storage device according to claim 2, wherein the controller is further configured to close an open region group upon completion of a write command to the region group, and is configured to release the XOR parity of the region group.

4. The data storage device according to claim 3, wherein the controller is further configured to use the region group XOR parity to at least partially recover data when the region group is open, to achieve an uncorrectable bit error rate (UBER) below a predetermined threshold.

5. The data storage device according to claim 3, wherein the controller is further configured to write region group data directly to a multi-level cell (MLC) memory.

6. The data storage device according to claim 5, wherein in the case of QLC programming using a two-level fuzzy-fine scheme, the controller is further configured to grade a small amount of rolling WL data in the SLC cache or volatile memory temporarily for the fine programming level.

7. The data storage device according to claim 3, wherein the controller is configured to store the XOR parity data at a location separate from the plurality of open region groups or within an additional block that is part of the region group.

8. The data storage device according to claim 3, wherein the maximum number of open region groups and independent regions managed by the controller simultaneously is predetermined.

9. A data storage device, the data storage device comprising: a memory device; and a controller coupled to the memory device, wherein the controller is configured to: open a region within an independent region or a region group based on a command received from a host device; and write to the region within the independent region or the region group.

10. The data storage device according to claim 9, wherein the controller is configured to allow a first predetermined number of independent regions and a second predetermined number of region groups.

11. The data storage device according to claim 10, wherein the first predetermined number is less than the second predetermined number.

12. The data storage device according to claim 9, wherein the controller is configured to notify the host device of the size of the region group.

13. The data storage device according to claim 12, wherein the controller is configured to notify the host device of the number of open regions supported for the region group.

14. The data storage device according to claim 13, wherein the controller is configured to notify the host device of the number of open regions supported for the independent region.

15. The data storage device according to claim 9, wherein the controller is configured to store exclusive-or (XOR) parity data of the region group in the memory device.

16. The data storage device according to claim 9, wherein the controller is configured to store independent region user data without exclusive-or (XOR) parity in a single-level cell (SLC) cache.

17. The data storage device according to claim 9, wherein the controller is configured to write to multi-level cells (MLCs) of the memory device.

18. A data storage device, the data storage device comprising: means for storing data; and a controller coupled to the means for storing data, wherein the controller is configured to: allocate a first predetermined amount of the means for storing data for an independent region; and allocate a second predetermined amount of the means for storing data for a region group, wherein the second predetermined amount is greater than the first predetermined amount.

19. The data storage device according to claim 18, wherein the controller is further configured to at least partially recover data to achieve an uncorrectable bit error rate (UBER) below a predetermined threshold.

20. The data storage device according to claim 18, wherein the controller is configured to store parity data in a location separate from the user data.

Images