A method and apparatus for allocating bandwidth of a namespace

Abstract

A namespace bandwidth allocation method and device, the method comprising: receiving an operation request and determining a target namespace to which the operation request is directed in an SSD; obtaining the capacity of the target namespace and the total bandwidth of a NAND flash end of the SSD, determining active namespaces at the time of receiving the operation request and obtaining the total capacity of all active namespaces; wherein the active namespaces refer to namespaces in which data operations exist within a preset time period; obtaining the capacity ratio between the capacity of the target namespace and the total capacity of all determined active namespaces; allocating bandwidth for the target command namespace according to the total bandwidth of the NAND flash end and the obtained capacity ratio, and executing the received operation request according to the allocated bandwidth. Therefore, the overall bandwidth utilization is improved.

Description

Technical Field

[0001] This article relates to data processing technology, and more particularly to a method and apparatus for bandwidth allocation in a namespace. Background Technology

[0002] With the widespread adoption of solid-state drives (SSDs) in data centers, enterprise storage, and high-performance computing, namespace technology, a core feature of the NVMe (Non-Volatile Memory Express) protocol, is widely used to achieve logical isolation and multi-tenant management of storage resources. By allocating independent namespaces to different users or applications, the system can achieve more flexible storage resource configuration, access isolation, and performance guarantees.

[0003] However, in existing technologies, multiple namespaces typically share the same bandwidth allocation strategy, meaning that regardless of the size of the namespace, the allocated access bandwidth remains consistent. This often exposes significant resource utilization efficiency issues in practical applications. Summary of the Invention

[0004] This application provides a method and apparatus for bandwidth allocation in a namespace, which can reasonably allocate bandwidth and thus improve bandwidth utilization.

[0005] This application provides a method for bandwidth allocation in a namespace, the method comprising:

[0006] Receive an operation request and determine the target namespace of the operation request in the SSD;

[0007] Obtain the capacity of the target namespace and the total bandwidth of the SSD's NAND Flash, determine the active namespace when the operation request is received, and obtain the total capacity of all active namespaces; wherein, the active namespace refers to the namespace where data operations occur within a preset time period;

[0008] Obtain the capacity ratio between the capacity of the target namespace and the total capacity of all determined active namespaces;

[0009] The target command space is allocated bandwidth based on the ratio of the total bandwidth of the NAND Flash terminal to the obtained capacity, and the received operation request is executed according to the allocated bandwidth.

[0010] This application embodiment also provides a namespace bandwidth allocation device, including: a memory and a processor, wherein the memory is used to store an executable program;

[0011] The processor is used to read and execute the executable program, and to perform the namespace bandwidth allocation method as described above.

[0012] Compared with related technologies, the namespace bandwidth allocation device and apparatus provided in this application allocate the total bandwidth of the SSD's NAND Flash by obtaining the capacity of the target namespace and the ratio between the total capacity of all active namespaces when the operation request is received. Therefore, it can achieve rational allocation of bandwidth resources, enabling large-capacity namespaces to obtain higher bandwidth matching their data throughput requirements under high-load scenarios, thereby improving their utilization efficiency. At the same time, it avoids resource idleness caused by excessive bandwidth allocation to small-capacity namespaces, effectively improving the overall bandwidth utilization rate and achieving synergistic optimization of storage performance and resource efficiency.

[0013] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the embodiments described in the description and the accompanying drawings. Attached Figure Description

[0014] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0015] Figure 1 This is a flowchart illustrating a namespace bandwidth allocation method according to an embodiment of this application;

[0016] Figure 2 This is a schematic diagram illustrating a process for obtaining bandwidth for different operation types in a target namespace according to an embodiment of this application;

[0017] Figure 3 This is a flowchart illustrating another namespace bandwidth allocation method according to an embodiment of this application;

[0018] Figure 4 This is a flowchart illustrating another method for bandwidth allocation in a namespace according to an embodiment of this application.

[0019] Figure 5 This is a schematic diagram of the structure of a namespace bandwidth allocation device according to an embodiment of this application;

[0020] Figure 6 This is a schematic diagram of another namespace bandwidth allocation device according to an embodiment of this application. Detailed Implementation

[0021] This application describes several embodiments, but these descriptions are exemplary and not limiting, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0022] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0023] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0024] In existing NAND Flash-based NVMe SSDs, namespace bandwidth allocation typically employs a static and singular scheduling strategy: when the SSD receives read / write commands from multiple namespaces simultaneously, the controller usually processes them alternately in a polling manner. For example, it might retrieve some commands from Namespace A for execution, then switch to Namespace B for execution, and so on. This fixed allocation mechanism cannot dynamically adjust resources based on the actual load of each namespace, resulting in low bandwidth utilization efficiency. Specifically, large-capacity namespaces, due to their large data volumes, have high bandwidth requirements when users perform large-scale read / write operations. However, limited by the preset fixed bandwidth limit, they cannot fully utilize their data throughput potential, leading to increased service response latency and decreased system efficiency. Conversely, small-capacity namespaces typically have lower actual data access loads. Even if allocated higher bandwidth resources, they are difficult to utilize effectively due to insufficient I / O demand, resulting in idle and wasted I / O bandwidth within the SSD.

[0025] Therefore, embodiments of this disclosure provide a method for bandwidth allocation in a namespace, such as... Figure 1 As shown, the method includes:

[0026] Step 100: Receive the operation request and determine the target namespace of the operation request in the SSD.

