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.
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 4, 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.