Why is restore so slow?

David Steffens das at eplunix.UUCP
Sun Feb 3 08:02:47 AEST 1991


In article <19019 at rpp386.cactus.org>,
jfh at rpp386.cactus.org (John F Haugh II) says:
> ... The most likely real-world ordering is probably reliability,
> usablity and performance... but you can't ignore all else -
> performance and usability really do count for quite a bit,
> because you are dealing with perceptions
> which affect how the user views the software...

If we were talking about any other unix utility (users, perhaps? :-),
I would probably agree with you.  But we're not.  We're talking about
restore, and to a lesser extent dump.  A similar, albeit weaker, case
can be made for tar and cpio since these utilities are also frequently
used in situations that demand extremely high reliabilty, e.g. archiving.

Unlike most unix utilities, there's only ONE reason to use restore...
to recover lost data.  If restore fails to perform this function,
then NO other performance characteristics matter.  Partial or inaccurate
recovery of data in a hurry is simply not very useful, IMHO.

> ... No, the psychology of computer users is such that any process
> which is SLOW will be avoided...

Users have nothing to do with it -- dump/restore is a sysadmin task.
And as an experienced sysadmin, I can tell you from hard-won personal
experience that a procedure that is slow but reliable is almost
always to be preferred to one that is faster but screws up occasionally.
The reason should be obvious -- in the long run, the time required
to detect and correct failures will probably far exceed the time saved.

> ... Although RELIABILITY is paramount, any process
> which operators are inclined to skip is of no value - they
> will pick the first less reliable process which is markedly faster...

The I Ching says: Inferior people should not be employed. :-)
-- 
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)



More information about the Comp.unix.internals mailing list