Abstract: A technique for operating a client node in a clustered file system includes allocating a number of blocks during a first time window and tracking the number of blocks allocated during the first time window. The technique further includes transmitting a block allocation request to a server node of the clustered file system for a number of requested blocks in response to a number of free blocks in a client-side block map reaching a first threshold value. In this case, the number of the requested blocks is based on the number of blocks allocated by the client node during the first time window.

Abstract: A technique for operating a client node in a clustered file system includes allocating a number of blocks during a first time window and tracking the number of blocks allocated during the first time window. The technique further includes transmitting a block allocation request to a server node of the clustered file system for a number of requested blocks in response to a number of free blocks in a client-side block map reaching a first threshold value. In this case, the number of the requested blocks is based on the number of blocks allocated by the client node during the first time window.

Abstract: Mechanisms, in a data processing system comprising a processor and an address translation cache, for caching address translations in the address translation cache are provided. The mechanisms receive an address translation from a server computing device to be cached in the data processing system. The mechanisms generate a cache key based on a current valid number of mirror copies of data maintained by the server computing device. The mechanisms allocate a buffer of the address translation cache, corresponding to the cache key, for storing the address translation and store the address translation in the allocated buffer. Furthermore, the mechanisms perform an input/output operation using the address translation stored in the allocated buffer.

Abstract: Mechanisms, in a data processing system comprising a processor and an address translation cache, for caching address translations in the address translation cache are provided. The mechanisms receive an address translation from a server computing device to be cached in the data processing system. The mechanisms generate a cache key based on a current valid number of mirror copies of data maintained by the server computing device. The mechanisms allocate a buffer of the address translation cache, corresponding to the cache key, for storing the address translation and store the address translation in the allocated buffer. Furthermore, the mechanisms perform an input/output operation using the address translation stored in the allocated buffer.

Abstract: A technique for operating a client node in a clustered file system includes allocating a number of blocks during a first time window and tracking the number of blocks allocated during the first time window. The technique further includes transmitting a block allocation request to a server node of the clustered file system for a number of requested blocks in response to a number of free blocks in a client-side block map reaching a first threshold value. In this case, the number of the requested blocks is based on the number of blocks allocated by the client node during the first time window.

Abstract: A method including creating a commit-in-progress context from a copy of a data object in a redirect-on-write file system; and begin storing the commit-in-progress context in a persistent storage device. The method further includes, while storing the commit-in-progress context in the persistent storage device: receiving a notification of a pending modification to the first data object, creating an update-in-progress context from a copy of the commit-in-progress context, and begin applying the modification to the update-in-progress context. The method further includes detecting that a connectivity error has occurred between the commit-in-progress context and the storage device, and in response, identifying whether the commit-in-progress context is successfully stored in the storage device.

Abstract: In a cluster that distributes fileset management, fileset managers will maintain a free block map and an in-flight block map to allocate blocks to clients writing to a relevant fileset. A fileset manager managing free block allocation for cluster clients that write to a fileset managed by the fileset manager. Since a clustered file system manager manages an initial free block map for the cluster (“cluster free block map”), the clustered file system manager provisions free blocks to fileset managers from the cluster free block map. The fileset manager then allocates free blocks from the provisioned free blocks to cluster clients that write to the fileset managed by the fileset manager.

Abstract: In some embodiments, a file management unit located in the operating system detects a write operation that writes the data blocks within the consistency snapshot (in main memory) to the persistent storage. The file management unit can then determine that all transactions have been completed before the write operation begins. In some instances, the file management unit then attempts to write the data blocks within the consistency snapshot to the persistent storage. The file management unit can then receive a notification that the write operation did not successfully write the data blocks from the consistency snapshot to the persistent storage. In some embodiments, the write operation is not successful because there are fewer free data blocks in the persistent storage than needed for writing the data blocks within the consistency snapshot to persistent storage. The file management can then wait a period of time.

Abstract: A method including creating a commit-in-progress context from a copy of a data object in a redirect-on-write file system; and begin storing the commit-in-progress context in a persistent storage device. The method further includes, while storing the commit-in-progress context in the persistent storage device: receiving a notification of a pending modification to the first data object, creating an update-in-progress context from a copy of the commit-in-progress context, and begin applying the modification to the update-in-progress context. The method further includes detecting that a connectivity error has occurred between the commit-in-progress context and the storage device, and in response, identifying whether the commit-in-progress context is successfully stored in the storage device.

Abstract: A technique for operating a client node in a clustered file system includes allocating a number of blocks during a first time window and tracking the number of blocks allocated during the first time window. The technique further includes transmitting a block allocation request to a server node of the clustered file system for a number of requested blocks in response to a number of free blocks in a client-side block map reaching a first threshold value. In this case, the number of the requested blocks is based on the number of blocks allocated by the client node during the first time window.

Abstract: In a cluster that distributes fileset management, fileset managers will maintain a free block map and an in-flight block map to allocate blocks to clients writing to a relevant fileset. A fileset manager managing free block allocation for cluster clients that write to a fileset managed by the fileset manager. Since a clustered file system manager manages an initial free block map for the cluster (“cluster free block map”), the clustered file system manager provisions free blocks to fileset managers from the cluster free block map. The fileset manager then allocates free blocks from the provisioned free blocks to cluster clients that write to the fileset managed by the fileset manager.

Abstract: In some embodiments, a file management unit located in the operating system detects a write operation that writes the data blocks within the consistency snapshot (in main memory) to the persistent storage. The file management unit can then determine that all transactions have been completed before the write operation begins. In some instances, the file management unit then attempts to write the data blocks within the consistency snapshot to the persistent storage. The file management unit can then receive a notification that the write operation did not successfully write the data blocks from the consistency snapshot to the persistent storage. In some embodiments, the write operation is not successful because there are fewer free data blocks in the persistent storage than needed for writing the data blocks within the consistency snapshot to persistent storage. The file management can then wait a period of time.