DEVICE TO ENABLE THE PROTECTED MSETS TO BE REUSED DURING CONTROL SYNC (CS) BASED ON A SHADOW ULAYER

Abstract

The mechanism for restoring protected segments (mSets) at runtime or after a rough shutdown (UGSD), such as in the case of a host memory buffer failure (HMB failure), uses a shadow structure (e.g., a shadow update layer (uLayer)) stored in the storage device (e.g., flash) within an mBlock and used solely for restoring protected mSets. This approach also allows for a significant increase in the number of protected mSets because the proposed shadow uLayer structure avoids flushing all protected mSets during Control Sync (CS). The expected performance improvements and reduction in control data write gain outweigh the additional overhead of handling the shadow structure.

Description

BACKGROUND OF REVELATION Area of ​​Revelation

[0001] Embodiments of the present disclosure generally relate to the improvement of the use of storage devices. Description of the state of the art

[0002] Storage devices use a logic-physical mapping (L2P mapping) and employ management tables containing control data for dynamic mapping. The management tables are stored in flash memory (e.g., NAND), but for efficient management, copies are retained in the controller's random-access memory (RAM). Modern devices feature a two-tier mapping architecture consisting of a master layer (mLayer) and an update layer (uLayer). The mLayer is relatively large and has a regular structure (direct-access array). The uLayer is much smaller and has a less regular structure. The mapping of the same range of logical block addresses (LBA range) can have different sizes at different times.

[0003] The mLayer can be easily divided into equal segments (mSets) that are stored in flash memory and can be loaded from flash memory (i.e., swapped out and reinserted) as needed. Devices with limited RAM have a limited amount of RAM and therefore retain uLayer units of a fixed size, independent of the device capacity. The uLayer contains the most recent mapping in the form of regions that allow only a portion of the uLayer, called the update region (uRegion), to be scanned during consolidation or translation. The purpose of the uLayer is to aggregate multiple control updates for the same uRegion with N mSets per uRegion, including the consolidation of captured uRegions. Each uRegion has an update header (uHeader) that contains the number of entries (uRun) in the uRegion and other information for the entire uRegion.

[0004] In cases of random write (RW), the uLayer overflows relatively quickly, leading to the consolidation of uLayer updates with mSets (e.g., mLayer). Therefore, good RW performance can be achieved as a compromise between the number of accumulations of the latest updates in the uLayer and the number of mSets stored in flash.

[0005] Write-through performance is limited by the CPU. The mSet used for consolidation in RAM contains all mappings, and the uLayer does not contain any of its uRuns. Therefore, all such mSets are saved to flash during / before Control Sync (CS). Thus, skipping uLayer updates, delaying writes to flash, and reducing the consolidation scope should improve write-through performance and write amplification (WAMP). However, on devices with limited RAM, the number of cached mSets is limited, so performance improvements may only be seen in tight write-through tests.

[0006] To improve read / write performance and latency for large-area tests, it can be helpful to create protected mSets for consolidation in the Host Memory Buffer (HMB). This is because such mSets contain all mappings, and the uLayer does not contain any of its uRuns. This allows uLayer updates to be skipped. However, the ability to restore HMB-protected mSets in case of failure (e.g., HMB disabling errors, PCI bus errors, etc.) is valuable, as the protected mSets should be restored for consolidation in the event of an HMB failure.

[0007] Therefore, in engineering, there is a need for efficient restoration of protected mSets. SUMMARY OF THE REVELATION

[0008] The mechanism for restoring protected segments (mSets) at runtime or after a rough shutdown (UGSD), such as in the case of a host memory buffer failure (HMB failure), uses a shadow structure (e.g., a shadow update layer (uLayer)) stored in the storage device (e.g., flash) within an mBlock and used solely for restoring protected mSets. This approach also allows for a significant increase in the number of protected mSets because the proposed shadow uLayer structure avoids flushing all protected mSets during Control Sync (CS). The expected performance improvements and reduction in control data write gain outweigh the additional overhead of handling the shadow structure.

[0009] In one embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: manage an update layer (uLayer), wherein the uLayer is configured to manage updates for unprotected segments (mSets), with unprotected mSets remaining in random access memory (RAM) until a control sync (CS) operation; and manage a shadow uLayer, wherein the shadow uLayer is configured to manage updates for protected mSets, with protected mSets being stored in the storage device after consolidation.

[0010] In another embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: perform an ungraceful shutdown (UGSD) operation; power on the device; detect that a UGSD event has occurred; and perform a UGSD mount operation, the UGSD mount operation comprising loading valid uSlices from the storage device into random-access memory, wherein uSlices are parts of a shadow update layer (uLayer), and wherein the shadow uLayer is configured to manage updates for protected RAM segments (mSets), and wherein protected mSets are stored in the storage device after consolidation.

[0011] In another embodiment, a data storage device comprises: means for storing data; and a controller coupled to the means for storing data, wherein the controller is configured to: manage both an update layer (uLayer) and a shadow uLayer, wherein the uLayer corresponds to the unprotected segments (mSets) stored in random-access memory (RAM) and the shadow uLayer corresponds to the protected mSets; selectively store portions of the shadow uLayer (uSlices) in the means for storing data; and invalidate uSlices when storing protected mSets in the means for storing data. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] In order to understand in detail the nature of the aforementioned features of the present disclosure, a more precise description of the disclosure, which has been briefly summarized above, can be given with reference to embodiments, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings only illustrate typical embodiments of this disclosure and are therefore not to be considered as limiting in its scope of protection, since the disclosure also permits other, equally effective embodiments. Fig. Figure 1 is a schematic block diagram illustrating a storage system in which a data storage device can function as a storage device for a host device according to certain embodiments. Fig. Figure 2 is a schematic illustration of SAT main components according to one embodiment. Fig. Figure 3 is a schematic illustration of a uLayer structure with shadow headers according to one embodiment. Fig. Figure 4 is a schematic illustration of a uLayer and Shadow uLayer design according to one embodiment. Fig. Figure 5 is a schematic illustration of a uLayer according to one embodiment. Fig. Figure 6 is a schematic illustration of a Shadow-uLayer according to one embodiment. Fig. Figure 7 is a schematic illustration of a uLayer and Shadow uLayer design according to another embodiment. Fig. Figure 8 is a flowchart of a process according to one embodiment.

[0013] To facilitate understanding, identical reference numerals have been used wherever possible to denote identical elements present in all figures. It is intended that elements disclosed in one embodiment may also be used effectively in other embodiments without specific mention. DETAILED DESCRIPTION

[0014] The following refers to embodiments of the disclosure. It is understood, however, that the disclosure is not limited to the specific embodiments described. Instead, any combination of the following features and elements, regardless of whether they relate to different embodiments or not, is intended for the implementation and practical application of the disclosure. Furthermore, although embodiments of the disclosure may offer advantages over other possible solutions and / or over the prior art, the fact that a particular embodiment achieves a specific advantage or not does not constitute a limitation of the disclosure.Therefore, the following aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly stated in one or more claims. Likewise, a reference to "the disclosure" is not to be construed as a generalization of any inventive subject matter disclosed herein and is not to be considered an element or limitation of the appended claims unless expressly stated in one or more claims.

[0015] The mechanism for restoring protected segments (mSets), which are protected in some cases and unprotected in others, at runtime or after an unclean shutdown (UGSD), such as in the case of a host memory buffer failure (HMB failure), uses a shadow structure (e.g., a shadow update layer (uLayer)) stored in the storage device (e.g., flash) in an mBlock and used only for restoring protected mSets. This approach also allows for a significant increase in the number of protected mSets because the proposed shadow uLayer structure avoids flushing all protected mSets during Control Sync (CS). The expected performance improvements and reduction in control data write gain outweigh the additional overhead of handling the shadow structure.

[0016] Fig. Figure 1 is a schematic block diagram illustrating a storage system 100 comprising a data storage device 106, which, according to certain embodiments, can function as a storage device for a host device 104. For example, the host device 104 can use non-volatile memory (NVM) 110 enclosed in the data storage device 106 for storing and retrieving data. The host device 104 includes dynamic random-access memory (DRAM) 138. In some examples, the storage system 100 can include a variety of storage devices, such as the data storage device 106, which can function as a storage array.For example, the storage system 100 can include a variety of data storage devices 106 configured as a redundant array of inexpensive / independent disks (RAID) and acting collectively as a mass storage device for the host device 104.

