Submission for comp-unix-microport

[UNIX-UNIX Cp]

Path: tolerant!voder!apple!rutgers!ucsd!sdcsvax!ucsdhub!hp-sdd!ncr-sd!ncrlnk!uunet!attcan!utgpu!tmsoft!mcl!unibase!roe
From: roe at unibase.UUCP (Roe Peterson)
Newsgroups: comp.unix.microport
Subject: Re: Efficient tape I/O, Followup.
Message-ID: <105 at unibase.UUCP>
Date: 22 Dec 88 07:33:39 GMT
References: <321 at focsys.UUCP>
Organization: EMIS Consulting, Regina, Saskatchewan, Canada
Lines: 38

>From article <321 at focsys.UUCP>, by larry at focsys.UUCP (Larry Williamson):
> | 
> | 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.
> 
  ... description of many good attempts with dd, etc, deleted.

> A 500k write takes about an hour!

Here's the problem: it sounds like your operating system is either implementing
tape I/O in a blocked fashion (ie: 1K blocks, no chance to change it), or it
implements both, and your /dev/rmt0 should actually be called /dev/mt0.

If find..|dd with a large block size does not change the duration of a write
to the tape (listen to it - with large blocks, the forward motion is audibly
much longer), the device driver is chopping data into small blocks for you
(this is a nono).

Raw device drivers (at least, for tape) are not supposed to do this.

Some systems provide both blocked and character (true rawmode) tape devices-
check your manual (try mt(4) or mt(7)).

Incidentally, on systems with proper device drivers (ie, most I've seen),
the best way to approach streaming speed is with a utility that uses
shared memory between the writer and the tape device to collect input into
larger blocks.  The advantage here is that the writer will not block waiting
for the output to occur.

If there is enough interest, I'll post a small buffering utility to
comp.sources.misc.

						Roe Peterson.
-- 

                                  Roe Peterson
                                  uunet!attcan!utgpu!tmsoft!mcl!unibase!roe