Operation of Mirrors

Mirroring is accomplished by the creation of metamirrors. A metamirror is a special type of metadevice that is made up of one or more other metadevices (concatenations or stripes). Each metadevice within a metamirror is called a submirror.

Mirrors or metamirrors use the same naming convention used for other metadevices. After a metamirror is defined, additional submirrors can be added at any time without disruption of writes or reads to the existing metamirror.

Metamirrors should be defined with a single submirror using the metainit command. Additional submirrors must be added with the metattach command. Metamirrors can also be defined in the /etc/opt/SUNWmd/md.tab file, but you must run metainit to activate them. When you are mirroring existing file systems or data, be sure that the existing data is contained on the submirror initially defined with the metamirror. When a second submirror is subsequently attached, data from the initial submirror is copied onto the attached submirror.

In general, it is best to avoid creating multi-way metamirrors using the metainit command without attaching the other submirrors. For example, the following use of the metainit command is not recommended:

# metainit d0 -m d1 d2

When you use metainit in this manner, the following message is displayed:

WARNING: This form of metainit is not recommended. The submirrors may not have the same data. Please see ERRORS in metainit(1M) for additional information.

When the metattach command is not used to attach the additional submirrors, no resync operation occurs.

---

Caution - In cases where you are mirroring existing data, be sure that the initial submirror contains the data.

---

One-way metamirrors (containing a single submirror), can be defined either in the /etc/opt/SUNWmd/md.tab file, or with the metainit command directly from the command line. For convenience, it is recommended that all simple metadevices be defined using the /etc/opt/SUNWmd/md.tab file. This will make manual operations (attaching, detaching, and replacing metadevices) easier to deal with.

There are basically two ways in which you can set up metamirrors:

• By defining one-way metamirrors in the /etc/opt/SUNWmd/md.tab file, running the metainit command with the -a option, and then performing subsequent instances of the metattach command (or use a shell script) to attach the submirrors.
• By defining one-way mirrors using the metainit command either manually or from a shell script, and then performing subsequent additions of submirrors using the metattach command.

The examples in this chapter show metadevices and one-way metamirrors defined in the /etc/opt/SUNWmd/md.tab file. Subsequent submirror additions are shown separately below the md.tab file definitions.

---

Note - Remember that definitions in the /etc/opt/SUNWmd/md.tab file do not become effective until they are activated using the metainit command.

---

An example is a metamirror that is made up of four physical components and two submirrors (metadevices). The physical components are named /dev/dsk/c0t0d0s0, /dev/dsk/c1t0d0s0, /dev/dsk/c2t0d0s0, and /dev/dsk/c3t0d0s0. The two submirrors are named /dev/md/dsk/d1 and /dev/md/dsk/d2. The metamirror is named /dev/md/dsk/d50.

To set up this metamirror using the /etc/opt/SUNWmd/md.tab file, you would add the following:

# # mirror concatenation of two components # /dev/md/dsk/d50 -m /dev/md/dsk/d1 /dev/md/dsk/d1 2 1 /dev/dsk/c0t0d0s0 1 /dev/dsk/c1t0d0s0 /dev/md/dsk/d2 2 1 /dev/dsk/c2t0d0s0 1 /dev/dsk/c3t0d0s0

In the above /etc/opt/SUNWmd/md.tab entry, the -m specifies the one-way mirror consists of the metadevice, /dev/md/dsk/d1. The two metadevices to be used as submirrors are then defined in the two lines that follow. (The metadevices are concatenations, as explained in Chapter 4, "Concatenating and Striping.")

To activate the metamirror you've defined, you would use the metainit command with the -a option as follows::

# metainit -a

The second metadevice is then attached with the metattach command as follows:

# metattach d50 d2

The metadevice, /dev/md/dsk/d2 is now a submirror for the metamirror /dev/md/dsk/d50.

Defining Metamirrors

All metamirrors that have been defined in the /etc/opt/SUNWmd/md.tab file can be configured at the same time or they can be configured individually using the metainit(1M) command. metainit configures the metadevices according to the configurations specified either on the command line or in the /etc/opt/SUNWmd/md.tab file.

When used with the -a option, metainit configures all metadevices defined in the /etc/opt/SUNWmd/md.tab file. If metainit -a is used, all submirrors are configured before the metamirror, regardless of the order in which the entries are made in the /etc/opt/SUNWmd/md.tab file.

If metainit is used to configure a metamirror and any of the submirrors are not configured at the time, metainit fails. For example, assume the following entries are made in the /etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d25 -m /dev/md/dsk/d26 /dev/md/dsk/d26 1 1 /dev/dsk/c0t1d0s0 /dev/md/dsk/d27 1 1 /dev/dsk/c0t2d0s0

Running metainit -a would activate the submirrors /dev/md/dsk/d26 and /dev/md/dsk/d27 and then activate the one-way mirror /dev/md/dsk/d25. If the submirrors and metamirror are activated individually, they should be done as follows:

# /usr/etc/metainit /dev/md/dsk/d27 # /usr/etc/metainit /dev/md/dsk/d26 # /usr/etc/metainit /dev/md/dsk/d25

Next, you would use the metattach command to attach the submirror /dev/md/dsk/d27 to the metamirror /dev/md/dsk/d25 as follows:

# /usr/etc/metattach /dev/md/dsk/d25 /dev/md/dsk/d27

Metamirror Options

DiskSuite supports several options to optimize metamirror performance for needs at individual sites. These options deal with:

• Setting the order in which metamirrors are resynced during reboot
• Read policy for metamirrors
• Write policy for metamirrors

You define these options using the metainit command when you initially configure a metamirror, or using the metaparam command after the metamirror has been set up. For more information regarding using the metaparam command, see "Changing Metamirror and Submirror Options" on page 97 or the metaparam(1M) manpage.

Resync Options

A pass number in the range 0-9 at the end of an entry defining a metamirror determines the order in which that mirror is resynced during a system reboot. The default is 1. Smaller pass numbers are resynced first. If 0 is used, the resync is skipped. A 0 should only be used for metamirrors mounted as read only. If different metamirrors have the same pass number, they are resynced concurrently. The following example shows three metamirrors defined in a /etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d51 -m /dev/md/dsk/d52 2 /dev/md/dsk/d61 -m /dev/md/dsk/d62 2 /dev/md/dsk/d71 -m /dev/md/dsk/d72

In the above example, the metamirror /dev/md/dsk/d71 is resynced first, then /dev/md/dsk/d51 and /dev/md/dsk/d61 are resynced concurrently.

Read Options

There are three kinds of read options associated with metamirrors. The default read option is ''balanced load.'' The balanced load means all reads are made in a round-robin order from all the submirrors in the metamirror.

If a -g is specified following a metamirror entry in the /etc/opt/SUNWmd/md.tab file or following a command line metamirror entry with the metainit utility, the metadisk driver performs ''geometric'' reads. This option provides faster performance on sequential reads or when you're using disks with track buffering.

Geometric reads allow read operations to be divided among submirrors on the basis of a logical disk block address. For instance, with a three-way submirror the disk space on the metamirror is divided into three (equally sized) logical address ranges. Reads from the three regions are then performed by separate submirrors (for example, reads to the first region are performed by the first submirror).

If a -r option is specified, all reads are directed to the first submirror. This option cannot be used in conjunction with a -g.

The following example illustrates the use of the -r and -g options:

# metainit /dev/md/dsk/d75 -m /dev/md/dsk/d76 -g # metattach /dev/md/dsk/d75 /dev/md/dsk/d77 # metainit /dev/md/dsk/d80 -m /dev/md/dsk/d81 -r # metattach /dev/md/dsk/d80 /dev/md/dsk/d82

In the above example, reads from the /dev/md/dsk/d75 metamirror will be performed geometrically from the two submirrors (/dev/md/dsk/d76 and /dev/md/dsk/d77). When reads are made from the /dev/md/dsk/d80 metamirror the submirror, /dev/md/dsk/d81, will be used.

Write Options

Writes to the submirror of a metamirror are either performed in parallel or serially. Parallel writes are the default action of the metadisk driver, meaning the writes are dispatched to all submirrors simultaneously. If a -S (uppercase 's') option is specified following a metamirror, the writes happen serially in the order in which the submirrors are specified in the metamirror. The following is an example of a metamirror defined with the -S option.

# metainit /dev/md/dsk/d90 -m /dev/md/dsk/d91 -S # metattach /dev/md/dsk/d90 /dev/md/dsk/d92 # metattach /dev/md/dsk/d90 /dev/md/dsk/d93

In the above example, a write to /dev/md/dsk/d90 will first write the data to /dev/md/dsk/d91. Once the write to /dev/md/dsk/d91 is complete, a write to /dev/md/dsk/d92 begins and after it finishes, the write to the third submirror, /dev/md/dsk/d93, will be made.

Resyncing Mirrors

If submirrors need to be replaced, attached, or taken offline for other reasons, the submirrors must be resynced. Resyncing is the act of copying data from one submirror to another and ensures the data on all submirrors is identical. DiskSuite offers two types of resyncing:

• Full resync
• Optimized resync

These resyncs both perform the basic function of copying data from a readable submirror to another submirror. While this copy takes place, the metamirror remains readable and writable by users.

A full resync must be performed when a new submirror is added to a metamirror and the user wants to bring it in sync with other submirrors that are part of that metamirror. Full resyncs are performed whenever the metattach(1M) command is used.

metattach attaches metadevices to metamirrors and resyncs the newly attached submirror to the mirror. The metadevices remain attached, even during system reboots, until the metadetach command is run.

If the system crashes while any resync is in progress, DiskSuite will finish the resync when the system comes back up.

An optimized resync occurs when the system boots following a crash or a reboot. Metamirror resyncs following a system crash are necessary because the crash may have interrupted a mirror write, thus some submirrors in the metamirror may be out of sync.

DiskSuite keeps track of regions of all mirrors. When a crash occurs, the metadisk driver knows which regions are not in sync. Subsequently, when the system reboots, only the regions that are not in sync are updated during this type of resync. For large metamirrors, this could be time consuming. This does not cause major problems during reboot, because system activity, including fsck(1M), can continue. However, system throughput is degraded.

metaonline(1M) performs an optimized resync similar to the type of optimized resync that is normally performed at boot time. metaonline only resyncs the data that was written to the metamirror while that submirror was offline.

Checking the Status of Mirrors

The metastat(1M) command is used to display the current status for each metadevice or hot spare pool, or of specified metadevices or hot spare pools. By default, all information pertaining to metadevices and hot spare pools is displayed by metastat.

The -p option can be used with metastat. When you specify the -p option, the output format is similar to that of the /etc/opt/SUNWmd/md.tab file. This option is mainly for viewing the metadevive configuration only; without status information.

The name of a metadevice or hot spare pool can be specified on the command line as an argument to the metastat command. If one is specified, only the information pertaining to that metadevice or hot spare pool is displayed.

If no metadevice or hot spare pool is specified, metastat displays information for all active metadevices and hot spare pools. An example of the default output from metastat follows:

# /usr/opt/SUNWmd/sbin/metastat d13: Mirror Submirror 0: d14 State: Needs maintenance Submirror 1: d15 State: Okay Submirror 2: d16 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 183750 blocks . . .

In the above output, information about the metamirror, /dev/md/dsk/d13, is displayed. metastat shows that the three submirrors, /dev/md/dsk/d14, /dev/md/dsk/d15, and /dev/md/dsk/d16 are configured. The state of each submirror is also provided. There are three possible states: ''Okay,'' ''Resyncing,'' and ''Needs maintenance.''

The next four lines deal with options that are set for the mirror. The ''Pass'' number defines when the mirrored metadevices will be resynced when the system reboots. The ''Read option'' specifies round-robin reads (the default). The ''Write option'' specifies parallel writes (the default). See "Metamirror Options" on page 70 and Appendix A, "Solstice DiskSuite Files" for additional information on setting up the /etc/opt/SUNWmd/md.tab file.

The size information is the total number of blocks included in the metamirror.

Output from metastat continues below with a submirror display.

. . . d14: Submirror of d13 State: Needs maintenance Invoke: metareplace /dev/md/dsk/d13 /dev/dsk/c0t3d0s0 \ <new device> Hot spare pool: hsp003 Size: 183750 blocks Stripe 0: Device Start Block Dbase State Hot Spare c0t2d0s0 0 No Okay Stripe 1: (Interlace = 16 blocks) Device Start Block Dbase State Hot Spare c0t3d0s0 630 Yes Maintenance c0t4d0s0 630 Yes Maintenance Stripe 2: Device Start Block Dbase State Hot Spare c0t0d0s0 0 No Maintenance . . .

In the above output, information about the submirror is displayed. metastat shows the metamirror (/dev/md/dsk/d13) which contains the submirror /dev/md/dsk/d14. The state of the submirror is shown on the second line.

There are four possible states: ''Okay,'' ''Resyncing,'' ''Maintenance,'' and "Last Erred." If ''Maintenance'' is displayed, the next line, ''Invoke'' specifies which command should be run to eliminate the problem. The interlace value is only shown if there are two or more devices in the stripe.

For example, to correct the maintenance required in the above example, the following command might be run:

# /usr/opt/SUNWmd/sbin/metareplace /dev/md/dsk/d13 \ /dev/dsk/c0t3d0s0 /dev/dsk/c0t5d0s0

In this example, the device, /dev/dsk/c0t5d0s0, is used for the "<new device>." It is possible that you may have to run metastat again to see if additional commands are needed to solve the ''Needs maintenance'' state.

The hot spare pool that has been assigned to the submirror is displayed on the following line. Next, the size of the submirror (in blocks) is displayed.

metastat also displays information about each component in the stripe, as shown with a separate entry. Each entry consists of the ''Device,'' ''Start Block,'' ''Dbase,'' ''State,'' and ''Hot Spare.''

The ''Device'' is the name of the device that is in the stripe.

The ''State'' is the state of the device, which is either ''Okay,'' ''Resyncing,'' ''Maintenance,'' or "Last Erred." These states are defined as follows:

• "Okay" - The component is operating properly.
• "Resyncing" - The component is actively being resync'ed.
• "Maintenance" - The component has encountered an I/O error or an open error. All reads and writes to and from this component have been discontinued. See "Replacing and Enabling Submirror Components" on page 96 for information on component replacement.
• "Last Erred" - The component has encountered an I/O error or an open error, however, the data is not replicated elsewhere due to another component failure. I/O is still performed on the component. If I/O errors result, the mirror I/O will fail. See "Replacing and Enabling Submirror Components" on page 96 for information on component replacement.

The ''Start Block'' is the block on which the component begins.

The ''Dbase'' field specifies whether or not a database resides on the component.

The final field is ''Hot Spare'' which specifies the device name of the hot spare that has been used for a replacement when the device failed.

Output from metastat continues below with a metadevice display.

. . . d60: Concat/Stripe Size: 183750 blocks Stripe 0: (61250 blocks) Device Start Block Dbase c1t1d0s1 0 No Stripe 1: (61250 blocks) Device Start Block Dbase c1t2d0s1 1034 Yes Stripe 2: (61250 blocks) Device Start Block Dbase c1t3d0s1 0 No . . .

First, the metadevice output contains the device name of the metadevice, /dev/md/dsk/d60. The size of the metadevice in blocks is shown on the second line.

The components, which are shown as a concatenation of stripes, are shown on separate lines. Information about each component in the stripe is shown with a separate entry followed by the size, in blocks, of the stripe. Each entry consists of the ''Device,'' ''Start Block,'' and ''Dbase.''

The ''Device'' is the name of the device that is in the stripe. The ''Start Block'' is the block on which the component begins. The ''Dbase'' field specifies whether or not a database resides on the component.

---

Note - State and hot spare information for stripes which are not submirrors is not retained by DiskSuite.

---

Mirroring Existing File Systems

Once the DiskSuite software package is installed, you can mirror existing file systems without backing up data or reconfiguring devices.

To mirror an existing file system, you must use an additional component of equal or greater size. It is possible to use a concatenation of two or more components that have adequate space available to contain the mirror. For example, if /export/home is mounted on a 1-Gbyte component named /dev/dsk/c0t0d0s0, at least 1-Gbyte of space must be available on the metadevice that is being defined for the new submirror.

When you mirror an existing file system, be sure that you initially configure a one-way metamirror with a submirror containing the existing file system. A submirror that you add subsequently with the metattach command should not contain any data that is needed, since it will overwritten by the resync following the metattach command. For a more detailed explanation of this process, see "Mirroring an Existing File System" in the "Examples" section at the end of this chapter.

Unmirroring File Systems

The procedure for unmirroring a file system that is not root, swap, or /usr, consists of the following steps:

1. Unmounting the file system

2. Running metadetach(1M) on the submirror that will continue to be used for the file system

3. Running metaclear(1M) on the mirror

4. Changing the file system entry in the /etc/vfstab file to use a nonmirror device, if the file system entry appears there

5. Removing the metamirror and submirror entries from the /etc/opt/SUNWmd/md.tab file

6. Remounting the file system

Example of Unmirroring a File System

The following is an example of unmirroring the /var file system. In this example, /var is made up of a two-way mirror with the names d2 and d3 in a mirror named, d4. The names of the components are /dev/dsk/c0t0d0s0 and /dev/dsk/c1t0d0s0.

# /sbin/umount /var # /usr/opt/SUNWmd/sbin/metadetach /dev/md/dsk/d4 /dev/md/dsk/d2 # /usr/opt/SUNWmd/sbin/metaclear -r /dev/md/dsk/d4

After you run the above commands, you must change the entry in the /etc/vfstab file (if one appears for /var). For example, the following line:

/dev/md/dsk/d4 /dev/md/rdsk/d4 /var ufs 4 yes --

should be changed to read:

/dev/md/dsk/d2 /dev/md/rdsk/d2 /var ufs 4 yes --

By using the metadevice name, /dev/md/dsk/d2 instead of /dev/md/dsk/d4, you have performed the unmirroring. By using /dev/md/dsk/d2 rather than the component name (for example, /dev/dsk/c0t0d0s0), you can continue to have the device support either a concatenation or a stripe.

The /var file system can be remounted.

# /sbin/mount /var

root, swap, and /usr Mirroring

The key feature that makes mirroring of the root, swap, and /usr file systems possible is that the state database locations are patched into the metadisk driver via the /etc/system file. Since the kernel has knowledge of the state database early in the boot process, it can obtain all the information it needs about all metadevices. This is explained further in Chapter 2, "Installation and Setup" and Chapter 8, "Disksets." Additional information about the mddb.cf file is provided in Appendix A, "Solstice DiskSuite Files."

---

Note - If problems occur when mirroring root, swap, and /usr, refer to Appendix C, "Recovery From Failed Boots.''

---

Mirroring /usr

There are seven basic steps involved with mirroring the /usr file system. In the following example, /dev/dsk/c0t3d0s6 is the existing device where /usr resides. The component used for the mirror of this file system is /dev/dsk/c1t0d0s6. The steps used to mirror /usr are:

1. Specify a metadevice for the existing file system by making an entry in the /etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d12 1 1 /dev/dsk/c0t3d0s6

2. Specify the one-way mirror in the /etc/opt/SUNWmd/md.tab file by inserting the following line:

/dev/md/dsk/d2 -m /dev/md/dsk/d12

3. Specify a metadevice for the new submirror on the other half of the mirror by entering the following in the /etc/opt/SUNWmd/md.tab file:

/dev/md/dsk/d22 1 1 /dev/dsk/c1t3d0s6

The number of blocks in /dev/dsk/c1t3d0s6 must be greater or equal to the number of blocks in /dev/dsk/c0t3d0s6. Otherwise, the metattach command in Step 7 of this procedure will fail.

4. Run the metainit command for each of the metadevices and the metamirror defined in the /etc/opt/SUNWmd/md.tab file. Note that a -f option is used with metainit for /dev/md/dsk/d12 because the component being used has /usr currently mounted (see Step 1). metainit normally fails if the component has a file system currently mounted, but the -f force option allows the metadevice to be activated.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d22 # /usr/opt/SUNWmd/sbin/metainit -f /dev/md/dsk/d12 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d2

5. Edit the /etc/vfstab file to change the entry for the /usr file system to be the newly defined metadevice name rather than the component name. For example, change the following line:

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

to read:

/dev/md/dsk/d2 /dev/md/rdsk/d2 /usr ufs 2 no -

6. Reboot the system using the reboot(1M) command.

# /usr/sbin/reboot

7. Attach the new metadevice to the one-way mirror, using the

   metattach(1M) command.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d2 /dev/md/dsk/d22

Once the above steps are performed, a resync of the mirror begins automatically, which copies all the data that exists on d12 (/dev/dsk/c0t3d0s6) to the submirror d2 (/dev/dsk/c1t3d0s6).

Mirroring root

The procedure for mirroring root on an x86 system is somewhat different from the procedure used for a SPARC system. Use the procedure described in one of the following two sections to set up root mirroring on your system.

---

Caution - When you are mirroring the root file system it is essential that you record the secondary root slice name in order to reboot the system if the primary submirror fails. This information should be written down, not recorded on the system which may not be available. Read either the section, "Booting From the Alternate Device -- SPARC System" on page 83 or "Booting From the Alternate Device -- x86 System" on page 89 for details.

---

Mirroring root on a SPARC System

There are eight basic steps involved with mirroring the root file system on a SPARC system. In the following example, /dev/dsk/c0t3d0s0 is the existing device where root resides. The component used to mirror this component is

/dev/dsk/c1t3d0s0.

Setting Up a Root Mirror -- SPARC System Follow these steps to mirror root on a SPARC system:

1. Create a metadevice for the existing file system by making an entry in the

/etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d10 1 1 /dev/dsk/c0t3d0s0

2. Create the one-way mirror in the /etc/opt/SUNWmd/md.tab file by inserting the following line:

/dev/md/dsk/d0 -m /dev/md/dsk/d10

3. Create a metadevice for the new component on the other half of the mirror by entering the following in the /etc/opt/SUNWmd/md.tab file:

/dev/md/dsk/d20 1 1 /dev/dsk/c1t3d0s0

4. Run the metainit(1M) command for each of the metadevices and the metamirror defined in the /etc/opt/SUNWmd/md.tab file. Note that a -f option is used with metainit for d10 because the component being used has root currently mounted (see Step 1). metainit normally fails if the component has a file system currently mounted, but the -f force option allows the metadevice to be activated.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d20 # /usr/opt/SUNWmd/sbin/metainit -f /dev/md/dsk/d10 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d0

5. Run the metaroot(1M) command. metaroot edits the /etc/system and /etc/vfstab to add information necessary to mirror root.

# /usr/opt/SUNWmd/sbin/metaroot /dev/md/dsk/d0

6. Reboot the system using the reboot(1M) command.

# /usr/sbin/reboot

7. Attach the new metadevice to the one-way mirror, using the metattach command.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d0 /dev/md/dsk/d20

Once the above steps are performed, a resync of the mirror begins automatically, which copies all the data that exists on d10 (/dev/dsk/c0t3d0s0) to the submirror d20 (the component named /dev/dsk/c1t3d0s0).

8. Record the path to the alternate root device. You may need this later if the primary device fails.

   In this example, you would determine the path to the alternate root device by entering:

# ls -l /dev/rdsk/c1t3d0s0 lrwxrwxrwx 1 root root 55 Mar 5 12:54 /dev/rdsk/c1t3d0s0 -> ../. ./devices/sbus@1,f8000000/esp@1,200000/sd@3,0:a

So you would record: /sbus@1,f8000000/esp@1,200000/sd@3,0:a

Booting From the Alternate Device -- SPARC System To boot your SPARC system from the alternate boot device, you would type:

# boot /sbus@1,f8000000/esp@1,200000/sd@3,0:a

---

Note - Backup Copilot users who are using system with open boot prom can use the OpenBoot nvalias command to define a "backup root" devalias for the secondary root mirror. For example:

ok nvalias backup_root /sbus@1,f8000000/esp@1,200000/sd@3,0:a In the event of primary root disk failure, you then would only enter: ok boot backup_root

---

Mirroring root on an x86 System

Before mirroring the root file system on an x86 system, you must first set up a Solaris partition large enough for your root mirror. For the purpose of the following procedures, we'll assume that the alternate disk is c0t1d0.

Creating a Solaris Partition Follow these steps to create a Solaris partition on an x86 system:

1. Create the disk partition using the fdisk command as follows:

# fdisk /dev/rdsk/c0t1d0p0

• If this is the first time you have run fdisk, the following is displayed:

The recommended default partitioning for your disk is: a 100% "SOLARIS System" partition To select this, please type "y". To partition your disk differently, type "n" and the "fdisk" program will let you select other partitions.

• If you have previously run fdisk, you see a menu similar to the following:

Total disk size is 1855 cylinders Cylinder size is 1110 (512 byte) blocks Partition Status Type Start End Length % ========= ====== ======== ===== === ====== === 1 Active SOLARIS 1 1854 1854 100 SELECT ONE OF THE FOLLOWING: 1. Create a partition 2. Change Active (Boot from) partion 3. Delete a partition 4. Exit (Update disk configuration and exit) 5. Cancel (Exit without updating disk configuration) Enter Selection:

2. Select menu items to ensure that you have a Solaris partition large enough for your root mirror. Your Solaris partition should be five cylinders larger than the size needed to hold your root slice.

---

Note - Make sure that the Solaris partition is active. Otherwise, you will be unable to boot from it.

---

3. Use the format program to format the Solaris partition and create a slice for your root mirror as follows:

# format Searching for disks...done AVAILABLE DISK SELECTIONS: 0. c0t0d0 <drive type unknown> /eisa/eha@1000,0/cmdk@0,0 1. c0t1d0 <DEFAULT cyl 1852 alt 2 hd 15 sec 74> /eisa/eha@1000,0/cmdk@1,0 2. c0t2d0 <SUN0207 cyl 1254 alt 2 hd 9 sec 36> /eisa/eha@1000,0/cmdk@2,0 Specifiy disk (enter its number): 1 selecting c0t1d0 [disk formatted] FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk fdisk - run the fdisk program repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name quit

4. Use the partition command to define a partition as follows:

format> partition PARTITION MENU: 0 - change '0' partition 1 - change '1' partition 2 - change '2' partition 3 - change '3' partition 4 - change '4' partition 5 - change '5' partition 6 - change '6' partition 7 - change '7' partition select - select a predefined table modify - modify a predefined partition table name - name the current table print - display the current table label - write partition map and label to the disk quit partition> 0 Part Tag Flag Cylinders Size Blocks 0 unassigned wm 0 0 (0/0/0) Enter partition id tag [unassigned]: root Enter partition permission flags [wm]: wm Enter new starting cyl [0]: 4 Enter partition size [0b, 0c, 0.00mb]: 400mb partition> label Ready to label disk, continue? y partition>

5. Exit from the partition menu and the format program by typing the quit command twice.

   For example:

partition> quit FORMAT MENU: disk - select a disk type - select (define) a disk type partition - select (define) a partition table current - describe the current disk format - format and analyze the disk repair - repair a defective sector label - write label to the disk analyze - surface analysis defect - defect list management backup - search for backup labels verify - read and display labels save - save new disk/partition definitions inquiry - show vendor, product and revision volname - set 8-character volume name quit format> quit

Note the following important points about your Solaris root partition:

• Its id tag must be "root"
• Its size must be greater than or equal to the size of the original root partition
• It should not use cylinders 0-2

6. Install the boot information on the alternate boot disk as follows:

# installboot /usr/lib/fs/ufs/pboot \ /usr/lib/fs/ufs/bootblk \ /dev/rdsk/c0t1d0s2

Setting Up a Root Mirror -- x86 System After you have completed the above procedure for creating a Solaris partition, you can mirror the root file system. The steps to mirror root on an x86 system are as follows:

1. Create a metadevice for the existing file system by making an entry in the

/etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d10 1 1 /dev/dsk/c0t0d0s0

2. Create the one-way mirror in the /etc/opt/SUNWmd/md.tab file by inserting the following line:

/dev/md/dsk/d0 -m /dev/md/dsk/d10

3. Create a metadevice for the new component on the other half of the mirror by entering the following in the /etc/opt/SUNWmd/md.tab file:

/dev/md/dsk/d20 1 1 /dev/dsk/c1t0d0s0

4. Run the metainit(1M) command for each of the metadevices and the metamirror defined in the /etc/opt/SUNWmd/md.tab file. Note that a -f option is used with metainit for d10 because the component being used has root currently mounted (see Step 1). metainit normally fails if the component has a file system currently mounted, but the -f force option allows the metadevice to be activated.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d20 # /usr/opt/SUNWmd/sbin/metainit -f /dev/md/dsk/d10 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d0

5. Run metaroot(1M) command. metaroot edits the /etc/system and /etc/vfstab to add information necessary to mirror root.

# /usr/opt/SUNWmd/sbin/metaroot /dev/md/dsk/d0

6. Reboot the system using the reboot(1M) command.

# /usr/sbin/reboot

7. Attach the new metadevice to the one-way mirror, using the metattach command.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d0 /dev/md/dsk/d20

Once the above steps are performed, a resync of the mirror begins automatically, which copies all the data that exists on d10 (/dev/dsk/c0t0d0s0) to the submirror d20 (the component named /dev/dsk/c1t0d0s0).

8. Record the path to the alternate root device. You may need this later if the primary device fails.

   In this example, you would determine the path to the alternate root device by:

# ls -l /dev/rdsk/c1t0d0s0 lrwxrwxrwx 1 root root 55 Mar 5 12:54 /dev/rdsk/c1t0d0s0 -> ../. ./devices/eisa/eha@1000,0/cmdk@1,0:a

So you would record: /eisa/eha@1000,0/cmdk@1,0:a

Booting From the Alternate Device -- x86 System To boot your x86 system from the alternate boot device, complete the following steps:

1. Boot your system from the Multiple Device Boot (MDB) diskette.

   After a moment, a screen similar to the following is displayed:

Solaris/x86 Multiple Device Boot Menu Code Device Vendor Model/Desc Rev ============================================================ 10 DISK COMPAQ C2244 0BC4 11 DISK SEAGATE ST11200N SUN1.05 8808 12 DISK MAXTOR LXT-213S SUN0207 4.24 13 CD SONY CD-ROM CDU-8812 3.0a 14 NET SMC/WD I/O=300 IRQ=5 80 DISK First IDE drive (Drive C:) 81 DISK Second IDE drive (Drive D:) Enter the boot device code:11

2. Select your alternate disk from the above screen.

   The following is displayed:

Solaris 2.4 for x86 Secondary Boot Subsystem,vsn 2.11 <<<Current Boot Parameters>>> Boot path:/eisa/eha@1000,0/cmdk@0,0:a Boot args:/kernel/unix Type b[file-name] [boot-flags] <ENTER> to boot with options or i<ENTER> to enter boot interpreter or <ENTER> to boot with defaults <<<timeout in 5 seconds>>>

3. Type i to select the interpreter.

4. Enter the following commands:

>setprop boot-path /eisa/eha@1000,0/cmdk@1,0:a >^D

Mirroring swap

There are seven basic steps involved with mirroring the swap partition. In the following example, /dev/dsk/c0t0d0s1 is the existing device where swap resides. The component used to mirror this component is /dev/dsk/c1t0d0s1. The steps used to mirror swap are:

1. Create a metadevice for the existing file system by making an entry in the

/etc/opt/SUNWmd/md.tab file.

/dev/md/dsk/d11 1 1 /dev/dsk/c0t0d0s1

2. Create the one-way mirror in the /etc/opt/SUNWmd/md.tab file by inserting the following line:

/dev/md/dsk/d1 -m /dev/md/dsk/d11

3. Create a metadevice for the new component on the other half of the mirror by entering the following in the /etc/opt/SUNWmd/md.tab file:

/dev/md/dsk/d21 1 1 /dev/dsk/c1t0d0s1

4. Run the metainit command for each of the metadevices and the metamirror defined in the /etc/opt/SUNWmd/md.tab file. Note that the -f option is used with metainit for d10 because the component being used is currently being used as a swap device.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d21 # /usr/opt/SUNWmd/sbin/metainit -f /dev/md/dsk/d11 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d1

5. If an entry exists in the /etc/vfstab file that matches the partition on which the system was swapping, the file must be edited. (If such an entry does not exist, do not add one.) Change the name of the partition to the newly defined metadevice name rather than the partition name. For example, change the following line:

/dev/dsk/c0t3d0s1 - - swap - no -

to read:

/dev/md/dsk/d1 - - swap - no -

6. Reboot the system using the reboot(1M) command.

# /usr/sbin/reboot

7. Attach the new metadevice to the one-way mirror, using the metattach command.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d1 /dev/md/dsk/d21

Once these steps are performed, a resync of the mirror begins automatically. The resync copies all the data that exists on d11 (/dev/dsk/c0t0d0s1) to the submirror d21 (the component named /dev/dsk/c1t0d0s1).

Unmirroring root and swap File Systems

To unmirror any file system that is not root or swap, follow the instructions provided in "Unmirroring File Systems" on page 77. The procedure for unmirroring the root or swap file systems consists of six basic steps:

1. Making the metamirror that contains root, swap, or /usr into a one-way mirror

2. Changing the file system entry in the /etc/vfstab file to use a non-DiskSuite device

3. If you're unmirroring root, running the metaroot command

4. Rebooting the system

5. Using the metaclear command, to clear the metamirrors and submirrors that were used by root, swap, or /usr

6. Removing the entries from the /etc/opt/SUNWmd/md.tab file

Example of Unmirroring Both root and swap

The following is an example of unmirroring both the root and swap file systems. In this example, root is a two-way mirror (/dev/md/dsk/d0) with submirrors d10 and d20, which are made up of the components named /dev/dsk/c0t3d0s0 and /dev/dsk/c1t3d0s0, respectively. swap is a two-way mirror (/dev/md/dsk/d1) with submirrors d11 and d21, which are made up of the components named /dev/dsk/c0t3d0s1 and /dev/dsk/c1t3d0s1, respectively.

1. Make the metamirrors into a one-way mirror by using the

   metadetach(1M) command.

# /usr/opt/SUNWmd/sbin/metadetach /dev/md/dsk/d0 /dev/md/dsk/d20 # /usr/opt/SUNWmd/sbin/metadetach /dev/md/dsk/d1 /dev/md/dsk/d21

The submirrors are detached at this time because the machine is currently using the mirrors, thus the mirrors can not be cleared (using metaclear) at this time. By detaching and making the mirror one-way, no resync can occur, which could cause incorrect data to be written to the component that will be used following the unmirroring.

2. Run the metaroot(1M) command which edits the /etc/system and /etc/vfstab files to remove information specifying the mirroring root.

# /usr/opt/SUNWmd/sbin/metaroot /dev/dsk/c0t3d0s0

3. Edit the /etc/vfstab file to change the entry for the swap file system. The entry must be changed to remove the metadevice name and replace it with the component name. For example, change the following line:

/dev/md/dsk/d1 - - swap - no -

to read:

/dev/dsk/c0t3d0s1 - - swap - no -

4. Reboot the system using the reboot(1M) command.

# /usr/sbin/reboot

5. Use the metaclear command to clear the metadevices.

# /usr/opt/SUNWmd/sbin/metaclear -r /dev/md/dsk/d0 # /usr/opt/SUNWmd/sbin/metaclear -r /dev/md/dsk/d1 # /usr/opt/SUNWmd/sbin/metaclear /dev/md/dsk/d20 # /usr/opt/SUNWmd/sbin/metaclear /dev/md/dsk/d21

6. Remove all entries for root and swap from the /etc/opt/SUNWmd/md.tab file.

Reconfiguring Submirrors

Several DiskSuite commands are available that make the reconfiguration of submirrors possible with little or no disruption of service. The functionality includes utilities to attach or detachsubmirrors, or bring submirrors online and offline. The replacement of components within submirrors is also explained. The uses of these utilities are explained in the following sections. For a complete description of all the options associated with the commands, refer to Appendix E, "Using Solstice DiskSuite 4.0 with the SPARCstorage Array 100."

Attaching and Detaching Submirrors

Metadevices (concatenations or stripes) are attached to a metamirror as a submirror beneath the metamirror with the metattach(1M) command. The DiskSuite software supports up to three-way mirroring, thus a submirror can be attached only if fewer than three are already attached to the metamirror.

After a new metadevice is attached, metattach automatically starts a resync operation to the newly added submirror. metattach can also be used to add components to an existing concatenated metadevice without interrupting service.

Metadevices are separated (detached) from the metamirror with the metadetach(1M) command. Once detached, the metadevice is no longer a part of the metamirror. Reads from and writes to the metamirror no longer go to the detached metadevices. However, the metadevice can be used for other purposes. To help protect your data, DiskSuite does not allow the last remaining submirror to be detached.

An example of detaching a metadevice might occur when errors are being reported. You could run metadetach to detach that submirror component without disruption of service from the system. The downtime to replace the drive could be scheduled at a more convenient time.

Placing Submirrors Online and Offline

The DiskSuite commands, metaonline(1M) and metaoffline(1M) are used to place submirrors online and offline.

These commands are useful when, for instance, one component in a physical SCSI chain fails. In this case, all other components on the chain could be taken offline while the broken component is replaced. After replacing the component, the other components in the SCSI chain can be brought back online, using metaonline.

When metaoffline is used on a submirror, the metadisk is prevented from reading from and writing to the submirror. While the submirror is offline, DiskSuite keeps track of all writes to the metamirror and they are written to the submirror when it is brought back online.

The metaoffline command's functionality is similar to that offered by metadetach, however metaoffline does not sever the logical association between the submirror and the metamirror.

metaonline can be used only when a submirror was taken offline using the metaoffline command. When metaonline is run, reading from and writing to the submirror resumes. A resync is automatically performed to resync the regions of the metamirror that were written to while the submirror was offline. Writes are directed to the submirror during the resync. Reads, however, will come from a different submirror during the resync operation. Once the resync is complete, reads and writes are performed on the submirror previously taken offline.

Replacing and Enabling Submirror Components

Before you replace or enable a component, you should first check to be sure it is partitioned correctly. See the fmthard(1M) and prtvtoc(1M) man pages for details.

---

Note - The partitioning information for any disk used by DiskSuite should be saved in a safe place before any errors occur.

---

A component being used as a replacement in a submirror must be as large as the component it is replacing.

If a component is in the "Last Erred" state, you cannot replace it until you first replace all of the other mirrored components in the "Maintenance" state. Remember, however, that replacing or enabling a component in the "Last Erred" state usually means that some data has been lost. Be sure to validate the data on the mirror be reusing it (see fsck(1M)). If components are in the "Maintenance" state, no data has been lost and you can safely replace or enable components in any order.

Always check the metadevice state database replicas (using metadb -i) when repairing components. Any database replica shown to be in error should be deleted (using metadb -d) and added back (using metadb -a) to repair it.

You can replace components within a submirror with the metareplace(1M) command. metareplace automatically starts a resync to get the new component in sync with the rest of the metamirror.

Enabling components within a submirror is also performed using the metareplace command. metareplace -e changes the state of a failed component and automatically starts a resync to get the component in sync with the rest of the metamirror.

This command is useful when a component fails due to human error (for example, write-protecting an active disk), because a cable was loose and retightened, or because the component was physically replaced. When a component is replaced, the component used for replacement must have the same attributes as the component that was replaced. For example, if SCSI target 3 (/dev/dsk/c2t3d0s1) was physically replaced with a disk that was also SCSI target 3, then metareplace -e should be used to enable the component.

Changing Metamirror and Submirror Options

You can use the metaparam(1M) command to change most submirror options while DiskSuite is running. The options that can be changed include the read and write options, pass numbers, and hot spare pools.

metaparam allows you to change all metamirror options from the command line, with the exception of the interlace value. To change the interlace value, you must run the metainit command. On existing metadevices the metaclear command must be run prior to using metainit to change the interlace value.

The options are the same as those reported by either the metastat or the metaparam commands. For example:

# /usr/opt/SUNWmd/sbin/metaparam /dev/md/dsk/d25 d25: metamirror Pass = 1 Read option = round robin Write option = parallel

Entering the following command would change the read option to geometric, the write option to serial, and the pass number to five.

# /usr/opt/SUNWmd/sbin/metaparam -r geometric \ -w serial -p 5 /dev/md/dsk/d25

---

Note - The above command will not change any entry in the /etc/opt/SUNWmd/md.tab file. However the information is automatically modified in the state database and also in the /etc/opt/SUNWmd/md.cf file.

---

Using Mirrors for Online Backup

Mirroring enables you to perform online backups. Because each submirror is an exact copy of the file system, it can be taken offline and backed up to tape. This eliminates taking the system down to make a backup of the system. With the DiskSuite software package, file system locking functionality also eliminates the need to run fsck(1M) after taking the metadevice offline.

There are drawbacks, however, to using mirrors for backup purposes. For instance, if the backup is of a two-way mirror, all data redundancy is lost while one submirror is taken offline for backup. This problem can be overcome by adding hardware to create a mirror containing three submirrors. There is also the overhead of bringing the submirror back online after the backup is complete.

If your site uses procedures for online backup like the ones described in the following sections, you should combine the commands into a script.

The following sections provide instructions for performing online backups of both mirrored and non-mirrored metadevices.

Performing Online Backups -- for Mirrors

A mirrored metadevice can be backed up (archived) without unmounting it or taking the entire mirror offline. One of the submirrors must be taken offline temporarily, thus losing mirroring, but it can be placed online and resynced as soon as the backup is complete -- without halting the system or denying user access to the data.

There are five steps in the procedure for backing up a file system that is being mirrored. The steps listed here are described in detail in the example below.

1. Write locking the file system

2. Using the metaoffline command to take one metadevice offline from the metamirror

3. Unlocking the file system

4. Backing up the data on the offlined metadevice

5. Using the metaonline command to place the offlined metadevice back online

Using mirrors to perform online backups creates a backup that is a ''snapshot'' of an active file system. For example, a problem will occur if a user is editing a file with vi and uses a :w immediately before the lockfs command is run. In this case, since the vi file is being written from the top, it is possible that the file will appear completely empty on the backup. It is also possible that only the first 100 characters of a 10 Kbyte text file are written to the backup.

In the example procedure that follows, the metamirror (/dev/md/dsk/d1) consists of the three metadevices (/dev/md/dsk/d2, /dev/md/dsk/d3, and /dev/md/dsk/d4).

---

Note - Do not perform this procedure on the root file system.

---

To take one side of the mirror offline and perform a backup, you would follow these steps:

1. Use lockfs with the -w option to lock the file system from writes. You need to lock the file system only if a UFS file system resides on the metamirror. For example, if the metadevice is set up as a raw device for database management software or some other specific application, it would not be necessary to use lockfs. (You may, however, want to run the appropriate vender-dependent utility to flush any buffers and lock access.)

# /usr/sbin/lockfs -w mount_point

2. Take one submirror offline from the metamirror.

# /usr/opt/SUNWmd/sbin/metaoffline /dev/md/dsk/d1 /dev/md/dsk/d4

Reads will continue to be made from /dev/md/dsk/d2 and /dev/md/dsk/d3. However, /dev/md/dsk/d4 will be out of sync as soon as the first write is made to the metamirror. This inconsistency is corrected when /dev/md/dsk/d4 is onlined in Step 5.

You don't need to run fsck on the offlined file system. The only possible inconsistency would be that files that have been deleted but were open at the time lockfs -w was run would still occupy file space on the file system.

3. Use lockfs with the -u option to unlock the file systems and allow writes to continue.

   (You may need to perform necessary unlocking procedures based on vendor-dependent utilities used in Step 1 above.)

# /usr/sbin/lockfs -u mount_point

4. Perform a backup, using ufsdump or whatever other backup utility is normally used to copy the offlined metadevice to tape or another medium.

---

Note - To ensure a proper backup, make certain you use the raw device (in this case, /dev/md/rdsk/d4). Using "rdsk" allows greater than 2GB access.

---

5. Place the metadevice back online using the metaonline command.

# /usr/opt/SUNWmd/sbin/metaonline /dev/md/dsk/d1 /dev/md/dsk/d4

When /dev/md/dsk/d4 is placed online, it is automatically resynced with the metamirror.

Performing Online Backups -- for Nonmirrors

DiskSuite allows you to attach or detach submirror while the product is operating. This functionality can be used to temporarily attach another metadevice to the one-way mirror, take the mirror offline, and then perform the backup without interrupting service to users.

While this approach to online backup is not the usual use for mirroring (since it is not being used to provide replication of data), it does offer a method of performing online backups.

In the following example, a server has four disk drives attached. Three of the components are configured as one-way mirrors, while the fourth component is defined as an unused (spare) metadevice. The spare metadevice is attached to each of the mirrors in turn and a backup is performed.

---

Note - This is not a recommended configuration or use of DiskSuite. This example is included only to illustrate a method of performing online backups.

---

The steps to use the mirroring facility to back up the file system are:

1. Making sure all the metadevices and metamirrors are defined

2. Defining the spare metadevice

3. Attaching the spare metadevice to the metamirror and waiting for the resync to finish

4. Using lockfs -w to write-lock the file system.

5. Taking the spare metadevice offline

6. Using lockfs -u to unlock the file system

7. Performing the backup

8. Placing the spare metadevice back online

9. Clearing the spare metadevice

In the example procedure that follows, /dev/md/dsk/d11 is the spare metadevice, and /dev/md/dsk/d1 is the metamirror to be backed up.

Complete the following procedure to backup a file system using the mirroring facility:

1. Activate the spare metadevice.

   This is not necessary if the spare metadevice already active.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d11

2. Attach the spare metadevice to a metamirror.

   When you run the metattach command, a resync is automatically started. (This may take some time to complete.)

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d1 /dev/md/dsk/d11

3. Wait for the device to synchronize.

   Using the metastat command periodically as follows, you'll be able to tell when the synchronization is complete.

# metastat d1

4. Use the lockfs command with the -w option to lock the file system from writes.

# /usr/sbin/lockfs -w mount_point

You need to lock the file system only if a UFS file system resides on the metamirror. For example, if the metadevice is set up as a raw device for database management software or some other specific application, it would not be necessary to use lockfs (though you may want to synchronize data in some other vender-dependent way). In this case, however, it may be desirable to take the database offline temporarily to synchronize the data.

5. Take the spare metadevice offline from the metamirror using the

   metaoffline command.

# /usr/opt/SUNWmd/sbin/metaoffline /dev/md/dsk/d1 /dev/md/dsk/d11

6. Use lockfs with the -u option to unlock the file systems and allow writes to continue.

# /usr/sbin/lockfs -u mount_point

7. Perform the backup, using ufsdump or whatever other backup utility is normally used to copy the detached metadevice to tape or another medium.

---

Note - To ensure a proper backup, make certain you use the raw device (in this case, /dev/md/rdsk/d11). Using "rdsk" allows greater than 2GB access.

---

8. Place the spare metadevice back online.

# /usr/opt/SUNWmd/sbin/metaonline /dev/md/dsk/d1 /dev/md/dsk/d11

9. Detach the spare metadevice.

# /usr/opt/SUNWmd/sbin/metadetach /dev/md/dsk/d1 /dev/md/dsk/d11

10. Clear the spare metadevice.

# /usr/opt/SUNWmd/sbin/metaclear /dev/md/dsk/d11

Examples

Several examples are offered in this section that show, in a step-by-step fashion, how to set up mirrors in various configurations. These examples include:

• Mirroring an existing file system
• Adding submirrors
• Watching the progress of a resync using metastat

Mirroring an Existing File System

This example shows how to set up a mirror of the file system located on /dev/dsk/c1t0d0s0. This example is typical for any existing file systems, except /usr, root, and swap. The steps to follow are:

1. Create two metadevices for the existing file system by making the following entries in the /etc/opt/SUNWmd/md.tab file. The first two entries create the metadevices, named /dev/md/dsk/d1 and /dev/md/dsk/d2, that will be used as submirrors. The third line creates a one-way metamirror, using only the first metadevice. The first metadevice is the existing component which contains the /master file system.

/dev/md/dsk/d1 1 1 /dev/dsk/c1t0d0s0 /dev/md/dsk/d2 1 1 /dev/dsk/c2t0d0s0 /dev/md/dsk/d0 -m /dev/md/dsk/d1

2. Unmount the file system.

# /sbin/umount /master

If the file system is busy, an error message is displayed.

3. Initialize the metadevices and metamirror.

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d1 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d2 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d0

4. Edit the /etc/vfstab file to change the entry for /master to be /dev/md/dsk/d0.

   For example, if the entry was:

/dev/dsk/c1t0d0s0 /dev/rdsk/c1t0d0s0 /master ufs 5 yes -

change the entry to read:

/dev/md/dsk/d0 /dev/md/rdsk/d0 /master ufs 5 yes -

5. Mount the /master file system.

   When it is mounted, it is a one-way mirror.

# /sbin/mount /master

6. Now attach the second metadevice, /dev/md/dsk/d2, to the mirror /dev/md/dsk/d0, using the metattach command.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d0 /dev/md/dsk/d2

When you run the metattach command, a resync of the mirror is started. Once the resync completes, /master is mirrored.

Adding Submirrors

In the following example, two submirrors are being added to the metamirror, /dev/md/dsk/d30. In this example, the metamirror already exists.

The metamirror, /dev/md/dsk/d30, appears as follows when you run metastat:

# /usr/etc/metastat /dev/md/dsk/d30 d30: metamirror Submirror 0: d15 State: Okay Regions which are dirty: 0% Pass = 1 Read option = geometric (-g) Write option = parallel (default) Size: 183750 blocks . . .

Note the size in the metastat output is 183750 blocks, thus each of the two submirrors being added must be 183750 blocks or larger to be added as submirrors. If the submirrors are larger, the extra space will be unused and unavailable.

Follow these steps to add the two submirrors from the command line:

1. Use metainit to create the two new submirrors. For example:

# /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d70 1 1 \ /dev/dsk/c0t3d0s0 # /usr/opt/SUNWmd/sbin/metainit /dev/md/dsk/d80 1 1 \ /dev/dsk/c1t2d0s0

2. Use the metattach command to attach each of the new submirrors to the metamirror.

   When metattach is run, the new submirrors are synced with the existing metamirror.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d30 /dev/md/dsk/d70 # /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d30 /dev/md/dsk/d80

If you wish to view the metamirror after adding the two submirrors, you can run the metastat command again. The output in this example would appear as follows:

# /usr/etc/metastat /dev/md/dsk/d30 d30: metamirror Submirror 0: d15 State: Okay Submirror 1: d70 State: Okay Submirror 2: d80 State: Okay Regions which are dirty: 0% Pass = 1 Read option = geometric (-g) Write option = parallel (default) Size: 183750 blocks . . .

Watching the Progress of a Resync Using metastat

In this example, the metadevice /dev/md/dsk/d22 is being attached to the metamirror /dev/md/dsk/d21.

Follow these steps to attach the metadevice:

1. Define the metadevice either in the /etc/opt/SUNWmd/md.tab file or on the command line.

2. Run metainit on the metadevices.

3. Use metattach to attach the new metadevices to the metamirror.

# /usr/opt/SUNWmd/sbin/metattach /dev/md/dsk/d21 /dev/md/dsk/d22

4. Use the metastat command with the metamirror name as an argument to view the status of the new metadevice.

# /usr/etc/metastat /dev/md/dsk/d21 d21: metamirror Submirror 0: d30 State: Okay Submirror 1: d22 State: Resyncing Regions which are dirty: 3% Resync in progress: 30% done Pass = 1 Read option = geometric (-g) Write option = parallel (default) Size: 183750 blocks

To view the progress, you can run the metastat command again.

# /usr/etc/metastat /dev/md/dsk/d21 d21: metamirror Submirror 0: d30 State: Okay Submirror 1: d22 State: Resyncing Regions which are dirty: 6% Resync in progress: 50% done . . .