[lug] Cleaning up /var when it gets too full
ed at eh3.com
Mon Sep 23 09:18:32 MDT 2002
On Mon, 2002-09-23 at 03:49, Sean Reifschneider wrote:
> On Wed, Sep 18, 2002 at 10:01:22PM -0600, Bear Giles wrote:
> >This may seem like a lot of effort, but experience shows that it
> >eliminates a *lot* of problems. It's a lot like that old commercial
I wholeheartedly disagree. Lots of partitions is lousy advice for
anyone other than experienced admins running servers--and *they*, by
definition, generally don't need the advice.
> Unfortunately, on systems without a nice LVM and online resizable
> filesystems, creating a bunch of partitions tends to create a lot more
> problems than it eliminates... Unless you have a really good idea up front
> what the high water mark of /var/tmp, /var/log, /var/spool, etc are, you're
> likely to run out of space in some of them while others have plenty to
IMNSHO, this *is* good advice! Absolutely!
I've seen numerous systems that were setup with a bunch of pointless
partitions. The folks (mostly newbies though some intermediates) then
had difficulty extracting themselves from the mess. In a few cases,
they switched to the "few-partitions" approach only after a disruptive
and time-wasting backup and re-install process. And all for what?
I have at many Ifests recommended the same three partitions as Sean
(/boot, /, /home) as it both allows one to easily boot with lilo and, at
some future point, quickly re-install the OS from scratch without
destroying the user data (/home). Since grub and recent lilo versions
have removed the 1024th-cyl booting limitation and since most distros
will now upgrade themselves relatively painlessly, there is less of a
need for a separate /boot and /home.
Edward H. Hill III, PhD
Post-Doctoral Researcher | Email: ed at eh3.com, ehill at mines.edu
Division of ESE | URLs: http://www.eh3.com
Colorado School of Mines | http://cesep.mines.edu/people/edhill.php
Golden, CO 80401 | Phone: 303-273-3483 Fax: 303-273-3311
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 232 bytes
Desc: This is a digitally signed message part
More information about the LUG