Κεφάλαιο 19. Αποθηκευτικά Μέσα

This translation may be out of date. To help with the translations please access the FreeBSD translations instance.

19.1. Σύνοψη

Το κεφάλαιο αυτό καλύπτει την χρήση των δίσκων στο FreeBSD. Περιλαμβάνει δίσκους που υποστηρίζονται από μνήμη, δίσκους συνδεδεμένους απευθείας στο δίκτυο, τις τυπικές συσκευές αποθήκευσης SCSI/IDE, καθώς και συσκευές που χρησιμοποιούν διεπαφή USB.

Αφού διαβάσετε αυτό το κεφάλαιο, θα ξέρετε:

  • Την ορολογία που χρησιμοποιεί το FreeBSD για να περιγράψει την οργάνωση των δεδομένων στο φυσικό μέσο του δίσκου (partitions - κατατμήσεις - και slices).

  • Πως να προσθέσετε νέους σκληρούς δίσκους στο σύστημα σας.

  • Πως να ρυθμίσετε το FreeBSD να χρησιμοποιεί συσκευές αποθήκευσης USB.

  • Πως να ρυθμίσετε εικονικά συστήματα αρχείων, όπως δίσκους που αποθηκεύονται σε μνήμη RAM.

  • Πως να χρησιμοποιήσετε quotas για να περιορίσετε τη χρήση χώρου στο δίσκο.

  • Πως να κρυπτογραφήσετε δίσκους για να τους ασφαλίσετε από επιθέσεις.

  • Πως να δημιουργήσετε και να γράψετε CD και DVD στο FreeBSD.

  • Πως να χρησιμοποιήσετε προγράμματα λήψης αντιγράφων ασφαλείας στο FreeBSD.

  • Τι είναι οι εικόνες (snapshots) σε ένα σύστημα αρχείων και πως να τις χρησιμοποιήσετε αποδοτικά.

Πριν διαβάσετε αυτό το κεφάλαιο, θα πρέπει:

19.2. Device Names

The following is a list of physical storage devices supported in FreeBSD and their associated device names.

Πίνακας 1. Physical Disk Naming Conventions
Drive typeDrive device name

IDE hard drives

ad or ada

IDE CD-ROM drives

acd or cd

SATA hard drives

ad or ada

SATA CD-ROM drives

acd or cd

SCSI hard drives and USB Mass storage devices

da

SCSI CD-ROM drives

cd

Assorted non-standard CD-ROM drives

mcd for Mitsumi CD-ROM and scd for Sony CD-ROM devices

Floppy drives

fd

SCSI tape drives

sa

IDE tape drives

ast

Flash drives

fla for DiskOnChip® Flash device

RAID drives

aacd for Adaptec® AdvancedRAID, mlxd and mlyd for Mylex®, amrd for AMI MegaRAID®, idad for Compaq Smart RAID, twed for 3ware® RAID.

19.3. Adding Disks

This section describes how to add a new SATA disk to a machine that currently only has a single drive. First, turn off the computer and install the drive in the computer following the instructions of the computer, controller, and drive manufacturers. Reboot the system and become root.

Inspect /var/run/dmesg.boot to ensure the new disk was found. In this example, the newly added SATA drive will appear as ada1.

For this example, a single large partition will be created on the new disk. The GPT partitioning scheme will be used in preference to the older and less versatile MBR scheme.

If the disk to be added is not blank, old partition information can be removed with gpart delete. See gpart(8) for details.

The partition scheme is created, and then a single partition is added:

# gpart create -s GPT ada1
# gpart add -t freebsd-ufs ada1

Depending on use, several smaller partitions may be desired. See gpart(8) for options to create partitions smaller than a whole disk.

A file system is created on the new blank disk:

# newfs -U /dev/ada1p1

An empty directory is created as a mountpoint, a location for mounting the new disk in the original disk’s file system:

# mkdir /newdisk

Finally, an entry is added to /etc/fstab so the new disk will be mounted automatically at startup:

/dev/ada1p1	/newdisk	ufs	rw	2	2

The new disk can be mounted manually, without restarting the system:

# mount /newdisk

19.4. USB Storage Devices

Many external storage solutions, such as hard drives, USB thumbdrives, and CD/DVD burners, use the Universal Serial Bus (USB). FreeBSD provides support for these devices.

19.4.1. Configuration

The USB mass storage devices driver, umass(4), is built into the GENERIC kernel and provides support for USB storage devices. For a custom kernel, be sure that the following lines are present in the kernel configuration file:

device scbus
device da
device pass
device uhci
device ohci
device ehci
device usb
device umass

Since the umass(4) driver uses the SCSI subsystem to access the USB storage devices, any USB device will be seen as a SCSI device by the system. Depending on the USB chipset on the motherboard, device uhci or device ohci is used to provide USB 1.X support. Support for USB 2.0 controllers is provided by device ehci.

If the USB device is a CD or DVD burner, cd(4), must be added to the kernel via the line:

device cd

Since the burner is seen as a SCSI drive, the driver atapicam(4) should not be used in the kernel configuration.

19.4.2. Testing the Configuration

To test the USB configuration, plug in the USB device. In the system message buffer, dmesg(8), the drive should appear as something like:

umass0: USB Solid state disk, rev 1.10/1.00, addr 2
GEOM: create disk da0 dp=0xc2d74850
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Generic Traveling Disk 1.11> Removable Direct Access SCSI-2 device
da0: 1.000MB/s transfers
da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C)

The brand, device node (da0), and other details will differ according to the device.

Since the USB device is seen as a SCSI one, camcontrol can be used to list the USB storage devices attached to the system:

# camcontrol devlist
<Generic Traveling Disk 1.11>      at scbus0 target 0 lun 0 (da0,pass0)

If the drive comes with a file system, it can be mounted. Refer to Adding Disks for instructions on how to format and create partitions on the USB drive.

Allowing untrusted users to mount arbitrary media, by enabling vfs.usermount as described below, should not be considered safe from a security point of view. Most file systems in FreeBSD were not built to safeguard against malicious devices.

To make the device mountable as a normal user, one solution is to make all users of the device a member of the operator group using pw(8). Next, ensure that the operator group is able to read and write the device by adding these lines to /etc/devfs.rules:

[localrules=5]
add path 'da*' mode 0660 group operator

If SCSI disks are installed in the system, change the second line as follows:

add path 'da[3-9]*' mode 0660 group operator

This will exclude the first three SCSI disks (da0 to da2)from belonging to the operator group.

Next, enable the devfs.rules(5) ruleset in /etc/rc.conf:

devfs_system_ruleset="localrules"

Next, instruct the running kernel to allow regular users to mount file systems. The easiest way is to add the following line to /etc/sysctl.conf:

vfs.usermount=1

Since this only takes effect after the next reboot use sysctl(8) to set this variable now.

The final step is to create a directory where the file system is to be mounted. This directory needs to be owned by the user that is to mount the file system. One way to do that is for root to create a subdirectory owned by that user as /mnt/username. In the following example, replace username with the login name of the user and usergroup with the user’s primary group:

# mkdir /mnt/username
# chown username:usergroup /mnt/username

Suppose a USB thumbdrive is plugged in, and a device /dev/da0s1 appears. If the device is preformatted with a FAT file system, it can be mounted using:

% mount -t msdosfs -o -m=644,-M=755 /dev/da0s1 /mnt/username

Before the device can be unplugged, it must be unmounted first. After device removal, the system message buffer will show messages similar to the following:

umass0: at uhub0 port 1 (addr 2) disconnected
(da0:umass-sim0:0:0:0): lost device
(da0:umass-sim0:0:0:0): removing device entry
GEOM: destroy disk da0 dp=0xc2d74850
umass0: detached

19.4.3. Further Reading

Beside the Adding Disks and Mounting and Unmounting File Systems sections, reading various manual pages may also be useful: umass(4), camcontrol(8), and usbconfig(8) under FreeBSD 8.X or usbdevs(8) under earlier versions of FreeBSD.

19.5. Creating and Using CD Media

19.5.1. Introduction

CD media provide a number of features that differentiate them from conventional disks. Initially, they were not writable by the user. They are designed so that they can be read continuously without delays to move the head between tracks. They are also much easier to transport between systems.

CD media do have tracks, but this refers to a section of data to be read continuously and not a physical property of the disk. For example, to produce a CD on FreeBSD, prepare the data files that are going to make up the tracks on the CD, then write the tracks to the CD.

The ISO 9660 file system was designed to deal with these differences. To overcome the original file system limits, it provides an extension mechanism that allows properly written CDs to exceed those limits while still working with systems that do not support those extensions.

The sysutils/cdrtools port includes mkisofs(8), a program that can be used to produce a data file containing an ISO 9660 file system. It has options that support various extensions, and is described below.

Which tool to use to burn the CD depends on whether the CD burner is ATAPI or something else. ATAPI CD burners use burncd which is part of the base system. SCSI and USB CD burners should use cdrecord from the sysutils/cdrtools port. It is also possible to use cdrecord and other tools for SCSI drives on ATAPI hardware with the ATAPI/CAM module.

For CD burning software with a graphical user interface, consider X-CD-Roast or K3b. These tools are available as packages or from the sysutils/xcdroast and sysutils/k3b ports. X-CD-Roast and K3b require the ATAPI/CAM module with ATAPI hardware.

19.5.2. mkisofs

The sysutils/cdrtools port also installs mkisofs(8), which produces an ISO 9660 file system that is an image of a directory tree in the UNIX® file system name space. The simplest usage is:

# mkisofs -o imagefile.iso /path/to/tree

This command creates an imagefile.iso containing an ISO 9660 file system that is a copy of the tree at /path/to/tree. In the process, it maps the file names to names that fit the limitations of the standard ISO 9660 file system, and will exclude files that have names uncharacteristic of ISO file systems.

A number of options are available to overcome these restrictions. In particular, -R enables the Rock Ridge extensions common to UNIX® systems, -J enables Joliet extensions used by Microsoft systems, and -hfs can be used to create HFS file systems used by Mac OS®.

For CDs that are going to be used only on FreeBSD systems, -U can be used to disable all filename restrictions. When used with -R, it produces a file system image that is identical to the specified FreeBSD tree, though it may violate the ISO 9660 standard in a number of ways.

The last option of general use is -b. This is used to specify the location of the boot image for use in producing an "El Torito" bootable CD. This option takes an argument which is the path to a boot image from the top of the tree being written to the CD. By default, mkisofs(8) creates an ISO image in "floppy disk emulation" mode, and thus expects the boot image to be exactly 1200, 1440 or 2880 KB in size. Some boot loaders, like the one used by the FreeBSD distribution disks, do not use emulation mode. In this case, -no-emul-boot should be used. So, if /tmp/myboot holds a bootable FreeBSD system with the boot image in /tmp/myboot/boot/cdboot, this command would produce the image of an ISO 9660 file system as /tmp/bootable.iso:

# mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot

If md is configured in the kernel, the file system can be mounted as a memory disk with:

# mdconfig -a -t vnode -f /tmp/bootable.iso -u 0
# mount -t cd9660 /dev/md0 /mnt

One can then verify that /mnt and /tmp/myboot are identical.

There are many other options available for mkisofs(8) to fine-tune its behavior. Refer to mkisofs(8) for details.

19.5.3. burncd

For an ATAPI CD burner, burncd can be used to burn an ISO image onto a CD. burncd is part of the base system, installed as /usr/sbin/burncd. Usage is very simple, as it has few options:

# burncd -f cddevice data imagefile.iso fixate

This command will burn a copy of imagefile.iso on cddevice. The default device is /dev/acd0. See burncd(8) for options to set the write speed, eject the CD after burning, and write audio data.

19.5.4. cdrecord

For systems without an ATAPI CD burner, cdrecord can be used to burn CDs. cdrecord is not part of the base system and must be installed from either the sysutils/cdrtools package or port. Changes to the base system can cause binary versions of this program to fail, possibly resulting in a "coaster". It is recommended to either upgrade the port when the system is upgraded, or for users tracking -STABLE, to upgrade the port when a new version becomes available.

While cdrecord has many options, basic usage is simple. Burning an ISO 9660 image is done with:

# cdrecord dev=device imagefile.iso

The tricky part of using cdrecord is finding the dev to use. To find the proper setting, use -scanbus which might produce results like this:

# cdrecord -scanbus
Cdrecord-Clone 2.01 (i386-unknown-freebsd7.0) Copyright (C) 1995-2004 J"org Schilling
Using libscg version 'schily-0.1'
scsibus0:
        0,0,0     0) 'SEAGATE ' 'ST39236LW       ' '0004' Disk
        0,1,0     1) 'SEAGATE ' 'ST39173W        ' '5958' Disk
        0,2,0     2) *
        0,3,0     3) 'iomega  ' 'jaz 1GB         ' 'J.86' Removable Disk
        0,4,0     4) 'NEC     ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM
        0,5,0     5) *
        0,6,0     6) *
        0,7,0     7) *
scsibus1:
        1,0,0   100) *
        1,1,0   101) *
        1,2,0   102) *
        1,3,0   103) *
        1,4,0   104) *
        1,5,0   105) 'YAMAHA  ' 'CRW4260         ' '1.0q' Removable CD-ROM
        1,6,0   106) 'ARTEC   ' 'AM12S           ' '1.06' Scanner
        1,7,0   107) *

This lists the appropriate dev value for the devices on the list. Locate the CD burner, and use the three numbers separated by commas as the value for dev. In this case, the CRW device is 1,5,0, so the appropriate input is dev=1,5,0. Refer to cdrecord(1) for easier ways to specify this value and for information on writing audio tracks and controlling the write speed.

19.5.5. Duplicating Audio CDs

To duplicate an audio CD, extract the audio data from the CD to a series of files, then write these files to a blank CD. The process is slightly different for ATAPI and SCSI drives.

Procedure: SCSI Drives
  1. Use cdda2wav to extract the audio:

    % cdda2wav -vall -D2,0 -B -Owav
  2. Use cdrecord to write the .wav files:

    % cdrecord -v dev=2,0 -dao -useinfo  *.wav

    Make sure that 2,0 is set appropriately, as described in cdrecord.

Procedure: ATAPI Drives

With the help of the ATAPI/CAM module, cdda2wav can also be used on ATAPI drives. This tool is usually a better choice for most of users, as it supports jitter correction and endianness, than the method proposed below.

  1. The ATAPI CD driver makes each track available as /dev/acddtnn, where d is the drive number, and nn is the track number written with two decimal digits, prefixed with zero as needed. So the first track on the first disk is /dev/acd0t01, the second is /dev/acd0t02, the third is /dev/acd0t03, and so on.

    Make sure the appropriate files exist in /dev. If the entries are missing, force the system to retaste the media:

    # dd if=/dev/acd0 of=/dev/null count=1
  2. Extract each track using dd(1), making sure to specify a block size when extracting the files:

    # dd if=/dev/acd0t01 of=track1.cdr bs=2352
    # dd if=/dev/acd0t02 of=track2.cdr bs=2352
    ...
  3. Burn the extracted files to disk using burncd. Specify that these are audio files, and that burncd should fixate the disk when finished:

    # burncd -f /dev/acd0 audio track1.cdr track2.cdr ... fixate

19.5.6. Duplicating Data CDs

It is possible to copy a data CD to an image file that is functionally equivalent to the image file created with mkisofs(8), and then use it to duplicate any data CD. The example given here assumes that the CD-ROM device is acd0. Substitute the correct CD-ROM device.

# dd if=/dev/acd0 of=file.iso bs=2048

Now that there is an image, it can be burned to CD as described above.

19.5.7. Using Data CDs

It is possible to mount and read the data on a standard data CD. By default, mount(8) assumes that a file system is of type ufs. Running this command:

# mount /dev/cd0 /mnt

will generate an error about Incorrect super block, and will fail to mount the CD. The CD does not use the UFS file system, so attempts to mount it as such will fail. Instead, tell mount(8) that the file system is of type ISO9660 by specifying -t cd9660 to mount(8). For example, to mount the CD-ROM device, /dev/cd0, under /mnt, use:

# mount -t cd9660 /dev/cd0 /mnt

Replace /dev/cd0 with the device name for the CD device. Also, -t cd9660 executes mount_cd9660(8), meaning the above command is equivalent to:

# mount_cd9660 /dev/cd0 /mnt

While data CD-ROMs from any vendor can be mounted this way, disks with certain ISO 9660 extensions might behave oddly. For example, Joliet disks store all filenames in two-byte Unicode characters. The FreeBSD kernel does not speak Unicode, but the FreeBSD CD9660 driver is able to convert Unicode characters on the fly. If some non-English characters show up as question marks, specify the local charset with -C. For more information, refer to mount_cd9660(8).

In order to do this character conversion with the help of -C, the kernel requires the cd9660_iconv.ko module to be loaded. This can be done either by adding this line to loader.conf:

cd9660_iconv_load="YES"

and then rebooting the machine, or by directly loading the module with kldload(8).

Occasionally, Device not configured will be displayed when trying to mount a CD-ROM. This usually means that the CD-ROM drive thinks that there is no disk in the tray, or that the drive is not visible on the bus. It can take a couple of seconds for a CD-ROM drive to realize that a media is present, so be patient.

Sometimes, a SCSI CD-ROM may be missed because it did not have enough time to answer the bus reset. To resolve this, add the following option to the kernel configuration and rebuild the kernel.

options SCSI_DELAY=15000

This tells the SCSI bus to pause 15 seconds during boot, to give the CD-ROM drive every possible chance to answer the bus reset.

19.5.8. Burning Raw Data CDs

It is possible to burn a file directly to CD, without creating an ISO 9660 file system. Some people do this for backup purposes. This command runs more quickly than burning a standard CD:

# burncd -f /dev/acd1 -s 12 data archive.tar.gz fixate

In order to retrieve the data burned to such a CD, the data must be read from the raw device node:

# tar xzvf /dev/acd1

This type of disk can not be mounted as a normal CD-ROM and the data cannot be read under any operating system except FreeBSD. In order to mount the CD, or to share the data with another operating system, mkisofs(8) must be used as described above.

19.5.9. Using the ATAPI/CAM Driver

This driver allows ATAPI devices, such as CD/DVD drives, to be accessed through the SCSI subsystem, and so allows the use of applications like sysutils/cdrdao or cdrecord(1).

To use this driver, add the following line to /boot/loader.conf:

atapicam_load="YES"

then, reboot the system.

Users who prefer to statically compile atapicam(4) support into the kernel, should add this line to the kernel configuration file:

device atapicam

Ensure the following lines are still in the kernel configuration file:

device ata
device scbus
device cd
device pass

Then rebuild, install the new kernel, and reboot the machine.

During the boot process, the burner should show up, like so:

acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4
cd0 at ata1 bus 0 target 0 lun 0
cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed

The drive can now be accessed via the /dev/cd0 device name. For example, to mount a CD-ROM on /mnt, type the following:

# mount -t cd9660 /dev/cd0 /mnt

As root, run the following command to get the SCSI address of the burner:

# camcontrol devlist
<MATSHITA CDRW/DVD UJDA740 1.00>   at scbus1 target 0 lun 0 (pass0,cd0)

In this example, 1,0,0 is the SCSI address to use with cdrecord(1) and other SCSI applications.

For more information about ATAPI/CAM and SCSI system, refer to atapicam(4) and cam(4).

19.6. Creating and Using DVD Media

19.6.1. Introduction

Compared to the CD, the DVD is the next generation of optical media storage technology. The DVD can hold more data than any CD and is the standard for video publishing.

Five physical recordable formats can be defined for a recordable DVD:

  • DVD-R: This was the first DVD recordable format available. The DVD-R standard is defined by the DVD Forum. This format is write once.

  • DVD-RW: This is the rewritable version of the DVD-R standard. A DVD-RW can be rewritten about 1000 times.

  • DVD-RAM: This is a rewritable format which can be seen as a removable hard drive. However, this media is not compatible with most DVD-ROM drives and DVD-Video players as only a few DVD writers support the DVD-RAM format. Refer to Using a DVD-RAM for more information on DVD-RAM use.

  • DVD+RW: This is a rewritable format defined by the DVD+RW Alliance. A DVD+RW can be rewritten about 1000 times.

  • DVD+R: This format is the write once variation of the DVD+RW format.

A single layer recordable DVD can hold up to 4,700,000,000 bytes which is actually 4.38 GB or 4485 MB as 1 kilobyte is 1024 bytes.

A distinction must be made between the physical media and the application. For example, a DVD-Video is a specific file layout that can be written on any recordable DVD physical media such as DVD-R, DVD+R, or DVD-RW. Before choosing the type of media, ensure that both the burner and the DVD-Video player are compatible with the media under consideration.

19.6.2. Configuration

To perform DVD recording, use growisofs(1). This command is part of the sysutils/dvd+rw-tools utilities which support all DVD media types.

These tools use the SCSI subsystem to access the devices, therefore ATAPI/CAM support must be loaded or statically compiled into the kernel. This support is not needed if the burner uses the USB interface. Refer to USB Storage Devices for more details on USB device configuration.

DMA access must also be enabled for ATAPI devices, by adding the following line to /boot/loader.conf:

hw.ata.atapi_dma="1"

Before attempting to use dvd+rw-tools, consult the Hardware Compatibility Notes.

For a graphical user interface, consider using sysutils/k3b which provides a user friendly interface to growisofs(1) and many other burning tools.

19.6.3. Burning Data DVDs

Since growisofs(1) is a front-end to mkisofs, it will invoke mkisofs(8) to create the file system layout and perform the write on the DVD. This means that an image of the data does not need to be created before the burning process.

To burn to a DVD+R or a DVD-R the data in /path/to/data, use the following command:

# growisofs -dvd-compat -Z /dev/cd0 -J -R /path/to/data

In this example, -J -R is passed to mkisofs(8) to create an ISO 9660 file system with Joliet and Rock Ridge extensions. Refer to mkisofs(8) for more details.

For the initial session recording, -Z is used for both single and multiple sessions. Replace /dev/cd0, with the name of the DVD device. Using -dvd-compat indicates that the disk will be closed and that the recording will be unappendable. This should also provide better media compatibility with DVD-ROM drives.

To burn a pre-mastered image, such as imagefile.iso, use:

# growisofs -dvd-compat -Z /dev/cd0=imagefile.iso

The write speed should be detected and automatically set according to the media and the drive being used. To force the write speed, use -speed=. Refer to growisofs(1) for example usage.

In order to support working files larger than 4.38GB, an UDF/ISO-9660 hybrid filesystem must be created by passing -udf -iso-level 3 to mkisofs(8) and all related programs, such as growisofs(1). This is required only when creating an ISO image file or when writing files directly to a disk. Since a disk created this way must be mounted as an UDF filesystem with mount_udf(8), it will be usable only on an UDF aware operating system. Otherwise it will look as if it contains corrupted files.

To create this type of ISO file:

% mkisofs -R -J -udf -iso-level 3 -o imagefile.iso /path/to/data

To burn files directly to a disk:

# growisofs -dvd-compat -udf -iso-level 3 -Z /dev/cd0 -J -R /path/to/data

When an ISO image already contains large files, no additional options are required for growisofs(1) to burn that image on a disk.

Be sure to use an up-to-date version of sysutils/cdrtools, which contains mkisofs(8), as an older version may not contain large files support. If the latest version does not work, install sysutils/cdrtools-devel and read its mkisofs(8).

19.6.4. Burning a DVD-Video

A DVD-Video is a specific file layout based on the ISO 9660 and micro-UDF (M-UDF) specifications. Since DVD-Video presents a specific data structure hierarchy, a particular program such as multimedia/dvdauthor is needed to author the DVD.

If an image of the DVD-Video file system already exists, it can be burned in the same way as any other image. If dvdauthor was used to make the DVD and the result is in /path/to/video, the following command should be used to burn the DVD-Video:

# growisofs -Z /dev/cd0 -dvd-video /path/to/video

-dvd-video is passed to mkisofs(8) to instruct it to create a DVD-Video file system layout. This option implies the -dvd-compat growisofs(1) option.

19.6.5. Using a DVD+RW

Unlike CD-RW, a virgin DVD+RW needs to be formatted before first use. It is recommended to let growisofs(1) take care of this automatically whenever appropriate. However, it is possible to use dvd+rw-format to format the DVD+RW:

# dvd+rw-format /dev/cd0

Only perform this operation once and keep in mind that only virgin DVD+RW medias need to be formatted. Once formatted, the DVD+RW can be burned as usual.

To burn a totally new file system and not just append some data onto a DVD+RW, the media does not need to be blanked first. Instead, write over the previous recording like this:

# growisofs -Z /dev/cd0 -J -R /path/to/newdata

The DVD+RW format supports appending data to a previous recording. This operation consists of merging a new session to the existing one as it is not considered to be multi-session writing. growisofs(1) will grow the ISO 9660 file system present on the media.

For example, to append data to a DVD+RW, use the following:

# growisofs -M /dev/cd0 -J -R /path/to/nextdata

The same mkisofs(8) options used to burn the initial session should be used during next writes.

Use -dvd-compat for better media compatibility with DVD-ROM drives. When using DVD+RW, this option will not prevent the addition of data.

To blank the media, use:

# growisofs -Z /dev/cd0=/dev/zero

19.6.6. Using a DVD-RW

A DVD-RW accepts two disc formats: incremental sequential and restricted overwrite. By default, DVD-RW discs are in sequential format.

A virgin DVD-RW can be directly written without being formatted. However, a non-virgin DVD-RW in sequential format needs to be blanked before writing a new initial session.

To blank a DVD-RW in sequential mode:

# dvd+rw-format -blank=full /dev/cd0

A full blanking using -blank=full will take about one hour on a 1x media. A fast blanking can be performed using -blank, if the DVD-RW will be recorded in Disk-At-Once (DAO) mode. To burn the DVD-RW in DAO mode, use the command:

# growisofs -use-the-force-luke=dao -Z /dev/cd0=imagefile.iso

Since growisofs(1) automatically attempts to detect fast blanked media and engage DAO write, -use-the-force-luke=dao should not be required.

One should instead use restricted overwrite mode with any DVD-RW as this format is more flexible than the default of incremental sequential.

To write data on a sequential DVD-RW, use the same instructions as for the other DVD formats:

# growisofs -Z /dev/cd0 -J -R /path/to/data

To append some data to a previous recording, use -M with growisofs(1). However, if data is appended on a DVD-RW in incremental sequential mode, a new session will be created on the disc and the result will be a multi-session disc.

A DVD-RW in restricted overwrite format does not need to be blanked before a new initial session. Instead, overwrite the disc with -Z. It is also possible to grow an existing ISO 9660 file system written on the disc with -M. The result will be a one-session DVD.

To put a DVD-RW in restricted overwrite format, the following command must be used:

# dvd+rw-format /dev/cd0

To change back to sequential format, use:

# dvd+rw-format -blank=full /dev/cd0

19.6.7. Multi-Session

Few DVD-ROM drives support multi-session DVDs and most of the time only read the first session. DVD+R, DVD-R and DVD-RW in sequential format can accept multiple sessions. The notion of multiple sessions does not exist for the DVD+RW and the DVD-RW restricted overwrite formats.

Using the following command after an initial non-closed session on a DVD+R, DVD-R, or DVD-RW in sequential format, will add a new session to the disc:

# growisofs -M /dev/cd0 -J -R /path/to/nextdata

Using this command with a DVD+RW or a DVD-RW in restricted overwrite mode will append data while merging the new session to the existing one. The result will be a single-session disc. Use this method to add data after an initial write on these types of media.

Since some space on the media is used between each session to mark the end and start of sessions, one should add sessions with a large amount of data to optimize media space. The number of sessions is limited to 154 for a DVD+R, about 2000 for a DVD-R, and 127 for a DVD+R Double Layer.

19.6.8. For More Information

To obtain more information about a DVD, use dvd+rw-mediainfo /dev/cd0 while the disc in the specified drive.

More information about dvd+rw-tools can be found in growisofs(1), on the dvd+rw-tools web site, and in the cdwrite mailing list archives.

When creating a problem report related to the use of dvd+rw-tools, always include the output of dvd+rw-mediainfo.

19.6.9. Using a DVD-RAM

19.6.9.1. Configuration

DVD-RAM writers can use either a SCSI or ATAPI interface. For ATAPI devices, DMA access has to be enabled by adding the following line to /boot/loader.conf:

hw.ata.atapi_dma="1"

19.6.9.2. Preparing the Media

A DVD-RAM can be seen as a removable hard drive. Like any other hard drive, the DVD-RAM must be formatted before it can be used. In this example, the whole disk space will be formatted with a standard UFS2 file system:

# dd if=/dev/zero of=/dev/acd0 bs=2k count=1
# bsdlabel -Bw acd0
# newfs /dev/acd0

The DVD device, acd0, must be changed according to the configuration.

19.6.9.3. Using the Media

Once the DVD-RAM has been formatted, it can be mounted as a normal hard drive:

# mount /dev/acd0 /mnt

Once mounted, the DVD-RAM will be both readable and writeable.

19.7. Creating and Using Floppy Disks

Storing data on floppy disks is sometimes useful, for example when one does not have any other removable storage media or when one needs to transfer small amounts of data to another computer.

This section explains how to use floppy disks in FreeBSD. It covers formatting and usage of 3.5inch DOS floppies, but the concepts are similar for other floppy disk formats.

19.7.1. Formatting Floppies

19.7.1.1. The Device

Floppy disks are accessed through entries in /dev, just like other devices. To access the raw floppy disk, simply use /dev/fdN.

19.7.1.2. Formatting

A floppy disk needs to be low-level formatted before it can be used. This is usually done by the vendor, but formatting is a good way to check media integrity. Although it is possible to force other disk sizes, 1440kB is what most floppy disks are designed for.

To low-level format the floppy disk, use fdformat(1). This utility expects the device name as an argument.

Make note of any error messages, as these can help determine if the disk is good or bad.

19.7.1.2.1. Formatting Floppy Disks

To format the floppy, insert a new 3.5inch floppy disk into the first floppy drive and issue:

# /usr/sbin/fdformat -f 1440 /dev/fd0

19.7.2. The Disk Label

After low-level formatting the disk, a disk label needs to placed on it. This disk label will be destroyed later, but it is needed by the system to determine the size of the disk and its geometry.

The new disk label will take over the whole disk and will contain all the proper information about the geometry of the floppy. The geometry values for the disk label are listed in /etc/disktab.

To write the disk label, use bsdlabel(8):

# /sbin/bsdlabel -B -w /dev/fd0 fd1440

19.7.3. The File System

The floppy is now ready to be high-level formatted. This will place a new file system on it so that FreeBSD can read and write to the disk. Since creating the new file system destroys the disk label, the disk label needs to be recreated whenever the disk is reformatted.

The floppy’s file system can be either UFS or FAT. FAT is generally a better choice for floppies.

To put a new file system on the floppy, issue:

# /sbin/newfs_msdos /dev/fd0

The disk is now ready for use.

19.7.4. Using the Floppy

To use the floppy, mount it with mount_msdosfs(8). One can also use emulators/mtools from the Ports Collection.

19.8. Creating and Using Data Tapes

Tape technology has continued to evolve but is less likely to be used in a modern system. Modern backup systems tend to use off site combined with local removable disk drive technologies. Still, FreeBSD will support any tape drive that uses SCSI, such as LTO and older devices such as DAT. There is limited support for SATA and USB tape drives.

19.8.1. Serial Access with sa(4)

FreeBSD uses the sa(4) driver, providing /dev/sa0, /dev/nsa0, and /dev/esa0. In normal use, only /dev/sa0 is needed. /dev/nsa0 is the same physical drive as /dev/sa0 but does not rewind the tape after writing a file. This allows writing more than one file to a tape. Using /dev/esa0 ejects the tape after the device is closed, if applicable.

19.8.2. Controlling the Tape Drive with mt(1)

mt(1) is the FreeBSD utility for controlling other operations of the tape drive, such as seeking through files on a tape or writing tape control marks to the tape.

For example, the first three files on a tape can be preserved by skipping past them before writing a new file:

# mt -f /dev/nsa0 fsf 3

19.8.3. Using tar(1) to Read and Write Tape Backups

An example of writing a single file to tape using tar(1):

# tar cvf /dev/sa0 file

Recovering files from a tar(1) archive on tape into the current directory:

# tar xvf /dev/sa0

19.8.4. Using dump(8) and restore(8) to Create and Restore Backups

A simple backup of /usr with dump(8):

# dump -0aL -b64 -f /dev/nsa0 /usr

Interactively restoring files from a dump(8) file on tape into the current directory:

# restore -i -f /dev/nsa0

19.8.5. Other Tape Software

Higher-level programs are available to simplify tape backup. The most popular are Amanda and Bacula. These programs aim to make backups easier and more convenient, or to automate complex backups of multiple machines. The Ports Collection contains both these and other tape utility applications.

19.9. Backup Strategies

The first requirement in devising a backup plan is to make sure that all of the following problems are covered:

  • Disk failure.

  • Accidental file deletion.

  • Random file corruption.

  • Complete machine destruction, say by fire, including destruction of any on-site backups.

Some systems will be best served by having each of these problems covered by a completely different technique. Except for strictly personal systems with low-value data, it is unlikely that one technique will cover all of them.

Some possible techniques include:

  • Archives of the whole system, backed up onto permanent, off-site media. This provides protection against all of the problems listed above, but is slow and inconvenient to restore from. Copies of the backups can be stored on site or online, but there will still be inconveniences in restoring files, especially for non-privileged users.

  • Filesystem snapshots, which are really only helpful in the accidental file deletion scenario, but can be very helpful in that case, as well as quick and easy to deal with.

  • Copies of whole file systems or disks which can be created with a periodic net/rsync of the whole machine. This is generally most useful in networks with unique requirements. For general protection against disk failure, this is usually inferior to RAID. For restoring accidentally deleted files, it can be comparable to UFS snapshots.

  • RAID, which minimizes or avoids downtime when a disk fails at the expense of having to deal with disk failures more often, because there are more disks, albeit at a much lower urgency.

  • Checking fingerprints of files using mtree(8). Although this is not a backup, this technique indicates when one needs to resort to backups. This is particularly important for offline backups, and should be checked periodically.

It is quite easy to come up with more techniques, many of them variations on the ones listed above. Specialized requirements usually lead to specialized techniques. For example, backing up a live database usually requires a method particular to the database software as an intermediate step. The important thing is to know which dangers should be protected against, and how each will be handled.

19.10. Backup Basics

The major backup programs built into FreeBSD are dump(8), tar(1), cpio(1), and pax(1).

19.10.1. Dump and Restore

The traditional UNIX® backup programs are dump and restore. They operate on the drive as a collection of disk blocks, below the abstractions of files, links and directories that are created by the file systems. Unlike other backup software, dump backs up an entire file system on a device. It is unable to backup only part of a file system or a directory tree that spans more than one file system. dump does not write files and directories, but rather writes the raw data blocks that comprise files and directories. When used to extract data, restore stores temporary files in /tmp/ by default. When using a recovery disk with a small /tmp, set TMPDIR to a directory with more free space in order for the restore to succeed.

If dump is used on the root directory, it will not back up /home, /usr or many other directories since these are typically mount points for other file systems or symbolic links into those file systems.

dump has quirks that remain from its early days in Version 6 of AT&T UNIX®,circa 1975. The default parameters are suitable for 9-track tapes (6250 bpi), not the high-density media available today (up to 62,182 ftpi). These defaults must be overridden on the command line to utilize the capacity of current tape drives.

It is also possible to backup data across the network to a tape drive attached to another computer with rdump and rrestore. Both programs rely upon rcmd(3) and ruserok(3) to access the remote tape drive. Therefore, the user performing the backup must be listed in .rhosts on the remote computer. The arguments to rdump and rrestore must be suitable to use on the remote computer. For example, to rdump from a FreeBSD computer to an Exabyte tape drive connected to a host called komodo, use:

# /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1

There are security implications to allowing .rhosts authentication, so use with caution.

It is also possible to use dump and restore in a more secure fashion over ssh.

Παράδειγμα 1. Using dump over ssh
# /sbin/dump -0uan -f - /usr | gzip -2 | ssh -c blowfish \
          targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz

Or, use the built-in RSH:

Παράδειγμα 2. Using dump over ssh with RSH Set
# env RSH=/usr/bin/ssh /sbin/dump -0uan -f targetuser@targetmachine.example.com:/dev/sa0 /usr

19.10.2. tar

tar(1) also dates back to Version 6 of AT&T UNIX®, circa 1975. tar operates in cooperation with the file system and writes files and directories to tape. tar does not support the full range of options that are available from cpio(1), but it does not require the unusual command pipeline that cpio uses.

To tar to an Exabyte tape drive connected to a host called komodo:

# tar cf - . | rsh komodo dd of=tape-device obs=20b

When backing up over an insecure network, instead use ssh.

19.10.3. cpio

cpio(1) is the original UNIX® file interchange tape program for magnetic media. cpio includes options to perform byte-swapping, write a number of different archive formats, and pipe the data to other programs. This last feature makes cpio an excellent choice for installation media. cpio does not know how to walk the directory tree and a list of files must be provided through stdin.

Since cpio does not support backups across the network, use a pipeline and ssh to send the data to a remote tape drive.

# for f in directory_list; do

# find $f >> backup.list

# done
# cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device"

Where directory_list is the list of directories to back up, user@host is the user/hostname combination that will be performing the backups, and backup_device is where the backups should be written to, such as /dev/nsa0).

19.10.4. pax

pax(1) is the IEEE/POSIX® answer to tar and cpio. Over the years the various versions of tar and cpio have become slightly incompatible. So rather than fight it out to fully standardize them, POSIX® created a new archive utility. pax attempts to read and write many of the various cpio and tar formats, plus new formats of its own. Its command set more resembles cpio than tar.

19.10.5. Amanda

Amanda (Advanced Maryland Network Disk Archiver) is a client/server backup system, rather than a single program. An Amanda server will backup to a single tape drive any number of computers that have Amanda clients and a network connection to the Amanda server. A common problem at sites with a number of large disks is that the length of time required to backup to data directly to tape exceeds the amount of time available for the task. Amanda solves this problem by using a "holding disk" to backup several file systems at the same time. Amanda creates "archive sets": a group of tapes used over a period of time to create full backups of all the file systems listed in Amanda’s configuration file. The "archive set" also contains nightly incremental, or differential, backups of all the file systems. Restoring a damaged file system requires the most recent full backup and the incremental backups.

The configuration file provides fine grained control of backups and the network traffic that Amanda generates. Amanda will use any of the above backup programs to write the data to tape. Amanda is not installed by but is available as either a port or package.

19.10.6. Do Nothing

"Do nothing" is not a computer program, but it is the most widely used backup strategy. There are no initial costs. There is no backup schedule to follow. Just say no. If something happens to your data, grin and bear it!

If your time and data is worth little to nothing, then "Do nothing" is the most suitable backup program for the computer. But beware, FreeBSD is a useful tool and over time it can be used to create a valuable collection of files.

"Do nothing" is the correct backup method for /usr/obj and other directory trees that can be exactly recreated by the computer. An example is the files that comprise the HTML or PostScript® version of this Handbook. These document formats have been created from XML input files. Creating backups of the HTML or PostScript® files is not necessary if the XML files are backed up regularly.

19.10.7. Which Backup Program Is Best?

dump(8) Period. Elizabeth D. Zwicky torture tested all the backup programs discussed here. The clear choice for preserving all your data and all the peculiarities of UNIX® file systems is dump. Elizabeth created file systems containing a large variety of unusual conditions (and some not so unusual ones) and tested each program by doing a backup and restore of those file systems. The peculiarities included: files with holes, files with holes and a block of nulls, files with funny characters in their names, unreadable and unwritable files, devices, files that change size during the backup, files that are created/deleted during the backup and more. She presented the results at LISA V in Oct. 1991. See torture-testing Backup and Archive Programs.

19.10.8. Emergency Restore Procedure

19.10.8.1. Before the Disaster

There are four steps which should be performed in preparation for any disaster that may occur.

First, print the bsdlabel of each disk using a command such as bsdlabel da0 | lpr. Also print a copy of /etc/fstab and all boot messages.

Second, burn a "livefs" CD. This CD contains support for booting into a FreeBSD "livefs" rescue mode, allowing the user to perform many tasks like running dump(8), restore(8), fdisk(8), bsdlabel(8), newfs(8), mount(8), and more. The livefs CD image for FreeBSD/i386 11.2-RELEASE is available from ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/ISO-IMAGES/11.2/FreeBSD-11.2-RELEASE-i386-livefs.iso.

Livefs CD images are not available for FreeBSD 12.0-RELEASE and later. In addition to the CD-ROM installation images, flash drive installation images may be used to recover a system. The "memstick" image for FreeBSD/i386 12.0-RELEASE is available from ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/i386/ISO-IMAGES/12.0/FreeBSD-12.0-RELEASE-i386-memstick.img.

Third, create backup tapes regularly. Any changes that made after the last backup may be irretrievably lost. Write-protect the backup media.

Fourth, test the "livefs" CD and the backups. Make notes of the procedure. Store these notes with the CD, the printouts, and the backups. These notes may prevent the inadvertent destruction of the backups while under the stress of performing an emergency recovery.

For an added measure of security, store an extra "livefs" CD and the latest backup at a remote location, where a remote location is not the basement of the same building. A remote location should be physically separated from the computers and disk drives by a significant distance.

19.10.8.2. After the Disaster

First, determine if the hardware survived. Thanks to regular, off-site backups, there is no need to worry about the software.

If the hardware has been damaged, the parts should be replaced before attempting to use the computer.

If the hardware is okay, insert the "livefs" CD and boot the computer. The original install menu will be displayed on the screen. Select the correct country, then choose Fixit — Repair mode with CD-ROM/DVD/floppy or start a shell. then select CD-ROM/DVD — Use the live filesystem CD-ROM/DVD. restore and the other needed programs are located in /mnt2/rescue.

Recover each file system separately.

Try to mount the root partition of the first disk using mount /dev/da0a /mnt. If the bsdlabel was damaged, use bsdlabel to re-partition and label the disk to match the label that was printed and saved. Use newfs to re-create the file systems. Re-mount the root partition of the disk read-write using mount -u -o rw /mnt. Use the backups to recover the data for this file system. Unmount the file system with umount /mnt. Repeat for each file system that was damaged.

Once the system is running, backup the data onto new media as whatever caused the crash or data loss may strike again. Another hour spent now may save further distress later.

19.11. Network, Memory, and File-Backed File Systems

In addition to physical disks such as floppies, CDs, and hard drives, FreeBSD also supports virtual disks.

These include network file systems such as the Network File System and Coda, memory-based file systems, and file-backed file systems.

According to the FreeBSD version, the tools used for the creation and use of file-backed and memory-based file systems differ.

Use devfs(5) to allocate device nodes transparently for the user.

19.11.1. File-Backed File System

mdconfig(8) is used to configure and enable memory disks, md(4), under FreeBSD. To use mdconfig(8), md(4) must be first loaded. When using a custom kernel configuration file, ensure it includes this line:

device md

mdconfig(8) supports several types of memory backed virtual disks: memory disks allocated with malloc(9) and memory disks using a file or swap space as backing. One possible use is the mounting of CD images.

To mount an existing file system image:

Παράδειγμα 3. Using mdconfig to Mount an Existing File System Image
# mdconfig -a -t vnode -f diskimage -u 0
# mount /dev/md0 /mnt

To create a new file system image with mdconfig(8):

Παράδειγμα 4. Creating a New File-Backed Disk with mdconfig
# dd if=/dev/zero of=newimage bs=1k count=5k
5120+0 records in
5120+0 records out
# mdconfig -a -t vnode -f newimage -u 0
# bsdlabel -w md0 auto
# newfs md0a
/dev/md0a: 5.0MB (10224 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 1.25MB, 80 blks, 192 inodes.
super-block backups (for fsck -b #) at:
 160, 2720, 5280, 7840
# mount /dev/md0a /mnt
# df /mnt
Filesystem 1K-blocks Used Avail Capacity  Mounted on
/dev/md0a       4710    4  4330     0%    /mnt

If unit number is not specified with -u, mdconfig(8) uses the md(4) automatic allocation to select an unused device. The name of the allocated unit will be output to stdout, such as md4. Refer to mdconfig(8) for more details about.

While mdconfig(8) is useful, it takes several command lines to create a file-backed file system. FreeBSD also comes with mdmfs(8) which automatically configures a md(4) disk using mdconfig(8), puts a UFS file system on it using newfs(8), and mounts it using mount(8). For example, to create and mount the same file system image as above, type the following:

Παράδειγμα 5. Configure and Mount a File-Backed Disk with mdmfs
# dd if=/dev/zero of=newimage bs=1k count=5k
5120+0 records in
5120+0 records out
# mdmfs -F newimage -s 5m md0 /mnt
# df /mnt
Filesystem 1K-blocks Used Avail Capacity  Mounted on
/dev/md0        4718    4  4338     0%    /mnt

When md is used without a unit number, mdmfs(8) uses the md(4) auto-unit feature to automatically select an unused device. For more details about mdmfs(8), refer to its manual page.

19.11.2. Memory-Based File System

For a memory-based file system, "swap backing" should normally be used. This does not mean that the memory disk will be swapped out to disk by default, but rather that the memory disk will be allocated from a memory pool which can be swapped out to disk if needed. It is also possible to create memory-based disks which are malloc(9) backed, but using large malloc backed memory disks can result in a system panic if the kernel runs out of memory.

Παράδειγμα 6. Creating a New Memory-Based Disk with mdconfig
# mdconfig -a -t swap -s 5m -u 1
# newfs -U md1
/dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 1.27MB, 81 blks, 192 inodes.
        with soft updates
super-block backups (for fsck -b #) at:
 160, 2752, 5344, 7936
# mount /dev/md1 /mnt
# df /mnt
Filesystem 1K-blocks Used Avail Capacity  Mounted on
/dev/md1        4718    4  4338     0%    /mnt
Παράδειγμα 7. Creating a New Memory-Based Disk with mdmfs
# mdmfs -s 5m md2 /mnt
# df /mnt
Filesystem 1K-blocks Used Avail Capacity  Mounted on
/dev/md2        4846    2  4458     0%    /mnt

19.11.3. Detaching a Memory Disk from the System

When a memory-based or file-based file system is no longer in use, its resources should be released back to the system. First, unmount the file system, then use mdconfig(8) to detach the disk from the system and release the resources.

For example, to detach and free all resources used by /dev/md4:

# mdconfig -d -u 4

It is possible to list information about configured md(4) devices by running mdconfig -l.

19.12. File System Snapshots

FreeBSD offers a feature in conjunction with Soft Updates: file system snapshots.

UFS snapshots allow a user to create images of specified file systems, and treat them as a file. Snapshot files must be created in the file system that the action is performed on, and a user may create no more than 20 snapshots per file system. Active snapshots are recorded in the superblock so they are persistent across unmount and remount operations along with system reboots. When a snapshot is no longer required, it can be removed using rm(1). While snapshots may be removed in any order, all the used space may not be acquired because another snapshot will possibly claim some of the released blocks.

The un-alterable snapshot file flag is set by mksnap_ffs(8) after initial creation of a snapshot file. unlink(1) makes an exception for snapshot files since it allows them to be removed.

Snapshots are created using mount(8). To place a snapshot of /var in the file /var/snapshot/snap, use the following command:

# mount -u -o snapshot /var/snapshot/snap /var

Alternatively, use mksnap_ffs(8) to create the snapshot:

# mksnap_ffs /var /var/snapshot/snap

One can find snapshot files on a file system, such as /var, using find(1):

# find /var -flags snapshot

Once a snapshot has been created, it has several uses:

  • Some administrators will use a snapshot file for backup purposes, because the snapshot can be transferred to CDs or tape.

  • The file system integrity checker, fsck(8), may be run on the snapshot. Assuming that the file system was clean when it was mounted, this should always provide a clean and unchanging result.

  • Running dump(8) on the snapshot will produce a dump file that is consistent with the file system and the timestamp of the snapshot. dump(8) can also take a snapshot, create a dump image, and then remove the snapshot in one command by using -L.

  • The snapshot can be mounted as a frozen image of the file system. To mount(8) the snapshot /var/snapshot/snap run:

    # mdconfig -a -t vnode -f /var/snapshot/snap -u 4
    # mount -r /dev/md4 /mnt

The frozen /var is now available through /mnt. Everything will initially be in the same state it was during the snapshot creation time. The only exception is that any earlier snapshots will appear as zero length files. To unmount the snapshot, use:

# umount /mnt
# mdconfig -d -u 4

For more information about softupdates and file system snapshots, including technical papers, visit Marshall Kirk McKusick’s website at http://www.mckusick.com/.

19.13. File System Quotas

Quotas are an optional feature of the operating system that can be used to limit the amount of disk space or the number of files a user or members of a group may allocate on a per-file system basis. This is used most often on timesharing systems where it is desirable to limit the amount of resources any one user or group of users may allocate. This prevents one user or group of users from consuming all of the available disk space.

19.13.1. Configuring the System to Enable Disk Quotas

Before using disk quotas, quota support must be added to the kernel by adding the following line to the kernel configuration file:

options QUOTA

Before FreeBSD 9.2, the GENERIC kernel usually did not include this option. sysctl kern.features.ufs_quota can be used to test whether the current kernel supports quotas. If the option is not present, a custom kernel must be compiled. Refer to Configuring the FreeBSD Kernel for more information on kernel configuration.

Next, enable disk quotas in /etc/rc.conf:

quota_enable="YES"

For finer control over quota startup, an additional configuration variable is available. Normally on bootup, the quota integrity of each file system is checked by quotacheck(8). This program insures that the data in the quota database properly reflects the data on the file system. This is a time consuming process that will significantly affect the time the system takes to boot. To skip this step, add this variable to /etc/rc.conf:

check_quotas="NO"

Finally, edit /etc/fstab to enable disk quotas on a per-file system basis. This is when user or group quotas can be enabled on the file systems.

To enable per-user quotas on a file system, add userquota to the options field in the /etc/fstab entry for the file system to enable quotas on. For example:

/dev/da1s2g   /home    ufs rw,userquota 1 2

To enable group quotas, instead use groupquota. To enable both user and group quotas, change the entry as follows:

/dev/da1s2g    /home    ufs rw,userquota,groupquota 1 2

By default, the quota files are stored in the root directory of the file system as quota.user and quota.group. Refer to fstab(5) for more information. Even though an alternate location for the quota files can be specified, this is not recommended because the various quota utilities do not seem to handle this properly.

Once the configuration is complete, reboot the system with the new kernel. /etc/rc will automatically run the appropriate commands to create the initial quota files for all of the quotas enabled in /etc/fstab. There is no need to manually create any zero length quota files.

In the normal course of operations, there should be no need to manually run quotacheck(8), quotaon(8), or quotaoff(8). However, one should read their manual pages to be familiar with their operation.

19.13.2. Setting Quota Limits

Once the system has been configured to enable quotas, verify they really are enabled by running:

# quota -v

There should be a one line summary of disk usage and current quota limits for each file system that quotas are enabled on.

The system is now ready to be assigned quota limits with edquota(8).

Several options are available to enforce limits on the amount of disk space a user or group may allocate, and how many files they may create. Allocations can be limited based on disk space (block quotas), number of files (inode quotas), or a combination of both. Each limits is further broken down into two categories: hard and soft limits.

A hard limit may not be exceeded. Once a user reaches a hard limit, no further allocations can be made on that file system by that user. For example, if the user has a hard limit of 500 kbytes on a file system and is currently using 490 kbytes, the user can only allocate an additional 10 kbytes. Attempting to allocate an additional 11 kbytes will fail.

Soft limits can be exceeded for a limited amount of time, known as the grace period, which is one week by default. If a user stays over their limit longer than the grace period, the soft limit turns into a hard limit and no further allocations are allowed. When the user drops back below the soft limit, the grace period is reset.

The following is an example output from edquota(8). When edquota(8) is invoked, the editor specified by EDITOR is opened in order to edit the quota limits. The default editor is set to vi.

# edquota -u test
Quotas for user test:
/usr: kbytes in use: 65, limits (soft = 50, hard = 75)
        inodes in use: 7, limits (soft = 50, hard = 60)
/usr/var: kbytes in use: 0, limits (soft = 50, hard = 75)
        inodes in use: 0, limits (soft = 50, hard = 60)

There are normally two lines for each file system that has quotas enabled. One line represents the block limits and the other represents the inode limits. Change the value to modify the quota limit. For example, to raise this user’s block limit from a soft limit of 50 and a hard limit of 75 to a soft limit of 500 and a hard limit of 600, change:

/usr: kbytes in use: 65, limits (soft = 50, hard = 75)

to:

/usr: kbytes in use: 65, limits (soft = 500, hard = 600)

The new quota limits take affect upon exiting the editor.

Sometimes it is desirable to set quota limits on a range of UIDs. This can be done by passing -p to edquota(8). First, assign the desired quota limit to a user, then run edquota -p protouser startuid-enduid. For example, if test has the desired quota limits, the following command will duplicate those quota limits for UIDs 10,000 through 19,999:

# edquota -p test 10000-19999

For more information, refer to edquota(8).

19.13.3. Checking Quota Limits and Disk Usage

Either quota(1) or repquota(8) can be used to check quota limits and disk usage. To check individual user or group quotas and disk usage, use quota(1). A user may only examine their own quota and the quota of a group they are a member of. Only the superuser may view all user and group quotas. To get a summary of all quotas and disk usage for file systems with quotas enabled, use repquota(8).

The following is sample output from quota -v for a user that has quota limits on two file systems.

Disk quotas for user test (uid 1002):
     Filesystem  usage    quota   limit   grace   files   quota   limit   grace
           /usr      65*     50      75   5days       7      50      60
       /usr/var       0      50      75               0      50      60

In this example, the user is currently 15 kbytes over the soft limit of 50 kbytes on /usr and has 5 days of grace period left. The asterisk * indicates that the user is currently over the quota limit.

Normally, file systems that the user is not using any disk space on will not show in the output of quota(1), even if the user has a quota limit assigned for that file system. Use -v to display those file systems, such as /usr/var in the above example.

19.13.4. Quotas over NFS

Quotas are enforced by the quota subsystem on the NFS server. The rpc.rquotad(8) daemon makes quota information available to quota(1) on NFS clients, allowing users on those machines to see their quota statistics.

Enable rpc.rquotad in /etc/inetd.conf like so:

rquotad/1      dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad

Now restart inetd:

# service inetd restart

19.14. Encrypting Disk Partitions

FreeBSD offers excellent online protections against unauthorized data access. File permissions and Mandatory Access Control (MAC) help prevent unauthorized users from accessing data while the operating system is active and the computer is powered up. However, the permissions enforced by the operating system are irrelevant if an attacker has physical access to a computer and can move the computer’s hard drive to another system to copy and analyze the data.

Regardless of how an attacker may have come into possession of a hard drive or powered-down computer, both the GEOM Based Disk Encryption (gbde) and geli cryptographic subsystems in FreeBSD are able to protect the data on the computer’s file systems against even highly-motivated attackers with significant resources. Unlike cumbersome encryption methods that encrypt only individual files, gbde and geli transparently encrypt entire file systems. No cleartext ever touches the hard drive’s platter.

19.14.1. Disk Encryption with gbde

  1. Configuring gbde requires superuser privileges.

    % su -
    Password:
  2. If using a custom kernel configuration file, ensure it contains this line:

    options GEOM_BDE

    If the kernel already contains this support, use kldload to load gbde(4):

    # kldload geom_bde

19.14.1.1. Preparing the Encrypted Hard Drive

The following example demonstrates adding a new hard drive to a system that will hold a single encrypted partition. This partition will be mounted as /private. gbde can also be used to encrypt /home and /var/mail, but this requires more complex instructions which exceed the scope of this introduction.

  1. Add the New Hard Drive

    Install the new drive to the system as explained in Adding Disks. For the purposes of this example, a new hard drive partition has been added as /dev/ad4s1c and /dev/ad0s1* represents the existing standard FreeBSD partitions.

    # ls /dev/ad*
    /dev/ad0        /dev/ad0s1b     /dev/ad0s1e     /dev/ad4s1
    /dev/ad0s1      /dev/ad0s1c     /dev/ad0s1f     /dev/ad4s1c
    /dev/ad0s1a     /dev/ad0s1d     /dev/ad4
  2. Create a Directory to Hold gbde Lock Files

    # mkdir /etc/gbde

    The gbde lock file contains information that gbde requires to access encrypted partitions. Without access to the lock file, gbde will not be able to decrypt the data contained in the encrypted partition without significant manual intervention which is not supported by the software. Each encrypted partition uses a separate lock file.

  3. Initialize the gbde Partition

    A gbde partition must be initialized before it can be used. This initialization needs to be performed only once:

    # gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c.lock

    gbde(8) will open the default editor, in order to set various configuration options in a template. For use with UFS1 or UFS2, set the sector_size to 2048:

    # $FreeBSD: src/sbin/gbde/template.txt,v 1.1.36.1 2009/08/03 08:13:06 kensmith Exp $
    #
    # Sector size is the smallest unit of data which can be read or written.
    # Making it too small decreases performance and decreases available space.
    # Making it too large may prevent filesystems from working.  512 is the
    # minimum and always safe.  For UFS, use the fragment size
    #
    sector_size	=	2048
    [...]

    gbde(8) will ask the user twice to type the passphrase used to secure the data. The passphrase must be the same both times. The ability of gbde to protect data depends entirely on the quality of the passphrase. For tips on how to select a secure passphrase that is easy to remember, see the Diceware Passphrase website.

    gbde init creates a lock file for the gbde partition. In this example, it is stored as /etc/gbde/ad4s1c.lock. gbde lock files must end in ".lock" in order to be correctly detected by the /etc/rc.d/gbde start up script.

    gbde lock files must be backed up together with the contents of any encrypted partitions. While deleting a lock file alone cannot prevent a determined attacker from decrypting a gbde partition, without the lock file, the legitimate owner will be unable to access the data on the encrypted partition without a significant amount of work that is totally unsupported by gbde(8).

  4. Attach the Encrypted Partition to the Kernel

    # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock

    This command will prompt to input the passphrase that was selected during the initialization of the encrypted partition. The new encrypted device will appear in /dev as /dev/device_name.bde:

    # ls /dev/ad*
    /dev/ad0        /dev/ad0s1b     /dev/ad0s1e     /dev/ad4s1
    /dev/ad0s1      /dev/ad0s1c     /dev/ad0s1f     /dev/ad4s1c
    /dev/ad0s1a     /dev/ad0s1d     /dev/ad4        /dev/ad4s1c.bde
  5. Create a File System on the Encrypted Device

    Once the encrypted device has been attached to the kernel, a file system can be created on the device using newfs(8). This example creates a UFS2 file system with soft updates enabled.

    # newfs -U /dev/ad4s1c.bde

    newfs(8) must be performed on an attached gbde partition which is identified by a *.bde extension to the device name.

  6. Mount the Encrypted Partition

    Create a mount point for the encrypted file system:

    # mkdir /private

    Mount the encrypted file system:

    # mount /dev/ad4s1c.bde /private
  7. Verify That the Encrypted File System is Available

    The encrypted file system should now be visible to df(1) and be available for use.

    % df -H
    Filesystem        Size   Used  Avail Capacity  Mounted on
    /dev/ad0s1a      1037M    72M   883M     8%    /
    /devfs            1.0K   1.0K     0B   100%    /dev
    /dev/ad0s1f       8.1G    55K   7.5G     0%    /home
    /dev/ad0s1e      1037M   1.1M   953M     0%    /tmp
    /dev/ad0s1d       6.1G   1.9G   3.7G    35%    /usr
    /dev/ad4s1c.bde   150G   4.1K   138G     0%    /private

19.14.1.2. Mounting Existing Encrypted File Systems

After each boot, any encrypted file systems must be re-attached to the kernel, checked for errors, and mounted, before the file systems can be used. The required commands must be executed as root.

  1. Attach the gbde Partition to the Kernel

    # gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c.lock

    This command will prompt for the passphrase that was selected during initialization of the encrypted gbde partition.

  2. Check the File System for Errors

    Since encrypted file systems cannot yet be listed in /etc/fstab for automatic mounting, the file systems must be checked for errors by running fsck(8) manually before mounting:

    # fsck -p -t ffs /dev/ad4s1c.bde
  3. Mount the Encrypted File System

    # mount /dev/ad4s1c.bde /private

    The encrypted file system is now available for use.

19.14.1.2.1. Automatically Mounting Encrypted Partitions

It is possible to create a script to automatically attach, check, and mount an encrypted partition, but for security reasons the script should not contain the gbde(8) password. Instead, it is recommended that such scripts be run manually while providing the password via the console or ssh(1).

As an alternative, an rc.d script is provided. Arguments for this script can be passed via rc.conf(5):

gbde_autoattach_all="YES"
gbde_devices="ad4s1c"
gbde_lockdir="/etc/gbde"

This requires that the gbde passphrase be entered at boot time. After typing the correct passphrase, the gbde encrypted partition will be mounted automatically. This can be useful when using gbde on laptops.

19.14.1.3. Cryptographic Protections Employed by gbde

gbde(8) encrypts the sector payload using 128-bit AES in CBC mode. Each sector on the disk is encrypted with a different AES key. For more information on the cryptographic design, including how the sector keys are derived from the user-supplied passphrase, refer to gbde(4).

19.14.1.4. Compatibility Issues

sysinstall(8) is incompatible with gbde-encrypted devices. All *.bde devices must be detached from the kernel before starting sysinstall(8) or it will crash during its initial probing for devices. To detach the encrypted device used in the example, use the following command:

# gbde detach /dev/ad4s1c

19.14.2. Disk Encryption with geli

An alternative cryptographic GEOM class is available through geli(8). geli differs from gbde; offers different features, and uses a different scheme for doing cryptographic work.

geli(8) provides the following features:

  • Utilizes the crypto(9) framework and, when cryptographic hardware is available, geli uses it automatically.

  • Supports multiple cryptographic algorithms such as AES, Blowfish, and 3DES.

  • Allows the root partition to be encrypted. The passphrase used to access the encrypted root partition will be requested during system boot.

  • Allows the use of two independent keys such as a "key" and a "company key".

  • geli is fast as it performs simple sector-to-sector encryption.

  • Allows backup and restore of master keys. If a user destroys their keys, it is still possible to get access to the data by restoring keys from the backup.

  • Allows a disk to attach with a random, one-time key which is useful for swap partitions and temporary file systems.

More geli features can be found in geli(8).

This section describes how to enable support for geli in the FreeBSD kernel and explains how to create and use a geli encryption provider.

Superuser privileges are required since modifications to the kernel are necessary.

  1. Adding geli Support to the Kernel

    For a custom kernel, ensure the kernel configuration file contains these lines:

    options GEOM_ELI
    device crypto

    Alternatively, the geli module can be loaded at boot time by adding the following line to /boot/loader.conf:

    geom_eli_load="YES"

    geli(8) should now be supported by the kernel.

  2. Generating the Master Key

    The following example describes how to generate a key file which will be used as part of the master key for the encrypted provider mounted under /private. The key file will provide some random data used to encrypt the master key. The master key will also be protected by a passphrase. The provider’s sector size will be 4kB. The example will describe how to attach to the geli provider, create a file system on it, mount it, work with it, and finally, how to detach it.

    It is recommended to use a bigger sector size, such as 4kB, for better performance.

    The master key will be protected with a passphrase and the data source for the key file will be /dev/random. The sector size of the provider /dev/da2.eli will be 4kB.

    # dd if=/dev/random of=/root/da2.key bs=64 count=1
    # geli init -s 4096 -K /root/da2.key /dev/da2
    Enter new passphrase:
    Reenter new passphrase:

    It is not mandatory to use both a passphrase and a key file as either method of securing the master key can be used in isolation.

    If the key file is given as "-", standard input will be used. This example shows how more than one key file can be used:

    # cat keyfile1 keyfile2 keyfile3 | geli init -K - /dev/da2
  3. Attaching the Provider with the Generated Key

    # geli attach -k /root/da2.key /dev/da2
    Enter passphrase:

    The new plaintext device will be named /dev/da2.eli.

    # ls /dev/da2*
    /dev/da2  /dev/da2.eli
  4. Creating the New File System

    # dd if=/dev/random of=/dev/da2.eli bs=1m
    # newfs /dev/da2.eli
    # mount /dev/da2.eli /private

    The encrypted file system should now be visible to df(1) and be available for use:

    # df -H
    Filesystem     Size   Used  Avail Capacity  Mounted on
    /dev/ad0s1a    248M    89M   139M    38%    /
    /devfs         1.0K   1.0K     0B   100%    /dev
    /dev/ad0s1f    7.7G   2.3G   4.9G    32%    /usr
    /dev/ad0s1d    989M   1.5M   909M     0%    /tmp
    /dev/ad0s1e    3.9G   1.3G   2.3G    35%    /var
    /dev/da2.eli   150G   4.1K   138G     0%    /private
  5. Unmounting and Detaching the Provider

    Once the work on the encrypted partition is done, and the /private partition is no longer needed, it is prudent to consider unmounting and detaching the geli encrypted partition from the kernel:

    # umount /private
    # geli detach da2.eli

More information about the use of geli(8) can be found in its manual page.

19.14.2.1. Using the geli rc.d Script

geli comes with a rc.d script which can be used to simplify the usage of geli. An example of configuring geli through rc.conf(5) follows:

geli_devices="da2"
geli_da2_flags="-p -k /root/da2.key"

This configures /dev/da2 as a geli provider of which the master key file is located in /root/da2.key. geli will not use a passphrase when attaching to the provider if -P was given during the geli init phase. The system will detach the geli provider from the kernel before the system shuts down.

More information about configuring rc.d is provided in the rc.d section of the Handbook.

19.15. Encrypting Swap Space

Like the encryption of disk partitions, encryption of swap space is used to protect sensitive information. Consider an application that deals with passwords. As long as these passwords stay in physical memory, these passwords will not be written to disk and be cleared after a reboot. If FreeBSD starts swapping out memory pages to free space for other applications, the passwords may be written to the disk platters unencrypted. Encrypting swap space can be a solution for this scenario.

The gbde(8) or geli(8) encryption systems may be used for swap encryption. Both systems use the encswap rc.d script.

For the remainder of this section, ad0s1b will be the swap partition.

Swap partitions are not encrypted by default and should be cleared of any sensitive data before continuing. To overwrite the current swap parition with random garbage, execute the following command:

# dd if=/dev/random of=/dev/ad0s1b bs=1m

19.15.1. Swap Encryption with gbde(8)

The .bde suffix should be added to the device in the respective /etc/fstab swap line:

# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad0s1b.bde		none		swap	sw		0	0

19.15.2. Swap Encryption with geli(8)

The procedure for instead using geli(8) for swap encryption is similar to that of using gbde(8). The .eli suffix should be added to the device in the respective /etc/fstab swap line:

# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/ad0s1b.eli		none		swap	sw		0	0

geli(8) uses the AES algorithm with a key length of 128 bit by default. These defaults can be altered by using geli_swap_flags in /etc/rc.conf. The following line tells the encswap rc.d script to create geli(8) swap partitions using the Blowfish algorithm with a key length of 128 bits and a sectorsize of 4 kilobytes, and sets "detach on last close":

geli_swap_flags="-e blowfish -l 128 -s 4096 -d"

Refer to the description of onetime in geli(8) for a list of possible options.

19.15.3. Encrypted Swap Verification

Once the system has rebooted, proper operation of the encrypted swap can be verified using swapinfo.

If gbde(8) is being used:

% swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ad0s1b.bde    542720        0   542720     0%

If geli(8) is being used:

% swapinfo
Device          1K-blocks     Used    Avail Capacity
/dev/ad0s1b.eli    542720        0   542720     0%

19.16. Highly Available Storage (HAST)

19.16.1. Synopsis

High availability is one of the main requirements in serious business applications and highly-available storage is a key component in such environments. Highly Available STorage, or HAST, was developed by Paweł Jakub Dawidek <pjd@FreeBSD.org> as a framework which allows transparent storage of the same data across several physically separated machines connected by a TCP/IP network. HAST can be understood as a network-based RAID1 (mirror), and is similar to the DRBD® storage system known from the GNU/Linux® platform. In combination with other high-availability features of FreeBSD like CARP, HAST makes it possible to build a highly-available storage cluster that is resistant to hardware failures.

After reading this section, you will know:

  • What HAST is, how it works and which features it provides.

  • How to set up and use HAST on FreeBSD.

  • How to integrate CARP and devd(8) to build a robust storage system.

Before reading this section, you should:

The HAST project was sponsored by The FreeBSD Foundation with support from OMCnet Internet Service GmbH and TransIP BV.

19.16.2. HAST Features

The main features of the HAST system are:

  • Can be used to mask I/O errors on local hard drives.

  • File system agnostic as it works with any file system supported by FreeBSD.

  • Efficient and quick resynchronization, synchronizing only blocks that were modified during the downtime of a node.

  • Can be used in an already deployed environment to add additional redundancy.

  • Together with CARP, Heartbeat, or other tools, it can be used to build a robust and durable storage system.

19.16.3. HAST Operation

As HAST provides a synchronous block-level replication of any storage media to several machines, it requires at least two physical machines: the primary, also known as the master node, and the secondary or slave node. These two machines together are referred to as a cluster.

HAST is currently limited to two cluster nodes in total.

Since HAST works in a primary-secondary configuration, it allows only one of the cluster nodes to be active at any given time. The primary node, also called active, is the one which will handle all the I/O requests to HAST-managed devices. The secondary node is automatically synchronized from the primary node.

The physical components of the HAST system are:

  • local disk on primary node, and

  • disk on remote, secondary node.

HAST operates synchronously on a block level, making it transparent to file systems and applications. HAST provides regular GEOM providers in /dev/hast/ for use by other tools or applications, thus there is no difference between using HAST-provided devices and raw disks or partitions.

Each write, delete, or flush operation is sent to the local disk and to the remote disk over TCP/IP. Each read operation is served from the local disk, unless the local disk is not up-to-date or an I/O error occurs. In such case, the read operation is sent to the secondary node.

19.16.3.1. Synchronization and Replication Modes

HAST tries to provide fast failure recovery. For this reason, it is very important to reduce synchronization time after a node’s outage. To provide fast synchronization, HAST manages an on-disk bitmap of dirty extents and only synchronizes those during a regular synchronization, with an exception of the initial sync.

There are many ways to handle synchronization. HAST implements several replication modes to handle different synchronization methods:

  • memsync: report write operation as completed when the local write operation is finished and when the remote node acknowledges data arrival, but before actually storing the data. The data on the remote node will be stored directly after sending the acknowledgement. This mode is intended to reduce latency, but still provides very good reliability.

  • fullsync: report write operation as completed when local write completes and when remote write completes. This is the safest and the slowest replication mode. This mode is the default.

  • async: report write operation as completed when local write completes. This is the fastest and the most dangerous replication mode. It should be used when replicating to a distant node where latency is too high for other modes.

19.16.4. HAST Configuration

HAST requires GEOM_GATE support which is not present in the default GENERIC kernel. However, the geom_gate.ko loadable module is available in the default FreeBSD installation. Alternatively, to build GEOM_GATE support into the kernel statically, add this line to the custom kernel configuration file:

options	GEOM_GATE

The HAST framework consists of several parts from the operating system’s point of view:

The following example describes how to configure two nodes in master-slave / primary-secondary operation using HAST to replicate the data between the two. The nodes will be called hasta with an IP address of 172.16.0.1 and hastb with an IP of address 172.16.0.2. Both nodes will have a dedicated hard drive /dev/ad6 of the same size for HAST operation. The HAST pool, sometimes also referred to as a resource or the GEOM provider in /dev/hast/, will be called test.

Configuration of HAST is done using /etc/hast.conf. This file should be the same on both nodes. The simplest configuration possible is:

resource test {
	on hasta {
		local /dev/ad6
		remote 172.16.0.2
	}
	on hastb {
		local /dev/ad6
		remote 172.16.0.1
	}
}

For more advanced configuration, refer to hast.conf(5).

It is also possible to use host names in the remote statements. In such a case, make sure that these hosts are resolvable and are defined in /etc/hosts or in the local DNS.

Now that the configuration exists on both nodes, the HAST pool can be created. Run these commands on both nodes to place the initial metadata onto the local disk and to start hastd(8):

# hastctl create test
# service hastd onestart

It is not possible to use GEOM providers with an existing file system or to convert an existing storage to a HAST-managed pool. This procedure needs to store some metadata on the provider and there will not be enough required space available on an existing provider.

A HAST node’s primary or secondary role is selected by an administrator, or software like Heartbeat, using hastctl(8). On the primary node, hasta, issue this command:

# hastctl role primary test

Similarly, run this command on the secondary node, hastb:

# hastctl role secondary test

When the nodes are unable to communicate with each other, and both are configured as primary nodes, the condition is called split-brain. To troubleshoot this situation, follow the steps described in Recovering from the Split-brain Condition.

Verify the result by running hastctl(8) on each node:

# hastctl status test

The important text is the status line, which should say complete on each of the nodes. If it says degraded, something went wrong. At this point, the synchronization between the nodes has already started. The synchronization completes when hastctl status reports 0 bytes of dirty extents.

The next step is to create a filesystem on the /dev/hast/test GEOM provider and mount it. This must be done on the primary node, as /dev/hast/test appears only on the primary node. Creating the filesystem can take a few minutes, depending on the size of the hard drive:

# newfs -U /dev/hast/test
# mkdir /hast/test
# mount /dev/hast/test /hast/test

Once the HAST framework is configured properly, the final step is to make sure that HAST is started automatically during system boot. Add this line to /etc/rc.conf:

hastd_enable="YES"

19.16.4.1. Failover Configuration

The goal of this example is to build a robust storage system which is resistant to the failure of any given node. The scenario is that a primary node of the cluster fails. If this happens, the secondary node is there to take over seamlessly, check and mount the file system, and continue to work without missing a single bit of data.

To accomplish this task, another FreeBSD feature, CARP, provides for automatic failover on the IP layer. CARP (Common Address Redundancy Protocol) allows multiple hosts on the same network segment to share an IP address. Set up CARP on both nodes of the cluster according to the documentation available in Common Access Redundancy Protocol (CARP). After setup, each node will have its own carp0 interface with a shared IP address of 172.16.0.254. The primary HAST node of the cluster must be the master CARP node.

The HAST pool created in the previous section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through NFS or Samba, using the shared IP address 172.16.0.254. The only problem which remains unresolved is an automatic failover should the primary node fail.

In the event of CARP interfaces going up or down, the FreeBSD operating system generates a devd(8) event, making it possible to watch for state changes on the CARP interfaces. A state change on the CARP interface is an indication that one of the nodes failed or came back online. These state change events make it possible to run a script which will automatically handle the HAST failover.

To be able to catch state changes on the CARP interfaces, add this configuration to /etc/devd.conf on each node:

notify 30 {
	match "system" "IFNET";
	match "subsystem" "carp0";
	match "type" "LINK_UP";
	action "/usr/local/sbin/carp-hast-switch master";
};

notify 30 {
	match "system" "IFNET";
	match "subsystem" "carp0";
	match "type" "LINK_DOWN";
	action "/usr/local/sbin/carp-hast-switch slave";
};

Restart devd(8) on both nodes to put the new configuration into effect:

# service devd restart

When the carp0 interface state changes by going up or down , the system generates a notification, allowing the devd(8) subsystem to run an arbitrary script, in this case /usr/local/sbin/carp-hast-switch. This script handles the automatic failover. For further clarification about the above devd(8) configuration, refer to devd.conf(5).

An example of such a script could be:

#!/bin/sh

# Original script by Freddie Cash <fjwcash@gmail.com>
# Modified by Michael W. Lucas <mwlucas@BlackHelicopters.org>
# and Viktor Petersson <vpetersson@wireload.net>

# The names of the HAST resources, as listed in /etc/hast.conf
resources="test"

# delay in mounting HAST resource after becoming master
# make your best guess
delay=3

# logging
log="local0.debug"
name="carp-hast"

# end of user configurable stuff

case "$1" in
	master)
		logger -p $log -t $name "Switching to primary provider for ${resources}."
		sleep ${delay}

		# Wait for any "hastd secondary" processes to stop
		for disk in ${resources}; do
			while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do
				sleep 1
			done

			# Switch role for each disk
			hastctl role primary ${disk}
			if [ $? -ne 0 ]; then
				logger -p $log -t $name "Unable to change role to primary for resource ${disk}."
				exit 1
			fi
		done

		# Wait for the /dev/hast/* devices to appear
		for disk in ${resources}; do
			for I in $( jot 60 ); do
				[ -c "/dev/hast/${disk}" ] && break
				sleep 0.5
			done

			if [ ! -c "/dev/hast/${disk}" ]; then
				logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear."
				exit 1
			fi
		done

		logger -p $log -t $name "Role for HAST resources ${resources} switched to primary."

		logger -p $log -t $name "Mounting disks."
		for disk in ${resources}; do
			mkdir -p /hast/${disk}
			fsck -p -y -t ufs /dev/hast/${disk}
			mount /dev/hast/${disk} /hast/${disk}
		done

	;;

	slave)
		logger -p $log -t $name "Switching to secondary provider for ${resources}."

		# Switch roles for the HAST resources
		for disk in ${resources}; do
			if ! mount | grep -q "^/dev/hast/${disk} on "
			then
			else
				umount -f /hast/${disk}
			fi
			sleep $delay
			hastctl role secondary ${disk} 2>&1
			if [ $? -ne 0 ]; then
				logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}."
				exit 1
			fi
			logger -p $log -t $name "Role switched to secondary for resource ${disk}."
		done
	;;
esac

In a nutshell, the script takes these actions when a node becomes master / primary:

  • Promotes the HAST pools to primary on a given node.

  • Checks the file system under the HAST pool.

  • Mounts the pools at an appropriate place.

When a node becomes backup / secondary:

  • Unmounts the HAST pools.

  • Degrades the HAST pools to secondary.

Keep in mind that this is just an example script which serves as a proof of concept. It does not handle all the possible scenarios and can be extended or altered in any way, for example, to start/stop required services.

For this example, a standard UFS file system was used. To reduce the time needed for recovery, a journal-enabled UFS or ZFS file system can be used instead.

More detailed information with additional examples can be found in the HAST Wiki page.

19.16.5. Troubleshooting

19.16.5.1. General Troubleshooting Tips

HAST should generally work without issues. However, as with any other software product, there may be times when it does not work as supposed. The sources of the problems may be different, but the rule of thumb is to ensure that the time is synchronized between all nodes of the cluster.

When troubleshooting HAST problems, the debugging level of hastd(8) should be increased by starting hastd(8) with -d. This argument may be specified multiple times to further increase the debugging level. A lot of useful information may be obtained this way. Consider also using -F, which starts hastd(8) in the foreground.

19.16.5.2. Recovering from the Split-brain Condition

Split-brain is when the nodes of the cluster are unable to communicate with each other, and both are configured as primary. This is a dangerous condition because it allows both nodes to make incompatible changes to the data. This problem must be corrected manually by the system administrator.

The administrator must decide which node has more important changes (or merge them manually) and let HAST perform full synchronization of the node which has the broken data. To do this, issue these commands on the node which needs to be resynchronized:

# hastctl role init <resource>
# hastctl create <resource>
# hastctl role secondary <resource>

Τελευταία τροποποίηση: 9 Μαρτίου 2024 από Danilo G. Baio