extending secondary swap...11iv2

[chindi]

Hi,
i got deferred swap reservation failiure in my syslog..
so i added a secondary swap of 8gb to my system..
rx2660
hpux 11iv2..
16 gb RAM..

swapinfo -tam


Mb Mb Mb PCT START/ Mb
TYPE AVAIL USED FREE USED LIMIT RESERVE PRI NAME
dev 8192 0 8192 0% 0 - 1 /dev/vg00/lvol2
dev 8160 0 8160 0% 0 - 1 /dev/vg_sec_swap/lvol1
reserve - 14632 -14632
memory 16362 8034 8328 49%
total 32714 22666 10048 69% - 0 -


kmeminfo report .given below...


root #/home/tejas >./kmeminfo
tool: kmeminfo 7.10 - HP CONFIDENTIAL
unix: /stand/current/vmunix 11.23 64bit IA64 on host "vinayak"
core: /dev/kmem live
link: Tue Oct 20 12:32:29 EDT 2009
boot: Tue Dec 22 21:58:13 2009
time: Mon Mar 29 19:06:56 2010
nbpg: 4096 bytes


----------------------------------------------------------------------
Physical memory usage summary (in page/byte/percent):

Physical memory = 4188676 16.0g 100%
Free memory = 1888347 7.2g 45%
User processes = 967026 3.7g 23% details with -user
System = 1319995 5.0g 32%
Kernel = 901128 3.4g 22% kernel text and data
Dynamic Arenas = 526831 2.0g 13% details with -arena
M_TEMP = 147217 575.1m 4%
vx_buffer_kmcac = 139264 544.0m 3%
vx_global_kmcac = 88412 345.4m 2%
spinlock = 33550 131.1m 1%
vm_pfn2v_arena = 16630 65.0m 0%
Other arenas = 101758 397.5m 2% details with -arena
Super page pool = 86161 336.6m 2% details with -kas
Static Tables = 220180 860.1m 5% details with -static
pfdat = 98172 383.5m 2%
nbuf = 52608 205.5m 1% bufcache headers
vhpt = 32768 128.0m 1%
inode = 9526 37.2m 0%
bufhash = 8192 32.0m 0% bufcache hash headers
Other tables = 18913 73.9m 0% details with -static
Buffer cache = 418867 1.6g 10% details with -bufcache
UFC file mrg = 0 0.0 0%
UFC meta mrg = 0 0.0 0%



My question ias i ahd added this sec swap without -C option of lvcreate...
What impact will it have ...??
Also i would like to increase this to 24 GB nw...how do i do it ?? without reboot...???


Thanx in advance...

[Michael Steele_2]

without -C option of lvcreate...
What impact will it have ...??

Well what is the difference between sequential access and random access? An index of pointers found in random access but not found in sequential access that tell the O/S where to find the next in line.

In sequential, contiguous, the O/S assumes the next address follows in order.

So you'll have something like a memory segmentation fault when you cross over from one lvol into anothers and puke you box.

[Matti_Kurkela]

Your secondary swap is /dev/vg_sec_swap/lvol1, so you apparently created a new VG for it.

If you used only one PV to create this new VG, your swap LV fulfills the "contiguous" requirement by default, even though you did not request LVM to verify it. This is because LVM always allocates space contiguously as much as possible. With an empty VG that contains only one PV, the first created LV will be contiguous even if you don't explicitly request it. However, if you don't use the "-C y" option, there will be no guarantee that it will stay that way.

The -C y option states that the contiguousness is an *absolute requirement*: if set, the LVM will make sure that the LV will stay contiguous at all times, and will reject any operations that would make it non-contiguous.

You should do a "lvchange -C y /dev/vg_sec_swap/lvol1" now, to make sure there is no way to make the swap LV non-contiguous by accident. If this command is successful, you can be sure that the new swap LV was contiguous all along, and will be guaranteed to stay that way even if you make other changes to the VG.

If the above-mentioned lvchange command fails, the swap LV is *not* contiguous. In that case, the system will crash if it actually needs to use the non-contiguous part of the swap LV, so you should schedule a maintenance break as soon as possible to disable the mis-configured swap LV, then re-create it using the correct procedure.


An already-activated swap LV cannot be extended without a reboot: however, you can add *another* swap LV (or more) to get the desired total amount of swap.

MK

[Michael Steele_2]

HI

I will tend to agree with Matt, but with hold a pertcentage, if you added an new disk to /dev/vg_sec_swap/lvol1 and did a pvcreate.

I will not agree with Matt if never pvcreated.

Under the circumstances described by Matt, the O/S sees a random access lvol, looks for a INDEX of pointers and fails to find it.

Matt is assuming that the O/S's response will be to take the next address in sequence of a lvol marked random access and I don't know if that is the correct assumption.

I would have to refer it to an HP-UX internals specialist, or, perform the procedure as the Manufacturer has indicated.