CN117369718A - System, method and apparatus for forming and selecting recovery units in storage devices - Google Patents

Abstract

Systems, methods, and apparatus for forming and selecting recovery units in storage devices are disclosed. The storage device may include: at least one storage medium; and a controller configured to: receiving a write command, wherein the write command specifies data and a reclamation unit handle; receiving information about the data; and storing data in the reclamation unit of the at least one storage medium based on the reclamation unit handle and the information. The information may include access information. The information may include error tolerance information. The information may include data attribute information. The information may include data type information. The controller may be configured to determine the information based at least in part on the reclamation unit handle. The controller may be configured to receive an indicator separate from the reclamation unit handle; and determining the information based at least in part on the indicator.

Description

Systems, methods and devices for forming and selecting recycling units in storage devices

This application claims U.S. Provisional Patent Application No. 63/421,994 filed on November 2, 2022, U.S. Provisional Patent Application No. 63/358,861 filed on July 6, 2022, and U.S. Provisional Patent Application No. 63/358,861 filed on October 26, 2022 Priority and benefit of U.S. Provisional Patent Application No. 63/419,699, the entirety of which is incorporated herein by reference.

Technical field

The present disclosure relates generally to storage devices, and more specifically to systems, methods, and apparatus for forming and selecting recycling units in storage devices.

Background technique

Storage devices such as solid state drives (SSD) can store data in storage media that can be implemented using non-volatile memory (NVM). In some non-volatile memories, data can be updated by erasing the memory where the data is stored and rewriting new data in the erased memory. Some non-volatile memories can be written and/or read in units of pages, but erased in units of blocks, which 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.

The above information disclosed in this Background section is only for enhancement of understanding of the background of the principles of the invention and therefore it may contain information that does not constitute the prior art.

Contents of the invention

A storage device may include: at least one storage medium; and a controller configured to: receive a write command, wherein the write command specifies data and a recycling unit handle; receive information about the data; and based on the recycling unit handle and the recycling unit handle The information is stored in the recycling unit of the at least one storage medium. The information may include access information. The information may include error tolerance information. The information may include data attribute information. The information may include data type information. The controller may be configured to determine the information based at least in part on the reclamation unit handle. The controller may be configured to receive an indicator separate from the recycling unit handle; and to determine the information based at least in part on the indicator. The controller may be configured to select a recycling unit based on the information. The controller may be configured to select the recycling unit based on characteristics of at least a portion of the recycling unit. Characteristics may include the number of programming loops. Characteristics may include error accumulation characteristics. The controller may be configured to form a recycling unit based on the information. The controller may be configured to form the recycling unit based on characteristics of at least a portion of the recycling unit. Characteristics may include the number of programming loops. Characteristics may include error accumulation characteristics.

An apparatus may include put logic configured to send a write command to a storage device, wherein the write command specifies data and a reclamation unit handle, wherein the reclamation unit handle may be used to reference a location in at least one storage medium of the storage device. Recycle the unit; and send information about the data to the storage device. The placement logic may be configured to determine the information based on operations on the data source. Operations may include write operations. The placement logic may be configured to determine the information based on one or more compression operations. The placement logic may be configured to determine the information based on one or more data management schemes. The information may include access information. The information may include error tolerance information. The placement logic may be configured to send the information based at least in part on the reclaim unit handle. The placement logic may be configured to send the information using, at least in part, an indicator separable from the reclaim unit handle.

A method may include receiving a write command at a storage device, wherein the write command specifies data and a reclaim unit handle; receiving information about the data at the storage device; and storing the data in the storage device based on the reclaim unit handle and the information. In the recovery unit of at least one storage medium of the storage device. The information may include access information. The information may include error tolerance information. The method may further include selecting a recycling unit based on the information. The selection may be based on characteristics of at least a portion of the recycling unit. The method may further include composing a recycling unit based on the information. The composition may be based on the characteristics of at least a portion of the recycling unit.

A method may include: receiving a data operation request at a storage device, wherein the data operation request specifies data and a reclamation unit handle; receiving information about the data at the storage device; and based on the data operation request, the reclamation unit handle, and the information Data operations associated with a reclamation unit of at least one storage medium of the storage device are performed. The data operation request may include a write operation request, and the data operation may include a write operation. The write operation request may include a write command, and the write operation may include storing data in the reclamation unit based on the reclamation unit handle and the information.

Description of the drawings

The drawings are not necessarily to scale, and throughout the drawings, elements of similar structure or function are generally designated by similar reference numerals or portions thereof for illustrative purposes. The drawings are merely intended to facilitate description of the various embodiments described herein. The drawings do not depict every aspect of the teachings disclosed herein and do not limit the scope of the claims. In order to prevent the drawings from becoming unclear, not all components, connections, etc. may be shown, and not all components may have reference numbers. However, the mode of component configuration can be easily understood from the accompanying drawings. The drawings, together with the description, illustrate example embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure.

1A illustrates an embodiment of a data placement scheme for a storage device in a first data placement state, in accordance with disclosed example embodiments.

FIG. 1B illustrates an embodiment of the data placement scheme shown in FIG. 1A in a second data placement state according to disclosed example embodiments.

1C illustrates an embodiment of the data placement scheme shown in FIG. 1A in a third data placement state according to disclosed example embodiments.

FIG. 1D illustrates an embodiment of the data placement scheme shown in FIG. 1A in a fourth data placement state according to disclosed example embodiments.

FIG. 1E illustrates an embodiment of the data placement scheme shown in FIG. 1A in a fifth data placement state according to disclosed example embodiments.

2A illustrates an embodiment of a flexible data placement scheme for a storage device in a first data placement state, in accordance with disclosed example embodiments.

2B illustrates an embodiment of the data placement scheme shown in FIG. 2A in a second data placement state according to disclosed example embodiments.

2C illustrates an embodiment of the data placement scheme shown in FIG. 2A in a third data placement state according to disclosed example embodiments.

Figure 2D illustrates an embodiment of the data placement scheme shown in Figure 2A in a fourth data placement state according to disclosed example embodiments.

3A illustrates an embodiment of a flexible data placement scheme with reference modification in a first data placement state, in accordance with disclosed example embodiments.

3B illustrates an embodiment of the data placement scheme shown in FIG. 3A in a second data placement state according to disclosed example embodiments.

3C illustrates an embodiment of the data placement scheme shown in FIG. 3A in a third data placement state according to disclosed example embodiments.

Figure 3D illustrates an embodiment of the data placement scheme shown in Figure 3A in a fourth data placement state according to disclosed example embodiments.

4A illustrates an embodiment of an update operation for a flexible data placement scheme in a first state in accordance with disclosed example embodiments.

Figure 4B illustrates an embodiment of the update operation shown in Figure 4A in a second state according to disclosed example embodiments.

Figure 5 illustrates an embodiment of a flexible data placement scheme with reclaim unit handles in accordance with disclosed example embodiments.

Figure 6 illustrates another embodiment of a flexible data placement scheme in accordance with disclosed example embodiments.

7 illustrates a first embodiment of a technique for selecting erase blocks for one or more reclaims for a cell flexible data placement scheme in accordance with disclosed example embodiments.

8 illustrates a second embodiment of a technique for selecting erase blocks for one or more reclaims for a cell flexible data placement scheme in accordance with disclosed example embodiments.

Figure 9 illustrates an embodiment of a storage system that implements a flexible data placement scheme in accordance with disclosed example embodiments.

10 illustrates an example of an initial isolation scheme for a flexible data placement scheme for a storage device in accordance with disclosed example embodiments.

11 illustrates an embodiment of a persistence isolation scheme for a flexible data placement scheme for a storage device, in accordance with disclosed example embodiments.

12 illustrates an example embodiment of a host device that may be used to implement any of the host functions disclosed herein, in accordance with the disclosed example embodiments.

13 illustrates an example embodiment of a storage device that may be used to implement any of the storage device functions disclosed herein, in accordance with the disclosed example embodiments.

14 illustrates an embodiment of a method for flexible data placement of a storage device in accordance with disclosed example embodiments.

Detailed ways

The storage device may implement a Flexible Data Placement (FDP) scheme that enables the host to place data into one or more physical reclaim units (RUs) in the storage device. Reclaiming a unit may be implemented using a portion of a physical storage medium that may be erased as a unit (eg, one or more erase blocks). This may, for example, reduce write amplification by enabling the host to place data that may be deallocated at the same time in the same reclamation unit.

In a flexible data placement scheme, the reclamation unit may appear to the host as a logical representation of the storage media. For example, a host may use a reclamation unit handle to reference one or more reclamation units into which a storage device may write data. The storage device may select the actual physical reclaim unit referenced by the reclaim unit handle and/or the storage medium used to implement the physical reclaim unit. For example, the storage device may use a round-robin technique, a random selection technique, or a technique that always selects one or more erase blocks with a minimum number of program and/or erase (P/E) cycles for the next reclaim unit. Select physical storage media. However, these techniques may not utilize information about the data that could help the storage device select a more beneficial physical storage medium for the recycling unit in which the data is stored.

In a flexible data placement scheme according to disclosed example embodiments, a storage device may receive (eg, from a host) information regarding data to be stored in a reclamation unit referenced by a reclamation unit handle. The storage device may use this information to select and/or compose the physical reclamation units where the data is stored. Depending on the implementation details, this can improve or optimize the usage of different reclaim units, erase blocks, etc. in the storage device.

The inventive principles encompass multiple types of information that may be provided to a storage device. For example, a storage device may be provided with access information regarding data to be stored in the device. Access information may include, for example: how quickly data has been written, read, etc.; how often data is expected to be overwritten, read, etc.; how often data has been or is expected to be written, read, etc.; and/or other access information. As another example, a storage device may be provided with information regarding one or more acceptable characteristics of a storage medium for implementing a recycling unit of data. Acceptable characteristics may include: error tolerance information (such as may be based, for example, on the length of time the data is stored as well as read operations, rewrite operations (e.g., refresh operations), data movement operations (e.g., garbage collection) An acceptable bit error rate (BER) specified by the number of (GC) operations), etc.; the number of remaining P/E cycles; and/or other acceptable characteristics of the storage medium). As another example, a storage device may be provided with information regarding one or more properties of data to be stored in the device. The attribute information may include: service level agreement (SLA) information; quality of service (QoS) information; access delay information; access bandwidth information, etc. As another example, the storage device may be provided with information regarding the type and/or usage of the data to be stored, such as operating system metadata, file system tables, etc.

The inventive principles encompass a variety of techniques for providing information to a storage device regarding data to be stored at the device. For example, the information may be provided implicitly (e.g., data stored in a reclamation unit referenced by a different predefined reclamation unit handle number may have different access frequencies based on the reclamation unit handle number) and/or be explicitly Provide (eg, the storage device may be provided with fields, extensions, etc. of commands, handles, etc. that may provide explicit information about the data). As another example, information about data may be provided persistently (e.g., information for data in a sequence of write commands may be the same until the information is updated) and/or provided on an individual basis (e.g., may Use each write command to provide information for the data). As another example, information that data is to be stored at the storage device may be provided to the storage device using any communication technology including: as an extension of the reclamation unit handle (eg, an indication of the reclamation unit handle plus access information) ;Implicitly in the reclamation unit handle number;Storage controller settings;Namespace attributes;Requests using update operations on reclamation unit handles;Configuration settings as a flexible data placement scheme;On input and/or output (I /O or IO) command; in the field of a management command; as properties, settings, etc. of a non-volatile memory (NVM) subsystem, controller, namespace, etc.

Inventive principles encompass a variety of techniques for a storage device to use information about the data to select and/or compose one or more recycling units where the data is stored. For example, if the information indicates that the data may be frequently written and/or rewritten (which may be referred to as hot data), the storage device may select and/or form a recycling unit with a storage medium that may have Relatively large number of P/E cycles remaining in its expected life. As another example, if the information indicates that the data has a relatively high error tolerance, for example, because the data may be stored in the storage device as part of a redundant storage scheme (eg, a redundant array of independent drives RAID scheme), the storage The device may be selected and/or composed of a recycling unit with storage media that may have a relatively small number of P/E cycles remaining over its expected life. As another example, a storage device may use information about where data will be stored at the device to select and/or compose a recycling unit based on one or more of the following attributes of the storage media at the drive: wafer production information, storage media Erase block location on the die, voltage and/or speed characteristics of read, write (programming) and/or erase operations, bit error accumulation rate, current status of storage media and/or adjacent media, etc. and/or historical temperature exposure, access activity, etc.

The inventive principles encompass a variety of techniques for identifying, collecting, processing, etc. (eg, by a host) information to be sent to a storage device with respect to which data is to be stored at the storage device. For example, the host may observe that data written by a user (e.g., operating system, application, process, etc.) may be or may be continuously used and/or have been stored, possibly for a relatively long time, and may The information is sent to the storage device, for example, together with the write request. As another example, the host may observe that data written by the user may or may be compressed (eg, garbage collected) at the file system level, database level, etc., and send this information to the storage device, eg, along with the write request. As another example, the host may determine the number of times the data has been compressed (eg, garbage collected) and send this information to the storage device along with the data to be stored at the device. As another example, the host may characterize data usage based on one or more data management schemes (such as one or more cache replacement policies, tiered storage schemes, multi-tier storage architectures, etc.) and compare this information to what is to be used Data stored at the device is sent together to the storage device.

In some embodiments, based on information about the data, the storage device may select one or more existing reclamation units for a reclamation unit handle, form one or more reclamation units for future write requests, form one or more Recycle units for current write requests, etc.

The disclosure covers a variety of inventive principles involving flexible data placement. The principles disclosed herein may have independent applicability and may be embodied separately, and not every embodiment may utilize every principle. Furthermore, these principles can be embodied in various combinations, some of which can amplify some of the benefits of the individual principles in a synergistic manner.

For purposes of illustration, some embodiments may be presented in the context of specific implementation details such as storage devices implemented with solid state drives (SSDs) using Non-AND (NAND) flash memory, Non-Volatile Memory Express (NVMe) protocols, etc. is described. However, inventive principles are not limited to these or any other implementation details. For example, some embodiments may implement storage media with flash memory, magnetic media, storage class memory (SCM), etc., or any combination thereof.

In some embodiments where the storage medium may be implemented at least in part using flash memory, a reclamation unit may represent one or more erase blocks, NVM devices (eg, NVM dies), etc., or any combination thereof, and a reclamation group may represent a or multiple 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 of them combination.

In some embodiments where the storage medium may be implemented at least in part using magnetic media (eg, shingled magnetic recording (SMR) media), the recycling unit may represent one or more shingled portions, regions, sectors, tracks, etc. or Any combination thereof, and a reclaim group may represent one or more disks (eg, drives), platters, tracks, regions, sectors, tiles, etc., or any combination thereof.

The storage medium may be at least partially composed of storage-level memory (e.g., magnetoresistive random access memory (MRAM), resistive random access memory (ReRAM), phase change memory (PCM), cross-grid non-volatile memory, with In some embodiments implemented (memory with varying body resistance, etc.), the recycling unit may represent one or more memory banks, programming groups, etc., or any combination thereof, and the recycling group may represent one or more dies, memory banks, programming groups, etc. group, etc. or any combination thereof.

As another example, the inventive principles are not limited to use with write commands, but may be applied to any type of request for data operations involving data locality, e.g., where data operations may be based on logical to physical mappings (e.g., physical storage Any type of scheme in which data is placed in a logical representation of the medium, such as a logical block address to physical block address (LBA to PBA or L2P) mapping. For example, a storage device may receive any type of data operation request (such as a request for a write operation (e.g., write command, write zero, write one, write uncorrectable, etc.), copy operation, deallocation operation (e.g., unmap, trim, etc.), clean operations, erase operations, format operations, compare and write operations (which may be referred to as fusion commands, for example, may include a read command to read data for a compare operation and may A pair of commands (a pair of write commands) that are executed based on the results of a comparison operation, a request for an update operation, etc.). In some embodiments, the data operation request may include an indication related to data locality in the storage medium (eg, reclamation unit handle, reclamation group, etc.). Based on receiving a data operation request having an indication related to data locality in the storage medium, the storage device may, based on the information related to data locality in the storage medium and/or the data to be used in association with the data operation request (For example, the corresponding data operation will be performed based on the information related to the data stored in the write command).

1A illustrates an embodiment of a data placement scheme for a storage device in a first data placement state, in accordance with disclosed example embodiments. FIG. 1B illustrates an embodiment of the data placement scheme shown in FIG. 1A in a second data placement state according to disclosed example embodiments. 1C illustrates an embodiment of the data placement scheme shown in FIG. 1A in a third data placement state according to disclosed example embodiments. FIG. 1D illustrates an embodiment of the data placement scheme shown in FIG. 1A in a fourth data placement state according to disclosed example embodiments. FIG. 1E illustrates an embodiment of the data placement scheme shown in FIG. 1A in a fifth data placement state according to disclosed example embodiments.

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

Storage device 104 may receive input and/or output (I/O or IO) requests (which may also be referred to as commands) from host 102 to enable the host to access the NVM subsystem (e.g., write data to storage media and/or Read data from storage media). The host may partition data into namespaces indicated by the different types of shading shown in Figures 1A-1E. Specifically, data belonging to the first namespace (data referenced by namespace identifier 1 (NSID 1)) may be indicated by a shading with a diagonal line from upper right to lower left, and data belonging to the second namespace (data referenced by NSID 2 Referenced data) may be indicated by shading with a diagonal line from upper left to lower right, and data belonging to the third namespace (data that may be referenced by 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 data based on logical block addresses (LBAs), applications that may use the data, host write traffic threads, etc. and/or arranged as groups.

Memory block 108 may initially be in an erased state, as shown by the absence of shading. Prior to receiving the write command, the NVM subsystem 106 may select an erased superblock (eg, superblock 0 indicated by solid shading) in which the write data may be placed. The erased superblocks may be selected randomly or using round robin techniques. Therefore, memory block 108a may initially be empty before NVM subsystem 106 receives a write command.

Referring to FIG. 1A , storage device 104 may receive a first write command having write data belonging to NSID 1 . The NVM subsystem 106 may place data belonging to NSID 1 (indicated by the number 1 in the rounded rectangle) in the first memory block 108a of superblock 0 as shown in Figure 1A. (The number 1 may indicate the sequence of data that can be placed instead of the NSID).

Referring to FIG. 1B , storage device 104 may continue to receive additional write commands from host 102 with write data belonging to various namespaces. NVM subsystem 106 may populate memory blocks 108a-108d in Super Block 0 by placing write data in the sequence indicated by the numbers in the rounded rectangles. In some cases, the amount of data written may be greater than the space remaining in the memory block. Thus, a first portion of the write data can be placed to fill the remaining space in the first memory block, and a second portion can be placed in the empty memory block. For example, as shown in Figure 1B, upon receipt of the second write command, a first portion 2a of data belonging to NSID 2 may be used to fill the remaining space in memory block 108a, and a second portion of data belonging to NSID 2 2b may be placed in memory block 108b. As shown in Figure IB, NVM subsystem 106 may continue to place write data in Super Block 0 until Super Block 0 is full or nearly full.

Referring to FIG. 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, the NVM subsystem 106 may choose to write a new empty superblock (eg, superblock 2 indicated by solid shading) into which the write data may be placed. NVM subsystem 106 may use the first portion 6a of the data belonging to NSID 3 to fill the remaining space in memory block 108d, and the second portion 6b of the data belonging to NSID 3 may be placed in memory block 108e in super block 2. The NVM subsystem 106 may continue to place write data in Super Block 2 and then Super Block 1, with data belonging to different namespaces mixed within one or more Super Blocks as shown in Figure ID. Data belonging to different namespaces may be mixed within blocks 108 and/or super blocks 110 , for example, because the host 102 may not be aware of the manner in which and/or the way NVM subsystem 106 placed the data within blocks 108 and/or super blocks 110 . The NVM subsystem 106 has no control over the manner in which data is placed within blocks 108 and/or super blocks 110 .

Host 102 may partition data into namespaces, for example, to provide isolation between data sources such as applications, processes, logical block address (LBA) ranges, and the like. Thus, for example, when an application terminates, host 102 may simultaneously deallocate some or all data belonging to the namespace.

Figure IE illustrates an example in which the host 102 has deallocated data belonging to the namespace indicated as NSID 3, which is shown using solid shading after the deallocation. Reusing the deallocated storage space may involve erasing the deallocated storage space. However, because the superblock 110 can be erased as a unit, the NVM subsystem 106 can move the remaining valid data in the superblock to a different superblock to prevent the loss of valid data when the superblock is erased. Depending on the implementation details, this may result in write amplification that may reduce the useful life of the storage media.

2A illustrates an embodiment of a flexible data placement scheme for a storage device in a first data placement state, in accordance with disclosed example embodiments. 2B illustrates an embodiment of the data placement scheme shown in FIG. 2A in a second data placement state according to disclosed example embodiments. Figure 2C illustrates an embodiment of the data placement scheme shown in Figure 2A in a third data placement state according to disclosed example embodiments. 2D illustrates an embodiment of the data placement scheme shown in FIG. 2A in a fourth data placement state according to disclosed example embodiments.

The embodiments shown in FIGS. 2A-2D may include components (such as host 202, storage device 204, communication connection 205, and/or memory block 208) that, in some aspects, may be configured in a manner similar to FIGS. 1A-2D. The corresponding components in the embodiment shown in Figure IE operate. However, in the embodiment shown in FIGS. 2A-2D , the memory blocks 208 in the NVM subsystem 212 may be arranged in one or more reclamation units 214 , which may be erased as one unit and One or more memory blocks 208 may be included. Reclamation unit 214 may be implemented, for example, using one or more erase blocks, super blocks, or the like. Additionally, reclamation unit 214 may be identified by a corresponding reclamation unit handle 236 , which may enable host 202 to specify (eg, in a field of the write command) a specific location for storing write data associated with the write command. Recycling unit 214. In some embodiments, some or all of the reclamation units 214 may be arranged in one or more locations where the host may also specify, for example, using one or more corresponding reclamation group identifiers (eg, in a field of the write command). In recycling group 218. In some embodiments, reclamation unit handle 236 may identify more than one reclamation unit 216. For example, the reclamation unit handle 236 may identify (eg, map to) one or more reclamation units 216 in one or more (eg, each) reclamation group 218 (eg, in a manner similar to that shown in FIG. 5 ).

Therefore, by designating a specific reclamation unit 214 and/or reclamation group 218 for storing data associated with a write command, the host 202 can cause the NVM subsystem 212 to store only data belonging to one or more specific namespaces in a or in multiple recycling units 214 and/or recycling groups 218 .

For example, referring to Figure 2A, the host 202 may instruct the NVM subsystem 212 to fall within the order indicated by the numbers in the rounded rectangles in Figures 2A-2D and indicated by the numbers in parentheses below that will belong to NSID 1, NSID 2, and The data of the namespace indicated by NSID 3 is stored in reclamation unit 0, reclamation unit 1 and reclamation unit 2 respectively. For example, the 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 reclamation unit 0 of reclamation group 0. The first portion [2a] of the data for the second write command associated with NSID 1 may be written into the remainder of the top memory block 208 of reclamation unit 0 of reclamation group 0, and the second write command associated with NSID 1 The second portion [2b] of the data of the incoming command may be written into the first portion of the second memory block 208 after the top of reclamation unit 0 of reclamation group 0. The data [3] of the third write command associated with NSID2 may be written to the first portion of the top memory block 208 of reclamation unit 1 of reclamation group 0. The 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 reclamation unit 0 of reclamation group 1. The data for the fifth write command [5] associated with NSID 3 may be written to the next portion of the top memory block 208 of reclamation unit 0 of reclamation 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 after the top of reclamation unit 0 of reclamation group 0. The first portion [7a] of the data for the seventh write command associated with NSID 1 may be written from the remainder of the second memory block 208 after the top of reclamation unit 0 of reclamation group 0 and associated with NSID 1 The second portion [7b] of the data of the associated seventh write command may be written in the first portion of the third memory block 208 after the top of reclamation unit 0 of reclamation group 0. The first portion [8a] of the data of the eighth write command associated with NSID 2 may be written into the remainder of the top memory block 208 of reclamation unit 1 of reclamation group 0, and the eighth write associated with NSID 2 The second portion [8b] of the data of the incoming command may be written into the first portion of the second memory block 208 after the top of reclamation unit 1 of reclamation group 0. The first portion [9a] of the data for the ninth write command associated with NSID 3 may be written into the remainder of the top memory block 208 of reclamation unit 0 of reclamation group 1, and the ninth write command associated with NSID 3 The second portion [9b] of the data of the incoming command may be written into the first portion of the second memory block 208 after the top of reclamation unit 0 of reclamation group 1.

Referring to FIG. 2B , host 202 may continue to send write commands and associated write data, which may instruct NVM subsystem 212 to store the write data using the write commands in the sequence indicated by the numbers in the rounded rectangles with In the recycling unit corresponding to each namespace, the sequence may correspond to the data of the associated write command.

Referring to Figure 2C, the host may deallocate some or all 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 at different times with various amounts of time in between. ), are deallocated at different times in various combinations, or all at once. Depending on the implementation details, this may enable NVM subsystem 212 to erase reclaim unit 0 (shown without shading in Figure 2D) without moving data belonging to other namespaces, thereby reducing or eliminating write amplification. Although FIG. 2D may show a reclamation unit handle 236 that references a reclamation unit 214 with one or more memory blocks 208 that may be erased, in some embodiments, one or more deallocated memory blocks 208 may be deleted after being erased. Return to free memory pool before erasing. Therefore, in some embodiments, the memory block 208 indicated as being erased in Figure 2D may not be the same memory block indicated as being deallocated in Figure 2C, but may have been previously erased (e.g., , when the memory block is in the free block pool and/or is not referenced by the reclamation unit handle 236) and is arranged to other memory blocks in the new (eg, empty) reclamation unit 214. In some embodiments, in addition to and/or as an alternative to namespaces, data may be partitioned and/or based on logical block addresses (LBAs), applications that may use the data, host write traffic threads, etc. Arranged as groups.

3A illustrates an embodiment of a flexible data placement scheme with reference modification in a first data placement state, in accordance with disclosed example embodiments. 3B illustrates an embodiment of the data placement scheme shown in FIG. 3A in a second data placement state according to disclosed example embodiments. 3C illustrates an embodiment of the data placement scheme shown in FIG. 3A in a third data placement state according to disclosed example embodiments. Figure 3D illustrates an embodiment of the data placement scheme shown in Figure 3A in a fourth data placement state according to disclosed example embodiments.

The embodiment shown in FIGS. 3A-3D may include a host 302 and a storage device 304 communicating using a communication connection 305. Storage device 304 may include a controller 326 , which may control the overall operation of storage device 304 , and storage media including reclamation units 314 arranged in one or more reclamation groups 318 . One recycling group 318, referred to as recycling group 0, is shown in FIGS. 3A-3D, but recycling units 314 may be arranged in any number of recycling groups 318. For purposes of illustration, in the embodiment shown in FIGS. 3A-3D , recycling group 0 may include five recycling units 314 identified as RU 0, RU 1, RU2, RU 3, and RU 4, each Each reclamation unit 314 may have a storage capacity of five pages of data, but any number and/or size of reclamation units may be used. For example, in a practical implementation, a reclamation unit may include one, two, four, or more erase blocks, each of which may have a storage capacity measured in MB or GB and a page size measured in KB.

One or more reclamation unit handles 336 may reference corresponding reclamation units 314. For example, as shown in Figure 3A, a first reclamation unit handle 336 identified as reclamation unit handle 0 (or RUH 0) may reference RUl as indicated by arrow 317. The second reclamation unit handle 336, identified as reclamation unit handle 1 (RUH 1), may reference RU 4 as shown by arrow 319a.

Referring to FIG. 3A , storage device 304 may be shown as being in a state where two pages of data may be stored in reclamation unit 314 identified as RU 1 and four pages, as indicated by the diagonally shaded portions of RU 1 and RU 4 . The data may be stored in an initial state in the recycling unit 314 identified as RU 4.

Host 302 may send write command 330 and page data 321 (or an address, pointer, or other indicator of the location of page data 321) to storage device 304 using communication connection 305. The command 330 may include a placement identifier 334 , which may include a reclamation group identifier 315 and/or a reclamation unit handle 336 . In the example shown in FIGS. 3A-3D , reclamation group identifier 315 and reclamation unit handle 336 may instruct storage device 304 to store page data 321 in reclamation unit 314 referenced by reclamation unit handle 1 in reclamation group 0 at.

In some embodiments, command 330 and/or put identifier 334 may use different techniques to specify the reclamation unit into which data 321 is to be written. For example, as shown in the embodiment described with respect to FIG. 4 , the command 330 and/or the placement identifier 334 may include a placement handle that may specify a recycle unit handle, rather than providing the recycle unit handle 336 directly.

Referring to FIG. 3B , controller 326 may receive write command 330 and/or page data 321 . Based on the reclamation group identifier 315 and the reclamation unit handle 336 included in the put identifier 334 in the write command 330 , the controller 326 may determine that the page data 321 should be stored in the reclamation unit referenced by the reclamation unit handle 1 in reclamation group 0 in the recycling unit 314. In the example shown in Figure 3B, reclamation unit handle 1 may reference reclamation unit 314 identified as RU 4, and therefore, as shown in Figure 3C, controller 326 may store page data 321 in RU 4 middle.

Referring to Figure 3D, page data 321 may populate reclamation unit 314, indicated as RU 4 as shown using diagonal shading. Accordingly, controller 326 may modify reclamation unit handle 1 to reference a different (eg, empty) reclamation unit 314 within reclamation group 0 (such as RU 2) as indicated by arrow 319b. The controller 326 may then continue to populate RU 2 with the data received from the host using a write command 330 specifying reclaim unit handle 1 in the put identifier 334 .

4A illustrates an embodiment of an update operation for a flexible data placement scheme in a first state in accordance with disclosed example embodiments. Figure 4B illustrates an embodiment of the update operation shown in Figure 4A in a second state according to disclosed example embodiments.

The embodiment shown in FIGS. 4A-4B may include a host 402 and a storage device 404 communicating using a communication connection 405. Storage device 404 may include a controller 426 that may control the overall operation of storage device 404 and storage media including reclamation units 414 arranged in one or more reclamation groups 418 .

One recycling group 418, referred to as recycling group 0, is shown in FIGS. 4A-4B, but recycling units 414 may be arranged in any number of recycling groups 418. For purposes of illustration, in the embodiment shown in FIGS. 4A-4B , although recycling group 0 may include five recycling units 414 identified as RU 0 , RU 1 , RU 2 , RU 3 , and RU 4 , each reclamation unit 414 may have a storage capacity of five pages of data, but any number and/or size of reclamation units may be used. For example, in a practical implementation, a reclamation unit may include one, two, four, or more erase blocks, each of which may have a storage capacity measured in MB and a page size measured in KB.

One or more reclamation unit handles 436 may reference corresponding reclamation units 414. For example, reclamation unit handle 0 (RUH 0) may refer to reclamation unit RU 1 as indicated by arrow 417a, and reclamation unit handle 1 (RUH 1) may refer to reclamation unit RU 4 as indicated by arrow 419a. The reclamation unit handle 436 may reference the reclamation unit 414 where the controller may use the reclamation unit handle 436 to store the next page of data.

Referring to FIG. 4A , storage device 404 may be shown as being in a state where two pages of data may be stored in reclamation unit 414 identified as RU 1 and four pages, as shown by the diagonally shaded portions of RU 1 and RU 4 . The data may be stored in an initial state in the reclamation unit 414 identified as RU 4. Accordingly, storage device 404 may be shown in an initial state that may be similar to the initial state of storage device 304 in FIG. 3A.

However, the controller 426 may receive an update request 423 (eg, usage command, indication, etc.) instead of receiving a write command. The update request 423 may request an update operation in which the controller 426 may modify one or more reclamation unit handles 436 to reference a new (eg, empty) reclamation unit 414 . The update request 423 may include an update list 425, which may specify one or more reclamation unit handles 436 that may be modified by the update operation. In the example shown in FIG. 4A , update list 425 may include reclamation unit handle 0 and reclamation unit handle 1 . In some embodiments, update request 423 may use different techniques to specify one or more reclaim handles 436 that may be updated. For example, as shown in the embodiment described with respect to FIG. 5 , the update request 423 may include a put handle that may specify a reclamation unit handle, rather than directly providing the reclamation unit handle 436 .

Referring to FIG. 4B , the controller 426 may execute the request by modifying the reclamation unit handle 0 to reference the reclamation unit RU 0 as shown by arrow 417b, and by modifying the reclamation unit handle 1 to refer to the reclamation unit RU 3 as shown by the arrow 419b. update operation. Therefore, data sent with a subsequent write command specifying reclamation unit handle 0 or reclamation unit handle 1 can be written to RU 0 or RU 3 respectively.

As shown in Figure 4B, the recycling units RU 1 and RU 4 may be only partially filled after the update operation. However, depending on the physical storage medium used to implement the recycling unit 414, partially filling the recycling unit may reduce the reliability, durability, performance, etc., of the recycling unit and/or the storage medium on which the recycling unit is implemented. Accordingly, in the embodiment shown in FIG. 4B , controller 426 may populate RU 1 and/or RU 4 with padding data, such as zeros, random data, and/or metadata, as shown by solid shading. some or all of the blank parts.

However, the use of padding data can result in wasted or underutilized storage space. For example, the portions of RU 1 and/or RU 4 shown in Figure 4B with populated data may not be used to store data until they are reclaimed (eg, by a garbage collection operation).

Figure 5 illustrates an embodiment of a flexible data placement scheme with reclaim unit handles in accordance with disclosed example embodiments. The embodiment shown in Figure 5 may include a controller 526 and an NVM subsystem 512, which may be located in a storage device, for example. NVM subsystem 512 may include P reclamation groups 518 identified as reclamation group 0 through reclamation group P-1. Recycling group 518 may include one or more recycling units 514 .

Controller 526 may receive I/O commands 530 from the host via communication interface 528 . I/O command 530 (which may be a write command in the example shown in FIG. 5 ) may include a namespace identifier (NSID) 532 and/or a placement identifier 534 . The put identifier 534 may include a recycle group identifier 515 and/or a put handle 516 that may enable the host to specify a recycle group 518 and/or a recycle unit 514 within the recycle group 518 , respectively, for storage associated with the write command 530 The data. Accordingly, in some embodiments, the scheme illustrated in Figure 5 may enable a host to combine data that may be deallocated together (e.g., data belonging to a namespace) with one or more reclaims that may be erased as a unit. Unit 514 is aligned.

In some embodiments, the put handle 516 may be mapped to a reclamation unit handle (RUH) 536 that may reference one or more reclamation units 514 in one or more reclamation groups 518 , rather than directly indicating one reclamation unit 514 . For example, a reclamation unit handle may be mapped to one reclamation unit 514 in each reclamation group 518 . FIG. 5 shows an example mapping from each reclamation unit handle 536 to one reclamation unit in each reclamation group 518 . In the embodiment shown in FIG. 5, the controller 526 may use N reclamation unit handles 536 identified as reclamation unit handle 0 through reclamation unit handle N-1. In some embodiments, reclamation unit handle 536 may be characterized as a controller resource.

The controller 526 may use the put handle list 538 to map one or more put handles 516 to one or more RUH identifiers (RUH IDs) 540 , which in turn may identify the corresponding recycle unit handle 536 . In the embodiment shown in Figure 5, the put handle list 538 may include M put handles identified as put handle 0 through put handle M-1.

In some embodiments, placement handle 516 may be qualified to namespace 524 (in this example, the namespace is identified as namespace A). The namespace may in turn contain one or more (eg, all) reclamation units 514 referenced by one or more reclamation unit handles 536 identified in the put handle list 538 (eg, by RUH ID 540). In some embodiments, put handle list 538 may be created, populated, modified, maintained, etc., by a host, a storage device (eg, controller 526), or any other entity or combination thereof. In some embodiments, in addition to and/or as an alternative to namespaces, data may be partitioned and/or based on logical block addresses (LBAs), applications that may use the data, host write traffic threads, etc. Arranged as groups.

In some embodiments, the use of placement handle 516 and/or reclamation unit handle 536 may enable the flexible data placement scheme illustrated in Figure 5 to use reclamation units as logical representations of physical non-volatile storage devices within a reclamation group. While presented to the host, the reclamation group may be physically erased, such as by controller 526, without disturbing other reclamation units 514. Controller 526 may implement logical reclamation units specified by the host (e.g., using placement identifier 534) using physical storage media (e.g., one or more erase blocks on the NVM die), where the physical storage media may be used by controller 526 Selected and erased as a cell.

In some embodiments, selection of recycling units 514 and/or recycling groups 518 may be performed, at least in part, by controller 526 . For example, if controller 526 receives write command 530 that does not include put identifier 534, controller 526 may use reclamation unit handle 536 mapped by default put handle 516 (e.g., put handle 0) and select reclamation group 518, The recycling unit 514 within the selected recycling group 518 and referenced by the recycling unit handle 536 mapped by the default placement handle 516 is thereby selected. As another example, if controller 526 receives a write command 530 with a put identifier that includes put handle 516 but does not include recycle group identifier 515 , controller 526 may respond by selecting recycle group 518 and using the selected recycle group. Reclamation unit 514 is selected by a reclamation unit 514 within 518 and referenced by reclamation unit handle 536 (which is mapped by put handle 516 provided by write command 530).

In some embodiments, the flexible data placement scheme shown in Figure 5 may be implemented, at least in part, using the NVMe protocol. In such embodiments, placement identifier 534 may be implemented as part of command 530 (eg, the instruction portion of an NVMe command); M, N, and/or P may be configurable, eg, using NVMe namespace management commands. Parameters; controller 526 may be implemented using one or more NVMe controllers; and/or NVM subsystem 512 may be implemented as an NVMe subsystem, a durability group (which in some embodiments may be co-extensive with storage), NVMe domain, etc., or any combination thereof. In embodiments implemented at least in part using the NVMe protocol, a directive specific (DSPEC) field may be used to provide a placement identifier (eg, a reclamation group (which may be indicated by a reclamation group identifier) and a placement handle). The DSPEC field may be used, for example, in implementations where the instruction type (DTYPE) field may be used to indicate that the flexible data placement feature is used. In such embodiments, an invalid and/or default (eg, all zeros) value for the DSPEC field may indicate the absence of a reclaim group indicator and/or a put handle.

In embodiments of the flexible data placement scheme shown in FIGS. 2A-2D, 3A-3D, 4A-4B, and/or 5, the recycling unit may be implemented (at least from the perspective of the host) as A logical representation of the underlying portion of a physical storage medium. Accordingly, the host may be shielded from and/or unaware of one or more ongoing operations and/or conditions of the storage device, which one or more ongoing operations and/or conditions of the storage device may be. The operations and/or conditions may adversely affect one or more operations involving the physical implementation of the logical reclamation unit selected by the host.

Figure 6 illustrates another embodiment of a flexible data placement scheme in accordance with disclosed example embodiments. In the embodiment shown in FIG. 6 , storage device 604 may include storage media implemented using a non-volatile memory device (eg, an NVM die) 620 controllable by controller 626 . Storage device 604 may communicate with host 602 using communication connection 605.

The embodiment shown in FIG. 6 may include eight NVM devices 620 implemented as NVM dies indicated as 620-0, ..., 620-7, which may be collectively and/or individually referred to as 620. Each NVM die may include a first plane shown on the left side of the die and a second plane shown on the right side of the die. Each plane may include 20 erase blocks 660, which are shown as rectangles with numbers within them. In some embodiments, the number in erase block 660 may represent the percentage of lifetime P/E cycles that have been performed on erase block 660. For example, an erase block with number 30 may have used 30% of its life P/E cycle. For convenience, individual erase blocks 660 within a plane may be represented by numbers within them. In some other embodiments, the numbers in the erase block may represent another aspect of the erase block (such as location on the NVM die, characterized bit error accumulation rate, historical temperature exposure, read and/or write disturbances Log (e.g., the log may represent a cumulative count, etc.).

NVM die 620 may be arranged in lanes 622, with two dies per lane. Thus, NVM die 620_0 and 620_1 are connected to channel 622_0, NVM dies 620_2 and 620_3 are connected to channel 622_1, NVM dies 620_4 and 620_5 are connected to channel 622_2, and NVM dies 620_6 and 620_7 are connected to channel 622_3. The number and/or arrangement of dies, planes, lanes, erase blocks, etc. shown in FIG. 6 is for the purpose of illustrating the principles of the invention only, and other embodiments may include any number and/or arrangement of dies, planes, etc. , channel, erase block, etc. In some embodiments, the RUH may be used to temporarily address one or more RUs 760 while the one or more RUs 760 receive write data from the host 702 .

7 illustrates a first embodiment of a technique for selecting erase blocks of one or more reclaim units for a flexible data placement scheme in accordance with disclosed exemplary embodiments. The techniques shown in Figure 7 may be implemented, for example, using the storage device shown in Figure 6, and components similar to those shown in Figure 6 may be identified using reference numbers ending in the same digit.

Referring to FIG. 7 , NVM die 720 may be arranged in a single reclaim group 718 . The reclamation unit may be composed by selecting (eg, by controller 726 ) one or more erase blocks 760 based on one or more rules related to placement of NVM dies and/or planes 720 , lanes 722 , etc. For example, the reclamation unit may be composed by selecting one erase block 760 per lane 722 from each plane of an NVM die 720 .

However, within a plane, one or more erase blocks may be randomly selected. For example, the first reclaim unit (which may be referred to as RU 0) may be composed of erase blocks indicated using thick solid outlines. Using this technique, RU 0 may include erase block 64 in the left plane of NVM die 720-0, erase block 30 in the right plane of NVM die 720-0, erase block 30 in the left plane of NVM die 720-2 Erase block 14 in the right plane of NVM die 720-2, erase block 92 in the left plane of NVM die 720-4, erase block 53 in the right plane of NVM die 720-4 Erase block 24, erase block 47 in the left plane of NVM die 720-6, and erase block 79 in the right plane of NVM die 720-6.

As mentioned above, for convenience, individual erase blocks 760 within a plane may be represented by numbers within them, which may also represent other characteristics (such as the percentage of P/E cycles used).

Therefore, erase block 760 (thick solid outline) within reclaim unit RU 0 may have a variety of program cycle counts.

Alternatively, cells may be formed by selecting one or more erase blocks 760 within each plane that may have the lowest program cycle count. For example, the second reclaim unit (which may be referred to as RU 1) may be composed of the erase block (indicated using a thick dashed outline) with the lowest program cycle count. Using this technique, RU 1 may include erase block 0 in the left plane of NVM die 720-1, erase block 5 in the right plane of NVM die 720-1, erase block 5 in the left plane of NVM die 720-3 Erase block 0 in the right plane of NVM die 720-3, erase block 1 in the left plane of NVM die 720-4, erase block 1 in the right plane of NVM die 720-4 Erase block 0, erase block 2 in the left plane of NVM die 720-7, and erase block 6 in the right plane of NVM die 720-7.

Therefore, erase block 760 (thick dashed outline) within reclaim unit RU1 may have a relatively low program cycle count.

Depending on the implementation details, any of these techniques may result in poor performance of the recycling unit. For example, if storage device 704 receives a write command with data that may be accessed frequently (eg, hot data), controller 726 may store the data in a reclamation unit RU 0 composed of randomly selected erase blocks, And thus erase blocks with various program cycle counts may be included, including erase blocks with relatively high program cycle counts that may wear out when used to store hot data. As another example, if storage device 704 receives a write command with data that may not be accessed again for a relatively long period of time (e.g., cold data), controller 726 may store the data using a minimum programming cycle Count of erase blocks consisting of a reclaim unit RU 1 that may be wasted in storage that can be tolerated in erase blocks with relatively high program cycle counts (e.g., more efficiently, at lower cost, etc.) on the cold data.

8 illustrates a second embodiment of a technique for selecting erase blocks for one or more reclaims for a cell flexible data placement scheme in accordance with disclosed exemplary embodiments. The techniques shown in Figure 8 may be implemented, for example, using the storage device shown in Figure 6, and components similar to those shown in Figure 6 may be identified using reference numbers ending with the same digits.

Referring to FIG. 8 , NVM dies 820 may be arranged in a single reclaim group 818 . The reclamation unit may be composed by selecting (eg, by controller 826) one or more erase blocks 860 based on one or more rules related to placement of NVM dies and/or planes 820, lanes 822, etc. For example, the reclamation unit may be composed by selecting one erase block 860 per lane 822 from each plane of an NVM die 820 .

However, within a plane, one or more erase blocks 860 may be selected based on information 861 about the data to be stored in the reclaim unit. For example, information 861 may be received from host 802 using communication connection 805. Host 802 may include placement logic 863 that may determine (eg, identify, collect, process, etc.) information 861 to be sent to storage device 804 . Controller 826 may include reclamation unit logic 865 that may use information 861 to select reclamation units and/or for erase blocks 860 to be included within the reclamation units.

For example, information 861 may indicate that the data to be stored in the first reclamation unit (which may be referred to as RU 2) may be relatively cold data that is not expected to be accessed frequently. Therefore, reclamation unit logic 865 may form RU 2 using erase blocks 860 with relatively high P/E cycle counts as indicated by the thick solid outline. Using this technique, RU 2 may include erase block 87 in the left plane of NVM die 820-0, erase block 91 in the right plane of NVM die 820-0, erase block 91 in the left plane of NVM die 820-2 erase block 92 in the right plane of NVM die 820-2, erase block 86 in the left plane of NVM die 820-4, erase block 92 in the right plane of NVM die 820-4 Erase block 93, erase block 92 in the left plane of NVM die 820-6, and erase block 90 in the right plane of NVM die 820-6.

The controller 826 and/or the reclaim unit logic 865 uses the composed reclaim unit RU 2 to store the data received for the current write command (e.g., the controller 826 may reference RU2 using the reclaim unit handle provided by the current write command) , or the composed reclamation unit RU2 may be saved for use with future write commands, reclamation unit handles, etc.

Depending on the implementation details, the reclaim unit RU 2 composed as described above can be used to efficiently store data indicated by the host as relatively cold data, thereby saving other erase blocks with relatively low P/E cycle counts for relatively hot data. .

Alternatively or additionally, information 861 may indicate that data to be stored in the second recovery unit (which may be referred to as RU 3 ) may be relatively sensitive to stresses arising from being located near the periphery of NVM die 820 . Thus, reclamation unit logic 865 may form RU 3 using erase block 860 , shown in thick dashed outline, located near the center of NVM die 820 . Using this technique, RU 3 may include erase block 52 in the left plane of NVM die 820-1, erase block 51 in the right plane of NVM die 820-1, erase block 51 in the left plane of NVM die 820-3 erase block 40, erase block 39 in the right plane of NVM die 820-3, erase block 37 in the left plane of NVM die 820-5, erase block 37 in the right plane of NVM die 820-5 Erase block 52, erase block 43 in the left plane of NVM die 820-7, and erase block 40 in the right plane of NVM die 820-7.

Controller 826 and/or reclaim unit logic 865 uses constituent reclaim unit RU 3 to store data received for the current write command (e.g., controller 826 may use the reclaim unit handle provided by the current write command to reference RU3) , or the composed reclaim unit RU 3 may be saved for use with future write commands, reclaim unit handles, etc.

Depending on the implementation details, the recovery unit RU 3 composed as described above may be used to efficiently store data indicated to be relatively sensitive to stresses arising from being located near the periphery of the NVM die 820 while using the Other erase blocks 860 are used to form other erase units to store data that may be less sensitive to being located near the periphery of the NVM die 820 .

Although the embodiments shown in Figures 7 and 8 are implemented using a single reclaim group that may include all eight NVM dies, in other embodiments the NVM dies may be arranged in any other configuration of reclaim groups . For example, in some embodiments, each NVM die may be configured as a separate reclamation group. In such embodiments, the reclamation unit may be composed, for example, by selecting one erase block from each plane of the NVM die. Within a plane, one or more erase blocks may be selected based on information (eg, received from the host) about the data to be stored in the reclamation unit. In such embodiments with multiple reclamation groups, the reclamation group may be selected based on information about the data to be stored in the reclamation unit (eg, to best align with the reclamation group). Additionally, in NVMe implementations with flexible data placement, if the write command does not specify a reclamation group, controller 826 may select a reclamation group based on information 861, for example.

Figure 9 illustrates an embodiment of a storage system that implements a flexible data placement scheme in accordance with disclosed example embodiments. The embodiment shown in Figure 9 may include a host 902 and a storage device 904 communicating using a communication connection 905. Storage device 904 may include a controller 926 (which may control the overall operation of storage device 904) and storage media 913 including one or more recovery units 914 that may be selected, composed, etc., as described herein.

Controller 926 may include reclamation unit logic 965 that may implement any of the flexible data placement schemes disclosed herein and may select and/or based on information 961 regarding data 921 to be stored in one or more reclamation units 914 Or form one or more recycling units 914. Information 961 may be provided by host 902, for example. Data 921 may be specified, for example, by a write command 930 sent from host 902 to storage device 904. Write command 930 may, for example, include data 921 with and/or within write command 930 by sending a pointer, address, and/or data therein (e.g., in memory, in a storage device , on a network, etc.), and/or in any other manner to specify the data 921.

Host 902 may include one or more processors 962 that may implement placement logic 963 that provides any information 961 regarding data to be stored in one or more reclamation units 914 of storage device 904 . One or more processors 962 may also run one or more operating systems 972, which in turn may run applications 974, file systems 976, etc. Any of the operating system 972 , applications 974 , file system 976 , etc. may be the user's data that may be stored in one or more reclamation units 914 of the storage device 904 . In some embodiments, placement logic 963 may use, for example, specialized hardware (such as a complex programmable logic device (CPLD), a field programmable gate array (FPGA), an application specific circuit (ASIC), etc.) with one or more processors 962 Implemented partially or completely separately. For example, in some embodiments, placement logic 963 may be implemented at least in part using hardware that may perform a lookup using one or more keys to obtain one or more values.

The placement logic 963 in the host 902 and the reclaim unit logic 965 in the storage device 904 may include information logic 963-1 and 965-1, respectively, which may be implemented and provided to the storage device 904. and/or host-side functions and device-side functions related to the type of information 961 used by the storage device 904 to select and/or compose a program for use based on, for example, a write request (eg, a write command) received from the host 902 One or more reclamation units 914 that store data.

In some embodiments, information logic 963-1 and/or 965-1 may enable host 902 to provide and/or storage device 904 to use access information regarding data to be stored in the reclamation unit. Access information may include access information such as historical access information such as how quickly and/or how frequently data has been written, read, rewritten, etc. For example, the data may be considered relatively cold data if it has been written and then not read or rewritten for a relatively long period of time. Historical access information may be sent from the host 902 to the storage device 904, which may use the historical access information to determine whether data 921 to be stored in one or more reclamation units 914 may be considered hot, cold, etc. Therefore, device-side information logic 965-1 can predict future access to data 921 based on historical access information.

Additionally or alternatively, access information sent from host 902 to storage device 904 may include determinations made by host-side information logic 963-1. For example, host 902 may store a set of data in storage 904 using a first set of LBAs. Host 902 may read a portion of the data set from storage 904, for example, as part of a file system compression operation (e.g., a garbage collection operation to remove one or more gaps between remaining valid portions of the data set), And that portion of the data set is written to storage 904 using the second set of LBAs. Host-side information logic 963-1 may send information 961 to device-side information logic 965 indicating that data 921 may be relatively cold data (eg, data 921 has not been recently rewritten and therefore was compressed as part of a garbage collection operation). -1. Therefore, the host-side information logic 963-1 can predict future access to the data 921 based on historical access information.

Information logic 963-1 and/or 965-1 may enable host 902 to provide and/or storage device 904 to use predictions based on any other basis than predictions based on historical access information. For example, the host may identify new threads launched by application 974 as relatively active, important, etc., and assume that any data associated with the application may be hot data. Accordingly, host side information logic 963-1 may predict future accesses of data 921 based on one or more characteristics of the thread, application 974, etc., and will indicate that any written data 921 associated with the thread, application, etc. may be considered The relatively hot data information 961 is sent to the device side information logic 965-1.

Additionally or alternatively, access information may include information such as how often data is expected (eg, predicted) to be rewritten, read, etc. For example, even if some data has not been accessed recently, there may be one or more indicators of an upcoming event, recent access to related data, etc. that may indicate that the data may be accessed soon, and therefore, the data may be considered relatively Hot data.

Additionally or alternatively, information logic 963-1 and/or 965-1 may enable host 902 to provide and/or storage device 904 to use information regarding one or more acceptable characteristics of a storage medium that is available Data 921 provided for storing information 961. Acceptable characteristics may include error margin information such as an acceptable bit error rate (BER), which in turn may be based on bit error accumulation. For example, BER and/or bit error accumulation may be based on the length of time the data is stored, the number of read operations performed on the data, the number of rewrite operations (e.g., refresh operations) performed on the data, one or Multiple data movement operations (eg, garbage collection (GC) operations), etc. are specified. As another example, BER and/or bit error accumulation may be related to the number of remaining P/E cycles in the expected and/or estimated lifetime of the reclamation unit and/or the erase blocks used in the reclamation unit. As with the information regarding access as described above, the information regarding acceptable characteristics of storage media may be based on historical information, predictions based on historical information, predictions based on any other basis, or the like.

Additionally or alternatively, information logic 963-1 and/or 965-1 may enable host 902 to provide and/or storage device 904 to use information regarding one or more attributes of data 921 for storage in the device. For example, the attribute information may include quality of service (QoS) information, which may specify the required availability of data to be stored in the reclamation unit. As another example, the attribute information may include access delay information of data to be stored in the recycling unit. This may be affected by, for example, wear leveling of the storage medium (eg, the lifetime of the NVM cell may affect read time, write (programming) time, erase time, etc.). As another example, attribute information may include access bandwidth information that may also be affected by, for example, wear leveling of the storage medium. As another example, the attribute information may include service level agreement (SLA) information, which may specify, for example, the minimum number of P/E cycles required to remain on the storage medium on which the data will be stored, regardless of whether the data may actually be accessed frequently. access (for example, even if the data to be stored is relatively cold data). As with the information regarding access as described above, the information regarding one or more attributes of data 921 may be based on historical information, predictions based on historical information, predictions based on any other basis, etc.

Additionally or alternatively, information logic 963-1 and/or 965-1 may enable the host 902 to provide and/or enable the storage device 904 to use information regarding the type and/or usage of the data 921 to be stored in the reclamation unit. Information. For example, data such as operating system metadata, file system tables, etc. may be accessed frequently, and therefore, the reclamation unit in which such data may be stored may be selected and/or composed to include a relatively large amount of P/E cycle remaining one or more erase blocks. As with the information regarding access as described above, the information regarding the type and/or usage of data 921 may be based on historical information, predictions based on historical information, predictions based on any other basis, etc.

In some embodiments, the placement logic 963 in the host 902 and the recycling unit logic 965 in the storage device 904 may include communication logic 963-2 and 965-2 respectively, and the communication logic 963-2 and 965-2 may respectively implement information processing. 961 Host-side functions and device-side functions related to the manner in which the host 902 can communicate to the storage device 904 .

Communication logic 963-2 and/or 965-2 may enable host 902 to receive information 961 implicitly and/or explicitly, and/or enable storage device 904 to send information 961 implicitly and/or explicitly. For example, information 961 may be implicitly conveyed by defining one or more reclamation unit handle identifiers (e.g., reclamation unit numbers) that may be recognized and/or expected to correspond to the Different access information for data stored in the corresponding recycling unit. For example, a reclamation unit handle RUH 0 may be recognized as implicitly indicating that the data stored using the reclamation unit handle is relatively hot data, and a reclamation unit handle RUH 1 may be recognized as implicitly indicating that the reclamation unit handle will be used. The stored data is relatively cold data. Additionally, a range of reclamation unit handle identifiers (e.g., a numeric range) may be used to indicate a range of access information (e.g., a range of access frequencies, with one end of the range indicating the most frequently accessed data and the other end indicating the least frequently accessed data). data). As another example, a reclamation unit handle RUH 3 may be recognized as implicitly indicating that data to be stored using this reclamation unit handle may be stored in a location with relatively low performance characteristics (eg, a relatively high P/E cycle count). in the recycling unit.

Additionally or alternatively, communication logic 963-2 and/or 965-2 may enable host 902 to explicitly use, for example, one or more fields, extensions, etc. of a command, handle, etc. that may provide explicit information about the data. The information 961 is received, and/or the storage device 904 is able to send the information 961 explicitly, for example, using one or more fields, extensions, etc. of a command, handle, etc. that can provide explicit information about the data. For example, the host can send a reclaim unit handle that includes the extension. One type of extension may indicate that data to be stored using the reclamation unit handle may be relatively hot, and another type of extension may indicate that data to be stored using the reclamation unit handle may be relatively cold. One or more additional extensions can indicate that the data is somewhere between hot and cold. Depending on the implementation details, such implementations may use one or more reclamation unit resources that may be sized based on each indication multiplied by the number of reclamation unit handles used.

Additionally or alternatively, communication logic 963-2 and/or 965-2 may enable host 902 to receive information 961 in a persistent manner, and/or storage device 904 to send information 961 in a persistent manner (e.g., for The information written to the data of the command sequence and/or the recycling unit handle may be the same until the information is updated). For example, the host may send an indication that may be a setting to indicate that a reclaim unit for one or more subsequent write commands may be processed, with information about a specific type of data, e.g., until the setting is changed and until a specific Time until a certain number of commands have been processed using the settings, a certain number of reclaim units have been filled for the reclaim unit handle, etc.

Additionally or alternatively, communication logic 963-2 and/or 965-2 may enable host 902 to receive information 961 on an individual basis, and/or enable storage device 904 to send information 961 on an individual basis. For example, information about the data to be stored in one or more reclamation units may be provided for each write command, each reclamation unit handle update, etc.

Additionally or alternatively, communication logic 963-2 and/or 965-2 may enable host 902 to use any other communication technology (such as settings of storage controllers; namespace attributes; use of update operations on reclaim unit handles) request; as a configuration setting for a flexible data placement scheme; in the field of input and/or output (I/O or IO) commands; in the field of management commands; as a non-volatile memory (NVM) subsystem, control properties, settings, etc.) of the storage device, namespace, etc.) to receive information 961, and/or enable the storage device 904 to use any other communication technology (such as settings of the storage device controller; namespace attributes; using updates to the reclaim unit handle A request for an operation; as a configuration setting for a flexible data placement scheme; in the field of input and/or output (I/O or IO) commands; in the field of management commands; as a non-volatile memory (NVM) subsystem, Properties, settings, etc. of a controller, namespace, etc.) to send message 961. For example, some or all of the information 961 may be provided with a write command, such as write command 330 shown in Figures 3A-3D. As another example, some or all of the information 961 may be provided with an update request, such as update request 423 shown in Figures 4A-4B. As another example, some or all of the information 961 may be provided in conjunction with namespace management operations such as establishing, configuring, and/or updating namespace 525 shown in Figure 5. As another example, some or all of the information 961 may be related to NVM subsystem management operations such as establishing, configuring, and/or updating the NVM subsystem shown in FIGS. 1A-1E and/or 2A-2D, respectively. 106 and/or 206) are provided together. As another example, in implementations using NVMe, information 961 may use a data set management (DSM) command (eg, using a context attribute), using one or more bits in an instruction specific field (eg, a DSPEC field), and/or is communicated using the command type field (DTYPE field) communicated with the command in the Submit Queue Entry (SQE). As another example, vendor specific technology may be used to communicate information 961.

In some embodiments, reclamation unit logic 965 in storage device 904 may include usage logic 965-3 that may implement and information 961 may be used to form and/or select one or more reclamation units 914. Mode-related device-side functions. For example, if information 961 indicates that data may be frequently written, read, re-read, and/or rewritten (e.g., is hot data), then use logic 965-3 may enable storage 904 to select and/or Compose a recycling unit with storage media that may have a relatively large number of P/E cycles remaining in its expected life. Additionally, if information 961 indicates that the data is unlikely to be written, read, re-read and/or re-written quickly or frequently (e.g., is cold data), then using logic 965-3 may cause the storage Apparatus 904 can select and/or compose a recycling unit with storage media that may have a relatively small number of P/E cycles remaining in its expected life.

As another example, if information 961 indicates that the data has a relatively high error tolerance, for example, because the data may be stored in the storage device as part of a redundant storage scheme, the storage device may be selected and/or composed with a storage medium. Recycling unit, the storage medium may have a relatively small number of P/E cycles remaining over its expected life (eg, the storage medium may have a relatively high wear leveling). For example, if the data is stored in a redundant array of independent drives (RAID) and/or a redundancy scheme with a relatively large number of mirrors (e.g., three mirrors instead of two), this may indicate that the host can provide a relatively high protection rate (eg, a relatively high data loss rate may be acceptable), and the data may be stored using a storage medium that may have a relatively small number of valid estimated P/E cycles remaining over its expected life. As another example, if the host does not allow the data to remain in storage for a long time (e.g., for a minimal amount of BER accumulation), the data may be stored using a storage medium that may have remaining time in its expected life. Relatively large number of effectively estimated P/E cycles.

As another example, usage logic 965-3 may identify and/or use one or more properties of one or more portions of storage medium 913 to compare with tolerance of a relatively large number of P/E cycles and/or accumulations based on the properties. The correlation of a small number of bit errors improves the ability to compose and/or select one or more recovery units 914 . For example, one or more erase blocks may be selected for a reclamation unit, and/or may be selected based on having one or more attributes, such as wafer production attributes (e.g., location of the die on the wafer), storage media on the die, erase block locations, voltage and/or speed characteristics of read, write (programming) and/or erase operations, bit error rate accumulation of the storage medium, current and/or historical temperature exposure of the storage medium, the storage medium and /or select a recycling unit adjacent to the storage medium in terms of access activity (eg, read, write (programming) and/or erase operations), etc.) of the medium.

In some embodiments, the manner in which information 961 may be used to compose and/or select one or more recycling units 914 may be based on one or more differentiation methods (such as binary thresholding, binning, simulation thresholding, etc.) . For example, in the case of a binary threshold, an erase block may be considered to have a high BER if the BER is above the threshold, and an erase block may be considered to have a low BER if the BER is below the threshold. However, in the case of binning techniques, erase blocks may be divided into multiple bins based on two or more thresholds (eg, behavioral expectations). For example, four different thresholds may be used to separate erase blocks into five different bins, each of which may be used to constitute a reclamation unit of data with a different tolerance level of bit errors. As another example, data that has been garbage collected once may be indicated as belonging to a first bin of cold data, while data that has been garbage collected twice may be indicated as belonging to a second bin of even colder data.

