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: Embodiments of the present disclosure provide for establishing an authenticated session between a client computing device and a remote computing device. In certain embodiments, a connection is established between the client computing device and the remote computing device. Once the connection is established, the client computing device sends a number of requests to the client computing device including a negotiate request, a setup request, and a validation request. In response to the requests, the client computing device receives a number of responses from the remote computing device including a negotiate response, setup response and a validation response. Once the responses have been received, a determination is made as to whether information contained in the validation response matches information contained in the negotiate response. If the information matches, an authenticated session is established between the remote computing device and the client computing device.

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: Embodiments of the present disclosure provide for establishing an authenticated session between a client computing device and a remote computing device. In certain embodiments, a connection is established between the client computing device and the remote computing device. Once the connection is established, the client computing device sends a number of requests to the client computing device including a negotiate request, a setup request, and a validation request. In response to the requests, the client computing device receives a number of responses from the remote computing device including a negotiate response, setup response and a validation response. Once the responses have been received, a determination is made as to whether information contained in the validation response matches information contained in the negotiate response. If the information matches, an authenticated session is established between the remote computing device and the client computing device.

Abstract: Embodiments provide a method and system for transferring data between different computing devices. Specifically, a communication session is established between a first computing device and a second computing device. The communication session may be established using a first communication protocol. The first computing device creates a virtual memory object which is bound to one or more memory blocks of the first computing device. A path to the virtual memory object is generated and the path is transmitted to the second computing device using the communication session. The second computing device may then read or write data directly into/from the virtual memory object using a second communication protocol that is different from the first communication protocol. The data is written into and read from the virtual memory object using file system commands.

Abstract: Methods of classifying a storage traffic stream in a shared storage network are described. In an embodiment, an identifier for the entity generating the stream is generated, where this entity may, for example, indicate a virtual machine, program, session, physical machine, user or process. The identifier is then shared with at least one processing layer along a path of the storage traffic stream between the generating entity and the storage device which stores the file to which the traffic stream relates. In various embodiments, the identifier may then be used by any processing layers which receive it, to selectively handle traffic streams based on the generating entity. The identifier may be shared when the traffic stream is created or subsequently and in various embodiments, the identifier is shared in a second exchange of messages, following the creation of the traffic stream and prior to any other traffic.

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: Embodiments of the present disclosure provide for establishing an authenticated session between a client computing device and a remote computing device. In certain embodiments, a connection is established between the client computing device and the remote computing device. Once the connection is established, the client computing device sends a number of requests to the client computing device including a negotiate request, a setup request, and a validation request. In response to the requests, the client computing device receives a number of responses from the remote computing device including a negotiate response, setup response and a validation response. Once the responses have been received, a determination is made as to whether information contained in the validation response matches information contained in the negotiate response. If the information matches, an authenticated session is established between the remote computing device and the client computing device.

Abstract: The embodiments described herein generally relate to a protocol for implementing data operations, e.g., a version of SMB, atop RDMA transports. In embodiments, systems and methods use the protocol definition, which specifies new messages for negotiating an RDMA connection and for transferring SMB2 data using the negotiated communication. A new protocol message may include new header information to determine message size, number of messages, and other information for sending the SMB2 data over RDMA. The header information is used to accommodate differences in message size requirements between RDMA and SMB2. The SMB Direct protocol allows SMB2 data to be fragmented into multiple individual RDMA messages that a receiver may then logically concatenate into a single SMB2 request or SMB2 response. The SMB Direct protocol also may allow SMB2 to transfer application data via efficient RDMA direct placement and to signal the application data's availability when the transfer is complete.

Abstract: Described are embodiments for providing unique identifiers for files or objects across servers in a server cluster. Embodiments include generating a unique identifier that includes at least three portions. The first portion includes a node identifier which identifies the particular server in a cluster which created the unique identifier. The second portion includes a major sequence number that is incremented when a server is rebooted or otherwise taken off-line and then brought back online. Additionally, the major sequence number is incremented when all of the minor sequence numbers, which are included in a third portion of the unique identifier, have been used. The minor sequence numbers in the third portion are incremented for every unique file or object requested.

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: Aspects of the subject matter described herein relate to synchronizing for directory actions performed while offline. In aspects, file system objects that reside on a remote data store are made available for offline use. While offline, a client receives an indication that a directory is to be deleted or renamed. In response, the client modifies its local copy of the directory and its descendants if any and stores one or more tombstones that include information that the client can use when synchronizing the changes made to the directory when the client is reconnected to the remote data store. When the client reconnects to the remote data store, the client synchronizes changes made while offline with the remote data store. Resolution conflict mechanisms may be used during this synchronization.

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 client-side caching. In aspects, when a client receives a request for data that is located on a remote server, the client first checks a local cache to see if the data is stored in the local cache. If the data is not stored in the local cache, the client may check a peer cache to see if the data is stored in the peer cache. If the data is not stored in the peer cache, the client obtains the data from the remote server, caches it locally, and publishes to the peer cache that the client has a copy of the data.

Abstract: Aspects of the subject matter described herein relate to synchronizing for directory actions performed while offline. In aspects, file system objects that reside on a remote data store are made available for offline use. While offline, a client receives an indication that a directory is to be deleted or renamed. In response, the client modifies its local copy of the directory and its descendants if any and stores one or more tombstones that include information that the client can use when synchronizing the changes made to the directory when the client is reconnected to the remote data store. When the client reconnects to the remote data store, the client synchronizes changes made while offline with the remote data store. Resolution conflict mechanisms may be used during this synchronization.