Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: Why is restore so slow?
Message-ID: <19028@rpp386.cactus.org>
Date: 5 Feb 91 14:10:11 GMT
References: <19023@rpp386.cactus.org> <1022@eplunix.UUCP>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 31
X-Clever-Slogan: Recycle or Die.

In article <1022@eplunix.UUCP> das@eplunix.UUCP (David Steffens) writes:
>Your boss will be even _more_ annoyed with you when he discovers
>that you _cannot_ restore that file because you (or your OS vendor)
>mucked around with dump/restore in order to "improve performance",
>successfully trading reliability for some piddling increase in speed!

In my original response I noted that reliability is the number one
concern.  This means that performance, which is a significant concern
because of human factors, should be improved whenever possible to not
impact reliability.  There are quite a few programming techniques
which could be heaved at dump and restore which would greatly increase
performance or usability without impacting reliability at all.  The
increases in performance which I've seen made to dump/restore with
zero decrease in reliability range from 2x to 10x.

As I stated earlier as well, the best written dump/restore type of
utility I've used was free software from Archive Corp that was included
with a tape drive I had purchased for a MS-DOS/PC.  It included double
buffering to drive the tape and disk at their limits and a point-
and-shoot interface for navigating the tape.  In terms of reliability,
usability and performance, this was a 4-star product.  By comparision,
dump/restore is 3-stars for reliability, and 1-star each for
performance and usability, IMNSHO.  As would be predicted, the user's
of that particular PC were very willing to backup and restore their
own files given the ease and speed with which the task could be
accomplished.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"I've never written a device driver, but I have written a device driver manual"
                -- Robert Hartman, IDE Corp.