From owner-freebsd-questions@FreeBSD.ORG Wed May 11 17:20:27 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 1EA9816A4CE for ; Wed, 11 May 2005 17:20:27 +0000 (GMT) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75EC043D7D for ; Wed, 11 May 2005 17:20:26 +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 003AEC8E1A2; Wed, 11 May 2005 13:20:24 -0400 (EDT) X-Sasl-enc: QjC3JKacZCAcOSANg+nQp2vkIDpWU6xM2DMAAQjYw+4o 1115832024 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 D2910570147; Wed, 11 May 2005 13:20:23 -0400 (EDT) Message-ID: <42824021.9000108@donnacha.com> Date: Wed, 11 May 2005 18:25:53 +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: <42822285.9050402@donnacha.com> <42823AB1.3050704@mac.com> In-Reply-To: <42823AB1.3050704@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: I need further HDD advice before submitting order. 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: Wed, 11 May 2005 17:20:27 -0000 Hi Chuck, thanks for responding. > ... For what it's worth, I'd rather have two 80GB > drives in a RAID-1 mirror than have my stuff on two seperate drives, but > using software RAID like vinum/gvinum, you can still mirror 80GB onto > the 200GB drive, and have an additional 120 GB of space left over. That does sound like a good idea, especially if it's something I can introduce at a later stage. > [ You don't have to do anything about that now, if you do leave an 80 GB > chunk of space uncommitted on the big disk. ] By uncommitted do you mean space that I keep completed unallocated or can it be space in which, following Jeremy's suggestion, I create a temporary file system that I keep empty until I learn how to use vinum/gvinum? Thanks, Donnacha > >> ---------- >> >> Server purpose: Initially just forums, later sundry other Web apps >> i.e. ecommerce, ticket bookings etc. Will possibly become a >> heavy-duty email server at some stage. >> >> 2GB RAM >> >> 80GB HDD IDE: >> / = 1GB >> /usr = 15GB >> /local = 15GB >> Swap = 4GB >> Unallocated = 40GB >> >> 200GB HDD IDE: >> >> /tmp = 2GB (is that enough?) >> /home = 28GB >> /var = 100GB (will inclube the forum databases etc) >> Unallocated = 70GB >> >> I'll be asking them to put the both disks in dangerously dedicated >> mode, with each on a different IDE bus. > > > Don't use "dangerously dedicated mode" for your boot drive. Reserving > the 63 sectors at the beginning for a MBR-style layout is a trivial > waste of space compared with the hassle of not being able to boot from > the drive > >> Is it a good idea leaving so much unallocated space? My research >> suggests that this may be useful for moving directories around or >> giving specific subdirectories their own partition at a later date >> when I have a better idea of usage, does that sound right? > > > Yes, it's a good idea. There is nothing wrong with configuring all of > the space to be used if you want to do so and you know what the usage > and growth are going to be. However, if you are not certain about how > various filesystems grow, there is a real advantage to having some > unallocated space handy. > >> The only problem about creating partitions at a later date is that I >> will have command line access only, I'm not even sure if I can create >> partitions at a later date, I think that for sysinstall I might >> actually have to be there. Can anyone advise me on this? > > > You can run /stand/sysinstall remotely via the command line, if you like. > > Either way, you can adjust the partition table and create new > filesystems later on without a problem. > >> Swap: As the second disk will have the presumably quite busy /tmp and >> /var, placing all the swap on this the first disk, rather than shared >> between both, could help to balance the load a bit (thanks to Henry >> Miller for that suggestion). With 2GB of RAM, I'm hoping the Swap >> won't be needed very often anyway; if it is, I may simply add more >> memory. > > > You want to have your swap partition be a little larger than the amount > of RAM you have; use 2.5 or 3 GB for swap. > > The biggest problem I see with your layout about is that you don't have > a complete bootable system on just the 80 GB drive. If you start moving > disks around between machines, for some reason (whether it's to add > another box to split the workload, or because one of the drives is > showing failure signs and needs to be replaced), you may really regret > doing so. > > I'd be happier with: > > 80GB HD: > / 1 GB > swap 3 GB > /tmp 6 GB > /var 20 GB > /usr 20 GB > /home? 30 GB maybe, or might leave unused > > Do this as two FDISK partitions, the first with a bootable system via > BSd partition slices, the second as /home or unused. > > 200GB HD: > unused 80 GB reserved at beginning of disk, either for possible > mirror or as needed for another filesystem based on growth > swap 3 GB (optional, could be put in the 80 GB slice above) > /local 40 GB I'd call this /opt, myself :-) > /home? 40 GB maybe I'd put /home here, and not on the 80 GB > unused 40 GB for a while until you see which filesystems grow and/or > to balance disk utilization... > > Do this as 4 FDISK partitions. > > The thing is, 20 GB will still fit a ton of stuff in /var. When it > starts getting full, take your biggest database or the forums or > whatever, and move it to it's own partition using the 30 or 40 GB of > space left uncommitted, and use a symlink so the old path still works... >