I asked about what patchadd was doing to fill my root filesystem. While I did
get enough information to answer my questions, I am sorry I left out a few
details that might have made it much easier to answer them:
1. The OS is Solaris 2.6 (some guessed from my reference to patchadd rather than
installpatch).
2. /var is contained in the / partition, and /tmp has its own partition (well, a
tmpfs shared with swap)... (more on that in a moment).
3. The system is an Ultra-2 dual cpu with a pair of internal 4.2gig disks (and 4
2.1gig disks I added today, with these split between two controllers), all
7200rpm Ultra-Wide SCSI.
The primary answer to my question is that when patches are added, the files
needed to remove them is stored in /var/sadm/pkg, with other info on each patch
in /var/sadm/patch.
A couple of people pointed out it is possible to pass an argument to patchadd to
inhibit saving uninstall information. I don't want to do that, as I have in the
past had to de-install bad patches and the system in question is my primary
server.
One person pointed to the various log files in /var as a potential culprit. In
my case, the problem was specifically occuring during patching, and thus was not
the log files. I have in the past observed that my wtmp and wtmpx files are
getting large, and that I should put some process in place to keep them from
growing out of control, but this is not causing my current problems.
RESOLUTION:
The resolution to this problem is to move /var/sadm to a partition with more
space. One reason for my question to this list was to determine if it was safe
to move this subtree to a different partition and leave behind a symbolic link.
I believe I got enough "yes" answers to go ahead and do this.
An important issue of filesystem partitioning philosophy was raised in some of
the replies. Some people suggested that one should always configure a seperate
partition for /var. While I agree that /var does not belong in the / (root)
filesystem, I also do not believe it should use its own partition. I wish Sun
would "fix" its install tools to allow more flexibility in specifying how
filesystems and partitions are laid out. Currently, the only choices for /opt,
/var and /usr are to have them share / (root) or live on their own partition. I
find I have far more success when I minimize the number of partitions, but
ensure that /opt, /var and /usr do not reside on root (root must be kept small
to keep boot times fast). The more partitions used, the more the free space on
your disk gets fragmented, and the more often one partition runs out of space
while plenty of space is available on a different partition. Even in these days
of very large and relatively inexpensive disks, the more partitions one uses,
the more often you get caught in the free space in the wrong location dilemna.
Thus, I routinely move /opt to /usr/opt leaving behind a link in root. And I
will be doing the same thing for /var/sadm (I probably will evolve to moving all
of /var but /var/sadm is good enough for the moment). I only wish I could
designate this scheme at system install time. The system in question, my one and
only Solaris 2.6 system right now, happens to have seperate /opt and /usr
partitions due to limits in the installer. The /var filesystem was not given its
own partition, due to my desire to reduce free space fragmentation, but hasn't
been moved off / (root) yet. I haven't decided which of these is the best home
for /var/sadm. I'll probably choose /usr and move to an other if I find I'm
running out of space.
My thanks to:
LINDA S GEE <u2is9lsg@lindasun.crrel.usace.army.mil>
Rahul Roy <uroy@eadev1.vanguard.com>
Colin_Melville@mastercard.com
Andrew M Townsend <ATOWNSEND@DOLETA.GOV>
Richard J Niziak <rickn@ziplink.net>
kmckinla@kan.lmcda.lmco.com (Ken McKinlay)
Nikos George <nikos@jimmy.harvard.edu>
plw@ncgr.org (Peter L. Wargo)
James.E.Coby.Jr@cdc.com (James Coby)
Karl Vogel <vogelke@c17mis.region2.wpafb.af.mil>
Peter Polasek <pete@cobra.brass.com>
Tim Evans <tkevans@eplrx7.es.dupont.com>
Chris Marble <cmarble@orion.ac.hmc.edu>
Steven Aizic <steven@yucc.yorku.ca>
David Thorburn-Gundlach <david@bae.uga.edu>
"Dwight Peters" <dpeters@nswc.navy.mil>
ms148@chrysler.com
-Marc
Marc S. Gibian
COMSYS Information Technology Services phone: (781) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
or is it: gibian@hanscom.af.mil
well, maybe: gibianm@hanscom.af.mil
and if all else fails: marc.gibian@acm.org
--Boundary_(ID_CKunqOk2d7RsQa86hG+O3g)
Content-type: MESSAGE/RFC822
Content-description: Mailbox
Content-MD5: Cuj8ZCMNwDKpRt4PngKJOA==
X-Sun-Data-type: mail-message
Return-path: <sun-managers-relay@ra.mcs.anl.gov>
Received: from stars1.hanscom.af.mil by drizzle.tfs.com (SMI-8.6/SMI-SVR4)
id OAA02456; Thu, 9 Apr 1998 14:30:04 -0400
Received: from smtpgw.hanscom.af.mil by stars1.hanscom.af.mil
(SMI-8.6/SMI-SVR4) id OAA07551; Thu, 9 Apr 1998 14:26:15 -0400
Received: from ra.mcs.anl.gov (ra.mcs.anl.gov [140.221.9.21])
by smtpgw.hanscom.af.mil (8.8.8/8.8.8) with ESMTP id OAA07689; Thu,
9 Apr 1998 14:31:17 -0400 (EDT)
Received: from localhost (daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
with SMTP id NAA04298; Thu, 9 Apr 1998 13:21:20 -0500 (CDT)
Received: by ra.mcs.anl.gov (bulk_mailer v1.5); Thu, 9 Apr 1998 13:20:31 -0500
Received: (from daemon@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
id MAA04184 for sun-managers-outbound; Thu, 9 Apr 1998 12:37:08 -0500 (CDT)
Received: (from listserv@localhost) by ra.mcs.anl.gov (8.8.3/8.8.3)
id MAA04171 for smmsgs-out; Thu, 9 Apr 1998 12:37:01 -0500 (CDT)
Received: from smtpgw.hanscom.af.mil (smtpgw.hanscom.af.mil [129.53.1.252])
by ra.mcs.anl.gov (8.8.3/8.8.3) with ESMTP id MAA04149 for
<sun-managers@ra.mcs.anl.gov>; Thu, 9 Apr 1998 12:35:52 -0500 (CDT)
Received: from stars1.hanscom.af.mil (stars1.hanscom.af.mil [129.53.46.10])
by smtpgw.hanscom.af.mil (8.8.8/8.8.8) with SMTP id NAA00426 for
<sun-managers@ra.mcs.anl.gov>; Thu, 9 Apr 1998 13:39:26 -0400 (EDT)
Received: from drizzle.tfs.com by stars1.hanscom.af.mil (SMI-8.6/SMI-SVR4)
id NAA07069; Thu, 9 Apr 1998 13:34:20 -0400
Received: from hail.tfs.com by drizzle.tfs.com (SMI-8.6/SMI-SVR4)
id NAA02335; Thu, 9 Apr 1998 13:38:07 -0400
Received: by hail.tfs.com (SMI-8.6/SMI-SVR4) id NAA01287; Thu,
9 Apr 1998 13:35:43 -0400
Date: Thu, 9 Apr 1998 13:35:43 -0400
From: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Subject: patchadd filling up root (/) filesystem
Sender: sun-managers-relay@ra.mcs.anl.gov
To: sun-managers@ra.mcs.anl.gov
Reply-to: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Message-id: <199804091735.NAA01287@hail.tfs.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Content-MD5: kgup0my+qG9ThZFAy+FDzg==
Precedence: bulk
Content-length: 834
>From gibian@stars1.hanscom.af.mil Thu Apr 9 14:30:05 1998
Followup-to: gibian@stars1.hanscom.af.mil (Marc S. Gibian)
Status: RO
I have noticed that the root filesystem on the workstations I administer slowly
fills up for reasons I have not been able to track. Today I applied a 35MB patch
and noticed it consumed a huge chunk of root, even though all of the files it
was patching live on other file systems.
Am I right that this space is being consumed by part of the patching mechanism?
Where is this space being consumed?
Can I safely move the relevent subtree to a different filesystem and leave a
symbolic link behind?
TIA,
Marc
Marc S. Gibian
COMSYS Information Technology Services phone: (781) 377-6350
PRISM/TFS email: gibian@stars1.hanscom.af.mil
or is it: gibian@hanscom.af.mil
well, maybe: gibianm@hanscom.af.mil
and if all else fails: marc.gibian@acm.org
--Boundary_(ID_CKunqOk2d7RsQa86hG+O3g)--