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 | Blog | 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




John Chambers wrote in a message to Mike Bilow:

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

First of all, /tmp is rarely used.  Even ordinary programs which need to make
temporary files should put them in /usr/tmp, which is usually just a symlink to
/var/tmp.  (Don't use /var/tmp directly, since some systems may not have it,
and performance anomalies could result.)  The distinction between /tmp and
/usr/tmp is historical, when /tmp was for stuff that had to be accessible
during the boot process and before /usr was mounted, possibly over a network.

Second, there are almost no cases where a ramdisk is useful under Linux for
production purposes.  The main purpose of ramdisk support is to handle
installation where the root filesystem must be loaded from floppies and will
usually exceed the size of a single floppy.  Using RAM as RAM, rather than as
pseudo-disk space, is almost always a big win.

This is merely another instance of the general principle: Unix ain't DOS.
 
-- Mike


-
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