Abstract: Methods and systems for cursor remirroring are disclosed. A mirroring process is initiated for a plurality of chunks stored by a master node. The mirroring process comprises visiting a sequence of one or more of the chunks and, for at least some of the chunks, copying chunk data or metadata to a slave node. During the initiated mirroring process, a request is received for a write operation on one of the chunks stored by the master node. If the chunk in the request has been visited in the mirroring process, the write operation is performed on the master node and on the slave node. If the chunk in the request has not been visited, the write operation is performed on the master node and postponed on the slave node until the chunk in the request has been visited in the mirroring process.

Abstract: Methods and systems for detecting error in data storage entities based at least in part on importance of data stored in the data storage entities. In an embodiment, multiple verification passes may be performed on a data storage entity comprising one or more data blocks. Each data block may be associated with a probability indicating the likelihood that the data block is to be selected for verification. During each verification pass, a subset of the data blocks may be selected based at least in part on the probabilities associated with the data blocks. The probabilities may be adjusted, for example, at the end of a verification pass, based on importance factors such as usage and verification information associated with the data blocks. The probabilities may be updated to facilitate timely detection of important data blocks. Additionally, error mitigation and/or correction routines may be performed in light of detected errors.

Abstract: Write optimization for block-based storage performing snapshot operations may be implemented. Write requests for a particular data volume may be received for which a snapshot operation is in progress. A determination may be made as to whether a data chunk of the data volume modified as part of the write request has not yet been stored to a remote snapshot data store as part of the snapshot operation. For a data chunk that is to be modified and that has not yet been stored, the data chunk may be stored in a local in-memory volume snapshot buffer. Once the data chunk is stored in the in-memory volume snapshot buffer, the write request may be performed and acknowledged as complete. The data chunk may be sent to the remote snapshot data store asynchronously with regard to the acknowledgment of the write request.

Abstract: A computing system recovers volumes in a distributed computing environment while reducing downtime of storage servers. In an embodiment, a storage server contacts a control plane after a storage failure has occurred. If the storage server hosts an authoritative copy of an offline volume, the storage server is requested to restore the volume. Non-authoritative volumes are removed from the storage server and the storage server provides read access to the restored volume while resuming storage services.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.

Abstract: A block-based storage system may implement dynamic durability adjustment for page cache write logging. A rate of incoming write requests for data volumes maintained at a storage node may be monitored. Based, at least in part, on the rate of incoming write requests, a dynamic modification to a durability property for a data volume may be made, such as enabling page cache write logging the data volume or disabling write logging for the data volume. When incoming write requests are received, a determination may be made as to whether page cache write logging for a particular data volume is enabled. For write requests with disabled page cache write logging, the page cache may be updated and the write request may be acknowledged without storing a log record describing the update in a page cache write log.

Abstract: A block-based storage system may implement page cache write logging. Write requests for a data volume maintained at a storage node may be received at a storage node. A page cache for may be updated in accordance with the request. A log record describing the page cache update may be stored in a page cache write log maintained in a persistent storage device. Once the write request is performed in the page cache and recorded in a log record in the page cache write log, the write request may be acknowledged. Upon recovery from a system failure where data in the page cache is lost, log records in the page cache write log may be replayed to restore to the page cache a state of the page cache prior to the system failure.

Abstract: A block-based storage system may implement dynamic durability adjustment for page cache write logging. A rate of incoming write requests for data volumes maintained at a storage node may be monitored. Based, at least in part, on the rate of incoming write requests, a dynamic modification to a durability property for a data volume may be made, such as enabling page cache write logging the data volume or disabling write logging for the data volume. When incoming write requests are received, a determination may be made as to whether page cache write logging for a particular data volume is enabled. For write requests with disabled page cache write logging, the page cache may be updated and the write request may be acknowledged without storing a log record describing the update in a page cache write log.

