Method, terminal and computer program product for updating files of an ubi file system

Abstract

The present disclosure provides a method, a terminal and a computer program product for updating a file of a UBI file system. The method comprises: obtaining a total amount of storage space change corresponding to a file change operation of the UBI file system, wherein the total amount of storage space change is determined according to a compressed size of a file involved in the file change operation; obtaining a target storage space size of the UBI file system, wherein the target storage space size is determined according to a remaining amount of storage space of the UBI file system; and determining whether to perform the file change operation according to a comparison result of the total amount of storage space change and the target storage space size. The method can avoid a problem that a UBI file system partition can only find that a remaining space is insufficient to cause a device to be unable to use when a file is actually written, and can improve a success rate and reliability of a file change operation of the UBI file system.

Description

Technical Field

[0001] This disclosure relates to the field of terminal technology, and in particular to a method, terminal, and computer program product for updating files in an Unsorted Block Image (ubi) file system. Background Technology

[0002] Due to its higher storage utilization and faster mount speed, the UBI file system is widely used in embedded products such as CPEs and UFIs. However, the remaining available space of the current partition (sector) seen at the UBI file system level differs from the actual amount of data that can be written, which may result in only a portion of the files being written, rendering the device unusable. Summary of the Invention

[0003] This disclosure provides a method, terminal, and computer program product for updating files in the Ubi file system.

[0004] In a first aspect, embodiments of this disclosure provide a method for updating files in a Ubi file system, including:

[0005] Get the total storage space change corresponding to file change operations in the UBI file system. The total storage space change is determined based on the compressed size of the files involved in the file change operation.

[0006] Get the target storage space size of the UBI file system. The target storage space size is determined based on the remaining storage space of the UBI file system.

[0007] Based on the comparison between the total change in storage space and the target storage space size, determine whether to perform file modification operations.

[0008] In a second aspect, embodiments of this disclosure provide a mobile terminal, including a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the method for updating files using the UBI file system as described in any implementation of the first aspect.

[0009] Thirdly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method for updating files in the UBI file system as described in any implementation of the first aspect.

[0010] The method, terminal, and computer program product for updating files in the UBI file system based on the embodiments of this disclosure can accurately assess the total amount of storage space change corresponding to the file change operation before performing the file change operation, based on the compressed size of the files involved in the file change operation. Based on the comparison result between the total amount of storage space change and the target storage space size, it is determined whether to perform the file change operation. This avoids the problem of insufficient remaining space in the UBI file system partition only being discovered when actually writing files, which would render the device unusable, in scenarios such as FOTA or when a large number of files need to be saved. This can improve the success rate and reliability of file change operations in the UBI file system. Attached Figure Description

[0011] In the accompanying drawings of the embodiments disclosed herein:

[0012] Figure 1 A flowchart illustrating a method for updating files in a Ubi file system, provided as an embodiment of this disclosure;

[0013] Figure 2 A flowchart of some steps in a method for updating files in a Ubi file system provided in this disclosure embodiment;

[0014] Figure 3 A flowchart of some steps in another method for updating files in the Ubi file system provided in this disclosure embodiment;

[0015] Figure 4 A flowchart of some steps in another method for updating files in the Ubi file system provided in this disclosure embodiment;

[0016] Figure 5 A flowchart of some steps in another method for updating files in the Ubi file system provided in this disclosure embodiment;

[0017] Figure 6 A flowchart of some steps in another method for updating files in the Ubi file system provided in this disclosure embodiment;

[0018] Figure 7 A block diagram of a terminal provided in an embodiment of this disclosure;

[0019] Figure 8 A flowchart illustrating another method for updating files in the UBI file system provided in this embodiment of the disclosure. Detailed Implementation

[0020] To enable those skilled in the art to better understand the technical solutions of this disclosure, the method, terminal, and computer program product for updating files in the UBI file system provided in the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0021] The present disclosure will be described more fully below with reference to the accompanying drawings; however, the embodiments shown may be embodied in different forms, and the present disclosure should not be construed as limited to the embodiments set forth below. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will enable those skilled in the art to fully understand the scope of the disclosure.

[0022] The accompanying drawings are provided to further illustrate this disclosure and form part of the specification. They are used together with the detailed embodiments to explain this disclosure and do not constitute a limitation thereof. These and other features and advantages will become more apparent to those skilled in the art from the description of detailed embodiments with reference to the accompanying drawings.

[0023] Unless otherwise specified, each embodiment and feature of this disclosure may be used individually or in combination with other embodiments and features thereof.

[0024] Those skilled in the art will understand that various changes in form and detail may be made to the embodiments of this disclosure without departing from the scope of this disclosure as set forth by the appended claims.

[0025] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the disclosure. The term "and / or" as used in this disclosure includes any and all combinations of one or more of the associated enumerated entries. The singular forms "a" and "the" as used in this disclosure are also intended to include the plural forms, unless the context clearly indicates otherwise. The terms "comprising," "made of," etc., as used in this disclosure specify the presence of the stated feature, integral, step, operation, element, and / or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof.

[0026] Unless otherwise specified, all terms used in this disclosure (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and this disclosure, and will not be interpreted as having an idealized or overly formal meaning, unless expressly so defined in this disclosure.

[0027] This disclosure is not limited to the embodiments shown in the accompanying drawings, but includes modifications to the configuration based on the manufacturing process. Therefore, the areas illustrated in the drawings are schematic, and the shapes of the areas shown illustrate specific shapes of the areas of an element, but are not intended to be limiting.

[0028] Embedded products such as Customer Premise Equipment (CPE) and USB Function Interface (UFI) widely use the UBI file system (Unsorted Block Image File System, UBIFS). However, there is a discrepancy between the remaining available space displayed at the operating system level and the actual amount of data that can be written. This is because the UBI file system compresses data when writing to Flash, causing the actual amount of data that can be written to to depend on the compression ratio. When writing multiple files at once, some files may fail to be written, compromising file integrity. This is particularly fatal in critical scenarios such as Firmware Over-The-Air (FOTA) updates, potentially rendering the device unusable.

[0029] Currently, to prevent insufficient space, the method of directly judging whether there is enough remaining space is usually adopted to determine whether to perform file modification operations. However, due to the existence of compression mechanisms, there is a large discrepancy between the actual amount of writable data and the displayed remaining space. The problem of inaccurate space judgment still exists, resulting in a low success rate and reliability of file writing.

[0030] The method for updating files using the UBI file system provided in this disclosure can be applied to various terminal devices using the UBI file system. This method is particularly suitable for scenarios with extremely high requirements for file write reliability, such as FOTA (Firmware Over-The-Air), or for batch file saving or updating on devices with limited storage space.

[0031] The core idea of ​​this disclosure is that, before performing file modification operations (adding, updating, and / or deleting files), instead of directly relying on the uncompressed remaining space displayed by the operating system, it accurately assesses the net change in storage space caused by all involved files (i.e., the "total change in storage space") based on the actual compression mechanism of the UBI file system. By comparing this total change with the target storage space size, such as a preset percentage of the remaining storage space (e.g., 98%), it can pre-determine whether the operation will fail due to insufficient space, thereby deciding whether to execute the entire operation and avoiding device malfunction or unusability caused by write failures midway.

[0032] Firstly, reference Figure 1 This disclosure provides a method for updating files in a Ubi file system, including:

[0033] S101, obtain the total storage space change corresponding to the file change operation of the UBI file system, wherein the total storage space change is determined based on the compressed size of the files involved in the file change operation.

[0034] In some embodiments, when a terminal needs to perform a file modification operation (e.g., a FOTA upgrade operation involving adding several new files, updating several existing files, and deleting several useless files), the system first calculates the overall change in storage space of the UBI file system partition that the operation will cause, i.e., the total change in storage space. The key feature of this total change is that it is not based on the original size of the files involved, but rather on the "compressed size" of these files under the UBI file system storage mechanism.

[0035] S102, obtain the target storage space size of the UBI file system. The target storage space size is determined based on the remaining storage space of the UBI file system.

[0036] In some embodiments, the target storage space size refers to the physical space available for new data to be written under the Ubi file system that is not occupied by any files or metadata.

[0037] In some embodiments, the remaining storage space of the UBI file system partition can be queried through a standard file system interface. The target storage space size is then determined by the remaining storage space after reserving a certain margin. The reserved margin can be expressed as a percentage. For example, if the reservation percentage is 2%, the preset percentage corresponding to the target storage space size is 98%, i.e., target storage space size = remaining storage space * 98%.

[0038] S103. Based on the comparison between the total change in storage space and the target storage space size, determine whether to perform the file change operation.

[0039] In some embodiments, after obtaining the total amount of storage space change and the target storage space size, the operating system compares the two and determines whether to perform the file change operation based on the comparison result, thereby avoiding the problem of the device becoming unusable due to insufficient storage space causing the operation to fail.

[0040] The method, terminal, and computer program product for updating files in the UBI file system based on the embodiments of this disclosure can accurately assess the total amount of storage space change corresponding to the file change operation before performing the file change operation, based on the compressed size of the files involved in the file change operation. Based on the comparison result between the total amount of storage space change and the target storage space size, it is determined whether to perform the file change operation. This avoids the problem of insufficient remaining space in the UBI file system partition only being discovered when actually writing files, which would render the device unusable, in scenarios such as FOTA or when a large number of files need to be saved. This can improve the success rate and reliability of file change operations in the UBI file system.

[0041] After obtaining the total change in storage space and the target storage space size, the operating system compares the two. In some embodiments, refer to Figure 2 , Figure 1 In step S103, based on the comparison between the total change in storage space and the target storage space size, it is determined whether to perform a file modification operation, including one of the following:

[0042] S201, When the total change in storage space is less than or equal to the target storage space size, perform a file change operation.

[0043] In some embodiments, the target storage space size is determined based on the amount of remaining storage space. For example, the threshold can be set to 98% or 95% of the remaining storage space. This means that when the net space required for the operation is no greater than a certain percentage (such as 98%) of the remaining space, the operating system considers that there is enough margin (taking into account the overhead that may be occupied by the UBI file system's own garbage collection mechanism) to safely complete all file changes involved in the file change operation, and therefore the entire operation can be executed.

[0044] S202: When the total change in storage space exceeds the target storage space size, file change operation will not be performed.

[0045] In some embodiments, if the required net space exceeds a safety threshold (e.g., more than 98% of the remaining space), the operating system will determine that there is a risk of write failure and decide not to perform any file changes in the file change operation. This can effectively avoid system stability problems caused by insufficient space leading to some file changes succeeding and others failing.

[0046] Optionally, the operating system may return an "insufficient space" error message to the user or upper-layer applications to alert the user to potential operational risks.

[0047] Below, in conjunction with Figures 3 to 6 For different types of file change operations, the specific calculation method of "total change in storage space" in step S101 is explained in detail.

[0048] In some embodiments, the file change operation is an add file operation; that is, when the operation to be performed only involves adding one or more new files, refer to... Figure 3 , Figure 1 In step S101, the total storage space change corresponding to file change operations in the Ubi file system is obtained, including:

[0049] S301 uses the write compression algorithm used by the Ubi file system to compress the files to be added in the file addition operation.

[0050] In some implementations, the Ubi file system needs to determine the compression algorithm (referred to as the "write compression algorithm") used when writing data to storage. This algorithm can be the default algorithm configured in the Ubi file system kernel (such as LZO, Zlib, etc.) or an algorithm specified when mounting the partition. After determining the write compression algorithm, all files to be added are compressed sequentially.

[0051] S302, determine the storage space usage based on the compressed size of the file to be added.

[0052] In some embodiments, after compression is completed, the size of each file to be added after compression is recorded and summed. This sum is the additional storage space that will be occupied when performing all file addition operations, i.e., "storage space usage".

[0053] S303, determine the total change in storage space based on the amount of storage space occupied.

[0054] It should be noted that since adding files only occupies space and does not release it, the final "total change in storage space" is equal to the "storage space usage" calculated in step S202 (which is a positive value). For example, if a file addition operation involves three files to be added, with compressed sizes of 10KB, 20KB, and 30KB respectively, then the total change in storage space for this operation is +60KB, where "+" indicates that the total change in storage space is a net increase.

[0055] Based on this scheme, by simulating the write compression process of the UBI file system, the actual space occupied after adding a file can be accurately predicted. This allows the operating system to accurately determine whether the remaining space is sufficient to accommodate the compressed file before performing the add operation, avoiding misjudgments caused by the discrepancy between the remaining space displayed by the operating system (without considering compression) and the actual writable space (with considering compression). This effectively prevents the problem of write failure due to insufficient space when adding large files, thereby improving the success rate and reliability of file operations.

[0056] In some embodiments, the file change operation is an update file operation. That is, when the file change operation to be performed only involves updating or upgrading one or more existing files (one file to be updated replaces one file to be replaced), this can be used. Figure 4 The method shown evaluates the total amount of storage space change. The file to be updated is used to replace the file to be replaced; therefore, the file to be updated can also be called the new file or new version file involved in the file change operation, and the file to be replaced can also be called the old file or old version file involved in the file change operation.

[0057] refer to Figure 4 , Figure 1In step S101, the total storage space change corresponding to file change operations in the Ubi file system is obtained, including:

[0058] S401 uses the write compression algorithm used by the Ubi file system to compress the files to be updated involved in the update file operation.

[0059] In some embodiments, similar to the file addition operation, all files to be updated (new version files) involved in the operation are first compressed using the current "write compression algorithm".

[0060] S402, determine the storage space usage based on the compressed size of the file to be updated.

[0061] In some embodiments, the sum of the compressed sizes of all files to be updated is calculated as the storage space that will be occupied by this file update operation (i.e., the space required to write all new files).

[0062] S403 uses the storage compression algorithm that is actually used when the file to be replaced is stored in the UBI file system during the update file operation to compress the file to be replaced.

[0063] It's important to note that, as a crucial step in this method, the compression algorithm used when a file to be replaced is stored in the Ubi file system may differ from the current "write compression algorithm." For example, a file to be replaced might have been compressed using the "raw compression algorithm" when the system image was initially created and then flashed in, and has never been modified. Therefore, to accurately assess how much space can be freed up after deleting all the files to be replaced involved in the update file operation, it is necessary to compress them using the compression algorithm actually used when they were stored, i.e., the storage compression algorithm. The operating system can obtain the actual compression algorithm used by resolving the physical storage nodes (such as data nodes) of these files and compress these old files based on the compression algorithm used when these files were stored.

[0064] S404, determine the amount of storage space to be released based on the compressed size of the file to be replaced.

[0065] In some embodiments, the storage compression algorithm determined in step S303 can be used to compress each file to be replaced, and the sum of the compressed sizes of all files to be replaced can be calculated. This sum is the amount of storage space that can be released after deleting all files to be replaced, i.e., the "storage space release amount" (which is a positive value).

[0066] S405, determine the total change in storage space based on the amount of storage space occupied and the amount of storage space released.

[0067] The file update operation involves "first releasing the storage space occupied by all files to be replaced, and then writing all files to be updated back into the storage space," therefore the net change is determined by both. Specifically, the total change in storage space = (the sum of the compressed sizes of all files to be updated) - (the sum of the compressed sizes of all files to be replaced). The result may be positive (the total number of files to be updated is larger, resulting in a net increase in space occupied) or negative (the total number of files to be updated is smaller, resulting in a net increase in space released).

[0068] In some embodiments, it is assumed that a single file update operation involves only one file. If the compressed size of the file to be replaced is 40KB and the compressed size of the file to be updated is 60KB, then the total change in storage space = 60KB - 40KB = +20KB. This result is positive, indicating that performing this file update operation will net occupy 20KB of storage space.

[0069] In other embodiments, it is assumed that a single file update operation involves only one file. If the compressed size of the file to be replaced is 100KB and the compressed size of the file to be updated is 70KB, then the total change in storage space = 70KB - 100KB = -30KB. This result is negative, indicating that performing this file update operation will net free up 30KB of storage space. Here, "-" indicates that the total change in storage space is a net freed value.

[0070] For file update operations, this disclosure introduces the identification and use of the "actual storage compression algorithm" of the file to be replaced. Since the compression algorithms for files in the UBI file system may differ due to different sources (such as image pre-installation versus subsequent writing), using the "write compression algorithm" to estimate the space released by the file to be replaced will result in significant errors. This method, by accurately identifying and using the compression algorithm actually used when the file to be replaced is stored, can accurately calculate the space that can be released after deleting the file to be replaced. Combined with the space occupied by the compressed file to be updated, it can accurately determine the net storage space change brought about by the file update operation. This effectively avoids estimation errors in the total storage space change caused by differences in compression algorithms, ensuring accurate space judgment before the file update operation is executed, and significantly improving the success rate and reliability of the file update operation.

[0071] In some embodiments, the file modification operation is a file deletion operation. When the file modification operation to be performed is only to delete one or more files to be deleted, refer to... Figure 5 , Figure 1 In step S101, the total storage space change corresponding to file change operations in the Ubi file system is obtained, including:

[0072] S501 uses the storage compression algorithm that is actually used when the file to be deleted is stored in the UBI file system to compress the file to be deleted.

[0073] In some embodiments, the same principle applies as when evaluating the amount of storage space freed by a file to be deleted in an update operation: the file to be deleted is compressed using the compression algorithm that was actually used when the file to be deleted was stored in the file deletion operation.

[0074] S502, determine the amount of storage space to be released based on the compressed size of the file to be deleted.

[0075] In some embodiments, the sum of the compressed sizes of all files to be deleted is calculated, and this sum is the "storage space released".

[0076] S503 determines the total change in storage space based on the amount of storage space released.

[0077] It should be noted that since deleting files only releases space and does not occupy space, the final "total change in storage space" is the opposite of the "storage space released" calculated in step S502 (which is a negative value). For example, if a file deletion operation involves three files and the total released amount is 50KB, then the total change in storage space for this operation is -50KB.

[0078] For file deletion operations, similar to update operations, the compression algorithm used when the file is actually stored is used to assess the space occupied by the file to be deleted. This ensures that the operating system can accurately understand how much physical space can be freed up after deleting these files, thus providing an accurate "space increment" assessment basis for subsequent add or update operations. This is especially important for batch file replacement or cleanup operations on devices with limited storage space.

[0079] In some embodiments, file modification operations include updating files, adding files, and deleting files. In practical applications, a single file modification operation may involve multiple operation types simultaneously. For example, a system upgrade operation may simultaneously involve adding several new files (files to be added), updating several existing files (files to be updated and files to be replaced), and deleting several useless files (files to be deleted). This embodiment provides a method for comprehensively handling this situation.

[0080] refer to Figure 6 When the file change operation simultaneously includes an update file action (involving one or more files to be updated and their corresponding replacement files), an add file action (involving one or more files to be added), and a delete file action (involving one or more files to be deleted), Figure 1In step S101, the total storage space change corresponding to file change operations in the Ubi file system is obtained, including:

[0081] S601 uses the write compression algorithm used by the Ubi file system to compress the files to be added in the add file operation and the files to be updated in the update file operation in sequence.

[0082] S602, determine the storage space usage based on the compressed size of the file to be added and the compressed size of the file to be updated.

[0083] In some embodiments, all files to be added and all files to be updated (new version files) involved in the file change operation can be compressed using a write compression algorithm, and the compressed sizes of each file can be summed to determine the storage space usage.

[0084] S603 uses the storage compression algorithm that is actually used when the file to be replaced is stored in the UBI file system during the update file operation to compress the file to be replaced.

[0085] S604, the file to be deleted is compressed using the storage compression algorithm used when the file to be deleted is actually stored in the UBI file system;

[0086] S605 determines the amount of storage space to be released based on the compressed size of the file to be replaced and the compressed size of the file to be deleted.

[0087] In some embodiments, all old files to be replaced and all files to be deleted involved in the file change operation can be compressed using their respective storage compression algorithms, and the compressed sizes of each file can be summed to determine the amount of storage space released.

[0088] S606, determine the total change in storage space based on the amount of storage space occupied and the amount of storage space released.

[0089] In some embodiments, the total storage space change for the file change operation = (the sum of the compressed sizes of all files to be added and updated) - (the sum of the compressed sizes of all files to be replaced and deleted).

[0090] In some embodiments, the priority of updating file operations is higher than the priority of adding file operations, but lower than the priority of deleting file operations.

[0091] Example 1 (Positive Calculation): Suppose an FOTA upgrade operation requires: adding a new file A (50KB compressed), updating file B (new version 80KB compressed, old version 60KB compressed), and deleting file C (30KB compressed). Then, the total storage space change for this operation = (50KB + 80KB) - (60KB + 30KB) = 40KB. The calculation result is positive, indicating that this upgrade operation is expected to net occupy 40KB of storage space. The operating system will then compare this net occupation (40KB) with a preset ratio of remaining storage space, such as 98%, to decide whether to perform the upgrade.

[0092] Example 2 (Negative Calculation Result): Suppose another cleanup and optimization operation requires: adding a new file A (20KB after compression), updating file B (new version 30KB after compression, old version 80KB after compression), and deleting file C (50KB after compression). Then, the total storage space change for this operation = (20KB + 30KB) - (80KB + 50KB) = 50KB - 130KB = -80KB. The negative result indicates that this cleanup operation is expected to net release 80KB of storage space. Since the net space release will not put additional pressure on the remaining space, the operating system can directly determine that the execution conditions are met.

[0093] For complex file change operations involving multiple operation types, this solution categorizes files to be added and updated into the "space occupation" category, and files to be replaced and deleted into the "space release" category. This allows for a comprehensive and accurate calculation of the net impact of the entire operation on storage space. As a result, the operating system can use a comprehensive net space change as a basis for decision-making before performing complex batch operations (such as FOTA upgrades). This avoids the logical confusion and error accumulation that may occur when judging various actions separately, greatly improving the success rate and reliability of file change operations in complex scenarios.

[0094] In some embodiments, to minimize failures due to insufficient instantaneous space during execution and further improve the success rate and reliability of file change operations in complex scenarios, the execution order within file change operations is optimized in this disclosure. Specifically, in one embodiment, for file change operations that simultaneously include multiple operation types, the priority of update file operations is higher than the priority of add file operations, but lower than the priority of delete file operations. This means that when a file change operation is determined to be executable, the operating system will actually execute it in the order of "first executing all delete file operations, then executing all update file operations, and finally executing all add file operations".

[0095] Furthermore, in each file update operation, deleting the file to be replaced has a higher priority than adding the file to be updated. Specifically, during a file update operation, deleting the file to be replaced (the old file) also has a higher priority than adding the file to be updated (the new file). That is, when performing each update action, the old file is deleted and its space is released first, and then the new file is written.

[0096] Example 1 (Net Space Usage, Space Sufficient Check Required): After determining that the net space usage (40KB) of the FOTA upgrade operation in Example 1 is less than 98% of the remaining space (assuming 100KB), the operating system executes the executable file modification operations in the following order:

[0097] (1) Perform all file deletion actions: delete file C and reclaim the 30KB physical space it actually occupies.

[0098] (2) Perform all file update actions:

[0099] To update file B, first delete the file B to be replaced, freeing up 60KB of space it actually occupies; then add the new version of file B, which occupies 80KB of space. This step takes up a net 20KB.

[0100] (3) Perform all file addition actions: Add a new file A, which occupies 50KB of space.

[0101] Example 2 (Net space release, no judgment required or conditions met automatically): For the cleanup and optimization operation in Example 2, since it releases a net 80KB of space, it will not put additional pressure on the storage space. The operating system can directly determine that the execution conditions are met and execute them in priority order as follows (assuming the remaining space is 50KB):

[0102] (1) Perform all file deletion operations: Delete file C, freeing up the 50KB of space it actually occupied. At this time, the remaining space changes from 50KB to 100KB.

[0103] (2) Perform all file update operations: For the update of file B, first delete the old file B, release the 80KB space it actually occupies, and the remaining space changes from 100KB to 180KB; then add the new version of file B, which occupies 30KB space, and the remaining space changes from 180KB to 150KB.

[0104] (3) Perform all file addition operations: Add a new file A, which occupies 20KB of space, and the remaining space changes from 150KB to 130KB.

[0105] All operations were successfully completed. This demonstrates that even though the remaining space (50KB) before the operation seemed insufficient to accommodate the combined total of new file A (20KB) and new version file B (30KB) (50KB), the "delete first, update second, add last" priority order allowed the deletion operation to release a significant amount of space (50KB + 80KB = 130KB), thus providing ample space for subsequent update and add operations. However, it should be noted that the method disclosed in this paper still performs a net space assessment before execution: in Example 2, the net change is -80KB (i.e., a net release of 80KB), and the operating system directly determines that execution is possible; if the net change is positive but judged by a threshold (e.g., less than 98% of the remaining space), the operating system will still execute, and the aforementioned priority order ensures space safety during execution.

[0106] Based on this scheme, by enforcing the execution order of "delete first, then update, and finally add," and the order of "delete old first, then write new" within the update operation, it is ensured that the space requirement at any time during the entire file modification process is "release first, then occupy." This avoids the awkward situation where a large space-consuming operation (such as adding a large file) leads to a momentary space shortage, preventing subsequent deletion operations from being executed (because deletion should release space). This priority design maximizes the use of freeable space to meet subsequent space requirements, significantly reducing the momentary space pressure during complex file modification operations, and further improving the success rate and reliability of operations, especially in embedded devices with limited storage space.

[0107] Secondly, refer to Figure 7 This disclosure provides a terminal, including a memory 702 and a processor 701; the memory 702 stores a computer program that can be executed by the processor 701, and when the computer program is executed by the processor 701, it implements the method for updating files in the UBI file system as described in any implementation of the first aspect.

[0108] Thirdly, embodiments of this disclosure provide a computer program product, including a computer program that, when executed by a processor, implements the method for updating files in the UBI file system as described in any implementation of the first aspect.

[0109] Fourthly, refer to Figure 8 This disclosure provides a method for updating files in the Ubi file system.

[0110] The core of this method is to accurately assess the total amount of storage space change involved in the operation based on the actual compression mechanism of the UBI file system before performing the file change operation, and then compare it with the preset proportion of the remaining space of the current partition (such as 98%) to decide whether to perform the operation, thereby avoiding failure due to insufficient space during the writing process.

[0111] Specifically, this disclosure relates to two compression algorithms:

[0112] Write compression algorithm: This refers to the default compression algorithm (such as zlib, lzo, zstd, etc.) used when mounting the current Ubi file system partition. If not explicitly specified, the compression algorithm configured in the kernel will be used. This algorithm is used for compression when writing new files.

[0113] Storage compression algorithm (i.e., raw compression algorithm): This refers to the compression algorithm used when creating a file system partition image file. When a file has never been modified since it was written to the device (i.e., it remains in the state it was in when the image was generated), the compression algorithm used when it is actually stored in the UBI file system is the storage compression algorithm. When deleting or updating such files, this algorithm must be used to calculate its compressed size. This algorithm can be obtained by analyzing the data nodes in the UBI block.

[0114] The calculation method for the total storage space change is as follows for different types of file modification operations:

[0115] (1) Add file operation

[0116] The write compression algorithm is used to compress the files to be added one by one, and the size of each file after compression is recorded. The total storage space occupied is obtained by summing the data. This value is the total change in storage space (positive value).

[0117] (2) File deletion operation

[0118] Determine whether the files to be deleted retain the state they were in when the image was generated: if yes, compress them using a storage compression algorithm; otherwise, compress them using a write compression algorithm. Record the compressed size of each file to be deleted, sum them up to obtain the amount of storage space released, and the negative of this sum is the total amount of storage space changed.

[0119] (3) Update file operations

[0120] First, determine whether the file to be replaced retains the state it was in when the image was generated. If so, use a storage compression algorithm; otherwise, use a write compression algorithm to compress it, thus obtaining the amount of storage space released. Then, use the write compression algorithm to compress the file to be updated, thus obtaining the amount of storage space occupied. Finally, subtract the amount of storage space released from the amount of storage space occupied to obtain the total change in storage space (which may be positive or negative). A positive result indicates that the total change in storage space is a net increase, while a negative result indicates that the total change in storage space is a net release.

[0121] (4) Mixed operations (including adding, updating, and deleting simultaneously)

[0122] The total storage space occupied is calculated by summing the compressed files to be added and updated using the write compression algorithm; the total storage space released is calculated by summing the compressed files to be replaced and deleted using the compression algorithm used for their actual storage; the difference between the two is the total storage space change (which may be positive or negative).

[0123] After calculating the total change in storage space, it is compared with the target storage space size. If the total change in storage space is less than or equal to the target storage space size, the write condition is considered met, and the operation can be executed; otherwise, a write risk is considered, and the operation is not executed. The target storage space size can be determined by multiplying the remaining storage space in the UBI file system by a preset percentage, such as 98% or 97%.

[0124] It should be noted that the preset ratio is less than 100% because the Ubi file system's own garbage collection and other mechanisms will occupy some space, which cannot be released immediately during the writing process. If the ratio is set to 100%, it may cause the write to fail. Therefore, a certain margin needs to be reserved.

[0125] Once the write conditions are met, file modification operations are executed in the following preset order: first, all file deletion operations are performed; then, all file update operations are performed; and finally, all file addition operations are performed. Within each file update operation, the order of deleting the file to be replaced and then adding the file to be updated is also followed. This order ensures that space is released preferentially during the operation, minimizing instantaneous storage space pressure and further improving the success rate of the operation.

[0126] The above process will be illustrated with a specific example below.

[0127] Suppose you need to perform the following operations on the system partition of the Ubi file system: add a new file A, update an existing file B (the new version is larger than the old version), update an existing file C (the new version is smaller than the old version), and delete an existing file D. Here, A is the file to be added, and D is the file to be deleted. In the file update operation, since the new version file is used to replace the old version file, the new version file is also called the file to be updated, and the old version file is also called the file to be replaced. For example, the new version file of file B can be called the file to be updated B, and the old version file of file C can be called the file to be replaced C.

[0128] Step 1: Determine the write compression algorithm (such as zlib, lzo, zstd, etc.) by judging the compression parameters of the Ubi file system partition.

[0129] Step 2: Compress the file A to be added using a write compression algorithm to obtain a compressed file A1, save it to memory, record its size VA, and then delete A1 from memory.

[0130] Step 3: Process the update of file B. By analyzing the compression algorithm of the data nodes in the LEB block of the file B to be replaced in the Ubi file system, it is determined whether it is the same as the write compression algorithm, thus determining the compression algorithm used when the file B to be replaced is actually stored (storage compression algorithm or write compression algorithm). The file B to be replaced is compressed using this compression algorithm to obtain B1, its size is recorded, and then B1 is deleted. The file B to be updated is compressed using the write compression algorithm to obtain B2, its size is recorded, and then B2 is deleted. Calculate VB = size(B2) - size(B1). Since the file B to be updated is larger than the file B to be replaced, i.e., the new version of file B is larger than the old version, VB is positive.

[0131] Step 4: Process the update of file C. Using the same method as in Step 3, analyze the actual storage compression algorithm of the file C to be replaced. Compress the file C to be replaced into C1, and compress the file C to be updated into C2. Calculate VC = size(C2) - size(C1). Wherein, since the file C to be updated is larger than the file C to be replaced, that is, the new version of file C is larger than the old version, VC is negative.

[0132] Step 5: Process the deletion of file D. By analyzing the data nodes of the file to be deleted D, determine the compression algorithm used in its actual storage, compress the file D to obtain D1, record its size VD, and then delete D1.

[0133] Step 6: Calculate the total storage space change VF for this file change operation, where VF = VA + VB + VC - VD. VA, VB, and VC represent the storage space occupied, and VD represents the storage space released.

[0134] Step 7: Determine if the write condition is met. The write condition is: VF is less than or equal to the target storage space size. If yes, the write condition is met; otherwise, the write condition is not met and the process will not proceed. Assume the target storage space size equals 98% of the remaining storage space in the current partition.

[0135] Step 8: If the write conditions are met, execute the process in a fixed order of "delete first, then update, and finally add": First, delete file D, then update files C and B in sequence, and finally add file A. During the update process of files C and B, delete the file to be replaced first, and then add the file to be updated.

[0136] In this embodiment of the disclosure, the processor is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory is a device with data storage capabilities, including but not limited to random access memory (RAM), more specifically such as SDRAM, DDR, etc., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory (FLASH); the I / O interface, or read-write interface, is connected between the processor and the memory, enabling information exchange between the memory and the processor, including but not limited to a data bus (Bus).

[0137] Those skilled in the art will understand that all or some of the steps, systems, and devices disclosed above, as functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0138] In hardware implementations, the division between functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be executed by several physical components working together.

[0139] Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit (CPU), digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media and communication media. In embodiments of this disclosure, computer storage media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, and any other media that can be used to store desired information and can be accessed by a computer. In embodiments of this disclosure, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0140] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for updating files in a Ubi file system, characterized in that, include: Obtain the total storage space change corresponding to file change operations in the UBI file system, wherein the total storage space change is determined based on the compressed size of the files involved in the file change operations; Obtain the target storage space size of the Ubi file system, wherein the target storage space size is determined based on the remaining storage space of the Ubi file system; Based on the comparison between the total change in storage space and the target storage space size, it is determined whether to perform the file change operation.

2. The method according to claim 1, characterized in that, The file modification operation is a file addition operation; The process of obtaining the total storage space change corresponding to file change operations in the Ubi file system includes: The file to be added is compressed using the write compression algorithm used by the Ubi file system. The storage space usage is determined based on the compressed size of the file to be added. The total change in storage space is determined based on the storage space occupancy.

3. The method according to claim 1, characterized in that, The file change operation is a file update operation; The process of obtaining the total storage space change corresponding to file change operations in the Ubi file system includes: The file to be updated involved in the update operation is compressed using the write compression algorithm used by the Ubi file system. The storage space usage is determined based on the compressed size of the file to be updated. The file to be replaced is compressed using the storage compression algorithm used when the file to be replaced is actually stored in the Ubi file system during the update file operation. The amount of storage space to be released is determined based on the compressed size of the file to be replaced. The total change in storage space is determined based on the storage space usage and the storage space release. The file to be updated is used to replace the file to be replaced.

4. The method according to claim 1, characterized in that, The file modification operation is a file deletion operation; The process of obtaining the total storage space change corresponding to file change operations in the Ubi file system includes: The file to be deleted is compressed using the storage compression algorithm used when the file to be deleted is actually stored in the Ubi file system. The amount of storage space to be released is determined based on the compressed size of the file to be deleted. The total change in storage space is determined based on the amount of storage space released.

