Mounting exception processing method and device, storage medium and vehicle

Abstract

The invention discloses a mounting exception processing method and device, a storage medium and a vehicle, and relates to the technical field of vehicle-mounted machine system control, and the method comprises the steps: responding to the access of a vehicle-mounted host to an external storage device, calculating a load score of vehicle-mounted hardware performance, and determining a mounting duration threshold for executing the mounting process of the external storage device according to the load score; monitoring an external storage device sub-thread, wherein the external storage device sub-thread is used for executing a file system detection task and a mounting task of the external storage device; and if the sub-thread of the external storage device does not complete the file system detection task and the mounting task within the mounting duration threshold value, quitting the mounting process of the external storage device. It is ensured that the main thread is not occupied, the risk of black screen or restart of the system due to external abnormal equipment is fundamentally avoided, and the reliability and fault tolerance of the mounting process are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle infotainment system control technology, and in particular to a method for handling mounting anomalies, a device for handling mounting anomalies, a storage medium, and a vehicle. Background Technology

[0002] In in-vehicle infotainment systems, external devices are primarily managed through file system checks and mounting processes triggered by the main thread, especially USB external storage devices (such as USB flash drives and portable hard drives). For example, after detecting a block device, the vold service in the Android system calls the corresponding file system tools (such as fsck_msdos, mount, etc.) in the main thread to complete the mounting, meeting the needs of vehicle users for quick access to external storage devices. This is a standard technical approach commonly adopted in the industry.

[0003] The specific implementation process is as follows: the vehicle's main unit detects a USB insertion and reports an event (uevent), which is an event message sent by the kernel to user space when the external storage device's state changes (such as insertion / removal, loading / unloading, power state change, attribute modification, etc.). The daemon process (vold) main thread calls the command-line tool (fsck_msdos) to check the file system; the main thread directly executes mount() to mount, that is, user space sends a request to associate the file system of the external storage device with the specified directory (i.e., the mount point).

[0004] In the above implementation, if the external storage device has bad blocks or is abnormal, the `mount()` call will remain unresponsive for an extended period. The system's main thread will be killed by the watchdog mechanism, potentially causing prolonged blocking during file system checks or mounting. This can lead to the mounting process being blocked on the main thread for an extended period, triggering a watchdog restart. Furthermore, since this process runs on the main thread, if the blocking time exceeds the threshold set by the system watchdog, it will result in a black screen on the vehicle's infotainment system and a system restart, severely impacting user experience and vehicle safety. In addition, because bad block USB drives are low-probability, sporadic events, traditional solutions are difficult to reliably reproduce during development and testing, making it difficult for manufacturers to promptly detect and verify the problem. Summary of the Invention

[0005] The purpose of this invention is to provide a mounting anomaly handling method, mounting anomaly handling device, electronic device, storage medium, and vehicle, at least to solve the technical problem of how to avoid long-term blocking during file system checks or mounting processes, and how to avoid vehicle infotainment system black screen and system restart issues.

[0006] This invention provides the following solution:

[0007] According to one aspect of the present invention, a method for handling mounting anomalies is provided, comprising:

[0008] In response to the vehicle host connecting to an external storage device, a load score of the vehicle hardware performance is calculated, and based on the load score, a threshold for the mounting time of the external storage device mounting process is determined.

[0009] A sub-thread for monitoring external storage devices is used to perform file system detection and mounting tasks for the external storage devices.

[0010] If the external storage device sub-thread fails to complete the file system detection task and the mounting task within the mounting time threshold, it will exit the external storage device mounting process.

[0011] Furthermore, the load score for calculating the performance of the vehicle hardware includes:

[0012] Once the vehicle system is confirmed to be running, the vehicle system monitor is started, and the vehicle CPU utilization, hardware data interaction waiting time, and system load index are monitored based on the vehicle system monitor.

[0013] In response to the vehicle host connecting to an external storage device, the load score of the vehicle hardware performance is dynamically calculated based on the current vehicle CPU utilization, hardware data interaction waiting time, and system load index.

[0014] Furthermore, determining the mount time threshold for executing the external storage device mount process based on the load score includes:

[0015] In response to the first connection of the external storage device to the vehicle host, the default baseline time of the vehicle system is obtained, and based on the default baseline time and the load score, the mounting duration threshold for mounting the external storage device is determined;

[0016] or

[0017] In response to the external storage device not being connected to the vehicle host for the first time, the system obtains the historical mounting records of the external storage device, and determines the mounting duration threshold for mounting the external storage device based on the historical mounting records and the load score.

[0018] Furthermore, the sub-thread for monitoring external storage devices includes:

[0019] In response to the vehicle host connecting to an external storage device, the mounting process is initiated, and a sub-thread for the external storage device is created;

[0020] The file system detection and mounting tasks of the external storage device are sent to the sub-thread of the external storage device;

[0021] Based on the external storage device sub-thread, the file system detection task and the mount task are run, and the external storage device sub-thread is monitored.

[0022] Furthermore, if the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes:

[0023] Record the mount logs of the file system detection task and the mount task run by the sub-thread of the external storage device;

[0024] Add a timeout flag to the mount log and store the mount log with the timeout flag in the mount history file corresponding to the external storage device.

[0025] Furthermore, if the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes:

[0026] Based on the attributes of the vehicle system, during the execution of the external storage device mounting process, a delayed mounting duration for the external storage device is set, wherein the delayed mounting duration is greater than the mounting duration threshold.

[0027] Based on the aforementioned delay mounting duration, the execution logic for exiting the external storage device mounting process is verified.

[0028] Furthermore, if the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes:

[0029] If the external storage device sub-thread completes the file system detection task and the mount task within the mount time threshold, the mount result of the external storage device is determined to be successful.

[0030] Update the volume management based on the successful mount result to complete the mount of the external storage device.

[0031] According to a second aspect of the present invention, a mounting anomaly handling device is provided, comprising:

[0032] The mounting time threshold determination module is used to respond to the vehicle host connecting to an external storage device, calculate the load score of the vehicle hardware performance, and determine the mounting time threshold for executing the external storage device mounting process based on the load score.

[0033] The monitoring thread module is used to monitor the external storage device sub-thread, which is used to perform file system detection and mounting tasks for the external storage device.

[0034] The mounting exception handling module is used to exit the external storage device mounting process if the external storage device sub-thread fails to complete the file system detection task and the mounting task within the mounting time threshold.

[0035] According to three aspects of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0036] The memory stores a computer program, which, when executed by the processor, causes the processor to perform the steps of attaching an exception handling method.

[0037] According to four aspects of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device performs the steps of a mounting exception handling method.

[0038] According to five aspects of the present invention, a vehicle is provided, comprising:

[0039] Electronic devices used to implement the steps of mounting anomaly handling methods;

[0040] The processor runs programs, and when the program runs, it executes the steps of the exception handling method based on the data output from the electronic device.

[0041] Storage medium used to store programs that, when running, execute steps of attaching exception handling methods for data output from electronic devices.

[0042] The above solution achieves the following beneficial technical effects:

[0043] This application determines the mounting time threshold for the external storage device mounting process by load scoring the performance of the vehicle hardware. It can flexibly set the upper limit of the mounting process time and dynamically calculate the reasonable timeout time of the mounting operation to ensure the temperature operation of the system.

[0044] This application ensures that the main thread is always responsive to system scheduling by monitoring the file system detection and mounting tasks performed by the external storage device's sub-thread.

[0045] This application ensures that the main thread is not occupied by exiting the external storage device mounting process if the file system detection and mounting tasks are not completed within the mounting time threshold. This fundamentally avoids the risk of system black screen or restart due to external abnormal devices, improves the reliability and fault tolerance of the mounting process, and guarantees that the system remains stable even under abnormal conditions. This effectively improves the stability of the vehicle infotainment system and the user experience. It also minimizes the time required to confirm whether the external storage device has timed out, allowing more time for repair operations and avoiding triggering the watchdog mechanism. Attached Figure Description

[0046] Figure 1 This is a flowchart of a mounting anomaly handling method provided by one or more embodiments of the present invention.

[0047] Figure 2 This is an external storage device mounting execution logic diagram provided in an embodiment of the present invention.

[0048] Figure 3 This is a flowchart of the external storage device mounting system provided in an embodiment of the present invention.

[0049] Figure 4 This is a structural diagram of a mounting anomaly handling device provided in one or more embodiments of the present invention.

[0050] Figure 5 This is a block diagram of an electronic device structure provided by one or more embodiments of the present invention for a method of handling mounting anomalies. Detailed Implementation

[0051] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0052] Figure 1 This is a flowchart of a mounting anomaly handling method provided by one or more embodiments of the present invention.

[0053] like Figure 1 The methods for handling mount anomalies shown include:

[0054] Step S1: In response to the vehicle host connecting to the external storage device, calculate the load score of the vehicle hardware performance, and determine the mounting time threshold for executing the external storage device mounting process based on the load score.

[0055] In this embodiment, after the vehicle system is started, the vehicle system monitor (SysMonitor) is started. The vehicle system monitor can read the vehicle CPU utilization, hardware data interaction (I / O) latency and system load index in real time.

[0056] Specifically, the vehicle's CPU utilization can be determined by reading / proc / stat in real time; the hardware data interaction wait time can be determined by reading the vehicle's system load monitoring ( / proc / loadavg) in real time; and the system load index can be determined by reading the vehicle's disk hardware data interaction status ( / proc / diskstats) in real time.

[0057] If an external storage device is connected to the vehicle's onboard unit, a load score (sys_load_score) is dynamically calculated based on the current onboard CPU utilization, hardware data interaction latency, and system load index. The load score then determines the threshold for the current external storage device mounting process. This means the mounting time threshold can be dynamically determined based on the load score, allowing for flexible configuration of the mounting time threshold parameter to achieve adaptive control of the mounting time threshold in different scenarios. This approach offers advantages such as ease of implementation, low overhead, and high scalability.

[0058] Step S2: Monitor the external storage device sub-thread.

[0059] The external storage device sub-thread is used to perform file system detection tasks (fsck_msdos) and mount tasks (mount) for the external storage device.

[0060] In this embodiment, if an external storage device is detected, the system management service triggers a mounting process. This mounting process can run in a newly created external storage device sub-thread, ensuring that the main thread is not occupied by the external storage device mounting process. This avoids the risk of the in-vehicle system experiencing a black screen or restart due to an abnormal external storage device. Executing the file system detection and mounting tasks of the external storage device through the external storage device sub-thread also improves the reliability and fault tolerance of the mounting process, and ensures that the system maintains a stable response even under abnormal conditions, thereby effectively improving the stability of the in-vehicle system and the user experience.

[0061] The main thread is responsible for thread scheduling and state monitoring, thereby preventing the main thread from being blocked by I / O.

[0062] In this embodiment, file system detection and mounting tasks for external storage devices can also be performed by forking an independent child process or calling a daemon process, and the forked independent child process or daemon process performing the file system detection and mounting tasks can be monitored based on the mounting duration threshold.

[0063] Step S3: If the external storage device sub-thread fails to complete the file system detection and mounting tasks within the mounting time threshold, the external storage device mounting process will exit.

[0064] In this embodiment, fsck_msdos or other corresponding file system checking tools (such as fsck_msdos) are called inside the external storage device sub-thread, and the execution process of the external storage device sub-thread is monitored through a timeout control mechanism (i.e., based on the mount duration threshold).

[0065] Furthermore, timeout control employs a polling method, using `pollfd` to monitor the output pipe of the external storage device sub-thread. If the external storage device sub-thread fails to complete the file system check and mount tasks within the mount duration threshold, the external storage device mount is deemed to have failed, and the mount process exits. In other words, if the external storage device sub-thread remains unresponsive after the set mount duration threshold, a forced exit logic is triggered, immediately terminating the external storage device sub-thread and related processes, and returning the mount failure result to the main thread. Alternatively, the main thread can be notified of the status of the external storage device sub-thread and related processes via kernel or system signals. Upon determining that the external storage device sub-thread has timed out, the main thread can forcibly terminate the file system check and mount tasks performed by the external storage device sub-thread.

[0066] I / O timeout and interrupt mechanisms can also be added at the USB controller firmware or driver level, specifically by adding an interrupt mechanism for the external storage device sub-thread at the USB controller firmware or driver level. Furthermore, if the external storage device sub-thread fails to complete the file system detection and mounting tasks within the mount duration threshold, the external storage device sub-thread interrupt mechanism at the USB controller firmware or driver level can be used to interrupt the external storage device sub-thread, thus avoiding prolonged blocking.

[0067] In the event of a timeout or mounting failure, the main thread automatically ignores the abnormal device and continues to operate normally, preventing the vehicle system from triggering the Watchdog mechanism.

[0068] If the external storage device sub-thread completes the file system check and mount tasks within the mount duration threshold, confirms that the external storage device is successfully mounted, and displays the successful mount result, it updates the volume management based on the successful mount result, completes the external storage device mount, and sends the successful mount result back to the main thread.

[0069] By using the mounting anomaly handling method provided in this embodiment, a mounting time threshold for the external storage device mounting process is set, and a sub-thread for the external storage device is created to ensure that the main thread is not occupied. This ensures that the system can still run stably under extreme conditions, avoids the vehicle's infotainment system from going black or restarting, and thus significantly improves the system's stability and user experience.

[0070] The mount duration threshold can also be determined by combining load scoring and historical access data of external storage devices.

[0071] In one implementation, if the external storage device is connected to the vehicle host for the first time, the default baseline time of the vehicle system (e.g., 15 seconds) is obtained, and based on the default baseline time and load score, a threshold for the mounting duration of the external storage device is determined.

[0072] In another implementation, if the external storage device is not being connected to the vehicle host for the first time, the historical mounting records of the external storage device are obtained, and based on the historical mounting records and load scores, the mounting duration threshold for mounting the external storage device is determined.

[0073] Furthermore, historical mount records can be queried from the mount history file (mount_history.json) by calling the HistoryStore module to find the average mount time corresponding to the external storage device. Based on the average mount time and the current load score of the vehicle system, a mount duration threshold for mounting the external storage device can be determined. The average mount time is updated after each mount. External storage devices can be identified using the key component VID (VendorID) and PID (Product ID), or they can be identified using a Universally Unique Identifier (UUID).

[0074] For example, the system adaptively adjusts the mounting time threshold based on the current hardware performance and historical mounting records during each mounting process. When the system is detected to be in a high-load or low-speed USB device environment, the timeout limit is automatically extended, while the waiting time is shortened in an idle state or high-speed device environment.

[0075] In this embodiment, the process of monitoring the external storage device sub-thread also includes creating the external storage device sub-thread.

[0076] Furthermore, if the vehicle-mounted host connects to an external storage device, the mounting process is initiated, creating a sub-thread for the external storage device. The file system detection and mounting tasks for the external storage device are then distributed to the external storage device sub-thread. Based on the external storage device sub-thread, the file system detection and mounting tasks are run, and the external storage device sub-thread is monitored.

[0077] This embodiment introduces an external storage device sub-thread into the mounting process, thereby executing file system detection and mounting tasks through the external storage device sub-thread. If the task is not completed within a preset time, it will be forcibly terminated, ensuring that the main thread is not occupied. This fundamentally avoids the risk of the system going black or restarting due to abnormal external devices, and enhances the reliability of the vehicle's electronic system and the user experience.

[0078] If the external storage device sub-thread fails to complete the file system check and mount tasks within the mount duration threshold, interrupts the main thread's wait, forcibly exits the external storage device mount process, and reclaims the created external storage device sub-thread, the `gettimeofday()` function can be used to record the mount logs of the external storage device sub-thread's file system check and mount tasks. A timeout flag is added to the mount logs, and mount logs with timeout flags are stored in the mount history file corresponding to the external storage device. The mount logs in the mount history file can also be reported to `HistoryStore::update()`, forming a self-learning loop. This ensures that the system continues to run without triggering the watchdog timer. Under normal circumstances, if the external storage device sub-thread successfully completes its tasks, the mount result of the external storage device will be reported to the main thread to complete volume management.

[0079] For example, Figure 2 This is a diagram illustrating the external storage device mounting execution logic provided in an embodiment of the present invention. Figure 3 This is a flowchart illustrating the execution of an external storage device mounting system according to an embodiment of the present invention. Figure 2 and Figure 3 As shown,

[0080] When an external storage device is inserted into the vehicle's infotainment system kernel, the kernel sends a uevent event to the main thread. Upon receiving the mount request, the main thread immediately creates a child thread (the external storage device child thread) to execute the fsck / mount operation. The main thread communicates with the child thread via a pipe and uses poll() to implement a timeout. If the child thread completes the mount within the set time (a dynamically calculated mount duration threshold), the main thread reads the result, updates the volume management, and completes the mount. If no response is received within the timeout period, the main thread actively terminates the wait and logs the event. If forced termination fails, the main thread ignores the external storage device and continues system operation.

[0081] In this embodiment, to facilitate verification and testing of the provided mount anomaly handling method, a delayed mount duration for the external storage device can be set based on the vehicle system's attributes during the external storage device mount process. This delayed mount duration is greater than a mount duration threshold. Specifically, a sleep delay is inserted into the Vfat.cpp mount logic, or an artificial delay is injected through vehicle system attributes to simulate a disk failure scenario. This allows for verification of the execution logic for exiting the external storage device mount process and the effectiveness of the timeout logic based on the delayed mount duration. This implementation not only ensures safe exit under abnormal conditions but also possesses good scalability and is applicable to various file systems such as vfat, exFAT, and ext4.

[0082] By implementing the external storage device sub-thread isolation mechanism and the timeout control mechanism with a mount duration threshold, the main thread remains available even under extreme conditions such as repeated insertion and removal of bad block USB drives, preventing the vehicle's infotainment system from blacking out or restarting, thus significantly improving system stability and user experience. The mount timeout is dynamically configured through system properties (such as `persist.sys.vold.fsck_delay_ms`), injecting controllable delays for adaptation in different environments and reproducible verification of bad block scenarios, thereby improving testing efficiency for mount anomaly handling. Specifically, the dynamic configuration of the mount timeout through system properties can be integrated into the `Mount()` function logic layer in the `Vfat.cpp` file, achieving mount fault tolerance through thread decoupling and time-based adjudication mechanisms, preventing main thread blocking and abnormal system restarts.

[0083] In this embodiment, the mounting time limit can also be set separately for each step of fsck and mount, so as to control the execution of the external storage device mounting process more finely, ensure that the mounting process has a time limit, and avoid the risk of the vehicle system going black or restarting due to abnormal external devices.

[0084] Figure 4 This is a structural diagram of a mounting anomaly handling device provided in one or more embodiments of the present invention.

[0085] like Figure 4 The mounting anomaly handling device shown includes: a mounting duration threshold determination module, a monitoring thread module, and a mounting anomaly handling module.

[0086] The mounting time threshold determination module is used to respond to the vehicle host connecting to an external storage device, calculate the load score of the vehicle hardware performance, and determine the mounting time threshold for executing the external storage device mounting process based on the load score.

[0087] The monitoring thread module is used to monitor the external storage device sub-thread, which is used to perform file system detection and mounting tasks for the external storage device.

[0088] The mounting exception handling module is used to exit the external storage device mounting process if the external storage device sub-thread fails to complete the file system detection and mounting tasks within the mounting time threshold.

[0089] The mounting duration threshold determination module is used to determine the start of the vehicle system, start the vehicle system monitor, and monitor the vehicle CPU utilization, hardware data interaction waiting time, and system load index based on the vehicle system monitor; in response to the vehicle host connecting to the external storage device, it dynamically calculates the load score of the vehicle hardware performance based on the current vehicle CPU utilization, hardware data interaction waiting time, and system load index.

[0090] In response to the first connection of an external storage device to the vehicle host, the system obtains the default baseline time of the vehicle system and determines the threshold for the mounting duration of the external storage device based on the default baseline time and load score.

[0091] or

[0092] In response to an external storage device being connected to the vehicle host for the first time, the system obtains the historical mounting records of the external storage device and determines the mounting duration threshold based on the historical mounting records and load score.

[0093] The monitoring thread module is used to respond to the on-board host connecting to an external storage device, start the mounting process, and create an external storage device sub-thread; distribute the file system detection task and mounting task of the external storage device to the external storage device sub-thread; run the file system detection task and mounting task based on the external storage device sub-thread, and monitor the external storage device sub-thread.

[0094] The mount exception handling module is used to record the mount logs of the file system detection and mount tasks run by the sub-thread of the external storage device; add timeout flags to the mount logs, and store the mount logs with timeout flags in the mount history file corresponding to the external storage device.

[0095] The mounting exception handling module is also used to set a delayed mounting duration for external storage devices during the external storage device mounting process based on the attributes of the vehicle system. The delayed mounting duration is greater than the mounting duration threshold. Based on the delayed mounting duration, the execution logic for exiting the external storage device mounting process is checked.

[0096] The mount exception handling module is also used for external storage device sub-threads to complete file system detection and mount tasks within the mount duration threshold, determine the successful mount result of the external storage device, update volume management based on the successful mount result, and complete the mount of the external storage device.

[0097] Figure 5 This is a block diagram of an electronic device structure provided by one or more embodiments of the present invention for a method of handling mounting anomalies.

[0098] like Figure 5 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0099] The memory stores a computer program, which, when executed by the processor, causes the processor to perform steps of attaching an exception handling method.

[0100] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform steps of a loading exception handling method.

[0101] This application also provides a vehicle, including:

[0102] Electronic equipment used to implement steps based on a mount-based exception handling method;

[0103] The processor runs programs, and when the program runs, it executes the steps of the exception handling method based on the data output from the electronic device.

