Disk management methods, devices, vehicle operating systems, media and products

Abstract

This invention relates to the field of system management technology, and discloses disk management methods, devices, vehicle operating systems, media, and products. This invention monitors hot-plug event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. It first locks the volume manager's global lock. When the storage device type for the hot-plug event request is identified as an external storage device, the global lock is released in advance, and the external storage device manager executes the hot-plug event request under the protection of a private lock, preventing the system from triggering a black screen restart due to global lock timeout. By combining the device access time when the external storage device executes the hot-plug event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the architecture of built-in storage and external storage services, ensures stable execution of external storage device hot-plug events, and improves system reliability.

Description

Technical Field

[0001] This invention relates to the field of system management technology, specifically to disk management methods, devices, vehicle operating systems, media, and products. Background Technology

[0002] With the increasing intelligence of automobiles, internal and external storage devices have become core components for storing in-vehicle music, video playback, and driving record data. The system uses a Volume Daemon (Vold) to achieve unified management of disk devices. The VolumeManager in the Volold is responsible for handling the mounting and unmounting of internal and external storage devices. A single-threaded global lock mechanism ensures the security of shared resources under concurrent multi-threaded access. When a user plugs or unplugs an external storage device, the corresponding thread holds the global lock, and other processes must wait for the lock to be released before continuing their operations.

[0003] However, when external storage devices suffer from media damage, file system abnormalities, or application resources not being released, operations such as disk metadata reading, file system detection, and unloading resource reclamation may be blocked for a long time. This causes the Volume global lock to be held by the current thread for an extended period. When the system detects the process blockage, it may trigger serious anomalies such as system black screen and restart, which greatly affects the stability of the vehicle system and the user experience.

[0004] Existing disk management optimization methods shorten the operation time of external storage devices and reduce the holding time of volume global locks by retrieving resource-consuming processes and triggering circuit breakers when processes time out. However, this method only terminates the operation when a timeout is detected, causing operations on external storage devices to be unable to continue, which affects the user experience and cannot fundamentally solve the problem of system crashes and restarts caused by external storage device malfunctions. Summary of the Invention

[0005] This invention provides a disk management method, device, vehicle operating system, medium, and product to solve the problem that existing technologies use timeout circuit breakers to terminate device operations in order to reduce the global lock holding time, resulting in the inability to continue performing corresponding operations on external storage devices.

[0006] In a first aspect, the present invention provides a disk management method applied to an in-vehicle infotainment system. The system includes a kernel storage device driver, and its process space includes a volume daemon process. The volume daemon process includes a volume manager and an external storage device manager that run independently in parallel. The method includes: Use the kernel storage device driver to listen for hot-plug event requests from storage devices; Send the hot-plug event request to the volume manager, lock the volume manager's global lock, and determine the storage device type corresponding to the hot-plug event request; When the storage device type is detected as an external storage device, the global lock is released, a hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed. Based on device access time and the blocking state of the kernel storage device driver, adjust the execution process of the external storage device manager for hot-plug event requests.

[0007] This invention monitors hot-plug event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. It first locks the volume manager's global lock. When the storage device type for the hot-plug event request is identified as an external storage device, the global lock is released in advance. The external storage device manager then executes the hot-plug event request under the protection of a private lock mechanism. This prevents time-consuming operations of the external storage device from occupying the global lock for extended periods, thus preventing system black screen restarts due to global lock timeouts. By combining the device access time during the execution of the hot-plug event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the architecture of internal and external storage services, ensures stable execution of external storage device hot-plug events, and improves system reliability.

[0008] In some optional implementations, the execution process of the external storage device manager for hot-plug event requests is adjusted based on device access time and the blocking state of the kernel storage device driver, including: Determine whether the device access time exceeds the device access time threshold; If the device access time exceeds the device access time threshold, based on the blocking state of the kernel storage device driver, the execution state of the external storage device manager for hot-plug event requests is reset until the hot-plug event requests are completed, at which point the private lock is released.

[0009] This invention, when device access time exceeds a threshold, determines the blocking state of the kernel storage device driver and adaptively resets the execution state of the external storage device manager for hot-plug event requests based on this blocking state. This avoids non-blocking, normal time-consuming operations being mistakenly identified as faults and interrupting the process, and also enables abnormal recovery from hardware-level blocking. Stable execution of hot-plug event requests can be restored without manual unplugging or plugging of external storage devices or a system restart. After the hot-plug event request is completed, the private lock is released, without occupying the system's global lock throughout the process, thus not affecting the core business operation of the vehicle system and avoiding system crashes and restarts caused by external storage device malfunctions, thereby improving system stability.

[0010] In some alternative implementations, based on the blocking state of the kernel storage device driver, the execution state of the external storage device manager for hot-plug event requests is reset, including: Determine if the kernel storage device driver is blocked; If the kernel storage device driver is not blocked, reset the device access timeout and control the external storage device manager to continue executing hot-plug event requests; If the kernel storage device driver is blocked, perform a hardware reset on the external storage device and return to the step of sending a hot-plug event request to the external storage device manager.

[0011] When the kernel storage device driver is not blocked, this invention only resets the device access time and continues to execute the hot-plug event request, avoiding the normal time-consuming operation being misjudged as a fault and interrupting the process. When the kernel storage device driver experiences hardware-level blocking, it performs a hardware reset on the external storage device and resends the hot-plug event, achieving abnormal recovery without requiring the user to plug or unplug the device or the system to restart. This solves the problem of system blackout and restart caused by external storage device abnormalities, and does not occupy the global lock throughout the process, does not affect the operation of the vehicle's core business, and improves the operational stability of the vehicle system.

[0012] In some optional implementations, the hot-plug event request includes multiple sub-operations for the external storage device, and the device access time is the duration corresponding to each sub-operation; the kernel storage device driver records the wait-to-complete flag bit when the external storage device manager starts executing each sub-operation, and updates the status of the wait-to-complete flag bit after the sub-operation is completed. Determining whether a kernel storage device driver is blocked includes: Send a diagnostic request to the kernel storage device driver so that the kernel storage device driver can check the status of the wait-to-complete flag. If the wait-to-complete flag is not in a waiting state, it is determined that the kernel storage device driver is not blocked. If the wait-to-complete flag is in a waiting state, it is determined that the kernel storage device driver is blocked.

[0013] This invention determines whether the kernel storage device driver is in a normal, non-waiting state or a hardware-stuck, blocked state by sending diagnostic requests to the kernel storage device driver and detecting the status of the waiting completion flag. This enables accurate determination of the kernel storage device driver's blocking state, providing a reliable basis for the adaptive adjustment and abnormal recovery of the subsequent hot-plug event execution process, and improving the accuracy and operational stability of the vehicle's operating system in monitoring storage device anomalies.

[0014] In some optional implementations, the execution process of the external storage device manager for hot-plug event requests is adjusted based on device access time and the blocking state of the kernel storage device driver. The method further includes: If the device access time does not exceed the device access time threshold, control the external storage device manager to continue executing the hot-plug event request, and release the private lock after the hot-plug event request is completed.

[0015] This invention determines that the external storage device hot-plug operation is running normally when the device access time does not exceed the device access time threshold, and the external storage device manager continues to execute the process, ensuring the continuity of hot-plug event request execution and avoiding process interruption that affects user experience. Furthermore, the hot-plug event request is executed under the protection of a private lock. The private lock is released promptly after the hot-plug event request is completed, ensuring mutual exclusion of external storage business resources and data consistency. At the same time, it does not occupy the system's global lock, thus avoiding triggering a global lock timeout restart and not affecting the operation of the vehicle's core business, thereby improving the overall stability of the vehicle's infotainment system.

[0016] In some alternative implementations, the hot-plug event request includes an insertion event request; controlling the external storage device manager to execute the hot-plug event request includes: Creates the first child process corresponding to the main process of the external storage device manager; The first child process executes the insertion event request for the external storage device. After the insertion event request is completed, the main process is controlled to mount the external storage device.

[0017] This invention creates a first child process of the external storage device manager main process, and delegates the insertion event request of the external storage device to the first child process for asynchronous execution. After the first child process completes the insertion event request, the main process performs the mounting operation of the external storage device. This decouples and isolates the time-consuming operation of executing the insertion event request from the main process, and avoids the external storage device abnormally blocking the main process.

[0018] In some optional implementations, a first child process executes an insertion event request for an external storage device. After the insertion event request is completed, the main process is controlled to mount the external storage device, including: The first child process performs disk information reading operations on the external storage device, and sends a first completion signal to the main process after the disk information reading operation is completed. If the main process receives the first completion signal within the first preset time period, the first child process performs a file system repair operation on the external storage device, and sends a second completion signal to the main process after the file system repair operation is completed. If the main process receives a second completion signal within the second preset time period, it controls the main process to mount the external storage device.

[0019] This invention isolates the potentially blocking and time-consuming disk operations from the main process by asynchronously executing disk information reading and file system repair operations on the external storage device through a first child process. This prevents the main process from freezing due to external storage device malfunctions and prevents the first child process from blocking indefinitely by setting a preset timeout. The main process performs the mounting operation under the protection of a private lock, without needing to occupy a global lock, thus avoiding system crashes and restarts caused by global lock timeouts and improving the stability of the external storage device mounting process.

[0020] In some optional implementations, the hot-plug event request includes a pull-out event request; controlling the external storage device manager to execute the hot-plug event request includes: Create a second child process corresponding to the main process of the external storage device manager; The second child process is controlled to execute the unplug event request of the external storage device in a multi-threaded manner. After the unplug event request is completed, the main process is controlled to unload the external storage device.

[0021] This invention creates a second child process corresponding to the main process of the external storage device manager to asynchronously execute the unplug event request for the external storage device, isolating time-consuming operations such as resource querying and release to the second child process. It also employs a multi-threaded approach to quickly locate the process occupying the unreleased resource, improving resource retrieval efficiency and effectively shortening the unloading process time. The main process then performs the unloading operation after the unplug event request has been completed. Thus, the unplug event request is executed asynchronously under the protection of a private lock, without needing to hold the system global lock throughout the process. This avoids system crashes and restarts caused by prolonged global lock holding, improving system reliability.

[0022] In some optional implementations, the control of the second child process executes the unplugging event request of the external storage device in a multi-threaded manner. After the unplugging event request is completed, the control of the main process unloads the external storage device, including: Create multiple child threads corresponding to the second child process; Multiple sub-threads are used to query the file information occupied by each process in the process space in parallel. Based on the file information, the unreleased resources of the external storage device are determined, and the process occupying the unreleased resources is determined. Send a resource release signal to the occupying process, and control the main process to unload the external storage device after all the unreleased resources on the external storage device have been released.

[0023] This invention creates multiple sub-threads corresponding to a second sub-process, enabling parallel queries of the process space and quickly locating the process occupying unreleased resources. By sending a resource release signal to the occupying process and controlling the main process to perform the unloading operation only after the resources are fully released, the unloading efficiency when removing external storage devices is improved. Furthermore, the asynchronous execution of the unloading time request under the protection of a private lock avoids system crashes and restarts caused by global lock occupancy, thus improving system stability.

[0024] In some alternative implementations, the method further includes: Listen for storage device operation requests from the vehicle's infotainment system operating system; these storage device operation requests are storage device-related operation requests initiated by the application layer or system layer to the volume daemon process. Send the storage device operation request to the volume manager, lock the global lock corresponding to the volume manager, and determine the storage device type corresponding to the storage device operation request; If the storage device type is detected as an external storage device, the global lock is released, the storage device operation request is sent to the external storage device manager, the private lock corresponding to the external storage device manager is locked, the external storage device manager is controlled to execute the storage device operation request, and the private lock is released after the storage device operation request is completed.

[0025] This invention continuously monitors storage device operation requests initiated by the vehicle infotainment system's application layer and system layer, and sends them to the volume manager natively managed by the volume daemon process, first locking the volume manager's global lock. When a storage device operation request is identified as related to an external storage device, the global lock is released in advance, and the external storage device manager executes a hot-plug event request under the protection mechanism of a private lock. This achieves architectural decoupling between internal and external storage services, avoids time-consuming operations of external storage devices from occupying the global lock for extended periods, and prevents the system from triggering a black screen restart failure due to global lock timeout.

[0026] In some alternative implementations, the method further includes: If the storage device type is detected as an internal storage device, the volume manager is controlled to execute a hot-plug event request. After the hot-plug event request is completed, the global lock is released.

[0027] If the present invention detects a hot-plug event request for the built-in storage device, it executes the hot-plug event request using the native volume manager and protects it with a global lock to ensure data access consistency of the built-in storage operation, thereby achieving decoupling of hot-plug events between internal and external storage devices.

[0028] Secondly, the present invention provides a disk management device applied to an in-vehicle infotainment system. The system includes a kernel storage device driver, and the system's process space includes a volume daemon process. The volume daemon process includes a volume manager and an external storage device manager that run independently in parallel. The device includes: The first processing module is used to listen for hot-plug event requests from storage devices using the kernel storage device driver. The second processing module is used to send the hot-plug event request to the volume manager, lock the global lock of the volume manager, and determine the storage device type corresponding to the hot-plug event request. The third processing module is used to release the global lock when the storage device type is detected as an external storage device, send the hot-plug event request to the external storage device manager, lock the private lock of the external storage device manager, control the external storage device manager to execute the hot-plug event request, and determine the device access time corresponding to the external storage device when executing the hot-plug event request. The fourth processing module is used to adjust the execution process of the external storage device manager for hot-plug event requests based on the device access time and the blocking state of the kernel storage device driver.

[0029] Thirdly, this invention provides an in-vehicle operating system, the system including a controller and a kernel storage device driver, the system's process space including a volume daemon, the volume daemon including a volume manager and an external storage device manager running in parallel and independently; the controller includes: The memory and the processor are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the disk management method of the first aspect or any of its corresponding embodiments.

[0030] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the disk management method of the first aspect or any corresponding embodiment thereof.

[0031] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the disk management method of the first aspect or any corresponding embodiment thereof.

[0032] The beneficial effects of this invention are as follows: This invention monitors hot-plug event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. It first locks the volume manager's global lock. When the storage device type for the hot-plug event request is identified as an external storage device, the global lock is released in advance. The external storage device manager then executes the hot-plug event request under the protection of a private lock mechanism. This prevents time-consuming operations of the external storage device from occupying the global lock for extended periods, thus preventing system black screen restarts due to global lock timeouts. By combining the device access time during the execution of the hot-plug event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the architecture of internal and external storage services, ensures stable execution of external storage device hot-plug events, and improves system reliability. Attached Figure Description

[0033] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0034] Figure 1 This is a structural block diagram of the vehicle operating system according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a first type of disk management method according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a second process of a disk management method according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating the process of mounting an external storage device according to an embodiment of the present invention; Figure 5 This is a schematic diagram of the third process of the disk management method according to an embodiment of the present invention; Figure 6 This is a schematic diagram of the process of unloading an external storage device according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the process of executing a storage device operation request according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the fourth process of the disk management method according to an embodiment of the present invention; Figure 9 This is a schematic diagram of the process of resetting the execution state of a hot-plug event request according to an embodiment of the present invention; Figure 10A This is a schematic diagram of the original flow of the volume daemon process according to an embodiment of the present invention; Figure 10B This is a fifth flowchart illustrating the disk management method according to an embodiment of the present invention; Figure 11 This is a schematic diagram of a disk management architecture according to an embodiment of the present invention; Figure 12 This is a comparative diagram of the disk management process according to an embodiment of the present invention; Figure 13 This is a structural block diagram of a disk management device according to an embodiment of the present invention; Figure 14 This is a schematic diagram of the hardware structure of the controller according to an embodiment of the present invention. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. 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.

[0036] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0037] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0038] With the increasing intelligence of automobiles, the use of internal and external storage devices is becoming more and more common, such as built-in DVRs and USB music playback. However, when external storage devices are plugged in or removed, or when there are malfunctions, the in-vehicle infotainment system may experience issues such as lag or black screens. Further analysis of the Android disk management service reveals that it essentially uses a single-threaded global volume lock mechanism. This means that when a user plugs in or removes an external storage device, the corresponding thread holds the global volume lock, and other processes must wait for the lock to be released before continuing their operations. This mechanism fails to consider scenarios such as damaged external storage devices, file system errors, and the time required for plugging and unplugging, significantly increasing the risk of lag, black screens, and restarts during the use of Android in-vehicle infotainment systems.

[0039] Related technologies optimize disk management services by detecting file systems, retrieving resource-consuming processes, and implementing timeout circuit breakers to reduce processing time when external storage devices are inserted, thus preventing the user interface from freezing when an external storage device is plugged into a vehicle. However, these methods do not fundamentally solve the problem of system freezing and restarting due to external storage device malfunctions. They only terminate the operation when a timeout is detected, preventing further operation on the external storage device and impacting the user experience.

[0040] To address the issue of system crashes and restarts caused by external storage device malfunctions or USB driver failures in in-vehicle operating systems, this invention provides a disk management method. This method monitors hot-plug event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. The global lock of the volume manager is locked initially. Upon identifying an external storage device as the source of the hot-plug event request, the global lock is released prematurely, and the external storage device manager executes the hot-plug event request under a private lock protection mechanism. This prevents time-consuming operations by the external storage device from occupying the global lock for extended periods, thus preventing system crashes and restarts due to global lock timeouts. By combining the device access time during the execution of the hot-plug event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the internal and external storage architectures, ensures stable execution of external storage device hot-plug events, and improves system reliability.

[0041] According to embodiments of the present invention, a vehicle infotainment operating system is provided, such as... Figure 1 As shown, the vehicle infotainment system includes a controller 101 and a kernel storage device driver 102 (USB Driver). The system's process space includes a volume daemon, which comprises a volume manager and an external storage device manager that run independently in parallel. Specifically, the controller 101 is used for: Use kernel storage device driver 102 to listen for hot-plug event requests from storage devices; Send the hot-plug event request to the volume manager, lock the volume manager's global lock, and determine the storage device type corresponding to the hot-plug event request; When the storage device type is detected as an external storage device, the global lock is released, a hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed. Based on the device access time and the blocking state of kernel storage device driver 102, adjust the execution process of external storage device manager for hot-plug event requests.

[0042] It should be noted that Vold is the volume daemon process of the vehicle's infotainment system, used to manage all storage devices within the system. In this embodiment, the Vold process provides sub-modules such as VolumeManager, VolumeManagerExt, VolumeNativeService, NetLinkManager, and VolumeExtMonitor. The infotainment system also provides StorageManager, which provides upper-layer applications (APPs) with interfaces for querying, mounting, and unmounting storage devices. It can also issue storage device operation requests via cross-process calls to VolumeNativeService through Binder.

[0043] Specifically, VoldNativeService is the Binder cross-process communication service provided by Vold. It receives storage device operation requests initiated by the application layer or system layer, including but not limited to Binder requests initiated by the upper-layer vehicle infotainment app and StorageManager, such as mounting, unmounting, formatting, and status queries, and forwards the requests to VolumeManager. Kernel storage device driver 102 can be a kernel USB driver, which may include the kernel USB driver submodule USBMonitor. USBMonitor provides a bidirectional interaction framework between kernel and user space, diagnostic protocol support, and other capabilities. NetLinkManager is used to receive hot-plug events, status change events, and abnormal events of storage devices reported by the kernel storage device driver and forward them to VolumeManager.

[0044] In this embodiment of the invention, the VolumeManager is a native management submodule of Vold. It receives kernel hot-plug events forwarded by NetLinkManager and upper-layer business requests (such as storage device operation requests from the application layer APP or system layer) issued by VoldNativeService. It also maintains a native global lock, vmlock, which is monitored by the system watchdog. Vold's native VolumeManager is used for disk management of the built-in storage devices. For requests related to external storage devices, only brief locking and request forwarding are performed; no disk management is performed on the external storage devices.

[0045] This embodiment adds a VolumeManagerExt within the Vold module to manage external storage devices (such as USB drives and TF cards). It does not occupy Vold's native global lock (vm lock), but instead utilizes its own private lock (vm_ext lock) to perform operations on external storage devices. This isolates time-consuming or abnormal operations related to external storage devices, without affecting the internal storage devices and the system's global lock (vm lock). Even if external storage device or kernel USB driver malfunctions, the global lock (vm lock) will not time out, fundamentally resolving the issue of the vehicle's operating system freezing and restarting due to global lock (vm lock) timeout.

[0046] In this embodiment of the invention, VolumeExtMonitor and USBMonitor establish a bidirectional communication channel. VolumeExtMonitor sends diagnostic requests to USBMonitor to determine whether the kernel USB driver is in a blocked state, thereby identifying kernel USB driver anomalies. It also monitors the device access time of VolumeManagerExt to identify external storage device anomalies. Upon identifying both external storage device and kernel USB driver anomalies, it performs anomaly recovery. This allows for continued operation on external storage devices without requiring a restart of the vehicle's operating system or the user to re-plug the external storage device, thus improving the user experience.

[0047] For a detailed description of the specific principles and working process of the controller 101, please refer to the following method embodiment, which will not be repeated here.

[0048] According to an embodiment of the present invention, a disk management method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0049] This embodiment provides a disk management method that can be used for, for example Figure 1 The in-vehicle operating system shown is such as Android. Figure 2 This is a flowchart of a disk management method according to an embodiment of the present invention, such as... Figure 2 As shown, the process includes the following steps: Step S201: Use the kernel storage device driver to listen for hot-plug event requests from the storage device.

[0050] Specifically, when the vehicle's operating system starts, the Vold volume daemon initializes each submodule. First, it calls the Vold native volume manager's interface `VolumeManager.start` to initialize the VolumeManager. Second, it calls the external storage device manager's interface `VolumeManagerExt.start` to initialize the newly added `VolumeManagerExt` for managing external storage devices. Then, it calls `VoldNativeService.start` to initialize the `VoldNativeService`, providing Vold with external communication capabilities. Finally, it calls `NetLinkManager.start` to initialize the NetLinkManager, using NetLink to listen for hot-plug events reported by the kernel storage device driver, such as storage device insertion, removal, and status changes.

[0051] Step S202: Send the hot-plug event request to the volume manager, lock the global lock of the volume manager, and determine the storage device type corresponding to the hot-plug event request.

[0052] Specifically, after the kernel storage device driver detects a hot-plug event request from a storage device, it reports the hot-plug event request to the NetLinkManager via Netlink. The NetLinkManager then forwards the hot-plug event request to the VolumeManager. Upon receiving the hot-plug event request, the VolumeManager immediately acquires and locks a global lock (VM lock). Under the lock protection mechanism of the VM lock, it parses the device information encapsulated in the hot-plug event request (such as the storage device's bus type, device node path, hardware attributes, etc.) to determine the type of storage device corresponding to the hot-plug event request. For example, a USB bus type indicates an external storage device, while MMC, PCIe, and other bus types indicate an internal storage device.

[0053] Furthermore, if the storage device type is detected as an internal storage device, the Volume Manager is controlled to execute a hot-plug event request. After the hot-plug event request is completed, the global lock is released. That is, the VolumeManager directly executes the native processing logic for the hot-plug event request of the internal storage device, and releases the global lock vmlock after the hot-plug event request is completed. For details, please refer to the description of the relevant technology. If the storage device type is detected as an external storage device, step S203 is executed.

[0054] If the present invention detects a hot-plug event request for the built-in storage device, it executes the hot-plug event request using the native volume manager and protects it with a global lock to ensure data access consistency of the built-in storage operation, thereby achieving decoupling of hot-plug events between internal and external storage devices.

[0055] Step S203: When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed.

[0056] Specifically, when VolumeManager determines that the hot-plug event request corresponds to an external storage device, it immediately releases the global lock vm lock it holds and forwards the hot-plug event request to the external storage device manager VolumeManagerExt. This transfers the management object of the external storage device from the native VolumeManager module of Vold to VolumeManagerExt, laying the foundation for the decoupling of business functions between internal and external storage devices.

[0057] Furthermore, upon receiving a hot-plug event request, VolumeManagerExt first requests and locks an independent private lock, vm_ext lock, to ensure the security of concurrent resources for external storage devices. Secondly, it calls the VolumeManagerExt.handleBlockEvent interface to read the event type corresponding to the hot-plug event request and calls the event handling interface matching the event type to process the hot-plug event request. This allows for the execution of hot-plug event requests such as insertion, removal, and state changes of external storage devices under the protection of the private lock vm_ext lock. After execution, the private lock vm_ext lock is released, and the device state change result is reported to the upper-level StorageManager and synchronized to the application side of the vehicle's operating system.

[0058] It should be noted that the VolumeManagerExt.handleBlockEvent interface is used to traverse the storage device list of the vehicle's operating system based on hot-plug event requests, matching the external storage device path. If a match is found in the storage device list, the event type is read, which includes insertion event requests, removal event requests, and status change event requests. If it is an insertion event request, the add interface is called; if it is a removal event request, the remove interface is called; and if it is a status change event request, the change interface is called.

[0059] In related technologies, hot-plugging event requests for external storage devices are handled uniformly by VolumeManager. The handleBlockEvent process holds the global VM lock for an extended period. Time-consuming or abnormal operations during the mounting, unmounting, or state changes of external storage devices can trigger Watchdog detection, leading to a system black screen and restart. This invention delegates the disk management of external storage devices to the VolumeManagerExt module, thereby releasing the global VM lock in advance. Time-consuming operations on external storage devices will not block the system Watchdog detection process, thus resolving the system-level black screen and restart problem caused by time-consuming operations on external storage devices.

[0060] In this embodiment of the invention, when the external storage device manager executes a hot-plug event request, the device access time corresponding to the external storage device is determined. The hot-plug event request includes multiple sub-operations for the external storage device, such as disk information reading, file system repair (i.e., file system detection), and mounting sub-operations when executing an insert event request, and resource release and unloading sub-operations when executing a remove event request. The VolumeExtMonitor module records the duration of each sub-operation when VolumeManagerExt executes it; the device access time is the duration corresponding to each sub-operation.

[0061] Step S204: Based on the device access time and the blocking state of the kernel storage device driver, adjust the execution process of the external storage device manager for hot-plug event requests.

[0062] This embodiment combines the device access time of external storage devices with the blocking state of kernel storage device drivers to adaptively adjust the event execution process of the VolumeManagerExt module, achieving anomaly isolation and recovery. Specifically, the VolumeExtMonitor module continuously monitors the device access time for each sub-operation on the external storage device to determine if there are any abnormal operations with excessively long access times; furthermore, it sends a diagnostic request to the USBMonitor to check if the kernel USB driver is in a blocking state. Then, when an anomaly is detected, the execution process of VolumeManagerExt for hot-plug event requests is adjusted based on the detection results, ensuring stable execution of external storage device hot-plug events and improving system reliability.

[0063] The disk management method provided in this embodiment listens for hot-plug event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. It first locks the global lock of the volume manager. When the storage device type for the hot-plug event request is identified as an external storage device, the global lock is released in advance. The external storage device manager then executes the hot-plug event request under the protection of a private lock mechanism. This prevents time-consuming operations of the external storage device from occupying the global lock for extended periods, thus preventing system black screen restarts due to global lock timeouts. By combining the device access time during the execution of the hot-plug event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the architecture of internal and external storage services, ensures stable execution of external storage device hot-plug events, and improves system reliability.

[0064] This embodiment provides a disk management method that can be used for, for example Figure 1 The in-vehicle operating system shown is such as Android. Figure 3 This is a flowchart of a disk management method according to an embodiment of the present invention, such as... Figure 3 As shown, the process includes the following steps: Step S301 involves using the kernel storage device driver to listen for hot-plug event requests from the storage device. See [link / reference] for details. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0065] Step S302: Send the hot-plug event request to the volume manager, lock the volume manager's global lock, and determine the storage device type corresponding to the hot-plug event request. See details in [reference needed]. Figure 2 Step S202 of the illustrated embodiment will not be described again here.

[0066] Step S303: When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed.

[0067] Specifically, the hot-plug event request includes an insertion event request, and step S303 above includes: Step S3031: When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, and the private lock of the external storage device manager is locked.

[0068] Specifically, upon recognizing an insertion event request from an external storage device, VolumeManager immediately releases the global lock (vm lock), isolating the time-consuming operation of the external storage device from the timeout detection process of the system's global lock (vm lock). Subsequently, the insertion event request from the external storage device is distributed to VolumeManagerExt, which requests and locks a private lock (vm_ext lock). Under the protection mechanism of the private lock (vm_ext lock), the lock resources and execution processes of the external storage service and the internal storage service are isolated.

[0069] Step S3032: Create the first child process corresponding to the main process of the external storage device manager; use the first child process to execute the insertion event request of the external storage device; after the insertion event request is completed, control the main process to mount the external storage device.

[0070] Specifically, VolumeManagerExt creates a first child process corresponding to its main process, and delegates the insertion event request for the external storage device to the first child process for asynchronous execution. This decouples easily blocking and time-consuming operations such as disk information reading and file system repair from the main process, eliminating the need for the main process to block and wait synchronously. After the first child process completes the execution of the insertion event request, the main process mounts the external storage device.

[0071] This invention creates a first child process of the external storage device manager main process, and delegates the insertion event request of the external storage device to the first child process for asynchronous execution. After the first child process completes the insertion event request, the main process performs the mounting operation of the external storage device. This decouples and isolates the time-consuming operation of executing the insertion event request from the main process, and avoids the external storage device abnormally blocking the main process.

[0072] In this embodiment, the mounting process for the external storage device is as follows: Figure 4 As shown, when VolumeManagerExt receives an external storage device insertion request, it has already released the system global lock (vm lock) and only locks the private lock (vm_extlock) to ensure resource isolation for the external storage service and avoid multi-threaded concurrent conflicts. It then enters the initialization phase of the external storage device mounting process. Next, it performs a disk information read operation (read metadata) asynchronously to prevent the vehicle's operating system from crashing due to an abnormal read metadata operation. After the disk information read is complete, it performs a file system repair operation (fscheck) asynchronously to repair the file system. Finally, it completes the device mounting operation (mount).

[0073] In some optional implementations, step S3032 above includes: Step a1: The first child process performs a disk information read operation on the external storage device, and after the disk information read operation is completed, it sends a first completion signal to the main process.

[0074] Specifically, the VolumeManagerExt main process creates an asynchronous first child process, isolating the disk metadata read operation within this child process. The main process monitors the status of the first child process via the P operation, while simultaneously setting a timeout for a preset duration (e.g., 5 seconds). After completing the disk metadata read and partition table parsing, the first child process sends a first completion signal to the main process via the V operation.

[0075] In some embodiments, if the first child process is stuck due to reasons such as an abnormality of the external storage device, the main process can detect the abnormality through a timeout monitoring mechanism. That is, if the first completion signal is not received within the first preset time period, the main process does not need to continue waiting for the first child process, terminates the first child process and exits the mounting process, without affecting the operation of other business processes of the main process.

[0076] Compared to related technologies that use VolumeManager to hold a global lock (vm lock) and perform disk information reading operations serially in the main process, this embodiment decouples disk information reading operations from the main process using VolumeManagerExt. This avoids occupying the global lock (vm lock) and prevents the main process from freezing due to disk parsing blockage, thus avoiding triggering a timeout restart of the vehicle's operating system.

[0077] Step a2: If the main process receives the first completion signal within the first preset time period, the first child process performs a file system repair operation on the external storage device, and sends a second completion signal to the main process after the file system repair operation is completed.

[0078] Specifically, if the main process receives the first completion signal from the first child process within the first preset time period, determining that the disk information was successfully read, the first child process continues to execute the file system repair operation fscheck, performing file system scanning, error detection, and repair on the external storage device. The main process monitors the status of the first child process through the P operation and simultaneously sets a timeout for a second preset time period (e.g., 10 seconds) to prevent the repair process from being blocked indefinitely due to severe file system corruption. After completing the fscheck operation, the first child process sends a second completion signal to the main process, synchronously indicating the repair completion status.

[0079] In some embodiments, if the main process does not receive the second completion signal within the second preset time period, it indicates that the file system repair process has timed out or failed. The main process can terminate the first child process and exit the mounting process to avoid abnormal operations from continuously occupying system resources.

[0080] In related technologies, fscheck scanning, disk parsing, and mounting operations are executed serially. VolumeManager holds the global lock vm lock throughout the process, which is prone to lock timeout due to file system anomalies. This embodiment executes fscheck asynchronously through the first child process and uses PV semaphores to achieve synchronous control between the main process and the first child process. This ensures the execution of file system repair without affecting system stability due to repair time.

[0081] Step a3: If the main process receives a second completion signal within the second preset time period, control the main process to mount the external storage device.

[0082] Specifically, if the main process receives the second completion signal from the first child process within the second preset time period, it is determined that both disk parsing and file system repair have been successfully executed, and the VolumeManagerExt main process performs the partition mount operation. The main process mounts the target partition of the external storage device by calling the mount command. Since the file system is repaired asynchronously, there is no risk of blocking during the mount process, and the main process performs the mount under the protection of the private lock vm_ext lock, without holding the system global lock, thus avoiding the Watchdog monitoring timeout and preventing the system from restarting unexpectedly.

[0083] Furthermore, after the partition mounting operation is completed, VolumeManagerExt releases the private lock vm_extlock and synchronously reports the mounting status of the external storage device to the upper-level StorageManager, completing the external storage device insertion event, so that the vehicle's operating system can normally recognize and use the external storage device.

[0084] The relevant technology utilizes VolumeManager to hold a global lock (vm lock), and then sequentially executes disk information reading, fscheck scanning, and disk mounting. If this process is blocked or the storage device malfunctions, it will time out, causing the system watchdog to time out and resulting in the system freezing and restarting.

[0085] This invention isolates the potentially blocking and time-consuming disk operations from the main process by asynchronously executing disk information reading and file system repair operations on the external storage device through a first child process. This prevents the main process from freezing due to external storage device malfunctions and prevents the first child process from blocking indefinitely by setting a preset timeout. The main process performs the mounting operation under the protection of a private lock, without needing to occupy a global lock, thus avoiding system crashes and restarts caused by global lock timeouts and improving the stability of the external storage device mounting process.

[0086] Step S304: Based on the device access time and the blocking state of the kernel storage device driver, adjust the execution process of the external storage device manager for hot-plug event requests. See details for further information. Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0087] The disk management method provided in this embodiment listens for insertion event requests from storage devices and sends them to the volume manager natively managed by the volume daemon. It first locks the global lock of the volume manager. When the insertion event request is identified as being related to an external storage device, the global lock is released in advance. The external storage device manager then executes the insertion event request asynchronously under the protection of a private lock mechanism. This prevents time-consuming operations of the external storage device from occupying the global lock for extended periods, thus preventing system black screen restarts due to global lock timeouts. By combining the device access time during the execution of the insertion event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the architecture of internal and external storage services, ensures stable execution of external storage device insertion events, and improves system reliability.

[0088] This embodiment provides a disk management method that can be used for, for example Figure 1 The in-vehicle operating system shown is such as Android. Figure 5 This is a flowchart of a disk management method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps: Step S501 involves using the kernel storage device driver to listen for hot-plug event requests from the storage device. See [link / reference] for details. Figure 3 Step S301 of the illustrated embodiment will not be described again here.

[0089] Step S502: Send the hot-plug event request to the volume manager, lock the volume manager's global lock, and determine the storage device type corresponding to the hot-plug event request. See details in [reference needed]. Figure 3 Step S302 of the illustrated embodiment will not be described again here.

[0090] Step S503: When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed.

[0091] Specifically, the hot-plug event request includes a pull-out event request, and step S503 above includes: Step S5031: When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, and the private lock of the external storage device manager is locked.

[0092] Specifically, upon recognizing a request to unplug an external storage device, VolumeManager immediately releases the global lock (vm lock), isolating the time-consuming operation of the external storage device from the timeout detection process of the system's global lock (vm lock). Subsequently, the request to unplug the external storage device is distributed to VolumeManagerExt, which requests and locks a private lock (vm_ext lock). Under the protection mechanism of the private lock (vm_ext lock), the lock resources and execution processes of the external storage service and the internal storage service are isolated.

[0093] Step S5032: Create a second child process corresponding to the main process of the external storage device manager; control the second child process to execute the unplug event request of the external storage device in a multi-threaded manner; after the unplug event request is completed, control the main process to unload the external storage device.

[0094] Specifically, the VolumeManagerExt main process creates a corresponding second child process, which asynchronously executes the external storage device unloading event request, decoupling resource querying and release operations from the main process. After the second child process completes the resource release of the external storage device, the main process then performs the unloading operation, without occupying the system's global lock, thus avoiding blocking of the main process and affecting the vehicle's operating system.

[0095] This invention creates a second child process corresponding to the main process of the external storage device manager to asynchronously execute the unplug event request for the external storage device, isolating time-consuming operations such as resource querying and release to the second child process. It also employs a multi-threaded approach to quickly locate the process occupying the unreleased resource, improving resource retrieval efficiency and effectively shortening the unloading process time. The main process then performs the unloading operation after the unplug event request has been completed. Thus, the unplug event request is executed asynchronously under the protection of a private lock, without needing to hold the system global lock throughout the process. This avoids system crashes and restarts caused by prolonged global lock holding, improving system reliability.

[0096] In this embodiment, the unloading process of the external storage device is as follows: Figure 6 As shown, the system uses asynchronous multi-threaded queries to match and query unreleased resources in / proc. After finding the process information corresponding to the unreleased resource, a resource release signal is sent to inform it to release the resource. The second child process sleeps for 1000 ms and then queries the process that is occupying the resource. After the resource is released, the VolumeManagerExt main process is woken up to perform unloading, reducing the time spent on resource release.

[0097] In some optional implementations, step S5032 above includes: Step b1: Create multiple child threads corresponding to the second child process.

[0098] Specifically, during the initialization of the second child process, multiple child threads are created. These multiple child threads can simultaneously traverse system process information, which significantly improves process query efficiency compared to the serial traversal method in related technologies.

[0099] Step b2 involves using multiple sub-threads to query the file information occupied by each process in the process space in parallel, determining the unreleased resources of the external storage device based on the file information, and identifying the process occupying the unreleased resources.

[0100] Specifically, see again Figure 6 Multiple child threads traverse all process directories under the / proc file system in parallel, reading the file descriptor (fd) information of each process. Then, based on / proc / process_id / fd, they open the directory, traverse each fd to obtain the file I / O information of each process, and match unreleased resources related to the current external storage device mount path based on the file I / O information. Through parallel queries, the processes still occupying external storage device I / O resources are quickly located, and relevant information about the occupying processes is recorded.

[0101] Step b3: Send a resource release signal to the occupying process until all unreleased resources on the external storage device are released, then control the main process to unload the external storage device.

[0102] Specifically, the second child process can send resource release signals to the occupying process via multi-threading, proactively notifying the occupying process to release the occupied I / O resources. The VolumeManagerExt main process executes the P operation to enter a waiting state, while setting a maximum waiting time of 5 seconds to avoid indefinite blocking of the process due to abnormal processes failing to release resources. The second child process cyclically queries the resource occupancy status of the external storage device every 1000ms. If it detects that all unreleased resources have been released, the second child process executes the V operation to wake up the main process.

[0103] Furthermore, after the main process is awakened, it calls the umount command to perform an unmount operation on the target partition of the external storage device. After the unmount operation is completed, VolumeManagerExt releases its private lock vm_ext lock and synchronously reports the device unmount status to the upper-level StorageManager, thus completing the handling of the external storage device removal event.

[0104] The related technology uses VolumeManager to hold a global VM lock, then reads process information serially, waits for process resources to be released, and then executes unmount to unload the storage device serially. This method is highly dependent on the release of application resources and the file system status of the storage device, which is time-consuming and can easily lead to system crashes and restarts.

[0105] This invention creates multiple sub-threads corresponding to a second sub-process, enabling parallel queries of the process space and quickly locating the process occupying unreleased resources. By sending a resource release signal to the occupying process and controlling the main process to perform the unloading operation only after the resources are fully released, the unloading efficiency when removing external storage devices is improved. Furthermore, the asynchronous execution of the unloading time request under the protection of a private lock avoids system crashes and restarts caused by global lock occupancy, thus improving system stability.

[0106] The above embodiments describe in detail the insertion and removal logic of external storage devices. Since Vold also has VoldNativeService capabilities, such as... Figure 7 As shown, after receiving a storage device operation request (i.e., a Binder request) from the application layer or system layer, the VoldNativeService forwards it to the VolumeManager. The VolumeManager determines whether it is related to an external storage device. If it is a request related to an external storage device, it obtains a VolumeManagerExt object, releases the global lock vm lock, and performs the external storage device operation through VolumeManagerExt. If it is a request related to an internal storage device, the VolumeManager executes the request normally.

[0107] In some optional implementations, the execution flow of a storage device operation request includes: Step c1: Listen for storage device operation requests from the vehicle's infotainment system; where a storage device operation request is an operation request related to the storage device initiated by the application layer or system layer to the volume daemon.

[0108] Specifically, the application or system layer of the vehicle's operating system (such as the vehicle's file manager, settings module, system storage service, etc.) initiates various storage device operation requests to the volume daemon (Vold) through the Binder inter-process communication mechanism. These requests include, but are not limited to, Binder requests for mounting, unmounting, formatting, status querying, and data reading / writing of storage devices. See again. Figure 7 The VoldNativeService module of Vold continuously listens for and receives Binder requests from upper-layer applications or systems.

[0109] Step c2: Send the storage device operation request to the volume manager, lock the global lock corresponding to the volume manager, and determine the storage device type corresponding to the storage device operation request.

[0110] Specifically, after receiving the Binder request, VoldNativeService forwards the request to Vold's native VolumeManager. See again. Figure 7 Upon receiving the request, the VolumeManager module immediately requests and locks the system-wide global lock (vm lock). Under the protection of the global lock, it parses the device identifier, bus type, and other information carried in the request to determine the storage device type corresponding to the current Binder request.

[0111] Step c3: If the storage device type is detected as an external storage device, release the global lock, send the storage device operation request to the external storage device manager, lock the private lock corresponding to the external storage device manager, control the external storage device manager to execute the storage device operation request, and release the private lock after the storage device operation request is completed.

[0112] Specifically, see again Figure 7 If the Binder request is related to an external storage device, the VolumeManager immediately releases the global lock it holds (vm lock), severing the association between the external storage operation and the system global lock. This prevents subsequent time-consuming operations from occupying the global lock for an extended period and triggering a system watchdog timeout. Then, it obtains the VolumeManagerExt object and forwards the Binder request to the VolumeManagerExt.

[0113] Furthermore, upon receiving a Binder request, VolumeManagerExt requests and locks its own private lock, vm_ext lock. Under the protection of this private lock, it executes the Binder request corresponding to the external storage device. The private lock ensures resource exclusivity for external storage services, avoiding multi-threaded concurrency conflicts without requiring the use of a system global lock. After the Binder request is completed, the VolumeManagerExt module releases the vm_ext lock and returns the execution result to the request initiator via VoldNativeService.

[0114] In this embodiment, see again Figure 7If the Binder request corresponds to the built-in storage device, then the Vold native processing flow is entered. The VolumeManager, holding the global lock (vm lock), directly executes the operation logic corresponding to the Binder request. After execution, the global lock (vm lock) is released, and the execution result is returned to the upper-level request initiator through VoldNativeService.

[0115] This invention continuously monitors storage device operation requests initiated by the vehicle infotainment system's application layer and system layer, and sends them to the volume manager natively managed by the volume daemon process, first locking the volume manager's global lock. When a storage device operation request is identified as related to an external storage device, the global lock is released in advance, and the external storage device manager executes a hot-plug event request under the protection mechanism of a private lock. This achieves architectural decoupling between internal and external storage services, avoids time-consuming operations of external storage devices from occupying the global lock for extended periods, and prevents the system from triggering a black screen restart failure due to global lock timeout.

[0116] Step S504: Based on the device access time and the blocking state of the kernel storage device driver, adjust the execution process of the external storage device manager for hot-plug event requests. See details for further information. Figure 3 Step S304 of the illustrated embodiment will not be described again here.

