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

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

Abstract: A file system executing on a computing device may store a placeholder for a file on secondary storage of the computing device. The placeholder may comprise a sparse data stream containing none or some of the data of the file and information which enables the remotely stored data of the file to be retrieved from the network. As some or all of the data for the file is being stored remotely, the computing device may rely on a storage virtualization provider to create metadata for the file. Thus, the file system executing on the computing device may receive, from the storage virtualization provider, a request to store metadata associated with the file. In response to this request, the file system may store the metadata as a Binary Large Object (BLOB) in a secondary data stream of the placeholder for the file.

Abstract: A file system executing on a computing device may store a placeholder for a file on secondary storage of the computing device. The placeholder may comprise a sparse data stream containing none or some of the data of the file and information which enables the remotely stored data of the file to be retrieved from the network. As some or all of the data for the file is being stored remotely, the computing device may rely on a storage virtualization provider to create metadata for the file. Thus, the file system executing on the computing device may receive, from the storage virtualization provider, a request to store metadata associated with the file. In response to this request, the file system may store the metadata as a Binary Large Object (BLOB) in a secondary data stream of the placeholder for the file.

Abstract: Storage virtualization techniques allow files and directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the files are stored locally—even though the data of those files and directories may not be resident on the local computing device. That is, the contents of files and directories that may exist in the cloud look and behave as if they were stored locally on a computing device. The level of hydration of placeholders may be monitored and operations may be performed to reduce the impact of excessive hydration on the resources of the computing device.

Abstract: Storage virtualization techniques allow directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the directories are stored locally—even though the data of those directories may not be resident on the local computing device. That is, the contents of directories that may exist in the cloud look and behave as if they were stored locally on a computing device.

Abstract: Storage virtualization techniques allow directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the directories are stored locally—even though the data of those directories may not be resident on the local computing device. That is, the contents of directories that may exist in the cloud look and behave as if they were stored locally on a computing device.

Abstract: Virtual storage free space management techniques may calculate a data allocation value of a virtual storage entity based on a number of storage slabs allocated with data. The virtual storage free space management techniques may further analyze a physical storage entity to determine a storage allocation value associated with the physical storage entity. The storage allocation value may be obtained by summing the storage amount in bytes associated with each of the storage slabs of the physical storage entity that is allocated to one or more virtual storage entities. A free space value associated with the virtual storage entity may be determined based on the storage allocation value and the data allocation value.

Abstract: Virtual storage free space management techniques may calculate a data allocation value of a virtual storage entity based on a number of storage slabs allocated with data. The virtual storage free space management techniques may further analyze a physical storage entity to determine a storage allocation value associated with the physical storage entity. The storage allocation value may be obtained by summing the storage amount in bytes associated with each of the storage slabs of the physical storage entity that is allocated to one or more virtual storage entities. A free space value associated with the virtual storage entity may be determined based on the storage allocation value and the data allocation value.

Abstract: The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.

Abstract: The techniques and systems described herein reduce the amount of storage resources consumed by containers by creating placeholder files in container namespaces. The placeholder files are associated with read-only access to corresponding shared files stored in a read-only namespace. The read-only namespace can be accessible to multiple different containers. This increases the storage density for a storage unit because more containers can be executed from the same storage unit. The techniques and systems described herein further reduce the amount of storage resources consumed by containers by creating placeholder directories. The techniques and systems described herein also reduce the amount of memory storage resources consumed by containers to execute files by using a shared execution memory area.

Abstract: A file system executing on a computing device may store a placeholder for a file on secondary storage of the computing device. The placeholder may comprise a sparse data stream containing none or some of the data of the file and information which enables the remotely stored data of the file to be retrieved from the network. As some or all of the data for the file is being stored remotely, the computing device may rely on a storage virtualization provider to create metadata for the file. Thus, the file system executing on the computing device may receive, from the storage virtualization provider, a request to store metadata associated with the file. In response to this request, the file system may store the metadata as a Binary Large Object (BLOB) in a secondary data stream of the placeholder for the file.

Abstract: Techniques are described for performing a memory operation where direct memory access and logical address translation are implemented. A request for an I/O operation received that includes information indicative of whether a physical memory address may be changed and whether sector atomicity is desired. Based on the information, the requested I/O operation is performed using unmodified Block Translation Table (BTT) where the physical location associated with the requested I/O operation is changed and sector atomicity is provided, or modified BTT where a physical location associated with the requested I/O operation is not changed, or modified BTT where a physical location associated with the requested I/O operation is not changed and atomicity is provided.

Abstract: Storage virtualization techniques allow files to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the files are stored locally—even though the data of those files may not be resident on the local computing device. That is, the contents of files that may exist in the cloud look and behave as if they were stored locally on a computing device.

Abstract: Storage virtualization techniques allow files and directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the files are stored locally—even though the data of those files and directories may not be resident on the local computing device. That is, the contents of files and directories that may exist in the cloud look and behave as if they were stored locally on a computing device. The level of hydration of placeholders may be monitored and operations may be performed to reduce the impact of excessive hydration on the resources of the computing device.

Abstract: Storage virtualization techniques allow directories to be stored remotely, for example, by a cloud storage provider, but in a manner that appears to a user or application running on a local computing device as if the directories are stored locally—even though the data of those directories may not be resident on the local computing device. That is, the contents of directories that may exist in the cloud look and behave as if they were stored locally on a computing device.

Abstract: Aspects of the subject matter described herein relate to an offload provider. In aspects, an offload provider may provide a token that represents data. The offload provider may be expected to ensure that the data the token represents will not change while the token is valid. The offload provider may take actions to ensure the immutability of the data. The actions may be taken, for example, in conjunction with receiving an offload read and/or offload write, and/or in conjunction with receiving another write that, if allowed to proceed, would otherwise change the data represented by the token.

Abstract: Techniques are described for performing a memory operation where direct memory access and logical address translation are implemented. A request for an I/O operation received that includes information indicative of whether a physical memory address may be changed and whether sector atomicity is desired. Based on the information, the requested I/O operation is performed using unmodified Block Translation Table (BTT) where the physical location associated with the requested I/O operation is changed and sector atomicity is provided, or modified BTT where a physical location associated with the requested I/O operation is not changed, or modified BTT where a physical location associated with the requested I/O operation is not changed and atomicity is provided.

Abstract: Improved methods and systems for granular opportunistic locking mechanisms (oplocks) are provided for increasing file caching efficiency. Oplocks can be specified with a combination of three possible granular caching intentions: read, write, and/or handle. An oplock can be specified with an identifier that indicates a client/specific caller to avoid breaking the original oplock due to an incompatibility from other requests of the same client. An atomic oplock flag is added to create operations that allow callers to request an atomic open with an oplock with a given file.

Abstract: The techniques and systems described herein determine whether or not to implement reparse behavior in association with a file or a directory access. A file system and/or a file system filter can receive, from a host system component, a request to open a file or a directory. While attempting to access the file or the directory, a reparse tag associated with an intermediate directory is encountered. The file system can then determine whether a next node, along an access path for the file or the directory to be opened, exists in the intermediate directory. That is, the file system can look beyond the reparse tag and into the intermediate directory to determine if the next node exists. Subsequently, the file system and/or the file system filter can decide whether to implement reparse behavior based on the reparse tag and whether the next node exists in the intermediate directory.