UFS Logging or Trans Metadevices

UFS Logging

UFS logging is the process of writing file system "metadata" updates to a log before applying the updates to a UFS file system.

UFS logging records UFS transactions in a log. Once a transaction is recorded in the log, the transaction information can be applied to the file system later.

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 fsck(1M).

A system crash can interrupt current system calls and introduce inconsistencies into a UFS. If you mount a UFS without running fsck(1M), 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.

DiskSuite manages UFS logging through trans metadevices.

UFS Logging Conventions

• Can UFS logging improve performance?

  UFS logging saves time when you reboot after a failure, because it eliminates the need to run the fsck(1M) command on file systems.

• What are the drawbacks to UFS logging?

  If the log fills up, performance can decrease because the UFS must empty the log before writing new information into it.

• What versions of Solaris work with UFS logging?

  UFS logging can only be used with Solaris 2.4 or later releases.

• Which file systems cannot be logged?

  Non-UFS file systems as well as the root (/) file system cannot be logged.

Trans Metadevices

A trans metadevice is a metadevice that manages UFS logging. A trans metadevice consists of two devices: a master device and a logging device.

A master device is a slice or metadevice that contains the file system that is being logged. Logging begins automatically when the trans metadevice is mounted, provided the trans metadevice has a logging device. The master device can contain an existing UFS file system (because creating a trans metadevice does not alter the master device), or you can create a file system on the trans metadevice later. Likewise, clearing a trans metadevice leaves the UFS file system on the master device intact.

A logging device is a slice or metadevice that contains the log. A logging device can be shared by several trans metadevices. The log is a sequence of records, each of which describes a change to a file system.

A trans metadevice has the same naming conventions as other metadevices: /dev/md/dsk/d0, d1 ...,d2, and so forth. (For more information on metadevice naming conventions, see Table 1-4.)

Trans Metadevice Conventions

• How do I use a trans metadevice?

  After a trans metadevice is configured, it can be used just as if it were a physical slice. A trans metadevice can be used as a block device (up to 2 Gbytes) or a raw device (up to 1 Tbyte). A UFS file system can be created on the trans metadevice if the master device doesn't already have a file system.

A logging device or a master device can be a physical slice or a metadevice. For reliability and availability, however, use mirrors for logging devices. A device error on a physical logging device could cause data loss. You can also use mirrors or RAID5 metadevices as master devices.

• How much disk space does a logging device need?

  A minimum of 1 Mbyte. (Larger logs permit more simultaneous file-system transactions.) The maximum log size is 1 Gbyte. 1 Mbyte worth of log per 1 Gbyte of file system is a recommended minimum. 1 Mbyte worth of log per 100 Mbyte of file system is a recommended "average." Unfortunately, there are no hard and fast rules. The best log size varies with an individual system's load and configuration. However, a log larger than 64 Mbytes will rarely be used. Fortunately, log sizes can be changed without too much work.

• Which file systems should I log?

  Generally, 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 activity.

• Which file systems should always have separate logs?

  All logged file systems can shared the same log. For better performance, however, file systems with the heaviest loads should have separate logs.

You must disable logging for /usr, /var, /opt, or any other file systems used by the system during a Solaris upgrade or installation when installing or upgrading software on a Solaris system.

• Where should I place logs?

  Place logs on mirrors, unused slices, or slices that contain the state database replicas. A device error on a physical logging device (a slice) can cause data loss.

• What if no slice is available for the logging device?

  You can still configure a trans metadevice. This may be useful if you plan to log exported file systems when you do not have a spare slice for the logging device. When a slice is available, you only need to attach it as a logging device. For instructions, see Solstice DiskSuite 4.2.1 User's Guide.

• Can a logging device be shared between trans metadevices?

  Yes, a logging device can be shared between file systems, though heavily-used file systems should have their own logging device. The disadvantage to sharing a logging device is that certain errors require that all file systems sharing the logging device must be checked with the fsck(1M) command.

Example -- Trans Metadevice

Figure 2-8 shows a trans metadevice, d1,consisting of a mirrored master device, d3, and a mirrored logging device, d30

Figure 2-8 Trans Metadevice Example

Example -- Shared Logging Device

Figure 2-9 shows two trans metadevices, d1 and d2, sharing a mirrored logging device, d30. Each master device is also a mirrored metadevice, as is the shared logging device.

Figure 2-9 Shared Log Trans Metadevice Example