File system mounting method and device, equipment and storage medium

Abstract

The invention provides a file system mounting method and device, equipment and a storage medium, and relates to the technical field of computers, in particular to the field of network file systems. The method comprises the following steps: detecting whether a mounting request obtained from a user side comprises a target token or not; under the condition that the target token is included, querying a target authorization record associated with the target token from candidate authorization records of candidate file systems; the target authorization record comprises a target identifier of a target file system; and feeding back the target identifier to the user side, so that the user side adopts the target identifier to access the target file system.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technologies, and more particularly to the field of network file systems. Specifically, it relates to a method, apparatus, device, and storage medium for mounting a file system. Background Art

[0002] The file system mounting technology is a key component in the field of data access and sharing. Among them, the Network File System (NFS), as an important tool for sharing file directories between Linux systems, has greatly facilitated the flexible access to data. As an open-source software project, NFS-Ganesha supports a wide range of distributed storage interfaces at the backend through the file system functions in the user space and exposes standard file system semantics to the user side, thereby enhancing the compatibility and usability of the system.

[0003] However, currently, mounting NFS through Ganesha still has difficulty meeting users' requirements for more refined and flexible file access control. Summary of the Invention

[0004] The present disclosure provides a method, apparatus, device, and storage medium for mounting a file system.

[0005] According to one aspect of the present disclosure, there is provided a method for mounting a file system, which is executed by a file system server, and the method includes:

[0006] Detecting whether a target token is included in a mounting request obtained from a user side;

[0007] In the case of including the target token, querying a target authorization record associated with the target token from candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0008] Feeding back the target identifier to the user side, so that the user side accesses the target file system by using the target identifier.

[0009] According to another aspect of the present disclosure, there is provided a method for mounting a file system, which is executed by a user side, and the method includes:

[0010] Generating a mounting request including a target token and sending the mounting request to a file system server, so that the file system server, in the case of detecting that the mounting request obtained from the user side includes the target token, queries a target authorization record associated with the target token from candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0011] Obtain the target identifier fed back by the file system server;

[0012] Access the target file system using the target identifier.

[0013] According to another aspect of the present disclosure, there is provided a mounting device for a file system, configured in a file system server, the device includes:

[0014] A token detection module, configured to detect whether a mounting request obtained from a client includes a target token;

[0015] A record query module, configured to, in the case of including the target token, query a target authorization record associated with the target token from candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0016] An identifier sending module, configured to feed back the target identifier to the client, so that the client accesses the target file system using the target identifier.

[0017] According to another aspect of the present disclosure, there is provided a mounting device for a file system, configured in a client, the device includes:

[0018] A mounting request module, configured to generate a mounting request including a target token, and send the mounting request to a file system server, so that the file system server, in the case of detecting that a mounting request obtained from a client includes a target token, queries a target authorization record associated with the target token from candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0019] An identifier feedback module, configured to obtain the target identifier fed back by the file system server;

[0020] A file access module, configured to access the target file system using the target identifier.

[0021] According to another aspect of the present disclosure, there is provided an electronic device, the electronic device includes:

[0022] At least one processor; and

[0023] A memory communicatively connected to the at least one processor; wherein,

[0024] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor, so that the at least one processor can execute the method provided by any embodiment of the present disclosure.

[0025] According to another aspect of the present disclosure, there is provided a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the method provided in any embodiment of the present disclosure.

[0026] According to still another aspect of the present disclosure, there is provided a computer program product including a computer program, which when executed by a processor implements the method provided in any embodiment of the present disclosure.

[0027] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the present disclosure. Other features of the present disclosure will become easily understandable through the following description. Description of the Drawings

[0028] Figure 1a is a flowchart of a method for mounting a file system provided according to an embodiment of the present disclosure;

[0029] Figure 1b is a schematic structural diagram of a file system provided according to an embodiment of the present disclosure;

[0030] Figure 2 is a flowchart of another method for mounting a file system provided according to an embodiment of the present disclosure;

[0031] Figure 3a is a flowchart of still another method for mounting a file system provided according to an embodiment of the present disclosure;

[0032] Figure 3b is a schematic structural diagram of another file system provided according to an embodiment of the present disclosure;

[0033] Figure 4 is a flowchart of still another method for mounting a file system provided according to an embodiment of the present disclosure;

[0034] Figure 5 is a flowchart of still another method for mounting a file system provided according to an embodiment of the present disclosure;

[0035] Figure 6 is a schematic structural diagram of a file system mounting device provided according to an embodiment of the present disclosure;

[0036] Figure 7 is a schematic structural diagram of another file system mounting device provided according to an embodiment of the present disclosure;

[0037] Figure 8 is a block diagram of an electronic device for implementing the method for mounting a file system according to an embodiment of the present disclosure. Detailed Embodiments

[0038] Figure 1a This is a flowchart of a method for mounting a file system provided according to an embodiment of the present disclosure. This method is applicable to the situation where a user is allowed to mount to a specified network file system. This method can be executed by a mounting device of a file system. The device can be implemented in software and / or hardware and can be integrated into a file system server. The file system server can be an open-source NFS server that supports multiple versions of the NFS protocol, such as a ganesha server. As Figure 1a shown, the method for mounting a file system in this embodiment may include:

[0039] S101, detecting whether a target token is included in a mounting request obtained from a client;

[0040] S102, when the target token is included, querying a target authorization record associated with the target token from candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0041] S103, feeding back the target identifier to the client, so that the client accesses the target file system using the target identifier.

[0042] Referring to Figure 1b , an NFS file system may include a client, a file system server such as a ganesha server, a backend storage module, and a file system management module. Among them, the file system server is respectively communicatively connected to the client, the backend storage module, and the file system management module. The backend storage module is used to store directory information and file data of each candidate file system. Some of the candidate file systems in the backend storage module may be based on the NFS protocol; some other candidate file systems may be based on protocols other than NFS, such as CephFS, GlusterFS, etc. The candidate file systems based on other protocols can be integrated with the NFS server through corresponding drivers or interfaces, so that the NFS server can share the data in these candidate file systems through the NFS protocol. In the database of the file system management module, candidate authorization records of each candidate file system may be pre-stored, at least including the association relationship between the candidate identifier and the candidate token of the candidate file system. The candidate identifier is a file system identifier (File System ID, fsid). A candidate file system can have different candidate authorization records for different users, that is, different users are allowed to access the same candidate file system using their respective different candidate tokens.

[0043] The mount request may include a request type, a protocol version, a server address, a file system directory, and a mount point directory; the file system directory refers to the directory in the candidate file system that needs to be mounted and accessed; the mount point directory is a directory on the local file system of the client, which is used as the mount point of the candidate file system in the candidate storage module. Once the mount is successful, the client can access the files and directories on the corresponding candidate file system in the backend storage module by accessing the local mount point directory.

[0044] The target token refers to the token specified by the user in the mount request, such as the token entered by the user. The target token may be in the file system directory of the mount request. Exemplarily, the user can obtain candidate tokens for accessing at least one candidate file system in advance. In the case of needing to mount to one of the candidate file systems, i.e., the target file system, the corresponding target token can be written into the file system directory to obtain the mount request, and the mount request is sent to the file system server.

[0045] The file system server obtains the mount request from the client and checks whether the mount request includes a target token; in the case where the mount request includes a target token, the file system server can query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes at least the target identifier of the target file system. Therefore, if the target identifier associated with the target token is queried from the candidate authorization record, the target identifier is fed back to the client, enabling the client to access the corresponding directory in the target file system using the target identifier; if there is no target identifier associated with the target token in the candidate authorization record, the mount request is rejected.

[0046] A user may have multiple candidate tokens for different candidate file systems, and the same user can also use the same candidate token to initiate a mount request on different clients, so as to access the same candidate file system on different clients; different users can also access different candidate file systems on the same client. By obtaining the mount request from the client and checking whether the mount request includes the target token specified by the user; if the target token is included, query the target identifier associated with the target token and feed the target identifier back to the client, enabling the client to access the corresponding directory in the target file system using the target identifier, that is, by the user specifying the target token in the mount request and modifying the processing logic of the file system server for the mount request, the flexible switching between different candidate file systems is achieved, improving the mount flexibility of the file system.

[0047] The technical solution provided by the embodiments of the present disclosure detects whether the mount request sent by the user terminal includes a target token specified by the user. In the case of including the target token, by querying the target authorization record associated with the target token from the candidate authorization records of each candidate file system, obtaining the target identifier associated with the target token, and feeding back the target identifier to the user terminal, the user terminal can use the target identifier to access the corresponding directory in the target file system, realizing flexible switching between different candidate file systems and improving the flexibility of mounting the file system.

[0048] Figure 2 It is a flowchart of another method for mounting a file system according to an embodiment of the present disclosure. Refer to Figure 2 Based on the above embodiment, it is further limited that the method for mounting a file system in this embodiment may include:

[0049] S201, in response to a sub-query request for a file system directory in a mount request obtained from the user terminal, detect whether the sub-query request includes a token field;

[0050] S202, in the case of including the token field, extract the value of the token field from the sub-query request to obtain the target token;

[0051] S203, in the case of including the target token, query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes the target identifier of the target file system;

[0052] S204, feed back the target identifier to the user terminal, so that the user terminal uses the target identifier to access the target file system.

[0053] The user terminal can generate a mount request according to the target token specified by the user. The user terminal kernel can split the mount request into multiple sub-requests, such as a mount sub-request and a sub-query (lookup) request for each level directory of the file system, and send the sub-requests to the file system server in logical order.

[0054] During the process of the file system server handling a mount request, a root handler needs to be obtained during the mount sub-request handling phase. For example, to simplify the processing flow, a fixed root handler can be uniformly returned. This root handler is a handle for operating on the root directory, and subsequent operations by the client on the target file system may be based on this handle. During the processing phase of the sub-query request, it can be detected whether the sub-query request includes a specified token field, such as whether it includes "token=". If the token field is included, the value of the token field is used as the target token. Taking the sub-query request "token=9ed1608d" as an example, the target token is 9ed1608d. Exemplarily, the target token can be sent to the file system management module to query whether there is a target identifier associated with the target token, such as fsid=108, in the candidate authorization records of each candidate file system, and then the target identifier is fed back to the client so that the client can access the target file system using the target identifier.

[0055] By detecting and extracting the value of the specified token field as the target token during the process of the file system server handling the sub-query request, and querying the target identifier associated with the target token from the candidate authorization records of each candidate file system accordingly, the file system server can efficiently and accurately provide the client with the permission to access the target file system, simplifying the client access process and enhancing the security of the system.

[0056] In an alternative implementation, the target token is in the first-level directory of the file system in the mount request.

[0057] Among them, the mount request may include information such as the request type, protocol version, server address, file system directory, and mount point directory. The file system directory can be a multi-level directory structure for the file system, and the target token is placed in the first-level directory of the file system. The other-level directories of the file system can correspond to the actual directories in the target file system. Taking the file system directory "token=9ed1608d / dir1" as an example, the first-level directory "token=9ed1608d" includes the target token "9ed1608d", and the second-level directory: " / dir1" is an actual directory on the target file system. By placing the target token in the first-level directory of the file system, the file system server can first parse out the target token and feed back the target identifier associated with the target token to the client. Subsequently, the client uses the target identifier and the candidate information of the other-level directories to access the actual directory in the target file system.

[0058] In an alternative embodiment, feeding back the target identifier to the client and enabling the client to access the target file system using the target identifier includes: creating and feeding back a file handle to the client according to the target identifier, so that the client uses the target identifier as the parent file handle of a newly initiated sub-query request; and in response to the new sub-query request, accessing a corresponding directory in the target file system according to the target identifier.

[0059] Exemplarily, in the case where a sub-query request for a file system directory in a mount request includes a target token, query a target identifier associated with the target token and store the target identifier in a file handle returned to the client. For example, the target identifier can be backfilled into the FSAL handle (File System Abstraction Layer handle) of the file handle. When the client needs to initiate a new sub-query request for other-level directories of the file system, the target identifier can be used as the parent file handle (i.e., the parent directory parentfh) of the new sub-query request and sent to the file system server. The file system server uses the target identifier in the parent file handle to identify and locate the corresponding target file system, and then accesses the actual directory in the target file system in the backend storage module.

[0060] Still taking the following file system directory as an example: “token = 9ed1608d / dir1”. For the first-level directory “token = 9ed1608d”, the file system server determines that the target identifier fsid = 108 associated with the target token and stores the target identifier fsid = 108 in the file handle returned to the client. When the client initiates a new sub-query request for the second-level directory “ / dir1”, the target identifier fsid = 108 is used as the parent file handle of the new sub-query request. It should be noted that for sub-query requests for subsequent other-level directories, the target identifier fsid = 108 is also used as the parent file handle of the new sub-query request.

[0061] By storing the target identifier associated with the target token in the file handle fed back to the client, enabling the client to use the target identifier as the parent file handle for newly initiated sub-query requests for other-level directories of the file system, it is possible to quickly locate and access the actual directory in the target file system without repeatedly verifying and specifying the file system, thereby improving the efficiency and convenience of file access.

[0062] In the technical solution provided by the embodiments of the present disclosure, when a sub-query request for a file system directory includes a target token, by determining a target identifier associated with the target token, the target identifier is stored in the file handle fed back to the client, enabling the client to use the target identifier as the parent file handle for subsequent new sub-query requests initiated for other levels of directories in the file system, so that the actual directory in the target file system can be quickly located and accessed without repeatedly verifying and specifying the file system, thereby improving the efficiency and convenience of file access.

[0063] Figure 3a It is a flowchart of another file system mounting method provided according to the embodiments of the present disclosure. Refer to Figure 3a Based on the above embodiments, it is further limited that the file system mounting method of this embodiment may include:

[0064] S301, detecting whether the mount request obtained from the client includes a target token;

[0065] S302, in the case of including the target token, querying a target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes a target identifier of the target file system and a target operation type;

[0066] S303, feeding back the target identifier and the target operation type to the client, so that the client performs a corresponding target operation on the corresponding directory in the target file system by using the target identifier.

[0067] The target authorization record may not only include the target identifier, but also include a pre-authorized target operation type, such as read-only permission, or read-write permission, etc. That is to say, the association relationship between the candidate identifiers, candidate operation types, and candidate tokens of each candidate file system can be pre-stored in the database of the file system management module.

[0068] When the file system server detects that the mount request includes the target token, it queries the target identifier and target operation type associated with the target token from the association relationship among the candidate identifiers, candidate operation types, and candidate tokens, and feeds back the target identifier and target operation type to the client. After receiving the target identifier and target operation type, the client performs the following: accessing the corresponding directory in the target file system using the target identifier, and performing the corresponding target operation on the corresponding directory in the target file system using the target operation type. Specifically, if the target operation type is read-only, the client only performs read operations on the corresponding directory in the target file system and rejects write operations; if the target operation type is read-write, the client can perform both read and write operations on the corresponding directory in the target file system. By determining the operation type in the authorization record, the operation permissions of the client for the target file system can be precisely controlled. By determining the operation type in the authorization record, the operation permissions of the client for the target file system can be precisely controlled, avoiding unauthorized access and greatly improving the security of file access.

[0069] The technical solution provided by the embodiments of the present disclosure detects whether the mount request sent by the client includes the target token specified by the user. In the case of including the target token, by querying the target authorization record associated with the target token from the candidate authorization records of each candidate file system, the target identifier and target operation type associated with the target token are obtained, and the target identifier and target operation type are fed back to the client, enabling the client to precisely control the operation permissions for the target file system using the target identifier and target operation type, further enhancing the security of file access.

[0070] In an alternative embodiment, the target authorization record further includes a target expiration time; the method further includes: detecting whether the target token has expired according to the target expiration time; and rejecting the mount request in the case where the target token has expired.

[0071] The target authorization record may include not only the target identifier but also the target expiration time. That is to say, the association relationship among the candidate identifiers, candidate expiration times, and candidate tokens of each candidate file system can be pre-stored in the database of the file system management module.

[0072] When the file system server detects that the mount request includes the target token, it queries the target identifier and target expiration time associated with the target token from the association relationship among the candidate identifier, candidate expiration time, and candidate token, and detects whether the target token has expired based on the target expiration time; if the target token has expired, the mount request is rejected; if the target token has not expired, the target identifier is fed back to the client, enabling the client to access the corresponding directory in the target file system using the target identifier. By determining the expiration time in the authorization record, the file system server can accurately verify whether the target token in the mount request is still within the validity period, thus effectively preventing the illegal access to the target file system using an expired token and further enhancing the security of file access.

[0073] In an alternative embodiment, the method further includes: obtaining and storing the association relationship between the target authorization record and the target token from the management end; the target authorization record is generated in response to an access authorization application from the client for the target file system.

[0074] Reference Figure 3b , in addition to the client, file system server, backend storage module, and file system management module, the NFS file system may further include a management end, which is communicatively connected to the client and the file system management module respectively. Exemplarily, the client may send an access authorization application for the file system to the management end. The access authorization application includes at least the target file system directory to be accessed. After the administrator authorizes, a target token is generated, and the association relationship between the target token and the target authorization record is stored in the database of the file system management module, and the target token is fed back to the client for the client to access the target file system using the target token.

[0075] Among them, the access authorization application may further include the target operation type and / or target expiration time. The client may send an authorization access application including the target file system directory to be accessed, as well as the target operation type and / or target expiration time to the management end. The management end receives the authorization access application and authenticates the client. If the authentication is passed, a target access token is generated for the client, and the association relationship among the target file system directory, target access token, target operation type, and target expiration time is written into the database of the file system management module, that is, the association relationship between the target access token and the target authorization record is stored, and the target access token is fed back to the client.

[0076] The authorization access application of the client may also include at least one of a candidate file system directory, a candidate operation type, and a candidate valid time. When the management end's authentication is passed, a candidate access token is generated for the corresponding client, and the association relationship between the candidate file system directory, the candidate access token, the candidate operation type, and the candidate valid time is written into the database of the file system management module, obtaining the association relationship between the candidate access token and the candidate authorization record. Through the authorization application, only authorized users can access the corresponding file system directory, further enhancing the security and controllability of file access.

[0077] Figure 4 is a flowchart of a method for mounting a file system according to an embodiment of the present disclosure. This method is applicable to the situation where a user is allowed to mount to a specified network file system. This method can be executed by a mounting device of a file system, and the device can be implemented in a software and / or hardware manner and integrated into the client. As Figure 4 shown, the method for mounting a file system in this embodiment may include:

[0078] S401, generate a mounting request including a target token and send the mounting request to the file system server, so that when the file system server detects that the mounting request obtained from the client includes the target token, query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes the target identifier of the target file system;

[0079] S402, obtain the target identifier fed back by the file system server;

[0080] S403, access the target file system using the target identifier.

[0081] Among them, the NFS file system may include a client, a file system server, a backend storage module, and a file system management module. Among them, the file system server is communicatively connected to the client, the backend storage module, and the file system management module respectively. The backend storage module is used to store the directory information and file data of each candidate file system. In the database of the file system management module, the candidate authorization records of each candidate file system may be pre-stored, including at least the association relationship between the candidate identifier and the candidate token of the candidate file system. The candidate identifier is the file system identifier (File System ID, fsid), and a candidate file system may have different candidate authorization records for different users.

[0082] Exemplarily, a user can obtain a candidate token for accessing at least one candidate file system in advance. In the case where it is necessary to mount to one of the candidate file systems, i.e., the target file system, the corresponding target token can be written into the file system directory to obtain a mount request, and the mount request is sent to the file system server, so that the file system server detects whether the mount request includes the target token; in the case where the mount request includes the target token, the file system server can query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes at least the target identifier of the target file system. The user side obtains the target identifier fed back by the file system server and accesses the target file system using the target identifier. By writing the required target token into the mount request and sending the mount request containing the target token to the file system server, the file system server parses the target token from the mount request, queries the target authorization record associated with the target token from the candidate authorization records, obtains at least the target identifier associated with the target token, and feeds back the target identifier to the user side. Moreover, the user side accesses the corresponding directory in the target file system using the target identifier, realizing flexible switching between different candidate file systems and improving the flexibility of mounting the file system.

[0083] According to the technical solution provided by the embodiments of the present disclosure, the user side generates a mount request containing a specified target token and sends the mount request to the file system server, so that the file system server parses the target token from the mount request, queries the target authorization record associated with the target token from the candidate authorization records, obtains at least the target identifier associated with the target token, and feeds back the target identifier to the user side. Moreover, the user side accesses the corresponding directory in the target file system using the target identifier, realizing flexible switching between different candidate file systems and improving the flexibility of mounting the file system.

[0084] Figure 5 It is a flowchart of another method for mounting a file system according to an embodiment of the present disclosure. Refer to Figure 5 On the basis of the above embodiments, it is further limited that the method for mounting a file system in this embodiment may include:

[0085] S501, generate a mount request including a target token and send the mount request to the file system server, so that when the file system server detects that the mount request obtained from the user side includes the target token, query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes the target identifier of the target file system;

[0086] S502. Obtain a file handle including the target identifier, which is feedback by the file system server in response to a sub-query request for the file system directory in the mount request and including the target token.

[0087] S503. Use the target identifier as the parent file handle of the newly initiated sub-query request.

[0088] S504. Use the new sub-query request to access the corresponding directory in the target file system.

[0089] The client can generate a mount request according to the target token specified by the user. The client kernel can split the mount request into multiple sub-requests. Exemplarily, it can be split into a mount sub-request and sub-lookup requests for each level directory of the file system, and send the sub-requests to the file system server in logical order.

[0090] The client first sends a mount sub-request to the file system server to enable the file system server to obtain a root handler. For example, to simplify the processing flow, a fixed root handler can be uniformly returned. Subsequent operations of the client on the target file system may be based on this handle. The client can send a sub-query request to the file system server to enable the file system server to detect whether the sub-query request includes a specified token field, such as whether it includes "token=". If the token field is included, the value of the token field is used as the target token. Taking the sub-query request "token=9ed1608d" as an example, the target token is 9ed1608d. Exemplarily, the client can send the target token to the file system management module to query whether there is a target identifier associated with the target token, such as fsid=108, in the candidate authorization records of each candidate file system, so that the file system server feeds back the target identifier to the client, and the client accesses the target file system using the feedback target identifier.

[0091] Exemplarily, when the sub-query request sent by the client includes the target token, the file system server queries the target identifier associated with the target token and stores the target identifier in the file handle returned to the client. For example, the target identifier can be filled back into the FSAL handle (File System Abstraction Layer handle) of the file handle. When the client needs to initiate a new sub-query request for other-level directories of the file system, the target identifier can be used as the parent file handle (i.e., the parent directory parent fh) of the new sub-query request and sent to the file system server. The file system server uses the target identifier in the parent file handle to identify and locate the corresponding target file system, and then accesses the actual directory in the target file system in the backend storage module.

[0092] Still taking the following file system directory as an example: “token=9ed1608d / dir1”. The client sends a sub-query request for the first-level directory “token=9ed1608d”, causing the file system server to determine the target identifier fsid=108 associated with the target token and store the target identifier fsid=108 in the file handle returned to the client. When the client makes a new sub-query request for the second-level directory “ / dir1”, the target identifier fsid=108 can be used as the parent file handle of the new sub-query request. If there are subsequent other-level directories, when the client initiates a new sub-query request for other-level directories, the target identifier fsid=108 is also used as the parent file handle of the new sub-query request. By obtaining the target identifier associated with the target token from the file system server and using the target identifier as the parent file handle for subsequent new sub-query requests for other-level directories of the file system, the client can quickly locate and access the actual directory in the target file system without repeating the verification and specifying the file system, thereby improving the efficiency and convenience of file access.

[0093] For the technical solution provided by the embodiments of the present disclosure, the client can initiate a sub-query request for the file system directory and including the target token, causing the file system server to feedback the target identifier associated with the target token, and the client can use the target identifier as the parent file handle for subsequent new sub-query requests for other-level directories of the file system, so as to quickly locate and access the actual directory in the target file system without repeating the verification and specifying the file system, thereby improving the efficiency and convenience of file access.

[0094] In an alternative embodiment, the target token is located in the first-level directory for the file system in the mount request.

[0095] Among them, the mounting request may include information such as the request type, protocol version, server address, file system directory, and mounting point directory. The file system directory may be a multi-level directory structure for the file system, and the target token is placed in the first-level directory for the file system. The other-level directories of the file system may correspond to the actual directories in the target file system. Taking the following mounting request as an example: "mount -t nfs4 127.0.0.1 / token=9ed1608d / dir1 / home / temp", where the file system directory is "token=9ed1608d / dir1", the first-level directory "token=9ed1608d" includes the target token "9ed1608d", and the second-level directory: " / dir1" is an actual directory on the target file system. By placing the target token in the first-level directory for the file system, the file system server can first resolve the target token and feedback the target identifier associated with the target token to the client. Subsequently, the client uses the target identifier and the candidate other-level directory information to access the actual directory in the target file system.

[0096] In an alternative embodiment, the target authorization record further includes a target operation type; the obtaining of the target identifier fed back by the file system server includes: obtaining the target identifier and the target operation type fed back by the file system server; and according to the target operation type, allowing the client to perform a corresponding target operation on the target file system using the target identifier.

[0097] The target authorization record may include not only the target identifier but also the pre-authorized target operation type, such as read-only permission, or read-write permission, etc. That is to say, the database of the file system management module may pre-store the association relationships between the candidate identifiers, candidate operation types, and candidate tokens of each candidate file system.

[0098] When the file system server detects that the mount request includes the target token, it queries the target authorization record associated with the target token from the association relationship between the candidate tokens and the candidate authorization records. The target authorization record may include a target identifier and a target operation type. The client obtains the target identifier and the target operation type fed back by the file system server, accesses the corresponding directory in the target file system using the target identifier, and performs the corresponding target operation on the corresponding directory in the target file system using the target operation type. Specifically, if the target operation type is read-only, the client only performs read operations on the corresponding directory in the target file system and rejects write operations; if the target operation type is read-write, the client can perform read and write operations on the corresponding directory in the target file system. By determining the operation type in the authorization record, the operation permissions of the client for the target file system can be precisely controlled. By determining the operation type in the authorization record, the operation permissions of the client for the target file system can be precisely controlled, avoiding unauthorized access and greatly improving the security of file access.

[0099] In an alternative embodiment, the method further includes: sending an access authorization application for the target file system to the management end, causing the management end to authorize the generation of a target authorization record including the target token, establishing an association relationship between the target authorization record and the target token; and obtaining the target token fed back by the management end.

[0100] Among them, in addition to including a client, a file system server, a backend storage module, and a file system management module, the NFS file system may further include a management end, and the management end is communicatively connected to the client and the file system management module respectively. Exemplarily, the client may send an access authorization application for the file system to the management end. The access authorization application includes at least the target file system directory to be accessed. After the administrator authorizes, a target token is generated, and the association relationship between the target token and the target authorization record is stored in the database of the file system management module, and the target token is fed back to the client for the client to access the target file system using the target token.

[0101] Among them, the access authorization application may further include a target operation type and / or a target valid time. The client may send an authorization access application including the target file system directory to be accessed, as well as the target operation type and / or the target valid time to the management end. The management end receives the authorization access application, authenticates the client, and generates a target access token for the client in the case of successful authentication. The association relationship between the target file system directory, the target access token, the target operation type, and the target valid time is written into the database of the file system management module, that is, the association relationship between the target access token and the target authorization record is stored, and the target access token is fed back to the client.

[0102] Moreover, the authorization access application of the client includes at least one of a candidate file system directory, a candidate operation type, and a candidate valid time. When the authentication at the management end is passed, a candidate access token is generated for the corresponding client, and the association relationship among the candidate file system directory, the candidate access token, the candidate operation type, and the candidate valid time is written into the database of the file system management module, obtaining the association relationship between the candidate access token and the candidate authorization record. That is to say, the user can send an access authorization application to the management end through the client. The access authorization application includes at least the candidate file system directory to be accessed, and may also include the required candidate operation type and / or candidate valid time. After the authentication at the management end is passed, a candidate token is generated. For example, when the management end determines that the user has supervision authority over the candidate file system, a candidate token for the candidate file system can be generated for the user. The management end also feeds back the candidate token to the client so that the client can initiate a mounting request using the corresponding token; and, the association relationship between the candidate authorization record and the candidate token can be stored in the database of the file system management module. The candidate authorization record includes at least the candidate file system directory. Through the authorization application, only authorized users can access the corresponding file system directory, further improving the security and controllability of file access.

[0103] Figure 6 It is a schematic structural diagram of a mounting device for a file system provided according to an embodiment of the present disclosure. This device is applicable to the situation where a user is allowed to mount to a specified network file system. This device can be implemented in software and / or hardware and can be integrated into a file system server. As Figure 6 shown, the mounting device 600 of the file system in this embodiment may include:

[0104] A token detection module 610, configured to detect whether a target token is included in the mounting request obtained from the client;

[0105] A record query module 620, configured to, when the target token is included, query a target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes a target identifier of a target file system;

[0106] An identifier sending module 630, configured to feed back the target identifier to the client, so that the client accesses the target file system using the target identifier.

[0107] In an alternative embodiment, the target token is in the first-level directory of the file system in the mounting request.

[0108] In an alternative embodiment, the token detection module 610 includes:

[0109] A token field unit, configured to detect whether a token field is included in a sub-query request for a file system directory in a mounting request obtained from the client in response to the sub-query request.

[0110] A token extraction unit, configured to extract the value of the token field from the sub-query request to obtain the target token when the token field is included.

[0111] In an optional implementation manner, the identification sending module 630 includes:

[0112] A file handle unit, configured to create and feedback a file handle to the client according to the target identifier, so that the client uses the target identifier as the parent file handle of a new sub-query request initiated.

[0113] A directory access unit, configured to access a corresponding directory in the target file system according to the target identifier in response to the new sub-query request.

[0114] In an optional implementation manner, the target authorization record further includes a target operation type;

[0115] The identification sending module 630 is specifically configured to:

[0116] Feedback the target identifier and the target operation type to the client, so that the client allows to perform a corresponding target operation on a corresponding directory in the target file system using the target identifier.

[0117] In an optional implementation manner, the target authorization record further includes a target valid time; the mounting device 600 of the file system further includes:

[0118] A token invalidation module, configured to detect whether the target token is invalid according to the target valid time; and reject the mounting request when the target token is invalid.

[0119] 7. The device according to claim 1, the device further includes:

[0120] A record storage module, configured to obtain and store the association relationship between the target authorization record and the target token from the management end; the target authorization record is generated in response to an access authorization application of the client for the target file system.

[0121] The mounting device of the file system provided by the embodiments of the present invention can execute the mounting method of the file system provided by any embodiment of the present invention, and has corresponding functional modules and beneficial effects for executing the method.

[0122] Figure 7It is a schematic structural diagram of a mounting device for a file system provided according to an embodiment of the present disclosure. This device is applicable to the situation where a user is allowed to mount to a specified network file system. This device can be implemented in software and / or hardware and can be integrated into the user terminal. As Figure 7 shown, the mounting device 700 of the file system in this embodiment may include:

[0123] A mounting request module 710, configured to generate a mounting request including a target token and send the mounting request to the file system server, so that when the file system server detects that the mounting request obtained from the user terminal includes the target token, query the target authorization record associated with the target token from the candidate authorization records of each candidate file system; the target authorization record includes the target identifier of the target file system;

[0124] An identifier feedback module 720, configured to obtain the target identifier fed back by the file system server;

[0125] A file access module 730, configured to access the target file system using the target identifier.

[0126] In an alternative embodiment, the target token is located in the first-level directory of the file system in the mounting request.

[0127] In an alternative embodiment, the identifier feedback module 720 includes:

[0128] A file handle unit, configured to obtain a file handle including the target identifier fed back by the file system server in response to a sub-query request for the file system directory in the mounting request and including the target token;

[0129] The file access module 730 includes:

[0130] A new request initiation module, configured to use the target identifier as the parent file handle of the initiated new sub-query request;

[0131] A file access unit, configured to access the corresponding directory in the target file system using the new sub-query request.

[0132] In an alternative embodiment, the target authorization record further includes a target operation type;

[0133] The identifier feedback module 720 includes:

[0134] An identifier feedback unit, configured to obtain the target identifier and the target operation type fed back by the file system server;

[0135] A target operation unit, configured to allow the client to perform a corresponding target operation on the target file system by using the target identifier according to the target operation type.

[0136] In an alternative embodiment, the mounting device 700 of the file system further includes an access authorization module, and the access authorization module includes:

[0137] An authorization application unit, configured to send an access authorization application for the target file system to the management end, so that the management end authorizes and generates a target authorization record including a target token, and establishes an association relationship between the target authorization record and the target token;

[0138] A target token unit, configured to obtain the target token fed back by the management end.

[0139] The mounting device of the file system provided by the embodiments of the present invention can execute the file system mounting method provided by any embodiment of the present invention, and has function modules and beneficial effects corresponding to the execution method.

[0140] In the technical solution of the present disclosure, the acquisition, storage, and application of the user's personal information involved all comply with the provisions of relevant laws and regulations and do not violate public order and good customs.

[0141] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0142] Figure 8 It is a block diagram of an electronic device for implementing the file system mounting method of the embodiments of the present disclosure. Figure 8 FIG. shows a schematic block diagram of an exemplary electronic device 800 that can be used to implement the embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as, a laptop computer, a desktop computer, a workbench, a personal digital assistant, a server, a blade server, a mainframe computer, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as, a personal digital processor, a cellular phone, a smart phone, a wearable device, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0143] Such as Figure 8As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for the operation of the electronic device 800 can also be stored. The computing unit 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0144] Multiple components in the electronic device 800 are connected to the I / O interface 805, including: an input unit 806, such as a keyboard, a mouse, etc.; an output unit 807, such as various types of displays, speakers, etc.; a storage unit 808, such as a magnetic disk, an optical disc, etc.; and a communication unit 809, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0145] The computing unit 801 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include but are not limited to a central processing unit (CPU), a graphics processing unit (GPU) for material placement, various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 801 executes the various methods and processes described above, such as the file system mounting method. For example, in some embodiments, the file system mounting method can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the computing unit 801, one or more steps of the file system mounting method described above can be executed. Alternatively, in other embodiments, the computing unit 801 can be configured to execute the file system mounting method by any other appropriate means (e.g., by means of firmware).

[0146] Figure 8FIG. 0 shows a schematic block diagram of an exemplary electronic device 800 that may be used to implement embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as, for example, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as, personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely exemplary and are not intended to limit the implementations of the present disclosure described and / or claimed herein.

[0147] As Figure 8 shown, the electronic device 800 includes a computing unit 801 that may perform various appropriate actions and processes in accordance with a computer program stored in a read only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. In the RAM 803, various programs and data required for operation of the electronic device 800 may also be stored. The computing unit 801, the ROM 802, and the RAM 803 are connected to each other via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0148] A plurality of components in the electronic device 800 are connected to the I / O interface 805, including: an input unit 806, such as, for example, a keyboard, a mouse, etc.; an output unit 807, such as, for example, various types of displays, speakers, etc.; a storage unit 808, such as, for example, a magnetic disk, an optical disk, etc.; and a communication unit 809, such as, for example, a network card, a modem, a wireless communication transceiver, etc. The communication unit 809 allows the electronic device 800 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0149] The computing unit 801 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU) for material delivery, various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 executes the various methods and processes described above, such as the method for mounting a file system. For example, in some embodiments, the method for mounting a file system can be implemented as a computer software program that is tangibly embodied in a machine-readable medium, such as the storage unit 808. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 800 via the ROM 802 and / or the communication unit 809. When the computer program is loaded into the RAM 803 and executed by the computing unit 801, one or more steps of the method for mounting the file system described above can be executed. Alternatively, in other embodiments, the computing unit 801 can be configured to execute the method for mounting the file system in any other suitable manner (e.g., by means of firmware).

[0150] The various embodiments of the systems and techniques described above in this document can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SOCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special-purpose or general-purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit the data and instructions to the storage system, the at least one input device, and the at least one output device.

[0151] The program code for implementing the methods of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the program codes are executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program codes can be executed entirely on the machine, partially on the machine, as an independent software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0152] In the context of this disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0153] In order to provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, speech input, or tactile input).

[0154] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which the user can interact with an implementation of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), and the Internet.

[0155] A computer system can include a client and a server. The client and the server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

[0156] Artificial intelligence is a discipline that studies how to make computers simulate certain human thinking processes and intelligent behaviors (such as learning, reasoning, thinking, planning, etc.), including both hardware-level technologies and software-level technologies. Artificial intelligence hardware technologies generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, and big data processing; artificial intelligence software technologies mainly include several major directions such as computer vision technology, audio recognition technology, natural language processing technology, machine learning / deep learning technology, big data processing technology, and knowledge graph technology.

[0157] Cloud computing refers to a technical system that accesses an elastic and scalable shared physical or virtual resource pool through a network. The resources can include servers, operating systems, networks, software, applications, and storage devices, etc., and the resources can be deployed and managed in a on-demand and self-service manner. Through cloud computing technology, it can provide efficient and powerful data processing capabilities for the application of technologies such as artificial intelligence and blockchain and model training.

[0158] It should be understood that various forms of processes shown above can be used, steps can be reordered, added, or deleted. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved, and no limitations are imposed herein.

[0159] The above specific embodiments do not constitute a limitation to the protection scope of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the protection scope of this disclosure.

Claims

1. A method for mounting a file system, executed by a file system server, the method comprising: Check whether the mount request received from the user includes the target token; In the case where the target token is included, querying the target authorization record associated with the target token from the candidate authorization records of each candidate file system; The target authorization record includes a target identifier of the target file system; The target identifier is fed back to the user terminal, so that the user terminal uses the target identifier to access the target file system.

2. The method according to claim 1, wherein: The target token is in the mount request for the first level directory of the file system.

3. The method according to claim 1 or 2, wherein: The detecting whether the mount request obtained from the user terminal includes the target token includes: In response to a sub-query request for a file system directory in a mount request obtained from the user end, detecting whether the sub-query request includes a token field; In the case where the token field is included, the value of the token field is extracted from the sub-query request to obtain the target token.

4. The method according to claim 3, wherein: Feeding back the target identifier to the user terminal so that the user terminal uses the target identifier to access the target file system includes: Creating a file handle according to the target identifier and feeding back a file handle to the user end, so that the user end uses the target identifier as a parent file handle of a new sub-query request initiated; In response to the new sub-query request, a corresponding directory in the target file system is accessed according to the target identifier.

5. The method according to claim 1, wherein: The target authorization record also includes a target operation type; Feeding back the target identifier to the user terminal so that the user terminal uses the target identifier to access the target file system includes: The target identifier and the target operation type are fed back to the user terminal, so that the user terminal allows the target identifier to be used to perform the corresponding target operation on the corresponding directory in the target file system.

6. The method according to claim 1, wherein: The target authorization record also includes the target validity period; The method further includes: detecting whether the target token is invalid according to the target validity time; and rejecting the mount request when the target token is invalid.

7. The method according to claim 1, further comprising: Acquire and store the association relationship between the target authorization record and the target token from the management end; The target authorization record is generated in response to an access authorization application from the client to the target file system.

8. A method for mounting a file system, executed by a user terminal, the method comprising: Generate a mount request including a target token, and send the mount request to a file system server, so that the file system server, when detecting that the mount request obtained from the user terminal includes the target token, queries the target authorization record associated with the target token from the candidate authorization records of each candidate file system; The target authorization record includes a target identifier of the target file system; Obtaining the target identifier fed back by the file system server; The target file system is accessed using the target identifier.

9. The method according to claim 8, wherein: The target token is located in the first level directory for the file system in the mount request.

10. The method according to claim 8 or 9, wherein: The obtaining the target identifier fed back by the file system server includes: Obtaining a file handle including the target identifier fed back by the file system server in response to a subquery request for a file system directory in a mount request and including the target token; The step of using the target identifier to access the target file system comprises: Using the target identifier as the parent file handle of the initiated new subquery request; The new sub-query request is used to access the corresponding directory in the target file system.

11. The method according to claim 8, wherein: The target authorization record also includes a target operation type; The obtaining the target identifier fed back by the file system server includes: Acquire the target identifier and the target operation type fed back by the file system server; According to the target operation type, the user terminal is allowed to use the target identifier to perform a corresponding target operation on the target file system.

12. The method according to claim 8, further comprising: Sending an access authorization application for the target file system to the management end, so that the management end authorizes the generation of a target authorization record including a target token, and establishes an association relationship between the target authorization record and the target token; Obtain the target token fed back by the management end.

13. A file system mounting device, configured in a file system server, the device comprising: A token detection module, used to detect whether the mount request obtained from the user terminal includes a target token; A record query module, configured to query a target authorization record associated with the target token from candidate authorization records of each candidate file system when the target token is included; The target authorization record includes a target identifier of the target file system; The identifier sending module is used to feed back the target identifier to the user terminal, so that the user terminal uses the target identifier to access the target file system.

14. A file system mounting device, configured in a user terminal, comprising: A mount request module, configured to generate a mount request including a target token, and send the mount request to a file system server, so that the file system server, when detecting that the mount request obtained from the user terminal includes the target token, queries the target authorization record associated with the target token from the candidate authorization records of each candidate file system; The target authorization record includes a target identifier of the target file system; An identifier feedback module, used for obtaining the target identifier fed back by the file system server; The file access module is used to access the target file system using the target identifier.

15. An electronic device, comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 12.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to make a computer execute the method according to any one of claims 1-12.

17. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 12.

Images