About File System Logging

Transactional volumes and UFS logging are two types of file system logging.

File system logging describes writing file system updates to a log before applying the updates to a UFS file system. Once a transaction is recorded in the log, the transaction information can be applied to the file system later. For example, if a user creates a new directory, the mkdir command will be logged, then applied to the file system.

At reboot, the system discards incomplete transactions, but applies the transactions for completed operations. The file system remains consistent because only completed transactions are ever applied. Because the file system is never inconsistent, it does not need checking by the fsck command.

A system crash can interrupt current system calls and introduce inconsistencies into an unlogged UFS. If you mount a UFS without running the fsck command, these inconsistencies can cause panics or corrupt data.

Checking large file systems takes a long time, because it requires reading and verifying the file system data. With UFS logging, UFS file systems do not have to be checked at boot time because the changes from unfinished system calls are discarded.

Choosing a Logging Method

UFS logging and transactional volumes provide the same capability of keeping a log of file system information. The only significant differences between the two methods are the following:

• Transactional volumes can write log information onto physically separate devices, while UFS logging combines logs and file systems on the same volume.

• UFS logging offers superior performance to transactional volumes in all cases.

• UFS logging allows logging of all UFS file systems, including root (/), while transactional volumes cannot log the root (/) file system.

Transactional volumes are scheduled to be removed from the Solaris operating environment in an upcoming Solaris release. UFS logging, available since the Solaris 8 release, provides the same capabilities but superior performance, as well as lower system administration requirements and overhead. These benefits provide a clear choice for optimal performance and capabilities.

To enable UFS logging, use the mount_ufs -logging option on the file system, or add logging to the mount options for the file system in the /etc/vfstab file. For more information about mounting file systems with UFS logging enabled, see Chapter 17, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems and the mount_ufs(1M) man page.

To learn more about using transactional volumes, continue reading this document.

If you are not currently logging UFS file systems but want to use this feature, choose UFS logging, rather than transactional volumes.

Transactional Volumes

A transactional volume is a volume that is used to manage file system logging, which is essentially the same as UFS logging. Both methods record UFS updates in a log before the updates are applied to the file system.

A transactional volume consists of two devices:

• The master device is a slice or volume that contains the file system that is being logged.

• The log device is a slice or volume that contains the log and can be shared by several file systems. The log is a sequence of records, each of which describes a change to a file system.

A log device or a master device can be a physical slice or a volume. However, to improve reliability and availability, use RAID 1 volumes (mirrors) for log devices. A device error on a physical log device could cause data loss. You can also use RAID 1 or RAID 5 volumes as master devices.

Logging begins automatically when the transactional volume is mounted, provided the transactional volume has a log device. The master device can contain an existing UFS file system (because creating a transactional volume does not alter the master device). Or, you can create a file system on the transactional volume later. Likewise, clearing a transactional volume leaves the UFS file system on the master device intact.

After you configure a transactional volume, you can use it as though it were a physical slice or another logical volume. For information about creating a transactional volume, see Creating Transactional Volumes.

Example—Transactional Volume

The following figure shows a transactional volume, d1, which consists of a master device, d3, and a mirrored log device, d30.

Figure 18–1 Transactional Volume Example

Example—Shared Log Device

The following figure shows two transactional volumes, d1 and d2, sharing a mirrored log device, d30. Each master device is also a RAID 1 volume, as is the shared log device.

Figure 18–2 Shared Log Transactional Volume Example