From owner-freebsd-questions Wed Oct 14 18:13:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA03106 for freebsd-questions-outgoing; Wed, 14 Oct 1998 18:13:59 -0700 (PDT) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA03072 for ; Wed, 14 Oct 1998 18:13:53 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id KAA03170; Thu, 15 Oct 1998 10:43:33 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id KAA01724; Thu, 15 Oct 1998 10:43:30 +0930 (CST) Message-ID: <19981015104330.E586@freebie.lemis.com> Date: Thu, 15 Oct 1998 10:43:30 +0930 From: Greg Lehey To: Graeme Tait Cc: FreeBSD Questions Subject: Re: Disk Partitioning (was Clearing /var/mail) References: <75B246B6570BD211815E0060B05785010355DF@naeugnt1.netassociates.com> <75B246B6570BD211815E0060B057850148EF@naeugnt1.netassociates.com> <19981014113501.C21983@freebie.lemis.com> <3624A3A4.1E79@echidna.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <3624A3A4.1E79@echidna.com>; from Graeme Tait on Wed, Oct 14, 1998 at 06:14:12AM -0700 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wednesday, 14 October 1998 at 6:14:12 -0700, Graeme Tait wrote: > Greg Lehey wrote: > >> It's difficult to do it with a symlink alone, since that would >> effectively rename the directory. You can move everything to a >> different file system and have symlink pointing to the new location; >> in fact, that's what I do. This is one reason why I recommend to have >> only one file system on a disk. > > Could you please explain this? Certainly. > I ask because I recently purchased a couple of systems from a supplier who > installed FreeBSD for us. Being a beginner, I accepted his recommendation (see > below), which seems to go to the other extreme. Indeed. I've seldom seen so fragmented a disk, especially as he was talking of only using about 25% of the disk. > I take it that the use of s1c in the original scheme is an oversight, and that > you can't do that? It could have been an error. You *can* do that, but you'll screw up all sorts of things on the way. > But if you look at the final allocation of disk 1 below now, there are 7 > partitions used and cylinders still unallocated. How can those cylinders be > allocated now? They all look allocated to me, they just have little in common with the original idea. But I disagree strongly with the approach. > The other thing I don't understand about this setup is that it is running CAM > (2.2.7-STABLE + CAM), but the SCSI disks turn up in disklabel as sd* rather than > da*. Does this matter? It seems you can refer to the disks as both sd* and da* > when you do disklabel -r, etc. Correct. The new device node names are da ("direct access") for disk and sa ("serial access") for tapes. There's been a certain resistance to the new names in -hackers, but the good thing is that a SCSI disk by any other name would access the same. You should ensure that you have the da and sa nodes in /dev, but it doesn't really do any harm to refer to them as sd. > His original recommendation was as follows (the disks are 4.5GB U2W SCSI): > --------------------------------------------------------------------------- > > As far as the install goes, the only info I'd want would be partitioning > info. Here is what I'd recommend, but feel free to tell me where to go if > it won't suit your needs: > > Disk1: s1a / 200 MB will include /etc /stand /root, etc > s1b swap 128 MB need at least as much swap as RAM > s1c /usr 200 MB most of /usr will be below... > s1d,na /usr/src 250 MB system source code (kernel + apps) > s1e,na /usr/ports 300 MB Ports + room for src, compiles > s1f /tmp 300 MB > s1g /var 200 MB for mail, news, logs, etc. > s1h ~3000 MB /home, /public_html, ??? > > Disk2: s1a swap 128 MB using 2 disks for swap = 2x speed > s1b /usr/X11R6 300 MB X11 libs, exec, man, bin > s1c /usr/local 700 MB All apps from ports, pkg, & you > s1d /usr/obj 350 MB object files from make world > ~3000 MB ??? > > The above setup is the optimal for FreeBSD, I disagree. He's trying to guess future usage. For example, he's allocated 250 MB for /usr/obj, which will leave about 220 MB for files. My /usr/src has 253 MB now, so it would already have overflowed. Even if you allocate 300 MB, you can expect it to overflow some time. > but perhaps not the optimal for administration. Not for administration either. > If these machines get hit hard and need really good IO, above is the > way to go. I think he doesn't understand how ufs works. His approach would have certain advantages of locality of reference under older file systems, but UFS keeps file data close together. > Splitting data across disks improves perfomance > (esp. /usr/src and /usr/obj, Well, yes, if you spend all your time doing 'make world'. > and different swaps). This is definitely an advantage, assuming you swap. > Having /usr/ports, /usr/src, and /usr/obj on their own partition > imporves anything that searches for files, since you can unmount > these directories when not used (almost always!) and eliminate > almost 100,000 files from the tree. Hmmm. You can do all sorts of things. In a multi-user environment you shouldn't be umounting file systems for the benefit of one user. The flaw with having separate file systems for /usr/src, /usr/obj and /usr/ports is that the sizes of these hierarchies are pretty constant anyway; you gain no security by limiting their size, and you gain the insecurity of having to completely repartition the disk if your original estimates turn out to be wrong. > --------------------------------------------------------------------------- > > As installed, it became: > --------------------------------------------------------------------------- > # Device Mountpoint FStype Options Dump Pass# > /dev/da0s1b none swap sw 0 0 > /dev/da1s1b none swap sw 0 0 > /dev/da0s1a / ufs rw 1 1 > /dev/da0s1h /tmp ufs rw 2 2 > /dev/da0s1e /usr ufs rw 2 2 > /dev/da1s1e /usr/obj ufs rw,noauto,async,noatime 2 2 > /dev/da0s1g /usr/ports ufs rw,noauto,async,noatime 2 2 > /dev/da0s1f /usr/src ufs rw,noauto,async,noatime 2 2 > /dev/da0s1d /var ufs rw 2 2 > /dev/cd0c /cdrom cd9660 ro,noauto 2 2 > proc /proc procfs rw 0 0 > --------------------------------------------------------------------------- > ... > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 409600 0 4.2BSD 0 0 0 # (Cyl. 0 - 25*) > b: 524288 409600 swap # (Cyl. 25*- 58*) > c: 8888924 0 unused 0 0 # (Cyl. 0 - 553*) > d: 409600 5849088 4.2BSD 0 0 0 # (Cyl. 364*- 389*) > e: 3072000 933888 4.2BSD 0 0 0 # (Cyl. 58*- 249*) > f: 512000 4005888 4.2BSD 0 0 0 # (Cyl. 249*- 281*) > g: 716800 4517888 4.2BSD 0 0 0 # (Cyl. 281*- 325*) > h: 614400 5234688 4.2BSD 0 0 0 # (Cyl. 325*- 364*) > --------------------------------------------------------------------------- The only valid reasons for more than one partition on a drive are: 1. Security. If you screw up a file system, you usually don't screw up the others. This happens very seldom nowadays, however. 2. To limit the size of the hierarchies, so that one user can't monopolize things. For that we use quotas, which can be changed as requirements change. If you really do need extensibility, take a look at Vinum (http://www.lemis.com/vinum.html). > -- > Graeme Tait - Echidna That's an interesting name from time zone -7. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message