VERITAS File SystemÖ 3.5 (HP OnlineJFS/JFS3.5) AdministratorÆs Guide (December 2002)

Chapter 6

Online Backup

Snapshot File System Internals

How a Snapshot File System Works

A snapshot file system is created by mounting an empty disk slice as a snapshot of a currently mounted file

system. The bitmap, blockmap and super-block are initialized and then the currently mounted file system is

frozen (see “Freeze and Thaw” on page 49, for a description of the VX_FREEZE ioctl). After the file system to

be snapped is frozen, the snapshot is enabled and mounted and the snapped file system is thawed. The

snapshot appears as an exact image of the snapped file system at the time the snapshot was made.

Initially, the snapshot file system satisfies read requests by finding the data on the snapped file system and

returning it to the requesting process. When an inode update or a write changes the data in block

of the

snapped file system, the old data is first read and copied to the snapshot before the snapped file system is

updated. The bitmap entry for block

is changed from 0 to 1 (indicating that the data for block

can be found

on the snapped file system). The blockmap entry for block

is changed from 0 to the block number on the

snapshot file system containing the old data.

A subsequent read request for block

on the snapshot file system will be satisfied by checking the bitmap

entry for block

and reading the data from the indicated block on the snapshot file system, instead of from

block

on the snapped file system. This technique is called copy-on-write. Subsequent writes to block

on the

snapped file system do not result in additional copies to the snapshot file system, since the old data only

needs to be saved once.

All updates to the snapped file system for inodes, directories, data in files, extent maps, and so forth, are

handled in this fashion so that the snapshot can present a consistent view of all file system structures on the

snapped file system for the time when the snapshot was created. As data blocks are changed on the snapped

file system, the snapshot gradually fills with data copied from the snapped file system.

The amount of disk space required for the snapshot depends on the rate of change of the snapped file system

and the amount of time the snapshot is maintained. In the worst case, the snapped file system is completely

full and every file is removed and rewritten. The snapshot file system would need enough blocks to hold a

copy of every block on the snapped file system, plus additional blocks for the data structures that make up the

snapshot file system. This is approximately 101 percent of the size of the snapped file system. Normally, most

file systems do not undergo changes at this extreme rate. During periods of low activity, the snapshot should

only require two to six percent of the blocks of the snapped file system. During periods of high activity, the

snapshot might require 15 percent of the blocks of the snapped file system. These percentages tend to be

lower for larger file systems and higher for smaller ones.

CAUTION If a snapshot file system runs out of space for changed data blocks, it is disabled and all further

access to it fails. This does not affect the snapped file system.