Location of partition table on disk

[H. Munster]

I think that the partition info belongs on the disk, along with anything
else needed to mount or boot off of a disk.  This will make life much
easier and safer for folks who use removable packs, and for those who
have to change their partitioning frequently.  A partition table should
contain the following:

disk geometry info (sectors/track, tracks/cyl, etc)
location of partition boundaries (obviously)
location of bad block table and spare tracks, and (maybe) a flag indicating
  what sort of bad block replacement algorithim is in use (mapping to spare
  sector, sector "slipping", etc)
a flag for each partition indicating what sort of thing the partition is
  (BSD partition, SYS-V partition, raw data, swap, etc).  The mount routines
  should mount only partitions of the proper type, and the swapon routines
  should refuse to start swapping on a partition that isn't designated as a
  swap partition.  Also, standalone disk diags that scribble on a portion
  of the disk to test write functions should issue a "are-you-sure-you-want-
  to-do-this" prompt if the area being used isn't a swap partition.
a volume or set number, for implementing multivolume file systems (for
  instance, Chris Torek's striping setup).
(perhaps) a partition label for each partition
ECC code (or even a backup copy of the table if there's room)

Resist the temptation to put info relating to mountable file systems in the
partition table.  Such info belongs in the file system's super block.

About the space problem: Is it safe to assume that every disk used in the
UN*X world has at least 8 512-byte sectors per track?  If so, there should
be at least 2k bytes for the table, as I've never seen a first-level bootstrap
that was larger than 2k (except for the VMS boot on 780's, but it loads that
off of a floppy).

Now, a related subject:

In article <8102 at sun.uucp>, mojo at sun.UUCP (Joseph Moran) types:

>In article <7221 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>>To answer some specific comments:
>>
>>> 	- there is a bootstrap problem (avoided by compiling
>>> 	  in the root partition info);
>>
>>There has always been a bootstrapping problem:  the kernel has to know
>>where the root is.  Not even self-describing disks will help this if
>>there is more than one possibility.  Using the inode to hold partitioning
>>information doesn't solve this problem, but nothing else does either.
>
>I still believe there is a fundamental bootstrap problem with the inode
>partitioning approach which you don't get it you do it `right'.  In the
>inode partitioning approach you have to have a file system open (which
>means you have to know partitioning info) before you can read the inode
>to get the partitioning info.  If the partitioning info is read off of
>the physical disk and you know which partition you want to use (e.g.
>the `a' partition), then you don't have any problems.  I'm not sure
>what you are thinking about when you say "more than one possibility",
>?_but if you want to boot off something other than the `a' partition,
>then the boot procedure should be set up to allow it and that's it.

I think what he means is the old problem of "how does the kernel know what
drive it was booted from?"  Well, on Gould machines, the console bootstrap
sequence leaves the boot device # in a register, and locore.s fetches it,
converts it to a major/minor number, and feeds it to the init routine.
Therefore, there's no need for specifying the root device at sysgen time,
and no problem with moving a pack that contains a root to another drive
and booting it.  (In the standard BSD setup, you have to specify the root
and swap devices at sysgen, and if you move the root pack to another drive
and try to boot it, it may overwrite data on the original drive when it
tries to turn on swapping.)  Other hardware developers should provide
this kind of feature.  "Fine and well," you say, "where does that leave
the rest of us with Vaxen or whatnot?"  Well, you could have a startup
routine that is called at cold-start time which goes through the CSR's
of each drive that the kernel knows about and looks for the one that
has an interrupt request outstanding (assuming that the initial boot is
done with interrupts disabled or blocked).  I realize that this would
be a problem since it's done way before autoconfig, but it's something
to think about.  A P.S.: is there a great demand for the ability to boot
from partitions other than the 'a' partition?  It would be nice, but I
personally could live without it if it means major work on the bootstrap
sequence.  Does anyone out there need this?

Another subject:

>>>	- it discourages sharing the information among operating
>>>	  systems (VMS to read Unix /dev directories anyone?).
>>
>>VMS to read Unix partitioning information anyone?  That's just as hard to
>>believe.
>
>While it might seem hard for you to believe that VMS/Unix disk
>partitioning could happen, I am an optimist and see it differently.

Although I too would like to see more operating systems able to coexist on
a single disk, I just thought I'd point out that, currently, VMS has no
concept of disk partitioning, and there doesn't seem to be a great demand
among VMS users for it.  (That's a flame for another article...)

Finally: I think that a good access method for reading/modifying partition
and bad block tables is to set up special partitions (and minor numbers) for
them (e.g., the bootstrap/partition table area is the 'x' partition, and the
bad block table is the 'y' partition).  This way, a utility that reads or
modifies the partition table can just open a raw device (say "/dev/rdk0x")
and use ordinary reads and writes; I'd prefer this to turning another set of
ioctl's loose in the world.  Of course, none of the ordinary partitions
should include either of these areas (not even the 'c' partition).

Thoughts?
---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.

Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP:  ...{sun,pur-ee,brl-bmd}!gould!dcornutt
 or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."