WO2020062985A1

WO2020062985A1 - Block device access tracking method and apparatus, storage medium and terminal

Info

Publication number: WO2020062985A1
Application number: PCT/CN2019/093718
Authority: WO
Inventors: 周明君; 方攀; 陈岩
Original assignee: Oppo广东移动通信有限公司
Priority date: 2018-09-26
Filing date: 2019-06-28
Publication date: 2020-04-02
Also published as: CN110955584A; CN110955584B

Abstract

Disclosed are a block device access tracking method and apparatus, a storage medium and a terminal. Said method comprises: when a preset block device access event is triggered, if it is determined that there is a preset program code written on the basis of a preset virtual machine in a kernel space before a function to be invoked corresponding to the preset block device access event, acquiring, by means of the preset program code, block device access information corresponding to the function to be invoked; and storing the block device access information in a storage format corresponding to the preset virtual machine for user space reading.

Description

Block device access tracking method and device, storage medium and terminal

This application claims priority from a Chinese patent application filed with the Chinese Patent Office on September 26, 2018, with application number 201811125064.9, the entire contents of which are incorporated herein by reference.

Technical field

The embodiments of the present application relate to the technical field of terminals, for example, to a method and device for tracking access to a block device, a storage medium, and a terminal.

Background technique

At present, in the operating system of the terminal, access to various types of files is relatively frequent, and access to files also generates access to block devices. How to optimize access to block devices is an important part of the system optimization topic.

When studying the optimization of access to block devices, it is usually necessary to track the access to block devices to understand the relevant information when the block devices are accessed. However, the related file tracking scheme is still not perfect and needs to be improved.

Summary of the Invention

The embodiments of the present application provide a method, an apparatus, a storage medium, and a terminal for tracking access to a block device, which can optimize a block device access tracking solution.

In a first aspect, an embodiment of the present application provides a method for tracking access to a block device, including:

When a preset block device access event is triggered, determining whether there is a preset program code written based on a preset virtual machine in a kernel space before a function to be called corresponding to the preset block device access event;

If it exists, obtaining the block device access information corresponding to the function to be called through the preset program code;

The block device access information is stored in a storage format corresponding to the preset virtual machine for user space reading.

In a second aspect, an embodiment of the present application provides a block device access tracking apparatus, including:

A judging module configured to determine, when a preset block device access event is triggered, whether a preset program code written based on a preset virtual machine exists in a kernel space before a function to be called corresponding to the preset block device access event;

The access information acquisition module is configured to acquire, when the judgment result of the judgment module is present, the access information of the block device corresponding to the function to be called through the preset program code;

The access information storage module is configured to store the block device access information in a storage format corresponding to the preset virtual machine for user space to read.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the block device access tracking method according to the embodiment of the present application is implemented.

In a fourth aspect, an embodiment of the present application provides a terminal, including a memory, a processor, and a computer program stored in the memory and executable by the processor. When the processor executes the computer program, the implementation is implemented as in the embodiment of the present application. The block device access tracking method.

Overview of the drawings

FIG. 1 is a schematic flowchart of a method for tracking access to a block device according to an embodiment of the present application; FIG.

FIG. 2 is a schematic flowchart of another block device access tracking method according to an embodiment of the present application; FIG.

FIG. 3 is a schematic flowchart of still another block device access tracking method according to an embodiment of the present application; FIG.

4 is a structural block diagram of a block device access tracking apparatus according to an embodiment of the present application;

5 is a schematic structural diagram of a terminal according to an embodiment of the present application;

FIG. 6 is a schematic structural diagram of still another terminal provided by an embodiment of the present application.

detailed description

The technical solutions of the present application will be further described below with reference to the accompanying drawings and specific embodiments. It can be understood that the specific embodiments described herein are only used to explain the present application, rather than limiting the present application. In addition, it should be noted that, for convenience of description, only some parts related to the present application are shown in the drawings instead of the entire structure.

Before discussing the exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although flowcharts describe steps as sequential processing, many of these steps can be performed in parallel, concurrently, or simultaneously. In addition, the order of the steps can be rearranged. The process may be terminated when its operation is completed, but may also have additional steps not included in the drawings. The processing may correspond to methods, functions, procedures, subroutines, subroutines, and so on.

FIG. 1 is a schematic flowchart of a block device access tracking method according to an embodiment of the present application. The method may be executed by a block device access tracking device, where the device may be implemented by software and / or hardware, and may generally be integrated in a terminal. As shown in FIG. 1, the method includes

steps

101, 102 and 103.

In step 101, when a preset block device access event is triggered, it is determined whether there is a preset program code written based on a preset virtual machine in a kernel space before a function to be called corresponding to the preset block device access event.

Exemplarily, the terminal in the embodiment of the present application may include a device provided with an operating system, such as a mobile phone, a tablet computer, a notebook computer, a computer, and a smart home appliance.

The type of the operating system is not limited in the embodiments of the present application, and may include, for example, an Android operating system, a Windows operating system, and an Apple operating system. For many operating systems, the kernel is generally implemented based on Linux. Input / output (I / O) devices in Linux are mainly divided into two types, character devices and block devices. The two devices themselves are not strictly limited, but are based on different functions. Classification. Character devices can provide a continuous data stream, and applications can read them sequentially. Usually, random access is not supported. On the contrary, such devices support byte / character reading and writing of data. For example, keyboards, serial ports, and modems are all Typical character device. For block devices, information is stored in fixed-size blocks. Each block has its own address. Applications can access the device data randomly. The program can determine where to read the data. Hard disks, floppy disks, and flash memory are typical. Block device, the application can address any location on the disk and read data from it. In addition, data can only be read and written in multiples of blocks (usually 512B). Unlike character devices, block devices do not support character-based addressing. Among them, a block is a basic unit of data processing such as a kernel or a file system, and a block is composed of one or more sectors.

