Patch Name: PHKL_12601 Patch Description: s700 10.20 VxFS, DMAPI, fsck, quota cumulative patch Creation Date: 97/09/19 Post Date: 97/09/25 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: AdvJournalFS.VXFS-ADV-KRN JournalFS.VXFS-BASE-KRN JournalFS.VXFS-PRG OS-Core.CORE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: No (superseded patches were critical) PHKL_12088: OTHER Patch REQUIRED for the OmniStorage 2.20 product PHKL_9569: HANG PHKL_8294: HANG PHKL_10199: CORRUPTION PHKL_9372: PANIC PHKL_11519: ABORT PHKL_11321: PANIC PHKL_11013: OTHER This problem leaves the file system disabled and unusable, and requires a system reboot to regain access to it. PHKL_7899: PANIC HANG OTHER The KI instrumentation fix does not fall into any of specified symptoms; the root setuid fix does not either. PHKL_11733: OTHER Unmountable VxFS (JFS) file system. PHKL_11860: PANIC PHKL_9370: OTHER Unmountable VxFS (JFS) file system. PHKL_7776: OTHER Unmountable VxFS (JFS) file system. 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_12601 Symptoms: PHKL_12601: VxFS systems do not allow a process to ftruncate() a file it has opened, write-locked and read from. When the program fails, errno is set to 11 which means resource is temporarily unavailable. PHKL_12088: The DMAPI functionality as delivered with HP-UX 10.20 is not functional. Thus the OmniStorage product, which relies exclusively on this functionality, will not work with the shipped JFS DMAPI software provided with the OnlineJFS product. 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_11860: The PHKL_9371 installed system panic's during reboot, if reboot command is used. This patch fixes this problem. PHKL_11733: After a hard failure (panic/hang/TOC), a JFS file system may not mount and will return the following error message: vxfs mount: %s is not a vxfs file system. This could even happen with patches PHKL_9371 and PHCO_11223 installed. A full fsck does not clean the file system; a newfs/mkfs is the only solution. PHKL_11607: System may panic in vx_itimes() when mounting a JFS file system after a boot from a hard failure. PHKL_11519: On a NFS server with a Vxfs file system exported, the file /var/adm/nettl.LOG0x grows dramatically with the recording of "read failed with errno 22" (EINVAL). This problem is addressed by kernel patch PHKL_11322 among other problems. However, after the patch is installed, some NFS clients experience command coredump on the NFS mounted VxFS disk. PHKL_11471: Quota command shows poor performance on a busy system under JFS. PHKL_11321: This patch fixes two JFS performance problems and one defect: 1) Upgrading from 10.10 to 10.20, customer experienced approximately 25% performance degradation in read operation under JFS. 2) Loading a program for a second and subsequent time takes much longer if the program is using shared libraries on JFS. 3) Occasional panic occurs when running an executable which attempts to pagein through vnode level, producing a stack: trap+0xf84 0.0xe21c4 0x6954.0x7ffe75b8 ... $RDB_trap_patch+0x20 0.0x22608 0x6954.0x7ffe75b8 ... lbcopy_fp_method1+0x58 0.0x222b98 0x6954.0x7ffe7108 ... privlbcopy+0x1c 0.0x222fc4 0x6954.0x7ffe70c8 ... uiomove+0x4f0 0.0xfabe8 0x6954.0x7ffe7008 ... vx_read1+0x26c 0.0xb9744 0x6954.0x7ffe6ec8 ... vx_rdwr+0x16c 0.0xc5164 0x6954.0x7ffe6e08 ... vn_rdwr+0x8c 0.0x107b04 0x6954.0x7ffe6d48 ... mfs_hpux_pagein+0x448 0.0x1cbb5c 0x6954.0x7ffe6c88 ... virtual_fault+0x9a0 0.0xf1fc8 0x6954.0x7ffe6b48 ... vfault+0x104 0.0xf281c 0x6954.0x7ffe6ac8 ... trap+0x129c and the message: trap type 15, pcsq.pcoq = 0.222b98, isr.ior = 18e.4179000 savestate ptr = 0x7ffe7108, savestate return ptr = 0x222fc4 9245XB HP-UX (B.10.20) #1: Sun Jun 9 06:31:19 PDT 1996 panic: (display==0xbd00, flags==0x0) Data page fault This is mostly seen on PureAtria's Clearcase product which sets the UIOSEG_PAGEIN flag for vn_rdwr() calls. PHKL_11247: On a VxFS with quota turned on, users who do not have quota set receive "write: Disk quota exceeded" error message when creating files on this file system. 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_11013: The vxupgrade command, used to convert a JFS version 2 file system to a version 3, can give an I/O error on execution. This causes the file system to be marked as unavailable, and a full fsck to be run. 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_10199: 10.20 JFS version 3 file system returns the following file allocation error on file systems large than 64Gb before the file system is actually full: vxfs: msg001: vx_nospace - /dev/vgXX/lvolY file system full (1 block extent) The following console message may also be seen: vxfs: mesg 003: vx_mapbad - /dev/vgXX/lvolY file system free extent bitmap in au nnnn marked bad PHKL_9711: Each time edquota -t is invoked for a VxFS file system, it resets the previously defined file system time limit back to default (7 days). PHKL_9569: This patch addresses 2 distinct VxFS (JFS) symptoms: - When trying to take a file-system snapshot, the mount command could fail with the following error message: # mount -F vxfs -o snapof=/dev/vg00/vxonline \ /dev/vg00/vxbackup /vxbackup vxfs mount: /dev/vg00/vxbackup is already mounted, /vxbackup is busy, or allowable number of mount points exceeded - The system could hang when manipulating directories. 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 . . . PHKL_9372: Panic: "data page fault" when using fsadm to resize a mounted VxFS filesystem with disk quotas. PHKL_9370: If a customer upgrades from 10.01 or 10.10 to 10.20, and tries to increase their VxFS file systems via SAM, the file system will not mount after completion of extending the volume and file system. The typical approach for SAM is: 1) unmount the file system 2) lvextend the volume 3) extendfs the file system 4) mount the file system The mount will always fail in this case. PHKL_9153: Add write-gathering support for NFS servers. PHKL_8481: JFS performance in 10.20 has improved disk i/o throughput at the cost of extra CPU utilization. This patch improves JFS performance by implementing a log buffer re-use scheme and also by making modifications to the read/write sleep lock primitives. PHKL_8294: When multiple nfsd's access the same file simultaneously, they hang in a deadlock. PHKL_7899: KI queuedone, enqueue and queuestart traces on JFS may contain NULL values in the b_apid and b_upid fields. With a system running a heavy load using JFS on LVM, the following panic may occur: "lv_syncx: returning error: 5" Systems running JFS may hang due to a deadlock problem. The setuid bit will be removed on a JFS file when the file is edited or text has been appended to it when run as root. PHKL_7776: It's possible for a JFS file system to get into a state where it can't be mounted (except read-only), but fsck(1M) does not report any problem with it. At mount time, the kernel prints the following warning on the console: vxfs: mesg 012: vx_iget - file system invalid inode number XXX and mount(1M) fails with the following message: vxfs mount: /dev/XXX is not a vxfs file system. Once a file system has gotten into this state, it remains unmountable, even after running fsck(1M). Defect Description: PHKL_12601: ftruncate() retuns EAGAIN on madatory locking regardless of lock owner. If we have mandatory locking on a VxFS file and if there is a pending lock, then we return EAGAIN regardless of the owner of the lock. vx_setattr() does not allow a file to be truncated if there is mandatory file lock owned by another process, even if it does not overlap the range being truncated. PHKL_12088: If a customer installs the HP-UX OmniStorage product on the 10.20 release, the product would not be functional. The DMAPI extensions available with the OnlineJFS product (currently only being utilized by OmniStorage and not linked into the kernel by default), had several severe bugs that were fixed in the 10.30 release. This patch backports the DMAPI functionality from 10.30 into 10.20. 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_11860: It is assumed that there is one active reference to a disk quota at vx_quotaoff(), which enables to free vx_dquota blocks in vx_dqlist. This assumption is not true during vx_replay() since there is still a VX_MLDQUOT mlink in the file system mlink chain waiting to be flushed. Hence, flushing the file system's mlink queue before calling vx_quotaoff will fix the problem. PHKL_11733: After a hard system failure, a JFS file system may not mount even if PHKL_9371 and PHCO_11223 are installed. If the VX_IETRUNC flag is set for a file, then vx_trunc() is called and returns without clearing the ip->i_eopflags field. Since VX_IETRUNC alone is still set after vx_trunc(), the error return is set to EINVAL (reason why the mount fails). Prior to returning, if error is non-zero, vxfs sets the VX_FULLFSCK flag and returns. Patch PHKL_9371 added the setting of the VX_FULLFSCK flag; the bug leaving the ip->i_eopflags set to VX_IETRUNC still existed prior to PHKL_9371, however after the first failed mount, a second mount would have been successful. 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_11519: During vnode read operation, if the request is from NFS, the request size is checked against the VX_MAXBSIZE and an EINVAL is returned if the request size is greater than or equal to VX_MAXBSIZE. The EINVAL is always returned because the request size is set to VX_MAXBSIZE (8K) for NFS by the calling routine. When PHKL_11322 fixes this problem, the code proceeds to read the data block and returns the buffer back to NFS. This exposes a bug in which if the data we need starts at a non-zero offset within the buffer and the caller receives the whole buffer assuming the good data starts at the beginning, invalid data is loaded and command coredumps. PHKL_11471: The quota command uses quotactl(Q_SYNC, NULL, 0, NULL) to update the quota usage file on all quota active file systems. For each VxFS file system, the quota sync operation flushes all transactions and writes quota information to the disk file synchronously. On a system with heavy I/O, this results long delay. The fix is to flush the transaction log only and use asynchronous I/O for disk file update. PHKL_11321: 1) In vx_read1(), some unnecessary conditions prevented vx_read_ahead() from being called for large reads. The fix is to remove these extra checkings to allow read_ahead to be performed. 2) When we are done with a shared library, pageout routine is called to flush the changes to disk. The way vx_pageout() works is that it invalidates the cached copy of the file then calls vx_do_pageout() to figure out the MMF pages need to be written and write them. A more efficient way of doing this is to invalidate and flush buffers in the buffer cache only if there are and may have been dirty pages. 3) When reading a sparse portion of a file on JFS, vx_read1() calls uiomove() to copy a page of zeroes to the target buffer. If the UIOSEG_PAGEIN flag is set in the uio structure, uiomove() by default will copy vx_zeropage from the buffer cache. Since vx_zeropage is not in the buffer cache's space, but is in space 0, this references an invalid address and triggers a panic. The fix is to replace uiomove() with long_uiomove() which allows the correct space id to be specified. PHKL_11247: An uninitialized variable, depending on what value it picks up from the stack, causes the quota checking routine to return EDQUOT erroneously during extent allocation. 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_11013: During vxupgrade, it is possible for the allocation unit length to change; thus the same inode located in the same block will change allocation unit numbers. There was a check in vx_iremount() to verify that the allocation unit numbers matched, and returned ENOSPC if not. This was the root cause of the problem which was easily reproducible: o Create a version 2 JFS file system on a 1GB volume: mkfs -Fvxfs -oversion=2 /dev/vg01/onegigvol o mount it: mount -Fvxfs /dev/vg01/onegigvol /tmp_mnt o fill up the file system halfway: prealloc /tmp_mnt/bigfile 500000000 o copy some files into the filesystem: cp -r /usr /tmp_mnt & o wait a few minutes and execute the vxupgrade command: vxupgrade -n 3 /tmp_mnt 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_10199: The bug is in the allocation and freeing of entire allocation units on file systems larger than 64Gb in JFS version 3. When calculating the buddy allocation unit to allocate and free, the code fails to add back in the map section that it subtracts out earlier, causing the summary of the wrong AU to be updated. The incorrect values in AU summaries and all higher level summaries lead to the allocation failure. PHKL_9711: VxFS quota routine vx_getquota() resets the time limit for root because it thinks root should not have a quota limit. Somehow it ignores the fact that the timelimit fields in root's dqblk structure are used to store the file system time limit. PHKL_9569: This patch fixes two different VxFS (JFS) defects: - A snapshot could not be mounted if a process was waiting arbitrarily long for a file record lock. An application using lockf() or fcntl() to get file record locks, and holding the locks for a long period of time, could prevent from mounting a file-system snapshot. - The VxFS rmdir(2) routine could run into a deadlock situation where the directory would be kept locked. Processes attempting to access the locked directory would then wait forever, and eventually this could cause the entire system to hang. 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. PHKL_9372: Resizing VxFS filesystems online effectively does quick unmounts and remounts of the filesystem, switching quickly between the two different data areas containing the filesystem structure information. The VxFS disk quota tracking structures were not updated during the switch, with the end result that the disk quota code was accessing invalid memory. The fix was to update the disk quota structures during the switch. PHKL_9370: The inode summary fields in the new allocation unit added by extendfs were not properly initialized, so whatever happened to be in the block wound up being treated as inode summary data. The vxfs fsck command never detected this, and the mount command was failing in the kernel due to a file system validation error. The problem is easily reproduced by executing the following: # lvcreate -L 40 -n testvol /dev/vg00 # mkfs -Fvxfs -oversion=2 /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt # umount /tmp_mnt # lvextend -L 80 /dev/vg00/testvol # extendfs -Fvxfs /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt PHKL_9153: Added code to update the v_last_fsync field on the vnode. This field will be used by rfs_write to implement write gathering on nfs servers. Patch PHKL_9155/56, which updates rfs_write(), must also be applied for this patch to be effective. If both patches are applied, server throughput should increase for write-intensive workloads, and I/O traffic to disk should decrease. PHKL_8481: JFS extra CPU utilization may cause system performance problems on some configurations. PHKL_8294: ufs_bread(), called by nfs server routines, prematurely unlocks the inode while the caller still owns the buffer. This opens a window for another process to grab the inode lock. Deadlock occurs when the process owning the buffer tries to access the inode again and the process holding the inode waits for the buffer to be available before it can release the inode lock. The fix is to delay the inode unlocking in ufs_bread() until the inode is no longer needed. PHKL_7899: KI problem: The JFS buffer allocation and IO paths were not fully instrumented causing buffer header b_apid and b_upid fields not to be updated consistently. The resulting KI queuedone, enqueue, and queuestart traces contain NULL values in these fields. A panic can occur with JFS on LVM due to an inode being able to change identity before it and its dirty pages are flushed to disk in vx_freeze_iflush(). System can deadlock due to a locking order problem in JFS when vx_fast_read() is called from VOP_BREAD. When a JFS file is created with the SETUID flag, the setuid bit is removed when the file has been edited with vi or text has been appended to it; this should only be the case when the writer is not root. PHKL_7776: At mount time, the kernel completes any pending "extended operations" for a JFS file system. (These might include, for example, removing a file that has no links but couldn't be removed when the last link went away because some process had the file open.) We maintain a bitmap on disk with one bit per inode indicating whether the inode has any extended operations pending, to avoid having to inspect every single inode at mount time. However, the calculation of an inode number from a bit in the bitmap is done incorrectly. This means, first of all, that some extended operations are never completed. More seriously, the inode number we calculate could be out of range, causing the mount to fail. Running fsck(1M) will not help, since there's nothing wrong with the file system. Although the file system can't be mounted in read/write mode, it can be mounted read-only. If a file system gets into this unmountable state, the only recourse is to mount it read-only and to copy the files from it to another (replacement) file system. SR: 1653166066 1653166983 1653194555 1653199802 1653216077 1653220079 4701327544 4701329292 4701329300 4701329441 4701334995 4701341479 4701341669 4701342121 4701344515 4701351932 4701352799 4701355560 4701356931 4701361444 4701361758 5003317487 5003330910 5003348425 5003363523 5003368290 5003379156 5003385203 5003387183 Patch Files: /usr/conf/lib/libdmapi.a(kdm_core.o) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) /usr/conf/lib/libhp-ux.a(vfs.o) /usr/conf/lib/libufs.a(ufs_vnops.o) /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o) /usr/conf/lib/libvxfs_base.a(vx_alloc.o) /usr/conf/lib/libvxfs_base.a(vx_attr.o) /usr/conf/lib/libvxfs_base.a(vx_bio.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_bsdquota.o) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) /usr/conf/lib/libvxfs_base.a(vx_iflush.o) /usr/conf/lib/libvxfs_base.a(vx_inode.o) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) /usr/conf/lib/libvxfs_base.a(vx_lite.o) /usr/conf/lib/libvxfs_base.a(vx_log.o) /usr/conf/lib/libvxfs_base.a(vx_mount.o) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) /usr/conf/lib/libvxfs_base.a(vx_replay.o) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) /usr/conf/lib/libvxfs_base.a(vx_vm.o) /usr/conf/lib/libvxfs_base.a(vx_vnops.o) /usr/include/dmapi.h /usr/include/sys/fs/vx_hpux.h what(1) Output: /usr/conf/lib/libdmapi.a(kdm_core.o): kdm_core.c $Date: 97/09/02 13:10:59 $ $Revision: 1.2 .98.9 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libdmapi.a(vx_dmattr_table.o): vx_dmattr_table.c $Date: 97/09/02 13:11:16 $ $Revisi on: 1.2.98.4 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libhp-ux.a(vfs.o): vfs.c $Date: 97/09/03 09:31:30 $ $Revision: 1.25.98. 12 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libufs.a(ufs_vnops.o): ufs_vnops.c $Date: 97/09/03 09:30:03 $ $Revision: 1.30.98.18 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o): vx_dmattr.c $Date: 97/09/02 13:11:14 $ $Revision: 1. 2.98.7 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o): vx_kdmi.c $Date: 97/09/02 13:11:34 $ $Revision: 1.2. 98.14 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_adv.a(vx_reorg.o): vx_reorg.c $Date: 97/09/03 13:35:46 $ $Revision: 1.6 .98.13 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_adv.a(vx_sample_dmattr.o): vx_sample_dmattr.c $Date: 97/09/02 13:11:41 $ $Revis ion: 1.2.98.8 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_alloc.o): vx_alloc.c $Date: 97/09/02 13:11:08 $ $Revision: 1.5 .98.14 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_attr.o): vx_attr.c $Date: 97/09/02 13:11:11 $ $Revision: 1.7. 98.10 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_bio.o): vx_bio.c $Date: 97/09/03 11:56:28 $ $Revision: 1.7.9 8.10 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o): vx_bmapext4.c $Date: 97/09/03 13:33:47 $ $Revision: 1.2.98.12 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o): vx_bmaptyped.c $Date: 97/09/03 13:35:40 $ $Revision: 1.2.98.17 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o): vx_bsdquota.c $Date: 97/09/03 09:25:58 $ $Revision: 1.7.98.13 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o): vx_dmstubs.c $Date: 97/09/02 13:11:23 $ $Revision: 1 .2.98.7 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o): vx_fsetsubr.c $Date: 97/09/03 13:35:44 $ $Revision: 1.2.98.13 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o): vx_hpuxsubr.c $Date: 97/09/02 13:11:25 $ $Revision: 1.7.98.13 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_iflush.o): vx_iflush.c $Date: 97/09/02 13:11:27 $ $Revision: 1. 6.98.14 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_inode.o): vx_inode.c $Date: 97/09/02 13:11:29 $ $Revision: 1.7 .98.19 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_itrunc.o): vx_itrunc.c $Date: 97/09/02 13:11:32 $ $Revision: 1. 7.98.18 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_lite.o): vx_lite.c $Date: 97/09/02 13:11:37 $ $Revision: 1.4. 98.7 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_log.o): vx_log.c $Date: 97/09/03 09:28:35 $ $Revision: 1.6.9 8.6 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_mount.o): vx_mount.c $Date: 97/09/02 13:11:38 $ $Revision: 1.7.98.15 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_rdwri.o): vx_rdwri.c $Date: 97/09/03 09:28:39 $ $Revision: 1.7 .98.24 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_replay.o): vx_replay.c $Date: 97/09/03 13:35:49 $ $Revision: 1. 2.98.13 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_vfsops.o): vx_vfsops.c $Date: 97/09/03 09:28:42 $ $Revision: 1. 7.98.14 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_vm.o): vx_vm.c $Date: 97/09/03 09:28:43 $ $Revision: 1.7.98 .15 $ PATCH_10.20 (PHKL_12088) /usr/conf/lib/libvxfs_base.a(vx_vnops.o): vx_vnops.c $Date: 97/09/19 10:32:10 $ $Revision: 1.8 .98.24 $ PATCH_10.20 (PHKL_12601) /usr/include/dmapi.h: dmapi.h: $Revision: 1.2.98.7 $ $Date: 97/09/02 13:03 :46 $ dmapi.h $Date: 97/09/02 13:03:46 $ $Revision: 1. 2.98.7 $ PATCH_10.20 (PHKL_12088) src/kernel/dmapi/dmapi.h 2.12 14 Aug 1996 18:51:12 - */ /usr/include/sys/fs/vx_hpux.h: vx_hpux.h: $Revision: 1.7.98.14 $ $Date: 97/09/03 09 :28:45 $ PATCH_10.20 (PHKL_12088) src/kernel/vxfs/vx_hpux.h 2.14.4.3 30 Jul 1996 17:05 :11 - */ fshp:src/kernel/vxfs/vx_hpux.h 2.14.4.3 cksum(1) Output: 2308637956 48664 /usr/conf/lib/libdmapi.a(kdm_core.o) 1239256143 1776 /usr/conf/lib/libdmapi.a(vx_dmattr_table.o) 939331928 20436 /usr/conf/lib/libhp-ux.a(vfs.o) 961541333 33300 /usr/conf/lib/libufs.a(ufs_vnops.o) 269850224 2956 /usr/conf/lib/libvxfs_adv.a(vx_dmattr.o) 2108343930 24740 /usr/conf/lib/libvxfs_adv.a(vx_kdmi.o) 3852088001 20336 /usr/conf/lib/libvxfs_adv.a(vx_reorg.o) 1890809084 4584 /usr/conf/lib/ libvxfs_adv.a(vx_sample_dmattr.o) 1310379027 28264 /usr/conf/lib/libvxfs_base.a(vx_alloc.o) 2930551803 37640 /usr/conf/lib/libvxfs_base.a(vx_attr.o) 2754688379 10480 /usr/conf/lib/libvxfs_base.a(vx_bio.o) 2938008535 10848 /usr/conf/lib/libvxfs_base.a(vx_bmapext4.o) 97328057 18332 /usr/conf/lib/libvxfs_base.a(vx_bmaptyped.o) 721700635 29152 /usr/conf/lib/libvxfs_base.a(vx_bsdquota.o) 2467117336 4928 /usr/conf/lib/libvxfs_base.a(vx_dmstubs.o) 2502467378 21176 /usr/conf/lib/libvxfs_base.a(vx_fsetsubr.o) 1856632835 16284 /usr/conf/lib/libvxfs_base.a(vx_hpuxsubr.o) 79717413 29716 /usr/conf/lib/libvxfs_base.a(vx_iflush.o) 725780164 44848 /usr/conf/lib/libvxfs_base.a(vx_inode.o) 2389370151 14580 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) 3907487765 3592 /usr/conf/lib/libvxfs_base.a(vx_lite.o) 3051126019 9620 /usr/conf/lib/libvxfs_base.a(vx_log.o) 480895945 28328 /usr/conf/lib/libvxfs_base.a(vx_mount.o) 2012872711 35416 /usr/conf/lib/libvxfs_base.a(vx_rdwri.o) 235394518 7048 /usr/conf/lib/libvxfs_base.a(vx_replay.o) 1883111337 15192 /usr/conf/lib/libvxfs_base.a(vx_vfsops.o) 479121503 11916 /usr/conf/lib/libvxfs_base.a(vx_vm.o) 4182450282 26624 /usr/conf/lib/libvxfs_base.a(vx_vnops.o) 1315928410 16548 /usr/include/dmapi.h 1556434298 9724 /usr/include/sys/fs/vx_hpux.h Patch Conflicts: None Patch Dependencies: s700: 10.20: PHCO_11909 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7776 PHKL_7899 PHKL_8294 PHKL_8481 PHKL_9153 PHKL_9370 PHKL_9372 PHKL_9517 PHKL_9569 PHKL_9711 PHKL_10199 PHKL_10966 PHKL_11013 PHKL_11039 PHKL_11247 PHKL_11321 PHKL_11471 PHKL_11519 PHKL_11607 PHKL_11733 PHKL_11860 PHKL_12088 PHKL_12100 Equivalent Patches: PHKL_12602: s800: 10.20 Patch Package Size: 670 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_12601 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_12601.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_12601.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_12601. 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_12601.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_12601.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.) 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). Due to the number of objects in this patch, the customization phase of the update may take more than 10 minutes. During that time the system will not appear to make forward progress, but it will actually be installing the objects.