第9章 　硬盘、 文件系统和引导加载器

请参阅 FreeBSD 使用手册中关于 如何添加磁盘 的说明。

理想的做法是在新磁盘上重新安装 OS， 然后将用户数据挪上去。 如果您长期使用 -STABLE， 或更新到了一个新的版本时， 这也是推荐的方式。 您可以使用 boot0cfg(8) 在新旧两块硬盘上安装 booteasy， 在两个系统之间双启动， 直至对新配置满意为止。 如果您这样做了， 就可以直接跳过下一段， 开始迁移数据了。

有时您可能不希望进行一次完整的全新安装， 此时应使用 sysinstall(8) 或 fdisk(8) 和 disklabel(8) 对新磁盘进行分区和 label。 此外i， 您还应使用 boot0cfg(8) 在两块硬盘上都安装 booteasy， 以便在复制完成后能够选择启动新旧系统。 请参见 介质格式化 介绍文章 以了解这一过程的细节。

现在您的新磁盘已经就绪， 并可以往上搬移数据了。 不过， 您并不能闭着眼睛复制全部数据。 类似设备文件 (在 /dev 中)、 文件系统标记， 以及连接这样的东西， 很可能会使这一过程失败。 您需要使用能够能够支持这些文件的工具， 例如 dump(8) 来进行配置。 除此之外， 尽管一般而言推荐在单用户模式下进行迁移， 但这并不是必需的。

在搬移根文件系统时， 不应使用 dump(8) 和 restore(8) 之外的任何工具。 tar(1) 命令也许能用 ── 但如之前所说的那样， 也可能不能用。 如果从一个分区搬移到另一个空白分区时， 您就应使用 dump(8) 和 restore(8)。 使用 dump 将一个分区上的数据搬移到另一个分区上的操作如下：

举例来说， 如果您准备将根分区挪到 /dev/ad1s1a， 并使用 /mnt 作为临时挂接点， 则命令为：

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore xf -

使用 dump 来重新整理分区所需要的操作更多一些。 如果希望将类似 /var 这样的分区与其父目录合并， 需要创建一个能够容纳下两者的分区， 并像前面介绍的那样移动父目录所在的分区， 然后将子目录所在的分区移动到那个分区上：

# newfs /dev/ad1s1a
# mount /dev/ad1s1a /mnt
# cd /mnt
# dump 0af - / | restore xf -
# cd var
# dump 0af - /var | restore xf -

要将一个目录从其父目录分离出来， 例如将 /var 放到一个单独的分区中， 应首先创建分区， 然后将分区挂接到各自的子目录， 接着移动老的单个分区：

# newfs /dev/ad1s1a
# newfs /dev/ad1s1d
# mount /dev/ad1s1a /mnt
# mkdir /mnt/var
# mount /dev/ad1s1d /mnt/var
# cd /mnt
# dump 0af - / | restore xf -

在迁移用户数据时， 您可能更喜欢用 cpio(1)、 pax(1)、 tar(1) 而不是 dump(8)。 目前， 这些工具都可能导致文件标记 (flag) 信息丢失， 因此应小心使用。

在安装过程中， 会提示您从两种不同分区方式之一来对硬盘完成分区的操作。 默认的方式是与其他操作系统兼容的， 其方法是使用 fdisk(8) 分区表 (在 FreeBSD 中称作 “slices”)， 并使用这个 FreeBSD slice。 这时， 您也可以选择安装启动选择器， 以便在启动时选择磁盘上已经安装的操作系统。 另一种方式， 则将整个磁盘交由 FreeBSD 使用， 从而不提供对其他操作系统的兼容性。

那么， 为什么这种方式被叫做 “危险的 (dangerous)” 呢？ 这是因为在这种模式并不包含普通 PC 工具能识别的有效 fdisk(8) 分区表。 随这些工具设计的不同， 在您试图操作这些磁盘时， 它们有可能会产生错误提示， 或者在更糟糕的情况下， 这些工具可能会在不询问和通知您的情况下毁掉 BSD 的引导记录。 此外目前已经知道， “dangerously dedicated” 这种磁盘格式， 会导致许多 BIOS， 包括 AWARD (例如 HP Netserver 和 Micronics 的服务器， 以及许多台式机) 和 Symbios/NCR (见于 53C8xx 系列的 SCSI 控制器) 出现问题。 这并不是完整的列表， 仍有许多其他问题。 这些问题的现象包括 FreeBSD 引导记录提示 “read error” 消息表示无法找到自己， 以及系统在启动时死锁等等。

那么， 为什么要提供这种模式呢？ 它只能节省几 k 字节的磁盘空间， 而且可能会给全新安装的系统带来问题。 “Dangerously dedicated” 模式最初是为了解决阻碍 FreeBSD 安装的一个常见问题 ── BIOS 提供的 “几何尺寸” 参数与磁盘不一致 ── 而设计的。

“Geometry” is an outdated concept, but one still at the heart of the PC's BIOS and its interaction with disks. When the FreeBSD installer creates slices, it has to record the location of these slices on the disk in a fashion that corresponds with the way the BIOS expects to find them. If it gets it wrong, you will not be able to boot.

“Dangerously dedicated” mode tries to work around this by making the problem simpler. In some cases, it gets it right. But it is meant to be used as a last-ditch alternative ── there are better ways to solve the problem 99 times out of 100.

So, how do you avoid the need for “DD” mode when you are installing? Start by making a note of the geometry that your BIOS claims to be using for your disks. You can arrange to have the kernel print this as it boots by specifying -v at the boot: prompt, or using boot -v in the loader. Just before the installer starts, the kernel will print a list of BIOS geometries. Do not panic ── wait for the installer to start and then use scrollback to read the numbers. Typically the BIOS disk units will be in the same order that FreeBSD lists your disks, first IDE, then SCSI.

When you are slicing up your disk, check that the disk geometry displayed in the FDISK screen is correct (ie. it matches the BIOS numbers); if it is wrong, use the G key to fix it. You may have to do this if there is absolutely nothing on the disk, or if the disk has been moved from another system. Note that this is only an issue with the disk that you are going to boot from; FreeBSD will sort itself out just fine with any other disks you may have.

Once you have got the BIOS and FreeBSD agreeing about the geometry of the disk, your problems are almost guaranteed to be over, and with no need for “DD” mode at all. If, however, you are still greeted with the dreaded “read error” message when you try to boot, it is time to cross your fingers and go for it - there is nothing left to lose.

To return a “dangerously dedicated” disk for normal PC use, there are basically two options. The first is, you write enough NULL bytes over the MBR to make any subsequent installation believe this to be a blank disk. You can do this for example with

# dd if=/dev/zero of=/dev/rda0 count=15

Alternatively, the undocumented DOS “feature”

C:\> fdisk /mbr

will to install a new master boot record as well, thus clobbering the BSD bootstrap.

Short answer: you can usually use Soft Updates safely on all partitions.

Long answer: There used to be some concern over using Soft Updates on the root partition. Soft Updates has two characteristics that caused this. First, a Soft Updates partition has a small chance of losing data during a system crash. (The partition will not be corrupted; the data will simply be lost.) Also, Soft Updates can cause temporary space shortages.

When using Soft Updates, the kernel can take up to thirty seconds to actually write changes to the physical disk. If you delete a large file, the file still resides on disk until the kernel actually performs the deletion. This can cause a very simple race condition. Suppose you delete one large file and immediately create another large file. The first large file is not yet actually removed from the physical disk, so the disk might not have enough room for the second large file. You get an error that the partition does not have enough space, although you know perfectly well that you just released a large chunk of space! When you try again mere seconds later, the file creation works as you expect. This has left more than one user scratching his head and doubting his sanity, the FreeBSD filesystem, or both.

If a system should crash after the kernel accepts a chunk of data for writing to disk, but before that data is actually written out, data could be lost or corrupted. This risk is extremely small, but generally manageable. Use of IDE write caching greatly increases this risk; it is strongly recommended that you disable IDE write caching when using Soft Updates.

These issues affect all partitions using Soft Updates. So, what does this mean for the root partition?

Vital information on the root partition changes very rarely. Files such as /boot/kernel/kernel and the contents of /etc only change during system maintenance, or when users change their passwords. If the system crashed during the thirty-second window after such a change is made, it is possible that data could be lost. This risk is negligible for most applications, but you should be aware that it exists. If your system cannot tolerate this much risk, do not use Soft Updates on the root filesystem!

/ is traditionally one of the smallest partitions. If you put the /tmp directory on / and you have a busy /tmp, you might see intermittent space problems. Symlinking /tmp to /var/tmp will solve this problem.

The symptom of this is:

# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

This usually happens when you are trying to concatenate the c partitions, which default to type unused. The ccd(4) driver requires the underlying partition type to be FS_BSDFFS. Edit the disklabel of the disks you are trying to concatenate and change the types of partitions to 4.2BSD.

The symptom of this is:

# disklabel ccd0
(it prints something sensible here, so let us try to edit it)
# disklabel -e ccd0
(edit, save, quit)
disklabel: ioctl DIOCWDINFO: No disk label on disk;
use "disklabel -r" to install initial label

This is because the disklabel returned by ccd(4) is actually a “fake” one that is not really on the disk. You can solve this problem by writing it back explicitly, as in:

# disklabel ccd0 > /tmp/disklabel.tmp
# disklabel -Rr ccd0 /tmp/disklabel.tmp
# disklabel -e ccd0
(this will work now)

FreeBSD supports a variety of other filesystems.

FreeBSD also supports network filesystems such as NFS (see mount_nfs(8)), NetWare (see mount_nwfs(8)), and Microsoft-style SMB filesystems (see mount_smbfs(8)). You can find ports based on FUSE (sysutils/fusefs-kmod) for many other filesystems.

The secondary DOS partitions are found after all the primary partitions. For example, if you have an “E” partition as the second DOS partition on the second SCSI drive, there will be a device file for “slice 5” in /dev, so simply mount it:

# mount -t msdos /dev/da1s5 /dos/e

Yes. You can use either gbde(8) or geli(8), see the Encrypting Disk Partitions section of the FreeBSD Handbook.

The general idea is that you copy the first sector of your native root FreeBSD partition into a file in the DOS/Windows NT partition. Assuming you name that file something like c:\bootsect.bsd (inspired by c:\bootsect.dos), you can then edit the c:\boot.ini file to come up with something like this:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
C:\BOOTSECT.BSD="FreeBSD"
C:\="DOS"

If FreeBSD is installed on the same disk as the Windows NT boot partition simply copy /boot/boot1 to C:\BOOTSECT.BSD. However, if FreeBSD is installed on a different disk /boot/boot1 will not work, /boot/boot0 is needed.

/boot/boot0 needs to be installed using sysinstall(8) by selecting the FreeBSD boot manager on the screen which asks if you wish to use a boot manager. This is because /boot/boot0 has the partition table area filled with NULL characters but sysinstall(8) copies the partition table before copying /boot/boot0 to the MBR.

When the FreeBSD boot manager runs it records the last OS booted by setting the active flag on the partition table entry for that OS and then writes the whole 512-bytes of itself back to the MBR so if you just copy /boot/boot0 to C:\BOOTSECT.BSD then it writes an empty partition table, with the active flag set on one entry, to the MBR.

If you have FreeBSD and Linux on the same disk, just follow LILO's installation instructions for booting a non-Linux operating system. Very briefly, these are:

Boot Linux, and add the following lines to /etc/lilo.conf:

other=/dev/hda2
        table=/dev/hda
        label=FreeBSD

(the above assumes that your FreeBSD slice is known to Linux as /dev/hda2; tailor to suit your setup). Then, run lilo as root and you should be done.

If FreeBSD resides on another disk, you need to add loader=/boot/chain.b to the LILO entry. For example:

other=/dev/dab4
        table=/dev/dab
        loader=/boot/chain.b
        label=FreeBSD

In some cases you may need to specify the BIOS drive number to the FreeBSD boot loader to successfully boot off the second disk. For example, if your FreeBSD SCSI disk is probed by BIOS as BIOS disk 1, at the FreeBSD boot loader prompt you need to specify:

Boot: 1:da(0,a)/boot/kernel/kernel

You can configure boot(8) to automatically do this for you at boot time.

The Linux+FreeBSD mini-HOWTO is a good reference for FreeBSD and Linux interoperability issues.

Booting FreeBSD using GRUB is very simple. Just add the following to your configuration file /boot/grub/menu.lst (or /boot/grub/grub.conf in some systems, e.g. Red Hat Linux and its derivatives).

title FreeBSD 6.1
    root (hd0,a)
    kernel /boot/loader
     

Where hd0,a points to your root partition on the first disk. If you need to specify which slice number should be used, use something like this (hd0,2,a). By default, if the slice number is omitted, GRUB searches the first slice which has a partition.

Install LILO at the start of your Linux boot partition instead of in the Master Boot Record. You can then boot LILO from BootEasy.

If you are running Windows® and Linux this is recommended anyway, to make it simpler to get Linux booting again if you should need to reinstall Windows (which is a Jealous Operating System, and will bear no other Operating Systems in the Master Boot Record).

You can not do that with the standard boot manager without rewriting it. There are a number of other boot managers in the sysutils ports category that provide this functionality.

Whether it is a removable drive like a Zip® or an EZ drive (or even a floppy, if you want to use it that way), or a new hard disk, once it is installed and recognized by the system, and you have your cartridge/floppy/whatever slotted in, things are pretty much the same for all devices.

(this section is based on Mark Mayo's ZIP FAQ)

If it is a ZIP drive or a floppy, you have already got a DOS filesystem on it, you can use a command like this:

# mount -t msdos /dev/fd0c /floppy

if it is a floppy, or this:

# mount -t msdos /dev/da2s4 /zip

for a ZIP disk with the factory configuration.

For other disks, see how they are laid out using fdisk(8) or sysinstall(8).

The rest of the examples will be for a ZIP drive on da2, the third SCSI disk.

Unless it is a floppy, or a removable you plan on sharing with other people, it is probably a better idea to stick a BSD filesystem on it. You will get long filename support, at least a 2X improvement in performance, and a lot more stability. First, you need to redo the DOS-level partitions/filesystems. You can either use fdisk(8) or sysinstall(8), or for a small drive that you do not want to bother with multiple operating system support on, just blow away the whole FAT partition table (slices) and just use the BSD partitioning:

# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto

You can use disklabel(8) or sysinstall(8) to create multiple BSD partitions. You will certainly want to do this if you are adding swap space on a fixed disk, but it is probably irrelevant on a removable drive like a ZIP.

Finally, create a new filesystem, this one is on our ZIP drive using the whole disk:

# newfs /dev/rda2c

and mount it:

# mount /dev/da2c /zip

and it is probably a good idea to add a line like this to /etc/fstab (see fstab(5)) so you can just type mount /zip in the future:

/dev/da2c /zip ffs rw,noauto 0 0

You have to tell mount(8) the type of the device that you want to mount. This is described in the Handbook section on optical media, specifically the section Using Data CDs.

This generally means that there is no CDROM in the CDROM drive, or the drive is not visible on the bus. Please see the Using Data CDs section of the Handbook for a detailed discussion of this issue.

Your CDROM probably uses the “Joliet” extension for storing information about files and directories. This is discussed in the Handbook chapter on creating and using CDROMs, specifically the section on Using Data CDROMs.

You most likely burned a raw file to your CD, rather than creating an ISO 9660 filesystem. Take a look at the Handbook chapter on creating CDROMs, particularly the section on burning raw data CDs.

This is discussed in the Handbook section on duplicating data CDs. For more on working with CDROMs, see the Creating CDs Section in the Storage chapter in the Handbook.

If you try to mount an audio CD, you will get an error like “cd9660: /dev/acd0c: Invalid argument”. This is because mount only works on filesystems. Audio CDs do not have filesystems; they just have data. You need a program that reads audio CDs, such as the audio/xmcd port.

By default, mount(8) will attempt to mount the last data track (session) of a CD. If you would like to load an earlier session, you must use the -s command line argument. Please see mount_cd9660(8) for specific examples.

Ordinary users can be permitted to mount devices. Here is how:

All users can now mount the floppy /dev/fd0 onto a directory that they own:

% mkdir ~/my-mount-point
% mount -t msdos /dev/fd0 ~/my-mount-point

Users in group operator can now mount the CDROM /dev/acd0c onto a directory that they own:

% mkdir ~/my-mount-point
% mount -t cd9660 /dev/acd0c ~/my-mount-point

Unmounting the device is simple:

% umount ~/my-mount-point

Enabling vfs.usermount, however, has negative security implications. A better way to access MS-DOS® formatted media is to use the emulators/mtools package in the Ports Collection.

You need to understand what du and df really do. du goes through the directory tree, measures how large each file is, and presents the totals. df just asks the filesystem how much space it has left. They seem to be the same thing, but a file without a directory entry will affect df but not du.

When a program is using a file, and you delete the file, the file is not really removed from the filesystem until the program stops using it. The file is immediately deleted from the directory listing, however. You can see this easily enough with a program such as more. Assume you have a file large enough that its presence affects the output of du and df. (Since disks can be so large today, this might be a very large file!) If you delete this file while using more on it, more does not immediately choke and complain that it cannot view the file. The entry is simply removed from the directory so no other program or user can access it. du shows that it is gone ── it has walked the directory tree and the file is not listed. df shows that it is still there, as the filesystem knows that more is still using that space. Once you end the more session, du and df will agree.

Note that Soft Updates can delay the freeing of disk space; you might need to wait up to 30 seconds for the change to be visible!

This situation is common on web servers. Many people set up a FreeBSD web server and forget to rotate the log files. The access log fills up /var. The new administrator deletes the file, but the system still complains that the partition is full. Stopping and restarting the web server program would free the file, allowing the system to release the disk space. To prevent this from happening, set up newsyslog(8).

In the Configuration and Tuning section of the Handbook, you will find a section describing how to do this.

Disk manufacturers calculate gigabytes as a billion bytes each, whereas FreeBSD calculates them as 1,073,741,824 bytes each. This explains why, for example, FreeBSD's boot messages will report a disk that supposedly has 80 GB as holding 76,319 MB.

Also note that FreeBSD will (by default) reserve 8% of the disk space.

A portion of each UFS partition (8%, by default) is reserved for use by the operating system and the root user. df(1) does not count that space when calculating the Capacity column, so it can exceed 100%. Also, you will notice that the Blocks column is always greater than the sum of the Used and Avail columns, usually by a factor of 8%.

For more details, look up the -m option in tunefs(8).