Abstract: Examples described herein generally relate to maintaining a snapshot of a multitier distributed file system. A snapshot directory volume of a directory volume can be created at least in part by copying, to the snapshot directory volume, metadata of the directory volume. Based on a file access request, it can be determined whether the file has not been snapshotted. If not, a snapshot file record of the file, and associated with the snapshot directory volume.

Abstract: Systems and methods are disclosed for clients and servers operating in a scaled cluster environment. Efficiencies are introduced to the process of connecting a client to a clustered environment by providing the client with the ability to attempt a connection with multiple servers in parallel. Servers operating the in the clustered environment are also capable of providing persistent storage of file handles and other state information. Ownership of the state information and persistent handles may be transferred between servers, thereby providing clients with the opportunity to move from one server to another while maintaining access to resources in the clustered environment.

Abstract: Examples described herein generally relate to maintaining a snapshot of a multitier distributed file system. A snapshot directory volume of a directory volume can be created at least in part by copying, to the snapshot directory volume, metadata of the directory volume. Based on a file access request, it can be determined whether the file has not been snapshotted. If not, a snapshot file record of the file, and associated with the snapshot directory volume.

Abstract: Examples described herein generally relate to maintaining a snapshot of a multitier distributed file system. A snapshot directory volume of a directory volume can be created at least in part by copying, to the snapshot directory volume, metadata of the directory volume. Based on a file access request, it can be determined whether the file has not been snapshotted. If not, a snapshot file record of the file, and associated with the snapshot directory volume.

Abstract: Examples described herein generally relate to maintaining a snapshot of a multitier distributed file system. A snapshot directory volume of a directory volume can be created at least in part by copying, to the snapshot directory volume, metadata of the directory volume. Based on a file access request, it can be determined whether the file has not been snapshotted. If not, a snapshot file record of the file, and associated with the snapshot directory volume.

Abstract: Systems and methods are disclosed for clients and servers operating in a scaled cluster environment. Efficiencies are introduced to the process of connecting a client to a clustered environment by providing the client with the ability to attempt a connection with multiple servers in parallel. Servers operating the in the clustered environment are also capable of providing persistent storage of file handles and other state information. Ownership of the state information and persistent handles may be transferred between servers, thereby providing clients with the opportunity to move from one server to another while maintaining access to resources in the clustered environment.

Abstract: Systems and methods are disclosed for clients and servers operating in a scaled cluster environment. Efficiencies are introduced to the process of connecting a client to a clustered environment by providing the client with the ability to attempt a connection with multiple servers in parallel. Servers operating the in the clustered environment are also capable of providing persistent storage of file handles and other state information. Ownership of the state information and persistent handles may be transferred between servers, thereby providing clients with the opportunity to move from one server to another while maintaining access to resources in the clustered environment.

Abstract: Described are embodiments directed at persistent handles that are used to retain state across network failures and server failovers. Persistent handles are requested by a client after a session has been established with a file server. The request for the persistent handle includes a handle identifier generated by the client. The server uses the handle identifier to associate with state information. When there is a network failure or a server failover, and a reconnection to the client, the handle identifier is used to identify replayed requests that if replayed would create an inconsistent state on the server. The replayed requests are then appropriately handled.

Abstract: Systems and methods are disclosed for clients and servers operating in a scaled cluster environment. Efficiencies are introduced to the process of connecting a client to a clustered environment by providing the client with the ability to attempt a connection with multiple servers in parallel. Servers operating the in the clustered environment are also capable of providing persistent storage of file handles and other state information. Ownership of the state information and persistent handles may be transferred between servers, thereby providing clients with the opportunity to move from one server to another while maintaining access to resources in the clustered environment.

Abstract: Described are embodiments directed at persistent handles that are used to retain state across network failures and server failovers. Persistent handles are requested by a client after a session has been established with a file server. The request for the persistent handle includes a handle identifier generated by the client. The server uses the handle identifier to associate with state information. When there is a network failure or a server failover, and a reconnection to the client, the handle identifier is used to identify replayed requests that if replayed would create an inconsistent state on the server. The replayed requests are then appropriately handled.

Abstract: Described are embodiments directed at persistent handles that are used to retain state across network failures and server failovers. Persistent handles are requested by a client after a session has been established with a file server. The request for the persistent handle includes a handle identifier generated by the client. The server uses the handle identifier to associate with state information. When there is a network failure or a server failover, and a reconnection to the client, the handle identifier is used to identify replayed requests that if replayed would create an inconsistent state on the server. The replayed requests are then appropriately handled.

Abstract: A connection state system is described herein that allows a client to resume a connection with a server or a different replacement server by remotely storing client state information in association with a resume key. The system provides a resume key filter operating at the server that facilitates the storing of volatile server state information. The state information can include information such as oplocks, leases granted to a client, and in-flight operations on a file handle. The resume key filter driver sits above the file system, which allows multiple file access protocols to use the filter. Upon a failover event, such as a server going down or losing connectivity to a client, the system can bring up another server or the same server and reestablish state for file handles held by various clients using the resume key filter.

Abstract: Systems and methods are disclosed for clients and servers operating in a scaled cluster environment. Efficiencies are introduced to the process of connecting a client to a clustered environment by providing the client with the ability to attempt a connection with multiple servers in parallel. Servers operating the in the clustered environment are also capable of providing persistent storage of file handles and other state information. Ownership of the state information and persistent handles may be transferred between servers, thereby providing clients with the opportunity to move from one server to another while maintaining access to resources in the clustered environment.

Abstract: Described are embodiments directed at persistent handles that are used to retain state across network failures and server failovers. Persistent handles are requested by a client after a session has been established with a file server. The request for the persistent handle includes a handle identifier generated by the client. The server uses the handle identifier to associate with state information. When there is a network failure or a server failover, and a reconnection to the client, the handle identifier is used to identify replayed requests that if replayed would create an inconsistent state on the server. The replayed requests are then appropriately handled.

Abstract: Aspects of the subject matter described herein relate to providing file access in a multi-protocol environment. In aspects, a file server is operable to receive requests formatted according to two or more file access protocols. If a request is formatted according to a first file access protocol, the file server applies access rights associated with the file to an account associated with a requester to determine whether to grant access. If the request is formatted according to the second file access protocol, the file server may first attempt to find an account for the requester. If an account is not found, the file server may then grant access based on access rights associated with the file as applied to information in the request without consulting an account on the file server.

Abstract: A connection state system is described herein that allows a client to resume a connection with a server or a different replacement server by remotely storing client state information in association with a resume key. The system provides a resume key filter operating at the server that facilitates the storing of volatile server state information. The state information can include information such as oplocks, leases granted to a client, and in-flight operations on a file handle. The resume key filter driver sits above the file system, which allows multiple file access protocols to use the filter. Upon a failover event, such as a server going down or losing connectivity to a client, the system can bring up another server or the same server and reestablish state for file handles held by various clients using the resume key filter.

Abstract: Aspects of the subject matter described herein relate to configuring file shares. In aspects, a template is created that includes policies to apply to one or more shares. The template may derive or otherwise obtain policies from other templates and may also refer to other templates. The template may include opaque data to pass to a subsystem that configures a share with a policy corresponding to the data. After the template is created, the template may then be applied to one or more shares to configure the shares according to policies included in the template. When the template or any template upon which the template depends or to which the template refers is changed, shares associated with the template may also be automatically changed as appropriate.

Abstract: Aspects of the subject matter described herein relate to directory oplocks. In aspects, a file system filter is inserted in a filter stack between requesters of directory oplocks and a file system that stores file system objects. The file system filter receives requests for directory oplocks and subsequently monitors for requests to access file system objects that are inconsistent with the directory oplocks. To provide directory oplock mechanisms, the file system filter may use alternate data streams if provided by the file system or may independently maintain information usable to maintain and release directory oplocks. A directory oplock may affect ancestors and descendants of the directory depending on constraints imposed by the oplock.

Abstract: Aspects of the subject matter described herein relate to configuring file shares. In aspects, a template is created that includes policies to apply to one or more shares. The template may derive or otherwise obtain policies from other templates and may also refer to other templates. The template may include opaque data to pass to a subsystem that configures a share with a policy corresponding to the data. After the template is created, the template may then be applied to one or more shares to configure the shares according to policies included in the template. When the template or any template upon which the template depends or to which the template refers is changed, shares associated with the template may also be automatically changed as appropriate.

Abstract: Aspects of the subject matter described herein relate to providing file access in a multi-protocol environment. In aspects, a file server is operable to receive requests formatted according to two or more file access protocols. If a request is formatted according to a first file access protocol, the file server applies access rights associated with the file to an account associated with a requester to determine whether to grant access. If the request is formatted according to the second file access protocol, the file server may first attempt to find an account for the requester. If an account is not found, the file server may then grant access based on access rights associated with the file as applied to information in the request without consulting an account on the file server.