* * * READ ME * * *
               * * * Veritas File System 5.0.1 RP3 * * *
                         * * * P-patch 5 * * *
                         Patch Date: 2012-08-03


This document provides the following information:

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


PATCH NAME
----------
Veritas File System 5.0.1 RP3 P-patch 5


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


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas File System 5.0.1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
HP-UX 11i v3 (11.31)


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

Patch ID: HKL_42892, PHCO_42893, PHCO_42894

* 1946124 (Tracking ID: 1797955)

SYMPTOM:
In a setup that involves files with large extents (greater than 32 MB), which 
have encountered state map corruptions previously, the file system is disabled 
and the following message is displayed in the syslog:
WARNING: msgcnt 3 mesg 037: V-2-37: vx_metaioerr - vx_tflush_1 -
 /dev/vx/dsk/<vol group name>/<vol name> file system meta data write error in 
dev/block ?/????

DESCRIPTION:
The file system is disabled after an existing corruption is discovered. 
According to the VxFS I/O error policy, the file system must be disabled only 
when a read/write operation fails with an I/O error to prevent further 
corruption and not when an existing corruption is discovered.

RESOLUTION:
The code has been modified such that the file system is not disabled in case of 
a discovered corruption.

* 1946136 (Tracking ID: 1859532)

SYMPTOM:
The umount (1M) operation on a file system checkpoint fails with a file system 
busy message after using for File Change Log(FCL) Application Program 
Interfaces (API) for FCL operations.

DESCRIPTION:
The FCL file is not closed while using FCL APIs for a read only checkpoint. 
This leads to the failure of the umount(1M) operation as the file remains open.

RESOLUTION:
The code is modified to close the FCL file even for a read only checkpoint.

* 1995390 (Tracking ID: 1985626)

SYMPTOM:
The system panics during multiple parallel unmount operations. The following 
stack trace is displayed:
vx_freeze_idone_list+24c 
vx_workitem_process+10
vx_worklist_process+344
vx_worklist_thread+94

DESCRIPTION:
During simultaneous unmount operations, a race condition occurs 
between the INODE_DEINIT() and FREEZE_IDONE_LIST() functions. While the 
INODE_DEINIT() function uses locks, the FREEZE_IDONE_LIST() function does not 
use locks while updating a pointer value. Hence, there is a possibility of a 
pointer having a NULL value, which gets de-referenced. This results in a panic.

RESOLUTION:
The code is modified to serialize the inode de-initialization operation.

* 2036204 (Tracking ID: 2028811)

SYMPTOM:
The ncheck() function dumps core in the printname() function during heavy I/O 
and the following stack trace is displayed:
printname+0x24c()
do_dirblk+0x21c()
nxtpass+0x3a4()
check+0x488()
checkallfilesets+0x620()
main+0x78()
_start+0x108()

DESCRIPTION:
When files are created under different directories in parallel and the ncheck() 
function starts printing the name of a new directory entry that has been 
created and whose inode number is greater than the maximum inode number, it is 
possible that the inodes beyond the end of print_itable get referenced. This 
results in a core dump.

RESOLUTION:
The code is modified to ensure that the number of inodes is less than the 
maximum number of inodes before performing the printname() function.

* 2036843 (Tracking ID: 2026799)

SYMPTOM:
A hang occurs while enforcing the policy on File Change Log (FCL) inode and the 
following stack trace is displayed:
lwp_park() 
cond_wait_queue ()
cond_wait ()
pthread_cond_wait()
ts_drain_masters()
do_walk_ilist()
do_process() 
do_enforce() 
main()    
_start()

DESCRIPTION:
While enforcing the policy on FCL, the file system is frozen. After enforcing 
the policy on FCL, a function is called which checks whether the file system is 
frozen. If it is frozen, the function returns the EACTIVERETRY error. This 
error gets percolated to further functions. The AIOCTL_COMMON() function 
performs the retry operation endlessly, resulting in a hang.

RESOLUTION:
The code is modified to return the EACTIVERETRY error only if the file system 
is not in the frozen state.

* 2069664 (Tracking ID: 2069059)

SYMPTOM:
A hang occurs in Cluster File System (CFS) when setting a LIBPATH to a CFS 
directory and the following threads are displayed:
pvthread+0B5F00 STACK:
e_block_thread+000278 () 
e_sleep_thread+00005C () 
vxg_ilock_wait+0000A0 () 
vxg_range_lock_body+000384 () 
vxg_api_range_lockwf+0000EC () 
vx_glm_range_lock+000078 () 
vx_glmrange_rangelock+000054 () 
vx_irwlock2+000114 () 
vx_irwlock+00003C () 
vx_recover_fsethdr+000080 () 
vx_assumption+000024 () 
vx_recover+000304 () 
vx_recover_evanesce+00000C () 
vx_thread_base+00002C () 
threadentry+000014 () 
 
pvthread+0B5600 STACK: 
e_block_thread+000278 () 
e_sleep_thread+00005C () 
vxg_get_block+00013C () 
vxg_api_initlock+0002B0 () 
vx_glm_init_blocklock+00005C () 
vx_cbuf_lookup+000280 () 
vx_getblk_clust+0000B4 () 
vx_getblk_cmn+0000BC () 
vx_getblk+00003C () 
vx_rdwrnomap+00032C () 
vx_kernread+000084 () 
vx_recover_fsethdr+000238 () 
vx_assumption+000024 () 
vx_recover+000304 () 
vx_recover_evanesce+00000C () 
vx_thread_base+00002C () 
threadentry+000014 ()

DESCRIPTION:
This issue occurs because of setting a LIBPATH to a CFS directory. When LIBPATH 
is set, every run through the shell opens the CFS directory.  The vxfsckd exec
()'s fsck command may require opening/closing the CFS files if LIBPATH is set 
to a CFS directory. This may cause a deadlock if it is done as a part of the 
log replay during reconfiguration.

RESOLUTION:
The code is modified so that the environment of the vxfsckd() function process 
is not used.

* 2084004 (Tracking ID: 2040647)

SYMPTOM:
Quota on cluster mounted system does not enforce hard limit.

DESCRIPTION:
The information on the hard limit is stored in an unsigned integer. When a 
larger value is subtracted from it, it wraps around and stores an incorrect 
value.

RESOLUTION:
The code is modified to handle the wrap around and special code is added to 
identify the quota soft limit in the Cluster File System (CFS) environment.

* 2090261 (Tracking ID: 2074281)

SYMPTOM:
An attempt to dump the File Control Log (FCL) using the fcladm(1M) command with 
the 'dump' option results in a segmentation fault and the following stack trace 
is displayed:
strlen()
vfprintf()
vx_viprintf()
vx_iprintf () 
fcl_dump ()
main()
 _start()

DESCRIPTION:
The internal function, fcl_dump(), opens the savefile (a command line option of 
the fcladm(1M) command) and if it fails, an error message is displayed. But if 
the savefile option is not specified with fcladm dump, the value of savefile is 
taken as NULL, which causes a segmentation fault in the string length.

RESOLUTION:
The code is modified to add a check for a non NULL savefile and handle the 
error appropriately.

* 2092072 (Tracking ID: 2029556)

SYMPTOM:
When the file system is full, it is not possible to remove a file which has 
more than 13 hard links. This may lead to a panic with the following stack 
trace:
panicsys()
vpanic()
panic()
mutex_panic()
vx_iunlock()
vx_remove_tran()
vx_do_remove()
vx_remove1()
vx_remove()
vn_remove()
unlink()
syscall_trap32()

DESCRIPTION:
While removing or updating an inode, a new attribute inode is allocated which 
is modified. When the file system is full, no new attribute inodes can be 
allocated and the above operation may panic the system.

RESOLUTION:
The code is modified such that the file system can modify the attribute inode 
rather than allocating new attribute inode.

* 2093325 (Tracking ID: 2050731)

SYMPTOM:
when resizing file systems, operation hangs

DESCRIPTION:
active level 1 is leaking due to an internal state variable is not
correctly reset

RESOLUTION:
Adding code to reset the internal variable

* 2114116 (Tracking ID: 2061177)

SYMPTOM:
On systems running Veritas File System (VxFS) version of 5.0MP3RP1, the fsadm
(1M) command with the ' -de' option displays an error with 'bad file number' on 
file systems.

DESCRIPTION:
The fsadm(1M) command maintains an in-core copy of the inode information from 
the disk and may re-read it later for any other processing. The command fails 
with an error because the in-core data and the on disk data are out of 
synchronization.

RESOLUTION:
The code is modified to add a sync operation in the fsadm(1M) command before it 
reads the layout from the raw disk to ensure synchronization of the in-core 
data and the on disk data.

