Predictive provisioning of remotely stored files

Abstract

A computer system that can access a remote file stored on a remote system can predict that a portion of the remote file may be necessary. The computer system can download the portion of the remote file to a local file and update the metadata of the local file to reflect the downloaded portion.

Description

Technical Field

[0001] The present invention relates to file storage, and more particularly, to predictively downloading remotely stored files to a local file system. Background Art

[0002] Cloud storage is becoming more and more popular in both business and personal settings. Using a cloud sync storage application, when a user installs the cloud sync storage application on a new computer, the user's cloud stored files and / or data can be automatically downloaded to the local storage.

[0003] However, automatically downloading every file stored in the user's cloud may unnecessarily consume bandwidth and local storage space. For example, if the user's cloud includes multiple important documents and several terabytes (TB) of video files, automatically downloading all of the files may take hours to days (or even longer) depending on the configuration of the user's new local machine and the Internet connection, and may completely fill up the user's new machine's local storage before the important documents are downloaded. Therefore, many cloud-synced storage applications implement various methods to prevent unnecessary downloads of large amounts of data, such as providing a list of files and downloading files only when a read instruction is received (such as when a user attempts to open a file that is currently only in the cloud, i.e., when no local copy currently exists).

[0004] This also enables the cloud system to act as "remote storage" - a user can upload a file to the cloud and delete the local copy of the file, freeing up storage space on the user's local system. If the user wishes to utilize the file again, the cloud sync storage application initiates a "download" of the file back to the local storage, enabling it to be used.

[0005] However, many types of read instructions do not require access to the entire file. For example, many file explorer systems automatically generate a thumbnail image of a video file by using only a predetermined frame of the video (e.g., the fifth frame). This single frame can be read from the video file (via a process initiated by a read request), possibly compressed and / or resized, and then displayed as a thumbnail, at which point no further information about the file may be required. Therefore, a read request seeking access to a large video file (e.g., a multi-GB file) may actually only require reading a few kilobytes (kB).

[0006] Since conventional systems can respond to a read request targeting a file by initiating a download of the entire file, they may waste a large amount of computing resources. Continuing with the above example, conventional systems may download an entire video file even if only a single frame of the video is needed at the time. Summary of the invention

[0007] According to one aspect of the present invention, a method is provided, comprising: identifying a remote file stored on a remote computing system; predicting that a predicted portion of the remote file is likely to be subject to a future read request; downloading the predicted portion of the remote file to a local file; and updating metadata of the local file to map the local portion of the local file to the predicted portion of the remote file. The method advantageously improves the efficiency of the remote file storage computing system by predictively downloading portions of the remotely stored file, thereby potentially reducing the amount of data downloaded when requesting the remotely stored file.

[0008] The method may also include: receiving a first read request, wherein: identifying a target based at least on the first read request; and predicting based at least on the first read request. This advantageously improves the efficiency of the remote file storage computing system by downloading a portion of the file predicted to be necessary (rather than the entire file) in response to a request to read a remotely stored file.

[0009] The method may further include: determining a requesting application that initiated the first read request based at least on an application profile database, wherein the prediction is further based at least on the requesting application. This advantageously provides additional prediction accuracy by basing the prediction of the portion to be downloaded on the application requesting the file.

[0010] The method may further comprise: receiving a second read request targeting the target portion of the remote file; and updating the application profile database based at least on the predicted portion and the target portion. This advantageously enables enhanced accuracy in determining the correlation between the identification of the application and the predicted portion.

[0011] Another aspect of the present invention is provided in the form of a computer program product including a computer-readable storage medium having program instructions implemented therewith, the program instructions being executable by a computer to cause the computer to perform any of the above methods. This advantageously improves the efficiency of a remote file storage computing system by predictively downloading portions of remotely stored files, thereby reducing the amount of data downloaded when a remotely stored file is requested.

[0012] Another aspect of the present invention is provided in the form of a system including a memory and a central processing unit (CPU). The CPU can be configured to perform any of the above methods. This advantageously improves the efficiency of the remote file storage computing system by predictively downloading portions of remotely stored files, thereby reducing the amount of data downloaded when requesting remotely stored files.

[0013] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings included in this application are incorporated into the specification and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the description, are used to explain the principles of the present disclosure. The accompanying drawings illustrate certain embodiments only and do not limit the present disclosure. As the following detailed description proceeds, the features and advantages of various embodiments of the claimed subject matter will become apparent when referring to the accompanying drawings, in which like reference numerals indicate like parts, and wherein:

[0015] Figure 1 A method of predictively serving a cloud-stored file in response to a read request targeting one of the cloud-stored files is shown in accordance with several embodiments of the present disclosure;

[0016] Figure 2 A block diagram illustrating an exemplary cloud-stored file and an exemplary locally stored file after downloading an identified portion of the cloud-stored file in accordance with several embodiments of the present disclosure;

[0017] Figure 3 A method of identifying an application responsible for initiating a read request according to several embodiments of the present disclosure is shown;

[0018] Figure 4 A method of predictively provisioning cloud-synchronized files according to several embodiments of the present disclosure is shown;

[0019] Figure 5 Describe a cloud computing environment according to an embodiment of the present disclosure;

[0020] Figure 6 Describes an abstract model layer according to an embodiment of the present disclosure; and

[0021] Figure 7 A high-level block diagram is shown of an example computer system that can be used to implement embodiments of the present disclosure.

[0022] Although the present invention can be modified into various modifications and alternative forms, its details have been shown by way of example in the accompanying drawings and will be described in detail. However, it should be understood that its purpose is not to limit the present invention to the specific embodiments described. On the contrary, the present invention covers all modifications, equivalents and substitutions that fall within the spirit and scope of the present invention. DETAILED DESCRIPTION

[0023] Aspects of the present disclosure relate to systems and methods for predictively serving one or more cloud-stored files. More specific aspects relate to a system that detects a read request, classifies the type of the read request, predicts a portion of a cloud-stored file required to satisfy the read request, and downloads the predicted portion of the cloud-stored file.

[0024] In the present disclosure, reference is made to a "cloud sync storage application." As used herein, a "cloud sync storage application" refers to an application executed on a client computing system ("client device") that enables the client device to upload one or more files to a cloud-based computing system ("the cloud") and download files from the cloud via, for example, the Internet. Once the files are uploaded, the client device may delete the local copy of the uploaded files, but may later download the cloud-stored files back to local storage. This enables the client device to free up local storage space while still having access to the files when needed. As will be appreciated by those of ordinary skill in the art, the systems and methods described herein are not necessarily limited to use with cloud-based systems; general remote file storage may be similarly improved in accordance with the present disclosure.

[0025] Cloud sync storage applications typically provide a list of files stored in the cloud, any of which may also be stored locally. The list is typically implemented as a series of "placeholder" files (typically, the files contain only minimal metadata about the actual file, such as the file name, file size, last modified date, etc.). From the perspective of the user of the client device, the files may be presented as if they were all stored locally, or they may be presented with markings to distinguish between files stored both in the cloud and locally and currently "cloud-only" files. As used herein, the phrase "cloud-only" refers to files stored on the cloud system but not stored on the local storage device (i.e., no local copy of the cloud-only file exists). Cloud-only files may typically be downloaded to local storage on demand via the cloud sync storage application, after which the file will no longer be referred to as "cloud-only." Note that "cloud only" and "placeholder" are not synonymous; as a clarifying example, when considering a 3GB video file stored on the cloud but not on the client device, the "cloud only" file refers to the 3GB video file itself stored on the cloud, while an associated ~1kB "placeholder" file is stored locally on the client device to represent the video file (listing metadata, e.g., its file name, file type, etc.). Thus, if a user of the client device wishes to open the "cloud only" file, the user can double-click the "placeholder" file.

[0026] It is worth noting that while the present disclosure relates broadly to cloud-stored files, some entities may utilize geographically distributed servers located on the end user's premises. These and other similar use cases may be considered "private cloud" implementations. As will be appreciated by those of ordinary skill in the art, the present disclosure may advantageously improve the performance of such systems.

[0027] In this disclosure, reference is made to a "read request". As used herein, a "read request" refers to a category of digital requests, all of which are seeking access to a file. A read request may be initiated by a user action, such as by a user double-clicking an icon representing a file (which may be referred to as an "open" request, which is a type of read request). A read request may also be initiated automatically by an application executing on a client device without direct user input, such as a file explorer program attempting to automatically generate a thumbnail for a video file.

[0028] A read request is typically the first step of an operating system (OS) or file explorer in the process of accessing a file. Notably, the file explorer system does not have to disclose what portion of the file will be needed as part of the initial read request. Instead, in a typical computer system, a read request identifying the associated file is sent to a storage controller. The storage controller may react to the read request by locating the identified file and responding with an acknowledgment to indicate that the requested file is ready to be read. The file explorer may then proceed with a more specific request (i.e., "return bits 300-700 of the file").

[0029] Further, many read requests do not require access to the entire file. For example, continuing with the "thumbnail" example above, many file explorer systems automatically generate a thumbnail image for a video file by using only a predetermined frame of the video (e.g., the fifth frame). This single frame can be read from the video file (via a process initiated by a read request), possibly compressed and / or resized, and then displayed as a thumbnail, at which point no further information about the file may be required. Thus, a read request seeking access to a large video file (e.g., a multi-GB file) may actually only require reading a few kilobytes (kB).

[0030] The cloud sync storage application can monitor for read requests seeking access to cloud-only files. When a conventional cloud sync storage application detects a read request for a cloud-only file, it can respond by initiating a download of the file and then responding to the request with an acknowledgement indicating that the file is ready to be read.

[0031] However, systems and methods consistent with the present disclosure enable determining, predicting, estimating, or otherwise approximating which portions of a file subject to a read request may actually be necessary, and downloading those portions. By downloading only specific portions of a file based on this prediction, systems and methods according to the present disclosure can advantageously save significant resources (e.g., bandwidth, local storage space, processing resources, energy, time, etc.). For example, if the file in question is a large video file, and the read request is determined to require only a single frame, downloading only that frame instead of the entire video file can save several GB of bandwidth.

[0032] In order to determine which parts of a file subject to a read request should be downloaded, aspects of a cloud sync storage application according to the present disclosure may classify the read request based on context information. The context information may include information describing, for example, the application (such as a file explorer, image editor, etc.) and / or the client system (such as runtime, recent operations such as downloading, installing, etc.) that initiated the read request.

[0033] Upon detecting a request to read a cloud-only file (such as a request to read a placeholder file for a corresponding cloud-only file), the cloud sync storage application may utilize contextual information to determine and / or classify the nature of the read request in order to determine which portions of the cloud-only file should be downloaded. The contextual information may include information describing, for example, the application (such as a file explorer, image editor, etc.) and / or the client system (such as runtime, recent operations such as downloading, installing, etc.) that initiated the read request. Examples of contextual information that may be used by the cloud sync storage application include application identification, system configuration information, historical request data, preset / hard-coded patterns, etc.

[0034] For example, a first application may frequently initiate read requests that read only a small, specific portion of a file, while a second application may frequently initiate read requests that require a large portion of a file or even the entire file. These profiles can be developed and monitored over time via an application profiler, as described in further detail below. Based at least in part on information collected from the application profiler, read requests can be classified into one of several categories. A read request initiated by a first application is more likely to require access to only a small, specific portion of a file. In this case, a cloud sync storage application according to the present disclosure may anticipate that the entire file is not necessary to satisfy the request, and may therefore initiate downloading a small, specific portion of the file. On the other hand, a read request initiated by a second application is more likely to require the entire file. Therefore, depending on the application from which the read request originates, the cloud sync storage application can identify and download a specific portion of the file (or, if deemed necessary, the entire file).

[0035] It should be understood that the above advantages and other advantages described herein are exemplary advantages and should not be interpreted as limiting. Embodiments of the present disclosure may include all or some advantages, or none of the advantages, while remaining within the spirit and scope of the present disclosure.

[0036] Figure 1A predictive cloud storage file provisioning method 100 according to several embodiments of the present disclosure is shown. In some embodiments, the method 100 may be performed by hardware, firmware, software executed on a processor, or any combination thereof. For example, the method 100 may be performed by a cloud sync storage application according to the present disclosure. The method 100 includes: at operation 102, detecting a read request for a file seeking (or for) cloud storage. Operation 102 may include, for example, the cloud sync storage application monitoring a request initiated by an application executed on a client device. The cloud sync storage application may maintain a list of cloud-stored files (especially "cloud-only" files) via a local storage of corresponding placeholder files. Further, the cloud sync storage application may be configured with a privilege level that enables it to monitor instructions or requests initiated by relatively low-level applications (such as a file explorer or the operating system itself). If an application (e.g., a file explorer) executing on a client device initiates a read request with a file identifier of a placeholder file corresponding to a cloud-only file, then at operation 102, the cloud sync storage application detects the request. In some embodiments, the cloud sync storage application may be an application, service, or set of functions included in an operating system.

[0037] Method 100 also includes, at operation 104, classifying the read request. Typically, operation 104 includes determining the "real" origin of the read request, and determining the purpose of the read request, in order to approximate which portion(s) of the file in question actually needs to be downloaded in order to satisfy the request. For example, a read request may be classified as an "OPEN" request or an "AUX" request. An OPEN request may be associated with opening the file in question (requiring the download of the entire file), while an AUX request may be associated with any other type of read request. Examples of AUX requests may include a request seeking to generate a thumbnail (a "thumbnail request") or a request seeking file metadata (a "metadata request" seeking information such as size, date, author, etc.). Other classifications are also possible, as well as more specific classifications (e.g., a first type of metadata request may require the author and file size, while a second type of metadata request may require the author, file name, and creation date).

[0038] At operation 104, the read request can be classified based on contextual information. As used herein, "contextual information" can include context of the read request collected from sources other than the read request itself. For example, the contextual information can include metadata for the file, an identification of an application that initiated the read request ("requesting application"), a hardware configuration of the client system from which the request originated, a time / date of the request, previous operations, historical trends, etc. The contextual information can be determined based on, for example, the output of one or more profilers, as described in further detail below.

[0039] The classification may be selected from the list of possible classifications based on a weighted analysis. For example, various contextual information may be associated with different weights, resulting in a list of possible classifications, each with a predicted likelihood. As an example, if the requested cloud-only file is a video file, and the requesting application is a file explorer, the contextual information may weight and / or bias the determination of operation 104 toward a thumbnail request. However, if the requesting application is a media player, a thumbnail request may be considered unlikely.

[0040] In some embodiments, the classification with the highest predicted likelihood is selected. In some embodiments, if there is no "clear winner" (e.g., if no potential classification has a likelihood greater than a threshold or no potential classification has a "margin of victory" large enough compared to other classifications), the system performing method 100 may consider the classification unsuccessful and initiate a download of the entire file (at which point method 100 will end). In some embodiments, when a classification attempt does not produce a clear winner, a classification may be randomly selected. In some embodiments, if a classification attempt does not produce a clear winner, the system performing method 100 may adjust the weights of various types of contextual information and re-evaluate.

[0041] Method 100 also includes, at operation 106, identifying and / or predicting necessary file segments. Operation 106 may include, for example, determining a bit range of a cloud-only file that may be required by the requesting application. For example, in some embodiments, the system performing method 100 may determine that the first 300 kB are most likely to be requested.

[0042] In some embodiments, the determination made at operation 106 may be based on the classification of the detected read request determined at operation 104. In some embodiments, a system performing method 100 may consider contextual information, such as described above, as part of operation 106. For example, if the read request is classified as a thumbnail request, operation 106 may include analyzing metadata of the file to determine the location of a particular keyframe. On the other hand, in some embodiments, the prediction at operation 106 is based solely on the classification of the request. For example, a system performing method 100 may be "hard coded" to identify the required portion of the file as 3,000 to 12,000 bits for all thumbnail requests.

[0043] Because some requests may seek multiple, non-contiguous portions of a file, multiple ranges may be identified at operation 106. For example, a metadata request may seek the author name and file name of a file. Files may store metadata in a particular order; for example, the author of a file may be stored at positions 13,384 to 13,415, the creation date of a file may be stored at positions 13,416 to 13,423, and the file name of a file may be stored at positions 13,424 to 13,511. Thus, to satisfy the example metadata request, operation 106 may include identifying positions 13,384 to 13,415 and positions 13,424 to 13,511.

[0044] Once the predicted portion of the file is identified, method 100 further includes, at operation 108, downloading the predicted portion. This may include, for example, sending a download request for the data identified in operation 106 to a cloud system and downloading the identified data. The downloaded data may be saved to local storage, as will be described below with reference to Figure 2 In some embodiments, the "placeholder" files in the directory may be replaced and / or modified based on the downloaded data. In some embodiments, the downloaded data may be stored in a separate cache and the existing placeholder files may not be modified.

[0045] In some embodiments, additional margins may be added to the identified portions. In other words, operation 108 may include downloading additional data outside the bit range predicted to be necessary at operation 106. Although this may consume additional resources, the favorable improvement in fault tolerance may outweigh the cost (e.g., if the prediction is incorrect, the data actually required may still be downloaded). Referring to the previous example in which 13,384 to 13,415 bits and 13,424 to 13,511 bits are identified as needed, operation 108 may, for example, add an 8-bit margin to one or more ends of the bit range. Therefore, the system can download, for example, 13,376 to 13,415 bits and 13,424 to 13,511 bits (downloading 8 additional bits located "before" the predicted range). The system can also download 13,384 to 13,519 bits (downloading 8 bits between the two ranges and 8 bits at the "end", a total of 16 additional bits).

[0046] In some embodiments, the margin may be predetermined. For example, in some embodiments, a system performing method 100 may always add a 5kB margin to the download at each end of each range (where possible). In some embodiments, the margin may be selected based on various parameters, such as read request classification and / or contextual information. For example, the system may download 3kB "after" the identified range required to satisfy a thumbnail request, but may download 1kB and 15kB "before" and "after" the range predicted to be necessary to satisfy a metadata request, respectively. Other bases for margin selection are possible, as will be appreciated by one of ordinary skill in the art.

[0047] Operation 108 may also include tracking, mapping, or otherwise recording which bits have been downloaded. As a clarifying example, if bits 235,016 to 235,023 and bits 235,032 to 235,039 have been downloaded, these bits may be saved as bits 1-16 in local storage, but operation 108 may additionally include recording that local bit 1 corresponds to "actual" bit 235,016, local bit 12 corresponds to actual bit 235,035, etc. This may advantageously enable a system performing method 100 to return the correct requested bit, as a read request and subsequent more specific bit requests may "assume" that the entire file is being accessed.

[0048] In some embodiments, operation 108 may also include throttling or otherwise modifying the download rate based on current network configuration and usage. In some embodiments, operation 108 may include checking whether the prediction data has been downloaded and stored locally; if so, the system performing method 100 may not perform the download.

[0049] In the event that the data is downloaded (or located), method 100 further includes: continuing at operation 110 as if the complete file is available. Operation 110 may include, for example, sending a confirmation signal to a file explorer application and / or an operating system. The confirmation may be configured to "mimic" a typical confirmation that the requested file has been located and is ready to be read (such as a confirmation sent by, for example, a storage controller).

[0050] Thus, the application that sent the read request can proceed as if the complete file is available, and can respond to the confirmation with a second read request containing more specific read instructions (such as "seek 5,000 bits, then return the next 2,500 bits"). In essence, the prediction made at operation 106 is an attempt to predictively pre-fetch the data that will be accessed by these more specific read instructions. If the prediction is accurate (or has sufficient margin), the system executing method 100 is able to return the requested bits without performing any additional downloads. Note that continuing with the "seek 5,000 bits, then return the next 2,500 bits" example, if the "local relative actual" position of the bits is tracked as part of operation 108, the system executing method 100 will not need to actually execute the "seek 5,000 bits" instruction. Instead, the system can confirm that bits 5,001-7,500 have been downloaded, and if so, proceed to return them. Thus, the system can satisfy the read request without downloading the entire cloud-only file.

[0051] If the system determines that the requested bits have not been downloaded (e.g., if the prediction of operation 106 is incorrect), one of several different actions may be taken. For example, in some embodiments, the system may simply download the entire file. In some embodiments, the system may download specific requested bits. Figure 4 ) further describes these and other responses to incorrect predictions in detail.

[0052] Figure 2 A block diagram of an example cloud-stored file 200 and an example locally stored file 220 after downloading identified portions 202 and 208 of the cloud-stored file 200 is shown in accordance with several embodiments of the present disclosure. Cloud file 200 includes a plurality of bits (i.e., "0" or "1"). At a given point in time, cloud file 200 may be a cloud-only file because a complete local copy of file 200 does not exist. The boxes depicted below dividing line 210 (i.e., boxes 222, 228, and 230) represent bits of locally stored file 220. Arrows 212 and 218 represent download operations, such as those initiated by a cloud sync storage application. Although two separate arrows 212 and 218 are shown, it should be understood that they do not necessarily represent two sequential downloads. For example, the downloaded data referenced by those arrows 212 and 218 may be downloaded in a single download operation, or may be downloaded in multiple simultaneous download operations.

[0053] Various bit ranges of local file 220 may contain the same data as compared to corresponding bit ranges of cloud file 200. For example, first local bit range 222 as a result of download 212 may be the same as first cloud bit range 202, and second local bit range 228 as a result of download 218 may be the same as second cloud bit range 208. As used herein, "same" refers to the logical state of the bits themselves; for example, ranges 202 and 222 may both contain the same bits (e.g., both ranges may be 1000101011010010, etc.).

[0054] Not all bits of the local file 220 need to be copied from the cloud file 200; for example, the local file 220 may also include metadata, such as information that maps which bits of the local file 220 correspond to which bits of the cloud file 200. Figure 2 , such metadata is depicted as scope 230. Metadata 230 (including a mapping of local-to-cloud locations) may be generated (e.g., by a cloud sync storage application) when a download such as 212 or 218 is performed. Metadata 230 may be updated based on further downloads, deletions, and the like.

[0055] The local file 220 may be stored on a local storage device, such as a hard disk drive (HDD), a solid state drive (SSD), volatile memory, etc. Further, in some embodiments, the local file 220 may include additional tags and / or metadata, depending on the nature of the cloud file 200 and the downloaded segments 222 , 228 .

[0056] For example, in at least one embodiment, the local system on which the local file 222 is stored utilizes a "thumbnail database". As used herein, a "thumbnail database" refers to a typical hidden file in a directory that contains thumbnail images of the files in the directory to enable quick thumbnail generation. If a thumbnail database does not exist in the directory on the example local system, the system can generate one (e.g., by pulling frames from video files in the directory, generating small copies of image files in the directory, etc.), and save the new thumbnail database in the directory for future use. In this example embodiment, the cloud file 200 can be a video file, and the local bit 222 can include a thumbnail image. The local file 220 can include metadata that identifies the local file 220 as a typical thumbnail database. Therefore, if a file explorer application executed on the system attempts to access the directory, the application will detect the local file 220 and will use the local bit 222 as a thumbnail of a placeholder file representing the cloud file 200. Since the local file 220 may be generated outside of a read request, this enables the cloud sync storage application to generate the thumbnail database before the file explorer application accesses the directory.

[0057] In some embodiments, the local file 220 may include tags and / or metadata (such as in range 230) to make the local file 220 appear to the user and / or the file system as if it were the complete cloud file 200. Thus, if an application requests bit ranges 202 and / or 208 ("believing" that it is attempting to read those bits from a complete local copy of the cloud file 200), the cloud sync storage application may be able to satisfy the read request without downloading the entire cloud file 200.

[0058] Depending on the nature of cloud file 200, different bit ranges may store different data; for example, segment 202 (bits 13,000 to 13,511) of file 200 may store the name of the author of file 200, segment 204 (bits 13,512 to 13,767) of file 200 may store the creation date of file 200, segment 206 (bits 13,768 to 14,023) may store the date when file 200 was last modified, segment 208 (bits 14,024 to 14,535) may store the file name of file 200, etc. For clarity, in Figure 2 The specific bit ranges depicted in the are for example purposes only; different files ( Figure 2 The 13,000 to 13,511 bits of the different file (not shown) may be used for a purpose entirely different from storing the name of the author of the different file, or indeed may not even exist (ie, the different file may contain fewer than 13,000 bits).

[0059] In some embodiments, the cloud sync storage application may determine that one or more portions (i.e., one or more bits) of the cloud file 200 may need to be downloaded to the local storage device. This may be in response to detecting a read request for the cloud file 200 (such as via operation 102 of method 100, as described with respect to Figure 1 In some embodiments, the cloud sync storage application may determine that certain portions of the cloud file 200 should be downloaded even in the absence of a read request, such as when the cloud sync storage application is first installed and started on a new system, as will be described in further detail below.

[0060] Local files 220 may be stored in the cloud sync directory along with one or more placeholder files. As described above, a placeholder file may be a locally stored file that represents a cloud-only file. The placeholder file may contain minimal metadata to enable the file system to track which files are stored on the cloud (e.g., if a cloud-only file is permanently deleted or moved to a different directory, the corresponding placeholder file may also be deleted or moved accordingly to indicate to the file system that the file no longer exists in that directory).

[0061] In some embodiments, local file 220 may be (or replace) a placeholder file. For example, in some embodiments, the cloud sync storage application may download data from the cloud via download 212 and / or download 218, and modify the pre-existing placeholder file to add data corresponding to ranges 202 and / or 208, respectively, to the placeholder file. In such embodiments, local file 220 is the placeholder file itself.

[0062] In some embodiments, the local file 220 may be stored in a different directory (e.g., a directory separate from the cloud sync directory including the placeholder file, such as in a compressed archive or database), but may be accessed (e.g., by a cloud sync storage application) when a read request for the cloud file 200 is detected. For example, the cloud sync storage application may have security privileges that enable it to monitor operations performed by the system executing the cloud sync storage application. Further, the cloud sync storage application may be able to intercept certain instructions.

[0063] For example, in some embodiments, while monitoring operations performed by the system, the cloud sync storage application may detect a read request submitted from the file explorer to the storage controller for cloud file 200. In response to detecting the read request, the cloud sync storage application may intercept the request, access the local file 220 (even if the local file 220 is stored in a completely different location on the local drive), and respond to the read request as if it were the storage controller that acknowledged ownership of the cloud file 200. In response to intercepting and responding to the request, the cloud sync storage application may receive subsequent requests for more specific requests to find data stored in bits 202 and / or 208, at which point the cloud sync storage application may return local bits 222 and / or 228, respectively, from the local file 220. Thus, the file explorer application may behave as if it had just accessed a complete copy of file 200 and had its request completed normally.

[0064] Subsequent read requests may include instructions to instruct the recipient on how to access the desired bits. For example, if the file explorer expects bits 14,024 to 14,535 (range 208), a subsequent read request may instruct the recipient to "seek bits 14,024 and return the following 512 bits." Based on the mapping stored in local bits 230, the cloud sync storage application may determine that the desired range 208 corresponds to local range 228, and may therefore instead seek bits 512 and return the following 512 bits. Thus, the request may be satisfied and the requested bits returned without downloading the entire local copy of the cloud file 200.

[0065] If a subsequent read request includes instructions indicating that the desired data is not stored in local file 220 (e.g., if a subsequent read request indicates "seek bit 3,000 and return bit 4,000 that follows," but a local copy of the requested data does not exist), this may indicate that the earlier prediction that the data might be requested was incorrect. There are several different responses to this situation. For example, in some embodiments, the cloud sync storage application may respond by initiating a download of only the specifically requested bits from cloud file 200 (bits 3,001 to 7,000 in this example) and returning them when the download is complete (possibly also saving the newly downloaded bits in local file 220 and updating metadata 230 if the particular data is requested again).

[0066] However, there is a possibility that multiple subsequent requests expect additional data. While the cloud sync storage application can check only the requested data for each request and download it when needed, initiating a download of data from the cloud has a non-zero resource footprint. The computational cost of initiating dozens of smaller downloads may consume more time and resources more quickly than just downloading the entire file once. In addition, if an early prediction does not result in the download of the now expected data, this may indicate that the prediction was incorrect and / or was misreported, thereby increasing the likelihood that additional subsequent requests will call for data that does not exist in the local file 220. Therefore, in some embodiments, if a subsequent request calls for data that is not included in the local file 220, the cloud sync storage application may respond by initiating a download of the entire cloud file 200. In some embodiments, the cloud sync storage application may also update one or more definitions or parameters to indicate that a previous prediction was incorrect.

[0067] Figure 3 A method 300 of identifying an application responsible for initiating a read request according to several embodiments of the present disclosure is shown. The method 300 may be performed, for example, by a cloud sync storage application executing on a client system. In general, the method 300 describes tracking patterns of various system operations and calls over time, maintaining profiles of various applications based on these operations, and utilizing this information to attempt to identify the application initiating the read request (enabling more accurate request classification / prediction of desired data).

[0068] Method 300 includes, at operation 302, monitoring system operations and requests. Operation 302 may include, for example, tracking calls (including associated data (such as signature hashes) and content returned in response to the calls). Method 300 also includes, at operation 304, maintaining and updating application profiles. This may include, for example, maintaining a database containing profiles of known applications and libraries. A given profile may consist of an application / library name, a known file path, a known file signature hash (Message Digest (MD) 5, Secure Hash Algorithm (SHA) 1, SHA256, etc.), an exported function (for a library), a function signature and name, and a call sequence. In addition, for each application and / or library, operation 304 may further include connecting a given request from the application and / or library to a location or portion of a file. For example, operation 304 may include recording the file path of the application, its size, one or more calls / requests submitted most frequently by the application, and which portions of a given file are being requested (e.g., "always the first 512 bytes").

[0069] Method 300 also includes, at operation 306, determining whether a read request has been detected. Operation 306 may include, for example, analyzing the monitored operation to determine whether the operation includes a read request. If a read request has not been detected (306 "No"), method 300 may continue to monitor and update its application profile (via returning to operations 302 and 304). If a read request is detected (306 "Yes"), method 300 also includes, at operation 308, identifying which application is responsible for the request. Note that although the request may include information marking the application responsible for the request, this may not always be the case. Further, even if the request does include this information, it may be misleading. For example, if a user of the system is using an image editing application and desires to open an image file, the image editing application may launch an embedded instance of a file explorer application to enable the user to browse the file. If the embedded file explorer application attempts to access a file in order to generate a thumbnail of the file in a particular directory, this may be detected as a read request for the file in question (306 "Yes"), but the request itself may include a signature indicating that it originates from the image editing application. Operation 308 may include utilizing the profile maintained at operation 304 to determine that the "actual" requesting application is a file explorer application (which is more likely to attempt to generate a thumbnail, whereas an image editing application is more likely to require the entire file to be opened).

[0070] Operation 308 may consider high confidence identifiers (such as checksums, or signature hashes) before relatively lower confidence identifiers (such as file paths, sizes, or behaviors) to determine which profile is the best match (and therefore which application initiated the request). In some embodiments, if a high confidence match is found (e.g., the signature in the request matches the signature contained in the profile), operation 308 may end its analysis.

[0071] In some embodiments, if no profile matches the request or if no profile is within a certain similarity threshold, then operation 308 may conclude that no match was found. In some embodiments, if no match is found, then the entire target file may be downloaded. However, in some embodiments, if no profile matches the request, then operation 308 may select a "closest match" profile.

[0072] Method 300 also includes predicting and downloading portions of the file at operation 312. Operation 312 may include, for example, identifying a segment of the file that may be needed to satisfy the read request (based on the identified profile), and downloading the segment if a local copy does not already exist. Operation 312 may also include responding to the request to indicate that the complete file is available and ready to be read, even though only a relatively small portion of the file (i.e., the predicted portion) has been obtained.

[0073] Note that operation 312 may include downloading one or more additional margins or extra data beyond the portion predicted to be required. For example, even if the identified profile strongly indicates that the true target of the request is a specified range of bits, operation 312 may include downloading that range, and also downloading an additional 1,024 bits before and / or after the specified range. Further, operation 312 may include downloading a predetermined range regardless of the prediction; for example, in some embodiments, operation 312 may include downloading the first and / or last 4,096 bits of any file, even if those bits are not specifically expected to be required. Although this may consume additional resources, portions of files are often requested regardless of the application / request, and therefore, in some embodiments, this may be considered a worthwhile tradeoff.

[0074] Method 300 also includes, at operation 314, determining whether the prediction is correct. Operation 314 may include, for example, analyzing subsequent read requests to determine which portion(s) of the file in question is actually needed, and comparing the required portion(s) with the downloaded portion(s). If the prediction is correct (314 "yes") and the required portion(s) of the file has been downloaded, method 300 also includes, at operation 318, returning the requested data.

[0075] If the prediction is incorrect (such as if the required portion has not been downloaded, 314 "No"), method 300 also includes: downloading the portion(s) of the file necessary to satisfy the request at operation 316. In some embodiments, operation 316 may include downloading the entire file. In some embodiments, operation 316 may include downloading only the missing portion of the file.

[0076] In some embodiments, operation 316 may include comparing the now known required portion to the application profile to determine whether a different profile is a closer match based on the additional information, and if so, downloading any additional data indicated by the new profile may also be necessary. For example, if at operation 308, a first profile was selected as the best match, but at operation 314, the prediction was found to be incorrect, operation 316 may include searching the profiles again to determine whether a second profile is a better match in light of the additional information. If a second match is found, operation 316 may also include downloading any remaining missing portions that may be necessary based on the second profile. In some embodiments, operation 316 may simply include downloading the entire file.

[0077] After downloading the desired portion of the file (at operation 312, or if the prediction was incorrect, at operation 316), method 300 further includes returning the requested data at operation 318. Operation 318 may include returning a portion of the local file corresponding to the requested portion of the cloud-only file, thereby advantageously enabling the system performing method 300 to satisfy the request without downloading the entire file from the cloud.

[0078] After returning the requested data, method 300 may return to operation 304 to update the profile database based on the results of operation 314 (and operation 316, if necessary). For example, if the initial download successfully captured the required data, but only because it was included in the margin (meaning that the prediction itself is still inaccurate), then this information can be used to update the associated profile. In some embodiments, operation 304 may include updating the various weights of the profile based on contextual information surrounding the request. If the prediction is incorrect (314 "No"), operation 304 may include updating the selected profile (and possibly a second "actually correct" profile) based on the error. In some embodiments, operation 304 may include creating a new profile based on the required portion(s) of the file.

[0079] Figure 4A method 400 for predictively provisioning cloud-synced files in accordance with several embodiments of the present disclosure is shown. The method 400 includes, at operation 402, identifying portions of cloud files that are likely to be requested. Operation 402 may include, for example, analyzing files stored on a cloud system and system configuration information, such as identification of various applications installed and / or executed on the computing system, runtime, identity of a user of the computing system, or an organization or entity (such as an enterprise and / or workplace) that controls the computing system. In some embodiments, the system configuration information may be compared to a stored profile. Operation 402 may include utilizing the information to predict portions of one or more files that are likely to be subject to a read request. For example, if one of the files stored on the cloud system is a video file, operation 402 may determine that a particular frame of the video is likely to be requested in order to generate a thumbnail.

[0080] Operation 402 may include analyzing portions of a cloud file to determine a likelihood level for some or all of the data contained in the file. In some embodiments, operation 402 may include identifying the most likely portion of the file with the relative greatest likelihood level. In some embodiments, operation 402 may only identify portions that are "likely" to be requested if the likelihood level is above a certain threshold. In some embodiments, operation 402 may include identifying the "top 3" most likely portions, etc. In some embodiments, operation 402 may consider the size of some or all portions of the file in addition to their likelihood levels to determine whether the portion is worth downloading.

[0081] It is worth noting that operation 402 can be performed with or without intercepting or detecting a read request. The system can perform operation 402, for example, when installed on a new machine and / or device, when a newly linked cloud system is detected or a new file is added to an existing cloud, when prompted (such as by a user), when executing in the background (possibly waiting for relative downtime), when detecting the installation of a new application, at startup, etc.

[0082] Method 400 also includes downloading the identified portion of the file that is not already stored locally at operation 404. Operation 404 may include, for example, checking one or more directories and / or files to determine whether the portion predicted to be needed already exists in local storage, and downloading some or all portions not found in local storage.

[0083] In some embodiments, operation 404 may include excluding one or more of the identified portions from downloading in view of system settings. For example, if a cloud video file has a size of 5GB, but operation 402 identifies that a particular 1GB segment of the video may be requested, even downloading the 1GB segment may still consume considerable bandwidth and storage. Therefore, various settings are contemplated that may limit, throttle, or cap such downloads unless the file in question (or segment thereof) is explicitly requested.

[0084] The parts may be saved to one or more files. In some embodiments, all of the identified parts may be bundled into a single "bulk" download and saved as a single file, with metadata mapping bits (or ranges thereof) of the bulk file to corresponding bits (or ranges thereof) of the cloud file. Thus, when data is requested, the system performing operation 400 may search the bulk file to determine whether the requested data has been downloaded (rather than checking multiple different files).

[0085] Method 400 also includes, at operation 406, intercepting and confirming the read request. Operation 406 may include, for example, monitoring system operation and determining that the read request has been sent. The system performing method 400 may have permissions that enable the system to observe and intercept interactions between applications and low-level file systems. Upon detecting a read request, operation 406 may include responding with a confirmation (such as transmitting to the sender of the request that the requested file is available for reading), regardless of whether the requested file is stored locally.

[0086] Method 400 also includes, at operation 408, determining whether the requested data is stored locally. Operation 408 may include, for example, receiving a follow-up to the confirmed read request, which specifies the specific data being requested. Operation 408 may include comparing the specified data of the target file with the content of one or more locally stored files (e.g., the files located or downloaded in operation 404).

[0087] If operation 408 results in locating the requested data in the local storage (408 "Yes"), method 400 also includes: at operation 410, returning the requested data, thereby advantageously satisfying the read request with the correct data, although the local copy of the target file has not yet been downloaded from the cloud. If the requested data is not found (408 "No"), method 400 also includes: at operation 412, downloading the data from the cloud. In some embodiments, operation 412 may include downloading the entire target file to the local storage. In some embodiments, operation 412 may include downloading only one or more portions of the target file (such as the portion containing the requested data). Once the requested data is obtained at operation 412, method 400 proceeds to operation 410, and in response to the request, the requested data is returned.

[0088] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings recorded herein is not limited to cloud computing environments. Instead, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0089] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a pool of shared, configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, VMs, and services) that can be quickly provisioned and released with minimal management cost or interaction with the service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0090] Features are as follows:

