Solaris Volume Manager Administration Guide

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