From: gert@greenie.gold.sub.org (Gert Doering)
Newsgroups: comp.os.linux
Subject: Re: SCSI Autodetect? Static table? (Was: ST01/02 and Syquest 5110)
Date: 21 Jan 93 18:39:02 GMT
Organization: GreeniE

eric@tantalus.nrl.navy.mil (Eric Youngdale) writes:

>>I wrote:

>>BTW, there is one detail I do not like at all in the numbering of the scsi
>>hard disks.
>>
>>Why are the SCSI disks numbered
>>
>>/dev/sda* for the first disk (lowest SCSI ID)
>>/dev/sdb* for the second disk (second lowest SCSI ID)
>>/dev/sdc* ...
>>
>>and so on, regardless of the exact SCSI numbers? Imagine a system with
>>three SCSI HDs, ID 0, 1 and 2, and HD 1 crashes. The Disk with ID 2,
>>former /dev/sdc, is now /dev/sdb and the result is big confusion, mis-
>>mounting, ...
>>
>>Why not naming them /dev/sd[i]* with "i" equal to the SCSI ID of the
>>drive?

>	How would you treat tapes and cdroms?  The same way?  Then you be
>forced to have /dev/st1 and /dev/scd2 if you had a /dev/sda0.  Also, you can in
>principle have more than one scsi controller in the system at the same time.
>You are limited to one of each type, and there are probably some that conflict
>with each other so you could have two or three different controllers.  In fact
>I think you could have one of nearly every type of scsi controller that linux
>supports.  How would you treat two disks with the same ID number that are on
>different scsi controllers.

Weeeeelll... right. I see your point.

That's one thing I did not think about.

But nevertheless, I think that confusing device names (-> they could always
be linked to something more tasty ;-) ) are *better* than device names
that change mysteriously just because you add or remove some *other*
hardware in your system. I *know* about it - but what happens when a
system administrator of a later Linux version (1.5?) who does *not* know
it changes some HD and then erases the wrong drive? I think with the
current naming scheme this can happen too fast.

>	Then again, how would you handle drive arrays where you access each
>drive with a separate lun.  Each drive would have the same ID number, but they
>would all have different luns from each other.

Ummm, good point.

That's a point for SCO Unix - there you have a list of SCSI devices (host
adapter number, SCSI ID and lun) and some bits of the device minors select
drives out of this list.

>	The problem is not so much in the device naming, we could come up with
>something that would be suitably confusing that would allow for all of the
                            ^^^^^^^^^ :-)
>possibilities.  It comes up more in the major and minor numbering - there are
>only 8 bits for the device minor number and we have to come up with a
>consistent way of assigning all of the possible ID/lun combinations to the 256
>available minor numbers (recall that each partition will get it's own minor
>number).  The only way to have fixed assignments would be to somehow restrict
>the number of partitions per drive, the number of luns per id, the number of
>disks per controller and/or the number of controllers on the system.

Would there be a way to use different majors for the same driver? I think
that's the way SCO is handling this. Nevertheless, if you want to be able
to use *all* the possible combinations on the SCSI bus (7 devices, 8 luns
each, 4+4 partitions each, multiple controllers) you end up with total
chaos. What about limiting the number of devices on the (one) SCSI bus to
16 (4 bits), somehow divided (how?) between SCSI IDs and LUNs. Then you have
4 bits left to number partitions.

For a second (third,...) SCSI host adaptor, you cold use a different major
number (if that's possible).

>	The one possibile solution would be to allow you to fix the drive
>designator (i.e. a, b, c, etc.) in the table that the scsi code reads at boot
>time. 

This would solve the problem of the changing device names. But it would
introduce others. Hmmm.

How are the minor numbers used right now?

gert
-- 
Gert Doering | SubNet  : gert@greenie.gold.sub.org      | mailbox / uucp:
Munich / FRG | InterNet: gdoering@physik.tu-muenchen.de | call (089)3243328
(089)3243228 | FidoNet : gert.doering@2:246/55.4        | login bbs / nuucp