Want info on disk label implementations

[Chris Torek]

I have grown rather tired of altering disk drivers to hold the
correct partition tables for various systems, and have decided
to do something about it.  Towards this end I need answers to
several questions.

First, the easy one:  There is at least one existing implementation
out there already for Vaxen, namely the one in Ultrix.  If anyone
can send me details on this format (or any other existing formats)
without violating licencing restrictions, I would appreciate it.
If I must reinvent the wheel, I would rather have one that is
interchangeable with others.  All I know now is that Ultrix puts
the partition table after the end of the primary superblock, in
the second 8K block on the drive.

Now a harder question:  Where *should* disk labels appear?  The
obvious choice is at the beginning of the disk.  However, the first
8K is `reserved'.  The first block is a micro-boot which reads the
next 7.5K as a milli-boot; this then reads /boot as a real boot.
As it happens, only the first few bytes of the first 512 byte block
is currently used on any Vax boot, but this seems a bad thing to
trust.  That leaves a region in the next 8K.  The first part of
this is normally the primary superblock on the `a' partition, but
there is quite a bit left over; the last sector seems a prime
candidate.

Another option is to put the label at the *end* of the disk, just
before any bad sector information.  This option I like rather less,
for one must know the size of the disk in order to find the label.
Yet there may well be cases where the only way to find the disk
size is to read the label.  (This is common in many SCSI systems.
Most Vaxen have `real' :-) interfaces, but it seems to me short-
sighted to ignore the possibility.)

Finally, if for some reason I do not use some existing label format,
what information should appear in a disk label?  Certainly there
should be a verifier (magic number and/or checksum), a set of sizes,
and a comment.  It seems reasonable also to include fields for
sectors per track, et cetera.  What else?  We have 512 bytes to
burn. . . .
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu