NVME SSD multi-namespace management method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of SSD management, and discloses an NVME SSD multi-namespace management method and device, computer equipment and a storage medium. The method comprises the following steps: acquiring a namespace creation command issued by a host; and according to the namespace creation command, applying to allocate a corresponding number of logic address blocks in the available user data block chain from the three-level block resource pool to obtain a namespace management structure body. By implementing the method provided by the invention, the corresponding number of logic address blocks can be flexibly applied to be allocated from the resource pool according to the namespace creation command issued by the host, so that the namespace management structure body is constructed, the problem of storage capacity fragmentation caused by frequent creation and deletion of the namespace is effectively avoided, and the storage capacity management efficiency is improved. By pre-planning and dynamically adjusting the allocation of the logical address blocks, the continuity and efficient utilization of the storage space are ensured, and the overall storage capacity utilization rate of the SSD is improved.

Description

Technical Field

[0001] The present invention relates to SSD management technology, and more specifically to a management method, device, computer equipment and storage medium for NVME SSD multiple namespaces. Background Art

[0002] With the continuous development of solid state drive (SSD) technology, SSD has been widely used in various data storage systems. Its high performance and reliability make it an important solution for modern data storage. SSD uses a complex firmware management mechanism to implement data storage, reading and erasing operations. Among them, the namespace management mechanism is an important part of SSD firmware design.

[0003] In SSD, namespace is a logical data organization unit, which is used to divide the physical storage space of SSD into multiple independent logical storage areas. SSD firmware realizes the mapping relationship between logical addresses of different namespaces and internal storage addresses through namespace management mechanism, so that users can flexibly use the storage space of SSD according to their needs.

[0004] However, in actual applications, users may need to dynamically allocate and delete namespaces on the SSD to meet different data storage requirements. This dynamic operation will cause the mapping relationship between the internal storage address of the SSD and the logical address of the namespace to be fragmented. Specifically, when namespaces of different sizes are frequently allocated and deleted on the SSD, the originally continuous storage address space will be divided into multiple discontinuous small blocks, requiring the SSD firmware to implement more complex mapping management logic to maintain these scattered mapping relationships.

[0005] In addition, the fragmentation of this mapping relationship will also lead to a decrease in the efficiency of SSD storage capacity utilization and a decrease in read and write performance. On the one hand, due to the increased complexity of the mapping relationship, the SSD firmware needs to spend more time and resources to find the correct storage address when performing read and write operations, thereby reducing the read and write speed; on the other hand, because the storage address space is divided into multiple small blocks, the SSD storage space cannot be fully utilized, resulting in inefficient storage capacity utilization.

[0006] The problem is particularly prominent when multiple namespaces of different sizes need to be dynamically allocated, deleted, and further allocated. For example, when the deleted namespace is smaller than the namespace to be created, the newly created namespace needs to be supplemented by allocating additional resources from the unallocated address area on the basis of reusing the logical address resources of the reclaimed namespace. This cyclical process of namespace creation and release will further aggravate the fragmentation of the mapping relationship, further reducing the storage capacity utilization and efficiency of the SSD.

[0007] Therefore, how to optimize the namespace management mechanism in the SSD firmware to reduce the fragmentation of mapping relationships and improve storage capacity utilization efficiency and read and write performance is an important issue that needs to be urgently addressed in the current SSD technology field. Summary of the invention

[0008] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a management method, device, equipment and medium for NVME SSD multiple namespaces.

[0009] In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0010] First, a method for managing NVME SSD multiple namespaces is provided, including:

[0011] Get the namespace creation command issued by the host;

[0012] According to the namespace creation command, apply for allocation of the corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool to obtain the namespace management structure;

[0013] The namespace management structure is used to manage the mapping relationship between each namespace and block space.

[0014] Secondly, a management device for NVME SSD multi-namespace is provided, including:

[0015] A first acquisition unit, used to acquire a namespace creation command issued by a host;

[0016] An allocation unit, used to apply for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command, so as to obtain a namespace management structure;

[0017] The namespace management structure is used to manage the mapping relationship between each namespace and block space.

[0018] In a third aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the steps of the above-mentioned NVME SSD multi-namespace management method are implemented.

[0019] In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned NVME SSD multi-namespace management method are implemented.

[0020] The above-mentioned NVME SSD multi-namespace management method, by introducing a three-level block resource pool management mechanism, can flexibly apply for allocation of a corresponding number of logical address blocks from the resource pool according to the namespace creation command issued by the host when creating a namespace, thereby constructing a namespace management structure. This mechanism effectively avoids the storage capacity fragmentation problem caused by frequent creation and deletion of namespaces, ensures the continuity and efficient use of storage space by pre-planning and dynamic adjustment of the allocation of logical address blocks, and significantly improves the overall storage capacity utilization of the SSD.

[0021] The present invention is further described below in conjunction with the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0024] Figure 2 A schematic diagram of an application scenario of a three-level block resource pool provided in an embodiment of the present invention;

[0025] Figure 3 A schematic diagram of an application scenario of the NVME SSD multi-namespace management method provided by an embodiment of the present invention;

[0026] Figure 4 A schematic diagram of an application scenario of a mapping table of a three-level block resource pool provided in an embodiment of the present invention;

[0027] Figure 5 A schematic diagram of an application scenario of namespace deletion provided in an embodiment of the present invention;

[0028] Figure 6A schematic block diagram of a management device for NVME SSD multiple namespaces provided by an embodiment of the present invention;

[0029] Figure 7 It is a schematic diagram of the structure of a computer device in an embodiment of the present invention. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] It should be understood that when used in this specification and the appended claims, the terms "include" and "comprises" indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

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

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

[0034] See also Figures 1 to 5 In the specific embodiment shown, the present invention discloses a method for managing multiple namespaces of an NVME SSD, comprising the following steps:

[0035] S110, obtaining a namespace creation command issued by the host;

[0036] The Multiple namespaces function defined by the NVME protocol allows users to allocate SSDs into different namespaces according to different logical block sizes. Different namespaces have independent logical address ranges, independent access control and encryption policies, which can ensure independent data security and meet the different business needs of different users.

[0037] Specifically, the firmware or driver of the SSD continuously monitors data transmission on the communication interface (such as PCIe, SAS, etc.) from the host. When data is received, the firmware parses the data packet to identify whether it contains a namespace creation command. This usually involves matching and verifying the command fields to ensure that the received command is indeed a valid namespace creation instruction. Once the namespace creation command is identified, the firmware further parses the command to obtain relevant parameter information, which may include an identifier of the namespace (such as a namespace ID), the number of required logical address blocks, and other settings related to the namespace configuration. After parsing the command, the firmware prepares to allocate the corresponding resources from the third-level block resource pool based on the number of required logical address blocks. This includes checking the current state of the resource pool to ensure that there are enough available logical address blocks to meet the requirements of the creation command. After the resource allocation is completed, the firmware constructs a response packet, which includes the result of the namespace creation (such as success or failure status) and any relevant configuration information. The response packet is then sent back to the host to confirm the execution result of the namespace creation command.

[0038] The implementation of the above-mentioned technical feature of obtaining the namespace creation command issued by the host brings the following technical effects:

[0039] Improved response speed: The firmware can quickly monitor and identify namespace creation commands from the host, thereby reducing the delay time of command processing.

[0040] Enhanced command accuracy: Through a strict command parsing process, it ensures that the received commands are valid and the relevant parameters are correctly extracted, thus avoiding resource allocation problems caused by command errors.

[0041] Optimize resource allocation: After parsing the command, the firmware can allocate resources from the three-level block resource pool according to actual needs, thus ensuring the effective use of resources and avoiding waste.

[0042] Improve user experience: By promptly responding to and confirming the execution results of the namespace creation command, users' trust and satisfaction with the SSD storage system are enhanced.

[0043] In one embodiment, before step S110, the method further includes: dividing the flash memory space of the NVMESSD into block groups for management according to different block levels, so as to establish a three-level block resource pool.

[0044] Specifically, see Figure 2 As shown in the figure, according to different SSD NAND flash topology structures, block group management is divided according to different block levels to establish a three-level block resource pool. Take the typical scenario of 4 FLASH DIEs and 4 Plane structure per DIE as an example:

[0045] L1 level has 4 Dies, and there are multiple Blocks on the same plane, which corresponds to 16 physical blocks;

[0046] L2 level is a single Die, a Block on the same plane, which corresponds to 4 physical Blocks;

[0047] Level L3 is a single Die, but the plane's Block corresponds to a physical Block.

[0048] More specifically, first, the firmware or controller of the NVMe SSD needs to identify the topology of the NAND Flash chip inside the SSD, which includes determining the number of each Flash chip (or Die), the number of Planes in each Die, and the number of Blocks in each Plane. Based on the identified NAND Flash topology, the flash memory space is divided into three levels of block resource pools (L1, L2, L3).

[0049] L1 block resource pool: treat all Dies as a whole, and divide all Blocks of the same Plane into an L1 block group. Taking the structure of 4 Dies and 4 Planes per Die as an example, there will be 16 L1 block groups (because 4 Dies*4 Planes=16).

[0050] L2 block resource pool: treat a single Die as a whole and divide all blocks of the same Plane into an L2 block group. In the above example, each Die will have 4 L2 block groups (because each Die has 4 Planes).

[0051] L3 block resource pool: a single block is considered as an independent resource unit, namely, an L3 block group. Each L3 block group corresponds to a physical block.

[0052] The firmware or controller needs to maintain information about these three levels of block resource pools, including the starting address, size, and status (such as free, in use, damaged, etc.) of each block group. When flash memory space needs to be allocated or released, the firmware selects the appropriate block group from the appropriate block resource pool for allocation or recycling based on the type and size of the request. This three-level block resource pool management method can better optimize the performance and reliability of NVMe SSDs. For example, frequently accessed data blocks can be placed in a higher-level block resource pool (such as L1 level) to reduce access latency and increase throughput. At the same time, some spare blocks can be reserved in a lower-level block resource pool to deal with data corruption or bad block management, thereby improving the reliability and data security of the SSD.

[0053] The technical feature of establishing a three-level block resource pool through the implementation of the above brings the following technical effects:

[0054] Improve storage resource utilization: By dividing the flash space into block resource pools of different levels, storage resources can be managed more flexibly. This helps avoid waste of storage resources and improves the overall utilization of storage resources.

[0055] Optimize storage performance: By placing frequently accessed data blocks in a higher-level block resource pool, data access latency can be reduced and the overall performance of the storage system can be improved. This helps improve the user experience and meet the needs of high-performance applications.

[0056] Enhanced storage reliability: By reserving spare blocks in a lower-level block resource pool and adopting appropriate bad block management strategies, the reliability of the storage system can be improved. This helps protect data from the risk of damage or loss and extends the service life of the storage system.

[0057] Simplify storage management: By dividing the flash space into block resource pools of different levels and maintaining the corresponding management information, the complexity of storage management can be simplified. This helps reduce the cost of storage management and improve the maintainability of the storage system.

[0058] S120, applying for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command, so as to obtain a namespace management structure;

[0059] The namespace management structure is used to manage the mapping relationship between each namespace and block space.

[0060] Specifically, see Figure 3 As shown, according to the command sent by the host to create a namespace, the SSD allocates a corresponding number of logical address blocks in the available user data block chain from the three-level Block resource pool according to the host's demand for the namespace logical sector.

[0061] More specifically, the firmware or controller parses the received namespace creation command to determine the total number of logical sectors required to create the namespace, which will determine how many logical address blocks need to be allocated from the third-level block resource pool. Based on the total number of logical sectors required, the SSD firmware or controller applies to allocate the corresponding logical address blocks from the third-level block resource pool. The allocation process follows the following principles:

[0062] Prioritize allocation of high-level block resources: Generally, block groups in the L1 block resource pool have higher access speeds and lower latency, so logical address blocks are allocated from these block groups first. If the L1 block resources are insufficient, the L2 and L3 block resource pools are considered in turn.

[0063] Ensure continuity: Allocate continuous logical address blocks as much as possible to reduce fragmentation and improve read and write performance.

[0064] Consider load balancing: When allocating logical address blocks, you also need to consider load balancing between different block resource pools and block groups to avoid performance degradation caused by overuse of certain block resources or block groups.

[0065] After allocating the logical address block, the SSD firmware or controller builds a namespace management structure. This structure contains key information such as the namespace identifier, the starting address of the logical address block, the total number of logical sectors, the block resource pool level, and the block group information. This structure is used to manage the mapping relationship between the namespace and the block space to ensure that data can be stored and retrieved correctly. Finally, the SSD firmware or controller returns the result of the namespace creation (including the success or failure status and related information of the namespace management structure) to the host.

[0066] The implementation of the above-mentioned technical feature of obtaining the namespace management structure brings the following technical effects:

[0067] Improve the efficiency of namespace creation: By flexibly allocating logical address blocks from the tertiary block resource pool, the host's namespace creation command can be quickly responded to, reducing the delay time of command processing.

[0068] Optimize storage resource utilization: Allocate logical address blocks from the appropriate block resource pool according to the logical sector requirements of the namespace, avoiding resource waste and over-allocation. At the same time, by maintaining the namespace management structure, storage resources can be managed more effectively and the overall storage resource utilization can be improved.

[0069] Improve storage performance: Prioritize the allocation of logical address blocks in high-level block resource pools and try to ensure continuity, which can reduce data access delays and fragmentation, thereby improving the overall performance of the storage system.

[0070] Enhance the scalability and flexibility of the storage system: The three-level block resource pool management method enables the storage system to flexibly adapt to namespaces of different sizes and requirements. At the same time, as storage capacity increases and technology develops, the level and capacity of the block resource pool can be easily expanded to meet future changes in storage needs.

[0071] In one embodiment, after step S120, it also includes: establishing a mapping table from the namespace logical sector address to the third-level block resource pool, preferentially allocating L1 block space and L2 block space for sequential write commands of the host namespace, and preferentially allocating L3 block space for random write commands.

[0072] Specifically, see Figure 4As shown, a mapping table from the namespace logical sector address to the block resource pool is established, that is, the L2P table of the namespace. The host preferentially allocates L1 and L2 block spaces for sequential write scenarios of the namespace, and preferentially allocates L3 block spaces for random write scenarios to ensure optimal read and write performance.

[0073] In NVMe SSD or similar storage systems, in order to optimize storage performance and resource utilization, a mapping table (L2P table) from the namespace logical sector address to the three-level block resource pool is established, and different levels of block space are allocated according to the characteristics of the host write command (sequential or random). The specific implementation method is as follows:

[0074] Establish L2P table: In the SSD firmware or controller, create a logical to physical (L2P) mapping table for each namespace. This table records the correspondence between the namespace logical sector address and the block address in the physical block resource pool. The L2P table is usually stored in the metadata area of ​​the SSD and uses efficient data structures (such as hash tables, B-trees, etc.) to speed up lookup and update operations.

[0075] Divide into three levels of block resource pools: Divide the physical storage space of the SSD into three levels of block resource pools: L1, L2, and L3. Each level of block resource pool has different performance and cost characteristics. The L1 block resource pool usually contains high-speed, low-latency blocks, which are suitable for application scenarios with high performance requirements. The L2 block resource pool has the second-best performance, but has a larger capacity, and is used to balance performance and cost. The L3 block resource pool provides larger capacity and lower cost, but has relatively poor performance, and is suitable for data with low performance requirements.

[0076] Distinguishing between sequential and random write commands: SSD firmware or controller identifies sequential and random write scenarios by analyzing the host's write commands. Sequential writes are usually expressed as continuous logical sector addresses being written to data, while random writes are expressed as jumping writes of logical sector addresses.