[0017] The host device 104 can store data on and / or retrieve data from one or more storage devices, such as the data storage device 106. As described in Fig. As illustrated in Figure 1, the host device 104 can communicate with the data storage device 106 via an interface 114. The host device 104 can include a wide range of devices, including computer servers, network-attached storage (NAS) units, desktop computers, notebooks (i.e., laptops), tablet computers, set-top boxes, mobile phones such as smartphones or smart tablets, televisions, cameras, display devices, digital media players, video game consoles, video streaming devices, or other devices that can send data to or receive data from a data storage device.

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

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

[0020] Interface 114 can include a data bus for data exchange with the host device 104 and / or a control bus for exchanging commands with the host device 104. Interface 114 can operate according to any suitable protocol. For example, interface 114 can 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), Serially Attached SCSI (SAS), PCI and PCIe, Non-Volatile Memory Express (NVMe), OpenCAPI, GenZ, Cache Coherent Interface Accelerator (CCIX), Open Channel SSD (OCSSD), or the like. Interface 114 (e.g.,The data bus, the control bus, or both) is electrically connected to the controller 108 and provides an electrical connection between the host device 104 and the controller 108, allowing data to be exchanged between the host device 104 and the controller 108. In some examples, the electrical connection of the interface 114 can also allow the data storage device 106 to receive power from the host device 104. For example, in... Fig. As illustrated in Figure 1, the power supply 111 can receive power from the host device 104 via the interface 114.

[0021] The NVM 110 can include a variety of storage devices or storage units. The NVM 110 can be configured to store and / or retrieve data. For example, a storage unit of the NVM 110 can receive data and a message from the controller 108 instructing the storage unit to store the data. Likewise, the storage unit can receive a message from the controller 108 instructing the storage unit to retrieve data. In some examples, each of the storage units can be referred to as a chip. In some examples, the NVM 110 can include a variety of chips (i.e., a variety of storage units). In some examples, each storage unit can be configured to store relatively large amounts 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.).

[0022] In some examples, each storage unit can include any type of non-volatile storage device, such as flash memory devices, phase-change memory (PCM), resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), holographic storage devices, and any other type of non-volatile storage device.

[0023] The NVM 110 can incorporate a variety of flash memory devices or storage units. NVM flash memory devices can include NAND- or NOR-based flash memory devices and can store data based on a charge contained in a floating gate of a transistor for each flash memory cell. In NVM flash memory devices, the flash memory device can be subdivided into a variety of dies, with each die containing a variety of physical or logical blocks, which can be further subdivided into a variety of pages. Each block within a given memory device can contain a variety of NVM cells. Rows of NVM cells can be electrically connected using a word line to define a page within a variety of pages.The individual cells in each of the multitude of pages can be electrically connected to the respective bit lines. Furthermore, NVM flash storage devices can be 2D or 3D devices and can be of the single-level cell (SLC), multi-level cell (MLC), triple-level cell (TLC), or quad-level cell (QLC) type. The controller 108 can write and read data to and from NVM flash storage devices at the page level and erase data from NVM flash storage devices at the block level.

[0024] The power supply 111 can power one or more components of the data storage device 106. In standard mode, the power supply 111 can power one or more components by drawing power from an external device, such as the host device 104. For example, the power supply 111 can power the one or more components by using power received from the host device 104 via interface 114. In some examples, the power supply 111 can include one or more power storage components configured to power the one or more components when they are in shutdown mode, such as when no power is being received from the external device. In this way, the power supply 111 can function as an integrated backup power source.Examples of one or more energy storage components include capacitors, supercapacitors, batteries, and the like. In some cases, the amount of electricity that can be stored by one or more energy storage components may depend on the cost and / or size (e.g., area / volume) of the one or more energy storage components. In other words, as the amount of electricity stored by one or more energy storage components increases, so do the cost and / or size of the one or more energy storage components.

[0025] The volatile memory 112 can be used by the controller 108 to store information. The volatile memory 112 can include one or more volatile storage devices. In some examples, the controller 108 can use the volatile memory 112 as a cache. For example, the controller 108 can store cached information in the volatile memory 112 until the cached information is written to the NVM 110. As in Fig. As illustrated in Figure 1, the volatile memory 112 can consume power received from the power supply 111. Examples of 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, and the like)). Likewise, the optional DRAM 118 can be used to store mapping data, buffered instructions, logic-physical (L2P) tables, metadata, cached data, and the like. In some examples, the data storage device 106 does not include the optional DRAM 118, so the data storage device 106 has no DRAM. In other examples, the data storage device 106 includes the optional DRAM 118.

[0026] The controller 108 can manage one or more operations of the data storage device 106. For example, the controller 108 can 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 can initiate a data storage command to store data in the NVM 110 and monitor the progress of the data storage command. The controller 108 can determine at least one operating property of the storage system 100 and store at least one operating property 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 associated with the write command in internal memory or write buffer 116 before sending the data to the NVM 110.The controller 108 can include switching logic or processors configured to run programs to operate the data storage device 106.

[0027] The controller 108 can include an optional second volatile memory 120. The optional second volatile memory 120 can be similar to the volatile memory 112. For example, the optional second volatile memory 120 can be SRAM. The controller 108 can allocate a portion of the optional second volatile memory to the host device 104 as a control memory buffer (CMB) 122. The CMB 122 can be accessed directly by the host device 104. For example, instead of managing one or more transmission queues in the host device 104, the host device 104 can use the CMB 122 to store the one or more transmission queues that are normally managed in the host device 104.In other words, the host device 104 can generate commands and store the generated commands with or without the associated data in the CMB 122, with the controller 108 accessing the CMB 122 to retrieve the stored generated commands and / or the associated data.

[0028] Fig. Figure 2 is a schematic illustration of 200 SAT main components according to one embodiment. Fig. Figure 3 is a schematic illustration of a uLayer structure with shadow headers according to one embodiment. As discussed herein, the disclosure involves accumulating all updates for protected mSets in the HMB in a new uLayer shadow structure for eventual HMB restoration at runtime or after a UGSD. The uLayer shadow structure is managed as described below.

[0029] The Shadow uLayer structure is implemented as in Fig. 3 shown, subdivided into uSlices. All protected mSets in the HMB back up all updates to uSlice buffers according to #uSlice. Each uSlice should be backed up in the main blocks of the storage device (mBlocks) in the event of a uLayer overflow (no elements). Each uSlice could be backed up to X times (where x is a predetermined integer) until all protected mSets are consolidated.

[0030] Since all required uLayer mappings of protected mSets are stored in a shadow uLayer structure, the following features can be implemented. If the protected mSet was created in CAT SRAM, it must be saved to flash memory at CS or before being transferred to HMB. If the protected mSet was created in CAT HMB, saving to flash memory is not required before transferring to HMB. Consolidating protected mSets in CAT HMB before / at CS is not mandatory, and it is preferable to save a predetermined number. Saving a uSlice to release elements from the element pool may also be preferable. The shadow uLayer structure improves accumulation in the uLayer, thereby reducing the WAMP required to save mSets to flash memory. The uLayer header and shadow uLayer header structures should be unified and use the same element memory pool.

[0031] The key difference between uLayer and Shadow-uLayer is as follows: Shadow-uLayer is used solely for mSet HMB recovery. The Shadow-uLayer structure is updated only in the HMB during each update to a protected mSet.

[0032] In this way, the FTL can, for example, create 1024 protected mSets in an HMB with a shadow uLayer, and there is no need to flush all protected mSets on CS or during a graceful shutdown (GSD). The proposed mechanism allows, for example, flushing 10% of the protected mSets on CS, saving uSlices to flash memory with other updates if needed, and saving uLayer with shadow headers in the log.

[0033] It should be noted that the implementations described herein are not limited to HMB. Rather, other memory types such as DRAM are also considered. Additionally, the number of protected mSets is limited only by the GSD time and also in DRAM projects, but the shadow uLayer and recovery after a GSD can eliminate this limitation.

[0034] The restoration of the protected mSet in HMB is now handled. The process includes the following: During runtime, the mSet and the relevant uSlice are loaded from flash memory and merged from the uSlice to form the mSet. The protected mSet is then cleared by a standard trigger. After a UGSD (Unprotected Storage Device), the mSet and several relevant uSlices are loaded from flash memory and merged from the uSlices to form the mSet. The protected mSet is then cleared by a standard trigger.

[0035] The following is an example of a preliminary calculation for a workload of 128 mSets. The uLayer has approximately 20 KB of uRuns; for example, the SLC block size in the FMU is 200 KB. Therefore, the uLayer is consolidated 10 times between two CS operations, and each mSet accumulates a maximum of 400 uRuns (including triangular distribution) before consolidation, resulting in approximately 500 mSets (32 KB) for consolidation. With 4 uSlices (32 KB = 4 KB entries), this results in 200 KB / 4 KB entries = 50 uSlices (32 KB) of flash memory savings. The limitations are that the number of protected mSets without using the shadow uLayer is limited by the GSD time, as all protected mSets must be backed up to both GSD and CS. The number of protected mSets with a Shadow-uLayer could be significantly increased, improving RW and read performance, especially in cases with mixed RW / Random Read (RR).However, the number is limited by the recovery time for protected mSets in a UGSD. This limitation could be resolved as a delicate compromise between storing mSets (flush) and storing uSlices.

[0036] To improve read / write performance and latency for large-area tests, creating protected mSets for the entire random-area test in DRAM / HMB can be helpful, as such mSets contain all mappings and the uLayer does not contain any of its uRuns. However, all protected mSets are saved at a GSD and at each CS, resulting in high latency during CS, performance degradation during CS, and timeouts at GSD. The implementations discussed here can solve the aforementioned problems and additionally provide, as part of the algorithm, HMB-protected mSet recovery in case of HMB failures (e.g., HMB disabling errors, PCI bus errors, etc.). This approach virtually increases the size of the uLayer because the shadow uLayer (latest updates) is cleared by uSlices (minimal write unit) in mBlock, while simultaneously reducing the number of mSet consolidations (i.e., by clearing mSets in NAND).The virtual increase in uLayer size is determined by the number of valid uSlices in the mBlock, which is limited by the recovery time of the protected mSets after a GSD / UGSD.

[0037] Fig. Figure 4 is a schematic illustration of a uLayer and Shadow-uLayer design according to one embodiment. As shown in Figure 400, the uLayer and the Shadow-uLayer use a common element pool and mBlocks. The Shadow-uLayer structure is only for protected mSets, and there is no translation. Emptying the uSlice is done by copying elements into a CAT slot. As a configuration example, the uSlice covers 4 uRegions, and the maximum number of valid uSlices in an mBlock is 8. The Shadow-uLayer contains headers / copy headers and 128 uSlices with elements from the element pool. The uLayer contains headers / copy headers and 512 uRegions with elements from the element pool. In the mBlock, only the last written mSet is valid.

[0038] For clarification, it is noted that this disclosure concerns the Flash Translation Layer (FTL). The uLayer and the mLayer, in which the uLayer stores the latest mapping updates, are limited in size and reside entirely in RAM. The mLayer, on the other hand, stores the entire mapping of the data storage device and is usually the most up-to-date, except for the very latest updates, which reside in the uLayer. The uLayer is responsible for mapping until consolidation.

[0039] During consolidation, a portion of the accumulated uLayer mapping is merged with the relevant mSets, and the merged mapping is deleted from the uLayer. At this point, the mSets responsible for the merged mapping are stored in the storage device (e.g., NAND). This means that unprotected mSets are stored in the storage device (e.g., NAND) immediately after consolidation. Protected mSets remain in RAM until consolidation (CS). At CS, the protected mSets must be stored in the storage device (e.g., NAND). The reason for this is to prevent the uLayer from being updated with the mapping, which can be updated in the mSets. The uLayer remains unupdated for the protected mSets.The disadvantage is that with CS, all protected mSets are stored in the storage device, and if there are many of them, this can take a long time and lead to increased write gain and latency. Therefore, the number of protected mSets may be limited, even though it would be advantageous to increase the number of protected mSets.

