dump on old 1.2 Ultrix...

[George Robbins]

In article <4113 at portia.Stanford.EDU> karish at forel.stanford.edu (Chuck Karish) writes:
> In article <7484 at cbmvax.UUCP> grr at cbmvax.UUCP (George Robbins) wrote:
> >In article <4082 at portia.Stanford.EDU> karish at forel.stanford.edu
> 
> >Does -b 126 really work with TK50's?  ...
> 
> 	A uVAX-II/GPX has neither a Massbus nor a SCSI bus, and
> 	`-b 126' works.  I used it for a tar backup to TK50 on a
> 	uVAX-II/GPX running 3.0, last week.  It's been a while since I
> 	used the flag on a 1.2 system, but it worked then, too.  I'm
> 	not absolutely sure that it worked on dump/restore, but I think
> 	it did.

I don't really want to fight about this - my purpose was simply to issue
sufficiently dire warnings that people wouldn't start spewing out big
blocksize dumps, and then be embarrassed at one of those critical moments
when you find that none of your recent dump tape seem to read back in...

The current Ultrix dump/restore and tar program seem pretty good about
blocksize, other versions have been know to *silently* generate unreadable
tapes.  The 1.2 versions can be assumed to be "closer" in an evolutionary
sense to those bad guys than the 3.x versions.

Anyway, I threw up a tape on a drive here an play around a bit.  It wasn't
a TK50, so the results don't apply to TK50's, though the ideas do.

tar:

tar -b switch specifies blocksize in terms of 512 byte blocks.
values of up to 127 work, blocksize=65024.  program claims that 128
or above is "invalid block size".  blocksize validated with dd.

dump/restore:

dump -b switch specifies blocksize in terms of *1024* byte blocks,
restore has no corresponding switch.  values of up to 64 work,
blocksize=65536.  program gets "write error" on first block if value
greater than 64.  blocksize validated with dd.  dd can be used to
reblock tapes to stdin to restore a single volume dump.

notions:

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.  I don't have access to any of these.
It's also possible for software to be broken when the numbers used are
larger than the programmer considered.   I seem to recall that dd
used to have problems in this regard, though it seems to work good
now.

-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr at uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)