Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Dec 1999 12:47:43 +1100
From:      aunty <aunty@comcen.com.au>
To:        Greg Lehey <grog@lemis.com>
Cc:        up@3.am, Sue Blake <sue@welearn.com.au>, freebsd-isp@FreeBSD.ORG
Subject:   Re: partition sizes
Message-ID:  <19991217124743.A141@comcen.com.au>
In-Reply-To: <19991217082605.G46720@freebie.lemis.com>
References:  <19991216140442.B88143@welearn.com.au> <Pine.BSF.4.10.9912152253060.95202-100000@richard2.pil.net> <19991217082605.G46720@freebie.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 17, 1999 at 08:26:06AM +1030, Greg Lehey wrote:
> On Wednesday, 15 December 1999 at 22:59:32 -0500, up@3.am wrote:
> > On Thu, 16 Dec 1999, Sue Blake wrote:
> >
> >> I'm rebuilding an ancient ISP server as two new FreeBSD servers, basically
> >> separating mail from the web/shell machine.
> >>
> >> Where there was two gigabytes to play with before (for the OS, swap,
> >> logs, ...), I find myself staring at about 8 on the new drives, and
> >> wondering how to make partitioning decisions that will still look
> >> resonable some time down the track. (The data drives will be brought
> >> across from the old system.)
> >>
> >> Apart from examining how the present system copes, is there something I
> >> should be reading, or is it just a matter of experience, or are all ISP
> >> systems started from best guesses and growed like Topsy? :-)
> >
> > for the mail server, I'd go:
> >
> > 500MB   /
> > 1.5GB   /usr
> > 4GB     /var  (put half of that in /home if you're using qmail)
> > 2GB     /home
> >
> > For the web server (assuming customer sites are in ~):
> >
> > 500MB   /
> > 2.5GB   /usr
> > 1GB     /var
> > 4GB     /home
> >
> > There are sooo many variables, of course...where are the customer web logs
> > going to be? etc..)
> 
> With either of these suggestions, when you run out of space on one
> partition, you'll have plenty on some other partition (probably / in
> this case, unless you're putting /tmp there, which is a Bad Idea).

Actually, /tmp is a 64MB mfs on the old system. I remember trying that
once in the past on another machine thinking it was a good idea and
then changing my mind, but can't remember why. Nobody here has
suggested using mfs either. Is it worth considering?

> How can you possibly guess how big your /var file system will become?

Not that hard. On the old system it's 800MB and only a quarter of
that is used, so 800MB again should see it through.

> I would recommend:
> 
>     50MB	/

Will that remain enough in the future?

>     256MB	swap (don't forget that!)

Oh, it will have at least that much memory so I was planning on giving
it a gigabyte. Is there such a thing as having too much swap?

>     rest	/usr
> 
> Then create symlinks for /tmp, /var and, if you need, /home.  If you
> need to restrict growth of a specific file system, use quotas.
> 
> If your disk is bigger than your backup tape, make enough equal-sized
> partitions so that each fits on a single tape.

Backups are a consideration, but not the size of the backup tapes.
There are only a handful of tapes which are shared between several
machines, and what doesn't fit doesn't get backed up. There is
little hope of getting more tapes and only the most necessary
filesystems are backed up. The definition of necessary is determined
and changed by others.

Also these machines have a history if disk problems, accidental power
outages, and periodic managerial reboots to freshen them up or to solve
hard puzzling behaviour. That is unlikely to change much. All I can do
is minimise and repair the damage. Often after a reboot a server is
offline while fscking, and I'd like those periods to be shorter, ie,
not 8 gigs worth every time, and to have less to restore if a
filesystem is really hosed.

With mail spool and home directories on separate drives, there is going
to be a lot of unused space on this drive. Given the ample free space,
a moderate approach to partitioning seems more prudent than a single
partition, don't you think?




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19991217124743.A141>