Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!ggs
From: ggs@ulysses.homer.nj.att.com (Griff Smith)
Newsgroups: comp.unix.ultrix
Subject: Re: dump on old 1.2 Ultrix...
Summary: error recovery may fail
Message-ID: <11953@ulysses.homer.nj.att.com>
Date: 1 Aug 89 15:00:38 GMT
References: <412@wuee1.wustl.edu> <4082@portia.Stanford.EDU> <7484@cbmvax.UUCP> <7492@cbmvax.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 29

In article <7492@cbmvax.UUCP>, grr@cbmvax.UUCP (George Robbins) writes:
...
> The actual limits here are probably based on Massbus 16-bit byte
> count registers, which enforce transfer sizes of 1-65536 bytes.
> tar seems to make a software decision to avoid 65536 byte blocks.
> 
> Now it's entirely possible that other I/O architectures / controllers
> may allow larger transfers.
> -- 
> George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
> but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
> Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)

Large blocks may also cause a problem when doing error recovery.  For instance,
if using 9-track tape at 6250 bpi a 64K block takes about ten inches of tape.
If the device driver tries to skip over a bad spot on the tape by rewinding
over a bad record and writing a three inch gap, the bad spot may be on the
other seven inches.  If the driver gives up after three write attempts, it
will never skip over an error in the last inch of the record.  Larger blocks
make the problem worse.  64k blocks are already at 97% of maximum density for
6250, so larger blocks are silly.

Adjust these arguments for newer media, but 64k should usually be a good size;
it's already 8 times larger than the disk block size used by most BSD-based systems.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs@ulysses.att.com