jerry@oliveb.UUCP (Jerry Aguirre) (04/22/86)
I have also noticed that after a restore all the files marked as
changed and will go on the next dump. The 4.2BSD restore works on the
mounted file system. This simplifies the dump code and partial
restores but makes it impossible to correctly update the time stamps on
the file. Previous versions of restor used the raw file system and
could write any information it wanted.
Remember that dump will use the ctime, not the mtime, when deciding
what files to dump. There is no system call to backdate the ctime on a
mounted file system.
Procedurally this is a crock as after spending X hours of down time
restoring the file system, you have to turn around and spend Y
additional hours doing a new level 0 dump. Besides additional down
time the new level 0 also messes up the dump schedule.
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|glacier|olhqma}!oliveb!jerryrichl@tektools.UUCP (04/23/86)
In article <801@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: > I have also noticed that after a restore all the files marked as > changed and will go on the next dump. [ ... ] > > Procedurally this is a crock as after spending X hours of down time > restoring the file system, you have to turn around and spend Y > additional hours doing a new level 0 dump. If you really did just spend hours restoring the file system, then you have restored all or virtually all of the file system. If you don't want to do a level 0 dump, simply edit /etc/dumpdates to reflect whatever time you want dumps taken from. If you just restored the entire file system you have the entire system on tape anyway; so you won't miss anything by this. Rick Lindsley richl%tektools@tektronix.csnet ...!{ihnp4,decvax,cbosgd}!tektronix!tektools!richl
ed@mtxinu.UUCP (04/24/86)
In article <801@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >I have also noticed that after a restore all the files marked as >changed and will go on the next dump. The 4.2BSD restore works on the >mounted file system. This simplifies the dump code and partial >restores but makes it impossible to correctly update the time stamps on >the file. Previous versions of restor used the raw file system and >could write any information it wanted. 4.2 dump still dumps from the raw disk. It's restore that is simplified bu working on the mounted filesystem. The reason is that the code to decide where to place a block on the disk is *very* complex in 4.2 because, generally, of the optimizations used to make the filesystem fast to read. It was decided (and I agree) that having two copies of that code (one in the kernel and one in restore) was too dangerous. >Remember that dump will use the ctime, not the mtime, when deciding >what files to dump. There is no system call to backdate the ctime on a >mounted file system. > >Procedurally this is a crock as after spending X hours of down time >restoring the file system, you have to turn around and spend Y >additional hours doing a new level 0 dump. Besides additional down >time the new level 0 also messes up the dump schedule. There are other reasons, as well, for redoing the level 0 dump after doing a full restore. Directories relate to files via their inode number. In order that the new directory contents be recorded correctly, a new level 0 is required. If not, any incremental dump done - even if the times were correct - would not correctly relate to the old full(er) dump. This *is* documented in the "BUGS" section of the restore(1) writeup. I agree that it is a big nuisance to redo the level 0 dumps after a full restore. Hopefully, however, restores happen infrequently enough to justify the extra work to get the increased filesystem performance. -- Ed Gould mt Xinu, 2910 Seventh St., Berkeley, CA 94710 USA {ucbvax,decvax}!mtxinu!ed +1 415 644 0146 "A man of quality is not threatened by a woman of equality."
richl@tektools.UUCP (Rick Lindsley) (04/30/86)
In article <974@tektools.UUCP> richl@tektools.UUCP (Rick Lindsley) writes: > >If you really did just spend hours restoring the file system, then you >have restored all or virtually all of the file system. If you don't >want to do a level 0 dump, simply edit /etc/dumpdates to reflect >whatever time you want dumps taken from. If you just restored the entire > >file system you have the entire system on tape anyway; so you won't > >miss anything by this. > In article <8@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes: > THIS IS BOTH INCORRECT AND DANGEROUS! alas, Ed is correct. It's been too long since I've been intimate with dump and restore. Rewind and erase my previous message. Rick
nz@wucs.UUCP (05/01/86)
In article <974@tektools.UUCP> richl@tektools.UUCP (Rick Lindsley) writes: > In article <801@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: > > I have also noticed that after a restore all the files marked as > > changed and will go on the next dump. [ ... ] > > If you really did just spend hours restoring the file system, then you > have restored all or virtually all of the file system. If you don't > want to do a level 0 dump, simply edit /etc/dumpdates to reflect > ... In fact, this problem is due to a quirk in a dump/restore, the restored files have the correct modification time, but their creation times are the time of the restore! Repeat-By: Put a file system on a dummy partition, and do a level 0 dump(8) of it. Wait a few minutes. Then, trash the partition and restore it fully from your dump. Change one file. Now, do a level 1 backup with dump(8). The backup should be extremely small (one file) but it isn't! It is the whole filesystem! To Fix: Change dump so that it looks only at the modification time, not the creation and modification times. Here is a diff for the file dump/dumptraverse.c. My change is bracketed by some #ifdef-#else-#endif.s, you can take those out if you like. *** /tmp/,RCSt1018628 Thu May 1 14:40:45 1986 --- dumptraverse.c Fri Apr 4 11:34:08 1986 *************** *** 38,43 BIS(ino, clrmap); if(f == IFDIR) BIS(ino, dirmap); if ((ip->di_mtime >= spcl.c_ddate || ip->di_ctime >= spcl.c_ddate) && !BIT(ino, nodmap)) { BIS(ino, nodmap); --- 38,44 ----- BIS(ino, clrmap); if(f == IFDIR) BIS(ino, dirmap); + #ifndef MTIME_ONLY if ((ip->di_mtime >= spcl.c_ddate || ip->di_ctime >= spcl.c_ddate) && #else if ((ip->di_mtime >= spcl.c_ddate ) && *************** *** 39,44 if(f == IFDIR) BIS(ino, dirmap); if ((ip->di_mtime >= spcl.c_ddate || ip->di_ctime >= spcl.c_ddate) && !BIT(ino, nodmap)) { BIS(ino, nodmap); if (f != IFREG && f != IFDIR && f != IFLNK) { --- 40,48 ----- BIS(ino, dirmap); #ifndef MTIME_ONLY if ((ip->di_mtime >= spcl.c_ddate || ip->di_ctime >= spcl.c_ddate) && + #else + if ((ip->di_mtime >= spcl.c_ddate ) && + #endif !BIT(ino, nodmap)) { BIS(ino, nodmap); if (f != IFREG && f != IFDIR && f != IFLNK) { We use this modified version some of the time. I noticed the problem, and made the changes, after a series of disk crashes and fixes that required full restores. Boy, the next weekends backups were big! Hmmm... Anyway, I hope this is helpful to some folks out there. -- ...nz (Neal Ziring at WU ECL - we're here to provide superior computing.) {seismo,ihnp4,cbosgd}!wucs!nz OR nz@wucs.UUCP "You could get an infinite number of wires into this !*$$#!?! junction box, but we usually don't go that far in practice" -- Employee of London Electricity Board, 1959
smb@ulysses.UUCP (Steven Bellovin) (05/03/86)
(discussions about dump/restore). > To Fix: > Change dump so that it looks only at the modification time, not > the creation and modification times. No! Dump is behaving exactly properly; if you install this fix you'll lose the results of chmod calls, access time, etc.
dave@onfcanim.UUCP (Dave Martindale) (05/03/86)
In article <1631@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes: > > > I have also noticed that after a restore all the files marked as > > > changed and will go on the next dump. [ ... ] > > > > If you really did just spend hours restoring the file system, then you > > have restored all or virtually all of the file system. If you don't > > want to do a level 0 dump, simply edit /etc/dumpdates to reflect > > ... > >In fact, this problem is due to a quirk in a dump/restore, the >restored files have the correct modification time, but their creation >times are the time of the restore! > >Repeat-By: > Put a file system on a dummy partition, and do a level 0 > dump(8) of it. Wait a few minutes. Then, trash the partition > and restore it fully from your dump. Change one file. > Now, do a level 1 backup with dump(8). The backup should be > extremely small (one file) but it isn't! It is the whole > filesystem! > >To Fix: > Change dump so that it looks only at the modification time, not > the creation and modification times. > If you think of a dump as "all the files that have changed *contents* since the most recent higher-level dump", then you do indeed want to dump according to modification times. But this is **not** what dump was written to do. It is intended to write out *all* the information needed to restore *all* changes made to the filesystem, including changes in permissions or link count of a file. These latter things change the inode's "di_ctime", which is really "change" not "create" time. So, if you want to use dump and restore as a method of completely restoring the state of a filesystem, not just getting back all the contents of the files, don't change the algorithm. And if you run 4.[23] BSD, you will still have to do level 0 dump after doing a full restore. No way of avoiding it. Dave Martindale
richl@tektools.UUCP (Rick Lindsley) (05/05/86)
In article <1631@wucs.UUCP> nz@wucs.UUCP (Neal Ziring) writes: > > In fact, this problem is due to a quirk in a dump/restore, the > restored files have the correct modification time, but their creation > times are the time of the restore! > As previously discussed, 4.2 & 4.3 restore do not use the raw disk, so they cannot maintain the ctime on the files. But changing dump to not look at the ctime could bite you in a big way -- ctime is changed if the owner, group, or mode was changed. Looking at the mtime will guarantee that you have a correct *copy* of the binary, but it may not be the correct owner, group, or mode! Also, if you link two files together, the new link won't appear on your dump because changing the link count changes the ctime, not the mtime. And of course, the reasons for doing a level 0 dump after a restore have also been expounded upon in this space. Rick