Microsoft Technology Licensing, LLC

Dexter Paul Bradshaw

Pedro Celis

Thomas Jay Miller

Chengliang Zhang

Georgiy Reynya

Sadashivan Krishnamurthy

Surendra Verma

William R Tipton

Alexandre Olegovich Verbitski

Suyash Sinha

Dana D Groff

Mark Joseph Zbikowski

Hanumantha Rao Kodavalla

James Ernest Johnson

Dmitry Malloy

Dmitry Meshchaninov

Muhunthan Sivapragasam

Jon Cargille

Steven J Malan

Zoheb Lester Alexander Vacheri

Crash recovery of a computing system in the context in which the computing system includes a volatile memory which has contents lost due to the crash, an intermediate non-volatile memory that (together with the volatile memory) contributes to the active memory of the computing system, and non-volatile storage. The recovery occurs by identifying pages that were in the volatile memory at the time of the crash and that are in the intermediate non-volatile memory and recovers those pages into the volatile memory. In embodiments in which access speeds for the intermediate non-volatile memory may be much faster than for the storage, and in which much of the pages to be recovered are recovered from the intermediate non-volatile memory, the recovery time may be reduced.

Crash recovery using non-volatile memory

A computing device and method for establishing more direct access to a storage device from unprivileged code in an unprivileged storage architecture component. Using a storage infrastructure driver to discover and enumerate storage architecture component(s), a user-mode application requests at least one portion of the storage device to store application-related data corresponding to executing input/output activity. The storage infrastructure driver maps the at least one portion of the storage device to substantially match an address space associated with the application-related data and configures at least one path for the user-mode application to perform block-level input/output between the storage device and the unprivileged storage architecture component. A virtual function may be generated corresponding to at least one path between a computing device and the unprivileged storage architecture component to execute input/output activity using the address space. A completion notification mechanism may also be provided.

Storage device access using unprivileged software code

Crash recovery of a computing system in the context in which the computing system includes a volatile memory which has contents lost due to the crash, an intermediate non-volatile memory that (together with the volatile memory) contributes to the active memory of the computing system, and non-volatile storage. The recovery occurs by identifying pages that were in the volatile memory at the time of the crash. For each of these pages, the recovery determines whether to recover the page into the volatile memory from either the intermediate non-volatile memory or the storage, and then performs the recovery. In embodiments in which access speeds for the intermediate non-volatile memory may be much faster than for the storage, and in which much of the pages to be recovered are recovered from the intermediate non-volatile memory, the recovery time may be reduced.

A method and system for establishing more direct access to a storage device from unprivileged code are described. Using a storage infrastructure mechanism to discover and enumerate storage architecture component(s), a user mode application requests a portion of the storage device to store application-related data. That portion is mapped to an address space representing the application-related data. The storage infrastructure mechanism determines whether the user mode application is authorized to access the storage device and if satisfied, the storage infrastructure mechanism configures at least one path for the user mode application to perform block-level input/output between the storage device and an unprivileged storage architecture component. A completion notification mechanism may be selected or established for returning information related to input/output requests.

A buffer manager that manages blocks of memory amongst multiple levels of buffer pools. For instance, there may be a first level buffer pool for blocks in first level memory, and a second level buffer pool for blocks in second level memory. The first level buffer pool evicts blocks to the second level buffer pool if the blocks are not used above a first threshold level. The second level buffer pool evicts blocks to a yet lower level if they have not used above a second threshold level. The first level memory may be dynamic random access memory, whereas the second level memory may be storage class memory, such as a solid state disk. By using such a storage class memory, the working block set of the buffer manager may be increased without resorting to lower efficiency random block access from yet lower level memory such as disk.

Multi-level buffer pool extensions

Aspects of the subject matter described herein relate to a buffer pool for a database system. In aspects, secondary memory such as solid state storage is used to extend the buffer pool of a database system. Thresholds such as hot, warm, and cold for classifying pages based on access history of the pages may be determined via a sampling algorithm. When a database system needs to free space in a buffer pool in main memory, a page may be evicted to the buffer pool in secondary memory or other storage based on how the page is classified and conditions of the secondary memory or other storage.

Buffer pool extension for database server

A system and method for providing scaleable recovery for a multiplexed transactional log. Unlike a dedicated log that includes log data of only one client, a multiplexed transactional log may include log data from multiple clients. In a multiplexed transactional log, log data from different clients may be multiplexed into the multiplexed transactional log in any order. The multiplexed log is maintained for multiple clients using a scaleable logging process. After a system failure, the multiplexed log is recovered using a scaleable recovery process. The scaleable recovery process includes an end-of-log locating process for locating the end of the multiplexed log and each of the virtual logs with the multiplexed log. The end-of-log locating process is also scaleable.

System and method for scaleable multiplexed transactional log recovery

A security model is provided in a transactional logging infrastructure that is arranged as a protected subsystem built on an underlying secure file system. Files in the underlying file system used by virtual log streams are protected from direct user writes, and are written-to only through the protected subsystem that is brokered by a machine-wide principal so that virtual log files sharing the same multiplexed physical log are kept secure from each other. Log file handles and user- and kernel-mode objects are exposed to log clients through interfaces using consistent security semantics for both dedicated and virtual logs. Log clients are agnostic of the underlying secure file system and can only manipulate file system containers&#x2014;abstract objects that implement the physical log and used to virtualize the file system by normalizing input/output operations&#x2014;by using the interfaces brokered by the principal in the protected subsystem.

Security model for common multiplexed transactional logs

A transactional logging service is provided to user-mode and kernel-mode log clients by utilizing a marshalling area to buffer a set of log records that a log client assembles into a log stream. Disk I/O (input/output) functionality is then separately brokered using a kernel-mode address space for a single dedicated physical log, or virtual logs multiplexed to a single log, which is written to stable storage that contains log records from across all of the log streams. Physical log writes are handled by a shared log flush queue and physical log reads are provided by a file system cache that underlies the service. A multi-level cache hierarchy is utilized when a log client needs to access a log record. A series of caches are queried in order of increasing latency until the targeted log record is located. The target log record is only read from disk in the event that it missed at each cache in the hierarchy.

Multi-level read caching for multiplexed transactional logging

A common logging system (a 'virtual logging system') that presents to one or more log clients the appearance that each log client is interacting with a dedicated logging system. In reality, the virtual logging system is multiplexing virtual log streams, including log records, for each log client into a single transactional log. In particular, the invention is directed at a scheme for mapping virtual identifiers that a client uses in connection with the client's own records to physical identifiers that represent the physical location of the client's records in the single transactional log

System and method for locating log records in multiplexed transactional logs

Transactions among kernel objects utilize application program interfaces (APIs) to implement operations on a transaction object and APIs to implement operations on a resource manager object.

Kernel-level transactions

A common logging system (a 'virtual logging system') that presents to one or more log clients the appearance that each log client is interacting with a dedicated logging system. In reality, the virtual logging system is multiplexing virtual log streams, including log records, for each log client into a single transactional log. In particular, the invention is directed at a system and method for decoupling space reservation between a plurality of distributed components and a core component in the virtual logging system.

System and method for decoupling space reservation in transactional logging systems

A common transactional logging system (a 'virtual logging system') that presents to one or more log clients the appearance that each log client is interacting with a dedicated logging system. In reality, the virtual logging system is multiplexing multiple virtual log streams, including log records, for each log client into a single transactional log.

Growing community of inventors

Duvall, WA, United States of America

Dexter Paul Bradshaw