Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

tlug: Partitioning sizes



>>>>> "Dave" == Dave Gutteridge <dave@example.com> writes:

    Dave> I'm finally going to set up my own Linux Machine, seperate
    Dave> from the machine that i've been using so far from my
    Dave> office. As i'm sure everyone always does with every new
    Dave> task, I'm telling mysefl "This time i'm going to do it
    Dave> really, REALLY right!"

:-)

FWIW, here's my df:

steve@example.com:VM$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hdb1                19485     12871      5608  70% /
/dev/hdb3               495746    452131     18012  96% /usr
/dev/hdb5                99507     38392     55976  41% /var
/dev/hdb6               495714    366877    103236  78% /usr/local
/dev/hdb7               148319    136598      4062  97% /home
/dev/hdb8               673217    621966     16477  97% /playpen

Now, that's a LOT more than 1.2 GB but note the /usr/local and
/playpen mounts.  /playpen is my development area, and has two full
XEmacs source trees, one full Emacs tree, and a kernel tree or two;
/usr/local used have that in it and now has miscellaneous students'
stuff.  You can ignore them for your application ;-)

I have a lot of extra stuff in /usr/doc (rfcs, etc) that most people
won't have.  You should consider consolidating that kind of shared
data using NFS (or CODA, eventually).  Keep docs on your road warrior
(that's where the hard remote debug jobs are going to come up---you
been there, done that already, ne?)

Unless you're going to put the GIMP or Applix on that box, 512MB for
/usr should be enough.

    Dave> The Red Hat 5.2 Manual says i should partition thusly:

Burn those pages.

    Dave> 64MB swap

This machine is a server, not a workstation, right?  If so, I'd say
2MB swap for every 1MB RAM up to 64MB swap.  (That's a little dated, I 
haven't really paid attention to this for a couple years.)

    Dave> 16MB /boot

Huh?  I have no idea why they'd suggest this.  I've only got 90kB in
boot.  Put a couple kernels in there and it might go to 2MB.

    Dave> 256MB /

I don't see any reason for more than 50MB, and that only for
TurboLinux.  For Debian systems I pretty much stick to 25MB.  Take
two, they're small.  Every time you're about to do something stupid
(install a new kernel, upgrade to a new libc, etc) that could hose
your system, do

		     dd if=/dev/hda1 of=/dev/hda2

Then with a proper lilo configuration you'll always have a bootable
system, subject to no hardware failures on /dev/hda2.  (Requires
keyboard, sorry, but if you need this, a keyboard will be cheap.)

    Dave> 512MB /usr 

This is plenty for a Debian development system or any non-development
TurboLinux system.  I dunno Redhat, but it should be plenty.

    Dave> 512MB /home

Pure fat for your application.  But see discussion of servers, below.

    Dave> 256MB /var

Pure fat for your application.  But see discussion of servers, below.

    Dave> What differs from the last time when I set up the machine at
    Dave> work is that I'm I'm going to be the only user of this new
    Dave> system, so i'm suspecting i can reduce /home or /usr, but
    Dave> i'm not sure which of the two should be given priority.

/usr, probably; that's where applications will go.

    Dave> Also, since a big part of this machine's purpose is to do
    Dave> mail services (albeit only for me at this point), should I
    Dave> increase /var?

No.  I have about 10 users on another box who mostly leave their mail
in the spool (they've been warned, their suicidal tendency is not my
problem).  Never goes above 20MB.  Unless you expect to be sending
receiving mailbombs, aka Word attachments, or multimedia attachments
on a regular basis, allowing 20MB for a single user's spool files is
plenty.  You can even skimp on that by using procmail to filter large
mails into a holding tank elsewhere.

You _do_ have to consider archival storage.  What do you do with the
mail?  Read and delete?  or Read and file?  If the latter, you need to 
increase the size of /home.

    Dave> Just in case it will affect the answers - the machine is for
    Dave> web pages (no streaming audio or video but multiple domain
    Dave> names), FTP (no anonymous) and mail (me with multiple
    Dave> accounts and one mailing list) only.

Where does RedHat put $WWWRoot and $FTPRoot?  Debian puts them in
/var/www, with the obvious implications for the size of /var.
Exercise for the reader.  I disagree with this in principle (but I'm
too lazy to bother changing it), because I think that /var should be
programs' scratch storage, projects like your Web page and so on
should live in /home.

Ah, is there gonna be a printer hooked to this machine?  The natural
unit for HP laserjet spool files generated by Ghostscript is `MB';
I've seen 40MB files in my /var/spool/lp.

The idea is that everything that a human sweats over is under /home so
you always back it up.  The root partition gets backed up, since /etc
is there.  Some of /var needs backed up (/var/spool/mail in
particular) unfortunately, but I prefer to minimize that.

>>>>> "Stephen" == Stephen Carter <carter@example.com> writes:

    Stephen> I've found the "advice" in both the Red Hat and the SUSE
    Stephen> manuals pretty confusing, and when followed, doesn't put
    Stephen> enough space in some of the partitions to load the

"One size gives all fits."

    Stephen> modules specified, and forces me to start over again--and
    Stephen> using Disk Druid isn't exactly the quickest thing in the
    Stephen> world!

symlinks are a lazy man's friend.  Make a directory where you do have
space, move stuff there, and symlink it into the right place.  Don't
tell anybody I told you that was ok, though.

    Stephen> While I understand that the sizes of the various file
    Stephen> systems are going to vary depending on use, personal
    Stephen> needs, etc., can someone suggest a reference or two, or
    Stephen> perhaps have some insight on laying out file systems?

Most of the distributions are File System Standard (FSSTND), now File
Hierarchy Standard (FHS), conformant.  Get this at any Linux site.  On
Debian systems you find them in /usr/doc/debian-policy/.  This
explains the rationale for the usual installation of files in certain
directories.

Unfortunately, the only way to figure these things out is by
experience.  None of the package systems tell you how big the various
files are.  However, in general nearly _all_ of the expanded size of
the packages goes under /usr.  So decide what packages you need, ask
dpkg or rpm how big their contents are, add it up, and multiply by 1.2 
because you know you are going to miss 20% of the dependencies.

Sorry, I haven't written the script to do this.

>>>>> "Dmytro" == Dmytro Kovalev <kovald@example.com> writes:

    Dmytro> Just personal opinion: I prefer to have separate /tmp and
    Dmytro> in this case 256 for / seems to much. What I have usually
    Dmytro> is something like:

This is a _good_ idea (although I don't do it myself).

One caveat:  you need to be careful that your init sequence does not
set up any files in /tmp that will proceed to disappear when you mount 
the /tmp partition.  Eg, the X server puts its Unix domain sockets
there.  So you may need to special case the mount of /tmp.

I have an overly large /var partition, so I set TMPDIR=/var/tmp in my
environment.  Most programs respect this, so it works for me.  Caveat:
automatic cleanup policies for /tmp and /var/tmp vary by installation,
so YMMV.

    Dmytro> /     40-50
    Dmytro> /tmp ~100
    Dmytro> /var 40-50

Looks right to me.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."
-------------------------------------------------------------------
Next Technical Meeting: February 13 (Sat), 12:30 place: Temple Univ.
** presentation: XEmacs, by Steven Baur and Martin Buchholz
Next Nomikai: March 19 (Fri), 19:30   Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links