Path: utzoo!attcan!uunet!zephyr.ens.tek.com!tekcrl!tekgvs!keithe
From: keithe@tekgvs.LABS.TEK.COM (Keith Ericson)
Newsgroups: comp.unix.i386
Subject: Re: Tape backup performance on 386 ISA/EISA systems
Keywords: tape, performance, 386
Message-ID: <7597@tekgvs.LABS.TEK.COM>
Date: 2 Jun 90 01:09:54 GMT
References: <1990May25.123302.26061@virtech.uucp> <1990May26..841@rdk386.uucp> <1990May30.132457.6117@virtech.uucp> <1060@sixhub.UUCP>
Reply-To: keithe@tekgvs.LABS.TEK.COM (Keith Ericson)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 19

In article <1060@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
<In article <1990May30.132457.6117@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes:
<| 
<| 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'm sorry, this is just totally wrong. You must never have had a
<fragmented disk. I have seen transfer rates as low as 300kBytes/sec with
<a fragmented disk and streaming tape which ran in fits and starts. I see
<about 4MB overall (from the time I hit return to the time the tape is
<rewound) on a non-fragmented f/s.

By far and away the biggest difference I've ever seen in disk<->tape
transfers is the size of the buffer uses in the cpio command: I generally
use cpio -[i,o] [???] -C 1048576 -[I,O] /dev/tape  for screaming, if not
streaming, tape I/O.

kEITHe