Xref: utzoo comp.unix.i386:5575 comp.unix.questions:22646
Path: utzoo!utgpu!watserv1!watmath!att!pacbell!sactoh0!unify!rdk386!ron
From: ron@rdk386.uucp (Ron Kuris)
Newsgroups: comp.unix.i386,comp.unix.questions
Subject: Re: Tape backup performance on 386 ISA/EISA systems
Keywords: tape, performance, 386
Message-ID: <1990Jun3..23883@rdk386.uucp>
Date: 3 Jun 90 21:53:05 GMT
References: <1990May25.123302.26061@virtech.uucp> <1990May26..841@rdk386.uucp> <1990May30.132457.6117@virtech.uucp>
Reply-To: ron@rdk386.UUCP (Ron Kuris)
Organization: At Home, Sacramento, CA
Lines: 34

In article <1990May30.132457.6117@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
>In article <1990May26..841@rdk386.uucp> ron@rdk386.UUCP (Ron Kuris) writes:
>>In article <1990May25.123302.26061@virtech.uucp> cpcahil@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.