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).
Joe
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
