Partition management method and device

Abstract

A partition management method and device, which relate to the technical field of storage. The method comprises: acquiring a request message for reading and writing partitions comprised in a storage device, the partitions comprised in the storage device comprising a user data partition and system partitions. The system partitions comprise first system partitions and a second system partition, the first system partitions are provided in front of the user data partition, and the second system partition is provided behind the user data partition. Then, a target partition comprised in the storage device is determined according to the request message, and the target partition is read and written. In this way, a part of the system partitions is provided behind the user data partition, which is equivalent to expanding the size of the system partitions located in front of the user data partition. If system software in the foregoing front system partitions is updated, the sizes of the system partitions are able to be sufficient for the updated system software, and the probability of successful system software updating will be improved.

Description

Partition management method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on June 13, 2023, with application number 202310700273.6 and application name “Partition Management Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of storage technology, and in particular to a partition management method and device. Background Art

[0003] Partitioning is an important means of dividing storage devices (such as disks) into areas. A storage device can be divided into several areas based on information such as the starting address and size. The divided areas are called partitions, and different partitions can be used to store different data.

[0004] Currently, partitions on storage devices include system partitions and user data partitions. The system partition can be used to store system software data, while the user data partition can be used to store data generated by users while using the storage device. The system partition is typically located at the head of the storage device, while the user data partition is typically located at the tail of the storage device. As system software is updated, the size of the system software data may exceed the space available in the corresponding system partition, causing the update to fail. Therefore, managing the system partition to ensure that the size of the system partition is sufficient for system software updates is a challenge that needs to be addressed.

[0005] Summary of the Invention

[0006] The present application provides a partition management method and device, which can expand the size of the system partition so that the size of the system partition can meet the needs of the updated system software, thereby increasing the probability of successful system software update.

[0007] To achieve the above objectives, this application adopts the following technical solutions:

[0008] In a first aspect, a partition management method is provided, the method comprising: obtaining a request message, the request message being used to read and write partitions included in a storage device, the partitions comprising a user data partition and multiple system partitions, the system partition being used to store a first type of data, the user data partition being used to store a second type of data, the system partitions comprising a first system partition and a second system partition, the first system partition being arranged in front of the user data partition, and the second system partition being arranged behind the user data partition; determining a target partition included in the storage device according to the request message; and reading and writing the target partition.

[0009] The first type of data and the second type of data are different types of data.

[0010] Based on the above technical solution, compared to placing the entire system partition in front of the user data partition, placing some system partitions behind the user data partition effectively divides the space occupied by these rear-placed system partitions with the front-placed system partitions, thereby expanding the space of the system partitions located in front of the user data partitions. This way, if the software in these front-placed system partitions is updated, the system partition size can accommodate the updated system software, increasing the probability of a successful system software update.

[0011] In one possible design, before the request message is received, the first system partition and the second system partition are both located in front of the user data partition; the method further includes: if the first system partition does not have sufficient space, merging part or all of the space of the second system partition located in front of the user data partition into the space of the first system partition; and placing the second system partition behind the user data partition. Based on this design, the second system partition located in front of the user data partition is placed behind the user data partition, and the freed space in front of the user data partition is then allocated to the first system partition, thereby achieving the purpose of expanding the system partition size. Furthermore, if the first system partition does not have sufficient space, executing this process again can save system overhead.

[0012] In one possible design, the starting address of the user data partition remains unchanged; setting the second system partition after the user data partition includes: setting the first space of the user data partition as the second system partition, where the first space includes the continuous free space at the end of the user data partition. Based on this design, the starting address of the user data partition does not need to be modified, and thus the storage address of all data in the user data partition does not need to be modified. Only the end address of the user data partition needs to be modified, which can reduce the risk of modifying the storage address of all data in the user data partition and reduce the time and system overhead of expanding the system partition. In addition, allocating the continuous free space at the end of the user data partition to the second system partition can facilitate reading and writing data in the second system partition.

[0013] In one possible design, the first space is larger than or equal to the second system partition. Based on this design, the contiguous space at the end of the user data partition that is larger than the second system partition is repartitioned as the second system partition, effectively expanding the space of the second system partition. This allows for expansion of the second system partition even if the second system partition lacks sufficient space. Repartitioning the contiguous space at the end of the user data partition that is equal to the second system partition as the second system partition ensures sufficient space for data storage in the second system partition.

[0014] In one possible design, before setting the first space of the user data partition as the second system partition, the method also includes: if user data is stored in the first space, moving the user data to the second space of the user data partition for storage, the second space being different from the first space, and the second space being the free space in the user data partition.

[0015] Based on this design, if data is stored in the contiguous free space at the end of the user data partition, the data in that space can be moved to other free space in the user data partition, thereby obtaining contiguous free space at the end of the user data partition and allocating that space to the second system partition. This leaves the starting address of the user data partition unchanged; only the ending address of the user data partition and the storage address of the moved data need to be modified. This eliminates the need to adjust the addresses of the user data partition and all data stored in it. This reduces the time and system overhead of expanding the system partition while minimizing the risks associated with modifying the storage addresses of data in the user data partition.

[0016] In one possible design, the first space of the user data partition is set as the second system partition by updating the size of the user data partition and the start and end addresses of the second system partition as included in the partition table. The partition table corresponds to the storage device and is used to index the partitions included in the storage device. Based on this design, the system partition can be placed after the user data partition by modifying the size of the user data partition and the start and end addresses of the second system partition as included in the partition table corresponding to the storage device.

[0017] In one possible design, the starting address of the updated second system partition is determined based on the size of the storage device and the size of the first space; and the size of the updated user data partition is determined based on the starting address of the user data partition and the starting address of the updated second system partition. Based on this design, since different storage devices have different sizes, the starting addresses of the system partitions located after the user data partitions also vary. Thus, by determining the starting address of the second system partition based on the size of the storage device and the size of the first space, the accuracy of the obtained starting address of the second system partition can be improved, and thus the accuracy of the obtained size of the user data partition can be improved.

[0018] In one possible design, the method further includes: when the space of the second system partition is insufficient, merging the third space of the user data partition into the space of the second system partition, wherein the third space includes the continuous free space at the end of the user data partition. Based on this design, when the space of the system partition set behind the user data partition is insufficient, the continuous free space at the end of the user data partition is further allocated to the system partition. When the size of the system partition to be expanded is reached, the starting address of the user data partition does not need to be changed. Only the ending address of the user data partition and the storage address of the moved data need to be modified. That is, there is no need to adjust the addresses of the user data partition and all the data stored in the user data partition. This can reduce the risk of modifying the storage address of the data in the user data partition while reducing the time consumption and system overhead of expanding the system partition.

[0019] In one possible design, before merging the third space of the user data partition into the space of the second system partition, the method further includes: if user data is stored in the third space, moving the user data to a fourth space of the user data partition for storage, where the fourth space is different from the third space and is free space within the user data partition. Based on this design, if data is stored in the continuous free space at the end of the user data partition, the data in that space can be moved to other free space within the user data partition. This can achieve the goal of obtaining continuous free space at the end of the user data partition, allowing this space to be allocated to the insufficient second system partition. In this way, while achieving the goal of expanding the size of the second system partition, the starting address of the user data partition remains unchanged; only the ending address of the user data partition and the storage address of the moved data need to be modified. That is, the addresses of the user data partition and all data stored in the user data partition do not need to be fully adjusted. This can reduce the time and system overhead of expanding the system partition while reducing the risks associated with modifying the storage address of data in the user data partition.

[0020] In one possible design, before obtaining the request message, the method further includes: obtaining a partition table, the partition table including at least one parameter including the starting address and ending address of the second system partition and the size of the user data partition; and determining whether to update the at least one parameter based on the size of the storage device. Based on this design, since different storage devices may correspond to different partition tables, the starting address and ending address of the second system partition, the size of the user data partition, and the like included in the storage table are corrected based on the actual size of the storage device. This ensures that the partition table is compatible with the actual size of the storage device, thereby ensuring the read and write performance of the storage device.

[0021] In a second aspect, a device is provided, which has the function of implementing the method described in the first aspect and any one of the designs thereof. The function can be implemented by hardware, or by hardware executing corresponding software implementation. The hardware or software includes one or more modules corresponding to the above functions. In a possible example, the device includes an acquisition unit (or acquisition module) and a processing unit (or processing module); the acquisition unit is used to obtain a request message, and the request message is used to read and write partitions included in the storage device, the partitions include a user data partition and multiple system partitions, the system partition is used to store a first type of data, the user data partition is used to store a second type of data, the system partition includes a first system partition and a second system partition, the first system partition is set in front of the user data partition, and the second system partition is set behind the user data partition; the processing unit is used to determine the target partition included in the storage device according to the request message; the processing unit is also used to read and write the target partition.

[0022] In one possible design, the first system partition and the second system partition are both set in front of the user data partition; the processing unit is also used to merge part or all of the space of the second system partition set in front of the user data partition into the space of the first system partition when the space of the first system partition is insufficient; the processing unit is also used to set the second system partition behind the user data partition.

[0023] In one possible design, the starting address of the user data partition remains unchanged; the processing unit is specifically used to set the first space of the user data partition as the second system partition, and the first space includes the continuous free space at the end of the user data partition.

[0024] In one possible design, the first space is larger than or equal to the second system partition.

[0025] In one possible design, the processing unit is also used to move user data to the second space of the user data partition for storage if the user data is stored in the first space. The second space is different from the first space and is the free space in the user data partition.

[0026] In one possible design, the first space of the user data partition is set as the second system partition by updating the size of the user data partition included in the partition table, as well as the starting address and ending address of the second system partition. The partition table corresponds to the storage device, and the partition table is used to index the partitions included in the storage device.

[0027] In one possible design, the starting address of the updated second system partition is determined according to the size of the storage device and the size of the first space; the size of the updated user data partition is determined according to the starting address of the user data partition and the starting address of the updated second system partition.

[0028] In one possible design, the processing unit is further used to merge the third space of the user data partition into the space of the second system partition when the space of the second system partition is insufficient, and the third space includes the continuous free space at the end of the user data partition.

[0029] In one possible design, the processing unit is also used to move user data to the fourth space of the user data partition for storage if the user data is stored in the third space. The fourth space is different from the third space and is the free space in the user data partition.

[0030] In one possible design, the acquisition unit is also used to obtain a partition table, which includes the starting address and ending address of the second system partition and at least one parameter of the size of the user data partition; the processing unit is also used to determine whether to update the at least one parameter based on the size of the storage device.

[0031] In a third aspect, a device is provided, comprising a processor and a memory, wherein the memory is coupled to the processor, the memory is used to store computer program code, the computer program code comprises computer instructions, and the processor reads the computer instructions from the memory so that the device executes the method described in the first aspect and any one of the designs thereof.

[0032] In one possible design, the device further includes a communication interface that can be used for the device to communicate with other devices. Exemplarily, the communication interface can be a transceiver, an input / output interface, an interface circuit, an output circuit, an input circuit, a pin, or related circuits.

[0033] In a fourth aspect, a computer-readable storage medium is provided, which includes a computer program or instructions. When the computer program or instructions are run on a device, the device executes the method described in the first aspect and any one of the designs thereof.

[0034] In a fifth aspect, a computer program product is provided. When the computer program product is run on a computer, the computer can execute the method described in the first aspect and any one of the designs thereof.

[0035] In a sixth aspect, a circuit system is provided, the circuit system including a processing circuit, and the processing circuit is configured to execute the method described in any one of the designs of the first aspect above.

[0036] In the seventh aspect, a chip system is provided, comprising at least one processor and at least one interface circuit, wherein the at least one interface circuit is used to perform transceiver functions and send instructions to the at least one processor. When the at least one processor executes the instructions, the at least one processor executes the method described in the first aspect and any one of the designs therein.

[0037] It should be noted that the technical effects brought about by any design in the above-mentioned second to seventh aspects can refer to the technical effects brought about by the corresponding design in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] FIG1 is a schematic diagram of the structure of an existing GPT;

[0039] FIG2 is a schematic diagram of the architecture of a file system provided in an embodiment of the present application;

[0040] FIG3 is a schematic diagram of the structure of an existing partition;

[0041] FIG4 is a schematic diagram of the architecture of an existing file system;

[0042] FIG5 is a schematic diagram of an existing interface for adjusting the size of a system partition;

[0043] FIG6 is a schematic diagram of the structure of a device provided in an embodiment of the present application;

[0044] FIG7 is a schematic diagram of the architecture of a centralized storage system provided in an embodiment of the present application;

[0045] FIG8 is a schematic structural diagram of another device provided in an embodiment of the present application;

[0046] FIG9 is a software structure block diagram of a device provided in an embodiment of the present application;

[0047] FIG10 is a schematic diagram of a scenario of moving data in a user data partition according to an embodiment of the present application;

[0048] FIG11 is a schematic diagram of a partition structure provided in an embodiment of the present application;

[0049] FIG12a is a schematic diagram of a scenario of a partition management method provided in an embodiment of the present application;

[0050] FIG12b is a schematic diagram of another scenario of a partition management method provided in an embodiment of the present application;

[0051] FIG13 is a schematic diagram of a scenario of updating a partition table provided in an embodiment of the present application;

[0052] FIG14 is a schematic diagram of a flow chart of a partition management method provided in an embodiment of the present application;

[0053] FIG15 is a flow chart of another partition management method provided in an embodiment of the present application;

[0054] FIG16 is a flow chart of another partition management method provided in an embodiment of the present application;

[0055] FIG17 is a schematic structural diagram of another device provided in an embodiment of the present application;

[0056] FIG18 is a schematic structural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0057] In the description of this application, unless otherwise specified, " / " indicates that the objects associated before and after are in an "or" relationship, for example, A / B can represent A or B; "and / or" in this application is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural.

[0058] In the description of this application, unless otherwise specified, "plurality" means two or more than two. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, a, b, and c, where a, b, and c can be single or plural.

[0059] In addition, to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or execution order, and the words "first" and "second" do not necessarily mean different.

[0060] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0061] The features, structures, or characteristics of this application may be combined in any suitable manner in one or more embodiments. In the various embodiments of this application, the order of the sequence numbers of the processes does not necessarily indicate the order of execution. The order of execution of the processes should be determined by their functions and inherent logic, and should not constitute any limitation on the implementation of the embodiments of this application.

[0062] Some optional features in the embodiments of the present application can be implemented independently in certain scenarios without relying on other features to solve corresponding technical problems and achieve corresponding effects. They can also be combined with other features in certain scenarios as needed.

[0063] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referenced to each other. In the various embodiments of this application, unless otherwise specified and there is no logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The implementation methods of this application do not constitute a limitation on the scope of protection of this application.

[0064] In addition, the network architecture and business scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Ordinary technicians in this field can know that with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0065] It is understood that the embodiments of the present application use a partition structure in which a storage device is divided into a system partition and a user data partition, where the system partition is used to store system software data and the user data partition is used to store data generated by the user during the use of the storage device. The technical solutions provided in the embodiments of the present application are also applicable to a partition structure in which a storage device is divided into two different types of partitions, each of which is used to store different types of data. It is also understood that the name of a partition does not constitute a limitation on its function.

[0066] To facilitate understanding, the following first introduces the technical terms and related concepts that may be involved in the embodiments of this application.

[0067] 1. Partition

[0068] Partitioning is an important means of dividing storage devices (such as disks) into areas. A storage device can be divided into several areas based on information such as the starting address and size. The divided areas are called partitions, and different partitions can be used to store different data.

[0069] In some partition architectures, the partitions on the storage device include a system partition and a user data partition. The system partition can be used to store system software data, which can be used to implement some system functions. For example, the system partition may include a FASTBOOT partition, an NV partition, a MODEM partition, a KERNEL partition, a SYSTEM partition, a VENDOR partition, a PRODUCT partition, etc. Among them, the data stored in the FASTBOOT partition can be used for device system startup, etc. In some embodiments, the device can be a device equipped with the above-mentioned storage device. The NV partition is used to store some information of the device, such as radio frequency parameters, etc. The data stored in the MODEM partition can be used for the device to implement communication functions. The KERNEL partition can be used to store the image file of the system kernel. The SYSTEM partition, the VENDOR partition, and the PRODUCT partition can be used to store data related to the upper-level operating system, such as pre-installed applications, executable programs, system services, etc.

[0070] The user data partition can be used to store data generated when the user uses the storage device.

[0071] 2. Partition table

[0072] The partition table is the backbone that supports the normal operation of storage devices (such as disks). It can be used to divide a storage device into several partitions and record information about each partition. Optionally, the partition table can be stored in the header of the storage device.

[0073] Currently, partition table types include the Master Boot Record (MBR) partition table and the Globally Unique Identifier (GUID) partition table (GPT). The MBR partition table, as the traditional partitioning scheme, stores partition information in the 64 bytes of the first sector of a storage device, and can only represent a limited number of partitions on the storage device.

[0074] GPT is a partition table corresponding to the new partitioning scheme. It divides the storage device into logical block addresses (LBA) and records partition information. Compared with MBR, GPT can represent more partitions on the storage device.

[0075] For example, FIG1 shows a schematic diagram of the structure of an existing GPT. As shown in FIG1 , the GPT header LBA0 stores the MBR of the traditional partition scheme, which can be called a protective MBR. LBA1 is the primary GPT header, which stores the available space of the storage device, the size and number of entries that make up the partition table, etc. LBA2-LBA33 store partition table entries. A partition table entry is used to represent the information of a partition, such as the partition type, start address, end address, partition name, partition attributes, etc. LBA33 and later stores the data of each partition, such as the data of partition 1, the data of partition 2, and so on.

[0076] 3. File System

[0077] A file system is the method and data structure used by a device's operating system to identify files on a device's partitions. A file system is a structured form of data file storage and organization. For example, Figure 2 shows a schematic diagram of the structure of a file system provided in an embodiment of the present application.

[0078] All data in a computer consists of 0s and 1s. The series of 0s and 1s stored on hardware media is completely incomprehensible and impossible for a computer to understand or manage. Therefore, computers use the concept of "files" to organize this data. Data used for the same purpose can be organized into different types of files according to the structure required by different applications. Different suffixes are typically used to denote different types of data, and the computer then assigns each file a name that is easy to understand and remember.

[0079] When there are many files, the computer groups them (as shown in the white squares in Figure 2) according to a certain partitioning method. Each group of files is placed in the same directory (or folder, as shown in the black squares in Figure 2). Furthermore, in addition to files, directories can also contain sub-directories (called sub-directories or sub-folders), forming a tree-like structure. This tree structure has a special name: file system. There are many types of file systems, including Windows' FAT / FAT32 / NTFS and Linux's EXT2 / EXT3 / EXT4 / XFS / BtrFS.

[0080] Typically, a file system consists of two parts: metadata and file data. Metadata includes information about the file system's attributes, such as the file system type and size, as well as indexes of the file data stored within the file system. File data is the actual content of the files stored within the file system.

[0081] In the current partitioning scheme, the system partition is placed at the head of the storage device, and the user data partition is placed at the tail of the storage device. In some scenarios, storage devices may have different configuration versions. The capacity of storage devices with different configuration versions may vary, and the configured partition sizes may also be different. However, to ensure the reliability of the data in the user data partition, the starting address (or starting position on the storage device) of the user data partition is the same on storage devices with different configurations.

[0082] For example, taking the capacity of a low-configuration version of a storage device as 128 gigabytes (GB, abbreviated as G), the capacity of a high-configuration version of a storage device as 256G, and the system partition including a FASTBOOT partition, an NV partition, a MODEM partition, a KERNEL partition, a SYSTEM partition, a VENDOR partition, a PRODUCT partition, etc. as an example, Figure 3 shows a schematic diagram of the structure of an existing partition.

