Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!seismo!brl-tgr!tgr!speck%cit-vlsi@CIT-VAX.ARPA
From: speck%cit-vlsi@CIT-VAX.ARPA (Don Speck)
Newsgroups: net.unix-wizards
Subject: Re: dump(8) verification?
Message-ID: <2054@brl-tgr.ARPA>
Date: Fri, 11-Oct-85 01:54:39 EDT
Article-I.D.: brl-tgr.2054
Posted: Fri Oct 11 01:54:39 1985
Date-Received: Sat, 12-Oct-85 07:31:24 EDT
Sender: news@brl-tgr.ARPA
Lines: 53

>   has anyone hacked dump to perform a verify pass on the data dumped?

    There are several levels of "verify" that one might want:

[1] Read the tape end-to-end just to see if read() returns any errors.

[2] Record the checksum of each block written, read the tape, compute
    the checksums of the blocks read, and compare.

[3] After each tape, repeat pass IV with the tape write() replaced
    with a read(), and compare with the disk data.

I suspect that the last of these is what the original poster had in
mind.  The trouble (aside from being slow) is that ANY filesystem
activity will cause a compare of "not identical".  Let's say the last
modify time of /dev/rmt8 changed while I was dumping, and I get a
"not identical" compare.  Does that mean that my dump of the root
filesystem was incorrect?  (Think!)  Some discrepancies are inevitable,
and cause no harm.  Unless these inconsequential diagnostics are
suppressed, the output becomes mostly noise, hence worse than useless.

Some of us aren't allowed the luxury of coming down to single-user
mode for dumps, or even dismounting filesystems.  For instance, an
availability of only 99% on our Sun diskservers would be considered
by faculty and staff as cause for serious emergency finger-pointing
meetings.  Taking our whole Sun network down 3 hours per Eagle for
full rdumps... look, I dislike the sight of gore.

When dumping active filesystems, there can be files on the tape
that are no longer on the disk.  It might be quite difficult to
resynchronize the comparison.  Dump(8) would need to have most
of restore(8) built into it.

Even the seemingly paranoid level of checking in [3] is hardly a
guarantee that the tape can be restored.  I remembering spending
a day re-doing dumps of a particular filesystem on our 780, NONE
of which would restore onto our 750, before discovering that the
filesystem being dumped wouldn't pass fsck.  The only way to be
SURE that the dump can be restored, is to run restore!

The only verification I do (it's all I can *afford*) is to list
my dumps with "restore t".  This gives me at least some minimal
sanity-check, and the listings come in handy when I must restore
accidentally deleted files.  Our sole GCR drive spends 12 hours
per week doing dumps and rdumps, growing longer despite my best
speedup efforts; I can ill afford to double that time for dubious
assurances.  However, schemes [1] and [2] might be cheap enough
to use.  Anyone care to convince me that one of these is worthwhile?
I certainly know how to implement them...

			Don Speck   speck@cit-vax.arpa

Yeah, I know, I should shell out $9K for another GCR drive.