more than 7 partitions on a SCSI-drive

Christian Baer christian.baer at
Mon Jan 22 18:48:28 UTC 2007

On Sun, 21 Jan 2007 11:54:40 -0900 Jeff Mohler wrote:

One polite request: Would you please quote properly? I know this is not
the usenet, but quoting serves a purpose and should make reading you
question/comment easier.

> If there is a fundamental reason why we still partition things like we
> only have 10, 20, or 40Mb RLL. or slightly larger ESDI drives from
> back in the willing to learn.

In the good ol' days HDs weren't divided up into many partitions. They
were usually too small to be of much good then. That actually began when
the space that single HDs had became bigger and therefore single HDs
could function almost as two or three on the same system.

If an error on a filesystem accurs that can take down the entire system
if all you have is /. The idea is to limit the amount of damage that can
be done to a system by dividing the data up intelligently. Usually most
write actions are on /tmp and /var. So if the power goes down before you
can shut down the system cleanly, the chances are high that you will
have errors on these file systems. If they are all on / then that's bad
news. But think about what would happen if data in /tmp ist lost because
of a filesystem error. Exactly: nobody cares!

Different partitions also have the advantage that they can be mounted
with different options, have different block sizes, more or less inodes
or can be encrypted.

Here are a few ideas as to why I divide my drives up, including some of
the reasons why I divided the drives up the way I showed.

/ ist usually mounted with synchronous writing only (and not soft
updates). That is usually relatively slow but doesn't matter on /. You
don't want to mess up this filesystem or you could end up not being able
to start the system at all. It's best to keep this filesystem small.

/usr contains all the programs files, usually the ports and source tree
too. Writing to this filesystem isn't that frequent but fast access is
definately wanted.

/tmp and /var contain quickly changing, usually not too important data.
Fast access is important and writing is very frequent. If the system
crashes or the filesystems are not unmounted cleanly you usually have
errors on these filesystems.

A swap partition is there for obvious reasons. :-)

/var/spool/news used to contain a lot of files (one file per article)
and required more inodes than the other filesystems. This can apply
today aswell if you choose byfile storage of news.

/home is useful to stop the users filling up /usr, which can be quite a
pain. I know this could also be done by using disc quota.

/home/christian is mirrored and encrypted as I keep all my personal
stuff on there like (e)mail, bank stuff and things from work. But also
personal things like my personal diary. I don't want to encrypt all my
system as that slows down access dramatically. And it's completely
useless waisting CPU-cycles on decrypting the executables of KDE,
Firefox and OO.

/usr/obj can be put in a seperate filesystem to increase performance.
The information in there isn't too important so if anything gets lost
because of a power out while doing a make buildworld, just erase it and
start over. The performance can be increased if the HDs are the
bottleneck. The idea is to read from one drive containing /usr/src and
writing to another containing /usr/obj. This partition can be optimized
for fast writes rather than safety. I have mounted this filesystem with

Is my concept a little clearer now?


More information about the freebsd-questions mailing list