From owner-freebsd-questions@FreeBSD.ORG Thu May 5 15:17:16 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25FBC16A4CE for ; Thu, 5 May 2005 15:17:16 +0000 (GMT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id A471043D81 for ; Thu, 5 May 2005 15:17:15 +0000 (GMT) (envelope-from d@donnacha.com) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id 61B29C89E02; Thu, 5 May 2005 11:17:14 -0400 (EDT) X-Sasl-enc: 70vg/ZhPrWtAKbAzHnPQtutYpor5UaJJRQ3OKMA7I8c2 1115306233 Received: from [127.0.0.1] (82-41-213-217.cable.ubr12.edin.blueyonder.co.uk [82.41.213.217]) by frontend2.messagingengine.com (Postfix) with ESMTP id 621A4570147; Thu, 5 May 2005 11:17:13 -0400 (EDT) Message-ID: <427A391D.5090401@donnacha.com> Date: Thu, 05 May 2005 16:17:49 +0100 From: freebsd.org@donnacha.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <200505051256.j45Cu2rM009492@clunix.cl.msu.edu> <427A1ED5.9050507@donnacha.com> <17018.12641.275076.802782@jerusalem.litteratus.org> In-Reply-To: <17018.12641.275076.802782@jerusalem.litteratus.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Robert Huff Subject: Re: How should I divvy up my HDDs? Suggestions Please. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 15:17:16 -0000 Thanks for taking the time to advise me Robert. > Consider putting the databases (data, not code) in their own > partition. That way they can be backed up, restored, and otherwise > managed independantly of other system operations. > The downside of this is you lose the ability to "borrow" space > from a larger partition. Is MySQL's code usually installed in /var, alongside the DB data? If so, where would you suggest I instead place the code? > As for swap: you've got 2gb ... now. Is there any chance > you'll add more in the future? Then build the system with swap for > that value. Thanks, hadn't thought of that! Seeing as I have plenty of space, I'll make it 4GB per HDD, having lots of swap can't hurt, can it? > As always, spread it multiple spindles for better > performance. Does each disk have multiple spindles? Are they like platters? I am aware that swap should be placed on the outer edge of each disk. >> How big should /tmp be? > > This may be hard to determine. My workstation uses 18k /tmp on > a 500mb / ... except when certain programs are running ("make > buildworld"??). With that much space, you might want to consider: > put /tmp under/, but leave unallocated space (100-500 mb) on the > other drive that could be put into service if that proves > insufficient. Wow, I didn't realize I could get away with using so little space for /tmp. I guess 1GB should cover it then, is that right? > recreate the partition at the new size (using only contiguous > space) Okay, how about the following, leaving plenty of space for resizing partitions at a later date: 80GB HDD: / = 30GB swap = 4GB free space = 46GB 200GB HDD: /db (special partition for database data)= 50GB /var = 50GB (may be a heavy-duty mail server at some stage) /home = 30GB /usr = 10GB /tmp = 1GB swap = 4GB free space = 55GB Does that make sense? Am I leaving enough free space to shift things around at a later stage? Do some of my allocations seem disproportionate? I might also use some of the free space on each disk to hold temporary back-ups of the data on the other. Thanks, Donnacha Robert Huff wrote: > Hello: > > >> In The Complete FreeBSD, Greg Lehey suggests that it's a good >> idea to place web pages in /var, I don't quite grasp why. > > > /var is intended for things with a moderate change rate, for > example mail queues and system logs. (/tmp is for things with a > high change rate.) It's also understood that if something is /var > gets trashed in a crash, core system operations ought not to be > adversely affected. > > >> How big should /tmp be? > > > This may be hard to determine. My workstation uses 18k /tmp on > a 500mb / ... except when certain programs are running ("make > buildworld"??). With that much space, you might want to consider: > put /tmp under/, but leave unallocated space (100-500 mb) on the > other drive that could be put into service if that proves > insufficient. > > >> As for databases, I'll have a lot of MySQL DBs and possibly, at a >> later date, Postgresql. I'm hoping to specialize in forum-based >> web-sites and Web apps generally. As I understand it, forum >> content is actually stored in the DB and pulled dynamically via >> PHP, meaning, I think, that the DB of each forum will take up a >> lot more space that the templated PHP pages that make up the >> "site" part of the equation. I could be wrong about that. > > > Consider putting the databases (data, not code) in their own > partition. That way they can be backed up, restored, and otherwise > managed independantly of other system operations. > The downside of this is you lose the ability to "borrow" space > from a larger partition. > > >> Here's a pretty stupid question I have, apologies for my lack of >> clue: do I have to define the size of each partition? > > > Yes. > > >> Is it difficult to change them at a later date? > > > The only sanctioned way to change partition size is: > > unmount the partition > back up the contents > delete the partition > recreate the partition at the new size (using only contiguous > space) > newfs the partition > restors from backup > > If you need to add space to a otherwise functioning filesystem, > and you have open positions on your IDE cables, look into using > "ccd". > > As for swap: you've got 2gb ... now. Is there any chance > you'll add more in the future? Then build the system with swap for > that value. As always, spread it multiple spindles for better > performance. > > > Robert Huff