Date: Tue, 22 Sep 2009 17:03:29 -0400 From: Brent Bloxam <brentb@beanfield.com> To: freebsd-questions@freebsd.org Subject: Re: Device naming on scbus using isp Message-ID: <4AB93BA1.9050105@beanfield.com> In-Reply-To: <4A4500D7.5090104@beanfield.com> References: <4A4500D7.5090104@beanfield.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AB93BA1.9050105>