Date: Fri, 8 Jan 1999 18:42:09 +1100 From: jonathan michaels <jon@caamora.com.au> To: questions@FreeBSD.ORG Subject: Re: max partitions in one slice? Message-ID: <19990108184209.B1504@caamora.com.au> In-Reply-To: <Pine.BSF.4.05.9901051347330.7183-100000@guru.phone.net>; from Mike Meyer on Tue, Jan 05, 1999 at 02:03:55PM -0800 References: <19990106081353.O78349@freebie.lemis.com> <Pine.BSF.4.05.9901051347330.7183-100000@guru.phone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 05, 1999 at 02:03:55PM -0800, Mike Meyer wrote: > > 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. i have a small scsi tape streamer (tandberg tdc-3820 - qic-525) and have started to rebuild my freebsd filesystems allocationing so that i can make 'simple' one tape 'dumps'. having transfered from a ms dos world where disk's just got bigger and teh filesystem managled to cope. i thought it was a real 'breath of fresh air' when i could cut up my media to support such notions as backup stratagies. > > 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. this is teh main reason i did it that way .. well that and data overruns, its a bit hairy when you untar, say a wp8 using midnight commander and get that almost ubiquioutious (my spelling checker is out to lunch, sorry) 'filesystem full' error message. > > 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. i was wondering how vinum would perform as a mailinglist filesystem manager. not a really bigh one but int eh class of some 100 mb inwards producing some 400mb output mail articles. lots and lots of small files, requiring lots of inodes and filesystem thunking .. sort of thing. > > 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. i can atest to that .. mail (used to) get dumped to tape on a 3 tape roster, back then the 500 mb tapes were expensive so i used 150 mb tapes. also i looked at it this way if one tape went down i'd have teh other two. i didn't use data compression .. once i got hosed with a bad tape and i'd compressed an ms dos filesystem .. lots of bad words and evil thoughts were directed in my general direction .. grin, i think. though, with freebsd i have yet to see those sorts of endemic, systemic irregularities .. after some 2 or 3 years of really trying .. grin. > > 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. yup, these days i give "/" about 50 to 100 mb and "/var" some 500 mb .. but, i remember a time when that was a realy big disk, haven't times changed ? > 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 my system is not generally publically available, but the users i do have are starting to discover what they can do in thier hostname:~userid/public_html it looks like its time to add to teh scsi chain and call it /usr/home, as well as /usr/local/www and possiblly as you have /usr/ports. > 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). yup, i've always included a generious margin for error, these days with junk mail being what it is, it is hard to, well dangerious not to be too carefull. this ofcourse needs to be balanced against the fortress mentality i suppose. been thier, done that, got teh release papers to prove it ... grin. regards, and best wishes for teh new year. cheers jonathan -- =============================================================================== Jonathan Michaels PO Box 144, Rosebery, NSW 1445 Australia ===========================================================<jon@caamora.com.au> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990108184209.B1504>