* * * READ ME * * *
            * * * Symantec Storage Foundation HA 6.2.1 * * *
                         * * * Patch 200 * * *
                         Patch Date: 2015-08-11

Note:
----
The Installer of this patch was updated on Jan. 24, 2017 to fixed the following issue.
Incident: 3905495

SYMPTOM:
The installer fails to install the patch on Oracle Linux.

DESCRIPTION:
The installer aborts the installation of the patch on Oracle Linux with the error message 'No pkg object defined for pkg <pkg_name> and padv OL7x8664'.

RESOLUTION:
The code of the Installer is modified to support the installation of the patch on Oracle Linux.


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
----------
Symantec Storage Foundation HA 6.2.1 Patch 200


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


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTScavf
VRTSdbac
VRTSgab
VRTSglm
VRTSllt
VRTSvcs
VRTSvcsea
VRTSvxfs


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Symantec Application HA 6.2
   * Symantec Cluster Server 6.2
   * Symantec File System 6.2
   * Symantec Storage Foundation 6.2
   * Symantec Storage Foundation Cluster File System HA 6.2
   * Symantec Storage Foundation for Oracle RAC 6.2
   * Symantec Storage Foundation HA 6.2


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: VRTSvcsea-6.2.1.200
* 3879170 (3879366) Extended support for all shells in oracle systemd startup 
script.
Patch ID: VRTSvcs-6.2.1.100
* 3871617 (3871614) With HAD in user.slice, Oracle (or applications) are not shut down gracefully during system reboot.
Patch ID: VRTSvxfs-6.2.1.100
* 3752475 (3758102) In Cluster File System(CFS) on Linux, stack overflow while
creating ODM file.
* 3821699 (3821698) GLM module failed to load on SLES11 SP4.
* 3737333 (3737329) Added support for RHEL7.1
* 3759910 (3765928) "cfsshare config -p all" doesn't populating smb.conf(samba
configuration file) properly for some global variables.
* 3760226 (3765921) On RHEL7 onwards, pluggable Authentication Modules(PAM)
related error messages for Samba daemon may be observed in system logs after
adding CIFS(common internet file system) share
Patch ID: VRTSvxvm-6.2.1.000
* 3661856 (3656155) Import of VxVM diskgroup triggered from CVMVolDg agent fails.
* 3717930 (3757778) After executing the hastop -local command, the vxconfigd(1M) daemon is not accessible.
* 3745321 (3760033) cfsshare command may report VCS error messages.
* 3746594 (3767771) CVMVOLDG agent does not deport shared disk groups when these
disks go into the disable state.
* 3762371 (3737329) Added support for RHEL7.1
* 3762380 (3697141) Added support for Sles12
* 3753724 (3731844) umount -r option fails for vxfs 6.2.
* 3754492 (3761603) Internal assert failure because of invalid extop processing 
at the mount time.
* 3756002 (3764824) Internal cluster file system(CFS) testing hit debug assert
* 3765324 (3736398) NULL pointer dereference panic in lazy unmount.
* 3765998 (3759886) In case of nested mount, force umount of parent leaves 
stale child entry in /etc/mtab even after subsequent umount of child.
* 3769992 (3729158) Deadlock due to incorrect locking order between write advise
and dalloc flusher thread.
* 3793241 (3793240) Vxrestore command dumps core file because of invalid 
japanese strings.
* 3798437 (3812914) On RHEL 6.5 and RHEL 6.4 latest kernel patch, umount(8) system call hangs if an
application watches for inode events using inotify(7) APIs.
* 3808285 (3808284) fsdedupadm status Japanese text includes strange character.
* 3817120 (3804400) VRTS/bin/cp does not return any error when quota hard 
limit is reached and partial write is encountered.
* 3821688 (3821686) VxFS module failed to load on SLES11 SP4.
Patch ID: VRTSvxfs-6.2.1.000
* 3093833 (3093821) The system panics due to referring freed super block after the vx_unmount() function errors.
* 3657150 (3604071) High CPU usage consumed by the vxfs thread process.
* 3657151 (3513507) Filesystem umount() may hang due to deadlock in kernel
* 3657152 (3602322) System panics while flushing the dirty pages of the inode.
* 3657153 (3622323) Cluster Filesystem mounted as read-only panics when it gets sharing and/or compression statistics with the fsadm_vxfs(1M) command.
* 3657156 (3604750) The kernel loops during the extent re-org.
* 3657157 (3617191) Checkpoint creation takes a lot of time.
* 3657158 (3601943) Truncating corrupted block map of a file may lead to an infinite loop.
* 3657159 (3633067) While converting from ext3 file system to VxFS using vxfsconvert, it is observed that many inodes are missing..
* 3665980 (2059611) The system panics due to a NULL pointer dereference while
flushing bitmaps to the disk.
* 3665984 (2439261) When the vx_fiostats_tunable value is changed from zero to
non-zero, the system panics.
* 3665990 (3567027) During the File System resize operation, the "fullfsck flag is set.
* 3666007 (3594386) On RHEL6u5, stack overflows lead to system panic.
* 3666008 (3616907) System is unresponsive causing the NMI watchdog service to 
stall.
* 3666010 (3233276) With a large file system, primary to secondary migration takes longer duration.
* 3683470 (3682138) The VxVM symbols are released before the VxFS modules unload time.
* 3687679 (3685391) Execute permissions for a file not honored correctly.
* 3697142 (3697141) Added support for Sles12
* 3697966 (3697964) The vxupgrade(1M) command fails to retain the fs_flags after upgrading a file system.
* 3698165 (3690078) The system panics at vx_dev_strategy() routine due to stack overflow.
* 3706864 (3709947) The SSD cache fails to go offline due to additional slashes "//" in the dev path of the cache device.
* 3710794 (3710792) Unmount fails when the mount point contains a special character(colon).
* 3715567 (3715566) VxFS fails to report an error when the maxlink and nomaxlink options are set on file systems having disk layout version (DLV) lower than 10.
* 3716627 (3622326) During a checkpoint promote, a file system is marked with a fullfsck flag because the corresponding inode is marked as bad.
* 3717895 (2919310) During stress testing on cluster file system, an assertion failure was hit because of a missing linkage between the directory and the associated attribute inode.
* 3718542 (3269553) VxFS returns inappropriate message for read of hole via Oracle Disk Manager (ODM).
* 3721458 (3721466) After a file system is upgraded from version 6 to 7, the vxupgrade(1M) command fails to set the VX_SINGLEDEV flag on a superblock.
* 3726403 (3739618) sfcache command with "-i" option maynot show filesystem cache statistic periodically.
* 3727166 (3727165) Enhance RHEV support for SF devices for identification in Guest
* 3729704 (3719523) 'vxupgrade' retains the superblock replica of old layout versions.
* 3733811 (3729030) The fsdedupschd daemon failed to start on RHEL7.
* 3733812 (3729030) The fsdedupschd daemon failed to start on RHEL7.
* 3737330 (3737329) Added support for RHEL7.1
* 3743913 (3743912) Users could create sub-directories more than 64K for disk layouts having versions lower than 10.
* 3744425 (3744424) Rebundled the fix "Openssl: Common Vulnerability and Exposure (CVE) CVE-
2014-3566 (POODLE)" as 6.2.1
* 3745651 (3642314) Umount operation reports error code 255 in case of write-back cache.
* 3749727 (3750187) Internal noise testing hits debug assert.
* 3749776 (3637636) Cluster File System (CFS) node initialization and protocol upgrade may hang during the rolling upgrade.
* 3755796 (3756750) VxFS may leak memory when File Design Driver (FDD) module is unloaded before the cache file system is taken offline.
Patch ID: 6.2.0.100
* 3703631 (3615043) Data loss when writing to a file while dalloc is on.
Patch ID: VRTSdbac-6.2.0.100-RHEL7
* 3861194 (3861191) 6.2.0 vcsmm module does not load with RHEL7.2 (3.10.0-319.el7.x86_64)
Patch ID: VRTSllt-6.2.1.200-RHEL7
* 3861312 (3861308) Veritas Cluster Server (VCS) does not support Red Hat Enterprise Linux 7 Update
2 (RHEL7.2).
Patch ID: VRTSvcs-6.2.1.100-RHEL7
* 3869873 (3869872) HAD (High Availability Daemon) starts in 'user.slice' after the 'hastart' operation.
Patch ID: VRTSvcsea-6.2.1.100-RHEL7
* 3871617 (3871614) With HAD in user.slice, Oracle (or applications) are not shut down gracefully during system reboot.
Patch ID: VRTSgab-6.2.1.300
* 3875807 (3875805) In some rare cases, if a few unicast messages are stuck in 
the Group Membership Atomic Broadcast (GAB) receive queue of a port, the port 
might receive a GAB I/O fence message.


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

Patch ID: VRTSvcsea-6.2.1.200

* 3879170 (Tracking ID: 3879366)

SYMPTOM:
Systemd service for oracle resource fails to start when user shell 
is csh

DESCRIPTION:
Oracle resource fails to online when the owner has csh set as 
default shell. The systemd service which is started during online E.P. fails 
to start if owner has csh set as default login shell. After a few attempts, 
clean is called which causes the Oracle resource to fault.

RESOLUTION:
Support for all types of shell used by the oracle user in 
systemd startup script.

Patch ID: VRTSvcs-6.2.1.100

* 3871617 (Tracking ID: 3871614)

SYMPTOM:
If HAD is running in the user.slice then during system reboot, Oracle (or its applications) running as a non-root user do not shut down gracefully.

DESCRIPTION:
On RHEL7 and SLES12, systemd is enabled. Therefore, all the processes running under user.slice are killed on system reboot. Since Oracle (or its applications) run under user.slice by default, a system reboot may cause Oracle to crash or udergo an abrupt shut down.

RESOLUTION:
Move the Oracle processes to system.slice to prevent them from an abrupt shut down during a system reboot.

Patch ID: VRTSvxfs-6.2.1.100

* 3752475 (Tracking ID: 3758102)

SYMPTOM:
In Cluster File System(CFS) on Linux, stack overflow while creating
ODM file.

DESCRIPTION:
In case of CFS, while creating a ODM file, cluster inode needs
initialization, which takes GLM(Group Lock Manager) lock.  While taking GLM
lock, processing within GLM module may lead to the system panic due to stack
overflow in Linux while doing memory allocation.

RESOLUTION:
Modified handoff values.

* 3821699 (Tracking ID: 3821698)

SYMPTOM:
GLM module will not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore GLM module failed to load
on it.

RESOLUTION:
Added GLM support for SLES11 SP4.

* 3737333 (Tracking ID: 3737329)

SYMPTOM:
Added support for RHEL7.1

DESCRIPTION:
Added support for RHEL7.1

RESOLUTION:
Added support for RHEL7.1

* 3759910 (Tracking ID: 3765928)

SYMPTOM:
"cfsshare config -p all" doesn't populating smb.conf(samba configuration
file) properly for some global variables.

DESCRIPTION:
"cfsshare config -p all" doesn't populating smb.conf properly for
some global variables. Attributes "encryptpasswords" and "smbpasswd file" should
have space in the name.

RESOLUTION:
Code is modified so that correct attribute names are present in samba
configuration file.

* 3760226 (Tracking ID: 3765921)

SYMPTOM:
On RHEL7 onwards, pluggable Authentication Modules(PAM) related error
messages for Samba daemon may be observed in system logs after adding CIFS share
and the CIFS share is may not be accessible from windows client.

DESCRIPTION:
There is a file /etc/pam.d/samba which is not available by default
on RHEL 7 onwards and also "obey pam restrictions" attribute from Samba
configuration file (smb.conf) is set to "yes", where default is "no". This
parameter will control whether or not Samba should obey PAM's account and
session management directives. The default behavior is to use PAM for clear 
text authentication only and to ignore any account or session management. Samba
always ignores PAM for authentication in the case of "encrypt passwords = yes".
If we set "obey pam restrictions" attribute to "no", then there are no PAM
related error messages and also the CIFS share is accessible from windows 
clients.

RESOLUTION:
Set obey pam restrictions = no in
/opt/VRTSvcs/bin/ApplicationNone/smb.conf before doing cfsshare config and
adding share.

Patch ID: VRTSvxvm-6.2.1.000

* 3661856 (Tracking ID: 3656155)

SYMPTOM:
Import of VxVM diskgroup triggered from CVMVolDg agent fails with following error message.
VxVM vxdg ERROR V-5-1-10978 Disk group <dg_name>: import failed:
SCSI3-PR is disabled. Enable it to allow operation

DESCRIPTION:
CVMVolDg import script does not handle non-scsi3 based fencing.
It just checks whether fencing is enabled, and it then tries to import the disk group with SCSI based fencing.
Hence import fails for the non-SCSI based fencing.

RESOLUTION:
CVMVolDg script now checks the return value of 'vxdctl scsi3pr' in addition to 'usefence' attribute.

* 3717930 (Tracking ID: 3757778)

SYMPTOM:
After executing the hastop -local command, the vxconfigd(1M) daemon is not accessible.

DESCRIPTION:
If any process is constantly performing I/O on a mount point and the hastop -local command is executed on that system, then the system calls cfsmount or offline script to umount all the mounted resources. As I/O is performed on the mounted file system, normal umount actions fail and then the script tries to kill the process running on the mounted file system with fuser -km. But the argument passed to the fuser command is device name on which FS is mounted. Hence, fuser kills the vxconfigd(1M) daemon.

RESOLUTION:
The code is modified such that while executing fuser -km, provide mount point, instead of the mount device name to properly kill the processes running on the mounted file system.

* 3745321 (Tracking ID: 3760033)

SYMPTOM:
cfsshare command may report VCS error messages.

DESCRIPTION:
In case of Checkpoints, the volume name is of format 
volume_name:checkpoint_name which causes internal IO testing on that
volume  to fail due to semicolon(':') in between.Hence the cluster volume 
manager(CVM) volume disk group corresponding to the volume goes in FAULTED 
state and all the  mount points will be automatically unmounted.Due to this, 
VCS Error messages are reported and also faulting the depending cfsmount 
resources are deleted automatically.The state is same even after the manual 
cfsmount.

RESOLUTION:
Added a check which will add skip adding volume to CVMVolumeIoTest 
atrribute for the cvmvoldg group in case of checkpoints.

* 3746594 (Tracking ID: 3767771)

SYMPTOM:
CVMVOLDG agent does not deport shared disk groups when these disks go
into the disable state.

DESCRIPTION:
When a shared disk group is disabled due to storage failures, the
CVMVOLDG agent does not deport these  disks  automatically. When storage comes
back, the CVMVOLDG agent does not import the shared disk group, either. Thus,
the disk groups must be deported or imported  manually.

RESOLUTION:
The code is modified to handle the scenario where  the shared disk group gets
into the disabled state, the CVMVOLDG agent deports the disabled shared disk
group automatically; whenever storage comes back, manual clear and online
corresponding CVMVOLDG resources, which automatically imports the disk group.

* 3762371 (Tracking ID: 3737329)

SYMPTOM:
Added support for RHEL7.1

DESCRIPTION:
Added support for RHEL7.1

RESOLUTION:
Added support for RHEL7.1

* 3762380 (Tracking ID: 3697141)

SYMPTOM:
Added support for Sles12

DESCRIPTION:
Added support for Sles12

RESOLUTION:
Added support for Sles12

* 3753724 (Tracking ID: 3731844)

SYMPTOM:
umount -r option fails for vxfs 6.2 with error "invalid options"

DESCRIPTION:
Till 6.2 vxfs did not have a umount helper on linux. We added a helper in 6.2,
because of this, each call to linux's umount also gets called to the umount
helper binary. Due to this the -r option, which was only handled by the linux
native umount, is forwarded to the umount.vxfs helper, which exits while
processing the option string becase we don't support readonly remounts.

RESOLUTION:
To solve this, we've changed the umount.vxfs code to not exit on
"-r" option, although we do not support readonly remounts, so if umount -r
actually fails and the os umount attempts a readonly remount, the mount.vxfs
binary will then exit with an error. This solves the problem of linux's default
scripts not working for our fs.

* 3754492 (Tracking ID: 3761603)

SYMPTOM:
Full fsck flag will be set incorrectly at the mount time.

DESCRIPTION:
There might be possibility that extop processing will be deferred 
during umount (i.e. in case of crash or disk failure) and will be kept on 
disk, so that mount can process them. During mount, inode can have multiple 
extop set. Previously if inode has trim and reorg extop set during mount, we 
were incorrectly setting fullfsck. This patch avoids this situation.

RESOLUTION:
Code is modified to avoid such unnecessary setting of fullfsck.

* 3756002 (Tracking ID: 3764824)

SYMPTOM:
Internal cluster file system(CFS) testing hit debug assert

DESCRIPTION:
Internal debug assert is seen when there is a glm recovery while one 
of the secondary  nodes is doing mount, specifically when glm recovery happens 
between attaching a file system and mounting file system.

RESOLUTION:
Code is modified to handle glm reconfiguration issue.

* 3765324 (Tracking ID: 3736398)

SYMPTOM:
Panic in the lazy unmount path during deinit of VxFS-VxVM API.

DESCRIPTION:
The panic is caused when an exiting thread drops the last reference
to a lazy-unmounted VxFS file-system where that fs is the last VxFS mount in the
system. The exiting thread does unmount, which then calls into VxVM to
de-initialize the private FS-VM API(as it is the last VxFS mounted fs). 
The function to be called in VxVM is looked-up via the files under /proc, this
requires an opening of a file but the exit processing has removed the structs
needed by the thread to open a file.

RESOLUTION:
The solution is to cache the de-init function (vx_fsvm_api_deinit)
when the VxFS-VxVM API is initialized, so no function look-up is needed during
an unmount. The cached function pointer can then be called during the last
unmount bypassing the need to open the file by the exiting thread.

* 3765998 (Tracking ID: 3759886)

SYMPTOM:
In case of nested mount, force umount of parent leaves stale child 
entry in /etc/mtab even after subsequent umount of child.

DESCRIPTION:
On rhel6 and sles11, in case of nested mount, if parent mount 
(say /mnt1) was removed/umounted forcefully, then child mounts (like /mnt1/dir) 
also get umounted but the "/etc/mtab" entry was not getting updated accordingly 
for child mount. Previously it was possible to remove such child entries from 
"/etc/mtab" by using os's umount binary. But from shikra on words, we have 
added helper umount binary in "/sbin/umount.vxfs". So now os's umount binary 
will call this helper binary which in turn call vxumount for child umount 
which will fail since path was not present. Hence mtab entry will not get
updated and will show child as mounted.

RESOLUTION:
Code is modified to update mnttab when ENOENT error is returned 
by umount() system call.

* 3769992 (Tracking ID: 3729158)

SYMPTOM:
fuser and other commands hang on vxfs file systems.

DESCRIPTION:
The hang is seen while 2 threads contest for 2 locks -ILOCK and
PLOCK. The writeadvise thread owns the ILOCK but is waiting for the PLOCK.
The dalloc thread owns the PLOCK and is waiting for the ILOCK.

RESOLUTION:
Correct order of locking is PLOCK followed by the ILOCK.

* 3793241 (Tracking ID: 3793240)

SYMPTOM:
Vxrestore command dumps core file because of invalid japanese 
strings.

DESCRIPTION:
Vxrestore command dumps core file because of invalid characters 
such as %, $ etc. are present in the japanese strings.

RESOLUTION:
code is modified to remove the extra characters from the 
Japanese message strings.

* 3798437 (Tracking ID: 3812914)

SYMPTOM:
On RHEL 6.5 and RHEL 6.4 latest kernel patch, umount(8) system call hangs if an
application watches for inode events using inotify(7) APIs.

DESCRIPTION:
On RHEL 6.5 and RHEL 6.4 latest kernel patch, additional OS counters were added in
the super block to track inotify Watches. These new counters were not implemented
in VxFS for RHEL6.5/RHEL6.4 kernel. Hence, while doing umount, the operation hangs
until the counter in the superblock drops to zero, which would never happen since
they are not handled in VxFS.

RESOLUTION:
The code is modified to handle additional counters added in super block of
RHEL6.5/RHEL6.4 latest kernel.

* 3808285 (Tracking ID: 3808284)

SYMPTOM:
fsdedupadm status Japanese text includes strange character.

DESCRIPTION:
The translation of FAILED string in English  is incorrect in Japanese 
and is "I/O" which stands for The failed I / O.So the translation from 
English to Japanese is not correct.

RESOLUTION:
Corrected the translation for "FAILED" string in Japanese.

* 3817120 (Tracking ID: 3804400)

SYMPTOM:
VRTS/bin/cp does not return any error when quota hard limit is 
reached and partial write is encountered.

DESCRIPTION:
When quota hard limit is reached, VRTS/bin/cp may encounter a 
partial write, but it may not return any error to up layer application in 
such situation.

RESOLUTION:
Adjust VRTS/bin/cp to detect the partial write caused by quota 
limit, and return a proper error to up layer application.

* 3821688 (Tracking ID: 3821686)

SYMPTOM:
VxFS module might not get loaded on SLES11 SP4.

DESCRIPTION:
Since SLES11 SP4 is new release therefore VxFS module failed to load
on it.

RESOLUTION:
Added VxFS support for SLES11 SP4.

Patch ID: VRTSvxfs-6.2.1.000

* 3093833 (Tracking ID: 3093821)

SYMPTOM:
The system panics due to referring freed super block after the vx_unmount() function errors.

DESCRIPTION:
In the file system unmount process, once Linux VFS calls in to VxFS specific unmount processing vx_unmount(), it doesn't expect error from this call. So, once the vx_unmount()function returns, Linux frees the file systems corresponding super_block object. But if any error is observed during vx_unmount(), it may leave file system Inodes in vxfs inode cache as it is. Otherwise, when there is no error, the file system inodes are processed and dropped on vx_unmount().

As file systems inodes left in VxFS inode cache would still point to freed super block object, so now when these inodes on Inode cache are cleaned up to free or reuse, they may refer freed super block in certain cases, which might lead to Panic due to NULL pointer de-reference.

RESOLUTION:
Do not return EIO or ENXIO error from vx_detach_fset() when you unmounts the filesystem. Insted of returning error process, drop inode from the inode cache.

* 3657150 (Tracking ID: 3604071)

SYMPTOM:
With the thin reclaim feature turned on, you can observe high CPU usage on the vxfs thread process. The backtrace of such kind of threads usually look like this:
	 
	 - vx_dalist_getau
	 - vx_recv_bcastgetemapmsg
	 - vx_recvdele
	 - vx_msg_recvreq
	 - vx_msg_process_thread
	 - vx_kthread_init

DESCRIPTION:
In the routine to get the broadcast information of a node which contains maps of Allocation Units (AUs) for which node holds the delegations, the locking mechanism is inefficient. Thus every time when this routine is called, it will perform a series of down-up operation on a certain semaphore. This can result in a huge CPU cost when many threads calling the routine in parallel.

RESOLUTION:
The code is modified to optimize the locking mechanism in the routine to get the broadcast information of a node which contains maps of Allocation Units (AUs) for which node holds the delegations, so that it only does down-up operation on the semaphore once.

* 3657151 (Tracking ID: 3513507)

SYMPTOM:
Filesystem umount() may hang due to deadlock in kernel with the following stack trace and other threads(denoted as T1):
vx_async_waitmsg
vx_msg_broadcast
vx_cwfa_step
vx_cwfreeze_common
vx_cwfreeze_all
vx_freeze
vx_detach_fset
vx_unmount
generic_shutdown_super
sys_umount

In the meanwhile, a thread(T2) is stuck at down_read:
rwsem_down_failed_common
rwsem_down_read_failed
call_rwsem_down_read_failed
down_read
do_page_fault
page_fault
filldir64
vx_readdir_int
mntput_no_expire
vx_irwlock2
vx_readdir
vfs_readdir
sys_getdents64

A thread(T3) is waiting for down_write
rwsem_down_failed_common
rwsem_down_write_failed
call_rwsem_down_write_failed
down_write
sys_munmap

A thread(T4) is doing vx_read?
vx_active_common_flush
vx_read
activate_task
vfs_read
sys_read
system_call_fastpath

DESCRIPTION:
This is a dead lock which involves multiple threads. When the umount thread(T1) 
is initiated, it blocks all file operations from coming into the filesystem and 
waits for those active threads to drop the active levels they have. One of the active thread(T2) hits a pagecache which attempts a rw semaphore of the process memory map structure with read mode. However, this semaphore is held by another thread(T4) with read mode, whilst a write request(T3) is waiting in the queue that prevents other read requests from getting the semaphore. The current read user of the semaphore(T4) is requiring the active level of the file system while holding read semaphore. But the file system is frozen by the first thread(T1).

RESOLUTION:
The code is modified to adjust the active level to avoid the deadlock.

* 3657152 (Tracking ID: 3602322)

SYMPTOM:
System may panic while flushing the dirty pages of the inode. The following 
stack traces are observed:

vx_iflush_list()
vx_workitem_process()
vx_worklist_process()
vx_worklist_thread()

and

vx_vn_cache_deinit()
vx_inode_deinit
vx_ilist_chunkclean()
vx_inode_free_list()
vx_ifree_scan_list()
vx_workitem_process()
vx_worklist_process()
vx_worklist_thread()

DESCRIPTION:
Panic may occur due to the synchronization problem between one thread that 
flushes the inode, and the other thread that frees the chunks that contain the 
inodes on the freelist. 

The thread that frees the chunks of inodes on the freelist grabs an inode, and 
clears/dereference the inode pointer while deinitializing the inode. This may 
result in the pointer dereference, if the flusher thread is working on the same 
inode.

