Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!mailrus!rutgers!umd5!trantor.umd.edu!chris
From: chris@trantor.umd.edu (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Cylinder boundaries in 4.3BSD
Message-ID: <2567@umd5.umd.edu>
Date: 17 Apr 88 22:13:49 GMT
References: <8808@eddie.MIT.EDU> <947@unmvax.unm.edu> <8843@eddie.MIT.EDU>
Sender: ris@umd5.umd.edu
Reply-To: chris@trantor.umd.edu (Chris Torek)
Organization: University of Maryland, College Park
Lines: 26

In article <8843@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
>If I don't care about getting standard kernals to run on them, I'd
>just use my own customized partition table, and then I'd get the
>fine-tuning right.  The question is how much will using a standard
>partition table, which has not been customized for a nonstandard
>drive, degrade system performance [in 4.3BSD]?

I have no numbers, but I do have a `gut feel' answer.  Nothing
makes much difference on RA disks, probably because of the large
head switch delay, and possibly because of any reordering done
inside the controller itself.  If you are using a non-DEC disk the
first factor vanishes, so it may become important.  It should be
easy enough to try it and see.

It may become important in the future, anyway, whenever Kirk gets
around to implementing the head-switch-delay factors in the block
allocator.  But by then you will have per-drive partition tables.
(Unfortunately, the boot code demands a standard drive or a label,
so if you label a nonstandard drive, and the label gets wiped out,
you are stuck.  The UDA50 driver allows the kernel to open an `a'
partition covering the entire drive if there is no label and no
default 4.2BSD-compatibility entry; maybe the boot code should do
the same.  In any case there ought to be a standalone make-a-label
program.)
-- 
In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163
Domain: chris@mimsy.umd.edu		Path: ...!uunet!mimsy!chris