[0027] For example, when receiving an "operation request" (such as reading data, writing data, or executing management commands) from a host or upper-layer application, the primary task is to parse and understand the specific content of the request. One of the core steps in this process is determining the target storage region for which the request is directed. In SSDs, especially those supporting the Non-Volatile Memory Express (NVMe) protocol, storage resources are logically divided into one or more independent management units, called "namespaces." Each namespace can be viewed as an independent, addressable logical storage volume with its own Logical Block Addressing (LBA) range. Therefore, "determining the target namespace of the operation request within the SSD" means extracting the unique identifier (NameSpace IDentifier, NS_ID) of the target namespace from the metadata of the operation request (e.g., the namespace ID field in the command descriptor), thereby clarifying which specific logical storage partition within the SSD the read / write operation should be performed on.

[0028] Step 101: Obtain the capacity of the target namespace and the total bandwidth of the SSD's NAND Flash, determine the active namespace when the operation request is received, and obtain the total capacity of all active namespaces; wherein, the active namespace refers to the namespace where data operations occur within a preset time period.

[0029] After determining the target namespace for the operation request, a series of resource assessments and status analyses are required to achieve more intelligent performance management. First, the capacity of the target namespace itself needs to be obtained, i.e., the total storage space allocated to it. Simultaneously, the total data transfer bandwidth of the entire SSD at the NAND Flash physical layer needs to be queried; this bandwidth represents the maximum concurrent read / write rate that the underlying flash memory chips of the SSD can support. Next, the "active namespaces" at the time the operation request arrives need to be identified. After obtaining this information, all identified active namespaces are listed, and their summed capacities are calculated.

[0030] This provides a basis for decision-making regarding bandwidth allocation in the target namespace by obtaining the capacity of the target namespace, the total capacity of the active namespace, and the total bandwidth of the SSD.

[0031] Step 102: Obtain the capacity ratio between the capacity of the target namespace and the total capacity of all determined active namespaces.

[0032] After obtaining the capacity of the target namespace and the total capacity of all identified active namespaces, a key performance evaluation metric needs to be calculated—the capacity ratio. This ratio is calculated by dividing the capacity of the "target namespace" targeted by the operation request by the total capacity of all "active namespaces" identified when the request arrives. That is: Capacity Ratio = Target Namespace Capacity / Total Capacity of All Active Namespaces. The physical meaning of this ratio is to measure the "weight" or "share" of the namespace to which the current request belongs within the system's current active load. If the ratio is close to 1, it indicates that only one namespace is currently active, or that the capacity of the target namespace far exceeds that of other active namespaces. If the ratio is much less than 1, it indicates that multiple namespaces are simultaneously active, resources will be shared, and bandwidth contention may exist.

[0033] Step 103: Allocate bandwidth to the target command space based on the ratio of the total bandwidth of the NAND Flash terminal to the obtained capacity, and execute the received operation request according to the allocated bandwidth.

[0034] After calculating the capacity ratio of the target namespace and determining the total bandwidth of the underlying NAND Flash of the SSD, the resource allocation and execution phase begins. First, based on the total bandwidth of the NAND Flash and the previously obtained capacity ratio, a dedicated I / O bandwidth is dynamically calculated and allocated to the target namespace. This allocation process typically follows a fair or weighted strategy; for example, multiplying the total bandwidth by the capacity ratio to allocate a bandwidth share to the target namespace that matches its capacity share. The purpose of this is to ensure that each active namespace receives fair performance guarantees based on its resource utilization ratio, preventing one namespace from excessively consuming bandwidth and affecting the normal operation of other namespaces.

[0035] Once the bandwidth allocation is complete, the initially received operation request can be executed based on this newly allocated bandwidth limit. This means that the read and write data stream of the request will be scheduled and controlled by the controller within this bandwidth threshold, thereby achieving fine-grained performance management and quality of service control based on real-time load status, ultimately ensuring the stability and predictability of the SSD in multi-task concurrent scenarios.

[0036] The namespace bandwidth allocation method provided in this application allocates the total bandwidth of the SSD's NAND Flash by obtaining the capacity of the target namespace and the ratio between the total capacity of all active namespaces when the operation request is received. Therefore, it can achieve rational allocation of bandwidth resources, enabling large-capacity namespaces to obtain higher bandwidth matching their data throughput requirements under high-load scenarios, thereby improving their utilization efficiency. At the same time, it avoids resource idleness caused by excessive bandwidth allocation to small-capacity namespaces, effectively improving the overall bandwidth utilization rate and achieving synergistic optimization of storage performance and resource efficiency.

[0037] In one exemplary instance, step 101 of the above embodiment, determining the active namespace at the time the operation request is received and obtaining the total capacity of all active namespaces, includes:

[0038] For each namespace in the SSD, obtain the time of the most recent data operation for that namespace, and determine the time difference between the time of the most recent data operation and the current time when the operation request is received; wherein, the data operation includes at least one of the following: reading data and writing data;

[0039] Namespaces with a time difference less than a preset time threshold are identified and designated as active namespaces.

[0040] To accurately identify the storage regions that are active at any given time, an activity assessment needs to be performed on each namespace in the SSD, which may include the following process:

[0041] First, for each namespace within the SSD, the system queries and retrieves the precise timestamp of the most recent data operation occurring in that namespace. Here, "data operation" broadly refers to any access to storage data, including at least reading data from or writing data to that namespace. After obtaining this timestamp, the system calculates the elapsed time between the operation and the current moment when a new operation request is received—a "time difference." This calculated time difference is then compared to a pre-defined "time threshold." If a namespace's time difference is less than this threshold, it indicates that the namespace still had I / O activity in the very recent past and can be considered "active." Finally, all namespaces that meet the condition of "time difference less than the pre-defined time threshold" are selected and collectively defined as the set of "active namespaces" in the current context. This mechanism dynamically and in real-time captures the storage resources being used, providing accurate load awareness for subsequent bandwidth allocation, performance optimization, and QoS control.

[0042] In one exemplary instance, the step of executing the received operation request according to the allocated bandwidth in the above embodiments includes:

[0043] Obtain the historical operation records of the target command space, and allocate the bandwidth of the target name space according to the request type in the historical operation records;

[0044] Determine the target request type corresponding to the received operation request, and execute the received operation request according to the allocated bandwidth of the target request type.

[0045] After allocating the total bandwidth to the target namespace, in order to achieve more granular resource management, the bandwidth will be further allocated based on the historical behavior of the namespace. This may include the following process:

[0046] First, the historical operation records of the target namespace are retrieved. These records can contain detailed information on all I / O requests executed on this namespace over a past period, particularly the type of each request (e.g., read or write). Based on this historical data, typical access patterns for the namespace can be analyzed. For example, if the historical records show that read operations far outnumber write operations, the total bandwidth allocated to the namespace will be divided proportionally between read and write bandwidth, with a larger share allocated to read operations. This process involves splitting and allocating the total bandwidth according to the request types in the historical operation records. When a new operation request arrives, the target request type (read or write) is first determined. Then, when executing the request, the bandwidth allocation previously assigned to this request type will be strictly followed, ensuring that I / O scheduling conforms to the historical load characteristics of the namespace, thereby optimizing overall performance and resource utilization.

[0047] In one exemplary instance, the historical operation record is the sum of historical bandwidth usage for multiple operations, wherein the multiple operations include at least one of the following: operations from multiple operation sources, and operations of multiple operation types;

[0048] The bandwidth allocated to the target namespace is determined according to the operation type in the historical operation record based on the historical operation record, including:

[0049] Based on the total historical bandwidth usage of various operation types in the historical operation records, the bandwidth of the target namespace is redistributed to obtain the bandwidth in the target namespace used for different operation types.

[0050] To achieve more precise and efficient resource scheduling, the allocated bandwidth of the target namespace can be finely divided based on its historical behavior data. Specifically, the historical operation records of the namespace are first analyzed to determine the bandwidth consumed by different operation types (such as read, write, and erase) in the past, and the historical bandwidth usage for each operation type is calculated, ultimately resulting in the sum of bandwidth usage for all operation types. Then, this historical usage ratio is used as a weighting basis to redistribute the total bandwidth currently allocated to the target namespace. For example, if historical data shows that read operations consume 70% of the total I / O bandwidth and write operations consume 30%, the newly allocated total bandwidth will be redistributed in the same proportion, ensuring that read operations have 70% of the bandwidth available and write operations have 30%. Through this process, a new set of bandwidth quotas is obtained, clearly specifying the dedicated bandwidth available to each different operation type within the target namespace, thereby ensuring that the current resource allocation matches the actual business access patterns and improving overall performance stability and service quality.

[0051] Operations originating from multiple sources can include both host-side and GC-side operations, and operations of multiple types can include both read and write operations. Therefore, multiple operations can include host-side read operations, host-side write operations, GC-side read operations, and GC-side write operations.

[0052] When multiple operations are host-side read operations, host-side write operations, GC-side read operations, and GC-side write operations, the processing module 23 is specifically used to redistribute the bandwidth of the target namespace according to the total historical bandwidth usage of host-side read operations, the total historical bandwidth usage of host-side write operations, the total historical bandwidth usage of GC-side read operations, and the total historical bandwidth usage of GC-side write operations in the historical operation records, so as to obtain the host-side read bandwidth, host-side write bandwidth, GC-side read bandwidth, and GC-side write bandwidth of the target namespace.

[0053] In one exemplary instance, the received operation request includes: multiple operation sub-requests, and the received operation request is executed according to the allocated bandwidth of the target request type, including:

[0054] For each of the multiple sub-requests included in the received operation request, perform the following operations:

[0055] Obtain the remaining available bandwidth value in the allocated bandwidth of the target request type, and determine whether the obtained remaining available bandwidth value meets the bandwidth requirements of the operation sub-request;

[0056] In response to the determination that the remaining available bandwidth value meets the bandwidth requirement of the operation sub-request, the operation sub-request is executed using the remaining available bandwidth;

[0057] In response to the determination that the remaining available bandwidth does not meet the bandwidth requirements of the operation sub-request, the operation sub-request will be executed after the previous operation sub-request is completed and the bandwidth is released.

[0058] After determining the target request type and its corresponding bandwidth quota for the current operation sub-request, it is necessary to check the real-time bandwidth usage for that type. Specifically, this can be done by first obtaining the portion of the bandwidth allocated to that target request type that is not currently occupied, i.e., the remaining available bandwidth value. Then, this remaining available bandwidth value is compared with the bandwidth requirement of the current operation sub-request to determine whether the existing resources are sufficient to support the immediate execution of the request.

[0059] If the determination result indicates that the remaining available bandwidth meets the bandwidth requirements of the operation sub-request, it means that resources are sufficient and execution can be scheduled immediately. In this case, the remaining bandwidth is used directly to process the operation sub-request, ensuring its efficient and low-latency completion.

[0060] Conversely, if the judgment result indicates that the remaining available bandwidth does not meet the bandwidth requirements of the operation sub-request, it means that the bandwidth resources of this type are currently occupied by other concurrent requests and cannot provide sufficient service guarantees for new requests. In this case, the operation sub-request will not be executed immediately, but will enter a waiting state. It will continue to wait until the previous (or more) operation sub-requests of the same type complete their execution and release the bandwidth resources they occupied, so that the remaining available bandwidth is restored to a level sufficient to meet its needs, before it will be awakened and begin execution.

[0061] This approach enables bandwidth quota-based traffic control and request queuing, effectively preventing resource overload and ensuring predictable service quality.

[0062] In one exemplary instance, the method further includes:

[0063] After executing the received operation request according to the allocated bandwidth of the target request type, the total bandwidth used in the process of completing the received operation request is calculated.

