Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Disk partitioning and swap



Derek Atkins sez:
	Really, the only advantage of having multiple, small partitions is if
	you have multiple disks (spindles).  The e2fsck program can work in
	parallel across multiple disks.  But it can only split up after it
	finishes the root paritition.  So, if you have, say, two 18G drives,
	it would be faster to have a 'small' root on one drive and then more
	partitions on both.

	If you only have one drive, it really doesn't matter.  IMHO.

It would be interesting to know of any actual measurable  performance
impact   of   different   partition  schemes.   I've  attempted  such
measurements on several sorts of Unix systems, and so far there  were
never  any measurable performance differences.  If linux actually has
some, it could be useful to know about them.

I've seen two reasons for  having  multiple  partitions,  neither  of
which is related to performance.  One is the technical limitations of
disk controllers or BIOSes.   Some  of  these  just  can't  handle  a
partition  more  than a certain size, and if your disk is bigger, you
have no choice but to partition it.

The other reason for partitioning is to wall off the mail,  news  and
log  directories, so you can't get a "denial of service" failure when
they fill the disk.  This can happen very easily,  even  without  any
malicious  intent,  as  we  just  saw  with the Melissa virus/worm on
Microsoft systems. Unix systems aren't immune to this, so it can be a
good  idea  to  partition  these  things  off so when they fill their
filesystem, it doesn't drag everything to a halt.

A related topic: making /tmp a separate "RAM disk" partition can be a
very good idea if you are interested in performance.  Of course, this
has little if anything to do directly with the  question  of  how  to
partition  your disk.  But saying "Don't put /tmp on disk at all" can
be a useful addendum to the subject.  (Then you have the quandary  of
how  to  decide  the  tradeoff  between  memory for processes, kernel
buffers and the /tmp filesystem.)

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org