System disk mounting method and related device

Abstract

The application discloses a system disk mounting method and related equipment, and relates to the technical field of diskless computing system, and the method comprises the following steps: in response to the power-on of a computing node, a target session identifier is allocated to the computing node, and the target session identifier and system disk metadata are written into a preset mailbox register; a takeover request generated by the computing node based on information in the preset mailbox register is received; after the takeover request is verified, the input and output path of the target system disk of the computing node is switched from a first channel to a second channel, and second channel connection parameters are generated; the second channel connection parameters are sent to the computing node, so that the computing node mounts the target system disk based on the second channel connection parameters; and in the process that the computing node mounts the target system disk, a write protection differential mounting is performed on the target system disk. The application can realize system disk image sharing, node data isolation and safe and reliable management of system disks.

Description

Technical Field

[0001] This application relates to the field of diskless computing system technology, and more specifically, to a system disk mounting method and related equipment. Background Technology

[0002] With the continuous development of cloud computing, edge computing, and intelligent computing cluster technologies, diskless computing systems, due to their advantages such as centralized storage management, flexible resource scheduling, and rapid node deployment, are increasingly being applied in data centers, server clusters, and large-scale computing platforms. As a crucial component of diskless computing systems, system disk mounting technology directly impacts the startup efficiency, operational stability, and system resource management capabilities of computing nodes. However, in diskless computing systems, the continuous access and reliable mounting of the system disk present significant challenges due to the differences in access methods and data channels used at different stages, from the startup phase to the continuous access during operating system operation. Therefore, the research and application of system disk mounting technology for diskless computing systems is particularly important.

[0003] In related technologies, diskless computing nodes typically obtain operating system images through remote storage, often employing different access channels and driver mechanisms during node startup and operating system runtime. However, due to the lack of effective state association and switching mechanisms between different access channels, issues such as inconsistent device identification, abnormal system disk mounting, and discontinuous input / output states can easily arise during system disk access path switching, affecting the startup efficiency and operational reliability of diskless nodes. Furthermore, to enable multiple computing nodes to share the system image, a centralized system disk deployment is usually adopted, but data writes generated during computing node operation may directly affect the shared system image, leading to modification or even corruption of the base image content. In other words, related technologies suffer from low reliability of system disk access path switching, insufficient write protection capabilities of the shared system disk, and poor node data isolation in diskless computing systems. Summary of the Invention

[0004] In the summary section of this application, the relevant technical solutions are described in general terms, and a series of simplified concepts are introduced. These concepts will be further elaborated in the detailed embodiments section. This summary section should not be construed as limiting the key or essential technical features of the claimed solutions, nor is it intended to limit the scope of protection of the claimed solutions.

[0005] The system disk mounting method and related equipment provided in this application can achieve smooth switching of system disk access path from the startup stage to the running stage of diskless computing nodes through the data processing unit. Combined with the write-protected differential mounting mechanism, it can realize system disk image sharing, node data isolation, and secure and reliable management of system disk.

[0006] In a first aspect, this application provides a system disk mounting method applied to a data processing unit in a diskless computing system, comprising: in response to a computing node powering on, assigning a target session identifier to the computing node and writing the target session identifier and system disk metadata into a preset mailbox register; receiving a takeover request generated by the computing node based on information in the preset mailbox register, wherein the takeover request includes the target session identifier and the node identifier of the computing node; after verifying the takeover request, switching the input / output path of the computing node to the target system disk from a first channel to a second channel, and generating second channel connection parameters, wherein the first channel is a simple block device channel and the second channel is a multi-queue data channel; sending the second channel connection parameters to the computing node so that the computing node mounts the target system disk based on the second channel connection parameters; during the process of the computing node mounting the target system disk, performing write-protected differential mounting on the target system disk, wherein the write-protected differential mounting includes dividing the target system disk into a read-only base mirror region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base mirror region to the writable differential region.

[0007] In some implementations, the step of assigning a target session identifier to the computing node in response to power-on and writing the target session identifier and system disk metadata into a preset mailbox register includes: generating the target session identifier in response to the computing node's basic input / output system accessing a read-only boot logic unit number through a boot assistant provided by the data processing unit; obtaining the system disk metadata associated with the read-only boot logic unit number; and writing the target session identifier and the system disk metadata into the preset mailbox register.

[0008] In some implementations, writing the target session identifier and system disk metadata into a preset mailbox register includes: writing the target session identifier and system disk metadata into a preset mailbox register so that an agent program running on the compute node in the initial memory file system after the operating system kernel is loaded reads the target session identifier and system disk metadata from the preset mailbox register, and the agent program constructs the takeover request based on the target session identifier, the system disk metadata, the node physical slot identifier, and the desired access mode.

[0009] In some implementations, the takeover request further includes a one-time random number; after verifying the takeover request, the input / output path of the compute node to the target system disk is switched from the first channel to the second channel, and the second channel connection parameters are generated, including: performing a validity check on the target session identifier and the node identifier in the takeover request; performing a uniqueness check on the one-time random number in the takeover request; after both the validity check and the uniqueness check pass, the input / output path of the compute node to the target system disk is switched from the simple block device channel to the multi-queue data channel based on the NVMe-oF Initiator, while keeping the namespace identifier of the target system disk unchanged before and after the switch; and the second channel connection parameters are generated based on the switched second channel.

[0010] In some implementations, the write-protected differential mounting of the target system disk during the process of mounting the target system disk on the computing node includes: intercepting the write request sent by the computing node through the second channel via the storage gateway on the data processing unit; obtaining the target logical block address carried by the write request; and if the target logical block address falls within the address range of the read-only base mirror region, redirecting the write request to the writable differential region bound to the node identifier.

[0011] In some implementations, the writable differential region is configured with a preset capacity quota and a preset lifespan, the preset lifespan corresponding to the physical slot corresponding to the node identifier.

[0012] In some implementations, the system disk mounting method further includes: obtaining the write frequency corresponding to each write operation in the writable differential region; extracting hot-write data blocks from the writable differential region based on the write frequency; and caching the hot-write data blocks in a non-volatile storage medium local to the data processing unit so that subsequent read requests for the hot-write data blocks are responded to from the non-volatile storage medium.

[0013] In some implementations, the system disk mounting method further includes: in response to a node reset command sent by the compute node, clearing the writable differential region corresponding to the node reset command, so that the compute node can be restored to the initial state of the read-only base image region upon the next startup.

[0014] Secondly, this application also provides a system disk mounting device, applied to a data processing unit in a diskless computing system, comprising: a data acquisition unit, configured to, in response to power-on of a computing node, assign a target session identifier to the computing node and write the target session identifier and system disk metadata into a preset mailbox register; a request receiving unit, configured to receive a takeover request generated by the computing node based on information in the preset mailbox register, wherein the takeover request includes the target session identifier and the node identifier of the computing node; and a channel switching unit, configured to, after verifying the takeover request, switch the input / output path of the computing node to the target system disk from a first channel to a second channel. The system generates second channel connection parameters, wherein the first channel is a simple block device channel and the second channel is a multi-queue data channel; a parameter sending unit is used to send the second channel connection parameters to the computing node so that the computing node mounts the target system disk based on the second channel connection parameters; a differential mounting unit is used to perform write-protected differential mounting on the target system disk during the process of the computing node mounting the target system disk, wherein the write-protected differential mounting includes dividing the target system disk into a read-only base mirror region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base mirror region to the writable differential region.

[0015] Thirdly, this application also provides an electronic device, including: a memory and a processor, wherein the processor is configured to implement the steps of the system disk mounting method described in the first aspect when executing a computer program stored in the memory.

[0016] Fourthly, this application also provides a computer-readable storage medium storing computer-executable instructions or a computer program, wherein when the computer-executable instructions or the computer program are executed by a processor, the steps of the system disk mounting method described in the first aspect are implemented.

[0017] Fifthly, this application also provides a computer program product, including a computer program or computer executable instructions, which, when executed by a processor, implement the steps of the system disk mounting method provided in the embodiments of this application.

[0018] In summary, this application generates a target session identifier after the computing node powers on via a data processing unit, and writes this session identifier and system disk metadata into a preset mailbox register. This enables the computing node to obtain the corresponding system disk access information during the subsequent boot phase, thereby avoiding the problem of the computing node being unable to continue accessing the target system disk due to the lack of system disk association information during the boot process, and thus improving the accuracy of resource identification during the boot process of diskless nodes. Furthermore, the computing node generates a takeover request based on the information in the mailbox register, and the data processing unit verifies the takeover request. After successful verification, an input / output path switch is performed, changing the path for the computing node to access the target system disk from the first channel to the second channel. The first channel is a simple block device channel used for access during the boot phase, and the second channel is a multi-queue data channel used during the runtime phase. Therefore, the computing node can continue to access the same target system disk through a data access channel suitable for the runtime state after the operating system boot is completed. Since the data processing unit generates the second channel connection parameters and sends them to the computing node during the switching process, the computing node can access the target system disk based on these connection parameters. The system disk is mounted automatically, reducing mounting anomalies caused by device identification differences between different access channels. Furthermore, during the mounting of the target system disk by the compute nodes, write-protected differential mounting is performed, dividing the target system disk into a read-only base image region and a writable differential region corresponding to the node identifier. Write requests for the read-only base image region are redirected to the writable differential region, allowing multiple compute nodes to provide a system operating environment based on the same read-only base image region. Modified data from each node is saved to the corresponding writable differential region, preventing compute nodes from directly modifying the read-only base image region during operation, thus reducing the risk of system disk base image corruption. By associating the writable differential region with the node identifier, different compute nodes can have independent data modification spaces. When a compute node performs a write operation, only the differential region of the corresponding node is affected, without affecting the base image region used by other nodes. This supports multiple diskless compute nodes sharing the system disk image while maintaining data isolation between the operating states of each node, improving the reliability of system disk management in the diskless computing system. In summary, the system disk mounting method provided in this application enables a smooth switching of the system disk access path from the startup phase to the running phase of the diskless computing node through the data processing unit, and combined with the write-protected differential mounting mechanism, it can realize system disk image sharing, node data isolation, and secure and reliable management of the system disk. Attached Figure Description

[0019] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit this specification. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0020] Figure 1 A flowchart illustrating a system disk mounting method provided in an embodiment of this application;

[0021] Figure 2 This application provides a schematic diagram of the composition structure of a system disk mounting device according to an embodiment of the present application.

[0022] Figure 3 This is a schematic diagram of the composition structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0023] The terms used in the specification, claims, and drawings of this application, such as "first," "second," "third," "fourth," etc. (if any), are used to distinguish similar objects and not to describe a specific order or sequence. Therefore, it is to be understood that these terms can be used interchangeably where appropriate, allowing the described embodiments to be used in different orders, unless specifically required by the illustrations or description. Furthermore, the terms "is" and "has," and any variations thereof, are intended to cover, non-exclusively, all possible constituent elements. For example, a process, method, system, product, or apparatus comprising several steps or units is not necessarily limited to the steps or units explicitly listed, but may also include other steps or units not explicitly listed, or steps or units inherent to the process, method, product, or apparatus.

[0024] In this application, a "module" or "unit" refers to a computer program or part of a computer program that has a specific function and works in conjunction with other related parts to achieve a predetermined goal. These modules or units can be implemented by software, hardware (e.g., processing circuitry or memory), or a combination of both. One or more processors or memories can implement one or more modules or units. Furthermore, each module or unit can also be part of a larger module or unit.

[0025] The technical solutions of this application will be described in detail below with reference to the accompanying drawings of the embodiments. It should be noted that the described embodiments are only a part of this application, and not all embodiments. In the following description, the "some embodiments" mentioned are only a subset of all possible embodiments, which may be the same or different subsets, and different embodiments can be combined with each other without conflict.

[0026] Figure 1This is a flowchart illustrating a system disk mounting method provided in an embodiment of this application. For example, see [link to example]. Figure 1 The system disk mounting method provided in this application is applied to the data processing unit of a diskless computing system. A diskless computing system is a distributed computing architecture that eliminates the local storage configuration of a single node and relies on centralized storage resources to achieve system startup and business operation. In a diskless computing system, all computing nodes are not equipped with local hard disks. All operating system images and business data are stored in a remote centralized storage cluster. On-demand access to storage resources is achieved through a switching network and dedicated hardware units. A diskless computing system can be built through hardware integration and deployment. It consists of a computing node cluster, a data processing unit cluster, a centralized storage cluster, and a switching network. Resource configuration and scheduling are completed through a unified management platform. For example, a personal computer farm (PC farm) array for high-density computing scenarios is a typical diskless computing system. The entire system contains dozens to hundreds of diskless computing nodes. All nodes share the system image in remote storage, realizing batch deployment and unified operation and maintenance. A Data Processing Unit (DPU) is a dedicated processing device for data center scenarios, deployed between compute nodes and the storage network. It undertakes data plane processing tasks such as storage protocol conversion, input / output path scheduling, and storage virtualization offloading, freeing the host CPU from storage-related loads. The DPU is deployed as a board and connects to the compute node motherboard via a high-speed Peripheral Component Interconnect Express (PCIe) interface. Hardware installation and firmware configuration are performed by system administrators. The system disk mounting method provided in this application embodiment may include the following steps 101 to 105:

[0027] Step 101: In response to the power-on of the compute node, assign a target session identifier to the compute node and write the target session identifier and system disk metadata to the preset mailbox register.

[0028] In some examples, compute nodes are independent hardware units in diskless computing systems that bear the business computing load. They have core computing components such as a central processing unit, memory, and Unified Extensible Firmware Interface (UEFI) firmware. They do not have local hard disk storage and rely on external storage resources to complete system startup and program execution. The compute node is based on a motherboard and is installed in a physical slot in a server chassis. Each physical slot corresponds to an independent compute node, which is connected to the data processing unit and power supply system through the chassis backplane. For example, the x86 architecture general-purpose compute motherboard node is equipped with a multi-core central processing unit and large-capacity memory. It does not have a local solid-state drive or hard disk drive configuration. It completes diskless startup and business operation through a matching data processing unit. It is the most common form of compute node in diskless computing systems.

[0029] The target session identifier is a unique identity credential assigned by the data processing unit to a compute node for a single startup process. It is used to associate storage access sessions at different stages of the same startup process, ensuring that the access context remains consistent between the boot phase and the runtime phase. For example, a string sequence in the format of a 128-bit globally unique identifier (GUID) is a typical form of the target session identifier. The data processing unit generates this identifier when responding to the node startup request, which serves as the session identity marker for the entire startup process and is used for identity verification and context association of subsequent storage access paths.

[0030] System disk metadata is a collection of information describing the core attributes and access configuration of the target system disk, including key information such as the system disk's storage location, capacity parameters, and access protocol configuration. It serves as the basis for compute nodes to locate and access the corresponding system disk. System disk metadata is pre-stored in the management node of the centralized storage cluster. After receiving a node startup request, the data processing unit retrieves the corresponding system disk metadata from the storage cluster management terminal based on the node's configuration information. For example, structured data containing information such as the system disk storage volume number, total capacity, and storage cluster access address is a typical form of system disk metadata. It is bound one-to-one with the startup configuration of the corresponding node, and the data processing unit retrieves and transmits it to the compute node side synchronously when the node starts.

[0031] The pre-configured mailbox register is a hardware register space pre-configured in the data processing unit. It can be accessed by both the firmware and kernel programs on the compute node side and is used to pass session information between different driver stack stages, enabling cross-stage information pass-through. The address space of the pre-configured mailbox register can be pre-planned by the hardware logic of the data processing unit and exposed to the compute node side through Memory Mapped Input Output (MMIO). The compute node can read the information in the register through direct address access. For example, a 32-bit register group with a fixed base address is a typical form of the pre-configured mailbox register. The data processing end is responsible for writing session identifiers and metadata information. The unified extensible firmware interface program and the kernel initialization program on the compute node side can both read the contents of this register group through MMIO to complete the cross-stage information transfer.

[0032] For example, after the diskless computing system completes the overall power-on initialization, the computing nodes in the corresponding physical slots of the chassis begin to execute the power-on self-test and firmware initialization process upon power-on. The data processing unit monitors the power supply status and startup events of the nodes in each physical slot in real time. When it detects that the target computing node has completed power-on and entered the firmware initialization stage, it triggers the session allocation process. The data processing unit generates a globally unique target session identifier through its internal random number generation module. This identifier corresponds one-to-one with the physical slot of the current computing node and is only valid within this startup cycle. Subsequently, the data processing unit retrieves the system disk metadata corresponding to the target system disk bound to the node from the configuration database of the centralized storage cluster according to the physical slot number of the computing node. The data processing unit encapsulates the generated target session identifier and the retrieved system disk metadata according to a preset message format and writes them into a preset mailbox register with a pre-allocated address, completing the information initialization configuration of the boot phase and providing a unified context for the subsequent system loading and storage access of the computing nodes.

[0033] By implementing step 101, the computing node is assigned a target session identifier upon power-up, and the target session identifier and system disk metadata are written to a preset mailbox register. This enables the computing node to obtain the association information corresponding to the target system disk during the startup process, thereby establishing a correspondence between the computing node and the target system disk. This avoids the problem of being unable to continue accessing the system disk due to the lack of system disk identification information during the startup phase, and improves the accuracy of resource identification and startup reliability during the startup process of the diskless computing node.

[0034] Step 102: Receive a takeover request generated by the computing node based on information in a preset mailbox register.

[0035] The takeover request includes the target session identifier and the node identifier of the compute node.

[0036] In some examples, a takeover request is a control message sent by the compute node to the data processing unit during system startup. It is used to request a switch of the system disk's input / output access path from the simplified channel in the boot phase to the formal data channel in the operating system runtime phase. It is a control signal that connects the two startup phases and triggers a smooth path switch. The takeover request is constructed and generated by an agent program running on the compute node side. The agent program reads the session information and system disk metadata stored in the preset mailbox register, combines them with the node's own identity information, and fills in the corresponding fields according to the message format agreed upon by the data processing unit to finally generate a complete takeover request. The takeover request includes the target session identifier and the compute node's node identifier.

[0037] A node identifier is a coded information used in a diskless computing system to uniquely identify a single computing node. It can correspond one-to-one with the physical deployment location or inherent hardware identifier of the computing node, and is the basis for realizing node identification and storage resource binding. The node identifier can be pre-written into the firmware parameter space of the computing node, or it can be allocated and distributed by the chassis management module according to the physical slot number of the node. The agent program on the computing node side can obtain the corresponding node identifier by reading the hardware configuration register or slot number information. The numerical coding sequence corresponding to the physical slot of the server chassis is the typical form of node identifier. Each physical slot corresponds to a unique node identifier. The data processing unit can match the storage resource configuration of the corresponding node based on the identifier to realize a one-to-one correspondence between the node and the storage resource.

[0038] For example, after the compute node completes kernel loading and enters the initial memory file system stage, the agent program running in the initial memory file system (initramfs) reads all the contents of the preset mailbox register through memory-mapped input / output, and parses out the target session identifier and system disk metadata. The agent program further reads the physical slot number corresponding to the compute node, obtains the node identifier corresponding to that slot, and then encapsulates the target session identifier and node identifier according to the agreed message structure to generate a complete takeover request message. The agent program sends the takeover request message to the data processing unit through the management interface (MI) provided by the data processing unit. When the data processing unit verifies the management process, it listens for uplink data from the management interface. When it detects a message that conforms to the protocol format, it identifies the type field in the message header. After confirming that it is a takeover request, it parses and extracts the target session identifier and node identifier fields from the message and temporarily stores them in the internal cache space, completing the takeover request reception process and preparing data for subsequent request verification and path switching operations.

[0039] By implementing step 102, the data processing unit can obtain the identity information and corresponding session information of the computing node, thereby providing a basis for subsequent system disk access path switching. At the same time, by performing subsequent processing based on the takeover request, the computing node can actively initiate the system disk access takeover process, improving the accuracy of information interaction between the computing node and the data processing unit.

[0040] Step 103: After verifying the takeover request, switch the input / output path of the compute node to the target system disk from the first channel to the second channel, and generate the connection parameters for the second channel.

[0041] The first channel is a simple block device channel, and the second channel is a multi-queue data channel.

[0042] In some examples, the input / output path of the compute node to the target system disk is the complete data transmission link that the data request is sent from the compute node side when the compute node initiates a read / write request to the target system disk, and finally arrives at the target system disk in the remote centralized storage through the protocol conversion and path scheduling of the data processing unit. It is the sum of the physical path and logical mapping for realizing remote access to storage resources in diskless computing scenarios.

[0043] The first channel is a lightweight storage access path used by the compute node during the boot process. It adapts to the simplified driver capabilities of the firmware stage, providing only basic block device read / write functions to support the loading process of the kernel and boot files during the boot phase. The first channel is automatically activated by the data processing unit when the compute node is detected to be powered on and is deeply integrated with the boot assist function. The compute node can access the channel through the simplified boot driver built into the firmware. The boot assist path corresponding to the unified extensible firmware interface boot phase is a typical form of the first channel, supporting only basic block read operations and a small number of device control instructions, and can load the boot file without a complete protocol driver stack. The simplified block device channel is a definition of the first channel's functional attributes. It refers to a block device access channel with functional trimming and protocol simplification, implementing only the instruction set for block device read / write, omitting complex features such as multi-queue scheduling, advanced error handling, and multi-path redundancy to adapt to the limited driver capabilities and code size in the firmware environment.

[0044] The second channel is the formal storage access path used by the compute node after it enters the operating system runtime phase. It possesses complete storage protocol support and high-performance data processing capabilities to support the full system disk read / write needs during normal operating system operation. The second channel is triggered by the data processing unit after the takeover request is verified. After completing path mapping and resource configuration, it provides access parameters to the compute node, which then accesses the channel through the operating system's built-in complete protocol driver. The high-speed storage protocol data path corresponding to the operating system runtime is a typical form of the second channel, supporting full protocol instructions, concurrent scheduling, and error recovery mechanisms to meet the high-frequency read / write needs during system operation. The multi-queue data channel is a definition of the core functional attribute of the second channel. It refers to a block device access channel that supports multi-queue parallel scheduling. Through the multi-queue mechanism, it achieves parallel distribution and processing of read / write requests, significantly improving storage access throughput and concurrency performance, and adapting to the high-performance storage access needs of the operating system runtime.

[0045] The second channel connection parameters are a complete set of configuration information required for a compute node to access the second channel. This includes key information such as the target storage address, protocol configuration parameters, queue resource configuration, and system disk identifier. These parameters are essential for the compute node's driver to establish a formal storage connection. The second channel connection parameters are automatically generated by the data processing unit after completing the path switching configuration, based on the actual deployment information of the current channel, and returned to the compute node's agent program through a dedicated management interface. A typical example is a structured parameter set containing the target storage target's Internet Protocol (IP) address, service port, system disk identifier, and queue quantity configuration. The operating system's storage protocol driver can establish a complete storage connection based on this parameter set, enabling formal access to the target system disk.

[0046] For example, after receiving a takeover request from a compute node, the data processing unit first calls its internal request verification module to verify the legitimacy of the request. This verifies whether the target session identifier carried in the request matches the session information previously allocated and written to the preset mailbox register. Simultaneously, it verifies whether the compute node corresponding to the node identifier in the request has access permissions to the target system disk. After successful verification, the data processing unit's path management module initiates the path switching process. First, it initializes the resources for the second channel, allocating the corresponding number of hardware queues and protocol processing resources, and establishing an access mapping relationship between the second channel and the target system disk. Once the second channel is configured, the path management module disconnects the access mapping between the first channel and the target system disk, switching the compute node's input / output path to the target system disk entirely to the configured second channel, ensuring the continuity of the target system disk's access logic. After the path switching operation is completed, the data processing unit generates second channel connection parameters, including the access address, protocol parameters, and queue configuration, based on the actual configuration information of the second channel. These parameters are then temporarily stored in the internal transmission buffer, preparing for subsequent return of connection information to the compute node.

[0047] By implementing step 103, the computing node can smoothly transition from the simple block device channel used in the startup phase to the multi-queue data channel used in the operation phase. Since the access continuity of the target system disk is maintained during the switching process and the corresponding second channel connection parameters are generated, the system disk access anomalies caused by device identification differences between different access channels can be reduced, and the stability of the system disk access path switching process can be improved.

[0048] Step 104: Send the second channel connection parameters to the compute node so that the compute node can mount the target system disk based on the second channel connection parameters.

[0049] In some examples, the target system disk is a remote logical storage volume in a diskless computing system that provides a complete operating system runtime environment for compute nodes. This includes the operating system kernel, system programs, runtime dependencies, and basic configuration files. It serves as the storage medium for compute nodes to boot up and run services after being removed from local storage. The target system disk is pre-deployed within a remote centralized storage cluster. The cluster management platform handles system image creation, storage resource allocation, and access permission configuration. The data processing unit interacts with the centralized storage cluster through a storage management channel to obtain the target system disk's address mapping and access configuration information. A typical example of a target system disk is a standardized system image volume deployed in a distributed block storage cluster. Its capacity can be configured from tens to hundreds of gigabytes depending on the operating system requirements. It comes pre-installed with a unified server operating system image and supports simultaneous access from multiple compute nodes, providing a consistent system runtime environment for the diskless computing cluster.

[0050] For example, the data processing unit can send the complete access information of the runtime storage channel to the compute node, guide the storage protocol driver on the compute node side to establish a formal storage access link, and mount the block device corresponding to the target system disk to the specified directory of the operating system, ultimately enabling the compute node to achieve stable runtime access to the system disk. In a typical implementation scenario, the data processing unit returns the access parameters of the multi-queue data channel as a successful response to the takeover request. After receiving the parameters, the agent program on the compute node side calls the system storage tool to establish a formal storage connection, identifies the corresponding block device, and completes the mounting of the system disk, enabling the operating system to obtain complete system disk access capabilities.

[0051] By implementing step 104, the computing node can continue to access the target system disk through the second channel after completing the startup phase. As a result, the computing node does not need to reacquire system disk information or re-establish access relationships, which can reduce the operational complexity of the system disk mounting process and improve the continuity of system disk access during system operation.

[0052] Step 105: During the process of mounting the target system disk on the compute node, perform write-protected differential mounting on the target system disk.

[0053] Write-protected differential mounting can include dividing the target system disk into a read-only base image region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base image region to the writable differential region.

[0054] In some examples, write-protected differential mounting is a storage virtualization mounting mechanism for multi-node shared system disk scenarios. While providing compute nodes with full read and write access to the system disk, it forcibly isolates the base image data from the node write data at the storage access level. This ensures that the integrity of the shared system image is not damaged by node write operations, while also meeting the system write requirements during single-node operation. Write-protected differential mounting is uniformly executed by the data processing unit during the system disk mounting phase. It achieves low-level control over write operations through storage address hierarchical mapping technology, without requiring additional configuration and adaptation from the compute node-side operating system.

[0055] The read-only base image area is the basic storage area in the target system disk that carries standardized operating system files and general runtime configurations. It has global read-only attributes and can be shared and read by all authorized computing nodes in the diskless computing system. It is the common data foundation for all computing nodes to start and run the system. The read-only base image area is pre-created by system operation and maintenance personnel and deployed in a remote centralized storage cluster. The storage cluster management platform configures global read-only access permissions for this area. When the data processing unit performs differential mounting, it allocates the corresponding logical storage space range of this area according to the system disk configuration. The system image storage area with a pre-installed complete server operating system and basic runtime environment is a typical example of a read-only base image area. All computing nodes in the entire cluster can read the system files in this area to complete the boot process, but cannot directly modify the original image data in this area.

[0056] The writable differential region corresponding to the node identifier is a private writable storage space that is bound one-to-one with the node identifier of a single computing node. It is specifically used to accommodate all write data generated during the operation of the corresponding node. The differential regions of different computing nodes are independent of each other and do not interfere with each other. Read and write permissions are only granted to the node to which the node belongs. The writable differential region is automatically allocated by the data processing unit according to the node identifier reported by the computing node when performing write protection differential mounting, and a binding relationship is established, forming a unique mapping with the node identity. Each computing node has an independent private differential storage area, which is a typical example. System configuration changes, temporary running files and other write content generated during the operation of the node are all stored in the corresponding differential region. The write data of different nodes are completely isolated and there will be no cross interference.

[0057] For example, during the process of a compute node initiating a target system disk mounting operation based on the second channel connection parameters, the data processing unit simultaneously initiates a write-protected differential mounting process. The data processing unit first retrieves the image configuration information of the target system disk and divides the complete logical storage space of the target system disk into two logical regions. One part is a read-only base image region that carries the complete operating system image. This region maintains a globally read-only attribute and grants read permissions to all authorized compute nodes. The other part is a writable differential region that is bound one-to-one with the node identifier of the current compute node. This region only grants read and write permissions to the current compute node. After completing the logical region division, the data processing unit loads write redirection processing logic into the input / output access path of the target system disk and performs address range judgment and dynamic adjustment on all write requests sent to the target system disk. When a write operation pointing to the read-only base image region is detected, the target address of the write operation is automatically mapped to the writable differential region corresponding to the current node, so that the written data is ultimately stored in the differential region instead of the base image. This achieves forced write protection of the shared system disk and isolated storage of written data between nodes without affecting the normal read and write experience of the compute node.

[0058] By implementing step 105, the target system disk is divided into a read-only base image region and a writable differential region corresponding to the node identifier. Write requests for the read-only base image region are redirected to the writable differential region, enabling multiple compute nodes to share the same read-only base image region. At the same time, data modifications made by each compute node during operation are saved to the corresponding writable differential region. This avoids compute nodes directly modifying the base system disk image, improving the security of the system disk image. Furthermore, the differential regions corresponding to the nodes achieve data isolation between different compute nodes, improving the reliability of system disk management in the diskless computing system.

[0059] In summary, this embodiment generates a target session identifier after the computing node powers on in response to the data processing unit's power-on, and writes the session identifier and system disk metadata into a preset mailbox register. This enables the computing node to obtain the corresponding system disk access information during the subsequent boot phase, thereby avoiding the problem of the computing node being unable to continue accessing the target system disk due to the lack of system disk association information during the boot process, and thus improving the accuracy of resource identification during the boot process of diskless nodes. Furthermore, the computing node generates a takeover request based on the information in the mailbox register, and the data processing unit verifies the takeover request. After successful verification, an input / output path switch is performed, switching the computing node's access path to the target system disk from the first channel to the second channel. The first channel is a simple block device channel used for access during the boot phase, and the second channel is a multi-queue data channel used during the runtime phase. Therefore, the computing node can continue to access the same target system disk through the data access channel suitable for the runtime state after the operating system boot is completed. Since the data processing unit generates the second channel connection parameters and sends them to the computing node during the switching process, the computing node can access the target system disk based on this connection. The parameters complete the system disk mounting, thereby reducing mounting anomalies caused by device identification differences between different access channels. Furthermore, during the mounting of the target system disk by the compute nodes, write-protected differential mounting is performed, dividing the target system disk into a read-only base image region and a writable differential region corresponding to the node identifier. Write requests for the read-only base image region are redirected to the writable differential region, allowing multiple compute nodes to provide a system operating environment based on the same read-only base image region. Modified data from each node is saved to the corresponding writable differential region, preventing compute nodes from directly modifying the read-only base image region during operation, thus reducing the risk of system disk base image corruption. By mapping the writable differential region to the node identifier, different compute nodes can have independent data modification spaces. When a compute node performs a write operation, only the differential region of the corresponding node is affected, without affecting the base image region used by other nodes. This supports multiple diskless compute nodes sharing the system disk image while maintaining data isolation between the operating states of each node, improving the reliability of system disk management in diskless computing systems. In summary, the system disk mounting method provided in this application embodiment enables a smooth switching of the system disk access path from the startup phase to the running phase of the diskless computing node through the data processing unit, and combined with the write-protected differential mounting mechanism, it can realize system disk image sharing, node data isolation, and secure and reliable management of the system disk.

[0060] In some embodiments, the aforementioned step 101 may include: in response to the basic input / output system of the computing node accessing the read-only boot logic unit number through the boot assistant provided by the data processing unit, generating a target session identifier; obtaining system disk metadata associated with the read-only boot logic unit number; and writing the target session identifier and system disk metadata into a preset mailbox register.

[0061] In some examples, the Basic Input Output System (BIOS) is a low-level system program embedded in the firmware storage chip of the compute node motherboard. It is responsible for hardware power-on self-test, peripheral initialization, boot device identification, and system boot loading. It is the first execution stage in the compute node boot process, providing the hardware foundation and boot entry point for subsequent operating system loading. The Unified Extensible Firmware Interface (UEI) is the mainstream implementation form of the next-generation BIOS. It supports standard storage protocol boot drivers and can adapt to the remote boot requirements in diskless computing scenarios.

[0062] The boot assistant is a lightweight boot support module provided by the data processing unit to simplify driver capabilities during the firmware phase. It presents standardized virtual block devices to the basic input / output system of the compute node, supporting the reading of boot files and kernel loading during the firmware phase, and enabling storage access without the need for a complete storage protocol driver. The boot assistant is integrated into the firmware system of the data processing unit and is automatically enabled when the data processing unit powers on. It can be directly recognized and invoked by the basic input / output system on the compute node side. The Non-Volatile Memory Express over Fabrics Boot Helper (NVMe-oF Boot Helper) is a typical implementation of the boot assistant, which provides a simplified block device access interface for the basic input / output system and supports file reading requirements during the boot phase.

[0063] A Read-only Boot Logical Unit Number (Boot LUN) is a dedicated read-only storage unit deployed in a remote centralized storage cluster. It stores only the bootloader, kernel image, and minimal initial memory file system required for system startup. It is small in size and is specifically used for file loading during the boot phase. It does not contain a complete operating system runtime environment. The Read-only Boot Logical Unit Number is created and configured with global read-only permissions in advance in the centralized storage cluster by the operations and maintenance personnel. At the same time, an association mapping relationship is established with the corresponding complete system disk. The data processing unit can obtain the access configuration information of the logical unit through the storage management interface. A dedicated read-only storage unit with a capacity of 2 gigabytes (GB) is a typical form of Read-only Boot Logical Unit Number. It only stores the kernel file, initial memory file system, and bootloader. It only has read permissions and can support the compute node to complete the kernel loading and initial startup process.

[0064] The process of generating a target session identifier in response to the compute node's basic input / output system accessing the read-only boot logical unit number via the boot assistant provided by the data processing unit involves the data processing unit automatically triggering a session allocation process when it detects that the compute node firmware side has initiated an access request to the read-only boot storage unit through the boot auxiliary channel. This generates a unique session identifier for this boot process, ensuring a unified identity context throughout the entire boot process. The process of obtaining system disk metadata associated with the read-only boot logical unit number involves the data processing unit retrieving the pre-configured attribute configuration information of the complete system disk corresponding to the currently accessed read-only boot logical unit number after triggering session generation. This provides metadata support for subsequent path switching. The process of writing the target session identifier and system disk metadata into a preset mailbox register involves the data processing unit writing the generated session identifier and the retrieved system disk metadata into a pre-planned shared hardware register space according to an agreed format. This completes the temporary storage of boot stage information, providing data support for subsequent kernel stage information reading by the compute node.

[0065] For example, after the compute node completes its power-on self-test, the basic input / output system begins enumerating boot devices. Upon identifying the virtual block device corresponding to the boot assistant provided by the data processing unit, it initiates a read access request for the read-only boot logic unit number. The boot management module of the data processing unit detects this access request, confirms that the request originates from the firmware boot process of a legitimate compute node, and then calls the internal session generation module to generate a globally unique target session identifier. This identifier is then bound to the current boot access session. After generating the session identifier, the data processing unit queries the locally stored boot unit-system disk mapping table based on the currently accessed read-only boot logic unit number to obtain the system disk metadata corresponding to the target system disk associated with that boot unit. The data processing unit encapsulates the generated target session identifier and the obtained system disk metadata according to a preset field order and data format. Through the register read / write interface, it writes the encapsulated data into a preset mailbox register at a pre-planned address, completing the session information initialization configuration for the boot phase. This provides a unified data basis for subsequent information reading and path takeover request construction during the compute node kernel phase.

[0066] Through the implementation of the above embodiments, the data processing unit can identify the corresponding system disk access object based on the clear session identifier and system disk metadata, providing an accurate information basis for subsequent system disk access path switching, reducing access anomalies caused by inconsistencies in system disk information between the startup and running phases, and improving the stability of the system disk mounting process.

[0067] In some embodiments, the aforementioned writing of the target session identifier and system disk metadata into a preset mailbox register may include: writing the target session identifier and system disk metadata into a preset mailbox register so that an agent program running on the compute node in the initial memory file system after the operating system kernel is loaded reads the target session identifier and system disk metadata from the preset mailbox register, and the agent program constructs a takeover request based on the target session identifier, system disk metadata, node physical slot identifier, and desired access mode.

[0068] In some examples, the agent running in the initial memory file system is a dedicated control program deployed in a temporary environment during the early stages of the operating system startup. The initial memory file system is a temporary root file system mounted first after the operating system kernel is loaded. It contains only the minimal drivers and toolset necessary for system startup, supporting initialization operations before the formal root file system is mounted. The agent running in this environment is the main execution entity connecting the boot phase and the runtime storage path, specifically responsible for reading cross-phase shared information, constructing path switching requests, and interacting with the data processing unit. This agent is pre-packaged and written into the initial memory file system image by system administrators when creating the system image. It is stored along with the kernel file in the read-only boot logic unit number. The agent is loaded synchronously when the compute node boots and loads the kernel, and its execution is automatically triggered after the kernel starts. For example, in a typical diskless Linux boot scenario, a customized storage path takeover agent is integrated into the initial memory file system. This agent runs automatically after the kernel is loaded and before the formal root file system is mounted, completing the interaction with the data processing unit throughout the process and supporting smooth switching of storage paths.

[0069] For example, after the compute node loads the operating system kernel using the read-only boot logic unit number, the kernel completes its own initialization and automatically mounts the initial memory file system, starting the system initialization process. The pre-integrated agent program automatically starts and runs along with the initialization process. The agent program first calls the system memory mapping interface, completes the address mapping of the hardware register space according to the fixed base address and address offset of the preset mailbox register, reads all the data stored in the register, parses and extracts the target session identifier and complete system disk metadata, and temporarily stores them in the local memory space. Then, the agent program accesses the baseboard management controller service of the compute node, reads the physical slot number of the chassis where the node is located, obtains the node physical slot identifier, and reads the preset system disk access mode parameters in the local configuration file to obtain the expected access mode corresponding to this startup. After completing the collection of all necessary information, the agent program fills the target session identifier, system disk metadata, node physical slot identifier, and expected access mode into the corresponding fields of the message according to the takeover request message format specified by the data processing unit, completes the structured construction of the takeover request, and prepares the data for sending a path switching application to the data processing unit later.

[0070] By implementing the above embodiments, the target session identifier and system disk metadata are written into a preset mailbox register, enabling the agent program in the initial memory file system after the operating system kernel is loaded to read the corresponding information. Based on the target session identifier, system disk metadata, node physical slot identifier, and desired access mode, a takeover request is constructed, allowing the computing node to actively initiate the system disk access takeover process after completing the initial boot. This enables the effective transfer of information from the boot phase to the runtime phase, avoiding the problem of failure to complete the system disk path switch due to information disconnection between the boot environment and the operating system runtime environment, and improving the accuracy of the system disk takeover process.

[0071] In some embodiments, the aforementioned takeover request may further include a one-time random number; the aforementioned step 103 may include: performing a validity check on the target session identifier and node identifier in the takeover request; performing a uniqueness check on the one-time random number in the takeover request; after both the validity check and the uniqueness check pass, switching the input / output path of the compute node to the target system disk from the simple block device channel to the multi-queue data channel based on the NVMe-oF Initiator, while keeping the namespace identifier of the target system disk unchanged before and after the switch; generating the second channel connection parameters based on the switched second channel.

[0072] In some examples, a Number Used Once (Nonce) is a random value used only in a single request interaction to enhance the security of takeover requests, prevent replay attacks caused by network sniffing, and ensure that each path switching request is a new and legitimate request initiated by the node. The Nonce is dynamically generated by the agent program on the compute node side through the kernel random number generator when constructing the takeover request. Each generation corresponds to one takeover request, and the value is not reused after the request is sent. A 64-bit unsigned random integer is a typical form of a Nonce. The agent program regenerates this value and fills it into the message field before each takeover request is constructed to ensure that each request has a unique random identifier.

[0073] The process of validating the target session identifier and node identifier in the takeover request is a verification step in the data processing unit's verification of the takeover request's identity and permissions. It is used to confirm that the node initiating the request has access permissions to the corresponding system disk and that the request corresponds one-to-one with the currently valid running session, avoiding path switching triggered by illegal nodes or expired sessions. For example, the data processing unit queries the locally stored session mapping table. If the target session identifier is within its valid lifecycle and the corresponding bound node identifier completely matches the node identifier carried in the request, the validity verification is deemed to have passed; otherwise, the verification is deemed to have failed and the request is rejected.

[0074] The process of verifying the uniqueness of the one-time random number in the takeover request is a special verification step in the data processing unit to prevent replay attacks. It is used to confirm that the current takeover request is a brand new request that has been initiated for the first time, so as to prevent attackers from intercepting and resending historical legitimate request messages and illegally triggering storage path switching. For example, the data processing unit saves the one-time random numbers corresponding to all legitimate takeover requests in the past 24 hours. If the random number carried by the current request does not appear in the history record, the uniqueness verification is determined to be successful, and the random number is stored in the history record. If the random number already exists, the verification is determined to be unsuccessful and the current request is discarded.

[0075] After both legality and uniqueness checks pass, the path switching logic involves switching the compute node's input / output path to the target system disk from the simple block device channel to a multi-queue data channel based on the Non-Volatile Memory Express over Fabrics Initiator (NVMe-oF Initiator), while maintaining the target system disk's namespace identifier unchanged before and after the switch. This process is triggered only after both security checks pass, achieving a seamless switch by maintaining consistent device identifiers. This operation is executed by the path management module of the data processing unit. The module first configures the resources and loads the protocol stack for the multi-queue data channel, then adjusts the path mapping relationship of the system disk, migrating the compute node's access traffic from the simple block device channel to the formal multi-queue data channel, preserving the original namespace identifier of the target system disk throughout the process. In a typical implementation scenario, the target system disk's namespace identifier is a fixed number before the switch, and this number remains completely consistent after the switch. The compute node's operating system will not detect device removal and re-enumeration, completely avoiding device identification anomalies and mount point conflicts.

[0076] The process of generating connection parameters for the second channel after switching is executed by the channel management module of the data processing unit. The module reads the actual effective access address, queue configuration, device identifier and other information from the configuration register and protocol stack of the second channel, and assembles them into structured connection parameters according to the agreed format. The typical generated result includes the network access address, protocol version, queue number and target system disk namespace number of the second channel. The non-volatile memory host controller interface protocol networking initiator driver on the computing node side can directly establish a complete storage access connection based on this parameter set.

[0077] For example, after receiving a takeover request from a computing node, the data processing unit first parses and extracts the target session identifier, node identifier, and one-time random number segment from the message, and then hands them over to the internal request verification module for double verification. The verification module first queries the locally maintained valid session mapping table to verify whether the target session identifier is in a valid state and whether the corresponding bound node identifier is completely consistent with the node identifier carried in the request, thus completing the legality verification. Subsequently, the verification module queries the locally stored historical set of used random numbers to verify whether the one-time random number in this request has never appeared before, thus completing the uniqueness verification. When both verifications pass, the path management module of the data processing unit initiates the channel switching process, first completing the non-volatile memory host controller interface. The protocol networking initiator initializes the resources of the multi-queue data channel, allocates the corresponding number of hardware input / output queues, loads the complete protocol processing stack, and establishes the mapping relationship between the channel and the target system disk. After configuration, the path management module adjusts the path mapping rules of the system disk, smoothly migrating the input / output access path of the computing node to the target system disk from the simple block device channel to the multi-queue data channel, keeping the namespace identifier of the target system disk fixed throughout the process. After the path switch is completed, the channel management module extracts information such as access address, queue parameters, and namespace number from the second channel's running configuration, assembles it into complete second channel connection parameters according to the agreed format, and stores it in the response message buffer to prepare for the subsequent return of access information to the computing node.

[0078] By implementing the above embodiments, a one-time random number is added to the takeover request, and the target session identifier, node identifier, and one-time random number are respectively validated for legality and uniqueness. This enables the data processing unit to confirm the validity of the takeover request source and the timeliness of the request process, thereby reducing the risk of incorrect switching of the system disk access path due to abnormal or duplicate requests. After successful verification, the system disk access path is switched from the simple block device channel to the multi-queue data channel based on NVMe-oF Initiator, while keeping the target system disk namespace identifier unchanged. This allows the compute node to complete the access path upgrade without interrupting the system disk association relationship, improving the continuity and reliability of the system disk path switching process.

[0079] In some embodiments, step 105 may include: intercepting write requests sent by computing nodes through a second channel via a storage gateway on the data processing unit; obtaining the target logical block address carried by the write request; and if the target logical block address falls within the address range of the read-only base mirror region, redirecting the write request to the writable differential region bound to the node identifier.

[0080] In some examples, the storage gateway is a storage protocol handler running on the general-purpose processing core built into the data processing unit. It has complete storage protocol parsing, request forwarding, and access policy control capabilities, and serves as the execution carrier for fine-grained control of input and output paths. The storage gateway is pre-compiled and deployed in the firmware system of the data processing unit. It automatically starts up when the data processing unit powers on and is deployed in series on the complete data path of the second channel. All input and output requests passing through the second channel must be processed by the storage gateway. The user-space storage protocol gateway developed based on the Storage Performance Development Kit (SPDK) is a typical implementation of the storage gateway. It runs on the Advanced RISC Machine (ARM) processing core of the data processing unit and can achieve low-latency, high-throughput input and output request interception and protocol processing. The Logical Block Address (LBA) is a linear address number used in a block storage system to locate data storage locations. It addresses the entire storage space uniformly in units of fixed-size data blocks. Each read / write request carries the corresponding LBA address to specify the specific storage location for data access. The LBA is carried in a specified field of the write request protocol message. The storage gateway can extract this address information by performing a complete protocol parsing of the request message. For example, a compute node sends a write request to the target system disk through a second channel. The opcode field of the request message carries a write operation identifier, and the address field carries the target LBA address. After intercepting the request in the data path, the storage gateway first identifies the operation type as a write operation, then parses the address field of the message to extract the target LBA address corresponding to this write operation, thus completing the interception of the write request and obtaining the core parameters.

[0081] After the storage gateway extracts the target logical block address, it compares it with the address range of the read-only base image. If a match is found, address redirection is performed, modifying the target storage address of the write request to the storage address of the corresponding differential region, and then forwarding the request to the backend storage. If no match is found, the request is forwarded directly at the original address. For example, the read-only base image region corresponds to a continuous address range from the starting logical block address to the ending logical block address of the base image. When the target logical block address of the write request is within this range, the storage gateway queries the base address of the writable differential region corresponding to the node identifier of the current request, converts the original target logical block address into the corresponding offset address within the differential region, so that the write operation ultimately lands in the node's private differential storage region. The original storage location corresponding to the read-only base image will not receive any write operations, ensuring the data integrity of the shared base image from the bottom layer of the input / output path.

[0082] For example, after the compute node initiates the mounting operation of the target system disk through the second channel, the storage gateway running on the data processing unit synchronously activates the write-protected differential processing logic and connects in series to the input / output data path of the second channel. When the compute node sends a write request to the target system disk, the request is transmitted to the data processing unit side along the multi-queue data path of the second channel and is first intercepted by the storage gateway in the path. The storage gateway performs a complete protocol parsing on the intercepted write request, first identifying the operation type of the request as a write operation, and extracting the address of the target logical block corresponding to this write from the address field of the request message. Subsequently, the storage gateway calls the internal... The address matching module compares the extracted target logical block address with the pre-stored read-only base mirror region address range. If the target logical block address falls within the address range of the read-only base mirror region, the storage gateway queries the address information of the writable differential region bound to the node identifier in the local mapping table based on the node identifier to which the current write request belongs. It then converts the target storage address of the write request into the corresponding logical address within the writable differential region. After completing the write request redirection process, it forwards the request to the backend centralized storage cluster, so that the written data is ultimately stored in the private differential region of the corresponding node. Throughout the process, no modification is made to the original data in the read-only base mirror region.

[0083] By implementing the above embodiments, the computing nodes can perform data modification operations normally during operation, while avoiding write operations from directly affecting the shared base system image. Thus, while ensuring the normal operation of the computing nodes, the protection capability of the system disk image can be improved, and the isolation of running data between different computing nodes can be achieved through the differential regions bound to the nodes.

[0084] In some embodiments, the writable differential region is configured with a preset capacity quota and a preset lifespan, and the preset lifespan corresponds to the physical slot corresponding to the node identifier.

[0085] In some examples, the preset capacity quota is the maximum available storage capacity limit set in advance for a single writable differential region. This limit is used to restrict the total amount of differential data generated during the operation of a single node, preventing the write data of a single node from excessively occupying the overall storage resources of the centralized storage cluster, and realizing fine-grained management and fair allocation of cluster storage resources. For example, in a diskless personal computer farm array for general computing scenarios, the preset capacity quota of the writable differential region corresponding to a single computing node is usually set to 50 gigabytes. When the total amount of differential data written by the node reaches this quota limit, the storage gateway will return a write failure prompt for subsequent over-quota write requests, preventing the differential storage resources from expanding without limit.

[0086] The preset lifecycle is a rule that pre-sets the effective retention time for writable differential regions. It is used to manage the storage period of differential data and ensure that the corresponding invalid differential data can be automatically cleaned up and reclaimed after a node goes offline or fails, thereby freeing up storage space in the centralized storage cluster and reducing cluster storage operation and maintenance costs. For example, the preset lifecycle rule can be set to retain data for 24 hours after a node goes offline. That is, when the corresponding computing node is powered off or offline, its associated writable differential region starts timing. After the 24-hour retention period is reached, the data processing unit automatically triggers the differential region deletion process to release the corresponding storage resources. The lifecycle management of writable differential regions is based on the physical slot where the compute node is located, rather than on temporary session identifiers or logical node identifiers. The lifecycle timing, renewal, and reclamation are all performed around the state of the physical slot, ensuring a stable one-to-one correspondence between differential regions and physical deployment locations. When a compute node in a physical slot restarts, the writable differential region corresponding to that slot will not be reset or recreated, and its lifecycle will continue according to the original timing rules. If the node hardware is changed but it is still deployed in the same physical slot, the lifecycle rules and capacity quota of the differential region remain unchanged, achieving a stable correspondence between storage resource configuration and physical deployment location.

[0087] For example, during the write-protected differential mounting process, the resource configuration and lifecycle management of the writable differential region are executed according to the following process: When the storage gateway of the data processing unit creates a corresponding writable differential region for the current compute node, it first queries the corresponding physical slot number based on the node identifier carried in the takeover request, and then retrieves the preset capacity quota and preset lifecycle parameters bound to the physical slot in the cluster storage management policy; the storage gateway completes the storage resource initialization of the differential region according to the preset capacity quota, using thin provisioning. Storage space is allocated in Provisioning (TP) mode, and the actual occupied capacity dynamically increases with the amount of data written by the nodes, and the total write volume must not exceed the preset capacity quota limit. After the differential region is created, the storage gateway establishes a stable mapping relationship between the differential region and the corresponding physical slot number. The built-in lifecycle management module starts status monitoring simultaneously, and the online status of the physical slot is used as the basis for timing triggering. When the compute node in the corresponding physical slot is online, the differential region remains effective and the lifecycle does not trigger a countdown. When the compute node in the physical slot is detected to be offline, the lifecycle management module starts a countdown according to the preset retention time. After the preset time is reached, the differential region is automatically cleaned up to release the corresponding storage resources, thus completing the automated management of the entire lifecycle of the differential region.

[0088] By implementing the above embodiments, the differential data of each computing node can be subject to independent resource constraints and lifecycle management, which can prevent a single node from generating excessive differential data and affecting the overall storage resources of the system. At the same time, the differential area can be managed according to the physical slot of the node, which can improve the controllability and reliability of node data management in a shared system disk environment.

[0089] In some embodiments, the aforementioned system disk mounting method may further include: obtaining the write frequency corresponding to each write operation in the writable differential region; extracting hot write data blocks from the writable differential region based on the write frequency; and caching the hot write data blocks in a non-volatile storage medium local to the data processing unit so that subsequent read requests for the hot write data blocks are responded to from the non-volatile storage medium.

[0090] In some examples, the process of obtaining the write frequency corresponding to each write operation in the writable differential region can be synchronously executed by the storage gateway running on the data processing unit during the write request processing. The storage gateway maintains an independent write statistics record table for the writable differential region corresponding to each node, recording the write timestamp and cumulative write count of each logical data block, and calculates the write frequency of each data block per unit time based on a preset sliding time window. For example, the storage gateway uses a sliding time window of one minute as the statistical period to count the cumulative write count of each 4 kilobyte (KB) data block in the writable differential region, and divides the count by the time window length to obtain the write frequency of the corresponding data block. The higher the frequency value, the more frequently the corresponding data block is accessed by write.

[0091] The process of extracting hot-write data blocks from the writable differential region based on write frequency can be executed by the hot data identification module built into the storage gateway. The module periodically reads the write frequency statistics, compares the write frequency of each data block with a preset hotness threshold, and marks the data blocks with frequencies higher than the threshold as hot-write data blocks, thus completing the extraction of the hot data set. For example, the operation and maintenance personnel can pre-configure the hotness judgment threshold as five writes per second. The storage gateway completes the write frequency statistics of all data blocks every 30 seconds, extracts all data blocks with write frequencies higher than the threshold as hot-write data blocks, and includes them in the cache candidate set. Usually, the proportion of hot-write data blocks to the total data volume of the differential region does not exceed 20%, which can cover the vast majority of high-frequency access needs.

[0092] By offloading frequently accessed data to local storage within the data processing unit, storage access latency can be reduced, alleviating bandwidth pressure on remote centralized storage. Non-volatile storage media, which persistently preserves data even after power failure, are pre-deployed on the data processing unit's board hardware and directly connected to the processing core via a high-speed bus. Caching operations are performed by the storage gateway's cache management module, which synchronously writes the complete data of hot-write data blocks to the local storage medium and establishes a mapping between logical block addresses and local storage addresses. When subsequent read requests arrive, the storage gateway first queries the local cache mapping table; if a match is found, the data is returned directly from the local medium; otherwise, it is forwarded to the remote centralized storage cluster. Solid-state drives (SSDs) are a typical implementation of this type of storage medium. The data processing unit's onboard SSD, with a capacity of several hundred gigabytes, serves as the local cache medium. After hot-write data blocks are synchronously stored in this medium, corresponding read requests from compute nodes can directly retrieve data locally, significantly reducing access latency compared to remote storage and effectively alleviating the access load on the centralized storage cluster.

[0093] For example, while processing write requests from compute nodes and redirecting them to writable differential regions, the storage gateway simultaneously initiates a write frequency statistics process. It maintains a write statistics record table for the writable differential region corresponding to the current node. For each write request processed, it updates the write timestamp and cumulative count of the corresponding logical data block, calculating the write frequency of each data block in real time based on a one-minute sliding time window. The storage gateway's built-in hot data identification module performs hot data filtering every thirty seconds, reading the write frequency statistics of all data blocks and comparing them with a preset hot data threshold of five writes per second. All data blocks with write frequencies exceeding the threshold are extracted as hot write data blocks, forming the latest hot data set. The cache management module then uses this hot data... The updated collection synchronously writes the newly added hot-write data blocks to the local solid-state drive of the data processing unit, and updates the mapping table between logical block addresses and local storage addresses. Data blocks that no longer meet the hotness criteria are cleared from the local cache, freeing up local storage space. Subsequently, when a compute node initiates a read request for differential region data through the second channel, the storage gateway first queries the local cache mapping table. If the logical block address corresponding to the request hits the cache, the data is directly read from the local solid-state drive and returned to the compute node without accessing the remote centralized storage cluster. If the cache is not hit, the read request is forwarded to the remote centralized storage cluster to complete the response. This effectively improves the access performance of high-frequency data without affecting data consistency.

[0094] By implementing the above embodiments, while maintaining write protection of the base image and isolation of node data, the read response efficiency of frequently accessed data can be improved, the performance impact of remote system disk access can be reduced, and the data access efficiency during the operation of the diskless computing system can be improved.

[0095] In some embodiments, the aforementioned system disk mounting method may further include: in response to a node reset command sent by the compute node, clearing the writable differential region corresponding to the node reset command, so that the compute node is restored to the initial state of the read-only base image region upon the next startup.

[0096] In some examples, a node reset command is a control message used to trigger a system environment restoration operation on a compute node. It is used to notify the data processing unit to clear the private differential data of the corresponding node and serves as a trigger signal to start the system reset process. The node reset command can be initiated by the local system management tool on the compute node or by the remote cluster management platform, which can then forward it to the data processing unit after sending it to the target compute node. The command message carries the node identifier of the target node to locate the writable differential area to be processed. For example, in a typical operation and maintenance scenario of a diskless personal computer farm array, the operation and maintenance personnel select the target node through the cluster management interface and trigger the system reset operation. After receiving the reset command, the agent program of the corresponding compute node encapsulates a reset request message carrying the physical slot identifier of the node and sends it to the data processing unit through the management interface to form a valid node reset command.

[0097] The storage resource management module of the data processing unit can first verify the legality of the command and the node permissions. After the verification is successful, it queries the differential region mapping table to locate the target differential storage resource, and then calls the management interface of the backend storage to complete the clearing of the differential region. For example, after the data processing unit receives the node reset command, it parses the physical slot number of the target node, verifies the legality of the node permissions, finds the writable differential storage volume bound to the slot in the local mapping table, and calls the resource management interface of the distributed storage to delete the corresponding differential volume and all its written data. The entire clearing operation can be completed in seconds.

[0098] The technical effect and design goal of differential clearing operation is to restore the compute node to the initial state of the read-only base image area upon the next startup. Relying on the hierarchical storage architecture with write-protected differential mounting, all system configuration changes, temporary files, and business data generated during the operation of the compute node are stored only in the writable differential area. The read-only base image area always maintains the pure state of the initial deployment. Therefore, after the differential area is cleared, when the node restarts, it will only load the original data of the read-only base image, without any historical running data residue. The system environment can be completely restored without redeploying the system image.

[0099] For example, when a compute node needs to restore its system environment, the system agent program running on the node receives a reset command from the local or remote cluster management platform, generates a node reset instruction carrying the node identifier, and sends it to the data processing unit through the data processing unit's management interface. After receiving the node reset instruction, the resource management module of the data processing unit first parses and extracts the node identifier from the instruction, verifies the legality of the instruction and the reset permission of the corresponding node, and after confirming the validity of the instruction, queries the differential region mapping table of the local storage to locate the writable differential region bound to the node identifier. The resource management module calls the storage management interface of the backend centralized storage cluster to perform the deletion operation of the target writable differential region, clears all historically written differential data of the node, and releases the corresponding storage resources. After the differential region is cleared, the compute node performs a restart operation. During the restart, the kernel will be loaded according to the boot process through the read-only boot logic unit number. The final mounted target system disk only contains the original data of the read-only base image region, without any historical differential data residue. The system environment is directly restored to the initial standard state corresponding to the read-only base image region, completing the entire node reset process.

[0100] By implementing the above embodiments, node environment recovery can be completed without redeploying the complete system image, which simplifies the reset process of diskless computing nodes, improves system maintenance efficiency, and ensures that the system environment after node recovery is consistent with the base image, thereby improving fault recovery and batch management capabilities.

[0101] Furthermore, as an implementation of the foregoing method embodiments, this application also provides a system disk mounting device for implementing the foregoing method embodiments. This device embodiment corresponds to the foregoing method embodiments. For ease of reading, this system disk mounting device embodiment will not repeat the details of the foregoing method embodiments one by one, but it should be clear that the device in this application embodiment can correspondingly implement all the contents of the foregoing method embodiments. For example... Figure 2As shown, the system disk mounting device 20 includes: a data acquisition unit 201, a request receiving unit 202, a channel switching unit 203, a parameter sending unit 204, and a differential mounting unit 205. The data acquisition unit 201 is used to assign a target session identifier to the computing node in response to its power-on, and write the target session identifier and system disk metadata into a preset mailbox register. The request receiving unit 202 is used to receive a takeover request generated by the computing node based on information in the preset mailbox register, wherein the takeover request may include the target session identifier and the node identifier of the computing node. The channel switching unit 203 is used to verify the takeover request and then switch the computing node to the target session identifier. The input / output path of the system disk is switched from the first channel to the second channel, and connection parameters for the second channel are generated. The first channel is a simple block device channel, and the second channel is a multi-queue data channel. The parameter sending unit 204 is used to send the second channel connection parameters to the compute node so that the compute node can mount the target system disk based on the second channel connection parameters. The differential mounting unit 205 is used to perform write-protected differential mounting on the target system disk during the process of mounting the target system disk on the compute node. The write-protected differential mounting may include dividing the target system disk into a read-only base image region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base image region to the writable differential region.

