Path: utzoo!attcan!uunet!littlei!lint.i.intel.com!vrs
Newsgroups: comp.unix.microport
Subject: Re: Efficient tape I/O with 386/ix; How??
Keywords: streaming tape interactive slow
Message-ID: <447@gandalf.littlei.UUCP>
Date: 12 Dec 88 23:11:26 GMT
References: <317@focsys.UUCP> <251@dcs.UUCP>
Sender: news@littlei.UUCP
Reply-To: vrs@lint.i.intel.com (Vincent R. Slyngstad)
Organization: Intel Corp., OMSO UNIX Development, Hillsboro, OR
Lines: 40

#In article <317@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes:
# >Streaming tape I/O with 386/ix seems to be rather slow.  The drive
# >is not streaming very well.  It spends most of it's time stopping
# >and starting.  I'm using an Everex Excel 60 with a long controller
# >card. 
# >
# >The command I've used is
# >	find . -print | cpio -ovc >/dev/rmt0
# >
There are two problems here: 1) The data transfers are done on small
buffers (5K bytes, I believe), and 2) cpio blocks in the write when it
should be reading the disk to create more output.

In article <251@dcs.UUCP> wnp@dcs.UUCP (Wolf N. Paul) writes:
#It seems to me that you should be able to achieve the effect of the
#"strm" utility on Uport 286 (and other similar utilities, i.e. "stream"
#as supplied with the Bell Tech driver, etc.) by using "dd" with a large
#block size. You may need to experiment to find out how large a block
#size your system will allow, but try something like this:
#
#  find . -print | cpio -ocv | dd of=/dev/rmt0 bs=64k
This decouples the reading done by CPIO from the writing done by DD, and
sometimes CPIO will be able to compute output fast enough to keep the tape
streaming.  This does not work well on my machine, though.  Here's the
command that I use:

	find . -print | cpio -oBcv | dd of=/dev/rmt0 ibs=5k obs=500k

With this command, DD will always wait until 500K have accumulated before
writing the tape (except at EOF, of course).  Then the tape is guaranteed
to stream at least that 500K.  Since my tape is still generally faster than
my disk, this command tends to read the disk more or less continuously,
writing the tape in long bursts, each of which keeps the tape streaming
for a minute or so.

The net result begins to feel like:

	find . -print | cpio -oBcv >/dev/null

except that a backup tape actually exists at the end.