Subject: Re: Another changer, another changer problem
To: NetBSD-current Discussion List <>
From: Bill Studenmund <>
List: current-users
Date: 10/05/1998 10:44:37
On Sun, 4 Oct 1998, Greg A. Woods wrote:

> I think all of Bill's confusion comes from a simple off-by-one
> assumption he's making.  I don't quite know why, since I *never*
> mentioned "major" numbers when talking about the idea of having a fixed
> "minor" number to reference the raw disk....

But Greg, that's in-band! :-)

> How about we explain it this way:  If you count your partitions from
> "one" (1), then there's a spare minor number for each ``unit'' (0).
> I.e. one could simply assume there are 17 (or 23) slices per unit and
> use the 0'th [or 17'th (or 23'rd) if you detest counting from one] unit
> as the raw disk.
> 	SCSI-raw-minor = bus * target * LUN * 23
> 	SCSI-part-minor = bus * target * LUN * 23 + part (where part is origin 1)
> There.  Understand?  Don't like "23" as a magic number?  Then pick 32 or
> 64 or some such "nicer" number that's also larger and deal with the
> empty space (i.e. return ENXIO)....

But that's basically what we do now, except you've decided to use 0
instead of 2 or 3 (c/d). Granted that if we have 64 partitions, we might
not notice, but it still is a minor number, in-band with all the others.

> Of course this means for SCSI-3 (with 16 targets/bus and 8 LUNs/target
> -- or are there more?) that we need a minimum of 2944 minor numbers per
> SCSI bus.
> That's why I think it's a good idea to put every SCSI bus on a separate
> major number (regardless of how close we are to hitting the maximum size
> of a minor number).  Also by doing so one is certain to wire down the
> location of drives by bus.

Ack! But VERY few devices EVER have more than one LUN. To reserve all this
space (7/8ths of it) for a rarity seems a waste. And it is a step
backwards from our current scsi layer, where we've eliminated the
necessity of reserving all this device space.

> It may be the case that nobody ever puts more than two or four SCSI
> cards in any given system, but *I* don't ever want to make it impossible
> for users of those really big servers to put in 10, 20, 30, 100, or more
> host adapters in a given system.

But we still have the problem we started with: you can tie devices to
scsibusX, but you still can't tie them to a particular controller. If one
of your controllers dies, all the higher numbered busses re-number.

The only way to nail the scsibusses down is in a kernel config. In the
same way which would nail the devices down now. Since that idea is not
acceptable, we will have added a fair amount of bloat (all these major
and minor numbers used for little gain) and we still don't have things
wired down.

If you have a server where you care what's where and you want things to
work even if controllers go down, you MUST wire EVERYTHING down. No more
ncr* at blah.

> I note with glee that this idea of having a fixed "raw" disk partition
> that's not really a partition (i.e. it's not in the disklabel) does
> indeed eliminate the need for having a "convention" of defining a 0-max
> partition, and thus as others have already mentioned it also eliminates
> the need for the current confusion of different platforms having
> different conventions (i.e. the 'c' vs. 'd' mess).

I don't think the c/d mess is too bad. I run two machines w/ it 'd' and
three with it 'c'. :-)

Maybe for now just make sdX partitions which are the c or d minor number?

Take care,