Abnormality processing method and device, equipment and medium

Abstract

The invention discloses an exception handling method and device, equipment and a medium. The exception handling method comprises the steps that a file system of a target partition is monitored; when it is monitored that the file system is abnormal, abnormal information corresponding to the target partition is recorded; in response to a starting operation of the vehicle-mounted terminal, when the abnormal information is recorded, formatting the target partition, so that a user terminal performs data recovery on the target partition after acquiring the formatted information; wherein the formatting information is information representing that the target partition is formatted. Thus, the file system of the target partition is monitored, the abnormal information can be recorded in time, and the formatting operation of the target partition is carried out after the vehicle-mounted terminal is restarted, so that the user terminal can carry out data recovery based on the formatting information, the file system can normally use the corresponding partition, the situation that the file system cannot be recovered after being abnormal is avoided, and the user experience is improved. And the reliability and the restorability of the file system are ensured.

Description

Technical Field

[0001] The present application relates to the technical field of system exception handling, and in particular to an exception handling method, device, equipment and medium. Background Art

[0002] In the early and middle stages of mass production of real vehicles, due to the frequent storage of log information in a specific partition of Flash (i.e. flash memory), the file system of the partition becomes Read Only (i.e. read-only state), and the partition cannot be used. When the file system becomes read-only mode, the relevant log or configuration information cannot be modified or written in the partition, causing some OTA (i.e. Over-the-Air, air download technology) upgrades of the real vehicle or remote control of the vehicle computer to fail. It can be seen that when the file system is abnormal and becomes read-only mode, it will affect the function of the vehicle computer. Therefore, how to ensure the reliability and recoverability of the file system is an urgent problem to be solved. Summary of the invention

[0003] In view of this, the purpose of this application is to provide an exception handling method, device, equipment and medium, which can ensure the reliability and recoverability of the file system. The specific scheme is as follows:

[0004] In a first aspect, the present application discloses an exception handling method, which is applied to a vehicle-mounted terminal, comprising:

[0005] Monitor the file system of the target partition;

[0006] When an abnormality is detected in the file system, the abnormality information corresponding to the target partition is recorded;

[0007] In response to the startup operation of the vehicle-mounted terminal itself, when the abnormal information is recorded, the target partition is formatted so that the user terminal can recover data of the target partition after acquiring the formatting information;

[0008] The formatting information is information indicating that the target partition has been formatted.

[0009] Optionally, after the file system is monitored to be abnormal, the method further includes:

[0010] The abnormal state corresponding to the file system is reported to the user terminal, so that the user terminal determines whether to perform the startup operation based on the abnormal state.

[0011] Optionally, after formatting the target partition, the method further includes:

[0012] The formatting information is recorded so that the user terminal calls a preset interface to query the formatting information from the vehicle-mounted terminal, and restores data from the target partition after the formatting information is queried.

[0013] Optionally, the recording of the abnormal information corresponding to the target partition includes:

[0014] Recording the abnormal information corresponding to the target partition to the raw partition;

[0015] Correspondingly, before formatting the target partition, the method further includes: querying the raw partition to see whether the abnormal information is recorded.

[0016] Optionally, also include:

[0017] In response to a partition registration operation, a partition corresponding to the partition registration operation is determined as a target partition.

[0018] Optionally, after formatting the target partition, the method further includes:

[0019] Remount the target partition.

[0020] Optionally, in response to the startup operation of the vehicle-mounted terminal itself, the method further includes:

[0021] When the abnormal information is not recorded, mounting the target partition;

[0022] If the target partition is mounted abnormally, the target partition is formatted so that the user terminal can recover data from the target partition.

[0023] In a second aspect, the present application discloses an exception handling device, which is applied to a vehicle-mounted terminal, comprising:

[0024] The file system monitoring module is used to monitor the file system of the target partition;

[0025] The abnormal information recording module is used to record the abnormal information corresponding to the target partition when the abnormality of the file system is monitored;

[0026] A startup operation response module, used for responding to the startup operation of the vehicle-mounted terminal itself, and formatting the target partition when the abnormal information is recorded, so that the user terminal can recover the data of the target partition after obtaining the formatting information;

[0027] The formatting information is information indicating that the target partition has been formatted.

[0028] In a third aspect, the present application discloses an electronic device, including a memory and a processor, wherein:

[0029] The memory is used to store the computer program;

[0030] The processor is used to execute the computer program to implement the above-mentioned exception handling method.

[0031] In a fourth aspect, the present application discloses a computer-readable storage medium, characterized in that it is used to store a computer program, wherein the computer program implements the aforementioned exception handling method when executed by a processor.

[0032] It can be seen from the above scheme that the present invention provides an exception handling method, which is applied to a vehicle-mounted terminal, including: monitoring the file system of a target partition; when an exception is detected in the file system, recording the exception information corresponding to the target partition; in response to the startup operation of the vehicle-mounted terminal itself, when the exception information is recorded, formatting the target partition so that the user terminal can recover data from the target partition after obtaining the formatting information; wherein the formatting information is information indicating that the target partition has been formatted.

[0033] It can be seen that the beneficial effects of the present application are: monitoring the file system of the target partition based on the vehicle terminal, recording the corresponding abnormal information when the file system of the target file is abnormal, and formatting the target partition based on the recorded abnormal information after the vehicle terminal is restarted, so that the abnormal information can be recorded in time, and the target partition can be formatted after the vehicle terminal is restarted, so that the user terminal can perform data recovery based on the formatted information. The present application is based on the recovery mechanism of the file system in the event of an abnormality during operation, records the abnormal information in time and formats the partition, so that the file system can use the corresponding partition normally, avoids the inability to recover after the file system is abnormal, and ensures the reliability and recoverability of the file system.

[0034] Correspondingly, an exception handling device, equipment and readable storage medium provided by the present application also have the above-mentioned technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0036] Figure 1 A flow chart of an exception handling method provided in an embodiment of the present application;

[0037] Figure 2A specific exception handling method flow chart provided in an embodiment of the present application;

[0038] Figure 3 A schematic diagram of the structure of an exception handling device provided in an embodiment of the present application;

[0039] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0041] In the early and middle stages of mass production of real vehicles, due to the frequent storage of log information in the specific partitions of Flash, the UBIFS (Unsorted Block Image File System) file system became Read Only and could not use the partition. When the partition became read-only mode, the relevant logs or configuration information could not be modified or written in the partition, causing some OTA upgrades of the real vehicle or remote control of the vehicle computer to fail. For the RAW (RAW Image Format) partitions of mass-produced real vehicles, if there is a partition abnormality, it can be restored through the AB partition division mechanism, that is, switch to the backup partition and then restore, but some UBI file systems mounted with large storage space cannot perform AB partition division.

[0042] During the actual vehicle road test and the early stage of mass production, a large number of logs will still be written to the file system of TBOX (i.e. Telematics BOX, the vehicle terminal), which may cause the file system to become read-only. Read-only cannot save the log information before and after the abnormal time point, and the debugging efficiency is low. In addition, due to the limited stability of NAND (i.e. Not AND) flash memory in the actual vehicle environment, when the NAND charge is unstable, it will cause UECC (i.e. Uncorrectable Error correction code) ERROR problems, resulting in the read-only state of the UBI file system mounted on the partition, causing some car machine functions to fail. It can be remounted as readable and writable after restarting and remounting, but if the problematic Block is stepped on, the partition will still be read-only. To this end, the present application provides an exception handling solution to solve the problem in the abnormal partition read-only scenario, avoid the file system from being unable to recover after the abnormality, and ensure the reliability and recoverability of the file system.

[0043] See also Figure 1 As shown, the embodiment of the present application discloses an exception handling method, which is applied to a vehicle-mounted terminal, comprising:

[0044] Step S11: monitoring the file system of the target partition.

[0045] Among them, the vehicle-mounted terminal (TBOX) can be understood as the vehicle's remote communication terminal. It is a key component in the Internet of Vehicles system and integrates the vehicle body network and wireless communication functions. It can be based on the Android (i.e. Android) or Linux operating system, and has a built-in communication module (such as a SIM (i.e. Subscriber Identity Module) card) to support remote communication and data transmission. TBOX can realize communication between the vehicle and the background system and mobile phone APP (i.e. Application) in the Internet of Vehicles system. TBOX is part of the car computer, which refers to the machine equipment installed inside the vehicle, which can integrate multiple functions, such as audio, navigation, reversing image, telephone, etc.

[0046] The target partition can be understood as the flash memory partition that needs to be monitored. The flash memory partition refers to a logical area among multiple logical areas into which the flash memory is divided, which can be managed and accessed independently. The file system corresponding to each partition runs independently. The file system can be understood as a system for storing and managing data corresponding to the partition. In this embodiment, the file system can be a file system designed for flash memory, for example, a UBIFS file system.

[0047] The embodiment of the present application can implement the monitoring logic in the vehicle terminal, and monitor the file system of the target partition through the monitoring logic. The monitoring logic can be understood as the application layer logic. That is, the embodiment can monitor the target partition through the application layer in the Tbox.

[0048] In an optional implementation, the embodiment of the present application can respond to a partition registration operation and determine the partition corresponding to the partition registration operation as a target partition. The partition to be detected can be registered through the partition registration operation and monitored as a target partition. That is, the target partition is the partition that needs to be monitored. In this embodiment, the target partition can be registered based on the partition identifier, and the partition identifier can uniquely identify the corresponding target partition. For example, the partition identifier can be the name of the partition. In this embodiment, multiple partitions can be registered, that is, multiple target partitions can be monitored. In addition, multiple target partitions can be monitored by polling.

[0049] Step S12: When an abnormality is detected in the file system, the abnormality information corresponding to the target partition is recorded.

[0050] The abnormality of the file system may include entering a read-only mode, etc. The abnormality information may be a partition identifier corresponding to the target partition.

[0051] In an optional implementation, the abnormal information corresponding to the target partition can be recorded in a raw partition; a raw partition is a partition that is not formatted by a file system and is directly read and written by an application program. This can bypass the file system layer of the operating system and achieve more efficient I / O (i.e., Input / Output) operations.

[0052] Furthermore, this embodiment can report the abnormal state corresponding to the file system to the user terminal, so that the user terminal determines whether to perform a startup operation based on the abnormal state. The user can choose to restart the TBOX according to the current service situation.

[0053] Step S13: In response to the startup operation of the vehicle terminal itself, when the abnormal information is recorded, the target partition is formatted so that the user terminal can recover data in the target partition after obtaining the formatting information; wherein the formatting information is information indicating that the target partition has been formatted.

[0054] In the embodiment of the present application, if the user decides to restart the vehicle terminal according to the current business situation, the vehicle terminal can be restarted through the user terminal to trigger the execution of step S13.

[0055] In an optional implementation, the formatting information may be a preset character, such as 1, where 1 indicates that the target partition has been formatted.

[0056] In the embodiment of the present application, whether the abnormal information is recorded can be queried in the raw partition. In the case where the abnormal information is queried from the raw partition, the target partition corresponding to the abnormal information is formatted based on the abnormal information. The target partition can be determined based on the partition identifier, and then the target partition is formatted.

[0057] In an optional implementation, the target partition may be formatted with UBI format. Specifically, the specific process of formatting the target partition may include: determining whether the target partition is in a mounted state, if it is in a mounted state, unmounting the target partition, and if the target partition is successfully unmounted, unbinding the UBI device if there is a UBI device, and performing UBI formatting if the unbinding is successful. If the target partition fails to be unmounted, or the UBI device fails to be unbound, or the UBI format fails, forced formatting is performed. For example, the flash_erase command is executed (i.e., resetting or clearing the data in the flash). Some information in the UBI can be retained by formatting with UBI format. For example, the erase status EC value (i.e., the number of erases) of the UBI corresponding block. Because each block has a corresponding lifespan, if the number of erases exceeds the preset value, the block is unstable, and some important information data can be recorded by formatting with UBI format. It should be pointed out that for a partition, if the power is turned off and restarted directly, the partition was in a mounted state before, and it remains in a mounted state after the power is turned off and restarted. In this case, if UBI formatting is performed, formatting will fail, and the UBI device cannot be bound. When formatting the target partition, the embodiment of the present application first determines whether the target partition is in a mounted state. If the target partition is in a mounted state, it is first uninstalled. After the uninstallation is successful, if the UBI device exists, the UBI device is unbound. The UBI format is performed only after the unbinding is successful. In this way, the probability of UBI formatting failure can be reduced, and the UBI formatting of the target partition is guaranteed to be successful. If the target partition fails to be uninstalled, or the UBI device fails to be unbound, or the UBI formatting fails, the target partition can also be formatted by forced formatting to provide an available target partition for subsequent data recovery.

[0058] In an optional implementation, after the target partition is formatted, the embodiment of the present application may record formatting information so that the user terminal calls a preset interface to query the formatting information from the vehicle-mounted terminal, and performs data recovery on the target partition after the formatting information is queried. For example, after the target partition is formatted, a message may be sent to the user terminal so that the user terminal calls a preset interface to query the formatting information from the vehicle-mounted terminal. The message may contain interface information corresponding to the preset interface, and the user terminal calls the preset interface based on the interface information. In another optional implementation, the formatting information may also be reported to the user terminal after the target partition is formatted.

[0059] Furthermore, after formatting the target partition, the embodiment of the present application further includes: remounting the target partition, thereby ensuring the availability of the target partition.

[0060] In an optional implementation, in response to the startup operation of the vehicle terminal itself, the method further includes: when the abnormal information is not recorded, mounting the target partition; if the mounting of the target partition is abnormal, formatting the target partition so that the user terminal can restore data of the target partition. The startup operation can be a restart operation.

[0061] That is, the embodiment of the present application can also handle the exceptions that occur during the normal mounting process of the target partition after the vehicle terminal is started, in which the file system has no exceptions. The exception can be understood as the number of attempts to mount the target partition reaching a preset value, such as 1 time, 2 times, 3 times, etc. In this embodiment, if the target partition is mounted abnormally, the target partition is formatted and the formatting information is recorded so that the user terminal can perform data recovery on the target partition based on the formatting information. For example, after the target partition is formatted, a message can be sent to the user terminal so that the user terminal calls a preset interface to query the formatting information from the vehicle terminal. The message may contain interface information corresponding to the preset interface, and the user terminal calls the preset interface based on the interface information.

[0062] It can be seen that the embodiment of the present application monitors the file system of the target partition based on the vehicle terminal. When the file system of the target file is monitored to be abnormal, the corresponding abnormal information is recorded, and after the vehicle terminal is restarted, the target partition is formatted based on the recorded abnormal information. In this way, the abnormal information can be recorded in time, and the target partition is formatted after the vehicle terminal is restarted, so that the user terminal can perform data recovery based on the formatted information. The present application is based on the recovery mechanism of the file system in the event of an abnormality during operation, and records the abnormal information in time and formats the partition, so that the file system can use the corresponding partition normally, avoiding the inability to recover after the file system is abnormal, and ensuring the reliability and recoverability of the file system.

[0063] For further information, see Figure 2 As shown, the embodiment of the present application discloses a specific exception handling method flow chart. The embodiment of the present application is developed and designed based on the Linux system, and a file system exception monitoring mechanism is designed. The partition with file system exceptions is monitored through the TBOX upper-layer application monitoring mechanism. The mechanism can monitor multiple different partitions by registering partitions. After the system in TBOX is running, the file system status of different partitions is monitored and processed using a polling method. If an abnormality is monitored, the abnormal status is reported to the client application. After the system in TBOX is restarted, the partition of the UBIFS file system is mounted, and the status of the partition is checked before the partition is mounted. If a file abnormality is found, the format mechanism is used to format and remount the partition and record the formatting information. After the client application obtains the partition abnormal status information and the partition formatting information, it performs data recovery.

[0064] like Figure 2,The TBOX upper layer application dynamically monitors the file system status of the partition during operation. When a file system abnormality is detected, the abnormal partition information is set to the raw partition through the interface. The name of the raw partition is info, and the abnormal status is reported to the client application layer (i.e., the application installed on the user terminal). The client application layer chooses to restart TBOX according to the current business situation. After TBOX restarts, it determines whether the info partition has recorded abnormal partition information. If so, the partition is formatted and the formatting information is recorded. After the client application layer obtains the formatting information, it recovers the partition data. Specifically, the TBOX upper layer application monitors the abnormal state of the file system. If the file system mounted by the customer partition is abnormal, the customer partition abnormal information is recorded to the raw partition info through a command. The customer partition abnormality is reported to the customer application layer. After receiving the abnormality, the customer application layer selects a restart action according to the customer business situation. The customer application restarts TBOX. After TBOX restarts, it determines whether the raw partition info records the customer partition information (i.e., the partition abnormal information). If it does not exist, the customer partition is mounted. If it exists, it determines whether the customer partition is in a mounted state. If it is in a mounted state, the customer partition is unmounted to determine whether the unmounting is successful. If the unmounting is successful, it determines whether the ubiXX_0 device (i.e., the subvolume of the UBI device) exists. If it exists, ubidetach the device (i.e., unbind the UBI device) to determine whether the ubidetach device is successful. If successful, ubiformat formats the partition, and if the formatting is successful, records the formatting information, remounts the customer partition, and the customer performs partition data recovery. It should be pointed out that when using UBI format formatting, the UBI device and MTD (i.e., Memory Technology Device, flash memory technology device) need to be unbound.

[0065] It can be seen that the embodiment of the present application provides a processing measure for the file system anomaly that occurs in the current vehicle and a mechanism for recovering from anomalies during the partition mounting phase. A monitoring mechanism for file system anomalies is provided, and the partition operation status and recovery mechanism after partition processing are constantly monitored. In this way, based on the recovery mechanism in the event of anomalies in the operation and mounting process of the UBIFS file system, the partition can be used normally, and the file system cannot be recovered after anomalies, so that the functions it depends on cannot use the corresponding partitions, and the reliability and recoverability of the mass production version using the UBIFS file system are achieved.

[0066] For example, a car manufacturer's mass-produced vehicles were found to have no response when the air conditioner was remotely controlled during use. After analysis, it was found that the file system mounted on the customer partition was read-only, which made it impossible to write data to the partition, and the remote control of the car failed. Based on the exception handling solution provided in the embodiment of the present application, the following steps can be performed: the first step is to register the customer partition exception monitoring mechanism; the second step is for the customer to restart the car after monitoring the partition exception; the third step is for the car to restart and format the abnormal partition and then remount the partition; the fourth step is for the customer to recover data from the formatted partition.

[0067] For example, a car manufacturer's mass-produced vehicle failed during OTA upgrade. It was found that the upgrade partition used by the customer abnormally became read-only, which caused the OTA upgrade package to time out after being unable to access, and ultimately caused the OTA upgrade to fail. Based on the exception handling solution provided in the embodiment of the present application, the following steps can be performed: the first step is to register the customer partition abnormality monitoring mechanism; the second step is that the customer application restarts the vehicle after monitoring the partition abnormality; the third step is that the vehicle restarts and formats the abnormal partition and remounts the partition; the fourth step is that the customer recovers the data of the formatted partition.

[0068] It can be seen that the embodiment of the present application can optimize NAND reliability and stability by real-time monitoring of partition operation status and recovery mechanism, thereby ensuring that the vehicle computer functions can be used normally.

[0069] See also Figure 3 As shown, the embodiment of the present application discloses an exception handling device, which is applied to a vehicle-mounted terminal, including:

[0070] The file system monitoring module 11 is used to monitor the file system of the target partition;

[0071] The abnormal information recording module 12 is used to record the abnormal information corresponding to the target partition when the abnormality of the file system is monitored;

[0072] A startup operation response module 13, for responding to the startup operation of the vehicle-mounted terminal itself, and formatting the target partition when the abnormal information is recorded, so that the user terminal can recover the data of the target partition after obtaining the formatting information;

[0073] The formatting information is information indicating that the target partition has been formatted.

[0074] In an optional embodiment, the exception handling device may also include an abnormal status reporting module, which is used to: after the file system monitoring module 11 monitors that an abnormality has occurred in the file system, report the abnormal status corresponding to the file system to the user terminal, so that the user terminal determines whether to execute the startup operation based on the abnormal status.

[0075] In an optional embodiment, the startup operation response module 13 may also include a formatting information recording submodule, which is used to: record formatting information after formatting the target partition, so that the user terminal calls a preset interface to query the formatting information from the vehicle-mounted terminal, and restore data to the target partition after querying the formatting information.

[0076] In an optional implementation, the exception information recording module 12 is specifically used to: record the exception information corresponding to the target partition to the raw partition;

[0077] Accordingly, the operation response module 13 is started, which is specifically used to query whether the abnormal information is recorded in the raw partition before formatting the target partition.

[0078] In an optional implementation, the exception handling device may further include a partition registration module, configured to: in response to a partition registration operation, determine the partition corresponding to the partition registration operation as a target partition.

[0079] In an optional implementation, the startup operation response module 13 may further include a partition mounting submodule, which is used to remount the target partition after formatting the target partition.

[0080] In an optional implementation, the partition mounting submodule is further configured to: mount the target partition when the abnormal information is not recorded. Correspondingly, the startup operation response module 13 can also be configured to: format the target partition if the target partition is mounted abnormally, so that the user terminal can perform data recovery on the target partition.

