Microsoft Technology Licensing, LLC

Karan Mehra

Darren Glen Moss

Surendra Verma

Shiv Kumar Rajpal

William R Tipton

Neal Robert Christiansen

Emanuel Paleologu

Shi Cong

Sarosh Cyrus Havewala

Scott A Brender

Ravinder S Thind

Andrew M Herron

Vinod R Shankar

Senthil Rajaram

Dustin Lyle Green

Sachin C Patel

Darwin Ou-Yang

Andrea D'Amato

John Andrew Starks

Rajeev Y Nagar

Grigory Borisovich Lyakhovitskiy

Vyacheslav Kuznetsov

Chung Lang Dai

Mathew John

Todd William Harris

John R Dietrick

Landy Wang

Octavian Tony Ureche

Rajsekhar Das

Ervin Peretz

Daniel Chan

Matt Garson

Taylor Alan Hope

Erik G Hortsch

Ankur Kasturiya

Gregory J Jacklin

Ashley P Ventura

Tarun Ramani

Norbert Paul Kusters

David Abzarian

Hari R Pulapaka

Parveen Kumar Patel

Scott Chao-Chueh Lee

Paul Adrian Oltean

David Rudolph Wooten

Innokentiy Basmov

Alan M Warwick

Jason Stewart Wohlgemuth

Michael L Michael

James Anthony Schwartz, Jr

Yi Meng

Benjamin A Leis

William L Scheidel

Malcolm James Smith

Juan-Lee Pang

Gaurav Jagtiani

Bryan Stephen Matthew

Matthew Kerner

Matthew Stuart Garson

Abhay Sudhir Ketkar

Nandagopal Kirubanandan

Natalia Valeryevna Varava

Binit Ranjan Mishra

Cornel Emilian Rat

Emma Sutherland Boyd

Venkatasubrahmanyam Raman

Shekhar Agrawal

Justin Sing Tong Cheung

Shiv Rajpal

David Wimmel

Shailesh Padmakar Joshi

Gregory Robert Domzalski

Thothathri Vanamamalai

Benjamin Alan Leis

Rajeev Nagar

Shiv K Rajpal

A computer system identifies an event from a management system log associated with a first container host. The presence of the event in the management system log is indicative that the first container host identified a fatal system error at the first container host. Based on the event, the computer system determines that a first instance of a container that is provisioned at the first container host has been isolated to the first container host. Based on the first instance of the container having been isolated to the first container host, the computer system instructs a second container host to provision a second instance of the container at the second container host.

Accelerated fatal system error recovery of container host

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

Data is identified that defines a known good state for a current operating system. The identified data includes read-only sets that are not updated during operation of the computing device, and modifiable sets that can be updated during operation of the computing device. The read-only sets are captured on an opportunistic basis and the modifiable sets are captured when the computing device is to be rebooted. A first and second virtual disk are allocated as snapshots of the identified data. The first virtual disk is updated to generate an updated state. The updates to the first virtual disk are isolated from the second virtual disk. The second virtual disk is maintained as an immutable snapshot of the identified data. In response to a failed reboot with the updated state, the computing device reverts to the known good state using the snapshot of the identified data.

Space snapshots

A first storage node configured to store data associated with a user is allocated. The data stored on the first storage node is mirrored at a second storage node. A resiliency mechanism is implemented at the first and second storage nodes. The resiliency mechanism is configured to restore data on at least one of the storage devices of the first and second storage nodes. In response to a loss of availability of either the first or second storage node and a loss of availability of one or more storage device on an available storage node, data on the unavailable storage devices of the available storage node is recovered using the resiliency mechanism of the available storage node.

Multilevel resiliency

A virtual disk is instantiated as a representation of a storage volume. The virtual disk is configured with metadata corresponding to the storage volume. A storage stack is instantiated that is operable to provide an active I/O path to the storage volume. The storage stack is modified by adding an alternative I/O path to the virtual disk. The alternative I/O path includes a layout driver configured to manage a converted storage layout for the storage volume. The storage volume is encapsulated to the virtual disk. The active I/O path is closed and the alternative I/O path is enabled for I/O requests to the virtual disk. The storage layout of the storage device is converted without taking the storage volume offline.

Online conversion of storage layout

In a parity-based redundancy scheme, allocation information indicative of free and allocated portions of storage is accessed. In response to a request for a write operation, when the write request shares its parity with a non-free portion of the storage, a record of writes to the storage is updated to include the requested write and associated parity. The parity is updated with the requested write, and the write request is executed. When the write request shares its parity with a free portion of the storage or the write request spans all portions of storage that shares the parity, the write request is allowed to be executed in the free portion of the storage without updating the record.

