Patent application number | Description | Published |
20090043968 | Sharing Volume Data Via Shadow Copies - Aspects of the subject matter described herein relate to sharing volume data via shadow copies. In aspects, an active computer creates a shadow copy of a volume. The shadow copy is exposed to one or more passive computers that may read but not write to the volume. A passive computer may obtain data from the shadow copy by determining whether the data has been written to a differential area and, if so, reading it from the differential area. If the data has not been written to the differential area, the passive computer may obtain it by first reading it from the volume, then re-determining whether it has been written to the differential area, and if so, reading the data from the differential area. Otherwise, the data read from the volume corresponds to the data needed for the shadow copy. | 02-12-2009 |
20090327367 | Common Block Storage Infrastructure - Common block storage infrastructure techniques are described in which files are created through interaction with a file system to reserve extents in a volume on behalf of volume storage drivers, which may form a driver stack that resides logically on top of the volume. The files protect the reserved extents within the volume for use by the volume storage drivers, such as to store metadata related to operations performed by the drivers. When reserved extents are created, a location of the reserved extents is communicated through the driver stack to a corresponding volume storage driver. Volume storage drivers may also be configured to discover their corresponding reserved extents and communicate these to upper-level drivers and components. Accordingly, when a volume storage driver manipulates data in the volume, it may do so with awareness of the reserved extents of the other volume storage drivers. | 12-31-2009 |
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 |
20100088525 | EXTERNAL ENCRYPTION AND RECOVERY MANAGEMENT WITH HARDWARE ENCRYPTED STORAGE DEVICES - Hardware encrypting storage devices can provide for hardware encryption of data being written to the storage media of such storage devices, and hardware decryption of data being read from that storage media. To utilize existing key management resources, which can be more flexible and accommodating, mechanisms for storing keys protected by the existing resources, but not the hardware encryption of the storage device, can be developed. Dedicated partitions that do not have corresponding encryption bands can be utilized to store keys in a non-hardware-encrypted manner. Likewise, partitions can be defined larger than their associated encryption bands, leaving room near the beginning and end for non-hardware encrypted storage. Or a separate bit can be used to individually specify which data should be hardware encrypted. Additionally automated processes can maintain synchronization between a partition table of the computing device and a band table of the hardware encrypting storage device. | 04-08-2010 |
20100114990 | VIRTUALIZED BOOT BLOCK WITH DISCOVERY VOLUME - A file system independent virtualized boot block with discovery volume and cover files renders a volume visible when accessed by an accessing system which differs from a source system. For example, a downlevel operating system recognizes that data is present on a volume created in an uplevel operating system, even where the uplevel data itself may not be accessible. | 05-06-2010 |
20100125588 | MODIFYING DELETE NOTIFICATIONS IN A STORAGE STACK - A filter between a filesystem and a storage device in a storage stack can be configured to modify a delete notification, such as by modifying an existing delete notification or creating a new delete notification. A storage stack filter can receive an existing delete notification and determine a modified range of deleted data in response to receiving the existing notification, where a modified delete notification indicates the modified range of deleted data. A new delete notification can be created with a storage stack filter positioned below a filesystem in a storage stack, where the new delete notification indicates a range of deleted data. The new or modified delete notification can be passed down the storage stack. | 05-20-2010 |
20100125705 | USING DELETE NOTIFICATIONS TO FREE RELATED STORAGE RESOURCES - 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. | 05-20-2010 |
20100125714 | DELETE NOTIFICATIONS FOR AN ENTIRE STORAGE VOLUME - 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. | 05-20-2010 |
20100281299 | FILE SYSTEM RECOGNITION STRUCTURE - A set of file system data structure and file system recognition APIs are disclosed that may allow an operating system to identify a partition of a storage device as having a valid file system, even if the operating system does not know how to access the file system a priori. File systems implement these data structures in a standardized, known location within a partition on the storage device such that an operating system may use APIs or other functions to examine that known location for the presence of these data structures. Information on how to interpret the data structure may be obtained using a network or other source. | 11-04-2010 |
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 |
20110296238 | DATA ENCRYPTION CONVERSION FOR INDEPENDENT AGENTS - The re-encryption of data can be performed with independent cryptographic agents that can automatically encrypt and decrypt data in accordance with cryptographic regions, such that data within a single cryptographic region is encrypted and decrypted with the same cryptographic key. An “in-place” re-encryption can be performed by reading data from a chunk in an existing cryptographic region, shrinking the existing cryptographic region past the chunk, expanding a replacement cryptographic region over the chunk, and then writing the data back to the same location, which is now part of the replacement cryptographic region. An “out-of-place” re-encryption can be performed by reading data from a chunk in an existing cryptographic region and then writing the data back to a location immediately adjacent that is part of a replacement cryptographic region. After the re-encrypted data is “shifted”, the cryptographic regions can be expanded and contracted appropriately, and another chunk can be selected. | 12-01-2011 |
20120079583 | OFFLOAD READS AND WRITES - Aspects of the subject matter described herein relate to offload reads and writes. In aspects, a requestor that seeks to transfer data sends a request for a representation of the data. In response, the requestor receives one or more tokens that represent the data. The requestor may then provide one or more of these tokens to a component with a request to write data represented by the one or more tokens. In some exemplary applications, the component may use the one or more tokens to identify the data and may then read the data or logically write the data without additional interaction with the requestor. Tokens may be invalidated by request or based on other factors. | 03-29-2012 |
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 |
20120110281 | VIRTUALIZATION AND OFFLOAD READS AND WRITES - Aspects of the subject matter described herein relate to virtualization and offload reads and writes. In aspects, an offload read allows a requestor to obtain a token that represents data while an offload write allows the requestor to request that the data (or a part thereof) represented by a token be logically written. Offload reads and writes may be used to perform various actions for virtual environments. | 05-03-2012 |
20120233434 | Virtual Disk Storage Techniques - 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. | 09-13-2012 |
20120311278 | DELETE NOTIFICATIONS FOR AN ENTIRE STORAGE DEVICE - 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 device. If the delete notification does not apply to the entire storage device, 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 device, a second set of actions can be taken with the storage stack filter in response to the delete notification. | 12-06-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 |
20130067159 | VOLATILE MEMORY REPRESENTATION OF NONVOLATILE STORAGE DEVICE SET - The storage devices of a storage device set (e.g., a RAID array) may generate a nonvolatile representation of the configuration of the storage device set, including logical disks, spaces, storage pools, and layout and provisioning plans, on the physical media of the storage devices. A computer accessing the storage device set may also generate a volatile memory representation of the storage device set to use while accessing the storage devices; however, the nonvolatile representation may not be performant due to its different usage and characteristics. Presented herein are techniques for accessing the storage device set according to a volatile memory representation comprising a hierarchy of logical disks, slabs, and extents, and an accessor comprising a provisioning component that handles slab accesses while applying provisioning plans, and that interfaces with a lower-level layout component that translates slab accesses into storage device accesses while applying layout plans to the storage device set. | 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 |
20130067179 | NONVOLATILE MEDIA DIRTY REGION TRACKING - A storage set (e.g., an array of hard disk drives) may experience a failure, such as a loss of power, a software crash, or a disconnection of a storage device, while writes to the storage set are in progress. Recover from the failure may involve scanning the storage set to detect and correct inconsistencies (e.g., comparing mirrors of a data set or testing checksums). However, lacking information about the locations of pending writes to the storage set during the failure, this “cleaning” process may involve scanning the entire storage set, resulting in protracted recovery processes. Presented herein are techniques for tracking writes to the storage set by apportioning the storage set into regions of a region size (e.g., one gigabyte), and storing on the nonvolatile storage medium descriptors of “dirty” regions comprising in-progress writes. The post-failure recovery process may then be limited to the regions identified as dirty. | 03-14-2013 |
20130067187 | ALLOCATION STRATEGIES FOR STORAGE DEVICE SETS - A storage device set may allocate capacity for spaces (e.g., logical volumes) according to an allocation strategy, e.g., allocating capacity from the storage device having the greatest available capacity, or maximizing the distribution of allocated capacity across the storage devices. However, such allocation strategies may be inefficient (e.g., limiting the capability of the storage device set to satisfy subsequent requests with constraints such as a minimum distribution of capacity across several storage devices). The techniques presented herein achieve efficient allocation by first allocating capacity on storage devices having ample available capacity using a round-robin technique, and if such storage devices do not satisfy the capacity request, allocating capacity on storage devices having limited available capacity. Additionally, the techniques presented herein facilitate thin provisioning through capacity reservations, wherein storage devices withhold unallocated storage for particular spaces that may be utilized as a reserve if unreserved capacity is exhausted. | 03-14-2013 |
20130067188 | STORAGE DEVICE DRIVERS AND CLUSTER PARTICIPATION - The representation of storage devices on computers (e.g., as logical volumes) may be complicated by the pooling of multiple storage devices in order to apply redundancy plans such as mirroring and checksumming. Presented herein is a storage device driver configured to operate as a storage device interface generating representations of the storage regions of the storage devices; to claim those regions as a storage controller; and to expose pooled storage regions as logical disks. Additionally, the storage device driver may support the inclusion of storage devices in a cluster, comprising nodes that may be appointed as managers of the storage pool configuration; as managers of the storage devices; as owners having exclusive read/write access to the storage pool or cluster resources; and as cluster resource writers having excusive write access to a cluster resource. The nodes of the cluster may interoperate to share the storage devices while avoiding write conflicts. | 03-14-2013 |
20130067191 | POOLED PARTITION LAYOUT AND REPRESENTATION - A set of storage devices may interoperate to share a pool of storage space, such as in a Redundant Array of Inexpensive Disks (RAID) scheme. However, the details of the representation of the pool and the allocation of capacity to the pool may enable advantages and/or impose limitations on the storage set. Presented herein are techniques for generating a representing a pooled partition on one or more storage devices featuring a pool configuration representing the pool as a set of spaces manifested by the pool; a set of storage devices sharing the pool; and a set of extents that map physical areas of the storage devices to logical areas of the spaces. The flexibility of these pooling techniques may enable such features as flexible capacity allocation, delayed binding, thin provisioning, and the participation of a storage device in two or more distinct pools shared with different sets of storage devices. | 03-14-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 |
20130339717 | Virtualized Boot Block with Discovery Volume - A file system independent virtualized boot block with discovery volume and cover files renders a volume visible when accessed by an accessing system which differs from a source system. For example, a downlevel operating system recognizes that data is present on a volume created in an uplevel operating system, even where the uplevel data itself may not be accessible. | 12-19-2013 |
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 |
20140279966 | VOLUME HAVING TIERS OF DIFFERENT STORAGE TRAITS - A volume system that presents a volume having an extent of logical addresses to a file system. A volume exposure system exposes the volume to the file system in a manner that the volume has multiple tiers, each offering storage of different traits. This is performed using multiple heterogenic underlying storage systems, each having different storage system-specific traits. Each underlying storage system may be hardware, software, or a combination thereof that permits each storage system to expose storage having the particular storage system-specific traits to the file system. The volume system supports each tier by mapping logical addresses of the tier to portions of underling storage systems that are consistent with the tier traits. | 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 |
20140281227 | PROVISIONING IN HETEROGENIC VOLUME OF MULTIPLE TIERS - The provisioning of a volume that has multiple tiers corresponding to different trait sets. The volume to be provisioned is identified along with multiple tiers that are to be in the volume. For each of the tiers that are to be provisioned within the volume, a corresponding trait set is identified as to be applied to each tier. This corresponding trait set may be based on underlying storage systems that are available at the time of provisioning, or which are anticipated to be available. The volume is then caused to be provisioned with the corresponding tiers having the corresponding trait sets. Also, the provisioning of a file, which is determined to have one or more storage traits. Based on these storage traits, the file is then caused to be assigned to an appropriate tier. | 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 |
20140297987 | Managing Capacity of a Thinly Provisioned Storage System - A thinly provisioned storage system detects whether physical storage capacity is available when there is a request to allocate storage capacity, prior to data being written to the storage system. In particular, at the time when the file system allocates storage, such as when creating a file or performing an extending write (append) operation, allocating storage to an unallocated region of a sparse file, defragmenting a file, and the like, a storage system can verify that actual physical storage capacity is available. Thus, if there is insufficient actual physical capacity at the time when a storage allocation is attempted, then an error message can be sent and remedial action can be taken. | 10-02-2014 |
20140310278 | CREATING GLOBAL AGGREGATED NAMESPACES FOR STORAGE MANAGEMENT - Embodiments are directed to creating global, aggregated namespaces for storage management and to providing consistent namespaces in a distributed storage system. In one scenario, a computer system defines data storage objects for each data storage node. The data storage objects uniquely identify storage elements of the data storage nodes, where each data storage object includes various associated attributes. The computer system replicates the defined data storage objects and any associated attributes from a first data storage node to a second, different data storage node among the data storage nodes. As such, the defined data storage objects are visible from any node in the data storage nodes. The computer system also aggregates the defined data storage objects for each of the data storage nodes and creates a global, aggregated namespace that includes the aggregated data storage objects for each of the data storage nodes. | 10-16-2014 |
20140379988 | CACHE DESTAGING FOR VIRTUAL STORAGE DEVICES - Some implementations may include a virtual storage system to which data is written. The virtual storage system may include a cache and multiple hard drives. Multiple queues may be associated with the multiple hard drives such that each hard drive of the multiple hard drives has a corresponding queue of the multiple queues. A set of candidate rows may be selected from the cache. For each candidate row in the set of candidate rows, destination hard drives may be identified. Each candidate row may be placed in queues corresponding to the destination hard drives. Two or more candidate rows from the multiple queues may be written substantially contemporaneously (e.g., in parallel) to two or more destination hard drives. | 12-25-2014 |