Solaris Volume Manager Administration Guide

Chapter 18 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 19, Transactional Volumes (Tasks). For more information about UFS logging, see Chapter 17, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems.

This chapter includes the following information:

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 –

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.

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 18–1 Transactional Volume Example

Diagram shows how a master device and logging device
combine for use as a transactional volume.

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

Diagram shows how two transactional volumes can share
the same logging device.

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.

Guidelines for Working with Transactional Volumes

Generally, you should log your largest UFS file systems and the UFS file system whose data changes most often. It is probably not necessary to log small file systems with mostly read-only activity.
If no slice is available for the log device, you can still configure a transactional volume. This strategy might be useful if you plan to log exported file systems when you do not have a spare slice for the log device. When a slice is available, you only need to attach it as a log device.
Consider sharing a log device among file systems if your system does not have many available slices, or if the file systems sharing the log device are primarily read, not written.

Caution –

When one master device of a shared log device goes into a failed state, the log device is unable to roll its changes forward. This problem causes all master devices sharing the log device to go into the hard error state.

Checking the Status of Transactional Volumes

The metastat command shows transactional volumes, including both master devices and log devices. For each device, the following information is displayed:

“Device”, which is the device name of the slice or volume
“Start Block”, which is the block on which the device begins
“Dbase”, which shows if the device contains a state database replica
“State”, which shows the state of the log device

The following table explains transactional volume states and possible actions to take.

Table 18–1 Transactional Volume States


State	Meaning	Action
Okay	The device is functioning properly. If mounted, the file system is logging and will not be checked at boot.	None.
Attaching	The log device will be attached to the transactional volume when the volume is closed or unmounted. When this occurs, the device transitions to the Okay state.	None.
Detached	The transactional volume does not have a log device. All benefits from UFS logging are disabled.	The `fsck` command automatically checks the device at boot time. See the fsck(1M)man page.
Detaching	The log device will be detached from the transactional volume when the volume is closed or unmounted. When this occurs, the device transitions to the Detached state.	None.
Hard Error	A device error or panic has occurred while the device was in use. An I/O error is returned for every read or write until the device is closed or unmounted. The first open causes the device to transition to the Error state.	Fix the transactional volume. See How to Recover a Transactional Volume With a Panic, or How to Recover a Transactional Volume With Hard Errors.
Error	The device can be read and written to. The file system can be mounted read-only. However, an I/O error is returned for every read or write that actually gets a device error. The device does not transition back to the Hard Error state, even when a later device error occurs.	Fix the transactional volume. See How to Recover a Transactional Volume With a Panic, or How to Recover a Transactional Volume With Hard Errors. Successfully completing the `fsck` or `newfs` commands transitions the device into the Okay state. When the device is in the Hard Error or Error state, the `fsck` command automatically checks and repairs the file system at boot time. The `newfs` command destroys whatever data might be on the device.

Scenario—Transactional Volumes

Transactional volumes provide logging capabilities for UFS file systems, similar to UFS Logging. The following example, drawing on the sample system explained in Chapter 5, Configuring and Using Solaris Volume Manager (Scenario), describes how transactional volumes can help speed reboot by providing file system logging.

Note –

Unless your situation requires the special capabilities of transactional volumes, specifically the ability to log to a different device than the logged device, consider using UFS logging instead. UFS logging provides superior performance to transactional volumes.

The sample system has several logical volumes that should be logged to provide maximum uptime and availability, including the root (/) and /var mirrors. By configuring transactional volumes to log to a third RAID 1 volume, you can provide redundancy and speed the reboot process.