2.t

早期freebsd实现

observed.  However, if a filesystem has a 4 kbyte block size
and 512 byte fragment size, converting it to an 8K/1K
filesystem will result in 4-8% more space being
used.  This implies that 4 kbyte block filesystems that
might be upgraded to 8 kbyte blocks for higher performance should
use fragment sizes of at least 1 kbytes to minimize the amount
of work required in conversion.
.PP
A second, more important, consideration when selecting the
fragment size for a filesystem is the level of fragmentation
on the disk.  With an 8:1 fragment to block ratio, storage fragmentation
occurs much sooner, particularly with a busy filesystem running
near full capacity.  By comparison, the level of fragmentation in a
4:1 fragment to block ratio filesystem is one tenth as severe.  This
means that on filesystems where many files are created and
deleted, the 512 byte fragment size is more likely to result in apparent
space exhaustion because of fragmentation.  That is, when the filesystem
is nearly full, file expansion that requires locating a
contiguous area of disk space is more likely to fail on a 512
byte filesystem than on a 1 kbyte filesystem.  To minimize
fragmentation problems of this sort, a parameter in the super
block specifies a minimum acceptable free space threshold.  When
normal users (i.e. anyone but the super-user) attempt to allocate
disk space and the free space threshold is exceeded, the user is
returned an error as if the filesystem were really full.  This
parameter is nominally set to 5%; it may be changed by supplying
a parameter to
.Xr newfs (8),
or by updating the super block of an existing filesystem using
.Xr tunefs (8).
.PP
Finally, a third, less common consideration is the attributes of
the disk itself.  The fragment size should not be smaller than the
physical sector size of the disk.  As an example, the HP magneto-optical
disks have 1024 byte physical sectors.  Using a 512 byte fragment size
on such disks will work but is extremely inefficient.
.PP
Note that the above discussion considers block sizes of up to only 8k.
As of the 4.4 release, the maximum block size has been increased to 64k.
This allows an entirely new set of block/fragment combinations for which
there is little experience to date.
In general though, unless a filesystem is to be used
for a special purpose application (for example, storing
image processing data), we recommend using the
values supplied above.
Remember that the current
implementation limits the block size to at most 64 kbytes
and the ratio of block size versus fragment size must be 1, 2, 4, or 8.
.PP
The disk geometry information used by the filesystem
affects the block layout policies employed.  The file
.Pn /etc/disktab ,
as supplied, contains the data for most
all drives supported by the system.  Before constructing
a filesystem with
.Xr newfs (8)
you should label the disk (if it has not yet been labeled,
and the driver supports labels).
If labels cannot be used, you must instead
specify the type of disk on which the filesystem resides;
.Xr newfs
then reads
.Pn /etc/disktab
instead of the pack label.
This file also contains the default
filesystem partition
sizes, and default block and fragment sizes.  To
override any of the default values you can modify the file,
edit the disk label,
or use an option to
.Xr newfs .
.Sh 3 "Implementing a layout"
.PP
To put a chosen disk layout into effect, you should use the
.Xr newfs (8)
command to create each new filesystem.
Each filesystem must also be added to the file
.Pn /etc/fstab
so that it will be checked and mounted when the system is bootstrapped.
.PP
First we will consider a system with a single disk.
There is little real choice on how to do the layout;
the root filesystem goes in the ``a'' partition,
.Pn /usr
goes in the ``e'' partition, and
.Pn /var
fills out the remainder of the disk in the ``f'' partition.
This is the organization used if you loaded the disk-image root filesystem.
With the addition of a memory-based
.Pn /tmp
filesystem, its fstab entry would be as follows:
.TS
center;
lfC lfC l l n n.
/dev/\*(Dk0a	/	ufs	rw	1	1
/dev/\*(Dk0b	none	swap	sw	0	0
/dev/\*(Dk0b	/tmp	mfs	rw,-s=14000,-b=8192,-f=1024,-T=sd660	0	0
/dev/\*(Dk0e	/usr	ufs	ro	1	2
/dev/\*(Dk0f	/var	ufs	rw	1	2
.TE
.PP
If we had a second disk, we would split the load between the drives.
On the second disk, we place the
.Pn /usr
and
.Pn /var
filesystems in their usual \*(Dk1e and \*(Dk1f
partitions respectively.
The \*(Dk1b partition would be used as a second paging area,
and the \*(Dk1a partition left as a spare root filesystem
(alternatively \*(Dk1a could be used for
.Pn /var/tmp ).
The first disk still holds the
the root filesystem in \*(Dk0a, and the primary swap area in \*(Dk0b.
The \*(Dk0e partition is used to hold home directories in
.Pn /var/users .
The \*(Dk0f partition can be used for
.Pn /usr/src
or alternately the \*(Dk0e partition can be extended to cover
the rest of the disk with
.Xr disklabel (8).
As before, the
.Pn /tmp
directory is a memory-based filesystem.
Note that to interleave the paging between the two disks
you must build a system configuration that specifies:
.DS
config	vmunix	root on \*(Dk0 swap on \*(Dk0 and \*(Dk1
.DE
The
.Pn /etc/fstab
file would then contain
.TS
center;
lfC lfC l l n n.
/dev/\*(Dk0a	/	ufs	rw	1	1
/dev/\*(Dk0b	none	swap	sw	0	0
/dev/\*(Dk1b	none	swap	sw	0	0
/dev/\*(Dk0b	/tmp	mfs	rw,-s=14000,-b=8192,-f=1024,-T=sd660	0	0
/dev/\*(Dk1e	/usr	ufs	ro	1	2
/dev/\*(Dk0f	/usr/src	ufs	rw	1	2
/dev/\*(Dk1f	/var	ufs	rw	1	2
/dev/\*(Dk0e	/var/users	ufs	rw	1	2
.TE
.PP
To make the
.Pn /var
filesystem we would do:
.DS
\fB#\fP \fIcd /dev\fP
\fB#\fP \fIMAKEDEV \*(Dk1\fP
\fB#\fP \fIdisklabel -wr \*(Dk1 "disk type" "disk name"\fP
\fB#\fP \fInewfs \*(Dk1f\fP
(information about filesystem prints out)
\fB#\fP \fImkdir /var\fP
\fB#\fP \fImount /dev/\*(Dk1f /var\fP
.DE
.Sh 2 "Installing the rest of the system"
.PP
At this point you should have your disks partitioned.
The next step is to extract the rest of the data from the tape.
At a minimum you need to set up the
.Pn /var
and
.Pn /usr
filesystems.
You may also want to extract some or all the program sources.
Since not all architectures support tape drives or don't support the
correct ones, you may need to extract the files indirectly using
.Xr rsh (1).
For example, for a directly connected tape drive you might do:
.DS
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP
\fB#\fP \fItar xbpf \*(Bz /dev/nr\*(Mt0\fP
.DE
The equivalent indirect procedure (where the tape drive is on machine ``foo'')
is:
.DS
\fB#\fP \fIrsh foo mt -f /dev/nr\*(Mt0 fsf\fP
\fB#\fP \fIrsh foo dd if=/dev/nr\*(Mt0 bs=\*(Bzb | tar xbpf \*(Bz -\fP
.DE
Obviously, the target machine must be connected to the local network
for this to work.
To do this:
.DS
\fB#\fP \fIecho  127.0.0.1  localhost >> /etc/hosts\fP
\fB#\fP \fIecho  \fPyour.host.inet.number  myname.my.domain  myname\fI >> /etc/hosts\fP
\fB#\fP \fIecho  \fPfriend.host.inet.number  myfriend.my.domain  myfriend\fI >> /etc/hosts\fP
\fB#\fP \fIifconfig  le0  inet  \fPmyname
.DE
where the ``host.inet.number'' fields are the IP addresses for your host and
the host with the tape drive
and the ``my.domain'' fields are the names of your machine and the tape-hosting
machine.
See sections 4.4 and 5 for more information on setting up the network.
.PP
Assuming a directly connected tape drive, here is how to extract and
install
.Pn /var
and
.Pn /usr :
.br
.ne 5
.TS
lw(2i) l.
\fB#\fP \fImount \-uw /dev/\*(Dk#a /\fP	(read-write mount root filesystem)
\fB#\fP \fIdate yymmddhhmm\fP	(set date, see \fIdate\fP\|(1))
\&....
\fB#\fP \fIpasswd -l root\fP	(set password for super-user)
\fBNew password:\fP	(password will not echo)
\fBRetype new password:\fP
\fB#\fP \fIpasswd -l toor\fP	(set password for super-user)
\fBNew password:\fP	(password will not echo)
\fBRetype new password:\fP
\fB#\fP \fIhostname mysitename\fP	(set your hostname)
\fB#\fP \fInewfs r\*(Dk#p\fP	(create empty user filesystem)
(\fI\*(Dk\fP is the disk type, \fI#\fP is the unit number,
\fIp\fP is the partition; this takes a few minutes)
\fB#\fP \fImount /dev/\*(Dk#p /var\fP	(mount the var filesystem)
\fB#\fP \fIcd /var\fP	(make /var the current directory)
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
\fB#\fP \fItar xbpf \*(Bz /dev/nr\*(Mt0\fP	(extract all of var)
(this takes a few minutes)
\fB#\fP \fInewfs r\*(Dk#p\fP	(create empty user filesystem)
(as before \fI\*(Dk\fP is the disk type, \fI#\fP is the unit number,
\fIp\fP is the partition)
\fB#\fP \fImount /dev/\*(Dk#p /mnt\fP	(mount the new /usr in temporary location)
\fB#\fP \fIcd /mnt\fP	(make /mnt the current directory)
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
\fB#\fP \fItar xbpf \*(Bz /dev/nr\*(Mt0\fP	(extract all of usr except usr/src)
(this takes about 15-20 minutes)
\fB#\fP \fIcd /\fP	(make / the current directory)
\fB#\fP \fIumount /mnt\fP	(unmount from temporary mount point)
\fB#\fP \fIrm -r /usr/*\fP	(remove excess bootstrap binaries)
\fB#\fP \fImount /dev/\*(Dk#p /usr\fP	(remount /usr)
.TE
If no disk label has been installed on the disk, the
.Xr newfs
command will require a third argument to specify the disk type,
using one of the names in
.Pn /etc/disktab .
If the tape had been rewound or positioned incorrectly before the
.Xr tar ,
to extract
.Pn /var
it may be repositioned by the following commands.
.DS
\fB#\fP \fImt -f /dev/nr\*(Mt0 rew\fP
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf 1\fP
.DE
The data on the second and third tape files has now been extracted.
If you are using 6250bpi tapes, the first reel of the
distribution is no longer needed; you should now mount the second
reel instead.  The installation procedure continues from this
point on the 8mm tape.
The next step is to extract the sources.
As previously noted,
.Pn /usr/src
.\" XXX Check
requires about 250-340Mb of space.
Ideally sources should be in a separate filesystem;
if you plan to put them into your
.Pn /usr
filesystem, it will need at least 500Mb of space.
Assuming that you will be using a separate filesystem on \*(Dk0f for
.Pn /usr/src ,
you will start by creating and mounting it:
.DS
\fB#\fP \fInewfs \*(Dk0f\fP
(information about filesystem prints out)
\fB#\fP \fImkdir /usr/src\fP
\fB#\fP \fImount /dev/\*(Dk0f /usr/src\fP
.DE
.LP
First you will extract the kernel source:
.DS
.TS
lw(2i) l.
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
(this should only be done on Exabyte distributions)
\fB#\fP \fItar xpbf \*(Bz /dev/nr\*(Mt0\fP	(extract the kernel sources)
(this takes about 15-30 minutes)
.TE
.DE
.LP
The next tar file contains the sources for the utilities.
It is extracted as follows:
.DS
.TS
lw(2i) l.
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
\fB#\fP \fItar xpbf \*(Bz /dev/rmt12\fP 	(extract the utility source)
(this takes about 30-60 minutes)
.TE
.DE
.PP
If you are using 6250bpi tapes, the second reel of the
distribution is no longer needed; you should now mount the third
reel instead.  The installation procedure continues from this
point on the 8mm tape.
.PP
The next tar file contains the sources for the contributed software.
It is extracted as follows:
.DS
.TS
lw(2i) l.
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
(this should only be done on Exabyte distributions)
\fB#\fP \fItar xpbf \*(Bz /dev/rmt12\fP 	(extract the contributed software source)
(this takes about 30-60 minutes)
.TE
.DE
.PP
If you received a distribution on 8mm Exabyte tape,
there is one additional tape file on the distribution tape
that has not been installed to this point; it contains the
sources for X11R5 in
.Xr tar (1)
format.  As distributed, X11R5 should be placed in
.Pn /usr/src/X11R5 .
.DS
.TS
lw(2i) l.
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImt -f /dev/nr\*(Mt0 fsf\fP	(space to end of previous tape file)
\fB#\fP \fItar xpbf \*(Bz /dev/nr\*(Mt0\fP	(extract the X11R5 source)
(this takes about 30-60 minutes)
.TE
.DE
Many of the X11 utilities search using the path
.Pn /usr/X11 ,
so be sure that you have a symbolic link that points at
the location of your X11 binaries (here, X11R5).
.PP
Having now completed the extraction of the sources, 
you may want to verify that your
.Pn /usr/src
filesystem is consistent.
To do so, you must unmount it, and run
.Xr fsck (8);
assuming that you used \*(Dk0f you would proceed as follows:
.DS
.TS
lw(2i) l.
\fB#\fP \fIcd /\fP	(change directory, back to the root)
\fB#\fP \fIumount /usr/src\fP	(unmount /usr/src)
\fB#\fP \fIfsck /dev/r\*(Dk0f\fP
.TE
.DE
The output from
.Xr fsck
should look something like:
.DS
.B
** /dev/r\*(Dk0f
** Last Mounted on /usr/src
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
23000 files, 261000 used, 39000 free (2200 frags, 4600 blocks)
.R
.DE
.PP
If there are inconsistencies in the filesystem, you may be prompted
to apply corrective action; see the
.Xr fsck (8)
or \fIFsck \(en The UNIX File System Check Program\fP (SMM:3) for more details.
.PP
To use the
.Pn /usr/src
filesystem, you should now remount it with:
.DS
\fB#\fP \fImount /dev/\*(Dk0f /usr/src\fP
.DE
or if you have made an entry for it in
.Pn /etc/fstab
you can remount it with:
.DS
\fB#\fP \fImount /usr/src\fP
.DE
.Sh 2 "Additional conversion information"
.PP
After setting up the new \*(4B filesystems, you may restore the user
files that were saved on tape before beginning the conversion.
Note that the \*(4B
.Xr restore
program does its work on a mounted filesystem using normal system operations.
This means that filesystem dumps may be restored even
if the characteristics of the filesystem changed.
To restore a dump tape for, say, the
.Pn /a
filesystem something like the following would be used:
.DS
\fB#\fP \fImkdir /a\fP
\fB#\fP \fInewfs \*(Dk#p\fI
\fB#\fP \fImount /dev/\*(Dk#p /a\fP
\fB#\fP \fIcd /a\fP
\fB#\fP \fIrestore x\fP
.DE
.PP
If
.Xr tar
images were written instead of doing a dump, you should
be sure to use its `\-p' option when reading the files back.  No matter
how you restore a filesystem, be sure to unmount it and and check its
integrity with
.Xr fsck (8)
when the job is complete.