Reduce OS imaging time using "just in time" file delivery

Abstract

Embodiments are provided for mirroring an operating system by creating a new OS image from a copy of an installer operating system (OS) image maintained in persistent storage. During operating system mirroring, only a portion of the operating system files in the installer image are fully copied to the new operating system image. Placeholder files are created for other files that were not included in the initial subset of OS files, which are determined to be critical to the booting of the OS and / or a minimum set of OS functions. Placeholder files are different from sparse files, which are not accurately displayed by the file system as complete copies of the underlying installer OS image. The data of the placeholder files is copied only when requested, on demand, and / or when there is available / unused processing bandwidth, which is subsequently identified after the computing system is rebooted using the new OS image.

Description

Background Art

[0001] Sometimes it is necessary to reformat a computing system's operating system (OS), for example, when the OS becomes corrupted or according to a scheduled maintenance schedule. Users may also wish to reformat their computing system's OS when they are preparing to sell or discard their computing system to erase or clear any personal data that may remain on the computing system and / or remove installed applications that may be associated with ancillary fees and subscriptions paid by the user. Some businesses also schedule periodic lifecycle maintenance that causes their computing systems to be reformatted on a scheduled or periodic basis.

[0002] During reformatting, the operating system's files are typically copied from a backup or installer copy of the OS that is maintained as a persistent copy of the OS image, for example, in a locked portion of the computing system's hard drive. Examples of persistent copies of OS images include the initial installer OS image that ships with the computing system, and backup / ghost copies of the OS image that can be created / saved during use of the computing system. The persistent copy of the OS image can also be stored separately from the computing system on a portable hard drive and / or a remote server.

[0003] During reformatting of an operating system, the current operating system files / folders are replaced with the files / folders maintained in the installer / backup copy of the operating system image. At least for this reason, reformatting an OS is often referred to as OS reimaging, OS imaging, reimaging the OS, and imaging the OS.

[0004] While OS imaging / re-imaging is sometimes necessary, copying all files from the persistent copy of the OS image to the new OS image is also computationally expensive and time consuming for the reasons stated above. However, much of this computational overhead and time is unnecessary, especially when considering the size of the unnecessary data that is initially copied during an OS re-image. For example, it is estimated that many computing systems using Microsoft's Windows typically only use approximately 1-2GB of the 20+GB of Windows files that are typically included in the persistent copy of the Windows operating system image. This discrepancy can occur, for example, due to the wide range of features built into Windows operating system images, including different language packs and specific application features that may not always be used, especially by all users, but are still provided for use if needed.

[0005] It is well known that the amount of data that is unnecessarily copied during re-imaging will depend on the capabilities and functionality of the operating system being re-imaged, as well as how different users wish to use their computing systems. However, many of the available operating system files / folders are not needed during the operating system boot and / or after its initial reformatting / re-imaging. For example, some experts have determined that less than 20% of the OS image files / folders need to be copied from the backup OS image during re-imaging to provide a functional OS image that is bootable and still has the basic set of required functionality that is most commonly used within a short period of time after boot. However, despite this knowledge, traditional re-imaging processes still involve copying unnecessary files / folders that are not required to boot the operating system and, in fact, may never be needed / used.

[0006] The aforementioned conventional re-imaging process represents a significant waste of computational overhead and delay during operating system imaging. Therefore, there is a continuing need and desire for improved systems, methods, and apparatus for OS imaging, particularly for improved systems, methods, and apparatus that can be used to reduce OS imaging time.

[0007] The subject matter claimed herein is not limited to embodiments that necessarily address any particular disadvantages of conventional systems or that operate only in environments such as those described above. Rather, this background is provided merely to illustrate one exemplary technology area in which some of the described embodiments may be practiced. Summary of the Invention

[0008] Embodiments disclosed herein relate to systems, methods, and devices configured to facilitate operating system imaging (OS imaging), and more particularly, to systems, methods, and devices that can be used to reduce OS imaging time.

[0009] In some embodiments, a new OS image is copied, or mirrored / re-imaged, from an installer copy of an OS stored in persistent memory and including a plurality of OS files. During OS mirroring, only a subset of OS files from the installer / persistent copy of the OS image are completely copied from the installer copy to the new OS image. In some cases, the subset of files selected for complete / complete copying consists of, or is otherwise limited to, a minimum set of OS files required to create a new OS image that is bootable by a computing system with a predetermined set of OS capabilities (e.g., files required to boot the operating system and / or files expected to be used shortly after booting the operating system). The remaining files are copied after booting the computing system using the new OS image only when requested, on demand, and / or when there is available / unused processing bandwidth.

[0010] The disclosed embodiments include a computer-implemented method for OS imaging (re-imaging an OS for a computing system) in response to a detected request for OS re-imaging. The method includes the computing system identifying a minimum set of OS data required to create a new OS image bootable by the computing system with a predetermined OS feature set, and identifying a remaining set of OS data determined to be not required to create at least a new OS image bootable by the computing system with the predetermined OS feature set.

[0011] The method further includes, for a minimum set of OS data determined to be required, creating a new OS image by creating a duplicate set of OS files in the file system from corresponding files in the persistent copy of the OS image that contains the same minimum set of OS files. Furthermore, for a remaining set of OS data determined to be not required, the method further includes creating a new OS image by creating placeholder files that include unhydrated and / or partially hydrated copies of corresponding OS files found in the stored persistent copy of the OS image, wherein the unhydrated and partially hydrated copies omit at least some data from the files contained in the stored persistent copy of the OS image.

[0012] The method also includes the system inaccurately presenting one or more placeholder files of the new OS image to one or more OS components as fully hydrated files (e.g., containing complete / functional copies of all data from corresponding files maintained by the persistent copy of the operating system), even though the placeholder files are not fully hydrated (because they omit at least some data from the associated files of the persistent operating system image).

[0013] Other embodiments include the computing system subsequently hydrating the placeholder file(s) by completing the data copy from the persistent OS image to the new OS image associated with the placeholder file(s), as needed and / or in response to detecting available bandwidth and / or sequential ordering. Other embodiments include the computing system refraining from hydrating one or more placeholder files in response to determining that the placeholder files do not need to be fully hydrated (i.e., determining that not all data from the persistent OS to the placeholder file(s) of the new OS image need to be copied).

[0014] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to exhaustively identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0015] Additional features and advantages will be set forth in the following description, and in part will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the present invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. The features of the present invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] To illustrate the manner in which the foregoing and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments that are illustrated in the accompanying drawings. Understanding that these drawings depict only typical embodiments and are therefore not to be considered limiting of scope, the embodiments will be described and explained with additional specificity and detail through the accompanying drawings, in which:

[0017] Figure 1 An example architecture including a computing system that includes and / or can be used to implement the disclosed embodiments is illustrated.

[0018] Figure 2 Describes the abstraction of operating system elements, including file systems and files, directory listings of file systems, and corresponding persistent OS images.

[0019] Figure 3 A flow chart illustrating an example method for performing OS imaging is shown.

[0020] Figure 4 A flow chart of an example method for processing a request for a file in a re-imaged OS that includes at least one placeholder file that is unhydrated relative to an OS (operating system) image stored in persistent storage is illustrated.

[0021] Figure 5 Illustrated is a flowchart of an example method for incrementally hydrating placeholder files from a re-imaged OS that are only partially hydrated and / or unhydrated relative to corresponding persistent copies of the files maintained in an OS (operating system) image stored in persistent storage. DETAILED DESCRIPTION

[0022] The disclosed embodiments are operable to facilitate OS imaging, including initial imaging of an OS and reformatting or re-imaging of an existing OS to create a new OS image that replaces the current OS image, the new OS image being bootable by a computing system for use at runtime, by copying OS files / data from a persistent copy of the existing OS image to the new OS image.

[0023] Figure 1An example computing architecture 100 for implementing the disclosed embodiments is illustrated and includes a computing system 110 having various components that will now be described, each stored within storage 115 of the computing system and / or within one or more remote systems 190 as will be described.

[0024] As shown, the computing system 110 includes a storage 120 and one or more processors 120. The storage 115 stores computer executable code 112, which is executed by the one or more processors 120 to instantiate other computing system components (e.g., monitoring agent 130, OS components 140, file system 150, kernel 160, and driver 170). The processor(s) 120 also execute the computer executable code 112 to implement the disclosed methods, e.g. Figures 3 to 5 The referenced method.

[0025] As will be described in greater detail below, the monitoring agent 130 is used to track and identify usage patterns of the computing system 110, including usage of different applications, interfaces, and other OS components 140, and usage of different files 152 in the file system 150, as well as user behavior and preferences regarding the computing system. The monitoring agent 130 and / or the file system 150 / driver 170 use this information to determine which files / data need to be copied from the persistent copy 180 of the OS during OS imaging / re-imaging.

[0026] Although storage 115 is currently shown as containing file system 150 and computer executable code 112, but not kernel 160, driver 170, monitoring agent 130 or OS component 140, it should be understood that this visual separation is shown only to facilitate the discussion herein and highlight a few selected computing system components. This should not be interpreted as representing any actual physical separation of storage components or the distribution of the components shown to different physical storage containers. For example, in some embodiments, kernel 160, driver 170 and OS component 140 are all maintained / stored on a single hard drive of storage 115.

[0027] That is, it should also be noted that storage 115 can be configured to be segmented / partitioned into different storage containers, for example, to separately store a persistent copy 180 of the OS (e.g., a backup installer copy of the OS that has at least the complete set of OS files 152 required to boot the OS) maintained in a discrete partition of persistent storage that persists across computer reboots and even during reformatting of other portions of storage 115 containing the current runtime OS and files.

[0028] In some cases, storage 115 is also configured with a combination of volatile and non-volatile storage. However, preferably, the file system and other OS components, including applications and interfaces (140) that the runtime OS uses to perform desired functions and which may include any applications / interfaces used by the OS, are stored in non-volatile memory.

[0029] OS components 140 are currently listed as including applications and interfaces, such as native OS applications and interfaces, as well as third-party applications and interfaces configured to run with the OS. In some cases, OS components 140 also include the underlying kernel 160 and drivers 170 of computing system 110, although they are shown separately and are also maintained in non-volatile storage as part of the OS image.

[0030] In some cases, storage 115 includes a hard drive. In other cases, storage 115 includes flash memory and / or other persistent storage and / or a combination of a hard drive and other persistent storage.

[0031] Storage 115 is presently shown as being maintained entirely within a single, standalone computing system 110. In some alternative embodiments, storage 115 is distributed among different computers / computing systems, such as remote system(s) 190, which are connected via one or more wired and / or wireless network connections 195, and such that computing system 110 may be viewed as a distributed computing system that includes one or more remote systems 190, each including their own storage and corresponding computing components to support the disclosed functionality (such as those described with reference to computing system 110).

[0032] During use, computing system 110 receives a request to image an OS from persistent copy of the OS 180. The request may be a request to create an initial installation (if not already fully installed) of the OS from persistent copy of the OS 180 (which may be stored entirely locally, such as on a hard drive, or in some cases at least partially remotely) and / or to re-image the computing system's OS.

[0033] The persistent copy of the OS image, referred to as the persistent copy of the OS 180, includes all files 182 necessary to boot the OS with a minimal set of OS functionality (which will be described in more detail below). For example, the persistent copy of the OS 180 includes files 182 for instantiating at least the kernel 160, drivers 170, and file system 150. In some cases, the persistent copy of the OS 180 also includes files for instantiating other OS components 140 (e.g., the monitoring agent 130 and other components). In alternative embodiments, the persistent copy of the OS 180 omits and does not include files for instantiating the monitoring agent 130 and / or at least some other OS components 140, and instead, these components are maintained and accessed by one or more remote systems 190.

[0034] Reference has been made previously to the determination made by the monitoring agent to determine the minimum set of functionality required to boot and / or operate the operating system. It will be appreciated that this determination may be made in a variety of ways. According to some embodiments, for example, the monitoring agent 130 (locally or remotely) tracks files requested during OS boot to understand / track which files are essential for booting. The monitoring agent 130 also tracks different types of file requests, which are made to distinguish between: requests that rely on data in a file and / or require actual data to be contained in the file, such as for actual read and write requests, and requests that are alternatively made as data verification or reference requests, which query whether a file has been created (e.g., to support an intended / subsequent use of the file) and / or require only metadata for a referenced file without requiring the actual underlying data of the referenced file.

[0035] In some cases, the monitoring agent 130 is able to make these determinations by using machine learning models / data that are incorporated into the monitoring agent 130 and / or referenced by the monitoring agent 130. In some cases, for example, the monitoring agent 130 is a machine learning engine or component that is trained to track the actual usage of file data requested during and after boot operations and determine which files are critical to booting the operating system and / or which files are most likely to be accessed immediately after boot and / or which files are most likely to be used by one or more different users after boot. For example, functions such as network functions may be determined to be critical functions or functions that may be expected shortly after boot. Based on the user's previous user behavior / preferences analyzed in the training data of the (multiple) machine learning models and / or based on the behavior / preferences of specific known users associated with the computing system being re-imaged, other applications (such as word processing and graphics processing) may also be determined to be preferred functions for one or more specific users that are likely to be invoked shortly after boot.

[0036] In view of the foregoing discussion, it will be understood that the monitoring agent 130 considers various factors to determine which files to fully copy during imaging, including considering the computing system type, operating system configuration, operating system boot process, and known and / or monitored user behavior, including the computing system that is most frequently used after the computer boots, known and / or monitored usage of the computing system and specific OS components (e.g., the applications and interfaces that were most frequently called recently and / or during use), and corresponding training data, including corresponding behavior, usage and profiles of other users, computing systems and operating systems on (multiple) remote systems and / or other training data sets.

[0037] The monitoring agent also considers information identifying unneeded applications / functionality that are never used and / or infrequently used by a particular user associated with the computer and / or by other users who use similar computers and have similar user profiles within a short period of time after booting the computer (e.g., within minutes, hours, or days of booting). In some cases, this information is used to identify files to be omitted from the limited minimum set of data that is copied from the persistent copy of the OS to the new OS image during the imaging process and / or files to be used to further train the machine learning model used by the monitoring agent 130.

[0038] The machine learning engine (when incorporated into and / or when used by a monitoring agent) can utilize any known machine learning model, including but not limited to deep neural networks, regression, clustering, and / or other machine learning models, utilizing any combination of supervised and unsupervised training processes.

[0039] When a new OS image is created (imaged / re-imaged) from a persistent OS image, the new OS image includes the underlying kernel 160 that manages core aspects of the operating system, and the OS file system 150 that includes and organizes all of the new operating system's files, as well as drivers 170 for interfacing with the file system and storage 115.

[0040] Some of the files 152 managed by the file system are necessary for booting the OS and providing a minimum set of OS functions. Other files are non-essential files that can be used to extend OS functions, but are not required for booting the OS.

[0041] The file system 150 is also configured to track various file attributes / metadata for the files in the file system 150. These attributes include, for example, the file path / storage location of each file, the handle / name of each file, and many other attributes of the files. This information is provided by the file system to operating system components that request access to files in the file system.

[0042] When a file or file data is requested, for example, during the boot and / or run-time of an OS, file system 150 or driver 170 (e.g., file system driver and hard drive driver) will access and provide the requested file data to the requesting component. In some cases, the requested data will include a handle to the requested data / file.

[0043] However, in some cases, requests for files / data in a file system do not require actual access to the file's underlying data. Instead, they are simply requests for information about the file (e.g., metadata / file attributes) to verify the file's existence and / or to perform non-critical functions that do not rely on the actual accuracy of the metadata and do not require actual access to all data contained in the referenced file(s). For example, a request to access only a portion of the data in a file does not require that all unrequested data in the file be present. Similarly, a request to check a file type to verify compatibility with a file or to verify the existence of a file does not require that the file's underlying data be currently copied into the file.

[0044] In some embodiments of the disclosed invention, driver 170 includes one or more dedicated file system drivers or driver layers ( Figure 1 , but included in driver 170), which will intercept all requests for OS data made to the file system 150 during boot and / or runtime to determine whether each request for OS data (e.g., a request for a folder, file and / or data within a file) actually requires the data and / or whether it is merely a request that requires general / verified knowledge about the OS data (e.g., checking whether the data / file has been created / exists, or querying for specific metadata / attributes of the file / data without requiring access to the specific data).

[0045] Then, depending on whether the requested operating system data is actually needed and whether the data actually exists in the file system, the dedicated file system driver will provide the data (if it exists) and / or alternatively, if the data is required and does not exist, the system will initialize an immediate data transfer from the persistent copy of the OS image to the OS image to make a copy of that data to the corresponding file in the file system for the new OS image. Additionally and / or alternatively, if the requested data does not exist and it is also determined that a minimum set of OS data is not required for creating a bootable OS image with a minimum set of functionality, the file system driver will inaccurately reflect that the data exists (even if it does not exist) to satisfy the request. This act of reflecting the existence of data can include providing metadata for placeholder files that is accurate or inaccurate with respect to the actual data associated with the placeholder files currently stored in the persistent copy of the OS.

[0046] It will be appreciated that the process of providing information (even if inaccurate) can be beneficial in some circumstances, for example, by avoiding having to copy all files from a persistent copy of the OS for use in a new OS image, particularly where the file data is not required during boot or initial operation of the OS after the image (until / unless actually needed), and by preventing OS components requesting the data from generating errors that could prevent the OS from booting and / or processing with a minimal set of features. This can also help reduce the time required to generate an initially bootable and operational operating system (with at least a predetermined minimal set of OS features, which is less than a full operating system feature set), and can allow for more comprehensive updates after boot.

[0047] Therefore, rather than copying all files from the persistent copy of the OS image during imaging, some files are created in the file system associated with the new OS image as placeholder files, which omit some of the data from the corresponding files maintained in the persistent copy of the OS image. Each of these placeholder files is created with a minimum set of attributes determined to be required by the file system / driver to convincingly present the placeholder file as a file fully copied from the persistent OS image to one or more requesting OS components.

[0048] In some cases, the minimum set of attributes for a placeholder file includes at least one of a file name or handle, a file size, and a file type. In some cases, other attributes required for some placeholder files also include, but are not limited to, one or more of a creation date, a modification date, an author, permissions, address information, duration, frame rate, and / or any combination of other attributes.

[0049] It should be understood that in some cases, the minimum set of attributes will also vary depending on the file type. For example, required additional attributes may include, for example, the duration of an audio file, the frame rate of a video file, the organizer or participants of an event file, the sender / receiver addresses of an email file, etc. However, for a placeholder file of the word processing type, these attributes are not required.

[0050] During the creation of placeholder files, in some embodiments, the system will allocate space for each placeholder file within the file system based on the known file size of the corresponding persistent OS image copy(s), and will organize and list these files in the file system directory listing with all of the metadata / file attribute information required to display the placeholder files as complete copies of the corresponding persistent OS image files, including at least the file type, file name / handle, and file size.

[0051] One advantage of allocating space for a placeholder file during its creation is that if / when, for example, you subsequently Figure 4and Figure 5 The exposed methods hydrate the placeholder files, which means there is always enough space to fully hydrate the placeholder files.

[0052] In some alternative embodiments, space is not allocated for placeholder files unless / until it is determined that the placeholder files may be hydrated. This will prevent locking up storage / computing resources that are never used if the placeholder files are never hydrated.

[0053] In some heterogeneous embodiments, the system will identify the hydration probability of the placeholder files (e.g., based on machine learning techniques referenced throughout this disclosure, which are based on user preferences and / or the system, operating system, and corresponding files). Then, based on the determined probability, the system will only allocate space in the file system for placeholder files that are determined to have a probability above a threshold (e.g., 10%, 20%, 30%, 40%, 50%, or higher). The probability determination can also be based on or include a probability that the placeholder file will be hydrated within a predetermined time period (e.g., within the next hour, day, week, month, or other time period).

[0054] However, if a full copy of a file is not made during mirroring, the system may not know all the correct attribute information for the file. For example, the system may not know how much space the file will take up when copying it, especially if it will be an uncompressed copy of the file in the persistent OS image. The system may also not know, for example, the duration of a video until it is played and / or if this duration information is not included in the metadata of the persistent OS image copy.

[0055] In this case, the system may estimate or construct metadata information for each placeholder file based on predetermined values ​​for different files of the same type and / or by basing attribute values ​​on corresponding existing attributes of another file of the same type that has been copied. This means that the metadata / attributes presented for the placeholder file(s) will in some cases be inaccurate. In some aspects, this inaccuracy also includes the designation of the type of the placeholder file (even if it matches the same type associated with the persistent OS image copy) because the placeholder file is empty and has not yet been populated with data formatted as that particular type, and may not be formatted unless / until the data from the persistent OS image file copy is copied into the new OS image placeholder file.

[0056] The values ​​that are made up for the file attributes are values ​​determined by the file system that are enabled to satisfy requests during operating system boot without negatively impacting other operating system processes that are executed during operating system boot. This determination is made during the training and use of the aforementioned machine learning module, and as previously described, the monitoring agent determines which files must be fully copied to create a new OS image that can be booted by a computing system with a predetermined OS feature set.

[0057] According to some embodiments, as described above, the new OS image will incorrectly reflect that the placeholders are actual copies of the corresponding files from the persistent OS image. This representation of the file system / driver is inaccurate because, as described above, at least some of the files are simply placeholders that are not fully hydrated (meaning they are not complete copies, they contain only a limited set of data from the corresponding file in the persistent OS image, rather than the complete set of data for that corresponding file). In this regard, placeholder files can be understood as partially hydrated files or non-hydrated files, wherein the non-hydrated files in the new OS image omit all data (except metadata / basic attribute information) from the corresponding file in the persistent OS image, and wherein the partially hydrated files in the new OS image contain some, but not all, of the data from the corresponding file in the persistent OS image.

[0058] In other words, placeholder files (including partially hydrated and non-hydrated files) are presented by the new OS image file system / driver, in some cases, as if they were fully hydrated (meaning they will be presented as if they are complete copies of the persistent / backup OS image, even though they are only placeholders and not complete copies).

[0059] At least with respect to the foregoing, the placeholder files of the present disclosure presented by the file system / driver (which are presented as complete copies / fully hydrated files) are distinct from sparse files, which are not presented as fully hydrated files.

[0060] The above representation of placeholder files (even if the metadata is inaccurate) and does not require the processing overhead of copying full files during imaging, however, is useful when considering that OS components may request this information during boot or initial / anticipated operation after boot, when determining whether a particular file has been created or has some attributes before continuing with the next process (even if the underlying data is not critical to the booting of the operating system and even if the underlying data is not required / requested).

[0061] In particular, by presenting placeholder files as fully hydrated (full copy) files, OS components that request information about particular placeholder files during boot and / or during initial processing after boot will be able to use the placeholder information (which may be erroneous) to perform their processing without imposing delays that would otherwise require making fully copied OS files rather than placeholder files generated from corresponding persistent OS image files (and / or without requiring all operating system files to be fully copied), and while still supporting booting of the OS and / or other predetermined set of OS functionality without requiring a full copy / (multiple) copies of the files in the persistent OS image.

[0062] As previously described, the monitoring agent 130 will rely on prior usage / behavior data and machine learning algorithms to pre-determine which files / portions of files are critical to booting the OS and providing a minimum set of OS functionality. In some cases, this minimum set of critical files / or file portions (i.e., the minimum set of OS data required to create a new OS image bootable by a computing system with a predetermined set of OS functionality) will include all of the files with data that is known to need to be accessed or accurately reported during boot time to avoid causing boot errors or other negative effects on the booting of the operating system and / or other errors in the expected execution of operating system processes within a short period of time after boot (e.g., within minutes, hours, or days after boot).

[0063] The list of the minimum data set (e.g., a set of critical files and / or file portions) is stored in a record maintained by the monitoring agent, which is stored locally and / or remotely and is accessed in response to receiving a request to image / re-image the operating system. Then, during the image / re-image process, the files / data comprising the listed minimum data set are copied from the persistent copy of the OS to the new OS file system. Optionally, placeholder files are also created for other files / data of the persistent copy of the OS, which files / data include the remaining data set determined to be unnecessary for creating a new OS image that is bootable with a predetermined set of OS capabilities.

[0064] With respect to the foregoing, it should be understood that the term file is broadly used to reflect an organized set of data accessible by a single file system handle (e.g., a file name) and typically includes an extension that reflects the file type. Non-limiting examples of files include audio files (e.g., mp3, wma, wav, etc.), video files (e.g., mp4, avim, mov, etc.), worksheet files (e.g., xlsx, odt, etc.), word processing and text files (e.g., docx, txt, etc.), system and kernel files (e.g., dll, dig, sys, etc.), mail and calendar files (e.g., pst, email, etc.), and / or code files (e.g., java, c, class, etc.). Files, as defined herein, in some alternative embodiments, even include groupings of other files (e.g., folders, subdirectories, or directories).

[0065] At some time during and / or after creating a new OS image, the file system creates a directory listing, index, or other type of data structure that can be used to navigate the file system's files and reflect the properties of the files in the file system, including fully hydrated / copied files, as well as placeholders.

[0066] Now turn your attention to Figure 2 , which illustrates an abstraction of an operating system element 200, including a file system 210 having files (e.g., files A, B, C, D, E, ...), and a file system directory list 220 that reflects the files and corresponding file attributes in the file system for the new operating system image. Figure 2 Also illustrated is a corresponding persistent OS image 230 in storage 240, with files copied / referenced during OS imaging, and remote storage 250 containing one or more files used by the file system to determine attributes for placeholder files. In some cases, the files of remote storage 250 include a copy of the persistent OS image.

[0067] As shown, files A, B, C, D, and E... are associated with the persistent OS image and are used to create a new OS image for use by the system and corresponding to the file system 210 shown. Directory listing 220 is a visualization of the file system directory and includes an entry for each referenced file and the corresponding file attributes. In this example, which is merely illustrative and non-exhaustive, the file attributes of the OS files tracked by the file system and referenced in the directory listing include: file path, handle / name, creation date / time, size, type, and various other attributes. Any combination of these attributes / metadata for a file can be requested by the file system / driver and can be presented by the file system / driver.

[0068] As previously discussed, in some cases, some metadata / attributes reflected in the files will not be accurate. This is especially true for placeholder files (e.g., files C, D, E) that are only partially hydrated (e.g., file C) or not hydrated (e.g., files D and E). The degree of hydration (e.g., as previously discussed, the terms hydrated and unhydrated refer to the relative amount of data copied into the file system file of the new OS image relative to the corresponding file of the persistent OS image). The amount of data copied into the files is reflected by the fill bar to the right of each file shown in file system 210, with the fill bars for files A and B being completely filled (fully hydrated), the fill bar for file C being partially filled (partially hydrated), and the fill bars for files D and E being completely empty or not filled (not hydrated).

[0069] In some cases, the directory listing 220 of the file system 210 is a data structure referenced by the file system / driver that is not reflected to the user in a visual interface. In some embodiments, the directory listing 220 includes a visual interface component that reflects the values ​​and file attributes of different files to the user of the computing system on the display of the computing system (not in the display). Figure 1 ). In some cases, the visual interface includes visual objects that reflect the hydration levels of different files, such as objects 222 (e.g., visual objects 223, 224, and 227) that include check boxes or other visual elements to reflect that the corresponding file (including a fully hydrated copy of the file), another type of visual element (e.g., visual object 225 including the letter "P" or another visual element) to reflect that the corresponding file is a partially hydrated placeholder file, and another type of visual element (e.g., visual object 226 including an "X" or another visual element) to reflect that the corresponding file is a completely unhydrated placeholder file. In other embodiments, colors, status bars, percentage values, or other elements are used to reflect and distinguish different types of fully copied files and placeholder files (e.g., partially hydrated files and / or unhydrated files).

[0070] In some cases, the visual interface inaccurately presents to the user that a file has been fully hydrated, similar to how the system presents file completion status to other OS components. For example, for file E, which is a non-hydrated placeholder file, the visual object 227 of the check box suggests / implies that the file has been fully loaded / copied to the file system, even though it has not. While this embodiment is not necessarily preferred, it is made at this time to reflect another way that the system can provide inaccurate information related to the copy / hydration status of placeholder files. However, this embodiment will be useful when the system makes such an inaccurate representation after determining that the file is not necessary or critical to any function called by the user, so that the user (when debugging a potential problem) will not attempt to fully hydrate the file by initiating a copy of the corresponding file from the persistent OS image 230 to the file system copy.

[0071] Now turn your attention to Figures 3 to 5 , which illustrates a flow chart of an example method implemented by a computing system, such as that described above with reference to Figure 1 and Figure 2 described, and associated with executing OS images using just-in-time file delivery ( Figure 3 ), a method for processing a request for a file in a re-imaged operating system, the operating system including at least one placeholder file that is only partially hydrated and / or unhydrated relative to a corresponding persistent copy of the file maintained in the operating system (operating system) and stored in persistent storage ( Figure 4 ), and methods for incrementally hydrating placeholder files from a re-imaged operating system that are only partially hydrated and / or unhydrated in persistent storage relative to corresponding persistent copies of the files maintained in a stored OS (operating system) image ( Figure 5 ).

[0072] As shown in the figure, by Figure 3 The method referenced by flowchart 300 includes an act of a computing system receiving a request to re-image the computing system's OS by creating a new OS image from a stored persistent OS image (act 310). This act includes identifying a stored persistent operating system image for re-imaging from within the computing system storage or from a remote system.

[0073] The computing system then identifies a minimum set of OS data required to create a new OS image bootable by the computing system with the predetermined set of OS capabilities from the stored persistent copy of the OS image (act 320), and identifies a remaining set of OS data not required for the new OS image bootable by the computing system with the predetermined set of OS capabilities from the persistent copy of the OS image (act 330). In some cases, the minimum set of OS data required is less than 50%, 60%, 70%, or 80% of the remaining set of OS data.

[0074] In some cases, action 320 includes utilizing the above reference Figure 1 Any of the techniques described herein determine a predetermined set of OS functions for a minimum set of OS data, and in some cases also include analysis of files / functions that have been recently and / or frequently called during boot of the OS and / or recently and / or frequently called within a predetermined time period after a previous boot of the OS on the computing system.

[0075] and Figure 3The illustrated actions of the method associated with flowchart 300 of the embodiment of the present invention further include, for the minimum set of required OS data, creating a new OS image by creating a replicated set of OS files in the file system from the stored persistent copy of the OS, the stored persistent copy being stored in the persistent storage and containing the minimum set of OS data (act 340). In addition, the computing system also creates placeholder files for the remaining OS data sets determined to be unnecessary (act 350), these files being unhydrated and / or only partially hydrated copies of associated OS files found in the stored persistent copy of the OS, wherein the unhydrated and partially hydrated copies omit at least some of the data from the associated OS files maintained in the stored persistent copy of the OS.

[0076] Then, as previously described, the computing system utilizes the new OS image to inaccurately present the one or more placeholder files to one or more OS components as fully hydrated files (act 360) (e.g., by presenting the placeholders as containing all of the data in the corresponding files maintained by the persistent copy of the operating system, even though they do not).

[0077] and Figure 3 The associated methods and many other disclosed methods are said to be able to reduce OS imaging time by using just-in-time (JIT) file delivery. The term JIT (Just In Time) is used to describe the on-demand nature provided by the disclosed embodiments, wherein files copied during OS imaging are copied just in time for their required functionality and / or just in time to avoid unnecessary processing burden. More specifically, during the initial imaging (only when needed), files in a minimum set of files determined to be critical to booting and intended operating system functionality are fully copied, while the remaining files are fully copied (only when needed) in response to requests for data and / or (just in time), thereby avoiding unnecessary burden on the computing system by waiting for available / unused bandwidth (just in time).

[0078] For example, some embodiments include methods for hydrating placeholder files by completing the data copy from the persistent OS image to the new OS image on demand and / or in response to detecting available bandwidth and / or in a particular priority order, while other embodiments include avoiding hydrating one or more placeholder files in response to determining that it is unnecessary.

[0079] Going further, Figure 4 The flowchart of illustrates the actions associated with processing a request for placeholder files / data and responding accordingly, so as to provide the requested data on demand and copy the requested data only when it is determined to be necessary, and by using the just-in-time techniques mentioned above. In addition, Figure 5Other actions related to the method of incrementally hydrating placeholder files using the just-in-time technique mentioned above are described.

[0080] For example, Figure 4 Flowchart 400 illustrates the actions of a computing system in response to receiving a request associated with specific data of a placeholder file that is only partially hydrated and / or unhydrated relative to a corresponding persistent copy of the file maintained in an OS (operating system) image stored in persistent storage (act 410). The system determines whether the type of request received requires actual access to the specific data (act 420) or only access to metadata for the file, for example. The system also determines whether the specific data has already been written to the placeholder file (act 430), for example, a file in the file system being evaluated.

[0081] Then, in response to determining that specific data is not written to the placeholder file and actual access to the specific data is required, the system accesses and copies the requested data from the maintained copy of the file and / or all data from the copy of the OS image in persistent storage to the placeholder file (action 440). In some cases, this will completely fill the placeholder file. In other cases, it will only partially fill the placeholder file.

[0082] Alternatively, in response to determining that the specific data does not need to be actually accessed from the placeholder file, the system avoids copying the specific data from the persistent copy of the file (found in the OS image copy in persistent storage) to the placeholder file of the new OS image (act 450). This may include, for example, determining that the request only requires metadata for the file and not the specific data contained in the file.

[0083] In this case, the system inaccurately presents the placeholder file to the requesting system component(s) as if the file had the specific data and was fully hydrated (act 460). This can be achieved, for example, by providing the requesting component(s) with accurate and / or inaccurate metadata for the file (e.g., the file's handle, file type, and file size).

[0084] After inaccurately presenting the placeholder file as a fully hydrated file, the system fully hydrates the placeholder file by copying the specific data from the copy of the operating system image in persistent storage (act 470), e.g., in response to a new request requiring access to the specific data and / or in response to a determination that the system is idle and / or has unused excess processing bandwidth and which is responsively allocated for copying.

[0085] Figure 5Flowchart 500 illustrates relevant actions for hydrating placeholder files. For example, the system first identifies a set of placeholder files for the file system that are partially hydrated and / or unhydrated relative to copies of corresponding files maintained in an OS (operating system) image stored in persistent storage (action 510). In some cases, the action is performed at any time after an initial set of files determined to be critical to booting an OS with minimal OS functionality is completely copied to a new OS image. In some instances, the action is performed in response to detecting idle processing of the computing system after the initial set of files is completely copied to the new OS image. In other embodiments, action 510 is performed in response to a specific user request to complete an image of the OS, but does not require the user to request access to specific data from any specific placeholder file.

[0086] Then, after and / or during the execution of act 510 , the system begins incrementally hydrating the plurality of placeholder files ( act 520 ).

[0087] In some cases, before any computer and / or user request for data associated with or omitted from the placeholder file is received, action 520 is performed to hydrate the particular file. This action may include, for example, detecting unused and available processing bandwidth of the computing system and utilizing the available processing bandwidth to hydrate multiple placeholder files by accessing and copying data from a persistent copy stored by the OS, without degrading the performance of other processes being executed by the computing system due to the hydration of the multiple placeholder files (action 522). It will be appreciated that this action will be an iterative process that, in some embodiments, goes through several suspend and resume phases in response to detected changes in the available processing bandwidth of the computing system, and in order to avoid competition / contention for the computing system's processing bandwidth, the processing of action 522 is performed only when it is determined that there is unused and available processing bandwidth for the processing directed to action 522.

[0088] Action 520 alternatively and / or additionally includes an associated action 524, which in some embodiments involves identifying relative preferences and / or priorities for hydrating a plurality of placeholder files based on historical usage and / or specified preferences, and then automatically performing incremental hydration of the placeholder files based on a set of preferences and / or priorities by accessing and copying data from a stored persistent copy of the OS to the plurality of placeholder files, the data being determined to be more highly preferred or associated with a relatively high priority than relatively lower priority data. Such priority determination is made by a monitoring agent, user input, file system, and / or third-party file system data associated with historical preference / usage data and / or explicit priority designations.

[0089] Although most of the embodiments described above refer to copying files of a new OS image and / or hydrating placeholder files in a new OS image from a persistent OS image maintained in local storage of a computing system having the OS being re-imaged, it should be understood that any files copied from the persistent OS image may be from local storage and / or to remote storage of the computing system where the OS image files are stored.

[0090] Furthermore, although the foregoing subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0091] like Figure 1 As referenced in the , the disclosed methods are implemented by a special purpose or general purpose computer including computer hardware, such as one or more processors (e.g., processor(s) 120) and system memory (e.g., contained in storage 115). Embodiments of the present invention also include the disclosed systems and physical and other computer-readable hardware memory or other computer-readable media for carrying or storing computer-executable instructions and / or data structures executable to implement the disclosed methods.

[0092] The computer-readable media referenced herein can be accessed and executed by a processor in a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions in the form of data are "physical computer storage media" or "hardware storage devices." Computer-readable media that carry computer-executable instructions are "transmission media." Thus, by way of example and not limitation, the present embodiments may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0093] Computer storage media (also known as "hardware storage devices") are computer-readable hardware storage devices such as RAM, ROM, EEPROM, CD-ROM, solid-state drive ("SSD") change memory ("PCM"), or other types of memory, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium, data or data structure for storing desired program code in the form of computer-executable instructions, accessed by a general-purpose or special-purpose computer.

[0094] As previously mentioned, the disclosed computer system can be connected to a remote device (via a wired or wireless connection) via a network that includes one or more data links and / or data switches that enable communication between the computer system, module, and / or other electronic device. When information is transmitted or provided to a computer via a network (wired, wireless, or a combination of wired and wireless), the computer properly considers the connection to be a transmission medium. Combinations of the foregoing should also be included within the scope of computer-readable media.

[0095] Upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures may be automatically transferred from a transmission medium to a computer storage medium (or vice versa). For example, computer-executable instructions or data structures received over a network or data link may be cached in RAM within a network interface module (e.g., a network interface card or "NIC") and then ultimately transferred to computer system RAM and / or to less volatile computer storage media within the computer system. Thus, it should be understood that computer storage media may be included in computer system components that also (or even primarily) utilize transmission media.

[0096] Computer-executable (or computer-interpretable) instructions include, for example, instructions that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or group of functions. For example, computer-executable instructions can be binary, intermediate format instructions (such as assembly language), or even source code.

[0097] Those skilled in the art will appreciate that the embodiments can be practiced in a network computing environment with various types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, pagers, routers, switches, etc. The embodiments can also be practiced in a distributed system environment, where local and remote computer systems linked by a network (by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) each perform tasks (e.g., cloud computing, cloud services, etc.). In a distributed system environment, program modules can be located in local and remote memory storage devices.

[0098] Without departing from the spirit of the present disclosure, the present invention may be implemented in other specific forms. The described embodiments should be considered in all respects to be illustrative only and restrictive. Therefore, the scope of the present invention is indicated by the appended claims, rather than by the previously described portion of the specification. Other changes within the meaning and equivalence of the claims should be considered to be included within their scope.

Claims

1. A computing system configured to execute an operating system (OS) image using just-in-time (JIT) file delivery, the computing system comprising: a hard drive having a stored hard drive copy of the OS, including a plurality of OS files; a file system configured to store the OS files; One or more file system filter drivers configured to receive a request for access to the OS file; one or more processors; as well as A method of storing computer-executable instructions executable by one or more processors to cause a computing system to execute an OS image using JIT file delivery, the method comprising: Identifying a minimum set of OS data required to create an OS image that is bootable with a predetermined set of operating system functions; identifying a remaining set of OS data determined to be unnecessary for at least creating the OS image bootable with the predetermined set of operating system functions; creating a replicated set of OS files in the file system from a storage hard drive copy of the OS containing the minimum set of OS data required; for remaining sets of the OS data determined not to be needed, creating placeholder files comprising unhydrated and / or only partially hydrated copies of associated OS files found on the hard drive where the OS is stored; inaccurately presenting the placeholder file as a fully hydrated file of the file system to one or more OS components; and After booting the operating system, the placeholder files are incrementally hydrated.

2. The system according to claim 1, wherein: The method further comprises: In response to detecting a read request for specific data associated with a placeholder file that is not in the placeholder file, accessing and copying the specific data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies.

3. The system according to claim 1, wherein: The method further comprises: In response to detecting a read request for specific data associated with a placeholder file in the placeholder file, avoiding accessing and copying the specific data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies until a request is made for additional data associated with the placeholder file that has not yet been copied to the placeholder file.

4. A system according to any one of the preceding claims, wherein: The method further comprises: detecting available processing bandwidth of the computing system; and In response to detecting available processing bandwidth of the computing system, incremental hydration of the placeholder files is automatically performed by accessing and copying data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies.

5. The system according to claim 1, wherein The method further comprises: In response to detecting a request to re-image the OS, executing the method; identifying a preference or priority set for specific data that has not been requested by or to the OS since the request to re-image the OS; and Based on the preference or priority set, incremental hydration of placeholder files is automatically performed by accessing and copying data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies, the data being determined to be of higher preference or associated with a relatively higher priority than relatively lower priority data.

6. The system according to claim 5, wherein: The preference or priority set is based on a historical log of frequency and / or recency of the data being copied, the historical log having been accessed by the OS prior to the request to re-image the OS.

7. The system according to claim 1, wherein: The one or more file system filter drivers present the placeholder file as a fully hydrated file to the one or more OS components.

8. The system of claim 2 or claim 5, wherein accessing and copying from the stored hard drive copy results in fully hydrating at least one previously unhydrated and / or only partially hydrated copy.

9. The system of claim 1 , wherein inaccurately rendering the placeholder file as a fully hydrated file comprises: A minimum set of file attributes required to be established and presented by the placeholder file in the file system is identified so that the one or more OS components view the placeholder file as a fully hydrated file.

10. The system according to claim 9, wherein: The placeholder file is different from a sparse file and cannot be detected as a sparse file by the OS component.

11. The system according to claim 1, wherein: The minimal set of OS data includes a minimal set of files, rather than just a limited and incomplete portion of a file.

12. The system of claim 1, wherein the method further comprises: At least some remote OS data is accessed from remote storage to hydrate at least one of the placeholder files at least in part with the remote OS data.

13. The system of claim 1 , wherein identifying a minimum set of OS data required to create the OS image bootable with the predetermined set of operating system functions comprises: At least one set of one or more application programs and application functions is identified, the at least one set having been recently and / or frequently used by one or more users of the computing system prior to receiving the request to re-image the operating system.

14. The system of claim 1, wherein a minimum set of the OS data required is less than 50% of a remaining set of the OS data determined not to be required.

15. A computer-implemented method of executing an operating system (OS) image using just-in-time (JIT) file delivery, the method comprising: Identifying a minimum set of OS data required to create an OS image that is bootable with a predetermined set of operating system functions; identifying a remaining set of OS data determined to be unnecessary for at least creating the OS image bootable with the predetermined set of operating system functions; creating a replicated set of OS files in the file system from a storage hard drive copy of the OS containing the minimum set of OS data required; for remaining sets of the OS data determined not to be needed, creating placeholder files comprising unhydrated and / or only partially hydrated copies of associated OS files found on the hard drive where the OS is stored; inaccurately presenting the placeholder file as a fully hydrated file of the file system to one or more OS components; as well as After booting the operating system, the placeholder files are incrementally hydrated.

16. The method according to claim 15, further comprising: In response to detecting a read request for specific data associated with a placeholder file that is not in the placeholder file, accessing and copying the specific data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies.

17. The method according to claim 15, further comprising: In response to detecting a read request for specific data associated with a placeholder file in the placeholder file, avoiding accessing and copying the specific data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies until a request is made for additional data associated with the placeholder file that has not yet been copied to the placeholder file.

18. The method according to claim 15, further comprising: detecting available processing bandwidth of the computing system; as well as In response to detecting available processing bandwidth of the computing system, incremental hydration of the placeholder files is automatically performed by accessing and copying data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies.

19. The method according to claim 15, further comprising: In response to detecting a request to re-image the OS, executing the method; identifying a preference or priority set for specific data that has not been requested by or to the OS since the request to re-image the OS; as well as Based on the preference or priority set, incremental hydration of placeholder files is automatically performed by accessing and copying data from the stored hard drive copy of the OS to one or more of the unhydrated and / or partially hydrated copies, the data being determined to be of higher preference or associated with a relatively higher priority than relatively lower priority data.

20. The method of claim 19, wherein the one or more file system filter drivers present the placeholder file as a fully hydrated file to the one or more OS components.

Images