In some embodiments with analog or proportional derivative schemes, erase blocks may be characterized as having specific values for characteristics, attributes, etc. For example, floating point or numeric quantities, which may use relatively high quantized numerical mathematics, may be used to characterize the speed and/or voltage of program, read, and/or erase operations of an erase block, and floating point or numeric quantities may be used based on The information 961 provided to the storage device 904 is used to select the erase block for the reclaim unit 914 .

In some embodiments, placement logic 963 of host 902 may include determination logic 963 - 4 , which may implement host-side functionality related to the manner in which host 902 may determine information 961 to send to storage device 904 . Determination logic 963-4 may enable the host 902 to identify, collect, process, etc. information 961 to be sent to the storage device. For example, the host may observe that data written by a user (e.g., operating system 972, application 974, file system 976, etc.) may be or may be continuously used and/or have been stored, possibly for a relatively long time, And this information can be sent to the storage device, for example, together with the write request. Additionally or alternatively, determination logic 963-4 may convert this type of information to another type of information that may be acted upon more directly by storage device 904. For example, if the determination logic 963-4 determines that data written by the user has been stored, or is likely to be stored for a relatively long time, the determination logic 963-4 may send information 961 indicating that the data is relatively cold data.

As another example, determination logic 963-4 may observe that data written by the user may or may be compressed (e.g., garbage collected) at the file system level, database level, etc., and combine this information with the writing of the data The request is sent to the storage device. For example, determination logic 963-4 may characterize user data that may or may be compressed into relatively hot data. As another example, the host may determine the number of times the data has been compressed (eg, garbage collected) and send this information to the storage device along with the data to be stored at the device. Depending on the implementation details, multiple compression operations on the same data can increase the correlation between the data and the likelihood that the data will be accessed frequently.

As another example, determination logic 963-4 may characterize data usage based on one or more data management schemes (such as one or more cache replacement policies, tiered storage schemes, multi-tier storage architectures, etc.) and assign the The information is sent to the storage device along with the data to be stored at the device. For example, where data is stored as part of a cache replacement policy, the cache level in which the data is stored may indicate the relative likelihood that the data will be accessed frequently (e.g., data stored at the L1 cache level may be more likely to be accessed frequently than data stored at the Data at the L3 cache level is accessed more frequently). Similarly, data stored at higher levels of a tiered storage scheme may be accessed more frequently than data stored at lower levels of a tiered storage scheme. Accordingly, determination logic 963-4 may report such usage information directly to storage device 904 as information 961, and/or convert such usage into information 961 indicating that the data is relatively hot or cold.

In some embodiments, the reclamation unit logic 965 may be based on a combination of information 961 received from outside the storage device 904 and information obtained locally at the storage device 904 (which may be referred to as local information and/or locally derived information) to form and/or select one or more recycling units 914. For example, reclamation unit logic 965 may collect one or more statistical information regarding data stored at storage device 904 . Examples of statistical information may include write counts and/or frequencies, rewrite counts and/or frequencies, read counts and/or frequencies, and the like. In some embodiments, such statistics may be thresholds and/or ranges mapped to different reclamation groups, reclamation units, etc. in storage medium 913 . Such statistics may be combined with received information 961 to compose and/or select one or more reclamation units 914 (eg, reclamation unit handle to reclamation unit classification and/or mapping). For example, host 902 may provide mirrored and/or non-mirrored bit error classification in information 961 . Reclamation unit logic 965 may combine this classification with one or more locally derived statistics to compose and/or select one or more reclamation units 914 for data operation requests (eg, write commands 930).

10 illustrates an example of an initial isolation scheme for a flexible data placement scheme for a storage device in accordance with disclosed example embodiments. The embodiment shown in Figure 10 may include three reclamation unit handles 1036 identified as RUH X, RUH Y, and RUH Z.

The reclamation unit handle RUH X may currently refer to the reclamation unit 1014 identified as RU A. Recycling unit RU A may be partially filled with data as shown by the single diagonal shading with a line extending from upper right to lower left. Reclamation unit handle RUH X may have previously referenced reclamation units 1014' identified as RU A'_0, RU A'_1 and RU A'_2. For example, RU A'_0, RU A'_1, and RU A'_2 are identified as being filled with Similar to the manner in which RU 4 of data is referenced by RUH Although not currently referenced by RUH

The reclamation unit handle RUH Y may currently refer to the reclamation unit 1014 identified as RU B. Recycle unit RU_B may be partially filled with data as shown by the diagonal cross-hatching. Reclamation unit handle RUH Y may have previously referenced reclamation units 1014' identified as RUB'_0, RU B'_1, and RU B'_2. For example, when RU B'_0, RU B'_1, and RU B'_2 are referenced by RUH Y, the previously referenced reclamation unit 1014' may already be filled with data (as shown by the diagonal cross-hatching).

Likewise, reclamation unit handle RUH Z may currently reference reclamation unit 1014 identified as RU C. The recycling unit RU C may be partially filled with data as shown by the single diagonal shading with a line extending from upper left to lower right. Reclamation unit handle RUH Z may have previously referenced reclamation units 1014' identified as RU C'_0, RU C'_1, and RU C'_2. For example, when RU C'_0, RU C'_1, and RU C'_2 are referenced by RUH Z, the previously referenced reclaim unit 1014' may have been populated with data (such as a single diagonal with a line extending from upper left to lower right Shown by line shading).

In some embodiments, a controller within the storage device may perform one or more operations (eg, maintenance operations) on data stored in the previously referenced reclamation unit 1014'. For example, some or all of the data stored in the previously referenced reclamation unit 1014' may be deallocated (eg, by the host), resulting in unused storage capacity in the previously referenced reclamation unit 1014'. This is illustrated in Figure 10, where the portion of a previously referenced reclaim unit 1014' containing deallocated (eg, invalidated) data is shown using shading with relatively thin lines.

In some embodiments, the controller may perform one or more maintenance operations to enable unused storage capacity in previously referenced reclamation units 1014' 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 deallocated) in one or more of the previously referenced collection units 1014' may be copied to a different collection unit such that the previously referenced One or more of the recycling units 1014' may be erased and reused.

The embodiment shown in FIG. 10 may implement an initial isolation scheme in which data written to reclamation units that are currently or previously referenced by different reclamation unit handles 1036 may be initially isolated from each other. In some embodiments, data may be considered isolated if the reclamation unit in which the data is stored only includes data written to the reclamation unit using the same reclamation unit handle. Therefore, the reclaim units RU A, RU A'_0, RU A'_1, and RU A'_2 may only include data written when these reclaim units are referenced by RUH X. Similarly, the reclamation units RU B, RU B'_0, RU B'_1, and RU B'_2 may only include data written when these reclamation units are referenced by RUH Y, and the reclamation units RU C, RU C'_0, RU C'_1 and RU C'_2 may only include data written when these reclaim units are referenced by RUH Z.

However, as part of controller operation, data from reclamation units written using different reclamation unit handles may be combined in a single reclamation unit. This is illustrated in Figure 10, where the controller may read valid data from previously referenced reclamation units RUA'_0, RU B'_0, and RU C'_0 and write them to reclamation unit 1082 identified as RUα. Because the valid data copied from the previously referenced reclamation units RU A'_0, RU B'_0, and RU C'_0 may be the last remaining valid data in one or more of these reclamation units, reclamation unit RU A'_0 One or more of , RU B'_0 and/or RU C'_0 may be erased (eg, as part of a garbage collection operation) to be reused to store other data. Reclamation units that have been erased (eg, garbage collected) may be removed from the reclamation unit association table in which they may have been listed.

In some embodiments, because data written using different reclamation unit handles 1036 may be initially isolated in different reclamation units, the isolation scheme shown in Figure 10 may be referred to as an initial isolation scheme, but may eventually For example, combined by subsequent operations such as garbage collection operations, media management operations (eg, refresh programming, read disturb), etc. In some embodiments, the isolation scheme shown in Figure 10 may be referred to as a host isolation scheme because the host can determine (eg, using a reclamation unit handle) the placement of data in an isolated reclamation unit.

Table 1

Although one recycling group 1018 is shown in Figure 10, recycling units 1014 may be arranged in any number of recycling groups. In some embodiments, data from reclamation units in different reclamation groups (eg, valid data from previously referenced reclamation units in different reclamation groups) may be combined in the same reclamation unit.

11 illustrates an embodiment of a persistence isolation scheme for a flexible data placement scheme for a storage device, in accordance with disclosed example embodiments. The embodiment shown in Figure 11 may include three reclaim unit handles 1136 identified as RUH X, RUH Y, and RUH Z, which may be used to write data to the current Referenced reclamation unit 1114 and/or previously referenced reclamation unit 1114'.

However, the isolation scheme shown in Figure 11 may involve more isolation of data written using different reclamation unit handles than the embodiment described above with respect to Figure 10. For example, in the embodiment shown in Figure 11, in controller operations that may move data from a previously referenced reclamation unit 1114', data written using different reclamation unit handles may not be combined in a single reclamation unit. This is illustrated in Figure 11, where the controller may retrieve data from (eg, only from) previously referenced reclamation units RU A'_0, RU A'_1 and/or RU A'_2 that were written using the same reclamation unit handle RUH Valid data is read and written into the recycling unit 1182 identified as RUα. However, in some embodiments, reclamation unit RUα may not receive data from reclamation units written using other reclamation handles, such as RUH Y and/or RUH Z.

Similarly, the controller may read valid data from (eg, only from) previously referenced reclamation units RU B'_0, RU B'_1, and/or RU B'_2 that were written using the same reclamation unit handle RUH Y, and Valid data is written to the recycling unit 1182 identified as RUβ. The controller may also read valid data from (e.g., only from) previously referenced reclamation units RU C'_0, RU C'_1 and/or RU C'_2 that were written using the same reclamation unit handle RUH Z and will be valid Data is written to the recycling unit 1182 identified as RUγ. Thus, in some embodiments, data written to one or more reclamation units 1182 may be read (eg, only read) from one or more reclamation units written using the same reclamation unit handle.

If the valid data read from any previously referenced reclamation unit 1114' is the last remaining valid data in the reclamation unit, the reclamation unit may be erased (eg, as part of a garbage collection operation) to be reused to store other data.

In some embodiments, because isolation between data written using different collection unit handles may continue beyond write and/or deallocation operations (e.g., including one or more garbage collections and/or other controller operations), So the isolation scheme shown in Figure 11 can be called a persistent isolation scheme. In some embodiments, because isolation between data written using different reclamation unit handles may continue throughout the life of the data in the storage device, the isolation scheme illustrated in Figure 11 may be referred to as full or All isolation plans.

Although one recycling group 1118 may be shown in FIG. 11 , recycling units 1114 may be arranged in any number of recycling groups. In some embodiments, data from reclamation units in different reclamation groups (eg, valid data from previously referenced reclamation units in different reclamation groups) may be combined in the same reclamation unit.

Any storage devices, storage media, etc. disclosed herein may be implemented using any type of non-volatile storage media based on solid state media, magnetic media, optical media, etc. For example, in some embodiments, the computational storage device may be implemented as a NAND flash based SSD, a persistent memory such as a cross-grid non-volatile memory, a memory with volume resistance variation, a phase change memory ( PCM), etc., or any combination thereof.

Any storage device disclosed herein may use any connector configuration (such as Serial Advanced Technology Attachment (ATA) (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), U.2, etc.) 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.

Any storage devices disclosed herein may be implemented in whole or in part using server chassis, server racks, data rooms, data centers, edge data centers, mobile edge data centers, and/or any combination thereof and/or with Server chassis, server racks, datarooms, data centers, edge data centers, mobile edge data centers and/or any combination thereof.

Any host disclosed herein may use any component (such as a compute server, storage server, network server, cloud server, etc., a node (such as a storage node), a computer (such as a workstation, personal computer, tablet), smartphone, etc. or a plurality and/or combination thereof) or a combination of components.

Any communication connections and/or communication interfaces disclosed herein may use any type of interface and/or protocol using one or more interconnections, one or more networks, a network of networks (e.g., the Internet), etc., or they combination to achieve. Examples may include Peripheral Component Interconnect Express (PCIe), NVMe, NVMe over Fabric (NVMe-oF), Ethernet, Transmission Control Protocol/Internet Protocol (TCP/IP), Direct Memory Access (DMA), Remote DMA (RDMA ), RDMA over Converged Ethernet (ROCE), Fiber Channel, Infinite Bandwidth, Serial ATA (SATA), Small Computer System Interface (SCSI), Serial Attached SCSI (SAS), iWARP, Compute Express Link (CXL) ) and/or coherence protocols (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 Wireless Fidelity (Wi-Fi), Bluetooth, NFC ), etc., or any combination thereof.

Any functionality described herein including host functionality, storage functionality, etc. (e.g., any storage controller, logic, etc.) may be implemented using hardware, software, firmware, or any combination thereof, including, for example, a combination of hardware and/or software 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 Volatile memory), memory with volume resistance changes, PCM, etc. and/or any combination thereof, complex programmable logic device (CPLD) field programmable gate array (FPGA), application specific circuit (ASIC), central processing unit (CPU) ) (including complex instruction set computer (CISC) processors (such as x86 processors) and/or reduced instruction set computer (RISC) processors (such as ARM processors)), graphics processing units (GPUs), neural processors (NPU), Tensor Processing Unit (TPU), etc., execute instructions stored in any type of memory. In some embodiments, one or more components may be implemented as a system on a chip (SOC).

In embodiments that are implemented at least in part using a storage device with a Flash Translation Layer (FTL), any functionality described herein (eg, any storage device controller, logic, etc.) may be implemented at least in part using the FTL.

In some embodiments, a reclaimed unit may include a physical non-volatile storage device that may be reclaimed (eg, erased, reused, repurposed, etc.) as a unit. Depending on the implementation details, the recycling unit can be recycled without disturbing one or more other recycling units. In some embodiments, the reclamation unit may be implemented as a physical construct only (eg, may be independent of a logical address or logical block address (LBA)).

In some embodiments, a namespace may include capacity allocated in one or more reclamation units, for example. A reclamation group may include one or more reclamation units, and one or more put handles may reference one or more reclamation units (eg, may be targeted by one or more I/O commands). In some embodiments, I/O commands executed on one reclamation group may not interfere with the performance, reliability, etc., of commands executed on another reclamation group.

In some embodiments, a placement identifier may specify a reclamation group paired with a placement handle, reclamation unit handle, etc. The placement identifier may reference, for example, a reclamation unit that may be used to write a random LBA (eg, write user data to a non-volatile storage device assigned to the reclamation unit). The write capacity of a reclaim unit referenced by a put identifier may be incremented (e.g., on each write command) in relation to one or more write commands specifying the put identifier, put handle, reclaim unit handle, etc., Once the capacity of a reclamation unit is partially or fully written, these write commands may in turn be modified to reference another reclamation unit.

In some embodiments, the host may track user data written to one or more reclamation units (eg, one or more LBAs of user data). Depending on the implementation details, this may enable the host to deallocate some or all user data (eg, all LBAs) associated with a particular reclaim unit together (eg, 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 may be responsible for managing placement identifiers, placement handles, reclaim unit handles, and/or other related device resources.

In some embodiments, the reclamation unit handle may include a reference to a reclamation unit (eg, within each reclamation group) in which user data for the write command may be placed. In some embodiments, a reclamation unit referenced by a reclamation unit handle may only be allowed to be referenced by at most one reclamation unit handle. However, in some embodiments, when a reclamation unit is cycled from erasure and returned to use, a specific reclamation unit may be referenced by the same or a different reclamation unit handle. When a reclamation unit is written to capacity, the controller may update the associated reclamation unit handle to reference a different reclamation unit that may be used to write user data (e.g., a non-volatile storage medium that may have been erased prior to writing ) and little or no user data has been written (for example, an empty recycling unit).

As described above, storage devices according to disclosed example embodiments may perform data operations based on requests other than write commands. For example, in some embodiments, a storage device may receive a request for an update operation (e.g., as described with respect to FIGS. 3A-3D) and an indication of data locality (such as one or more reclaim unit handles to be updated). ). In some such embodiments, the storage device may use information about data to be stored in one or more reclamation units referenced by one or more updated reclamation unit handles to compose and/or select one or more Recycling unit to use for the updated recycling unit handle. For example, the storage device may receive an update request from the host along with a reclaim unit handle to be updated. The host may also send information indicating that the data to be stored in the reclamation unit referenced by the reclamation unit handle may be relatively hot data. Accordingly, the storage device may compose and/or select a reclamation unit with a relatively large number of remaining P/E cycles based on information received from the host and update the reclamation unit handle to point to the composed and/or selected reclamation unit. In some such embodiments, the storage device may maintain a data isolation scheme (eg, an initial isolation scheme and/or a persistence isolation scheme as described herein).

12 illustrates an example embodiment of a host device that may be used to implement any of the host functions disclosed herein, in accordance with the disclosed example embodiments. The host device (or host) 1200 shown in Figure 12 may include a processor 1202, which may include a memory controller 1204, system memory 1206, and host control logic 1208 (the host control logic 1208 may be used to implement, for example, Figure 9 Placement logic 963) and/or communication interface 1210 are shown. Any or all components shown in Figure 12 may communicate via one or more system buses 1212. In some embodiments, one or more of the components shown in Figure 12 may be implemented using other components. For example, in some embodiments, host control logic 1208 may be implemented by processor 1202 executing instructions stored in system memory 1206 or other memory.

13 illustrates an example embodiment of a storage device that may be used to implement any of the storage device functions disclosed herein, in accordance with the disclosed example embodiments. Storage device 1300 may include a device controller 1302 (device controller 1302 may be used to implement, for example, reclaim unit logic 965 shown in Figure 9), a media translation layer 1304 (eg, FTL), a storage medium 1306, and/or a communication interface 1310 . The components shown in Figure 13 may communicate via one or more device buses 1312. In some embodiments where flash memory may be used for some or all of storage medium 1306, media translation layer 1304 may be implemented partially or completely as a flash translation layer (FTL).

14 illustrates an embodiment of a method for flexible data placement of a storage device in accordance with disclosed example embodiments. The method may begin at operation 1402.

At operation 1404, the method may receive a data operation request at the storage device, wherein the data operation request specifies data and a reclaim unit handle. For example, data operation requests may include requests for write operations, copy operations, deallocation operations, clean operations, erase operations, format operations, compare and write operations, and the like. In some example embodiments, the data operation request may include a write command (such as write commands 330, 530, and/or 930 shown in FIGS. 3A-3D, 5, and/or 9).

At operation 1406, the method may receive information about the data at the storage device. The information about the data may include access information, information about one or more acceptable characteristics of the storage medium used to implement the recycling unit of the data, information about one or more attributes of the data to be stored in the device, information about One or more of the type and/or usage information of the data to be stored. In some example embodiments, information regarding data (eg, information 861 and/or 961) may be received by storage devices 804 and/or 904 as shown in Figures 8 and/or 9.

At operation 1408, the method may perform a data operation associated with a reclamation unit of at least one storage medium of the storage device based on the data operation request, the reclamation unit handle, and the information. For example, as shown in Figure 8, information 861 may indicate that the data to be stored may be relatively cold data, which may be stored in a reclaim unit that includes an erase block with a relatively high P/E cycle count. . The method may end at operation 1410.

The embodiment illustrated in Figure 14, 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. Furthermore, in some embodiments, the temporal order and/or spatial order of operations and/or components may be changed. 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 as shown Some components and/or operations that are single components and/or operations may be implemented using multiple components and/or operations.

Some of the embodiments disclosed above have been described in the context of various implementation details, but the principles of the disclosure are not limited to these or any other specific details. For example, some functionality has been described as being implemented by specific components, but in other embodiments, the functionality may be distributed among different systems and components in different locations and with various user interfaces. Particular embodiments have been described as having particular processes, operations, etc., but these terms also include embodiments in which a particular process, operation, etc. may be implemented as multiple processes, operations, etc., or multiple processes, operations, etc. may be integrated into Embodiments in a single process, operation, etc. A reference to a component or element may refer to only a portion of the component or element. For example, a reference to a block may represent the entire block or one or more subblocks. A reference to a component or element may refer to one or more of the 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 represent one or more resources, and a reference to a resource may represent a single resource. Unless otherwise clear from the context, terms such as "first" and "second" may be used in this disclosure and the claims solely for the purpose of distinguishing the elements they modify and may not indicate any spatial order or time. order. In some embodiments, a reference to an element may mean at least a portion of the element, for example, "based on" may mean "based at least in part on," etc. A reference to a first element does not imply the presence of the second element. The principles disclosed herein have independent applicability and may be embodied individually, and not every embodiment may utilize every principle. However, these principles can also be embodied in various combinations, some of which can amplify the benefits of the individual principles in a synergistic manner. The various details and embodiments described above may be combined to create additional embodiments in accordance with the inventive principles disclosed in this patent.

Since the inventive principles disclosed in this patent may be modified in arrangement and detail without departing from the inventive concept, such changes and modifications are deemed to be within the scope of the appended claims.

Claims (20)

1. A storage device, comprising: at least one storage medium; and Controller, configured as: Receive a write command, where the write command specifies data and a recycling unit handle; receive information about the data; and Based on the reclamation unit handle and the information, data is stored in the reclamation unit of the at least one storage medium. 2. The storage device of claim 1, wherein the information includes access information. 3. The memory device of claim 1, wherein the information includes error tolerance information. 4. The storage device of claim 1, wherein the information includes data attribute information. 5. The storage device of claim 1, wherein the information includes data type information. 6. The storage device of claim 1, wherein the controller is configured to determine the information based at least in part on a reclaim unit handle. 7. The storage device of claim 1, wherein the controller is configured to: Receive an indicator separate from the recycling unit handle; and The information is determined based at least in part on the indicator. 8. The storage device of claim 1, wherein the controller is configured to select a recycling unit based on the information. 9. The storage device of claim 8, wherein the controller is configured to select the recycling unit based on characteristics of at least a portion of the recycling unit. 10. The memory device of claim 9, wherein the characteristic includes a number of programming cycles. 11. The memory device of claim 9, wherein the characteristics include error accumulation characteristics. 12. The storage device of claim 1, wherein the controller is configured to form a recycling unit based on the information. 13. The storage device of claim 12, wherein the controller is configured to form the recycling units based on characteristics of at least a portion of the recycling units. 14. The memory device of claim 13, wherein the characteristic includes a number of programming cycles. 15. The memory device of claim 13, wherein the characteristics include error accumulation characteristics. 16. An apparatus for forming and selecting recycling units, comprising: Placement logic, configured as: sending a write command to the storage device, wherein the write command specifies data and a reclamation unit handle, wherein the reclamation unit handle is used to reference a reclamation unit in at least one storage medium of the storage device; and Send information about the data to storage. 17. The apparatus of claim 16, wherein the information includes access information. 18. A method of forming and selecting recycling units, comprising: receiving a data operation request at the storage device, wherein the data operation request specifies data and a reclaim unit handle; receiving information about the data at the storage device; and A data operation associated with a reclamation unit of at least one storage medium of the storage device is performed based on the data operation request, the reclamation unit handle, and the information. 19. The method of claim 18, wherein the data operation request includes a write operation request, and the data operation includes a write operation. 20. The method of claim 19, wherein the write operation request includes a write command, and the write operation includes storing data in the reclamation unit based on the reclamation unit handle and the information.