From owner-freebsd-isp Tue Jan 27 14:28:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA29660 for freebsd-isp-outgoing; Tue, 27 Jan 1998 14:28:19 -0800 (PST) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from mixcom.mixcom.com (mixcom.mixcom.com [198.137.186.100]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA29644 for ; Tue, 27 Jan 1998 14:28:16 -0800 (PST) (envelope-from mountin.man@mixcom.com) Received: by mixcom.mixcom.com (8.6.12/2.2) id QAA13788; Tue, 27 Jan 1998 16:25:16 -0600 Received: from dial193-21.mixcom.com(207.250.193.21) by mixcom.mixcom.com via smap (V1.3) id sma013750; Tue Jan 27 16:24:46 1998 Message-Id: <3.0.3.32.19980127161925.0070865c@198.137.186.100> X-Sender: mmttnn@198.137.186.100 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 27 Jan 1998 16:19:25 -0600 To: andrew@pubnix.net, lamaster@george.arc.nasa.gov From: "Jeffrey J. Mountin" Subject: Re: Sendmail - low on space Cc: freebsd-isp@FreeBSD.ORG In-Reply-To: References: <199801272034.MAA04209@george.arc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:24 PM 1/27/98 -0500, Andrew Webster wrote: >I'll jump in on this one as I've been bitten by the small /var more than >once! > >Watch out for /tmp too as the the local mail delivery agent called by >sendmail (usually rmail) will write into /tmp. So if you are trying >to deliver a large file it may still fail, and even if you have the space >in /var/mail. I've been bitten by /tmp myself. Majordomo can kill a small /tmp in a hurry. >I create my systems without a physical /var parition and symlink /var and >/tmp into /usr/var and /usr/tmp respectively, this eliminates all >problems, and you don't end up "wasting" lots of disk space for temporary >files. > >Can we make this the default of sysinstall? > >Alternatively you CAN create a biggish /var partion and link /tmp into >/var/tmp. There may be reasons against this, since some programs use /var/tmp and /usr/tmp for different things, but see no practical reason why not. >On Tue, 27 Jan 1998 lamaster@george.arc.nasa.gov wrote: --snip-- >> I know it is unfashionable right now to say this, and, >> each to his own taste, but, /var was created for a reason. >> The reason hasn't really gone away. I think it in >> multiple-user environments it is good planning >> to decide how much to reserve in advance for, e.g., >> the user mail input queues. As well as user home >> directories and other similar requirements. Preference and needs of the situation should dictate how you manage the filesystems. As the number of users grow, more disks are needed... >> In other words, while the original user needs help and probably >> doesn't feel like re-partitioning the disk at this point, >> in general, I recommend planning the /var partition in advance >> and partitioning the disk accordingly. The FreeBSD sysinstall >> defaults are reasonable for smallish disks, but most people >> have more memory and bigger disks today, and would benefit from >> generally larger partitions (including swap). But, the basic >> partitioning is very reasonable; the default sizes for /, swap, >> and /var, should probably be larger for larger disks. I forget the defaults, but do recall that as packages were added to a system, the wasted space having separate /var and /usr partitions was an issue and forced me to start over fresh. :/ For a single user consigning /var to /usr/var and /tmp to either (/usr)/var/tmp or /usr/tmp works fine and if more space is needed, then another disk(s) can be used for the mount point(s) you wish. Even for a personal system, I'd much rather have 2 or 3 small disks. In an ISP environment only a DNS server could have one drive, IMHO. Unless you want to go overkill from the start, adjusting partition sizes on a production server is a greater hassle, easier to add a disk to either a growing or heavily hit filesystem. As the system grows it would be advisable to separate /var/spool/* (or just mqueue) and /var/mail, so the working and storage directories are on different disks, even to the point of using mutiple disks to break apart /var/mail. It all depends on if disk IO can keep up with demand. Break off /usr/home if there are a lot of shell users. I consider / and /usr the "base" of the system and work from there on what the needs will be by adding more drives. Jeff Mountin - Unix Systems TCP/IP networking mountin.man@mixcom.com