--- On Mon, 2/15/10, Joe Eykholt <[email protected]> wrote:
> From: Joe Eykholt <[email protected]>
> Subject: Re: [Scst-devel] [RFC PATCH] scst: new target module fcst adapts to
> open-fcoe libfc
> To: "Chetan Loke" <[email protected]>
> Cc: "Vladislav Bolkhovitin" <[email protected]>,
> [email protected], [email protected]
> Date: Monday, February 15, 2010, 4:29 AM
> Chetan Loke wrote:
> > --- On Fri, 2/12/10, Joe Eykholt <[email protected]>
> wrote:
> >
> >> If the remote initiator logs in before the target
> is
> >> configured and
> >> enabled for that initiator, it may need to be
> reset to
> >> "see" the target
> >> and probe the LUNs. I suppose there's a way
> to do
> >> this nicer ...
> >
> > nicer == RSCN's,no? Let the switch take care of it.But
> the onus is really on the intiator side to regsiter SCN's.
>
> Well the initiators all register for RSCNs, but RSCN only
> gets sent by the fabric when there's a new N-port logged
> in,
> not when an N port changes roles, as far as I know.
Agreed, but how many production SAN's actually run initiator+target on the same
target box? You see what I was getting at?
Ok, lets look at some real life target implementations. How many target vendors
really advocate using a few ports in initiator mode on the target-box? Let's
ignore vendors. How many customers use initiator+target on a single box? Till
date I have never ever found a single customer trying to configure an
initiator+target on the same host. Let's ignore performance anaylsis or
engineering rigs because these don't qualify as production SANs.But yes, during
normal development one can just reset the port.
> Resetting the local port causes the target to logout and
> re-login to the fabric, which will cause the RSCNs to be
> sent, but maybe RFF can do the same thing. I'll
> check.
> It sounds heavyweight but if the local port is only for
> target use and not also an initiator, it's non-disruptive.
> Even if it is an initiator, it's not *very* disruptive,
> it wouldn't ruin any I/Os in progress.
>
In a stock linux SCSI-LLDD stack,if you were to reset an initiator, and if you
didn't have an alternate storage path, then a reset is disruptive and invasive
for in-flight IO.You would've to ABTS all the in-flight IO and the scsi layer
would have to requeue it again when the path's come back.
Chetan Loke
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel