John Forte wrote:
> Garrett D'Amore wrote:
>> John Forte wrote:
>>> Garrett D'Amore wrote:
>>>> In principle this looks good, and I'm almost ready to +1 it, but I
>>>> have a few questions first:
>>>>
>>>> 1) I don't know enough about the FC protocol... will forcing target
>>>> ports to reinitialize have any negative implications for the
>>>> initiators? I'd like to understand the ramifications of any side
>>>> effects.
>>> The initiators will get a RSCN (Remote State Change Notification)
>>> from the FC switch, which will generally cause them to rediscover
>>> for any changes to the fabric, which is generally the desired
>>> behavior from the administrator issuing this command.
>>
>> Does this have negative implications for any in-flight I/O? (I.e. is
>> this command potentially destructive?) Are the implications
>> restricted to just the target being reinitialized? (Sorry if it
>> sounds like I'm being paranoid here, but to a certain extent a little
>> paranoia can be helpful. :-) If its potentially destructive, then
>> I'd like to have a warning issued to the administrator first. If it
>> can't be destructive, then we needn't worry about it.
> Likely a bit disruptive but it shouldn't be destructive. Certainly the
> target port will re-initialize it's login with the switch. When this
> command was first implemented in luxadm, FC switched fabrics did not
> exist and it was much more disruptive in that it forced every
> participating port in the fibre channel arbitrated loop to
> renegotiate. That is no longer the case with switched fabrics in FC. I
> think at most we should have the documentation for the subcommand
> indicate the appropriate warnings to the extent that it will result in
> an RSCN from the switch to all zoned initiators. My preference would
> be to not have a warning issued to the administrator forcing a
> confirmation prior to executing the initialization of the link. I
> think FC administrators are generally savvy enough to understand the
> meaning of this operation and when it should be used as well as what
> impact it's likely to have. My opinion is anything more than a
> documented warning would be annoying.
Okay, as long as it can't cause data loss, I'm fine with it. (The
disruption would be expected. :-) Documentation of the disruption
details in the man page would be a good idea, though.
I'll go ahead and grant my +1 at this point.
-- Garrett
>
> - John
