On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) has gotten way out of hand due to the remarkably large growth of /var/sadm. Can this directory tree be safely moved to a zfs filesystem? How much of /var can be moved to a zfs filesystem without causing boot or runtime issues? Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On Sat, May 31, 2008 at 5:16 PM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote:> On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) > has gotten way out of hand due to the remarkably large growth of > /var/sadm. Can this directory tree be safely moved to a zfs > filesystem? How much of /var can be moved to a zfs filesystem without > causing boot or runtime issues?/var/sadm is not used during boot. If you have been patching regularly, you probably have a bunch of undo.Z files that are used only in the event that you want to back out. If you don''t think you will be backing out any patches that were installed 90 or more days ago the following commands may be helpful: To understand how much space would be freed up by whacking the old undo files: # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs du -k \ | nawk ''{t+= $1; print $0} END {printf("Total: %d MB\n", t / 1024)}'' Copy the old backout files somewhere else: # cd /var/sadm # find pkg -mtime +90 -name undo.Z \ | cpio -pdv /somewhere/else Remove the old (90+ days) undo files # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs rm -f Oops, I needed those files to back out 123456-01 # cd /somewhere/else # find pkg -name undo.Z | grep 123456-01 \ | cpio -pdv /var/sadm # patchrm 123456-01 Before you do this, test it and convince yourself that it works. I have not seen Sun documentation (either docs.sun.com or sunsolve.sun.com) that says that this is a good idea - but I haven''t seen any better method for getting rid of the cruft that builds up in /var/sadm either. I suspect that further discussion on this topic would be best directed to install-discuss at opensolaris.org or sun-managers mailing list (see http://www.sunmanagers.org/). -- Mike Gerdts http://mgerdts.blogspot.com/
I think you''ll find that any attempt to make zones (certainly whole root ones) will fail after this. Jim --- Mike Gerdts wrote:> On Sat, May 31, 2008 at 5:16 PM, Bob Friesenhahn > <bfriesen at simple.dallas.tx.us> wrote: > >> On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) >> has gotten way out of hand due to the remarkably large growth of >> /var/sadm. Can this directory tree be safely moved to a zfs >> filesystem? How much of /var can be moved to a zfs filesystem without >> causing boot or runtime issues? >> > > /var/sadm is not used during boot. > > If you have been patching regularly, you probably have a bunch of > undo.Z files that are used only in the event that you want to back > out. If you don''t think you will be backing out any patches that were > installed 90 or more days ago the following commands may be helpful: > > To understand how much space would be freed up by whacking the old undo files: > > # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs du -k \ > | nawk ''{t+= $1; print $0} END {printf("Total: %d MB\n", t / 1024)}'' > > Copy the old backout files somewhere else: > > # cd /var/sadm > # find pkg -mtime +90 -name undo.Z \ > | cpio -pdv /somewhere/else > > Remove the old (90+ days) undo files > > # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs rm -f > > Oops, I needed those files to back out 123456-01 > > # cd /somewhere/else > # find pkg -name undo.Z | grep 123456-01 \ > | cpio -pdv /var/sadm > # patchrm 123456-01 > > Before you do this, test it and convince yourself that it works. I > have not seen Sun documentation (either docs.sun.com or > sunsolve.sun.com) that says that this is a good idea - but I haven''t > seen any better method for getting rid of the cruft that builds up in > /var/sadm either. > > I suspect that further discussion on this topic would be best directed > to install-discuss at opensolaris.org or sun-managers mailing list (see > http://www.sunmanagers.org/). > >
On Sat, May 31, 2008 at 7:37 PM, Jim Litchfield at Sun <James.Litchfield at sun.com> wrote:> I think you''ll find that any attempt to make zones (certainly whole root > ones) will fail after this.In no way am I speaking authoritatively on this (I really wish all the install, lu, patch code was open...), but are you perhaps confusing the patch backout data with the CAS and and modifiable (e, v) files that have pristine values stashed under /var/sadm/pkg/<pkgname>/save/pspool/<pkgname>? My understanding was that files of type f are installed into non-global zones by copying the file from the installed location in the global zone. So as to not pick up changes that occurred to editable (e - e.g. /etc/passwd) and volatile (v - e.g. /var/adm/messages) in the global zone, the pristine copy is picked up from pspool directories I mention above. To try things out, let''s play with alternate root installation of studio 11 at /opt/studio11 - on ZFS. Playing is best done on clones... zfs snapshot pool0/opt/studio11 at junk zfs clone pool0/opt/studio11 at junk pool0/junk I have patch 121015-06 installed - which patches SPROcc. It was installed with "patchadd -R /opt/studio11 -M `pwd` *" with several patches in the cwd while running the command. The contents of /pool0/junk/var/sadm/pkg/SPROcc look like: var/sadm/pkg/SPROcc var/sadm/pkg/SPROcc/install var/sadm/pkg/SPROcc/install/copyright var/sadm/pkg/SPROcc/install/depend var/sadm/pkg/SPROcc/pkginfo var/sadm/pkg/SPROcc/save var/sadm/pkg/SPROcc/save/121015-06 var/sadm/pkg/SPROcc/save/121015-06/undo.Z var/sadm/pkg/SPROcc/save/pspool var/sadm/pkg/SPROcc/save/pspool/SPROcc var/sadm/pkg/SPROcc/save/pspool/SPROcc/install var/sadm/pkg/SPROcc/save/pspool/SPROcc/install/copyright var/sadm/pkg/SPROcc/save/pspool/SPROcc/install/depend var/sadm/pkg/SPROcc/save/pspool/SPROcc/pkginfo var/sadm/pkg/SPROcc/save/pspool/SPROcc/pkgmap var/sadm/pkg/SPROcc/save/pspool/SPROcc/save var/sadm/pkg/SPROcc/save/pspool/SPROcc/save/121015-06 var/sadm/pkg/SPROcc/save/pspool/SPROcc/save/121015-06/undo.Z I back out the patch (patchrm -R /pool0/junk 121015-06), then reinstall it without backout info (patchadd -R /pool0/junk -d 121015-06). Things have changed to... var/sadm/pkg/SPROcc var/sadm/pkg/SPROcc/install var/sadm/pkg/SPROcc/install/checkinstall var/sadm/pkg/SPROcc/install/copyright var/sadm/pkg/SPROcc/install/depend var/sadm/pkg/SPROcc/install/patch_checkinstall var/sadm/pkg/SPROcc/install/patch_postinstall var/sadm/pkg/SPROcc/pkginfo var/sadm/pkg/SPROcc/save var/sadm/pkg/SPROcc/save/pspool var/sadm/pkg/SPROcc/save/pspool/SPROcc var/sadm/pkg/SPROcc/save/pspool/SPROcc/install var/sadm/pkg/SPROcc/save/pspool/SPROcc/install/copyright var/sadm/pkg/SPROcc/save/pspool/SPROcc/install/depend var/sadm/pkg/SPROcc/save/pspool/SPROcc/pkginfo var/sadm/pkg/SPROcc/save/pspool/SPROcc/pkgmap Notice the lack of undo.Z files (and associated patch directories), but the rest looks the same. -- Mike Gerdts http://mgerdts.blogspot.com/
Jim Litchfield at Sun wrote:> I think you''ll find that any attempt to make zones (certainly whole root > ones) will fail after this. >right, zoneadm install actually copies in the global zones undo.z into the local zone, so that patchrm of an existing patch will work. haven''t tried out what happens when the undo is missing, but zoneadm install actually copies the undo from /var/sadm/pkg/SUNWcsr/save/pspool/SUNWcsr/save/<patch-id>/undo.z above example for just SUNWcsr. BTW the undo under pspool is identical to the one in /var/sadm/pkg/SUNWcsr/save/<patch-id>/undo.z ( obvious waste of space really ) so one solution based on Mike''s would be to create a symlink in the pspool save/<patch-id> for each undo.z being moved. Note I have not tested any of this out so beware :-) Enda> Jim > --- > Mike Gerdts wrote: > >> On Sat, May 31, 2008 at 5:16 PM, Bob Friesenhahn >> <bfriesen at simple.dallas.tx.us> wrote: >> >> >>> On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) >>> has gotten way out of hand due to the remarkably large growth of >>> /var/sadm. Can this directory tree be safely moved to a zfs >>> filesystem? How much of /var can be moved to a zfs filesystem without >>> causing boot or runtime issues? >>> >>> >> /var/sadm is not used during boot. >> >> If you have been patching regularly, you probably have a bunch of >> undo.Z files that are used only in the event that you want to back >> out. If you don''t think you will be backing out any patches that were >> installed 90 or more days ago the following commands may be helpful: >> >> To understand how much space would be freed up by whacking the old undo files: >> >> # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs du -k \ >> | nawk ''{t+= $1; print $0} END {printf("Total: %d MB\n", t / 1024)}'' >> >> Copy the old backout files somewhere else: >> >> # cd /var/sadm >> # find pkg -mtime +90 -name undo.Z \ >> | cpio -pdv /somewhere/else >> >> Remove the old (90+ days) undo files >> >> # find /var/sadm/pkg -mtime +90 -name undo.Z | xargs rm -f >> >> Oops, I needed those files to back out 123456-01 >> >> # cd /somewhere/else >> # find pkg -name undo.Z | grep 123456-01 \ >> | cpio -pdv /var/sadm >> # patchrm 123456-01 >> >> Before you do this, test it and convince yourself that it works. I >> have not seen Sun documentation (either docs.sun.com or >> sunsolve.sun.com) that says that this is a good idea - but I haven''t >> seen any better method for getting rid of the cruft that builds up in >> /var/sadm either. >> >> I suspect that further discussion on this topic would be best directed >> to install-discuss at opensolaris.org or sun-managers mailing list (see >> http://www.sunmanagers.org/). >> >> >> > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
On Sun, Jun 1, 2008 at 3:53 AM, Enda O''Connor <Enda.Oconnor at sun.com> wrote:> Jim Litchfield at Sun wrote: >> >> I think you''ll find that any attempt to make zones (certainly whole root >> ones) will fail after this. >> > > right, zoneadm install actually copies in the global zones undo.z into the > local zone, so that patchrm of an existing patch will work. > > haven''t tried out what happens when the undo is missing,My guess it works just fine - based upon the fact that "patchadd -d" does not create the undo.z file. Admittedly, it is sloppy to just get rid of the undo.z file - the existence of the other related directories is (save/<patchid>) may trip something up. -- Mike Gerdts http://mgerdts.blogspot.com/
> On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) > has gotten way out of hand due to the remarkably large growth of > /var/sadm. Can this directory tree be safely moved to a zfs > filesystem? How much of /var can be moved to a zfs filesystem without > causing boot or runtime issues?It seems your original question hasn''t been answered yet... :-) I have used U4 with the complete /var on zfs for quite a while and have not encountered any problems. My usual setup for mirrored root disks is: what where how / /dev/md/dsk/d0 ufs swap /dev/md/dsk/d1 swap ROOT cXt0d0s3 + cXt1d0s3 zpool The ROOT pool contains /var, /opt, and /export. I set both quota and reservation for /var to be on the safe side. I have not done any stress testing with zones, but normal use is absolutely trouble-free. HTH -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45 Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
Volker A. Brandt wrote:>> On my heavily-patched Solaris 10U4 system, the size of /var (on UFS) >> has gotten way out of hand due to the remarkably large growth of >> /var/sadm. Can this directory tree be safely moved to a zfs >> filesystem? How much of /var can be moved to a zfs filesystem without >> causing boot or runtime issues? >> > > It seems your original question hasn''t been answered yet... :-) > > I have used U4 with the complete /var on zfs for quite a while and > have not encountered any problems. My usual setup for mirrored root > disks is: > > what where how > > / /dev/md/dsk/d0 ufs > swap /dev/md/dsk/d1 swap > ROOT cXt0d0s3 + cXt1d0s3 zpool > > The ROOT pool contains /var, /opt, and /export. I set both quota > and reservation for /var to be on the safe side. > > I have not done any stress testing with zones, but normal use > is absolutely trouble-free. > > >I guess you''ve never tried a (live) upgrade on that setup! Ian