Re: SCSI device numbering (was: Re: Ideas for v2.1

Dan Merillat (
Mon, 8 Jul 1996 20:10:13 -0400 (EDT)

On Mon, 8 Jul 1996, Eric Youngdale wrote:

> Date: Mon, 8 Jul 1996 19:25:49 -0400
> From: Eric Youngdale <>
> To: Dan Merillat <>
> Subject: Re: SCSI device numbering (was: Re: Ideas for v2.1
> >We have vendor, model number etc. ID's may change, but that won't. If
> >you can ioctl on each scsi device and get that back you can build
> >a /dev/scsi tree that looks like
> >
> >/dev/scsi/HP_C3725S_<serial>/
> >/dev/scsi/QNTM_XP34301_<serial>/
> Take a look at scsidev. This is similar to what it does (the
> aliasing allows matching upon manufacturer name, etc).
> Serial numbers are not present for all devices, so this cannot
> be used. To be perfectly general, some other mechanism needs to be used.

Ok, but I mean for scsi disks... this is the /dev/scsi/disk tree to be
perfectly accurate. Besides, if the disk dosn't have a serial number
you would be shooting yourself in the foot with it anyway, as you would
have nothing absolute to go on. In that case I would recommend putting
a number at the 510 byte mark (Lilo dosn't use that if I remember right)
but the point is that there SHOULD be some kind of identification on the
drive to absolutly identify it. So that solves the problem. If the drive
you normally use for /opt/games is the third dynamic (of 5) and it dies,
it was in the fstab as /dev/scsi/disk/MANUFACTURER_MODEL_SERIAL/1 (same as
/dev/sdc1) and the one after it (/dev/sdd1) was in as
/dev/scsi/disk/MANUFACTURER2_MODEL2_SERIAL/1 (which happens to be mounted
as /home)

And this solves the root of the problem. A remote system reboots, and a
non-vital disk fails to spin up. The dynamically assigned device numbers

And look, no kernel modifications! All done in pagable, throwwaway,
non-memorywasting user space! Now, I know the proponents of a /proc/dev
tree will hate me, but I run both types of servers. A high end 128mb
Pentium system with all the goodies, AND a 486/50 with 4 meg of ram.
I couldn't run the 486 on a bloated kernel. I only have 1.5 meg of
userspace memory after libc loads anyway. But it's still there
( being a mailhost. I have to laugh at all the arguments...
"Hey! lets make dev_t 258 bits! That way...." Unless there is a shortage
of device numbers IN GENERAL, I don't see a reason to add more bits.