Configuration management method, electronic device, medium and product of network file system

Abstract

The present application discloses a configuration management method, electronic device, medium and product for a network file system, and relates to the technical field of network file systems. The method comprises obtaining a first file by parsing a configuration file and storing the parsed configuration information in a preset format. The preset format is used to indicate the memory layout of different configuration information and the memory layout of the different configuration information is continuous, so that the configuration file is converted into a precompiled first file, and the configuration information in the first file has a continuous memory layout. Therefore, when the content of the first file is loaded, the memory storing the loaded content is continuous, thereby reducing the memory fragmentation rate. Moreover, since the first file is obtained by pre-parsing the configuration file, when a configuration loading instruction is received, there is no need to parse the configuration file again, thereby avoiding the time-consuming parsing of the configuration file and improving the loading efficiency. Therefore, the technical problems of low configuration file loading efficiency and high memory fragmentation rate can be solved.

Description

Technical Field

[0001] The present application relates to the technical field of network file systems, and in particular to a configuration management method, electronic equipment, medium, and product of a network file system. Background Art

[0002] As a core component of distributed storage, the Network File System (NFS) and its configuration management mechanisms directly impact system performance and operational efficiency. With the widespread adoption of cloud computing and hyperscale data centers, the number of export rules in a single cluster has surged from dozens to tens of thousands, and a single export block may contain hundreds of nested member (client) rules. Currently, NFS configuration rules are typically written into a text-based configuration file, which is then parsed and loaded at system startup to complete the configuration.

[0003] However, in related technologies, when parsing configuration files, recursive descent syntax analysis is mainly used. The parsing time of this parsing method increases superlinearly with the number of rules in the configuration file, the loading efficiency is low, and independent memory objects are dynamically allocated for each configuration item during parsing, which easily leads to a high memory fragmentation rate. Summary of the Invention

[0004] The present application provides a configuration management method, electronic device, medium and product for a network file system, so as to at least solve the problems of low configuration file loading efficiency and high memory fragmentation rate in the related art.

[0005] This application provides a configuration management method for a network file system, including:

[0006] In response to the configuration loading instruction, obtaining a first file, the first file being obtained by parsing a configuration file of a network file system and storing configuration information obtained by parsing the configuration file in a preset format, the preset format being used to indicate a memory layout of different configuration information, wherein the memory layout of the different configuration information is continuous, and configuration information in a nested relationship corresponds to a continuous memory block;

[0007] Loading the content of the first file into the target memory;

[0008] Memory access is performed according to the first address of the target memory and the memory layout to read the configuration information.

[0009] The present application also provides a configuration management device for a network file system, comprising:

[0010] an acquisition module, configured to acquire a first file in response to a configuration loading instruction, wherein the first file is obtained by parsing a configuration file of a network file system and storing configuration information obtained by parsing the configuration file in a preset format, wherein the preset format is used to indicate a memory layout of different configuration information, wherein the memory layout of the different configuration information is continuous, and configuration information in a nested relationship corresponds to a continuous memory block;

[0011] A loading module, configured to load the contents of the first file into a target memory;

[0012] An access module is used to perform memory access according to the first address of the target memory and the memory layout to read the configuration information.

[0013] 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 network file system configuration management methods when executing the computer program.

[0014] 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 network file system configuration management methods are implemented.

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

[0016] Through the present application, since the first file is obtained by parsing the configuration file and storing the configuration information obtained by parsing the configuration file in a preset format, the preset format is used to indicate the memory layout of different configuration information and the memory layout of different configuration information is continuous, and the configuration information with a nested relationship corresponds to a continuous memory block, so that the configuration file is converted into a pre-compiled first file, and the configuration information in the first file has a continuous memory layout, so that when the content of the first file is loaded, the memory storing the loaded content is continuous, which reduces the memory fragmentation rate and helps to improve the utilization rate of memory resources. Moreover, since the first file is obtained by pre-parsing the configuration file, when the configuration loading instruction is received, the existing first file can be directly loaded into the memory without parsing the configuration file again, thereby avoiding the time-consuming parsing of the configuration file and improving the loading efficiency. Therefore, the technical problems of low configuration file loading efficiency and high memory fragmentation rate can be solved, and the technical effect of improving configuration loading efficiency and reducing memory fragmentation rate can be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] 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.

[0018] Figure 1 A schematic diagram of the BPCC system architecture for implementing a configuration management method for a network file system provided by an exemplary embodiment of the present application;

[0019] Figure 2 A flowchart of a method for configuring and managing a network file system provided in an embodiment of the present application;

[0020] Figure 3 A schematic diagram of a binary format of an exemplary embodiment of the present application;

[0021] Figure 4 This is a schematic diagram of a binary file loading process according to an exemplary embodiment of the present application;

[0022] Figure 5 A flowchart of another method for configuring and managing a network file system provided in an embodiment of the present application;

[0023] Figure 6 A schematic diagram of a binary file generation process according to an exemplary embodiment of the present application;

[0024] Figure 7 A flowchart of another method for configuring and managing a network file system provided in an embodiment of the present application;

[0025] Figure 8 This is a timing diagram of difference merging according to an exemplary embodiment of the present application;

[0026] Figure 9 A flowchart of another method for configuring and managing a network file system provided in an embodiment of the present application;

[0027] Figure 10 A schematic diagram of the structure of a configuration management device for a network file system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0028] 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.

[0029] 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.

[0030] With the prevalence of cloud computing and hyperscale data centers, the number of export rules in a single cluster has skyrocketed from dozens to tens of thousands. For example, the open-source NFS implementation of the Ganesha file server requires complex configuration files, including access control lists (ACLs), storage backend parameters like the File System Abstraction Layer (FSAL), and protocol options. A single export block can contain hundreds of nested client rules. Currently, NFS configuration is typically managed using text-based configuration, which presents the following systemic challenges:

[0031] (1) Low parsing efficiency

[0032] Configuration parsers generally use a Flex / Bison combination for recursive descent parsing, resulting in a time complexity of O(n²) (n is the number of rules), with parsing time scaling superlinearly with the number of rules. Furthermore, nested structures (such as export nesting FSAL and client) lead to excessive syntax tree depth, consuming significant stack space and impacting parsing efficiency.

[0033] (2) Memory fragmentation

[0034] The text-based configuration management solution dynamically allocates a separate memory object (such as structexport_entry) for each configuration item. Actual measurement data shows that when the configuration size reaches 100,000, the memory fragmentation rate exceeds 35%, resulting in a decrease in effective memory capacity and a surge in garbage collection (GC) pressure.

[0035] (3) Dynamic update delay

[0036] Current systems, such as NFS-Ganesha, rely on a full reload model: even if only a single client IP address is modified, the entire configuration file must be reparsed and the in-memory structure rebuilt. In ultra-large clusters, reload delays of minutes make it difficult to meet business continuity requirements, such as real-time permission changes in financial trading systems.

[0037] Several solutions currently exist to address these issues, but they don't effectively address them. For example, related technology 1: database-based configuration management. Specifically, configurations are stored in SQLite or Redis databases and dynamically loaded through query interfaces. However, this management approach can reduce loading speed by 30% due to database query latency (average 2-5ms per query), and there's object conversion overhead. Deserialization from database records to memory objects consumes over 40% of CPU time. Related technology 2: parallel text parsing. Specifically, configuration files are split into multiple segments, parsed in parallel by different threads, and the results are merged. However, this approach suffers from syntax dependency conflicts. Nested blocks (such as EXPORT{ FSAL{ ...}}) create strong dependencies between threads. Amdahl's law limits parallel efficiency to less than 20%. Furthermore, there's merging overhead. Cross-segment object references require complex pointer relocation, and the merging phase accounts for over 60% of the time. Related technology three: Configuration templates and sharding. Specifically, large files are split into multiple sub-files through the %include directive and loaded on demand. However, this method does not touch the parsing logic, and the sub-files still need to be fully parsed. The total time consumption is not significantly reduced, and the management complexity is high. The variable scope between shards can easily lead to configuration errors (such as global parameter overwriting).

[0038] In response to the problems existing in the above-mentioned related technologies, this application provides a configuration management solution for a network file system based on a binary precompiled cache, aiming to solve the problems of how to achieve millisecond-level full loading in large-scale configuration scenarios, how to support dynamic updates and avoid full parsing. This solution converts the configuration file into a compact binary format (.bconf) file through the Binary Precompiled Configuration Cache (BPCC). Its memory layout is consistent with the runtime data structure, and the binary file is directly mapped to the memory address space through memory mapping (MMap) technology to accelerate access, skipping the parsing step, which can significantly improve loading efficiency. In addition, through compact memory mapping, it can reduce memory fragmentation and increase effective memory capacity, reduce memory usage by 40%, reduce CPU peak load by 70%, and significantly optimize system resources. In addition, by generating a binary patch file based on the difference part of the configuration file, only the changed part is updated, realizing dynamic differential update, and the configuration reload time after the process restart is shortened from minutes to seconds.

[0039] 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.

[0040] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the configuration management method of the network file system depends, the specific application environment architecture or specific hardware architecture is described herein.

[0041] Figure 1 A schematic diagram of the BPCC system architecture for implementing a configuration management method for a network file system provided by an exemplary embodiment of the present application is shown in FIG. Figure 1 As shown in the figure, the BPCC system architecture includes a configuration compiler, a cache manager, and a runtime loader. The configuration compiler is responsible for parsing text configuration files and converting them (such as ganesha.conf) into binary files (.bconf) through a series of operations, including syntax parsing, memory layout alignment, serialization, and compression. Its input is the original text configuration file and a user-defined compilation strategy (such as a selectable compression algorithm). Its output is a binary file with complete metadata (such as version number, timestamp, checksum, etc.). The cache manager is responsible for the lifecycle management of binary files, including version control, verification, compression optimization, and storage strategy. During compression optimization, the compression algorithm is dynamically adjusted based on hardware resources: the low-latency LZ4 algorithm is used on low-end devices (such as ARM embedded devices), while the high-compression Zstd algorithm is used in storage-intensive scenarios (such as cloud servers). The runtime loader uses zero-copy technology (such as MMap) to map binary files directly to memory, achieving instantaneous configuration loading. The loading process does not require the intervention of a parser. The corresponding configuration can be read directly by accessing the configuration data structure through a pointer. Magic number and version verification are performed before memory access. If the verification is successful, memory access can be performed directly. Otherwise, the text configuration parsing process is triggered. An atomic update mechanism is also provided to ensure that the service is unaware of dynamic configuration switching.

[0042] The embodiments of the present application provide a configuration management method for a network file system. The method is described in detail in conjunction with the execution flow of the configuration management method for a network file system.

[0043] Figure 2 This is a flow chart of a method for configuration management of a network file system provided in an embodiment of the present application. The method can be executed by the device for configuration management of a network file system provided in an embodiment of the present application and can be integrated into an electronic device.

[0044] like Figure 2 As shown, the configuration management method of the network file system includes the following steps:

[0045] Step 101: In response to a configuration loading instruction, a first file is obtained. The first file is obtained by parsing a configuration file of a network file system and storing configuration information obtained by parsing the configuration file in a preset format. The preset format is used to indicate the memory layout of different configuration information, and the memory layout of different configuration information is continuous. Configuration information with a nested relationship corresponds to a continuous memory block.

[0046] In this embodiment, the first file is obtained by parsing the configuration file and storing the configuration information obtained by parsing the configuration file in a preset format. For example, after the user configures the configuration file, that is, through Figure 1 The configuration compiler shown converts the configuration file into a first file and stores it.

[0047] In an optional embodiment of the present application, the preset format is a binary format, and the first file is a binary file obtained by parsing the configuration file and storing the parsed configuration information in the binary format. The binary format defines a memory layout corresponding to different configuration information, and the memory layout is continuous, so that the binary file obtained by storing the configuration information in the binary format has a continuous memory layout, and nested structures are also converted into continuous memory blocks.

[0048] For example, Figure 3 This is a schematic diagram of a binary format of an exemplary embodiment of the present application, such as Figure 3 As shown, the binary format defines the data structure of the header, export block, and trailer. For the header, the offset, character length, and corresponding description information of the Magic Number field, Version field, Timestamp field, and Export Count field are defined; for the export block, the memory size occupied by the export block ID, the memory size (bytes) occupied by the path length, the memory size occupied by the number of client rules, and the client rule array nested under the export block are defined; for the trailer, the offset of the Cyclic Redundancy Check (CRC) field, the Compression algorithm identifier (Compression) field, and the Reserved field, as well as the corresponding description information of each field are defined. Figure 3 It can be seen that the binary format indicates the memory layout of different configuration information, and the memory layout of different configuration information is continuous. Therefore, when the configuration information is stored in the binary format, the memory occupied by each configuration information is connected, which can reduce the memory fragmentation rate.

[0049] In this embodiment, when a configuration load instruction is received, such as when the device is started or restarted, the configuration load instruction is triggered. In response to the configuration load instruction, the system first detects whether the first file exists on the disk. If so, the system retrieves the first file and performs the subsequent step of mapping the first file to the memory. If the system detects that the first file does not exist, the system triggers a configuration file parsing process to generate a corresponding binary file, which is then loaded into the memory. By converting the configuration file to the first file and then loading it into the memory when the first file is not detected, rather than directly loading the configuration file, the system can map the configuration information to a continuous memory space when loading the configuration, reducing memory fragmentation and facilitating the direct loading of the first file after a subsequent system restart.

[0050] Step 102: Load the content of the first file into the target memory.

[0051] In this embodiment, if the first file is obtained, it can be obtained by Figure 1 The runtime loader in [ 15 ] maps the first file directly to memory, thereby loading the contents of the first file into the target memory, where the target memory refers to the memory space storing the contents of the first file. When mapping the first file to memory, the runtime loader automatically allocates a larger block of memory with a known first address. Starting from this first address, the contents read from the first file are sequentially stored, allowing the contents of the first file to be stored in a continuous memory space.

[0052] For example, MMap can be used to map the first file into memory. The MAP_POPULATE flag of MMap is used to preload the binary file into physical memory to avoid page fault interrupts during the first access. Madvise (MADV_SEQUENTIAL) is used to prompt the kernel to pre-read the file content to improve sequential access performance.

[0053] Step 103: Perform memory access according to the first address and memory layout of the target memory to read the configuration information.

[0054] The first address of the target memory is known to the runtime loader.

[0055] In this embodiment, since the preset format indicates the memory layout of different configuration information, the memory layout reflects the offset of each configuration information and / or the size of the memory occupied. Therefore, based on the first address of the target memory and the memory layout of the configuration information, the storage space address of the configuration information in the memory can be determined, and then the storage space address can be directly accessed through a pointer to read the configuration information from the memory without parsing.

[0056] Exemplarily, when the export rules of an export block need to be read, the export rules are directly located by pointer arithmetic as follows:

[0057] struct bin_export *exp = (struct bin_export *)((char *)header +sizeof(struct bin_header) + i * sizeof(struct bin_export)).

[0058] The configuration management method of the network file system in the embodiment of the present application parses the configuration file and stores the configuration information obtained by parsing the configuration file in a preset format to obtain a first file. The preset format is used to indicate the memory layout of different configuration information and the memory layout of different configuration information is continuous. The configuration information with a nested relationship corresponds to a continuous memory block, so that the configuration file is converted into a pre-compiled first file, and the configuration information in the first file has a continuous memory layout. Therefore, when the content of the first file is loaded, the memory storing the loaded content is continuous, which reduces the memory fragmentation rate and helps to improve the utilization rate of memory resources. Moreover, since the first file is obtained by pre-parsing the configuration file, when the configuration loading instruction is received, the existing first file can be directly loaded into the memory without parsing the configuration file again, thereby avoiding the time-consuming parsing of the configuration file and improving the loading efficiency. Therefore, the technical problems of low configuration file loading efficiency and high memory fragmentation rate can be solved, and the technical effect of improving configuration loading efficiency and reducing memory fragmentation rate can be achieved.

[0059] In an optional embodiment of the present application, the first file includes a header and a trailer. The header includes a magic number and a file version number. The magic number is a preset value that indicates the file type. Checking whether the magic number is the preset value can prevent file type errors. For example, the magic number can be set to a fixed value of "0x4E465347" (corresponding to "NFSG" in ASCII). The trailer includes a full-file checksum, which indicates the integrity of all information in the first file except the trailer data. The full-file checksum can be determined based on all information in the first file except the trailer data. For example, it can be calculated using a hash function, CRC32, or other algorithm on the header and all derived blocks of the first file. These fields can be used to verify the compatibility and integrity of the first file, thereby ensuring the normal loading of the configuration. Therefore, in this embodiment, before performing memory access, the loaded first file can be verified based on the magic number, file version number, and full-file checksum. Memory access can only be performed after successful verification.

[0060] Specifically, it is possible to first detect whether the magic number is a preset value. If it is detected that the magic number is a preset value, then based on the preset compatibility rules, it is detected whether the file version number is compatible with the current program. The compatibility rule can be a pre-set custom rule used to indicate which version of the file the current program is compatible with. When the file version number in the header is consistent with the text version number set in the compatibility rule, it is determined that the version of the first file is compatible with the current program, otherwise it is considered incompatible. When compatibility is determined, an integrity check is further performed based on the full file check code. For example, the full file check code is calculated using the CRC32 algorithm. The CRC32 check code of the header and the export block in the first file content is calculated, and the calculated result is compared with the full file check code in the tail to detect whether the data is damaged. If the two are consistent, it is considered that the data is not damaged and the integrity check passes. At this point, the first file check is successful and memory access can be performed.

[0061] In an embodiment of the present application, by detecting whether the magic number is a preset value, it is possible to identify whether the type of the first file is incorrect; by detecting whether the file version number is compatible with the current program, it is possible to detect the compatibility of the first file with the current program; by performing a loop integrity check based on the full-file checksum, it is possible to detect whether the first file has data corruption problems, thereby ensuring the integrity of the first file. Through the above-mentioned detection, the correctness, compatibility and integrity of the first file can be ensured, thereby ensuring the normal progress of configuration loading.

[0062] Furthermore, in an optional embodiment of the present application, if the magic number is not a preset value, it is determined that the binary file has an incorrect file type. In this case, the file may be marked as damaged and a configuration file parsing process may be triggered to obtain a second file. Alternatively, if it is detected that the file version number is incompatible with the current program, a configuration file parsing process may be triggered to obtain the second file. Alternatively, if the integrity check fails, it may be determined that the first file has data corruption. In this case, the configuration file parsing process may also be triggered to obtain the second file. It is understood that the second file is also obtained by parsing the configuration file of the network file system and storing the configuration information obtained by parsing the configuration file in a preset format.

[0063] For example, if the preset format is binary format and the first file is a binary file, Figure 4 This is a schematic diagram of a binary file loading process of an exemplary embodiment of the present application, as shown in FIG. Figure 4As shown, when loading the configuration, the system first checks whether a binary file (.bconf file) exists. If not, the configuration file parsing process is triggered to generate the binary file. If a binary file is detected, it is mapped to memory and the magic number is checked to see if it matches the preset value. If not, it is marked as corrupted and the configuration file parsing process is triggered. If it matches, the system checks whether the file version number is compatible. If not, the configuration file parsing process is triggered. If so, the system further verifies whether the full file checksum matches. If not, the configuration file parsing process is triggered. If so, direct memory access is performed to read the corresponding configuration information.

[0064] In an optional implementation of the present application, the preset format is a binary format, and the first file is a binary file, such as Figure 5 As shown, based on the above embodiment, the step of obtaining the first file may include the following sub-steps:

[0065] Step 201: Call a text parser to parse the configuration file and generate a configuration syntax tree.

[0066] The text parser may adopt a currently commonly used file parser, such as Flex and Bison.

[0067] In this embodiment, a file parser is called to parse the configuration file, and a configuration syntax tree in memory can be generated.

[0068] Step 202: Flatten the configuration syntax tree and convert the nested structure in the configuration syntax tree into a continuous memory block.

[0069] Among them, flattening processing refers to converting a multi-layer nested data structure into a single-layer data structure for easier processing and analysis.

[0070] In this embodiment, by flattening the configuration syntax tree, nested structures in the configuration syntax tree (such as Export{ client{ ...}}) can be converted into continuous memory blocks, thereby eliminating the cache miss problem caused by pointer jumps.

[0071] For example, if a single export rule in a configuration file includes multiple nested client rules, the parsed configuration syntax tree contains multiple client nodes under one export node. This can be flattened according to the preset export and client data structures. For example, the export and client data structures are as follows:

[0072] struct bin_export{ / / single shared configuration

[0073] uint32_texport_id; / / Export ID

[0074] uint32_tpath_len; / / path string length

[0075] charpath[path_len]; / / path string

[0076] uint32_tnum_clients; / / Number of clients

[0077] bin_client clients[num_clients]; / / client list

[0078] / / Other parameters (Access_type, etc.)

[0079] };

[0080] struct bin_client{ / / single client configuration

[0081] uint8_tip_type; / / IP type (IPv4=0, IPv6=1)

[0082] union {

[0083] uint32_t ipv4; / / IPv4 address (binary format)

[0084] uint8_t ipv6

[16] ; / / IPv6 address

[0085] };

[0086] uint32_t netmask; / / Subnet mask (valid only for IPv4)

[0087] };

[0088] Step 203: Perform memory alignment detection on the continuous memory blocks according to a preset alignment strategy.

[0089] Among them, the alignment strategy is used to indicate the number of bytes of memory alignment, which can be set according to actual needs. Different platforms use different alignment strategies, such as 4-byte alignment and 8-byte alignment.

[0090] In this embodiment, after flattening the configuration syntax tree, memory alignment can be checked for contiguous memory blocks according to a preset alignment strategy. A binary memory layout (structbin_export) that is completely consistent with the runtime object can be defined to ensure that field offsets and byte order match the target platform.

[0091] For example, memory alignment detection can be performed using the following code:

[0092] size_t current_offset = 0;

[0093] for (each field) {

[0094] if (current_offset % field_alignment != 0) {

[0095] / / Pad with blank bytes to satisfy alignment

[0096] pad_bytes = field_alignment - (current_offset % field_alignment);

[0097] write_padding(pad_bytes);

[0098] current_offset += pad_bytes;

[0099] }

[0100] write_field(field_data);

[0101] current_offset += sizeof(field_data);

[0102] }

[0103] In the above code, field_alignment represents the number of memory alignment bytes indicated in the alignment policy.

[0104] In this embodiment, memory alignment is performed so that the binary file is forced to be aligned with 4K and 8K pages, which can prevent MMap from being abnormal and ensure that MMap can be directly converted into a structure pointer after mapping.

[0105] In an optional implementation of the present application, when memory misalignment is detected, the process of generating the binary file is terminated and the mode returns to the text configuration management mode.

[0106] Step 204 : If the memory alignment test passes, the configuration information of the configuration syntax tree and the continuous memory blocks are stored in a binary format to obtain a binary file corresponding to the configuration file.

[0107] In this embodiment, if the memory alignment test passes, the configuration information of the configuration syntax tree and the continuous memory blocks are stored in a preset binary format to obtain a binary file.

[0108] In an optional embodiment of the present application, a binary format includes a header memory layout, an export block memory layout, and a trailer memory layout. When generating a binary file according to the binary format, global and shared configuration information can be obtained based on the configuration syntax tree. The shared configuration information includes configuration information for multiple export blocks (export rules). The configuration information for each export block includes block header information such as the export block ID and path string, as well as the client belonging to the export block. The global configuration information can be stored according to the header memory layout. For each export block, each of the multiple export blocks can be traversed, and the block header information of the currently traversed export block and the contiguous memory blocks corresponding to the member rules associated with the currently traversed export block can be stored according to the export block memory layout. After traversing multiple export blocks, a cyclic redundancy check code (CRC32) of the currently stored information is calculated, namely, a CRC32 check code of the stored header data and the data of all export blocks is calculated, and this CRC code is stored according to the trailer memory layout as a full-file check code. Optionally, an incremental write method can be adopted, with each completed export block being written to disk to avoid the risk of full memory cache overflow.

