Tape backup performance on 386 ISA/EISA systems

[Ron Kuris]

In article <1990May30.132457.6117 at virtech.uucp> cpcahil at virtech.UUCP (Conor P. Cahill) writes:
>In article <1990May26..841 at rdk386.uucp> ron at rdk386.UUCP (Ron Kuris) writes:
>>In article <1990May25.123302.26061 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) writes:
>>> [ stuff deleted ]
>>Seems to me like you're not taking into account filesystem fragmentation
>>or a bunch of other factors.  How about running a disk optimizer (e.g.
>>shuffle) before you start the test?  I've noticed a dramatic increase due
>>to less head activity (I don't have numbers handy).
>
>For several reasons:
>
>1. There are no commercial disk optimzers for UNIX (at least that I know of)
>and most people, myself included, cringe at the thought of letting someone's
>program hunt around my raw disk patching things together.  I'm not saying
>that the programs are bad. I'm just saying that it will take a lot more
>than a simple post to alt.sources to get me to run one of those programs
>on my production systems.  Anyway, I can't ask people to run one when they
>may not even have it.
You don't have to run one -- how about a backup then a mkfs, then a restore,
then the REAL backup?

>2. The performance of the disk due to optimizations will probably have
>little performance effect on the overall perforance on the tape write, since
>the tape write is the limiting factor.

I get double the performance on an optimized backup as compared to an
unoptimized backup.  Reason:  My tape streams when everything is optimal,
and does NOT when it is not optimal.  I know this because originally my
disks were not backed up and restored at all.  When I finally did this,
my backup time was halved!
-- 
--
...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron
It's not how many mistakes you make, its how quickly you recover from them.