NVMe SSD multi-namespace management method and device, equipment and medium

Abstract

The invention discloses an NVMe SSD multi-namespace management method and device, equipment and a medium, and relates to the technical field of SSDs. The method comprises the following steps: dividing a total logic address space of the SSD into a preset number of static logic address groups, wherein each static logic address group has a continuous logic page address range with a preset size; a dynamic logic address group pool is reserved, the dynamic logic address group pool comprises a plurality of dynamic logic address groups, and the dynamic logic address group pool is used for absorbing fragment space generated by namespace operation; and in response to a creation instruction of the namespace, dynamically combining logical address groups to form an address range of the namespace, and triggering the dynamic logical address group pool to absorb and merge the fragmented space, the logical address groups including a static logical address group and a dynamic logical address group. According to the method, the problem of resource waste caused by storage fragmentation in a traditional scheme can be solved, and the utilization rate of the storage space is remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of SSD technology, and in particular to a method, apparatus, device, and medium for managing multiple namespaces of an NVMe SSD. Background Art

[0002] NVMe SSDs are high-performance storage devices. Multi-namespace technology divides the physical storage space of SSDs into multiple independent logical units, enabling each namespace to independently configure storage capacity and access control policies, thereby improving the isolation and management flexibility of storage resources.

[0003] However, in practice, due to the random nature of dynamic namespace allocation and deletion, frequent adjustments can cause the unoccupied logical address space to become fragmented, forming multiple, dispersed, and non-contiguous address blocks. Traditional namespace management architectures require newly created namespaces to occupy contiguous logical address space, limiting the system to selecting only the largest contiguous address block as the target area during allocation.

[0004] This mechanism suffers from a fundamental flaw: when the logical address space accumulates multiple non-contiguous fragments due to historical operations, the actual allocatable capacity of the new namespace is limited by the size of the largest single fragment, even if the sum of all the fragmented spaces is significantly larger than the available capacity. This results in a significant amount of available storage space being left unused because it cannot be consolidated. For example, if the logical space of an SSD contains several non-contiguous address blocks, attempts to create a namespace larger than the maximum fragment size will inevitably fail, even if the total capacity of the remaining fragments is sufficient to meet the required capacity.

[0005] The root cause of this resource waste caused by storage fragmentation lies in the conflict between the inevitability of fragmentation under dynamic operations and the rigid constraints of traditional contiguous allocation mechanisms. As the frequency of namespace operations increases, fragmentation continues to intensify, not only causing a substantial reduction in physical storage capacity but also severely limiting users' ability to configure storage on demand. Summary of the Invention

[0006] Embodiments of the present invention provide a method, apparatus, device, and medium for managing multiple NVMe SSD namespaces, aiming to solve at least one technical problem in the above-mentioned background technology.

[0007] In a first aspect, an embodiment of the present invention provides a method for managing multiple namespaces of an NVMe SSD, comprising:

[0008] Dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size;

[0009] A dynamic logical address group pool is reserved, where the dynamic logical address group pool includes multiple dynamic logical address groups and is used to absorb fragmented space generated by namespace operations;

[0010] In response to a namespace creation instruction, logical address groups are dynamically combined to form an address range of the namespace, and the dynamic logical address group pool is triggered to absorb and merge fragmented space. The logical address groups include static logical address groups and dynamic logical address groups.

[0011] A further technical solution is that the number of the dynamic logical address group pools is configured as follows:

[0012] The number of dynamic logical address groups = the maximum number of namespaces supported by the system - 1.

[0013] A further technical solution is that the method further comprises:

[0014] Establish a mapping management structure from namespace to logical address group;

[0015] The allocation relationship between the namespace and the static logical address group and the dynamic logical address group is maintained in the mapping management structure.

[0016] A further technical solution is that the mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to the namespace identifier, and the column dimension of the mapping table stores the logical address group number assigned to the namespace.

[0017] A further technical solution is that the address allocation during namespace creation includes:

[0018] Calculate the required number of logical address groups based on the requested capacity;

[0019] Static logical address groups are allocated first, and the insufficient part is supplemented by dynamic logical address groups;

[0020] When the static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

[0021] A further technical solution is that space recovery when a namespace is deleted includes:

