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

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:

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.

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

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:

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.

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:

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

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:

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:

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:

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:

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.

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.

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:

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:

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

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.

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:

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.

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:

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:

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.

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.

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.

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

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:

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:

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:

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).

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.

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.

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:

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

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.

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:

then, reboot the system.

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

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

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

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).

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:

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.

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:

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

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:

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:

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.

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:

-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.

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:

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:

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:

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

To blank the media, use:

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:

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

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:

To change back to sequential format, use:

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:

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.

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.

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):

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:

The disk is now ready for use.

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

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.

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:

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

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

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

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

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.

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.

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:

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.

Or, use the built-in RSH:

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:

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

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.

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).

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.

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.

"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.

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.

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:

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:

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

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:

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.

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.

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:

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

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

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:

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:

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:

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

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.

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

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.

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:

to:

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:

For more information, refer to edquota(8).

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.

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.

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:

Now restart inetd:

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:

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.

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

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

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:

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":

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

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

If gbde(8) is being used:

If geli(8) is being used:

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:

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.

The main features of the HAST system are:

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.

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:

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.

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:

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:

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

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):

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:

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

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

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:

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: