Data inline compression method for terminal device, terminal device and storage medium

Abstract

The embodiment of the present application discloses a data inline compression method for terminal devices, a terminal device, and a storage medium, which are used to compress write data and insert a compression code and a compression code index into an inline space to implement an aggressive data compression strategy and significantly reduce the amount of data written to the terminal device. The method of the embodiment of the present application includes: obtaining write data generated by a system update; when the write data is inserted into a page cache, obtaining old data from the page cache or an external memory; calculating the compression size of the XOR value of the write data and the old data; determining whether to perform compression inline according to the compression size of the XOR value and the inline space management strategy; in the case of determining to perform compression inline, compressing the XOR value to obtain a compression code and a compression code index, and inserting the compression code and the compression code index into the inline space.

Description

Technical Field

[0001] The present application relates to the field of terminal device storage, and in particular to a data inline compression method for terminal devices, terminal devices, and storage media. Background Art

[0002] The existing technical solution uses a non-volatile memory (NVM) powered by a backup capacitor as the compression code maintenance medium for incremental compression, and performs incremental compression for the update operation of the SQLite database file to reduce the amount of writing on the mobile phone. However, adding additional capacitor components to the mobile terminal has a large overhead in terms of cost, product size, heat dissipation, power consumption, etc., so it is not practical for mobile manufacturers. Summary of the invention

[0003] The embodiments of the present application provide a data inline compression method, a terminal device and a storage medium for a terminal device, which are used to compress write data and insert compression codes and compression code indexes into an inline space to implement an aggressive data compression strategy and significantly reduce the amount of data written to the terminal device.

[0004] A first aspect of the present application provides a data inline compression method for a terminal device, the method being applied to the terminal device, and the method may include:

[0005] Get the write data generated by the system update;

[0006] When the write data is inserted into the page cache, old data is obtained from the page cache or external memory;

[0007] Calculate the compressed size of the XOR value of the write data and the old data;

[0008] Determining whether to perform compression inlining according to the compression size of the XOR value and the inline space management strategy;

[0009] In the case where it is determined to perform compression inlining, the XOR value is compressed to obtain a compression code and a compression code index, and the compression code and the compression code index are inserted into the inline space.

[0010] A second aspect of the present application provides a terminal device, which may include:

[0011] The acquisition module is used to obtain the write data generated by the system update;

[0012] A processing module is used to obtain old data from the page cache or external memory when the write data is inserted into the page cache; calculate the compression size of the XOR value of the write data and the old data; determine whether to perform compression inlining according to the compression size of the XOR value and the inline space management strategy; if it is determined to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space.

[0013] A third aspect of the present application provides a terminal device, including:

[0014] A memory storing executable program code;

[0015] a processor coupled to the memory;

[0016] The processor is used to execute the method described in the first aspect of the present application.

[0017] Another aspect of an embodiment of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a processor, enables the processor to execute the method described in the first aspect of the present application.

[0018] Yet another aspect of an embodiment of the present application discloses a computer program product. When the computer program product is run on a computer, the computer is enabled to execute the method described in the first aspect of the present application.

[0019] Another aspect of an embodiment of the present application discloses an application publishing platform, which is used to publish a computer program product. When the computer program product runs on a computer, the computer executes the method described in the first aspect of the present application.

[0020] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0021] In the embodiment of the present application, the write data generated by the system update is obtained; when the write data is inserted into the page cache, the old data is obtained from the page cache or external memory; the compression size of the XOR value of the write data and the old data is calculated; according to the compression size of the XOR value and the inline space management strategy, it is determined whether to perform compression inline; if it is determined to perform compression inline, the XOR value is compressed to obtain a compression code and a compression code index, and the compression code and the compression code index are inserted into the inline space. It is used to compress the write data and insert the compression code and the compression code index into the inline space to implement an aggressive data compression strategy and significantly reduce the amount of data written to the terminal device. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments and the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can be obtained based on these drawings.

[0023] Figure 1 This is a framework diagram of the incremental compression inline system used in the embodiment of the present application;

[0024] Figure 2 A schematic diagram of an embodiment of a data inline compression method for a terminal device in an embodiment of the present application;

[0025] Figure 3A A schematic diagram comparing the inline space layout of F2FS and the inline space layout of this application;

[0026] Figure 3B This is a schematic diagram of the specific layout of the inline space of this application;

[0027] Figure 3C This is a flow chart of the page cache optimization strategy in the embodiment of the present application;

[0028] Figure 4 This is another embodiment schematic diagram of the data inline compression method for a terminal device in an embodiment of the present application;

[0029] Figure 5 This is a schematic diagram of an embodiment of a terminal device in an embodiment of the present application;

[0030] Figure 6 This is another schematic diagram of a terminal device in an embodiment of the present application. DETAILED DESCRIPTION

[0031] The embodiment of the present application provides a method of compressing write data and inserting compression codes and compression code indexes into an inline space, thereby implementing an aggressive data compression strategy and significantly reducing the amount of data written to a terminal device.

[0032] In order to make the technical personnel in the technical field better understand the scheme of the present application, the technical scheme in the embodiment of the present application will be described below in conjunction with the drawings in the embodiment of the present application. Obviously, the described embodiment is only a part of the embodiment of the present application, not all of the embodiments. Based on the embodiments in the present application, they should all fall within the scope of protection of the present application.

[0033] The following is a brief description of some terms involved in this application, as follows:

[0034] External memory: generally refers to external storage. External storage refers to storage other than computer memory and central processing unit (CPU) cache. This type of storage can generally still save data after power failure. Common external storage includes hard disks, floppy disks, CDs, USB flash drives, etc.

[0035] Hot data: For example, data within six months, which users often query, is placed in hot storage. For example, popular videos have a large number of visits and high hardware requirements, and often have high-performance servers, storage, and bandwidth support.

[0036] Warm data: For example, it can be data from half a year to a year. Users sometimes need to query data within a year online. This data is also suitable for storage in the database. If the amount of data is not large, there is no need to distinguish between warm data and hot data.

[0037] Cold data: data that is rarely used. This data can be stored in a file system with lower performance and lower price. Correspondingly, cold data is placed in cold storage. For example, unpopular videos have low traffic and low requirements for data center performance, so they are generally allocated to servers with lower performance.

[0038] Page Cache: It is understandable that files are generally stored in hard disks (mechanical hard disks or solid-state hard disks), and the CPU cannot directly access the data in the hard disk. Instead, the data in the hard disk must be read into the memory before it can be accessed by the CPU. Since the speed of reading and writing the hard disk is much slower than reading and writing the memory (DDR4 memory reads and writes 500 times faster than mechanical hard disks and 200 times faster than solid-state drives), in order to avoid reading and writing the hard disk every time a file is read or written, the Linux kernel uses a page cache mechanism to cache the data in the file. In order to improve the efficiency of reading and writing files, the Linux kernel divides the file into multiple data blocks in units of page size (4KB). When a user reads or writes a data block in a file, the kernel first applies for a memory page (called a page cache) to bind it to the data block in the file.

[0039] When users read and write files, they are actually reading and writing the page cache of the file. Therefore, when reading and writing files, there are two cases for processing:

[0040] (1) When reading data from a file, if the page cache where the data to be read is located already exists, then the data in the page cache can be directly copied to the user. Otherwise, the kernel will first apply for a free memory page (page cache), then read the data from the file into the page cache, and copy the data in the page cache to the user.

[0041] (2) When writing data to a file, if the page cache where the data to be written is located already exists, then the new data can be directly written to the page cache. Otherwise, the kernel will first request a free memory page (page cache), then read the data from the file into the page cache, and write the new data to the page cache. For modified page caches, the kernel will periodically refresh these page caches to the file.

[0042] The technical solution of the present application is further described below by way of embodiments. Figure 1 The figure shows a framework diagram of the incremental compression inline system used in the embodiment of the present application. Figure 1 As shown in the figure, when the system update write occurs①, the Virtual File System (VFS) inserts the write data into the page cache②, the file system obtains the benchmark (old data) from the page cache or external memory③, calculates the XOR value compression code size of the updated data (write data) and the original data (old data)④, and decides whether to compress inline through the inline space management strategy⑤. If yes, the XOR value is compressed⑥, and the compression code and compression code index are inserted into the inline space⑦.

[0043] like Figure 2 FIG. 1 is a schematic diagram of an embodiment of a method for inline data compression for a terminal device in an embodiment of the present application. The method embodiment is applied to a terminal device. The method embodiment may include:

