Address management method of partitioned namespace solid state disk and related device

Abstract

The application discloses a kind of address management methods of partitioned namespace solid state disk and related equipment.Its method includes: in power-on initialization stage, the memory space corresponding to the address space of single partition is applied with the size of logical-to-physical mapping table, and logical-to-physical mapping table is initialized as the physical mapping address value set of all address units in reference superblock;Binding relationship between partition and superblock and the binding relationship table of the amount of valid data written in each partition are maintained;In response to read command, the physical mapping address of target data is obtained according to binding relationship table and logical-to-physical mapping table;When power-off, the binding relationship table is persisted, and the saved binding relationship table is loaded when re-powered.The application can greatly reduce memory requirements and simplify operation management logic while ensuring the performance of direct table lookup of read command, shorten the power-on and power-off time of partitioned namespace solid state disk, and improve its overall performance and efficiency.

Description

Technical Field

[0001] This application relates to the field of solid-state drive technology, and in particular to an address management method and related equipment for a partitioned namespace solid-state drive. Background Technology

[0002] A Zone Namespace Solid State Drive (ZNS SSD) is a storage device that divides an entire namespace into contiguous, non-overlapping logical blocks (Zones) of the same size. The ZNS protocol specification requires that write commands issued by the host must be executed sequentially within a Zone. This sequential write mechanism naturally creates a sequential correspondence between the Logical Mapping Address (LMA) and the Physical Mapping Address (PMA) within a Zone.

[0003] Based on the above characteristics, there are currently two main technical solutions in the industry for obtaining the physical address of the target data when processing read requests from partitioned namespace SSDs. The first solution abandons the traditional Logical-to-Physical (L2P) mapping table design. When processing read commands, it relies entirely on the sequential correspondence between logical and physical addresses within a Zone, with the processor calculating and obtaining the physical address of the target data in real time. The second solution retains the traditional L2P mapping table design. Each Zone within the partitioned namespace SSD is allocated a separate memory space to store the full address mapping information for that Zone. When processing read commands, the physical address is obtained by directly querying the memory table. During disk operation, the corresponding memory table entries are updated in real time as data is written. Before the device is powered down, the full L2P mapping table data in memory is flushed to NAND flash memory for persistent storage. During the device's power-on initialization phase, the full L2P mapping table data is loaded from the NAND flash memory and restored to memory.

[0004] However, the aforementioned existing technical solutions all have inherent limitations and contradictions that urgently need to be resolved in practical applications, making it difficult to balance read performance, memory resource consumption, and data persistence and recovery time. Specifically, for solutions that do not retain a logical-to-physical mapping table, each read request requires the processor to calculate the physical address in real time, resulting in significant CPU (Central Processing Unit) overhead, which in turn restricts the read performance of partition namespace SSDs. For solutions that retain the traditional logical-to-physical mapping table, the technical bottleneck persists throughout the entire lifecycle of the partition namespace SSD: in terms of memory consumption, its design of allocating independent memory for each zone results in a huge demand for the total capacity of Double Data Rate (DDR) dynamic random access memory, increasing hardware costs; during operation, each data write requires real-time modification of the corresponding memory table entry, and a Zone reset requires further modification. During Zone operations, large memory areas need to be reinitialized, making the management logic of the logic-to-physical mapping table quite cumbersome. During the power-down phase, the entire logic-to-physical mapping table data, which has a large capacity, must be flushed and saved to the NAND flash memory. This process often takes several seconds or even tens of seconds, significantly lengthening the power-down time. Especially in abnormal power-down scenarios, the system must rely on large-capacity energy storage capacitors to provide backup power to complete the data flushing. During the power-up phase, it not only takes a long time to fully load the logic-to-physical mapping table data from the NAND flash memory, but also requires complex table reconstruction logic for the recovery process after abnormal power-down. This further increases the design complexity and manufacturing cost of the firmware, weakening the overall competitiveness of the product.

[0005] Therefore, there is an urgent need for an address management solution that can effectively reduce the memory requirements of solid-state drives (SSDs) and shorten the time spent on data persistence and recovery during power-on and power-off cycles while ensuring the read command response performance of partition namespace SSDs. Summary of the Invention

[0006] This application provides an address management method for partitioned namespace solid-state drives, aiming to solve the technical problem that existing address management methods for partitioned namespace solid-state drives struggle to balance read performance, memory resource consumption, and data persistence and recovery time.

[0007] To solve the above-mentioned technical problems, the technical solution adopted in this application is: to provide an address management method for a partition namespace solid-state drive. This address management method for a partition namespace solid-state drive includes: during the power-on initialization phase, allocating memory space of a size corresponding to the address space of a single partition to store a logical-to-physical mapping table, and initializing the logical-to-physical mapping table as a set of physical mapping address values ​​for all address units within a base superblock; maintaining a binding relationship table, which records the binding relationship between partitions and the superblock, as well as the amount of valid data written to each partition; and in response to a received read command, obtaining the physical mapping address of the target data according to the binding relationship table and the logical-to-physical mapping table.

[0008] In some embodiments, maintaining the binding relationship table includes: persistently saving the binding relationship table when power is off, and loading the saved binding relationship table when power is restored.

[0009] In some embodiments, the size of the memory space is determined based on the partition size, the address unit size, and the number of bytes stored in the address unit; the number of bytes stored in the address unit is the number of bytes required to store a physical mapped address value.

[0010] In some embodiments, initializing the logical-to-physical mapping table as a set of physical mapping address values ​​for all address units within a base superblock includes: sequentially initializing each entry in the logical-to-physical mapping table as a physical mapping address value offset from the corresponding address unit within the base superblock; the physical mapping address value consists of a superblock identifier and an address unit identifier.

[0011] In some embodiments, the step of obtaining the physical mapping address of the target data according to the binding relationship table and the logical-to-physical mapping table in response to a received read command includes: querying the binding relationship table in response to a received read command containing a first target partition and an address unit offset; determining whether the first target partition has a binding relationship; if no binding relationship exists, returning a non-mapping response; if a binding relationship exists, obtaining the effective data volume of the first target partition and comparing the effective data volume of the first target partition with the address unit offset in the read command; if the effective data volume of the first target partition is less than the address unit offset, returning a non-mapping response; if the effective data volume of the first target partition is greater than or equal to the address unit offset, querying the logical-to-physical mapping table according to the address unit offset to obtain a base physical mapping address, replacing the superblock identifier in the base physical mapping address with the superblock identifier bound to the first target partition, and obtaining the target physical mapping address.

