Data updating method, device and flash memory management system for flash memory device

Abstract

The application relates to a data updating method and device of a flash memory device and a flash memory management system. The method comprises the following steps: mapping a plurality of flash memory devices into corresponding file systems, the file system comprising an index file and at least one data file, the index file comprising a data type identifier, and each data file mapping flash memory data corresponding to the data type identifier in the flash memory device; based on a dynamic allocation mode, establishing a first mounting connection with at least one target file system, reading the content of the index file and the data file corresponding to the to-be-updated data into a cache, and releasing the corresponding first mounting connection; updating the content of the data file read into the cache to obtain updated data; based on the dynamic allocation mode, establishing a second mounting connection with the target file system, writing the updated data into the corresponding target file system, updating the index file and writing the index file into the target file system, and releasing the second mounting connection, so that the problem of increased difficulty in FLASH storage management and high storage management cost is solved.

Description

Technical Field

[0001] This application relates to the field of storage device technology, and in particular to a data update method, apparatus and flash memory management system for a flash memory device. Background Technology

[0002] Flash memory is widely used in embedded systems and various electronic devices due to its non-volatility and durability. However, as device functions become more complex and diverse, storage requirements also become more complex. Different devices and software versions often have significantly different data storage needs, requiring developers to perform customized development for each device or software version. Developers need a deep understanding of the hardware characteristics of flash memory, which directly affect the efficiency and reliability of data storage. This requires meticulous planning and optimization when using flash memory, including partitioning storage blocks and determining erase / write strategies, to achieve optimal performance with limited storage resources. However, as the complexity of stored data increases, the difficulty of managing flash memory based on hardware characteristics increases, requiring developers to spend more time and increasing storage management costs.

[0003] There is currently no effective solution to the problem of high management costs for FLASH storage in related technologies. Summary of the Invention

[0004] This embodiment provides a data update method, apparatus, and flash memory management system for flash memory devices to address the problems of increased difficulty and high cost of FLASH storage management in related technologies.

[0005] In a first aspect, this embodiment provides a data update method for a flash memory device. The method is applied to a host computer in a flash memory management system, which further includes multiple flash memory devices connected to the host computer. The method includes:

[0006] The plurality of flash memory devices are mapped to a plurality of corresponding file systems, wherein the file system includes an index file and at least one data file, the index file includes at least one preset data type identifier, and each data file maps to flash memory data in the flash memory device corresponding to the data type identifier;

[0007] Based on the dynamic allocation method, a corresponding first mount connection is established with at least one target file system corresponding to the data to be updated, the contents of the index file and data file corresponding to the data to be updated are read into the cache and the corresponding first mount connection is released;

[0008] The contents of the data file read into the cache are updated to obtain updated data;

[0009] Based on the dynamic allocation method, a corresponding second mount connection is established with the at least one target file system, the updated data is written to the corresponding target file system, the index file is updated and written to the target file system, and the corresponding second mount connection is released.

[0010] In some embodiments, the flash memory device includes a primary partition and a backup partition, which are respectively mapped to corresponding file systems, wherein:

[0011] The step of reading the contents of the index file and data file corresponding to the data to be updated into the cache includes: sequentially performing deserialization on the index file and data file of the main partition and reading them into the cache;

[0012] The step of writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system includes: sequentially performing serialization on the updated data and the updated index file, and writing them to the file systems corresponding to the primary partition and the backup partition.

[0013] In some embodiments, the step of sequentially deserializing the index file and data file of the primary partition and reading them into the cache includes:

[0014] The index file is deserialized and read into the cache to obtain the first verification information, version information, and data type identifier;

[0015] The first verification information, version information, and data type identifier are matched sequentially with the pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier, respectively.

[0016] If all matching results are consistent, the data file is deserialized and read into the cache.

[0017] In some embodiments, after matching the first verification information, version information, and data type identifier sequentially with pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier, the method further includes:

[0018] If the matching result between the first verification information and the benchmark verification information is inconsistent, the index file corresponding to the backup partition is deserialized and the second verification information is read.

[0019] The second verification information is matched with the benchmark verification information;

[0020] If the matching results are consistent, modify the index file and data file of the primary partition based on the index file and data file of the backup partition.

[0021] In some embodiments, after matching the first verification information, version information, and data type identifier sequentially with pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier, the method further includes:

[0022] If the matching result between the version information and the benchmark version information is inconsistent, it is determined whether the version information is lower than the benchmark version information;

[0023] If so, based on the data type identifier corresponding to the version information, the data file is parsed to obtain the first version data, and the first version data is converted into the second version data corresponding to the base version information;

[0024] If not, then the data file is determined to be abnormal.

[0025] In some embodiments, the flash memory device includes a primary partition and a backup partition, which are respectively mapped to corresponding file systems. The step of establishing a first mount connection with at least one target file system corresponding to the data to be updated, based on a dynamic allocation method, includes:

[0026] The target file system of the primary partition of the flash memory device corresponding to the data to be updated attempts to establish a first mount connection;

[0027] If the connection to the primary partition fails, an attempt is made to establish a first mount connection with the target file system of the backup partition of the flash memory device.

[0028] If the connection to the backup partition fails, format the flash memory device and repeat the above steps until the connection to the primary partition or the backup partition is successful, or the preset number of attempts is reached.

[0029] In some embodiments, after establishing a first mount connection with at least one target file system corresponding to the flash data to be updated based on a dynamic allocation method, the method further includes:

[0030] Determine whether an index file exists in the target file system;

[0031] If no index file exists, create an index file for the target file system.

[0032] Perform serialization of the index file, and write the serialized index file to the primary and backup partitions of the flash memory device corresponding to the flash memory data to be updated.

[0033] In some embodiments, establishing a first mount connection with at least one target file system corresponding to the data to be updated based on a dynamic allocation method, reading the contents of the index file and data file corresponding to the data to be updated into a cache, and releasing the corresponding first mount connection includes:

[0034] Obtain multiple flash memory devices corresponding to the data to be updated;

[0035] The system sequentially requests multiple handles corresponding to the multiple flash memory devices from the handle pool, and establishes a first mount connection with the target file system corresponding to the flash memory device based on the handles; and

[0036] After releasing the first mount connection, the handle is released back into the handle pool;

[0037] The step of establishing a corresponding second mount connection with the at least one target file system based on dynamic allocation, writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system, and releasing the corresponding second mount connection includes:

[0038] Sequentially request multiple handles corresponding to the multiple flash devices from the handle pool, and establish a second mount connection with the target file system corresponding to the flash device based on the handles; and

[0039] After releasing the second mount connection, the handle is released back into the handle pool.

[0040] In some embodiments, updating the contents of the data file read into the cache to obtain updated data includes:

[0041] Each update involves one or more data records in the data file, and the updated data records constitute an updated data file. The content of the data file is obtained by reading one or more data files in the target file system at once, and one or more of the updated data files are written to the corresponding target file system at once.

[0042] In some embodiments, writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system includes:

[0043] Based on the index file, the updated data is serialized and written sequentially to the corresponding data file in the target file system;

[0044] Based on the updated data, the data type identifier, version information, and verification information of the index file are updated;

[0045] Write the updated index file to the target file system.

[0046] In some embodiments, mapping the plurality of flash memory devices to corresponding file systems includes:

[0047] Construct the flash object corresponding to the file system;

[0048] The operation function of the flash memory device is passed as a parameter to the corresponding flash memory object. The operation function is used to perform any one of the initialization, read, or write operations on the flash memory device.

[0049] In some embodiments, the method further includes:

[0050] In the event of a flash memory device replacement, a first mount connection is established with the file system corresponding to the replaced flash memory device, and the contents of the data files and index files in the file system are read into the cache.

[0051] Secondly, this embodiment provides a data update device for a flash memory device. The device is applied to a host computer in a flash memory management system. The flash memory management system further includes multiple flash memory devices connected to the host computer. The device includes:

[0052] A mapping module is used to map the plurality of flash memory devices to corresponding plurality of file systems. The file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier.

[0053] The reading module is used to establish a corresponding first mount connection with at least one target file system corresponding to the data to be updated based on a dynamic allocation method, read the contents of the index file and data file corresponding to the data to be updated into the cache and release the corresponding first mount connection;

[0054] The update module is used to update the content of the data file read into the cache to obtain updated data;

[0055] The write module is used to establish a corresponding second mount connection with the at least one target file system based on a dynamic allocation method, write the updated data to the corresponding target file system, update the index file and write it to the target file system, and release the corresponding second mount connection.

[0056] Thirdly, this embodiment provides a flash memory management system, which includes a host computer and multiple flash memory devices connected to the host computer. The host computer performs storage management on the multiple flash memory devices using the data update method for the flash memory devices described in the first aspect.

[0057] Compared with related technologies, the data update method for flash memory devices provided in this embodiment maps multiple flash memory devices to corresponding file systems. Each file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier. The flash memory devices are mapped to file systems for storage management through pure software abstraction. By setting data types based on actual storage needs using the index file, different storage customization schemes can be implemented, improving the flexibility and scalability of storage management. By establishing corresponding first and second mount connections with at least one target file system corresponding to the data to be updated based on a dynamic allocation method, read and write operations on the flash memory devices are implemented based on the mount connections. This supports parallel read and write operations on multiple flash memory devices while ensuring independent storage management, avoiding data conflicts and interference. By updating the content of the data file read into the cache and executing the data update in the cache, the number of erase / write cycles of the flash memory devices is greatly reduced, extending the lifespan of the flash memory devices.

[0058] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0059] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0060] Figure 1 These are schematic diagrams of flash memory management systems according to some embodiments of this application;

[0061] Figure 2 This is a flowchart of a data update method for a flash memory device according to some embodiments of this application;

[0062] Figure 3 This is a schematic diagram of a file system mapped to a flash memory device according to some embodiments of this application;

[0063] Figure 4 This is a schematic diagram of the storage space allocation of a flash memory device according to some embodiments of this application;

[0064] Figure 5 This is a flowchart illustrating the deserialization of index files and data files in some embodiments of this application;

[0065] Figure 6 This is a flowchart of the verification information matching process in some embodiments of this application;

[0066] Figure 7This is a flowchart of version information matching for some embodiments of this application;

[0067] Figure 8 This is a flowchart illustrating the establishment of a first mount connection according to some embodiments of this application;

[0068] Figure 9 This is a flowchart illustrating the index file creation process of some embodiments of this application;

[0069] Figure 10 This is a flowchart illustrating the dynamic allocation of connection resources in some embodiments of this application;

[0070] Figure 11 This is a flowchart illustrating the writing process of the index file in some embodiments of this application;

[0071] Figure 12 This is a flowchart illustrating a file system mapped to a flash device according to some embodiments of this application;

[0072] Figure 13 This is one of the flowcharts of a data update method for a flash memory device according to some preferred embodiments of this application;

[0073] Figure 14 This is a second flowchart of a data update method for a flash memory device according to some preferred embodiments of this application;

[0074] Figure 15 This is a structural block diagram of a data update apparatus for a flash memory device according to some embodiments of this application. Detailed Implementation

[0075] To better understand the purpose, technical solution, and advantages of this application, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0076] Unless otherwise defined, the technical or scientific terms used in this application shall have the general meaning as understood by one of ordinary skill in the art to which this application pertains. Words such as “a,” “an,” “an,” “the,” “the,” and “these,” used in this application, do not indicate quantitative limitation and may be singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that comprises a series of steps or modules (units) is not limited to the listed steps or modules (units) but may include steps or modules (units) not listed, or may include other steps or modules (units) inherent to such processes, methods, products, or devices. The terms “connected,” “linked,” and “coupled,” used in this application, are not limited to physical or mechanical connections but may include electrical connections, whether direct or indirect. The term “multiple” used in this application refers to two or more. The "and / or" operator describes the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: A alone, A and B simultaneously, and B alone. Typically, the character " / " indicates that the objects before and after it are in an "or" relationship. The terms "first," "second," and "third," etc., used in this application are merely for distinguishing similar objects and do not represent a specific ordering of the objects.

[0077] The data update method for flash memory devices provided in this application embodiment can be executed in a host computer applied to a flash memory management system. The flash memory management system includes a host computer and multiple flash memory devices connected to the host computer. Figure 1 These are schematic diagrams of flash memory management systems according to some embodiments of this application, such as... Figure 1 As shown, the flash memory device in this embodiment can be a hardware FLASH memory or a virtual FLASH device. The FLASH memory can be connected to the host computer via a hardware device or a relay device.

[0078] A virtual flash device refers to a storage system that doesn't concern itself with the specific type or implementation of the storage device, but only with the understanding that the storage device can be read and written in fixed-size blocks and accessed through specific disk I / O functions. All flash devices mounted at the endpoints can be broadly categorized as a type of virtual flash device. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the flash memory management system described above. For example, the flash memory management system may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown are illustrated.

[0079] This embodiment provides a data update method for a flash memory device. Figure 2 This is a flowchart of a data update method for a flash memory device according to some embodiments of this application, such as... Figure 2 As shown, the process includes the following steps:

[0080] Step S201: Map multiple flash memory devices to multiple corresponding file systems. The file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier.

[0081] Figure 3 This is a schematic diagram of a file system mapped to a flash memory device according to some embodiments of this application. For example... Figure 3 As shown, the storage space of each flash memory device includes a file boot information area, a data index information area, and a data area. This embodiment maps the flash memory device to a file system, which includes an index file DataIndex and at least one data file DataX (X = A, B, C…). Different data files DataX can store data with different data structures, including but not limited to multi-level nested structures, variable-length data structures, sparse matrices, etc. Each integrated data information is mapped to an independently existing data file DataX.

[0082] The index file DataIndex is used to store the index information corresponding to each data file. Specifically, it can include the name of the data file and the data type identifier typeID. The typeID can be a unique data type identifier obtained through data packaging.

[0083] Furthermore, the index file may also include verification information for each data file, as well as version information for the index file.

[0084] Step S202: Based on the dynamic allocation method, establish a corresponding first mount connection with at least one target file system corresponding to the data to be updated, read the contents of the index file and data file corresponding to the data to be updated into the cache, and release the corresponding first mount connection.

[0085] The target file system refers to the file system corresponding to the flash memory device where the data to be updated resides. When data in the flash memory device needs to be updated, the data can be read into a cache first, updated in the cache, and then written to the flash memory device, thus reducing the number of erase and write operations on the flash memory device. Therefore, for one or more flash memory devices that need to update flash data, a first mount connection can be established with the target file system of the flash memory device through dynamic allocation. Dynamic allocation refers to dynamically requesting connection resources and releasing them after completing read or write operations, allowing other target file systems to continue using them. When there are multiple connection resources, parallel execution of read or write operations on the target file systems of multiple flash memory devices can be supported.

[0086] Mounting a file system refers to associating the target file system of a flash memory device with the file system of the operating system through a specified directory as the mount point. In this embodiment, a first mount connection needs to be established before a read operation. After the first mount connection is established, the operating system can perform read operations on the target file system of the flash memory device, and release the mount connection after the read operation is completed so that other target file systems can continue to use the connection resource. The read operation on the target file system refers to reading the data file and index file corresponding to the data to be updated into the cache.

[0087] Step S203: Update the contents of the cached data file to obtain updated data.

[0088] The contents of the cached data file are updated. The update can be done in one go or in multiple parts, updating a portion of the data each time.

[0089] In a further embodiment, each update involves one or more data records in the content of the data file, and the multiple updated data records constitute an updated data file; the updated data is a set of updated data records.

[0090] The content of the data file is obtained by reading data files from one or more target file systems at once, and the one or more updated data files are written to the corresponding target file systems at once. In this embodiment, the data to be updated is distributed across one or more target file systems. Before updating, the content of the corresponding data files is read into a cache at once through a first mount connection with one or more target file systems. "Reading in one go" means reading the content of all data files corresponding to the data to be updated into the cache, even if these contents belong to different data files and different target file systems. These contents can be of the same or different data types.

[0091] The data file can contain multiple data records, which may belong to different data files. Each update may update only one or more data records. After all data records have been updated, the updated data file, composed of these data records, is written to the corresponding target file system all at once. Each data file corresponds to an independent integrated data structure. For scattered multi-dimensional structures, tuples can be used for packaging, and corresponding data type identifiers (typeIDs) can be generated. The data update method for flash memory devices in this embodiment improves data read and write efficiency, significantly reduces the number of erase and write cycles of the flash memory device, and further extends the lifespan of the flash memory device.

[0092] Step S204: Based on the dynamic allocation method, establish a corresponding second mount connection with at least one target file system, write the updated data to the corresponding target file system, update the index file and write it to the target file system, and release the corresponding second mount connection.

[0093] Similar to read operations, a second mount connection needs to be established before a write operation. Once established, the operating system can perform write operations on the target file system of the flash memory device and release the mount connection after the write operation is complete, allowing other target file systems to continue using this connection resource. Write operations on the target file system include writing updated data from the cache to the corresponding data files in the target file system. When multiple data files need to be written, the updated data can be written sequentially to the corresponding data files based on the order of the data files in the index file.

[0094] Then, based on the updated data written, the typeID, verification information, and version information in the index file are updated, and the updated index file is written to the target file system. Finally, the corresponding second mount connection is released.

[0095] Through steps S201 to S204, multiple flash memory devices are mapped to corresponding file systems. Each file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier. The flash memory devices are mapped to file systems for storage management through pure software abstraction. Data types are set based on actual storage needs using the index file, enabling different customized storage solutions and improving the flexibility and scalability of storage management. By establishing a first mount connection and a second mount connection with at least one target file system corresponding to the data to be updated using a dynamic allocation method, read and write operations on the flash memory devices are implemented based on the mount connections. This supports parallel read and write operations on multiple flash memory devices while ensuring independent storage management, avoiding data conflicts and interference. By updating the content of the data files read into the cache and executing the data update in the cache, the number of erase / write cycles on the flash memory devices is greatly reduced, extending their lifespan.

[0096] In some embodiments, Figure 4 This is a schematic diagram of the storage space allocation of a flash memory device according to some embodiments of this application, such as... Figure 4 As shown, the flash memory device includes a primary partition and a backup partition, which are mapped to corresponding file systems. This embodiment involves reading the contents of the index file and data file corresponding to the data to be updated into a cache, writing the updated data to the corresponding target file system, updating the index file, and writing it to the target file system.

[0097] The method for reading the contents of the index file and data file corresponding to the data to be updated in the flash memory into the cache includes: performing deserialization on the index file and data file of the main partition in sequence and reading them into the cache;

[0098] The method for writing updated data to the corresponding target file system and updating the index file and writing it to the target file system includes: sequentially performing serialization on the updated data and the updated index file, and writing them to the file systems corresponding to the primary partition and the backup partition.

[0099] In this embodiment, data objects are converted into byte streams using serialization technology and stored in a mapped file. The serialization process supports compressed storage of complex data structures such as sparse matrices. When reading data, both the index file and the data file contain byte streams, requiring deserialization before being read into the cache. Specifically, a first mount connection can be established with the file system of the flash memory device containing the data to be updated. First, the index file of the primary partition is deserialized and read into the cache to obtain data type identifiers, verification information, and version information. Then, the data file of the primary partition is deserialized and read into the cache to obtain the data to be updated, and the corresponding first mount connection is released.

[0100] The cached data file contains multiple data records, which may belong to different data files. Updated data refers to the collection of updated data records. Once all data records have been updated, the updated data is obtained, and the updated data file, composed of these data records, is serialized and written to the corresponding target file system. In this embodiment, the updated data is serialized to obtain several serialized updated data files, which are then serialized and written to the corresponding target file system.

