Removing Disksuite

Introduction

There are many circumstances in which it may be necessary to remove the operating system from Disksuite control. For example, the process of upgrading the operating system from one release to another requires that the Solaris filesystem be simple slices, not metadevices. Prior to upgrading the operating system, the administrator must first remove Disksuite from the system, while preserving the data in the underlying slices.

Typically, the administrator is often under pressure while performing these types of maintenance. Because simple mistakes at this stage can render the system unusable, it is important that the process be well documented and tested prior to using it in production. Fortunately, this process is simpler than that for Veritas volume manager because there are no "de-encapsulation" issues to address.

Removing Disksuite step-by-step

In the example below, the server pegasus has two internal disks (c0t0d0 and c0t1d0) under Disksuite control. The operating system is mirrored between the two devices, with slices five and six on each disk employed for state database replicas:

# metadb
        flags           first blk       block count
     a m  p  luo        16              1034            /dev/dsk/c0t0d0s5
     a    p  luo        16              1034            /dev/dsk/c0t0d0s6
     a    p  luo        16              1034            /dev/dsk/c0t1d0s5
     a    p  luo        16              1034            /dev/dsk/c0t1d0s6

# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d0       6607349  845208 5696068    13%    /
/proc                      0       0       0     0%    /proc
fd                         0       0       0     0%    /dev/fd
mnttab                     0       0       0     0%    /etc/mnttab
/dev/md/dsk/d4       1016863    8414  947438     1%    /var
swap                 1443840       8 1443832     1%    /var/run
swap                 1443848      16 1443832     1%    /tmp

1. Using the Disksuite metaroot command, change the root device to a simple slice. This will update the /etc/system and /etc/vfstab files:

   # metaroot /dev/dsk/c0t0d0s0

2. Detach the metadevices from c0t1d0:

   # metadetach d0 d20
# metadetach d1 d21
# metadetach d4 d24
   
3. Edit the /etc/vfstab to reference the physical disk slices (eg. /dev/dsk/c0t0d0s4) rather than the Disksuite metadevices (eg. /dev/md/dsk/d4).

4. If the system is using a DiskSuite metadevice for crash dumps, use the dumpadm command to send crash dumps to a simple disk slice (eg. swap):

   # dumpadm -d /dev/dsk/c0t0d0s1

5. Reboot the system, hopefully mounting the simple slices from c0t0d0 for /, /var, and swap:

   # reboot

   The server should come back up mounting the physical disk slices. Verify this with df -ak

6. Remove the now unused Disksuite metadevices:

   # metaclear d20 d21 d24
# metaclear -r d0 d1 d4

7. Delete the state database replicas. You can determine their location with the command "metadb -i":

   # metadb -d -f c0t0d0s5 c0t0d0s6 c0t1d0s5 c0t1d0s6

8. Confirm that there are no remaining metadevices or state database replicas present. The commands "metadb -i" and "metastat" shouldn't return anything.

At this point, the operating system is no longer under Disksuite control. The disk c0t1d0 is unused, and the system would not survive the failure of c0t0d0 if it were to die now. However, the system is now ready to be upgraded. Because operating system upgrades are not completely reliable, it is recommended that the administrator duplicate the disk c0t0d0 to c0t1d0 prior to starting the upgrade. This ensures an easy recovery if there are problems during the upgrade.

To ensure high availability, the administrator must remember to mirror the operating system again once the upgrade is completed.