Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.