Location of partition table on disk

[mojo at sun.UUCP]

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.
If you are talking about changing the partitioning dynamically, then
you have to make sure that file systems are remade if the partition
is shrinking.  In any case having a standalone program that changes
the partitioning info per disk allows for additional flexibility.
I don't believe that there "has always been a bootstrapping problem"
on all systems.

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

Again - what is your model of the world?  The current Vax 4.x disk
layout is *not* what everyone has.  I agree that having to recompile
the kernel for these types of things is wrong, wrong, wrong.  Having
partitioning info read per disk handles things like removable packs
correctly.

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

I disagree with the use of the word "just" here - it is no where as hard
of a problem.  While having VMS read Unix directory formats is really
wrong, having more than one OS or file system type understanding disk
labeling and partitioning is possible and seems usable.  Why go with a
layout that will forever precludes sharing disk labeling/partitioning?
While it might seem hard for you to believe that VMS/Unix disk
partitioning could happen, I am an optimist and see it differently.
If, for example, someone implements a VMS file system type under Sun's
vnode as a different file system type, it seems bogus to have a disk
which has both VMS and Unix file systems on it to have one file system
type or the other control partitioning of the disk.  It still seems to
me that this is a per disk pack sort of thing at a different level from
the file system implementation.

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

Again I disagree as I think you are thinking just about the current
Vax Unix situation only.  When the partitioning is read off the disk,
having the information in the inode seems much worse here.

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

Agreed that there are ways to load up the bits.  But the point here not
the inode size, rather I think it is the inode concept.  With your
proposed approach you are making making "yet another a special inode
type".  Gee, we could talk about overloading all 40 bytes for device
inodes with "super minor numbers" which can be interpreted all over the
OS!  The thing that seems to get messy here is where these things
are interpreted.  The device driver is normally the one interpreting
the disk partitioning, yet the file system implementation would seem to
be the one looking at the inode partitioning info.  It just doesn't
seem real clean to me.

The inode partitioning approach does have some advantages (personally I
think the no hard limit on number of partitions the best one), but
overall I think that reading the partitioning information off the disk
is a FAR better way to go.  Please remember that comparing new
partitioning schemes to the current 4.3 scheme isn't the right way to
go as that stuff is a mistake in itself.  There are other folks that
have a more sane approach to these types of problems and that "the
current situation" is not always the "partitions compiled in the
kernel" scheme.

	Joseph Moran
	{ihnp4, decvax, seismo, decwrl, ...}!sun!mojo
	mojo at sun.COM (or mojo at sun.ARPA)