[0081] It can be seen that the embodiment of the present application monitors the file system of the target partition based on the vehicle terminal. When the file system of the target file is monitored to be abnormal, the corresponding abnormal information is recorded, and after the vehicle terminal is restarted, the target partition is formatted based on the recorded abnormal information. In this way, the abnormal information can be recorded in time, and the target partition is formatted after the vehicle terminal is restarted, so that the user terminal can perform data recovery based on the formatted information. The present application is based on the recovery mechanism of the file system in the event of an abnormality during operation, and records the abnormal information in time and formats the partition, so that the file system can use the corresponding partition normally, avoiding the inability to recover after the file system is abnormal, and ensuring the reliability and recoverability of the file system.

[0082] See also Figure 4As shown, an embodiment of the present application discloses an electronic device 20, including a processor 21 and a memory 22; wherein the memory 22 is used to store a computer program; the processor 21 is used to execute the computer program, and the exception handling method disclosed in the above embodiment.

[0083] For the specific process of the above exception handling method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0084] Furthermore, the memory 22 as a carrier for storing resources may be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the storage method may be temporary storage or permanent storage.

[0085] In addition, the electronic device 20 also includes a power supply 23, a communication interface 24, an input / output interface 25 and a communication bus 26; wherein the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and an external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input / output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0086] Furthermore, an embodiment of the present application also discloses a computer-readable storage medium for storing a computer program, wherein the computer program, when executed by a processor, implements the exception handling method disclosed in the aforementioned embodiment.

[0087] For the specific process of the above exception handling method, reference may be made to the corresponding contents disclosed in the aforementioned embodiments, which will not be described in detail here.

[0088] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0089] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0090] The above is a detailed introduction to an exception handling method, device, equipment and medium provided by the present application. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea; at the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. An exception handling method, characterized in that: Applied to vehicle terminals, including: Monitor the file system of the target partition; When an abnormality is detected in the file system, the abnormality information corresponding to the target partition is recorded; In response to the startup operation of the vehicle-mounted terminal itself, when the abnormal information is recorded, the target partition is formatted so that the user terminal can recover data of the target partition after acquiring the formatting information; The formatting information is information indicating that the target partition has been formatted.

2. The exception handling method according to claim 1, characterized in that: After the file system is monitored to be abnormal, the method further includes: The abnormal state corresponding to the file system is reported to the user terminal, so that the user terminal determines whether to perform the startup operation based on the abnormal state.

3. The exception handling method according to claim 1, characterized in that: After formatting the target partition, the method further includes: The formatting information is recorded so that the user terminal calls a preset interface to query the formatting information from the vehicle-mounted terminal, and restores data from the target partition after the formatting information is queried.

4. The exception handling method according to claim 1, characterized in that: The recording of the abnormal information corresponding to the target partition includes: Recording the abnormal information corresponding to the target partition to the raw partition; Correspondingly, before formatting the target partition, the method further includes: querying the raw partition to see whether the abnormal information is recorded.

5. The exception handling method according to claim 1, characterized in that: Also includes: In response to a partition registration operation, a partition corresponding to the partition registration operation is determined as a target partition.

6. The exception handling method according to claim 1, characterized in that: After formatting the target partition, the method further includes: Remount the target partition.

7. The exception handling method according to any one of claims 1 to 6, characterized in that: In response to the startup operation of the vehicle-mounted terminal itself, the method further includes: When the abnormal information is not recorded, mounting the target partition; If the target partition is mounted abnormally, the target partition is formatted so that the user terminal can recover data from the target partition.

8. An exception handling device, characterized in that: Applied to vehicle terminals, including: The file system monitoring module is used to monitor the file system of the target partition; The abnormal information recording module is used to record the abnormal information corresponding to the target partition when the abnormality of the file system is monitored; A startup operation response module, used for responding to the startup operation of the vehicle-mounted terminal itself, and formatting the target partition when the abnormal information is recorded, so that the user terminal can recover the data of the target partition after obtaining the formatting information; The formatting information is information indicating that the target partition has been formatted.

9. An electronic device, characterized in that: comprising a memory and a processor, wherein: The memory is used to store the computer program; The processor is used to execute the computer program to implement the exception handling method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store a computer program, wherein when the computer program is executed by a processor, the exception handling method according to any one of claims 1 to 7 is implemented.

Images