[0102] In some embodiments, the data acquisition unit 201 is further configured to, in response to the basic input / output system of the computing node accessing the read-only boot logic unit number through the boot assistant provided by the data processing unit, generate a target session identifier; acquire system disk metadata associated with the read-only boot logic unit number; and write the target session identifier and system disk metadata into a preset mailbox register.

[0103] In some embodiments, the data acquisition unit 201 is further configured to write the target session identifier and system disk metadata into a preset mailbox register, so that the agent program running in the initial memory file system after the computing node loads the operating system kernel can read the target session identifier and system disk metadata in the preset mailbox register, and the agent program can construct a takeover request based on the target session identifier, system disk metadata, node physical slot identifier and desired access mode.

[0104] In some embodiments, the takeover request also includes a one-time random number; the channel switching unit 203 is also used to perform a validity check on the target session identifier and node identifier in the takeover request; perform a uniqueness check on the one-time random number in the takeover request; after both the validity check and the uniqueness check pass, the input / output path of the computing node to the target system disk is switched from the simple block device channel to the multi-queue data channel based on the NVMe-oF Initiator, and the namespace identifier of the target system disk remains unchanged before and after the switch; based on the switched second channel, the second channel connection parameters are generated.

[0105] In some embodiments, the differential mounting unit 205 is further configured to intercept write requests sent by computing nodes through the second channel via the storage gateway on the data processing unit; obtain the target logical block address carried by the write request; and if the target logical block address falls within the address range of the read-only base mirror region, redirect the write request to the writable differential region bound to the node identifier.

[0106] In some embodiments, the writable differential region is configured with a preset capacity quota and a preset lifespan, and the preset lifespan corresponds to the physical slot corresponding to the node identifier.

[0107] In some embodiments, the system disk mounting device 20 further includes a data caching unit for obtaining the write frequency corresponding to each write operation in the writable differential region; extracting hot write data blocks from the writable differential region based on the write frequency; and caching the hot write data blocks in a non-volatile storage medium local to the data processing unit so that subsequent read requests for the hot write data blocks are responded to from the non-volatile storage medium.

[0108] In some embodiments, the system disk mounting device 20 further includes a region clearing unit, which clears the writable differential region corresponding to the node reset command in response to the node reset command sent by the compute node, so that the compute node can be restored to the initial state of the read-only base image region when it is started next time.

[0109] This application also provides a computer-readable storage medium storing computer-executable instructions or computer programs, which, when executed by a processor, will cause the processor to perform any step of the system disk mounting method provided in this application.

[0110] In some embodiments, the computer-readable storage medium may be a random access memory (RAM), a read-only memory (ROM), flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); or it may be a variety of devices that include one or any combination of the above-mentioned memories.

[0111] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0112] In some embodiments, computer-executable instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0113] In some embodiments, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0114] like Figure 3 As shown, this application also provides an electronic device 30, including a memory 310, a processor 320, and a computer program 311 stored in the memory 310 and executable on the processor. When the processor 320 executes the computer program 311, it implements any step of the above-described system disk mounting method.

[0115] This application also provides a computer program product comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer program or computer-executable instructions from the computer-readable storage medium and executes the computer program or computer-executable instructions, causing the electronic device to perform any step of the system disk mounting method described above.

[0116] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for mounting a system disk, characterized in that, A data processing unit applied in a diskless computing system, wherein the system disk mounting method includes: In response to the power-on of the compute node, a target session identifier is assigned to the compute node, and the target session identifier and system disk metadata are written to a preset mailbox register; Receive a takeover request generated by the computing node based on information in the preset mailbox register, wherein the takeover request includes the target session identifier and the node identifier of the computing node; After verifying the takeover request, the input / output path of the computing node to the target system disk is switched from the first channel to the second channel, and the connection parameters for the second channel are generated. The first channel is a simple block device channel, and the second channel is a multi-queue data channel. The second channel connection parameters are sent to the compute node so that the compute node mounts the target system disk based on the second channel connection parameters. During the process of mounting the target system disk on the computing node, write-protected differential mounting is performed on the target system disk. The write-protected differential mounting includes dividing the target system disk into a read-only base mirror region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base mirror region to the writable differential region.

2. The system disk mounting method according to claim 1, characterized in that, The step of responding to the power-on of the compute node by assigning a target session identifier to the compute node and writing the target session identifier and system disk metadata into a preset mailbox register includes: In response to the basic input / output system of the computing node, the target session identifier is generated by accessing the read-only boot logic unit number through the boot assistant provided by the data processing unit. Obtain the system disk metadata associated with the read-only boot logic unit number; Write the target session identifier and the system disk metadata into the preset mailbox register.

3. The system disk mounting method according to claim 1, characterized in that, The step of writing the target session identifier and system disk metadata into a preset mailbox register includes: The target session identifier and system disk metadata are written to a preset mailbox register, so that the agent program running on the compute node in the initial memory file system after the operating system kernel is loaded reads the target session identifier and system disk metadata from the preset mailbox register, and the agent program constructs the takeover request based on the target session identifier, the system disk metadata, the node physical slot identifier, and the desired access mode.

4. The system disk mounting method according to claim 1, characterized in that, The takeover request also includes a one-time random number; after verifying the takeover request, the input / output path of the computing node to the target system disk is switched from the first channel to the second channel, and the connection parameters for the second channel are generated, including: The legality of the target session identifier and the node identifier in the takeover request is verified; Perform a uniqueness check on the one-time random number in the takeover request; After both the validity check and the uniqueness check pass, the input / output path of the computing node to the target system disk is switched from the simple block device channel to the multi-queue data channel based on NVMe-oF Initiator, while keeping the namespace identifier of the target system disk unchanged before and after the switch; Based on the switched second channel, the connection parameters for the second channel are generated.

5. The system disk mounting method according to claim 1, characterized in that, During the process of mounting the target system disk on the computing node, the write-protected differential mount of the target system disk includes: The storage gateway on the data processing unit intercepts the write request sent by the computing node through the second channel; Obtain the address of the target logical block carried in the write request; If the target logical block address falls within the address range of the read-only base mirror region, the write request is redirected to the writable differential region bound to the node identifier.

6. The system disk mounting method according to claim 5, characterized in that, The writable differential region is configured with a preset capacity quota and a preset lifespan, and the preset lifespan corresponds to the physical slot corresponding to the node identifier.

7. The system disk mounting method according to claim 5, characterized in that, The system disk mounting method also includes: Obtain the write frequency corresponding to each write operation in the writable differential region; Based on the write frequency, hot write data blocks are extracted from the writable differential region; The hot-write data block is cached in the non-volatile storage medium local to the data processing unit so that subsequent read requests for the hot-write data block are responded to from the non-volatile storage medium.

8. The system disk mounting method according to any one of claims 1 to 7, characterized in that, The system disk mounting method also includes: In response to a node reset command sent by the compute node, the writable differential region corresponding to the node reset command is cleared so that the compute node is restored to the initial state of the read-only base image region upon the next startup.

9. A system disk mounting device, characterized in that, The data processing unit applied in a diskless computing system includes a system disk mounting device comprising: The data acquisition unit is used to allocate a target session identifier to the computing node in response to the computing node power-on, and write the target session identifier and system disk metadata into a preset mailbox register; A request receiving unit is configured to receive a takeover request generated by the computing node based on information in the preset mailbox register, wherein the takeover request includes the target session identifier and the node identifier of the computing node; The channel switching unit is used to verify the takeover request, switch the input / output path of the computing node to the target system disk from the first channel to the second channel, and generate the second channel connection parameters. The first channel is a simple block device channel, and the second channel is a multi-queue data channel. A parameter sending unit is used to send the second channel connection parameters to the computing node, so that the computing node can mount the target system disk based on the second channel connection parameters; A differential mounting unit is used to perform write-protected differential mounting on the target system disk during the process of mounting the target system disk on the computing node. The write-protected differential mounting includes dividing the target system disk into a read-only base mirror region and a writable differential region corresponding to the node identifier, and redirecting write requests for the read-only base mirror region to the writable differential region.

10. An electronic device, comprising: A memory and a processor, characterized in that the processor, when executing a computer program stored in the memory, implements the steps of the system disk mounting method as described in any one of claims 1 to 8.

Images