International Business Machines Corporation

Andrew N Solomon

Manoj N Kumar

David Jones Craft

Janet Elizabeth Adkins

Joon Chang

Matthew Todd Brandyberry

Ninad S Palsule

Adekunle Bello

Grover Herbert Neuman

Frank L Nichols, Iii

David K Bradford

Robert Wright Thomson

A cluster server manages allocation of free blocks to cluster clients performing writes in a clustered file system. The cluster server manages free block allocation with a free block map and an in-flight block map. The free block map is a data structure or hardware structure with data that indicates blocks or extents of the clustered file system that can be allocated to a client for the client to write data. The in-flight block map is a data structure or hardware structure with data that indicates blocks that have been allocated to clients, but remain in-flight. A block remains in-flight until the clustered file system metadata has been updated to reflect a write performed to that block by a client. After a consistency snapshot of the metadata is published to the storage resources, the data at the block will be visible to other nodes of the cluster.

In-flight block map for a clustered redirect-on-write filesystem

Provided are techniques for more efficient data storage on a computing system. An inode table is provided and populated with information relating to current and N previous locations within data storage that a particular data block has been stored. When a particular data block is modified in a redirect on write system, the modified data block is stored, if possible in a previous storage location for that particular data block and the current data location may be saved for use as the location for a subsequent modification.

Preferential block recycling in a redirect-on-write filesystem

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. In response to identifying that the commit-in-progress context is not successfully stored: aborting the storing of the commit-in-progress context, assigning a new commit-in-progress context, and begin storing the new commit-in-progress context.

Merging multiple contexts to manage consistency snapshot errors

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.

Multiple contexts in a redirect on write file system

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.

Distributed free block map for a clustered redirect-on-write file system

Embodiments include a method for removing a file within a redirect-on-write file system. In some embodiments, a file removal operation is detected in a file management unit, which resides in a memory unit. It is then determined that the number of free data blocks in the persistent storage is below a minimum threshold. The file removal operation is written to a log used for storing system operations. A file management unit is notified of the successful write of the file removal operation to the log used for storing system operations. The data blocks are moved from the file selected for removal to a list of free data blocks. The indirect blocks from the file selected for removal are moved to a data block removal list.

File removal with no available disk blocks in redirect-on-write file systems

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. After the file management unit has waited for a period of time, it can make another attempt to write the data blocks within the consistency snapshot to the persistent storage.

Handling file operations with low persistent storage space

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.

Recoverability while adding storage to a redirect-on-write storage pool

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').

Growing community of inventors

Cedar Park, TX, United States of America

Andrew N Solomon