International Business Machines Corporation

Ninad S Palsule

Janet Elizabeth Adkins

Joon Chang

Venkateswararao Jujjuri

James John Seeger, Jr

Vishal Chittranjan Aslot

Malahal R Naineni

Manoj N Kumar

David Jones Craft

Jason Christopher Young

Thomas K Clark

Andrew N Solomon

Alexei Kojenov

Matthew Todd Brandyberry

Paul A Dorwin

James Patrick Smith

Craig Fulmer Everhart

Christian Bolik

Robert K Gjertsen

Devesh K Rai

A processor-implemented method for copying a source file to a destination file using a virtual memory manager (VMM) of a computer operating system is provided. The method includes receiving, by the VMM, a request to copy the source file to a destination file. The method further provides that based on the status of the virtual page, performing at least one of moving the virtual page to the destination file, copying the virtual page to the destination file, reading the virtual page into memory, and ignoring the virtual page.

Zero copy support by the virtual memory manager

A computer system for copying a source file to a destination file using a virtual memory manager of a computer operating system is provided. One or more processors, one or more non-tangible computer-readable storage devices, and a plurality of program instructions are included. The program instructions provide for receiving, by the virtual memory manager, a request to copy the source file to a destination file. The program instructions further provides that based on the status of the virtual page, performing at least one moving the virtual page to the destination file, copying the virtual page to the destination file, reading the virtual page into memory, and ignoring the virtual page.

A computer program product for copying a source file to a destination file using a virtual memory manager of a computer operating system is provided. The computer program product includes receiving, by the virtual memory manager, a request to copy the source file to a destination file. The computer program product further provides that based on the status of the virtual page, performing at least one moving the virtual page to the destination file, copying the virtual page to the destination file, reading the virtual page into memory, and ignoring the virtual page.

Metadata is extracted from a filesystem of a first system. The filesystem includes user data and the metadata. The metadata relates to the user data and is corrupt. Just the just the metadata extracted from the filesystem is transmitted from the first system to a second system. The second system receives the transmitted metadata, and loads this metadata to create a dummy namespace reflecting the metadata. The second system debugs the metadata, and prepares a patch based on this debugging. Execution of the patch allows the metadata to be repaired so that the metadata is no longer corrupt. The patch is transmitted from the second system to the first system for execution at the first system to allow the metadata to be repaired at the first system so that the metadata is no longer corrupt at the first system.

Remotely debugging metadata of filesystem without accessing user data of filesystem

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.

File cloning across different filesets

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.

Activity-based block management of a clustered file system

Activity-based block management of a clustered file system using client-side block maps

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

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.

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.

A client node on which a file system is mounted can be configured to efficiently handle content access requests after a snapshot is created. The client node can maintain generation numbers at a data block, a file, and a fileset level to determine whether a data block is part of a snapshot generation and consequently whether the data block is writable in a current generation. Data block mappings and write access permissions associated with the data blocks need not be revoked at the client node prior to creating the snapshot. Cached data block mappings can be accessed to identify data blocks for servicing a read request. The data block can be updated in place if the data block is not part of the snapshot generation. The write request can be serviced at a new data block if the data block is part of the snapshot generation.

Managing data access requests after persistent snapshots

File system objects of unknown type are backed up and restored. A list of file system objects is received from a file system. The file system objects are to be backed up. For each file system object that has a file type that is unknown, the following is performed. First, the file system is queried to obtain information regarding the file system object that is sufficient for the file system to later recreate the file system object if necessary. Second, the file system object and the information regarding the file system object are stored. Examples of file system object types of the file system that may be unknown to an application running on a Microsoft Windows&#xae; operating system include symbolic links, named pipes, and special device files.

Backup and restore of file system objects of unknown type

Provided are techniques for determining whether content of an object has changed. Under control of a backup system, opaque object attributes and a data identifier are received, wherein the data identifier is generated based on one or more relevant object attributes of the opaque object attributes that indicate whether at least one of the content of the object and one or more of the relevant object attributes has changed. The received data identifier is compared with a previously stored data identifier. In response to determining that the received data identifier and the previously stored data identifier do not match, it is determined that the content of the object has changed.

Growing community of inventors

Austin, TX, United States of America

Ninad S Palsule