fs-hpux1131-5.1SP1RP2P1
Obsolete
The latest patch(es) : sfha-hpux1131-5.1SP1RP3 

 Basic information
Release type: P-patch
Release date: 2013-02-27
OS update support: None
Technote: None
Documentation: None
Popularity: 1047 viewed    downloaded
Download size: 68.03 MB
Checksum: 3636396101

 Applies to one or more of the following products:
Storage Foundation 5.1SP1 On HP-UX 11i v3 (11.31)
Storage Foundation Cluster File System 5.1SP1 On HP-UX 11i v3 (11.31)
Storage Foundation for Oracle RAC 5.1SP1 On HP-UX 11i v3 (11.31)
Storage Foundation HA 5.1SP1 On HP-UX 11i v3 (11.31)

 Obsolete patches, incompatibilities, superseded patches, or other requirements:

This patch is obsolete. It is superseded by: Release date
sfha-hpux1131-5.1SP1RP3 2013-10-15

This patch supersedes the following patches: Release date
fs-hpux1131-5.1SP1RP1P2 (obsolete) 2012-06-19
fs-hpux1131-5.1SP1RP1P1 (obsolete) 2012-02-07

This patch requires: Release date
sfha-hpux1131-5.1SP1RP2 (obsolete) 2012-10-29

 Fixes the following incidents:
3042340, 3042341, 3042351, 3042352, 3042357, 3042373, 3042407, 3042427, 3042479, 3042501, 3047980, 3073371, 3074864

 Patch ID:
PHCO_43435
PHKL_43432

Readme file
                          * * * READ ME * * *
              * * * Veritas File System 5.1 SP1 RP2 * * *
                         * * * P-patch 1 * * *
                         Patch Date: 2013-02-27


This document provides the following information:

   * PATCH NAME
   * OPERATING SYSTEMS SUPPORTED BY THE PATCH
   * PACKAGES AFFECTED BY THE PATCH
   * BASE PRODUCT VERSIONS FOR THE PATCH
   * SUMMARY OF INCIDENTS FIXED BY THE PATCH
   * DETAILS OF INCIDENTS FIXED BY THE PATCH
   * INSTALLATION PRE-REQUISITES
   * INSTALLING THE PATCH
   * REMOVING THE PATCH


PATCH NAME
----------
Veritas File System 5.1 SP1 RP2 P-patch 1


OPERATING SYSTEMS SUPPORTED BY THE PATCH
----------------------------------------
HP-UX 11i v3 (11.31)


PACKAGES AFFECTED BY THE PATCH
------------------------------
VRTSvxfs
VRTSvxfs


BASE PRODUCT VERSIONS FOR THE PATCH
-----------------------------------
   * Veritas Storage Foundation for Oracle RAC 5.1 SP1
   * Veritas Storage Foundation Cluster File System 5.1 SP1
   * Veritas Storage Foundation 5.1 SP1
   * Veritas Storage Foundation High Availability 5.1 SP1


SUMMARY OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
Patch ID: PHCO_43435, PHKL_43432
* 3042340 (2616622) The performance of the mmap() function is slow when the file system block size is 8KB and the page size is 4KB.
* 3042341 (2555198) sendfile() does not create DMAPI events for HSM on VxFS.
* 3042351 (2858683) Reserve extent attributes changed after vxrestore, only for
files greater than 8192bytes
* 3042352 (2806466) "fsadm -R" resulting in panic at LVM layer due to vx_ts.ts_length set to 2GB.
* 3042357 (2750860) Performance issue due to CFS fragmentation in CFS cluster
* 3042373 (2874172) Infinite looping in vx_exh_hashinit()
* 3042407 (3031869) "vxfsstat -b" does not print correct information on maximum
buffer size
* 3042427 (2850738) The system may hang in the low memory condition.
* 3042479 (3042460) Add support for DOX lock to tackle vnode lock contention in VN_HOLD/RELE
* 3042501 (3042497) Atomically increment/decrement active level in HP
* 3047980 (2439261) [VxFS]VxFS 16 bytes sequential writes buffer IO performance is 30% slower than jfs2. fiostats seems to be taking time.
* 3073371 (3073372) Changing default max pdir level to 2 and default threshold size to 32768.
* 3074864 (3073372) Changing default max pdir level to 2 and default threshold size to 32768.


DETAILS OF INCIDENTS FIXED BY THE PATCH
---------------------------------------
This patch fixes the following Symantec incidents:

Patch ID: PHCO_43435, PHKL_43432

* 3042340 (Tracking ID: 2616622)

SYMPTOM:
The performance of the mmap() function is slow when the file system block size 
is 8 KB and the page size is 4 KB.

DESCRIPTION:
When the file system block size is 8 KB, the page size is 4 KB, and the mmap() 
function is performed on an 8 KB file, the file gets represented in memory as 
two pages (0 and 1). When the memory at offset 0 in the mapping is modified, a 
page fault occurs for page 0 in the file. When that disk 
block is allocated and marked as valid, the page mentioned in the fault request 
is expected to get flushed out to the disk and therefore, it is left 
uninitialized on the disk by default. Only that particular page is cleaned in 
memory and left modified so that it is known that the data in memory ismore 
recent than the data on disk. However, the other half of the block (which could 
eventually be mapped to page 1) gets cleared with a synchronous write because 
such a fault may not occur. This synchronous clearing of the other half of 8 KB 
block causes performance degradation.

RESOLUTION:
The code is modified to expand the range of the fault to cover the entire 8 KB 
block. The message from the OS asking for only one page is ignored and two 
pages are given to cover the entire file system block to save the separate 
synchronous clearing of the other half of 8 KB block.

* 3042341 (Tracking ID: 2555198)

SYMPTOM:
On HPUX 11.31 binary mode, File Transfer Protocol (FTP) transfer uses the 
sendfile() interface, which  does not create the DMAPI events for Hierarchical 
Storage Management (HSM).

DESCRIPTION:
The sendfile() interface does not call the Veritas File System (VxFS) read() 
function that creates the DMAPI events. It uses the HP Unified File Cache(UFC) 
interface. The UFC interface is not aware of the HSM application. As a result, 
the DMAPI events are not generated.

RESOLUTION:
The code is modified to set a flag in the vfs structure during the mount time, 
to indicate if the file system is configured under HSM. This flag information 
is used by the UFC interface to generate the DMAPI events.

* 3042351 (Tracking ID: 2858683)

SYMPTOM:
The reserve-extent attributes are changed after the vxrestore(1M ) operation, 
for files that are greater than 8192 bytes.

DESCRIPTION:
A local variable is used to contain the number of the reserve bytes that are 
reused during the vxrestore(1M) operation, for further VX_SETEXT ioctl call for 
files that are greater than 8k. As a result, the attribute information is 
changed.

RESOLUTION:
The code is modified to preserve the original variable value till the end of 
the function.

* 3042352 (Tracking ID: 2806466)

SYMPTOM:
A reclaim operation on a filesystem mounted on a Logical Volume Manager (LVM)
volume using the fsadm(1M) command with the "R" option may panic the system and 
the following stack trace is displayed:
vx_dev_strategy+0xc0() 
vx_dummy_fsvm_strategy+0x30() 
vx_ts_reclaim+0x2c0() 
vx_aioctl_common+0xfd0() 
vx_aioctl+0x2d0() 
vx_ioctl+0x180()

DESCRIPTION:
Thin reclamation is supported only on the file systems mounted on a Veritas 
Volume Manager (VxVM) volume.

RESOLUTION:
The code is modified to error out gracefully if the underlying volume is LVM.

* 3042357 (Tracking ID: 2750860)

SYMPTOM:
On a large file system(4TB or greater), the performance of the write(1) 
operation with many small request sizes may degrade, and many threads may be 
found sleeping with the following stack trace:
real_sleep
sleep_one
vx_sleep_lock
vx_lockmap
vx_getemap
vx_extfind
vx_searchau_downlevel
vx_searchau_downlevel
vx_searchau_downlevel
vx_searchau_downlevel
vx_searchau_uplevel
vx_searchau
vx_extentalloc_device
vx_extentalloc
vx_te_bmap_alloc
vx_bmap_alloc_typed
vx_bmap_alloc
vx_write_alloc3
vx_recv_prealloc
vx_recv_rpc
vx_msg_recvreq
vx_msg_process_thread
kthread_daemon_startup

DESCRIPTION:
For a cluster-mounted file system, the free-extend-search algorithm is not 
optimized for a large file system (4TB or greater), and for instances where 
the number of free Allocation Units (AUs) available can be very large.

RESOLUTION:
The code is modified to optimize the free-extend-search algorithm by skipping 
certain AUs. This reduces the overall search time.

* 3042373 (Tracking ID: 2874172)

SYMPTOM:
Network File System (NFS) file creation thread might loop continuously 
with the following stack trace:

vx_getblk_cmn(inlined)
vx_getblk+0x3a0 
vx_exh_allocblk+0x3c0
vx_exh_hashinit+0xa50
vx_dexh_create+0x240
vx_dexh_init+0x8b0 
vx_do_create+0x1e0 
vx_create1+0x1d0 
vx_create0+0x270
vx_create+0x40
rfs3_create+0x420
common_dispatch+0xb40
rfs_dispatch+0x40
svc_getreq+0x250
svc_run+0x310  
svc_do_run+0xd0
nfssys+0x6a0  
hpnfs_nfssys+0x60  
coerce_scall_args+0x130 
syscall+0x590

DESCRIPTION:
The Veritas File System (VxFS) file creation vnode operation (VOP) 
routine expects the parent vnode to be a directory vnode pointer. But, the NFS 
layer passes a stale file vnode pointer by default. This might cause unexpected 
results such as hang during VOP handling.

RESOLUTION:
The code is modified to check for the vnode type of the parent 
vnode pointer at the beginning of the create VOP call and return an error if it 
is not a directory vnode pointer.

* 3042407 (Tracking ID: 3031869)

SYMPTOM:
In a multi-CPU environment, the "vxfsstat -b" command does not print the 
correct information on the maximum-size buffer.

DESCRIPTION:
The "vx_bc_bufhwm" parameter represents the maximum amount of memory that can 
be used to cache the VxFS metadata. When the kctune(1M) command is used to tune 
the "vxfs_bc_bufhwm" parameter to a different value, the tunable is not set 
correctly due to the incorrect arithmetic. As a consequence, the "vxfsstat -b" 
command reports the maximum-size buffer to be increased, even though 
the "vxfs_bc_bufhwm" parameter is tuned to a lower value.

RESOLUTION:
The code is modified to correct the arithmetic for tuning the "vx_bc_bufhwm" 
parameter.

* 3042427 (Tracking ID: 2850738)

SYMPTOM:
The Veritas File System (VxFS) module allocates memory with MEMWAIT in the 
callback() routine during the low memory condition. This causes the system to 
hang with the following
stack trace:
swtch_to_thread(inlined)
slpq_swtch_core+0x520   real_sleep(inlined)
sleep+0x400 
mrg_reserve_swapmem(inlined)
$cold_steal_swap+0x460
$cold_kalloc_nolgpg+0x4b0 
kalloc_internal(inlined)
$cold_kmem_arena_refill+0x650
kmem_arena_varalloc+0x280 
vx_alloc(inlined)vx_worklist_enqueue+0x40 
vx_buffer_kmcache_callback+0x160
kmem_gc_arena(inlined)
foreach_arena_ingroup+0x840
kmem_garbage_collect_group(inlined)
kmem_garbage_collect+0x390 
kmem_arena_gc+0x240 
kthread_daemon_startup+0x90

DESCRIPTION:
The VxFS kernel memory callback() routine allocates memory with MEMWAIT. As a 
result, the system hangs in low memory condition.

RESOLUTION:
The code is modified to allocate memory without waiting in the VxFS kernel 
memory callback() routine.

* 3042479 (Tracking ID: 3042460)

SYMPTOM:
On high end configurations (single npar or stand alone systems) having more 
than 128 number of processing units, where the work load frequently involves 
translating a pathname to vnode such as open, stat, find etc, may observe 
reduced performance due to vnode spin lock contention.

DESCRIPTION:
Efficient locking technique is not used in the pathname traversal component of 
VxFS.

RESOLUTION:
The code has been modified to use a locking mechanism called "shared write 
spinlocks" which provides an efficient means to lock a vnode. To make use of 
this new locking, the following set of products, including this patch, has to 
be installed on the system: 
PHKL_43180
PHKL_43178
SyncShwrspl
VfsShwrsplEnh

* 3042501 (Tracking ID: 3042497)

SYMPTOM:
On high end configurations (single npar or stand alone systems) having more 
than 128 number of processing units, contention is seen on the locks to 
serialize the increment and decrement of active levels used to serialize the 
file-system activity.

DESCRIPTION:
In the current implementation, the active level is incremented or decremented 
by taking a spin lock leading to the contention on the locks.

RESOLUTION:
The code has been enhanced to enable incrementing or decrementing the active 
level atomically.

* 3047980 (Tracking ID: 2439261)

SYMPTOM:
When vx_fiostats_tunable is changed from zero to non-zero, the system panics 
with the following stack trace:
panic_save_regs_switchstack+0x110 ()
panic+0x410 ()
bad_kern_reference+0xa0 ()
$cold_pfault+0x5c0 ()
vm_hndlr+0x370 ()
bubbleup+0x880 ()
vx_fiostats_do_update+0x140 ()
vx_fiostats_update+0x170 ()
vx_read1+0x10e0 ()
vx_rdwr+0x790 ()
vno_rw+0xd0 ()
rwuio+0x32f ()
pread+0x121 ()
syscall+0x590 ()
in ?? ()

DESCRIPTION:
When vx_fiostats_tunable is changed from zero to non-zero, all the incore-inode 
fiostats attributes are set to NULL. When these attributes are accessed, the 
system panics due to the NULL pointer dereference.

RESOLUTION:
The code has been modified such that when vx_fiostats_tunable is changed from 
zero to non-zero, it is verified if the fiostats attributes of inode are NULL 
or not. This will prevent the panic.

* 3073371 (Tracking ID: 3073372)

SYMPTOM:
Contention as observed in the lookup-code path when the maximum number of the 
partition-directory level is set to 3 and the the default partition-directory 
threshold is 32000.

DESCRIPTION:
An enhancement is required to change the default maximum number of the 
partition-directory level to 2 and the default partition-directory threshold 
(directory size beyond which partition directories come into effect) to 32768.

RESOLUTION:
An enhancement is made to change the default maximum number of the partition-
directory level to 2 and the default partition-directory threshold to 32768. 
The man pages are updated to reflect these changes accordingly.

* 3074864 (Tracking ID: 3073372)

SYMPTOM:
Contention as observed in the lookup-code path when the maximum number of the 
partition-directory level is set to 3 and the the default partition-directory 
threshold is 32000.

DESCRIPTION:
An enhancement is required to change the default maximum number of the 
partition-directory level to 2 and the default partition-directory threshold 
(directory size beyond which partition directories come into effect) to 32768.

RESOLUTION:
An enhancement is made to change the default maximum number of the partition-
directory level to 2 and the default partition-directory threshold to 32768. 
The man pages are updated to reflect these changes accordingly.



INSTALLING THE PATCH
--------------------
1.Installing VxFS 5.0 SP1RP2P1 patch:

a)If you install this patch on a CVM cluster, install it one system at a time so that all the nodes are not brought down
 simultaneously.

b)VxFS 5.0(GA)  must be installed before applying these patches.

c)To verify the VERITAS file system level, enter:

     # swlist -l product | egrep -i "VRTSvxfs"

  VRTSvxfs     5.1.100.000        VERITAS File System

Note : VRTSfsman is a corequisite for VRTSvxfs.Hence VRTSfsman also needs to be installed alongwith VRTSvxfs.

    # swlist -l product | egrep -i "VRTS"

  VRTSvxfs      5.1.100.000      Veritas File System

d)All prerequisite/corequisite patches have to be installed.The Kernel patch requires a system reboot for both installat
ion and removal.

e)To install the patch, enter the following command:

# swinstall -x autoreboot=true -s <patch_directory>    PHCO_43435 PHKL_43432

Incase the patch is not registered, the patch can be registered using the following command:

# swreg -l depot <patch_directory>   ,

where  <patch_directory>    is the absolute path where the patch resides.


REMOVING THE PATCH
------------------
Removing VxFS 5.0 SP1RP2P1 patches:

a)To remove the patch, enter the following command:

# swremove -x autoreboot=true PHCO_43435 PHKL_43432


SPECIAL INSTRUCTIONS
--------------------
NONE


OTHERS
------
NONE