sys/ufs/ffs/README.snapshot

   1 $FreeBSD$
   2
   3 Soft Updates Status
   4
   5 As is detailed in the operational information below, snapshots
   6 are definitely alpha-test code and are NOT yet ready for production
   7 use. Much remains to be done to make them really useful, but I
   8 wanted to let folks get a chance to try it out and start reporting
   9 bugs and other shortcomings. Such reports should be sent to
  10 Kirk McKusick <mckusick@mckusick.com>.
  11
  12
  13 Snapshot Copyright Restrictions
  14
  15 Snapshots have been introduced to FreeBSD with a `Berkeley-style'
  16 copyright. The file implementing snapshots resides in the sys/ufs/ffs
  17 directory and is compiled into the generic kernel by default.
  18
  19
  20 Using Snapshots
  21
  22 To create a snapshot of your /var filesystem, run the command:
  23
  24         mount -u -o snapshot /var/snapshot/snap1 /var
  25
  26 This command will take a snapshot of your /var filesystem and
  27 leave it in the file /var/snapshot/snap1. Note that snapshot
  28 files must be created in the filesystem that is being snapshotted.
  29 I use the convention of putting a `snapshot' directory at the
  30 root of each filesystem into which I can place snapshots.
  31 You may create up to 20 snapshots per filesystem. Active snapshots
  32 are recorded in the superblock, so they persist across unmount
  33 and remount operations and across system reboots. When you
  34 are done with a snapshot, it can be removed with the `rm'
  35 command. Snapshots may be removed in any order, however you
  36 may not get back all the space contained in the snapshot as
  37 another snapshot may claim some of the blocks that it is releasing.
  38 Note that the `schg' flag is set on snapshots to ensure that
  39 not even the root user can write to them. The unlink command
  40 makes an exception for snapshot files in that it allows them
  41 to be removed even though they have the `schg' flag set, so it
  42 is not necessary to clear the `schg' flag before removing a
  43 snapshot file.
  44
  45 Once you have taken a snapshot, there are three interesting
  46 things that you can do with it:
  47
  48 1) Run fsck on the snapshot file. Assuming that the filesystem
  49    was clean when it was mounted, you should always get a clean
  50    (and unchanging) result from running fsck on the snapshot.
  51    If you are running with soft updates and rebooted after a
  52    crash without cleaning up the filesystem, then fsck of the
  53    snapshot may find missing blocks and inodes or inodes with
  54    link counts that are too high. I have not yet added the
  55    system calls to allow fsck to add these missing resources
  56    back to the filesystem - that will be added once the basic
  57    snapshot code is working properly. So, view those reports
  58    as informational for now.
  59
  60 2) Run dump on the snapshot. You will get a dump that is
  61    consistent with the filesystem as of the timestamp of the
  62    snapshot.
  63
  64 3) Mount the snapshot as a frozen image of the filesystem.
  65    To mount the snapshot /var/snapshot/snap1:
  66
  67         mdconfig -a -t vnode -f /var/snapshot/snap1 -u 4
  68         mount -r /dev/md4 /mnt
  69
  70    You can now cruise around your frozen /var filesystem
  71    at /mnt. Everything will be in the same state that it
  72    was at the time the snapshot was taken. The one exception
  73    is that any earlier snapshots will appear as zero length
  74    files. When you are done with the mounted snapshot:
  75
  76         umount /mnt
  77         mdconfig -d -u 4
  78
  79    Note that under some circumstances, the process accessing
  80    the frozen filesystem may deadlock. I am aware of this
  81    problem, but the solution is not simple. It requires
  82    using buffer read locks rather than exclusive locks when
  83    traversing the inode indirect blocks. Until this problem
  84    is fixed, you should avoid putting mounted snapshots into
  85    production.
  86
  87
  88 Performance
  89
  90 It takes about 30 seconds to create a snapshot of an 8Gb filesystem.
  91 Of that time 25 seconds is spent in preparation; filesystem activity
  92 is only suspended for the final 5 seconds of that period. Snapshot
  93 removal of an 8Gb filesystem takes about two minutes. Filesystem
  94 activity is never suspended during snapshot removal.
  95
  96 The suspend time may be expanded by several minutes if a process
  97 is in the midst of removing many files as all the soft updates
  98 backlog must be cleared. Generally snapshots do not slow the system
  99 down appreciably except when removing many small files (i.e., any
 100 file less than 96Kb whose last block is a fragment) that are claimed
 101 by a snapshot. Here, the snapshot code must make a copy of every
 102 released fragment which slows the rate of file removal to about
 103 twenty files per second once the soft updates backlog limit is
 104 reached.
 105
 106
 107 How Snapshots Work
 108
 109 For more general information on snapshots, please see:
 110         http://www.mckusick.com/softdep/