[0083] Among them, Figure 3 (1) is a schematic diagram of the structure of the partitions set on a 128G storage device, and Figure 3 (2) is a schematic diagram of the structure of the partitions set on a 256G storage device. As shown in Figure 3 (1) and Figure 3 (2), the system partition is set at the head of the storage device, and the user data partition is set at the tail of the storage device. The starting address of the user data partition on the 128G storage device is the same as the starting address on the 256G storage device, but the size of the user data partition is different. For example, the size of the user data partition on the 128G storage device is smaller than the size of the user data partition on the 256G storage device.

[0084] During device use, the system software in the device may be updated to provide a better user experience. As the system software is updated, the system software data may exceed the size of the corresponding system partition. For example, for an image file stored in the MODEM partition shown in Figure 3, due to the corresponding system software update, the image file becomes larger. The size of the MODEM partition may not be sufficient to store the increased size of the image file. This may cause the system software update to fail, meaning that the system software cannot be updated in a timely manner, thus affecting the user experience.

[0085] One existing solution involves reserving space in the system partition when setting up the system partition to meet system software update requirements. For example, when setting up a system partition, a portion of free space is reserved within the system partition. Alternatively, a portion of free space is reserved on a storage device. When the system partition is insufficient, this reserved free space is used as the system partition's space. In this solution, because the size of the updated system software data cannot be estimated, the reserved free space may still be insufficient, or excessive free space may result in reduced storage space for user data, impacting the user experience.

[0086] Another solution addresses this issue by evolving the Hierarchical File System Plus (HFS+) to the Apple File System (APFS), which provides runtime storage sharing capabilities. This capability involves adding a virtual volume management layer, allowing a partition to have multiple virtual volumes, and the partition's space can be allocated to any of these volumes.

[0087] For example, (1) in FIG4 is a schematic diagram of the structure of an existing HFS+. As shown in (1) in FIG4, one partition corresponds to one virtual volume, and the space of the partition can only be allocated to the corresponding virtual volume for use. For example, the space of partition 1 can be allocated to virtual volume 1, and the space of partition 2 can be allocated to virtual volume 2. (2) in FIG4 is a schematic diagram of the structure of an existing APFS file system. As shown in (2) in FIG4, one partition corresponds to multiple virtual volumes, and the space of the partition can be allocated to these multiple virtual volumes for use. For example, the space of partition 3 can be allocated to virtual volume 3 and virtual volume 4 at the same time.

[0088] In this solution, the added virtual volume management layer will cause performance loss during operation.

[0089] In another solution, the above technical problem is solved by adjusting the size of the system partition and the user data partition under an architecture in which the system partition and the user data partition are not isolated. It can be understood that the architecture in which the system partition and the user data partition are not isolated means that the system partition and the user data partition may simultaneously store data generated by the user during the use of the device and data of the system software. For example, Figure 5 shows an existing interface schematic diagram for adjusting the size of the system partition. As shown in Figure 5, the adjustment interface 500 of a partition includes an adjustment button 501 and an adjustment button 502. The size of the corresponding partition can be adjusted by dragging the adjustment button 501 and / or the adjustment button 502 left and right. The adjustment interface 500 can also include one or more adjustment options, such as partition size 503, available space in front of the partition 504, available space behind the partition 505, etc. The size of the partition can also be adjusted through these adjustment options.

[0090] First, this solution isn't suitable for a partition structure where the system partition and user data partition are separated. That is, the system partition is used only to store system software data, while the user data partition is used only to store data generated by the user during device usage. Furthermore, this solution requires the user to adjust the size of the system partition and / or the user data partition, which is cumbersome. Furthermore, during the partition resizing process, the user may modify the starting address of the user data partition, requiring the recalculation and refresh of the storage addresses of all data stored in that user data partition. This process is time-consuming and imposes significant system overhead.

[0091] Based on this, an embodiment of the present application provides a partition management method, which can expand the size of the system partition by setting part of the system partition at the tail position of the storage device, so that the size of the system partition can meet the needs of the updated system software, thereby increasing the probability of successful system software update. At the same time, it can also reduce the time consumption of expanding the system partition and reduce system overhead.

[0092] The technical solution provided in the embodiment of the present application can be applied to the device 600, or to a system including the device 600.

[0093] For example, device 600 may be an embedded device, a mobile phone, a tablet computer, a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, as well as various types of terminal devices such as a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device.

[0094] For another example, the device 600 may be a network device, such as a Node B (NB), a baseband unit (BBU), an access point (AP) in a wireless fidelity (WIFI) system, a wireless relay node, a wireless backhaul node, a transmission point (TP) or a transmission / receipt point (TRP), etc. It may also be a 5G, such as a gNB in ​​an NR system, or a transmission point (TRP or TP), or a network node constituting a gNB or a transmission point, such as a baseband unit (BBU) or a distributed unit (DU), etc. It may also be a satellite, etc.

[0095] For another example, the device 600 in the present application may be a module, a module, a component, or a chip, etc., which is built into any device as one or more components or units.

[0096] In some embodiments, the device 600 may be a fixed device or a portable device.

[0097] Optionally, the operating system installed on the device 600 includes but is not limited to This application does not limit the specific type of device 600 or the installed operating system.

[0098] For example, taking the device 600 as a mobile phone as an example, FIG6 shows a structural diagram of a device 600 provided in an embodiment of the present application.

[0099] As shown in Figure 6, the device 600 may include a processor 610, a storage device 620, a universal serial bus (USB) interface 630, a charging management module 640, a power management module 641, a battery 642, an antenna 1, an antenna 2, a mobile communication module 650, a wireless communication module 660, an audio module 670, a sensor module 680, a button 690, a motor 691, an indicator 692, a camera 693, a display screen 694, and a subscriber identification module (SIM) card interface 695, etc.

[0100] The processor 610 may include one or more processing units. For example, the processor 610 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0101] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0102] Processor 610 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 610 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 610. If processor 610 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 610 latency, and thus improves system efficiency.

[0103] In some embodiments, processor 610 may include one or more interfaces.

[0104] The charging management module 640 is used to receive charging input from a charger, which can be a wireless charger or a wired charger.

[0105] The power management module 641 is used to connect the battery 642, the charging management module 640, and the processor 610. The power management module 641 receives input from the battery 642 and / or the charging management module 640 to provide power to the processor 610, the storage device 620, the display 694, the camera 693, and the wireless communication module 660.

[0106] The wireless communication function of the device 600 can be implemented through antenna 1, antenna 2, mobile communication module 650, wireless communication module 660, modem processor and baseband processor.

[0107] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in device 600 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.

[0108] The mobile communication module 650 can provide solutions for wireless communications including 2G / 3G / 4G / 5G, etc., applied to the device 600. The mobile communication module 650 can include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc.

[0109] The wireless communication module 660 can provide wireless communication solutions applied on the device 600, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication technology (NFC), infrared technology (IR), etc.

[0110] In some embodiments, antenna 1 of device 600 is coupled to mobile communication module 650 , and antenna 2 is coupled to wireless communication module 660 , so that device 600 can communicate with a network and other devices via wireless communication technology.

[0111] Device 600 implements display functionality through a GPU, a display screen 694, and an application processor. Display screen 694 is used to display images, videos, and the like. Display screen 694 includes a display panel. Camera 693 is used to capture still images or videos.

[0112] The storage device 620 can be used to store computer executable program code, which includes instructions. The storage device 620 may include a program storage area and a data storage area. The program storage area may 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 may store data created during the use of the device 600 (such as audio data, a phone book, etc.). In some embodiments, the storage device 620 and the device 600 may be integrated together, such as the storage device 620 may be a module, module, component, or chip built into the device 600 as one or more components or units. In other embodiments, the storage device 620 may be set separately from the device 600.

[0113] Exemplarily, the storage device 620 may be a memory in which various system partitions are separated from user data partitions. For example, the storage device 620 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), a mechanical hard disk drive (HDD), a solid state drive (SSD), a shingled magnetic recording (SMR) disk, or an SSD that supports a zoned namespace (ZNS), or other memory, such as a persistent memory (PMEM). The processor 610 executes various functional applications and data processing of the device 600 by running instructions stored in the storage device 620 and / or instructions stored in a memory provided in the processor.

[0114] In some embodiments of the present application, the device 600 may divide the storage device 620 into different partitions using a partition table, and different partitions may be used to store different data. In some embodiments, the storage device 620 may include a system partition and a user data partition. For example, the system partition may be the program storage area described above, and the user data partition may be the data storage area described above.

[0115] Optionally, in the embodiments of the present application, the storage system employed by device 600 and the like can be a centralized storage system or a distributed storage system. A centralized storage system is characterized by a unified entry point through which all data from external devices must pass. This entry point is the engine of the centralized storage system. The engine is the core component of the centralized storage system, implementing many of the system's advanced functions.

[0116] For example, FIG7 shows a schematic diagram of the architecture of a centralized storage system provided in an embodiment of the present application.

[0117] As shown in FIG7 , engine 121 may include one or more controllers. FIG7 illustrates an example in which engine 121 includes a single controller. In one possible example, if engine 121 includes multiple controllers, a mirroring channel may be established between any two controllers, enabling the two controllers to serve as backups for each other, thereby preventing hardware failures from causing the entire device 600 to become unavailable.

[0118] The engine 121 also includes a front-end interface 1211 and a back-end interface 1214. The front-end interface 1211 is used to communicate with other devices, while the back-end interface 1214 is used to communicate with the storage device 620 to expand the capacity of the device 600. Through the back-end interface 1214, the engine 121 can connect to more storage devices 620, thereby forming a very large storage resource pool.

[0119] In terms of hardware, as shown in Figure 7 , the controller includes at least a processor 1212 and memory 1213. Processor 1212 is a central processing unit (CPU) that processes data access requests from outside device 600 (such as servers or other storage systems) and also processes requests generated within device 600. For an introduction to processor 1212, please refer to the introduction to processor 610 above.

[0120] Exemplarily, when processor 1212 receives write data requests from other devices via front-end interface 1211, it temporarily stores the data in these write data requests in memory 1213. When the total amount of data in memory 1213 reaches a certain threshold, processor 1212 sends the data stored in memory 1213 to storage device 620 via the back-end port for persistent storage. FIG7 takes the example of storage device 620 including a hard disk drive (HDD) 1221, a mechanical hard disk 1222, a solid state drive (SSD) 1223, or another hard disk 1224.

[0121] Memory 1213 refers to an internal memory that directly exchanges data with the processor. It can read and write data at any time and at a very high speed. It serves as a temporary data storage for the operating system or other running programs. The memory includes at least two types of memories. For example, the memory can be a random access memory, such as DRAM, or SCM, or a read-only memory (ROM). In actual applications, multiple memories 1213 and different types of memories 1213 can be configured in the controller. This embodiment does not limit the number and type of memory 1213. In addition, the memory 1213 can be configured to have a power-saving function. The power-saving function means that when the system loses power and then powers on again, the data stored in the memory 1213 will not be lost. A memory with a power-saving function is called a non-volatile memory.

[0122] The memory 1213 stores software programs, and the processor 1212 runs the software programs in the memory 1213 to manage the memory 620 .

[0123] In addition, FIG. 7 shows only one engine 121 . However, in actual applications, the storage system may include two or more engines 121 , and redundancy or load balancing may be performed between the multiple engines 121 .

[0124] Audio module 670 is used to convert digital audio information into analog audio signal output, and also to convert analog audio input into digital audio signals. Buttons 690 include a power button, volume button, etc. Buttons 690 can be mechanical buttons or touch buttons.

[0125] Motor 691 can generate vibration prompts.

[0126] Indicator 692 can be an indicator light, which can be used to indicate charging status, power changes, messages, missed calls, notifications, etc.

[0127] The SIM card interface 695 is used to connect a SIM card.

[0128] For example, the above only uses a mobile phone as an example to illustrate the structure of the device 600 in the embodiment of the present application, but does not constitute a limitation on the structure and form of the device 600. The embodiment of the present application does not limit the structure and form of the device 600. For example, Figure 8 shows another exemplary structure of the device 600. As shown in Figure 8, the device 600 includes: a processor 801, a memory 802, and a transceiver 803. The implementation of the processor 801 and the memory 802 can refer to the implementation of the processor and storage device shown in Figure 6. The transceiver 803 can be used for the device 600 to interact with other devices (such as electronic devices). The transceiver 803 can be based on devices such as Wi-Fi, Bluetooth or other communication protocols.

[0129] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on device 600. In other embodiments of the present application, device 600 may include more or fewer components than those shown in Figures 6 and 8, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0130] In some embodiments, the software architecture of the device 600 may adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture, or a cloud architecture. This embodiment of the application takes a layered architecture as an example to illustrate the software structure of the device 600.

[0131] FIG9 shows a software structure block diagram of a device 600 provided in an embodiment of the present application.

[0132] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other via software interfaces. In some embodiments, the software structure of device 600 may include three layers: storage device layer, file system layer, and business software layer, from bottom to top.

[0133] In some embodiments, the storage device can be divided into different partitions, each of which can be used to store different data. Exemplarily, these partitions can include a system partition and a user data partition. For an introduction to the system partition and the user data partition, please refer to the above description.

[0134] In some embodiments of the present application, part of the system partition may be set in front of the user data partition, and part of the system partition may be set behind the user data partition (not shown in the figure).

[0135] In some embodiments, the storage device may include a partition table that can be used to record information related to each partition. Optionally, the partition table can be stored in the header of the storage device. Currently, the partition table can also be stored in other locations of the storage device, and this embodiment of the application is not limited to this.

[0136] The file system layer can be used to manage files on the storage device. In some embodiments, the file system layer can include one or more file systems, such as file system 1, file system 2, etc. In some embodiments, different partitions can correspond to different file systems, and each file system can manage the data in the corresponding partition.

[0137] In some embodiments, the file system corresponding to the user data partition (e.g., file system 2) may include a data migration module that can move data stored later in the user data partition to free space earlier in the user data partition. For example, the data migration module can store data stored later in the user data partition at an earlier location in the user data partition by determining the storage address of the data.

[0138] As a specific implementation, the data migration module can migrate data in the user data partition based on the garbage collection (GC) function included in the log-structured feature of the file system. The GC function can be used to reclaim free space (such as invalid blocks) in the user data partition. The data migration module can perform targeted migration of data stored in the user data partition based on the GC function, such as moving data stored at the end of the user data partition to the free space (such as invalid blocks) at the front of the user data partition. Furthermore, when the free space in the user data partition is reclaimed, the space at the end of the user data partition can also be freed up.

[0139] In some embodiments, the data migration module may also be used to modify the address range of the user data partition managed by the file system, thereby achieving the purpose of modifying the size of the user data partition.

[0140] It will be appreciated that the above embodiment uses the example of a data migration module located in the file system corresponding to the user data partition. In other embodiments, the data migration module may also be located directly in the file system layer, and the present embodiment does not limit the specific location of the data migration module. In other embodiments, the data migration module may also be referred to as a garbage collection (GC) module. It will be appreciated that the name does not constitute a limitation on the function.

[0141] For example, FIG10 shows a schematic diagram of a scenario for moving data in a user data partition provided by an embodiment of the present application. As shown in FIG10 (1), the data migration module can move data 1, data 2, data 3, etc. to the locations of area 1, area 2, and area 3 of the user data partition respectively. In response to the movement operation, the data storage status of the user data partition can be shown as shown in FIG10 (2).

[0142] Optionally, after the data migration module migrates the data in the user data partition, the data in the user data partition may be stored continuously or not continuously.

[0143] Furthermore, the data migration module can also modify the address management range of the file system corresponding to the user data partition. For example, if the address management range of the file system corresponding to the user data partition shown in (1) of Figure 10 is from address a to address c, if the data migration module deletes address b to address c from the address management range of the file system, the address management range of the file system becomes from address a to address b. Accordingly, the size of the user data partition becomes the size shown in (3) of Figure 10.

[0144] The business software layer may include various types of business software. For example, these business software may include but are not limited to system software and application software. For example, system software may include but are not limited to pre-installed applications, executable programs, system services, etc. of the device 600. Among them, pre-installed applications may refer to applications that have been installed on the device 600 before leaving the factory. Application software may refer to software and programs installed by the user in the process of using the device 600 after the device 600 leaves the factory, as well as data generated in the process of using the system software, etc. For example, application software includes but is not limited to third-party applications, executable programs, user data (such as phone books, text messages, videos, photos, messages), etc.

[0145] In some embodiments, data of different types of business software can be stored in different partitions. For example, data of system software can be stored in the system partition, and data of application software can be stored in the user data partition.

[0146] In some embodiments of the present application, when updating system software at the service software layer, if it is determined that the space in the system partition on the storage device used to store the system software data is insufficient to store the updated system software data, the system partition size can be expanded by modifying parameters of the system partition stored in the partition table on the storage device, such as the size, start address, and end address. Furthermore, data in the user data partition can be moved using a data migration module at the file system layer to allocate free space in the user data partition to the previously insufficient system partition, thereby expanding the system partition size.

[0147] It will be understood that the architecture shown in FIG9 is merely illustrative and serves only as a logical architecture. In actual implementation, the architecture may be divided in other ways, such as including more or fewer layers. The system architecture of device 600 may also be divided into functional modules, with each functional module being divided for each function. Two or more functions may also be integrated into a single processing unit. This integrated unit may be implemented in the form of hardware or software functional modules.

[0148] The technical solutions involved in the following embodiments can all be implemented in devices having structures as shown in Figures 6, 8, 9, etc.

[0149] It is understood that in the following embodiments, device 600 is a mobile phone and storage device 620 is a storage device. It is also understood that the execution subject of the partition management method provided in the embodiment of the present application can be a mobile phone or a processor in the mobile phone, such as a chip.

[0150] This embodiment of the present application provides a partition management method that relocates part of the system partition located at the head of a storage device to the tail of the storage device. This allows the size of the system partition to be expanded. If the system software stored in the system partition is updated, the size of the system partition can be adjusted to accommodate the updated system software, thereby increasing the probability of a successful system software update.

[0151] In some embodiments, some or all of the first-type system partitions located at the front of the storage device can be placed at the end of the storage device. The second-type system partitions located at the front of the storage device can still be placed at the head of the storage device. Optionally, the number of first-type system partitions and the number of second-type system partitions can both be one or more.

[0152] The first type of system partition may be a partition used for mobile phone operation, such as, but not limited to, an NV partition, a MODEM partition, a KERNEL partition, a SYSTEM partition, a VENDOR partition, and a PRODUCT partition. It is understood that the data in the first type of system partition is data required to be loaded during mobile phone operation. Placing the first type of system partition at the end of the storage device will not affect the startup of the mobile phone.

[0153] The second type of system partition can be a partition used to start the mobile phone, complete power-on, and complete operations such as partition table parsing, such as including but not limited to XLOADER partitions, FASTBOOT partitions, etc. Among them, the XLOADER partition can be located at the starting address of the storage device (such as address 0). The XLOADER partition can be used to perform some initialization operations on the storage device, such as parsing the partition table to obtain the address of the FASTBOOT partition, and then loading and starting the FASTBOOT partition, and the FASTBOOT partition completes the subsequent startup process of the mobile phone. Of course, the addresses of other partitions on the storage device can also be obtained by parsing the partition table. It can be understood that the data in the second type of system partition is the data that needs to be loaded when the mobile phone starts. Since the location of each partition on the storage device cannot be determined when the mobile phone starts, data will be loaded and executed starting from the head of the storage device. In this way, setting the second type of system partition at the head of the storage device can facilitate loading data when the mobile phone starts to complete the successful startup of the mobile phone, such as the power-on process. And by loading the second type of system partition and parsing the partition table, the addresses of other partitions on the storage device can be obtained, so that the data of each partition can be loaded when the mobile phone is running.

[0154] In a specific embodiment, part or all of the first type system partition may be set at the end of the storage device. It is understood that setting at the end of the storage device may mean that the end address of the storage device is the end address of a first type system partition.

[0155] For example, taking the case where the first type of system partition includes an NV partition, a MODEM partition, a KERNEL partition, a SYSTEM partition, a VENDOR partition, and a PRODUCT partition, and the second type of system partition includes a FASTBOOT partition, FIG11 (1) shows a schematic diagram of the structure of a storage device partition provided by an embodiment of the present application. As shown in FIG11 (1), the FASTBOOT partition, the NV partition, the MODEM partition, and the KERNEL partition are set at the head of the storage device, and the SYSTEM partition, the VENDOR partition, and the PRODUCT partition are set at the very end of the storage device, wherein the end address of the PRODUCT partition is the end address of the storage device.

[0156] In another specific embodiment, part or all of the first type of system partition can be specifically set at a location that is a preset size away from the end of the storage device. It is understood that setting it at a location that is a preset size away from the end of the storage device can mean that the location is a preset size away from the end address of the storage device, which is the end address of a first type of system partition. Optionally, the preset size can be set by the developer based on actual needs, and this embodiment of the application is not limited to this.

[0157] For example, taking the example that the first type of system partition includes an NV partition, a MODEM partition, a KERNEL partition, a SYSTEM partition, a VENDOR partition, and a PRODUCT partition, and the second type of system partition includes a FASTBOOT partition, FIG11 (2) shows a schematic diagram of the structure of another storage device partition provided by an embodiment of the present application. As shown in FIG11 (2), the FASTBOOT partition, the NV partition, the MODEM partition, and the KERNEL partition are set at the head of the storage device, and the SYSTEM partition, the VENDOR partition, and the PRODUCT partition are set at a position that is a preset size away from the end of the storage device, wherein the end address of the PRODUCT partition is a position that is a preset size away from the end address of the storage device.

[0158] In some scenarios, a mobile phone uses a partition structure such as that shown in FIG11 before leaving the factory.

[0159] In this scenario, in some embodiments, the size of each system partition can be preset. In other embodiments, the size of each system partition can be determined based on the growth of the data stored in the system partition. For example, if the data stored in a system partition grows significantly and / or the data grows more frequently, the system partition can be set to a larger size. If the storage device of a system partition grows less and / or the data grows less frequently, the system partition can be set to a smaller size.

[0160] In other scenarios, before leaving the factory, the mobile phone adopts a partition structure such as that shown in FIG3 . In this scenario, in order to make the size of the system partition meet the needs of the updated system software and improve the probability of successful system software update, the mobile phone can convert the partition structure such as that shown in FIG3 into a partition structure such as that shown in FIG11 . For example, the mobile phone can set the part of the system partition located on the storage device to the tail of the storage device by modifying the index of the system partition and the user data partition in the partition table, such as the starting address, end address, and partition size of the partition. In some embodiments, after modifying the index of the user data partition, it is also necessary to modify the address management range of the file system corresponding to the user data partition, so that the address range managed by the file system corresponding to the user data partition is the address range of the modified user data partition.

[0161] It is understandable that in this scenario, for the system partitions still set at the head of the storage device, the positions of some system partitions may not change, while the positions of some system partitions may change. For example, after converting the partition structure shown in FIG3 to the partition structure shown in FIG11 (1), the positions of the KERNEL partition and the MODEM partition may change, such as the starting address of the KERNEL partition and the ending address of the MODEM partition, while the positions of the FASTBOOT partition and the NV partition may not change.

[0162] Optionally, the positions of the system partitions still set at the head of the storage device may also be changed. Optionally, whether the position of a system partition still set at the head of the storage device is changed can be determined based on the growth of the data of the storage device in the system partition and / or the growth of the data in other system partitions still stored at the head of the storage device. For example, if the data stored in a system partition grows more and / or the data grows more frequently, the system partition can be expanded and the other system partitions can be reduced. If the data of the storage device in a system partition grows less and / or the data grows less frequently, the system partition can be reduced and the other system partitions can be expanded, etc.

[0163] In some embodiments, the system partition may have insufficient space due to reasons such as the system software stored in the system partition may be updated from time to time, and the size of the system partition may not be sufficient to store the updated system software. Therefore, in this scenario, before converting a partition structure such as that shown in FIG3 to a partition structure such as that shown in FIG11 , the mobile phone may first determine whether the space of several system partitions set at the head of the storage device is insufficient. If it is determined that the space of some or all system partitions is insufficient, the aforementioned conversion operation may be performed. Conversely, if it is determined that the space of all system partitions is sufficient, the mobile phone may not perform the aforementioned conversion operation. In this way, the system overhead of the mobile phone can be saved while increasing the probability of successful system software upgrade.

[0164] Optionally, in this embodiment, the mobile phone can relocate the system partition that is not experiencing insufficient space to the end of the storage device, while retaining the system partition that is experiencing insufficient space at the beginning of the storage device. This allows for more free space at the beginning of the storage device to be reallocated to the insufficient system partition, thereby expanding the insufficient system partition.

[0165] In this embodiment, in conjunction with the partition structure shown in (1) of FIG3 , taking the system partitions with insufficient space as the SYSTEM partition and the VENDOR partition as an example, the mobile phone can set one or more other system partitions with sufficient space at the end of the storage device. As shown in FIG12a , the mobile phone can set the PRODUCT partition shown in (1) of FIG12a at the end of the storage device, and at the same time allocate the free space at the head of the storage device to the SYSTEM partition, the VENDOR partition, etc., as shown in the partition structure shown in (2) of FIG12a .

[0166] In conjunction with the partition structure shown in (1) of Figure 12b, taking the system partitions with insufficient space as SYSTEM partitions and PRODUCT partitions as an example, the mobile phone can set one or more other system partitions with sufficient space at the end of the storage device. For example, the mobile phone can set the PRELOAD partition shown in (1) of Figure 12b at the end of the storage device, and at the same time allocate the free space at the head of the storage device to the SYSTEM partition, PRODUCT partition, etc., as shown in the partition structure shown in (2) of Figure 12b. For the functional introduction of each partition in Figure 12b, please refer to the introduction in the relevant technology, which will not be repeated in this article.

[0167] In some embodiments, one or more system partitions located after the system partition where insufficient space occurs can be set at the end of the storage device. In this way, the modification of the addresses of the system partitions set at the head of the storage device can be reduced, saving the system overhead of the mobile phone. As shown in the example (2) in Figure 12a, only the end address of the SYSTEM partition and the start and end addresses of the VENDOR partition are modified, and the addresses of other system partitions still set at the head of the storage device, such as the FASTBOOT partition, NV partition, MODEM partition, KERNEL partition, etc., do not need to be modified.

[0168] Optionally, the position of the system partition that is still set at the head of the storage device but does not have insufficient space can be changed or not changed. (2) in Figure 12a is an example of no change, and (2) in Figure 12b is an example of change. This application does not limit this.

[0169] In other embodiments, one or more system partitions preceding the system partition experiencing insufficient space may be placed at the end of the storage device.

[0170] In some scenarios, since the tail of the storage device is occupied by the user data partition, the system partition is set at the tail of the storage device, that is, part of the space of the user data partition is reallocated to the system partition. As shown in (3) in Figure 12a, part of the space of the user data partition needs to be allocated to the PRODUCT partition. As shown in (3) in Figure 12b, part of the space of the user data partition needs to be allocated to the PRELOAD partition.

[0171] In a specific embodiment, the tail free space of the user data partition may be allocated to the system partition located at the tail of the storage device.

[0172] In some scenarios, data may be stored at the rear of the user data partition, such as when the continuous free space behind the user data partition is smaller than the required space for the system partition to be located at the rear of the storage device. It will be appreciated that the required space for the system partition can be the actual size of the system partition, or it can be larger or smaller than the actual size of the system partition. In this case, the data at the rear of the user data partition can be moved to the front of the free space in the user data partition. For example, a mobile phone can implement this operation using the data migration module described above. This facilitates reallocating part of the space in the user data partition to the system partition located at the rear of the storage device.

[0173] This way, the starting address of the user data partition remains unchanged; only the ending address of the user data partition and the storage address of the moved data need to be modified. This eliminates the need to adjust the addresses of the entire user data partition and all data stored in it. This reduces the time and system overhead of expanding the system partition while also minimizing the risks associated with modifying the storage address of data in the user data partition.

[0174] In some embodiments, the location, size, etc. of the system partition and / or user data partition can be adjusted by modifying the corresponding parameters of the system partition and / or user data partition in the partition table. For example, the parameters in the partition table may include, but are not limited to, one or more of the size, start address, and end address of the system partition, and the size and end address of the user data partition.

[0175] In some embodiments, the starting address of a system partition located at the end of a storage device can be determined based on the size of the storage device, the space required for the system partition, a preset size, or the starting address, ending address, or space required for other system partitions located at the end of the storage device. The size of a user data partition can be determined based on the starting address of the user data partition, the space required for the system partition located at the end of the storage device, a preset size, or the like.

[0176] As a possible implementation, taking the case where a system partition is set at the end of a storage device as an example, the starting address of the system partition set at the end of the storage device can satisfy Formula 1, and the size of the user data partition can satisfy Formula 2. System partition starting address = storage device size - space required for system partition Formula 1 User data partition size = system partition starting address - user data partition starting address Formula 2

[0177] In Formula 1, the "starting address of the system partition" is the starting address of the system partition located at the end of the storage device. In Formula 2, the "starting address of the system partition" is the "starting address of the system partition" obtained according to Formula 1. Optionally, Formula 2 can also be transformed into Formula 2.1. User data partition size = user data partition starting address - system partition space required Formula 2.1

[0178] For the introduction of each parameter in Formula 2.1, please refer to the introduction of the corresponding parameters in Formula 1 and Formula 2.

[0179] As another possible implementation, multiple system partitions may be set at the end of the storage device. In this case, the starting address of the system partition set at the end of the storage device and adjacent to the user data partition can satisfy Formula 3, and the size of the user data partition can satisfy Formula 4. The starting address of system partition 1 = storage device size - the space required for all subsequent system partitions. Formula 3 The size of the user data partition = the starting address of system partition 1 - the starting address of the user data partition. Formula 4

[0180] Among them, in Formula 3, "the starting address of system partition 1" is the starting address of the system partition set at the tail position of the storage device (that is, behind the user data partition) and adjacent to the user data partition, and "the space required for all rear system partitions" is the required space size of all system partitions set at the tail position of the storage device. In Formula 4, "the starting address of system partition 1" is the "starting address of system partition 1" obtained according to Formula 3. Optionally, similar to the way Formula 2 is transformed into Formula 2.1, Formula 4 can also be transformed into Formula 4.1. The size of the user data partition = the starting address of the user data partition - the space required for all rear system partitions Formula 4.1

[0181] For the introduction of each parameter in Formula 4.1, please refer to the introduction of the corresponding parameters in Formula 3 and Formula 4.

[0182] It can be understood that in this implementation, the starting address, ending address, etc. of the system partition stored at the tail position of the storage device and not adjacent to the user data partition can also be determined based on the size of the storage device, the preset size, and the size, starting address, ending address, etc. of other system partitions located at the tail position of the storage device.

[0183] It can be understood that the above implementation is based on the example of setting the rear system partition at the end of the storage device. If the rear system partition is set at a preset distance from the end of the storage device, the above formula 1 can be transformed into formula 5. The starting address of the system partition = the size of the storage device - the space required by the system partition - the preset size Formula 5

[0184] For the description of each parameter in Formula 5, refer to the description of the corresponding parameters in Formula 1. Accordingly, the "system partition starting address" in Formula 2 can be determined based on Formula 5. Alternatively, the "system partition required space" in Formula 2.1 can be replaced with the sum of the "system partition required space" and the "preset size" in Formula 5.

[0185] Similarly, the above formula 3 can also be transformed into formula 6. The starting address of system partition 1 = storage device size - the space required by all rear system partitions - the preset size Formula 6

[0186] For the description of each parameter in Formula 6, refer to the description of the corresponding parameters in Formula 3. Accordingly, the "starting address of system partition 1" in Formula 4 can be determined based on Formula 6. Alternatively, the "required space size of all rear system partitions" in Formula 4.1 can be replaced by the sum of the "required space size of all rear system partitions" and the "preset size" in Formula 6.

[0187] As shown in the partition structure shown in (2) of Figure 12a and the above formulas 1 and 2, the starting address of the PRODUCT partition can satisfy formula 7, and the size of the user data partition can satisfy formula 8. The starting address of the PRODUCT partition = the size of the storage device - the space required for the PRODUCT partition Formula 7 The size of the user data partition = the starting address of the PRODUCT partition - the starting address of the user data partition Formula 8

[0188] It can be understood that Formula 7 and Formula 8 are based on the example of the PRODUCT partition being set at the end of the storage device. If the PRODUCT partition is set at a preset distance from the end of the storage device, then combined with Formula 5 above, the starting address of the PRODUCT partition can satisfy Formula 9. The starting address of the PRODUCT partition = the size of the storage device - the space required by the PRODUCT partition - the preset size Formula 9

[0189] Accordingly, in Formula 8, the starting address of the PRODUCT partition can be determined according to Formula 9, and then the size of the user data partition can be determined according to Formula 8.

[0190] Similarly, combining the partition structure shown in (2) of Figure 12b and the above formulas 1 and 2, the starting address of the PRELOAD partition can satisfy formula 10, and the size of the user data partition can satisfy formula 11. The starting address of the PRELOAD partition = the size of the storage device - the space required for the PRELOAD partition Formula 10 The size of the user data partition = the starting address of the PRELOAD partition - the starting address of the user data partition Formula 11

[0191] It can be understood that Formulas 10 and 11 are also based on the example of setting the PRELOAD partition at the end of the storage device. If the PRELOAD partition is set at a position a preset distance away from the end of the storage device, the starting address of the PRELOAD partition and the size of the user data partition can refer to the relevant implementation of the PRODUCT partition described in Formula 9 and other embodiments.

[0192] It will be appreciated that this embodiment uses the example of data stored at the rear end of the user data partition. In other embodiments, if data is not stored at the rear end of the user data partition, for example, if the continuous free space at the rear end of the user data partition is greater than or equal to the required size of the system partition to be stored at the end of the storage device, the mobile phone may not adjust the location of the data stored in the user data partition. This can reduce system overhead and further mitigate the risks associated with modifying the storage address of data in the user data partition.

[0193] In other embodiments, the system partition experiencing insufficient space may be adjusted to the end of the storage device, while the system partition experiencing insufficient space may be retained at the beginning of the storage device. This is not limited in the present embodiment. For a specific implementation of this embodiment, reference may be made to the aforementioned implementation of adjusting the system partition experiencing insufficient space to the end of the storage device while retaining the system partition experiencing insufficient space at the beginning of the storage device.

[0194] In some embodiments, after the partition structure of the mobile phone has been changed to the partition structure shown in FIG11, FIG12a (2), FIG12b (2), etc., the space of the system partition located at the head of the storage device may still be insufficient due to reasons such as the system software stored in the system partition being updated from time to time and the size of the system partition being insufficient to store the updated system software. In this case, a method such as that described above can be further adopted, such as: the system partition that does not have insufficient space can be adjusted to the tail position of the storage device, and the system partition that has insufficient space can still be retained at the head position of the storage device. Alternatively, the system partition that has insufficient space can be adjusted to the tail position of the storage device, and the system partition that does not have insufficient space can still be retained at the head position of the storage device, etc., to achieve the purpose of expanding the space of the system partition.

[0195] In some embodiments, after the partition structure of the mobile phone has been changed to the partition structure shown in Figure 11, Figure 12a (2), Figure 12b (2), etc., the space of the system partition located at the end of the storage device may also be insufficient due to the fact that the system software stored in the system partition is updated from time to time and the size of the system partition may not be sufficient to store the updated system software.

[0196] In this embodiment, as a possible implementation, the free space at the end of the user data partition can also be allocated to the system partition at the end of the storage device that is experiencing insufficient space. Similarly, data may also be stored at the end of the user data partition. For example, if the continuous free space at the end of the user data partition is smaller than the amount of space to be expanded in the system partition experiencing insufficient space, the amount of space to be expanded can optionally be greater than or equal to the amount of space missing from the system partition experiencing insufficient space.

[0197] At this point, the mobile phone can use the method described above to move the data at the end of the user data partition to the free space at the front of the user data partition. This facilitates reallocating part of the space in the user data partition to the system partition at the end of the storage device that is experiencing insufficient space. Optionally, the free space allocated from the user data partition can also be reallocated to the system partition at the end of the storage device that is not experiencing insufficient space. This embodiment of the present application is not limited to this.

[0198] For example, in combination with the partition structure shown in (2) in FIG12a, taking the system partition with insufficient space as the PRODUCT partition as an example, after the mobile phone reallocates part of the space of the user data partition to the PRODUCT partition, the partition structure of the storage device can be as shown in (3) in FIG12a.

[0199] Similarly, in combination with the partition structure shown in (2) in Figure 12b, taking the system partition with insufficient space as the PRELOAD partition as an example, after the mobile phone reallocates part of the space of the user data partition to the PRELOAD partition, the partition structure of the storage device can be as shown in (3) in Figure 12b.

[0200] Similarly, in this embodiment, the mobile phone can also adjust the position, size, etc. of the system partition and / or user data partition by modifying the corresponding parameters of the system partition and / or user data partition in the partition table. Please refer to the above description for the parameters in the partition table.

[0201] In some scenarios, for a system partition located at the end of a storage device that is experiencing insufficient space, reallocating part of the user data partition's space to the system partition may cause one or more of the system partition's start address, end address, and size to change. For other system partitions located at the end of a storage device that are not experiencing insufficient space, one or more of the start address, end address, and size may or may not change.

[0202] For other implementations of this embodiment, reference may be made to the relevant implementations of the embodiment described above.

[0203] In some other embodiments, after the partition structure of the mobile phone has been changed to the partition structure shown in Figure 11, Figure 12a (2), Figure 12b (2), etc., if the space of the system partition located at the end of the storage device is insufficient, and / or the space of the system partition located at the head of the storage device is insufficient, the virtual volume technology described above can also be used to use the free space of other system partitions as the free space of the insufficient system partition. Alternatively, the space of the other system partition can be reduced by modifying the address of the other system partition, and the space of the other system partition can be allocated to the insufficient system partition for use. Optionally, the other system partition can be the system partition located at the head of the storage device or the system partition located at the end of the storage device.

[0204] In some scenarios, storage devices may have different versions, such as a high-configuration version and a low-configuration version. The sizes of storage devices of different versions may be different. In some embodiments, multiple storage devices of different versions may correspond to one partition table. Alternatively, all storage devices of different versions may correspond to one partition table.

[0205] For example, taking a storage device including four versions as an example, a storage device of version 1 and a storage device of version 2 correspond to partition table 1. Partition table 1 may be a partition table adapted for storage devices of version 1, version 2, or other versions. It can be understood that a partition table adapted for a storage device may mean that the partition table is designed based on the actual size of the storage device. A storage device of version 3 and a storage device of version 4 correspond to partition table 2. Partition table 2 may be a partition table adapted for storage devices of version 3, version 4, or other versions. Partition table 1 and partition table 2 may be designed based on the actual sizes of storage devices of different versions.

[0206] For another example, taking a storage device including four versions, the storage device of version 1, the storage device of version 2, the storage device of version 3, and the storage device of version 4 all correspond to partition table 3. Partition table 3 can be designed based on the actual size of any storage device of version 1 to version 4.

[0207] In this embodiment, after the mobile phone obtains the partition table, it saves the partition table to the storage device and then reads and writes to the storage device based on the partition table. Because the partition table obtained by the mobile phone may not be compatible with the current version of the storage device, that is, the partition table is not designed based on the actual size of the current version of the storage device, the mobile phone can also calibrate the obtained partition table to ensure that the partition table saved to the storage device is compatible with the storage device.

[0208] In the embodiments of the present application, the starting address of the user data partition remains unchanged across different versions of the storage device. This reduces the probability of data loss within the user data partition and improves the reliability of the storage device. Therefore, in a specific embodiment, the mobile phone does not need to recalculate the starting address of the user data partition when calibrating the partition table, thereby reducing system overhead.

[0209] For example, before a mobile phone leaves the factory, it uses a partition structure such as that shown in FIG11, FIG12a (2), FIG12b (2), and FIG13 (1). It can be understood that FIG12b (2), FIG13 (1), etc. are based on the example of storing the partition table in the head of the storage device. Since the starting address of the user data partition of different versions of storage devices is unchanged, the starting address and ending address of the system partition before the user data partition will not change for different versions of storage devices, while the size of the user data partition and the starting address and ending address of the system partition after the user data partition may change.

[0210] In some embodiments, similar to the method for determining the starting address of the system partition set at the tail position of the storage device and the size of the user data partition described in Formulas 1 to 6 above, the mobile phone can determine one or more of the starting address, ending address, and size of the user data partition of the system partition set at the tail position of the storage device based on the size of the current storage device, the preset size, etc.

[0211] As a possible implementation, taking the case where a system partition is set at the end of a storage device as an example, the starting address of the system partition set at the end of the storage device can satisfy Formula 12, and the size of the user data partition can satisfy Formula 13. System partition starting address = storage device size - system partition size Formula 12 User data partition size = system partition starting address - user data partition starting address Formula 13

[0212] In Formula 12, "system partition start address" is the start address of the system partition located at the end of the storage device. "System partition size" is the actual size of the system partition. In Formula 13, "system partition start address" is the "system partition start address" obtained according to Formula 12. Optionally, Formula 13 may also employ variations such as those shown in Formula 2.1 above.

[0213] As another possible implementation, multiple system partitions may be set at the end of the storage device. In this case, the starting address of the system partition set at the end of the storage device and adjacent to the user data partition can satisfy Formula 14, and the size of the user data partition can satisfy Formula 15. The starting address of system partition 1 = storage device size - the size of all subsequent system partitions (Formula 14). The size of the user data partition = the starting address of system partition 1 - the starting address of the user data partition (Formula 15).

[0214] In Formula 14, "Starting address of system partition 1" is the starting address of the system partition located at the end of the storage device and adjacent to the user data partition, and "Total size of all subsequent system partitions" is the total size of all system partitions located at the end of the storage device. In Formula 15, "Starting address of system partition 1" is the "Starting address of system partition 1" obtained according to Formula 14. Optionally, Formula 15 may also employ variations such as those shown in Formula 4.1 above.

[0215] It will be appreciated that the above implementation is based on the example of a rear-mounted system partition being located at the very end of a storage device. Similarly, if the rear-mounted system partition is located at the very end of a storage device at a predetermined size, then Formulas 12 through 15 can also be expressed using variations such as Formulas 5 and 6 described above.

[0216] As shown in the partition structure described in (1) of Figure 13, assuming that the partition table obtained by the mobile phone is as shown in (2) of Figure 13, the end address of the user data partition is "H". The starting address of the PRODUCT partition is "H" and the end address is "I". At this time, combined with the above formulas 12 and 13, the starting address of the PRODUCT partition can satisfy formula 16, and the size of the user data partition can satisfy formula 17. The starting address of the PRODUCT partition = the storage device size - the size of the PRODUCT partition Formula 16 The size of the user data partition = the starting address of the PRODUCT partition - the starting address of the user data partition Formula 17

[0217] If the starting address of the PRODUCT partition is calculated as "M" according to Formula 16, the size of the user data partition is "MF", and the tail address of the storage device is changed from "I" to "L", then the partition table shown in (2) of Figure 13 can be updated to the partition table shown in (3) of Figure 13. It can be understood that because the sizes of storage devices of different versions may be different, under the same address rule, the tail address of the storage device is determined based on the actual size of the storage device.

[0218] On the contrary, if the starting address and ending address of the PRODUCT partition determined according to Formula 16 and Formula 17, and the size of the user data partition have not changed, then the partition table shown in (2) in Figure 13 may not be updated.

[0219] In other embodiments, different versions of storage devices may correspond to different partition tables. For example, there may be a one-to-one correspondence between different versions of storage devices and partition tables. In this way, the mobile phone can skip the aforementioned partition table calibration operation and directly store the partition table in the storage device. This can reduce system overhead.

[0220] For example, FIG14 shows a flow chart of a method for updating a partition table provided in an embodiment of the present application. As shown in FIG14 , the method includes the following steps:

[0221] S1401. The mobile phone obtains a partition table.

[0222] S1402. The mobile phone updates the partition table according to the actual size of the storage device.

[0223] For the specific implementation of this step, please refer to the relevant implementation described above.

[0224] S1403. The mobile phone stores the partition table in the storage device.

[0225] In some embodiments, in step S1403, if the partition table obtained by the mobile phone is compatible with the storage device, the partition table may be an unupdated partition table. In other embodiments, if the partition table obtained by the mobile phone is not compatible with the storage device, the partition table may be an updated partition table.

[0226] Optionally, in an embodiment of the present application, the partition table can be stored in the head of the storage device.

[0227] In the following, in conjunction with the scenario where the partition structure shown in (1) of FIG. 12b is converted to the partition structure shown in (2) of FIG. 12b , taking the case where the partition table obtained by the mobile phone is incompatible with the storage device as an example, FIG. 15 shows a flow chart of a partition management method provided by an embodiment of the present application. As shown in FIG. 15 , the method includes the following steps:

[0228] S1501. The mobile phone updates the obtained partition table.

[0229] For the specific implementation of this step, please refer to the relevant implementation described in Figure 14.

[0230] Optionally, the mobile phone may first store the partition table in a storage device and then update it, or may first update the partition table and then store the updated partition table in a storage device.

[0231] S1502: The mobile phone obtains the size of the PRELOAD partition.

[0232] If the mobile phone determines to place the PRELOAD partition at the position shown in (1) of FIG. 12b at the position shown in (2) of FIG. 12b , the mobile phone can execute step S1502 , and the size of the PRELOAD partition can be the size of the PRELOAD partition shown in (1) of FIG. 12b . In other words, when the mobile phone determines to place a system partition that is located before the user data partition after the user data partition, the mobile phone can obtain the size of the system partition.

[0233] Optionally, in step S1502, the size of the PRELOAD partition may be the actual size of the PRELOAD partition, or may be the space size required by the PRELOAD partition.

[0234] S1503. The mobile phone shrinks the user data partition to a specified size.

[0235] The specified size may be the space required by the PRELOAD partition. Optionally, the space required by the PRELOAD partition may be the same as, or larger or smaller than, the actual size of the PRELOAD partition.

[0236] For example, the mobile phone may reduce the user data partition as shown in (1) in FIG12b to the specified size.

[0237] S1504: The mobile phone calibrates the size of the user data partition and the starting address of the PRELOAD partition.

[0238] Optionally, in step S1504, the mobile phone may calibrate the size of the user data partition and the starting address of the PRELOAD partition using a method such as Formulas 1 to 6 described above. For example, after calibration, the size of the user data partition is updated from the size shown in (1) in FIG. 12b to the size shown in (2) in FIG. 12b . The starting address of the PRELOAD partition is updated from the starting address shown in (1) in FIG. 12b to the starting address shown in (2) in FIG. 12b .

[0239] S1505: The mobile phone updates one or more of the starting address, ending address, size, etc. of the user data partition and the PRELOAD partition.

[0240] For example, the mobile phone may update one or more of the start address, end address, size, etc. of the user data partition and the PRELOAD partition stored in the partition table according to the calibrated size of the user data partition and the start address of the PRELOAD partition.

[0241] S1506. Flash the partition table of the mobile phone.

[0242] The mobile phone flashes the partition table, that is, updates the partition table stored in the storage device. Optionally, the mobile phone can also update one or more of the start address, end address, size, etc. of one or more other system partitions (such as the SYSTEM partition, PRODUCT partition, etc. shown in (1) of Figure 12b) by flashing the partition table.

[0243] For example, FIG16 shows a flow chart of a partition management method provided by an embodiment of the present application. The execution subject of the method can be the device 600 described above, or a processor in the device 600, such as a chip. As shown in FIG16 , the method includes the following steps:

[0244] S1601. Get a request message.

[0245] The request message may be used to read and write partitions included in the storage device, including a user data partition and multiple system partitions. The system partition is used to store a first type of data. For example, the first type of data may include, but is not limited to, data such as the system software described above. The user data partition is used to store a second type of data. For example, the second type of data may include, but is not limited to, data generated by a user during use of the storage device as described above.

[0246] The system partition includes a first system partition and a second system partition. The first system partition is set in front of the user data partition, and the second system partition is set behind the user data partition. Optionally, the data stored in the first system partition and the second system partition can be different. Optionally, the system partition can also include one or more system partitions other than the first system partition and the second system partition. For example, the partition structure is shown in (2) in Figure 12a.

[0247] In some embodiments, before executing step S1401, the first system partition and the second system partition are both set in front of the user data partition, as shown in the partition architecture (1) in Figure 12a. Optionally, in this embodiment, other system partitions may be set behind the user data partition. In this case, the second system partition may be set behind the user data partition. For example, if the space of the first system partition is insufficient, part or all of the space of the second system partition set in front of the user data partition may be merged into the space of the first system partition, and the second system partition may be set behind the user data partition.

[0248] It is understood that the space of the merged first system partition is larger than the space of the original first system partition. In some embodiments, the merge operation can be performed based on the space missing from the first system partition to determine the specific amount of space from the second system partition to be merged into the first system partition. Optionally, the space of the original first system partition can also be divided into other system partitions.

[0249] In a specific embodiment, the second system partition is set after the user data partition, and the starting address of the user data partition remains unchanged. Setting the second system partition after the user data partition can be specifically implemented as follows: the first space of the user data partition is set as the second system partition, and the first space includes the continuous free space at the end of the user data partition, as shown in the partition structure (2) in Figure 12a. Optionally, the first space can be larger than or equal to the second system partition. In this way, it can be ensured that there is sufficient space to store the data in the second system partition.

[0250] In some embodiments, before setting the first space of the user data partition as the second system partition, if user data is stored in the first space, the user data is moved to the second space of the user data partition for storage. The second space is different from the first space and is free space in the user data partition. For example, the second space can be located before the first space. Optionally, the second space can be continuous free space or non-contiguous free space.

[0251] In some embodiments, the first space of the user data partition can be set as the second system partition by updating the size of the user data partition and the start and end addresses of the second system partition included in the partition table. For details on this implementation, please refer to the relevant implementation described above. The partition table corresponds to the storage device, that is, the partition table is a partition table adapted for the storage device and is used to index the partitions included in the storage device. Optionally, the partition table can be stored in the header of the storage device.

[0252] In some embodiments, the starting address of the updated second system partition is determined based on the size of the storage device and the size of the first space; the size of the updated user data partition is determined based on the starting address of the user partition and the starting address of the updated second system partition (or the size of the first space). Optionally, the size of the first space may be the size of the second system partition.

[0253] In some embodiments, if the space of the second system partition behind the user data partition is insufficient, the third space of the user data partition can be merged into the space of the second system partition. The third space can also include the continuous free space at the end of the user data partition. In other words, the size of the second system partition can be expanded by the size of the third space.

[0254] In some embodiments, if user data is stored in the third space, the user data is moved to a fourth space in the user data partition for storage. The fourth space is different from the third space and is free space in the user data partition. Optionally, the fourth space can be located before the third space, and the fourth space can be continuous free space or non-continuous free space. Optionally, the fourth space can be the same as or different from the second space.

[0255] S1602: Determine the target partition included in the storage device according to the request message.

[0256] Optionally, the target partition may include one or more partitions included in the storage device, which is not limited in this application. In some embodiments, the target partition may be determined based on the request message through a partition table corresponding to the storage device, which may be stored in the storage device or elsewhere.

[0257] S1603: Read and write the target partition.

[0258] It can be understood that reading and writing a target partition may refer to reading data from or writing data into the target partition.

[0259] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of method. It is understandable that, in order to realize the above functions, the device includes a hardware structure and / or software module corresponding to the execution of each function. In combination with the units and algorithm steps of each example described in the embodiment disclosed in this application, the embodiment of the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer-driven hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to realize the described functions for each specific application, but such implementation should not be considered to exceed the scope of the technical solution of the embodiment of the present application.

[0260] The present application is an embodiment that can divide the functional modules of the device according to the above method example. For example, each functional module can be divided corresponding to each function, or two or more functions can be integrated into one processing unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of units in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0261] As shown in Figure 17, a schematic diagram of the structure of a device provided in an embodiment of the present application is provided. The device 1700 can be used to implement the methods described in the above method embodiments. Exemplarily, the device 1700 may include: a processing unit 1701 and an acquisition unit 1702.

[0262] The processing unit 1701 is used to support the device 1700 to perform any processing function described in Figures 1 to 16. The acquisition unit 1702 is used to support the device 1700 to perform any acquisition function described in Figures 1 to 16.

[0263] Optionally, the device 1700 shown in Figure 17 may further include a storage unit 1703 storing a program or instruction. When the processing unit 1701 executes the program or instruction, the device 1700 shown in Figure 17 may execute the method described in the above method embodiment.

[0264] Optionally, the device 1700 shown in Figure 17 may also include a communication unit, which is used to support the device 1700 to execute the steps of communication between the device and other devices in the embodiments of the present application.

[0265] The technical effects of the device 1700 shown in FIG17 can refer to the technical effects described in the above method embodiments and will not be repeated here. The processing unit 1701 involved in the device 1700 shown in FIG17 can be implemented by a processor or processor-related circuit components, and can be a processor or processing module. The communication unit can be implemented by a transceiver or transceiver-related circuit components, and can be a transceiver or transceiver module.

[0266] An embodiment of the present application also provides a chip system, as shown in Figure 18, which includes at least one processor 1801 and at least one interface circuit 1802. The processor 1801 and the interface circuit 1802 can be interconnected via lines. For example, the interface circuit 1802 can be used to receive signals from other devices. For another example, the interface circuit 1802 can be used to send signals to other devices (such as the processor 1801). Exemplarily, the interface circuit 1802 can read instructions stored in the memory and send the instructions to the processor 1801. When the instructions are executed by the processor 1801, the device can execute the various steps performed by the device in the above embodiment. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0267] Optionally, there may be one or more processors in the chip system. The processor may be implemented in hardware or software. When implemented in hardware, the processor may be a logic circuit, an integrated circuit, etc. When implemented in software, the processor may be a general-purpose processor implemented by reading software code stored in a memory.

[0268] Optionally, the memory in the chip system may be one or more memories. The memory may be integrated with the processor or may be provided separately from the processor, which is not limited in this application. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or provided on different chips. This application does not specifically limit the type of memory or the configuration of the memory and the processor.

[0269] Exemplarily, the chip system can be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD) or other integrated chips.

[0270] It should be understood that each step in the above method embodiment can be completed by hardware integrated logic circuits in a processor or by software instructions. The method steps disclosed in the embodiments of the present application can be directly embodied as being executed by a hardware processor, or by a combination of hardware and software modules in a processor.

[0271] An embodiment of the present application further provides a computer storage medium, in which computer instructions are stored. When the computer instructions are executed on a device, the device executes the method described in the above method embodiment.

[0272] An embodiment of the present application provides a computer program product, which includes: a computer program or instructions, which, when executed on a computer, causes the computer to execute the method described in the above method embodiment.

[0273] In addition, an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the device to execute the methods in the above-mentioned method embodiments.

[0274] Among them, the equipment, computer storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0275] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0276] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The various embodiments can be combined with each other or referenced to each other without conflict. The device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another device, 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 through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0277] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0278] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0279] 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 readable storage medium. Based on this understanding, the technical solution of the embodiment 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, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments 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 magnetic disk or an optical disk.

[0280] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A partition management method, characterized in that: The method comprises: Get a request message, where the request message is used to read and write partitions included in a storage device, where the partitions include a user data partition and multiple system partitions, where the system partition is used to store a first type of data, where the user data partition is used to store a second type of data, where the system partition includes a first system partition and a second system partition, where the first system partition is arranged in front of the user data partition, and where the second system partition is arranged behind the user data partition; Determine a target partition included in the storage device according to the request message; Read and write the target partition.

2. The method according to claim 1, characterized in that: Before the acquisition request message, the first system partition and the second system partition are both arranged in front of the user data partition; The method further comprises: In the case where the space of the first system partition is insufficient, merging part or all of the space of the second system partition arranged in front of the user data partition into the space of the first system partition; The second system partition is arranged behind the user data partition.

3. The method according to claim 2, characterized in that The starting address of the user data partition remains unchanged; The step of arranging the second system partition behind the user data partition includes: The first space of the user data partition is set as the second system partition, wherein the first space includes a continuous free space at the end of the user data partition.

4. The method according to claim 3, characterized in that The first space is larger than or equal to the second system partition.

5. The method according to claim 4, characterized in that Before setting the first space of the user data partition as the second system partition, the method further includes: If user data is stored in the first space, the user data is moved to a second space of the user data partition for storage, where the second space is different from the first space and is a free space in the user data partition.

6. The method according to any one of claims 3 to 5, characterized in that: By updating the size of the user data partition included in the partition table, as well as the starting address and the ending address of the second system partition, the first space of the user data partition is set as the second system partition, and the partition table corresponds to the storage device, and the partition table is used to index the partitions included in the storage device.

7. The method according to claim 6, characterized in that The starting address of the updated second system partition is determined according to the size of the storage device and the size of the first space; the size of the updated user data partition is determined according to the starting address of the user data partition and the starting address of the updated second system partition.

8. The method according to claim 1, characterized in that The method further comprises: In the case that the space of the second system partition is insufficient, the third space of the user data partition is merged into the space of the second system partition, and the third space includes the continuous free space at the end of the user data partition.

9. The method according to claim 8, characterized in that Before merging the third space of the user data partition into the space of the second system partition, the method further includes: If user data is stored in the third space, the user data is moved to a fourth space of the user data partition for storage. The fourth space is different from the third space and is a free space in the user data partition.

10. The method according to claim 1, characterized in that Before obtaining the request message, the method further includes: Obtaining a partition table, the partition table including at least one parameter of a start address and an end address of the second system partition and a size of the user data partition; Determine whether to update the at least one parameter according to the size of the storage device.

11. A device, characterized in that: The method comprises modules for executing each step in the method according to any one of claims 1 to 10.

12. A device, characterized in that: include: A processor and a memory, wherein the memory is coupled to the processor, the memory is used to store program code, the program code includes instructions, and the processor reads the instructions from the memory to enable the device to execute the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium comprises a computer program, and when the computer program is run on a device, the device is caused to perform the method according to any one of claims 1 to 10.

14. A computer program product, characterized in that The computer program product comprises: a computer program or instructions, and when the computer program or instructions are executed on a computer, the computer is caused to perform the method according to any one of claims 1 to 10.

Images