Removing Disksuite

diandianrong

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

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

Detach the metadevices from c0t1d0:
# metadetach d0 d20
# metadetach d1 d21
# metadetach d4 d24

Edit the /etc/vfstab to reference the physical disk slices (eg. /dev/dsk/c0t0d0s4) rather than the Disksuite metadevices (eg. /dev/md/dsk/d4).

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  (Note:这个我不是很明白，bash-3.00# dumpadm -d /dev/dsk/c0d0s1
      转储内容：内核 页
       转储设备：/dev/dsk/c0d0s1 (swap)
Savecore 目录：/var/crash/kale
  已启用 Savecore：是
去网上找了些资料：从Solaris 7开始，缺省情况下crashdump写到交换区上,这也是为什么交换区为什么和内存一样大的原因之一。下次启动的时候，从交换区中读取这个文件，压缩之后写到var/crash/里面，用于以后的分析。因此/var（如果没有单独分出/var或者是/区）不能太小。 如果一个系统用了几个G的空间作为dump设备，启动时会由于上面提到的拷贝操作，花上很长时间。这时候，最好利用dumpadm定义一个dump分区，从这个指定分区拷贝的操作会在后台运行。注意经常检查和清除/var/crash/，保证有足够的空间用于其他的crashdumps。

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

Remove the now unused Disksuite metadevices:
# metaclear d20 d21 d24
# metaclear -r d0 d1 d4

Delete the state database replicas. You can determine their location with the command "metadb -i":
# metadb -d -f c0t0d0s5 c0t0d0s6 c0t1d0s5 c0t1d0s6

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.
Reference:http://blog.chinaunix.net/u/524/showart_87412.html


本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u/26090/showart_321360.html