[0064] Update the corresponding historical bandwidth usage in the historical operation record according to the total bandwidth used in completing the received operation request.

[0065] After successfully executing the received operation request within the allocated bandwidth according to the target request type, a feedback and learning process is initiated. First, the resource consumption during this operation is accurately statistically analyzed. This involves calculating and recording the total bandwidth actually used throughout the entire request processing cycle. This "total bandwidth used" includes not only the bandwidth consumed by data transmission itself but may also cover related control overhead, reflecting the true occupancy of the underlying NAND Flash resources for this request. Then, based on the actual consumption data of this operation, the locally maintained historical operation records are dynamically updated. The core update operation is to locate the entry in the historical record that is of the same type as the current request (e.g., read or write), and add its original "total historical bandwidth usage" value to the newly calculated actual bandwidth usage, thus obtaining an updated and more accurate historical cumulative value.

[0066] Through this closed-loop feedback process, historical operation records can continuously reflect the latest I / O behavior patterns, providing real-time and reliable data support for subsequent bandwidth reallocation optimization, enabling resource management strategies to evolve adaptively.

[0067] In one exemplary instance, such as Figure 2 As shown, based on the total historical bandwidth usage of various operation types in the historical operation records, the bandwidth of the target namespace is redistributed to obtain the bandwidth in the target namespace used for different operation types, including:

[0068] Step 200: Determine the bandwidth allocation ratio for different operation types in the target namespace based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace;

[0069] Step 201: Determine whether the bandwidth allocation ratios for different operation types are less than their respective preset lower limits.

[0070] Step 202: In response to the situation that all bandwidth allocation ratios are not less than the corresponding preset lower limit ratio, the bandwidth of the target namespace is allocated according to the bandwidth allocation ratio of different operation types to obtain the bandwidth of the target namespace for different operation types.

[0071] When allocating bandwidth to a target namespace, the first step is to determine the resource allocation for each type of operation. This process is based on the historical operation record table maintained by the target namespace. By analyzing the historical bandwidth usage of various operation types (such as read and write), the proportion of each operation type in the total historical bandwidth usage is calculated, thus determining a preliminary bandwidth allocation ratio. This ratio reflects the past I / O behavior characteristics of the namespace and serves as the basis for dynamic resource allocation.

[0072] To prevent excessive bandwidth compression for certain critical operation types from impacting basic performance, a corresponding safeguard mechanism is implemented. Specifically, the calculated bandwidth allocation ratio for each operation type is compared with its preset minimum safeguard ratio (i.e., the preset lower limit ratio). This lower limit ratio ensures that even if an operation has historically been used infrequently, it still receives the minimum bandwidth resources required to maintain its functionality.

[0073] When the judgment results show that the bandwidth allocation ratio for all operation types is not lower than its corresponding preset lower limit ratio, it indicates that the ratio calculated based on historical data is safe and reasonable. At this point, these ratios will be used to split the total bandwidth allocated to the target namespace, that is, multiply the total bandwidth by the allocation ratio of each type to obtain the dedicated bandwidth value that each operation type can actually use, thus completing the fine-grained bandwidth resource allocation.

[0074] In one exemplary instance, such as Figure 3 As shown, the method further includes:

[0075] Step 300: In response to any bandwidth allocation ratio being less than the corresponding preset lower limit ratio, allocate corresponding bandwidth to the target operation type according to the bandwidth of the target namespace and the corresponding preset lower limit ratio; wherein, the target type refers to the operation type whose bandwidth allocation ratio is less than the corresponding preset lower limit ratio.

[0076] Step 301: Obtain the remaining allocable bandwidth based on the bandwidth of the target namespace and the bandwidth already allocated to the target operation type;

[0077] Step 302: Based on the total historical bandwidth usage of various operation types other than the target operation type in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types other than the target operation type in the target namespace;

[0078] Step 303: Allocate the remaining allocable bandwidth according to the bandwidth allocation ratio of the remaining different operation types to obtain the bandwidth of the target namespace for different operation types other than the target operation type.

[0079] When it is determined that the bandwidth allocation ratio for at least one operation type is lower than its preset minimum guarantee ratio (i.e., preset lower limit ratio), it indicates that directly allocating bandwidth according to historical ratios would compromise the basic service quality of that operation type. At this point, the priority guarantee mechanism is triggered. For all such operation types with "bandwidth allocation ratios less than the preset lower limit" (referred to as target operation types), the calculated historical ratio is no longer used. Instead, sufficient bandwidth is forcibly allocated based on its corresponding preset lower limit ratio and the total bandwidth of the target namespace. Specifically, the bandwidth allocated to each target operation type is equal to the total bandwidth multiplied by its preset lower limit ratio, ensuring it receives a minimum level of resource guarantee.

[0080] After allocating guaranteed bandwidth to all target operation types, a portion of the total bandwidth in the target namespace will remain unallocated. This remaining allocable bandwidth can be calculated by subtracting the total bandwidth allocated to all target operation types from the total bandwidth. This remaining bandwidth will then be allocated to the remaining operation types.

[0081] Next, in order to make reasonable use of the remaining bandwidth, it is necessary to recalculate the allocation ratio of non-target operation types. This process is based on the historical operation record table, but excludes target operation types that have already obtained guaranteed bandwidth, and only counts the relative proportion of the remaining operation types in the historical bandwidth usage, thereby determining the new, adjusted bandwidth allocation ratio among them.

[0082] Finally, the calculated remaining allocable bandwidth is allocated according to these newly determined proportions to obtain the actual available bandwidth for all types of operations in the target namespace, excluding the target operation type.

[0083] In one exemplary instance, determining the bandwidth allocation ratio for different operation types in the target namespace based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace includes:

[0084] Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types in the target namespace;

[0085] or,

[0086] The bandwidth allocation ratio for different operation types in the target namespace is determined based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, the pre-set importance weight of each operation type, and the NAND Flash read / write bandwidth ratio.

[0087] When determining the bandwidth allocation ratio for various operations in a target namespace, a baseline method based on historical behavior can be used. This method directly analyzes the historical operation record table of the target namespace, calculating the total bandwidth occupied by various operation types (such as read and write) in the past. By calculating the proportion of bandwidth occupied by each operation type in the total, a bandwidth allocation ratio reflecting its actual usage frequency and load characteristics can be obtained. This ratio embodies the principle of "the more used, the more allocated," ensuring that resource allocation remains consistent with historical access patterns.

[0088] In addition to the methods mentioned above, a more complex weighted comprehensive method can be used to determine the allocation ratio. This method not only considers the total historical bandwidth usage but also introduces two key factors: first, pre-set importance weights for each operation type to reflect business-level priorities (for example, even if write operations have low historical bandwidth usage, they can be given higher weights because they are crucial for data consistency); second, the inherent read-write bandwidth ratio of the NAND Flash medium, as read operations are generally faster than write operations physically, and this parameter ensures that the allocation scheme matches the actual capabilities of the underlying hardware. The final bandwidth allocation ratio is obtained by comprehensively calculating (e.g., weighted product or normalized summation) the historical bandwidth usage, importance weights, and NAND read-write bandwidth ratio. This method can achieve better resource scheduling by respecting historical patterns while incorporating business needs and hardware characteristics.

[0089] In the current multi-namespace architecture of NAND Flash-based NVMe SSDs, the bandwidth allocation mechanism has several key flaws, severely impacting user experience and system resource utilization efficiency. Specifically:

[0090] First, when different namespaces have significantly different capacities, such as one namespace being 10GB and another 1000GB, existing scheduling strategies typically use a fixed number of commands to poll and execute requests for each namespace, resulting in both receiving the same bandwidth. However, from a practical usage perspective, larger-capacity namespaces often carry higher I / O loads and should be allocated more bandwidth; while smaller-capacity namespaces, due to lower loads, would waste resources if bandwidth were shared equally.

[0091] Secondly, when different namespaces are configured with different logical block address sizes—for example, one namespace has a logical block address of 512 bytes and another has 4096 bytes—if commands are scheduled alternately based solely on the number of logical block address requests, the actual data throughput bandwidth will differ by as much as 8 times. Ideally, given similar namespace capacities, their effective bandwidth should tend to be consistent, rather than becoming unbalanced due to the size of the logical block address.

[0092] Third, flash memory read and write operations exhibit significant time asymmetry; the number of read commands that can be processed in the same amount of time is far greater than the number of write commands. If the scheduling mechanism ignores this characteristic and simply allocates bandwidth based on the number of commands or a fixed quota, it will result in low overall bandwidth utilization and fail to fully realize the input / output potential of the solid-state drive.

[0093] To address the aforementioned issues, this application provides a namespace bandwidth allocation method that rationally allocates bandwidth for namespace operations in various complex scenarios, thereby optimizing user experience and improving SSD utilization efficiency. The overall concept of this method is as follows:

[0094] 1. Calculate the total bandwidth of the SSD's NAND Flash. Since NAND Flash can only perform one operation at a time, either read or write, calculate them separately. Let the read bandwidth of the SSD's NAND Flash be Nr and the write bandwidth be Nw.

[0095] 2. Based on the source of namespace operation requests received by the SSD, they are divided into host-side read / write requests (Hr, Hw) and GC-side read / write requests (Gr, Gw). Among them, Hr, Hw, Gr, and Gw are four types of read / write requests. The SSD uses Hr_use, Hw_use, Gr_use, and Gw_use to record all historical read / write operation requests for this namespace, and uses Hr_remain, Hw_remain, Gr_remain, and Gw_remain to record the available remaining bandwidth for the four types of read / write requests for this namespace.

[0096] 3. Determine if a namespace is in an active state. If the namespace does not perform any operation within a time period of x (which can be preset according to the actual scenario), the namespace is in an idle state; otherwise, the namespace is in an active state.

[0097] 4. When a namespace changes from idle to active, query the size and number of LBAs for that namespace.

[0098] When an SSD receives an operation request for a certain namespace, it will allocate the total bandwidth BW (ns) that the namespace should receive based on the proportion of the capacity of that namespace (LBA size multiplied by the number of LBAs) to the capacity of all active namespaces.

[0099] 5. Classify and record all operation requests for a certain namespace into 4 categories: Hr (host read), Hw (host write), Gr (GC read), and Gw (GC write).

[0100] The above technical concept can be summarized as follows: When the SSD receives an operation request, it first checks which namespace the request belongs to, and then allocates bandwidth according to the proportion of the current namespace's capacity to the total capacity of all active namespaces. The bandwidth available to this namespace is denoted as BW(ns). Next, based on the bandwidth already used, BW(ns) is divided into four types: Hr, Hw, Gr, and Gw. Then, the bandwidth required for the current operation request (multiple operation requests) is calculated. Finally, it is determined whether the bandwidth required for the current operation request is less than the remaining available bandwidth. If the remaining available bandwidth is sufficient to complete the current operation request, the operation request is completed, and the usage ratios of Hr, Hw, Gr, and Gw, as well as the used bandwidth, are updated.

[0101] Based on the above technical concept, this application embodiment also provides a namespace bandwidth allocation method. The NAND Flash bandwidth values ​​Nr and Nw can be configured during SSD power-on initialization according to the NAND Flash manual and actual test values. The default NAND Flash bandwidth allocation is Nw. For write operations, it is used directly; for read operations, the bandwidth is multiplied by Nr / Nw before use. Figure 4 As shown, the method includes:

[0102] Step 400: When the SSD receives a read / write operation request for a namespace, it first determines whether all namespaces are active or idle, and allocates bandwidth according to the proportion of the capacity of the namespace to the capacity of all active namespaces.

[0103] Whenever the SSD completes an operation request for a namespace, it records the time. Every x time interval (x can be set in advance based on experience and usage scenarios), it checks whether the time interval between the current time and the last time the namespace completed a read / write request is greater than y (y can be set in advance based on experience and usage scenarios).

[0104] If the value is greater than y, the namespace is considered to be in an idle state, and the SSD will release the bandwidth of that namespace, meaning the namespace no longer has any available bandwidth. If the value is less than y, the bandwidth of the namespace will be reallocated according to the following rules: bandwidth is allocated based on the proportion of the namespace's capacity to the total capacity of all active namespaces.

[0105] BW(ns)=CAP(ns) / (CAP(ns0)+CAP(ns1)+…CAP(ns_max))

[0106] BW(ns) is the bandwidth allocated to a certain namespace, and CAP(ns0), CAP(ns1)...CAP(ns_max) are the capacities of s namespaces respectively;

[0107] Step 401: Use the record of all completed read and write operation requests in this namespace to determine how much bandwidth each of the four operations will be allocated.

[0108] The bandwidth allocated to each of the four scenarios is determined by the sum of all completed host read history usage (Hr_use), host write history usage (Hw_use), gc read history usage (Gr_use), and gc write history usage (Gw_use) for that namespace. For example, if host read history usage is 50GB, host write history usage is 40GB, gc read history usage is 30GB, and gc write history usage is 20GB, then the latest calculated bandwidth for the four scenarios is Hr_use:Hw_use:Gr_use:Gw_use = Hr_remain:Hw_remain:Gr_remain:Gw_remain = 50:40:30:20, where BW(ns) = Hr_remain + Hw_remain + Gr_remain + Gw_remain. Note that there is a lower limit to the bandwidth allocated in each case. For example, if the lower limit of Hr_remain is z%, then if the bandwidth ratio of Hr_remain obtained by calculation is less than z% of the total bandwidth of the namespace, then the bandwidth of Hr_remain is BW(ns)*z%, and the remaining bandwidth is allocated to the other three cases.

[0109] Step 402: The SSD determines whether the remaining available bandwidth of the namespace is sufficient for the current read / write operation request. If it is sufficient, the current operation request is executed; otherwise, it waits for sufficient bandwidth before proceeding.

[0110] Step 403: When the read / write operation request for this namespace is completed, update the read / write operation request record.

[0111] Record the data bandwidth used in Hr_use, Hw_use, Gr_use, and Gw_use, and modify the values ​​of Hr_remain, Hw_remain, Gr_remain, and Gw_remain.

[0112] The namespace bandwidth allocation method provided in this application addresses the shortcomings of related technologies through the following core mechanism:

[0113] First, initial bandwidth allocation is based on namespace capacity. A base bandwidth weight is set according to the capacity ratio of each namespace, ensuring that large-capacity namespaces receive higher bandwidth matching their expected load and avoiding resource mismatch.

[0114] Second, the method distinguishes four operation types and allocates bandwidth independently. Input and output requests for each namespace are subdivided into four categories: host read, host write, garbage collection read, and garbage collection write. Historical bandwidth usage is recorded for each category, and dedicated bandwidth is dynamically allocated accordingly. Compared to related solutions that allocate a single total bandwidth to the namespace without distinguishing the source of the operation, the bandwidth allocation method for the namespace provided in this application prioritizes the performance of host user operations and suppresses the interference of background garbage collection operations on the user experience.

[0115] Third, a read / write time normalization factor is introduced. Considering that read operation latency in flash memory is much lower than write operation latency, the number of read and write operations that can be completed per unit time is defined, and a normalization factor is introduced. In bandwidth calculation, the bandwidth consumed by each read request is discounted according to this factor, making multiple read operations equivalent to a single write operation in terms of bandwidth usage. This mechanism more realistically reflects physical resource consumption, allowing the system to accommodate more read requests while maintaining the same total bandwidth. This aligns with the typical load characteristics of read operations being a high proportion in practical applications, significantly improving overall bandwidth utilization efficiency and response speed.

[0116] Fourth, dynamic real-time adjustment based on historical load. The system continuously monitors the historical bandwidth usage of each namespace across four types of operations and adjusts bandwidth quotas in real time based on the current load status, achieving adaptive scheduling for complex and changing workloads. Compared to existing static and fixed allocation strategies, this method combines scenario adaptability with dynamic optimization capabilities.

[0117] In summary, the namespace bandwidth allocation method provided in this application achieves more reasonable, efficient, and user-friendly bandwidth allocation in a multi-namespace environment through capacity awareness, operation type differentiation, read-write asymmetry modeling, and dynamic feedback mechanism. It effectively solves the performance bottleneck and resource waste problems caused by rigid bandwidth allocation in related solid-state drives.

[0118] Corresponding to the above-described bandwidth allocation method for namespaces, this application also provides a bandwidth allocation device for namespaces. For example... Figure 5 As shown, the bandwidth allocation device for the namespace includes:

[0119] The receiving module 51 is used to receive an operation request and determine the target namespace of the operation request in the SSD.

[0120] The acquisition module 52 is used to acquire the capacity of the target namespace and the total bandwidth of the NAND Flash end of the SSD, determine the active namespace when the operation request is received, and acquire the total capacity of all active namespaces; wherein, the active namespace refers to the namespace in which data operations occur within a preset time period;

[0121] The acquisition module 52 is also used to acquire the capacity ratio between the capacity of the target namespace and the total capacity of all determined active namespaces;

[0122] The processing module 53 is used to allocate bandwidth to the target command space based on the ratio of the total bandwidth of the NAND Flash terminal to the obtained capacity, and to execute the received operation request based on the allocated bandwidth.