For ease of description, the embodiments of this application will take the Android operating system as an example for subsequent description. In the terminal's Android operating system, access to various types of files is very frequent, and access to files also generates access to block devices. How to optimize access to block devices is an important part of the system optimization topic. In related technologies, when optimizing the access of a block device, it is necessary to use some means to track the access of the block device and obtain the access information of the block device to achieve a precise optimization goal.

For example, a Linux kernel-level tracing framework similar to ftrace or blktrace may be used to implement block device access tracking. The earliest ftrace is a function tracer, which can only record the function call process of the kernel. Now ftrace has developed into a framework, which can be used to support developers to add more kinds of traces (plugin). The trace) function helps developers understand the runtime behavior of the Linux kernel for fault debugging or performance analysis. Therefore, it can be used to trace block device access. However, when using a tracing framework such as ftrace to perform block device access tracking, the collected information is written into a ring buffer (ring buffer), and operations such as filtering or statistics cannot be performed during the collection process, and kernel information is collected. At this time, only the information in the kernel standard format can be obtained, resulting in a large amount of collected information, and the storage space in the ring buffer is limited. In order to prevent information loss, the user space program will continuously read the content in the ring buffer, and then User space performs operations such as filtering, calculation, or statistics on the read information. In this way, a large number of kernel space and user space interactions will be generated, and user space programs will occupy a large number of processors, such as central processing unit (CPU) resources. In addition, if you want to collect other types of information than the standard format information of the kernel, you need to insert the corresponding code in the kernel. Inserting code into the kernel based on architectures such as ftrace will cause exceptions such as kernel crashes, reduce system stability, and lead to development. The cycle is long and it is difficult to integrate in the actual mass production system. blktrace is a tracing framework for the block device layer. The specific working method is similar to ftrace, so it also has the same problems as above.

In the embodiment of the present application, block device access tracking may be implemented based on a preset virtual machine implemented in a kernel space. Exemplarily, the preset block device access event may include synchronous read, synchronous write, asynchronous read, asynchronous write, and the like. Of course, other block device access events may also be included. The types or names of the block device access events may be different in different operating systems, and those skilled in the art may make adaptive selections according to the actual operating system used.

For many operating systems, the bottom layer of the system is generally Linux Kernel. The system divides kernel space and user space. Different operating systems may have different division methods or results. User space generally refers to the memory area where the user process is located. Application programs run in user space, and user process data is stored in user space. Kernel space is the memory area occupied by the operating system. The operating system and drivers run in kernel space. The operating system The data is stored in the system space. In this way, user data and system data can be isolated to ensure system stability. In general, user space and kernel space interact through system calls. System calls can be understood as a set of all system calls provided by the operating system implementation, that is, a program interface or application programming interface (Application Programming Interface, API). ) Is the interface between the application and the system. The main function of the operating system is to manage hardware resources and provide a good environment for application developers to make applications more compatible. In order to achieve this purpose, the kernel provides a series of multi-kernel functions with predetermined functions. Groups of interfaces called system calls are presented to the user. The system call passes the application's request to the kernel, calls the corresponding kernel function to complete the required processing, and returns the processing result to the application.

In the embodiment of the present application, when an application program accesses a block device, the kernel space needs to be accessed through a system call, that is, the corresponding system call interface needs to be called to access the kernel space. Therefore, events can be accessed according to a preset block device Whether the corresponding system call interface is called to determine whether the preset block device access event is triggered. If it is called, it can be considered that the preset block device access event is triggered.

For example, after calling a corresponding system call interface, a corresponding function in the kernel space needs to be called (usually called by a block device driver) to implement block device access, and the corresponding function may be called a function to be called. Taking the above-mentioned synchronous read, synchronous write, asynchronous read, and asynchronous write as examples, each preset block device access event corresponds to a corresponding function to be called, and is used to implement synchronous read, synchronous write, asynchronous read, and asynchronous write. Features. The specific implementation form of the function may be different in different operating systems, which are not limited in the embodiments of the present application.

In the embodiment of the present application, a preset program code writing method based on a preset virtual machine may be used in advance, and a preset program code is inserted before a function to be called in the kernel space, and the preset program code is used to obtain block device access information. In this way, when the preset block device access event is triggered, it can be determined whether there is a preset program code written based on the preset virtual machine, and then it is determined whether the preset program code is executed first or the code corresponding to the function to be called is directly executed. Inserting the preset program code based on the preset virtual machine can ensure the stability of the system.

In step 102, if there is, the block device access information corresponding to the function to be called is obtained through the preset program code.

For example, when it is determined that a preset program code exists, the preset program code may be executed first, and then the function to be called is executed. The preset program code is used to perform information related to block device access when executing the function to be called. This information is acquired in the embodiments of the present application as block device access information. The block device access information may include detailed information reflecting the block device access process, such as which block device is accessed, which file is accessed in the block device, and the specific access method, etc. In an embodiment, the block device access information includes a size of a transmission data amount and a transmission delay when a data transmission process corresponding to the preset block device access event ends. The transmission delay may represent a time interval between the initiation of the access request and the completion of the access request (that is, the end of the data transmission process for the access request). By analyzing the amount of transmission data and transmission delay, the access performance of the block device can be evaluated, so that the access to the block device can be optimized in a more targeted manner.

In step 103, the block device access information is stored in a storage format corresponding to the preset virtual machine for user space reading.

In the embodiment of the present application, the acquired block device access information is stored by using a preset storage format corresponding to a virtual machine, instead of storing in a kernel standard format, which can save storage space. User space does not need to constantly read the block device access information, but can read the required block device access information periodically or when needed, which can effectively reduce the number of interactions between kernel space and user space. Adopting a preset virtual machine storage format, the amount of read information is less, and the amount of transmission is small, so the amount of interactive data is also reduced, thereby reducing the burden of block device access tracking on the system and improving system stability.

In the block device access tracking method provided in the embodiment of the present application, when a preset block device access event is triggered, if it is determined that a function to be called corresponding to the preset block device access event exists in the kernel space and is written based on a preset virtual machine, The preset program code obtains the block device access information corresponding to the function to be called through the preset program code, and stores the block device access information by using a preset storage format corresponding to the virtual machine for user space reading. By adopting the above technical solution, based on a preset virtual machine implemented in kernel space, a preset program code can be inserted before a function to be called corresponding to a preset block device access event in the kernel space, and the preset program code can be used to obtain And store block device access information for user space reading, which can reduce the interaction between kernel space and user space, reduce the burden of block device access tracking on the system, and improve system stability.

In some embodiments, before the determining whether there is a preset program code written based on a preset virtual machine in a kernel space to be called corresponding to the preset block device access event, includes: determining a block in the kernel space In the device layer, whether a preset program code written based on a preset virtual machine exists at a start position of a function to be called corresponding to the preset block device access event. The advantage of this setting is that it does not destroy related code in kernel space. The block device layer is also called the general block layer. The function to be called for implementing block device access is generally in this layer. A program based on a preset virtual machine can be written at the starting position of the function to be called, and used to obtain The block device access information makes the timing and location of the preset program code more clear when it is determined whether the preset program code exists, and ensures that the preset program code can be successfully executed. In addition, when accessing the block device, after calling the corresponding system call interface, it may be necessary to determine the access method, which generally includes memory access and physical device access. If it is determined that the physical device access is made, continue to determine the block in the kernel space In the device layer, whether a preset program code written based on a preset virtual machine exists at a start position of a function to be called corresponding to the preset block device access event.

In some embodiments, for the size of the amount of data to be transmitted, obtaining the block device access information corresponding to the function to be called through the preset program code includes: obtaining the standby device information through the preset program code. The content of the function parameters corresponding to the calling function and / or the content of the kernel data structure corresponding to the function to be called; determining the size of the amount of transmission data corresponding to the function to be called according to the content of the function parameter and / or the content of the kernel data structure. . The advantage of this setting is that it can successfully and accurately obtain the size of the amount of transmitted data in the block device access information. When executing the function to be called, the amount of data transferred may exist in the function parameters; it may also exist in the corresponding kernel data structure, and the kernel data structure may also exist in the function parameters. Among them, the existing form is not limited. After obtaining the content of the function parameters or the content of the kernel data structure, it may need to be converted to obtain the finally required block device access information.

In some embodiments, the functions to be called include a first to-be-called function corresponding to a block device request initiation event and a second to-be-called function corresponding to a block device request completion event. For the transmission delay, obtaining the block device access information corresponding to the function to be called through the preset program code includes: obtaining the first time when the first to be called function is called through the preset program code. A time, and a second time when the second function to be called is called; and a corresponding transmission delay is determined according to a difference between the second time and the first time. The advantage of this setting is that it can successfully and accurately obtain the transmission delay in the block device access information. In Linux, the driver's input / output (I / O) operations on the block device, that is, when the block device is accessed, a request is made to the block device, which is described by the request structure in the driver, and the corresponding called function is recorded Is the first function to be called. However, for some disk devices, the request speed is very slow. At this time, the kernel provides a queue mechanism to add these I / O requests to the queue (which can be called a request queue), which is described by the request_queue structure in the driver. When the access to the block device is completed, that is, when the request is completed, it is necessary to return to indicate whether the requested data has been transmitted, and the corresponding called function is recorded as the second function to be called. Therefore, the transmission delay corresponding to the preset block device access event can be determined according to the time difference between calling the two functions to be called.

In some embodiments, the preset virtual machine includes an extended Berkeley Packet Filter (eBPF), and a storage format corresponding to the preset virtual machine includes a hash table. eBPF is a set of virtual machines implemented in the kernel. It was originally designed to filter network packets. Now it has the ability to insert and execute virtual machine code anywhere in the kernel, and generally inserts virtual machine code. A large number of tests will be performed before to ensure that the stability of the system will not be affected. Currently, the storage format specified in eBPF includes a hash table (hash table), which is also called a hash table. It is a data structure that is directly accessed according to a key value (Key value, referred to as a key value). Map to a location in the table to access records to speed up lookups. The advantage of this setting is that it can further ensure system stability and reduce interaction between kernel space and user space.

In some embodiments, storing the block device access information in a storage format corresponding to the preset virtual machine includes: using a process identifier corresponding to the preset block device access event and the block device access The information serves as a key value of the hash table, and the number of occurrences of a preset block device access event that matches the key value is stored in a hash table corresponding to the preset block device access event. The advantage of this setting is that the access information of the block device can be stored reasonably and accurately, and it is convenient for querying and subsequent analysis and statistics. The process identifier may be a process identification (ID), and the process identifier corresponding to the preset block device access event may be understood as the ID of the process that triggered the preset block device access event. The number of occurrences of the preset block device access event matching the key value can be understood as the number of occurrences of the preset block device access event with the same block device access information for the same process ID. Taking the block device access information including the size of transmission data and transmission delay as an example, process A triggers a preset block device access event 4 times, and the size of the first transmission data amount is 2pages (assuming that the unit is memory pages), and the transmission delay 2ms, the size of the second transfer of data is 3pages (assuming memory pages as a unit), the transfer delay is 2ms, the size of the third transfer of data is 2pages (assuming memory pages), and the transfer delay is 2ms , The size of the 4th transmission data amount is 3pages (assuming memory pages as a unit), and the transmission delay is 1ms. Then A22 can be used as the first key value, A means process A, the first 2 means the amount of data transmitted is 2pages, the second 2 means the transmission delay is 2ms, and the storage content corresponding to the first key value is 2 times; A32 is the second key value and the corresponding storage content is 1 time; A31 is the second key value and the corresponding storage content is 1 time. It can be understood that the arrangement order of the process identifier and the block device access information in the key value is not limited.

For example, for different preset block device access events, such as synchronous read, synchronous write, and other requests, a separate hash table may be allocated respectively. For example, synchronous read corresponds to hash table 1, synchronous write corresponds to hash table 2, and other requests correspond to hash table 3. The advantage of this setting is that the access information corresponding to different preset block device access events can be stored independently, which is convenient for subsequent query and analysis. In addition, there may be multiple block devices in the terminal, which can be further subdivided according to block devices. Each block device can contain multiple hash tables, and these multiple hash tables correspond to synchronous read, synchronous write, and other requests respectively.

In some embodiments, before the storing the block device access information by using the storage format corresponding to the preset virtual machine, the method further includes: obtaining a preset hash table, wherein the preset hash table Passed from the user space to the kernel space, filter condition information is stored in the preset hash table; and the block device access information is filtered according to the filter condition information in the preset hash table. Correspondingly, storing the block device access information by using the storage format corresponding to the preset virtual machine includes storing the filtered block device access information by using the storage format corresponding to the preset virtual machine. Among them, filtering can be forward filtering or reverse filtering. The advantage of this setting is that before the block device access information is stored, it can be selectively filtered to further reduce the amount of storage. In addition, the preset hash table is passed from the user space to the kernel space, which can support the user to set the preset hash table by himself, such as selecting an application that he cares about (can be represented by a user ID, that is, each application There is a corresponding user ID) or a process (which can be represented by the process ID) as the filtering condition information, instructing the kernel space to filter out block access information corresponding to these applications or processes for storage. For example, the user ID or process ID can be used as the key value, and the filtering method can be used as the corresponding storage content (such as reserved or filtered out). Alternatively, the filtering mode can be used as the key value, and the user ID or process ID can be used as the key value. Corresponding storage content and so on. For example, in some embodiments, it may further include: receiving a filtering condition setting operation through user space, generating a preset hash table according to the filtering condition setting operation, and passing the preset hash table from the user space to The kernel space.

In some embodiments, after storing the block device access information in a storage format corresponding to the preset virtual machine for user space reading, the method further includes: receiving the user space in the kernel space. When the preset read request is requested, a hash table corresponding to the preset block device access event is queried according to the preset read request, and the query result is fed back to the user space. The advantage of this setting is that the user space can send preset read requests to the kernel space at any time or periodically according to its own wishes, and the kernel space completes the query, instead of the user space reading the entire hash table storing the block device access information. And self-inquiry can further reduce the amount of interactive data between user space and kernel space, and reduce the load on the system caused by tracking block device access.

In an embodiment, after the query result is fed back to the user space, further operations such as analysis or statistics may be performed on the query result in the user space. For example, count the number of occurrences of access events with the same transmission delay; for example, count the number of occurrences of access events with the same transmission data size; for another example, the correspondence between the amount of transmission data and the transmission delay, and so on. Exemplarily, it may be displayed in the form of a histogram or a heat map. For example, a histogram of transmission delay obtained according to the query result statistics is displayed on the terminal display screen (for example, the horizontal axis is the transmission delay and the unit is ms; the vertical axis is the number of occurrences ), Transmission size histogram (such as the horizontal axis is the amount of transmitted data, the unit is pages; the vertical axis is the number of occurrences) and the transmission size vs. the transmission delay heat map (the horizontal axis is the amount of transmitted data, the unit is pages; the vertical axis is Transmission delay in ms; shades of color indicate the number of occurrences). In one embodiment, three graphs may be corresponding to the synchronous read, synchronous write, and other requests.

FIG. 2 is a schematic flowchart of another block device access tracking method according to an embodiment of the present application. Taking a preset virtual machine as an eBPF as an example, the method includes the following steps 201 to 207.

In step 201, it is detected that a preset block device access event is triggered.

Exemplarily, whether a preset block device access event is triggered may be determined according to whether a system call interface corresponding to the preset block device access event is called. If it is called, the preset block device access event may be considered to be triggered. Preset block device access events can include synchronous read, synchronous write, asynchronous read, asynchronous write, and so on.

In step 202, it is determined whether there is a preset program code written based on eBPF in the block device layer in the kernel space at the starting position of the first function to be called corresponding to the preset block device access event. Go to step 203; otherwise, go to step 207.

Exemplarily, the functions to be called include a first to-be-called function corresponding to the block device request initiation event and a second to-be-called function corresponding to the block device request completion event. Generally, the first function to be called is called first, so it can be directly determined whether an eBPF program exists at the starting position of the first function to be called.

In step 203, the contents of the function parameters corresponding to the first to-be-called function and the second to-be-called function are obtained through preset program code, and the first moment when the first to-be-called function is called, and the second to-be-called function is called. The second moment when called.

For example, the preset program code can be executed first, and then the function to be called is executed. The block device access information generally exists in the function parameters. Therefore, the preset program code can be used to treat the content of the function parameters involved in the execution of the called function. Obtain. In addition, you need to record the moment when the function to be called is called. Exemplarily, there may be a hash table, using the request ID corresponding to this request as a key value, and storing the corresponding calling moment. The kernel space generally allocates a memory address for each request, and the allocated memory address can be used as the request ID for this request.

In step 204, the size of the amount of transmission data corresponding to the function to be called is determined according to the content of the function parameters, and the corresponding transmission delay is determined according to the difference between the second time and the first time.

After the function parameter content is obtained, the kernel parameter structure may be included in the function parameter content, and the kernel data structure may be further converted to obtain the size of the final required transmission data amount. Query the second time and the first time corresponding to the same request ID from the hash table, and then calculate the transmission delay.

In step 205, the process identifier corresponding to the preset block device access event, the size of the transmission data amount, and the transmission delay are used as key values of the hash table, and the number of occurrences of the preset block device access event matching the key value is stored. In a hash table corresponding to the preset block device access event.

In step 206, when a preset read request in user space is received in the kernel space, a hash table corresponding to the preset block device access event is queried according to the preset read request, and the query result is fed back to the User space.

In step 207, the first function to be called is executed.

Exemplarily, if the preset program code does not exist at the starting position of the first to-be-called function, it may indicate that the current block device access event is not concerned, and there is no need to track the current block device access. It is not necessary to obtain corresponding block device access information, and the first function to be called can be directly executed.

The block device access tracking method provided in the embodiment of the present application uses the eBPF framework to implement real-time block device access statistics in the kernel, and inserts the eBPF program at the starting position of the function to be called to implement the block device access information acquisition. It is stored in the hash table. When a preset read request from the user space is received, the kernel space queries the hash table according to the preset read request and feeds back the query result to the user space. Practice has proved that the amount of each transmission can be reduced to tens of KB. It can be seen that by adopting the solution provided in the embodiment of the present application, the interaction between the kernel space and the user space can be effectively reduced, the burden of the block device access tracking on the system, and the system stability can be improved Sex.

FIG. 3 is a schematic flowchart of another block device access tracking method according to an embodiment of the present application. The method includes steps 301 to 310.

In step 301, a filtering condition setting operation is received through user space, and a first hash table is generated according to the filtering condition setting operation.

For example, the terminal device access tracking setting interface may be displayed to the user in the terminal, and the user may enter a filtering condition setting operation based on the setting interface, such as selecting an application or process that he or she cares about as a target application or target process. The user space generates a first hash table according to the filtering condition setting operation input by the user, and is used to instruct the kernel space to track the block device access initiated by the target application or target process in real time.

In step 302, the first hash table is passed from user space to kernel space.

In step 303, it is detected that the preset block device access event is triggered.

In step 304, in the virtual file system layer in the kernel space, a preset program code written based on eBPF is detected at a start position of a first function to be called corresponding to a preset block device access event.

In step 305, the contents of the function parameters corresponding to the first to-be-called function and the second to-be-called function are obtained through preset program code, and the first moment when the first to-be-called function is called, and the second to-be-called function is called. The second moment when called.

In step 306, the size of the amount of transmission data corresponding to the function to be called is determined according to the content of the function parameters, and the corresponding transmission delay is determined according to the difference between the second time and the first time.

In step 307, the size of the transmission data amount and the transmission delay are filtered according to the filtering condition information in the first hash table.

Exemplarily, it can be judged whether the size of the current transmission data amount and the transmission target corresponding to the transmission delay belong to the target application (or whether it is a target process). If yes, it means that the block device access that needs to be tracked can be used to transfer the amount of data The size and transmission delay are retained; if not, it means that the block device access that does not need to be tracked, and the size of the current transmission data amount and transmission delay can be ignored, that is, filtering is performed.

In step 308, the process identifier, the size of the filtered transmission data amount, and the transmission delay are used as key values of the hash table, and the number of occurrences of a preset block device access event matching the key values is stored to obtain the first Two hash tables.

The process identifier, the size of the filtered transmission data amount, and the transmission delay can be combined into a continuous string to form the key value of the second hash table.

In step 309, when the kernel space receives a preset read request from the user space, the second hash table is queried according to the preset read request, and the query result is fed back to the user space.

In step 310, the query results are counted through user space, and a transmission delay histogram, a transmission size histogram, and a transmission size vs. transmission delay heat map are displayed.

The block device access tracking method provided in the embodiments of the present application can be set in advance by a user on an initiating object that needs to be tracked for access, and after the block device access information is obtained through the eBPF program in the kernel space, corresponding filtering is performed according to the user's settings. Re-storing in the hash table can not only further reduce the storage amount, but also enhance the targeting and personalization of block device access tracking. When user space needs to read block device access information, it can further reduce kernel space and user space. The interaction enables lightweight file tracking, which is beneficial for deployment to mass production systems. In addition, the read access information of the block device is counted and displayed in the form of charts, which is convenient for the analysis and optimization of the block device access.

FIG. 4 is a structural block diagram of a block device access tracking device according to an embodiment of the present application. The device may be implemented by software and / or hardware, and is generally integrated in a terminal. Block device access may be performed by executing a block device access tracking method. track. As shown in FIG. 4, the device includes a judgment module 401, an access information acquisition module 402, and an access information storage module 403.

The judging module 401 is configured to judge whether a preset program code written based on a preset virtual machine exists in a kernel space before a function to be called corresponding to the preset block device access event is triggered when a preset block device access event is triggered. .

The access information acquisition module 402 is configured to acquire the block device access information corresponding to the function to be called through the preset program code when the judgment result of the judgment module is present.

The access information storage module 403 is configured to store the block device access information in a storage format corresponding to the preset virtual machine for reading by user space.

In the block device access tracking device provided in the embodiment of the present application, when a preset block device access event is triggered, if it is determined that a function to be called corresponding to the preset block device access event exists in the kernel space and is written based on a preset virtual machine, The preset program code obtains the block device access information corresponding to the function to be called through the preset program code, and stores the block device access information by using a preset storage format corresponding to the virtual machine for user space reading. By adopting the above technical solution, based on a preset virtual machine implemented in kernel space, a preset program code can be inserted before a function to be called corresponding to a preset block device access event in the kernel space, and the preset program code can be used to obtain And store block device access information for user space reading, which can reduce the interaction between kernel space and user space, reduce the burden of block device access tracking on the system, and improve system stability.

In an embodiment, the judgment module is further configured to:

It is determined whether a preset program code written based on a preset virtual machine exists in a block device layer in kernel space at a starting position of a function to be called corresponding to the preset block device access event.

In one embodiment, the block device access information includes a size of a transmission data amount and a transmission delay when a data transmission process corresponding to the preset block device access event ends.

In an embodiment, for the size of the amount of transmitted data, the access information acquisition module is further configured to:

Obtaining the function parameter content corresponding to the function to be called and / or the kernel data structure content corresponding to the function to be called through the preset program code;

The size of the amount of data transmitted corresponding to the function to be called is determined according to the function parameter content and / or the kernel data structure content.

In an embodiment, the functions to be called include a first to-be-called function corresponding to a block device request initiation event and a second to-be-called function corresponding to a block device request completion event;

For the transmission delay, the access information acquisition module is set to:

Obtaining the first time when the first function to be called is called and the second time when the second function to be called is called by using the preset program code;

A corresponding transmission delay is determined according to a difference between the second time and the first time.

In an embodiment, the preset virtual machine includes an extended Berkeley packet filter eBPF, and the storage format corresponding to the preset virtual machine includes a hash table.

In an embodiment, the access information storage module is further configured to:

The process identifier corresponding to the preset block device access event and the block device access information are used as key values of the hash table, and the number of occurrences of the preset block device access event matching the key value is stored in the The preset block access event corresponds to a hash table.

In an embodiment, the device further includes: a preset hash table acquisition module and a filtering module.

The preset hash table obtaining module is configured to obtain a preset hash table, wherein the preset hash table is passed from the user space to the kernel space, and the preset hash table stores filtering conditions. information;

A filtering module configured to filter the block device access information according to the filtering condition information in the preset hash table;

Accordingly, the access information storage module is further configured to:

The filtered block device access information is stored in a storage format corresponding to the preset virtual machine.

In an embodiment, the apparatus further includes a query result feedback module.

The query result feedback module is configured to store the block device access information in a storage format corresponding to the preset virtual machine for user space reading, and then receive a user space preview in the kernel space. When the read request is set, a hash table corresponding to the preset block device access event is queried according to the preset read request, and the query result is fed back to the user space.

In an embodiment, the apparatus may further include a preset hash table generation module and a preset hash table transfer module.

A preset hash table generating module configured to receive a filtering condition setting operation through user space, and generate a preset hash table according to the filtering condition setting operation;

The preset hash table transfer module is configured to transfer the preset hash table from the user space to the kernel space.

An embodiment of the present application further provides a storage medium containing computer-executable instructions, where the computer-executable instructions are used to execute a block device access tracking method when executed by a computer processor, the method includes:

Storage medium-any type of memory device or storage device. The term "storage medium" is intended to include: installation media, such as CD-ROM, floppy disks, or magnetic tape devices; computer system memory or random access memory, such as Dynamic Random Access Memory (DRAM), double-rate synchronization Dynamic Random Access Memory (Double Date, Synchronous and Dynamic Access Memory, DDRRAM), Static Random Access Memory (Static Random Access Memory, SRAM), Extended Data Output Random Access Memory (Extended Data Output Random Access Memory, EDORAM), Lan Rambus RAM, etc .; non-volatile memory such as flash memory, magnetic media (such as hard disk or optical storage); registers or other similar types of memory elements, etc. The storage medium may further include other types of memory or a combination thereof. In addition, the storage medium may be located in a first computer system in which the program is executed, or may be located in a different second computer system connected to the first computer system through a network such as the Internet. The second computer system may provide program instructions to the first computer for execution. The term "storage medium" may include two or more storage media that may reside in different locations, such as in different computer systems connected through a network. The storage medium may store program instructions (for example, embodied as a computer program) executable by one or more processors.

Certainly, a storage medium including computer-executable instructions provided in the embodiments of the present application is not limited to the block device access tracking operation described above, and may also execute the block device provided by any embodiment of the application. Relevant operations in access tracking methods.

The embodiment of the present application provides a terminal, and the terminal may be integrated with the block device access tracking device provided by the embodiment of the present application. FIG. 5 is a schematic structural diagram of a terminal according to an embodiment of the present application. The terminal 500 may include: a memory 501, a processor 502, and a computer program stored on the memory 501 and executable on the processor 502. When the processor 502 executes the computer program, the block device according to the embodiment of the present application is implemented Access tracking method.

The terminal provided in the embodiment of the present application may be based on a preset virtual machine implemented in the kernel space, insert a preset program code before a function to be called corresponding to a preset block device access event in the kernel space, and use the preset program. The code acquires and stores block device access information for user space reading, which can reduce the interaction between kernel space and user space, reduce the burden of block device access tracking on the system, and improve system stability.

FIG. 6 is a schematic structural diagram of another terminal provided by an embodiment of the present application. The terminal may include: a housing (not shown in the figure), a memory 601, a central processing unit (CPU) 602 (also referred to as processing). (Hereinafter referred to as CPU), a circuit board (not shown in the figure) and a power supply circuit (not shown in the figure). The circuit board is disposed in a space surrounded by the housing; the CPU 602 and the memory 601 are disposed on the circuit board; and the power supply circuit is configured to supply power to various circuits or devices of the terminal; The memory 601 is configured to store executable preset program code; the CPU 602 runs a computer program corresponding to the executable preset program code by reading the executable preset program code stored in the memory 601, To achieve the following steps:

The terminal further includes: a peripheral interface 603, a radio frequency (RF) circuit 605, an audio circuit 606, a speaker 611, a power management chip 608, an input / output (I / O) subsystem 609, and other input / control devices 610, a touch screen 612, other input / control devices 610, and an external port 604. These components communicate through one or more communication buses or signal lines 607.

It should be understood that the illustrated terminal 600 is only an example of the terminal, and the terminal 600 may have more or fewer components than those shown in the figure, may combine two or more components, or may have Different component configurations. The various components shown in the figures can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application specific integrated circuits.

The terminal for block device access tracking provided in this embodiment is described in detail below. The terminal uses a mobile phone as an example.

Memory 601, which can be accessed by CPU602, peripheral interface 603, etc. The memory 601 can include high-speed random access memory, and can also include non-volatile memory, such as one or more disk storage devices, flash memory devices , Or other volatile solid-state storage devices.

Peripheral interface 603, which can connect the input and output peripherals of the device to the CPU 602 and the memory 601.

I / O subsystem 609, which can connect input / output peripherals on the device, such as touch screen 612 and other input / control devices 610, to peripheral interface 603. The I / O subsystem 609 may include a display controller 6091 and one or more input controllers 6092 for controlling other input / control devices 610. Among them, one or more input controllers 6092 receive electrical signals from or send electrical signals to other input / control devices 610. Other input / control devices 610 may include physical buttons (press buttons, rocker buttons, etc.) ), Dial, slide switch, joystick, click wheel. It is worth noting that the input controller 6092 can be connected to any of the following: a keyboard, an infrared port, a USB interface, and a pointing device such as a mouse.

A touch screen 612, which is an input interface and an output interface between a user terminal and a user, and displays a visual output to the user. The visual output may include graphics, text, icons, videos, and the like.

The display controller 6091 in the I / O subsystem 609 receives electrical signals from the touch screen 612 or sends electrical signals to the touch screen 612. The touch screen 612 detects a contact on the touch screen, and the display controller 6091 converts the detected contact into interaction with a user interface object displayed on the touch screen 612, that is, realizes human-computer interaction. The user interface object displayed on the touch screen 612 may be an operation Icons for games, icons connected to the appropriate network, etc. It is worth noting that the device may also include a light mouse, which is a touch-sensitive surface that does not display visual output, or an extension of the touch-sensitive surface formed by a touch screen.

The RF circuit 605 is mainly configured to establish communication between a mobile phone and a wireless network (that is, a network side), and realize data reception and transmission of the mobile phone and the wireless network. For example, send and receive text messages, e-mail, and so on. Specifically, the RF circuit 605 receives and sends an RF signal. The RF signal is also referred to as an electromagnetic signal. The RF circuit 605 converts an electrical signal into an electromagnetic signal or converts an electromagnetic signal into an electrical signal, and communicates with the communication network and other devices through the electromagnetic signal. For communication. RF circuit 605 may include known circuits for performing these functions, including but not limited to antenna systems, RF transceivers, one or more amplifiers, tuners, one or more oscillators, digital signal processors, codec (COder-DECoder, CODEC) chipset, Subscriber Identity Module (SIM), and so on.

The audio circuit 606 is mainly configured to receive audio data from the peripheral interface 603, convert the audio data into an electrical signal, and send the electrical signal to the speaker 611.

The speaker 611 is configured to restore a voice signal received by the mobile phone from the wireless network through the RF circuit 605 to a sound and play the sound to a user.

The power management chip 608 is configured to provide power and power management for the hardware connected to the CPU 602, the I / O subsystem, and peripheral interfaces.

The block device access tracking device, storage medium, and terminal provided in the foregoing embodiments can execute the block device access tracking method provided by any embodiment of the present application, and have corresponding function modules and beneficial effects for executing the method. For technical details not described in detail in the foregoing embodiments, reference may be made to the block device access tracking method provided in any embodiment of the present application.

Claims

A block device access tracking method includes:

If a preset block device access event is triggered, determining whether there is a preset program code written based on a preset virtual machine in a kernel space before a function to be called corresponding to the preset block device access event;

In response to the existence of a preset program code written based on a preset virtual machine, obtaining the block device access information corresponding to the function to be called through the preset program code;

The block device access information is stored in a storage format corresponding to the preset virtual machine for user space reading.
The method according to claim 1, wherein, before the determining whether a function to be called corresponding to the preset block device access event in the kernel space exists, a preset program code written based on a preset virtual machine comprises:

It is determined whether a preset program code written based on a preset virtual machine exists in a block device layer in kernel space at a starting position of a function to be called corresponding to the preset block device access event.
The method according to claim 1, wherein the block device access information comprises a size of a transmission data amount and a transmission delay when a data transmission process corresponding to the preset block device access event ends.
The method according to claim 3, wherein, for the size of the amount of data to be transmitted, the acquiring, through the preset program code, block device access information corresponding to the function to be called comprises:

Obtaining at least one of content of a function parameter corresponding to the function to be called and content of a kernel data structure corresponding to the function to be called through the preset program code;

The size of the amount of data transmitted corresponding to the function to be called is determined according to at least one of the function parameter content and the kernel data structure content.
The method according to claim 3, wherein the functions to be called comprise a first to-be-called function corresponding to a block device request initiation event and a second to-be-called function corresponding to a block device request completion event;

For the transmission delay, obtaining the block device access information corresponding to the function to be called through the preset program code includes:

Obtaining the first time when the first function to be called is called and the second time when the second function to be called is called by using the preset program code;

A corresponding transmission delay is determined according to a difference between the second time and the first time.
The method according to claim 1, wherein the preset virtual machine comprises an extended Berkeley packet filter eBPF, and the storage format corresponding to the preset virtual machine comprises a hash table.
The method according to claim 6, wherein the storing the block device access information in a storage format corresponding to the preset virtual machine comprises:

The process identifier corresponding to the preset block device access event and the block device access information are used as key values of the hash table, and the number of occurrences of the preset block device access event matching the key value is stored in the The preset block access event corresponds to a hash table.
The method according to claim 6, before the storing the block device access information in the storage format corresponding to the preset virtual machine, further comprising:

Obtaining a preset hash table, wherein the preset hash table is passed from the user space to the kernel space, and the preset hash table stores filter condition information;

Filtering the block device access information according to the filter condition information in the preset hash table;

The storing the block device access information in a storage format corresponding to the preset virtual machine includes:

The filtered block device access information is stored in a storage format corresponding to the preset virtual machine.
The method according to any one of claims 6 to 8, after storing the block device access information in a storage format corresponding to the preset virtual machine for user space reading, further comprising:

In the case where the kernel space receives a preset read request of the user space, a hash table corresponding to the preset block device access event is queried according to the preset read request, and the query result is fed back Give the user space.
A block device access tracking device includes:

A judging module configured to determine whether a preset program written based on a preset virtual machine exists in a kernel space before a function to be called corresponding to the preset block device access event is triggered in a case where a preset block device access event is triggered Code

The access information acquisition module is configured to, when the judgment result of the judgment module exists, acquire the access information of the block device corresponding to the function to be called through the preset program code;

The access information storage module is configured to store the block device access information in a storage format corresponding to the preset virtual machine for user space to read.
The apparatus according to claim 10, wherein the judgment module is further configured to:

It is determined whether a preset program code written based on a preset virtual machine exists in a block device layer in kernel space at a starting position of a function to be called corresponding to the preset block device access event.
The apparatus according to claim 10, wherein the block device access information comprises a size of a transmission data amount and a transmission delay when a data transmission process corresponding to the preset block device access event ends.
The apparatus according to claim 12, wherein, for the size of the amount of transmitted data, the access information acquisition module is further configured to:

Obtaining at least one of content of a function parameter corresponding to the function to be called and content of a kernel data structure corresponding to the function to be called through the preset program code;

The size of the amount of data transmitted corresponding to the function to be called is determined according to at least one of the function parameter content and the kernel data structure content.
The apparatus according to claim 12, wherein the functions to be called comprise a first function to be called corresponding to a block device request initiation event and a second function to be called corresponding to a block device request completion event;

For the transmission delay, the access information acquisition module is set to:

Obtaining the first time when the first function to be called is called and the second time when the second function to be called is called by using the preset program code;

A corresponding transmission delay is determined according to a difference between the second time and the first time.
The apparatus according to claim 10, wherein the preset virtual machine comprises an extended Berkeley packet filter eBPF, and the storage format corresponding to the preset virtual machine includes a hash table.
The apparatus according to claim 15, wherein the access information storage module is further configured to:

The process identifier corresponding to the preset block device access event and the block device access information are used as key values of the hash table, and the number of occurrences of the preset block device access event matching the key value is stored in the The preset block access event corresponds to a hash table.
The apparatus of claim 10, further comprising:

The preset hash table obtaining module is configured to obtain a preset hash table, wherein the preset hash table is passed from the user space to the kernel space, and the preset hash table stores filtering conditions. information;

A filtering module configured to filter the block device access information according to the filtering condition information in the preset hash table;

The access information storage module is further configured to:

The filtered block device access information is stored in a storage format corresponding to the preset virtual machine.
The apparatus of claim 10, further comprising:

The query result feedback module is configured to query a hash corresponding to the preset block device access event according to the preset read request when the preset read request of the user space is received in the kernel space. Table, and feedback the query results to the user space.
A computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the block device access tracking method according to any one of claims 1-9.
A terminal includes a memory, a processor, and a computer program stored on the memory and executable by the processor. When the processor executes the computer program, the block device access tracking according to any one of claims 1-9 is implemented. method.