System and method for extending command orchestration through address mapping

Abstract

Embodiments of the invention generally relate to systems and methods for extending command orchestration through address mapping. An apparatus for processing commands to manage non-volatile memory includes a controller configured to obtain address information from a command, read an entry of a metadata table based on the address information, and determine whether a metadata page corresponding to the address information is being processed by the controller based on the entry of the metadata table. In response to determining that the metadata page corresponding to the address information is being processed, the controller determines a processing state of the metadata page among a plurality of processing states based on the entry of the metadata table and processes the command according to the processing state of the first metadata page. In response to determining that the metadata page corresponding to first address information is not being processed, the controller reads the metadata page from the non-volatile memory based on the entry of the metadata table.

Description

Technical Field

[0001] The present invention generally relates to systems and methods for operating a data storage device by processing commands to manage non-volatile memory, and more particularly, to systems and methods for processing commands to manage non-volatile memory using address mappings arranged with extended commands. Background Technology

[0002] Storage devices can read blocks of data from non-volatile memory via logical-to-physical address mapping. After receiving multiple commands requesting the reading of data blocks, the storage device can execute command orchestration to issue multiple reads sequentially. Given the limited capacity of volatile memory and the limited processing power of storage devices, improvements in efficient and scalable command orchestration are still desired. Summary of the Invention

[0003] Embodiments of the present invention relate to a system and method for processing commands to manage nonvolatile memory using address mapping with extended command orchestration.

[0004] According to some aspects, embodiments provide an apparatus for processing commands to manage non-volatile memory. The apparatus may include a controller and volatile memory. The controller may be configured to obtain first address information from a first command. The controller may be configured to read a first entry of a metadata table based on the first address information. The controller may be configured to determine, based on the first entry of the metadata table, whether a first metadata page corresponding to the first address information is being processed by the controller. The controller may be configured to, in response to determining that the first metadata page corresponding to the first address information is being processed, determine a first processing state of the first metadata page among a plurality of processing states based on the first entry of the metadata table and process the first command according to the first processing state of the first metadata page. The controller may be configured to, in response to determining that the first metadata page corresponding to the first address information is not being processed, read the first metadata page from the non-volatile memory based on the first entry of the metadata table.

[0005] According to other aspects, embodiments provide a method for processing commands to manage non-volatile memory. The method may include obtaining first address information from a first command by a processor. The method may include reading a first entry of a metadata table by the processor based on the first address information. The method may include determining, based on the first entry of the metadata table, whether a first metadata page corresponding to the first address information is being processed by the controller. The method may include, in response to determining that the first metadata page corresponding to the first address information is being processed, determining a first processing state of the first metadata page among a plurality of processing states by the processor based on the first entry of the metadata table and processing the first command according to the first processing state of the first metadata page. The method may include, in response to determining that the first metadata page corresponding to the first address information is not being processed, reading the first metadata page from the non-volatile memory by the processor based on the first entry of the metadata table. Attached Figure Description

[0006] These and other aspects and features of the embodiments of the present invention will become apparent to those skilled in the art upon review of the following description of specific embodiments in conjunction with the accompanying drawings, wherein:

[0007] Figure 1 This is a block diagram illustrating an example computer system according to some embodiments;

[0008] Figure 2 This is a block diagram illustrating an example command orchestration system using address mapping according to some embodiments;

[0009] Figure 3A and Figure 3B This describes an example process of using address mapping to execute command orchestration according to some embodiments;

[0010] Figure 4 This is a block diagram illustrating an example of an address mapping for command orchestration according to some embodiments; and

[0011] Figure 5 This is a flowchart illustrating an example method for executing command orchestration using address mapping, according to some embodiments. Detailed Implementation

[0012] According to some aspects, embodiments of this disclosure relate to techniques for processing commands to manage non-volatile memory using address mappings orchestrated by extended commands.

[0013] For high-performance systems, avoiding performance bottlenecks is crucial. Parallel operations can lead to unexpected race conditions, which often become bottlenecks or vulnerabilities. In paging FTL (Flash Translation Layer), multiple read or write requests can cause pages to need to be loaded, leading to problems with extended command orchestration or sorting. For example, both read and write operations may require loading the same metadata page (or MDPage) containing mapping information. One solution to this problem is to maintain a sorted list of pages loaded during retrieval to determine which pages are being loaded or processed. For example, red-black trees can be used to maintain a searchable sorted list with computational complexity of O(log₂ N), where N is the number of nodes (or pages) in the tree. However, this solution leads to high design complexity and the expectation of improved performance and scalability. For paging systems, there is a general scalability problem in tracking the state of valid pages. These valid pages may have many different states (beyond loading), requiring the tracking that this invention addresses.

[0014] To address this problem, according to certain aspects, embodiments of this disclosure relate to techniques for using address mapping to track valid operations and perform command orchestration accordingly. In some embodiments, the command orchestration system (e.g., FTL) may utilize a large mapping (e.g., a metadata mapping) in memory. Instead of storing values ​​indicating the location of a page (e.g., a metadata page) in non-volatile memory (e.g., flash memory) in the metadata mapping, the command orchestration system may replace said values ​​with specific setting values ​​indicating that the page is in the loading process.

[0015] In some embodiments, a metadata map (MDMap) may be an in-memory table used to track the location of a given (metadata) page in non-volatile memory. In some embodiments, the metadata map may contain mapping information between addresses (e.g., logical addresses) provided for data and addresses (e.g., "physical addresses") in physical memory where the data or metadata pages of data are stored. In some embodiments, the metadata map may have multiple entries, each containing the address of a metadata page (MDPage) that contains mapping information (metadata) for a given metadata page number. In some embodiments, a portion of the address space defined by the metadata map may not be used for addresses in non-volatile memory, and this unused portion of the address space may be allocated to orchestration management use. In some embodiments, when a metadata page is being fetched, the command orchestration system may use address redirection by using the address value corresponding to an execution tag (ExecTag) used to issue and track the read process, instead of using the address of the metadata page. In some embodiments, the execution tag may be associated with an address in an unused portion of the address space defined by the metadata map.

[0016] In some embodiments, the execution tag may have a linked list of requests for reading undetermined metadata pages. For example, when a new request arrives, a conventional FTL may attempt to look up a flash address in the metadata map to issue a read of the corresponding (metadata) page. A command orchestration system according to some embodiments may instead perform the lookup to find a value indicating that a read of a metadata page is in progress and may instead add the request to the appropriate linked list. In some embodiments, after a metadata read operation (MDRead) is completed, the command orchestration system may serve queued requests that can be served based on the linked list.

[0017] In some embodiments, the command orchestration system may apply this modified address mapping technique to different stages of the command orchestration process, such as on-chip cache / buffer or trimming states. In some embodiments, this modified address mapping technique may be used to manage background trimming operations. For example, when a metadata page undergoes a background trimming operation, the command orchestration system may use address redirection by using the address value corresponding to a trim tag used to track the trimming process instead of the address of the metadata page. In some embodiments, the command orchestration system may process pages in at least two metadata packet units to which commands are grouped. For example, when processing a metadata page in a metadata packet unit, the command orchestration system may use address redirection by using the address value corresponding to a pack tag used to track the metadata packing process.

[0018] In some embodiments, the command orchestration system can dispose of pages stored in a memory cache (e.g., DRAM). For example, when a metadata page is stored in the cache, the command orchestration system can use address redirection by using an address value corresponding to a read cache tag (RdCacheTag), which indicates the location of the metadata page in DRAM, (e.g., as a fully associative caching mechanism). Similarly, when a metadata page stored in the cache has been modified but not written to non-volatile memory (e.g., the page is dirty), the command orchestration system can use address redirection by using an address value corresponding to a write cache tag (WrCacheTag), which indicates the location of additional information about the dirty metadata page in DRAM. In some embodiments, execution tags, trim tags, wrap tags, read cache tags, and write cache tags can be defined as corresponding unused portions of the address space defined by the metadata map.

[0019] According to some aspects, embodiments of this disclosure relate to an apparatus for processing commands to manage non-volatile memory. The apparatus may include a controller and volatile memory. The controller may be configured to obtain first address information from a first command. The controller may be configured to read a first entry of a metadata table based on the first address information. The controller may be configured to determine, based on the first entry of the metadata table, whether a first metadata page corresponding to the first address information is being processed by the controller. The controller may be configured to, in response to determining that the first metadata page corresponding to the first address information is being processed, determine a first processing state of the first metadata page among a plurality of processing states based on the first entry of the metadata table and process the first command according to the first processing state of the first metadata page. The controller may be configured to, in response to determining that the first metadata page corresponding to the first address information is not being processed, read the first metadata page from the non-volatile memory based on the first entry of the metadata table.

[0020] According to some aspects, embodiments of this disclosure relate to a method for processing commands to manage non-volatile memory. The method may include obtaining first address information from a first command by a processor. The method may include reading a first entry of a metadata table by the processor based on the first address information. The method may include determining, based on the first entry of the metadata table, whether a first metadata page corresponding to the first address information is being processed by the controller. The method may include, in response to determining that the first metadata page corresponding to the first address information is being processed, determining a first processing state of the first metadata page among a plurality of processing states by the processor based on the first entry of the metadata table and processing the first command according to the first processing state of the first metadata page. The method may include, in response to determining that the first metadata page corresponding to the first address information is not being processed, reading the first metadata page from the non-volatile memory by the processor based on the first entry of the metadata table.

[0021] The embodiments in this disclosure have at least the following advantages and benefits.

[0022] The embodiments in this disclosure provide useful techniques for improving command orchestration using modified address mapping. By employing modified address mapping techniques that replace flash memory addresses with values ​​(tags) corresponding to processing states, command orchestration systems according to some embodiments can determine which pages are in a loading process (or other process) with computational complexity O(1). This command orchestration method also achieves better scalability and lower design complexity than conventional techniques (e.g., techniques using red-black trees). Furthermore, by adding cache tags to the mapped address space, command orchestration systems according to some embodiments can achieve higher performance and scalability through fully associative caching instead of n-way caching. The command orchestration system can also use replacement values ​​as needed to reference lists and other data to efficiently track operations associated with target metadata pages. These improvements provide additional benefits and simplification to key-value stores with significantly larger metadata volumes than typical namesspace / logical addressing systems.

[0023] Figure 1 This is a block diagram illustrating an example computer system according to some embodiments.

[0024] refer to Figure 1 The computer system 1000 may include a host 10 and a solid-state drive (SSD) 100, which is a storage device and can be used as the main storage device of an information processing device (such as the host 10). The SSD 100 may be integrated into the information processing device or may be connected to the information processing device via a cable or network.

[0025] Host 10 may be an information processing device (computing device) that accesses SSD 100. Host 10 may be a server (storage server) that stores large amounts of various data in SSD 100, or it may be a personal computer. Host includes a file system 15 for controlling file operations (such as creation, saving, updating, or deletion). For example, ZFS, Btrfs, XFS, ext4, or NTFS may be used as file system 15. Alternatively, a file object system (such as Ceph object storage process) or a key-value store system (such as RocksDB) may be used as file system 15.

[0026] SSD 100 includes, for example, a controller 120 and flash memory 180 as non-volatile memory (e.g., NAND flash memory). SSD 100 may include random access memory as volatile memory, such as DRAM (Dynamic Random Access Memory) 110. In some embodiments, controller 120 may include random access memory, such as SRAM (Static Random Access Memory). The random access memory (e.g., DRAM 110) has, for example, a read buffer as a buffer for temporarily storing data read from flash memory 180, a write buffer as a buffer for temporarily storing data written to flash memory 180, and a buffer for discarded item collection. In some embodiments, controller 120 may include DRAM 110.

[0027] In some embodiments, flash memory 180 may include an array of memory cells comprising a plurality of flash memory blocks (e.g., NAND blocks) 182-1 to 182-m. Each of blocks 182-1 to 182-m may be used as an erase unit. Each of blocks 182-1 to 182-m contains a plurality of physical pages. In some embodiments, in flash memory 180, data reading and data writing are performed on a page-by-page basis, and data erasure is performed on a block-by-block basis.

[0028] In some embodiments, controller 120 may be a memory controller configured to control flash memory 180. Controller 120 includes, for example, a processor (e.g., CPU) 150, a flash memory interface 140 and a DRAM interface 130, and a host interface 190, all of which are interconnected via bus 128. DRAM interface 130 may be used as a DRAM controller configured to control access to DRAM 110. Flash memory interface 140 may be used as flash memory control circuitry (e.g., NAND control circuitry) configured to control flash memory 180 (e.g., NAND flash memory).

[0029] Host interface 190 can be used as circuitry to receive various requests from host 15 and transmit responses to those requests to host 10. Requests may include various commands, such as I / O commands and control commands. I / O commands may include, for example, write commands, read commands, trim commands (unmapping commands), format commands, and refresh commands. Write commands are also called program commands. Format commands may be commands used to unmapping the entire memory system (SSD 100).

[0030] Processor 150 can be configured to control flash interface 140 and DRAM interface 130. Processor 150 can be configured to perform various processes by executing control programs (e.g., firmware) stored in (e.g., ROM, not shown). In some embodiments, processor 150 can execute command control 160 to perform command processing for processing various commands received from an information processing device (e.g., a host computer). Processor 150 can be configured to act as a flash translation layer (FTL) 170 to perform data management and block management of flash memory 180. FTL 170 may include lookup table control 172, discard item collection control 174, wear leveling control 176, and flash control 178. Data management may include the management of mapping information indicating the correspondence between logical addresses (e.g., LBA (Logical Block Address)) and physical addresses of flash memory 180. In some embodiments, lookup table control 172 may use an address translation table (logical / physical address translation table, e.g., ...). Figure 2 The metadata mappings 230 and 330 in section 3 perform (1) mapping management between each logical block address (LBA) or each logical page address and (2) each physical address. The FTL 170 can be used as a command orchestration system (e.g., Figure 2 and the command orchestration system 2000 or 3000 in 3) to manage metadata mapping (e.g. Figure 2 and metadata mappings 230 and 330 in 3) and multiple queues (e.g. Figure 3A and 3B The queue 366 in the memory is used to sequentially perform multiple reads. The garbage collection control unit 174 can perform garbage collection (GC), which is a process of generating free blocks as the destination blocks for data writing. The wear leveling control 176 can perform wear leveling, which is a process of balancing the number of block erases so that the probability of SSD 100 failure can be reduced by preventing more blocks from being erased. The flash memory control unit 178 can perform control of the flash memory interface 140.

[0031] Figure 2 This is a block diagram illustrating an example command orchestration system using address mapping according to some embodiments. (See references) Figure 2 The command orchestration system 2000 can use address mapping to track valid operations and execute command orchestration accordingly. In some embodiments, the command orchestration system 2000 may include a flash translation layer (e.g., Figure 1 In some embodiments, the metadata map 230 may be an in-memory table (e.g., stored in a non-volatile memory like FTL 170) for tracking the location of a given (metadata) page in memory. Figure 1In volatile memory of DRAM 110. In some embodiments, the metadata map may have multiple entries (e.g., entries 232, 234), each containing the flash memory address of a metadata page (MDPage) that contains mapping information (or metadata) for a given metadata page number (e.g., metadata page number 260). For example, a flash memory system (e.g., Figure 1 The SSD 100 in the middle can be obtained from a computing device (e.g., Figure 1 The host 10 receives a command 210 that may include command information 216 (e.g., whether it is a read command, write command, etc.), logical address information 212 of the data, and size 214 or other parameter information 218. The FTL can determine the metadata page number 260 of the data based on the command 210. The FTL can use the metadata page number 260 as an index to look up the metadata map 230 to locate an entry 234 containing the physical (flash) address of the metadata page 244 corresponding to the data. Similarly, the entry 232 of the metadata map may contain the physical (flash) address of the metadata page 244. In some embodiments, the metadata page 244 may contain non-volatile memory (e.g., a memory indicating the location of the target data 256) indicating the location of the target data 256. Figure 1 The physical address 254 of the page in the flash memory 180. In some embodiments, the metadata page 244 may contain at least one of other metadata 252, such as block status, data status, ECC (error correction code) of the block content, or information about the content (file ID, page ID, byte count, version, or ECC).

[0032] Figure 3A and Figure 3B This describes an example process for executing command orchestration using address mapping according to some embodiments. References Figure 3A In some embodiments, instead of storing the instruction page (e.g., metadata page) in the metadata map, it is stored in non-volatile memory (e.g., ...). Figure 1 The command orchestration system 3000 may replace the position value in the flash memory 180 with a special setting value that indicates the page is in the process of loading or being processed in another process. In some embodiments, the command orchestration system 3000 may use the controller of the flash memory system (e.g., Figure 1 The controller 120 in the system is implemented. For example, a flash memory system (e.g., Figure 1 The SSD 100 in the middle can be obtained from the host 10 (see Figure 1The system receives a command 310 containing logical address information 312 and a size 314, including data. The flash memory system can allocate or create an appropriate number of user execution tags (351, 352, etc.) based on the data size indicated by the command 314 to track the execution of the command 310 and allow commands to be executed in parallel. For example, the number of user execution tags can be determined based on the command size and a predetermined page size, such that each user execution tag may contain information for accessing a corresponding page or metadata page. In some embodiments, the user execution tag may contain information for executing a command (or a portion thereof) using the corresponding page. In some embodiments, the flash memory system's FTL (e.g., FTL 170) or command control (e.g., ...) Figure 1 The command control system 160 can assign a number of user execution tags. The FTL can determine the metadata page number #1 (321) of the data based on the user execution tag 351. Then, the FTL can use the metadata page number 321 as an index to look up the metadata map 330 to locate the entry 332 at the physical (flash) address 342 of the metadata page 1 (363) that may contain the data corresponding to the command 310. In some embodiments, the command orchestration system 3000 can assign a system execution tag (e.g., 365) indicated by the SysExecTag to execute data loaded into volatile memory (e.g., Figure 1 The metadata page 1 (363) in DRAM 110 is read (MDRead). Then, the command orchestration system 3000 replaces the current address value contained in entry 332 with address 344 (indicated by the dashed line 345) of the system execution tag address space (SysExecTag address space) 364. In some embodiments, the SysExecTag address space 364 may be a portion of the address space defined by the metadata mapping (e.g., ...). Figure 3A The 232 total address space shown in the figure is not used for addresses in non-volatile memory, such as outside the flash memory address space 362. This unused portion 364 of the address space can be allocated to orchestration management use.

[0033] In some embodiments, in response to determining that metadata page 363 is being read and retrieved, command orchestration system 3000 may use address redirection by using address value 344 corresponding to a system execution tag (SysExecTag) 1 (365) used for, for example, issuing and tracking the read process, instead of using the flash memory address 342 of the metadata page. In some embodiments, system execution tag 1 (365) may be associated with address 344 in an unused portion of the address space defined by metadata mapping 330 (e.g., SysExecTagTag address space 364). In some embodiments, system execution tag may have or point to a queue 366 of UserExecTag requests for reading undetermined metadata pages. In some embodiments, queue 366 may be stored in volatile memory separate from the memory location of SysExecTag 365, such that system execution tag 365 contains the memory address of queue 366. In some embodiments, queue 366 may be managed using a separate table indicated by SysExecTag 365. In some embodiments, queue 366 may be replaced by any implementation of a FIFO (First In First Out) data structure capable of performing queue operations (e.g., enqueueing and dequeueing) in O(1) time, such as an array, a singly linked list, or a doubly linked list. In some embodiments, queue 366 may be empty in response to a request to read undetermined metadata page 1, since it contains only null value 367. In some embodiments, such as Figure 3A As shown, after the command orchestration system assigns SysExecTag1 (365) and issues a read of metadata page 363, UserExecTag1 (351) may be placed or added to queue 366 (or any FIFO data structure associated with SysExecTag 365) to be served or processed after the read is complete. After the command orchestration system completes the service or processing of UserExecTag1 (351) (e.g., by executing command 310 (or a portion thereof) using metadata page 363), UserExecTag1 (351) may be removed from queue 366 (or any FIFO data structure associated with SysExecTag 365).

[0034] In some embodiments, there may be no non-volatile memory space allocated to the address of the system execution tag (because the system execution tag address space is outside the flash memory address space), and the system execution tag may be stored in volatile memory (e.g., Figure 1In DRAM 110. In some embodiments, the address of the system execution tag in volatile memory may be associated with address 344 in entry 332 of metadata map 330. In other words, the command orchestration system may calculate the address of the system execution tag in volatile memory based on address 344 in entry 332 of metadata map 330. For example, the address of the system execution tag in volatile memory may be calculated based on the offset of address 344 from the starting address of SysExecTag address space 364. In some embodiments, the execution tag may contain information about the process currently being performed on the metadata page (e.g., process ID or type of process, such as read process, write process, etc.) and / or information about accessing the metadata page (e.g., the address of the metadata page loaded in volatile memory).

[0035] refer to Figure 3B For example, when a new user's tag request arrives, the command orchestration system 3000, according to some embodiments, can perform a lookup of the metadata map to find a value indicating that a read of the metadata page is in progress and can instead add the request to an appropriate queue or any FIFO data structure (e.g., a linked list). For example, in addition to receiving command 1 (310) from host 10 (see... Figure 3A In addition to the above, the flash memory can receive another command 370 containing logical address information 372 and size 374. The system can assign a user execution tag 3 or UserExecTag3 (391). Based on command 370 and UserExecTag3 (391), FTL 170 can determine whether the request for command 370 is related to the previous request for command 310 (see...). Figure 3A The same data has metadata page number #1 (321). Next, the FTL can use metadata page number 321 as an index to look up metadata mapping 330 to locate entry 332. At this time, entry 332 of the metadata mapping may contain address 344 of the SysExecTag address space 364, rather than the flash memory address corresponding to metadata page 1 (363) of the data. In some embodiments, the command orchestration system 3000 may identify, locate, or access system execution tag 1 (365) based on address 344 of the SysExecTag address space 364, for example, by calculating the address of system execution tag 1 in volatile memory based on the offset of address 344 from the starting address of the SysExecTag address space 364.

[0036] In some embodiments, the command orchestration system 3000 may determine that address 344 is within the SysExecTag address space 364. In response to this determination, the system can... Figure 3AThe queue 366 shown has UserExecTag1 (351) to identify that the read operation (MDRead) of metadata page 1 is in progress (but not yet completed). The command orchestration system 3000 can then add the current request UserExecTag3 (391) (from command 2) to queue 366. In some embodiments, after the read operation of metadata page 1 is completed, the command orchestration system can remove UserExecTag1 (351) from queue 366, then service or process UserExecTag1 (351), then remove UserExecTag3 (391) from queue 366, then service or process UserExecTag3 (391). In response to determining that the service or process of UserExecTag3 (391) has been completed, the command orchestration system can determine that queue 366 is empty because it contains only null value 367. In some embodiments, in response to determining that queue 366 is empty, the command orchestration system can update the entry 332 of metadata mapping 330 with the address 342 of metadata page 1 (363) (see [link to documentation]). Figure 3A ).

[0037] Figure 4 This is a block diagram illustrating an example of an address mapping for command orchestration according to some embodiments. The command orchestration system according to some embodiments can utilize modified address mapping techniques (such as...) Figure 2 , 3A (As shown in 3B) It is applied to different stages of the command orchestration process, such as packaging, trimming, or caching.

[0038] In some embodiments, execution tags, trim tags, wrap tags, read cache tags, and write cache tags can be defined as corresponding unused portions of the address space defined by the metadata mapping. For example, refer to Figure 4 The address space 400 (2) is defined by 4-byte entries mapped from metadata. 32 Address space) can contain 2 6 Address space 412 contains a packtag for each address, where the packtag can instruct the corresponding metadata page to be processed into a metadata packet unit grouped into it by at least two commands. Address space 400 may contain addresses with 2 8 The system execution tag (SysExecTag) address space is 410, where the system execution tag (SysExecTag) indicates which read process is loading the corresponding metadata page, such as... Figure 3A and 3B As described in [the document]. Address space 400 may contain addresses with 2 [units / items]. 13Address space 408 contains trim tags for each address, where trim tags can instruct the corresponding metadata page during background trimming operations. Address space 400 may contain addresses with 2... 14 The address space is 406, where the write cache tag (WrCacheTag) indicates the corresponding dirty metadata page in volatile memory (e.g., ...). Figure 1 The location in DRAM 110). Address space 400 may contain 2 20 Address space 404 contains read cache tag (RdCacheTag) addresses, where each RdCacheTag indicates the location of a corresponding metadata page in DRAM. Address space 400 may contain approximately 2 32 -2 20 The flash memory address space is 402.

[0039] In some embodiments, the background trimming operation can be similar to Figure 3A and 3B The modified address mapping technique described herein is used for management. For example, when a metadata page undergoes background trimming, the command orchestration system can manage it by using the trim tag address space corresponding to the trim tag used to track the trimming process (e.g., ...). Figure 4 The address value of the trimmed tag address space (408) is used instead of the flash address space (e.g., the address value of the trimmed tag address space). Figure 4 The flash address of the metadata page in the flash address space (402) is used to perform address redirection. After receiving a request for specific data currently undergoing a background trimming process, the command orchestration system can identify or track the trimming process in which the metadata page is located based on the trimming tag associated with the metadata page of the specific data.

[0040] In some embodiments, the command orchestration system can process pages with at least two annotation-grouped metadata data units. For example, when processing metadata pages as metadata data units, the command orchestration system can use a pack tag address space corresponding to a pack tag used to track the command packaging process (e.g., ...). Figure 4 The address value of the packaging label address space (412) is used for address redirection. After receiving a request for specific data currently undergoing a packaging process for grouping two or more commands into a packaging command unit, the command orchestration system can identify or track the packaging process in which the metadata page is located based on the packaging label associated with the metadata page of the specific data.

[0041] In some embodiments, the command orchestration system may handle data stored in a memory cache (e.g., Figure 1 Pages in DRAM110. For example, when metadata pages are stored in a cache, the command orchestration system can access them by using the read cache tag address space (e.g., the read cache tag address space corresponding to the read cache tag (RdCacheTag) indicating the location of the metadata page in the cache (e.g., DRAM). Figure 4 The address redirection is used by reading the address value of the cache tag address space 404. In some embodiments, the command orchestration system may calculate the address of the metadata page stored in the cache based on the redirected address in the cache tag address space 404. For example, the address of the metadata page stored in the cache may be calculated based on the offset of the redirected address from the starting address of the cache tag address space 404.

[0042] In some embodiments, when stored in a cache (e.g.) Figure 1 When a metadata page in DRAM 110 has been modified but not written to non-volatile memory (e.g., the page is dirty), the command orchestration system can use the write cache tag address space (e.g., the write cache tag corresponding to the location of the dirty metadata page in the cache (e.g., DRAM) to indicate the location of the dirty metadata page in the cache (e.g., DRAM). Figure 4 The address redirection is used based on the address value in the write cache tag address space 406. In some embodiments, the command orchestration system may calculate the address of a dirty metadata page stored in the cache based on the redirected address in the write cache tag address space 406. For example, the address of a dirty metadata page stored in the cache may be calculated based on the offset of the redirected address from the starting address of the write cache tag address space 406. In some embodiments, after writing a metadata page to non-volatile memory, the command orchestration system may update the entry of the metadata map corresponding to the metadata page with the address value of the flash memory address in response to determining that the metadata page has been removed from the cache, or update the entry of the metadata map corresponding to the metadata page with the address value of the read cache address in response to determining that a (clean) metadata page has been retained.

[0043] In some embodiments, it is used to process commands (e.g.) Figure 2 , 3A and commands 210, 310, and 370 in 3B) to manage non-volatile memory (e.g. Figure 1 The device (e.g., flash memory 180) in the flash memory 180) Figure 1 The SSD 110 in the middle may include a controller (e.g., Figure 1 The controller 120 in the middle) and volatile memory (e.g. Figure 1DRAM 110 in the middle). The controller can be configured to receive a first command (e.g., Figure 3A and 3B Commands 310 and 320 in the command obtain the first address information (e.g., Figure 3A and 3B The logical address information 312, 352 in the table. The controller can be configured to read the first entry of the metadata table based on the first address information (e.g., logical address information 312, 352 in the table). Figure 3A Entry 332 of the metadata mapping 330 in the metadata table). The controller can be configured to base its actions on the first entry in the metadata table (e.g., entry 332 of the metadata mapping 330). Figure 3A The controller determines whether the first metadata page corresponding to the first address information is being processed by the controller (either at address 342 in the flash memory address space 362 or address 344 in the system execution tag address space 364). The controller can be configured to respond to determining that the first metadata page corresponding to the first address information is being processed (e.g., when the entry contains...). Figure 3B When the system executes the label address space 364 at address 344, it does so based on the first entry of the metadata table (e.g., ...). Figure 3B Entry 332 of metadata mapping 330 determines the first processing state of the first metadata page among multiple processing states (e.g., via...). Figure 3B The execution label 365 indicates the loaded state) and the first command is processed according to the first processing state of the first metadata page (e.g., from the state indicated by the first processing label 365). Figure 3B The request for command 2 in the queue is added to queue 366. The controller can be configured to respond to determining that the first metadata page corresponding to the first address information has not been processed (e.g., when entry 332 contains...). Figure 3A When the address is 342 in the flash memory address space 362, the first entry in the metadata table (e.g., contained in) is used. Figure 3A The first metadata page 363 is read from non-volatile memory at address 342 in entry 332.

[0044] In some embodiments, the metadata table (e.g. Figure 2 , 3A The metadata mappings in 3B (230, 330) can be stored in volatile memory (e.g., Figure 1 In DRAM 110). In some embodiments, multiple processing states (e.g., by DRAM 110) are used. Figure 4 The states indicated by the multiple labels shown may include the loading state for read operations (e.g., Figure 4 The ExecTag in the data (e.g., the loading state used for trimming operations) Figure 4 TrimTag in the code), and the loading state used for wrapping operations (e.g., ...). Figure 4 PackTag in the cache), page state in the cache (e.g.) Figure 4(RdCacheTag in the cache) or dirty page state in the cache (e.g.) Figure 4 At least one of the WrCacheTags in the dataset.

[0045] In some embodiments, when determining whether a first metadata page is being processed by the controller, the controller may be configured to base its decision on a first entry (e.g., ...). Figure 3A and 3B Entry 332 in the document determines the first address (e.g., ...). Figure 3A and 3B Address 342 or address 344 in the code). The controller can be configured to respond to determining the first address (e.g., address 342 or address 344 in the code). Figure 3A Address 342 in the address space of non-volatile memory (e.g., ...) Figure 3A and 3B The first metadata page (e.g., within the flash memory address space 362) is determined. Figure 3A Metadata page 1 (363) in the document was not processed. The controller can be configured to respond to determining the first address (e.g., Figure 3B Address 344 in the address space of non-volatile memory (e.g., in...) Figure 3B The system execution tag address space (364) outside the flash memory address space (362) determines that the first metadata page is being processed. In some embodiments, each of the plurality of processing states may be associated with a corresponding address space outside the address space of non-volatile memory (e.g., ...). Figure 4 The packaging tag address space 412, system execution tag address space 410, trim tag address space 408, write cache tag address space 406, and read cache tag address space 404 are associated with each other. In some embodiments, when determining the first processing state of the first metadata page, the controller may be configured to base its actions on the first entry (e.g., ...). Figure 3B Entry 332 in the document determines the first address (e.g., ...). Figure 3B Address 344 in the middle) and determine the first address (e.g. Figure 3B Address 344 in the address space associated with the first processing state (e.g., ...) Figure 3B The system execution label address space is within 364.

[0046] In some embodiments, the controller may be configured to be the first metadata page (e.g. Figure 3A In the metadata page 1 (363)) create the first request queue (e.g. Figure 3A Queue 366 in the middle). The controller can be configured to respond to determining that a first metadata page is being processed by sending a corresponding first command (e.g., Figure 3B The request in command 2 (370) (e.g.) Figure 3B Request 368 in the middle) is added to the first queue (e.g. Figure 3B Queue 366 in the first metadata page). The controller can be configured to determine whether the current processing of the first metadata page is complete. The controller can be configured to release data from the first queue (e.g., queue 366) in response to determining that the current processing of the first metadata page is complete. Figure 3B The request is removed from queue 366 and the first metadata page is read (e.g., ...). Figure 3B Metadata page 1 (363) in the document is used to handle removal requests (e.g. Figure 3B (Request 368 in the original text). The controller can be configured to determine whether the current processing of the first metadata page is complete. In response to determining that the current processing of the first metadata page is complete, the controller can be configured to determine that the first queue is empty. In response to determining that the first queue is empty, the controller can be configured to indicate the location of the first metadata page (e.g., ...). Figure 3B The address of the non-volatile memory of metadata page 1 (363) is updated to the first entry of the metadata table (e.g., the address of the metadata page 1 (363)). Figure 3B Entries 332 of the metadata mapping 330 in the metadata mapping 330). In some embodiments, the first queue may be a linked list (e.g., Figure 3B (Linked list implementation scheme for queue 366).

[0047] Figure 5 This is a flowchart illustrating an example method for executing command orchestration using address mapping, according to some embodiments. In this example, the process begins at S502: by the processor (e.g., Figure 1 The processor 250 in the first command (e.g.) Figure 3A and 3B Commands 310 and 370 in the command obtain the first address information (e.g., Figure 3A and 3B (Logical address information 312, 372).

[0048] In S504, in some embodiments, the processor may read the first entry of the metadata table based on the first address information (e.g., Figure 3A Entries 332 of the metadata mapping 330 in the metadata table). In some embodiments, the metadata table may be stored in volatile memory (e.g., Figure 1 In DRAM 110).

[0049] In S506, in some embodiments, the processor may base its processing on the first entry of the metadata table (e.g., Figure 3A The controller determines whether the first metadata page corresponding to the first address information is being processed by the controller (either at address 342 in the flash memory address space 362 or address 344 in the system execution tag address space 364). In some embodiments, when determining whether the first metadata page is being processed by the controller (e.g., when the entry contains...), the controller... Figure 3BWhen the system executes at address 344 in label address space 364, the processor can base its decisions on the first entry (e.g., ...). Figure 3A and 3B Entry 332 in the document determines the first address (e.g., ...). Figure 3A and 3B Address 342 or address 344 in the middle), in response to determining the first address (e.g. Figure 3A Address 342 in the address space of non-volatile memory (e.g., ...) Figure 3A and 3B The first metadata page (e.g., within the flash memory address space 362) is determined. Figure 3A Metadata page 1 (363) in the document was not processed, and in response to determining the first address (e.g. Figure 3B Address 344 in the address space of non-volatile memory (e.g., in...) Figure 3B The system execution tag address space (outside the flash memory address space 362) determines that the first metadata page is being processed.

[0050] In some embodiments, each of the plurality of processing states may be associated with a corresponding address space outside the address space of non-volatile memory (e.g., Figure 4 The address space of the packaging tag 412, the system execution tag address space 410, the trim tag address space 408, the write cache tag address space 406, and the read cache tag address space 404 are associated. When determining the first processing state of the first metadata, the processor may base it on the first entry (e.g., ...). Figure 3B Entry 332 in the document determines the first address (e.g., ...). Figure 3B Address 344 in the middle) and determine the first address (e.g. Figure 3B Address 344 in the address space associated with the first processing state (e.g., ...) Figure 3B The system execution label address space is within 364.

[0051] In S508, in some embodiments, in response to determining that a first metadata page corresponding to the first address information is being processed (e.g., when the entry contains...), Figure 3B When the system executes at address 344 in label address space 364, the processor can base its decision on the first entry in the metadata table (e.g., ...). Figure 3B Entry 332 of metadata mapping 330 in the document determines the first processing state of the first metadata page among multiple processing states (e.g., by...). Figure 3B The execution label 365 indicates the loaded state) and the first command is processed according to the first processing state of the first metadata page (e.g., from the state indicated by the first processing label 365). Figure 3B The request for command 2 in the process is added to queue 366). In some embodiments, multiple processing states (e.g., by...) Figure 4The states indicated by the multiple labels shown may include the loading state for read operations (e.g., Figure 4 The ExecTag in the data (e.g., the loading state used for trimming operations) Figure 4 TrimTag in the code), and the loading state used for wrapping operations (e.g., ...). Figure 4 PackTag in the cache), page state in the cache (e.g.) Figure 4 (RdCacheTag in the cache) or dirty page state in the cache (e.g.) Figure 4 At least one of the WrCacheTags in the dataset.

[0052] In some embodiments, the processor may be the first metadata page (e.g. Figure 3A In the metadata page 1 (363)) create the first request queue (e.g. Figure 3A Queue 366 in the queue). In response to determining that the first metadata page is being processed, the processor can send the corresponding first command (e.g., Figure 3B The request in command 2 (370) (e.g.) Figure 3B Request 368 in the middle) is added to the first queue (e.g. Figure 3B In queue 366). The processor can determine whether the current processing of the first metadata page is complete. In response to determining that the current processing of the first metadata page is complete, the processor can retrieve data from the first queue (e.g., queue 366). Figure 3B The request is removed from queue 366 and the first metadata page is read (e.g., ...). Figure 3B Metadata page 1 (363) in the document is used to handle removal requests (e.g. Figure 3B (Request 368 in the original text). The processor may determine whether the current processing of the first metadata page is complete. In response to determining that the current processing of the first metadata page is complete, the processor may determine that the first queue is empty. In response to determining that the first queue is empty, the processor may use an indication of the location of the first metadata page (e.g., ...). Figure 3B The address of the non-volatile memory of the metadata page 1 (363) is updated to the first entry of the metadata table (e.g., the address of the metadata page 1 (363)). Figure 3B Entries 332 of metadata mapping 330). In some embodiments, the first queue may be a linked list (e.g., Figure 3B (Linked list implementation scheme for queue 366).

[0053] In S510, in some embodiments, in response to determining that the first metadata page corresponding to the first address information has not been processed (e.g., when entry 332 contains...), Figure 3A When the processor is at address 342 in the flash memory address space 362, it can base its decision on the first entry in the metadata table (e.g., contained in...). Figure 3AThe first metadata page 363 is read from non-volatile memory at address 342 in entry 332.

[0054] The above description is provided to enable those skilled in the art to practice the various aspects described herein. Those skilled in the art will readily understand the various modifications to these aspects, and the general principles defined herein can be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but rather to be given the full scope consistent with the written claims, wherein the reference to a singular element does not mean “one and only one” (unless otherwise stated), but rather “one or more.” Unless otherwise stated, the term “some” means one or more. All structural and functional equivalents of the elements of the various aspects described in the entire above description that are known or would be known thereafter by those skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be made public, whether or not such disclosure is expressly stated in the claims. No claim element should be construed as a component + function unless the element is expressly stated using the phrase “component for…”.

[0055] It should be understood that the specific order or hierarchy of steps in the disclosed process is an example of an illustrative method. Based on design preferences, it should be understood that the specific order or hierarchy of steps in the process may be rearranged while remaining within the scope described above. The appended method claims present the elements of each step in the order shown in the sample, and are not intended to be limited to the specific order or hierarchy presented.

[0056] The above description of the disclosed embodiments is provided to enable those skilled in the art to make or use the disclosed object. Those skilled in the art will readily understand various modifications to these embodiments and can apply the general principles defined herein to other embodiments without departing from the spirit or scope of the above description. Therefore, the above description is not intended to be limited to the embodiments shown herein, but should be given the broadest scope consistent with the principles and novel features disclosed herein.

[0057] The examples illustrated and described are merely illustrative of the various features of the claims. However, the features shown and described with respect to any given example are not necessarily limited to the associated example, but may be used or combined with other examples shown and described. Furthermore, the claims are not intended to be limited by any single example.

[0058] The above method descriptions and process flowcharts are for illustrative purposes only and are not intended to require or imply that the steps in each example must be performed in the presented order. Those skilled in the art will understand that the order of the steps in the above examples can be performed in any order. Words such as "after," "next," and "following" are not intended to limit the order of steps; these words are only used to guide the reader through the description of the method. Furthermore, any reference to elements in the singular claims (e.g., the use of the articles "a" or "described") should not be construed as limiting the element to the singular.

[0059] The various illustrative logic blocks, modules, circuits, and algorithm steps described in conjunction with the examples disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, the various illustrative components, blocks, modules, circuits, and steps have been described above generally according to their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as departing from the scope of this disclosure.

[0060] The hardware used to implement the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the examples disclosed herein may be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware component, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but in alternative examples, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by a circuit system specifically designed for a given function.

[0061] In some exemplary instances, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. Software-implemented functionality may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The steps of the methods or algorithms disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. For example, but not limited to, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage devices, or any other media that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact disks (CDs), laser disks, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically magnetically copy data, while optical discs utilize lasers to optically copy data. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium that may be incorporated into a computer program product.

[0062] The above description of the disclosed examples is provided to enable those skilled in the art to make or use this disclosure. Those skilled in the art will readily understand various modifications to these examples and can apply the general principles defined herein to some examples without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not intended to be limited to the examples shown herein, but should be given the broadest scope consistent with the principles and novel features disclosed herein and in the appended claims.

Claims

1. An apparatus for processing commands to manage non-volatile memory, comprising: Controller; and Volatile memory, The controller is configured to: Obtain the first address information from the first command; The first entry of the metadata table is read based on the first address information, wherein the metadata table is configured to include multiple entries, each of the multiple entries providing mapping information or additional information, the mapping information specifying the mapping between address information from the command and page addresses in the non-volatile memory, and the additional information specifying the processing status of the metadata page in the non-volatile memory. Based on the first entry in the metadata table, determine whether the first metadata page corresponding to the first address information is being processed by the controller; In response to determining that the first metadata page corresponding to the first address information is being processed, the additional information of the first entry in the metadata table is used to determine the first processing state of the first metadata page among multiple processing states; and In response to determining that the first metadata page corresponding to the first address information has not been processed, the first metadata page is read from the non-volatile memory into the volatile memory using the mapping information in the first entry of the metadata table and the mapping information in the first entry of the metadata table is replaced with the additional information.

2. The apparatus of claim 1, wherein the metadata table is stored in the volatile memory.

3. The apparatus of claim 1, wherein the plurality of processing states includes at least one of a loading state for a read operation, a loading state for a trimming operation, a loading state for a packing operation, a page state in the cache, or a dirty page state in the cache.

4. The apparatus according to claim 1, wherein When determining whether the first metadata page is being processed by the controller, the controller is configured to: The first address is determined based on the first entry; In response to determining that the first address is within the address space of the non-volatile memory, it is determined that the first metadata page has not been processed; and In response to determining that the first address is outside the address space of the non-volatile memory, it is determined that the first metadata page is being processed.

5. The apparatus according to claim 1, wherein Each of the plurality of processing states is associated with a corresponding address space outside the address space of the non-volatile memory.

6. The apparatus according to claim 5, wherein When determining the first processing state of the first metadata page, the controller is configured to: Determine the first address based on the first entry; and The first address is determined to be within the corresponding address space associated with the first processing state.

7. The apparatus of claim 1, wherein the controller is configured to: Create a first request queue for the first metadata page; and In response to determining that the first metadata page is being processed, a request corresponding to the first command is added to the first request queue.

8. The apparatus of claim 7, wherein the controller is configured to: Determine whether the current processing of the first metadata page is complete; and In response to determining that the current processing of the first metadata page has been completed, the controller is configured to remove the request from the first request queue.

9. The apparatus of claim 7, wherein the controller is configured to: Determine whether the current processing of the first metadata page is complete; and In response to determining that the current processing of the first metadata page has been completed, It is determined that the first request queue is empty, and In response to determining that the first request queue is empty, the first entry in the metadata table is updated with the metadata page address in the non-volatile memory of the first metadata page.

10. The apparatus of claim 7, wherein the first request queue is a linked list.

11. A method for processing commands to manage non-volatile memory, comprising: The processor obtains the first address information from the first command; The processor reads a first entry from the metadata table based on the first address information, wherein the metadata table is configured to include multiple entries, each of which provides mapping information or additional information, the mapping information specifying the mapping between address information from the command and page addresses in the non-volatile memory, and the additional information specifying the processing status of the metadata page in the non-volatile memory. The processor determines, based on the first entry in the metadata table, whether the first metadata page corresponding to the first address information is being processed by the controller; In response to determining that the first metadata page corresponding to the first address information is being processed, the processor uses the additional information in the first entry of the metadata table to determine the first processing state of the first metadata page among a plurality of processing states; and In response to determining that the first metadata page corresponding to the first address information has not been processed, the processor uses the mapping information in the first entry of the metadata table to read the first metadata page from the non-volatile memory into the volatile memory and replaces the mapping information in the first entry of the metadata table with the additional information.

12. The method of claim 11, wherein the metadata table is stored in volatile memory.

13. The method of claim 11, wherein the plurality of processing states includes at least one of a load state for a read operation, a load state for a trim operation, a load state for a wrap operation, a page state in the cache, or a dirty page state in the cache.

14. The method of claim 11, wherein determining whether the first metadata page is being processed by the controller comprises: The first address is determined based on the first entry; In response to determining that the first address is within the address space of the non-volatile memory, it is determined that the first metadata page has not been processed; and In response to determining that the first address is outside the address space of the non-volatile memory, it is determined that the first metadata page is being processed.

15. The method of claim 11, wherein each of the plurality of processing states is associated with a corresponding address space outside the address space of the non-volatile memory.

16. The method of claim 15, wherein determining the first processing state of the first metadata comprises: The first address is determined based on the first entry; and The first address is determined to be within the address space associated with the first processing state.

17. The method of claim 11, further comprising: Create a first request queue for the first metadata page; and In response to determining that the first metadata page is being processed, a request corresponding to the first command is added to the first request queue.

18. The method of claim 17, further comprising: Determine whether the current processing of the first metadata page is complete; and In response to determining that the current processing of the first metadata page has been completed, the request is removed from the first request queue.

19. The method of claim 17, further comprising: Determine whether the current processing of the first metadata page is complete; and In response to determining that the current processing of the first metadata page has been completed, It is determined that the first request queue is empty, and In response to determining that the first request queue is empty, the first entry in the metadata table is updated with the metadata page address in the non-volatile memory of the first metadata page.

20. The method of claim 17, wherein the first request queue is a linked list.

Images