Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!ncar!tank!gargoyle!ddsw1!nvk
From: nvk@ddsw1.MCS.COM (Norman Kohn)
Newsgroups: comp.unix.i386
Subject: Re: Compressing to a tape drive
Message-ID: <1990Mar10.041015.23468@ddsw1.MCS.COM>
Date: 10 Mar 90 04:10:15 GMT
References: <14496@s.ms.uky.edu>
Reply-To: nvk@ddsw1.MCS.COM (Norman Kohn)
Distribution: na
Organization: ddsw1.MCS.COM Contributor, Mundelein, IL
Lines: 25

In article <14496@s.ms.uky.edu> acp@ms.uky.edu (ACPNET consultant) writes:
>find . -print | cpio -oc | compress | dd [blocking options] > /dev/rmt/c0s0
>
>Now, including dd in the pipe is *loads* faster than not including
>it, but I haven't been able to find any dd options which let the 
>tape stream.  It keeps stopping and backing up.  When using something
>like ibs=32k obs=512 (the tape writes 512-byte records), dd reports
>no full input blocks, all partial blocks--I assume this corresponds to
>bursts produced by compress.  Something like bs=512 produces all full
>blocks but doesn't affect the tape speed.
>
Try dd ibs=5120 obs=512k
(as I recall, this is what ISC uses when loading the system from tape).
With ISC it does indeed produce improvement, perhaps even better
than bs=512k which I have also used.  While I haven't looked, I don't
think that the blocks written on tape are any different: cpio and the
tape driver still prepare the blocks they want, and all you've done
is modify the amount of data that arrives at one time down the pipe.
Reading, of course, you reverse the respective ibs/obs sizes.

-- 
Norman Kohn   		| ...ddsw1!nvk
Chicago, Il.		| days/ans svc: (312) 650-6840
			| eves: (312) 373-0564