roy@phri.UUCP (Roy Smith) (06/08/88)
indermau@dg.cs.umn.edu.UUCP (Kurt Indermaur) writes: > What is an "active file system"? Nobody logged in? Single user mode? For all intents and purposes, an active file system is one mounted with write permission. I believe there have been some mods to the 4.2BSD dump posted (probably by Don Speck, and probably included in the 4.3 version of dump) which help make dump more immune to file system activity. Note that this doesn't mean that dump is guaranteed to work properly on an active file system, just that it is less likely to mess up. These changes were a grudging concession to the fact that most people just can't afford to dismount their user's files every day to do incrmentals. For example, we do daily and weekly dumps while the system is running full-tilt. Monthlys and quarterlies (the latter being archival level-0's) are done with the system single-user. Also along this line, note that in SunOS-4.0, the system comes up with root mounted read-only so fsck can work more reliably and is later changed to r/w for normal use. Presumably you can do level-0 root dumps with the root in this read-only state. -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
rbj@icst-cmr.arpa (Root Boy Jim) (06/09/88)
From: Kurt Indermaur <indermau@dg> In the man pages for restore, under "BUGS", is the sentence "Restore can get confused when doing incremental restores from dump tapes that were made on active file systems." What is an "active file system"? Nobody logged in? Single user mode? This doesn't answer all you questions, but a file system that is unmounted, or mounted read-only is inactive. Dump root and user in single user mode, and you can do the rest this way. My home directory is on a very large root for exactly this reason. I recently had a bad experience with dump/restore, which resulted (I think) from an active file system when the dump was made, and I'd like to avoid those problems in the future. I have also had bad experiences with incremental restores, so I never do them. I always do a restore x into a virgin directory and merge the results by hand. I consider full dumps sacred, to be done correctly, and incremental dumps somewhat open to error, but this is my personal preference. Thanks again, Kurt Indermaur (indermau@dg.cs.umn.edu) (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement My name is in /usr/dict/words. Is yours?
mangler@cit-vax.Caltech.Edu (Don Speck) (06/10/88)
In article <3339@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > I believe there have been some mods to the 4.2BSD > dump posted (probably by Don Speck, and probably included in the 4.3 > version of dump) which help make dump more immune to file system activity. Those mods pre-date the parts that I did. I first saw them in the "mass-driver" diffs that Chris Torek sent me in January 1985. They skip inodes that have been zeroed (deleted) during the dump, as opposed to the Purdue mods, which also skip inodes whose st_mtime has changed (such as /dev/tty and /dev/rmt8). To see how much difference the 4.3 mods made, I copied a small filesystem to /usr/tmp, then started a simultaneous dump to tape and "rm -r". Restore would dump core after typically 20% of each tape made by 4.2 dump, but typically made it through 80% (and sometimes all) of each tape made by 4.3 dump. Part of the difference is that 4.3 dump finished before the "rm -r", so the filesystem was not modified as much during the dump. An "active filesystem" is one suffering deletions, renamings, and (to a smaller extent) truncations. Dump will not see files created during the dump, and restore should not care about access times being updated. Directories changing between passes II and III is what confuses restore. By way of illustration, I once modified dump to start on the mapping passes while the first tape was being mounted. Restore choked on dumps started right before the operator's meal break, which was putting a one-hour wait between passes II and III. Don Speck speck@vlsi.caltech.edu {amdahl,ames!elroy}!cit-vax!speck
allbery@ncoast.UUCP (Brandon S. Allbery) (06/18/88)
As quoted from <5757@umn-cs.cs.umn.edu> by indermau@dg (Kurt Indermaur): +--------------- | In the man pages for restore, under "BUGS", is the sentence "Restore can get | confused when doing incremental restores from dump tapes that were made on | active file systems." What is an "active file system"? Nobody logged in? | Single user mode? +--------------- A file system is active if it's mounted. It *is* possible to dump a mounted file system if you sync beforehand and make absolutely *certain* that nobody does *anything* on the filesystem -- even "echo /being-dumped/*" can screw things up, as the st_atime of the directory /being-dumped will be updated. -- Brandon S. Allbery | "Given its constituency, the only uunet!marque,sun!mandrill}!ncoast!allbery | thing I expect to be "open" about Delphi: ALLBERY MCI Mail: BALLBERY | [the Open Software Foundation] is comp.sources.misc: ncoast!sources-misc | its mouth." --John Gilmore
chris@mimsy.UUCP (Chris Torek) (06/28/88)
In article <8158@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: >A file system is active if it's mounted. Most people consider it active iff it is being written. >It *is* possible to dump a mounted file system if you sync beforehand >and make absolutely *certain* that nobody does *anything* on the >filesystem -- even "echo /being-dumped/*" can screw things up, as the >st_atime of the directory /being-dumped will be updated. This is rather minor---you either get the old atime or the new atime, since the atime does not cross a disk block boundary (assuming 512 byte sectors, or multiples thereof). You can also dump a file system that is mounted read-only. This is often suitable for NFS servers. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris