Conditionalize keyboard layout change
[ikiwiki.git] / docs / newhandbook / UnixBasics / index.mdwn
index b2060bb..f15e369 100644 (file)
@@ -64,7 +64,7 @@ This is the part where you are supposed to type in your <i>username</i> to log i
 
 ### Logging into DragonFly 
 
-DragonFly is a multiuser, multiprocessing system. This is the formal description that is usually given to a system that can be used by many different people, who simultaneously run a lot of programs on a single machine. Every multiuser system needs some way to distinguish one <i>user</i>from the rest. In !DragonFly (and all the UNIX-like operating systems), this is accomplished by requiring that every user must ***log into*** the system before being able to run programs. Every user has a unique name (the <i>username</i> and a personal, secret key (the <i>password</i>). DragonFly will ask for these two before allowing a user to run any programs.
+DragonFly is a multiuser, multiprocessing system. This is the formal description that is usually given to a system that can be used by many different people, who simultaneously run a lot of programs on a single machine. Every multiuser system needs some way to distinguish one <i>user</i>from the rest. In DragonFly (and every other kind of UNIX and UNIX-like operating system), this is accomplished by requiring that every user must <i>log into</i>  the system before being able to run programs. Every user has a unique name (the <i>username</i> and a personal, secret key (the <i>password</i>). DragonFly will ask for these two before allowing a user to run any programs.
 
 Right after DragonFly boots and finishes running its startup scripts[(2)](#FTN.AEN1060), it will present you with a prompt and ask for a valid username: 
 
@@ -222,7 +222,7 @@ To disable the system undeletable flag, simply issue the previous command with *
 
     # chflags nosunlink file1
 
-To view the flags of this file, use the [ls(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=ls&amp;section1) with the `-lo` flags:
+To view the flags of this file, use the [ls(1)](http://leaf.dragonflybsd.org/cgi/web-man?command=ls&amp;section1) command with the `-lo` flags:
 
     
 
@@ -328,318 +328,222 @@ Or `C` could be mounted directly on to the `A` file system, under the `A1` direc
 <!-- XXX: image -->
 
 If you are familiar with MS-DOS, this is similar, although not identical, to the `join` command.
+### The fstab File 
 
-## Choosing File System Layout 
-
-This is not normally something you need to concern yourself with. Typically you create file systems when installing DragonFly and decide where to mount them, and then never change them unless you add a new disk.
-
-It is entirely possible to have one large root file system, and not need to create any others. There are some drawbacks to this approach, and one advantage.
-
- **Benefits of Multiple File Systems** 
-
-* Different file systems can have different ***mount options***.  For example, with careful planning, the root file system can be mounted read-only, making it impossible for you to inadvertently delete or edit a critical file.  Separating user-writable file systems, such as `/home`, from other file systems also allows them to be mounted ***nosuid***; this option prevents the ***suid***/***guid*** bits on executables stored on the file system from taking effect, possibly improving security.
-
-* The UFS file system automatically optimizes the layout of files, depending on how the file system is being used. So a file system that contains many small files that are written frequently will have a different optimization to one that contains fewer, larger files.  By having one big file system this optimization breaks down.
-
-* DragonFly's file systems are very robust should you lose power.  However, a power loss at a critical point could still damage the structure of the file system.  By splitting your data over multiple file systems it is more likely that the system will still come up, making it easier for you to restore from backup as necessary. This a major reason to make the root file system of limited size, and with low write activity.
-
- **Benefit of a Single File System** 
-
-* File systems are a fixed size. If you create a file system when you install DragonFly and give it a specific size, you may later discover that you need to make the partition bigger.  The [growfs(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=growfs&amp;section8) command makes it possible to increase the size of a UFS file system on the fly.
-<!-- XXX: what about hammer? -->
-
-## Disk Slices, Partitions and local UNIX file systems 
-
-Here we describe how disks are subdivided.
-
-<!-- XXX: mention serno stuff -->
-
-### Slices 
-
-A disk can be subdivided in slices.
-
-Slices are named `s0`, `s1` and so on.
-
-For example the disk `ad6` can contain the slice `ad6s3`.
-
-DragonFly support two schemes for slices, MBR and GPT, either of them will manage all slices on a disk:
-
-* MBR: set up using [fdisk(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fdisk&amp;section8), can be up to 2 TB in size.  MBR slices are numbered from 1; but if disk is ***dangerously dedicated*** it has slice number 0.
-
-* GPT: set up using [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section8), can be extremely large: size up to 8 billion TB.  DragonFly doesn't support booting from a GPT slice in DragonFly  2.0.  Note that GPT slices are numbered from 0. ***Dangerously dedicated*** is not supported nor needed for GPT.  DragonFly 2.1 does have some support for booting from a GPT slice, this is described in [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section=8).
-
-### Partitions 
-
-Partitions are contained in slices.
-
-Partitions are named `a`, `b` and so on.
-
-DragonFly support 16 partitions per slice, that is `a` through `p`.
-
-For example the partition `ad6s3a` is contained in the slice `ad6s3`.
-
-Partition layout is defined in a label on the slice where the partition reside. DragonFly support two types of disk labels, disklabel32 and disklabel64 (the default):
-
-* [disklabel32(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&amp;section8): 32 bit disk label which can use slices with size up to 2 TB.
-
-* [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8): 64 bit disk label which can use very large slices: size up to 16 million TB.
-
-### Local UNIX file systems 
-
-File systems are contained in partitions.  Each partition can contain only one file system, which means that file systems often are described by either their typical mount point in the file system hierarchy, or the letter of the partition they are contained in.  ***Partition*** does not have the same meaning as the common usage of the term partition (for example, MS-DOS partition), because of DragonFly's UNIX┬« heritage.
-
-DragonFly support two local UNIX file systems, UFS and HAMMER:
-
-* UFS: The classical BSD UNIX file system, see [ffs(5)](http://leaf.dragonflybsd.org/cgi/web-man?command#ffs&amp;section5), it supports size up to 2 TB.
-
-* [HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5): A new file system, as of DragonFly 2.0, with many advanced features.  HAMMER file system support size up to 1 million TB.
-
-### Typical disk layout 
-
-From the above we see the following typical disk layout scenarios:
-
-* For booting DragonFly from a local file system UFS is recommended.  A BOOT+HAMMER setup is recommended for HAMMER use, this consists of a small UFS file system for booting, typically 512MB, and a HAMMER root file system.  The BOOT file system is mounted as /boot after boot.
-
-* For moderate storage requirements UFS can be used; it can be setup on any partition, e.g. on the same disk slice as the boot partition.  HAMMER is an alternative, with extra features supported, like history retention.  You should evaluate if HAMMER is suitable, see note below.
-
-* If really big storage capacity is needed UFS can't fit the need.  You should evaluate if HAMMER is suitable, see note below.  For this use HAMMER needs to be used on a GPT slice with  a [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8) label.  In DragonFly 2.0 it has to be set up on a disk separate from the boot disk.  In  DragonFly 2.1 one disk can be used for both booting and HAMMER file system on GPT slice, as some support for booting from GPT is present, as described in [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section=8).
-
-### HAMMER Note 
-
-[HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5)
-
-is a rather new file system, under active development.
-
-As of DragonFly 2.2.1 release HAMMER is considered production ready.  At 2.0 release it was considered to be in an early Beta state .
-
-All major features except the mirroring are quite well tested as-of the 2.2.1 release.
-
-You should evaluate if HAMMER is suitable for your needs.
-<!-- XXX: mention disk and memory requirements for efficient hammer use -->
-
-Examples of ongoing development includes:
-
-* Making HAMMER more self managing; e.g. ability to setup policy for which history to save for how long: e.g. make snapshot every hour and prune and reblock the file system regularly.  When snapshot gets older than 1 month only keep them for every 6 hours; when older than 3 months only keep snapshot for every 24 hours, when older than 3 years only keep snapshot per month.  For now you need to set up [cron(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=cron&amp;section8) jobs for this yourself, see [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8).
+During the [boot process](boot.html), file systems listed in `/etc/fstab` are automatically mounted (unless they are listed with the `noauto` option).
 
-* Multi master mirroring. For now only one mirror master is supported, but multiple mirror targets, called slaves, are already supported.
+The `/etc/fstab` file contains a list of lines of the following format:
+  
 
-* Support for shrinking existing HAMMER file systems.  The HAMMER design is prepared for this, utility just have to be written to support it.
-<!-- XXX: is this still accurate? Do we really want to mention it here? -->
+    device       mount-point   fstype     options      dumpfreq     passno
 
-### HAMMER Features 
+These parameters have the following meaning:
 
-[HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5) has several advanced features not found in UFS:
+* `device`: A device name (which should exist), as explained [here](disks-naming.html).
 
-* Large file systems:  Up to 1 million TB, also called 1 Exabyte is supported.
+* `mount-point`: A directory (which should exist), on which to mount the file system.
 
-* Multiple volumes:  A HAMMER file system can span up to 256 disks, each partition part of a HAMMER file system is called a volume.  Each volume can be up to 4096 TB in size.
+* `fstype`: The file system type to pass to [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8). The default DragonFly file system is `ufs`.
 
-* Support for growing and shrinking existing HAMMER file systems: adding and removing volumes from the file system.  As of 2.4 release an existing HAMMER file system can be expanded by adding extra space, see the `expand` directive to [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8).  The HAMMER design is also prepared for removing volumes, utilities just have to be written to support it.
+* `options`: Either `rw` for read-write file systems, or `ro` for read-only file systems, followed by any other options that may be needed. A common option is `noauto` for file systems not normally mounted during the boot sequence. Other options are listed in the [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) manual page.
 
-* Instant crash recovery:  If a crash should occur, then HAMMER file systems will be ready a few seconds after boot, no lenghty fsck have to be run.
+* `dumpfreq`: This is used by [dump(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=dump&section8) to determine which file systems require dumping. If the field is missing, a value of zero is assumed.
 
-* Full history retention:  All file system changes are saved every ~30 seconds.  Changes are written at least when sync() is called, see [syncer(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=syncer&amp;section4).  Every time data for files are written to disk a transaction is completed, this is assigned an ID and the file updated can after this be accessed with the contents from this moment.  To access the file with the state of this moment, the transaction ID, TID for brevity, just needs to be added to the file name, like: 'file@@<TID>'.  The TID can be saved from the 'snapshot', 'cleanup', or 'synctid' [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8) command or looked up with the 'hammer history file' command.  This history will typically grow over time, so any disk will fill up over time.  Two things are done so disks doesn't fill up: first: big disks are used, at least 50GB is typical for HAMMER file systems, and second: unused history information is deleted regularly. Here we need to define what unused means: a TID is used if a snapshot have been taken on it. Data assigned to unused history can be reclaimed using the `prune` and `reblock` [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8) commands, this will also defragment the file system and can be done while the file system is in normal operation.  Generally after file system is pruned only TIDs for the snapshots or newer than newest shapshot should be used, see explanation [here](http://leaf.dragonflybsd.org/mailarchive/bugs/2008-07/msg00213.html) (more info on HAMMER design [here](http://leaf.dragonflybsd.org/mailarchive/kernel/2008-07/msg00114.html)).  See also [hammer(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=5). 
+* `passno`: This determines the order in which file systems should be checked. File systems that should be skipped should have their `passno` set to zero. The root file system (which needs to be checked before everything else) should have its `passno` set to one, and other file systems' `passno` should be set to values greater than one. If more than one file systems have the same `passno` then [fsck(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fsck&section8) will attempt to check file systems in parallel if possible.
 
-* Mirroring:  A master file system can be mirrored online to a number of slave file systems.  Mirror targets are read-only, but does have history available.  History retension policy can even be different on slaves and master.  Mirroring can be over network and unreliable connections are handled gracefully.
+Consult the [fstab(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=fstab&section5) manual page for more information on the format of the `/etc/fstab` file and the options it contains.
 
-* Data integrity:  HAMMER has high focus in data integrity and implements a CRC checksum on all data, this means that if disk fails with bit errors it will be detected.
+### The mount Command 
 
-More info on HAMMER can be found [here](http://www.dragonflybsd.org/hammer/index.html).
+The [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) command is what is ultimately used to mount file systems.
 
-DragonFly also uses disk space for ***swap space***.  Swap space provides DragonFly with ***virtual memory***.  This allows your computer to behave as though it has much more memory than it actually does.  When DragonFly runs low on memory it moves some of the data that is not currently being used to the swap space, and moves it back in (moving something else out) when it needs it.
+In its most basic form, you use:
 
-<!-- XXX: mention swapcache, and also how to configure and use it (somewhere else, probably) -->
+    
 
-### Adding a Disk 
+    # mount device mountpoint
 
-Adding a disk is done by installing it physically, and to connect it to a disk controller that DragonFly supports.  If you are in doubt if controller is supported, manual pages for disk controllers can be consulted ('man -k disk' or 'man -k scsi' can be of help).  The easiest thing is normally to boot DargonFly with the controller installed and note if boot message contains the controller.
+Or, if `mountpoint` is specified in `/etc/fstab`, just:
 
-Assuming that disk `ad6` is installed, we could set it up using [fdisk(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fdisk&amp;section8) and  disklabel(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&amp;section8) or  [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section8) and 
-[disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8).
+    
 
-In this example we choose [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section=8) & [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section=8).
+    # mount mountpoint
 
-<!-- XXX: mention that disklabel64 is default now -->
-    
+There are plenty of options, as mentioned in the [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) manual page, but the most common are:
 
-    # gpt -v create ad6
+ **Mount Options** 
 
-    ...
+* `-a`: Mount all the file systems listed in `/etc/fstab`. Except those marked as `noauto`, excluded by the `-t` flag, or those that are already mounted.
 
-    # gpt add -s1 ad6
+* `-d`: Do everything except for the actual mount system call. This option is useful in conjunction with the `-v` flag to determine what [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) is actually trying to do.
 
-    ad6s0
+* `-f`: Force the mount of an unclean file system (dangerous), or forces the revocation of write access when downgrading a file system's mount status from read-write to read-only.
 
-    # gpt add ad6
+* `-r`: Mount the file system read-only. This is identical to using the `rdonly` argument to the `-o` option.
 
-    ad6s1
+* `-t` ***fstype***: Mount the given file system as the given file system type, or, if used with `-a` option, mount only file systems of the given type. `ufs` is the default file system type.
 
-    # gpt show ad6
+* `-u`: Update mount options on the file system.
 
-    ...
+* `-v`: Be verbose.
 
-Here we first create the GPT and then add two slices.  In this example the first slice added is `ad6s0`, which is made a dummy slice of size 1 sector, this is just for not having to make further reference to it, as many users remembers that `s0` has special meaning, which really isn't true for GPT slices.  The second slice is `ad6s1` which will cover the rest of the disk.
+* `-w`: Mount the file system read-write.
 
-    
+The `-o` option takes a comma-separated list of the options, including the following:
 
-    # disklabel64 -rw ad6s1 auto
+* `nodev:` Do not interpret special devices on the file system. This is a useful security option.
 
-    # disklabel64 -e ad6s1          # edit label to add partitions as needed
+* `noexec`: Do not allow execution of binaries on this file system. This is also a useful security option.
 
-### disklabel 
-<!-- XXX: what is all this fuzz about dangerously dedicated? -->
+* `nosuid`: Do not interpret setuid or setgid flags on the file system. This is also a useful security option.
 
-For [disklabel(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&amp;section8) labels some partitions have certain conventions associated with them.
+### The umount Command 
 
-[[!table  data="""
-<tablestyle="width:100%"> Partition | Convention 
-<tablestyle="width:100%"> `a` | Normally contains the root file system 
- `b` | Normally contains swap space 
- `c` | Normally the same size as the enclosing slice.  This allows utilities that need to work on the entire slice (for example, a bad block scanner) to work on the `c` partition. You would not normally create a file system on this partition. This is not necessarily true; it is possible to use the 'c' partition as a normal partition.
- `d` | Partition `d` used to have a special meaning associated with it, although that is now gone.  To this day, some tools may operate oddly if told to work on partition `d`. |
+The [umount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=umount&section8) command takes, as a parameter, one of a mountpoint, a device name, or the `-a` or `-A` option.
 
-"""]]
+All forms take `-f` to force unmounting, and `-v` for verbosity. Be warned that `-f` is not generally a good idea. Forcibly unmounting file systems might crash the computer or damage data on the file system.
 
-Each partition-that-contains-a-file-system is stored in what DragonFly calls a ***slice***.  Slice is DragonFly's term for what the common call partitions, and again, this is because of DragonFly's UNIX background.  Slices are numbered, starting at 1.
+`-a` and `-A` are used to unmount all mounted file systems, possibly modified by the file system types listed after `-t`. `-A`, however, does not attempt to unmount the root file system.
 
-Slice numbers follow the device name, prefixed with an `s`, starting at 1. So ***da0s1*** is the first slice on the first SCSI drive. There can only be four physical slices on a disk, but you can have logical slices inside physical slices of the appropriate type.  These extended slices are numbered starting at 5, so ***ad0s5*** is the first extended slice on the first IDE disk. These devices are used by file systems that expect to occupy a slice.
+## Choosing File System Layout 
 
-<!-- XXX: gpt allows for way more than 4 partitions... let's remove this stuff above -->
+This is not normally something you need to concern yourself with. Typically you create file systems when installing DragonFly and decide where to mount them, and then never change them unless you add a new disk.
 
-***Dangerously dedicated*** physical drives are accessed as slice 0.
+It is entirely possible to have one large root file system, and not need to create any others. There are some drawbacks to this approach, and one advantage.
 
-Slices, ***dangerously dedicated*** physical drives, and other drives contain ***partitions***, which are represented as letters from `a` to `p`.  This letter is appended to the device name, so ***da0s0a*** is the a partition on the first da drive, which is ***dangerously dedicated***. ***ad1s3e*** is the fifth partition in the third slice of the second IDE disk drive.
+ **Benefits of Multiple File Systems** 
 
-Finally, each disk on the system is identified.  A disk name starts with a code that indicates the type of disk, and then a number, indicating which disk it is.  Disk numbering starts at 0. Common codes that you will see are listed in [Table 3-1](disk-organization.html#BASICS-DEV-CODES).
+* Different file systems can have different ***mount options***.  For example, with careful planning, the root file system can be mounted read-only, making it impossible for you to inadvertently delete or edit a critical file.  Separating user-writable file systems, such as `/home`, from other file systems also allows them to be mounted ***nosuid***; this option prevents the ***suid***/***guid*** bits on executables stored on the file system from taking effect, possibly improving security.
 
-<!-- XXX: here would probably be the right place to talk about serno -->
+* The UFS file system automatically optimizes the layout of files, depending on how the file system is being used. So a file system that contains many small files that are written frequently will have a different optimization to one that contains fewer, larger files.  By having one big file system this optimization breaks down.
 
-When referring to a partition DragonFly requires that you also name the slice and disk that contains the partition, and when referring to a slice you should also refer to the disk name. Do this by listing the disk name, `s`, the slice number, and then the partition letter.  Examples are shown in [Example 3-1](disk-organization.html#BASICS-DISK-SLICE-PART).
+* DragonFly's file systems are very robust should you lose power.  However, a power loss at a critical point could still damage the structure of the file system.  By splitting your data over multiple file systems it is more likely that the system will still come up, making it easier for you to restore from backup as necessary. This a major reason to make the root file system of limited size, and with low write activity.
 
-<!-- XXX: later talk also about devfs, definitely not here though. also, devfs rules -->
+ **Benefit of a Single File System** 
 
-[Example 3-2](disk-organization.html#BASICS-CONCEPT-DISK-MODEL) shows a conceptual model of the disk layout that should help make things clearer.
+* File systems are a fixed size. If you create a file system when you install DragonFly and give it a specific size, you may later discover that you need to make the partition bigger.  The [growfs(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=growfs&amp;section8) command makes it possible to increase the size of a UFS file system on the fly.
+<!-- XXX: what about hammer? -->
 
-In order to install DragonFly you must first configure the disk slices, then create partitions within the slice you will use for DragonFly, and then create a file system (or swap space) in each partition, and decide where that file system will be mounted.
+## Disk Slices, Partitions and local UNIX file systems 
+*** Heavily edited by Nick Matavka***
 
-***'Table 3-1. Disk Device Codes***'
+DragonFly BSD divides disks into partitions and slices; it refers to locations on a disk by means of their unique codes.  For instance, the disk code `ad1s3d` has a clear meaning: IDE hard disk one, slice three, root file system.  Meanings for other such codes will become apparent by the end of this section; first of all come the meanings for the physical drive codes.  The most common are:
 
 [[!table  data="""
 <tablestyle="width:100%"> Code | Meaning 
 <tablestyle="width:100%"> `ad` | ATAPI (IDE) disk 
- `da` | SCSI direct access disk 
- `acd` | ATAPI (IDE) CDROM 
- `cd` | SCSI CDROM 
- `vn` | Virtual disk
- `fd` | Floppy disk |
-
-"""]]
-
-***'Example 3-1. Sample Disk, Slice, and Partition Names***'
-
-[[!table  data="""
-<tablestyle="width:100%"> Name | Meaning 
-<tablestyle="width:100%"> `ad0s1a` | The first partition (`a`) on the first slice (`s1`) on the first IDE disk (`ad0`). 
- `da1s2e` | The fifth partition (`e`) on the second slice (`s2`) on the second SCSI disk (`da1`). |
-
+`da` | SCSI direct access disk 
+`acd` | ATAPI (IDE) CDROM 
+`cd` | SCSI CDROM 
+`vn` | Virtual disk
+`fd` | Floppy disk |
 """]]
 
-***'Example 3-2. Conceptual Model of a Disk***'
 
-This diagram shows DragonFly's view of the first IDE disk attached to the system. Assume that the disk is 4 GB in size, and contains two 2 GB slices (MS-DOS partitions).  The first slice contains a MS-DOS disk, `C:`, and the second slice contains a DragonFly installation. This example DragonFly installation has three partitions, and a swap partition.
 
-The three partitions will each hold a file system. Partition `a` will be used for the root file system, `e` for the `/var` directory hierarchy, and `f` for the `/usr` directory hierarchy.
 
-<!-- XXX: image -->
+### Slices 
 
-## Mounting and Unmounting File Systems 
+In BSD UNIX, including DragonFly, what are elsewhere known as ***partitions*** are instead known as ***slices***; on a multi-boot system, every operating system occupies at least one slice and is aware of the others.  Linux, and most UNIX operating systems, generally occupy at least two slices, one for the file system and one for swap space; on the other hand, BSD (with the exception of MacOS/DarwinBSD) may occupy only one slice, using an alternative method (called ***partitioning*** in BSD) to segregate file system and swap space.  Programs such as `parted` and `gparted`, contrary to their names, are in fact disk slicers.
 
-The file system is best visualized as a tree, rooted at `/`.
+In DragonFly, disk slices are designated with the letter `s` for ***slice*** and a positive integer, beginning either from zero or one, depending on the slicing scheme.  The first slice of a physical disk is thus named `s0`; the second, `s1`; and so on.  There can only be four ***physical*** slices on a disk, but one of these, designated the ***extended*** slice, may itself be sliced into ***logical*** slices.  If an extended slice exists, the logical slices it contains are numbered beginning with `s5`.  
 
-The directories, e.g. `/dev` and `/usr`, in the root directory are branches,
+For instance, the disk `ad6` may be divided into physical slices `ad6s1`, `ad6s2` (the extended slice, containing logical slices `ad6s5` and `ad6s6`), and `ad6s3`.  Note that if there are less than four physical slices, the relevant numbers are skipped, even if there are logical slices.
 
-which may have their own branches, such as `/usr/local`, and so on.
+DragonFly support two schemes for slices, MBR and GPT. Either of them can manage all of the slices on a disk:
 
-There are various reasons to house some of these directories on separate file systems. `/var` contains the directories `log/` and `spool/`, and various types of temporary files, and as such, may get filled up. Filling up the root file system is not a good idea, so splitting `/var` from `/` is often favorable.
+* MBR: are set up using [fdisk(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fdisk&amp;section8) and can be up to two terabytes (2,048 GB) in size.  Usually, MBR slices are numbered from 1; if there is only one slice on the disk (that is, the disk is ***dangerously dedicated***), however,it has slice number 0.
 
-Another common reason to contain certain directory trees on other file systems is if they are to be housed on separate physical disks, e.g. CD-ROM, or are used as separate virtual disks, such as [Network File System](network-nfs.html) exports.
+* GPT: are set up using [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section8) and support disk sizes up to eight exabytes (eight billion terabytes, a ludicrously large and, within the foreseeable future, entirely theoretical size equivalent to 800,000 times the sum total of printed works within the Library of Congress).  ***Dangerous dedication*** is irrelevant in GPT; slices are ***always*** numbered from 0.
 
-### The fstab File 
+***NOTE:*** DragonFly doesn't support booting from a GPT slice in DragonFly  2.0.  DragonFly 2.1 does have some support for booting from a GPT slice, this is described in [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section=8).
 
-During the [boot process](boot.html), file systems listed in `/etc/fstab` are automatically mounted (unless they are listed with the `noauto` option).
+### Partitions 
 
-The `/etc/fstab` file contains a list of lines of the following format:
-  
+Uniquely in BSD, disk slices contain `disklabel` partitions, not to be confused with the word partition in its usual meaning (that kind of partition is called a slice in BSD).  In most variants of UNIX, at least two slices are used to contain the system: one for the primary file system, and one for swap space.  With one exception, BSD can dispense with slices entirely and use a utility known as `disklabel` (or `bsdlabel`) to ***partition*** the disk instead. 
 
-    device       mount-point   fstype     options      dumpfreq     passno
+All BSD UNIX operating systems support eight partitions per slice, labelled `a` through `h`; most BSD systems, DragonFly included, support an additional eight, labelled `i` through `p`, for a total of sixteen per slice.  Partition layout is defined in a label on the slice where they reside.  Since each partition may have its own ***file system***, ***in BSD***, one slice may be formatted in several different file systems (a situation that does not hold true in Linux or Windows). 
 
-These parameters have the following meaning:
+Partition layout is defined in a label on the slice where the partition reside. DragonFly support two types of disk labels, disklabel32 and disklabel64 (the default):
 
-* `device`: A device name (which should exist), as explained [here](disks-naming.html).
+* [disklabel32(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&amp;section8): 32 bit disk label which can use slices with size up to 2 TB.
 
-* `mount-point`: A directory (which should exist), on which to mount the file system.
+* [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8): 64 bit disk label which can use very large slices: size up to 16 million TB.
 
-* `fstype`: The file system type to pass to [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8). The default DragonFly file system is `ufs`.
+***By convention***, four partition labels are reserved by the system and have special meanings.  The convention does not strictly have to hold true, but it is highly recommended to follow this gentleman's agreement:
 
-* `options`: Either `rw` for read-write file systems, or `ro` for read-only file systems, followed by any other options that may be needed. A common option is `noauto` for file systems not normally mounted during the boot sequence. Other options are listed in the [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) manual page.
+[[!table  data="""
+<tablestyle="width:100%"> Partition | Convention 
+<tablestyle="width:100%"> `a` | Normally contains the root file system 
+ `b` | Normally contains swap space 
+  `c` | Normally the same size as the enclosing slice.  This allows utilities that need to work on the entire slice (for example, a bad block scanner) to work on the `c` partition. You would not normally create a file system on this partition. This is not necessarily true; it is possible to use the 'c' partition as a normal partition.
+   `d` | Normally the same size as the entire physical disk.  This is now rare, but to this day, some tools may operate oddly if told to work on partition `d`. | """]]
 
-* `dumpfreq`: This is used by [dump(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=dump&section8) to determine which file systems require dumping. If the field is missing, a value of zero is assumed.
+   
 
-* `passno`: This determines the order in which file systems should be checked. File systems that should be skipped should have their `passno` set to zero. The root file system (which needs to be checked before everything else) should have its `passno` set to one, and other file systems' `passno` should be set to values greater than one. If more than one file systems have the same `passno` then [fsck(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fsck&section8) will attempt to check file systems in parallel if possible.
+### Local UNIX file systems 
 
-Consult the [fstab(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=fstab&section5) manual page for more information on the format of the `/etc/fstab` file and the options it contains.
+Each partition can contain only one ***file system***. Therefore, file systems often are described by either their typical mount point in the file system hierarchy, or the letter of the `disklabel` partition they are contained in.  DragonFly BSD supports two local UNIX file systems, UFS and HAMMER:
 
-### The mount Command 
+* UFS: is the classic BSD UNIX file system (see [ffs(5)](http://leaf.dragonflybsd.org/cgi/web-man?command#ffs&amp;section5)). It supports a volume size up to two terabytes.
 
-The [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) command is what is ultimately used to mount file systems.
+* [HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5): introduced in DragonFly 2.0, this is a new file system with many advanced features.  HAMMERfs supports a volume size of up to one exabyte (one million terabytes).
 
-In its most basic form, you use:
+***Historically***, the desirability of HAMMERfs increased with storage capacity.  For booting DragonFly from a small, local file system, UFS was previously recommended, with the option of a BOOT+HAMMER set up (512 MB UFS boot partition, the rest HAMMERfs).  For moderate storage requirements, UFS continued to be an option, but the extra features boasted by HAMMERfs (such as history retention) made it more desirable in this regard.  
+Then, as now, HAMMERfs was the unrivalled king of the large partition, usually with a [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8) label on a GPT slice.
 
-    
+As of DragonFly version 3.6, this question is mostly, or entirely, of academic interest. HAMMERfs is now recommended for all volumes greater than eighty gigabytes---that is to say, all volumes manufactured within the last five years, and a goodly portion of older ones as well.
 
-    # mount device mountpoint
+## The HAMMER File System
 
-Or, if `mountpoint` is specified in `/etc/fstab`, just:
+[HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5) is a rather new file system, under active development.  HAMMERfs reached beta in release 2.0.  As of release 2.2.1, HAMMERfs is considered to be appropriate for use in the production environment; DragonFly is currently in release 3.6.    
 
-    
+If you are deploying DragonFly on a low-capacity, low-memory system, you should evaluate if HAMMERfs is suitable for your needs; for a personal computer or server of even medium vintage, no thought need go into this, as it will be found that HAMMERfs is the file system ***of choice***.  [HAMMER(5)](http://leaf.dragonflybsd.org/cgi/web-man?command=HAMMER&amp;section5) has several advanced features not found in UFS:
 
-    # mount mountpoint
+* Large file systems:  HAMMERfs supports systems up to one exabyte (that is, one million terabytes) in size. 
 
-There are plenty of options, as mentioned in the [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) manual page, but the most common are:
+* Multiple volumes: A HAMMER file system can span up to 256 disks.  Each part of a HAMMER file system is called a volume; each volume can be up to 4096 TB in size.
 
- **Mount Options** 
+* Re-sizeability: As of release 2.4, the `expand` directive to [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8) allows HAMMER file systems to be easily re-sized; volumes may also be added and removed.  
 
-* `-a`: Mount all the file systems listed in `/etc/fstab`. Except those marked as `noauto`, excluded by the `-t` flag, or those that are already mounted.
+* Instant crash recovery:  Should a crash occur, HAMMER obviates the necessity for `fsck`, saving precious time in mission-critical applications. 
 
-* `-d`: Do everything except for the actual mount system call. This option is useful in conjunction with the `-v` flag to determine what [mount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=mount&section8) is actually trying to do.
+* Mirroring:  HAMMERfs makes it possible to ***mirror*** a master file system to a number of slave file systems.  Although mirror targets are, by necessity, read-only, they do have history available.  The history retention policy can even be different on slaves and master. Mirroring over network is supported, and unreliable connections are handled gracefully.
 
-* `-f`: Force the mount of an unclean file system (dangerous), or forces the revocation of write access when downgrading a file system's mount status from read-write to read-only.
+* Data integrity:  HAMMERfs makes data integrity a priority by implementing cyclic redundancy checks on all data.  If bits become corrupted, this will be detected.
 
-* `-r`: Mount the file system read-only. This is identical to using the `rdonly` argument to the `-o` option.
+All these features are subordinate to the single, basic, overarching purpose of the HAMMER file system: ***full history retention***.  With HAMMERfs, **all** file system changes are saved every ~30 seconds.  Changes are written at least when sync() is called (see [syncer(4)](http://leaf.dragonflybsd.org/cgi/web-man?command=syncer&amp;section4)).  Every time data are written to disk, a transaction is completed, this is assigned an identifier,  and the file updated can after this be accessed with the contents from this moment.  
 
-* `-t` ***fstype***: Mount the given file system as the given file system type, or, if used with `-a` option, mount only file systems of the given type. `ufs` is the default file system type.
+To access the file as it was then, all the user must do is add the transaction identifier to the file name, in the form `file@@<tid>`.  The TID can be saved from the `snapshot`, `cleanup`, or `synctid` [hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8) command, or looked up with the `hammer history file` command.  This history will typically grow over time, so any disk will fill up over time.  
 
-* `-u`: Update mount options on the file system.
+Two things are done so the disk does not fill up too fast, or too much.  First of all, at least moderately large disks are used.  Second, HAMMER can be made self-managing with a policy for which history to save for how long.  For example, make a snapshot every hour and `prune` and `reblock` ([hammer(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=hammer&amp;section=8)) regularly.  When snapshots get older than one month, keep them for six hours; when older than three months, keep them for a day; when older than  three years, keep them for a month. 
 
-* `-v`: Be verbose.
+Historically, you needed to set up  [cron(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=cron&amp;section8) jobs for this yourself, but HAMMER now includes a utility to make this easy.
 
-* `-w`: Mount the file system read-write.
+### Adding a Disk 
 
-The `-o` option takes a comma-separated list of the options, including the following:
+Adding a disk is done by installing it physically and by connecting it to a disk controller supported by DragonFly BSD.  If you are in doubt as to whether a particular disk controller is supported, the manual pages for disk controllers can be consulted (`man -k disk` or `man -k scsi` can be of help).  Another, easier way of ascertaining support for a controller is to boot with the controller installed, and note if the boot messages contain the controller.
 
-* `nodev:` Do not interpret special devices on the file system. This is a useful security option.
+Assuming that disk `ad6` is installed, we could set it up the old-fashioned way, using [fdisk(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=fdisk&amp;section8) and  disklabel(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel&amp;section8) or the modern way, with [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section8) and [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section8), or any combination thereof.
 
-* `noexec`: Do not allow execution of binaries on this file system. This is also a useful security option.
+In this example, we chose [gpt(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=gpt&amp;section=8) and [disklabel64(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=disklabel64&amp;section=8).
 
-* `nosuid`: Do not interpret setuid or setgid flags on the file system. This is also a useful security option.
+    # gpt -v create ad6
+    [...]
+    # gpt add -s1 ad6
+    ad6s0
+    # gpt add ad6
+    ad6s1
+    # gpt show ad6
+    [...]
 
-### The umount Command 
+In the above example, we first create the GPT and then add two slices.  The first slice added is `ad6s0`, which is made a dummy slice of size 1 sector.  The reason for this is backwards compatibility: veteran users may remember that `s0` has special meaning in MBR slice schemes, but this is not true in GPT slices.  The second slice, `ad6s1`, will cover the rest of the disk:
 
-The [umount(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=umount&section8) command takes, as a parameter, one of a mountpoint, a device name, or the `-a` or `-A` option.
+    # disklabel64 -rw ad6s1 auto
+    # disklabel64 -e ad6s1          # edit label to add partitions as needed
 
-All forms take `-f` to force unmounting, and `-v` for verbosity. Be warned that `-f` is not generally a good idea. Forcibly unmounting file systems might crash the computer or damage data on the file system.
+                                        
 
-`-a` and `-A` are used to unmount all mounted file systems, possibly modified by the file system types listed after `-t`. `-A`, however, does not attempt to unmount the root file system.
 
 ## Processes