Abstract: A file server provides access to a file system built on a logical volume of data storage. The file system includes multiple cylinder groups of file system blocks, and the logical volume includes slices of the cylinder groups. The file server has a storage reorganizer for identifying allocated file system blocks in a selected slice, and evacuating the identified allocated file system blocks from the selected slice. The selected slice is evacuated by reverse mapping each identified allocated block to identify a file to which the identified allocated block is allocated, allocating a new block in another slice, copying data from the identified allocated block to the new block, and substituting the new block for the identified allocated block in the file.

Abstract: Storage tiering uses file system awareness of storage class for storage allocation or migration of a storage object from one class of storage to another. For example, the storage object is a production file system, a logical unit number (LUN) of storage, or a snapshot copy of the production file system or LUN. Each storage class may comprise a different back-end disk type, such as Fiber Channel, ATA, etc. Storage allocation or migration is based on storage class to implement a storage policy, such as: (a) move snapshots off the class of storage of the production object and onto a different class of storage; (b) direct new writes to a specified class of storage; or (c) writes targeting a particular storage object are targeted to a particular class of storage.

Abstract: A method and apparatus for performing incremental file system checks is described which uses file system information to identify changes that have occurred to a file system between checkpoints. The set of changes can be represented by bitmaps and data structures which may be used by file system check utilities to identify potential errors and to remedy these errors if appropriate. Verifying only file system changes greatly reduces the processing overhead associated with typical backup and recovery mechanisms.

Abstract: A write interface in a file server provides permission management for concurrent access to data blocks of a file, ensures correct use and update of indirect blocks in a tree of the file, preallocates file blocks when the file is extended, solves access conflicts for concurrent reads and writes to the same block, and permits the use of pipelined processors. For example, a write operation includes obtaining a per file allocation mutex (mutually exclusive lock), preallocating a metadata block, releasing the allocation mutex, issuing an asynchronous write request for writing to the file, waiting for the asynchronous write request to complete, obtaining the allocation mutex, committing the preallocated metadata block, and releasing the allocation mutex. Since no locks are held during the writing of data to the on-disk storage and this data write takes the majority of the time, the method enhances concurrency while maintaining data integrity.

Abstract: When a client requests creation of a production file system or logical unit number (LUN) of storage, a sparse metavolume and a container file system built on the sparse metavolume are implicitly created for containing the production file system or LUN. By implicitly creating one container file system for each production file system or LUN, it is possible to hide the management of the container file system from the client or end user. The creation of snapshot copies in the container file system can also be hidden from the client or end user. Customer service level expectations and thin provisioning can be met automatically by storage policies implemented upon the container file system and the underlying sparse metavolume.

Abstract: A self healing file system is designed for proactive detection and containment of faults, errors, and corruptions, in order to enable in place (online) and non-intrusive recovery. For proactive fault detection, the file system maintains certain per-block metadata of each file system block. The per-block metadata includes a redundancy check, and for file system data blocks, an inode identifier, and an offset of the file system data block in the file including the file system data block. The redundancy check is used to detect and mark bad file system blocks. The inode identifier and offset is used for validating connectivity of the file system blocks to the inodes, and for tracing bad blocks to files that contain the bad blocks.

Abstract: A container file system is built on a sparse metavolume for enhanced decoupling of logical storage from physical storage and for providing common supplementary storage services for iSCSI block access and for NFS or CIFS file system access. The container file system contains a production file system or iSCSI LUN and may also contain snapshot copies of the production file system or iSCSI LUN. The container file system manages storage space among the production file system or iSCSI LUN and its snapshot copies, and also improves fault containment. The sparse metavolume provides thin provisioning of the container file system. A slice map indicates whether or not each slice of logical storage in the sparse metavolume is provisioned with an associated configured slice of data storage.

Abstract: Read-only and read-write snapshot copies of a production file in a Unix-based file system are organized as a version set of file inodes and shared file blocks. Version pointers and branch pointers link the inodes. Initially the production file can have all its blocks preallocated or it can be a sparse file having only an inode and its last data block. A protocol is provided for creating read-only and read-write snapshots, deleting snapshots, restoring the production file with a specified snapshot, refreshing a specified snapshot, and naming the snapshots. Block pointers are marked with a flag indicating whether or not the pointed-to block is owned by the parent inode. A non-owner marking is inherited by all of the block's descendants. The block ownership controls the copying of indirect blocks when writing to the production file, and also controls deallocation and passing of blocks when deleting a read-only snapshot.

Abstract: A write interface in a file server provides permission management for concurrent access to data blocks of a file, ensures correct use and update of indirect blocks in a tree of the file, preallocates file blocks when the file is extended, solves access conflicts for concurrent reads and writes to the same block, and permits the use of pipelined processors. For example, a write operation includes obtaining a per file allocation mutex (mutually exclusive lock), preallocating a metadata block, releasing the allocation mutex, issuing an asynchronous write request for writing to the file, waiting for the asynchronous write request to complete, obtaining the allocation mutex, committing the preallocated metadata block, and releasing the allocation mutex. Since no locks are held during the writing of data to the on-disk storage and this data write takes the majority of the time, the method enhances concurrency while maintaining data integrity.

Abstract: Read-only and read-write snapshot copies of a production file in a Unix-based file system are organized as a version set of file inodes and shared file blocks. Version pointers and branch pointers link the inodes. Initially the production file can have all its blocks preallocated or it can be a sparse file having only an inode and its last data block. A protocol is provided for creating read-only and read-write snapshots, deleting snapshots, restoring the production file with a specified snapshot, refreshing a specified snapshot, and naming the snapshots. Block pointers are marked with a flag indicating whether or not the pointed-to block is owned by the parent inode. A non-owner marking is inherited by all of the block's descendants. The block ownership controls the copying of indirect blocks when writing to the production file, and also controls deallocation and passing of blocks when deleting a read-only snapshot.