[0022] Release all logical address groups occupied by the namespace;

[0023] Triggers automatic space merging of adjacent dynamic logical address groups to form larger contiguous free blocks.

[0024] A further technical solution is that the method further comprises:

[0025] The namespace access request is directly parsed by the SSD controller, and based on the mapping management structure, a calculation operation of the physical address being equal to the logical address group base address plus the request offset is performed to determine the accessed physical address.

[0026] In a second aspect, an embodiment of the present invention further provides a management device for NVMe SSD multiple namespaces, which includes a unit for executing the above method.

[0027] In a third aspect, an embodiment of the present invention further provides a computer device, which includes a memory and a processor, wherein a computer program is stored in the memory, and the processor implements the above method when executing the computer program.

[0028] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the storage medium stores a computer program, and the computer program can implement the above method when executed by a processor.

[0029] An embodiment of the present invention provides a method, apparatus, device, and medium for managing multiple namespaces of an NVMe SSD. The method includes: The embodiment of the present invention proposes a method for managing multiple namespaces of an NVMe SSD, comprising: dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size; reserving a dynamic logical address group pool, the dynamic logical address group pool comprising multiple dynamic logical address groups, the dynamic logical address group pool being used to absorb fragmented space generated by namespace operations; in response to a namespace creation instruction, dynamically combining logical address groups to form an address range of the namespace, and triggering the dynamic logical address group pool to absorb and merge the fragmented space, the logical address groups comprising static logical address groups and dynamic logical address groups. This invention divides the total logical address space of an SSD into a preset number of static logical address groups, each of which provides a contiguous logical page address range of a predetermined size, laying a structured resource foundation for namespace allocation. A dynamic logical address group pool is also reserved to absorb the fragmented space generated by namespace operations. This allows the system to dynamically combine multiple logical address groups (both static and dynamic) to form the namespace address range in response to namespace creation instructions. For example, when creating a 31GB namespace, the system can combine one complete static logical address group (32GB) with one dynamic logical address group to absorb the remaining 1GB of space, breaking the limitation of traditional solutions that namespaces must occupy contiguous address blocks. This collaborative mechanism of dynamic and static address groups fundamentally solves the storage fragmentation problem caused by the frequent creation and deletion of namespaces. The dynamic logical address group pool absorbs the fragmented space in real time and participates in the reorganization, transforming unused scattered address blocks into valid resources. The technical effect is directly reflected in the storage space utilization rate approaching 100%, while maintaining the logical continuity of the namespace address range, ensuring that subsequent access performance is not degraded. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0031] Figure 1 A schematic diagram of a flow chart of a method for managing multiple NVMe SSD namespaces provided by an embodiment of the present invention;

[0032] Figure 2 A schematic diagram of SSD address space division provided by an embodiment of the present invention;

[0033] Figure 3A schematic diagram of a mapping table provided in an embodiment of the present invention;

[0034] Figure 4 A schematic diagram illustrating the configuration status of the SSD internal storage allocation and the corresponding namespace array after the namespace is created according to an embodiment of the present invention;

[0035] Figure 5 A schematic diagram illustrating the configuration status of the SSD internal storage allocation and the corresponding namespace array after namespace deletion according to an embodiment of the present invention;

[0036] Figure 6 A schematic diagram showing the query process from host read and write commands to SSD internal mapping addresses after namespace creation.

[0037] Figure 7 A schematic block diagram of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0038] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0039] It will be understood that when used in this specification and the appended claims, the terms “comprises” and “comprising” indicate the presence of described features, integers, steps, operations, elements and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0040] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the present invention. As used in the specification and appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms unless the context clearly indicates otherwise.

[0041] It should be further understood that the term "and / or" used in the present description and the appended claims refers to and includes any and all possible combinations of one or more of the associated listed items.

[0042] As used in this specification and the appended claims, the term "if" can be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0043] See also Figure 1 An embodiment of the present invention provides a method for managing multiple namespaces of an NVMe SSD, the method comprising the following steps:

[0044] S1 , dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size.

[0045] In a specific implementation, the total logical address space of the SSD is divided into a preset number of static logical address groups. Each static logical address group provides a continuous logical page address range of a predetermined size, laying a structured resource foundation for namespace allocation.

[0046] See also Figure 2 Taking a 4TB SSD as an example, the total logical address space size of a 4TB SSD is 3816GB (IDEMA specification), which is divided into 120 static logical address groups with a 32GB LPA Group size.

[0047] S2, reserve a dynamic logical address group pool, the dynamic logical address group pool includes multiple dynamic logical address groups, and the dynamic logical address group pool is used to absorb fragmented space generated by namespace operations.

[0048] In the specific implementation, a dynamic logical address group pool is reserved to absorb the fragmented space generated by the namespace operation, so that the system can dynamically combine multiple logical address groups (including static and dynamic) to form the address range of the namespace when responding to the namespace creation instruction.

[0049] In some preferred embodiments, the number of the dynamic logical address group pools is configured as follows: number of dynamic logical address groups = maximum number of namespaces supported by the system - 1.

[0050] For example, see Figure 2 Taking the need to support a maximum of 16 namespaces as an example, 15 dynamic logical address groups are reserved, and the total number of LPA groups is 135.

[0051] In an embodiment of the present invention, the number of dynamic logical address group pools is configured to be the maximum number of namespaces supported by the system minus 1. The essence of this is to optimize resource allocation through mathematical relationship constraints. For example, 15 dynamic logical address groups are configured when a maximum of 16 namespaces are supported. This is due to the coverage of the worst-case scenario: when the system has 15 namespaces and each generates fragments, each dynamic logical address group can independently absorb the corresponding fragments; and when the 16th namespace is created, there is no need to add a new dynamic group because it can directly occupy the last continuous space. This rule ensures that the capacity of the dynamic logical address group pool accurately matches the system's extreme requirements, avoiding both resource waste (such as increased management overhead due to configuring too many dynamic groups) and resource shortages (such as inability to fully absorb fragments when too few are configured). This deterministic design based on the maximum number of namespaces enables the storage system to maintain a stable fragment recovery capability during long-term operation, eliminating the risk of fragment accumulation from a mechanism perspective.

[0052] In some preferred embodiments, the method further includes: establishing a mapping management structure from namespace to logical address group; and maintaining the allocation relationship between the namespace and the static logical address group and the dynamic logical address group in the mapping management structure.

[0053] In a specific implementation, by establishing a mapping management structure from namespace to logical address group, and maintaining the allocation relationship between namespace and dynamic and static logical address groups in the structure, a flexible scheduling capability of the software layer for physical storage resources is constructed. The mapping management structure introduced by the present invention enables the system to dynamically record the discrete logical address groups actually occupied by the namespace (for example, namespace A occupies static group 1 and dynamic group 3). This design converts the fragmented distribution of physical storage into a continuous mapping of the logical layer. When users access the namespace, they only need to operate a single continuous address space without having to perceive the distribution status of the underlying address group. More importantly, this structure converts namespace creation and deletion operations into updates to mapping relationships rather than physical data movement, greatly reducing management overhead. For example, when deleting a namespace, it is only necessary to release the mapping relationship and trigger the dynamic logical address group to absorb the space, which is several orders of magnitude more efficient than traditional physical organization.

[0054] In some preferred embodiments, the mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to a namespace identifier, and the column dimension of the mapping table stores a logical address group number assigned to the namespace.

[0055] In the specific implementation, see Figure 3is an example of a mapping table. In the present invention, a mapping table is used as a specific implementation of the mapping management structure, in which the row dimension corresponds to the namespace identifier and the column dimension stores the assigned address group number, thereby realizing efficient management of non-contiguous address groups. The architecture with the namespace ID as the row index supports directly locating all the logical address groups occupied by the namespace identifier (such as querying the 3rd row to obtain the address group list of namespace 3); and the design of storing the address group number in the column dimension allows a single namespace to be associated with multiple non-contiguous address groups (such as column 1 stores static group 5 and column 2 stores dynamic group 2). This row-column structure improves the search efficiency of fragmented address groups from O(n) of the traditional linked list to O(1), which is particularly advantageous in large-scale namespace scenarios. For example, when the host sends an access request for namespace 5, the controller instantly obtains the distribution of all its address groups through the row index 5, and then quickly calculates the physical address in combination with the column data, completely avoiding the performance bottleneck of traversal query.

[0056] S3, in response to the namespace creation instruction, dynamically combine logical address groups to form the address range of the namespace, and trigger the dynamic logical address group pool to absorb and merge the fragmented space, the logical address groups include static logical address groups and dynamic logical address groups.

[0057] In specific implementation, when the system responds to a namespace creation instruction, it can dynamically combine static logical address groups and dynamic logical address groups to form a continuous address range of the namespace, and trigger the dynamic logical address group pool to absorb and merge fragmented space in real time.

[0058] In the present invention, the static logical address group provides the ability to allocate large-scale continuous address blocks to ensure the basic performance of the namespace; the dynamic logical address group pool acts as an elastic buffer to continuously absorb the address space remnants that are not fully utilized when the namespace is created (such as the partially occupied static group remaining area) and the discrete address blocks released after the namespace is deleted, thereby converting the fragmented space that cannot be used in traditional solutions into reconfigurable resources.

[0059] In some preferred embodiments, address allocation during namespace creation includes: calculating the required number of logical address groups based on the requested capacity; allocating static logical address groups first, and making up the shortfall with dynamic logical address groups; when a static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

[0060] In specific implementation, static logical address groups are prioritized when a namespace is created, with any shortfalls made up by dynamic logical address groups. When a partial static group is allocated, the remaining space is absorbed by the dynamic group, forming a hierarchical resource scheduling strategy. This strategy ensures basic performance through static logical address groups (due to their continuity and physical mapping stability), while dynamic logical address groups act as a flexible supplement to absorb irregular demands. For example, when a 35GB namespace is requested, a full static group (32GB) is prioritized, with the remaining 3GB being made up by the dynamic group. If only 31GB is required, the static group provides 32GB of space, and the remaining 1GB is absorbed in real time by the dynamic group. This three-tiered mechanism of "static priority + dynamic supplementation + fragmentation recovery" maximizes the performance advantages of static groups while enabling fine-grained resource segmentation and reuse through dynamic groups, ensuring that namespace requests of any size can be met without wasting space.

[0061] For example, see Figure 4 , take the creation of four namespaces as an example to illustrate:

[0062] Step 1: Create namespace 1 with a size of 1 GB. The SSD internally allocates LPA Group 0 to namespace 1 and generates dynamic LPA Group 120, with a usable effective space of 31 GB.

[0063] Step 2: Create namespace 2 with a size of 2 GB. LPA Group 0 is allocated to namespace 2 internally on the SSD. The available size of LPA Group 120 is adjusted to 32 GB, creating dynamic LPA Group 121 with an effective available space of 29 GB.

[0064] Step 3: Create namespace 3 with a size of 3752 GB. At this time, the SSD internally allocates LPA Groups 0-119 to namespace 3.

[0065] Step 4: Create namespace 4 with a size of 31 GB. At this time, the SSD internally allocates LPA Group 120 to namespace 4 and adjusts the size of LPA Group 121 to 30 GB to absorb the remaining 1 GB of space after LPA Group 120 is allocated.

[0066] In some preferred embodiments, space reclamation upon namespace deletion includes: releasing all logical address groups occupied by the namespace; and triggering automatic space merging of adjacent dynamic logical address groups to form a larger continuous available block.

[0067] In a specific implementation, when a namespace is deleted, all occupied logical address groups are released and the automatic space merging of adjacent dynamic logical address groups is triggered, thereby building a real-time self-healing capability for fragmented space. In the traditional solution, deleting a namespace simply releases the space, and the fragments still exist independently; however, the present invention requires that the merging operation of adjacent dynamic groups be triggered immediately after the release (such as when the static group 5 occupied by the namespace is released, its adjacent dynamic group 2 and dynamic group 7 automatically merge their space), so that the scattered fragments are reorganized into larger continuous blocks. For example, when two 5GB fragments are absorbed by different dynamic groups, if their physical addresses are adjacent, the deletion operation will trigger the two to be merged into 10GB of continuous space. This dynamic group merging mechanism blocks the vicious cycle of fragmentation from the root, ensuring that the system can still provide large blocks of continuous space after long-term operation, and avoiding the performance degradation problem of traditional SSDs caused by fragment accumulation.

[0068] For example, see Figure 5 For example, when namespaces 2 and 4 are deleted, LPA Group 1 absorbs 32 GB of space, and LPA Group 128 absorbs the remaining 1 GB. In this state, the host can recreate a 33 GB namespace.

[0069] In some preferred embodiments, the method further includes: directly parsing the namespace access request through the SSD controller, and performing a calculation operation based on the mapping management structure: the physical address is equal to the logical address group base address plus the requested offset to determine the accessed physical address.

[0070] In specific implementations, the SSD controller hardware directly parses namespace access requests and performs the calculation operation of "physical address = logical address group base address + request offset" based on the mapping management structure, achieving hardware-level acceleration of the storage access path. This design converts traditional table lookup calculations that require software participation (such as traversing the mapping table to obtain the address group base address and then adding the offset) into a direct completion by the controller hardware circuit: the namespace ID in the access request is input into the row index circuit to obtain the address group base address, and the offset and base address are output in real time through the adder circuit. For example, when processing a request for LBA = 0x8000 in namespace 3, the hardware queries the address group base address of namespace 3 in parallel (such as 0xC000_0000), and then calculates 0xC000_0000 + 0x8000 to obtain the physical address. This hardware pass-through architecture eliminates the microsecond delay caused by software table lookup, making read and write performance completely unaffected by the degree of namespace fragmentation, which is particularly groundbreaking for low-latency application scenarios.

[0071] For example, see Figure 6Taking the read command with NSID = 3 and LBA = 0x4001234 as an example, the following description is provided: 0x4001234 / 0x4000000 calculates unit[1], reads unit[1] corresponding to namespace 3, obtains Group LPA 3, calculates 3*0x4000000 (32GB) + 0x1234, and obtains the SSD internal mapping LPA address 0xC001234. The host can then read the required data through subsequent mapping lookups. To accelerate the processing of read and write commands, the query process is implemented by the SSD controller.

[0072] An embodiment of the present invention proposes a method for managing multiple namespaces of an NVMe SSD, comprising: dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size; reserving a dynamic logical address group pool, the dynamic logical address group pool including multiple dynamic logical address groups, the dynamic logical address group pool being used to absorb fragmented space generated by namespace operations; dynamically combining logical address groups to form an address range of the namespace in response to a namespace creation instruction, and triggering the dynamic logical address group pool to absorb and merge the fragmented space, the logical address groups including static logical address groups and dynamic logical address groups. The present invention lays a structured resource foundation for namespace allocation by dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group providing a continuous logical page address range of a predetermined size; and reserving a dynamic logical address group pool to absorb the fragmented space generated by namespace operations, enabling the system to dynamically combine multiple logical address groups (including static and dynamic) to form the address range of the namespace in response to a namespace creation instruction. For example, when creating a 31GB namespace, the system can combine one complete static logical address group (32GB) with one dynamic logical address group to absorb the remaining 1GB of space, breaking through the limitation of traditional solutions that namespaces must occupy continuous address blocks. This collaborative mechanism of dynamic and static address groups fundamentally solves the problem of storage fragmentation caused by the frequent creation and deletion of namespaces - the dynamic logical address group pool absorbs fragmented space in real time and participates in reorganization, converting unused scattered address blocks into effective resources. Its technical effect is directly reflected in the storage space utilization rate approaching 100%, while maintaining the logical continuity of the namespace address range, ensuring that subsequent access performance is not degraded.

[0073] The NVMe SSD multi-namespace management method provided by the present invention constructs a stable basic storage resource framework by dividing the total logical address space of the SSD into a preset number of static logical address groups and configuring a continuous logical page address range of a predetermined size; at the same time, a dynamic logical address group pool containing multiple dynamic logical address groups is reserved, which is specifically used to absorb the fragmented space generated during the namespace operation process. When the system responds to the namespace creation instruction, it can dynamically combine the static logical address group and the dynamic logical address group to form a continuous address range of the namespace, and trigger the dynamic logical address group pool to absorb and merge the fragmented space in real time. The technical effect produced by this scheme is derived from its unique resource management mechanism: the static logical address group provides the ability to allocate large-scale continuous address blocks to ensure the basic performance of the namespace; the dynamic logical address group pool acts as an elastic buffer to continuously absorb the address space remnants that are not fully utilized when the namespace is created (such as the partially occupied static group remaining area) and the discrete address blocks released after the namespace is deleted, so that the fragmented space that cannot be used in the traditional scheme is converted into a reorganizable resource. Because the dynamic logical address group pool is always in an actively managed state, any address space fragmentation caused by namespace operations will be captured and consolidated immediately, completely breaking the vicious cycle of fragmentation accumulation.

[0074] This collaborative operation mechanism of dynamic and static address groups fundamentally overcomes the inherent defects of traditional NVMe SSDs in multi-namespace scenarios. Traditional solutions are limited by the principle of continuous address allocation. When frequent creation and deletion of namespaces result in multiple non-continuous fragments in the logical address space, the new namespace can only be subject to the maximum single-block fragment size. Even if the sum of the fragmented space is much larger than the demand, it cannot be allocated. This method dynamically combines multiple logical address groups to form a virtual continuous space, so that the actual available capacity of the namespace is expanded to the sum of all fragmented spaces, significantly improving storage resource utilization. More importantly, the dynamic logical address group pool absorbs and reorganizes fragments in real time, ensuring that the address range presented to the outside world by the namespace always maintains logical continuity, avoiding the increase in access path complexity caused by the underlying physical fragmentation distribution. This enables the system to maintain stable read and write performance after long-term operation, eliminating the delay fluctuation problem caused by fragmentation in traditional solutions.

[0075] Corresponding to the above NVMe SSD multi-namespace management method, the present invention also provides an NVMe SSD multi-namespace management device. The NVMe SSD multi-namespace management device includes a unit for executing the above NVMe SSD multi-namespace management method, and the NVMe SSD multi-namespace management device can be configured in a terminal. Specifically, the NVMe SSD multi-namespace management device includes:

[0076] a partitioning unit, configured to partition a total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size;

[0077] A reservation unit, configured to reserve a dynamic logical address group pool, wherein the dynamic logical address group pool includes a plurality of dynamic logical address groups and is configured to absorb fragmented space generated by namespace operations;

[0078] A combining unit is used to dynamically combine logical address groups to form an address range of the namespace in response to a namespace creation instruction, and trigger the dynamic logical address group pool to absorb and merge fragmented space, wherein the logical address groups include static logical address groups and dynamic logical address groups.

[0079] In some preferred embodiments, the number of the dynamic logical address group pools is configured as follows:

[0080] The number of dynamic logical address groups = the maximum number of namespaces supported by the system - 1.

[0081] In some preferred embodiments, the NVMe SSD multi-namespace management device further includes:

[0082] An establishment unit for establishing a mapping management structure from a namespace to a logical address group;

[0083] A maintenance unit is used to maintain the allocation relationship between the namespace and the static logical address group and the dynamic logical address group in the mapping management structure.

[0084] In some preferred embodiments, the mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to a namespace identifier, and the column dimension of the mapping table stores a logical address group number assigned to the namespace.

[0085] In some preferred embodiments, address allocation during namespace creation includes:

[0086] Calculate the required number of logical address groups based on the requested capacity;

[0087] Static logical address groups are allocated first, and the insufficient part is supplemented by dynamic logical address groups;

[0088] When the static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

[0089] In some preferred embodiments, space reclamation upon namespace deletion includes:

[0090] Release all logical address groups occupied by the namespace;

[0091] Triggers automatic space merging of adjacent dynamic logical address groups to form larger contiguous free blocks.

[0092] In some preferred embodiments, the NVMe SSD multi-namespace management device further includes:

[0093] The parsing unit is used to directly parse the namespace access request through the SSD controller, and perform a calculation operation based on the mapping management structure: the physical address is equal to the logical address group base address plus the request offset to determine the accessed physical address.

[0094] It should be noted that technical personnel in the relevant field can clearly understand that the specific implementation process of the above-mentioned NVMe SSD multi-namespace management device and each unit can refer to the corresponding description in the aforementioned method embodiment. For the convenience and conciseness of the description, it will not be repeated here.

[0095] The above-mentioned NVMe SSD multi-namespace management device can be implemented in the form of a computer program, which can be used in the following ways: Figure 7 Runs on the computer equipment shown.

[0096] See also Figure 7 , Figure 7 1 is a schematic block diagram of a computer device provided in an embodiment of the present application. The computer device 500 can be a terminal or a server.

[0097] The computer device 500 includes a processor 502 , a memory, and a network interface 505 connected via a system bus 501 , wherein the memory may include a non-volatile storage medium 503 and an internal memory 504 .

[0098] The non-volatile storage medium 503 can store an operating system 5031 and a computer program 5032. When the computer program 5032 is executed, the processor 502 can execute a method for managing multiple namespaces of an NVMe SSD.

[0099] The processor 502 is used to provide computing and control capabilities to support the operation of the entire computer device 500.

[0100] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a method for managing multiple namespaces of NVMe SSD.

[0101] The network interface 505 is used to communicate with other devices over the network. Those skilled in the art will appreciate that the above structure is merely a block diagram of a portion of the structure related to the present invention and does not limit the computer device 500 to which the present invention is applied. A specific computer device 500 may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0102] The processor 502 is configured to execute a computer program 5032 stored in the memory to implement the following steps:

[0103] Dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size;

[0104] A dynamic logical address group pool is reserved, where the dynamic logical address group pool includes multiple dynamic logical address groups and is used to absorb fragmented space generated by namespace operations;

[0105] In response to a namespace creation instruction, logical address groups are dynamically combined to form an address range of the namespace, and the dynamic logical address group pool is triggered to absorb and merge fragmented space. The logical address groups include static logical address groups and dynamic logical address groups.

[0106] In some preferred embodiments, the number of the dynamic logical address group pools is configured as follows:

[0107] The number of dynamic logical address groups = the maximum number of namespaces supported by the system - 1.

[0108] In some preferred embodiments, the method further comprises:

[0109] Establish a mapping management structure from namespace to logical address group;

[0110] The allocation relationship between the namespace and the static logical address group and the dynamic logical address group is maintained in the mapping management structure.

[0111] In some preferred embodiments, the mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to a namespace identifier, and the column dimension of the mapping table stores a logical address group number assigned to the namespace.

[0112] In some preferred embodiments, address allocation during namespace creation includes:

[0113] Calculate the required number of logical address groups based on the requested capacity;

[0114] Static logical address groups are allocated first, and the insufficient part is supplemented by dynamic logical address groups;

[0115] When the static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

[0116] In some preferred embodiments, space reclamation upon namespace deletion includes:

[0117] Release all logical address groups occupied by the namespace;

[0118] Triggers automatic space merging of adjacent dynamic logical address groups to form larger contiguous free blocks.

[0119] In some preferred embodiments, the method further comprises:

[0120] The namespace access request is directly parsed by the SSD controller, and based on the mapping management structure, a calculation operation of the physical address being equal to the logical address group base address plus the request offset is performed to determine the accessed physical address.

[0121] It should be understood that in the embodiment of the present application, the processor 502 may be a central processing unit (CPU), and the processor 502 may also be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0122] Those skilled in the art will appreciate that all or part of the steps in the method of the above-described embodiment can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. The computer program is executed by at least one processor in the computer system to implement the steps in the method of the above-described embodiment.

[0123] Therefore, the present invention also provides a storage medium. The storage medium may be a computer-readable storage medium. The storage medium stores a computer program. When the computer program is executed by a processor, the processor performs the following steps:

[0124] Dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size;

[0125] A dynamic logical address group pool is reserved, where the dynamic logical address group pool includes multiple dynamic logical address groups and is used to absorb fragmented space generated by namespace operations;

[0126] In response to a namespace creation instruction, logical address groups are dynamically combined to form an address range of the namespace, and the dynamic logical address group pool is triggered to absorb and merge fragmented space. The logical address groups include static logical address groups and dynamic logical address groups.

[0127] In some preferred embodiments, the number of the dynamic logical address group pools is configured as follows:

[0128] The number of dynamic logical address groups = the maximum number of namespaces supported by the system - 1.

[0129] In some preferred embodiments, the method further comprises:

[0130] Establish a mapping management structure from namespace to logical address group;

[0131] The allocation relationship between the namespace and the static logical address group and the dynamic logical address group is maintained in the mapping management structure.

[0132] In some preferred embodiments, the mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to a namespace identifier, and the column dimension of the mapping table stores a logical address group number assigned to the namespace.

[0133] In some preferred embodiments, address allocation during namespace creation includes:

[0134] Calculate the required number of logical address groups based on the requested capacity;

[0135] Static logical address groups are allocated first, and the insufficient part is supplemented by dynamic logical address groups;

[0136] When the static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

[0137] In some preferred embodiments, space reclamation upon namespace deletion includes:

[0138] Release all logical address groups occupied by the namespace;

[0139] Triggers automatic space merging of adjacent dynamic logical address groups to form larger contiguous free blocks.

[0140] In some preferred embodiments, the method further comprises:

[0141] The namespace access request is directly parsed by the SSD controller, and based on the mapping management structure, a calculation operation of the physical address being equal to the logical address group base address plus the request offset is performed to determine the accessed physical address.

[0142] The storage medium is a physical, non-transient storage medium, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a magnetic disk, or an optical disk, etc. Any physical storage medium capable of storing program code can be non-volatile or volatile.

[0143] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0144] In the several embodiments provided herein, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the various units is merely a logical functional division, and actual implementation may employ other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0145] The steps in the methods of the embodiments of the present invention may be adjusted in order, combined, or deleted as needed. The units in the devices of the embodiments of the present invention may be combined, divided, or deleted as needed. Furthermore, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit.

[0146] If this integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the existing technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, terminal, or network device, etc.) to execute all or part of the steps of the method described in various embodiments of the present invention.

[0147] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0148] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, to the extent such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to encompass such changes and modifications.

[0149] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and such modifications or substitutions are intended to be within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be subject to the scope of protection of the claims.

Claims

1. A method for managing multiple namespaces of an NVMe SSD, characterized in that: include: Dividing the total logical address space of the SSD into a preset number of static logical address groups, each static logical address group having a continuous logical page address range of a predetermined size; A dynamic logical address group pool is reserved, where the dynamic logical address group pool includes multiple dynamic logical address groups and is used to absorb fragmented space generated by namespace operations; In response to a namespace creation instruction, logical address groups are dynamically combined to form an address range of the namespace, and the dynamic logical address group pool is triggered to absorb and merge fragmented space. The logical address groups include static logical address groups and dynamic logical address groups.

2. The method according to claim 1, characterized in that The number of dynamic logical address group pools is configured as follows: The number of dynamic logical address groups = the maximum number of namespaces supported by the system - 1.

3. The method according to claim 1, characterized in that The method further comprises: Establish a mapping management structure from namespace to logical address group; The allocation relationship between the namespace and the static logical address group and the dynamic logical address group is maintained in the mapping management structure.

4. The method according to claim 3, characterized in that The mapping management structure is a mapping table, wherein: the row dimension of the mapping table corresponds to a namespace identifier, and the column dimension of the mapping table stores a logical address group number assigned to the namespace.

5. The method according to claim 4, characterized in that Address allocation during namespace creation includes: Calculate the required number of logical address groups based on the requested capacity; Static logical address groups are allocated first, and the insufficient part is supplemented by dynamic logical address groups; When the static logical address group is only partially allocated, the remaining space of the static logical address group is absorbed by the dynamic logical address group.

6. The method according to claim 1, characterized in that Space reclamation when a namespace is deleted includes: Release all logical address groups occupied by the namespace; Triggers automatic space merging of adjacent dynamic logical address groups to form larger contiguous free blocks.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: The namespace access request is directly parsed by the SSD controller, and based on the mapping management structure, a calculation operation of the physical address being equal to the logical address group base address plus the request offset is performed to determine the accessed physical address.

8. A management device for NVMe SSD multiple namespaces, characterized in that: The method comprises a unit for executing the method according to any one of claims 1 to 7.

9. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and the processor implements the method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that The storage medium stores a computer program, and when the computer program is executed by a processor, the computer program can implement the method according to any one of claims 1 to 7.

Images