Data request response method, electronic equipment and storage medium

Abstract

The invention discloses a data request response method, electronic equipment and a computer readable storage medium, and is applied to a storage server, the method comprises the following steps: when a protocol layer receives a login request of a target storage client to a target storage block, the protocol layer adds a protocol layer version number, the flow guide layer is notified to update the version number of the flow guide layer based on the added version number of the protocol layer; when the protocol layer receives a data request of a target storage client for a target storage block, the data request is filled with a current protocol layer version number and forwarded to the diversion layer; the flow guide layer compares the protocol layer version number carried in the received data request with the current flow guide layer version number, if the protocol layer version number carried in the received data request is smaller than the current flow guide layer version number, the data request is intercepted, and otherwise, the data request is issued to the target storage block for response. According to the invention, expired data requests are effectively identified and intercepted, so that old requests are prevented from covering new data.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a data request and response method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] In block storage systems, when a storage server's internal processing delays or failures cause a client's data request (such as an I / O request) to be blocked, if the connection between the client and the storage server is broken and then re-established, or if the client switches to another communication path through a multipath mechanism, the client may send a new write request that overwrites the same data area before the old request is completed. Since storage servers typically process requests in the order they arrive, once the previously blocked old request is finally recovered and executed, it may write outdated data to the storage block, overwriting the newly written valid data, resulting in inconsistent storage block content or even data corruption. In related technologies, handling this problem often relies on the complex consistency mechanisms of the underlying distributed storage system or request interception at the storage infrastructure level. This approach is not only lengthy and complex to implement, but also difficult to reliably intercept old requests in abnormal scenarios such as node failures.

[0003] Therefore, how to effectively identify and intercept expired data requests to prevent old requests from overwriting new data is a technical problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] The purpose of this application is to provide a data request response method, an electronic device, and a computer-readable storage medium, which effectively identify and intercept expired data requests to prevent old requests from overwriting new data.

[0005] To achieve the above objectives, this application provides a data request-response method applied to a storage server, the storage server including a protocol layer and a flow routing layer, the method comprising:

[0006] When the protocol layer receives a login request from the target storage client for the target storage block, the protocol layer increments the protocol layer version number and notifies the flow routing layer to update the flow routing layer version number based on the incremented protocol layer version number.

[0007] When the protocol layer receives a data request for a target storage block from the target storage client, it fills the current protocol layer version number into the data request and forwards it to the flow guide layer.

[0008] The routing layer compares the protocol layer version number carried in the received data request with the current routing layer version number. If the protocol layer version number carried in the received data request is greater than or equal to the current routing layer version number, the data request is sent to the target storage block for response. If the protocol layer version number carried in the received data request is less than the current routing layer version number, the data request is intercepted.

[0009] When the protocol layer receives a login request from the target storage client for the target storage block, it also includes:

[0010] Determine if any other clients have logged in to the target storage block;

[0011] If it does not exist, the protocol layer initializes the protocol layer version number to an initial value and notifies the flow layer to initialize the flow layer version number based on the initial value.

[0012] If it exists, the protocol layer performs the step of incrementing the protocol layer version number and notifying the flow layer to update the flow layer version number based on the incremented protocol layer version number.

[0013] The process of comparing the received protocol layer version number with the current flow layer version number further includes:

[0014] If the received protocol layer version number is greater than or equal to the current routing layer version number, then the routing layer version number is updated to the received protocol layer version number.

[0015] The method further includes:

[0016] When the protocol layer receives a termination instruction sent by the target storage client, it searches for the target data request that needs to be terminated in the incomplete request chain list according to the request identifier in the termination instruction, increments the protocol layer version number, and marks the target data request as terminated.

[0017] The protocol layer returns a success response to the termination instruction and a response indicating that the target data request has been terminated to the target storage client.

[0018] The step of searching for the target data request to be terminated in the incomplete request chain based on the request identifier in the termination instruction further includes:

[0019] If the request identifier in the termination instruction is not found in the incomplete request list, a success response for the termination instruction is returned directly.

[0020] The method further includes:

[0021] If the protocol layer receives the processing result of the target data request sent by the flow guide layer, it determines whether the target data request has been marked as terminated.

[0022] If so, then discard the processing result;

[0023] If not, then determine whether to retry sending the target data request based on the response status code returned by the routing layer.

[0024] The storage server is a node in a distributed storage cluster;

[0025] The process of populating the current protocol layer version number into the data request and forwarding it to the flow guidance layer includes:

[0026] The data request is populated with the cluster metadata version number and the current protocol layer version number and then forwarded to the flow guidance layer.

[0027] Accordingly, before comparing the protocol layer version number carried in the received data request with the current flow layer version number, the flow layer further includes:

[0028] Verify whether the cluster metadata version number carried in the received data request is valid; if yes, perform the step of comparing the protocol layer version number carried in the received data request with the current traffic redirection layer version number; if no, perform the step of intercepting the data request.

[0029] The storage client connects to multiple nodes in the distributed storage cluster via multiple physical paths; the method further includes:

[0030] When the protocol layer receives a path probing request from the storage client, it responds to the path probing request so that the storage client can check the physical path corresponding to the storage server; wherein, the storage client sends path probing requests to multiple nodes in the distributed storage cluster through each physical path according to a preset time period.

[0031] To achieve the above objectives, this application provides an electronic device, comprising:

[0032] Memory, used to store computer programs;

[0033] A processor for implementing the steps of the data request-response method described above when executing the computer program.

[0034] To achieve the above objectives, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the data request-response method described above.

[0035] The data request and response method provided in this application effectively solves the problem of old data requests overwriting new data by introducing a coordinated version number mechanism between the protocol layer and the routing layer of the storage server. Specifically, whenever a target storage client initiates a login request to a target storage block, the protocol layer proactively increments its maintained protocol layer version number and notifies the routing layer to synchronously update its routing layer version number, thereby ensuring that the two versions are consistent and represent the latest state of the current session. Subsequently, all data requests sent from this client carry the current protocol layer version number when forwarded from the protocol layer to the routing layer. After receiving a data request, the routing layer compares the protocol layer version number it carries with its own currently maintained routing layer version number: only if the request version number is greater than or equal to the routing layer version number is the request allowed to continue to be sent to the storage block; if the request version number is less than the routing layer version number, the request is determined to be an old request that has been left over from a previous session and is intercepted. Since each login triggers a version number increment, and requests in new sessions inevitably carry the updated version number, even if old requests arrive at the flow layer after network or server delays, their old version number will be identified and intercepted, thus fundamentally preventing old data from overwriting new data. This application also discloses an electronic device and a computer-readable storage medium that achieve the same technical effects.

[0036] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. The drawings are used to provide a further understanding of this disclosure and constitute a part of the specification. They are used together with the following detailed description to explain this disclosure, but do not constitute a limitation of this disclosure. In the drawings:

[0038] Figure 1 This is a flowchart illustrating a data request and response method according to an exemplary embodiment;

[0039] Figure 2 This is a flowchart illustrating a method for processing a termination instruction according to an exemplary embodiment;

[0040] Figure 3 An overall architecture diagram of an application embodiment provided in this application;

[0041] Figure 4A flowchart of LUN (Logical Unit Number) login access in one application embodiment provided in this application;

[0042] Figure 5 This application provides a flowchart of an EDS (Enterprise Distributed Storage) server-side Abort request processing in one application embodiment.

[0043] Figure 6 A schematic diagram of a flow layer request termination scheme provided in one application embodiment of this application;

[0044] Figure 7 This is a structural diagram of an electronic device according to an exemplary embodiment. Detailed Implementation

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

[0046] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0047] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0048] This application discloses a data request response method that effectively identifies and intercepts expired data requests to prevent old requests from overwriting new data.

[0049] See Figure 1 A flowchart illustrating a data request and response method according to an exemplary embodiment is shown below. Figure 1 As shown, it includes:

[0050] S101: When the protocol layer receives a login request from the target storage client for the target storage block, the protocol layer increments the protocol layer version number and notifies the flow layer to update the flow layer version number based on the incremented protocol layer version number;

[0051] In this embodiment, the execution entity is a storage server, which includes a protocol layer and a traffic steering layer. The protocol layer refers to the software module in the storage server responsible for parsing communication protocols and managing sessions with storage clients. The traffic steering layer is an intermediate logical layer located between the protocol layer and the underlying storage device, used for routing, filtering, or scheduling data requests from the protocol layer.

[0052] In this step, when a target storage client initiates a login request for a target storage block for the first time or reconnects after a link failure, the protocol layer first verifies the validity of the request. Then, it increments its internally maintained protocol layer version number (e.g., from an initial value of 0 to 1) to mark the start of a new valid session. Next, the protocol layer sends the updated version number to the flow layer via an internal inter-process communication mechanism. The flow layer then updates its own maintained flow layer version number accordingly. Both the protocol layer version number and the flow layer version number are monotonically increasing integer values ​​used to identify the validity status of the current session.

[0053] As can be seen, this step ensures that the storage server maintains a consistent understanding of the current valid sessions by synchronously incrementing the version number, laying the foundation for subsequent identification and interception of expired requests.

[0054] As a feasible implementation, when the protocol layer receives a login request from the target storage client for the target storage block, it further includes: determining whether other clients have logged in to the target storage block; if not, the protocol layer initializes the protocol layer version number to an initial value and notifies the flow layer to initialize the flow layer version number based on the initial value; if so, the protocol layer increments the protocol layer version number and notifies the flow layer to update the flow layer version number based on the incremented protocol layer version number.

[0055] In practice, before processing a new login request, the protocol layer first queries the session state table or connection management module of the target storage block to confirm whether an active session already exists. If the query result is negative, meaning the storage block is currently in an idle state not used by any client, the protocol layer resets its version number to a preset initial value (e.g., 0 or 1) and notifies the flow layer to also synchronously initialize its flow layer version number to the same value, thus establishing a clean version context for the upcoming new session. Conversely, if another client is already logged in, it indicates that the storage block is in active use. In this case, the login of a new client is considered as joining or switching to the existing session environment. The protocol layer no longer resets the version number but instead increments its current value and notifies the flow layer to update synchronously.

[0056] As can be seen, this implementation method supports clean boot of the version number when a single client has exclusive access, and is also compatible with continuous version evolution in scenarios of concurrent access by multiple clients or fault switching, thereby enhancing the system's adaptability and consistency assurance capabilities under different deployment modes.

[0057] S102: When the protocol layer receives a data request from the target storage client for the target storage block, it fills the current protocol layer version number into the data request and forwards it to the flow guide layer;

[0058] A data request refers to a read / write operation instruction initiated by the client to the storage server, used to access a specific logical address range in the target storage block.

[0059] In this step, upon receiving such a data request, the protocol layer does not immediately hand it over to the lower layer for processing. Instead, it first embeds the version number maintained by the current protocol layer into its internal encapsulation structure (such as a request control block or metadata header). This version number serves as a timeliness identifier for the request and is passed to the flow control layer along with the request.

[0060] S103: The flow layer compares the protocol layer version number carried in the received data request with the current flow layer version number. If the protocol layer version number carried in the received data request is greater than or equal to the current flow layer version number, the data request is sent to the target storage block for response. If the protocol layer version number carried in the received data request is less than the current flow layer version number, the data request is intercepted.

[0061] In this step, upon receiving a data request with a version number, the routing layer first extracts the embedded protocol layer version number and compares it with its own currently maintained routing layer version number. Since the protocol layer and routing layer synchronize their version numbers after each login, they should normally be equal. However, if a new session is established due to multipath switching or reconnection, the protocol layer version number will be higher. Therefore, if the version number carried in the request is greater than or equal to the current version number of the routing layer, it indicates that the request belongs to a current or newer valid session, and the routing layer allows it to continue forwarding to the target storage block to perform actual data operations. Conversely, if the version number carried in the request is less than the current version number of the routing layer, it indicates that the request originates from an older session that has been superseded (e.g., an old write request delayed due to network latency). In this case, the routing layer actively discards or rejects the request and no longer forwards it to the storage medium.

[0062] As can be seen, this step enables accurate identification and interception of expired data requests locally on the storage server, effectively preventing data inconsistency or overwriting issues caused by delayed execution of old requests, and significantly improving the data reliability and consistency assurance capabilities of the storage system.

[0063] As a possible implementation, after comparing the received protocol layer version number with the current traffic layer version number, the traffic layer further includes: if the received protocol layer version number is greater than or equal to the current traffic layer version number, then the traffic layer version number is updated to the received protocol layer version number.

[0064] In practice, after executing the version number comparison logic, the flow guidance layer not only decides whether to allow the data request but also dynamically maintains its own version status. Specifically, when the flow guidance layer receives a data request carrying a protocol layer version number, after determining that the version number is greater than or equal to the current flow guidance layer version number, it not only allows the request to continue to be sent to the target storage block but also immediately updates its own flow guidance layer version number to the protocol layer version number carried in the request. This mechanism ensures that the flow guidance layer always tracks the latest valid session version, and even if the protocol layer fails to actively send a version synchronization notification due to an anomaly, passive version number synchronization can be achieved through the data request itself.

[0065] As can be seen, this implementation improves the robustness and self-healing capability of version synchronization, enabling the flow layer to automatically align with the latest session state through the data path, further enhancing the accuracy of intercepting expired requests, while reducing the dependence on the reliability of the control path.

[0066] The data request response method provided in this application effectively solves the problem of old data requests overwriting new data by introducing a coordinated version number mechanism between the protocol layer and the routing layer of the storage server. Specifically, whenever a target storage client initiates a login request to a target storage block, the protocol layer actively increments its maintained protocol layer version number and notifies the routing layer to synchronously update its routing layer version number, thereby ensuring that the two versions are consistent and represent the latest state of the current session. Subsequently, all data requests sent from this client carry the current protocol layer version number when forwarded to the routing layer via the protocol layer. After receiving a data request, the routing layer compares the protocol layer version number it carries with its own currently maintained routing layer version number: only if the request version number is greater than or equal to the routing layer version number is the request allowed to continue to be sent to the storage block; if the request version number is less than the routing layer version number, the request is determined to be an old request that has been left over from a previous session and is intercepted. Since each login triggers a version number increment, and requests in new sessions inevitably carry the updated version number, even if old requests arrive at the flow layer after network or server delays, the old version number they carry will be identified and intercepted, thus fundamentally preventing old data from overwriting new data.

[0067] This application discloses a method for processing termination instructions, specifically:

[0068] See Figure 2 A flowchart illustrating a method for processing a termination instruction according to an exemplary embodiment is shown below. Figure 2 As shown, it includes:

[0069] S201: When the protocol layer receives a termination instruction sent by the target storage client, it searches for the target data request that needs to be terminated in the incomplete request chain list according to the request identifier in the termination instruction, increments the protocol layer version number, and marks the target data request as terminated.

[0070] The termination command is a control command actively sent by the target storage client to the storage server to cancel a data request (such as a write or read operation) that has been issued but not yet completed. The command contains a unique request identifier to precisely indicate the request to be canceled.

[0071] In practice, the protocol layer maintains a linked list of incomplete requests, dynamically recording all data requests that have been received but have not yet received a final response from the underlying storage block, along with their status information, including request identifier, logical address, operation type, and version number. In this step, when the protocol layer receives a termination instruction, it first parses the request identifier and searches for it in the linked list of incomplete requests. If a corresponding target data request is found, two key operations are performed: first, the protocol layer version number currently maintained is incremented to indicate that the system has entered a new logical session phase; second, the status field of the target data request is updated to a terminated status, ensuring that even if it is subsequently processed by the underlying storage block, it cannot return a valid response or modify the stored content.

[0072] As can be seen, this step, by combining version number increment with explicit request marking, not only ensures the semantic invalidation of aborted requests, but also establishes new time limits for possible new requests, preventing old requests from being revived after a delay and causing data pollution.

[0073] As a possible implementation, after searching for the target data request to be terminated in the incomplete request chain based on the request identifier in the termination instruction, the method further includes: if the request identifier in the termination instruction is not found in the incomplete request chain, then a successful response to the termination instruction is returned directly.

[0074] In practice, if the request identifier in the termination instruction is not found in the incomplete request chain, it means that the data request corresponding to that request identifier was either never received or has been processed and removed from the chain (e.g., a successful response has been returned or it has been discarded by the underlying layer). In this case, the protocol layer no longer performs operations such as version number increment or status marking, but directly returns a successful abort response to the client.

[0075] S202: The protocol layer returns a successful response to the termination instruction to the target storage client, as well as a response that the target data request has been terminated.

[0076] In this step, after completing the termination process for the target data request, the protocol layer needs to provide clear operational feedback to the client to ensure that the upper-layer application can perceive the termination result and make corresponding logical adjustments. Specifically, the protocol layer constructs a success response containing two key pieces of information: first, confirming that the termination command itself has been correctly received and processed; and second, explicitly informing the client that the target data request corresponding to the specified request identifier has successfully entered the termination state.

[0077] As a feasible implementation method, this embodiment further includes: if the protocol layer receives the processing result of the target data request sent by the flow guide layer, it determines whether the target data request is marked as terminated; if so, the processing result is discarded; if not, it determines whether to retry sending the target data request based on the response status code returned by the flow guide layer.

[0078] Understandably, in this implementation, due to the asynchronous processing characteristics of the storage system, even if a data request has been aborted and marked as terminated by the client, it may still continue to execute in the processing queue of the routing layer or the underlying storage device, and eventually return a processing result. Therefore, after receiving the processing result from the routing layer, the protocol layer first checks the status of the request in its local record. If it finds that the request has been marked as terminated, regardless of whether the processing result is successful or failed, the protocol layer actively discards the result, does not forward it to the client, and does not trigger any subsequent actions, thereby ensuring that the aborted request will not have side effects on the upper-layer application. Conversely, if the request is not marked as terminated, the protocol layer further parses the response status code returned by the routing layer and determines whether the request needs to be retried according to a preset strategy. For example, for recoverable transient errors, the request can be re-added to the delivery queue; while for permanent errors, a failure is directly returned. For example, if a write request encounters a network interruption during transmission, the routing layer returns a connection timeout status code. The protocol layer recognizes that the error is a retryable type and that the request has not been terminated, so it re-encapsulates it and sends it again.

[0079] As can be seen, this implementation achieves end-to-end closed-loop protection for abort semantics, preventing cancelled but still active requests from disrupting data consistency.

[0080] Therefore, this embodiment combines request abort operation with a protocol layer version number increment mechanism, supplemented by request status marking and result filtering strategies, to achieve complete isolation of cancelled requests. This embodiment effectively solves the semantic inconsistency problem in traditional storage systems where requests are cancelled but still being executed, preventing old requests with delayed completion from interfering with new sessions or overwriting valid data.

[0081] Based on the above embodiments, as a preferred implementation, the storage server is a node in a distributed storage cluster; correspondingly, filling the data request with the current protocol layer version number and forwarding it to the flow guide layer includes: filling the data request with the cluster metadata version number and the current protocol layer version number and forwarding it to the flow guide layer; correspondingly, before the flow guide layer compares the protocol layer version number carried in the received data request with the current flow guide layer version number, it further includes: verifying whether the cluster metadata version number carried in the received data request is valid; if yes, then the step of comparing the protocol layer version number carried in the received data request with the current flow guide layer version number is performed; if no, then the step of intercepting the data request is performed.

[0082] Among them, a distributed storage cluster refers to a system architecture in which multiple storage server nodes work together to provide unified storage services. Each node shares global metadata about storage resources, and the cluster metadata version is a monotonically increasing sequence number used to identify the current consistent state of the global metadata.

[0083] In practice, when a storage client accesses a target storage block through a node, the node's protocol layer needs to maintain not only the local session's protocol layer version number but also the latest metadata version number of the current cluster. Before forwarding the data request, the protocol layer embeds both version numbers into the request's metadata header. When processing the request, the routing layer first verifies whether the cluster metadata version number carried is consistent with the latest metadata version currently cached by the node. If they are inconsistent, the request context is deemed invalid, and the request is directly intercepted without further protocol layer version comparison. If they are consistent, the step of comparing the protocol layer version number carried in the received data request with the current routing layer version number is performed.

[0084] As can be seen, this implementation method, based on local session consistency assurance, further introduces cluster-level metadata timeliness verification, effectively preventing illegal data operations caused by inconsistent node views, thereby realizing a dual version protection mechanism in a distributed environment and significantly improving the overall data security of the system.

[0085] Based on the above embodiments, as a preferred implementation, the storage client connects to multiple nodes in the distributed storage cluster through multiple physical paths; the above embodiments also include: when the protocol layer receives a path probing request from the storage client, it responds to the path probing request so that the storage client can check the physical path corresponding to the storage server; wherein, the storage client sends path probing requests to multiple nodes in the distributed storage cluster through each physical path according to a preset time period.

[0086] In practice, storage clients establish redundant connections with multiple nodes in the distributed storage cluster through multiple physical paths. To ensure path availability, the storage client proactively sends path probe requests to the nodes corresponding to each path at preset intervals. These requests typically do not carry actual load and are only used to detect link connectivity and node responsiveness. When the protocol layer of any storage server node receives such a probe request, it immediately returns a brief success response without going through the routing layer or underlying storage processing. The client determines the health of the physical path based on whether it receives a response within the timeout window and dynamically adjusts the routing strategy for subsequent data requests accordingly.

[0087] The following describes an application embodiment provided by this application, with the overall architecture as follows: Figure 3 As shown, it includes storage clients and EDS storage service providers. Storage clients mainly include virtualization platforms, Windows Servers, Linux servers, etc., while EDS storage service providers can be dual-controller array devices.

[0088] The client storage application software mainly includes an iSCSI (Internet Small Computer System Interface) initiator and an NVMe (Non-Volatile Memory Express) initiator. After the parameters are configured correctly, it can be connected to the EDS storage service. Figure 3 This indicates that the same client connects to two EDS nodes through two paths. After a client successfully connects to a LUN, the operating system mounts it as a block device. The same LUN connected through multiple paths will appear as different block devices on the operating system. The multipathing software is mainly responsible for managing the block devices, mapping different block devices corresponding to the same LUN to the same virtual disk. Subsequent operations only require IO (Input / Output) on the virtual disk. The protocol layer of the EDS storage service is mainly responsible for parsing the iSCSI or NVMe protocol and initializing an IO version number upon first connection. The routing service is responsible for recording the maximum version number of the current node and verifying whether the version number brought by the protocol layer IO request meets the requirements, using this as a criterion to intercept IO.

[0089] The LUN login access process is as follows: Figure 4As shown, the client can initiate a login request using an iSCSI or NVMe initiator and after configuring the relevant settings. When the EDS protocol parsing module receives the login request, it parses it according to the standard protocol and determines the validity of the login request. After parsing and validating the request, the protocol layer needs to determine if this is the first login to the LUN. If it is the first time accessing the LUN, the protocol layer needs to reset the version number and also needs to pass the reset version number flag to the data routing layer, notifying the routing layer to reset its routing version number, thus ensuring that the protocol layer version number and the routing layer version number are the same. If it is not the first login, for example, if this LUN has already been logged into by a client, and then another client logs into this LUN again, the protocol layer version number needs to be incremented, and the protocol layer passes the latest version number to the routing layer, notifying the routing layer to update to the latest version number. The data routing layer also maintains a routing version number; therefore, the IO request interception function can be implemented simply by comparing the version numbers.

[0090] The Abort command is a command sent by the client to terminate an I / O request. When the client does not receive an I / O response from the storage service provider for an extended period of time, it will actively terminate the I / O request. This extended period is typically 3 seconds or more, but may vary depending on the client. The Abort command includes the ID of the I / O request to be terminated, allowing the storage service provider to identify the specific I / O request that needs to be terminated based on this ID.

[0091] The EDS server handles Abort requests as follows: Figure 5As shown, when the client detects that an IO request has not returned, it sends an Abort command to the EDS storage service, along with the ID of the terminated IO request. The protocol layer then parses the Abort command. The protocol layer places all incomplete IO requests into a linked list. When the protocol layer retrieves the ID of the IO request to be terminated from the Abort command, if no such request is found in the linked list, the Abort request returns immediately because there is no IO request to be terminated. If a IO request to be terminated is found in the linked list, the protocol layer immediately increments its version number and marks the current IO request as terminated. Subsequently, for the terminated IO request, the protocol layer returns a response to the client with a status code indicating that the IO was terminated; for the Abort command request, the protocol layer also returns a response to the client with a success status code. After these steps, the client receives response information for both requests, but the IO requests stuck at the storage service are not actually completed. After a terminated I / O request is returned from the flow layer to the protocol layer, it's necessary to determine if the request is in a terminated state. Software exceptions or other reasons may cause I / O requests that should be marked as terminated to fail to be marked as terminated. Checking the request's termination status provides a fallback for I / O requests affected by exceptions. If the request is in a terminated state, it is discarded without further processing. If the request is not marked as terminated, the specific status code returned by the flow layer is used to determine whether the I / O request needs to be retried.

