Re: Device naming on scbus using isp
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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Device naming on scbus using isp
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 dnel...@allantgroup.com ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Device naming on scbus using isp
Dan Nelson wrote: 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. Thanks Dan, I'm using UFS so looks like labeling will be the solution to this issue ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Device naming on scbus using isp
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
