Date: Thu, 15 Oct 1998 10:43:30 +0930 From: Greg Lehey <grog@lemis.com> To: Graeme Tait <graeme@echidna.com> Cc: FreeBSD Questions <questions@FreeBSD.ORG> Subject: Re: Disk Partitioning (was Clearing /var/mail) Message-ID: <19981015104330.E586@freebie.lemis.com> In-Reply-To: <3624A3A4.1E79@echidna.com>; from Graeme Tait on Wed, Oct 14, 1998 at 06:14:12AM -0700 References: <75B246B6570BD211815E0060B05785010355DF@naeugnt1.netassociates.com> <75B246B6570BD211815E0060B057850148EF@naeugnt1.netassociates.com> <19981014113501.C21983@freebie.lemis.com> <3624A3A4.1E79@echidna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <unused> ~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
> <unused> ~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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981015104330.E586>