Date: Wed, 05 Jul 2000 20:42:18 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: arch@freebsd.org Subject: Snapshots in the Fast Filesystem Message-ID: <200007060342.UAA23667@beastie.mckusick.com>
next in thread | raw e-mail | index | archive | help
I have completed an initial implementation of snapshots for the fast filesystem (UFS/FFS). I have put up a tarball on http://people.freebsd.org/~mckusick/snap.tgz I am looking for comments and feedback on these changes. I am proposing to put them into 5.0-current on Tuesday July 11th unless I get feedback indicating that folks are not happy with this addition. Enclosed below is the README file that is included in the above tarball. Kirk McKusick =-=-=-=-=-=-=-= <details on installing the patch deleted> Once you have a new kernel running, and new versions of fsck and mount (which a `make world' should provide for you), you are ready to try out 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. 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 (twenty seconds if you are runnong with soft updates). Filesystem activity is never suspended during snapshot removal. 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. So, as you can see, this is definitely alpha-quality code. Much remains to be done to make it really useful in production systems. But, I wanted to let folks get a chance to try it out and start reporting bugs. Kirk McKusick July 5, 2000 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007060342.UAA23667>