Transactional Volumes (Overview)

This chapter provides conceptual information about two types of file system logging, transactional volumes and UFS logging. For information about performing tasks related to transactional volumes, see Chapter 18, Transactional Volumes (Tasks). For more information about UFS logging, see "Mounting and Unmounting File Systems (Tasks)" in System Administration Guide: Basic Administration.

This chapter includes the following information:

• About File System Logging

• Background Information for Transactional Volumes

• Scenario--Transactional Volumes

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

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.

Note - 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 "Mounting and Unmounting File Systems (Tasks)" in System Administration Guide: Basic Administration and the mount_ufs(1M) man page.

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

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

Caution - 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 17-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 17-2 Shared Log Transactional Volume Example

Background Information for Transactional Volumes

When you are working with transactional volumes, consider the following Requirements for Working with Transactional Volumes and Guidelines for Working with Transactional Volumes.

Requirements for Working with Transactional Volumes

Before you can work with transactional volumes, note the following requirements:

• Before you create transactional volumes, identify the slices or volume to be used as the master devices and log devices.

• Log any UFS file system except root (/).

• Use a mirrored log device for data redundancy.

• Do not place logs on heavily used disks.

• Plan for a minimum of 1 Mbyte of storage space for logs. (Larger logs permit more simultaneous file system transactions.) Plan on using an additional 1 Mbyte of log space per 100 Mbytes of file system data, up to a maximum recommended log size of 64 Mbytes. Although the maximum possible log size is 1 Gbyte, logs larger than 64 Mbytes are rarely fully used and often waste storage space.

• The log device and the master device of the same transactional volume should be located on separate drives and possibly separate controllers to help balance the I/O load.

• Transactional volumes can share log devices. However, heavily used file systems should have separate logs. The disadvantage of sharing a log device is that certain errors require that all file systems that share the log device must be checked with the fsck command.

• Once you set up a transactional volume, you can share the log device among file systems.

• Logs (log devices) are typically accessed frequently. For best performance, avoid placing logs on disks with high usage. You might also want to place logs in the middle of a disk, to minimize the average seek times when accessing the log.

• The larger the log size, the better the performance. Larger logs allow for greater concurrency (more simultaneous file system operations per second).

Note - Mirroring log devices is strongly recommended. Losing the data in a log device because of device errors can leave a file system in an inconsistent state that fsck might be unable to fix without user intervention. Using a RAID 1 volume for the master device is a good idea to ensure data redundancy.