README VERSION : 1.1 README CREATION DATE : 2012-03-09 PATCH-ID : PVKL_03951 PATCH NAME : VRTSvxfs 6.0RP1 BASE PACKAGE NAME : VRTSvxfs BASE PACKAGE VERSION : 6 OBSOLETE PATCHES : NONE SUPERSEDED PATCHES : NONE REQUIRED PATCHES : PVCO_03952 INCOMPATIBLE PATCHES : NONE SUPPORTED PADV : hpux1131 (P-PLATFORM , A-ARCHITECTURE , D-DISTRIBUTION , V-VERSION) PATCH CATEGORY : CORE , PANIC REBOOT REQUIRED : YES PATCH INSTALLATION INSTRUCTIONS: -------------------------------- Please refer to the Release Notes for Installation and Uninstallation Instructions. PATCH UNINSTALLATION INSTRUCTIONS: ---------------------------------- Please refer to the Release Notes for Installation and Uninstallation Instructions. SPECIAL INSTRUCTIONS: --------------------- NONE SUMMARY OF FIXED ISSUES: ----------------------------------------- 2645691 The following error message is displayed during the execution of the fsmap(1M) command:'UX:vxfs fsmap: ERROR: V-3-27313' 2645821 The fscdsconv(1M) command which is used to convert corrupted or non-VxFS file systems generates core. 2646915 The fsck(1M) command exits during an internal CFS stress reconfiguration testing. 2654504 The replication process dumps core when shared extents are present in the source file system. 2661223 'Shared' extents are not transferred as 'shared' by the replication process. 2672209 When the fsckptadm(1M) command with the '-r' and '-R' option is executed, two mutually exclusive options gets executed simultaneously. 2672212 The nlink count of PD needs to be calculated while validating directories in the fscdsadm(1M) command. 2678196 The fiostat command dumps core when the count value is 0. 2683410 Binaries linking the libvxfssnap.sl library dumps the core while reading the inodes. SUMMARY OF KNOWN ISSUES: ----------------------------------------- 2654682 Full file system check using fsck_vxfs(1m) takes over a week 2654685 on a cluster mounted filesystem ls(1m) with -l option may take longer 2627081 vxfsd is taking a lot of CPU time after deleting some directories 2627096 fsckptadm (1m) fails with ENXIO 2627101 On file-system having low free memory , commands like ls,find may seem to be hung. 2627084 umount(1m) on a CFS filesystem panics the machine. 2627089 mmap(1m) performance is lower on VXFS 5.0.1 with HPUX 11.31 2654673 A cluster mounted file-system may panic the system showing vx_tflush_map in the stack trace. 2684732 fsppadm(1m) dumps core with SIGSEGV while assigning a policy. KNOWN ISSUES : -------------- * INCIDENT NO::2654682 TRACKING ID ::2628207 SYMPTOM:: One large file-system with many checkpoints the fsck operation may seem to be hung WORKAROUND:: None * INCIDENT NO::2654685 TRACKING ID ::2651922 SYMPTOM:: on a cluster mounted filesystem ls(1m) with -l option may take longer WORKAROUND:: None * INCIDENT NO::2627081 TRACKING ID ::2129455 SYMPTOM:: vxfsd is taking a lot of CPU time after deleting some directories WORKAROUND:: None. * INCIDENT NO::2627096 TRACKING ID ::1956458 SYMPTOM:: fsckptadm (1m) fails with ENXIO and filesytem is marked for full fsck WORKAROUND:: None. * INCIDENT NO::2627101 TRACKING ID ::2359706 SYMPTOM:: On file-system having low free memory , commands like ls,find may seem to be hung. WORKAROUND:: None * INCIDENT NO::2627084 TRACKING ID ::2107152 SYMPTOM:: In rare corner cases, system panics while unmounting a cluster mounted filesystem WORKAROUND:: None * INCIDENT NO::2627089 TRACKING ID ::2183320 SYMPTOM:: mmap(1m) performance is lower on VXFS 5.0.1 with HPUX 11.31 WORKAROUND:: None * INCIDENT NO::2654673 TRACKING ID ::2558892 SYMPTOM:: VxFS causes a server to panic. The subroutine initiating the panic is vx_tflush_map. WORKAROUND:: None * INCIDENT NO::2684732 TRACKING ID ::2715414 SYMPTOM:: fsppadm(1m) dumps core with SIGSEGV while assigning a policy. WORKAROUND:: Increase the pthread stack size using the following command export PTHREAD_DEFAULT_STACK_SIZE=2048000 FIXED INCIDENTS: ---------------- PATCH ID:PVKL_03951 * INCIDENT NO:2645691 TRACKING ID:2645435 SYMPTOM: The fsmap command gives error 'UX:vxfs fsmap: ERROR: V-3-27313: failed to open mount point: : I/O error' DESCRIPTION: fsmap queries the mount table and makes a list of all mounted filesystems and then opens the mount points in the list. If in between, the filesystem gets unmounted then the open fails with the above error and program exits. RESOLUTION:Instead of exiting on error because of above scenario, continue by skipping the filesystem which gave error (because it got unmounted). * INCIDENT NO:2645821 TRACKING ID:2536130 SYMPTOM: Issue 1: If fscdsconv command is used to convert a) corrupted or b) non-VxFS file system, instead of exiting with prooper error message it crashes with the following message: devops.c 1693: ASSERT(0) failed DESCRIPTION: Before starting to convert a filesystem, VxFS does a sanity check on the file system. While doing sanity check, for corrupt file system the command incorrectly tries to close the file system twice. Hence on the second close the program crashes. RESOLUTION:Fix makes sure that if close is called once it is not called again. Now if fscdsconv is run on a corrupted or non VxFs file system it exits with the following error message: UX:vxfs fscdsconv: ERROR: V-3-20318: file system dirty, run fsck first UX:vxfs fscdsconv: ERROR: V-3-24426: fscdsconv: Failed to migrate. Issue 2: If partition directory feature is enabled in filesystem and trying to export the filesystem from Linux to AIX platform , mount command asserts with "f:VX_FCL_INIT_FAILED:ndebug". * INCIDENT NO:2646915 TRACKING ID:2630954 SYMPTOM: During internal CFS stress reconfiguration testing, the fsck(1M) command exits by hitting an assert. DESCRIPTION: When the dexh_getblk() function is executed, if the extent size is greater than 256 Kbytes, the extent is divided into chunks of 256 Kbytes each. When the extent of the hash inodes are read in the dexh_getblk() function, a maximum of 256 Kbytes (MAXBUFSZ) is read at a time. Currently, the chunk size is assigned as 256 Kbytes every time. But there is a bug when the last chunk in the extent is less than 256 Kbytes because of which the length of the buffer is assigned incorrectly and we get an aliased buffer in the buffer cache. Instead, for the last chunk, the remaining size in the extent to be read should be assigned as the chunk size. RESOLUTION:The code is modified so that the buffer size is calculated correctly. * INCIDENT NO:2654504 TRACKING ID:2646936 SYMPTOM: Replication process sometimes dumps core if shared extents are present in the source file system. You will see "UX:vxfs vfradmin: INFO: V-3-27703: ... 'replication process killed by signal'." when you use "vfradmin getjobstatus" command. DESCRIPTION: Replication process saves to disk information about shared extents present on the source side. This information is used to optimize data transfer as well as achieve same sharing at the destination files. When a new chunk of main memory is allocated, to save the shared extent structure, it has to be initialized to zero to avoid ambiguity. In one particular case, the replication process fails to initialize the main memory to 0, and aborts processing (dumps core) when it reads uninitialized memory. RESOLUTION:Replication process has been changed to initialize every newly allocated piece of memory in which shared extents are stored to 0. * INCIDENT NO:2661223 TRACKING ID:2655786 SYMPTOM: Replication turns off shared extent processing after transferring a large number of shared extents succesfully. In further iterations, extents that are shared at the source do not appear as shared at the destination. DESCRIPTION: There is an internal limit in the send side replication process to the size of one of buffers used to store shared extents starting from same physical block, but varying lengths. The varying length of shared extent could be due to varying length of matching sections from different files. Once this limit of shared extent entries at source side is exceeded, the replication process turns off shared extent processing in all future iterations to prevent data structure inconsistency. RESOLUTION:Replication process has been enhanced to remove the internal limit on number of varying length shared extents at source side that refer to the same starting block. * INCIDENT NO:2672209 TRACKING ID:2653845 SYMPTOM: Two mutually exclusive option (-r and -R ) with fsckptadm were getting executed simultaneously. DESCRIPTION: Option (-R) is used to create non-removable checkpoint, if the tunable ckpt_removable is set to 1 (in this case removable checkpoint is created by default). To override this -R option was introduced , which should be mutually exclusive with -r option in fsckptadm. RESOLUTION:Changed the code such that they are mutually exclusive. * INCIDENT NO:2672212 TRACKING ID:2655788 SYMPTOM: fscdsadm/fscdsconv miss to validate PD for nlink checks. DESCRIPTION: When the directory is partitioned the correct nlink count of the directory is not stored in ondisk inode field. The nlink value stored on the disk inode is the count of the hash directories. So, during a normal read (stat system call) when nlink count of a directory is requested , sum of all the nlinks of it's hash directories is returned as the nlink value of the directory. The issue occurs during the course of cds validation/conversion. During cds validation the nlink value of the directory being validated is read from the disk inode. So, if the directory has more than 32k nlinks and it is partitioned, the cds validation can miss to validate the directory as nlink count stored in it's disk inode does not represent the correct nlink value. So, in such cases the directory (with >32k nlink) does not get reported in the output of cds validation and customer may miss to set the proper tunable value for vx_malink before mounting the file system on target platform. If such file system is mounted on the target platform the directories with >32k subdirs may get marked as bad. RESOLUTION:During the course of cds validation, find a way to identify the correct nlink value of all the partitioned directories before they go through the cds validation checks for nlink. * INCIDENT NO:2678196 TRACKING ID:2678096 SYMPTOM: fiostat cordumps saying "Segmentation Fault (core dumped)" when count value is <= 0 DESCRIPTION: when count value is <= 0 we are trying to free the memory which is not allocated. Hence core dump. RESOLUTION:Free the memory only when we allocate them. * INCIDENT NO:2683410 TRACKING ID:2683409 SYMPTOM: Binaries linking the libvxfssnap.sl library dumps the core while reading the inodes. DESCRIPTION: The binaries like pgntest in fsqa suite dumps the core while tyring to read the inodes through function pdir_get_visible_parent() for partitioned directories. The core dumps with the FPE_INTDIV (integer divide by zero) error. This happens because the pdir_get_visible_parent() when called from vxfs_getdents() has the uninitialized fs_dat pointer which further gets passed to fset_iread() causing the dump. RESOLUTION:Provide the correct pointer to pdir_get_visible_parent(). INCIDENTS FROM OLD PATCHES: --------------------------- NONE