System, method, and device for updating usage of a reclamation unit based on references in a storage device

Abstract

A storage device may include at least one storage medium and a controller, the controller including at least one processor configured to perform an update operation associated with a recycling unit handle that references at least one recycling unit of the at least one storage medium, read data from a first recycling unit of the at least one storage medium based on the update operation, and write data to a second recycling unit of the at least one storage medium based on the update operation. Based on the update operation, the second recycling unit may be associated with the recycling unit handle. The first recycling unit may be associated with the recycling unit handle. The recycling unit handle may be a first recycling unit handle, and the first recycling unit may be associated with the second recycling unit handle.

Description

Technical Field

[0001] The present disclosure relates generally to storage devices and, more particularly, to systems, methods, and apparatus for data placement in storage devices. Background Art

[0002] Storage devices such as solid-state drives (SSDs) can store data in a storage medium that can be implemented using non-volatile memory (NVM). In some non-volatile memories, data can be updated by erasing the memory storing the data and rewriting the new data in the erased memory. Some non-volatile memories can be written and / or read in units of pages, but are erased in units of blocks that may include multiple pages. Therefore, in order to update data stored in a page of non-volatile memory, valid data stored in other pages in the same block can be copied to a different block to prevent the loss of valid data when the block is erased.

[0003] The above information disclosed in this Background section is only for enhancement of understanding of the background of the inventive concept and therefore it may contain information that does not constitute the prior art. Summary of the Invention

[0004] A storage device may include at least one storage medium and a controller. The controller may include at least one processor configured to perform an update operation associated with a reclaim unit handle referencing at least one reclaim unit of the at least one storage medium, read data from a first reclaim unit of the at least one storage medium based on the update operation, and write data to a second reclaim unit of the at least one storage medium based on the update operation. Based on the update operation, the second reclaim unit may be associated with the reclaim unit handle. The first reclaim unit may be associated with the reclaim unit handle. The reclaim unit handle may be the first reclaim unit handle, and the first reclaim unit may be associated with the second reclaim unit handle. The at least one processor may be configured to perform a reclaim operation on the first reclaim unit based on the update operation. The at least one processor may be configured to fill the second reclaim unit based at least in part on the update operation. The data may be first data, and the at least one processor may be configured to read second data from a third reclaim unit of the at least one storage medium and write the second data to the second reclaim unit. The third reclaim unit may be associated with the reclaim unit handle. Based on the update operation, the first reclaim unit may be associated with the reclaim unit handle. The data may be first data, the first data may be written to a first portion of the second reclaim unit, and at least a second portion of the second reclaim unit includes the second data associated with the reclaim unit handle. The data may be first data, the first data may be written to a first portion of a second recycling unit, the recycling unit handle may be the first recycling unit handle, and at least a second portion of the second recycling unit includes second data associated with the second recycling unit handle. The at least one processor may be configured to perform a recycling operation on the first recycling unit based on an update operation. The update operation may include modifying the recycling unit handle.

[0005] A method may include performing an update operation associated with a recycling unit handle that references at least one recycling unit of at least one storage medium, reading data from a first recycling unit of the at least one storage medium based on the update operation, and writing data to a second recycling unit of the at least one storage medium based on the update operation. The second recycling unit may be associated with the recycling unit handle. The first recycling unit may be associated with the recycling unit handle. The recycling unit handle may be a first recycling unit handle, and the first recycling unit may be associated with the second recycling unit handle. Based on the update operation, the first recycling unit may be associated with the recycling unit handle. The update operation may include modifying the recycling unit handle.

[0006] A storage device may include at least one storage medium and a controller, the controller may include at least one processor configured to perform an update operation associated with a reclamation unit of the at least one storage medium, wherein a first portion of the reclamation unit includes data, and the update operation may include referencing a second portion of the reclamation unit and at least a portion of over-provisioned space associated with the reclamation unit via a reclamation unit handle. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The drawings are not necessarily drawn to scale, and throughout the drawings, for illustrative purposes, elements of similar structure or function may generally be represented by similar reference numerals or portions thereof. The drawings are merely for the purpose of facilitating the description of the various embodiments described herein. The drawings do not describe every aspect of the teachings disclosed herein and do not limit the scope of the claims. To prevent the drawings from becoming obscure, not all components, connections, etc. are shown, and not all components have reference numerals. However, the pattern of component configuration can be easily seen from the drawings. The drawings, together with the specification, illustrate example embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0008] Figure 1A An embodiment of a data placement scheme of a storage device in a first data placement state according to an example embodiment of the present disclosure is illustrated.

[0009] Figure 1B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown.

[0010] Figure 1C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown.

[0011] Figure 1D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown.

[0012] Figure 1E FIG. 1 shows a diagram of a data storage medium in a fifth data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown.

[0013] Figure 2A An embodiment of a flexible data placement scheme of a storage device in a first data placement state according to an example embodiment of the present disclosure is illustrated.

[0014] Figure 2B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown.

[0015] Figure 2C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown.

[0016] Figure 2D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown.

[0017] Figure 3A An embodiment of a flexible data placement scheme using reference modification in a first data placement state according to an example embodiment of the present disclosure is illustrated.

[0018] Figure 3B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown.

[0019] Figure 3C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown.

[0020] Figure 3D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown.

[0021] Figure 4 An embodiment of a flexible data placement scheme utilizing a reclaim unit handle according to an example embodiment of the present disclosure is illustrated.

[0022] Figure 5 An embodiment of an initial isolation scheme for a flexible data placement scheme of a storage device according to an example embodiment of the present disclosure is shown.

[0023] Figure 6 An embodiment of a persistent isolation scheme for a flexible data placement scheme of a storage device according to an example embodiment of the present disclosure is shown.

[0024] Figure 7A An embodiment of an update operation of a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is illustrated.

[0025] Figure 7B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 7A An embodiment of an update operation is shown.

[0026] Figure 8A An embodiment of a flexible data placement scheme of a reclaim unit transferring data to a storage device in a first state according to an example embodiment of the present disclosure is shown.

[0027] Figure 8B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 8A The embodiment shown.

[0028] Figure 9A An embodiment of a flexible data placement scheme for transferring data to a reclamation unit using persistent isolation in a storage device in a first state according to an example embodiment of the present disclosure is shown.

[0029] Figure 9B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 9A The embodiment shown.

[0030] Figure 10A An embodiment of a flexible data placement scheme for transferring data to a reclamation unit using initial isolation in a storage device in a first state according to an example embodiment of the present disclosure is shown.

[0031] Figure 10B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 10A The embodiment shown.

[0032] Figure 11A A first embodiment of a data transmission operation for a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is shown.

[0033] Figure 11B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 11A An embodiment of a data transfer operation is shown.

[0034] Figure 12A A second embodiment of a data transmission operation with a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is shown.

[0035] Figure 12B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 12A An embodiment of a data transfer operation is shown.

[0036] Figure 13A An embodiment of a flexible data placement scheme for transferring data from a reclaim unit in a storage device in a first state according to an example embodiment of the present disclosure is shown.

[0037] Figure 13B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 13A The embodiment shown.

[0038] Figure 14 An example embodiment of a flexible data placement scheme utilizing data storage in over-provisioned space according to an example embodiment of the present disclosure is illustrated.

[0039] Figure 15 An example embodiment of a host device according to an example embodiment of the present disclosure that can be used to implement any host functionality disclosed herein is shown.

[0040] Figure 16 An example embodiment of a storage device according to an example embodiment of the present disclosure that can be used to implement any storage device functionality disclosed herein is shown.

[0041] Figure 17 An embodiment of a method for flexible data placement of a storage device according to an example embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0042] A storage device may implement a flexible data placement (FDP) scheme that enables a host to place data into one or more physical reclaim units (RUs) in the storage device. A reclaim unit may be implemented as a portion of the physical storage medium that can be erased as a unit (e.g., one or more erase blocks). This can reduce write amplification, for example, by enabling the host to place data that may be deallocated at the same time into the same reclaim unit.

[0043] A flexible data placement scheme can use a reclaim unit handle to enable a host to specify one or more reclaim units in a storage device to which the storage device can write data. For example, a host can send a write command to a storage device. The write command can specify the data to be written to the storage device. The write command can also include or provide a technique for indicating a reclaim unit handle to specify one or more reclaim units to which the storage device can write the data. At the storage device, the reclaim unit handle can initially reference the first reclaim unit to which the storage device can write the host-specified data.

[0044] The host may send one or more additional write commands specifying additional data to be written to the storage device using the same reclamation unit handle. The storage device may begin writing the additional data to a first reclamation unit referenced by the reclamation unit handle. When the first reclamation unit becomes full, the storage device may modify the reclamation unit handle to reference a second reclamation unit to which the storage device can continue writing data. Although the reclamation unit handle no longer references the first reclamation unit (this state may be referred to as being dereferenced or previously referenced), the first reclamation unit may remain associated with the reclamation unit handle to indicate that it was written using the reclamation unit handle.

[0045] A flexible data placement scheme may implement an update operation that may modify a reclaim unit handle to reference a different reclaim unit, such as an empty reclaim unit. For example, a host may request an update operation. However, if a first reclaim unit referenced by the reclaim unit handle is not full when the update operation modifies the reclaim unit handle to reference a second reclaim unit, the first reclaim unit may remain only partially full. Depending on the physical storage medium used to implement the first reclaim unit, leaving the reclaim unit partially full may reduce the reliability, durability, performance, etc. of the reclaim unit and / or the storage medium implementing the reclaim unit. Therefore, the flexible data placement scheme may fill some or all unfilled portions of a previously referenced reclaim unit with fill data such as zeros, random data, and / or controller metadata. However, the use of fill data may result in wasted or underutilized storage space.

[0046] A flexible data placement scheme according to an example embodiment of the present disclosure can transfer data between recycling units based on an update operation. For example, when a recycling unit handle references a partially full first recycling unit, and an update operation modifies the recycling unit handle to reference a second (e.g., empty) recycling unit, data can be read from one or more additional recycling units (e.g., a third recycling unit and / or a fourth recycling unit) and written to the empty portion of the first recycling unit. The data read from the one or more additional recycling units can include, for example, valid user data that would otherwise be moved as part of one or more garbage collection operations that can erase or recycle one or more additional recycling units. Depending on the implementation details, this can reduce write amplification, for example, by using program cycles that would have been used to store fill data in the first recycling unit to store valid data from the one or more additional recycling units.

[0047] As another example of transferring data between reclamation units based on an update operation, when a reclamation unit handle references a partially full first reclamation unit, and the update operation modifies the reclamation unit handle to reference a second (e.g., empty) reclamation unit, data can be moved or copied from one or more filled portions of the first reclamation unit to one or more additional reclamation units. Depending on implementation details, this can enable the first reclamation unit to be erased, returned to a pool of available (e.g., empty, erased, etc.) memory for later reuse, and / or otherwise reclaimed.

[0048] In some embodiments, depending on, for example, the isolation scheme, data that may be retained in a recycling unit and / or transferred between recycling units based on update operations may be referenced by the same or different recycling unit handles and / or associated with the same or different recycling unit handles. For example, some embodiments may implement a persistent isolation scheme in which data written to a first recycling unit using a first recycling unit handle may only be combined (e.g., in a third recycling unit) with data written to one or more additional recycling units using the first recycling unit handle (e.g., during a garbage collection operation). Thus, in a persistent isolation scheme, data that may be retained in a recycling unit and / or transferred between recycling units based on update operations may only be referenced by the same recycling unit handle and / or associated with the same recycling unit handle. In some embodiments, a recycling unit may be said to be associated with a recycling unit handle if at least a portion of the recycling unit is written using a recycling unit handle.

[0049] As another example, some embodiments may implement an initial isolation scheme in which data written to a first reclamation unit using a first reclamation unit handle may be combined (e.g., in a third reclamation unit) with data written to one or more other reclamation units using one or more other reclamation unit handles (e.g., during a garbage collection operation). Thus, in the initial isolation scheme, data that may remain in a reclamation unit and / or be transferred between reclamation units based on update operations may be referenced by and / or associated with more than one reclamation unit handle.

[0050] Additionally or alternatively, a flexible data placement scheme according to an example embodiment of the present disclosure may store data in one or more overprovisioning spaces associated with one or more recycling units. For example, if a recycling unit handle references a recycling unit with associated overprovisioning space, and when an update operation is requested, the referenced recycling unit is only partially full, the recycling unit handle may remain unchanged, and at least a portion of the overprovisioning space may be used to store user data written to the recycling unit in response to one or more write commands that may specify the recycling unit handle, rather than modifying the recycling unit handle to reference a different (e.g., empty) recycling unit. In some embodiments, this may be characterized as modifying the recycling unit based on the update request, rather than, or in addition to, modifying the recycling unit handle.

[0051] As another example of using overprovisioned space associated with a recycling unit, if a recycling unit is full (or almost full) when an update operation is performed, data from another recycling unit (e.g., valid user data in a previously referenced recycling unit) can be transferred to at least a portion of the overprovisioned space associated with the recycling unit (and / or to an empty portion of the recycling unit).

[0052] This disclosure incorporates numerous inventive principles related to flexible data placement. The principles disclosed herein may have independent utility and may be implemented individually, and not every embodiment may utilize every principle. Furthermore, these principles may be embodied in various combinations, some of which may synergistically amplify certain benefits of individual principles.

[0053] For illustrative purposes, some embodiments may be described in the context of specific implementation details, such as a storage device implemented with a solid-state drive (SSD) using non-AND (NAND) flash memory, non-volatile memory express (NVMe) protocol, etc. However, the inventive principles are not limited to these or any other implementation details. For example, some embodiments may implement a storage medium having flash memory, magnetic media, storage class memory (SCM), etc., or any combination thereof.

[0054] In some embodiments where the storage medium may be implemented at least in part with flash memory, a reclamation unit may refer to one or more erase blocks, NVM devices (e.g., NVM dies), etc., or any combination thereof, and a reclamation group may refer to one or more reclamation units, one or more NVM device partitions (e.g., planes), one or more NVM devices (e.g., NVM dies), one or more storage devices (e.g., storage drives), etc., or any combination thereof.

[0055] In some embodiments where the storage medium may be implemented at least in part with magnetic media (e.g., shingled magnetic recording (SMR) media), a recycling unit may refer to one or more shingled segments, zones, sectors, tracks, etc., or any combination thereof, and a recycling group may refer to one or more disks (e.g., drives), platters, tracks, zones, sectors, shingled segments, etc., or any combination thereof.

[0056] In some embodiments where the storage medium may be implemented at least in part with a storage class memory (e.g., magnetoresistive random access memory (MRAM), resistive random access memory (ReRAM), phase change memory (PCM), cross-grid non-volatile memory, memory with body resistance change, etc.), a recycling unit may refer to one or more memory banks, programming groups, etc., or any combination thereof, and a recycling group may refer to one or more dies, memory banks, programming groups, etc., or any combination thereof.

[0057] Figure 1A An embodiment of a data placement scheme of a storage device in a first data placement state according to an example embodiment of the present disclosure is illustrated. Figure 1B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown. Figure 1C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown. Figure 1D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown. Figure 1E FIG. 1 shows a diagram of a data storage medium in a fifth data placement state according to an exemplary embodiment of the present disclosure. Figure 1A An embodiment of a data placement scheme is shown.

[0058] Figure 1A 、 Figure 1B 、 Figure 1C 、 Figure 1D and / or Figure 1E May be collectively and / or individually referred to as FIG. 1 .

[0059] The embodiment shown in FIG1 may include a host 102 and a storage device 104 communicating using a communication connection 105. Storage device 104 may include storage media in an NVM subsystem 106 having memory blocks 108 arranged in super blocks 110. Memory blocks 108 may be implemented using non-volatile memory that can be erased in units of blocks as shown in FIG1 and, therefore, may also be referred to as erase blocks. Memory blocks 108 may be programmed (e.g., written to) and / or read in units of pages and / or word lines, which are smaller than a memory block. Memory blocks 108 may be erased before pages and / or word lines of data can be written thereto. For example, memory blocks 108 may be arranged in super blocks 110 to simplify management of memory blocks 108. Therefore, the non-volatile memory shown in FIG1 may be erased in units of super blocks 110.

[0060] The storage device 104 may receive input and / or output (I / O or IO) requests (also referred to as commands) from the host 102 to enable the host to access the NVM subsystem 106 (e.g., to write data to a storage medium and / or to read data from a storage medium). The host 102 may divide the data into namespaces indicated by different types of shading as shown in FIG1 . Specifically, data belonging to a first namespace (which may be referenced by namespace identifier 1 (NSID 1)) may be indicated by diagonal shading from the upper right to the lower left, data belonging to a second namespace (which may be referenced by NSID 2) may be indicated by diagonal shading from the upper left to the lower right, and data belonging to a third namespace (which may be referenced by namespace identifier NSID 3) may be indicated by diagonal cross-hatching. In some embodiments, in addition to and / or as an alternative to namespaces, the host 102 may partition and / or arrange data into groups based on logical block addresses (LBAs), one or more applications that may use the data, host write traffic threads, etc., for separating and / or managing data based on reclaim unit handles, reclaim units, erase units, etc.

[0061] Memory block 108 may initially be in an erased state, as indicated by the absence of shading. Before receiving a write command, NVM subsystem 106 may select an erased Super Block (e.g., Super Block 0, indicated by solid shading) in which to place the write data. The erased Super Block may be selected randomly or using a round robin technique. Thus, before NVM subsystem 106 receives a write command, memory block 108a may initially be empty.

[0062] refer to Figure 1A, storage device 104 may receive a first write command with write data belonging to NSID 1. NVM subsystem 106 may place the data belonging to NSID 1 (represented by the number 1 in the rounded rectangle) in the first memory block 108a of Super Block 0, as shown. Figure 1A (The number 1 may indicate the order in which the data is placed, rather than the NSID.)

[0063] refer to Figure 1B , the storage device 104 may continue to receive additional write commands from the host 102 with write data belonging to the various namespaces. The NVM subsystem 106 may fill the memory blocks 108a-108d in Super Block 0 by placing the write data in the order indicated by the numbers in the rounded rectangles. In some cases, the amount of write data may be greater than the space remaining in the memory blocks. Therefore, a first portion of the write data may be placed to fill the remaining space in the first memory block, while a second portion may be placed in an empty memory block. For example, Figure 1B As shown, upon receiving the second write command, the first portion 2a of the data belonging to NSID 2 may be used to fill the remaining space in memory block 108a, and the second portion 2b of the data belonging to NSID 2 may be placed in memory block 108b. Figure 1B As shown, NVM subsystem 106 may continue to place write data into Super Block 0 until Super Block 0 is full or nearly full.

[0064] refer to Figure 1C , storage device 104 may receive a sixth write command with data belonging to NSID 3 that is too large to fit in the remaining space in memory block 108d in Super Block 0. Therefore, NVM subsystem 106 may select a new empty Super Block (e.g., Super Block 2 indicated by solid shading) in which the write data may be placed. NVM subsystem 106 may fill the remaining space in memory block 108d with the first portion 6a of the data belonging to NSID 3, and the second portion 6b of the data belonging to NSID 3 may be placed in memory block 108e in Super Block 2. NVM subsystem 106 may continue to place the write data in Super Block 2 and then in Super Block 1, where data belonging to different namespaces are intermixed in one or more Super Blocks, as shown in FIG. Figure 1D Data belonging to different namespaces may be intermixed in blocks 108 and / or superblocks 110 , for example, because host 102 may not be aware of and / or have no control over how NVM subsystem 106 places data in memory blocks 108 and / or superblocks 110 .

[0065] The host 102 can partition data into namespaces, for example, to provide isolation between data sources such as applications, processes, logical block address (LBA) ranges, etc. Thus, the host 102 can release some or all data belonging to a namespace simultaneously, for example, when an application terminates.

[0066] Figure 1E An example is shown in which the host 102 has freed data belonging to a namespace indicated as NSID 3, which is shown with solid shading after the freeing. Reusing the freed storage space may include erasing the freed storage space. However, because Super Block 110 can be erased as a unit, NVM subsystem 106 may move the remaining valid data in the Super Block to a different Super Block to prevent loss of valid data when the Super Block is erased. Depending on the implementation details, this may result in write amplification, thereby shortening the useful life of the storage media.

[0067] Figure 2A An embodiment of a flexible data placement scheme of a storage device in a first data placement state according to an example embodiment of the present disclosure is illustrated. Figure 2B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown. Figure 2C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown. Figure 2D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 2A An embodiment of a data placement scheme is shown.

[0068] Figure 2A 、 Figure 2B 、 Figure 2C and / or Figure 2D May be collectively and / or individually referred to as FIG. 2 .

[0069] The embodiment shown in FIG2 may include several components, such as a host 202, a storage device 204, a communication connection 205, and / or memory blocks 208, which in some respects may operate in a manner similar to the corresponding components in the embodiment shown in FIG1. ​​However, in the embodiment shown in FIG2, the memory blocks 208 in the NVM subsystem 212 may be arranged in one or more reclaim units 214, which may be erased as a unit and may include one or more memory blocks 208. The reclaim units 214 may be implemented, for example, using one or more erase blocks, super blocks, etc. In addition, the reclaim units 214 may be identified by corresponding reclaim unit handles 236, which may enable the host 202 to specify (e.g., in a field of a write command) a specific reclaim unit 214 for storing write data associated with a write command. In some embodiments, some or all reclaim units 214 may be arranged in one or more reclaim groups 218, which the host 202 may also specify, for example, using one or more corresponding reclaim group identifiers (e.g., in a field of a write command). In some embodiments, a reclaim unit handle 236 may identify more than one reclaim unit 216. For example, a reclaim unit handle 236 may identify (e.g., map to) one or more reclaim units 216 in one or more (e.g., each) reclaim group 218 (e.g., in a manner similar to Figure 4 as shown.)

[0070] Thus, by designating particular reclaim units 214 and / or reclaim groups 218 for storing data associated with a write command, host 202 can cause NVM subsystem 212 to store only data belonging to one or more particular namespaces in one or more reclaim units 214 and / or reclaim groups 218 .

[0071] For example, reference Figure 2A , the host 202 may instruct the NVM subsystem 212 to store the data belonging to the namespaces indicated by NSID 1, NSID 2, and NSID 3 in reclaim unit 0, reclaim unit 1, and reclaim unit 2, respectively, in the order indicated by Figure 2AThe numbers in the rounded rectangles in are indicated and are indicated by the numbers in the parentheses below. For example, data [1] of the first write command associated with NSID 1 may be written to the first portion of the top memory block 208 of recycling unit 0 of recycling group 0. The first portion of data [2a] of the second write command associated with NSID 1 may be written to the remaining portion of the top memory block 208 of recycling unit 0 of recycling group 0, and the second portion of data [2b] of the second write command associated with NSID 1 may be written to the first portion of the second memory block 208 starting from the top of recycling unit 0 of recycling group 0. Data [3] of the third write command associated with NSID 2 may be written to the first portion of the top memory block 208 of recycling unit 1 of recycling group 0. Data [4] of the fourth write command associated with NSID 3 may be written to the first portion of the top memory block 208 of recycling unit 0 of recycling group 1. Data [5] of the fifth write command associated with NSID 3 may be written to the next portion of the top memory block 208 of recycling unit 0 of recycling group 1. The data [6] of the sixth write command associated with NSID 1 may be written to the next portion of the second memory block 208 from the top of reclaim unit 0 of reclaim group 0. The first portion of data [7a] of the seventh write command associated with NSID 1 may be written to the remaining portion of the second memory block 208 from the top of reclaim unit 0 of reclaim group 0, and the second portion of data [7b] of the seventh write command associated with NSID 1 may be written to the first portion of the third memory block 208 from the top of reclaim unit 0 of reclaim group 0. The first portion of data [8a] of the eighth write command associated with NSID 2 may be written to the remaining portion of the top memory block 208 of reclaim unit 1 of reclaim group 0, and the second portion of data [8b] of the eighth write command associated with NSID 2 may be written to the first portion of the second memory block 208 from the top of reclaim unit 1 of reclaim group 0. The first portion of data [9a] of the ninth write command associated with NSID 3 may be written to the remaining portion of the top memory block 208 of recycling unit 0 of recycling group 1, and the second portion of data [9b] ​​of the ninth write command associated with NSID 3 may be written to the first portion of the second memory block 208 from the top of recycling unit 0 of recycling group 1.

[0072] refer to Figure 2B , the host 202 can continue to send write commands and associated write data, and the host 202 can instruct the NVM subsystem 212 to use the write commands in the order indicated by the numbers in the rounded rectangles to store these write commands and associated write data in the recycling units corresponding to each namespace, and the numbers in the rounded rectangles can correspond to the data of the associated write commands.

[0073] refer to Figure 2C , the host may release some or all of the data belonging to NSID 1, as shown by the solid shading. For example, data associated with any of the first, second, sixth, seventh, thirteenth, fourteenth, and / or seventeenth write commands may be released at different times (with different amounts of time between them), at different times, in various combinations, or all at once. Depending on the implementation details, this may enable the NVM subsystem 212 to erase reclaim unit 0 (e.g., Figure 2D ), without moving data belonging to other namespaces, thereby reducing or eliminating write amplification. Figure 2D A reclaim unit handle 236 may be shown referencing a reclaim unit 214 having one or more memory blocks 208 that may be erased, but in some embodiments, one or more freed memory blocks 208 may be returned to the free memory pool before being erased. Figure 2D The memory block 208 indicated as erased in the Figure 2C 236) and are arranged into a new (e.g., empty) reclaim unit 214. In some embodiments, in addition to and / or as an alternative to namespaces, data can be divided and / or arranged into groups based on logical block addresses (LBAs), one or more applications that can use the data, host write traffic threads, etc., for separation and / or management of data based on reclaim unit handles, reclaim units, erase units, etc.

[0074] Figure 3A An embodiment of a flexible data placement scheme using reference modification in a first data placement state according to an example embodiment of the present disclosure is illustrated. Figure 3B FIG. 1 shows a diagram of a data storage medium in a second data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown. Figure 3C FIG. 1 shows a diagram of a data storage medium in a third data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown. Figure 3D FIG. 1 shows a fourth data placement state according to an exemplary embodiment of the present disclosure. Figure 3A An embodiment of a data placement scheme is shown.

[0075] Figure 3A 、 Figure 3B 、 Figure 3C and / or Figure 3D May be collectively and / or individually referred to as FIG. 3 .

[0076] The embodiment shown in Figure 3 can include a host 302 and a storage device 304 that communicate using a communication connection 305. The storage device 304 can include a controller 326 (which can control the overall operation of the storage device 304) and a storage medium that includes recycling units 314 arranged in one or more recycling groups 318. In Figure 3, one recycling group 318, referred to as recycling group 0, is shown, but recycling units 314 can be arranged in any number of recycling groups 318. For illustrative purposes, in the embodiment shown in Figure 3, recycling group 0 can include five recycling units 314 identified as RU 0, RU 1, RU 2, RU 3, and RU 4, each recycling unit can have a storage capacity of five pages of data, but any number and / or size of recycling units can be used. For example, in actual implementations, a recycling unit can include one, two, four, or more erase blocks, each of which can have a storage capacity measured in MB or GB and a page size measured in KB.

[0077] One or more recycling unit handles 336 may reference corresponding recycling units 314. For example, Figure 3A As shown, a first reclaim unit handle 336 identified as reclaim unit handle 0 (or RUH 0) may reference RU 1 as indicated by arrow 317. A second reclaim unit handle 336 identified as reclaim unit handle 1 (RUH 1) may reference RU 4 as indicated by arrow 319a.

[0078] refer to Figure 3A , the storage device 304 can be shown as being in an initial state, where two pages of data can be stored in the reclaim unit 314 identified as RU 1, and four pages of data can be stored in the reclaim unit 314 identified as RU 4, as shown by the diagonal shading of RU 1 and RU 4.

[0079] The host 302 may use the communication connection 305 to send a write command 330 and a data page 321 (or an address, pointer, or other indicator of the location of the data page 321) to the storage device 304. The write command 330 may include a placement identifier 334, which may include a reclaim group identifier 315 and / or a reclaim unit handle 336. In the example shown in FIG3 , the reclaim group identifier 315 and the reclaim unit handle 336 may instruct the storage device 304 to store the data page 321 at the reclaim unit 314 referenced by the reclaim unit handle 1 in the reclaim group 0.

[0080] In some embodiments, the write command 330 and / or placement identifier 334 may use different techniques to specify the reclamation unit to which the data page 321 is to be written. For example, rather than directly providing a reclamation unit handle 336, the write command 330 and / or placement identifier 334 may include a placement handle that may specify a reclamation unit handle, e.g., as described in reference to FIG. Figure 4 As shown in the described embodiments.

[0081] refer to Figure 3B , the controller 326 may receive a write command 330 and / or a data page 321. Based on the reclaim group identifier 315 and the reclaim unit handle 336 included in the placement identifier 334 in the write command 330, the controller 326 may determine that the data page 321 should be stored in the reclaim unit 314 referenced by the reclaim unit handle 1 in the reclaim group 0. Figure 3B In the example shown, the reclaim unit handle 1 may reference the reclaim unit 314 identified as RU 4, and thus the controller 326 may Figure 3C Data page 321 is shown stored in RU 4.

[0082] refer to Figure 3D , data page 321 may have filled reclaim unit 314 indicated as RU 4, as shown by the diagonal shading. Therefore, as shown by arrow 319b, controller 326 may modify reclaim unit handle 1 to reference a different (e.g., empty) reclaim unit 314 (such as RU 2) within reclaim group 0. Controller 326 may then proceed to fill RU 2 with data received from the host using write command 330, which specifies reclaim unit handle 1 in placement identifier 334.

[0083] Figure 4 An embodiment of a flexible data placement scheme utilizing a reclaim unit handle according to an example embodiment of the present disclosure is illustrated. Figure 4 The illustrated embodiment may include a controller 426 and an NVM subsystem 412, which may be located, for example, in a storage device. The NVM subsystem 412 may include P recycling groups 418, identified as recycling group 0 through recycling group P-1. A recycling group 418 may include one or more recycling units 414.

[0084] The controller 426 may receive I / O commands 430 from the host via the communication interface 428. Figure 4In the illustrated example, the I / O command 430, which may be a write command, may include a namespace identifier (NSID) 432 and / or a placement identifier 434. The placement identifier 434 may include a reclaim group identifier 415 and / or a placement handle 416, which may enable the host to specify a reclaim group 418 and / or a reclaim unit 414, respectively, within which to store data associated with the write command 430. Thus, in some embodiments, Figure 4 The illustrated scheme may enable the host to align data that may be freed together (eg, data belonging to a namespace) with one or more reclaim units 414 that may be erased as a unit.

[0085] In some embodiments, a placement handle 416 may be mapped to a reclaim unit handle (RUH) 436, which may reference one or more reclaim units 414 in one or more reclaim groups 418. For example, a reclaim unit handle 436 may be mapped to one reclaim unit 414 in each reclaim group 418. Figure 4 An example mapping from each reclaim unit handle 436 to a reclaim unit in each reclaim group 418 is shown. Figure 4 In the embodiment shown, the controller may use N reclaim unit handles 436, identified as reclaim unit handle 0 through reclaim unit handle N- 1. In some embodiments, the reclaim unit handles 436 may be characterized as controller resources.

[0086] The controller 426 may use the placement handle list 438 to map one or more placement handles 416 to one or more RUH identifiers (RUH IDs) 440, which in turn may identify corresponding reclaim unit handles 436. Figure 4 In the illustrated embodiment, drop handle list 438 may include M drop handles identified as drop handle 0 through drop handle M1.

[0087] In some embodiments, the scope of the placement handle 416 may be a namespace 424 (in this example, a namespace identified as namespace A). The namespace may, in turn, contain one or more (e.g., all) reclaim units 414 referenced by one or more reclaim unit handles 436 identified in a placement handle list 438 (e.g., by RUH ID 440). In some embodiments, the placement handle list 438 may be created, populated, modified, maintained, etc., by a host, a storage device (e.g., a controller 426), or any other entity or combination thereof. In some embodiments, in addition to and / or in lieu of namespaces, data may be partitioned and / or arranged into groups based on logical block addresses (LBAs), one or more applications that may use the data, host write traffic threads, etc., for purposes of separating and / or managing data based on reclaim unit handles, reclaim units, erase units, etc.

[0088] In some embodiments, the use of the placement handle 416 and / or the recycling unit handle 436 may enable Figure 4 The flexible data placement scheme shown can present a Reclamation Unit to the host as a logical representation of physical non-volatile storage within a Reclamation Group that can be physically erased by the controller 426, for example, without disturbing other Reclamation Units 414. The controller 426 can implement the logical Reclamation Units specified by the host (e.g., using placement identifiers 434) with physical storage media (e.g., one or more erase blocks on an NVM die) that can be selected by the controller 426 and erased as a unit.

[0089] In some embodiments, selection of a reclaim unit 414 and / or a reclaim group 418 can be performed, at least in part, by the controller 426. For example, if the controller 426 receives a write command 430 that does not include a placement identifier 434, the controller can use the reclaim unit handle 436 mapped by the default placement handle 416 (e.g., placement handle 0) and select a reclaim group 418, thereby selecting a reclaim unit 414 that is within the selected reclaim group 418 and referenced by the reclaim unit handle 436 mapped by the default placement handle 416. As another example, if the controller 426 receives a write command 430 with a placement identifier 434 that includes a placement handle 416 but does not include a reclaim group identifier 415, the controller 426 can select a reclaim unit 414 by selecting a reclaim group 418 and using a reclaim unit 414 that is within the selected reclaim group 418 and referenced by the reclaim unit handle 436 mapped by the placement handle 416 provided with the write command 430.

[0090] In some embodiments, Figure 4The flexible data placement scheme shown can be implemented at least in part using the NVMe protocol. In such an embodiment, the placement identifier 434 can be implemented as part of the write command 430 (e.g., the indication portion of the NVMe command); M, N and / or P can be parameters that can be configured, for example, using NVMe namespace management commands; the controller 426 can be implemented using one or more NVMe controllers; and / or the NVM subsystem 412 can be implemented as an NVMe subsystem, a durability group (which can be coextensive with the storage device in some embodiments), an NVMe domain, etc., or any combination thereof. In an embodiment implemented at least in part using the NVMe protocol, a command-specific (DSPEC) field can be used to provide a placement identifier (e.g., a reclaim group (which can be indicated by a reclaim group identifier) ​​and a placement handle). The DSPEC field can be used, for example, in one embodiment, where an indication type (DTYPE) field can be used to indicate that the flexible data placement feature is used. In such an embodiment, an invalid and / or default (e.g., all zero) value of the DSPEC field can indicate the absence of a reclaim group indicator and / or a placement handle.

[0091] In Figures 2, 3 and / or Figure 4 In the illustrated embodiment of the flexible data placement scheme, a reclaim unit may be implemented as a logical representation of an underlying portion of a physical storage medium (at least from the host's perspective). Thus, the host may be shielded from and / or unaware of one or more ongoing operations and / or conditions of the storage device that may adversely affect one or more operations involving the physical implementation of the logical reclaim unit selected by the host.

[0092] For example, in Figure 4 In the illustrated embodiment, the host may send a write command 430 with a placement identifier 434, which includes a reclaim group identifier 415 and a placement handle 416. The placement handle 416 may specify a particular reclaim unit 414 for storing the data associated with the write command. However, the controller 426 may have already implemented the specified reclaim unit 414 with a physical storage medium (e.g., a non-volatile memory (NVM) die) that may be busy with a read operation. Therefore, the write operation requested by the write command 430 may be delayed until the read operation is completed.

[0093] Other examples of ongoing operations and / or conditions of the storage device that may be unknown to the host and may adversely affect one or more operations involving the physical implementation of a logical reclaim unit selected by the host may include: NVM die management conflicts; programming operations involving programming data from a write buffer in the controller into a reclaim unit selected by the host; erase operations performed by the die containing the reclaim unit selected by the host; garbage collection operations involving the reclaim unit selected by the host, etc.

[0094] Additionally, to some extent, the host can gain insight into the NVM die by observing its behavior (e.g., NVM die programming delay, erase delay, etc.). Figure 4 The flexible data placement scheme shown is based on knowledge of one or more operations on the physical storage medium, which may be delayed by the host, for example, due to NVM channel delays, controller delays, communication connection delays (e.g., PCIe delays), host central processing unit (CPU) delays, etc.

[0095] In a flexible data placement scheme according to example embodiments of the present disclosure, a storage device selects a reclamation unit and / or a reclamation group (eg, for storing data associated with a write request) based on one or more operations and / or conditions of the storage device.

[0096] For example, as described above, in some cases (e.g., when the controller 426 receives a write command 430 that does not include a placement handle 416 or includes a placement handle 416 but not a reclaim group identifier 415), the controller 426 may select a reclaim unit 414 and / or a reclaim group 418 for storing data associated with the write command. In such cases, the controller 426 may select a reclaim unit 414 and / or a reclaim group 418 based at least in part on one or more operations of the storage device that may affect the performance of the write operation associated with the write command. For example, the controller 426 may select a reclaim unit 414 and / or a reclaim group 418 that is implemented using a physical storage medium (e.g., an NVM die) that is not currently busy with a program (e.g., write) operation, a read operation, an erase operation, a garbage collection operation, etc. As another example, the controller 426 may select a reclaim unit 414 and / or a reclaim group 418 that has a command queue that has no or relatively few pending commands. As another example, the controller may select reclaim unit 414 and / or reclaim group 418 based on opportunity status, such as an NVM die with a nearly program cycle completed, an associated write buffer with a nearly full word line, and / or an open block timer that is nearly expired.

[0097] Additionally or alternatively, the controller 426 can select a reclamation unit 414 and / or a reclamation group 418 based at least in part on one or more conditions of the storage device that may affect the performance of a write operation associated with the write command. For example, the controller 426 can avoid selecting a reclamation unit and / or a reclamation group where the NVM die may exhibit end-of-life (EOL) behavior, such as a relatively slow operating speed, a relatively high bit error accumulation rate, voltage excursions, etc. Additionally or alternatively, the controller 426 can select a reclamation unit and / or a reclamation group where the physical storage media may exhibit relatively young behavior.

[0098] In some embodiments, the operation of a memory device may refer to an ongoing operation, such as a currently executing read, write, and / or erase operation, a command queue currently containing a relatively large number of commands, a write buffer currently being filled with nearly a full word line, and the like. In some embodiments, the ongoing operation may be contrasted with a previous operation, such as a previous selection of a reclaim unit based on a cycling technique or a wear leveling technique. In some embodiments, the wear leveling technique may manage the behavior of the NVM to attempt to equalize (at least approximately equalize) the number of program and / or erase (P / E) cycles across one or more (e.g., each) erase blocks of the NVM. In some embodiments, one or more modifiers may alter the attempt to equalize P / E cycles, for example, based on one or more ongoing behaviors and / or conditions of the NVM (e.g., fewer P / E cycles may be performed on erase blocks that may have an indication of relatively high wear).

[0099] Figure 5 An embodiment of an initial isolation scheme for a flexible data placement scheme of a storage device according to an example embodiment of the present disclosure is shown. Figure 5 The illustrated embodiment may include three recycling unit handles 536 identified as RUH X, RUH Y, and RUH Z.

[0100] Recycling unit handler RUH X may currently reference the recycling unit 514 identified as RU A. Recycling unit RU A may be partially filled with data, as indicated by the single diagonal shading of the line extending from the upper right to the lower left. Recycling unit handler RUH X may have previously referenced recycling units 514′ identified as RU A′_0, RU A′_1, and RU A′_2. The previously referenced recycling units 514′ may have been filled with data (as indicated by the single diagonal shading of the line extending from the upper right to the lower left), for example, when they were referenced by RUH X in the same manner as Figure 3B and Figure 3CReclamation unit 314, shown as RU 4, is populated with data in a similar manner when referenced by reclaim unit handle 1 (RUH 1). Although not currently referenced by RUH X, previously referenced reclaim units RU A′_0, RU A′_1, and RU A′_2 may still remain associated with RUH X, for example, using a data structure such as a reclaim unit association table.

[0101] Recycling unit handler RUH Y may currently reference recycling unit 514 identified as RU B. Recycling unit RU B may be partially filled with data, as indicated by the diagonal shading. Recycling unit handler RUH Y may have previously referenced recycling units 514′ identified as RU B′_0, RU B′_1, and RU B′_2. For example, when the previously referenced recycling units 514′ were referenced by RU HY, they may have already been filled with data (as indicated by the diagonal shading).

[0102] Similarly, the recycling unit handle RUH Z may currently reference the recycling unit 514 identified as RU C. The recycling unit RU C may be partially filled with data, as indicated by the single diagonal shading represented by the line from the upper left to the lower right. The recycling unit handler RUH Z may have previously referenced the recycling units 514′ identified as RU C′_0, RU C′_1, and RU C′_2. For example, when the previously referenced recycling units 514′ were referenced by RUH Z, they may have been filled with data (as indicated by the single diagonal shading represented by the line from the upper left to the lower right).

[0103] In some embodiments, a controller within the storage device may perform one or more operations (e.g., maintenance operations) on the data stored in the previously referenced reclamation unit 514'. For example, some or all of the data stored in the previously referenced reclamation unit 514' may be released (e.g., by a host), resulting in unused storage capacity in the previously referenced reclamation unit 514'. This may be done in the following manner: Figure 5 , portions of the reclaim unit 514' containing previously referenced released (eg, invalid) data are shown shaded with relatively thin lines.

[0104] In some embodiments, the controller may perform one or more maintenance operations to enable unused storage capacity in the previously referenced reclamation units 514′ to be erased, reused, repurposed, etc. For example, the controller may perform a garbage collection operation in which valid data (e.g., data that has not been freed) in one or more previously referenced reclamation units 514′ may be copied to a different reclamation unit, thereby enabling the one or more previously referenced reclamation units 514′ to be erased and reused.

[0105] Figure 5 The embodiment shown in FIG5 may implement an initial isolation scheme in which data written to reclamation units currently or previously referenced by different reclamation unit handles 536 may be initially isolated from one another. (In some embodiments, data may be considered isolated if the reclamation units storing data include only data written to the reclamation units using the same reclamation unit handle.) Thus, reclamation units RU A, RU A′_0, RU A′_1, and RU A′_2 may include only data written when those reclamation units are referenced by RUH X. Similarly, reclamation units RU B, RU B′_0, RU B′_1, and RU B′_2 may include only data written when those reclamation units are referenced by RUH Y, and reclamation units RU C, RU C′_0, RU C′_1, and RU C′_2 may include only data written when those reclamation units are referenced by RUH Z.

[0106] However, as part of the controller's operation, data from reclaim units written using different reclaim unit handles may be combined in a single reclaim unit. Figure 5 542, where the controller can read valid data from previously referenced reclaim units RU A'_0, RU B'_0, and RU C'_0 and write them to reclaim unit 542 identified as RU α. Because the valid data copied from previously referenced reclaim units RU A'_0, RU B'_0, and RU C'_0 may be the last remaining valid data in one or more of these reclaim units, one or more of reclaim units RU A'_0, RU B'_0, and / or RU C'_0 may be erased, for example, as part of a garbage collection operation, to be reused to store other data. Reclaim units that have been erased (e.g., garbage collected) may be removed from the reclaim unit association table in which they may have been listed.

[0107] In some embodiments, Figure 5 The isolation scheme shown may be referred to as an initial isolation scheme because data written using different reclamation unit handles 536 may initially be isolated in different reclamation units, but may eventually be combined, for example, by subsequent operations such as garbage collection operations, media management operations (e.g., flushing procedures, read disturb), etc. In some embodiments, Figure 5 The illustrated isolation scheme may be referred to as a host isolation scheme because the host may determine (eg, using a reclamation unit handle) the placement of data in the isolated reclamation units.

[0108] Table 1

[0109]

[0110]

[0111] Despite Figure 5 5. One recycling group 518 is shown, but recycling units 514 can be arranged in any number of recycling groups. In some embodiments, data from recycling units in different recycling groups (e.g., valid data from previously referenced recycling units in different recycling groups) can be combined in the same recycling unit.

[0112] Figure 6 An embodiment of a persistent isolation scheme for a flexible data placement scheme of a storage device according to an example embodiment of the present disclosure is shown. Figure 6 The illustrated embodiment may include three recycling unit handles 636 identified as RUH X, RUH Y, and RUH Z, which may be used to process the recycling unit handles 636 in a manner similar to that described above with reference to FIG. Figure 5 The described manner writes data to the currently referenced reclamation unit 614 and / or the previously referenced reclamation unit 614'.

[0113] However, with the reference above Figure 5 Compared to the described embodiments, Figure 6 The isolation scheme shown can involve more isolation of data written using different recycling unit handles. For example, in Figure 6 In the illustrated embodiment, in controller operations that may move data from the previously referenced reclaim unit 614', data written using different reclaim unit handles may not be combined in a single reclaim unit. Figure 6 , where the controller can read valid data from (e.g., only from) previously referenced reclaim units RU A′_0, RU A′_1, and / or RU A′_2 that were written using the same reclaim unit handle RUH X and write it to reclaim unit identified as RUα 642. However, in some embodiments, reclaim unit RUα may not receive data from reclaim units written using other reclaim handles, such as RUH Y and / or RUH Z.

[0114] Similarly, the controller can read valid data from (e.g., only from) previously referenced reclaim units RU B′_0, RU B′_1, and / or RU B′_2 that were written using the same reclaim unit handle RUH Y and write it to the reclaim unit 642 identified as RUβ. The controller can also read valid data from (e.g., only from) previously referenced reclaim units RU C′_0, RUC′_1, and / or RU C′_2 that were written using the same reclaim unit handle RUH Z and write it to the reclaim unit 642 identified as RUγ. Thus, in some embodiments, data written to one or more reclaim units 642 can be read from (e.g., only from) one or more reclaim units written using the same reclaim unit handle.

[0115] If the valid data read from any previously referenced reclaim unit 614' is the last remaining valid data in the reclaim unit, the reclaim unit may be erased, such as as part of a garbage collection operation, to be reused to store other data.

[0116] In some embodiments, Figure 6 The isolation scheme shown may be referred to as a persistent isolation scheme because the isolation between data written using different reclaim unit handles may persist after write and / or release operations, including, for example, one or more garbage collection and / or other controller operations. Figure 6 The illustrated isolation scheme may be referred to as a complete or fully isolated scheme because the isolation between data written using different reclamation unit handles may persist throughout the lifecycle of the data in the storage device.

[0117] Despite Figure 6 6. One recycling group 618 is shown, but recycling units 614 can be arranged in any number of recycling groups. In some embodiments, data from recycling units in different recycling groups (e.g., valid data from previously referenced recycling units in different recycling groups) can be combined in the same recycling unit.

[0118] Figure 7A An embodiment of an update operation of a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is illustrated. Figure 7B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 7A An embodiment of an update operation is shown. Figure 7A and Figure 7B May be collectively and / or individually referred to as FIG. 7 .

[0119] 7 may include a host 702 and a storage device 704 communicating using a communication connection 705. The storage device 704 may include a controller 726 that may control the overall operation of the storage device 704 and a storage medium including reclamation units 714 arranged in one or more reclamation groups 718.

[0120] In FIG7 , one recycling group 718, referred to as recycling group 0, is shown, but the recycling units 714 can be arranged in any number of recycling groups 718. For illustrative purposes, in the embodiment shown in FIG7 , recycling group 0 can include five recycling units 714 identified as RU 0, RU 1, RU 2, RU 3, and RU 4, each of which can have a storage capacity of five pages of data, but any number and / or size of recycling units can be used. For example, in actual implementations, a recycling unit can include one, two, four, or more erase blocks, each of which can have a storage capacity measured in MB or GB and a page size measured in KB.

[0121] One or more reclaim unit handles 736 can reference corresponding reclaim units 714. For example, reclaim unit handle 0 (RUH 0) can reference reclaim unit RU 1 as shown by arrow 717a, while reclaim unit handle 1 (RUH 1) can reference reclaim unit RU 4 as shown by arrow 719a. Reclaim unit handles 736 can reference reclaim units 714, where the controller can use reclaim unit handles 736 to store the next page of data.

[0122] refer to Figure 7A , the storage device 704 may be shown in an initial state, wherein two pages of data may be stored in the reclaim unit 714 identified as RU 1, and four pages of data may be stored in the reclaim unit 714 identified as RU 4, as indicated by the diagonally shaded portions of RU 1 and RU 4. Thus, the storage device 704 may be shown in a state that may be similar to Figure 3A The initial state of the storage device 304 is stored in the memory.

[0123] However, instead of receiving a write command, the controller 726 may receive an update request 723 (e.g., using a command, indication, etc.). The update request 723 may request an update operation in which the controller 726 may modify one or more reclaim unit handles 736 to reference a new (e.g., empty) reclaim unit 714. The update request 723 may include an update list 725, which may specify one or more reclaim unit handles 736 that may be modified by the update operation. Figure 7AIn the example shown, the update list 725 may include reclaim unit handle 0 and reclaim unit handle 1. In some embodiments, the update request 723 may use different techniques to specify one or more reclaim handles 736 that may be updated. For example, instead of directly providing the reclaim unit handle 736, the update request 723 may include a placement handle that may specify the reclaim unit handle, for example, as described in reference to Figure 4 As shown in the described embodiments.

[0124] refer to Figure 7B , the controller 726 may perform the requested update operation by modifying reclaim unit handle 0 to reference reclaim unit RU 0, as indicated by arrow 717 b, and modifying reclaim unit handle 1 to reference reclaim unit RU 3, as indicated by arrow 719 b. Thus, data sent with subsequent write commands specifying reclaim unit handle 0 or reclaim unit handle 1 may be written to RU 0 or RU 3, respectively.

[0125] like Figure 7B As shown, recycling units RU 1 and RU 4 may be only partially full after the update operation. However, depending on the physical storage medium used to implement the recycling unit 714, leaving the recycling unit partially full may reduce the reliability, durability, performance, etc. of the recycling unit and / or the storage medium implemented therewith. Figure 7B In the illustrated embodiment, the controller 726 may fill some or all of the empty portions (as indicated by solid shading) of RU 1 and / or RU 4 with filler data (such as zeros, random data, and / or controller metadata). In some embodiments, the controller metadata may include data that may be used by the storage device or storage device controller, such as media activity tracking information, temporary data that may be used to protect against power failure events, swap space (e.g., scratchpad space for extended computations that may exceed the nominal available memory space), and the like.

[0126] However, the use of padding data may result in wasted or underutilized storage space. For example, Figure 7B The portions of RU 1 and / or RU 4 shown as filled with data may not be used to store data until they are reclaimed by, for example, a garbage collection operation.

[0127] Figure 8A An embodiment of a flexible data placement scheme of a reclaim unit in a storage device in a first state transferring data according to an example embodiment of the present disclosure is shown. Figure 8B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 8A The embodiment shown. Figure 8A and Figure 8B May be collectively and / or individually referred to as FIG8.

[0128] The embodiment shown in FIG. 8 may include at least three reclaim units 814 identified as RU 0 , RU 1 , and / or RU 2 , and a reclaim unit handle (RUH) 836 .

[0129] Figure 8A A first state is shown where RU 0 may be a previously referenced reclaim unit, RU 1 may currently be referenced by reclaim unit handle 836 as indicated by arrow 817a, and RU 2 may be empty.

[0130] RU 0 may have been previously referenced by reclaim unit handle 836 or any other reclaim unit handle. RU 0 may have been filled when previously referenced by reclaim unit handle 836 or any other reclaim unit handle. RU 0 may include at least a first portion 844 storing valid user data, as indicated by diagonal shading using thicker lines. RU 0 may include one or more other portions storing freed user data 848, as indicated by diagonal shading using relatively thinner lines.

[0131] RU 1 may include at least a first portion 850 storing valid user data, as shown by diagonal shading using bold lines. RU 1 may include one or more other portions 852 that may be empty (e.g., erased and not yet programmed with user data).

[0132] Figure 8B 836. The second state is shown after an update operation, which may be performed, for example, by a controller in which recycling unit 814 and recycling unit handle 836 may be located. The update operation may modify recycling unit handle 836 to reference empty recycling unit RU 2, as indicated by arrow 817b. Although no longer referenced by recycling unit handle 836, RU 1 may remain associated with recycling unit handle 836, as indicated by dashed arrow 827. Thus, RU 1 may be referred to as a previously referenced or dereferenced recycling unit.

[0133] Based on the update operation, at least a portion of the valid user data 844 in RU 0 can be read from RU 0 and written to the empty portion 852 of RU 1 (e.g., copied or moved from RU 0 to RU 1) as shown by arrow 829. Depending on the implementation details, this data transfer between recycling units may have one or more effects. For example, storing the valid user data in the previously empty portion of RU 1 may utilize storage space in RU 1 that would otherwise have been wasted and / or only marginally useful if filled with padding data. As another example, moving valid user data from RU 0 to RU 1 may enable RU 0 to be reclaimed (e.g., erased, reused, repurposed, returned to a pool of available (e.g., empty, erased, etc.) memory for later reuse, and / or otherwise reclaimed. Depending on implementation details, this may reduce write amplification. For example, as part of a garbage collection operation for RU 0, one or more write cycles that might have been used to move valid user data 844 in RU 0 to a different location may instead be used to move valid user data 844 to RU 1. In some embodiments, the update operation shown in FIG. 8 may be characterized as a mixed and / or partial garbage collection operation.

[0134] Further possible implementation details of the embodiment shown in Figure 8 may depend on the isolation scheme applied to RU 1. For example, if RU 1 is implemented with a persistent isolation scheme, RU 0 may have only been previously referenced by (e.g., associated with) a recycling unit handle 836, as shown in Figure 8. However, if RU 1 is implemented with an initial isolation scheme, RU 0 may have been previously referenced by (e.g., associated with) any recycling unit handle, including recycling unit handle 836 as shown in Figure 10. Furthermore, in some embodiments, data transfer between recycling units may be limited to recycling units in the same recycling group.

[0135] Figure 9A An embodiment of a flexible data placement scheme for transferring data to a reclamation unit using persistent isolation in a storage device in a first state according to an example embodiment of the present disclosure is shown. Figure 9B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 9A The embodiment shown. Figure 9A and Figure 9B May be collectively and / or individually referred to as FIG. 9 .

[0136] The embodiment shown in FIG. 9 may implement a persistent isolation scheme and may include at least three reclaim units 914 identified as RU A′_0, RUA, and / or RU 2, and a reclaim unit handle 936 identified as RUH X.

[0137] Figure 9A A first state is shown where RU A'_0 may be a previously referenced recycling unit previously referenced by (eg, currently associated with) RUH X, as indicated by arrow 931. RU A may currently be referenced by RUH X, as indicated by arrow 917a, and RU 2 may be empty.

[0138] RU A′_0 may have been filled when previously referenced by RUH X. Reclaim unit RU A′_0 may include at least a first portion 944 storing valid user data, as indicated by diagonal shading using thicker lines. RU A′_0 may include one or more other portions storing freed user data 948, as indicated by diagonal shading using relatively thinner lines.

[0139] RU A may include at least a first portion 950 storing valid user data, as shown using diagonal shading with bold lines. RU A may include one or more other portions 952 that may be empty (eg, erased and not yet programmed with user data).

[0140] Figure 9B 917b, which may be previously in the state of the empty reclaim unit RU A. Figure 9A Although no longer referenced by RUH X, the recycling unit RU A′_1 (which was previously Figure 9A RU A) may remain associated with the reclaim unit handle 936, as indicated by dashed arrow 927. Thus, RU A'_1 may be referred to as a previously referenced or dereferenced reclaim unit.

[0141] Based on the update operation, at least a portion of the valid user data 944 in RU A'_0 can be read from RU A'_0 and written to the empty portion 952 of RU A'_1 (e.g., copied or moved from RU A'_0) as shown by arrow 929. Therefore, based on the persistent isolation scheme, the valid user data written to RU A'_1 can only be read from the reclaim units referenced or previously referenced by RUH X. In some embodiments, the data written to RU A'_0 can be limited to data read from the reclaim units in the same reclaim group as RU A'_0.

[0142] Figure 10A An embodiment of a flexible data placement scheme for transferring data to a reclamation unit using initial isolation in a storage device in a first state according to an example embodiment of the present disclosure is shown. Figure 10BThe second state according to an exemplary embodiment of the present disclosure is shown. Figure 10A The embodiment shown. Figure 10A and Figure 10B May be collectively and / or individually referred to as FIG. 10 .

[0143] The embodiment shown in FIG. 10 may implement an initial isolation scheme and may include at least three reclaim units 1014 identified as RU B′_0, RU A, and / or RU2, and reclaim unit handles 1036 identified as RUH X and / or RUH Y.

[0144] Figure 10A A first state is shown where RU B'_0 may be a previously referenced reclaimed unit previously referenced by (eg, currently associated with) RUH Y, as indicated by arrow 1031. RU A may currently be referenced by RUH X, as indicated by arrow 1017a, and RU 2 may be empty.

[0145] RU B'_0 may have been filled when previously referenced by RUH Y. Reclaim unit RU B'_0 may include at least a first portion 1044 storing valid user data, as indicated by diagonal shading using thicker lines. RU B'_0 may include one or more other portions storing freed user data 1048, as indicated by diagonal shading using relatively thinner lines.

[0146] RU A may include at least a first portion 1050 storing valid user data, as shown by diagonal shading using bold lines. RU A may include one or more other portions 1052 that may be empty (eg, erased and not yet programmed with user data).

[0147] Figure 10B 1014 and 1036 may be located in the controller. The update operation may modify RUH X to reference the empty reclaim unit RU A (which was previously in the Figure 10A Although no longer referenced by RUH X, the recycled unit RU A′_0 (which was previously Figure 10A RU A) may remain associated with RUH X, as indicated by dashed arrow 1027. Thus, RU A'_0 may be referred to as a previously referenced or dereferenced reclaimed unit.

[0148] Based on the update operation, at least a portion of the valid user data 1044 in RU B'_0 can be read from RU B'_0 and written to the empty portion 1052 of RU A'_0 (e.g., copied or moved from RU B'_0) as shown by arrow 1029. Thus, based on the initial isolation scheme, the valid user data written to RU A'_0 can be read from any reclaim unit referenced or previously referenced by any reclaim unit handle (e.g., RUH Y). In some embodiments with initial isolation, even though the data written to RU A'_0 may not be limited to data read from reclaim units referenced and / or associated with RUH X, it can still be limited to data read from reclaim units in the same reclaim group as RU A'_0.

[0149] Figure 11A A first embodiment of a data transmission operation for a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is shown. Figure 11B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 11A The embodiment of the data transmission operation shown. For example, Figure 11A and Figure 11B The illustrated embodiment may be used with any of the update operations disclosed herein, including the operations described with respect to FIG. 8 , FIG. 9 , and / or FIG. 10 .

[0150] refer to Figure 11A , a recycling unit 1114-1, identified as RU D, may include a first portion in which user data 1150 may be stored, as indicated by the diagonal shading using bold lines. RU D may also include one or more other portions 1152, which may be empty. Recycling unit RU D may be referenced by a recycling unit handle, which in this example may be referred to as RUH 1, as indicated by the solid arrow 1160.

[0151] Another recycling unit 1114-2, identified as RU D′_23, may include one or more portions in which valid user data 1144-1, 1144-2, ... (which may be collectively and / or individually referred to as 1144) may be stored, as indicated by the diagonal shading using thicker lines. RU D′_23 may include one or more other portions in which released user data 1148-1, 1148-2, ... (which may be collectively and / or individually referred to as 1148) may be stored, as indicated by the diagonal shading using relatively thinner lines. RU D′_23 may be a previously referenced recycling unit that may currently be associated with (e.g., previously referenced by) recycling unit handle RUH 1, as indicated by dashed arrow 1162.

[0152] Another recycling unit 1114-3, identified as RU D'_104, may include one or more portions in which valid user data 1145-1, 1145-2, ... (which may be collectively and / or individually referred to as 1145) may be stored, as indicated by the diagonal shading using thicker lines. RU D'_104 may include one or more other portions in which released user data 1149-1, 1149-2, ... (which may be collectively and / or individually referred to as 1149) may be stored, as indicated by the diagonal shading using relatively thinner lines. D'_104 may be a previously referenced recycling unit that may currently be associated with (e.g., previously referenced by) recycling unit handle RUH 1, as indicated by the dashed arrow 1164.

[0153] refer to Figure 11B Based on an update operation that may modify the recycling unit handle RUH 1, which may reference or be associated with RU D, some or all of the valid user data 1144 and / or 1145 may be transferred to RU D. Some or all of the data may be transferred before, after, and / or as part of the update operation. Some or all of the data may be transferred before, after, and / or while the recycling unit handle RUH 1 is modified to reference a different recycling unit (e.g., a recycling unit other than RU D).

[0154] exist Figure 11B In the illustrated embodiment, valid user data 1144 and / or 1145 may fill one or more empty portions 1152 of the RU D. Depending on implementation details, the RU D may be closed (e.g., one or more erase blocks within the RU D may be closed). Additionally or alternatively, depending on implementation details, one or both of the reclaim units RU D′_23 and / or RU D′_104 may then be reclaimed (e.g., erased, reused, repurposed, etc.). Depending on implementation details, this may reduce write amplification.

[0155] Depending on the implementation details, Figure 11A and Figure 11B The data transfer operations shown in can be characterized as achieving persistent isolation because, for example, valid user data 1144 and / or 1145 transferred to RU D can only be read from the (e.g., previously referenced) reclaim unit associated with the reclaim unit handle RUH 1 (e.g., valid user data 1144 and / or 1145 can only be read from the reclaim units (e.g., RU D′_23 and / or RU D′_104) referenced by RUH 1 when they are written together with the valid user data transferred to RU D).

[0156] 11 , valid user data 1144 and / or 1145 may fill one or more empty portions 1152 of RU D, and thus reclaim unit 114-1RU D may be full. However, in other embodiments, valid user data 1144 and / or 1145 may be more or less than the amount required to fill one or more empty portions 1152 of RU D. If valid user data 1144 and / or 1145 is greater than the capacity of one or more empty portions 1152 of RU D, only the amount of valid user data 1144 and / or 1145 required to fill one or more empty portions 1152 of RU D may be transferred, and any remaining portion of valid user data 1144 and / or 1145 may remain in RU D′_23 and / or RU D′_104, or be transferred to another reclaim unit (e.g., as part of a garbage collection operation).

[0157] If the amount of valid user data 1144 and / or 1145 is less than the capacity of one or more empty portions 1152 of RU D, some or all of the remaining empty portions 1152 of RU D can be filled with valid user data transmitted from one or more other recycling units (e.g., a fourth recycling unit that can be referred to as RU D′_45). Alternatively or additionally, some or all of the remaining empty portions 1152 of RU D can be filled with padding data such as zeros, random data, and / or metadata. Furthermore, in some embodiments, data transmission between recycling units can be limited to recycling units in the same recycling group.

[0158] Figure 12A A second embodiment of a data transmission operation in a first state for a flexible data placement scheme according to an example embodiment of the present disclosure is shown. Figure 12B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 12A The embodiment of the data transmission operation shown. For example, Figure 12A and Figure 12B The illustrated embodiment may be used with any of the update operations disclosed herein, including those described with respect to FIG. 8 , FIG. 9 , and / or FIG. 10 .

[0159] refer to Figure 12A , a reclaim unit 1214-1, identified as RU D, may include a first portion, as indicated by the diagonal shading using bold lines, in which user data 1250 may be stored. RU D may also include one or more other portions 1252, which may be empty. Reclaim unit RU D may be referenced by a first reclaim unit handle, which in this example may be referred to as RUH 1, as indicated by a solid arrow 1260.

[0160] Another recycling unit 1214-2, identified as RU E′_35, may include one or more portions in which valid user data 1244-1, 1244-2, ... (collectively and / or individually 1244) may be stored, as indicated by the diagonal shading using thicker lines. RU 35 may include one or more other portions in which released user data 1248-1, 1248-2, ... (collectively and / or individually 1248) may be stored, as indicated by the diagonal shading using relatively thinner lines. RU E′_35 may be the previously referenced recycling unit, which may currently be associated with (e.g., previously referenced by) a second recycling unit handle, which may be referred to as RUH 2, as indicated by the dashed arrow 1262.

[0161] Another recycling unit 1214-3, identified as RU F′_86, may include one or more portions in which valid user data 1245-1, 1245-2, ... (which may be collectively and / or individually referred to as 1245) may be stored, as indicated by the diagonal shading using thicker lines. RU F′_86 may include one or more other portions in which freed user data 1249-1, 1249-2, ... (which may be collectively and / or individually referred to as 1249) may be stored, as indicated by the diagonal shading using relatively thinner lines. RUF′_86 may be the previously referenced recycling unit that may currently be associated with (e.g., previously referenced by) a third recycling unit handle, which may be referred to as RUH 3, as indicated by the dashed arrow 1264.

[0162] refer to Figure 12B Based on an update operation that may modify the recycling unit handle RUH 1, which may reference or be associated with RU D, some or all of the valid user data 1244 and / or 1245 may be transferred to RU D. Some or all of the data may be transferred before, after, and / or as part of the update operation. Some or all of the data may be transferred before, after, and / or while the recycling unit handle RUH 1 is modified to reference a different recycling unit (e.g., a recycling unit other than RU D).

[0163] exist Figure 12B In the illustrated embodiment, valid user data 1244 and / or 1245 may fill one or more empty portions 1252 of the RU D. Depending on implementation details, the RU D may be closed (e.g., one or more erase blocks within the RU D may be closed). Additionally or alternatively, depending on implementation details, one or both of the reclaim units RU E′_35 and / or RU F′_86 may then be reclaimed (e.g., erased, reused, repurposed, etc.). Depending on implementation details, this may reduce write amplification.

[0164] Depending on the implementation details, Figure 12A and Figure 12B The data transfer operations shown in can be characterized as achieving initial isolation because, for example, valid user data 1244 and / or 1245 transferred to RU D can be read from a reclaim unit currently referenced by and / or associated with (e.g., previously referenced) one or more reclaim unit handles other than the reclaim unit handle RUH 1 (e.g., valid user data 1244 and / or 1245 can be read from reclaim units (e.g., RU E′_35 and / or RU F′_86) referenced by reclaim unit handles other than RUH 1 when they are written together with the valid user data transferred to RU D).

[0165] 12 , valid user data 1244 and / or 1245 may fill one or more empty portions 1252 of RU D, and thus, reclaim unit 124-1RU D may be full. However, in other embodiments, valid user data 1244 and / or 1245 may be more or less than the amount required to fill one or more empty portions 1252 of RU D. If the valid user data 1244 and / or 1245 is greater than the capacity of the one or more empty portions 1252 of RU D, only the amount of valid user data 1244 and / or 1245 required to fill the one or more empty portions 1252 of RU D may be transferred, and any remaining portion of the valid user data 1244 and / or 1245 may remain in RU E′_35 and / or RU F′_86, or be transferred to another reclaim unit (e.g., as part of a garbage collection operation).

[0166] If the amount of valid user data 1244 and / or 1245 is less than the capacity of one or more empty portions 1252 of the RUD, some or all of the remaining empty portions 1252 of the RUD may be filled with valid user data transmitted from one or more other recycling units (e.g., a fourth recycling unit that may be referred to as RUG′_55). Alternatively or additionally, some or all of the remaining empty portions 1252 of the RUD may be filled with filler data such as zeros, random data, and / or metadata. Furthermore, in some embodiments, data transmission between recycling units may be limited to recycling units in the same recycling group.

[0167] In the embodiments described with respect to Figures 8, 9, 10, and / or 11, data may be transferred to a recycling unit that may be the subject of an update operation. However, in some other embodiments, data may be transferred from a recycling unit that may be the subject of an update operation.

[0168] Figure 13AAn embodiment of a flexible data placement scheme in a first state according to an example embodiment of the present disclosure is shown, wherein data is transferred from a reclaim unit in a storage device. Figure 13B The second state according to an exemplary embodiment of the present disclosure is shown. Figure 13A The embodiment shown. Figure 13A and Figure 13B May be collectively and / or individually referred to as FIG. 13 .

[0169] The embodiment shown in FIG. 13 may include at least three reclaim units 1314 identified as RU 0 , RU 1 , and / or RU 2 , and a reclaim unit handle (RUH) 1336 .

[0170] Figure 13A A first state is shown in which RU 0 may have writable space available for transferring data, RU 1 may currently be referenced by a reclaim unit handle 1336 as indicated by arrow 1317a, and RU 2 may be empty. Examples of RU 0 that may have writable space may include an empty reclaim unit, a reclaim unit that is currently referenced by a reclaim unit handle but has empty space, a previously referenced reclaim unit that still has empty space, etc.

[0171] RU 1 may include at least a first portion 1350 storing valid user data, as shown by diagonal shading using bold lines. RU 1 may include one or more other portions 1352 that may be empty (eg, have been erased and not yet programmed with user data).

[0172] Figure 13B 13. The second state is shown after an update operation, which may be performed, for example, by a controller in which reclaim unit 1314 and reclaim unit handle 1336 may be located. The update operation may modify reclaim unit handle 1336 to reference an empty reclaim unit RU 2, as indicated by arrow 1317b. Although no longer referenced by reclaim unit handle 1336, RU 1 may remain associated with reclaim unit handle 1336, as indicated by dashed arrow 1327.

[0173] Based on the update operation, at least a portion of valid user data 1350 in RU 1 may be read from RU 1 and written to the empty portion of RU 0 as indicated by arrow 1333 (eg, copied or moved from RU 1 to RU 0).

[0174] Depending on the implementation details, this data transfer between recycling units may have one or more effects. For example, moving valid user data from RU 1 to RU 0 may enable RU 1 to be recycled (e.g., erased, reused, repurposed, returned to a pool of available (e.g., empty, erased, etc.) memory for later reuse, etc.). Depending on the implementation details, this may reduce write amplification. Furthermore, depending on the implementation details of the type of storage media used for RU 1 (e.g., depending on NAND characterization data for a storage media implemented with NAND flash memory), erasing RU 1 as one or more open erase blocks may be beneficial (e.g., as compared to erasing one or more filled and / or closed erase blocks). Additionally or alternatively, if RU 1 is updated based on an update request that includes multiple reclamation unit handles, and if more than one reclamation unit handle is implemented to have initial isolation, data from multiple reclamation units implemented to have initial isolation (e.g., such as RU 1) may be copied to the same reclamation unit (e.g., RU 0), for example, simultaneously and / or based on the same update operation and / or update operation request.

[0175] Alternatively or additionally, a flexible data placement scheme according to an example embodiment of the present disclosure may store data in one or more over-provisioned spaces associated with one or more recycling units. For example, if a recycling unit handle references a recycling unit with associated over-provisioned space, and when an update operation is requested, the referenced recycling unit is only partially full, rather than modifying the recycling unit handle to reference a different (e.g., empty) recycling unit, the recycling unit handle may remain unmodified and at least a portion of the over-provisioned space may be used to store user data written to the recycling unit in response to one or more write commands that may specify the recycling unit handle. In some embodiments, this may be characterized as modifying the recycling unit based on the update request instead of, or in addition to, modifying the recycling unit handle.

[0176] Figure 14 An example embodiment of a flexible data placement scheme utilizing data storage in over-provisioned space according to an example embodiment of the present disclosure is illustrated. Figure 14 The illustrated embodiment may include a reclaim unit handle (RUH) 1436, which may reference a reclaim unit (RU 0) 1414. The reclaim unit 1414 may include an amount of data storage space 1454 known to the host (e.g., a reclaim unit size that may be configured by the host, storage device, etc.). In some embodiments, this may be referred to as the original or initial storage space of the reclaim unit 1414.

[0177] Over-provisioning (OP) space 1456 can be associated with the reclamation unit 1414. Some storage devices may include over-provisioning space for purposes such as storing controller metadata, accommodating storage media behavior (e.g., word line failures), operating auxiliary data protection schemes (e.g., redundant array of independent drives (RAID)), etc. For example, in some storage devices, an erase block may contain one or more stored spare word lines that the host may not be aware of. Alternatively or additionally, the over-provisioning space associated with the erase blocks and / or reclamation unit may be in a separate physical storage device (e.g., a separate erase block that may be mapped to the erase block of the reclamation unit and arranged to be erased, reused, re-planned, returned to a pool of available (e.g., empty, erased, etc.) memory for later reuse in conjunction with the reclamation unit, etc.). In some embodiments, some or all of the over-provisioning space 1456 may be implemented with one or more types of storage media that may be different from the original data storage space 1454.

[0178] The spare word line can be used, for example, to replace a failed word line in a manner that is invisible to the host. Thus, in some embodiments, if the reclamation unit 1414 is implemented, for example, with two erase blocks, and each erase block includes a spare word line, the reclamation unit 1414 can include two stored spare word lines that the host may not be aware of.

[0179] like Figure 14 As shown, raw data storage space 1454 may include one or more first portions 1450 and one or more empty portions 1452, where user data may be stored, as indicated by the diagonal shading. Thus, raw data storage space 1454 may only be partially full. If an update operation is requested for reclaim unit handle 1436 (e.g., via an update request sent from a host to a controller of a storage device in which one or both of reclaim unit handle 1436 and reclaim unit 1414 may be located), the controller may modify the storage space used to store user data in reclaim unit 1414, rather than modifying reclaim unit handle 1436 to reference a different reclaim unit. For example, user data in one or more first portions 1450 of reclaim unit 1414 may remain in place, and a modified data storage space 1458, which may include at least a portion of overprovisioned space 1456, may be used to store user data based on one or more write commands. Depending on implementation details, modified data storage space 1458 may be at least the same size as original data storage space 1454 so that the host can store the same amount of data it would expect to store in a normal reclamation unit referenced by reclamation unit handle 1436 .

[0180] Although not limited to any particular implementation details, a flexible data placement scheme for data storage in over-provisioned space according to example embodiments of the present disclosure (e.g., Figure 14 ) may be particularly beneficial, for example, if the amount of user data stored in one or more first portions 1450 of the reclaim unit 1414 is less than or equal to the amount of over-provisioning space 1456 when an update operation is performed.

[0181] Additionally or alternatively, storing user data in over-provisioned space associated with a reclamation unit may be beneficial, for example, if an update request is received early during the filling of the reclamation unit 1414 (e.g., when the amount of user data stored in the one or more first portions 1450 is relatively small, and / or the amount of time remaining on the open block timer associated with the reclamation unit is relatively large (e.g., if the reclamation unit 1414 was recently opened). In some embodiments, when using some or all of the over-provisioned space 1456 as part of the modified data storage space 1458, the reclamation unit 1414 can be expected to remain open for approximately the estimated active reclamation unit time remaining.

[0182] Additionally or alternatively, it may be beneficial to store user data in overprovisioning space associated with the reclamation unit, for example, if the storage medium implementing the reclamation unit 1414 is relatively new and / or has undergone relatively few program and / or erase (P / E) cycles (e.g., because the likelihood of using overprovisioning space 1456 to replace failed storage media may be relatively low).

[0183] Additionally or alternatively, the storage of user data in the overprovisioned space 1454 associated with the reclaim unit 1414 may be expanded to include one or more additional overprovisioned spaces in one or more additional reclaim units. For example, if, when performing an update operation, the amount of user data stored in the one or more first portions 1450 of the reclaim unit 1414 is greater than the amount of overprovisioned space 1456, the modified data storage space 1458 may be expanded to include one or more additional overprovisioned spaces in the one or more additional reclaim units. This may be implemented, for example, by using a data buffer to store (e.g., temporarily) the amount of data that exceeds the amount of overprovisioned space 1456. For example, if the overprovision space 1454 associated with the reclaim unit 1414 includes two word lines of user data and the one or more first portions 1450 of the reclaim unit 1414 include three word lines of user data, the two word lines of user data can be stored in the first overprovision space 1454 associated with the reclaim unit 1414 and the third word line of user data can be stored, for example, until it can be stored in the overprovision space associated with the next one or more reclaim units opened and / or referenced by the reclaim unit handle 1436.

[0184] In some embodiments, when a reclaim unit, such as reclaim unit 1414, is shut down (e.g., when it is filled with user data), overprovisioning space 1456 associated with reclaim unit 1414 may be filled with padding data (e.g., to properly shut down reclaim unit 1414 and / or one or more erase blocks that may implement it). In some embodiments consistent with the present disclosure, rather than filling overprovisioning space 1456 associated with reclaim unit 1414 with padding data, some or all of overprovisioning space 1456 may be filled with valid user data, such as from the previously referenced reclaim units.

[0185] In some embodiments, storing user data in over-provisioned space associated with reclaim units, open times (e.g., estimated open times), etc. may be characterized as consuming a margin of over-provisioned space, reclaim units, open times, etc.

[0186] Any storage device, storage medium, etc. disclosed herein may be implemented using any type of non-volatile storage medium based on solid-state media, magnetic media, optical media, etc. For example, in some embodiments, the computational storage device may be implemented as an SSD based on non-AND (NAND) flash memory, a persistent memory such as a crossbar non-volatile memory, a memory with a bulk resistance change, a phase change memory (PCM), etc., or any combination thereof.

[0187] Any storage device disclosed herein may be implemented in any form factor such as 3.5-inch, 2.5-inch, 1.8-inch, M.2, Enterprise and Data Center SSD Form Factor (EDSFF), NF1, etc. using any connector configuration such as Serial ATA (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), U.2, etc.

[0188] Any storage device disclosed herein may be implemented and / or used in combination, in whole or in part, with a server chassis, a server rack, a data room, a data center, an edge data center, a mobile edge data center, and / or any combination thereof.

[0189] Any host disclosed herein may be implemented using any component or combination of components such as a compute server, a storage server, a network server, a cloud server, etc., a node such as a storage node, a computer such as a workstation, a personal computer, a tablet computer, a smartphone, etc., or multiple and / or combinations thereof.

[0190] Any communication connection and / or communication interface disclosed herein can be implemented using any type of interface and / or protocol with one or more interconnects, one or more networks, a network of multiple networks (e.g., the Internet), etc., or a combination thereof. Examples may include Peripheral Component Interconnect Express (PCIe), NVMe, NVMe-over-Fabric (NVMe-oF), Ethernet, Transmission Control Protocol / Internet Protocol (TCP / IP), Direct Attached Memory Access (DMA) Remote DMA (RDMA), RDMA over Converged Ethernet (ROCE), Fibre Channel, InfiniBand, Serial ATA (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), iWARP, Compute Express Link (CXL) and / or a coherence protocol such as CXL.mem, CXL.cache, CXL.IO, etc., Gen-Z, Open Coherent Accelerator Processor Interface (OpenCAPI), Cache Coherent Interconnect for Accelerators (CCIX), etc., Advanced Extensible Interface (AXI), any generation of wireless networks including 2G, 3G, 4G, 5G, 6G, etc., any generation of Wi-Fi, Bluetooth, Near Field Communication (NFC), etc., or any combination thereof.

[0191] Any functionality described herein, including functionality of any host functionality, storage device functionality, and the like (e.g., functionality of any storage device controller, logic lamp), can be implemented in hardware, software, firmware, or any combination thereof, including, for example, hardware and / or software combinational logic, sequential logic, timers, counters, registers, state machines, volatile memory such as DRAM and / or SRAM, non-volatile memory including flash memory, persistent memory such as cross-grid non-volatile memory, memory with body resistance change, PCM, etc., and / or any combination thereof, complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), application specific circuits (ASICs), central processing units (CPUs) including CISC processors such as x86 processors and / or RISC processors such as ARM processors, graphics processing units (GPUs), neural processing units (NPUs), tensor processing units (TPUs), etc., executing instructions stored in any type of memory. In some embodiments, one or more components may be implemented as a system on a chip (SOC).

[0192] In embodiments implemented at least in part with a storage device having a flash translation layer (FTL), any functionality described herein (eg, any storage device controller, logic, etc.) may be implemented at least in part with the FTL.

[0193] In some embodiments, a recycling unit may include physical non-volatile storage that can be recycled (e.g., erased, reused, repurposed, etc.) as a unit. Depending on implementation details, a recycling unit may be recycled without interfering with one or more other recycling units. In some embodiments, a recycling unit may be implemented solely as a physical structure (e.g., may not be associated with a logical address or logical block address (LBA)).

[0194] In some embodiments, a namespace may include, for example, capacity allocated in one or more reclamation units. A reclamation group may include one or more reclamation units, and one or more placement handles may reference one or more reclamation units (e.g., which may be the target of one or more I / O commands). In some embodiments, an I / O command executed on one reclamation group does not interfere with the performance, reliability, etc., of a command executed on another reclamation group.

[0195] In some embodiments, a placement identifier may specify a reclaim group that is paired with a placement handle, a reclaim unit handle, etc. A placement identifier may reference, for example, a reclaim unit that may be used to write to a random LBA (e.g., to write user data to non-volatile storage assigned to a reclaim unit). The write capacity of a reclaim unit referenced by a placement identifier may be incremented by a combination of one or more write commands that specify the placement identifier, placement handle, reclaim unit handle, etc. (e.g., incremented on each write command), which in turn may be modified to reference another reclaim unit once the capacity of the reclaim unit has been partially or fully written.

[0196] In some embodiments, the host can track user data written to one or more reclamation units (e.g., user data of one or more LBAs). Depending on the implementation details, this can enable the host to release some or all user data associated with a particular reclamation unit (e.g., all LBAs) together (e.g., simultaneously). Depending on the implementation details, this can reduce or minimize garbage collection by the controller, thereby reducing write amplification. In some embodiments, the host can be responsible for managing layout identifiers, layout handles, reclamation unit handles, and / or other related device resources.

[0197] In some embodiments, a recycling unit handle may include a reference to a recycling unit (e.g., in each recycling group) in which the user data of a write command may be placed. In some embodiments, a recycling unit referenced by a recycling unit handle may only be allowed to be referenced by at most one recycling unit handle. However, in some embodiments, when a recycling unit is recycled back into use from being erased, a particular recycling unit may be referenced by the same or different recycling unit handles. When a recycling unit is written to maximum capacity, the controller may update the associated recycling unit handle to reference a different recycling unit that can be used to write user data (e.g., a non-volatile storage medium that may have been erased before writing) and to which little or no write user data has been written (e.g., an empty recycling unit).

[0198] Figure 15 An example embodiment of a host device according to an example embodiment of the present disclosure is shown, which host device can be used to implement any host functionality disclosed herein. Figure 15 The illustrated host device 1500 may include a processor 1502 , which may include a memory controller 1504 , a system memory 1506 , host control logic 1508 , and / or a communication interface 1510 . Figure 15 Any or all of the components shown may communicate via one or more system buses 1512. In some embodiments, Figure 15One or more of the components shown may be implemented using other components. For example, in some embodiments, host control logic 1508 may be implemented by processor 1502 executing instructions stored in system memory 1506 or other memory.

[0199] Figure 16 An example embodiment of a storage device according to an example embodiment of the present disclosure is shown, which can be used to implement any storage device functionality disclosed herein. Storage device 1600 may include a device controller 1602, a media conversion layer 1604 (eg, FTL), and / or a storage medium 1606. Figure 16 The components shown may communicate via one or more device buses 1612. In some embodiments where flash memory may be used for some or all of storage media 1606, media translation layer 1604 may be implemented partially or entirely as a flash translation layer (FTL).

[0200] Figure 17 7 and 8. The method of FIG. 7 is shown in FIG. 8. The method of FIG. 8 is shown in FIG. 8. The method of FIG. 8 is shown in FIG. 8. The method of FIG. 8 is shown in FIG. 8. Figure 16 Controller 1602 is shown.

[0201] At operation 1704, the method may perform an update operation associated with a reclaim unit handle that references at least one reclaim unit of at least one storage medium. Figure 8B and / or Figure 13B , the recycle unit handle RUH may initially reference recycle unit RU 1, as indicated by arrows 827 and / or 1327, respectively. An update operation may include updating the RUH to reference recycle unit RU 2, as indicated by arrows 827 and / or 1327, respectively. Figure 8B and / or Figure 13B As further example, refer to Figure 9B and / or Figure 10B , the reclaim unit handle RUH X may initially reference reclaim units RU A′_1 and / or RU A′_0, as indicated by arrows 927 and / or 1027, respectively. The update operation may include updating RUH X to reference reclaim units RU A, as indicated by arrows 927 and / or 1027, respectively. Figure 9B and / or Figure 10B As shown by arrows 917b and / or 1017b.

[0202] At operation 1706, the method may read data from a first recycling unit of at least one storage medium based on the update operation, and at operation 1708, the method may write data to a second recycling unit of at least one storage medium based on the update operation. Figure 8A、 Figure 9B and / or Figure 10B , data can be read from the first recycling unit (respectively RU 0, RU A′_0 and / or RU B′_0) and written to the second recycling unit (respectively RU 1, RU A′_1 and / or RU A′_0), as shown by arrows 829, 929 and / or 1029, respectively. As another example, referring to Figure 13B , data may be read from the first recycling unit RU 1 and written to the second recycling unit RU 0 as indicated by arrow 1333 . The method may end at operation 1710 .

[0203] Figure 17 The illustrated embodiments and all other embodiments described herein are example operations and / or components. In some embodiments, some operations and / or components may be omitted, and / or other operations and / or components may be included. In addition, in some embodiments, the temporal and / or spatial order of operations and / or components may vary. Although some components and / or operations may be shown as separate components, in some embodiments, some components and / or operations shown separately may be integrated into a single component and / or operation, and / or some components and / or operations shown as a single component and / or operation may be implemented with multiple components and / or operations.

[0204] Some of the embodiments disclosed above have been described in the context of various implementation details, but the principles of the present disclosure are not limited to these or any other specific details. For example, some functionality has been described as being implemented by certain components, but in other embodiments, the functionality may be distributed across different systems and components in different locations and with various user interfaces. Some embodiments are described as having specific processes, operations, etc., but these terms also encompass embodiments in which a specific process, operation, etc. may be implemented using multiple processes, operations, etc., or in which multiple processes, operations, etc. may be integrated into a single process, step, etc. A reference to a component or element may refer to only a portion of that component or element. For example, a reference to a block may refer to the entire block or one or more sub-blocks. A reference to a component or element may refer to one or more components or elements, and a reference to multiple components or elements may refer to a single component or element. For example, a reference to a resource may refer to one or more resources, and a reference to a resource may refer to a single resource. Terms such as "first" and "second" may be used solely to distinguish the elements they modify and may not indicate any spatial or temporal order unless otherwise apparent from the context. In some embodiments, a reference to an element may refer to at least a portion of the element, for example, "based on" may mean "at least partially based on," etc. A reference to a first element does not imply the presence of a second element. The principles disclosed herein have independent utility and can be implemented separately, and not every embodiment can utilize every principle. However, these principles may also be embodied in various combinations, some of which can amplify the benefits of a single principle in a synergistic manner. According to the inventive principles disclosed in this patent, the various details and embodiments described above may be combined to produce additional embodiments.

[0205] Since the inventive concepts disclosed in this patent may be modified in arrangement and detail without departing from the inventive concept, such changes and modifications are considered to fall within the scope of the claims.

Claims

1. A storage device comprising: at least one storage medium; as well as A controller comprising at least one processor, wherein the processor is configured to: reading data from a first recycling unit of the at least one storage medium based on an update operation; a second recycling unit that writes data to the at least one storage medium based on the update operation; receiving a write command specifying an identifier of a recycling unit handle; as well as Based on the write command specifying the identifier of the reclaim unit handle, a second reclaim unit is written.

2. The storage device according to claim 1, wherein Based on the update operation, the reclaim unit handle is updated to reference the second reclaim unit.

3. The storage device according to claim 2, wherein: The first collection unit is associated with the collection unit handle. The storage device according to claim 2 , wherein: The reclaim unit handle is a first reclaim unit handle, and the first reclaim unit is associated with the second reclaim unit handle. The storage device according to claim 2 , wherein: The at least one processor is configured to perform a reclaim operation on a first reclaim unit based on the update operation. The storage device according to claim 2 , wherein: The at least one processor is configured to populate a second reclaim unit based at least in part on the update operation.

7. The storage device according to claim 2, wherein: The data is first data, and the at least one processor is configured to: reading second data from a third recycling unit of the at least one storage medium; and The second data is written to the second recycling unit. The storage device according to claim 7 , wherein: The third recycling unit is associated with the recycling unit handle.

9. The storage device according to claim 1, wherein: Based on the update operation, a first collection unit is associated with the collection unit handle.

10. The storage device according to claim 9, wherein: The data is first data; writing the first data into a first portion of the second recycling unit; as well as At least a second portion of the second reclamation unit includes second data associated with the reclamation unit handle.

11. The storage device according to claim 9, wherein: The data is first data; writing the first data into a first portion of the second recycling unit; The recycling unit handle is the first recycling unit handle; as well as At least a second portion of the second reclamation unit includes second data associated with the second reclamation unit handle.

12. The storage device according to claim 9, wherein The at least one processor is configured to perform a reclaim operation on a first reclaim unit based on the update operation.

13. The storage device according to claim 1, wherein Update operations involve modifying the collection unit handle.

14. A method comprising: Based on the update operation, reading data from a first recycling unit of at least one storage medium; as well as a second recycling unit that writes data to the at least one storage medium based on the update operation; receiving a write command specifying an identifier of a recycling unit handle; as well as Based on the write command specifying the identifier of the reclaim unit handle, a second reclaim unit is written.

15. The method according to claim 14, wherein Based on the update operation, the reclaim unit handle is updated to reference the second reclaim unit.

16. The method according to claim 15, wherein The first collection unit is associated with the collection unit handle.

17. The method according to claim 15, wherein: The reclaim unit handle is a first reclaim unit handle, and the first reclaim unit is associated with the second reclaim unit handle.

18. The method according to claim 14, wherein Based on the update operation, a first collection unit is associated with the collection unit handle.

19. The method according to claim 14, wherein Update operations involve modifying the collection unit handle.

20. A storage device comprising: at least one storage medium; as well as a controller comprising at least one processor configured to perform an update operation associated with a recycling unit of the at least one storage medium, wherein the first portion of the reclaim unit includes data, and the update operation includes referencing, by the reclaim unit handle, a second portion of the reclaim unit and at least a portion of over-provisioned space associated with the reclaim unit; Wherein, the at least one processor of the controller is configured to: receiving a write command specifying an identifier of a reclaim unit handle; and Based on the write command specifying the identifier of the reclaim unit handle, a second reclaim unit is written.

Images