* 2194629 (Tracking ID: 2161379)

SYMPTOM:
In a Cluster File System (CFS) environment, various file system operations hang 
with the following stack trace:
T1:
vx_event_wait()
vx_async_waitmsg()
vx_msg_send()
vx_iread_msg()
vx_rwlock_getdata()
vx_glm_cbfunc()
vx_glmlist_thread()

T2:
vx_ilock()
vx_assume_iowner()
vx_hlock_getdata()
vx_glm_cbfunc()
vx_glmlist_thread()

DESCRIPTION:
Due to improper handling of the ENOTOWNER error in the ireadreceive() function, 
the operation is retried repeatedly while holding an inode lock. All the other 
threads are blocked, thus causing a deadlock.

RESOLUTION:
The code is modified to release the inode lock on the ENOTOWNER error and 
acquire it again, thus resolving the deadlock.

* 2222508 (Tracking ID: 2192895)

SYMPTOM:
A system panic occurs when executing File Change Log (FCL) commands and the 
following stack trace is displayed:
panicsys()
panic_common()
panic()
vmem_xalloc()
vmem_alloc()
segkmem_xalloc()
segkmem_alloc_vn()
vmem_xalloc()
vmem_alloc()
kmem_alloc()
vx_getacl()
vx_getsecattr()
fop_getsecattr()
cacl()
acl()
syscall_trap32()

DESCRIPTION:
The Access Control List (ACL) count in the inode can be corrupted due to a race 
condition. For example, the setacl() function can change the ACL count when the 
getacl() function is processing the same inode. This results in an incorrect 
ACL count.

RESOLUTION:
The code is modified to add protection to the vulnerable ACL count to avoid 
corruption.

* 2370061 (Tracking ID: 2370046)

SYMPTOM:
Read ahead operations miss to read early blocks of data when the value 
of "read_nstream" tunable is not set to 1.
PROBLEM

DESCRIPTION:
The read ahead operation reads the file on demand and does not read the portion 
of the file which is to be read in advance. This occurs because the parameter 
that determines the next read ahead offset is incorrectly reset.

RESOLUTION:
The code is modified so that the read ahead length is set correctly.

* 2720002 (Tracking ID: 1396859)

SYMPTOM:
The internal spin watcher tools show heavy contention on the buffer freelist 
lock, bc_freelist_lock, even when the I/O loads are predominantly direct I/Os.

DESCRIPTION:
Direct I/O data need not be cached in file system buffers. But Veritas File 
System (VxFS) maintains empty buffers to track these requests. Hence, 
contention is seen even when I/O is direct in nature.

RESOLUTION:
The code is modified to have a separate arena to track direct I/O buffers so 
that the contention on the buffer freelist lock is reduced.

* 2722869 (Tracking ID: 1244756)

SYMPTOM:
A lookup operation on a VxFS file system may fail with the following stack 
trace:
vx_cbdnlc_purge_iplist+0x64
vx_inode_free_list+0x160
vx_ifree_scan_list+0xf8
vx_workitem_process+0x10
vx_worklist_process+0x17c
vx_worklist_thread+0x94

DESCRIPTION:
Due to a race condition between the Directory Name Lookup Cache (DNLC) lookup 
and the DNLC get functions, there is an attempt to move a DNLC entry to the 
tail of the freelist in the lookup function when it has already been removed 
from the freelist by the DNLC get function. This leads to a null pointer de-
reference.

RESOLUTION:
The code is modified to verify that the DNLC entry is present on the freelist 
before it is moved to the tail by the DNLC get function.

* 2722958 (Tracking ID: 2696067)

SYMPTOM:
When a getaccess() command is issued on a file which inherits the default 
Access Control List (ACL) entries from the parent, it shows incorrrect group 
object permissions.

DESCRIPTION:
If a newly created file leverages the ACL entries of its parent directory, the 
vx_daccess() function does not fabricate any GROUP_OBJ entry unlike the 
vx_do_getacl() function.

RESOLUTION:
The code is modified to fabricate a GROUP_OBJ entry.

* 2726001 (Tracking ID: 2371710)

SYMPTOM:
User quota file gets corrupted when DELICACHE feature is enabled and the 
current usage of inodes of a user becomes negative after frequent file 
creations and deletions. If the quota information is checked using the vxquota 
command with the '-vu username ' option, the number of files is "-1".
For example:
    # vxquota -vu testuser2
   Disk quotas for testuser2 (uid 500):
   Filesystem     usage  quota  limit     timeleft  files  quota  limit     