[0104] Storage medium used to store programs that, when running, execute steps of attaching exception handling methods for data output from electronic devices.

[0105] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0106] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0107] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0108] Electronic devices can also obtain reset commands corresponding to storage media. These reset commands are provided by the supplier, and the reset commands for different storage media can be the same or different, which is not limited here.

[0109] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0110] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0111] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0112] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0113] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0114] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for handling mounting anomalies, characterized in that, The mounting anomaly handling method includes: In response to the vehicle host connecting to an external storage device, a load score of the vehicle hardware performance is calculated, and based on the load score, a threshold for the mounting time of the external storage device mounting process is determined. A sub-thread for monitoring external storage devices is used to perform file system detection and mounting tasks for the external storage devices. If the external storage device sub-thread fails to complete the file system detection task and the mounting task within the mounting time threshold, it will exit the external storage device mounting process.

2. The mounting anomaly handling method according to claim 1, characterized in that, The load score for calculating the performance of the vehicle hardware includes: Once the vehicle system is confirmed to be running, the vehicle system monitor is started, and the vehicle CPU utilization, hardware data interaction waiting time, and system load index are monitored based on the vehicle system monitor. In response to the vehicle host connecting to an external storage device, the load score of the vehicle hardware performance is dynamically calculated based on the current vehicle CPU utilization, hardware data interaction waiting time, and system load index.

3. The mounting anomaly handling method according to claim 2, characterized in that, The step of determining the mount time threshold for executing the external storage device mount process based on the load score includes: In response to the first connection of the external storage device to the vehicle host, the default baseline time of the vehicle system is obtained, and based on the default baseline time and the load score, the mounting duration threshold for mounting the external storage device is determined; or In response to the external storage device not being connected to the vehicle host for the first time, the system obtains the historical mounting records of the external storage device, and determines the mounting duration threshold for mounting the external storage device based on the historical mounting records and the load score.

4. The mounting anomaly handling method according to claim 1, characterized in that, The sub-thread for monitoring external storage devices includes: In response to the vehicle host connecting to an external storage device, the mounting process is initiated, and a sub-thread for the external storage device is created; The file system detection and mounting tasks of the external storage device are sent to the sub-thread of the external storage device; Based on the external storage device sub-thread, the file system detection task and the mount task are run, and the external storage device sub-thread is monitored.

5. The mounting anomaly handling method according to claim 1, characterized in that, If the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes: Record the mount logs of the file system detection task and the mount task run by the sub-thread of the external storage device; Add a timeout flag to the mount log and store the mount log with the timeout flag in the mount history file corresponding to the external storage device.

6. The mounting anomaly handling method according to claim 1, characterized in that, If the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes: Based on the attributes of the vehicle system, during the execution of the external storage device mounting process, a delayed mounting duration for the external storage device is set, wherein the delayed mounting duration is greater than the mounting duration threshold. Based on the aforementioned delay mounting duration, the execution logic for exiting the external storage device mounting process is verified.

7. The mounting anomaly handling method according to claim 1, characterized in that, If the external storage device sub-thread fails to complete the file system detection task and the mount task within the mount duration threshold, and exits the external storage device mount process, the method further includes: If the external storage device sub-thread completes the file system detection task and the mount task within the mount time threshold, the mount result of the external storage device is determined to be successful. Update the volume management based on the successful mount result to complete the mount of the external storage device.

8. A mounting anomaly handling device, characterized in that, The mounting anomaly handling device includes: The mounting time threshold determination module is used to respond to the vehicle host connecting to an external storage device, calculate the load score of the vehicle hardware performance, and determine the mounting time threshold for executing the external storage device mounting process based on the load score. The monitoring thread module is used to monitor the external storage device sub-thread, which is used to perform file system detection and mounting tasks for the external storage device. The mounting exception handling module is used to exit the external storage device mounting process if the external storage device sub-thread fails to complete the file system detection task and the mounting task within the mounting time threshold.

9. A computer-readable storage medium, characterized in that, The device stores a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the mounting exception handling method as described in any one of claims 1 to 6.

10. A vehicle, characterized in that, include: An electronic device for implementing the steps of the mounting anomaly handling method as described in any one of claims 1 to 7; A processor that runs a program that, when the program is running, performs the steps of the mounting exception handling method as described in any one of claims 1 to 7 from data output by the electronic device. A storage medium for storing a program that, when running, performs the steps of the mounting exception handling method as described in any one of claims 1 to 7 on data output from an electronic device.

Images