--- 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

Reply via email to