File operation method, program product, electronic device and storage medium

By receiving the client's reopen request on the Samba server and resuming the connection with persistent identifiers, the business interruption problem caused by network interruption or restart of the Samba server is solved, and business continuity and user experience are improved.

CN120492409APending Publication Date: 2025-08-15SANGFOR TECH INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510499843.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-18
Publication Date
2025-08-15

AI Technical Summary

Technical Problem

When the Samba server network is interrupted or the service process restarts, the client connection is interrupted, resulting in business interruption, and the user experience is poor.

Method used

The server receives the client's reopen request, re-establishes the access link with the persistent identifier, restores the connection by querying the second persistent identifier of the preset area, and implements failover in the cluster, optimizing the processing logic of non-idempotent operations.

Benefits of technology

It improves the service continuity, ensures the client's business continuity, improves the user experience, and enhances the system's availability in failure scenarios.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120492409A_ABST
    Figure CN120492409A_ABST
Patent Text Reader

Abstract

The embodiment of the invention is applicable to the technical field of computers, and provides a file operation method, a program product, electronic equipment and a storage medium, the method comprises the following steps: receiving a reopening request sent by a client, the reopening request is used for reestablishing an access link for a target file, the reopening request comprises a first persistent identifier, and the first persistent identifier is used for reestablishing an access link for the target file; the first persistent identifier is used for positioning the storage position of the target file and representing that the client has the permission to access the target file; querying a corresponding second persistent identifier according to the first persistent identifier; wherein the second persistent identifier is created in response to an opening request sent by the client and is stored in a preset area, and the second persistent identifier supports to be queried by any server after being created; the first persistent identifier is stored in the client; and if the corresponding second persistent identifier is queried, re-establishing an access link to the target file, and sending a response message to the client.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a file operation method, program product, electronic device and storage medium. Background Art

[0002] Samba is software that implements the SMB (Server Message Block) protocol on an operating system and consists of server and client programs. The SMB protocol is a stateful protocol. In related technologies, when a Samba server experiences a network outage or a service process restart, the connection between the Samba server and the client is lost, causing the client to immediately return an error to the application, resulting in service interruption and a poor user experience. Summary of the Invention

[0003] In view of this, embodiments of the present application provide a file operation method, a program product, an electronic device, and a storage medium.

[0004] The technical solution of the embodiment of the present application is implemented as follows:

[0005] On the one hand, an embodiment of the present application provides a file operation method, which is applied to a server, and the method includes:

[0006] receiving a reopen request sent by a client, the reopen request being used to re-establish an access link to a target file, the reopen request including a first persistent identifier being used to locate a storage location of the target file and indicating that the client has permission to access the target file;

[0007] Querying a corresponding second persistent identifier based on the first persistent identifier; wherein the second persistent identifier is created in response to an open request sent by the client and stored in a preset area, and the second persistent identifier supports querying by any server after creation; the first persistent identifier is stored on the client;

[0008] If the corresponding second persistent identifier is found, an access link to the target file is re-established, and a response message is sent to the client.

[0009] In the above solution, before receiving the reopening request sent by the client, the method further includes:

[0010] Receive an open request sent by the client; the open request is used to obtain access rights to the target file;

[0011] A persistent identifier is constructed according to the open request, and the persistent identifier is sent to the client; the persistent identifier stored in the client is a first persistent identifier, and the persistent identifier stored in the preset area is a second persistent identifier.

[0012] In the above scheme, the server runs on the second node of the cluster, and the cluster includes at least a first node and a second node. The client accesses the first node through a virtual IP address and accesses the target file. The first node stores the second persistent identifier in a preset area; when the first node fails, the virtual IP address of the client drifts to the second node; when the client initiates a reopening request for the target file, the server is used to execute the steps of receiving the reopening request sent by the client and subsequent steps.

[0013] In the above solution, the method further includes:

[0014] Receiving a non-idempotent operation request sent by the client;

[0015] Sending the non-idempotent operation request to the file system;

[0016] If an error message returned by the file system is received, it is determined whether to return an operation success response to the client according to the process startup time of the server.

[0017] In the above solution, the non-idempotent operation request is a create request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0018] If the difference between the process start time and the current time does not exceed the first threshold, and the difference between the creation time of the file corresponding to the creation request and the current time does not exceed the second threshold, a creation success response is returned to the client.

[0019] In the above solution, the non-idempotent operation request is a rename request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0020] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the rename request;

[0021] generating a successful access link creation response according to the first setting identifier and sending the response to the client, so that the client sends a rename request according to the first setting identifier;

[0022] determining whether the renaming request sent by the client includes the first setting identifier;

[0023] If the renaming request includes the first setting identifier, a renaming success response is returned to the client.

[0024] In the above solution, the non-idempotent operation request is a delete request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0025] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the deletion request;

[0026] generating a successful creation response of the access link according to the second setting identifier and sending the response to the client, so that the client sends a deletion request according to the second setting identifier;

[0027] determining whether the deletion request sent by the client includes the second setting identifier;

[0028] If the deletion request includes the second setting identifier, a deletion success response is returned to the client.

[0029] On the other hand, an embodiment of the present application provides a file operation method, applied to a client, the method comprising:

[0030] When the access link to the target file of the client is disconnected, a reopen request is sent to the server, wherein the reopen request is used to re-establish the access link to the target file, and the reopen request includes a first persistent identifier, wherein the first persistent identifier is used to locate the storage location of the target file and indicates that the client has the authority to access the target file; the server is used to query the corresponding second persistent identifier based on the first persistent identifier, and if the corresponding second persistent identifier is queried, the access link to the target file is re-established, and a response message is sent to the client; wherein the second persistent identifier is created in response to the open request sent by the client and stored in a preset area, and the second persistent identifier supports being queried by any server after creation; the first persistent identifier and the corresponding second persistent identifier carry the same identifier, and the first persistent identifier is stored on the client;

[0031] A response message sent by the server is obtained, and the server is used to re-establish an access link to the target file according to the persistent identifier.

[0032] In the above solution, before sending the reopen request to the server, the method further includes:

[0033] Sending an open request to the server; the open request is used to obtain access rights to the target file; the server is used to construct a persistent identifier according to the open request, and send the persistent identifier to the client;

[0034] The persistent identifier sent by the server is received and stored, and the persistent identifier stored in the client is a first persistent identifier.

[0035] On the other hand, an embodiment of the present application further provides an electronic device comprising: a processor and a memory for storing a computer program that can be run on the processor, wherein the processor is configured to execute the steps of the file operation method in the above scheme when running the computer program.

[0036] On the other hand, an embodiment of the present application further provides a computer storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the file operation method in the above scheme are implemented.

[0037] On the other hand, an embodiment of the present application further provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the file operation method in the above-mentioned scheme.

[0038] The server of the embodiment of the present application receives a reopen request sent by the client, and the reopen request is used to re-establish the access link to the target file. The reopen request includes a first persistent identifier, and the first persistent identifier is used to locate the storage location of the target file and indicates that the client has the authority to access the target file. The server queries the corresponding second persistent identifier based on the first persistent identifier. The second persistent identifier is created in response to the open request sent by the client and stored in a preset area. After creation, the second persistent identifier supports querying by any server, and the first persistent identifier is stored in the client. If the server queries the corresponding second persistent identifier, it re-establishes the access link to the target file and sends a response message to the client. The embodiment of the present application stores the second persistent identifier in a preset area. When the client disconnects the access link to the target file, the client can send a reopen request based on the first persistent identifier. Any server can query the corresponding second persistent identifier based on the first persistent identifier, thereby re-establishing the client's access link to the target file and restoring the client's business connection. The embodiment of the present application improves the server's support capability for business continuity, ensures the client's business continuity, and improves user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A flowchart of a file operation method provided in an embodiment of the present application;

[0040] Figure 2This is a schematic diagram of a file operation process provided by an embodiment of the present invention;

[0041] Figure 3 is a schematic diagram of another file operation process provided by an embodiment of the present invention;

[0042] Figure 4 is a schematic diagram of another file operation process provided by an embodiment of the present invention;

[0043] Figure 5 This is a schematic diagram of a processing flow of a non-idempotent operation provided by an embodiment of the present invention;

[0044] Figure 6 This is a schematic diagram of another processing flow of a non-idempotent operation provided by an embodiment of the present invention;

[0045] Figure 7 This is a schematic diagram of another processing flow of a non-idempotent operation provided by an embodiment of the present invention;

[0046] Figure 8 A flowchart of another file operation method provided in an embodiment of the application;

[0047] Figure 9 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0048] The present application will be described in further detail below with reference to the accompanying drawings and embodiments.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application pertains. The terms used herein in the specification of this application are for the purpose of describing specific embodiments only and are not intended to limit this application.

[0050] In view of the shortcomings of the above-mentioned background technology, the embodiment of the present application provides a file operation method. In order to illustrate the technical solution described in the present application, a specific embodiment is provided below for description.

[0051] Figure 1 This is a flowchart of a file operation method provided in an embodiment of the present application. The method is applied to the server, referring to Figure 1 , the method comprising:

[0052] S101, receiving a reopen request sent by a client, wherein the reopen request is used to re-establish an access link to a target file, and the reopen request includes a first persistent identifier, which is used to locate a storage location of the target file and indicates that the client has permission to access the target file.

[0053] The client and the server may support the SMB protocol, and Samba software may be installed on the client and the server to implement the SMB protocol.

[0054] If the connection between the client and the server is interrupted, the client's business will also be interrupted. For example, if the file system service process restarts abnormally or the network is interrupted, the client and server connection will be interrupted.

[0055] After the connection between the client and the server is disconnected, the client sends a reopen request to the server, which is used to re-establish the access link to the target file.

[0056] The reopen request carries a first persistent identifier, which is used to locate the storage location of the target file and indicates that the client has permission to access the target file.

[0057] The first persistent identifier is stored in the client, and the first persistent identifier may be created by the server and sent to the client.

[0058] S102, querying a corresponding second persistent identifier based on the first persistent identifier; wherein the second persistent identifier is created in response to an open request sent by the client and stored in a preset area, and the second persistent identifier supports querying by any server after creation; the first persistent identifier is stored on the client.

[0059] The client sends an open request for the target file to the server, and the server creates a second persistent identifier in response to the open request and stores the second persistent identifier in a preset area.

[0060] In some embodiments, the preset area may be a metadata server (MDS) or a cache layer, and the MDS is responsible for managing and storing metadata information such as the directory structure and permissions of the file system.

[0061] The second persistent identifier stored in the preset area can be queried by any server.

[0062] In some embodiments, the first persistent identifier and the second persistent identifier may have the same identifier, and the server may query in a preset area whether there is a second persistent identifier having the same identifier as the first persistent identifier.

[0063] S103: If the corresponding second persistent identifier is found, re-establish the access link to the target file and send a response message to the client.

[0064] If the server finds the second persistent identifier corresponding to the first persistent identifier, it re-establishes the access link to the target file and sends a response message to the client.

[0065] For example, if a second persistent identifier that is identical to the identifier of the first persistent identifier is found in the preset area, it indicates that the client has the authority to access the target file, and the access link to the target file can be re-established.

[0066] The storage location of the target file can be located according to the retrieved second persistent identifier, and an access link to the target file can be re-established according to the storage location of the target file.

[0067] After the access link to the target file is re-established, the client's business connection can be restored.

[0068] The server of the embodiment of the present application receives a reopen request sent by the client, and the reopen request is used to re-establish the access link to the target file. The reopen request includes a first persistent identifier, and the first persistent identifier is used to locate the storage location of the target file and indicates that the client has the authority to access the target file. The server queries the corresponding second persistent identifier based on the first persistent identifier. The second persistent identifier is created in response to the open request sent by the client and stored in a preset area. After creation, the second persistent identifier supports querying by any server, and the first persistent identifier is stored in the client. If the server queries the corresponding second persistent identifier, it re-establishes the access link to the target file and sends a response message to the client. The embodiment of the present application stores the second persistent identifier in a preset area. When the client disconnects the access link to the target file, the client can send a reopen request based on the first persistent identifier. Any server can query the corresponding second persistent identifier based on the first persistent identifier, thereby re-establishing the client's access link to the target file and restoring the client's business connection. The embodiment of the present application improves the server's support capability for business continuity and ensures the client's business continuity.

[0069] In some embodiments, before receiving the reopen request sent by the client, the method further includes:

[0070] Receive an open request sent by the client; the open request is used to obtain access rights to the target file;

[0071] A persistent identifier is constructed according to the open request, and the persistent identifier is sent to the client; the persistent identifier stored in the client is a first persistent identifier, and the persistent identifier stored in the preset area is a second persistent identifier.

[0072] The client sends an open request for the target file to the server. The server creates a persistent identifier in response to the open request, stores the persistent identifier in a preset area, and sends the persistent identifier to the client.

[0073] The persistent identifier stored in the client is the first persistent identifier, and the persistent identifier stored in the preset area is the second persistent identifier. The first persistent identifier and the second persistent identifier may have the same identifier.

[0074] In addition, when constructing a persistent identifier, the server can also construct corresponding persistent data. The persistent identifier and persistent data are stored in a preset area in the form of key-value pairs. The persistent data may include information such as the creation time of the persistent identifier.

[0075] This embodiment saves the client's persistent identifier. After the client disconnects from the server, it can still re-establish access to the target file based on the persistent identifier, thereby restoring the client's service connection. This enables the server to have complete Continuous Availability (CA) capabilities, ensuring that client services are not interrupted during upgrades or restarts of the underlying file system service.

[0076] In some embodiments, re-establishing the access link to the target file includes:

[0077] verifying the second persistent identifier;

[0078] If the second persistent identifier passes verification, the access link to the target file is re-established.

[0079] Here, after the corresponding second persistent identifier is found, the second persistent identifier needs to be verified to ensure access security.

[0080] In some embodiments, verifying the second persistent identifier includes:

[0081] determining whether the creation time of the second persistent identifier is within a preset time range;

[0082] If the creation time of the second persistent identifier is within the preset time range, it is determined that the verification of the second persistent identifier has passed.

[0083] For example, the second persistent identifier has an expiration time after creation. It is possible to determine whether the second persistent identifier has expired based on the current time and the creation time of the second persistent identifier. If it has expired, the second persistent identifier is invalid and the verification fails. If it has not expired, the second persistent identifier passes the verification.

[0084] The above embodiment can extend the CA feature of the server, so that after the connection between the server and the client is interrupted, the access link to the target file can be re-established, thereby maximizing the server's ability to support business continuity.

[0085] like Figure 2 As shown, Figure 2This is a schematic diagram of a file operation process provided by an embodiment of the present invention. After the server opens CA, the simplified open process is:

[0086] 1) The client sends an open request to the server.

[0087] The open request corresponds to the above open request.

[0088] 2) The server builds the persistent handle (ph) key and ph data.

[0089] phkey corresponds to the above persistent identifier, and phdata is the persistent data.

[0090] In some embodiments, the ph key can be 64 bits, with the first 32 bits marking the CA mode and node, and the last 32 bits being a random number. ph data can include information such as a rejection lock, a globally unique identifier (GUID), a persistent, backend cookie, an oplock, and a global ID.

[0091] 3)Persist the ph key and ph data.

[0092] The server stores the ph key and ph data persistently in a preset area, and the client can restore to the previous open state when reopening.

[0093] 4) The server adds DH2C or DHnC to the Response and replies to the client.

[0094] The Response carries the ph key, and the client can subsequently carry the ph key in the reopen request to restore the previous open state.

[0095] If CA is not enabled on the server, the server will construct the phkey after receiving the open request from the client, but will not persist the phkey.

[0096] refer to Figure 3 , Figure 3 This is a schematic diagram of another file operation process provided by an embodiment of the present invention. After the server extends CA, regardless of whether the server has enabled the CA feature, when a process restarts abnormally or the network is interrupted, the client will send a reopen request. The reopen request corresponds to the aforementioned reopen request. The server's reopen processing process includes:

[0097] 1) The client sends a reopen request to the server.

[0098] The reopen request carries phkey, which is the first persistent identifier mentioned above.

[0099] 2) The server searches for ph data based on ph key.

[0100] The server searches for the previous open state based on the ph key and returns the ph data.

[0101] That is, the server searches for the corresponding second persistent identifier in the preset area according to the first persistent identifier, and returns ph data if the second persistent identifier is found.

[0102] 3a) If the ph key is not found, reopen it;

[0103] 3b) If the ph key is found, verify the ph data.

[0104] If the ph key is not found in the preset area, the server needs to reopen.

[0105] If phkey is found in the preset area, ph data is checked, for example, to determine whether the creation time is within a preset time range.

[0106] 4a) If the ph data verification passes, a reopen is initiated;

[0107] 4b) If the ph data verification fails, a failure is returned.

[0108] After verification is successful, the server re-establishes access to the target file.

[0109] If verification fails, failure is returned.

[0110] 5) Return reopen Response to the client.

[0111] The server returns a reopen response to the client, including two cases: reopen success and reopen failure.

[0112] In some embodiments, the server runs on the second node of a cluster, and the cluster includes at least a first node and a second node. The client accesses the first node through a virtual IP address and accesses the target file. The first node stores the second persistent identifier in a preset area; when the first node fails, the virtual IP address of the client drifts to the second node; when the client initiates a reopening request for the target file, the server is used to execute the steps of receiving the reopening request sent by the client and subsequent steps.

[0113] This embodiment can be applied to distributed storage systems, which are generally composed of multiple hosts (multiple nodes). Client services are generally accessed through a single node, which results in service interruption if a single node fails. This embodiment establishes failover capabilities by storing the second persistent identifier in a preset area that can be accessed by all nodes.

[0114] For example, Figure 4 As shown, Figure 4 This is a schematic diagram of another file operation process provided by an embodiment of the present invention, including:

[0115] 1) The client accesses node 1 through a virtual IP (VIP).

[0116] Here, node1 corresponds to the first node.

[0117] 2a)node1 constructs ph key and ph data.

[0118] 2b) Persistently open to MDS.

[0119] After the client accesses node1 to access the file, node1 constructs the ph key and ph data, and stores the ph key and ph data persistently in the preset area.

[0120] Here, the preset area can be MDS. By persisting the open state to the cluster MDS instead of a single-node key-value storage database (Tombstone Database, TDB), different nodes can obtain the open state.

[0121] 3) Node1 fails, and the VIP accessed by the client shifts to the normal node node2.

[0122] The failure of node1 will cause the network between the client and node1 to be disconnected, and the VIP will drift to the normal node node2.

[0123] 4) The client initiates a reopen request to node2.

[0124] Here, node2 corresponds to the second node.

[0125] 5) The server on node2 processes the reopen request.

[0126] Node2 searches for phkey and verifies ph data. This step can refer to the reopen process in the above embodiment.

[0127] 6) Return the reopen result.

[0128] If node2 reopens successfully, it returns a reopen success message to the client.

[0129] This embodiment builds a failover capability by storing the second persistent identifier in a preset area so that each node can access the preset area to obtain the second persistent identifier, thereby processing the reopen request sent by the client and subsequent steps.

[0130] SMB clients can replay operations, and if a read operation occurred during a failover, the read operation will be replayed. These types of operations are called idempotent operations. However, some operations cannot be easily replayed, such as file deletion operations. These types of operations are called non-idempotent operations. If a failover occurs while a file is being deleted, the results are unpredictable for the client. The file server may have completed the deletion but not reported the result to the client, or it may not have completed the deletion at all. If the delete operation is replayed, the client may receive a successful deletion message or an "object not found" error because the file was deleted before it was moved.

[0131] For example, when a service restarts abnormally or the network is interrupted, the server may be executing non-idempotent operations, such as rename, create, delete, hard link, etc. Once the operation has been completed in the file system, it cannot be replied to the client due to restart or network interruption. When the server network is restored, the client will receive an error message from the server when it initiates the operation again, because the file system cannot identify whether the operation needs to be repeated. In this regard, this embodiment optimizes the processing logic of non-idempotent operations to avoid the above-mentioned abnormal situations.

[0132] In some embodiments, the method further comprises:

[0133] Receiving a non-idempotent operation request sent by the client;

[0134] Sending the non-idempotent operation request to the file system;

[0135] If an error message returned by the file system is received, it is determined whether to return an operation success response to the client according to the process startup time of the server.

[0136] Here, non-idempotent operation requests include rename, create, delete, hard link, etc.

[0137] If the server is an SMB server, the process startup time here may refer to the startup time of the smbd process. The smbd process is a server process that provides file sharing and printing services to the client.

[0138] It can be determined whether the process startup time exceeds the threshold. If so, an error is returned; if not, the server returns a successful operation response to the client.

[0139] In some embodiments, the non-idempotent operation request is a create request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0140] If the difference between the process start time and the current time does not exceed the first threshold, and the difference between the creation time of the file corresponding to the creation request and the current time does not exceed the second threshold, a creation success response is returned to the client.

[0141] The creation request here includes the creation of files and directories, as well as the creation of hard links.

[0142] like Figure 5 As shown, Figure 5 The following is a schematic diagram of a processing flow for a non-idempotent operation provided by an embodiment of the present invention. The non-idempotent operation is a create operation, including:

[0143] 1) The SMB client sends a create request to the SMB server.

[0144] 2) The SMB server sends a create request to the file system.

[0145] The SMB client sends a create request to the SMB server, and the SMB server sends the create request to the file system.

[0146] 3) The file system returns EEXIST to the SMB server.

[0147] 4) The SMB server determines whether the process startup time exceeds the threshold, and returns an error if it exceeds the threshold.

[0148] The SMB server determines whether the smbd process startup time exceeds the threshold. If so, an error is returned. If not, the server executes the following steps.

[0149] 5) The SMB server continues to determine whether the creation time difference exceeds the threshold, and returns an error if it exceeds the threshold.

[0150] The SMB server then checks whether the difference between the creation time of the file corresponding to the create request and the current time exceeds the threshold. If so, an error is returned. If not, the create is successful.

[0151] 6) The SMB server sends a Create success response to the SMB client.

[0152] The process of creating a hard link includes:

[0153] 1) The SMB client sends a hardlink request to the SMB server.

[0154] 2) The SMB server sends the hardlink request to the file system.

[0155] 3) The file system returns EEXIST to the SMB server.

[0156] 4) Check whether the SMB server process startup time exceeds the threshold. If it exceeds the threshold, an error is returned.

[0157] The SMB server determines whether the smbd process startup time exceeds the threshold. If so, an error is returned. If not, the server executes the following steps.

[0158] 5) The SMB server continues to determine whether the difference in modification time ctime (change time) exceeds the threshold, and returns an error if it exceeds the threshold.

[0159] ctime is the timestamp of the last modification of the file metadata in the file system. The SMB server then determines whether the difference between the modification time of the file corresponding to the hardlink request and the current time exceeds the threshold. If so, an error is returned. If not, the Create operation succeeds.

[0160] 6) The SMB server sends a hardlink success response to the SMB client.

[0161] In some embodiments, the non-idempotent operation request is a rename request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0162] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the rename request;

[0163] generating a successful access link creation response according to the first setting identifier and sending the response to the client, so that the client sends a rename request according to the first setting identifier;

[0164] determining whether the renaming request sent by the client includes the first setting identifier;

[0165] If the renaming request includes the first setting identifier, a renaming success response is returned to the client.

[0166] For example, reference Figure 6 , Figure 6 FIG2 is a schematic diagram of a processing flow of another non-idempotent operation provided by an embodiment of the present invention. The non-idempotent operation is a rename operation, including:

[0167] 1) The SMB client sends an open / reopen request to the SMB server.

[0168] 2) The SMB server sends the open / reopen request to the file system.

[0169] 3) The file system returns ENOENT to the SMB server.

[0170] 4) Check whether the SMB server process startup time exceeds the threshold. If it exceeds the threshold, an error is returned.

[0171] The SMB server determines whether the smbd process startup time exceeds the threshold. If so, an error is returned. If not, the server executes the following steps.

[0172] 5) Mark volatile_id and construct fake open or fake reopen.

[0173] Among them, volatile_id corresponds to the first setting identifier, which is a non-persistent identifier and is not used for reconstruction and persistence.

[0174] Construct fake open or fake reopen to build a fake access link.

[0175] 6) The SMB server returns an Open / reopen success response to the client.

[0176] 7) The SMB client sends a setinfo / getinfo / close request to the SMB server.

[0177] The setinfo / getinfo / close request corresponds to the rename request, and the setinfo / getinfo / close request carries volatile_id.

[0178] 8) The SMB server identifies the volatile_id in the request.

[0179] 9) Swallow ENOENT and construct a response packet

[0180] 10) The SMB server sends a rename success response to the SMB client.

[0181] In one embodiment, the non-idempotent operation request is a delete request, and determining whether to return an operation success response to the client based on the process startup time of the server includes:

[0182] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the deletion request;

[0183] generating a successful creation response of the access link according to the second setting identifier and sending the response to the client, so that the client sends a deletion request according to the second setting identifier;

[0184] determining whether the deletion request sent by the client includes the second setting identifier;

[0185] If the deletion request includes the second setting identifier, a deletion success response is returned to the client.

[0186] For example, reference Figure 7 , Figure 7 The following is a schematic diagram of a processing flow for another non-idempotent operation provided by an embodiment of the present invention. The non-idempotent operation is a delete operation, including:

[0187] 1) The SMB client sends an open / reopen request to the SMB server.

[0188] 2) The SMB server sends the open / reopen request to the file system.

[0189] 3) The file system returns ENOENT to the SMB server.

[0190] 4) Check whether the SMB server process startup time exceeds the threshold. If it exceeds the threshold, an error is returned.

[0191] The SMB server determines whether the smbd process startup time exceeds the threshold. If so, an error is returned. If not, the server executes the following steps.

[0192] 5) Mark volatile_id and construct fake open or fake reopen.

[0193] Among them, volatile_id corresponds to the second setting identifier, which is a non-persistent identifier and is not used for reconstruction and persistence.

[0194] Construct fake open or fake reopen to build a fake access link.

[0195] 6) The SMB server returns an Open / reopen success response to the client.

[0196] The SMB server sends the open / reopen request to the file system

[0197] 7) The SMB client sends a close request to the SMB server.

[0198] 8) The SMB server identifies the volatile_id in the close request.

[0199] 9) Construct a response packet

[0200] 10) If the delete operation succeeds, the SMB server sends a rename success response to the SMB client.

[0201] This embodiment optimizes the processing logic of non-idempotent OPs on the server side, avoids the problem of business interruption due to errors in node or service failure restart scenarios, and comprehensively improves the ability of business continuity and availability in system upgrades and failure scenarios.

[0202] refer to Figure 8 , Figure 8 A flowchart of a file operation method provided in an embodiment of the present application, which is applied to a client, is shown in FIG. Figure 8 , the method comprising:

[0203] S801, when the client's access link to the target file is disconnected, a reopen request is sent to the server, the reopen request is used to re-establish the access link to the target file, and the reopen request includes a first persistent identifier, the first persistent identifier is used to locate the storage location of the target file and represents that the client has the authority to access the target file; the server is used to query the corresponding second persistent identifier based on the first persistent identifier, if the corresponding second persistent identifier is queried, the access link to the target file is re-established, and a response message is sent to the client; wherein, the second persistent identifier is created in response to the open request sent by the client and stored in a preset area, and the second persistent identifier supports being queried by any server after creation; the first persistent identifier is stored in the client.

[0204] S802, obtaining a response message sent by the server, and the server is used to re-establish an access link to the target file according to the persistent identifier.

[0205] The client method embodiment and the server method embodiment provided in the above embodiment belong to the same concept and will not be described in detail here.

[0206] In some embodiments, before sending the reopen request to the server, the method further includes:

[0207] Sending an open request to the server; the open request is used to obtain access rights to the target file; the server is used to construct a persistent identifier according to the open request, and send the persistent identifier to the client;

[0208] The persistent identifier sent by the server is received and stored, and the persistent identifier stored in the client is a first persistent identifier.

[0209] The persistent identifier stored in the client is the first persistent identifier, and the persistent identifier stored in the preset area is the second persistent identifier. The first persistent identifier and the second persistent identifier may have the same identifier.

[0210] The embodiment of the present application also provides a file operation device, which corresponds to the file operation method of the above-mentioned server side. The various steps in the embodiment of the file operation method of the above-mentioned server side are also fully applicable to the embodiment of this device.

[0211] The file operation device includes:

[0212] a first receiving module, configured to receive a reopening request sent by a client, the reopening request being used to re-establish an access link to a target file, the reopening request including a first persistent identifier, the first persistent identifier being used to locate a storage location of the target file and indicating that the client has permission to access the target file;

[0213] a query module, configured to query a corresponding second persistent identifier based on the first persistent identifier; wherein the second persistent identifier is created in response to an open request sent by the client and stored in a preset area, and after creation, the second persistent identifier supports querying by any server; and the first persistent identifier is stored on the client;

[0214] The reconstruction module is configured to re-establish an access link to the target file if the corresponding second persistent identifier is found, and send a response message to the client.

[0215] In one embodiment, the apparatus further comprises:

[0216] A second receiving module is configured to receive an open request sent by the client; the open request is used to obtain access rights to the target file;

[0217] The first sending module is used to construct a persistent identifier according to the open request and send the persistent identifier to the client; the persistent identifier stored in the client is a first persistent identifier, and the persistent identifier stored in the preset area is a second persistent identifier.

[0218] In one embodiment, the server runs on the second node of a cluster, and the cluster includes at least a first node and a second node. The client accesses the first node through a virtual IP address and accesses the target file. The first node stores the second persistent identifier in a preset area; when the first node fails, the virtual IP address of the client drifts to the second node; when the client initiates a reopening request for the target file, the server is used to execute the steps of receiving the reopening request sent by the client and subsequent steps.

[0219] In one embodiment, the criteria further include:

[0220] A third receiving module is used to receive a non-idempotent operation request sent by the client;

[0221] A second sending module, configured to send the non-idempotent operation request to a file system;

[0222] A determination module is used to determine whether to return an operation success response to the client based on the process startup time of the server if an error message returned by the file system is received.

[0223] In one embodiment, the non-idempotent operation request is a create request, and the determining module is specifically configured to:

[0224] If the difference between the process start time and the current time does not exceed the first threshold, and the difference between the creation time of the file corresponding to the creation request and the current time does not exceed the second threshold, a creation success response is returned to the client.

[0225] In one embodiment, the non-idempotent operation request is a rename request, and the determining module is specifically configured to:

[0226] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the rename request;

[0227] generating a successful access link creation response according to the first setting identifier and sending the response to the client, so that the client sends a rename request according to the first setting identifier;

[0228] determining whether the renaming request sent by the client includes the first setting identifier;

[0229] If the renaming request includes the first setting identifier, a renaming success response is returned to the client.

[0230] In one embodiment, the non-idempotent operation request is a delete request, and the determining module is specifically configured to:

[0231] If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the deletion request;

[0232] generating a successful creation response of the access link according to the second setting identifier and sending the response to the client, so that the client sends a deletion request according to the second setting identifier;

[0233] determining whether the deletion request sent by the client includes the second setting identifier;

[0234] If the deletion request includes the second setting identifier, a deletion success response is returned to the client.

[0235] The embodiment of the present application also provides a file operation device, which corresponds to the file operation method of the client mentioned above, and each step in the embodiment of the file operation method of the client mentioned above is also fully applicable to the embodiment of this device.

[0236] The file operation device includes:

[0237] A third sending module is configured to send a reopen request to the server when the access link to the target file of the client is disconnected, the reopen request is used to re-establish the access link to the target file, and the reopen request includes a first persistent identifier, the first persistent identifier is used to locate the storage location of the target file and indicates that the client has the authority to access the target file; the server is configured to query the corresponding second persistent identifier based on the first persistent identifier, and if the corresponding second persistent identifier is found, re-establish the access link to the target file and send a response message to the client; wherein the second persistent identifier is created in response to the open request sent by the client and stored in a preset area, and the second persistent identifier supports being queried by any server after creation; the first persistent identifier and the corresponding second persistent identifier carry the same identifier, and the first persistent identifier is stored on the client;

[0238] The acquisition module is used to acquire the response message sent by the server, and the server is used to re-establish an access link to the target file according to the persistent identifier.

[0239] In one embodiment, the criteria further include:

[0240] A fourth sending module is configured to send an open request to the server; the open request is used to obtain access rights to the target file; the server is configured to construct a persistent identifier according to the open request and send the persistent identifier to the client;

[0241] The fourth receiving module is configured to receive and store the persistent identifier sent by the server, wherein the persistent identifier stored in the client is the first persistent identifier.

[0242] In actual application, the first receiving module, query module, reconstruction module, third sending module and acquisition module can be implemented by a processor in the electronic device. Of course, the processor needs to run the computer program in the memory to implement its functions.

[0243] It should be noted that the apparatus provided in the above embodiments is merely illustrated by the division of the aforementioned program modules. In actual applications, the aforementioned processing can be distributed among different program modules as needed, i.e., the internal structure of the apparatus can be divided into different program modules to complete all or part of the aforementioned processing. Furthermore, the apparatus and method embodiments provided in the above embodiments are based on the same concept and will not be further elaborated here.

[0244] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiment of the present application, the embodiment of the present application also provides an electronic device. Figure 9 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present application is shown in FIG. Figure 9 As shown, the electronic device includes:

[0245] Communication interface 901, capable of exchanging information with other devices such as network devices;

[0246] The processor 902 is connected to the communication interface 901 to implement information exchange with other devices and is used to execute the methods provided by one or more of the above technical solutions when running a computer program. The computer program is stored in the memory 903.

[0247] Of course, in actual application, the various components in the electronic device are coupled together through the bus system 904. It can be understood that the bus system 904 is used to realize the connection and communication between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, Figure 9 Various buses are labeled as bus system 904.

[0248] The memory 903 in the embodiment of the present application is used to store various types of data to support the operation of the computer device. Examples of such data include: any computer program used to operate on the electronic device.

[0249] It is understood that memory 903 can be volatile memory or non-volatile memory, or can include both volatile and non-volatile memory. 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 disk, or compact disc read-only memory (CD-ROM); magnetic surface memory can be magnetic disk memory or magnetic tape memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example and 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), synchronized dynamic random access memory (SLDRAM), and direct rambus random access memory (DRRAM). The memory described in the embodiments of the present application is intended to include, but is not limited to, these and any other suitable types of memory.

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

[0251] Optionally, when the processor 902 executes the program, it implements the corresponding processes implemented by the computer device in each method of the embodiment of the present application, which will not be described here for the sake of brevity.

[0252] In an exemplary embodiment, the present application also provides a storage medium, namely, a computer storage medium, specifically a computer-readable storage medium, including, for example, a first memory storing a computer program. The computer program can be executed by a processor of a computer device to perform the steps of the aforementioned method. The computer-readable storage medium can be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface mount storage, optical disk, or CD-ROM.

[0253] In the several embodiments provided in this application, it should be understood that the disclosed devices, computer equipment and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple units or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0254] The units described above as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units; some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0255] In addition, all functional units in the embodiments of the present application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the above-mentioned integrated units can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0256] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, ROM, RAM, disks or optical disks, etc. Various media that can store program codes.

[0257] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application can be essentially or in other words, the part that contributes to the relevant technology can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROM, RAM, magnetic disks or optical disks.

[0258] In an exemplary embodiment, the present application also provides a computer program product, including a computer program, which can be executed by the processor 902 of the electronic device to complete the steps described in the file operation method in the embodiment of the present application.

[0259] It should be noted that: "first", "second", etc. are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

[0260] In addition, the technical solutions described in the embodiments of the present application can be arbitrarily combined without conflict.

[0261] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A file operation method, characterized in that: The method is applied to the server, and includes: receiving a reopen request sent by a client, the reopen request being used to re-establish an access link to a target file, the reopen request including a first persistent identifier being used to locate a storage location of the target file and indicating that the client has permission to access the target file; Querying a corresponding second persistent identifier based on the first persistent identifier; wherein the second persistent identifier is created in response to an open request sent by the client and stored in a preset area, and the second persistent identifier supports querying by any server after creation; the first persistent identifier is stored on the client; If the corresponding second persistent identifier is found, an access link to the target file is re-established, and a response message is sent to the client.

2. The method according to claim 1, characterized in that Before receiving the reopening request sent by the client, the method further includes: Receive an open request sent by the client; the open request is used to obtain access rights to the target file; A persistent identifier is constructed according to the open request, and the persistent identifier is sent to the client; the persistent identifier stored in the client is a first persistent identifier, and the persistent identifier stored in the preset area is a second persistent identifier.

3. The method according to claim 1, characterized in that The server runs on a second node of a cluster, the cluster includes at least a first node and a second node, the client accesses the first node through a virtual IP address and accesses the target file, and the first node stores the second persistent identifier in a preset area; When the first node fails, the virtual IP address of the client drifts to the second node; When the client initiates a reopening request for the target file, the server is configured to execute the steps of receiving the reopening request sent by the client and subsequent steps.

4. The method according to claim 1, characterized in that The method further comprises: Receiving a non-idempotent operation request sent by the client; Sending the non-idempotent operation request to the file system; If an error message returned by the file system is received, it is determined whether to return an operation success response to the client according to the process startup time of the server.

5. The method according to claim 4, characterized in that: The non-idempotent operation request is a create request, and determining whether to return an operation success response to the client based on the process startup time of the server includes: If the difference between the process start time and the current time does not exceed the first threshold, and the difference between the creation time of the file corresponding to the creation request and the current time does not exceed the second threshold, a creation success response is returned to the client.

6. The method according to claim 4, characterized in that: The non-idempotent operation request is a rename request, and determining whether to return an operation success response to the client based on the process startup time of the server includes: If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the rename request; generating a successful access link creation response according to the first setting identifier and sending the response to the client, so that the client sends a rename request according to the first setting identifier; determining whether the renaming request sent by the client includes the first setting identifier; If the renaming request includes the first setting identifier, a renaming success response is returned to the client.

7. The method according to claim 4, characterized in that: The non-idempotent operation request is a delete request, and determining whether to return an operation success response to the client based on the process startup time of the server includes: If the difference between the process start time and the current time does not exceed a first threshold, constructing a pseudo access link for the file corresponding to the deletion request; generating a successful creation response of the access link according to the second setting identifier and sending the response to the client, so that the client sends a deletion request according to the second setting identifier; determining whether the deletion request sent by the client includes the second setting identifier; If the deletion request includes the second setting identifier, a deletion success response is returned to the client.

8. A file operation method, applied to a client, characterized in that: The method comprises: When the access link to the target file of the client is disconnected, a reopen request is sent to the server, wherein the reopen request is used to re-establish the access link to the target file, and the reopen request includes a first persistent identifier, wherein the first persistent identifier is used to locate the storage location of the target file and indicates that the client has the authority to access the target file; the server is used to query the corresponding second persistent identifier based on the first persistent identifier, and if the corresponding second persistent identifier is queried, the access link to the target file is re-established, and a response message is sent to the client; wherein the second persistent identifier is created in response to the open request sent by the client and stored in a preset area, and the second persistent identifier supports being queried by any server after creation; the first persistent identifier is stored on the client; A response message sent by the server is obtained, and the server is used to re-establish an access link to the target file according to the persistent identifier.

9. The method according to claim 8, characterized in that Before sending the reopen request to the server, the method further includes: Sending an open request to the server; the open request is used to obtain access rights to the target file; the server is used to construct a persistent identifier according to the open request, and send the persistent identifier to the client; The persistent identifier sent by the server is received and stored, and the persistent identifier stored in the client is a first persistent identifier.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 8 to 9.

11. An electronic device, characterized in that: include: A processor and a memory for storing a computer program capable of being executed on the processor, wherein: The processor is configured to execute the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 8 to 9 when running a computer program.

12. A computer storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 or the steps of the method according to any one of claims 8 to 9 are implemented.