[0012] In some embodiments, maintaining the binding relationship table further includes: in response to a received partition open command, selecting a target superblock from the free superblock according to a preset strategy and establishing a binding relationship with the partition to be opened, and recording the binding relationship in the binding relationship table; wherein, in the initial state, there is no binding relationship between each partition and the superblock, and the effective data volume of each partition is zero.

[0013] In some embodiments, the preset strategy includes: selecting the superblock with the fewest erase counts from all currently free superblocks as the target superblock; wherein, there is a one-to-one binding relationship between the partition and the superblock, and at any given time, a partition is bound to only one superblock.

[0014] In some embodiments, maintaining the binding relationship table further includes: in response to a received write command for the second target partition, querying the binding relationship table to obtain the superblock bound to the second target partition; writing the data to be written into the bound superblock; and, after successful writing, accumulating and updating the effective data volume of the second target partition.

[0015] In some embodiments, maintaining the binding relationship table further includes: in response to a received partition reset command for the third target partition, releasing the superblock that has a binding relationship with the third target partition to an idle state for use by other partitions; setting the binding relationship between the third target partition and the corresponding superblock to empty in the binding relationship table, and setting the effective data volume of the third target partition to zero.

[0016] To solve the above-mentioned technical problems, another technical solution adopted in this application is to provide a storage medium. The storage medium stores program data, and when the program data is executed by a partitioned namespace solid-state drive (SSD), the SSD performs the steps of the address management method for the partitioned namespace SSD described above.

[0017] To address the aforementioned technical problems, another technical solution adopted in this application is to provide a partitioned namespace solid-state drive (SSD). This SSD includes a processor and a memory interconnected, the memory storing a computer program. When the processor executes the computer program, it implements the steps of the address management method for the partitioned namespace SSD described above.

[0018] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses an address management method for partitioned namespace solid-state drives (SSDs). By retaining a streamlined logical-to-physical mapping table design, this application only requires allocating memory space corresponding to the address space of a single partition, significantly reducing the demand for dynamic random access memory (DRAM) and lowering hardware costs. By maintaining a binding relationship table to record the binding relationship between partitions and the superblock, as well as the amount of valid data written within each partition, it achieves precise tracking of partition data storage locations. By combining the binding relationship table and the logical-to-physical mapping table for fast table lookup during read command processing, it avoids the overhead of real-time physical address calculation by the processor, ensuring the responsiveness of read commands. By persistently saving the binding relationship table only when power-down and loading the binding relationship table and reinitializing the logical-to-physical mapping table when power-up, it eliminates the need for flushing and loading the large logical-to-physical mapping table, significantly shortening power-up and power-down time. It is also very friendly to abnormal power-down scenarios, eliminating the need for large-capacity capacitors to increase the disk's backup power time and simplifying the abnormal power-down recovery process. This approach effectively balances read command response performance, memory resource consumption, and data persistence recovery time. While ensuring the performance of direct table lookup for read commands, it can significantly reduce memory requirements and simplify the operation and management logic, thereby significantly shortening the power-on and power-off time of the partition namespace solid-state drive and improving its overall performance and usage efficiency. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the address management method for a partitioned namespace solid-state drive provided in this application; Figure 2 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application.

[0020] Figure 3 This is a schematic diagram of the structure of an embodiment of the partitioned namespace solid-state drive provided in this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0022] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] This application provides a method for address management of a partitioned namespace solid-state drive, see reference. Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the address management method for a partition namespace solid-state drive provided in this application. The address management method for the partition namespace solid-state drive includes: Step 10: During the power-on initialization phase, allocate memory space of the size corresponding to the address space of a single partition to store the logical-to-physical mapping table, and initialize the logical-to-physical mapping table as a set of physical mapping address values ​​of all address units within the base superblock; Step 20: Maintain the binding relationship table, which records the binding relationship between partitions and superblocks, as well as the amount of valid data written to each partition; Step 30: In response to the received read command, obtain the physical mapping address of the target data according to the binding relationship table and the logical-to-physical mapping table; Maintaining the binding relationship table includes: persisting the binding relationship table when power is off, and loading the saved binding relationship table when power is on again.

[0025] This embodiment provides a method for quickly obtaining physical mapping addresses by utilizing the binding relationship between record partitions (Zone) and superblocks (Sblk) and the binding relationship table of effective data volume, based on the simplification of the logical-to-physical mapping table. This enables fast table lookup during data reading and fast persistence and recovery during power-on and power-off.

[0026] In this embodiment, the simplification of the logical-to-physical mapping table is performed during the power-on initialization phase. The power-on initialization phase can specifically be the phase of powering on a new disk, a normal power-on, or an abnormal power-on. Since the size and number of partitions in a partition namespace SSD are reported to the host operating system so that the host operating system can correctly identify and manage the storage space of the partition namespace SSD, memory requests during this phase can be accurately allocated according to the actual partition configuration, avoiding waste of memory resources.

[0027] In this embodiment, unlike traditional solutions that allocate separate memory for each partition using a logical-to-physical mapping table or do not retain a logical-to-physical mapping table at all, this application only allocates memory space corresponding to the address space of a single partition to store the logical-to-physical mapping table. This allows all partitions on the entire disk to share a single memory block, rather than each partition having its own dedicated memory block. The address space size of a single partition is determined by the partition size, which is equal to the superblock size. Therefore, the corresponding memory space can accurately meet the address mapping requirements of a single partition, significantly reducing the demand for dynamic random access memory (DRAM) on the partition namespace SSD.

[0028] In this embodiment, unlike traditional logical-to-physical mapping tables that require complete recording of the actual physical mapping addresses of each partition to ensure query accuracy, the simplified logical-to-physical mapping table retained in this application is initialized as a set of physical mapping address values ​​of all address units within the base superblock. That is, it only records the address mapping relationships within the base superblock, rather than the address mapping relationships within the superblocks actually bound to each partition. Here, a superblock (Sblk) is a physical storage unit in the partition namespace solid-state drive, capable of accommodating multiple address units. The size of a single partition is equal to the size of a single superblock. The correspondence between partitions and superblocks is uniformly managed internally by the solid-state drive. The base superblock is a pre-selected fixed superblock (for example, superblock Sblk0 with number 0 can be selected as the base superblock, or other superblocks with different numbers can be selected).

[0029] In this embodiment, the set of physical mapping address values ​​for all Address Units (AUs) within the base superblock constitutes the initial value of the logical-to-physical mapping table. This set reflects the one-to-one correspondence between the offsets of each address unit within the base superblock and the physical mapping addresses. Therefore, the corresponding physical mapping address can be directly obtained by querying the address unit offset. It should be noted that the physical mapping address is typically composed of a superblock identifier and an address unit identifier. Since the ZNS protocol requires sequential writing within a partition, the logical address offset must be consistent with the physical address offset. Therefore, the simplified logical-to-physical mapping table essentially constructs a "template" for physical address mapping. When querying data for a specific partition, simply replace the superblock identifier in the retrieved base physical mapping address with the superblock identifier actually bound to that partition to obtain the actual physical address. The actual superblock information bound to each partition is recorded and queried through the binding relationship table described later, decoupling the binding relationship between the logical-to-physical mapping table and the specific partition. This allows all partitions to share a single simplified logical-to-physical mapping table, greatly simplifying management logic.

[0030] In this embodiment, the binding relationship table is the core data structure maintained during the runtime of the partition namespace SSD. Specifically, it can be constructed based on data structures such as arrays, linked lists, or hash tables, and maintained in the memory of the partition namespace SSD to achieve precise tracking of partition data storage locations. This binding relationship table records the binding relationship between partitions and superblocks, as well as the amount of valid data written within each partition. The binding relationship between a partition and a superblock refers to the superblock identifier currently bound to the partition, which reflects the actual physical storage location where user data within the partition is written. Therefore, during read command processing, this binding relationship can be used to quickly locate the superblock where the partition data is located, and then, combined with the logical-to-physical mapping table, obtain the accurate physical mapping address. The amount of valid data written within each partition refers to the number of address units successfully written within the partition, reflecting the writing progress and effective range of data within the partition. This amount of valid data is counted in address units and is only accumulated and updated after writing is completed. If writing fails or is interrupted, it is not updated, thus ensuring data consistency. During read command processing, the system can determine whether the address unit offset requested by the read command has been written using the effective data volume. For address unit offsets that have not been written, an unmapped response (unmap) can be returned directly, indicating that there is no valid data at the requested address unit offset, specifically in cases where the partition has never been written to or the partition has been reset, thus avoiding invalid physical mapping address queries. By recording and maintaining these two key pieces of information, the binding relationship table can accurately track the data storage location and write status of each partition. Furthermore, since the binding relationship table only records the binding relationship between the partition and the superblock and the effective data volume, its size only needs to be a few tens of kilobytes or even a few kilobytes to meet the management requirements of all partitions on the entire disk, greatly reducing memory usage and persistence overhead.

[0031] In this embodiment, based on maintaining a simplified logical-to-physical mapping table and binding relationship table, upon receiving a read command (Host Read Command, HostRd Cmd) issued by the host, a quick table lookup can be performed using these two data structures to obtain the physical mapping address of the target data. The read command contains partition information and address unit offset information. The partition information reflects the target partition requested by the read command, while the offset information can specifically be an address unit identifier (AuId) or an address unit offset (AuOff). Both of these data can be obtained by parsing the read command and can uniquely identify the target address unit requested by the read command, reflecting the offset position of the target data within the partition. By parsing the read command, the storage location of the target data can be accurately located.

[0032] In this embodiment, to obtain the physical mapping address of the target data requested by the read command, a joint query is performed using the aforementioned binding relationship table and logical-to-physical mapping table to quickly and accurately obtain the target physical mapping address. Specifically, when processing the read command, the binding status of the target partition can be queried through the binding relationship table. Using the binding relationship between the partition and the superblock recorded therein, the superblock where the target partition data is located can be quickly located. Using the corresponding valid data volume, it can be further determined whether the address unit offset requested by the read command has been written with data. For address unit offsets that have not been written, an unmapped response can be returned directly to avoid invalid queries. For address unit offsets that have been written with data, the reference physical mapping address can be obtained by querying the aforementioned simplified logical-to-physical mapping table. Then, the superblock identifier in the reference physical mapping address is replaced with the superblock identifier bound to the target partition to obtain the accurate target physical mapping address. Then, the target data can be read from the NAND flash memory through the target physical mapping address. Compared to traditional solutions that maintain a logical-to-physical mapping table for each partition independently, and solutions that rely on real-time CPU calculations instead of a logical-to-physical mapping table, this data reading method retains the efficiency of direct table lookups while significantly reducing memory requirements, greatly shortening the response time of read commands, and improving the overall read performance of partition namespace SSDs.

[0033] In this embodiment, to ensure data consistency and fast recovery capabilities of the partition namespace SSD, the power-on / off logic of the binding relationship table has been further optimized. Specifically, only the binding relationship table needs to be persisted (e.g., saved to NAND flash memory) upon power-off, while the logical-to-physical mapping table does not need to be persisted. Since the binding relationship table only records the binding relationship between the partition and the superblock and the amount of effective data, it decouples the tight coupling between the partition and the specific physical storage location. The amount of data in this persisted binding relationship table is extremely small (as mentioned above, it is usually tens of kilobytes or even a few kilobytes), and its flushing and saving time is in the microsecond range, which is much lower than the time required for a full flushing and saving of the non-simplified logical-to-physical mapping table in traditional solutions. (This process typically takes several seconds or even tens of seconds.) Meanwhile, traditional solutions, in order to avoid the loss of the mapping table due to abnormal power-down and to ensure the reliability of data persistence, usually require a very large capacitor to provide backup power for data flushing. However, the simplified persistence solution proposed in this application only requires a very small amount of power to complete the flushing of the binding relationship table. It usually does not require additional large-capacity capacitors or only requires small-capacity capacitors to meet the requirements. This can effectively reduce the size of the corresponding partition namespace solid-state drive and reduce hardware costs. It does not require large-capacity capacitors to increase the backup power time of the disk, thus enhancing the competitiveness of the product.

[0034] In this embodiment, during the power-on phase after power-down, a fast recovery logic is executed. This involves regenerating (reconstructing) the logical-to-physical mapping table according to the initialization rules and loading the corresponding binding relationship table from persistent storage (such as the aforementioned NAND flash memory) for recovery. This completes the initialization of the partition namespace SSD, enabling a quick and efficient recovery to the pre-power-down operating state and continuous response to host commands. This avoids the overhead of a full load of the logical-to-physical mapping table and achieves rapid data recovery. Compared to the traditional method that requires a full load of the logical-to-physical mapping table to ensure data consistency, this process is faster, simpler, and significantly reduces power-on time.

[0035] This embodiment, through the above-described simplification of the logical-to-physical mapping table, maintenance of the binding relationship table, fast table lookup for read commands, and rapid persistence and recovery during power-on and power-off cycles, effectively reduces memory requirements and shortens data persistence and recovery time during the partition namespace SSD while ensuring read command response performance. It solves the technical problem that existing address management methods for partition namespace SSDs struggle to balance read performance, memory resource consumption, and data persistence and recovery time, thus effectively improving the overall performance and user experience of partition namespace SSDs.

[0036] Optionally, in some embodiments, the size of the memory space is determined based on the partition size, the address unit size, and the number of bytes stored in the address unit; the number of bytes stored in the address unit is the number of bytes required to store a physical mapped address value.

[0037] This optional embodiment details the method for determining the memory space size of the logical-to-physical mapping table to be claimed in this application. Specifically, the partition size refers to the logical address space capacity of a single partition, which reflects the maximum amount of data that the partition can store, and its value is determined by the device configuration; the address unit size refers to the smallest granular unit for address mapping and management inside the solid-state drive, such as 4KB, and one address unit corresponds to one physical mapping address table entry; the address unit storage bytes refer to the memory space required to store one physical mapping address value, which is usually determined by the bit width of the physical address, such as 4 bytes (32 bits). Since the logical-to-physical mapping table needs to establish a mapping table entry for each address unit in the partition, the three parameters of partition size, address unit size, and address unit storage bytes can accurately calculate the memory space size required for a complete mapping table of a single partition.

[0038] In this optional embodiment, the memory space size can be calculated using the formula: Memory space size = (Partition size / Address unit size) × Number of bytes stored in the address unit. The memory space size calculated by this formula is only related to the logical size of a single partition, without needing to allocate based on the entire disk capacity. Furthermore, because the ZNS protocol requires sequential writing within a partition, there is a fixed linear correspondence between logical address offsets and physical address offsets. This logical-to-physical mapping table essentially constructs an address mapping template covering the maximum offset range of a single partition. When querying the address of any partition, it is only necessary to obtain the offset address based on this template and replace the corresponding superblock identifier. Therefore, this size of memory space can also cover the maximum offset range of a single partition, and thus, by replacing the superblock identifier, the address resolution requirements of all partitions on the entire disk can be met. For example, in a specific embodiment, assuming the partition size is configured as 4GB, the address unit size is 4KB, and the number of bytes stored in the address unit is 4 bytes, then the memory space size = (4GB / 4KB) × 4Byte = 4MB. This means that only 4MB of contiguous memory space needs to be requested to meet the entire logical-to-physical mapping table requirements of the partition namespace SSD. Compared with the traditional solution of allocating a mapping table independently for each partition, it can save (number of partitions - 1) × the size of a single partition mapping table. For large-capacity, multi-partition ZNS SSDs, its memory reduction effect is particularly significant, which can effectively solve the problem of the surge in DDR capacity requirements caused by the excessively large mapping table in existing technologies, and significantly reduce hardware material costs.

[0039] In this optional embodiment, the precise calculation and allocation of an appropriate amount of memory space using the aforementioned formula avoids mapping table construction failures due to insufficient memory allocation. It also eliminates resource waste caused by blindly allocating huge amounts of memory space according to the total disk capacity ratio in traditional solutions. This achieves precise on-demand allocation of memory resources, optimizing the solid-state drive design in terms of both hardware cost and resource utilization. Furthermore, since the size of the logical-to-physical mapping table automatically adapts to the partition size by default, and the partition size can be configured by the user or be the default configuration, when a new disk is powered on, the superblock of the corresponding size is built according to the configured partition size, also achieving automatic adaptation of the logical-to-physical mapping table size. This flexible configuration method allows the technical solution of this application to adapt to solid-state drives with different capacities and configurations of partition namespaces, exhibiting good versatility and scalability.

[0040] Optionally, in some embodiments, initializing the logical-to-physical mapping table as a set of physical mapping address values ​​for all address units within the base superblock includes: sequentially initializing each entry in the logical-to-physical mapping table as a physical mapping address value offset from the corresponding address unit within the base superblock; the physical mapping address value consists of a superblock identifier and an address unit identifier.

[0041] In this optional embodiment, the initialization process of the logical-to-physical mapping table is described in detail. Specifically, each entry in the logical-to-physical mapping table corresponds to a physical mapping address value offset from a specific address unit within the base superblock. During initialization, these entries are sequentially set to the physical mapping address values ​​corresponding to the address unit offsets. Thus, by using the logical address offset as an index, the corresponding position within the base superblock can be directly mapped, resulting in a set of base physical mapping address values ​​that covers the entire range of the base superblock and has a fixed offset pattern.

[0042] In this optional embodiment, the physical mapping address value is specifically composed of a superblock identifier and an address unit identifier. It can usually be combined using a bit concatenation method, i.e., PMA=SblkId | AUId, where "|" represents a bit concatenation operation. This structural design divides the physical address space into superblock granularity and intra-block offset granularity to clearly represent the hierarchical structure of the physical address. For example, in some specific embodiments, assuming the physical mapping address is a 32-bit value, the address unit identifier occupies 22 bits, and the superblock identifier occupies 10 bits, if SblkId=1, then the physical mapping address value PMA of the address unit with AUId=0 is 1<<22|0 = 1|00 0000 0000 0000 0000 0000 = 4194304 = 0x400000, and the physical mapping address value PMA of the address unit with AUId=1024 is 1<<22|1024 = 1|00 0000 0000 0100 0000 0000 = 4195328 = 0x400400. The above is only an example of calculating the address unit offset within Sblk1 for ease of understanding; similar calculations will not be described further.

