4.0MP1RP2 (Rollingpatch2 for 4.0MP1)
===================================

This rollingpatch (RP) is applicable for the following products

1. Linux SF 4.0MP1
2. Linux SFCFS 4.0MP1
3. Linux SFRAC 4.0MP1

The patch fixes the following components

1. VRTSvxfs
2. VRTSglm

The following rpms form this rolling patch

1. VRTSvxfs-4.0.10.2-MP1RP2_RHEL3.i686.rpm
2. VRTSglm-4.0.10.1-MP1RP1_RHEL3.i686.rpm

Only VRTSvxfs-4.0.10.2-MP1RP2_RHEL3.i686.rpm is needed for Linux SF 4.0MP1
product.  For Linux SFCFS 4.0MP1, and Linux SFRAC 4.0MP1 products both of
the above rpms are needed.


Installation instructions
-------------------------

This RP can only be installed on Linux 4.0MP1 products or products at
Linux 4.0MP1RP1 level. If your products are at a 4.0GA level,
please apply 4.0MP1 before installing this RP.

To install this patch on SF 4.0MP1
----------------------------------

a. Make sure all VxFS filesystems are unmounted
b. #> rmmod fdd vxportal vxfs
c. #> rpm -Uhv VRTSvxfs-4.0.10.2-MP1RP2_RHEL3.i686.rpm
d. Reboot the system

For SF/HA the above steps are the same, except that these have to be done
one node at a time.


To install this patch on SFCFS 4.0MP1
-------------------------------------

a. Make sure all VxFS filesystems are unmounted on all cluster nodes
b. Stop HA from one of the nodes in the cluster,
   #> /opt/VRTS/bin/hastop -all

c. #> gabconfig -a
   Verify that only ports 'a', 'b' and 'f' are open, like shown below
        Port a gen   344a02 membership 01
        Port b gen   344a01 membership 01
        Port f gen   344a1d membership 01

d. On each node of the cluster
   #> rmmod fdd vxportal vxfs vxglm

e. On each node of the cluster
   #> rpm -Uhv VRTSvxfs-4.0.10.2-MP1RP2_RHEL3.i686.rpm

f. On each node of the cluster
   #>rpm -Uhv VRTSglm-4.0.10.1-MP1RP1_RHEL3.i686.rpm

g. Reboot all nodes of the cluster


To install this patch on SFRAC 4.0MP1
-------------------------------------

a. make sure that no vxfs filesystem is mounted in any of the cluster nodes

b. do #> /opt/VRTS/bin/hastop -all
   from one of the nodes in the cluster

c. verify through #> gabconfig -a
   that only ports 'a', 'b' 'd' and 'f' are open, like shown below
        Port a gen   344a02 membership 01
        Port b gen   344a01 membership 01
        Port d gen   344a12 membership 01
        Port f gen   344a1d membership 01
d. On each node of the cluster
   #>/etc/init.d/vxodm stop

e. On each node of the cluster
   #>umount /dev/odm

f. On each node of the cluster
   #> rmmod vxodm fdd vxportal vxfs vxglm

g. On each node of the cluster
   #>rpm -Uhv VRTSvxfs-4.0.10.2-MP1RP2_RHEL3.i686.rpm

h. On each node of the cluster
   #>rpm -Uhv VRTSglm-4.0.10.1-MP1RP1_RHEL3.i686.rpm

i. reboot the nodes of the cluster

Uninstall instructions
----------------------

RPs dont have to be uninstalled, the subsequent VRTSvxfs, VRTSglm versions will
have the fixes this RPs have and the systems can directly be upgraded to them
without removing the RPs. If there is a need to uninstall these RPs, the same
exact steps followed for the install needs to be followed, except for the

#> rpm -Uhv <VRTSvxfs [VRTSglm]> steps have to be

#> rpm -e --nodeps <VRTSvxfs [VRTSglm]> step

and then the 4.0 MP1 VRTSvxfs [VRTSglm] have to be installed in place by doing

#> rpm -ihv <VRTSvxfs [VRTSglm]>

Issues fixed through this RP
----------------------------

Veritas incident 152379:

        In a cluster filesystem environment (SFCFS and SFRAC) intermittently,
        file permissions were seen with all zeroes from a Secondary node.

Veritas incident 152715:

        In a SFRAC environment, Oracle I/O to files that have been recently
        copied/moved, takes a long time to complete.

Veritas incident 152047:

        F_GETLCK fcntl does not work correctly on linux VxFS. The problem
        manifests itself in the failure of an fcntl F_GETLCK cmd to return
        the correct information. It will return that the file is locked
        when it isnt.

Veritas incident 152242:

        In a cluster filesystem environment (SFCFS and SFRAC) on nodes that
        have a lot of physical memory, the GLM component loops forever trying
        to allocate memory beyond linux's max possible allocation size. This
        would appear as vxfsckd process spinning on CPU.

VERITAS Incident 152189:

        Due to a race condition in VxFS, processing of extent maps of the file
        system could get impacted and messages warning about bad maps could
        get logged on the console.