Patent application number | Description | Published |
20090044204 | Application programming interfaces for transacted file and registry operations - A set of application programming interfaces (“APIs”) is provided that enables an application to perform operations on multiple system resources as a single logical unit of work through a transaction. The application can then commit or roll back the entire group of changes as a single unit in a coordinated manner. The APIs expose functions and methods that take a reference to a transaction context, such as a handle, name, or pointer, as one of their parameters so that the application can manipulate the resource as a transacted operation. The transaction is bound to all created handles so that all operations on the resource using those handles are also transacted. In an illustrative example, the set of APIs are transacted name-based WIN32 APIs that take a transaction handle. The transacted APIs expose transacted operations to the application for durable system resources in the OS kernel, including the NTFS file system (New Technology File System) and registry. | 02-12-2009 |
20090112942 | System and Method for Decoupling Space Reservation in Transactional Logs - 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. | 04-30-2009 |
20100042626 | Transactional File System - A transactional file system wherein multiple file system operations may be performed as a transaction. An application specifies that file system-related operations are to be handled as a transaction, and the application is given a file handle associated with a transaction context. For file system requests associated with a transaction context, a file system component manages operations consistent with transactional behavior. Transactions over a network are facilitated. Remote files may be accessed within a transaction via a redirector protocol. A redirector on a client computer system communicates with an agent on a server computer system to relay and maintain transactional information on both systems. | 02-18-2010 |
20100082550 | AGGREGATION OF WRITE TRAFFIC TO A DATA STORE - 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. | 04-01-2010 |
20100082918 | LOG MANAGER FOR AGGREGATING DATA - A processing device and a machine-implemented method may be provided for sequentially aggregating, or writing, data to a log included in a data store. The log may store multiple log entries. Each of the log entries may include an entry metadata portion, describing a respective log entry, and an entry payload data portion. The entry metadata portion may include a log sequence number, corresponding to a log entry at a particular position in the log. A library of log-related processes may be provided, along with an application program interface to permit a calling application program to call any of the log related processes. The log-related processes may be called during a boot mode, a user mode, and a kernel mode. | 04-01-2010 |
20100199109 | ABSTRACTING PROGRAMMATIC REPRESENTION OF DATA STORAGE SYSTEMS - Providing for a paradigm shift in block-level abstraction for storage devices is described herein. At a block-level, storage is characterized as a variable size data record, rather than a fixed size sector. In some aspects, the variable size data record can comprise a variable binary key-data pair, for addressing and identifying a variable size block of data, and for dynamically specifying the size of such block in terms of data storage. By changing the key or data values, the location, identity or size of block-level storage can be modified. Data records can be passed to and from the storage device to facilitate operational commands over ranges of such records. Block-level data compression, space management and transactional operations are provided, mitigating a need of higher level systems to characterize underlying data storage for implementation of such operations. | 08-05-2010 |
20110145527 | Consistency Without Ordering Dependency - Aspects of the subject matter described herein relate to maintaining consistency in a storage system. In aspects, one or more objects may be updated in the context of a transaction. In conjunction with updating the objects, logical copies of the objects may be obtained and modified. A request to write the updated logical copies is sent to a storage controller. The logical copies do not overwrite the original copies. In conjunction with sending the request, a data structure is provided for the storage controller to store on the disk. The data structure indicates the one or more objects that were supposed to be written to disk and may include verification data to indicate the content that was supposed to be written to disk. During recovery, this data structure may be used to determine whether all of the object(s) were correctly written to disk. | 06-16-2011 |
20110197016 | Aggregation of Write Traffic to a Data Store - 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. | 08-11-2011 |
20110276611 | Transactional File System - A transactional file system wherein multiple file system operations may be performed as a transaction. An application specifies that file system-related operations are to be handled as a transaction, and the application is given a file handle associated with a transaction context. For file system requests associated with a transaction context, a file system component manages operations consistent with transactional behavior. Logging and recovery are also facilitated by logging page data separate from the main log with a unique signature that enables the log to determine whether a page was fully flushed to disk prior to a system crash. | 11-10-2011 |
20110314229 | Error Detection for Files - Aspects of the subject matter described herein relate to error detection for files. In aspects, before allowing updates to a clean file, a flag marking the file as dirty is written to non-volatile storage. Thereafter, the file may be updated as long as desired. Periodically or at some other time, the file may be marked as clean after all outstanding updates to the file and error codes associated with the file are written to storage. While waiting for outstanding updates and error codes to be written to storage, if additional requests to update the file are received, the file may be marked as dirty again prior to allowing the additional requests to update the file. The request to write a clean flag regarding the file may be done lazily. | 12-22-2011 |
20110314246 | HIERARCHICAL ALLOCATION FOR FILE SYSTEM STORAGE DEVICE - Aspects of the subject matter described herein relate to storage allocation. In aspects, a hierarchical data structure is used to track allocation data for storage managed by a file system. The hierarchical data structure may have multiple levels with each level having data regarding a different granularity of storage. Portions of the hierarchical data structure may be locked independently of other portions of the hierarchical data structure. The hierarchical data structure may indicate that one or more portions of storage are for exclusive use by a directory. Extra space may be reserved in allocated space in anticipation of subsequent operations. Allocation requestors may obtain storage allocation from regions associated with different levels of the hierarchical data structure. | 12-22-2011 |
20120102265 | Aggregation of Write Traffic to a Data Store - 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. | 04-26-2012 |
20130064052 | EFFICIENT ACCESS TO STORAGE DEVICES WITH USAGE BITMAPS - Upon receiving a request to allocate a storage region, a storage device may initialize the contents of the storage device to default values (e.g., zero) in order to avoid problems arising from unknown data stored in the locations of the storage region (e.g., upon writing a data set to a location involved in a mirroring relationship, uninitialized data in the corresponding mirror location may result in a mismatch that jeopardizes the written data). However, initializing the storage device may be time-consuming and inefficient. Instead, a usage bitmap may be generated that, for respective location sets of the storage region, indicates whether values exist in the location. A read request may be fulfilled by examining the usage bitmap to determine whether values exist in the specified location, and if not, the default value may be returned without accessing the storage device. Other efficiencies may also be achieved using the usage bitmap. | 03-14-2013 |
20130067174 | NONVOLATILE MEDIA JOURNALING OF VERIFIED DATA SETS - The storage of data sets in a storage set (e.g., data sets written to hard disk drives comprising a RAID array) may diminish the performance of the storage set through non-sequential writes, particularly if the storage devices promptly write data sets that are followed by sequentially following data sets. Additionally, storage sets may exhibit inconsistencies due to non-atomic writes of data sets and verifiers (e.g., checksums) and an intervening failure, such as an occurrence of the RAID write hole. Instead, data sets and verifiers may first be written to a stored on the nonvolatile media of a storage device before being committed to the storage set. Such writes may be sequentially written to the journal, irrespective of the locations of the data sets in the storage set; and recovery of a failure may simply involve re-committing the consistent records in the journal to correct incomplete writes to the storage set. | 03-14-2013 |
20130173872 | Abstracting Programmatic Representation of Data Storage Systems - Providing for a paradigm shift in block-level abstraction for storage devices is described herein. At a block-level, storage is characterized as a variable size data record, rather than a fixed size sector. In some aspects, the variable size data record can comprise a variable binary key-data pair, for addressing and identifying a variable size block of data, and for dynamically specifying the size of such block in terms of data storage. By changing the key or data values, the location, identity or size of block-level storage can be modified. Data records can be passed to and from the storage device to facilitate operational commands over ranges of such records. Block-level data compression, space management and transactional operations are provided, mitigating a need of higher level systems to characterize underlying data storage for implementation of such operations. | 07-04-2013 |
20130265861 | EFFICIENT ACCESS TO STORAGE DEVICES WITH USAGE BITMAPS - Upon receiving a request to allocate a storage region, a storage device may initialize the contents of the storage device to default values (e.g., zero) in order to avoid problems arising from unknown data stored in the locations of the storage region (e.g., upon writing a data set to a location involved in a mirroring relationship, uninitialized data in the corresponding mirror location may result in a mismatch that jeopardizes the written data). However, initializing the storage device may be time-consuming and inefficient. Instead, a usage bitmap may be generated that, for respective location sets of the storage region, indicates whether values exist in the location. A read request may be fulfilled by examining the usage bitmap to determine whether values exist in the specified location, and if not, the default value may be returned without accessing the storage device. Other efficiencies may also be achieved using the usage bitmap. | 10-10-2013 |
20130265862 | EFFICIENT ACCESS TO STORAGE DEVICES WITH USAGE BITMAPS - Upon receiving a request to allocate a storage region, a storage device may initialize the contents of the storage device to default values (e.g., zero) in order to avoid problems arising from unknown data stored in the locations of the storage region (e.g., upon writing a data set to a location involved in a mirroring relationship, uninitialized data in the corresponding mirror location may result in a mismatch that jeopardizes the written data). However, initializing the storage device may be time-consuming and inefficient. Instead, a usage bitmap may be generated that, for respective location sets of the storage region, indicates whether values exist in the location. A read request may be fulfilled by examining the usage bitmap to determine whether values exist in the specified location, and if not, the default value may be returned without accessing the storage device. Other efficiencies may also be achieved using the usage bitmap. | 10-10-2013 |
20130311733 | CONSISTENCY WITHOUT ORDERING DEPENDENCY - Aspects of the subject matter described herein relate to maintaining consistency in a storage system. In aspects, one or more objects may be updated in the context of a transaction. In conjunction with updating the objects, logical copies of the objects may be obtained and modified. A request to write the updated logical copies is sent to a storage controller. The logical copies do not overwrite the original copies. In conjunction with sending the request, a data structure is provided for the storage controller to store on the disk. The data structure indicates the one or more objects that were supposed to be written to disk and may include verification data to indicate the content that was supposed to be written to disk. During recovery, this data structure may be used to determine whether all of the object(s) were correctly written to disk. | 11-21-2013 |
20130325830 | TRANSACTIONAL FILE SYSTEM - A transactional file system wherein multiple file system operations may be performed as a transaction. An application specifies that file system-related operations are to be handled as a transaction, and the application is given a file handle associated with a transaction context. For file system requests associated with a transaction context, a file system component manages operations consistent with transactional behavior. Logging and recovery are also facilitated by logging page data separate from the main log with a unique signature that enables the log to determine whether a page was fully flushed to disk prior to a system crash. | 12-05-2013 |
20140201163 | HANDLING FILE SYSTEM CORRUPTION - Aspects of the subject matter described herein relate to file system technology. In aspects, a mechanism is described that allows a file system to handle corrupted file system metadata in a way that provides high availability. When corrupted metadata is detected, the corrupted metadata may be deleted while the file system remains online and available to service file input/output operations that involve non-corrupted metadata. | 07-17-2014 |
20140237173 | AGGREGATION OF WRITE TRAFFIC TO A DATA STORE - 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. | 08-21-2014 |
20140279895 | N-way Parity for Virtual Disk Resiliency - Resiliency techniques for a virtual disk are described that enable user control over storage efficiency and recovery time. Configuration parameters for a virtual disk are obtained that indicate a number of available storage devices and a specified tolerance for storage device failures. A default configuration for the virtual disk that designates a default amount of redundancy data to store with client data to balance storage efficiency and recovery time is derived based on the configuration parameters. Options may then be provided to specify a custom configuration that changes the amount of redundancy data to customize the level of storage efficiency and recovery time. The virtual disk is configured and data is stored thereon in accordance with the default configuration or the custom configuration as directed by the user. | 09-18-2014 |
20140280397 | HETEROGENIC VOLUME GENERATION AND USE SYSTEM - A system in which a file system may operate on a volume in which the logical address extent of the volume is divided into multiple tiers, each tier providing storage having a distinct trait set by mapping the logical addresses of the volume to appropriate underlying storage systems. A volume system exposes the volume to the file system in a manner that the file system itself has awareness of the tiers, and is aware of the trait sets of each tier. The file system may thus store file system namespaces (such as directories and files) into the tiers as appropriate for the file system namespace. A provisioning system may also be provided and be configured to provision the volume to include such tiers, and if desired, to extend the tiers. | 09-18-2014 |
20140281692 | Virtual Disk Recovery and Redistribution - Techniques for recovery and redistribution of data from a virtual disk storage system are described herein. In one or more implementations, a storage scheme derived for a virtual disk configuration is configured to implement various recovery and redistribution designed to improve recovery performance. The storage scheme implements one or more allocation techniques to produce substantially uniform or nearly uniform distributions of data across physical storage devices associated with a virtual disk. The allocation facilitates concurrent regeneration and rebalancing operations for recovery of data in the event of failures. Additionally, the storage scheme is configured to implements parallelization techniques to perform the concurrent operations including but not limited to controlling multiple parallel read/writes during recovery. | 09-18-2014 |
20140304550 | Error Detection for Files - Aspects of the subject matter described herein relate to error detection for files. In aspects, before allowing updates to a clean file, a flag marking the file as dirty is written to non-volatile storage. Thereafter, the file may be updated as long as desired. Periodically or at some other time, the file may be marked as clean after all outstanding updates to the file and error codes associated with the file are written to storage. While waiting for outstanding updates and error codes to be written to storage, if additional requests to update the file are received, the file may be marked as dirty again prior to allowing the additional requests to update the file. The request to write a clean flag regarding the file may be done lazily. | 10-09-2014 |
20140337302 | Error Detection for Files - Aspects of the subject matter described herein relate to error detection for files. In aspects, before allowing updates to a clean file, a flag marking the file as dirty is written to non-volatile storage. Thereafter, the file may be updated as long as desired. Periodically or at some other time, the file may be marked as clean after all outstanding updates to the file and error codes associated with the file are written to storage. While waiting for outstanding updates and error codes to be written to storage, if additional requests to update the file are received, the file may be marked as dirty again prior to allowing the additional requests to update the file. The request to write a clean flag regarding the file may be done lazily. | 11-13-2014 |
20140359203 | STORAGE SYSTEMS AND ALIASED MEMORY - Aspects of the subject matter described herein relate to storage systems and aliased memory. In aspects, a file system driver or other component may send a request to a memory controller to create an alias between two blocks of memory. One of the blocks of memory may be used for main memory while the other of the blocks of memory may be used for a storage system. In response, the memory controller may create an alias between the blocks of memory. Until the alias is severed, when the memory controller receives a request for data from the block in main memory, the memory controller may respond with data from the memory block used for the storage system. The memory controller may also implement other actions as described herein. | 12-04-2014 |