[0077] Allocate block space based on write commands: For sequential write commands, prioritize allocating block space from the L1 block resource pool. If L1 resources are insufficient, then consider L2 and L3 block resource pools in turn. For random write commands, prioritize allocating block space from the L3 block resource pool. Doing so can reduce fragmentation in the L1 and L2 block resource pools, thereby maintaining read and write performance in these high-performance areas.

[0078] Update L2P table: After allocating block space, update the L2P table to reflect the new logical-to-physical mapping relationship. Ensure that the update of the L2P table is atomic to avoid data inconsistency issues.

[0079] The implementation of the above-mentioned technical feature of establishing a mapping table from namespace logical sector addresses to the third-level block resource pool brings the following technical effects:

[0080] Optimize read and write performance: By prioritizing the allocation of high-performance L1 and L2 block spaces for sequential writes, sequential read and write performance can be significantly improved. By directing random writes to the L3 block space, the fragmentation of high-performance areas can be reduced, thereby maintaining their read and write performance.

[0081] Improve storage resource utilization: By allocating write commands with different characteristics to block resource pools at different levels, storage resources can be used more efficiently. This prevents high-performance block resources from being occupied by a large number of random writes, thereby extending the life of these resources.

[0082] Enhance system flexibility and scalability: The three-level block resource pool management method enables the storage system to flexibly adapt to write commands with different characteristics. With the development of storage technology and the increase of storage capacity, the level and capacity of the block resource pool can be easily expanded to meet the changes in future storage needs.

[0083] In one embodiment, after step S120, the method further includes:

[0084] Get the namespace deletion command issued by the host;

[0085] According to the namespace deletion command, the block resources allocated to the namespace are reclaimed to the third-level block resource pool, and the mapping information and namespace management structure corresponding to the namespace are deleted.

[0086] Specifically, see Figure 5 As shown in the figure, the namespace deletion and corresponding Block resource release process corresponds to the namespace creation process. The deletion process completes the release of the namespace Block address to the logical address resource pool and deletes the mapping table information and management structure corresponding to the namespace.

[0087] More specifically, in a storage system, especially an NVMe SSD or other block-based storage device, when a host no longer needs a namespace, it will issue a namespace deletion command. In order to efficiently manage storage resources, the storage system needs to implement the process of namespace deletion and corresponding block resource release. The following is a specific implementation of the process:

[0088] Obtaining the namespace deletion command sent by the host: The firmware or controller of the storage system monitors the command queue from the host. When a namespace deletion command is detected, the command is parsed to obtain the identifier of the namespace to be deleted (such as the namespace ID).

[0089] Reclaim the allocated block resources of the namespace: According to the namespace ID, find all the allocated block resources associated with the namespace. These block resources may be distributed in different physical locations and may belong to any of the three-level block resource pools (L1, L2, L3) mentioned earlier. Remove these block resources from the allocation table of the namespace and mark them as available or recycle them to the corresponding block resource pool. If the block resource pool has a specific management policy (such as wear leveling, garbage collection, etc.), it will also be processed accordingly in this step.

[0090] Delete the mapping information and namespace management structure corresponding to the namespace: Find and delete the logical to physical (L2P) mapping table entries related to the namespace. These entries record the correspondence between the namespace logical sector address and the physical block address. Release the memory occupied by the namespace management structure. This structure usually contains metadata about the namespace, such as size, status, block resource allocation, etc. Ensure that the data integrity of other namespaces or block resources is not damaged during the deletion process.

[0091] Update the storage system's metadata: Update the storage system's global metadata to reflect the namespace deletion and block resource reclamation. This may include updating the namespace list, block resource pool status, garbage collection queues, etc.

[0092] Notify the host that the namespace deletion is complete: Send a response or status update to the host that the namespace deletion is complete. Ensure that the host can correctly identify the namespace deletion and update its file system or volume management layer accordingly.

[0093] The implementation of the above-mentioned technical feature of deleting the mapping information and namespace management structure corresponding to the namespace brings the following technical effects:

[0094] Efficient resource utilization: By reclaiming the block resources allocated to a namespace, it is ensured that these resources can be used by other namespaces or future write operations. This improves the resource utilization of the storage system and reduces resource waste.

