The VxFS file system provides a mechanism for taking snapshot
images of mounted file systems, which is useful for making backups.The snapshot file system is an exact image of the original file system, which
is referred to as the snapped file system. The snapshot is a consistent view of the file system "snapped" at
the point in time the snapshot is made. Selected files can be backed
up from the snapshot (using standard utilities such as cpio or cp) or the entire file system image can be backed
up (using the vxdump or fscat utilities).
The mount command is used to create a snapshot file system;
there is no mkfs step involved. A snapshot file system is always
read-only and exists only as long as it and the file system that
has been snapped are mounted. A snapped file system cannot be unmounted
until any corresponding snapshots are first unmounted. A snapshot
file system ceases to exist when unmounted. While it is possible
to have multiple snapshots of a file system made at different times,
it is not possible to make a snapshot of a snapshot.
This chapter describes the creation of snapshot file systems
and gives some examples of backing up all or part of a file system
using the snapshot mechanism.
Snapshot File System Disk Structure |
 |
A snapshot file system consists of:
data blocks copied from the snapped file system
Figure 4-1 “The Snapshot Disk Structure” shows the disk structure of a snapshot
file system.
The super-block is similar to the super-block ofa normal VxFS
file system, however, the magic number is different and many of
the fields are meaningless.
Immediately following the super-block is the bitmap. The bitmap contains
one bit for every block on the snapped file system. Initially, all bitmap
entries are zero. A set bit indicates that the appropriate block was
copied from the snapped file system to the snapshot. In this case,
the appropriate position in the blockmap will reference the copied
block,
Following the bitmap is the blockmap. It contains one entryfor
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 used by the snapshot file system are located
after the blockmap. These are filled by any data copied from the
snapped file system, starting from the front 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”, for
a description of the VX_FREEZE ioctl). Once 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 simply 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, rather than from block n on the snapped file system. 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, etc., are handled in this fashion so
that the snapshot can present a consistent view of all file system
structures for the snapped file system for the time when the snapshot
was created. As data blocks are changed on the snapped file system,
the snapshot will gradually fill 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.
|
| |
|
 | NOTE: 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. |
|
| |
|
Printable version
