chris@umcp-cs.UUCP (Chris Torek) (09/20/86)
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@umcp-cs ARPA: chris@mimsy.umd.edu