[0123] In one exemplary instance, the acquisition module 52 is further configured to:

[0124] For each namespace in the SSD, obtain the time of the most recent data operation for that namespace, and determine the time difference between the time of the most recent data operation and the current time when the operation request is received; wherein, the data operation includes at least one of the following: reading data and writing data;

[0125] Namespaces with a time difference less than a preset time threshold are identified and designated as active namespaces.

[0126] In one exemplary instance, the processing module 53 is further configured to:

[0127] Obtain the historical operation records of the target command space, and allocate the bandwidth of the target name space according to the request type in the historical operation records;

[0128] Determine the target request type corresponding to the received operation request, and execute the received operation request according to the allocated bandwidth of the target request type.

[0129] In one exemplary instance, the historical operation record is the sum of historical bandwidth usage for multiple operations, and the multiple operations include at least one of the following: operations from multiple operation sources, operations of multiple operation types; the processing module 53 is further configured to redistribute the bandwidth of the target namespace based on the sum of historical bandwidth usage for multiple operation types in the historical operation record, to obtain the bandwidth in the target namespace for different operation types.

[0130] In one exemplary instance, the received operation request includes: multiple operation sub-requests, and the processing module 53 is further configured to:

[0131] For each of the multiple sub-requests included in the received operation request, perform the following operations:

[0132] Obtain the remaining available bandwidth value in the allocated bandwidth of the target request type, and determine whether the obtained remaining available bandwidth value meets the bandwidth requirements of the operation sub-request;

[0133] In response to the determination that the remaining available bandwidth value meets the bandwidth requirement of the operation sub-request, the operation sub-request is executed using the remaining available bandwidth;

[0134] In response to the determination that the remaining available bandwidth does not meet the bandwidth requirements of the operation sub-request, the operation sub-request will be executed after the previous operation sub-request is completed and the bandwidth is released.

[0135] In one exemplary instance, the processing module 53 is further configured to:

[0136] After executing the received operation request according to the allocated bandwidth of the target request type, the total bandwidth used in the process of completing the received operation request is calculated.

[0137] Update the corresponding historical bandwidth usage in the historical operation record according to the total bandwidth used in completing the received operation request.

[0138] In one exemplary instance, the processing module 53 is further configured to:

[0139] Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types in the target namespace;

[0140] Determine whether the bandwidth allocation ratios for different operation types are less than their respective preset lower limits.

[0141] In response to the situation where all bandwidth allocation ratios are not less than the corresponding preset lower limit ratio, the bandwidth of the target namespace is allocated according to the bandwidth allocation ratio of different operation types to obtain the bandwidth of the target namespace for different operation types.

[0142] In one exemplary instance, the processing module 53 is further configured to:

[0143] In response to any bandwidth allocation ratio being less than the corresponding preset lower limit ratio, the corresponding bandwidth is allocated to the target operation type based on the bandwidth of the target namespace and the corresponding preset lower limit ratio; wherein, the target type refers to the operation type whose bandwidth allocation ratio is less than the corresponding preset lower limit ratio.

[0144] The remaining allocable bandwidth is obtained based on the bandwidth of the target namespace and the bandwidth already allocated to the target operation type;

[0145] Based on the total historical bandwidth usage of various operation types other than the target operation type in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types other than the target operation type in the target namespace;

[0146] The remaining allocable bandwidth is allocated according to the bandwidth allocation ratio of the remaining different operation types, so as to obtain the bandwidth of different operation types of the target namespace other than the target operation type.

[0147] In one exemplary instance, the processing module 53 is further configured to:

[0148] Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types in the target namespace;

[0149] or,

[0150] The bandwidth allocation ratio for different operation types in the target namespace is determined based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, the pre-set importance weight of each operation type, and the NAND Flash read / write bandwidth ratio.

[0151] The namespace bandwidth allocation device provided in this application allocates the total bandwidth of the SSD's NAND Flash by obtaining the capacity of the target namespace and the ratio between the total capacity of all active namespaces when the operation request is received. Therefore, it can achieve rational allocation of bandwidth resources, enabling large-capacity namespaces to obtain higher bandwidth matching their data throughput requirements under high-load scenarios, thereby improving their utilization efficiency. At the same time, it avoids resource idleness caused by excessive bandwidth allocation to small-capacity namespaces, effectively improving the overall bandwidth utilization rate and achieving synergistic optimization of storage performance and resource efficiency.

[0152] This application embodiment also provides a bandwidth allocation device such as Figure 6 As shown, it includes: a memory 600 and a processor 610;

[0153] The memory 600 is connected to the processor 610 and is used to store programs;

[0154] The processor 610 is used to implement the namespace bandwidth allocation method described in any of the above embodiments by running the program in the memory 600.

[0155] Specifically, the aforementioned electronic device may also include: a bus, a communication interface 620, an input device 630, and an output device 640.

[0156] The processor 610, memory 600, communication interface 620, input device 630, and output device 630 are interconnected via a bus. Among them:

[0157] A bus can include a pathway for transmitting information between various components of a computer system.

[0158] The processor 610 can be a general-purpose processor, such as a general-purpose central processing unit (CPU), a microprocessor, etc., or an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present invention. It can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0159] The processor 610 may include a main processor, as well as a baseband chip, modem, etc.

[0160] The memory 600 stores a program that executes the technical solution of this invention, and may also store an operating system and other key business functions. Specifically, the program may include program code, which includes computer operation instructions. More specifically, the memory 600 may include read-only memory (ROM), other types of static storage devices capable of storing static information and instructions, random access memory (RAM), other types of dynamic storage devices capable of storing information and instructions, disk storage, Flash memory, etc.

[0161] Input device 630 may include a device for receiving user input data and information, such as a keyboard, mouse, camera, scanner, light pen, voice input device, touch screen, pedometer, or gravity sensor.

[0162] Output device 630 may include devices that allow information to be output to a user, such as a display screen, printer, speaker, etc.

[0163] The communication interface 620 may include a device that uses any transceiver to communicate with other devices or communication networks, such as Ethernet, Radio Access Network (RAN), Wireless Local Area Network (WLAN), etc.

[0164] The processor 610 executes the program stored in the memory 600 and calls other devices, which can be used to implement the various steps of any namespace bandwidth allocation method provided in the above embodiments of this application.

[0165] In addition to the methods and devices described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps in the namespace bandwidth allocation method according to various embodiments of this application as described in any of the foregoing embodiments of this specification.

[0166] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0167] Furthermore, this application also provides a storage medium storing a computer program, which, when executed by a processor, implements the namespace bandwidth allocation method described in any of the above embodiments.

[0168] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A method for bandwidth allocation in a namespace, characterized in that, The method includes: Receive an operation request and determine the target namespace of the operation request in the SSD; Obtain the capacity of the target namespace and the total bandwidth of the SSD's NAND Flash, determine the active namespace when the operation request is received, and obtain the total capacity of all active namespaces; wherein, the active namespace refers to the namespace where data operations occur within a preset time period; Obtain the capacity ratio between the capacity of the target namespace and the total capacity of all determined active namespaces; The bandwidth is allocated to the target namespace based on the ratio of the total bandwidth of the NAND Flash terminal to the obtained capacity, and the received operation request is executed according to the allocated bandwidth; Execute the received operation request based on the allocated bandwidth, including: Obtain the historical operation records of the target namespace, and allocate the bandwidth of the target namespace according to the request type in the historical operation records; Determine the target request type corresponding to the received operation request, and execute the received operation request according to the allocated bandwidth of the target request type; The received operation request includes: multiple operation sub-requests, which are executed according to the allocated bandwidth of the target request type, including: For each of the multiple sub-requests included in the received operation request, perform the following operations: Obtain the remaining available bandwidth value in the allocated bandwidth of the target request type, and determine whether the obtained remaining available bandwidth value meets the bandwidth requirements of the operation sub-request; In response to the determination that the remaining available bandwidth value meets the bandwidth requirement of the operation sub-request, the operation sub-request is executed using the remaining available bandwidth; In response to the determination that the remaining available bandwidth does not meet the bandwidth requirements of the operation sub-request, the operation sub-request will be executed after the previous operation sub-request is completed and the bandwidth is released.

2. The method according to claim 1, characterized in that, Determining the active namespace at the time the operation request is received and obtaining the total capacity of all active namespaces includes: For each namespace in the SSD, obtain the time of the most recent data operation for that namespace, and determine the time difference between the time of the most recent data operation and the current time when the operation request is received; wherein, the data operation includes at least one of the following: reading data and writing data; Namespaces with a time difference less than a preset time threshold are identified and designated as active namespaces.

3. The method according to claim 1, characterized in that, The historical operation record is the sum of historical bandwidth usage for multiple operations, and the multiple operations include at least one of the following: operations from multiple operation sources, and operations of multiple operation types; The bandwidth allocated to the target namespace is determined according to the operation type in the historical operation record, based on the historical operation record. This includes: Based on the total historical bandwidth usage of various operation types in the historical operation records, the bandwidth of the target namespace is redistributed to obtain the bandwidth in the target namespace used for different operation types.

4. The method according to claim 1 or 3, characterized in that, The method further includes: After executing the received operation request according to the allocated bandwidth of the target request type, the total bandwidth used in the process of completing the received operation request is calculated. Update the corresponding historical bandwidth usage in the historical operation record according to the total bandwidth used in completing the received operation request.

5. The method according to claim 3, characterized in that, Based on the total historical bandwidth usage of various operation types in the historical operation records, the bandwidth of the target namespace is redistributed to obtain the bandwidth in the target namespace used for different operation types, including: Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types in the target namespace; Determine whether the bandwidth allocation ratios for different operation types are less than their respective preset lower limits. In response to the situation where all bandwidth allocation ratios are not less than the corresponding preset lower limit ratio, the bandwidth of the target namespace is allocated according to the bandwidth allocation ratio of different operation types to obtain the bandwidth of the target namespace for different operation types.

6. The method according to claim 5, characterized in that, The method further includes: In response to any bandwidth allocation ratio being less than the corresponding preset lower limit ratio, the corresponding bandwidth is allocated to the target operation type based on the bandwidth of the target namespace and the corresponding preset lower limit ratio; wherein, the target type refers to the operation type whose bandwidth allocation ratio is less than the corresponding preset lower limit ratio. The remaining allocable bandwidth is obtained based on the bandwidth of the target namespace and the bandwidth already allocated to the target operation type; Based on the total historical bandwidth usage of various operation types other than the target operation type in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types other than the target operation type in the target namespace; The remaining allocable bandwidth is allocated according to the bandwidth allocation ratio of the remaining different operation types, so as to obtain the bandwidth of different operation types of the target namespace other than the target operation type.

7. The method according to claim 5, characterized in that, Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio for different operation types in the target namespace, including: Based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, determine the bandwidth allocation ratio of different operation types in the target namespace; or, The bandwidth allocation ratio for different operation types in the target namespace is determined based on the total historical bandwidth usage of various operation types in the historical operation record table of the target namespace, the pre-set importance weight of each operation type, and the NAND Flash read / write bandwidth ratio.

8. A namespace bandwidth allocation device, characterized in that, include: A memory and a processor, wherein the memory is used to store an executable program; The processor is used to read and execute the executable program, and to perform the bandwidth allocation method for the namespace as described in any one of claims 1-7.

Images