Subject: Re: partition bookkeeping
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 10/04/1999 11:06:16
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
> 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
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
Would that do what you want?