|
|
VxFS System Administrator's Guide
The following topics are covered in this chapter:
The
mount command (see
mount_vxfs(1M))
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.
Figure 11 The Snapshot Disk Structure
The super-block is similar to the super-block of a 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 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 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.
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 2 to 6 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.
cpio) can be used without modification on a snapshot file
system, since the snapshot presents the same data as the snapped file
system. Backup programs that access the disk structures of a VxFS file
system
(such as
volcopy(1M)
and
vxdump(1M)
require
some modifications to deal with a snapshot file system. The VxFS
utilities understand snapshot file systems and make suitable
modifications in their behavior so that their operation on a snapshot
file system is indistinguishable from that on a normal file system.
Other backup programs that normally read the raw disk image cannot work
on snapshots without modification. These programs can use the
fscat command to obtain a raw image of the entire file system
identical to that which would have been obtained by a dd
of the disk device containing the snapped file system at the exact
moment the snapshot was created. The snapread ioctl takes arguments
similar to those of the read
system call and returns the same results as would have been obtained by
performing a read on the disk device containing the snapped file system
at the exact time the snapshot was created. In both cases, however, the
snapshot file system provides a consistent image of the snapped file
system with all activity complete; it is an instantaneous read of the
entire file system. This is a marked contrast to the results that would
be obta
If a complete backup of a snapshot file system is made through a
utility such as volcopy and is later restored, it will be
necessary to fsck the restored file system because the
snapshot file system is only consistent and not clean. The file system
may have some extended inode operations that must be completed, though
there should be no other changes. Since the
snapshot file system is not writable, it cannot be fully
fscked. However, the fsck -n
command can be used to report any inconsistencies.
-o
snapof= option of the mount command. The
-o snapsize= option
may also be required if the device being mounted does not identify the
device size in its disk label, or if a size smaller than the entire
device is desired. The following commands create a snapshot file
system:
mount -F vxfs -o snapof=special,snapsize=snapshot_size \ snapshot_special snapshot_mount_pointThe snapshot file system must be created large enough to hold any blocks on the snapped file system that may be written to while the snapshot file system exists.
fuser nor
mount will indicate that a snapped file system cannot be
unmounted because a snapshot of it exists.
/home (which exists on disk
/dev/dsk/c0b0t0d0s7) using a snapshot file system on
/dev/dsk/c0b0t1d0s1 with a snapshot mount point of
backup/home:
cpio:
mount -F vxfs -o snapof=/dev/dsk/c0bot0d0s7, \ snapsize=100000 /dev/dsk/c0bot1d0s1 /backup/home cd /backup find home -ctime -7 -depth -print | \ cpio -oc > /dev/rmt/c0s0 \ umount /backup/home
volcopy:
mount -F vxfs -o snapof=/dev/dsk/c0b0t0d0s7, \ snapsize=100000 /dev/dsk/c0b0t10d0s1 /backup/home volcopy -F vxfs home /dev/rdsk/c0b0t1d0s1 \ c0b0t1d0s1 /dev/rmt/c0s0 tape77 umount /backup/home
/dev/dsk/c0b0t0d0s7 and use
dd to control blocking of output onto tape device using
vxdump:
vxdump f - /dev/rdsk/c0b0t0d0s7 | \ dd bs=128k > /dev/rmt/c0s0
/dev/dsk/c0b0t0d0s7 and
collect those files that have changed in the current directory:
vxdump 3f - /dev/rdsk/c0b0t0d0s7 | vxrestore -xf -
mount -o snapof=/dev/dsk/c0b0t0d0s7,snapsize=100000 \ /dev/dsk/c0b0t1d0s1 /backup/home vxdump f - /dev/rdsk/c0b0t1d0s1 | \ dd bs=128k > /dev/rmt/c0s0The volcopy(1M) and vxdump(1M) programs will ascertain that
/dev/dsk/c0b0t1d0s1 is a snapshot mounted as
/backup/home and do the appropriate work to get the
snapshot data through the mount point.The performance of reads from the snapped file system should not be affected. Writes to the snapped file system, however, typically average two to three times as long as without a snapshot, since the initial write to a data block now requires a read of the old data, a write of the data to the snapshot, and finally the write of the new data to the snapped file system. If multiple snapshots of the same snapped file system exist, writes will be even slower. Only the initial write to a block suffers this penalty, however, so operations like writes to the intent log or inode updates proceed at normal speed after the initial write.
Reads from the snapshot file system are impacted if the snapped file system is busy, since the snapshot reads are slowed by all of the disk I/O associated with the snapped file system.
The overall impact of the snapshot is dependent on the read to write ratio of an application and the mixing of the I/O operations. As an example, Oracle running an OLTP workload on a snapped file system was measured at about 15 to 20 percent slower than a file system that was not snapped.