--- filesys.mm	2001/12/26 07:09:54	4.1
+++ filesys.mm	2003/04/02 06:43:57
@@ -1,52 +1,31 @@
-\" This file is in -*- nroff-fill -*- mode
-.\" STATUS: draft fourth edition
-.\" $Id: filesys.mm,v 4.1 2001/12/26 07:09:54 grog Exp $
+.\" This file is in -*- nroff-fill -*- mode
+.\" STATUS: 4th edition
+.\" $Id: filesys.mm,v 4.17 2003/04/02 06:43:57 grog Exp $
 .\"
-.Chapter \*[nchfilesys] "File systems"
-XXX soft updates
+.Chapter \*[nchfilesys] "File systems and devices"
 .X "file system"
-One of the most far-reaching concepts of the UNIX operating system was its
-\fIfile system\fP, the way in which it stores data.  Although most other
-operating systems have copied it since then, including Microsoft's platforms,
-none have come close to the elegance with which it is implemented.  In this
-chapter, we'll look at what that means to you.
-.H2 "File systems"
-.X "file systems"
-.X "directories"
 .X "files"
 .X "directories"
-Both UNIX and Microsoft environments store disk data in \fIfiles\fP, which in
-turn are placed in \fIdirectories\fP.  A file may be a directory: that is, it
-may contain other files.
-.H4 "File names"
-.X "file names"
-.X "file name extension"
-The differences between UNIX and Microsoft start with \fIfile names\fP.
-Traditional Microsoft file names are rigid: a file name consists of eight
-characters, possibly followed by a period and another three characters (the
-so-called \fIfile name extension\fP\|).  There are significant restrictions on
-which characters may be used to form a file name, and upper and lower case
-letters have the same meaning (internally, Microsoft converts the names to UPPER
-CASE).  Directory members are selected with a backslash (\fB\e\fP), which
-conflicts with other meanings in the C programming language\(emsee page
-\*[slash] for more details.
-.P
-By comparison, UNIX file names are much more flexible.  They may contain any
-character except a slash (\f(CW/\fP), which is used to indicate a directory
-component, and they may be up to 255 characters long.
-.Aside
-In some older versions of UNIX and early versions of Linux, file names were
-restricted to 14 characters.
-.End-aside
-Upper and lower case letters have different meanings, so in UNIX the names
-\fIfoo\fP, \fIFOO\fP, and \fIFoo\fP\| are three different names.
-.H3 "Permissions"
+One of the most revolutionary concepts of the UNIX operating system was its
+\fIfile system\fP, the way in which it stores data.  Although most other
+operating systems have copied it since then, including Microsoft's platforms,
+none have come close to the elegance with which it is implemented.  Many aspects
+of the file system are not immediately obvious, some of them not even to
+seasoned UNIX users.
+.P
+We've already looked at file naming conventions on page
+.Sref \*[file-names] .
+In the next section, we'll look at the file system access, structure and
+hierarchy, and on page
+.Sref \*[devices] \&
+we'll look at how the file system treats hardware devices as files.
+.H2 "File permissions"
 .X "file permissions"
 .X "permissions, file"
 .Pn permissions
-Since a UNIX system may potentially be used by many people, it includes a method
+A UNIX system may potentially be used by many people, so UNIX includes a method
 of protecting data from access by unauthorized persons.  Every file has three
-items of information associated with it which describes who can access it in
+items of information associated with it that describe who can access it in
 what manner:
 .Ls B
 .LI
@@ -54,30 +33,30 @@
 The \fIfile owner\fP, the user ID of the person who owns the file.
 .LI
 .X "file group"
-The \fIfile group\fP, the group ID of the group which ``owns'' the file.
+The \fIfile group\fP, the group ID of the group that ``owns'' the file.
 .LI
 A list of what the owner, the group and other people can do with the file.  The
 possible actions are reading, writing or executing.
 .Le
-For example, you might have a program which accesses private data, and you want
-to be sure that only you may execute it.  You do this by setting the permissions
-so that only the owner may execute it.  Or you might have a text document in
+.ne 2v
+For example, you might have a program that accesses private data, and you want
+to be sure that only you can execute it.  You do this by setting the permissions
+so that only the owner can execute it.  Or you might have a text document in
 development, and you want to be sure that you are the only person who can change
 it.  On the other hand, the people who work with you have a need to be able to
-refer to the document.  You set the permissions so that only the owner may write
-it, that the owner and group may read it, and, since it's not ready for
+refer to the document.  You set the permissions so that only the owner can write
+it, that the owner and group can read it, and, because it's not ready for
 publication yet, you don't allow anybody else to access it.
 .P
 Traditionally, the permissions are represented by three groups of \f(CWrwx\fP:
-\f(CWr\fP stands for \fIread\fP\| permission, \f(CWw\fP stands for \fIwrite\fP\|
-permission, and \f(CWx\fP stands for \fIexecute\fP\| permission.  The three
+\f(CWr\fP stands for \fIread\fP\/ permission, \f(CWw\fP stands for \fIwrite\fP\/
+permission, and \f(CWx\fP stands for \fIexecute\fP\/ permission.  The three
 groups represent the permissions for the owner, the group and others
 respectively.  If the permission is not granted, it is represented by a hyphen
 (\f(CW-\fP).
 .\" Hi, Jack :-)
 .nh
 Thus, the permissions for the program I discussed above would be
-.br
 \f(CWr-x------\fP (I can read and execute the program, and nobody else can do
 anything with it).  The permissions for the draft document would be
 \f(CWrw-r-----\fP (I can read and write, the group can read, and others can't
@@ -88,12 +67,12 @@
 Typical FreeBSD file access permissions are \f(CWrwxr-xr-x\fP for programs and
 \f(CWrw-r--r--\fP for other system files.  In some cases, however, you'll find
 that other permissions are \fIrequired\fP.  For example, the file
-\fI~/.rhosts\fP, which is used by some network programs for user validation, may
-contain the user's password in legible form.  To help ensure that other people
-don't read it, the network programs will refuse to read it unless its
-permissions are \f(CWrw-------\fP.  The vast majority of system problems in UNIX
-can be traced to incorrect permissions, so you should pay particular attention
-to them.
+.File ~/.rhosts ,
+which is used by some network programs for user validation, may contain the
+user's password in legible form.  To help ensure that other people don't read
+it, the network programs refuse to read it unless its permissions are
+\f(CWrw-------\fP.  The vast majority of system problems in UNIX can be traced
+to incorrect permissions, so you should pay particular attention to them.
 .P
 .X "permission, setuid"
 .X "permission, setgid"
@@ -103,30 +82,34 @@
 .X "set group"
 Apart from these access permissions, executables can also have two bits set to
 specify the access permissions of the process when it is run.  If the
-\fIsetuid\fP\| (\fIset user ID\fP\|) bit is set, the process will always run as
-if it had been started by its owner.  If the \fIsetgid\fP\| (\fIset group\fP\|
-ID) bit is set, it will run as if it had been started by its group.  This is
-frequently used to start system programs which need to access resources which
-the user may not access directly.  We'll see an example of this with the
-\fIps\fP\| command on page \*[ps-permissions].  \fIls\fP\| represents the
-\fIsetuid\fP\| bit by setting the third letter of the permissions string to
-\f(CWs\fP instead of \f(CWx\fP; similarly, it represents the \fIsetgid\fP\| bit
-by setting the sixth letter of the permissions string to \f(CWs\fP instead of
-\f(CWx\fP.
+\fIsetuid\fP\/ (\fIset user ID\fP\/) bit is set, the process always runs as if
+it had been started by its owner.  If the \fIsetgid\fP\/ (\fIset group ID\fP\/)
+bit is set, it runs as if it had been started by its group.  This is frequently
+used to start system programs that need to access resources that the user may
+not access directly.  We'll see an example of this with the
+.Command ps
+command on page
+.Sref \*[ps-permissions] .
+.Command ls
+represents the \fIsetuid\fP\/ bit by setting the third letter of the permissions
+string to \f(CWs\fP instead of \f(CWx\fP; similarly, it represents the
+\fIsetgid\fP\/ bit by setting the sixth letter of the permissions string to
+\f(CWs\fP instead of \f(CWx\fP.
 .P
 In addition to this access information, the permissions contain a character
-which describes what kind of file it represents.  The first letter may be a
+that describes what kind of file it represents.  The first letter may be a
 \f(CW-\fP (hyphen), which designates a regular file, the letter \f(CWd\fP for
 directory, or the letters \f(CWb\fP or \f(CWc\fP for a device node.  We'll look
-at device nodes in \*[chdisks], page
+at device nodes in Chapter
+.Sref "\*[nchdisks]" ,
+page
 .Sref \*[devices] .
-There are also a number of other letters which are less used.  See the man page
-\fIls(1)\fP\| for a full list.
+There are also a number of other letters that are less used.  See the man page
+\fIls(1)\fP\/ for a full list.
 .P
-.X "ls command"
-.X "command, ls"
-To list files and show the permissions, use the \fIls\fP\| command with the
-\f(CW-l\fP option:
+To list files and show the permissions, use the
+.Command ls
+command with the \f(CW-l\fP option:
 .Dx
 $ \f(CBls -l\fP
 total 2429
@@ -137,7 +120,7 @@
 -rw-rw-r--   1 grog     wheel         108 Dec  4 12:36 Makefile.bak
 -rw-rw-r--   1 grog     wheel         108 Dec  4 12:36 Makefile~
 -rw-rw-r--   1 grog     wheel           0 Dec  4 12:36 depend
--rw-rw-r--   1 root     wheel     1474560 Dec 14 17:03 deppert.floppy
+-rw-rw-r--   1 daemon   wheel     1474560 Dec 14 17:03 deppert.floppy
 -rwxr-xr-x   1 grog     wheel         100 Dec 19 15:24 doio
 -rwxrwxr-x   1 grog     wheel         204 Dec 19 15:25 doiovm
 -rwxrwxr-x   1 grog     wheel         204 Dec 19 15:16 doiovm~
@@ -149,36 +132,38 @@
 This format shows the following information:
 .Ls B
 .LI
-First, the permissions, which we've already looked at.
+First, the permissions, which we've already discussed.
 .LI
-.X "link count"
-Then, the \fIlink count\fP.  This is the number of hard links to the file.
-For a regular file, this is normally 1, but directories have at least 2.  We'll
-look at links on page \*[links].
+.X "link, count"
+Then, the \fIlink count\fP.  This is the number of hard links to the file.  For
+a regular file, this is normally 1, but directories have at least 2.  We look at
+links on page
+.Sref \*[links] .
 .LI
 .X "image, floppy"
 .X "floppy image"
-.X deppert
 .X "Lincke, Roland"
 Next come the names of the owner and the group, and the size of the file in
-bytes.  You'll notice that the file \fIdeppert.floppy\fP\| belongs to
-\f(CWroot\fP.  This was probably an accident, and it could lead to problems.
-Incidentally, looking at the name of the file and its size, it's fairly obvious
-that this is an \fIimage\fP\| of a 3\(12\f(CW"\fP floppy, that is to say, a
-literal copy of the complete floppy.
+bytes.  You'll notice that the file
+.File -n deppert.floppy
+belongs to \f(CWdaemon\fP.  This was probably an accident, and it could lead to
+problems.  Incidentally, looking at the name of the file and its size, it's
+fairly obvious that this is an \fIimage\fP\/ of a 3\(12\f(CW"\fP floppy, that is
+to say, a literal copy of the data on the complete floppy.
 .LI
 The date is normally the date that the file was last modified.  With the
-\f(CW-u\fP option to \fIls\fP, you can list the last time the file was
-accessed.
+\f(CW-u\fP option to
+.Command ls ,
+you can list the last time the file was accessed.
 .LI
 Finally comes the name of the file.  As you can see from this example, the names
 can be quite varied.
 .Le
 A couple of the permissions are of interest.  The directories all have the
-\f(CWx\fP (execute) permission bit set.  This is necessary in order to be able
-to access the files in the directory\(emthat's the way the term \fIexecute\fP\|
-is defined for a directory.  If I reset the execute permission, I can still list
-the names of the files, but I can't access them.
+\f(CWx\fP (execute) permission bit set.  This enables accessing (i.e.  opening)
+files in the directory\(emthat's the way the term \fIexecute\fP\/ is defined for
+a directory.  If I reset the execute permission, I can still list the names of
+the files, but I can't access them.
 .P
 I am the only person who can access the directory \fIMail\fP.  This is the
 normal permission for a mail directory.
@@ -187,47 +172,50 @@
 three programs to do this:
 .Ls B
 .LI
-.X "chown command"
-.X "command, chown"
 .X "deppert.floppy"
-To change the file owner, use \fIchown\fP.  For example, to change the ownership
-of the file \fIdeppert.floppy\fP, which in the list above belongs to
-\f(CWroot\fP, \f(CWroot\fP would enter:
+To change the file owner, use
+.Command chown .
+For example, to change the ownership of the file
+.File -n deppert.floppy ,
+which in the list above belongs to \f(CWdaemon\fP, \f(CWroot\fP would enter:
 .Dx
 # \f(CBchown grog deppert.floppy\fP
 .De
-Note that this operation must be performed by \f(CWroot\fP.
+Note that only \f(CWroot\fP may perform this operation.
 .LI
-.X "chgrp command"
-.X "command, chgrp"
-To change the file group, use \fIchgrp\fP, which works in the same way as
-\fIchown\fP.  To change the group ownership to \fIlemis\fP, you would enter:
+To change the file group, use
+.Command chgrp ,
+which works in the same way as
+.Command chown .
+To change the group ownership to \fIlemis\fP, you would enter:
 .Dx
 # \f(CBchgrp lemis deppert.floppy\fP
 .De
-\fIchown\fP\| can also change both the owner and the group.  Instead of the two
-previous examples, you could enter:
+.Command chown
+can also change both the owner and the group.  Instead of the two previous
+examples, you could enter:
 .Dx
 # \f(CBchown grog:lemis deppert.floppy\fP
 .De
-This would change the owner to \f(CWgrog\fP, as before, and also change the
-group to \f(CWlemis\fP.
+This changes the owner to \f(CWgrog\fP, as before, and also changes the group to
+\f(CWlemis\fP.
 .LI
-.X "chmod command"
-.X "command, chmod"
-To change the permissions, use the \fIchmod\fP\| program.  \fIchmod\fP\| has a
-number of different formats, but unfortunately the 9-character representation
-isn't one of them.  Read the man page \fIchmod(1)\fP\| for the full story, but
-you can achieve just about anything you want with one of the formats shown in
-table
-.Sref \*[chmod-codes] :
-.TB "chmod permission codes"
+To change the permissions, use the
+.Command chmod
+program.
+.Command chmod
+has a number of different formats, but unfortunately the nine-character
+representation isn't one of them.  Read the man page \fIchmod(1)\fP\/ for the
+full story, but you can achieve just about anything you want with one of the
+formats shown in table
+.Sref "\*[chmod-codes]" :
+.Table-heading "chmod permission codes"
 .Tn chmod-codes
 .TS H
-box, center,tab(#) ;
-lfCWp9 | lw63 .
-\s10\fRSpecification#Effect
-=
+tab(#) ;
+lfCWp9 | lw55 .
+\s10\fBSpecification#\fBEffect
+_
 .TH N
 go-w#T{
 Deny write permission to group and others
@@ -257,107 +245,116 @@
 T}
 .sp .4v
 .\" .TH N
+_
 .TE
 .Le
 .H4 "Permissions for new files"
 .Pn umask
-.X "umask"
-.X "User mask"
+.X "umask, command"
+.X "command, umask"
+.X "user, mask"
 None of this tells us what the permissions for new files are going to be.  The
 wrong choice could be disastrous.  For example, if files were automatically
 created with the permissions \f(CWrwxrwxrwx\fP, anybody could access them in any
 way.  On the other hand, creating them with \f(CWr--------\fP could result in a
 lot of work setting them to what you really want them to be.  UNIX solves this
-problem with a thing called \fIumask\fP\| (\fIUser mask\fP\|).  This is a
-default non-permission: it specifies which permission bits \fInot\fP\| to allow.
+problem with a thing called \fIumask\fP\/ (\fIUser mask\fP\/).  This is a
+default non-permission: it specifies which permission bits \fInot\fP\/ to allow.
 .P
 As if this weren't confusing enough, it's specified in the octal number system,
 in which the valid digits are \f(CW0\fP to \f(CW7\fP.  Each octal digit
 represents 3 bits.  By contrast, the more common hexadecimal system uses 16
 digits, \f(CW0\fP to \f(CW9\fP and \f(CWa\fP to \f(CWf\fP.  The original
-versions of UNIX ran on machines which used the octal number system, and since
-the permissions come in threes, it made sense to leave the \fIumask\fP\| value
+versions of UNIX ran on machines that used the octal number system, and since
+the permissions come in threes, it made sense to leave the \fIumask\fP\/ value
 in octal.
 .P
-An example: by default, you want to create files which anybody can read, but
+An example: by default, you want to create files that anybody can read, but
 only you can write.  You set the mask to \f(CW022\fP.  This corresponds to the
 binary bit pattern \f(CW000010010\fP.  
 .Aside
 The leading \f(CW0\fP is needed to specify that the number is in octal, not to
 make up three digits.  If you want to set the permissions so that by default
 nobody can read, you'd set it to \f(CW0222\fP.  Some shells automatically assume
-that the number is octal, so you \fImay\fP\| be able to omit the \f(CW0\fP, but
+that the number is octal, so you \fImay\fP\/ be able to omit the \f(CW0\fP, but
 it's not good practice.
 .End-aside
+.ne 5v
 The permissions are allowed where the corresponding bit is \f(CW0\fP:
 .Dx
-rwxrwxrwx		\fIPossible permissions\fP\|
-000010010		\fIumask\fP\|
-rwxr-xr-x		\fIresultant permissions\fP\|
+rwxrwxrwx               \fIPossible permissions\fP\/
+000010010               \fIumask\fP\/
+rwxr-xr-x               \fIresultant permissions\fP\/
 .De
 By default, files are created without the \f(CWx\fP bits, whereas directories
-are created with the allowed \f(CWx\fP bits, so with this \fIumask\fP\|, a file
+are created with the allowed \f(CWx\fP bits, so with this \fIumask\fP\/, a file
 would be created with the permissions \f(CWrw-r--r--\fP.
 .P
-\fIumask\fP\| is a shell command.  To set it, just enter:
+.Command umask
+is a shell command.  To set it, just enter:
 .Dx
 $ \f(CBumask 022\fP
 .De
 It's preferable to set this in your shell initialization file\(emsee page
-\*[bashrc] for further details.
+.Sref \*[bashrc] \&
+for further details.
 .P
 Beware of creating a too restrictive umask.  For example, you will get into a
-lot of trouble with a umask like \f(CW377\fP, which creates files which you can
-only read, and which nobody else can access.  If you disallow the \f(CWx\fP
-(executable) bit, you will not be able to access directories you create, and you
-won't be able to run programs you compile.
+lot of trouble with a umask like \f(CW377\fP, which creates files that you can
+only read, and that nobody else can access at all.  If you disallow the
+\f(CWx\fP (executable) bit, you will not be able to access directories you
+create, and you won't be able to run programs you compile.
 .H4 "Making a program executable"
 .Pn ps-permissions
 File permissions enable one problem that occurs so often that it's worth drawing
 attention to it.  Many operating systems require that an executable program have
-a special naming convention, such as \fICOMMAND.COM\fP\| or \fIFOO.BAT\fP, which
-in MS-DOS denotes a specific kind of binary executable and a script file,
-respectively.  In UNIX, you don't need a special suffix in order to be able to
-execute a program, but it must have the \f(CWx\fP bit set.  Sometimes this bit
-gets reset (turned off), for example if you copy it across the net with
-\fIftp\fP.  The result looks like this:
+a special naming convention, such as
+.File -n COMMAND.COM
+or
+.File -n FOO.BAT ,
+which in MS-DOS denotes a specific kind of binary executable and a script file,
+respectively.  In UNIX, executable programs don't need a special suffix, but
+they must have the \f(CWx\fP bit set.  Sometimes this bit gets reset (turned
+off), for example if you copy it across the Net with
+.Command ftp .
+The result looks like this:
 .Dx
 $ \f(CBps\fP
 bash: ps: Permission denied
 $ \f(CBls -l /bin/ps\fP
 -r--r--r--  1 bin  kmem  163840 May  6 06:02 /bin/ps
-$ \f(CBsu\fP							\fIyou need to be super user to set ps permission\fP\|
-Password:						\fIpassword doesn't echo\fP\|
-# \f(CBchmod +x /bin/ps\fP				\fImake it executable\fP\|
-# \f(CBps\fP							\fInow it works\fP\|
+$ \f(CBsu\fP                                             \fIyou need to be super user to set ps permission\fP\/
+Password:                                        \fIpassword doesn't echo\fP\/
+# \f(CBchmod +x /bin/ps\fP                               \fImake it executable\fP\/
+# \f(CBps\fP                                             \fInow it works\fP\/
   PID  TT  STAT      TIME COMMAND
   226  p2  S      0:00.56 su (bash)
   239  p2  R+     0:00.02 ps
   146  v1  Is+    0:00.06 /usr/libexec/getty Pc ttyv1
   147  v2  Is+    0:00.05 /usr/libexec/getty Pc ttyv2
-# \f(CB^D\fP							\fIexit su\fP\|
+# \f(CB^D\fP                                             \fIexit su\fP\/
 $ \f(CBps\fP
-ps: /dev/mem: Permission denied		\fIhey! it's stopped working\fP\|
+ps: /dev/mem: Permission denied                  \fIhey! it's stopped working\fP\/
 .De
-Huh?  It only worked under \fIsu\fP\|, and stopped working when I became a mere
-mortal again?  What's going on here?
+Huh?  It only worked under
+.Command su ,
+and stopped working when I became a mere mortal again?  What's going on here?
 .P
-.X "ps, command"
-.X "command, ps"
-.X "/dev/mem"
 .X "setuid"
-There's a second problem with programs like \fIps\fP\|: some versions need to be
-able to access special files, in this case \fI/dev/mem\fP, a special file which
-addresses the system memory.  In order to do this, we need to set the
-\fIsetgid\fP\| bit, \f(CWs\fP.  To do this, we become superuser again:
+There's a second problem with programs like
+.Command ps \/:
+some versions need to be able to access special files, in this case
+.Device mem ,
+a special file that addresses the system memory.  To do this, we need to set
+the \fIsetgid\fP\/ bit, \f(CWs\fP, which requires becoming superuser again:
 .Dx
-$ \f(CBsu\fP							\fIyou need to be super user to set ps permission\fP\|
-Password:						\fIpassword doesn't echo\fP\|
-# \f(CBchmod g+s /bin/ps\fP				\fIset the setgid bit\fP\|
-# \f(CBls -l /bin/ps\fP					\fIsee what it looks like\fP\|
+$ \f(CBsu\fP                                             \fIyou need to be super user to set ps permission\fP\/
+Password:                                        \fIpassword doesn't echo\fP\/
+# \f(CBchmod g+s /bin/ps\fP                              \fIset the setgid bit\fP\/
+# \f(CBls -l /bin/ps\fP                                  \fIsee what it looks like\fP\/
 -r-xr-sr-x  1 bin  kmem  163840 May  6 06:02 /bin/ps
-# \f(CB^D\fP							\fIexit su\fP\|
-$ \f(CBps\fP							\fInow it still works\fP\|
+# \f(CB^D\fP                                             \fIexit su\fP\/
+$ \f(CBps\fP                                             \fInow it still works\fP\/
   PID  TT  STAT      TIME COMMAND
   226  p2  S      0:00.56 su (bash)
   239  p2  R+     0:00.02 ps
@@ -365,470 +362,581 @@
   147  v2  Is+    0:00.05 /usr/libexec/getty Pc ttyv2
 .De
 In this example, the permissions in the final result really are the correct
-permissions for \fIps\fP.  It's impossible to go through the permissions for
-every standard program.  If you suspect that you have the permissions set
-incorrectly, use the permissions of the files on the Live Filesystem CD-ROM as a
-guideline.
-.Aside
-\fIsetuid\fP\| and \fIsetgid\fP\| programs can be a security issue.  What
-happens if the program called \fIps\fP\| is really something else, a Trojan
-Horse?  We set the permissions to allow it to break into the system.  As a
-result, newer versions of FreeBSD have alternative methods for \fIps\fP\| to do
-its work, and it no longer needs to be set \fIsetgid\fP.
-.End-aside
-.H4 "Links"
+permissions for
+.Command ps .
+It's impossible to go through the permissions for every standard program.  If
+you suspect that you have the permissions set incorrectly, use the permissions
+of the files on the Live Filesystem CD-ROM as a guideline.
+.P
+\fIsetuid\fP\/ and \fIsetgid\fP\/ programs can be a security issue.  What
+happens if the program called
+.Command ps
+is really something else, a Trojan Horse?  We set the permissions to allow it to
+break into the system.  As a result, FreeBSD has found an alternative method for
+.Command ps
+to do its work, and it no longer needs to be set
+.Command setgid .
+.H2 "Mandatory Access Control"
+For some purposes, traditional UNIX permissions are insufficient.  Release 5.0
+of FreeBSD introduces \fIMandatory Access Control\fP, or \fIMAC\fP, which
+permits loadable kernel modules to augment the system security policy.  MAC is
+intended as a toolkit for developing local and vendor security extensions, and
+it includes a number of sample policy modules, including Multi-Level Security
+(MLS) with compartments, and a number of augmented UNIX security models
+including a file system firewall.  At the time of writing it is still considered
+experimental software, so this book doesn't discuss it further.  See the man
+pages for more details.
+.H2 "Links"
 .Pn links
 .X "hard link"
 .X "link, hard"
-..if appropriate
-.Aside
-`Or else it doesn't, you know.  The name of the song is called
-``\fIHaddocks' Eyes\fP.'''
-
-`Oh, that's the name of the song, is it?' Alice said, trying to
-feel interested.
-
-`No, you don't understand,' the Knight said, looking a little vexed.  `That's
-what the name is \fIcalled\fP\|.  The name really \fIis\fP\| ``\fIThe Aged Aged
-Man\fP\|.'''
-
-`Then I ought to have said ``That's what the \fIsong\fP\| is called''?'  Alice
-corrected herself.
-
-`No, you oughtn't: that's quite another thing!  The \fIsong\fP\| is called
-``\fIWays And Means''\fP\|: but that's only what it's \fIcalled\fP\|, you know!'
-
-`Well, what \fIis\fP\| the song, then?' said Alice, who was by this time
-completely bewildered.
-
-`I was coming to that,' the Knight said.  `The song really \fIis\fP\|
-``\fIA-sitting On A Gate''\fP\|:  and the tune's my own invention.'
-.br
-\h'4i'\(emLewis Carroll, \fIThrough the Looking Glass\fP
-.End-aside
-..endif
-.X "hard link"
-.X "link, hard"
-In UNIX, files are defined by \fIinodes\fP, structures on disk which you can't
+In UNIX, files are defined by \fIinodes\fP, structures on disk that you can't
 access directly.  They contain the \fImetadata\fP, all the information about the
 file, such as owner, permissions and timestamps.  What they don't contain are
 the things you think of as making up a file: they don't have any data, and they
-don't have any name.  Instead, the inode contains information about where the
-data blocks are located on the disk.  It doesn't know anything about the name:
-that's the job of the directories.
+don't have names.  Instead, the inode contains information about where the data
+blocks are located on the disk.  It doesn't know anything about the name: that's
+the job of the directories.
 .P
-A directory is simply a special kind of file which contains a list of names and
+.ne 3v
+A directory is simply a special kind of file that contains a list of names and
 inode numbers: in other words, they assign a name to an inode, and thus to a
 file.  More than one name can point to the same inode, so files can have more
 than one name.  This connection between a name and an inode is called a
-\fIlink\fP, sometimes confusingly \fIhard link\fP.  Since the inode numbers
-relate to the file system, files must be in the same file system as the
-directory which refers to them.
+\fIlink\fP, sometimes confusingly \fIhard link\fP.  The inode numbers relate to
+the file system, so files must be in the same file system as the directory that
+refers to them.
 .P
 Directory entries are independent of each other: each points to the inode, so
-they're completely equivalent.  The inode contains a \fIlink count\fP which
-keeps track of how many directory entries point to it: when you remove the last
-entry, the file data is deleted.
+they're completely equivalent.  The inode contains a \fIlink count\fP that keeps
+track of how many directory entries point to it: when you remove the last entry,
+the system deletes the file data and metadata.
 .P
 .X "symbolic link"
 .X "soft link"
 .X "link, symbolic"
 .X "link, soft"
-Alternatively, \fIsymbolic links\fP, sometimes called \fIsoft links\fP, are
-not restricted to the same file system (not even to the same system!), and they
+Alternatively, \fIsymbolic links\fP, sometimes called \fIsoft links\fP, are not
+restricted to the same file system (not even to the same system!), and they
 refer to another file name, not to the file itself.  The difference is most
 evident if you delete a file: if the file has been hard linked, the other names
 still exist and you can access the file by them.  If you delete a file name
-which has a symbolic link pointing to it, the file will go away and the symbolic
-link will not be able to find it any more.
+that has a symbolic link pointing to it, the file goes away and the symbolic
+link can't find it any more.
 .P
 It's not easy to decide which kind of link to use\(emsee \fIUNIX Power Tools\fP
-for more details.
-.H2 "Directory structure"
+(O'Reilly) for more details.
+.H2 "Directory hierarchy"
 .Pn directory-structure
 Although Microsoft platforms have a hierarchical directory structure, there is
 little standardization of the directory names: it's difficult to know where a
 particular program or data file might be.  UNIX systems have a standard
 directory hierarchy, though every vendor loves to change it just a little bit to
 ensure that they're not absolutely compatible.  In the course of its evolution,
-UNIX has changed its directory structure several times.  Still, it's much better
-than the almost complete lack of standardization in the Microsoft world.  The
-most recent, and probably most far-reaching changes, occurred with System V.4
-and 4.4BSD, both of which made almost identical changes.
+UNIX has changed its directory hierarchy several times.  It's still better than
+the situation in the Microsoft world.  The most recent, and probably most
+far-reaching changes, occurred over ten years ago with System V.4 and 4.4BSD,
+both of which made almost identical changes.
 .P
 .X "root file system"
 .X "file system, root"
-.X "fsck command"
-.X "command, fsck"
-.X "fsdb command"
-.X "command, fsdb"
-.X "/usr"
 .X "directory, /usr"
-.X "/"
 .X "directory, /"
 Nearly every version of UNIX prefers to have at least two file systems,
-\fI/\fP\| (the \fIroot file system\fP\|) and \fI/usr\fP, even if they only have
-a single disk.  This arrangement is considered more reliable than a single file
-system: it's possible for a file system to crash so badly that it can't be
-mounted any more, and you need to read in a tape backup, or use programs like
-\fIfsck\fP\| or \fIfsdb\fP\| to piece them together.  We have already discussed
-this issue on page 
+.Directory -n /
+(the \fIroot file system\fP\/) and
+.Directory /usr ,
+even if they only have a single disk.  This arrangement is considered more
+reliable than a single file system: it's possible for a file system to crash so
+badly that it can't be mounted any more, and you need to read in a tape backup,
+or use programs like
+.Command fsck
+or
+.Command fsdb
+to piece them together.  We have already discussed this issue on page
 .Sref \*[partition-size] ,
-where we recommend having \fI/usr\fP\| on the same file system as \fI/\fP.
+where I recommend having
+.Directory /usr
+on the same file system as
+.Directory -n / .
 .H3 "Standard directories"
 The physical layout of the file systems does not affect the names or contents of
-the directories, which are standardized.  Table \*[hierarchy] gives an overview
-of the standard FreeBSD directories.
+the directories, which are standardized.  Table
+.Sref \*[hierarchy] \&
+gives an overview
+of the standard FreeBSD directories; see the man page \f(CWhier(7)\fP for more
+details.
 .P
-.ad l
 .ne 10
 .ds Section*title FreeBSD directory hierarchy
-.TB "FreeBSD directory hierarchy"
+.Table-heading "FreeBSD directory hierarchy"
+.Tn hierarchy
 .TS H
-box,tab(#) ;
-| lfI | lw62 | .
-\fRDirectory
-\fRName#Usage
-=
+tab(#) ;
+ lfI | lw53  .
+\fBDirectory
+\fBname#\fBUsage
+_
 .TH N
-.X "/"
 .X "directory, /"
 /#T{
-Root file system.  Contains the kernel, the bootstrap, and mount points for
+Root file system.  Contains a couple of system directories and mount points for
 other file systems.  It should not contain anything else.
 T}
 .sp .4v
-.X "/bin"
 .X "directory, /bin"
 /bin#T{
-Executable programs of general use which are needed at system startup time.  The
+Executable programs of general use needed at system startup time.  The
 name was originally an abbreviation for \fIbinary\fP, but many of the files in
 here are shell scripts.
 T}
 .sp .4v
-.X "/boot"
 .X "directory, /boot"
 /boot#T{
-Files used when booting the system.  From FreeBSD version 5 onwards this
-directory will also contain the kernel and its associated \fIklds\fP.
+Files used when booting the system, including the kernel and its associated
+\fIklds\fP.
 T}
 .sp .4v
-.X "/cdrom"
 .X "directory, /cdrom"
 /cdrom#T{
-A mount point for CD-ROM drives
+A mount point for CD-ROM drives.
 T}
 .sp .4v
-.X "/compat
 .X "directory, /compat"
 /compat#T{
-A directory containing code for emulated systems, such as Linux.
+A link to
+.Directory /usr/compat \/:
+see below.
 T}
 .sp .4v
-.X "/dev"
 .X "directory, /dev"
 /dev#T{
-Directory of device nodes.  The name is an abbreviation for \fIdevices\fP.
-We'll look at the contents of this directory in more detail on page
+Directory of device nodes.  The name is an abbreviation for \fIdevices\fP.  From
+FreeBSD 5.0 onward, this is normally a mount point for the \fIdevice file
+system\fP, \fIdevfs\fP.  We'll look at the contents of this directory in more
+detail on page
 .Sref \*[FreeBSD-devices] .
-.X "/etc"
 .X "directory, /etc"
-.X "/sbin"
 .X "directory, /sbin"
 T}
 .sp .4v
-.X "/etc"
 .X "directory, /etc"
 /etc#T{
-Files used at system startup.  Unlike System V, \fI/etc\fP\| does not contain
-kernel build files, which are not needed at system startup.  Unlike earlier UNIX
-versions, it also does not contain executables\(emthey have been moved to
-\fI/sbin\fP.
+Configuration files used at system startup.  Unlike System V,
+.Directory /etc
+does not contain kernel build files, which are not needed at system startup.
+Unlike earlier UNIX versions, it also does not contain executables\(emthey have
+been moved to
+.Directory /sbin .
+T}
+.sp .4v
+.X "directory, /home"
+/home#T{
+By convention, put user files here.  Despite the name,
+.Directory /usr
+is for system files.
 T}
 .sp .4v
-.X "/proc"
 .X "directory, /proc"
-.X "process directory"
+.X "process, directory"
 .X "directory, process"
-.X "/stand/sysinstall"
-.X "/lib"
 .X "directory, /lib"
-.X "/var"
 .X "directory, /var"
-.X "/mnt"
 .X "directory, /mnt"
 /mnt#T{
-A mount point for floppies and other temporary file systems
+A mount point for floppies and other temporary file systems.
 T}
 .sp .4v
-.X "kernel loadable module"
-.X "/modules"
-.X "directory, /modules"
-/modules#T{
-Directory containing \fIkernel loadable modules\fP, parts of the kernel which
-can be started at run time.  Starting with FreeBSD version 5, the files in this
-directory will be moved to \fI/boot/kernel\fP.
-T}
-.sp .4v
-.X "/proc"
 .X "directory, /proc"
 /proc#T{
-.X "process file system"
+.X "process, file system"
 .X "file system, process"
-The \fIprocess file system\fP.  This directory contains pseudo-files which refer
+The \fIprocess file system\fP.  This directory contains pseudo-files that refer
 to the virtual memory of currently active processes.
 T}
 .sp .4v
-.X "/root"
 .X "directory, /root"
 /root#T{
 The home directory of the user \f(CWroot\fP.  In traditional UNIX file
-systems, \f(CWroot\fP's home directory was \fI/\fP, but this is messy.
+systems, \f(CWroot\fP's home directory was
+.Directory -n / ,
+but this is messy.
 T}
 .sp .4v
-.X "/sbin"
 .X "directory, /sbin"
 \fI/sbin#T{
 System executables needed at system startup time.  These are typically system
 administration files
-that used to be stored in \fI/etc\fP.
+that used to be stored in
+.Directory /etc .
 T}
-.X "/stand"
-.X "directory, /stand"
-/stand#T{
-Directory with \fIstandalone\fP\| programs.  In fact, most of the programs are
-the same file, \fI/stand/sysinstall\fP, which we discussed in great detail in
-\*[chinstall].  Starting with version 5 of FreeBSD, \fIsysinstall\fP\| will move
-to \fI/sbin\fP\| in order to facilitate using it on a live system.
+.sp .4v
+/sys#T{
+If present, this is usually a symbolic link to
+.Directory /usr/src/sys ,
+the kernel sources.  This is a tradition derived from 4.3BSD.
+T}
+.sp .4v
+/tmp#T{
+A place for temporary files.  This directory is an anachronism: normally it is
+on the root file system, though it is possible to mount it as a separate file
+system or make it a symbolic link to
+.Directory /var/tmp .
+It is maintained mainly for programs that expect to find it.
 T}
 .sp .4v
-.X "/usr"
 .X "directory, /usr"
 /usr#T{
-The ``second file system''.  See the discussion above.
+The ``second file system.''  See the discussion above.
 T}
 .sp .4v
-.X "/usr/X11R6"
 .X "directory, /usr/X11R6"
 /usr/X11R6#T{
-The X11 windowing system
+The X Window System.
 T}
 .sp .4v
-.X "/usr/X11R6/bin"
 .X "directory, /usr/X11R6/bin"
 /usr/X11R6/bin#T{
-Executable X11 programs
+Executable X11 programs.
 T}
 .sp .4v
-.X "/usr/X11R6/include"
 .X "directory, /usr/X11R6/include"
 /usr/X11R6/include#T{
-Header files for X11 programming
+Header files for X11 programming.
 T}
 .sp .4v
-.X "/usr/X11R6/lib"
 .X "directory, /usr/X11R6/lib"
 /usr/X11R6/lib#T{
-Library files for X11
+Library files for X11.
 T}
 .sp .4v
-.X "/usr/X11R6/man"
 .X "directory, /usr/X11R6/man"
 /usr/X11R6/man#T{
-Man pages for X11
+Man pages for X11.
 T}
 .sp .4v
-.X "/usr/bin"
 .X "directory, /usr/bin"
 /usr/bin#T{
-Standard executable programs that are not needed at system start.  Most programs
-you use will be stored here.
+Standard executable programs that are not needed at system start.  Most standard
+programs you use are stored here.
+T}
+.sp .4v
+.X "directory, /usr/compat"
+/usr/compat#T{
+A directory containing code for emulated systems, such as Linux.
 T}
 .sp .4v
-.X "/usr/games"
 .X "directory, /usr/games"
 /usr/games#T{
-Games
+Games.
 T}
 .sp .4v
-.X "/usr/include"
 .X "directory, /usr/include"
 /usr/include#T{
-Header files for programmers
+Header files for programmers.
 T}
 .sp .4v
-.X "/usr/lib"
 .X "directory, /usr/lib"
-.X "/lib"
 .X "directory, /lib"
 /usr/lib#T{
-Library files for programmers.  FreeBSD does not have a directory
-\fI/lib\fP.
+Library files.  FreeBSD does not have a directory
+.Directory /lib .
 T}
 .sp .4v
-.X "/usr/libexec"
 .X "directory, /usr/libexec"
 /usr/libexec#T{
-Executable files which are not started directly by the user, for example the
-phases of the C compiler (which are started by \fI/usr/bin/gcc\fP\|) or the
-.X "/usr/bin/gcc"
-\fIgetty\fP\| program, which is started by \fIinit\fP.
+Executable files that are not started directly by the user, for example the
+phases of the C compiler (which are started by
+.File /usr/bin/gcc )
+or the
+.Command getty
+program, which is started by
+.Daemon init .
+T}
+.sp .4v
+.X "directory, /usr/libdata"
+/usr/libdata#T{
+Miscellaneous files used by system utilities.
 T}
 .sp .4v
-.X "/usr/local"
 .X "directory, /usr/local"
 /usr/local#T{
-Additional programs which are not part of the operating system.  It parallels
-the \fI/usr\fP\| directory in having subdirectories \fIbin\fP, \fIinclude\fP,
-\fIlib\fP, \fIman\fP, \fIsbin\fP, and \fIshare\fP.  This is where you can put
-programs which you get from other sources.
+Additional programs that are not part of the operating system.  It parallels
+the
+.Directory /usr
+directory in having subdirectories
+.Directory -n bin ,
+.Directory -n include ,
+.Directory -n lib ,
+.Directory -n man ,
+.Directory -n sbin ,
+and
+.Directory -n share .
+This is where you can put programs that you get from other sources.
+T}
+.sp .4v
+.X "directory, /usr/obj"
+/usr/obj#T{
+Object files created when building the system.  See Chapter
+.Sref "\*[nchbuild]".
+T}
+.sp .4v
+.X "directory, /usr/ports"
+/usr/ports#T{
+The Ports Collection.
 T}
 .sp .4v
-.X "/usr/sbin"
 .X "directory, /usr/sbin"
 /usr/sbin#T{
-System administration programs which are not needed at system startup.
+System administration programs that are not needed at system startup.
 T}
 .sp .4v
-.X "/usr/share"
 .X "directory, /usr/share"
 /usr/share#T{
 Miscellaneous read-only files, mainly informative.  Subdirectories include
-\fIdoc\fP, the FreeBSD documentation, \fIgames\fP, \fIinfo\fP, the GNU
-\fIinfo\fP\| documentation, \fIlocale\fP, internationization information, and
-\fIman\fP, the man pages.
+.Directory -n doc ,
+the FreeBSD documentation,
+.Directory -n games ,
+.Directory -n info ,
+the GNU \fIinfo\fP\/ documentation,
+.Directory -n locale ,
+internationization information, and
+.Directory -n man ,
+the man pages.
+T}
+.sp .4v
+.X "directory, /usr/src"
+/usr/src#T{
+System source files.
 T}
 .sp .4v
-.X "/var"
 .X "directory, /var"
 /var#T{
-A file system for data which changes frequently, such as mail, news, and log
-files.  If \fI/var\fP\| is not a separate file system, you should create a
-directory on another file system and symlink \fI/var\fP\| to it\(emsee page
-\*[symlink-var]).
+A file system for data that changes frequently, such as mail, news, and log
+files.  If
+.Directory /var
+is not a separate file system, you should create a directory on another file
+system and symlink
+.Directory /var
+to it.
 T}
 .sp .4v
-.X "/var/log"
 .X "directory, /var/log"
 /var/log#T{
 Directory with system log files
 T}
 .sp .4v
-.X "/var/mail"
 .X "directory, /var/mail"
 /var/mail#T{
 Incoming mail for users on this system
 T}
 .sp .4v
-.X "/var/spool"
 .X "directory, /var/spool"
-.X "/var/spool/lpd"
-.X "/var/spool/mqueue"
-.X "/var/spool/uucp"
-.X "/var/spool/ftp"
 /var/spool#T{
-Spool data, such as data waiting to be printed (\fI/var/spool/lpd\fP\|),
-\fI/var/spool/mqueue\fP\| (outgoing mail), UUCP data (\fI/var/spool/uucp\fP\|), and
-\fI/var/spool/ftp\fP\| (anonymous FTP).
+Transient data, such as outgoing mail, print data and anonymous ftp.
 T}
 .sp .4v
-.X "/var/tmp"
 .X "directory, /var/tmp"
 /var/tmp#T{
 Temporary files.
 T}
+_
 .TE
-.Tn hierarchy
-.ad b
 .H2 "File system types"
 .Pn fs-types
 FreeBSD supports a number of file system types.  The most important are:
 .Ls B
 .LI
-.X "ufs"
+.X "UFS"
+.X "ffs"
 .X "UNIX File System"
-\fIufs\fP\| is the \fIUNIX File System\fP.  All native disk files are of this
-type.
+.X "Fast File System"
+\fIUFS\fP\/ is the \fIUNIX File System\fP.\*F
+.FS
+Paradoxically, although BSD may not be called UNIX, its file system \fIis\fP\/
+called the UNIX File System.  The UNIX System Group, the developers of UNIX
+System V.4, adopted UFS as the standard file system for System V and gave it
+this name.  Previously it was called the Berkeley \fIFast File System\fP, or
+\fIffs\fP.
+.FE
+All native disk file systems are of this type.  Since FreeBSD 5.0, you have a
+choice of two different versions, \fIUFS 1\fP\/ and \fIUFS 2\fP.  As the names
+suggest, UFS 2 is a successor to UFS 1.  Unlike UFS 1, UFS 2 file systems are
+not limited to 1 TB (1024 GB) in size.  UFS 2 is relatively new, so unless you
+require very large file systems, you should stick to UFS 1.
 .LI
 .Pn RockRidge
-.X "cd9660 file system"
+.X "cd9660, file system"
 .X "Rock Ridge Extensions"
-\fIcd9660\fP\| is the ISO 9660 CD-ROM format with the so-called \fIRock Ridge
-Extensions\fP\| which enable UNIX-like file names to be used.  Use this file
+\fIcd9660\fP\/ is the ISO 9660 CD-ROM format with the so-called \fIRock Ridge
+Extensions\fP\/ that enable UNIX-like file names to be used.  Use this file
 system type for all CD-ROMs, even if they don't have the Rock Ridge Extensions.
 .LI
 .X "nfs"
 .X "Network File System"
-\fInfs\fP\| is the \fINetwork File System\fP, a means of sharing file systems
-across a network.  We'll look at it in \*[chnfs].
-.LI
-You can access Linux files systems with the \fIext2fs\fP\| file system.
+\fInfs\fP\/ is the \fINetwork File System\fP, a means of sharing file systems
+across a network.  We'll look at it in Chapter
+.Sref "\*[nchserver]" .
 .LI
-.X "msdos file system"
-.X "file system, msdos"
 .Pn msdosfs
-.X "mount_msdos, command"
-.X "command, mount_msdos"
-You can access Microsoft files with the \fImsdos\fP\| and \fIntfs\fP\| file
-systems.  See the man page \fImount_msdos(8)\fP\| and page \fImount_ntfs(8)\fI
-for further details.
+FreeBSD supports a number of file systems from other popular operating systems.
+You mount the file systems with the
+.Command mount
+command and the \f(CW-t\fP option to specify the file system type.  For example:
+.Dx
+# \f(CBmount -t ext2fs /dev/da1s1 /linux\fP     \fImount a Linux ext2 file system\fP\/
+# \f(CBmount -t msdos /dev/da2s1 /C:\fP         \fImount a Microsoft FAT file system\fP\/
+.De
+Here's a list of currently supported file systems:
+.br
+.ne 1i
+.Table-heading "File system support"
+.TS
+tab(#) ;
+l | lfCWp9 .
+\fBFile system#\fBmount option
+_
+CD-ROM#cd9660
+DVD#udf
+Linux ext2#ext2fs
+Microsoft MS-DOS#msdosfs
+Microsoft NT#ntfs
+Novell Netware#nwfs
+Microsoft CIFS#smbfs
+.TE
+.Le
+.SPUP
+.H3 "Soft updates"
+.Pn soft-updates
+Soft updates change the way the file system performs I/O.  They enable
+\fImetadata\fP\/ to be written less frequently.  This can give rise to dramatic
+performance improvements under certain circumstances, such as file deletion.
+Specify soft updates with the \f(CW-U\fP option when creating the file system.
+For example:
+.Dx
+# \f(CBnewfs -U /dev/da1s2h\fP
+.De
+If you forget this flag, you can enable them later with
+.Command tunefs \/:
+.Dx
+# \f(CBtunefs -n enable /dev/da1s2h\fP
+.De
+You can't perform this operation on a mounted file system.
+.H3 "Snapshots"
+One of the problems with backing up file systems is that you don't get a
+consistent view of the file system: while you copy a file, other programs may be
+modifying it, so what you get on the tape is not an accurate view of the file at
+any time.  \fISnapshots\fP\/ are a method to create a unified view of a file
+system.  They maintain a relatively small file in the file system itself
+containing information on what has changed since the snapshot was taken.  When
+you access the snapshot, you get this data rather than the current data for the
+parts of the disk which have changed, so you get a view of the file system as it
+was at the time of the snapshot.
+.H4 "Creating snapshots"
+You create  snapshots with the
+.Command mount
+command and the \f(CW-o snapshot\fP option.  For example, you could enter
+.Dx
+# \f(CBmount -u -o snapshot /var/snapshot/snap1 /var\fP
+.De
+This command creates a snapshot of the
+.Directory /var
+file system called
+.File /var/snapshot/snap1 .
+.P
+.ne 4v
+Snapshot files have some interesting properties:
+.Ls B
+.LI
+You can have multiple snapshots on a file system, up to the current limit of 20.
+.LI
+Snapshots have the \f(CWschg\fP flag set, which prevents anybody writing to them.
+.LI
+Despite the \f(CWschg\fP flag, you can still remove them.
+.LI
+They are automatically updated when anything is written to the file system.  The
+view of the file system doesn't change, but this update is necessary in order to
+maintain the ``old'' view of the file system.
+.LI
+They look like normal file systems.  You can mount them with the \fImd\fP\/
+driver.  We'll look at that on page
+.Sref \*[vnode-device] .
 .Le
-.H3 "Mounting file systems"
-.X "mount, command"
-.X "command, mount"
-.X "/cdrom"
-.X "file system, /cdrom"
-.X "/cd0"
-.X "file system, /cd0"
+Probably the most useful thing you can do with a snapshot is to take a backup of
+it.  We'll look at backups on page
+.Sref \*[backups] .
+.P
+At the time of writing, snapshots are still under development.  It's possible
+that you might still have trouble with them, in particular with deadlocks that
+can only be cleared by rebooting.
+.P
+It takes about 30 seconds to create a snapshot of an 8 GB file system.  During
+the last five seconds, file system activity is suspended.  If there's a lot of
+soft update activity going on in the file system (for example, when deleting a
+lot of files), this suspension time can become much longer, up to several
+minutes.  To remove the same snapshot takes about two minutes, but it doesn't
+suspend file system activity at all.
+.SPUP
+.H2 "Mounting file systems"
 .Pn mount
 .X "file system, root"
 .X "root file system"
 .X "mounting"
 .X "CD-ROM, mounting"
-Microsoft platforms identify partitions by letters which are assigned at boot
+Microsoft platforms identify partitions by letters that are assigned at boot
 time.  There is no obvious relation between the partitions, and you have little
 control over the way the system assigns them.  By contrast, all UNIX partitions
 have a specific relation to the \fIroot file system\fP, which is called simply
-\fI/\fP.  This flexibility has one problem: you have the choice of where in the
-overall file system structure you put your individual file systems.  You specify
-the location with the \fImount\fP\| command.  For example, you would typically
-mount a CD-ROM in the directory \fI/cdrom\fP, but if you have three CD-ROM
-drives attached to your SCSI controller, you might prefer to mount them in the
-directories \fI/cd0\fP, \fI/cd1\fP, and \fI/cd2\fP.\*F
-.FS
-This numbering is in keeping with the UNIX tradition of numbering starting from
-0.  There's nothing to stop you choosing some other name, of course.
-.FE
-In order to mount a file system, you need to specify the device to be mounted,
-where it is to be mounted, and the type of file system (unless it is ufs).  The
-\fImount point\fP, (the directory where it is to be mounted) must already exist.
-To mount your second CD-ROM on \fI/cd1\fP, you would enter:
+.Directory -n / .
+This flexibility has one problem: you have the choice of where in the overall
+file system structure you put your individual file systems.  You specify the
+location with the
+.Command mount
+command.  For example, you would typically mount a CD-ROM in the directory
+.Directory /cdrom ,
+but if you have three CD-ROM drives attached to your SCSI controller, you might
+prefer to mount them in the directories
+.Directory -n /cd0 ,
+.Directory -n /cd1 ,
+and
+.Directory -n /cd2 .
+To mount a file system, you need to specify the device to be mounted, where it
+is to be mounted, and the type of file system (unless it is ufs).  The \fImount
+point\fP, (the directory where it is to be mounted) must already exist.  To
+mount your second CD-ROM on
+.Directory -n /cd1 ,
+you enter:
 .Dx
-# \f(CBmkdir /cd1\fP				\fIonly if it doesn't exist\fP\|
+# \f(CBmkdir /cd1\fP                                    \fIonly if it doesn't exist\fP\/
 # \f(CBmount -t cd9660 -o ro /dev/cd1a /cd1\fP
 .De
-.X "/etc/rc"
-.X "/etc/fstab"
-When the system boots, it calls the startup script \fI/etc/rc\fP, which amongst
-other things automatically mounts the file systems.  All you need to do is to
-supply the information: what is to be mounted, and where?  This is in the file
-\fI/etc/fstab\fP.  If you come from a System V environment, you'll notice
-significant difference in format\(emsee the man page \fIfstab(5)\fP\| for the
-full story.  A typical \fI/etc/fstab\fP\| might look like:
+When the system boots, it calls the startup script
+.File /etc/rc ,
+which among other things automatically mounts the file systems.  All you need to
+do is to supply the information: what is to be mounted, and where?  This is in
+the file
+.File /etc/fstab .
+If you come from a System V environment, you'll notice significant difference in
+format\(emsee the man page \fIfstab(5)\fP\/ for the full story.  A typical
+.File /etc/fstab
+might look like:
 .Dx
-/dev/ad0s1a     /               ufs     rw 1 1  \fIroot file system\fP\|
-/dev/ad0s1b     none            swap    sw 0 0  \fIswap\fP\|
-/dev/ad0s1e     /usr            ufs     rw 2 2  \fI/usr file system\fP\|
-/dev/da1e       /src            ufs     rw 2 2  \fIadditional file system\fP\|
-/dev/da2s1      /linux          ext2fs  rw 2 2  \fILinux file system\fP\|
-/dev/ad1s1      /C:             msdos   rw 2 2  \fIMicrosoft file system\fP\|
-proc            /proc           procfs  rw 0 0  \fIproc pseudo-file system\fP\|
-/dev/cd0a       /cdrom          cd9660  ro 0 0  \fICD-ROM\fP\|
-presto:/        /presto/root    nfs     rw 0 0  \fINFS file systems on other systems\fP\|
+/dev/ad0s1a  /                   ufs         rw  1 1  \fIroot file system\fP\/
+/dev/ad0s1b  none                swap        sw  0 0  \fIswap\fP\/
+/dev/ad0s1e  /usr                ufs         rw  2 2  \fI/usr file system\fP\/
+/dev/da1s1e  /src                ufs         rw  2 2  \fIadditional file system\fP\/
+/dev/da2s1   /linux              ext2fs      rw  2 2  \fILinux file system\fP\/
+/dev/ad1s1   /C:                 msdos       rw  2 2  \fIMicrosoft file system\fP\/
+proc         /proc               procfs      rw  0 0  \fIproc pseudo-file system\fP\/
+linproc      /compat/linux/proc  linprocfs   rw  0 0
+/dev/cd0a    /cdrom              cd9660      ro  0 0  \fICD-ROM\fP\/
+presto:/     /presto/root        nfs         rw  0 0  \fINFS file systems on other systems\fP\/
 presto:/usr     /presto/usr     nfs     rw 0 0
 presto:/home    /presto/home    nfs     rw 0 0
 presto:/S       /S              nfs     rw 0 0
+//guest@samba/public  /smb       smbfs       rw,noauto  0 0  \fISMB file system\fP\/
 .De
+.ne 5v
 The format of the file is reasonably straightforward:
 .Ls B
 .LI
@@ -836,48 +944,102 @@
 keyword for some file systems, like \f(CWproc\fP, or the name of the remote file
 system for NFS mounts.
 .LI
-The second column specifies the mount point.
+The second column specifies the mount point.  Swap partitions don't have a mount
+point, so the mount point for the swap partition is specified as \f(CWnone\fP.
 .LI
 The third column specifies the type of file system.  Local file systems on hard
 disk are always \fIufs\fP, and file systems on CD-ROM are \fIcd9660\fP.  Remote
-file systems are always \fInfs\fP\|.  Specify swap partitions with \fIswap\fP,
-and the \fIproc\fP\| file system with \fIproc\fP\|.
+file systems are always \fInfs\fP\/.  Specify swap partitions with \fIswap\fP,
+and the \fIproc\fP\/ file system with \fIproc\fP\/.
 .LI
-The fourth column contains \f(CWrw\fP for file systems which can be read or
-written, \f(CWro\fP for file systems (like CD-ROM) which can only be read, and
-\f(CWsw\fP for swap partitions.
+The fourth column contains \f(CWrw\fP for file systems that can be read or
+written, \f(CWro\fP for file systems (like CD-ROM) that can only be read, and
+\f(CWsw\fP for swap partitions.  It can also contain options like the
+\f(CWnoauto\fP in the bottom line, which tells the system startup scripts to
+ignore the line.  It's there so that you can use the shorthand notation
+\f(CWmount /smb\fP when you want to mount the file system.
 .LI
-The fifth and sixth columns are used by the \fIdump\fP\| and \f(CWfsck\fP
+The fifth and sixth columns are used by the \fIdump\fP\/ and \f(CWfsck\fP
 programs.  You won't normally need to change them.  Enter \f(CW1\fP for a root
-file system, \f(CW2\fP for other ufs file systems, and 0 for everything else.
+file system, \f(CW2\fP for other UFS file systems, and 0 for everything else.
 .Le
-.ne 1.5i
+.H3 "Mounting files as file systems"
+.X "loop mount"
+.X "mount, loop"
+.Pn vnode-device
+So far, our files have all been on devices, also called \fIspecial files\fP.
+Sometimes, though, you may want to access the contents of a file as a file
+system:
+.Ls B
+.LI
+It's sometimes of interest to access the contents of a snapshot, for example to
+check the contents.
+.LI
+After creating an ISO image to burn on CD-R, you should check that it's valid.
+.LI
+Also, after downloading an ISO image from the Net, you may just want to access
+the contents, and not create a CD-R at all.
+.Le
+In each case, the solution is the same: you mount the files as a \fIvnode\fP\/
+device with the \fImd\fP\/ driver.
+.P
+The \fImd\fP\/ driver creates a number of different kinds of pseudo-device.  See
+the man page \fImd(4)\fP.  We use the \fIvnode\fP\/ device, a special file that
+refers to file system files.  Support for \fImd\fP\/ is included in the GENERIC
+kernel, but if you've built a kernel without the \fImd\fP\/ drive, you can load
+it as a \fIkld\fP.  If you're not sure, try loading the kld anyway.
+.P
+In the following example, we associate a vnode device with the ISO image
+.File -n iso-image
+using the program
+.Command mdconfig \/:
+.Dx
+# \f(CBkldload md\fP                            \fIload the kld module if necessary\fP\/
+kldload: can't load md: File exists     \fIalready loaded or in the kernel\fP\/
+# \f(CBmdconfig -a -t vnode -f iso-image\fP     \fIand configure the device\fP\/
+md0                                     \fIthis is the name assigned in directory /dev\fP\/
+# \f(CBmount -t cd9660 /dev/md0 /mnt\fP         \fIthen mount it\fP\/
+.De
+.ne 5v
+After this, you can access the image at
+.Directory /mnt
+as a normal file system.  You specify \f(CW-t cd9660\fP in this case because the
+file system on the image is a CD9660 file system.  You don't specify this if
+you're mounting a UFS file system, for example a snapshot image.
+.P
+Older versions of FreeBSD used the \fIvn\fP\/ driver, which used different
+syntax.  Linux uses \fIloop mounts\fP, which FreeBSD doesn't support.
 .H3 "Unmounting file systems"
 When you mount a file system, the system assumes it is going to stay there, and
 in the interests of efficiency it delays writing data back to the file system.
-This is the same effect we discussed on page \*[shutdown].  As a result, if you
-want to stop using a file system, you must tell the system about it so that it
-can flush any remaining data.  You do this with the \fIumount\fP\| command.
-Note the spelling\(emthere's no \fBn\fP in the command name.
+This is also the reason why you can't just turn the power off when you shut down
+the system.  If you want to stop using a file system, you must tell the system
+about it so that it can flush any remaining data.  You do this with the
+.Command umount
+command.  Note the spelling of this command\(emthere's no \fBn\fP in the command
+name.
 .P
 You need to do this even with read-only media such as CD-ROMs: the system
 assumes it can access the data from a mounted file system, and it gets quite
 unhappy if it can't.  Where possible, it locks removable media so that you can't
 remove them from the device until you unmount them.
 .P
-Using \fIumount\fP\| is straightforward: just tell it what to unmount, either
-the device name or the directory name.  For example, to unmount the CD-ROM we
-mounted in the example above, you could enter one of these commands:
+Using
+.Command umount
+is straightforward: just tell it what to unmount, either the device name or the
+directory name.  For example, to unmount the CD-ROM we mounted in the example
+above, you could enter one of these commands:
 .Dx
 # \f(CBumount /dev/cd1a\fP
 # \f(CBumount /cd1\fP
 .De
-Before unmounting a file system, \fIumount\fP\| checks that nobody is using it.
-If somebody is using it, it will refuse to unmount it with a message like
-\f(CWumount: /cd1: Device busy\fP.  This message often occurs because you have
-changed your directory to a directory on the file system you want to remove.
-For example (which also shows the usefulness of having directory names in the
-prompt):
+Before unmounting a file system,
+.Command umount
+checks that nobody is using it.  If somebody is using it, it refuses to unmount
+it with a message like \f(CWumount: /cd1: Device busy\fP.  This message often
+occurs because you have changed your directory to a directory on the file system
+you want to remove.  For example (which also shows the usefulness of having
+directory names in the prompt):
 .Dx
 === root@freebie (/dev/ttyp2) /cd1 16 -> \f(CBumount /cd1\fP
 umount: /cd1: Device busy
@@ -885,180 +1047,52 @@
 === root@freebie (/dev/ttyp2) ~ 18 -> \f(CBumount /cd1\fP
 === root@freebie (/dev/ttyp2) ~ 19 -> 
 .De
+.ne 3v
+After unmounting a vnode file system, don't forget to unconfigure the file:
+.Dx
+# \f(CBumount /mnt\fP
+# \f(CBmdconfig -d -u 0\fP
+.De
+The parameter \f(CW0\fP refers to \fImd\fP\/ device 0, in other words
+.Device md0 .
 .H2 "FreeBSD devices"
 .Pn devices
-.X "ifconfig, command"
-.X "command, ifconfig"
 UNIX refers to devices in the same manner as it refers to normal files.  By
 contrast to normal (``regular'') files, they are called \fIspecial files\fP.
 They're not really files at all: they're information about device support in the
-kernel, and the term \fIdevice node\fP\| is more accurate.  Conventionally, they
-are stored in the directory \fI/dev\fP.  Some devices don't have device nodes,
-for example Ethernet interfaces: they are treated differently by the
-\fIifconfig\fP\| program.
-.P
-UNIX systems distinguish two types of device, \fIblock devices\fP\| and
-\fIcharacter devices\fP.  FreeBSD no longer has block devices; we discussed the
-reasons for this on page
+kernel, and the term \fIdevice node\fP\/ is more accurate.  Conventionally, they
+are stored in the directory
+.Directory /dev .
+Some devices don't have device nodes, for example Ethernet interfaces: they are
+treated differently by the
+.Command ifconfig
+program.
+.P
+Traditional UNIX systems distinguish two types of device, \fIblock devices\fP\/
+and \fIcharacter devices\fP.  FreeBSD no longer has block devices; we discussed
+the reasons for this on page
 .Sref \*[block-device] .
-.X "major number"
-.X "minor number"
-.X "block device"
-.X "character device"
-.H3 "Major and minor numbers"
-Like all traditional UNIX systems, FreeBSD refers to devices by a \fImajor
-number\fP and a \fIminor number\fP.  The major number is in fact simply a number
-used to identify the driver, and the minor number is a number which the driver
-uses to distinguish the individual device and how it should treat it.
-.P
-Traditionally, major and minor numbers are stored in the same machine word.
-Originally, the word was 16 bits long, and the major and minor numbers were each
-8 bit quantities, which limited their maximum values to 255.  Then System V.4
-increased the word size to 32 bits, and gave 14 bits to the major numbers and 18
-bits to the minor numbers, giving maximum values of 16383 and 262143
-respectively.  4.4BSD also introduced 32 bit device numbers, but left the major
-number in the same place, and left it 8 bits long.  The minor number takes up
-the rest of the word, and is thus 24 bits long with a hole in the middle.
-Currently, Linux systems have the traditional 16 bit device number, but this may
-change in the future.
-.P
-Here's a overview:
-.PS
-h = .2i
-dh = .02i
-dw = .8i
-move.25i
-[
-        Caps: [
-                boxht = h; boxwid = dw
-		   box invis "\f(CWByte\fP"
-                A: box invis "\s10\f(CW0\fR\s0"
-                B: box invis "\s10\f(CW1\fR\s0"
-                C: box invis "\s10\f(CW2\fR\s0"
-                D: box invis "\s10\f(CW3\fR\s0"
-      ]
-        Trad: [
-                boxht = h; boxwid = dw
-		   box invis "traditional"
-		box invis
-		box invis
-                A: box "major"
-                B: box "minor"
-      ]   at Caps.s - (0, h)
-        SVR4: [
-		boxht = h; boxwid = dw
-		boxht = h;
-		box invis "System V.4"
-		box wid dw * 1.75 "major (14 bits)"
-                box wid dw * 2.25 "minor (18 bits)"
-      ]   at Trad.s - (0, h)
-        BSD44: [
-		boxht = h; boxwid = dw
-		box invis "FreeBSD"
-		box wid dw * 2 "more minor"
-		box "major"
-		box "minor"
-      ]   at SVR4.s - (0, h)
-]
-.PE
-.Figure-heading "Major and minor numbers"
-FreeBSD uses the high-order bits of the minor number for very special devices,
-such as control ports for disks.  Normally, you'll never see them, but if you
-\fIdo\fP\| find a minor number in the millions, it's not a bug, it's a feature.
-.H3 "devfs"
-Device nodes pose a problem: when you create them, how do you know what support
-is in the kernel?  What if you change the kernel?
-.P
-This is really a problem.  In particular, there are two different errors you
-might get when trying to access a special file:
-.Ls B
-.LI
-\f(CWENOENT\fP, ``no such file or directory'', means that there is no device
-node with this name.  This could happen if you add support to the kernel but
-don't create the device nodes.  We'll look at adding device nodes in the next
-section.
-.LI
-\f(CWENXIO\fP, ``device configured'', means that the device node exists, but the
-kernel does not have support for the device.  In this case you need to add
-support for the device, a topic we'll consider in \*[chbuild].
-.Le
-It's a problem not knowing which device nodes to create.  The install scripts
-make up for it by creating lots of device nodes for which there is no kernel
-support.  The standard install creates nearly 1000 device nodes.  Even this may
-not be enough.  For example, the system supports any combination of SCSI devices
-on a controller, up to fifteen of them, but the default configuration creates
-device nodes for only one tape and four disks.  If you add a second tape drive
-or a fifth SCSI disk, you will need to add device nodes to be able to talk to
-them.
-.P
-Version 5 of FreeBSD has addressed this issue with the \fIdevice file system\fP,
-also known as \fIdevfs\fP.  \fIdevfs\fP\| is a pseudo-file system which
-dynamically creates device nodes for exactly those devices which are in the
-kernel, which will make it unnecessary to manually create devices.
-.H3 "Creating device nodes"
-.Pn MAKEDEV
-.X "mknod command"
-.X "command, mknod"
-.X "/dev/MAKEDEV"
-.X "MAKEDEV, script"
-.X "script, MAKEDEV"
-.X "mknod, command"
-.X "command, mknod"
-So what if you need to create new device nodes?  The hard way uses the
-\fImknod\fP\| command (see the man page \fImknod(8)\fP\|).
-.X "/dev/MAKEDEV"
-The easy way uses the script \fI/dev/MAKEDEV\fP.  For example, by default
-FreeBSD only supplies definitions for four SCSI disks.  If you add a
-fifth SCSI disk, enter:
-.Dx
-# \f(CBcd /dev\fP
-# \f(CB./MAKEDEV da4\fP				\fIcreate the device\fP\|
-# \f(CB./MAKEDEV da4s0a\fP			\fIcreate the slice entries too\fP\|
-.De
-\fIMAKEDEV\fP\| assumes that you are in the \fI/dev\fP\| directory, as indicated
-in this example.
 .P
-The names that \fIMAKEDEV\fP\| chooses aren't the most intuitive.  You may have
-difficulty deciding how to tell it to build the devices you want.  Check the
-comments at the beginning of the file \fI/dev/MAKEDEV\fP\| itself for more
-details.  For example, if you wanted to create a second tape drive, you would
-find:
-.Dx
-# Device "make" file.  Valid arguments:
-#       all     makes all known devices, standard number of units (or close)
-#       std     standard devices
-#       jail    suitable for a jail(8)
-#       local   configuration specific devices
-\&...
-# Tapes:
-#       wt*     QIC-interfaced (e.g. not SCSI) 3M cartridge tape
-#       sa*     SCSI Sequential Access Devices
-.De
-The asterisk (\f(CW*\fP) after some names indicates that you should specify the
-number of devices to create, or in some cases the specific device number.  In
-this case, To create the device node for the second tape, you would enter:
-.Dx
-# \f(CBcd /dev\fP
-# \f(CB./MAKEDEV sa1\fP
-.De
-Also be careful of \f(CW./MAKEDEV all\fP: it first removes existing entries, so
-you might actually end up with fewer device nodes, not more.  If this happens to
-you, you can remake them again with a more specific application, such as in the
-example above.
+In traditional UNIX systems, including FreeBSD up to Release 4, it was necessary
+to create device nodes manually.  This caused a number of problems when they
+didn't match what was in the system.  Release 5 of FreeBSD has solved this
+problem with the \fIdevice file system\fP, also known as \fIdevfs\fP.
+\fIdevfs\fP\/ is a pseudo-file system that dynamically creates device nodes for
+exactly those devices that are in the kernel, which makes it unnecessary to
+manually create devices.
 .H3 "Overview of FreeBSD devices"
 .Pn FreeBSD-devices
 Every UNIX system has its own peculiarities when it comes to device names and
 usage.  Even if you're used to UNIX, you'll find the following table useful.
-.ad l
 .ne 1i
-.X "devices, overview"
-.TB "FreeBSD device names"
+.X "device, overview"
+.Table-heading "FreeBSD device names"
 .Tn FreeBSD-devices-table
 .TS H
-box,tab(#) ;
-| lfCWp9 | lw68 | .
-\s10\fRDevice#Description
-=
+tab(#) ;
+lfCWp9 | lw60 .
+\s10\fBDevice#\fBDescription
+_
 .TH N
 .\" XXX redo this if there's time
 .sp .3v
@@ -1067,8 +1101,11 @@
 T}
 .sp .3v
 ad0#T{
-First ata (IDE or similar) disk drive, block device.  See \*[chconcepts], page
-\*[disk-partitions], for a complete list of disk drive names.
+First ata (IDE or similar) disk drive.  See Chapter
+.Sref "\*[nchconcepts]" ,
+page
+.Sref \*[disk-partitions] ,
+for a complete list of disk drive names.
 T}
 .X "fd/0, device"
 .X "device, fd/0"
@@ -1078,15 +1115,15 @@
 .X "device, fd0c"
 .X "bpf0, device"
 .X "device, bpf0"
+.sp .3v
 bpf0#T{
-Berkeley packet filter\(emsee the description of \f(CWbpfilter\fP on page
-\*[config-bpfilter]
+Berkeley packet filter.
 T}
 .sp .3v
-.X "cd0a, device"
+.X "cd0, device"
 .X "device, cd0a"
-cd0a#T{
-First SCSI CD-ROM drive
+cd0#T{
+First SCSI CD-ROM drive.
 T}
 .sp .3v
 .X "ch0, device"
@@ -1098,14 +1135,15 @@
 .X "console, device"
 .X "device, console"
 console#T{
-System console, the device which receives console messages.  Initially it is
-\fI/dev/ttyv0\fP, but it can be changed
+System console, the device that receives console messages.  Initially it is
+.Device ttyv0 ,
+but it can be changed.
 T}
 .sp .3v
 .X "cuaa0, device"
 .X "device, cuaa0"
 cuaa0#T{
-First serial port in callout mode
+First serial port in callout mode.
 T}
 .sp .3v
 .X "cuaia0, device"
@@ -1125,39 +1163,34 @@
 .X "da0, device"
 .X "device, da0"
 da0#T{
-First SCSI disk drive, block device.  See \*[chconcepts], page \*[disk-partitions],
+First SCSI disk drive.  See Chapter
+.Sref "\*[nchconcepts]" ,
+page
+.Sref \*[disk-partitions] ,
 for a complete list of disk drive names.
 T}
 .sp .3v
 .X "esa0, device"
 .X "device, esa0"
 esa0#T{
-First SCSI tape drive, eject on close mode
+First SCSI tape drive, eject on close mode.
 T}
 .sp .3v
 .X "fd, device"
 .X "device, fd"
 fd#T{
-File descriptor pseudo-devices: a directory containing pseudo-devices which,
+File descriptor pseudo-devices: a directory containing pseudo-devices that,
 when opened, return a duplicate of the file descriptor with the same number.
-For example, if you open \fI/dev/fd/0\fP,
-you will get another handle on your
-\fIstdin\fP\| stream (file descriptor 0).
+For example, if you open
+.Device fd/0 ,
+you get another handle on your
+\fIstdin\fP\/ stream (file descriptor 0).
 T}
 .sp .3v
 .X "fd0, device"
 .X "device, fd0"
 fd0#T{
-The first floppy disk drive, accessed as a file system
-T}
-.sp .3v
-.X "fd0a, device"
-.X "device, fd0a"
-fd0a#T{
-The first floppy disk drive, accessed as a file system.  Floppy disks are not
-partitioned in the same way as hard disks, and the names \fIfd0a\fP, \fIfd0b\fP,
-\fIfd0c\fP, \fIfd0d\fP, \fIfd0e\fP, \fIfd0f\fP, \fIfd0g\fP, and \fIfd0h\fP\| all
-refer to the same device.
+The first floppy disk drive, accessed as a file system.
 T}
 .sp .3v
 .\" io
@@ -1165,152 +1198,235 @@
 .X "kmem, device"
 .X "device, kmem"
 kmem#T{
-Kernel virtual memory pseudo-device
-T}
-.sp .3v
-.\" log
-.X "bit bucket"
-.X "lpctl0, device"
-.X "device, lpctl0"
-lpctl0#T{
-Control port of first parallel printer
+Kernel virtual memory pseudo-device.
 T}
 .sp .3v
 .X "lpt0, device"
 .X "device, lpt0"
 lpt0#T{
-First parallel printer
+First parallel printer.
 T}
 .sp .3v
 .X "mem, device"
 .X "device, mem"
 mem#T{
-Physical virtual memory pseudo-device
+Physical virtual memory pseudo-device.
 T}
 .sp .3v
 .X "nsa0, device"
 .X "device, nsa0"
 nsa0#T{
-First SCSI tape drive, no-rewind mode
-T}
-.sp .3v
-.X "nwt0, device"
-.X "device, nwt0"
-nwt0#T{
-First QIC-36 tape drive, no-rewind mode
+First SCSI tape drive, no-rewind mode.
 T}
 .sp .3v
 .X "null, device"
 .X "device, null"
 null#T{
-The ``bit bucket''.  Write data to this device if you never want to see it
+The ``bit bucket.''  Send data to this device if you never want to see it
 again.
 T}
 .sp .3v
+.X "psm0, device"
+.X "device, psm0"
+psm0#T{
+PS/2 mouse.
+T}
+.sp .3v
 .X "ptyp0, device"
 .X "device, ptyp0"
 ptyp0#T{
-First master pseudo-terminal.  Master pseudo-terminals are named \fIptyp0\fP\|
-through \fIptypv\fP, \fIptyq0\fP\| through \fIptyqv\fP, \fIptyr0\fP\| through
-\fIptyrv\fP, \fIptys0\fP\| through \fIptysv\fP, \fIptyP0\fP\| through
-\fIptyPv\fP, \fIptyQ0\fP\| through \fIptyQv\fP, \fIptyR0\fP\| through
-\fIptyRv\fP and \fIptyS0\fP\| through \fIptySv\fP.
+First master pseudo-terminal.  Master pseudo-terminals are named
+.Device -n ptyp0
+through
+.Device -n ptypv ,
+.Device -n ptyq0
+through
+.Device -n ptyqv ,
+.Device -n ptyr0
+through
+.Device -n ptyrv ,
+.Device -n ptys0
+through
+.Device -n ptysv ,
+.Device -n ptyP0
+through
+.Device -n ptyPv ,
+.Device -n ptyQ0
+through
+.Device -n ptyQv ,
+.Device -n ptyR0
+through
+.Device -n ptyRv
+and
+.Device -n ptyS0
+through
+.Device -n ptySv .
+T}
+.sp .3v
+.X "random, device"
+.X "device, random"
+random#T{
+Random number generator.
 T}
 .sp .3v
 .Pn sa0
 .X "sa0, device"
 .X "device, sa0"
 sa0#T{
-First SCSI tape drive, rewind on close mode
+First SCSI tape drive, rewind on close mode.
 T}
 .sp .3v
-.X "speaker, device"
-.X "device, speaker"
-speaker#T{
-PC speaker device
+.X "sysmouse, device"
+.X "device, sysmouse"
+sysmouse#T{
+System mouse, controlled by
+.Daemon moused .
+We'll look at this again on page
+.Sref \*[XF86Config-InputDevice-section] .
 T}
 .sp .3v
 .X "tty, device"
 .X "device, tty"
 tty#T{
-Current controlling terminal
+Current controlling terminal.
 T}
 .sp .3v
 .X "ttyd0, device"
 .X "device, ttyd0"
 ttyd0#T{
-First serial port in callin mode
+First serial port in callin mode.
 T}
 .sp .3v
 .X "ttyid0, device"
 .X "device, ttyid0"
 ttyid0#T{
-First serial port in callin mode, initial state
+First serial port in callin mode, initial state.
 T}
 .sp .3v
 .X "ttyld0, device"
 .X "device, ttyld0"
 ttyld0#T{
-First serial port in callin mode, lock state
+First serial port in callin mode, lock state.
 T}
 .sp .3v
 .Pn pty-devname
 .X "ttyp0, device"
 .X "device, ttyp0"
 ttyp0#T{
-First slave pseudo-terminal.  Slave pseudo-terminals are named \fIttyp0\fP\| through
-\fIttypv\fP, \fIttyq0\fP\| through \fIttyqv\fP, \fIttyr0\fP\| through
-\fIttyrv\fP, \fIttys0\fP\| through \fIttysv\fP, \fIttyP0\fP\| through
-\fIttyPv\fP, \fIttyQ0\fP\| through \fIttyQv\fP, \fIttyR0\fP\| through
-\fIttyRv\fP and \fIttyS0\fP\| through \fIttySv\fP.  Some processes, such as
-\fIxterm\fP, only look at \fIttyp0\fP\| through \fIttysv\fP.
+First slave pseudo-terminal.  Slave pseudo-terminals are named
+.Device -n ttyp0
+through
+.Device -n ttypv ,
+.Device -n ttyq0
+through
+.Device -n ttyqv ,
+.Device -n ttyr0
+through
+.Device -n ttyrv ,
+.Device -n ttys0
+through
+.Device -n ttysv ,
+.Device -n ttyP0
+through
+.Device -n ttyPv ,
+.Device -n ttyQ0
+through
+.Device -n ttyQv ,
+.Device -n ttyR0
+through
+.Device -n ttyRv
+and
+.Device -n ttyS0
+through
+.Device -n ttySv .
+Some processes, such as
+.Command -n xterm ,
+only look at
+.Device -n ttyp0
+through
+.Device -n ttysv .
 T}
 .sp .3v
 .X "ttyv0, device"
 .X "device, ttyv0"
-.X "/etc/ttys"
 ttyv0#T{
 First virtual tty.  This is the display with which the system starts.  Up to 10
-virtual ttys can be activated by adding the appropriate \fIgetty\fP\|
-information in the file \fI/etc/ttys\fP.  See \*[chmodems], page \*[dialin], for
+virtual ttys can be activated by adding the appropriate
+.Command getty
+information in the file
+.File /etc/ttys .
+See Chapter
+.Sref "\*[nchmodems]" ,
+page
+.Sref \*[dialin] ,
+for
 further details.
 T}
 .sp .3v
-.\" tun0#T{
-.\" Tunnel driver, used for
-.X "tw0, device"
-.X "device, tw0"
-tw0#T{
-TW-523 power line interface driver
+ugen0#T{
+First generic USB device.
+T}
+.sp .3v
+ukbd0#T{
+First USB keyboard.
+T}
+.sp .3v
+ulpt0#T{
+First USB printer.
+T}
+.sp .3v
+umass0#T{
+First USB mass storage device.
+T}
+.sp .3v
+ums0#T{
+First USB mouse.
+T}
+.sp .3v
+uscanner0#T{
+First USB scanner.
+T}
+.sp .3v
+vinum#T{
+Directory for Vinum device nodes.  See Chapter
+.Sref "\*[nchvinum]" ,
+for further details.
 T}
 .sp .3v
 .X "zero, device"
 .X "device, zero"
 zero#T{
-Dummy device which always returns the value \f(CW0\fP when read
+Dummy device that always returns the value (binary) \f(CW0\fP when read.
 T}
+_
 .TE
 .sp 1.5v
-You'll note a number of different modes associated with the serial ports.  See
-\&\*[chmodems], page \*[serial-hardware], for more details.
-.ad b
+You'll note a number of different modes associated with the serial ports.  We'll
+look at them again in Chapter
+.Sref "\*[nchmodems]" .
 .H2 "Virtual terminals"
 .Pn vt
 .X "virtual terminal"
 .X "terminal, virtual"
-.X "/dev/ttyv0"
-.X "/etc/ttys"
 As we have seen, UNIX is a multitasking operating system, but a PC generally
 only has one screen.  FreeBSD solves this problem with \fIvirtual
 terminals\fP.  When in text mode, you can change between up to 16 different
 screens with the combination of the \fBAlt\fP key and a function key.  The
-devices are named \fI/dev/ttyv0\fP\| through \fI/dev/ttyv15\fP, and
-correspond to the keystrokes \fBAlt-F1\fP through \fBAlt-F16\fP.  By default,
-three virtual terminals are active: \fI/dev/ttyv0\fP\| through
-\fI/dev/ttyv2\fP.  The system console is the virtual terminal
-\fI/dev/ttyv0\fP, and that's what you see when you boot the machine.  To
-activate additional virtual terminals, edit the file \fI/etc/ttys\fP.  There
-you will find:
+devices are named
+.Device ttyv0
+through
+.Device ttyv15 ,
+and correspond to the keystrokes \fBAlt-F1\fP through \fBAlt-F16\fP.  By
+default, three virtual terminals are active:
+.Device ttyv0
+through
+.Device ttyv2 .
+The system console is the virtual terminal
+.Device ttyv0 ,
+and that's what you see when you boot the machine.  To
+activate additional virtual terminals, edit the file
+.File /etc/ttys .
+There you find:
 .Dx
 ttyv0	"/usr/libexec/getty Pc"		cons25	on  secure
 .\" # Virtual terminals
@@ -1320,90 +1436,43 @@
 .De
 The keywords \f(CWon\fP and \f(CWoff\fP refer to the state of the terminal: to
 enable one, set its state to \f(CWon\fP.  To enable extra virtual terminals, add
-a line with the corresponding terminal name, in the range \fI/dev/ttyv4\fP\| to
-\fI/dev/ttyv15\fP.
-.P
-.X "/dev"
-.X "/dev/MAKEDEV"
-.X "mknod, command"
-.X "getty, dmon"
-.X "command, mknod"
-.X "dmon, getty"
-In addition, you may need to create the device nodes if they don't already
-exist.  By default, the system contains four virtual terminal devices in the
-\fI/dev\fP\| directory.  If you use more than this number, you must create them,
-either with \fIMAKEDEV\fP\| (see page \*[MAKEDEV]), or with \fImknod\fP\| (see
-page \fImknod(8)\fP\|).  When calculating how many devices you need, note that
-if you intend to run X11, you need a terminal device without a \fIgetty\fP\| for
-the X server.  For example, if you have enabled \fI/dev/ttyv3\fP,
-\fI/dev/ttyv4\fP, and \fI/dev/ttyv5\fP, and you also want to run X, you will
-need a total of 7 virtual terminals (\fI/dev/ttyv0\fP\| through
-\fI/dev/ttyv6\fP\|).  With \fIMAKEDEV\fP, you specify how many virtual terminals
-you need:
-.Dx
-# \f(CBcd /dev\f(CW
-# \f(CB./MAKEDEV vty7		\fImake 7 vtys\f(CW
-.De
-Alternatively, you can do this with \fImknod\fP\|:
-.Dx
-# \f(CBcd /dev\f(CW
-# \f(CBls -l ttyv0\f(CW
-crw-------  1 root  wheel   12,   0 Nov 28 10:25 ttyv0
-# \f(CBmknod ttyv3 c 12 3\f(CW
-# \f(CBmknod ttyv4 c 12 4\f(CW
-# \f(CBmknod ttyv5 c 12 5\f(CW
-# \f(CBmknod ttyv6 c 12 6\f(CW
-.De
-.X "major device number"
-.X "mknod"
-In this example, you list the entry for \fI/dev/ttyv0\fP\| in order to check the
-\fImajor device number\fP\| of the virtual terminals (that's the \f(CW12,\fP in
-this example; it may change from one release to another).  You need to specify
-this number to \fImknod\fP.  For more details about major and minor device
-numbers, see page \*[devices].
-.P
-.X "/etc/ttys"
-After you have edited \fI/etc/ttys\fP, and possibly created the device nodes,
+a line with the corresponding terminal name, in the range
+.Device ttyv4
+to
+.Device ttyv15 .
+After you have edited
+.File /etc/ttys ,
 you need to tell the system to re-read it in order to start the terminals.  Do
 this as \f(CWroot\fP with this command:
 .Dx
 # \f(CBkill -1 1\fP
 .De
-.X "init command"
-.X "command, init"
-Process 1 is \fIinit\fP\|\(emsee page \*[init] for more details.
+Process 1 is
+.Daemon init
+\(emsee page
+.Sref \*[init] \&
+for more details.
 .H3 "Pseudo-terminals"
 .Pn ptys
 .X "pty"
 .X "pity"
 .X "pseudo-terminal"
 .X "master device"
-.X "/dev/ptyp0"
 .X "slave device"
-.X "/dev/ttyp0"
 In addition to virtual terminals, FreeBSD offers an additional class of
 terminals called \fIpseudo-terminals\fP.  They come in pairs: a \fImaster
-device\fP, also called a \fIpty\fP\| (pronounced \fIpity\fP) is used only by
-processes which use the interface, and has a name like \fI/dev/ptyp0\fP.  The
-\fIslave device\fP\| looks like a terminal, and has a name like
-\fI/dev/ttyp0\fP.  Any process can open it without any special knowledge of the
-interface.  These terminals are used for network connections such as
-\fIxterm\fP, \fItelnet\fP\| and \fIrlogin\fP.  You don't need a \fIgetty\fP\|
-for pseudo-terminals.
-.P
-You need one pseudo-terminal for each terminal-like connection, for example for
-an \fIxterm\fP.  It's quite easy to run out of them; if you do, you can
-configure more\(emsee page \*[config-pty].  In addition, generate the device
-nodes.  For example, to generate a second set of 32 pseudo-terminals, enter:
-.Dx
-# \f(CBcd /dev\fP
-# \f(CB./MAKEDEV pty1\fP
-.De
-You can generate up to 256 pseudo-terminals.  They are named \fIttyp0\fP\|
-through \fIttypv\fP, \fIttyq0\fP\| through \fIttyqv\fP, \fIttyr0\fP\| through
-\fIttyrv\fP, \fIttys0\fP\| through \fIttysv\fP, \fIttyP0\fP\| through
-\fIttyPv\fP, \fIttyQ0\fP\| through \fIttyQv\fP, \fIttyR0\fP\| through
-\fIttyRv\fP and \fIttyS0\fP\| through \fIttySv\fP.  To create each set of 32
-terminals, use the number of the set: the first set is \f(CWpty0\fP, and the
-eighth set is \f(CWpty7\fP.  Note that some processes, such as \fIxterm\fP, only
-look at \fIttyp0\fP\| through \fIttysv\fP.
+device\fP, also called a \fIpty\fP\/ (pronounced \fIpity\fP\/) is used only by
+processes that use the interface, and has a name like
+.Device ptyp0 .
+The \fIslave device\fP\/ looks like a terminal, and has a name like
+.Device ttyp0 .
+Any process can open it without any special knowledge of the interface.  These
+terminals are used for network connections such as
+.Command xterm ,
+.Command telnet
+and
+.Command rlogin .
+You don't need a
+.Command getty
+for pseudo-terminals.  Since FreeBSD Release 5.0, pseudo-terminals are created
+as required.
