Path: utzoo!attcan!uunet!dino!sharkey!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!pyramid!ctnews!mitisft!dold
From: dold@mitisft.Convergent.COM (Clarence Dold)
Newsgroups: comp.unix.wizards
Subject: Re: Cartridge tape stuff
Message-ID: <757@mitisft.Convergent.COM>
Date: 29 Jun 89 16:52:46 GMT
References: <1989Jun28.173209.1457@eci386.uucp>
Distribution: na
Organization: Convergent Technologies, San Jose, CA
Lines: 31

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.  You can prove this
> to yourself by tar'ing with differing buffer sizes to a file and comparing
> the result.  On a fixed 1/2K style streamer you can "tar c" with 1Mb buffers 
> with confidence that almost anything can read it (modulo machines with
> byteswap or other wierdnesses) using 512 byte buffers if nothing else.

One exception I can think of is EOT on a multi-volume archive.
If you use
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.
When restoring the archive with 512K blocks, the same will happen.  The partial
512K block will be discarded, and the next reel will be in sequence.

If an attempt is made to restore it with 512 byte blocks, the partial 512K 
at EOT will be successfully read as, say, 45 512byte blocks, causing
the second reel to be out of sequence.

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.
-- 
---
Clarence A Dold - dold@tsmiti.Convergent.COM		(408) 434-5293
		...pyramid!ctnews!tsmiti!dold
		P.O.Box 6685, San Jose, CA 95150-6685	MS#10-007