[0043] In this optional embodiment, the superblock with SblkId of 0 (i.e., Sblk0) is preferably used as the base superblock. Its calculation is simpler, and each entry in its corresponding physical mapping address value set can be directly initialized sequentially to the physical mapping address value 0x0, 0x1, 0x2, 0x3, 0x4, 0x5...0xFFFFD, 0xFFFFE, 0xFFFFF (taking a partition size of 4G, an address unit size of 4KB, and an address unit storage size of 4 bytes as an example, there are 1,048,576 entries). It can be seen that when Sblk0 is used, the index of the entry is exactly equal to the value of the entry. This special initialization method makes subsequent address lookup and replacement operations more efficient and less prone to errors (e.g., calculation verification can be introduced), improving the stability and reliability of address management.

[0044] This optional embodiment, through the aforementioned initialization method, makes the logical-to-physical mapping table a base mapping table, with a fixed correspondence between the index (i.e., address unit offset) of each entry and the value (i.e., the physical mapping address) of the entry. Subsequently, when querying the physical mapping address of a specific partition, it is only necessary to retrieve the base physical mapping address from the logical-to-physical mapping table based on the address unit offset, and then replace the superblock identifier in the base physical mapping address with the superblock identifier actually bound to that partition to obtain the correct physical mapping address. This initialization process is simple and efficient, requiring only the sequential setting of the values ​​of each entry according to fixed rules, without complex calculation logic. Furthermore, the initialized logical-to-physical mapping table can be directly used for address lookups without additional conversion or mapping operations. Since the logical-to-physical mapping table is a base mapping table and does not depend on specific partition binding relationships, it does not require persistent storage and restoration during power-on and power-off, greatly simplifying the power-on and power-off process.

[0045] Optionally, in some embodiments, in response to a received read command, obtaining the physical mapping address of the target data according to the binding relationship table and the logical-to-physical mapping table includes: in response to a received read command containing a first target partition and an address unit offset, querying the binding relationship table; determining whether the first target partition has a binding relationship; if no binding relationship exists, returning a non-mapping response; if a binding relationship exists, obtaining the effective data volume of the first target partition and comparing the effective data volume of the first target partition with the address unit offset in the read command; if the effective data volume of the first target partition is less than the address unit offset, returning a non-mapping response; if the effective data volume of the first target partition is greater than or equal to the address unit offset, querying the logical-to-physical mapping table according to the address unit offset to obtain a base physical mapping address, replacing the superblock identifier in the base physical mapping address with the superblock identifier bound to the first target partition, and obtaining the target physical mapping address.

[0046] This embodiment describes the processing flow of read commands. The read command (HostRd Cmd) is an instruction from the host to request data from the solid-state drive (SSD) in the partition namespace. It is typically initiated by the host operating system or applications and aims to obtain data stored at a specified location on the SSD. It includes partition information and address unit offset information, which are used to specify the logical partition (i.e., the first target partition) where the target data is located and its specific location within that partition. For details, please refer to the foregoing description; further elaboration is omitted here.

[0047] In this optional embodiment, the read command will specifically utilize the logical-to-physical mapping table and binding relationship table established in steps 10 and 20 above for joint querying. Specifically, after receiving a read command containing partition information (denoted as zone x, representing the target partition identifier) ​​and address unit offset information (denoted as AuOff y, representing the offset of the target data within the partition), the binding relationship table corresponding to the first target partition will be queried first, and it will be determined whether the corresponding binding relationship is empty (i.e., whether the superblock bound to it is NULL). If the binding relationship is empty, it means that the first target partition has not yet been bound to a superblock, that is, no data has been written. An unmapped response can be returned directly to indicate that the target data has not been mapped to a specific physical storage unit. If the binding relationship is not empty, it means that the first target partition has been bound to a superblock and there may be data to be written. The superblock identifier (denoted as sblk n) and the effective data volume (denoted as m) can be recorded. The effective data volume is then compared with the offset information of the address unit in the read command (e.g., whether m is less than AuOff y) to determine whether data has been written at that offset position. If the amount of valid data is less than the offset corresponding to the address unit offset information, it means that no valid data has been written to that offset position, and the target data requested by the read command does not exist. An unmapped response (unmap) can be returned directly. If the amount of valid data is not less than the address unit offset, it means that valid data has been written to that offset position, and the target data requested by the read command exists. Therefore, it is necessary to further locate its specific physical address. This can be done by querying the simplified logical-to-physical mapping table initialized in step 10 based on the offset information of the corresponding address unit, and obtaining the corresponding base physical mapping address (denoted as Pma). This base physical mapping address effectively represents the physical address of the offset within the base superblock, allowing for superblock identifier replacement. Then, by modifying the superblock within the base physical mapping address to the superblock identifier (sblk n) bound to the partition obtained from the binding relationship table, the address mapping can point to the correct physical storage unit, thereby determining the specific physical mapping address of the target data corresponding to the read command, achieving fast and accurate address location. After obtaining the target physical mapping address or after returning an unmapped response in the aforementioned steps, the processing flow of this read command can be terminated.

[0048] This optional embodiment achieves a complete logical closed loop for read command processing through the detailed process of read command processing. The entire read command processing process quickly and accurately obtains the physical mapping address of the target data through two table lookups (binding relationship table lookup and logical-to-physical mapping table lookup) and one identifier replacement operation. It avoids the CPU overhead and performance bottleneck caused by the processor's real-time calculation of physical addresses, overcomes the technical problem of limited read performance in traditional schemes that do not retain logical-to-physical mapping tables, and eliminates the need to maintain a full logical-to-physical mapping table for each partition independently. It overcomes the problems of large memory consumption and cumbersome management logic in traditional schemes that retain a full logical-to-physical mapping table. It can effectively balance read performance, memory efficiency and management complexity, achieve an efficient balance in partition namespace solid-state drive address management, and significantly improve its overall performance.

[0049] Optionally, in some embodiments, maintaining the binding relationship table further includes: in response to a received partition open command, selecting a target superblock from the free superblock according to a preset strategy and establishing a binding relationship with the partition to be opened, and recording the binding relationship in the binding relationship table; wherein, in the initial state, there is no binding relationship between each partition and the superblock, and the effective data volume of each partition is zero.

[0050] This optional embodiment details the processing flow of the received partition open command (openZone Cmd) during the maintenance of the binding relationship table. The partition open command is a standard operation command defined in the ZNS protocol, specifically issued by the host operating system or application. It is used to put a specified partition (Zone) into an active state to allow data writing. This command contains partition information (denoted as zone x), which represents the logical partition identifier to be operated on. Based on this identifier, the partition to be opened can be determined. Upon receiving the command, the corresponding partition to be opened must be opened to prepare for subsequent data writing.

[0051] In this optional embodiment, upon receiving the partition open command, to achieve physical space allocation before data writing, a target superblock (denoted as sblk n) is selected from the current free superblocks according to a preset strategy and bound to the partition to be opened. This preset strategy refers to a wear leveling strategy for physical blocks, such as selecting the superblock with the fewest erase cycles among all current free superblocks, selecting the superblock with the largest remaining writable capacity among all current free superblocks, or selecting the superblock with the highest physical health score among all current free superblocks. This aims to extend the overall lifespan of the solid-state drive, optimize physical storage space utilization, or improve data storage reliability, and provide stable and reliable physical storage units for subsequent data writing. This preset strategy can be selected and adjusted according to specific application scenarios or user configurations, providing flexible physical resource allocation capabilities for partition namespace solid-state drives.

[0052] In this optional embodiment, while processing the partition open command and allocating the superblock, the binding relationship table is maintained. Specifically, when a target superblock is selected, a binding relationship is established between the partition to be opened and the target superblock, and this binding relationship is recorded in the memory-maintained binding relationship table (i.e., zone x → sblk n). Initially, there is no binding relationship between the partition and the superblock (indicating that the partition is idle or has been reset, with no valid data), and the valid data volume of each partition is zero (indicating that data has not yet been written). This initial state is the standard state after a new SSD in the partition namespace is powered on or after a partition reset (corresponding to the condition of returning an unmapped response). Upon receiving a partition open command and selecting a target superblock, the binding relationship table is updated, changing the binding relationship of the corresponding partition to be opened from empty to the bound target superblock identifier, while keeping the valid data volume of the partition at zero to accurately reflect the state where no data has been written after the new binding.

[0053] This optional embodiment achieves dynamic binding between the partition logical space and the physical superblock through the above-described partition open command processing flow. Furthermore, by binding based on a preset strategy, it effectively ensures wear leveling of flash memory blocks, avoiding localized excessive wear caused by write operations concentrated on a few superblocks, thus improving the reliability of the solid-state drive. Simultaneously, a unique one-to-one binding relationship is maintained between the partition and the superblock at any given time, avoiding complex address cross-mapping and simplifying management logic.

[0054] Optionally, in some embodiments, the preset strategy includes: selecting the superblock with the fewest erase counts from all currently free superblocks as the target superblock; wherein, there is a one-to-one binding relationship between the partition and the superblock, and at any given time, a partition is bound to only one superblock.

[0055] In this optional embodiment, a preset strategy is specifically introduced to select the free superblock with the smallest Erase Count (EC) as the target superblock. The advantage of this preset strategy is that it can effectively achieve wear leveling of the underlying physical blocks of the solid-state drive, and avoid some physical blocks from reaching their lifespan limit prematurely due to frequent allocation and erasure. Therefore, it can maximize the utilization of the flash memory chip's lifespan and improve the long-term reliability and data security of the solid-state drive.

[0056] In this optional embodiment, since the host issues operations such as opening and resetting partitions, the superblock dynamically switches between used and idle states. Specifically, when a partition receives a partition reset command, the superblock previously bound to that partition is released, and the released superblock's state changes to idle. This idle superblock can then re-establish binding relationships with other partitions awaiting opening. Therefore, at any given time, a strict and unique binding can be achieved between partitions and superblocks, ensuring that data writes to each partition have a clear physical ownership and avoiding address overlap and logical confusion that might result from one-to-many or many-to-many bindings.

[0057] This optional embodiment, through the above-described allocation strategy based on the number of erases and the strict unique binding mechanism, not only ensures the balanced consumption of the lifespan of the underlying physical blocks of the solid-state drive, but also simplifies the maintenance logic of the partition-physical space mapping relationship, further improving the stability and maintainability of the partition namespace solid-state drive firmware operation.

[0058] Optionally, in some embodiments, maintaining the binding relationship table further includes: in response to a received write command for the second target partition, querying the binding relationship table to obtain the superblock bound to the second target partition; writing the data to be written into the bound superblock; and after successful writing, accumulating and updating the effective data volume of the second target partition.

[0059] In this optional embodiment, the processing flow of received write commands during the maintenance of the binding relationship table is described in detail. A write command is an instruction from the host to request data to be written to the solid-state drive (SSD) in the partition namespace. It is typically initiated by the host operating system or an application, and aims to store specified data in the logical location corresponding to the SSD. This write command includes partition information (denoted as zone x) for the specified second target partition, thereby enabling data writing operations to be performed on that second target partition.

[0060] In this optional embodiment, upon receiving a write command, the binding relationship table is first queried (i.e., the binding relationship of zone x → sblk n corresponding to zone x) to determine the physical superblock (i.e., sblk n) bound to the second target partition to be written, thus achieving rapid location from logical partition to physical storage unit. Based on the determination of the physical superblock, the data to be written can be written to the corresponding position in the bound superblock sblk n according to the order writing rules required by the ZNS protocol, realizing persistent data storage. After a successful write (which can be determined by the status signal returned by the NAND flash programming operation, the verification result, or the confirmation information from the underlying controller), the effective data volume of the second target partition is cumulatively updated to ensure that the binding relationship table can accurately reflect the effective data volume currently written in the partition, providing an accurate basis for subsequent read command processing. If the write fails (e.g., a programming failure or interruption occurs), the effective data volume is not updated, thus ensuring that the effective data volume recorded in the binding relationship table is strictly consistent with the actual successfully written data volume, maintaining the correctness and consistency of the data mapping relationship.

[0061] This optional embodiment, through the above-described write command processing flow, achieves rapid location of physical addresses and real-time maintenance of mapping relationships during data writing. By tightly coupling the data write operation with the update operation of the effective data volume in the binding relationship table, it not only simplifies the management logic that requires real-time modification of the massive L2P table in traditional solutions, but also ensures the absolute reliability of the mapping information through a mechanism that updates only after a successful write, thereby improving the stability and management efficiency of the partition namespace solid-state drive during the data writing phase.

[0062] Optionally, in some embodiments, maintaining the binding relationship table further includes: in response to a received partition reset command for the third target partition, releasing the superblock that has a binding relationship with the third target partition to an idle state for use by other partitions; setting the binding relationship between the third target partition and the corresponding superblock to empty in the binding relationship table, and setting the effective data volume of the third target partition to zero.

[0063] This optional embodiment details the processing flow of received partition reset commands during the maintenance of the binding relationship table. The partition reset command is a standard operation command defined in the ZNS protocol, typically issued by the host operating system or applications. It logically clears all data within a specified partition, restoring the partition to its initial state for reuse. The command contains partition information (denoted as zonex) for the corresponding specified third target partition, enabling a reset operation to be performed on that third target partition.

[0064] In this optional embodiment, upon receiving a partition reset command, the superblock bound to the third target partition is determined according to the binding relationship table. This superblock is then released to an idle state, allowing the data within it to be safely erased during subsequent garbage collection or erasure processes. After erasure, the idle superblock can be rebound and used by other partitions when executing a partition open command, achieving the recycling of physical storage resources. Simultaneously, the binding relationship table is modified by setting the binding relationship between the third target partition and the corresponding superblock to null (represented by updating the binding relationship from zone x → sblk n to zone x → NULL). This removes the mapping binding relationship between the logical partition and the physical superblock, indicating that there is no longer any valid user data mapping within the partition. Furthermore, the valid data volume of the third target partition is set to zero, indicating that the partition's write progress has been completely reset, and all previously written data is logically considered invalid. Through these two updates, the third target partition is logically completely cleared and restored to its initial idle state.

[0065] This optional embodiment achieves rapid unbinding and resource reclamation of the partition logical space and physical superblock through the above-described partition reset command processing flow. Compared to the time-consuming process of reinitializing large memory areas when performing a reset operation in traditional solutions, this only requires modifying two extremely small fields in the binding relationship table. The operation is extremely fast, consumes almost no extra time, greatly simplifies the partition reset management logic, and improves the response speed of the solid-state drive when processing such management commands.

[0066] This embodiment, through the aforementioned embodiments and optional embodiments, significantly reduces memory requirements by applying for a simplified logical-to-physical mapping table corresponding to the address space of a single partition; it constructs a universal address lookup template by initializing the logical-to-physical mapping table as a set of physical mapping address values ​​of the baseline superblock; it achieves precise tracking of the partition data storage location and status by maintaining a binding relationship table that records binding relationships and effective data volume; it achieves fast and accurate acquisition of the target physical address by jointly querying the binding relationship table and the logical-to-physical mapping table and replacing the superblock identifier during read command processing; it ensures physical block wear leveling and clear mapping logic by establishing a unique binding relationship based on a preset strategy during partition open commands; it ensures consistency between mapping information and actual data by updating the effective data volume only after successful write during write command processing; it simplifies management logic and achieves resource recycling by quickly unbinding and releasing the superblock during partition reset commands; it significantly shortens power-down time and reduces the requirement for backup capacitors by persisting only a very small amount of the binding relationship table during power-down; and it significantly shortens power-up recovery time by rebuilding the logical-to-physical mapping table and loading the binding relationship table during power-up. This series of coordinated technical actions constitutes a complete and efficient partition namespace solid-state drive address management solution. This application can effectively balance and optimize memory resource consumption, operation and management complexity, and data persistence and recovery time while ensuring high performance of direct table lookup for read commands. It avoids the inherent contradiction between performance, resources and complexity in existing technologies and significantly improves the overall performance, reliability and product competitiveness of partition namespace solid-state drives.

[0067] See Figure 2 , Figure 2 This is a schematic diagram of an embodiment of the storage medium provided in this application.

[0068] The storage medium 40 stores program data 41, which, when executed by the partitioned namespace solid-state drive, implements, as follows: Figure 1 The described method for address management of partitioned namespace solid-state drives.

[0069] The program data 41 is stored in a storage medium 40 and includes several instructions for causing the partition namespace solid-state drive to execute all or part of the steps of the methods in the various embodiments of this application. The storage medium 40 can be a NAND flash memory, dynamic random access memory, or static random access memory in the partition namespace solid-state drive, thereby providing the firmware of the partition namespace solid-state drive with the program code and data storage space required for operation. It can also be other types of computer-readable storage media, such as read-only memory, programmable read-only memory, erasable programmable read-only memory, or electrically erasable programmable read-only memory, for storing firmware programs and configuration data, enabling the partition namespace solid-state drive to load and execute the corresponding program code during startup or operation, thereby achieving various performance improvement functions. As long as the storage medium 40 can store the corresponding program data 41 and implement the corresponding address management method when executed by the partition namespace solid-state drive, it can be used as the applicable object of the embodiments of this application.

[0070] See Figure 3 , Figure 3 This is a schematic diagram of a structural embodiment of the partitioned namespace solid-state drive provided in this application.

[0071] The partition namespace solid-state drive 50 includes a processor 52 and a memory 51 interconnected. The memory 51 stores a computer program, and when the processor 52 executes the computer program, it implements, for example... Figure 1 The described method relates to the address management of a partitioned namespace solid-state drive. The memory 51 may include the storage medium 40, or it may be another separately developed memory.

[0072] In this embodiment, the processor 52 and memory 51 in the partition namespace solid-state drive 50 can be connected via a bus or other means. The memory 51, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and functional modules, such as program instructions / modules for implementing the address management method in this embodiment. The processor 52 can implement the address management method of the partition namespace solid-state drive in the above method embodiment by running the software programs, instructions, and modules stored in the memory 51.

[0073] In this embodiment, the partition namespace solid-state drive can be a solid-state drive using the NVMe (Non-Volatile Memory Express) protocol interface, an embedded storage device, or a storage unit in an enterprise-level storage array. It can be specifically applied to scenarios with high requirements for storage performance, reliability, and cost, such as data centers, cloud computing servers, high-performance computing, database storage, or edge computing devices. This application does not specifically limit its specific capacity, interface speed, or physical form. As long as the partition namespace solid-state drive is designed based on the ZNS protocol specification and can implement the address management method of the partition namespace solid-state drive described in this application, it can be understood to be within the protection scope of this application.

[0074] Unlike existing technologies, this application discloses an address management method and related devices for partitioned namespace solid-state drives (SSDs). By retaining a streamlined logical-to-physical mapping table design, only the memory space corresponding to the address space of a single partition needs to be allocated, greatly reducing the demand for dynamic random access memory (DRAM) and lowering hardware costs. By maintaining a binding relationship table to record the binding relationship between partitions and superblocks, as well as the amount of valid data written in each partition, precise tracking of partition data storage locations is achieved. By combining the binding relationship table and the logical-to-physical mapping table for fast table lookup during read command processing, the overhead of real-time physical address calculation by the processor is avoided, ensuring the response performance of read commands. By persistently saving the binding relationship table only when power-down and loading the binding relationship table and reinitializing the logical-to-physical mapping table when power-up, the need for flushing and loading operations of the large logical-to-physical mapping table is eliminated, significantly shortening power-up and power-down time. It is also very friendly to abnormal power failure scenarios, eliminating the need for large-capacity capacitors to increase the backup power time of the disk and simplifying the abnormal power failure recovery process. This approach effectively balances read command response performance, memory resource consumption, and data persistence recovery time. While ensuring the performance of direct table lookup for read commands, it can significantly reduce memory requirements and simplify the operation and management logic, thereby significantly shortening the power-on and power-off time of the partition namespace solid-state drive and improving its overall performance and usage efficiency.

[0075] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the storage medium embodiments and partitioned namespace solid-state drive embodiments are basically similar to the address management method embodiments of partitioned namespace solid-state drives, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the corresponding method embodiments.

[0076] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for address management of a partitioned namespace solid-state drive, characterized in that, include: During the power-on initialization phase, a memory space of the size corresponding to the address space of a single partition is allocated to store the logic-to-physical mapping table, and the logic-to-physical mapping table is initialized as a set of physical mapping address values ​​of all address units within the base superblock; Maintain a binding relationship table, which records the binding relationship between partitions and superblocks, as well as the amount of valid data written in each partition; In response to the received read command, the physical mapping address of the target data is obtained according to the binding relationship table and the logical-to-physical mapping table; The maintenance of the binding relationship table includes: persistently saving the binding relationship table when power is off, and loading the saved binding relationship table when power is on again.

2. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The size of the memory space is determined based on the partition size, the address unit size, and the number of bytes stored in the address unit; the number of bytes stored in the address unit is the number of bytes required to store a physical mapping address value.

3. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The initialization of the logical-to-physical mapping table as a set of physical mapping address values ​​for all address units within the base superblock includes: Each entry in the logical-to-physical mapping table is sequentially initialized to a physical mapping address value that is the offset of the corresponding address unit within the base superblock; the physical mapping address value consists of a superblock identifier and an address unit identifier.

4. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The step of responding to a received read command by obtaining the physical mapping address of the target data according to the binding relationship table and the logical-to-physical mapping table includes: In response to a received read command containing the first target partition and address unit offset, the binding relationship table is queried; Determine whether the first target partition has a binding relationship; If no binding relationship exists, an unmapped response is returned; If a binding relationship exists, the effective data volume of the first target partition is obtained, and the effective data volume of the first target partition is compared with the address unit offset in the read command; If the effective data volume of the first target partition is less than the address unit offset, an unmapped response is returned; If the effective data volume of the first target partition is greater than or equal to the address unit offset, then the logical-to-physical mapping table is queried according to the address unit offset to obtain the base physical mapping address, and the superblock identifier in the base physical mapping address is replaced with the superblock identifier bound to the first target partition to obtain the target physical mapping address.

5. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The maintenance of the binding relationship table also includes: In response to the received partition open command, a target superblock is selected from the free superblock according to a preset strategy and a binding relationship is established with the partition to be opened, and the binding relationship is recorded in the binding relationship table; In the initial state, there is no binding relationship between each partition and the superblock, and the effective data volume of each partition is zero.

6. The address management method for a partitioned namespace solid-state drive according to claim 5, characterized in that, The preset strategy includes: Select the superblock with the fewest erase counts from all currently free superblocks as the target superblock; There is a one-to-one binding relationship between the partition and the superblock, and at any given time, a partition is bound to only one superblock.

7. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The maintenance of the binding relationship table also includes: In response to the received write command for the second target partition, the binding relationship table is queried to obtain the superblock bound to the second target partition; Write the data to be written into the bound superblock; After a successful write operation, the effective data volume of the second target partition is cumulatively updated.

8. The address management method for a partitioned namespace solid-state drive according to claim 1, characterized in that, The maintenance of the binding relationship table also includes: In response to the received partition reset command for the third target partition, the superblock that is bound to the third target partition is released to an idle state for use by other partitions. In the binding relationship table, the binding relationship between the third target partition and the corresponding superblock is set to empty, and the effective data volume of the third target partition is set to zero.

9. A storage medium storing program data, characterized in that, When the program data is executed by the partition namespace solid-state drive, the partition namespace solid-state drive performs the address management method of the partition namespace solid-state drive as described in any one of claims 1-8.

10. A partitioned namespace solid-state drive, characterized in that, It includes an interconnected processor and a memory, the memory storing a computer program, and when the processor executes the computer program, it implements the address management method of the partitioned namespace solid-state drive as described in any one of claims 1 to 8.

Images