mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-20 11:11:24 +00:00
33fc362512
filesystem supports additional operations using shared vnode locks. Currently this is used to enable shared locks for open() and close() of read-only file descriptors. - When an ISOPEN namei() request is performed with LOCKSHARED, use a shared vnode lock for the leaf vnode only if the mount point has the extended shared flag set. - Set LOCKSHARED in vn_open_cred() for requests that specify O_RDONLY but not O_CREAT. - Use a shared vnode lock around VOP_CLOSE() if the file was opened with O_RDONLY and the mountpoint has the extended shared flag set. - Adjust md(4) to upgrade the vnode lock on the vnode it gets back from vn_open() since it now may only have a shared vnode lock. - Don't enable shared vnode locks on FIFO vnodes in ZFS and UFS since FIFO's require exclusive vnode locks for their open() and close() routines. (My recent MPSAFE patches for UDF and cd9660 already included this change.) - Enable extended shared operations on UFS, cd9660, and UDF. Submitted by: ups Reviewed by: pjd (ZFS bits) MFC after: 1 month |
||
|---|---|---|
| .. | ||
| ffs_alloc.c | ||
| ffs_balloc.c | ||
| ffs_extern.h | ||
| ffs_inode.c | ||
| ffs_rawread.c | ||
| ffs_snapshot.c | ||
| ffs_softdep.c | ||
| ffs_subr.c | ||
| ffs_tables.c | ||
| ffs_vfsops.c | ||
| ffs_vnops.c | ||
| fs.h | ||
| README.snapshot | ||
| softdep.h | ||
$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/