RESOLUTION:
The code is modified to resolve the race condition by taking proper locks on 
the inode and freelist, whenever a pointer in the inode is dereferenced. 

If the inode pointer is already de-initialized to NULL, then the flushing is 
attempted on the next inode.

* 3657153 (Tracking ID: 3622323)

SYMPTOM:
Cluster Filesystem mounted as read-only panics when it gets sharing and/or compression statistics using the fsadm_vxfs(1M) command with the following stack:
	 
	- vx_irwlock
	- vx_clust_fset_curused
	- vx_getcompstats
	- vx_aioctl_getcompstats
	- vx_aioctl_common
	- vx_aioctl
	- vx_unlocked_ioctl
	- vx_ioctl
	- vfs_ioctl
	- do_vfs_ioctl
	- sys_ioctl
	- system_call_fastpath

DESCRIPTION:
When file system is mounted as read-only, part of the initial setup is skipped, including loading of few internal structures. These structures are referenced while gathering statistics for sharing and/or compression. As a result, panic occurs.

RESOLUTION:
The code is modified to only allow "fsadm -HS all" to gather sharing and/or compression statistics on read-write file systems. On read-only file systems, this command fails.

* 3657156 (Tracking ID: 3604750)

SYMPTOM:
The kernel loops during the extent re-org with the following stack trace:
vx_bmap_enter()
vx_reorg_enter_zfod()
vx_reorg_emap()
vx_extmap_reorg()
vx_reorg()
vx_aioctl_full()
$cold_vx_aioctl_common()
vx_aioctl()
vx_ioctl()
vno_ioctl()
ioctl()
syscall()

DESCRIPTION:
The extent re-org minimizes the file system fragmentation. When the re-org 
request is issued for an inode with a lot of ZFOD extents, it reallocates the 
extents of the original inode to the re-org inode. During this, the ZFOD extent 
are preserved and enter the re-org inode in a transaction. If the extent 
allocated is big, the transaction that enters the ZFOD extents becomes big and 
returns an error. Even when the transaction is retried the same issue occurs. 
As a result, the kernel loops during the extent re-org.

RESOLUTION:
The code is modified to enter the Bmap (block map) of the allocated extent and 
then perform the ZFOD processing. If you get a committable error during the 
ZFOD enter, then commit the transaction and continue with the ZFOD enter.

* 3657157 (Tracking ID: 3617191)

SYMPTOM:
Checkpoint creation may take hours.

DESCRIPTION:
During checkpoint creation, with an inode marked for removal and being overlaid, there may be a downstream clone and VxFS starts pulling all the data. With Oracle it's evident because of temporary files deletion during checkpoint creation.

RESOLUTION:
The code is modified to selectively pull the data, only if a downstream push inode exists for file.

* 3657158 (Tracking ID: 3601943)

SYMPTOM:
The block map tree of a file is corrupted across the levels, and during truncating, inode for the file may lead to an infinite loop.


There are various

DESCRIPTION:
For files larger than 64G, truncation code first walks through the bmap tree to find the optimal offset from which to begin the truncation. 
If this truncation falls within corrupted range of the bmap, actual truncation 
code which relies on binary search to find this offset. As a result, the truncation cannot find the offset, thus it returns empty. The output makes the truncation code to submit dummy transaction, which updates the inode of file with latest ctime, without freeing the extents allocated.

RESOLUTION:
The truncation code is modified to detect the corruption, mark the inode bad and, mark the file system for full-fsck. The modification makes the truncation  possible for full fsck. Next time when it runs, the truncation code is able to throw out the inode and free the extents.

* 3657159 (Tracking ID: 3633067)

SYMPTOM:
While converting from ext3 file system to VxFS using vxfsconvert, it is observed that many inodes are missing.

DESCRIPTION:
When vxfsconvert(1M) is run on an ext3 file system, it misses an entire block group of inodes. This happens because of an incorrect calculation of block group number of a given inode in border case. The inode which is the last inode for a given block group is calculated to have the correct inode offset, but is calculated to be in the next block group. This causes
 the entire next block group to be skipped when the code attempts to find the next consecutive inode.

RESOLUTION:
The code is modified to correct the calculation of block group number.

* 3665980 (Tracking ID: 2059611)

SYMPTOM:
The system panics due to a NULL pointer dereference while flushing the
bitmaps to the disk and the following stack trace is displayed:


vx_unlockmap+0x10c
vx_tflush_map+0x51c
vx_fsq_flush+0x504
vx_fsflush_fsq+0x190
vx_workitem_process+0x1c
vx_worklist_process+0x2b0
vx_worklist_thread+0x78

DESCRIPTION:
The vx_unlockmap() function unlocks a map structure of the file
system. If the map is being used, the hold count is incremented. The
vx_unlockmap() function attempts to check whether this is an empty mlink doubly
linked list. The asynchronous vx_mapiodone routine can change the link at random
even though the hold count is zero.

RESOLUTION:
The code is modified to change the evaluation rule inside the
vx_unlockmap() function, so that further evaluation can be skipped over when map
hold count is zero.

* 3665984 (Tracking ID: 2439261)

SYMPTOM:
When the vx_fiostats_tunable is changed from zero to non-zero, the
system panics with the following stack trace:
vx_fiostats_do_update
vx_fiostats_update
vx_read1
vx_rdwr
vno_rw
rwuio
pread

DESCRIPTION:
When vx_fiostats_tunable is changed from zero to non-zero, all the
incore-inode fiostats attributes are set to NULL. When these attributes are
accessed, the system panics due to the NULL pointer dereference.

RESOLUTION:
The code has been modified to check the file I/O stat attributes are
present before dereferencing the pointers.

* 3665990 (Tracking ID: 3567027)

SYMPTOM:
During the File System resize operation, the "fullfsck flag is set with the following message:vxfs: msgcnt 183168 mesg 096: V-2-96: vx_setfsflags - /dev/vx/dsk/sfsdg/vol file system fullfsck flag set - vx_fs_upgrade_reorg

DESCRIPTION:
File system resize requires some temporary inodes to swap the old inode and the converted inode. However, before a structural inode ise processed, the "fullfsck flag is set when a failure occurs during the metadata change. The flag is cleared after the swap is successfully completed.

If the temporary inode allocation fails, VxFS leaves the fullfsck flag on the 
disk. However, all temporary inodes can be cleaned up when not being in use, 
thus these temporary inodes do not result in corruption.

RESOLUTION:
The code is modified to clear the fullfsck flag if the structural inode conversion cannot create its temporary inode.

* 3666007 (Tracking ID: 3594386)

SYMPTOM:
On installing VxFS 5.1SP1RP4P1HF1 on RHEL6u5, system panic occurs when 
ftrace(1M) is enabled and multiple files are created when large amount of space 
is consumed.

DESCRIPTION:
The system panic occurs when the stack overflow happens through 
the bio_alloc() function that was initiated through a routine. The routine is 
where the bio_alloc() function exits VxFS and call through the block layer.

RESOLUTION:
The code is modified by adding a new handoff routine that would 
hand off the bio_alloc() task to a new worker thread in case the remaining 
stack was insufficient to proceed.

* 3666008 (Tracking ID: 3616907)

SYMPTOM:
While performing the garbage collection operation, VxFS causes the non-maskable 
interrupt (NMI) service to stall.

DESCRIPTION:
With a highly fragmented Reference Count Table (RCT), when a garbage collection 
operation is performed, the CPU could be used for a longer duration. The CPU 
could be busy if a potential entry that could be freed is not identified.

RESOLUTION:
The code is modified such that the CPU is released after a when it is idle 
after a specified time interval.

* 3666010 (Tracking ID: 3233276)

SYMPTOM:
On a 40 TB file system, the fsclustadm setprimary command consumes more than 2 minutes for execution. And, the unmount operation consumes more time causing a primary migration.

DESCRIPTION:
The old primary needs to process the delegated allocation units while migrating
from primary to secondary. The inefficient implementation of the allocation unit
list is consuming more time while removing the element from the list. As the file system size increases, the allocation unit list also increases, which results in additional migration time.

RESOLUTION:
The code is modified to process the allocation unit list efficiently. With this modification, the primary migration is completed in 1 second on the 40 TB file system.

* 3683470 (Tracking ID: 3682138)

SYMPTOM:
The VxVM symbols are released before the VxFS modules unload time.

DESCRIPTION:
On RHEL7, the VxFS module receives or adds VxVM symbol as follows:

1. Get or imports all required VxVM symbols on first access or on first mount. 
Refcnt/hold for VxVM module is incremented through VEKI on symbol_get request so that module doesnt get unloaded.
   2. The symbols (imported in step 1) are used as required.
3. VxFS puts/releases VxVM symbols during the VxFS unload time. Refcnt is decremented/hold is released. As a result, VxVM module unloads until the VxFS module is unloaded.
   Manual upgrade of VxVM pkg cannot happen until the VxFS 
   modules are unloaded

RESOLUTION:
The code is modified to release VxVM symbols before the VxFS modules unload time.

* 3687679 (Tracking ID: 3685391)

SYMPTOM:
Execute permissions for a file not honored correctly.

DESCRIPTION:
The user was able to execute the file regardless of not having the execute permissions.

RESOLUTION:
The code is modified such that an error is reported when the execute permissions are not applied.

* 3697142 (Tracking ID: 3697141)

SYMPTOM:
Added support for Sles12

DESCRIPTION:
Added support for Sles12

RESOLUTION:
Added support for Sles12

* 3697966 (Tracking ID: 3697964)

SYMPTOM:
When a file system is upgraded, the upgraded layout clears the superblock flags (fs_flags).

DESCRIPTION:
When a file system is upgraded, the new superblock structure gets populated with the field values. Most of these values are inherited from the old superblock. As a result, the fs_flags values are overwritten and the flags such as VX_SINGLEDEV are deleted from the superblock.

RESOLUTION:
The code is modified to restore the old superblock flags while upgrading the disk layout of a file system.

* 3698165 (Tracking ID: 3690078)

SYMPTOM:
The system panics at vx_dev_strategy() routine with the following stack trace:
vx_snap_strategy()
vx_logbuf_write() 
vx_logbuf_io()
vx_logbuf_flush() 
vx_logflush()
vx_mapstrategy() 
vx_snap_strategy() 
vx_clonemap() 
vx_unlockmap() 
vx_holdmap() 
vx_extmaptran() 
vx_extmapchange() 
vx_extprevfind() 
vx_extentalloc() 
vx_te_bmap_alloc() 
vx_bmap_alloc_typed() 
vx_bmap_alloc() 
vx_get_alloc() 
vx_cfs_pagealloc() 
vx_alloc_getpage() 
vx_do_getpage() 
vx_internal_alloc() 
vx_write_alloc() 
vx_write1() 
vx_write_common_slow()
vx_write_common() 
vx_vop_write()
vx_writev() 
vx_naio_write_v2() 
vfs_writev()

DESCRIPTION:
The issue was observed due to low handoff limit of vx_extprevfind.

RESOLUTION:
The code is modified  to avoid the stack overflow.

* 3706864 (Tracking ID: 3709947)

SYMPTOM:
The SSD cache fails to go offline due to additional slashes "//" in the dev path of the cache device.

DESCRIPTION:
The conv_to_bdev() function authenticates whether a path contains rdsk (character device) or dsk (disk device). 
If rdsk is present, the fs_convto_bspec() function calls the fs_pathcanon() function to remove the additional slashes.
In case the path contains dsk (disk device) then VxFS refuses to call the functions. As a result, the additional slashes appear in the final output path.

RESOLUTION:
The code is modified to enable VxFS to call  the correct functions.

* 3710794 (Tracking ID: 3710792)

SYMPTOM:
Unmount fails when the mount point contains a special character (colon).

DESCRIPTION:
For clones, the pseudo device name must contain <devicepath>:<clone name>. Thus, when using the cloned block device, the umount codepath performs an exclusive processing to unmount the device. Sometimes, the mount point itself can be created using the special character (colon). As a result, the  mount point splits at the colon.

RESOLUTION:
The code is modified to unsplit the mount point if it is not a block device and it is a real mount point that can be searched in the mounted file systems table (mtab).

* 3715567 (Tracking ID: 3715566)

SYMPTOM:
VxFS fails to report an error  when the maxlink and nomaxlink options are set for disk layout version (DLV) lower than 10.

DESCRIPTION:
The maxlink and nomaxlink options allow you to enable and disable the maxlink support feature respectively. The maxlink support feature operates only on DLV version 10. Due to an issue, the maxlink and nomaxlink options wrongly appear in DLV versions lower than 10. However, when selected the options do not take effect.

RESOLUTION:
The code is modified such that VxFS reports an error when you attempt to  set the maxlink and nomaxlink options for DLV version lower than 10.

* 3716627 (Tracking ID: 3622326)

SYMPTOM:
During a checkpoint promote, a file system is marked with a fullfsck flag because the corresponding inode is marked as bad.

DESCRIPTION:
The issue was observed because VxFS skipped moving the data to clone inode. As a result, the inode is marked bad during a checkpoint promote and as a consequence the file system is marked with a fullfsck flag.

RESOLUTION:
The code is modified to move the correct data to the clone inode.

* 3717895 (Tracking ID: 2919310)

SYMPTOM:
During stress testing on cluster file system, an assertion failure was hit because of a missing linkage between the directory and the associated attribute inode.

DESCRIPTION:
As per the designed behavior, the node which owns the inode of the file, receives the request to remove the file from the directory. If the directory has an alternate index (hash directory) present, then in the file remove receive handler, the attribute inode is read from the disk. However, VxFS does not create a linkage between the directory and the corresponding inode, which results in an assert failure.

RESOLUTION:
The code is modified to set the directory inodes i_dirhash field to attribute inode. This change is exercised while bringing the inode incore during file or directory removal.

* 3718542 (Tracking ID: 3269553)

SYMPTOM:
VxFS returns inappropriate message for read of hole via ODM.

DESCRIPTION:
Sometimes sparse files containing temp or backup/restore files are created outside the Oracle database. And, Oracle can read these files only using the ODM. As a result, ODM fails with an ENOTSUP error.

RESOLUTION:
The code is modified to return zeros instead of an error.

* 3721458 (Tracking ID: 3721466)

SYMPTOM:
After a file system is upgraded from version 6 to 7, the vxupgrade(1M) command fails to set the VX_SINGLEDEV flag on a superblock.

DESCRIPTION:
The VX_SINGLEDEV flag was introduced in disk layout version 7.
The purpose of the flag is to indicate whether a file system resides only on a single device or a volume.
When the disk layout is upgraded from version 6 to 7, the flag is not inherited along with the other values since it was not supported in version 6.

RESOLUTION:
The code is modified to set the VX_SINGLEDEV flag when the disk layout is upgraded from version 6 to 7.

* 3726403 (Tracking ID: 3739618)

SYMPTOM:
sfcache command with the "-i" option may not show filesystem cache statistic periodically.

DESCRIPTION:
sfcache command with the "-i" option may not show filesystem cache statistic periodically.

RESOLUTION:
The code is modified to add a loop to print sfcache statistics at the specified interval.

* 3727166 (Tracking ID: 3727165)

SYMPTOM:
Enhance RHEV support for SF devices for identification in Guest

DESCRIPTION:
We need a provision of assigning serial no to a device while
attach. This would be passed on as the serial no of the scsi device to the
guest. As a result, scsi inquiry on the device should return the provided serial
no in Vendor specific data.

RESOLUTION:
Corresponding changes for supplying the serial number to the vxfs
hook is done

* 3729704 (Tracking ID: 3719523)

SYMPTOM:
'vxupgrade' does not clear the superblock replica of old layout versions.

DESCRIPTION:
While upgrading the file system to a new layout version, a new superblock inode is allocated and an extent is allocated for the replica superblock. After writing the new superblock (primary + replica), VxFS frees the extent of the old superblock replica.
Now, if the primary superblock corrupts, the full fsck searches for replica to repair the file system. If it finds the replica of old superblock, it restores the file system to the old layout, instead of creating a new one. This behavior is wrong.
In order to take the file system to a new version, we should clear the replica of old superblock as part of vxupgrade, so that full fsck won't detect it later.

RESOLUTION:
Clear the replica of old superblock as part of vxupgrade.

* 3733811 (Tracking ID: 3729030)

SYMPTOM:
The fsdedupschd daemon failed to start on RHEL7.

DESCRIPTION:
The dedup service daemon failed to start because RHEL 7 changed the service management mechanism. The daemon uses the new systemctl to start and stop the service. For the systemctl to properly start, stop, or query the service, it needs a service definition file under the /usr/lib/systemd/system.

RESOLUTION:
The code is modified to create the fsdedupschd.service file while installing the VRTSfsadv package.

* 3733812 (Tracking ID: 3729030)

SYMPTOM:
The fsdedupschd daemon failed to start on RHEL7.

DESCRIPTION:
The dedup service daemon failed to start because RHEL 7 changed the service management mechanism. The daemon uses the new systemctl to start and stop the service. For the systemctl to properly start, stop, or query the service, it needs a service definition file under the /usr/lib/systemd/system.

RESOLUTION:
The code is modified to create the fsdedupschd.service file while installing the VRTSfsadv package.

* 3737330 (Tracking ID: 3737329)

SYMPTOM:
Added support for RHEL7.1

DESCRIPTION:
Added support for RHEL7.1

RESOLUTION:
Added support for RHEL7.1

* 3743913 (Tracking ID: 3743912)

SYMPTOM:
Users could create sub-directories more than 64K for disk layouts having versions lower than 10.

DESCRIPTION:
In this release, the maxlink feature enables users to create sub-directories larger than 64K.This feature is supported on disk layouts whose versions are higher than or equal to 10. The macro VX_TUNEMAXLINK denotes the maximum limitation on sub-directories. And, its value was changed from 64K to 4 billion. Due to this, users could create more than 64K sub-directories for layout versions < 10 as well, which is undesirable.
This fix is applicable only on platforms other than AIX.

RESOLUTION:
The code is modified such that now you can set the value of sub-directory limitation to 64K for layouts whose versions are lower than 10.

* 3744425 (Tracking ID: 3744424)

SYMPTOM:
Rebundled the fix "Openssl: Common Vulnerability and Exposure (CVE) CVE-2014-3566 (POODLE)" as 
6.2.1.

DESCRIPTION:
VRTSfsadv package uses old versions of OpenSSL which are vulnerable to
POODLE(CVE-2014-3566) 
and Hearbleed(CVE-2014-0160). By upgrading to OpenSSL 0.9.8zc, many security
vulnerabilities 
have been fixed.

RESOLUTION:
The VRTSfsadv package is built with OpenSSL 0.9.8zc..

* 3745651 (Tracking ID: 3642314)

SYMPTOM:
Umount operation reports an  error code 255 in case of write-back cache.

DESCRIPTION:
Umount helper binary uses umount or umount2 system calls to unmount VxFS file system. In case of error, these system calls return -1. The umount helper returns this value to the system(OSes) umount binary which interpreted it as 255.

RESOLUTION:
The code is modified to maintain consistency with the operating systems behavior. In case of umount failure, it must return MOUNT_EX_FAIL which is defined as 32 for RHEL7 and 1 for RHEL6 or SLES11.

* 3749727 (Tracking ID: 3750187)

SYMPTOM:
Internal noise testing hits debug assert.

DESCRIPTION:
The issue is observed becasue Linux inodes are not initialized properly. Initialization of Linux inodes are done at some VxFS entry points like vx_lookup. In write back replay, an inode is created based on the inode number in log and similar initialization is required here as well.

RESOLUTION:
The code is modified to have proper initialization of inodes.

* 3749776 (Tracking ID: 3637636)

SYMPTOM:
Cluster File System (CFS) node initialization and protocol upgrade may hang during rolling upgrade with the following stack trace:
vx_svar_sleep_unlock()
vx_event_wait()
vx_async_waitmsg()
vx_msg_broadcast()
vx_msg_send_join_version()
vx_msg_send_join()
vx_msg_gab_register()
vx_cfs_init()
vx_cfs_reg_fsckd()
vx_cfsaioctl()
vxportalunlockedkioctl()
vxportalunlockedioctl()

And

vx_delay()
vx_recv_protocol_upgrade_intent_msg()
vx_recv_protocol_upgrade()
vx_ctl_process_thread()
vx_kthread_init()

DESCRIPTION:
CFS node initialization waits for the protocol upgrade to complete. Protocol upgrade waits for the flag related to the CFS initialization to be cleared. As the result, the deadlock occurs.

RESOLUTION:
The code is modified so that the protocol upgrade process does not wait to clear the CFS initialization flag.

* 3755796 (Tracking ID: 3756750)

SYMPTOM:
VxFS may leak memory when File Design Driver (FDD) module is unloaded before the cache file system is taken offline.

DESCRIPTION:
When FDD module is unloaded before the cache file system is taken offline, few FDD related structures in the cache file system remains to be free. As a result, memory leak is observed.

RESOLUTION:
The code is modified such that FDD related structure is not initialized for cache file systems.

Patch ID: 6.2.0.100

* 3703631 (Tracking ID: 3615043)

SYMPTOM:
At times, while writing to a file, data could be missed.

DESCRIPTION:
While writing to a file when delayed allocation is on, Solaris could dishonour the NON_CLUSTERING flag and 
cluster pages beyond the range for which we have issued the flushing, leading to data loss.

RESOLUTION:
Make sure we clear the flag and flush the exact range, in case of dalloc.

Patch ID: VRTSdbac-6.2.0.100-RHEL7

* 3861194 (Tracking ID: 3861191)

SYMPTOM:
VRTSdbac patch version does not work with RHEL7.2 (3.10.0-319.el7.x86_64 
kernel) and is unable to load the vcsmm module on RHEL7.2 .

DESCRIPTION:
Installation of VRTSdbac patch version 6.2.0 fails on RHEL7.2 as 
the VCSMM module is not available on RHEL7.2 kernel 3.10.0-319.el7.x86_64. 
The system log file logs the following messages:
Starting VCSMM: 
ERROR: No appropriate modules found.
Error in loading module "vcsmm". See documentation.
Error : VCSMM driver could not be loaded.
Error : VCSMM could not be started.
Error : VCSMM could not be started.

RESOLUTION:
The VRTSdbac package is re-compiled with RHEL7.2 kernel in the build 
environment to mitigate the failure.

Patch ID: VRTSllt-6.2.1.200-RHEL7

* 3861312 (Tracking ID: 3861308)

SYMPTOM:
Veritas Cluster Server (VCS) does not support Red Hat Enterprise Linux 7 Update
2 (RHEL7.2).

DESCRIPTION:
VCS did not support RHEL versions released after Red Hat Enterprise Linux 7
Update 1 (RHEL7.1).

RESOLUTION:
VCS support for Red Hat Enterprise Linux 7 Update 2 (RHEL7.2) is now introduced.

Patch ID: VRTSvcs-6.2.1.100-RHEL7

* 3869873 (Tracking ID: 3869872)

SYMPTOM:
After executing the hastart command, the HAD, hashadow and agent processes 
start in user.slice instead of system.slice.

DESCRIPTION:
After a reboot operation, HAD, hashadow, CmdServer and agent processes 
start in system.slice under vcs.service. But after executing the hastop operation 
followed by the hastart operation, CmdServer remains in 'system.slice', while HAD, 
hashadow and the agent processes wrongly start in 'user.slice'. If the system 
reboots or shuts down while HAD is in user.slice, the HAD gets killed before it can 
execute offline operations for the resources.

RESOLUTION:
The code is modified to start HAD, hashadow and agent processes under 
'system.slice'.
Note: This issue is specific to RHEL 7 Update 1 and 2

Patch ID: VRTSvcsea-6.2.1.100-RHEL7

* 3871617 (Tracking ID: 3871614)

SYMPTOM:
If HAD is running in the user.slice then during system reboot, Oracle (or its applications) running as a non-root user do not shut down gracefully.

DESCRIPTION:
On RHEL7 and SLES12, systemd is enabled. Therefore, all the processes running under user.slice are killed on system reboot. Since Oracle (or its applications) run under user.slice by default, a system reboot may cause Oracle to crash or udergo an abrupt shut down.

RESOLUTION:
Move the Oracle processes to system.slice to prevent them from an abrupt shut down during a system reboot.

Patch ID: VRTSgab-6.2.1.300

* 3875807 (Tracking ID: 3875805)

SYMPTOM:
A port on a node receives an I/O fence message when the membership for that 
port changes. This is caused by some unicast messages being stuck in the GAB 
receive queue of that port.

DESCRIPTION:
Under certain rare situation, a few unicast messages which belong to a future 
generation get stuck in the GAB receive queue of a port. This causes unintended 
consequences like preventing a RECONFIG message from being delivered to that 
port. In this case, the port receives an I/O fence message from the GAB to 
ensure the consistency in membership.

RESOLUTION:
The code is modified to ensure that the unicast messages belonging to future 
generation are never left pending in the GAB receive queue of a port.



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 sfha-rhel7_x86_64-Patch-6.2.1.200.tar.gz to /tmp
2. Untar sfha-rhel7_x86_64-Patch-6.2.1.200.tar.gz to /tmp/hf
    # mkdir /tmp/hf
    # cd /tmp/hf
    # gunzip /tmp/sfha-rhel7_x86_64-Patch-6.2.1.200.tar.gz
    # tar xf /tmp/sfha-rhel7_x86_64-Patch-6.2.1.200.tar
3. Install the hotfix(Please be noted that the installation of this P-Patch will cause downtime.)
    # pwd /tmp/hf
    # ./installSFHA621P2 [<host1> <host2>...]

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

Install the patch manually:
--------------------------
Manually installing of this patch is not recommended.


REMOVING THE PATCH
------------------
Removing this patch is not recommended.


SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE