[conspire] Estimating disk usage (Was: RHL 9 Install problems_

Heather Stern star at starshine.org
Tue Aug 12 13:04:01 PDT 2003


> After reading the first chapters of the RedHat Linux 9 Bible, I was
> thinking about creating the following partitions and mount points:
> 
> 2 GB /tmp
> 2 GB /var
> 8 GB /usr
> 5 GB /home
> `8 GB / (i.e. it get's what's left over)
 
I'm quite late to getting to this, and the problem was eventually
discovered as wicked memory, but I figured I'd expound on the art of 
drive partitioning, as it may be useful to many of us.  For those who
figure it's all old hat, maybe you can keep the note around for
installfesting.

> Is this reasonable for what I want to do?  Is this overly complicated, and I
> should just make one large partition?  TIA, anyone.

There are two major philosophies of disk partitioning - the "keep it
simple" model, and the "by usage" model which wants to apply different
security to different places.

The extreme form of the "keep it simple" philosophy is what I refer to
as One Big Slash - the same attitude that leads MSwin variants to just
call the whole thing C: and the hell with it.  A decent One Big Slash
setup also needs a swap partition.  To my mind it works better on
smaller drives where the sector size does not get big enough to insanely
waste a bunch of space.

Selecting a size for your swap partition is an art all on its own.
Here's the rulles that should do alright.   
  1. Don't give yourself less than 4 MB swap, even if you think you'll
     never need any.  Unless you're crafting an embedded system it is
     not worth the headache to assume you will -* never *- use swap.
  2. Try to estimate how many tasks are likely to be backgrounded, and
     the kind of memory they are likely to take.  That's a measure of
     likely swap usage.
  3. If you will be sometimes heavily abusing the memory, but mostly
     not, you may considering preparing an additional swapfile just 
     before you get hoggy.  Don't forget to add it to the usable swap
     with swapon, nor to free it with swapoff when it's no longer
     needed.
  4. If your heavy uses are not so predictable, plan for swap to be
     aproximately your memory plus enough to hold a fairly fat program
     you predictably use.  That'll give some clean space for the mem
     manager to do right things with.

In my opinion more is a waste of overhead, unless the system as a whole
does not have enough memory for normal services.  In which case I
gleefully offer my consulting services to shoehorn whatever you're
trying to do with the poor beastie into RAM that it really has.  For 
example, a 24 MB system just shouldn't run Gnome or K.  It'll barely
walk.  This doesn't mean you can't use gtk apps with a much lighter
weight WM nor that you can't have a nice little menu system.  It just
means trimming the fat will help a lot.

The "by usage" philosophy handles two things.  It allows you to mount
volumes with radically different permissions, and it allows you to limit
filespace use - without indulging in the gory mess known as userspace
quota.  The simplest example of this by far is merely to make sure a few
filesystems that might have something go nuts trying to fill them, don't
get to hog the drive.

On a mail server this will probably be /var/sppol mail and maybe
/var/log.... often simplified to just plain /var.   Beware that /var
contains your package managemenet setup and on Debian at least, also
contains apt's download area, so don't make it too small, or else get
used to the idea of doing your dist-upgrade 4 to 10 packages at a time.
I typically use 300 MB or bigger.

On a very busy workstation /tmp is likely to be a bleeder so it's worth
keeping seperate.   In my own usage, I open fairly chubby tarballs a
lot with MC, so bleeding or not bleeding, I like to have a decent size 
/tmp area.

Now the filesystem heirarchy standard stuff mumbles about /usr being
able to be made readonly and frankly, I find very few people do that.
But it may be handy to moutn it nodev.  /usr should be a big partition 
with spare space since new apps will install there.  I usually symlink 
/opt to /usr/opt or /usr/local.

On dual boot two-linux setups I have made a point of seperating
/usr/local - whether /usr is seperate from / or not - so that I keep
sources there, and locally build packages to be used by both distros
myself to be kept there.  This gets rid of "which mozilla am I using"
headaches.  Dual Linux sharing parts is definitely an advanced topic.
If you're willing to have the two distros utterly ignore each other,
they may as well be big-slash setups; they can safely share the
swapfile.  

My own baseline, assuming a fairly modern drive, is 
	/	minimum 200 MB, but usually 1G if I suspect /opt
		will be invoked.  None of the installers I've
		come across deal adequately with the idea that /opt
		belongs in /usr somewhere imho.
	/var	minimum 300 MB, unless I expect to hold news or mail
		spools or be a logserver
	* sometimes I will symlink /var/cache/apt/archives elesewhere

	/usr	mountable read-only but I don't usually bother
		2.5 Gb or more.  Lots more if a decent size disk
		though I don't think I've given more than 10G yet.
	* /opt I usually symlink to /usr/opt

	/tmp	can vary according to your usage - 150 MB will be 
		way plenty for some, for others, 512 M or a gig might
		suit.  It's gotta be writable though and if you're
		going for a read-only / as a goal, you must have one.
	/usr/local    if dual-linuxing, or if you outgrew an old 
		disk this is a good place to add and start getting
		things into.  e.g. /usr/src could be symlinked to
		/usr/local/src to releive the stress.
	/home	often on a seperate drive eventually.

The math works out well for a 6G drive or better and a modern distro.
But also consider that I can fit a very nice text mode debian into 
about 175 MB as a big-slash style,  and Red Hat 3.03 gave me a decent
GUI environment in about 528 MB with room to spare fod documents 
adn graphic bits.  So it really does depend what you need to do with a
box...

BTW I do personal installfests as consulting gigs, if anyone needs help
directly more often than the normal 'fests go.

  . | .   Heather Stern                  |         star at starshine.org
--->*<--- Starshine Technical Services - * - consulting at starshine.org
  ' | `   Sysadmin Support and Training  |        (800) 938-4078




More information about the conspire mailing list