[0101] Specifically, when writing data, a second mount connection is first established with the file system of the flash memory device. The updated data in the cache is serialized into a byte stream. According to the order of each data file in the index file, the byte stream is written to each data file in the primary partition and the backup partition in sequence. Then, according to the content written to the data file, the data type identifier, verification information and version information in the index file are updated, and serialization is performed to convert it into a byte stream. The byte stream is then written to the index file in the primary partition and the backup partition, and the corresponding second mount connection is released.

[0102] The data update method for flash memory devices in this embodiment converts data into a byte stream for storage by sequentially deserializing the index file and data file during read operations and sequentially serializing the updated data file and updated index file during write operations. This supports compressed storage of complex data structures such as sparse matrices, effectively avoiding memory gaps caused by direct storage and thus optimizing storage space utilization. It also avoids the need for developers to solve the conversion problems of complex nested data structures, reducing development cycles and maintenance costs. Fast switching between primary and backup partitions ensures the continuity, reliability, and stability of the storage system.

[0103] In some embodiments, Figure 5 This is a flowchart illustrating the deserialization of index files and data files in some embodiments of this application, such as... Figure 5 As shown, the process includes the following steps:

[0104] Step S501: Deserialize the index file and read it into the cache to obtain the first verification information, version information and data type identifier.

[0105] The index file and data file are stored in the flash memory device as byte streams. In this embodiment, the index file and data file are stored in the main partition. The index file is deserialized, and the byte stream is converted into index information and then read into the cache. The index information includes first verification information, version information, and data type identifier.

[0106] Step S502: The first verification information, version information, and data type identifier are matched sequentially with the pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier.

[0107] The baseline verification information, baseline version information, and baseline data type identifier are obtained in advance. The matching of the first verification information is used to verify the correctness of the data file. In practical applications, bad blocks may appear in flash memory devices during read and write operations, leading to data errors. Verification technology is used to verify the integrity of stored data. The first verification information is generated by calculating the content of the data file based on existing verification algorithms. If the first verification information does not match, it indicates that the data file content is abnormal.

[0108] Version information matching is used to verify whether the update status of the data file is correct. The version information of the index file is updated every time the data file is updated. If the version information does not match, it means that the data file stored on the flash memory device has not been updated in time, or the index file is abnormal.

[0109] Matching data type identifiers is used to determine the data type of the data file. Different data types correspond to different parsing methods. If the data type identifiers do not match, the data file cannot be parsed correctly.

[0110] Step S503: If the matching results are consistent, perform deserialization on the data file and read it into the cache.

[0111] If the matching results of the first verification information, version information, and data type identifier are consistent, it is determined that there are no errors in the contents of the index file and the data file. At this time, deserialization is performed on the data file to convert the byte stream into the data to be updated. Based on the parsing method corresponding to the data type of the data file, the data to be updated is parsed and read into the cache.

[0112] Through steps S501 to S503, the index file is deserialized and read into the cache to obtain the first verification information, version information, and data type identifier. These are then matched sequentially with the pre-obtained baseline verification information, baseline version information, and baseline data type identifier. Based on the matching results, it is determined whether the index file and data file are abnormal. If the matching results are consistent, the data file is deserialized and read into the cache, ensuring the correctness and integrity of data reading from the flash memory device.

[0113] In some embodiments, Figure 6 This is a flowchart of the verification information matching process for some embodiments of this application, such as... Figure 6 As shown, the process includes the following steps:

[0114] Step S601: If the matching result of the first verification information and the baseline verification information is inconsistent, deserialize the index file corresponding to the backup partition and read the second verification information.

[0115] The first verification information is obtained by deserializing the index file of the primary partition of the flash memory device. If the first verification information does not match the baseline verification information, the data file content of the primary partition is considered abnormal. In this case, the index file in the backup partition is deserialized to obtain the second verification information.

[0116] Step S602: Match the second verification information with the baseline verification information.

[0117] Step S603: If the matching results are consistent, modify the index file and data file of the primary partition based on the index file and data file of the backup partition.

[0118] If the second verification information matches the baseline verification information, it can be determined that the data file content of the backup partition is correct. At this point, the index file and data file of the primary partition can be modified based on the index file and data file of the backup partition. Specifically, the contents of the index file and data file of the backup partition are overwritten with the index file and corresponding data file of the primary partition.

[0119] Through steps S601 to S603, if the matching result of the first verification information and the baseline verification information is inconsistent, the second verification information in the index file corresponding to the backup partition is read and matched with the baseline verification information. If the data file content of the main partition is abnormal, it is determined whether the data file of the backup partition is abnormal. If the matching result is consistent, the index file and data file of the main partition are modified based on the index file and data file of the backup partition to realize the recovery of abnormal data, thereby improving the security, accuracy and reliability of data storage.

[0120] In some embodiments, Figure 7 This is a flowchart of version information matching for some embodiments of this application, such as... Figure 7 As shown, the process includes the following steps:

[0121] Step S701: If the matching result between the version information and the baseline version information is inconsistent, determine whether the version information is lower than the baseline version information.

[0122] Step S702: If yes, then based on the data type identifier corresponding to the version information, parse the data file to obtain the first version data, and convert the first version data into the second version data corresponding to the base version information.

[0123] If the version information is lower than the baseline version information, it means that the data file corresponding to the index file has not been updated in time. In this case, the data file after deserialization is parsed according to the data type identifier in the index file to obtain the first version data. Then, based on the baseline data type identifier corresponding to the baseline version information, the data structure of the first version data is transformed into the second version data, which is stored in the cache and awaits data updates.

[0124] Step S703: If not, then determine that the data file is abnormal.

[0125] If the version information is higher than the baseline version information, which is usually the latest version, it indicates that there is an anomaly in the data file or index file. In this case, an alarm message can be sent to notify relevant personnel that there is a file error.

[0126] Through steps S701 to S703, if the matching result between the version information and the baseline version information is inconsistent, it is determined whether the version information is lower than the baseline version information. If it is lower than the baseline version information, the data file is parsed based on the data type identifier corresponding to the version information to obtain the first version data, and the first version data is converted into the second version data corresponding to the baseline version information. This realizes the data structure conversion of the data file, avoids the problem of parsing errors caused by using inappropriate parsing methods to parse the data file, and improves the reliability of data reading.

[0127] In some embodiments, Figure 8 This is a flowchart illustrating the establishment of a first mount connection in some embodiments of this application, such as... Figure 8 As shown, the process includes the following steps:

[0128] In step S801, the target file system of the primary partition of the flash memory device corresponding to the flash memory data to be updated attempts to establish a first mount connection.

[0129] In practical use, you can first mount the target file system of the main partition of the flash memory device using the mount command, and then perform multiple mount attempts by pre-setting the number of mount attempts.

[0130] In step S802, if the attempt to connect to the primary partition fails, an attempt is made to establish a first mount connection with the target file system of the backup partition of the flash memory device.

[0131] If multiple attempts fail, mount the backup partition of the flash memory device using the mount command. The number of mount attempts can be preset to perform multiple mount attempts.

[0132] Step S803: If the connection attempt to the backup partition fails, format the flash memory device and repeat the above steps until the connection to the primary partition or backup partition is successful, or the preset number of attempts is reached.

[0133] If both the primary and backup partitions fail to mount, it can be determined that the flash memory device does not have primary or backup partitions and contains no stored data. In this case, the flash memory device needs to be formatted and partitioned into primary and backup partitions. Then, steps S801 to S803 are repeated until a first mount connection is established with the target file system of the primary or backup partition, or the process terminates after a preset number of attempts is reached.

[0134] The method for establishing the first mount connection in this embodiment is also applicable to establishing the second mount connection.

[0135] Through steps S801 to S803, a mount connection is automatically established when the flash memory device is an empty disk, avoiding connection errors when the flash memory device is an empty disk and improving the reliability of data read or write operations.

[0136] In some embodiments, Figure 9 This is a flowchart of the index file creation process of some embodiments of this application, such as... Figure 9 As shown, the process includes the following steps:

[0137] Step S901: Determine whether an index file exists in the target file system.

[0138] When the flash memory device is empty, a mount connection is established after formatting in the above embodiment, but the index file does not exist in the file system, making read operations impossible. Therefore, before reading the index file, it can be determined whether the index file exists in the target file system. If it exists, the index file is directly deserialized and read into the cache.

[0139] Step S902: If no index file exists, create an index file for the target file system.

[0140] If the index file does not exist in the target file system, a new index file will be created. The verification information, version information, and data type identifier information can use pre-set default values.

[0141] Step S903: Serialize the index file and write the serialized index file to the primary and backup partitions of the flash memory device corresponding to the flash memory data to be updated.

[0142] The index file is serialized into a byte stream and written to the primary and backup partitions of the flash memory device.

[0143] Through steps S901 to S903, by determining whether an index file exists in the target file system, and if no index file exists, an index file for the target file system is created, the index file is serialized, and written to the primary and backup partitions of the flash memory device corresponding to the flash memory data to be updated. This ensures that the read operation is successfully performed even when the flash memory device is empty, thus improving the reliability of the data read operation.

[0144] In some embodiments, Figure 10 This is a flowchart of the dynamic allocation of connection resources in some embodiments of this application, such as... Figure 10 As shown, the process includes the following steps:

[0145] Step S1001: Obtain multiple flash memory devices corresponding to the flash memory data to be updated.

[0146] When the flash memory data to be updated is stored on multiple flash memory devices, it is necessary to establish a first mount connection and a second mount connection for each of the multiple flash memory devices. This embodiment allocates corresponding connection resources to the multiple flash memory devices dynamically. Specifically, the handle is used as an identifier for the connection resource allocation, and the mount connection is established through the handle.

[0147] Step S1002: Sequentially request multiple handles corresponding to multiple flash devices from the handle pool, and establish a first mount connection with the target file system corresponding to the flash device based on the handle.

[0148] Specifically, based on the data update order of multiple flash memory devices, multiple handles can be requested sequentially from the handle pool, with each handle corresponding to one flash memory device. When the number of handles in the handle pool is less than the number of flash memory devices, it is necessary to wait for the read operations of other flash memory devices to complete and release the first mount connection and the corresponding handle before acquiring the handle resource. After acquiring the handle, a first mount connection is established with the target file system corresponding to the flash memory device, and a read operation is performed.

[0149] Step S1003: After releasing the first mount connection, release the handle back into the handle pool.

[0150] After the data reading is complete, the first mount connection is released, and then the handle is released back into the handle pool for other flash devices to establish mount connections.

[0151] The method for dynamically allocating connection resources in this embodiment is also applicable to the establishment and release of the second mounted connection. The steps for establishing and releasing the second mounted connection by dynamically allocating connection resources include:

[0152] Step S31: Sequentially request multiple handles corresponding to multiple flash devices from the handle pool, and establish a second mount connection with the target file system corresponding to the flash device based on the handle.

[0153] Specifically, multiple handles can be requested from the handle pool sequentially according to the data writing order of multiple flash devices, with each handle corresponding to one flash device. After obtaining the handle, a second mount connection is established with the target file system corresponding to the flash device, and write operations are performed.

[0154] Step S32: After releasing the second mount connection, release the handle back into the handle pool.

[0155] Through steps S1001-S1003 and S31-S32, multiple flash memory devices corresponding to the flash memory data to be updated are obtained, and multiple handles corresponding to the multiple flash memory devices are requested from the handle pool in sequence. Based on the handles, a first mount connection and a second mount connection are established with the target file system corresponding to the flash memory device to realize dynamic allocation of connection resources. After releasing the first mount connection and the second mount connection, the handles are released back to the handle pool. After the read operation is completed, the resources are released, supporting concurrent read and write of an unlimited number of flash memory devices when connection resources are limited.

[0156] In some embodiments, Figure 11 This is a flowchart illustrating the writing process of the index file in some embodiments of this application, such as... Figure 11 As shown, the process includes the following steps:

[0157] Step S1101: Based on the index file, the update data is serialized and written sequentially to the corresponding data files in the target file system.

[0158] Once the data in the cache has been updated, the updated data is serialized, converted into a byte stream, and written to the corresponding data file in the target file system, including the primary partition and backup partition. When multiple data files exist, they can be written sequentially based on the order of the data files in the index file.

[0159] Step S1102: Based on the updated data, update the data type identifier, version information, and verification information of the index file.

[0160] Based on the updated data written to each data file, the data type identifier, version information, and verification information corresponding to each data file in the index file are updated.

[0161] Step S1103: Write the updated index file to the target file system.

[0162] The index file is serialized and then written to the primary and backup partitions of the target file system.

[0163] Through steps S1101 to S1103, based on the index file, the updated data is sequentially written to the corresponding data file in the target file system. Based on the updated data, the data type identifier, version information, and verification information of the index file are updated. The updated index file is then written to the target file system, thus updating the index file in a timely manner and providing accurate index information for the next data update.

[0164] In some embodiments, Figure 12 This is a flowchart of a flash device mapping file system according to some embodiments of this application, such as... Figure 12 As shown, the process includes the following steps:

[0165] Step S1201: Construct the flash object corresponding to the file system.

[0166] An abstract flash memory object is constructed in software to serve as a mapping object for the physical device.

[0167] Step S1202: Pass the operation function of the flash memory device as a parameter to the corresponding flash memory object. The operation function is used to perform any one of the initialization, read, or write operations on the flash memory device.

[0168] The operation functions for a physical device can be hardware initialization, hardware block read, and hardware block write. These operation functions are used to perform corresponding hardware operations on the physical device. By passing these three operation functions as parameters to the constructed flash memory object, the abstract flash memory object is bound to the physical device, thereby achieving the mapping between the flash memory device and the file system.

[0169] In some embodiments, a hot reload method is also involved in the event of flash memory device replacement. The method includes:

[0170] In the event of a flash memory device replacement, a first mount connection is established with the file system corresponding to the replaced flash memory device, and the contents of the data files and index files in the file system are read into the cache.

[0171] When the storage system detects the need for a software update or data switch, it initiates a hot reload (dynamic loading) mechanism to ensure the update operation is completed without shutting down the system. This update includes both data structure and data updates. If data anomalies occur, the system will switch to backup files and perform data recovery using verified information. Hot reload is implemented directly through read operations on the flash memory device.

[0172] In one specific embodiment, 16 abstract flash memory objects correspond to 16 hardware devices. When a hardware device is replaced, there is no need to restart the software system or change the code. It is only necessary to read the updated hardware device again and execute the mounting and reading cache process in step S202.

[0173] The data update method for flash memory devices in this embodiment dynamically detects changes in the file system and loads new data based on a hot reload mechanism, ensuring that the storage system can update data in a timely manner during operation, thus guaranteeing the high availability and flexibility of the storage system.

[0174] The present embodiment will now be described and illustrated through preferred embodiments.

[0175] Figure 13 This is one of the flowcharts of a data update method for a flash memory device according to some preferred embodiments of this application, including initialization and data reading in the data update method; Figure 14 This is a second flowchart of a data update method for a flash memory device according to some preferred embodiments of this application, including data update and data writing in the data update method. Figure 13 As shown, the initialization and data reading in the data update method of this preferred embodiment include the following steps:

[0176] Step S1301: Construct the flash object corresponding to the file system;

[0177] Step S1302: Pass the operation function of the flash memory device as a parameter to the corresponding flash memory object to complete the mapping between the flash memory device and the file system;

[0178] Step S1303: Check the target flash memory device corresponding to the data to be updated to determine if there is any abnormality. If there is an abnormality, end the process.

[0179] Step S1304: Attempt to establish a first mount connection with the primary partition of the target flash memory device;

[0180] Step S1305: If the connection with the primary partition fails, attempt to establish a first mount connection with the backup partition of the target flash memory device;

[0181] Step S1306: If the connection to the backup partition fails, format the flash memory device and determine whether the preset number of attempts has been reached. If not, proceed to step S1304.

[0182] Step S1307: If a first mount connection is established with the primary partition or backup partition, determine whether the index file of the partition exists.

[0183] Step S1308: If an index file does not exist, create an index file for the target flash memory device;

[0184] Step S1309: Serialize the index file and write the serialized index file to the primary partition and backup partition of the target flash memory device;

[0185] Step S1310: Deserialize the primary partition index file to obtain the first verification information, version information, and data type identifier;

[0186] Step S1311: Match the first verification information with the pre-acquired benchmark verification information;

[0187] Step S1312: If the matching results are inconsistent, read the second verification information from the index file corresponding to the backup partition;

[0188] Step S1313: Match the second verification information with the baseline verification information;

[0189] Step S1314: If the matching results are consistent, restore the corresponding files of the main partition based on the index file and data file of the backup partition;

[0190] Step S1315: Match the version information with the pre-acquired baseline version information;

[0191] Step S1316: In the case of inconsistent matching results, determine whether the version information is lower than the baseline version information;

[0192] Step S1317: If yes, then based on the data type identifier corresponding to the version information, parse the data file to obtain the first version data, and convert the first version data into the second version data corresponding to the base version information; if no, then end the process.

[0193] Step S1318: Match the data type identifier with the pre-acquired baseline data type identifier;

[0194] Step S1319: If the matching results are consistent, perform deserialization on the data file and read it into the cache;

[0195] Step S1320: Release the first mount connection.

[0196] Through steps S1301 to S1320, the flash memory device is mapped to a file system for storage management through pure software abstraction. Data types are set based on actual storage needs using an index file, enabling different customized storage solutions and improving the flexibility and scalability of storage management. Data is converted into byte streams for storage through serialization, supporting compressed storage of complex data structures such as sparse matrices, effectively avoiding memory gaps caused by direct storage and thus optimizing storage space utilization. Dynamically allocated mount connections enable read operations on the flash memory device, supporting parallel reads from multiple flash memory devices with independent storage management, avoiding data conflicts and interference. Primary and backup partitions enable rapid switching of data read operations, ensuring the continuity, reliability, and stability of the storage system. A verification mechanism ensures the correctness and integrity of data reads from the flash memory device. Version information and data type identifiers ensure timely updates of the index file and the correctness of the data structure.

[0197] like Figure 14 As shown, the data update method of this preferred embodiment includes the following steps for data update and data writing:

[0198] Step S1401: Update the content of the data file read into the cache. Each update involves one or more data records in the data file. Multiple updated data records constitute an updated data file. The content of this data file is obtained by reading one or more data files in the target file system at once. One or more updated data files are written to the corresponding target file system at once.

[0199] In some specific embodiments, a data file DataA of a flash memory device includes 100 data records. After being read into the cache all at once, one record is updated each time, for a total of 100 updates, and then written into the data file all at once.

[0200] Step S1402: Check the target flash memory device corresponding to the updated data to determine if there is any abnormality. If there is an abnormality, end the process.

[0201] Step S1403: Establish a second mount connection with the primary or backup partition of the target flash memory device;

[0202] The specific steps can be the same as steps S1304 to S1306.

[0203] Step S1404: Perform serialization on the updated data;

[0204] Step S1405: Based on the sorting of each data file in the index file, the serialized update data is written sequentially to each data file in the primary partition and the backup partition.

[0205] Step S1406: Based on the updated data, update the data type identifier, version information, and verification information of the index file;

[0206] Step S1407: Write the updated index file to the primary partition and backup partition of the target file system;

[0207] Step S1408: Release the second mount connection.

[0208] Through steps S1401 to S1408, write operations on flash memory devices are achieved through dynamically allocated mount connections, supporting parallel writing of multiple flash memory devices with independent storage management, thus avoiding data conflicts and interference. By placing data updates in the cache, the number of erase / write cycles of flash memory devices is greatly reduced, extending the lifespan of flash memory devices. Data is converted into byte streams for storage through serialization, supporting compressed storage of complex data structures such as sparse matrices, effectively avoiding memory gaps caused by direct storage, thereby optimizing storage space utilization. Version information and data type identifiers ensure timely updates of index files and the correctness of data structures.

[0209] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0210] In some embodiments, this application also provides a data update apparatus for a flash memory device, which is applied to... This data update apparatus for a flash memory device is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. The terms "module," "unit," "subunit," etc., used below refer to combinations of software and / or hardware that implement a predetermined function. In some embodiments, Figure 15 This is a structural block diagram of the data update apparatus of the flash memory device in this embodiment, as shown below. Figure 15 As shown, the device includes:

[0211] The mapping module 1501 is used to map multiple flash memory devices to corresponding multiple file systems. The file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier.

[0212] The reading module 1502 is used to establish a corresponding first mount connection with at least one target file system corresponding to the flash data to be updated based on a dynamic allocation method, read the contents of the index file and data file corresponding to the flash data into the cache and release the corresponding first mount connection.

[0213] Update module 1503 is used to update the contents of the read-in cached data file to obtain updated data;

[0214] The write module 1504 is used to establish a corresponding second mount connection with at least one target file system based on dynamic allocation, write updated data to the corresponding target file system, update the index file and write it to the target file system, and release the corresponding second mount connection.

[0215] The data update device for the flash memory device in this embodiment maps multiple flash memory devices to corresponding file systems through the mapping module 1501. Each file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier. The flash memory devices are mapped to file systems for storage management through pure software abstraction. Data types are set based on actual storage needs using the index file, enabling different customized storage solutions and improving the flexibility and scalability of storage management. The read module 1502 and write module 1504 establish corresponding first and second mount connections with at least one target file system corresponding to the data to be updated, based on a dynamic allocation method. Read and write operations on the flash memory devices are implemented based on these mount connections, supporting parallel read and write operations on multiple flash memory devices while ensuring independent storage management, thus avoiding data conflicts and interference. The update module 1503 updates the content of the data files read into the cache, placing the data updates in the cache for execution, which greatly reduces the number of erase / write cycles of the flash memory devices and extends their lifespan.

[0216] In some embodiments, this application also provides a flash memory management system, which includes a host computer and multiple flash memory devices connected to the host computer. The host computer performs storage management on the multiple flash memory devices using the data update method for the flash memory devices described in the above embodiments.

[0217] Specifically, the flash memory management system may include:

[0218] Hardware Abstraction Layer (HAL):

[0219] This layer is responsible for direct interaction with the underlying hardware (i.e., FLASH memory). It provides an abstract interface to the upper layers, freeing them from the details of the hardware implementation. Its main functions include reading and writing to the FLASH memory, managing FLASH memory erase and write operations, and providing memory status information. This is achieved by encapsulating the underlying hardware operations through a set of API functions (such as hardware initialization `device_initial()`, hardware read `read_block()`, hardware write `write_block()`, etc.). The hardware abstraction layer is typically optimized for specific hardware platforms to ensure efficient read and write operations.

[0220] File System Layer:

[0221] The file system layer is one of the core layers of the system, responsible for mapping the FLASH memory to one or more files within the file system. This layer organizes, stores, and retrieves data through file system management mechanisms (such as FATFS or LittleFS), making data access more standardized and modular. In this embodiment, each integrated data piece of information is mapped to a file; different data structures are combined into different files; and the type information of all data structures is summarized in an index file, providing data type verification and CRC checksums, thereby providing secure and customizable data storage for multiple modules. Implementation involves initializing, formatting, creating, reading, and writing files within the file system, and combining these operations with the API functions of the hardware abstraction layer. Different file system formats are supported to adapt to different application scenarios, such as FATFS and LittleFS commonly used in embedded systems.

[0222] Data Serialization and Deserialization Layer:

[0223] This layer is responsible for serializing data objects into byte streams and writing them to the file system, or deserializing byte streams stored in the file system back into data objects. It uses serialization techniques (such as Protobuf, Boost.Serialization, or YAS) to convert complex data structures into byte stream formats suitable for storage and transmission. When dealing with sparse matrices, this layer supports compressed storage of serialized data, avoiding memory gaps and wasted space caused by direct storage. By implementing serialization and deserialization interfaces, the application layer can store and retrieve data by calling these interfaces. Combined with the file system layer's API, it enables efficient storage and retrieval of data.

[0224] Verification, Cache, and Hot Reload Management Layer:

[0225] The caching mechanism is implemented at this layer, responsible for reducing frequent writes to the file system during data update operations, reducing FLASH memory wear, and improving system performance. The hot reload mechanism is implemented at this layer, supporting dynamic updates of data in the file system during application runtime, ensuring high availability and flexibility of the system. Verification and data backup mechanisms are implemented at this layer, ensuring data consistency and integrity during hot reload or other data updates. A caching module is implemented to store recently accessed or updated data and write it to the file system when necessary. File monitoring and hot reload logic is implemented to dynamically detect file changes and load new data, ensuring timely data updates during system runtime. Backup and rollback mechanisms are implemented to restore the system to a previous stable state in case of data update failure or anomalies.

[0226] Application Layer:

[0227] The application layer is the top layer of the system, responsible for calling various functional interfaces provided by the underlying layers to implement specific business logic. This layer may include specific functional modules such as target data storage, configuration management, and log management. The application layer stores and retrieves data by calling the interfaces of the file system layer and the data serialization layer. The application layer can directly interact with the caching and hot reload management layer to achieve efficient data management and dynamic updates.

[0228] In this embodiment of the flash memory management system, the host computer manages the storage of multiple flash memory devices using the data update method of the flash memory devices described in the above embodiment. The flash memory devices are mapped to a file system for storage management through pure software abstraction, and data types are set based on actual storage needs through index files, which can realize different storage customization schemes, improving the flexibility and scalability of storage management. It also supports parallel read and write of multiple flash memory devices while the storage management is independent of each other, avoiding data conflicts and interference. Furthermore, it reduces the number of erase and write cycles of the flash memory devices and extends their service life.

[0229] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated in this embodiment.

[0230] It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. All other embodiments derived by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0231] Obviously, the accompanying drawings are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar situations based on these drawings without any creative effort. Furthermore, it is understood that although the work done in this development process may be complex and lengthy, for those skilled in the art, certain design, manufacturing, or production modifications made based on the technical content disclosed in this application are merely conventional technical means and should not be considered as insufficient disclosure of this application.

[0232] The term "embodiment" in this application refers to a specific feature, structure, or characteristic described in connection with an embodiment that may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily imply the same embodiment, nor does it imply that it is mutually exclusive with or independent of other embodiments. It will be clearly or implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0233] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of patent protection. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the appended claims.

Claims

1. A data update method for a flash memory device, characterized in that, The method is applied to a host computer in a flash memory management system, the flash memory management system further including multiple flash memory devices connected to the host computer, and the method includes: The plurality of flash memory devices are mapped to a plurality of corresponding file systems, wherein the file system includes an index file and at least one data file, the index file includes at least one preset data type identifier, and each data file maps to flash memory data in the flash memory device corresponding to the data type identifier; Based on the dynamic allocation method, a corresponding first mount connection is established with at least one target file system corresponding to the data to be updated, the contents of the index file and data file corresponding to the data to be updated are read into the cache and the corresponding first mount connection is released; The contents of the data file read into the cache are updated to obtain updated data; Based on the dynamic allocation method, a corresponding second mount connection is established with the at least one target file system, the updated data is written to the corresponding target file system, the index file is updated and written to the target file system, and the corresponding second mount connection is released.

2. The method according to claim 1, characterized in that, The flash memory device includes a primary partition and a backup partition, which are respectively mapped to corresponding file systems, wherein: The step of reading the contents of the index file and data file corresponding to the data to be updated into the cache includes: sequentially performing deserialization on the index file and data file of the main partition and reading them into the cache; The step of writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system includes: sequentially performing serialization on the updated data and the updated index file, and writing them to the file systems corresponding to the primary partition and the backup partition.

3. The method according to claim 2, characterized in that, The step of sequentially deserializing the index file and data file of the primary partition and reading them into the cache includes: The index file is deserialized and read into the cache to obtain the first verification information, version information, and data type identifier; The first verification information, version information, and data type identifier are matched sequentially with the pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier, respectively. If all matching results are consistent, the data file is deserialized and read into the cache.

4. The method according to claim 3, characterized in that, After matching the first verification information, version information, and data type identifier with the pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier in sequence, the method further includes: If the matching result between the first verification information and the benchmark verification information is inconsistent, the index file corresponding to the backup partition is deserialized and the second verification information is read. The second verification information is matched with the benchmark verification information; If the matching results are consistent, the index file and data file of the primary partition are modified based on the index file and data file of the backup partition.

5. The method according to claim 3, characterized in that, After matching the first verification information, version information, and data type identifier with the pre-acquired benchmark verification information, benchmark version information, and benchmark data type identifier in sequence, the method further includes: If the matching result between the version information and the benchmark version information is inconsistent, it is determined whether the version information is lower than the benchmark version information; If so, based on the data type identifier corresponding to the version information, the data file is parsed to obtain the first version data, and the first version data is converted into the second version data corresponding to the base version information; If not, then the data file is determined to be abnormal.

6. The method according to claim 1, characterized in that, The flash memory device includes a primary partition and a backup partition, which are respectively mapped to corresponding file systems. The step of establishing a first mount connection with at least one target file system corresponding to the data to be updated, based on a dynamic allocation method, includes: The target file system of the primary partition of the flash memory device corresponding to the data to be updated attempts to establish a first mount connection; If the connection to the primary partition fails, an attempt is made to establish a first mount connection with the target file system of the backup partition of the flash memory device. If the connection to the backup partition fails, format the flash memory device and repeat the above steps until the connection to the primary partition or the backup partition is successful, or the preset number of attempts is reached.

7. The method according to claim 6, characterized in that, After establishing a first mount connection with at least one target file system corresponding to the flash data to be updated based on the dynamic allocation method, the method further includes: Determine whether an index file exists in the target file system; If no index file exists, create an index file for the target file system. Perform serialization of the index file, and write the serialized index file to the primary and backup partitions of the flash memory device corresponding to the flash memory data to be updated.

8. The method according to claim 1, characterized in that, The step of establishing a corresponding first mount connection with at least one target file system corresponding to the data to be updated based on the dynamic allocation method, reading the contents of the index file and data file corresponding to the data to be updated into the cache, and releasing the corresponding first mount connection includes: Retrieve multiple flash memory devices corresponding to the data to be updated; The system sequentially requests multiple handles corresponding to the multiple flash memory devices from the handle pool, and establishes a first mount connection with the target file system corresponding to the flash memory device based on the handles; and After releasing the first mount connection, the handle is released back into the handle pool; The step of establishing a corresponding second mount connection with the at least one target file system based on dynamic allocation, writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system, and releasing the corresponding second mount connection includes: Sequentially request multiple handles corresponding to the multiple flash devices from the handle pool, and establish a second mount connection with the target file system corresponding to the flash device based on the handles; and After releasing the second mount connection, the handle is released back into the handle pool.

9. The method according to claim 1, characterized in that, The step of updating the content of the data file read into the cache to obtain updated data includes: Each update involves one or more data records in the data file, and the updated data records constitute an updated data file. The content of the data file is obtained by reading one or more data files in the target file system at once, and one or more of the updated data files are written to the corresponding target file system at once.

10. The method according to claim 1, characterized in that, The step of writing the updated data to the corresponding target file system, updating the index file and writing it to the target file system includes: Based on the index file, the updated data is serialized and written sequentially to the corresponding data file in the target file system; Based on the updated data, the data type identifier, version information, and verification information of the index file are updated; Write the updated index file to the target file system.

11. The method according to claim 1, characterized in that, The step of mapping the plurality of flash memory devices to corresponding plurality of file systems includes: Construct the flash object corresponding to the file system; The operation function of the flash memory device is passed as a parameter to the corresponding flash memory object. The operation function is used to perform any one of the initialization, read, or write operations on the flash memory device.

12. The method according to claim 1, characterized in that, The method further includes: In the event of a flash memory device replacement, a first mount connection is established with the file system corresponding to the replaced flash memory device, and the contents of the data files and index files in the file system are read into the cache.

13. A data update apparatus for a flash memory device, characterized in that, The device is used in a host computer of a flash memory management system, the flash memory management system further includes multiple flash memory devices connected to the host computer, and the device includes: A mapping module is used to map the plurality of flash memory devices to corresponding plurality of file systems. The file system includes an index file and at least one data file. The index file includes at least one preset data type identifier. Each data file maps flash memory data in the flash memory device corresponding to the data type identifier. The reading module is used to establish a corresponding first mount connection with at least one target file system corresponding to the data to be updated based on a dynamic allocation method, read the contents of the index file and data file corresponding to the data to be updated into the cache and release the corresponding first mount connection; The update module is used to update the content of the data file read into the cache to obtain updated data; The write module is used to establish a corresponding second mount connection with the at least one target file system based on a dynamic allocation method, write the updated data to the corresponding target file system, update the index file and write it to the target file system, and release the corresponding second mount connection.

14. A flash memory management system, characterized in that, The flash memory management system includes a host computer and multiple flash memory devices connected to the host computer. The host computer performs storage management on the multiple flash memory devices using the data update method for the flash memory devices described in any one of claims 1 to 12.

Images