Chapter 18 Transactional Volumes (Tasks)

This chapter provides information about performing tasks that are associated with transactional volumes. For information about the concepts involved in these tasks, see Chapter 17, Transactional Volumes (Overview).

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 (Task Map)

The following task map identifies the procedures needed to manage Solaris Volume Manager transactional volumes.

Creating Transactional Volumes

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

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

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

   ---

3. 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 -t master-device log-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.

     ---

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

   #/dev/dsk/c0t0d0s5 /dev/rdsk/c0t0d0s5 /export ufs 2 yes - /dev/md/dsk/d10 /dev/md/rdsk/d10 /export ufs 2 yes -

5. If possible, remount the file system.

   ---

   Note –

   If you are creating a transactional volume for a file system that cannot be unmounted, such as /usr, then reboot the system now to remount the transactional volume and start logging.

   ---

Example—Creating a Transactional Volume for a Slice

# umount /home1
# metainit d63 -t c0t2d0s2 c2t2d0s1
d63: Trans is setup
(Edit the /etc/vfstab file so that the file system references 
the transactional volume) 
# mount /home1

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—Creating a Transactional Volume for /usr

# metainit -f d20 -t c0t3d0s6 c1t2d0s1
d20: Trans is setup
(Edit the /etc/vfstab file so that the file system references 
the transactional volume)
# reboot

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—Creating a Transactional Volume for a Logical Volume

# umount /home1
# metainit d64 -t d30 d12
d64: Trans is setup
(Edit the /etc/vfstab file so that the file system references 
the transactional volume)
# mount /home1

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

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

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

   # metastat d2: Trans State: Okay Size: 2869209 blocks Master Device: d0 Logging Device: d20 d20: Logging device for d2 State: Okay Size: 28470 blocks d20: Concat/Stripe Size: 28728 blocks Stripe 0: (interlace: 32 blocks) Device Start Block Dbase State Reloc Hot Spare d10 0 No Okay No d11 0 No Okay No d12

   Note the names for these devices for later use.

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

   # df | grep d2 /mnt/transvolume (/dev/md/dsk/d2 ): 2782756 blocks 339196 files

3. Verify adequate free space on the transactional volume by using the df -k command.

   # df -k /mnt/transvolume file system kbytes used avail capacity Mounted on /dev/md/dsk/d2 1391387 91965 1243767 7% /mnt/transvolume

4. Stop all activity on the file system, either by halting applications or bringing the system to the single user mode.

   # init s [root@lexicon:lexicon-setup]$ init s INIT: New run level: S The system is coming down for administration. Please wait. Dec 11 08:14:43 lexicon syslogd: going down on signal 15 Killing user processes: done. INIT: SINGLE USER MODE Type control-d to proceed with normal startup, (or give root password for system maintenance): single-user privilege assigned to /dev/console. Entering System Maintenance Mode Dec 11 08:15:52 su: 'su root' succeeded for root on /dev/console Sun Microsystems Inc. SunOS 5.9 s81_51 May 2002 #

5. Flush the log for the file system that is logged with lockfs -f.

   # /usr/sbin/lockfs -f /mnt/transvolume

6. Unmount the file system.

   # umount /mnt/transvolume

7. Clear the transactional volume that contains the file system.

   This operation will not affect the data on the file system.

   # metaclear d2 d2: Trans is cleared

   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.

8. 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:

   #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/d0 /dev/md/rdsk/d0 /mnt/transvolume ufs 1 no logging

9. Remount the file system.

   # mount /mnt/transvolume

   ---

   Note –

   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.

   ---

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

    # grep mnt /etc/mnttab mnttab /etc/mnttab mntfs dev=43c0000 1007575477 /dev/md/dsk/d0 /mnt/transvolume ufs rw,intr,largefiles, logging,xattr,onerror=panic,suid,dev=1540000 1008085006

11. If you changed to single-user mode during the process, you can now return to multiuser mode.

Example—Converting From Transactional Volumes to UFS Logging

The following example shows the process of converting a transactional volume to UFS logging.

# metastat
    d50: Trans
    State: Okay         
    Size: 204687 blocks
    Master Device: c1t14d0s0
    Logging Device: c1t12d0s0

        Master Device       Start Block  Dbase Reloc
        c1t14d0s0                  0     No    Yes

c1t12d0s0: Logging device for d50
    State: Okay         
    Size: 30269 blocks

        Logging Device      Start Block  Dbase Reloc
        c1t12d0s0               5641     No    Yes

Make note of the 'master' and 'log' devices as you will need this
information in subsequent steps.

Determine if the transactional volume contains a mounted file system.

# df | grep d50
/home1             (/dev/md/dsk/d50   ):  161710 blocks    53701 files

Verify sufficient free space (more than 1 MByte)
# df -k /home1
filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d50        95510   14655   71304    18%    /home1

Go to single-user mode.

# /usr/sbin/lockfs -f /home1
# /usr/sbin/umount /home1
# /usr/sbin/metaclear d50
d50: Trans is cleared
Update /etc/vfstab file to mount underlying volume and add logging option.


# cat /etc/vfstab
#device             device               mount   FS   fsck    mount  
mount
#to mount           to fsck              point   type pass    at boot
options
/dev/dsk/c1t14d0s0  /dev/rdsk/c1t14d0s0  /home1  ufs  2       yes    
logging

# mount /home1
# /usr/bin/grep /home1 /etc/mnttab
/dev/dsk/c1t14d0s0      /home1  ufs
rw,intr,largefiles,logging,xattr,onerror=panic,suid,dev=740380
1008019906
Return to multi-user mode.

Maintaining Transactional Volumes

How to Check the State of Transactional Volumes

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.

• Use the metastat command.

  For more information, see the metastat(1M) man page.

Example—Checking the Status of Transactional Volumes

Here is sample transactional volume output from the metastat command:

# metastat
d20: Trans
    State: Okay        
    Size: 102816 blocks
    Master Device: c0t3d0s4
    Logging Device: c0t2d0s3
 
        Master Device       Start Block  Dbase
        c0t3d0s4                   0     No  
 
c0t2d0s3: Logging device for d0
    State: Okay        
    Size: 5350 blocks
 
        Logging Device      Start Block  Dbase
        c0t2d0s3                 250     No 

The metastat command also shows master devices and log devices. For each device, the following information is displayed:

• “Device”, which is the device name of the slice or volume

• “Start Block”, which is the block on which the device begins

• “Dbase”, which shows if the device contains a state database replica

• “State”, which shows the state of the log device

The following table explains transactional volume states and possible actions to take.

How to Attach a Log Device to a Transactional Volume

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

2. Unmount the UFS file system for which you want to enable logging.

3. 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-volume logging-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.

     See the metattach(1M) man page for more information.

   # metattach d1 d23

4. Remount the file system.

Example—Attaching a Log Device to a Transactional Volume

This example shows a log device, the slice (c1t1d0s1), being attached to the transactional volume d1, which is mounted on /fs2.

# umount /fs2
# metattach d1 c1t1d0s1
d1: log device d0c1t1d0s1 is attached
# mount /fs2

How to Detach a Log Device from a Transactional Volume

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

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

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

     See the metadetach(1M) man page for more information.

4. Remount the file system.

Example—Detaching a Log Device from a Transactional Volume

This example show a log device, the slice (c1t1d0s1), being detached from the transactional volume d1, which is mounted on /fs2.

# umount /fs2
# metadetach d1
d1: log device c1t1d0s1 is detached
# mount /fs2

How to Expand a Transactional Volume

You can expand a master device within a transactional volume only when the master device is a volume (RAID 0, RAID 1, or RAID 5).

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

2. 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-volume component

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

     component is the name of the volume or slice that should be attached.

     See the metattach(1M) man page for more information.

     ---

     Note –

     If the master device is a mirror, you need to attach additional slices to each submirror.

     ---

3. If the master device is a slice, you cannot expand it directly. Instead, you must do the following:

   • Clear the existing transactional volume.

   • Put the master device's slice into a volume.

   • Recreate the transactional volume.

   Once you have completed this process, you can expand the master device as explained in the previous steps of this procedure.

Example—Expanding a RAID 1 Master Device Within a Transactional Volume

# metastat d10
d10: Trans
    State: Okay        
    Size: 102816 blocks
    Master Device: d0
    Logging Device: d1
d0: Mirror
    Submirror 0: d11
      State: Okay
...
    Submirror 1: d12
      State: Okay        
...
# metattach d11 c0t2d0s5
d11: component is attached
# metattach d12 c0t3d0s5
d12: component is attached

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.

Where to Go From Here

For a UFS, run the growfs command on the transactional volume (not the master device). See How to Grow a File System.

An application, such as a database, that uses the raw volume must have its own way of growing the added space.

How to Remove a Transactional Volume

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

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

   # umount /filesystem

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

     See the metadetach(1M) man page for more information.

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

   • Use the following form of the metaclear command:

     metaclear master-volume

     See the metaclear(1M) man page for more information.

5. If necessary, update /etc/vfstab to mount the underlying volume, rather than the transactional volume you just cleared.

6. Remount the file system.

Example—Removing a Transactional Volume

This example shows the removal of a transactional volume d1, which was mounted on /fs2. The underlying slice, c1t1d0s1, is mounted directly after this procedure.

# umount /fs2
# metadetach d1
d1: log device d2 is detached
# metaclear d1 
d1: Trans is cleared

( Edit /etc/vfstab to update mount point for /fs2 to mount on c1t1d0s1, not d1)
# mount /fs2

How to Remove a Transactional Volume and Retain the Mount Device

This procedure works only for situations in which the transactional volume and the underlying device are both Solaris Volume Manager logical volumes.

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

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

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

     See the metadetach(1M) man page for more information.

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

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

   • Use the following form of the metaclear command:

     metaclear master-volume

     See the metaclear(1M) man page for more information.

6. Run the fsck command on the master device.

   When asked whether to fix the file system's state in the superblock, respond y.

7. Remount the file system.

Example—Removing a Transactional Volume While Retaining the Mount Device

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.

# metastat d1
d1: Trans
    State: Okay        
    Size: 5600 blocks
    Master Device: d21
    Logging Device: d0
 
d21: Mirror
    Submirror 0: d20
      State: Okay        
    Submirror 1: d2
      State: Okay        
...
 
d0: Logging device for d1
    State: Okay        
    Size: 5350 blocks
# umount /fs2
# metadetach d1
d1: log device d0 is detached
# metarename -f -x d1 d21
d1 and d21 have exchanged identities
# metastat d21
d21: Trans
    State: Detached    
    Size: 5600 blocks
    Master Device: d1
 
d1: Mirror
    Submirror 0: d20
      State: Okay        
    Submirror 1: d2
      State: Okay
# metaclear 21
# fsck /dev/md/dsk/d1
** /dev/md/dsk/d1
** Last Mounted on /fs2
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
 
FILE SYSTEM STATE IN SUPERBLOCK IS WRONG; FIX? y
 
3 files, 10 used, 2493 free (13 frags, 310 blocks, 0.5%
fragmentation)
# mount /fs2

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.

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

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

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

   • Use the following form of the metadetach command:

     metadetach master-volume

     See the metadetach(1M) man page for more information.

4. 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-volume logging-volume

     See the metattach(1M) man page for more information.

5. Edit the /etc/vfstab file to modify (or add) the entry for the file system to reference the transactional volume.

6. Remount the file system. If the file system cannot be unmounted, reboot the system to force your changes to take effect.

Example—Sharing a Logging Device

# umount /xyzfs
# metainit d64 -t c0t2d0s4 d10
d64: Trans is setup
(Edit the /etc/vfstab file so that the entry for /xyzfs references 
the transactional volume d64)
# mount /xyzfs
# metastat
...
d10: Logging device for d63 d64
...

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

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

See How to Check the State of Transactional Volumes to check the status of a transactional volume.

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.

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.

1. Check Prerequisites for Creating Solaris Volume Manager Elements and Background Information for Transactional Volumes.

2. Read Background Information for Transactional Volumes.

3. Run the lockfs command to determine which file systems are locked.

   # lockfs

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

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

5. (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.

6. 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 rescanned 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.

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

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

Example—Logging Device Error

# metastat d5
d5: Trans
    State: Hard Error  
    Size: 10080 blocks
    Master Device: d4
    Logging Device: c0t0d0s6
 
d4: Mirror
    State: Okay
...
c0t0d0s6: Logging device for d5
    State: Hard Error
    Size: 5350 blocks
...
# fsck /dev/md/rdsk/d5
** /dev/md/rdsk/d5
** Last Mounted on /fs1
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
WARNING: md: log device: /dev/dsk/c0t0d0s6 changed state to
Okay
4 files, 11 used, 4452 free (20 frags, 554 blocks, 0.4%
fragmentation)
# metastat d5
d5: Trans
    State: Okay
    Size: 10080 blocks
    Master Device: d4
    Logging Device: c0t0d0s6
 
d4: Mirror
    State: Okay
...
 
c0t0d0s6: Logging device for d5
    State: 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.”