README VERSION : 1.1 README CREATION DATE : 2013-08-20 PATCH-ID : 143275-09 PATCH NAME : VRTScavf 5.1SP1RP4 BASE PACKAGE NAME : VRTScavf BASE PACKAGE VERSION : 5.1.000.000 SUPERSEDED PATCHES : 143275-08 REQUIRED PATCHES : 5.1.100.000 INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : sol10_x64 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : OTHER PATCH CRITICALITY : RECOMMENDED HAS KERNEL COMPONENT : NO ID : NONE REBOOT REQUIRED : NO REQUIRE APPLICATION DOWNTIME : Yes PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to Release Notes for install instructions PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to Release Notes for uninstall instructions SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- PATCH ID:143275-09 2930184 (2720034) The vxfsckd(1M) daemon does not restart after being killed manually. PATCH ID:143275-08 2694495 (2669724) CFSMountAgent core dump due to assertion failure in VCSAgThreadTbl::add() 2788309 (2684573) enhancement request for force option of cfsumount command 2824916 (2824895) vcscvmqa "cfsumount" test getting fail. PATCH ID:143275-07 2406572 (2146573) SUMMARY OF KNOWN ISSUES: ----------------------------------------- NONE KNOWN ISSUES : -------------- NONE FIXED INCIDENTS: ---------------- PATCH ID:143275-09 * INCIDENT NO:2930184 TRACKING ID:2720034 SYMPTOM: The vxfsckd(1M) daemon does not restart after being killed manually. DESCRIPTION: When the vxfsck process is killed manually, all the processes may not be killed and there might be some process still running. Starting of the new vxfscd fails since the cleanup of these processes is not done correctly. RESOLUTION: The script is modified to clean-up/kill existing vxfsckd daemons correctly before re-starting them. PATCH ID:143275-08 * INCIDENT NO:2694495 TRACKING ID:2669724 SYMPTOM: CFSMount agent hit assert on monitor timeout with stack similar to the following: VCSAssert() VCSAgThreadTbl::add() VCSAgRes::call_entry_point() VCSAgIntState::process_res_fault() VCSAgISMonitoring::timedout() VCSAgRes::process_cmd() vcsag_service_thread_join() start_thread() Also following messages will apear in the engine log: Thread(4149205920) Agent is calling clean for resource(cfsmount12) because 1 successive invocations of the monitor procedure did not complete within the expected time. 2010 Jul 23 21:30:09 swsfs2_01 AgentFramework[3942]: ASSERTION FAILED DESCRIPTION: The pthread cancellation is not processed cleanly by the library glibc routines used in monitor entry point. Due to this the cancellation cleanup handler was not getting called. RESOLUTION:Replaced the glibc function with the unix system call to avoid it, e.g fopen() replaced with open and fgets() replaced with read(). * INCIDENT NO:2788309 TRACKING ID:2684573 SYMPTOM: The performance of the cfsumount(1M) command for the VRTScavf package is slow when some checkpoints are deleted. DESCRIPTION: When a checkpoint is removed asynchronously, a kernel thread is started to handle the job in the background. If an unmount command is issued before these checkpoint removal jobs are completed, the command waits for the completion of these jobs. A forced unmount can interrupt the process of checkpoint deletion and the remaining work is left to the next mount. RESOLUTION:The code is modified to add a counter in the vxfsstat(1M) command to determine the number of checkpoint removal threads in the kernel. The '-c' option is added to the cfsumount(1M) command to force unmount a mounted file system if the checkpoint jobs are running. * INCIDENT NO:2824916 TRACKING ID:2824895 SYMPTOM: vcscvm test cfsumount was failing while umount of a storage checkpoint instance through cfsumount. DESCRIPTION: While umount through cfsumount when storage checkpoint instance on one of the node of cluster is mounted, the cfsumount didn't succeeded on nodes where parent is not ONLINE. RESOLUTION:Update proper checks in check_offline function to make sure in failed umount case and return correct umount exit code. PATCH ID:143275-07 * INCIDENT NO:2406572 TRACKING ID:2146573 SYMPTOM:Customer reported this as performance issue. The application was running slower when this problem happens. The SAR utility on HP-UX was showing some processes in PRI state. DESCRIPTION:(1) Complexity: This is an extremely complex performance concern in an environment where different applications are in great competition for the same system-wide resources. (2) Performance overheads: Competition for system resources is expected. However intense competition can create large overheads due to increased repetitive initialization. We approached this issue in multiple ways. Provided customer some tuning and application changes. RESOLUTION:No product bug was identified from Symantec side. However a GLM patch was provided to customer which does two things. 1. Different names given to different GLM spin locks. So that we can identify various locks from spin watcher output. 2. We take avoiding a spinlock which keeps accounting if how many times allocation did in GLM. Removing this lock will not cause any regression. Also, we have not said that it will solve this performance problem. INCIDENTS FROM OLD PATCHES: --------------------------- NONE