Why is restore so slow?

[David Steffens]

All right, my $0.02 on this issue.

Who cares how slow restore is?  How often do you do have to do
full restore on a filesystem or a whole disk?  Once or twice a year?
If it's more often than that, then you have a REAL problem
and maybe you ought to spend your time and energy fixing THAT!

And none of your fancy programming tricks for me, thank you.
I'd much rather have a SLOW restore that was guaranteed to WORK
than one that was FAST and had unknown bugs because of some
magic algorithm that wasn't tested under all possible conditions.
My users and I would rather wait longer for a reliable restoration
of our files than have incomplete or inaccurate results in a hurry.

Reminds me of the 4.2bsd restore which claimed to have a checkpoint
option that supposedly allowed the restore to be stopped and restarted.
Never could get it to work correctly for us.  Wasted an awful lot
of time on that one.  I also remember the Ultrix1.1 dump which DEC
tried to "improve".  Unfortunately, one of their "optimizations"
had a small, undiscovered side-effect -- the highest-numbered inode
on the filesystem was never written on the dump tape.  Produced no end
of fun during the restore if said inode happened to be a directory.

I don't wish to repeat these experiences!  Repeat after me, the three
most important performance characteristics of dump and restore are:
	RELIABILITY, RELIABILITY and RELIABILITY.
-- 
David Allan Steffens       | I believe in learning from past mistakes...
Eaton-Peabody Laboratory   | ...but does a good education require so many?
Mass. Eye & Ear Infirmary, 243 Charles Street, Boston, MA 02114
{harvard,mit-eddie,think}!eplunix!das      (617) 573-3748 (1400-1900h EST)