Streaming tape and 386/ix (summary)

Avi Schwartz avi at chinet.chi.il.us
Tue Jul 31 14:43:40 AEST 1990


Last week I posted the following plea for help:

>I saw a question some time ago about the same problem but haven't seen the
>answer:
>
>I am using an Adaptec 1542 scsi controller and a Wangtec 5150 ES tape drive.
>When writing to the drive I cannot get the tape to stream and it is extremely 
>slow.  Is the problem with the kernel configuration or with the hardware?
>
>Any help will be highly appreciated.  Please reply by e-mail, and I'll post a
>summery.
>-- 

Well, I guess it is time for the summary (and not summery :-) ).  What I found
out from the following replies is that there is really no good way to achieve a
streaming operation of the cartridge tape under ISC's 386ix (unix in general?).
The only way, so it seems, to get a reasonable writing rate is by writing blocks
as big as possible but not bigger than 360K (as you'll find out).

I have the source code for both mentioned utilities (ddd and afio) and I am
willing to e-mail them if you don't have any other way to get them.


Thanks again to Richard Foulk
                Doug Pintar
                Larry Snyder
                Mark McWiggins for replying to my help plea.


Here are the replies I recieved, some slightly edited:
======================================================

Richard Foulk		richard at pegasus.com

After lots of testing with various programs, including tar, cpio, afio,
dd, gnutar, buffer and ddd I've only found one way to get my Wangtec drive
to stream, via ddd.  Ddd is a double-buffering clone of dd.  I normally
use it like this:

	find dirs -depth -print > FILES
	cpio -ocB < FILES | ddd of=/dev/tape obs=100b cbs 500b

Doing the find separately isn't mandatory for streaming, though it probably
helps, I do it so I can verify the tape afterwards (cpio -it ...).

It helps to keep the system activity fairly low to keep things
streaming.  Some have said that it also helps to keep the console i/o
to a minimum -- with my monochrome video card it doesn't seem to be
that critical.

I sometimes put compress in line between cpio and ddd in order to
double the amount of storage on a tape.  The drive won't stream, but
this actually takes less time to backup 300megs (~50 min.) than the two
tape approach.  The data isn't quite as secure though, since everything
past any tape errors will be lost (unless someone knows how to resync
in the middle of a compressed file.)

Has anyone managed to get a Wangtec drive to stream with something other
than ddd?  I mean really stream, where the drive will write 150megs before
is has to stop.

Richard Foulk		richard at pegasus.com

-- 

From: Doug Pintar <gargoyle!ico.isc.com!dougp>

I'm using a 1542 with an Archive 2150S at home and it works fine.  Bear in
mind that the driver does NO internal buffering.  If you want it to stream
(at least do big bursts) try something like:

	find . -print | cpio -oBcv | dd ibs=5120 obs=320k of=/dev/ct

There is a problem in the driver that any single write request bigger than
about 360 KB will give you an 'EINVAL' return, so don't make 'obs' too big...
The above technique on my machine at home gives me a backup rate of about
65 KB/sec or so.  Not spectacular, but fine for my needs (20-25 min for
100 MB).

DLP

--

From: gargoyle!ndmath.nd.edu!nstar!larry (Larry Snyder)

I use a 1542 with a Archive 2150S and the tape flies at something like
6 megabytes a minute.  I use something like:

find . -depth -print | cpio -ocBC 10240 > /dev/ct

larry

--

From: mark at intek01.uucp (Mark McWiggins)

There's a freely available program called 'afio' (cpio clone) that does double 
buffering, recovery of corrupted archives, and is otherwise generally wonderful.
It should make your tape drive stream, if anything will.

--

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
     _          o                          avi at chinet.chi.il.us
   /  )/      _           Avi              GEnie mail - A.SCHWARTZ
 /   /   /|  / |       Schwartz            Compu$erve - 71350,2006



More information about the Comp.unix.i386 mailing list