Freeing up space in /var

The following is now published as Infodoc 208057:

To whom it may concern,

Over time, customers may experience space issues in /var as patch "undo" and "obsolete" data, which is stored for use during patch backout, builds up as more patches are applied to the system.

It is best to plan for this expansion of /var in advance,  and allocate plenty of free space to this partition. 

How much space to allocate to /var depends on a number of variables, such as how many patches are likely to be applied to the system, which is dependent on frequency of patching, strategy of which patches will be applied (all, sun alert, security only, etc.), products patched; whether the system has zones which implies 'pspool' space requirements, etc.  A figure of 10Gb to 20Gb or even more is not unreasonable.   In my Patch System Test lab, we currently have Solaris 10 systems with >7GB used in /var and this will continue to grow over the lifetime of Solaris 10.

If you have insufficient space in /var of an existing system, the recommended solution is to extend the size of the /var partition.  This can be accomplished by backing up /var, creating a bigger /var partition on another disk, restoring the /var backup onto that partition and then updating the /var entry in the /etc/vfstab file.  If /var is part of the "/" (root) partition, then relocating /var to a separate partition would be a good solution.  The relocation process is documented in Infodoc 215988.

Sun strongly discourages manual modifications to the /var/sadm/pkg directory and its file structure.  That directory structure should only be modified by the Solaris[TM] patching and packaging utilities.  Corruption in this directory structure will prevent any future packaging or patching operations.

Below is information on how to free up space in /var by deleting certain patch related files.  This should only be used when there are no other ways of gaining space in /var.

Having a full and current backup of the OS is highly recommended before deleting files from /var.

On behalf of Sun Microsystems, I hereby confirm that unneeded "obsolete" and "undo" files may be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> and "undo" files from the /var/sadm/pkg/<pkgname>/save/pspool/<pkgname>/save/<PatchID> directories in order to free up space in /var.

This will not invalidate support contracts.

The "undo" files are used during the patch removal process. Removing the "undo" files associated with a patch means that it will no longer be possible to uninstall the patch.

Once a later revision of a patch is applied, or a patch which obsoletes a patch is applied, the "undo" files in /var/sadm/pkg/<pkgname>/save/<PatchID> are renamed "obsolete".  These "obsolete" files may also be removed.

It is strongly recommended to only remove the "obsolete" and "undo" files for patches which the customer is confident will not need to be backed out - for example rejuvenated Kernel patches associated with Solaris 10 Update releases such as 118833-36 (SPARC) / 118855-36 (x86), 120011-14 (SPARC) / 120012-14 (x86), etc. and other older Kernel patch revisions.  See the sequence of Solaris 10 Kernel PatchIDs listed on http://blogs.sun.com/patch/date/20080416

As patches containing subsequent fixes to the objects contained in these rejuvenated patches will have a SUNW_REQUIRES dependency on the these rejuvenated patches, it's extremely unlikely that older versions of these rejuventated Kernel patches will ever be backed out.   Therefore, their "undo" files are prime candidates for removal to free up space in /var if required and it's not possible to extend /var.

All the "undo" or "obsolete" files for a particular patch should be removed from the /var/sadm/pkg/<pkgname>/save/<PatchID> directories. For example:

rm /var/sadm/pkg/\*/save/118833-36/undo\*

The system also keeps a copy of "undo" files for use during creation of new non-global zones. These may also be removed if the customer is confident that the patches will not need to be backed out. For example:

rm /var/sadm/pkg/\*/save/pspool/\*/save/118833-36/undo\*

The "undo" files in the pspool directory are not renamed to "obsolete" when a later revision is installed.

Further Information:

  1. The "undo" files are specific to the zone of the system on which they were created during application of a patch by patchadd. Therefore, do not copy the "undo" file from one zone to another or from one system to another.

  2. One could potentially archive the "undo" files for each zone of a system and restore it to that zone if desired.

Best Wishes,

Gerry Haskins
Director, Software Patch Services

Comments:

I hate to be a pest, but this sounds like excellent fodder for an Infodoc. :)

Even if you think you may need to back out those patches at some time in the future, you should be able to so long as you have a backup of them. Something like the following (untested) should do the trick:

Make a backup copy

# find /var/sadm/pkg -name undo.Z -o -name obsolete.Z | cpio -pdv /net/my4500/backout/`uname -n`

Free up space in /var

# find /var/sadm/pkg -name undo.Z -o -name obsolete.Z | xargs rm -f

In the event that you need to back out patch 999999-01:

# cd /net/my4500/backout/`uname -n`
# find var/sadm/pkg | grep 999999-01 | cpio -pdv /
# patchrm 999999-01

My typical strategy around this is to only clear out patch backout information that is old enough that it is very unlikely that I would ever back out to it.

# find /var/sadm/pkg -name undo.Z -mtime +180 | xargs rm -f

I've never noticed the obsolete.Z files as a space hog, so I haven't pruned them.

The same problem can bite you on each zone as well.

Posted by Mike Gerdts on January 21, 2009 at 08:27 AM GMT #

Hi Mike!

For once I'm actually ahead of you!

I've asked for Infodoc 208057, http://sunsolve.sun.com/search/document.do?assetkey=1-61-208057-1, to be updated with the text of the above posting.

A referenced Infodoc will also be updated to reflect a modern S10 /var value and an obsolete Infodoc will be deleted.

Best Wishes,

Gerry.

Posted by Gerry Haskins on January 21, 2009 at 09:08 AM GMT #

Hi Mike!

Infodoc 208057, http://sunsolve.sun.com/search/document.do?assetkey=1-61-208057-1, has been updated with the text of the above posting.

Best Wishes,

Gerry.

Posted by Gerry Haskins on January 22, 2009 at 06:56 AM GMT #

Thanks!

Posted by Mike Gerdts on January 22, 2009 at 07:27 AM GMT #

Hi Mike, Hi Gerry,

I would suggest if undo.Z and obsolete.Z should be removed from the system, then store an md5 checksum for each of the files before deletion and store them on the machine and somewhere else.

Imagine a Datacenter with important systems, using a md5sum for verification could use that additional security the undo.Z and obsolete.Z restored from <tape|nfs|ftp|\*> are from \*this\* specific machine and are complete and valid.

For retire or "committing" patches (like that term much) I would suggest, that swapping out old undo.Z and obsolete.Z should be aligned with exactly that list of patches that are contained in the patchcluster which has been used some months/weeks before (see the saved patch_order list) and then name the archive with that patchclustername+date. That would make life easy.

As a suggestion, one could search the list of undo.Z and obsolete.Z by using the old patch_order file containing the patch-ids.

Thomas

Posted by Thomas Wagner on January 22, 2009 at 08:24 AM GMT #

Hi,
Unfortunantly, none of the links mentioned are active today:

"The relocation process is documented in Infodoc 215988"
nor
http://sunsolve.sun.com/search/document.do?assetkey=1-61-208057-1

Please advise.

Wilian

Posted by wilian on February 15, 2014 at 04:12 PM GMT #

Hi Wilian,

Apologies for my delay in responding.

SunSolve Infodoc 208057 has been migrated to MOS (My Oracle Support) Doc 1005804.1.

SunSolve Infodoc 215988 has been migrated to MOS Doc 1011662.1.

In general, to find migrated Sun docs on MOS, login to support.oracle.com, click on the "Knowledge Base" tab, and enter the old Sun doc id into the top search pane, and it'll usually return the correct migrated doc.

I'll update the post to reflect the MOS Doc IDs.

Best Wishes,

Gerry.

Posted by Gerry on July 04, 2014 at 03:07 PM IST #

Hmmm, apparently the posting is so old, I'm not able to edit it any more.

But Docs 1005804.1 and 1011662.1 on My Oracle Support, support.oracle.com, are the correct ones.

Best Wishes,

Gerry.

Posted by Gerry on July 04, 2014 at 03:34 PM IST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This blog is to inform customers about patching best practice, feature enhancements, and key issues. The views expressed on this blog are my own and do not necessarily reflect the views of Oracle. The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect these plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material code, or functionality, and SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISIONS. The development, release, and timing of any features or functionality described remains at the sole discretion of Oracle. THIS INFORMATION MAY NOT BE INCORPORATED INTO ANY CONTRACTUAL AGREEMENT WITH ORACLE OR ITS SUBSIDIARIES OR AFFILIATES. ORACLE SPECIFICALLY DISCLAIMS ANY LIABILITY WITH RESPECT TO THIS INFORMATION. ~~~~~~~~~~~~ Gerry Haskins, Director, Software Lifecycle Engineer

Search

Categories
Archives
« May 2015
MonTueWedThuFriSatSun
    
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
       
Today