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.

Creating Transactional Volumes

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.

How to Create a Transactional Volume

Steps

If possible, unmount the
UFS file system for which you want to enable logging.

# umount /export

Note –

If the file system cannot be unmounted, you can continue, but
will have to reboot the system before the transactional volume can be active.

Create the transactional
volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose Action->Create
Volume and follow the instructions in the wizard. For more information, see
the online help.

Use the following form of the metainit command:

metainit trans-volume-tmaster-devicelog-device

trans-volume is the name of the
transactional volume to create.

master-device is the name of the
device containing the file system you want to log.

log-device is the name of the
device that will contain the log.

The master
device and log device can be either slices or logical volumes. See the metainit(1M) man
page for more information.

For example, to create a transactional
volume (d10) logging the file system on slice c0t0d0s6 to a log on c0t0d0s7, use the following
syntax:

# metainit d10 -t c0t0d0s6 c0t0d0s7

Note –

You can use the same log device (c0t0d0s7 in
this example) for several master devices. The sharing of log devices is fully
supported.

Edit the /etc/vfstab file so that the existing UFS file system information is replaced
with that of the created transactional volume.

For example, if /export was on c0t0d0s6, and the new transactional
volume is d10, edit /etc/vfstab as
shown here, so the mount points to the transactional volume rather than to
the raw disk slice:

Example 19–1 Creating a Transactional Volume for a Slice

The slice /dev/dsk/c0t2d0s2 contains a file system
mounted on /home1. The slice that will contain the log
device is /dev/dsk/c2t2d0s1. First, the file system is
unmounted. The metainit command with the -t option
creates the transactional volume, d63.

Next, the /etc/vfstab file must be edited to change the entry for the file
system to reference the transactional volume. For example, the following line:

/dev/dsk/c0t2d0s2 /dev/rdsk/c0t2d0s2 /home1 ufs 2 yes -

should be changed to:

/dev/md/dsk/d63 /dev/md/rdsk/d63 /home1 ufs 2 yes -

Logging becomes effective for the file system when it is remounted.

On subsequent reboots, instead of checking the file system, the fsck command displays a log message for the transactional volume:

# reboot
...
/dev/md/rdsk/d63: is logging

Example 19–2 Creating a Transactional Volume for /usr

Slice /dev/dsk/c0t3d0s6 contains the /usr file system. The slice that will contain the log device is /dev/dsk/c1t2d0s1. Because /usr cannot be
unmounted, the metainit command is run with the -f option to force the creation of the transactional volume, d20. Next, the line in the /etc/vfstab file
that mounts the file system must be changed to reference the transactional
volume. For example, the following line:

/dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 1 no -

should be changed to:

/dev/md/dsk/d20 /dev/md/rdsk/d20 /usr ufs 1 no -

Logging becomes effective for the file system when
the system is rebooted.

Example 19–3 Creating a Transactional Volume for a Logical Volume

RAID 1 volume d30 contains a file system that is
mounted on /home1. The mirror that will contain the log
device is d12. First, the file system is unmounted. The metainit command with the -t option creates the
transactional volume, d64.

Next, the line in the /etc/vfstab file that mounts
the file system must be changed to reference the transactional volume. For
example, the following line:

/dev/md/dsk/d30 /dev/md/rdsk/d30 /home1 ufs 2 yes -

should be changed to:

/dev/md/dsk/d64 /dev/md/rdsk/d64 /home1 ufs 2 yes -

Logging becomes effective
for the file system when the file system is remounted.

On subsequent file system remounts or system reboots, instead of checking
the file system, the fsck command displays a log message
for the transactional volume:

# reboot
...
/dev/md/rdsk/d64: is logging

To avoid editing the /etc/vfstab file, you can
use the metarename(1M) command
to exchange the name of the original logical volume and the new transactional
volume. For more information, see Renaming Volumes.

Converting Transactional Volumes
to UFS Logging

Converting any existing transactional volumes on your system to use
UFS logging could improve performance and maintainability. Additionally, because
transactional volumes will not be supported at some time in the future, you
will eventually need to move to UFS logging. The following section outlines
the conversion process.

How to Convert a Transactional
Volume to UFS Logging

Note –

You must have at least one Mbyte of free space (using default
system settings) to convert to UFS logging, because the log requires some
space and resides on the logged volume. If you do not have sufficient free
space, you will have to remove files or grow your file system before you can
complete this conversion process.

To Convert a Transactional
Volume to Use UFS Logging

Steps

Identify transactional volumes
and their associated log devices by using the metastat command
and looking for Trans and Logging device in
the output.

Check to see if the Trans device is currently mounted by using the df command
and searching for the name of the transactional volume in the output. If the
transactional volume is not mounted, go to Step 7.

The Logging device, identified at the beginning of
this procedure, is now unused and can be reused for other purposes. The master
device, also identified at the beginning of this procedure, contains the file
system and must be mounted for use.

Edit the /etc/vfstab file to update the mount information for the file system.

You must change the raw and block mount points, and add logging to the options for that file system. With the transactional volume
in use, the /etc/vfstab entry looks like this:

/dev/md/dsk/d2 /dev/md/rdsk/d2 /mnt/transvolume ufs 1 no -

After you update the file to change the mount point from the transactional
volume d2 to the underlying device d0,
and add the logging option, that part of the /etc/vfstab file
looks like this:

The mount command might report an error, similar
to “the state of /dev/md/dsk/d0 is not okay and
it was attempted to be mounted read/write. Please run fsck and
try again.” If this happens, run fsck on the raw
device (fsck /dev/md/rdsk/d0 in this case), answer y to fixing the file system state in the superblock, and try again.

Verify that the file system
is mounted with logging enabled by examining the /etc/mnttab file
and confirming that the file system has logging listed as one of the options.

Maintaining Transactional Volumes

How to Check the State of Transactional
Volumes

Step

To check the status of a
transactional volume, use one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then view the status
of the volumes. Right-click a transactional volume and choose Properties for
more detailed status information. For more information, see the online help.

How to Attach a Log Device to
a Transactional Volume

Steps

Attach a log device to the
transactional volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

Use the following form of the metattach command:

metattach master-volumelogging-volume

master-volume is the name of the transactional
volume that contains the file system to be logged.

logging-volume is the name of the volume or slice that should
contain the log.

How to Detach a Log Device from
a Transactional Volume

Steps

Unmount the UFS file system
for which you want to disable logging or change the log device.

Detach the log device from
the transactional volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

Use the following form of the metadetach command:

metadetach master-volume

master-volume is the name of the transactional
volume that contains the file system that is being logged.

Steps

If the master device is a
volume (rather than a basic slice), attach additional slices to the master
device by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties, then the Components panel. For more information, see the online
help.

Use the following form of the metattach command:

metattach master-volumecomponent

master-volume is the name of the transactional
volume that contains the file system to be logged.

This example shows the
expansion of a transactional device, d10, whose master
device consists of a two-way RAID 1 volume, d0, which
contains two submirrors, d11 and d12.
The metattach command is run on each submirror. The system
confirms that each slice was attached.

How to Remove a Transactional
Volume

Steps

Unmount the UFS file system
for which you want to remove the transactional volume and disable logging.

# umount /filesystem

Detach the log device from
the transactional volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

Use the following form of the metadetach command:

metadetach master-volume

master-volume is the name of the transactional
volume that contains the file system that is being logged.

Remove (clear) the transactional
volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Delete. For more information, see the online help.

Steps

Unmount the UFS file system
for which you want to remove the transactional volume and disable logging.

Detach the log device from
the transactional volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

Use the following form of the metadetach command:

metadetach master-volume

master-volume is the name of the transactional
volume that contains the file system that is being logged.

Exchange the name of the
transactional volume with that of the master device.

Remove (clear) the transactional
volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Delete. For more information, see the online help.

This example begins with a transactional
volume, d1, that contains a mounted file system, and
ends up with a file system that is mounted on the transactional volume`s underlying
master device, which will be d1.

The metastat command confirms that the transactional
volume, d1, is in the “Okay” state. The file
system is unmounted before detaching the transactional volume's log device.
The transactional volume and its mirrored master device are exchanged by using
the -f (force) flag. Running the metastat command
again confirms that the exchange occurred. The transactional volume and the
log device (if desired) are cleared, in this case, d21 and d0, respectively. Next, the fsck command is
run on the mirror, d1, and the prompt is answered with
a y. After the fsck command is done,
the file system is remounted. Note that because the mount device for /fs2 did not change, the /etc/vfstab file
does not require editing.

Sharing Log Devices

How to Share a Log Device Among
File Systems

This procedure assumes that you have already set up a transactional
volume with a log for another file system.

Steps

If possible, unmount the
file system for which you want to enable logging.

If you already have an existing
log device, detach it from the transactional volume by using one of the following
methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

Attach a log device to the
transactional volume by using one of the following methods:

From the Enhanced Storage tool within the Solaris Management Console, open the Volumes node, then choose the
transactional volume from the listing. Right-click the volume, and choose
Properties. For more information, see the online help.

This example
shows the sharing of a log device (d10) defined as the
log for a previous transactional volume, with a new transactional volume (d64). The file system to be set up as the master device is /xyzfs and is using slice /dev/dsk/c0t2d0s4.
The metainit -t command specifies the configuration
is a transactional volume. The /etc/vfstab file must
be edited to change (or enter for the first time) the entry for the file system
to reference the transactional volume. For example, the following line:

/dev/dsk/c0t2d0s4 /dev/rdsk/c0t2d0s4 /xyzfs ufs 2 yes -

should be changed to:

/dev/md/dsk/d64 /dev/md/rdsk/d64 /xyzfs ufs 2 yes -

The metastat command verifies that the log is being
shared. Logging becomes effective for the file system when the system is rebooted.

Upon subsequent reboots, instead of checking the file system,
the fsck command displays these messages for the two file
systems:

/dev/md/rdsk/d63: is logging.
/dev/md/rdsk/d64: is logging.

Recovering Transactional Volumes
When Errors Occur

How to Recover a Transactional Volume
With a Panic

Step

For file systems that the fsck command cannot repair, run the fsck command
on each transactional volume whose file systems share the affected log device.

Example 19–11 Recovering a Transactional Volume

# fsck /dev/md/rdsk/trans

Only after all of the affected transactional volumes have been
checked and successfully repaired will the fsck command
reset the state of the failed transactional volume to “Okay.”

How to Recover a Transactional Volume
With Hard Errors

Use this procedure to transition a transactional volume to the “Okay”
state.

If either the master device or log device encounters errors while processing
logged data, the device transitions from the “Okay” state to the “Hard
Error” state. If the device is in the “Hard Error” or “Error”
state, either a device error or panic occurred. Recovery from both scenarios
is the same.

Note –

If a log (log device)
is shared, a failure in any of the slices in a transactional volume will result
in all slices or volumes that are associated with the transactional volume
switching to a failed state.

Affected file systems are listed with a lock type of hard.
Every file system that shares the same log device would be hard locked.

Unmount the affected file system(s).

You can unmount locked file systems even if they were in use
when the error occurred. If the affected processes try to access an opened
file or directory on the hard locked or unmounted file system, an error is
returned.

(Optional) Back up
any accessible data.

Before you attempt to fix the device error,
you might want to recover as much data as possible. If your backup procedure
requires a mounted file system (such as the tar command
or the cpio command), you can mount the file system read-only.
If your backup procedure does not require a mounted file system (such as the dump command or the volcopy command), you can
access the transactional volume directly.

Fix the device error.

At this point, any attempt to open or mount the transactional volume for read-and-write
access starts rolling all accessible data on the log device to the appropriate
master devices. Any data that cannot be read or written is discarded. However,
if you open or mount the transactional volume for read-only access, the log
is simply scanned again and not rolled forward to the master devices, and
the error is not fixed. In other words, all data on the master device and
log device remains unchanged until the first read or write open or mount.

Run the fsck command
to repair the file system, or the newfs command if you
need to restore data.

Run the fsck command
on all of the transactional volumes that share the same log device. When all
transactional volumes have been repaired by the fsck command,
they then revert to the “Okay” state.

The newfs command
will also transition the file system back to the “Okay” state,
but the command will destroy all of the data on the file system. The newfs command is generally used when you plan to restore file systems
from backup.

The fsck or newfs commands
must be run on all of the transactional volumes that share the same log device
before these devices revert back to the “Okay” state.

Run the metastat command
to verify that the state of the affected devices has reverted to “Okay.”

This example
shows a transactional volume, d5, which has a log device
in the “Hard Error” state, being fixed. You must run the fsck command on the transactional volume itself, which transitions
the state of the transactional volume to “Okay.” The metastat command confirms that the state is “Okay.”