8.0-RELEASE -> -STABLE and size of /

Jeremy Chadwick freebsd at jdc.parodius.com
Sat Jan 23 20:21:50 UTC 2010

On Sat, Jan 23, 2010 at 09:04:57PM +0100, Miroslav Lachman wrote:
> Jeremy Chadwick wrote:
> [...]
> >While I'm here, I figure I'd share how I end up partitioning most of the
> >server systems I maintain.  I use this general "formula" when building a
> >new system, unless it's a 4-disk box (see bottom of mail):
> >
> >ad4s1a = /    = UFS2    = 1GB
> >ad4s1b = swap           = (2*RAM) or (2*MaxRAMPossible)
> >ad4s1d = /var = UFS2+SU = 16GB  (mandatory: must be>= 2*RAM)
> >ad4s1e = /tmp = UFS2+SU = (2*RAM)
> >ad4s1f = /usr = UFS2+SU = 16GB
> Why you are suggesting /var >= 2*RAM? Is it just for saving crash
> dumps or anything else?

1) Kernel panics/crash dumps are a big focus, yes.  There's nothing
worse than experiencing one, only to find out that savecore(8) can't do
its job because /var/crash lacks the space.  The system then boots
anyway, swap starts getting used as normal, and the dump is therefore
lost.  Chance of debugging this post-mortem: zero.

Additionally, people these days are often upgrading RAM in their systems
as well; they start out with 1-2GB and create /var possibly with the
knowledge of the above ordeal (re: crash dumps).  Then they later
upgrade to 4GB or 8GB RAM, and suddenly realise that they can't grow
/var to deal with a crash dump.

2) I tend to keep a large amount of logs on systems, going back weeks if
not months.  This is intentional; it's amazing how often a customer or
user will ask for some information from 3 or 4 months prior.

FreeBSD's Apache port out-of-the-box logs to /var/log/httpd-*, and what
we do is mostly web content serving.  Let's also not forget about
/var/log/maillog.  I also advocate use of /var/log/all.log.

I think it's fairly well-established at this point that I focus on
server environments and not workstations (where /var probably doesn't
need to be anywhere near that size).  Folks should always review their
needs, keeping expansion possibility in mind, when doing filesystem

> And why so big /tmp? I am running servers with smaller sizes for years
> without any problem.

My recommendation above doesn't imply those who don't use it will have
problems -- each environment/system is different.

That said, it's amazing how much software out there blindly uses /tmp.
Last year I ran into this situation: an older server (1GB /tmp) started
behaving oddly due to /tmp filling.  A user of the system was using lynx
to download some large files (an ISO image and something else, I forget
what).  lynx saves data its downloading to /tmp, and once it completes,
the user is prompted where to save the data (CWD being the default).

"So tune lynx to use /var/tmp or some other path" -- sure, that'd work,
except lynx is just one of many programs which could do this.  I'd
rather not "tune them all".  :-)  /tmp is more or less universal.

Hope this sheds some light on my decisions.  :-)

| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

More information about the freebsd-stable mailing list