Patch-ID# 119300-01 NOTE: *********************************************************************** READ THE TERMS OF THE AGREEMENT ("AGREEMENT") IN THE LEGAL_LICENSE.TXT FILE CAREFULLY BEFORE USING THIS SOFTWARE. BY USING THE SOFTWARE, YOU AGREE TO THE TERMS OF THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE TERMS, PROMPTLY DESTROY THE UNUSED SOFTWARE. *********************************************************************** Keywords: vxfs 4.1 veritas file system rp 01 Synopsis: VERITAS File System 4.1: Rolling Patch 01 for File System 4.1 Date: Aug/09/2005 Install Requirements: Reboot after installation Solaris Release: 8 SunOS Release: 5.8 Unbundled Product: Veritas VxFS Unbundled Release: 4.1 Xref: Topic: VxFS 4.1 RP1 Multiple Fixes Patch Relevant Architectures: sparc BugId's fixed with this patch: 4942492 4988337 6223830 6227073 Changes incorporated in this version: 4942492 4988337 6223830 6227073 Patches accumulated and obsoleted by this patch: Patches which conflict with this patch: Patches required with this patch: Obsoleted by: Files included with this patch: $ROOT_2.8/kernel/fs/sparcv9/vxfs $ROOT_2.8/kernel/fs/vxfs $ROOT_2.8/opt/VRTSvxfs/sbin/vxfsckd $ROOT_2.8/usr/lib/fs/vxfs/sparcv7/fsck $ROOT_2.8/usr/lib/fs/vxfs/sparcv7/fsck_logv10 $ROOT_2.8/usr/lib/fs/vxfs/sparcv7/fsck_logv9 $ROOT_2.8/usr/lib/fs/vxfs/sparcv9/fsck $ROOT_2.8/usr/lib/fs/vxfs/sparcv9/fsck_logv10 Problem Description: -------------------- (152379) inconsistent CFS permissions (152830) vxfsckd sleeping 5secs for an avail replay thread could be improved 4942492 (147918) workaround possible panic caused by NFS and force umount 4988337 (147918) workaround possible panic caused by NFS and force umount (152189) HP : VxFS 3.5/HP 11.23 panic:unresolved kernel interruption 6223830 (152278) cookie based DNLC: more than 8 bits of cookie required for cpuid (153375) bmap routines for IORG_NONE inodes should return an error (153719) Log Version mismatch issue with BCV backup (153765) license check in fsck 6227073 (153702) gets ENOSPC from vx_te_bmap_enter Patch Installation Instructions: -------------------------------- For the Solaris 8 release, refer to the online manual pages for instructions on using 'patchadd' and 'patchrm' scripts provided with Solaris. Any other special or non-generic installation instructions should be described below as special instructions. The following example installs a patch to a standalone machine: example# patchadd /var/spool/patch/110434-07 The following example removes a patch from a standalone system: example# patchrm 104945-02 For additional examples please see the appropriate manual pages. Special Install Instructions: ----------------------------- You need to use the shutdown command to reboot the system after patch installation or de-installation: shutdown -g0 -y -i6 Additional Notes: ----------------- 1) VERITAS Incident 152379 (Support ID 240-090-418 280-351-481) Intermittently, file permissions were seen with all zeroes from a Secondary node. This problem has been corrected. 2) VERITAS Incident 152830 (Support ID 210-022-128) When there are many CFS file systems to failover and the failover time is critical for the customer environment and applications, the vxfsckd daemon sleeping 5 seconds for an available replay thread is wasteful. The sleeping time can be reduced to 1/4 second via usleep(250000). 3) VERITAS Incident 147918 (Sun BUG IDs 4942492,4988337, Support ID 230-006-731) There is a potential race condition with NFS clients caused by nfs3_fhtovp and a force unmount. Such a race can result in a panic in vx_do_vget, as the VFS pointer has been freed by the force unmount. The fix is to ensure that as long as there are potential NFS clients still active (that is, they have a share on the file system), then the VFS is not freed. 4) VERITAS Incident 152189 (Support ID 210-021-782) The problem is that the ml_flag in the mlinks structure is not being protected in some VxFS code paths [eg: vx_map_delaydone() and vx_map_delayflush() routines]. If multiple vxfs threads try to modify the value of ml_flag at the same time, the value of ml_flag may be not correctly modified. This is a race condition in VxFS. The solution to this problem is to always aquire the fsq_lock() to atomically modifying the ml_flag field. 5) VERITAS Incident 152278 (Sun BUG ID 6223830, Support ID 280-336-483 230-049-767 240-093-737) The DNLC cookie changed from 96-bit to 128-bit to allow 16 bits rather than 8 bits for the CPUID. Using SPARC IV CPUs, the two processors within each unit are allocated cpuid numbers that differ by 0x200. Also, F15Ks allocate cpuid numbers depending on the hardware slot. cpuid numbers 160 and 416 are possible. Duplicate cookies are possible if the low order byte of the cpuid numbers clash. All the ramifications have not been determined, but it is possible that all three support cases above may have had this issue as their root cause. Any patch delivering this fix cannot co-exist in a Veritas cluster where some nodes do and other nodes do not have it installed. Therefore, installing this patch requires the whole Veritas CFS cluster to be brought down. You cannot perform a rolling upgrade. 6) VERITAS Incident 153375 (Support ID 210-027-259) VxFS was looping in vx_flush_pages() trying to flush a file that has already been removed and lost its identity. 7) VERITAS Incidents 153719,153765 (Support IDs 280-386-769,230-068-156) The fsck command has been enhanced to use the bundled 3.5 fsck binary in replaying 3.5 file systems, and 4.0 fsck binary for 4.0 file systems. VxFS has also been updated to allow read-write mount of dusty 3.5 and 4.0 file systems. 8) VERITAS Incident 153702 (Sun BUG ID 6227073, Support ID 210-023-774) When the filesystem is full, truncation of file operations could fail due to ENOSPC conditions, leading to the file being marked bad and filesystem setup for fullfsck. This has been fixed by making the truncations happen without requiring any additional space. README -- Last modified date: Tuesday, August 9, 2005