[0117] The disk management method provided in this embodiment listens for storage device unplugging event requests and sends them to the volume manager natively managed by the volume daemon. It first locks the global lock of the volume manager. When the unplugging event request is identified as being related to an external storage device, the global lock is released in advance. The external storage device manager then executes the unplugging event request asynchronously under the protection of a private lock mechanism. This prevents time-consuming operations of the external storage device from occupying the global lock for extended periods, thus preventing system black screen restarts due to global lock timeouts. By combining the device access time during the execution of the unplugging event request with the blocking state of the kernel storage device driver, the execution process of the external storage device manager is adaptively adjusted to achieve anomaly isolation and recovery. This decouples the internal and external storage services, ensures stable execution of external storage device unplugging events, and improves system reliability.

[0118] This embodiment provides a disk management method that can be used for, for example Figure 1 The in-vehicle operating system shown is such as Android. Figure 8 This is a flowchart of a disk management method according to an embodiment of the present invention, such as... Figure 8 As shown, the process includes the following steps: Step S801 involves using the kernel storage device driver to listen for hot-plug event requests from the storage device. See [link / reference] for details. Figure 5Step S501 of the illustrated embodiment will not be described again here.

[0119] Step S802: Send the hot-plug event request to the volume manager, lock the volume manager's global lock, and determine the storage device type corresponding to the hot-plug event request. See details in [reference needed]. Figure 5 Step S502 of the illustrated embodiment will not be described again here.

[0120] Step S803: When the storage device type is detected as an external storage device, the global lock is released, a hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed. See details for further information. Figure 5 Step S503 of the illustrated embodiment or Figure 3 Step S303 of the illustrated embodiment will not be described again here.

[0121] Step S804: Based on the device access time and the blocking state of the kernel storage device driver, adjust the execution process of the external storage device manager for hot-plug event requests.

[0122] Specifically, step S804 includes: Step S8041: Determine whether the device access time exceeds the device access time threshold.

[0123] In this embodiment, when VolumeManagerExt processes an insertion event request or a removal event request for an external storage device, it can use a watchdog mechanism to check if there are any time-consuming operations on the external storage device. The hot-plug event request includes multiple sub-operations for the external storage device, and the device access time is the duration corresponding to each sub-operation. When VolumeManagerExt begins executing each sub-operation (e.g., disk information read operation, file system repair operation, etc.), it checks if there are any time-consuming operations on the external storage device. Figure 9 As shown, VolumeExtMonitor starts a watchdog timer task, counts the device access time corresponding to the sub-operation, and compares the device access time with a device access time threshold (e.g., 5 seconds) to determine whether there is any abnormal behavior of excessively long operation time in the current external storage device. If the device access time exceeds the device access time threshold, step S8042 is executed; if the device access time does not exceed the device access time threshold, step S8043 is executed.

[0124] Step S8042: If the device access time exceeds the device access time threshold, based on the blocking state of the kernel storage device driver, reset the execution state of the external storage device manager for the hot-plug event request until the hot-plug event request is completed, and then release the private lock.

[0125] Specifically, when the device access time exceeds the device access time threshold, a diagnostic process is triggered. By detecting the actual blocking state of the kernel USB driver, differentiated processing is performed based on different states to reset the execution state of the hot-plug event request. After the hot-plug event request is completed, the private lock is released. This achieves stable execution of the hot-plug event request without restarting the vehicle's operating system or requiring the user to actively plug or unplug external storage devices, thus improving the user experience.

[0126] This invention, when device access time exceeds a threshold, determines the blocking state of the kernel storage device driver and adaptively resets the execution state of the external storage device manager for hot-plug event requests based on this blocking state. This avoids non-blocking, normal time-consuming operations being mistakenly identified as faults and interrupting the process, and also enables abnormal recovery from hardware-level blocking. Stable execution of hot-plug event requests can be restored without manual unplugging or plugging of external storage devices or a system restart. After the hot-plug event request is completed, the private lock is released, without occupying the system's global lock throughout the process, thus not affecting the core business operation of the vehicle system and avoiding system crashes and restarts caused by external storage device malfunctions, thereby improving system stability.

[0127] In some optional implementations, step S8042 above includes: Step d1: Determine if the kernel storage device driver is blocked.

[0128] Specifically, the kernel storage device driver records a completion flag when the external storage device manager begins executing each sub-operation, and updates the completion flag after the sub-operation is completed. See again. Figure 9 At the start of each sub-operation of the external storage device hot-plug event, the kernel USB driver submodule USBMonitor sets the WaitComplete flag to the waiting state true, and updates it to the completion state false after the sub-operation is completed.

[0129] In this embodiment, a diagnostic request is sent to the kernel storage device driver so that the kernel storage device driver can check the status of the wait-to-complete flag. If the wait-to-complete flag is not in a waiting state, it is determined that the kernel storage device driver is not blocked. If the wait-to-complete flag is in a waiting state, it is determined that the kernel storage device driver is blocked.

[0130] Specifically, see again Figure 9VolumeExtMonitor sends a diagnostic request to the kernel USBMonitor module, requesting to check the running status of the kernel USB driver. USBMonitor queries the current status of the WaitComplete flag. If the WaitComplete flag is not in a waiting state (true), it is determined that the kernel USB driver is not blocked, but the operation is just taking a long time. If the WaitComplete flag is in a waiting state (true), it is determined that the kernel USB driver is in a hardware-level blocked state and cannot complete the operation normally.

[0131] This invention determines whether the kernel storage device driver is in a normal, non-waiting state or a hardware-stuck, blocked state by sending diagnostic requests to the kernel storage device driver and detecting the status of the waiting completion flag. This enables accurate determination of the kernel storage device driver's blocking state, providing a reliable basis for the adaptive adjustment and abnormal recovery of the subsequent hot-plug event execution process, and improving the accuracy and operational stability of the vehicle's operating system in monitoring storage device anomalies.

[0132] Step d2: If the kernel storage device driver is not blocked, reset the device access timeout and control the external storage device manager to continue executing hot-plug event requests.

[0133] Specifically, see again Figure 9 When it is determined that the kernel USB driver is not blocked, the kernel USB driver sends an asynchronous callback to VolumeExtMonitor through the FASYNC mechanism to reset the device access time of the VolumeExtMonitor module. The VolumeManagerExt module continues to execute the current hot-plug event request without interrupting the process or triggering a hardware reset.

[0134] Step d3: If the kernel storage device driver is blocked, perform a hardware reset on the external storage device and return to the step of sending a hot-plug event request to the external storage device manager.

[0135] Specifically, when the kernel USB driver is determined to be in a blocked state, the vehicle's external USB power supply system is controlled to perform a hardware reset operation (power off and then power on) on the external storage device to clear the abnormal blocking state. After the hardware reset is complete, the kernel USB driver processes the device hot-plug interrupt event and generates a new hot-plug event request for the external storage device. The USB driver reports the new hot-plug event to the Vold process via Netlink, re-triggering the VolumeManagerExt's hot-plug event processing flow, thus achieving automatic recovery after abnormal blocking. This enables abnormal monitoring and recovery of external storage devices, improving the stability of external storage devices.

[0136] In some embodiments, the hardware reset of the external storage device can also be achieved by reloading the port corresponding to the kernel USB driver.

[0137] When the kernel storage device driver is not blocked, this invention only resets the device access time and continues to execute the hot-plug event request, avoiding the normal time-consuming operation being misjudged as a fault and interrupting the process. When the kernel storage device driver experiences hardware-level blocking, it performs a hardware reset on the external storage device and resends the hot-plug event, achieving abnormal recovery without requiring the user to plug or unplug the device or the system to restart. This solves the problem of system blackout and restart caused by external storage device abnormalities, and does not occupy the global lock throughout the process, does not affect the operation of the vehicle's core business, and improves the operational stability of the vehicle system.

[0138] Step S8043: If the device access time does not exceed the device access time threshold, control the external storage device manager to continue executing the hot-plug event request, and release the private lock after the hot-plug event request is completed.

[0139] Specifically, if the device access time does not exceed the device access time threshold, the external storage device operation is determined to be normal, and the VolumeManagerExt module continues to execute the remaining sub-operations of the hot-plug event under the protection of the private lock vm_ext lock. After all sub-operations requested by the hot-plug event (such as mount completion, unmount completion) have been executed, VolumeManagerExt releases the private lock vm_ext lock.

[0140] This invention determines that the external storage device hot-plug operation is running normally when the device access time does not exceed the device access time threshold, and the external storage device manager continues to execute the process, ensuring the continuity of hot-plug event request execution and avoiding process interruption that affects user experience. Furthermore, the hot-plug event request is executed under the protection of a private lock. The private lock is released promptly after the hot-plug event request is completed, ensuring mutual exclusion of external storage business resources and data consistency. At the same time, it does not occupy the system's global lock, thus avoiding triggering a global lock timeout restart and not affecting the operation of the vehicle's core business, thereby improving the overall stability of the vehicle's infotainment system.

[0141] The disk management solution of the present invention will be described in detail below with reference to a specific application example.

[0142] like Figure 10AAs shown, the native Vold process is triggered by a USB driver event or a VolumeNativeService request, entering the VolumeManager. The VolumeManager requests and holds the global lock (vm lock), while the Android system's StorageManager also requests the global lock (vm lock), continuously monitoring the holding duration of the global lock (vm lock) via a Watchdog. While holding the global lock (vm lock), the VolumeManager directly executes the storage device request. After the request is completed, the global lock (vm lock) is released, and the process ends. Time-consuming or abnormal operations on external storage devices can occupy the global lock (vm lock) for a long time, easily triggering the system Watchdog timeout and restart.

[0143] In this embodiment, as Figure 10B As shown, after a USB driver event (i.e., a hot-plug event of a storage device detected by the kernel USB driver) or a VolumeNativeService request (i.e., a storage device operation request issued by an upper-layer application or system) is triggered, the VolumeManager is first entered and a global lock (vm lock) is requested and acquired. Under the protection of the global lock (vm lock), the VolumeManager determines whether the request is related to an external storage device. If it is, it acquires a VolumeManagerExt object, and the VolumeManager immediately releases the global lock (vm lock), no longer performing any operations related to the external storage device within the lock. The requests related to the external storage device are executed by VolumeManagerExt, without occupying the system's global lock (vm lock) throughout the process, thus avoiding system restart issues caused by long-term global lock occupation.

[0144] The disk management architecture of this invention is as follows: Figure 11 As shown, at the hardware layer, external storage devices interact with the USB Driver via USB plug-in / plug-out interrupts and USB control commands. The USB Driver reports hot-plug event requests from the external storage device. At the kernel layer, the USB Driver receives the hot-plug event requests from the external storage device and reports them to the Native layer's VolumeManagerExt via Netlink events. Simultaneously, it responds to diagnostic commands and sends USB control commands to the external storage device. The USBMonitor receives diagnostic commands from the VolumeExtMonitor, queries the kernel USB driver status, and synchronizes the status back to the VolumeExtMonitor via the FASYNC mechanism.

[0145] See you again Figure 11In the Native layer where the Volume process resides, VolumeManagerExt receives Netlink events from the USB driver, handles the mounting and unmounting operations of external storage devices, and reports the operation status to VolumeExtMonitor via a watchdog mechanism. VolumeExtMonitor, as an anomaly monitoring module, sends diagnostic commands to the kernel USBMonitor, receives status synchronization, and implements anomaly monitoring and recovery for external storage operations.

[0146] See you again Figure 11 At the system framework layer, `VoldNativeService` receives Binder requests from the upper layer, while requests related to external storage devices are handled by `VolumeManagerExt`, and other business requests are handled by the native `VolumeManager`. `StorageManager` receives device status synchronized by `VolumeManagerExt` and is monitored by the system watchdog to ensure stable operation of the storage service.

[0147] Taking USB driver events as an example, such as Figure 12 As shown, in the native Vold process, hot-plug events generated by the USB driver are reported to the Vold process via NetLinkManager. After obtaining the VolumeManager object, the VolumeManager directly requests and holds the global lock, vm lock. Simultaneously, the Android system's StorageManager is monitored by a Watchdog, synchronously monitoring the global lock state. While holding the vm lock, the VolumeManager performs operations such as mounting and unmounting storage devices (including external storage). After the operations are completed, the StorageManager synchronizes the device state and finally releases the vm lock. In the above process, time-consuming operations such as mounting and unmounting external storage devices can occupy the vm lock for a long time, easily triggering Watchdog timeouts and causing a system restart.

[0148] In this embodiment, see again Figure 12The USB driver reports hot-plug events via NetLinkManager. NetLinkManager obtains a VolumeManager object, which determines if the request involves an external storage device and obtains a VolumeManagerExt object. The VolumeManagerExt handles the hot-plug event and holds an independent private lock (vm_ext lock), no longer occupying the system's global lock (vm lock). Under the protection of the vm_ext lock, the mounting and unmounting operations of the external storage device are performed. After the operations are completed, the device state is synchronized with StorageManager, and finally the vm_ext lock is released. By isolating external storage operations with a private lock and avoiding the use of the global lock (vm lock), system restarts caused by watchdog timeouts are prevented.

[0149] This invention adds a VolumeManagerExt module to handle business logic related to Android external storage devices, optimizes the mounting and removal processes of external storage devices, and reconstructs the access process for external storage devices by debinding the external storage device business from the Android system. This resolves issues such as system crashes and black screens caused by abnormalities like external storage device damage and time spent on file system resource reclamation when the external storage device is removed. It also solves user interface crashes and black screens caused by Android system freezes, black screens, restarts, and ANRs (Application Not Responding) due to Android platform disk management services, disk anomalies, and disk driver anomalies, ensuring a superior user experience and achieving better in-car entertainment.

[0150] This invention supports external storage device mounting and unmounting dead detection through VolumeExtMonitor and the kernel USBMonitor module. Through the communication interface between user space and the USB driver layer, it supports proactive issuance of diagnostic commands, effectively solving the problem in traditional architectures where user space cannot proactively obtain device status and issue control commands. This significantly improves the management capabilities and reliability of external storage devices. Through a bidirectional communication mechanism, the system can monitor device status in real time and proactively trigger recovery processes when an anomaly is detected, thereby ensuring the stable operation of the storage system.

[0151] This embodiment also provides a disk management device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0152] This embodiment provides a disk management device, such as... Figure 13As shown, it includes: The first processing module 1301 is used to listen for hot-plug event requests of storage devices using the kernel storage device driver. The second processing module 1302 is used to send the hot-plug event request to the volume manager, lock the global lock of the volume manager, and determine the storage device type corresponding to the hot-plug event request. The third processing module 1303 is used to release the global lock, send the hot-plug event request to the external storage device manager, lock the private lock of the external storage device manager, control the external storage device manager to execute the hot-plug event request, and determine the device access time corresponding to the external storage device when the hot-plug event request is executed. The fourth processing module 1304 is used to adjust the execution process of the external storage device manager for hot-plug event requests based on the device access time and the blocking state of the kernel storage device driver.

[0153] In some optional implementations, the hot-plug event request includes an insertion event request; the third processing module 1303 is further configured to: Creates the first child process corresponding to the main process of the external storage device manager; The first child process executes the insertion event request for the external storage device. After the insertion event request is completed, the main process is controlled to mount the external storage device.

[0154] In some optional implementations, the third processing module 1303 is further configured to: The first child process performs disk information reading operations on the external storage device, and sends a first completion signal to the main process after the disk information reading operation is completed. If the main process receives the first completion signal within the first preset time period, the first child process performs a file system repair operation on the external storage device, and sends a second completion signal to the main process after the file system repair operation is completed. If the main process receives a second completion signal within the second preset time period, it controls the main process to mount the external storage device.

[0155] In some optional implementations, the hot-plug event request includes a pull-out event request; the third processing module 1303 is further configured to: Create a second child process corresponding to the main process of the external storage device manager; The second child process is controlled to execute the unplug event request of the external storage device in a multi-threaded manner. After the unplug event request is completed, the main process is controlled to unload the external storage device.

[0156] In some optional implementations, the third processing module 1303 is further configured to: Create multiple child threads corresponding to the second child process; Multiple sub-threads are used to query the file information occupied by each process in the process space in parallel. Based on the file information, the unreleased resources of the external storage device are determined, and the process occupying the unreleased resources is determined. Send a resource release signal to the occupying process, and control the main process to unload the external storage device after all the unreleased resources on the external storage device have been released.

[0157] In some optional implementations, the fourth processing module 1304 is further configured to: Determine whether the device access time exceeds the device access time threshold; If the device access time exceeds the device access time threshold, based on the blocking state of the kernel storage device driver, the execution state of the external storage device manager for hot-plug event requests is reset until the hot-plug event requests are completed, at which point the private lock is released.

[0158] In some optional implementations, the fourth processing module 1304 is further configured to: Determine if the kernel storage device driver is blocked; If the kernel storage device driver is not blocked, reset the device access timeout and control the external storage device manager to continue executing hot-plug event requests; If the kernel storage device driver is blocked, perform a hardware reset on the external storage device and return to the step of sending a hot-plug event request to the external storage device manager.

[0159] In some optional implementations, the hot-plug event request includes multiple sub-operations for the external storage device, and the device access time is the duration corresponding to each sub-operation; the kernel storage device driver records a wait-to-complete flag when the external storage device manager starts executing each sub-operation, and updates the status of the wait-to-complete flag after the sub-operation is completed; the fourth processing module 1304 is also used for: Send a diagnostic request to the kernel storage device driver so that the kernel storage device driver can check the status of the wait-to-complete flag. If the wait-to-complete flag is not in a waiting state, it is determined that the kernel storage device driver is not blocked. If the wait-to-complete flag is in a waiting state, it is determined that the kernel storage device driver is blocked.

[0160] In some optional implementations, the fourth processing module 1304 is further configured to: If the device access time does not exceed the device access time threshold, control the external storage device manager to continue executing the hot-plug event request, and release the private lock after the hot-plug event request is completed.

[0161] In some alternative implementations, the device is also used for: Listen for storage device operation requests from the vehicle's infotainment system operating system; these storage device operation requests are storage device-related operation requests initiated by the application layer or system layer to the volume daemon process. Send the storage device operation request to the volume manager, lock the global lock corresponding to the volume manager, and determine the storage device type corresponding to the storage device operation request; If the storage device type is detected as an external storage device, the global lock is released, the storage device operation request is sent to the external storage device manager, the private lock corresponding to the external storage device manager is locked, the external storage device manager is controlled to execute the storage device operation request, and the private lock is released after the storage device operation request is completed.

[0162] In some alternative implementations, the device is also used for: If the storage device type is detected as an internal storage device, the volume manager is controlled to execute a hot-plug event request. After the hot-plug event request is completed, the global lock is released.

[0163] The disk management device provided in this embodiment of the invention can execute the disk management method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0164] Figure 14 This is a schematic diagram of the structure of a vehicle operating system controller 101 provided in an embodiment of the present invention.

[0165] The following is a detailed reference. Figure 14 The diagram illustrates a structural schematic suitable for implementing a controller in an embodiment of the present invention. The controller may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 1401, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1402 or a program loaded from memory 1408 into random access memory (RAM) 1403. The RAM 1403 also stores various programs and data required for controller operation. The processor 1401, ROM 1402, and RAM 1403 are interconnected via a bus 1404. An input / output (I / O) interface 1405 is also connected to the bus 1404.

[0166] Typically, the following devices can be connected to I / O interface 1405: input devices 1406 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1407 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory 1408 including, for example, magnetic tape, hard disk, etc.; and communication devices 1409. Communication device 1409 allows the controller to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 14 A controller with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown, and may alternatively implement or have more or fewer devices.

[0167] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1409, or installed from a memory 1408, or installed from a ROM 1402. When the computer program is executed by the processor 1401, it performs the functions defined in the disk management method of the embodiments of the present invention.

[0168] Figure 14 The controller shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0169] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the disk management method shown in the above embodiments is implemented.

[0170] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0171] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A disk management method, characterized in that, The method is applied to an in-vehicle infotainment system, wherein the system includes a kernel storage device driver, the system's process space includes a volume daemon, and the volume daemon includes a volume manager and an external storage device manager that run independently in parallel; the method includes: The kernel storage device driver is used to listen for hot-plug event requests from the storage device. The hot-plug event request is sent to the volume manager, the global lock of the volume manager is locked, and the storage device type corresponding to the hot-plug event request is determined. When the storage device type is detected as an external storage device, the global lock is released, the hot-plug event request is sent to the external storage device manager, the private lock of the external storage device manager is locked, the external storage device manager is controlled to execute the hot-plug event request, and the device access time corresponding to the external storage device is determined when the hot-plug event request is executed. Based on the device access time and the blocking state of the kernel storage device driver, the execution process of the external storage device manager for the hot-plug event request is adjusted.

2. The disk management method according to claim 1, characterized in that, The step of adjusting the execution process of the external storage device manager for the hot-plug event request based on the device access time and the blocking state of the kernel storage device driver includes: Determine whether the device access time exceeds the device access time threshold; If the device access time exceeds the device access time threshold, based on the blocking state of the kernel storage device driver, the execution state of the external storage device manager for the hot-plug event request is reset until the hot-plug event request is completed, at which point the private lock is released.

3. The disk management method according to claim 2, characterized in that, The step of resetting the execution state of the external storage device manager for the hot-plug event request based on the blocking state of the kernel storage device driver includes: Determine whether the kernel storage device driver is blocked; If the kernel storage device driver is not blocked, reset the device access time and control the external storage device manager to continue executing the hot-plug event request; If the kernel storage device driver is blocked, perform a hardware reset on the external storage device and return to the step of sending the hot-plug event request to the external storage device manager.

4. The disk management method according to claim 3, characterized in that, The hot-plug event request includes multiple sub-operations for the external storage device, and the device access time is the duration corresponding to each sub-operation. When the external storage device manager starts executing each sub-operation, the kernel storage device driver records a waiting-to-complete flag and updates the status of the waiting-to-complete flag after the sub-operation is completed. The step of determining whether the kernel storage device driver is blocked includes: A diagnostic request is sent to the kernel storage device driver so that the kernel storage device driver can detect the status of the wait-to-complete flag. If the state of the wait-to-complete flag is not in a waiting state, then it is determined that the kernel storage device driver is not blocked; If the status of the wait-to-complete flag is in a waiting state, it is determined that the kernel storage device driver is blocked.

5. The disk management method according to claim 2, characterized in that, The method further includes adjusting the execution process of the external storage device manager for the hot-plug event request based on the device access time and the blocking state of the kernel storage device driver. If the device access time does not exceed the device access time threshold, the external storage device manager is controlled to continue executing the hot-plug event request, and the private lock is released after the hot-plug event request is completed.

6. The disk management method according to claim 1, characterized in that, The hot-plug event request includes an insertion event request; The step of controlling the external storage device manager to execute the hot-plug event request includes: Create the first child process corresponding to the main process of the external storage device manager; The first subprocess executes the insertion event request of the external storage device, and after the insertion event request is completed, the main process is controlled to mount the external storage device.

7. The disk management method according to claim 6, characterized in that, The step of using the first subprocess to execute the insertion event request of the external storage device, and controlling the main process to mount the external storage device after the insertion event request is completed, includes: The first subprocess performs a disk information read operation on the external storage device, and after the disk information read operation is completed, sends a first completion signal to the main process. If the main process receives the first completion signal within a first preset time period, it uses the first child process to perform a file system repair operation on the external storage device, and sends a second completion signal to the main process after the file system repair operation is completed. If the main process receives the second completion signal within a second preset time period, it controls the main process to mount the external storage device.

8. The disk management method according to claim 1, characterized in that, The hot-plug event request includes a pull-out event request; controlling the external storage device manager to execute the hot-plug event request includes: Create a second child process corresponding to the main process of the external storage device manager; The second subprocess is controlled to execute the unplug event request of the external storage device in a multi-threaded manner. After the unplug event request is completed, the main process is controlled to unload the external storage device.

9. The disk management method according to claim 8, characterized in that, The process of controlling the second subprocess to execute the unplug event request of the external storage device in a multi-threaded manner, and controlling the main process to unload the external storage device after the unplug event request is completed, includes: Create multiple child threads corresponding to the second child process; The multiple sub-threads are used to query the file information occupied by each process in the process space in parallel. Based on the file information, the unreleased resources of the external storage device are determined, and the process occupying the unreleased resources is determined. A resource release signal is sent to the occupying process until all unreleased resources of the external storage device are released, and then the main process is controlled to unload the external storage device.

10. The disk management method according to any one of claims 1-9, characterized in that, The method further includes: Listen for storage device operation requests from the vehicle's operating system; wherein, the storage device operation request is a storage device-related operation request initiated by the application layer or system layer to the volume daemon process; The storage device operation request is sent to the volume manager, the global lock corresponding to the volume manager is locked, and the storage device type corresponding to the storage device operation request is determined. If the storage device type is detected to be an external storage device, the global lock is released, the storage device operation request is sent to the external storage device manager, the private lock corresponding to the external storage device manager is locked, the external storage device manager is controlled to execute the storage device operation request, and the private lock is released after the storage device operation request is completed.

11. The disk management method according to any one of claims 1-9, characterized in that, The method further includes: If the storage device type is detected to be an internal storage device, the volume manager is controlled to execute the hot-plug event request, and the global lock is released after the hot-plug event request is completed.

12. A disk management device, characterized in that, Applied to an in-vehicle infotainment system, the system includes a kernel storage device driver, and the system's process space includes a volume daemon process, which includes a volume manager and an external storage device manager that run independently in parallel; the device includes: The first processing module is used to listen for hot-plug event requests of the storage device using the kernel storage device driver. The second processing module is used to send the hot-plug event request to the volume manager, lock the global lock of the volume manager, and determine the storage device type corresponding to the hot-plug event request. The third processing module is used to release the global lock when the storage device type is detected as an external storage device, send the hot-plug event request to the external storage device manager, lock the private lock of the external storage device manager, control the external storage device manager to execute the hot-plug event request, and determine the device access time corresponding to the external storage device when executing the hot-plug event request. The fourth processing module is used to adjust the execution process of the external storage device manager for the hot-plug event request based on the device access time and the blocking state of the kernel storage device driver.

13. A vehicle infotainment system, characterized in that, The system includes a controller and a kernel storage device driver. The system's process space includes a volume daemon, which includes a volume manager and an external storage device manager that run independently in parallel. The controller includes: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the disk management method according to any one of claims 1 to 11 by executing the computer instructions.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the disk management method according to any one of claims 1 to 11.

15. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the disk management method according to any one of claims 1 to 11.

Images