Date: Mon, 30 Jul 2001 07:39:00 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Martin Aherron <martin@cybernetics.com> Cc: <freebsd-scsi@FreeBSD.ORG> Subject: Re: ISP support for WWN Message-ID: <20010730072610.N45229-100000@wonky.feral.com> In-Reply-To: <01Jul26.170453edt.119044@cyborg.cybernetics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the delay... On Thu, 26 Jul 2001, Martin Aherron wrote: > Matt - > > I was looking over the isp driver in both -stable and -current. I have not > really dug in yet but it appears that you are adding the ability to wire > (if that is the proper FreeBSD terminology) a particular WWN to a device > name. If I am correct - what is the status of that functionality? I have > only worked with -stable up till now so I can't run a quick test. The only way I was ever intending to 'wire' a device name to a WWN in FreeBSD would be to have WWNs export to devfs. The config framework in *NetBSD* might allow for this kind of wiring in their config framework- but I doubt I'd ever spend the time to do this. That is, it's probably worth doing, but the priority of getting it done falls below, say, an IP stack for the ISP driver. > > Assuming this feature is available/coming soon has any discussion occurred > about some mechanism for supporting hot swap of FC devices, without > rebooting, such that the new device shows works with the previous device > name? The 'hot-swap' feature already partially exists in -current. This is code snippet from isp_freebsd.c: case ISPASYNC_PROMENADE: { struct cam_path *tmppath; const char *fmt = "Target %d (Loop 0x%x) Port ID 0x%x " "(role %s) %s\n Port WWN 0x%08x%08x\n Node WWN 0x%08x%08x"; static const char *roles[4] = { "(none)", "Target", "Initiator", "Target/Initiator" }; fcparam *fcp = isp->isp_param; int tgt = *((int *) arg); int is_tgt_mask = (SVC3_TGT_ROLE >> SVC3_ROLE_SHIFT); struct lportdb *lp = &fcp->portdb[tgt]; isp_prt(isp, ISP_LOGINFO, fmt, tgt, lp->loopid, lp->portid, roles[lp->roles & 0x3], (lp->valid)? "Arrived" : "Departed", (u_int32_t) (lp->port_wwn >> 32), (u_int32_t) (lp->port_wwn & 0xffffffffLL), (u_int32_t) (lp->node_wwn >> 32), (u_int32_t) (lp->node_wwn & 0xffffffffLL)); ISPLOCK_2_CAMLOCK(isp); if (xpt_create_path(&tmppath, NULL, cam_sim_path(isp->isp_sim), (target_id_t)tgt, CAM_LUN_WILDCARD) != CAM_REQ_CMP) { CAMLOCK_2_ISPLOCK(isp); break; } /* * Policy: only announce targets. */ if (lp->roles & is_tgt_mask) { if (lp->valid) { xpt_async(AC_FOUND_DEVICE, tmppath, NULL); } else { xpt_async(AC_LOST_DEVICE, tmppath, NULL); } } xpt_free_path(tmppath); CAMLOCK_2_ISPLOCK(isp); break; } As devices that support TARGET capability arrive or depart, an async event is generated for the path that includes bus && target and a wildcarded LUN. > I am specifically thinking of a tape library with multiple native FC tape > drives. The drives currently do not allow hard addressing. If a drive > needs to be replaced the replacement drive would need to show up as the > old device to keep any application software/scripts happy. > I think that the right thing to do here would be to support WWN alias names in /dev. But there's another issue here, really. You're talking about replacing a drive. If the WWN stays the same, ISP already guarantees that *while you're still in the same boot session* that the target ID doesn't change. If there's no notification (e.g., via a LIP causing a Port Database or Name Server Database change) that the device has gone (e.g., on a segmented loop), the device, even if it appears at a different Loop or Port ID, will still retain the same target ID. But when you reboot, all bets are off- first come, first assigned, etc. This is where a /dev/wwn/XXXX might be useful. We've tended to not have to try really hard to solve this SAN problem because the preponderance of devices on SANs are disks, and the only time you see a disk that's without a self-identifying volume manager type of label on it is when it's fresh and you're importing it, in which case you don't have any device unit number to preserve as yet. Tapes are indeed a different story. Again, the best bet for this might be WWN aliasing. This bcomes a bit awkward- you'll have a 16 digit hex number and suffixes like you have for tape. I'll put this into my spanking new bugzilla database to remind me to get it done. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010730072610.N45229-100000>