Location of partition table on disk

[Henry Spencer]

> I still believe there is a fundamental bootstrap problem with 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 don't believe
> that there "has always been a bootstrapping problem" on all systems.

There is no chicken-and-egg problem with inode partitioning:  you do
bootstrapping the same way most Unixes do it now, i.e. the kernel knows the
location of the bootstrap partition.  This is a little unclean, but I never
claimed that inode partitioning was an answer to all the world's problems --
just some of them.  Self-describing disks don't solve all the problems
either, since they still have the fundamental bootstrap problem I alluded to,
to wit knowing which partition on which drive to boot from.  (Yes, Virginia,
there are people who have more than one kind of drive, so "drive 0" isn't
a sufficient answer.)  Self-describing disks are not a panacea for the
bootstrap problem.  They do simplify the problem of knowing where the chosen
partition is, although I would comment that this is seldom much of an issue,
since most people put the usual boot partition first on the drive anyway.

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

This was precisely my point -- inode partitioning can handle this situation
correctly too.  You just need a different set of inodes for a different
pack.  Not as graceful or as automatic as self-describing disks, but a
major improvement on the current situation.

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

I should have been more explicit here.  I didn't mean it was unbelievable
because there was anything technically hard about it; I meant it is
unbelievable because that degree of cooperation from the VMS world is
totally implausible.  VMS, read *somebody else's* idea of partitioning
information?  Don't you know that VMS is The Only operating system for the
VAX, by royal decree?  (You and I, benighted heathens that we are, may not
know this, but the VMS group within DEC sure does.)  No, there is no real
technical reason why different operating systems cannot share partitioning
information, but this is an inconsequential argument because the probability
of it actually happening to any extent is just about zero.

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

Nonsense, all I'm doing is adding a few more fields to an *existing*
special inode type, to wit the block-special-file inode.

> ...  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 most straightforward implementation just remembers the information
and passes it to the driver at the right times.  The file system
implementation doesn't have to know what it means or how to interpret it,
any more than it knows how to interpret block numbers as disk addresses.
All it knows is "if I hand this to the disk driver, it will do the right
things with it".

> The inode partitioning approach does have some advantages ... 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...

Overall, I agree that reading the partitioning information off the disk
is a better way to go.  *If* you can swing it.  It's not easy to retrofit
into existing implementations that just don't *have* any convenient place
to put the information on the disk.  Inode partitioning lacks that problem.
It provides fewer benefits, but at potentially lower costs for existing
systems.  I agree that self-describing disks are preferable for new work.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry