Interaction method of raid controller, raid controller, electronic device and storage medium

Abstract

This disclosure provides an interaction method for a RAID controller, a RAID controller, an electronic device, and a storage medium, relating to the field of computer technology. The interaction method for a RAID controller, applied to a RAID controller, includes: a hardware layer moving NVMe commands from host memory to a local command queue and sending processing notifications to a software adaptation layer; the software adaptation layer, in response to parsing and determining that the NVMe command is a management command, converting the management command into a RAID array management command and / or a partition file management command, and sending the RAID array management command and / or partition file management command to the RAID software processing layer for execution; and in response to parsing and determining that the NVMe command is an I / O command, parsing the target namespace identifier and read / write address information from the I / O command, converting the I / O command into a read / write command based on the read / write address information, and sending the read / write command to the RAID software processing layer for execution. This approach addresses the storage usage requirements of low cost, high compatibility, and flexible iteration.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to an interaction method for a RAID controller, a RAID controller, an electronic device, and a storage medium. Background Technology

[0002] As data storage scale continues to expand, the industry is placing higher demands on storage system capacity, read / write performance, and data reliability. RAID (Redundant Array of Independent Disks) technology, relying on multi-disk redundancy mechanisms, has become the mainstream storage solution. The RAID controller, as the core component of a RAID system, is responsible for managing data distribution, read / write operations, and fault recovery within the disk array. Existing RAID controllers are mainly divided into three categories: pure software RAID, hardware RAID, and hybrid software / hardware RAID.

[0003] Among them, pure software RAID relies on the host CPU to complete array verification calculations, which can easily lead to performance bottlenecks under high load scenarios, and system failures can directly affect array stability; traditional hardware RAID requires dedicated processing chips, resulting in complex hardware circuits, high development, production and maintenance costs, and the hardware architecture needs to be iterated when changing storage media interfaces, resulting in poor compatibility and scalability; existing hybrid software and hardware RAID solutions mostly bind the core array computing logic to hardware units, with the hardware layer undertaking a large number of RAID calculation tasks, resulting in high hardware design complexity. At the same time, the software and hardware development processes are deeply coupled, and any change in any stage requires simultaneous hardware modification and software adaptation, making it difficult to quickly adapt to new storage protocols such as NVMe. It cannot meet the actual usage needs of low cost, rapid iteration and multi-storage media compatibility. In other words, existing hybrid software and hardware RAID solutions still have the problems of high hardware dependence and complex hardware acceleration units (IPCores), resulting in long overall development and verification cycles and high difficulty in product iteration, updates and maintenance. Summary of the Invention

[0004] This disclosure provides an interaction method for a RAID controller, a RAID controller, an electronic device, and a storage medium to at least solve the above-mentioned technical problems existing in the prior art.

[0005] According to a first aspect of this disclosure, an interaction method for a RAID controller is provided, applied to a RAID controller including a hardware layer, a software adaptation layer, and a RAID software processing layer, the method comprising: In response to the host writing NVMe commands to host memory, the hardware layer moves the NVMe commands from the host memory to the local command queue and sends a processing notification to the software adaptation layer. In response to the processing notification, the software adaptation layer retrieves the NVMe command from the local command queue and parses the NVMe command. In response to the resolution that the NVMe command is a management command, the management command is converted into a RAID array management command and / or a partition file management command, and the RAID array management command and / or partition file management command is sent to the RAID software processing layer for execution; the partition file is mapped to a namespace conforming to the NVMe standard; In response to the determination that the NVMe command is an I / O command, the identifier of the target namespace and the read / write address information are parsed from the I / O command, and the I / O command is converted into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and the read / write command is sent to the RAID software processing layer for execution; The software adaptation layer obtains the execution results of the RAID array management command, partition file management command, or read / write command from the RAID software processing layer, and writes the execution results into the local completion queue of the hardware layer so that the host can obtain the execution results.

[0006] According to a second aspect of this disclosure, a RAID controller is provided, comprising: a hardware layer, a software adaptation layer, and a RAID software processing layer. The hardware layer is configured to, in response to the host writing NVMe commands to host memory, move the NVMe commands from the host memory to the local command queue and send a processing notification to the software adaptation layer. The software adaptation layer is used to respond to the processing notification, retrieve the NVMe command from the local command queue, and parse the NVMe command. The software adaptation layer is further configured to, in response to the determination that the NVMe command is a management command, convert the management command into a RAID array management command and / or a partition file management command, and send the RAID array management command and / or partition file management command to the RAID software processing layer; the partition file is mapped to a namespace conforming to the NVMe standard; The software adaptation layer is further configured to, in response to the determination that the NVMe command is an I / O command, parse the identifier and read / write address information of the target namespace from the I / O command, convert the I / O command into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and send the read / write command to the RAID software processing layer; The RAID software processing layer is used to execute the RAID array management command, the partition file management command, or the read / write command, and return the execution result to the software adaptation layer. The software adaptation layer is also used to obtain the execution result and write the execution result into the local completion queue of the hardware layer; The hardware layer is also used to provide the execution results in the local completion queue to the host.

[0007] According to a third aspect of this disclosure, an electronic device is provided, comprising: a RAID controller as described in this disclosure, the RAID controller being capable of performing the methods described in this disclosure.

[0008] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions for causing the computer to perform the methods described in this disclosure.

[0009] This disclosure discloses an interaction method for a RAID controller, a RAID controller, an electronic device, and a storage medium. The RAID controller is divided into a hardware layer, a software adaptation layer, and a RAID software processing layer. The hardware layer is only responsible for NVMe command transmission and message notification, and does not handle complex RAID calculations such as striping and parity checking, significantly simplifying hardware circuit design and reducing hardware development and production costs. The software adaptation layer completes the conversion of NVMe management commands and I / O commands to Linux software RAID operation instructions, mapping partition files to a standard NVMe namespace. The host can access array resources through a general NVMe interface without modifying the host-side driver. All array calculations and data redundancy logic are implemented by the RAID software processing layer, facilitating rapid iteration and upgrades, and is compatible with various storage media such as SSDs and HDDs. Simultaneously, it distinguishes between query-type management commands and configuration / read / write commands. Query operations directly read the local information database without distributing to the disk, reducing underlying storage access overhead and effectively improving command processing response speed, thus meeting the storage usage requirements of low cost, high compatibility, and flexible iteration.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which: In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts.

[0012] Figure 1 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 1 ; Figure 2 A schematic diagram of the structure of a RAID controller according to an embodiment of the present disclosure is shown; Figure 3 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 2 ; Figure 4 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 3 ; Figure 5 A schematic diagram of the composition structure of an electronic device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0013] To make the objectives, features, and advantages of this disclosure more apparent and understandable, the technical solutions in the embodiments of this disclosure 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 disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0014] Figure 1 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 1 ,like Figure 1 As shown, an interaction method for a RAID controller is applied to the RAID controller, which includes a hardware layer, a software adaptation layer, and a RAID software processing layer. The method includes: In step S101, the hardware layer responds to the host writing the NVMe command to the host memory, moves the NVMe command from the host memory to the local command queue, and sends a processing notification to the software adaptation layer.

[0015] In this embodiment, the RAID controller is a hardware and software integrated controller for managing storage resources. The RAID controller is divided into three layers: the first layer is the hardware layer, which is only responsible for the most basic physical signal transmission and protocol link management; the second layer is the software adaptation layer, which acts as a bridge connecting the hardware layer and the RAID software processing layer; and the third layer is the RAID software processing layer, which is responsible for performing all RAID calculations, stripe splitting, data recovery, and verification tasks. Through this layered structure, the hardware layer does not need to concern itself with the specific RAID algorithm, and the software layer does not need to handle the low-level timing of interaction with the host, achieving functional decoupling between hardware and software.

[0016] In this embodiment, when the NVMe (Non-Volatile Memory Express) driver in the host operating system needs to send instructions to the storage device, a commit queue is built in the host's own memory space, and the specific NVMe command is written into this queue. After the write is completed, the host writes an updated value to the doorbell register in the RAID controller hardware layer to notify the RAID controller that a new command is waiting to be processed. After the host interface management unit inside the hardware layer detects that the doorbell register has been written, it actively reads the newly written NVMe command from the commit queue in the host memory using the address mapped by the PCIe base address register space and the direct memory access engine, and temporarily stores it in the local command queue inside the controller. After the data transfer is completed, the hardware layer sends a processing notification to the software adaptation layer through a physical interrupt signal, informing that a new command is ready to be processed.

[0017] In step S102, the software adaptation layer responds to the processing notification by retrieving NVMe commands from the local command queue and parsing the NVMe commands.

[0018] In this embodiment, the software adaptation layer pre-registers interrupt handling functions corresponding to hardware layer interrupt signals. When the hardware layer issues a processing notification, the software adaptation layer responds to the interrupt by calling its own interrupt service routine or a processing thread awakened by the interrupt service routine, and begins interacting with the hardware layer. The software adaptation layer reads the raw NVMe command from the hardware layer's local command queue by calling the driver interface provided by the hardware layer. Subsequently, the command parsing module in the software adaptation layer decodes the NVMe command according to the command format defined by the NVMe protocol standard. The parsing process includes extracting the command's opcode, which is used to distinguish the command type (Admin command or IO command), and extracting the specific parameters carried by the command, such as the namespace identifier, starting logical block address, and number of logical blocks. After parsing, the command and its parameters are converted into a unified data structure within the software adaptation layer for subsequent routing decisions by the dispatch module.

[0019] In step S103, in response to the NVMe command being determined to be a management command, the management command is converted into a RAID array management command and / or a partition file management command, and the RAID array management command and / or partition file management command is sent to the RAID software processing layer for execution.

[0020] In this embodiment, the software adaptation layer performs branching based on the parsed command opcode. If the command is determined to be an Admin command defined in the NVMe protocol, a conversion operation is performed, mapping the management semantics of the NVMe protocol layer to RAID array management commands or partition file management commands that the underlying Linux operating system can recognize. After conversion, the software adaptation layer sends these system commands to the RAID software processing layer for execution via system call interfaces or kernel interfaces. The management commands are used for controller configuration, querying, and queue management, and do not involve user data transmission. It should be noted that in the data structure of the software adaptation layer, each NVMe namespace has a one-to-one mapping relationship with a specific partition file (e.g., / dev / md0p1) in the Linux system. This partition file is built on a software RAID array composed of underlying physical disks. Therefore, from the host's perspective, this partition file, through the encapsulation of the NVMe standard interface, is completely equivalent to a namespace conforming to the NVMe standard.

[0021] In step S104, in response to the determination that the NVMe command is an I / O command, the identifier of the target namespace and the read / write address information are parsed from the I / O command, and the I / O command is converted into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and the read / write command is sent to the RAID software processing layer for execution.

[0022] In this embodiment, if the software adaptation layer determines that the NVMe command belongs to the I / O command defined in the NVMe protocol, it first extracts the target namespace identifier from the parsed command parameters. The software adaptation layer internally maintains a mapping table that records the association between each activated namespace identifier and its corresponding Linux partition file path. Simultaneously, the software adaptation layer also extracts the starting logical block address and the number of logical blocks to be accessed from the command. Based on the extracted namespace identifier, the software adaptation layer queries the mapping table to determine the target partition file for this I / O operation. Next, the software adaptation layer converts the NVMe read / write command into a standard Linux block device layer read / write request (i.e., constructs a bio request), converting the starting logical block address in the NVMe command into an offset within the partition file during the conversion. Finally, the software adaptation layer sends the read / write request to the RAID software processing layer through the read / write interface. Upon receiving the request, the RAID software processing layer treats it as a read / write operation on a regular block device file.

[0023] In step S105, the software adaptation layer obtains the execution results of the RAID array management commands, partition file management commands, or read / write commands from the RAID software processing layer, and writes the execution results to the local completion queue of the hardware layer so that the host can obtain the execution results.

[0024] In this embodiment, after the RAID software processing layer completes its execution, it returns an execution result. The software adaptation layer obtains this result and encapsulates it into a completion queue element according to the NVMe protocol specification. This completion queue element contains the command's status field, command identifier, and other protocol-required status information. After encapsulation, the software adaptation layer calls the hardware driver interface to write the completion queue element into the hardware layer's local completion queue. When the host interface management unit in the hardware layer detects a new entry in the local completion queue, it can transmit the completion queue element to the corresponding completion queue in the host memory via the PCIe bus. After the transmission is complete, the hardware layer sends an interrupt to the host. The host's NVMe driver reads the completion queue element from the host-side completion queue, thus learning that the command has been processed and obtaining the final execution result.

[0025] In this disclosure, the hardware, software adaptation, and RAID software processing layers are clearly functionally divided, achieving decoupling of the hardware and software architecture. The hardware layer only performs command routing and data transmission, avoiding complex RAID calculation logic, significantly simplifying hardware design, and reducing development difficulty and material costs. The software adaptation layer handles protocol parsing and command conversion, allowing the upper RAID software processing layer to directly utilize the mature Linux software RAID system without needing to concern itself with NVMe protocol details. This architecture enables the core RAID algorithm to be implemented entirely at the software level, facilitating subsequent functional upgrades and iterations. Simultaneously, the software layer can manage various types of physical storage media, giving the RAID controller excellent compatibility and scalability.

[0026] In another embodiment, step S102, "converting management commands into RAID array management commands and / or partition file management commands," includes: In response to a management command instructing RAID array management, the management command is translated into an mdadm array creation command; In response to a management command instructing namespace management, the management command is translated into a parted partitioning command, which is used to generate partition files on the RAID array device.

[0027] In this embodiment, when the software adaptation layer recognizes that the currently processed management command involves RAID array management operations, it executes specific command conversion logic. The management command contains a subtype field or specific parameters to indicate the specific management intent of the command, such as creating a RAID array, deleting a RAID array, expanding a RAID array, migrating a RAID level, or performing consistency checks. When the software adaptation layer parses the management command to indicate RAID array management (e.g., creating a new RAID group), it does not directly manipulate the hardware or storage media. Instead, it converts the NVMe protocol-formatted management command into command-line instructions that the mdadm tool in the Linux system can recognize. mdadm is a standard tool in Linux for managing and monitoring software RAID. Its command-line parameters can precisely specify key attributes such as RAID level (e.g., RAID0, RAID 1, RAID 5, RAID 6), member disk list, stripe size, and array device name. During the conversion process, the software adaptation layer extracts information such as the host's desired RAID level and the number of member disks from the management command parameters and concatenates them into a complete instruction string according to the syntax rules of the mdadm command.

[0028] In this embodiment, when the software adaptation layer parses a current management command instructing namespace management (e.g., creating a namespace, deleting a namespace, or resizing a namespace), the conversion module executes another conversion logic. In the NVMe protocol, a namespace (ns) is a logical storage unit accessible to the host, and each namespace corresponds to a contiguous logical address space. In this disclosure, each namespace corresponds to a partition file in the Linux system. Therefore, when a management command instructs the creation of a new namespace, the software adaptation layer converts it into a parted partitioning command. parted is a commonly used disk partitioning management tool in Linux systems, supporting the creation, deletion, and resizing of partitions on block devices. During the conversion process, the software adaptation layer extracts information such as the namespace size and starting position from the parameters of the management command, and combines this information with the information of the existing RAID array device (e.g., / dev / md0) to construct the corresponding parted command. This parted command is specifically used to create a new partition on the specified RAID array device, which is represented in the system as a partition file (e.g., / dev / md0p1). The newly generated partition file is then mapped to a namespace conforming to the NVMe standard, and subsequent host I / O operations will directly read and write to this partition file. After the conversion is complete, the `parted` command is sent to the RAID software processing layer for execution. The Linux kernel's partition management module then performs the actual partition creation operation, thereby generating the corresponding partition file on the RAID array device.

[0029] In this disclosure, by translating NVMe management commands into mdadm array creation commands and parted partitioning commands respectively, a seamless mapping from NVMe protocol management semantics to Linux software RAID management operations is achieved. This eliminates the need for the RAID controller to reimplement complex array management and partitioning logic at the hardware or firmware layer, instead reusing widely validated system tools, thus significantly reducing the development workload of the software adaptation layer. Furthermore, since mdadm and parted are standard Linux tools, any subsequent additions of new RAID management or partitioning functions only require adding the corresponding conversion logic to the software adaptation layer, without modifying the hardware layer, thus improving flexibility.

[0030] In another embodiment, after "parse and determine that the NVMe command is a management command" in step S103, the method further includes: In response to management commands instructing a namespace query or controller query, the system reads the locally pre-stored namespace information database or controller information database, and performs the namespace query or controller query based on the namespace information database or controller information database to obtain the corresponding query results.

[0031] In this embodiment, the software adaptation layer pre-maintains a namespace information database (ns_info) and a controller information database (controller_info). The namespace information database records parameters such as the size, capacity, attributes, whether it has been created, and whether it has been bound for each currently created namespace. The controller information database records attribute configuration information such as the data page size, number of queues, and queue depth supported by the controller. When the software adaptation layer parses the current management command as an Identify command, it recognizes that the command indicates a namespace query or a controller query. At this time, the software adaptation layer does not issue any system commands to the RAID software processing layer, but directly reads the required data from the locally pre-stored namespace information database or controller information database. If the command requests information about a specific namespace, the software adaptation layer searches for and extracts the corresponding record from the namespace information database based on the namespace identifier carried in the command; if the command requests information about the controller, the software adaptation layer directly reads the corresponding fields from the controller information database. After the reading is complete, the software adaptation layer assembles the information from the local database according to the Identify command response data format specified by the NVMe protocol to obtain the corresponding query results, which are then encapsulated into completion queue elements and returned to the host.