[0044] 201. Obtain write data generated by system update.

[0045] The present application embodiment is combined with Figure 1 The incremental compression inline system framework diagram shown is used for explanation. The terminal device obtains the write data generated by the system update.

[0046] Optionally, the method is applied to a terminal device including a log-structured filesystem (LFS).

[0047] 202. When the write data is inserted into the page cache, old data is obtained from the page cache or external memory.

[0048] When it is detected that write data is inserted into the page cache, the terminal device obtains a reference, ie, old data, from the page cache or an external memory.

[0049] 203. Calculate a compressed size of an XOR value of the write data and the old data.

[0050] It can be understood that both the write data and the old data are expressed in binary. For example: when the first bit of the binary expression of the write data from right to left is 0, and the first bit of the binary expression of the old data from right to left is also 0, the XOR value of the write data and the old data is 0; when the second bit of the binary expression of the write data from right to left is 1, and the second bit of the binary expression of the old data from right to left is also 1, the XOR value of the write data and the old data is 0; when the third bit of the binary expression of the write data from right to left is 1, and the third bit of the binary expression of the old data from right to left is also 0, the XOR value of the write data and the old data is 1; when the fourth bit of the binary expression of the write data from right to left is 0, and the fourth bit of the binary expression of the old data from right to left is also 1, the XOR value of the write data and the old data is 1. The terminal device needs to calculate the compressed size of the XOR value of the write data and the old data.

[0051] 204. Determine whether to perform compression inlining according to the compression size of the XOR value and the inline space management strategy.

[0052] The terminal device determines whether to perform compression inlining according to the compression size of the XOR value and the inline space management policy.

[0053] 205. When it is determined to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space.

[0054] Optionally, the terminal device determines whether to perform compression inlining according to the compression size of the XOR value and the inline space management policy, which may include: the terminal device determines whether to perform compression inlining according to a size threshold in the inline space management policy, the compression size of the XOR value, and the size of the XOR value;

[0055] In the case where it is determined to perform compression inlining, the terminal device compresses the XOR value to obtain a compression code and a compression code index, which may include: in the case where the difference between the size of the XOR value and the compressed size of the XOR value is greater than the size threshold, the terminal device determines to perform compression inlining, compresses the XOR value, and obtains a compression code and a compression code index.

[0056] Optionally, the method may further include: when the difference between the size of the XOR value and the compressed size of the XOR value is less than or equal to the size threshold, the terminal device determines not to perform compression inline and writes the write data to external memory.

[0057] Optionally, the compression code increases from the tail file attribute area to the head; each compression code includes a compression code index, a compression code size and a compression code content in sequence.

[0058] Optionally, the inline space is stored in a file node in memory.

[0059] like Figure 3A As shown, it is a comparative schematic diagram of the inline space layout of F2FS and the inline space layout of the present application. Among them, the F2FS inline space maintains a total of 923 4-byte data indexes, that is, 3.692KB. At the same time, the inline space reserves 50 4-byte data index spaces to maintain file attributes, that is, the size of the available data index area is (923-50)*4=3.488KB. The technical solution of the present application inserts a compression code linked list (Delta List) and a compression code index linked list (Delta indexList) into the inline space. Therefore, the inline space increments the contents of the two linked lists while maintaining the original data index and file attributes, which adds a certain complexity to the inline space management.

[0060] like Figure 3B As shown, it is a specific layout diagram of the inline space of this application. In the current F2FS, the inline space is in units of 4 bytes, and each 4 bytes maintains a data index. The first index is a reserved position, and the data index layout starts from the beginning. At the same time, the last 50 4-byte data indexes of the inline space are used to maintain file attributes. The compression code of the technical solution of this application increases from the tail file attribute area to the head. Each compression code starts from the compression code index, occupies 2 bytes, and is used to represent the data offset (0-872) of the compression code. After the compression code index is the compression code size, which occupies 1 byte and can record compression code sizes below 256, that is, the maximum supported compression code size of this technical solution is data compression of less than 256 bytes. After the compression code index, the compression code content is formally maintained. Through this layout, this technical solution inserts the compression code in real time during the operation of the mobile phone until it collides with the data index, and then starts the inline space replacement strategy to replace the compression code.

[0061] Optionally, the terminal device inserting the compression code and the compression code index into the inline space may include: when the size of the compression code inserted into the inline space is smaller than the size of the compression code pushed out of the inline space is smaller than a preset threshold, the terminal device inserting the compression code and the compression code index into the inline space.

[0062] Optionally, the method may further include: the terminal device stores the data stored before inserting the compression code and the inline space corresponding to the compression code index into an external memory.

[0063] It is understandable that the inline space of the new file system is larger than that of the traditional file system. For example, F2FS supports 3.488KB of inline space, while EXT4 only supports a maximum of 256Byte. However, inline space resources are still limited. Therefore, the technical solution of this application proposes an inline space compression code replacement strategy by conducting a detailed investigation of the input / output (IO) load characteristics, analyzing the benefits and system overhead of compressed inline. In terms of benefits, the inline space compression code replacement strategy calculates the average compression code size S of the system. xor , average write delay L W and compressed data write delay L CW , the replacement benefit is calculated by formula 1.

[0064]

[0065] Among them, SR is the size of the inline space released by the compression code replacement. The meaning of this formula is to calculate the number of entries of the average size compression code that can be accommodated by the released inline space size, multiplied by the performance benefit that each data compression can bring to the system (that is, the difference in IO latency before and after compression). It should be noted that the system benefits brought by compression include flash memory life in addition to IO performance. However, in order to ensure that the benefits are greater than the expenses, and because the flash memory life is heavily dependent on the manufacturer's process, this formula does not calculate the flash memory life benefit.

[0066] The system overhead caused by compression code replacement includes the decoding time delay L caused by dirty page recovery De , the write-back overhead of the restored data is L W , and the benchmark reading overhead during decoding. It is specifically calculated using Formula 2.

[0067] Cost = L De +L W +P hit ×L RC +(1-P hit )×L RF (2)

[0068] Among them, P hit is the benchmark memory hit rate, L RC is the memory read benchmark overhead, L RF Benchmark overhead for external memory reads.

[0069] By comparing the benefits and costs of compression code replacement, we can derive a specific replacement SR threshold. For example, when the system average write IO latency L W The average delay of compressed data is 954 microseconds. CW is 25 microseconds, and the average size of the compressed code is S xor 72 bytes, decoding time overhead L De7 microseconds, the benchmark memory hit rate P hit The memory read benchmark overhead is 74.1%. RC 9 microseconds, the external memory read benchmark overhead L RF It can be calculated that when SR is greater than 81 bytes, that is, when the size of the compressed code inserted into the inline space is 81 bytes smaller than the size of the compressed code pushed out of the inline space (exemplarily, the above preset threshold is 81 bytes), the replacement benefit will be greater than the replacement cost.

[0070] Through a series of comprehensive strategies of the present application, the technical solution of the present application can achieve aggressive data compression and minimize the reading and writing overhead caused by compression.

[0071] (1) The technical solution of this application can effectively reduce write pressure. For example, according to relevant experiments, more than 75% of the write IO in current mainstream mobile data applications is IO generated by data updates, and the average content difference before and after the update is 10.3%. By differentially compressing the updated data, the technical solution of this application can achieve a great degree of write pressure relief.

[0072] (2) The technical solution of this application realizes compression without hardware cost. By using pure software, the compression code is maintained in the inline space of the file node. Compared with related technologies, the technical solution of this application does not require additional hardware and has great advantages in cost, product volume, power consumption, heat control and IO management.

[0073] (3) The technical solution of this application is to improve IO performance through efficient data compression. For write IO, the update data IO that originally needed to be written to the external memory now only needs to maintain the increment to the inline space to complete the IO, shortening the millisecond-level write delay to a few to tens of microseconds, thereby greatly reducing the write IO overhead. For read IO, a large amount of current work points out that too much write IO will interfere with read IO at multiple operating system kernel levels, such as: IO scheduling layer, external memory channel layer chip layer, etc.; greatly reducing write IO can effectively improve the performance of read IO.

[0074] (4) The technical solution of the present application can improve the life of flash memory. Current mobile phone external storage uses flash memory as a storage medium, and one of the biggest features of flash memory is that it only supports valid write / erase cycles (Programming / EraseCycles), so the life of flash memory is approximately linearly related to the amount of writes. By reducing the amount of writes in a large amount and efficiently, the technical solution of the present application helps to significantly improve the life of flash memory, thereby effectively reducing the cost of flash memory devices; considering that the flash memory of most current smartphones is embedded, the technical solution of the present application can even help to extend the service life of the entire device.

[0075] In the embodiment of the present application, the write data generated by the system update is obtained; when the write data is inserted into the page cache, the old data is obtained from the page cache or external memory; the compression size of the XOR value of the write data and the old data is calculated; according to the compression size of the XOR value and the inline space management strategy, it is determined whether to perform compression inline; if it is determined to perform compression inline, the XOR value is compressed to obtain a compression code and a compression code index, and the compression code and the compression code index are inserted into the inline space. It is used to compress the write data and insert the compression code and the compression code index into the inline space to implement an aggressive data compression strategy and significantly reduce the amount of data written to the terminal device.

[0076] like Figure 4 FIG. 1 is a schematic diagram of another embodiment of a method for inline data compression for a terminal device in an embodiment of the present application. The method embodiment is applied to a terminal device. The method embodiment may include:

[0077] 401. Obtain write data generated by system update.

[0078] The present application embodiment is combined with Figure 1 The incremental compression inline system framework diagram shown is used for explanation. The terminal device obtains the write data generated by the system update.

[0079] 402. When the write data is inserted into the page cache, old data is obtained from the page cache or external memory.

[0080] 403. Calculate a compressed size of an XOR value of the write data and the old data.

[0081] 404. Determine whether to perform compression inlining according to the compression size of the XOR value and the inline space management strategy.

[0082] It should be noted that steps 401-404 in the embodiment of the present application are similar to Figure 2 Steps 201 - 204 in the illustrated embodiment are similar and will not be described in detail herein.

[0083] 405. When it is determined to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space.

[0084] Optionally, the first data is maintained in a first data linked list in the page cache, and the second data is maintained in a second data linked list in the page cache or in an external memory; wherein the read popularity of the first data is greater than that of the second data.

[0085] It is understandable that the first data list can also be called a new data list (Modified page list), and the second data list can also be called a base list (Base list). The first data is the compressed data with high read frequency; the second data is the compressed data with low read frequency; the specific judgment can be based on experience, which will not be repeated here.

[0086] Optionally, the method may further include: the terminal device inserting the write data into the first data linked list or the second data linked list according to the heat of the write data. That is, when the heat of the write data is high, the write data is inserted into the first data linked list, and when the heat of the write data is low, the write data is inserted into the second data linked list or external memory.

[0087] Optionally, the method may also include: after the first data linked list is full, the terminal device discards the pushed data of the first data linked list; after the second data linked list is full, the terminal device determines whether the pushed data of the second data linked list is a dirty page, and decides whether to write it back; if it is a dirty page, the terminal device writes back the pushed data of the second data linked list; if it is not a dirty page, the terminal device discards the pushed data of the second data linked list.

[0088] It should be noted that, for other descriptions about step 405 in the embodiment of the present application, reference can be made to step 205 in the embodiment shown in FIG. , which will not be described again here.

[0089] 406. Get read request.

[0090] 407. Search for data in the first data linked list according to the read request.

[0091] 408. If no data is found in the first data linked list, search for data in the second data linked list according to the read request.

[0092] 409. If no data is found in the second data linked list, search for data in an external memory according to the read request.

[0093] It is understandable that for the benchmark reading in the incremental compression decoding process, if the benchmark does not hit in the memory, it will cause read amplification in the external memory read operation, thereby affecting system performance. In order to improve the memory hit rate of the benchmark, the technical solution of this application proposes a memory page cache optimization strategy, which inserts a new linked list in the memory to manage the compressed data. Figure 3CAs shown, it is a flow chart of the page cache optimization strategy in the embodiment of the present application. The technical solution of the present application adds two linked lists in the page cache, namely the new data linked list (Modified page list) and the benchmark linked list (Base list). For compressed data with high frequent reading temperature, the latest version of the data will be maintained in the new data linked list. It should be noted that the linked list data will not mark dirty pages and write back, so as to reduce the amount of writing; for compressed data with slightly lower temperature, the technical solution maintains its benchmark in the benchmark linked list. In this strategy, the system reads compressed data flow each time first from the new data linked list, and then goes to the benchmark linked list if it misses, and finally goes to the external memory to find the benchmark. The specific process of writing compressed data in this strategy is that first the file write is generated ① and the compression code size and the inline space state ② are calculated to consider whether to compress the inline. If so, the XOR value is compressed ③, the compression code is inserted into the inline space ④, and the new data, that is, the write data updated by the system is directly inserted into the new data linked list and the benchmark is directly put into the external memory ⑥ or the benchmark is inserted into the benchmark linked list ⑧. It should be noted that in order to save memory overhead, the technical solution of this application strictly controls the volume of the reference linked list and the new data linked list. Referring to the pre-read volume of the current memory pre-reading strategy, the length of both linked lists is set to 32. Therefore, when the linked list is full, the technical solution of this application needs to push the tail node of the linked list out ⑤⑦ to accommodate the newly inserted node. For the new data linked list ⑤, the pushed data is directly released and discarded; for the reference linked list ⑦, the pushed data needs to be considered whether it is a dirty page to consider whether to write it back.

[0094] The technical solution of this application provides a series of operating system kernel optimization strategies, specifically: (1) update data compression inline strategy; (2) inline space efficient management strategy; (3) memory page cache optimization strategy.

[0095] It should be noted that the latest file systems, such as the F2FS file system, support large inline spaces to reduce the additional index reading overhead caused by large-size file indexes. However, for load environments such as mobile loads that are dominated by small-size files, large inline spaces will cause serious waste of space. The technical solution of the present application proposes that by maintaining the compression code of incremental compression in the inline space, pure software efficient data compression can be achieved and wasted space resources can be fully utilized. In addition, since the inline space is stored in the file node of the resident memory, the solution also helps to eliminate the external memory read overhead caused by frequent compression code reading.

[0096] Since LFS uses non-in-place updates, it needs to frequently dirty the file nodes to maintain the updated data addresses. Therefore, performing incremental compression code access operations in the inline space of the file node will not dirty the file node and cause additional write amplification. Secondly, for traditional in-place update file systems such as EXT4, incremental compression will cause holes in the compressed data addresses, causing serious fragmentation problems, while LFS can arrange all non-compressed data in order to avoid this problem. Therefore, this technical solution fully combines the technical advantages of LFS and incremental compression to achieve cost-free high-compression data compression.

[0097] In an embodiment of the present application, the write data generated by the system update is obtained; when the write data is inserted into the page cache, the old data is obtained from the page cache or external memory; the compression size of the XOR value of the write data and the old data is calculated; according to the compression size of the XOR value and the inline space management strategy, it is determined whether to perform compression inline; in the case of determining to perform compression inline, the XOR value is compressed to obtain a compression code and a compression code index, and the compression code and the compression code index are inserted into the inline space. It is used to compress the write data and insert the compression code and the compression code index into the inline space to implement a radical data compression strategy and greatly reduce the amount of data written to the terminal device. That is, the technical solution of the present application fully combines the technical characteristics of the log-structured file system (LFS) and incremental compression to implement a cost-free radical data compression strategy on the mobile phone side, thereby greatly reducing the amount of data written to the device.

[0098] like Figure 5 As shown, it is a schematic diagram of an embodiment of a terminal device in an embodiment of the present application, which may include:

[0099] An acquisition module 501 is used to acquire write data generated by system update;

[0100] The processing module 502 is used to obtain old data from the page cache or external memory when the write data is inserted into the page cache; calculate the compression size of the XOR value of the write data and the old data; determine whether to perform compression inlining according to the compression size of the XOR value and the inline space management strategy; if it is determined to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space.

[0101] Optionally, the processing module 502 is specifically used to determine whether to perform compressed inlining based on a size threshold in the inline space management strategy, the compression size of the XOR value, and the size of the XOR value; when the difference between the size of the XOR value and the compressed size of the XOR value is greater than the size threshold, determine to perform compressed inlining, compress the XOR value, and obtain a compression code and a compression code index.

[0102] Optionally, the compression code increases from the tail file attribute area to the head; each compression code includes a compression code index, a compression code size and a compression code content in sequence.

[0103] Optionally, the inline space is stored in a file node in memory.

[0104] Optionally, the first data is maintained in a first data linked list in the page cache, and the second data is maintained in a second data linked list in the page cache or in an external memory; wherein the read popularity of the first data is greater than that of the second data.

[0105] Optionally, the processing module 502 is further configured to insert the write data into the first data linked list or the second data linked list according to the heat of the write data.

[0106] Optionally, the acquisition module 501 is further used to acquire a read request;

[0107] The processing module 502 is also used to search for data in the first data linked list according to the read request; if the data is not found in the first data linked list, search for data in the second data linked list according to the read request; if the data is not found in the second data linked list, search for data in the external memory according to the read request.

[0108] Optionally, the processing module 502 is specifically configured to insert the compressed code and the compressed code index into the inline space when the size of the compressed code inserted into the inline space is smaller than the size of the compressed code pushed out of the inline space by a preset threshold.

[0109] Optionally, the method is applied to a terminal device including a log appending file system LFS.

[0110] like Figure 6 As shown, it is a schematic diagram of another embodiment of the terminal device in the embodiment of the present application, which may include:

[0111] Figure 6 FIG. 1 is a block diagram showing a partial structure of a mobile phone related to a terminal device provided in an embodiment of the present application. Figure 6The mobile phone includes: a radio frequency (RF) circuit 610, a memory 620, an input unit 630, a display unit 640, a sensor 650, an audio circuit 660, a wireless fidelity (Wi-Fi) module 670, a processor 680, and a power supply 690. Those skilled in the art will understand that Figure 6 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0112] Combine the following Figure 6 A detailed introduction to the various components of the mobile phone:

[0113] The RF circuit 610 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 680 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit 610 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (Low Noise Amplifier, LNA), a duplexer, etc. In addition, the RF circuit 610 can also communicate with the network and other devices through wireless communication. The above wireless communication can use any communication standard or protocol, including but not limited to Global System of Mobile communication (Global System of Mobile communication, GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, CDMA), Wideband Code Division Multiple Access (Wideband Code Division Multiple Access, WCDMA), Long Term Evolution (Long Term Evolution, LTE), email, Short Messaging Service (SMS), etc.

[0114] The memory 620 can be used to store software programs and modules. The processor 680 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 620. The memory 620 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 620 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0115] The input unit 630 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 630 may include a touch panel 631 and other input devices 632. The touch panel 631, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 631 or near the touch panel 631 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 631 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 680, and can receive and execute commands sent by the processor 680. In addition, the touch panel 631 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 631, the input unit 630 may also include other input devices 632. Specifically, the other input devices 632 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, etc.

[0116] The display unit 640 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 640 may include a display panel 641. Optionally, the display panel 641 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel 631 may cover the display panel 641. When the touch panel 631 detects a touch operation on or near it, it is transmitted to the processor 680 to determine the type of touch event. Subsequently, the processor 680 provides a corresponding visual output on the display panel 641 according to the type of touch event. Although in Figure 6 In the embodiment, the touch panel 631 and the display panel 641 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 631 and the display panel 641 can be integrated to realize the input and output functions of the mobile phone.

[0117] The mobile phone may also include at least one sensor 650, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 641 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 641 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0118] The audio circuit 660, the speaker 661, and the microphone 662 can provide an audio interface between the user and the mobile phone. The audio circuit 660 can transmit the received audio data to the speaker 661 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 662 converts the collected sound signal into an electrical signal, which is received by the audio circuit 660 and converted into audio data, and then the audio data is output to the processor 680 for processing, and then sent to another mobile phone through the RF circuit 610, or the audio data is output to the memory 620 for further processing.

[0119] Wi-Fi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the Wi-Fi module 670, which provides users with wireless broadband Internet access. Figure 6A Wi-Fi module 670 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the application.

[0120] The processor 680 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 620, and calling data stored in the memory 620, it executes various functions of the mobile phone and processes data, thereby monitoring the mobile phone as a whole. Optionally, the processor 680 may include one or more processing units; preferably, the processor 680 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 680.

[0121] The mobile phone also includes a power supply 690 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 680 through a power management system, so that the power management system can manage charging, discharging, power consumption and other functions.

[0122] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

[0123] In an embodiment of the present application, processor 680 is used to obtain write data generated by system updates; when the write data is inserted into the page cache, old data is obtained from the page cache or external memory; the compression size of the XOR value of the write data and the old data is calculated; according to the compression size of the XOR value and the inline space management strategy, it is determined whether to perform compression inlining; if it is determined to perform compression inlining, the XOR value is compressed to obtain a compression code and a compression code index, and the compression code and the compression code index are inserted into the inline space.

[0124] Optionally, the processor 680 is specifically used to determine whether to perform compressed inlining based on a size threshold in the inline space management strategy, the compression size of the XOR value, and the size of the XOR value; when the difference between the size of the XOR value and the compressed size of the XOR value is greater than the size threshold, determine to perform compressed inlining, compress the XOR value, and obtain a compression code and a compression code index.

[0125] Optionally, the compression code increases from the tail file attribute area to the head; each compression code includes a compression code index, a compression code size and a compression code content in sequence.

[0126] Optionally, the inline space is stored in a file node in memory.

[0127] Optionally, the first data is maintained in a first data linked list in the page cache, and the second data is maintained in a second data linked list in the page cache or in an external memory; wherein the read popularity of the first data is greater than that of the second data.

[0128] Optionally, the processor 680 is further configured to insert the write data into the first data linked list or the second data linked list according to the heat of the write data.

[0129] Optionally, processor 680 is also used to obtain a read request; search for data in the first data linked list according to the read request; if the data is not found in the first data linked list, search for data in the second data linked list according to the read request; if the data is not found in the second data linked list, search for data in the external memory according to the read request.

[0130] Optionally, the processor 680 is specifically configured to insert the compression code and the compression code index into the inline space when a size of the compression code inserted into the inline space is smaller than a preset threshold value than a size of the compression code pushed out of the inline space.

[0131] Optionally, the method is applied to a terminal device including a log appending file system LFS.

[0132] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0133] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0134] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0135] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0136] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0137] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk.

[0138] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A data inline compression method for terminal devices, characterized in that: The method is applied to a terminal device, and the method comprises: Get the write data generated by the system update; When the write data is inserted into the page cache, old data is obtained from the page cache or external memory; Calculate the compressed size of the XOR value of the write data and the old data; Determining whether to perform compression inlining according to a size threshold in an inline space management strategy, a compression size of the XOR value, and a size of the XOR value; When the difference between the size of the XOR value and the compressed size of the XOR value is greater than the size threshold, determine to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space; Each compressed code includes a compressed code index, a compressed code size and a compressed code content in sequence.

2. The method according to claim 1, characterized in that The compression code increases from the tail file attribute area to the head.

3. The method according to claim 1, characterized in that The first data is maintained in a first data linked list in the page cache, and the second data is maintained in a second data linked list in the page cache or in an external memory; wherein the read popularity of the first data is greater than that of the second data.

4. The method according to claim 3, characterized in that The method further comprises: The write data is inserted into the first data linked list or the second data linked list according to the heat of the write data.

5. The method according to claim 3, characterized in that: The method further comprises: Get read request; Searching for data in the first data linked list according to the read request; If no data is found in the first data linked list, searching for data in the second data linked list according to the read request; When the data is not found in the second data linked list, the data is searched in the external memory according to the read request.

6. The method according to claim 1, characterized in that The step of inserting the compressed code and the compressed code index into an inline space comprises: In a case where the size of the compressed code inserted into the inline space is smaller than the size of the compressed code pushed out of the inline space by a preset threshold, the compressed code and the compressed code index are inserted into the inline space.

7. The method according to claim 1, characterized in that The method is applied to a terminal device including a log appending file system LFS.

8. A terminal device, characterized in that: include: The acquisition module is used to obtain the write data generated by the system update; A processing module, configured to obtain old data from the page cache or an external memory when the write data is inserted into the page cache; Calculate the compressed size of the XOR value of the write data and the old data; Determining whether to perform compression inlining according to a size threshold in an inline space management strategy, a compression size of the XOR value, and a size of the XOR value; When the difference between the size of the XOR value and the compressed size of the XOR value is greater than the size threshold, it is determined to perform compression inlining, compress the XOR value to obtain a compression code and a compression code index, and insert the compression code and the compression code index into the inline space; wherein each compression code includes a compression code index, a compression code size and a compression code content in sequence.

9. A terminal device, characterized in that: include: A memory storing executable program code; a processor coupled to the memory; The processor is used to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium comprising instructions, which, when executed on a processor, causes the processor to perform the method according to any one of claims 1 to 7.

Images