From owner-freebsd-isp Wed Jan 28 08:37:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23887 for freebsd-isp-outgoing; Wed, 28 Jan 1998 08:37:03 -0800 (PST) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from mercury.jorsm.com (mercury.jorsm.com [207.112.128.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23882 for ; Wed, 28 Jan 1998 08:37:01 -0800 (PST) (envelope-from jeff@mercury.jorsm.com) Received: from localhost (jeff@localhost) by mercury.jorsm.com (8.8.7/8.8.7) with SMTP id KAA05234; Wed, 28 Jan 1998 10:32:57 -0600 (CST) Date: Wed, 28 Jan 1998 10:32:57 -0600 (CST) From: Jeff Lynch Reply-To: Jeff Lynch To: jack cc: Greg Lehey , freebsd-isp@FreeBSD.ORG Subject: Re: Sendmail - low on space In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 28 Jan 1998, jack wrote: > On Wed, 28 Jan 1998, Greg Lehey wrote: > > > I think you're missing the point. Nobody's advocating doing away with > > the /usr file system. > > I realize that. I just see no sense in doing the amount of writing that > is normally done to /var done on the same slice that houses system files. > Has it been forgotten that var is short for variable? For files that are > constantly being changed? /usr is the user's playground, for their > working files. Loose /var and it's not too traumatic. Loose /usr and > you've got a problem. Loose / and you've got nothing to work with. With > an intact / slice you can boot single user and rebuild the rest. > > A read only / is a nice added security measure, not foolproof but every > little bit helps. :) Exactly. Wisdom of the ages...way back in the days when heads blew a couple times a year. Eventhough disk technology is more reliable these days, I still fully believe in keeping /, /usr, and /var as separate file systems. It's much faster and easier to rebuild separate filesystems anyway and it's easier to plan your backups. I even separate /home, and a second local filesystem that keeps all my custom stuff there because I usually d/l tarballs from the source and build for FBSD myself rather than rely on packages/ports although I do make use of them when appropriate. This makes it easier at OS upgrade time. On minis I even made /tmp it's own partition to keep temp files from killing mail, logs, and other in-house tools...and vice versa. The FBSD label editor makes it simple to partition disks at install time or when you decide to take the hit and repartition. It's always a pain to resize later but it's better to start out playing it safe. Separate partitions are your friend. Disks are cheap, throw in a few more spindles and waste a little space. Get a performance increase on SCSI or multiple IDE controllers too! The FBSD team knows this, I don't expect to seeing the default changed. This is really small stuff to worry about. ========================================================================= Jeffrey A. Lynch, President JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com