Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: A file system that operates on an underlying volume that has multiple tiers, each tier including a particular trait set. Upon creating or otherwise identifying a file system namespace (such as a directory or file) that is in a volume or that is to be included within the volume, a storage trait set to be applied corresponding to the file system namespace is identified. Then, the storage trait set is compared against the trait sets for the multiple tiers to identify a tier into which to store the file system namespace. The file system namespace is then caused to be stored within the identified tier. Thus, the file system is provided with a volume that has multiple tiers (each having different trait sets) to choose from in storing files.

Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: Current file systems may implement opportunistic locks on files that allow clients to locally cache file data, while promoting data consistency when multiple clients read/write the same file. Unfortunately, when a client locally caches directory content of a directory, the file system may lack a mechanism for notifying the client of changes to the directory that would render the cached directory content “stale”. Accordingly, one or more systems and/or techniques for managing a directory oplock are disclosed herein. A directory oplock may be generated based upon an oplock request comprising a first target key and a first parent key. Subsequent access requests for access to the directory or objects therein may be compared with the directory oplock to determine whether to break the directory oplock, and notify the client (e.g., directory oplock is broken if the client submitting the access request is different than the client owning the directory oplock).

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

Abstract: A file system that operates on an underlying volume that has multiple tiers, each tier including a particular trait set. Upon creating or otherwise identifying a file system namespace (such as a directory or file) that is in a volume or that is to be included within the volume, a storage trait set to be applied corresponding to the file system namespace is identified. Then, the storage trait set is compared against the trait sets for the multiple tiers to identify a tier into which to store the file system namespace. The file system namespace is then caused to be stored within the identified tier. Thus, the file system is provided with a volume that has multiple tiers (each having different trait sets) to choose from in storing files.

Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: Described are embodiments for allowing clients that access a distributed file system to locally cache directory metadata. The client may request a read lease which allows the client to cache the directory metadata locally and service requests received from the same application which originally requested the directory metadata using the cache. In addition, the client may also request a handle lease which allows a client to delay the closing of a directory handle and allow the handle to be reused to service subsequent directory metadata requests from the same or a different application. A client may also request a write lease which allows an application on the client to modify the directory metadata, such as by creating or deleting new files in the directory, or changing their attributes, and cache those changes.

Abstract: Current file systems may implement opportunistic locks on files that allow clients to locally cache file data, while promoting data consistency when multiple clients read/write the same file. Unfortunately, when a client locally caches directory content of a directory, the file system may lack a mechanism for notifying the client of changes to the directory that would render the cached directory content “stale”. Accordingly, one or more systems and/or techniques for managing a directory oplock are disclosed herein. A directory oplock may be generated based upon an oplock request comprising a first target key and a first parent key. Subsequent access requests for access to the directory or objects therein may be compared with the directory oplock to determine whether to break the directory oplock, and notify the client (e.g., directory oplock is broken if the client submitting the access request is different than the client owning the directory oplock).

Abstract: A host computing device has multiple instantiated copies of a legacy application. Each copy may issue a data request to access data at an absolute location common to all of the copies. To respond to the data request from a particular copy, it is determined that the absolute location of the data request has a redirection device specifying an alternate location, and the data request is dishonored. A unique location is determined from the alternate location and a unique ID of the particular copy of the legacy application, and the data request is re-issued to access the data at the unique location. Data requests from different copies of the legacy application are thus directed to different unique locations.