File quota management method and device, electronic equipment and readable storage medium
By establishing a communication connection between the client and the quota server and the metadata server in the file system, the accurate file size after the file change operation is obtained, and the quota change amount is calculated and managed, the problem of inaccurate quota management after the file change operation is solved, and more accurate file quota management is achieved.
Patent Information
- Application Number
- CN202412000351.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-31
- Publication Date
- 2025-03-28
AI Technical Summary
In the file system, file change operations (such as rename operations) cause inaccurate file quota management, mainly because the file information recorded locally on the client is not up-to-date, which affects file quota management before and after the change.
Through the communication between the client and the quota server and the metadata server, determine the original file and target file corresponding to the file change operation, send metadata requests to obtain the file size, calculate the quota change, and send it to the quota server for capacity quota management.
It realizes more accurate quota management for files before and after the change in the file change scenario, ensuring that the quota server can effectively manage capacity based on the latest file size.
Smart Images

Figure CN119719027A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of file management, and in particular to a file quota management method, and also to a file quota management device, an electronic device, and a computer-readable storage medium. Background Art
[0002] In the file system, moving / overwriting / renaming a file is called a rename operation (file change operation). The rename operation is a relatively complex operation. During its implementation, the client generally uses the locally recorded file information to manage the quota of the file before and after the change. However, the file information recorded locally by the client is not necessarily the latest information, and the file change operation may have a certain impact on the file, resulting in inaccurate file quota management in the file change operation process.
[0003] Therefore, how to perform more accurate quota management on files before and after the change in a file change scenario is an urgent problem to be solved by those skilled in the art. Summary of the invention
[0004] The purpose of this application is to provide a file quota management method, which can perform more accurate quota management on files before and after the change in a file change scenario; another purpose of this application is to provide a file quota management device, an electronic device, a computer-readable storage medium and a computer program product, all of which have the above-mentioned beneficial effects.
[0005] In a first aspect, the present application provides a file quota management method, which is applied to a client, wherein the client is in communication connection with both a quota server and a metadata server, and the method comprises:
[0006] Determine an original file and a target file corresponding to the file change operation, and send a metadata request to a metadata server to which the original file and the target file belong;
[0007] Receiving the original file size and the target file size fed back by the metadata server based on the metadata request;
[0008] The quota changes of the original file and the target file are calculated respectively according to the local cache file information, the original file size, and the target file size;
[0009] The quota change amount is sent to the quota service end, so that the quota service end performs capacity quota management on the original file and the target file according to the quota change amount.
[0010] Optionally, sending a metadata request to a metadata server to which the original file and the target file belong includes:
[0011] Sending the metadata request to the metadata server to which the target file belongs, so that when the metadata server to which the target file belongs determines that the file change operation is a file change operation based on cross-file directory shards, the metadata request is forwarded to the metadata server to which the original file belongs;
[0012] Accordingly, receiving the original file size and the target file size fed back by the metadata server based on the metadata request includes:
[0013] Receiving the original file size fed back by the metadata server to which the original file belongs based on the metadata request;
[0014] Receive the target file size fed back by the metadata server to which the target file belongs based on the metadata request.
[0015] Optionally, sending a metadata request to a metadata server to which the original file and the target file belong includes:
[0016] Determine the estimated quota change amount of the original file and the target file according to the local cache file information;
[0017] When the estimated quota change amount of the target file is a decrease or remains unchanged, sending the metadata request to the metadata server to which the original file and the target file belong;
[0018] When the estimated quota change amount of the target file is an increase, sending a capacity application request to the quota server, so that the quota server pre-allocates a capacity size corresponding to the estimated quota change amount for the target file;
[0019] When the capacity size corresponding to the estimated quota change is pre-allocated successfully, sending the metadata request to the metadata server to which the original file and the target file belong;
[0020] When the pre-allocation of the capacity size corresponding to the estimated quota change fails, a prompt indicating that the file change operation has failed is output.
[0021] Optionally, determining the estimated quota change amount of the original file and the target file according to the local cache file information includes:
[0022] Determine a first record size of the original file and a second record size of the target file according to the local cache file information;
[0023] When the first record size is larger than the second record size, determining the estimated quota change amount of the original file to be a reduction of the first record size, and determining the estimated quota change amount of the target file to be an increase of the difference between the first record size and the second record size;
[0024] When the first record size is equal to the second record size, determining that the estimated quota change amount of the original file is to reduce the first record size, and determining that the estimated quota change amount of the target file remains unchanged;
[0025] When the first record size is smaller than the second record size, the estimated quota change amount of the original file is determined to be reduced by the first record size, and the estimated quota change amount of the target file is determined to be reduced by the difference between the second record size and the first record size.
[0026] Optionally, sending a metadata request to a metadata server to which the original file and the target file belong includes:
[0027] Acquire first file information of the original file and second file information of the target file;
[0028] generating the metadata request according to the first file information and the second file information;
[0029] The metadata request is sent to a metadata server to which the original file and the target file belong.
[0030] Optionally, respectively calculating the quota changes of the original file and the target file according to the local cache file information, the original file size, and the target file size includes:
[0031] Determine a first record size of the original file and a second record size of the target file according to the local cache file information;
[0032] Calculate the quota change of the original file according to the first record size and the original file size;
[0033] The quota change amount of the target file is calculated according to the second record size and the target file size.
[0034] Optionally, sending the quota change amount to the quota server so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount includes:
[0035] The quota change is sent to the quota server, so that the quota server allocates the capacity corresponding to the quota change to the original file and / or the target file when the quota change increases, and reclaims the capacity corresponding to the quota change from the original file and / or the target file when the quota change decreases.
[0036] In a second aspect, the present application further discloses a file quota management device, wherein the client is in communication connection with both the quota server and the metadata server, and the device comprises:
[0037] A sending module, used to determine the original file and the target file corresponding to the file change operation, and send a metadata request to the metadata server to which the original file and the target file belong;
[0038] A receiving module, configured to receive the original file size and the target file size fed back by the metadata server based on the metadata request;
[0039] A calculation module, used to calculate the quota changes of the original file and the target file respectively according to the local cache file information, the original file size, and the target file size;
[0040] The management module is used to send the quota change amount to the quota service end, so that the quota service end performs capacity quota management on the original file and the target file according to the quota change amount.
[0041] In a third aspect, the present application further discloses an electronic device, comprising:
[0042] Memory for storing computer programs;
[0043] A processor is used to implement the steps of any one of the file quota management methods described above when executing the computer program.
[0044] In a fourth aspect, the present application further discloses a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of any one of the file quota management methods described above are implemented.
[0045] In a fifth aspect, the present invention further discloses a computer program product, including a computer program / instruction, which implements the steps of any one of the file quota management methods described above when executed by a processor.
[0046] The present application provides a file quota management method, which is applied to a client, and the client is in communication with a quota server and a metadata server. The method includes: determining an original file and a target file corresponding to a file change operation, and sending a metadata request to the metadata server to which the original file and the target file belong; receiving the original file size and the target file size fed back by the metadata server based on the metadata request; respectively calculating the quota change amount of the original file and the target file according to local cache file information, the original file size, and the target file size; and sending the quota change amount to the quota server, so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount.
[0047] By applying the technical solution provided by the present application, in a file system, for a large file directory, the file directory will be divided into several directory fragments, and each directory fragment will be respectively entrusted to a different metadata server. Based on this, a communication connection can be established between the client and the metadata server and the quota server, so that the client can obtain the file size of the files before and after the change corresponding to the file change operation from the metadata server, and then the quota server can use the file size to perform quota management on the files before and after the change. It can be understood that the file size fed back by the metadata server must be the accurate value of the file size before and after the change, thereby effectively ensuring the accuracy of quota management. It can be seen that the present technical solution can perform more accurate quota management on the files before and after the change in the file change scenario.
[0048] In one embodiment of the present application, before initiating a metadata request to the metadata server to obtain accurate file size information, a preliminary verification of file quota management is first performed through the communication connection between the client and the quota server, that is, the quota change of the file before and after the change is first estimated based on the locally recorded file information, so that the quota server can perform pre-quota management on the file before and after the change based on the estimated quota change. If the pre-quota management is successful, metadata requests can continue to be initiated to the metadata server to obtain accurate file size information. Otherwise, there is no need to initiate metadata requests to the metadata server to obtain accurate file size information, that is, there is no need to waste the service resources of the metadata server, which effectively reduces the load pressure of the metadata server.
[0049] The file quota management device, electronic device, computer-readable storage medium, and computer program product provided in this application also have the above-mentioned technical effects, and this application will not elaborate on them here. BRIEF DESCRIPTION OF THE DRAWINGS
[0050] In order to more clearly illustrate the technical solutions in the prior art and the embodiments of the present application, the drawings required for use in the description of the prior art and the embodiments of the present application are briefly introduced below. Of course, the drawings described below in relation to the embodiments of the present application are only part of the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without creative work, and the obtained other drawings also belong to the protection scope of the present application.
[0051] Figure 1 A schematic diagram of the structure of a file system provided by this application;
[0052] Figure 2 A flowchart of a file quota management method provided by this application;
[0053] Figure 3 A timing diagram of a file quota management method provided by this application;
[0054] Figure 4 A schematic diagram of the structure of a file quota management device provided by this application;
[0055] Figure 5 A schematic diagram of the structure of an electronic device provided in this application. DETAILED DESCRIPTION
[0056] The core of this application is to provide a file quota management method, which can perform more accurate quota management on files before and after the change in a file change scenario; another core of this application is to provide a file quota management device, an electronic device, a computer-readable storage medium and a computer program product, all of which have the above-mentioned beneficial effects.
[0057] In order to describe the technical solutions in the embodiments of the present application more clearly and completely, the technical solutions in the embodiments of the present application will be introduced below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.
[0058] An embodiment of the present application provides a file quota management method.
[0059] First, please refer to Figure 1 , Figure 1This is a structural diagram of a file system provided by the present application, the file system includes a client, a quota server and a metadata server, wherein the number of quota servers is one, and the number of clients and metadata servers is not unique. The file quota management method provided in the embodiment of the present application is based on Figure 1 The file system shown is implemented. In a possible implementation, the file system may specifically be a distributed file system.
[0060] For further information, please refer to Figure 2 , Figure 2 A flowchart of a file quota management method provided by the present application, wherein the file quota management method is applied to Figure 1 The client shown may include the following S101 to S104.
[0061] S101: Determine an original file and a target file corresponding to a file change operation, and send a metadata request to a metadata server to which the original file and the target file belong.
[0062] This step aims to determine the files before and after the change and initiate a metadata request. The files before and after the change are the original file and the target file corresponding to the file change operation, the original file is the file before the change, the target file is the file after the change, and the metadata request is a request sent to the metadata server to which the files before and after the change belong to obtain the file size of the files before and after the change. It should be noted that in the file system, for a large file directory, the file directory will be divided into several directory fragments, and each directory fragment will be entrusted to a different metadata server. Therefore, the metadata server to which the files before and after the change belong may be the same or different.
[0063] In one embodiment of the present application, sending a metadata request to a metadata server to which an original file and a target file belong may include:
[0064] Acquire first file information of the original file and second file information of the target file;
[0065] generating a metadata request according to the first file information and the second file information;
[0066] Send a metadata request to the metadata server to which the original file and the target file belong.
[0067] The embodiment of the present application provides a method for implementing sending a metadata request to a metadata server to which the files before and after the change belong. Specifically, after determining the original file and the target file, the file information of the two can be obtained to generate a metadata request, and then the metadata request can be sent to the metadata server to which the two belong. Among them, the first file information may include but is not limited to the original file ino (a file format), the original file uid (a file identifier), the original file gid (another file identifier), the original file type, the original file size, the quota directory where the original file is located, etc.; the second file information may include but is not limited to the target file ino, the target file uid, the target file gid, the target file type, the target file size, the quota directory where the target file is located, etc. It can be understood that both the first file information and the second file information are suitable for the metadata server to realize the accurate determination of the file size before and after the change (corresponding to S102).
[0068] S102: Receive the original file size and the target file size fed back by the metadata server based on the metadata request.
[0069] This step aims to obtain the file size before and after the change. Specifically, after receiving the metadata request sent by the client, the metadata server can respond to the metadata request, determine the file size of the original file (i.e., the above-mentioned original file size) according to the first file information in the metadata request, and / or determine the file size of the target file (i.e., the above-mentioned target file size) according to the second file information in the metadata request, thereby feeding back the original file size and / or the target file size to the client.
[0070] In one embodiment of the present application, sending the metadata request to the metadata server to which the original file and the target file belong may include: sending the metadata request to the metadata server to which the target file belongs, so that the metadata server to which the target file belongs, when determining that the file change operation is a file change operation based on cross-file directory shards, forwards the metadata request to the metadata server to which the original file belongs;
[0071] Accordingly, receiving the original file size and the target file size fed back by the metadata server based on the metadata request may include: receiving the original file size fed back by the metadata server to which the original file belongs based on the metadata request; receiving the target file size fed back by the metadata server to which the target file belongs based on the metadata request.
[0072] The embodiment of the present application provides an implementation method for obtaining the file size before and after the change. As described above, the metadata server to which the file belongs before and after the change may be the same or different. For the client, it can first send a metadata request to the metadata server to which the target file belongs, and the metadata server to which the target file belongs will perform a type judgment of the file change operation, that is, whether the file change operation is a file change operation based on cross-file directory sharding. In essence, it is to judge whether the metadata server to which the file belongs before and after the change is the same. If it is not the same, the metadata server to which the target file belongs can continue to forward the metadata request to the metadata server to which the original file belongs. As a result, the metadata server to which the target file belongs can feed back the target file size to the client, and the metadata server to which the original file belongs can feed back the original file size to the client. Of course, if the metadata server to which the file belongs before and after the change is the same, the metadata server will directly feed back the original file size and the target file size to the client.
[0073] S103: Calculate the quota changes of the original file and the target file respectively according to the local cache file information, the original file size, and the target file size.
[0074] This step aims to realize the quota change of the file before and after the change, that is, the file change size before and after the file change. This process can be implemented in combination with local cache file information, wherein the local cache file information mainly includes the file information of the original file recorded locally by the client and the file information of the target file, such as the first file information and the second file information as described above.
[0075] In one embodiment of the present application, respectively calculating the quota changes of the original file and the target file according to the local cache file information, the original file size, and the target file size may include:
[0076] Determine a first record size of the original file and a second record size of the target file according to the local cache file information;
[0077] The quota change amount of the original file is calculated according to the first record size and the original file size;
[0078] The quota change amount of the target file is calculated according to the second record size and the target file size.
[0079] The embodiment of the present application provides a method for calculating the quota change of files before and after the change. As described above, the client locally caches the file information of the files before and after the change, that is, the local cache file information, and thus, the original file size (that is, the first record size) and the target file size (that is, the second record size) recorded locally by the client can be determined based on the local cache file information. Then, the difference between the first record size and the original file size is the quota change of the original file, and the difference between the second record size and the target file size is the quota change of the target file.
[0080] S104: Sending the quota change amount to the quota server, so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount.
[0081] This step aims to implement the quota server's capacity quota management for the original file and the target file. Specifically, after the client determines the quota change of the original file and the target file, it can send the two to the quota server, so that the quota server can perform capacity quota management on the file directories of the two according to the quota change of the two, where the capacity quota management can be to allocate new capacity quotas or reclaim excess capacity quotas.
[0082] In one embodiment of the present application, sending the quota change to the quota server so that the quota server performs capacity quota management on the original file and the target file based on the quota change may include: sending the quota change to the quota server so that the quota server allocates the capacity size corresponding to the quota change to the original file and / or the target file when the quota change is increased, and reclaims the capacity size corresponding to the quota change from the original file and / or the target file when the quota change is decreased.
[0083] The embodiment of the present application provides a method for implementing capacity quota management of original files and target files by a quota server. It can be understood that when the quota change of the target file is increasing, new capacity can continue to be allocated to the target file, and when the quota change of the target file is decreasing, excess capacity can be reclaimed from the target file; when the quota change of the original file is increasing, new capacity can continue to be allocated to the original file, and when the quota change of the original file is decreasing, excess capacity can be reclaimed from the original file. Of course, the specific size of the new capacity allocated and the size of the excess capacity reclaimed are determined by the value of the corresponding quota change.
[0084] It can be seen that the file quota management method provided in the embodiment of the present application, in the file system, for a large file directory, will divide the file directory into several directory fragments, and entrust each directory fragment to a different metadata server respectively. Based on this, a communication connection can be established between the client and the metadata server and the quota server, so that the client can obtain the file size of the files before and after the change corresponding to the file change operation from the metadata server, and then the quota server can use the file size to perform quota management on the files before and after the change. It can be understood that the file size fed back by the metadata server must be the accurate value of the file size before and after the change, so as to effectively ensure the accuracy of quota management. It can be seen that the technical solution can perform more accurate quota management on the files before and after the change in the file change scenario.
[0085] Based on the above embodiments:
[0086] In one embodiment of the present application, sending a metadata request to a metadata server to which an original file and a target file belong may include:
[0087] Determine the estimated quota change of the original file and the target file based on the local cache file information;
[0088] When the estimated quota change of the target file is reduced or unchanged, a metadata request is sent to the metadata server to which the original file and the target file belong;
[0089] When the estimated quota change of the target file is an increase, a capacity application request is sent to the quota server, so that the quota server pre-allocates the capacity size corresponding to the estimated quota change for the target file;
[0090] When the capacity size corresponding to the estimated quota change is pre-allocated successfully, a metadata request is sent to the metadata server to which the original file and the target file belong;
[0091] When the capacity size corresponding to the estimated quota change fails to be pre-allocated, a prompt indicating that the file change operation failed is output.
[0092] The embodiment of the present application provides a method for implementing sending a metadata request to the metadata server to which the files before and after the change belong, aiming to effectively reduce the waste of unnecessary metadata server resources. It is understandable that there may be hundreds or thousands of clients in the entire file system, but there will only be a small number of metadata servers. If all quota management work is pushed to the metadata server, the metadata server will be under too much pressure, resulting in reduced system performance. Therefore, the client can first perform preliminary verification work.
[0093] Specifically, before initiating a metadata request to the metadata server to obtain accurate file size information, a preliminary verification of file quota management is first performed through the communication connection between the client and the quota server, that is, the quota change of the file before and after the change is first estimated based on the locally recorded file information, so that the quota server can perform pre-quota management on the files before and after the change based on the estimated quota change. If the pre-quota management is successful, you can continue to initiate a metadata request to the metadata server to obtain accurate file size information. Otherwise, there is no need to initiate a metadata request to the metadata server to obtain accurate file size information, that is, there is no need to waste the service resources of the metadata server, which effectively reduces the load pressure of the metadata server.
[0094] Determining the estimated quota change amount of the original file and the target file according to the local cache file information may include:
[0095] Determine a first record size of the original file and a second record size of the target file according to the local cache file information;
[0096] When the first record size is larger than the second record size, determining the estimated quota change amount of the original file is to reduce the first record size, and determining the estimated quota change amount of the target file is to increase the difference between the first record size and the second record size;
[0097] When the first record size is equal to the second record size, determining that the estimated quota change amount of the original file is to reduce the first record size, and determining that the estimated quota change amount of the target file remains unchanged;
[0098] When the first record size is smaller than the second record size, the estimated quota change amount of the original file is determined to be reduced by the first record size, and the estimated quota change amount of the target file is determined to be reduced by the difference between the second record size and the first record size.
[0099] The embodiment of the present application provides a method for estimating the change in quota of original files and directory files based on local cache file information. In the implementation process, the estimation strategy can be determined based on the file size of the files before and after the change recorded in the local cache file information, so that the validity calculation of the estimated quota change can be performed using a suitable estimation strategy.
[0100] In one embodiment of the present application, after sending the quota change amount to the quota server so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount, the following may also be included:
[0101] Determine the actual file sizes of the original and target files;
[0102] Update the local cache file information according to the actual file sizes of the original file and the target file;
[0103] Upload the actual file sizes of the original file and the target file to the quota server so that the quota server can update the file quota management information.
[0104] The file quota management method provided by the embodiments of the present application can further update the file record information of the client and the quota client, so as to achieve more accurate file quota management during subsequent file change operations. Specifically, after the quota server completes file quota management, the current actual file sizes of the original file and the target file can be uploaded to the quota server. Thus, the quota server can update the file quota management information it maintains (including the quota management of various files in the file system), and the client can also update the file information it maintains (i.e., the above local cached file information).
[0105] Based on the above embodiments, the embodiments of the present application provide another file quota management method.
[0106] Please refer to Figure 3 , Figure 3 which is a timing diagram of a file quota management method provided by the present application, and its implementation process is as follows:
[0107] (1) The user initiates a rename operation (file change operation) to the client.
[0108] (2) According to the file size before the change and the file size after the change currently recorded by the client, roughly estimate the quota reduction amount of the file before the change and the quota change amount after the change. The estimation calculation method is as follows:
[0109] Assume there are files / a / file1 (file before the change) and / b / file2 (file after the change), the size of file1 is size1, and the size of file2 is size2. Execute mv / a / file1 / b / file2 (file change command):
[0110] If size1>size2, after the file change operation, the capacity of the / a directory decreases by size1, and the capacity of the / b directory increases by size1 - size2;
[0111] If size1 = size2, after the file change operation, the capacity of the / a directory decreases by size1, and the capacity of the / b directory remains unchanged;
[0112] If size1<size2, after the file change operation, the capacity of the / a directory decreases by size1, and the capacity of the / b directory decreases by size2 - size1.
[0113] After the above calculation, if the quota usage of the changed file increases, the client initiates a pre-application for quota to the quota server, trying to apply for sufficient capacity. If the remaining amount of the quota server is sufficient, it allocates an appropriate amount of capacity to the client and updates the remaining amount of the quota of the changed file; if the remaining amount of the quota server is insufficient, the pre-application fails, and the client is notified that the file change operation has failed. If the quota usage of the changed file remains unchanged or decreases, go directly to step (4).
[0114] (3) The client consumes the quota capacity allocated by the quota server based on the calculated quota change of the changed file. After this process is successfully executed, the quota check passes and step (4) is allowed to be executed.
[0115] (4) The client constructs a metadata request and initiates a metadata request to the metadata server of the changed file. The metadata request carries relevant parameters of the file change operation, including but not limited to the original file ino, original file uid, original file gid, original file type, original file size, the quota directory where the original file is located, target file ino, target file uid, target file gid, target file type, target file size, and the quota directory where the target file is located.
[0116] (5) After the metadata server of the changed file receives the metadata request, if it finds that the file change operation spans the directory shard, it will forward the metadata request to the metadata server of the file before the change, requesting the metadata server of the file before the change to cooperate in completing the file change operation.
[0117] (6) After receiving the metadata request, the metadata server of the file before the change processes the change of the directory fragment and responds to the metadata server of the file after the change with the current actual file size of the file before the change.
[0118] (7) After receiving the response from the metadata server of the file before the change, the metadata server of the file after the change processes the change of the directory fragment and responds to the client with the current actual file sizes of the file before and after the change.
[0119] (8) After the client receives the actual file size of the file before and after the change, it calculates the actual quota reduction of the file before the change and the actual quota change of the file after the change.
[0120] If the actual quota change of the file becomes larger after the change, the quota allocation needs to be consumed again. Therefore, you can make a pre-application to the quota server again. The quota server allocates capacity, updates the remaining amount, and responds.
[0121] If the actual quota change of the file becomes smaller after the change, it means that the quota capacity previously consumed is too large. This part of the capacity needs to be calibrated and returned to the quota server to ensure that the quota server maintains the correct quota remaining amount.
[0122] (9) The client returns a message to the front-end user indicating that the file change operation was successful.
[0123] (10) The client periodically reports the quota usage of the file before and after the change to the quota server.
[0124] (11) After receiving the reported data, the quota server updates the quota usage of the file before and after the change. Since the quota usage of the file before the change is reduced, the quota server can synchronize the reduction to its own remaining amount. At this point, the quota server counts the actual quota usage and quota remaining amount of the file before and after the change.
[0125] It can be seen that the file quota management method provided in the embodiment of the present application, in the file system, for a large file directory, will divide the file directory into several directory fragments, and entrust each directory fragment to a different metadata server respectively. Based on this, a communication connection can be established between the client and the metadata server and the quota server, so that the client can obtain the file size of the files before and after the change corresponding to the file change operation from the metadata server, and then the quota server can use the file size to perform quota management on the files before and after the change. It can be understood that the file size fed back by the metadata server must be the accurate value of the file size before and after the change, so as to effectively ensure the accuracy of quota management. It can be seen that the technical solution can perform more accurate quota management on the files before and after the change in the file change scenario.
[0126] An embodiment of the present application provides a file quota management device.
[0127] Please refer to Figure 4 , Figure 4 This is a schematic diagram of the structure of a file quota management device provided by the present application. The file quota management device is applied to a client that can communicate with both a quota server and a metadata server, and may include:
[0128] A sending module 1 is used to determine the original file and the target file corresponding to the file change operation, and send a metadata request to the metadata server to which the original file and the target file belong;
[0129] Receiving module 2, used to receive the original file size and the target file size fed back by the metadata server based on the metadata request;
[0130] Calculation module 3, used to calculate the quota changes of the original file and the target file respectively according to the local cache file information, the original file size and the target file size;
[0131] The management module 4 is used to send the quota change amount to the quota server, so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount.
[0132] It can be seen that the file quota management device provided in the embodiment of the present application, in the file system, for a large file directory, will divide the file directory into several directory fragments, and entrust each directory fragment to a different metadata server respectively. Based on this, a communication connection can be established between the client and the metadata server and the quota server, so that the client can obtain the file size of the files before and after the change corresponding to the file change operation from the metadata server, and then the quota server can use the file size to perform quota management on the files before and after the change. It can be understood that the file size fed back by the metadata server must be the accurate value of the file size before and after the change, so as to effectively ensure the accuracy of quota management. It can be seen that the technical solution can perform more accurate quota management on the files before and after the change in the file change scenario.
[0133] In one embodiment of the present application, the sending module 1 may be specifically used to send a metadata request to a metadata server to which the target file belongs, so that when the metadata server to which the target file belongs determines that the file change operation is a file change operation based on cross-file directory shards, the metadata request is forwarded to the metadata server to which the target file belongs;
[0134] Accordingly, the receiving module 2 can be specifically used to receive the original file size fed back by the metadata server to which the target file belongs based on the metadata request; and receive the target file size fed back by the metadata server to which the target file belongs based on the metadata request.
[0135] In one embodiment of the present application, the sending module 1 may include:
[0136] A determination unit, used to determine an estimated quota change amount of an original file and a target file according to local cache file information;
[0137] A first sending unit is used to send a metadata request to a metadata server to which the original file and the target file belong when the estimated quota change amount of the target file is reduced or unchanged;
[0138] The second sending unit is used to send a capacity application request to the quota server when the estimated quota change amount of the target file is an increase, so that the quota server pre-allocates a capacity size corresponding to the estimated quota change amount for the target file;
[0139] A third sending unit is used to send a metadata request to a metadata server to which the original file and the target file belong when the capacity size corresponding to the estimated quota change amount is pre-allocated successfully;
[0140] The output unit is used to output a prompt indicating that the file change operation failed when the capacity size corresponding to the estimated quota change fails to be pre-allocated.
[0141] In one embodiment of the present application, the above-mentioned determination unit can be specifically used to determine the first record size of the original file and the second record size of the target file based on the local cache file information; when the first record size is larger than the second record size, the estimated quota change of the original file is determined to be a reduction of the first record size, and the estimated quota change of the target file is determined to be an increase of the difference between the first record size and the second record size; when the first record size is equal to the second record size, the estimated quota change of the original file is determined to be a reduction of the first record size, and the estimated quota change of the target file is determined to be unchanged; when the first record size is smaller than the second record size, the estimated quota change of the original file is determined to be a reduction of the first record size, and the estimated quota change of the target file is determined to be a reduction of the difference between the second record size and the first record size.
[0142] In one embodiment of the present application, the above-mentioned sending module 1 can be specifically used to obtain the first file information of the original file and the second file information of the target file; generate a metadata request based on the first file information and the second file information; and send the metadata request to the metadata server to which the original file and the target file belong.
[0143] In one embodiment of the present application, the above-mentioned calculation module 3 can be specifically used to determine the first record size of the original file and the second record size of the target file based on the local cache file information; calculate the quota change of the original file based on the first record size and the original file size; calculate the quota change of the target file based on the second record size and the target file size.
[0144] In one embodiment of the present application, the above-mentioned management module 4 can be specifically used to send the quota change to the quota server, so that the quota server allocates the capacity size corresponding to the quota change to the original file and / or the target file when the quota change is increased, and reclaims the capacity size corresponding to the quota change from the original file and / or the target file when the quota change is decreased.
[0145] For an introduction to the device provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.
[0146] An embodiment of the present application provides an electronic device.
[0147] Please refer to Figure 5 , Figure 5This is a schematic diagram of the structure of an electronic device provided in this application, and the electronic device may include:
[0148] A memory 11, used for storing computer programs;
[0149] The processor 10 can implement the steps of any one of the above-mentioned file quota management methods when executing a computer program.
[0150] like Figure 5 , which is a schematic diagram of the composition structure of an electronic device, the electronic device may include: a processor 10, a memory 11, a communication interface 12 and a communication bus 13. The processor 10, the memory 11 and the communication interface 12 all communicate with each other through the communication bus 13.
[0151] In the embodiment of the present application, the processor 10 may be a central processing unit (CPU), an application specific integrated circuit, a digital signal processor, a field programmable gate array or other programmable logic devices, etc.
[0152] The processor 10 may call a program stored in the memory 11. Specifically, the processor 10 may execute operations in an embodiment of a file quota management method in a file change scenario.
[0153] The memory 11 is used to store one or more programs, which may include program codes, and the program codes include computer operation instructions. In the embodiment of the present application, the memory 11 at least stores programs for implementing the following functions:
[0154] Determine the original file and the target file corresponding to the file change operation, and send a metadata request to the metadata server to which the original file and the target file belong;
[0155] Receive the original file size and target file size fed back by the metadata server based on the metadata request;
[0156] The quota changes of the original file and the target file are calculated based on the local cache file information, the original file size, and the target file size;
[0157] The quota change amount is sent to the quota server, so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount.
[0158] In a possible implementation, the memory 11 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and an application required for at least one function, etc.; the data storage area may store data created during use.
[0159] In addition, the memory 11 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.
[0160] The communication interface 12 may be an interface of a communication module, and is used to connect to other devices or systems.
[0161] Of course, it should be noted that Figure 5 The structure shown does not constitute a limitation on the electronic device in the embodiment of the present application. In actual applications, the electronic device may include Figure 5 More or fewer components than shown, or combinations of certain components.
[0162] An embodiment of the present application provides a computer-readable storage medium.
[0163] The computer-readable storage medium provided in the embodiment of the present application stores a computer program, and when the computer program is executed by a processor, the steps of any one of the above-mentioned file quota management methods can be implemented.
[0164] Among them, the computer-readable storage medium can be any available medium that can be stored in a computer or a data storage device such as a server or data center that includes one or more available media integrated. For example, it can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape, etc.), an optical medium (such as a DVD) or a semiconductor medium (such as a solid-state hard disk) and other media that can store computer program codes.
[0165] For an introduction to the computer-readable storage medium provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.
[0166] An embodiment of the present application provides a computer program product.
[0167] The computer program product provided in the embodiments of the present application includes a computer program / instruction, and when the computer program / instruction is executed by a processor, the steps of any one of the above-mentioned file quota management methods can be implemented.
[0168] Specifically, in the above embodiments, all or part of them can be implemented by software, hardware, firmware or any combination thereof. When implemented by software, all or part of them can be implemented in the form of a computer program product.
[0169] Among them, the computer program product may include one or more computer programs / instructions, and when the computer program / instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application may be generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, computer instructions may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line, etc.) or wireless (e.g., infrared, wireless, microwave, etc.) means.
[0170] For an introduction to the computer program product provided in the embodiments of the present application, please refer to the above method embodiments, and the present application will not elaborate on them here.
[0171] The various embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.
[0172] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0173] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
[0174] The technical solution provided by the present application is described in detail above. The principle and implementation method of the present application are described in detail using specific examples herein, and the description of the above embodiments is only used to help understand the method and core idea of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.
Claims
1. A file quota management method, characterized in that: Applied to a client, the client is in communication connection with both a quota server and a metadata server, the method comprising: Determine an original file and a target file corresponding to the file change operation, and send a metadata request to a metadata server to which the original file and the target file belong; Receiving the original file size and the target file size fed back by the metadata server based on the metadata request; The quota changes of the original file and the target file are calculated respectively according to the local cache file information, the original file size, and the target file size; The quota change amount is sent to the quota service end, so that the quota service end performs capacity quota management on the original file and the target file according to the quota change amount.
2. The file quota management method according to claim 1, characterized in that: Sending a metadata request to a metadata server to which the original file and the target file belong includes: Sending the metadata request to the metadata server to which the target file belongs, so that when the metadata server to which the target file belongs determines that the file change operation is a file change operation based on cross-file directory shards, the metadata request is forwarded to the metadata server to which the original file belongs; Accordingly, receiving the original file size and the target file size fed back by the metadata server based on the metadata request includes: Receiving the original file size fed back by the metadata server to which the original file belongs based on the metadata request; Receive the target file size fed back by the metadata server to which the target file belongs based on the metadata request.
3. The file quota management method according to claim 1 or 2, characterized in that: Sending a metadata request to a metadata server to which the original file and the target file belong includes: Determine the estimated quota change amount of the original file and the target file according to the local cache file information; When the estimated quota change amount of the target file is a decrease or remains unchanged, sending the metadata request to the metadata server to which the original file and the target file belong; When the estimated quota change amount of the target file is an increase, sending a capacity application request to the quota server, so that the quota server pre-allocates a capacity size corresponding to the estimated quota change amount for the target file; When the capacity size corresponding to the estimated quota change is pre-allocated successfully, sending the metadata request to the metadata server to which the original file and the target file belong; When the pre-allocation of the capacity size corresponding to the estimated quota change fails, a prompt indicating that the file change operation has failed is output.
4. The file quota management method according to claim 3, characterized in that: Determining the estimated quota change amount of the original file and the target file according to the local cache file information includes: Determine a first record size of the original file and a second record size of the target file according to the local cache file information; When the first record size is larger than the second record size, determining the estimated quota change amount of the original file to be a reduction of the first record size, and determining the estimated quota change amount of the target file to be an increase of the difference between the first record size and the second record size; When the first record size is equal to the second record size, determining that the estimated quota change amount of the original file is to reduce the first record size, and determining that the estimated quota change amount of the target file remains unchanged; When the first record size is smaller than the second record size, the estimated quota change amount of the original file is determined to be reduced by the first record size, and the estimated quota change amount of the target file is determined to be reduced by the difference between the second record size and the first record size.
5. The file quota management method according to claim 1, characterized in that: Sending a metadata request to a metadata server to which the original file and the target file belong includes: Acquire first file information of the original file and second file information of the target file; generating the metadata request according to the first file information and the second file information; The metadata request is sent to a metadata server to which the original file and the target file belong.
6. The file quota management method according to claim 1, characterized in that: The quota changes of the original file and the target file are calculated respectively according to the local cache file information, the original file size, and the target file size, including: Determine a first record size of the original file and a second record size of the target file according to the local cache file information; Calculate the quota change of the original file according to the first record size and the original file size; The quota change amount of the target file is calculated according to the second record size and the target file size.
7. The file quota management method according to claim 1, characterized in that: The method includes: sending the quota change amount to the quota server so that the quota server performs capacity quota management on the original file and the target file according to the quota change amount. The quota change is sent to the quota server, so that the quota server allocates the capacity corresponding to the quota change to the original file and / or the target file when the quota change increases, and reclaims the capacity corresponding to the quota change from the original file and / or the target file when the quota change decreases.
8. A file quota management device, characterized in that: Applied to a client, the client is in communication connection with both a quota server and a metadata server, and the device comprises: A sending module, used to determine the original file and the target file corresponding to the file change operation, and send a metadata request to the metadata server to which the original file and the target file belong; A receiving module, configured to receive the original file size and the target file size fed back by the metadata server based on the metadata request; A calculation module, used to calculate the quota changes of the original file and the target file respectively according to the local cache file information, the original file size, and the target file size; The management module is used to send the quota change amount to the quota service end, so that the quota service end performs capacity quota management on the original file and the target file according to the quota change amount.
9. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the file quota management method according to any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the file quota management method according to any one of claims 1 to 7 are implemented.
Citation Information
Patent Citations
Quota information reporting method and device
CN118733251A
File system with quota management function, quota management method, and quota management program
JP2014146144A