Loading of image file

Abstract

The present application provides a loading method for an image file, an apparatus, an electronic device, and a storage medium. The method comprises: on the basis of target image disk creation information of a target cloud disk and a heatmap address database, acquiring a storage address of a reference disk creation heatmap, wherein the heatmap address database is used for storing the correspondence between first image disk creation information of a historical cloud disk and a storage address of a disk creation heatmap thereof, and the disk creation heatmap is used for indicating an access sequence of sub-blocks in block devices corresponding to image files during creation of the historical cloud disk; on the basis of the storage address of the reference disk creation heatmap, acquiring the reference disk creation heatmap; and according to the access sequence indicated by the reference disk creation heatmap, loading sub-blocks of a target block device corresponding to a target image file.

Description

[0001] Image file loading technology field

[0002]

[0001] The present application relates to the field of cloud computing technology, and in particular to the loading of image files.

[0003] With the development of cloud computing technology and the explosive growth of data, cloud storage services powered by cloud computing are widely used in various fields. Block storage, currently the most widely used cloud storage service, provides low-latency, persistent, and highly reliable block-level random access storage. To access the services provided by block storage, users can create a cloud disk based on an image file. Typically, image files are not stored locally on the user, but rather in OSS (Object Storage Service). Therefore, the image file must first be loaded from OSS to the user's local computer.

[0004] In a block storage scenario, an image file typically stores data for a series of block devices, including a file system. The block device is divided into multiple sub-blocks at a certain granularity, and each sub-block is assigned a corresponding number. When loading an image file, the related art typically loads the sub-blocks sequentially in ascending order of number. For example, if the block device abstracted by the image file is divided into 20,480 sub-blocks, numbered from 0 to 20,479, loading will start from sub-block numbered 0 and continue to sub-block numbered 20,479.

[0005]

[0004] However, during the cloud disk creation process, the front-end accesses the sub-blocks in a non-sequential order. Related technologies load sub-blocks in numerical order. This can lead to situations where, when the front-end needs to access a sub-block, it is not loaded because it is numbered later. At this point, the front-end needs to wait for the sub-block to be loaded before continuing to create the cloud disk. This results in a higher input / output (I / O) delay during cloud disk creation, leading to a longer cloud disk creation time. Summary of the Invention

[0006]

[0005] Embodiments of the present application provide a method, apparatus, electronic device, and storage medium for loading an image file. These methods predict the order in which sub-blocks in a block device corresponding to an image file are accessed during cloud disk creation, and then load each sub-block based on the order. This eliminates the need to wait for the sub-blocks to be loaded, reduces some of the delay during cloud disk creation, and thereby shortens the cloud disk creation time. The technical solution is as follows.

[0007]

[0006] In a first aspect, a method for loading an image file is provided, the method comprising: obtaining a storage address of a reference disk creation heat map based on target image disk creation information of a target cloud disk to be created and a heat map address database, the heat map address database being used to store a correspondence between first image disk creation information of a created historical cloud disk and the storage address of its disk creation heat map, the disk creation heat map being used to indicate an access order of each sub-block in a block device corresponding to the image file during a historical cloud disk creation process, the reference disk creation heat map being a disk creation heat map corresponding to the first image disk creation information having a similarity with the target image disk creation information greater than a preset threshold; obtaining the reference disk creation heat map based on the storage address of the reference disk creation heat map; and loading each sub-block of a target block device according to the access order indicated by the reference disk creation heat map, the target block device being a block device corresponding to the target image file to be loaded during the target cloud disk creation process.

[0008]

[0007] In a second aspect, a device for loading an image file is provided, the device comprising: a first acquisition module, configured to acquire a storage address of a reference disk creation heat map based on target image disk creation information of a target cloud disk to be created and a heat map address database, the heat map address database being configured to store a correspondence between first image disk creation information of a historical cloud disk that has been created and the storage address of its disk creation heat map, the disk creation heat map being configured to indicate an access order of each sub-block in a block device corresponding to the image file during a historical cloud disk creation process, the reference disk creation heat map being a disk creation heat map corresponding to first image disk creation information having a similarity with the target image disk creation information that is higher than a preset threshold; a second acquisition module, configured to acquire the reference disk creation heat map based on the storage address of the reference disk creation heat map; and a loading module, configured to load each sub-block of a target block device according to an access order indicated by the reference disk creation heat map, the target block device being a block device corresponding to a target image file that needs to be loaded during the target cloud disk creation process.

[0009]

[0008] In a third aspect, an electronic device is provided, comprising a processor and a memory; the memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the image file loading method as described in the first aspect.

[0010]

[0009] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by a processor, the image file loading method as described in the first aspect can be implemented.

[0011]

[0010] In a fifth aspect, a computer program product is provided, the computer program product including a computer program, and when the computer program is executed by a processor, the image file loading method as described in the first aspect can be implemented.

[0012]

[0011] The beneficial effects of the technical solution provided by the embodiment of the present application are as follows: Considering that the process of creating a cloud disk based on an image file is actually the process of loading the data in the image file onto the disk mounted by the electronic device, the image creation information can reflect the relevant information of the image file that needs to be loaded during the cloud disk creation process, and the relevant information includes the image file that needs to be loaded and the access order of each sub-block in the block device corresponding to the image file. In view of this, the embodiment of the present application constructs a heat map address database, which stores the corresponding relationship between the first image creation information of the historical cloud disk and the storage address of the creation heat map. The creation heat map can indicate the access order of each sub-block in the block device corresponding to the image file during the historical cloud disk creation process. Based on the creation heat map, the access order of each sub-block in the block device corresponding to the image file by the front end during the historical cloud disk creation process can be obtained. For two cloud disks, if the similarity between the image creation information of the two cloud disks is high, then the access order of each sub-block in the block device corresponding to the image file during the creation of the two cloud disks will also be relatively similar. Based on the above analysis, during the target cloud disk creation process, the embodiment of the present application does not load the target block device corresponding to the target image file to be loaded according to the numbering order of each sub-block. Instead, based on the heat map address database and the target cloud disk's target image creation information, a reference disk creation heat map corresponding to the first image information with a similarity greater than a preset threshold to the target image creation information is obtained. Because the access order of each sub-block in the target block device during the target cloud disk creation process is highly similar to the access order indicated by the reference disk creation heat map, each sub-block in the target block device is loaded based on the access order indicated by the reference disk creation heat map. This allows the sub-block of the target block device to be loaded in advance before the front-end needs to access it, thereby reducing the front-end's 10-second latency and shortening the cloud disk creation time. Description of the Figures

[0013]

[0012] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.

[0014] FIG1 is a schematic diagram of a process of loading data blocks into a block device corresponding to an image file according to a related art;

[0015]

[0014] FIG2 is a schematic diagram of a process of loading each data block in a block device corresponding to an image file according to an embodiment of the present application;

[0016] FIG3 is a schematic diagram of an implementation environment involved in a method for loading an image file provided in an embodiment of the present application;

[0017] FIG4 is a schematic diagram of an implementation environment involved in a method for loading an image file provided in an embodiment of the present application;

[0018] FIG5 is a flow chart of a method for loading an image file according to an embodiment of the present application;

[0019] FIG6 is a schematic diagram of a process for generating a heat map of a cascade provided in an embodiment of the present application;

[0020] FIG7 is a schematic diagram of a process for loading an image file according to an embodiment of the present application;

[0021]

[0020] FIG8 is a schematic structural diagram of an image file loading device provided in an embodiment of the present application;

[0022]

[0021] FIG9 shows a block diagram of an electronic device 900 provided by an exemplary embodiment of the present application.

[0023]

[0022] In order to make the purpose, technical solutions and advantages of this application more clear, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0024] It is understood that the terms "each", "a plurality", and "any" used in the embodiments of the present application include two or more, each refers to each of the corresponding plurality, and any refers to any one of the corresponding plurality. For example, a plurality of words includes 10 words, and each word refers to each of the 10 words, and any word refers to any one of the 10 words.

[0025]

[0024] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject.

[0026]

[0025] Before executing the embodiments of the present application, the terms involved in the present application are first explained.

[0027]

[0026] EBS (Elastic Block Store), also known as cloud disk, is a block storage product at the data block level with the characteristics of low latency, high performance, persistence, and high reliability.

[0028] Lazy loading is a delayed loading technique that typically does not load all data into memory at once. Instead, it loads the data to be processed into memory in chunks. Using lazy loading can reduce memory usage and the consumption of network resources by loading data at once, thereby improving program performance and stability.

[0029]

[0028] Mirroring is a form of file storage and a type of redundancy. Generally speaking, a mirror is a copy of the data on a disk stored on another disk.

[0030]

[0029] A snapshot is a backup of cloud disk data at a certain moment.

[0031]

[0030] Object Storage Service (OSS) is a massive, secure, low-cost, and highly reliable cloud storage service suitable for storing any type of file.

[0032]

[0031] SLS (Simple Log Service) is a cloud-native observation and analysis platform that provides large-scale, low-cost, real-time platform services for log, metric, and trace data. It can provide functions such as data collection, processing, query and analysis, visualization, alerting, consumption and delivery, and can comprehensively enhance users' digital capabilities in R&D, operation and maintenance, operations, security and other scenarios.

[0033]

[0032] ODPS (Open Data Processing Service) is a big data computing platform that provides massive data storage and computing services and supports multiple computing engines and programming languages ​​including MaxCompute and Spark.

[0034] Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system refers to a storage system that uses cluster applications, grid technology, and distributed storage file systems to bring together a large number of different types of storage devices (also known as storage nodes) in a network through application software or application interfaces to work together and provide external data storage and access capabilities. Cloud storage is primarily intended for cloud customers running on cloud provider hardware. These features can meet a variety of different needs and support pay-per-use. In the cloud storage model, the provider is responsible for maintaining the underlying hardware and ensuring data availability, resiliency, and security. Common cloud storage types include object storage, block storage, and file storage, but this application applies to block storage scenarios.

[0035] Currently, image files are typically stored on OSS. When creating a cloud disk based on an image file, the EBS backend needs to first load the image file locally to the user. In a block storage scenario, to facilitate loading the block device corresponding to the image file, the block device is divided into multiple sub-blocks according to a certain granularity, and a corresponding number is assigned to each sub-block. To reduce the user's local memory usage and avoid application crashes or system freezes, the EBS backend typically uses a lazy load read (LazyLoadRead) strategy to load each sub-block in the block device corresponding to the image file. However, when using the lazy read strategy to load the block device corresponding to an image file, each sub-block in the block device corresponding to the image file is not loaded all at once. Instead, each sub-block is loaded incrementally as the frontend accesses it. If a sub-block has not yet been loaded when the frontend accesses it, the frontend must wait for it to be loaded before creating the cloud disk. In this case, due to the high latency of the EBS backend 10, the cloud disk creation process takes a long time, resulting in long wait times for the service and even leading to task failure and damage. Therefore, it is crucial to load each sub-block in the block device corresponding to the image file to reduce the latency of the EBS backend 10 and shorten the cloud disk creation process.

[0036]

[0035] In the related art, when loading each sub-block in the block device corresponding to the image file, the sub-blocks are loaded according to the numbering order of the sub-blocks. However, during the cloud disk creation process, the order in which the front end accesses the sub-blocks is inconsistent with the numbering order of the sub-blocks. Therefore, there may be a situation where the front end needs to access a sub-block but the sub-block has not been loaded, resulting in a large delay in the EBS backend 10 and a long cloud disk creation time. As shown in Figure 1, the block device is divided into 20480 sub-blocks. In the order of division, the 20480 sub-blocks are numbered 0 to 20479. When creating a cloud disk, the relevant technology starts loading sub-blocks from sub-block 0 according to their numbers and continues loading sub-block 20479. During the loading process of each sub-block, the front-end accesses the EBS back-end in real time. At a certain moment, the EBS back-end has loaded sub-blocks 1, 2, 3, 4, and 5. At this time, the front-end needs to access sub-block 19. Since sub-block 19 has not been loaded, it needs to wait until the EBS back-end has loaded sub-block 19 before continuing to create the cloud disk. After accessing sub-block 19, the front-end needs to access sub-block 106. However, sub-block 106 has not been loaded. Therefore, It is also necessary to wait for the sub-block numbered 106 to be loaded. In the process of creating a cloud disk using the related technology, the EBS backend 10 has a large delay due to the need to constantly wait for the required sub-blocks to be loaded, and the cloud disk creation time is long.

[0037] During the initial stage of creating a cloud disk based on an image file (referred to as image creation), the operating system portion of the image file is loaded first. Analysis of logs (block device logs) from the initial stage of historical cloud disk creation reveals that logs for cloud disks created from different image files exhibit varying degrees of similarity. This similarity is primarily reflected in the degree of overlap in access addresses for block devices when creating a cloud disk based on an image file. The higher the degree of access address overlap, the greater the similarity in access patterns for block devices when creating a cloud disk based on an image file. Based on the similarity in access patterns during the image creation process, image files are divided into three clusters: official image files with the same operating system and version; official image files with different versions of the same operating system; and custom image files. Generally speaking, when creating a cloud disk based on an official image file with the same operating system and version, the access pattern similarity is the highest; when creating a cloud disk based on an official image file with different versions of the same operating system, the access pattern similarity is second highest; and when creating a cloud disk based on a custom image file, the access pattern similarity is the lowest.

[0038]

[0037] Based on the above theory, an embodiment of the present application proposes a method for loading an image file. The method provides a loading sequence generation model (i.e., a BPHMap (Best Preload HeatMap) model). The loading sequence generation model is called to process the first image creation information and block device log of the historical cloud disk to generate a creation heat map corresponding to the historical cloud disk. The creation heat map generated for the historical cloud disk is then stored in the OSS, and the storage address of the creation heat map in the OSS is obtained. The first image creation information of the historical cloud disk and the storage address of the creation heat map are then stored in the heat map address database. During the target cloud disk creation process, the storage address of a reference disk creation heat map is obtained based on the target image creation information and the heat map address database of the target cloud disk. Then, based on the storage address of the reference disk creation heat map, a reference disk creation heat map is obtained. This reference disk creation heat map is a disk creation heat map where the similarity between the first image creation information and the target image creation information exceeds a preset threshold. Furthermore, based on the access order indicated by the reference disk creation heat map, each sub-block in the target block device corresponding to the target image file is loaded. This allows the corresponding sub-blocks to be pre-loaded before the front-end access request arrives, reducing the target image file's latency during lazy loading and shortening the target cloud disk creation time.

[0039] FIG2 illustrates the process of loading the block device corresponding to the image file in FIG1 using the method provided in an embodiment of the present application. Referring to FIG2 , for example, for the image file shown in FIG1 , the EBS backend does not load the image file according to the order in which the sub-blocks are numbered, but rather loads the image file based on a predicted loading order. After loading sub-block numbered 3, sub-block numbered 19 is loaded, followed by sub-block numbered 106. Thus, upon receiving an access request from the front end for sub-block numbered 19, sub-block numbered 19 can be directly accessed without waiting. This reduces the loading latency of the block device corresponding to the image file and shortens the image file creation time. Experiments have shown that using the method provided in an embodiment of the present application can reduce the average latency of lazy loading read operations by 89.27% ​​and the median latency by 96%, thereby optimizing system performance.

[0040]

[0039] Figure 3 shows the system involved in the cloud disk creation process in an embodiment of the present application, see Figure 3, including a core system, an analysis system and an agent system.

[0041]

[0040] The core system may include multiple clusters (e.g., clusters 1-N), a snapshot OSS, etc. The snapshot OSS is used to receive a loading policy sent by any cluster and send the received loading policy to each cluster. Each cluster may provide multiple external interfaces for recommending a loading order for each sub-block in the block device corresponding to the image file based on the loading policy sent by the proxy system to complete the creation of the cloud disk.

[0042] The proxy system may include multiple components, such as a first proxy component and a second proxy component. The first proxy component is configured to receive a notification collection message sent by the analysis platform of the analysis system and send the notification collection message to the second proxy component. The second proxy component is configured to, after receiving the notification collection message, obtain the log record of the created historical cloud disk sent by the cluster in the core system and send the received log record to the analysis platform of the analysis system. The first proxy component is also configured to receive the characteristics of the historical cloud disk sent by the core system (i.e., the disk creation heat map), generate a loading strategy based on the received characteristics, and send the loading strategy to any cluster.

[0043]

[0042] The analysis system may include an analysis platform. The analysis platform is used to obtain image creation information of a created historical cloud disk. The image creation information may be sourced from multiple computing platforms or databases, such as SLS, ODPS, ADB, etc. The analysis platform is further used to obtain the log record of the historical cloud disk, generate features corresponding to the historical cloud disk based on the image creation information and the log record of the historical cloud disk, and then send the generated features of the historical cloud disk to the first agent component.

[0044]

[0043] The embodiment of the present application sets up a proxy system so that the analysis system will not invade the underlying core system. If the service is unavailable, the core system can also run normally, thereby ensuring the stability of the core system.

[0045] FIG4 is a schematic diagram showing a detailed interaction process based on the analysis system in FIG3 . Referring to FIG4 , the analysis system maintains a state database (equivalent to the heat map address database in the embodiment of the present application, which stores data received and generated by the analysis platform in FIG3 ). The state database is used to store received image creation information and the storage address of the image creation heat map corresponding to the image creation information. The image creation information stored in the state database corresponds to a state flag. The value of the state flag includes a first value and a second value. The first value is used to indicate that the image creation information has not been analyzed, that is, the storage address of the image creation heat map corresponding to the image creation information is not stored in the state database. The second value is used to indicate that the image creation information has been analyzed, that is, the storage address of the image creation heat map corresponding to the image creation information is stored in the state database.

[0045] The analysis system also maintains a loading sequence generation model, which sets two scheduled tasks. The first scheduled task is used to query the status flag value of the image creation information of the historical cloud disk stored in the status database. When the value of the status flag value of the image creation information of any historical cloud disk is found to be the first value, the second scheduled task is triggered to execute. The second scheduled task is used to obtain the block device log corresponding to the historical cloud disk whose status flag value of the image creation information is the first value from the OSS, and then generate a creation heat map corresponding to the historical cloud disk based on the block device log. The creation heat map generated for the historical cloud disk is then stored in the OSS. To facilitate the management of the stored data, the OSS in the embodiment of the present application can maintain two data buckets, namely a first data bucket and a second data bucket. The first data bucket is used to store the block device log of the historical cloud disk; the second data bucket is used to store the creation heat map corresponding to the historical cloud disk.

[0046]

[0046] In response to a creation operation for a target cloud disk, the analysis system obtains the target image creation disk information of the target cloud disk, and based on the target image creation disk information and the status database, obtains the storage address of a reference creation disk heat map corresponding to the first image creation disk information whose similarity with the target image creation disk information is higher than a preset threshold. Based on the storage address of the reference creation disk heat map, the reference creation disk heat map is obtained, and then the reference creation disk heat map is output to the core system, so that the EBS backend can load each sub-block in the block device corresponding to the target image file that the front end needs to access from the OSS of the core system according to the loading order indicated by the reference creation disk heat map.

[0047]

[0047] When designing the above analysis system, the process of obtaining the image creation information, the process of predicting the loading order corresponding to the target cloud disk, and the process of the loading order recommended by the core system application are executed asynchronously. Each execution process is decoupled from each other, ensuring the smooth operation of the system.

[0048]

[0048] The method provided in the embodiment of the present application can be used to analyze the disk creation behavior of different image files at the block level, and construct a BPHMap model based on the differences and similarities of the operating systems in different image files. Then, based on the recommended order predicted by the BPHMap model, each sub-block in the block device corresponding to each image file is loaded, solving the problem that the loading order cannot be known in the case of cold start due to the lack of corresponding image snapshots.

[0049]

[0049] In addition, the embodiment of the present application constructs an offline asynchronous analysis link. When a mirror snapshot identifier is stored in the heat map address database, the storage address of the disk creation heat map corresponding to the mirror snapshot identifier is obtained based on the stored mirror snapshot identifier, and then the corresponding disk creation heat map is obtained based on the storage address, and then the sub-blocks in the block device corresponding to the image file are loaded based on the access order indicated by the disk creation heat map. When a mirror snapshot identifier is stored in the heat map address database, the disk creation heat map corresponding to the historical cloud disk with a high similarity in access mode during the disk creation process of the image file is obtained based on the file information of the image file, and the sub-blocks in the block device are loaded based on the loading order indicated by the obtained disk creation heat map. After the cloud disk is created, the block device log of the cloud disk during the actual creation process is obtained based on the cloud disk creation information of the cloud disk. Then, based on the obtained block device log, a corresponding disk creation heat map is generated for the cloud disk, and the image snapshot identifier corresponding to the cloud disk and the storage address of the generated disk creation heat map on the OSS are stored in the heat map address database. This enables adaptive enhancement of the heat map address database.

[0050]

[0050] In addition, the recommended format for the loading order in the embodiment of the present application retains a certain degree of flexibility, and the granularity of dividing the image file corresponding to the block device has a certain degree of flexibility. For example, it can be divided into 2M units or 4M units, which satisfies the difference in the granularity of the sub-blocks caused by the different sizes of the image files.

[0051]

[0051] In addition, when network bandwidth resources are limited, the method provided in the embodiment of the present application can effectively reduce the long tail delay and average delay caused by lazy loading reads, reducing the problem of Slow 10 caused by lazy loading reads. In addition, the method provided in the embodiment of the present application can find the similarities and differences in access modes when different image files are created on cloud disks, providing guidance for optimizing image creation and loading in more scenarios.

[0052]

[0052] The embodiment of the present application provides a method for loading an image file. Referring to FIG5 , the method flow provided by the embodiment of the present application includes steps 501 to 503.

[0053]

[0053] 501. Based on the target image creation disk information and the heat map address database of the target cloud disk to be created, obtain the storage address of the reference creation disk heat map.

[0054]

[0054] The target image creation information includes an image snapshot identifier and file information of the target image file. The image snapshot identifier is a unique identifier generated for the target image file to be loaded by the target cloud disk during the target cloud disk creation process. If the image files to be loaded by two cloud disks are the same, the image snapshot identifiers corresponding to the two cloud disks are the same. The file information includes the type and version number of the operating system of the target image file. The operating system type of the image file includes official types and custom images. Accordingly, the image files include official image files and custom image files. Official image files refer to image files that are officially released and have not been modified by the user; custom image files are official image files that have been modified by the user.

[0055]

[0055] The heat map address database is used to store the corresponding relationship between the first mirror image creation information of the created historical cloud disk and the storage address of the disk creation heat map. The disk creation heat map is used to indicate the access order of each sub-block in the block device corresponding to the image file during the historical cloud disk creation process. When creating the heat map address database, the following steps 5011 to 5015 can be adopted.

[0056]

[0056] 5011. Obtain first image creation information of multiple historical cloud disks.

[0057]

[0057] Wherein, the historical cloud disk is a cloud disk that has been created, and the block device log generated by the historical cloud disk during the creation process can be obtained. The embodiment of the present application can obtain the first image creation disk information of the historical cloud disk from multiple databases or analysis platforms. When the first image creation disk information of each historical cloud disk is obtained, the obtained first image creation disk information of the historical cloud disk can be stored in a state database, which is also a heat map address database. Furthermore, before the first image creation disk information of the historical cloud disk is stored in the state database, it will also be queried whether the state database stores the first image creation disk information of the historical cloud disk. If it has been stored, it does not need to be stored again.

[0058]

[0058] 5012. For any historical cloud disk, if the value of the status identification bit corresponding to the historical cloud disk is the first value, obtain the block device log corresponding to the first mirror creation information of the historical cloud disk.

[0059]

[0059] The application embodiment sets two timed tasks for the loading sequence generation model, namely the first timed task and the second timed task. The first timed task is used to query the status identification bit corresponding to the first mirror creation disk information of each historical cloud disk stored in the status database. For any historical cloud disk, if the value of the status identification bit corresponding to the historical cloud disk is the first value, it means that the block device log corresponding to the historical cloud disk has not been analyzed. Therefore, it is necessary to obtain the block device log corresponding to the first mirror creation disk information of the historical cloud disk. The block device log is used to record the access information of each sub-block of the corresponding block device during the creation process of the historical cloud disk. The access information includes the op operation type (such as read operation and write operation), the offset of the sub-block address offset, the length of the sub-block length, the access time time, etc.

[0060]

[0060] 5013. By processing the block device log, a heat map of the disk creation corresponding to the historical cloud disk is generated.

[0061]

[0061] Specifically, by processing the block device log, generating a heat map corresponding to the historical cloud disk creation, which may include steps 50131 to 50132.

[0062]

[0062] 5013 K constructs an access feature matrix corresponding to the historical cloud disk based on the access information of each sub-block during the historical cloud disk creation process recorded in the block device log.

[0063]

[0063] Based on the access information of each sub-block in the historical cloud disk construction process recorded in the block device log, by statistically analyzing the access information of each sub-block, a row of feature vectors corresponding to each sub-block can be obtained. The feature vector includes the first access time > the last access time > the address addr of the sub-block, the access frequency > the size group_size of the sub-block, etc. Then, the feature vectors corresponding to each sub-block are combined into an access feature matrix.

[0064]

[0064] 50132. Sort the feature vectors in the access feature matrix according to access time and access frequency to obtain a historical cloud disk creation heat map.

[0065]

[0065] After obtaining the access feature matrix, the eigenvectors in the access feature matrix can be sorted in the order of first access time from earliest to latest. If the first access time of two sub-blocks is the same, the two sub-blocks are sorted in the order of access frequency from high to low. By sorting the eigenvectors in the access feature matrix, a heat map of historical cloud disk creation can be obtained, which can be represented by HeatMap.

[0066]

[0066] FIG6 shows a process of processing the block device log of the historical cloud disk to generate a disk creation heat map corresponding to the historical cloud disk. Referring to FIG6, the block device log of the historical cloud disk includes multiple access information, and the access information includes the op operation type, the offset of the sub-block address offset, the length of the sub-block length, the access time time, etc. By performing statistics on the multiple access information, the disk creation heat map corresponding to the historical cloud disk can be obtained. The disk creation heat map is an access feature matrix composed of multiple rows of feature vectors, and each row of the feature vector includes the first access time first access time> the last access time last access time, the address addr of the sub-block, the access frequency frequency> the size group_size of the sub-block, etc.

[0067]

[0067] In an embodiment of the present application, block device addresses are divided into M groups according to a certain group size, and the access frequency, first access time, and last access time of each group are counted to form an M*5 matrix vector, which is then sorted according to first access time and frequency. The access feature matrix obtained has addr from the first row to the last row as the optimal loading order.

[0068]

[0068] 5014. Store the disk creation heat map and obtain the storage address of the disk creation heat map.

[0069]

[0069] After generating a disk creation heat map for a historical cloud disk, the embodiment of the present application also stores the generated disk creation heat map in a second data bucket of the OSS and obtains the storage address of the disk creation heat map.

[0070]

[0070] 5015. The first mirror image creation information of the historical cloud disk and the storage address of the creation heat map thereof are stored in the heat map address database.

[0071]

[0071] Based on the storage address of the first mirror disk creation information and its creation heat map of the historical cloud disk, it can be stored in the heat map address database accordingly.

[0072]

[0072] Further, after storing the first mirror creation information of the historical cloud disk and the storage address of its creation heat map in the heat map address database, the embodiment of the present application also changes the value of the status identification bit corresponding to the historical cloud disk to a second value to indicate that the block device log corresponding to the historical cloud disk has been analyzed.

[0073]

[0073] In an embodiment of the present application, in order to facilitate the management of the data stored in the heat map address database, the heat map address database can be divided into a first sub-database, a second sub-database and a third sub-database. The first sub-database is used to store the correspondence between the image snapshot identifier of the historical cloud disk and the storage address of the disk creation heat map, the second sub-database is used to store the correspondence between different version numbers of the official image file and the storage address of the disk creation heat map, and the third sub-database is used to store the correspondence between different types of custom image files and the storage address of the disk creation heat map, so that different confidence levels of matching can be performed according to the data in different sub-databases.

[0074] In an embodiment of the present application, when obtaining the storage address of a reference disk creation heat map based on the target image creation disk information and the heat map address database of the target cloud disk to be created, a query can be made as to whether a mirror snapshot identifier identical to the target image snapshot identifier is stored in the first sub-database. If a mirror snapshot identifier identical to the target image snapshot identifier is stored in the first sub-database, the storage address of the reference disk creation heat map is obtained from the first sub-database based on the mirror snapshot identifier identical to the target image snapshot identifier. The reference disk creation heat map is the storage address of a disk creation heat map corresponding to the first image creation disk information whose similarity to the target image creation disk information exceeds a preset threshold.

[0075]

[0075] Furthermore, when the first sub-database does not store an image snapshot identifier identical to the target image snapshot identifier, the target file information of the target image file can be obtained based on the target image creation information. Furthermore, based on the target file information and the heat map address database, second image creation information can be obtained. Then, based on the second image creation information, the storage address of the reference creation heat map can be obtained from the heat map address database. The second image creation information can be first image creation information whose similarity to the target image creation information exceeds a preset threshold. The preset threshold can be set by a technician. Optionally, to improve creation accuracy, the second image creation information with the highest similarity to the target image creation information can be selected from among the second image creation information whose similarity to the target image creation information exceeds a preset threshold.

[0076]

[0076] Specifically, when obtaining the second image creation information based on the target file information and the heat map address database, the target file information indicating the type of the target image file can be obtained. When the target file information indicates that the target image file is an official image file, the version number of the official image file that is closest to the version number of the target image file is obtained from the second sub-database as the second image creation information. When the target file information indicates that the target image file is a custom image file, a target creation feature vector corresponding to the target image file is constructed based on the target image creation information. The target creation feature vector may include the operating system type, version number, block device size, block device type, etc. of the target image file, thereby forming a 1*N vector, where N represents the category information of the image file. Based on the image creation information corresponding to different types of custom image files, creation feature vectors corresponding to different types of custom image files are constructed. Then, the similarity between the target creation feature vector and the creation feature vectors corresponding to different types of custom image files is calculated. Finally, the type of the custom image file with the greatest similarity is used as the second image creation information.

[0077]

[0077] Using the method provided in an embodiment of the present application, when a mirror snapshot identifier identical to the mirror snapshot identifier of the target image file is matched, a disk creation heat map address corresponding to the matched mirror snapshot identifier is obtained. If a mirror snapshot identifier identical to the mirror snapshot identifier of the target image file is not matched, and the target image file is an official image file, the official image file with the closest version number to the target image file is obtained. Generally, for the same operating system type, the closer the version number, the relatively fewer the modified parts, and the higher the disk creation task similarity. If a mirror snapshot identifier identical to the mirror snapshot identifier of the target image file is not matched, and the target image file is a custom image file, the embodiment of the present application solves the disk creation cold start problem by constructing a disk creation feature vector and calculating the similarity between the disk creation feature vector corresponding to the target image file and the disk creation feature vector corresponding to the stored custom image file.

[0078]

[0078] Furthermore, since the accuracy of the reference creation heat map obtained based on the data stored in different sub-databases is different, when the storage address of the reference creation heat map is obtained, different confidence levels can be generated for the storage addresses of the reference creation heat map obtained from different sub-databases, and the generated confidence levels can be output together.

[0079]

[0079] 502. Based on the storage address of the reference disk creation heat map, obtain the reference disk creation heat map.

[0080]

[0080] Based on the storage address of the reference disk creation heat map, the reference disk creation heat map can be obtained from the OSS, and the reference disk creation heat map indicates the access order of each sub-block.

[0081]

[0081] 503. Load each sub-block of the target block device according to the access order indicated by the reference disk creation heat map.

[0082]

[0082] The target block device is a block device corresponding to the target image file that needs to be loaded during the target cloud disk creation process. By adopting the access order indicated by the reference disk creation heat map, each sub-block in the target block device is loaded, thereby shortening the delay generated by the EBS backend loading the target block device to a certain extent.

[0083]

[0083] In an embodiment of the present application, when the first sub-database does not store a mirror snapshot identifier that is the same as the target mirror snapshot identifier, after the target cloud disk is created, the actual block device log of the target cloud disk can also be obtained, and then based on the actual block device log, the actual disk creation heat map of the target cloud disk is generated, and then the actual disk creation heat map is stored, and the storage address of the actual disk creation heat map is obtained, and then the target mirror creation information and the storage address of the actual disk creation heat map are stored in the heat map address database, thereby realizing dynamic expansion of the heat map address database.

[0084]

[0084] FIG7 shows a process for creating a target cloud disk in an embodiment of the present application. Referring to FIG7, when a target cloud disk creation operation is detected, target image creation information of the target cloud disk is obtained. The target image creation information includes a target image snapshot identifier. Based on the target image snapshot identifier, the image snapshot library (first sub-database) is queried to determine whether the target image snapshot identifier exists. If so, the storage address of a creation heat map corresponding to the target image snapshot identifier is obtained. The confidence level of the access sequence of each sub-block in the target block device corresponding to the target image file indicated by the creation heat map is 100%. If not, the type of the target image file is analyzed. If the target image file is an official image file, the second image creation information with a version number closest to the version number of the target image file is obtained from the official image template (second database). Then, the storage address of a reference creation heat map corresponding to the second image creation information is obtained. The confidence level of the access sequence of each sub-block in the target block device corresponding to the target image file indicated by the reference creation heat map is 100%. If not, If the target image file is a custom image file, a target disk creation feature vector is constructed for the target image file. Based on the image creation information corresponding to different types of custom image files, disk creation feature vectors are constructed for different types of custom image files. The similarity between the target disk creation feature vector and the disk creation feature vectors corresponding to different types of custom image files is calculated. Finally, the type of the custom image file with the greatest similarity is used as the second image disk creation information. The storage address of a reference disk creation heat map corresponding to the second image disk creation information is then obtained. The access order of each sub-block in the target block device corresponding to the target image file, as indicated by the reference disk creation heat map, has a confidence level of 10%. Based on the obtained storage address of the reference disk creation heat map, the reference disk creation heat map is retrieved from the OSS. Based on the access order indicated by the reference disk creation heat map, each sub-block of the target block device is loaded to complete the creation of the target cloud disk. Furthermore, if the target image snapshot identifier does not exist in the image snapshot library, after the target cloud disk is created, an actual disk creation heat map of the target cloud disk is generated based on the actual block device log of the target cloud disk, and then the actual disk creation heat map is stored, and the storage address of the actual disk creation heat map is obtained. Then, the target image creation information and the storage address of the actual disk creation heat map are stored in the heat map address database.

[0085] The embodiments of the present application analyze the creation behavior of different image files at the block level and recommend an optimal loading order for each image file based on the differences in operating systems within the different image files, thereby resolving the cold start issue. Furthermore, an offline asynchronous analysis link is constructed to automatically recommend a preloading order for image creation, while also enabling adaptive enhancement of the heat map address database. In summary, whenever an image creation occurs, this method can be used to prefetch the address space that will be accessed by the block device and then preload it. This significantly reduces loading delays caused by resource limitations and provides guidance for accelerating image creation loading in a wider range of scenarios, based on the differences in access patterns between different image creations.

[0086]

[0086] All the above optional technical solutions can be combined in any way to form optional embodiments of the present application, and will not be described in detail here.

[0087]

[0087] Please refer to FIG8 , which shows a schematic structural diagram of an image file loading device provided in an embodiment of the present application. The device can be implemented through software, hardware, or a combination of both, and becomes all or part of an electronic device. The device includes a first acquisition module 801, a second acquisition module 802, and a loading module 803.

[0088]

[0088] A first acquisition module 801 is configured to acquire a storage address of a reference disk creation heat map based on target image disk creation information of a target cloud disk to be created and a heat map address database. The heat map address database is configured to store a correspondence between first image disk creation information of a previously created historical cloud disk and the storage address of its disk creation heat map. The disk creation heat map is configured to indicate an access order of sub-blocks in a block device corresponding to an image file during a historical cloud disk creation process. The reference disk creation heat map is a disk creation heat map corresponding to first image disk creation information having a similarity with the target image disk creation information that exceeds a preset threshold.

[0089]

[0089] The second acquisition module 802 is used to acquire the reference disk creation heat map based on the storage address of the reference disk creation heat map.

[0090]

[0090] The loading module 803 is used to load each sub-block of the target block device according to the access order indicated by the reference disk creation heat map. The target block device is the block device corresponding to the target image file that needs to be loaded during the target cloud disk creation process.

[0091]

[0091] In another embodiment of the present application, the device also includes: a third acquisition module, used to obtain the first mirror creation disk information of multiple historical cloud disks; a fourth acquisition module, used to obtain the block device log corresponding to the first mirror creation disk information of any historical cloud disk if the value of the status identification bit corresponding to the historical cloud disk is the first value, and the block device log is used to record the access information of each sub-block of the corresponding block device during the creation process of the historical cloud disk; a first generation module, used to generate a creation disk heat map corresponding to the historical cloud disk by processing the block device log; a first storage module, used to store the creation disk heat map; a fifth acquisition module, used to obtain the storage address of the creation disk heat map; a second storage module, used to store the first mirror creation disk information of the historical cloud disk and the storage address of its creation disk heat map in the heat map address database.

[0092]

[0092] In another embodiment of the present application, a generation module is used to construct an access feature matrix corresponding to the historical cloud disk based on the access information of each sub-block during the historical cloud disk creation process recorded in the block device log, and each sub-block corresponds to a row of feature vectors in the access feature matrix; the feature vectors in the access feature matrix are sorted according to the access time and access frequency to obtain a heat map of the historical cloud disk creation.

[0093]

[0093] In another embodiment of the present application, the device also includes: a changing module for changing the value of the status identification bit corresponding to the historical cloud disk to a second value.

[0094]

[0094] In another embodiment of the present application, the target image creation information includes a target image snapshot identifier, the heat map address database includes a first sub-database, the first sub-database is used to store the correspondence between the image snapshot identifier of the historical cloud disk and the storage address of the creation heat map, and the first acquisition module is used to query whether the first sub-database stores a mirror snapshot identifier that is identical to the target image snapshot identifier; when the first sub-database stores a mirror snapshot identifier that is identical to the target image snapshot identifier, then based on the mirror snapshot identifier that is identical to the target image snapshot identifier, the storage address of the reference creation heat map is obtained from the first sub-database.

[0095]

[0095] In another embodiment of the present application, the device further includes: a sixth acquisition module, configured to, when the first sub-database does not store a mirror snapshot identifier identical to the target mirror snapshot identifier, acquire second mirror disk creation information based on the target file information and the heat map address database, wherein the second mirror disk creation information is first mirror disk creation information whose similarity with the target mirror disk creation information is higher than a preset threshold; and a seventh acquisition module, configured to acquire the storage address of the reference disk creation heat map from the heat map address database based on the second mirror disk creation information.

[0096]

[0096] In another embodiment of the present application, the heat map address database includes a second sub-database, and the second sub-database is used to store the correspondence between different version numbers of the official image file and the storage address of the disk creation heat map. The sixth acquisition module is used to obtain the version number of the official image file that is closest to the version number of the target image file from the second sub-database when the target file information indicates that the target image file is an official image file, as the second image creation information.

[0097]

[0097] In another embodiment of the present application, the heat map address database includes a third sub-database, which is used to store the correspondence between different types of custom image files and the storage addresses of the disk creation heat map. The sixth acquisition module is used to, when the target file information indicates that the target image file is a custom image file, construct a target disk creation feature vector corresponding to the target image file based on the target image disk creation information; construct disk creation feature vectors corresponding to different types of custom image files based on the image disk creation information corresponding to different types of custom image files; calculate the similarity between the target disk creation feature vector and the disk creation feature vectors corresponding to different types of custom image files; and use the type of the custom image file with the greatest similarity as the second image disk creation information.

[0098]

[0098] In another embodiment of the present application, the device further includes: a seventh acquisition module, which is used to obtain the actual block device log of the target cloud disk after the target cloud disk is created; a second generation module, which is used to generate the actual disk creation heat map of the target cloud disk based on the actual block device log; a third storage module, which is used to store the actual disk creation heat map; an eighth acquisition module, which is used to obtain the storage address of the actual disk creation heat map; and a fourth storage module, which is used to store the target image disk creation information and the storage address of the actual disk creation heat map in a heat map address database.

[0099]

[0099] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here.

[0100]

[0100] FIG9 shows a block diagram of an electronic device 900 provided by an exemplary embodiment of the present application. Generally, the electronic device 900 includes: a processor 901 and a memory 902.

[0101]

[0101] The processor 901 may be implemented in at least one hardware form selected from the group consisting of a DSP (Digital Signal Processing), an FPGA (Field-Programmable Gate Array), and a PLA (Programmable Logic Array). The processor 901 may also include a main processor and a coprocessor. The main processor is a processor for processing data in an awake state; the coprocessor is a low-power processor for processing data in a standby state. In some embodiments, the processor 901 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing content to be displayed on a display screen. In some embodiments, the processor 901 may also include an artificial intelligence processor for processing computational operations related to machine learning.

[0102]

[0102] The memory 902 may include one or more computer-readable storage media. The computer-readable storage media may be non-transitory computer-readable storage media. For example, the non-transitory computer-readable storage media may be a CD-ROM (Compact Disc Read-Only Memory), a ROM, a RAM (Random Access Memory), a magnetic tape, a floppy disk, an optical data storage device, etc. The computer-readable storage medium stores at least one computer program. When the at least one computer program is executed, the method for loading an image file can be implemented.

[0103]

[0103] Of course, the electronic device may also include other components, such as input / output interfaces, communication components, etc. The input / output interface provides an interface between the processor and a peripheral interface module, and the peripheral interface module may be an output device, an input device, etc. The communication component is configured to facilitate wired or wireless communication between the electronic device and other devices.

[0104]

[0104] Those skilled in the art will appreciate that the structure shown in FIG9 does not limit the electronic device 900, and the electronic device 900 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0105]

[0105] An embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium stores at least one computer program, and when the at least one computer program is executed by a processor, the above-mentioned image file loading method can be implemented.

[0106]

[0106] An embodiment of the present application provides a computer program product, which includes a computer program. When the computer program is executed by a processor, it can implement the above-mentioned image file loading method.

[0107]

[0107] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some of the technical features therein with equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application.

Claims

Claims 1. A method for loading an image file, comprising: Obtaining the storage address of a reference disk creation heat map based on the target image creation disk information of the target cloud disk to be created and a heat map address database. The heat map address database is used to store the correspondence between the first image creation disk information of a previously created historical cloud disk and the storage address of its creation heat map. The creation heat map is used to indicate the order in which sub-blocks in the block device corresponding to the image file are accessed during the creation of the historical cloud disk. The reference disk creation heat map is a creation heat map corresponding to the first image creation disk information whose similarity with the target image creation disk information exceeds a preset threshold. Based on the storage address of the reference disk creation heat map, obtaining the reference disk creation heat map; According to the access order indicated by the reference disk creation heat map, each sub-block of the target block device is loaded, and the target block device is a block device corresponding to the target image file required to be loaded during the target cloud disk creation process.

2. The method according to claim 1, wherein: Before obtaining the storage address of the reference disk creation heat map based on the target image disk creation information and heat map address database of the target cloud disk to be created, the method further includes: obtaining the first image disk creation information of multiple historical cloud disks; for any historical cloud disk, if the value of the status identification bit corresponding to the historical cloud disk is the first value, obtaining the block device log corresponding to the first image disk creation information of the historical cloud disk, the block device log being used to record access information of each sub-block of the corresponding block device during the creation process of the historical cloud disk; generating a disk creation heat map corresponding to the historical cloud disk by processing the block device log; storing the disk creation heat map and obtaining the storage address of the disk creation heat map; storing the first image disk creation information of the historical cloud disk and the storage address of its disk creation heat map in the heat map address database.

3. The method according to claim 2, wherein: The process of processing the block device log to generate a heat map for creating a historical cloud disk includes: constructing an access feature matrix corresponding to the historical cloud disk based on the access information of each sub-block during the creation process of the historical cloud disk recorded in the block device log, where each sub-block corresponds to a row of feature vectors in the access feature matrix; and sorting the feature vectors in the access feature matrix according to access time and access frequency to obtain a heat map for creating a historical cloud disk.

4. The method according to claim 2, wherein: After storing the first image creation disk information of the historical cloud disk and the storage address of the creation disk heat map thereof in the heat map address database, the method further includes: changing the value of the status identification bit corresponding to the historical cloud disk to a second value.

5. The method according to claim 1, wherein: The target image creation information includes a target image snapshot The heat map address database includes a first sub-database, and the first sub-database is used to store the correspondence between the mirror snapshot identifier of the historical cloud disk and the storage address of the disk creation heat map. The target mirror creation disk information of the target cloud disk to be created and the heat map address database are used to obtain the storage address of the reference disk creation heat map, including: querying whether the first sub-database stores a mirror snapshot identifier that is identical to the target mirror snapshot identifier; when the first sub-database stores a mirror snapshot identifier that is identical to the target mirror snapshot identifier, obtaining the storage address of the reference disk creation heat map from the first sub-database based on the mirror snapshot identifier that is identical to the target mirror snapshot identifier.

6. The method according to claim 5, further comprising: When the first sub-database does not store the same image snapshot identifier as the target image snapshot identifier, obtaining target file information of the target image file based on the target image creation information; Based on the target file information and the heat map address database, obtaining second image creation information, where the second image creation information is first image creation information having a similarity with the target image creation information that is higher than a preset threshold; Based on the second image creation information, the storage address of the reference creation heat map is obtained from the heat map address database.

7. The method according to claim 6, wherein: The heat map address database includes a second sub-database, and the second sub-database is used to store the correspondence between different version numbers of official image files and the storage addresses of the disk creation heat map. The obtaining of the second image disk creation information based on the target file information and the heat map address database includes: when the target file information indicates that the target image file is an official image file, obtaining from the second sub-database the version number of the official image file that is closest to the version number of the target image file, and using the version number as the second image disk creation information.

8. The method according to claim 6, wherein: The heat map address database includes a third sub-database, the third sub-database being used to store correspondences between different types of custom image files and storage addresses of a disk creation heat map. The obtaining of second image disk creation information based on the target file information and the heat map address database includes: when the target file information indicates that the target image file is a custom image file, constructing a target disk creation feature vector corresponding to the target image file based on the target image disk creation information; calculating similarities between the target disk creation feature vector and disk creation feature vectors corresponding to different types of custom image files; and selecting the type of the custom image file having the greatest similarity as the second image disk creation information.

9. The method according to any one of claims 6 to 8, further comprising: After the target cloud disk is created, the actual block device log of the target cloud disk is obtained; Generate a heat map of actual disk creation of the target cloud disk based on the actual block device log; Storing the actual disk creation heat map and obtaining the storage address of the actual disk creation heat map; The target image creation information and the storage address of the actual creation heat map are stored in the heat map address database.

10. A device for loading an image file, comprising: A first acquisition module is configured to acquire the storage address of a reference disk creation heat map based on the target image creation disk information of the target cloud disk to be created and a heat map address database. The heat map address database is configured to store the correspondence between the first image creation disk information of previously created historical cloud disks and the storage address of their creation heat maps. The creation heat map indicates the order in which sub-blocks in the block device corresponding to the image file are accessed during the creation of the historical cloud disk. The reference disk creation heat map is a creation heat map corresponding to the first image creation disk information whose similarity with the target image creation disk information exceeds a preset threshold. a second acquiring module, configured to acquire the reference disk creation heat map based on a storage address of the reference disk creation heat map; The loading module is configured to load each sub-block of a target block device according to the access order indicated by the reference disk creation heat map, where the target block device is a block device corresponding to a target image file required to be loaded during the target cloud disk creation process.

11. An electronic device comprising a processor and a memory; wherein: The memory stores at least one program code; the at least one program code is used to be called and executed by the processor to implement the image file loading method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing at least one computer program, wherein: When the at least one computer program is executed by a processor, it is possible to implement the image file loading method according to any one of claims 1 to 9.

13. A computer program product comprising a computer program, wherein: When the computer program is executed by a processor, it can implement the image file loading method according to any one of claims 1 to 9.

Images