Messages in this thread |  | | Date | Mon, 8 Jul 1996 20:10:13 -0400 (EDT) | From | Dan Merillat <> | Subject | Re: SCSI device numbering (was: Re: Ideas for v2.1 |
| |
On Mon, 8 Jul 1996, Eric Youngdale wrote:
> Date: Mon, 8 Jul 1996 19:25:49 -0400 > From: Eric Youngdale <eric@aib.com> > To: Dan Merillat <harik@ao.net> > 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 change, BUT THE SYSTEM COMES UP ANYWAY.
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 (chaos.ao.net) 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.
--Dan
|  |