Microsoft Technology Licensing, LLC

Senthil Rajaram

Neal Robert Christiansen

Dustin Lyle Green

Karan Mehra

John Andrew Starks

Andrew M Herron

Mathew John

Todd William Harris

Ravinder S Thind

David Matthew Kruse

Sarosh Cyrus Havewala

Mathew George

Christian Gregory Allred

Chung Lang Dai

Nandagopal Kirubanandan

Darren Glen Moss

Daniel W H Chan

Eric P Traut

William R Tipton

Malcolm James Smith

Gregory J Jacklin

This document describes techniques for storing virtual disk payload data. In an exemplary configuration, each virtual disk extent can be associated with state information that indicates whether the virtual disk extent is described by a virtual disk file. Under certain conditions the space used to describe a virtual disk extent can be reclaimed and state information can be used to determine how read and/or write operations directed to the virtual disk extent are handled. In addition to the foregoing, other techniques are described in the claims, figures, and detailed description of this document.

Virtual disk storage techniques

Improved methods and systems for granular opportunistic locking mechanisms (oplocks) are provided for increasing file caching efficiency. Oplocks can be specified with a combination of three possible granular caching intentions: read, write, and/or handle. An oplock can be specified with an identifier that indicates a client/specific caller to avoid breaking the original oplock due to an incompatibility from other requests of the same client. An atomic oplock flag is added to create operations that allow callers to request an atomic open with an oplock with a given file.

Efficient file management through granular opportunistic locking

In an exemplary embodiment, a virtual disk file can be assigned an identifier and a virtual disk files that is dependent on the virtual disk file can include a copy of the identifier. In the instance that the virtual disk file is opened and data is modified that causes the contents of a virtual disk extent to change the identifier can be changed. If the virtual disk file and the dependent virtual disk file are used to instantiate a virtual disk the difference between identifiers can be detected, which is indicative of the fact that the virtual disk may be corrupted. Other techniques are described in the detailed description, claims, and figures that form a part of this document.

Detecting and preventing virtual disk storage linkage faults

In accordance with one or more aspects, one or more portions of at least one file that have been freed are determined. One or more delete notifications are generated that identify the one or more portions of the at least one file. Each portion is identified as a range of data on a storage device, and each delete notification includes one or more ranges of data on the storage device. A determination is made as to when to send the generated delete notifications based on one or more threshold-based criteria. These generated delete notifications are then sent to a storage stack.

Use of delete notifications by file systems and applications to release storage space

This document describes techniques for effecting a virtual disk. In an exemplary configuration, a virtual disk file can be associated with a log that acts as both a log and a check point record. When a log entry is generated, information that identifies the tail can be stored therein. This information can be used in the event that virtual disk file is improperly closed, i.e., a crash or power failure occurs, to discover a sequence of log entries to replay. In addition to the foregoing, other techniques are described in the claims, detailed description, and figures.

In accordance with one or more aspects, one or more portions of each of multiple files that have been freed are determined. One or more delete notifications are generated identifying the one or more portions of the multiple files. Each portion is identified as a range of data on a storage device, and each delete notification includes one or more ranges of data on the storage device. These generated delete notifications are then sent to a storage stack. Additionally, an application can determine that one or more ranges of data of a storage device are to be freed and send a delete notification, in the absence of a file system on the device, to the storage stack identifying the one or more ranges of data of the storage device that are to be freed.

A storage stack delete notification can be received at a storage stack filter. The delete notification can indicate deletion of primary data in a primary storage region. Secondary data that is taking up storage resources managed by the storage stack filter can be identified. The secondary data can be associated with the primary storage region, and the storage resources can be resources other than the primary storage region. It can be determined whether it is useful to have the secondary data continue taking up the storage resources. If having the secondary data continue taking up the storage resources is not useful, then the storage resources can be freed.

Using delete notifications to free related storage resources

A processing device and a machine-implemented method may be provided for tracking file system dependencies with respect to a volume residing on a storage device and guest volumes residing on virtual storage devices nested within the volume. A shim driver may receive an indication of a virtual storage device being surfaced and may parse contents to surface partitions and volumes contained within the virtual storage device to a system. The shim driver may open a guest volume nested within a host volume and may send a register request, regarding the guest volume, to a virtual disk mini-filter associated with the host volume. The virtual disk mini-filter may save information regarding a relationship between the host volume and the guest volume. The saved information may be used to prevent file system corruption when the host volume is dismounted or unexpectedly removed.

Nested file system support

A delete notification can be received at a storage stack filter in a storage stack. It can be determined whether the delete notification applies to an entire storage volume. If the delete notification does not apply to the entire storage volume, a first set of actions can be taken with the storage stack filter in response to the delete notification. If the delete notification does apply to the entire storage volume, a second set of actions can be taken with the storage stack filter in response to the delete notification.

Growing community of inventors

Seattle, WA, United States of America

Senthil Rajaram