swconfig and swinstall strange problem

[G V R Shankar]

Hi All,

I have installed QPK for 11.23 OS instaces. swinstall analysis didn't show any disk space problem, installation went thru fine. System was rebooted. While the system was coming up, it configuring the uncofigured filesets. It usually takes time and all of a sudden I saw /dev/vg00/lvol8 has no free extents. Server came up. Most of the patches were in Installed state, swconfig \* didnot work. I had to reignite the server, doubled /var and swinstall and swconfig went fine.

Could some one please explain me, why did /var became full, while it was confuguring the unconfigured filesets.

Thank You.

Ravi.

[James R. Ferguson · Accepted solution]

Hi Ravi:

I have never had this problem. I keep a generous amount of free space in '/var', however (> 50% at least). Before a patch upgrade, one thing I like to do is reclaim additional '/var' space by commiting superceded patches beforehand with 'swmodify -x patch_commit=true \*'. Another, choice is to run 'cleanup -c 1'.

That said, I suspect that as 'swconfig' ran, the previous verions of filesets delivered by your patch session were moved to '/var/adm/sw/save' to allow potential (sw)removal and rollback of the new patch's filesets should you need or desire. You must have been very close to "the edge" in terms of the space analysis and this and/or other server activity filled all of the free space in '/var'.

It's too bad that you had to recovery by re-Igniting, but it was good planning to have been able to do so. I'd be interested to know how large a patch bundle you installed, and what the free '/var' space was when you originally started.

Regards!

...JRF...

[Dennis Handly]

>why did /var became full, while it was configuring the unconfigured filesets.

You should report this issue to the Response Center. Ideally swinstall should be able to figure out the expected storage requirements but if a patch copies Mb into the patch save area during the configure step, it may not know about it. It may be accounted under /usr/newconfig/ instead of /var/.

If swinstall can't do this, then patches with 10s of Mbs of "hidden" disk space should be spelled out in the special installation notes.

>JRF: the previous versions of filesets delivered by your patch session were moved to /var/adm/sw/save

Typically this is done in the installation phase. But configure control scripts could also do this.

>I'd be interested to know how large a patch bundle you installed, and what the free /var space was when you originally started.

Right. And how much just before the reboot.

[G V R Shankar]

Hi,

Following o/p is from SysInfo
/var vxfs 7176192KB 6361864KB 808352KB 88%

The depot size was aroung 800MB.

Ravi.

[Steven E. Protter]

Shalom Ravi,

That is a pretty big depot.

I generally keep my large install depots themselves off the /var filesystem.

cd /var

du - k | sort -rn | more

This will point out the fat directory.

You may find some other surprises that help you manage /var

cleanup -c 1

Will clean up superseded patches from /var and save you a lot of space. It does prevent you from backing out the last patch set.

SEP

[Bob E Campbell]

Have you read the /var/adm/sw/swagent.log file? It should show what was running when the fault occurred. I assume it was not saved, but I would love to see it.

[G V R Shankar]

Hi,

Thank you very much for the responces. I have tried to simulate this in the LAB and it was found that that was /var was not full during analysis and install phase, but was at deadline. Very few extents were left and this has casued the problem.

Cheers,

Ravi.

[G V R Shankar]

Thanks again for all the responces.