From owner-freebsd-questions Tue Jan 5 14:04:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA17728 for freebsd-questions-outgoing; Tue, 5 Jan 1999 14:04:34 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from guru.phone.net (guru.phone.net [209.157.82.120]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA17721 for ; Tue, 5 Jan 1999 14:04:29 -0800 (PST) (envelope-from mwm@phone.net) Received: (qmail 20984 invoked by uid 100); 5 Jan 1999 22:03:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Jan 1999 22:03:55 -0000 Date: Tue, 5 Jan 1999 14:03:55 -0800 (PST) From: Mike Meyer To: questions@FreeBSD.ORG Subject: Re: max partitions in one slice? In-Reply-To: <19990106081353.O78349@freebie.lemis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 Jan 1999, Greg Lehey wrote: > > Hmm - considering that two file systems is at least one two few for a > > Unix system, I'm curious as to what you're going to do with those few? > > > > To justify my statement, and start a discussion of file system > > allocation, you want the following (bare miminum): > > > > 1) OS installed software (/ & /usr) > > > > 2) Spool area (/var) > > > > 3) Things that didn't come with the OS (i.e. - your home directory). > > > > On second thought, if you don't ever spool anything (i.e. - no mail, > > no printer, nothing logged, etc.), you can get away without > > /var. That's not very likely, though. > > You haven't said why you think you need separate file systems for all > these things. It's perfectly possible to have a UNIX system with only > one file system; I have at least one on my network, and that may be > too few. Fair enough. Heavily-trafficed things (mail spools, printer spools, the log files) get pulled into one area so that writes to them will be isolated during a crash. Stuff that doesn't come from the vendor gets a separate file system so that it's got separate backups, is well out of the way for OS upgrades, etc. > In general, there are three possible reasons for having more than one > file system: > > 1. Security. If you break one file system, you still have the > other. This was once a serious problem, but nowadays the systems > are so reliable that it hardly counts. I've been running BSD for > nearly 7 years now, and I've only had one crash (on a BSD/OS root > file system, FWIW). Still, this and superstition are the reason > that I accept a separate root file system on the system disk. That's one reason for splitting /var off from /. Not the only one, though. > 2. Because they are on different disks. Vinum will solve this > problem too. See http://www.lemis.com/vinum.html for more > details. Vinum? How is this different from a RAID implementation? For my workstations, I've never needed such a thing, but some of my clients use RAID for databases. > 3. Because otherwise it would be too big to make a backup on a single > tape. That's only if your backup software is truly hosed. Since the stock software that comes with BSD supports multi-tape backups just fine, there's no reason to worry about that. > The biggest disadvantage of separate partitions is that it fragments > your data space. In this forum we continually see people running out > of space, usually on /var, and wanting to know what to do. If they > hadn't had a separate /var in the first place, they wouldn't have had > the problem. True - it does make things inconvenient that way. That's why you want to minimize the number - especially for things that don't come with the OS. On the other hand, I got tired of seeing SunOS systems (that put /var on / and way to little space on /) die horribly when /var filled up. That gets solved by moving /var off of /. /var fills up, but the system still runs mostly fine. Which is another reason for having a seperate file system: to provide firewalls (terminology courtesy of Mike O'Dell). I split /usr off from / on my system, in part so I don't have to worry about filling / while mucking about with /usr/ports and thus causing real problems. Ditto for putting your own stuff on a different file system from root, or one where you log files, etc. That way, a runaway user process can't cripple the system by running something critical out of space (or, given the 10% slop, so close that it'll finish the job itself).