on filesystems that shouldn't have them cannot hurt. In most cases, the only partition that should have device nodes is root (/).

If you've mounted a hard drive native to another UNIX, be sure to mount it as nodev. Accidentally accessing a device node native to another operating system will almost certainly crash or damage your system!

You cannot use jails on a partition mounted as nodev; remember, jails have their own minimal set of device nodes.

What's Mounted Now?

How do you determine what you have mounted on your system? Well, you can start by running mount(8) without any options. This gives you a list of all mounted filesystems:

...............................................................................................

# mount

/dev/ad0s1a on / (ufs, local, soft−updates)

/dev/ad0s1f on /test1 (ufs, local, soft−updates) /dev/ad0s1g on /test2 (ufs, local, soft−updates) /dev/ad0s1h on /usr (ufs, local, soft−updates)

/dev/ad0s1e on /var (ufs, local, soft−updates) procfs on /proc (procfs, local)

#

...............................................................................................

Here we see that our filesystems are almost all standard FFS partitions that are all mounted locally with soft updates enabled. (We'll look at soft updates later in the chapter.) If you're using features such as SMB (see Chapter 21) or the Network File System to mount partitions, they'll show up here. This is another quick way to get the device names for each of your partitions.

You can also do more interesting tasks with mount, as we'll see later. First, though, let's look at what can go wrong with your partitions.

Dirty Disks

No, disks don't get muddy through use (although dust on a platter will quickly damage it, and adding water certainly won't help). A dirty disk partition is one that's in a kind of limbo: The operating system has asked for information to be written to it, but the data is yet to be written completely. (Part of the data block may 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 you're writing to disk, the system will come back up with "unclean disks."

Fsck

FreeBSD includes a very powerful filesystem checking tool, fsck(8). When a rebooting system finds a dirty disk, it automatically checks the disk and tries to clean everything up. You will lose any data

373

that was not written to the disk, but fsck will do its best to clean what you have. If successful, everything should be right where you left it–except for that unwritten data.

Failed Automatic Fscks

Occasionally the reboot will fail, and you'll be left staring at a single−user prompt asking you to run fsck manually. At this point, you have a few choices. If you enter fsck, fsck will check every block and inode on the disk. It will probably find any number of blocks that have become disassociated from their inodes, and will make a good guess as to how they fit together and how they should be attached. It won't be able to tell which directory these files belong in, however.

Fsck will ask if you want to perform this reattachment. If you answer "n", it deletes the damaged files. If you answer "y", it will add the disassociated file to a lost−and−found directory (such as /usr/lost+found) on the partition on which they were found, with a number as a filename. Use grep in that directory to search your missing files by content or, if there are only a few files, have a look at them with a tool such as more(1) to identify them.

Turning Off the Fsck Prompt

If your disk was in the middle of a very busy operation when it became dirty, you could end up with many, many disassociated files. Rather than spend an hour typing "y" over and over again to tell fsck to attempt to place these files, run fsck −y at the single−user prompt. This tells fsck that you're answering "y" to every question, and it's much easier than sitting there typing "y" repeatedly.

Note At times when running experimental filesystems on −current, I've had the entire contents of a disk migrate to /usr/lost+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, I've never had a problem with an automatic disk repair.

You can set your system to automatically try a fsck −y on boot. I don't recommend this, though, because if there's the faintest chance of my filesystem winding up in digital heaven, I want to know about it. I want to type the offending command myself and feel the trepidation of watching the fsck run. Besides, it's always unpleasant to find that your system is trashed, without having the faintest clue of what happened. But if you must try it, set the following /etc/rc.conf option:

...............................................................................................

fsck_y_enable="YES"

...............................................................................................

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, though,[3] and is recommended only for Secret Ninja Filesystem Masters.

[3]I'm using "difficult" much like this: "Climbing Mount Everest wearing sandals and shorts is difficult."

374