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:
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.
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.
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 “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.
If you are not currently logging UFS file systems but want to use this feature, choose UFS logging, rather than 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.
The following figure shows a transactional volume, d1, which consists of a master device, d3, and a mirrored log device, d30.
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.
When you are working with transactional volumes, consider the following Requirements for Working with Transactional Volumes and Guidelines 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).
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.
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.
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.
Transactional volumes provide logging capabilities for UFS file systems, similar to UFS Logging. The following example, drawing on the sample system explained in Chapter 4, Configuring and Using Solaris Volume Manager (Scenario), describes how transactional volumes can help speed reboot by providing file system logging.
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.