VERITAS File System 4.1 Administrator's Guide

Online Backup Using File System Snapshots
Snapshot File System Internals
Chapter 6 125
The blockmap contains one entry for each block on the snapped file system. Initially, all
entries are zero. When a block is copied from the snapped file system to the snapshot, the
appropriate entry in the blockmap is changed to contain the block number on the snapshot file
system that holds the data from the snapped file system.
The data blocks are filled by data copied from the snapped file system, starting from the
beginning of the data block area.
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 84, 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 n 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 n is
changed from 0 to 1 (indicating that the data for block n can be found on the snapped file
system). The blockmap entry for block n is changed from 0 to the block number on the
snapshot file system containing the old data.
A subsequent read request for block n on the snapshot file system will be satisfied by checking
the bitmap entry for block n and reading the data from the indicated block on the snapshot file
system, instead of from block n on the snapped file system. This technique is called
copy-on-write. Subsequent writes to block n 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