WO2022077777A1

WO2022077777A1 - Locking reapplication method, lock management method, and server

Info

Publication number: WO2022077777A1
Application number: PCT/CN2020/141986
Authority: WO
Inventors: 张明谦; 珮瓦雷西; 库玛阿吉特
Original assignee: 华为技术有限公司
Priority date: 2020-10-16
Filing date: 2020-12-31
Publication date: 2022-04-21
Also published as: CN114710976A; CN114710976B

Abstract

A locking reapplication method, a lock management method, and a server, for use in reducing abnormal locking reapplications of a client. The method comprises, after receiving a locking reapplication request of the client, the server needs to detect whether a locking identifier is present on extension information of a target object requested by the locking reapplication request, and the target object can be locked only when the locking identifier is present.

Description

A lock reiteration method, lock management method and server

This application is required to be submitted to the Indian Patent Office on October 16, 2020, the application number is IN202031045050, and the name of the invention is "LOCK MANAGEMENT METHOD, LOCK MANAGEMENT APPARATUS, AND COMPUTER-READABLE STORAGE MEDIUM" (lock management method, lock management device and computer can Priority of the Indian Patent Application for Reading Storage Medium), the entire contents of which are incorporated herein by reference.

technical field

The present application relates to the field of computer technology, and in particular, to a lock reassertion method, a lock management method, and a server.

Background technique

Network file system (NFS) version 3 (NFS version 3, NFSv3) is a stateless network file sharing protocol, which can provide file read and write services for multiple NFS clients at the same time. In practical applications, in order to avoid data inconsistency caused by multiple NFS clients writing the same file at the same time, it is necessary to perform lock protection on the files in the server when the NFS client reads and writes. When the server fails and restarts, it will read the client information from the persistence layer and send a message to the client to inform the client to re-apply for the lock that has been added when the capacity is expanded or contracted.

During the reiteration process, the server will set a silent period. During the silent period, only the client is allowed to reiterate the lock, and new lock requests are not allowed. When the silent period ends, the lock request from any client can be received normally. But in the process of lock reiteration, the client may reiterate the lock that was not added before the failure.

SUMMARY OF THE INVENTION

The present application provides a lock reiteration method, a lock management method and a server, which are used to reduce abnormal lock reiteration of clients.

A first aspect of the present application provides a lock reassertion method, which includes: a server receiving a lock reassertion request from a client; Locked file; the server locks the target object from the lock identifier in the extension information corresponding to the target object, and the lock identifier indicates that the target object was locked before the server failure. Specifically, the target object may be a file, directory, etc. in the file system, or may be a block or a logical unit number (LUN) in a block storage system, or an object in an object storage system.

In the above-mentioned first aspect, when the server determines that there is a move-in event, it mutes each object area in the server, and obtains the locked client information in the feature log, so as to release the silent state of the object area that does not need to be muted. In one implementation, in the file system, the object area is the file area or the directory area; in the block storage system, the object area is the metadata area of the block or LUN; in the object storage system, it is the metadata area of the object. After the server restarts, the data in the cache is lost, and the locks on each object are also cleared. The client needs to be reminded to apply for the lock again. The corresponding server receives the lock reiteration request from the client, and obtains the lock reiteration request from the client. Locked target object. The objects in the server of the present application all have corresponding extension information, the data in the extension information is non-volatile data, the server can determine whether there is a lock mark in the extension information of the target object, if there is the lock mark, The server can lock the target file, and if there is no lock identification, the server can reject the lock reiteration request. This application only locks the object with the lock identification, and rejects the client's lock reiteration request for the object without the lock identification, so as to reduce the abnormal lock reiteration of the client.

In a possible implementation, the extended information also includes the number of locks, and in the above steps, before the server locks the target object according to the lock reiteration request, the method further includes: when the number of lock reiteration requests corresponding to the target object exceeds the number of locks. , the server marks the end of the target object lock reassurance.

In the above possible implementation manner, the extended information of each object in the server of the present application further includes the number of locks, and the number of locks may indicate the number of locks added before the server restarts. For the client's lock reiteration request, the server also needs to determine the target object corresponding to the lock reiteration request, whether the number of reiterated locks after the server restarts exceeds the number of locks, and if so, the client's lock reiteration request is directly rejected. If the number of locks is exceeded, the corresponding locking operation can be performed according to the client's lock reiteration request. In this way, abnormal lock reiteration by clients can be further reduced.

In a possible implementation manner, after the server locks the target object according to the lock reiteration request in the above steps, the method further includes: when the successful lock reiteration request corresponds to the client, and the lock of the object area where the target object is located. When the relationship is not stored in the feature log, the server stores the locking relationship between the client and the object area where the target object is located in the feature log.

In the above possible implementation manner, the server can detect whether the target successful client and the locking relationship of the object area are stored in the feature log, if so, do not perform other operations, if not, the server can store the Locking relationship for double protection against locking.

In a possible implementation, before the server receives the lock reiteration request from the client in the above steps, the method further includes: the server receives the lock request from the client; the server determines the target object according to the lock request; the server extends the corresponding extension of the target object. The lock identification is stored in the information.

In the above possible implementation, before the server restarts, the server can determine the target object according to the object identifier in the client's locking request, and if the target object can be locked, the locking identifier is stored in the extension information of the target object, So that after the server restarts, it can be determined through the lock identifier that the target object has been locked before the server restarts, so as to improve the feasibility of the solution.

In a possible implementation manner, the extended information further includes the number of locks, and after the server stores the lock identifier in the extended information corresponding to the target object in the above steps, the method further includes: the server correspondingly increases the number of locks.

In the above possible implementation manner, when multiple clients request locks on the target object, the server correspondingly increases the number of locks according to the number of requests that can be successfully locked, so that the feasibility of the solution can be improved.

In a possible implementation, after the server stores the lock identification in the extension information corresponding to the target object in the above steps, the method further includes: the server receives an unlock request from one or more clients; the server determines the target object according to the unlock request; When the number of unlock requests of the target object is the same as the number of lock requests, the server clears the lock flag.

In the above possible implementation manner, after the server stores the lock identifier in the extension information corresponding to the target object, if the locked client does not need to be locked, it can send an unlock request to the server. The server can detect the number of unlock requests and the number of lock requests of the target object in the cache. If the number of unlock requests is less than the number of lock requests, the lock identifier in the extended information is retained. If the number of unlock requests is equal to the number of lock requests, Then the server deletes the lock identification in the extended information, which can improve the reliability of lock reiteration.

In a possible implementation, after the server correspondingly increases the number of locks in the above steps, the method further includes: the server receives an unlock request from the client; the server determines the target object according to the unlock request; the server correspondingly reduces the number of locks; when the number of locks is 0 , the server clears the lock flag.

In the above possible implementation, when the extended information includes the number of locks, the server also needs to correspondingly reduce the number of locks according to the unlock request. If the number of locks is 0, it means that there is no lock on the target object, then clear the lock identification to Improve the reliability of lock reiteration.

In a possible implementation, after the server determines the target object according to the locking request in the above steps, the method further includes: when the locking relationship between the client and the target area where the target object is located is not stored in the feature log, the server stores the client and the target object. The locking relationship of the object area where the target object is located is stored in the feature log.

In the above possible implementation manner, the locking relationship between the successfully locked client and the object area where the target object is located is stored in the feature log, so that the lock can be reiterated later.

A second aspect of the present application provides a lock management method. The method includes: the server obtains a lock identifier of a target object; and the server records the lock identifier in extended information of the target object.

In the above-mentioned second aspect, the locking request that the client applies for locking to the target object carries the locking identification, and the server obtains the locking identification in the locking request, and stores the locking identification in the extension information of the target object. , so that after the server restarts, it can be determined through the lock identifier that the target object has been locked before the server restarts.

In a possible implementation manner, the server obtains the lock quantity of the target object; the server records the lock quantity in the extended information of the target object.

In the above possible implementation manner, when there is no unlock request, the server can use the number of lock requests stored by the target object in the cache as the number of locks of the target object, and then record it in the extension information of the target object, so that after the server restarts The number of clients locked on the target object can be determined by the number of locks.

In a possible implementation manner, when releasing the lock of the target object, the server deletes the lock identification from the extended information of the target object.

In the above possible implementation manner, when the client completes the operation and does not need to lock, it can send an unlock request to the server, and accordingly, the server can release the lock on the target object and delete the lock identifier in the extended information. Optionally, when the lock on the target object is a write lock or there is only one read lock, the server deletes the lock ID upon receiving the unlock request. When there are multiple read locks on the target object, if there is only one read lock in the extended information If there are multiple lock identifiers in the extended information, the server can delete the extended information after receiving the unlock request. The lock identifier corresponding to the unlock request.

In a possible implementation manner, when restoring the lock of the target object, the server acquires the lock identifier from the extended information stored in the hard disk.

In the above possible implementation manner, after the server is restarted, if a lock reiteration request for the target object is received from the client, the lock identification can be obtained from the extended information stored in the hard disk. The lock reiteration requests that the target object be locked accordingly.

In a possible implementation, the method is applied to a distributed file storage system.

A third aspect of the present application provides a server, the server comprising: a receiving unit for receiving a lock reiteration request from a client; a determining unit for determining a target object corresponding to the client according to the lock reiteration request, where the target object is the client The object to be locked after the server restarts; the re-locking unit is used to lock the target object according to the lock reiteration request when the extension information corresponding to the target object determines that there is a lock mark, and the lock mark indicates the target object Locked before server failure.

The server is configured to execute the method of the foregoing first aspect or any implementation manner of the first aspect.

A fourth aspect of the present application provides a server, the server comprising: an acquiring unit, configured to acquire a locking identifier of a target object; and a recording unit, configured to record the locking identifier in extended information of the target object.

The server is configured to execute the method of the foregoing second aspect or any implementation manner of the second aspect.

A fifth aspect of the present application provides a computer device, including: a processor, a memory, and a communication interface, where the processor is configured to execute instructions stored in the memory, so that the computer device executes the first aspect or any one of the first aspects The method provided by the optional manner, the communication interface is used for receiving or sending an indication. For the specific details of the computer device provided in the fifth aspect, reference may be made to the first aspect or any optional manner of the first aspect, which will not be repeated here.

A sixth aspect of the present application provides a computer device, including: a processor, a memory, and a communication interface, where the processor is configured to execute instructions stored in the memory, so that the computer device executes the second aspect or any one of the second aspects. The method provided by the optional manner, the communication interface is used for receiving or sending an indication. For the specific details of the computer device provided by the sixth aspect, reference may be made to the second aspect or any optional manner of the second aspect, which will not be repeated here.

A seventh aspect of the present application provides a computer-readable storage medium, where a program is stored in the computer-readable storage medium, and when the computer executes the program, the computer executes the first aspect or any optional manner of the first aspect. method.

An eighth aspect of the present application provides a computer-readable storage medium, where a program is stored in the computer-readable storage medium. When the computer executes the program, the computer executes the second aspect or any optional manner of the second aspect. method.

A ninth aspect of the present application provides a computer program product. When the computer program product is executed on a computer, the computer executes the method provided in the foregoing first aspect or any optional manner of the first aspect.

A tenth aspect of the present application provides a computer program product. When the computer program product is executed on a computer, the computer executes the method provided in the second aspect or any optional manner of the second aspect.

Description of drawings

1 is a block diagram of a server-client system provided by an embodiment of the present application;

2 is a server-client lock recovery scenario provided by an embodiment of the present application;

3 is a schematic diagram of an embodiment of a lock reassertion method provided by an embodiment of the present application;

4 is a schematic diagram of another embodiment of a lock reassertion method provided by an embodiment of the present application;

FIG. 5 is a schematic diagram of an embodiment of a locking method provided by an embodiment of the present application;

FIG. 6 is a schematic diagram of another embodiment of the locking method provided by the embodiment of the present application;

FIG. 7 is a schematic structural diagram of a server provided by an embodiment of the present application;

