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

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.

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.