[0092] The flow layer request termination scheme is as follows: Figure 6As shown in the diagram, the LUN home module is the aforementioned routing layer. When an I / O operation triggers an abort request due to timeout, the block device first sends an abort request to the protocol layer (step 1). Upon receiving the request, the protocol layer immediately marks the corresponding I / O task as terminated (step 2) and returns a success response to the block device (step 3), ensuring that the upper-layer application is aware that the request has been cancelled. Then, a loop processing logic is entered, continuously attempting to send the I / O request through available paths until the maximum retry time, no_path_retry, is reached. In each loop, the system first selects the path group with the highest priority of currently valid paths and chooses a specific path for transmission (step 4). Next, the I / O request is forwarded to the protocol layer through the transport layer (step 5). The protocol layer fills the request with context information such as the current node identifier (node_id), node version number (node_ver), and cluster metadata version number (mds_epoch) (step 6), and then sends the encapsulated request to the LUN home module through the storage private network (step 7). After receiving the request, the LUN home module first verifies the validity of the cluster metadata version number it carries (step 8). If the verification is successful, it continues to verify whether the node version number matches. If the verification fails, it determines that the request context has expired, discards it directly, and returns an error (step 11). If the verification passes, the I / O request is sent to the backend storage (such as logcache) for execution (step 9), and the result is returned after completion (step 10). If the request is dropped or aborted during the sending process, the system will discard the request and try to resend it using a new node version number (step 12). Finally, regardless of success or failure, the result will be returned to the business layer (step 13), and one cycle will be completed (step 14). Multipathd periodically initiates path detection tasks (step 15), sending tur (Test Unit Ready) or io probe requests to each physical path (step 16) to verify link connectivity and node responsiveness. After receiving the probe request, the protocol layer can quickly return the result without complex processing (step 17). If the probe is successful, the path status is set to active (step 19), indicating that it can participate in subsequent I / O scheduling; otherwise, the path will be marked as unavailable to avoid being selected.

[0093] Each I / O request sent from the protocol layer to the routing layer carries the latest protocol layer version number. Upon receiving the request, the routing layer compares the protocol layer version number with the routing layer version number. These two version numbers control whether the I / O request should be intercepted, following these rules: if the protocol layer version number is greater than or equal to the routing layer version number, the I / O request is allowed; if the protocol layer version number is less than the routing layer version number, the I / O request is not allowed, and a special error code is returned to the protocol layer. If, during the version number comparison, the routing layer detects that the protocol layer version number is greater than its own version number, it automatically updates its own version number to match the protocol layer version number.

[0094] As can be seen, when the client sends an Abort request to the protocol layer, the protocol layer's version number increments, becoming larger than the version number of the stuck IO request. Therefore, when subsequent IO requests with overlapping regions are sent to the protocol layer first to obtain the latest protocol layer version number, and then the IO request continues to be sent to the flow control layer, the comparison of the two version numbers achieves the function of intercepting old IO (i.e., stuck IO) requests, avoiding the problem of old IO data overwriting new IO data.

[0095] To implement the method of the embodiments of this application, the embodiments of this application also provide an electronic device. Figure 7 This is a structural diagram of an electronic device according to an exemplary embodiment, such as... Figure 7 As shown, the electronic device includes:

[0096] Communication interface 1 enables information exchange with other devices, such as network devices;

[0097] Processor 2 is connected to communication interface 1 to enable information interaction with other devices and, when running a computer program, executes the data request and response methods provided by one or more of the above-mentioned technical solutions. The computer program is stored in memory 3.

[0098] Of course, in practical applications, the various components in an electronic device are coupled together through bus system 4. It can be understood that bus system 4 is used to achieve communication and connection between these components. In addition to the data bus, bus system 4 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 7 The general will label all buses as Bus System 4.

[0099] The memory 3 in this embodiment is used to store various types of data to support the operation of the electronic device. Examples of such data include any computer program used to operate on the electronic device.

[0100] It is understood that memory 3 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), ferromagnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM); magnetic surface memory can be disk storage or magnetic tape storage. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Synchronous Static Random Access Memory (SSRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic Random Access Memory (SDRAM), Double Data Rate Synchronous Dynamic Random Access Memory (DDRSDRAM), Enhanced Synchronous Dynamic Random Access Memory (ESDRAM), SyncLink Dynamic Random Access Memory (SLDRAM), and Direct Rambus Random Access Memory (DRRAM).The memory 3 described in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0101] The methods disclosed in the embodiments of this application can be applied to processor 2, or implemented by processor 2. Processor 2 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 2 or by instructions in the form of software. The processor 2 may be a general-purpose processor, DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 2 can implement or execute the methods, steps and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software modules may be located in a storage medium, which is located in memory 3. Processor 2 reads the program in memory 3 and completes the steps of the aforementioned method in combination with its hardware.

[0102] When processor 2 executes the program, it implements the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, these will not be described in detail here.

[0103] In an exemplary embodiment, this application also provides a storage medium, namely a computer storage medium, specifically a computer-readable storage medium, such as a memory 3 that stores a computer program, which can be executed by a processor 2 to complete the steps described in the aforementioned method. The computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM.

[0104] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0105] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A data request and response method, characterized in that, Applied to a storage server, the storage server including a protocol layer and a traffic routing layer, the method includes: When the protocol layer receives a login request from the target storage client for the target storage block, the protocol layer increments the protocol layer version number and notifies the flow routing layer to update the flow routing layer version number based on the incremented protocol layer version number. When the protocol layer receives a data request for a target storage block from the target storage client, it fills the current protocol layer version number into the data request and forwards it to the flow guide layer. The routing layer compares the protocol layer version number carried in the received data request with the current routing layer version number. If the protocol layer version number carried in the received data request is greater than or equal to the current routing layer version number, the data request is sent to the target storage block for response. If the protocol layer version number carried in the received data request is less than the current routing layer version number, the data request is intercepted.

2. The data request and response method according to claim 1, characterized in that, When the protocol layer receives a login request from the target storage client for the target storage block, it also includes: Determine if any other clients have logged in to the target storage block; If it does not exist, the protocol layer initializes the protocol layer version number to an initial value and notifies the flow layer to initialize the flow layer version number based on the initial value. If it exists, the protocol layer performs the step of incrementing the protocol layer version number and notifying the flow layer to update the flow layer version number based on the incremented protocol layer version number.

3. The data request and response method according to claim 1, characterized in that, After comparing the received protocol layer version number with the current flow layer version number, the flow layer further includes: If the received protocol layer version number is greater than or equal to the current routing layer version number, then the routing layer version number is updated to the received protocol layer version number.

4. The data request and response method according to claim 1, characterized in that, The method further includes: When the protocol layer receives a termination instruction sent by the target storage client, it searches for the target data request that needs to be terminated in the incomplete request chain list according to the request identifier in the termination instruction, increments the protocol layer version number, and marks the target data request as terminated. The protocol layer returns a success response to the termination instruction and a response indicating that the target data request has been terminated to the target storage client.

5. The data request and response method according to claim 4, characterized in that, After searching for the target data request to be terminated in the incomplete request list based on the request identifier in the termination instruction, the method further includes: If the request identifier in the termination instruction is not found in the incomplete request list, a success response for the termination instruction is returned directly.

6. The data request and response method according to claim 4, characterized in that, The method further includes: If the protocol layer receives the processing result of the target data request sent by the flow guide layer, it determines whether the target data request has been marked as terminated. If so, then discard the processing result; If not, then determine whether to retry sending the target data request based on the response status code returned by the routing layer.

7. The data request and response method according to claim 1, characterized in that, The storage server is a node in a distributed storage cluster; The process of populating the current protocol layer version number into the data request and forwarding it to the flow guidance layer includes: The data request is populated with the cluster metadata version number and the current protocol layer version number and then forwarded to the flow guidance layer. Accordingly, before comparing the protocol layer version number carried in the received data request with the current flow layer version number, the flow layer further includes: Verify whether the cluster metadata version number carried in the received data request is valid; if yes, perform the step of comparing the protocol layer version number carried in the received data request with the current traffic redirection layer version number; if no, perform the step of intercepting the data request.

8. The data request and response method according to claim 7, characterized in that, The storage client connects to multiple nodes in the distributed storage cluster via multiple physical paths; the method further includes: When the protocol layer receives a path probing request from the storage client, it responds to the path probing request so that the storage client can check the physical path corresponding to the storage server; wherein, the storage client sends path probing requests to multiple nodes in the distributed storage cluster through each physical path according to a preset time period.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the data request-response method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the data request-response method as described in any one of claims 1 to 8.

Images