nessus@athena.mit.edu (Doug Alan) (10/05/88)
The following are a few problems I've had with 4.3BSD on a uVax II in
dealing with disk subsystems that I've put together myself. I'm
wondering whether I'm doing something wrong, or whether these are
known bugs, and whether or not there is a work-around:
(1) If you accidentally attempt to boot a system on a disk drive
for which there is no partition table in the kernal, BSD kindly
trashes the filesystem for you. This is of more than academic
concern, because it has happened to me. This happened when I
built a new kernal, but the distributed version of uda.c got
accidentally used, rather than our modified version. Is there
any work-around for this problem? (Other than being perfect
and never accidentally booting the wrong kernal.)
(2) It appears that the BSD bootblocks will not boot a kernal that
is bigger than a certain size. This happened to me, and it was
very frustrating to figure out what the problem was. I finally
replaced the BSD bootblocks with the Ultrix bootstrap system,
and this fixed things.
(3) In the partition table for a disk drive, a "-1" for the size of
a partition is supposed to mean that the partition contains
everything up to the end of the disk. It seems, however, that
this only works if the disk is less than a certain size. Is
this indeed the case, or am I doing something wrong? If I
could get this to work for any sized disk drive, then I could
make just one partition table for all drives and use the disk
partitioning features of our disk controller to make logical
disk drives in place of the normal BSD Unix disk partition
notion.
I also have a more academic question: A BSD filesystem is supposed to
begin on a cylinder boundary for performance reasons. Is swap space
also supposed to begin a cylinder boundary, or does it make no
difference? I know there's "tunefs", and there's tuna fish, but
there's no "tuneswap"....
|>oug /\lan
(or nessus@athena.mit.edu
nessus@mit-eddie.uucp)
P.S. The hardware I've been dealing with is a VAXstation II with a Sigma
SDC-RQD11-EC disk controller and Maxtor XT4380E, XT8380E, and XT8760E
disk drives.chris@mimsy.UUCP (Chris Torek) (10/06/88)
In article <10194@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: >The following are a few problems I've had with 4.3BSD on a uVax II .... > (1) If you accidentally attempt to boot a system on a disk drive > for which there is no partition table in the kernal, BSD kindly > trashes the filesystem for you. The 4.3BSD UDA50 driver treats unknown disks as type `ra81'. I considered this bogus; the 4.3BSD-tahoe driver considers them to be of type `unknown' (and then gives you a chance to label them). This does not help much with non-DEC MSCP disks, which generally claim themselves to be RA81s anyway. > (2) It appears that the BSD bootblocks will not boot a kernal that > is bigger than a certain size. This happened to me, and it was > very frustrating to figure out what the problem was. I finally > replaced the BSD bootblocks with the Ultrix bootstrap system, > and this fixed things. The 4.3BSD bootblock will not work at all on a MicroVAX II. You have to have been using an old Ultrix bootblock. > (3) In the partition table for a disk drive, a "-1" for the size of > a partition is supposed to mean that the partition contains > everything up to the end of the disk. Yes. > It seems, however, that this only works if the disk is less than > a certain size. No. Any negative number translates into `reported size - partition offset'. If the disk reports its size incorrectly, VMS does not work, so no disks report their sizes incorrectly. >I also have a more academic question: A BSD filesystem is supposed to >begin on a cylinder boundary for performance reasons. Is swap space >also supposed to begin a cylinder boundary, or does it make no >difference? I know there's "tunefs", and there's tuna fish, but >there's no "tuneswap".... It hardly matters, but if everything else starts and ends on a cylinder boundary, the free region(s) left over for swap space will do so as well. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
loverso@xenna.Encore.COM (John Robert LoVerso) (10/07/88)
In article <10194@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes: > The following are a few problems I've had with 4.3BSD on a uVax II... > > (1) If you accidentally attempt to boot a system on a disk drive > for which there is no partition table in the kernal, BSD kindly > trashes the filesystem for you. In the recent "4.3-Tahoe" release, BSD now will store disk partition information on the pack itself, thus completely preventing this type of problem. > Is swap space also supposed to begin a cylinder boundary, or does > it make no difference? It makes no difference, but you'll make better use of your space by using whole cylinders. John R LoVerso Encore Computer Corp encore!loverso, loverso@multimax.arpa, [full moon only: loverso@encore.com]
mike@turing.unm.edu (Michael I. Bushnell) (10/10/88)
In article <10194@eddie.MIT.EDU> nessus@athena.mit.edu (Doug Alan) writes:
~The following are a few problems I've had with 4.3BSD on a uVax II in
~dealing with disk subsystems that I've put together myself. I'm
~wondering whether I'm doing something wrong, or whether these are
~known bugs, and whether or not there is a work-around:
We did this quite a lot (we are going to stop now that we have the
disklabeling drivers...)
~ (1) If you accidentally attempt to boot a system on a disk drive
~ for which there is no partition table in the kernal, BSD kindly
~ trashes the filesystem for you. This is of more than academic
~ concern, because it has happened to me. This happened when I
~ built a new kernal, but the distributed version of uda.c got
~ accidentally used, rather than our modified version. Is there
~ any work-around for this problem? (Other than being perfect
~ and never accidentally booting the wrong kernal.)
It is probably trashing the filesystem because it is swapping on it.
A pain, yes, but this is fixed in tahoe by the use of a disklabel on
the disk. The kernel will use the label on the disk and not an
internal hard-coded partition table.
~ (2) It appears that the BSD bootblocks will not boot a kernal that
~ is bigger than a certain size. This happened to me, and it was
~ very frustrating to figure out what the problem was. I finally
~ replaced the BSD bootblocks with the Ultrix bootstrap system,
~ and this fixed things.
This happened to me too when I made a significantly larger generic
kernel. The problem is that boot is not relocating itself high enough
for the kernel to fit in underneath. Change RELOC in
/sys/stand/Makefile to something larger.
~ (3) In the partition table for a disk drive, a "-1" for the size of
~ a partition is supposed to mean that the partition contains
~ everything up to the end of the disk. It seems, however, that
~ this only works if the disk is less than a certain size. Is
~ this indeed the case, or am I doing something wrong? If I
~ could get this to work for any sized disk drive, then I could
~ make just one partition table for all drives and use the disk
~ partitioning features of our disk controller to make logical
~ disk drives in place of the normal BSD Unix disk partition
~ notion.
That is exactly what we do. I don't know why it doesn't work for you.
N u m q u a m G l o r i a D e o
\ Michael I. Bushnell
\ HASA - "A" division
/\ mike@turing.unm.edu
/ \ {ucbvax,gatech}!unmvax!turing.unm.edu!mike