* * * READ ME * * * * * * Veritas File System 5.0.1 RP3 * * * * * * P-patch 4 * * * Patch Date: 2012-03-09 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 4 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: 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 -------------------- o 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 PHKL_42732 PHCO_42731 PHCO_42851 If the patch is not registered, you can register it using the following command: # swreg -l depot The 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_42732 PHCO_42731 PHCO_42851 SPECIAL INSTRUCTIONS -------------------- NONE OTHERS ------ NONE