This chapter provides information about performing tasks that are associated with transactional volumes. For information about the concepts involved in these tasks, see Chapter 18, 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.
The following task map identifies the procedures needed to manage Solaris Volume Manager transactional volumes.
Task |
Description |
Instructions |
---|---|---|
Create a transactional volume |
Use the Solaris Volume Manager GUI or the metainit command to create a transactional volume. | |
Convert transactional volumes to UFS logging |
Use the metaclear and mount commands to clear a transactional volume and mount the file system with UFS logging. | |
Check the status of transactional volumes |
Use the Solaris Volume Manager GUI or the metastat command to check the status of a transactional volume. | |
Attach a log device to a transactional volume |
Use the Solaris Volume Manager GUI or the metattach command to attach a log device. | |
Detach a log device from a transactional volume |
Use the Solaris Volume Manager GUI or the metadetach command to detach a log device. | |
Expand a transactional volume |
Use the Solaris Volume Manager GUI or the metattach command to expand a transactional volume. | |
Delete a transactional volume |
Use the Solaris Volume Manager GUI, the metadetach command, or the metarename command to delete a transactional volume. | |
Delete a transactional volume and retain the mount point |
Use the Solaris Volume Manager GUI or the metadetach command to delete a transactional volume. |
How to Remove a Transactional Volume and Retain the Mount Device |
Share a log device |
Use the Solaris Volume Manager GUI or the metainit command to share a transactional volume log device. | |
Recover a transactional volume with a file system panic |
Use the fsck command to recover a transactional volume with a panic. | |
Recover a transactional volume with hard errors |
Use the fsck command to recover a transactional volume with hard errors. |
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.
Solaris Volume Manager transactional volumes do not support large (greater than 1TB) volumes. In all cases, UFS logging should be used. For more information, see mount_ufs(1M). See Overview of Large Volume Support in Solaris Volume Manager for more information about large volume support in Solaris Volume Manager.
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
If possible, unmount the UFS file system for which you want to enable logging.
# umount /export |
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 -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 |
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:
#/dev/dsk/c0t0d0s6 /dev/rdsk/c0t0d0s6 /export ufs 2 yes - /dev/md/dsk/d10 /dev/md/rdsk/d10 /export ufs 2 yes - |
If possible, remount the file system.
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.
# 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 |
# 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.
# 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 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.
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.
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.
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 |
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 |
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 # |
Flush the log for the file system that is logged with lockfs -f.
# /usr/sbin/lockfs -f /mnt/transvolume |
Unmount the file system.
# umount /mnt/transvolume |
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.
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 |
Remount the file system.
# mount /mnt/transvolume |
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.
# 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 |
If you changed to single-user mode during the process, you can now return to multiuser mode.
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. |
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.
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 |
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
Unmount the UFS file system for which you want to enable logging.
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 |
Remount the file system.
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 |
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
See the metadetach(1M) man page for more information.
Remount the file system.
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 |
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).
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
If the master device is a mirror, you need to attach additional slices to each submirror.
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.
# 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.
For a UFS, run the growfs command on the transactional volume (not the master device). See How to Expand a File System.
An application, such as a database, that uses the raw volume must have its own way of growing the added space.
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
See the metadetach(1M) man page for more information.
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.
If necessary, update /etc/vfstab to mount the underlying volume, rather than the transactional volume you just cleared.
Remount the file system.
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 |
This procedure works only for situations in which the transactional volume and the underlying device are both Solaris Volume Manager logical volumes.
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
See the metadetach(1M) man page for more information.
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.
Use the following form of the metaclear command:
metaclear master-volume |
See the metaclear(1M) man page for more information.
Run the fsck command on the master device.
When asked whether to fix the file system's state in the superblock, respond y.
Remount the file system.
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.
This procedure assumes that you have already set up a transactional volume with a log for another file system.
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
Use the following form of the metadetach command:
metadetach master-volume |
See the metadetach(1M) man page for more information.
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.
Edit the /etc/vfstab file to modify (or add) the entry for the file system to reference the transactional volume.
Remount the file system. If the file system cannot be unmounted, reboot the system to force your changes to take effect.
# 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. |
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.
# 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.”
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.
Check Prerequisites for Creating Solaris Volume Manager Components and Background Information for Transactional Volumes.
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.
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.”
# 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.”