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>