Abstract: A block-based storage system may implement reducing durability state for a data volume. A determination may be made that storage node replicating write requests for a data volume is unavailable. In response, subsequent write requests may be processed according to a reduced durability state for the data volume such that replication for the data volume may be disabled for the storage node. Write requests may then be completed at a fewer number of storage nodes prior to acknowledging the write request as complete. Durability state for the data volume may be increase in various embodiments. A storage node may be identified and replication operations may be performed to synchronize the current data volume at the storage node with a replica of the data volume maintained at the identified storage node.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: Methods and systems for detecting error in data storage entities based at least in part on importance of data stored in the data storage entities. In an embodiment, multiple verification passes may be performed on a data storage entity comprising one or more data blocks. Each data block may be associated with a probability indicating the likelihood that the data block is to be selected for verification. During each verification pass, a subset of the data blocks may be selected based at least in part on the probabilities associated with the data blocks. The probabilities may be adjusted, for example, at the end of a verification pass, based on importance factors such as usage and verification information associated with the data blocks. The probabilities may be updated to facilitate timely detection of important data blocks. Additionally, error mitigation and/or correction routines may be performed in light of detected errors.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: Techniques, including systems and methods, for capturing data sets include performing a client-side two-phase commit to ensure one or more data consistency conditions. A logical volume may represent a data set that is distributed among a plurality of physical storage devices. One or more client devices are instructed to block at least acknowledgment of write operations. When the one or more client devices have blocked at least acknowledgment of write operations, one or more servers in communication with the physical storage devices are instructed to capture corresponding portions of the data set. When the servers have been instructed to capture corresponding portions of the data set, the client devices are instructed to resume at least acknowledgment of write operations.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: The relative health of data storage drives may be determined based, at least in some aspects, on data access information and/or other drive operation information. In some examples, upon receiving the operation information from a computing device, a health level of a drive may be determined. The health level determination may be based at least in part on operating information received from a client entity. Additionally, a storage space allocation instruction or operation may be determined for execution. The allocation instruction or operation determined to be performed may be based at least in part on the determined health level.

Abstract: Techniques, including systems and methods, for capturing data sets include performing a client-side two-phase commit to ensure one or more data consistency conditions. A logical volume may represent a data set that is distributed among a plurality of physical storage devices. One or more client devices are instructed to block at least acknowledgment of write operations. When the one or more client devices have blocked at least acknowledgment of write operations, one or more servers in communication with the physical storage devices are instructed to capture corresponding portions of the data set. When the servers have been instructed to capture corresponding portions of the data set, the client devices are instructed to resume at least acknowledgment of write operations.

Abstract: A method is disclosed that includes receiving a request for a transaction from a customer at a seller server system via an electronic-commerce website and identifying a customer account stored at the seller server system based on an identity of the customer. A plurality of financial instruments is associated with the customer account. The plurality of financial instruments has a customer-specific sequence including at least a first financial instrument pre-selected by the customer and a second financial instrument. The method includes automatically attempting to collect a particular payment associated with the transaction from a first financial service provider corresponding to the first financial instrument and automatically attempting to collect the particular payment from a second financial service provider corresponding to the second financial instrument in response to data received at the seller server system indicating a denial of the payment.

Abstract: Customers of a shared-resource environment can provision resources in a fine-grained manner that meets specific performance requirements. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), and the amount of storage requested. The customer will then at any time be able to complete at least the committed rate of IOPS. If the customer generates submissions at a rate that exceeds the committed rate, the resource can still process at the higher rate when the system is not under pressure. Even under pressure, the system will deliver at least the committed rate. Multiple customers can be provisioned on the same resource, and more than one customer can have a committed rate on that resource. Customers without committed or guaranteed rates can utilize the uncommitted portion, or committed portions that are not being used.

Abstract: Commitments against various resources can be dynamically adjusted for customers in a shared-resource environment. A customer can provision a data volume with a committed rate of Input/Output Operations Per Second (IOPS) and pay only for that commitment (plus any overage), for example, as well as the amount of storage requested. The customer can subsequently adjust the committed rate of IOPS by submitting an appropriate request, or the rate can be adjusted automatically based on any of a number of criteria. Data volumes for the customer can be migrated, split, or combined in order to provide the adjusted rate. The interaction of the customer with the data volume does not need to change, independent of adjustments in rate or changes in the data volume, other than the rate at which requests are processed.