Protecting Critical Infrastructure: Process Control and SCADA

Windows IT Pro

- Advertise

Protecting Critical Infrastructure: Process Control and SCADA
View the book table of contents

Author:	Craig Schiller
Published:	November 2007
Copyright:	2007
Publisher:	Syngress Publishing

In this chapter we’ll consider the most common disk tasks every system administrator performs.

The importance of managing filesystems and disks cannot be overemphasized. (Go ahead, try to emphasize it too much. I’ll wait.) Your disks contain your data, making reliability and flexibility paramount to the operating system. FreeBSD supports a variety of filesystems and has many different ways to handle them. In this chapter we’ll consider the most common disk tasks every system administrator performs.

DISK DRIVES 101

Most people treat disk drives as fragile magic boxes. If you treat a drive badly, you can make the drive screech and grind, and with enough abuse, you can let the magic smoke escape so it will never work again. To really understand filesystems, you must know a little bit about what’s going on inside the drive. If you have a dusty old disk drive that you no longer have any respect for, feel free to crack the case and follow along.

Inside the hard drive case you’ll find a stack of round aluminum or plastic disks, commonly called platters. When the drive is active, the platters spin at thousands of revolutions per minute. The RPM count on hard drives measures platter rotation speed.

A thin layer of magnetic media covers the platters. This magnetic material is arranged in thousands of circular rings, called tracks, that extend from the platter’s inner core to its outer edge, much like the growth rings in a tree. These tracks hold data as strings of zeros and ones. Each track is subdivided into sectors. Each sector on the outer tracks holds more data than a corresponding sector on an inner track, and reading a constant amount of data takes less time on an outer track than on an inner track because any point on the outer track is moving faster.

Heads, mounted over each platter, write and read data as the platters pass by, much like a phonograph needle. These heads can read and write data quickly, but they must wait for the disk to move into the proper position under them. Drive performance basically boils down to how quickly those platters can move under the drive heads, which is what makes RPM important.

ATA, SATA, SCSI, AND SAS

I assume that you’re familiar with the basics of the standard disk storage technologies. If you’re not, please spend a few moments online with any of the excellent tutorials on these subjects, or even the brief articles available on Wikipedia. I’ll make suggestions here and there about how these technologies can be used, but SCSI IDs and LUNs are a subject for another book.

DEVICE NODES

We touched briefly on device nodes in Chapter 3, but let’s consider them in more detail. Device nodes are special files that represent hardware on the system. They’re used as logical interfaces between user programs and either a device driver or a physical device. By using a command on a device node, sending information to a device node, or reading data from a device node, you’re telling the kernel to perform an action upon a physical device. These actions can be very different for different devices—writing data to a disk is very different than writing data to a sound card. All device nodes exist in /dev.

Before you can work with a disk or disk partition, you must know its device name. FreeBSD disk device nodes come from the names of the device drivers for that type of hardware. Device driver names, in turn, come from the chipset used in the device and not from what the device appears to be.

Table 8-1 shows the most common disk device nodes. See the man page for each if you want the full details.

Disks attached to most hardware RAID controllers don’t use device names for each disk. Instead, these RAID controllers present a virtual disk for each RAID container, using a device node named after the RAID driver. For example, the amr(4) driver presents its virtual disks as /dev/amrd*. A few RAID cards use the cam(4) abstraction layer, so their hard drives do show up as /dev/da* devices.

Hard Disks and Partitions

While we discussed partitioning in Chapter 2, let’s consider partitions from a disk device perspective. The first possible ATA disk on our first ATA controller is called /dev/ad0. Subsequent disks are /dev/ad1, /dev/ad2, and so on. Subdivisions of each disk start with this name and add something at the end, like /dev/ad0s1b. While you might expect a disk to be a monolithic whole, you’ll see lots of subdivisions if you look in /dev for everything that begins with /dev/ad0.

# ls /dev/ad*
/dev/ad0    /dev/ad0s1a    /dev/ad0s1c    /dev/ad0s1e
/dev/ad0s1  /dev/ad0s1b    /dev/ad0s1d    /dev/ad0s1f

So, what are all these subdivisions? Think back to when you allocated disk space. If you followed the recommendations in this book, you used the whole disk for FreeBSD. You could have created a second chunk of disk for a second operating system, or even cut the disk into two FreeBSD sections. These sections are called partitions in the Microsoft and Linux worlds, and slices in FreeBSD land. The s1 in the preceding list represents these large partitions, or slices. The drive ad0 has one slice, ad0s1, with further subdivisions marked by letters.

In FreeBSD, a partition is a further subdivision within a slice. You created partitions inside the slice during the install. Each partition has a unique device node name created by adding a letter to the slice device node. For example, partitions inside the slice /dev/ad0s1 show up as /dev/ad0s1a, /dev/ad0s1b, /dev/ad0s1c, and so on. Each partition you created—/usr, /var, and so on—is assigned one of these device nodes.

You can assign partition device names almost arbitrarily, with some exceptions. Tradition says that the node ending in a (in our example, /dev/ad0s1a) is the root partition, and the node ending in b (/dev/ad0s1b) is the swap space. The c label indicates the entire slice, from beginning to end. You can assign d through h to any partition you like. You can have only eight partitions in one slice, and up to four slices per drive. For example, the device node /dev/ad0s1a is disk number 0, slice 1, partition 1, and is probably the root filesystem. The device node /dev/ad1s2b is on disk number 2, and is probably swap space.

If you have non-ATA disks, substitute the appropriate device for /dev/ad.

ATA DISK NUMBERING

Just because the first possible ATA disk on the system would be /dev/ad0 doesn’t mean that you have to have a hard drive /dev/ad0 installed. My laptop’s hard drive is /dev/ad4 because it’s on a RAID controller, not on the built-in ATA controller. SCSI and SAS hard drives are smarter about this and generally number the first disk with /dev/da0 no matter where they’re attached. Removing the kernel option ATA_STATIC_ID makes ATA disks start numbering at 0, if you desire.

THE FILESYSTEM TABLE: /etc/fstab

So, how does your system map these device names to partitions? With the filesystem table, /etc/fstab. In that file, each filesystem appears on a separate line, along with any special options used by mount(8). Here’s a sample entry from a filesystem table:

/dev/ad4s2a    /    ufs    rw    1    1

The first field in each entry gives the device name.

The second field lists the mount point, or the directory where the filesystem is attached. Every partition you can write files to is attached to a mount point such as /usr, /var, and so on. A few special partitions, such as swap space, have a mount point of none. You can’t write files to swap space— at least, not if you want to use either the file or the swap space!

Next, we have the type of filesystem on this partition. The standard FreeBSD partition is of type ufs, or Unix Fast File System. The example below includes swap (swap space), cd9660 (CD), and nfs (Network File System). Before you can attach a partition to your directory tree, you must know what sort of filesystem it has. As you might guess, trying to mount a DOS floppy as an FFS filesystem will fail.

The fourth field shows the mount options used on this filesystem. The mount options tell FreeBSD to treat the filesystem in a certain matter. We’ll discuss mount options in more detail later in this chapter, but here are a few special ones used only by /etc/fstab:

ro The filesystem is mounted as read-only. Not even root can write to it.

rw The filesystem is mounted read-write.

noauto FreeBSD won’t automatically mount the filesystem, neither at boot nor when using mount -a. This option is useful for removable media drives which might not have media in them at boot. The fifth field tells the dump(8) whether or not this filesystem needs dumping. If set to 0, dump won’t back up the filesystem at all. Otherwise, the number gives the minimum dump level needed to trigger a backup of this filesystem. See Chapter 4 for details.

The last field, Pass#, tells the system when to check the filesystem’s integrity during the boot process. All of the partitions in the same Pass# are checked in parallel with fsck(8). Only the root filesystem has a Pass# of 1, and it is checked first. All other filesystems are set to 2, which means that FreeBSD mounts them after the root filesystem. Swap and read-only media don’t require integrity checking, so are set to 0.

With this knowledge, let’s look at a complete /etc/fstab.

Our first entry, /dev/ad4s1b

, is swap space. It isn’t mounted anywhere; FreeBSD uses swap as secondary memory.

The second entry

is the root partition. Note the device name—while swap is partition b on slice 1, the root filesystem is partition a on slice 2. The root directory is on a different slice than the swap space!

The third partition is /dev/ad4s1a

. We’d normally expect the root partition to be here, but instead it’s mounted as /amd64. The next two partitions are also on slice 1, but mounted under /amd64.

Our /tmp

filesystem is a partition on slice 1, which contains the /amd64 filesystem.

The next entries, /usr

and /var

, are normal-looking partitions on slice 2.

The next partition, /home

, is on the same disk, slice 3, partition d. Where the heck did slice 3 come from?

Our CD drive is mounted on /cdrom

and is not automatically mounted at boot.

The final entry doesn’t start with a device node. This is a Network File System (NFS) entry, and it tells us to mount the partition mp3 on the machine data as /mp3 on the local machine when we specifically request it. We’ll talk about NFS later in this chapter.

This filesystem table comes from a dual-boot machine, running FreeBSD/ i386 and FreeBSD/amd64. That’s why the table doesn’t look quite normal. I can access the amd64 filesystem and use the amd64 swap space while running the i386 slice.

WHAT'S MOUNTED NOW?

If not all filesystems are mounted automatically at boot, and if the sysadmin can request additional mounts, how can you determine what’s mounted right now on the system? Run mount(8) without any options to see a list of all mounted filesystems.

# mount
/dev/ad4s2a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad4s1e on /tmp (ufs, local, soft-updates)
/dev/ad4s2e on /usr (ufs, local, soft-updates)
/dev/ad4s2d on /var (ufs, local, soft-updates)
/dev/ad4s3d on /usr/home (ufs, local, soft-updates)

Here we see that our filesystems are almost all standard UFS partitions. The word local means that the partition is on a hard drive attached to this machine. We also see soft-updates, a feature of the FreeBSD filesystem we’ll discuss later in this chapter. If you’re using features such as NFS or SMB to mount partitions, they’ll appear here.

mount(8) is a quick way to get the device names for each of your partitions, but it also provides other functions.

MOUNTING AND UNMOUNTING DISKS

mount(8)’s main purpose is to mount partitions onto your filesystem. If you’ve never played with mounting before, boot your FreeBSD machine into the single-user mode (see Chapter 3) and follow along.

In single-user mode FreeBSD has mounted the root partition read-only. The root partition contains just enough of the system to perform basic setup, get core services running, and find the rest of the filesystems. Those other filesystems are not mounted, so their content is inaccessible. Go ahead and look in /usr on a system in single-user mode; it’s empty. FreeBSD hasn’t lost the files, it just hasn’t mounted the partition with those files on it yet. To do anything interesting in single-user mode, you must mount other filesystems.

Mounting Standard Filesystems

To manually mount a filesystem listed in /etc/fstab, such as /var or /usr, give mount(8) the name of the filesystem you want to mount.

# mount /usr

This mounts the partition exactly as listed in /etc/fstab, with all the options specified in that file. If you want to mount all the partitions listed in /etc/fstab, use mount’s -a flag.

# mount -a

Mounting at Nonstandard Locations

Perhaps you need to mount a filesystem at an unusual point. I do this most commonly when installing a new disk. Use the device name and the desired mount point. If my /usr partition is /dev/ad0s1e, and I want to mount it on /mnt, I would run:

# mount /dev/ad0s1e /mnt

Unmounting a Partition

When you want to disconnect a filesystem from the system, use umount(8) to tell the system to unmount the partition. (Note that the command is umount, not unmount.)

# umount /usr

You cannot unmount filesystems that are in use by any program. If you cannot unmount a partition, you’re probably accessing it somehow. Even a command prompt in the mounted directory prevents you from unmounting the underlying partition.

HOW FULL IS A PARTITION?

To get an overview of how much space each partition has left, use df(1). This provides a list of partitions on your system, the amount of space used by each one, and where it’s mounted. The annoying thing about df is that it defaults to providing information in 1KB blocks. This was fine when disks were much much smaller, but counting out blocks can make you go cross-eyed today. Fortunately, the -h and -H flags provide human-readable output. The small -h uses base 2 to create a 1,024-byte megabyte, while the large -H uses base 10 for a 1,000-byte megabyte. Typically, network administrators and disk manufacturers use base 10, while system administrators use base 2.¹ Either works so long as you know which you’ve chosen. I’m a network administrator, so you get to suffer through my prejudices in these examples, despite what my tech editor thinks.

# df -H 
Filesystem    Size    Used    Avail    Capacity    Mounted on 
/dev/ad4s2a   520M    301M    177M     63%         / 
devfs         1.0k    1.0k    0B       100%        /dev 
/dev/ad4s1e   520M    2.4M    476M     0%          /tmp 
/dev/ad4s2e   11G     4.1G    5.9G     41%         /usr 
/dev/ad4s2d   1.0G    322M    632M     34%         /var 
/dev/ad4s3d   49G     43G     2.0G     96%         /usr/home

Here we see the partition name, the size of the partition, the amount of space used, the amount of space available, the percent of space used, and the mount point. For example, the home directory on this machine is 96 percent full, but it still has 2GB of disk free. The root partition is only 63 percent full, but it has only 177MB free.

FFS holds back 8 percent of the disk space for on-the-fly optimization. This is used for moving files and reducing fragmentation. You can overfill your disks and see negative disk space remaining. When this happens, disk performance drops dramatically. It is best to keep a little free space on your partitions, so that FFS can continually defragment itself. While you can adjust the filesystem to reduce the amount of reserved space, this negatively impacts performance and is basically unwise. See tunefs(8) if you really want to try it.

The obvious question is, "What is taking up all that space?" If your systems are like mine, disk usage somehow keeps growing for no apparent reason. You can identify individual large files with ls -l, but recursively doing this on every directory in the system is impractical.

$BLOCKSIZE

Many disk tools show sizes in bocks of 512 bytes, or one-haf KB.f you set the environment variable $BLOCKSIZE, to k, df(1) and many other programs dispay fie sizes in blocks of 1KB, which is much more usefu. Others like a setting of 1M, for sizes in megabytes.

du(1) displays disk usage in a single directory. Its initial output is intimidating and can scare off inexperienced users. Here, we use du(1) to find out what’s taking up all the space in my home directory:

# cd $HOME 
# du 
1      ./bin/RCS 
21459  ./bin/wp/shbin10 
53202  ./bin/wp 
53336  ./bin 
5      ./.kde/share/applnk/staroffice_52 
6      ./.kde/share/applnk 
...

This goes on and on, displaying every subdirectory and giving its size in blocks. The total of each subdirectory is given—for example, the contents of $HOME/bin totals 53,336 blocks, or roughly 53MB. I could sit and let du(1) list every directory and subdirectory, but then I’d have to dig through much more information than I really want to. And blocks aren’t that convenient a measurement, especially not when they’re printed left-justified.

Let’s clean this up. First, du(1) supports an -h flag much like df. Also, I don’t need to see the recursive contents of each subdirectory. We can control the number of directories we display with du’s -d flag. This flag takes one argument, the number of directories you want to explicitly list. For example, -d0 goes one directory deep and gives a simple subtotal of the files in a directory.

# du -h -d0 $HOME 
 37G     /home/mwlucas

I have 37 gigs of data in my home directory? Let’s look a layer deeper and identify the biggest subdirectory.

# du  -h  -d1 
38K       ./bin 
56M       ./mibs 
... 
34G       ./mp3 
...

Apparently I must look elsewhere for storage space, as the data in my home directory is too important to delete. If you’re not too attached to the -h flag, you can use sort(1) to find the largest directory with a command like du -kxd 1 | sort -n.

THE FAST FILE SYSTEM

FreeBSD’s filesystem, the Fast File System (FFS), is a direct descendant of the filesystem shipped with BSD 4.4. One of the original FFS authors still develops the FreeBSD filesystem and has added many nifty features in recent years. FFS is sometimes called UFS (for Unix File System), and many system utilities still call FFS partitions UFS. FreeBSD is not the only operating system to still use the 4.4 BSD filesystem or a descendant thereof. If a Unix vendor doesn’t specifically tout its "improved and advanced" filesystem, it is almost certainly running a derivative of FFS.

FFS is designed to be fast and reliable, and to handle the most common situations as effectively as possible while still supporting unusual situations reliably. FreeBSD ships with FFS configured to be as widely useful as possible on relatively modern hardware, but you can choose to optimize a particular filesystem for trillions of small files or a half-dozen 30GB files if you must. You don’t have to know much about FFS’s internals, but you do need to understand blocks, fragments, and inodes, if nothing else.

Blocks are segments of disk that contain data. FreeBSD defaults to 16KB blocks. Not all files are even multiples of 16KB, so FFS uses fragments to store leftovers. The standard is one-eighth of the block size, or 2KB. For example, a 20KB file would fill one block and two fragments. Inodes are index nodes, special blocks that contain basic data such as a file’s size, permissions, and the list of blocks that this file uses. Collectively, the data in an inode is known as metadata, or data about data. This arrangement isn’t unique to FFS; other filesystems such as NTFS use data blocks and index nodes as well. The indexing system used by each filesystem is largely unique, however.

Each filesystem has a certain number of inodes, proportional to the filesystem size. A modern disk probably has hundreds of thousands of inodes on each partition, which is sufficient to support hundreds of thousands of files. If you have a truly large number of very tiny files, however, you might need to rebuild your filesystem to support additional inodes. Use df -i to see how many inodes remain free on your filesystem. If you must rebuild your filesystem to increase the number of inodes, see Chapter 18.

Vnodes

Inodes and blocks worked wonderfully in Unix’s early days, when hard drives were permanently attached to machines. As time passed, however, swapping disks between different machines and even different operating systems became common. CDs, with their unique read-only filesystem, became popular, floppy disks slowly converged on the FAT32 filesystem as a standard, and other Unix-like systems developed their own variant filesystems. Since BSD needed to speak to all those different systems, another layer of abstraction was needed.

That abstraction was the virtual node, or vnode. Users never manipulate vnodes directly, but you’ll see references to them throughout the system documentation. The vnode is a translator between the kernel and whatever specific filesystem type you’ve mounted. Every tool that reads and writes to disks actually does so through vnodes, which map the data to the appropriate filesystem for the underlying media. When you write a file to an FFS filesystem, the kernel addresses data to a vnode which, in turn, is mapped to an inode. When you write a file to a FAT32 filesystem, the kernel addresses data to a vnode mapped to a point in the FAT32 filesystem. You use inodes only when dealing with FFS filesystems, but you’ll use vnodes when dealing with any filesystem.

FFS Mount Types

Unlike Windows filesystems, FreeBSD treats FFS partitions differently depending on how they’re mounted. The manner in which a partition is mounted is called the mount type. If you’re mounting a partition manually, you can specify mount options on the command line, but if you’re using /etc/fstab to mount it, you must specify any choice in the Options column.

Use -o mounttype to specify a mount type on the command line, or specify the option in /etc/fstab in the Options column.

Read-Only Mounts
If you want to look at the contents of a disk but not write to it, mount the partition read-only. In most cases, this is the safest and the most useless way to mount a disk, because you cannot alter the data on the disk or write any new data.

Many system administrators mount the root partition, and perhaps even /usr, as read-only to minimize potential system damage from a loss of power or software problems. Even if you lose the physical hard drive due to a power surge or other hardware failure, the data on the platters remains intact. That’s the advantage of read-only mounts. The disadvantage is that system maintenance becomes much more difficult because you cannot write to read-only disks!

Read-only mounts are especially valuable when your computer is damaged. While FreeBSD won’t let you perform a standard read-write mount on a damaged or dirty filesystem, it can perform a read-only mount most of the time. This gives you a chance to recover data from a dying system.

To mount a filesystem read-only, use one of the options rdonly or ro. Both work identically.

Synchronous Mounts
Synchronous (or sync) mounts are the old-fashioned way of mounting filesystems. When you write to a synchronously mounted disk, the kernel waits to see whether the write is actually completed before informing the program. If the write did not complete successfully, the program can choose to act accordingly.

Synchronous mounts provide the greatest data integrity in the case of a crash, but they are also slow. Admittedly, "slow" is relative today, when even a cheap disk outperforms what was the high end several years ago. Consider using synchronous mounting when you wish to be truly pedantic on data integrity, but in almost all cases it’s an overkill.

To mount a partition synchronously, use the option sync.

Asynchronous Mounts
While asynchronous mounts are pretty much supplanted by soft updates, you’ll still hear about them. For faster data access at higher risk, mount your partitions asynchronously. When a disk is asynchronously mounted, the kernel writes data to the disk and tells the writing program that the write succeeded without waiting for the disk to confirm that the data was actually written. Asynchronous mounting is fine on disposable machines, but don’t use it with important data. The performance difference between asynchronous mounts and noasync with soft updates is very small.

To mount a partition asynchronously, use the option async.

Noasync Mounts
Finally, we have a method that combines sync and async mounts, called noasync. This is FreeBSD’s default. When using noasync mounts, data that affects inodes is written to the disk synchronously, while actual data is handled asynchronously. Combined with soft updates (see later in this chapter), a noasync mount creates a very robust filesystem.

Noasync mounts are the default, and you don’t need to specify anything.

FFS Mount Options

FreeBSD supports several mount options in addition to the mount types. These options change the behavior of mounted filesystems.

noatime
Every file in FFS includes an access-time stamp, called the atime, which records when the file was last accessed. If you have a large number of files and don’t need this data, you can mount the disk noatime so that FFS does not update this timestamp. This is most useful for flash media or disks that suffer from heavy load, such as Usenet news spool drives.

noexec
The noexec mount option prevents any binaries from being executed on this partition. Mounting /home noexec can help prevent users from running their own programs, but for it to be effective, be sure to also mount /tmp, /var/tmp, and anywhere else users can write their own files noexec as well. Also note that a noexec mount doesn’t prevent a user from running a shell script, which is just a set of instructions for a program elsewhere in the system. Another common use for a noexec mount is when you have on your server binaries for a different operating system or a different hardware architecture and you don’t want anyone to execute them.

nosuid
The nosuid option prevents setuid programs from running on your system. Setuid programs allow users to run programs as if they’re another user. For example, programs such as login(1) must perform actions as root but must be run by regular users. Setuid programs obviously must be written carefully so that intruders cannot exploit them to get unauthorized access to your system. Many system administrators habitually disable all unneeded setuid programs. You can use nosuid to disable setuid programs on a partition, but script wrappers like suidperl get around this.

nosymfollow
The nosymfollow option disables symlinks, or aliases to files. Symlinks are mainly used to create aliases to files that reside on other partitions. To create an alias to another file on the same partition, use a regular link instead. See ln(1) for a discussion of links.

Aliases to directories are always symlinks; you cannot use a hard link for that.

Soft Updates and Journaling with FFS

Soft updates is a technology to organize and arrange disk writes so that filesystem metadata remains consistent at all times, giving nearly the performance of an async mount with the reliability of a sync mount. While that doesn’t mean that all data will be safely written to disk—a power failure at the wrong moment can still lose data—soft updates prevent many problems. If the system has a failure, soft updates can run its filesystem checks in the background while the system runs. In my opinion, soft updates are suitable for partitions of less than 80GB or so.

As of FreeBSD 7.0, FFS also supports journaling. A journaling filesystem records all changes made to the filesystem on a separate part of the disk, so that if the system shuts down unexpectedly, data changes can be recovered from the journal automatically upon restart. This eliminates the need to run fsck(8). Each journaled filesystem uses about 1GB for the journal, which means that journaling is wasteful on small filesystems. However, FreeBSD’s journaling differs from most journaled filesystems in that the journal is maintained in a disk layer beneath the filesystem rather than in the filesystem itself. This journaling is brand new in FreeBSD and is still considered somewhat experimental.

For example, as of this writing, I have a logging host. Most of the partitions are less than 10GB, but /var is almost two terabytes. I journal /var, but use soft updates on the other partitions. Between background fsck and journaling, system recovery after an unexpected power outage is fast and painless.

We’ll talk more about journaling and gjournal in Chapter 18.

Write Caching

FFS works best with SCSI and SAS drives due to the robustness of the SCSI architecture. FFS also works as well as the ATA architecture allows, with one critical exception: Many modern IDE drives support write caching.

Write caching IDE drives have a small onboard chip. This chip records data that needs to be written to the drive. This can be tricky for soft updates and for journaling, because these technologies expect honest hard drives— when the hard drive reports the data is written to disk, the soft updates mechanism expects the data to actually be on that platter. But IDE write caching reports success as soon as the data is stored in the drive’s cache, not when it has been written to disk. It might be a second or more until that data is actually safely stored.

While this doesn’t pose a big risk if it happens occasionally, write caching occurs continuously on a server. Therefore, if you care about your data, disable write caching by adding the following to /boot/loader.conf:

hw.ata.wc=0

Disabling write caching slows the IDE drive, but eliminates the risk. I use write caching on desktop and laptop systems, where data is not being continuously written to the disk, but on servers it’s a bad idea to leave caching on. You can either tell your management that the ATA-based server is throttled and you need more hardware, or you can tell them that you’re missing data because you overstressed the hardware. Personally, I prefer the former.

Snapshots

FFS with soft updates can take an image of a disk at a moment in time, or a snapshot. You’ll find these snapshots in the .snapshot directory in the root of each partition.

While you don’t perform system administration on snapshots, various tools take advantage of snapshots. For example, dump(8) backs up a snapshot of each filesystem rather than the live filesystem so that you have an internally consistent backup. Background fsck (explained later in this chapter) uses snapshots to do its work. You can mount a snapshot and get a picture of your filesystem at a particular instant. While this is interesting, most system administrators don’t find it terribly useful. Still, you’ll see references to snapshots throughout working with FreeBSD.

Dirty Disks

No, disks don’t get muddy with use (although dust on a platter will quickly damage it, and adding water won’t help). A dirty FFS partition is one that’s in a kind of limbo; the operating system has asked for information to be written to the disk, but the data is not yet completely written out. Part of the data block might have been written, the inode might have been edited but the data not written out, or any combination of the two. If the power goes out while your disk is dirty, the system reboots with unclean disks.

FreeBSD refuses to mount unclean disks read-write; you can write them read-only, but that’s not suitable for normal operation. You must clean your disk.

fsck(8)
FreeBSD includes a filesystem integrity checking tool, fsck(8). When a rebooting system finds a dirty disk, it automatically checks the filesystem and tries to clean everything. You have already lost any data not written to disk, but fsck(8) verifies that every file is attached to the proper inodes and in the correct directory. If successful, everything is right where you left it—except for that unwritten data, of course!

Failed Automatic fscks Runs
Occasionally this automated fsck-on-reboot fails to work. When you check the console, you’ll be looking at a single-user mode prompt and a request to run fsck(8) manually. At this point, you have a simple choice: run fsck or not. If you enter fsck at the command prompt, fsck(8) verifies every block and inode on the disk. It finds any blocks that have become disassociated from their inodes and guesses how they fit together and how they should be attached. fsck(8) might not be able to identify which directory these files belong in, however.

fsck asks if you want to perform these reattachments. If you answer n, it deletes the damaged files. If you answer y, it adds the lost file to a lost+found directory in the root of the partition, with a number as a filename. For example, the lost+found directory on your /usr partition is /usr/lost+found. If there are only a few files, you can identify them manually; if you have many files and are looking for particular ones, tools such as file(1) and grep(1) can help you identify them by content.

Turning Off the fsck Prompt
If your server was in the middle of a very busy operation when it became dirty, you could end up with many disassociated files. Instead of spending an hour at the console typing y over and over again to tell fsck to reassemble these files, type fsck -y at the single-user prompt. This makes fsck(8) believe that you’re answering yes to every question.

DANGER!

Running fsck -y is not guaranteed safe. At times, when running experimental filesystems on -current or when doing other daft things, I’ve had the entire contents of a partition migrate to /usr/ost+found and /var/lost+found thanks to fsck -y. Recovery becomes difficult at that point. Having said that, in a production system running FreeBSD-stable with a standard UFS fiesystem, ’ve never had a problem.

You can set your system to automatically try fsck -y on boot. I don’t recommend this, however, because if there’s the faintest chance my filesystem will wind up in digital nirvana I want to know about it. I want to type the offending command myself and feel the trepidation of watching fsck(8) churn my hard drives. Besides, it’s always unpleasant to discover that your system is trashed without having the faintest clue of how it got that way. If you’re braver than I, you can set fsck_y_enable="YES" in rc.conf.

Avoiding fsck -y
What options do you have if you don’t want to use fsck -y? Well, fsdb(8) and clri(8) allow you to debug the filesystem and redirect files to their proper locations. You can restore files to their correct directories and names. This is difficult,² however, and is recommended only for Secret Ninja Filesystem Masters.

Background fsck
Background fsck gives FFS some of the benefits of a journaled filesystem without using all the disk required by journaling. When FreeBSD sees that a background fsck is in process after a reboot, it mounts the dirty disk readwrite. fsck(8) runs in the background while the server is running, identifying loose bits of files and tidying them up behind the scenes.

A background fsck actually has two major stages. When FreeBSD finds dirty disks during the initial boot process, it runs a preliminary fsck(8) assessment of the disks. fsck(8) decides if the damage can be repaired while the system is running, or if a full single-user mode fsck run is required. Most frequently, fsck thinks it can proceed and lets the system boot. After the system reaches single-user mode the background fsck runs at a low priority, checking the partitions one by one. The results of the fsck process appear in /var/log/messages.

You can expect performance of any applications requiring disk activity to be lousy during a background fsck. fsck(8) occupies a large portion of the disk’s possible activity. While your system might be slow, it will at least be up.

You must check /var/log/messages for errors after a background fsck. The preliminary fsck assessment can make an error, and perhaps a full singleuser mode’s fsck on a partition really is required. If you find such a message, schedule downtime within a few hours to correct the problem. While inconvenient, having the system down for a scheduled period is better than the unscheduled downtime caused by a power outage and the resulting singleuser mode’s fsck -y.

Forcing Read-Write Mounts on Dirty Disks

If you really want to force FreeBSD to mount a dirty disk read-write without using a background fsck, you can. You will not like the results. At all. But, as it’s described in mount(8), some reader will think it’s a good idea unless they know why. Use the -w (read-write) and -f (force) flags to mount(8).

Mounting a dirty partition read-write corrupts data. Note the absence of words like might and could from that sentence. Also note the absence of words like recoverable. Mounting a dirty filesystem may panic your computer. It might destroy all remaining data on the partition or even shred the underlying filesystem. Forcing a read-write mount of a dirty filesystem is bad juju. Don’t do it.

FFS Syncer at Shutdown

When you shut down your FreeBSD system the kernel synchronizes all its data to the hard drive, marks the disks clean, and shuts down. This is done by a kernel process called the syncer. During a system shutdown, the syncer reports on its progress in synchronizing the hard drive.

You’ll see odd things from the syncer during shutdown. The syncer doesn’t actually go down the list of inodes and blocks that need updating on the hard drive; it walks the list of vnodes that need synchronizing. Thanks to soft updates, writing one vnode to disk can generate another dirty vnode that needs updating. You can see the number of buffers being written to disk rapidly drop from a high value to a low value, and perhaps bounce between zero and a low number once or twice as the system really synchronizes the hard drive.

THE REAL DETAILS ON FFS

If you really want to know more about FFS, you can downoad a large diagram of the kernel internals of FFS at http://phk.freebsd.dk/misc/ufs.pdf. You’ll need a large engineering or architectural printer, or 18 sheets of regular paper and a lot of clear tape.

Background fsck, fsck -y, Foreground fsck, Oy Vey!

All these different fsck(8) problems and situations can occur, but when does FreeBSD use each command? FreeBSD uses the following conditions to decide when and how to fsck(8) on a filesystem:

If the filesystem is clean, it is mounted without fsck(8).
If a filesystem without soft updates is dirty at boot, FreeBSD runs fsck on it. If the filesystem damage is severe, FreeBSD stops the fsck and requests your intervention. You can either run fsck -y or manually check each reconnection.
If a filesystem with soft updates is dirty at boot, FreeBSD performs a very basic fsck(8) check. If the damage is mild, FreeBSD uses a background fsck(8) in multi-user mode. If the damage is severe, FreeBSD interrupts the boot and requests your intervention with either fsck -y or approval or rejection of each filesystem problem.
If a journaled filesystem is dirty at boot, FreeBSD recovers the data from the journal and continues the boot. A journaled filesystem rarely needs fsck(8).

USING FOREIGN FILESYSTEMS

For our purposes, any partition or disk that isn’t FFS is a foreign filesystem. FreeBSD includes extensive support for foreign filesystems, with the caveat that only those functions supported by the filesystem work. Microsoft’s FAT32 doesn’t support filesystem permissions, for example, and Linux filesystems don’t support BSD-style file flags.

Each foreign filesystem needs support in the FreeBSD kernel. To make your life a little easier, mount(8) automatically loads the proper kernel modules on demand.

To mount any foreign filesystem, you need the same information needed to mount an FFS filesystem: a device name and a mount point. You’ll also need the type of filesystem, although you might figure that out by trial and error. For example, FreeBSD provides a /cdrom mount point for CDs. The first IDE CD on your system is /dev/acd0. CDs use the ISO 9660 filesystem, and FreeBSD mounts them with mount -t cd9660(8). Here we mount our CD on /cdrom:

# mount -t cd9660 /dev/acd0 /cdrom

You can now go to the /cdrom directory and view the contents. Simple enough, eh?

If you try to mount a disk using the wrong mount command for its filesystem, you’ll get an error. For example, any floppy disk in my house has either a FAT32 or an FFS filesystem on it; /dev/fd0 is the proper device node for floppy disks, and /media is their standard mount point.

# mount /dev/fd0 /media 
mount: /dev/fd0 on /media: incorrect super block

This floppy has a FAT32 filesystem. Had I tried mount -t msdosfs first, it would have worked.

You can unmount any filesystem with umount(8):

# umount /cdrom

umount(8) doesn’t care about the filesystem type. It just disconnects the disk partition.

Supported Foreign Filesystems

Here are some of the most commonly used foreign filesystems, along with a brief description of each and the appropriate mount command.

FAT (MS-DOS)
FreeBSD includes extensive support for FAT, the DOS/Windows 9x File Allocation Table filesystem, commonly used on removable media and some dual-boot systems. This support covers the FAT12, FAT16, and FAT32 varieties. You can format a floppy disk with an FFS filesystem, however, so do not blindly assume that all floppy disks are FAT-formatted. As the most common use for a floppy these days is transferring files between machines, however, most are FAT32. The mount type is msdosfs (mount -t msdosfs).

If you handle a lot of FAT32 disks, investigate /usr/ports/tools/mtools, a collection of programs for working with FAT filesystems that offer greater flexibility than the default FreeBSD tools.

ISO 9660
ISO 9660 is the standard CD filesystem. FreeBSD supports reading CDs and writing them as well if you have a CD burner. Just about every CD you encounter is formatted with ISO 9660. The mount command is mount -t cd9660.

cdrtools, in /usr/ports/sysutils/cdrtools, contains many helpful tools for working with CD images, including tools that build an ISO image from files on disk.

UDF
UDF, or Universal Data Format, is a replacement for ISO 9660. You’ll find UDF on some DVDs and on flash/USB devices larger than the 32GB supported under FAT32. As the capacity of removable media increases, you’ll see more and more UDF filesystems. The mount command is mount -t udf.

NTFS
The Windows NT/2000/XP filesystem, NTFS, is tightly integrated with Microsoft’s proprietary kernel. To write to an NTFS partition, you must have extensive knowledge of how the filesystem works. Since Microsoft does not make that information available, FreeBSD can safely mount NTFS partitions read-only but has limited read-write functionality. The mount command is mount -t ntfs.

I find NTFS mounts most useful when migrating from Windows systems to FreeBSD systems; just remove the hard drive from the old Windows machine, mount it in the FreeBSD machine, and copy your data from one to the other. NTFS support is also useful for dual-boot laptops.

As the NTFS filesystem has a closed specification and contains data encoded in a proprietary manner, FreeBSD’s NTFS read support is not guaranteed to work.

ext2fs and ext3fs
The standard Linux filesystems, ext2fs and ext3fs, support many of the same features as the FreeBSD filesystem and can be safely written to and read from without any problems. Like the NTFS mounts, mounting Linux filesystems is most useful for disaster recovery or dual-boot systems. Despite the name, mount -t ext2fs supports mounting both ext2fs and ext3fs.

Linux filesystem users might find the tools in /usr/ports/sysutils/e2fsprogs useful. They let you fsck(8) and assess Linux filesystems, among other things.

ReiserFS
ReiserFS is a filesystem with a small percentage of devotees amidst Linux users. FreeBSD supports read-only ReiserFS partitions. Support for mounting ReiserFS is implemented directly in mount(8); just run mount -t reiserfs partition mountpoint.

XFS
FreeBSD supports reading from SGI’s XFS partitions, but writing to XFS is available on an experimental basis as of this writing. XFS is the oldest journaling filesystem in existence and has a well-debugged codebase. XFS is licensed under the GPL, however, which makes it a poor candidate for inclusion in the FreeBSD base system. If you’re interested in journaling, please check out gjournal in Chapter 18.

Programs for formatting, mounting, and managing XFS partitions can be found in /usr/ports/sysutils/xfsprogs.

ZFS
As of 7.0, FreeBSD includes experimental support for ZFS, ported from OpenSolaris. While the installer doesn’t support ZFS, if you need the advanced ZFS features you can use them. ZFS’s license is not suitable for making it the primary FreeBSD filesystem, but its high-end features can be very useful for certain applications on multiterabyte filesystems and on 64-bit systems. ZFS on 32-bit systems suffers from memory problems, but ZFS has a good reputation on 64-bit systems.

Permissions and Foreign Filesystems

The method used to mount a filesystem, and the person who mounts it, control the permissions of the mounted filesystem. For example, ext3fs and XFS store permissions in the filesystem and map them to UIDs. Since their permissions behave much like FFS, and all the permissions information needed is available within the filesystem and the kernel, FreeBSD respects the permissions on these filesystem.

NTFS has its own permission system. Since that system bears only a coincidental resemblance to that used by Unix-like systems, permissions are discarded when a NTFS partition is mounted on a FreeBSD system, and it’s treated much like a CD or a floppy disk.

By default, only root can mount filesystems, and root owns all non-Unix filesystems. If that’s not your preference, you can use the -u and -g flags to set the user ID and group ID of the owner when you’re mounting a FAT32, NTFS, or ISO 9660 filesystem. For example, if you’re mounting a FAT32 USB device for the user cstrzelc and want her to be able to edit the contents, use this command:

# mount -t msdosfs -u cstrzelc -g cstrzelc /dev/da0 /mnt

The user cstrzelc now owns the files on the device.

You might get sick of mounting media for your users, especially in a facility with dozens of machines. To let a user mount a filesystem, set the sysctl vfs.usermount to 1. The user can then mount any filesystem she wants on any mount point she owns. While cstrzelc couldn’t mount the removable device on /mnt, she could mount it on /home/cstrzelc/mnt.

REMOVABLE MEDIA FILESYSTEM

Removable media has boomed in the last few years. While once we only had to worry about floppy disks, we now have CDs and USB devices. You must be able to manage any removable media that might wander in through the door of your data center. We’ll discuss dealing with filesystems on floppy disks, USB devices, and CDs.

I recommend not plugging removable media willy-nilly into your production servers, for security reasons if nothing else. Who knows what’s actually on that vendor’s USB device? I prefer to mount those devices on my workstation, examine the contents, and then copy the desired data over to the FreeBSD machine. Removable media is just too easy for certain applications, however, and of course the rules change when it’s my personal USB device.

Formatting FAT32 Media

Both floppy disks and USB media use the FAT32 filesystem. USB media uses the FAT32 filesystem, but usually comes preformatted. As USB media has a limited number of reads and writes, do not reformat it capriciously. That leaves floppies, which frequently need reformatting if used heavily. What most Windows users think of as "formatting a floppy" is actually a multistage process that includes formatting the disk, giving it a disk label, and creating a filesystem. You must perform all of these operations to use a floppy in FreeBSD.

NONSTANDARD FLOPPIES

We'll assume that you have a standard 1.44MB foppy disk, which has been the standard on x86 hardware for almost two decades. If you have a disk drive of 800KB or another uncommon size, you’ll have to modify this process somewhat, but the general steps are the same.

Low-Level Formatting
First, perform a low-level format with fdformat(1). This program only requires two arguments: the floppy’s size and the device name.

# fdformat -f 1440 /dev/fd0 
Format 1440K floppy '/dev/fd0.1440'? (y/n): y

When you type y, fdformat(1) runs a low-level format to prepare the disk to receive a filesystem. Low-level formatting is the slowest part of making a floppy usable. Windows performs this sort of formatting when you request a complete format.

Creating an FFS Filesystem
After the low-level format, if you want to use FFS on your floppy, label the disk with disklabel(8). This writes basic identification information to the floppy, sets partition information, and can even mark a disk as bootable. Marking a disk as bootable doesn’t actually put any programs on the disk; it simply puts a marker on the disk so the hardware BIOS identifies this disk as bootable. If you need an actual FreeBSD boot floppy, just copy the provided disk image from the installation media. Here, we’ll install a plain disklabel without any special characteristics:

# disklabel -r -w /dev/fd0 fd1440

The -r option in this example tells disklabel to access the raw disk, because there is no filesystem on it yet. The -w option says to write to the disk. We’re writing to /dev/fd0 and installing a standard 1.44MB floppy disk label. You can find a full list of floppy disk labels in /etc/disktab, as well as labels for many other types of drives, as discussed in Chapter 10.

Finally, newfs(8) the disk to create a filesystem.

# newfs /dev/fd0

You’ll see a few lines of newfs output and then get a command prompt back.

Note that using FFS on a floppy wastes space and does not provide the protection many people expect it would. While permission information is stored on the floppy, the system owner can override those privileges easily. Also, remember that FFS reserves 8 percent of disk space for its own overhead and bookkeeping. Do you really need a 1.32MB floppy? FFS is nifty, but FAT32 is a better choice for floppy disks.

Creating a FAT32 Filesystem
To swap data between a wide range of hardware, use the FAT32 filesystem on your floppy. While you still need to low-level format the floppy as discussed earlier, you don’t need to disklabel it. Just use newfs_msdos(8):

# newfs_msdos /dev/fd0

You’ll get a couple lines of output, and your floppy is done.

Using Removable Media

Handling removable media is just like working with fixed media such as hard drives. You must know the filesystem on the device, the device node where the device appears, and assign a mount point.

CDs use the ISO 9660 filesystem, while DVDs use either a UDF or a combination of ISO 9660 and UDF. USB devices and floppy disks are usually FAT32. Very new USB devices might be UDF. I expect UDF to become more common, especially as flash devices become larger.

The device node varies with the device type. IDE CDs are /dev/acd0, while SCSI CDs appear at /dev/cd0. Floppy disks are at /dev/fd0. USB devices appear as the next available unit of /dev/da. When you insert a USB device, a message giving the device node and type appears on the console and in /var/log/messages.

Finally, you need a mount point. By default, FreeBSD includes a /cdrom mount point for CD and DVD media. You’ll also find a /media mount point for general removable media mounts. You can create additional mount points as you like—they’re just directories. For miscellaneous short-term mounts, FreeBSD offers /mnt.

So, to mount your FAT32 USB device /dev/da0 on /media, run:

# mount -t msdosfs /dev/da0 /media

Occasionally you’ll find a USB device that has an actual slice table on it, and those devices will insist you mount /dev/da0s1 rather than /dev/da0. This depends on how the device is formatted, not on anything in FreeBSD.

One annoyance with CD drives is that SCSI CD and ATA CD drives offer different interfaces to software. Much software is written to only use the SCSI interface, as SCSI is generally considered more reliable. If you encounter such a piece of software, check out atapicam(4) kernel module which provides a SCSI emulation layer to your ATA CD devices.

Ejecting Removable Media

To disconnect removable media from your FreeBSD system, you must unmount the filesystem. Your CD tray won’t open until you unmount the CD, and the floppy drive won’t eject your disk. You can probably forcibly remove a USB dongle, but doing so while the filesystem is mounted panics the server and might damage data on the device. Use umount(8) just as you would for any other filesystem:

# umount /cdrom

Removable Media and /etc/fstab

You can update /etc/fstab with entries for removable media to make system maintenance a little easier. If a removable filesystem has an entry in /etc/fstab, you can drop both the filesystem and the device name when mounting it. This means that you don’t have to remember the exact device name or filesystem to mount the device. You probably already have an /etc/fstab’s entry for your CD device.

/dev/acd0      /cdrom      cd9660   ro,noauto      0      0

While I’m sure you’ve already memorized the meaning of every column in /etc/fstab, we’ll remind you that entry means "mount /dev/acd0 on /cdrom, using the ISO 9660 filesystem, read-only, and do not mount it automatically at boot." Using this as a template, make similar entries for USB devices and floppy disks.

FreeBSD doesn’t provide these by default, but I find having them to be much easier on systems where I use removable media regularly. Confirm that your next available da device is /dev/da0

, as trying to mount a hard drive that’s already mounted won’t work. When listing removable media in /etc/fstab, be sure to include the noauto

. flag. Otherwise, whenever you don’t have the removable media in place, your boot will stop in single-user mode because a filesystem is missing.

OTHER FREEBSD FILESYSTEMS

In addition to FFS and non-FreeBSD filesystems, FreeBSD supports several special-purpose filesystems. Some of these are interesting but not generally useful, such as mount_umapfs(8), while others are very useful or even required in certain circumstances. We’ll talk about memory filesystems, a popular optimization for certain environments; building filesystems on files; as well as the procfs and fdescfs filesystems occasionally required by software packages.

Memory Filesystems

In addition to using disks for partitions, FreeBSD lets you create partitions from files, from pure RAM, and from a combination of the two. One of the most popular uses of this is for memory filesystems, or memory disks. Reading and writing files to and from memory is much faster than accessing files on disk, which makes a memory-backed filesystem a huge optimization for certain applications. As with everything else in memory, however, you lose the contents of your memory disk at system shutdown.

Memory Disk /tmp
The most common place a memory filesystem is used is for /tmp. This is so common that FreeBSD includes specific rc.conf support for it. Look for the following rc.conf variables:

By setting tmpmfs

to YES, you’re telling FreeBSD to automatically create a memory-based /tmp filesystem at boot. Specify the size of your new /tmp with the tmpsize

variable. We’ll discuss the flags

a little later in this section. If this is all you want to use a memory filesystem for, you’re done.

To create and use special memory devices with mdmfs(8), read on.

Memory Disk Types
Memory disks come in three types: malloc-backed, swap-backed, and vnodebacked.

Malloc-backed disks are pure memory. Even if your system runs short on memory, FreeBSD won’t swap out the malloc-backed disk. Using a large malloc-backed disk is a great way to make your system run out of free memory and panic. This is most useful for embedded devices with no swap, as we’ll see in Chapter 20.

Swap-backed disks are mostly memory, but they also access the system swap partition. If the system runs out of memory, it moves the least recently used parts of memory to swap as discussed in Chapter 19. Swap-backed disks are the safest way to use a memory filesystem.

Vnode-backed disks are files on disk. While you can use a file as backing for your memory disk, this is really only useful for filesystem developers who want to perform tests or for mounting a disk image.

Your application dictates the type of memory disk you need. If your system has no swap space and a read-only filesystem, a malloc-backed disk is your only choice. If you’re running a workstation or a server and want a piece of fast filesystem for scratch space, you want a swap-backed disk. You only need a vnode-backed memory disk to mount a disk image.

Once you know what you want to do, use mdmfs(8) to perform the action.

Creating and Mounting Memory Disks
The mdmfs(8) utility is a handy front end for several programs such as mdconfig(8) and newfs(8). It handles the drudgery of configuring devices and creating filesystems on those devices, and makes creating memory disks as easy as possible. You only need to know the size of the disk you want to use, the type of the memory disk, and the mount point.

Swap-backed memory disks are the default. Just tell mdmfs(8) the size of the disk and the mount point. Here, we create an 8MB swap-backed memory disk on /home/mwlucas/test:

# mdmfs -s 8m md /home/mwlucas/test

The -s flag gives the size of the disk. If you run mount(8) without any arguments, you’ll see that you now have the memory disk device /dev/md0 mounted on that directory.

To create and mount a malloc-backed disk, add the -M flag.

To mount a vnode-backed memory disk, use the -F flag and the path to the image file.

 mdmfs -F diskimage.file md /mnt

The md entry we’ve been using all along here means, "I don’t care what device name I get, just give me the next free one." You can also specify a particular device name if you like. Here, I used /dev/md9 as the memory disk device:

 mdmfs -F diskimage.file md9 /mnt

Memory Disk Headaches
Memory disks sound too good to be true for high-performance environments. They do have constraints that you must understand before you scurry around and implement them everywhere.

The big issue is that system shutdown erases memory disks. While this might not seem like a problem, I’ve been surprised more than once by losing a file on a filesystem I had forgotten was a memory disk.

Also, malloc-backed memory disks never release memory. When you write a file to a memory disk and then erase the file, the file still takes up memory. With a swap-backed memory disk FreeBSD eventually writes that file to swap as memory pressure rises. A memory disk on a long-running system will eventually exhaust your system’s RAM.

The one way you can free this used memory is to unmount the memory disk, destroy the disk device, and re-create the memory disk. I find that performing this task on a monthly basis is more than sufficient, even on a busy server.

A couple months before release, FreeBSD 7.0 added a tmpfs(5) memory filesystem that is supposed to release memory back to the system. It’s brand new to FreeBSD, however, and considered an experimental feature. If you’re reading this a few releases into the future I’d recommend you check out tmpfs(5), but if you’re installing 7.0 or 7.1, I’d let someone else discover the bugs for you.

Memory Disk Shutdown
To remove a memory disk you must unmount the partition and destroy the disk device. Destroying the disk device frees the memory used by the device, which is useful when your system is heavily loaded. To find the disk device, run mount(8) and find your memory disk partition. Somewhere in the output, you’ll find a line like this:

/dev/md41 on /mnt (ufs, local, soft-updates)

Here, we see memory disk /dev/md41 mounted on /mnt. Let’s unmount it and destroy it.

Unmounting with umount

is done exactly as with other filesystems.

The mdconfig(8) call is a new one, however. Use mdconfig(8) to directly manage memory devices. The -d

flag means destroy, and the -u

gives a device number. The above destroys the device /dev/md41, or the md device number 41. The memory used by this device is now freed for other uses.

Memory Disks and /etc/fstab
If you list memory disks in /etc/fstab, FreeBSD automatically creates them at boot time. These entries look more complicated than the other entries, but aren’t too bad if you understand the mdmfs(8) commands we’ve been using so far. To refresh your memory, here’s the top of /etc/fstab and a single standard filesystem:

# Device      Mountpoint   FStype   Options   Dump   Pass# 
/dev/ad4s2a   /            ufs      rw         1     1

We’re allowed to use the word md as a device name to indicate a memory disk. We can choose the mountpoint just as we would for any other device, and the filesystem type is mfs. Under Options, list rw (for read-write) and the command-line options used to create this device. To create our 8MB filesystem mounted at /home/mwlucas/test, use the following /etc/fstab entry:

md    /home/mwlucas/test    mfs    rw,-s 8m    0    0

Looks easy, doesn’t it? The only problem is that the long line messes up your nice and even /etc/fstab’s appearance. Well, they’re not the only things that make this file ugly, as we’ll soon see.

This discussion is even less productive than the "Emacs versus vi" argument. And I bet you thought no such argument could exist!

In the first edition of this book, I said using fsdb(8) and clri(8) was like climbing Mount Everest in sandals and shorts. Since writing that, I’ve tried them more than once and discovered that I was wrong. You don’t get the shorts.

Page: 1, 2

ADS BY GOOGLE