Parity log with by-pass

Virtual storage free space management techniques may calculate a data allocation value of a virtual storage entity based on a number of storage slabs allocated with data. The virtual storage free space management techniques may further analyze a physical storage entity to determine a storage allocation value associated with the physical storage entity. The storage allocation value may be obtained by summing the storage amount in bytes associated with each of the storage slabs of the physical storage entity that is allocated to one or more virtual storage entities. A free space value associated with the virtual storage entity may be determined based on the storage allocation value and the data allocation value.

Virtual storage free space management

A method and a processing device are provided for sequentially aggregating data to a write log included in a volume of a random-access medium. When data of a received write request is determined to be suitable for sequentially aggregating to a write log, the data may be written to the write log and a remapping tree, for mapping originally intended destinations on the random-access medium to one or more corresponding entries in the write log, may be maintained and updated. At time periods, a checkpoint may be written to the write log. The checkpoint may include information describing entries of the write log. One or more of the checkpoints may be used to recover the write log, at least partially, after a dirty shutdown. Entries of the write log may be drained to respective originally intended destinations upon an occurrence of one of a number of conditions.

Aggregation of write traffic to a data store

In a parity-based redundancy scheme, a log is maintained that contains a record of storage writes and associated redundancy backups. A mapping of allocation information indicative of free and allocated portions of storage is stored. An indication is received of a change to the free and allocated portions of storage. An update to the mapping of allocation information is determined, and the update to the mapping of allocation information is stored. The stored update is accessed and the redundancy backup is synchronized with stored data in response to a power interruption.

Parity log with delta bitmap

The techniques disclosed herein provide a dynamically configurable cluster of storage devices. In some configurations, the dynamically configurable cluster is associated with a fault domain. The cluster may include a plurality of computing devices that each include at least a storage device. The plurality of storage devices in the cluster may be configured to support a plurality of workloads coupled to the dynamically configurable cluster. The plurality of storage devices in the dynamically configurable cluster may be allocated to one or more of the plurality of workloads based on metadata identified resiliency requirements, performance requirements, and/or cost factors linked to the one or more of the plurality of workloads.

Dynamically configurable storage clusters

Scalable data storage techniques are described. In one or more implementations, data is obtained by one or more computing devices that describes fault domains in a storage hierarchy and available storage resources in a data storage pool. Operational characteristics are ascertained, by the one or more computing devices, of devices associated with the available storage resources within one or more levels of the storage hierarchy. Distribution of metadata is assigned by the one or more computing devices to one or more particular data storage devices within the data storage pool based on the described fault domains and the ascertained operational characteristics of devices within one or more levels of the storage hierarchy.

Scalable data storage pools

Recovery requests are scheduled and prioritized according to priority valuations of the minimum time to next failure relative to the minimum time to next recovery for corresponding storage data sets. The prioritization can be performed by an upper layer recovery scheduler that dispatches requests to different storage units and/or by lower layers and individual storage unit schedulers. Prioritizations can be reflected in tagging on recovery requests, as determined by a first entity, and/or determined dynamically at the point of dispatch and processing.

System reliability by prioritizing recovery of objects

Embodiments are directed to modifying storage capacity within a data store and to modifying resiliency for a data store. In one scenario, a computer system receives a request to move data. The computer system may determine that data is to be moved from an allocation on one data store to a new allocation on another data store. The computer system may create a new allocation on the other data store, where the new allocation is configured to receive data from the first data store. The computer system then moves the data to the new allocation on the second data store as data I/O requests are received at the first data store. Data store access requests are synchronized with the data movement by directing the data store access requests to the first data store, to the second data store or to both data stores depending on the type of access request.

Migrating data in response to changes in hardware or workloads at a data store

Embodiments are directed to dynamically changing partitions size for a partition in a storage device and to transferring storage space between partitions in a storage device. A computer system identifies portions of free space on a storage device, where the storage device has at least one partition whose offset and length are stored in a partition table. The computer system determines where the identified free space is located relative to other storage locations on the storage device. The computer system further determines that the partition is to be dynamically resized to a new size which is specified by one or more offset and length values, and based on where the identified free space is located, dynamically transforms the partition into a logical partition, and resizes the logical partition, the logical partition's offset and length values being updated in the partition table to include the new specified offset and length values.

Disk partition stitching and rebalancing using a partition table

Growing community of inventors

Sammamish, WA, United States of America

Karan Mehra