Xref: utzoo comp.unix.i386:5443 comp.unix.questions:22511
Path: utzoo!attcan!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.unix.i386,comp.unix.questions
Subject: Re: Tape backup performance on 386 ISA/EISA systems
Keywords: tape, performance, 386
Message-ID: <1990May30.132457.6117@virtech.uucp>
Date: 30 May 90 13:24:57 GMT
References: <1990May25.123302.26061@virtech.uucp> <1990May26..841@rdk386.uucp>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 26

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.

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.

-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170