On Thu, 28 Dec 2000, Chuck Silvers wrote:

> On Thu, Dec 28, 2000 at 01:48:16PM -0500, Todd Vierling wrote:
> > On Thu, 28 Dec 2000, Chuck Silvers wrote:
> > 
> > : the only completely backward-compatible way to increase the number
> > : of partitions is to create a new device major number for each current
> > : device major that uses part of its minor as a partition.

I agree with this.

> > There comes a point where supposition leads into ludicrous situations, and
> > this is one of them.  If the extra partition bits are placed sufficiently
> > high in the minor number to provide a reasonably large number of units (say,
> > 16384 drives?), someone will have had to create nodes with ridiculously
> > large unit numbers to conflict with them.

[bit from Todd discussing 3rd party patches breaking & Chuck saying that's
another discussion]

> however, the use of high minor numbers to represent normal disks is
> a currently supported feature of the official NetBSD distribution,
> and changing the interpretation of the minor number would break that.

Think about what this will do for minor numbers too. Assuming we only make
room for 16 partitions (which strikes me as way too small - if we change,
we should go to 64), partition i will have a radically different minor
offsets on different ports. Some ports already support 16 partitions/disk,
so this change will make wd0i minor 8 on some ports and minor 1048576 on
others.

Ack! ls -l will make little sense!

> > : I think we should consider a logical volume manager design
> > : rather than continuing to fiddle with fixed-partitioning.
> > 
> > That's not addressed by this thread, and does not help people who want this
> > feature right now.
> 
> the feature that people want is not "increase MAXPARTITIONS", it is
> "allow me to divide my disks into more logical devices".  a logical volume
> manage would provide this feature in a more flexible way than just
> increasing MAXPARTITIONS.  for example, increasing MAXPARTITIONS from
> 8 to 16 does not allow dividing a disk into 17 pieces, whereas a
> well-designed logical volume manager would allow that (and much more).

I think an LVM would be really cool, but that it solves a slightly
different problem. All the LVM's I've seen get the whole disk, and divvy
it up. That makes sharing disks between OSs hard. I think fixed
partitioning will help us more with supporting multiple OSs on a disk.

> the fact that people want this feature right now does not justify
> making incompatible changes that are clearly not the best solution.
> back when ISA DMA was still an important issue for many people,
> people wanted bounce-buffering "right now".  rather than just hack all
> the relevant drivers to provide that, NetBSD designed and implemented
> the bus_dma framework, which has been a far superiour solution in the
> long run.  why would we start making design decisions based on expediency
> now?  and changing the interpretation of device minor numbers has a far more
> significant downside than the choice of ISA bounce-buffering schemes,
> since the changing the interpretation of device minor numbers is visible
> to applications and it breaks existing usage.

I strongly concur with the above.

Take care,

Bill