Volume Manager (VxVM)

The following notes and recommendations apply to the Volume Manager.

• Disks with insufficient space (less than 1024 disk blocks) for the allocation of an on-disk database copy cannot be encapsulated. The database requires at least the same space as is allocated for other disks in the same disk group. This size defaults to 1024 blocks. A way to work around this is to relocate the data on the last partition of the disk to a volume on a different disk, and free the space by reducing the partition size to 0. The space for this database must be allocated from the beginning or the end of the disk, with the exception of the root disk. The root disk can be encapsulated by carving out space from the swap slice if there is no space at the beginning or at the end of the disk. This is done by creating a subdisk for the private partition in the space obtained from the swap slice. There is no workaround to the problem of not having space on a disk to store private VxVM information. VxVM requires at least a small region of private storage (1024 blocks) for proper disk identification.

• The Volume Manager tracks disks using long unique identifiers that VxVM stores on each disk. VxVM expects each disk to have a different unique identifier, and does not effectively guard against the situation where two disks have the same unique identifier. Duplicate identifiers should only occur as the result of the administrator using dd or some other utility to perform physical copies of the contents of an entire disk. The only effective workaround is that the administrator should not do exact physical disk copying.

• It should be possible to prevent any access of a disk by VxVM. For example, startup of VxVM could be severely impacted by a disk with errors that result in I/Os that take a long time to fail. However, when VxVM starts up, it accesses every disk on the system, by reading its VTOC and possibly a few blocks from one partition. There is currently no mechanism to prevent this. A disk can be off-lined persistently, but the offline state is only recognized after the probe of all disks.

• RAID-5 cannot currently be mirrored or backed up online using any mechanisms provided in VxVM.

• The disk hot-sparing mechanism currently used in VxVM does not work well for partial disk failures. The model was written using the presumption that disks fail totally, rather than partially, and that partial errors can usually be fixed by writing back a failing sector (which is done automatically when using mirroring or RAID-5). Usually this is a good assumption, but some users have encountered situations where only a few sectors failed and hot sparing did not occur.

• On machines with low memory (32 megabytes or less), under heavy I/O stress conditions against high memory usage volumes (that is, RAID-5 volumes), a situation occurred in which the system could not allocate physical memory pages any more. For example, such a situation may result when exercising heavy I/O stress against RAID-5 volumes for 24 hours on a 32-megabyte machine.

• UnixWare does not support raw interfaces for devices greater than 2 gigabytes.

• VxVM assumes there are not more than 16 partitions defined on any disk VTOC. It is assumed that the slices are s0 through s15.

• Note that there is no protection built into vxassist to prevent the user from shrinking the swap volume without first shrinking what the system sees as available swap space. If it is necessary to shrink the swap volume, this operation should be done in single-user mode and the system should be rebooted immediately. Failing to take these precautions could result in unknown system behavior or lock-up.

• Using vxdg free with a non-existent disk-media-name does not print an appropriate error message. It simply prints a header.

• If you are mirroring your swap device, we recommend that you set aside a dedicated dump slice to store possible system dumps. Otherwise, the system may not detect the presence of a system dump on the swap slice.

Upgrading SCO UnixWare 2.1 VxVM to UnixWare 7

You can preserve a UnixWare 2.1 VxVM filesystem if it is not your root or /usr filesystem. To preserve a filesystem:

1. Ensure that the VxVM ODM packages are installed and the filesystem is configured as you require it on the SCO UnixWare 2.1 system.

2. Mount the filesystem.

3. Create an s5 filesystem on a diskette as follows:
   
   # format /dev/rdsk/f03ht
   # mkfs -F s5 /dev/dsk/f03ht 2880

4. Mount the diskette and copy the necessary files and directories:
   
   # mount -Fs5 /dev/dsk/f0t /mnt
   # find /etc/vx/reconfig.d \
   /etc/vx/tempdb \
   /etc/vx/volboot \
   /etc/vfstab | cpio -pd /mnt

5. Unmount the diskette and install UnixWare 7:
   
   # umount /mnt

   ---

   CAUTION: After the installation of UnixWare 7 do not perform a vxinstall.

   ---

6. Copy the files from the diskette back to the UnixWare 7 system:
   
   # mount -Fs5 /dev/dsk/f0t /mnt
   # cd /mnt
   # find etc/vx/reconfig.d \
   etc/vx/tempdb \
   etc/vx/volboot | cpio -pd /

   Merge /mnt/vfstab and /etc/vfstab manually.

7. If the mountpoint used in SCO UnixWare 2.1 (in step 2) does not exist, create it:
   
   # mkdir mount_point

8. Remove the file /etc/vx/reconfig.d/state.d/install-db:
   
   # rm /etc/vx/reconfig.d/state.d/install-db

9. Reboot the system.

10. Mount the VxVM filesystem or volume:
    
    # mount /mount-point