Hi SCSI users,
from people using SCSI devices, there's one question that turns up again
and again: How can one assign stable device names to SCSI devices in
case there are devices that may or may not be switched on or connected.
There are a couple of ways to address this problem:
(a) mount by uuid
(b) userspace programs that collect information to create
alternative and persistent names / device nodes, such
as Eric Youngdale's scsidev[1], Doug Gilbert's sg_map[2], scsimon[3],
or Mike Sullivan's scsiname/devnaming[4]
(c) devfs
[1] http://www.garloff.de/kurt/linux/scsidev/
[2] http://www.torque.net/sg/
[3] http://www.torque.net/scsi/scsimon.html
[4] http://oss.software.ibm.com/devreg/
Unfortunately, those approaches all have some deficiencies.
Ad (a): Does only work for ext2 filesystems. For locating
/ one needs additional initrd work.
Ad (b): A considerable amount of work needs to be done in userspace:
- For all devices types you need to probe possible devices
- You need to do SCSI_IOCTL_GET_IDLUN to get controller,bus,
target and unit number
The problem is that the collection of this information is
not always successful. If a medium is not inserted, the
open() fails for some device types, despite O_NONBLOCK.
Assumptions about the order of devices OTOH are not safe,
as remove-single-device/add-single-device may result in a
non-straightforward ordering.
Ad (c): devfs is currently not (yet?) an option for distributions
due to security and stability considerations.
Life would be easier if the scsi subsystem would just report which SCSI
device (uniquely identified by the controller,bus,target,unit tuple) belongs
to which high-level device. The information is available in the kernel.
Attached patch does this:
garloff@pckurt:/raid5/Kernel/src $ cat /proc/scsi/map
# C,B,T,U Type onl sg_nm sg_dev nm dev(hex)
0,0,00,00 0x05 1 sg0 c:15:00 sr0 b:0b:00
1,0,01,00 0x05 1 sg1 c:15:01 sr1 b:0b:01
1,0,02,00 0x01 1 sg2 c:15:02 osst0 c:ce:00
1,0,03,00 0x05 1 sg3 c:15:03 sr2 b:0b:02
1,0,05,00 0x00 1 sg4 c:15:04 sda b:08:00
1,0,09,00 0x00 1 sg5 c:15:05 sdb b:08:10
2,0,01,00 0x05 1 sg6 c:15:06 sr3 b:0b:03
2,0,02,00 0x01 1 sg7 c:15:07 osst1 c:ce:01
2,0,03,00 0x05 1 sg8 c:15:08 sr4 b:0b:04
2,0,05,00 0x00 1 sg9 c:15:09 sdc b:08:20
2,0,09,00 0x00 1 sg10 c:15:0a sdd b:08:30
3,0,10,00 0x00 1 sg11 c:15:0b sde b:08:40
3,0,12,00 0x00 1 sg12 c:15:0c sdf b:08:50
This allows a simple script to parse the map and create device nodes as
needed.
The patch does work the following way.
- Add a find_kdev() function pointer to the high-level driver template
structure. The function takes a Scsi_Device pointer (points to a
low-level device) and returns a name and a kdev_t if the device
is attached to this high-level driver.
- Implement the function for sg, sd, sr, st, osst
- Make scsi/scsi_proc iterate over all devices and calls the high-level
drivers find_kdev() to find out about it.
Obviously, it can only report the assignment of high-level drivers,
if they are loaded, otherwise the last two columns will stay empty.
(sg is handled especially, as we know it supports all devices.)
If we attach a third high-level device driver, two more columns would show
up.
(Is this variable column number format a problem?)
The patch also includes a simple shell script that does assign
/dev/scsi/sdc2b0t9u0 type names to those devices and making a device nodes
(or optionally symlinks to the old name devices) with this name.
The design allows for two more things:
* using root=/dev/scsi/sdc1b0t9u0p5 without much additional code
(patch follows in another mail)
* in case we want to support more than 128 scsi disks, the information
about additional majors can be reported by /proc/scsi/map without further
change
Patch is against 2.4.19pre10.
I'd like to get it accepted into the kernel.
So please give your criticism ...
I already got some by Doug Gilbert :-)
A patch for 2.5 should be done as well, if the design is OK, of course.
Regards,
-- Kurt Garloff <kurt@garloff.de> [Eindhoven, NL] Physics: Plasma simulations <K.Garloff@TUE.NL> [TU Eindhoven, NL] Linux: SCSI, Security <garloff@suse.de> [SuSE Nuernberg, DE] (See mail header or public key servers for PGP2 and GPG public keys.)
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:33 EST