f2a2857bb3
the gating of system calls that cause modifications to the underlying filesystem. The gating can be enabled by any filesystem that needs to consistently suspend operations by adding the vop_stdgetwritemount to their set of vnops. Once gating is enabled, the function vfs_write_suspend stops all new write operations to a filesystem, allows any filesystem modifying system calls already in progress to complete, then sync's the filesystem to disk and returns. The function vfs_write_resume allows the suspended write operations to begin again. Gating is not added by default for all filesystems as for SMP systems it adds two extra locks to such critical kernel paths as the write system call. Thus, gating should only be added as needed. Details on the use and current status of snapshots in FFS can be found in /sys/ufs/ffs/README.snapshot so for brevity and timelyness is not included here. Unless and until you create a snapshot file, these changes should have no effect on your system (famous last words).
113 lines
4.6 KiB
Plaintext
113 lines
4.6 KiB
Plaintext
$FreeBSD$
|
|
|
|
Soft Updates Status
|
|
|
|
As is detailed in the operational information below, snapshots
|
|
are definitely alpha-test code and are NOT yet ready for production
|
|
use. Much remains to be done to make them really useful, but I
|
|
wanted to let folks get a chance to try it out and start reporting
|
|
bugs and other shortcomings. Such reports should be sent to
|
|
Kirk McKusick <mckusick@mckusick.com>.
|
|
|
|
|
|
Snapshot Copyright Restrictions
|
|
|
|
Snapshots have been introduced to FreeBSD with a `Berkeley-style'
|
|
copyright. The file implementing snapshots resides in the sys/ufs/ffs
|
|
directory and is compiled into the generic kernel by default.
|
|
|
|
|
|
Using Snapshots
|
|
|
|
To create a snapshot of your /var filesystem, run the command:
|
|
|
|
mount -u -o snapshot /var/snapshot/snap1 /var
|
|
|
|
This command will take a snapshot of your /var filesystem and
|
|
leave it in the file /var/snapshot/snap1. Note that snapshot
|
|
files must be created in the filesystem that is being snapshotted.
|
|
I use the convention of putting a `snapshot' directory at the
|
|
root of each filesystem into which I can place snapshots.
|
|
You may create up to 20 snapshots per filesystem. Active snapshots
|
|
are recorded in the superblock, so they persist across unmount
|
|
and remount operations and across system reboots. When your
|
|
are done with a snapshot, it can be removed with the `rm'
|
|
command. Snapshots may be removed in any order, however you
|
|
may not get back all the space contained in the snapshot as
|
|
another snapshot may claim some of the blocks that it is releasing.
|
|
Note that the `schg' flag is set on snapshots to ensure that
|
|
not even the root user can write to them. The unlink command
|
|
makes an exception for snapshot files in that it allows them
|
|
to be removed even though they have the `schg' flag set, so it
|
|
is not necessary to clear the `schg' flag before removing a
|
|
snapshot file.
|
|
|
|
Once you have taken a snapshot, there are three interesting
|
|
things that you can do with it:
|
|
|
|
1) Run fsck on the snapshot file. Assuming that the filesystem
|
|
was clean when it was mounted, you should always get a clean
|
|
(and unchanging) result from running fsck on the snapshot.
|
|
If you are running with soft updates and rebooted after a
|
|
crash without cleaning up the filesystem, then fsck of the
|
|
snapshot may find missing blocks and inodes or inodes with
|
|
link counts that are too high. I have not yet added the
|
|
system calls to allow fsck to add these missing resources
|
|
back to the filesystem - that will be added once the basic
|
|
snapshot code is working properly. So, view those reports
|
|
as informational for now.
|
|
|
|
2) Run dump on the snapshot. You will get a dump that is
|
|
consistent with the filesystem as of the timestamp of the
|
|
snapshot. Note that I have not yet changed dump to set the
|
|
dumpdates file correctly, so do not use this feature in
|
|
production until that fix is made.
|
|
|
|
3) Mount the snapshot as a frozen image of the filesystem.
|
|
To mount the snapshot /var/snapshot/snap1:
|
|
|
|
vnconfig -c vn0c /var/snapshot/snap1
|
|
mount -r /dev/vn0c /mnt
|
|
|
|
You can now cruise around your frozen /var filesystem
|
|
at /mnt. Everything will be in the same state that it
|
|
was at the time the snapshot was taken. The one exception
|
|
is that any earlier snapshots will appear as zero length
|
|
files. When you are done with the mounted snapshot:
|
|
|
|
umount /mnt
|
|
vnconfig -u vn0c
|
|
|
|
Note that under some circumstances, the process accessing
|
|
the frozen filesystem may deadlock. I am aware of this
|
|
problem, but the solution is not simple. It requires
|
|
using buffer read locks rather than exclusive locks when
|
|
traversing the inode indirect blocks. Until this problem
|
|
is fixed, you should avoid putting mounted snapshots into
|
|
production.
|
|
|
|
|
|
Performance
|
|
|
|
It takes about 30 seconds to create a snapshot of an 8Gb filesystem.
|
|
Of that time 25 seconds is spent in preparation; filesystem activity
|
|
is only suspended for the final 5 seconds of that period. Snapshot
|
|
removal of an 8Gb filesystem takes about two minutes. Filesystem
|
|
activity is never suspended during snapshot removal.
|
|
|
|
The suspend time may be expanded by several minutes if a process
|
|
is in the midst of removing many files as all the soft updates
|
|
backlog must be cleared. Generally snapshots do not slow the system
|
|
down appreciably except when removing many small files (i.e., any
|
|
file less than 96Kb whose last block is a fragment) that are claimed
|
|
by a snapshot. Here, the snapshot code must make a copy of every
|
|
released fragment which slows the rate of file removal to about
|
|
twenty files per second once the soft updates backlog limit is
|
|
reached.
|
|
|
|
|
|
How Snapshots Work
|
|
|
|
For more general information on snapshots, please see:
|
|
http://www.mckusick.com/softdep/
|