[0095] Data integrity protection: When deleting a namespace and its block resources, ensure that the data of other namespaces or block resources will not be destroyed. This maintains the data integrity of the storage system and improves the reliability and stability of the system.

[0096] System flexibility: Allows hosts to dynamically create and delete namespaces to adapt to different storage requirements and application scenarios. This improves the flexibility and scalability of the storage system, enabling it to better support modern cloud computing and big data environments.

[0097] Simplified management: The standardized namespace deletion process simplifies the management of storage systems, making it easier for storage administrators to monitor and manage storage resources and reducing management costs.

[0098] In addition, after multiple allocation and deletion processes of the namespace, the unallocated resource blocks in each storage block are distributed at random positions in the resource block group, but the complexity of the mapping table from logical address to physical address that needs to be created after the new namespace is applied will fall within the predictable range. The new namespace management solution can effectively avoid the problem of fragmented distribution of namespaces in physical storage space caused by frequent application and release of namespaces, and effectively improve the efficiency and performance of storage capacity.

[0099] That is to say, by introducing the three-level block resource pool management mechanism, when creating a namespace, it is possible to flexibly apply for the allocation of the corresponding number of logical address blocks from the resource pool according to the namespace creation command issued by the host, thereby constructing a namespace management structure. This mechanism effectively avoids the problem of storage capacity fragmentation caused by frequent creation and deletion of namespaces. By pre-planning and dynamically adjusting the allocation of logical address blocks, it ensures the continuity and efficient use of storage space, and significantly improves the overall storage capacity utilization of SSDs. In addition, the design of the three-level block resource pool allows the precise allocation of logical address blocks according to actual needs when creating a namespace, avoiding unnecessary waste of space; at the same time, when a namespace is deleted, the logical address blocks it occupies can be quickly recovered and re-incorporated into the resource pool for use in subsequent namespace creation. This efficient resource recovery and reuse mechanism further improves the utilization of SSD storage space and extends the service life of SSDs. In addition, when managing the namespace, the traditional SSD often suffers from a decrease in read and write performance due to the fragmented allocation of physical blocks. The present invention ensures that the mapping relationship between the namespace logical address block and the physical block is more reasonable and efficient through the fine management of the three-level block resource pool. When the namespace is created, the logical address block can be mapped to a continuous physical block as much as possible, reducing the addressing time and data migration overhead during read and write operations, thereby significantly improving the read and write performance of the SSD. In addition, the three-level block resource pool management mechanism of the present invention is not only suitable for the current mainstream NVME SSD, but also has good flexibility and scalability. With the continuous development of SSD technology, the level and capacity of the resource pool can be further expanded in the future to meet larger-scale and more complex data storage needs. At the same time, this mechanism is also convenient for combining with other advanced storage management technologies (such as data compression, deduplication, etc.) to further improve the comprehensive performance of the SSD.

[0100] Figure 6 FIG. 3 is a schematic block diagram of a NVME SSD multi-namespace management device 300 provided in an embodiment of the present invention. Figure 6As shown, corresponding to the above NVME SSD multiple namespace management method, the present invention also provides a NVME SSD multiple namespace management device 300. The NVME SSD multiple namespace management device 300 includes a unit for executing the above NVME SSD multiple namespace management method, and the device can be configured in a server. Specifically, please refer to Figure 6 , the NVME SSD multi-namespace management device 300 includes a first acquisition unit 301 and an allocation unit 302;

[0101] The first acquisition unit 301 is used to acquire a namespace creation command issued by a host;

[0102] The allocation unit 302 is used to apply for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command to obtain a namespace management structure;

[0103] The namespace management structure is used to manage the mapping relationship between each namespace and block space.

[0104] In one embodiment, the device further includes: a partition establishment unit, which is used to divide the flash memory space of the NVME SSD into block groups for management according to different block levels, so as to establish a three-level block resource pool.

[0105] In one embodiment, the device also includes: establishing an allocation unit for establishing a mapping table from a namespace logical sector address to a third-level block resource pool, and for sequential write commands of the host namespace, L1 block space and L2 block space are preferentially allocated, and for random write commands, L3 block space is preferentially allocated.

[0106] In one embodiment, the device further comprises:

[0107] A second obtaining unit is used to obtain a namespace deletion command issued by the host;

[0108] The recycling and deletion unit is used to recycle the block resources allocated to the namespace to the third-level block resource pool according to the namespace deletion command, and delete the mapping information and namespace management structure corresponding to the namespace.

[0109] 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 300 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.

[0110] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 7As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external client via a network connection. When the computer program is executed by the processor, it implements the functions or steps of the server side of a method for managing multiple namespaces of an NVME SSD.

[0111] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0112] Obtain a namespace creation command issued by the host; apply for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command to obtain a namespace management structure; wherein the namespace management structure is used to manage the mapping relationship between each namespace and the block space.

[0113] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0114] Obtain a namespace creation command issued by the host; apply for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command to obtain a namespace management structure; wherein the namespace management structure is used to manage the mapping relationship between each namespace and the block space.

[0115] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the client side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0116] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0117] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0118] The embodiments described above are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that the technical solutions described in the aforementioned embodiments may still be modified, or some of the technical features may be replaced by equivalents. Such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A method for managing NVME SSD multiple namespaces, characterized in that: include: Get the namespace creation command issued by the host; According to the namespace creation command, apply for allocation of the corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool to obtain the namespace management structure; The namespace management structure is used to manage the mapping relationship between each namespace and block space.

2. The NVME SSD multi-namespace management method according to claim 1, characterized in that: Before the step of obtaining the namespace creation command issued by the host, the method further includes: dividing the flash memory space of the NVME SSD into block groups for management according to different block levels to establish a three-level block resource pool.

3. The NVME SSD multi-namespace management method according to claim 1, characterized in that: After the step of applying for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command to obtain the namespace management structure, the method also includes: establishing a mapping table from the namespace logical sector address to the third-level block resource pool, and giving priority to allocating L1 block space and L2 block space for sequential write commands of the host namespace, and giving priority to allocating L3 block space for random write commands.

4. The NVME SSD multi-namespace management method according to claim 3, characterized in that: After the step of establishing a mapping table from the namespace logical sector address to the third-level block resource pool, the method further includes: Get the namespace deletion command issued by the host; According to the namespace deletion command, the block resources allocated to the namespace are reclaimed to the third-level block resource pool, and the mapping information and namespace management structure corresponding to the namespace are deleted.

5. An NVME SSD multi-namespace management device, characterized in that: include: A first acquisition unit, used to acquire a namespace creation command issued by a host; An allocation unit, used to apply for allocation of a corresponding number of logical address blocks in the available user data block chain from the third-level block resource pool according to the namespace creation command, so as to obtain a namespace management structure; The namespace management structure is used to manage the mapping relationship between each namespace and block space.

6. The NVME SSD multi-namespace management device according to claim 5, characterized in that: The device also includes: a division establishment unit, which is used to divide the flash memory space of the NVME SSD into block groups for management according to different block levels, so as to establish a three-level block resource pool.

7. The NVME SSD multi-namespace management device according to claim 5, characterized in that: The device also includes: establishing an allocation unit, which is used to establish a mapping table from a namespace logical sector address to a three-level block resource pool, and for sequential write commands of the host namespace, L1-level block space and L2-level block space are preferentially allocated, and for random write commands, L3-level block space is preferentially allocated.

8. The NVME SSD multi-namespace management device according to claim 7, characterized in that: The device also includes: A second obtaining unit is used to obtain a namespace deletion command issued by the host; The recycling and deletion unit is used to recycle the block resources allocated to the namespace to the third-level block resource pool according to the namespace deletion command, and delete the mapping information and namespace management structure corresponding to the namespace.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the NVME SSD multi-namespace management method as described in any one of claims 1 to 4 are implemented.

10. A storage medium, wherein the computer-readable storage medium stores a computer program, characterized in that: When the computer program is executed by a processor, the steps of the NVME SSD multi-namespace management method as described in any one of claims 1 to 4 are implemented.

Images