From owner-freebsd-questions Wed May 27 02:39:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA16177 for freebsd-questions-outgoing; Wed, 27 May 1998 02:39:40 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from freebie.lemis.com (freebie.lemis.com [139.130.136.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA16151 for ; Wed, 27 May 1998 02:39:31 -0700 (PDT) (envelope-from grog@lemis.com) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id TAA25979; Wed, 27 May 1998 19:09:09 +0930 (CST) (envelope-from grog) Message-ID: <19980527190909.M24133@freebie.lemis.com> Date: Wed, 27 May 1998 19:09:09 +0930 From: Greg Lehey To: chas , Doug White Cc: freebsd-questions@FreeBSD.ORG Subject: Re: adding 25GB as single partition ok ? References: <3.0.32.19980527105421.0093fd30@peace.com.my> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <3.0.32.19980527105421.0093fd30@peace.com.my>; from chas on Wed, May 27, 1998 at 10:32:16AM +0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 27 May 1998 at 10:32:16 +0800, chas wrote: > Thanks Doug, > >> You can't easily back up /var, at least using dump. > > I've actually picked up some good input from some Digital > Unix folks : > >> 2. The root partition looks a little small, I'd be more comfortable with >> 150-200mb. That might be right for Digital UNIX. It's far too large for FreeBSD. 40 or 50 MB is more typical. >> 3. Your /usr partition is large, but then I tend to split /usr/local >> (or /usr/opt if you come from an HP background) and /var off onto >> seperate partitions. In a configuration/security sensitive environment >> this allows you to mount /usr as read-only (make sure that the links >> to var are in place for directories that need to change) and only mounted >> read-write when the OS is updated. 1GB should be plenty if you split >> out your local and var files. The trouble with this scheme is that it's difficult to estimate the size of /usr, and FreeBSD is not laid out to easily mount /usr read-only. >> 4. As above, I tend to seperate out /usr/local and /var >> >> a. /usr/local is nice to have seperate, just because I don't trust the >> vendor's installers -- that way you can unmount it before any upgrades. This may be a Digital problem. We haven't had it on FreeBSD. >> b. /var is nice to have on a seperate partition because it contains both >> your log files and your crash dumps. If your system is attacked, both >> can start to fill a filesystem quickly. This is true, but you can use quotas. You can limit the amount of space that core dump files take by setting corresponding values in /var/crash/minfree, and there's no reason why you shouldn't include some script in the startup file to ensure that your /var/log/ directory doesn't get too big. Nevertheless, in this particular case, it may be justified if you're primarily a mail and news machine, in which case most of the disk would be /var. >> 5. If the 25GB raid set is to be used only for the mail spool, why >> not just mount it as /var/spool/mail or to be more flexable, >> /var/spool? Why not call the file system /var? >>> Are there any speed (I/O) considerations that would >>> suggest an alternative configuration ? (backup/redundancy >>> should be failsafe since it's hardware RAID) >> >> Speed-wise, if you could get another disk I'd strongly suggest using >> RAID 0+1 (somtimes refered to as RAID 10). RAID 5 and especially >> RAID 3 tend to bottle-neck with many small files. RAID 0+1 is a >> stripe set that is then mirrored by an identical stripe set. It has >> the all of the performance benifits of stripe sets and mirroring >> (round-robin reads) but is very costly in terms of disks (2 X capacity >> is needed). If possible, spread all of the disks out over controller >> chanels (HSZ) or at least put the stripe sets on different chanels >> (SWXCR). It also uses significantly more disk--depending on the RAID 5 configuration, up to double. >> Mail, as opposed to news, generates one spool file per user. Depending >> on the number of users, you may want to consider adjusting the inode >> or extent ratio that you use. >> >> I don't remember the max size for a UFS partiion, but if you are using >> UFS -- don't forget to set the inodes per kb down to one or two. This >> will reduce the avialable space bya small amount but will let you handle >> more small files. If this is primarily mail, you won't need to do this. If it's primarily news, it's a good idea. Remember that the only way to increase the number of inodes (files) is to re-newfs the file system, which involves a backup and restore of the complete Raid set. Even a fast tape drive (2 MB/s) would take about 8 hours to back up the data, and possibly about 12 hours to restore; count 24 hours uninterrupted work to rebuild it. > Also, we're hoping to use Qmail which everyone says will speed things > up. (if we can get it to work with Cyrus - next post) I don't know about "everyone". The jury's out about qmail. Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message