* * * READ ME * * *
                 * * * Veritas File System 8.0.2 * * *
                        * * * Hot Fix 2701 * * *
                         Patch Date: 2025-07-29


This document provides the following information:

   * PATCH NAME
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * SUMMARY OF INCIDENTS FIXED BY THE PATCH
   * DETAILS OF INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH


PATCH NAME
----------
Veritas File System 8.0.2 Hot Fix 2701


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
RHEL9 x86-64


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxfs


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * InfoScale Enterprise 8.0.2
   * InfoScale Foundation 8.0.2
   * InfoScale Storage 8.0.2


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: 8.0.2.2701
* 4190079 (4190078) System panicked due to VxFS LRU list inconsistency.
* 4190857 (4175191) File system corruption was seen after upgrading from VxFS 742 to 802.


DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following incidents:

Patch ID: 8.0.2.2701

* 4190079 (Tracking ID: 4190078)

SYMPTOM:
System panicked due to VxFS LRU list inconsistency.

DESCRIPTION:
Multiple LRU lists changes were introduced to avoid single LRU lock contention seen during parallel lookups. With the multiple LRU lists changes, d_name.hash is used to pick which LRU list the dentry should be put on, and the same LRU list lock is taken when taking the same dentry is taken off the LRU list based its d_name.hash. However, a dentrys d_name could be changed in between adding/removing it to/from the LRU list just which was picked based on its initial d_name.hash, as a result because of which the wrong LRU list lock is taken unexpectedly based on its current (already changed) d_name.hash. This can cause a panic due to the lists being inconsistent because the wrong lock is taken. One of the scenarios that where d_name.hash can be changed is file system rename operation. This is a filesystem metadata only inconsistency and has no effect on the data.

RESOLUTION:
Once a dentry LRU list is picked based on its initial d_name.hash, make sure the dentry sit on the same LRU list until it gets deleted.

* 4190857 (Tracking ID: 4175191)

SYMPTOM:
After upgrading from VxFS 742 to 802, VxFS file system failed to mount, fsck is required and reports the following error:

UX:vxfs fsck: ERROR: V-3-20448: No valid fset headers found
UX:vxfs fsck: ERROR: V-3-20694: cannot initialize aggregate

DESCRIPTION:
vxFS introduced new fset header filed (fsh_rtime) in DLV 17 after VxFS 8.0, after upgrading from 742 to 802, if file system isn't unmounted cleanly, log replay is required to replay those transactions haven't been flushed to disk. During log replay, when calculating the size of file system log entries, the new file set header is used unexpectedly when replaying an fset header transaction, since the size of new fset headers increased due to the addition of fsh_time filed, replay of such fset header transaction could overwrite the adjacent transactions, hence the corruption.

RESOLUTION:
Calculate the actual size of FS log entries based on the DLV layout versions.



INSTALLING THE PATCH
--------------------
Run the Installer script to automatically install the patch:
-----------------------------------------------------------
Please be noted that the installation of this P-Patch will cause downtime.

To install the patch perform the following steps on at least one node in the cluster:
1. Copy the patch fs-rhel9_x86_64-HotFix-8.0.2.2701.tar.gz to /tmp
2. Untar fs-rhel9_x86_64-HotFix-8.0.2.2701.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/fs-rhel9_x86_64-HotFix-8.0.2.2701.tar.gz
    # tar xf /tmp/fs-rhel9_x86_64-HotFix-8.0.2.2701.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
    # pwd /tmp/hf
    # ./installVRTSvxfs802P2701 [<host1> <host2>...]

You can also install this patch together with 8.0.2 base release using Install Bundles
1. Download this patch and extract it to a directory
2. Change to the Veritas InfoScale 8.0.2 directory and invoke the installer script
   with -patch_path option where -patch_path should point to the patch directory
    # ./installer -patch_path [<path to this patch>] [<host1> <host2>...]

Install the patch manually:
--------------------------
1) This patch requires outage for the environment.
2) We need to unmount all the file systems.
3) In case SFCFSHA/SFHA is there then follow this step, otherwise skip this 3rd step.
        a) /opt/VRTS/bin/hastop -all
        b) unmount any local file systems.
        c) Check gabconfig showing only ports a b
        d) in case ODM is loaded and showing port "d", unload the ODM.
                systemctl stop vxodm
4)Stop vxfs.service
    systemctl stop vxfs
5) Update the vxfs patch on all the cluster nodes.
        rpm -Uvh <rpm_name>
6) Load the odm once again.
        systemctl start vxodm
7) start the cluster with /opt/VRTS/bin/hastart.


REMOVING THE PATCH
------------------
# rpm  -e <rpm name>


SPECIAL INSTRUCTIONS
--------------------
If ODM is running, please stop using below command
systemctl stop vxodm


OTHERS
------
NONE