Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!husc6!seismo!ll-xn!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (System Mangler)
Newsgroups: net.unix-wizards
Subject: Re: Seeking a Development Environment (Sun?)
Message-ID: <1081@cit-vax.Caltech.Edu>
Date: Sun, 26-Oct-86 19:28:11 EST
Article-I.D.: cit-vax.1081
Posted: Sun Oct 26 19:28:11 1986
Date-Received: Mon, 27-Oct-86 05:17:46 EST
References: <4254@brl-smoke.ARPA> <935@kbsvax.steinmetz.UUCP> <8422@sun.uucp> <8501@sun.uucp>
Organization: California Institute of Technology
Lines: 43
Summary: porting 4.1bsd dump to SysV

In article <8501@sun.uucp>, guy@sun.uucp (Guy Harris) writes:
> The main thing you'd have to do is teach it [4.1bsd dump] to
> support both 512-byte and 1024-byte file systems.

First, remove the fstab stuff.	Sys V has no /etc/fstab.

Next, realize that daddr's are in units of the filesystem blocksize
(e.g. 1024) but bread() and the tape routines use different units.
Conversion factors creep in everywhere.

You have to decide whether TP_BSIZE is 512 or 1024.  Making it BSIZE
(512) makes dumpdir happy, but then it takes two spclrec's to hold
each indirect block from a 1K filesystem (harmless but ugly).

The dumprestor.h supplied with Sys V defines NTREC as 20, which is
too large for the 3B20's UN52 tape controller (limited to blocksizes
of 6 KB or less).

If TP_BSIZE is smaller than the blocksize of the filesystem being
restor'd, bmap() needs to return the same pointer for both 512-byte
halves instead of zapping the pointer and allocating 1K block.	Be
sure to zap the first block pointer, which got copied from the tape
inode just in case the file was character or block special (better
yet, only copy that block pointer if the file is actually special).

Lastly, integrate the 4.3bsd dump speedups, which already understand
about variable blocksizes.  Main difficulty is recovery from the 4.1bsd
interrupt trap routine (signals vs. pipes *sigh*); once you get that
right, the interprocess synchronization is easy to convert to signals.

Despite only being able to read 1K at a time, full dumps are nearly
the same speed as volcopy.  The UN52 tape controller simply won't
go faster than 80 KB/s.  Of course incremental dumps beat the tar
out of cpio.

> Anybody at AT&T-IS willing to torque off their management by doing this?

(I got pretty torqued off at having to do this myself, and so did my
management).  If adopting a 4.1bsd program is going to torque off the
AT&T-IS management, start from the Sys III version!  The differences
are largely cosmetic.

Don Speck   speck@vlsi.caltech.edu  {seismo,rutgers}!cit-vax!speck