Patch Name: PHKL_21594 Patch Description: s700 10.20 VxFS (JFS) mount, fsck cumulative patch Creation Date: 00/04/27 Post Date: 00/05/05 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: No (superseded patches were critical) PHKL_18197: CORRUPTION PHKL_17716: PANIC PHKL_12339: HANG PHKL_12007: CORRUPTION Path Name: /hp-ux_patches/s700/10.X/PHKL_21594 Symptoms: PHKL_21594: (SR: 8606135341 CR: JAGad04475) Inactive inodes are not getting cleared after 110 days. (SR: 8606104878 CR: JAGab72639) System performance is unacceptable (slows down) due to ibmaplock contention even when inode is in memory. PHKL_19539: ( SR: 1653302711 DTS: JAGab15428 ) A VxFS file system cannot be mounted if it has more than 8 million inodes. PHKL_18197: ( SR: 1653297531 DTS: ) On vxfs filesystems where a particular type of inode corruption occurs, all future mounts of that filesystem fail. In the message buf will be the message: vx_iget - [fs name] file system invalid inode number [#] This message will possibly be repeated many times. Future attempts to mount this file system will fail with either: vxfs mount: [device] is not a vxfs file system or vxfs mount: [device] is corrupted. needs checking At that point, if an fsck is performed the file system can be mounted, but further use of the file system may cause the vx_iget message to occur again, and the file system to again be unmountable. PHKL_17716: ( SR: 4701411298 DTS: JAGaa45918 ) A panic may occur in vx_spinlock() when trying to mount a corrupt VxFS file system. This patch provides a fix so that a failure is reported in this case, but a panic will not occur. PHKL_12339: ( SR: 5003383307 DTS: JAGaa00693 ) Mounting a VxFS Version 2 filesystem containing a large amount of files (in excess of 800,000) can take several minutes to complete. During the time it takes to mount the filesystem the system appears to be hung. This patch provides improved kernel routines which eliminate this performance problem. PHKL_12007: ( SR: 4701361758 DTS: DSDe438092 ) 10.20 fsck on vxfs (version 3) filesystem fails with the following error: # fsck -o full -y /dev/vg01/lvol3 pass0 - checking structural files pass1 - checking inode sanity and blocks pass2 - checking directory linkage pass3 - checking reference counts pass4 - checking resource maps small extent in iau inode This occured after a normal shutdown. The filesystem is unusable and must be newfs'd. This patch provides the kernel half of a solution for an fsck defect. The commands patch PHCO_11908 must also be applied to install the full solution. Without PHCO_11908 installed, this patch will have no impact. Defect Description: PHKL_21594: (SR: 8606135341 CR: JAGad04475) Prior to 110 days inactive inodes are removed early from the inode cache. After 110 days inactive inodes are never removed from the inode cache. The JFS inode cache or inode table is dynamic it keeps expanding and contracting, but after the system is up for over 110 days the cache does not reduce in size, it grows to the max and stays the same after that. Customer monitored the inode size using: # sar -v 1 1 16:29:09 text-sz ov proc-sz ov inod-sz ov file-sz ov 16:29:10 N/A N/A 272/1620 0 3500/3500 0 1137/6010 0 Resolution: The variable (i_ftime) which is assigned the time inode is put on free list is incorrectly set to lbolt, it should be set to vx_lbolt (system time) in the function vx_inactive() which inactivates an inode. (SR: 8606104878 CR: JAGab72639) The vx_iget() function grabs ibmaplocks exclusively every time it is called, even when the inode is in memory. This is slowing down the system. Resolution: Changes vx_iget() function to obtain ibmaplock, only if inode is not in memory. PHKL_19539: ( SR: 1653302711 DTS: JAGab15428 ) To reproduce the problem, create a VxFS file system with more than 8 million files. The file system cannot be mounted without this patch. Resolution: The problem occurs because a 32 bit integer overflows when the number of inodes reaches 8 million. The variable has been changed to a 64 bit integer. PHKL_18197: ( SR: 1653297531 DTS: ) The vxfs kernel was not properly handling sparse IFILT files. This was due to fsh_ninode being incorrectly set in this case, as well as the end of the IFILT list being calculated incorrectly. Resolution: vx_fsetialloc() was updated to properly update fsh_ninode in the case of a sparse IFILT file. vx_olt_ilistadd() was updated to properly find the end of the IFILT list in this case. This prevents a corrupt filesystem from getting worse, and will not fix the inital cause of the corruption. PHKL_17716: ( SR: 4701411298 DTS: JAGaa45918 ) SR: 4701411298 DTS: JAGaa45918 The problem can be reproduced by using fsdb to corrupt inode 2 (the root inode) of the file system. Resolution: The problem has been corrected so that the mount will fail instead of causing a panic if the file system is corrupted in this manner since a corrupted file system should not be mounted. PHKL_12339: ( SR: 5003383307 DTS: JAGaa00693 ) Mounting a version 2 VxFS filesystem containing many (>800K) files takes several minutes. PHKL_12007: ( SR: 4701361758 DTS: DSDe438092 ) This is the kernel part of the solution to that fsck problem that PHCO_11908 addresses. It involves a VxFS filesystem. SR: 1653297531 1653302711 4701361758 4701411298 5003383307 8606135341 8606104878 Patch Files: /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_oltmount.o) what(1) Output: /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o): vx_fsetsubr.c $Date: 99/04/09 10:15:28 $ $Revision: 1.2.98.15 $ PATCH_10.20 (PHKL_18197) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 2000/04/27 11:20:53 $ $Revision: 1 .7.98.22 $ PATCH_10.20 (PHKL_21594) /usr/conf/lib/libvxfs_base.a(vx_oltmount.o): vx_oltmount.c $Date: 99/08/20 07:01:32 $ $Revision: 1.6.98.17 $ PATCH_10.20 (PHKL_19539) cksum(1) Output: 3172264055 21208 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) 3834113420 45048 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 3177947342 27968 /usr/conf/lib/libvxfs_base.a(vx_oltmount.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHKL_16750 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_12007 PHKL_12339 PHKL_17716 PHKL_18197 PHKL_19539 Equivalent Patches: PHKL_21595: s800: 10.20 PHKL_20079: s700: 11.00 PHKL_19942: s700: 11.00 Patch Package Size: 160 KBytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHKL_21594 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_21594.depot By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_21594. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. WARNING: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_21594.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_21594.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: The kernel patch PHKL_12007 provides the kernel half of a solution for an fsck defect. The commands patch PHCO_11908 must also be applied to achieve the full solution. Without PHCO_11908 installed, this patch will have no impact. This patch depends on base patch PHKL_16750. For successful installation, please ensure that PHKL_16750 is in the same depot with this patch, or PHKL_16750 is already installed.