CN112579179A - Partition mounting method of embedded system - Google Patents
Partition mounting method of embedded system Download PDFInfo
- Publication number
- CN112579179A CN112579179A CN201910942933.5A CN201910942933A CN112579179A CN 112579179 A CN112579179 A CN 112579179A CN 201910942933 A CN201910942933 A CN 201910942933A CN 112579179 A CN112579179 A CN 112579179A
- Authority
- CN
- China
- Prior art keywords
- error
- target partition
- configuration information
- file system
- partition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000005192 partition Methods 0.000 title claims abstract description 206
- 238000000034 method Methods 0.000 title claims abstract description 83
- 230000008439 repair process Effects 0.000 claims abstract description 44
- 238000001514 detection method Methods 0.000 claims abstract description 33
- 230000009471 action Effects 0.000 claims abstract description 15
- 230000008569 process Effects 0.000 claims description 46
- 238000012544 monitoring process Methods 0.000 claims description 19
- 238000011084 recovery Methods 0.000 claims description 16
- 230000006870 function Effects 0.000 description 6
- 101100226364 Arabidopsis thaliana EXT1 gene Proteins 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application discloses a partition mounting method of an embedded system, which comprises the following steps: before mounting a target partition to be mounted, judging whether an error mark set for the target partition exists or not; if the error mark exists, repairing the file system of the target partition; and if the error mark does not exist, mounting the target partition. The method of the embodiment of the application can directly repair the file system of the target partition under the condition that the error mark exists, and the file system of the target partition does not need to be repaired after mounting failure, so that the system starting time is shortened, and the efficiency is improved. Furthermore, under the condition that no error mark exists, the repairing action does not need to be executed, the time consumed by directly carrying out detection and repairing is saved, and the system starting time is also shortened.
Description
Technical Field
The application relates to the technical field of computer communication, in particular to a partition mounting method of an embedded system.
Background
In the existing embedded system, as more and more user data are stored in a data partition, reading and writing key partitions of the system are more and more frequent in the running process, such as a user data (userdata) partition, a customized partition and the like of an android system. If abnormal power failure occurs in the read-write process or the erase process of the partitions, file loss or data inconsistency can be caused, the partitions can be damaged greatly, the system cannot be mounted normally or mounted into read-only, and finally the system cannot be started or crashed. At present, the commonly adopted solution is to directly perform detection and error repair on a file system of a partition to be mounted in the process of starting up, and mount the partition after the detection and error repair, or directly perform partition mounting, and perform detection and error repair after the mounting failure is found. In both cases, the problem of low starting efficiency exists.
Disclosure of Invention
The application mainly solves the problem of providing a partition mounting method of an embedded system, which can improve the starting efficiency.
In order to solve the technical problem, the technical scheme adopted by the application is as follows: a partition mounting method of an embedded system is provided, and the method comprises the following steps: before mounting a target partition to be mounted, judging whether an error mark set for the target partition exists or not; if the error mark exists, repairing the file system of the target partition; and if the error mark does not exist, mounting the target partition.
Through the scheme, the beneficial effects of the application are that: according to the partition mounting method of the embedded system, before the target partition to be mounted is mounted, the judging step is set, whether the error mark set for the target partition exists or not is judged, if the error mark exists, the file system of the target partition is directly repaired, the file system is not required to be repaired after mounting failure, the system starting time is shortened, and the efficiency is improved. Furthermore, if no error mark exists, the actions of detection and repair do not need to be executed, so that the time consumed by directly performing detection and repair is saved, the system starting time is also shortened, and the efficiency is improved.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts. Wherein:
FIG. 1 is a flowchart illustrating an embodiment of a partition mount method for an embedded system according to the present disclosure;
FIG. 2 is a flowchart illustrating another embodiment of a partition mount method for an embedded system according to the present application;
FIG. 3 is a flowchart illustrating an embodiment of error monitoring of a file system of a target partition during operation of the file system according to the present application;
FIG. 4 is a flowchart illustrating another embodiment of error monitoring of a file system of a target partition during operation of the file system according to the present application;
FIG. 5 is a flowchart illustrating an embodiment of performing error monitoring on a file system of a target partition during a shutdown process according to the present application;
FIG. 6 is a schematic flow chart diagram illustrating one embodiment of erasing and/or repairing a target partition as provided herein;
FIG. 7 is a flow diagram illustrating one embodiment of erasing and/or repairing a target partition as provided herein.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
When ineffectiveness factors such as abnormal power failure and the like occur in the use process of the target partition, the data of the file system of the target partition may be damaged, and further the file system mounting function of the target partition is abnormal. When the data of the target partition is updated, if the data to be updated is being used, the update of the key data or the system abnormality may be caused, and the file system mount function of the target partition is also abnormal, which affects the use of the user.
The embodiment of the application provides a partition mounting method to solve the problem of low starting efficiency of the conventional partition mounting method. Further, the embodiments of the present application also provide a secure environment capable of erasing and/or repairing a partition when a fatal error occurs, where the secure environment only runs a minimal system, such as a bootloader/Recovery or a customized system secure running environment.
Specifically, referring to fig. 1, a partition mounting method for an embedded system according to an embodiment of the present application includes:
step 100: before the target partition to be mounted is mounted, whether an error mark set for the target partition exists is judged. In one embodiment, the error flag is generated during a last run or a last shutdown. Therefore, the corresponding judgment action can be executed before the target partition is mounted for the first time, and error detection and repair attempt are not needed to be carried out on the target partition. The specific contents and manner of generation of the error flag will be described in detail below.
If there is an error flag, execute step 200: and repairing the file system of the target partition. Specifically, the repairing the file system of the target partition may include: error detection and repair of the file system of the target partition is performed using a detection and repair tool, and/or an erase and/or backup recovery of the target partition is performed. That is, in this embodiment, the repairing the file system of the target partition includes three repairing manners, one is to perform error detection and repair on the file system of the target partition by using a detection and repair tool, the other is to perform erasure and/or backup recovery on the target partition, and the other is a combination of the two manners.
In a specific embodiment, a corresponding error detection and repair tool is selected according to the file system of the target partition to perform error detection and repair on the file system. For example, if the file system type of the target partition is EXT4, then the corresponding EXT4 file system repair tool is e2 fsck. The subsequent operation of differentiating the target partition based on the detected error flag will be described in further detail below.
If no error flag exists, execute step 300: and mounting the target partition.
According to the partition mounting method of the embedded system, before the target partition to be mounted is mounted, whether the target partition has the error mark or not is judged, if the error mark exists, the file system of the target partition is directly repaired, the file system of the target partition can be repaired without mounting failure, the system starting time is shortened, and the efficiency is improved. Furthermore, if no error mark exists, the action of repairing does not need to be executed, so that the time consumed by directly detecting and repairing is saved, the system starting time is also shortened, and the efficiency is improved.
Specifically, the embedded system of the embodiment of the present application includes, but is not limited to, an android system and a Linux system. The target partition in the embodiment of the application can be a system partition or a customized partition so as to meet the mounting requirement of the embedded system and the customized requirement of the end user. For example, the target partition is a customized map partition and is primarily used to store map data. If file system data on the customized map partition is damaged due to abnormal power failure, the navigation function may not be normally used by the terminal user. For another example, the target partition may also be a user data partition, which is used to store Apk installation data of the user.
The error flag in the embodiment of the application is generated in the last running process or the last shutdown process. The error marks in the embodiment of the application comprise a running error mark and an unloading error mark, wherein the running error mark is used for indicating that an error exists in the file system of the target partition monitored in the last running process, and the unloading error mark is used for indicating that the file system of the target partition monitored in the last shutdown process is not unloaded normally. The error flag may be a running error flag or an unloading error flag, or may include both a running error flag and an unloading error flag, and the errors in the two cases may be represented by the same flag or may be set to be represented by different flags.
Specifically, in one particular implementation, the run error flag and the unload error flag are set to be represented by different flags. At this time, before mounting the target partition to be mounted, it is determined whether at least one of the operation error flag and the uninstall error flag exists in step 100. If at least one of the run error flag and the unload error flag exists, step 200 is executed, and a file system of the target partition is subjected to error detection and repair by using a detection and repair tool, and/or the target partition is subjected to erasure and/or backup recovery. If the operation error flag and the uninstall error flag do not exist, step 300 is executed to mount the target partition.
It should be noted that, since the error flag is generated in the last operation process or the last shutdown process, it is necessary to store the error flag in a specific nonvolatile storage area, and set an access path of the storage area in the system, so that the storage area can be accessed when the system is started, and further, whether the error flag exists is determined.
And further, the error mark can be used for representing the error grade of the error detected in the last running process or the last shutdown process, and a corresponding repairing means is selected according to the error grade. For example, when the error level indicated by the error flag is relatively low, the file system of the target partition is first detected and repaired by using a detection and repair tool, and when the error level indicated by the error flag is relatively high, the target partition is directly erased and/or backed up for recovery.
As will be described in detail below with specific examples of errors resolved, and as shown in fig. 2 in particular, another embodiment of the present application includes the following steps:
step 100': before mounting a target partition to be mounted, judging whether at least one of a first operation error mark, a second operation error mark and an unloading error mark exists. And if at least one of the first operation error mark, the second operation error mark and the unloading error mark exists, selecting a corresponding execution repair mode according to the corresponding error level represented by the first operation error mark, the second operation error mark and the unloading error mark.
Specifically, in this embodiment, the error flags include a first operation error flag, a second operation error flag, and an uninstall error flag, where the first operation error flag and the second operation error flag are used to respectively indicate that the file system of the target partition monitored in the last operation process has a first slight error and a first serious error, and the uninstall error flag is used to indicate that the file system of the target partition monitored in the last shutdown process has not been normally uninstalled. In this step, the first operation error flag, the second operation error flag, and the unload error flag may all be determined, or only one of the first operation error flag, the second operation error flag, and the unload error flag may be determined.
In the embodiment of the present application, the "first" of the first minor error and the first major error does not have a definite sequential meaning, and is only used to indicate the error existing in the last operation process, where the first minor error and the first major error are classified according to the error grade, that is, according to the criteria such as whether the target partition can be theoretically repaired by the system tool, if the target partition cannot be theoretically repaired by the system tool, the first minor error is determined, and if the target partition can be theoretically repaired by the system tool, the first minor error is determined.
If the first operation error flag and/or the unload error flag exists, step 210 is executed: and utilizing a detection and repair tool to detect and repair errors of the file system of the target partition.
Specifically, in step 210, a corresponding file system detection and repair tool may be selected according to different file systems. For example, if the file system type is EXT4, and the corresponding EXT4 file system detection and repair tool is e2fsck, the e2fsck repair tool is selected to detect and repair the file system.
If the second operation error flag exists, step 230 is executed: and erasing or backing up and restoring the target partition. Specifically, if the second operation error flag exists, that is, the file system of the target partition monitored in the last operation process has the first serious error, at this time, the target partition cannot be repaired by the file system detection and repair tool, and therefore, the target partition can be directly erased or backed up and restored.
If not, executing step 300': and mounting the target partition.
Step 210 is followed by step 220: it is determined whether an error is detected and the level of the detected error. Due to step 210: the file system of the target partition is subjected to error detection and repair by using a detection and repair tool, the repaired target partition can be detected and repaired by the repair tool theoretically, but in the actual execution process, uncertain factors exist to cause that the repair cannot be performed, or the detection error is repaired in the subsequent operation process before, so that the error does not exist any more, and therefore the detection and repair result of the detected and repaired file system needs to be judged.
If no error is detected or the detected error belongs to the second minor error, then the process jumps to step 300': and mounting the target partition.
If the detected error belongs to the second fatal error, go to step 230: and erasing or backing up and restoring the target partition. This step is described in detail below.
The second minor error and the second major error do not have definite meanings, and only indicate that the error grade is judged for the error under the condition that the error still exists in the target partition after the target partition is detected and repaired by the detection and repair tool before the target partition to be mounted is mounted, wherein the second minor error indicates an error which does not affect the mounting of the target partition and the normal operation of the system, and the second major error indicates an error which can affect the subsequent mounting (cannot be mounted or can be mounted in a read-only mode) and/or the subsequent normal operation of the system. Specifically, for example, there are some errors that cannot be detected by the repair tool, and due to factors such as defects of the software itself, there may be a second minor error condition, and therefore, it is necessary to interpret the error; for another example, Bad Magic in Superblock, i.e. Magic error in the file system Superblock; unexecuted inconsistence, which detects inconsistent data beyond expectations, fails to repair the error as a second most serious error. In the present application, the first minor error, the first major error, the second minor error and the second major error may be distinguished and defined by developers according to specific practical situations.
Further, after the target partition is overloaded in step 300', the method further includes step 400: and in the current running process and/or the current shutdown process, carrying out error monitoring on the file system of the target partition, and selectively setting an error mark for the target partition according to a monitoring result.
Specifically, in this embodiment, by performing error monitoring during the operation process, the shutdown process, or both, an error can be timely found and processed accordingly; or forming an error mark as a judgment basis before the next target partition is mounted.
Referring to fig. 3, in one embodiment, the step 400 specifically includes the following steps:
step 410: in the system operation process, whether the file system of the target partition has I/O (input/output) errors or not is monitored.
Generally, all I/O requests are initiated by the application layer, the file system of the target file acts as a bridge, and the requests initiated by the application are converted to some extent and then read, changed, and deleted from the corresponding storage device. The I/O requests include open, read, write, and close operations of the file. When the I/O request fails, such as a read failure, a write failure, etc., i.e., an I/O error occurs, the file system of the target partition is considered to be corrupted. Wherein the I/O exceptions caused by write protection and read protection do not belong to I/O errors due to permission issues. I/O errors are typically obtained by detecting a log of the file system.
If there is an I/O error, go to step 411: the type of the I/O error is judged, and an error flag is selectively set.
Step 412: if the I/O error is a slight error, a first run error flag is generated.
Step 413: if the I/O error is a fatal error, a second operation error flag is generated, or step 230 is executed instead, and the target partition is erased and/or backed up for recovery. The minor error and the major error are classified by a criterion such as whether the target partition can be theoretically repaired by the system tool, and are considered to be a major error if the target partition cannot be theoretically repaired by the system tool, and are considered to be a minor error if the target partition can be theoretically repaired by the system tool.
In other embodiments, the I/O error type may not be determined, that is, as shown in fig. 4, the method includes the step 410': in the system operation process, monitoring whether an I/O error exists in a file system of a target partition;
if there is an I/O error, step 411': and setting a running error flag. And the generated error mark is used for detection and repair before and after the next startup.
Referring to FIG. 5, in another embodiment, step 400 includes the following steps:
step 420: and in the shutdown process, monitoring whether the target partition is normally unloaded.
Specifically, when the system is shut down, the target partition with the successful mount will execute the uninstall action to uninstall the file system in the target partition. The file system is mounted to normally access the data in the target partition, and the data must be unloaded when the system is shut down, otherwise, the problems of file loss and data asynchronism may be caused because the file system is not unloaded during the shutdown process of the system.
Step 421: if not, an error flag is generated.
Specifically, in this embodiment, the error flag is recorded in the storage device, and the error flag is used to determine whether the error flag set for the target partition exists before the next power-on mount. Specifically, in this embodiment, if the target partition is not unloaded normally, the shutdown unloading status of the target partition is marked as PART _ UMOUNT _ FAIL, and the mark is recorded in the storage device. If it is unloaded normally, a correct flag can be generated, marking the shutdown unloading status of the target partition as PART _ UMOUNT _ OK, and recording the mark in the storage device.
The steps for performing an erase or backup restore of the target partition will be described in detail below. As shown in fig. 6, the erasing or backup restoring of the target partition includes the following steps:
step 510: it is determined whether erasable configuration information and/or recoverable configuration information set for the target partition exists.
If erasable configuration information and/or recoverable configuration information is present, step 520: entering a safe mode;
step 530: in the secure mode, the target partition is erased and/or backup repaired using the erasable configuration information and/or the recoverable configuration information.
Preferably, after step 520 and before step 530, the method further includes:
step 521: it is determined whether the target partition is erasable or recoverable.
If yes, step 530: in the secure mode, the target partition is erased and/or backup repaired using the erasable configuration information and/or the recoverable configuration information.
If not, step 540: and ending the process, namely not executing the step of erasing and/or repairing the target partition in the safe mode.
First, the erasable configuration information and/or the recoverable configuration information is set by the user in advance, or the user is prompted to set after it is determined that an erase and backup recovery action is required.
The erasable configuration information is used to define the way the target partition is erased, such as the erase tool used. It should be noted that it is necessary to ensure that the target partition is in an unloaded state before erasing the partition. The specific erase action may include a formatting operation on the target partition to clear all data on the target partition, and then re-create the file system of the target partition. For example, when the target partition is EXT4, tool software such as mkfs. ext4 or make _ EXT4fs may be used. Of course, the erasing action may be formatting the target partition and rebuilding the file system in other ways.
The recoverable configuration information is used to define access paths for backup data and recovery patterns for the target partition. Specifically, in this embodiment, the access path includes a local data path of the embedded system, for example, a path in eMMC/Nand or the like; the path of data in the external storage device, such as a U disk/SD card; but also a network data path, etc., where the network data path can be taken on the premise that a security mode is required to support access to the network data path.
Generally, two recovery methods can be used to recover the target partition: one is to perform copy recovery action according to binary data through partition backup mirror image; the other is to perform copy recovery action in a file form, and when the latter is executed, it is required to ensure that the target partition needs to be mounted first and avoid other processes from performing read-write operation on the target partition. At this time, the system file needs to be reproduced in advance.
It is noted that, in general, since the system needs to be restarted when switching to the secure environment, the identification information of the target partition needs to be stored in a designated nonvolatile storage area before restarting. Of course, it is also necessary to select whether to store the erasable configuration information and/or the recoverable configuration information in the nonvolatile storage area according to the current storage manner of the erasable configuration information and/or the recoverable configuration information. For example, when the erasable configuration information and/or the recoverable configuration information is prompted for user input when a fatal error is detected and stored in the volatile memory area, the erasable configuration information and/or the recoverable configuration information needs to be stored in the non-volatile memory area as well. When the erasable configuration information and/or the recoverable configuration information are preset by the user and are already stored in the non-volatile storage area, the erasable configuration information and/or the recoverable configuration information are not considered to be stored again. Of course, the erasable configuration information and/or the recoverable configuration information may be stored again after being associated with the identification information of the target partition.
In the specific implementation process, the erasable and recoverable functions can be used simultaneously or separately, and the flexible configurability is realized. When the erasable configuration information and the recoverable configuration information exist at the same time, the erasing action is preferentially executed, and then the recovering action is executed. It is also possible to perform only the erasing action.
Specifically, as shown in fig. 7, in the secure mode, the step of erasing and/or repairing the target partition specifically includes:
step 701: and acquiring the identification information of the target partition and the related configuration information from the designated nonvolatile storage area.
Step 702: and judging whether erasable configuration information exists in the configuration information.
If yes, go to step 703, otherwise go to step 706.
Step 703: and judging whether the target partition is erasable. In this step, whether the target partition is erasable may be determined by determining whether the target partition is a system protection area or in an erasable list. The system protection area is, for example, a Read Only (Read Only) partition or a Write Protect (Write Protect).
If yes, go to step 704, erase the target partition according to the erase mode defined by the erasable configuration information, otherwise go to step 705: the process exits or step 706 may be executed instead. For example, when the system protection area is determined, step 705 is executed, and if the system protection area is not in the erasable list, step 706 is executed.
After step 704, the process may optionally go to step 706 or step 705, and exit the process directly.
Step 706: judging whether recoverable location information exists in the configuration information;
if yes, go to step 707, otherwise go to step 705: and exiting the process, and continuing to execute other actions in the security mode, such as UI display and the like.
Step 707: and judging whether the target partition can be recovered. In this step, it may be determined whether the target partition is recoverable by determining whether the target partition is a system protected area or is in a recoverable list.
If yes, go to step 708: and acquiring backup data according to an access path in the recoverable configuration information, and recovering the target partition by using the backup data according to a recovery mode defined by the recoverable configuration information.
If not, step 705: exiting the process.
The safety mode of the embodiment of the application can provide the functions of erasing and recovering the target partition, can simultaneously support and can also independently support, and has stronger flexibility. In the security mode, key partitions of the file system, such as system/vendor and other partitions, can not be erased and data can not be updated, so that the robustness and the security of the system are improved. The recovery function of the security mode in the embodiment of the application is not limited to the system backup partition, and may be a path on the external storage device, or the like.
The above embodiments are merely examples, and not intended to limit the scope of the present application, and all modifications, equivalents, and flow charts using the contents of the specification and drawings of the present application, or those directly or indirectly applied to other related arts, are included in the scope of the present application.
Claims (17)
1. A partition mounting method of an embedded system is characterized by comprising the following steps:
before mounting a target partition to be mounted, judging whether an error mark set for the target partition exists or not;
if the error mark exists, repairing the file system of the target partition;
and if the error mark does not exist, mounting the target partition.
2. The method of claim 1, wherein the error flag is generated during a last run or a last shutdown.
3. The method of claim 1, wherein the step of repairing the file system of the target partition comprises: and utilizing a detection and repair tool to detect and repair errors of the file system of the target partition and/or to erase and/or backup and restore the target partition.
4. The method of claim 3, wherein the step of repairing the file system of the target partition comprises:
when the error level represented by the error mark is relatively low, firstly, a detection and repair tool is utilized to detect and repair the error of the file system of the target partition;
and when the error level represented by the error mark is relatively high, directly performing erasing and/or backup recovery on the target partition.
5. The method according to claim 3, wherein the error flags include a run error flag and an unload error flag, the run error flag is used to indicate that an error exists in the file system of the target partition monitored in the last run, and the unload error flag is used to indicate that the file system of the target partition monitored in the last shutdown process has not been unloaded normally;
the step of judging whether an error flag set for the target partition to be mounted exists comprises the following steps:
determining whether at least one of the run error flag and the unload error flag exists;
the step of repairing the file system of the target partition comprises:
and utilizing a detection and repair tool to detect and repair errors of the file system of the target partition.
6. The method according to claim 3, wherein the error flags include a first operation error flag, a second operation error flag, and an uninstall error flag, the first operation error flag and the second operation error flag are used to indicate that the file system of the target partition has been monitored to have a first slight error and a first serious error respectively during a last operation, and the uninstall error flag is used to indicate that the file system of the target partition has not been normally uninstalled during a last shutdown;
the step of judging whether an error flag set for the target partition to be mounted exists comprises the following steps:
judging whether at least one of a first operation error mark, a second operation error mark and an unloading error mark exists;
the step of repairing the file system of the target partition further comprises:
if the first operation error mark and/or the unloading error mark exist, utilizing a detection and repair tool to carry out error detection and repair on the file system of the target partition;
and if the second operation error mark exists, erasing or backing up and recovering the target partition.
7. The method according to claim 5 or 6, wherein after the step of performing error detection and repair on the file system of the target partition by using the detection and repair tool, the method further comprises:
judging whether an error is detected and the grade of the detected error;
if no error is detected or the detected error belongs to a second slight error, entering the step of mounting the target partition;
and if the detected error belongs to a second serious error, erasing or backing up and recovering the target partition.
8. The method of claim 1, further comprising:
and in the current running process and/or the current shutdown process, carrying out error monitoring on the file system of the target partition, and selectively setting the error mark for the target partition according to a monitoring result.
9. The method according to claim 8, wherein the step of monitoring an error of the file system of the target partition during the current system operation and/or the current shutdown process, and selectively setting the error flag for the target partition according to a monitoring result includes:
in the running process of the system, monitoring whether the file system of the target partition has I/O errors;
if the I/O error exists, judging the type of the I/O error, and selectively setting the error mark.
10. The method of claim 9, wherein the step of determining the type of I/O error and selectively setting the error flag comprises:
if the I/O error is a slight error, generating a first operation error mark;
and if the I/O error is a serious error, generating a second operation error mark, or erasing and/or backing up and recovering the target partition.
11. The method according to claim 8, wherein the step of monitoring an error of the file system of the target partition during the current system operation and/or the current shutdown process, and selectively setting the error flag for the target partition according to a monitoring result includes:
in the running process of the system, monitoring whether the file system of the target partition has I/O errors;
and if the I/O error exists, setting the operation error mark.
12. The method according to claim 8, wherein the step of monitoring an error of the file system of the target partition during the current system operation and/or the current shutdown process, and selectively setting the error flag for the target partition according to a monitoring result includes:
in the shutdown process, monitoring whether the target partition is normally unloaded;
and if the unloading is not normally carried out, generating the error mark.
13. The method of claim 3, wherein the step of performing an erase and/or backup restore on the target partition comprises:
judging whether erasable configuration information and/or recoverable configuration information set for the target partition exists;
if the erasable configuration information and/or the recoverable configuration information exist, entering a safety mode;
and in the safety mode, erasing and/or backing up and repairing the target partition by using erasable configuration information and/or recoverable configuration information.
14. The method of claim 13, wherein the erasable configuration information and/or the recoverable configuration information is preset by a user or is prompted to be set by the user after determining that an erase and/or backup recovery is required.
15. The method according to claim 13, wherein the erasing and/or backup repairing the target partition using erasable configuration information and/or recoverable configuration information in the secure mode comprises:
if the recoverable configuration information exists, obtaining backup data according to an access path in the recoverable configuration information, and recovering the target partition by using the backup data according to a recovery mode defined by the recoverable configuration information;
and if the erasable configuration information exists, erasing the target partition according to an erasing mode defined by the erasable configuration information.
16. The method of claim 13, wherein in the secure mode, the step of erasing and/or backup repairing the target partition using erasable configuration information and/or the recoverable configuration information comprises:
and if the erasable configuration information and the recoverable configuration information exist at the same time, selecting to preferentially execute the erasing action of the target partition.
17. The method according to claim 13, wherein before the step of erasing and/or backing up the target partition in the secure mode using erasable configuration information and/or the recoverable configuration information, further comprising:
judging whether the target partition is erasable or recoverable;
and if the target partition is not erasable or unrecoverable, the step of erasing and/or backing up and repairing the target partition by using erasable configuration information and/or the recoverable configuration information in the safety mode is not executed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910942933.5A CN112579179A (en) | 2019-09-30 | 2019-09-30 | Partition mounting method of embedded system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910942933.5A CN112579179A (en) | 2019-09-30 | 2019-09-30 | Partition mounting method of embedded system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112579179A true CN112579179A (en) | 2021-03-30 |
Family
ID=75116448
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910942933.5A Pending CN112579179A (en) | 2019-09-30 | 2019-09-30 | Partition mounting method of embedded system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112579179A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116055310A (en) * | 2022-06-28 | 2023-05-02 | 荣耀终端有限公司 | Method, device and network equipment for recovering user configuration information |
| CN116361817A (en) * | 2023-06-02 | 2023-06-30 | 麒麟软件有限公司 | Protection method of ubi file system under Linux |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6591376B1 (en) * | 2000-03-02 | 2003-07-08 | Hewlett-Packard Development Company, L.P. | Method and system for failsafe recovery and upgrade of an embedded operating system |
| CN103377094A (en) * | 2012-04-12 | 2013-10-30 | 金蝶软件（中国）有限公司 | Abnormity monitoring method and abnormity monitoring device |
| KR20140032071A (en) * | 2012-09-05 | 2014-03-14 | 주식회사 팬택 | Apparatus and method for managing file system of a computing device |
| CN105072372A (en) * | 2015-07-30 | 2015-11-18 | 成都亿盟恒信科技有限公司 | Automatic repair method for FAT file system on DVR terminal |
| CN106126382A (en) * | 2016-06-29 | 2016-11-16 | 北京小米移动软件有限公司 | Identify the method and device of file system error |
| CN106708960A (en) * | 2016-11-30 | 2017-05-24 | 浙江宇视科技有限公司 | Restoration method for file system of NAS device and NAS device |
| CN106776128A (en) * | 2016-11-29 | 2017-05-31 | 邦彦技术股份有限公司 | Method for ensuring normal start of Linux operating system |
| CN106919470A (en) * | 2015-12-25 | 2017-07-04 | 中兴通讯股份有限公司 | A kind of data reconstruction method and device |
-
2019
- 2019-09-30 CN CN201910942933.5A patent/CN112579179A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6591376B1 (en) * | 2000-03-02 | 2003-07-08 | Hewlett-Packard Development Company, L.P. | Method and system for failsafe recovery and upgrade of an embedded operating system |
| CN103377094A (en) * | 2012-04-12 | 2013-10-30 | 金蝶软件（中国）有限公司 | Abnormity monitoring method and abnormity monitoring device |
| KR20140032071A (en) * | 2012-09-05 | 2014-03-14 | 주식회사 팬택 | Apparatus and method for managing file system of a computing device |
| CN105072372A (en) * | 2015-07-30 | 2015-11-18 | 成都亿盟恒信科技有限公司 | Automatic repair method for FAT file system on DVR terminal |
| CN106919470A (en) * | 2015-12-25 | 2017-07-04 | 中兴通讯股份有限公司 | A kind of data reconstruction method and device |
| CN106126382A (en) * | 2016-06-29 | 2016-11-16 | 北京小米移动软件有限公司 | Identify the method and device of file system error |
| CN106776128A (en) * | 2016-11-29 | 2017-05-31 | 邦彦技术股份有限公司 | Method for ensuring normal start of Linux operating system |
| CN106708960A (en) * | 2016-11-30 | 2017-05-24 | 浙江宇视科技有限公司 | Restoration method for file system of NAS device and NAS device |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116055310A (en) * | 2022-06-28 | 2023-05-02 | 荣耀终端有限公司 | Method, device and network equipment for recovering user configuration information |
| CN116055310B (en) * | 2022-06-28 | 2023-10-20 | 荣耀终端有限公司 | Method, device and network equipment for recovering user configuration information |
| CN116361817A (en) * | 2023-06-02 | 2023-06-30 | 麒麟软件有限公司 | Protection method of ubi file system under Linux |
| CN116361817B (en) * | 2023-06-02 | 2023-08-22 | 麒麟软件有限公司 | Protection method of ubi file system under Linux |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7675776B2 (en) | Bit map control of erase block defect list in a memory | |
| CN101329631B (en) | Method and apparatus for automatically detecting and recovering start-up of embedded system | |
| JP4480815B2 (en) | Memory rewriting method and computer system | |
| CN111552592A (en) | Double-backup starting method and system | |
| US5421003A (en) | Disk storage system with fault tolerant media maintenance | |
| CN105786545B (en) | Breakpoint recovery method and system based on heterogeneous hybrid memory | |
| CN112579179A (en) | Partition mounting method of embedded system | |
| CN114895845A (en) | EMmC data storage control method and embedded mainboard | |
| CN114579971A (en) | Starting method of safety control module and related device | |
| CN113626262A (en) | BMC recovery method, system, equipment and medium | |
| CN116361817B (en) | Protection method of ubi file system under Linux | |
| JP2002062956A (en) | Service interruption processing method and service interruption processing device | |
| CN111984195A (en) | Method and device for improving stability of embedded Linux system | |
| JP2005284902A (en) | Terminal device, control method and control program thereof, host device, control method and control program thereof, and method, system, and program for remote updating | |
| KR100853941B1 (en) | Multimedia storage device and data recovering method of the device | |
| CN113094107B (en) | Data protection method, device, equipment and computer storage medium | |
| CN114356653A (en) | Power-down protection method and device for industrial control firewall | |
| CN111522686B (en) | Nonvolatile data reading and writing method and device | |
| CN111897583A (en) | Equipment starting method and embedded equipment | |
| US11250929B2 (en) | System for detecting computer startup and method of system | |
| CN117724658B (en) | Data security storage method and system based on embedded Linux system | |
| JP2002259152A (en) | Flash memory rewriting method | |
| CN117312059A (en) | PFR BIOS function test method, device, equipment and medium | |
| JPH06266573A (en) | Fault recovery information managing system | |
| US7069471B2 (en) | System PROM integrity checker |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |