[net.unix-wizards] 4.2 dist tape

malloy@ittral.UUCP (William P. Malloy) (08/18/84)

This article is both a warning and a (minor) flame.

We have FINALLY, after many months, received our 4.2 tapes.  ITT's lawyers
must charge by the hour from all the time they took to get us our 4.2 license.
Anyway, being good little boys, and not trusting anything (paranoia is a virtue)
we tried to make a copy of the tapes.  I figured easy!  We've got two drives, a
TU-77 and a TU-78, all we need is to do is ``dd if=/dev/rmt5 of=/dev/rmt12''.
Works fine, then I do it again (there are six files on the first tape).  We
begin to notice a curious thing, one drive is cranking along a whole lot
faster then the other (we may be a confused bunch, but we can tell how fast
things go round and round.)  Well we try everything, dd bs=512, everything,
we do cmp on the files, and find the first one is okay, but nothing else works.

Luckily I read the manuals (like WOW, literate!) And I remembered a curious
phrase which goes, "The tapes are 9-track 1600 BPI and contain some 512-byte
records followed by many 10240-byte records."  Yeah you guessed it, the SOME
refers to the first file on the tape (the boot), and everything else needs
to have ``bs=10240'' option to dd.  Now why didn't anyone TELL people this?
We were going nuts trying to figure it out, we tried everything even the
basic ``cp /dev/rmt5 /dev/rmt12'' and no luck.

I guess the point is (a) most people don't back up their distribution tapes
(some people LIKE living dangerously), or (b) most people don't have two
tape drives or (c) everyone thought it was a good chuckle and wanted to see
what other people thought of it.  Well here's the warning if you're thinking
of converting to 4.2, watch out and save this article.

Maybe the people who are doing the distribution just thought it would be
a good giggle to see how many people really bother to back-up their distrib-
ution.  From the lack of complaints either (a) no one bothers or (b) we must
have a STRANGE configuration which caused our problems.

Well at least I've improved, the first time I ever touched a tape drive I
crashed a system.  That's why I work for the ``Software'' Support Group.
--
Address: William P. Malloy, ITT Telecom, B & CC Engineering Group, Raleigh NC
	 {ihnp4!mcnc, burl, ncsu, decvax!ittvax}!ittral!malloy

lmc@denelcor.UUCP (Lyle McElhaney) (08/20/84)

Ah, yes, making an exact copy of a tape with Unix. Its easy enough if its a
tar or cpio tape (provided you know that ahead of time), but what about
the Univac tape you just received with one label on it, giving the returnee's
address?

The easiest thing to do is to use dd, as the referenced article stated,
from one tape drive to another (with due regard to tape densities). If you
set the buffer size higher than any physical record size on the tape, dd
will make an exact copy of the tape file. We regularly copy tapes with
the command:

	dd if=/dev/nrmt0 of=/dev/nrmt1 bs=21000

Yup, it wastes space on a non-virtual machine, but almost any machine that
runs multitasking Unix (and has two tape drives) won't notice the
difference.

Now, the gentleman did have a valid gripe: why does the Berkeley setup manual
(and others, probably) wisely say "make copies of the tapes" and then don't
say how?  We certainly aren't all guri when we start, as many of us have,
becoming system admin's from a cold start.

I have a tape utility called ts that describes the file/record layout of
an arbitrary tape - so as I write a manual page I'll submit it to net.sources.
In addition, I also wrote a utility for making a tape copy on a system with
only one tape drive, as long as you have sufficient disk. Will post it too.

PS: Michael P., where are you?
-- 
		Lyle McElhaney
		(hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc

mike@BRL-TGR.ARPA (08/20/84)

From:      Mike Muuss <mike@BRL-TGR.ARPA>

Appendix A of "Insalling and Operating 4.2 BSD" contains a detailed
description of the layout of the tapes, including blocking info.

Reading the installation manual COVER TO COVER is recommended;
it's small enough.

				RTFM,
				 -Mike

cspencer@bbncca.ARPA (Clifford Spencer) (11/14/84)

Anyone have a recipe for copying 4.2 distribution tapes?
In other words, which blocks are what size? What stands
in the way to a simplified full restore scheme as opposed
to this <<MINI ROOT>> jazz? why not a stand alone
mkfs/restore? is this because restore only can restore into
the current working directory? there must be a better way.
				cliff
-- 
{decvax,linus,ima,ihnp4,wjh12}!bbncca!cspencer
cspencer@bbncca.ARPA

msc@qubix.UUCP (Mark Callow) (11/15/84)

cspencer seems to be asking two separate questions

> Anyone have a recipe for copying 4.2 distribution tapes?
> In other words, which blocks are what size?
I've no idea.  I don't have any systems with two tape drives.
I just generate a new distribution tape when I need one.

> What stands
> in the way to a simplified full restore scheme as opposed
> to this <<MINI ROOT>> jazz? why not a stand alone
> mkfs/restore? is this because restore only can restore into
> the current working directory? there must be a better way.

Having installed both 4.1BSD, which used a standalone mkfs and
restore, and many, many, 4.2BSD systems I vastly prefer the mini-unix
method.  The mini-unix takes only 5 to 10 minutes to load and then
you have the complete Unix essentials with which to install the real
root file system.  It all operates very smoothly and I feel no need
for a "better" way.

The reason it is done this way in 4.2 is that restore works through
regular system calls on the block device rather than operating directly
on the raw device and inodes as the 4.1 and v7 restor's do.  This makes
it very hard to write a standalone version of restore.

Incidentally "restore" is a vast iprovement over "restor".
-- 
From the TARDIS of Mark Callow
msc@qubix.UUCP,  qubix!msc@decwrl.ARPA
...{decvax,ucbvax}!decwrl!qubix!msc, ...{amd,ihnp4,ittvax}!qubix!msc

Mike Muuss <mike@brl-tgr> (11/15/84)

The "mini root" step in the distribution was so that your REAL root
would have a layout that is optimal for your disk geometry.
Performance on the real root is critical enough that this is
a very important step.  Sites starting with only one disk drive
would have a hard time going back and re-building their root
later.
		-Mike Muuss, BRL