Configuration management method of network file system, electronic equipment, medium and product
By converting the configuration files of the network file system into binary format and loading using memory mapping technology, the problem of low loading efficiency and high memory fragmentation rate of configuration management mechanism in large-scale configuration scenarios is solved, and efficient configuration loading and dynamic differential updates are achieved.
Patent Information
- Application Number
- CN202510534547.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-04-27
- Publication Date
- 2025-05-30
- Estimated Expiration
- 2045-04-27
AI Technical Summary
The configuration management mechanism of existing network file systems is low loading efficiency and high memory fragmentation rate in large-scale configuration scenarios, resulting in a degradation of system performance.
Fast loading is achieved by converting configuration files into compact binary formats and using memory mapping technology to map binary files directly to memory, skipping the parsing step. At the same time, by generating binary patch files, only the change part is updated, and dynamic differential updates are achieved.
It significantly improves configuration file loading efficiency, reduces memory fragmentation rate, improves memory resource utilization, and shortens configuration reload time.
Smart Images

Figure CN120066618A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of network file systems, and particularly to a configuration management method, an electronic device, a medium, and a product for a network file system. Background Art
[0002] As a core component of distributed storage, the configuration management mechanism of the Network File System (NFS) directly affects system performance and operation and maintenance efficiency. With the popularization of cloud computing and ultra-large-scale data centers, the number of export rules in a single cluster has increased exponentially from dozens to tens of thousands, and a single export block may contain hundreds of nested member (client) rules. Currently, the rules that need to be configured for NFS are usually written into a configuration file in a text-based configuration manner, and the configuration file is parsed and loaded at system startup to complete the configuration.
[0003] However, in related technologies, when parsing the configuration file, it is mainly implemented by recursive descent syntax analysis. 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 large memory fragmentation rate. Summary of the Invention
[0004] This application provides a configuration management method, an electronic device, a medium, and a product for a network file system, so as to at least solve the problems of low loading efficiency of the configuration file and large memory fragmentation rate in related technologies.
[0005] This application provides a configuration management method for a network file system, including: In response to a configuration loading instruction, obtain a first file, where the first file is obtained by parsing a configuration file of the network file system 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 layouts of different configuration information are continuous, and the configuration information with a nested relationship corresponds to continuous memory blocks; Load the content of the first file into the target memory; Perform memory access according to the start address of the target memory and the memory layout to read the configuration information.
[0006] This application also provides a configuration management device for a network file system, including: An acquisition module, 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 the parsed configuration information in a preset format, and the preset format is used to indicate the memory layout of different configuration information, and the memory layouts of different configuration information are continuous, and the configuration information with a nested relationship corresponds to a continuous memory block; A loading module, configured to load the content of the first file into a target memory; An access module, configured to perform memory access according to the starting address of the target memory and the memory layout to read the configuration information.
[0007] This application further provides an electronic device, including: a memory, configured to store a computer program; a processor, configured to implement the steps of any one of the above network file system configuration management methods when executing the computer program.
[0008] This application further provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a processor, the steps of any one of the above network file system configuration management methods are implemented.
[0009] This application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of any one of the above network file system configuration management methods are implemented.
[0010] Through this application, since the first file is obtained by parsing the configuration file and storing the parsed configuration information in a preset format, and the preset format is used to indicate the memory layout of different configuration information, and the memory layouts of different configuration information are continuous, and the configuration information with a nested relationship corresponds to a continuous memory block, 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 loading the content of the first file, the memory storing the loaded content is continuous, reducing the memory fragmentation rate and helping to improve the utilization rate of memory resources. Moreover, since the first file is obtained by pre-parsing the configuration file, when receiving a configuration loading instruction, the existing first file can be directly loaded into the memory without parsing the configuration file again, thus avoiding the time-consuming of parsing the configuration file and improving the loading efficiency. Therefore, the technical problems of low configuration file loading efficiency and large memory fragmentation rate can be solved, and the technical effects of improving the configuration loading efficiency and reducing the memory fragmentation rate can be achieved. Description of the Drawings
[0011] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.
[0012] Figure 1 Schematic diagram of the BPCC system architecture for implementing the configuration management method of the network file system provided by an exemplary embodiment of the present application; Figure 2 Flow chart of a configuration management method for a network file system provided by an embodiment of the present application; Figure 3 Schematic diagram of the binary format provided by an exemplary embodiment of the present application; Figure 4 Flow chart of the binary file loading process provided by an exemplary embodiment of the present application; Figure 5 Flow chart of another configuration management method for a network file system provided by an embodiment of the present application; Figure 6 Flow chart of the binary file generation process provided by an exemplary embodiment of the present application; Figure 7 Flow chart of yet another configuration management method for a network file system provided by an embodiment of the present application; Figure 8 Timing diagram of differential merging provided by an exemplary embodiment of the present application; Figure 9 Flow chart of yet another configuration management method for a network file system provided by an embodiment of the present application; Figure 10 Schematic diagram of the structure of a configuration management device for a network file system provided by an embodiment of the present application. Detailed implementation manners
[0013] The following will clearly and completely describe the technical solutions in the embodiments of the present application in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments of the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the protection scope of the present application.
[0014] It should be noted that in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. The terms "first", "second", etc. in this application are used to distinguish similar objects, rather than to describe a specific order or sequence.
[0015] With the popularization of cloud computing and ultra-large-scale data centers, the number of export rules in a single cluster has increased exponentially from dozens to tens of thousands. Taking the open-source NFS implementation of the Ganesha file server as an example, its configuration file needs to define complex access control lists (ACLs), storage backend parameters such as the file system abstraction layer (FSAL), and protocol options. A single export block may contain hundreds of nested client rules. Currently, in related technologies, the configuration of NFS is usually managed based on text configuration, and this management method faces the following systematic challenges: (1) Low parsing efficiency Configuration parsers generally use the Flex / Bison combination to implement recursive descent syntax analysis, with a time complexity of O(n²) (n is the number of rules). The parsing time grows superlinearly with the number of rules. Moreover, nested structures (such as FSAL and client embedded in export) lead to an excessive depth of the syntax tree, consuming a large amount of stack space and also affecting the parsing efficiency.
[0016] (2) Memory fragmentation The text configuration-based management scheme dynamically allocates independent memory objects (such as struct export_entry) for each configuration item. Measured data shows that when the configuration scale reaches 100,000 levels, the memory fragmentation rate exceeds 35%, resulting in a decrease in the effective memory capacity and a sharp increase in the pressure of garbage collection (GC).
[0017] (3) Dynamic update latency The current system (such as NFS-Ganesha) adopts a full-reload mode: even if only the IP of a single client is modified, the entire configuration file still needs to be re-parsed and the memory structure rebuilt. In ultra-large-scale clusters, the reload latency of minutes is difficult to meet the requirements of business continuity (such as real-time permission changes in financial trading systems).
[0018] Regarding the above problems, there are currently some solutions, but these solutions cannot well solve the above problems. For example, Related Technology 1: Configuration management based on a database. Specifically, the configuration is stored in an SQLite or Redis database and dynamically loaded through a query interface. However, this management method will cause the loading speed to decrease by 30% due to database query latency (average 2 - 5 ms / time), and there is an object conversion overhead. The deserialization from database records to memory objects consumes more than 40% of the CPU time. Related Technology 2: Parallel text parsing. Specifically, the configuration file is split into multiple segments, and the results are merged after being parsed in parallel by different threads. However, this method has syntax dependency conflicts. Nested blocks (such as EXPORT{ FSAL{...}}) lead to strong dependencies between threads. The Amdahl's law limits make the parallel efficiency lower than 20%, and there is a merging overhead. Cross-segment object references require complex pointer relocations, and the time consumption during the merging phase accounts for more than 60%. Related Technology 3: Configuration templates and sharding. Specifically, a large file is split into multiple sub-files through the %include directive and loaded as needed. However, this method does not touch the parsing logic, and the sub-files still need to be fully parsed, so the total time consumption is not significantly reduced, and the management complexity is high. Variable scopes between shards are prone to cause configuration errors (such as global parameter overwriting).
[0019] Aiming at the problems existing in the above related technologies, this application provides a configuration management solution for a network file system based on binary precompiled cache, aiming to solve the problems of how to achieve millisecond-level full-load in a large-scale configuration scenario, how to support dynamic updates and avoid full parsing. This solution converts the configuration file into a file in a compact binary format (.bconf) through a binary precompiled cache (BinaryPrecompiled Configuration Cache, BPCC). Its memory layout is consistent with the runtime data structure, and through the Memory Mapping (MMap) technology, the binary file is directly mapped to the memory address space to accelerate access, skipping the parsing step, which can significantly improve the loading efficiency. And through the compact memory mapping, the memory fragmentation rate can be reduced, the effective memory capacity can be increased, the memory occupancy is reduced by 40%, and the CPU peak load is reduced by 70%, and the system resources are significantly optimized. Also, by generating a binary patch file based on the different parts of the configuration file and only updating the changed parts, dynamic differential updates are realized, and the configuration reload time after the process restarts is shortened from minutes to seconds.
[0020] To enable those skilled in the art of this technology to better understand the solution of this application, the following further detailed description of this application will be given in conjunction with the accompanying drawings and specific implementation manners.
[0021] In combination 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.
[0022] Figure 1 The following is a schematic diagram of the BPCC system architecture for implementing the configuration management method of the network file system provided by an exemplary embodiment of the present application. As Figure 1 shown, the BPCC system architecture includes a Configuration Compiler, a Cache Manager, and a Runtime Loader. Among them, the Configuration Compiler is responsible for parsing the text configuration. Through a series of operations such as syntax parsing, memory layout alignment, serialization, and compression, it converts the text configuration (such as ganesha.conf) into a binary file (.bconf). Its input is the original text configuration file and the user-defined compilation policy (such as the selectable compression algorithm), and the output is a binary file with complete metadata (such as version number, timestamp, checksum, etc.). The Cache Manager is responsible for the life cycle management of the binary file, including version control, verification, compression optimization, and storage policies, etc. Among them, when performing compression optimization, the compression algorithm is dynamically adjusted according to the hardware resources: the low-latency LZ4 algorithm is used in low-end devices (such as ARM embedded devices), and the high-compression-ratio Zstd algorithm is used in storage-intensive scenarios (such as cloud servers). The Runtime Loader directly maps the binary file to memory through the zero-copy technology (such as MMap) to achieve instantaneous loading of the configuration. The loading process does not require the intervention of a parser, and the corresponding configuration can be read directly by accessing the configuration data structure through pointers. Before accessing the memory, the magic number and version are verified first. After the verification is successful, the memory can be accessed directly, otherwise the text configuration parsing process is triggered, and an atomic update mechanism is provided to ensure that the service is unaware during dynamic configuration switching.
[0023] An embodiment of the present application provides a configuration management method for a network file system. In combination with the execution process of the configuration management method of the network file system, the method is described in detail.
[0024] Figure 2 The following is a schematic flowchart of a configuration management method for a network file system provided by an embodiment of the present application. This method can be executed by the configuration management device of the network file system provided by the embodiment of the present application and can be integrated in an electronic device.
[0025] As Figure 2 shown, the configuration management method of the network file system includes the following steps: Step 101: In response to a configuration loading instruction, obtain a first file. The first file is obtained by parsing a configuration file of a network file system 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 layouts of different configuration information are continuous. Configuration information with a nested relationship corresponds to continuous memory blocks.
[0026] 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, the configuration compiler shown below can be used to convert the configuration file into the first file and store it. Figure 1 The configuration compiler shown below can be used to convert the configuration file into the first file and store it.
[0027] In an alternative 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 the memory layout corresponding to different configuration information, and the memory layout is continuous. As a result, the configuration information in the binary file obtained by storing the configuration information in the binary format has a continuous memory layout, and the nested structure is also converted into continuous memory blocks.
[0028] Exemplarily, Figure 3 is a schematic diagram of the binary format of an exemplary embodiment of the present application. As shown in Figure 3 below, the binary format defines the data structures of a header, an export block, and a trailer. For the header, it defines the offsets, character lengths, and corresponding description information of the magic number field, version field, timestamp field, and export count field; for the export block, it defines the memory size occupied by the export block ID, the memory size (number of 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; for the trailer, it defines the offsets of the cyclic redundancy check (CRC) field, compression algorithm identifier (Compression) field, and reserved field, and the description information corresponding to each field. It can be seen from Figure 3 this that the binary format indicates the memory layout of different configuration information, and the memory layouts of different configuration information are continuous. Therefore, when storing the configuration information in the binary format, the memory occupied by each configuration information is contiguous, which can reduce the memory fragmentation rate.
[0029] In this embodiment, when a configuration loading instruction is received, for example, when the device starts or restarts, the configuration loading instruction is triggered. In response to this configuration loading instruction, first, it is detected whether there is a first file in the disk. If it exists, the first file is obtained and the subsequent step of mapping the first file to memory is executed; if it is detected that the first file does not exist, a configuration file parsing process is triggered to generate a corresponding binary file, and then the generated binary file is loaded into memory. By converting the configuration file into the first file and then loading it into memory when the first file is not detected, rather than directly loading the configuration file, the configuration information can be mapped to a continuous memory space during loading, reducing the memory fragmentation rate, and also providing conditions for directly loading the first file after the subsequent system restarts.
[0030] Step 102, load the content of the first file into the target memory.
[0031] In this embodiment, if the first file is obtained, the first file can be directly mapped to memory through the Figure 1 runtime loader in, so as to load the content of the first file into the target memory. Here, the target memory refers to the memory space storing the content of the first file. When mapping the first file to memory, the runtime loader will automatically allocate a relatively large memory, and the starting address of the allocated memory is known. Starting from this starting address, the content read from the first file is stored in sequence, so that the content in the first file can be stored using continuous memory space.
[0032] Exemplarily, MMap can be used to map the first file to memory. Among them, the MAP_POPULATE flag of MMap is used to preload the binary file into physical memory to avoid page faults during the first access; madvise(MADV_SEQUENTIAL) is used to prompt the kernel to prefetch the file content to improve the continuous access performance.
[0033] Step 103, perform memory access according to the starting address of the target memory and the memory layout to read the configuration information.
[0034] Among them, the starting address of the target memory is known to the runtime loader.
[0035] In this embodiment, since the preset format indicates the memory layout of different configuration information, and the memory layout reflects the offset and / or the size of the memory occupied by each configuration information, therefore, according to the starting address of the target memory and the memory layout of the configuration information, the storage space address of the configuration information in memory can be determined, and thus by directly accessing this storage space address through a pointer, the configuration information can be read from memory without parsing.
[0036] Exemplarily, when it is necessary to read the export rules of the export block, the export rules are directly located through pointer arithmetic as follows: struct bin_export *exp = (struct bin_export *)((char *)header + sizeof(struct bin_header) + i * sizeof(struct bin_export));
[0037] In the configuration management method of the network file system according to the embodiment of the present application, by parsing the configuration file and storing the configuration information obtained by parsing the configuration file in a preset format, a first file is obtained. The preset format is used to indicate the memory layout of different configuration information, and the memory layouts of different configuration information are 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, reducing the memory fragmentation rate, which helps to improve the utilization rate of memory resources. And, since the first file is obtained by pre-parsing the configuration file in advance, when a configuration loading instruction is received, the existing first file can be directly loaded into memory without parsing the configuration file again, thus avoiding the time-consuming of parsing the configuration file and improving the loading efficiency. Therefore, the technical problems of low configuration file loading efficiency and large memory fragmentation rate can be solved, and the technical effects of improving the configuration loading efficiency and reducing the memory fragmentation rate can be achieved.
[0038] In an alternative embodiment of the present application, the first file includes a header and a tail. The header includes a magic number and a file version number. The magic number is a preset value used to indicate the file type. By detecting whether the magic number is the preset value, file type errors can be prevented. For example, the magic number can be set to a fixed value "0x4E465347" (the corresponding ASCII is "NFSG"); the tail includes a full file checksum, which is used to represent the integrity of all information in the first file except the tail data and can be determined based on all information in the first file except the tail data. For example, it is calculated by algorithms such as hash function, CRC32, etc. for the header and all export blocks of the first file. These fields can be used for the verification of the first file to ensure the compatibility and integrity of the first file, thus ensuring the normal progress of configuration loading. Therefore, in this embodiment, before memory access, the loaded first file can be verified according to the magic number, file version number, and full file checksum, and then memory access can be performed after the verification is successful.
[0039] Specifically, it is possible to first detect whether the magic number is a preset value. If the magic number is detected to be 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 rules can be pre-set custom rules for indicating what version of files 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 rules, it is determined that the version of the first file is compatible with the current program, otherwise it is considered incompatible. When it is determined to be compatible, an integrity check is further performed based on the full file check code. For example, the full file check code is calculated by the CRC32 algorithm, then the CRC32 check code of the header and the export block in the first file content is calculated, and the calculation 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 is successfully checked and memory access can be performed.
[0040] In the 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, the compatibility of the first file with the current program can be detected; by performing an integrity check based on the full-file checksum, it is possible to detect whether the first file has data corruption problems and ensure 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.
[0041] Further, in an optional implementation of the present application, if the magic number is not a preset value, it is determined that the file type of the binary file is wrong. In this case, the file can be marked as damaged and the configuration file parsing process can be triggered to obtain the second file; or, if it is detected that the file version number is incompatible with the current program, the configuration file parsing process is triggered to obtain the second file; or, if the integrity check fails, it can be determined that the first file has data damage. In this case, the configuration file parsing process is also triggered to obtain the second file. It can be 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.
[0042] Take the default format as binary format and the first file as a binary file as an example. Figure 4 FIG. 1 is a schematic diagram of a binary file loading process according to an exemplary embodiment of the present application. Figure 4As shown, when loading the configuration, first check whether there is a binary file (`.bconf` file). If not, trigger the configuration file parsing process to generate a binary file. If the binary file is detected, map the binary file to memory and check whether the magic number is the preset value. If it is not the preset value, mark it as damaged and trigger the configuration file parsing process; if it is the preset value, check whether the file version number is compatible. If it is not compatible, trigger the configuration file parsing process. If it is compatible, further verify whether the full file checksum matches. If it does not match, trigger the configuration file parsing process. If it matches, perform direct memory access to read the corresponding configuration information.
[0043] In an alternative embodiment of the present application, the preset format is a binary format, and the first file is a binary file. As Figure 5 shown, based on the foregoing embodiment, the step of obtaining the first file may include the following sub-steps: Step 201, call a text parser to parse the configuration file to generate a configuration syntax tree.
[0044] Among them, the text parser may adopt commonly used file parsers at present, such as Flex and Bison.
[0045] In this embodiment, calling a file parser to parse the configuration file can generate a configuration syntax tree in memory.
[0046] Step 202, perform a flattening process on the configuration syntax tree to convert the nested structure in the configuration syntax tree into a continuous memory block.
[0047] Among them, the flattening process refers to converting a multi-layer nested data structure into a one-layer data structure for more convenient processing and analysis.
[0048] In this embodiment, by performing a flattening process on the configuration syntax tree, the nested structure in the configuration syntax tree (such as Export{ client{...}}) can be converted into a continuous memory block, thereby eliminating the cache miss problem caused by pointer jumps.
[0049] Exemplarily, taking the example that a single export rule in the configuration file includes multiple nested client rules, in the parsed configuration syntax tree, a single export node includes multiple client nodes, and the flattening process can be performed according to the preset data structures of export and client. For example, the data structures of export and client are as follows: struct bin_export{ / / Single shared configuration uint32_texport_id; / / Export ID uint32_t path_len; / / The length of the path string char path[path_len]; / / The path string uint32_t num_clients; / / The number of clients bin_client clients[num_clients]; / / The client list / / Other parameters (such as Access_type, etc.) }; struct bin_client{ / / Configuration of a single client uint8_t ip_type; / / IP type (IPv4 = 0, IPv6 = 1) union { uint32_t ipv4; / / IPv4 address (in binary format) uint8_t ipv6
[16] ; / / IPv6 address }; uint32_t netmask; / / Subnet mask (only valid for IPv4) }; Step 203: Perform memory alignment detection on the continuous memory block according to the preset alignment strategy.
[0050] Among them, the alignment strategy is used to indicate the number of bytes for memory alignment, which can be set according to actual needs. Different platforms adopt different alignment strategies, such as 4-byte alignment and 8-byte alignment.
[0051] In this embodiment, after flattening the configuration syntax tree, memory alignment detection can be performed on the continuous memory block according to the preset alignment strategy. A binary memory layout (struct bin_export) exactly the same as the runtime object can be defined to ensure that the field offsets and byte orders match the target platform.
[0052] Exemplarily, memory alignment detection can be performed through the following code: size_t current_offset = 0; for (each field) { if (current_offset % field_alignment != 0) { / / Fill in blank bytes to meet the alignment pad_bytes = field_alignment - (current_offset % field_alignment); write_padding(pad_bytes); current_offset += pad_bytes; } write_field(field_data); current_offset += sizeof(field_data); } Among them, in the above code, field_alignment represents the number of memory alignment bytes indicated in the alignment policy.
[0053] In this embodiment, by performing memory alignment, the binary file is forced to be aligned by 4K and 8K pages, which can prevent exceptions from occurring in MMap and ensure that it can be directly converted into a structure pointer after MMap mapping.
[0054] In an alternative embodiment of the present application, when it is detected that the memory is not aligned, the process of generating the binary file is terminated and the system reverts to the text configuration management mode.
[0055] Step 204, in the case where the memory alignment detection passes, store the configuration information of the configuration syntax tree and the continuous memory block in binary format to obtain the binary file corresponding to the configuration file.
[0056] In this embodiment, if the memory alignment detection passes, the configuration information of the configuration syntax tree and the continuous memory block are stored in a preset binary format to obtain the binary file.
[0057] In an alternative embodiment of the present application, the binary format includes a header memory layout, an export block memory layout, and a tail memory layout. When generating a binary file in accordance with the binary format, global configuration information and shared configuration information can be obtained based on the configuration syntax tree. The shared configuration information includes the configuration information of multiple export blocks (export rules). The configuration information of each export block includes block header information such as an export block ID and a path string, and also includes a client belonging to the export block, etc. For the global configuration information, it can be stored according to the header memory layout. For each export block, each export block among the multiple export blocks can be traversed, and the block header information of the currently traversed export block and the continuous memory block corresponding to the member rules associated with the currently traversed export block can be stored according to the export block memory layout. After traversing the multiple export blocks, a cyclic redundancy check code of the currently stored information is calculated, that is, a CRC32 check code of the stored header data and the data of all export blocks is calculated, and the cyclic redundancy check code is stored as a full file check code according to the tail memory layout. Optionally, an incremental writing method can be adopted, and each export block is written to the disk as soon as it is completed, avoiding the risk of full memory cache overflow.
[0058] 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. Among them, the non-index fields can be preset according to actual needs. For example, the non-index fields include path strings. In an alternative embodiment of the present application, when the block header information includes a path string, the path string can be compressed and stored. Thus, when storing the block header information of the currently traversed export block according to the export block memory layout, the path string of the currently traversed export block can be obtained from the configuration information of the multiple export blocks (for the sake of easy description and distinction, it is called the initial path string); then, the target compression algorithm is determined according to the current device type. Among them, 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. Then, the initial path string is compressed using the current compression algorithm to obtain a compressed path string, and then the compressed path string is used as the path string of the currently traversed export block and stored according to the export block memory layout. That is to say, when storing the path string according to the export block memory layout, the initial path string in the configuration file is compressed first and then stored in the binary file. It should be noted that in this embodiment, when compressing, each export block is compressed independently and supports random access. The path compression of multiple export blocks can be executed in parallel (implied parallel for semantics) to improve the compression efficiency.
[0059] In the embodiments of the present application, by determining the target compression algorithm according to the current device type, a compression algorithm 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 occupation of the path string can be reduced, and the situation of overflowing its corresponding memory space when the path string is long can be avoided.
[0060] The configuration management method of the network file system in the embodiments of the present application parses the configuration file through 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 abnormal, ensuring that it can be directly converted into a structure pointer after MMap mapping; in the case where the memory alignment detection passes, store the configuration information of the configuration syntax tree and the continuous memory block in binary format to obtain the binary file corresponding to the configuration file. Thus, the conversion of the configuration file into a binary file with continuous memory is realized, providing data support for efficient configuration.
[0061] Figure 6 It is a schematic diagram of the binary file generation process for an exemplary embodiment of the present application, as Figure 6As shown, first parse the text configuration file to generate an in-memory syntax tree, then flatten the configuration syntax tree to flatten its nested structure. Next, perform an in-memory layout alignment check. If the memory is not aligned, throw a prompt message for the alignment exception. If the memory is aligned, start serialization and write to a binary file according to the predefined binary format (Header + Export Block + Trailer). Serialization includes serializing the Header, serializing according to the memory layout of the binary format's header, where the header memory layout includes a magic number (4 bytes for file type identification), a file version number (2 bytes), a timestamp (8 bytes), and the number of export blocks (4 bytes). When serializing an export block, each block (struct bin_export) contains export rule metadata (such as path, access mode) and its associated client rule array. Traverse each export block. First, serialize the block header of the export block. For the path string in the block header, it needs to be compressed before writing. Before compression, first determine the current device type, select a suitable compression algorithm according to the current device type, and use the selected compression algorithm to compress the initial path string. For example, select the LZ4 compression algorithm for low-end devices and the Zstd compression algorithm for servers / clouds, and write the compressed path string to the block header. After completing the serialization of the block header, write the client rule array associated with the export block. Determine whether the currently traversed export block is the last export block. If not, return to the step of traversing the export block to determine the next export block. If it is the last export block, start writing the Trailer metadata. The Trailer metadata includes a CRC32 checksum (4 bytes), a compression algorithm identifier (1 byte), and a reserved field (3 bytes). After writing, record the current time and write it to the timestamp field of the Header, and save the.bconf file to obtain the binary file.
[0062] The solution of this application can also achieve dynamic differential updates. When the user modifies the shared configuration of the configuration file, first write the new configuration into the configuration file to obtain a new configuration file, and then trigger the dynamic differential update process. In an optional implementation manner of this application, as Figure 7 shown, based on the foregoing embodiments, the configuration management method of the network file system of this application may further include the following steps: Step 301, in response to receiving a user's modification operation on the configuration file, obtain the modified file.
[0063] In this embodiment, the user can modify the original configuration file according to requirements. After the user finishes the modification, a new configuration file after modification is obtained, which is referred to as the modified file in this embodiment.
[0064] Step 302: Based on the modified file and the configuration file, determine the difference content of the modified file relative to the configuration file.
[0065] 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 finishes the modification to determine the difference content of the modified file relative to the original configuration file.
[0066] As an example, the modified file can be parsed to obtain a corresponding syntax tree, and the syntax tree can be compared with the configuration syntax tree corresponding to the original configuration file to obtain the newly modified difference content.
[0067] As another example, the modified file and the original configuration file can be compared to determine the incremental modification content; and, a text parser is called to parse the modified file to obtain a configuration syntax tree (for the convenience of description and distinction, called the first configuration syntax tree). Based on the first configuration syntax tree and the second configuration syntax tree corresponding to the configuration file, a tree difference detection is performed on the nested structure of the first configuration syntax tree to determine the target nodes that have changed (including addition and modification), and the node modification content corresponding to the target nodes is obtained from the modified file. 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, compared with the method of using a single comparison of files or comparison of syntax trees, the method of combining the two to determine the difference content is more efficient.
[0068] Step 303: Compile the difference content into a binary patch file.
[0069] In this embodiment, for the determined difference content, it can be compiled into a binary patch file (B_diff).
[0070] Among them, the binary patch file includes at least one patch, and each patch includes the following content: An opcode for identifying the operation type, where the operation type is addition (ADD) or modification (UPDATE); A target offset for indicating the position in the binary file that needs to be modified; A data block for indicating the added or modified content, such as a compressed IP address string.
[0071] In the embodiments of the present application, by generating a binary patch file containing an opcode, a target offset, and a data block, it provides data support for subsequently merging the binary patch file into the current binary file and also provides the ease of file merging.
[0072] Step 304: Generate a new binary file based on the binary patch file and the binary file.
[0073] In this embodiment, after determining the binary patch file, the binary patch file can be merged into the current binary file to generate a new binary file of a new version. Among them, when merging, the current binary file can be locked to prohibit other write operations and only support the writing of the binary patch file.
[0074] In an alternative embodiment of the present application, when merging the binary patch file into the current binary file, the binary patch file can be applied to the original binary file item by item according to the operation code to generate a new binary file. Specifically, read the patches in the binary patch file item by item, obtain the target operation code, target offset, and target data block of the currently read patch, and apply the target data block to the position corresponding to the target offset in the binary file according to the target operation code to complete the merging of the currently read patch. After reading the entire binary patch file, a new binary file is obtained.
[0075] It should be noted that in this embodiment, after obtaining the new binary file, it is also 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.
[0076] Step 305: Access the new binary file through a symbolic link.
[0077] The process accesses the.bconf file through a 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, ensuring that the runtime loader always points to the binary file of the valid version.
[0078] Exemplarily, the atomic switch can be achieved through the following steps: 1. Create a new symbolic link target_link.f.new that points to the new binary file.bconf_v2 ln -sf.bconf_v2 target_link.f.new; 2. Modify the original symbolic link to the newly created symbolic link mv target_link.f.new target_link.f.
[0079] In an alternative embodiment of the present application, after switching to the new binary file and mapping it to memory, if the verification of the new binary file fails, such as incorrect file type, incompatibility, or failed cyclic redundancy check, it will automatically roll back to the previous version of the binary file.
[0080] The configuration management method of the network file system according to the embodiments of the present application responds to receiving a user's modification operation on the configuration file, obtains the modified file, 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 further generates a new binary file based on the binary patch file and the binary file. By accessing the new binary file through a symbolic link, thus, dynamic differential update after the modification of the configuration file is achieved, improving the update efficiency, and seamless switching of the updated file is realized by atomically switching to the new binary file through the symbolic link.
[0081] Figure 8 For the differential merge timing diagram of an exemplary embodiment of the present application, as Figure 8 shown, after the patch manager receives a merge request (patch) triggered by the user, it locks the binary files to be merged and traverses all differential operations. Specifically, it reads the operation code (op.type). If the operation code is OP-UPDATE, it calculates the target address according to the target offset, performs memory mapping based on the target address, returns the corresponding pointer, and then writes new data to the target address through the memcpy function. If the operation code is OP-ADD, it expands the file size in the file system through the ftruncate function, the file system returns the new size, remaps the memory through the mremap function, returns the new pointer, and then appends new data; if the operation code is an unknown operation, it records an error log. After traversing all differential operations, it updates the file version number and CRC checksum, and switches to the newly generated binary file through an atomic switch of the symbolic link.
[0082] In an alternative embodiment of the present application, as Figure 9 shown, based on the foregoing embodiment, the configuration management method of the network file system of the present application may further include the following steps: Step 401, obtain the historical configuration access information of the current device.
[0083] Among them, the historical configuration access information may include, but is not limited to, at least one of access logs, system resource information, temporal features, and correlation 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; the system resource information includes, but is not limited to, environmental parameters such as memory occupancy, CPU load, and network latency; the temporal features include sliding window statistics and periodic patterns. The sliding window statistics include the number of accesses in the past N minutes / hours, the peak value within a time period, etc. The periodic pattern includes the access rules statistically calculated by hour, day, and week (such as the difference between weekdays and weekends); the correlation features include, but are not limited to, the configuration co-occurrence matrix and the user behavior sequence. The configuration co-occurrence matrix is used to statistically calculate the frequency of multiple configurations being continuously accessed in the same session, and the user behavior sequence is used to analyze the user operation chain (such as usually accessing configuration D after accessing configuration C).
[0084] 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. The configuration prediction model is used to predict the configuration file to be accessed and output the corresponding configuration file identifier.
[0085] Among them, the configuration prediction model is pre-trained. It is possible to collect configuration access information such as access logs, system resource information, temporal features, and correlation features of different devices, as well as the configuration files loaded when the configuration access information is collected as training samples, and use the training samples to train the initial model. When training, the configuration access information is used as the input of the model, the file identifier of the configuration file is used as the output of the model, 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.
[0086] It can be understood that the selection of the initial model can be made according to the 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 a classification task needs to be completed, models that screen key factors according to feature importance, such as random forest and eXtreme Gradient Boosting (XGBoost), can be selected, or a 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 association of "configuration A → configuration B").
[0087] In this embodiment, the historical configuration access information of the current device obtained can be input into a configuration prediction model for prediction, and the file identifier of the configuration file to be accessed soon predicted is output by the configuration prediction model.
[0088] Step 403: Determine the corresponding target file according to the configuration file identifier.
[0089] In this embodiment, after obtaining the configuration file identifier predicted by the configuration prediction model, the corresponding file (referred to as the target file for convenience of description and distinction) can be determined according to the configuration file identifier.
[0090] Step 404: Load the data of the first preset size of the target file, and load the remaining data of the target file by means of asynchronous preloading.
[0091] Among them, the preset size can be set in advance according to actual requirements. For example, the preset size is set to 1MB.
[0092] In this embodiment, for the determined target file, the data of the first preset size of the file can be immediately loaded, and the remaining data of the file can be loaded by means of asynchronous preloading. That is to say, when it is predicted that a certain configuration will be accessed, asynchronous loading is triggered, and different processes are started to load different data of the target file.
[0093] For example, if the preset size is 1MB, the first 1MB data of the target file is immediately loaded, and the subsequent data is asynchronously preloaded. The asynchronous loading can be implemented by the following code: madvise(addr, 1024*1024, MADV_WILLNEED); posix_madvise(addr+1024*1024, file_size-1024*1024, POSIX_MADV_WILLNEED).
[0094] The configuration management method of the network file system according to the embodiment of the present application, by pre-training a configuration prediction model, using the configuration prediction model to predict according to the historical configuration access information of the current device, and obtaining the configuration file identifier to be accessed soon. Thus, it can predict in advance the configuration to be accessed and load it in advance, which is beneficial to improving the configuration loading efficiency. And when loading the target file, the data of the first preset size is loaded first, and then the remaining data is loaded by means of asynchronous preloading, which can further improve the loading efficiency.
[0095] In an alternative embodiment of the present application, for the generated binary file, it can also be synchronized to each node in the cluster to achieve cross-node consistent synchronization of the binary file in the Kubernetes cluster, ensuring that the configurations on all nodes in the cluster are consistent. The synchronization of the binary file can be achieved by combining Kubernetes native resources (such as ConfigMap, DaemonSet), distributed storage (such as S3), and a consistency protocol, 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 the binary file, and ConfigMap records the version metadata. For example, MinIO, AWS S3, or S3-compatible object storage can be used to save the binary file (.bconf), and each file is identified by a unique key (such as the SHA-256 hash value) to ensure the immutability of the content. For the management of metadata, 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 the version management of the binary file, a new hash value is generated each time the binary file is updated, and the old and new versions are recorded to support quick rollback; the configuration status is marked through Kubernetes' Annotation or Label, and the configuration status includes, for example, stable, pending / waiting.
[0096] In the change detection and triggering step, changes can be monitored through the Watch API or a custom controller. For example, the Watch API of Kubernetes can be used to monitor the change events of ConfigMap. When a new version hash value is detected, the node synchronization process is triggered.
[0097] In the synchronization and consistency implementation step, eventual consistency is adopted to ensure data synchronization between nodes in the cluster. The synchronization policy is: the control plane broadcasts the hash value of the new configuration to all nodes, and each node asynchronously pulls the corresponding binary file. The specific synchronization process includes: 1. Metadata update: Update the active-hash in ConfigMap to the new version hash value; 2. Node synchronization: Each node downloads the.bconf file with the corresponding hash value from the object storage according to the new version hash value; then, verify the file integrity of the downloaded.bconf file (such as CRC32 check). If the verification passes, replace the local cache file with the currently downloaded.bconf file and reload the configuration (such as through MMap remapping); 3. Status reporting: The node reports the synchronization status to the control plane, and the synchronization status includes, for example, success or failure; 4. Health check: The control plane monitors the status of all nodes. If there is a timeout (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 a rollback to the previous version is performed.
[0098] The solution of this application also provides a fault tolerance and recovery mechanism, which supports functions such as automatic rollback configuration, node health check, and network partition processing. In addition, performance optimization of cross-node configuration consistency synchronization can be achieved through measures such as incremental synchronization, local caching, parallel transmission, and compression.
[0099] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation method.
[0100] The embodiment of this application also provides a configuration management device for a network file system. Figure 10 As shown in the structure diagram of a configuration management device for a network file system provided by the embodiment of this application, Figure 10 the configuration management device 50 of the network file system includes: an acquisition module 510, a loading module 520, and an access module 530.
[0101] Among them, the acquisition module 510 is used to obtain a first file in response to a configuration loading instruction. The first file is 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. The preset format is used to indicate the memory layout of different configuration information, and the memory layouts of different configuration information are continuous. The configuration information with a nested relationship corresponds to a continuous memory block. The loading module 520 is used to load the content of the first file into the target memory. The access module 530 is used to perform memory access according to the start address of the target memory and the memory layout to read the configuration information.
[0102] Optionally, the preset format is a binary format, the first file is a binary file, and the acquisition module 510 is further used to: Call a text parser to parse the configuration file to generate a configuration syntax tree; Flatten the configuration syntax tree to convert the nested structure in the configuration syntax tree into a continuous memory block; Perform memory alignment detection on the continuous memory block according to a preset alignment strategy; In the case where the memory alignment detection passes, store the configuration information of the configuration syntax tree and the continuous memory block in binary format to obtain the binary file corresponding to the configuration file.
[0103] Optionally, the configuration management device 50 of the network file system further includes: a differential update module, configured to: Upon receiving a modification operation of the user on the configuration file, obtain the modified file; Based on the modified file and the configuration file, determine the differential content of the modified file relative to the configuration file; Compile the differential content into a binary patch file; Based on the binary patch file and the binary file, generate a new binary file; Access the new binary file through a symbolic link.
[0104] For the description of the features in the corresponding embodiments of the configuration management device of the network file system, reference can be made to the relevant descriptions in the corresponding embodiments of the configuration management method of the network file system, which will not be elaborated here one by one.
[0105] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the configuration management method of the network file system.
[0106] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above-mentioned embodiments of the configuration management method of the network file system when running.
[0107] In an exemplary embodiment, the above-mentioned computer-readable storage medium may include, but is not limited to: USB flash drive, read-only memory (ROM for short), random access memory (RAM for short), mobile hard disk, magnetic disk or optical disc, etc., various media that can store computer programs.
[0108] An embodiment of the present application further provides a computer program product. The above-mentioned computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-mentioned embodiments of the configuration management method of the network file system.
[0109] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium. The non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-mentioned embodiments of the configuration management method of the network file system.
[0110] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered as exceeding the scope of this application.
[0111] The above has introduced in detail a configuration management method, an electronic device, a medium, and a product of a network file system provided by this application. Specific examples are used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can still be made to this application, and these improvements and modifications also fall within the protection scope 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 first file is obtained, 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 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; Loading the content of the first file into the target memory; Memory access is performed according to the first address of the target memory and the memory layout to read the configuration information.
2. The configuration management method of a 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 checksum; Before performing the memory access, the method further includes: Detecting whether the magic number is a preset value; In the case where 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, an integrity check is performed based on the full file check 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: When 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, characterized in that: 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 4, characterized in that: The obtaining of the first file comprises: Call the text parser to parse the configuration file and generate a configuration syntax tree; Flattening the configuration syntax tree, and converting the nested structure in the configuration syntax tree into a continuous memory block; Performing memory alignment detection on the continuous memory blocks according to a preset alignment strategy; When the memory alignment check passes, the configuration information of the configuration syntax tree and the continuous memory block are stored in the binary format to obtain a binary file corresponding to the configuration file.
6. The configuration management method of the network file system according to claim 5, characterized in that: The binary format includes a header memory layout, an export block memory layout, and a tail memory layout; The storing 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 multiple export blocks, and storing the block header information of the currently traversed export block and the continuous memory blocks corresponding to the member rules associated with the currently traversed export block according to the export block memory layout; 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.
7. The configuration management method of the network file system according to claim 6, characterized in that: The block header information includes a path character string, and the block header information of the currently traversed export block is stored according to the export block memory layout, including: 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.
8. The configuration management method of a 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 a modified file; Based on the modified file and the configuration file, determining the difference 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.
9. The configuration management method of a network file system according to claim 8, characterized in that: The determining, based on the modified file and the configuration file, the difference between the modified file and the configuration file, comprises: 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.
10. The configuration management method of a network file system according to claim 8, characterized in that: The binary patch file includes at least one patch, each patch including: An operation code, used to identify the operation type, where 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.
11. The configuration management method of a network file system according to claim 10, characterized in that: The generating a new binary file based on the binary patch file and the binary file comprises: 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; According to the target operation code, applying the target data block to the position corresponding to the target offset in the binary file; After the binary patch file is read, the new binary file is obtained.
12. The method for configuration management of a network file system according to any one of claims 1 to 11, 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.
13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the method for configuration management of a network file system as claimed in any one of claims 1 to 12 when executing the computer program.
14. 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 12.
15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the configuration management method of the network file system as claimed in any one of claims 1 to 12 are implemented.
Citation Information
Patent Citations
Method and apparatus for cache data in memory
CN101013400A
Application program operation method and configuration file generating method and device
CN104598263A
Data configuration and loading method and device
CN105915389A
Method and device for updating configuration files of application programs
CN106843842A
Distributed storage data backup method and device
CN111930556A
Cited By
Storage method and device of authentication toolkit, electronic equipment and storage medium
CN120354400A
Configuration file management system of distributed power supply access unit
CN120763116A
A configuration file management system of a distributed power supply access unit
CN120763116B