Leech, Christopher wrote:
> Yes, it's because when fc_remote_port_add gets called it only revives
> ports in a blocked state if the wwnames match was well as the id. So
> the old directory server port stays in a blocked state until the
> dev_loss_tmo fires and deletes it.
>
> I'll look at it, but I think it's more an a problem in scsi_transport_fc
> with creating rports before all the names are known. James Smart and I
> talked briefly about changing that, so we could get rid of the temporary
> ID and name holders during discovery as well.
That sounds good to me. For rports other than the directory server, if the
FC_ID is found but it's a different port_name then it seems to me we have to
verify the port_name before using it. While verifying it, the rport
would remain blocked or in a new state. If port_name or node_name
mismatch, we should keep both, but clear the FC_ID in the old one.
The current implementation is probably better because it doesn't add
fields to the fc_rport that would only be used during verification
of the port name.
But for well-known addresses, I'll bet we can change the port_name
and node_name anytime ... nothing should care. There's no
persistent-binding impact.
Joe
>
> - Chris
>
> Joe Eykholt wrote:
>> I sometimes see multiple rports to the directory server. I think
>> this may happen after a host reset because the old rport gets blocked
>> and when we restart discovery we create a new one. Note that the
>> number in the /sys file name gets incremented each time and can get
>> large.
>>
>> I think we should look up the directory server without regard to the
>> port name or host name, and change them to whatever we have from the
>> PLOGI response.
>>
>> Here's a portion of fcc output:
>>
>> host5 Remote Ports:
>> Path Port Name Port ID State Roles
>> 5:0-1 2100002037329f5a 1300dc Online FCP Target
>> 5:0-2 2100002037323844 1300e0 Online FCP Target
>> 5:0-28 250d000dec6da040 fffffc Blocked Directory Server
>> 5:0-29 250d000dec6da040 fffffc Online Directory Server
>> ...
>>
>> 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
