Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!pyramid!pesnta!hplabs!qantel!lll-lcc!unisoft!mtxinu!ed
From: ed@mtxinu.UUCP
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: 4.2BSD restore(8)
Message-ID: <2@mtxinu.UUCP>
Date: Thu, 24-Apr-86 03:25:57 EDT
Article-I.D.: mtxinu.2
Posted: Thu Apr 24 03:25:57 1986
Date-Received: Sun, 27-Apr-86 04:57:28 EDT
References: <2066@hao.UUCP> <801@oliveb.UUCP>
Reply-To: ed@mtxinu.UUCP (Ed Gould)
Distribution: net
Organization: mt Xinu, Berkeley, CA
Lines: 42
Keywords: 4.2BSD restore ctime
Xref: watmath net.unix-wizards:17809 net.bugs.4bsd:2071

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."