On Sun, 7 Aug 2005, Bart Trojanowski wrote: > In general, I would say... > > / for all your OS, so ~5G The only thing I'd say here is that corruption on / is much worse than corruption anywhere else. For this reason it can pay to make / as small as possible and spit off /usr and /opt. It can also be a hassle if you make it too small :) There was a time people would mount /usr read-only but that was before regular security updates became a standard part of a sysadmin's day. > /tmp on tmpfs is a cool hack that a friend told me to try. I have not > actually tested it yet, so I don't have first hand experience. Anyway, There is a hidden catch with using tmpfs. Linux cannot quota this filesystem type yet so a user can (un)intentionally fill /tmp with ease. On multi-user systems I refrain from using tmpfs for this reason. A seperate /tmp on a regular filesystem with per user quotas isn't necessarily out of the question. I haven't found the performance gains from using tmpfs to be huge either. These days users usually have gobs of space in $HOME and don't need to use /tmp as a scratch drive as they did when tmpfs was developed on other OSes (such as Solaris). Besides, most systems with tmpfs in use have /tmp fairly small so it ends up being useless for a scratch drive anyway :) > /tmp will eat up RAM as long as it's used actively. Once files are > stale it will get swaped out. This of course means that files don't > persist over reboots. The POSIX standard calls for /tmp (but not /var/tmp) to be cleared on reboot anyway IIRC and this is certainly standard behaviour for Linux. Cheers, Rob -- Robert Brockway B.Sc. Phone: +1-416-669-3073 Senior Technical Consultant Email: support [ at ] opentrend [ dot ] net OpenTrend Solutions Ltd. Web: www.opentrend.net We are open 24x7x365 for technical support. Call us in a crisis.