On Mon, 4 Oct 1999, der Mouse wrote:

> >> (b) [this] limits you to a max of 63 partitions per drive.  (The
> >> latter seems like infinity now, perhaps, but with drives pushing
> >> 100GB, I'm not at all sure it'll stay that way.)
> > I doubt we'll need more than 63 partitions, but I can be wrong.
> 
> "640K ought to be enough for anybody."

True. But the difference here is 63 partitions is not a limit on how much
you can store on a disk, but how many filesytems you can break it up into
easily. :-)

> I have no immediate use for anywhere near 63 partitions.  But I already
> have a real-life example of needing more than 8:
> 
> /dev/sd0a         19823     9958     8873    53%    /
> /dev/sd0g         74415    51555    19139    73%    /usr
> /dev/sd0d         24791    19348     4203    82%    /var
> /dev/sd0e         19823     3979    14852    21%    /tmp
> /dev/sd0h         49599     1402    45717     3%    /local-machine
> /dev/sd0i        744271   531940   175117    75%    /locals
> /dev/sd0k        205375    14873   180233     8%    /backups
> /dev/sd0j        496175   370624   100742    79%    /mouse
> /dev/sd0f        148847    42199    99205    30%    /anne
> (plus b, swap, and c, raw, which don't appear on this list - total 11).
> 
> >> By "recursive partitioning" I mean that any partition can itself be
> >> partitioned.  That's "any partition".  Not "any MBR partition".
> > That is something different than I've been talking about.  But I've
> > really got to ask, "Why?" :-)
> 
> Why not?

Because to do it right is not easy. We'd really need a devfs with
persistent storage. Otherwise just booting and inserting removable
(wired-down even!) media in different orders can mess things up.

> To me, both lots of partitions and recursive partitioning (my
> definition) are examples of things that seem stupid but are reasonably
> likely to turn out to be clever.  "UNIX doesn't prevent you from doing
> stupid things because that would also prevent you from doing clever
> things."

I'm sorry. I never meant to say the idea of recursive partitioning of any
partition was stupid. :-) I just think that to do it in a own-minor wedge
scheme (where it would shine the most) will require much more work.

> I don't know what the "clever things" are in this case.  I'm fairly
> sure someone will come up with some. :-)
> 
> > [W]hy should we permit the subpartitioning on a partition when we can
> > support more partitions overall?
> 
> Working with disk images?  I'm likely to be setting up a co-loc machine
> before so very long.  I'll probably set it up with a small 80M drive I
> have spare.  It'd be nice to be able to create an 80M partition on one
> of my big disks and do all the setup there.  Currently I'd have to do
> it in a file with a vnd.
> 
> To solve the MBR problem?  I really dislike throwing in a special-case
> solution to this sort of problem (allowing other partitioning schemes
> within an MBR partition) when a more general solution is apparent and
> not that much harder (full recursive partitions).

What we could do, which sounds like it would satisfy your concerns, is
something inbetween. I've been arguing against giving wedges their own
major number, and just assigning 63 per device. Our current disklabel
struct can't hold that many in one sector - actually only 22 will fit. So
what we could do is if we find disklabels in the partitions in the initial
system, we dump their disklabels after the intial disklabel (well, aster
the first 22 so that the overall disklabel's growth won't move things
around).

Would that do what you want?

Take care,

Bill