2.t

早期freebsd实现

INPUT	T{
Standard DEC keyboard (LK201) and mouse.
T}
_
MISC	T{
Battery-backed real time clock,
internal and TURBOchannel PMAZ-AA SCSI interfaces.
T}
.TE
.LP
Major items that are not supported include the 5000/240
(there is code but not compiled in or tested),
R4000 based machines, FDDI and audio interfaces.
Diskless machines are not supported but booting kernels and bootstrapping
over the network is supported on the 5000 series.
.Sh 3 "The procedure"
.PP
The first file on the distribution tape is a tar file that contains
four files.
The first step requires a running UNIX (or ULTRIX) system that can
be used to extract the tar archive from the first file on the tape.
The command:
.DS
.ft CW
tar xf /dev/rmt0
.DE
will extract the following four files:
.DS
A) root.image: \fIdd\fP image of the root filesystem
B) vmunix.tape: \fIdd\fP image for creating boot tapes
C) vmunix.net: file for booting over the network
D) root.dump: \fIdump\fP image of the root filesystem
.DE
There are three basic ways a system can be bootstrapped corresponding to the
first three files.
You may want to read the section on bootstrapping the HP300
since many of the steps are similar.
A spare, formatted SCSI disk is also useful.
.Sh 4 "Procedure A: copy root filesystem to disk"
.PP
This procedure is similar to the HP300.
If you have an extra disk, the easiest approach is to use \fIdd\fP\|(1)
under ULTRIX to copy the root filesystem image to the beginning
of the spare disk. 
The root filesystem image includes a disklabel and bootblock along with the
root filesystem.
An example command to copy the image to the beginning of a disk is:
.DS
.ft CW
dd if=root.image of=/dev/rz1c bs=\*(Bzb
.DE
The actual special file syntax will vary depending on unit numbers and
the version of ULTRIX that is running.
This system is now ready to boot. You can boot the kernel with one of the
following PROM commands. If you are booting on a 3100, the disk must be SCSI
id zero because of a bug.
.DS
.ft CW
DEC 3100:    boot \-f rz(0,0,0)vmunix
DEC 5000:    boot 5/rz0/vmunix
.DE
You can then proceed to section 2.5
to create reasonable disk partitions for your machine
and then install the rest of the system.
.Sh 4 "Procedure B: bootstrap from tape"
.PP
If you have only a single machine with a single disk,
you need to use the more difficult approach of booting a
kernel and mini-root from tape or the network, and using it to restore
the root filesystem.
.PP
First, you will need to create a boot tape. This can be done using
\fIdd\fP as in the following example.
.DS
.ft CW
dd if=vmunix.tape of=/dev/nrmt0 bs=1b
dd if=root.dump of=/dev/nrmt0 bs=\*(Bzb
.DE
The actual special file syntax for the tape drive will vary depending on
unit numbers, tape device and the version of ULTRIX that is running.
.PP
The first file on the boot tape contains a boot header, kernel, and
mini-root filesystem that the PROM can copy into memory.
Installing from tape has only been tested
on a 3100 and a 5000/200 using a TK50 tape drive. Here are two example
PROM commands to boot from tape.
.DS
.ft CW
DEC 3100:    boot \-f tz(0,5,0) m    # 5 is the SCSI id of the TK50
DEC 5000:    boot 5/tz6 m           # 6 is the SCSI id of the TK50
.DE
The `m' argument tells the kernel to look for a root filesystem in memory.
Next you should proceed to section 2.4.3 to build a disk-based root filesystem.
.Sh 4 "Procedure C: bootstrap over the network"
.PP
You will need a host machine that is running the \fIbootp\fP server 
with the
.Pn vmunix.net
file installed in the default directory defined by the
configuration file for
.Xr bootp .
Here are two example PROM commands to boot across the net:
.DS
.ft CW
DEC 3100:	boot \-f tftp()vmunix.net m
DEC 5000:	boot 6/tftp/vmunix.net m
.DE
This command should load the kernel and mini-root into memory and
run the same as the tape install (procedure B).
The rest of the steps are the same except
you will need to start the network
(if you are unsure how to fill in the <name> fields below,
see sections 4.4 and 5).
Execute the following to start the networking:
.DS
.ft CW
# mount \-uw /
# echo 127.0.0.1 localhost >> /etc/hosts
# echo <your.host.inet.number> myname.my.domain myname >> /etc/hosts
# echo <friend.host.inet.number> myfriend.my.domain myfriend >> /etc/hosts
# ifconfig le0 inet myname
.DE
Next you should proceed to section 2.4.3 to build a disk-based root filesystem.
.Sh 3 "Label disk and create the root filesystem"
.LP
There are five steps to create a disk-based root filesystem.
.IP 1)
Label the disk.
.DS
.ft CW
# disklabel -W /dev/rrz?c		# This enables writing the label
# disklabel -w -r -B /dev/rrz?c $DISKTYPE
# newfs /dev/rrz?a
\&...
# fsck /dev/rrz?a
\&...
.DE
Supported disk types are listed in
.Pn /etc/disktab .
.IP 2)
Restore the root filesystem.
.DS
.ft CW
# mount \-uw /
# mount /dev/rz?a /a
# cd /a
.DE
.ti +0.4i
If you are restoring locally (procedure B), run:
.DS
.ft CW
# mt \-f /dev/nrmt0 rew
# restore \-xsf 2 /dev/rmt0
.DE
.ti +0.4i
If you are restoring across the net (procedure c), run:
.DS
.ft CW
# rrestore xf myfriend:/path/to/root.dump
.DE
.ti +0.4i
When the restore finishes, clean up with:
.DS
.ft CW
# cd /
# sync
# umount /a
# fsck /dev/rz?a
.DE
.IP 3)
Reset the system and initialize the PROM monitor to boot automatically.
.DS
.ft CW
DEC 3100:	setenv bootpath boot \-f rz(0,?,0)vmunix
DEC 5000:	setenv bootpath 5/rz?/vmunix -a
.DE
.IP 4)
After booting UNIX, you will need to create
.Pn /dev/mouse
to run X windows as in the following example.
.DS
.ft CW
rm /dev/mouse
ln /dev/xx /dev/mouse
.DE
The 'xx' should be one of the following:
.DS
pm0	raw interface to PMAX graphics devices
cfb0	raw interface to TURBOchannel PMAG-BA color frame buffer
xcfb0	raw interface to maxine graphics devices
mfb0	raw interface to mono graphics devices
.DE
You can then proceed to section 2.5 to install the rest of the system.
Note that where the disk name ``sd'' is used throughout section 2.5,
you should substitute the name ``rz''.
.Sh 2 "Disk configuration"
.PP
All architectures now have a root filesystem up and running and
proceed from this point to layout filesystems to make use
of the available space and to balance disk load for better system
performance.
.Sh 3 "Disk naming and divisions"
.PP
Each physical disk drive can be divided into up to 8 partitions;
UNIX typically uses only 3 or 4 partitions.
For instance, the first partition, \*(Dk0a,
is used for a root filesystem, a backup thereof,
or a small filesystem like,
.Pn /var/tmp ;
the second partition, \*(Dk0b,
is used for paging and swapping; and
a third partition, typically \*(Dk0e,
holds a user filesystem.
.PP
The space available on a disk varies per device.
Each disk typically has a paging area of 30 to 100 megabytes
and a root filesystem of about 17 megabytes.
.\" XXX check
The distributed system binaries occupy about 150 (180 with X11R5) megabytes
.\" XXX check
while the major sources occupy another 250 (340 with X11R5) megabytes.
The
.Pn /var
filesystem as delivered on the tape is only 2Mb,
however it should have at least 50Mb allocated to it just for
normal system activity.
Usually it is allocated the last partition on the disk
so that it can provide as much space as possible to the
.Pn /var/users
filesystem.
See section 2.5.4 for further details on disk layouts.
.PP
Be aware that the disks have their sizes
measured in disk sectors (usually 512 bytes), while the UNIX filesystem
blocks are variable sized.
If
.Sm BLOCKSIZE=1k
is set in the user's environment, all user programs report
disk space in kilobytes, otherwise,
disk sizes are always reported in units of 512-byte sectors\**.
.FS
You can thank System V intransigence and POSIX duplicity for
requiring that 512-byte blocks be the units that programs report.
.FE
The
.Pn /etc/disktab
file used in labelling disks and making filesystems
specifies disk partition sizes in sectors.
.Sh 3 "Layout considerations"
.PP
There are several considerations in deciding how
to adjust the arrangement of things on your disks.
The most important is making sure that there is adequate space
for what is required; secondarily, throughput should be maximized.
Paging space is an important parameter.
The system, as distributed, sizes the configured
paging areas each time the system is booted.  Further,
multiple paging areas of different sizes may be interleaved.
.PP
Many common system programs (C, the editor, the assembler etc.)
create intermediate files in the
.Pn /tmp
directory, so the filesystem where this is stored also should be made
large enough to accommodate most high-water marks.
Typically,
.Pn /tmp
is constructed from a memory-based filesystem (see
.Xr mount_mfs (8)).
Programs that want their temporary files to persist
across system reboots (such as editors) should use
.Pn /var/tmp .
If you plan to use a disk-based
.Pn /tmp
filesystem to avoid loss across system reboots, it makes
sense to mount this in a ``root'' (i.e. first partition)
filesystem on another disk.
All the programs that create files in
.Pn /tmp
take care to delete them, but are not immune to rare events
and can leave dregs.
The directory should be examined every so often and the old
files deleted.
.PP
The efficiency with which UNIX is able to use the CPU
is often strongly affected by the configuration of disk controllers;
it is critical for good performance to balance disk load.
There are at least five components of the disk load that you can
divide between the available disks:
.IP 1)
The root filesystem.
.IP 2)
The
.Pn /var
and
.Pn /var/tmp
filesystems.
.IP 3)
The
.Pn /usr
filesystem.
.IP 4)
The user filesystems.
.IP 5)
The paging activity.
.LP
The following possibilities are ones we have used at times
when we had 2, 3 and 4 disks:
.TS
center doublebox;
l | c s s
l | lw(5) | lw(5) | lw(5).
	disks
what	2	3	4
_
root	0	0	0
var	1	2	3
usr	1	1	1
paging	0+1	0+2	0+2+3
users	0	0+2	0+2
archive	x	x	3
.TE
.PP
The most important things to consider are to
even out the disk load as much as possible, and to do this by
decoupling filesystems (on separate arms) between which heavy copying occurs.
Note that a long term average balanced load is not important; it is
much more important to have an instantaneously balanced
load when the system is busy.
.PP
Intelligent experimentation with a few filesystem arrangements can
pay off in much improved performance.  It is particularly easy to
move the root, the
.Pn /var
and
.Pn /var/tmp
filesystems and the paging areas.  Place the
user files and the
.Pn /usr
directory as space needs dictate and experiment
with the other, more easily moved filesystems.
.Sh 3 "Filesystem parameters"
.PP
Each filesystem is parameterized according to its block size,
fragment size, and the disk geometry characteristics of the
medium on which it resides.  Inaccurate specification of the disk
characteristics or haphazard choice of the filesystem parameters
can result in substantial throughput degradation or significant
waste of disk space.  As distributed,
filesystems are configured according to the following table.
.DS
.TS
center;
l l l.
Filesystem	Block size	Fragment size
_
root	8 kbytes	1 kbytes
usr	8 kbytes	1 kbytes
users	4 kbytes	512 bytes
.TE
.DE
.PP
The root filesystem block size is
made large to optimize bandwidth to the associated disk.
The large block size is important as many of the most
heavily used programs are demand paged out of the
.Pn /bin
directory.
The fragment size of 1 kbyte is a ``nominal'' value to use
with a filesystem.  With a 1 kbyte fragment size
disk space utilization is about the same
as with the earlier versions of the filesystem.
.PP
The filesystems for users have a 4 kbyte block
size with 512 byte fragment size.  These parameters
have been selected based on observations of the
performance of our user filesystems.  The 4 kbyte
block size provides adequate bandwidth while the
512 byte fragment size provides acceptable space compaction
and disk fragmentation.
.PP
Other parameters may be chosen in constructing filesystems,
but the factors involved in choosing a block
size and fragment size are many and interact in complex
ways.  Larger block sizes result in better
throughput to large files in the filesystem as
larger I/O requests will then be done by the
system.  However,
consideration must be given to the average file sizes
found in the filesystem and the performance of the
internal system buffer cache.   The system
currently provides space in the inode for
12 direct block pointers, 1 single indirect block
pointer, 1 double indirect block pointer,
and 1 triple indirect block pointer.
If a file uses only direct blocks, access time to
it will be optimized by maximizing the block size.
If a file spills over into an indirect block,
increasing the block size of the filesystem may
decrease the amount of space used
by eliminating the need to allocate an indirect block.
However, if the block size is increased and an indirect
block is still required, then more disk space will be
used by the file because indirect blocks are allocated
according to the block size of the filesystem.
.PP
In selecting a fragment size for a filesystem, at least
two considerations should be given.  The major performance
tradeoffs observed are between an 8 kbyte block filesystem
and a 4 kbyte block filesystem.  Because of implementation
constraints, the block size versus fragment size ratio can not
be greater than 8.  This means that an 8 kbyte filesystem
will always have a fragment size of at least 1 kbytes.  If
a filesystem is created with a 4 kbyte block size and a
1 kbyte fragment size, then upgraded to an 8 kbyte block size
and 1 kbyte fragment size, identical space compaction will be