Prefetching method, electronic device, storage medium, and program product

Abstract

Embodiments of the present application disclose a prefetching method, an electronic device, a storage medium and a program product. The method comprises receiving a first access request for a file, obtaining a prefetching model according to the first access request, wherein the prefetching model is used to determine a first file, the first file is a file predicted by the prefetching model based on the first access request to be requested by a second access request, the second access request is a next access request of the first access request, obtaining a first prefetching window according to historical hit information, obtaining a second file according to the first prefetching window and the first file, and storing preset data in the second file in a cache. The method can improve the accuracy of prefetching, and thus improve the fluency of the operating system and the experience of the user.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a prefetching method, electronic device, storage medium, and program product. Background Technology

[0002] In storage devices, cache access is faster than hard drive access. When reading data, a prefetching method is used to predict the data to be read and pre-fetch the predicted data from the hard drive into the cache. When the storage device receives an input / output (IO) request, the data in the cache can be hit, thus greatly improving the processing speed of read IO requests. In existing technologies, the most commonly used prefetching method is sequential prefetching. Sequential prefetching operates under assumptions and is suitable for workloads with good order. However, traditional prefetching methods cannot work properly in diverse user access scenarios. Summary of the Invention

[0003] This application provides a prefetching method, electronic device, medium, and program product that can improve the accuracy of data prefetching, thereby improving the smoothness of the operating system and enhancing the user experience.

[0004] In a first aspect, embodiments of this application provide a prefetching method, comprising: receiving a first access request for a file; obtaining a prefetching model based on the first access request, wherein the prefetching model is used to determine a first file, the first file being a file that the prefetching model predicts a second access request will request based on the first access request, and the second access request being the next access request after the first access request; obtaining a first prefetching window based on historical hit information; obtaining a second file based on the first prefetching window and the first file; and storing preset data in the second file in a cache.

[0005] The first access request includes the target to be accessed and the access operation to be performed. The first access request can be a read request for a file or a write request for a file.

[0006] In this embodiment, a first access request for a file is acquired in real time. A prefetch model is then established or updated based on this first access request. The prefetch model predicts the file that the next access request after the first access request will request. A first prefetch window is then obtained based on historical hit information. A second file is obtained based on the first prefetch window and the first file, and preset data from the second file is stored in a cache. File-level prefetching improves prefetch hit rate, reduces data access latency, and has no significant impact on memory usage.

[0007] In one possible implementation, obtaining the first prefetch window based on historical hit information includes: obtaining a second prefetch window; obtaining a historical hit rate based on historical hit information; when the historical hit rate is lower than a preset threshold, reducing the second prefetch window to obtain the first prefetch window; and when the historical hit rate is greater than or equal to the preset threshold, increasing the second prefetch window to obtain the first prefetch window.

[0008] In one possible implementation, obtaining the prefetch window based on historical hit information includes: obtaining a second prefetch window; determining whether the file requested by the first access request has been pre-stored in the cache based on the historical hit information; if not, shrinking the second prefetch window to obtain a first prefetch window; if yes, increasing the second prefetch window to obtain the first prefetch window.

[0009] In one possible implementation, obtaining the prefetch model based on the first access request includes: recording a third access request, wherein the third access request is the previous access request of the first access request; and obtaining the prefetch model based on the first access request and the third access request.

[0010] In one possible implementation, obtaining the prefetch model based on the first access request and the third access request includes: assigning a first identifier to the file requested by the first access request; assigning a second identifier to the file requested by the third access request; recording the timestamp of the first access request as a first timestamp; recording the timestamp of the third access request as a second timestamp; and obtaining the prefetch model based on the first identifier, the first timestamp, the second identifier, and the second timestamp.

[0011] In one possible implementation, obtaining the prefetch model based on the first identifier, the first timestamp, the second identifier, and the second timestamp includes: when the time interval between the first timestamp and the second timestamp is greater than a preset time threshold, recording that the file requested by the first access request is unrelated to the file requested by the third access request; when the time interval between the first timestamp and the second timestamp is less than or equal to the preset time threshold, recording that the file requested by the first access request is related to the file requested by the third access request; and obtaining the prefetch model based on the correlation between the file requested by the first access request and the file requested by the third access request.

[0012] In one possible implementation, obtaining the prefetch model based on the first access request further includes: determining the type of the first access request based on the file type requested in the first access request; and obtaining the corresponding prefetch model based on the type of the first access request.

[0013] Secondly, embodiments of this application also provide an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, the processor is configured to perform the prefetching method as described above.

[0014] Thirdly, embodiments of this application also provide a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the prefetching method as described above.

[0015] Fourthly, embodiments of this application also provide a computer program product, the computer program product including computer program code, which, when executed by a computer, enables the computer to perform the prefetching method as described above. Attached Figure Description

[0016] Figure 1 This is a diagram of the storage system architecture involved in the prefetching method provided in the embodiments of this application.

[0017] Figure 2 A schematic diagram of a prefetching system 100 involved in the prefetching method provided in the embodiments of this application.

[0018] Figure 3 This is a schematic flowchart of a prefetching method provided in an embodiment of this application.

[0019] Figure 4a This is a schematic diagram of a hash operation provided in an embodiment of this application.

[0020] Figure 4b This is a schematic diagram of an LRU chain provided in an embodiment of this application.

[0021] Figure 4c This is a schematic diagram of a Markov model provided for an embodiment of this application.

[0022] Figure 5 This is a schematic flowchart of a prefetch window adjustment method provided in an embodiment of this application.

[0023] Figure 6 This is a schematic diagram of obtaining a prefetch model provided in an embodiment of this application.

[0024] Figure 7a This is a schematic diagram illustrating the average read latency effect provided in the embodiments of this application.

[0025] Figure 7b This is a schematic diagram illustrating the reading and actual request effects provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] The term "multiple" in this application refers to two or more. Furthermore, it should be understood that the terms "first," "second," etc., used in the description of this application are used only for descriptive purposes and should not be construed as indicating or implying relative importance, nor as indicating or implying order.

[0028] Before providing a detailed explanation of the embodiments of this application, the storage system architecture involved in the embodiments of this application will be introduced first.

[0029] Please see Figure 1 , Figure 1 This is a diagram of the storage system architecture involved in the prefetching method provided in the embodiments of this application.

[0030] like Figure 1 As shown, the storage system may include a host 01, a controller 02, and multiple hard disks 03. The host 01 and the controller 02 communicate via a Network File System (NFS) / Common Internet File System (CIFS) protocol or a Fiber Channel (FC) protocol.

[0031] Specifically, host 01 can send a write data request to controller 02. After receiving the write data request, controller 02 writes the data carried in the write data request to hard disk 03. Additionally, host 01 can also send a read data request to controller 02. After receiving the read data request, controller 02 checks whether the data to be read is stored in its cache 022 based on the logical address of the data to be read in the read data request. If it is, it directly sends the data to be read to host 01; otherwise, it obtains the data from hard disk 03 and sends it to host 01. The controller 02 and hard disk 03 can be integrated into a single storage device or located in two independent devices. This embodiment does not impose any limitations on the positional relationship between controller 02 and hard disk 03.

[0032] Taking a read data request as an example, when a user submits a large read data request on host 01 or a client connected to host 01, host 01 typically splits the read data request into multiple requests and sends them to controller 02 for processing. This splitting can be performed by the host bus adapter (HBA) in host 01 or by the HBA in controller 02. The size of each split request can be the same or different; this embodiment does not limit the size of the split read data requests. Furthermore, the logical addresses of the multiple split read data requests can be consecutive. Such consecutive logical addresses in multiple read data requests are called a sequential stream. Host 01 can send multiple read data requests from the sequential stream serially to controller 02 for processing, or it can send them in parallel to controller 02 for processing. A sequential stream sent serially to controller 02 is called a serial sequential stream, and a sequential stream sent in parallel to controller 02 is called a parallel sequential stream. For a serial sequential stream, host 01 sends each of a series of consecutive read data requests to controller 02 in turn, sending the next read data request only after the previous one has been processed. For a parallel sequential stream, host 01 sends at least two of a series of consecutive read data requests to controller 02, and the storage device can process at least two read data requests in parallel. Assuming host 01 sends nine read data requests to controller 02, if these nine read data requests are processed serially, host 01 first sends the first read data request, then sends the second read data request after receiving the response, and so on, until all nine read data requests have been processed. If these nine read data requests are processed in parallel, then host 01 can simultaneously send the first, second, and third read data requests to controller 02. Controller 02 processes these three read data requests in parallel. When the first read data request is completed, even if the second or third read data request has not yet been completed, host 01 can send the fourth read data request to controller 02, and so on, until all nine read data requests are completed. This embodiment of the application does not impose specific limitations on this.

[0033] It should be noted that, as Figure 1 As shown, controller 02 may include at least processor 021 and cache 022.

[0034] Processor 021 is a central processing unit (CPU). In this embodiment, processor 021 can be used to receive and process read and write data requests from host 01. Cache 022 is used to temporarily store data received from host 01 or data read from hard disk 03. When controller 02 receives multiple write data requests from host 01, it can temporarily store the data in the multiple write data requests in cache 022. When the capacity of cache 022 reaches a certain threshold, the data stored in cache 022 is sent to hard disk 03. Hard disk 03 stores the data. Cache 022 includes volatile memory, non-volatile memory, or a combination thereof. Volatile memory is, for example, random-access memory (RAM). Non-volatile memory includes, for example, floppy disks, hard disks, solid-state disks (SSDs), optical disks, and other machine-readable and writable media that can store program code used to implement the embodiments of this application.

[0035] It is understandable that cache 022 reads data faster than hard disk 03. Therefore, if the data requested by the read request is found in cache 022, it is unnecessary to read the data from hard disk 03, thus improving data reading efficiency. To improve the data hit rate of cache 022, the common practice is for processor 021 to pre-read a segment of data from hard disk 03 (e.g., ...). Figure 1 The data 023 shown is written to the cache 022. So, when the host 01 sends a read data request to the controller 02 to read the data 023, since the data 023 has already been read into the cache 022, the processor 021 can directly send the data 023 to the host 01.

[0036] In this embodiment, prefetching data 023 into cache 022 is a technique called prefetching. The main idea of ​​prefetching is to prefetch data A, which will be accessed in the future, into "upper-layer storage," thereby hiding the underlying hardware and software latency. "Upper-layer storage" refers to storage that is closer to the processing device that will process data A in the future, so that the processing device can read data A more quickly. "Upper-layer storage" can be the cache of the processing device that will process data A. The term "prefetch" refers to issuing a prefetch request before the cache expires by overlapping computation and memory access, so that the data is prefetched into the cache when it is actually used, thereby avoiding processor pauses caused by cache expiration.

[0037] In one possible implementation, prefetching scenarios include the process of storing the data that the processor will use in the calculation from memory into a cache memory (usually referring to a cache memory) in advance while the processor is performing calculations. When the processor needs this data, it can directly obtain the data from these cache memories.

[0038] In one possible implementation, prefetching scenarios include reading the data that the server is about to process in advance and storing it in the server's memory.

[0039] In the above storage system, although prefetching some data from hard disk 03 into cache 022 before the read data request sent by host 01 reaches cache 022 can improve the cache hit rate, too much prefetched data will waste memory resources, and if the prefetch accuracy is low, it will also cause a large disk read pressure.

[0040] Please see Figure 2 , Figure 2 This is a schematic diagram of the prefetching system involved in the prefetching method provided in the embodiments of this application.

[0041] The prefetch system 100 of this application embodiment has a wide range of applications. It can be applied to local computer systems based on any storage device and edge devices, such as laptops, smartphones, smart screens, or televisions. It can be applied to distributed scenarios and cross-device scenarios. For example, when two devices (device A and device B) need to interact with each other, prefetching technology can be used to facilitate data interaction. If device A needs to access data stored on device B, the data that device A needs to access is prefetched from device B and then stored in storage closer to device A, such as prefetching the data stored in device B into device A's cache. Or, if device B needs to access data stored on device A, the data that device B needs to access is prefetched from device A and then stored in storage closer to device B, such as prefetching the data into device B's cache.

[0042] The prefetch system 100 of this application embodiment can be applied to the above-mentioned storage system and can be applied to data access scenarios in general computer architectures and systems. It prefetches data to storage close to the processing device that will process the data, thereby improving data access performance in various application scenarios.

[0043] In this embodiment, the prefetch granularity is the size of the prefetched data, which can be of various sizes, such as 8 bytes, 16 bytes, etc. The prefetch granularity can be at the data block level or the file level. Prefetching at the data block level means prefetching at the data block level, which is the finest granularity mapping. The architecture of data block level mapping is generally a cache layering. This data block can contain system data pages and storage data blocks. At the data block level, data is accessed directly by reading and writing one or a segment of addresses in the storage space (such as a disk). Prefetching at the file level means prefetching at the file level, where the file serves as the organizational unit for related blocks. Block requests are categorized by file, and all blocks of the same file are mapped to the same device. At the file level, data is accessed by reading and writing a segment of data within a file. The prefetching system 100 in this embodiment can use either the data block level or the file level as the granularity; this embodiment does not specifically limit this.

[0044] This prefetching system 100 is implemented at the VFS (Virtual File System) layer, described at the file level. The VFS layer performs file-level access pattern learning and prefetching management. The role of the VFS is to use standard Unix system calls to read and write different file systems located on different physical media, providing a unified operating interface and application programming interface for various file systems. The VFS is a glue layer that allows system calls such as open(), read(), and write() to work without needing to know the underlying storage media and file system type.

[0045] like Figure 2 As shown, the prefetching system 100 may include a model building module 10, a prefetching module 20, and a model compression module 30.

[0046] The model building module 10 is used to dynamically build or update the prefetch model based on access requests. That is, the model building module 10 can build a prefetch model based on user access requests. After building the prefetch model, it can continue to acquire new user access requests to update the prefetch model accordingly; in other words, the prefetch model is continuously updated based on user access requests. The model prefetch module 20 includes online tracking of file access information, filtering invalid files such as empty files, dynamically building and generating prefetch models.

[0047] Specifically, the model building module 10 tracks user access information for files online, records the files accessed by users, cleans and filters invalid files such as empty files, and builds a prefetch model based on user access requests for files. After the prefetch model is built, it can continue to acquire user access requests for files to continue to update the prefetch model based on user access requests for files. In other words, the prefetch model is continuously updated based on user access requests for files.

[0048] The access request includes the target to be accessed and the access operation to be performed. When the granularity is file, the target to be accessed can be a file, and can include at least one of the following: a local file, a local file directory (or a local folder); the target to be accessed in the access request can be represented by the local path of the target to be accessed, for example, it can be represented as " / tmp / a.txt". Here, "local" can refer to an actual hardware device (such as a personal computer, server, etc.) or a virtual machine, and the access operation to be performed can be a read operation or a write operation to the target to be accessed.

[0049] In one possible implementation, the access request may be initiated by a local application of the device executing the method of the embodiments of this application. That is, when an application in a device wants to access the target to be accessed, the device executes the method of the embodiments of this application, so that the application can access the target to be accessed as if it were a local file or file directory.

[0050] In one possible implementation, the access request can also be initiated by an application on another device. For example, a server can be used to execute the method of this application embodiment to map the target to be accessed to a local file or file directory. Applications on other devices can access the target by accessing the file or file directory on the server.

[0051] The prefetch module 20 is used to prefetch files based on a dynamic prefetch window. That is, when the prefetch module 20 prefetches files, it does so according to a prefetch window whose size dynamically changes. The prefetch module 20 performs file prefetching based on this dynamically adjusted prefetch window. The prefetch module 20 includes dynamically adjusting the prefetch window size based on historical prefetch hits to control the memory usage of prefetched file data and alleviate memory pressure.

[0052] Specifically, the model building module 10 and the prefetching module 20 can interact through VFS. The prefetching module 20 detects prefetch hits to obtain historical prefetch hit data, and then dynamically adjusts the prefetch window size based on the historical prefetch hit data. The prefetching module 20 obtains a first file from the prefetched model built in the model building module 10 or the updated prefetched model, then determines a second file from the first file based on the adjusted prefetch window, performs prefetching based on the second file, and prefetches the prefetched data in the second file into the cache.

[0053] The model compression module 30 is used to build or update the corresponding prefetch model according to the access request type. Specifically, the model compression module 30 classifies the files requested by the user, determines different types of access requests based on the different types of files requested, and then the model building module 10 builds or updates the corresponding prefetch model according to the different types of access requests. The model compression module 30 includes classifying the files accessed by the user, such as classifying files according to the file path of the requested file, thereby determining different access requests. The model building module 10 builds or updates the corresponding prefetch model for different access requests to reduce the memory usage of the prefetch model.

[0054] Specifically, if the user requests file A at time T and file B at time T+1, the model compression module 30 determines that files A and B are of different types, thus classifying the access requests at time T and T+1 as different types of access requests. The model building module 10 builds or updates the prefetch model based on the output of the model compression module 30. The model building module 10 builds or updates the prefetch model a based on the access request at time T and the prefetch model b based on the access request at time T+1.

[0055] The following is a brief description of the working process of each model in the prefetching system 100:

[0056] When a user requests access to a file, this request is detected by the model building module 10. The model building module 10 obtains the access request record and builds or updates the prefetch model based on the record. If the prefetch model has not yet been built, the model building module 10 builds it based on the access request; if it has already been built, it updates it. To reduce the memory overhead of the file prefetch model, the model compression module 30 can compress it to obtain prefetch models corresponding to different access requests. That is, if the model compression module 30 and the model building module 10 can work simultaneously, the model compression module 30 determines the file type requested by the current user, and then the model building module 10 builds or updates the prefetch model based on the output of the compression module 30. The prefetch module 20 obtains the prefetch model built or updated by the model building module 10 and then performs prefetching based on the obtained model.

[0057] The prefetching method provided in the embodiments of this application will be described next.

[0058] Flowcharts are used in the embodiments of this application to illustrate the operations performed by the apparatus according to the embodiments of this application. It should be understood that the preceding or following operations are not necessarily performed in exact order. Instead, various steps can be processed in reverse order or simultaneously as needed. Furthermore, other operations can be added to these processes, or one or more steps can be removed from these processes.

[0059] Please see Figure 3 , Figure 3 This application provides a schematic flowchart of a prefetching method according to an embodiment. The prefetching method can be executed by the aforementioned prefetching system 100, and may include the following steps:

[0060] Step S301: Receive the first access request for the file.

[0061] In this embodiment of the application, the first access request may be a read request for a file or a write request for a file. The first access request will be described as a read request for a file.

[0062] Step S302: Obtain a prefetch model based on the first access request, wherein the prefetch model is used to determine a first file, the first file being the file that the prefetch model predicts the second access request will request based on the first access request, and the second access request being the next access request after the first access request.

[0063] In this embodiment, a prefetching model can be established or updated based on real-time capture of user access requests to files. The access sequence of user requests can be obtained, and then an online intelligent model is used to learn this access sequence to obtain the prefetching model. This online intelligent model is one that can acquire and learn data in real-time, such as learning the user's file access sequence and updating the model accordingly. This online intelligent model can be a Markov model. The resulting prefetching model can predict the file that the second access request will access, i.e., it can predict the file that the next access request will access.

[0064] In this embodiment, the prefetch model is used to predict the first file, that is, the prefetch model is used to predict the file that the next access request will request after the first access request. The first file is the file that the prefetch model predicts the next access request will request after the first access request. The prefetch model can predict multiple first files. The second access request is the next access request after the first access request. The second access request can be a read request or a write request to the file; this description uses a read request as an example.

[0065] In this embodiment of the application, obtaining the prefetch model based on the first access request includes: recording a third access request, wherein the third access request is the previous access request of the first access request, and obtaining the prefetch model based on the first access request and the third access request.

[0066] In this embodiment, the third access request is the previous access request before the first access request. It can be a read request or a write request to the file. This will be described as a read request to the file.

[0067] In this embodiment of the application, user access requests to files are recorded, such as recording the first access request and the third access request, to obtain the user's access sequence to files. This allows the user to learn the user's data access pattern from the user's access sequence to files. Based on a more accurate learning of the user's access pattern, the resulting prefetch model can more accurately predict the file that the user will request in the next access request after each access request.

[0068] In this embodiment of the application, obtaining a prefetch model based on the first access request and the third access request includes: assigning a first identifier to the file requested by the first access request; assigning a second identifier to the file requested by the third access request; recording the timestamp of the first access request as a first timestamp; recording the timestamp of the third access request as a second timestamp; and obtaining a prefetch model based on the first identifier, the first timestamp, the second identifier, and the second timestamp.

[0069] In this embodiment, the identifier assigned to the file requested by the access request can uniquely indicate that file. Specifically, the first identifier can uniquely indicate the file requested by the first access request, and the second identifier can uniquely indicate the file requested by the third access request. The timestamp of the first access request is the timestamp when the user initiated the first access request, i.e., the timestamp when the first access request was generated, and this timestamp is recorded as the first timestamp. The timestamp of the third access request is the timestamp when the user initiated the third access request, i.e., the timestamp when the third access request was generated, and this timestamp is recorded as the second timestamp.

[0070] Specifically, obtaining the prefetch model based on the first identifier, the first timestamp, the second identifier, and the second timestamp includes: when the time interval between the first timestamp and the second timestamp is greater than a preset time threshold, recording that the file requested by the first access request is unrelated to the file requested by the third access request; when the time interval between the first timestamp and the second timestamp is less than or equal to the preset time threshold, recording that the file requested by the first access request is related to the file requested by the third access request; and obtaining the prefetch model based on the correlation between the file requested by the first access request and the file requested by the third access request.

[0071] In this application, when the time interval between the first timestamp and the second timestamp is greater than a preset time threshold (i.e., the time interval between the first access request and the third access request is greater than the preset time threshold, i.e., the time interval between the user initiating the first access request and the third access request is greater than the preset time threshold), it can be considered that the files requested by the first access request and the third access request are unrelated, and the prefetch model can be established or updated without relying on the first access request and the third access request. Conversely, when the time interval between the first timestamp and the second timestamp is less than or equal to the preset time threshold (i.e., the time interval between the first access request and the third access request is less than or equal to the preset time threshold, i.e., the time interval between the user initiating the first access request and the third access request is less than or equal to the preset time threshold), it can be considered that the files requested by the first access request and the third access request are related, and the prefetch model can be established or updated based on the first access request and the third access request.

[0072] Specifically, user read requests for files can be captured in real time at the VFS layer. The system calls the `vfs_read` interface of the VFS layer to track file access requests in real time, recording information such as the full file path name and timestamp. It can also record information including file size and file request offset. The full file path name includes the filename and file path. The filename is a specified name for the file, which can consist of the filename and extension. The file path is the storage location of the file. The filename and file path uniquely identify the file. The timestamp is the timestamp of the access request. The file size is the size of the file requested by the access request. The file request offset measures the number of bytes counted from the beginning of the file. Typically, read or write operations start at the current file offset and increment the offset by the number of bytes read or written.

[0073] To record information for every user access request, including the full path name and timestamp of the requested file for each request, would require significant storage space, resulting in substantial resource consumption. To reduce this consumption, a hash operation is performed on the full file path name to obtain a hash value, which uniquely represents the file. The hash algorithm used in this operation includes, but is not limited to, addition hash, bitwise hash, multiplication hash, division hash, lookup table hash, and hybrid hash; this embodiment does not impose specific limitations on these algorithms.

[0074] To improve the scanning and access speed of files in file systems, storage spaces, or storage devices, a file index is created for the files on these platforms. Each file requested in an access request is assigned an index value, which can be assigned based on the order in which files are accessed. Specifically, we use a hash index structure to index files. This hash index structure includes a hash value that uniquely represents the file, and an index value assigned to each file based on the order in which files are accessed. Please refer to [further details omitted]. Figure 4a At time T, it is recorded that a total of N files were accessed from the initial time to time T. The file access sequence is in chronological order: file A: Path_A / A.jpg, file B: Path_x / x.so, file C: Path_y / y.log... file N-2: Path_B / B.png, file N-1 is an empty file, and file N: Path_z / z.so.

[0075] A hash operation is performed on the full pathname of each file, resulting in a unique hash value for each file. For example, hashing file A (Path_A / A.jp) yields hash value H1. Hashing file B (Path_x / x.so) yields hash value H4. Hashing file C (Path_y / y.log) yields hash value H2. Since file N-1 is empty, a hash operation is not performed on file N-1.

[0076] Initially, the globally recorded index value is 0. When a user requests access to file A:Path_A / A.jpg, index value 0 is assigned to file A, and the global index value increases to 1. When a user requests access to file B:Path_x / x.so, for control purposes, index value 1 is assigned to file B, and the global index value increases to 2. This process continues, assigning a unique index value to each requested file. If a user requests access to file N-1, and file N-1 is found to be empty, file N-1 is filtered out, and no index value is assigned to it. When a user requests access to file N:Path_z / z.so, index value N-1 is assigned to file N, and the global index value increases to N.

[0077] This hash index structure stores the unique hash value of each file and its corresponding index value. For example... Figure 4a As shown, the hash index structure for file A: Path_A / A.jpg includes a hash value H1 and an index value 1. Even if the full path name of the file is hashed to reduce memory usage, recording all access request information will still incur significant memory overhead. Therefore, to control the memory overhead of file access request records, we need to choose a suitable eviction algorithm to remove file records and thus control memory consumption. We choose the Least Recently Used (LRU) algorithm, so all access request records will be managed through a Least Recently Used (LRU) linked list. The Least Recently Used linked list is a memory management algorithm, a commonly used page replacement algorithm, which selects the least recently used page for eviction. To achieve this goal, the operating system uses an LRU linked list, placing the most recently accessed page at the head of the list, and pages closer to the tail of the list are the least recently accessed pages. The least recently used page can be found by using the relative position of the page in the LRU linked list. The page replacement algorithm follows the First-In-First-Out (FIFO) principle, which includes linking newly allocated pages to the head of either the inactive or active linked list. Pages are retrieved from the tail of the active linked list and linked to the head of the inactive linked list. Page tables are retrieved from the tail of the inactive linked list for memory reclamation. Here, "page" refers to the size of the storage space; the operating system divides storage space into fixed-size pages for memory allocation and management.

[0078] Specifically, please refer to the following: Figure 4bThe LRU list maintains an active list and an inactive list. When a file is accessed for the first time, it is inserted into the inactive list. When the file is accessed again, it is removed from the inactive list and inserted at the head of the active list. Files evicted from the active list are inserted at the head of the inactive list. When a file access record needs to be removed, it is removed from the end of the inactive list. Since the prefetch model is based on user access requests, its size increases exponentially with the number of access requests. Therefore, we control this by limiting the maximum index value. If the file index value reaches the maximum value, a file is evicted using the LRU list, the file at the tail of the inactive list is reclaimed, and the index value allocated to that file is reclaimed. Simultaneously, the hash index structure and the prefetch model are updated: the index value allocated to the file evicted from the inactive list is reclaimed, the index value is allocated to a new file, and the hash value of the new file is obtained. The prefetch model is related to the file's hash index structure. When the file's hash index structure is updated, the prefetch model is also updated accordingly. Please refer to the following text for the establishment and updating of the prefetch model.

[0079] To establish or update the prefetch model, a state table is maintained. This state table records information about the current access request and the previous access request. Specifically, the state table includes the first timestamp and the index value of the file requested by the first access request, and the second timestamp and the index value of the file requested by the third access request. For example, at time T, a user access request (the third access request) is detected, and the index value of the file requested by the third access request is recorded as 4, with the second timestamp as 1631.21342. At the current time, T+1, a user access request (the first access request) is detected, and the index value of the file requested by the first access request is recorded as 2, with the first timestamp as 9876.87231.

[0080] Please refer to Table 1.

[0081] The index value of the file requested in the last access. 4 Timestamp 1631.21342 The index value of the currently accessed requested file 2 Timestamp 9876.87231

[0082] Table 1

[0083] If the time interval between the timestamp of the current access request and the timestamp of the previous access request is less than or equal to a preset time interval, then the file requested by the current access request is considered to be related to the file requested by the previous access request, and the prefetch model is updated based on this relationship. If the time interval between the timestamp of the current access request and the timestamp of the previous access request is greater than the preset time interval, then the file requested by the current access request is considered not to be related to the file requested by the previous access request, and the prefetch model is not updated. That is, if the time interval between the first and third timestamps is greater than the prefetch time threshold (e.g., a preset time threshold of 24 hours), then the files corresponding to these two timestamps are considered not related, and the prefetch model is not updated. If the time interval between the first and third timestamps is greater than the prefetch time threshold (e.g., a preset time threshold of 24 hours), then the files corresponding to these two timestamps are considered not related, and the prefetch model is not updated based on this relationship.

[0084] A prefetch model can be built based on a state table or updated in real time based on a state table. Taking the Markov model as an example, the online intelligent model learns the user's access sequence to obtain the prefetch model. The Markov model is represented by a two-dimensional state transition table, i.e., the Markov model includes the Markov transition table, which consists of N rows and N columns. The Markov transition table records the number of transitions between two different files. For example, if the value recorded in the i-th row and j-th column is 2, it means that the situation of accessing the file with index j after the file with index i occurred twice. If the value recorded in the j-th row and i-th column is 1, it means that the situation of accessing the file with index j after the file with index i occurred once.

[0085] The maximum space required for the Markov transformation table is determined based on the set maximum index value. If the maximum index value is set to N, then N represents the maximum number of files that can be recorded, which also determines the maximum space required for the Markov transformation table. Memory space of size N*N data is allocated to store the Markov transformation table. The Markov transformation table records the historical access information between pairs of files. Based on this model, when accessing a file, files with a larger number of historical transformations are more likely to be prefetched. Please refer to Table 2.

[0086] 1 2 3 … N 1 / 3 2 … 0 2 0 / 1 … 0 3 0 3 / … 0 … … … … … … N 0 2 0 … /

[0087] Table 2

[0088] As shown in Table 2, the value in the second row and third column is 1, indicating that the conversion between the file with index value 2 and the file with index value 3 occurred once. For example, accessing the file with index value 3 after the file with index value 2 occurred once. The value in the third row and second column is 3, indicating that the conversion between the file with index value 3 and the file with index value 2 occurred three times.

[0089] For example, please refer to the following: Figure 4c , Figure 4c This is a schematic diagram of a Markov model provided in an embodiment of this application. The Markov model includes the number of transformations between each file. For example, if the arrow pointing from the file with index value 1 to the file with index value 6 indicates a transformation count of 1, meaning that accessing the file with index value 6 after the file with index value 1 occurred once. The file with index value 6 does not have an arrow pointing to the file with index value 1, meaning that accessing the file with index value 1 after the file with index value 6 occurred 0 times.

[0090] In this embodiment, an initial prefetch model can be pre-established by simulating user access requests. This allows prefetching to be performed based on the initial prefetch model when the first user access request is detected (i.e., when the first access request is detected at the initial moment). Subsequently, user access request data is continuously acquired, and the initial prefetch model is updated accordingly.

[0091] In this embodiment, the prefetching model can be established and updated after continuously acquiring user access request data. For example, if a user access request is detected at the initial time, the prefetching model has not yet been established, so prefetching is not performed. At the next time T1, if a user access request is detected and it is determined that the time interval between the initial time and T1 is less than a preset time threshold, a prefetching model is established based on the user access request at the initial time and the user access request at T1, and the number of conversions between file A requested at the initial time and file B requested at T1 is recorded as 1. At the next time T2 after T1, if a user access request is detected and it is determined that the time interval between T1 and T2 is less than a preset time threshold, a prefetching model is established based on the user access request at T1 and the user access request at T2, and the number of conversions between file B requested at T1 and file C requested at T2 is recorded as 1. At T2, the prefetching model includes one instance of accessing file B after file A and one instance of accessing file C after file B. At time T3, the next time step after time T2, a user access request is detected. It is determined that the time interval between time T2 and time T3 is less than a preset time threshold. Therefore, a prefetch model is established based on the user's access request at time T3 and time T2. The number of conversions between file A requested at time T3 and file C requested at time T2 is recorded as 1. At time T3, the prefetch model includes one instance of accessing file B after file A, one instance of accessing file C after file B, and one instance of accessing file A after file C. At time T4, the next time step after time T3, a user access request is detected. It is determined that the time interval between time T3 and time T4 is less than a preset time threshold. Therefore, the prefetch model is updated based on the user's access request at time T3 and time T4. The number of conversions between file B requested at time T4 and file A requested at time T3 is recorded as 1. At time T4, the prefetch model includes two instances of accessing file B after file A, one instance of accessing file C after file B, and one instance of accessing file A after file C. This process is repeated to continuously update or build the prefetch model in order to obtain the prefetch model.

[0092] In this embodiment, the prefetch model records the number of conversions between each file. When a file is accessed, the higher the number of conversions recorded in the corresponding entry, the more likely the file is to be read in the future. That is, the first file includes files with a higher number of recorded conversions. A conversion count threshold can be set; if the number of conversions exceeds this threshold, the corresponding file is the first file.

[0093] For example, if the conversion count threshold is set to 3, the conversion count between the file with index value 1 and the file with index value 2 is 8, the conversion count between the file with index value 1 and the file with index value 3 is 2, the conversion count between the file with index value 1 and the file with index value 6 is 4, and the conversion count between the file with index value 1 and the file with index value 7 is 5. Since the conversion counts 8, 5, and 4 are greater than the conversion count threshold 3, the files with index values ​​2, 6, and 7 are more likely to be read in the future. Therefore, it can be determined that the first file includes the files with index values ​​2, 6, and 7.

[0094] Please refer to the following: Figure 4c When accessing a file, we select files for prefetching based on the Markov transformation table. If the number of transformations of a file in the same row exceeds the transformation threshold (e.g., 1 by default), the corresponding file is identified as the first file. For example, if the file requested by the current first access request is the file with index value 1, the number of transformations from the file with index value 1 to the file with index value 2 is 3, the number of transformations from the file with index value 1 to the file with index value 3 is 2, and the number of transformations from the file with index value 1 to the file with index value 2 is 1, then the first file can be determined to include the file with index value 2 and the file with index value 3.

[0095] Step S303: Obtain the first prefetch window based on historical hit information.

[0096] In this embodiment, to best improve prefetch hit rate, data prefetching is performed based on a prefetch window, where the first prefetch window represents the size of the data prefetched at one time. Taking file prefetching as an example, we prefetch files based on a prefetch window, which represents the number of files prefetched at one time. Therefore, the first prefetch window is the prefetch window used when prefetching is performed after the first access request is detected.

[0097] In this embodiment, a hit refers to the data of any access request being read out in advance and placed in "upper-layer storage," such as in a cache. Historical hit data can be statistically analyzed to obtain historical hit information, such as the historical hit rate or whether the previous access request was successful. The historical hit rate can be the ratio of the number of hits to the number of misses in the obtained historical hit data.

[0098] In this embodiment, a second prefetch window can be obtained, and adjusted according to historical hit information to obtain the first prefetch window upon which this prefetch is based. The second prefetch window can be an initially set prefetch window or a prefetch window adjusted after the previous prefetch. For example, the second prefetch window can be a prefetch window preset at the initial time. The second prefetch window can also be a previous prefetch window. For instance, if the first prefetch window at time T-1 is A, then at time T, prefetch window A becomes the second prefetch window. The second prefetch window A is adjusted according to historical hit information, and then the first prefetch window B is obtained. At time T+1, the second prefetch window B is adjusted according to historical hit information, and then the first prefetch window C is obtained.

[0099] In one possible implementation, an initial prefetch window, namely a second prefetch window, can be pre-set. During the first prefetch, since there is no historical hit information, prefetching can be performed directly based on the second prefetch window. During the next prefetch, the size of the second prefetch window can be adjusted based on the historical hit information to obtain a first prefetch window, and then prefetching can be performed based on the first prefetch window.

[0100] In one possible implementation, an initial prefetch model and an initial prefetch window (i.e., a second prefetch window) can be pre-set. The initial prefetch model is tested to obtain its historical hit information. When the first access request is detected initially, prefetching is performed based on this initial prefetch window. When the first access request is detected again, the initial prefetch window can be adjusted based on its historical hit information to obtain the first prefetch window.

[0101] In one possible implementation, obtaining the first prefetch window based on historical hit information includes: obtaining a second prefetch window; obtaining a historical hit rate based on historical hit information; when the historical hit rate is lower than a preset threshold, reducing the second prefetch window to obtain the first prefetch window; and when the historical hit rate is greater than or equal to the preset threshold, increasing the second prefetch window to obtain the first prefetch window.

[0102] In this embodiment, the historical hit rate can be the ratio of the number of historical hits to the number of historical misses, or the ratio of the number of historical hits to the total number of historical prefetches. The historical hit rate is calculated based on the historical hit information of the prefetch model. Since the historical hit rate changes with each prefetch, the corresponding first prefetch window is also related to the historical hit information.

[0103] In one possible implementation, obtaining the prefetch window based on historical hit information includes: obtaining a second prefetch window; determining whether the file requested by the first access request has been pre-stored in the cache based on the historical hit information; if not, shrinking the second prefetch window to obtain a first prefetch window; if yes, increasing the second prefetch window to obtain the first prefetch window.

[0104] In this embodiment of the application, the size of the current prefetch window can be adjusted according to the previous prefetch situation. That is, if prefetching is performed at time T, it is determined whether the prefetch at time T-1 is successful, that is, whether the file requested at time T has been pre-read into the cache. If not, the prefetch window can be appropriately reduced; if so, the prefetch window can be appropriately increased.

[0105] Specifically, when accessing a file, we select the file for prefetching based on the Markov transformation table, that is, we select the first file for prefetching. If the number of transformations of files in the same row exceeds a certain threshold (default is 2), then the corresponding file is the first file, and we put the first file into the prefetch window, until the maximum prefetch window size (default 8) is reached or no file meets the prefetch requirements. Figure 4b As shown, when accessing the file with index value 1, the files with index value 2 and index value 3 will be placed in the first prefetch window because the number of conversions for the files with index value 2 and index value 3 has exceeded the conversion threshold.

[0106] However, if the data prefetch hit rate is low, indiscriminate prefetching will waste memory resources and bandwidth. Therefore, we dynamically adjust the file prefetch window based on historical hit rates. Please refer to [link / reference needed]. Figure 5 Before each prefetch, the prefetch window is adjusted to obtain the first prefetch window, and prefetching is then performed based on this first prefetch window. Initially, the window size is set to 1, and the maximum prefetch window size is set to 8 and the minimum prefetch window size is set to 1. It is determined whether the previous prefetch at the current time was a hit. If so, the prefetch window size is increased, for example, by doubling the prefetch window size. It is then determined whether the increased prefetch window size is greater than or equal to the maximum prefetch window size. If so, the prefetch window size is adjusted to the maximum prefetch window size of 8. If not, the size of the first prefetch window is the increased prefetch window size. If the previous prefetch at the current time was a hit, the prefetch window size is reduced, for example, by halving the prefetch window size. It is then determined whether the reduced prefetch window size is less than or equal to the minimum prefetch window size of 1. If not, the prefetch window size is adjusted to the minimum prefetch window size of 1. If not, the size of the first prefetch window is the increased prefetch window size. The prefetch window adjustment ends, and the first prefetch window is obtained.

[0107] For example, the initial prefetch window size is set to 1. At time T, it is determined whether the previous prefetch hit occurred, i.e., whether the file requested at time T-1 has been prefetched into the cache. If so, the initial prefetch window size is doubled, i.e., adjusted to 2, resulting in a first prefetch window size of 2 at time T. If not, the initial prefetch window size is halved, resulting in a prefetch window size of 0.5. Since this prefetch window size is less than the minimum prefetch window size of 1, the first prefetch window size at time T is adjusted to the minimum prefetch window size of 1. If the prefetch hits at time T-1, the prefetch window size at time T is 2. At time T2, it is determined whether the previous prefetch hit occurred, i.e., whether the file requested at time T has been prefetched into the cache. If so, the initial prefetch window size is doubled, i.e., adjusted to 4, resulting in a first prefetch window size of 4 at time T1. If not, halve the initial prefetch window size, then the prefetch window size is 1. If the prefetch window size is equal to the minimum prefetch window size of 1, then adjust the size of the first prefetch window at time T to 1.

[0108] Step S304: Obtain the second file based on the first prefetch window and the first file.

[0109] In this embodiment, after determining the size of the first prefetch window, the number of files to be prefetched can be obtained. Based on the number of files to be prefetched, the corresponding number of files are extracted from the first file to obtain the second file. Prefetching is performed on the first file determined by the Markov model. When the number of conversions of a file in the same row as the first file exceeds a certain conversion threshold (default is 2), the corresponding file is placed in the first prefetch window. This process continues until the number of files placed in the first prefetch window reaches the maximum window size (default is 8) or no first file meets the prefetching requirements, i.e., no file's conversion count exceeds the conversion threshold.

[0110] For example, if the first prefetch window is 5 and the first file includes 6 files, then 5 files are determined from the 6 files, and these 5 determined files are the second files. If the first prefetch window is 5 and the first file includes 4 files, since the number of first files is less than the size of the first prefetch window, all 4 first files can be determined as second files.

[0111] In one possible implementation, files with higher conversion counts from the first file can be prioritized for inclusion in the first prefetch window based on their conversion counts. This process continues until the first prefetch window reaches its maximum size or there are no more first files available. For example, if the first prefetch window is 3, and the first file consists of four files: A, B, C, and D, with A having a conversion count of 6, B having a conversion count of 5, C having a conversion count of 4, and D having a conversion count of 3, then files with higher conversion counts from the first file are prioritized for inclusion in the first prefetch window. That is, file A is included first, followed by file B, and finally file C.

[0112] Step S305: Store the preset data in the second file in the cache.

[0113] In this embodiment, to reduce the memory footprint of prefetched data, a portion of the data from the second file can be stored in the cache, rather than storing all the data from the second file in the cache. For example, if the second file includes file A and file B, then a portion of the data from file A and a portion of the data from file B are stored in the cache. This portion of the data can be the first N pages of the file; this embodiment does not specifically limit this.

[0114] In this embodiment of the application, file prefetching data can be controlled based on the file internal prefetching strategy. Taking the Readahead file internal prefetching strategy as an example, a file can be selected to prefetch at most the first two pages. If the file internal access mode is sequential, internal file prefetching will be performed automatically after reading the first two pages.

[0115] In this embodiment, the size of the Markov model is controlled by controlling the maximum index value of the file. However, the actual situation may be more complex, requiring the storage of a large number of file access records to improve prefetch hit rate. Furthermore, when building or updating the prefetch model, the model size can be further reduced based on a file classification method. By classifying the accessed files, different types of access requests are identified, and corresponding prefetch models are built or updated according to these different types of access requests. This aims to reduce the prefetch model size without compromising prefetch accuracy.

[0116] In one possible implementation, obtaining the prefetch model based on the first access request further includes: determining the type of the first access request based on the file type requested in the first access request; and obtaining the corresponding prefetch model based on the type of the first access request.

[0117] In this embodiment, the type of the first access request is determined based on the file type requested by the first access request, and a corresponding prefetch model is established based on the different types of first access requests, thereby compressing the size of the established prefetch model. When classifying file types, files can be classified by semantic analysis of directories, or by different applications, such as system files and user files.

[0118] For example, access requests are categorized into system files and user files because these two types of files are relatively separate in terms of access. Although system files and user files may have associations, the access sequence for system files is generally more fixed, while the access sequence for user files is more arbitrary. Therefore, separating these two types of files can also reduce some erroneous associations. Regarding the classification of system files and user files, since files accessed by users are generally located in semantically clear directories, we identify user files by their file paths, while the remaining files are system files. Please refer to [further details omitted]. Figure 6 The original access request files recorded were 5. After classification, the requested files were divided into 3 system files and 2 user files. Then, models were built for each type of file. The first prefetch model was built or updated based on the access requests corresponding to the 2 user files, and the second prefetch model was built or updated based on the access requests corresponding to the 3 system files. As a result, the space usage of the original model was reduced from 5*5 to 3*3+2*2, a reduction of 53%.

[0119] In one possible implementation, there are applications A, B, and C. At time T, if the user's first access request requests a file from application A, then the prefetch model is built or updated based on the access request for application A. At time T+1, if the user's first access request requests a file from application B, then the prefetch model is built or updated based on the access request for application B. At time T+2, if the user's first access request requests a file from application C, then the prefetch model is built or updated based on the access request for application C. This results in three different prefetch models.

[0120] In one possible implementation, if the document prediction model has a low prediction accuracy, i.e., the hit rate consistently falls below a certain threshold, the prefetched model data is cleared, and the model is rebuilt and updated. For example... Figure 6 As shown, if the hit rate of the first prefetch model is lower than a certain threshold, the first prefetch model is deleted, new user access request data is obtained again, and a new first prefetch model is established or updated.

[0121] In this embodiment, file-level prefetching improves prefetch hit rate and reduces data access latency without significantly impacting memory usage. Three real workloads and four simulated workloads were used for testing, including workloads one through eight. For example, workload one is image gallery browsing, workload two is document browsing, workload three is short video browsing, workload four is Facebook, workload five is Twitter, workload six is ​​the MOOC webserver, and workload seven is a file server. Workload eight is the average of workloads one through seven, i.e., a combination of workloads one through seven. The test machine configuration was: Intel i5-9500 processor, 16GB of RAM, and an M.2 Teclast 256GB NP900-2280 SSD. The experimental comparison objects include Models 1 through 5. Model 1 is the Readahead model, a sequential prefetching method built into the Linux system. Readahead is a file internal page prefetching strategy in the Linux kernel. This strategy determines the current access sequence by checking whether adjacent page accesses are sequential. If a sequential pattern is identified, sequential prefetching is performed; otherwise, the prefetch size is halved until prefetching is disabled. This is a commonly used prefetching strategy. Model 2 is a Markov-based file internal prefetching method. This method maintains a Markov state machine for each file, where each state represents a page in the file. The entity of a Markov state machine is a state transition table, which records the number of transitions between file pages. Based on the currently accessed page, the page with the highest transition probability in the state table is prefetched each time. When the accuracy falls below a certain threshold, the state table is regenerated. Model 3 is a trie-based file prefetching method. This method is an SSD internal prefetching strategy based on the frequent tree FP-Growth algorithm. This prefetching method prefetches data from the flash memory chip to the SSD's internal cache to improve SSD access speed. Specifically, this method analyzes the SSD access LBA sequence within a certain time period and then mines frequent object sets. During prefetching, the existing frequent sets are matched. If half of the addresses in a frequent set are accessed, the remaining addresses in that frequent set are prefetched into the SSD cache. Model four is the prefetching model in this embodiment, and model five is a prefetching model in this embodiment with added model reduction functionality, that is, it adds the function of determining the type of the first access request based on the file type requested by the first access request, and obtaining the corresponding prefetching model based on the type of the first access request. The default setting for the maximum file index is determined to be 512.

[0122] like Figure 7aAs shown, in terms of average read latency, Model 2 improves upon Model 1 across all loads for intra-file prefetching because Model 1 can identify more random access patterns within a file. For inter-file prefetching, Model 3 improves performance by an average of 13.6%. In almost all loads, Model 4 in this embodiment performs best, especially on Facebook and Twitter loads, where it shows a significant performance improvement of 40% compared to Model 3. However, the improvement is not significant for the first two types of loads (image gallery browsing and document browsing), because these loads are mostly sequential accesses, and Model 1 is the most frequently hit. Please refer to [further details omitted]. Figure 7b The hit rate of all prefetching strategies was low. Although Model 3 showed some improvement, its resource consumption was too high. In addition, the performance of Model 5 did not decrease significantly compared to Model 4. In fact, on some workloads such as Twitter, Model 5 outperformed Model 4, which also proved the feasibility of our model compression method.

[0123] This application also provides a computer-readable storage medium. The storage medium stores computer instructions that, when executed on a computing device, cause the computing device to perform the prefetching method provided in the foregoing embodiments.

[0124] Embodiments of this application also provide a computer program product, which includes computer program code. When the computer program code is executed by a computer, it causes the computer to perform the method described above. Therefore, by swapping non-fluttering anonymous pages into an inactive linked list, non-fluttering anonymous pages can be swapped out before fluttering anonymous pages, reducing the probability of fluttering anonymous pages being swapped out, thereby reducing data thrashing of anonymous pages. This reduces invalid anonymous page reclamation under high system memory pressure, improving the efficiency of anonymous page memory reclamation.

[0125] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application. Therefore, any appropriate changes and variations made to the above embodiments within the essential spirit and scope of this application should fall within the scope of protection claimed by this application.

Claims

1. A prefetching method, characterized by, The method comprises: receiving a first access request for a file; when a time interval between a first timestamp corresponding to the first access request and a second timestamp corresponding to a previous access request of the first access request is less than or equal to a preset time threshold, obtaining a prefetch model according to the first access request and the previous access request of the first access request, wherein the prefetch model is used to determine a first file, the first file being a file predicted by the prefetch model based on the first access request to be requested by a second access request, the second access request being a next access request of the first access request; obtaining a first prefetch window according to historical hit information; obtaining a second file according to the first prefetch window and the first file; storing preset data in the second file in a cache.

2. The prefetching method of claim 1, wherein, The obtaining of the first prefetch window according to the historical hit information comprises: obtaining a second prefetch window; obtaining a historical hit rate according to the historical hit information; when the historical hit rate is lower than a preset threshold, reducing the second prefetch window to obtain the first prefetch window; when the historical hit rate is greater than or equal to the preset threshold, increasing the second prefetch window to obtain the first prefetch window.

3. The prefetching method of claim 1, wherein, The obtaining of the first prefetch window according to the historical hit information comprises: obtaining a second prefetch window; judging whether a file requested by the first access request is pre-stored in a cache according to the historical hit information; if not, reducing the second prefetch window to obtain the first prefetch window; if yes, increasing the second prefetch window to obtain the first prefetch window.

4. The prefetching method of claim 1, wherein, After receiving the first access request for the file, the method further comprises: allocating a first identifier for the file requested by the first access request, the first identifier being used to indicate the file requested by the first access request.

5. The prefetch method of any one of claims 1 to 4, wherein, After receiving the first access request for the file, the method further comprises: when a time interval between the first timestamp and the second timestamp is greater than the preset time threshold, recording that the file requested by the first access request is irrelevant to a file requested by a previous access request of the first access request; when the time interval between the first timestamp and the second timestamp is less than or equal to the preset time threshold, recording that the file requested by the first access request is relevant to the file requested by the previous access request of the first access request.

6. An electronic device, comprising: comprise: a memory for storing a computer program; a processor for executing the computer program stored in the memory, when the computer program is executed, the processor is used to execute the prefetch method in any one of claims 1 to 5.

7. A computer readable storage medium characterized by The computer readable storage medium comprises computer instructions, when the computer instructions run on an electronic device, the computer instructions make the electronic device execute the prefetch method in any one of claims 1 to 5.

8. A computer program product, characterised in that, The computer program product comprises computer program code, when the computer program code is executed by a computer, the computer program code can make the computer execute the prefetch method in any one of claims 1 to 5.

Images