A storage management method and vehicle

Abstract

The application provides a storage management method and a vehicle, the method is applied to the field of data processing, and the method comprises the following steps: when it is detected that a remaining quota of a first application meets quota borrowing conditions, initiating a quota borrowing request to at least one second application to obtain a temporary quota for data writing; detecting whether a frequency at which the first application triggers quota limitation meets storage IO resource adjustment conditions; and when it is determined that the frequency meets the storage IO resource adjustment conditions, adjusting a storage IO resource configuration item corresponding to the first application. The application comprehensively borrows quotas flexibly and adjusts IO resources dynamically, realizes the coordinated optimization of storage resource allocation and IO performance, and guarantees the stability of the car machine device and the use experience of each application.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a storage management method and vehicle in the field of data processing. Background Technology

[0002] With the increasing prevalence of intelligent cockpit infotainment systems, these systems need to operate continuously for extended periods while the vehicle is in motion, running numerous applications such as navigation, music, and vehicle control. These applications require data writing; if their remaining quota is insufficient to handle the volume of data to be written, it can lead to lag, crashes, or malfunctions, thus impacting the driving experience. Therefore, dynamically adjusting the quotas for multiple applications can satisfy sudden surges in data writing demands.

[0003] However, resource allocation based solely on storage space is still insufficient to meet the demand for multiple applications to run concurrently for extended periods in in-vehicle infotainment systems. In particular, foreground applications such as navigation and vehicle control interfaces have extremely high priority. Compared to background applications such as settings and music, the continuous and stable operation of foreground applications should be prioritized.

[0004] Existing storage management solutions are mainly designed for ordinary devices and are not adapted to the specific scenarios of smart cockpit in-vehicle systems, thus failing to meet the usage requirements of in-vehicle systems. Summary of the Invention

[0005] This application provides a storage management method and a vehicle that can solve the above-mentioned problems.

[0006] Firstly, a storage management method is provided, the method comprising: When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing; The frequency at which the first application triggers quota limits is detected to meet the storage I / O resource adjustment conditions; wherein, the conditions for triggering quota limits include at least initiating the quota borrowing request; When it is determined that the frequency meets the storage IO resource adjustment conditions, the storage IO resource configuration item corresponding to the first application is adjusted; wherein, the storage IO resource configuration item includes at least one of the following: upper limit of write bandwidth, upper limit of read / write requests per second (IOPS), and IO scheduling weight.

[0007] Through the above technical solution, when an application's remaining quota is insufficient to meet its write requirements, it temporarily borrows quota from other applications based on quota borrowing conditions to obtain temporary quota for data writing, avoiding issues such as application lag, crashes, or functional failures due to insufficient space. Simultaneously, it continuously monitors data such as the number of times an application initiates quota borrowing requests, recording the frequency at which the application triggers quota limits. By determining whether the frequency of triggering quota limits meets the storage IO resource adjustment conditions, it accurately identifies applications that are actively writing and frequently need to borrow quota, and adaptively adjusts the storage IO resource configuration items of those applications. By limiting the excessive IO resource consumption of a single application that frequently triggers quota limits, it ensures that each application can reasonably use IO resources in scenarios with concurrent access from multiple applications. In particular, it ensures that high-priority foreground applications can not only borrow the necessary temporary quota but also use matching IO resources for continuous and stable operation. In summary, this application integrates flexible quota borrowing and dynamic IO resource adjustment to achieve coordinated optimization of storage resource allocation and IO performance, ensuring the stability of in-vehicle equipment and the user experience of various applications.

[0008] Secondly, a vehicle is provided, comprising: Memory, used to store executable program code; A processor is configured to call and run the executable program code from the memory, causing the vehicle to perform the method described in the first aspect or any possible implementation thereof. Attached Figure Description

[0009] Figure 1 This is a schematic diagram illustrating a storage management method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 5 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 6 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 7 This is a flowchart illustrating a storage management method provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of a storage management device provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a vehicle provided in an embodiment of this application. Detailed Implementation

[0010] The technical solutions in this application will be clearly and thoroughly described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. "And / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0011] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating 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.

[0012] The present application will now be described in detail with reference to specific embodiments.

[0013] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the features, information, and data involved in this application were all obtained under full authorization.

[0014] like Figure 1 As shown, Figure 1 This is a schematic diagram of a storage management method provided in an embodiment of this application. The vehicle 101 is equipped with an in-vehicle infotainment system 102, which serves as the core computing and interaction unit of the smart cockpit. Its display screen simultaneously runs multiple in-vehicle applications, such as a settings application 1031, a music application 1033, and a navigation application 1032.

[0015] The method described in this application is mainly applied to intelligent cockpit vehicle systems, and is adapted to specific scenarios where the vehicle system operates continuously for a long time, the system storage partition capacity is fixed and cannot be expanded, the foreground application has extremely high priority, and the background application has low operation frequency, which is different from the storage management solution of ordinary mobile terminals.

[0016] Specifically, the in-vehicle infotainment device 102 needs to continuously support the concurrent operation of applications such as navigation, music, and settings while the vehicle is in motion. Its storage medium is usually an embedded eMMC or UFS chip, and the system storage partition capacity is fixed at the factory and cannot be elastically expanded through external storage cards or remote cloud space. At the same time, core foreground applications such as navigation application 1032 are directly related to driving safety and driving experience, and their IO response latency will directly affect the real-time performance of user operation feedback. Background applications such as settings application 1031 and music application 1033 have relatively weaker requirements for system resources.

[0017] Therefore, this application proposes a storage management method to solve the above problems.

[0018] It is understood that the storage management solution provided in this application is not only suitable for in-vehicle systems in vehicle driving scenarios, but also for systems or terminals in other scenarios. For example, it is applicable to industrial control systems, IoT edge computing devices, avionics control systems, or rail transit vehicle-mounted control systems to ensure the stability of system and application operation.

[0019] In one embodiment, such as Figure 2 The diagram shown is a flowchart illustrating a storage management method provided in an embodiment of this application. This method can be implemented using a computer program and can run on a storage management device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0020] Specifically, the storage management method includes: S101. When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0021] The remaining quota refers to the available storage quota of the first application that has not yet been used by data. In other words, the remaining quota is the difference between the storage quota of the first application and the used quota.

[0022] By registering a listener for StorageStatsManager (android.os.storage.StorageStatsManager), you can obtain the quota usage and remaining quota for each application in real time. The monitoring period can be set to 100ms to ensure real-time detection of quota usage status.

[0023] The above example uses an in-vehicle infotainment system running Android and a Linux kernel as an illustration. The technical solution of this application can also be adapted to other operating systems (such as QNX, HarmonyOS, etc.) and different kernel architectures. It is understood that when adapted to other systems, equivalent functionality can be achieved through the corresponding interfaces, frameworks, and block device control mechanisms of that system, without departing from the technical principles of this application. For example, in the QNX system, the quota statistics interface of fs-qnx6.so can replace the interface for registering the StorageStatsManager's listener events, and inter-process quota scheduling can be implemented through the ResourceManager. As another example, in HarmonyOS, quota monitoring can be achieved through the storage event subscription mechanism of the distributed file management service, and cross-application quota negotiation can be achieved through the Ability scheduling service.

[0024] The other specific methods implemented based on the Android system and Linux kernel (including but not limited to application status monitoring, dynamic adjustment of storage quota, etc.) mentioned later are also applicable to other operating systems and kernel architectures. Those skilled in the art can implement the corresponding functions through the equivalent or similar interfaces or control mechanisms provided by each system.

[0025] Quota borrowing conditions are used to initiate a quota borrowing process, triggering at least one quota borrowing process to be sent to the second application. The quota borrowing conditions are related to the remaining quota of the first application; for example, the content of the quota borrowing conditions is that the remaining quota of the first application is 10% of the storage quota of the first application.

[0026] In one embodiment, when the remaining quota of the first application is detected to be lower than a preset quota threshold and a data write request is received from the first application, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0027] In other words, in this embodiment, the quota borrowing condition is that the remaining quota of the first application is lower than the preset quota threshold, and a data write request from the first application is received.

[0028] The system monitors the file write interface of the first application to determine whether there is a data write request from the first application, i.e., whether a write operation of the first application is being performed. When the remaining quota of the first application is lower than the preset quota threshold and a write operation needs to be performed, a quota borrowing request can be initiated from at least one second application through the custom QuotaBorrowManager interface.

[0029] The above technical solution initiates a quota borrowing process when the remaining quota of the first application is below the threshold and there is a data write request. This avoids the first application from accidentally triggering the quota borrowing process when it is only in display mode or in a low write demand state, prevents the idle quota of the second application from being occupied, and reduces the system operating burden caused by frequent quota borrowing process initiation, thereby improving the overall storage management response accuracy and the rationality of resource allocation.

[0030] After receiving a quota borrowing request, the second application automatically grants the quota based on its available quota. The authorization result is then communicated back to the first application via Binder communication. In response to the authorized quota borrowing request, the `adjustQuotaForPackage()` method of `StorageManager` can be used to temporarily increase the available quota of the first application while decreasing the available quota of the corresponding second application, without changing the second application's underlying storage quota.

[0031] For example, if the remaining quota of the navigation application 1032, which is the first application, is 1GB, and it is detected that the remaining quota of the first application is lower than the preset quota threshold (10% of the storage quota of the navigation application 1032), it initiates a quota borrowing request to the settings application 1031 and the music application 1033, which are the second applications, and borrows 3GB from the settings application 1031 and 2GB from the music application 1033, obtaining a total of 5GB of temporary quota.

[0032] S102. Check whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions.

[0033] By linking the storage quota mechanism with the IO control module, not only can the storage quota of an application be limited, but the storage IO resource configuration items of the application can also be dynamically adjusted according to the frequency of the application triggering the quota limit. This prevents a single application from frequently triggering the quota limit and consuming too many IO resources, which would affect the experience of other applications.

[0034] The IO control module can be the blkio controller in the Linux kernel cgroup subsystem, which is used to perform weighted scheduling and traffic limiting of block device (disk) IO of process groups, or it can be a module with the same or similar functions in other systems.

[0035] The custom QuotaTriggerMonitor interface counts the number of times the first application triggers the quota limit within a unit of time (e.g., 1 minute).

[0036] The conditions for triggering quota limits include at least initiating quota borrowing requests. In other words, the system detects whether the number of times a first application initiates quota borrowing requests within a preset time period meets the storage I / O resource adjustment conditions, thereby identifying applications that are active in writing and frequently need to borrow temporary quotas. For example, if it detects that the first application triggers three quota borrowing requests to multiple second applications within one minute, then it is determined that the storage I / O resource adjustment conditions are met.

[0037] S103. When it is determined that the frequency meets the storage IO resource adjustment conditions, adjust the storage IO resource configuration item corresponding to the first application.

[0038] The storage IO resource configuration items include at least one of the following: upper limit of write bandwidth, upper limit of read / write requests per second (IOPS), and IO scheduling weight.

[0039] The upper limit of write bandwidth is the maximum number of bytes of data that the first application is allowed to write to the data partition per unit time, for example, 10MB / s. The upper limit of read / write requests per second (IOPS) is the maximum number of input / output operations that the first application is allowed to initiate to the data partition per unit time, for example, 1000. IO scheduling weight is a relative priority parameter used to determine the proportion of block device service time obtained by each application when multiple applications concurrently access the data partition. For example, the IO scheduling weight of navigation application 1032 is 800, and the IO scheduling weight of music application 1033 is 200.

[0040] The adjustment range is positively correlated with the quota triggering frequency. For every preset value increase in the quota triggering frequency, the IOPS limit decreases by the first preset value (e.g., 100), or the write bandwidth limit decreases by the second preset value (e.g., 1MB / s), or the IO scheduling weight decreases by the third preset value (e.g., 100).

[0041] In other implementations, for every increase in the quota trigger frequency by a preset value, two or three of the following are adjusted: the upper limit of write bandwidth, the upper limit of read / write requests per second (IOPS), and the IO scheduling weight.

[0042] Through the above technical solution, when an application's remaining quota is insufficient to meet its write requirements, it temporarily borrows quota from other applications based on quota borrowing conditions to obtain temporary quota for data writing, avoiding issues such as application lag, crashes, or functional failures due to insufficient space. Simultaneously, it continuously monitors data such as the number of times an application initiates quota borrowing requests, recording the frequency at which the application triggers quota limits. By determining whether the frequency of triggering quota limits meets the storage IO resource adjustment conditions, it accurately identifies applications that are actively writing and frequently need to borrow quota, and adaptively adjusts the storage IO resource configuration items of those applications. By limiting the excessive IO resource consumption of a single application that frequently triggers quota limits, it ensures that each application can reasonably use IO resources in scenarios with concurrent access from multiple applications. In particular, it ensures that high-priority foreground applications can not only borrow the necessary temporary quota but also use matching IO resources for continuous and stable operation. In summary, this application integrates flexible quota borrowing and dynamic IO resource adjustment to achieve coordinated optimization of storage resource allocation and IO performance, ensuring the stability of in-vehicle equipment and the user experience of various applications.

[0043] In one embodiment, after detecting that the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain temporary quota for data writing, and then the method further includes: when detecting that the usage of the second application meets the quota return conditions, the borrowed quota belonging to the second application in the temporary quota is returned to the second application.

[0044] Quota borrowing conditions are used to initiate the quota return process. Quota borrowing conditions can be related to the running status of the second application, for example, the quota borrowing condition is when the second application returns to the foreground from the background. Quota borrowing conditions can also be related to the borrowing time, for example, when the quota borrowing time reaches a time threshold (e.g., 30 minutes, 40 minutes), the quota return process is initiated.

[0045] Specifically, when a second application returns to the foreground as a background application, the `registerActivityLifecycleCallbacks()` method of `ActivityManager` can be used to listen for application foreground switching events, immediately terminating the borrowing relationship and returning the borrowed quota from the temporary quota. Alternatively, for background applications that have not returned to the foreground, the return logic can be triggered periodically (e.g., every 30 minutes) using a `Handler` to automatically return the quota.

[0046] Understandably, in addition to using the getRunningAppProcesses() method of ActivityManager, AccessibilityService can also be used to monitor application interface switching to ensure the accuracy of identification of whether the second application has switched to the foreground application, thus adapting to the multi-task switching scenario of the vehicle system.

[0047] For example, 2GB of the 5GB temporary quota belonging to the music application 1033 is returned from the navigation application 1032.

[0048] Through the above technical solution, when the usage of the second application meets the preset return conditions, the borrowed quota belonging to the second application in the temporary quota is automatically returned to the second application. On the one hand, this ensures that the second application can promptly reclaim the borrowed quota when its own write demand increases, avoiding write failures caused by insufficient available space due to long-term quota borrowing. On the other hand, by dynamically releasing the borrowed quota, storage resources are made available again, supporting cyclical scheduling of quota borrowing among multiple applications, significantly improving the turnover efficiency and continuous availability of fixed storage space.

[0049] In one embodiment, such as Figure 3 The diagram shown is a flowchart illustrating a storage management method provided in an embodiment of this application. This method can be implemented using a computer program and can run on a storage management device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0050] Specifically, the storage management method includes: S201. Based on the quota decision information corresponding to multiple different applications, allocate the corresponding storage quota to each application.

[0051] Multiple applications include Application 1 and Application 2. Quota decision information includes at least one of the following: application priority, functional storage requirements, and historical data write volume.

[0052] Application priority refers to the application's functional importance in the vehicle system. The higher the priority, the more storage quota the application needs to ensure functional stability during vehicle system operation.

[0053] Functional storage requirements refer to the storage space requirements determined by the application's own business function characteristics, data type, and data scale. Different applications have different functional storage requirements due to functional differences. For example, map navigation applications have large functional storage requirements because they need to cache offline maps and driving trajectory data, while system tool applications have smaller functional storage requirements.

[0054] Historical data write volume refers to the total amount of data actually written to a data partition by an application within a preset statistical period. It is used to characterize the historical storage usage patterns of the application. The larger the historical data write volume, the more appropriate the storage quota should be allocated to it, so that the quota configuration matches the actual usage patterns.

[0055] In the vehicle infotainment system, a fixed storage quota is allocated to each application based on its priority, functional storage requirements, and historical write volume. Specifically, applications such as navigation and the vehicle control interface are designated as core foreground applications based on their quota allocation information, while applications like music are classified as regular foreground applications, and settings applications are designated as background applications. Core foreground applications receive higher quotas than regular foreground applications, and vice versa.

[0056] Specifically, the total capacity of the data partition is obtained through the StorageManager API (android.os.storage.StorageManager) of the Android system. The setQuotaForPackage() method of StorageManager is called to allocate the corresponding basic storage quota for each application's package name. Furthermore, the type of the application is obtained through the PackageManager API (android.content.pm.PackageManager) to determine whether the application is a core foreground application, a normal foreground application, or a background application. The quota is dynamically adjusted on the basic storage quota of the application to obtain the corresponding storage quota for each application.

[0057] For example, the storage quota for the navigation app is set to 10GB, the storage quota for the music app is set to 5GB, and the storage quota for the settings app is set to 2GB.

[0058] S202. When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0059] based on Figure 3 Please refer to the embodiments shown below. Figure 4 As shown in the implementation, S202 includes the following steps: S202-1. When the remaining quota of the first application is detected to meet the quota borrowing conditions, a quota borrowing request is initiated to at least one second application.

[0060] Once the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request can be initiated to at least one second application through the custom QuotaBorrowManager interface.

[0061] S202-2. Based on the quota borrowing request and quota lending rules, obtain a portion of the idle quota of the second application as the lending quota.

[0062] Credit lending rules are used to constrain the lending quota value of the second application. For example, the credit lending rule is that the quota that a single application can lend out does not exceed a first quota threshold of the application's idle quota, such as 40% or 50%, the idle quota is the difference between the application's storage quota and the used quota, and the total quota borrowed by a single first application from other second applications does not exceed a second quota threshold of the first application's storage quota, such as 100%.

[0063] S202-3. Obtain a temporary quota based on the lending quota of at least one second application.

[0064] The temporary quota is the sum of the lending quotas of multiple secondary applications.

[0065] Through the above technical solution, a reasonable quota lending rule is established. This quota lending rule is related to the quota lending ratio of a single application and the total quota lending ratio. Based on the quota lending rule, a portion of the idle quota of the second application is obtained as a temporary quota for the first application. While protecting the storage needs of the second application, it supports the use of idle quota to provide lending quotas to multiple first applications in parallel, thereby improving the flexibility and reliability of quota allocation.

[0066] In one embodiment, when the remaining quota of the first application meets the quota borrowing conditions, multiple pending second applications are scored according to a borrowing priority rule; at least one second application is determined based on the scores of the multiple pending second applications, and a quota borrowing request is initiated to the at least one second application to obtain temporary quota for data writing. The borrowing priority rule is related to at least one of the following: the historical activity time, background activity level, and application priority of the pending second applications.

[0067] In this embodiment, when multiple first applications simultaneously initiate quota borrowing requests, or when multiple second applications can provide idle quotas, a preset priority arbitration mechanism is used to select the borrowing object and allocate the quota. The application priority arbitration mechanism involves scoring multiple pending second applications using borrowing priority rules to determine their borrowing priority.

[0068] Specifically, the second application is scored based on three dimensions: historical activity time (or recent activity time), background activity, and application priority, with each dimension having a weight of 40%, 30%, and 30%, respectively. The second application with the highest score, or a score higher than a certain frequency threshold, or a high score is selected as the borrowing object.

[0069] Understandably, the weight can be other quantities, and the lending priority of the second application can be scored based on any two or one of the above-mentioned historical activity time, background activity, and application priority.

[0070] Among them, the historical activity time takes precedence over the last activity time of the second application within the historical time period. The lastActivityTime of the second application can be obtained through the getRunningAppProcesses() method of the ActivityManager API (android.app.ActivityManager). The longer the time, the higher the score.

[0071] The background activity of the second application is obtained by using the ActivityManager's getProcessMemoryInfo() method to get the application's memory usage. The lower the usage, the lower the activity and the higher the score. The application priority of the second application can be obtained by using the `getApplicationInfo()` method of PackageManager to get the application's priority attribute. The lower the priority, the higher the score. The priority of background applications is usually LOW or LOWEST.

[0072] The above technical solution supports the parallel initiation of quota borrowing requests to multiple eligible secondary applications. It also introduces a borrowing priority rule, or secondary application priority arbitration mechanism, to score multiple secondary applications and intelligently select at least one suitable secondary application as the quota borrowing target. The borrowing priority rule uses multi-dimensional indicators such as historical activity time, background activity, and application priority to quantitatively score applications, accurately identifying idle applications with low storage needs and avoiding impacting the operation of applications with high storage needs or high priority.

[0073] In one embodiment, there are multiple first applications, and temporary quotas are allocated to each first application according to its priority. The temporary quota for a first application is positively correlated with its priority.

[0074] Specifically, if multiple first applications simultaneously initiate quota borrowing requests to second applications, temporary quotas are allocated according to the priority of the first applications; the higher the priority, the larger the quota allocated.

[0075] For example, the priority of the navigation application is higher than that of the vehicle control application, which is higher than that of the music application, which is higher than that of other applications. A total of 5GB of temporary quota is borrowed from multiple second applications. 3GB is allocated to the navigation application as a temporary quota, and 2GB is allocated to the music application as a temporary quota.

[0076] The above technical solution introduces a first application priority arbitration mechanism to respond to the quota borrowing needs of multiple first applications at the same time, and allocates the acquired temporary quotas differently according to the priority of each first application, so as to ensure that high-priority first applications can still obtain sufficient data writing space under high storage pressure, thereby improving the efficiency of storage resource allocation in complex multi-tasking scenarios.

[0077] S203. Check whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions; See S103 above, which will not be repeated here.

[0078] S205. When it is determined that the frequency meets the storage IO resource adjustment conditions, adjust the storage IO resource configuration item corresponding to the first application.

[0079] See S104 above, which will not be repeated here.

[0080] For example, after starting the vehicle's infotainment system, the total capacity of the data partition (e.g., 64GB) is obtained through the StorageManager API. The setQuotaForPackage() method is then called to allocate basic storage quotas for the three core applications, namely 10GB for the navigation application, 5GB for the music application, and 2GB for the settings application.

[0081] The quota monitoring thread is further initialized, and a listener event is registered through StorageStatsManager. The quota usage of each application is collected every 100ms, and a preset quota threshold is set, which is that the remaining quota is less than 10% of the storage quota. Specifically, when the remaining quota of the navigation application is less than 1GB, the music application is less than 0.5GB, and the settings application is less than 0.2GB, a quota borrowing request is triggered.

[0082] Furthermore, based on preset quota borrowing conditions and priority arbitration mechanisms, the quota borrowing rules are configured (a single second application can borrow 50% of its idle quota, and the first application can borrow a total quota not exceeding 100% of its own storage quota) and the return mechanism (if the second application switches from the background to the foreground, the quota will be returned immediately; if it does not switch, the quota will be automatically returned after 30 minutes).

[0083] Furthermore, taking the navigation application, which is the core foreground application, as the first application, as an example, the navigation application continuously writes to the map cache. When the remaining quota drops to 0.8GB (that is, below the preset quota threshold of 1GB) and 2GB of data needs to be written, a quota borrowing request is initiated through the QuotaBorrowManager interface.

[0084] Furthermore, based on the priority arbitration mechanism and according to the lending priority rules, the historical activity time (last activity time 1 hour ago), background activity (memory usage rate 5%), and application priority (LOW) of the settings application (which is the second application) are obtained through ActivityManager. The application with the highest score is determined to be the lending target. The idle quota of the settings application is 1.5GB, which is obtained by subtracting the used quota of 0.5GB from the basic quota of 2GB. The lending quota is 50% of the limit quota, which is 0.75GB.

[0085] Furthermore, the second application is set to automatically grant quota borrowing requests. Through the StorageManager's adjustQuotaForPackage() method, the available quota of the navigation application is temporarily increased by 0.75GB, that is, from 0.8GB to 1.55GB, and the available quota of the application is decreased by 0.75GB, that is, from 1.5GB to 0.75GB.

[0086] Furthermore, the navigation application continues writing data. If the settings application is switched to the foreground by the user, the borrowing relationship is immediately terminated and the 0.75GB quota is returned via the ActivityManager's lifecycle listener. If no switching operation of the settings application is detected, the return logic is triggered automatically via a Handler after 30 minutes to return the quota.

[0087] In one embodiment, such as Figure 5 The diagram shown is a flowchart illustrating a storage management method provided in an embodiment of this application. This method can be implemented using a computer program and can run on a storage management device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0088] Specifically, the storage management method includes: S301. When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0089] See S101 above; it will not be repeated here.

[0090] S302. Based on the priority of the first application, set the initial value and lower limit value of the storage IO resource configuration item corresponding to the first application.

[0091] Storage I / O resource configuration items include at least one of the following: maximum write bandwidth, maximum read / write requests per second (IOPS), and I / O scheduling weight. The higher the priority of the primary application, the higher the initial value of the corresponding storage I / O resource configuration item.

[0092] Taking an Android smart cockpit in-vehicle infotainment system as an example, to enable the cgroup blkio controller in the Linux kernel of the Android smart cockpit in-vehicle infotainment system, initialize the configuration using the following commands: Create an application-specific cgroup group: `mkdir / sys / fs / cgroup / blkio / app_{packageName}`, where `packageName` is the application package name; Set the blkio weight baseline value (i.e., IO scheduling weight): `echo 500> / sys / fs / cgroup / blkio / app_{packageName} / blkio.weight`, where the baseline weight is 500, ranging from 100 to 1000; Set the initial value for the maximum number of read / write requests per second (IOPS): `echo "8:0 1000"> / sys / fs / cgroup / blkio / app_{packageName} / blkio.io_limit`, where `8:0` is the device number of the data partition, and `1000` is the baseline IOPS limit; Add the application process to the corresponding cgroup group: `echo ...` The process ID (pid) is set to `{pid}> / sys / fs / cgroup / blkio / app_{packageName} / tasks`, where pid is the application process ID, which is obtained through the `getRunningAppProcesses()` method of ActivityManager.

[0093] For the priority of the first application, a lower limit value for the storage IO resource configuration item also needs to be set. For example, as a high-priority core foreground application, the IO scheduling weight of the navigation application and the vehicle control application is set to 800. Even if the quota limit is frequently triggered, the minimum weight is not lower than 500 to ensure its IO response speed and avoid affecting the driving experience.

[0094] Through the above technical solution, the initial and lower limits of storage IO resource configuration items are set differently according to the priority of the first application. The first application with higher priority is given higher initial and lower limits, which ensures that when it faces high-frequency write-triggered IO adjustment, it still retains sufficient upper limit of write bandwidth, upper limit of input / output operations per second, and IO scheduling weight, effectively avoiding write delay or functional response lag caused by excessive reduction, and ensuring the IO response speed and operational stability of critical applications in driving scenarios.

[0095] S303. Check whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions.

[0096] See S103 above, which will not be repeated here.

[0097] S304. When it is determined that the frequency meets the storage IO resource adjustment conditions, the corresponding adjustment strategy is obtained according to the preset frequency range in which the frequency is located.

[0098] Multiple frequency ranges are preset, and each frequency range corresponds to a different adjustment strategy. The adjustment strategy includes the specific items of the storage I / O resource configuration and the reduction range.

[0099] S305. Based on the adjustment strategy, reduce at least one of the following: the upper limit of write bandwidth, the upper limit of read / write requests per second (IOPS), and the IO scheduling weight corresponding to the first application.

[0100] The quota triggering frequency is statistically analyzed using a custom QuotaTriggerMonitor interface. The number of times the quota limit is triggered within a unit of time (e.g., 1 minute) is recorded as F.

[0101] The adjustment strategy includes: the IO scheduling weight is 500. When F=0, the baseline weight is maintained; when F≥1 and≤3, the IO scheduling weight is reduced to 400; when F≥4 and≤6, the IO scheduling weight is reduced to 300; when F>6, the IO scheduling weight is reduced to 200, and the minimum weight is not lower than the lower limit of 100. The adjustment command is echo {new_weight}> / sys / fs / cgroup / blkio / app_{packageName} / blkio.weight.

[0102] The adjustment strategy also includes: a baseline IOPS limit of 1000 and a baseline write bandwidth limit of 10MB / s. The adjustment magnitude is positively correlated with the quota trigger frequency. For every 1 increase in F, the IOPS limit decreases by 100 and the write bandwidth limit decreases by 1MB / s. The minimum IOPS limit is set to 500 and the minimum write bandwidth limit is set to 5MB / s. The adjustment commands are: echo "8:0 {new_iops}"> / sys / fs / cgroup / blkio / app_{packageName} / blkio.io_limit, echo {new_bandwidth}> / sys / fs / cgroup / blkio / app_{packageName} / blkio.throttle.write_bps_device.

[0103] By introducing a tiered adjustment strategy based on preset frequency ranges, the above technical solution can precisely match the corresponding reduction range according to the frequency range in which the first application triggers quota limits. Differentiated linkage control is implemented on at least one of the first application's write bandwidth limit, maximum number of input / output operations per second, and IO scheduling weight. This ensures that the reduction range of storage IO resource configuration items matches the actual storage write pressure of the first application, achieving tiered management of storage IO resources. By limiting the IO channel occupation of storage areas by high-frequency write applications through multi-dimensional linkage, it effectively prevents data partition IO response imbalance caused by continuous large-scale writes from a single application, ensuring that each application receives reasonable block device service time in multi-application concurrent access scenarios.

[0104] In one embodiment, after adjusting the storage I / O resource configuration item corresponding to the first application when it is determined that the frequency meets the storage I / O resource adjustment conditions, the method further includes: detecting whether the frequency meets the storage I / O resource recovery conditions; and restoring the storage I / O resource configuration item to its initial value before adjustment when it is determined that the frequency meets the storage I / O resource recovery conditions.

[0105] The frequency at which the first application triggers the quota limit is continuously monitored. If the first application does not trigger the quota limit for 5 consecutive minutes (F=0), it is determined that the storage IO resource recovery conditions are met, and the storage IO resource configuration settings are automatically restored.

[0106] By establishing an automatic recovery mechanism through the above technical solution, once it is determined that the subsequent operation of the first application meets the recovery conditions, the configuration items are automatically restored to their initial values ​​before adjustment. This avoids the first application from having its IO performance suppressed for a long time due to temporary storage IO resource adjustments, ensuring that each application can obtain IO resources that match its actual needs at different operating stages, and improving the continuous scheduling capability and resource turnover efficiency of fixed storage space in scenarios where multiple applications coexist for a long time.

[0107] For example, initialize the cgroup blkio controller, create dedicated cgroup groups for three applications, and set baseline weights, with the navigation application at 800, the music application at 500, and the settings application at 500. The baseline IOPS limit for each application is 1000, and the baseline write bandwidth limit is 10MB / s.

[0108] When the music application is detected to be frequently writing to the cache, the quota limit is triggered 5 times within 1 minute (F=5). The quota triggering frequency is high, so its blkio weight (IO scheduling weight) is adjusted to 300, the IOPS limit is reduced to 500, and the write bandwidth limit is reduced to 5MB / s.

[0109] If the navigation application is detected to have triggered the quota limit twice (F=2), its weight will be reduced to 700. The lower limit of the navigation application's IO scheduling weight will be 500, the upper limit of IOPS will be reduced to 800, and the upper limit of write bandwidth will be reduced to 8MB / s to ensure its IO response speed.

[0110] If the music application fails to trigger the quota limit (F=0) for 5 consecutive minutes, the baseline weight of 500, IOPS limit of 1000, and bandwidth limit of 10MB / s will be automatically restored.

[0111] In one embodiment, such as Figure 6 The diagram shown is a flowchart illustrating a storage management method provided in an embodiment of this application. This method can be implemented using a computer program and can run on a storage management device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0112] Specifically, the storage management method includes: S401. When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0113] See S101 above; it will not be repeated here.

[0114] S402. When it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area.

[0115] When it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, that is, when the temporary quota borrowed by the first application is still insufficient to meet the writing demand, a transparent compression temporary overflow mechanism is activated. The data to be written is transparently compressed and then stored in a preset temporary overflow area. The compression process is invisible to the application layer. In other words, the application does not need to modify any code and continues to execute according to the normal writing logic.

[0116] Overflow data refers to the portion of the data to be written that exceeds the sum of the temporary quota and the remaining quota. For example, if the navigation application 1032, which is the first application, has a remaining quota of 1GB, receives a temporary quota of 5GB, and the amount of data to be written is 7.5GB, then the amount of overflow data in the data to be written is 1.5GB.

[0117] The compression process can intercept file write requests from the first application through a custom TransparentCompressManager interface (using Hook technology to intercept the write() method of java.io.FileOutputStream), compress the written data in real time, and store it in a temporary overflow area at the path / data / overflow.

[0118] S403. Check whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions.

[0119] The conditions for triggering quota limits include at least initiating a quota borrowing request. In one embodiment, the conditions for triggering quota limits also include the amount of data to be written exceeding the temporary quota.

[0120] Specifically, it obtains the total number of times within a preset time period that the amount of data to be written for flexible quota borrowing and flexible quota borrowing exceeds the total number of times the temporary quota is borrowed, and checks whether the total number of flexible quota borrowings meets the storage IO resource adjustment conditions.

[0121] In other words, the storage I / O resource adjustment conditions are the number of times the first application initiates a quota borrowing request within a preset time period and the number of times the amount of data to be written is determined, that is, the number of times the first application's quota is insufficient and still insufficient after borrowing quota. For example, within a preset time period of 1 minute, if it is detected that the first application initiates a quota borrowing request once, the number of times the amount of data to be written exceeds the temporary quota after obtaining the temporary quota is 1, and the first application initiates a quota borrowing request again, then it is determined that the frequency at which the first application triggers the quota limit meets the storage I / O resource adjustment conditions.

[0122] By using the above technical solution, both the initiation of a quota borrowing request and the amount of data to be written exceeding the temporary quota are used as the conditions for triggering quota restrictions. This significantly improves the accuracy of identifying applications with high write pressure and frequent IO resource consumption, and provides objective data basis for subsequent dynamic adjustment of storage IO resource configuration items.

[0123] S404. When it is determined that the frequency meets the storage IO resource adjustment conditions, adjust the storage IO resource configuration item corresponding to the first application.

[0124] See S103 above, which will not be repeated here.

[0125] In one embodiment, such as Figure 7 The diagram shown is a flowchart illustrating a storage management method provided in an embodiment of this application. This method can be implemented using a computer program and can run on a storage management device based on the von Neumann architecture. The computer program can be integrated into an application or run as a standalone utility application.

[0126] Specifically, the storage management method includes: S501. When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing.

[0127] See S101 above; it will not be repeated here.

[0128] S502. Set up a temporary overflow area and establish a metadata management mechanism for the temporary overflow area.

[0129] The temporary overflow area has a capacity limit that is a preset proportion of the total storage area capacity, and the metadata management mechanism is used to record the decompression and migration information of the overflow data.

[0130] Specifically, a temporary overflow area can be mounted using the Android system's mount command. The upper limit of the overflow area size can be set, for example, the upper limit of the overflow area capacity can be 15% of the total capacity of the data partition, and the EXT4 file system can be used to support real-time read and write and compressed data storage.

[0131] At the same time, a temporary overflow area metadata management mechanism is established, which records information such as the original storage path, compression algorithm type, compression time, and decompression priority of compressed data through an SQLite database, so as to facilitate subsequent decompression and migration.

[0132] By implementing the above technical solution, a temporary overflow area with a capacity limit and a metadata management mechanism are set up to provide emergency storage buffer space for the first application that exceeds the storage quota and temporary quota. The preset capacity limit ensures that the overflow area has sufficient emergency carrying capacity while preventing it from excessively encroaching on the basic operating space of the storage area. Furthermore, the metadata management mechanism records the decompression and migration information of the overflow data, providing accurate path guidance and algorithmic basis for subsequent data migration. This ensures that compressed data can be completely and accurately migrated back to its original storage location, avoiding data loss or migration errors.

[0133] S503. When it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, the processor load is obtained.

[0134] Processor load refers to the resource utilization of a processor at a specific moment or within a statistical period, usually expressed as a percentage. It reflects the proportion of the central processing unit's current time spent executing computational tasks out of the total available time. A low percentage indicates that the processor is relatively idle and there are still sufficient computing resources available; a high percentage indicates that the processor is operating under high load and the remaining available computing resources are relatively scarce.

[0135] S504. Compare the processor load with a preset load threshold, and match the target compression algorithm among multiple preset compression algorithms based on the comparison result.

[0136] A dynamic compression algorithm selection mechanism based on processor load is introduced. This mechanism matches a suitable target compression algorithm from multiple preset algorithms based on a comparison between the current processor load and a preset threshold. This includes prioritizing algorithms with higher compression ratios when the processor load is low, significantly reducing the physical space occupied by overflowing data, and automatically switching to faster compression algorithms when the processor load is high, reducing the processor resource consumption during compression and avoiding impact on the real-time response performance of the primary application. Furthermore, this dynamic selection process is transparent to the primary application, achieving adaptive compression without modifying any application-layer code.

[0137] Specifically, taking LZ4 or Zstd real-time compression algorithm as the preset compression algorithm as an example, the specific steps are as follows: Get the current CPU load (percentage) using the android.os.Process.getSystemCpuLoad() method, and set the preset load threshold to 70%.

[0138] When the CPU load is below a preset load threshold, the Zstd algorithm is selected as the target compression algorithm. The Zstd algorithm is characterized by a high compression ratio, which can reach 30%-50%. The Java interface of the Zstd algorithm (org.zstd.Zstd.compress()) is called, and the compression level is set to 3 to balance the compression ratio and speed.

[0139] When the CPU load exceeds a preset load threshold, the LZ4 algorithm is selected as the target compression algorithm. The LZ4 algorithm is characterized by its high speed, with a compression speed 2-3 times faster than the Zstd algorithm. The Java interface for the LZ4 algorithm (net.jpountz.lz4.LZ4Factory.fastCompressor().compress()) can be called to adopt the LZ4 Fast mode, ensuring that the compression process does not consume excessive CPU resources and does not affect the responsiveness of the foreground application.

[0140] In the above example, the compression algorithm can be optimized. Specifically, the LZ4 / Zstd algorithm is compiled into an Android executable file using a native C library and called through the JNI interface, thereby improving compression / decompression speed and reducing CPU usage.

[0141] It is understood that the above description uses LZ4 or Zstd real-time compression algorithms as examples of preset compression algorithms. This application may also include other types of preset compression algorithms, so as to match a reasonable target compression algorithm among multiple preset compression algorithms based on the comparison results of processor load and preset load threshold.

[0142] S505. Based on the target compression algorithm, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area.

[0143] In one embodiment, when the available space in the detected storage area meets the migration conditions, the overflow data is decompressed and migrated back to the target storage area corresponding to the first application based on the decompression and migration information of the overflow data; the compressed data included in the temporary overflow area is deleted.

[0144] Specifically, the StorageManager monitors the available space of the data partition. When a user cleans up storage space by deleting useless files, uninstalling applications, etc., and the available space of the data partition is greater than 20% of the total capacity, the migration conditions are met, and the decompression and migration process is automatically triggered.

[0145] Based on the metadata recorded in the SQLite database through the metadata management mechanism, the decompression interface (Zstd.decompress(), LZ4Factory.fastDecompressor().decompress()) of the corresponding compression algorithm is called to decompress the compressed data in the temporary overflow area. The decompression process is unknown to the application layer.

[0146] After the compressed data is decompressed, the overflow data obtained from the decompression is moved back to the original storage location, that is, the target storage area corresponding to the first application, and the quota usage of the first application is updated. At the same time, the compressed data in the temporary overflow area is deleted.

[0147] By establishing an automatic decompression and migration mechanism through the above technical solution, when the available space in the storage area is detected to meet the preset migration conditions, the compressed data in the temporary overflow area is accurately decompressed and migrated back to the target storage area corresponding to the first application based on the decompression and migration information of the overflow data, and the corresponding overflow data in the temporary overflow area is deleted. This not only ensures the integrity and consistency of the first application data, but also releases the occupied space of the temporary overflow area in a timely manner through the automatic cleanup operation after migration, so as to meet the subsequent possible compression overflow needs.

[0148] In one embodiment, when the available space in the detected storage area meets the migration conditions, it is determined whether the amount of overflow data is greater than a preset data threshold; when it is determined that the amount of overflow data is greater than the preset data threshold, the overflow data is decompressed and migrated back to the target storage area corresponding to the first application in batches.

[0149] If the amount of compressed data in the temporary overflow area is large, a batch decompression and migration strategy is adopted, and the compressed data of the first application with the highest priority is migrated back first.

[0150] By introducing a batch migration strategy through the above technical solution, storage IO peaks and system lag caused by a large amount of overflow data during a single decompression and migration are avoided, ensuring the stability of the overall system IO performance. Furthermore, batch processing reduces the risk of failure of a single migration operation, because an anomaly in a particular batch will not lead to the loss or damage of all data, thus improving the reliability and fault tolerance of data migration.

[0151] In one embodiment, when the temporary overflow area occupancy rate reaches the capacity limit threshold (e.g., 90% of the capacity limit), the LRU (Least Recently Used) strategy is used to evict the least recently accessed compressed data. This is achieved by recording the last access time of the compressed data and deleting the data with the earliest last access time, thereby ensuring that the temporary overflow area has enough space to store new compressed data and avoiding the overflow area being full and unable to compress and write.

[0152] S506. Check whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions.

[0153] See S102 above, which will not be repeated here.

[0154] S507. When it is determined that the frequency meets the storage IO resource adjustment conditions, adjust the storage IO resource configuration item corresponding to the first application.

[0155] See S103 above, which will not be repeated here.

[0156] For example, a temporary overflow area ( / data / overflow) is mounted, with a capacity limit of 9.6GB, which is 15% of the total storage area of ​​64GB. An SQLite metadata database is also established to record the decompression and migration information of compressed data through the metadata management mechanism.

[0157] After the navigation application borrows 0.75GB of quota, the available quota is 1.55GB. It still needs to write 2GB of data. It is determined that the amount of data to be written by the first application exceeds the temporary quota, thus triggering the transparent compression logic.

[0158] Furthermore, the Process.getSystemCpuLoad() method is used to obtain the current CPU load as 65%, which determines that the processor load is lower than the preset load threshold of 70%. The Zstd algorithm is selected as the target compression algorithm, and the Zstd.compress() method is called to compress the remaining 0.45GB of data to be written, resulting in a compressed size of approximately 0.225GB.

[0159] Furthermore, the compressed data is stored in a temporary overflow area, and the original storage path ( / data / data / com.example.navigation / cache / map), compression algorithm (Zstd), compression time, decompression priority, and other decompression migration information are recorded through an SQLite database. The compression process is invisible to the navigation application.

[0160] When a user cleans up storage space, such as deleting useless music files and freeing up 8GB of space, the available space of the data partition reaches 12GB, which is more than 20% of the total capacity of the data partition. When the available space of the storage area meets the migration conditions, the decompression and migration logic is triggered.

[0161] Furthermore, based on the metadata record management mechanism, the Zstd.decompress() method is called to decompress the compressed data. After decompression, the data is moved back to the original storage path, which is the target storage area corresponding to the first application. The quota usage of the navigation application is updated, and the corresponding compressed data in the temporary overflow area is deleted.

[0162] Furthermore, when the temporary overflow area occupancy rate reaches 90% of the temporary overflow area's capacity limit (8.64GB), an LRU strategy is adopted to delete the configuration application compression data with the earliest last access time, thereby freeing up space.

[0163] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0164] Please see Figure 8 This illustration shows a schematic diagram of a storage management device provided in an exemplary embodiment of this application. The storage management device can be implemented as all or part of a device through software, hardware, or a combination of both. The device includes a quota borrowing module 601, a dynamic compression module 602, an adjustment detection module 602, and a resource adjustment module 603.

[0165] The quota borrowing module 601 is used to initiate a quota borrowing request to at least one second application when the remaining quota of the first application meets the quota borrowing conditions, so as to obtain a temporary quota for data writing. The adjustment detection module 602 is used to detect whether the frequency at which the first application triggers the quota limit meets the storage IO resource adjustment conditions. The resource adjustment module 603 is used to adjust the storage IO resource configuration items corresponding to the first application when it is determined that the frequency meets the storage IO resource adjustment conditions; wherein, the storage IO resource configuration items include at least one of the following: upper limit of write bandwidth, upper limit of read / write requests per second (IOPS), and IO scheduling weight.

[0166] In one or more embodiments, the storage management device further includes: The quota allocation module is used to allocate a corresponding storage quota to each application based on the quota decision information corresponding to multiple different applications; wherein, the multiple applications include the first application and the second application, and the quota decision information includes at least one of the application's priority, functional storage requirements, and historical data write volume.

[0167] In one or more embodiments, the quota borrowing module 601 is specifically configured to: when the remaining quota of the first application is detected to meet the quota borrowing conditions, initiate a quota borrowing request to at least one second application; according to the quota borrowing request and the quota borrowing rules, obtain a portion of the idle quota of the second application as the borrowed quota; and obtain a temporary quota based on the borrowed quota of at least one second application.

[0168] In one or more embodiments, the quota borrowing module 601 is specifically configured to: when detecting that the remaining quota of the first application meets the quota borrowing conditions, score multiple second applications to be determined according to the borrowing priority rule; wherein, the borrowing priority rule is related to at least one of the historical activity time, background activity and application priority of the second applications to be determined; determine at least one second application according to the scores of the multiple second applications to be determined, and initiate a quota borrowing request to the at least one second application to obtain a temporary quota for data writing.

[0169] In one or more embodiments, the storage management device further includes: The priority allocation module is used to allocate the temporary quota to each of the first applications according to the priority corresponding to each of the multiple first applications; wherein the temporary quota of the first application is positively correlated with the priority of the first application.

[0170] In one or more embodiments, the condition for triggering the quota limit further includes the amount of data to be written exceeding the temporary quota. The adjustment detection module 602 is specifically used to: obtain the total number of times the quota borrowing request is initiated and the amount of data to be written exceeds the temporary quota within a preset time period, and detect whether the total number of times meets the storage IO resource adjustment condition.

[0171] In one or more embodiments, the resource adjustment module 603 is specifically configured to: when it is determined that the frequency meets the storage IO resource adjustment conditions, obtain a corresponding adjustment strategy according to the preset frequency range in which the frequency is located; and based on the adjustment strategy, reduce at least one of the following: the upper limit of the write bandwidth corresponding to the first application, the upper limit of the number of read / write requests per second (IOPS), and the IO scheduling weight.

[0172] In one or more embodiments, the storage management device further includes: The configuration settings module is used to set the initial value and lower limit value of the storage IO resource configuration item corresponding to the first application according to the priority of the first application.

[0173] In one or more embodiments, the storage management device further includes: The dynamic compression module is used to dynamically compress the overflow data in the data to be written when it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, so as to obtain compressed data and store it in the temporary overflow area.

[0174] In one or more embodiments, the storage management device further includes: The management module is used to set up a temporary overflow area and establish a metadata management mechanism for the temporary overflow area; wherein, the upper limit of the capacity of the temporary overflow area is a preset proportion of the total capacity of the storage area, and the metadata management mechanism is used to record the decompression and migration information of the overflow data.

[0175] In one or more embodiments, the dynamic compression module is specifically configured to: when it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, obtain the processor load; compare the processor load with a preset load threshold, and match a target compression algorithm among multiple preset compression algorithms based on the comparison result; and dynamically compress the overflow data in the data to be written based on the target compression algorithm to obtain compressed data and store it in a temporary overflow area.

[0176] Through the above technical solution, when an application's remaining quota is insufficient to meet its write requirements, it temporarily borrows quota from other applications based on quota borrowing conditions to obtain temporary quota for data writing, avoiding issues such as application lag, crashes, or functional failures due to insufficient space. Simultaneously, it continuously monitors data such as the number of times an application initiates quota borrowing requests, recording the frequency at which the application triggers quota limits. By determining whether the frequency of triggering quota limits meets the storage IO resource adjustment conditions, it accurately identifies applications that are actively writing and frequently need to borrow quota, and adaptively adjusts the storage IO resource configuration items of those applications. By limiting the excessive IO resource consumption of a single application that frequently triggers quota limits, it ensures that each application can reasonably use IO resources in scenarios with concurrent access from multiple applications. In particular, it ensures that high-priority foreground applications can not only borrow the necessary temporary quota but also use matching IO resources for continuous and stable operation. In summary, this application integrates flexible quota borrowing and dynamic IO resource adjustment to achieve coordinated optimization of storage resource allocation and IO performance, ensuring the stability of in-vehicle equipment and the user experience of various applications.

[0177] It should be noted that the storage management device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the storage management method. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the storage management device and the storage management method embodiments provided in the above embodiments belong to the same concept, and the implementation process can be found in the method embodiments, which will not be repeated here.

[0178] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0179] This application also provides a computer storage medium that can store multiple instructions, which are adapted to be loaded and executed by a processor as described above. Figure 1 - Figure 7 The storage management method of the illustrated embodiment can be found in the following document for a detailed execution process. Figure 1 - Figure 7 The specific details of the illustrated embodiments will not be elaborated here.

[0180] This application also provides a computer program product that stores at least one instruction, which is loaded and executed by a processor as described above. Figure 1 - Figure 7 The storage management method of the illustrated embodiment can be found in the following document for a detailed execution process. Figure 1 - Figure 7 The specific details of the illustrated embodiments will not be elaborated here.

[0181] Please see Figure 9 This provides a structural schematic diagram of a vehicle according to an embodiment of this application. Figure 9 As shown, vehicle 600 may include: at least one processor 701, at least one network interface 604, user interface 603, memory 605, and at least one communication bus 602.

[0182] The communication bus 602 is used to enable communication between these components.

[0183] The user interface 603 may include a display screen and a camera. Optionally, the user interface 603 may also include a standard wired interface and a wireless interface.

[0184] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0185] The processor 701 may include one or more processing cores. The processor 701 connects to various parts within the vehicle 600 using various interfaces and lines, and performs various functions and processes data of the vehicle 600 by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the processor 701 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 701 may integrate one or more of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 701 and may be implemented as a separate chip.

[0186] The memory 605 may include random access memory (RAM) or read-only memory. Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 605 may also be at least one storage device located remotely from the aforementioned processor 701. Figure 9 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a storage management application.

[0187] exist Figure 9 In the vehicle 600 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 701 can be used to call the storage management application stored in the memory 605 and specifically perform the following operations: When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing; When it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area. Detect whether the frequency at which the first application triggers quota limits meets the storage I / O resource adjustment conditions; When it is determined that the frequency meets the storage IO resource adjustment conditions, the storage IO resource configuration item corresponding to the first application is adjusted; wherein, the storage IO resource configuration item includes at least one of the following: upper limit of write bandwidth, upper limit of read / write requests per second (IOPS), and IO scheduling weight.

[0188] In one or more embodiments, before the processor 701 executes the step of initiating a quota borrowing request to at least one second application to obtain temporary quota for data writing when it detects that the remaining quota of the first application meets the quota borrowing conditions, it also executes: Based on the quota decision information corresponding to multiple different applications, a corresponding storage quota is allocated to each application; wherein, the multiple applications include the first application and the second application, and the quota decision information includes at least one of the application's priority, functional storage requirements, and historical data write volume.

[0189] In one or more embodiments, the processor 701 executes the following: when the remaining quota of the first application is detected to meet the quota borrowing condition, it initiates a quota borrowing request to at least one second application to obtain a temporary quota for data writing, and performs the following: When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application; Based on the quota borrowing request and quota lending rules, a portion of the idle quota of the second application is obtained as the lending quota; A temporary quota is obtained based on the lending quota of at least one of the second applications.

[0190] In one or more embodiments, the processor 701 executes the following: when the remaining quota of the first application is detected to meet the quota borrowing condition, it initiates a quota borrowing request to at least one second application to obtain a temporary quota for data writing, and performs the following: When the remaining quota of the first application meets the quota borrowing conditions, multiple second applications to be determined are scored according to the borrowing priority rule; wherein, the borrowing priority rule is related to at least one of the historical activity time, background activity and application priority of the second applications to be determined. Based on the scores of the multiple second applications to be determined, at least one second application is identified, and a quota borrowing request is initiated to the at least one second application to obtain a temporary quota for data writing.

[0191] In one or more embodiments, the processor 701 executes multiple instances of the first application. After detecting that the remaining quota of the first application meets the quota borrowing condition, and initiating a quota borrowing request to at least one second application to obtain a temporary quota for data writing, the processor further executes: The temporary quota is allocated to each of the first applications according to their respective priorities; wherein the temporary quota of the first application is positively correlated with the priority of the first application.

[0192] In one or more embodiments, the condition for triggering the quota limit further includes the amount of data to be written exceeding the temporary quota, and the processor 701 executes the step of detecting whether the frequency of the first application triggering the quota limit meets the storage I / O resource adjustment condition, and executes: The system obtains the total number of times within a preset time period that the quota borrowing request and the amount of data to be written exceed the temporary quota, and checks whether the total number of times meets the storage IO resource adjustment conditions.

[0193] In one or more embodiments, processor 701 performs the following: when it is determined that the frequency meets the storage I / O resource adjustment conditions, adjusts the storage I / O resource configuration item corresponding to the first application, and executes: When it is determined that the frequency meets the storage I / O resource adjustment conditions, the corresponding adjustment strategy is obtained according to the preset frequency range in which the frequency is located. Based on the adjustment strategy, at least one of the following will be reduced: the upper limit of write bandwidth, the upper limit of read / write requests per second (IOPS), and the IO scheduling weight corresponding to the first application.

[0194] In one or more embodiments, before processor 701 performs the step of adjusting the storage I / O resource configuration item corresponding to the first application when it is determined that the frequency meets the storage I / O resource adjustment conditions, it further performs the following: Based on the priority of the first application, set the initial value and lower limit value of the storage IO resource configuration item corresponding to the first application.

[0195] In one or more embodiments, after processor 701 executes the step of initiating a quota borrowing request to at least one second application to obtain temporary quota for data writing when detecting that the remaining quota of the first application meets the quota borrowing condition, and before detecting whether the frequency of the first application triggering quota limits meets the storage I / O resource adjustment condition, it further executes: When it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area.

[0196] In one or more embodiments, before the processor 701 performs the following steps: when it determines that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, dynamically compresses the overflow data in the data to be written to obtain compressed data and stores it in the temporary overflow area, the processor 701 further performs the following steps: A temporary overflow area is set up, and a metadata management mechanism for the temporary overflow area is established; wherein, the upper limit of the capacity of the temporary overflow area is a preset proportion of the total capacity of the storage area, and the metadata management mechanism is used to record the decompression and migration information of the overflow data.

[0197] In one or more embodiments, the processor 701 executes the following: when it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, dynamically compresses the overflow data in the data to be written to obtain compressed data and stores it in the temporary overflow area. When it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, the processor load is obtained; The processor load is compared with a preset load threshold, and the target compression algorithm is matched among multiple preset compression algorithms based on the comparison result; Based on the target compression algorithm, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in a temporary overflow area.

[0198] Through the above technical solution, when an application's remaining quota is insufficient to meet its write requirements, it temporarily borrows quota from other applications based on quota borrowing conditions to obtain temporary quota for data writing, avoiding issues such as application lag, crashes, or functional failures due to insufficient space. Simultaneously, it continuously monitors data such as the number of times an application initiates quota borrowing requests, recording the frequency at which the application triggers quota limits. By determining whether the frequency of triggering quota limits meets the storage IO resource adjustment conditions, it accurately identifies applications that are actively writing and frequently need to borrow quota, and adaptively adjusts the storage IO resource configuration items of those applications. By limiting the excessive IO resource consumption of a single application that frequently triggers quota limits, it ensures that each application can reasonably use IO resources in scenarios with concurrent access from multiple applications. In particular, it ensures that high-priority foreground applications can not only borrow the necessary temporary quota but also use matching IO resources for continuous and stable operation. In summary, this application integrates flexible quota borrowing and dynamic IO resource adjustment to achieve coordinated optimization of storage resource allocation and IO performance, ensuring the stability of in-vehicle equipment and the user experience of various applications.

[0199] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented. Each of the above methods can be executed by a computer program instructing related hardware. The program corresponding to each method can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The storage medium of the electronic device 700 can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0200] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0201] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application are still within the scope of this application.

Claims

1. A storage management method, characterized in that, The method includes: When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing; The frequency at which the first application triggers quota limits is detected to meet the storage I / O resource adjustment conditions; wherein, the conditions for triggering quota limits include at least initiating the quota borrowing request; When it is determined that the frequency meets the storage IO resource adjustment conditions, the storage IO resource configuration item corresponding to the first application is adjusted; wherein, the storage IO resource configuration item includes at least one of the following: upper limit of write bandwidth, upper limit of read / write requests per second (IOPS), and IO scheduling weight.

2. The storage management method according to claim 1, characterized in that, Before initiating a quota borrowing request to at least one second application to obtain temporary quota for data writing when the remaining quota of the first application meets the quota borrowing conditions, the method further includes: Based on the quota decision information corresponding to multiple different applications, a corresponding storage quota is allocated to each application; wherein, the multiple applications include the first application and the second application, and the quota decision information includes at least one of the application's priority, functional storage requirements, and historical data write volume.

3. The storage management method according to claim 1, characterized in that, When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing, including: When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application; Based on the quota borrowing request and quota lending rules, a portion of the idle quota of the second application is obtained as the lending quota; A temporary quota is obtained based on the lending quota of at least one of the second applications.

4. The storage management method according to claim 1, characterized in that, When the remaining quota of the first application meets the quota borrowing conditions, a quota borrowing request is initiated to at least one second application to obtain a temporary quota for data writing, including: When the remaining quota of the first application meets the quota borrowing conditions, multiple second applications to be determined are scored according to the borrowing priority rule; wherein, the borrowing priority rule is related to at least one of the historical activity time, background activity and application priority of the second applications to be determined. Based on the scores of the multiple second applications to be determined, at least one second application is identified, and a quota borrowing request is initiated to the at least one second application to obtain a temporary quota for data writing.

5. The storage management method according to claim 1 or 4, characterized in that, The first application has multiple components. After detecting that the remaining quota of the first application meets the quota borrowing conditions, and initiating a quota borrowing request to at least one second application to obtain a temporary quota for data writing, the method further includes: The temporary quota is allocated to each of the first applications according to their respective priorities; wherein the temporary quota of the first application is positively correlated with the priority of the first application.

6. The storage management method according to claim 1, characterized in that, The conditions for triggering the quota limit also include the amount of data to be written exceeding the temporary quota; The step of detecting whether the frequency at which the first application triggers quota limits meets the storage I / O resource adjustment conditions includes: The system obtains the total number of times within a preset time period that the quota borrowing request and the amount of data to be written exceed the temporary quota, and checks whether the total number of times meets the storage IO resource adjustment conditions.

7. The storage management method according to claim 1, characterized in that, When it is determined that the frequency meets the storage I / O resource adjustment conditions, adjusting the storage I / O resource configuration item corresponding to the first application includes: When it is determined that the frequency meets the storage I / O resource adjustment conditions, the corresponding adjustment strategy is obtained according to the preset frequency range in which the frequency is located. Based on the adjustment strategy, at least one of the following will be reduced: the upper limit of write bandwidth, the upper limit of read / write requests per second (IOPS), and the IO scheduling weight corresponding to the first application.

8. The storage management method according to claim 1, characterized in that, Before adjusting the storage I / O resource configuration item corresponding to the first application when it is determined that the frequency meets the storage I / O resource adjustment conditions, the method further includes: Based on the priority of the first application, set the initial value and lower limit value of the storage IO resource configuration item corresponding to the first application.

9. The storage management method according to claim 1, characterized in that, After initiating a quota borrowing request to at least one second application to obtain temporary quota for data writing when the remaining quota of the first application meets the quota borrowing conditions, and before detecting whether the frequency of the first application triggering quota limits meets the storage I / O resource adjustment conditions, the method further includes: When it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area.

10. The storage management method according to claim 1, characterized in that, Before dynamically compressing the overflow data in the data to be written to obtain compressed data and storing it in the temporary overflow area when it is determined that the amount of data to be written in the first application exceeds the sum of the temporary quota and the remaining quota, the method further includes: A temporary overflow area is set up, and a metadata management mechanism for the temporary overflow area is established; wherein, the upper limit of the capacity of the temporary overflow area is a preset proportion of the total capacity of the storage area, and the metadata management mechanism is used to record the decompression and migration information of the overflow data.

11. The storage management method according to claim 9, characterized in that, When it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in the temporary overflow area, including: When it is determined that the amount of data to be written by the first application exceeds the sum of the temporary quota and the remaining quota, the processor load is obtained; The processor load is compared with a preset load threshold, and the target compression algorithm is matched among multiple preset compression algorithms based on the comparison result; Based on the target compression algorithm, the overflow data in the data to be written is dynamically compressed to obtain compressed data and stored in a temporary overflow area.

12. A vehicle, characterized in that, The vehicles include: Memory, used to store executable program code; A processor for calling and running the executable program code from the memory, causing the vehicle to perform the method as described in any one of claims 1 to 11.

Images