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 shallow file is adapted for intensive read-only access to data of a primary file. The primary file resides in another file system or file server. The shallow file includes the data block mapping metadata of the primary file and a link to the primary file. To open the shallow file, the file system manager of the shallow file obtains a read lock on the primary file from the file system manager of the primary file. Then the file system manager of the shallow file may use the data block mapping in the shallow file to access the file data from the primary file in storage without participation of the file system manager of the primary file. This permits offloading of data protection services for secure and efficient storage of a backup copy of the file data.

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.