Abstract: A method includes determining, by a processor, that a write request indicates a clone file that was cloned from a file in a first fileset. The clone file is of a second fileset and a clustered file system comprises the first fileset and the second fileset. A data block of the clone file affected by the write request is determined. The method includes determining that the data block at a current location cannot be modified. In response to a determination that the data block at the current location cannot be modified, the method includes implementing the write request with respect to the data block at a different location and indicating that the data block at the different location can be modified for subsequent write requests that indicate the clone file.

Abstract: A method includes determining, by a processor, that a write request indicates a clone file that was cloned from a file in a first fileset. The clone file is of a second fileset and a clustered file system comprises the first fileset and the second fileset. A data block of the clone file affected by the write request is determined. The method includes determining that the data block at a current location cannot be modified. In response to a determination that the data block at the current location cannot be modified, the method includes implementing the write request with respect to the data block at a different location and indicating that the data block at the different location can be modified for subsequent write requests that indicate the clone file.

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: Some embodiments of the inventive subject matter are directed to performing sub-transactions from a long-lived transaction using an identifier, wherein the sub-transactions are required to be completed in a sequence for the long-lived transaction. In some embodiments, the method is further directed to determining that the sub-transactions require a write of a data value to a database, writing in a log, using the identifier, an entry that indicates the data value, detecting an interruption in performing of the write of the data value to the database, and initiating re-performance of the sub-transactions in order of the sequence. Some embodiments are further directed to, during re-performance of the sub-transactions, detecting the data value in the entry of the log using the identifier, and using the data value indicated in the entry of the log to write the data value to the database.

Abstract: Hierarchical recovery of failed computing nodes to operative computing nodes within a cluster of computing nodes is managed by initiating a recovery leader at an operative node that retrieves management information from the operative nodes and applies the management information to recover filesets of a meta-fileset in a hierarchical filesystem. The use of hierarchical filesets throughout the cluster provides more rapid failover by distributing recovery load across computing nodes and supporting recovery of nodes in parallel.

Abstract: After a clone file is created from a file, a write request targeting the clone file can be handled. It is determined that the write request indicates the clone file that was cloned from a file in a first fileset. The clone file is of a second fileset and a clustered file system comprises the first fileset and the second fileset. A data block of the clone file affected by the write request is determined. It is then determined that the data block at a current location cannot be modified. The write request is implemented with respect to the data block at a different location. It is indicated that the data block at the different location can be modified for subsequent write requests that indicate the clone file.

Abstract: Embodiments include a computer program product and an apparatus for cloning files across different filesets and maintaining the clone files. After a clone file is created from a file, a write request targeting the clone file can be handled. It is determined that the write request indicates the clone file that was cloned from a file in a first fileset. The clone file is of a second fileset and a clustered file system comprises the first fileset and the second fileset. A data block of the clone file affected by the write request is determined. It is then determined that the data block at a current location cannot be modified. The write request is implemented with respect to the data block at a different location. It is indicated that the data block at the different location can be modified for subsequent write requests that indicate the clone file.

Abstract: A method includes initiating committing to persistent storage of a current consistency snapshot of a plurality of data objects in a redirect-on-write file system. Each of the plurality of data objects has a first copy of at least two copies of the data having a first context of at least two contexts. The method includes receiving, during committing to storage of the current consistency snapshot, an update to a data object of the plurality of data objects. The method also includes responsive to receipt of the update to the data object, creating a second copy of data of the data object from the first copy. The second copy of the data has a second context of the at least two contexts. The method includes responsive to receipt of the update to the data object, updating, based on the update, the second copy of the data of the data object.

Abstract: Management of a file hierarchy for a clustered file system can be distributed across nodes of the cluster. A cluster file hierarchy is accessed to determine location of a file in response to a request to write to a file. A first node maintains the cluster file hierarchy. It is determined that management of a fileset object, which represents a fileset that includes the file, has been delegated to a second node based, at least in part, on said accessing the cluster file hierarchy. A node file hierarchy maintained by the second node is accessed responsive to determining the delegation. The cluster file hierarchy represents filesets of the clustered file system and the node hierarchy represents a subset of one or more of the filesets. Location of the file is determined based, at least in part, on said accessing the node file hierarchy.

Abstract: One embodiment is for using a sparse file as a clone. The method includes creating, by an application associated with a computer system, a snapshot of a file, such as an individual file, a collection of files, file system, directories, and so forth. Further, the method includes requesting, by the application, a clone of that created snapshot. Further still, the method includes generating, by the application, an empty sparse having at least one inode identifying the empty sparse file as the clone and pointing to the snapshot associated with the clone. Thereby, the requested clone is created using the created sparse file, which begins as an empty sparse file.

Abstract: Management of a file hierarchy for a clustered file system can be distributed across nodes of the cluster. A cluster file hierarchy is accessed to determine location of a file in response to a request to write to a file. A first node maintains the cluster file hierarchy. It is determined that management of a fileset object, which represents a fileset that includes the file, has been delegated to a second node based, at least in part, on said accessing the cluster file hierarchy. A node file hierarchy maintained by the second node is accessed responsive to determining the delegation. The cluster file hierarchy represents filesets of the clustered file system and the node hierarchy represents a subset of one or more of the filesets. Location of the file is determined based, at least in part, on said accessing the node file hierarchy.

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: Embodiments include a method comprising detecting addition of a new nonvolatile machine-readable medium to a data storage pool of nonvolatile machine-readable media. The method includes preventing from being performed a first operation of a file system that requires a first parameter that identifies a logical indication of a location within the nonvolatile machine-readable media for the file system, until logical indications of locations within the new nonvolatile machine-readable medium for the file system have been stored in the data storage pool. The method includes allowing to be performed, prior to logical indications of locations within the new nonvolatile machine-readable medium being stored in the data storage pool, a second operation of the file system that does not require a second parameter that identifies a logical indication of a location within the nonvolatile machine-readable media, wherein the second operation causes data to be written into the new nonvolatile machine-readable medium.

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: Some embodiments of the inventive subject matter allow a redirect-on-write file system to continue processing file transactions while writing a snapshot to persistent storage. Thus, embodiments do not block file transactions while flushing snapshots to persistent storage. To avoid blocking, some embodiments the file system can maintain two snapshot generations. The first snapshot generation is the snapshot being written to persistent storage. The second snapshot generation may reside in main memory, and store data for file transactions occurring after the file system began writing the first snapshot generation.

Abstract: Maintaining a generation value for each fileset that is distinct from a corresponding fileset manager preserves the independence of nodes while also allowing distributed fileset management. A fileset manager can maintain a value that reflects consistency snapshots for that node (“node generation”) separately from a value that reflects consistency snapshots for a particular fileset (“fileset generation”).

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: Some embodiments of the inventive subject matter are directed to performing sub-transactions of a long-lived transaction (LLT) in a sequence (e.g., according to an LLT flow) and writing a log entry at the performance of each of the sub-transactions that specifies results of the sub-transaction. Some embodiments do not require generating any compensating transactions during performance of the sub-transactions. Some embodiments are further directed to detecting that an interruption occurs to the LLT and repeating, or initiating re-performance of the LLT from the beginning of the sequence following the flow of the LLT from its beginning. During the re-performance of the LLT, some embodiments are further directed to checking the log entry at each sub-transaction to determine whether the sub-transaction was performed successfully before the interruption.

Abstract: Hierarchical recovery of failed computing nodes to operative computing nodes within a cluster of computing nodes is managed by initiating a recovery leader at an operative node that retrieves management information from the operative nodes and applies the management information to recover filesets of a meta-fileset in a hierarchical filesystem. The use of hierarchical filesets throughout the cluster provides more rapid failover by distributing recovery load across computing nodes and supporting recovery of nodes in parallel.

Abstract: One embodiment is for using a sparse file as a clone. The method includes creating, by an application associated with a computer system, a snapshot of a file, such as an individual file, a collection of files, file system, directories, and so forth. Further, the method includes requesting, by the application, a clone of that created snapshot. Further still, the method includes generating, by the application, an empty sparse having at least one inode identifying the empty sparse file as the clone and pointing to the snapshot associated with the clone. Thereby, the requested clone is created using the created sparse file, which begins as an empty sparse file.