[0040] In other words, the uLayer is responsible for mapping until consolidation. The uLayer is stored in the NAND flash memory during consolidation (CS). Consolidation merges some of the accumulated uLayer mappings with the relevant mSets and deletes the merged mapping units in the uLayer. After consolidation, the mSets are responsible for mapping and must be stored in the NAND flash memory. Ordinary (unprotected) mSets are stored in the NAND flash memory immediately after consolidation. Protected mSets remain in RAM until CS, after which they are stored in the NAND flash memory. This delayed storage of protected mSets prevents the uLayer from being updated with the new mapping to these mSets between consolidation and CS. The disadvantage is that all protected mSets are lost on the storage device (e.g., RAM) at CS.NAND) must be stored, which makes the CS operation too long, impairs the write gain and latency of the device, and ultimately limits the number of protected mSets to a relatively small number.

[0041] In Fig. 4 applies to blocks 410 - 470: Block 410: uLayer and Shadow-uLayer use a common element pool and mBlocks and are managed uniformly. Block 420: - Shadow-uLayer only contains updates for protected mSets - Up to 64 (TBD) uSlices and mSets can be cleared at CS - Shadow headers are fully stored in CS, just like uLayer headers. Block 430: - The copy of the headers reflects the state at the beginning of CS. - The headers and content can be updated during CS. Block 440: Example of configuration 1. uSlice covers 16 (TBD) sRegions 2. Max. number of valid uSlices in mBlock 8 (TBD) Block 450: Each uSlice contains an array of stored sRegion headers and a copy of the elements for each stored sRegion. Block 460: uLayer for updating, translating and consolidating mSets (no changes) Block 470: uLayer contains header / copy header, 512 uRegions with ultem from element pool. Only the last written mSet #X is valid in the mBlock.

[0042] Fig. Figure 5 is a schematic illustration of a uLayer according to one embodiment. Regarding the main uLayer: the main uLayer stores updates only for unprotected mSets; is searched for translation; is fully saved at CS; the copy of the headers reflects the state at the start of CS and allows recovery after a UGSD; the headers and content can be updated during CS; if no free elements are available, some regions can be freed after their mSets have been consolidated and stored in the NAND; and at UGSD mount, it is loaded as is, with the headers replaced by their copies created at the start of CS.

[0043] As in Fig. As shown in Figure 5, the main uLayer is divided into regions. In this example, there are approximately 512 regions, numbered zero through 511. There are two headers: the main header and a copy. The copy is used during Compilation Processing (CSS). The rest of the uLayer is a mapping that can be associated with different mSets, but each region has several associated mSets. For example, region zero might be responsible for the mSets for the first ten mSets. Region number one, for instance, would be responsible for the next ten mSets if the uLayer retains updates for unprotected mSets, since protected mSets are not updated within the uLayer. Protected mSets allow the uLayer to skip updates, so the uLayer retains updates for unprotected mSets, which are searched for translation as needed. The main uLayer is fully saved during CS.During CS, all current headers are copied, so that the header copy and the header copy for storing the uLayer in the storage device (e.g., NAND) are used. The main headers may be updated with the new compilation during CS.

[0044] If there is no free space or no free elements, some regions can be consolidated. This means that the regions are moved to their mSets. For example, the assignment to mSet 22 in Fig. The 5 uLayer was merged and deleted from the region to free up some memory. On startup, the entire uLayer is loaded, but in the case of the UGSD mount, the process is slightly more complex. It's necessary to revert to the state of the most recent CS and then restore the mapping that occurred after the CS. However, to revert to the state of the most recent CS, the uLayer is loaded as is, and the headers are copied back to preserve the uLayer in the state it was in at the beginning of the most recent CS.

[0045] Fig. Figure 6 is a schematic illustration of a Shadow-uLayer according to one embodiment. Regarding the Shadow-uLayer: the Shadow-uLayer retains updates only for protected mSets; it is never searched but managed to prevent all protected mSets from being stored during CS, with the possibility of restoring them after a UGSD; it is fully stored during CS; the copy of the headers reflects the state at the start of CS and allows for restoration after a UGSD; the headers and contents can be updated during CS; if no free elements are available, some regions can be freed after either being stored as uSlices in the NAND or their mSets being stored in the NAND, thereby invalidating all previously stored uSlices for that region.and with UGSD mounting, the valid uSlices are loaded individually one after the other in chronological order, with the headers being replaced by their copies created at the beginning of CS and used to update their mSets.;

[0046] As mentioned above, the Shadow-uLayer stores updates for protected mSets and is never scanned. The main uLayer is scanned for translation purposes. The Shadow-uLayer is never scanned and is maintained solely to avoid storing all protected mSets at once in CS, while still providing the ability to restore the mSets after a UGSD (Unified Grounded Software Development).

[0047] During CS, the shadow uLayer is stored just like the main uLayer, but in the case of consolidation or if no free elements are available, a choice is possible. Instead of the consolidation performed in the main uLayer, one option is to either store the entire region unchanged as a uSlice from the end, or to consolidate the region and store it in the storage device (e.g., NAND) so that the region can be deleted. These options allow you to choose whether to save a small uSlice or all mSets. The decision comes down to balancing time and storage requirements. Saving all mSets requires more storage in the storage device.On the other hand, if uSlices are repeatedly saved for the same region, many uSlices for that region will be retained, and with a UGSD, restoring the mapping of all uSlices will take a lot of time, since all uSlices must be loaded individually one after the other and used for mapping to the associated mSets.

[0048] One example of what can be done is to back up a uSlice for each region a predetermined number of times. Once the predetermined number is reached, the mSets are backed up, since backing up the mSets renders all previous uSlices for that region obsolete. This approach provides some flexibility, as otherwise many more mSets would be protected, but instead of backing them all up on every CS (Conversion Check), a choice can be made. Initially, the Shadow uLayer structure, which is relatively small, is backed up on CS. When memory in the structure becomes scarce, a decision can be made whether to back up a small uSlice or the mSets. For each given mSet, a decision can be made when to back up mSets for one region and when to back up mSets for another region. On the remaining occasions, only small uSlices can be backed up.

[0049] In summary, the Shadow uLayer allows CS to avoid storing all protected mSets. Ultimately, in CS, the region of each Shadow uLayer can either be stored as a uSlice in the NAND flash memory, or all protected mSets related to the region must be stored in the storage device (e.g., NAND flash memory). Typically, a uSlice occupies less space than all its associated mSets, thus improving CS latency and write gain. Until the region's mSets are stored, the stored uSlices are responsible for mapping. Once the region's mSets are stored in the storage device (e.g., NAND flash memory), all previously stored uSlices of the region become obsolete, and the responsibility for mapping shifts to the mSets.The balance between storing the region as a uSlice and storing the region's mSets (separately for each region) reflects the trade-off between a longer UGSD mount (when many uSlices need to be handled) and a longer CS (when many mSets need to be stored).

[0050] Fig. Figure 7 is a schematic illustration of a uLayer and shadow uLayer design according to another embodiment. The correspondence between the regions in the main and shadow uLayer is not necessarily 1:1. In the example of Fig. Seven regions in the Shadow uLayer correspond to four regions in the Main uLayer. For example, the Main uLayer might contain only a few regions, but correspond to a single region in the Shadow uLayer. Similarly, a region in the Main uLayer might be divided into several regions in the Shadow uLayer depending on various conditions.

[0051] The RAM for the main and shadow uLayers can be shared or separate, and can be statically or dynamically allocated. In the case of shared memory, if no free elements are available, one (or both) of the uLayers can be selected for consolidation.

[0052] Fig. Figure 8 is a flowchart 800 of a process according to one embodiment. The process begins at block 802, where a uLayer is managed, and at block 804, a shadow uLayer is managed. Then, at block 806, uSlices can be selectively stored in a storage device, and at block 808, consolidation can be performed that invalidates the uSlices. At block 810, a UGSD event can be detected, and subsequently, at block 812, a UGSD mount process can be performed for valid uSlices and protected mSets.

[0053] The disclosure here explains that dividing a uLayer into uSlices for HMB mSet recovery offers several advantages over a common protocol for all protected mSets. For example, uSlices allow the number of protected mSets to increase by a factor of N (e.g., N = 128), which is beneficial because there is typically a limit to the maximum number of protected mSets that can be flushed on a GSD. In the case of a uSlice, however, protected mSets are flushed from only one uSlice at a time due to a uLayer overflow. The shadow uLayer reduces the WAMP required to store protected mSets due to the increasing accumulation of updates before flushing to flash. Protected mSet recovery can be performed uSlice by uSlice, as needed, for the next read / write operation. uSlices utilize the uLayer memory (and do not require additional memory for the protocol) and use the uLayer algorithms, including non-blocking CS.Therefore, protected mSets can still be used with uSlices during CS, but this is not possible in the case of a common protocol for all protected mSets. The uSlices use the mLayer algorithms, which enable unification and also allow contiguous copies of the same uSlice to be retained in the mBlock before all protected mSets are flushed and the contiguous copies of the same uSlices are set to zero. Such an approach virtually increases the uLayer storage space and also increases the accumulation of updates before the protected mSets are flushed.

[0054] Using a shadow uLayer significantly improves RW and mixed RW / RR performance because the number of protected mSets using the HMB increases considerably. Additionally, the shadow uLayer solves the problem of restoring protected mSets in the HMB. The shadow uLayer also reduces the WA of control data (i.e., reduces the number of mSet consolidations).

[0055] In one embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: manage an update layer (uLayer), the uLayer being configured to manage updates for unprotected segments (mSets), with unprotected mSets remaining in random access memory (RAM) until a control sync (CS) operation; and manage a shadow uLayer, the shadow uLayer being configured to manage updates for protected mSets, with protected mSets being stored in the storage device after consolidation. The shadow uLayer is never searched. The shadow uLayer is managed to prevent all protected mSets from being stored during a CS operation, while maintaining the ability to recover protected mSets after ungraceful shutdown (UGSD) events.The controller is configured to periodically store a portion of the shadow uLayer (uSlice) in the storage device. The controller is configured to store the protected mSets in the storage device and invalidate the uSlices. The controller is configured to perform the CS operation, storing all unprotected mSets in the storage device during the CS operation, and storing portions of the shadow uLayer (uSlices) in the storage device during the CS operation. The controller is configured to balance the storage of uSlices and protected mSets in the storage device. The correspondence between regions in the uLayer and the shadow uLayer is not one-to-one, and the correspondence between regions in the uLayer and uSlices is not one-to-one. The RAM for the uLayer and the shadow uLayer is shared.The controller is configured to select either the uLayer or the Shadow uLayer, or both, for consolidation after determining that there are no free elements in the shared RAM.

[0056] In another embodiment, a data storage device comprises: a storage device; and a controller coupled to the storage device, the controller being configured to: perform an ungraceful shutdown (UGSD) operation; power on the device; detect that a UGSD event has occurred; and perform a UGSD mount operation, wherein the UGSD mount operation includes loading valid uSlices from the storage device into random-access memory, wherein uSlices are parts of a shadow update layer (uLayer), and wherein the shadow uLayer is configured to manage updates for protected RAM segments (mSets), and wherein protected mSets are stored in the storage device after consolidation. The uSlices are loaded individually. The uSlices are loaded in chronological order.The controller is configured to replace headers for the shadow uLayer with copies created during a control sync (CS) operation. The controller is configured to load a non-shadow uLayer as is during UGSD mount. The controller is configured to replace headers for the uLayer with copies created during a control sync (CS) operation. The controller is configured to allocate RAM between the shadow uLayer and a non-shadow uLayer.

[0057] In another embodiment, a data storage device comprises: means for storing data; and a controller coupled to the means for storing data, wherein the controller is configured to: manage both an update layer (uLayer) and a shadow uLayer, the uLayer corresponding to the unprotected segments (mSets) stored in random-access memory (RAM) and the shadow uLayer corresponding to the protected mSets; selectively store portions of the shadow uLayer (uSlices) in the means for storing data; and invalidate uSlices when storing protected mSets in the means for storing data. The controller is configured to accumulate updates for the shadow uLayer in a host memory buffer (HMB). The controller is configured to back up a uSlice multiple times before consolidating the shadow uLayer.

[0058] While the foregoing relates to embodiments of the present disclosure, other and further embodiments of the disclosure may be conceived without deviating from its basic scope, the scope of which is determined by the following claims.

Images