5. The method according to claim 1, characterized in that, The file modification operations include updating files, adding files, and deleting files; The process of obtaining the total storage space change corresponding to file change operations in the Ubi file system includes: The write compression algorithm used by the Ubi file system is used to compress the files to be added in the file addition operation and the files to be updated in the file update operation in sequence. The storage space usage is determined based on the compressed size of the file to be added and the compressed size of the file to be updated; The file to be replaced is compressed using the storage compression algorithm used when the file to be replaced is actually stored in the Ubi file system during the update file operation. The file to be deleted is compressed using the storage compression algorithm used when the file to be deleted is actually stored in the Ubi file system. The amount of storage space to be released is determined based on the compressed size of the file to be replaced and the compressed size of the file to be deleted; The total change in storage space is determined based on the storage space usage and the storage space release.

6. The method according to any one of claims 1-5, characterized in that, The priority of the file update operation is higher than the priority of the file add operation, but lower than the priority of the file delete operation.

7. The method according to claim 3 or 5, characterized in that, In the file update operation, deleting the file to be replaced has a higher priority than adding the file to be updated.

8. The method according to any one of claims 1 to 5, characterized in that, The step of determining whether to perform the file change operation based on the comparison result of the total change in storage space and the target storage space size includes one of the following: When the total change in storage space is less than or equal to the target storage space size, the file modification operation is performed; or... If the total change in storage space exceeds the target storage space size, the file change operation will not be performed.

9. A terminal, characterized in that, It includes a memory and a processor; the memory stores a computer program that can be executed by the processor, and when the computer program is executed by the processor, it implements the method for updating files in the UBI file system as described in any one of claims 1 to 8.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method for updating files in the UBI file system as described in any one of claims 1 to 8.

Images