Patch Name: PHKL_12100 Patch Description: s700 10.20 VxFS (JFS) cumulative patch Creation Date: 97/08/11 Post Date: 97/08/15 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_12100: CORRUPTION Kernel portion of fix for unrepairable JFS file system where fsck produces the error message "no valid ILIST in fileset 999". PHKL_11607: PANIC PHKL_11039: CORRUPTION This patch fixes data corruption for applications that create large files which keep changing their size dynamically. PHKL_9517: CORRUPTION Path Name: /hp-ux_patches/s700/10.X/PHKL_12100 Symptoms: PHKL_12100: kernel part of the fix for the slow fsck problem: command patch PHCO_11909 The following problems are fixed: 1) Under certain circumstances after a hard failure, VxFs fsck log replay would fail requiring a full fsck. 2) On large file systems containing a very large number of files, full fsck would run extremely slowly. PHKL_11607: System may panic in vx_itimes() when mounting a JFS file system after a boot from a hard failure. PHKL_11039: JFS file system corruption when running applications using file truncation on large files. The system message buffer will show: "vxfs: mesg 017: vx_trunc - /mnt file system inode 123 marked bad. vxfs: mesg 016: vx_ilisterr - /mnt file system error reading inode 123". It also fixes a malloc panic which was found while fixing this defect. PHKL_10966: When running fsadm to reorganize extents (de-fragment) the command fails with error: exclusion zone for bno = 323584, len = 2048 failed This error message does not occur at all times. It has been observed when running fsadm on file systems which contain directories with many small files. PHKL_9517: VxFS file system corruption can occur when running the reorg option of the fsadm command on a busy file system. System diagnostic messages from the dmesg command will include the following: vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system inode X marked bad vxfs: mesg 016: vx_ilisterr - /??? file system error reading inode X vxfs: mesg 008: vx_direrr - /??? file system inode X block Y error 6 vxfs: mesg 017: vx_iread - /??? file system error reading inode X . . . Defect Description: PHKL_12100: fsck was not able to handle iau data spread across multiple extents. The kernel, on the other hand, seems capabable of multiple extents for iau. fsck was fixed to agree with kernel with respect to iau. PHKL_11607: The file system that was being mounted had previously been under a reorg operation. The panic occurred during replay on the structural fileset where an inode with the org type of IORG_TYPED was being truncated. The truncate operation produced a transaction with over VX_MAXTRAN subfunctions. vx_trunc_typed() is called to truncate the file to size 0. This function makes an accounting error in its loop that frees extents. For each iteration of the loop vxfs only accounts for one subfunction to add to the transaction while more than one subfunction can be added. PHKL_11039: There was a defect in the routine checking the validity of extent buffers. This defect would cause inodes to be marked wrongly as BAD, when they were perfectly valid. This also fixes a defect that was found while fixing this problem. The bug is in the routine that splits the extent. It assumes that the allocated extent is same as it had requested, which is not always the case. The defect was that it copied half the entries from extent being split to the new extent, and it may be that not all the entries will fix.(if it allocated less than requested). PHKL_10966: The exclusion zones were not being properly merged for some orders of sets if they wound up being adjacent. When at- tempting to clear the exclusion zones, the clearing code did not bother to look at the next zone on the list to see if it was an exact match since adjacent zones should have been merged. PHKL_9517: The problem can be reproduced by executing the following: - create a version 2 VxFS fs the same size as /usr - fragment the fs (ie. fill up the fs with 8k files, and then remove every other one. Proceed to remove groups of files until enough space is available to copy /usr over - cpio /usr to new fs, and run upgrade fs to version 3 - change /etc/fstab to use new volname for /usr, and reboot - start up /usr applications like sam, vi, swinstall, etc. - run several scripts to do things like add/delete small files, and ``ls'' commands in /usr - with ``busy'' filesystem, run "fsadm -Fvxfs -e /usr" The problem was that the resulting geometry was not being taken into account in vx_reorg_copy() if the reorg range was broken up due to lack of free extents of the requested size. The amount of data to be copied cannot be greater than the minimum of the two extent sizes returned by the bmap calls. SR: 4701342121 4701351932 4701352799 4701356931 5003379156 4701361758 Patch Files: /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) /usr/conf/lib/libvxfs_base.a(vx_attr.o) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) what(1) Output: /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o): vx_kdmi.c $Date: 97/08/11 15:04:25 $ $Revision: 1.2. 98.13 $ PATCH_10.20 (PHKL_12100) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o): vx_reorg.c $Date: 97/05/07 10:50:03 $ $Revision: 1.6 .98.12 $ PATCH_10.20 (PHKL_10966) /usr/conf/lib/libvxfs_base.a(vx_attr.o): vx_attr.c $Date: 97/08/11 15:04:23 $ $Revision: 1.7. 98.9 $ PATCH_10.20 (PHKL_12100) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o): vx_bmapext4.c $Date: 96/12/18 07:52:44 $ $Revision: 1.2.98.11 $ PATCH_10.20 (PHKL_9517) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o): vx_bmaptyped.c $Date: 97/08/11 15:04:08 $ $Revision: 1.2.98.16 $ PATCH_10.20 (PHKL_12100) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o): vx_fsetsubr.c $Date: 97/08/11 15:04:19 $ $Revision: 1.2.98.12 $ PATCH_10.20 (PHKL_12100) cksum(1) Output: 3701265017 22548 /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) 4206932155 20336 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) 2246841658 37804 /usr/conf/lib/libvxfs_base.a(vx_attr.o) 1538814991 10848 /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) 4106033481 18332 /usr/conf/lib/ libvxfs_base.a(vx_bmaptyped.o) 2824094623 21176 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_9517 PHKL_10966 PHKL_11039 PHKL_11607 Equivalent Patches: PHKL_12101: s800: 10.20 Patch Package Size: 200 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_12100 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_12100.depot 5b. For a homogeneous NFS Diskless cluster run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This will invoke swcluster in the interactive mode and force all clients to be shut down. WARNING: All cluster clients must be shut down prior to the patch installation. Installing the patch while the clients are booted is unsupported and can lead to serious problems. The swcluster command will invoke an swinstall session in which you must specify: alternate root path - default is /export/shared_root/OS_700 source depot path - /tmp/PHKL_12100.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFS Diskless cluster: - run swinstall on the server as in step 5a to install the patch on the cluster server. - run swcluster on the server as in step 5b to install the patch on the cluster clients. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_12100. 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_12100.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_12100.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: This kernel patch need to work with the command patch PHCO_11909; please install PHCO_11909 with this patch. Installed alone, this kernel patch will not solve the fsck problem. If you are planning to install the advanced VxFS product (AdvJournalFS.VXFS-ADV-KRN), it is imperative that this patch, and all listed superseded patches, be removed from the system via swremove(1M) before the actual product installation. After the installation of the advanced VxFS product has completed, this patch can be re-installed. (It is not necessary to re-install superseded patches prior.) All patches listed in the Supersedes field are subject to this behavior and need to be removed before installing the advanced VxFS product. After running swremove(1M), use the swlist(1M) command to insure that none of the previous patches were restored during the removal process. If one was, remove it using swremove(1M).