[0109] Since the binary format defines the memory size occupied by different fields, in order to prevent data overflow, the data of non-index fields can be compressed and stored, wherein the non-index fields can be pre-set according to actual needs, for example, the non-index fields include path strings. In an optional embodiment of the present application, the block header information includes a path string, and the path string can be compressed and stored. Thus, when the block header information of the currently traversed export block is stored according to the export block memory layout, the path string of the currently traversed export block (for ease of description and distinction, referred to as the initial path string) can be obtained from the configuration information of multiple export blocks; then, the target compression algorithm is determined according to the current device type, wherein the device type can include embedded and server. For example, if the current device is a low-end device such as an ARM embedded device, the target compression algorithm is determined to be the low-latency LZ4 algorithm. If the current device is a device in a storage-intensive scenario such as a server, the target compression algorithm is determined to be the high-compression ratio Zstd algorithm. Next, the initial path string is compressed using the current compression algorithm to obtain a compressed path string. This compressed path string is then used as the path string for the currently traversed export block and stored according to the export block memory layout. In other words, when storing the path string according to the export block memory layout, the initial path string in the configuration file is first compressed before being stored in the binary file. It should be noted that in this embodiment, during compression, individual export blocks are compressed independently, supporting random access. Path compression for multiple export blocks can be performed in parallel (implying the "parallel for" semantics) to improve compression efficiency.

[0110] In an embodiment of the present application, by determining the target compression algorithm according to the current device type, a compression algorithm that is more suitable for the current device can be selected for compression to ensure the compression effect. By using the determined target compression algorithm to compress the initial path string and writing the compressed path string obtained by compression, the memory occupied by the path string can be reduced, avoiding the situation where the path string overflows the corresponding memory space when it is long.

[0111] The configuration management method of the network file system in the embodiment of the present application parses the configuration file by calling a text parser to generate a configuration syntax tree, flattens the configuration syntax tree, converts the nested structure in the configuration syntax tree into a continuous memory block, and performs memory alignment detection on the continuous memory block according to a preset alignment strategy. Through the memory alignment detection, it is possible to prevent MMap from having anomalies and ensure that MMap can be directly converted into a structure pointer after mapping; when the memory alignment detection passes, the configuration information and the continuous memory block of the configuration syntax tree are stored in a binary format to obtain a binary file corresponding to the configuration file, thereby realizing the conversion of the configuration file into a memory-continuous binary file, providing data support for achieving efficient configuration.

[0112] Figure 6 This is a schematic diagram of a binary file generation process of an exemplary embodiment of the present application, as shown in FIG. Figure 6 As shown, the text configuration file is first parsed to generate an in-memory syntax tree. This configuration syntax tree is then flattened to flatten the nested structure. A memory layout alignment check is then performed. If the memory is not aligned, an alignment exception message is thrown. If the memory is aligned, serialization begins and the binary file is written according to the predefined binary format (Header+Export Block+Trailer). Serialization involves serializing the header according to the binary format header memory layout. The header memory layout includes a magic number (4 bytes, used for file type identification), a file version number (2 bytes), a timestamp (8 bytes), and the number of export blocks (4 bytes). When serializing export blocks, each block (struct bin_export) contains export rule metadata (such as path and access mode) and its associated client rule array. Each export block is traversed, and the block header is first serialized. The path string in the block header is compressed before being written. Before compression, the current device type is determined and an appropriate compression algorithm is selected based on the device type. The initial path string is compressed using the selected compression algorithm, such as LZ4 for low-end devices and Zstd for servers / cloud. The compressed path string is then written to the block header. After the block header is serialized, the client rule array associated with the export block is written. The process checks whether the currently traversed export block is the last one. If not, the process returns to the export block traversal step to determine the next export block. If it is the last export block, the trailer metadata is written. The trailer metadata includes a CRC32 checksum (4 bytes), a compression algorithm identifier (1 byte), and a reserved field (3 bytes). After writing, the current time is recorded and written to the timestamp field in the header. Saving the .bconf file results in a binary file.

[0113] The solution of this application can also realize dynamic difference update. When the user modifies the shared configuration of the configuration file, the new configuration is first written into the configuration file to obtain a new configuration file, and then the dynamic difference update process is triggered. In an optional implementation of this application, if Figure 7 As shown, based on the above embodiment, the configuration management method of the network file system of the present application may further include the following steps:

[0114] Step 301: In response to receiving a modification operation of a configuration file by a user, a modified file is obtained.

[0115] In this embodiment, the user can modify the original configuration file as needed. After the user completes the modification, a new configuration file is obtained, which is referred to as a modified file in this embodiment.

[0116] Step 302: Based on the modified file and the configuration file, determine the difference between the modified file and the configuration file.

[0117] In this embodiment, when the user modifies the configuration file, the system can automatically back up the configuration file for comparison with the modified file after the user completes the modification to determine the differences between the modified file and the configuration file before modification.

[0118] As an example, the modified file may be parsed to obtain a corresponding syntax tree, and the syntax tree may be compared with a configuration syntax tree corresponding to the configuration file before the modification to obtain the newly modified difference content.

[0119] As another example, the modified file and the configuration file before modification can be compared to determine the incremental modification content; and the text parser can be called to parse the modified file to obtain a configuration syntax tree (referred to as the first configuration syntax tree for ease of description and distinction). Based on the first configuration syntax tree and the second configuration syntax tree corresponding to the configuration file, the nested structure of the first configuration syntax tree is subjected to tree difference detection to determine the target node that has changed (including additions and modifications), and the node modification content corresponding to the target node is obtained from the modified file, and the node modification content and the incremental modification content are determined as the difference content. Thus, the incremental modification content is determined by comparing files, and the node modification content is determined by comparing configuration syntax trees. Since comparing files can quickly identify newly added export rules and the configuration syntax tree can intuitively reflect the changed nodes, it is more efficient to determine the difference content by combining the two methods compared to using a single comparison file or comparison syntax tree.

[0120] Step 303: compile the difference content into a binary patch file.

[0121] In this embodiment, the determined difference content may be compiled into a binary patch file (B_diff).

[0122] The binary patch file includes at least one patch, and each patch includes the following:

[0123] Operation code, used to identify the operation type, which can be ADD or UPDATE.

[0124] The target offset is used to indicate the location in the binary file that needs to be modified;

[0125] Data block, used to indicate new or modified content, such as a compressed IP address string.

[0126] In an embodiment of the present application, by generating a binary patch file containing an opcode, a target offset, and a data block, data support is provided for subsequently merging the binary patch file into the current binary file, and ease of operation of file merging is also provided.

[0127] Step 304: Generate a new binary file based on the binary patch file and the binary file.

[0128] In this embodiment, after the binary patch file is determined, the binary patch file can be merged into the current binary file to generate a new binary file of a new version. During the merging, the current binary file can be locked to prohibit other write operations and only support the writing of the binary patch file.

[0129] In an optional embodiment of the present application, when merging a binary patch file into a current binary file, the merged binary patch file can be applied to the original binary file line by line according to the opcode to generate a new binary file. Specifically, the patches in the binary patch file are read one by one, and the target opcode, target offset, and target data block of the currently read patch are obtained. According to the target opcode, the target data block is applied to the position corresponding to the target offset in the binary file, completing the merge of the currently read patch. After reading the binary patch file, a new binary file is obtained.

[0130] It should be noted that, in this embodiment, after obtaining the new binary file, it is necessary to update the version number of the new binary file and recalculate the checksum and write it to the end of the new binary file.

[0131] Step 305: Access the new binary file through the symbolic link.

[0132] The process accesses the .bconf file through the symbolic link (target_link.f). Therefore, in this embodiment, after obtaining the new binary file, the file can be atomically switched to the new version file through the symbolic link, so that the process can access the new binary file and ensure that the runtime loader always points to the valid version of the binary file.

[0133] For example, atomic switching can be achieved through the following steps:

[0134] 1. Create a new symbolic link target_link.f.new to point to the new binary file .bconf_v2

[0135] ln -sf .bconf_v2 target_link.f.new;

[0136] 2. Modify the original symbolic link to the newly created symbolic link

[0137] mv target_link.f.new target_link.f.

[0138] In an optional embodiment of the present application, after switching to a new binary file, it is mapped to the memory. If the verification of the new binary file fails, such as the file type is incorrect, incompatible, or the cyclic redundancy check fails, it automatically rolls back to the previous version of the binary file.

[0139] The configuration management method of the network file system of the embodiment of the present application obtains the modified file in response to receiving the user's modification operation on the configuration file, and determines the difference content of the modified file relative to the configuration file based on the modified file and the configuration file, then compiles the difference content into a binary patch file, and then generates a new binary file based on the binary patch file and the binary file, and accesses the new binary file through symbolic links. In this way, dynamic difference updates after the configuration file is modified are realized, the update efficiency is improved, and the seamless switching of the updated file is realized by atomically switching to the new binary file through the symbolic link.

[0140] Figure 8 This is a timing diagram of difference merging according to an exemplary embodiment of the present application. Figure 8 As shown in the figure, after the patch manager receives the merge request (patch) triggered by the user, it locks the binary file to be merged and traverses all the difference operations. Specifically, the opcode (op.type) is read. If the opcode is OP-UPDATE, the target address is calculated based on the target offset, memory mapping is performed based on the target address, the corresponding pointer is returned, and then the new data is written to the target address through the memcpy function. If the opcode is OP-ADD, the file size is expanded to the file system through the ftruncate function, the file system returns the new size, and then the memory is remapped through the mremap function, a new pointer is returned, and then the new data is appended; if the opcode is an unknown operation, an error log is recorded. After traversing all the difference operations, the file version number and CRC checksum are updated, and the symbolic link is switched to the newly generated binary file by atomic switching.

[0141] In an optional embodiment of the present application, Figure 9 As shown, based on the above embodiment, the configuration management method of the network file system of the present application may further include the following steps:

[0142] Step 401: Obtain historical configuration access information of the current device.

[0143] Among them, historical configuration access information may include but is not limited to at least one of access logs, system resource information, timing features, and association features. The access log records the access time, access frequency, access source (user / IP), request context (such as associated operations), etc. of each configuration file; system resource information includes but is not limited to environmental parameters such as memory usage, CPU load, network latency, etc.; timing features include sliding window statistics and periodic patterns. Sliding window statistics include the number of accesses in the past N minutes / hours, peak values within a time period, etc., and periodic patterns include access patterns counted by hour, day, and week (such as the difference between weekdays and weekends); association features include but are not limited to configuration co-occurrence matrices and user behavior sequences. The configuration co-occurrence matrix is used to count the frequency of continuous accesses to multiple configurations in the same session, and the user behavior sequence is used to analyze user operation chains (for example, after accessing configuration C, configuration D is usually accessed).

[0144] Step 402: Input the historical configuration access information into a pre-trained configuration prediction model for prediction, and obtain the configuration file identifier output by the configuration prediction model, wherein the configuration prediction model is used to predict the configuration file to be accessed and output the corresponding configuration file identifier.

[0145] Among them, the configuration prediction model is pre-trained. It can collect configuration access information such as access logs, system resource information, timing characteristics, correlation characteristics of different devices, and configuration files loaded when configuring access information as training samples. The initial model is trained using the training samples. During training, the configuration access information is used as the input of the model, the file identifier of the configuration file is used as the model output, and the file identifier of the configuration file in the training sample is used as the training target. By continuously adjusting and optimizing the model parameters, a trained configuration prediction model is obtained.

[0146] It is understandable that the choice of the initial model can be based on training requirements and model characteristics. For example, if time series prediction is required, models suitable for capturing long-term dependencies and periodic patterns, such as Long Short-Term Memory (LSTM) and Gated Recurrent Unit (GRU), can be selected. If classification tasks are required, models that screen key factors based on feature importance, such as Random Forest and eXtreme Gradient Boosting (XGBoost), can be selected, or Deep Neural Network (DNN) can be selected to process high-dimensional sparse features (such as user ID embedding). If association rules need to be mined, the Apriori algorithm can be selected to discover high-frequency configuration combinations (such as discovering the correlation between "configuration A → configuration B").

[0147] In this embodiment, the acquired historical configuration access information of the current device may be input into a configuration prediction model for prediction, and the configuration prediction model outputs a file identifier of a configuration file that is predicted to be accessed.

[0148] Step 403: Determine the corresponding target file according to the configuration file identifier.

[0149] In this embodiment, after obtaining the configuration file identifier predicted by the configuration prediction model, the corresponding file (referred to as a target file for ease of description and distinction) can be determined according to the configuration file identifier.

[0150] Step 404 : Load the data of the target file up to a preset size, and load the remaining data of the target file by asynchronous preloading.

[0151] The preset size can be set in advance according to actual needs, for example, the preset size is set to 1MB.

[0152] In this embodiment, for a specific target file, the pre-set size of data can be loaded immediately, and the remaining data of the file can be loaded through asynchronous preloading. In other words, when it is predicted that a certain configuration will be accessed soon, asynchronous loading is triggered, and different processes are started to load different data of the target file.

[0153] For example, if the preset size is 1MB, the first 1MB of the target file is loaded immediately, and the subsequent data is preloaded asynchronously. You can use the following code to achieve asynchronous loading:

[0154] madvise(addr, 1024*1024, MADV_WILLNEED);

[0155] posix_madvise(addr+1024*1024, file_size-1024*1024, POSIX_MADV_WILLNEED).

[0156] The configuration management method of the network file system in the embodiment of the present application obtains a configuration prediction model through pre-training, and uses the configuration prediction model to make predictions based on the historical configuration access information of the current device to obtain the identifier of the configuration file to be accessed. As a result, the configuration to be accessed can be predicted in advance and loaded in advance, which is conducive to improving the configuration loading efficiency. Moreover, when loading the target file, the data of a preset size is loaded first, and then the remaining data is loaded through asynchronous preloading, which can further improve the loading efficiency.

[0157] In an optional implementation of the present application, for the generated binary files, the binary files can also be synchronized to each node in the cluster to achieve cross-node consistency synchronization of the binary files in the Kubernetes cluster, ensuring that the configurations on all nodes in the cluster are consistent. The synchronization of binary files can be achieved by combining Kubernetes native resources (such as ConfigMap, DaemonSet), distributed storage (such as S3) and consistency protocols, including the following steps: storage and version management, change detection and triggering, synchronization and consistency implementation. Among them, in the storage and version management step, object storage is used to save binary files, and ConfigMap records version metadata. For example, MinIO, AWS S3 or S3-compatible object storage can be used to save binary files (.bconf), and each file is identified by a unique key (such as a SHA-256 hash value) to ensure that the content is immutable. For metadata management, the version information of the file in the file (such as the currently effective hash value, timestamp) can be stored in etcd distributed storage or Kubernetes' ConfigMap. For version management of binary files, a new hash value is generated each time the binary file is updated, and the new and old versions are recorded to support fast rollback; the configuration status is marked by Kubernetes annotations or labels, and the configuration status includes, for example, stable and pending.

[0158] In the change detection and triggering steps, you can monitor changes through the Watch API or a custom controller. For example, you can use the Kubernetes Watch API to monitor ConfigMap change events and trigger the node synchronization process when a new version hash value is detected.

[0159] In the synchronization and consistency implementation steps, eventual consistency is used to ensure data synchronization between nodes in the cluster. The synchronization strategy is: the control plane broadcasts the newly configured hash value to all nodes, and each node asynchronously pulls the corresponding binary file. The specific synchronization process includes:

[0160] 1. Metadata update: Update the active-hash in ConfigMap to the new version hash value;

[0161] 2. Node synchronization: Each node downloads the .bconf file with the corresponding hash value from the object storage based on the new version hash value. Next, the node verifies the integrity of the downloaded .bconf file (e.g., CRC32 checksum). If the check passes, the node replaces the local cache file with the currently downloaded .bconf file and reloads the configuration (e.g., through MMap remapping).

[0162] 3. Status reporting: The node reports the synchronization status to the control plane. The synchronization status may include success or failure.

[0163] 4. Health check: The control plane monitors the status of all nodes. If a timeout occurs (i.e., the synchronization status reported by all nodes in the cluster is not received within a certain period of time) or the number of failed nodes exceeds the threshold, an alarm is triggered or the system is rolled back to the previous version.

[0164] This application's solution also provides fault tolerance and recovery mechanisms, supporting automatic configuration rollback, node health checks, and network partition handling. Furthermore, it optimizes cross-node configuration consistency synchronization performance through incremental synchronization, local caching, parallel transmission, and compression.

[0165] 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.

[0166] An embodiment of the present application also provides a configuration management device for a network file system. Figure 10 A schematic diagram of a configuration management device for a network file system provided in an embodiment of the present application is shown in FIG. Figure 10 As shown, the configuration management device 50 of the network file system includes: an acquisition module 510 , a loading module 520 and an access module 530 .

[0167] The acquisition module 510 is configured to acquire a first file in response to a configuration loading instruction, where the first file is obtained by parsing a configuration file of a network file system and storing configuration information obtained by parsing the configuration file in a preset format, where the preset format is configured to indicate a memory layout of different configuration information, wherein the memory layout of different configuration information is continuous, and configuration information in a nested relationship corresponds to a continuous memory block.

[0168] A loading module 520 is configured to load the contents of the first file into a target memory;

[0169] The access module 530 is used to perform memory access according to the first address and memory layout of the target memory to read the configuration information.

[0170] Optionally, the preset format is a binary format, the first file is a binary file, and the acquisition module 510 is further configured to:

[0171] Call the text parser to parse the configuration file and generate a configuration syntax tree;

[0172] Flatten the configuration syntax tree and convert the nested structure in the configuration syntax tree into a continuous memory block;

[0173] Perform memory alignment detection on continuous memory blocks according to the preset alignment strategy;

[0174] When the memory alignment test passes, the configuration information of the configuration syntax tree and the continuous memory blocks are stored in a binary format to obtain a binary file corresponding to the configuration file.

[0175] Optionally, the configuration management device 50 for the network file system further includes a difference update module configured to:

[0176] In response to receiving a modification operation of the configuration file by the user, obtaining the modified file;

[0177] Based on the modified file and the configuration file, determining the difference between the modified file and the configuration file;

[0178] Compile the differences into a binary patch file;

[0179] Generate a new binary file based on the binary patch file and the binary file;

[0180] The new binary is accessed through a symbolic link.

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

[0182] 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 of any of the above-mentioned network file system configuration management method embodiments.

[0183] An embodiment of the present application further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned embodiments of the method for configuration management of a network file system when running.

[0184] 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.

[0185] 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 network file system configuration management method embodiments are implemented.

[0186] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps in any of the above-mentioned network file system configuration management method embodiments.

[0187] 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.

[0188] The above describes in detail the configuration management method, electronic device, medium, and product for a network file system provided by this application. This article uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is only intended to help understand the method and core concept of this application. It should be noted that for those skilled in the art, without departing from the principles of this application, various improvements and modifications can be made to this application, and these improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A configuration management method for a network file system, characterized in that: include: In response to the configuration loading instruction, a precompiled first file is obtained by parsing a configuration file of a network file system and storing configuration information obtained by parsing the configuration file in a preset format, wherein the preset format is used to indicate a memory layout of different configuration information, and the memory layout of the different configuration information is continuous, and configuration information in a nested relationship corresponds to a continuous memory block. The preset format is a binary format with a memory layout consistent with a memory layout of a target platform, and the memory layout reflects an offset and / or a size of memory occupied by each configuration information; Loading the content of the first file into the target memory; Performing memory access according to the first address of the target memory and the memory layout to read the configuration information; The binary format defines the data structure of the header, export block, and trailer. For the header, the offset, character length, and description information of the magic number field, version field, timestamp field, and export block number field are defined; for the export block, the memory size occupied by the export block ID, the memory size occupied by the path length, the memory size occupied by the number of member rules, and the member rule array nested under the export block are defined; for the trailer, the offset of the cyclic redundancy check field and the description information corresponding to each field are defined; Generating the first file according to the binary format includes: Call the text parser to parse the configuration file and generate a configuration syntax tree; Flattening the configuration syntax tree to convert nested structures in the configuration syntax tree into continuous memory blocks; Performing memory alignment detection on the continuous memory blocks according to a preset alignment strategy; If the memory alignment test passes, storing the configuration information of the configuration syntax tree and the continuous memory block in the binary format to obtain a binary file corresponding to the configuration file; The storing of the configuration information of the configuration syntax tree and the continuous memory block in the binary format includes: Acquire global configuration information and shared configuration information based on the configuration syntax tree, wherein the shared configuration information includes configuration information of multiple export blocks; Storing the global configuration information according to the header memory layout; Traversing the plurality of export blocks, and storing, according to the export block memory layout, block header information of the currently traversed export block and continuous memory blocks corresponding to member rules associated with the currently traversed export block; When the plurality of export blocks are traversed, a cyclic redundancy check code of the currently stored information is calculated and the cyclic redundancy check code is stored as a full-file check code according to the tail memory layout.

2. The configuration management method of the network file system according to claim 1, characterized in that: The first file includes a header and a tail, the header includes a magic number and a file version number, and the tail includes a full file check code; Before performing the memory access, the method further includes: Detecting whether the magic number is a preset value; When the magic number is a preset value, detecting whether the file version number is compatible with the current program based on a preset compatibility rule; If compatibility is confirmed, performing integrity verification based on the full file verification code; If the integrity check passes, memory access is performed.

3. The configuration management method of the network file system according to claim 2, characterized in that: The method further comprises: If the magic number is not the preset value, or the file version number is incompatible with the current program, or the integrity check fails, a configuration file parsing process is triggered to obtain a second file.

4. The configuration management method of a network file system according to claim 1, wherein: The preset format is a binary format, and the first file is a binary file obtained by parsing the configuration file and storing the parsed configuration information in the binary format.

5. The configuration management method of the network file system according to claim 1, characterized in that: The block header information includes a path string, and the storing of the block header information of the currently traversed export block according to the export block memory layout includes: Acquire an initial path character string of the currently traversed export block from the configuration information of the multiple export blocks; Determine the target compression algorithm based on the current device type; Compressing the initial path character string using the target compression algorithm to obtain a compressed path character string; The compressed path string is used as the path string of the currently traversed export block and is stored according to the export block memory layout.

6. The configuration management method of the network file system according to claim 4, characterized in that: The method further comprises: In response to receiving a modification operation of the configuration file by the user, obtaining the modified file; Determining, based on the modified file and the configuration file, differences between the modified file and the configuration file; Compile the difference content into a binary patch file; Generate a new binary file based on the binary patch file and the binary file; Said new binary is accessed via a symbolic link.

7. The configuration management method of the network file system according to claim 6, characterized in that: The determining, based on the modified file and the configuration file, the difference between the modified file and the configuration file, includes: Comparing the modified file with the configuration file to determine the incremental modification content; Calling a text parser to parse the modified file to obtain a first configuration syntax tree; Based on the first configuration syntax tree and the second configuration syntax tree corresponding to the configuration file, performing tree difference detection on the nested structure of the first configuration syntax tree to determine the target node that has changed; Obtaining the node modification content corresponding to the target node from the modified file; The node modified content and the incremental modified content are determined as the difference content.

8. The configuration management method of a network file system according to claim 6, characterized in that: The binary patch file includes at least one patch, each patch including: Operation code, used to identify the operation type, the operation type is add or modify; A target offset, used to indicate the location in the binary file that needs to be modified; A data block used to indicate new or modified content.

9. The configuration management method of the network file system according to claim 8, characterized in that: The generating a new binary file based on the binary patch file and the binary file includes: Read the patches in the binary patch file one by one, and obtain the target operation code, target offset, and target data block of the currently read patch; applying the target data block to a position corresponding to the target offset in the binary file according to the target operation code; After reading the binary patch file, the new binary file is obtained.

10. The configuration management method of a network file system according to any one of claims 1 to 9, characterized in that: The method further comprises: Get the historical configuration access information of the current device; Inputting the historical configuration access information into a pre-trained configuration prediction model for prediction, and obtaining a configuration file identifier output by the configuration prediction model, wherein the configuration prediction model is used to predict the configuration file to be accessed and output the corresponding configuration file identifier; Determine the corresponding target file according to the configuration file identifier; The first preset size of data of the target file is loaded, and the remaining data of the target file is loaded by asynchronous preloading.

11. An electronic device, characterized in that: include: memory for storing computer programs; A processor is configured to implement the steps of the network file system configuration management method according to any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method for configuration management of a network file system according to any one of claims 1 to 10.

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the network file system configuration management method according to any one of claims 1 to 10 are implemented.

Images