Namespace operation method for flash storage device

Abstract

An embodiment of the present invention provides a namespace operation method for a flash memory storage device, which is executed by a processing unit of the storage device and includes: receiving a cross-namespace data migration command from a host device, requesting that user data at a first logical address in a first namespace be migrated to a storage space at a second logical address in a second namespace; cutting out first physical address information corresponding to the first logical address in a first logical-physical comparison table, wherein the first logical-physical comparison table corresponds to the first namespace; and pasting the first physical address information to an entry corresponding to the second logical address in a second logical-physical comparison table, wherein the second logical-physical comparison table corresponds to the second namespace.

Description

[0001] This application is a divisional application. The application date of the original application is August 24, 2018; the application number is 201810970872.9; the name of the invention is: Namespace operation method of flash memory storage device. Technical Field

[0002] The present invention relates to a flash memory storage device, and in particular to a namespace operation method of the flash memory storage device. Background Art

[0003] Flash memory devices are generally categorized as NOR flash memory devices and NAND flash memory devices. NOR flash memory devices are random access devices. The host can provide any address to access the NOR flash memory device on the address pins and promptly retrieve the data stored at that address from the NOR flash memory device's data pins. In contrast, NAND flash memory devices are not random access devices, but rather sequential access devices. Unlike NOR flash memory devices, NAND flash memory devices cannot access any random address. Instead, the host must write a sequence of byte values to the NAND flash memory device to define the type of command being requested (e.g., read, write, erase, etc.) and the address used for that command. The address can point to a page (the smallest data block for write operations in a flash memory device) or a block (the smallest data block for erase operations in a flash memory device).

[0004] The Non-Volatile Memory Express (NVMe) Namespace Management command can be used to create and delete namespaces. In addition to the operations described above, users may need to increase the length of a namespace or perform advanced operations such as migrating data between different namespaces. However, current specifications do not support these advanced operations. Therefore, the present invention provides a namespace operation method for a flash memory storage device to support these advanced operations. Summary of the Invention

[0005] In view of this, how to alleviate or eliminate the deficiencies in the above-mentioned related fields is indeed a problem to be solved.

[0006] The present invention provides an embodiment of a namespace operation method for a flash memory storage device, which is executed by a processing unit of the storage device and includes: receiving a namespace setting update command from a host device, requesting to update the namespace length of the namespace; determining whether the updated namespace length can be supported; and when the updated namespace length can be supported, updating the logical-physical comparison table of the namespace to allow the namespace to store user data of the updated namespace length.

[0007] The present invention also provides an embodiment of a namespace operation method for a flash memory storage device, which is executed by a processing unit of the storage device and includes: receiving a cross-namespace data migration command from a host device, requesting to migrate user data of a first logical address in a first namespace to a storage space of a second logical address in a second namespace; cutting out the first physical address information corresponding to the first logical address in a first logical-physical comparison table; and pasting the first physical address information to the item corresponding to the second logical address in the second logical-physical comparison table.

[0008] One of the advantages of the above embodiment is that, after a namespace is created and attached, the host device is allowed to increase the length and capacity of the namespace.

[0009] Another advantage of the above embodiment is that since it does not involve any actual migration of user data between different namespaces, it avoids wasting space and bandwidth to store and transmit a series of read and write commands and completion components.

[0010] Other advantages of the present invention will be explained in more detail with reference to the following description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The drawings described herein are used to provide further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute improper limitations on the present application.

[0012] Figure 1 FIG. 1 is a schematic diagram of a system architecture of a flash memory according to an embodiment of the present invention.

[0013] Figure 2 A schematic diagram of the connection between the access sub-interface and multiple storage sub-units.

[0014] Figure 3 This is a schematic diagram of physical storage comparison.

[0015] Figure 4 Schematic diagram of data organization of storage unit.

[0016] Figure 5 This is a diagram of the command queue.

[0017] Figure 6A flowchart of the steps involved in executing a management or data access command.

[0018] Figure 7 Sequence diagram for namespace creation and attachment.

[0019] Figure 8 Sequence diagram for namespace disassociation and deletion.

[0020] Figure 9 A sequence diagram of namespace configuration update according to an embodiment of the present invention.

[0021] Figure 10 FIG. 1 is a diagram illustrating the data structure of a namespace update command according to an embodiment of the present invention.

[0022] Figure 11 FIG. 4 is a flow chart of a method for namespace update operation according to an embodiment of the present invention.

[0023] Figure 12 FIG. 4 is a schematic diagram of an expanded logical-physical correspondence table according to an embodiment of the present invention.

[0024] Figure 13 FIG. 1 is a functional module diagram of a namespace setting update operation according to an embodiment of the present invention.

[0025] Figure 14 4 is a sequence diagram of cross-namespace data migration according to an embodiment of the present invention.

[0026] Figure 15 Schematic diagram of the data structure of a cross-namespace data migration command according to an embodiment of the present invention.

[0027] Figure 16 4 is a flow chart of a method for cross-namespace data migration according to an embodiment of the present invention.

[0028] Figure 17 FIG. 4 is a schematic diagram illustrating the migration of physical address information in a logical-physical mapping table of different namespaces according to an embodiment of the present invention.

[0029] Figure 18 Schematic diagram of the functional modules of a cross-namespace data migration operation according to an embodiment of the present invention.

[0030] Explanation of symbols:

[0031] 110 Main unit

[0032] 120, 131 Random Access Memory

[0033] 130 Storage Device

[0034] 132 Data Link Layer

[0035] 135 Flash Memory Controller

[0036] 137 Access Interface

[0037] 137_0 Access sub-interface

[0038] 139 storage units

[0039] 139_0_0~139_0_i storage subunits

[0040] 210 data cable

[0041] 230_0~230_i Chip enable control signal

[0042] 310, 1210, 1230, 1710, 1730 logical-physical comparison table

[0043] 330, 330-0 to 330-3 physical address information

[0044] 350 physical blocks

[0045] 351 Physical Area

[0046] 410, 430, 450, 470 input and output channels

[0047] 410_0 to 410_m, 430_0 to 430_m, 450_0 to 450_m, 470_0 to 470_m data plane

[0048] 490_0~490_n super page

[0049] P#0~p#(n) physical pages

[0050] 510, 530 queues

[0051] S611~S636, S1110~S1170, S1610~S1640 Method steps

[0052] Commands 712, 732, 752, 812, 832, 912, and 1412

[0053] Execution results: 714, 734, 754, 814, 834, 914, 1414

[0054] 720, 740, 760, 780, 820, 840, 920, 1420 operation

[0055] Fields 1010 to 1070

[0056] 1310-1340, 1810-1830 Program process module DETAILED DESCRIPTION

[0057] The embodiments of the present invention will be described below with reference to the accompanying drawings. In these drawings, the same reference numerals represent the same or similar components or method flows.

[0058] It must be understood that the words "comprise", "include" and the like used in this specification are used to indicate the existence of specific technical features, values, method steps, job processing, components and / or components, but do not exclude the addition of more technical features, values, method steps, job processing, components, components, or any combination of the above.

[0059] The terms "first", "second", "third", etc. used in the present invention are used to modify the components in the claims and are not used to indicate a priority order, a precedence relationship, or that one component precedes another, or a temporal sequence in executing method steps. They are only used to distinguish components with the same name.

[0060] It should be understood that when a component is described as being "connected" or "coupled" to another component, it can be directly connected or coupled to the other component, and intervening components may be present. Conversely, when a component is described as being "directly connected" or "directly coupled" to another component, there are no intervening components. Other words used to describe the relationship between components should be interpreted in a similar manner, such as "between" versus "directly between," or "adjacent" versus "directly adjacent," etc.

[0061] refer to Figure 1. The flash memory system architecture 100 includes a main device 110, a random access memory (Random Access Memory RAM) 120 and a storage device 130. When the main device 110 is in operation, it can establish a queue according to its needs. This system architecture can be implemented in electronic products such as personal computers, laptop computers (Laptop PC), tablet computers, mobile phones, digital cameras, digital video cameras, etc. Specific areas in the random access memory 120 can be configured as data buffers and queues, etc., as well as storage device operating parameters and namespace variables. The storage device 130 may include a processing unit 133. The processing unit 133 can receive a namespace management command from the main device 110, and accordingly instruct the flash controller 135 to perform operations such as increasing the namespace length or capacity (Namespace Size or Capacity) and data migration across namespaces. The length or capacity of the namespace can be represented by the number of logical blocks, and each logical block is assigned a logical block address. The size of the logical block can be determined by the length of the formatted logical block address (Formatted LBA Size), for example, 4KB, wherein the logical block may include metadata in addition to user data. The namespace length may refer to the total number of logical blocks in a specific namespace. For example, a namespace of length n includes logical blocks of logical block addresses (LBAs) LBA#0 to LBA#(n-1) from 0 to n-1. The namespace capacity may refer to the maximum number of logical blocks that a specific namespace can store in the main device 110. The main device 110 and the processing unit 133 preferably use a fast non-volatile memory express (NVMe) communication protocol for communication. Host device 110 and processing unit 133 can be implemented in a variety of ways, such as using general-purpose hardware (e.g., a single processor, a multiprocessor with parallel processing capabilities, a graphics processor, or other processors with computing capabilities), and provide the functionality described below when executing instructions, macrocode, or microcode. Random access memories 120 and 131 can store data required during execution, such as variables and data tables.

[0062] The storage device 130 further includes a flash memory controller 135, an access interface 137, and a storage unit 139. The flash memory controller 135 communicates with the storage unit 139 via the access interface 137. Specifically, a double data rate (DDR) communication protocol, such as Open NAND Flash Interface (ONFI), DDR Toggle, or other interfaces, may be employed. The flash memory controller 135 of the storage device 130 writes user data to a specified address (destination address) in the storage unit 139 and reads user data from a specified address (source address) in the storage unit 139 via the access interface 137. The access interface 137 coordinates the transfer of data and commands between the flash memory controller 135 and the storage unit 139 using several electronic signals, including data lines, clock signals, and control signals. The data lines can be used to transmit commands, addresses, and read and write data; the control signal lines can be used to transmit control signals such as chip enable (CE), address latch enable (ALE), command latch enable (CLE), and write enable (WE). The processing unit 133 and the flash memory controller 135 can exist separately or be integrated into the same chip.

[0063] The storage unit 139 may include multiple storage sub-units, each of which uses an associated access sub-interface to communicate with the flash memory controller 135. One or more storage sub-units may be encapsulated in a die. The storage device 130 may include j access sub-interfaces, each of which is connected to i storage sub-units. The access sub-interface and the storage sub-units connected thereto may be collectively referred to as output-input channels, and may be identified by logical unit numbers. In other words, i storage sub-units share one access sub-interface. For example, when the storage device 130 includes 4 outputs and inputs and each output and input is connected to 4 storage units, the storage device 130 has a total of 16 storage sub-units. The flash memory controller 135 may drive one of the access sub-interfaces to read data from a specified storage sub-unit or write data to a specified storage sub-unit. Each storage sub-unit has an independent chip enable (CE) control signal. In other words, when data is to be read from a specified storage sub-unit, the associated access sub-interface needs to be driven to enable the chip enable control signal of this storage sub-unit. Reference Figure 2The flash controller 135 can select one of the connected memory subunits 139_0_0 to 139_0_i using independent chip enable control signals 230_0_0 to 230_0_i via the access sub-interface 137_0 and then read data from a designated address of the selected memory subunit via the shared data line 210_0.

[0064] refer to Figure 3 . The logical-physical correspondence table 310 preferably stores the physical address information corresponding to each logical address (or logical block address) in sequence. The space required for the logical-physical correspondence table 310 is preferably proportional to the total number of logical addresses. The logical address can be represented by a logical block address, and each LBA corresponds to a logical block of a fixed size, such as 512 bytes, and is stored in a physical address. For example, the logical-physical correspondence table 310 stores the physical address information from LBA#0 to LBA#65535 in sequence. The data of several consecutive logical addresses (for example, LBA#0 to LBA#7) can form a host page. Physical address information 330 can be represented by four bytes: the first byte 330-0 records the (physical) block number, the second byte 330-1 records the (physical) page number and offset, the third byte 330-2 records the (physical) plane number, and the last byte 330-3 records the logical unit number (LUN). For example, physical information 330 corresponding to LBA #2 may point to an area 351 in block 350.

[0065] refer to Figure 4The storage unit 139 includes multiple planes 410_0 to 410_m, 430_0 to 430_m, 450_0 to 450_m, and 470_0 to 470_m. Each plane or multiple planes are placed in a logical unit number. Planes 410_0 to 410_m and their shared access sub-interfaces are referred to as input / output channels 410, planes 430_0 to 430_m and their shared access sub-interfaces are referred to as input / output channels 430, planes 450_0 to 450_m and their shared access sub-interfaces are referred to as input / output channels 450, and planes 470_0 to 470_m and their shared access sub-interfaces are referred to as input / output channels 470. m can be an integer that is a power of 2 (e.g., 2, 4, 8, 16, 32, etc.), and input / output channels 410, 430, 450, and 470 can be identified using logical unit numbers. Each of planes 410_0 to 470_m includes multiple blocks, each block includes multiple pages P#0 to P#(n), each page includes multiple sectors (e.g., 4, 8, etc.), where n can be 767 or 1535. Each page includes multiple NAND memory cells, and the NAND memory cells can be single-level cells (SLCs), multi-level cells (MLCs), triple-level cells (TLCs), or quad-level cells (QLCs). In some embodiments, when each NAND memory cell is a single-level cell capable of recording two states, page P#0 in planes 410_0 to 470_0 may virtually form super page 490_0, and page P#1 in planes 410_0 to 470_0 may virtually form super page 490_1, and so on. In other embodiments, when each NAND memory cell is a multi-level cell capable of recording four states, a physical word line may include page P#0 (which may be called the Most Significant Bit (MSB) page), page P#1 (which may be called the Least Significant Bit (LSB) page), and so on. In some other embodiments, when each NAND memory cell is a three-level cell and can record 8 states, a physical word line may include page P#0 (which may be called the least significant bit page, MSB page), page P#1 (which may be called the center significant bit page, CSB) and page P#2 (which may be called the most significant bit page, LSB page).When each NAND memory cell is a four-level cell capable of recording 16 states, in addition to the MSB, CSB, and LSB pages, a TSB (also known as Top Significant Bit) page is further included.

[0066] When the memory unit 139 is operating, a page is the smallest unit for data writing or programming, with a size of, for example, 4KB. In this case, the physical address can be represented by the page number. If a page contains multiple sectors, for example, 4 sectors, each capable of storing 4KB of data, the sector can be the smallest unit for data management. In this case, the physical address can be represented by the sector number (SectorNumber) of the page or the offset (Offset) of the sector within the page. Furthermore, generally speaking, a block is the smallest unit for data erasure.

[0067] Figure 5 Schematic diagram of a command queue. The command queue may include a submission queue (SQ) 510 and a completion queue (CQ) 530, which are used to temporarily store master device commands and completion elements (CEs), respectively. The submission queue 510 and the completion queue 530 are preferably established in the same device. For example, the submission queue 510 and the completion queue 530 are preferably established in the memory of the master device, but can also be established in the memory of the storage device 130. The submission queue 510 and the completion queue 530 can also be established in different devices. Each of the submission queue 510 and the completion queue 530 contains a collection of multiple entries. Each entry in the submission queue 510 stores a master device command. The master device commands can be further divided into administration commands, such as identification, set feature, namespace management, namespace attachment commands, etc.; and input / output commands, such as erase, read, and write commands, which can also be called data access commands. Figure 5Only two queues 510 and 530 are shown, but technicians in the relevant technical field can establish two submission queues 510, namely an administration submission queue (Administration Submission Queue) and an input / output submission queue (I / O Submission Queue), respectively for temporarily storing management commands and data access commands from the master device 110. Similarly, technicians in the relevant technical field can establish two completion queues 530, namely an administration completion queue (Administration Completion Queue) and an input / output completion queue (I / O Completion Queue), respectively for storing completion components associated with management commands and data access commands.

[0068] Each entry in the completion queue 530 stores a completion component associated with a management command or data access command. This completion component is used to report the execution result of the master device's instruction, such as success or failure, and can also serve as confirmation information. The items in the collection are stored in order. The basic principle of collection operation is to add items (also known as enqueue) from the end position (or called the tail of the queue) and execute items (also known as dequeue) at the beginning position (or called the head of the queue). The total number of items enqueued or dequeued at one time can be greater than or equal to one. The first command or information added to the submission queue 510 or completion queue 530 will also be the first to be replaced or updated. The master device 110 can write management or data access commands to the submission queue 510, and the processing unit 133 reads (also known as fetches) the earliest arriving management or data access command from the submission queue 510 and executes it. After the management or data access command is executed, the processing unit 133 writes a completion element to the completion queue 530 . The host device 110 can read or extract the completion element to determine the execution result of the management or data access command.

[0069] refer to Figure 6The host device 110 generates and writes a management command or data access command to the submission queue 510 (step S611). Next, the host device 110 sends a submission doorbell to the processing unit 133 (step S612) to notify the processing unit 133 that a management command or data access command has been written to the submission queue 510 and to update the value at the end of the submission queue 510. It should be noted that steps S611 and S612 can also be referred to as the host device 110 sending a management command or data access command to the storage device 130. After receiving the submission doorbell (step S631), the processing unit 133 reads the management command or data access command at the head of the submission queue 510 (step S632) and executes the operation specified by the management command or data access command (e.g., identification, parameter setting, namespace management, namespace attachment, erasure, data reading, data writing, etc.) (step S633).

[0070] It should be noted that steps S631 and S632 can also be referred to as the storage device 130 receiving a management command or data access command from the host device 110. When the designated operation is completed, the processing unit 133 generates and writes a completion element to the completion queue 530 (step S634) to notify the host device 110 of the execution result and status information of the operation corresponding to the specific management command or data access command, and then issues an interrupt to the host device 110 (step S635). After receiving the interrupt (step S613), the host device 110 reads the completion element at the head of the completion queue 530 (step S613) to determine the execution result of the specific management command or data access command. If the execution fails, the cause of the failure can be determined based on the status information in the completion element. The host device 110 then issues a completion doorbell to the processing unit 133 (step S614). After receiving the completion doorbell (S636), the processing unit 133 receives the updated value at the head of the completion queue 530. It should be noted that steps S634 and S635 can also be referred to as the storage device 130 replying to the host device 110 regarding the execution result of the management command or data access command. It should be noted that steps S613 and S614 can also be referred to as the host device 110 receiving the execution result of the management command or data access command from the storage device 130.

[0071] In steps S612 and S614 , the host device 110 may set corresponding registers to send a doorbell submission and doorbell termination signal to the processing unit 133 .

[0072] refer to Figure 7, when the storage device 130 is connected to the main device 110 and completes initialization, the main device 110 may issue an identification command (Identify Command) 712 to the storage device 130. After the storage device 130 completes the pre-operation 720, the main device 110 may receive the execution result 714 from the storage device 130, wherein the identification command 712 may be a controller identification command to request a controller data structure (Controller Data Structure). Controller Data Structure Controller Capabilities and Features, such as including fields such as the peripheral component interconnect vendor identification code, serial number, firmware version, maximum data transmission length, and controller identification code. The controller data structure may further describe management command set attributes and optional controller capabilities, such as fields such as optional management command set support (Optional Admin Command Support, OACS). The OACS field may record information on whether the controller supports namespace management and attachment commands.

[0073] In addition to the controller identification command, identification command 712 can also be a common namespace identification command to request a common namespace data structure (Namespace Data Structure), such as Common Namespace Capabilities, which includes fields such as Namespace Size (NSZE) and Namespace Capacity (NCAP). Byte 0 of the 10th double word in identification command 712 can be used to distinguish whether the request is for a controller data structure or a namespace data structure.

[0074] In the pre-processing operation 720, the processing unit 133 may read the read-only memory (not shown in FIG. Figure 1 ) or reads the storage unit 139 to obtain the required information in the controller and namespace data structure, and uploads the contents of the controller and namespace data structure to the address of the random access memory 120 specified in the identification command 712 for the host device 110 to read.

[0075] Afterwards, the host device 110 may refer to the controller and the contents of the namespace data structure described above and issue a namespace management command 732 to the storage device 130 to establish a new namespace. The host device 110 may allocate 4K bytes in the random access memory 120 to store the contents of the namespace data structure to be established, with bytes 0 to 383 constituting the Identify Namespace field. For example, bytes 0 to 7 constitute the Namespace Size field, with a value of 0x0FFFFFF, while bytes 8 to 15 constitute the Namespace Capacity field, with a value of 0x0FFFFFF. To establish a new namespace, the host device 110 may indicate in the Namespace Management Command 732 that this is a create operation (as indicated by bits 0 to 3 in the 10th double word) and provide the address (memory address) pointing to the contents of the namespace data structure (as indicated by double words 6 to 7 or double words 6 to 9).

[0076] During the namespace establishment operation 740, the processing unit 133 may allocate a namespace, such as 0x00, from the available namespace identifiers (NSIDs) for the request, and may store the values of the namespace length and capacity fields in the random access memory 131 and / or the storage unit 139. After the storage device 130 successfully executes the namespace #0 establishment operation 740, the host device 110 may receive an execution result 734 from the storage device 130, including the namespace identifier assigned by the storage device 130 and information indicating that namespace #0 was successfully established.

[0077] In another embodiment, when the host device 110 issues a namespace management command 732 to establish a namespace, the namespace management command 732 includes a namespace identification code, for example: 0x00. During the namespace establishment operation 740, the storage device 130 establishes namespace #0 according to the namespace management command 732.

[0078] After namespace #0 is successfully established, host device 110 may issue a namespace attach command 752 to storage device 130 to attach namespace #0 to one or more controllers. Host device 110 may indicate in bits 0 through 3 of the 10th double word that this command requests a controller attach operation. After storage device 130 successfully executes namespace attach operation 760, host device 110 may receive an execution result 754 from storage device 130, including information indicating that namespace #0 was successfully attached.

[0079] After successfully establishing namespace #0 and attaching namespace #0 to the controller, the host device 110 begins data access 780 in namespace #0, such as reading user data at a specific logical block address in namespace #0 or writing user data at a specific logical block address in namespace #0.

[0080] refer to Figure 8 The host device 110 may issue a namespace attach command 812 to the storage device 130 to detach namespace #0 from a specific controller. The host device 110 may indicate in bits 0 to 3 of the 10th double word that this command requests a controller detach operation. After the storage device 130 successfully executes the namespace detach operation 820, the host device 110 may receive an execution result 814 from the storage device 130, including information indicating that namespace #0 was successfully detached.

[0081] After all dependencies of namespace #0 to a specific controller have been successfully released, host device 110 may issue a namespace management command 832 to storage device 130 to delete namespace #0. Host device 110 may indicate in namespace management command 832 that this is a delete operation (e.g., bits 0 to 3 of the 10th double word) and provide the namespace identifier of the namespace to be deleted (e.g., the 1st double word), for example, the value 0x00 corresponding to namespace #0. After storage device 130 successfully executes delete operation 840 for namespace #0, host device 110 may receive an execution result 834 from storage device 130, including information indicating that the deletion of namespace #0 was successful.

[0082] However, once a namespace is created and attached, there is currently no mechanism for adjusting the length or capacity of the established namespace, resulting in the host device 110 being unable to increase the length or capacity of the namespace. For example, if storage device 130 has 1TB of available space and namespace #0 only occupies 64GB, the host device 110 cannot increase the length or capacity of the 64GB namespace to 128GB. To address this limitation, embodiments of the present invention provide a namespace configuration update mechanism that allows the host device 110 to increase the length or capacity of the namespace.

[0083] refer to Figure 9. Taking namespace #0 as an example, after namespace #0 is established and attached, the main device 110 can issue a namespace setting update command 912 to the storage device 130 to request to increase the length or capacity of namespace #0. In addition to issuing the namespace setting update command 912, the main device 110 can also allocate 4K bytes in the random access memory 120 to store the contents of the updated data structure of namespace #0, where bytes 0 to 383 are used to define the namespace field. For example, bytes 0 to 7 are the namespace length field, which can be filled with the updated namespace length value, such as: 0x1FFFFFF (in logical blocks). Bytes 8 to 15 are the namespace capacity field, which can be filled with the updated namespace capacity value, such as: 0x1FFFFFF. Generally speaking, the namespace length is equal to the namespace capacity value. However, when the host device 110 wishes to over-provision space as a buffer for data migration or other operations, the updated namespace capacity value, for example, 0x1FFFF00, may be smaller than the updated namespace length value. In some embodiments, except for the namespace length field and the namespace length field, each remaining byte of the updated namespace data structure may be set to a dummy value (e.g., 0x00, 0xFF, or other predetermined value). Therefore, the storage device 130 may ignore these dummy values.

[0084] The format of the namespace setting update command 912 is as follows Figure 10 As shown. Namespace setup update command 912 is a 64-byte command. Byte 0 of double word 0 records an operation code (opcode) 1010, which is used to notify storage device 130 that this is a namespace management command. Bytes 2 and 3 of double word 0 record a command identification code 1030. This command identification code 1030 is preferably generated sequentially and serves as a basis for identifying namespace setup update command 912. It is also used to associate a corresponding completion element in completion queue 530 with namespace setup update command 912. Double word 1 records an identification code 1080 of namespace #0 to be updated, which has a value of 0x00. The host device 110 can indicate that this is an update operation in the option field 1070 of bits 0 to 3 in double word 10. The host device 110 provides a starting address pointing to the updated namespace data structure stored in the random access memory 120 in the main memory address field 1050 of the 6th to 7th double words, or in the main memory address field 1050 and the extended memory address field 1060 of the 6th to 9th double words, so that the storage unit 130 can obtain the updated namespace length and capacity from the random access memory 120 according to the memory address.

[0085] Although the host device 110 uses the random access memory 120 to store the namespace length or capacity for reading by the storage device 130, in other embodiments, the host device 110 may directly provide information such as the updated namespace length or capacity value in the namespace configuration update command 912. This avoids occupying RAM 120 space, conserves transmission bandwidth between the host device 110 and the storage device 130, and further accelerates the execution of the namespace configuration update command 912. For example, the updated namespace length value may be stored in the primary memory address field 1050, or the updated namespace capacity value may be stored in the extended memory address field 1060.

[0086] In another embodiment, the operation code 1010 indicates that this is the namespace setting update command 912, and in this case, the option field 1080 can be omitted.

[0087] Furthermore, before issuing the namespace management command 912 to the storage device 130, the host device 110 may first issue an identify command 712 to the storage device 130 to obtain the original data structure of namespace #0. Based on the original data structure, the host device 110 may adjust necessary parameters, including the namespace length or capacity, to serve as the updated data structure of namespace #0. Alternatively, the host device 110 may issue a general namespace identify command to obtain the general namespace length or capacity, using this value as the maximum logical block value. Subsequently, by sequentially obtaining the namespace length or capacity value of each established namespace, the value of the unallocated logical blocks may be determined. In this manner, the host device 110 may add the value of some or all of the unallocated logical blocks to the namespace length or capacity value of namespace #0 to serve as the updated namespace length or capacity value of namespace #0.

[0088] The namespace setting update operation 920 is preferably executed by the processing unit 133 with a higher priority. The details of the namespace setting update operation 920 are as follows: Figure 11 The processing unit 133 may obtain the namespace configuration update command 912 from the submission queue 510 (step S1110), and obtain the updated namespace length or capacity according to the namespace configuration update command 912 (step S1120), wherein the updated namespace length or capacity may be obtained from the content of the namespace configuration update command 912 or from a data structure stored at a specified memory address.

[0089] Next, the processing unit 133 determines whether the updated namespace length or capacity can be supported (step S1130). The processing unit 133 may add the updated namespace length or capacity to the namespace lengths or capacities of all other namespaces, and then determine whether the updated namespace length or capacity exceeds the maximum logical block size, or whether the difference between the updated namespace length or capacity and the original namespace length or capacity is less than the value of unallocated logical blocks.

[0090] If it is determined that the updated namespace length or capacity cannot be supported ("No" path in step S1130), the processing unit 133 may write a completion component including an execution failure message to the completion queue 530 (step S1170). Otherwise ("Yes" path in step S1130), the processing unit 133 may store the updated namespace length or capacity of the namespace in the random access memory 131 and / or the storage unit 139 (step S1140).

[0091] The processing unit 133 updates the logical-physical lookup table for this namespace (step S1150). Generally, the logical-physical lookup table can be divided into multiple sub-logical-physical lookup tables. Therefore, the processing unit 133 can update the number of sub-logical-physical lookup tables to update the logical-physical lookup table. Alternatively, the processing unit 133 can pre-create the sub-logical-physical lookup tables or wait until they are needed to access them. The processing unit 133 writes a completion component containing execution success information to the completion queue 530 (step S1160).

[0092] refer to Figure 12 . Assuming that the original length or capacity of the namespace (before update) is 64GB, the processing unit 133 establishes a logical-physical reference table 1210 to store the correspondence information between the logical block addresses 0x0000000 to 0x0FFFFFF and the physical addresses to manage 64GB of user data. When the storage device 130 receives a request for a namespace setting update command 912 issued by the host device 110, for example: to increase the length or capacity of this namespace to 128GB, the processing unit 133 can add a new logical-physical reference table 1230 after the original logical-physical reference table 1210 to extend the logical block address from 0x0FFFFFF to 0x1FFFFFF to manage 128GB of user data. The physical address information of each entry in the logical-physical correspondence table 1230 can be first filled with a dummy value (such as 0x00000000, 0xFFFFFFFF, or others), or the logical-physical correspondence table 1230 can be established when the host device 110 accesses the logical block address 0x1000000 to 0x1FFFFFF.

[0093] The method steps of the namespace setting update operation 920 performed by the processing unit 133 can be implemented by a computer program product composed of one or more functional modules. These functional modules are stored in a non-volatile storage device and can be loaded and executed by the processing unit 133 at a specific time point. Figure 13 The processing unit 133 executes the namespace setting reading module 1310 to complete the operations of steps S1110 and S1120, executes the determination module 1320 to complete the operation of step S1130, executes the namespace length or capacity expansion module 1330 to complete the operations of steps S1140 and S1150 when the determination of the determination module 1320 is not satisfied, and executes the component writing module 1340 to complete the operations of steps S1160 and S1170. The namespace setting reading module 1310 may include an NVMe interface driver and an NVMe command parser for receiving commands from the host device 110 and identifying the types of commands and requested operations, as well as a driver for a direct memory access controller (DMA controller) for reading the updated length and capacity of a specific namespace from the random access memory 120. The namespace length or capacity expansion module 1330 may include a driver for the flash memory controller 135, configured to write the updated length and capacity of a specific namespace to the storage unit 139 via the access interface 137. The completion component writing module 1340 may include a driver for the NVMe interface and code for generating an NVMe completion component, configured to generate a completion component and notify the host device 110 that the completion component has been written, as well as a driver for the direct memory access controller, configured to write the completion component to a completion queue in the random access memory 120.

[0094] Furthermore, there is currently no cross-namespace data migration mechanism. For example, to migrate user data from namespace #0 to namespace #1, host device 110 needs to issue a series of read commands from namespace #0 to storage device 130 to read the user data and store it in the data buffer of random access memory 120. Then, host device 110 issues a series of deallocate commands from namespace #0 to storage device 130 to delete the user data. Host device 110 then issues a series of write commands from namespace #1 to storage device 130 to write the user data in the data buffer to namespace #1. However, using the read, deallocate, and write commands described above to complete cross-namespace data migration consumes a significant amount of queue space to store the series of read, deallocate, and write commands and completion components. Furthermore, random access memory 120 consumes significant bandwidth to transmit data read from storage unit 139 and data to be written to storage unit 139, as well as significant space to store data read from storage unit 139. In addition, the host device 110 and the processing unit 133 also need to consume a large amount of computing resources to process this series of read and write commands, which will make the storage device 130 unable to maintain appropriate computing resources to respond to the data access commands of the host device 110 in a timely manner, resulting in low system performance of the storage device 130.

[0095] To solve the above problems, refer to Figure 14 After the namespace is established and attached, the host device 110 may issue a cross-namespace data migration command 1412 to the storage device 130 to instruct the storage device 130 to migrate user data of a source logical block address of a source namespace, such as namespace #0, to a destination logical block address of a destination namespace, such as namespace #1, by internal migration, wherein the values of the source logical block address and the destination logical block address may be the same or different.

[0096] refer to Figure 15The cross-namespace data migration command 1412 is a 64-byte command. The 0th byte of the 0th double word records the operation code 1510, which is used to notify the storage device 130 that this is a cross-namespace data migration command. The 2nd and 3rd bytes of the 0th double word record the command identification code 1530. This command identification code 1530 is preferably generated in sequence and serves as the basis for identifying the cross-namespace data migration command 1412. It is also used to associate a corresponding completion component in the completion queue 530 with the cross-namespace data migration command 1412. The 1st double word records the identification code 1580 of the destination namespace, and the 6th and 7th double words record the starting destination logical block number 1550. The 2nd double word records the identification code 1590 of the source namespace, and the 10th and 11th double words record the starting source logical block number 1560. The 0th to 1st bytes of the 12th double word record the migration quantity 1570. The starting source logical block number 1560 and the migration amount 1570 define a continuous logical block address segment in the source namespace, and the starting destination logical block number 1550 and the migration amount 1570 define a continuous logical block address segment in the destination namespace.

[0097] The details of the cross-namespace data migration operation 1420 are as follows: Figure 16The cross-namespace data migration operation 1420 can be performed by the processing unit 133 when the relevant firmware is loaded and executed. The processing unit 133 can obtain the cross-namespace data migration command 1412 from the submission queue 510, requesting that the user data at the specified logical block address of the source namespace be migrated to the storage space at the specified logical block address of the destination namespace (step S1610). Next, the processing unit 133 starts to cut (or first copies and then deallocates after the copy is completed) a specified amount of physical address information from the starting source entry (i.e., the entry indicated by the starting source logical block number 1560) in the source logical-physical mapping table (i.e., the logical-physical mapping table corresponding to the source namespace identification code 1590) (step S1620), and sequentially stores the cut physical address information starting from the starting destination entry (i.e., the entry indicated by the starting destination logical block number 1550) in the destination logical-physical mapping table (i.e., the logical-physical mapping table corresponding to the destination namespace identification code 1580) (step S1630). Before step S1620, the processing unit 133 may drive the flash memory controller 135 to read the corresponding portion of the source logical-physical correspondence table and the destination logical-physical correspondence table from the storage unit 139 and store them in the random access memory 131. The cut and paste operations in steps S1620 and S1630 may update the data in the random access memory 131. After step S1630, the processing unit 133 may drive the flash memory controller 135 to write the updated portion of the source logical-physical correspondence table and the destination logical-physical correspondence table to the storage unit 139. Finally, the processing unit 133 may write a completion component containing execution success information to the completion queue 530 (step S1640). Figure 16 The described method flow does not involve any actual movement of user data, and thus can effectively solve the above-mentioned problems.

[0098] For example, the main device 110 can be configured with two namespaces to store confidential and non-confidential data respectively, which can be called a confidential namespace (Confidential Namespace) and a public namespace (Public Namespace). The access rights or qualifications of the confidential namespace are preferably determined by the main device 110. For example, the main device 110 only allows accounts belonging to the confidential group to access user data in the confidential namespace, while the public namespace allows accounts of general users to access user data therein. When some confidential data is changed to public data, the main device 110 can migrate this data from the confidential namespace to the public namespace. This application can use the cross-naming area data migration mechanism described above. Reference Figure 13Assuming that the cross-namespace data migration command 1412 instructs to change the user data of the logical block addresses #1 to #2 of namespace #0 to the user data of the logical block addresses #3 to #4 of namespace #1, the processing unit 133 cuts the physical address information recorded in the first and second items in the logical-physical reference table 1710 (corresponding to namespace #0) and stores it in the third and fourth items in the logical-physical reference table 1730 (corresponding to namespace #1).

[0099] The method steps of the cross-namespace data migration operation 1420 performed by the processing unit 133 can be implemented using a computer program product composed of one or more functional modules. These functional modules are stored in a non-volatile storage device and can be loaded and executed by the processing unit 133 at a specific time point. Figure 18 . The processing unit 133 executes the cross-namespace data migration command reading module 1810 to complete the operation of step S1610, executes the logical-physical reference table update module 1820 to complete the operations of steps S1620 and S1630, and executes the component writing module 1830 to complete the operation of step S1640. The cross-namespace data migration command reading module 1810 may include an NVMe interface driver and an NVMe command parser for receiving commands from the main device 110 and identifying the type of command and request operation. The logical-physical reference table update module 1820 may include a driver for the flash memory controller 135 to read the corresponding parts of the source logical-physical reference table and the destination logical-physical reference table from the storage unit 139 through the access interface 137 and write the updated physical address information to the storage unit 139. The completion component write module 1830 may include a driver for the NVMe interface and a program code for generating an NVMe completion component, which is used to generate a completion component and notify the host device 110 that the completion component has been written, and a driver for the direct memory access controller, which is used to write the completion component to the completion queue in the random access memory 120.

[0100] All or part of the steps in the method described in the present invention can be implemented in a computer program, such as an operating system of a computer, a driver for specific hardware in a computer, or a software program. In addition, it can also be implemented in other types of programs as shown above. A person with ordinary knowledge in the art can write the method of the embodiment of the present invention into a computer program, which will not be described again for the sake of simplicity. The computer program implemented according to the method of the embodiment of the present invention can be stored in an appropriate computer-readable data carrier, such as a DVD, CD-ROM, USB disk, hard disk, or can also be placed on a network server that can be accessed through a network (e.g., the Internet, or other appropriate carrier).

[0101] Although Figure 1The components described above are included, but it is not excluded that more additional components may be used to achieve better technical effects without violating the spirit of the invention. Figure 11 and 16 The flowchart is executed in the specified order. However, those skilled in the art may modify the order of these steps without violating the spirit of the invention, provided that the same effect is achieved. Therefore, the present invention is not limited to the sequence described above. Furthermore, those skilled in the art may also combine several steps into one step, or perform more steps sequentially or in parallel in addition to these steps, and the present invention is not limited thereto.

[0102] While the present invention is described using the above embodiments, it should be noted that these descriptions are not intended to limit the present invention. On the contrary, the present invention encompasses modifications and similar arrangements that are obvious to those skilled in the art. Therefore, the scope of the claims should be interpreted in the broadest manner to encompass all obvious modifications and similar arrangements.

Claims

1. A namespace operation method for a flash memory storage device, executed by a processing unit of the storage device, characterized in that: Include: Reading a first logical-physical comparison table corresponding to a first namespace, wherein the first logical-physical comparison table stores physical information corresponding to a logical address in the first namespace; Reading a second logical-physical correspondence table corresponding to a second namespace, wherein the second logical-physical correspondence table stores physical information corresponding to logical addresses in the second namespace; receiving a cross-namespace data migration command from a host device, requesting migration of user data at a first logical address in the first namespace in a storage unit of the storage device to a second logical address in the second namespace, wherein the user data at the first logical address in the first namespace is stored in a physical address of the storage unit; as well as In response to the cross-namespace data migration command, the user data of the first logical address of the first namespace is not migrated, the physical address information corresponding to the first logical address is deleted from the first logical-physical comparison table corresponding to the first namespace, and the physical address information is stored in the item corresponding to the second logical address in the second logical-physical comparison table corresponding to the second namespace, wherein the physical address information describes the physical address of the storage unit storing the user data, and the user data stored in the physical address of the storage unit remains unchanged.

2. The namespace operation method of the flash memory storage device according to claim 1, wherein: The first logical address represents a continuous first logical block address, and the second logical address represents a continuous second logical block address.

3. The namespace operation method of the flash memory storage device according to claim 1, wherein: The cross-namespace data migration command includes a first namespace identification code, a second namespace identification code, a first logical block number, a second logical block number, and a migration quantity, wherein the first namespace identification code represents the first namespace, the second namespace identification code represents the second namespace, the first logical block number and the migration quantity define the first logical address, and the second logical block number and the migration quantity define the second logical address.

4. The namespace operation method of the flash memory storage device according to claim 1, wherein: The first namespace is a confidential namespace and the second namespace is a public namespace, or the first namespace is the public namespace and the second namespace is the confidential namespace.

5. The namespace operation method of the flash memory storage device according to claim 4, wherein: The confidential namespace only allows accounts belonging to a confidential group to access data, and the public namespace allows accounts with general users to access data.

6. A computer-readable storage medium for storing program code that can be executed by a processing unit, characterized in that: When the program code is executed by the processing unit, the namespace operation method of the flash memory storage device according to any one of claims 1 to 5 is implemented.

7. A namespace operation device for a flash memory storage device, comprising: a flash memory controller coupled to the storage unit; as well as A processing unit coupled to the flash memory controller for driving the flash memory controller to Reading a first logical-physical comparison table and a second logical-physical comparison table, the first logical-physical comparison table corresponding to the first namespace and the second logical-physical comparison table corresponding to the second namespace, wherein the first logical-physical comparison table stores physical information corresponding to logical addresses in the first namespace and the second logical-physical comparison table stores physical information corresponding to logical addresses in the second namespace; receiving a cross-namespace data migration command from the host device, requesting migration of user data at a first logical address in the first namespace in the storage unit to a second logical address in the second namespace; And when responding to the cross-namespace data migration command, the user data of the first logical address of the first namespace is not migrated, the physical address information corresponding to the first logical address is deleted from the first logical-physical comparison table corresponding to the first namespace, and the physical address information is stored in the item corresponding to the second logical address in the second logical-physical comparison table corresponding to the second namespace, wherein the physical address information describes the physical address of the storage unit storing the user data, and the user data stored in the physical address of the storage unit remains unchanged.

8. The namespace operation device of the flash memory storage device according to claim 7, wherein: The first logical address represents a continuous first logical block address, and the second logical address represents a continuous second logical block address.

9. The namespace operation device of the flash memory storage device according to claim 7, wherein: The cross-namespace data migration command includes a first namespace identification code, a second namespace identification code, a first logical block number, a second logical block number, and a migration quantity, wherein the first namespace identification code represents the first namespace, the second namespace identification code represents the second namespace, the first logical block number and the migration quantity define the first logical address, and the second logical block number and the migration quantity define the second logical address.

10. The namespace operation device of the flash memory storage device according to claim 7, wherein: The first namespace is a confidential namespace and the second namespace is a public namespace, or the first namespace is the public namespace and the second namespace is the confidential namespace; the confidential namespace only allows accounts belonging to a confidential group to access data; and the public namespace allows accounts of general users to access data.

Images