On Thu, 2010-01-14 at 17:11 -0800, Joe Eykholt wrote:
> Robert Love wrote:
> > On Thu, 2010-01-14 at 16:29 -0800, Vasu Dev wrote:
> >> The sysfs host scan detects only new lun addition and each existing
> >> lun's rescan is required to correctly detect any removed or replaced
> >> luns with possibly different lun capacity.
> >>
> >> The fcoe interface reset removes and then adds target ports which
> >> effectively does same as sysfs host scan w/o detecting any change to
> >> existing lun/s, so this patch adds fc_fcp_rescan to trigger each lun
> >> rescan to detect any change to lun/s.
> >>
> >> I think added fc_fcp_rescan on reset is quick and makes reset case
> >> more useful to also detect any lun changes instead doing each lun
> >> rescan from user land.
> >>
> >> For RFC I added this to only fcoe.ko reset but can be easily moved to
> >> scsi_transport_fc or fc_lport_reset as this should be useful to
> >> other FC or FCoE HBA also.
> >>
> >> Any comment on this ?
> >>
> >> Signed-off-by: Vasu Dev <[email protected]>
> >> ---
> >>
> >>  drivers/scsi/fcoe/fcoe.c |    1 +
> >>  include/scsi/libfc.h     |   12 ++++++++++++
> >>  2 files changed, 13 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/drivers/scsi/fcoe/fcoe.c b/drivers/scsi/fcoe/fcoe.c
> >> index 10be9f3..aee1d9b 100644
> >> --- a/drivers/scsi/fcoe/fcoe.c
> >> +++ b/drivers/scsi/fcoe/fcoe.c
> >> @@ -2238,6 +2238,7 @@ int fcoe_reset(struct Scsi_Host *shost)
> >>  {
> >>    struct fc_lport *lport = shost_priv(shost);
> >>    fc_lport_reset(lport);
> >> +  fc_fcp_rescan(lport);
> > 
> > Is there any timing concern here? I don't think that fc_lport_reset()
> > blocks until the lport is READY. If the host is down when
> > scsi_rescan_device() is called do the rescan requests get queued?
> > 
> > Thanks, //Rob
> 
> I don't know the answer to that, but
> I would think the fc_lport_reset() would be sufficient, because
> all the rports should go away and come back ... 
> SCSI should rescan
> in that case.  (I'm not absolutely sure it does, though).

Yes port does go away and comes back as I mentioned in patch description
and as you said the scsi also rescan target but for only any new luns
and doesn't detect any change to existing lun unless rescan is triggered
on existing lun.

For instance, add a clarion tgt w/o any lun assigned and create fcoe
interface, the initiator will discover lun-0 with zero capacity. Now add
a valid lun to same tgt and that will also get reported as lun-0 from
tgt since this would be the first lun on tgt and now try using added lun
wih current fc_lport_reset or host scan. The added lun won't be usable
since these actions won't cause lun rescan.

Above steps can be repeated with replacing luns also and you would get
same results unless either user rescan luns or destroy and then
re-creates the interface.

        Vasu
> 
>       Joe
> _______________________________________________
> devel mailing list
> [email protected]
> http://www.open-fcoe.org/mailman/listinfo/devel

_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel

Reply via email to