Path: utzoo!attcan!lsuc!eci386!clewis
From: clewis@eci386.uucp (Chris Lewis)
Newsgroups: comp.unix.wizards
Subject: Re: Cartridge tape stuff
Message-ID: <1989Jul7.003455.1950@eci386.uucp>
Date: 7 Jul 89 00:34:55 GMT
References: <1989Jun28.173209.1457@eci386.uucp> <757@mitisft.Convergent.COM>
Reply-To: clewis@eci386.UUCP (Chris Lewis)
Distribution: na
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 76

In article <757@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes:
>in article <1989Jun28.173209.1457@eci386.uucp>, clewis@eci386.uucp (Chris Lewis) says:

>> tar and cpio do not change their formats regardless of the buffer size
>> you give them, they simply use bigger I/O buffers.

>One exception I can think of is EOT on a multi-volume archive.
>    cpio -ocvT512k >/dev/rmt0
>and EOT is reached somewhere in the midst of writing a 512K block, the next
>reel will have a repeat of that 512K block.

[And reads with small blocks would get out of sync]

True.  Didn't think of that.  Mind you, most tar's don't support multi-volume
(and frankly, I simply don't trust cpio multi-volume except *maybe* on 
floppies) so the question is moot for tar.

>If a small buffer is used on the outbound side, and a large buffer is used
>to read it, the opposite will happen, even on single reel archives.
>An archive that is 33*512 byte, will come out to an uneven multiple of
>512K, and the restore will fail, unable to read the last, apparently partial
>set of blocks.

H'm, I just tried this with cpio on ISC 1.0.6 and it worked just fine.
try:

	cd /etc
	cpio -o > /tmp/foo
	passwd
	inittab
	group
	<ctrl-D>
	cd /tmp
	cpio -iC512000 < /tmp/foo
	(will say that 10000 blocks read, but will create the files
	just perfectly)

(-C is an undocumented cpio argument on ISC, probably AT&T, Microport and
Bell Tech.  I belive they (whoever "they" were) replaced cpio with something 
called "ncpio" which appears to have been an internal enhanced version of cpio.
This appears to be the only way to get arbitrarily sized buffers specified
to cpio.)

Even if true, on QIC devices you really do need big buffers to get
any sort of reasonable throughput.  So you should be able to choose a 
reasonable size.  Any QIC driver that can't read/write more
than 512 bytes at a time should be junked.  Any 1/4" streamer that has 
variable length records wouldn't be able to read/write compatible QIC tapes 
anyhow.

As a reasonable compromise: use 128K on QIC streamers - large enough to
not have too bad a start-stop hit, not so large that you could run into
severe problems on machines with small amounts of memory or lots of other
users that are trying to get things done ;-).  On 9-track, 5K is usually
fine (tar limit), though there are some machines that can only handle 3K 
(some 3b's).  Once you get above 5K blocks all bets are off as to whether
the hardware can handle real physical blocks that big.

There are a few machines that don't like > 32K or > 64K raw I/O because
of DMA boundaries.  386 UNIX and NCR Towers have it right even though they
have somewhat strange DMA structures.  Some older PC UNIXes don't.  For
those machines, you might have to limit yourselves to 32K.

Even then, you might be able to fake it:

If your tar doesn't support buffers bigger than 5K, you can always
pipe the output of tar thru dd:

	tar cvf - .... | dd bs=<whatever> > /dev/....

[I may be mistaken, but doesn't 386 2.3.1 Xenix dd not support bs > 64K?]
-- 
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425