[0091] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capacity (such as server time and network storage) on demand without manual interaction with the service provider.

[0092] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0093] Resource pooling: The computing resources of a provider are grouped into resource pools to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Generally, consumers cannot control or know the exact location of the provided resources, but can specify the location at a higher level of abstraction (such as country, state, or data center), thus having location independence.

[0094] Rapid elasticity: Capacity can be rapidly and elastically (in some cases automatically) provisioned to scale out quickly and released quickly to scale down quickly. To the consumer, the capacity available for provisioning often appears to be unlimited and can be purchased in any quantity at any time.

[0095] Measurable services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services being utilized.

[0096] The service model is as follows:

[0097] Software as a Service (SaaS): The capability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Aside from limited user-specific application configuration settings, consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems, storage, or even individual application capabilities.

[0098] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired by consumers on the cloud infrastructure, which are created using programming languages ​​and tools supported by the provider. Consumers neither manage nor control the underlying cloud infrastructure including networks, servers, operating systems or storage, but have control over the applications they deploy and may also have control over the configuration of the application hosting environment.

[0099] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, network, and other basic computing resources on which consumers can deploy and run arbitrary software including operating systems and applications. Consumers neither manage nor control the underlying cloud infrastructure, but have control over the operating system, storage, deployed applications, and may have limited control over selected network components (e.g., host firewalls).

[0100] The deployment model is as follows:

[0101] Private cloud: Cloud infrastructure is run solely for an organization. It can be managed by that organization or a third party and can exist inside or outside the organization.

[0102] Community cloud: The cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist inside or outside the organization.

[0103] Public cloud: Cloud infrastructure is available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0104] Hybrid cloud: A cloud infrastructure consisting of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0105] Cloud computing environments are service-oriented, with characteristics centered on statelessness, low coupling, modularity, and semantic interoperability. The core of computing is the infrastructure that includes a network of interconnected nodes.

[0106] Reference now Figure 5 , depicts an illustrative cloud computing environment 500. As shown, the cloud computing environment 500 includes one or more cloud computing nodes 510 with which a local computing device used by a cloud consumer can communicate, such as a personal digital assistant (PDA) or cellular phone 540A, a desktop computer 540B, a laptop computer 540C, and / or an automobile computer system 540N. The nodes 510 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks (such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above). This allows the cloud computing environment 500 to provide infrastructure as a service, platform as a service, and / or software as a service without the cloud consumer having to maintain resources for them on a local computing device. It should be understood that Figure 5 The various types of computing devices 540A-N shown in the figure are merely illustrative, and the computing node 510 and cloud computing environment 500 can communicate with any type of computing device over any type of network and / or network addressable connection (eg, using a web browser).

[0107] Reference now Figure 6 , showing a cloud computing environment 500 ( Figure 5 ) provides a set of functional abstraction layers. First of all, it should be understood that Figure 6 The components, layers and functions shown are merely illustrative, and embodiments of the present invention are not limited thereto. As shown in the figure, the following layers and corresponding functions are provided:

[0108] The hardware and software layer 660 includes hardware and software components. Examples of hardware components include: mainframe 661; server 662 based on RISC (Reduced Instruction Set Computer) architecture; server 663; blade server 664; storage device 665; and network and network components 666. In some embodiments, software components include network application server software 667 and database software 668.

[0109] Virtualization layer 670 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 671 ; virtual storage 672 ; virtual networks 673 , including virtual private networks; virtual applications and operating systems 674 ; and virtual clients 675 .

[0110] In one example, the management layer 680 may provide the functionality described below. Resource provisioning functionality 681 provides dynamic acquisition of computing resources and other resources for performing tasks in a cloud computing environment. Metering and pricing functionality 682 provides cost tracking of resources used within a cloud computing environment and provides bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security functionality provides identity authentication for cloud consumers and tasks and provides protection for data and other resources. User portal functionality 683 provides access to the cloud computing environment for consumers and system administrators. Service level management functionality 684 provides allocation and management of cloud computing resources to meet required service levels. Service level agreement (SLA) planning and fulfillment functionality 685 provides pre-scheduling and procurement of cloud computing resources for which future demand is forecasted in accordance with the SLA.

[0111] The workload layer 690 provides examples of functions that can take advantage of a cloud computing environment. In this layer, examples of workloads and functions that can be provided include: mapping and navigation 691; software development and lifecycle management 692; virtual classroom teaching provision 693; data analysis processing 694; transaction processing 695; and predictive provisioning of files stored in the cloud 696.

[0112] Reference now Figure 7 , shows a high-level block diagram of an example computer system 700 that can be configured to perform various aspects of the present disclosure (e.g., including methods 100, 300, and 400, respectively). According to an embodiment of the present disclosure, the example computer system 700 can be used to implement one or more of the methods or modules described herein and any related functions or operations (e.g., using one or more processor circuits of a computer or a computer processor). In some embodiments, the main components of the computer system 700 may include one or more CPUs 702, a memory subsystem 708, a terminal interface 716, a storage interface 718, an I / O (input / output) device interface 720, and a network interface 722, all of which can be directly or indirectly communicatively coupled via a memory bus 706, an I / O bus 714, and an I / O bus interface unit 712 for inter-component communication.

[0113] The computer system 700 may include one or more general-purpose programmable central processing units (CPUs) 702, some or all of which may include one or more cores 704A, 704B, 704C, and 704D, generally referred to herein as CPUs 702. In some embodiments, the computer system 700 may include multiple processors typical of relatively large systems; however, in other embodiments, the computer system 700 may instead be a single CPU system. Each CPU 702 may execute instructions stored in a memory subsystem 708 on a CPU core 704, and may include one or more levels of on-board cache.

[0114] In some embodiments, the memory subsystem 708 may include random access semiconductor memory, storage devices, or storage media (volatile or non-volatile) for storing data and programs. In some embodiments, the memory subsystem 708 may represent the entire virtual memory of the computer system 700, and may also include virtual memories of other computer systems coupled to the computer system 700 or connected via a network. The memory subsystem 708 may be a single monolithic entity in concept, but in some embodiments, the memory subsystem 708 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function so that one cache stores instructions and another cache stores non-instruction data used by one or more processors. The memory may also be distributed and associated with different CPUs or CPU groups, as known in any of various so-called non-uniform memory access (NUMA) computer architectures. In some embodiments, the main memory or memory subsystem 804 may include elements for controlling and flowing the memory used by the CPU 702. This may include a memory controller 710.

[0115] Although the memory bus 706 is Figure 7706, but in some embodiments, the memory bus 706 may include multiple different buses or communication paths, which may be arranged in any of a variety of forms, such as point-to-point links in a hierarchical, star or mesh configuration, multi-layer buses, parallel and redundant paths, or any other suitable type of configuration. In addition, although the I / O bus interface 712 and the I / O bus 714 are shown as a single corresponding unit, in some embodiments, the computer system 700 may include multiple I / O bus interface units 712, multiple I / O buses 714, or both. Further, although multiple I / O interface units are shown that separate the I / O bus 714 from the various communication paths to various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0116] In some embodiments, the computer system 700 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device with little or no direct user interface but receiving requests from other computer systems (clients). Further, in some embodiments, the computer system 700 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a phone, a smart phone, a mobile device, or any other suitable type of electronic device.

[0117] Notice, Figure 7 The main components of the exemplary computer system 700 are intended to be depicted. However, in some embodiments, the various components may have more Figure 7 greater or lesser complexity than shown in Figure 7 The components shown in or except Figure 7 Components other than those shown in FIG. 1 and the number, type, and configuration of these components may vary.

[0118] The present invention may be a system, method and / or computer program product at any possible level of technical detail integration. The computer program product may include (one or more) computer-readable storage media having computer-readable program instructions thereon, and the computer-readable program instructions are used to cause a processor to perform various aspects of the present invention.

[0119] Computer readable storage medium can be a tangible device that can hold and store instructions used by an instruction execution device. Computer readable storage medium can be, for example, but not limited to, any suitable combination of electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or the aforementioned storage devices. A non-exhaustive list of more specific examples of computer readable storage medium includes the following: portable computer disk, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, such as a punch card or a convex structure in a groove with instructions recorded on it, and any suitable combination of the above devices. Computer readable storage medium as used herein should not be interpreted as a temporary signal itself, such as radio waves or other free propagating electromagnetic waves, electromagnetic waves propagated by waveguides or other transmission media (e.g., light pulses by optical fiber cables), or electrical signals transmitted by wires.

[0120] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0121] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of integrated circuits, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++, etc.) and process programming languages ​​(such as "C" programming language or similar programming languages). The computer-readable program instructions can be executed completely on the user's computer, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions to personalize the electronic circuit, so as to perform various aspects of the present invention.

[0122] Various aspects of the present invention are described herein with reference to the flow chart and / or block diagram of the method, device (system) and computer program product according to embodiments of the present invention. It will be understood that each frame of the flow chart and / or block diagram and the combination of frames in the flow chart and / or block diagram can be implemented by computer-readable program instructions.

[0123] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed via the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in one or more boxes of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can guide the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable storage medium having the instructions stored therein includes an article of manufacture, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0124] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps will be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in one or more boxes of the flowchart and / or block diagram.

[0125] Flowchart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention.In this regard, each frame in the flow chart or block diagram can represent the module, segment or part of instruction, which includes one or more executable instructions for realizing the specified logical function.In some alternative embodiments, the function noted in the frame may not occur in the order noted in the figure.For example, two frames shown continuously can actually be performed substantially simultaneously, or these frames can sometimes be performed in reverse order, depending on the function involved.It will also be noted that the combination of the frames in each frame of the block diagram and / or flow chart illustration and the block diagram and / or flow chart illustration can be realized by a dedicated hardware-based system that performs a specified function or action or performs a combination of special hardware and computer instructions.

[0126] The description of various embodiments of the present invention has been given for the purpose of illustration, but it is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found on the market, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method for predictively serving a remote file, comprising: identifying remote files stored on the remote computing system; predicting that a predicted portion of the remote file is likely to be subject to a future read request; downloading the predicted portion of the remote file to a local file; as well as Metadata of the local file is updated to map a local portion of the local file to the predicted portion of the remote file, wherein the local file is configured to appear to the file system as if it were the complete remote file.

2. The method according to claim 1, further comprising: A first read request is received, wherein: The identifying is based at least on a target of the first read request; and The prediction is based on at least the first read request.

3. The method according to claim 2, further comprising: Based at least on an application profile database, a requesting application initiating the first read request is determined, wherein the prediction is also based at least on the requesting application.

4. The method according to claim 3, further comprising: receiving a second read request targeting a target portion of the remote file; as well as Based at least on the predicted portion and the target portion, the application profile database is updated.

5. The method according to claim 1, further comprising: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file includes the target portion; as well as In response to determining that the predicted portion includes the target portion, at least a portion of the local portion mapped to the predicted portion is returned based on the metadata.

6. The method according to claim 1, further comprising: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file does not include the target portion; as well as In response to determining that the predicted portion does not include the target portion, at least a second portion of the remote file including the target portion is downloaded.

7. The method according to any one of claims 1 to 6, further comprising: Read operations of the computing system are monitored, wherein the predicting is based at least on the monitoring.

8. The method according to any one of claims 1 to 6, wherein: The prediction is based at least on system configuration information.

9. The method according to any one of claims 1 to 6, wherein: The remote computing system is a cloud computing system; and The remote file is a cloud file.

10. A system for predictively serving remote files, comprising: Memory; as well as A central processing unit (CPU), wherein the CPU includes one or more CPU cores, and the CPU is configured to: identifying remote files stored on the remote computing system; predicting that a predicted portion of the remote file is likely to be subject to a future read request; downloading the predicted portion of the remote file to a local file; as well as Metadata of the local file is updated to map a local portion of the local file to the predicted portion of the remote file, wherein the local file is configured to appear to the file system as if it were the complete remote file.

11. The system according to claim 10, wherein: The CPU is further configured to receive a first read request, wherein: The identifying is based at least on a target of the first read request; and The prediction is based on at least the first read request.

12. The system according to claim 11, wherein: The CPU is further configured to determine, based at least on an application profile database, a requesting application that initiated the first read request, wherein the prediction is further based at least on the requesting application.

13. The system according to claim 12, wherein: The CPU is also configured to: receiving a second read request targeting the target portion of the remote file; and Based at least on the predicted portion and the target portion, the application profile database is updated.

14. The system according to claim 10, wherein: The CPU is also configured to: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file includes the target portion; as well as In response to determining that the predicted portion includes the target portion, at least a portion of the local portion mapped to the predicted portion is returned based on the metadata.

15. The system according to claim 10, wherein: The CPU is also configured to: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file does not include the target portion; as well as In response to determining that the predicted portion does not include the target portion, at least a second portion of the remote file including the target portion is downloaded.

16. The system according to any one of claims 10 to 15, wherein: The CPU is further configured to monitor read operations of the system, wherein the predicting is based at least on the monitoring.

17. The system according to any one of claims 10 to 15, wherein: The remote computing system is a cloud computing system; and The remote file is a cloud file.

18. A computer program product for predictively serving a remote file, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by a computer to cause the computer to: identifying remote files stored on the remote computing system; predicting that a predicted portion of the remote file is likely to be subject to a future read request; downloading the predicted portion of the remote file to a local file; as well as Metadata of the local file is updated to map a local portion of the local file to the predicted portion of the remote file, wherein the local file is configured to appear to the file system as if it were the complete remote file.

19. The computer program product of claim 18, wherein: The instructions further cause the computer to receive a first read request, wherein: The identifying is based at least on a target of the first read request; and The prediction is based on at least the first read request.

20. The computer program product of claim 19, wherein: The instructions further cause the computer to determine a requesting application that initiated the first read request based at least on an application profile database, wherein the prediction is further based at least on the requesting application.

21. The computer program product of claim 20, wherein: The instructions further cause the computer to: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file includes the target portion; as well as In response to determining that the predicted portion includes the target portion, at least a portion of the local portion mapped to the predicted portion is returned based on the metadata.

22. The computer program product of claim 18, wherein: The instructions further cause the computer to: receiving a second read request targeting a target portion of the remote file; determining that the predicted portion of the remote file does not include the target portion; as well as In response to determining that the predicted portion does not include the target portion, at least a second portion of the remote file including the target portion is downloaded.

23. The computer program product of claim 22, wherein: The second portion of the remote file includes the entirety of the remote file.

24. A computer program product according to any one of claims 18 to 23, wherein: The instructions further cause the computer to monitor a read operation of the computer, wherein the predicting is based at least on the monitoring.

25. A computer program product according to any one of claims 18 to 23, wherein: The remote computing system is a cloud computing system; and The remote file is a cloud file.

Images