Compressing to a tape drive

Conor P. Cahill cpcahil at virtech.uucp
Mon Mar 12 09:33:31 AEST 1990


In article <1990Mar10.041015.23468 at ddsw1.MCS.COM> nvk at ddsw1.MCS.COM (Norman Kohn) writes:
>In article <14496 at s.ms.uky.edu> acp at ms.uky.edu (ACPNET consultant) writes:
>>find . -print | cpio -oc | compress | dd [blocking options] > /dev/rmt/c0s0
>>
>>  [discusion of how to get dd to stream deleted]
>>
>Try dd ibs=5120 obs=512k

While all the suggestions that I have seen for this may actually get
the tape to stream on some systems, there is no answer for every 
system.  In addition, if there is some other high priority stuff going on,
there is no command that will get the tape to stream always.

For example, the following dd will stream an entire tape to a file
without stopping at all:

		dd if=/dev/rmt0 of=junkfile bs=50k

However, if I am working on the console and cause just a few lines
to be output on the console, the streaming will stop.  This even occurs
if I use bs=2048k.  Whenever I type ls -l on the console the tape
drive will stop and restart.

So the answer is:  If you are working on the console, you may never get the
tape to stream for very large chunks.  If you are working elsewhere, you
might still have problems because of what you are running on the
system.  If you system is totally quiet (except for the backup stuff itself)
you "should" be able to get the data to stream.

PS - Another part of this is how fast the compress can feed the data to dd.  
If your tape drive can get ahead of the compress output, you can't 
stream.  That is why some people were saying  to use ...|dd obs=big_value
that way dd stored up the data and then fed it to the tape in one big
chunk.

I guess I am just rambling on now so I will stop.  Remember there is no
one solution, and sometimes none at all, to getting a tape drive to stream.

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



More information about the Comp.unix.i386 mailing list