lkml.org 
[lkml]   [1996]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: SCSI device numbering
Date
From: "Eric Youngdale" <eric@aib.com>
>
>> All other devices on the SCSI busses are numbered with the
>> present method, starting with minor number 16.
>
> Won't work. First of all, for disks we need to be able to address
> individual partitions. Right now we allow for 0-15, so you lose 4 bits
> here. Thus we have only 4 bits left in which to encode scsi ID/lun, etc.

I don't think the kernel should address individual partitions.
On the PC alone there are many ways to partition a disk.
Such as: primary, extended, BSD, SCO, several disk managers,
Windows NT mirrored disks, and a variety of corrupted partition
tables left by fdisk for so many different types of OS.

Some tool can be used to give the kernel offset/size data.

> Also you are assuming that scsi is set in stone and isn't
> changing. We don't want to build in some 640Kb types of
> limitations just to solve this problem for some people.
>
> For some concrete examples, consider that scsi3 extends the lun
> to 5 bits. In SSA, the ID number is extended to 7 bits.

Ok, that is 12 bits.

> We also need to identify what type of controller we are talking to.
> Remember that we can have multiple controllers on the system, so we
> need a unique identifier. Consider that we have 20 some odd supported
> controllers now, so we want to at least allow for 64 or even 128.
> 7 bits here.
>
> Next, remember that we support more than one of any different type
> of controller. We need to do it in such a way that we can identify a given
> card even if others get added. We probably want full 16 bits here, since we
> might need to track things like I/O port address, PCI slot, etc, etc.

These two go together. At the extreme, 16 bits will do.

> Consider that some cards drive multiple channels. Currently some
> cards support 2, but I don't see any reason why more couldn't be
> added. We could say 4 bits here just to be safe.

OK.

> We still have 4 bits required for the partition ID for disk drives.

Maybe.

> Where do we stand? We have 5+7+7+16+4+4=43 bits. Even a symmetric
> 64 bit dev_t woudn't be able to express this.

I calculate 32 bits max. (with 4 bits for partitions)

There is no need for dev_t to be symmetric, and no need for the division
to be the same for block and character devices. You could just double
every estimate I gave to fill 64 bits, then put IDE and all the
proprietary CD-ROM controllers in with the SCSI devices. Forget about
the major/minor stuff.

If you really want to encode the partitions, that requires about
16 bits. primary:2 extended:4 slice:4

> It would be theoretically possible to give a seperate major number
> to each different type of scsi controller. This would shift some
> of the bits to the major number, and if this were done correctly we
> might be able to make things fit in a 64 bit symmetric dev_t.

Think of device numbers as being like IP numbers. You can then split
them in arbitrary ways using a bitmask.

> I have seen some people argue for solutions that work for the small
> systems, but exclude the large systems. I believe that this is
> fundamentally wrong, since the problems with dynamic address shifting
> grow as the number of devices on the sysetem grow. We should be
> looking for solutions that work in the case of large systems (with
> say 500 or more disk drives), and then make sure that this works
> well for the small systems.

People do this because:

Small systems outnumber huge systems in a big way,
perhaps 10000 to 1 depending on your definition of huge.
It is assumed that admins of large systems are really good at
dealing with problems.
On a big system, 500 disks appear as less than 20 because they
go into RAID boxes
A system with 500 disks does not use PCMCIA and/or docking station.

> Note that with the current system, there can be a maximum of 16 disk
> drives (since 16 * 16 partitions = 256 = max minor number). Clearly
> a larger dev_t is needed, no matter how we do it. We need to somehow
> agree on how large this needs to be, and *then* we need to fix the
> filesystems so that they store a dev_t that is this large.

For now, a quick hack would be very helpful. With a different
major number, controller:1 disk:3 partition:4 would work.

I have a concern about 64-bit dev_t. Would it be as fast?
I am most worried about the idea of sparse numbers.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.100 / U:2.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site