timeleft
   /vol01       1127809 8239104 8239104                  -1      0      0

DESCRIPTION:
This issue is introduced by the inode DELICACHE feature which is a performance 
enhancement to optimize the updates done to the inode map during file creation 
and deletion operations. The feature is enabled by default, and can be changed 
by the vxtunefs(1M) command. 
When DELICACHE is enabled and the quota is set for Veritas File System (VxFS), 
there is an extra quota update for the inodes on the inactive list during the 
removal process. Since this quota has been updated already before being put on 
the DELICACHE list, the current number of user files gets decremented twice.

RESOLUTION:
The code is modified to add a flag to identify the inodes which have been moved 
to the inactive list from the DELICACHE list. This flag is used to prevent 
decrementing the quota again during the removal process.

* 2730957 (Tracking ID: 2651922)

SYMPTOM:
On a local VxFS file system, the ls(1M) command with the '-l' option runs 
slowly and high CPU usage is observed.

DESCRIPTION:
Currently, Cluster File System (CFS) inodes are not allowed to be reused as 
local inodes to avoid Global Lock Manager (GLM) deadlo`ck issue when Veritas 
File System (VxFS) reconfiguration is in process. Hence, if a VxFS local inode 
is needed, all the inode free lists need to be traversed to find a local inode 
if the free lists are almost filled up with CFS inodes.

RESOLUTION:
The code is modified to add a global variable, 'vxi_icache_cfsinodes' to count 
the CFS inodes in inode cache. The condition is relaxed for converting a 
cluster inode to a local inode when the number of in-core CFS inodes is greater 
than the 'vx_clreuse_threshold' threshold and reconfiguration is not in 
progress.

* 2732177 (Tracking ID: 2612741)

SYMPTOM:
Need for a tunable to disable delicache feature for the work loads where
its not needed

DESCRIPTION:
There is need to enable and disable the delicache feature as needed.

RESOLUTION:
Filesystem specific tunable 'delicache_enable' is added to enable/disable
delicache feature.

* 2733704 (Tracking ID: 2421901)

SYMPTOM:
Internal stress test on locally mounted VxFS file system resulted in the 
following assert:
 f:vx_getinoquota:1a

DESCRIPTION:
While reusing the inode from inactive inode list, the inode field that contains 
quota information is expected to be NULL. While moving the inode from delicache 
list to inactive inode list, quota information field is not set to NULL.  This 
results in the 
assert.

RESOLUTION:
The code is modified to reset the quota information field of inode while moving 
it from delicache list to inactive inode list.

* 2773761 (Tracking ID: 2693010)

SYMPTOM:
The formatted uncompressed files created by the catman(1M) command for Veritas 
File System (VxFS) man pages remain available even after the removal of the 
VxFS package.

DESCRIPTION:
Currently, the formatted compressed files created by the catman(1M) command for 
VxFS man pages are not removed during the removal/uninstall of patches.

RESOLUTION:
The code is modified in the postremove and preinstall/postinstall packaging 
scripts to cleanup any remaining formatted uncompressed files created by the 
catman(1M) command.

Patch ID: PHKL_42732, PHCO_42731, PHCO_42851

* 1935628 (Tracking ID: 1807536)

SYMPTOM:
The VX_FREEZE_ALL ioctl failed with EBUSY for CFS file systems.

DESCRIPTION:
The VX_FREEZE_ALL ioctl has been designed for local mounts only. When we start 
the timeout for some file systems before all of them are frozen, it will not be 
right.
We should freeze each file system individually, then call timeout individually.

RESOLUTION:
Enhance VX_FREEZE_ALL ioctl to work with CFS file systems. Each file system is 
individually frozen and then the timeout is called individually.

* 1935630 (Tracking ID: 1844833)

SYMPTOM:
The fsadm shrink fs command was looping on a file with ZFOD extents.

DESCRIPTION:
The fsadm shrink fs was looping in vx_reorg_emap() due to
VX_EBMAPMAX error from vx_reorg_enter_zfod().

RESOLUTION:
Updated the check before commit inside the while loop in vx_reorg_emap()
to commit sooner in order to avoid getting VX_EBMAPMAX.  Corrected the
incrementing of extent count in vx_reorg_enter_zfod().

* 1946127 (Tracking ID: 1808445)

SYMPTOM:
On CFS freeing memory while holding spinlock triggers internal debug assert 
f:xted_free:1a.

DESCRIPTION:
On CFS in recovery code path currently we are holding the spinlock and freeing the 
memory.
This triggers internal debug assert f:xted_free:1a.

RESOLUTION:
Changed the code to release the spinlock then free memory and again hold the 
spinlock to fix this problem.

* 2007748 (Tracking ID: 1978020)

SYMPTOM:
Command fsadm(1M) with '-R' may return EFAULT wrongly.

DESCRIPTION:
While getting free extent from filesystem, if size required is less than 8 times
file block size, buffer size required to store extent is calculated as zero. This
results in EFAULT.

RESOLUTION:
Code is modified to calculate buffer size after taking into account that range can
be less than 8 times file block size.

* 2007750 (Tracking ID: 1972205)

SYMPTOM:
Full filesystem check with command fsck(1M) is very slow on VxFS filesystem with
ilist file containing many holes.

DESCRIPTION:
During full filesystem check, holes in ilist files are searched linearly. As
number of holes in ilist file increases, time required to search holes also
increases.

RESOLUTION:
Code is changed to convert the list of ilist holes into a sorted array so that
binary search can be used.

* 2026535 (Tracking ID: 1544221)

SYMPTOM:
Reduced NFS Performance and excessive CPU Utilization by VERITAS Threads
(specially vxglm) when continuously accessing a Cluster shared File System from
a large number of NFS clients with a READ ONLY workload

DESCRIPTION:
NFS, in order to maintain the consistency of its client cache,
makes frequent getattr calls to the NFS server which in turn translates into
FS's getattr calls. The getattr code path in VxFS had a flaw wherein, even
during times when the workload is READ ONLY, in order to validate the size of
the file, the attribute locks are taken in UPDATE mode forcing unnecessary GLM
communication

RESOLUTION:
Provided a fix that takes attribute locks in SHARED mode whenever 
possible, thereby eliminating unnecessary GLM workload and network communication!

* 2026592 (Tracking ID: 1999493)

SYMPTOM:
On a CFS mounted Filesystem, file data read in via the filesystem 
cache ( through use of a non directIO read ) differs from that actually on 
disk. This may be seen via a directIO read or from looking at the raw disk. If 
Oracle write/read verify is turned on then ORA-600 errors might be seen like :-
ORA-00600: internal error code, arguments: [kcbbvr_verify_writes], [], [], [], 
[], [], [], []

DESCRIPTION:
The problem is encountered on a CFS mounted Filesystem when a 
DirectIO write operation is being issued to the same blocks that a buffered 
read operation is reading. The buffered read initiates read ahead of the blocks 
being writted by the DirectIO write. There is a race condition in these 
codepaths which allows the read to read in the "old" data and create valid 
pages for this data before the write hits the disk but after the DirectIO write 
has invalidated the pages for this range of blocks. This leaves the new data on 
disk and the old data as valid in the cache.

RESOLUTION:
The solution is therefore to make sure that all relevant pages are 
invalidated after the DirectIO write completes.

* 2038412 (Tracking ID: 1005244)

SYMPTOM:
The system panics during a fast pre-allocation for DB2 with 
Veritas File System (VxFS).

DESCRIPTION:
In a fast pre-allocation for DB2, VxFS returns the "ENOSPC" 
error, even though memory is available in the pre-allocated 
area. This occurs because VxFS cannot split the Zero-Filled 
on Demand  (ZFOD) extents into DATA  and new ZFOD extents.

RESOLUTION:
The code is changed to split the ZFOD extents into DATA and 
new ZFOD extents without returning "ENOSPC".

* 2114161 (Tracking ID: 2091103)

SYMPTOM:
CFS hangs with thread appears to be looping while allocating the space for file.

DESCRIPTION:
Currently in function vx_searchau() if VX_ERETRY error is received, it keeps on
retrying indefinitely, resulting in hang.

RESOLUTION:
Code is changed to limit number of retries to 3.

* 2194613 (Tracking ID: 2178147)

SYMPTOM:
Customer uses zenoss application which uses link operations on socket
files which reside on vxfs file systems. Customer is concerned as there
application cannot run on vxfs due to  vxfs errors and vxfs fsck flag being set.

DESCRIPTION:
Linking a IFSOC file does not call vx_dotdot_op which results in a 
corrupted inode.  Dtrace shows that we fail to correctly set up the inode in 
vx_link_tran thus a subsequent unlink or file remove will result in a vxfs  
message and full fsck flag set on the file system.

RESOLUTION:
Call vx_dotdot_op() for link of IFSOC files, A fix from e467214 that
was mistakenly backed out by the i154092 mts merge.

* 2242594 (Tracking ID: 1591301)

SYMPTOM:
CFS got vx_mapbad - vx_smap_stateupd message.

DESCRIPTION:
When punching holes in ALLOCATED AU, the punched out extents are moved to the
reorg inodes, and these punched out extents will be free when these reorg
inodes are processed via inactive processing.
It just happens that a write into a hole in this AU, before the punched out
extents getting free; the write somehow allocates an extent in this AU filling
in the a portion of the hole and leads to smap marked bad, vx_mapbad -
vx_smap_stateupd message from vx_dirty_eausum().

RESOLUTION:
Updated punch hole code to expand affected allocated AUs.

* 2301469 (Tracking ID: 1240665)

SYMPTOM:
Internal conformance test for fsapadm(1M) command hit an debug assert
"f:xted_validate_ip:69".

DESCRIPTION:
The assert was hit because the inode did not have shared locks setup but the
fileset is part of a clone chain. This issue occurred due to forced refresh of the
clone chain and the shared locks before the debug assert.

RESOLUTION:
Code changed to do forced refresh of the clone chain and the shared locks after
the debug assert.

* 2376391 (Tracking ID: 2376382)

SYMPTOM:
vxrestore man page does not specify that vxrestore will fail if -b option is 
used while taking dump and block size used is greater than default max i.e. 63
at the same time -b option is not used while restoring from dump.

DESCRIPTION:
If vxdump is used to take the dump and -b option is used with block size greater
than default max i.e. 63 then vxrestore fails to restore this dump if used
without -b options. This is because vxrestore attempts to dynamically determine
the tape block size , up to default maximum of 63.
This is not mentioned in the man page of vxrestore man page.

RESOLUTION:
Added
"vxrestore will attempt to dynamically determine the tape block size , upto the
default maximum of 63.So, if -b option is used when creating a dump, but not
used when restoring the dump, the restore will fail when the tape block size is
specified to be greater than 63."
 to -b option of vxrestore man page.

* 2429349 (Tracking ID: 2374887)

SYMPTOM:
Access to a file system can hang when creating a named attribute 
due to a read/write lock being held exclusively and indefinitely 
causing a thread to loop in vx_tran_nattr_dircreate() 

A typical stacktrace of a looping thread:

vx_itryhold_locked
vx_iget
vx_attr_iget
vx_attr_kgeti
vx_attr_getnonimmed
vx_acl_inherit
vx_aclop_creat
vx_attr_creatop
vx_new_attr
vx_attr_inheritbuf
vx_attr_inherit
vx_tran_nattr_dircreate
vx_nattr_copen
vx_nattr_open
vx_setea
vx_linux_setxattr
vfs_setxattr
link_path_walk
sys_setxattr
system_call

DESCRIPTION:
The initial creation of a named attribute for a regular file 
or directory will result in the automatic creation of a 
'named attribute directory'. Creations are initially attempted 
in a single transaction. Should the single transaction fail 
due to a read/write lock being held then a retry should split
the task into multiple transactions. An incorrect reset of a 
tracking structure meant that all retries were performed using 
a single transaction creating an endless retry loop.

RESOLUTION:
The tracking structure is no longer reset within the retry loop.

* 2478023 (Tracking ID: 2384831)

SYMPTOM:
System panics with the following stack trace. This happens in some cases when 
names streams are used in VxFS.

machine_kexec()
crash_kexec()
__die
do_page_fault()
error_exit()
[exception RIP: iput+75]
vx_softcnt_flush()
vx_ireuse_clean()
vx_ilist_chunkclean()
vx_inode_free_list()
vx_ifree_scan_list()
vx_workitem_process()
vx_worklist_process()
vx_worklist_thread()
vx_kthread_init()
kernel_thread()

DESCRIPTION:
VxFS internally creates a directory to keep the named streams pertaining to a 
file. In some scenarios, an error code path is missing to release the hold on 
that directory. Due to this unmount of the file system will not clean the inode 
belonging to that directory. Later when VxFS reuses such a inode panic is seen.

RESOLUTION:
Release the hold on the named streams directory in case of an error.

* 2478033 (Tracking ID: 2413172)

SYMPTOM:
vxfs_fcl_seektime() API seeks to the first record in the File change log(FCL)
file after specified time. This API can incorrectly return EINVAL(FCL record not
found)error while reading first block of FCL file.

DESCRIPTION:
To seek to the first record after the given time, first a binary search is 
performed to get the largest block offset where fcl record time is less than the
given time. Then a linear search from this offset is performed to find the first
record which has time value greater than specified time. 

FCL records are read in buffers. There can be scenarios where FCL records read
in one buffer are less than buffer size, e.g. reading first block of FCL file.
In such scenarios, buffer read can continue even when all data in current buffer
has been read. This is due to wrong check which decides if all records in one
buffer has been read.
Thus reading buffer beyond boundary was causing search to terminate without
finding record for given time and hence EINVAL error was returned.

Actually, VxFS should detect that it is partially filled buffer and the search
should continue reading the next buffer.

RESOLUTION:
Check which decides if all records in buffer have been read is corrected such
that buffer is read within its boundaries.

* 2521467 (Tracking ID: 2439242)

SYMPTOM:
Shrinking file system using vxresize(1M) or fsadm(1M) fails when structural file 
is present in the shrink area.

DESCRIPTION:
While shrinking file system , reorg inode is always allocated as IORG_TYPED.
So if original inode is not IORG_TYPED it is converted to IORG_TYPED.
After such conversion file size gets updated and vxresize code path treats this 
change in
file size as an error and fails to shrink the file system.

RESOLUTION:
Changed the code to match the file size in the request with the actual file size.

* 2521491 (Tracking ID: 2481984)

SYMPTOM:
Access to the file system got hang.

DESCRIPTION:
In function 'vx_setqrec', it will call 'vx_dqget'. when 'vx_dqget' return
errors, it will try to unlock DQ structure using 'VX_DQ_CLUSTER_UNLOCK'. But, in
this situation, DQ structure doesn't hold the lock. hence, this hang happens.

RESOLUTION:
'dq_inval' would be set in 'vx_dqget' in case of any error happens in
'vx_dqget'. Skip unlocking DQ structure in the error code path of 'vx_setqrec',
if 'dq_inval' is set.

* 2551558 (Tracking ID: 2428964)

SYMPTOM:
Value of kernel tunable max_thread_proc gets incremented by 1 after every software
maintenance related activity (install, remove etc.) of VRTSvxfs package.

DESCRIPTION:
In the postinstall script for VRTSvxfs package, value of kernel tunable
max_thread_proc is wrongly increment by 1.

RESOLUTION:
From postinstall script increment operation of max_thread_proc tunable is removed.

* 2567067 (Tracking ID: 2566875)

SYMPTOM:
A write(2) exceeding a quota limit fails with EDQUOT error(i.e. "Disc quota
exceeded") before user quota limit is reached. Therefore write upto length below
quota limit is not performed. Partial write of length within quota limit should
be performed instead of just returning EDQUOT error.

DESCRIPTION:
When a write request exceeds a quota limit, the error EDQUOT should be handled
so that vxfs can manage to allocate space up to the hard quota limit to proceed
with a partial write. However, vxfs doesn't handle this error and error is
returned without performing partial write.

RESOLUTION:
EDQUOT error from extent allocation routine is now handled to retry write of
length within quota limit.

* 2579766 (Tracking ID: 2492304)

SYMPTOM:
"find" command displays duplicate directory entries.

DESCRIPTION:
Whenever the directory entries can fit in the inode's immediate area VxFS
doesn't allocate new directory blocks. As new directory entries get added to the 
directory this immediate area gets filled and  all the directory entries are
then moved to a newly allocated directory block. 

The directory blocks have space reserved at the start of the block to hold the 
block hash information which is used for fast lookup of entries in that block. 

Offset of the directory entry, which was at say x bytes in the inode's immediate
area, when moved to the directory block, will be at (x + y) bytes. "y" is the
size of the block hash. 

During this transition phase from immediate area to directory blocks, a
readdir() can report a directory entry more than once.

RESOLUTION:
Directory entry offsets returned to the "readdir" call are adjusted so that when 
the entries move to a new block, they will be at the same offsets.

* 2587029 (Tracking ID: 2561739)

SYMPTOM:
When the file is created and the if the parent has default ACL entry then that
entry is not taken into account for calculating the class entry of that file. When
a separate dummy entry added we take into account the default entry from parent as
well.
e.g.
$ getacl .
# file: .
# owner: root
# group: sys
user::rwx
group::rwx
class:rwx
other:rwx
default:user:user_one:r-x

$ touch file1
$ getacl file1
# file: try1
# owner: root
# group: sys
user::rw-
user:user_one:r-x
group::rw-
class:rw- <------
other:rw-

The class entry here should be rwx.

DESCRIPTION:
We were not taking into account the default entry of parent. We share the
attribute inode with parent and do not create new attribute inode for newly
created file. But when an ACL entry is explicitly made we create the separate
attribute inode so the default entry also get copied in new inode and taken into
consideration while returning the class entry of file.

RESOLUTION:
Now before returning the ACL entry buffer we calculate the class entry again and
consider all the entries.

* 2612752 (Tracking ID: 2612741)

SYMPTOM:
Need for a tunable to disable delicache feature for the work loads where
its not needed

DESCRIPTION:
There is need to enable and disable the delicache feature as needed.

RESOLUTION:
Filesystem specific tunable 'delicache_enable' is added to enable/disable
delicache feature.

* 2660217 (Tracking ID: 2253617)

SYMPTOM:
Fullfsck fails to run cleanly using "fsck -n".

DESCRIPTION:
In case of duplicate file name entries in one directory, fsck 
compares the directory entry with the previous entries. If the filename
already exists further action is taken according to the user input [Yes/No]. As 
we are using strncmp, it will compare first n characters, if it matches it will 
return success and will consider it as a duplicate file name entry and fails to 
run cleanly using "fsck -n"

RESOLUTION:
Checking the filename size and changing the length in strncmp to 
name_len + 1 solves the issue.

* 2682142 (Tracking ID: 2588593)

SYMPTOM:
df(1M) shows wrong usage value for volume when large file is deleted.

DESCRIPTION:
We maintain all freed extent size in the in core global variable and transaction 
subroutine specific data structures.
After deletion of a large file, we were missing to update this in core global 
variable. df(1M) while reporting
usage data, read the freed space information from this global variable which 
contains stale information.

RESOLUTION:
Code is modified to account the freed extent data into global vaiable used by 
df(1M) so that correct usage for volume is
reported by df(1M).

* 2683635 (Tracking ID: 2670022)

SYMPTOM:
Duplicate file names can be seen in a directory.

DESCRIPTION:
VxFS maintains internal directory name lookup cache (DNLC) to improve the 
performance of directory lookups. A race condition is arising in DNLC lists 
manipulation code during lookup/creation of file names having >32 characters ( 
which will further affect other file creations). This is causing DNLC to have a 
stale entry for an existing file in the directory. A lookup of such a file 
through DNLC will say file as non-existent which will allow another duplicate 
file name in the directory.

RESOLUTION:
Fixed the race condition by protecting the DNLC lists through proper locks.


INSTALLING THE PATCH
--------------------
To install the VxFS 5.0.1-11.31 patch:

a) To install this patch on a CVM cluster, install it one
 system at a time so that all the nodes are not brought down
 simultaneously.

b) The VxFS 11.31 pkg with revision 5.0.31.5 must be installed before applying the patch.

c) To verify the VERITAS file system level, execute:

     # swlist -l product | egrep -i 'VRTSvxfs'

  VRTSvxfs     5.0.31.5        VERITAS File System

Note: VRTSfsman is a corequisite for VRTSvxfs. So, VRTSfsman also
needs to be installed with VRTSvxfs.

    # swlist -l product | egrep -i 'VRTS'

  VRTSvxfs      5.0.31.5      Veritas File System
  VRTSfsman     5.0.31.5      Veritas File System Manuals

d)All prerequisite/corequisite patches have to be installed.The Kernel patch
  requires a system reboot for both installation and removal.

e) To install the patch, execute the following command:

# swinstall -x autoreboot=true -s <patch_directory>    PHKL_42892 PHCO_42893 PHCO_42894

If the patch is not registered, you can register it
using the following command:

# swreg -l depot <patch_directory>  

The <patch_directory>    is the absolute path where the patch resides.


REMOVING THE PATCH
------------------
To remove the VxFS 5.0.1-11.31 patch:

a) Execute the following command:

# swremove -x autoreboot=true PHKL_42892 PHCO_42893 PHCO_42894


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


OTHERS
------
NONE