"WANG,YIDING (HP-SanJose,ex1)" wrote:
>
> I have an issue regarding scsi device node assignment to scsi device in
> Linux.
>
> As current device node assignment, Linux will assign a detected scsi device
> with next available device node, namely sdb, sdc, sdd, ... etc. The device
> node itself dosn't have information about card number, taget id or LUN
> compare with the dvice node in Unixware or Solaris which has those
> information available in device node.
>
> It works OK until I am trying to do persistent binding for our fibre channel
> HBA.
>
> Considering if a system has one scsi driver as primary boot device, and a
> fibre channel HBA which connected with JBOD, RAID and other FC devices on
> fabric, or even simplier, just hooked with a JBOD. Persistent binding
> requires device node (or device - mount point pair) to be consistent from
> boot to boot. Currently what we can do is to assure that from boot to boot
> that the devices connected with our FC HBA are persistent even user swaped
> devices, or added new devices in FC loop or fabric. The problem comes when
> there is a new scsi device added in the system (or another HBA added in
> which take place in front of our HBA). Then at very next reboot, those new
> added scsi device will be scanned first and be assigned with those available
> device node which could be used by our HBA at last boot. This will ruine
> the persistent binding. (e.g. from last boot, we have sda assigne to primary
> scsi device, sdb, sdc, sdd assigned to FC devices. Now the new added scsi
> device will take sdb. The device node assigned to fc device became sdc, sdd
> and sde).
>
> If Linux scsi device node assignment is nased on slot, or has card, target
> and lun information associated with, then even new scsi devices are added in
> the front, we can still keep our previous assigned device node for
> persistent binding.
>
> Is there a way for driver to force Linux to reserve the device node that has
> been assigned to a particular device?
>
> If not, any suggestion to resolve the issue?
>
> By the way, this is not a problem for other UNix such as Solaris, both Sparc
> and x86 where our persisten binding works just fine.
Hopefully the answer is devfs, the device pseudo file system
introduced in lk 2.3.46 . It is also avaliable as a patch
to 2.2 series kernels. I have written a page about devfs
and the Linux SCSI subsystem:
http://www.torque.net/sg/devfs_scsi.html
One outstanding issue is the "scsihosts" boot time option
specified in the devfs documentation. This would allow the
user to specify the order in which HBA drivers are to be
scanned. Even though logic is present to interpret the
given string, the logic to modify the scan order does not
seem to be present.
Also, during the boot sequence the root partition is found
by major:minor number. This maps directly to the existing
/dev/sda1 type naming system. How this major:minor
number maps to the devfs naming system depends on several
variables.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
