nessus@athena.mit.edu (Doug Alan) (04/13/88)
I have just hooked up a brand new spiffy Maxtor XT-4380E (a 340
formatted Megabyte, 5.25-inch disk drive) to a VAXstation (running
4.3BSD), and plan on using it with a root partition (a), a swap
partition (b), and a partition for the rest of the disk (g). I have
two options regarding partition tables. Since the disk controller we
are using lets me set things so that the drive is reported to be
whatever I want it to be, one of my options is to tell the drive to
report itself as a very large RD53 or RD54 (standard DEC drives), and
this will work fine. I won't lose any space on the disk, because the
partition tables for the RD53 and RD54 have the 'g' partition set to
go from the end of swap space to the end of the disk, wherever that
may be. If I chose to do this, however, then the 'b' and 'g'
partitions will not start at the beginning of a cylinder, which is
important for the proper performance fine-tuning of a 4.3BSD file
system. (Of course, I *will* create a disktab entry specially
tailored for the XT4380, so at least the number of sectors/track and
tracks/cylinder will be set correctly.)
My other option is to add a partition table to the kernal specifically
for this drive. If I chose to do this, though, I will then need a
special kernal just to use the drive, and this has serious
ramifications on system maintainability. For example, if I boot the
system from your joe random boot tape, I will not be able to access
this drive, because the kernal on it will claim "NO PARTITION TABLE
FOR DISK TYPE: XT43".
So my question is, how much performance will I lose if my partitions
don't begin on cylinder boundaries? Is it worth the hassle of making
up a special boot tape, for example, so that I can begin my partitions
on cylinder boundaries, and thus not lose performance due to incorrect
fine-tuning? Or is the performance-loss due to a partition beginning
in the wrong place negligable? And I shouldn't hassle with special
nonstandard partition tables?
|>oug /\lan
P.S. Maxtor has just come out with a new 5.25-inch drive, the
XT-8760, that is 680 formatted megabytes and only costs $3100.
That's only $4.55 per megabyte! Maybe I'll hook one of those up
too sometime soon.mike@turing.UNM.EDU (Michael I. Bushnell) (04/13/88)
In article <8808@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
[He wants to stick a non-DEC drive on a Microvax-II.]
What we do is make the disk look like an RA-81 or an RD-51. (We have
two different partition tables for the two different kinds.) If you
have to get "standard" kernels to run on it, then I would suggest
making it look like an RA-81>. You will need to fix up your own
/etc/disktab entry, but the kernel reads the disk size at boot time,
and all the other partitions will be the same. This gives the
following picture:
[aaaaaaaa][bbbbbbbbbbb][hhhhhhhhh][ddddddd][eeeeeeee][ffffffff]
[ggggggggggggggggggggggggggg]
[ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc]
The f, g, and c sizes are determined at boot time.
If you make it look like an RD53, then you will still need the special
disktab entry, but you won't have the benifit of separate h and g
partitions.
Yet another possibility, if you don't really care about getting
"standard" kernels to run on them, is to make it look like an rd51.
rd51 is the type the controller returns if it can't determine the
type. That is what we do for almost all our large microvax disks.
Hope this helps.
N u m q u a m G l o r i a D e o
Michael I. Bushnell
HASA - "A" division
14308 Skyline Rd NE Computer Science Dept.
Albuquerque, NM 87123 OR Farris Engineering Ctr.
OR University of New Mexico
mike@turing.unm.edu Albuquerque, NM 87131
{ucbvax,gatech}!unmvax!turing.unm.edu!mikenessus@athena.mit.edu (Doug Alan) (04/16/88)
> What we do is make the disk look like an RA-81 or an RD-51. That will work, but you still have the problem that your partitions are not beginning at the beginning of cylinders. This messes up the Berkeley Fast File System's perfomance fine-tuning. > If you make it look like an RD53, then you will still need the > special disktab entry, but you won't have the benifit of separate h > and g partitions. I understand, but I don't want separate g and h partitions anyway, so this is not a problem. > Yet another possibility, if you don't really care about getting > "standard" kernels to run on them, is to make it look like an rd51. > rd51 is the type the controller returns if it can't determine the > type. That is what we do for almost all our large microvax disks. 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? One percent? Then, who cares. Fifty percent? Then, it's worth caring about. |>oug /\lan
chris@trantor.umd.edu (Chris Torek) (04/18/88)
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
mike@turing.UNM.EDU (Michael I. Bushnell) (04/20/88)
In article <8843@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >> What we do is make the disk look like an RA-81 or an RD-51. >That will work, but you still have the problem that your partitions >are not beginning at the beginning of cylinders. This messes up the >Berkeley Fast File System's perfomance fine-tuning. That isn't too critical. If a partition starts half-way through a cylinder, the first cylinder group of the second partition and the last cylinder group of the first partition will still be "close" on the disk to themselves. The /etc/disktab entries are correct for the particular disk used, and so the cylinder groups are allocated at the right places. >> If you make it look like an RD53, then you will still need the >> special disktab entry, but you won't have the benifit of separate h >> and g partitions. >I understand, but I don't want separate g and h partitions anyway, so >this is not a problem. >> Yet another possibility, if you don't really care about getting >> "standard" kernels to run on them, is to make it look like an rd51. >> rd51 is the type the controller returns if it can't determine the >> type. That is what we do for almost all our large microvax disks. >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? One percent? Then, who cares. >Fifty percent? Then, it's worth caring about. It doesn't damage things that much. The performace disadvantages are NIL. What you MUST do is have a custom /etc/disktab entry for the disk. N u m q u a m G l o r i a D e o Michael I. Bushnell HASA - "A" division 14308 Skyline Rd NE Computer Science Dept. Albuquerque, NM 87123 OR Farris Engineering Ctr. OR University of New Mexico mike@turing.unm.edu Albuquerque, NM 87131 {ucbvax,gatech}!unmvax!turing.unm.edu!mike
mouse@mcgill-vision.UUCP (der Mouse) (04/23/88)
In article <8843@eddie.MIT.EDU>, nessus@athena.mit.edu (Doug Alan) writes: > That will work, but you still have the problem that your partitions > are not beginning at the beginning of cylinders. This messes up the > Berkeley Fast File System's perfomance fine-tuning. What we do in this case is to change the partition table so the partitions *do* begin on cylinder boundaries. Just be careful to give the proper nsect and ntrak numbers to mkfs when you make the filesystem on the resulting partition. By the way, does anyone have a program to run standalone (single-user) which does disk accesses, times them, and tries to guess the geometry of the disk from the timing data? Or guesses the geometry by any other means, for that matter? We have a MicroVAX disk which claims to be an RA81 but is 277712 sectors (2*2*2*2*17*1021). der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu