Dazed and Confused about Partitioning Drives
Pete Peters
>>> snipped it all, lol <<<
I agree, very interesting thread, and, as another newbie, one I have
pestered my more experienced Linux friends with. Another advantage to just /
and /swap is not worrying how many and how large to make the other
partitions--mainly 'cause I don't have a clue. What say ye? When y'all
create more than / and /swap, just how big do you make 'em? I hate wasting
disk space.
Thanks,
Pete
** Sent via the linuxppc-user mail list. See http://lists.linuxppc.org/
johnathan spectre
> I agree, very interesting thread, and, as another newbie, one I have
> pestered my more experienced Linux friends with. Another advantage to just /
> and /swap is not worrying how many and how large to make the other
> partitions--mainly 'cause I don't have a clue. What say ye? When y'all
> create more than / and /swap, just how big do you make 'em? I hate wasting
> disk space.
Disk space is cheap these days and most systems I set up (at my current
employer) have 18g drives (sun 220's) and I'm free to do what I want with
with system partitioning (on the boot drive). Here's how I generally set
these boxes up and reasoning why, you can adjust your sizes to fit your
needs.
/ (root) - Generally 512M is enough, you figure anything that isn't stored
in another partition already is going to be lumped into root, so you have to
give it a bit of space. One of the most common mistakes newbie admins make
is giving the minimum space to root and having it fill up. This usually
renders a system unbootable (in multi-user mode), no one can log in, and
many other mysterious errors. Given my partitioning scheme root us usually
pretty empty. When I see it filling up I go looking why.
/usr - 2G to 3G depending on the OS. Solaris is fine with 2g, linux (various
distributions) some times wants more depending on how many extras you
install and where they go. You will also want more space here if you do not
put /usr/local in a separate partition (see below)
/tmp - 1G (or more) - /tmp is the catch-all. If the system is used by many
people they will tend to store scratch files here. This can fill up fast.
Applications store a lot of their temporary files here as well. Another
common mistake by newbie admins is not separating this out of / (root). If
they don't and this fills up it can cause the problems mentioned in root. If
you're the only person using the system, less is fine if you don't plan on
filling it up (or leaving it under / and giving / more space).
/var - 512M or more. Again this depends on the function of the server. For
example a mail server will need A LOT more space here since most mail is
stored under /var/spool/mail. Log files tend to be under /var/log. Printer
spool files can be stored here too. This file can fill up faster than /tmp.
If I'm setting up a multi-user server (or web or print server) I will give
it more space. If it is a single-user box then less is fine, even combining
it under / (again the same warnings apply if you combine it with /, if it
fills you can have trouble).
/usr/local - 1G+ This partition depends on how much custom software you will
build here. In practice I put open-source software here (gnu stuff, etc.). I
like to partition it off by itself to keep it away from the OS installed
software under /usr. Also it may be NFS exported to other systems. Some
times I will even put this partition on another disc to improve performance.
If you don't plan (or know how to) on building a lot of software (you
install everything by packages that go into /usr) this can be eliminated
entirely or simply left to fall under /usr's partition.
swap - the general rule is 2x to 4x your physical RAM. Linux is a bit funny
how it treats swap partitions (at one time it would not handle swap
partitions that were larger than 128M, so you had to have multiple
partitions). In the "real world" it depends on the function of the box. Some
of my oracle servers have 2G of ram and I'll give them 4G of swap since
space is cheap but we really don't want them using any swap since it is a
performance hit on what we're doing. Personal boxes vary. If you have less
physical RAM and plan on running X windows, Enlightenment, and a ton of
apps, you might want 2x to 4x. If you have lots of physical RAM and don't
plan on running a lot of apps you can give it 1x to 2x. My Pismo has 640M of
RAM and I didn't want to give it 1.2G of swap space out of my 12G drive (a
30 is on its way though). So I only gave it 128M.
/opt - Varies. This is where I typically install "commerical" applications
purchased by my employer for use on the system. Oracle, Sybase, Netscape
Enterprise Server, etc. They are kept out of /usr/local and typically
install in their own directories such as /opt/ora8.0i or /opt/netscape.
Personal boxes probably don't need this at all. I'll allocate space to here
depending on the function of the box (which I'll know ahead of time).
/home - Heh. You can never have enough home space according to some users.
If this is a multi-user system, figure 1G per user and then multiply by 10!
(Just kidding ;-) On a box for yourself, allocate whatever you are
comfortable with, or even combine it with /. Multi-user systems (that don't
have home directories auto-mounted from a server somewhere or that are the
server) need a lot of space. Developers tend to want as much as they can
grab, holding multiple copies of whatever they are working on plus their
favorite utilities that aren't installed in /usr/local. On multi-user
systems I never let this combine with / because it can fill up very fast
with users downloading mp3's, porn, cd images, etc. Quotas are very nice to
use on /home (another topic entirely).
Well I hope this answers some questions on partitioning. Remember this is
simply my opinion and method for doing this. Others I'm sure will have their
own schemes. Comments are welcome, flames can be filed under /dev/null.
Thanks.
johnathan spectre
Some follow-up notes I forgot to mention last night..
I mentioned lots of space reasons for breaking things out into separate
partitions, but there are a few other reasons.
1. Backups - It's easier and faster to back up separate partitions than one
mega-partition. Some partitions (such as / or /usr) might only get a full
back up once a week or month because the rarely change. Others such as /var
or /home might get backed up nightly.
2. Re-creating a system. By isolating all your "factory installed" software
into partitions like / and /usr you can easily re-create a system by just
restoring what you need, /opt, /usr/local, /home.
3. Re-installing/upgrading. Now I've had problems getting various upgrades
to just install, some times it is just as easy to have the installer
re-format and do a fresh install on /, /usr, /var while leaving your
/usr/local, /home untouched. When done you just re-mount and go.
4. Performance. You can easily locate partitions across several drives for
best performance. IDE systems might want to use two master drives on two IDE
busses. SCSI might want to split up among different SCSI busses. I also try
and put swap, /tmp, /var in the "center" of a drive if they are used a lot
on a system. Drive heads have less to travel. Directory structures are also
smaller in more partitions than a single one.
5. Loss. One of discussions that started this thread I think. From run-away
processes, crashes or *OOPS* admin screw-ups. You might take out far less
with that accidental newfs.
There are others but these are among the important ones in my opinion..
Chris Brown
On Sat, Aug 19, 2000 at 07:59:24AM -0400, johnathan spectre wrote:
> 5. Loss. One of discussions that started this thread I think. From run-away
> processes, crashes or *OOPS* admin screw-ups. You might take out far less
> with that accidental newfs.
>
> There are others but these are among the important ones in my opinion..
>
To add another to these excellent reasons (and it's true, segmenting
partitions becomes much more important on multiuser systems than on single
user systems... my (intel/linux) laptop has a 1.5gb hard drive, and I am
the only user, so I made just swap and / partitions... I wouldn't dream of
doing that on the multiuser systems I manage... there are just too many
things that can happen)
6. inodes... with the drive sizes today, if you format as a single large
partition, you have to make the block size really large to get a manageable
number of inodes... which leads to inefficiency in storing small files...
and if you forget, and don't change the block size when you format, you are
likely to run out of inodes at some point... smaller partitions allow you
to optimize the block size and number of inodes...
Sriranga Veeraraghavan
> /tmp - 1G (or more) - /tmp is the catch-all.
On a Linux box this is fesable, since its just disk, but on a Solaris
box where its Ram+Swap, you need a pretty stacked machine. We had this
E10K with 2 GB /tmp, compiles on that thing were unbelievably fast.
> swap - the general rule is 2x to 4x your physical RAM.
I don't remember every needing 4 times RAM for swap.
The olden days of swapping the rule for swap space was:
((physical memory) * 2) + 1 in MB
because swapping was just that, swapping one executing processes
memory image to disk to load another processes memory image. You need
a lot of disk space to swap running images.
In modern times swapping has been replaced with paging, which is much
more efficient. In paging, when a process requires a page that is
currently paged to disk, a unused page in memory is written to disk
and the required page that is on disk is loaded into memory, which
requires a much smaller amount of disk space.
----ranga
johnathan spectre
> On a Linux box this is fesable, since its just disk, but on a Solaris
> box where its Ram+Swap, you need a pretty stacked machine. We had this
> E10K with 2 GB /tmp, compiles on that thing were unbelievably fast.
if you allocate a /tmp partition under solaris it is not ram+swap. this is
another good reason for making a separate /tmp partition (under solaris).
you don't have to worry about running out of swap space or /tmp space by
using too much of the other.
>> swap - the general rule is 2x to 4x your physical RAM.
>
> I don't remember every needing 4 times RAM for swap.
like i said, everyone's configuration is different. i've worked on systems
that had processes running that grabbed HUGE amounts of memory for modeling
space even if they didn't use it all at once. sections of models would be
developed and held in "memory" (really swap space) until the whole model was
completed and saved on disc. most of these systems had 64-128M of RAM when
that was a lot, not the 4G+ "small" servers have these days.
> The olden days of swapping the rule for swap space was:
>
> ((physical memory) * 2) + 1 in MB
my rule was 4*RAM => actual_swap => 2*RAM
> because swapping was just that, swapping one executing processes
> memory image to disk to load another processes memory image. You need
> a lot of disk space to swap running images.
swapping was not always complete program images but also code fragments or
whatever the developers felt like using.