Device naming on scbus using isp

Brent Bloxam brentb at beanfield.com
Tue Sep 22 21:19:15 UTC 2009


Brent Bloxam wrote:
> I'm wondering about how device names are assigned on scbus, specifically 
> when using the isp driver. It seems to me that there's potential when an 
> HBA has access to multiple LUNs that on boot the scbus will have entries 
> in /dev scrambled compared to the previous run (thus messing up mounts). 
> My experience so far has been that da0 will be assigned to the first 
> target scanned, da1 to the second, etc. Is this generally something 
> countered with device.hints? If a LUN were to go away, but a device hint 
> pointing to the target:unit remained, would that cause any issues on boot?
> 
> Thanks,
> Brent

Thought I'd follow up with a bit of information I've determined about 
this, despite the lack of response from anyone on list. Maybe someone 
will find it useful :)

I can only speak for this applying to use of isp(4) with scbus(4).

Devices that operate in target mode appear to isp(4) and are assigned a 
target ID starting at 0. The order in which they appear depends on their 
fcid or what's known to isp(4) as PortID. This order is ascending, so 
the lower fcid takes precedence. isp(4) will then check the target to 
see if any LUNs are available to it. If not, the target disappears -- 
and here's the important thing to note -- but its target ID does not go 
away.

Say you have 5 devices with the following fcids, 4 in target mode:

0x00 - target
0x01 - target
0x02 - another server with an HBA
0xF0 - target with LUN
0xF1 - target with LUN

isp(4) is loaded at boot, and the following occurs:

0x00 appears, is assigned target 0, and disappears because there are no LUNs
0x01 appears, is assigned target 1, and disappears because there are no LUNs
0x02 appears and simply disappears because it is not a target
0xF0 appears, is assigned target 2, and is assigned to da0
0xF1 appears, is assigned target 3, and is assigned to da1

You can see because of this example that maintaining device names using 
/boot/device.hints is impossible if targets in the fabric change. If 
0x00 were to disappear, the target IDs would change and render 
/boot/device.hints invalid, or worse, the wrong LUN could be given the 
wrong device name.


Ideally, there would be a way to assign target IDs by fcid, but that 
does not exist presently.


More information about the freebsd-questions mailing list