File configuration method and device, electronic equipment and storage medium

Abstract

The invention discloses a file configuration method and device, electronic equipment and a storage medium, and relates to the technical field of computers, which comprises the steps of adopting a mode that a mounting command carries an independent configuration file path, so that each mounting point can be subjected to parameter customization based on an exclusive configuration file, and the limitation that all mounting points share the same set of configuration is avoided. Therefore, the technical problem that an existing distributed file system client side cannot be flexibly configured according to different service requirements can be solved, and the technical effects that differentiated configuration management is achieved according to the mounting points, the flexibility and adaptability of the system are improved, and diversified service requirements in a data center and a cloud computing scene are met are achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a file configuration method, device, electronic device, and storage medium. Background Art

[0002] With the rapid development of data centers and cloud computing, distributed file storage systems are widely used in various application scenarios. Kernel-mode clients, due to their high performance and direct system call compatibility, have become the mainstream access method for distributed file systems. Currently, distributed file system clients only support a global unified configuration file, where all mount points share the same set of parameters, preventing flexible configuration for different business needs. Summary of the Invention

[0003] The present application provides a file configuration method, device, electronic device and storage medium to at least solve the problem in the related art that the distributed file system client only supports a global unified configuration file, and all mount points share the same set of parameters, resulting in the inability to flexibly configure according to different business needs.

[0004] This application provides a file configuration method, including:

[0005] Obtain a mount command; wherein the mount command includes at least one configuration file path;

[0006] Parse the mount command and extract the configuration file path;

[0007] A mapping relationship between the configuration file corresponding to the configuration file path and the target mount point is established.

[0008] This application also provides a file configuration device, including:

[0009] An acquiring unit, configured to acquire a mount command, wherein the mount command includes at least one configuration file path;

[0010] A parsing unit, configured to parse the mount command and extract the configuration file path;

[0011] The establishing unit is used to establish a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point.

[0012] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned file configuration methods when executing the computer program.

[0013] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned file configuration methods are implemented.

[0014] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned file configuration methods when the computer program is executed by a processor.

[0015] This application uses a mount command with a separate configuration file path, allowing each mount point to be customized based on its own configuration file, thus avoiding the limitation of all mount points sharing the same configuration file. Therefore, it can solve the technical problem of existing distributed file system clients being unable to flexibly configure for different business needs, achieving differentiated configuration management based on mount points, improving system flexibility and adaptability, and meeting the diverse business needs of data center and cloud computing scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

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

[0018] Figure 2 A schematic diagram of the structure of a file configuration device provided by an embodiment of the present disclosure;

[0019] Figure 3 A schematic diagram of the structure of another file configuration device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0022] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0023] The embodiment of the present application provides a method for configuring a file. Figure 1 A flowchart of a file configuration method provided in an embodiment of the present application is shown as follows: Figure 1 As shown, the method comprises the following steps: Step 101, obtaining a mount command; wherein the mount command comprises at least one configuration file path;

[0024] In some embodiments, the mount command is generated by both manual user input and automated deployment tools. For manual user input, a command line tool can be used to add a configuration file path parameter to the standard mount command, such as using the command `mount -t dfs --config= / etc / dfs / configs / mysql-data.cfg / dev / sda1 / mnt / mysql-data` to explicitly specify the configuration file to use for mounting. Automated deployment tools can automatically generate a mount command that includes the path information by calling the mount API and setting a configuration file path reference field in the relevant configuration file.

[0025] The configuration file path can be included in the mount command through explicit parameter specification, environment variable reference, or configuration center index. The system intercepts the mount request by registering a file system operation hook on the kernel client, extracts the path parameter using the kernel parameter parser, and verifies the initiator's identity and permissions to obtain the mount command.

[0026] In some embodiments, when the mount command contains multiple configuration file paths, the system loads the configuration files sequentially according to the order of the parameters.

[0027] Step 102: Parse the mount command and extract the configuration file path;

[0028] When parsing the mount command and extracting the configuration file path, the command line parameters are split and processed, and the command is split into a parameter array according to separators such as spaces and equal signs. The parameters related to the configuration file path (such as parameters starting with "--config" or "-c") are traversed one by one to identify and extract the subsequent path string. At the same time, the relative path is normalized into an absolute path to ensure the accuracy of the path.

[0029] In some embodiments, after extracting the path, a validity verification is performed by calling the system interface to check whether the file pointed to by the path exists and whether the current process has read permission, and to filter paths containing illegal characters or symbolic links to prevent path traversal attacks. If the path verification passes, it is parsed into a data structure recognizable by the kernel according to the file format (such as JSON, YAML, INI, etc.), and the format and range of the parsed parameters are checked (such as verifying whether the numerical parameters are in a reasonable range). When the mount command contains multiple configuration file paths, the system loads them in order of parameters, and merges them using a strategy of overwriting the previous parameters with the same name with the later loaded configuration. If a conflict that cannot be automatically merged is encountered, the mount is refused and the user is prompted. The entire process is executed in kernel mode to ensure the accuracy and security of parameter parsing, laying the foundation for differentiated configuration management.

[0030] Step 103: Establish a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point.

[0031] In some embodiments, when establishing a mapping relationship between a configuration file and a target mount point, the system first creates a global mount point instance mapping table, which can be implemented using an efficient data structure such as a hash table or a red-black tree, to store the configuration information and status of all active mount points. It should be noted that this narrative method is only an exemplary description and is not a specific limitation on a specific data structure.

[0032] After parsing the mount command and extracting the legal configuration file path, the system creates an independent `mount_instance` structure instance for each mount point, stores the configuration file path and mount point path in the corresponding fields of the structure respectively, and uses a hash function or path prefix matching algorithm to insert the pointer of the structure instance as the value and the mount point path as the key into the global mapping table, thereby establishing the initial association between the configuration file and the mount point.

[0033] Through data structure optimization and algorithm design, performance and stability are guaranteed when processing a large number of concurrent mount requests and file operations, providing core support for implementing configuration-based differentiated mount point management.

[0034] In some embodiments, before establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes:

[0035] A mount instance body is created, and an association relationship is established between the mount instance body and the target mount point; wherein the mount instance body and the target mount point have a one-to-one correspondence.

[0036] In some embodiments, after parsing the mount command and extracting the valid configuration file path, the system dynamically generates an independent mount instance body (such as the kernel-state data structure `mount_instance`) for each target mount point. The instance body contains core information related to the mount point life cycle, such as the mount point path, configuration file path, parsed configuration parameter set, exclusive resource pointers (such as connection pool, cache manager handle), and status flags, etc.

[0037] In some embodiments, when establishing an association, the target mount point path is normalized (e.g., converting relative paths to absolute paths and removing redundant slashes) to generate a standardized path identifier. This identifier is then used as an index key to store the memory address or reference of the mount instance in the instance's associated field, forming a one-way mapping from "mount point path → instance." To ensure the uniqueness of the one-to-one correspondence, the system queries the global instance table before creating an instance. If an instance already exists associated with the target mount point, the duplicate creation is rejected and a conflict error is returned.

[0038] The mount instance body serves as the core carrier for subsequent configuration management and resource scheduling. The internally maintained associations provide the data foundation for subsequent steps: when it is necessary to establish a mapping between the configuration file and the mount point, simply write the parsed configuration file parameters into the corresponding fields of the instance body, and the target mount point can be quickly located through the instance body's associated path. When processing file operation requests, the system finds the corresponding mount point path through a path matching algorithm, and then obtains exclusive configuration parameters and resource handles through the instance body's association relationship to achieve differentiated operations.

[0039] Through an explicit instance creation and association mechanism, logical mount points are bound to physical configuration management units, providing a clear entity carrier for the establishment of subsequent mapping relationships, ensuring the precise correspondence between configuration data and mount point operations, avoiding the problem of multiple mount point configuration confusion at the underlying data structure level, and laying a key foundation for achieving fine-grained mount point isolation management.

[0040] In some embodiments, establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point includes:

[0041] Parse the configuration file path and obtain the configuration file corresponding to the configuration file path;

[0042] The configuration file is stored in the mount instance body corresponding to the target mount point.

[0043] In some embodiments, the configuration file path is first deeply parsed, and the configuration file content corresponding to the path can be read by calling the underlying file system interface (such as `open()` and `read()`), and the file content is syntactically parsed and semantically verified according to a preset format (such as JSON, YAML). At the same time, permission checks (ensuring that the current subject has read permissions) and integrity checks (such as hash value comparison) are performed to ensure that the configuration file is legal and credible.

[0044] After parsing is completed, the system will store the generated configuration parameters (such as permission rules, connection pool parameters, etc.) in the form of structured data in the exclusive field of the mount instance body corresponding to the target mount point (such as the kernel state `mount_instance` structure). The instance body establishes a unique association with the target mount point path through the global mapping table created in the early stage. During the storage process, if the mount command contains multiple configuration file paths, the system will parse and merge the configuration parameters in order of parameters. The later loaded configuration will overwrite the previous parameters with the same name to ensure that the final stored configuration is the latest valid version. It provides core data support for subsequent differentiated resource access and isolation management based on mount points, ensuring that the operation of each mount point can call its exclusive configuration parameters to avoid global configuration confusion.

[0045] In some embodiments, after storing the configuration file in the mount instance corresponding to the target mount point, the method further includes:

[0046] The system component is initialized based on the configuration file, so that the system component can access corresponding resources according to the configuration file associated with the target mount point.

[0047] The core goal of the system component initialization phase is to enable each system component (such as the connection pool, cache manager, authentication context, etc.) to dynamically generate a runtime entity that meets the business requirements of the mount point based on the content of the configuration file stored in the mount instance body, thereby achieving differentiated access to the corresponding resources.

[0048] The specific implementation process is as follows: extract the parsed configuration parameters (such as database connection string, cache capacity threshold, permission control rules, etc.) from the mounted instance body, and store these parameters in the form of key-value pairs or structured data in the exclusive fields of the instance body. Then, according to the preset component-parameter mapping rules, the system identifies the component type that needs to be initialized: if the configuration contains fields such as `db_host` and `db_port`, the initialization of the database connection pool component is triggered; if there are `cache_size` and `eviction_policy`, the creation logic of the cache manager component is started. It should be noted that this narrative method is only an exemplary explanation and is not a limitation on specific fields. The embodiments of this application do not limit this.

[0049] During initialization, each component instance establishes a strong association with the mounted instance. For example, the connection pool component creates a specified number of database connections based on the `max_connections` configuration parameter and stores the connection handle list in the instance's connection resource field. The authentication context component generates a corresponding permission verification function pointer based on the `allowed_users` or `token_secret` parameters and binds it to the instance's access control hook. For scenarios requiring cross-component collaboration (such as the cache manager relying on user identity information in the authentication context), the system initializes in dependency order to ensure that the call chain between components is legal and complete.

[0050] After initialization, each system component implements its functionality through the unified interface of the mounted instance: when a file operation request arrives, the system first locates the corresponding instance using the mount point path, then obtains the initialized component handle from the instance and calls the provided methods (such as `get_connection()` for the connection pool and `get_cache()` for the cache manager) to access the target resource. This design ensures that each component instance at a mount point can only access resources defined in its dedicated configuration file (such as a specific database or independent cache space), achieving complete isolation between different mount points in terms of connection, memory, permissions, and other dimensions.

[0051] In some embodiments, if the configuration file contains hot-updatable parameters, the initialized component will register for configuration change listeners. When the configuration parameters in the mount instance are updated, it will automatically reconfigure its own behavior (such as adjusting the connection timeout) without restarting the entire mount point service. Through this configuration-driven component initialization mechanism, the system converts abstract configuration file content into executable resource access logic, ensuring the independent operation of each mount point while enabling the flexible customization of component behavior based on business needs.

[0052] In some embodiments, before establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes:

[0053] Performing a permission check on the configuration file; wherein the permission check includes readability and integrity.

[0054] In some embodiments, the system verifies whether the current operating subject (such as the process or user initiating the mount) has permission to read the configuration file by calling the underlying file system interface (such as `stat()` or `access()`). For example, the system verifies whether the file permission bit contains `R` (read permission) or confirms through security policy (such as SELinux context) that the process has access to the path. If the file does not exist or the read permission is insufficient, the system will refuse to mount and return an error message (such as `EACCES`), avoiding subsequent process failures due to unreadable configuration files.

[0055] Perform integrity verification to ensure that the configuration file content has not been tampered with or damaged: The system supports multiple verification methods, such as hash verification (calculating a file's hash value, such as MD5 or SHA-256, and comparing it with a pre-stored value), digital signature verification (using a public key to verify a file's digital signature), or format verification based on file content (such as JSON / YAML syntax checking). For example, when the configuration file is published, its hash digest is generated and stored in a trusted location. Before mounting, the hash value is recalculated and compared. If there is a mismatch, the file is determined to have been tampered with, the mounting process is terminated, and an audit log is recorded. For binary configuration files, the system also checks the magic number or file header structure to ensure that the file format meets expectations.

[0056] After the permission check passes, a mapping relationship between the configuration file and the mount point is established. If any check item fails, the mount operation will be terminated immediately to prevent loading illegal or damaged configuration files and causing uncontrollable system behavior. This step ensures the legitimacy of the configuration file from a security perspective, preventing unauthorized users from tampering with the configuration (such as inserting malicious parameters) or configuration parsing errors caused by file corruption. It provides a reliable prerequisite for the creation of subsequent mount instances and the establishment of mapping relationships, ensuring that each mount point only loads trusted and complete configuration data, avoiding security risks and functional anomalies caused by configuration issues at the source.

[0057] In some embodiments, after establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes:

[0058] Storing the mapping relationship between the configuration file and the target mount point in a mount point instance mapping table;

[0059] When executing a file operation, the corresponding mount point instance is located from the mapping table based on the longest prefix matching rule of the configuration file path; wherein the file operation is executed in the context of the corresponding mount point instance.

[0060] This mapping information is stored in a globally maintained mount point instance mapping table, which can be implemented using data structures such as hash tables or prefix trees (Trie trees) to support fast path matching operations. During storage, the system normalizes the mount point paths (such as unifying path separators and removing redundant slashes), and stores the mapping relationship between the configuration file path and the mount point path as a key-value pair in the table. At the same time, it associates the corresponding mount instance body pointer to form an index relationship of "path→instance". To ensure thread safety, read and write operations of the mapping table are protected by spin locks or read-write locks to avoid data inconsistencies caused by concurrent mount / unmount operations.

[0061] When performing a file operation, the target mount point instance is located from the mapping table based on the longest prefix matching rule: first, the file operation path is decomposed hierarchically (such as ` / mnt / data / file.txt` is decomposed into prefixes such as ` / mnt`, ` / mnt / data`, etc.), and then the mapping table is searched in sequence starting from the longest prefix until a matching mount point path is found. For example, when accessing the path ` / mnt / data / file.txt`, the system will first check whether ` / mnt / data` is a mount point. If not, it will check ` / mnt` until the nearest mount point (such as ` / mnt`) is found. This matching strategy ensures accurate routing in nested mount scenarios (such as ` / mnt` and ` / mnt / data` are mounted on file systems with different configurations).

[0062] After locating the mount point instance, the context of the file operation is switched to the instance, including loading instance-specific configuration parameters, setting the mount point context pointer in thread-local storage (TLS), initializing resource access credentials, etc. For example, if the mount point is configured with specific access control rules (such as read-only permissions), the file operation will be executed under this constraint; if an independent cache policy is configured, the operation will prioritize hitting the cache space of the mount point. By binding the operation to the mount instance body, the system achieves resource isolation and configuration differentiation between different mount points, ensuring that each file operation only accesses the resources allowed by its mount point configuration, avoiding the confusion of permissions and resource contention in the traditional global configuration mode. The entire process is executed efficiently in kernel state, and through optimized path matching algorithms and memory access patterns, it ensures operational performance and stability in large-scale mount point scenarios.

[0063] In some embodiments, after establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes:

[0064] In response to a configuration change request, lock the mount instance to be changed;

[0065] The old configuration of the mount instance to be changed is saved, and the configuration file of the mount instance to be changed is updated.

[0066] Dynamically update the configuration of mounted instances to respond to changing business needs or system optimization. When a configuration change request is received, the system first locates the mounted instance to be modified using the global mount point instance mapping table and locks it exclusively using a mutex (such as a spinlock or semaphore) to prevent concurrent operations (such as file access requests) from modifying the instance's state. This locking mechanism ensures the atomicity of the configuration change process, preventing dirty reads and data inconsistencies.

[0067] Subsequently, the system performs a configuration backup operation: the current configuration parameters of the instance to be changed (such as connection pool size, cache strategy, permission rules, etc.) are completely copied to a temporary storage area to form a snapshot of the old configuration. This snapshot not only records the current values ​​of the configuration parameters, but also contains version information (such as timestamp or version number) so that it can be accurately rolled back when the change fails. After the backup is completed, the configuration file is updated: based on the new configuration content in the change request, the configuration parameter structure inside the mounted instance body is directly modified, or the new configuration file path is re-parsed and the original configuration data is overwritten. For configuration items that require external resources (such as database connection parameters), the system will first verify the validity of the new configuration (such as trying to establish a new connection) to ensure that the change does not cause service interruption.

[0068] After the configuration update is completed, the state transition of the mounted instance body is triggered: the instance is marked as "configuration updating", and the components that rely on the configuration (such as the cache manager and file access filter) are notified to make corresponding adjustments. For components that support hot updates, the system will dynamically refresh their operating parameters (such as adjusting the cache size and reloading permission rules); for components that must be restarted (such as certain network services), the system will arrange for restart first to ensure that existing connections can still be processed during the restart. Following the principle of "backup first, then verification, and then application", the system ensures the security and rollback of configuration updates through locking mechanisms and state management, and realizes dynamic adjustment of mount point configurations without interrupting services, significantly improving the flexibility and operation and maintenance efficiency of distributed file systems.

[0069] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0070] The embodiment of the present application also provides a file configuration device, Figure 2 A schematic diagram of a file configuration device provided by an embodiment of the present disclosure is shown in FIG. Figure 2 As shown,

[0071] The acquisition unit 21 is configured to acquire a mount command, wherein the mount command includes at least one configuration file path;

[0072] The parsing unit 22 is used to parse the mount command and extract the configuration file path;

[0073] The establishing unit 23 is configured to establish a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point.

[0074] Furthermore, in a possible implementation of the embodiment of the present disclosure, as Figure 3 As shown, the device also includes:

[0075] The creation unit 24 is used to create a mount instance body and establish an association relationship between the mount instance body and the target mount point before the establishment unit 23 establishes a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point; wherein the mount instance body corresponds to the target mount point one by one.

[0076] Furthermore, in a possible implementation of the embodiment of the present disclosure, the establishing unit 23 is further configured to:

[0077] Parse the configuration file path and obtain the configuration file corresponding to the configuration file path;

[0078] The configuration file is stored in the mount instance body corresponding to the target mount point.

[0079] Furthermore, in a possible implementation of the embodiment of the present disclosure, as Figure 3 As shown, the device also includes:

[0080] The initialization unit 25 is configured to initialize the system components based on the configuration file after the establishment unit 23 stores the configuration file in the mount instance corresponding to the target mount point, so that the system components can access corresponding resources according to the configuration file associated with the target mount point.

[0081] Furthermore, in a possible implementation of the embodiment of the present disclosure, as Figure 3 As shown, the device also includes:

[0082] The checking unit 26 is configured to perform a permission check on the configuration file before the establishing unit 23 establishes a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point; wherein the permission check includes readability and integrity.

[0083] Furthermore, in a possible implementation of the embodiment of the present disclosure, as Figure 3 As shown, the device also includes:

[0084] a storage unit 27 configured to store the mapping relationship between the configuration file and the target mount point corresponding to the configuration file path in a mount point instance mapping table after the establishing unit 23 establishes the mapping relationship between the configuration file and the target mount point;

[0085] The positioning unit 28 is used to locate the corresponding mount point instance from the mapping table based on the longest prefix matching rule of the configuration file path when performing a file operation; wherein the file operation is performed in the context of the corresponding mount point instance.

[0086] Furthermore, in a possible implementation of the embodiment of the present disclosure, as Figure 3 As shown, the device also includes:

[0087] a locking unit 29 configured to lock the mount instance to be changed in response to a configuration change request after the establishing unit 23 establishes a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point;

[0088] The updating unit 210 is configured to save the old configuration of the mount instance to be changed and update the configuration file of the mount instance to be changed.

[0089] For the description of the features in the embodiment corresponding to the file configuration device, please refer to the relevant description of the embodiment corresponding to the file configuration method, and no further details will be given here.

[0090] An embodiment of the present application further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned file configuration method embodiments.

[0091] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned file configuration method embodiments when running.

[0092] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0093] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned file configuration method embodiments are implemented.

[0094] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned file configuration method embodiments are implemented.

[0095] 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 above description has generally described the components and steps of each example according to their functions. 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 beyond the scope of this application.

[0096] The above is a detailed introduction to the configuration method, device, electronic device and storage medium of a file provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. 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 principles 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 claims of the present application.

Claims

1. A file configuration method, characterized in that: include: Obtain a mount command; wherein the mount command includes at least one configuration file path; Parse the mount command and extract the configuration file path; A mapping relationship between the configuration file corresponding to the configuration file path and the target mount point is established.

2. The file configuration method according to claim 1, characterized in that: Before establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes: A mount instance body is created, and an association relationship is established between the mount instance body and the target mount point; wherein the mount instance body and the target mount point have a one-to-one correspondence.

3. The file configuration method according to claim 2, characterized in that: The establishing of a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point includes: Parse the configuration file path and obtain the configuration file corresponding to the configuration file path; The configuration file is stored in the mount instance body corresponding to the target mount point.

4. The file configuration method according to claim 3, characterized in that: After storing the configuration file in the mount instance corresponding to the target mount point, the method further includes: The system component is initialized based on the configuration file, so that the system component can access corresponding resources according to the configuration file associated with the target mount point.

5. The file configuration method according to claim 1, characterized in that: Before establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes: Performing a permission check on the configuration file; wherein the permission check includes readability and integrity.

6. The file configuration method according to any one of claims 1 to 5, characterized in that: After establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes: Storing the mapping relationship between the configuration file and the target mount point in a mount point instance mapping table; When executing a file operation, the corresponding mount point instance is located from the mapping table based on the longest prefix matching rule of the configuration file path; wherein the file operation is executed in the context of the corresponding mount point instance.

7. The file configuration method according to any one of claims 1 to 5, characterized in that: After establishing a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point, the method further includes: In response to a configuration change request, lock the mount instance to be changed; The old configuration of the mount instance to be changed is saved, and the configuration file of the mount instance to be changed is updated.

8. A file configuration device, characterized in that: include: An acquiring unit, configured to acquire a mount command, wherein the mount command includes at least one configuration file path; A parsing unit, configured to parse the mount command and extract the configuration file path; The establishing unit is used to establish a mapping relationship between the configuration file corresponding to the configuration file path and the target mount point.

9. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the file configuration 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, wherein when the computer program is executed by a processor, the steps of the file configuration method according to any one of claims 1 to 7 are implemented.

Images