Location of partition table on disk

[davest at tektronix.UUCP]

In article <7195 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>They had the right idea:  the size and disk location of each partition
>is recorded in the /dev inode for it.

	This does have a certain appeal to it.  After all, we really are
talking about an attribute of the thing you are opening or mounting, so
it makes sense to put it there.

	The disadvantage of this is that inodes contained in /dev are not
in some fixed location on the disk.  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.  In this way,
one could write a standalone facility to repair the partition information
in case of damage.  Alternatively, one might wish to establish the partition
sizes and location as part of a disk initilization operation and thus before
the root partition gets made.

	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 (of course, if we're talking aesthetics, an ugly disk label plopped
someplace is not very symetrical either).

	It would certainly be a better alternative to put the
information in the /dev inode than in the superblock as has
been done in Ultrix.  The Ultrix solution is quite prone to lossage due
to error (I am used to dd-ing the root partition to a spare `a'
partition to use as a shadow root.  This is a fine way to clobber the
partitioning data you may have already put on that disk in the `a'
partition.) However, the best approach to this is one where the
partitioning information cannot be destroyed by some inadvertant
administrator action that may not be discovered until the next
attempted reboot.

	I dislike hiding the information within another system
structure (be it inode or superblock or whathaveyou) that is
susceptable to change without realizing the impact.  I like the
alternative of putting the disk label in a dedicated location on disk
and constraining the disk driver so that the sector cannot be written
unless it is via an explicit ioctl that orders it.  That way, if the
sector *does* get written to, at least the person making the change
`deserves what they get.'

-- 
David C. Stewart                          uucp:    tektronix!davest
Unix Systems Support Group                csnet:   davest at TEKTRONIX
Tektronix, Inc.                           phone:   (503) 627-5418