On Mon, 20 Sep 1999, Greywolf wrote:

> On Mon, 20 Sep 1999, Leo Weppelman wrote:
> 
> # On Mon, Sep 20, 1999 at 12:48:53PM -0700, Bill Studenmund wrote:
> # > On Fri, 17 Sep 1999, Leo Weppelman wrote:
> # > > 
> # > >   * The basis of the generic-label is the current dislabel definition
> # > >     (as defined in 'include/disklabel.h'). The additions are:
> # > >       - 52 (2*26 == [a-zA-Z]) partitions (MAX_GENERIC_PARTITIONS)
> # > 
> # > I'd vote for 64 partitions, and shoving the "whole disk" one at #63. For
> # > now, ports could keep shoving a "whole disk" partition at #2 or #3 (c or
> # > d).
> # 
> # I started out with the 64 idea myself until I tried to think up the name
> # of partitions above 52 ;-) So, do you have a suggestion?

I'd vote for X Y Z aa ab ac ad ae af ag ah ai "" for partiton 49 -> 63.

> Let's see, since names are for organic lifeform readability only, we
> have some choices:
> 
> 	use /dev/$disktype$disknum$delim$partition_index, where
> 		$disktype == sd, wd, hd, xy, whatever;
> 		$disknum should be obvious;
> 		$delim would be one of nothing at all or some compatible
> 			character, probably one of @,%+=-_~.:
> 		$partition_index would be from 0[0]-64, 0[0]-3f
> 
> 	Super-partitioning, i.e. /dev/sd0a.a, with links from
> 	sd0a -> sd0a.a, sd0b -> sd0a.b (or something similar) 
> 
> 	Use funky characters, i.e. /dev/sd3[@#%+=-_~,.].

I don't know if they are shell-happy characters..

> As well, I think that sd0 should point to the 'whole partition' as
> a physical entity of its own rather than depending on compiled-in
> magic, i.e. it happens at MAKEDEV time.

I agree. It'd be partition 63 to keep it out of the way (and it's the ""
entry above).

> Are we going to hit the point where it might actually make sense
> to reference things like /dev/sd0/a.a or however we name these
> things?

Maybe. I certainly thing /dev/disk would make sense. I have a machine w/
48 disk drives on it. /dev is a mess.. Having more than 8 partitions per
disk would make it even worse.. 

> How many partitions can we fit into the space of a standard disklabel?
> Or are we looking to change the size and format (thus losing compatibility
> with older systems)?

I don't think the thought is we'd be changing the on-disk layout
necessarily. Maybe make an "extended" disklabel format which'd handle this
many partitions, but I think it's more for compatability with other
systems and to not build in limits we'll soon encounter. i.e. on a
multi-booting i386, it'd be nice to be able to automagically see NetBSD,
FreeBSD, 386BSD, Linux, and MSDOS partitions. We wouldn't be storing all
of those partitions in one place, just being able to access them
simultaneously.

> This is all stuff to think about; I thought 22 or 24 was more or
> less the maximum number of partitions a disklabel could support.

22 I believe. But as above, I don't think the idea's to necessarily store
all of these in one BSD disklabel..

> FWIW, if I really needed to do something like this, I'd probably
> reference most of the partitions as ccds and label them that way.

In general, I'd agree.

> Not to mention that I don't see a whole lot of use for many more
> than 16 partitions, as far as intent and purpose go, unless you're
> planning on hosting many dic^Hskless workstations and want each one
> to have its own separate space (which doesn't strike me as extremely
> practical...).
> 
> Or did I miss the question completely?

Not completely.. no. :-) See multi-booting i386 above. Or non-i386 which
was given disk from dead formerly-multi-booting i386. :-)

Take care,

Bill