Date: Tue, 22 Sep 2009 16:43:30 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Brent Bloxam <brentb@beanfield.com> Cc: freebsd-questions@freebsd.org Subject: Re: Device naming on scbus using isp Message-ID: <20090922214330.GG29215@dan.emsphone.com> In-Reply-To: <4AB93BA1.9050105@beanfield.com> References: <4A4500D7.5090104@beanfield.com> <4AB93BA1.9050105@beanfield.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Sep 22), Brent Bloxam said: > 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? > > 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. If you're mounting UFS filesystems, you can label them and mount them by label (see the tunefs and glabel manpages for more info). ZFS should find its pool devices automatically, but you can always manually label devices with glabel and refer to the label instead of the da## name. -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090922214330.GG29215>