freebsd-dev/sys/ufs/ffs
Attilio Rao 0e9eb108f0 Cleanup lockmgr interface and exported KPI:
- Remove the "thread" argument from the lockmgr() function as it is
  always curthread now
- Axe lockcount() function as it is no longer used
- Axe LOCKMGR_ASSERT() as it is bogus really and no currently used.
  Hopefully this will be soonly replaced by something suitable for it.
- Remove the prototype for dumplockinfo() as the function is no longer
  present

Addictionally:
- Introduce a KASSERT() in lockstatus() in order to let it accept only
  curthread or NULL as they should only be passed
- Do a little bit of style(9) cleanup on lockmgr.h

KPI results heavilly broken by this change, so manpages and
FreeBSD_version will be modified accordingly by further commits.

Tested by: matteo
2008-01-24 12:34:30 +00:00
..
ffs_alloc.c Fix a broken check that recently became more annoying because it now 2007-12-01 13:12:43 +00:00
ffs_balloc.c ffs_balloc_ufsX() routines, in the case of recovering from the failed 2008-01-03 12:28:57 +00:00
ffs_extern.h Cylinder group bitmaps and blocks containing inode for a snapshot 2007-01-23 10:01:19 +00:00
ffs_inode.c Turn most ffs 'DIAGNOSTIC's into INVARIANTS. 2007-11-08 17:21:51 +00:00
ffs_rawread.c VOP_LOCK1() (and so VOP_LOCK()) and VOP_UNLOCK() are only used in 2008-01-13 14:44:15 +00:00
ffs_snapshot.c Cleanup lockmgr interface and exported KPI: 2008-01-24 12:34:30 +00:00
ffs_softdep.c VOP_LOCK1() (and so VOP_LOCK()) and VOP_UNLOCK() are only used in 2008-01-13 14:44:15 +00:00
ffs_subr.c /* -> /*- for license, minor formatting changes 2005-01-07 02:29:27 +00:00
ffs_tables.c /* -> /*- for license, minor formatting changes 2005-01-07 02:29:27 +00:00
ffs_vfsops.c Cleanup lockmgr interface and exported KPI: 2008-01-24 12:34:30 +00:00
ffs_vnops.c Cleanup lockmgr interface and exported KPI: 2008-01-24 12:34:30 +00:00
fs.h Add gjournal specific code to the UFS file system: 2006-10-31 21:48:54 +00:00
README.snapshot
softdep.h - Move softdep from using a global worklist to per-mount worklists. This 2006-03-02 05:50:23 +00:00

$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 you
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.

3) Mount the snapshot as a frozen image of the filesystem.
   To mount the snapshot /var/snapshot/snap1:

	mdconfig -a -t vnode -f /var/snapshot/snap1 -u 4
	mount -r /dev/md4 /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
	mdconfig -d -u 4

   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/