FIG. 8 is a schematic structural diagram of a server according to an embodiment of the present application;

FIG. 9 is another schematic structural diagram of a server provided by an embodiment of the present application;

FIG. 10 is another schematic structural diagram of a server provided by an embodiment of the present application;

FIG. 11 is a schematic structural diagram of a computer device according to an embodiment of the present application.

Detailed ways

Embodiments of the present application provide a lock reiteration method, a lock management method, and a server, which are used to reduce abnormal lock reiteration by clients.

The embodiments of the present application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Those of ordinary skill in the art know that with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

The terms "first", "second" and the like in the description and claims of the present application and the above drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It is to be understood that data so used may be interchanged under appropriate circumstances so that the embodiments described herein can be practiced in sequences other than those illustrated or described herein. Furthermore, the terms "comprising" and "having" and any variations thereof, are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those expressly listed Rather, those steps or units may include other steps or units not expressly listed or inherent to these processes, methods, products or devices.

The following describes some terms used in the introduction by taking a file system environment as an example in this embodiment of the present application:

Network file system (NFS): A network file system allows a server to share files and directories with clients over a network. This allows clients to access remote files and directories in the same way that clients would access local files and directories. The NFS structure can provide many advantages. For example, clients use less storage space because data can be stored on a single server and still be accessible by clients. Thus, data that would otherwise be replicated on each client can be stored in a single location and accessed by multiple clients on the network.

File System: A storage device of a data storage system may implement one or more file systems to organize data stored on it. As used herein, a "file system" may refer to the structure or organization of files or directories, and a "file" may refer to a set of data. Each file can be associated with a filename that allows the file to be uniquely identified and located. Depending on the specific requirements and desired application, a number of different file systems can be used.

The PortMapper protocol uses fixed ports to manage ports for various NFS services.

The network lock manager (NLM) protocol registers the listening port with the PortMapper module when the NFS service starts. Clients can lock and unlock files through this protocol, support blocking locks and non-blocking locks, and support transmission control protocol (TCP) and user datagram protocol (UDP) connections.

The network status monitoring (NSM) protocol registers the listening port with the PortMapper module when the NFS service starts. The client and the server inform each other of their own status through this protocol, which is used for NLM cleanup and recovery in the scenario of client failure and server failure. Supports TCP and UDP connections.

FIG. 1 is a block diagram of a server-client system provided by an embodiment of the present application. The system 100 may include a client 101 in communication with an NFS server 103 (ie, a server, exemplified here as an NFS server) over a network 102 . NFS server 103 may access storage device 104 including file system 1041 . Although shown and described as a separate component, it is contemplated that in some embodiments storage device 104 may be included in NFS server 103 .

In practice, a client 101 may issue a request to access or perform an operation on a data object on the NFS server 103 through the network 102 . A request can be encapsulated into a standardized message format defined by the NFS protocol. As used herein, a "data object" may refer to any of data, files, applications, subdirectories, directories, file systems, combinations thereof, and the like. Once the request is received, the NFS server 103 may allow the client 101 to access the data object from the file system 1041 of the storage device 104. For example, NFS server 103 may send data objects from file system 1041 to requesting client 101 . In another example, NFS server 103 may allow client 101 to mount a remote directory of file system 1041 on a local directory at client 101 .

NFS server 103 may also allow client 101 to perform one or more operations on data objects. For example, client 101 may open data objects, read data objects, write data objects, close data objects, create data objects, lock data objects, delete data objects, delegate data objects, combinations thereof, and the like. NFS server 103 may track some or all of these operations in the form of state. NFS server 103 may track one or more of these states associated with one or more data objects. In some embodiments, client 101 may additionally track these states.

In some embodiments, NFS server 103 may first determine whether client 101 has appropriate permissions to access or perform certain operations on data objects in file system 1041 of storage device 104 . As used herein, "permission" defines access control options that can be applied to one or more users. For example, NFS server 103 may examine metadata associated with a data object to ensure that the requesting user (eg, a user ID associated with client 101) is associated with a "read" operation of the data object. NFS server 103 may deny client 101 access to the data object if the requesting user is not associated with the operation.

Traditionally, state information for data objects is stored in volatile memory for fast access and update compared to non-volatile memory. However, as discussed above, volatile memory is erased when the storage system is powered down. Thus, in the event of an NFS server crash or failure, conventional NFS protocols often rely on clients to resend all previous state information and/or related data to the server during a smooth recovery period.

Furthermore, even in the absence of crashes or failures, the state information of data objects on one storage device can be difficult to copy from volatile memory to another storage device. For example, it may be desirable to mirror the source storage device with the destination storage device to seamlessly replace the source storage device or to back up data at a given point in time. In this case, typically only the data objects themselves will be migrated, and it may be desirable to migrate the state of the data objects, however, during migration, data (eg, state information) stored in volatile memory will typically not be migrated to destination storage device.

Accordingly, according to some embodiments of the present application, systems and methods are provided for capturing and storing state information corresponding to various states of NFS. In various aspects, the disclosed systems and methods can automatically collect and synchronously write state changes made to NFS to non-volatile storage. In the event of a failure or crash of the NFS system (eg, failure of the NFS server), state information corresponding to the NFS system can be automatically imported from the non-volatile storage device, so that the NFS service can be restored immediately and transparently. In the case of migration, the state information can be transferred from the non-volatile storage to the destination storage device, which can then import the state information into memory to mirror the source storage device.

FIG. 2 is a server-client lock recovery scenario provided by an embodiment of the present application. As shown in FIG. 2 , the client 101 includes an NSM1 module and an NLM1 module, and the server 103 includes an NSM2 module, an NLM2 module, and a lock service module.

After the NLM1 module is successfully locked, it will notify the NSM1 module to save the locked server information, and the NSM1 module is responsible for persisting this information. When the client restarts due to failure, NSM1 reads the server information from the persistence layer, and sends a notification message to the NSM2 module of the server 103, instructing the server 103 to clear all locking requests sent from the client 101.

After the NLM2 module receives the lock request, it will submit the request to the lock service module (LockServer) to process the lock business logic (locking, unlocking, lock conflict checking, etc.), and persist the client information. When the server 103 restarts due to a failure, it will read the client information from the persistence layer when expanding or shrinking the capacity, and send a notification message to the client 101, informing the client 101 to re-apply for the lock that has been added. During the reiteration process, the server 103 will set a silent period. During the silent period, only the client 101 is allowed to reiterate the lock, and a new client's lock request is not allowed. When the silent period ends, the lock request from any client can be received normally.

The server does not save which files have been locked. During the process of client lock reiteration, it is impossible to prevent the client from reiterating the locks that have not been added before the failure. To solve the above problem, the embodiment of the present application provides a lock reiteration method. The method includes: the server receives a lock reiteration request from the client; the server determines a target file corresponding to the client according to the lock reiteration request, and the target file is a file that the client wants to lock after the server restarts; The target file is locked with the lock mark of the lock mark, and the lock mark indicates that the target file was locked before the server failure. In this way, the client can only perform lock reiteration on the files that were locked before the failure, reducing the abnormal lock reiteration of the client.

Hereinafter, based on the above-mentioned system framework, the lock reassertion method in the embodiment of the present application will be described below.

The server in this embodiment may be a network attached storage (NAS) server, which is a dedicated data storage server. It is data-centric, completely separates storage devices from servers, and centrally manages data, thereby freeing bandwidth, improving performance, reducing total cost of ownership, and protecting investments. Its cost is much lower than using server storage, and its efficiency is much higher. NAS is defined as a special dedicated data storage server, including storage devices (such as disk arrays, compact disc (CD)/digital versatile disc (DVD) drives, tape drives or removable storage media ) and embedded system software to provide cross-platform file sharing. NAS usually has its own node on a local area network (LAN) without the intervention of the application server, allowing users to access data on the network. In this configuration, the NAS centrally manages and processes all data on the network. Offload the load from the application or enterprise server, effectively reduce the total cost of ownership and protect user investment.

In the lock reiteration method of the embodiment of the present application, the server configures the file with extended information that can store non-volatile data. When locking, the lock reiteration request is processed according to the lock ID of the extended information.

1. When the client reiterates the lock, the server processes the lock reiteration request according to the lock identifier of the extended information.

In this embodiment of the present application, after the server is restarted, a period of silence is set for the client to reiterate the lock. The server may be configured to end the silence in advance, or may not be configured to end the silence in advance.

1.1. The server is not configured to end the silence in advance.

Please refer to an embodiment of the lock reassertion method shown in FIG. 3 including:

301. When the server determines the move-in event, it sets each file area to be silent, and reads the client information from the feature log.

This embodiment is applied to the distributed file storage system of the network file system version 3 (NFS version 3, NFSv3). The migration event is that when one node in the server fails, another node takes over the physical storage of the failed node. resource. The server can silence each file area to prevent other clients from applying for locking and affecting the locking service of the client before the failure. The server can read the client information from the feature log of the physical storage resource, and the client information can be the locking relationship between the client and the file area where the file in the server is located, indicating that the client is in a certain file area in the file area. The file is locked.

302. Unmute the file area that does not need to be silenced.

The server can determine which file areas and which clients have been locked before the server fails according to the locking relationship between the client and the file area in the server in the client information. The server can de-quiesce the file area that has not been locked before the failure, so that the lock application of other clients can be executed normally.

303. The server sends a lock reiteration message to the client according to the client information.

The failure of the server can be a crash or other failure. When the server is restarted, the data in the cache is lost, and the locks on each file are also cleared. The client needs to restore all previous state information and/or during the recovery period (ie the silent time). Or the relevant data is resent to the server, and the server can send a lock reiteration message to the client that locked the file before the server failure, informing the client that the file lock needs to be re-applied.

304. The client sends a lock reiteration request to the server according to the lock reiteration message.

After receiving the lock reiteration message, the client can send a lock reiteration request to the server based on the file lock recorded in the cache, and the lock reiteration request may include the file identifier of the target file to be re-locked. Among them, the lock reiteration request also includes the lock status reply flag (reclaim). The client needs to restore the file lock previously applied for. At this time, the reclaim in the lock reiteration request message is set to 1, and the value is 0 in other cases.

305. The server determines the target file corresponding to the client according to the lock reiteration request.

After the server receives the lock reiteration request, it can determine the target file to be applied for by the client from the file system according to the above-mentioned file identifier.

306. Lock the target file from the lock identifier in the extension information corresponding to the target file.

Each file in the file system is provided with extended information, which is used to store non-volatile data. When the server determines the target file and needs to restore the lock of the target file, the server obtains the lock identifier from the extended information stored in the hard disk, for example, the data in the extended information corresponding to the target file can be read into the cache , if there is no lock identification in the extended information, the server can reject the client's lock reiteration request. If the lock identification exists in the extended information, the server can read and lock or write the target file accordingly according to the lock reiteration request. lock, wherein the lock identifier is used to indicate that the target file has been locked before the server fails. Optionally, for the target file, if there are lock reiterations of other clients, the server can directly perform corresponding operations according to the data in the cache without reading the extended information.

307. When the lock reiteration request corresponding to the successful lock reiteration request is not stored in the feature log, the server stores the lock relationship between the client and the file region where the target file is located in the feature log.

In this embodiment, the server can determine whether the locking relationship between the client and the file area where the target file is located has been written after a lock identification exists in the extended information and a corresponding locking operation is performed on the target file according to the lock reiteration request. If it has been written, it does not need to be written repeatedly. If it has not been written, the lock relationship between the client and the file area where the target file is located can be stored in the feature log to ensure data reliability.

In the embodiment of the present application, the server confirms the lock identification from the extended information of the target file reiterated by the client, and rejects the lock reiteration request of the client for the file without the lock identification, because the reiterated file in the lock reiteration request of the client is not necessarily It is a file to which the client was locked before the server failure. In this embodiment, the client's lock reiteration request can be rejected for a file that has not been locked before the server failure, which can reduce abnormal lock reiteration by the client.

1.2. The server configuration ends the silence in advance.

Please refer to another embodiment of the lock reassertion method shown in FIG. 4 including:

401. When the server determines the move-in event, it sets each file area to be silent, and reads client information from the feature log.

402. Unmute the file area that does not need to be silenced.

403. The server sends a lock reiteration message to the client according to the client information.

404. The client sends a lock reiteration request to the server according to the lock reiteration message.

405. The server determines the target file corresponding to the client according to the lock reiteration request.

Steps 401 to 405 in this embodiment may refer to the relevant descriptions of steps 301 to 305 in the lock reassertion method shown in FIG. 3 , and details are not repeated here.

406. When it is determined that the extension information corresponding to the target file has a lock identifier, if the number of lock reiteration requests corresponding to the target file reaches the number of locks in the extension information, the server marks the end of lock reiteration of the target file.

In this embodiment, the scope of influence of the silence at the file area level is relatively large, and the silence cannot be released in advance during silence, and the influence time is relatively long, generally 60s. During the silent reiteration, since the NAS server does not save the file information locked by the client, it cannot prevent the client from using the reiterated rules to apply for a lock that does not belong to itself during the reiteration. Each file in the file system is provided with extended information, which is used to store non-volatile data. When the server determines the target file, it can read the data in the extension information corresponding to the target file into the cache. If there is no lock identification in the extension information, the server can reject the client's lock reiteration request. The lock identifier, the server can also obtain the number of locks in the extended information, and the number of locks is used to indicate the number of locks added to the target file before the server fails. Exemplarily, the target file can be set to multiple reads before the server fails. To get the lock, the server can judge whether the number of multiple lock reiteration requests of the target file exceeds the number of locks after restarting. Within the range, the server can reject the current lock reiteration request and mark the end of the lock reiteration process of the target file, that is, the silence of the target file can be ended in advance. The lock identification is used to indicate that the target file has been locked before the server fails.

407. If the number of lock reiteration requests corresponding to the target file does not exceed the number of locks in the extended information, the server locks the target file according to the lock reiteration request.

In this embodiment, when the number of multiple lock reiteration requests of the target file does not exceed the number of locks, it means that the current lock reiteration request is still within the range of the locks added to the target file before the server failure, and the server can directly The target file is read-locked or write-locked accordingly according to the lock reiteration request.

408. When the lock reiteration request corresponding to the successful lock reiteration request is not stored in the feature log, the server stores the lock relationship between the client and the file region where the target file is located in the feature log.

For step 408 in this embodiment, reference may be made to the relevant description of step 307 in the lock reassertion method shown in FIG. 3 , and details are not repeated here.

Further, when the number of lock reiteration requests corresponding to the target file reaches the number of locks in the extended information, the server can mark the end of the lock reiteration of the target file, that is, end the silence of the target file in advance, and other clients can proceed normally. Applying for a lock can also prevent the client from applying for a lock that does not belong to itself through the lock reiteration during the reiteration period, ending the silence in advance, and reducing the time affected by the failure.

2. The server sets the lock flag to the extended information of the file when the client applies for lock.

2.1. The server is not configured to end the silence in advance.

Please refer to an embodiment of the locking method shown in FIG. 5 including:

501. The client sends a lock request to the server.

In this embodiment, the client can check whether there is a file lock on the server when accessing a file in the server, so there will be no conflict when all clients access the same file. When the file to be accessed by the client in the server has no file lock or only has a read lock, the client can send a lock request for the file to the server. Exemplarily, when there is no file lock on the file, the client can request a read lock or a write lock, and when there is only a read lock on the file, the client can only apply for a read lock.

502. The server determines the target file according to the lock request.

The lock request sent by the client includes the identifier of the file to be accessed by the client, and the server can determine the target file to be locked by the client according to the identifier.

503. When the locking relationship between the client and the file region where the target file is located is not stored in the feature log, the server stores the locking relationship between the client and the file region where the target file is located in the feature log.

The server can judge whether the locking relationship between the client and the file area where the target file is located has been written into the feature log (Feature log). and the locking relationship of the file area where the target file is located is stored in the feature log as the basis for the client to reiterate the lock.

504. The server stores the lock identifier in the extension information corresponding to the target file.

Each file in the file system is provided with extended information, which is used to store non-volatile data. In this embodiment, after receiving the lock request from the client, the server may determine the target file, obtain the lock identifier of the target file, and store the lock identifier in the extension information of the target file, and the lock identifier indicates the lock identifier of the target file. The target file is currently locked, which can be used to indicate that the target file was locked before the server failed.

When the target file has multiple lock requests that can be implemented, the extended information only records the lock identification once, which can save memory resources. Exemplarily, the target file has only one write lock, and can have one or more read locks. When the target file has multiple read locks, the extended information may record the lock identification only once.

505. The client sends an unlock request to the server.

After the client accesses the file in the server, it needs to release the locked state of the file, and can send an unlock request for the file to the server, wherein the number of clients sending the unlock request to the server can be one or more.

506. The server determines the target file according to the unlock request.

In this embodiment, the server determines the target file to be unlocked by the client according to the file identifier included in the unlock request.

507. When the number of unlock requests of the target file is the same as the number of lock requests, the server clears the lock identifier.

In this embodiment, the number of lock requests and unlock requests of all clients to the target file are stored in the cache. That is, the lock to be released by the current unlock request is the last lock of the target file, and the server can know the lock identifier in the extension information corresponding to the target file. Remove the lock sign from .

In the embodiment of the present application, the server configures extended information for the file, and whether the lock identifier in the extended information exists can indicate whether the file has been locked when the server is restarted. For files that have not been locked before the server fails, the server can Rejecting the client's lock reiteration request can reduce the client's abnormal lock reiteration.

2.2. The server configuration ends the silence in advance.

Please refer to another embodiment of the locking method shown in FIG. 6 including:

601. The client sends a lock request to the server.

602. The server determines the target file according to the lock request.

603. When the locking relationship between the client and the file area where the target file is located is not stored in the feature log, the server stores the locking relationship between the client and the file region where the target file is located in the feature log.

604. The server stores the lock identifier in the extension information corresponding to the target file.

Steps 601 to 604 in this embodiment may refer to the relevant descriptions of steps 501 to 504 in the locking method shown in FIG. 5 , and details are not repeated here.

605. The server correspondingly increases the number of locks.

The extended information also includes the number of locks of the target file. When the server receives a lock request that can be implemented, it will perform the corresponding lock operation on the target file, and then the number of locks of the target file can be obtained, and correspondingly. The number of locks is recorded in the extended information, for example, an increase operation can be performed on the number of locks in the extended information. Exemplarily, after the server locks the target file, the number of locks is incremented by 1.

606. The client sends an unlock request to the server.

607. The server determines the target file according to the unlock request.

Steps 606 to 607 in this embodiment may refer to the relevant descriptions of steps 505 to 506 in the locking method shown in FIG. 5 , and details are not repeated here.

608. The server correspondingly reduces the number of locks.

Correspondingly, after receiving the unlock request, the server reduces the number of locks in the extension information corresponding to the target file. Exemplarily, when an unlock request is received, the number of locks is decremented by 1.

609. When the number of locks is 0, the server clears the lock identification.

When the number of unlock requests of the target file is the same as the number of lock requests, the number of locks is correspondingly reduced to 0, and the server can clear the lock flag in the extension information of the target file, that is, when releasing the lock of the target file, the server will remove the lock from the target file from the target file. Delete the lock mark from the extended information of the file.

In the embodiment of the present application, the server configures extended information for the file, and whether the lock identifier in the extended information exists can indicate whether the file has been locked when the server is restarted, so that there is no locked file before the server fails, the server The client's lock reiteration request can be rejected, which can reduce the client's abnormal lock reiteration.

Further, the extended information also includes the number of locks, and the number of locks can provide the server with the number of locks added to the file after the server restarts, so that the server can end the file silence in advance according to the number of locks after restarting.

Exemplarily, the lock reassertion method in this embodiment of the present application may be implemented through a system architecture. Please refer to FIG. 7 , which is a schematic diagram of the architecture of the server in this embodiment of the present application. The server 103 includes an NFS module 1031, a lock server module 1032, Feature log module 1033 and file system 1034. The lock server module 1032 further includes: a recovery (recover) module 10321, a lock manager (lock manager) module 10322 and a persistent (persistent) module 10323.

During the locking process:

After receiving the lock request from the client, the NFS module 1031 parses the lock information, and sends the lock information to the lock management module 10322 . The NFS module 1031 executes steps 501 and 505 in FIG. 5 or steps 601 and 606 in FIG. 6 .

The lock management module 10322 determines whether the information of the locked client has been written into the feature log module 1033. If it has been written, it will not be written again. If the feature log module 1033 has not been written before, the client information will be written into the feature log module. 1033. The lock management module 10322 may perform steps 502, 503, 506 and 507 in FIG. 5 or steps 602, 603, 607 and 609 in FIG. 6 .

The lock management module 10322 sends the lock information to the persistence module 10323, and the persistence module 10323 determines whether to write to the file system. The persistence module 10323 determines whether the current server is configured with the function of ending the silence early. If the silent function is not terminated in advance, only the identifier of the first NFS lock needs to be written into the extended information of the file. When the client is unlocked, when the last lock is unlocked, the lock identifier in the extended information of the file is cleared. If the function of prematurely ending the silence is set, the number of locks (the number of locks) will be written into the extended information of the file. The number of locks in the extended information of the refresh file when the client is unlocked. The lock management module 10322 may perform step 504 in FIG. 5 or steps 605 and 608 in FIG. 6 .

Lock reiteration process:

After receiving the migration event, the recovery module 10321 reads the lock client information from the feature log module 1033 , and then sends the client information to the NFS module 1031 . The recovery module 10321 can perform steps 301 and 302 in FIG. 3 or steps 401 and 402 in FIG. 4 .

The NFS module 1031 sends a lock reassertion message to the client, and receives a lock reassertion request from the client, parses the lock information, and sends the lock information to the lock management module 10322. The NFS module 1031 may perform steps 303 and 304 in FIG. 3 or steps 403 and 404 in FIG. 4 .

The lock management module 10322 reads the extended information through the persistence module 10323. If it has already been read, it does not need to be read repeatedly, but can be read directly from the cache. If there is no setting to end the silent function in advance, you only need to judge whether there is a lock mark. If there is a lock identification, the logical judgment of lock reiteration is performed. If there is no lock flag, an error is returned and the client's lock reassertion is rejected. If the early termination of silence function is set, it is judged whether the number of locks reiterated is equal to the number of locks read, and if it is less than the number of locks read, the logical judgment of lock reiteration is performed. If the number of locks reiterated is equal to the number of locks read, the end of lock reiteration is marked. The persistence module 10323 may perform step 306 in FIG. 3 or steps 406 and 407 in FIG. 4 .

The lock management module 10322 determines whether the information of the locked client has been written into the feature log module 1033. If it has been written, it will not be written again. If the feature log module 1033 has not been written before, the client information will be written into the feature log module. 1033. The lock management module 10322 may perform steps 305 and 307 in FIG. 3 or steps 405 and 408 in FIG. 4 .

The lock reassertion method has been described above, and the following describes the server of the embodiment of the present application with reference to the accompanying drawings.

FIG. 8 is a schematic diagram of an embodiment of a server 80 in an embodiment of the present application.

As shown in FIG. 8 , an embodiment of the present application provides a structure of the server 80 including:

A receiving unit 801, configured to receive a lock reiteration request from a client;

A determination unit 802, configured to determine the target object corresponding to the client according to the lock reiteration request, and the target object is the object that the client wants to lock after the server restarts;

The re-locking unit 803 is configured to lock the target object from the lock identifier in the extension information corresponding to the target object, where the lock identifier indicates that the target object was locked before the server failure.

As shown in FIG. 9 , another structure of the server 90 provided in this embodiment of the present application includes:

a receiving unit 901, configured to receive a lock reiteration request from a client;

The determining unit 902 is used to determine the target object corresponding to the client according to the lock reiteration request, and the target object is the object that the client wants to lock after the server restarts;

The re-locking unit 903 is configured to lock the target object from the lock identifier in the extension information corresponding to the target object, where the lock identifier indicates that the target object was locked before the server failure.

Optionally, the extended information further includes the number of locks, the server further includes a marking unit 904, and the marking unit 904 is specifically configured to: when the number of lock reiteration requests corresponding to the target object exceeds the number of locks, mark the end of lock reiteration of the target object.

Specifically, the target object may be a file, directory, etc. in the file system, or may be a block or a logical unit number (Logical Unit Number, LUN) in a block storage system, or an object in an object storage system.

Optionally, the server further includes a first storage unit 905, and the first storage unit 905 is specifically configured to: when the successful lock reiteration request corresponds to the client, and the locking relationship of the object area where the target object is located is not stored in the feature log. When , the lock relationship between the client and the target area where the target object is located is stored in the feature log. In one implementation, in the file system, the object area is the file area or the directory area; in the block storage system, the object area is the metadata area of the block or LUN; in the object storage system, it is the metadata area of the object.

Optionally, the server also includes a locking unit 906, and the locking unit 906 is specifically used to: receive a locking request from the client; determine a target object according to the locking request, and the target object is the object to be locked by the client; The lock identification is stored in the corresponding extended information.

Optionally, the extended information further includes the number of locks, and the locking unit is also used for: correspondingly increasing the number of locks.

Optionally, the server further includes a first unlocking unit 907, and the first unlocking unit 907 is specifically configured to: receive unlocking requests from one or more clients; determine the target object according to the unlocking request, and the target object is the target object; When the number of unlock requests is the same as the number of lock requests, the lock flag is cleared.

Optionally, the server further includes a second unlocking unit 908, and the second unlocking unit 908 is specifically configured to: receive the unlocking request from the client; determine the target object according to the unlocking request; reduce the number of locks accordingly; When the number of lock requests is the same, the lock flag is cleared.

Optionally, the server further includes a second storage unit 909, and the second storage unit 909 is specifically configured to: when the locking relationship of the object area where the client and the target object are located is not stored in the feature log, store the object where the client and the target object are located. The locking relationship of the region is stored in the feature log.

As shown in FIG. 10 , another structure of the server 100 provided in this embodiment of the present application includes:

Obtaining unit 1001, for obtaining the lock identification of the target object;

The recording unit 1002 is configured to record the lock identification in the extended information of the target object.

Optionally, the obtaining unit 1001 is further configured to obtain the lock quantity of the target object; the recording unit 1002 is further configured to record the lock quantity in the extended information of the target object.

Optionally, the server 100 further includes a deletion unit 1003, the deletion unit 1003 is configured to delete the lock identification from the extended information of the target object when the lock of the target object is released.

Optionally, the server 100 further includes a reading unit 1004, and the reading unit 1004 is configured to acquire the lock identification from the extended information stored in the hard disk when restoring the lock of the target object.

Optionally, the server 100 is applied to a distributed file storage system.

As shown in FIG. 11 , a schematic diagram of a possible logical structure of the computer device 110 provided by the embodiment of the present application is shown. Computer device 110 includes: processor 1101 , communication interface 1102 , storage system 1103 , and bus 1104 . The processor 1101 , the communication interface 1102 , and the storage system 1103 are connected to each other through a bus 1104 . In this embodiment of the present application, the processor 1101 is configured to control and manage the actions of the computer device 110. For example, the processor 1101 is configured to execute the steps performed by the storage management apparatus in the method embodiment of FIG. 3 . Communication interface 1102 is used to support computer device 110 to communicate. The storage system 1103 is used to store program codes and data of the computer device 110 .

The processor 1101 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute the various exemplary logical blocks, modules and circuits described in connection with this disclosure. The processor 1101 may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor and a microprocessor, and the like. The bus 1104 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (Extended Industry Standard Architecture, EISA) bus or the like. The bus can be divided into address bus, data bus, control bus and so on. For ease of presentation, only one thick line is used in FIG. 11, but it does not mean that there is only one bus or one type of bus.

Embodiments of the present invention The modules or units in the foregoing embodiments may be specifically implemented by software, for example, by instructions, or by hardware, or by both software and hardware. This embodiment of the present invention does not limit this. The embodiment of the present invention can be used in a storage array supporting a file system, and can also be used to perform the above operations of the embodiment of the present invention on a directory in the file system. In addition, the embodiments of the present invention may also be applied to a block storage system or an object storage system. The block storage system may be a distributed block storage system or a storage array. In the block storage system, the foregoing operations in the embodiments of the present invention may be used for operations on blocks or LUNs. In an object storage system, the foregoing operations in the embodiments of the present invention may be applied to objects in the object storage system.

In another embodiment of the present application, a computer-readable storage medium is also provided, where computer-executable instructions are stored in the computer-readable storage medium. When the processor of the device executes the computer-executable instructions, the device executes the above-mentioned FIG. 3 to The steps of the lock reassurance method performed by the server in FIG. 6 .

In another embodiment of the present application, a computer program product is also provided, the computer program product includes computer-executable instructions, and the computer-executable instructions are stored in a computer-readable storage medium; when a processor of a device executes the computer-executable instructions , the device executes the steps of the lock reassertion method executed by the server in the above-mentioned FIG. 3 to FIG. 6 .

The server in this embodiment of the present invention may be a lock server, an array controller in a storage array, a server providing corresponding functions in a distributed storage system, and the like, which is not limited in this embodiment of the present invention. Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above may refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or modules may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

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

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units.

The integrated unit, if implemented in the form of a software functional unit and sold or used as an independent product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of software products in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, and the computer software products are stored in a storage medium , including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), magnetic disk or optical disk and other media that can store program codes .

Claims

A lock reiteration method, comprising:

The server receives a lock reassertion request from the client;

The server determines the target object corresponding to the client according to the lock reiteration request, and the target object is the object that the client wants to lock after the server restarts;

The server locks the target object from a lock identifier in the extension information corresponding to the target object, and the lock identifier indicates that the target object was locked before the server fails.
The lock reassertion method according to claim 1, wherein the extension information further includes a lock quantity, and the server locks the target object from a lock identifier in the extension information corresponding to the target object Before, the method further includes:

When the number of lock reassertion requests corresponding to the target object exceeds the number of locks, the server marks the lock reassertion end of the target object.
The lock reassertion method according to claim 1, wherein after the server locks the target object according to the lock reassertion request, the method further comprises:

When the client corresponding to the successful lock reiteration request and the locking relationship of the object area where the target object is located are not stored in the feature log, the server stores the client and the target object where The locking relationship of the object area is stored in the feature log.
The lock reassertion method according to claim 1, wherein before the server receives the lock reassertion request from the client, the method further comprises:

the server receives the locking request from the client;

The server determines the target object according to the lock request;

The server stores the lock identifier in the extension information corresponding to the target object.
The lock reassertion method according to claim 4, wherein the extended information further includes the number of locks, and after the server stores the lock identification in the extended information corresponding to the target object, the method further includes :

The server increases the number of locks accordingly.
The lock reiteration method according to claim 4, wherein after the server stores the lock identification in the extension information corresponding to the target object, the method further comprises:

the server receives an unlock request from one or more clients;

The server determines the target object according to the unlock request;

When the number of the unlocking requests is the same as the number of the locking requests, the server clears the locking identifier.
The lock reassertion method according to claim 5, wherein after the server increases the number of locks correspondingly, the method further comprises:

the server receives the unlock request from the client;

The server determines the target object according to the unlock request;

The server reduces the number of locks accordingly;

When the number of locks is 0, the server clears the lock identification.
lock reiteration method according to claim 4, is characterized in that, after described server determines described target object according to described lock request, described method also comprises:

When the locking relationship between the client and the object area where the target object is located is not stored in the feature log, the server stores the locking relationship between the client and the object region where the target object is located in the feature log .
A lock management method, characterized in that the method comprises:

The server obtains the lock identifier of the target object;

The server records the lock identification in the extended information of the target object.
The lock management method according to claim 9, wherein the method further comprises:

the server acquires the number of locks of the target object;

The server records the number of locks in the extended information of the target object.
The lock management method according to claim 9 or 10, wherein the method further comprises:

When releasing the lock of the target object, the server deletes the lock identification from the extended information of the target object.
The lock management method according to any one of claims 9-11, wherein the method further comprises:

When restoring the lock of the target object, the server acquires the lock identification from the extended information stored in the hard disk.
The lock management method according to any one of claims 9-12, wherein the method is applied to a distributed file storage system.
A server, characterized in that it includes:

A receiving unit for receiving a lock reiteration request from a client;

a determining unit, configured to determine a target object corresponding to the client according to the lock reiteration request, where the target object is an object that the client wants to lock after the server restarts;

A re-locking unit, configured to lock the target object from a lock identifier in the extension information corresponding to the target object, where the lock identifier indicates that the target object was locked before the server fails.
The server according to claim 14, wherein the extended information further includes a lock quantity, the server further includes a marking unit, and the marking unit is specifically used for:

When the number of lock reiteration requests corresponding to the target object exceeds the number of locks, the lock reiteration of the target object is marked as complete.
The server according to claim 14, wherein the server further comprises a first storage unit, and the first storage unit is specifically used for:

When the client corresponding to the successful lock reiteration request and the locking relationship of the object area where the target object is located are not stored in the feature log, the data of the client and the object area where the target object is located are The locking relationship is stored in the feature log.
The server according to claim 14, wherein the server further comprises a locking unit, and the locking unit is specifically used for:

receiving a lock request from the client;

Determine the target object according to the lock request;

The lock identifier is stored in the extension information corresponding to the target object.
The server according to claim 17, wherein the extended information further includes the number of locks, and the locking unit is further configured to:

Increase the number of locks accordingly.
The server according to claim 17, wherein the server further comprises a first unlocking unit, and the first unlocking unit is specifically configured to:

receive unlock requests from one or more clients;

Determine the target object according to the unlock request;

When the number of unlock requests of the target object is the same as the number of lock requests, the lock identifier is cleared.
The server according to claim 18, wherein the server further comprises a second unlocking unit, and the second unlocking unit is specifically configured to:

receiving an unlock request from the client;

Determine the target object according to the unlock request;

reduce the number of locks accordingly;

When the number of locks is 0, the lock identification is cleared.
The server according to claim 17, wherein the server further comprises a second storage unit, and the second storage unit is specifically used for:

When the locking relationship between the client and the object area where the target object is located is not stored in the feature log, the locking relationship between the client and the object region where the target object is located is stored in the feature log.
A server, characterized in that it includes:

The acquisition unit is used to acquire the lock identification of the target object;

A recording unit, configured to record the lock identification in the extended information of the target object.
The server of claim 22, wherein:

The acquiring unit is also used to acquire the lock quantity of the target object;

The recording unit is further configured to record the number of locks in the extended information of the target object.
The server according to claim 22 or 23, wherein the server further comprises a deletion unit,

The deletion unit is configured to delete the lock identification from the extended information of the target object when the lock of the target object is released.
The server according to any one of claims 22-24, wherein the server further comprises a reading unit,

The reading unit is configured to acquire the lock identification from the extended information stored in the hard disk when restoring the lock of the target object.
The server according to any one of claims 22-25, wherein the server is applied to a distributed file storage system.
A computer device is characterized in that, comprising: a processor and a memory,

The processor is configured to execute instructions stored in the memory to cause the computer device to perform the method of any one of claims 1 to 8.
A computer equipment, characterized in that it comprises: a processor and a memory,

The processor is configured to execute instructions stored in the memory, causing the computer device to perform the method of any one of claims 9 to 13.
A computer-readable storage medium, characterized in that, a computer program is stored in the computer-readable storage medium, and when the computer program is executed on the computer, the computer is made to execute the functions as described in claims 1 to 13. The method of any one.
A computer program product, characterized in that, when the computer program product is executed on a computer, the computer executes the method according to any one of claims 1 to 13.