Location of partition table on disk

[Henry Spencer]

My, this has stirred up some discussion, both in news and in private mail.
I've thought about it some more, and would like to slightly revise my
previous position...

Clearly, the ideal solution is indeed a self-describing disk, in which all
information about partitioning is on the disk itself.  This is complicated
somewhat by things like striping:  there isn't necessarily a many-to-one
correspondence between filesystems and disks, it can be many-to-many.  The
solution to this might be to define a larger entity, call it a disk group,
with the many-to-one mapping being from filesystems to disk groups, and
the partition information being a property of the disk group.  Each disk
would presumably carry an indication of which part of the group it was.
There are some other ramifications, like the problem of sorting out how
many filesystems there are on a disk -- having this hardwired into the
kernel is inconsistent, since it too is partitioning information.

Apart from the substantial complexity of describing partitioning in the
presence of things like striping, the big problem is the lack of a standard
place to put the information.  It's really hard to come up with something
that can be fitted onto any disk, especially if more than one system wants
to run on it.

If we do NOT go for self-describing disks, then I would contend that the
inode is the ideal place for the information.  Putting it in the driver
is silly, since this information isn't particularly device-dependent in
the usual sense.  (It depends on, e.g., which Eagle is connected, not on
whether it's an Eagle or what type of controller it's connected
via.)  Making it a separate entity within the kernel seems unnecessary.

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.

>	- it does little for removable packs (indeed, it is
>	  quite possibly harmful in such cases);

It's no worse than the current situation.  Indeed it is substantially
better, since one can just use a different set of /dev entries for access
to the pack, rather than having to recompile the kernel.

>	- 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.

> ... It makes sense to put the partitioning
> information in some location where a stanadlone utility, for example, can
> find it without needing to know anything about the filesystem...

This is a valid point.  Putting the information in the inodes is no better
than the current situation, although I would point out that it's no worse.
Sometimes it makes sense to settle for solving some of the problems, rather
than trying for all of them.

> 	Another disadvantage to putting the information in the on-disk
> inode is that you add another bit of fluff to the inode structure that
> will only be used by a very small portion of the total number of the system's
> inodes...

It doesn't have to make inodes any bigger, since much of the space in a
special-file inode is unused anyway.  Typically the device number uses 2
bytes of the 40 available.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry