HK1243785B - Virtual disk storage techniques - Google Patents

Description

Virtual disk storage technology

Background Art

Storage virtualization technology allows logical storage to be separated from physical storage. One exemplary use case for storage virtualization is within a virtual machine. A layer of virtualization software (often called a hypervisor or virtual machine monitor) is installed on a computer system and controls how the virtual machine interacts with the physical hardware. Because guest operating systems are typically coded to exercise exclusive control over the physical hardware, the virtualization software can be configured to subdivide the resources of the physical hardware and simulate the presence of physical hardware within the virtual machine. Another use case for storage virtualization is within a computer system configured to implement a storage array. In this scenario, the physical computer system or virtual machine can connect to the storage array using protocols such as iSCSI.

A storage manipulation module can be used to emulate storage on a virtual or physical machine. For example, the storage manipulation module can manipulate storage I/O tasks issued by a virtual or physical machine by reading and writing one or more virtual disk files (i.e., contiguous storage areas such as blocks) that can be used to describe (i.e., store) virtual disk extents. Similarly, the storage manipulation program can respond to write requests by writing virtual disk bit pattern data to one or more virtual disk files, and respond to read requests by reading the bit patterns stored in one or more virtual disk files.

Summary of the Invention

This document describes techniques for storing virtual disk data in one or more virtual disk files. In an exemplary configuration, a virtual disk extent can be associated with state information indicating whether the virtual disk extent is described by a virtual disk file. In certain circumstances, space used to describe a virtual disk extent can be reclaimed, and the state information can be used to determine how subsequent read and/or write operations directed to the virtual disk extent are handled. The reclaimed space (e.g., an extent created from one or more extents) can be used to describe the same or another virtual disk extent. In addition to the above, other techniques are described in the claims, detailed description, and figures.

Those skilled in the art will appreciate that one or more various aspects of the present disclosure may include, but are not limited to, circuits and/or programming for implementing the aspects referenced herein; the circuits and/or programming may be substantially any combination of hardware, software, and/or firmware configured to implement the aspects referenced herein based on the design choices of a system designer.

The above content is an overview and therefore necessarily contains simplifications, generalizations and omissions of details. Those skilled in the art will appreciate that the summary is illustrative only and is not intended to be limiting in any way.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 depicts a high-level block diagram of a computer system.

FIG2 depicts a high-level block diagram of an exemplary architecture of a virtualization software program.

FIG3 depicts a high-level block diagram of an alternative architecture for a virtualization software program.

4 depicts a low-level block diagram of a computer system configured to implement a virtual disk.

5A depicts a low-level block diagram of a computer system configured to implement a virtual disk.

5B depicts a low-level block diagram of a computer system configured to implement a virtual disk.

Figure 6 depicts a high-level block diagram of a differencing disk.

FIG7 depicts a high-level example of the relationship between a virtual disk and virtual disk files.

FIG8 depicts a high-level example of the relationship between a virtual disk and virtual disk files.

FIG9 depicts a high-level example of the relationship between a virtual disk and virtual disk files.

FIG10 depicts a high-level example of the relationship between a virtual disk and virtual disk files.

FIG11 depicts an operational flow that may be embodied in a computer-readable storage medium and/or performed by a computer system.

FIG12 depicts additional operations that may be performed in conjunction with those illustrated in FIG11.

FIG13 depicts additional operations that may be performed in conjunction with those illustrated in FIG12.

FIG14 depicts an operational flow that may be embodied in a computer-readable storage medium and/or performed by a computer system.

FIG15 depicts additional operations that may be performed in conjunction with those illustrated in FIG14.

FIG16 depicts an operational flow that may be embodied in a computer-readable storage medium and/or performed by a computer system.

FIG17 depicts additional operations that may be performed in conjunction with those illustrated in FIG16.

DETAILED DESCRIPTION

The disclosed subject matter may employ one or more computer systems. Figure 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the disclosed subject matter may be implemented.

The term "circuit," as used throughout this document, may include hardware components such as hardware interrupt controllers, hard drives, network adapters, graphics processors, hardware-based video/audio codecs, and the firmware used to operate such hardware. The term "circuit" may also include microprocessors, application-specific integrated circuits, and processors configured by firmware and/or software, such as the cores of a multi-core general-purpose processing unit that performs instruction fetching and execution. A processor may be configured by instructions loaded from memory (e.g., RAM, ROM), firmware, and/or mass storage, implementing logic operable to configure the processor to perform functions. In example embodiments where the circuit comprises a combination of hardware and software, the implementer may write source code implementing the logic, which is subsequently compiled into machine-readable code that can be executed by the hardware. As those skilled in the art will appreciate, the state of the art has evolved to the point where there is minimal difference between hardware-implemented and software-implemented functions. Therefore, the choice of hardware versus software to implement the functions described herein is merely a design choice. In other words, as those skilled in the art will appreciate, software processes can be transformed into equivalent hardware structures, and hardware structures themselves can be transformed into equivalent software processes. Therefore, the choice of hardware versus software implementation is left to the implementer's discretion.

Referring now to FIG. 1 , an exemplary computing system 100 is depicted. Computer system 100 may include a processor 102, e.g., an execution core. While a single processor 102 is illustrated, in other embodiments, computer system 100 may have multiple processors, e.g., multiple execution cores per processor substrate and/or multiple processor substrates each having multiple execution cores. As shown, various computer-readable storage media 110 may be interconnected via one or more system buses that couple various system components to processor 102. The system bus may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. In an example embodiment, computer-readable storage media 110 may include, for example, random access memory (RAM) 104, storage 106 (e.g., an electromechanical hard drive, a solid-state hard drive, etc.), firmware 108 (e.g., flash RAM or ROM), and removable storage 118 such as, for example, a CD-ROM, floppy disk, DVD, flash drive, external storage, and the like. Those skilled in the art will appreciate that other types of computer-readable storage media may be used, such as magnetic cassettes, flash memory cards, and/or digital video disks.

Computer-readable storage media 110 may provide non-volatile and volatile storage of processor-executable instructions 122, data structures, program modules, and other data for computer system 100, such as executable instructions. A basic input/output system (BIOS) 120, containing basic routines that help transfer information between elements within computer system 100 (e.g., during startup), may be stored in firmware 108. A number of programs may be stored on firmware 108, storage device 106, RAM 104, and/or removable storage device 118, and executed by processor 102, including an operating system and/or application programs. In an exemplary embodiment, computer-readable storage media 110 may store a virtual disk parser 404, described in more detail in the following paragraphs, which may be executed by processor 102 to transform computer system 100 into a computer system configured for a specific purpose, i.e., a computer system configured according to the techniques described in this document.

The computer system 100 can receive commands and information through input devices 116, which may include, but are not limited to, a keyboard and pointing device. Other input devices may include microphones, joysticks, game controllers, scanners, and the like. These and other input devices are often connected to the processor 102 via a serial port interface coupled to the system bus, but may also be connected via other interfaces such as a parallel port, a game port, or a universal serial bus (USB). A monitor or other type of display device may also be connected to the system bus via an interface such as a video adapter that may be part of or connected to the graphics processor unit 112. In addition to a monitor, computers typically include other peripheral output devices such as speakers and printers (not shown). The exemplary system of FIG. 1 may also include a host adapter, a small computer system interface (SCSI) bus, and external storage devices connected to the SCSI bus.

The computer system 100 can operate in a networked environment using logical connections to one or more remote computers (e.g., remote computers). A remote computer can be another computer, a server, a router, a network PC, a peer device, or other public network node, and can generally include many or all of the elements described above with respect to the computer system 100.

When used in a LAN or WAN networking environment, the computer system 100 can be connected to the LAN or WAN via a network interface card 114. The NIC 114, which can be internal or external, can be connected to the system bus. In a networked environment, program modules depicted relative to the computer system 100, or portions thereof, can be stored in remote memory storage devices. It will be appreciated that the network connections described herein are exemplary, and other means of establishing a communication link between computers can also be used. Furthermore, while it is contemplated that numerous embodiments of the present disclosure are particularly well-suited to computerized systems, nothing herein is intended to limit the present disclosure to such embodiments.

Turning to FIG. 2 , an exemplary virtualization platform that can be used to generate virtual machines is illustrated. In this embodiment, a microkernel hypervisor 202 can be configured to control and arbitrarily access the hardware of a computer system 200. The microkernel hypervisor 202 can generate execution environments called partitions, such as subpartition 1 through subpartition N (where N is an integer greater than 1). Here, a subpartition is the basic unit of isolation supported by the microkernel hypervisor 202. The microkernel hypervisor 202 can isolate processes in one partition from accessing resources in another partition. In particular, the microkernel hypervisor 202 can isolate kernel-mode code of a guest operating system from accessing resources in another partition and user-mode processes. Each subpartition can be mapped to a set of hardware resources under the control of the microkernel hypervisor 202, such as memory, devices, processor cycles, etc. In embodiments, the microkernel hypervisor 202 can be a stand-alone software product, part of an operating system embedded in the motherboard's firmware, an application-specific integrated circuit, or a combination thereof.

The microkernel hypervisor 202 can enforce partitioning by constraining the guest operating system's view of memory in the physical computer system. When the microkernel hypervisor 202 instantiates a virtual machine, it can allocate pages of system physical memory (SPM) (e.g., fixed-length blocks of memory with start and end addresses) to the virtual machine as guest physical memory (GPM). Here, the microkernel hypervisor 202 controls the guest-constrained view of system memory. The term guest physical memory is a concise way to describe memory pages from the perspective of the virtual machine, while the term system physical memory is a concise way to describe memory pages from the perspective of the physical system. Consequently, a page of memory allocated to a virtual machine will have both guest physical addresses (the addresses used by the virtual machine) and system physical addresses (the actual addresses of the pages).

A guest operating system can virtualize guest physical memory. Virtual memory is a management technique that allows the operating system to overcommit memory and grants applications independent access to logically contiguous working memory. In a virtualized environment, the guest operating system can use one or more page tables, referred to in this context as guest page tables, to translate virtual addresses (called virtual guest addresses) into guest physical addresses. In this example, a memory address can have a guest virtual address, a guest physical address, and a system physical address.

In the depicted example, the parent partition components, which can also be considered similar to Domain 0 of the Xen open source hypervisor, can include a host environment 204. Host environment 204 can be an operating system (or a set of configuration tools) that can be configured to provide resources to the guest operating systems executing in child partitions 1-N using a virtualization service provider (VSP). VSP 228, commonly referred to as a back-end driver in the open source community, can be used to multiplex interfaces to hardware resources via virtualization service clients (VSCs) (commonly referred to as front-end drivers in the open source community or in paravirtualized devices). As shown, the virtualization service clients execute within the context of the guest operating system. However, these drivers differ from the rest of the guest drivers in that they communicate with host environment 204 via the VSP, rather than with hardware or emulated hardware. In exemplary embodiments, the paths used by virtualization service provider 228 to communicate with virtual service clients 216 and 218 can be considered enlightened IO paths.

As shown, emulator 234 (e.g., a virtualized IDE device, a virtualized video adapter, a virtualized NIC, etc.) can be configured to run within host environment 204 and attach to emulated hardware resources available to guest operating systems 220 and 222, such as IO ports, guest physical address ranges, virtual VRAM, emulated ROM ranges, and the like. For example, when a guest OS touches a guest virtual address that is mapped to a guest physical address (where a device's register would be used for a memory-mapped device), microkernel hypervisor 202 can intercept the request and pass the value the guest is attempting to write to the associated emulator. Here, the emulated hardware resource in this example can be considered the location of the virtual device in the guest physical address space. Using the emulator in this manner can be considered an emulation path. This emulation path is less efficient than the heuristic IO path because it requires more CPU time to emulate the device than it does to pass messages between the VSP and VSC. For example, several actions on register-mapped memory are required to write a buffer to disk via the emulation path, but this is reduced to a single message passed from the VSC to the VSP in the heuristic IO path because the drivers in the VM are designed to access the IO services provided by the virtualization system rather than to access the hardware.

Each child partition can include one or more virtual processors (230 and 232), which the guest operating system (220 and 222) can manage and schedule threads executing on. Generally, a virtual processor is executable instructions and associated state information that provide a representation of a physical processor having a specific architecture. For example, one virtual machine may have a virtual processor that has the characteristics of an Intel x86 processor, while another virtual processor may have the characteristics of a PowerPC processor. The virtual processors in this example can be mapped to processors of the computer system so that instructions implementing the virtual processors will be executed directly by the physical processors. Thus, in embodiments including multiple processors, a virtual processor can be executed simultaneously by a processor while, for example, other processors execute hypervisor instructions. The combination of virtual processors and memory in a partition can be considered a virtual machine.

The guest operating systems (220 and 222) can be any operating system, such as, for example, operating systems from Microsoft®, Apple®, open source groups, and the like. A guest operating system can include user/kernel operating modes and can have a kernel, which can include a scheduler, a memory manager, and the like. Generally speaking, kernel mode can include an execution mode in a processor that grants access to at least privileged processor instructions. Each guest operating system can have an associated file system on which applications, such as a terminal server, an e-commerce server, an email server, and the like, can be stored, as well as the guest operating system itself. The guest operating system can schedule threads for execution on the virtual processors, which can implement instances of these applications.

Reference is now made to FIG3 , which illustrates an alternative virtualization platform to that described above in FIG2 . FIG3 depicts similar components to FIG2 ; however, in this example embodiment, hypervisor 302 may include a microkernel component and similar components as in host environment 204 of FIG2 , such as virtualization service provider 228 and device driver 224 , while management operating system 304 may include, for example, configuration tools for configuring hypervisor 302 . In this architecture, hypervisor 302 may perform the same or similar functions as microkernel hypervisor 202 of FIG2 ; however, in this architecture, hypervisor 304 implements heuristic IO paths and drivers for the physical hardware of the computer system. Hypervisor 302 of FIG3 may be a stand-alone software product, part of an operating system embedded in firmware on a motherboard, or a portion of hypervisor 302 may be implemented via an application-specific integrated circuit.

Turning now to FIG. 4 , which depicts a computer system 400 illustrating a high-level block diagram of components that may be used to implement the techniques described herein. Briefly, computer system 400 may include similar components as described above with respect to FIG. 1 through FIG. 3 . FIG. 4 illustrates a virtualization system 420 that may be viewed as a high-level representation of the virtualization platform illustrated in FIG. 2 or FIG. 3 . For example, virtualization system 420 may be viewed as a high-level representation of a combination of features provided by microkernel hypervisor 202 and host environment 204. Alternatively, virtualization system 420 may be viewed as a high-level representation of hypervisor 302 and management OS 304. Thus, throughout this document, the use of the term “virtualization system 420” means that the virtual disk techniques described in the following paragraphs may be implemented within any type of virtualization software layer or in any type of virtualization platform.

Virtualization system 420 may include an offload provider engine 422. Briefly, offload provider engine 422 may be configured to service offload read and offload write requests (sometimes referred to as proxy reads and proxy writes), for example, issued by application 424. An offload read request is a request to create a token representing the data that would have been read if the offload read were a normal read. An offload write is a request to write the data represented by the token to a destination. In one use case, an offload read followed by an offload write can be used to copy data from one location to another (e.g., from computer system 400 to a destination computer system within a domain using a token representing the data that avoids moving the data through local RAM). For example, assume that computer system 400 and a destination computer system (not shown) have access to a common data repository and a request is received to copy data from the computer system to the destination. Instead of copying the data to the destination, application 424 may request offload provider engine 422 to issue a token representing the data as it existed when the token was associated with the data. The token can be sent to the destination and used by a program running on the destination to retrieve data from the common data repository and write the data to the destination. Copy offload techniques are described in more detail in co-pending U.S. patent application Ser. No. 12/888,433, entitled “Offload Reads and Writes,” and U.S. patent application Ser. No. 12/938,383, entitled “Virtualization and Offload Reads and Writes,” the contents of which are incorporated herein by reference in their entirety to the extent they are consistent with the techniques described herein.

A virtual disk parser 404, which can be an executable instruction module in a specific example embodiment, can be used to instantiate a virtual disk from a virtual disk file and manipulate storage IO on behalf of a virtual machine. As shown, the virtual disk parser 404 can open one or more virtual disk files such as virtual disk file 406 and generate a virtual disk 402.

The virtual disk parser 404 can obtain the virtual disk file 406 from the storage device 106 via the virtualization system file system 408. In short, the virtualization system file system 408 represents a software module that organizes the computer files and data (e.g., virtual disk file 406) of the virtualization system 420. The virtualization system file system 408 can store this data in an array of fixed-size physical extents (i.e., contiguous storage areas on the physical storage device). In a specific example, an extent can be a cluster, which is a sequence of bytes of a set length. Exemplary cluster sizes are typically powers of two between 512 bytes and 64 kilobytes. In a specific configuration, the cluster size can be 4 kilobytes.

When a request to open a virtual disk file 406 is received, the virtualization system file system 408 determines where the file is located on disk and issues an IO task to the disk device driver to read data from one or more physical extents of the disk. The IO task issued by the file system 408 determines the disk offset and length that describes the location of the permanent copy of the virtual disk file 406 on the storage device 106 and issues the IO task to the storage device 106. Due to the semantics of how the storage device operates, the write IO task can be cached in one or more levels of volatile memory represented by cache memory 454 until the circuitry of the storage device 106 determines to access a location on a permanent storage unit 460 (e.g., a magnetic disk platter, a flash memory unit, etc.) and writes a cache bit pattern indicating the new contents of the permanent copy of the virtual disk file 406 to the permanent storage unit 460.

Virtual disk parser 404 can obtain a bit pattern indicative of virtual disk file 406 and expose the payload (e.g., user data) in virtual disk file 406 as a disk comprising multiple virtual disk extents. In one embodiment, these virtual disk extents can be fixed-size blocks ranging from 512 kilobytes to 64 megabytes in size and partitioned into multiple sectors; however, in another embodiment, the virtual disk extents can be variable-size extents. In an exemplary configuration, resources related to an emulated or heuristic storage controller and aspects of the emulation or heuristic are set up before launching guest operating system 412, such that the emulated storage controller with memory-mapped registers is implemented within the guest physical address space of virtual machine 410. Boot code can run and launch guest operating system 412. Virtualization system 420 can detect attempts to access this area of the guest physical address space and return a result that allows guest operating system 412 to determine that a storage device is attached to the emulated storage controller. In response, guest operating system 412 can load a driver (either a paravirtualized driver or a regular driver) and use the driver to issue storage I/O requests to the detected storage device. The virtualization system 420 may send the storage IO request to the virtual disk parser 404 .

After the guest operating system 412 is running, it can issue IO tasks to the virtual disk 402 via the file system 414. The file system is similar to the virtualization system file system 414 because it organizes the computer files and data of the guest operating system 412 and the applications installed on the guest operating system 412. The guest operating system 412 can interact with the virtual disk 402 in a manner similar to how the operating system interacts with the physical storage device and ultimately sends the IO tasks to the virtual disk parser 404. The virtual disk parser 404 can include logic for determining how to respond to the IO tasks in a manner that simulates a physical storage device. For example, the virtual disk parser 404 can read data from the virtual disk file 406 and write data to the virtual disk file 406. The data written to the virtual disk file 406 is then sent through the virtualization system file system 408 and delivered to the permanent copy of the virtual disk file 406 stored on or in the permanent storage unit 460.

Referring briefly to FIG5A , an alternative architecture for implementing the techniques described herein is illustrated. As shown in FIG5 , a virtual disk parser 404 can also be implemented in an operating system 502, such as an operating system provided by Microsoft®. In this example, the virtual disk parser 404 can be configured to run on a storage server 500, which can include components similar to the computer system 100 of FIG1 . In this example, the storage server 500 can include an array of physical storage devices 510 and can be configured to make the storage devices available to the server as if the storage devices were locally attached to the operating system 508. The virtual disk parser 404 can operate as described with respect to FIG4 ; differences in this configuration read/write IO tasks issued by the file system 414 can be sent to the virtual disk parser 404 over a network connection.

Referring briefly to FIG. 5B , yet another architecture for implementing the techniques described herein is illustrated. FIG. 5B is similar to FIG. 5A in that virtual disk parser 404 is implemented in operating system 502 and computer system 512 may include components similar to computer system 100 of FIG. 1 . However, the difference in this example is that the figure illustrates a loopback-attached virtual disk 402. A file system 414, including applications such as application 424, may be stored in virtual disk 402, and virtual disk files 406 may be stored in computer system file system 514.

Turning now to virtual disk 402, while it can be implemented using a single virtual disk file, in other configurations, a set of differencing virtual disk files can be used to implement virtual disk 402. FIG6 illustrates an exemplary chain of virtual disk files that can be used by virtual disk parser 404 to implement virtual disk 402 as a differencing disk. Generally, a differencing virtual disk file represents the current state of the virtual disk as a set of modified extensions compared to a parent image. The parent image can be another differencing virtual disk file or a base virtual disk file.

In an exemplary configuration, a link between a parent virtual disk file and a child virtual disk file can be stored within the child. Specifically, the child can include the identifier of the parent and a value describing the parent's location. When starting a virtual machine, the virtual disk parser 404 can receive information describing the last virtual disk file in the chain, i.e., virtual disk file 612 being the last in the chain including virtual disk files 612, 610, 606, and 600, and open this file. This file can include the identifier of its parent (i.e., virtual disk file 610) and the path to it. The virtual disk parser 404 can locate and open the parent, and so on, until the base virtual disk file is located and opened.

Virtual disk parser 404 can use information indicating whether data exists or is stored in a parent virtual disk file. Typically, the last virtual disk file in a chain is opened for read/modify, while other virtual disk files are opened for read only. Therefore, writes are typically performed to the last virtual disk file in the chain. Similarly, read operations target the last virtual disk file in the chain first. Virtual disk parser 404 will logically search virtual disk files in a logical order from last to first until the data is found, without caching information about where the data is located. In a specific example, a block allocation table (not shown) of a virtual disk file (e.g., virtual disk file 612) may include status information indicating whether a virtual disk extent is defined by a section of the virtual disk file or whether the virtual disk extent is transparent (e.g., defined by a different virtual disk file further along the chain). In one embodiment, virtual disk parser 404 may determine whether the virtual disk extent is transparent and access the block allocation table of the next virtual disk file in the chain (e.g., virtual disk file 610), and so on, until the virtual disk file in the chain defining the data is located.

Referring now to FIG. 7 , a virtual disk 402 is illustrated, at least in part, as described by a virtual disk file 702, which may be similar to any of the virtual disk files described in FIG. 6 (e.g., virtual disk files 602, 608, or 612, or a single virtual disk file) in a writable/modifiable manner. As shown, virtual disk 402 may include N storage extents (where N is an integer greater than 0), with 10 extents in this particular example. Virtual disk 402 is illustrated as including bit patterns of different files, distinguished by different patterns within the virtual disk extents, and data for guest operating system 412.

Because virtual disk 402 is not a physical storage device, the underlying payload data for a virtual disk extent can be "described" (i.e., stored in different sections within virtual disk file 702) by different sections within virtual disk file 702. For example, virtual disk extent 1 is described by a section defined by virtual disk file offset 0, or the first offset that can be used to store payload data. While computer system 400 is operating, allocation table 416, which can be stored in random access memory, can be maintained in any section of virtual disk file 702 and can span multiple sections. In short, allocation table 416 can include information linking virtual disk extents to sections of virtual disk file 702. For example, allocation table 416 can store information defining virtual disk file byte offsets that define sections of virtual disk file 702 where data is stored. Arrows represent relationships stored in allocation table 416.

As described in more detail in the following paragraphs, allocation table 416 may also include status information; however, this configuration is exemplary. In alternative configurations, this information may be stored in different sections of virtual disk file 702 and loaded into RAM 104. Allocation table 416 may include an entry for each virtual disk extent; status information indicating the status of each extent; and a file offset (not illustrated) indicating where each virtual disk extent is described in virtual disk file 702. In alternative embodiments, an extent may be defined by multiple table entries that are mapped and contiguous (in file offsets). In this configuration, reads and writes across block boundaries can be handled as a single read/write to virtual disk file 702, provided that block payloads are contiguous within the file. In a specific example, virtual disk parser 404 may also store information indicating what type of bit pattern is stored in each unused section of the virtual disk file, i.e., a free space map. In addition to the above, the free space map may be used by virtual disk parser 404 to determine which sectors of virtual disk file 406 are used and which are free. The free space map in this example can be configured to track free space in non-zero files. In the exemplary embodiment, because the non-zero portion of free space is used to describe a portion of virtual disk 402 (which must be zero or not disclose information from other virtual disk offsets), the free space is overwritten with zeros or a non-information-disclosing pattern (usually zeros), respectively. Virtual disk parser 404 can use this information to determine which sections of the virtual disk file are allocated to virtual disk extents. For example, if a virtual disk extent is written to and is in the zero state, virtual disk parser 404 can allocate sections that already have zeros in them to back up the virtual disk extent.

As the guest operating system 412 or operating system 508 runs, it will generate data and files and issue disk writes to the virtual disk 402 to store data. When the virtual disk file 702 does not have any additional unused space, the virtual disk parser 404 can extend the end of the file and use the new space to describe the virtual disk extents. The guest operating system 412 or operating system 508 can use, delete, and reuse segments of the virtual disk 402; however, because the virtual disk parser 404 only stores data on behalf of the file system 414, the virtual disk parser 404 may not be able to determine whether the guest operating system 412 is still using segments of the virtual disk file. As a result, the virtual disk parser 404 may hold allocated space in the virtual disk file 702 to describe virtual disk extents that are no longer in use by the file system 414. As a result, the size of the virtual disk file 702 will grow until it reaches the size of the virtual disk 402.

In an exemplary embodiment, virtual disk parser 404 can be configured to reclaim unused segments of a virtual disk file and optionally reuse them. This reduces the frequency with which the virtual disk file needs to be expanded, and reduces the overall size of the virtual disk file. In an exemplary embodiment, when the file system informs it that a virtual disk extent is no longer in use, virtual disk parser 404 can release (i.e., unlink) the virtual disk extent from the virtual disk file and associate the virtual disk extent with information describing how read operations on the virtual disk extent should be treated. The segments of the virtual disk file can subsequently be reused to describe the same or another virtual disk extent.

In an exemplary configuration, virtual disk parser 404 can use TRIM, UNMAP, and/or WRITE SAME commands issued by the file system to determine when to release virtual disk extents from virtual disk file 406. Guest operating system 412 or operating system 508 can issue TRIM commands. For example, as guest operating system 412 or operating system 508 runs, file system 414 can determine that some sectors are no longer needed and issue TRIM commands. Alternatively or in addition, virtual disk parser 404 can be configured to request file system 414 to issue TRIM commands at predetermined intervals or when predetermined criteria are met (e.g., when virtual machine 410 is instantiated, when virtual machine 410 is shut down, under minimal usage conditions, etc.).

In short, TRIM commands are used to inform the data storage device about which sectors are no longer considered for use so that the data storage device can optionally discard the data stored therein. One type of TRIM command, called a freespace TRIM command, can be used by the file system 414 to inform the file system 414 that a sector is no longer in use, while another, called a standard TRIM command, does not. The difference between the two types of TRIM commands is that when a sector is the subject of a freespace TRIM, the file system 414 provides security for the sector by preventing userspace applications, etc., from reading from it. The fact that the file system 414 ensures access to sectors trimmed in this manner can be exploited to increase the ability to efficiently allocate virtual disk file space. This particular aspect is described in more detail in the following paragraphs.

In an exemplary configuration, virtual disk parser 404 can be configured to perform a reclaim operation when a TRIM command completely overwrites a virtual disk extent. In other words, virtual disk parser 404 can delink the virtual disk extent from the virtual disk file in response to receiving a TRIM command that defines a virtual disk sector range that identifies all sectors in the virtual disk extent. In the same or alternative embodiments, when a TRIM command is received that overwrites a portion of a virtual disk extent, virtual disk parser 404 can determine what portion of the virtual disk file corresponds to the TRIM sector and send a TRIM command for the portion of the virtual disk file to storage device 106. In this instance, the underlying file system (e.g., virtualization system file system 408, storage server file system 504, or computer system file system 514) can translate the offset of the TRIM command and send the translated offset to storage device 106, reclaim the space directly via an internal data structure update, or purge the data from cache memory.

In the same or another embodiment, when a trim command is received that overwrites a portion of a virtual disk extent, virtual disk parser 404 can be configured to store information indicating what sectors were the subject of the trim command and whether the trim command was a free space trim. In the event that the remaining portion of the virtual disk extent is trimmed, virtual disk parser 404 can free the virtual disk extent from the virtual disk file.

When releasing a virtual disk extent, virtual disk parser 404 may associate the virtual disk extent with state information that describes how read operations directed to the virtual disk extent may be handled. Table 1 illustrates exemplary state information that virtual disk parser 404 may associate with a virtual disk extent and use to optimize the reclamation of virtual disk files. The ability to reclaim a virtual disk extent can be accomplished in one example using two states (described and not described); however, since the bit pattern stored in virtual disk file 702 is typically not erased when data is deleted, additional states may be used to determine when the space selected to describe the virtual disk extent needs to be cleared before it can be reused, or whether it can be reused without overwriting previously stored data therein. One reason for not erasing data after deletion is that it consumes processor cycles to erase the data, and since some storage devices are configured to perform write operations on a per-block basis, erasing data is more efficient when overwriting with new data. The following states are exemplary, and the disclosure is not limited to the states defined using the following table.

state describe Mapping This status indicates that the virtual disk extent is linked to the virtual disk file. transparent This status indicates that the virtual disk extent is defined by different virtual disk files. zero This state shows that virtual disk extension is not described by virtual disk file.In addition, this state shows that virtual disk extension is defined as zero and zero is meaningful. Unmapped This state indicates that the virtual disk extent is not described by a virtual disk file. In an embodiment, this state may include anchored and unanchored sub-states. Uninitialized This state shows that the virtual disk extension is not described by the virtual disk file and the virtual disk extension is defined as free space. In an embodiment, this state may also include anchored and unanchored substates.

Table 1.

7, the first state listed is a "mapped" state indicating that the virtual disk extent is described by a section of virtual disk file 702. For example, virtual disk extent 0 is an example virtual disk extent illustrated as being in the "mapped" state.

Continuing with the description of Table 1, a virtual disk extent may be associated with state information indicating that the virtual disk extent is "transparent" (i.e., the virtual disk extent is described by a different virtual disk file). If virtual disk parser 404 receives a read operation for a virtual disk extent in the transparent state, virtual disk parser 404 may refer to the different virtual disk file and check its allocation table to determine how to respond to the read. If virtual disk parser 404 receives a write to the virtual disk extent, virtual disk parser 404 may transition the virtual disk extent from the "transparent" state to the "mapped" state.

Continuing with the description of Table 1 in conjunction with FIG7 , a virtual disk extension can also be associated with an "unmapped" state. In this example, the virtual disk extension is not described by virtual disk file 702, nor is it described by any other virtual disk file in the chain. In this example, the unmapped state can be used to describe a virtual disk extension that has been subjected to a TRIM command that did not indicate that the file system 414 will ensure access to the virtual disk extension. In other words, the TRIM command used to transition the virtual disk extension to this state was a standard TRIM command. If a virtual disk extension is in the unmapped state and an IO task indicating a read of the extension is received, the virtual disk parser 404 can respond with a zero, a zero token, a one, a token indicating all ones, or a non-information-disclosing bit pattern (e.g., all zeros, all ones, or a randomly generated pattern of ones and zeros). In this example, if a segment of virtual disk file 702 is allocated to back a virtual disk extent in this state, virtual disk parser 404 can write a non-information-disclosing bit pattern to the segment of virtual disk file 702 before allocation, or select a segment that already includes a non-information-disclosing bit pattern to describe the virtual disk extent. Virtual disk extent 6 of FIG7 is indicated as being in an unmapped state.

In an embodiment, data defining unmapped or uninitialized extents can be retained, and the unmapped or uninitialized state can include two sub-states: anchored, meaning that the data still exists within virtual disk file 702, and unanchored, meaning that the data can or cannot be retained. Using these sub-states, virtual disk parser 404 can transition an unmapped but anchored extent to a mapped state by allocating extents storing data without zeroing the extents. Similarly, although virtual disk parser 404 is configured to treat uninitialized extents as if they were unmapped with respect to at least a portion of virtual disk 402, virtual disk parser 404 can avoid zeroing uninitialized but anchored extents during the transition of the extent to a mapped state by allocating extents storing data without zeroing the extents.

Table 1 additionally describes a "zero" state. In this example, the virtual disk extent is not described by virtual disk file 702 or any other virtual disk file in the chain; however, the virtual disk extent needs to be read as all zeros. In this example, the zero state can be used to describe a virtual disk extent that has been subjected to any type of TRIM command or to describe a virtual disk extent to which a program has written all zeros. For example, suppose a delete utility program writes all zeros to virtual disk extent 4 to ensure that its previously stored data is completely overwritten. If a virtual disk extent is in the zero state and an I/O task indicating a read of the extent is received, virtual disk parser 404 can respond with a zero or zero token (in an offload read operation). When writing to a virtual disk extent in this state, virtual disk parser 404 can zero a section of virtual disk file 702 and use it to describe the virtual disk extent, or select a section of virtual disk file 702 that is already zeroed and allocate it to support the virtual disk extent. In this embodiment, a data structure or virtual disk file 702 can be used to track zero space. The data structure may be updated periodically when the virtual disk file 702 is opened, when the virtual disk file 702 is closed, etc. Reading from an extent that is in an unmapped or uninitialized state may optionally cause the virtual disk parser 404 to transition the extent to a zero state in configurations where the virtual disk parser 404 is configured to provide sector stability for extents that are in an unmapped or uninitialized state.

Table 1 also describes a state called "Uninitialized." The Uninitialized state indicates that a virtual disk extent is not described by virtual disk file 702 and that file system 414 is ensuring access to the virtual disk extent. That is, file system 414 is configured to prevent user applications from reading sectors within this virtual disk extent. In this example, the Uninitialized state can be used to describe a virtual disk extent that has been subjected to a free space TRIM command. When a virtual disk extent is in the Uninitialized state and an IO task indicating a read request for the extent has been received, virtual disk parser 404 can respond with any data (i.e., a bit pattern from virtually any other location in virtual disk file 702, zeros, ones, non-information-disclosing bit patterns, etc.) because virtual disk parser 404 is not providing security for the virtual disk extent beyond the requirement that only virtual disk payload data and non-security-impacting metadata be exposed to virtual disk clients. When writing to a virtual disk extent in this state, virtual disk parser 404 can simply allocate an extent of virtual disk file 702 without modifying any data that may be stored within the extent. As a result, this state is the most beneficial because space can be allocated within the virtual disk file without having to clear it beforehand.The virtual disk extent 5 of Figure 7 is indicated as being in an uninitialized state, and the virtual disk file 702 is not supporting the virtual disk extent.

Once status information is associated with each virtual disk extent, virtual disk parser 404 can be configured to provide additional information to an administrator, etc., regarding how virtual disk 402 is arranged. In an example embodiment, virtual disk parser 404 can be configured to respond to offset queries that include certain parameters based on the status information. For example, a user can issue a query that begins iterating through virtual disk 402 at a given byte offset and locates ranges that meet specific criteria such as "mapped," "unmapped," "transparent," etc. Additionally, the user can select how "deep" the query should proceed to account for difference virtual disk file 702. For example, and referring to FIG. 7 , the user can set a depth of 2 and execute the query. In response, virtual disk parser 404 will execute a query on the last two virtual disk files in the chain (e.g., virtual disk files 610 and 612). Specific queries can include queries to obtain the next non-transparent range, the next non-zero range, the next defined range, the next initialized range, etc. In short, a query for a next defined range can be configured to return the next range containing defined data (e.g., a sector in a mapped or zeroed state, if a transparent sector resolves to the parent virtual disk file state for that sector). A query for a next initialized range can return the next range containing data in a state other than an uninitialized state, if a transparent sector resolves to the parent virtual disk file state for that sector.

Turning now to FIG. 8 , which illustrates a specific example of how virtual disk parser 404 may transition a virtual disk extent from one state to another in response to a file or other data being saved to virtual disk 402. For example, assume a user uses a database manager within virtual machine 410 and creates a database. The user may save the database in a file, and file system 414 may determine where to save file 802 on virtual disk 402. File system 414 may issue one or more disk writes to write file 802 to sectors falling within virtual disk extents 3-5, for example. In this example, virtual disk extent 3 is "mapped," and virtual disk parser 404 may write the first portion of file 802 to the sectors identified by allocation table 416.

On the other hand, virtual disk extents 4 and 5 are in a "zeroed" and "uninitialized" state. In this example, virtual disk parser 404 can select an unused section of virtual disk file 702 to support virtual disk extent 4 and determine that virtual disk extent 4 is in a zeroed state. In response to this determination, virtual disk parser 404 can zero out the section that was about to describe virtual disk extent 4 or locate a section that is already all zeros. After the process of locating or zeroing the section is complete, virtual disk parser 404 can generate information identifying a virtual disk file byte offset indicating the first byte of the section that describes virtual disk extent 4 as defined in virtual disk file 702, and store this information in allocation table 416. Virtual disk parser 404 can then change the state information associated with virtual disk extent 4 to indicate that it is "mapped." Writes to extent 4 can then be written to the located section.

Alternatively, for a portion of a write covering an entire extent of a virtual disk currently in a zeroed state, a positioned segment of the virtual disk file may be selected, the portion of the write may be issued to that segment, and after the write is complete, virtual disk parser 404 may subsequently change the state information associated with the virtual disk extent to indicate that the extent is "mapped." Alternatively, for a portion of a write covering only a portion of a virtual disk extent currently in a zeroed state, a positioned segment of the virtual disk file may be selected, the portion of the write may be issued to that segment, a zeroed write may be issued to the remainder of the segment, and after the write is complete, virtual disk parser 404 may subsequently change the state information associated with the virtual disk extent to indicate that the extent is "mapped." Those skilled in the art will recognize that a given ordering of writes may be enforced using flushes or write-through writes (e.g., force-unit-access writes).

Similarly, virtual disk parser 404 may select an unused section of virtual disk file 702 to support virtual disk extent 5 and determine, by referring to allocation table 416, that virtual disk extent 5 is in an uninitialized state. In response to this determination, virtual disk parser 404 may allocate a section to describe virtual disk extent 5 without modifying the contents of the selected section. Virtual disk parser 404 may generate information that identifies a virtual disk file byte offset indicating the first byte of the section, indicating where virtual disk extent 4 is described in virtual disk file 702, and store the file byte offset of the section in allocation table 416. Virtual disk parser 404 may then change the state information associated with virtual disk extent 5 to indicate that it is "mapped."

FIG9 illustrates another specific example of how virtual disk parser 404 can transition virtual disk extents from one state to another in response to a delete operation on file 802 and an operation to zero the contents of virtual disk extent 7. For example, a user may have deleted file 802, and file system 414 may have issued a TRIM command. In this example, virtual disk parser 404 may receive a TRIM command that includes a range of virtual disk sectors that completely encompasses virtual disk extents 4 and 5 and partially encompasses virtual disk extent 3. In response to determining that virtual disk extents 4 and 5 are completely trimmed, virtual disk parser 404 may be configured to remove the link from allocation table 416 and transition virtual disk extent 4 to a state indicating that virtual disk file 702 is not currently backing this virtual disk extent. As shown in the allocation table entry for virtual disk extent 4, the state to which virtual disk parser 404 transitions the virtual disk extent depends on the state virtual disk parser 404 is configured to use and whether file system 414 issued a free space TRIM command or a standard TRIM command. For example, virtual disk parser 404 can be configured to use two states: mapped and zero to describe virtual disk extensions. Alternatively, virtual disk parser 404 can be configured to use three states: mapped, zero, unmapped to describe virtual disk extensions. Alternatively, virtual disk parser 404 can be configured to use four states: mapped, zero, unmapped, and uninitialized. The difference between unmapped and uninitialized corresponds to the difference between standard trimming and free space trimming. If the parser is configured not to use the uninitialized state, free space trimming is treated as normal trimming. As shown, parts of file 702 are still stored in virtual disk file 702, which is inefficient because it is cleared from virtual disk file 702.

Because the TRIM partially covers virtual disk extent 5, virtual disk parser 404 can manipulate this extent in one of various ways. In one configuration, virtual disk parser 404 can leave extent 5 in a mapped state. In this configuration, virtual disk parser 404 can transform an extent when TRIM information is received for the entire extent. Alternatively, virtual disk parser 404 can track TRIM information that partially covers an extent, if it is desirable to receive more TRIM information that indicates that space describing the extent can be freed.

Similarly, the trimming also partially covers the virtual disk extension. In this example, the virtual disk parser 404 can leave it in the mapped state and can also be configured to send trim information describing the portion of the virtual disk file 702 that is no longer in use to the underlying file system (e.g., the virtualized file system 408, the storage server file system 504, or the computer system file system 514).

In addition to the deletion of file 802, FIG9 illustrates an example of zeroing a virtual disk extent. Virtual disk parser 404 may scan for IO tasks issued by file system 414 indicating that the entire extent of virtual disk extent 7 should be zeroed. In response to this determination, virtual disk parser 404 may be configured to remove the link from extent allocation table 416 and transition virtual disk extent 7 to a zeroed state. As shown, the previous contents of virtual disk extent 7 are still stored in virtual disk file 702.

Turning to FIG. 10 , a virtual disk 402 is illustrated, at least in part, as described by a set of virtual disk files 1002, 1004, and 1006 (which may be similar to the chain of virtual disk files defined by virtual disk files 608, 604, and 600). In this exemplary embodiment, the data representing virtual disk 402 is spread across multiple virtual disk files. In this exemplary embodiment, when virtual disk parser 404 attempts to read virtual disk extents 1 and 2, virtual disk parser 404 may access the allocation table of virtual disk file 1002 and determine that these extents are transparent. Next, virtual disk parser 404 may access the allocation table of virtual disk file 1004 and determine that these extents are transparent. Finally, virtual disk parser 404 may access the allocation table of grandparent virtual disk file 1006 and determine that these virtual disk extents are defined.

The following is a series of flow charts depicting operational flows. For ease of understanding, the flow charts are organized such that the initial flow chart presents an embodiment from an overall "big picture" perspective, while subsequent flow charts provide further additional content and/or details illustrated by dashed lines. Furthermore, those skilled in the art will appreciate that operational flows depicted by dashed lines are considered optional.

Referring now to FIG. 11 , an operational flow for reclaiming space within a virtual disk file is illustrated, including operations 1100 , 1102 , 1104 , and 1106 . Operation 1100 begins the operational flow, and operation 1102 illustrates instantiating ( 1102 ) a virtual disk ( 402 ) including virtual disk extents, detaching the virtual disk extents from the virtual disk file. Briefly referring to FIG. 4 , FIG. 5A , or FIG. 5B , a virtual disk parser 404 (e.g., executable instructions and associated instance data) can instantiate virtual disk 402 , exposing data stored within one or more virtual disk files as a logical hard drive that can be configured to handle read/write operations from file system 414 by emulating the behavior of a hard drive. Virtual disk files 406 (which can be one or more files as illustrated in FIG. 6 ) can store content typically found on a physical hard drive, i.e., disk partitions, file systems, etc. Turning to FIG. 7 , virtual disk 402 is illustrated as including multiple extents, with some of the extents detached from any section of virtual disk file 702 .

In this specific example, assume that the extents are blocks. In this instance, an allocation table 416, which can be loaded into random access memory from one or more extents in virtual disk file 702, can be used to store information linking disk blocks in virtual disk 402 to extents of the virtual disk file 702 (e.g., block size). Allocation table 416 can also store status information for each virtual disk block in virtual disk 402. Virtual blocks that potentially contain non-zero data can be associated with status information indicating that the block is in a mapped state. That is, an extent of virtual disk file 702 is allocated to describe a block of virtual disk 402 (i.e., to store data for the virtual disk 402 block). Examples of blocks in this state are virtual disk blocks 0-3 and 7. As shown in the figure, virtual disk blocks 4 and 5, 6, 8, and 9 can be valid virtual disk blocks; however, these virtual disk blocks do not have any space allocated within virtual disk file 702. Because file system 414 may write to these blocks, in an exemplary embodiment, these virtual disk blocks may be associated with information that may be used by virtual disk parser 404 to determine how to respond to read and/or write operations thereto.

Referring briefly back to FIG. 11 , operation 1104 illustrates that the computer system may additionally include circuitry that allocates, based on state information associated with the virtual disk (402), sections (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) of the virtual disk file to describe a virtual disk extent without overwriting a pre-existing bit pattern within the sections of the virtual disk file. For example, and returning to FIG. 8 , the virtual disk parser 404 may receive an IO task to write to a portion of a virtual disk extent. In response to receiving the write IO task, the virtual disk parser 404 may examine the allocation table 416 and determine that space within the virtual disk file 702 has not been allocated to describe the virtual disk extent and allocate sections of the virtual disk file 406 to support the virtual disk extent. Consequently, the virtual disk parser 404 may store the data written by the file system 414 to the virtual disk extent in the sections of the virtual disk file 702.

In this example, virtual disk parser 404 does not overwrite any data already stored in the section of virtual disk file 702 (by writing all zeros, ones, or any other non-information-disclosing bit pattern) before using it to describe the virtual disk extent based on the status information in allocation table 416. In the exemplary configuration, because the file system free space covers the virtual disk extent, the status information can indicate that the file system 414 is ensuring access to this virtual disk extent. In a specific example, the status information can indicate that the virtual disk extent is in an "uninitialized" state. Allocating the virtual disk extent without clearing it provides the additional benefit of saving processor cycles and IO work that would otherwise be used to overwrite the section of virtual disk file 702.

In the specific example of operation 1104, and turning to FIG7 , assume that the extent is a block and file system 414 sends an IO task to virtual disk 402 to write a bit pattern indicative of file 802 to virtual disk blocks 3-5. In response to receipt of such an IO task, virtual disk parser 404 may determine that virtual disk block 5 is not backed by any extent of virtual disk file 406 and uninitialize it. In response to this determination, virtual disk parser 404 may be configured to allocate an extent of virtual disk file 702 to describe virtual disk block 5 and write therein a portion of the bit pattern indicative of file 802 without overwriting data previously stored in the portion of the extent not covered by the IO task.

Turning again to FIG. 11 , operation 1106 illustrates that the computer system may additionally include circuitry configured to modify ( 1106 ) state information associated with virtual disk extents to indicate that the virtual disk extents are described by virtual disk files. For example, and returning to FIG. 8 , virtual disk parser 404 may modify (e.g., overwrite in memory) state information associated with virtual disk extent 5 to reflect that virtual disk file 702 is describing the virtual disk extent. In one configuration, the writing and modification of state information may occur simultaneously. For example, virtual disk parser 404 may store information in allocation table 416 indicating that virtual disk extent 5 is "mapped." Consequently, subsequent read operations targeting sectors of virtual disk extent 5 will be handled by virtual disk parser 404 by returning the bit pattern stored at the byte offset identified in allocation table 416. The virtual disk parser 404 can simultaneously write data (e.g., a bit pattern associated with the write operation that triggered this process) to the extent of the virtual disk file 702 allocated to describe the virtual disk extent and issue an IO task to the virtualization system file system 408, the storage server file system 504, or the computer system file system 514 to write the bit pattern to the extent of the virtual disk 702. At some point in time, such as until a subsequently issued flush command is completed, the bit pattern will be maintained in the persistent storage unit 460.

Turning now to FIG. 12 , additional operations that may be performed in conjunction with those illustrated in FIG. 11 are illustrated. Turning to operation 1208 , the computer system may include circuitry for responding to an offset query command by identifying information about non-zero virtual disk sectors, sectors of virtual disks in a non-transparent state, sectors of virtual disks in a mapped state, and/or sectors of virtual disks in an initialized state. For example, virtual disk parser 404 may be configured to receive a command to generate information about virtual disk 402, such as the next byte offset on the virtual disk in a non-transparent state (i.e., a state other than transparent), a mapped state (i.e., a sector of virtual disk 402 that includes data in virtual disk file 406), a defined state (i.e., a sector of virtual disk 402 that is mapped or zeroed), and/or an initialized state (i.e., a state other than uninitialized), given a starting byte offset. The command may be depth limited in that only a certain number of virtual disk files are checked, and any ranges that remain transparent after checking the certain number of virtual disk files, in addition to the range indicated by the status query (regardless of which status query is requested), are reported back to the requester. In response to receipt of such a command, virtual disk parser 404 may start at an initial byte offset on virtual disk 402 and build a response range or set of ranges until the range associated with the command is detected and the desired information is returned.

Continuing with the description of FIG. 12 , operation 1210 illustrates sending a request to a file system (414) controlling a virtual disk file (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) to issue at least one command selected from a command group consisting of a trim command, an unmap command, a write same of zero command, and a zero token offload write command. Referring back to FIG. 4 , FIG. 5A , or FIG. 5B , virtual disk parser 404 may be configured to issue a request to file system 414. The request in this example may be for file system 414 to issue a trim command. For example, virtual disk parser 404 may periodically issue one or more requests to file system 414 shortly after instantiation of virtual disk 402 and/or before virtual machine 410 is shut down, hibernated, or the like. In response to such a request, file system 414 can determine which sectors of virtual disk 402 it no longer uses and send one or more TRIM commands identifying these unused sectors to virtual disk parser 404. Virtual disk parser 404 can thus receive TRIM information such as a list of sector ranges that are no longer used by file system 414 and whether file system 414 is blocking reads from the ranges of sectors to ensure access to those sectors. Virtual disk parser 404 can receive the information and transition the virtual disk extents covered by the ranges into a state where space within virtual disk file 702 can be reclaimed.

Continuing with the description of FIG. 12 , operation 1212 illustrates that the computer system may include circuitry for, in response to receiving a request to trim a portion of a second virtual disk extent, determining a portion of a virtual disk file corresponding to the portion of the second virtual disk extent; and circuitry for sending a trim command for the determined portion of the virtual disk file to a file system configured to store the virtual disk file in a storage device. For example, and referring to FIG. 8 , file system 414 may issue a trim command that identifies a portion of a virtual disk extent. For example, the trim command may identify only a range of sectors corresponding to a portion of sectors forming one or more virtual disk blocks. In a specific example, assume that file system 414 trims space used to store file 802. Thus, the trim command may identify only a portion of sectors forming virtual disk extent 3. In this example, virtual disk parser 404 may determine that the range of sectors encompasses a subsection of the virtual disk extent and, using mapping information in allocation table 416, determine the portion of virtual disk file 702 corresponding to the trimmed sectors of the virtual disk extent. The virtual disk parser 404 may issue a request to the virtualization system file system 408 or the storage server file system 504 to trim the portion of the virtual disk file 702 corresponding to the trim sectors of the virtual disk extent. The virtualization system file system 408 or the storage server file system 504 may be configured to use and benefit from the trim command by trimming a portion of the sectors backing the virtual disk file 406, flushing data from the cache memory, clearing internal buffers, and the like.

Alternatively, virtual disk parser 404 may store information indicating that a portion of the virtual disk extent was trimmed and whether it was a free space trim. As guest operating system 412 or operating system 508 executes, it may eventually zero or trim the remaining portion of the virtual disk extent. In response to this event, virtual disk parser 404 may determine to transition the virtual disk extent to a state not described by virtual disk file 702 and select a state based on how different portions of the virtual disk extent were trimmed or zeroed. Virtual disk parser 404 may be configured to select the most restrictive state to transition the virtual disk extent to when different portions of the virtual disk extent may be placed in different undescribed states, with the zero state being the most restrictive, uninitialized being the least restrictive, and unmapped being somewhere in between. For example, if the first portion is zeroed and the remaining portion is uninitialized, virtual disk parser 404 may transition the entire virtual disk extent to the zero state.

Continuing with the description of FIG12, operation 1214 illustrates that computer system 400 may additionally include circuitry configured to, in response to receiving a request to trim a sector range encompassing a virtual disk extent, release the virtual disk extent from the extent of the virtual disk file and modify state information associated with the virtual disk extent to indicate that the virtual disk extent has no associated space within the virtual disk file. For example, and returning to FIG9, virtual disk parser 404 may remove a link in allocation table 416 that ties the virtual disk extent to the extent of virtual disk file 702. This operation has the effect of detaching the virtual disk extent from virtual disk file 702. In addition to removing the link, virtual disk parser 404 may modify state information associated with the virtual disk extent to indicate that the extent has no associated space within virtual disk file 702. That is, virtual disk parser 404 may place the virtual disk extent in an unmapped, uninitialized, or zeroed state.

Virtual disk parser 404 can remove links and update status information in response to receiving a request to trim or zero sectors of a virtual disk extent. For example, a request to trim or zero sectors can be received that identifies a range of byte offsets that can cover one or more virtual disk extents. In response to receiving such an IO task, virtual disk parser 404 can determine that the request covers sectors of the virtual disk extent and perform the aforementioned operations for removing links and updating status information.

In a specific example, assume that the IO task indicates that the trim is a free space trim. For example, a user may have deleted file 802, which is stored as a bit pattern on virtual disk extents 3-5, and file system 414 may indicate that file system 414 no longer uses this space. In response to receiving the free space trim command, virtual disk parser 404 may access allocation table 416 and determine that file system 414 has trimmed extents 3, 5, and all of extent 4. In this example, virtual disk parser 404 may remove the link that maps virtual disk extent 4 to virtual disk file 702 and modify the state information associated with virtual disk extent 4 to indicate that the virtual disk extent is uninitialized. This section of virtual disk file 702 can now be reused to support other virtual disk extents. In addition, virtual disk parser 404 may determine that virtual disk extents 3 and 5 are the subject of a partial trim command. In this example, the virtual disk parser 404 can use the allocation table 416 to discover the virtual disk file byte offset that describes the portion of the virtual disk file 702 (the portion that describes the trimmed portion of virtual disk extents 3 and 5) and issue a trim command describing the virtual disk file byte offset to the virtualization system file system 408, the storage server file system 504, or the computer system file system 514.

In another specific example, assume that file system 414 issues an IO task indicating that file 802 should be zeroed. For example, file 802 may be a database file storing sensitive information, such as credit card numbers and administrators. The administrator is determined to zero out the file contents by writing all zeros to the file contents. This is accomplished by issuing a write command to an all-zero buffer that will write zeros over the existing data in file 802. In response to receiving this IO task, virtual disk parser 404 may be configured to determine that virtual disk extent 4 should be zeroed out and that this extent may be reclaimed. In this example, virtual disk parser 404 may remove the link that maps virtual disk extent 4 to virtual disk file 702 and modify the state information associated with virtual disk extent 4 to indicate that the virtual disk extent should be zeroed out. This section of virtual disk file 702 can now be reused to support other virtual disk extents, and virtual disk parser 404 may respond to subsequent read operations on virtual disk extent 4 by replying with all zeros.

In another specific example, rather than overwriting the data stored therein, a user may write a batch of zeros to initialize the state of file 802. In this example, the extent may be transitioned to a zero state using commands such as a TRIM command when virtual disk parser 404 reports a trimmed segment read as zero, an UNMAP command when virtual disk parser 404 reports an unmapped area as zero, a WRITE SAME OF ZERO command, and/or a ZERO TOKEN UNLOAD WRITE command.

In a specific example, assume that the IO task indicates that the trim is a standard trim. For example, a user may have deleted file 802, which is stored as a bit pattern on virtual disk extents 3-5; however, the trim command cannot indicate whether file system 414 is using the space. In response to receiving the standard trim command, virtual disk parser 404 can access allocation table 416 and determine that file system 414 has trimmed extents 3, part of extent 5, and all of extent 4. In this example, virtual disk parser 404 can remove the link that maps virtual disk extent 4 to virtual disk file 702 and modify the state information associated with virtual disk extent 4 to indicate that the virtual disk extent is unmapped or is zeroed. This section of virtual disk file 702 can now be reused to describe other virtual disk extents. In addition, virtual disk parser 404 can determine that virtual disk extents 3 and 5 are the subject of a partial trim command. In this example, virtual disk parser 404 can use allocation table 416 to discover the virtual disk file byte offset (which constitutes the portion of virtual disk file 702 that describes the trimmed portion of virtual disk extents 3 and 5) and issue a trim command to virtualization system file system 408 that specifies the virtual disk file byte offset (typically in the form of a range).

Referring now to FIG. 13 , additional operations that may be performed in addition to operation 1214 of FIG. 12 are illustrated. Operation 1316 illustrates that a computer system may include circuitry for receiving a request to write data to a virtual disk extent; circuitry for zeroing unused segments of a virtual disk file based on status information associated with the virtual disk extent, the status information indicating that the virtual disk extent is to be zeroed; and circuitry for allocating unused segments of the virtual disk file to describe the virtual disk extent. Referring to the context of FIG. 9 , virtual disk parser 404 may receive a request to write data to a virtual disk extent (e.g., virtual disk extent 4 of FIG. 9 , which in this example is associated with status information indicating that the virtual disk extent is to be zeroed). For example, virtual disk parser 404 may have determined that the virtual disk extent is to be zeroed when virtual disk extent 4 is freed, i.e., an application writes all zeros to file 602 via an offload write using a well-known zero token.

In response to determining that the virtual disk extent is in a zeroed state, virtual disk parser 404 can identify an unused section of virtual disk file 702 (i.e., a section not actively used to describe the virtual disk extent and not actively used to store any allocated metadata) and use that section to support the virtual disk extent. Virtual disk parser 404 further ensures that any reads of unwritten sectors from the newly allocated extent are read as all zeros. Virtual disk parser 404 can write the payload of the IO write task to that section; update status information to indicate that the virtual disk extent is mapped; and update information in allocation table 416 to describe the virtual disk file byte offset that identifies the start of the section used to store virtual disk extent 4. Virtual disk parser 404 can also create a log entry that ensures that in the event of a system failure and restart before flushing writes, unwritten sectors of the newly allocated extent are still read as all zeros, and written sectors of the newly allocated extent are read as all zeros or written data. After the first subsequent flush command, virtual disk parser 404 ensures that a system failure following flush completion will result in reading from previously written sectors of the newly allocated extents reading written data, and reading from unwritten sectors of the newly allocated extents reading zeros.

Continuing with the description of FIG. 13 , operation 1318 illustrates that the computer system may include circuitry for receiving a request to write to a virtual disk extent; and circuitry for allocating an unused section of the virtual disk file to describe the virtual disk extent without modifying the contents of the unused section of the virtual disk file based on state information associated with the virtual disk extent, indicating that the file system is ensuring access to the virtual disk extent. Referring again to the context of FIG. 9 , virtual disk parser 404 may receive an IO task to write data to a virtual disk extent (e.g., virtual disk extent 4 of FIG. 9 , which in this example is associated with state information indicating that file system 414 is providing security for the virtual disk extent). In response to detecting this state information, virtual disk parser 404 may identify an unused section of virtual disk file 702; write the payload of the IO task to the section; update the state information to indicate that the virtual disk extent is mapped; and update information in allocation table 416 to describe a virtual disk file byte offset identifying the beginning of the section used to store virtual disk extent 4.

Assume in this example that the extent is a block and the I/O task's payload only covers a portion of the sectors in the virtual disk block. Specifically, the virtual disk block may be 512 kilobytes, and the write may cover the first 500 sectors of the virtual disk block. In this example, virtual disk parser 404 can write data to the first 500 sectors of the allocated section of virtual disk file 702 without erasing the data stored in the remaining 524 sectors. Therefore, if this section is examined, the first 500 sectors will contain the payload, while the remaining 524 sectors will contain whatever bit pattern was previously written to the section of virtual disk file 702. In this example, virtual disk parser 404 can use this section without clearing it because file system 414 is configured to reject read operations on sectors in file system free space. Since the application will be prevented from reading the remaining 524 sectors of the virtual disk block, it may contain any data previously stored on the virtual disk.

Turning now to operation 1320 of FIG. 13 , it is shown that the computer system can be configured to include circuitry for receiving a request to write to a virtual disk extent; circuitry for logically overwriting an unused section of the virtual disk file using a non-disclosure bit pattern based on status information associated with the virtual disk extent, the status information indicating that the file system has not properly ensured access to the virtual disk extent; and circuitry for allocating an overlay section of the virtual disk file to describe the virtual disk extent. Referring again to the context of FIG. 9 , virtual disk parser 404 can receive a request to write data to a virtual disk extent that, in this example, is associated with status information indicating that the file system 414 has not properly ensured access to the virtual disk extent. For example, virtual disk parser 404 may have freed the virtual disk extent in response to receiving a standard TRIM command and may store status information in allocation table 416 indicating that the virtual disk extent is unmapped (i.e., not backed by space in virtual disk file 702).

In response to determining that the virtual disk extent is unmapped, virtual disk parser 404 may identify an unused section of virtual disk file 702 to be used to describe the virtual extent and logically write a non-information-disclosing bit pattern to the section to ensure that reading the virtual disk extent does not inadvertently leak any information. In a preferred embodiment, the non-information-disclosing bit pattern may be all zeros or previously stored data. After zeroing the section or logically writing some other non-information-disclosing bit pattern (such as previously stored data) to the section, virtual disk parser 404 may logically write the payload of the IO task to the section; update status information to indicate that the virtual disk extent is mapped; and update information in allocation table 416 to describe the virtual disk file byte offset that identifies the beginning of the section used to store the virtual disk extent.

Continuing with the description of FIG. 13 , operation 1322 illustrates that the computer system may include circuitry configured to send a token representing zero to a requestor in response to receiving an offload read request associated with a virtual disk extent based on status information indicating zeroing the virtual disk extent. For example, and referring to FIG. 4 , offload provider engine 422 (e.g., circuitry configured to service offload read and offload write commands) may send a token representing zero to a requestor (e.g., application 424) in response to an offload read request issued by the requestor. Offload read requests can be used to efficiently copy data from one location to another by generating and sending a token to the requestor, the token representing the requested data, rather than copying the data to the requestor's memory and then sending the data to the destination. Offload read and offload write commands can be used to achieve copy offload when the destination recognizes the token generated by the source and can logically write the data represented by the token to the destination. In the case of a well-known zero token generated by the source, the destination does not need to access underlying storage, such as storage device 106, which in this embodiment may be a SAN target. In this example, the offload read request can be to perform an offload read operation on one or more files having data stored in one or more virtual disk extents, one of which is associated with state information indicating that the virtual disk extent is to be zeroed. In this example, the offload read request can be serviced by generating a well-known zero token value and returning the well-known zero token to the requester.

The offload read request may be sent to the offload provider engine 422. The offload provider engine 422 may receive the request and send a message to the virtual disk parser 404 for the data stored in the virtual disk extent. The virtual disk parser 404 may receive the request, read the status information for the virtual disk extent, and determine, in this specific example, that the status information indicates that the virtual disk extent is to be zeroed. The virtual disk parser 404 may send a message back to the offload provider engine 422 indicating that the virtual disk extent is all zeros. The offload provider engine 422 may generate a well-known token value indicating that the requested data is all zeros (e.g., a range of sectors describing a virtual disk block is all zeros) and send the well-known zero token to the requester.

In a specific example, the offload request can be forwarded to the SAN rather than being processed by computer system 400, storage service 500, or computer system 512. In this example, the SAN can generate a token and return it to virtual disk parser 404, which can then send a zero token to the requester. In another example, when offload provider engine 422 receives a message indicating that the virtual disk extent is all zeros, offload provider engine 422 can generate a well-known zero token that effectively logically copies the requested zero data to a separate area associated with the token by identifying the data as equivalent to any other zero data and sharing the area associated with the well-known zero token. In the event that offload provider engine 422 subsequently receives an offload write specifying the token previously sent to the requester, offload provider engine 422 can logically copy the data from the area associated with the token to the offset specified by the requester.

Turning now to FIG. 14 , an operational flow for reclaiming virtual disk file space is illustrated, including operations 1400 , 1402 , 1404 , and 1406 . As shown, operation 1400 begins the operational flow, and operation 1402 illustrates that a computer system may include circuitry for receiving a signal indicating that a portion of a virtual disk extent is no longer in use, the virtual disk extent being a portion of a virtual disk ( 402 ) stored in a virtual disk file. For example, and turning to FIG. 4 , virtual disk parser 404 may be configured to instantiate virtual disk 402. File system 414 may send a signal to virtual disk parser 404 indicating that it is no longer using a portion of virtual disk 402 (i.e., a range of sectors of a virtual disk extent). In a specific example, the signal may be a TRIM command. In a specific example, the signal received by virtual disk parser 404 may identify a byte offset value defining a range of sectors that are no longer in use (which may be the first portion of a virtual disk extent).

Continuing with the description of FIG. 14 , operation 1404 illustrates that the computer system may further include circuitry configured to identify a portion of a virtual disk file ( 406 , 600 , 602 , 604 , 606 , 608 , 610 , 612 , 702 , 1002 ) that describes a virtual disk extent. Referring back to FIG. 7 , virtual disk parser 404 may receive a signal and identify a virtual disk byte offset value for, for example, the first portion of virtual disk extent 0. In response to receiving the signal, virtual disk parser 404 may check allocation table 416 to determine the portion of virtual disk file 702 corresponding to the virtual disk byte offset value associated with the signal.

Turning now to operation 1406 of FIG. 14 , it is shown that the computer system may include circuitry for sending a request to a file system configured to store virtual disk file (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) on a storage device to trim an identified portion of virtual disk file (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002). For example, and referring again to FIG. 7 , virtual disk parser 404 may determine that the signal identified is less than the entire virtual disk extent. For example, the signal may indicate that the range of sectors does not include all sectors of the virtual disk extent. In response to this determination, virtual disk parser 404 may issue a request to a file system hosting virtual disk file 702 (e.g., virtualization system file system 408) to trim the portion of virtual disk file 702 corresponding to the trimmed portion of the virtual disk extent. The virtualized system file system 408 may be configured to use and benefit from the trim command by trimming virtual disk files 406, flushing data from cache memory, clearing internal buffers, sending trims to disks storing file system data, and the like.

In a specific example, virtual disk parser 404 can be configured to issue a trim command to the underlying file system in response to determining that a request to trim a portion of a virtual disk file does not encompass the entire extent. For example, assume that a signal identifies that the first 600 sectors of a virtual disk extent are no longer in use and virtual disk parser 404 can determine that the first 600 sectors of the virtual disk extent are less than the 1024 sectors that constitute the virtual disk extent. In response to this determination, virtual disk parser 404 can access allocation table 416 and determine the virtual disk file byte offset that describes the first 600 sectors of the virtual disk file 702 section that describes the virtual disk extent, and send a request to the file system hosting virtual disk file 702 to trim this portion of virtual disk file 702.

Turning now to FIG. 15 , additional operations that may be performed in conjunction with those depicted in FIG. 14 are illustrated. Turning now to operation 1508 , the computer system may additionally include circuitry for sending ( 1508 ) a token representing zero to a requestor in response to receiving an offload read request associated with the virtual disk extent, based on state information indicating zeroing the virtual disk extent. For example, and referring back to FIG. 4 , the offload provider engine 422 (e.g., circuitry configured to service offload read and offload write commands) may send a token representing zero to a requestor (e.g., application 424) in response to an offload read request issued by the requestor. Offload read requests can be used to efficiently copy data from one location to another by generating and sending a token to the requestor, the token representing the requested data, rather than copying the data to the requestor's memory and then sending the data to the destination. The offload read and offload write commands can be used to implement copy offload when the destination recognizes the token generated by the source and can logically write the data represented by the token to the destination. In the case of a well-known zero token generated by the source, the destination does not need to access the underlying storage, for example, storage device 106, which in this embodiment may be a SAN target. In this example, the offload read request may be to perform an offload read operation on one or more files having data stored in one or more virtual disk extents, one of which is associated with state information indicating that the virtual disk extent is zeroed. In this example, the offload read request may be serviced by generating a well-known zero token value and returning the well-known zero token to the requester.

Continuing with the description of FIG. 15 , operation 1510 illustrates that the computer system may include circuitry for selecting ( 1510 ) a subgroup from a group of virtual disk files; and circuitry for generating ( 1510 ) information identifying sectors of the subgroup including data and sectors of the transparent subgroup. In an exemplary embodiment, virtual disk 402 may be instantiated from multiple virtual disk files. Or, in other words, virtual disk 402 may be formed from M virtual disk files (where M is an integer greater than 1). In this exemplary embodiment, virtual disk parser 404 may be configured to receive a request from, for example, an administrator to determine the next byte offset on virtual disk 402, starting at a given byte offset, that is associated with a sector defined within a subgroup of virtual disk files. For example, and referring to FIG. 10 , virtual disk parser 404 may receive a request for a next defined byte offset starting at a virtual disk offset corresponding to the first sector of virtual disk extent 2 and information indicating that the subgroup includes virtual disk file 1002 and virtual disk file 1004. In this example, virtual disk parser 404 may begin scanning through the subgroups and determine that the next defined byte offset is the sector corresponding to the start of virtual disk extent 3. Since, in this example, the data in virtual disk extent 2 is backed by sectors of virtual disk file 1006, it is outside the seek and not returned as defined.

Continuing with the description of FIG. 15 , operation 1512 illustrates that the computer system may include circuitry configured to, in response to determining to zero a virtual disk extent, detach the virtual disk extent from the virtual disk file (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) and modify state information associated with the virtual disk extent to indicate that the virtual disk extent has been zeroed. For example, and turning to FIG. 7 , in an embodiment, virtual disk parser 404 may determine to zero a virtual disk extent. For example, virtual disk parser 404 may receive a request to write data represented by a well-known zero token to a virtual disk extent (e.g., virtual disk extent 7). Virtual disk parser 404 may determine, based on a data structure associated with the request, that the request is for the entire virtual disk extent, i.e., the byte offset value may begin at the first sector of extent 7 and end at the last sector of extent 7. In response to this determination, and instead of writing zeros to the corresponding section of virtual disk file 702, virtual disk parser 404 can be configured to remove the link that maps virtual disk extent 7 to the section of virtual disk file 702 that describes virtual disk extent 7, and associate the virtual disk extent with information indicating that the virtual disk extent is all zeros. For example, virtual disk parser 404 can write eight bytes of information in allocation table 416 indicating that the virtual disk extent consists of all zeros. The net result of this operation is that even if the portion of the virtual disk file that bit-by-bit describes the extent does not exist, the section of virtual disk file 702 can be reused to store data for other virtual disk extents, and the virtual disk extent will be read as if it consisted of all zeros.

Continuing with the description of FIG. 15 , operation 1514 illustrates that the computer system may additionally include circuitry configured to, in response to the file system determining that the virtual disk extension is considered free space, detach the virtual disk extension from the virtual disk file and modify state information associated with the virtual disk extension to indicate that the virtual disk extension is free space. For example, and referring again to FIG. 7 , virtual disk parser 404 may determine that file system 414 has associated the virtual disk extension with information indicating that it is free space (i.e., space not used by file system 414). For example, virtual disk parser 404 may receive a signal from file system 414 indicating that a range of sectors encompasses a virtual disk extension (e.g., virtual disk extent 3) and information indicating that the sectors are considered free space. In response to receiving this signal, virtual disk parser 404 may be configured to remove information linking the virtual disk extension to the extent of virtual disk file 702. As a result, the extent of virtual disk file 702 can be reused to store data for other virtual disk extensions. Virtual disk parser 404 can additionally associate the virtual disk extent with information indicating that the virtual disk extent includes arbitrary data (i.e., data previously stored in any portion of the virtual disk, all zeros, or all ones). As a result, read operations directed to the virtual disk extent can be manipulated by returning the arbitrary data previously stored in the virtual disk. Furthermore, if virtual disk parser 404 is configured to allow the arbitrary data to change each time a read operation is received, the arbitrary data can optionally change each time a read operation is received.

Continuing with the description of FIG. 15 , operation 1516 illustrates that the computer system may additionally include circuitry configured to, in response to determining that a virtual disk extent has been pruned, detach the extent from the virtual disk file and modify state information associated with the virtual disk extent to indicate that the virtual disk extent includes a non-disclosure bit pattern. For example, and referring again to FIG. 7 , virtual disk parser 404 may determine that file system 414 has pruned the range of sectors comprising the virtual disk extent. In response to this determination, virtual disk parser 404 may remove information from allocation table 416 that links the virtual disk extent to the extents of virtual disk file 702. This operation results in the extents of virtual disk file 702 being reusable to store data for other virtual disk extents. Virtual disk parser 404 may additionally associate the virtual disk extent with information indicating that the virtual disk extent includes a non-disclosure bit pattern (e.g., all zeros, ones, or a randomly generated bit pattern). Consequently, read operations directed to the virtual disk extent can be manipulated by returning the non-disclosure bit pattern. In a preferred embodiment, the non-disclosure bit pattern may be all zeros. However, this differs from the zero state described above in that the zero state can be used to represent meaningful zeros (ie, situations where the virtual disk is intentionally extended to zero).

Referring to operation 1518, it is shown that the computer system may additionally include circuitry configured to send (1518) a request to the file system (414) controlling the virtual disk to issue a trim command. Referring back to FIG. 7, the virtual disk parser 404 may be configured to issue a request to the file system 414 to issue one or more trim commands. In an exemplary configuration, the virtual disk parser 404 may be configured to send such a request periodically or based on predetermined criteria, for example, when the VM 410 starts or shortly before shutting down the VM. In response to such a request, the file system 414 may issue one or more trim commands to the virtual disk parser 404 to identify unused sectors of the virtual disk 402. The virtual disk parser 404 may then receive trim information from the trim command, such as the sector range that the file system 414 no longer uses and, optionally, information indicating whether the trimmed sectors are considered free space. The virtual disk parser 404 may receive the information and use it to update state information stored in the allocation table 416 and possibly reclaim unused sections of the virtual disk file 702.

Turning now to FIG. 16 , an operational flow for storing virtual machine data is illustrated. The operational flow begins at operation 1600 and transitions to operation 1602 , which describes a scenario in which a computer system may include circuitry for executing ( 1602 ) a guest operating system ( 220 , 222 , 412 , 518 ) including a file system within a virtual machine. For example, and with reference to FIG. 4 , virtualization system 420 (which may be a combination of the functions performed by hypervisor 302 or host environment 204 of FIG. 3 and microkernel hypervisor 202 of FIG. 2 ) may instantiate virtual machine 410 and run a guest operating system (e.g., guest operating system 412) therein. In this example, guest operating system 412 may include file system 414 , which may be executable instructions for organizing and controlling data for guest operating system 412 .

Continuing with the description of FIG. 16 , operation 1604 illustrates that the computer system may include circuitry for exposing ( 1604 ) a virtual storage device ( 402 ) to a guest operating system ( 220 , 222 , 412 , 508 ), the virtual storage device ( 402 ) including a virtual disk extension, separating the virtual disk extension from the virtual disk file. Returning to FIG. 4 , the virtualization system 420 may expose the virtual disk 402 to the guest operating system 412. For example, the virtual disk parser 404 may communicate with a storage virtualization service provider, which may be operable to communicate with a storage virtualization service client running within the guest operating system 410. In a specific example, the storage virtualization service client may be a driver installed within the guest operating system 412 that notifies the guest that it can communicate with the storage device. In this example, IO tasks sent by the file system 414 are first sent to the storage virtualization service client and then to the storage virtualization service provider via a communication channel (e.g., a memory region and cross-partition notification facility). One or more virtual disk files 406 opened by virtual disk parser 404 and used to store data for virtual disk 402 may constitute virtual disk 402. In a specific example, virtual disk 402 may be at least partially described by virtual disk file 702 of FIG. 7 . In another specific example, and turning to FIG. 10 , virtual disk 402 may be described by a set of virtual disk files (1002-1006). In either case, and returning to FIG. 4 , virtual disk 402 may include multiple virtual disk extents, and one of the virtual disk extents may be detached, i.e., not described bit-by-bit by any space within its associated virtual disk file.

Continuing with the description of FIG16, operation 1606 shows that the computer system may include circuitry for receiving (1606) a request to write data to a virtual disk extent. Returning to FIG7, virtual disk parser 404 may receive a request to write data to a virtual disk extent that does not have associated space in virtual disk file 702. For example, an IO task may be received that specifies an offset value indicating a virtual disk sector address within the virtual disk extent.

Returning to FIG. 16 , operation 1608 illustrates that the computer system may optionally include circuitry for determining ( 1608 ) that status information associated with the virtual disk extent indicates that the virtual disk extent is free space. In response to receiving the IO task, virtual disk parser 404 may access allocation table 416 and read the status information associated with the virtual disk extent. In this example, the virtual disk extent may be associated with information indicating that the virtual disk extent is free space (i.e., the virtual disk extent is not being used by file system 414 and a read operation on the virtual disk extent may be responded to with any data).

16 , operation 1610 illustrates that the computer system may optionally include circuitry for allocating ( 1610 ) a section of a virtual disk file ( 406 , 600 , 602 , 604 , 606 , 608 , 610 , 612 , 702 , 1002 ) to describe a virtual disk extent without overwriting a pre-existing bit pattern within the section of the virtual disk file. For example, and returning to FIG. 7 , in response to receiving a write IO task, virtual disk parser 404 may locate a section in virtual disk file 702 that is not currently in use and allocate it to store data for the virtual extent. For example, virtual disk parser 404 may write information in allocation table 416 linking the virtual disk extent to the byte offset value of the allocated section of virtual disk file 702.

In this example, because the state information indicates that the file system 414 has identified virtual disk extent 5 as free space, the virtual disk parser 404 does not overwrite any existing bit patterns (e.g., data from some deleted files and/or arbitrary data) stored in the extent of the virtual disk file 702 before using the extent to describe the virtual disk extent (by writing all zeros, ones, or any other non-information-disclosing bit patterns). This provides the added benefit of saving processor cycles and IO work that would otherwise be used to overwrite the extents of the virtual disk extent.

Referring to operation 1612 of FIG. 16 , it is shown that the computer system may optionally include circuitry for modifying ( 1612 ) state information associated with the virtual disk extent to indicate that the virtual disk extent is mapped to the allocated segment of the virtual disk file. For example, and returning to FIG. 7 , virtual disk parser 404 may modify (e.g., overwrite in memory) state information associated with the virtual disk extent to indicate that it is mapped. As a result, subsequent read operations directed to sectors of the virtual disk extent will be handled by virtual disk parser 404 by returning the bit pattern stored in the corresponding portion of the allocated segment.

Turning now to operation 1614 of FIG16 , which illustrates storing 1614 the data in the allocated section of the virtual disk file. Returning to FIG6 , the virtual disk parser 404 can write the data (i.e., the bit pattern) to the virtual disk file 702. An IO task indicating the write to the virtual disk file 702 can be issued to the virtualization system file system 408, and ultimately the change can be maintained by the permanent storage unit 460.

Turning now to FIG. 17 , it illustrates additional operations that may be performed in conjunction with those illustrated in FIG. 16 . Turning attention to operation 1716 , it illustrates that the computer system may optionally include circuitry for, in response to determining to zero the virtual disk extent, detaching the virtual disk extent from the virtual disk file and modifying state information associated with the virtual disk extent to indicate that the virtual disk extent has been zeroed. For example, and also turning to FIG. 6 , in one embodiment, virtual disk parser 404 may determine that the virtual disk extent has been zeroed. For example, virtual disk parser 404 may receive an offload write request to write data represented by a well-known zero token to a virtual disk extent (e.g., virtual disk extent 7). Virtual disk parser 404 may determine, based on a data structure associated with the request, that the request is for the entire virtual disk extent, i.e., the byte offset value may begin at the first sector of virtual disk extent 7 and end at the last sector of virtual disk extent 7. In response to this determination, and instead of writing zeros to the corresponding segment of virtual disk file 702, virtual disk parser 404 can be configured to remove the link from the virtual disk extent to the segment of virtual disk file 702 stored in allocation table 416 and associate the virtual disk extent with information indicating that the virtual disk extent is all zeros.

Continuing with the description of FIG17, operation 1718 shows that the computer system may optionally include circuitry for, in response to receiving a signal from the file system 414 identifying the virtual disk extension as free space, detaching the virtual disk extension from the virtual disk file 406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) and modifying state information associated with the virtual disk extension to indicate that the virtual disk extension includes any data. For example, and returning again to FIG7, the virtual disk parser 404 may determine that the file system 414 has associated the virtual disk extension with information indicating that it is free space (i.e., space not used by the file system 414). For example, the virtual disk parser 404 may receive a signal from the file system 414 indicating a range of sectors encompassing the virtual disk extension (e.g., virtual disk extent 3) and information indicating that the sectors are free space. In response to this determination, virtual disk parser 404 can be configured to remove information in allocation table 416 linking the virtual disk extent to the section of virtual disk file 702 and to associate the virtual disk extent with information indicating that any data (i.e., data previously stored in any portion of the virtual disk, all zeros, or all ones) can be returned in response to receipt of a read IO task.

Operation 1720 of FIG. 17 illustrates that computer system 400 may optionally include circuitry for, in response to receiving a request to trim all sectors of a virtual disk extent, detaching the virtual disk extent from virtual disk file (406, 600, 602, 604, 606, 608, 610, 612, 702, 1002) (1720) and modifying state information associated with the virtual disk extent to indicate that the virtual disk extent includes a non-information-disclosing bit pattern. For example, and returning to FIG. 7 , virtual disk parser 404 may determine that the sectors comprising the virtual disk extent have been trimmed. For example, virtual disk parser 404 may receive a trim command from file system 414 indicating a range of sectors encompassing the virtual disk extent. In response to receiving this signal, virtual disk parser 404 may be configured to remove information in allocation table 416 linking the virtual disk extent to the section of virtual disk file 702 and associate the virtual disk extent with information indicating that the virtual disk extent includes the non-information-disclosing bit pattern.

The above detailed description describes various embodiments of the system and/or process by way of examples and/or operational diagrams. To the extent that such block diagrams and/or examples include one or more functions and/or operations, those skilled in the art will understand that each function and/or operation within such block diagrams or examples may be implemented individually and/or collectively by a wide range of hardware, software, firmware, or substantially any combination thereof.

While particular aspects of the subject matter described herein have been shown and described, it will be obvious to those skilled in the art, based on the teachings herein, that changes and modifications may be made without departing from the subject matter described herein and its broader aspects, and therefore, the appended claims are intended to cover within their scope all such changes and modifications as come within the true spirit and scope of the subject matter described herein.

Claims (20)

1. A storage device comprising computer-executable instructions that, when executed by a processor, cause the processor to perform the following operations: Based on the state information associated with the virtual disk separated from the virtual disk file, without overwriting pre-existing bit patterns within the segments of the virtual disk file, the segments of the virtual disk file are allocated to describe the virtual disk expansion; and Modify the status information associated with the virtual disk extension to indicate that the virtual disk extension is described by the virtual disk file. 2. The storage device of claim 1, further comprising instructions that, when executed, cause the processor to perform the following operations: The offset query command is responded to by recognizing at least one of the following: Sectors of a non-zero virtual disk Sectors of a virtual disk in a non-transparent state Sectors of a virtual disk in a mapped state, or The sectors of a virtual disk in the initialization state. 3. The storage device of claim 1, further comprising instructions that, when executed, cause the processor to perform the following operations: Send a request to the file system controlling the virtual disk file to issue at least one command selected from a group of commands including: Trim command Unmapped commands Write to zero command, and Zero-token unload write command. 4. The storage device of claim 1, further comprising instructions that, when executed, cause the processor to perform the following operations: Identify a portion of the virtual disk file corresponding to a portion of the second virtual disk; A trim command is sent to the file system, which is configured to store the virtual disk file on a storage device, for the determined portion of the virtual disk file. 5. The storage device of claim 1, further comprising instructions that, when executed, cause the processor to perform the following operations: In response to receiving a request to trim the sector range including the virtual disk extension, the virtual disk extension is separated from the segment of the virtual disk file, and the status information associated with the virtual disk extension is modified to indicate that the virtual disk extension does not have associated space in the virtual disk file. 6. The storage device of claim 5, further comprising instructions that, when executed, cause the processor to perform the following operations: Receive a request to write data to the virtual disk. Based on status information associated with the virtual disk expansion, the unused portion of the virtual disk file is set to zero, whereby the status information indicates that the virtual disk expansion is set to zero; and Allocate the unused segments of the virtual disk file to describe the virtual disk extension. 7. The storage device of claim 5, further comprising instructions that, when executed, cause the processor to perform the following operations: Receive a request to extend the write to the virtual disk; and Allocate unused sections of the virtual disk file to describe the virtual disk expansion without modifying the contents of the unused sections of the virtual disk file. 8. The storage device of claim 5, further comprising instructions that, when executed, cause the processor to perform the following operations: Receive a request to write to the virtual disk extension; based on status information associated with the virtual disk extension, overwrite unused sections of the virtual disk file using a non-information disclosure bit mode, the status information indicating that the file system is not securing access to the virtual disk extension; and allocate overwrite sections of the virtual disk file to describe the virtual disk extension. 9. The storage device of claim 5, further comprising instructions that, when executed, cause the processor to perform the following operations: In response to the receipt of an unload read request associated with the virtual disk expansion, a zero token is sent to the requester based on state information indicating that the virtual disk expansion is zero. 10. A computer system, comprising: Processor; and Memory, coupled to the processor, including instructions that, when executed by the processor, cause the computer system to perform: Receive a signal indicating that a portion of the virtual disk extension is no longer in use; Identify a portion of a virtual disk file that describes a portion of the virtual disk extension, the virtual disk file being a member of a set of virtual disk files that together form a virtual disk including the virtual disk extension; Send a request to a file system configured to store the virtual disk file in a storage device to trim the identified portion of the virtual disk file; Select a subgroup from the set of virtual disk files; Generate information identifying the sectors of the subgroup containing data and the sectors of the transparent subgroup; and The virtual disk extension is separated from the virtual disk file, and the status information associated with the virtual disk extension is modified so that when the file system considers the virtual disk extension to be free space, it indicates that the virtual disk extension includes free space. 11. The computer system of claim 10, wherein identifying the portion of the virtual disk file comprises: Receive virtual disk byte offset value; and The allocation table is checked to determine a portion of the virtual disk file corresponding to the virtual disk byte offset value. 12. The computer system of claim 10, wherein the memory further includes instructions that, when executed, cause the computer system to perform the following operations: Remove information from the sections that extend the virtual disk to the virtual disk file. 13. The computer system of claim 12, wherein the segment of the virtual disk file is reused to store data from other virtual disk extensions. 14. The computer system of claim 10, wherein the memory further includes instructions that, when executed, cause the computer system to perform the following operations: The virtual disk extension is associated with information indicating that the virtual disk extension includes arbitrary data. 15. The computer system of claim 14, wherein any data comprises at least one of the following: Data stored in any part of the virtual disk; Data representing all zeros; or Data that represents all ones. 16. A method implemented for a computer storing data in a virtual machine, comprising: Expose a virtual storage device to a guest operating system, the virtual storage device including a virtual disk extension detached from a virtual disk file; Receive a request to extend the write data to the virtual disk; When the virtual disk extension includes free space, the segment of the virtual disk file is allocated to describe the virtual disk extension without overwriting the pre-existing bit pattern within the segment of the virtual disk file. Modify the status information associated with the virtual disk extension to indicate that the virtual disk extension is mapped to the allocated segment of the virtual disk file; and The data is stored on the allocated segment of the virtual disk file. 17. The method of claim 16, further comprising: when the virtual disk extension is reduced to zero, separating the virtual disk extension from the virtual disk file and modifying state information associated with the virtual disk extension to indicate that the virtual disk extension has been reduced to zero. 18. The method of claim 16, further comprising: in response to receiving a signal from a file system that identifies a virtual disk extension as free space, detaching the virtual disk extension from the virtual disk file and modifying state information associated with the virtual disk extension to indicate that the virtual disk extension includes arbitrary data. 19. The method of claim 16, further comprising: in response to receiving a request to trim all sectors of the virtual disk extension, detaching the virtual disk extension from the virtual disk file and modifying status information associated with the virtual disk extension to indicate that the virtual disk extension includes a non-information disclosure bit mode. 20. The method of claim 17, further comprising: sending a zero token to the requester in response to receiving an unmount read request associated with the virtual disk extension.