Method and apparatus for back-end wear level balancing of separate storage domains

Abstract

A method and apparatus are provided in which a controller of a storage device receives a command. The logical capacity of the storage device is divided into domains. The controller determines a logical address associated with the command. The logical address is associated with a first domain of the storage device. Based on a physical address associated with the logical address, the command is rerouted from a first resource of the controller belonging to the first domain to a second resource of the controller belonging to a second domain of the storage device.

Description

[0001] Priority

[0002] This application is based on and claims priority to U.S. Provisional Patent Application Serial No. 63 / 637,643, filed April 23, 2024, U.S. Provisional Patent Application Serial No. 63 / 637,672, filed April 23, 2024, and U.S. Patent Application Serial No. 19 / 084,159, filed March 19, 2025, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates generally to data storage management systems, and more particularly, to a method and apparatus for storage domain wear-leveling in a data storage management system. BACKGROUND

[0004] This Background section is intended to provide context only and is not admitted as prior art to the concepts presented in this section.

[0005] As computing demands increase, the complexity of data storage management continues to grow. Computing demands can be evidenced by an increase in commands (e.g., read commands, write commands, or copy commands) issued by a host and inserted into a data storage management system for execution.

[0006] A solid state drive (SSD) can have domains that divide the SSD into multiple different or identical back-ends, each managing a respective subset of the total drive logical capacity on a respective subset of the drive physical capacity (e.g., four to eight domains of NAND management). Each domain has a smaller physical capacity than the entire drive, and the addressing size of each logical page number (LPN) can be reduced to the size available to only that domain. Since these domains are managed separately, they have no knowledge or control of the other domains.

[0007] If user workloads decrease, the business can not be evenly distributed across the domains, and the life of the entire drive can be shortened to the life of the most worn domain. Global wear leveling divides the work evenly so that each domain will reach the end of life endurance at the same time. However, this division between domains can not address different business conditions, and is not flexible if the non-uniform business distribution changes. In addition, moving and excess logical block addresses (excess LBAs) cannot be tracked, and it is not clear how much data a target domain can support. SUMMARY

[0008] According to an embodiment, a method is provided in which a controller of a storage device receives a command. A logical capacity of the storage device is divided into domains. The controller determines a logical address associated with the command. The logical address is associated with a first domain of the storage device. The command is rerouted from a first resource of the controller attributed to the first domain to a second resource of the controller attributed to a second domain of the storage device based on a physical address associated with the logical address.

[0009] According to this embodiment, the physical address can be an invalid physical page number (PPN) retrieved from a first logical to physical (L2P) lookup table (LUT) of the first domain. Rerouting the command can include rerouting the LPN from the first L2P LUT to a second L2P LUT of the second domain. The first domain can have more wear than the second domain.

[0010] According to this embodiment, the L2P reroute table can be configured with a portion of L2P LUT entries that are not used in defining PPNs. The L2P reroute table can track LPNs that are routed from the first L2P LUT to the second L2P LUT. The LPNs can be indicated as being rerouted by a flag that enables the second resource of the controller attributed to the second domain to retrieve the physical location from the L2P reroute table.

[0011] According to this embodiment, the command can include a read command routed to the first resource of the controller attributed to the first domain, and executing the read command can include determining that a PPN value from the first L2P LUT is invalid based on the read command. An offset in the L2P reroute table can be determined by subtracting a last valid PPN value in the first domain from the PPN value. A new PPN value can be determined based on the offset in the L2P reroute table. The new PPN value can be a physical location in the second domain.

[0012] According to this embodiment, the command can include a garbage collection command routed to the first resource of the controller attributed to the first domain, and executing the garbage collection command can include triggering garbage collection across superblocks of the first domain. Valid LPNs are read and written to new superblocks. L2P information in the first L2P LUT and the L2P reroute table are updated.

[0013] According to this embodiment, the command can include a write command routed to the first resource of the controller attributed to the first domain, and data of the write command can be buffered. Based on the write command, it can be determined that a PPN value from the first L2P LUT indicates rerouting to the second domain and a physical location in the second domain. The write command and the buffered data can be sent to the second resource of the controller attributed to the second domain.

[0014] Alternatively, according to this embodiment, when the command includes a write command to a first resource of the first domain that is routed to the controller, the data of the write command can be buffered and the physical location indicated in the first L2P LUT can be invalidated based on the write command. The physical location can be updated based on the value of the L2P re-routing table. A temporary value can be attributed to the L2P re-routing table that points to the buffered data of the write command. The write command and the temporary value can be transferred from the first resource of the first domain that is attributed to the controller to a second resource of the second domain that is attributed to the controller. The write command can be executed by sending the buffered data to the second resource of the second domain that is attributed to the controller. The temporary value of the L2P re-routing table can be changed to the physical location of the data in the second domain.

[0015] According to this embodiment, a re-direct L2P LUT can be configured. Executing the command can include concurrently using the first L2P LUT and the re-direct L2P LUT. A first PPN entry of the first L2P LUT can include at least a first cross-domain ID that identifies a cross-domain access to a second domain. A second PPN entry of the first L2P LUT can include a second cross-domain ID that identifies a cross-domain access to a third domain of the domains. A hash function can be performed on the LPN of the command to reduce the LPN for an entry of the re-direct L2P LUT.

[0016] According to this embodiment, the first resource can include first hardware and firmware resources that are dedicated to the first domain and the second resource can include separate second hardware and firmware resources that are dedicated to the second domain. Alternatively, the first resource and the second resource can include hardware and firmware resources that are used on a round-robin basis between the first domain and the second domain.

[0017] According to an embodiment, a storage device is provided that includes a controller and a non-transitory computer readable storage medium having a logical capacity partitioned into domains and storing instructions. When executed, the instructions cause the controller to receive a command and determine a logical address associated with the command. The logical address is associated with a first domain. The instructions further cause the controller to re-route the command from a first resource of the controller that is attributed to the first domain to a second resource of the controller that is attributed to a second domain based on a physical address associated with the logical address.

[0018] According to this embodiment, the physical address can be an invalid PPN retrieved from a first L2P LUT of the first domain. Re-routing the command can include re-routing the LPN from the first L2P LUT to a second L2P LUT of the second domain. The first domain can have more wear than the second domain.

[0019] According to this embodiment, an L2P rerouting table can be configured with a portion of the L2P LUT entries that are not used when defining PPNs. The L2P rerouting table tracks LPNs that are routed from a first L2P LUT to a second L2P LUT. The LPN can be indicated as being rerouted by a flag that enables a second resource of the controller belonging to a second domain to retrieve the physical location from the L2P rerouting table.

[0020] According to this embodiment, a redirection L2P LUT may be configured. Executing a command may include concurrently using the first L2P LUT and the redirection L2P LUT. A first PPN entry in the first L2P LUT may include a first cross-domain ID identifying a cross-domain access to a second domain. A second PPN entry in the first L2P LUT may include a second cross-domain ID identifying a cross-domain access to a third domain. A hash function may be performed on the LPN of the command to narrow the LPN of the entry used for the redirection L2P LUT. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The drawings described below are examples of how embodiments of the present disclosure may be implemented and are not intended to limit the embodiments of the present disclosure. Various embodiments of the present disclosure may include elements not shown in a particular drawing and / or may omit elements shown in a particular drawing. The drawings are intended to provide illustrations and may not be to scale. The above and other aspects, features, and advantages of certain embodiments of the present disclosure will become more apparent from the following detailed description in conjunction with the accompanying drawings, in which:

[0022] Figure 1 is a diagram illustrating a data storage management system for processing commands in an electronic device according to an embodiment;

[0023] Figure 2 is a diagram illustrating an SSD configured with a plurality of domains according to an embodiment;

[0024] Figure 3 is a diagram illustrating a PPN address space according to an embodiment;

[0025] Figure 4 is a diagram illustrating wear leveling between domains according to an embodiment;

[0026] Figure 5 is a flow chart illustrating domain wear leveling for a read command according to an embodiment;

[0027] Figure 6 is a flow chart illustrating domain wear leveling for write commands according to an embodiment;

[0028] Figure 7 is a flow chart illustrating domain wear leveling for a read command according to another embodiment;

[0029] Figure 8 is a flowchart illustrating domain wear leveling for a write command according to another embodiment; and

[0030] Figure 9 is a block diagram of an electronic device in a network environment for processing a command according to an embodiment. DETAILED DESCRIPTION

[0031] Hereinafter, embodiments of the disclosure are described in detail with reference to the accompanying drawings. It should be noted that although the same elements are shown in different drawings, the same elements will be denoted by the same reference numerals. In the following description, only specific details such as detailed configuration and components are provided in order to assist in a comprehensive understanding of the embodiments of the disclosure. Therefore, it will be apparent to those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope of the disclosure. Furthermore, descriptions of well-known functions and structures are omitted for clarity and conciseness. The terms described below are terms defined in consideration of the functions in the disclosure, and can differ according to users, user's intentions, or habits. Therefore, the definition of the terms should be determined based on the contents throughout the specification.

[0032] The disclosure can have various modifications and various embodiments, in which the embodiments are described in detail below with reference to the accompanying drawings. However, it should be understood that the disclosure is not limited to the embodiments, but includes all modifications, equivalents, and alternatives within the scope of the disclosure.

[0033] Although terms including ordinal numbers such as first, second, etc. can be used to describe various elements, the structural elements are not limited by the terms. The terms are used only to distinguish one element from another element. For example, a first structural element can be referred to as a second structural element without departing from the scope of the disclosure. Similarly, a second structural element can also be referred to as a first structural element. As used herein, the term "and / or" includes any and all combinations of one or more related items.

[0034] The terms used herein are only used to describe various embodiments of the disclosure, but are not intended to limit the disclosure. The singular form is intended to include the plural form unless the context clearly dictates otherwise. In the disclosure, it should be understood that the term "include" or "have" indicates the presence of a feature, number, step, operation, structural element, component, or a combination thereof, and does not exclude the presence or probability of addition of one or more other features, numbers, steps, operations, structural elements, components, or a combination thereof.

[0035] Unless defined differently, all terms used herein have the same meaning as understood by those skilled in the art to which the present disclosure belongs. Terms such as those defined in commonly used dictionaries should be interpreted as having the same meaning as in the context of the relevant technical field, and should not be interpreted as having an ideal or overly formal meaning unless explicitly defined in the present disclosure.

[0036] The terms used in this disclosure are not intended to limit the disclosure, but are intended to include various changes, equivalents or replacements of corresponding embodiments. With regard to the description of the accompanying drawings, similar figure numerals may be used to refer to similar or related elements. The singular form of the noun corresponding to an item may include one or more of the things, unless the relevant context clearly indicates otherwise. As used herein, each of the phrases such as "A or B", "at least one of A and B", "at least one of A or B", "A, B or C", "at least one of A, B and C" and "at least one of A, B or C" may include all possible combinations of the items listed together in the corresponding phrases in each phrase. As used herein, terms such as "1st", "2nd", "first" and "second" may be used to distinguish a corresponding component from another component, but are not intended to limit a component (e.g., importance or order) in other respects. If an element (e.g., a first element) is referred to as being “coupled” with another element (e.g., a second element), “coupled to” another element (e.g., a second element), “connected with” another element (e.g., a second element), or “connected to” another element (e.g., a second element), with or without the term “operably” or “communicatively,” it indicates that the element may be coupled to the other element directly (e.g., by wire), wirelessly, or via a third element.

[0037] As used herein, the term "module" may include units implemented in hardware, software, firmware, or a combination thereof, and may be used interchangeably with other terms such as "logic," "logic block," "component," and "circuit." A module may be a single integrated component or its smallest unit or part adapted to perform one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC), a coprocessor, or a field-programmable gate array (FPGA).

[0038] According to one embodiment, the electronic device can be one of various types of electronic devices that utilize a storage device (e.g., a memory device). The electronic device can use any suitable storage standard, such as Peripheral Component Interconnect Express (PCIe), Non-Volatile Memory Express (NVMe), NVMe-over-fabric (NVMeoF), Advanced eXtensible Interface (AXI), Ultra Path Interconnect (UPI), Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Remote Direct Memory Access (RDMA), RDMA over Converged Ethernet (ROCE), Fibre Channel (FC), Infiniband (IB), Serial Advanced Technology Attachment (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), Internet Wide Area RDMA Protocol (iWARP), etc., or any combination thereof. In some embodiments, the interconnect interface can be implemented with one or more memory semantics and / or memory consistency interfaces and / or protocols, including one or more Compute Express Link (CXL) protocols, such as CXL.mem, CXL.io, and / or CXL.cache, Gen-Z, Coherent Accelerator Processor Interface (CAPI), Cache Coherent Interconnect for Accelerators (CCIX), etc., or any combination thereof. Any memory device can be implemented with one or more of any type of memory device interface, including Double Data Rate (DDR), DDR2, DDR3, DDR4, DDR5, Low Power DDR (LPDDR X), Open Memory Interface (OMI), Nvlink High Bandwidth Memory (HBM), HBM2, HBM3, etc. The electronic device can include, for example, a portable communication device (e.g., a smartphone), a computer, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance. The electronic device is not limited, however, to those described above.

[0039] Figure 1 is a diagram illustrating a data storage management system for processing commands in an electronic device, according to an embodiment. In data storage management, commands can be issued by a host and executed in a data storage device. Destination addresses (e.g., logical page numbers (LPNs)) are in a storage address space of the data storage device. The LPNs can be a result of a namespace (NS) multiplexed with logical block addresses (LBAs). Each NS has a range of LBAs, and each NS can have a different number of LBAs (and thus a different capacity). The drive converts [NS, LBA] pairs to globally unique LPNs within the drive.

[0040] The storage system 100 includes a host 102 and a storage device 104 (e.g., a memory device). Although one host and one storage device are depicted, the storage system 100 can include multiple hosts and / or multiple storage devices. The storage device 104 can be a hard disk drive (HDD), a solid state drive (SSD), a universal flash storage (UFS), etc. The storage device 104 can include a controller 106 and a storage medium 108 connected to the controller 106. The controller 106 can be an HDD controller, an SSD controller, a UFS controller, etc. The controller 106 can be tailored for high performance storage management and can include multiple processing cores and hardware accelerators. The controller 106 can be implemented in one or more chips on the storage device 104. One or more specialized processing elements (e.g., microcontrollers, digital signal processors, or FPGAs) can accelerate tasks and can run concurrently to handle command throughput from the host. The storage medium 108 can include volatile memory, non-volatile memory, or both, and can include one or more flash memory chips, a disk drive platter, phase change memory (PCM), resistive random access memory (ReRAM), magnetic random access memory (MRAM), or other storage medium. The controller 106 can be configured to facilitate transfer of data / commands between the host 102 and the storage medium 108. The host 102 can send data / commands to the storage device 104 to be received by the controller 106 and processed in connection with the storage medium 108. A firmware instruction module 110 can be disposed within or directly coupled to the controller 106 and can include firmware instructions that run a wear leveling method stored in a dedicated non-volatile memory portion. In particular, the firmware instruction module 110 can monitor domain wear, analyze traffic conditions, and adjust logical-physical mappings based on current wear conditions and traffic. The firmware instruction module 110 can have associated hardware components 112 of the controller 106. The firmware instruction module 110 and the associated hardware components 112 can be referred to as resources of the controller 106.

[0041] Figure 2 is a diagram illustrating an SSD configured with multiple domains according to an embodiment. The SSD can be implemented as the storage device 104, as described above with respect to Figure 1 The host 202 can communicate with the SSD 204 configured with eight local domains. Each of the local domains includes a set of memory blocks. For example, the first local domain 206 can include a first set of memory blocks 208, and the eighth local domain 210 can include an eighth set of memory blocks 212, with the second through seventh local domains and respective sets of memory blocks in between. A controller 214 of the SSD 204 can correspond to Figure 1The controller 106 may have dedicated hardware, firmware, and processing resources (also commonly referred to as "resources") for each local domain. Such dedicated resources may be included in Figure 1 1 and 12. Alternatively, the hardware, firmware, and processing resources of the controller 214 may be shared between local domains and may be assigned to each local domain on a rotating basis.

[0042] A portion of dynamic random access memory (DRAM) 216 can be dedicated to storing a logical-to-physical (L2P) lookup table (LUT) for each domain. For example, a first portion 218 of DRAM 216 is used for the L2P LUT for the first local domain 206, a second portion 220 of DRAM 216 is used for the L2P LUT for the second local domain, third through seventh portions 222 of DRAM 216 are used for the L2P LUT for the corresponding local domain, an eighth portion 224 of DRAM 216 is used for the L2P LUT for the eighth local domain 210, and the remaining portion 226 of DRAM 216 is used for other DRAM data. The corresponding L2P LUT can be used to track the physical location of the data for that domain by mapping logical addresses to physical addresses. The L2P LUT can also be split between static random access memory (SRAM), NAND, or between DRAM 216 and NAND. If split between DRAM 216 and NAND, the L2P LUT can be cached in a portion of DRAM 216 for a short period of time.

[0043] Each globally unique LPN can be routed to a local domain. This routing can be performed by any hashing method. One such hashing method may include running a modulo function on the global LPN. Figure 2 Given the eight local domains shown in FIG, the global LPN can be divided by eight. The remainder of this division is equal to the modulo-8 value. All remainder values ​​of 0 can be routed to the first local domain 206, all remainder values ​​of 1 can be routed to the second local domain, and so on. The global LPN can be right-shifted by three bits to omit three bits within the local LPN value. This right shift can be used to reduce the number of bits required to store the local LPN value. A globally unique LPN can also be addressed by a combination of domain and local LPN value.

[0044] Each local region can then be used in isolation and the controller can perform garbage collection (GC) on all local LPNs within each local region. In addition to the reduced number of bits of the LPN values within a local region, each local region can also be allocated a reduced amount of flash memory. The flash memory can be addressed with physical page numbers (PPNs). Since a smaller amount of flash within each domain is addressed by the local PPN values, the L2P LUT can utilize a reduced number of bits by reducing the width of the PPNs. The local LPNs within each local region can be placed in the local PPNs of each domain.

[0045] Figure 3 is a diagram illustrating a PPN address space according to an embodiment. The PPNs can be contained in the 32-bit addresses of the L2P LUT entries. The L2P LUT can be stored in DRAM and the DRAM controller’s accesses or DRAM error correction codes (ECCs) can be optimized for 32-bit accesses. The 32-bit addresses can have a 4 KiB data granularity and the L2P LUT can track 2 32

[0046] Within each local region, a subset of the bits within the 32-bit address can be allocated to, for example, a chip index to represent a flash chip within that local region, a plane within that flash chip, an erase block (EB) within that plane, a word line (WL) in that EB, a page within that WL, etc. Unused numbering intervals can exist in each subset of bits. For example, it can not be desirable for the PPN to define the use of every allocated chip of each domain, every allocated block of each chip, etc. In Figure 3 One non-compact embodiment is shown in (a) of FIG. 3, where unused blocks 302 are interspersed throughout the PPN address space after used addresses 304, resulting in unallocated numbering intervals on the 32-bit address space. Specifically, the unused blocks 302 can indicate the absence of chips, EBs, WLs, and pages, and the PPNs corresponding to such locations can be invalid. Alternatively, these addressing intervals can be combined into a single interval at the end of the contiguously packed L2P PPN address space.

[0047] In Figure 3 ​(b) of FIG. 3 shows a compact embodiment in which unused blocks 302 are arranged after all used addresses 304 in the 32-bit address space. As an example of compact numbering, PPN 0 can be assigned to chip-0, plane-0, EB-0, page-0, WL-0, sector-0; PPN 1 can be assigned to chip-1, plane-0, EB-0, page-0, WL-0, sector-0; PPN 2 can be assigned to chip-2, plane-0, EB-0, page-0, WL-0, sector-0, and so on. In another example of compact numbering, PPN 0 can be assigned to chip-0, plane-0, EB-0, page-0, WL-0, sector-0; PPN 1 can be assigned to chip-0, plane-0, EB-0, page-0, WL-0, sector-1; PPN 2 can be assigned to chip-0, plane-0, EB-0, page-0, WL-0, sector-2, and so on. So, 8.3TB to 17TiB can mean that the 32 It remains unused in the bitmap definition. Generally, in this document, metric prefixes are used for decimal numbers and International Electromechanical Commission (IEC) prefixes are used for binary numbers, thus avoiding ambiguity caused by using memory terms for binary numbers.

[0048] Figure 4 is a diagram illustrating wear balancing between local domains according to an embodiment. Wear between local domains may become unbalanced due to excessive business access to a particular local domain or due to the domain being weak or unhealthy. The controller of the SSD may calculate the average wear of the local domain by estimating the remaining number of writes that a block can withstand or by estimating the programming, reading or erasing speed. Figure 4 As shown, host 402 is communicating with SSD 404, which may include a first local domain 406 having a wear value of 100, a second local domain 408 having a wear value of 10, a seventh local domain 410 having a wear value of 12, an eighth local domain 412 having a wear value of 0, and the third through sixth local domains therebetween. Controller 422 may compare the average wear calculations between the domains to determine the local domains of SSD 404 with the most wear and the least wear. The amount of life remaining in the local domain with the most accumulated wear is less than the amount of life remaining in the local domain with the least accumulated wear. Therefore, it may be beneficial to subsequently attribute more wear (or LPNs) to the local domain with the least accumulated wear and subsequently attribute less wear to the local domain with the most accumulated wear.

[0049] The controller 422 may temporarily move the LPN from the most worn local domain (e.g., the first local domain 406) to the least worn domain (e.g., the eighth domain 412). Initially, both local domains may be globally marked (e.g., a move from domain 1 to domain 8).Figure 3 As described, the number interval (unused values) 414 in the 32-bit address space 416 can be used to specify the use of the L2P re-routing table 418 of the DRAM 420. Specifically, invalid values (offsets) within the number interval 414 of the 32-bit L2P LUT address space 416 can be used as an array offset in the L2P re-routing table 418 in order to re-route a given command to the L2P LUT of the least-worn home domain (e.g., the eighth home domain 412). As more data is routed into the eighth home domain 412, over-provisioning (OP) can be reduced and a write amplification factor (WAF) can be increased at the eighth home domain 412. In the case of less data attributed to the first home domain 406, OP can increase and WAF can decrease at the first home domain 406. Rebalancing can generally be stronger for increased wear on the least-worn home domains compared to reduced wear on the most-worn home domains.

[0050] Figure 5 is a flowchart illustrating domain wear leveling for read commands according to an embodiment. At 502, a host can submit a read command to a drive. For example, for Figure 2 , the host 202 can submit a read command to the SSD 204, or for Figure 4 , the host 402 can submit a read command to the SSD 404.

[0051] At 504, a controller of the drive can extract and parse the read submission queue entry (SQE), convert the NS and LBA to LPN, and route the read command to the originating home domain as described above for Figure 2 . By way of example, for Figure 2 , the controller 214 can route the read command to the first home domain 206, or for Figure 4 , the controller 422 can route the read command to the first home domain 406.

[0052] As described above for Figure 2 , the drive controller can have dedicated hardware, firmware, and processing resources (hereinafter, resources) for each home domain. Alternatively, the hardware, firmware, and processing resources of the drive controller can be shared among the home domains and attributed to the individual home domains on a rotating basis. In both cases, such resources can represent a portion of the drive controller and can correspond to the firmware instruction modules 110 and hardware components 112 of the controller 106 in Figure 1 .

[0053] At 506, resources belonging to the drive controller of the originating native domain can look up the LPN corresponding to the read command in the L2P LUT of the originating domain. For example, for Figure 2 resources belonging to the controller 214 of the first domain 206 can look up the LPN corresponding to the read command in the L2P LUT 218 of the first domain 206, or for Figure 4 resources belonging to the controller 422 of the first domain 406 can look up the LPN corresponding to the read command in the L2P LUT of the first domain 406 in the DRAM 420.

[0054] At 508, resources belonging to the drive controller of the originating native domain can determine that the PPN value retrieved from the L2P LUT is an invalid physical location (e.g., unused / unallocated value). For example, for Figure 2 resources belonging to the controller 214 of the first domain 206 can determine that the PPN value from the L2P LUT 218 is invalid, or for Figure 4 resources belonging to the controller 422 of the first domain 406 can determine that the PPN value from the L2P LUT in the DRAM 420 is invalid.

[0055] At 510, resources belonging to the drive controller of the originating native domain can determine that the retrieved PPN value corresponds to an L2P re-routing table, and that the LPN is moved from the originating native domain. For example, for Figure 4 resources belonging to the controller 422 of the first domain 406 can determine that the retrieved PPN value corresponds to the L2P re-routing table 418.

[0056] At 512, resources belonging to the drive controller of the originating native domain can determine the offset in the L2P re-routing table by subtracting the last used / effective PPN value in the originating native domain from the retrieved PPN value. For example, for Figure 4 resources belonging to the controller 422 of the first domain 406 can determine the offset in the L2P re-routing table 418. In a compact numbering scheme for PPN (e.g., (b) of Figure 3 the value of PPN can be in the range of 0 to N. N+l and larger PPN values are invalid. N can be subtracted from the invalid PPN value to determine the lookup value for the L2P re-routing table.

[0057] For a non-compact numbering scheme (e.g., (a) of Figure 3of (a)), a conversion can be required to determine the lookup value for the L2P re-routing table. Specifically, the interval within the numbering scheme needs to be known. For example, the first interval can be in the fourth bit of the page (e.g., there are only three pages). In the case where the first four bits are 4KiB sectors in a 16KiB page, the binary value of the PPN is:

[0058] 00...00 | Page 00 | Sector 00 - Valid

[0059] 00...00 | Page 00 | Sector 01 - Valid

[0060] 00...00 | Page 00 | Sector 10 - Valid

[0061] 00...00 | Page 00 | Sector 11 - Valid

[0062] 00...00 | Page 01 | Sector 00 - Valid

[0063] 00...00 | Page 01 | Sector 01 - Valid

[0064] 00...00 | Page 01 | Sector 10 - Valid

[0065] 00...00 | Page 01 | Sector 11 - Valid

[0066] 00...00 | Page 10 | Sector 00 - Valid

[0067] 00...00 | Page 10 | Sector 01 - Valid

[0068] 00...00 | Page 10 | Sector 10 - Valid

[0069] 00...00 | Page 10 | Sector 11 - Valid

[0070] 00...00 | Page 11 | Sector 00 - Invalid

[0071] 00...00 | Page 11 | Sector 01 - Invalid

[0072] 00...00 | Page 11 | Sector 10 - Invalid

[0073] 00...00 | Page 11 | Sector 11 - Invalid

[0074] 00...01 | Page 00 | Sector 00 - Valid

[0075] 00...01 | Page 00 | Sector 01 - Valid

[0076] 00...01 | Page 00 | Sector 10 - Valid

[0077] 00...01 | Page 00 | Sector 11 - Valid

[0078] The first interval with invalid numbers has four values, and the interval starts with the decimal 12 (binary value 1100). Subtracting 12 from the value in the L2P table gives 0, which is used as a lookup value for the L2P re-routing table. The next interval can be based on how many WLs are present in each EB.

[0079] At 514, resources belonging to the drive controller of the originating local domain or the receiving local domain can use the offset in the L2P re-routing table to find a new PPN value, which is the physical location in the receiving local domain. For example, for Figure 4 , resources belonging to the controller 422 of the first local domain 406 or the eighth local domain 412 can use the offset in the L2P re-routing table 418 to find a new PPN value. The originating local domain can check global information, as described above, to determine the correct receiving local domain. For example, global information in the tracking can indicate that domain 3 has an LPN that is being re-routed to domain 5, and domain 5 can be checked to find a local PPN within domain 5. The L2P re-routing table has meaning in domain 5.

[0080] At 516, resources belonging to the drive controller of the originating local domain can redirect the read command and the offset of the L2P re-routing table to the receiving local domain with a flag indicating that this is a re-direction. Specifically, the flag can provide an indication that the L2P re-routing table should be used, and resources belonging to the drive controller of the receiving local domain can look up the physical location in the L2P re-routing table. For example, for Figure 4 , resources belonging to the controller 422 of the first local domain 406 can redirect the read command, the offset, and the flag to the eighth local domain 412, and resources belonging to the controller 422 of the eighth local domain 412 can look up the physical location. Alternatively, resources belonging to the drive controller of the originating local domain can perform the lookup at the L2P re-routing table, and the result from the L2P re-routing table can be passed to the receiving local domain.

[0081] At 518, resources belonging to the drive controller of the receiving local domain can read the physical location within the receiving local domain and return the requested data to the host. For example, for Figure 4 , resources belonging to the controller 422 of the eighth local domain 412 can read the physical location in the eighth local domain 412 and return the requested data to the host 402.

[0082] When a host deallocate (or trim) command releases memory or the host overwrites data and invalidates memory locations, a GC command can collect the remaining valid data. The valid data can be programmed contiguously elsewhere, allowing the previously sparse space to be erased and creating a contiguous set of space that can accept new incoming data. A typical GC command can process a unit of memory, such as a block, by copying the valid data within the unit of memory to a new location(s) and then erasing the entire unit so that it becomes available for future write commands. A super block (SB) is a grouping of blocks from more than one chip (or die). The memory management subsystem can request an erase command for the purpose of GC, and the controller can issue an erase command to an entire super block, which can run across multiple chips (or dies) at a time. When a GC is triggered on a SB, the SB information can be read, and valid LPNs in the SB can be looked up and read from NAND based on the SB. The valid LPNs can be written compactly in a new SB. The L2P LUT information for the moved LPNs can be updated.

[0083] Two methods can be utilized to move LPNs between domains. In a first method, LPNs can be moved by temporarily pausing processing of commands and moving LPNs between domains in the background. In a second method, selected LPNs can be moved as write commands submitted from the host. This second method does not trigger the additional writes required in the first method.

[0084] Figure 6 is a flowchart illustrating domain wear leveling for write commands according to an embodiment. Such an embodiment can be applied during a transition period for moving incoming write commands, or can apply write commands to LPNs that have already been moved to a receiving domain. The drive can identify that a domain is wearing quickly (e.g., an originating domain), and can select another domain that is not wearing quickly to receive write commands (e.g., a receiving domain).

[0085] The host can create a write command that would normally be written to the originating native domain (e.g., the first domain 406) of the SSD 404. At 602, the host can submit the write command to the drive. For example, for Figure 2 , the host 202 can submit a write command to the SSD 204, or for Figure 4 , the host 402 can submit a write command to the SSD 404.

[0086] At 604, the drive can extract and parse the write SQE, convert the NS and LBA to LPN, and route the write command to the originating domain. For example, for Figure 2 , the controller 214 can route the write command to the first native domain 206, or for Figure 4 , the controller 414 can route the write command to the first native domain 406.Figure 4 The controller 422 can route the write command to the first local domain 406.

[0087] As described above with respect to Figure 2 the drive controller can have dedicated hardware, firmware, and processing resources (hereinafter, resources) for each local domain. Alternatively, the hardware, firmware, and processing resources of the drive controller can be shared among the local domains and attributed to the respective local domains on a rotating basis. In both cases, such resources can represent a portion of the drive controller.

[0088] At 606, the resources attributed to the drive controller of the originating local domain can buffer the incoming data of the write command. For example, for Figure 2 the resources attributed to the controller 214 of the first local domain 206 can buffer the incoming data, or for Figure 4 the resources attributed to the controller 422 of the first local domain 406 can buffer the incoming data.

[0089] At 608, the resources attributed to the drive controller of the originating local domain can read the current value in the L2P LUT of the originating local domain to find the PPN for the LPN. For example, for Figure 2 the resources attributed to the controller 214 of the first local domain 206 can read the value in the L2P LUT 218, or for Figure 4 the resources attributed to the controller 422 of the first local domain 406 can read the value in the L2P LUT of the first local domain 406 of the DRAM 420.

[0090] For a redirection established between local domains, the write command is redirected in a manner similar to a read command, as described above with respect to Figure 4 Specifically, based on the read value, the resources attributed to the controller of the originating local domain can determine that the local LPN is being rerouted. The resources attributed to the controller of the originating local domain can pass the write command, the L2P reroute offset, and the flag to the resources attributed to the controller of the receiving domain.

[0091] However, for embodiments of Figure 6 the controller in the originating domain can determine that the local LPN is valid, but the originating domain needs to move the L2P value from the originating local domain to the receiving local domain. At 610, the resources attributed to the controller of the originating local domain can invalidate the existing physical location indicated in the L2P LUT in the originating local domain and update the entry to a value to be used in the L2P reroute table (e.g., a value within the range 16 TiB - 8.3 TB). For example, for Figure 4, resources attributed to the controller 422 of the first local region 406 can update an entry of the L2P LUT of the first local region 406 in the DRAM 420 to an invalid value indicating use of the L2P re-routing table 418. Specifically, the controller can determine a next unused value in the L2P re-routing table and can convert that array offset value to a range of invalid intervals of PPN table values. The new PPN in the L2P re-routing table can be determined by the controller in the receiving domain. Resources attributed to the controller of the receiving domain can select a PPN according to normal operations, which can be the next available PPN for writes in the receiving domain.

[0092] At 612, resources attributed to the controller of the originating local region can increment a tracking value that indicates a number address within a range of the L2P re-routing table (e.g., 16TiB - 8.3TB) that is used. For example, for Figure 4 , resources attributed to the controller 422 of the first local region 406 can increment the tracking value. As re-routed LPNs are accumulated, the tracking value increases. With each increment, a next offset in the L2P re-routing table is selected. Resources attributed to the controller of the originating local region can also use the tracking value to confirm that enough LPNs have been re-routed to meet a planned threshold of LPNs to move.

[0093] At 614, resources attributed to the controller of the originating local region can place a temporary value (e.g., a memory pointer) in the L2P re-routing table that points to a buffer where data of the write command is currently located. For example, for Figure 4 , resources attributed to the controller 422 of the first local region 406 can place the temporary value in the L2P re-routing table 418.

[0094] At 616, resources attributed to the controller of the originating local region can pass the write command and a pointer to the data to resources attributed to the controller of the receiving domain. For example, for Figure 4 , resources attributed to the controller 422 of the first local region 406 can pass the write command and the pointer to resources attributed to the controller 422 of the eighth local region 412.

[0095] At 618, resources attributed to the controller of the receiving domain can perform a normal write procedure of the write command, where buffered data is programmed to a physical location in NAND in the receiving domain. For example, for Figure 4 , resources attributed to the controller 422 of the eighth local region 412 can perform the write operation.

[0096] At 620, the resource belonging to the controller of the receiving domain can change the value of the re-routing table pointing to the buffer data to the physical location in the receiving domain after it has been programmed. For example, for Figure 4 The resource belonging to the controller 422 of the eighth native domain 412 can change the value of the L2P re-routing table 418 to the physical location in the eighth native domain 412.

[0097] The above process can be performed for all LPNs written to the originating domain until a target number of LPNs are moved to the receiving domain. If the target number of LPNs between the domains is not at an acceptable threshold, the method repeats for the next write command. After the target number of LPNs are moved to the receiving domain, the drive can maintain this state of fewer LPNs in the originating domain and more LPNs in the receiving domain for a period of time. During this period of time, there can be writes from the host and GC activity from a different drive domain. If the wear leveling between the domains reaches an acceptable threshold, the data can be read out from the receiving domain, buffered, transferred with buffer pointers to the originating domain, and the originating domain can update the L2P LUT values to the new physical location of the data in the originating domain. When the data is copied from the receiving domain, the receiving domain can mark the data as invalid in its own domain. Thus, the number of LPNs of the originating and receiving domains returns to normal (e.g., the number of LPNs in each domain is equal), and the wear between the domains can be more even. The wear leveling between the domains can target to keep the wear within an acceptable boundary or to overshoot. The trigger for wear leveling can be a greater difference (e.g., 5%) than the trigger for wear leveling termination (e.g., 1%). For example, wear leveling can be triggered when the wear level difference between the domains exceeds 5%, and wear leveling can be terminated when the wear level difference drops to 1% or lower.

[0098] Alternatively, if wear leveling is to be terminated, normal GC is performed on the majority of data when GC is triggered in the receiving domain. However, if the data is from the originating domain, the data is buffered and sent to the originating domain with the pointers to the data. The data can be received by the originating domain as new host write, or it can be processed as GC data. The originating domain can write the data from the buffer to NAND as per the GC append point or the incoming host write data stream. The originating domain can respond to the receiving domain that the particular data was programmed to NAND (or buffered in the originating domain with power failure protection ensured). The receiving domain can be able to consider the LPN moved back to the originating domain and the data invalid. The GC process can continue without performing GC on the data since it is invalid. The GC process in the receiving domain can avoid the stop and copy process, which benefits performance and does not require additional writes.

[0099] Alternatively, if wear leveling is to be terminated, a write command can come in from the host. If the write command resides in the receiving domain, it can be used to route data back into the originating domain and invalidate data in the receiving domain.

[0100] Thus, in addition to the write command executed in the process of moving the LPN, the L2P re-routing table is incorporated into the number interval (unused values) of the 32-bit L2P LUT entries for read commands, write commands, and GC have low impact as described above for Figure 6 The existing memory structure, tracking, and flip-flops are not affected. While one additional DRAM read can be performed in the above-described embodiment, this can be avoided by placing the data in SRAM. However, any increase in RAM can be met by normal expectations.

[0101] Thus, a drive with multiple domains can be implemented that balances wear between the domains by exchanging LPNs between those domains. The LPNs can be exchanged within an additional L2P re-routing table implemented in the unused values in the 32-bit physical meaning of the L2P LUT. The exchanged LPN on the NAND can be signaled as coming from another domain, which enables the GC process to properly utilize the L2P re-routing table. For example, a flag or utilization of the sparse LPN space can be sufficient for this signaling.

[0102] While the above describes two domains, Figure 3 and Figure 4 more than one domain pair can be balanced at a time, a domain grouping can map more than one domain with high wear to a single domain with least wear, or one domain with high wear can spread the LPNs to more than one domain (e.g., all other domains).

[0103] Additionally, if certain LPNs need to be re-routed, the host can not write them. The LPNs can be re-routed by an additional copy operation selecting and moving the LPN. The LPNs can also be opportunistically re-routed during the GC process. However, the GC can not occur as it is a result of indirect host activity and can reach a time limit.

[0104] Furthermore, different segment ordering can be used in addition to strict sequential ordering. A flag can be used stating "this LPN has moved" and the receiving domain can have a slightly larger L2P LUT. The receiving domain can then solve func(LPN, original domain) = new logical lookup value. The receiving domain can have a small number of LPNs from the old domain in SRAM. The receiving domain can use a different memory structure (e.g., linked list, b-tree, CAM, and hash table) for the small number of LPNs transferred.

[0105] According to another embodiment, the number intervals (unused values) in the above 32-bit L2P LUT entries may be large enough to completely address all physical locations in other domains.

[0106] The two-pass L2P LUT can be decoupled into a source L2P LUT and a concurrent redirection L2PLUT. The domain selection can be shifted to the end, and the redirection can be identified by a fixed but unmapped address. This decoupling can improve the delay caused by the sequential two-pass redirection mapping for cross-domain access and can improve the restriction of PPN entries retained in the source domain. High program / erase cycles can be spread across multiple domains via multiple concurrent redirection L2P LUTs and different redirection IDs that can select different target domains. This dispersion can improve target capacity restrictions.

[0107] The hash function can be used to reduce the double size of the L2P LUT by scaling the full LPN to the desired number of X-domain entries. Hash function collision detection can be performed by adding the LPN to the X-L2P LUT. Collisions can be resolved by linking entries associated with the same hash function, but this may negatively impact latency.

[0108] Instead, conflict resolution latency can be improved by using a double hash function that employs multiple orthogonal hash functions and concurrent accesses to find non-conflicting entries. The number of conflicts can be greater than the double hash function count, and the reserved memory can use a content-addressable memory (CAM)-based algorithm or a sequential search-based algorithm.

[0109] Figure 7 1 is a flowchart illustrating domain wear balancing for read commands according to another embodiment. Figure 5 As described, the host may submit a read command to the drive, and the drive may extract and parse the read SQE, convert the NS and LBA to LPN, and route the read command to the originating domain. At 702, the drive controller may receive a global LPN for the read command and may perform concurrent domain path operations at 704. For example, for Figure 2 , the controller 214 may receive a global LPN for a read command.

[0110] At 706, the resource belonging to the controller of the source domain may use the LPN to retrieve the source domain PPN via the source domain L2P LUT. At 708, the resource belonging to the source domain may store the source domain PPN in a temporary buffer. For example, for Figure 2 , resources belonging to the controller 214 of the first local domain 206 may retrieve the PPN from the L2P LUT 218 and store the PPN in a temporary buffer.

[0111] Concurrently, at 710, a driver controller (eg, Figure 2 The driver controller 214 may apply a hash function to the LPN. At 712, the driver controller may determine whether a conflict is detected. If a conflict is detected, the driver controller may perform conflict resolution at 714. Subsequently, at 716, the driver controller may use the hashed LPN to determine a cross-domain PPN via the cross-domain L2P LUT. At 718, the driver controller may provide the cross-domain PPN to a temporary buffer.

[0112] At 720, a driver controller (eg, Figure 2 The controller 214 of the source domain may determine whether the source domain PPN is a cross-domain ID. The cross-domain ID may be a fixed value that identifies a cross-domain access from the source domain to the redirected domain. If the source domain PPN is not a cross-domain ID, then at 722, the resource belonging to the controller of the source domain may extract the source domain NAND data indexed by the source domain PPN. For example, for Figure 2 , resources belonging to the controller 214 of the first local domain 206 can extract the NAND data of the first local domain 206.

[0113] If the source domain PPN is a cross-domain ID, then at 724, the resources belonging to the controller of the redirect domain may extract the redirect domain NAND data indexed by the cross-domain PPN, and at 726, the resources belonging to the controller of the redirect domain may send the redirect domain NAND data to the resources belonging to the controller of the source domain. Figure 2 , the resources belonging to the controller 214 of the eighth local domain 210 can extract the NAND data of the eighth local domain 210 and send the NAND data to the resources belonging to the controller 214 of the first local domain 206.

[0114] Figure 8 FIG. 1 is a flow chart illustrating domain wear balancing for a write command according to another embodiment. The host may create a write command that will typically be written to the originating domain. Figure 6 As described, the host may submit a write command to the drive, and the drive may extract and parse the write SQE, convert the NS and LBA to LPN, and route the write command to the originating domain. At 802, the drive controller may receive a global LPN for the write command and may perform domain partitioning at 804. At 806, the drive controller may determine whether the write command will cross domains. For example, for Figure 2 , the controller 214 may determine that the write command received at the SSD 204 will span between the first local domain 206 and the eighth local domain 210 .

[0115] If it is determined that the write command will not cross domains, then at 808, resources of the drive controller belonging to the source domain may apply the LPN to the source domain L2P LUT to determine the source domain PPN. Figure 2 , resources belonging to the controller 214 of the first local domain 206 can determine the PPN from the L2P LUT 218 .

[0116] At 810, the domain belonging to the source (e.g., Figure 2 A driver controller (eg, Figure 2 Resources of the drive controller 214 of the source domain can determine whether the source domain PPN is a cross-domain ID. The cross-domain ID can be a fixed value that identifies a cross-domain access from the source domain to the redirection domain. If the source domain PPN is not a cross-domain ID, then at 812, the resources of the drive controller belonging to the source domain can mark the old source PPN bitmap as invalid. If the source domain PPN is a cross-domain ID, then at 814, the resources of the drive controller belonging to the source domain can mark the redirection PPN bitmap as invalid. Subsequently, at 816, the resources of the drive controller belonging to the source domain can allocate a source domain PPN in the source erase pool using the trimmed LPN.

[0117] At 818, the domain belonging to the source (e.g., Figure 2 A driver controller (eg, Figure 2 Resources belonging to the source domain's driver controller 214 may mark the new source domain PPN bitmap as valid. At 820, resources belonging to the source domain's driver controller may update the source domain L2P LUT entry value to the new source domain PPN. At 822, resources belonging to the source domain's driver controller may program source domain NAND data indexed by the source domain PPN. At 824, resources belonging to the source domain's driver controller may program metadata including the global LPN.

[0118] Referring back to 806, if the write command will cross domains, then at 826, resources belonging to the drive controller of the source domain may apply the LPN to the source domain L2P LUT to determine the source domain PPN. Figure 2 , resources belonging to the controller 214 of the first local domain 206 can determine the PPN from the L2P LUT 218 .

[0119] At 828, the domain belonging to the source (e.g., Figure 2 A driver controller (eg, Figure 2the source domain PPN is not a cross-domain ID, the resources of the drive controller attributed to the source domain can mark the source domain PPN bitmap as invalid at 830, update the source L2P LUT entry value to the fixed cross-domain ID at 832, and apply the hash function at 834.

[0120] If the source domain PPN is a cross-domain ID, the resources of the drive controller attributed to the redirecting domain (e.g., the eighth native domain 210 of the storage device 200) can determine the old redirecting domain PPN using the cross-domain L2P LUT at 836, mark the redirecting domain PPN bitmap as invalid at 838, and update the redirecting domain L2P LUT entry value to the old redirecting domain PPN at 840. Figure 2 Figure 2 The resources of the drive controller attributed to the eighth native domain 210 of the storage device 200 can apply the hash function at 836, determine the old redirecting domain PPN using the cross-domain L2P LUT at 838, and mark the redirecting domain PPN bitmap as invalid at 840.

[0121] At 842, the resources of the drive controller attributed to the redirecting domain (e.g., the eighth native domain 210 of the storage device 200) can allocate a redirecting domain PPN in the redirecting erase pool. At 844, the resources of the drive controller attributed to the redirecting domain can mark the redirecting domain PPN bitmap as valid. At 846, the resources of the drive controller attributed to the redirecting domain can update the redirecting domain L2P LUT entry value to the redirecting PPN. At 848, the resources of the drive controller attributed to the redirecting domain can program the redirecting domain NAND data indexed by the redirecting domain PPN. At 850, the resources of the drive controller attributed to the redirecting domain can program the metadata including the global LPN. Figure 2 Figure 8 The resources of the drive controller attributed to the eighth native domain 210 of the storage device 200 can allocate a redirecting domain PPN in the redirecting erase pool at 842, mark the redirecting domain PPN bitmap as valid at 844, update the redirecting domain L2P LUT entry value to the redirecting PPN at 846, program the redirecting domain NAND data indexed by the redirecting domain PPN at 848, and program the metadata including the global LPN at 850.

[0122] GC can use the same host write. GC read can be based on PPN, and GC write insertion can be before the domain split (e.g., 804 of the storage device 200). The global LPN can be programmed as meta information in the NAND with data. Figure 9

[0123] ​​​Thus, wear level can be balanced by cross-domain read and write commands. Redirected read decisions can be deferred until source domain L2P lookup is complete. Concurrent independent source domain L2P LUT and redirected L2P LUT reduce redirect latency. A fixed ID can be used as a value in a source domain L2P LUT table entry to identify cross-domain access from one source domain to one redirected domain. Multiple fixed IDs can be used as values in a source L2P LUT entry to identify cross-domain access from one source domain to multiple redirected domains. A hashed global LPN can be used as a redirected domain L2P LUT index / key so that L2P LUT entry count can match cross-domain size requirements. Classic next-link can be applied to resolve hash collisions. Double hash function can be applied to reduce collision resolution latency. Global LPN can be programmed in metadata of NAND so that GC writes are identical to host writes.

[0124] Figure 1 is a block diagram of an electronic device in a network environment 900 for processing commands according to an embodiment. The electronic device can be one of various types of electronic devices utilizing a memory device as described above in Figure 6 and Figure 9 .

[0125] Referring to Figure 1 , an electronic device 901 in the network environment 900 can communicate with an electronic device 902 via a first network 998 (e.g., a short-range wireless communication network), or an electronic device 904 or a server 908 via a second network 999 (e.g., a long-range wireless communication network). The electronic device 901 can communicate with the electronic device 904 via the server 908. The electronic device 901 can include a processor 920, a memory 930, an input device 950, a sound output device 955, a display device 960, an audio module 970, a sensor module 976, an interface 977, a haptic module 979, a camera module 980, a power management module 988, a battery 989, a communication module 990, a subscriber identification module (SIM) card 996, or an antenna module 997. In one embodiment, at least one (e.g., the display device 960 or the camera module 980) of the components can be omitted from the electronic device 901, or one or more other components can be added in the electronic device 901. Some of the components can be implemented as single integrated circuit (IC) or multiple ICs. The sensor module 976 (e.g., a fingerprint sensor, an iris sensor, or an illuminance sensor) can be embedded in the display device 960 (e.g., a display) or implemented as a separate component.

[0126] The processor 920 can execute software (e.g., a program 940) to control at least one other component (e.g., a hardware or software component) of the electronic device 901 coupled with the processor 920 and can perform various data processing or computation. The program 940 can be stored in the memory 930 or transmitted from or through the communication module 990.

[0127] As at least a part of data processing or computation, the processor 920 can load a command or data received from a host or another component (e.g., the sensor module 976 or the communication module 990) into the volatile memory 932, process the command or the data stored in the volatile memory 932, and store resultant data in the non-volatile memory 934. The processor 920 can include a main processor 921 (e.g., a central processing unit (CPU) or an application processor (AP)) and an auxiliary processor 923 (e.g., a graphics processing unit (GPU), an image signal processor (ISP), a sensor hub processor, or a communication processor (CP)) that is operable independently from, or in conjunction with, the main processor 921. Additionally or alternatively, the auxiliary processor 923 can be adapted to consume less power than the main processor 921 or to perform a specific function. The auxiliary processor 923 can be implemented as separate from, or as part of, the main processor 921.

[0128] The auxiliary processor 923 can control at least some of the functions or states of at least one of the components of the electronic device 901 (e.g., the display device 960, the sensor module 976, or the communication module 990), instead of the main processor 921 while the main processor 921 is in an inactive (e.g., sleep) state, or together with the main processor 921 while the main processor 921 is in an active state (e.g., performing an application). The auxiliary processor 923 (e.g., an image signal processor or a communication processor) can be implemented as a part of another component functionally related to the auxiliary processor 923 (e.g., the camera module 980 or the communication module 990).

[0129] The memory 930 can store various data used by at least one component (e.g., the processor 920 or the sensor module 976) of the electronic device 901. The various data can include, for example, software (e.g., a program 940) and input data or output data about a command related thereto. The memory 930 can include the volatile memory 932 or the non-volatile memory 934. The non-volatile memory 934 can include the internal memory 936 and / or the external memory 938. The memory 930 can be embodied as a storage device 104 of FIG. 1. ​

[0130] The program 940 can be stored in the memory 930 as software, and can include, for example, an operating system (OS) 942, middleware 944, or an application 946.

[0131] ​The input device 950 can receive a command or data to be used by another component (e.g., the processor 920) of the electronic device 901, from the outside (e.g., a user) of the electronic device 901. The input device 950 can include, for example, a microphone, a mouse, or a keyboard.

[0132] The sound output device 955 can output sound signals to the outside of the electronic device 901. The sound output device 955 can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as playing multimedia or recording, and the receiver can be used for receiving an incoming call. The receiver can be implemented as separate from, or as part of, the speaker.

[0133] The display device 960 can visually provide information to the outside (e.g., a user) of the electronic device 901. The display device 960 can include, for example, a display, a hologram device, or a projector and a control circuit for controlling a corresponding one of the display, the hologram device, and the projector. The display device 960 can include a touch circuit adapted to detect a touch or a sensor circuit (e.g., a pressure sensor) adapted to measure the intensity of force incurred by the touch.

[0134] The audio module 970 can convert a sound into an electrical signal and vice versa. The audio module 970 can obtain sound from a microphone, or output sound through a speaker, a receiver, or an earphone.

[0135] The sensor module 976 can detect an operational state (e.g., power or temperature) of the electronic device 901 or an environmental state (e.g., a state of a user) external to the electronic device 901, and then generate an electrical signal or data value corresponding to the detected state. The sensor module 976 can include, for example, a gesture sensor, a gyro sensor, an atmospheric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an infrared (IR) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0136] The interface 977 can support one or more designated protocols for the electronic device 901 to be coupled with the external electronic device 902 directly (e.g., wiredly) or wirelessly. The interface 977 can include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, a secure digital (SD) card interface, or an audio interface.

[0137] The connection terminal 978 can include a connector through which the electronic device 901 can be physically connected with the external electronic device 902. The connection terminal 978 can include, for example, a HDMI connector, a USB connector, a SD card connector, or an audio connector (e.g., a headphone connector).

[0138] The haptic module 979 can convert electrical signal into a mechanical stimulus (e.g., vibration or movement) or electrical stimulus that can be recognized by a user via tactile feeling or kinesthetic sense. The haptic module 979 can include, for example, a motor, a piezoelectric element, or an electrical stimuluser.

[0139] The camera module 980 can capture a still image or moving images. The camera module 980 can include one or more lenses, image sensors, image signal processors, or flashes. The power management module 988 can manage power supplied to the electronic device 901. The power management module 988 can be implemented as at least a part of, for example, a power management integrated circuit (PMIC).

[0140] The battery 989 can supply power to at least one component of the electronic device 901. The battery 989 can include, for example, a primary cell which is not rechargeable, a secondary cell which is rechargeable, or a fuel cell.

[0141] The communication module 990 can support establishing a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device 901 and an external electronic device (e.g., the electronic device 902, the electronic device 904, or a server 908) and performing communication via the established communication channel. The communication module 990 can include one or more communication processors that are operable independently from the processor 920 (e.g., an AP) and support direct (e.g., wired) communication or wireless communication. The communication module 990 can include a wireless communication module 992 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 994 (e.g., a local area network (LAN) communication module or a power line communication (PLC) module). A corresponding communication module among the communication modules can communicate with the external electronic device via a first network 998 (e.g., a short-range communication network, such as BLUETOOTH, wireless-fidelity (Wi-Fi) direct, or infrared data association (IrDA)) or a second network 999 (e.g., a long-range communication network, such as a cellular network, the Internet, or a computer network (e.g., LAN or wide area network (WAN)). The various types of communication modules can be implemented as a single component (e.g., a single IC) or can be implemented as separate components (e.g., separate ICs) from each other. The wireless communication module 992 can identify and authenticate the electronic device 901 in a communication network, such as the first network 998 or the second network 999, using subscriber information (e.g., international mobile subscriber identity (IMSI)) stored in the subscriber identification module 996. TM

[0142] ​The antenna module 997 can transmit or receive a signal or power to or from an external electronic device (e.g., an external electronic device) of the electronic device 901. The antenna module 997 can include one or more antennas, and can, for example, select at least one antenna appropriate for a communication scheme used in a communication network, such as the first network 998 or the second network 999, from among the one or more antennas, by the communication module 990 (e.g., the wireless communication module 992). Then, communication can be performed between the communication module 990 and the external electronic device via the selected at least one antenna, by transmitting or receiving a signal or power.

[0143] Commands or data can be transmitted or received between the electronic device 901 and an external electronic device 904 via the server 908 coupled with the second network 999. Each of the electronic devices 902 and 904 can be a device of a same type as or different from the electronic device 901. All or some of the operations to be executed at the electronic device 901 can be executed at one or more of the external electronic devices 902, 904, or 908. For example, if the electronic device 901 should perform a function or a service automatically, or in response to a request from a user or another device, the electronic device 901, instead of, or in addition to, executing the function or the service, can request one or more external electronic devices to perform at least part of the function or the service. The one or more external electronic devices receiving the request can perform at least part of the requested function or service, or an additional function or an additional service related to the request, and transfer an outcome to the electronic device 901. The electronic device 901 can provide the outcome, with or without further processing of the outcome, as at least part of a reply to the request. To that end, a cloud computing, distributed computing, or client-server computing technology can be used, for example.

[0144] Embodiments of the subject matter and operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a computer storage medium for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions can be encoded as propagated signals, e.g., machine-generated electrical, optical, or electromagnetic signals, that are generated to encode information for transmission to suitable receiver apparatus for execution by a data processing apparatus. The computer storage medium can be, or include, a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of them. Moreover, while a computer storage medium is not a propagated signal, a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or include, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices) within or across multiple systems. Additionally, the described operations can be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0145] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any claims, but rather as descriptions of features specific to particular embodiments. Certain features described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features can be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination and the claimed combination can be directed to a subcombination or variation of a subcombination.

[0146] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring such order, nor that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing can be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated in a single software product or packaged into multiple software products.

[0147] Accordingly, particular embodiments of the subject matter have been described herein. Other embodiments are within the scope of the following claims. In some cases, actions recited in the claims can be performed in a different order and still achieve desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing can be advantageous.

[0148] Although certain embodiments of the disclosure have been described in the detailed description of the disclosure, the disclosure can be modified in various forms without departing from the scope of the disclosure. Accordingly, the scope of the disclosure should not be determined only based on the described embodiments, but based on the appended claims and their equivalents.

Claims

1. A method for wear leveling of a storage device, comprising: receiving a command at a controller of the storage device, wherein a logical capacity of the storage device is divided into domains; determining, by the controller, a logical address associated with the command, wherein the logical address is associated with a first domain of the storage device; and based on a physical address associated with the logical address, rerouting the command from a first resource of the controller attributed to the first domain to a second resource of the controller attributed to a second domain of the storage device.

2. The method of claim 1, wherein, the physical address is an invalid physical page number (PPN) retrieved from a first logical-to-physical (L2P) lookup table (LUT) of the first domain, wherein rerouting the command includes rerouting a logical page number (LPN) from the first L2P LUT to a second L2P LUT of the second domain, and wherein the first domain has more wear than the second domain.

3. The method of claim 2, further comprising: configuring a L2P reroute table with a portion of L2P LUT entries that were not used in defining PPNs, wherein the L2P reroute table tracks the LPNs that are routed from the first L2P LUT to the second L2P LUT.

4. The method of claim 3, wherein, the LPN is indicated as being rerouted by a flag that enables the second resource of the controller attributed to the second domain to retrieve a physical location from the L2P reroute table.

5. The method of claim 3, wherein, the command includes a read command routed to the first resource of the controller attributed to the first domain, and executing the command includes: based on the read command, determining that a PPN value from the first L2P LUT is invalid; determining an offset in the L2P reroute table by subtracting a last valid PPN value in the first domain from the PPN value; and based on the offset in the L2P reroute table, determining a new PPN value, wherein the new PPN value is a physical location in the second domain.

6. The method of claim 3, wherein, the command includes a garbage collection command routed to the first resource of the controller attributed to the first domain, and executing the command includes: triggering garbage collection across a superblock of the first domain; reading valid LPNs and writing the valid LPNs to a new superblock; and updating L2P information in the first L2P LUT and the L2P reroute table.

7. The method of claim 3, wherein, the command includes a write command routed to the first resource of the controller attributed to the first domain, and executing the command includes: buffering data of the write command; based on the write command, determining that a PPN value from the first L2P LUT indicates rerouting to the second domain and a physical location in the second domain; and sending the write command and the buffered data to the second resource of the controller attributed to the second domain.

8. The method of claim 3, wherein, the command includes a write command routed to the first resource of the controller attributed to the first domain, and executing the command includes: buffering data of the write command; invalidate a physical location indicated in the first L2P LUT based on the write command; update the physical location based on a value of the L2P re-routing table; assign a temporary value to the L2P re-routing table, the temporary value pointing to buffered data of the write command; pass the write command and the temporary value from the first resource of the controller assigned to the first domain to the second resource of the controller assigned to the second domain; execute the write command by sending the buffered data to the second resource of the controller assigned to the second domain; and change the temporary value of the L2P re-routing table to a physical location of the data in the second domain.

9. The method of claim 2, further comprising: configuring a re-direct L2P LUT, wherein executing the command includes concurrently using the first L2P LUT and the re-direct L2P LUT.

10. The method of claim 9, wherein, a first PPN entry of the first L2P LUT includes a first cross-domain identifier (ID) identifying cross-domain access to the second domain.

11. The method of claim 10, wherein, a second PPN entry of the first L2P LUT includes a second cross-domain identifier (ID) identifying cross-domain access to a third domain of the domains.

12. The method of claim 9, further comprising: performing a hash function on an LPN of the command to reduce the LPN for an entry of the re-direct L2P LUT.

13. The method of claim 1, wherein: the first resource includes first hardware and firmware resources dedicated to the first domain and the second resource includes separate second hardware and firmware resources dedicated to the second domain; or the first resource and the second resource include hardware and firmware resources used on a round-robin basis between the first domain and the second domain.

14. A storage device, comprising: a controller; and a non-transitory computer-readable storage medium having a logical capacity partitioned into domains and storing instructions that, when executed, cause the controller to: receive a command; determine a logical address associated with the command, wherein the logical address is associated with a first domain; and re-route the command from a first resource of the controller assigned to the first domain to a second resource of the controller assigned to a second domain based on a physical address associated with the logical address.

15. The storage device of claim 14, wherein, the physical address is an invalid physical page number (PPN) retrieved from a first logical-to-physical (L2P) lookup table (LUT) of the first domain, wherein re-routing the command includes re-routing a logical page number (LPN) from the first L2P LUT to a second L2P LUT of the second domain, and wherein the first domain has more wear than the second domain.

16. The storage device of claim 15, wherein, the instructions further cause the controller to: configure an L2P re-routing table with a portion of L2P LUT entries not used in defining PPNs, wherein the L2P re-routing table tracks the LPNs routed from the first L2P LUT to the second L2P LUT.

17. The storage device of claim 16, wherein, The LPN is indicated by a flag to be re-routed, the flag enabling the second resources of the controller belonging to the second domain to retrieve a physical location from the L2P re-routing table.

18. The storage device of claim 14, wherein, The instructions further cause the controller to: configure a re-direction L2P LUT, wherein executing the command includes concurrently using the first L2P LUT and the re-direction L2P LUT, and wherein a first PPN entry of the first L2P LUT includes a first cross-domain identifier (ID) identifying cross-domain access to the second domain.

19. The storage device of claim 18, wherein, A second PPN entry of the first L2P LUT includes a second cross-domain identifier (ID) identifying cross-domain access to a third domain of the domains.

20. The storage device of claim 18, wherein, The instructions further cause the controller to: perform a hash function on the LPN of the command to reduce the LPN for an entry of the re-direction L2P LUT.

Images