[0032] In this embodiment, the software adaptation layer is generally divided into two layers (e.g., Figure 2 As shown in the diagram, the driver layer and the translation layer (processing module) are respectively the driver layer and the translation layer. The driver layer acts as a bridge between the translation layer and the hardware, providing interfaces for accessing and controlling the hardware, including reading and writing NVMe controller registers, dequeuing IOSQE (I / O Submission Queue Element), enqueuing IOCQE (I / O Completion Queue Element), dequeuing ASQE (Admin Submission Queue Element), and enqueuing ACQE (Admin Completion Queue Element).

[0033] The data structures in the software adaptation layer may include: a) ns_info: Records parameters such as the size, capacity, attributes, whether it has been created, and whether it is bound to a namespace. It uses file descriptors to represent the mapping relationship between namespaces and device files. Information is read from this data structure when responding to the host's `identify namespace` command. b) raid_info: Describes the size, level, number of member disks, etc. of the mapped RAID group; c) controller_info: Records the controller's supported data page size, number of queues, queue depth and other attribute configuration information. Information is read from this data structure when responding to the host's identify controller command.

[0034] In this disclosure, by pre-storing namespace and controller information bases locally within the software adaptation layer, Identify query commands do not need to be sent to the RAID software processing layer to perform any actual operations; the response can be completed directly at the software adaptation layer. This approach significantly reduces the response latency of query commands, improves system performance, avoids unnecessary system call overhead, and simplifies the processing flow.

[0035] In another embodiment, step S103, "converting I / O commands into read / write commands for the partition file corresponding to the target namespace based on read / write address information," includes: The logical block address in the read / write address information is converted into the block device address of the corresponding partition file, a standard I / O request for the adapted block device is generated, and the standard I / O request is identified as a read / write command.

[0036] In this embodiment, the software adaptation layer obtains the starting logical block address (slba) and the number of logical blocks (nlb) from the parsed I / O commands as read / write address information. After querying the mapping table based on the target namespace identifier (nsid), the software adaptation layer determines the partition file corresponding to the namespace (e.g., / dev / md0p1). To convert NVMe read / write commands into read / write operations recognizable by the Linux block device layer, the software adaptation layer needs to convert the logical block address used in the NVMe command into the block device address offset within the partition file. This conversion is calculated based on the starting sector offset of the partition file in the RAID array device. Specifically, the block device address within the partition file equals the starting logical block address in the NVMe command plus the starting sector number of the partition on the RAID array device. After the conversion, the software adaptation layer uses the converted block device address, the number of logical blocks, and the data direction (read or write) information carried in the I / O command to construct a standard Linux block device layer I / O request data structure (i.e., a bio request). The bio request contains complete address mapping information, data buffer pointers, and operation types, fully conforming to the input specifications of the Linux kernel block device subsystem. After construction, the software adaptation layer identifies the bio request as a translated read / write command and sends it to the RAID software processing layer for execution.

[0037] In this disclosure, by mapping logical block addresses in the NVMe protocol to block device addresses recognizable by the Linux block device layer and generating standard bio requests, a seamless conversion from NVMe I / O commands to Linux block device read / write operations is achieved. This conversion method eliminates the need for the RAID software processing layer to be aware of whether the upper-layer protocol is NVMe or another storage protocol; it only needs to process bio requests according to the standard block device interface. This further reduces the coupling between the software adaptation layer and the RAID software processing layer, improving system compatibility and maintainability.

[0038] In another embodiment, the RAID software processing layer executes read and write commands in the following manner: The read and write commands are split into RAID stripes and parity checks, and the split read and write commands are distributed to different storage media to complete data read and write. The storage media include at least one of SSD, HDD and SD card.

[0039] In this embodiment, after receiving the standard block device read / write request (i.e., BIO request) from the software adaptation layer, the RAID software processing layer begins to execute the actual RAID data processing logic. First, based on the current RAID array configuration information (including RAID level, stripe size, number of member disks, etc.), the RAID software processing layer performs stripe splitting calculations on the data address range involved in the read / write request. Specifically, the RAID software processing layer divides the block device address in the request into multiple stripe units according to the stripe size, and calculates the target member disk number and offset position on that disk corresponding to each stripe unit. For write requests, the RAID software processing layer also performs parity calculations according to the RAID level (e.g., RAID 5 or RAID 6) to generate corresponding parity data. After completing stripe splitting and parity calculations, the RAID software processing layer distributes the original data blocks and parity data blocks to different underlying storage media. The distribution operation is completed through the general block request interface of the Linux block device layer, and each distributed sub-request corresponds to an actual read / write operation on a physical storage medium. The specific type of the underlying storage medium is not limited; it can be HDD (Hard Disk Drive), SSD (Solid State Drive), SD (Secure Digital) card, etc. The RAID software processing layer achieves unified access to the above different media types through the unified block device abstraction layer of the Linux kernel.

[0040] In this disclosure, striping and parity calculations are performed by the RAID software processing layer, and the complex RAID calculation tasks are completely handled by the software. This eliminates the need for the hardware layer to integrate any RAID calculation logic, thus achieving extreme lightweighting of the hardware layer.

[0041] In another embodiment, step S105, "writing the execution result to the local completion queue of the hardware layer so that the host can obtain the execution result," includes: The software adaptation layer encapsulates the execution results into NVMe completion entries and writes them into the hardware layer's local completion queue; The hardware layer notifies the host to read the execution results in the local completion queue via PCIe interrupts.

[0042] In this embodiment, after the RAID software processing layer executes a management command or I / O command, it returns an execution status code (execution result) to the software adaptation layer. This execution status code indicates whether the command execution was successful, failed, or has a specific error type. After obtaining the execution status code, the software adaptation layer needs to convert it into completion information that the host can recognize, according to the NVMe protocol standard. Specifically, the software adaptation layer fills the status field in the completion queue element according to the execution status code, and simultaneously fills the command identifier (Command ID) from the original NVMe command into the corresponding field in the completion queue element, so that the host can match the completion response with the previously issued command. After filling all fields, the software adaptation layer writes the assembled complete CQE (Completion Queue Element) data into the hardware layer's local completion queue, such as IOCQ (I / O Completion Queue) or ACQ (Admin Completion Queue). This queue is a hardware-maintained circular buffer used to temporarily store completion entries to be sent to the host.

[0043] In this embodiment, after the software adaptation layer writes the encapsulated NVMe completion entry into the local completion queue of the hardware layer, it sends a notification to the hardware layer that a new entry is ready. Upon detecting a new completion entry to be sent in the local completion queue, the host interface management unit of the hardware layer moves the completion entry from the local completion queue to the corresponding pre-allocated completion queue (CQ) in the host memory via the PCIe bus. After the data transfer is complete, the hardware layer sends an interrupt request to the host CPU via the PCIe interface. Upon receiving the interrupt, the host CPU calls the interrupt handler function of its NVMe driver to read the NVMe completion entry from the host-side completion queue. At this point, the host knows that the previously issued NVMe command has been processed and learns the final result of the command execution by reading the status field in the completion entry, thus completing a full command interaction cycle.

[0044] In this disclosure, the execution result is encapsulated into a completion entry conforming to the NVMe protocol through a software adaptation layer, and then the host is actively notified to read it via a PCIe interrupt mechanism through a hardware layer, thus achieving standardized reporting of command completion information. This interrupt-driven mechanism eliminates the need for the host to poll and wait for command completion, reducing host CPU overhead and improving system responsiveness, real-time performance, and overall I / O efficiency. Simultaneously, the hardware layer is only responsible for transporting completion entries and triggering interrupts, without participating in any completion information generation logic, maintaining a lightweight hardware layer design.

[0045] In another embodiment, before "parse and determine that the NVMe command is a management command" in step S103, the method further includes: Establish a mapping relationship between file descriptors of partitioned files and namespace identifiers, and store the mapping relationship in the data structure of the software adaptation layer.

[0046] In this embodiment, during the initialization phase after system startup or RAID array creation, the software adaptation layer needs to establish a mapping between partition files and NVMe namespaces. After the RAID software processing layer creates a RAID array (e.g., / dev / md0) using mdadm, the software adaptation layer creates partitions on the RAID array device using the parted command, generating corresponding partition files (e.g., / dev / md0p1, / dev / md0p2, etc.). Each partition file is mapped to an independent NVMe namespace. To achieve this mapping, the software adaptation layer calls the Linux system's open system call to open the partition file and obtain a corresponding file descriptor. Simultaneously, the software adaptation layer assigns a namespace identifier (nsid) conforming to the NVMe protocol specification to this namespace. Subsequently, the software adaptation layer records the file descriptor and namespace identifier as key-value pairs in a locally maintained mapping data structure (e.g., the ns_info structure). This data structure also synchronously records parameter information such as the size, capacity, and attributes of the namespace, which is used to respond to the host's Identify command. Once the mapping relationship is established, when the host issues an I / O command, the software adaptation layer can query the mapping relationship based on the NSID in the command, quickly find the corresponding file descriptor, and then locate the target partition file for read and write operations. When the host issues a management command to create a new namespace, the software adaptation layer will also update the mapping relationship data structure synchronously, adding new NSID and file descriptor records.

[0047] In this disclosure, by pre-establishing and maintaining the mapping relationship between file descriptors and namespace identifiers in the data structure of the software adaptation layer, the software adaptation layer can quickly index the corresponding partition file through the NSID when subsequent host I / O commands arrive. This avoids complex path lookups and file opening operations for each I / O operation, significantly improving the efficiency of command translation. Simultaneously, the centralized storage of this mapping relationship facilitates unified management of namespaces, providing a data foundation for subsequent namespace addition, deletion, and modification operations.

[0048] In another embodiment, the local command queue includes a management commit queue and an I / O commit queue, and step S101, "moving NVMe commands from host memory to the local command queue," includes: The hardware layer monitors write events to the host's doorbell register; If an update to the doorbell register corresponding to the management commit queue is detected, the NVMe command is moved from the host memory to the management commit queue. If an update to the doorbell register corresponding to the I / O submission queue is detected, the NVMe command is moved from host memory to the I / O submission queue.

[0049] In this embodiment, the host interface management unit within the hardware layer continuously monitors the doorbell register. The doorbell register is a core mechanism in the NVMe protocol used for communication between the host and controller. Each time the host writes one or more commands to the commit queue, it notifies the controller by writing a new tail pointer value to the corresponding doorbell register. The hardware layer uses combinational logic or state machine design to detect write operation events at these register addresses in real time. Once a write operation is detected, it is considered that a new host command needs to be processed. The monitoring process requires no software intervention and is entirely autonomously performed by the hardware layer, ensuring extremely low event response latency.

[0050] In this embodiment, management commands from the host are issued through the Management Submission Queue (ASQ). Once the hardware layer detects that the SQ0TDBL doorbell register corresponding to the management submission queue has been updated by the host, it immediately initiates a read operation. Based on the base address and queue depth information of the host-side management submission queue configured in the controller's ASQ register, the hardware layer reads the newly enqueued ASQ element (i.e., the management command) from the specified address in the host memory. After reading, the hardware layer writes the management command into the hardware's local ASQ circular buffer in the enqueue order, awaiting processing by the software adaptation layer. During this process, the hardware layer is responsible for maintaining the read / write pointer state of the queue, ensuring that commands are stored in order and do not overwrite unprocessed historical commands.

[0051] In this embodiment, host-side I / O commands are issued through the I / O Submission Queue (IOSQ). After the hardware layer detects that the SQ1TDBL doorbell register corresponding to the I / O Submission Queue has been written to and updated by the host, it initiates a read operation to retrieve the SQE (i.e., I / O command) from the host-side I / O Submission Queue and move it to the hardware's local IOSQ circular buffer. It should be noted that for I / O commands, the hardware layer moves the command from the host's IOSQ to its local IOSQ (not the IOCQ). Only after the command execution is complete will the software adaptation layer write the completion entry to the local IOCQ.

[0052] In this disclosure, real-time detection of host command arrival is achieved by independently monitoring doorbell register write events at the hardware layer, avoiding CPU overhead and response latency caused by software polling. Simultaneously, management commands and I / O commands are distinguished based on the doorbell register type and transported to different local queues. This allows the software adaptation layer to quickly identify command types and dispatch them to the corresponding processing modules during subsequent processing, improving the processing efficiency and workflow clarity of the software adaptation layer.

[0053] Figure 3 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 2 ,like Figure 3 As shown, the execution process for the Admin command is as follows: The host writes the ASQE corresponding to the management command into the ASQ queue in the host memory and updates the NVMe doorbell register to notify the device that a new command is pending. After detecting that the doorbell register has been written, the host interface management unit (hardware layer) moves the ASQE from the host side to the local ASQ ring for temporary storage. Subsequently, the host interface management unit triggers an interrupt to notify the software adaptation layer. The command parsing module of the software adaptation layer calls the interface provided by the driver layer to dequeue the ASQE from the local ASQ ring and parses the ASQE to obtain the specific command type and parameters. After parsing, the dispatch module selects a branch based on the command type.

[0054] If the command type is a RAID create command, the dispatch module converts the management command into instructions executable by the mdadm command-line tool, such as "mdadm -create / dev / md0 --level=1 --raid-devices=2 / dev / nvme0n1 / dev / nvme0n2", and sends these instructions to the RAID software processing layer for execution. If the command type is a namespace create command, the dispatch module converts the management command into instructions executable by the parted partitioning tool, such as "parted / dev / md0 mkpart primary 0% 100%", and generates the corresponding partition file on the RAID array device. This partition file is mapped to a namespace conforming to the NVMe standard. If the command type is an identify namespace command, the dispatch module does not call any system tools, but directly reads the data structure (e.g., ns_info) pre-stored locally by the software adaptation layer to obtain information such as the size, capacity, and attributes of the namespace as the query result.

[0055] Regardless of the command type, the RAID software processing layer returns the execution result to the software adaptation layer after completion. The software adaptation layer assembles the queue element ACQE according to the NVMe protocol standard based on the command execution result and enqueues the ACQE into the local ACQ Ring by calling the driver layer interface. When the host interface management unit detects a new completion entry in the local ACQ Ring, it moves the local ACQE to the ACQ Ring in the host memory (i.e., the completion queue on the host side). Subsequently, the hardware layer notifies the host to read the ACQE from the ACQ Ring via a PCIe interrupt, allowing the host to know that the management command has been processed and obtain the final execution status.

[0056] Figure 4 This disclosure illustrates a flowchart of an interaction method for a RAID controller according to an embodiment of the present disclosure. Figure 3 ,like Figure 4 As shown, the execution process of I / O commands is as follows: The host writes the IOSQE corresponding to the I / O command to the IOSQ queue in the host memory and updates the NVMe doorbell register to notify the device that there is a new command to be processed. After the host interface management unit (hardware layer) detects that the doorbell register has been written, it moves the IOSQE on the host side to the local IOSQ Ring for temporary storage. Subsequently, the host interface management unit triggers an interrupt, waking up the I / O command processing module in the software adaptation layer.

[0057] The I / O command processing module calls the interface provided by the driver layer to dequeue the IOSQE from the local IOSQ Ring and parses it to extract parameters such as the namespace identifier nsid, the starting logical block address slba, and the number of logical blocks nlb. After parsing, the I / O command processing module queries the local mapping relationship based on nsid to determine the target partition file corresponding to the namespace (e.g., / dev / md0p1), and converts the starting logical block address slba in the NVMe command into the block device address inside the partition file.

[0058] After address translation is completed, the I / O command processing module constructs a standard Linux block device layer bio request and sends the read / write request to the target partition file / dev / md0p1. This request then enters the software RAID layer, which performs striping and parity calculations on the request according to the RAID array configuration, and distributes the split sub-requests to different underlying physical disks to complete the actual data read / write operations.

[0059] After the read / write operation is completed, the software RAID layer returns the execution result to the I / O command processing module. Based on this result, the I / O command processing module assembles the queue element IOCQE according to the NVMe protocol standard and enqueues the IOCQE into the hardware's local IOCQ Ring by calling the driver layer interface. When the host interface management unit detects a new completion entry in the local IOCQ Ring, it moves the local IOCQE to the IOCQ Ring in the host memory (i.e., the host-side completion queue). Subsequently, the hardware layer notifies the host to read the IOCQE from the IOCQ Ring via a PCIe interrupt, allowing the host to know that the I / O command has been processed and obtain the final execution status.

[0060] It is important to emphasize that in this disclosure, Linux abstracts all storage devices, whether physical disks, RAID groups, or namespaces, into a unified block device file. This disclosure maps host control flow and data flow: In Linux, ` / dev / nvme0n1` is equivalent to a physical disk; ` / dev / mdX` is a RAID group created using `mdadm`, composed of physical disks; other management commands such as deleting, expanding, migrating RAID levels, and performing consistency checks on RAID groups can also be converted into `mdadm` operations; a partition created on the device ` / dev / mdX` represents an independent logical volume, and one namespace corresponds to a device file like ` / dev / mdXnY`; `attach namespace` is equivalent to opening the namespace device file, and the obtained file descriptor is recorded in a software data structure; `detach namespace` is equivalent to closing the file descriptor, releasing resources. Host read / write I / O requests are performed by reading and writing to the namespace device file through the already opened file descriptors.

[0061] Figure 2 A schematic diagram of the structure of a RAID controller according to an embodiment of the present disclosure is shown, as follows: Figure 2 As shown, a RAID controller includes: Hardware layer, software adaptation layer, and RAID software processing layer: The hardware layer is used to respond to the host writing NVMe commands to the host memory, move NVMe commands from the host memory to the local command queue, and send processing notifications to the software adaptation layer. The software adaptation layer is used to respond to and process notifications, retrieve NVMe commands from the local command queue, and parse the NVMe commands. The software adaptation layer is also used to convert the management command into a RAID array management command and / or partition file management command in response to the resolution that the NVMe command is a management command, and then send the RAID array management command and / or partition file management command to the RAID software processing layer; the partition file is mapped to a namespace that conforms to the NVMe standard; The software adaptation layer is also used to respond to the NVMe command being determined to be an I / O command by parsing the target namespace identifier and read / write address information from the I / O command, and convert the I / O command into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and send the read / write command to the RAID software processing layer; The RAID software processing layer is used to execute RAID array management commands, partition file management commands, or read / write commands, and return the execution results to the software adaptation layer. The software adaptation layer is also used to obtain the execution results and write them into the local completion queue of the hardware layer. The hardware layer is also used to provide the execution results in the local completion queue to the host.

[0062] In another embodiment, the software adaptation layer is also used for: In response to a management command instructing RAID array management, the management command is translated into an mdadm array creation command; In response to a management command instructing namespace management, the management command is translated into a parted partitioning command, which is used to generate partition files on the RAID array device.

[0063] In another embodiment, the software adaptation layer is also used for: In response to management commands instructing a namespace query or controller query, the system reads the locally pre-stored namespace information database or controller information database, and performs the namespace query or controller query based on the namespace information database or controller information database to obtain the corresponding query results.

[0064] In another embodiment, the software adaptation layer is also used for: The logical block address in the read / write address information is converted into the block device address of the corresponding partition file, a standard I / O request for the adapted block device is generated, and the standard I / O request is identified as a read / write command.

[0065] In another embodiment, the RAID software processing layer is also used for: The read and write commands are split into RAID stripes and parity checks, and the split read and write commands are distributed to different storage media to complete data read and write. The storage media include at least one of SSD, HDD and SD card.

[0066] In another embodiment, the software adaptation layer is also used to: encapsulate the execution result into an NVMe completion entry and write it into the local completion queue of the hardware layer; The hardware layer is also used to: notify the host to read the execution results in the local completion queue via PCIe interrupts.

[0067] In another embodiment, the software adaptation layer is also used to: establish a mapping relationship between file descriptors of partition files and identifiers of namespaces, and store the mapping relationship in the data structure of the software adaptation layer.

[0068] In another embodiment, the local command queue includes a management commit queue and an I / O commit queue. The hardware layer is also used to: monitor write events to the host's doorbell register; if a doorbell register update corresponding to the management commit queue is detected, move the NVMe command from the host memory to the management commit queue; if a doorbell register update corresponding to the I / O commit queue is detected, move the NVMe command from the host memory to the I / O commit queue.

[0069] like Figure 2 As shown, the RAID controller in this disclosure is logically divided into three layers: a hardware layer, a software adaptation layer, and a RAID software processing layer. The host is connected to the RAID controller via a PCIe bus. The host memory maintains four queues: ASQ, ACQ, IOSQ, and IOCQ, which are used for the submission and completion of management commands and the submission and completion of I / O commands, respectively.

[0070] The hardware layer internally includes NVMe standard registers, a host interface management unit, a data transfer unit, and corresponding local circular queues and data spaces. The NVMe standard registers are used to report controller capabilities, version information, and status information to the host, while also receiving configuration parameters and doorbell writes from the host. The host interface management unit monitors write events to the doorbell register and triggers corresponding command transfer operations based on doorbell updates. The data transfer unit transfers commands and completion entries between the host memory queue and the hardware's local circular queue. The hardware layer's local circular queues include the ASQ Ring, ACQ Ring, IOSQ Ring, and IOCQ Ring, corresponding to the four queues on the host side, used to temporarily store commands transferred from the host and completion entries to be sent back to the host. The data space is used to temporarily store user data corresponding to I / O commands.

[0071] The software adaptation layer includes the host interface unit I / O driver, the data transport unit I / O driver, the Admin command processing module, and the IO command processing module. The host interface unit I / O driver provides the interface for reading and writing NVMe controller registers, while the data transport unit I / O driver provides the interface for command dequeueing and entry enqueueing. The Admin command processing module is responsible for parsing management commands issued by the host, converting them into mdadm or parted commands based on the command type, or reading local data structures to respond to identify queries. The IO command processing module is responsible for parsing I / O commands issued by the host, performing the mapping from namespace identifiers to partition files and the conversion from logical block addresses to block device addresses, and constructing a bio request to send to the RAID software processing layer.

[0072] The RAID software processing layer comprises multiple RAID array devices (e.g., / dev / md0, / dev / md1), each with multiple partition files (e.g., / dev / md0p1, / dev / md0p2, / dev / md1p1, / dev / md1pN). Each partition file is mapped to an NVMe-compliant namespace, serving as the final target for I / O commands from the software adaptation layer. Upon receiving read / write requests, the RAID software processing layer performs striping and parity calculations, distributing the data to various underlying storage media, including SSDs, HDDs, and SD cards, thereby completing the actual data storage and retrieval operations.

[0073] In this embodiment, the hardware layer only provides interfaces for host access to the controller and data transmission; it does not perform any RAID calculations. The functions of the hardware layer are as follows: 1. Implement the controller registers defined in the NVMe protocol, as shown in Table 1 below. CAP is used to report controller capabilities to the host, VS reports the current NVMe protocol version used by the controller to the host, and CC is a register used by the host to configure controller characteristics. The specific values ​​of these registers are filled during hardware initialization. The host accesses device registers through the BAR space. CSTS describes the controller state and is used to establish communication between the host and the controller.

[0074] Table 1

[0075] 2. Implement queue management and data transfer functions, detect the write to the SQ Tail DB register (commit queue tail bell register), move host commands to the local IOSQ queue or ASQ queue; process the completion information of the command completed by the processing software, and send the CQE in the local IOCQ queue or ACQ queue to the host.

[0076] According to embodiments of this disclosure, this disclosure also provides an electronic device and a readable storage medium.

[0077] Figure 5 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0078] like Figure 5 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804. The electronic device also includes a RAID controller as disclosed in this disclosure, which is capable of executing an interaction method for a RAID controller as disclosed in this disclosure.

[0079] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, such as keyboard, mouse, etc.; output unit 807, such as various types of displays, speakers, etc.; storage unit 808, such as disk, optical disk, etc.; and communication unit 809, such as network card, modem, wireless transceiver, etc. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0080] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc.

[0081] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0082] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0083] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0084] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0085] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0086] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0087] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0088] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise explicitly specified.

[0089] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. An interaction method for a RAID controller, characterized in that, Applied to a RAID controller, the RAID controller comprising a hardware layer, a software adaptation layer, and a RAID software processing layer, the method includes: In response to the host writing NVMe commands to host memory, the hardware layer moves the NVMe commands from the host memory to the local command queue and sends a processing notification to the software adaptation layer. In response to the processing notification, the software adaptation layer retrieves the NVMe command from the local command queue and parses the NVMe command. In response to the resolution that the NVMe command is a management command, the management command is converted into a RAID array management command and / or a partition file management command, and the RAID array management command and / or partition file management command is sent to the RAID software processing layer for execution; the partition file is mapped to a namespace conforming to the NVMe standard; In response to the determination that the NVMe command is an I / O command, the identifier of the target namespace and the read / write address information are parsed from the I / O command, and the I / O command is converted into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and the read / write command is sent to the RAID software processing layer for execution; The software adaptation layer obtains the execution results of the RAID software processing layer on the RAID array management command, partition file management command or read / write command, and writes the execution results into the local completion queue of the hardware layer so that the host can obtain the execution results; Before the NVMe command is determined to be a management command through parsing, the method further includes: Establish a mapping relationship between the file descriptors of the partition files and the identifiers of the namespaces, and store the mapping relationship in the data structure of the software adaptation layer.

2. The method according to claim 1, characterized in that, The step of converting the management commands into RAID array management commands and / or partition file management commands includes: In response to the management command instructing RAID array management, the management command is converted into an mdadm array creation command; In response to the management command instructing namespace management, the management command is converted into a parted partitioning command, which is used to generate partition files on the RAID array device.

3. The method according to claim 1, characterized in that, After the parsing determines that the NVMe command is a management command, the method further includes: In response to the management command instructing a namespace query or controller query, the system reads the locally pre-stored namespace information database or controller information database, and performs a namespace query or controller query based on the namespace information database or controller information database to obtain the corresponding query results.

4. The method according to claim 1, characterized in that, The step of converting the I / O command into a read / write command for the partition file corresponding to the target namespace based on the read / write address information includes: The logical block address in the read / write address information is converted into the block device address of the corresponding partition file, a standard I / O request adapted to the block device is generated, and the standard I / O request is determined as the read / write command.

5. The method according to claim 1, characterized in that, The RAID software processing layer executes the read and write commands in the following manner: The read / write commands are subjected to RAID striping and parity checks, and the split read / write commands are distributed to different storage media to complete data read / write operations; the storage media include at least one of SSD, HDD and SD card.

6. The method according to claim 1, characterized in that, The step of writing the execution result into the local completion queue of the hardware layer so that the host can obtain the execution result includes: The software adaptation layer encapsulates the execution result into an NVMe completion entry and writes it into the local completion queue of the hardware layer. The hardware layer notifies the host to read the execution results in the local completion queue via a PCIe interrupt.

7. The method according to claim 1, characterized in that, The local command queue includes a management commit queue and an I / O commit queue. Moving the NVMe command from the host memory to the local command queue includes: The hardware layer monitors write events to the host's doorbell register; If an update to the doorbell register corresponding to the management commit queue is detected, the NVMe command is moved from the host memory to the management commit queue. If an update to the doorbell register corresponding to the I / O submission queue is detected, the NVMe command is moved from the host memory to the I / O submission queue.

8. A RAID controller, characterized in that, The RAID controller includes: Hardware layer, software adaptation layer, and RAID software processing layer: The hardware layer is configured to, in response to the host writing NVMe commands to host memory, move the NVMe commands from the host memory to the local command queue and send a processing notification to the software adaptation layer. The software adaptation layer is used to respond to the processing notification, retrieve the NVMe command from the local command queue, and parse the NVMe command. The software adaptation layer is further configured to, in response to the determination that the NVMe command is a management command, convert the management command into a RAID array management command and / or a partition file management command, and send the RAID array management command and / or partition file management command to the RAID software processing layer; the partition file is mapped to a namespace conforming to the NVMe standard; The software adaptation layer is further configured to, in response to the determination that the NVMe command is an I / O command, parse the identifier and read / write address information of the target namespace from the I / O command, convert the I / O command into a read / write command for the partition file corresponding to the target namespace based on the read / write address information, and send the read / write command to the RAID software processing layer; The RAID software processing layer is used to execute the RAID array management command, the partition file management command, or the read / write command, and return the execution result to the software adaptation layer. The software adaptation layer is also used to obtain the execution result and write the execution result into the local completion queue of the hardware layer; The hardware layer is also used to provide the execution results in the local completion queue to the host; The software adaptation layer is further configured to establish a mapping relationship between the file descriptors of the partition files and the identifiers of the namespaces, and store the mapping relationship in the data structure of the software adaptation layer.

9. The RAID controller according to claim 8, characterized in that, The software adaptation layer is also used for: In response to the management command instructing RAID array management, the management command is converted into an mdadm array creation instruction; In response to the management command instructing namespace management, the management command is converted into a parted partitioning command, which is used to generate partition files on the RAID array device.

10. The RAID controller according to claim 8, characterized in that, The software adaptation layer is also used for: In response to the management command instructing a namespace query or controller query, the system reads the locally pre-stored namespace information database or controller information database, and performs a namespace query or controller query based on the namespace information database or controller information database to obtain the corresponding query results.

11. The RAID controller according to claim 8, characterized in that, The software adaptation layer is also used for: The logical block address in the read / write address information is converted into the block device address of the corresponding partition file, a standard I / O request adapted to the block device is generated, and the standard I / O request is determined as the read / write command.

12. The RAID controller according to claim 8, characterized in that, The RAID software processing layer is also used for: The read / write commands are subjected to RAID striping and parity checks, and the split read / write commands are distributed to different storage media to complete data read / write operations; the storage media include at least one of SSD, HDD and SD card.

13. An electronic device, characterized in that, include: The RAID controller according to any one of claims 8-12 is capable of performing the method according to any one of claims 1-7.

14. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images